เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ

เทมเพลต process mining สำหรับทุกกระบวนการ
เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ

เทมเพลตข้อมูลสำหรับกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ

เทมเพลต process mining สำหรับทุกกระบวนการ

นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ จัดซื้อจนถึงชำระเงิน: ใบขอซื้อ หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.

เลือกระบบที่ต้องการ
  • ฟิลด์ข้อมูลมาตรฐานเพื่อให้วิเคราะห์ข้อมูลจากระบบต่างๆ ได้อย่างสอดคล้องกัน.
  • รายการกิจกรรมสำคัญที่ควรติดตาม เพื่อให้เห็นภาพกระบวนการได้ครบถ้วน.
  • โครงสร้างพื้นฐานที่ยืดหยุ่นและปรับให้เข้ากับเวิร์กโฟลว์ใบขอซื้อขององค์กรคุณได้.
เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

แอตทริบิวต์ของกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ

ส่วนนี้อธิบายฟิลด์ข้อมูลที่แนะนำและแอตทริบิวต์สำคัญที่ควรใส่ในบันทึกเหตุการณ์ เพื่อวิเคราะห์กระบวนการจัดซื้อจนถึงชำระเงินและการขอซื้อได้อย่างครบถ้วน.
5 จำเป็น 7 แนะนำ 5 ไม่บังคับ
ชื่อ คำอธิบาย
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
เหตุผลที่ผู้อนุมัติระบุเมื่อปฏิเสธคำขอซื้อหรือขั้นตอนอนุมัติ.
คำอธิบาย

เหตุผลที่ปฏิเสธเป็นฟิลด์ข้อความหรือรหัสที่อธิบายสาเหตุที่ไม่อนุมัติคำขอซื้อ ผู้อนุมัติให้ข้อมูลนี้เพื่อแจ้งผู้ขอ ซึ่งอาจต้องแก้ไขและส่งคำขออีกครั้ง.

แอตทริบิวต์นี้มีประโยชน์อย่างยิ่งต่อการวิเคราะห์หาสาเหตุรากของปัญหาในกระบวนการ การจัดหมวดหมู่และวิเคราะห์เหตุผลที่ปฏิเสธช่วยให้องค์กรเห็นปัญหาที่พบบ่อย เช่น 'รหัสบัญชีแยกประเภทไม่ถูกต้อง' 'เกินงบประมาณ' หรือ 'ผู้ขายไม่เป็นไปตามข้อกำหนด' ข้อมูลเชิงลึกนี้นำไปสู่การปรับปรุงที่ตรงจุด เช่น ฝึกอบรมผู้ขอให้ดีขึ้น สื่อสารนโยบายให้ชัดเจน หรือปรับปรุงระบบเพื่อป้องกันข้อผิดพลาดที่พบบ่อย.

เหตุผลที่สำคัญ

ช่วยให้ทราบโดยตรงว่าคำขอซื้อไม่ผ่านเพราะเหตุใด จึงวิเคราะห์หาสาเหตุรากเพื่อลดการทำงานซ้ำและเพิ่มอัตราการอนุมัติตั้งแต่ครั้งแรกได้.

แหล่งข้อมูล

โดยทั่วไปบันทึกไว้ในฟิลด์ความคิดเห็นหรือหมายเหตุที่เชื่อมโยงกับกิจกรรม 'ปฏิเสธแล้ว' หรือการเปลี่ยนสถานะ.

ตัวอย่าง
เกินงบประมาณศูนย์ต้นทุนไม่ถูกต้องคำขอซ้ำไม่เป็นไปตามนโยบาย
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในกระบวนการจัดซื้อจนถึงชำระเงิน: ใบขอซื้อ

กิจกรรมในรายการนี้คือขั้นตอนสำคัญและเหตุการณ์หลักที่ควรบันทึก เพื่อค้นพบกระบวนการและระบุคอขวดได้อย่างแม่นยำ.
7 แนะนำ 6 ไม่บังคับ
กิจกรรม คำอธิบาย
แก้ไขคำขอซื้อ
ผู้ใช้แก้ไขคำขอซื้อหลังส่งแล้ว โดยมักแก้ข้อมูลให้ถูกต้องหรือตอบสนองต่อการปฏิเสธ การแก้ไขอาจเปลี่ยนรายละเอียด เช่น จำนวน ราคา หรือรายการสินค้า และอาจทำให้ต้องเริ่มกระบวนการอนุมัติใหม่.
เหตุผลที่สำคัญ

การติดตามการแก้ไขมีความสำคัญต่อการค้นหาวงจรทำงานซ้ำ ความไม่มีประสิทธิภาพของกระบวนการ และข้อกำหนดเริ่มต้นที่ไม่ชัดเจน หากมีการแก้ไขบ่อย รอบเวลาอาจยาวขึ้นอย่างมาก.

แหล่งข้อมูล

ดึงข้อมูลจากบันทึกการตรวจสอบของระบบ บันทึกการเปลี่ยนแปลง หรือระบุจากการสร้างเอกสารคำขอซื้อเวอร์ชันใหม่.

บันทึก

ระบุเหตุการณ์ในบันทึกการเปลี่ยนแปลงหรือบันทึกการตรวจสอบที่ตรงกับการแก้ไขช่องข้อมูลสำคัญของคำขอซื้อหลังจากส่งครั้งแรก.

ประเภทเหตุการณ์ 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
แนะนำ ไม่บังคับ

คู่มือการดึงข้อมูล

เตรียมข้อมูลสำหรับ process mining อย่างไร.

วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด

อ่านคู่มือ ETL ของเรา   หรือ   เลือกกระบวนการและระบบที่ต้องการ.

พร้อมเริ่มต้นหรือยัง?

เลือกคู่มือการดึงข้อมูลสำหรับระบบที่คุณใช้เพื่อปรับวิธีเก็บข้อมูล หรือใช้เทมเพลตทั่วไปนี้เป็นโครงสร้างยืดหยุ่นสำหรับเริ่มวิเคราะห์กระบวนการใบขอซื้อ ตั้งแต่การจัดซื้อจนถึงชำระเงิน.

ปรับปรุงกระบวนการใบขอซื้อ P2P เพิ่มประสิทธิภาพได้ตั้งแต่วันนี้

ระบุคอขวด ปรับปรุงการปฏิบัติตามข้อกำหนด และลดค่าใช้จ่ายตลอดกระบวนการ P2P.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จได้ในไม่กี่นาที.