เทมเพลตข้อมูลสำหรับการจัดการคำขอรับบริการ

เทมเพลต process mining สำหรับทุกกระบวนการ
เทมเพลตข้อมูลสำหรับการจัดการคำขอรับบริการ

เทมเพลตข้อมูลสำหรับการจัดการคำขอรับบริการ

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

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

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

แอตทริบิวต์สำหรับการจัดการคำขอรับบริการ

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

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

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

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

ใช้ระบุขั้นตอนของกระบวนการ ช่วยให้ค้นพบขั้นตอนการทำงานจริง คอขวด และจุดที่แตกต่างจากกระบวนการที่กำหนดไว้.

แหล่งข้อมูล

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

ตัวอย่าง
สร้างคำขอบริการมอบหมายคำขอแก้ไขคำขอแล้วปิดคำขอบริการ
รหัสคำขอบริการ
CaseId
รหัสเฉพาะของเคสคำขอบริการแต่ละรายการ ใช้ติดตามคำขอตั้งแต่สร้างจนปิด.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปจะอยู่ในส่วนหัวหรือตารางธุรกรรมหลักของคำขอบริการ.

ตัวอย่าง
SR-2023-00123REQ0045891TICKET-98765
เวลาเริ่มต้น
StartTime
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เริ่มต้นขึ้น.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
ระบบต้นทาง
SourceSystem
ระบุระบบหรือแอปพลิเคชันที่เป็นแหล่งที่มาของข้อมูลคำขอบริการ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปจะเพิ่มค่านี้ระหว่างการดึงข้อมูล (ETL) ไม่ใช่ฟิลด์ที่มีอยู่ในระบบต้นทางแต่แรก.

ตัวอย่าง
ServiceNowJira Service ManagementZendesk
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาที่ระบุว่ามีการดึงหรือรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุดเมื่อใด.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ฟิลด์ข้อมูลเมตานี้มักสร้างและจัดเก็บระหว่างกระบวนการดึงข้อมูล (ETL).

ตัวอย่าง
2023-10-27T08:00:00Z2023-10-26T23:59:59Z
กำหนดส่งตาม SLA
SlaDueDate
วันที่และเวลาที่คาดว่าจะดำเนินการแก้ไขคำขอให้เสร็จตามข้อตกลงระดับการให้บริการ (SLA).
คำอธิบาย

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

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

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

ใช้เป็นเกณฑ์วัดประสิทธิภาพ คำนวณอัตราการปฏิบัติตาม SLA และระบุคำขอที่เกินกำหนดได้.

แหล่งข้อมูล

มักเป็นฟิลด์ที่คำนวณในระเบียนคำขอบริการตามนโยบาย SLA ที่ใช้.

ตัวอย่าง
2023-10-28T17:00:00Z2023-11-01T09:00:00Z
เจ้าหน้าที่ผู้รับผิดชอบ
AssignedAgent
ผู้ใช้หรือเจ้าหน้าที่ที่ได้รับมอบหมายให้ดำเนินการกับคำขอบริการในขณะนั้น.
คำอธิบาย

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

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

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

ช่วยวิเคราะห์ประสิทธิภาพและภาระงานของเจ้าหน้าที่แต่ละคน รวมถึงความถี่ในการมอบหมายงานใหม่ระหว่างเจ้าหน้าที่.

แหล่งข้อมูล

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

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

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

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

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

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

แหล่งข้อมูล

เป็นฟิลด์มาตรฐานในระเบียนคำขอบริการ การเปลี่ยนแปลงฟิลด์นี้จะบันทึกไว้ในบันทึกการตรวจสอบ.

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

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

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

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

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

แหล่งข้อมูล

เป็นฟิลด์มาตรฐานในระเบียนคำขอบริการ ซึ่งมักเชื่อมโยงกับแค็ตตาล็อกบริการ.

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

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปเป็นฟิลด์มาตรฐานในระเบียนคำขอบริการหลัก.

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

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

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

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

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

แหล่งข้อมูล

ดูได้จากตารางคำขอบริการหลักหรือบันทึกประวัติสถานะ.

ตัวอย่าง
กำลังดำเนินการรอลูกค้าแก้ไขแล้วปิดแล้ว
เกินกำหนด SLA หรือไม่
IsSlaBreached
ตัวบ่งชี้ว่าคำขอบริการได้รับการแก้ไขหลังจากกำหนดส่งตาม SLA หรือไม่.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
truefalse
จำนวนครั้งที่มอบหมายใหม่
ReassignmentCount
จำนวนครั้งทั้งหมดที่มีการมอบหมายคำขอให้เจ้าหน้าที่หรือทีมอื่น.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

เป็นตัวชี้วัดที่คำนวณจากจำนวนครั้งที่ฟิลด์ 'AssignedAgent' หรือ 'AssignedTeam' เปลี่ยนแปลงสำหรับ 'CaseId' แต่ละรายการ.

ตัวอย่าง
0135
ช่องทางการส่งคำขอ
SubmissionChannel
วิธีหรือช่องทางที่ใช้ส่งคำขอบริการ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปเป็นฟิลด์มาตรฐานในระเบียนคำขอบริการ.

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

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปดึงข้อมูลนี้จากโปรไฟล์ผู้ยื่นคำขอในไดเรกทอรีพนักงานหรือระบบ ITSM.

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

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

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

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

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

แหล่งข้อมูล

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

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

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
2023-10-26T10:05:12Z2023-10-26T15:00:45Z2023-10-28T09:20:00Z
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในการจัดการคำขอรับบริการ

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

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาประทับของการเปลี่ยนสถานะครั้งแรกเป็นสถานะที่กำลังดำเนินการ เช่น 'กำลังดำเนินการ' หลังจากมอบหมายคำขอแล้ว.

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

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

แหล่งข้อมูล

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

บันทึก

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

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

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

แหล่งข้อมูล

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

บันทึก

ใช้เวลาประทับเมื่อสถานะคำขอเปลี่ยนเป็นสถานะที่ระบุว่ากำลังรอผู้ใช้.

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

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

แหล่งข้อมูล

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

บันทึก

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

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

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาประทับเมื่อสถานะเปลี่ยนจากสถานะที่แก้ไขแล้วกลับเป็นสถานะที่กำลังดำเนินการ.

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

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

แหล่งข้อมูล

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

บันทึก

ระบุเวลาประทับแรกที่มีการกรอกช่องผู้รับผิดชอบหรือกลุ่มที่ได้รับมอบหมาย.

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

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

แหล่งข้อมูล

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

บันทึก

ใช้เวลาประทับที่บันทึกเมื่อสร้างระเบียนคำขอบริการหลัก.

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

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาประทับเมื่อสถานะเปลี่ยนจากสถานะรอผู้ใช้กลับเป็นสถานะที่กำลังดำเนินการ.

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

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาประทับเมื่อสถานะคำขอเปลี่ยนเป็น 'ปฏิเสธ' หรือสถานะสิ้นสุดที่มีความหมายใกล้เคียงกัน.

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

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

แหล่งข้อมูล

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

บันทึก

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

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

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

แหล่งข้อมูล

ติดตามเหตุการณ์นี้ได้จากการเปลี่ยนแปลงช่อง 'ผู้รับผิดชอบ' หรือ 'กลุ่มที่ได้รับมอบหมาย' หลังจากมอบหมายครั้งแรกแล้ว.

บันทึก

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

ประเภทเหตุการณ์ explicit
ยกเลิกคำขอบริการ
ถอนคำขอบริการก่อนดำเนินการเสร็จ ผู้ส่งคำขอหรือศูนย์บริการเป็นผู้ยกเลิกได้.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาประทับเมื่อสถานะเปลี่ยนเป็น 'ยกเลิกแล้ว'.

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

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

แหล่งข้อมูล

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

บันทึก

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

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

กิจกรรมนี้ช่วยแยกและวัดความล่าช้าที่เกิดจากหน่วยงานภายนอก ซึ่งจำเป็นต่อการวิเคราะห์ผลการดำเนินงานและจัดการ SLA ให้แม่นยำ.

แหล่งข้อมูล

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

บันทึก

ระบุเวลาประทับเมื่อสถานะเปลี่ยนเป็นสถานะที่แสดงว่าต้องรอหน่วยงานภายนอก.

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

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาประทับเมื่อสถานะคำขอเปลี่ยนเป็นสถานะรออนุมัติ.

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

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

แหล่งข้อมูล

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

บันทึก

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

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

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

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

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

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

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

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

เริ่มปรับปรุงการจัดการคำขอรับบริการวันนี้

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

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

ไม่ต้องใช้บัตรเครดิต