เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ
เทมเพลตข้อมูลสำหรับการจัดการคำขอบริการ
- แอตทริบิวต์ที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตามเพื่อค้นพบกระบวนการ
- แนวทางดึงข้อมูลทีละขั้นตอน
คุณลักษณะของการจัดการคำขอบริการ
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
ActivityName
|
ชื่อเหตุการณ์หรืองานที่เกิดขึ้นในวงจรคำขอบริการ. | ||
|
คำอธิบาย
คุณลักษณะกิจกรรมบันทึกชื่อของแต่ละขั้นตอนหรือการเปลี่ยนสถานะในกระบวนการคำขอบริการ เช่น 'สร้างคำขอแล้ว' 'อนุมัติคำขอแล้ว' 'มอบหมายให้เจ้าหน้าที่แล้ว' หรือ 'ปิดคำขอแล้ว' การวิเคราะห์กิจกรรมเหล่านี้ช่วยให้เห็นภาพการไหลของกระบวนการ ระบุเส้นทางที่เกิดขึ้นบ่อย และตรวจพบความคลาดเคลื่อนจากขั้นตอนมาตรฐาน นี่คือพื้นฐานสำคัญในการทำความเข้าใจสิ่งที่เกิดขึ้นจริงระหว่างดำเนินการตามคำขอ.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้จำเป็นต่อการกำหนดขั้นตอนในแผนผังกระบวนการ และเป็นพื้นฐานของการวิเคราะห์กระบวนการ ทั้งการค้นหาคอขวด วงจรการทำงานซ้ำ และปัญหาการปฏิบัติตามข้อกำหนด.
แหล่งข้อมูล
ได้จากการเปลี่ยนแปลงฟิลด์ 'State' หรือ 'Stage' ในตาราง เช่น 'sc_request' หรือ 'sc_req_item' หรือจากประวัติการตรวจสอบ (sys_audit).
ตัวอย่าง
สร้างคำขอบริการมอบหมายคำขอให้กลุ่มแก้ไขคำขอบริการแล้วขอข้อมูลเพิ่มเติมจากผู้ใช้
|
|||
|
รหัสคำขอบริการ
ServiceRequestID
|
รหัสเฉพาะของรายการคำขอบริการแต่ละรายการ. | ||
|
คำอธิบาย
Service Request ID เป็นคีย์หลักที่ใช้ระบุคำขอบริการแต่ละรายการที่ผู้ใช้หรือระบบส่งเข้ามาได้อย่างไม่ซ้ำกัน รหัสนี้เชื่อมโยงเหตุการณ์ทั้งหมด ตั้งแต่บันทึกคำขอครั้งแรกจนถึงปิดคำขอ ใน process mining รหัสนี้จำเป็นต่อการสร้างเส้นทางตั้งแต่ต้นจนจบของคำขอแต่ละรายการ เพื่อให้วิเคราะห์วงจรคำขอได้ครบถ้วน.
เหตุผลที่สำคัญ
นี่คือ Case ID ที่จำเป็นต้องมี ใช้เชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมดให้เป็นกระบวนการเดียวกัน เพื่อวิเคราะห์การไหลของกระบวนการ ความแตกต่าง และเวลาตั้งแต่ต้นจนจบได้.
แหล่งข้อมูล
ตาราง ServiceNow Request [sc_request] ฟิลด์ 'number'.
ตัวอย่าง
REQ0010001REQ0010025REQ0010112
|
|||
|
เวลาเริ่มต้น
EventTime
|
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เริ่มต้นเมื่อใด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกวันที่และเวลาที่เกิดกิจกรรมแต่ละรายการในกระบวนการคำขอบริการอย่างแม่นยำ ข้อมูลนี้แสดงลำดับเหตุการณ์ตามเวลา ซึ่งจำเป็นต่อการสร้างแผนผังกระบวนการและวิเคราะห์ข้อมูลตามช่วงเวลา. การบันทึกเวลาอย่างถูกต้องจำเป็นต่อการคำนวณเวลาตั้งแต่ต้นจนจบ เวลารอ และระยะเวลาดำเนินการ ข้อมูลนี้ช่วยระบุคอขวด การไม่เป็นไปตาม SLA และแนวโน้มประสิทธิภาพในแต่ละช่วงเวลา.
เหตุผลที่สำคัญ
ต้องมีเวลานี้เพื่อเรียงลำดับเหตุการณ์ให้ถูกต้อง และใช้เป็นพื้นฐานของการวิเคราะห์ประสิทธิภาพและระยะเวลา รวมถึงการคำนวณเวลาตั้งแต่ต้นจนจบและการระบุคอขวด.
แหล่งข้อมูล
โดยทั่วไปพบในฟิลด์ 'sys_updated_on' หรือ 'sys_created_on' ของตาราง ServiceNow ที่เกี่ยวข้อง เช่น sc_request และ sc_task หรือในประวัติการตรวจสอบ (sys_audit).
ตัวอย่าง
2023-04-15T10:00:00Z2023-04-15T11:30:15Z2023-04-16T09:05:45Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่เป็นแหล่งที่มาของข้อมูล. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุระบบต้นทางของข้อมูล ซึ่งในกรณีนี้คือ ServiceNow มีประโยชน์เมื่อนำข้อมูลจากหลายระบบมารวมกันเพื่อให้เห็นภาพกระบวนการโดยรวม. แม้วิเคราะห์ข้อมูลจากแหล่งเดียว แอตทริบิวต์นี้ก็ยังให้บริบทที่สำคัญ ช่วยกำกับดูแลและจัดการข้อมูล รวมถึงทำให้ผู้ใช้เข้าใจที่มาของข้อมูลที่กำลังวิเคราะห์.
เหตุผลที่สำคัญ
ให้ข้อมูลกำกับที่จำเป็นต่อการกำกับดูแลข้อมูล การตรวจสอบย้อนกลับ และการทำความเข้าใจบริบท โดยเฉพาะเมื่อนำข้อมูลจากระบบองค์กรหลายระบบมารวมกัน.
แหล่งข้อมูล
โดยทั่วไปเป็นค่าคงที่ที่เพิ่มระหว่างการดึงและแปลงข้อมูล.
ตัวอย่าง
ServiceNow
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่รีเฟรชหรือดึงข้อมูลครั้งล่าสุด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุวันที่และเวลาที่ดึงข้อมูลจากระบบต้นทางครั้งล่าสุดและโหลดเข้าสู่เครื่องมือ process mining ช่วยให้ทราบว่าข้อมูลที่กำลังวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด. นักวิเคราะห์ใช้ข้อมูลนี้ตรวจสอบว่ากำลังดูข้อมูลที่เป็นปัจจุบันหรือไม่ ซึ่งสำคัญต่อการติดตามการปฏิบัติการและการตัดสินใจได้ทันท่วงที อีกทั้งยังช่วยให้เข้าใจว่าข้อมูลเชิงลึกอ้างอิงจากข้อมูลล่าสุดเมื่อใด.
เหตุผลที่สำคัญ
ช่วยให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด ซึ่งจำเป็นต่อความเชื่อมั่นในการวิเคราะห์และการตัดสินใจโดยใช้ข้อมูลได้ทันท่วงที.
แหล่งข้อมูล
ฟิลด์ข้อมูลกำกับนี้เพิ่มระหว่างนำเข้าข้อมูล โดยระบุเวลาที่งาน ETL เสร็จสิ้น.
ตัวอย่าง
2023-10-27T04:00:00Z
|
|||
|
กลุ่มผู้รับผิดชอบ
AssignmentGroup
|
ทีมงานหรือกลุ่มที่รับผิดชอบจัดการคำขอบริการ. | ||
|
คำอธิบาย
Assignment Group คือทีมที่รับผิดชอบคำขอบริการในแต่ละขั้นตอน เช่น 'Service Desk', 'Network Operations' หรือ 'Database Administration' แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์การไหลของกระบวนการระหว่างหน่วยงาน. การติดตามการเปลี่ยน Assignment Group ช่วยให้องค์กรเห็นการส่งต่องานระหว่างทีม วัดเวลาที่งานค้างในคิวของแต่ละกลุ่ม และระบุการพึ่งพากันหรือความล่าช้าระหว่างทีม ข้อมูลนี้จำเป็นต่อการปรับปรุงการทำงานร่วมกันระหว่างหน่วยงาน.
เหตุผลที่สำคัญ
ติดตามการกระจายงานระหว่างทีม แสดงการส่งต่องานระหว่างทีม และช่วยระบุคอขวดหรือปัญหาด้านประสิทธิภาพของแต่ละทีม.
แหล่งข้อมูล
ตาราง ServiceNow Request Item [sc_req_item] หรือ Catalog Task [sc_task] ฟิลด์ 'assignment_group'
ตัวอย่าง
ศูนย์บริการฝ่ายสนับสนุน IT ระดับ 2จัดเตรียมอุปกรณ์ฮาร์ดแวร์
|
|||
|
เป็นไปตาม SLA
MadeSLA
|
ค่าบูลีนที่ระบุว่าคำขอบริการได้รับการแก้ไขภายในเวลาที่กำหนดใน Service Level Agreement หรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุว่าคำขอบริการได้รับการแก้ไขภายในเวลาที่กำหนดใน Service Level Agreement (SLA) หรือไม่ เป็นตัวชี้วัดผลลัพธ์สำคัญที่ใช้วัดผลการให้บริการเทียบกับข้อตกลงโดยตรง การวิเคราะห์ค่านี้ช่วยคำนวณ KPI อัตราการปฏิบัติตาม SLA และใช้เปรียบเทียบเส้นทางกระบวนการของคำขอที่เป็นไปตามข้อกำหนดกับคำขอที่ผิด SLA เพื่อค้นหารูปแบบหรือกิจกรรมที่มักทำให้ไม่เป็นไปตาม SLA ซึ่งจำเป็นต่อการติดตามความเสี่ยงล่วงหน้าและปรับปรุงบริการอย่างต่อเนื่อง.
เหตุผลที่สำคัญ
ใช้วัดผลการให้บริการเทียบกับข้อตกลงโดยตรง และช่วยวิเคราะห์สาเหตุที่ไม่เป็นไปตาม SLA ด้วยการเปรียบเทียบกรณีที่เป็นไปตามข้อกำหนดกับกรณีที่ไม่เป็นไปตามข้อกำหนด.
แหล่งข้อมูล
ตาราง ServiceNow Task SLA [task_sla] ฟิลด์ 'has_breached' ต้องกลับค่าของฟิลด์นี้ เช่น MadeSLA = NOT has_breached
ตัวอย่าง
truefalse
|
|||
|
มอบหมายให้
AssignedTo
|
ผู้ใช้ที่รับผิดชอบดำเนินการตามคำขอบริการในช่วงเวลาหนึ่ง. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุเจ้าหน้าที่หรือช่างเทคนิคที่ได้รับมอบหมายให้ดูแลคำขอบริการ และจะเปลี่ยนเมื่อมีการส่งต่องานระหว่างบุคคล. การวิเคราะห์ฟิลด์ 'Assigned To' จำเป็นต่อการทำความเข้าใจการกระจายงาน ประสิทธิภาพของแต่ละคน และผลของการส่งต่องานต่อเวลาแก้ไขคำขอ ช่วยให้เห็นการใช้ทรัพยากร และระบุโอกาสในการฝึกอบรมหรือปรับขั้นตอนให้ชัดเจนเพื่อลดการมอบหมายงานซ้ำ.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ปริมาณงาน ประสิทธิภาพ และการส่งต่องานของเจ้าหน้าที่ จำเป็นต่อการจัดการทรัพยากรและระบุคอขวดที่เกี่ยวข้องกับบุคคล.
แหล่งข้อมูล
ตาราง ServiceNow Request Item [sc_req_item] หรือ Catalog Task [sc_task] ฟิลด์ 'assigned_to'
ตัวอย่าง
Beth AnglinDavid LooHoward Johnson
|
|||
|
ลำดับความสำคัญ
Priority
|
ระดับความสำคัญของคำขอบริการ ซึ่งมีผลต่อความเร่งด่วนในการดำเนินการ. | ||
|
คำอธิบาย
ลำดับความสำคัญใช้จัดประเภทคำขอบริการตามความสำคัญและความเร่งด่วน โดยมักพิจารณาจากผลกระทบและความเร่งด่วนร่วมกัน เพื่อช่วยให้เจ้าหน้าที่รู้ว่าควรจัดการคำขอใดก่อน. การวิเคราะห์ข้อมูลตามลำดับความสำคัญจำเป็นต่อการตรวจสอบว่าคำขอที่มีความสำคัญสูงได้รับการดำเนินการเร็วกว่าคำขอที่มีความสำคัญต่ำหรือไม่ คุณสามารถกรองแดชบอร์ดเพื่อดูว่าคำขอเร่งด่วนเป็นไปตาม SLA หรือไม่ และประเมินได้ว่าการจัดลำดับความสำคัญมีประสิทธิภาพเพียงใด.
เหตุผลที่สำคัญ
ช่วยแบ่งกลุ่มคำขอเพื่อตรวจสอบว่ารายการที่มีความสำคัญสูงได้รับการดำเนินการเร็วกว่า จำเป็นต่อการวิเคราะห์ SLA และจัดสรรทรัพยากร.
แหล่งข้อมูล
ตาราง ServiceNow Request [sc_request] หรือ Request Item [sc_req_item] ฟิลด์ 'priority'.
ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
|
|||
|
สถานะ
State
|
สถานะปัจจุบันของคำขอบริการในการปฏิบัติงาน. | ||
|
คำอธิบาย
แอตทริบิวต์ State ระบุขั้นตอนปัจจุบันของคำขอบริการในวงจร เช่น 'Open', 'Work in Progress', 'Pending' หรือ 'Closed' การเปลี่ยนแปลงในฟิลด์นี้มักใช้สร้างกิจกรรมในแผนผังกระบวนการ. การวิเคราะห์ State จำเป็นต่อการทำความเข้าใจว่าคำขออยู่ในแต่ละสถานะนานเท่าใด โดยเฉพาะสถานะรอหรือค้างดำเนินการ ช่วยระบุคิวและความล่าช้า เช่น เวลาที่ใช้ในสถานะ 'Awaiting User Information' ซึ่งมักทำให้เวลาตั้งแต่ต้นจนจบยาวนานขึ้น.
เหตุผลที่สำคัญ
แสดงสถานะของคำขอในแต่ละช่วงเวลา ช่วยวิเคราะห์เวลารอ คิวงาน และระยะเวลาของแต่ละขั้นตอนในกระบวนการ.
แหล่งข้อมูล
ตาราง ServiceNow Request [sc_request] หรือ Request Item [sc_req_item] ฟิลด์ 'state' หรือ 'stage'.
ตัวอย่าง
เปิดกำลังดำเนินการรอข้อมูลจากผู้ใช้ปิดงานเรียบร้อย
|
|||
|
หมวดหมู่
Category
|
การจัดประเภทหลักของคำขอบริการ เช่น ฮาร์ดแวร์หรือซอฟต์แวร์. | ||
|
คำอธิบาย
หมวดหมู่ใช้จัดประเภทคำขอบริการในระดับภาพรวม โดยทั่วไปใช้ส่งคำขอไปยังทีมที่รับผิดชอบ และรายงานประเภทคำขอที่ส่งเข้ามา ใน process mining หมวดหมู่ช่วยกรองข้อมูลและวิเคราะห์แยกตามมิติได้ นักวิเคราะห์สามารถเปรียบเทียบขั้นตอนการทำงาน ระยะเวลาดำเนินการ และอัตราการทำงานอัตโนมัติของคำขอแต่ละประเภท เพื่อค้นหาความแตกต่างที่อาจมองไม่เห็นเมื่อดูข้อมูลรวม เช่น กระบวนการจัดการคำขอ 'ฮาร์ดแวร์' อาจแตกต่างจากคำขอ 'ซอฟต์แวร์' อย่างมาก.
เหตุผลที่สำคัญ
ช่วยแบ่งกลุ่มและเปรียบเทียบกระบวนการตามประเภทบริการ เพื่อค้นหาปัญหาและโอกาสในการปรับปรุงของแต่ละหมวดหมู่.
แหล่งข้อมูล
ตาราง ServiceNow Request Item [sc_req_item] โดยทั่วไปใช้หมวดหมู่ของ Catalog Item [sc_cat_item] ที่เกี่ยวข้อง.
ตัวอย่าง
ฮาร์ดแวร์ซอฟต์แวร์คำขอสิทธิ์การเข้าถึงเครือข่าย
|
|||
|
แก้ไขสำเร็จตั้งแต่ครั้งแรกหรือไม่
IsFirstPassResolution
|
ค่าที่ระบุว่าคำขอได้รับการแก้ไขตั้งแต่ครั้งแรกโดยไม่มีการเปิดอีกครั้งหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์นี้คำนวณเป็นค่าบูลีน โดยเป็น 'true' เฉพาะเมื่อคำขอบริการได้รับการแก้ไขและปิดแล้วโดยไม่มีการเปิดอีกครั้ง เป็นตัวชี้วัดสำคัญของคุณภาพและประสิทธิผลในการแก้ไขปัญหาของฝ่ายบริการ ตัวชี้วัดนี้ใช้คำนวณ KPI อัตราการแก้ไขสำเร็จตั้งแต่ครั้งแรก อัตราที่สูงเป็นผลดี เพราะแสดงถึงบริการที่มีประสิทธิภาพและมีคุณภาพ ซึ่งช่วยเพิ่มความพึงพอใจของลูกค้า การวิเคราะห์กรณีที่แก้ไขไม่สำเร็จตั้งแต่ครั้งแรกอาจช่วยค้นหาสาเหตุ เช่น การฝึกอบรมไม่เพียงพอ เอกสารไม่ชัดเจน หรือวินิจฉัยปัญหาเบื้องต้นไม่ถูกต้อง.
เหตุผลที่สำคัญ
ใช้วัดคุณภาพและประสิทธิภาพของกระบวนการแก้ไขปัญหา หากอัตราการแก้ไขสำเร็จตั้งแต่ครั้งแรกต่ำ แสดงว่าอาจมีปัญหาที่ทำให้ต้องแก้ไขซ้ำและสร้างความไม่พอใจให้ลูกค้า.
แหล่งข้อมูล
คำนวณในระดับเคส โดยถือว่าเคสแก้ไขสำเร็จตั้งแต่ครั้งแรกเมื่อค่า 'ReopenCount' เป็นศูนย์.
ตัวอย่าง
truefalse
|
|||
|
คะแนนความพึงพอใจ
SatisfactionScore
|
คะแนนความพึงพอใจที่ผู้ส่งคำขอให้เมื่อปิดคำขอ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกคะแนนความพึงพอใจ ซึ่งมักอยู่ในช่วง 1-5 ที่ผู้ใช้ปลายทางส่งหลังจากแก้ไขคำขอบริการแล้ว เป็นการวัดคุณภาพบริการตามการรับรู้ของผู้ใช้โดยตรง ข้อมูลนี้จำเป็นต่อแดชบอร์ดวิเคราะห์ผลกระทบต่อความพึงพอใจของลูกค้า ช่วยเชื่อมโยงตัวชี้วัดกระบวนการ เช่น ระยะเวลาดำเนินการ งานแก้ไขซ้ำ และการส่งต่องาน กับประสบการณ์ที่ลูกค้าได้รับ และแสดงให้เห็นว่าการปรับปรุงประสิทธิภาพการปฏิบัติงานส่งผลต่อผลลัพธ์ของลูกค้าอย่างไร.
เหตุผลที่สำคัญ
เชื่อมโยงตัวชี้วัดผลการดำเนินงานของกระบวนการกับผลลัพธ์ที่ลูกค้าได้รับโดยตรง ช่วยวัดผลกระทบของความไม่มีประสิทธิภาพต่อประสบการณ์ของผู้ใช้.
แหล่งข้อมูล
โดยทั่วไปอยู่ในตาราง Survey [asmt_assessment_instance] ที่เชื่อมโยงกับคำขอต้นทาง.
ตัวอย่าง
5431
|
|||
|
จำนวนครั้งที่เปิดคำขออีกครั้ง
ReopenCount
|
จำนวนครั้งที่เปิดคำขอบริการอีกครั้งหลังจากแก้ไขแล้ว. | ||
|
คำอธิบาย
แอตทริบิวต์นี้นับจำนวนครั้งที่คำขอบริการเปลี่ยนจากสถานะแก้ไขแล้วหรือปิดแล้ว กลับไปเป็นสถานะเปิดหรือกำลังดำเนินการ หากค่ามากกว่าศูนย์ แสดงว่าการแก้ไขครั้งแรกยังไม่สำเร็จ ตัวชี้วัดนี้บอกปริมาณงานแก้ไขซ้ำ และเป็นส่วนสำคัญของ KPI อัตราการแก้ไขสำเร็จตั้งแต่ครั้งแรก หากมีการเปิดคำขออีกหลายครั้ง อาจบ่งชี้ว่าการแก้ไขไม่มีคุณภาพ แก้ไขไม่ครบ หรือเข้าใจความต้องการของผู้ใช้ไม่ตรงกัน ซึ่งล้วนทำให้กระบวนการไม่มีประสิทธิภาพและผู้ใช้ไม่พึงพอใจ.
เหตุผลที่สำคัญ
ใช้วัดปริมาณงานแก้ไขซ้ำและคุณภาพการแก้ไข หากมีการเปิดคำขออีกหลายครั้ง มักสะท้อนถึงความไม่มีประสิทธิภาพ อัตราการแก้ไขสำเร็จตั้งแต่ครั้งแรกที่ต่ำ และความพึงพอใจของลูกค้าที่ลดลง.
แหล่งข้อมูล
ตาราง ServiceNow Request [sc_request] หรือ Request Item [sc_req_item] ฟิลด์ 'reopen_count'.
ตัวอย่าง
012
|
|||
|
ช่องทาง
ContactType
|
วิธีที่ผู้ส่งคำขอใช้ส่งคำขอบริการ. | ||
|
คำอธิบาย
Contact Type หรือช่องทาง ระบุว่ามีการเริ่มคำขอบริการผ่านช่องทางใด เช่น พอร์ทัลบริการ อีเมล โทรศัพท์ หรือการแจ้งเตือนอัตโนมัติ การทราบช่องทางช่วยวิเคราะห์ความแตกต่างของกระบวนการที่อาจเกิดจากวิธีส่งคำขอ เช่น คำขอผ่านพอร์ทัลอาจมีข้อมูลเป็นแบบแผนและทำงานอัตโนมัติได้มากกว่า จึงดำเนินการได้เร็วกว่าคำขอทางอีเมล การวิเคราะห์นี้ช่วยส่งเสริมให้ใช้ช่องทางที่มีประสิทธิภาพมากขึ้น.
เหตุผลที่สำคัญ
ช่วยให้เห็นว่าช่องทางส่งคำขอแต่ละแบบส่งผลต่อประสิทธิภาพกระบวนการ ระดับการทำงานอัตโนมัติ และระยะเวลาดำเนินการอย่างไร เพื่อใช้ปรับปรุงการติดต่อกับผู้ใช้.
แหล่งข้อมูล
ตาราง ServiceNow Request [sc_request] หรือ Interaction [interaction] โดยฟิลด์มักใช้ชื่อ 'contact_type'.
ตัวอย่าง
พอร์ทัลอีเมลโทรศัพท์บริการตนเอง
|
|||
|
ทำงานอัตโนมัติหรือไม่
IsAutomated
|
ค่าที่ระบุว่ากิจกรรมดำเนินการโดยระบบหรือระบบอัตโนมัติหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์บูลีนนี้ใช้แยกกิจกรรมที่เจ้าหน้าที่ดำเนินการเองออกจากกิจกรรมที่ระบบอัตโนมัติ เช่น เวิร์กโฟลว์หรือการเชื่อมต่อระบบเป็นผู้ดำเนินการ ตัวอย่างเช่น 'ส่งคำขออนุมัติ' อาจทำงานอัตโนมัติ ส่วน 'มอบหมายคำขอให้เจ้าหน้าที่' อาจต้องดำเนินการด้วยตนเอง การวิเคราะห์แอตทริบิวต์นี้ช่วยวัดและเพิ่มระดับการทำงานอัตโนมัติในกระบวนการจัดการคำขอบริการ อีกทั้งช่วยค้นหางานที่ต้องทำด้วยตนเองและใช้เวลามาก ซึ่งอาจนำไปทำงานอัตโนมัติในอนาคตเพื่อเพิ่มประสิทธิภาพและลดต้นทุน.
เหตุผลที่สำคัญ
ช่วยวัดอัตราการทำงานอัตโนมัติและค้นหาโอกาสในการทำงานที่ต้องทำด้วยตนเองให้เป็นอัตโนมัติ ซึ่งช่วยเพิ่มประสิทธิภาพและลดต้นทุนการปฏิบัติงาน.
แหล่งข้อมูล
คำนวณจากการตรวจสอบว่าผู้ใช้ที่ดำเนินการ เช่น 'sys_updated_by' เป็นบัญชีระบบหรือบัญชีเชื่อมต่อระบบที่กำหนดไว้หรือไม่.
ตัวอย่าง
truefalse
|
|||
|
เป็นงานแก้ไขซ้ำ
IsRework
|
ค่าที่คำนวณเพื่อระบุว่ากิจกรรมเป็นการทำซ้ำกิจกรรมก่อนหน้าในเคสเดียวกันหรือไม่. | ||
|
คำอธิบาย
ค่าบูลีนนี้คำนวณเพื่อค้นหาวงจรการทำงานซ้ำในคำขอบริการ โดยกำหนดเป็น 'true' หากกิจกรรมเดียวกันเกิดขึ้นก่อนหน้านี้ในเคสเดียวกัน เช่น มอบหมายคำขอให้ทีมเดิมสองครั้ง หรือขอข้อมูลจากผู้ใช้หลายครั้ง แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ดการส่งต่องานระหว่างเจ้าหน้าที่และเหตุการณ์งานแก้ไขซ้ำ รวมถึง KPI อัตราการแก้ไขซ้ำของคำขอ ช่วยแสดงและวัดปริมาณวงจรที่ไม่มีประสิทธิภาพในกระบวนการ ซึ่งมักมองไม่เห็นเมื่อดูข้อมูลรวม.
เหตุผลที่สำคัญ
ระบุและวัดปริมาณงานแก้ไขซ้ำในกระบวนการโดยตรง ช่วยวิเคราะห์สาเหตุและผลกระทบของวงจรที่ไม่มีประสิทธิภาพ ซึ่งทำให้ต้นทุนและระยะเวลาดำเนินการเพิ่มขึ้น.
แหล่งข้อมูล
คำนวณระหว่างการแปลงข้อมูล โดยตรวจสอบว่าชื่อกิจกรรมเดียวกันเคยเกิดขึ้นก่อนหน้าในเคสเดียวกันหรือไม่.
ตัวอย่าง
falsetrue
|
|||
|
ผู้เปิดคำขอ
OpenedBy
|
บุคคลที่ส่งคำขอบริการเป็นคนแรก. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุผู้ใช้ที่สร้างคำขอบริการ ซึ่งมักเป็นคนเดียวกับผู้ที่ได้รับผลกระทบจากคำขอ แต่อาจเป็นผู้จัดการ ผู้รับมอบหมาย หรือระบบอัตโนมัติก็ได้ การวิเคราะห์คำขอตามผู้ใช้หรือแผนกในฟิลด์ 'ผู้เปิดคำขอ' ช่วยให้เห็นรูปแบบ เช่น กลุ่มผู้ใช้ที่ส่งคำขอซับซ้อนหรือมีปัญหาบ่อยครั้ง ข้อมูลนี้ใช้วางแผนการฝึกอบรมให้ตรงกลุ่ม หรือชี้ให้เห็นว่าควรปรับปรุงบทความในฐานความรู้เพื่อให้ผู้ใช้แก้ปัญหาได้ด้วยตนเอง.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์รูปแบบคำขอตามผู้ใช้ แผนก หรือบทบาท เพื่อนำไปวางแผนการฝึกอบรมและปรับปรุงกระบวนการให้ตรงจุด.
แหล่งข้อมูล
ตาราง ServiceNow Request [sc_request] ฟิลด์ 'opened_by'.
ตัวอย่าง
Abel TuterFred LuddyDon Goodliffe
|
|||
|
รหัสการแก้ไข
ResolutionCode
|
รหัสที่ใช้จัดประเภทผลการแก้ไขคำขอบริการ. | ||
|
คำอธิบาย
รหัสการแก้ไขใช้จัดประเภทวิธีที่แก้ไขคำขอบริการจนเสร็จสิ้นอย่างเป็นแบบแผน ตัวอย่างเช่น 'ดำเนินการด้วยระบบอัตโนมัติ' 'ผู้ใช้ทำผิดพลาด' หรือ 'ไม่ต้องการแล้ว' แอตทริบิวต์นี้สำคัญต่อแดชบอร์ดวิเคราะห์สาเหตุหลักของความล่าช้า เมื่อนำรหัสการแก้ไขมาเทียบกับระยะเวลาดำเนินการที่นานหรืออัตราการแก้ไขซ้ำที่สูง นักวิเคราะห์จะค้นหาปัญหาเชิงระบบได้ เช่น หากคำขอที่มีรหัส 'ข้อมูลไม่ครบถ้วน' ใช้เวลานานอยู่เสมอ แสดงว่าอาจมีปัญหาในขั้นตอนรวบรวมข้อมูลเบื้องต้น.
เหตุผลที่สำคัญ
ให้ข้อมูลผลการแก้ไขในรูปแบบที่เป็นระบบ ช่วยวิเคราะห์สาเหตุหลักของความล่าช้า งานแก้ไขซ้ำ และความไม่มีประสิทธิภาพอื่นๆ ในกระบวนการ.
แหล่งข้อมูล
ตาราง ServiceNow Request Item [sc_req_item] หรือตารางงานที่เกี่ยวข้อง โดยฟิลด์มักใช้ชื่อ 'close_code' หรือ 'resolution_code'.
ตัวอย่าง
แก้ไขได้ถาวรแก้ไขไม่ได้ (ไม่สามารถทำซ้ำได้)ดำเนินการตามคำขอแล้วผู้ใช้ยกเลิก
|
|||
|
ระยะเวลาดำเนินการของเคส
CaseCycleTime
|
เวลาทั้งหมดตั้งแต่สร้างคำขอบริการจนถึงปิดคำขอในขั้นตอนสุดท้าย. | ||
|
คำอธิบาย
ระยะเวลาดำเนินการของเคสเป็นตัวชี้วัดที่คำนวณจากเวลาตั้งแต่เหตุการณ์แรกสุดจนถึงเหตุการณ์สุดท้ายสุด ใช้แสดงเวลาตั้งแต่ต้นจนจบที่ลูกค้าได้รับบริการ ตัวชี้วัดนี้เป็น KPI หลักสำหรับประสิทธิภาพโดยรวมของกระบวนการ ใช้ในแดชบอร์ดระดับภาพรวมเพื่อติดตามผลเทียบกับเป้าหมายและวิเคราะห์แนวโน้มตามช่วงเวลา นอกจากนี้ยังแยกดูตามมิติ เช่น หมวดหมู่หรือระดับความสำคัญ เพื่อค้นหาคำขอประเภทที่ใช้เวลานานที่สุดได้.
เหตุผลที่สำคัญ
KPI สำคัญที่ใช้วัดผลการดำเนินงานของกระบวนการตั้งแต่ต้นจนจบ จำเป็นต่อการติดตามผลในภาพรวม การเปรียบเทียบผลการดำเนินงาน และการค้นหาจุดที่ควรปรับปรุง.
แหล่งข้อมูล
คำนวณโดยนำค่า 'StartTime' ต่ำสุดมาลบออกจากค่า 'EndTime' สูงสุดของ 'ServiceRequestID' แต่ละรายการ.
ตัวอย่าง
2 10:30:000 04:15:2210 00:05:00
|
|||
|
เวลาสิ้นสุด
EndTime
|
เวลาที่ระบุว่ากิจกรรมหรือเหตุการณ์เสร็จสิ้นเมื่อใด. | ||
|
คำอธิบาย
เวลาสิ้นสุดระบุจุดที่กิจกรรมเสร็จสิ้น โดยใช้เวลาของกิจกรรมถัดไปในลำดับเป็นเวลาสิ้นสุดของกิจกรรมปัจจุบัน แอตทริบิวต์นี้จำเป็นต่อการคำนวณว่าแต่ละขั้นตอนใช้เวลานานเท่าใด. เมื่อนำเวลาเริ่มต้นและเวลาสิ้นสุดของกิจกรรมมาเปรียบเทียบ นักวิเคราะห์จะคำนวณเวลาทำงานและเวลารอได้ ข้อมูลนี้เป็นพื้นฐานในการระบุคอขวด วัดประสิทธิภาพการใช้ทรัพยากร และติดตามผลเทียบกับเป้าหมายด้านเวลา.
เหตุผลที่สำคัญ
แอตทริบิวต์นี้จำเป็นต่อการคำนวณระยะเวลาของแต่ละกิจกรรม ซึ่งเป็นส่วนสำคัญของการวิเคราะห์ประสิทธิภาพ การระบุคอขวด และการศึกษาการใช้ทรัพยากร.
แหล่งข้อมูล
แอตทริบิวต์นี้ได้จากการคำนวณ โดยใช้ 'StartTime' ของเหตุการณ์ถัดไปในเคส.
ตัวอย่าง
2023-04-15T10:05:10Z2023-04-15T11:45:00Z2023-04-16T09:15:30Z
|
|||
กิจกรรมในการจัดการคำขอบริการ
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
แก้ไขคำขอบริการแล้ว
|
กิจกรรมนี้แสดงว่าเจ้าหน้าที่ดำเนินงานเสร็จและให้แนวทางแก้ไขแล้ว ระบบบันทึกเหตุการณ์เมื่อเปลี่ยนสถานะคำขอเป็น 'Resolved' หรือสถานะที่มีความหมายใกล้เคียงกัน. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้มักเป็นจุดหยุดนับเวลา SLA แสดงจุดสิ้นสุดของการดำเนินงาน และเป็นส่วนสำคัญในการคำนวณเวลารวมจนแก้ไขเสร็จ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ใน sc_req_item เป็น 'Resolved' หรือสถานะสิ้นสุดที่มีความหมายใกล้เคียงกัน ก่อนปิดคำขอขั้นสุดท้าย โดยติดตามการเปลี่ยนแปลงในตาราง sys_audit.
บันทึก
ระบุเวลาที่ sc_req_item.state เปลี่ยนเป็น 'Resolved'.
ประเภทเหตุการณ์
inferred
|
|||
|
ขอข้อมูลเพิ่มเติมจากผู้ใช้
|
เกิดขึ้นเมื่อเจ้าหน้าที่ผู้ดำเนินการต้องการข้อมูลเพิ่มเติมจากผู้ส่งคำขอเพื่อทำงานต่อ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะคำขอเป็น 'Awaiting User Info' หรือสถานะที่มีความหมายใกล้เคียงกัน. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้จำเป็นต่อแดชบอร์ด 'Requestor Information Delay Analysis' ซึ่งช่วยวัดเวลาที่เสียไปกับการรอข้อมูลจากผู้ใช้.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ใน sc_req_item เป็นสถานะที่กำหนดให้รอข้อมูล โดยบันทึกการเปลี่ยนแปลงไว้ในตาราง sys_audit.
บันทึก
ระบุเวลาที่ sc_req_item.state เปลี่ยนเป็น 'Awaiting User Info'.
ประเภทเหตุการณ์
inferred
|
|||
|
ปิดคำขอบริการ
|
แสดงจุดสิ้นสุดของวงจรคำขอบริการอย่างเป็นทางการ โดยทั่วไประบบจะปิดคำขอโดยอัตโนมัติหลังจากอยู่ในสถานะ 'Resolved' ตามระยะเวลาที่กำหนด ซึ่งระหว่างนั้นผู้ใช้ยังเปิดคำขออีกครั้งได้. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์สิ้นสุดหลักเมื่อกระบวนการเสร็จสมบูรณ์ นอกจากนี้ยังวิเคราะห์เวลาระหว่าง 'Resolved' กับ 'Closed' เพื่อทำความเข้าใจนโยบายการปิดคำขออัตโนมัติได้.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ใน sc_req_item เป็นสถานะปิดขั้นสุดท้าย เช่น 'Closed Complete' โดยบันทึกเหตุการณ์ไว้ในตาราง sys_audit.
บันทึก
ระบุเวลาที่ sc_req_item.state เปลี่ยนเป็น 'Closed Complete'.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายคำขอให้เจ้าหน้าที่
|
กิจกรรมนี้เกิดขึ้นเมื่อมอบหมายคำขอบริการให้เจ้าหน้าที่รายใดรายหนึ่ง โดยติดตามการเปลี่ยนแปลงฟิลด์ 'Assigned to' ในคำขอหรืองานจัดส่งบริการที่เกี่ยวข้อง. | ||
|
เหตุผลที่สำคัญ
ข้อมูลนี้จำเป็นต่อการวัดการส่งต่องาน คำนวณปริมาณงานของเจ้าหน้าที่แต่ละคน และวิเคราะห์เวลาที่คำขออยู่ในคิวก่อนมีผู้เริ่มดำเนินการ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ assigned_to ในตาราง sc_req_item หรือ sc_task โดยบันทึกประวัติการเปลี่ยนแปลงไว้ในตาราง sys_audit.
บันทึก
ติดตามการเปลี่ยนแปลงฟิลด์ assigned_to ใน sys_audit.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างคำขอบริการ
|
กิจกรรมนี้เป็นจุดเริ่มต้นของวงจรคำขอบริการ โดยบันทึกเมื่อผู้ใช้ส่งคำขอผ่านแค็ตตาล็อกบริการ ระบบบันทึกเหตุการณ์นี้เมื่อสร้างรายการใหม่ในตาราง sc_req_item (Requested Item). | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ ซึ่งจำเป็นต่อการคำนวณเวลาตั้งแต่ต้นจนจบ รวมถึงวิเคราะห์ปริมาณและรูปแบบการส่งคำขอ.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรงจากเวลาที่สร้างรายการ (ฟิลด์ sys_created_on) ในตาราง sc_req_item.
บันทึก
ใช้เวลา sys_created_on จากรายการใน sc_req_item.
ประเภทเหตุการณ์
explicit
|
|||
|
อนุมัติคำขอแล้ว
|
กิจกรรมนี้แสดงว่าคำขอได้รับอนุมัติอย่างเป็นทางการและดำเนินการต่อในขั้นตอนจัดส่งบริการได้ ระบบบันทึกเหตุการณ์เมื่อผู้อนุมัติกำหนดสถานะรายการอนุมัติที่เกี่ยวข้องเป็น 'approved'. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สำคัญนี้แสดงการเปลี่ยนจากขั้นตอนอนุมัติไปสู่ขั้นตอนจัดส่งบริการ การวิเคราะห์เวลาที่ใช้จนถึงขั้นตอนนี้ช่วยให้เข้าใจความล่าช้าก่อนเริ่มดำเนินการ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ของรายการ sysapproval_approver ที่เกี่ยวข้องเป็น 'approved' ซึ่งจะทำให้สถานะของ sc_req_item เปลี่ยนตาม.
บันทึก
ระบุเวลาที่ sysapproval_approver.state เปลี่ยนเป็น 'approved'.
ประเภทเหตุการณ์
inferred
|
|||
|
ปฏิเสธคำขอ
|
กิจกรรมนี้แสดงผลลัพธ์เมื่อมีการปฏิเสธคำขออย่างเป็นทางการในขั้นตอนอนุมัติ ซึ่งเป็นอีกเส้นทางหนึ่งที่นำไปสู่การปิดคำขอ ระบบบันทึกเหตุการณ์เมื่อผู้อนุมัติกำหนดสถานะคำขอเป็น 'rejected'. | ||
|
เหตุผลที่สำคัญ
การติดตามคำขอที่ถูกปฏิเสธช่วยระบุคำขอที่ไม่ถูกต้องหรือส่งผิดหน่วยงาน ปัญหาในขั้นตอนส่งคำขอ และเส้นทางกรณียกเว้นที่ควรนำมาวิเคราะห์.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ของรายการ sysapproval_approver ที่เกี่ยวข้องเป็น 'rejected' ซึ่งโดยทั่วไปจะทำให้ sc_req_item หลักเปลี่ยนเป็นสถานะปิดและดำเนินการไม่สำเร็จ.
บันทึก
ระบุเวลาที่ sysapproval_approver.state เปลี่ยนเป็น 'rejected'.
ประเภทเหตุการณ์
inferred
|
|||
|
เปิดคำขออีกครั้ง
|
กิจกรรมนี้บันทึกกรณีที่คำขอซึ่งเคยระบุว่าแก้ไขแล้วกลับมาอยู่ในสถานะเปิด อนุมานได้จากการเปลี่ยนสถานะจาก 'Resolved' กลับเป็น 'Work in Progress' หรือสถานะที่มีความหมายใกล้เคียงกัน. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้ใช้วัดงานที่ต้องทำซ้ำโดยตรง และจำเป็นต่อการคำนวณ KPI 'First-Pass Resolution Rate' หากพบจำนวนมาก อาจหมายถึงคุณภาพการแก้ไขไม่ดีหรือแก้ไขไม่ครบถ้วน.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ใน sc_req_item จากสถานะแก้ไขแล้วหรือปิดแล้ว กลับไปเป็นสถานะเปิดหรือกำลังดำเนินการ โดยบันทึกการเปลี่ยนแปลงไว้ใน sys_audit.
บันทึก
ตรวจจับการเปลี่ยนสถานะจาก 'Resolved' เป็น 'Work in Progress' ใน sys_audit.
ประเภทเหตุการณ์
inferred
|
|||
|
ผู้ใช้ให้ข้อมูลแล้ว
|
กิจกรรมนี้แสดงจุดที่ผู้ส่งคำขอให้ข้อมูลที่ต้องการแล้ว อนุมานได้เมื่อคำขอเปลี่ยนจากสถานะ 'Awaiting User Info' กลับไปเป็นสถานะที่กำลังดำเนินการ เช่น 'Work in Progress'. | ||
|
เหตุผลที่สำคัญ
เมื่อนำมาวิเคราะห์คู่กับกิจกรรม 'ขอข้อมูลเพิ่มเติมจากผู้ใช้' จะช่วยวัดความล่าช้าที่เกิดจากการรอผู้ใช้ได้อย่างแม่นยำ และประเมินประสิทธิภาพของการสื่อสาร.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ใน sc_req_item จากสถานะรอข้อมูลเป็นสถานะที่กำลังดำเนินการ ซึ่งมักเกิดขึ้นเมื่อผู้ใช้เพิ่มความคิดเห็นหรือตอบกลับอีเมล.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนจาก 'Awaiting User Info' เป็น 'Work in Progress'.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายคำขอให้กลุ่ม
|
แสดงว่ามีการมอบหมายคำขอบริการให้ทีมจัดส่งบริการหรือกลุ่มที่กำหนด อนุมานเหตุการณ์นี้ได้จากการเปลี่ยนฟิลด์กลุ่มผู้รับผิดชอบในรายการคำขอหรืองานที่เกี่ยวข้อง. | ||
|
เหตุผลที่สำคัญ
การติดตามการมอบหมายให้กลุ่มช่วยวิเคราะห์การกระจายงานระหว่างทีม และระบุความล่าช้าก่อนส่งคำขอไปยังผู้รับผิดชอบที่เหมาะสม.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ assignment_group ในตาราง sc_req_item หรือ sc_task โดยบันทึกประวัติการเปลี่ยนแปลงไว้ในตาราง sys_audit.
บันทึก
ติดตามการเปลี่ยนแปลงฟิลด์ assignment_group ใน sys_audit.
ประเภทเหตุการณ์
inferred
|
|||
|
ยกเลิกคำขอ
|
กิจกรรมนี้เป็นสถานะสิ้นสุดของคำขอที่ถูกยกเลิกก่อนดำเนินการเสร็จ ไม่ว่าจะยกเลิกโดยผู้ใช้หรือเจ้าหน้าที่ ระบบบันทึกเหตุการณ์เมื่อกำหนดสถานะคำขอเป็น 'Cancelled' หรือ 'Closed Cancelled'. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์สิ้นสุดที่ไม่สำเร็จ การวิเคราะห์สาเหตุที่ยกเลิกคำขอช่วยให้เข้าใจความต้องการของผู้ใช้ จุดที่กระบวนการไม่มีประสิทธิภาพ หรือการเปลี่ยนแปลงลำดับความสำคัญทางธุรกิจ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ใน sc_req_item เป็นสถานะยกเลิกขั้นสุดท้าย เช่น 'Closed Cancelled' โดยบันทึกการเปลี่ยนแปลงไว้ในตาราง sys_audit.
บันทึก
ระบุเวลาที่ sc_req_item.state เปลี่ยนเป็น 'Cancelled'.
ประเภทเหตุการณ์
inferred
|
|||
|
ส่งคำขอเพื่อขออนุมัติ
|
แสดงจุดที่ส่งคำขอบริการให้ผู้จัดการหรือผู้มีอำนาจอนุมัติ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะคำขอเป็น 'Pending Approval' หรือสถานะที่มีความหมายใกล้เคียงกัน. | ||
|
เหตุผลที่สำคัญ
การติดตามการอนุมัติช่วยระบุคอขวดในขั้นตอนอนุมัติ และวัดเวลาที่คำขอต้องรอการอนุมัติก่อนเริ่มดำเนินการ.
แหล่งข้อมูล
อนุมานจากการเปลี่ยนฟิลด์ state ใน sc_req_item เป็นสถานะรออนุมัติ หรือจากการสร้างรายการที่เกี่ยวข้องในตาราง sysapproval_approver โดยบันทึกการเปลี่ยนแปลงไว้ในตาราง sys_audit.
บันทึก
ระบุเวลาที่ sc_req_item.state เปลี่ยนเป็น 'Pending Approval'.
ประเภทเหตุการณ์
inferred
|
|||
|
ส่งงานให้ผู้ให้บริการภายนอก
|
แสดงการส่งต่อคำขอบริการหรืองานที่เกี่ยวข้องให้ผู้ให้บริการภายนอกดำเนินการ อนุมานได้จากการมอบหมายให้กลุ่มของผู้ให้บริการ หรือจากการตั้งค่าสถานะในคำขอ. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้ช่วยวิเคราะห์ประสิทธิภาพของผู้ให้บริการและผลกระทบต่อวงจรคำขอโดยรวม ซึ่งจำเป็นต่อแดชบอร์ด 'External Vendor Engagement Cycle'.
แหล่งข้อมูล
โดยทั่วไปกิจกรรมนี้อนุมานจากการกำหนด assignment_group เป็นกลุ่มของผู้ให้บริการ หรือการตั้งค่าฟิลด์สถานะเฉพาะในรายการ sc_req_item หรือ sc_task.
บันทึก
ระบุการเปลี่ยน assignment_group เป็นกลุ่มผู้ให้บริการที่รู้จัก.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างงานจัดส่งบริการ
|
แสดงถึงการสร้างรายการงานหรืองานย่อยที่จำเป็นสำหรับดำเนินการตามคำขอบริการ ระบบจะบันทึกเหตุการณ์นี้โดยตรงเมื่อมีการสร้างระเบียนใหม่ในตาราง Catalog Task | ||
|
เหตุผลที่สำคัญ
สำหรับคำขอที่ซับซ้อน การวิเคราะห์เวลาสร้างและทำงานแต่ละรายการให้เสร็จช่วยให้เห็นรายละเอียดของขั้นตอนจัดส่งบริการและจุดที่เกิดความล่าช้า.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรงจากเวลาที่สร้างรายการ (ฟิลด์ sys_created_on) ในตาราง sc_task ซึ่งเชื่อมโยงกับ sc_req_item.
บันทึก
ใช้เวลา sys_created_on จากรายการใน sc_task.
ประเภทเหตุการณ์
explicit
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตนี้เพื่อเริ่มต้นโครงการ process mining และค้นหาโอกาสเพิ่มประสิทธิภาพในการจัดการคำขอบริการ เริ่มปรับปรุงเวิร์กโฟลว์วันนี้ เพื่อแก้ไขคำขอได้เร็วขึ้นและเพิ่มความพึงพอใจของลูกค้า.
ยกระดับการจัดการคำขอบริการ เริ่มลงมือวันนี้
ทำให้คำขอบริการเป็นระบบอัตโนมัติ 70% และแก้ไขได้เร็วขึ้น.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.