เทมเพลตข้อมูล Purchase to Pay - Requisition

NetSuite
เทมเพลตข้อมูล Purchase to Pay - Requisition

เทมเพลตข้อมูล Purchase to Pay - Requisition

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

ฟิลด์ข้อมูล Purchase to Pay - Requisition

ฟิลด์ข้อมูลเหล่านี้เป็นรายการที่แนะนำให้ใส่ในบันทึกเหตุการณ์ เพื่อวิเคราะห์กระบวนการ Purchase to Pay - Requisition ได้อย่างละเอียด.
3 จำเป็น 4 แนะนำ 12 ไม่บังคับ
ชื่อ คำอธิบาย
Purchase Requisition ID
PurchaseRequisitionId
รหัสเฉพาะของคำขอซื้อแต่ละรายการ ใช้เป็น Case ID หลักสำหรับวิเคราะห์กระบวนการ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

นี่คือ ID ภายในหรือหมายเลขธุรกรรมของรายการ Purchase Requisition ใน NetSuite โดยทั่วไปดูได้จากฟิลด์ 'tranid' ของธุรกรรม.

ตัวอย่าง
PR-001254PR-001255PR-001256
ชื่อกิจกรรม
ActivityName
ชื่อเหตุการณ์ทางธุรกิจหรืองานเฉพาะที่เกิดขึ้นในวงจรคำขอซื้อ.
คำอธิบาย

ชื่อกิจกรรมใช้ระบุขั้นตอนที่แตกต่างกันในกระบวนการใบขอซื้อ เช่น 'สร้างใบขอซื้อ', 'อนุมัติขั้นตอนการอนุมัติ' หรือ 'สร้างใบสั่งซื้อ' กิจกรรมเหล่านี้เป็นองค์ประกอบพื้นฐานของแผนผังกระบวนการ และแสดงงานที่เกิดขึ้น

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

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

ใช้ระบุขั้นตอนในกระบวนการ ทำให้แสดงแผนผังกระบวนการ วิเคราะห์รูปแบบกระบวนการ และระบุคอขวดได้.

แหล่งข้อมูล

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

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

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

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

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

Timestamp นี้เป็นพื้นฐานของการวิเคราะห์ประสิทธิภาพ เช่น การคำนวณรอบเวลา การระบุความล่าช้า และการวัดประสิทธิภาพของกระบวนการ.

แหล่งข้อมูล

ข้อมูลนี้บันทึกในฟิลด์ที่ระบบสร้าง เช่น 'Date Created' หรือ Timestamp ใน System Notes หรือบันทึกการทำงานของเวิร์กโฟลว์สำหรับแต่ละธุรกรรม.

ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
ผู้ขอ
Requester
พนักงานที่สร้างและส่งคำขอซื้อ.
คำอธิบาย

ผู้ขอคือผู้เริ่มกระบวนการจัดซื้อด้วยการสร้างคำขอซื้อ โดยทั่วไปเป็นพนักงานที่ต้องการสินค้าหรือบริการเฉพาะเพื่อใช้ทำงาน

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

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

ระบุผู้เริ่มกระบวนการ ซึ่งสำคัญต่อการวิเคราะห์พฤติกรรมผู้ใช้ อัตราการปฏิเสธแยกตามผู้ขอ และความต้องการฝึกอบรม.

แหล่งข้อมูล

โดยทั่วไปคือฟิลด์ 'Employee' หรือ 'Created By' ในรายการธุรกรรม Purchase Requisition.

ตัวอย่าง
John SmithJane DoePeter Jones
แผนก
Department
แผนกธุรกิจที่คำขอซื้อหรือผู้ขอสังกัดอยู่.
คำอธิบาย

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

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

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

ช่วยแบ่งกลุ่มข้อมูลกระบวนการเพื่อเปรียบเทียบประสิทธิภาพ ต้นทุน และการปฏิบัติตามข้อกำหนดระหว่างหน่วยธุรกิจต่างๆ.

แหล่งข้อมูล

ข้อมูลนี้มักเชื่อมโยงกับประวัติพนักงานของผู้ขอ หรือกำหนดได้โดยตรงในส่วนหัวธุรกรรมของ Purchase Requisition.

ตัวอย่าง
การตลาดITการเงินการปฏิบัติการ
ยอดรวม
TotalAmount
มูลค่ารวมของคำขอซื้อ.
คำอธิบาย

แอตทริบิวต์นี้บันทึกต้นทุนรวมของสินค้าทั้งหมดในคำขอซื้อ เป็นข้อมูลทางการเงินสำคัญที่มักส่งผลต่อกระบวนการ เช่น กระตุ้นให้ใช้เวิร์กโฟลว์การอนุมัติที่ต่างกันตามเกณฑ์มูลค่า

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

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

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

แหล่งข้อมูล

ฟิลด์มาตรฐานในรายการ Purchase Requisition ซึ่งมักใช้ชื่อ 'Total' หรือชื่อใกล้เคียง.

ตัวอย่าง
500.001250.7525000.00
สถานะคำขอซื้อ
RequisitionStatus
ระบุสถานะปัจจุบันของคำขอซื้อในวงจรการดำเนินงาน.
คำอธิบาย

Requisition Status แสดงสถานะของคำขอซื้อในกระบวนการ ณ เวลาหนึ่ง สถานะที่พบบ่อย ได้แก่ 'Pending Approval', 'Fully Approved', 'Rejected' และ 'Closed'

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

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

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

แหล่งข้อมูล

ฟิลด์ 'Status' หรือ 'Approval Status' ในส่วนหัวธุรกรรม Purchase Requisition.

ตัวอย่าง
รอการอนุมัติอนุมัติครบแล้วปฏิเสธแล้วปิดแล้ว
Purchase Order ID
PurchaseOrderId
รหัสของใบสั่งซื้อที่สร้างจากคำขอซื้อที่อนุมัติแล้ว.
คำอธิบาย

Purchase Order ID คือรหัสเฉพาะของใบสั่งซื้อที่สร้างขึ้นหลังจากอนุมัติใบขอซื้อแล้ว ฟิลด์นี้เชื่อมโยงกระบวนการขอซื้อกับขั้นตอนการจัดซื้อที่ตามมา

ในการวิเคราะห์กระบวนการ ลิงก์นี้จำเป็นต่อการวิเคราะห์ P2P ตั้งแต่ต้นจนจบ ช่วยคำนวณ KPI 'PO Creation Lead Time' โดยวัดเวลาตั้งแต่อนุมัติใบขอซื้อจนถึงสร้างใบสั่งซื้อ และยังช่วยคำนวณ 'Requisition-to-PO Conversion Rate' เพื่อให้เห็นว่าใบขอซื้อถูกเปลี่ยนเป็นใบสั่งซื้อที่นำไปดำเนินการได้อย่างมีประสิทธิภาพเพียงใด.

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

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

แหล่งข้อมูล

ดูข้อมูลนี้ได้ในระเบียน Purchase Requisition โดยมักอยู่ในแท็บระเบียนที่เกี่ยวข้อง หรือลิงก์ 'Created From' ในระเบียน Purchase Order.

ตัวอย่าง
PO-005432PO-005433PO-005434
ชื่อผู้ขาย
VendorName
ชื่อผู้ขายที่แนะนำหรือผู้ขายที่ต้องการสำหรับใบขอซื้อ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ข้อมูลนี้อาจอยู่ในฟิลด์ 'Vendor' ระดับหัวเอกสาร หรือระบุไว้ในแต่ละรายการของระเบียน Purchase Requisition.

ตัวอย่าง
Dell Inc.StaplesMcKinsey & Company
ผู้อนุมัติ
Approver
พนักงานหรือผู้ใช้ที่รับผิดชอบอนุมัติหรือปฏิเสธขั้นตอนการอนุมัติ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ข้อมูลนี้มักอยู่ในบันทึกการทำงานของเวิร์กโฟลว์หรือ System Notes ที่เกี่ยวข้องกับการเปลี่ยนสถานะการอนุมัติ และอาจจัดเก็บในฟิลด์ระเบียนที่กำหนดเองสำหรับเวิร์กโฟลว์การอนุมัติ.

ตัวอย่าง
Sarah JenkinsDavid Chenกลุ่มอนุมัติฝ่ายการเงิน
มีการแก้ไขงานซ้ำ
IsRework
ค่าบูลีนที่ระบุว่าใบขอซื้อถูกปฏิเสธและส่งกลับมาใหม่หรือไม่.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
truefalse
ระดับความเร่งด่วน
UrgencyLevel
การจัดระดับความสำคัญของใบขอซื้อ เช่น ปกติหรือเร่งด่วน.
คำอธิบาย

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

ฟิลด์นี้ใช้กับแดชบอร์ด 'Urgent Request Handling Performance' และ KPI 'Urgent Requisition Handling Time' โดยกรองข้อมูลกระบวนการตามระดับความเร่งด่วนเพื่อเปรียบเทียบระยะเวลาและเส้นทางของคำขอเร่งด่วนกับคำขอปกติ ช่วยให้ผู้วิเคราะห์ประเมินได้ว่าการจัดลำดับความสำคัญช่วยให้ดำเนินการเร็วขึ้นหรือยังมีคอขวดทำให้ล่าช้า.

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

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

แหล่งข้อมูล

โดยทั่วไปจะเป็นฟิลด์เนื้อหารายการธุรกรรมที่กำหนดเองในแบบฟอร์ม Purchase Requisition.

ตัวอย่าง
สูงปานกลางต่ำ
ระบบต้นทาง
SourceSystem
ระบุระบบต้นทางที่ใช้ดึงข้อมูล.
คำอธิบาย

แอตทริบิวต์นี้ระบุระบบต้นทางของข้อมูลกระบวนการ ซึ่งในกรณีนี้คือ NetSuite มีประโยชน์เป็นพิเศษเมื่อรวมข้อมูลจากหลายระบบเพื่อให้เห็นภาพกระบวนการโดยรวม

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

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

ให้บริบทสำคัญเกี่ยวกับแหล่งที่มาของข้อมูล ช่วยให้เข้าใจและกำกับดูแลข้อมูลได้ถูกต้อง โดยเฉพาะในสภาพแวดล้อมที่มีหลายระบบ.

แหล่งข้อมูล

เพิ่มค่าคงที่ 'NetSuite' ระหว่างขั้นตอนดึงและแปลงข้อมูล.

ตัวอย่าง
NetSuiteNetSuite SuitePeopleNetSuite ERP
ระยะเวลาดำเนินการ
CycleTime
เวลารวมตั้งแต่สร้างใบขอซื้อจนถึงได้ข้อสรุปสุดท้าย.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ฟิลด์นี้คำนวณโดยนำเวลาของเหตุการณ์แรกมาลบจากเวลาของเหตุการณ์สุดท้ายในแต่ละ 'PurchaseRequisitionId'.

ตัวอย่าง
25920060480086400
สกุลเงิน
Currency
รหัสสกุลเงินของยอดรวมคำขอซื้อ.
คำอธิบาย

แอตทริบิวต์ Currency ระบุสกุลเงินที่ใช้แสดงมูลค่าทางการเงินของคำขอซื้อ เช่น USD, EUR หรือ GBP ซึ่งสำคัญเป็นพิเศษสำหรับองค์กรข้ามชาติที่ใช้หลายสกุลเงิน

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

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

จำเป็นต่อการวิเคราะห์ทางการเงินที่ถูกต้องในองค์กรข้ามชาติ ช่วยให้ตีความและรวมมูลค่าเงินได้อย่างเหมาะสม.

แหล่งข้อมูล

ฟิลด์มาตรฐาน 'Currency' ในรายการธุรกรรม Purchase Requisition โดยเฉพาะ NetSuite ที่ตั้งค่าให้รองรับหลายสกุลเงิน.

ตัวอย่าง
USDEURGBP
เส้นทางเวิร์กโฟลว์การอนุมัติ
ApprovalWorkflowPath
ลำดับขั้นตอนการอนุมัติที่ใบขอซื้อผ่าน.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ฟิลด์นี้คำนวณจากการนำค่า 'ActivityName' ของแต่ละ 'PurchaseRequisitionId' มาเรียงต่อกันตามลำดับเวลา.

ตัวอย่าง
สร้าง > ส่งคำขอ > อนุมัติสร้าง > ส่งคำขอ > ปฏิเสธ > แก้ไข > ส่งคำขอ > อนุมัติสร้าง > ส่งคำขอ > อนุมัติ > ถอนคำขอ
หมวดหมู่สินค้า
ItemCategory
หมวดหมู่ของสินค้าหรือบริการที่ระบุในใบขอซื้อ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ข้อมูลนี้ดึงจากระเบียน 'Item' ที่เชื่อมกับแต่ละรายการใน Purchase Requisition ส่วนหมวดหมู่อาจเป็นฟิลด์มาตรฐานหรือฟิลด์ที่กำหนดเองในระเบียน Item.

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

เหตุผลที่ปฏิเสธเป็นฟิลด์ข้อความที่ผู้อนุมัติใช้ระบุว่าใบขอซื้อไม่ผ่านเกณฑ์การอนุมัติข้อใด ข้อมูลนี้ช่วยอธิบายกิจกรรม 'Approval Step Rejected' ให้ชัดเจนขึ้น

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

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

ช่วยให้เข้าใจสาเหตุของการปฏิเสธ และวิเคราะห์หาสาเหตุที่แท้จริงเพื่อลดการปฏิเสธในอนาคตและเพิ่มคุณภาพตั้งแต่ครั้งแรก.

แหล่งข้อมูล

ข้อมูลนี้มักบันทึกไว้ในฟิลด์ 'Memo' ตอนปฏิเสธ หรือในฟิลด์ที่เพิ่มไว้ในเวิร์กโฟลว์การอนุมัติ นอกจากนี้ยังดูได้ใน System Notes.

ตัวอย่าง
เกินงบประมาณเลือกผู้ขายไม่ถูกต้องรายละเอียดสินค้าไม่ครบคำขอซ้ำ
อัปเดตข้อมูลล่าสุด
LastDataUpdate
Timestamp ที่ระบุเวลาล่าสุดที่ดึงหรือรีเฟรชข้อมูลจากระบบต้นทาง.
คำอธิบาย

แอตทริบิวต์นี้บันทึกวันที่และเวลาที่ดึงข้อมูลจาก NetSuite ล่าสุด เป็นข้อมูลเมตาสำคัญสำหรับแดชบอร์ดหรือการวิเคราะห์ process mining

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

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

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

แหล่งข้อมูล

สร้างและเพิ่ม Timestamp นี้ระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL).

ตัวอย่าง
2024-05-21T08:00:00Z2024-05-20T08:00:00Z
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในกระบวนการ Purchase to Pay - Requisition

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

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

แหล่งข้อมูล

อนุมานจากแท็บย่อย System Notes โดยระบุ Timestamp ที่ฟิลด์ 'Approval Status' เปลี่ยนเป็นสถานะสุดท้าย 'Rejected'.

บันทึก

Timestamp ที่ 'Approval Status' เปลี่ยนเป็น 'Rejected'.

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

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

แหล่งข้อมูล

อนุมานจากแท็บย่อย System Notes โดยระบุ Timestamp ที่ฟิลด์ 'Status' ระดับรายการย่อยหรือส่วนหัวเปลี่ยนเป็น 'Closed'.

บันทึก

Timestamp ที่ฟิลด์ 'Status' เปลี่ยนเป็น 'Closed'.

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

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

แหล่งข้อมูล

เหตุการณ์นี้บันทึกจาก Timestamp วันที่สร้างรายการธุรกรรม Purchase Requisition โดยดูได้จากส่วนหัวหลักของรายการ หรือแท็บย่อย System Notes ซึ่งบันทึกการดำเนินการ 'Create'.

บันทึก

ใช้ฟิลด์ 'Date Created' ในรายการ Purchase Requisition.

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

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

แหล่งข้อมูล

ระบุได้จากรายการ Purchase Order ที่ฟิลด์ 'Created From' หรือฟิลด์เชื่อมโยงที่คล้ายกันอ้างอิงถึง Purchase Requisition ID วันที่สร้าง PO คือ Timestamp ของกิจกรรมนี้.

บันทึก

ค้นหา PO ที่ฟิลด์ 'Created From' ตรงกับ Requisition ID แล้วใช้ค่า 'Date Created' ของ PO.

ประเภทเหตุการณ์ explicit
อนุมัติคำขอซื้อครบทุกขั้นตอน
คำขอซื้อผ่านทุกขั้นตอนที่กำหนดในเวิร์กโฟลว์การอนุมัติ โดยอนุมานได้เมื่อ 'Approval Status' สุดท้ายของรายการเปลี่ยนเป็น 'Approved'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากแท็บย่อย System Notes โดยระบุ Timestamp ที่ฟิลด์ 'Approval Status' เปลี่ยนเป็นสถานะสุดท้าย 'Approved'.

บันทึก

Timestamp ที่ 'Approval Status' เปลี่ยนเป็น 'Approved'.

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

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

แหล่งข้อมูล

บันทึกจากแท็บย่อย System Notes ในรายการ Purchase Requisition รายการที่มี 'Type' เป็น 'Change' หรือ 'Edit' ในฟิลด์ที่เกี่ยวข้องถือเป็นการแก้ไข.

บันทึก

บันทึกเหตุการณ์สำหรับรายการประเภท 'Change' ทุกรายการในบันทึก System Notes.

ประเภทเหตุการณ์ explicit
ถอนคำขอซื้อ
ผู้ขอเดิมหรือผู้ดูแลระบบยกเลิกคำขอซื้อก่อนอนุมัติครบทุกขั้นตอนหรือก่อนเปลี่ยนเป็น PO โดยทั่วไปอนุมานได้จากการเปลี่ยนสถานะเป็น 'Cancelled' หรือ 'Withdrawn'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากแท็บย่อย System Notes โดยติดตาม Timestamp ที่ฟิลด์ 'Approval Status' เปลี่ยนเป็นค่าอย่าง 'Cancelled' หรือสถานะถอนคำขอที่กำหนดเอง.

บันทึก

Timestamp ที่ 'Approval Status' เปลี่ยนเป็น 'Cancelled' หรือ 'Withdrawn'.

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

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

แหล่งข้อมูล

บันทึกจาก log ของ SuiteApprovals หรือแท็บย่อย System Notes ซึ่งระบุการปฏิเสธ ผู้ใช้ที่ปฏิเสธ และ Timestamp.

บันทึก

ระบุการปฏิเสธจาก log ของ SuiteApprovals หรือ System Notes.

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

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

แหล่งข้อมูล

อนุมานจากบันทึกการทำงานของเวิร์กโฟลว์ หรือการเปลี่ยนแปลงในฟิลด์ 'Current Approver' หรือสถานะเวิร์กโฟลว์ แพลตฟอร์ม SuiteApprovals ติดตามขั้นตอนการอนุมัติที่กำลังดำเนินการ.

บันทึก

อนุมานจากบันทึกเวิร์กโฟลว์ หรือเมื่อมีการมอบหมายรายการให้ผู้อนุมัติคนใหม่.

ประเภทเหตุการณ์ inferred
ส่งคำขอซื้อเพื่อขออนุมัติ
ผู้ขอส่งคำขอซื้อที่กรอกข้อมูลครบแล้วเข้าสู่เวิร์กโฟลว์การอนุมัติที่กำหนดอย่างเป็นทางการ โดยมักอนุมานจากการเปลี่ยนสถานะในรายการคำขอซื้อ เช่น จาก 'Draft' หรือ 'Pending Submission' เป็น 'Pending Approval'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากแท็บย่อย System Notes โดยระบุ Timestamp ที่ฟิลด์ 'Approval Status' เปลี่ยนเป็นค่าอย่าง 'Pending Approval' เป็นครั้งแรก.

บันทึก

ระบุ Timestamp แรกที่ฟิลด์ 'Approval Status' เปลี่ยนเป็น 'Pending Approval'.

ประเภทเหตุการณ์ inferred
อนุมัติขั้นตอน
ผู้ใช้ที่ได้รับอนุญาตอนุมัติขั้นตอนที่ได้รับมอบหมายในเวิร์กโฟลว์ ทำให้คำขอซื้อเข้าใกล้การอนุมัติขั้นสุดท้ายมากขึ้น แพลตฟอร์ม SuiteApprovals ของ NetSuite บันทึกการดำเนินการนี้พร้อมรายละเอียดผู้ใช้และ Timestamp.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

บันทึกจาก log ของ SuiteApprovals หรือแท็บย่อย System Notes ซึ่งระบุการอนุมัติ ผู้อนุมัติ และ Timestamp ที่แน่นอนของเหตุการณ์.

บันทึก

ระบุการอนุมัติจาก log ของ SuiteApprovals หรือ System Notes.

ประเภทเหตุการณ์ explicit
แนะนำ ไม่บังคับ

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

วิธีดึงข้อมูลจาก NetSuite

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

ใช้เทมเพลตนี้เริ่มต้นใช้งาน process mining และค้นหาข้อมูลเชิงลึกที่เป็นประโยชน์เกี่ยวกับกระบวนการ Purchase to Pay - Requisition ใน NetSuite เริ่มปรับปรุงประสิทธิภาพและเร่งการอนุมัติได้ตั้งแต่วันนี้.

เริ่มปรับปรุงกระบวนการ Purchase to Pay - Requisition วันนี้!

อนุมัติใบขอซื้อได้เร็วขึ้น 30% และขจัดคอขวด.

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

ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้วันนี้.