เทมเพลตข้อมูลการจัดการเหตุขัดข้อง
เทมเพลตข้อมูลการจัดการเหตุขัดข้อง
- คุณลักษณะที่แนะนำให้เก็บ
- กิจกรรมสำคัญที่ควรติดตาม
- แนวทางดึงข้อมูลจาก Jira Service Management
คุณลักษณะของการจัดการเหตุขัดข้อง
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
ActivityName
|
ชื่อเหตุการณ์หรือการเปลี่ยนสถานะที่เกิดขึ้นกับ Incident. | ||
|
คำอธิบาย
กิจกรรมคือขั้นตอนหรือเหตุการณ์หนึ่งในวงจรการจัดการ Incident เช่น 'สร้าง Incident', 'มอบหมาย Incident' หรือ 'เสนอแนวทางแก้ไข' โดยทั่วไปข้อมูลเหล่านี้ได้มาจากการเปลี่ยนสถานะหรือเหตุการณ์อัปเดตที่บันทึกไว้ในประวัติหรือ changelog ของ Jira Issue การวิเคราะห์ลำดับและระยะเวลาของกิจกรรมเป็นเป้าหมายหลักของ process mining ซึ่งช่วยให้เห็นขั้นตอนการทำงานจริง คอขวด และจุดที่กระบวนการเบี่ยงเบนไป.
เหตุผลที่สำคัญ
กิจกรรมเป็นองค์ประกอบหลักของแผนผังกระบวนการ ช่วยให้เห็นภาพและวิเคราะห์วงจรการจัดการ Incident ได้.
แหล่งข้อมูล
ดึงข้อมูลจากประวัติและ changelog ของ Jira Issue เพื่อบันทึกการเปลี่ยนสถานะและการอัปเดตฟิลด์สำคัญ.
ตัวอย่าง
มอบหมายเหตุขัดข้องเริ่มตรวจสอบแก้ไขเหตุขัดข้องแล้ว
|
|||
|
รหัส Incident
IncidentId
|
รหัสเฉพาะของ Ticket Incident แต่ละรายการใน Jira Service Management. | ||
|
คำอธิบาย
รหัส Incident ซึ่งมักเรียกว่า Issue Key ใน Jira เป็นรหัสเฉพาะหลักของ Incident ที่มีการแจ้งเข้ามาแต่ละรายการ รหัสนี้เชื่อมโยงกิจกรรม ความคิดเห็น และการเปลี่ยนสถานะทั้งหมด ตั้งแต่สร้าง Incident จนถึงปิดรายการ ใน process mining รหัสนี้จำเป็นต่อการสร้างลำดับเหตุการณ์ตลอดวงจรของ Incident แต่ละรายการขึ้นใหม่ และช่วยให้วิเคราะห์กระบวนการได้ครบถ้วน.
เหตุผลที่สำคัญ
รหัสนี้ใช้เชื่อมโยงเหตุการณ์ที่เกี่ยวข้องทั้งหมดให้เป็นเคสเดียว จึงเป็นข้อมูลพื้นฐานสำหรับการวิเคราะห์ process mining.
แหล่งข้อมูล
นี่คือช่อง 'Key' มาตรฐานของ Issue ใน Jira Service Management เช่น 'ITSM-123'.
ตัวอย่าง
INC-10234HELPDESK-5678OPS-9901
|
|||
|
เวลาเริ่มต้น
EventTimestamp
|
วันและเวลาที่กิจกรรมเกิดขึ้นอย่างแน่นอน. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกเวลาที่เกิดกิจกรรมแต่ละรายการตลอดวงจรของ Incident ซึ่งจำเป็นต่อการคำนวณระยะเวลา เวลาที่ใช้ในแต่ละรอบ และเวลารอระหว่างขั้นตอน การบันทึกเวลาอย่างถูกต้องช่วยให้วิเคราะห์ประสิทธิภาพ ติดตาม SLA และค้นหาคอขวดได้อย่างละเอียด ตัวชี้วัดด้านประสิทธิภาพ เช่น เวลาจนแก้ปัญหาเสร็จและระยะเวลาวินิจฉัย ล้วนคำนวณจากข้อมูลเวลาเหล่านี้.
เหตุผลที่สำคัญ
ข้อมูลเวลาจำเป็นต่อการคำนวณตัวชี้วัดด้านเวลา ทำความเข้าใจระยะเวลาของกระบวนการ และค้นหาคอขวดด้านประสิทธิภาพ.
แหล่งข้อมูล
นี่คือวันที่ 'created' ของแต่ละรายการใน changelog หรือประวัติของ Jira Issue.
ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่ดึงข้อมูลออกมา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุแหล่งที่มาของข้อมูล ซึ่งในกรณีนี้คือ Jira Service Management มีประโยชน์เป็นพิเศษเมื่อรวมข้อมูลจากหลายระบบเพื่อดูภาพรวมของกระบวนการ การระบุระบบต้นทางช่วยให้ตรวจสอบที่มาของข้อมูลได้ชัดเจน และช่วยวินิจฉัยปัญหาด้านคุณภาพข้อมูลหรือการดึงข้อมูล สำหรับโมเดลนี้ ค่าดังกล่าวจะเป็นค่าเดียวกันเสมอ.
เหตุผลที่สำคัญ
ระบุที่มาของข้อมูลให้ชัดเจนและตรวจสอบย้อนกลับได้ โดยเฉพาะเมื่อต้องวิเคราะห์ข้อมูลจากหลายระบบ.
แหล่งข้อมูล
เป็นค่าคงที่ที่ควรเพิ่มระหว่างการดึงข้อมูล.
ตัวอย่าง
Jira Service ManagementJira Cloud
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ระบุว่ามีการรีเฟรชข้อมูลจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกเวลาที่อัปเดตชุดข้อมูลล่าสุด เพื่อให้ผู้วิเคราะห์ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด เรื่องนี้สำคัญเป็นพิเศษสำหรับแดชบอร์ดติดตามผลอย่างต่อเนื่อง ซึ่งต้องใช้ข้อมูลล่าสุดประกอบการตัดสินใจได้ทันเวลา โดยทั่วไปเหตุการณ์ทั้งหมดที่ดึงข้อมูลมาในรอบเดียวกันจะมีค่าเวลานี้เหมือนกัน.
เหตุผลที่สำคัญ
ช่วยให้ผู้ใช้ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด ซึ่งมีผลต่อความเกี่ยวข้องและความถูกต้องของการวิเคราะห์.
แหล่งข้อมูล
นี่คือเวลาที่ดึงข้อมูล ซึ่งเพิ่มเข้ามาระหว่างการแปลงข้อมูล.
ตัวอย่าง
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
กลุ่มผู้รับผิดชอบ
AssignmentGroup
|
ทีมที่รับผิดชอบจัดการ Incident. | ||
|
คำอธิบาย
กลุ่มผู้รับผิดชอบคือทีมที่ได้รับมอบหมายให้ดูแล Incident ซึ่งอาจเป็นทีมสนับสนุนระดับหนึ่ง เช่น 'L1 Helpdesk' ทีมเฉพาะทาง เช่น 'Network Operations' หรือทีมพัฒนา การวิเคราะห์การเปลี่ยนกลุ่มผู้รับผิดชอบช่วยให้เข้าใจการยกระดับปัญหาและการส่งต่องาน อีกทั้งยังใช้วัดประสิทธิภาพของทีม ระบุคอขวดในระดับทีม และวิเคราะห์การพึ่งพากันระหว่างทีมได้.
เหตุผลที่สำคัญ
จำเป็นต่อการวิเคราะห์ประสิทธิภาพและปริมาณงานของทีม รวมถึงการไหลของงานระหว่างระดับการสนับสนุนหรือกลุ่มเฉพาะทาง.
แหล่งข้อมูล
มักกำหนดเป็นฟิลด์แบบกำหนดเองใน Jira เช่น 'Team' หรือ 'Assignment Group' บางกรณีอาจอนุมานจาก Jira Components หรือ Project Roles ได้.
ตัวอย่าง
ทีมสนับสนุนระดับ 1ทีมโครงสร้างพื้นฐานผู้ดูแลฐานข้อมูล
|
|||
|
ผู้รับผิดชอบ
Assignee
|
ผู้ใช้ที่ได้รับมอบหมายให้จัดการ Incident ในขณะนั้น. | ||
|
คำอธิบาย
ผู้รับผิดชอบคือเจ้าหน้าที่หรือผู้ใช้ที่ดูแล Incident ในช่วงเวลาหนึ่ง การติดตามการเปลี่ยนผู้รับผิดชอบช่วยวิเคราะห์การส่งต่องาน ทำความเข้าใจการกระจายภาระงาน และระบุผู้ที่เกี่ยวข้องในแต่ละขั้นตอน แอตทริบิวต์นี้ช่วยตอบคำถามเกี่ยวกับประสิทธิภาพการทำงานรายบุคคลและการจัดสรรทรัพยากรในทีมสนับสนุน.
เหตุผลที่สำคัญ
ช่วยติดตามภาระงานรายบุคคล ระบุคอขวดที่เกี่ยวข้องกับเจ้าหน้าที่แต่ละคน และวิเคราะห์ผลของการส่งต่องานต่อเวลาที่ใช้แก้ปัญหา.
แหล่งข้อมูล
ฟิลด์ 'Assignee' มาตรฐานใน Jira Issue.
ตัวอย่าง
John SmithEmily JonesServiceDeskAgent1
|
|||
|
ลำดับความสำคัญ
Priority
|
ระดับความสำคัญที่กำหนดให้ Incident เพื่อบอกความเร่งด่วนในการแก้ไข. | ||
|
คำอธิบาย
ลำดับความสำคัญกำหนดความเร็วที่ต้องใช้ในการจัดการ Incident โดยมักพิจารณาจากผลกระทบและความเร่งด่วนร่วมกัน และมีผลโดยตรงต่อเป้าหมาย SLA การวิเคราะห์ Incident ตามลำดับความสำคัญช่วยให้เห็นว่า Incident ที่มีความสำคัญสูงได้รับการจัดการเร็วกว่ารายการที่มีความสำคัญต่ำหรือไม่ และมีการจัดลำดับความสำคัญอย่างสม่ำเสมอหรือไม่ นอกจากนี้ยังเป็นมิติสำคัญสำหรับกรองและเปรียบเทียบประสิทธิภาพของกระบวนการ.
เหตุผลที่สำคัญ
จำเป็นต่อการวิเคราะห์ผลการดำเนินงานตาม SLA และตรวจสอบว่ามีการจัดสรรทรัพยากรให้ Incident ที่สำคัญที่สุดอย่างเหมาะสมหรือไม่.
แหล่งข้อมูล
ฟิลด์ 'Priority' มาตรฐานใน Jira Issue.
ตัวอย่าง
สูงสุดสูงปานกลางต่ำ
|
|||
|
วันที่แก้ไขแล้ว
ResolutionDate
|
วันและเวลาที่ทำเครื่องหมายว่า Incident แก้ไขแล้ว. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกเวลาที่เปลี่ยน Incident ไปเป็นสถานะแก้ไขแล้วเป็นครั้งแรก ซึ่งเป็นจุดสิ้นสุดของช่วงที่มีการดำเนินงาน และใช้เป็นเวลาสิ้นสุดในการคำนวณเวลาจนแก้ปัญหาเสร็จ เมื่อนำวันที่แก้ไขเสร็จมาเปรียบเทียบกับวันที่สร้าง จะได้ตัวชี้วัดหลักสำหรับประเมินประสิทธิภาพของกระบวนการ นอกจากนี้ยังเป็นองค์ประกอบสำคัญในการพิจารณาการปฏิบัติตาม SLA.
เหตุผลที่สำคัญ
ระบุจุดสิ้นสุดของกระบวนการแก้ไข เพื่อคำนวณเวลารวมของแต่ละรอบและผลการดำเนินงานตาม SLA.
แหล่งข้อมูล
ฟิลด์ 'Resolved' มาตรฐานใน Jira Issue.
ตัวอย่าง
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
วันที่สร้าง
CreatedDate
|
วันและเวลาที่สร้าง Incident ในระบบเป็นครั้งแรก. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุจุดเริ่มต้นอย่างเป็นทางการของวงจร Incident และเป็นเวลาอ้างอิงสำหรับคำนวณตัวชี้วัดโดยรวม เช่น เวลาทั้งหมดจนแก้ปัญหาเสร็จ วันที่สร้างเป็นค่าคงที่ของ Incident แต่ละรายการ และใช้เป็นจุดเริ่มต้นของเคสในการวิเคราะห์ process mining.
เหตุผลที่สำคัญ
ใช้เป็นจุดเริ่มต้นในการคำนวณเวลาตั้งแต่ต้นจนจบของแต่ละรอบและการวัด SLA.
แหล่งข้อมูล
ฟิลด์ 'Created' มาตรฐานใน Jira Issue.
ตัวอย่าง
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
สถานะ
Status
|
ขั้นตอนปัจจุบันของ Incident ในวงจรการดำเนินงาน. | ||
|
คำอธิบาย
ฟิลด์ Status แสดงสถานะปัจจุบันของ Incident ในเวิร์กโฟลว์ที่กำหนดไว้ เช่น 'เปิด', 'กำลังดำเนินการ', 'รอลูกค้า' หรือ 'แก้ไขแล้ว' การเปลี่ยนสถานะเป็นแหล่งข้อมูลหลักสำหรับสร้างบันทึกกิจกรรมเพื่อใช้ใน process mining การวิเคราะห์เวลาที่ใช้ในแต่ละสถานะเป็นพื้นฐานสำคัญในการค้นหาคอขวดและทำความเข้าใจว่า Incident ใช้เวลาส่วนใหญ่อยู่ในขั้นตอนใด.
เหตุผลที่สำคัญ
แสดงความคืบหน้าของ Incident โดยตรง และเป็นแหล่งข้อมูลหลักในการระบุขั้นตอนของกระบวนการและเวลารอ.
แหล่งข้อมูล
ฟิลด์ 'Status' มาตรฐานใน Jira Issue.
ตัวอย่าง
กำลังดำเนินการรอลูกค้าแก้ไขแล้วปิดแล้ว
|
|||
|
จำนวนครั้งที่ส่งต่องาน
HandoffCount
|
จำนวนครั้งที่มอบหมาย Incident ใหม่ให้กลุ่มหรือผู้ใช้อื่น. | ||
|
คำอธิบาย
ตัวชี้วัดที่คำนวณขึ้นนี้นับจำนวนครั้งที่ฟิลด์ 'Assignee' หรือ 'AssignmentGroup' เปลี่ยนแปลงตลอดวงจรของ Incident หากมีการส่งต่องานหลายครั้ง มักบ่งชี้ถึงกระบวนการที่ไม่มีประสิทธิภาพ การแก้ปัญหาไม่สำเร็จตั้งแต่ครั้งแรก หรือช่องว่างด้านความรู้ ซึ่งทำให้ใช้เวลาแก้ปัญหานานขึ้น การวิเคราะห์ KPI นี้ช่วยปรับขั้นตอนการมอบหมายงานให้คล่องตัวและเพิ่มความร่วมมือระหว่างทีม.
เหตุผลที่สำคัญ
วัดความติดขัดและความไม่มีประสิทธิภาพที่เกิดจากการมอบหมายงานใหม่ ช่วยระบุโอกาสในการปรับปรุงกระบวนการ.
แหล่งข้อมูล
คำนวณโดยนับจำนวนครั้งที่ฟิลด์ 'Assignee' หรือ 'AssignmentGroup' เปลี่ยนแปลงใน changelog ของ Issue.
ตัวอย่าง
015
|
|||
|
ประเภท Issue
IssueType
|
ประเภทของ Issue เช่น Incident, Service Request หรือ Problem. | ||
|
คำอธิบาย
Jira ใช้ Issue Types เพื่อแยกงานแต่ละประเภท ในบริบทของการจัดการ Incident ประเภทหลักคือ 'Incident' แต่อาจมีประเภทอื่นที่เกี่ยวข้อง เช่น 'Sub-task' แอตทริบิวต์นี้สำคัญต่อการกรองชุดข้อมูลให้เหลือเฉพาะ Incident เพื่อให้การวิเคราะห์ process mining มุ่งไปที่กระบวนการที่ถูกต้อง.
เหตุผลที่สำคัญ
ช่วยกำหนดขอบเขตการวิเคราะห์ให้ตรงกับ Incident และแยกออกจากงานประเภทอื่น เช่น คำขอรับบริการหรือการเปลี่ยนแปลง.
แหล่งข้อมูล
ฟิลด์ 'Issue Type' มาตรฐานใน Jira Issue.
ตัวอย่าง
Incidentความช่วยเหลือด้านไอทีข้อบกพร่องของซอฟต์แวร์
|
|||
|
ประเภทคำขอจากลูกค้า
CustomerRequestType
|
ประเภทคำขอที่ลูกค้าส่งผ่านพอร์ทัลบริการ. | ||
|
คำอธิบาย
ฟิลด์นี้จัดหมวดหมู่คำขอตามมุมมองของลูกค้า โดยแสดงบนพอร์ทัล Jira Service Management เช่น 'แจ้งปัญหาระบบ' ซึ่งเป็นการจัดประเภท Incident ที่เข้าใจง่ายสำหรับผู้ใช้ และอาจแตกต่างจาก 'Issue Type' ภายใน การวิเคราะห์แอตทริบิวต์นี้ช่วยให้เข้าใจว่าลูกค้ามองและแจ้งปัญหาอย่างไร เพื่อนำไปปรับปรุงพอร์ทัลและบริการที่นำเสนอ.
เหตุผลที่สำคัญ
แสดงหมวดหมู่ Incident จากมุมมองของลูกค้า ซึ่งมีประโยชน์ต่อการวิเคราะห์ความต้องการและปรับปรุงประสบการณ์ของลูกค้า.
แหล่งข้อมูล
ฟิลด์ 'Customer Request Type' ซึ่งใช้เฉพาะในโปรเจกต์ Jira Service Management.
ตัวอย่าง
ขอความช่วยเหลือด้านไอที > แจ้งปัญหาระบบอีเมล > คำขอสิทธิ์เข้าถึง
|
|||
|
เป้าหมายเวลาจนแก้ปัญหาเสร็จ
TimeToResolutionTarget
|
ระยะเวลาเป้าหมายตาม SLA สำหรับแก้ Incident ให้เสร็จ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้กำหนดระยะเวลาสูงสุดที่คาดไว้สำหรับแก้ Incident ตามลำดับความสำคัญหรือประเภทที่กำหนด ใช้เป็นเกณฑ์เปรียบเทียบกับเวลาที่ใช้แก้ปัญหาจริง เพื่อพิจารณาการปฏิบัติตาม SLA โดยทั่วไปค่านี้จะกำหนดตามกฎที่พิจารณาปัจจัยต่างๆ เช่น ลำดับความสำคัญ ระดับความรุนแรง หรือประเภท Issue ค่านี้เป็นพื้นฐานสำคัญของแดชบอร์ดติดตามผลการดำเนินงานตาม SLA.
เหตุผลที่สำคัญ
ใช้เป็นเกณฑ์วัดการปฏิบัติตาม SLA และเป็นพื้นฐานของ KPI อัตราการผิด SLA ของ Incident.
แหล่งข้อมูล
ดึงค่าจากการตั้งค่า SLA ใน Jira Service Management โดยต้องระบุเป้าหมายที่ต้องการ เช่น 'เวลาจนแก้ปัญหาเสร็จ'.
ตัวอย่าง
4 ชั่วโมง8 ชั่วโมง3 วัน
|
|||
|
ผลการแก้ไข
Resolution
|
ผลลัพธ์สุดท้ายหรือเหตุผลที่ปิด Incident ว่าแก้ไขแล้ว. | ||
|
คำอธิบาย
ฟิลด์ Resolution อธิบายเหตุผลที่เปลี่ยน Incident ไปเป็นสถานะแก้ไขแล้ว ผลการแก้ไขที่พบบ่อย ได้แก่ 'แก้ไขแล้ว', 'รายการซ้ำ', 'ไม่ดำเนินการ' หรือ 'ทำซ้ำไม่ได้' การวิเคราะห์สัดส่วนของผลการแก้ไขแต่ละประเภทช่วยให้เข้าใจคุณภาพของรายงานที่ได้รับและประสิทธิผลของกระบวนการแก้ไข ตัวอย่างเช่น หากมีผลการแก้ไขเป็น 'รายการซ้ำ' จำนวนมาก อาจบ่งชี้ถึงปัญหาในขั้นตอนสร้าง Incident หรือคัดแยกปัญหา.
เหตุผลที่สำคัญ
ให้บริบทเกี่ยวกับผลลัพธ์ของ Incident ช่วยจัดหมวดหมู่ผลการแก้ไขและหาแนวโน้มในการปิด Incident.
แหล่งข้อมูล
ฟิลด์ 'Resolution' มาตรฐานใน Jira Issue โดยทั่วไปจะกำหนดค่าเมื่อเปลี่ยน Issue ไปยังหมวดสถานะ 'Done'.
ตัวอย่าง
เสร็จแล้วแก้ไขแล้วรายการซ้ำไม่แก้ไข
|
|||
|
ผิด SLA
SlaBreach
|
ตัวบ่งชี้ว่าเวลาที่ใช้แก้ Incident เกินเป้าหมาย SLA หรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์แบบบูลีนที่คำนวณขึ้นนี้ระบุว่า Incident ผิด SLA 'Time to Resolution' หรือไม่ โดยจะเป็น true เมื่อ 'IncidentResolutionCycleTime' มากกว่า 'TimeToResolutionTarget' ตัวบ่งชี้นี้ช่วยให้วิเคราะห์และแสดงผลได้ง่ายขึ้น ทั้งยังกรองและรวมข้อมูลเพื่อคำนวณ KPI อัตราการผิด SLA โดยรวมได้สะดวก เป็นตัวชี้วัดผลลัพธ์หลักของแดชบอร์ดติดตามผลการดำเนินงานตาม SLA.
เหตุผลที่สำคัญ
แสดงผลการดำเนินงานตาม SLA อย่างชัดเจนว่าเป็นไปตามเป้าหมายหรือไม่ ช่วยคำนวณอัตราการผิด SLA และระบุจุดที่มีปัญหาได้ง่าย.
แหล่งข้อมูล
คำนวณจาก ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
ตัวอย่าง
truefalse
|
|||
|
ผู้แจ้ง
Reporter
|
ผู้ใช้ที่สร้างหรือแจ้ง Incident ในตอนแรก. | ||
|
คำอธิบาย
ผู้แจ้งคือบุคคล ซึ่งมักเป็นผู้ใช้ปลายทางหรือระบบอื่น ที่บันทึก Incident เป็นคนแรก การวิเคราะห์ Incident ตามผู้แจ้งช่วยระบุผู้ใช้หรือแผนกที่พบปัญหาบ่อย นอกจากนี้ยังใช้ทำความเข้าใจรูปแบบการสื่อสารได้ โดยเฉพาะเมื่อวิเคราะห์กิจกรรมอย่าง 'รอลูกค้า' และ 'ลูกค้าตอบกลับแล้ว'.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์แหล่งที่มาของ Incident ระบุรูปแบบปัญหาที่เกี่ยวข้องกับผู้ใช้หรือแผนกเฉพาะ และทำความเข้าใจความล่าช้าในการติดต่อกับลูกค้า.
แหล่งข้อมูล
ฟิลด์ 'Reporter' มาตรฐานใน Jira Issue.
ตัวอย่าง
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
มีการทำงานซ้ำหรือไม่
IsRework
|
ตัวบ่งชี้ว่า Incident มีการทำงานซ้ำ เช่น ถูกเปิดขึ้นมาอีกครั้งหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์แบบบูลีนที่คำนวณขึ้นนี้ระบุ Incident ที่ย้อนกลับไปยังขั้นตอนก่อนหน้าในกระบวนการ โดยส่วนใหญ่มักเกิดจากการเปิด Incident อีกครั้งหลังจากแก้ไขแล้ว การวนกลับมาทำงานซ้ำเป็นสาเหตุสำคัญของความไม่มีประสิทธิภาพและความไม่พอใจของลูกค้า ตัวบ่งชี้นี้ช่วยคำนวณอัตราการทำงานซ้ำ และให้วิเคราะห์ได้ตรงจุดว่าเหตุใดจึงแก้ Incident ไม่สำเร็จตั้งแต่ครั้งแรก.
เหตุผลที่สำคัญ
ชี้ให้เห็นปัญหาด้านคุณภาพและความไม่มีประสิทธิภาพของกระบวนการ โดยระบุ Incident ที่ต้องทำงานซ้ำ และช่วยวิเคราะห์การทำงานซ้ำโดยตรง.
แหล่งข้อมูล
คำนวณโดยตรวจจับลำดับการเปลี่ยนสถานะที่กำหนดในบันทึกเหตุการณ์ เช่น 'แก้ไขแล้ว' -> 'เปิดอีกครั้ง'.
ตัวอย่าง
truefalse
|
|||
|
รหัส Problem ที่เชื่อมโยง
LinkedProblemId
|
รหัสของ Ticket Problem ที่เชื่อมโยงกับ Incident นี้. | ||
|
คำอธิบาย
Incident ที่เป็นอาการของปัญหาใหญ่ซึ่งมีสาเหตุอยู่เบื้องหลัง มักเชื่อมโยงกับ Ticket Problem ฟิลด์นี้เก็บรหัสของ Problem ที่เกี่ยวข้อง การวิเคราะห์ลิงก์เหล่านี้ช่วยให้เข้าใจความสัมพันธ์ระหว่าง Incident กับ Problem วัดประสิทธิผลของกระบวนการจัดการปัญหา และระบุ Incident ที่เกิดซ้ำซึ่งต้องแก้ไขอย่างถาวร.
เหตุผลที่สำคัญ
เชื่อมโยง Incident กับปัญหาที่อยู่เบื้องหลัง เพื่อวิเคราะห์ว่าองค์กรจัดการสาเหตุที่แท้จริงและป้องกัน Incident ในอนาคตได้ดีเพียงใด.
แหล่งข้อมูล
ข้อมูลนี้จัดเก็บไว้ในส่วน 'Issue Links' ของ Jira Issue.
ตัวอย่าง
PROB-123PROB-456ไม่มี
|
|||
|
ระดับความรุนแรง
Severity
|
ระดับผลกระทบทางธุรกิจของ Incident. | ||
|
คำอธิบาย
ระดับความรุนแรงบอกว่า Incident ส่งผลกระทบต่อธุรกิจมากเพียงใด ตั้งแต่กระทบผู้ใช้รายเดียวไปจนถึงระบบสำคัญหยุดทำงาน ลำดับความสำคัญใช้กำหนดลำดับการทำงาน ส่วนระดับความรุนแรงใช้บอกผลกระทบโดยรวมต่อธุรกิจ การวิเคราะห์ตามระดับความรุนแรงช่วยให้เข้าใจผลการดำเนินงานของกระบวนการสำหรับ Incident ที่สำคัญต่อธุรกิจ และมักใช้ร่วมกับลำดับความสำคัญเพื่อให้วิเคราะห์ได้ละเอียดขึ้น.
เหตุผลที่สำคัญ
แสดงผลกระทบต่อธุรกิจ ช่วยให้วิเคราะห์โดยเน้น Incident ที่สร้างความเสียหายต่อการดำเนินงานมากที่สุด.
แหล่งข้อมูล
โดยทั่วไปจะเป็นฟิลด์แบบกำหนดเองใน Jira เนื่องจากไม่ใช่ฟิลด์มาตรฐานของระบบ โปรดตรวจสอบการตั้งค่าโปรเจกต์ใน Jira Service Management.
ตัวอย่าง
วิกฤตร้ายแรงเล็กน้อยไม่ร้ายแรง
|
|||
|
หมวดหมู่สาเหตุที่แท้จริง
RootCauseCategory
|
การจัดประเภทสาเหตุเบื้องหลังของ Incident. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกสาเหตุหลักที่ทำให้เกิด Incident เช่น 'ข้อผิดพลาดของซอฟต์แวร์', 'ฮาร์ดแวร์ขัดข้อง' หรือ 'ข้อผิดพลาดจากผู้ใช้' โดยทั่วไปจะกรอกข้อมูลหลังการตรวจสอบ และจำเป็นต่อการจัดการปัญหาอย่างมีประสิทธิภาพและป้องกัน Incident ในอนาคต การวิเคราะห์หมวดหมู่สาเหตุช่วยระบุจุดอ่อนเชิงระบบและจัดลำดับความสำคัญของการปรับปรุง หากพบสาเหตุที่ 'ไม่ทราบ' ในสัดส่วนสูง อาจเป็นสัญญาณว่าควรปรับปรุงกระบวนการตรวจสอบ.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์สาเหตุที่แท้จริง เปลี่ยนจากการแก้ปัญหาเฉพาะหน้าไปสู่การป้องกัน โดยระบุและจัดการต้นตอของ Incident.
แหล่งข้อมูล
ฟิลด์นี้แทบจะเป็นฟิลด์แบบกำหนดเองใน Jira เสมอ ชื่อและตัวเลือกขึ้นอยู่กับการตั้งค่าของแต่ละองค์กร.
ตัวอย่าง
ข้อผิดพลาดในการตั้งค่าเครือข่ายขัดข้องข้อบกพร่องของซอฟต์แวร์
|
|||
|
องค์ประกอบ
Component
|
ระบบ แอปพลิเคชัน หรือส่วนของโครงสร้างพื้นฐานที่ได้รับผลกระทบจาก Incident. | ||
|
คำอธิบาย
Components คือส่วนย่อยของโปรเจกต์ Jira ที่ใช้จัดกลุ่ม Issue เช่น 'ส่วนติดต่อผู้ใช้', 'ฐานข้อมูล' หรือ 'API' การวิเคราะห์ Incident ตามองค์ประกอบช่วยระบุว่าส่วนใดของระบบมีแนวโน้มเกิดปัญหามากที่สุด ข้อมูลนี้มีประโยชน์ต่อการวิเคราะห์สาเหตุที่แท้จริง และช่วยกำหนดแนวทางปรับปรุงบริการหรือลดหนี้ทางเทคนิค.
เหตุผลที่สำคัญ
ช่วยกรองและวิเคราะห์ตามผลิตภัณฑ์หรือส่วนของระบบที่ได้รับผลกระทบ เพื่อระบุจุดที่เกิดปัญหาด้านเทคโนโลยีบ่อย.
แหล่งข้อมูล
ฟิลด์ 'Components' มาตรฐานใน Jira Issue.
ตัวอย่าง
บริการยืนยันตัวตนแดชบอร์ดรายงานแอปมือถือ
|
|||
กิจกรรมในการจัดการเหตุขัดข้อง
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
แก้ไขเหตุขัดข้องแล้ว
|
กิจกรรมนี้ยืนยันว่าแก้ไขเหตุขัดข้องสำเร็จและกู้คืนบริการแล้ว โดยมักเกิดขึ้นพร้อมกับการเปลี่ยนสถานะเป็น 'Resolved'. | ||
|
เหตุผลที่สำคัญ
นี่คือหมุดหมายหลักที่แสดงว่ากระบวนการสำเร็จ ระยะเวลาจนถึงจุดนี้เป็น KPI ที่ใช้กันทั่วไปมากที่สุด ซึ่งหมายถึงเวลาจนแก้ไขเสร็จ (TTR).
แหล่งข้อมูล
อนุมานจากการเปลี่ยนสถานะเป็น 'Resolved' ในหลายเวิร์กโฟลว์ เหตุการณ์นี้เป็นเหตุการณ์เดียวกับ 'Resolution Proposed' และแสดงจุดหลักที่แก้ไขเสร็จ.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนเป็น 'Resolved'.
ประเภทเหตุการณ์
inferred
|
|||
|
ปิดเหตุขัดข้อง
|
หมายถึงการปิดทิกเก็ตเหตุขัดข้องในขั้นตอนธุรการขั้นสุดท้าย หลังจากแก้ไขและตรวจสอบแล้ว อนุมานจากการเปลี่ยนสถานะเป็น 'Closed'. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์สุดท้ายของกระบวนการ การวิเคราะห์เวลาระหว่าง 'Resolved' กับ 'Closed' ช่วยให้เห็นความล่าช้าในการจัดการงานธุรการหรือรอการยืนยันจากผู้ใช้.
แหล่งข้อมูล
อนุมานจากประวัติการเปลี่ยนสถานะของรายการ เหตุการณ์นี้ตรงกับเวลาที่สถานะเปลี่ยนเป็น 'Closed' ซึ่งเป็นสถานะสุดท้าย.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนเป็น 'Closed'.
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายเหตุขัดข้องใหม่
|
เกิดขึ้นเมื่อมีการโอนเหตุขัดข้องจากเจ้าหน้าที่หรือกลุ่มหนึ่งไปยังอีกกลุ่มหนึ่งหลังจากมอบหมายครั้งแรก อนุมานเหตุการณ์นี้จากการเปลี่ยนแปลงใด ๆ ของฟิลด์ 'Assignee' หรือ 'Assigned Group'. | ||
|
เหตุผลที่สำคัญ
การติดตามการมอบหมายใหม่เป็นสิ่งสำคัญต่อการวิเคราะห์การส่งต่องาน การมอบหมายใหม่หลายครั้งมักบ่งชี้ถึงความไม่มีประสิทธิภาพของกระบวนการ ช่องว่างด้านความรู้ หรือการส่งต่องานครั้งแรกไม่ถูกต้อง ซึ่งทำให้การแก้ไขล่าช้า.
แหล่งข้อมูล
อนุมานจากประวัติรายการปัญหา โดยตรวจหาการอัปเดตฟิลด์ 'Assignee' หลังจากมีการกรอกค่าเป็นครั้งแรก การเปลี่ยนแปลงแต่ละครั้งถือเป็นเหตุการณ์มอบหมายงานใหม่.
บันทึก
ระบุการเปลี่ยนแปลงครั้งต่อ ๆ ไปของฟิลด์ 'Assignee' หลังการมอบหมายครั้งแรก.
ประเภทเหตุการณ์
inferred
|
|||
|
รอข้อมูลจากลูกค้า
|
ระบุช่วงที่ทีมสนับสนุนกำลังรอข้อมูลหรือการดำเนินการจากลูกค้า อนุมานจากการเปลี่ยนสถานะไปเป็นสถานะรอโดยเฉพาะ เช่น 'Waiting for customer'. | ||
|
เหตุผลที่สำคัญ
การแยกเวลาที่พักงานช่วงนี้ออกมามีความสำคัญต่อการวัด SLA ให้แม่นยำ เนื่องจากมักไม่นับรวมในเวลาคำนวณการแก้ไข และยังช่วยวิเคราะห์ความล่าช้าในการตอบกลับของลูกค้า.
แหล่งข้อมูล
อนุมานจากประวัติการเปลี่ยนสถานะของรายการ เหตุการณ์นี้ตรงกับเวลาที่สถานะเปลี่ยนเป็น 'Waiting for customer' หรือสถานะที่มีความหมายใกล้เคียงกัน.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนเป็น 'Waiting for customer'.
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มตรวจสอบ
|
หมายถึงเจ้าหน้าที่ที่ได้รับมอบหมายเริ่มวิเคราะห์เหตุขัดข้องอย่างจริงจัง โดยทั่วไปอนุมานเมื่อสถานะรายการเหตุขัดข้องเปลี่ยนจาก 'Open' หรือ 'New' เป็น 'In Progress'. | ||
|
เหตุผลที่สำคัญ
หมุดหมายสำคัญนี้แสดงจุดเริ่มต้นของการดำเนินการแก้ไขอย่างจริงจัง การวัดเวลาจนถึงกิจกรรมนี้ช่วยระบุความล่าช้าจากการรอคิวและปัญหาความพร้อมของทรัพยากร.
แหล่งข้อมูล
อนุมานจากประวัติการเปลี่ยนสถานะของรายการ เวลาของเหตุการณ์คือเวลาที่สถานะเปลี่ยนเป็นสถานะที่แสดงว่ากำลังดำเนินงาน เช่น 'In Progress'.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนเป็น 'In Progress'.
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างเหตุขัดข้อง
|
ระบุจุดเริ่มต้นอย่างเป็นทางการของวงจรเหตุขัดข้อง เมื่อมีการส่งรายงานเหตุขัดข้องและสร้างปัญหาใหม่ใน Jira ระบบจะบันทึกเหตุการณ์นี้อย่างชัดเจนเมื่อมีการสร้างรายการประเภท 'Incident'. | ||
|
เหตุผลที่สำคัญ
นี่คือเหตุการณ์เริ่มต้นหลักของกระบวนการ การวิเคราะห์เวลาตั้งแต่กิจกรรมนี้จนถึงการแก้ไขเป็นพื้นฐานสำคัญในการวัดเวลารวมของรอบงานและการปฏิบัติตาม SLA.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรงจากเวลาที่สร้างรายการเหตุขัดข้องใน Jira โดยบันทึกการสร้างรายการไว้ในประวัติของรายการนั้น.
บันทึก
ใช้เวลาที่สร้างรายการปัญหา.
ประเภทเหตุการณ์
explicit
|
|||
|
เสนอวิธีแก้ไข
|
กิจกรรมนี้หมายถึงการระบุและดำเนินการแก้ไขแล้ว และกำลังรอการยืนยันหรือตรวจสอบขั้นสุดท้าย อนุมานจากการเปลี่ยนสถานะเป็น 'Resolved'. | ||
|
เหตุผลที่สำคัญ
หมุดหมายสำคัญนี้แสดงว่าทีมสนับสนุนสิ้นสุดการทำงานอย่างจริงจังแล้ว และมักเป็นเหตุการณ์ที่หยุดการนับเวลา SLA.
แหล่งข้อมูล
อนุมานจากประวัติการเปลี่ยนสถานะของรายการ เวลาของเหตุการณ์คือเวลาที่สถานะเปลี่ยนเป็น 'Resolved' หรือสถานะที่มีความหมายเทียบเท่า.
บันทึก
ระบุเวลาที่สถานะเปลี่ยนเป็น 'Resolved'.
ประเภทเหตุการณ์
inferred
|
|||
|
จัดลำดับความสำคัญของเหตุขัดข้อง
|
หมายถึงการกำหนดลำดับความสำคัญและ/หรือระดับความรุนแรงของเหตุขัดข้อง ซึ่งเป็นตัวกำหนดความเร่งด่วนและผลกระทบทางธุรกิจ โดยทั่วไปอนุมานจากครั้งแรกที่กรอกหรืออัปเดตฟิลด์ 'Priority' หรือ 'Severity' หลังสร้างรายการ. | ||
|
เหตุผลที่สำคัญ
การติดตามการจัดลำดับความสำคัญช่วยวิเคราะห์ได้ว่ามีการประเมินเหตุขัดข้องอย่างรวดเร็วและสม่ำเสมอหรือไม่ ความล่าช้าในขั้นตอนนี้อาจส่งผลโดยตรงต่อการคำนวณ SLA และการจัดสรรทรัพยากร.
แหล่งข้อมูล
อนุมานจากบันทึกประวัติรายการปัญหา ซึ่งติดตามการเปลี่ยนแปลงของทุกฟิลด์ ให้ค้นหาการอัปเดตครั้งแรกของฟิลด์ 'Priority' หรือฟิลด์ 'Severity' ที่กำหนดเองหลังสร้างรายการ.
บันทึก
ตรวจหาการเปลี่ยนแปลงครั้งแรกของฟิลด์ 'Priority' ในประวัติรายการปัญหา.
ประเภทเหตุการณ์
inferred
|
|||
|
เชื่อมโยงกับทิกเก็ตปัญหา
|
เกิดขึ้นเมื่อเชื่อมโยงเหตุขัดข้องกับรายการปัญหาประเภท 'Problem' เพื่อวิเคราะห์สาเหตุที่แท้จริง ระบบบันทึกเหตุการณ์นี้โดยตรงเมื่อสร้างลิงก์ 'relates to' หรือ 'caused by' ไปยังรายการประเภท Problem. | ||
|
เหตุผลที่สำคัญ
การติดตามลิงก์นี้จำเป็นต่อการทำความเข้าใจว่าองค์กรเปลี่ยนจากการบรรเทาเหตุขัดข้องไปสู่การวิเคราะห์สาเหตุที่แท้จริงและการป้องกันได้มีประสิทธิภาพเพียงใด.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรงในประวัติลิงก์ของรายการ ลิงก์แต่ละรายการมีเวลาที่สร้าง และสามารถกรองเฉพาะลิงก์ไปยังรายการประเภท 'Problem' ได้.
บันทึก
ใช้เวลาที่สร้างลิงก์ไปยังรายการประเภท 'Problem'.
ประเภทเหตุการณ์
explicit
|
|||
|
นำวิธีแก้ปัญหาชั่วคราวไปใช้
|
หมายถึงการนำวิธีแก้ไขชั่วคราวมาใช้เพื่อกู้คืนบริการระหว่างพัฒนาวิธีแก้ไขถาวร อนุมานได้จากการเปลี่ยนสถานะหรือความคิดเห็นที่ระบุไว้. | ||
|
เหตุผลที่สำคัญ
การวัดเวลาที่ใช้ในการให้วิธีแก้ปัญหาชั่วคราวเป็นตัวชี้วัดสำคัญของความเร็วในการกู้คืนบริการ และช่วยแยกการบรรเทาปัญหาชั่วคราวออกจากการแก้ไขถาวร.
แหล่งข้อมูล
เหตุการณ์นี้มักอนุมานจากข้อมูลอื่น เช่น การเปลี่ยนสถานะเป็น 'Workaround Provided' หรือการเพิ่มความคิดเห็นสาธารณะที่มีคำสำคัญอย่าง 'workaround'.
บันทึก
ระบุการเปลี่ยนสถานะเฉพาะหรือคำสำคัญในความคิดเห็น.
ประเภทเหตุการณ์
inferred
|
|||
|
เปิดเหตุขัดข้องอีกครั้ง
|
หมายถึงการเปิดใช้งานเหตุขัดข้องที่แก้ไขแล้วอีกครั้ง เนื่องจากปัญหาเกิดซ้ำหรือวิธีแก้ไขไม่ได้ผล อนุมานจากการเปลี่ยนสถานะจาก 'Resolved' หรือ 'Closed' กลับไปเป็นสถานะเปิด. | ||
|
เหตุผลที่สำคัญ
เหตุขัดข้องที่เปิดซ้ำเป็นตัวชี้วัดคุณภาพการแก้ไขโดยตรงและเป็นสัญญาณสำคัญของการทำงานซ้ำ การวิเคราะห์เหตุการณ์เหล่านี้ช่วยระบุการปิดงานก่อนเวลาและวิธีแก้ไขที่ไม่ได้ผล.
แหล่งข้อมูล
อนุมานจากประวัติการเปลี่ยนสถานะของรายการ โดยบันทึกเหตุการณ์เมื่อสถานะเปลี่ยนจากสถานะสิ้นสุด เช่น 'Resolved' หรือ 'Closed' กลับไปเป็น 'Open' หรือ 'In Progress'.
บันทึก
ตรวจหาการเปลี่ยนสถานะจาก 'Resolved' หรือ 'Closed' ไปเป็นสถานะเปิด.
ประเภทเหตุการณ์
inferred
|
|||
|
เพิ่มความคิดเห็น
|
หมายถึงเหตุการณ์สื่อสารหรือบันทึกข้อมูลที่ผู้ใช้เพิ่มความคิดเห็นลงในทิกเก็ตเหตุขัดข้อง ระบบบันทึกเหตุการณ์นี้ทุกครั้งที่มีการโพสต์ความคิดเห็น. | ||
|
เหตุผลที่สำคัญ
การวิเคราะห์ความถี่ของความคิดเห็นช่วยให้เข้าใจรูปแบบการสื่อสาร ประสิทธิภาพการทำงานร่วมกัน และความซับซ้อนของเหตุขัดข้อง อีกทั้งยังช่วยระบุเหตุขัดข้องที่ต้องสื่อสารกันมากเกินไป.
แหล่งข้อมูล
เหตุการณ์นี้บันทึกโดยตรง Jira จัดเก็บความคิดเห็นทุกข้อความพร้อมเวลาและผู้เขียน โดยดูได้จากประวัติความคิดเห็นของรายการหรือผ่าน API.
บันทึก
ใช้เวลาที่เพิ่มความคิดเห็นแต่ละรายการลงในปัญหา.
ประเภทเหตุการณ์
explicit
|
|||
|
มอบหมายเหตุขัดข้อง
|
กิจกรรมนี้หมายถึงการมอบหมายเหตุขัดข้องให้เจ้าหน้าที่หรือกลุ่มสนับสนุนเพื่อดำเนินการเป็นครั้งแรก โดยติดตามครั้งแรกที่มีการกรอกฟิลด์ 'Assignee' หรือ 'Assigned Group'. | ||
|
เหตุผลที่สำคัญ
ใช้วัดเวลาตอบสนองและมอบหมายงานครั้งแรก ซึ่งเป็นองค์ประกอบสำคัญของตัวชี้วัด SLA และช่วยระบุความล่าช้าก่อนเริ่มตรวจสอบอย่างจริงจัง.
แหล่งข้อมูล
อนุมานจากประวัติรายการปัญหา โดยระบุการเปลี่ยนแปลงครั้งแรกของฟิลด์ 'Assignee' ซึ่งค่าก่อนหน้าเป็น 'Unassigned'.
บันทึก
ตรวจหาการอัปเดตครั้งแรกของฟิลด์ 'Assignee' ในประวัติรายการปัญหา.
ประเภทเหตุการณ์
inferred
|
|||
|
ลูกค้าตอบกลับ
|
หมายถึงลูกค้าให้ข้อมูลที่ร้องขอแล้ว ทำให้ดำเนินการกับเหตุขัดข้องต่อได้ อนุมานเมื่อสถานะเปลี่ยนจาก 'Waiting for customer' กลับไปเป็นสถานะที่กำลังดำเนินงาน. | ||
|
เหตุผลที่สำคัญ
กิจกรรมนี้เป็นจุดสิ้นสุดของความล่าช้าที่เกิดจากการรอลูกค้า การวิเคราะห์ระยะเวลาตั้งแต่ 'Waiting For Customer' จนถึงกิจกรรมนี้ช่วยให้ทราบเวลาเฉลี่ยที่ลูกค้าใช้ในการตอบกลับ.
แหล่งข้อมูล
อนุมานจากประวัติการเปลี่ยนสถานะของรายการ เหตุการณ์เกิดขึ้นเมื่อสถานะเปลี่ยนจาก 'Waiting for customer' เป็นสถานะอย่าง 'In Progress' ซึ่งมักเกิดขึ้นเมื่อลูกค้าเพิ่มความคิดเห็น.
บันทึก
ตรวจหาการเปลี่ยนสถานะจาก 'Waiting for customer' เป็น 'In Progress'.
ประเภทเหตุการณ์
inferred
|
|||
|
ส่งต่อให้ทีมผู้เชี่ยวชาญ
|
หมายถึงการยกระดับเหตุขัดข้องไปยังทีมเฉพาะทาง เช่น Tier 2 หรือทีมพัฒนา เพื่อรับการสนับสนุนขั้นสูง อนุมานจากการเปลี่ยนฟิลด์ 'Support Team' ที่กำหนดเองหรือการมอบหมายใหม่ในลักษณะเฉพาะ. | ||
|
เหตุผลที่สำคัญ
ช่วยระบุเหตุขัดข้องที่ต้องใช้ความรู้เฉพาะทางและติดตามการส่งต่องานระหว่างระดับการสนับสนุนต่าง ๆ เพื่อค้นหาคอขวดในทีมเฉพาะทางและวิเคราะห์รูปแบบการยกระดับปัญหา.
แหล่งข้อมูล
อนุมานจากประวัติรายการปัญหา โดยติดตามการเปลี่ยนแปลงฟิลด์ที่กำหนดเองซึ่งระบุทีมที่ได้รับมอบหมาย หรือระบุการเปลี่ยนฟิลด์ 'Assignee' ไปเป็นสมาชิกของกลุ่มผู้เชี่ยวชาญที่ทราบอยู่แล้ว.
บันทึก
ตรวจหาการเปลี่ยนแปลงในฟิลด์ 'Assigned Team' ที่กำหนดเอง หรือการเปลี่ยนผู้รับผิดชอบที่ระบุไว้.
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
ใช้เทมเพลตข้อมูลนี้ปรับปรุงการจัดการเหตุขัดข้อง ค้นหาจุดที่ไม่มีประสิทธิภาพ และลดเวลาแก้ไข เริ่มปรับปรุงกระบวนการของคุณได้วันนี้.
ปรับปรุงการจัดการเหตุขัดข้อง แก้ไขเหตุได้เร็วขึ้น
ลด MTTR ลง 35% และเพิ่มความพึงพอใจของผู้ใช้ด้วยกระบวนการที่คล่องตัวขึ้น.
ไม่ต้องใช้บัตรเครดิต • ตั้งค่าเสร็จใน 5 นาที