เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ
เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ จัดซื้อจนถึงชำระเงิน: ใบขอซื้อ หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- ฟิลด์ข้อมูลมาตรฐานเพื่อให้วิเคราะห์ข้อมูลจากระบบต่างๆ ได้อย่างสอดคล้องกัน.
- รายการกิจกรรมสำคัญที่ควรติดตาม เพื่อให้เห็นภาพกระบวนการได้ครบถ้วน.
- โครงสร้างพื้นฐานที่ยืดหยุ่นและปรับให้เข้ากับเวิร์กโฟลว์ใบขอซื้อขององค์กรคุณได้.
แอตทริบิวต์ของกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ID คำขอซื้อ PurchaseRequisitionId | รหัสเฉพาะของคำขอซื้อแต่ละรายการ ใช้เป็นรหัสเคสหลักของกระบวนการ. | ||
| คำอธิบาย ID คำขอซื้อเป็นรหัสเฉพาะที่กำหนดให้กับเอกสารคำขอซื้อแต่ละฉบับเมื่อสร้างขึ้น รหัสนี้ใช้เป็นจุดอ้างอิงหลักสำหรับกิจกรรม การเปลี่ยนแปลง และการอนุมัติทั้งหมดของคำขอเดียว ตั้งแต่เริ่มต้นจนเสร็จสิ้น. ใน process mining รหัสนี้จำเป็นต่อการเชื่อมโยงเคส ช่วยให้ระบบสร้างลำดับการดำเนินงานของคำขอซื้อแต่ละรายการตั้งแต่ต้นจนจบ โดยเชื่อมเหตุการณ์ที่แยกจากกัน เช่น 'สร้างคำขอซื้อ' 'อนุมัติขั้นตอน' และ 'สร้างใบสั่งซื้อ' ให้เป็นกระบวนการเดียวกัน หากไม่มีรหัสเคสที่สม่ำเสมอและไม่ซ้ำกัน ก็จะวิเคราะห์รูปแบบกระบวนการ รอบเวลา และผลลัพธ์ไม่ได้. เหตุผลที่สำคัญ นี่คือรหัสสำคัญที่ใช้ติดตามคำขอซื้อตลอดวงจร และเชื่อมเหตุการณ์ที่เกี่ยวข้องทั้งหมดให้เป็นกระบวนการเดียวกัน. แหล่งข้อมูล โดยทั่วไปพบในข้อมูลส่วนหัวของธุรกรรมคำขอซื้อหรือตารางเอกสาร. ตัวอย่าง PR-100567REQ00043218000123987 | |||
| ชื่อกิจกรรม ActivityName | ชื่อกิจกรรมทางธุรกิจหรือเหตุการณ์ที่เกิดขึ้นกับคำขอซื้อ ณ เวลาหนึ่ง. | ||
| คำอธิบาย ชื่อกิจกรรมใช้ระบุขั้นตอนหรือการเปลี่ยนสถานะหนึ่งรายการในวงจรคำขอซื้อ โดยเป็นป้ายชื่อที่อ่านเข้าใจง่ายสำหรับเหตุการณ์ เช่น 'ส่งคำขอซื้อแล้ว' 'เริ่มขั้นตอนอนุมัติแล้ว' หรือ 'ปฏิเสธคำขอซื้อแล้ว' ซึ่งเป็นองค์ประกอบพื้นฐานของแผนผังกระบวนการ. แอตทริบิวต์นี้เป็นพื้นฐานสำคัญของการค้นพบและวิเคราะห์กระบวนการ เมื่อนำกิจกรรมมาเรียงตามลำดับ เครื่องมือ process mining จะแสดงภาพกระบวนการที่เกิดขึ้นจริง ช่วยระบุจุดที่ต่างจากขั้นตอนมาตรฐาน รวมถึงคอขวดและการทำงานซ้ำ การตั้งชื่อกิจกรรมให้สม่ำเสมอและสื่อความหมายช่วยให้สร้างแบบจำลองกระบวนการที่เข้าใจง่ายและนำไปใช้ปรับปรุงได้. เหตุผลที่สำคัญ ข้อมูลนี้ระบุขั้นตอนแต่ละรายการของกระบวนการ ซึ่งจำเป็นต่อการแสดงแผนผังกระบวนการและวิเคราะห์ลำดับการทำงาน. แหล่งข้อมูล มักได้มาจากบันทึกเหตุการณ์ ตารางเปลี่ยนสถานะ หรือรหัสธุรกรรมที่เกี่ยวข้องกับเอกสารคำขอซื้อ. ตัวอย่าง สร้างคำขอซื้ออนุมัติขั้นตอนสร้างใบสั่งซื้อแล้ว | |||
| เวลาเกิดเหตุการณ์ EventTime | วันที่และเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ ใช้เป็นเวลาหลักในการเรียงลำดับเหตุการณ์. | ||
| คำอธิบาย เวลาเกิดเหตุการณ์ หรือที่มักเรียกว่า timestamp บันทึกเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ ข้อมูลนี้จำเป็นต่อการเรียงลำดับเหตุการณ์และการวิเคราะห์กระบวนการตามเวลา เช่น การคำนวณรอบเวลา การระบุคอขวด และการติดตามประสิทธิภาพ. ใน process mining จะใช้ timestamp เรียงกิจกรรมภายในแต่ละเคสและวัดระยะเวลาระหว่างขั้นตอน การวิเคราะห์ระยะเวลาเหล่านี้ช่วยให้เห็นความล่าช้า เข้าใจสาเหตุของรอบเวลาที่ยาวนาน และประเมินว่าการให้บริการเป็นไปตามข้อตกลงระดับบริการหรือไม่ ข้อมูล timestamp ที่ถูกต้องและครบถ้วนเป็นเงื่อนไขสำคัญของการวิเคราะห์ประสิทธิภาพที่มีความหมาย. เหตุผลที่สำคัญ เวลานี้จำเป็นต่อการเรียงลำดับเหตุการณ์ คำนวณรอบเวลา และวิเคราะห์ประสิทธิภาพกับคอขวดของกระบวนการ. แหล่งข้อมูล โดยทั่วไปบันทึกไว้ในบันทึกการตรวจสอบของระบบ บันทึกเหตุการณ์ หรือเป็นวันที่สร้างหรือวันที่เปลี่ยนแปลงในระเบียนธุรกรรม. ตัวอย่าง 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:45Z | |||
| ระบบต้นทาง SourceSystem | ระบุระบบสารสนเทศที่ดึงข้อมูลมา เช่น ERP หรือแพลตฟอร์มจัดซื้อ. | ||
| คำอธิบาย แอตทริบิวต์ระบบต้นทางระบุแหล่งที่มาของข้อมูลกระบวนการ ในองค์กรที่ใช้หลายระบบ เช่น ERP ส่วนกลางและเครื่องมือจัดซื้อทางอิเล็กทรอนิกส์เฉพาะทาง ฟิลด์นี้ช่วยแยกข้อมูลจากแต่ละแหล่ง. ข้อมูลนี้มีประโยชน์ต่อการตรวจสอบความถูกต้องของข้อมูล การแก้ไขปัญหา และการทำความเข้าใจความแตกต่างของกระบวนการที่อาจเกิดจากระบบ ตัวอย่างเช่น คำขอซื้อจากระบบหนึ่งอาจใช้เส้นทางอนุมัติต่างจากอีกระบบ หรือมีรอบเวลาสั้นกว่า การวิเคราะห์แยกตามระบบต้นทางช่วยให้เห็นปัญหาการเชื่อมต่อระบบหรือโอกาสในการรวมระบบ. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยให้ทราบที่มาของข้อมูล ซึ่งจำเป็นต่อการตรวจสอบความถูกต้องและวิเคราะห์ความแตกต่างของกระบวนการระหว่างหลายระบบ. แหล่งข้อมูล มักเป็นค่าคงที่ที่เพิ่มระหว่างการดึงข้อมูล หรืออยู่ในฟิลด์ข้อมูลเมตาทางเทคนิค. ตัวอย่าง SAP S/4HANAOracle FusionCoupa | |||
| อัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ระบุว่ามีการรีเฟรชหรือดึงข้อมูลของระเบียนนี้จากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย เวลาอัปเดตข้อมูลล่าสุดแสดงว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลใหม่เพียงใด โดยระบุเวลาที่ดึงระเบียนจากระบบต้นทางและโหลดเข้าสู่สภาพแวดล้อม process mining ครั้งล่าสุด. แอตทริบิวต์นี้จำเป็นต่อการติดตามการปฏิบัติการและช่วยให้มั่นใจว่าการวิเคราะห์อ้างอิงข้อมูลปัจจุบัน ผู้ใช้จึงเห็นความล่าช้าระหว่างเหตุการณ์จริงกับข้อมูลที่แสดงในแบบจำลองกระบวนการได้ แดชบอร์ดและ KPI ที่ติดตามการปฏิบัติการต่อเนื่องต้องอาศัยข้อมูลนี้เพื่อแสดงผลวิเคราะห์ที่ทันเวลาและเกี่ยวข้อง. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด ซึ่งสำคัญต่อการวิเคราะห์ให้ได้ผลที่เกี่ยวข้องและทันสมัย. แหล่งข้อมูล โดยทั่วไปเครื่องมือเชื่อมต่อข้อมูลหรือ ETL (Extract, Transform, Load) จะเพิ่มข้อมูลนี้ระหว่างโหลดข้อมูล. ตัวอย่าง 2024-05-20T02:00:00Z2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| ID ใบสั่งซื้อ PurchaseOrderId | รหัสของใบสั่งซื้อที่สร้างจากคำขอซื้อที่ได้รับอนุมัติแล้ว. | ||
| คำอธิบาย ID ใบสั่งซื้อคือหมายเลขเฉพาะของเอกสาร PO ที่สร้างจากคำขอซื้อที่ได้รับอนุมัติแล้ว ฟิลด์นี้เชื่อมกระบวนการขอซื้อกับกระบวนการจัดซื้อและชำระเงินในขั้นตอนถัดไป. แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์ประสิทธิภาพการแปลงคำขอซื้อเป็น PO โดยยืนยันว่าคำขอซื้อทำให้เกิดใบสั่งซื้อ และช่วยวัดเวลาที่ใช้ในการแปลงคำขอ การวิเคราะห์ว่าคำขอใดมี PO ที่เกี่ยวข้องช่วยให้องค์กรประเมินประสิทธิภาพของขั้นตอนก่อนจัดซื้อ และระบุคำขอที่ได้รับอนุมัติแต่ไม่ได้ดำเนินการต่อจนเสร็จ. เหตุผลที่สำคัญ เชื่อมคำขอซื้อกับกระบวนการจัดซื้อในขั้นตอนถัดไป ช่วยวิเคราะห์อัตราและระยะเวลาการแปลงคำขอซื้อเป็น PO. แหล่งข้อมูล มักพบในข้อมูลเอกสารคำขอซื้อหลังจากสร้าง PO แล้ว บางครั้งอยู่ในตารางเอกสารที่เกี่ยวข้องหรือลำดับเอกสาร. ตัวอย่าง PO-4500012345ORD7890016000054321 | |||
| ชื่อผู้ขอ RequesterName | ชื่อพนักงานหรือผู้ใช้ที่สร้างและส่งคำขอซื้อ. | ||
| คำอธิบาย ชื่อผู้ขอระบุบุคคลที่เริ่มคำขอซื้อ โดยทั่วไปคือผู้ใช้ทางธุรกิจที่ต้องการสินค้าหรือบริการ. การวิเคราะห์กระบวนการแยกตามผู้ขอช่วยให้เห็นรูปแบบที่เกี่ยวข้องกับบุคคลหรือกลุ่มต่างๆ ตัวอย่างเช่น อาจพบว่าผู้ขอบางรายส่งคำขอที่ข้อมูลไม่ครบหรือไม่เป็นไปตามข้อกำหนดบ่อยครั้ง จนต้องทำงานซ้ำ ข้อมูลนี้นำไปใช้จัดการฝึกอบรมให้ตรงจุด หรือปรับขั้นตอนขอซื้อให้ใช้ง่ายขึ้นสำหรับกลุ่มผู้ใช้ที่พบบ่อย ซึ่งช่วยเพิ่มประสิทธิภาพและการปฏิบัติตามข้อกำหนด. เหตุผลที่สำคัญ ช่วยให้เห็นพฤติกรรมของผู้ใช้แต่ละราย และจัดการฝึกอบรมหรือปรับปรุงกระบวนการให้เหมาะกับบุคคลหรือทีมได้. แหล่งข้อมูล พบในข้อมูลส่วนหัวของคำขอซื้อ โดยมักเชื่อมโยงกับข้อมูลหลักของพนักงาน. ตัวอย่าง John SmithJane DoeMaria Garcia | |||
| ประเภทคำขอซื้อ RequisitionType | หมวดหมู่หรือประเภทของคำขอซื้อ เช่น ขอสินค้า บริการ หรือค่าใช้จ่ายลงทุน. | ||
| คำอธิบาย ประเภทคำขอซื้อใช้จำแนกคำขอตามลักษณะหรือวัตถุประสงค์ ตัวอย่างเช่น ขอวัสดุทั่วไป บริการ ค่าใช้จ่ายลงทุน หรือสินค้าจากแค็ตตาล็อก การจำแนกนี้มักกำหนดเวิร์กโฟลว์อนุมัติและวิธีบันทึกบัญชี. การวิเคราะห์กระบวนการแยกตามประเภทคำขอช่วยให้เข้าใจว่าคำขอแต่ละประเภทใช้เส้นทางหรือมีประสิทธิภาพต่างกันหรือไม่ ตัวอย่างเช่น คำขอค่าใช้จ่ายลงทุนอาจมีรอบเวลานานกว่าเพราะต้องผ่านการอนุมัติเพิ่ม ส่วนคำขอสินค้าจากแค็ตตาล็อกทั่วไปอาจทำงานโดยอัตโนมัติได้มาก การวิเคราะห์นี้ช่วยออกแบบและปรับปรุงกระบวนการให้เหมาะกับคำขอแต่ละประเภท. เหตุผลที่สำคัญ ช่วยวิเคราะห์เส้นทางกระบวนการที่แตกต่างกันได้ เนื่องจากประเภทคำขอมักกำหนดเวิร์กโฟลว์อนุมัติและระดับความซับซ้อนที่ต้องใช้. แหล่งข้อมูล โดยทั่วไปจัดเก็บข้อมูลนี้เป็นรหัสประเภทเอกสารหรือรหัสหมวดหมู่ในข้อมูลส่วนหัวของคำขอซื้อ. ตัวอย่าง ค่าใช้จ่ายลงทุนค่าใช้จ่ายในการดำเนินงานคำขอบริการคำขอวัสดุ | |||
| แผนก Department | แผนกธุรกิจ ศูนย์ต้นทุน หรือหน่วยงานที่รับผิดชอบค่าใช้จ่ายของคำขอซื้อ. | ||
| คำอธิบาย แอตทริบิวต์แผนกระบุหน่วยงานที่รับผิดชอบการซื้อ เช่น 'การตลาด' 'ไอที' หรือ 'การเงิน' เป็นข้อมูลสำคัญด้านการเงินและองค์กรที่ใช้วางงบประมาณและจัดสรรค่าใช้จ่าย. ใน process mining การวิเคราะห์ข้อมูลแยกตามแผนกเป็นวิธีที่ใช้กันทั่วไป ช่วยเปรียบเทียบประสิทธิภาพระหว่างหน่วยธุรกิจ และระบุได้ว่าแผนกใดทำงานได้มีประสิทธิภาพหรือแผนกใดอาจต้องการความช่วยเหลือ การวิเคราะห์นี้ช่วยให้เห็นความแตกต่างด้านรอบเวลา อัตราการอนุมัติ หรือการปฏิบัติตามข้อกำหนด ซึ่งอาจเกี่ยวข้องกับรูปแบบการซื้อหรือขั้นตอนภายในของแต่ละแผนก. เหตุผลที่สำคัญ ช่วยเปรียบเทียบประสิทธิภาพและวิเคราะห์ค่าใช้จ่ายระหว่างหน่วยธุรกิจ พร้อมแสดงรูปแบบกระบวนการเฉพาะของแต่ละแผนก. แหล่งข้อมูล โดยทั่วไปมีอยู่ในข้อมูลส่วนหัวหรือรายการของคำขอซื้อ และเชื่อมโยงกับโครงสร้างองค์กร. ตัวอย่าง การตลาดเทคโนโลยีสารสนเทศการเงินการปฏิบัติการ | |||
| มูลค่าคำขอซื้อ RequisitionAmount | มูลค่ารวมของคำขอซื้อ. | ||
| คำอธิบาย มูลค่าคำขอซื้อคือมูลค่ารวมของสินค้าและบริการทั้งหมดที่ระบุในคำขอซื้อ เป็นตัวชี้วัดทางการเงินสำคัญที่ใช้ตลอดกระบวนการจัดซื้อ. ในการวิเคราะห์กระบวนการ แอตทริบิวต์นี้สำคัญต่อการกรองและวิเคราะห์ตามมูลค่า ช่วยแบ่งคำขอเป็นกลุ่ม เช่น มูลค่าสูงและมูลค่าต่ำ ซึ่งมักมีเวิร์กโฟลว์อนุมัติและระดับความเสี่ยงต่างกัน การวิเคราะห์รอบเวลาหรืออัตราการปฏิเสธตามมูลค่าคำขออาจเผยให้เห็นว่าคำขอมูลค่าสูงใช้เวลาอนุมัตินานกว่ามากหรือถูกปฏิเสธบ่อยกว่า ซึ่งเป็นจุดเริ่มต้นในการปรับปรุงกระบวนการ. เหตุผลที่สำคัญ ช่วยให้วิเคราะห์ตามมูลค่าได้ จึงจัดลำดับความสำคัญของคำขอมูลค่าสูงและทำความเข้าใจผลของมูลค่าทางการเงินต่อกระบวนการได้. แหล่งข้อมูล โดยทั่วไปพบในข้อมูลส่วนหัวของธุรกรรมคำขอซื้อหรือตารางเอกสาร. ตัวอย่าง 500.0012500.7599.95 | |||
| สกุลเงิน Currency | รหัสสกุลเงิน เช่น USD หรือ EUR ที่ใช้กับยอดรวมของคำขอซื้อ. | ||
| คำอธิบาย แอตทริบิวต์สกุลเงินระบุหน่วยเงินของมูลค่าคำขอซื้อ องค์กรข้ามชาติอาจสร้างคำขอซื้อเป็นสกุลเงินต่างกันตามที่ตั้งของผู้ขอหรือผู้ขาย. ฟิลด์นี้จำเป็นต่อการรายงานและวิเคราะห์ทางการเงินให้ถูกต้อง ช่วยให้ตีความมูลค่าเงินได้ถูกต้องและแปลงสกุลเงินได้เมื่อนำข้อมูลจากหลายภูมิภาคมารวมกัน การวิเคราะห์มูลค่าคำขอซื้อต้องคำนึงถึงสกุลเงิน เพื่อไม่ให้เปรียบเทียบจำนวนเงินคนละสกุลกันโดยตรง. เหตุผลที่สำคัญ ข้อมูลนี้ให้บริบทที่จำเป็นสำหรับข้อมูลทางการเงิน ช่วยให้ตีความและรวมมูลค่าคำขอซื้อจากหลายภูมิภาคได้อย่างถูกต้อง. แหล่งข้อมูล โดยทั่วไปอยู่ในข้อมูลส่วนหัวของธุรกรรมคำขอซื้อ ใกล้กับฟิลด์จำนวนเงิน. ตัวอย่าง USDEURGBP | |||
| สถานะคำขอซื้อ RequisitionStatus | สถานะปัจจุบันหรือสถานะสุดท้ายของคำขอซื้อในวงจรการดำเนินงาน. | ||
| คำอธิบาย สถานะคำขอซื้อแสดงสถานะของคำขอ ณ เวลาหนึ่งหรือผลลัพธ์สุดท้าย สถานะที่พบบ่อย ได้แก่ 'กำลังดำเนินการ' 'รออนุมัติ' 'อนุมัติแล้ว' 'ปฏิเสธแล้ว' และ 'ปิดแล้ว'. แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ผลลัพธ์และติดตามการปฏิบัติการ นักวิเคราะห์สามารถกรองคำขอตามสถานะสุดท้ายเพื่อคำนวณตัวชี้วัด เช่น อัตราการปฏิเสธหรืออัตราการแปลงเป็น PO ในการปฏิบัติการ ข้อมูลนี้ช่วยให้ทีมเห็นภาระงานปัจจุบัน เช่น จำนวนคำขอที่รออนุมัติ และจัดลำดับงานพร้อมบริหารทรัพยากรได้อย่างเหมาะสม. เหตุผลที่สำคัญ ช่วยให้เห็นผลลัพธ์ของคำขอซื้ออย่างชัดเจน คำนวณตัวชี้วัดสำคัญ เช่น อัตราการปฏิเสธ และบริหารภาระงานในการปฏิบัติการได้. แหล่งข้อมูล โดยทั่วไปพบในฟิลด์สถานะส่วนหัวของเอกสารคำขอซื้อ. ตัวอย่าง อนุมัติแล้วปฏิเสธแล้วรออนุมัติถอนแล้ว | |||
| ชื่อผู้ใช้ UserName | ชื่อผู้ใช้ที่ดำเนินกิจกรรมหนึ่งๆ เช่น สร้าง แก้ไข หรืออนุมัติ. | ||
| คำอธิบาย ชื่อผู้ใช้ระบุผู้รับผิดชอบแต่ละกิจกรรมในบันทึกกระบวนการ โดยเป็นแอตทริบิวต์ทั่วไปที่ใช้บันทึกผู้ขอ ผู้แก้ไข ผู้อนุมัติ หรือบุคคลอื่นที่เกี่ยวข้องกับใบขอซื้อ แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์ทรัพยากรและระบบอัตโนมัติ ช่วยให้เห็นการส่งต่องานระหว่างผู้ใช้ตามหลักการตรวจสอบโดยบุคคลสองคน และคำนวณอัตราการทำงานอัตโนมัติได้โดยแยกกิจกรรมที่ดำเนินการโดยผู้ใช้ระบบหรือผู้ใช้แบบกลุ่ม การวิเคราะห์กิจกรรมแยกตามผู้ใช้ยังช่วยให้เข้าใจว่าบทบาทต่างๆ ทำงานร่วมกันอย่างไร. เหตุผลที่สำคัญ แอตทริบิวต์นี้จำเป็นต่อการทำความเข้าใจการส่งต่องานระหว่างผู้ใช้ การวิเคราะห์ระบบอัตโนมัติ และการระบุผู้ดำเนินการในแต่ละขั้นตอนของกระบวนการให้ถูกต้อง. แหล่งข้อมูล ข้อมูลนี้อยู่ในเส้นทางการตรวจสอบหรือบันทึกเหตุการณ์ของแต่ละธุรกรรม โดยมักจัดเก็บเป็น User ID. ตัวอย่าง asmithjdoeBATCH_USER | |||
| ชื่อผู้อนุมัติ ApproverName | ชื่อผู้ใช้หรือกลุ่มที่รับผิดชอบกิจกรรมอนุมัติหรือปฏิเสธ. | ||
| คำอธิบาย ชื่อผู้อนุมัติระบุบุคคล บทบาท หรือกลุ่มที่ดำเนินการอนุมัติหรือปฏิเสธในเวิร์กโฟลว์ ซึ่งแตกต่างจากผู้ขอหรือผู้ใช้ทั่วไปที่อาจทำกิจกรรมอื่น. แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์กระบวนการอนุมัติโดยตรง ช่วยวัดประสิทธิภาพของผู้อนุมัติ เช่น เวลาเฉลี่ยที่ใช้ตัดสินใจ และแสดงการกระจายภาระงานเพื่อให้เห็นว่าผู้อนุมัติบางรายเป็นคอขวดของกระบวนการหรือไม่ การวิเคราะห์นี้ช่วยจัดสรรทรัพยากรและบริหารประสิทธิภาพภายในสายการอนุมัติได้ดีขึ้น. เหตุผลที่สำคัญ ช่วยวิเคราะห์เวิร์กโฟลว์อนุมัติได้อย่างละเอียด ทั้งภาระงานและประสิทธิภาพของผู้อนุมัติ รวมถึงการระบุคอขวด. แหล่งข้อมูล บันทึกไว้ในบันทึกเหตุการณ์หรือบันทึกการตรวจสอบของกิจกรรมที่เกี่ยวกับการอนุมัติ อาจต้องเชื่อมข้อมูลกับข้อมูลหลักของพนักงาน. ตัวอย่าง Alice JohnsonBob Williamsกลุ่มอนุมัติฝ่ายการเงิน | |||
| ระดับความเร่งด่วน UrgencyLevel | การจัดประเภทที่ระบุลำดับความสำคัญหรือความเร่งด่วนของคำขอซื้อ เช่น 'สูง' 'ปานกลาง' หรือ 'ต่ำ'. | ||
| คำอธิบาย ระดับความเร่งด่วน ซึ่งบางครั้งเรียกว่าลำดับความสำคัญ เป็นฟิลด์ที่ผู้ขอใช้ระบุว่าต้องการสินค้า或บริการเร็วเพียงใด การจัดประเภทนี้อาจมีผลต่อวิธีส่งต่อคำขอและการจัดลำดับความสำคัญของทีมจัดซื้อและผู้อนุมัติ. การวิเคราะห์ประสิทธิภาพกระบวนการตามระดับความเร่งด่วนช่วยให้ทราบว่ากระบวนการตอบสนองความต้องการทางธุรกิจได้ดีหรือไม่ ตัวอย่างเช่น ตรวจสอบได้ว่าคำขอเร่งด่วนระดับ 'สูง' ดำเนินการเร็วกว่าคำขอระดับ 'ต่ำ' จริงหรือไม่ หากไม่เป็นเช่นนั้น อาจมีคอขวดหรือกลไกจัดลำดับความสำคัญทำงานไม่ตามที่ควร ซึ่งควรได้รับการแก้ไข. เหตุผลที่สำคัญ ช่วยประเมินว่ากระบวนการจัดลำดับความสำคัญให้คำขอเร่งด่วนได้เหมาะสมหรือไม่ และระดับความเร่งด่วนที่ระบุตรงกับความเร็วในการดำเนินการจริงหรือไม่. แหล่งข้อมูล โดยทั่วไปเป็นฟิลด์ที่เลือกกรอกหรือจำเป็นต้องกรอกในแบบฟอร์มสร้างคำขอซื้อ และจัดเก็บไว้ในส่วนหัวของคำขอ. ตัวอย่าง สูงปานกลางต่ำเร่งด่วน | |||
| วันที่ต้องการรับสินค้า RequiredByDate | วันที่ผู้ขอต้องการให้ส่งมอบสินค้าหรือบริการ. | ||
| คำอธิบาย ผู้ขอระบุวันที่ต้องการรับสินค้าเพื่อกำหนดเส้นตายในการดำเนินการ วันที่นี้ใช้เป็นเป้าหมายตลอดกระบวนการจัดซื้อ ตั้งแต่การอนุมัติใบขอซื้อจนถึงการส่งมอบ แอตทริบิวต์นี้ช่วยวิเคราะห์ความตรงต่อเวลาของกระบวนการและความสอดคล้องกับความต้องการทางธุรกิจ เมื่อนำวันที่ต้องการรับสินค้าไปเปรียบเทียบกับวันที่สร้างใบสั่งซื้อหรือวันที่ส่งมอบจริง องค์กรจะวัดได้ว่าสามารถทำตามข้อตกลงระดับการให้บริการภายในได้หรือไม่ และตอบคำถามสำคัญได้ เช่น กระบวนการจัดซื้อรวดเร็วพอที่จะทันกำหนดเวลาทางธุรกิจหรือไม่. เหตุผลที่สำคัญ ใช้เป็นเกณฑ์วัดผลการดำเนินงานของกระบวนการเทียบกับกำหนดเวลาทางธุรกิจ และประเมินความสามารถในการส่งมอบตรงเวลา. แหล่งข้อมูล โดยทั่วไปผู้ใช้จะกรอกข้อมูลนี้เมื่อสร้างใบขอซื้อ และจัดเก็บไว้ในส่วนหัวของใบขอซื้อหรือรายละเอียดรายการสินค้า. ตัวอย่าง 2024-06-302024-07-152024-08-01 | |||
| เหตุผลที่ปฏิเสธ RejectionReason | เหตุผลที่ผู้อนุมัติระบุเมื่อปฏิเสธคำขอซื้อหรือขั้นตอนอนุมัติ. | ||
| คำอธิบาย เหตุผลที่ปฏิเสธเป็นฟิลด์ข้อความหรือรหัสที่อธิบายสาเหตุที่ไม่อนุมัติคำขอซื้อ ผู้อนุมัติให้ข้อมูลนี้เพื่อแจ้งผู้ขอ ซึ่งอาจต้องแก้ไขและส่งคำขออีกครั้ง. แอตทริบิวต์นี้มีประโยชน์อย่างยิ่งต่อการวิเคราะห์หาสาเหตุรากของปัญหาในกระบวนการ การจัดหมวดหมู่และวิเคราะห์เหตุผลที่ปฏิเสธช่วยให้องค์กรเห็นปัญหาที่พบบ่อย เช่น 'รหัสบัญชีแยกประเภทไม่ถูกต้อง' 'เกินงบประมาณ' หรือ 'ผู้ขายไม่เป็นไปตามข้อกำหนด' ข้อมูลเชิงลึกนี้นำไปสู่การปรับปรุงที่ตรงจุด เช่น ฝึกอบรมผู้ขอให้ดีขึ้น สื่อสารนโยบายให้ชัดเจน หรือปรับปรุงระบบเพื่อป้องกันข้อผิดพลาดที่พบบ่อย. เหตุผลที่สำคัญ ช่วยให้ทราบโดยตรงว่าคำขอซื้อไม่ผ่านเพราะเหตุใด จึงวิเคราะห์หาสาเหตุรากเพื่อลดการทำงานซ้ำและเพิ่มอัตราการอนุมัติตั้งแต่ครั้งแรกได้. แหล่งข้อมูล โดยทั่วไปบันทึกไว้ในฟิลด์ความคิดเห็นหรือหมายเหตุที่เชื่อมโยงกับกิจกรรม 'ปฏิเสธแล้ว' หรือการเปลี่ยนสถานะ. ตัวอย่าง เกินงบประมาณศูนย์ต้นทุนไม่ถูกต้องคำขอซ้ำไม่เป็นไปตามนโยบาย | |||
กิจกรรมในกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| แก้ไขคำขอซื้อ | ผู้ใช้แก้ไขคำขอซื้อหลังส่งแล้ว โดยมักแก้ข้อมูลให้ถูกต้องหรือตอบสนองต่อการปฏิเสธ การแก้ไขอาจเปลี่ยนรายละเอียด เช่น จำนวน ราคา หรือรายการสินค้า และอาจทำให้ต้องเริ่มกระบวนการอนุมัติใหม่. | ||
| เหตุผลที่สำคัญ การติดตามการแก้ไขมีความสำคัญต่อการค้นหาวงจรทำงานซ้ำ ความไม่มีประสิทธิภาพของกระบวนการ และข้อกำหนดเริ่มต้นที่ไม่ชัดเจน หากมีการแก้ไขบ่อย รอบเวลาอาจยาวขึ้นอย่างมาก. แหล่งข้อมูล ดึงข้อมูลจากบันทึกการตรวจสอบของระบบ บันทึกการเปลี่ยนแปลง หรือระบุจากการสร้างเอกสารคำขอซื้อเวอร์ชันใหม่. บันทึก ระบุเหตุการณ์ในบันทึกการเปลี่ยนแปลงหรือบันทึกการตรวจสอบที่ตรงกับการแก้ไขช่องข้อมูลสำคัญของคำขอซื้อหลังจากส่งครั้งแรก. ประเภทเหตุการณ์ explicit | |||
| ปฏิเสธคำขอซื้อ | คำขอซื้อถูกปฏิเสธอย่างเป็นทางการระหว่างกระบวนการอนุมัติ และจะไม่ถูกแปลงเป็นใบสั่งซื้อ นี่คือผลลัพธ์สุดท้ายที่ไม่สำเร็จของคำขอ. | ||
| เหตุผลที่สำคัญ นี่คือขั้นตอนสำคัญที่แสดงว่าคำขอไม่สำเร็จ การวิเคราะห์สาเหตุของการปฏิเสธขั้นสุดท้ายช่วยปรับปรุงขั้นตอนก่อนส่งคำขอและการฝึกอบรมผู้ขอได้. แหล่งข้อมูล อนุมานจากสถานะโดยรวมของส่วนหัวคำขอซื้อที่เปลี่ยนเป็น 'Rejected' หรือ 'Denied' หรือสถานะปฏิเสธขั้นสุดท้ายที่มีความหมายใกล้เคียงกัน. บันทึก บันทึกเวลาที่สถานะโดยรวมของคำขอซื้อเปลี่ยนเป็น 'Rejected' หรือ 'Denied' หรือสถานะเทียบเท่าเป็นครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| ปิดคำขอซื้อแล้ว | ปิดคำขอซื้อในระบบงานธุรการ ซึ่งหมายความว่าจะไม่มีการดำเนินการเพิ่มเติม โดยทั่วไปจะเกิดขึ้นเมื่อแปลงรายการทั้งหมดเป็นใบสั่งซื้อเรียบร้อยแล้ว หรือยกเลิกรายการทั้งหมด. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์สุดท้ายของกระบวนการ ซึ่งยืนยันว่าคำขอซื้อดำเนินมาครบวงจรแล้ว และช่วยป้องกันไม่ให้คำขอเก่าค้างอยู่ในสถานะเปิดตลอดไป. แหล่งข้อมูล อนุมานจากการอัปเดตสถานะสุดท้ายในส่วนหัวคำขอซื้อ หรือเมื่อรายการที่เกี่ยวข้องทั้งหมดมีสถานะสั่งซื้อครบแล้วหรือปิดแล้ว. บันทึก บันทึกเวลาที่กำหนดสถานะสุดท้ายของคำขอซื้อเป็น 'Closed' หรือ 'Completed'. ประเภทเหตุการณ์ inferred | |||
| ส่งคำขอซื้อ | ผู้ขอส่งคำขอซื้อที่กรอกข้อมูลครบแล้วเข้าสู่เวิร์กโฟลว์อนุมัติอย่างเป็นทางการ การดำเนินการนี้เปลี่ยนสถานะคำขอซื้อจากร่างเป็นกำลังดำเนินการ เพื่อรอการตรวจสอบและอนุมัติ. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้เริ่มกระบวนการอนุมัติอย่างเป็นทางการ เวลาตั้งแต่ส่งคำขอจนถึงอนุมัติขั้นสุดท้ายเป็นส่วนสำคัญของรอบเวลาโดยรวม. แหล่งข้อมูล โดยทั่วไปบันทึกจากเหตุการณ์เปลี่ยนสถานะ บันทึกการดำเนินการของผู้ใช้ หรือบันทึกจาก workflow engine ที่ระบุว่าเริ่มกระบวนการอนุมัติแล้ว. บันทึก บันทึกเวลาที่สถานะคำขอซื้อเปลี่ยนจากร่างเป็นสถานะรออนุมัติ. ประเภทเหตุการณ์ explicit | |||
| สร้างคำขอซื้อ | ผู้ใช้เริ่มขอสินค้าและบริการด้วยการสร้างเอกสารคำขอซื้อใหม่ เหตุการณ์นี้เป็นจุดเริ่มต้นของวงจรคำขอซื้อ โดยทั่วไปเอกสารจะอยู่ในสถานะร่างหรือยังไม่สมบูรณ์ก่อนส่งอย่างเป็นทางการ. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ การวิเคราะห์เวลาตั้งแต่สร้างจนถึงส่งคำขอช่วยให้เห็นความล่าช้าในการเตรียมคำขอหรือความไม่แน่ใจของผู้ใช้. แหล่งข้อมูล โดยทั่วไปบันทึกจากเวลาที่สร้างในระเบียนหรือ table ส่วนหัวของคำขอซื้อหลัก. บันทึก ระบุเวลาที่สร้างระเบียนส่วนหัวของคำขอซื้อครั้งแรก. ประเภทเหตุการณ์ explicit | |||
| สร้างใบสั่งซื้อแล้ว | สร้างเอกสารใบสั่งซื้ออย่างเป็นทางการจากข้อมูลในรายการคำขอซื้อที่อนุมัติแล้วหนึ่งรายการหรือหลายรายการ เหตุการณ์นี้เป็นจุดส่งต่องานจากกระบวนการขอซื้อภายในไปยังกระบวนการจัดซื้อภายนอก. | ||
| เหตุผลที่สำคัญ นี่คือผลลัพธ์หลักที่แสดงว่ากระบวนการขอซื้อสำเร็จ ระยะเวลาตั้งแต่อนุมัติขั้นสุดท้ายจนถึงการสร้าง PO ใช้วัดประสิทธิภาพของฝ่ายจัดซื้อ. แหล่งข้อมูล อนุมานเหตุการณ์นี้สำหรับคำขอซื้อได้จากการค้นหาเอกสารใบสั่งซื้อที่อ้างอิง ID ของคำขอซื้อ. บันทึก ระบุเวลาที่สร้างใบสั่งซื้อซึ่งอ้างอิง ID ของคำขอซื้อ. ประเภทเหตุการณ์ inferred | |||
| อนุมัติคำขอซื้อแล้ว | คำขอซื้อผ่านทุกขั้นตอนที่กำหนดในเวิร์กโฟลว์อนุมัติแล้ว ขั้นตอนสำคัญนี้ทำให้สามารถจัดหาสินค้าหรือแปลงคำขอเป็นใบสั่งซื้อได้. | ||
| เหตุผลที่สำคัญ นี่คือขั้นตอนสำคัญที่แสดงว่ากระบวนการสำเร็จ ระยะเวลาที่ใช้จนถึงสถานะนี้เป็นตัวชี้วัดหลักของประสิทธิภาพกระบวนการขอซื้อ. แหล่งข้อมูล อนุมานจากสถานะโดยรวมของส่วนหัวคำขอซื้อที่เปลี่ยนเป็น 'Approved' หรือสถานะอนุมัติขั้นสุดท้ายที่มีความหมายใกล้เคียงกันในบันทึกเวิร์กโฟลว์. บันทึก บันทึกเวลาที่สถานะโดยรวมของคำขอซื้อเปลี่ยนเป็น 'Approved' หรือสถานะเทียบเท่าเป็นครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| กำหนดแหล่งจัดหาแล้ว | ผู้ซื้อหรือผู้เชี่ยวชาญด้านจัดซื้อกำหนดผู้ขาย สัญญา หรือข้อตกลงด้านราคาให้กับรายการในคำขอซื้อที่ได้รับอนุมัติแล้ว ขั้นตอนนี้เป็นการเตรียมก่อนสร้างใบสั่งซื้อ. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ใช้วัดประสิทธิภาพของทีมจัดซื้อเชิงปฏิบัติการ หากล่าช้า อาจเกิดคอขวดระหว่างการอนุมัติคำขอซื้อกับการออกใบสั่งซื้อ. แหล่งข้อมูล ตรวจจับจากการเปลี่ยนแปลงข้อมูลผู้ขายหรือแหล่งจัดหาในรายการคำขอซื้อ หลังจากได้รับอนุมัติแล้ว. บันทึก ระบุเวลาที่มีการกรอกรหัสผู้ขายหรือรหัสสัญญาในรายการคำขอซื้อที่อนุมัติแล้วเป็นครั้งแรก. ประเภทเหตุการณ์ explicit | |||
| ถอนคำขอซื้อ | ผู้ขอหรือผู้ใช้ที่ได้รับอนุญาตยกเลิกคำขอซื้อก่อนที่จะได้รับอนุมัติขั้นสุดท้ายหรือแปลงเป็นใบสั่งซื้อ การดำเนินการนี้จะยุติกระบวนการของคำขอนี้. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้เป็นจุดสิ้นสุดของกระบวนการ โดยไม่ได้ระบุชัดเจนว่าคำขอสำเร็จหรือล้มเหลว หากมีการถอนคำขอจำนวนมาก อาจเป็นสัญญาณว่าความต้องการทางธุรกิจเปลี่ยนไปหรือมีการส่งคำขอก่อนเวลาอันควร. แหล่งข้อมูล โดยทั่วไปจะบันทึกจากการดำเนินการของผู้ใช้โดยตรง ซึ่งเปลี่ยนสถานะเป็น 'Withdrawn' หรือ 'Cancelled' หรือกำหนดแฟล็กการลบ. บันทึก บันทึกเวลาที่สถานะคำขอซื้อเปลี่ยนเป็น 'Withdrawn' หรือ 'Cancelled' หรือเวลาที่กำหนดแฟล็กการลบ. ประเภทเหตุการณ์ explicit | |||
| ปฏิเสธขั้นตอนอนุมัติ | ผู้อนุมัติปฏิเสธคำขอซื้อในขั้นตอนที่ตนรับผิดชอบ โดยทั่วไปจะส่งคำขอกลับไปให้ผู้ขอแก้ไข การดำเนินการนี้ทำให้เวิร์กโฟลว์อนุมัติเดินหน้าต่อไม่ได้. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นสาเหตุหลักของการทำงานซ้ำ การติดตามการปฏิเสธช่วยให้ทราบสาเหตุที่พบบ่อย ความจำเป็นในการฝึกอบรม และขั้นตอนอนุมัติที่เป็นปัญหา. แหล่งข้อมูล บันทึกจากการดำเนินการของผู้ใช้โดยตรง ซึ่งปรากฏในประวัติการอนุมัติหรือข้อมูลธุรกรรมของเวิร์กโฟลว์. บันทึก ดึงเหตุการณ์การปฏิเสธจากประวัติการอนุมัติหรือบันทึกเวิร์กโฟลว์ พร้อมข้อมูลผู้อนุมัติและเวลา. ประเภทเหตุการณ์ explicit | |||
| รีเซ็ตการอนุมัติ | ระบบเริ่มเวิร์กโฟลว์อนุมัติคำขอซื้อใหม่ตั้งแต่ต้น โดยทั่วไปจะเกิดขึ้นเมื่อมีการแก้ไขคำขอซื้อครั้งสำคัญหลังจากเริ่มดำเนินการไปแล้ว. | ||
| เหตุผลที่สำคัญ การเริ่มอนุมัติใหม่เป็นสาเหตุสำคัญที่ทำให้รอบเวลาดำเนินการยาวนานขึ้น การตรวจสอบความถี่และสาเหตุที่ทำให้เกิดเหตุการณ์นี้อาจช่วยชี้ให้เห็นปัญหาด้านนโยบายหรือขั้นตอนการแก้ไขคำขอ. แหล่งข้อมูล อนุมานจากการสังเกตสถานะอนุมัติที่ถูกล้างหรือย้อนกลับไปยังขั้นตอนแรก หลังจากที่เคยมอบหมายให้ผู้อนุมัติในขั้นตอนถัดไปแล้ว. บันทึก ระบุเวลาที่สถานะเวิร์กโฟลว์อนุมัติกลับไปเป็นสถานะเริ่มต้น หลังจากดำเนินไปยังขั้นตอนถัดไปแล้ว. ประเภทเหตุการณ์ inferred | |||
| เริ่มขั้นตอนอนุมัติ | ระบบมอบหมายคำขอซื้อให้ผู้อนุมัติหรือกลุ่มผู้อนุมัติเฉพาะราย ซึ่งเป็นส่วนหนึ่งของเวิร์กโฟลว์หลายขั้นตอน กิจกรรมนี้เป็นจุดเริ่มต้นของช่วงเวลารอการอนุมัติในขั้นตอนนั้น. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้ช่วยวิเคราะห์คอขวดในลำดับการอนุมัติได้อย่างละเอียด และระบุผู้อนุมัติหรือขั้นตอนที่ทำให้เกิดความล่าช้า. แหล่งข้อมูล อนุมานจากบันทึกของ workflow engine เมื่อมีการสร้างงานอนุมัติใหม่และมอบหมายให้ผู้ใช้หรือบทบาท. บันทึก บันทึกเวลาที่สร้างงานอนุมัติ หรือเวลาที่สถานะคำขอซื้อระบุว่ากำลังรอผู้อนุมัติเฉพาะราย. ประเภทเหตุการณ์ inferred | |||
| อนุมัติขั้นตอน | ผู้อนุมัติแต่ละรายให้ความเห็นชอบคำขอซื้อในขั้นตอนที่ตนรับผิดชอบ การดำเนินการนี้จะส่งคำขอซื้อไปยังขั้นตอนถัดไปหรือเข้าใกล้การอนุมัติขั้นสุดท้าย. | ||
| เหตุผลที่สำคัญ การวิเคราะห์เวลาตั้งแต่เริ่มจนจบขั้นตอนอนุมัติช่วยให้เห็นประสิทธิภาพและภาระงานของผู้อนุมัติแต่ละคน. แหล่งข้อมูล บันทึกจากการดำเนินการของผู้ใช้โดยตรง ซึ่งปรากฏในประวัติการอนุมัติหรือข้อมูลธุรกรรมของเวิร์กโฟลว์. บันทึก ดึงเหตุการณ์การอนุมัติจากประวัติการอนุมัติหรือบันทึกเวิร์กโฟลว์ พร้อมข้อมูลผู้อนุมัติและเวลา. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เลือกคู่มือการดึงข้อมูลสำหรับระบบที่คุณใช้เพื่อปรับวิธีเก็บข้อมูล หรือใช้เทมเพลตทั่วไปนี้เป็นโครงสร้างยืดหยุ่นสำหรับเริ่มวิเคราะห์กระบวนการใบขอซื้อ ตั้งแต่การจัดซื้อจนถึงชำระเงิน.
ปรับปรุงกระบวนการใบขอซื้อ P2P เพิ่มประสิทธิภาพได้ตั้งแต่วันนี้
ระบุคอขวด ปรับปรุงการปฏิบัติตามข้อกำหนด และลดค่าใช้จ่ายตลอดกระบวนการ P2P.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จได้ในไม่กี่นาที.