เทมเพลตข้อมูลการจัดการเหตุการณ์ของคุณ
เทมเพลตข้อมูลการจัดการเหตุการณ์ของคุณ
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ การจัดการเหตุขัดข้อง หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- โครงสร้างข้อมูลกลางที่ใช้ได้กับระบบจัดการเหตุการณ์ทุกประเภท
- แอตทริบิวต์และกิจกรรมแนะนำสำหรับการวิเคราะห์อย่างละเอียด
- คำแนะนำในการดึงข้อมูล พร้อมตัวอย่างเฉพาะระบบ
แอตทริบิวต์การจัดการเหตุการณ์
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อกิจกรรมทางธุรกิจ เหตุการณ์ หรือการเปลี่ยนสถานะที่เกิดขึ้นในวงจรชีวิตของเหตุขัดข้อง. | ||
| คำอธิบาย ชื่อกิจกรรมระบุขั้นตอนหรืองานที่เกิดขึ้นในกระบวนการจัดการเหตุขัดข้อง กิจกรรมเหล่านี้เป็นองค์ประกอบของแผนผังกระบวนการ และอาจเป็นเหตุการณ์อัตโนมัติจากระบบ เช่น 'ตรวจพบการละเมิด SLA' หรือการดำเนินการด้วยตนเอง เช่น 'มอบหมายเจ้าหน้าที่' หรือ 'ให้วิธีแก้ปัญหาชั่วคราว'. ข้อมูลนี้เป็นพื้นฐานสำคัญของการวิเคราะห์ process mining เพราะใช้กำหนดโหนดในกราฟกระบวนการ ช่วยให้นักวิเคราะห์เห็นลำดับงาน ระบุเส้นทางที่พบบ่อย ค้นหาคอขวด และวิเคราะห์ขั้นตอนที่ต่างจากแนวทางมาตรฐาน ชื่อกิจกรรมที่ชัดเจนและมีรายละเอียดเหมาะสมส่งผลโดยตรงต่อคุณภาพและความลึกของข้อมูลเชิงลึกที่ได้. เหตุผลที่สำคัญ ข้อมูลนี้กำหนดขั้นตอนในกระบวนการ ทำให้เห็นภาพและวิเคราะห์ลำดับงานตลอดวงจรชีวิตเหตุขัดข้องได้. แหล่งข้อมูล มักได้จากการรวมข้อมูลในบันทึกเหตุการณ์ บันทึกการตรวจสอบ ระเบียนการเปลี่ยนสถานะ หรือช่องคำอธิบายงานในระบบจัดการเหตุขัดข้อง. ตัวอย่าง สร้างเหตุขัดข้องมอบหมายให้กลุ่มแก้ไขเหตุขัดข้องแล้วเปลี่ยนสถานะเป็นรอดำเนินการ | |||
| รหัสเหตุขัดข้อง IncidentId | รหัสเฉพาะที่กำหนดให้กับเหตุขัดข้องแต่ละรายการ ใช้ติดตามเหตุขัดข้องตลอดวงจรชีวิต. | ||
| คำอธิบาย รหัสเหตุขัดข้องเป็นรหัสตัวอักษรและตัวเลขที่ไม่ซ้ำกัน ใช้แยกเหตุขัดข้องแต่ละรายการออกจากกันในระบบ ระบบจะสร้างรหัสนี้เมื่อมีการสร้างเหตุขัดข้องใหม่ และรหัสจะคงเดิมจนกว่าจะเก็บเหตุขัดข้องเข้าคลังถาวรหรือลบออก. ในการทำ process mining รหัสเหตุขัดข้องเป็นหัวใจสำคัญของการวิเคราะห์และทำหน้าที่เป็น Case ID ซอฟต์แวร์ใช้รหัสนี้เชื่อมโยงเหตุการณ์ การเปลี่ยนสถานะ และกิจกรรมที่เกี่ยวข้องให้เป็นกระบวนการเดียวกัน เมื่อนำเหตุการณ์ทั้งหมดมาจัดกลุ่มตามรหัสเหตุขัดข้อง นักวิเคราะห์จะเห็นเส้นทางของเหตุขัดข้องแต่ละรายการตั้งแต่การแจ้งครั้งแรกจนถึงการแก้ไขและปิดเหตุขัดข้อง. เหตุผลที่สำคัญ รหัสนี้จำเป็นต่อการเชื่อมโยงกิจกรรมและเหตุการณ์ที่เกี่ยวข้อง เพื่อสร้างภาพวงจรชีวิตเหตุขัดข้องตั้งแต่ต้นจนจบสำหรับการทำ process mining. แหล่งข้อมูล รหัสนี้เป็นคีย์หลักของเหตุขัดข้อง โดยทั่วไปจะอยู่ในส่วนหัวหรือระเบียนหลักของตารางหรือออบเจ็กต์เหตุขัดข้องแต่ละรายการ. ตัวอย่าง INC0010032TICKET-84321789456123 | |||
| เวลาที่เกิดเหตุการณ์ EventTimestamp | วันที่และเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์หนึ่งเกิดขึ้นกับเหตุขัดข้อง. | ||
| คำอธิบาย เวลาที่เกิดเหตุการณ์ระบุช่วงเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ กิจกรรมแต่ละรายการในวงจรชีวิตเหตุขัดข้องควรมีเวลาที่เกี่ยวข้อง เพื่อเรียงลำดับเหตุการณ์ตามเวลา. ข้อมูลนี้สำคัญต่อการวิเคราะห์ process mining ตามเวลา ใช้คำนวณเวลาตั้งแต่กิจกรรมหนึ่งไปยังอีกกิจกรรม ระยะเวลาของแต่ละขั้นตอน และเวลาโดยรวมในการแก้ไขเหตุขัดข้อง การวิเคราะห์เวลาช่วยให้องค์กรระบุคอขวด วัดการปฏิบัติตาม SLA และทำความเข้าใจว่าประสิทธิภาพของกระบวนการเปลี่ยนแปลงไปอย่างไรเมื่อเวลาผ่านไป นอกจากนี้ยังเป็นข้อมูลพื้นฐานในการคำนวณ KPI เช่น เวลาเฉลี่ยในการแก้ไข. เหตุผลที่สำคัญ ข้อมูลนี้แสดงลำดับเหตุการณ์ตามเวลา ซึ่งจำเป็นต่อการคำนวณระยะเวลา ระบุคอขวด และวิเคราะห์ประสิทธิภาพของกระบวนการในแต่ละช่วงเวลา. แหล่งข้อมูล พบได้ในบันทึกเหตุการณ์ ตารางประวัติการตรวจสอบ หรือช่อง 'แก้ไขล่าสุด' หรือ 'วันที่สร้าง' ของระเบียนที่เกี่ยวข้อง. ตัวอย่าง 2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:45Z | |||
| ระบบต้นทาง SourceSystem | ชื่อหรือรหัสของระบบที่ใช้ดึงข้อมูลเหตุขัดข้อง. | ||
| คำอธิบาย ข้อมูลระบบต้นทางระบุแหล่งที่มาของข้อมูล ในสภาพแวดล้อมที่มีเครื่องมือ ITSM หรือระบบเชื่อมต่อหลายระบบ ช่องนี้ช่วยแยกระเบียนจากแต่ละแหล่งได้. แม้จะไม่ได้ใช้วาดแผนผังกระบวนการโดยตรง แต่ข้อมูลนี้มีประโยชน์ต่อการตรวจสอบและกำกับดูแลข้อมูล ช่วยให้นักวิเคราะห์ติดตามข้อมูลกลับไปยังแหล่งที่มา ทำความเข้าใจความคลาดเคลื่อนระหว่างระบบ และแบ่งกลุ่มข้อมูลเพื่อวิเคราะห์ ตัวอย่างเช่น องค์กรอาจเปรียบเทียบกระบวนการจัดการเหตุขัดข้องใน ServiceNow และ Jira. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยระบุที่มาของข้อมูล ซึ่งสำคัญต่อการตรวจสอบข้อมูล การแก้ไขปัญหา และการเปรียบเทียบข้อมูลจากหลายระบบ. แหล่งข้อมูล โดยทั่วไปจะเป็นค่าคงที่ที่เพิ่มระหว่างการดึงข้อมูล หรือเป็นช่องข้อมูลที่มีอยู่ในตารางของระบบต้นทาง. ตัวอย่าง ServiceNowJira Service ManagementBMC HelixZendesk | |||
| เวลาอัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ระบุว่ามีการรีเฟรชข้อมูลของระเบียนนี้จากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย เวลาอัปเดตข้อมูลล่าสุดระบุเวลาที่ดึงหรือซิงค์ข้อมูลจากระบบต้นทางครั้งล่าสุด ข้อมูลเมตานี้แสดงว่าข้อมูลที่นำมาวิเคราะห์เป็นข้อมูลล่าสุดเพียงใด. ในการวิเคราะห์ process mining ข้อมูลนี้ช่วยให้เข้าใจว่าข้อมูลเชิงลึกที่ได้เป็นปัจจุบันแค่ไหน ผู้ใช้จึงทราบว่ากำลังดูข้อมูลแบบเรียลไทม์หรือภาพข้อมูล ณ ช่วงเวลาก่อนหน้า ข้อมูลนี้สำคัญต่อการติดตามการปฏิบัติการและช่วยให้มั่นใจว่าการตัดสินใจอ้างอิงข้อมูลที่เป็นปัจจุบันและเกี่ยวข้อง. เหตุผลที่สำคัญ ข้อมูลนี้แสดงความใหม่ของข้อมูล ช่วยให้นักวิเคราะห์ทราบว่าผลการวิเคราะห์กระบวนการเป็นปัจจุบันเพียงใด. แหล่งข้อมูล โดยทั่วไประบบจะสร้างค่านี้และบันทึกลงในแต่ละระเบียนระหว่างกระบวนการดึงและแปลงข้อมูล (ETL). ตัวอย่าง 2023-10-26T23:59:59Z2024-01-16T04:00:10Z2023-11-02T01:05:00Z | |||
| กลุ่มที่รับผิดชอบ AssignedGroup | ทีมสนับสนุน คิว หรือกลุ่มที่รับผิดชอบดำเนินการกับเหตุขัดข้องในขณะนั้น. | ||
| คำอธิบาย กลุ่มที่รับผิดชอบระบุว่าทีมใดดูแลเหตุขัดข้องในแต่ละช่วงเวลา โดยมักส่งต่อเหตุขัดข้องระหว่างกลุ่มต่างๆ เช่น Service Desk ระดับ 1 ทีมเครือข่ายระดับ 2 หรือทีมสนับสนุนแอปพลิเคชันระดับ 3. ข้อมูลนี้จำเป็นต่อการวิเคราะห์การส่งต่องานและภาระงาน process mining ใช้ข้อมูลนี้แสดงเส้นทางการส่งต่อเหตุขัดข้องระหว่างทีม วัดเวลาที่อยู่ในคิวของแต่ละทีม และค้นหาคอขวดที่เกิดจากการมอบหมายงานใหม่บ่อยครั้ง นอกจากนี้ยังช่วยตอบคำถามเกี่ยวกับประสิทธิภาพและการทำงานร่วมกันของทีม และเป็นพื้นฐานของแดชบอร์ดวิเคราะห์การส่งต่องานและการมอบหมายใหม่. เหตุผลที่สำคัญ ข้อมูลนี้สำคัญต่อการวิเคราะห์การส่งต่องานระหว่างทีม การวัดเวลารอในคิว และการทำความเข้าใจประสิทธิภาพและการกระจายภาระงานของแต่ละทีม. แหล่งข้อมูล โดยทั่วไปข้อมูลนี้จัดเก็บไว้ในระเบียนเหตุขัดข้อง และอัปเดตทุกครั้งที่มอบหมายเหตุขัดข้องให้ทีมใหม่. ตัวอย่าง Service Deskฝ่ายปฏิบัติการเครือข่ายฝ่ายดูแลฐานข้อมูลทีมสนับสนุนแอปพลิเคชันระดับ 2 | |||
| เจ้าหน้าที่ที่รับผิดชอบ AssignedAgent | เจ้าหน้าที่สนับสนุนหรือผู้ใช้ที่ได้รับมอบหมายให้จัดการเหตุขัดข้อง. | ||
| คำอธิบาย เจ้าหน้าที่ที่รับผิดชอบระบุบุคคลที่ดูแลเหตุขัดข้องโดยเฉพาะ ส่วนกลุ่มที่รับผิดชอบระบุทีม เจ้าหน้าที่คือผู้ลงมือดำเนินการแก้ไข. ข้อมูลนี้ช่วยวิเคราะห์ประสิทธิภาพและภาระงานในระดับบุคคลได้ละเอียดขึ้น การติดตามการมอบหมายงานในระดับเจ้าหน้าที่ช่วยให้ผู้จัดการประเมินผลงานรายบุคคล ระบุความต้องการฝึกอบรม และจัดสรรงานให้สมดุล process mining ยังช่วยให้เห็นรูปแบบการมอบหมายงานใหม่ที่ซับซ้อน ซึ่งอาจมองไม่เห็นเมื่อดูเฉพาะระดับกลุ่ม และช่วยให้เข้าใจว่างานของแต่ละคนส่งผลต่อเวลาแก้ไขอย่างไร. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยวิเคราะห์ภาระงาน ประสิทธิภาพ และรูปแบบการมอบหมายงานใหม่ของแต่ละคน ทั้งภายในทีมและระหว่างทีมได้อย่างละเอียด. แหล่งข้อมูล ช่องนี้อยู่ในระเบียนเหตุขัดข้องหลัก และจะอัปเดตเมื่อเจ้าหน้าที่รับผิดชอบหรือได้รับมอบหมายเหตุขัดข้อง. ตัวอย่าง John SmithJane Doeagent.12345Emily Jones | |||
| ช่องทางการแจ้ง ReportingChannel | วิธีหรือช่องทางที่ใช้แจ้งเหตุขัดข้อง เช่น อีเมล โทรศัพท์ หรือพอร์ทัลบริการตนเอง. | ||
| คำอธิบาย ช่องทางการแจ้งระบุแหล่งที่มาของการแจ้งเหตุขัดข้อง ข้อมูลนี้แสดงให้เห็นว่าผู้ใช้ติดต่อฝ่ายสนับสนุนอย่างไร ไม่ว่าจะเป็นการติดต่อโดยตรง เช่น โทรศัพท์ หรือช่องทางอัตโนมัติ เช่น การแจ้งเตือนจากระบบตรวจสอบ. การวิเคราะห์กระบวนการตามช่องทางการแจ้งอาจเผยให้เห็นความแตกต่างด้านประสิทธิภาพที่สำคัญ ตัวอย่างเช่น เหตุขัดข้องที่แจ้งผ่านพอร์ทัลบริการตนเองอาจแก้ไขได้เร็วกว่า เพราะมักมีข้อมูลที่เป็นระบบตั้งแต่ต้น การวิเคราะห์นี้ช่วยให้องค์กรปรับช่องทางสนับสนุนและส่งเสริมให้ใช้ช่องทางที่มีประสิทธิภาพมากขึ้น. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยวิเคราะห์ประสิทธิภาพและเส้นทางการแก้ไขเหตุขัดข้องตามแหล่งที่มา เพื่อนำไปใช้วางแผนช่องทางและจัดสรรทรัพยากร. แหล่งข้อมูล โดยทั่วไประบบจะบันทึกข้อมูลนี้โดยอัตโนมัติ หรือเจ้าหน้าที่เลือกช่องทางเมื่อสร้างเหตุขัดข้อง. ตัวอย่าง อีเมลโทรศัพท์พอร์ทัลบริการตนเองการแจ้งเตือนจากระบบ | |||
| ระดับความรุนแรง Severity | ระดับผลกระทบทางธุรกิจของเหตุขัดข้อง ซึ่งแสดงว่าปัญหาส่งผลต่อผู้ใช้หรือบริการมากเพียงใด. | ||
| คำอธิบาย ระดับความรุนแรงแสดงผลกระทบที่เหตุขัดข้องมีต่อธุรกิจ โดยพิจารณาว่าปัญหาร้ายแรงเพียงใด โดยไม่ขึ้นกับความเร่งด่วน ตัวอย่างเช่น ระบบล่มทั้งองค์กรถือเป็นเหตุขัดข้องที่มีความรุนแรงสูง ส่วนข้อผิดพลาดด้านรูปลักษณ์เล็กน้อยถือว่ามีความรุนแรงต่ำ. การวิเคราะห์เหตุขัดข้องตามระดับความรุนแรงช่วยให้องค์กรเข้าใจว่าปัญหาประเภทใดสร้างผลกระทบมากที่สุด process mining อาจแสดงให้เห็นว่าเหตุขัดข้องที่มีความรุนแรงสูงใช้เส้นทางแก้ไขที่ต่างออกไปและกระชับกว่า ข้อมูลนี้สำคัญต่อการวิเคราะห์สาเหตุที่แท้จริงและจัดลำดับความสำคัญของทรัพยากรสำหรับการจัดการปัญหาเชิงรุก เพื่อป้องกันไม่ให้เหตุขัดข้องร้ายแรงเกิดซ้ำ. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยแบ่งกลุ่มเหตุขัดข้อง เพื่อดูว่าปัญหาที่มีผลกระทบสูงได้รับการแก้ไขต่างจากปัญหาที่มีผลกระทบต่ำหรือมีประสิทธิภาพกว่าหรือไม่. แหล่งข้อมูล เป็นช่องข้อมูลมาตรฐานในระเบียนเหตุขัดข้อง และมักใช้ร่วมกับความเร่งด่วนเพื่อกำหนดระดับความสำคัญ. ตัวอย่าง 1 - สูง2 - ปานกลาง3 - ต่ำวิกฤต | |||
| ระดับความสำคัญ Priority | ระดับความสำคัญที่กำหนดให้กับเหตุขัดข้อง ซึ่งใช้จัดลำดับความเร่งด่วนและการแก้ไข. | ||
| คำอธิบาย ระดับความสำคัญเป็นข้อมูลหลักที่ใช้กำหนดความสำคัญของเหตุขัดข้องเมื่อเทียบกับรายการอื่น และความเร็วในการตอบสนองที่ต้องการ โดยมักคำนวณจากผลกระทบและความเร่งด่วนของเหตุขัดข้อง ระดับโดยทั่วไปมีตั้งแต่วิกฤตไปจนถึงต่ำ. การวิเคราะห์เหตุขัดข้องตามระดับความสำคัญด้วย process mining ช่วยให้เห็นว่ากระบวนการจัดการเหตุขัดข้องที่เร่งด่วนต่างกันอย่างไร นักวิเคราะห์สามารถเปรียบเทียบเวลาแก้ไขของเหตุขัดข้องที่มีความสำคัญสูงกับรายการที่มีความสำคัญต่ำ เพื่อตรวจสอบการปฏิบัติตาม SLA และการจัดสรรทรัพยากร คำถามที่ช่วยตอบได้ เช่น เราจัดการเหตุขัดข้องที่วิกฤตที่สุดได้เร็วที่สุดจริงหรือไม่? เหตุผลที่สำคัญ ข้อมูลนี้ช่วยวิเคราะห์ประสิทธิภาพของกระบวนการตามระดับความเร่งด่วน และตรวจสอบว่าเหตุขัดข้องวิกฤตได้รับการจัดการเร็วกว่ารายการที่ไม่วิกฤตหรือไม่. แหล่งข้อมูล มีเป็นช่องข้อมูลมาตรฐานในระเบียนเหตุขัดข้อง โดยอาจกำหนดด้วยตนเองหรือคำนวณอัตโนมัติจากผลกระทบและความเร่งด่วน. ตัวอย่าง 1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ | |||
| วิธีแก้ไข ResolutionMethod | รหัส หมวดหมู่ หรือคำอธิบายที่ระบุวิธีแก้ไขเหตุขัดข้องในท้ายที่สุด. | ||
| คำอธิบาย วิธีแก้ไขอธิบายผลลัพธ์ของเหตุขัดข้องและวิธีที่ใช้แก้ไข อาจเป็นรหัสมาตรฐานหรือคำอธิบายการดำเนินการในรูปแบบข้อความอิสระ ตัวอย่างเช่น 'แนะนำวิธีใช้งานให้ผู้ใช้' 'ติดตั้งแพตช์ซอฟต์แวร์' 'ไม่พบข้อบกพร่อง' หรือ 'เหตุขัดข้องซ้ำ'. ข้อมูลนี้ช่วยให้เข้าใจช่วงท้ายของกระบวนการ การวิเคราะห์เหตุขัดข้องตามวิธีแก้ไขด้วย process mining ช่วยประเมินประสิทธิผลของวิธีแก้ไขแต่ละแบบ และอาจชี้ให้เห็นกรณีที่ปิดเหตุขัดข้องโดยยังไม่ได้แก้ปัญหาจริง หรือรูปแบบการแก้ไขที่พบบ่อยในเหตุขัดข้องบางหมวดหมู่ ซึ่งนำไปใช้สร้างฐานความรู้และเพิ่มอัตราการแก้ไขได้ตั้งแต่การติดต่อครั้งแรก. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยให้เห็นวิธีแก้ปัญหาที่ใช้อยู่ ซึ่งเป็นประโยชน์ต่อการหาโอกาสนำระบบอัตโนมัติมาใช้ ปรับปรุงฐานความรู้ และวางแผนฝึกอบรม. แหล่งข้อมูล โดยทั่วไปเจ้าหน้าที่สนับสนุนจะกรอกข้อมูลนี้เมื่อเปลี่ยนสถานะเหตุขัดข้องเป็น 'Resolved' หรือ 'Closed'. ตัวอย่าง Service Desk แก้ไขแล้วไม่พบข้อบกพร่องรายการซ้ำนำการอัปเดตซอฟต์แวร์ไปใช้แล้ว | |||
| สถานะเหตุขัดข้อง IncidentStatus | สถานะปัจจุบันหรือสถานะในอดีตของเหตุขัดข้องในวงจรชีวิต เช่น 'New', 'In Progress' หรือ 'Closed'. | ||
| คำอธิบาย สถานะเหตุขัดข้องแสดงขั้นตอนที่เหตุขัดข้องอยู่ ณ ช่วงเวลาหนึ่ง ช่วยให้เห็นภาพรวมว่าเหตุขัดข้องอยู่ในขั้นตอนไหนของกระบวนการแก้ไข สถานะที่พบบ่อย ได้แก่ ใหม่ มอบหมายแล้ว กำลังดำเนินการ รอดำเนินการ แก้ไขแล้ว และปิดแล้ว. ข้อมูลนี้เป็นพื้นฐานสำคัญของการวิเคราะห์กระบวนการ เพราะการเปลี่ยนสถานะมักใช้กำหนดกิจกรรมในแผนผังกระบวนการ การวิเคราะห์เวลาที่ใช้ในแต่ละสถานะช่วยค้นหาคอขวด เช่น เหตุขัดข้องที่ค้างอยู่ในสถานะ 'Pending' เป็นเวลานาน นอกจากนี้ยังใช้คำนวณจำนวนเหตุขัดข้องที่ยังเปิดอยู่และติดตามความคืบหน้าในการแก้ไขได้ด้วย. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยให้เข้าใจความคืบหน้าของเหตุขัดข้อง และมักใช้สร้างกิจกรรมในแผนผังกระบวนการ การวิเคราะห์เวลาที่ใช้ในแต่ละสถานะช่วยค้นหาความล่าช้า. แหล่งข้อมูล โดยทั่วไปมีเป็นช่องข้อมูลหลักในระเบียนเหตุขัดข้อง หรืออยู่ในบันทึกประวัติเหตุขัดข้อง. ตัวอย่าง ใหม่กำลังดำเนินการรอลูกค้าแก้ไขแล้วปิดแล้ว | |||
| หมวดหมู่เหตุขัดข้อง IncidentCategory | การจัดประเภทเหตุขัดข้อง ซึ่งมักจัดเป็นลำดับชั้น เช่น ฮาร์ดแวร์ > แล็ปท็อป > แบตเตอรี่. | ||
| คำอธิบาย หมวดหมู่เหตุขัดข้องช่วยจัดประเภทเหตุขัดข้องตามลักษณะของปัญหา โดยทั่วไปจะจัดเป็นลำดับชั้นเพื่อให้จำแนกได้ละเอียดขึ้น และจัดกลุ่มเหตุขัดข้องอย่างเป็นระบบสำหรับการรายงานและวิเคราะห์. การจัดหมวดหมู่มีความสำคัญต่อการวิเคราะห์สาเหตุที่แท้จริงและแนวโน้ม การกรองแผนผังกระบวนการตามหมวดหมู่ช่วยให้องค์กรระบุปัญหาที่เกิดซ้ำและรูปแบบที่เกี่ยวข้องกับเหตุขัดข้องแต่ละประเภทได้ ตัวอย่างเช่น กระบวนการแก้ไขเหตุขัดข้องด้าน 'ซอฟต์แวร์' อาจต่างจากเหตุขัดข้องด้าน 'ฮาร์ดแวร์' มาก ข้อมูลนี้ใช้คำนวณ KPI เช่น ความแม่นยำในการจัดหมวดหมู่ครั้งแรกและอัตราการเกิดเหตุขัดข้องซ้ำ. เหตุผลที่สำคัญ ข้อมูลนี้จำเป็นต่อการวิเคราะห์สาเหตุที่แท้จริง การหาแนวโน้มของเหตุขัดข้องที่เกิดซ้ำ และการทำความเข้าใจวิธีจัดการปัญหาแต่ละประเภท. แหล่งข้อมูล เป็นชุดช่องข้อมูลมาตรฐานที่มักจำเป็นต้องกรอกในระเบียนเหตุขัดข้องเพื่อใช้จัดประเภท. ตัวอย่าง ซอฟต์แวร์ | แอปพลิเคชัน | ปัญหาการเข้าสู่ระบบฮาร์ดแวร์ | เครื่องพิมพ์ | ไม่ตอบสนองเครือข่าย | Wi-Fi | การเชื่อมต่อช้า | |||
| จำนวนครั้งที่มอบหมายใหม่ ReassignmentCount | จำนวนครั้งทั้งหมดที่มอบหมายเหตุขัดข้องให้เจ้าหน้าที่หรือกลุ่มอื่น. | ||
| คำอธิบาย จำนวนครั้งที่มอบหมายใหม่ใช้วัดจำนวนครั้งที่มีการส่งต่องานระหว่างวงจรชีวิตของเหตุขัดข้อง จำนวนที่สูงมักบ่งชี้ถึงความไม่มีประสิทธิภาพ การส่งต่อไปยังทีมผิดตั้งแต่แรก หรือทีมสนับสนุนมีความรู้ไม่เพียงพอ. ข้อมูลนี้มีประโยชน์ต่อการวิเคราะห์ process mining แม้ process mining จะแสดงการมอบหมายงานใหม่ได้ แต่การมีจำนวนที่คำนวณไว้แล้วช่วยให้กรองข้อมูลและวัด KPI ได้ง่าย นอกจากนี้ยังใช้โดยตรงในแดชบอร์ดวิเคราะห์การส่งต่องานและการมอบหมายใหม่ เพื่อค้นหากรณีที่ทิกเก็ตถูกส่งกลับไปมาระหว่างทีมจนใช้เวลาแก้ไขนานขึ้นและสร้างความไม่พอใจให้ผู้ใช้. เหตุผลที่สำคัญ ตัวชี้วัดนี้แสดงความไม่มีประสิทธิภาพของกระบวนการโดยตรง จำนวนที่สูงมักสัมพันธ์กับเวลาแก้ไขที่นานขึ้น และบ่งชี้ถึงปัญหาในการส่งต่องานหรือความสามารถของทีม. แหล่งข้อมูล โดยทั่วไปมีเป็นช่องตัวนับมาตรฐานในระเบียนเหตุขัดข้อง หากไม่มี สามารถคำนวณได้จากจำนวนครั้งที่เปลี่ยนผู้รับผิดชอบในบันทึกการตรวจสอบของเหตุขัดข้อง. ตัวอย่าง 0135 | |||
| บริการที่ได้รับผลกระทบ AffectedService | บริการทางธุรกิจ แอปพลิเคชัน หรือรายการกำหนดค่า (CI) ที่ได้รับผลกระทบจากเหตุขัดข้อง. | ||
| คำอธิบาย บริการที่ได้รับผลกระทบเชื่อมโยงเหตุขัดข้องกับองค์ประกอบเฉพาะในโครงสร้างพื้นฐาน IT เช่น แอปพลิเคชันทางธุรกิจ เซิร์ฟเวอร์ หรืออุปกรณ์เครือข่าย โดยมักเชื่อมโยงกับฐานข้อมูลการจัดการการกำหนดค่า (CMDB). ข้อมูลนี้ช่วยให้เข้าใจบริบททางธุรกิจของเหตุขัดข้อง ในการทำ process mining สามารถใช้วิเคราะห์ความเสถียรของบริการหรือทรัพย์สินแต่ละรายการ องค์กรจะระบุได้ว่าบริการใดมีเหตุขัดข้องมากที่สุด วิเคราะห์กระบวนการแก้ไข และจัดลำดับความสำคัญของการจัดการปัญหาเพื่อเพิ่มเสถียรภาพให้บริการสำคัญทางธุรกิจ ข้อมูลนี้ยังช่วยให้เข้าใจผลกระทบโดยรวมของเหตุขัดข้องด้าน IT ต่อธุรกิจ. เหตุผลที่สำคัญ ข้อมูลนี้เชื่อมโยงเหตุขัดข้องกับบริการทางธุรกิจหรือองค์ประกอบ IT ที่เกี่ยวข้อง ช่วยวิเคราะห์ว่าบริการใดมีปัญหาบ่อยที่สุดและส่งผลกระทบอย่างไร. แหล่งข้อมูล โดยทั่วไปจะเชื่อมโยงจากฐานข้อมูลการจัดการการกำหนดค่า (CMDB) หรือเลือกจากรายการแค็ตตาล็อกบริการในแบบฟอร์มแจ้งเหตุขัดข้อง. ตัวอย่าง บริการอีเมลSAP ERP ด้านการเงินVPN ขององค์กรSRV-SQL-01 | |||
| ผู้แจ้ง Requester | ผู้ใช้ พนักงาน หรือระบบที่แจ้งเหตุขัดข้องในตอนแรก. | ||
| คำอธิบาย ผู้แจ้งคือบุคคลที่พบปัญหาและเริ่มแจ้งเหตุขัดข้อง อาจเป็นพนักงานภายในหรือผู้ใช้บริการภายนอก ข้อมูลนี้อาจระบุแผนกหรือองค์กรของผู้แจ้งด้วย. การวิเคราะห์เหตุขัดข้องตามผู้แจ้งหรือแผนกช่วยระบุกลุ่มผู้ใช้ที่พบปัญหามากกว่ากลุ่มอื่น ซึ่งอาจชี้ให้เห็นความต้องการฝึกอบรมหรือปัญหาด้านสภาพแวดล้อมเฉพาะพื้นที่ ใน process mining ข้อมูลนี้ช่วยให้มองกระบวนการสนับสนุนจากมุมมองของผู้ใช้ และทำความเข้าใจประสบการณ์ของผู้ใช้แต่ละกลุ่ม. เหตุผลที่สำคัญ ข้อมูลนี้ช่วยวิเคราะห์จากมุมมองของผู้ใช้ และระบุได้ว่าผู้ใช้ แผนก หรือสถานที่บางแห่งแจ้งเหตุขัดข้องมากกว่าสัดส่วนที่ควรหรือไม่. แหล่งข้อมูล เป็นช่องข้อมูลมาตรฐานในระเบียนเหตุขัดข้อง โดยทั่วไปจะระบุผู้ใช้ที่สร้างทิกเก็ตหรือผู้ใช้ที่แจ้งแทน. ตัวอย่าง Alice Johnsonฝ่ายขายb.williamsCustomer-XYZ Corp | |||
| สถานะ SLA SlaStatus | ระบุว่าเหตุขัดข้องยังอยู่ภายในเป้าหมายตามข้อตกลงระดับบริการ (SLA) มีความเสี่ยงที่จะเกินกำหนด หรือเกินกำหนดแล้ว. | ||
| คำอธิบาย สถานะ SLA แสดงผลการดำเนินงานของเหตุขัดข้องเมื่อเทียบกับกรอบเวลาที่กำหนดไว้ เช่น เวลาตอบรับหรือเวลาแก้ไขให้เสร็จ สถานะที่พบบ่อย ได้แก่ “กำลังดำเนินการ” “เสี่ยงเกินกำหนด” และ “เกินกำหนดแล้ว” แอตทริบิวต์นี้ใช้วัดคุณภาพบริการโดยตรง และเป็นข้อมูลสำคัญสำหรับแดชบอร์ดภาพรวมผลการดำเนินงานตาม SLA ใน process mining คุณสามารถเปรียบเทียบเส้นทางกระบวนการของเหตุขัดข้องที่เกินกำหนดกับเหตุขัดข้องที่ไม่เกินกำหนด เพื่อระบุกิจกรรม ความล่าช้า หรือการทำงานซ้ำที่เป็นสาเหตุหลักของการผิด SLA และนำไปปรับปรุงกระบวนการได้ตรงจุด. เหตุผลที่สำคัญ ใช้วัดผลการดำเนินงานเทียบกับเป้าหมายโดยตรง การวิเคราะห์เหตุขัดข้องที่เกินกำหนดช่วยระบุปัญหาในกระบวนการที่ทำให้บริการมีคุณภาพต่ำ. แหล่งข้อมูล โดยทั่วไป ฟิลด์นี้คำนวณภายในเครื่องมือ ITSM และอัปเดตโดยอัตโนมัติตามลำดับความสำคัญ อายุของเหตุขัดข้อง และกฎ SLA ที่กำหนดไว้. ตัวอย่าง กำลังดำเนินการหยุดชั่วคราวเกินกำหนดแล้วเสี่ยงเกินกำหนด | |||
กิจกรรมในการจัดการเหตุการณ์
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| แก้ไขเหตุขัดข้องแล้ว | กิจกรรมนี้ระบุว่าได้นำวิธีแก้ไขไปใช้แล้ว และคาดว่าผู้ใช้จะกลับมาใช้บริการได้ตามปกติ โดยทั่วไปเหตุการณ์สำคัญนี้จะหยุดการนับเวลาแก้ไขตาม SLA. | ||
| เหตุผลที่สำคัญ จุดนี้เป็นจุดสิ้นสุดหลักสำหรับวัดเวลาแก้ไข ช่วงเวลาตั้งแต่จุดนี้จนถึงการปิดเหตุขัดข้องอย่างเป็นทางการมีความสำคัญต่อการวิเคราะห์ความล่าช้าในการยืนยันจากผู้ใช้หรือนโยบายปิดเหตุขัดข้องอัตโนมัติ. แหล่งข้อมูล โดยทั่วไปเหตุการณ์นี้จะถูกบันทึกไว้อย่างชัดเจนเมื่อเจ้าหน้าที่เปลี่ยนสถานะเหตุขัดข้องเป็น 'Resolved' หรือ 'Solved'. บันทึก ใช้เวลาจากบันทึกการตรวจสอบเมื่อมีการเปลี่ยนสถานะเหตุขัดข้องเป็น 'Resolved'. ประเภทเหตุการณ์ explicit | |||
| ตรวจพบการผิด SLA | เหตุการณ์ที่คำนวณได้ ซึ่งเกิดขึ้นเมื่อเวลาตอบสนองหรือแก้ไขเหตุขัดข้องเกินเป้าหมายที่กำหนดไว้ในข้อตกลงระดับการให้บริการ (SLA) เหตุการณ์นี้ไม่ได้เกิดจากการดำเนินการด้วยตนเองของผู้ใช้ แต่เกิดจากเวลาที่ผ่านไป. | ||
| เหตุผลที่สำคัญ การละเมิด SLA เป็น KPI หลัก การวิเคราะห์ว่าเกิดขึ้นเมื่อใดและเพราะเหตุใดจึงสำคัญต่อการยกระดับบริการและการปฏิบัติตามข้อผูกพันตามสัญญา. แหล่งข้อมูล เหตุการณ์นี้ไม่ได้บันทึกไว้โดยตรงในบันทึกเหตุการณ์ แต่คำนวณได้จากการเปรียบเทียบเวลาของเหตุการณ์กับกำหนดเวลาตาม SLA ที่ระบุในระเบียนเหตุขัดข้อง. บันทึก เปรียบเทียบเวลาที่แก้ไขเหตุขัดข้องกับ 'วันครบกำหนด SLA' หากแก้ไขหลังจากกำหนด ให้สร้างเหตุการณ์การละเมิด SLA โดยใช้เวลาครบกำหนดตาม SLA. ประเภทเหตุการณ์ calculated | |||
| ปิดเหตุขัดข้องแล้ว | กิจกรรมสุดท้ายในวงจรชีวิตของเหตุขัดข้อง เมื่อปิดระเบียนอย่างเป็นทางการและเปลี่ยนเป็นข้อมูลย้อนหลังที่อ่านได้อย่างเดียว โดยมักปิดอัตโนมัติหลังจากอยู่ในสถานะ 'Resolved' ตามระยะเวลาที่กำหนด. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้เป็นจุดสิ้นสุดของวงจรชีวิตเหตุขัดข้องอย่างสมบูรณ์ การวิเคราะห์เวลาตั้งแต่สร้างจนถึงปิดช่วยให้เห็นระยะเวลาของกระบวนการทั้งหมด รวมถึงช่วงดำเนินการด้านธุรการหลังแก้ไขแล้ว. แหล่งข้อมูล บันทึกจากการเปลี่ยนสถานะเป็น 'Closed' ในประวัติเหตุขัดข้อง ซึ่งระบุเวลาสิ้นสุดไว้อย่างชัดเจน. บันทึก ใช้เวลาจากบันทึกการตรวจสอบเมื่อมีการเปลี่ยนสถานะเหตุขัดข้องเป็น 'Closed'. ประเภทเหตุการณ์ explicit | |||
| เปิดเหตุขัดข้องอีกครั้ง | เกิดขึ้นเมื่อเหตุขัดข้องที่แก้ไขแล้วกลับมาอยู่ในสถานะที่กำลังดำเนินการ โดยมักเกิดเมื่อผู้ใช้แจ้งว่าปัญหาเกิดขึ้นอีก หรือวิธีแก้ไขที่ให้ไปไม่ได้ผล. | ||
| เหตุผลที่สำคัญ อัตราการเปิดเหตุขัดข้องซ้ำที่สูงบ่งชี้ถึงปัญหาด้านคุณภาพการแก้ไข การวิเคราะห์สาเหตุที่แท้จริงไม่ครบถ้วน หรือการปิดเหตุขัดข้องเร็วเกินไป ตัวชี้วัดนี้สำคัญต่อการวิเคราะห์งานแก้ไขซ้ำ. แหล่งข้อมูล อนุมานจากประวัติสถานะ เมื่อสถานะเหตุขัดข้องเปลี่ยนจาก 'Resolved' หรือ 'Closed' กลับไปเป็นสถานะที่กำลังดำเนินการ เช่น 'In Progress'. บันทึก ตรวจจับการเปลี่ยนสถานะจากสถานะที่แก้ไขแล้วเป็นสถานะเปิด และบันทึกเวลาที่เปลี่ยนสถานะ. ประเภทเหตุการณ์ inferred | |||
| มอบหมายให้กลุ่ม | หมายถึงการมอบหมายเหตุขัดข้องให้กลุ่มสนับสนุนหรือทีมที่รับผิดชอบตรวจสอบเป็นครั้งแรก นี่คือการส่งต่องานอย่างเป็นทางการครั้งแรกและเป็นจุดเริ่มต้นของเวิร์กโฟลว์การแก้ไข. | ||
| เหตุผลที่สำคัญ นี่คือขั้นตอนสำคัญในการส่งงาน ความล่าช้าในการมอบหมายหรือการส่งงานผิดทีมอาจทำให้เวลาแก้ไขเพิ่มขึ้นอย่างมาก และเกิดการส่งต่องานระหว่างทีมโดยไม่จำเป็น. แหล่งข้อมูล อนุมานเหตุการณ์นี้จากบันทึกการตรวจสอบ โดยค้นหาครั้งแรกที่มีการกรอกฟิลด์ 'Assignment Group' หรือ 'Support Team'. บันทึก ระบุเวลาที่มีการกรอกฟิลด์ 'Assignment Group' ในประวัติเหตุขัดข้องเป็นครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| เริ่มตรวจสอบ | หมายถึงเจ้าหน้าที่ที่ได้รับมอบหมายเริ่มดำเนินการกับเหตุขัดข้อง โดยมักแสดงจากการเปลี่ยนสถานะจาก 'Assigned' หรือ 'New' เป็น 'In Progress'. | ||
| เหตุผลที่สำคัญ หมุดหมายนี้เป็นจุดสิ้นสุดของเวลารอในคิวช่วงแรกและเป็นจุดเริ่มต้นของการลงมือทำ การวัดเวลาจนถึงกิจกรรมนี้ช่วยให้เข้าใจขีดความสามารถของเจ้าหน้าที่และความล่าช้าในการตอบสนอง. แหล่งข้อมูล โดยทั่วไปอนุมานจากการเปลี่ยนสถานะในบันทึกประวัติของเหตุขัดข้อง. บันทึก ระบุเวลาที่สถานะเหตุขัดข้องเปลี่ยนเป็น 'In Progress', 'Work in Progress' หรือสถานะดำเนินการอื่นเป็นครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| สร้างเหตุขัดข้อง | กิจกรรมนี้บันทึกการสร้างรายการเหตุขัดข้องอย่างเป็นทางการในระบบ ถือเป็นจุดเริ่มต้นที่ชัดเจนของวงจรเหตุขัดข้อง โดยบันทึกการแจ้งเหตุครั้งแรกจากผู้ใช้หรือเครื่องมือตรวจสอบระบบ. | ||
| เหตุผลที่สำคัญ นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ การวิเคราะห์เวลาตั้งแต่สร้างรายการจนถึงหมุดหมายอื่นๆ เป็นพื้นฐานสำคัญในการวัดเวลาแก้ไขโดยรวมและค้นหาความล่าช้าในช่วงต้น. แหล่งข้อมูล โดยทั่วไปจะดึงข้อมูลนี้จากเวลาที่สร้างรายการในตารางเหตุขัดข้องหลักหรือทิกเก็ตของระบบต้นทาง. บันทึก ใช้เวลาจากฟิลด์ 'create_date' หรือ 'submitted_on' ในรายการเหตุขัดข้องหลัก. ประเภทเหตุการณ์ explicit | |||
| กลับมาดำเนินงาน | บันทึกเวลาที่เหตุขัดข้องซึ่งพักไว้กลับมาดำเนินการอีกครั้ง โดยทั่วไปเกิดขึ้นเมื่อได้รับข้อมูลที่ต้องการ ทำให้เจ้าหน้าที่สนับสนุนทำงานต่อได้. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการวัดระยะเวลาที่รอปัจจัยภายนอกอย่างถูกต้อง เวลาระหว่าง 'Pending' กับ 'Resumed' แสดงว่ากระบวนการหยุดชะงักเพราะปัจจัยภายนอกนานเพียงใด. แหล่งข้อมูล อนุมานจากประวัติสถานะของเหตุขัดข้องเมื่อเปลี่ยนจากสถานะ 'Pending' กลับเป็น 'In Progress' หรือสถานะดำเนินการอื่น. บันทึก บันทึกเวลาที่สถานะเหตุขัดข้องเปลี่ยนจากสถานะ 'รอดำเนินการ' กลับมาเป็นสถานะดำเนินการ. ประเภทเหตุการณ์ inferred | |||
| กำหนดลำดับความสำคัญของเหตุขัดข้อง | กิจกรรมนี้เกิดขึ้นเมื่อกำหนดลำดับความสำคัญของเหตุขัดข้อง โดยทั่วไปจะพิจารณาจากผลกระทบและความเร่งด่วน ระดับความสำคัญจะกำหนดเวลาเป้าหมายในการตอบสนองและแก้ไขตามข้อตกลงระดับการให้บริการ (SLA). | ||
| เหตุผลที่สำคัญ การจัดลำดับความสำคัญส่งผลโดยตรงต่อการจัดสรรทรัพยากรและลำดับการจัดการเหตุขัดข้อง การวิเคราะห์ขั้นตอนนี้ช่วยให้มั่นใจว่าเหตุขัดข้องระดับวิกฤตได้รับการจัดการก่อนและทำตาม SLA ได้. แหล่งข้อมูล ตรวจจับกิจกรรมนี้จากบันทึกการตรวจสอบ โดยติดตามการเปลี่ยนแปลงในฟิลด์ 'Priority' หรือ 'Severity'. บันทึก ใช้เวลาจากบันทึกการตรวจสอบที่เกี่ยวข้องกับการอัปเดตฟิลด์ 'Priority'. ประเภทเหตุการณ์ explicit | |||
| จัดหมวดหมู่เหตุขัดข้อง | หมายถึงการจำแนกเหตุขัดข้อง รวมถึงการกำหนดหมวดหมู่ ประเภท และรายการย่อย ขั้นตอนคัดแยกนี้สำคัญต่อการส่งเหตุขัดข้องไปยังทีมที่เหมาะสมและเลือกวิธีแก้ไขที่ถูกต้อง. | ||
| เหตุผลที่สำคัญ การจัดหมวดหมู่ผิดอาจทำให้ล่าช้า ต้องมอบหมายงานใหม่ และทำให้รายงานคลาดเคลื่อน การวิเคราะห์กิจกรรมนี้ช่วยประเมินคุณภาพของการคัดแยกเบื้องต้นและผลต่อประสิทธิภาพการแก้ไข. แหล่งข้อมูล โดยทั่วไปอนุมานเหตุการณ์นี้จากบันทึกการตรวจสอบหรือตารางประวัติ โดยระบุครั้งแรกที่มีการกรอกข้อมูลในฟิลด์เกี่ยวกับการจัดหมวดหมู่. บันทึก ตรวจหาการอัปเดตครั้งแรกของฟิลด์ เช่น 'Category', 'Subcategory' หรือ 'Configuration Item' หลังจากสร้างเหตุขัดข้อง. ประเภทเหตุการณ์ inferred | |||
| แจ้งวิธีแก้ไขชั่วคราว | หมายถึงการแจ้งวิธีแก้ไขชั่วคราวให้ผู้ใช้เพื่อให้บริการกลับมาใช้งานได้ ช่วยลดผลกระทบต่อธุรกิจระหว่างที่กำลังพัฒนาวิธีแก้ไขถาวร. | ||
| เหตุผลที่สำคัญ การแจ้งวิธีแก้ไขชั่วคราวเป็นขั้นตอนสำคัญในการจัดการเหตุขัดข้องร้ายแรง และช่วยแยกเวลาที่ใช้บรรเทาปัญหาออกจากเวลาที่ใช้แก้ไขถาวร. แหล่งข้อมูล อาจบันทึกเป็นสถานะหรือธงระบุโดยตรง แต่บ่อยครั้งอนุมานจากบันทึกของเจ้าหน้าที่หรือบันทึกการสื่อสารด้วยการค้นหาคำสำคัญ. บันทึก ระบุจากสถานะเฉพาะ เช่น 'Workaround Provided' หรือค้นหาคำอย่าง 'workaround' หรือ 'temporary fix' ในความคิดเห็นของเจ้าหน้าที่. ประเภทเหตุการณ์ inferred | |||
| เปลี่ยนสถานะเป็นรอดำเนินการ | เกิดขึ้นเมื่อหยุดดำเนินการกับเหตุขัดข้องชั่วคราว โดยทั่วไปเพื่อรอข้อมูลจากผู้ใช้ ผู้ให้บริการ หรือปัจจัยภายนอกอื่น สถานะนี้มักหยุดนับเวลา SLA. | ||
| เหตุผลที่สำคัญ การวิเคราะห์เวลาที่อยู่ในสถานะรอดำเนินการช่วยให้เห็นการพึ่งพาปัจจัยภายนอกและความล่าช้า เวลารอที่นานเกินไปอาจบดบังความไม่มีประสิทธิภาพภายในและทำให้ตัวชี้วัดเวลาแก้ไขคลาดเคลื่อน. แหล่งข้อมูล อนุมานจากประวัติสถานะของเหตุขัดข้องเมื่อเปลี่ยนเป็น 'Pending', 'On Hold' หรือ 'Awaiting User'. บันทึก บันทึกเวลาทุกครั้งที่สถานะเหตุขัดข้องเปลี่ยนเป็นสถานะ 'รอดำเนินการ' ที่กำหนดไว้. ประเภทเหตุการณ์ inferred | |||
| มอบหมายเหตุขัดข้องใหม่ | หมายถึงการส่งเหตุขัดข้องจากกลุ่มสนับสนุนหรือเจ้าหน้าที่คนหนึ่งไปยังอีกกลุ่มหรืออีกคนหนึ่ง การส่งต่องานนี้มักเกิดขึ้นเมื่อทีมแรกแก้ปัญหาไม่ได้และต้องใช้ความเชี่ยวชาญด้านอื่น. | ||
| เหตุผลที่สำคัญ การมอบหมายงานใหม่บ่อยครั้งเป็นสัญญาณชัดเจนว่ากระบวนการไม่มีประสิทธิภาพ ส่งงานผิดทีมตั้งแต่แรก หรือทีมขาดความรู้ การวิเคราะห์การส่งต่องานเหล่านี้เป็นกุญแจสำคัญในการปรับขั้นตอนการแก้ไขให้คล่องตัว. แหล่งข้อมูล อนุมานจากบันทึกการตรวจสอบ โดยตรวจจับการเปลี่ยนแปลงใดๆ ในฟิลด์ 'Assignment Group' หรือ 'Assignee' หลังจากมอบหมายครั้งแรก. บันทึก บันทึกเหตุการณ์ใหม่ทุกครั้งที่ฟิลด์ 'Assignment Group' เปลี่ยนแปลงหลังจากกรอกข้อมูลครั้งแรก. ประเภทเหตุการณ์ inferred | |||
| มอบหมายให้เจ้าหน้าที่ | กิจกรรมนี้บันทึกเวลาที่เจ้าหน้าที่คนใดคนหนึ่งรับหรือได้รับมอบหมายให้ดูแลเหตุขัดข้อง เป็นการเปลี่ยนจากความรับผิดชอบระดับทีมไปสู่ความรับผิดชอบของบุคคล. | ||
| เหตุผลที่สำคัญ การติดตามการมอบหมายให้เจ้าหน้าที่ช่วยวิเคราะห์ภาระงานและประสิทธิภาพของแต่ละคน รวมถึงค้นหาคอขวดที่เหตุขัดข้องต้องรอเจ้าหน้าที่ว่าง. แหล่งข้อมูล ติดตามจากการเปลี่ยนแปลงฟิลด์ 'Assignee' หรือ 'Assigned To' ในบันทึกการตรวจสอบของเหตุขัดข้อง. บันทึก ใช้เวลาจากบันทึกการตรวจสอบเมื่อมีการกรอกฟิลด์ 'Assignee' เป็นครั้งแรก หรือเปลี่ยนเป็นผู้ใช้รายใหม่. ประเภทเหตุการณ์ explicit | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงกระบวนการจัดการเหตุขัดข้องได้วันนี้ เลือกคู่มือดึงข้อมูลสำหรับระบบของคุณด้านล่าง หรือใช้เทมเพลตทั่วไปนี้เพื่อเริ่มสร้างบันทึกเหตุการณ์สำหรับวิเคราะห์กระบวนการ.
แก้ไขเหตุการณ์ให้เร็วขึ้น เริ่มปรับปรุงได้เลย
ระบุคอขวด ลดเวลาหยุดให้บริการ และเพิ่มประสิทธิภาพของทีม.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จใน 5 นาที