เทมเพลตข้อมูลการจัดการเหตุการณ์ของคุณ
เทมเพลตข้อมูลการจัดการเหตุการณ์ของคุณ
- แอตทริบิวต์ข้อมูลที่แนะนำให้รวบรวม
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางดึงข้อมูลจาก ServiceNow Problem Management
แอตทริบิวต์การจัดการเหตุการณ์
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
Incident ID
IncidentId
|
รหัสเฉพาะของระเบียนเหตุขัดข้องแต่ละรายการ ใช้เป็นคีย์หลักสำหรับติดตามวงจรทั้งหมด. | ||
|
คำอธิบาย
Incident ID คือหมายเลขอ้างอิงเฉพาะที่กำหนดให้กับเหตุขัดข้องทุกรายการใน ServiceNow ใช้ระบุเคสหลักและเชื่อมโยงกิจกรรม การอัปเดต และการสื่อสารที่เกี่ยวข้องทั้งหมด ตั้งแต่สร้างเหตุขัดข้องจนถึงปิดเคส. ในการวิเคราะห์ process mining รหัสนี้เป็นข้อมูลพื้นฐานที่ขาดไม่ได้ เพราะช่วยให้เครื่องมือเรียงเหตุการณ์ของแต่ละเคสเข้าด้วยกัน เพื่อค้นหาแผนผังกระบวนการ วิเคราะห์รูปแบบการดำเนินงาน และคำนวณระยะเวลาตั้งแต่ต้นจนจบ หากแต่ละเคสไม่มี Incident ID ที่ไม่ซ้ำกัน ก็จะติดตามเส้นทางการแก้ไขเหตุขัดข้องไม่ได้.
เหตุผลที่สำคัญ
นี่คือ Case ID สำคัญที่เชื่อมโยงเหตุการณ์ทั้งหมดตลอดวงจรเหตุขัดข้อง ทำให้วิเคราะห์กระบวนการตั้งแต่ต้นจนจบได้.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow, ฟิลด์ number.
ตัวอย่าง
INC0010001INC0010045INC0010239
|
|||
|
ชื่อกิจกรรม
ActivityName
|
ชื่อเหตุการณ์หรืองานที่เกิดขึ้น ณ ช่วงเวลาหนึ่งในวงจรเหตุขัดข้อง. | ||
|
คำอธิบาย
ชื่อกิจกรรมใช้ระบุขั้นตอนหรือการเปลี่ยนสถานะในกระบวนการจัดการเหตุขัดข้อง เช่น 'สร้างเหตุขัดข้อง', 'มอบหมายให้เจ้าหน้าที่' หรือ 'ปิดเหตุขัดข้อง' โดยทั่วไปข้อมูลนี้ได้มาจากการเปลี่ยนแปลงฟิลด์สำคัญ เช่น 'State' หรือ 'Assignment Group' หรือจากรายการบันทึกเฉพาะ. ข้อมูลนี้จำเป็นต่อการสร้างแผนผังกระบวนการ เพราะใช้กำหนดจุดต่างๆ ในแผนภาพ ช่วยให้นักวิเคราะห์เห็นเส้นทางของเหตุขัดข้อง ระบุเส้นทางที่พบบ่อย ค้นหาคอขวดระหว่างกิจกรรม และวิเคราะห์รูปแบบของกระบวนการ ความละเอียดและความถูกต้องของชื่อกิจกรรมส่งผลโดยตรงต่อคุณภาพการวิเคราะห์.
เหตุผลที่สำคัญ
ใช้กำหนดขั้นตอนในแผนผังกระบวนการ ซึ่งเป็นพื้นฐานของการวิเคราะห์และการแสดงผล process mining ทั้งหมด.
แหล่งข้อมูล
คุณลักษณะนี้ได้มาจากการประมวลผล โดยทั่วไปสร้างจากตรรกะการแปลงข้อมูลที่อ้างอิงการเปลี่ยนแปลงฟิลด์ เช่น state, assignment_group และ assigned_to ในตาราง sys_audit หรือ incident.
ตัวอย่าง
สร้างเหตุขัดข้องเปลี่ยนกลุ่มผู้รับผิดชอบเสนอวิธีแก้ไขปิดเหตุขัดข้อง
|
|||
|
เวลาเกิดเหตุการณ์
EventTime
|
เวลาที่ระบุอย่างแม่นยำว่ากิจกรรมเกิดขึ้นเมื่อใด. | ||
|
คำอธิบาย
เวลาเกิดเหตุการณ์ หรือที่มักเรียกว่า timestamp ใช้บันทึกวันที่และเวลาที่กิจกรรมเสร็จสิ้นหรือสถานะเปลี่ยนแปลงอย่างแม่นยำ ใน ServiceNow โดยทั่วไปจะบันทึกไว้ในฟิลด์ sys_updated_on สำหรับการเปลี่ยนแปลงแต่ละครั้งในประวัติการตรวจสอบ. ข้อมูลนี้จำเป็นต่อการเรียงเหตุการณ์ให้ถูกลำดับและการวิเคราะห์ด้านเวลา ใช้คำนวณระยะเวลาของกระบวนการ เวลารอคิว และช่วงเวลาระหว่างกิจกรรม ซึ่งเป็นข้อมูลพื้นฐานในการค้นหาคอขวด วัดผลเทียบกับ SLA และทำความเข้าใจประสิทธิภาพของกระบวนการ ความถูกต้องของ timestamp มีผลโดยตรงต่อความน่าเชื่อถือของตัวชี้วัดด้านระยะเวลา.
เหตุผลที่สำคัญ
timestamp นี้ใช้เรียงกิจกรรมตามลำดับเวลาและคำนวณตัวชี้วัดที่อิงระยะเวลาทั้งหมด เช่น ระยะเวลาของกระบวนการและคอขวด.
แหล่งข้อมูล
ใช้ฟิลด์ sys_created_on จากตาราง sys_audit ของ ServiceNow หรือใช้ฟิลด์ sys_updated_on จากตาราง incident สำหรับสถานะล่าสุด.
ตัวอย่าง
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ใช้ดึงข้อมูลนี้. | ||
|
คำอธิบาย
คุณลักษณะนี้ระบุแหล่งที่มาของข้อมูลเหตุขัดข้อง ซึ่งในกรณีนี้คือ ServiceNow Problem Management โดยทั่วไปจะเพิ่มค่าแบบคงที่ระหว่างการดึงและแปลงข้อมูล. เมื่อวิเคราะห์ข้อมูลจากหลายระบบ ฟิลด์นี้จำเป็นต่อการติดตามที่มาของข้อมูลและแยกข้อมูลตามแหล่งที่มา ช่วยให้วิเคราะห์ตัวชี้วัดและกระบวนการในบริบทที่ถูกต้อง รวมถึงเปรียบเทียบกระบวนการจากระบบต้นทางต่างๆ ได้.
เหตุผลที่สำคัญ
ช่วยระบุที่มาของข้อมูล ซึ่งจำเป็นต่อการติดตามที่มาของข้อมูลและการตีความอย่างถูกต้องเมื่อใช้ข้อมูลจากหลายระบบ.
แหล่งข้อมูล
โดยทั่วไปจะเพิ่มค่าแบบคงที่ระหว่างการดึงข้อมูล.
ตัวอย่าง
การจัดการปัญหาใน ServiceNowServiceNow
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ระบุว่าข้อมูลของระเบียนนี้ได้รับการรีเฟรชจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
คุณลักษณะนี้บันทึกวันที่และเวลาที่ดึงหรืออัปเดตข้อมูลจาก ServiceNow ล่าสุด เป็นฟิลด์ข้อมูลกำกับที่แสดงความใหม่ของข้อมูลที่นำมาวิเคราะห์ ไม่ใช่เหตุการณ์ในกระบวนการ. ข้อมูลนี้ช่วยให้ทราบว่าการวิเคราะห์เป็นปัจจุบันเพียงใด ผู้ใช้จึงประเมินได้ว่าข้อมูลใหม่แค่ไหน ซึ่งสำคัญต่อแดชบอร์ดการปฏิบัติการและการตัดสินใจจากเหตุการณ์ล่าสุด อีกทั้งช่วยให้เข้าใจว่าข้อมูลยังเกี่ยวข้องและทันสมัยอยู่หรือไม่.
เหตุผลที่สำคัญ
ช่วยให้ผู้ใช้ทราบว่าข้อมูลใหม่แค่ไหน ซึ่งสำคัญต่อความเกี่ยวข้องและความถูกต้องของการวิเคราะห์.
แหล่งข้อมูล
เครื่องมือหรือกระบวนการดึงข้อมูลจะสร้างและกำหนด timestamp นี้เมื่อโหลดข้อมูล.
ตัวอย่าง
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Priority
Priority
|
ระดับความสำคัญของเหตุขัดข้อง ซึ่งกำหนดความเร่งด่วนในการตอบสนอง. | ||
|
คำอธิบาย
Priority เป็นฟิลด์สำคัญใน ServiceNow ที่กำหนดลำดับและความเร็วในการจัดการเหตุขัดข้อง โดยทั่วไปคำนวณจากผลกระทบและความเร่งด่วนของเหตุขัดข้อง และส่งผลโดยตรงต่อเป้าหมาย SLA. คุณลักษณะนี้เป็นพื้นฐานสำคัญสำหรับการแบ่งกลุ่มและวิเคราะห์ผล แดชบอร์ด 'ภาพรวมการปฏิบัติตาม SLA' ใช้ Priority ประเมินว่าเหตุขัดข้องที่มีความสำคัญสูงได้รับการแก้ไขภายในเวลาที่กำหนดหรือไม่ การวิเคราะห์ระยะเวลาของกระบวนการแยกตาม Priority ช่วยยืนยันว่าเหตุขัดข้องระดับวิกฤตได้รับการจัดการเร็วกว่ากรณีที่สำคัญน้อยกว่าจริงหรือไม่ นอกจากนี้ยังเป็นมิติสำคัญสำหรับ KPI และแดชบอร์ดเกือบทุกประเภท.
เหตุผลที่สำคัญ
ช่วยแบ่งกลุ่มเหตุขัดข้องตามความสำคัญต่อธุรกิจ ซึ่งจำเป็นต่อการติดตามการปฏิบัติตาม SLA และการจัดสรรทรัพยากร.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow, ฟิลด์ priority.
ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
|
|||
|
กลุ่มผู้รับผิดชอบ
AssignmentGroup
|
ทีมสนับสนุนหรือกลุ่มที่รับผิดชอบจัดการเหตุขัดข้อง. | ||
|
คำอธิบาย
กลุ่มผู้รับผิดชอบหมายถึงทีมเจ้าหน้าที่ที่ได้รับมอบหมายให้แก้ไขเหตุขัดข้อง โดยมักส่งเหตุขัดข้องต่อระหว่างกลุ่มต่างๆ เช่น จากทีมช่วยเหลือระดับ 1 ไปยังทีมเครือข่ายเฉพาะทางระดับ 2. คุณลักษณะนี้จำเป็นต่อการวิเคราะห์การส่งต่องานระหว่างทีมและค้นหาคอขวดที่เกิดซ้ำในระบบ แดชบอร์ด 'อัตราการส่งต่องานและการมอบหมายใหม่' ใช้ข้อมูลนี้เพื่อแสดงว่าทีมใดเกี่ยวข้องกับการโอนงานบ่อย อีกทั้งยังช่วยเปรียบเทียบผลงานระหว่างกลุ่มสนับสนุนและทำความเข้าใจว่าความเชี่ยวชาญในการแก้ไขปัญหาอยู่ที่ใดในองค์กร.
เหตุผลที่สำคัญ
ใช้ติดตามว่าทีมใดรับผิดชอบ ช่วยวิเคราะห์ผลงานและภาระงานของทีม รวมถึงการส่งต่องานระหว่างกลุ่ม.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow, ฟิลด์ assignment_group.
ตัวอย่าง
ศูนย์บริการทีมสนับสนุนเครือข่ายผู้ดูแลระบบฐานข้อมูล
|
|||
|
ผู้รับมอบหมาย
AssignedTo
|
ผู้ใช้หรือเจ้าหน้าที่ที่ได้รับมอบหมายให้ดำเนินการกับเหตุขัดข้องในขณะนั้น. | ||
|
คำอธิบาย
คุณลักษณะนี้ระบุเจ้าหน้าที่สนับสนุนที่รับผิดชอบเหตุขัดข้อง ณ ช่วงเวลาหนึ่ง ข้อมูลนี้สำคัญต่อการทำความเข้าใจการกระจายภาระงาน ผลงานของเจ้าหน้าที่ และการส่งต่องานระหว่างบุคคล. ในการวิเคราะห์ 'ผู้รับมอบหมาย' ช่วยให้เห็นการจัดสรรทรัพยากรและระบุเจ้าหน้าที่ที่มีภาระงานมากเกินไป อีกทั้งใช้ในแดชบอร์ดการส่งต่องานและการมอบหมายใหม่ เพื่อติดตามจำนวนครั้งที่เปลี่ยนผู้รับผิดชอบรายบุคคล ซึ่งอาจบ่งชี้ถึงความไม่มีประสิทธิภาพหรือช่องว่างด้านความรู้ การวิเคราะห์เวลาแก้ไขแยกตามเจ้าหน้าที่ยังช่วยให้เห็นผู้ที่ทำผลงานได้ดีและผู้ที่อาจต้องได้รับการฝึกอบรมเพิ่มเติม.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ภาระงาน ผลงานของเจ้าหน้าที่ และการส่งต่องานระหว่างบุคคล ซึ่งเป็นข้อมูลสำคัญในการทำความเข้าใจประสิทธิภาพการใช้ทรัพยากร.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow, ฟิลด์ assigned_to.
ตัวอย่าง
Beth AnglinDavid LooHoward Johnson
|
|||
|
สถานะเหตุขัดข้อง
IncidentState
|
สถานะปัจจุบันของเหตุขัดข้องในวงจรการดำเนินงาน. | ||
|
คำอธิบาย
สถานะเหตุขัดข้องแสดงขั้นตอนปัจจุบัน เช่น 'New', 'In Progress', 'On Hold' หรือ 'Resolved' การเปลี่ยนสถานะมักเป็นแหล่งข้อมูลหลักในการสร้างกิจกรรมในบันทึกเหตุการณ์สำหรับ process mining. การวิเคราะห์เวลาที่ใช้ในแต่ละสถานะช่วยค้นหาคอขวดได้ ตัวอย่างเช่น หากอยู่ในสถานะ 'On Hold' นาน อาจหมายถึงต้องรอปัจจัยภายนอกหรือผู้ใช้ ลำดับการเปลี่ยนสถานะยังเป็นพื้นฐานของแผนผังกระบวนการ ซึ่งแสดงให้เห็นว่าเหตุขัดข้องดำเนินไปสู่การแก้ไขอย่างไร.
เหตุผลที่สำคัญ
ใช้ติดตามความคืบหน้าของเหตุขัดข้อง และเป็นข้อมูลสำคัญในการวิเคราะห์เวลาที่ใช้ในแต่ละขั้นตอนและค้นหาคอขวดของกระบวนการ.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow, ฟิลด์ incident_state หรือ state.
ตัวอย่าง
ใหม่กำลังดำเนินการรอข้อมูลจากผู้ใช้แก้ไขแล้วปิดแล้ว
|
|||
|
Configuration Item
ConfigurationItem
|
องค์ประกอบ บริการ หรือทรัพย์สินด้าน IT ที่ได้รับผลกระทบจากเหตุการณ์. | ||
|
คำอธิบาย
Configuration Item (CI) คือทรัพย์สินในฐานข้อมูล Configuration Management Database (CMDB) ที่ได้รับผลกระทบจากเหตุการณ์ เช่น เซิร์ฟเวอร์ แอปพลิเคชัน แล็ปท็อป หรืออุปกรณ์เครือข่าย การวิเคราะห์เหตุการณ์แยกตาม CI ช่วยระบุทรัพย์สินหรือบริการที่มีปัญหาบ่อยได้อย่างมีประโยชน์ คุณจะเห็นว่าองค์ประกอบใดในโครงสร้างพื้นฐาน IT ทำให้เกิดเหตุการณ์มากที่สุด และใช้ข้อมูลนี้ประกอบการตัดสินใจลงทุนอัปเกรดหรือเปลี่ยนอุปกรณ์ ใน process mining การกรองตาม CI ยังช่วยตรวจสอบได้ว่าเหตุการณ์ที่เกี่ยวข้องกับแอปพลิเคชันสำคัญได้รับการจัดการต่างจากเหตุการณ์อื่นหรือไม่ และดำเนินการได้มีประสิทธิภาพกว่าหรือไม่.
เหตุผลที่สำคัญ
ใช้ระบุทรัพย์สินที่ได้รับผลกระทบ ช่วยชี้องค์ประกอบที่มีปัญหาในโครงสร้างพื้นฐาน IT และกำหนดจุดที่ควรปรับปรุงได้ตรงจุด.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow ฟิลด์ cmdb_ci.
ตัวอย่าง
SAP ERP ProductionOracle DB Server 05บริการอีเมล
|
|||
|
Problem ID
ProblemId
|
รหัสของระเบียน Problem ที่เกี่ยวข้อง หากเหตุการณ์เชื่อมโยงกับปัญหาที่ใหญ่กว่า. | ||
|
คำอธิบาย
Problem ID ใช้เชื่อมโยงเหตุการณ์กับระเบียนที่เกี่ยวข้องในโมดูล Problem Management เมื่อพบว่าเหตุการณ์เป็นอาการของปัญหาพื้นฐานที่ใหญ่กว่า ซึ่งส่งผลกระทบต่อผู้ใช้หรือบริการหลายราย การเชื่อมโยงนี้สำคัญต่อแดชบอร์ด 'ปริมาณเหตุการณ์ที่เกิดซ้ำ' และ KPI 'อัตราเหตุการณ์ที่เกิดซ้ำ' นักวิเคราะห์สามารถจัดกลุ่มเหตุการณ์ที่มีสาเหตุเดียวกัน วัดผลกระทบทั้งหมดของปัญหา และติดตามผลการแก้ไขปัญหาได้ หากมีเหตุการณ์จำนวนมากเชื่อมโยงกับปัญหา แสดงว่าทีมสนับสนุนอาจต้องรับมือกับปัญหาหลังเกิดขึ้นเป็นหลัก.
เหตุผลที่สำคัญ
ใช้เชื่อมโยงเหตุการณ์กับสาเหตุที่แท้จริง ซึ่งจำเป็นต่อการวิเคราะห์ปัญหาที่เกิดซ้ำและวัดผลกระทบของการจัดการปัญหา.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow ฟิลด์ problem_id.
ตัวอย่าง
PRB0040001PRB0040015PRB0040102
|
|||
|
กำหนดส่งตาม SLA
SlaDueDate
|
วันและเวลาที่คาดว่าจะแก้ไขเหตุการณ์เสร็จตาม SLA. | ||
|
คำอธิบาย
กำหนดส่งตาม SLA คือเวลาที่คำนวณไว้เพื่อระบุเส้นตายในการแก้ไขเหตุการณ์ โดยกำหนดจากข้อตกลงระดับการให้บริการ (SLA) ที่เกี่ยวข้องกับลักษณะของเหตุการณ์ เช่น ลำดับความสำคัญ แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'ภาพรวมการปฏิบัติตาม SLA' และ KPI 'อัตราเหตุการณ์สำคัญที่ผิด SLA' โดยใช้เป็นเกณฑ์เปรียบเทียบกับเวลาแก้ไขจริง การวิเคราะห์เหตุการณ์ที่ใกล้ถึงกำหนดส่งตาม SLA ช่วยให้ยกระดับปัญหาและจัดลำดับความสำคัญได้ล่วงหน้า.
เหตุผลที่สำคัญ
ระบุเป้าหมายเวลาแก้ไข ทำให้วัดการปฏิบัติตาม SLA และค้นหาเหตุการณ์ที่เสี่ยงเกินกำหนดได้.
แหล่งข้อมูล
โดยทั่วไป ค่านี้อยู่ในตาราง task_sla ซึ่งเชื่อมโยงกับตาราง incident โดยฟิลด์ planned_end_time คือเวลาที่เกี่ยวข้อง.
ตัวอย่าง
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
|
|||
|
ความรุนแรง
Severity
|
ระดับผลกระทบทางธุรกิจที่เกิดจากเหตุการณ์. | ||
|
คำอธิบาย
ระดับความรุนแรงระบุว่าเหตุการณ์ส่งผลกระทบต่อการดำเนินงานของธุรกิจมากเพียงใด โดยมักใช้ร่วมกับความเร่งด่วนเพื่อคำนวณลำดับความสำคัญของเหตุการณ์โดยอัตโนมัติ ในการวิเคราะห์ ระดับความรุนแรงเป็นมิติสำคัญของแดชบอร์ด 'ภาพรวมการปฏิบัติตาม SLA' ช่วยให้องค์กรตรวจสอบได้ว่าบรรลุระดับบริการที่กำหนดสำหรับเหตุการณ์ที่กระทบการดำเนินงานมากที่สุดหรือไม่ และช่วยให้เห็นผลการดำเนินงานจากมุมมองธุรกิจ เสริมข้อมูลด้านการปฏิบัติการที่ได้จากลำดับความสำคัญ.
เหตุผลที่สำคัญ
ใช้วัดผลกระทบทางธุรกิจของเหตุการณ์ เป็นข้อมูลสำคัญสำหรับจัดลำดับการดำเนินงานและวิเคราะห์ผลการจัดการปัญหาสำคัญ.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow ฟิลด์ severity.
ตัวอย่าง
1 - สูง2 - ปานกลาง3 - ต่ำ
|
|||
|
จำนวนครั้งที่มอบหมายใหม่
ReassignmentCount
|
จำนวนครั้งที่มีการมอบหมายเหตุการณ์ให้กลุ่มหรือเจ้าหน้าที่รายอื่น. | ||
|
คำอธิบาย
ฟิลด์นี้บันทึกจำนวนครั้งทั้งหมดที่มีการโอนเหตุการณ์ระหว่างกลุ่มผู้รับผิดชอบ ใช้วัดความติดขัดในกระบวนการโดยตรง และมักนำไปใช้เป็นตัวชี้วัดผลการดำเนินงาน แอตทริบิวต์นี้เป็นข้อมูลหลักของแดชบอร์ด 'อัตราการส่งต่องานและการมอบหมายใหม่' และ KPI 'จำนวนครั้งเฉลี่ยที่ส่งต่องานต่อเหตุการณ์' หากมีการมอบหมายใหม่หลายครั้ง อาจเกิดจากการส่งงานผิดกลุ่มตั้งแต่แรก ทีมสนับสนุนขาดทักษะที่จำเป็น หรือไม่มีผู้รับผิดชอบกระบวนการที่ชัดเจน การลดจำนวนครั้งนี้เป็นเป้าหมายที่พบบ่อยในการปรับปรุงกระบวนการ เพราะมักช่วยให้แก้ไขเหตุการณ์ได้เร็วขึ้น.
เหตุผลที่สำคัญ
ใช้วัดการส่งต่องานในกระบวนการโดยตรง ซึ่งเป็นตัวบ่งชี้สำคัญของความไม่มีประสิทธิภาพ การส่งงานผิดกลุ่ม และโอกาสในการปรับปรุง.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow ฟิลด์ reassignment_count.
ตัวอย่าง
0135
|
|||
|
เปิดเหตุการณ์อีกครั้งหรือไม่
IsReopened
|
ตัวบ่งชี้ว่าเปิดเหตุการณ์อีกครั้งหลังจากแก้ไขแล้วหรือไม่. | ||
|
คำอธิบาย
ค่านี้เป็น true เมื่อสถานะของเหตุการณ์เปลี่ยนกลับไปเป็นสถานะที่ยังดำเนินอยู่ เช่น 'กำลังดำเนินการ' หลังจากเปลี่ยนเป็น 'แก้ไขแล้ว' หรือ 'ปิดแล้ว' โดยทั่วไปจะตรวจสอบจากกิจกรรม 'เปิดเหตุการณ์อีกครั้ง' ในบันทึกเหตุการณ์ เหตุการณ์ที่เปิดขึ้นอีกครั้งมักบ่งชี้ว่าการแก้ไขยังไม่สมบูรณ์หรือไม่ได้ผล การวิเคราะห์กรณีเหล่านี้ช่วยค้นหาการปิดเหตุการณ์ก่อนเวลา หรือปัญหาที่เกิดซ้ำและยังแก้ไม่ตรงจุด หากอัตราการเปิดเหตุการณ์อีกครั้งสูง อาจกระทบความพึงพอใจของผู้ใช้และประสิทธิภาพของทีม จึงเป็นตัวชี้วัดสำคัญสำหรับควบคุมคุณภาพ.
เหตุผลที่สำคัญ
ตัวบ่งชี้นี้ช่วยค้นหาจุดบกพร่องในกระบวนการแก้ไข โดยแสดงเหตุการณ์ที่ต้องดำเนินการเพิ่มเติมหลังจากระบุว่าแก้ไขแล้ว.
แหล่งข้อมูล
คำนวณโดยตรวจสอบลำดับกิจกรรมของแต่ละเหตุการณ์ เพื่อดูว่ามีสถานะ 'เปิด' ตามหลังสถานะ 'แก้ไขแล้ว' หรือไม่.
ตัวอย่าง
truefalse
|
|||
|
ผิด SLA หรือไม่
IsSlaBreached
|
ตัวบ่งชี้ว่าแก้ไขเหตุการณ์เกินกำหนดส่งตาม SLA หรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์แบบบูลีนที่คำนวณขึ้นเพื่อระบุว่าเหตุการณ์ผิดข้อตกลงระดับการให้บริการหรือไม่ โดยเปรียบเทียบเวลาที่แก้ไขจริงกับ 'กำหนดส่งตาม SLA' หากแก้ไขหลังวันและเวลาที่กำหนด ค่านี้จะเป็น true แอตทริบิวต์นี้เป็นข้อมูลพื้นฐานของแดชบอร์ด 'ภาพรวมการปฏิบัติตาม SLA' และ KPI ที่เกี่ยวข้อง ช่วยให้วิเคราะห์ได้ง่ายขึ้น โดยแปลงการเปรียบเทียบเวลาที่ซับซ้อนให้เป็นค่า true/false คุณจึงกรองเหตุการณ์ที่ผิด SLA และวิเคราะห์ลักษณะที่พบร่วมกัน เช่น หมวดหมู่ กลุ่มผู้รับผิดชอบ หรือลำดับความสำคัญได้สะดวก.
เหตุผลที่สำคัญ
ช่วยให้วิเคราะห์การปฏิบัติตาม SLA ได้ง่ายขึ้น โดยกรองและเจาะลึกเหตุการณ์ที่ไม่บรรลุเป้าหมายได้สะดวก.
แหล่งข้อมูล
คำนวณโดยเปรียบเทียบเวลาประทับ 'Resolved At' กับเวลาประทับ 'SlaDueDate' (Resolved At > SlaDueDate).
ตัวอย่าง
truefalse
|
|||
|
ผู้แจ้งเหตุ
CallerId
|
ผู้ใช้ที่แจ้งเหตุการณ์เป็นคนแรก. | ||
|
คำอธิบาย
ผู้แจ้งเหตุคือผู้ใช้ปลายทางหรือลูกค้าที่ได้รับผลกระทบจากเหตุการณ์และเป็นผู้รายงาน ข้อมูลนี้ช่วยให้ทราบว่าใครได้รับผลกระทบจากการหยุดชะงักของบริการ แม้ข้อมูลนี้จะไม่ได้เกี่ยวข้องโดยตรงกับลำดับขั้นตอนของกระบวนการเสมอไป แต่การวิเคราะห์เหตุการณ์แยกตามผู้แจ้งเหตุอาจช่วยให้พบว่าบุคคลหรือแผนกใดได้รับผลกระทบมากเป็นพิเศษ ซึ่งอาจชี้ถึงความจำเป็นในการอบรมหรือปัญหาเฉพาะในสภาพแวดล้อมการทำงาน นอกจากนี้ยังช่วยให้ติดต่อผู้ใช้เพื่อสำรวจความพึงพอใจและแจ้งความคืบหน้าได้โดยตรง.
เหตุผลที่สำคัญ
ระบุผู้ใช้ที่ได้รับผลกระทบ ช่วยวิเคราะห์แยกตามแผนกหรือบุคคล และให้ข้อมูลประกอบการสื่อสารกับผู้ใช้.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow ฟิลด์ caller_id.
ตัวอย่าง
Abel TuterCarolina PashDon Goodliffe
|
|||
|
รหัสวิธีแก้ไข
ResolutionCode
|
รหัสที่ระบุวิธีแก้ไขเหตุขัดข้องในท้ายที่สุด. | ||
|
คำอธิบาย
รหัสวิธีแก้ไขระบุลักษณะของวิธีแก้ปัญหาที่ใช้ เช่น ผู้ใช้แก้ไขเอง แก้ไขด้วยวิธีที่ทราบอยู่แล้ว หรือใช้วิธีแก้ปัญหาชั่วคราว โดยทั่วไปเจ้าหน้าที่จะกรอกฟิลด์นี้เมื่อปิดเหตุขัดข้อง. คุณลักษณะนี้ช่วยสนับสนุนแดชบอร์ด 'ประสิทธิผลของวิธีแก้ไข' โดยใช้วิเคราะห์จำนวนเหตุขัดข้องที่ปิดด้วยวิธีแก้ไขถาวรเทียบกับวิธีแก้ปัญหาชั่วคราว ซึ่งเป็นตัวชี้วัดสำคัญของคุณภาพบริการและเสถียรภาพในระยะยาว หากใช้วิธีแก้ปัญหาชั่วคราวบ่อย อาจหมายถึงยังจัดการปัญหาที่อยู่เบื้องหลังได้ไม่เพียงพอ.
เหตุผลที่สำคัญ
ช่วยระบุวิธีแก้ไข ทำให้วิเคราะห์การแก้ไขถาวรเทียบกับการแก้ปัญหาชั่วคราว และสนับสนุนการวิเคราะห์สาเหตุที่แท้จริงได้.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow ฟิลด์ close_code หรือฟิลด์รหัสการแก้ไขปัญหาที่กำหนดเอง.
ตัวอย่าง
แก้ไขแล้ว (ใช้วิธีแก้ปัญหาชั่วคราว)แก้ไขแล้ว (แก้ไขถาวร)ยังแก้ไขไม่ได้ (ผู้ใช้ยกเลิก)ข้อผิดพลาดที่ทราบแล้ว
|
|||
|
หมวดหมู่
Category
|
การจัดประเภทเหตุขัดข้องในระดับกว้าง เช่น ฮาร์ดแวร์ ซอฟต์แวร์ หรือเครือข่าย. | ||
|
คำอธิบาย
หมวดหมู่ใช้จำแนกลักษณะของเหตุขัดข้องในภาพรวม โดยมักใช้ร่วมกับหมวดหมู่ย่อยเพื่อส่งเหตุขัดข้องไปยังทีมสนับสนุนที่เหมาะสม และใช้ในการจัดทำรายงานและวิเคราะห์แนวโน้ม. สำหรับ process mining คุณลักษณะนี้สำคัญต่อแดชบอร์ด 'ความแม่นยำในการจัดหมวดหมู่เหตุขัดข้อง' และ 'จำนวนเหตุขัดข้องที่เกิดซ้ำ' การวิเคราะห์เหตุขัดข้องที่มีการเปลี่ยนหมวดหมู่ระหว่างดำเนินการช่วยให้องค์กรพบปัญหาในการคัดกรองเบื้องต้น การกรองแผนผังกระบวนการตามหมวดหมู่ยังช่วยให้เห็นว่าเหตุขัดข้องบางประเภทมีเส้นทางการแก้ไขหรือคอขวดที่แตกต่างกันหรือไม่.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ประเภทของเหตุขัดข้อง วัดความแม่นยำในการจัดหมวดหมู่ และเป็นข้อมูลสำคัญสำหรับการส่งต่องานและวิเคราะห์แนวโน้ม.
แหล่งข้อมูล
ตาราง incident ของ ServiceNow, ฟิลด์ category.
ตัวอย่าง
ฮาร์ดแวร์ซอฟต์แวร์เครือข่ายฐานข้อมูล
|
|||
กิจกรรมการจัดการเหตุการณ์
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
ปิดเหตุขัดข้อง
|
เป็นกิจกรรมสุดท้ายในวงจรเหตุขัดข้อง แสดงว่าแก้ไขและยืนยันผลเรียบร้อยแล้ว และไม่ต้องดำเนินการเพิ่มเติม ระบบบันทึกเหตุการณ์นี้โดยใช้เวลาปิดเหตุขัดข้อง. | ||
|
เหตุผลที่สำคัญ
ในฐานะเหตุการณ์สิ้นสุดที่ชัดเจน กิจกรรมนี้จำเป็นต่อการคำนวณระยะเวลารวมของวงจรเหตุขัดข้องและวิเคราะห์เวลาที่ใช้ในขั้นตอนหลังการแก้ไข.
แหล่งข้อมูล
เวลาในฟิลด์ 'closed_at' ของตาราง 'incident' ใช้เป็นเวลาของเหตุการณ์นี้โดยตรง โดยทั่วไปจะกำหนดเมื่อฟิลด์ 'state' เปลี่ยนเป็น 'Closed'.
บันทึก
ใช้เวลาในฟิลด์ 'closed_at' จากระเบียนเหตุขัดข้อง.
ประเภทเหตุการณ์
explicit
|
|||
|
เปลี่ยนกลุ่มผู้รับผิดชอบ
|
แสดงการส่งต่องานเมื่อย้ายเหตุขัดข้องจากกลุ่มสนับสนุนหนึ่งไปยังอีกกลุ่มหนึ่ง ตรวจจับได้จากการเปลี่ยนแปลงฟิลด์ 'assignment_group' หลังจากกำหนดค่าในครั้งแรก. | ||
|
เหตุผลที่สำคัญ
การมอบหมายงานต่อบ่อยครั้งอาจบ่งชี้ว่าการส่งต่องานครั้งแรกไม่ถูกต้อง กระบวนการซับซ้อน หรือมีช่องว่างด้านความรู้ กิจกรรมนี้สำคัญต่อการวัด KPI 'จำนวนครั้งที่ส่งต่องานเฉลี่ยต่อเหตุขัดข้อง'.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' โดยติดตามการเปลี่ยนแปลงฟิลด์ 'assignment_group' หลังจากมอบหมายงานครั้งแรก.
บันทึก
ระบุเวลาของการเปลี่ยนแปลงฟิลด์ 'assignment_group' แต่ละครั้งในบันทึกการตรวจสอบ.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายเหตุขัดข้องให้กลุ่ม
|
กิจกรรมนี้เกิดขึ้นเมื่อมอบหมายเหตุขัดข้องให้กลุ่มสนับสนุนที่รับผิดชอบ เป็นขั้นตอนสำคัญในการส่งต่องาน ซึ่งตรวจจับได้จากการเปลี่ยนแปลงฟิลด์กลุ่มผู้รับผิดชอบ. | ||
|
เหตุผลที่สำคัญ
การติดตามการมอบหมายงานจำเป็นต่อการวิเคราะห์การส่งต่องาน ระยะเวลารอคิวของแต่ละกลุ่ม และการค้นหาจุดที่การส่งต่องานไม่มีประสิทธิภาพหรือเกิดคอขวด.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' โดยติดตามเวลาที่มีการกรอกหรือเปลี่ยนฟิลด์ 'assignment_group' ในตาราง 'incident'.
บันทึก
ใช้เวลาจากบันทึกการตรวจสอบเมื่อมีการเปลี่ยนแปลงฟิลด์ 'assignment_group'.
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มดำเนินงาน
|
แสดงว่าเจ้าหน้าที่เริ่มตรวจสอบหรือดำเนินการกับเหตุขัดข้อง โดยทั่วไปอนุมานจากการเปลี่ยนสถานะของเหตุขัดข้องจาก 'New' หรือ 'Assigned' เป็นสถานะที่กำลังดำเนินการ เช่น 'In Progress'. | ||
|
เหตุผลที่สำคัญ
หมุดหมายนี้เป็นจุดสิ้นสุดของเวลารอคิวช่วงแรกและจุดเริ่มต้นของการแก้ไขอย่างจริงจัง การวัดเวลาจนเริ่มดำเนินงานจึงสำคัญต่อการวิเคราะห์คอขวด.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' โดยตรวจหาการเปลี่ยนแปลงฟิลด์ 'state' ในตาราง 'incident' เป็นสถานะที่แสดงว่ากำลังดำเนินงาน เช่น 'In Progress'.
บันทึก
ระบุเวลาที่ฟิลด์ 'state' เปลี่ยนเป็น 'In Progress' หรือสถานะที่มีความหมายใกล้เคียงกัน.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างเหตุขัดข้อง
|
เป็นจุดเริ่มต้นของวงจรเหตุขัดข้อง เมื่อมีการบันทึกเหตุขัดข้องใหม่ใน ServiceNow อย่างเป็นทางการ ระบบจะบันทึกเหตุการณ์นี้โดยใช้เวลาที่สร้างระเบียนเหตุขัดข้อง. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ การวิเคราะห์เวลาตั้งแต่กิจกรรมนี้จนถึงการแก้ไขเสร็จสิ้นเป็นพื้นฐานสำคัญในการวัดระยะเวลารวมของกระบวนการและการปฏิบัติตาม SLA.
แหล่งข้อมูล
ใช้เวลาในฟิลด์ 'sys_created_on' ของตาราง 'incident' เป็นเวลาของเหตุการณ์นี้โดยตรง.
บันทึก
ใช้เวลาในฟิลด์ 'sys_created_on' จากระเบียนเหตุขัดข้อง.
ประเภทเหตุการณ์
explicit
|
|||
|
เสนอวิธีแก้ไข
|
แสดงจุดที่เจ้าหน้าที่สนับสนุนดำเนินการแก้ไขแล้วและเปลี่ยนสถานะเหตุขัดข้องเป็น 'Resolved' ซึ่งเป็นหมุดหมายสำคัญก่อนปิดเหตุขัดข้องอย่างเป็นทางการ. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้แสดงว่างานที่ต้องดำเนินการสิ้นสุดลงและเริ่มขั้นตอนยืนยันผล เวลาระหว่างกิจกรรมนี้กับ 'ปิดเหตุขัดข้อง' อาจช่วยให้เห็นความล่าช้าในการยืนยันจากผู้ใช้หรือการตรวจสอบผล.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' เมื่อฟิลด์ 'state' ในตาราง 'incident' เปลี่ยนเป็น 'Resolved' โดยมักมีการกรอกเวลาใน 'resolved_at' ณ เวลานี้.
บันทึก
ใช้เวลาที่ฟิลด์ 'state' เปลี่ยนเป็น 'Resolved' หรือเวลาใน 'resolved_at'.
ประเภทเหตุการณ์
inferred
|
|||
|
จัดหมวดหมู่เหตุขัดข้อง
|
แสดงการจัดประเภทเหตุขัดข้องในเบื้องต้น โดยกำหนดฟิลด์ต่างๆ เช่น Category, Subcategory และ Priority โดยทั่วไปอนุมานเหตุการณ์นี้จากประวัติการตรวจสอบ เมื่อมีการกรอกหรือแก้ไขฟิลด์เหล่านี้ครั้งแรกหลังสร้างระเบียน. | ||
|
เหตุผลที่สำคัญ
การจัดหมวดหมู่ที่ถูกต้องมีความสำคัญต่อการส่งต่องานและจัดลำดับความสำคัญให้เหมาะสม การติดตามกิจกรรมนี้ช่วยวิเคราะห์อัตราการจัดหมวดหมู่ใหม่และผลกระทบต่อเวลาในการแก้ไข.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' โดยค้นหาการเปลี่ยนแปลงครั้งแรกของฟิลด์ เช่น 'category', 'subcategory' หรือ 'priority' สำหรับเหตุขัดข้องแต่ละรายการ.
บันทึก
ระบุเวลาที่มีการแก้ไขฟิลด์การจัดประเภทครั้งแรกในบันทึกการตรวจสอบ.
ประเภทเหตุการณ์
inferred
|
|||
|
เชื่อมโยงเหตุขัดข้องกับปัญหา
|
กิจกรรมนี้เกิดขึ้นเมื่อเชื่อมโยงเหตุขัดข้องกับระเบียนปัญหาอย่างเป็นทางการ ซึ่งแสดงว่าเหตุขัดข้องเป็นส่วนหนึ่งของปัญหาที่ใหญ่กว่าและมีสาเหตุอยู่เบื้องหลัง อนุมานได้เมื่อมีการกรอกฟิลด์ 'problem_id' ในระเบียนเหตุขัดข้อง. | ||
|
เหตุผลที่สำคัญ
การเชื่อมโยงกับปัญหาเป็นขั้นตอนสำคัญในการเปลี่ยนจากการแก้เหตุขัดข้องเฉพาะหน้าไปสู่การวิเคราะห์สาเหตุที่แท้จริงเชิงรุก และช่วยสนับสนุนแดชบอร์ด 'จำนวนเหตุขัดข้องที่เกิดซ้ำ'.
แหล่งข้อมูล
อนุมานได้จากการตรวจพบว่าฟิลด์อ้างอิง 'problem_id' ในตาราง 'incident' มีการกรอกค่า.
บันทึก
ระบุเวลาจากบันทึกการตรวจสอบเมื่อมีการกรอกฟิลด์ 'problem_id'.
ประเภทเหตุการณ์
inferred
|
|||
|
เปิดเหตุขัดข้องอีกครั้ง
|
เกิดขึ้นเมื่อผู้ใช้แจ้งว่าปัญหายังคงอยู่หลังจากระบุว่าแก้ไขแล้ว อนุมานได้เมื่อสถานะเหตุขัดข้องเปลี่ยนจาก 'Resolved' กลับไปเป็นสถานะที่กำลังดำเนินการ เช่น 'In Progress'. | ||
|
เหตุผลที่สำคัญ
เหตุขัดข้องที่เปิดขึ้นอีกครั้งแสดงว่าการแก้ไขไม่สำเร็จและต้องทำงานซ้ำ การติดตามกิจกรรมนี้สำคัญต่อการวัดคุณภาพการแก้ไขและอัตราการแก้ไขสำเร็จตั้งแต่ครั้งแรก.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' โดยตรวจจับการเปลี่ยนฟิลด์ 'state' จาก 'Resolved' กลับไปเป็นสถานะที่กำลังดำเนินการ เช่น 'In Progress' หรือ 'Assigned'.
บันทึก
ระบุเวลาที่ 'state' เปลี่ยนจาก 'Resolved' ไปเป็นสถานะที่กำลังดำเนินการ.
ประเภทเหตุการณ์
inferred
|
|||
|
เพิ่มความคิดเห็นจากทีมสนับสนุน
|
เจ้าหน้าที่สนับสนุนเพิ่มบันทึกการทำงานหรือความคิดเห็นที่ผู้ใช้มองเห็นได้ เหตุการณ์นี้บันทึกไว้อย่างชัดเจนในรายการกิจกรรมของเหตุขัดข้อง. | ||
|
เหตุผลที่สำคัญ
ติดตามการสื่อสารและการตรวจสอบของทีมสนับสนุน การวิเคราะห์ความถี่และเวลาที่เพิ่มความคิดเห็นช่วยให้เข้าใจขั้นตอนการตรวจสอบ.
แหล่งข้อมูล
ดึงข้อมูลจากตาราง 'sys_journal_field' ซึ่งบันทึกรายการในฟิลด์ 'work_notes' และ 'comments' ของตาราง 'incident'.
บันทึก
ใช้เวลาที่สร้างรายการบันทึก โดย element มีค่าเป็น 'work_notes' หรือ 'comments'.
ประเภทเหตุการณ์
explicit
|
|||
|
มอบหมายเหตุขัดข้องให้เจ้าหน้าที่
|
แสดงจุดที่เจ้าหน้าที่คนใดคนหนึ่งในกลุ่มสนับสนุนรับผิดชอบเหตุขัดข้อง โดยติดตามการเปลี่ยนแปลงฟิลด์ 'assigned_to'. | ||
|
เหตุผลที่สำคัญ
ข้อมูลนี้ช่วยให้เห็นภาระงานของเจ้าหน้าที่และการแก้ไขปัญหาได้ตั้งแต่ครั้งแรกอย่างละเอียด อีกทั้งช่วยวัดว่าเหตุขัดข้องต้องรอนานเท่าใดกว่าผู้รับผิดชอบรายบุคคลจะเริ่มดำเนินการหลังจากมอบหมายให้กลุ่มแล้ว.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' โดยติดตามเวลาที่มีการกรอกหรือเปลี่ยนฟิลด์ 'assigned_to' ในตาราง 'incident'.
บันทึก
ใช้เวลาจากบันทึกการตรวจสอบเมื่อมีการเปลี่ยนแปลงฟิลด์ 'assigned_to'.
ประเภทเหตุการณ์
inferred
|
|||
|
ยกระดับเหตุขัดข้อง
|
เกิดขึ้นเมื่อเพิ่มระดับความสำคัญหรือความรุนแรงของเหตุขัดข้อง ซึ่งมักต้องตอบสนองเร็วขึ้นหรือใช้ทรัพยากรอื่น อนุมานได้จากการตรวจพบว่าค่าในฟิลด์ 'priority' เพิ่มขึ้น. | ||
|
เหตุผลที่สำคัญ
การยกระดับมักบ่งชี้ว่าเหตุขัดข้องรุนแรงกว่าที่ประเมินไว้ในตอนแรก หรือใกล้ผิด SLA การวิเคราะห์เหตุการณ์เหล่านี้ช่วยให้เข้าใจกรณีที่กระบวนการไม่เป็นไปตามปกติ.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' โดยตรวจหาการเปลี่ยนแปลงฟิลด์ 'priority' ไปเป็นค่าที่มีระดับความเร่งด่วนสูงขึ้น.
บันทึก
ตรวจจับเมื่อค่าฟิลด์ 'priority' เพิ่มขึ้น เช่น จาก '3 - Moderate' เป็น '2 - High'.
ประเภทเหตุการณ์
inferred
|
|||
|
รอผู้ใช้ยืนยัน
|
เหตุขัดข้องอยู่ในสถานะรอดำเนินการ โดยรอให้ผู้ใช้ยืนยันว่าการแก้ไขที่เสนอได้ผล โดยทั่วไปอนุมานจากสถานะเฉพาะ เช่น 'Awaiting User Info' หลังจากแก้ไขแล้ว. | ||
|
เหตุผลที่สำคัญ
สถานะนี้อาจกลายเป็นคอขวดสำคัญหากผู้ใช้ตอบกลับช้า การวัดเวลาที่ใช้ในกิจกรรมนี้ช่วยให้พบช่องว่างในการสื่อสารและโอกาสในการปิดเหตุขัดข้องโดยอัตโนมัติ.
แหล่งข้อมูล
อนุมานจากตาราง 'sys_audit' โดยตรวจหาการเปลี่ยนไปยังสถานะรอดำเนินการเฉพาะหลังจากแก้ไขแล้ว ชื่อสถานะอาจกำหนดเอง เช่น 'Awaiting Caller'.
บันทึก
ระบุเวลาที่ 'state' เปลี่ยนเป็นสถานะที่แสดงว่ากำลังรอข้อมูลจากผู้ใช้.
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
เทมเพลตนี้มีข้อมูลที่จำเป็นสำหรับเริ่มต้นใช้ process mining กับกระบวนการจัดการเหตุการณ์ เริ่มปรับปรุงการแก้ไขเหตุการณ์ของคุณได้วันนี้.
แก้ไขเหตุการณ์ได้เร็วขึ้น เพิ่มประสิทธิภาพ ServiceNow วันนี้
ลด MTTR ใน ServiceNow ได้ 35% ค้นหาปัญหาและยกระดับความพึงพอใจ.
ไม่ต้องใช้บัตรเครดิต เริ่มปรับปรุงกระบวนการได้ในไม่กี่นาที.