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