เทมเพลตข้อมูลการจัดการสัญญาของคุณ
เทมเพลตข้อมูลการจัดการสัญญาของคุณ
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ การจัดการสัญญา หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- โมเดลข้อมูลมาตรฐานสำหรับกระบวนการจัดการสัญญา.
- แอตทริบิวต์และกิจกรรมที่แนะนำสำหรับการวิเคราะห์อย่างละเอียด.
- คำแนะนำในการดึงบันทึกเหตุการณ์ ไม่ว่าคุณจะใช้ระบบต้นทางใด.
แอตทริบิวต์การจัดการสัญญา
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| Contract ID ContractId | รหัสเฉพาะของสัญญาแต่ละฉบับ ใช้เป็นรหัสกรณีหลักที่เชื่อมโยงกิจกรรมและเอกสารที่เกี่ยวข้องทั้งหมด. | ||
| คำอธิบาย Contract ID คือรหัสเฉพาะที่กำหนดให้กับวงจรชีวิตของสัญญาแต่ละฉบับ ทำหน้าที่เชื่อมโยงเหตุการณ์ทั้งหมด ตั้งแต่คำขอเริ่มต้นจนถึงการหมดอายุหรือยุติสัญญา กิจกรรมต่างๆ เช่น การจัดทำร่าง การตรวจสอบ การอนุมัติ และการลงนาม จะเชื่อมโยงกับรหัสนี้โดยตรง. ในการวิเคราะห์ process mining นั้น Contract ID เป็นข้อมูลพื้นฐานที่ใช้สร้างเส้นทางของสัญญาแต่ละฉบับตั้งแต่ต้นจนจบ เครื่องมือจะจัดกลุ่มเหตุการณ์ที่เกี่ยวข้องให้เป็นกรณีเดียวกัน เพื่อแสดงภาพและวิเคราะห์ลำดับการทำงานทั้งหมด หากไม่มี Contract ID ที่สอดคล้องกัน ก็จะวัดระยะเวลาดำเนินการ ระบุคอขวด หรือวิเคราะห์รูปแบบกระบวนการได้ไม่แม่นยำ. เหตุผลที่สำคัญ รหัสนี้จำเป็นต่อการติดตามสัญญาตลอดวงจรชีวิต และช่วยให้ค้นพบกระบวนการและวัดผลการดำเนินงานได้อย่างแม่นยำ. แหล่งข้อมูล โดยทั่วไปจะพบในส่วนหัวหรือระเบียนหลักของสัญญาในระบบ Contract Lifecycle Management (CLM). ตัวอย่าง CTR-2023-00123MSA-98765-ACMENDA-GLOBAL-4510 | |||
| ชื่อกิจกรรม ActivityName | ชื่อของเหตุการณ์ทางธุรกิจ งาน หรือหมุดหมายที่เกิดขึ้นในวงจรชีวิตของสัญญา. | ||
| คำอธิบาย ชื่อกิจกรรมใช้ระบุขั้นตอนในกระบวนการจัดการสัญญา กิจกรรมเหล่านี้หมายถึงงานแต่ละรายการ เช่น 'จัดทำร่างสัญญาแล้ว' 'ตรวจสอบโดยฝ่ายกฎหมายเสร็จแล้ว' หรือ 'ลงนามในสัญญาแล้ว' เมื่อนำกิจกรรมของ Contract ID เดียวกันมาเรียงตามเวลา จะเห็นลำดับการทำงานของกระบวนการ. ข้อมูลนี้เป็นหัวใจสำคัญในการสร้างแผนผังกระบวนการ ซึ่งเป็นภาพหลักที่ใช้ในการทำ process mining การวิเคราะห์ลำดับและความถี่ของกิจกรรมช่วยให้ผู้วิเคราะห์เข้าใจการทำงานจริง ระบุขั้นตอนที่ต่างจากแนวทางมาตรฐาน และหาจุดที่ต้องทำงานซ้ำหรือไม่มีประสิทธิภาพ เช่น การแก้ไขเอกสารหลายรอบ. เหตุผลที่สำคัญ ข้อมูลนี้กำหนดขั้นตอนของกระบวนการ ช่วยให้เห็นภาพวงจรชีวิตของสัญญาและระบุขั้นตอนที่เบี่ยงเบนจากกระบวนการปกติหรือเกิดคอขวด. แหล่งข้อมูล โดยทั่วไปจะพบในบันทึกเหตุการณ์ บันทึกการตรวจสอบ หรือตารางประวัติสถานะที่เชื่อมโยงกับระเบียนสัญญาหลัก. ตัวอย่าง ร่างสัญญาเสร็จอนุมัติภายในเสร็จส่งสัญญาเพื่อลงนาม | |||
| เวลาเริ่มเหตุการณ์ EventStartTime | วันและเวลาที่ระบุอย่างแม่นยำว่ากิจกรรมหรือเหตุการณ์เริ่มต้นเมื่อใด. | ||
| คำอธิบาย เวลาเริ่มเหตุการณ์ระบุจุดเริ่มต้นของกิจกรรมในวงจรชีวิตของสัญญา เวลานี้จำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลา คำนวณระยะเวลาของแต่ละกิจกรรม และวัดเวลารวมของกระบวนการ อีกทั้งยังช่วยให้เข้าใจลำดับการทำงานเมื่อเวลาผ่านไป. ในการวิเคราะห์ จะใช้เวลานี้สร้างแผนผังกระบวนการและคำนวณ KPI สำคัญ เช่น 'ระยะเวลาดำเนินการสัญญาเฉลี่ย' และ 'ระยะเวลาอนุมัติเฉลี่ย' นอกจากนี้ยังช่วยวิเคราะห์คอขวด โดยแสดงให้เห็นว่าขั้นตอนใดใช้เวลานานที่สุด การเปรียบเทียบเวลาเริ่มของแต่ละกิจกรรมช่วยตรวจสอบระยะเวลาระหว่างขั้นตอนได้อย่างละเอียด และชี้ให้เห็นความล่าช้าในกระบวนการ. เหตุผลที่สำคัญ เวลานี้จำเป็นต่อการเรียงลำดับเหตุการณ์ คำนวณระยะเวลาดำเนินการ และระบุคอขวดที่เกี่ยวข้องกับเวลา. แหล่งข้อมูล ดูได้จากบันทึกการตรวจสอบของระบบ ระเบียนธุรกรรม หรือตารางประวัติเหตุการณ์ที่บันทึกเวลาของแต่ละขั้นตอน. ตัวอย่าง 2023-03-15T09:00:00Z2023-05-20T14:30:15Z2023-06-01T11:22:05Z | |||
| ระบบต้นทาง SourceSystem | ชื่อระบบไอทีหรือแอปพลิเคชันที่ใช้ดึงข้อมูลสัญญา. | ||
| คำอธิบาย ข้อมูลระบบต้นทางใช้ระบุแหล่งที่มาของข้อมูลเหตุการณ์ ในหลายองค์กร วงจรชีวิตของสัญญาอาจเกี่ยวข้องกับหลายระบบ เช่น แพลตฟอร์ม CLM, CRM สำหรับเริ่มคำขอ และระบบ ERP สำหรับข้อมูลทางการเงิน การระบุระบบต้นทางของแต่ละเหตุการณ์มีความสำคัญต่อการตรวจสอบข้อมูลและทำความเข้าใจระบบเทคโนโลยีที่รองรับกระบวนการ. ในการวิเคราะห์ process mining ข้อมูลนี้ช่วยระบุการแยกส่วนของกระบวนการระหว่างระบบต่างๆ และอาจแสดงให้เห็นว่าความล่าช้าหรือปัญหาเกิดจากการส่งต่อข้อมูลระหว่างแอปพลิเคชันใด นอกจากนี้ยังสำคัญต่อการกำกับดูแลข้อมูลและการสืบหาต้นตอของปัญหาคุณภาพข้อมูล. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูล ซึ่งจำเป็นต่อการตรวจสอบข้อมูล ทำความเข้าใจการแยกส่วนของกระบวนการ และแก้ไขปัญหาคุณภาพข้อมูล. แหล่งข้อมูล โดยทั่วไปจะเพิ่มข้อมูลนี้ระหว่างการดึงข้อมูล หรืออาจมีเป็นช่องมาตรฐานในบันทึกของระบบ. ตัวอย่าง AgiloftSAP AribaDocuSign CLM | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ข้อมูลของเหตุการณ์นี้ได้รับการรีเฟรชหรือดึงจากระบบต้นทางครั้งล่าสุด. | ||
| คำอธิบาย เวลาอัปเดตข้อมูลล่าสุดระบุว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด โดยแสดงเวลาที่กระบวนการดึง แปลง และโหลดข้อมูล (ETL) ทำงานครั้งล่าสุด ช่วยให้ทราบว่าผลการวิเคราะห์เป็นปัจจุบันแค่ไหน เวลานี้ต่างจากเวลาของเหตุการณ์ ซึ่งบันทึกเวลาที่กิจกรรมทางธุรกิจเกิดขึ้น. ข้อมูลนี้สำคัญต่อการกำกับดูแลข้อมูลและการแจ้งผู้เกี่ยวข้องว่าข้อมูลเชิงลึกเป็นข้อมูลล่าสุดเพียงใด ช่วยให้ผู้ใช้ทราบว่ากำลังดูข้อมูลแบบเรียลไทม์ หรือข้อมูล ณ วันหรือสัปดาห์ก่อน บริบทนี้จำเป็นต่อการตัดสินใจได้ทันเวลาและมีข้อมูลประกอบจากแดชบอร์ด process mining. เหตุผลที่สำคัญ ช่วยให้ผู้เกี่ยวข้องทราบว่าข้อมูลเป็นปัจจุบันเพียงใด และเข้าใจว่าข้อมูลเชิงลึกเกี่ยวกับกระบวนการอ้างอิงจากข้อมูลล่าสุดหรือไม่. แหล่งข้อมูล โดยทั่วไปเครื่องมือเชื่อมต่อข้อมูลหรือ ETL จะสร้างและจัดเก็บเวลานี้ระหว่างโหลดข้อมูล. ตัวอย่าง 2023-10-26T02:00:00Z2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| ชื่อคู่สัญญา CounterpartyName | ชื่อบุคคลภายนอก บริษัท ลูกค้า ผู้ขาย หรือพันธมิตรที่เกี่ยวข้องกับสัญญา. | ||
| คำอธิบาย ชื่อคู่สัญญาระบุหน่วยงานภายนอกที่องค์กรทำข้อตกลงด้วย อาจเป็นลูกค้า ผู้จัดหา หรือพันธมิตร ข้อมูลนี้ช่วยให้เข้าใจความสัมพันธ์ทางธุรกิจที่สัญญากำกับดูแล. คู่สัญญาเป็นมิติที่มีประโยชน์อย่างยิ่งในการวิเคราะห์ ช่วยให้ธุรกิจวิเคราะห์ประสิทธิภาพของกระบวนการแยกตามผู้ขายหรือลูกค้าได้ ตัวอย่างเช่น อาจพบว่าการเจรจากับคู่สัญญาบางรายใช้เวลานานกว่าค่าเฉลี่ยอย่างต่อเนื่อง ข้อมูลนี้ช่วยวางแผนการเจรจาในอนาคต บริหารความสัมพันธ์ และจัดทำแม่แบบสัญญาที่เหมาะกับพันธมิตรเชิงกลยุทธ์เพื่อให้กระบวนการเร็วขึ้น. เหตุผลที่สำคัญ ระบุคู่สัญญาภายนอก ช่วยวิเคราะห์ระยะเวลาดำเนินการและรูปแบบการเจรจาแยกตามลูกค้าหรือผู้ขาย. แหล่งข้อมูล เป็นช่องมาตรฐานในระเบียนสัญญา ซึ่งมักเชื่อมโยงกับระเบียนข้อมูลหลักของลูกค้าหรือผู้จัดหา. ตัวอย่าง Acme CorporationGlobal Tech Inc.Innovate Solutions LLC | |||
| ชื่อผู้ใช้ UserName | ชื่อหรือ ID ของผู้ใช้ พนักงาน หรือทรัพยากรที่ทำหรือรับผิดชอบกิจกรรมเกี่ยวกับสัญญา. | ||
| คำอธิบาย ชื่อผู้ใช้ระบุผู้รับผิดชอบงานแต่ละรายการในวงจรชีวิตของสัญญา เช่น เจ้าของสัญญา ผู้ตรวจสอบจากฝ่ายกฎหมาย ผู้อนุมัติ หรือผู้ลงนาม ข้อมูลนี้เชื่อมโยงกิจกรรมในกระบวนการกับผู้ที่ดำเนินการ. ในการทำ process mining ข้อมูลนี้ช่วยให้เห็นผลการทำงานของทีมและบุคคล โดยใช้ในแดชบอร์ดอย่าง 'ภาระงานและผลิตภาพของทีม' เพื่อวิเคราะห์การกระจายงาน ระบุพนักงานหรือทีมที่มีภาระงานมากเกินไป และประเมินผลการทำงาน นอกจากนี้ยังช่วยให้เข้าใจว่าพฤติกรรมการทำงานที่แตกต่างกันส่งผลให้กระบวนการเปลี่ยนแปลงหรือล่าช้าอย่างไร และนำไปใช้วางแผนการฝึกอบรมหรือจัดสรรทรัพยากรได้ตรงจุด. เหตุผลที่สำคัญ เชื่อมโยงกิจกรรมในกระบวนการกับบุคคล ช่วยวิเคราะห์การกระจายภาระงาน ประสิทธิภาพของทีม และการจัดสรรทรัพยากร. แหล่งข้อมูล โดยทั่วไปจะพบในระเบียนธุรกรรม บันทึกการตรวจสอบ หรือช่องมอบหมายงานในระบบต้นทาง. ตัวอย่าง John Smithj.smith@example.comUSER12345 | |||
| ประเภทสัญญา ContractType | การจัดประเภทสัญญา เช่น Master Service Agreement (MSA), Non-Disclosure Agreement (NDA) หรือ Statement of Work (SOW). | ||
| คำอธิบาย ประเภทสัญญาเป็นข้อมูลแบบจัดหมวดหมู่ที่ใช้จำแนกสัญญาตามลักษณะทางกฎหมายและวัตถุประสงค์ ประเภทที่พบบ่อย ได้แก่ NDA, MSA, SOW และสัญญาซื้อขายหรือจัดซื้อ ข้อมูลนี้ช่วยให้เข้าใจบริบททางธุรกิจของวงจรชีวิตสัญญา. ข้อมูลนี้เป็นมิติสำคัญสำหรับการเปรียบเทียบ ผู้วิเคราะห์สามารถกรองแผนผังกระบวนการและ KPI เพื่อดูว่าสัญญาแต่ละประเภทมีลำดับการทำงาน ระยะเวลาดำเนินการ หรืออัตราการแก้ไขงานซ้ำแตกต่างกันหรือไม่ ตัวอย่างเช่น อาจพบว่า MSA ใช้เวลาตรวจสอบทางกฎหมายนานกว่า NDA มาก ซึ่งอาจนำไปสู่การปรับกระบวนการสำหรับข้อตกลงที่ซับซ้อนกว่า. เหตุผลที่สำคัญ ช่วยแบ่งกลุ่มและเปรียบเทียบกระบวนการ เพื่อให้เห็นว่าประเภทสัญญาที่ต่างกันส่งผลต่อระยะเวลาดำเนินการ ความซับซ้อน และความเสี่ยงอย่างไร. แหล่งข้อมูล เป็นช่องมาตรฐานในระเบียนสัญญาหลักของระบบ CLM. ตัวอย่าง ข้อตกลงไม่เปิดเผยข้อมูล (NDA)ข้อตกลงการให้บริการหลัก (MSA)ขอบเขตงาน (SOW) | |||
| แผนก Department | หน่วยธุรกิจหรือแผนกภายในที่เป็นเจ้าของสัญญา เช่น ฝ่ายขาย ฝ่ายกฎหมาย หรือฝ่ายจัดซื้อ. | ||
| คำอธิบาย ข้อมูลแผนกระบุทีมภายในหรือหน่วยธุรกิจที่รับผิดชอบหรือเกี่ยวข้องกับสัญญา โดยทั่วไปคือแผนกของเจ้าของสัญญาหรือทีมที่เริ่มส่งคำขอสัญญา. ข้อมูลนี้เป็นมิติสำคัญสำหรับการเปรียบเทียบผลการทำงานภายในและวิเคราะห์ภาระงาน ช่วยให้เข้าใจว่ากระบวนการจัดการสัญญาแตกต่างกันอย่างไรในแต่ละส่วนขององค์กร คุณสามารถกรองแดชบอร์ด 'ภาระงานและผลิตภาพของทีม' ตามแผนก เพื่อเปรียบเทียบผลการทำงาน ระบุความต้องการด้านทรัพยากร และดูว่าแผนกใดอาจต้องการการฝึกอบรมหรือการสนับสนุนกระบวนการเพิ่มเติม ข้อมูลนี้ช่วยตอบคำถาม เช่น 'แผนกใดใช้เวลาอนุมัตินานที่สุด' หรือ 'กระบวนการของฝ่ายขายต่างจากฝ่ายจัดซื้ออย่างไร'. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพของกระบวนการระหว่างหน่วยธุรกิจต่างๆ เพื่อระบุคอขวดภายในและแลกเปลี่ยนแนวทางปฏิบัติที่ดี. แหล่งข้อมูล โดยทั่วไปจะเชื่อมโยงกับโปรไฟล์ผู้ใช้ของเจ้าของสัญญา หรือระบุไว้ในช่องของระเบียนสัญญาโดยตรง. ตัวอย่าง ฝ่ายขายฝ่ายกฎหมายฝ่ายจัดซื้อฝ่ายไอที | |||
| มูลค่าสัญญา ContractValue | มูลค่าเงินรวมของสัญญา ซึ่งอาจเป็นรายได้ ค่าใช้จ่าย หรือภาระผูกพัน. | ||
| คำอธิบาย มูลค่าสัญญาแสดงความสำคัญทางการเงินของสัญญา เป็นข้อมูลบริบททางธุรกิจที่ช่วยจัดลำดับความสำคัญของสัญญาและทำความเข้าใจผลกระทบต่อองค์กร โดยทั่วไปจะแสดงในสกุลเงินที่กำหนด. ในการทำ process mining ข้อมูลนี้ใช้วิเคราะห์ผลกระทบทางธุรกิจจากประสิทธิภาพของกระบวนการ แดชบอร์ด 'ผลกระทบทางธุรกิจและปริมาณงาน' ใช้ข้อมูลนี้แสดงมูลค่าของสัญญาที่กำลังดำเนินการ ติดขัด หรือลงนามแล้ว ช่วยจัดลำดับความสำคัญของสัญญามูลค่าสูง และตอบคำถามได้ เช่น 'สัญญาที่มีมูลค่าสูงที่สุดของเราติดค้างอยู่ในขั้นตอนอนุมัติหรือไม่' หรือ 'สัญญาที่พ้นกำหนดต่ออายุมีมูลค่าเท่าใด'. เหตุผลที่สำคัญ แสดงผลกระทบทางการเงินของสัญญา ช่วยจัดลำดับความสำคัญและวิเคราะห์ว่าความไม่มีประสิทธิภาพของกระบวนการส่งผลต่อข้อตกลงมูลค่าสูงอย่างไร. แหล่งข้อมูล อยู่ในส่วนรายละเอียดทางการเงินของระเบียนสัญญาหลักในระบบ CLM หรือ ERP. ตัวอย่าง 100000.0025000.505000000.00 | |||
| เวลาสิ้นสุดเหตุการณ์ EventEndTime | วันและเวลาที่ระบุอย่างแม่นยำว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด. | ||
| คำอธิบาย เวลาสิ้นสุดเหตุการณ์ระบุว่ากิจกรรมเสร็จสิ้นเมื่อใด เมื่อนำมาใช้ร่วมกับเวลาเริ่มเหตุการณ์ จะคำนวณเวลาที่ใช้ในแต่ละขั้นตอนของวงจรชีวิตสัญญาได้อย่างแม่นยำ ข้อมูลที่ละเอียดระดับนี้จำเป็นต่อการวิเคราะห์ประสิทธิภาพอย่างละเอียด. ข้อมูลนี้ใช้คำนวณระยะเวลาของกิจกรรม ซึ่งเป็นพื้นฐานสำคัญในการวิเคราะห์คอขวด แดชบอร์ดอย่าง 'วิเคราะห์คอขวดในการอนุมัติและตรวจสอบ' ใช้ข้อมูลนี้ชี้ให้เห็นขั้นตอนที่ทำให้สัญญาล่าช้า เมื่อทราบระยะเวลาของแต่ละกิจกรรม องค์กรจะมุ่งปรับปรุงส่วนที่ใช้เวลามากที่สุดได้ เช่น การตรวจสอบทางกฎหมายหรือการเจรจา. เหตุผลที่สำคัญ ช่วยคำนวณระยะเวลาของแต่ละกิจกรรม ซึ่งจำเป็นต่อการระบุตำแหน่งที่เกิดคอขวดในกระบวนการอย่างแม่นยำ. แหล่งข้อมูล ดูได้จากบันทึกการตรวจสอบของระบบหรือตารางประวัติเหตุการณ์ หากไม่มีการบันทึกเวลาไว้โดยตรง อาจคำนวณจากเวลาเริ่มต้นของเหตุการณ์ถัดไป. ตัวอย่าง 2023-03-15T17:30:00Z2023-05-22T10:15:45Z2023-06-01T11:55:10Z | |||
| สถานะสัญญา ContractStatus | ขั้นตอนหรือสถานะปัจจุบันของสัญญา เช่น 'Draft', 'In Approval', 'Executed' หรือ 'Expired'. | ||
| คำอธิบาย สถานะสัญญาแสดงภาพรวมว่าสัญญาอยู่ในขั้นตอนใดของวงจรชีวิต ณ เวลาหนึ่ง โดยมักมีการอัปเดตเมื่อสัญญาผ่านหมุดหมายสำคัญ และช่วยสรุปความคืบหน้าของสัญญาในภาพรวม. ข้อมูลนี้มีประโยชน์ในการกรองกรณีเพื่อวิเคราะห์ส่วนต่างๆ ของกลุ่มสัญญาโดยเฉพาะ ตัวอย่างเช่น ผู้วิเคราะห์อาจเลือกดูสัญญา 'Active' เพื่อจัดการภาระผูกพัน หรือสัญญา 'Stalled' เพื่อหาสาเหตุของความล่าช้า ข้อมูลนี้เป็นองค์ประกอบสำคัญของแดชบอร์ด 'ประสิทธิภาพวงจรชีวิตสัญญา' ซึ่งแสดงจำนวนสัญญาในแต่ละขั้นตอนและใช้วัด KPI 'อัตราสัญญาที่หยุดชะงัก'. เหตุผลที่สำคัญ แสดงขั้นตอนปัจจุบันของสัญญาในภาพรวม ช่วยกรองและวิเคราะห์กลุ่มสัญญาตามช่วงของวงจรชีวิต. แหล่งข้อมูล เป็นช่องสถานะหลักในระเบียนสัญญาหลักของระบบ CLM. ตัวอย่าง ร่างอยู่ระหว่างตรวจสอบลงนามแล้วยุติแล้ว | |||
| จำนวนครั้งที่แก้ไข RevisionCount | จำนวนครั้งที่แก้ไขหรือแสดงการเปลี่ยนแปลงในเอกสารสัญญาระหว่างการเจรจาและการตรวจสอบ. | ||
| คำอธิบาย จำนวนครั้งที่แก้ไขใช้ติดตามปริมาณงานที่ต้องทำซ้ำก่อนลงนามในสัญญา ทุกครั้งที่แก้ไขเอกสารและสร้างเวอร์ชันใหม่ ควรเพิ่มจำนวนนี้ ข้อมูลนี้ใช้บ่งชี้ความซับซ้อนและความเห็นต่างในการเจรจา. ข้อมูลนี้ใช้วัดประสิทธิภาพโดยตรงและคำนวณ KPI 'อัตราการแก้ไขสัญญาซ้ำ' แดชบอร์ด 'ประสิทธิภาพการเจรจาและการแก้ไขงานซ้ำ' ใช้ข้อมูลนี้ระบุสัญญา คู่สัญญา หรือประเภทสัญญาที่ต้องแก้ไขหลายครั้งเกินไป จำนวนครั้งที่แก้ไขสูงมักสัมพันธ์กับระยะเวลาดำเนินการที่นานขึ้น และอาจบ่งชี้ว่าข้อกำหนดไม่ชัดเจน มีการเจรจาต่อรองอย่างเข้มข้น หรือควรปรับปรุงแม่แบบมาตรฐาน. เหตุผลที่สำคัญ ใช้วัดปริมาณงานที่ต้องแก้ไขซ้ำและความซับซ้อนในการเจรจา ช่วยระบุสาเหตุของความไม่มีประสิทธิภาพและระยะเวลาดำเนินการที่ยาวนาน. แหล่งข้อมูล ดึงข้อมูลได้จากช่องหมายเลขเวอร์ชันของเอกสารสัญญา หรือคำนวณจากจำนวนกิจกรรม 'แก้ไขสัญญา' ในแต่ละกรณี. ตัวอย่าง 135 | |||
| วันหมดอายุ ExpirationDate | วันที่สัญญาจะหมดอายุ หากไม่มีการต่ออายุหรือยุติสัญญาก่อนกำหนด. | ||
| คำอธิบาย วันหมดอายุเป็นข้อมูลวันที่สำคัญที่ระบุวันสิ้นสุดระยะเวลาของสัญญา ใช้กำหนดวงจรชีวิตของสัญญาที่ยังมีผล และเป็นจุดเริ่มต้นหลักของการต่ออายุหรือยุติสัญญา การจัดการวันหมดอายุให้เหมาะสมช่วยป้องกันไม่ให้บริการหรือรายได้ขาดช่วงโดยไม่ตั้งใจ. ในการทำ process mining ข้อมูลนี้จำเป็นต่อแดชบอร์ด 'การจัดการภาระผูกพันและการต่ออายุ' โดยใช้คำนวณ KPI 'อัตราการต่ออายุตรงเวลา' ด้วยการเปรียบเทียบวันที่ดำเนินการต่ออายุกับวันหมดอายุ การวิเคราะห์สัญญาที่ใกล้หมดอายุช่วยให้องค์กรจัดการแผนการต่ออายุล่วงหน้า และป้องกันรายได้รั่วไหลหรือการหยุดชะงักของการปฏิบัติงาน. เหตุผลที่สำคัญ ข้อมูลวันที่นี้สำคัญต่อการจัดการต่ออายุและลดความเสี่ยง ช่วยติดตามหมุดหมายของสัญญาและดำเนินการได้ทันเวลา. แหล่งข้อมูล เป็นช่องวันที่สำคัญในระเบียนสัญญาหลักของระบบ CLM. ตัวอย่าง 2024-12-312025-06-302026-01-15 | |||
กิจกรรมการจัดการสัญญา
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| ต่ออายุสัญญาแล้ว | แสดงว่าสัญญาได้รับการต่ออายุเมื่อครบกำหนด ซึ่งเป็นผลลัพธ์ทางธุรกิจที่สำคัญและทำให้สัญญามีผลต่อไป. | ||
| เหตุผลที่สำคัญ อัตราการต่ออายุเป็นตัวชี้วัดโดยตรงของการรักษาลูกค้าและความพึงพอใจ การติดตามเหตุการณ์นี้ช่วยให้เข้าใจความสำเร็จทางธุรกิจในระยะยาวและความต่อเนื่องของรายได้. แหล่งข้อมูล โดยทั่วไปเหตุการณ์นี้เกิดจากผู้ใช้ดำเนินการโดยตรงเพื่อเปลี่ยนสถานะสัญญา หรือสร้างระเบียนสัญญาใหม่สำหรับระยะเวลาที่ต่ออายุ ซึ่งจะใช้แทนสัญญาเดิม. บันทึก ตรวจหาการเปลี่ยนสถานะเป็น 'Renewed' หรือการสร้างสัญญาใหม่ที่เชื่อมโยงกับสัญญาเดิมในฐานะการต่ออายุ. ประเภทเหตุการณ์ explicit | |||
| ยุติสัญญา | แสดงว่าสัญญาที่ยังมีผลถูกยุติก่อนวันหมดอายุตามกำหนด อาจยุติเพราะมีเหตุหรือเพื่อความสะดวก ตามที่ข้อกำหนดในสัญญาอนุญาต. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้แสดงว่าความสัมพันธ์ทางธุรกิจสิ้นสุดลงก่อนกำหนด การทำความเข้าใจความถี่และสาเหตุของการยุติสัญญาสำคัญต่อการบริหารความเสี่ยงและประเมินสถานะธุรกิจ. แหล่งข้อมูล โดยทั่วไปผู้ใช้จะบันทึกเหตุการณ์นี้โดยเปลี่ยนสถานะสัญญาเป็น 'Terminated' พร้อมระบุรหัสเหตุผลหรือหมายเหตุ. บันทึก บันทึกเวลาที่สถานะของสัญญาที่ยังมีผลเปลี่ยนเป็น 'Terminated'. ประเภทเหตุการณ์ explicit | |||
| เริ่มคำขอจัดทำสัญญา | กิจกรรมแรกในวงจรชีวิตสัญญา คือการยื่นคำขออย่างเป็นทางการเพื่อจัดทำสัญญาใหม่ โดยทั่วไปบันทึกเป็นการสร้างระเบียนสัญญาหรือพื้นที่ทำงานใหม่ในระบบ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นจุดเริ่มต้นอย่างเป็นทางการของกระบวนการ และเวลาที่บันทึกไว้จำเป็นต่อการคำนวณระยะเวลาดำเนินการสัญญาทั้งหมด การวิเคราะห์จำนวนคำขอช่วยวางแผนทรัพยากรและจัดการปริมาณงานได้. แหล่งข้อมูล โดยทั่วไป เหตุการณ์นี้บันทึกจากเวลาที่สร้างระเบียนหรือออบเจ็กต์สัญญาหลักในตารางสัญญาหลักหรือบันทึกการตรวจสอบของระบบต้นทาง. บันทึก ระบุเหตุการณ์การสร้างหรือเวลาที่เก่าที่สุดซึ่งเชื่อมโยงกับ Contract ID ที่ไม่ซ้ำกัน. ประเภทเหตุการณ์ explicit | |||
| ลงนามสัญญาเสร็จ | นี่คือหมุดหมายสำคัญที่ทุกฝ่ายลงนามในสัญญาแล้ว ทำให้สัญญามีผลผูกพันตามกฎหมาย และแสดงว่าขั้นตอนก่อนลงนามในวงจรชีวิตสัญญาเสร็จสมบูรณ์. | ||
| เหตุผลที่สำคัญ วันที่ลงนามเสร็จเป็นผลลัพธ์ความสำเร็จหลักที่จำเป็นต่อการคำนวณระยะเวลารวมตั้งแต่ยื่นคำขอจนถึงลงนาม และเป็นเหตุการณ์สำคัญสำหรับวิเคราะห์ผลการดำเนินงานและปริมาณงานที่เสร็จสิ้น. แหล่งข้อมูล โดยทั่วไปบันทึกข้อมูลนี้โดยตรงผ่านการเชื่อมต่อกับแพลตฟอร์มลงนามอิเล็กทรอนิกส์ หรือเมื่อผู้ใช้เปลี่ยนสถานะเป็น 'Executed' ด้วยตนเองและระบุวันที่ลงนามเสร็จ. บันทึก ใช้เวลาที่การลงนามเสร็จสิ้นจากระบบลงนามอิเล็กทรอนิกส์ หรือวันที่เปลี่ยนสถานะเป็น 'Executed' ด้วยตนเอง. ประเภทเหตุการณ์ explicit | |||
| ส่งสัญญาเพื่อลงนาม | กิจกรรมนี้ระบุเวลาที่ส่งสัญญาฉบับสุดท้ายซึ่งได้รับอนุมัติแล้วให้ทุกฝ่ายลงนาม แสดงว่าการเจรจาทั้งหมดสิ้นสุดลงและเริ่มขั้นตอนการลงนามขั้นสุดท้าย. | ||
| เหตุผลที่สำคัญ นี่คือหมุดหมายสำคัญที่เริ่มนับระยะเวลารอบการลงนามขั้นสุดท้าย การวิเคราะห์เวลาตั้งแต่จุดนี้จนถึงการลงนามเสร็จช่วยให้เห็นความล่าช้าในขั้นตอนการลงนาม. แหล่งข้อมูล ในระบบที่เชื่อมต่อกับบริการลงนามอิเล็กทรอนิกส์ มักบันทึกเป็นการดำเนินการโดยตรงที่เริ่มขั้นตอนลงนามและปรากฏในบันทึกการตรวจสอบของระบบ. บันทึก ค้นหาเวลาของเหตุการณ์ในบันทึกเหตุการณ์หรือการเรียก API ที่เกี่ยวข้องกับการเริ่มเวิร์กโฟลว์ลงนามอิเล็กทรอนิกส์. ประเภทเหตุการณ์ explicit | |||
| สัญญาเริ่มมีผล | หมายถึงเวลาที่สัญญาเริ่มมีผลและบังคับใช้ได้ ซึ่งอาจเกิดขึ้นในวันเดียวกับหรือหลังวันลงนามเสร็จ เหตุการณ์นี้เป็นจุดเริ่มต้นของการจัดการภาระผูกพันและติดตามผลการดำเนินงาน. | ||
| เหตุผลที่สำคัญ การเริ่มมีผลของสัญญาเป็นจุดเปลี่ยนจากกระบวนการทำสัญญาไปสู่กระบวนการจัดการสัญญา และเป็นวันเริ่มต้นที่แท้จริงสำหรับติดตามการปฏิบัติตามข้อกำหนด การต่ออายุ และภาระผูกพัน. แหล่งข้อมูล โดยทั่วไประบบจะบันทึกเหตุการณ์นี้เป็นการเปลี่ยนสถานะจาก 'Executed' เป็น 'Active' หรือ 'Live' และบางครั้งจะระบุวันที่มีผลบังคับใช้ไว้ในช่อง 'Effective Date'. บันทึก ใช้เวลาที่สถานะเปลี่ยนเป็น 'Active' หรือใช้วันที่มีผลบังคับใช้ของสัญญา หากมีข้อมูล. ประเภทเหตุการณ์ inferred | |||
| สัญญาหมดอายุ | เหตุการณ์นี้แสดงว่าสัญญาถึงวันสิ้นสุดโดยไม่มีการต่ออายุหรือยุติก่อนกำหนด เป็นการสิ้นสุดตามแผนและเป็นไปตามวงจรชีวิตของสัญญา. | ||
| เหตุผลที่สำคัญ การติดตามวันหมดอายุสำคัญต่อการจัดการต่ออายุและป้องกันไม่ให้บริการหรือข้อตกลงสิ้นสุดลงโดยไม่ตั้งใจ หากสัญญาหมดอายุโดยไม่ได้ต่ออายุเป็นจำนวนมาก อาจเป็นสัญญาณว่าธุรกิจสูญเสียลูกค้า. แหล่งข้อมูล โดยทั่วไประบบไม่ได้บันทึกเหตุการณ์นี้โดยตรง แต่คำนวณจากการเปรียบเทียบช่องวันหมดอายุของสัญญากับวันที่ปัจจุบัน. บันทึก สร้างเหตุการณ์นี้โดยบันทึกเวลาเมื่อวันที่ของระบบมากกว่าหรือเท่ากับวันที่ในช่อง 'Expiration Date' ของระเบียนสัญญา. ประเภทเหตุการณ์ calculated | |||
| อนุมัติภายในเสร็จ | หมุดหมายนี้ระบุว่าผู้มีส่วนเกี่ยวข้องภายในทุกคนที่จำเป็นอนุมัติสัญญาฉบับสุดท้ายแล้ว แสดงว่าองค์กรมีความเห็นตรงกันและพร้อมส่งสัญญาให้คู่สัญญาภายนอก. | ||
| เหตุผลที่สำคัญ นี่คือจุดอนุมัติสำคัญที่แสดงว่าการเจรจาภายในสิ้นสุดลงแล้ว เวลาที่ใช้กว่าจะถึงขั้นตอนนี้เป็นตัวชี้วัดประสิทธิภาพภายในที่สำคัญ. แหล่งข้อมูล โดยทั่วไปอนุมานได้เมื่อสถานะสัญญาเปลี่ยนเป็นสถานะอนุมัติขั้นสุดท้าย เช่น 'Fully Approved' หรือ 'Ready for Signature' หรือเมื่องานอนุมัติรายการสุดท้ายเสร็จสิ้น. บันทึก ระบุเวลาที่สถานะอนุมัติโดยรวมเปลี่ยนเป็นเสร็จสมบูรณ์ หรือเวลาที่บันทึกการอนุมัติรายการสุดท้ายที่จำเป็น. ประเภทเหตุการณ์ inferred | |||
| แก้ไขสัญญา | หมายถึงกรณีที่แก้ไขหรือทำเครื่องหมายแก้ไขในเอกสารสัญญาระหว่างการเจรจาหรือการตรวจสอบภายใน การแก้ไขแต่ละครั้งจะสร้างเอกสารเวอร์ชันใหม่. | ||
| เหตุผลที่สำคัญ ความถี่ในการแก้ไขหรืออัตราการทำงานซ้ำเป็นตัวชี้วัดสำคัญของประสิทธิภาพกระบวนการและความซับซ้อนของสัญญา อัตราการทำงานซ้ำที่สูงอาจบ่งชี้ถึงปัญหาในร่างฉบับแรกหรือกลยุทธ์การเจรจา. แหล่งข้อมูล โดยทั่วไปบันทึกเหตุการณ์นี้โดยตรงทุกครั้งที่อัปโหลดหรือบันทึกเอกสารสัญญาหลักเวอร์ชันใหม่ลงในคลังเอกสารของระบบ. บันทึก บันทึกเวลาที่อัปโหลดเอกสารเวอร์ชันใหม่แต่ละรายการหลังจากร่างฉบับแรก. ประเภทเหตุการณ์ explicit | |||
| ตรวจสอบทางกฎหมายเสร็จ | ระบุว่าฝ่ายกฎหมายตรวจสอบสัญญาเสร็จแล้ว นี่คือจุดตรวจสอบสำคัญก่อนส่งสัญญาไปขออนุมัติในวงกว้างหรือเจรจากับคู่สัญญาภายนอก. | ||
| เหตุผลที่สำคัญ การวัดระยะเวลาตรวจสอบทางกฎหมายช่วยประเมินภาระงานของทีมกฎหมายและค้นหาโอกาสปรับปรุงกระบวนการทางกฎหมาย ขั้นตอนนี้มักเป็นปัจจัยสำคัญที่ทำให้ระยะเวลาดำเนินการโดยรวมยาวนานขึ้น. แหล่งข้อมูล มักบันทึกเมื่อทีมกฎหมายเปลี่ยนสถานะสัญญา เช่น เป็น 'Legal Approved' หรือทำงานอนุมัติเฉพาะในบันทึกเวิร์กโฟลว์ของระบบเสร็จสิ้น. บันทึก ค้นหาเวลาที่งานซึ่งมอบหมายให้ฝ่ายกฎหมายเสร็จสิ้น หรือเวลาที่สถานะเปลี่ยนเพื่อระบุว่าได้รับอนุมัติทางกฎหมายแล้ว. ประเภทเหตุการณ์ explicit | |||
| ถอนคำขอสัญญา | แสดงว่ามีการยกเลิกคำขอสัญญาหรือสัญญาที่อยู่ระหว่างดำเนินการโดยตั้งใจก่อนลงนาม สถานะนี้เป็นจุดสิ้นสุดที่ทำให้กระบวนการหยุดลง. | ||
| เหตุผลที่สำคัญ การวิเคราะห์สาเหตุที่ถอนสัญญาอาจช่วยให้พบปัญหาในขั้นตอนคัดกรองหรือการเปลี่ยนแปลงลำดับความสำคัญทางธุรกิจ จึงควรติดตามผลลัพธ์ด้านลบนี้. แหล่งข้อมูล เหตุการณ์นี้เป็นสถานะสิ้นสุดที่ระบุชัดเจน โดยทั่วไปเกิดเมื่อผู้ใช้เปลี่ยนสถานะสัญญาเป็น 'Canceled' หรือ 'Withdrawn' ในบันทึกประวัติสถานะของระบบ. บันทึก บันทึกเวลาที่สถานะสัญญาเปลี่ยนเป็นสถานะสิ้นสุด 'Canceled' หรือ 'Withdrawn'. ประเภทเหตุการณ์ explicit | |||
| ร่างสัญญาเสร็จ | หมายถึงการจัดทำร่างสัญญาฉบับแรกเสร็จสิ้น โดยมักบันทึกเมื่ออัปโหลดหรือสร้างเอกสารสัญญาฉบับแรกและเชื่อมโยงกับระเบียนสัญญา. | ||
| เหตุผลที่สำคัญ การติดตามเวลาตั้งแต่ยื่นคำขอจนถึงจัดทำร่างเสร็จ ช่วยให้เห็นประสิทธิภาพของการตั้งต้นและการจัดทำเอกสาร ความล่าช้าในขั้นตอนนี้อาจเป็นสัญญาณเริ่มต้นของคอขวดในกระบวนการ. แหล่งข้อมูล โดยทั่วไปพบข้อมูลนี้ในบันทึกการจัดการเอกสารหรือไฟล์แนบที่เชื่อมโยงกับระเบียนสัญญา หรืออาจอนุมานจากการเปลี่ยนสถานะ เช่น 'Drafting Complete'. บันทึก ใช้เวลาที่อัปโหลดเอกสารเวอร์ชันแรกหรือเวลาที่สถานะเปลี่ยนเป็น 'Drafted'. ประเภทเหตุการณ์ inferred | |||
| เริ่มเจรจา | ระบุว่าเริ่มเจรจาโต้ตอบกับคู่สัญญาแล้ว โดยมักบันทึกจากการตอบกลับครั้งแรกหรือเอกสารที่คู่สัญญาภายนอกส่งกลับมาพร้อมทำเครื่องหมายแก้ไข. | ||
| เหตุผลที่สำคัญ การติดตามจุดเริ่มต้นของการเจรจามีความสำคัญต่อการวิเคราะห์ระยะเวลารอบการเจรจาและทำความเข้าใจว่าคู่สัญญาใช้เวลาตอบกลับนานเท่าใด. แหล่งข้อมูล มักอนุมานจากการที่คู่สัญญาภายนอกอัปโหลดเอกสารเวอร์ชันใหม่ หรือสถานะสัญญาเปลี่ยนเพื่อระบุว่าเริ่มเจรจาแล้ว. บันทึก ใช้เวลาที่ได้รับเอกสารฉบับแรกจากคู่สัญญา หรือเวลาที่สถานะเปลี่ยนเป็น 'In Negotiation'. ประเภทเหตุการณ์ inferred | |||
| เริ่มดำเนินการแก้ไขสัญญา | เหตุการณ์นี้เป็นจุดเริ่มต้นของกระบวนการแก้ไขสัญญาที่มีผลอยู่ โดยแสดงว่ามีคำขอเปลี่ยนแปลงข้อกำหนดเดิมของสัญญา. | ||
| เหตุผลที่สำคัญ หากมีการแก้ไขสัญญาบ่อยครั้ง อาจหมายความว่าสัญญาเดิมระบุรายละเอียดไม่เพียงพอ การวิเคราะห์การแก้ไขช่วยให้เห็นว่าความสัมพันธ์ทางธุรกิจเปลี่ยนแปลงไปอย่างไร. แหล่งข้อมูล โดยทั่วไประบบบันทึกเหตุการณ์นี้เมื่อสร้างระเบียนหรือพื้นที่ทำงาน 'Amendment' ใหม่ที่เชื่อมโยงกับสัญญาต้นฉบับ ซึ่งมักพบในตารางข้อมูลหลักของระบบ. บันทึก ระบุเหตุการณ์สร้างระเบียนประเภท 'Amendment' ที่เชื่อมโยงกับ Contract ID ของสัญญาหลัก. ประเภทเหตุการณ์ explicit | |||
| เริ่มตรวจสอบภายใน | กิจกรรมนี้ระบุเวลาที่ส่งร่างสัญญาให้ผู้มีส่วนเกี่ยวข้องภายในตรวจสอบและให้ข้อเสนอแนะอย่างเป็นทางการ เป็นจุดเริ่มต้นของการทำงานร่วมกันและการอนุมัติภายใน. | ||
| เหตุผลที่สำคัญ นี่คือจุดเริ่มต้นสำหรับวัดระยะเวลารอบการตรวจสอบภายในทั้งหมด การวิเคราะห์เวลาที่ใช้ในขั้นตอนนี้ช่วยระบุคอขวดในการหาข้อสรุปร่วมกันระหว่างผู้มีส่วนเกี่ยวข้อง. แหล่งข้อมูล โดยทั่วไปบันทึกจากการเปลี่ยนสถานะในเวิร์กโฟลว์ เช่น จาก 'Draft' เป็น 'Internal Review' หรือจากการสร้างงานตรวจสอบ. บันทึก บันทึกเวลาที่สถานะสัญญาเปลี่ยนเป็น 'In Review' หรือเวลาที่มอบหมายงานตรวจสอบรายการแรก. ประเภทเหตุการณ์ explicit | |||
| เริ่มติดตามภาระผูกพัน | กิจกรรมนี้เป็นจุดเริ่มต้นของการจัดการหลังลงนาม โดยเริ่มติดตามวันสำคัญ สิ่งที่ต้องส่งมอบ และข้อผูกพันอื่นๆ อย่างต่อเนื่อง นับเป็นขั้นตอนแรกในการดูแลให้เป็นไปตามข้อกำหนดหลังได้รับสัญญา. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการทำความเข้าใจการกำกับดูแลหลังลงนาม การติดตามงานเหล่านี้ช่วยให้องค์กรได้รับประโยชน์ตามที่คาดหวังจากสัญญาและลดความเสี่ยงได้. แหล่งข้อมูล บันทึกเหตุการณ์นี้เมื่อมีการสร้างหรือเริ่มงาน รายการตรวจสอบ หรือกระบวนการย่อยเพื่อติดตามภาระผูกพันตามสัญญา โดยมักพบข้อมูลในบันทึกการจัดการงาน. บันทึก บันทึกเวลาที่สร้างงานหรือเหตุการณ์ที่เกี่ยวข้องกับการติดตามภาระผูกพันหรือการปฏิบัติตามข้อกำหนดของสัญญาที่ยังมีผลอยู่. ประเภทเหตุการณ์ explicit | |||
| ส่งสัญญาให้คู่สัญญา | กิจกรรมนี้ระบุเวลาที่ส่งสัญญาให้คู่สัญญาภายนอกตรวจสอบและเจรจา เป็นจุดเปลี่ยนจากกระบวนการภายในไปสู่การติดต่อกับภายนอก. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้เป็นจุดเริ่มต้นสำหรับวัดรอบการเจรจากับคู่สัญญาภายนอก หากส่งสัญญาล่าช้า วงจรการทำข้อตกลงทั้งหมดก็อาจยืดเยื้อ. แหล่งข้อมูล อาจบันทึกจากการดำเนินการของผู้ใช้โดยตรง เช่น 'Send for Negotiation' หรืออนุมานจากการเปลี่ยนสถานะเป็น 'In Negotiation' หรือ 'External Review'. บันทึก บันทึกเวลาของเหตุการณ์ 'Send to Counterparty' หรือเวลาที่สถานะเปลี่ยนเป็นสถานะตรวจสอบโดยคู่สัญญาภายนอก. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เลือกคู่มือสำหรับระบบที่คุณใช้จากตัวเลือกด้านล่างเพื่อเริ่มดึงข้อมูล หรือใช้เทมเพลตทั่วไปนี้เป็นแนวทางสำหรับจัดทำบันทึกเหตุการณ์.
เริ่มปรับปรุงการจัดการสัญญาวันนี้
ค้นหาคอขวด ลดความเสี่ยง และเร่งการทำข้อตกลงให้เสร็จเร็วขึ้น เพื่อให้เห็นผลได้ไว.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จในไม่กี่นาที