เทมเพลตข้อมูลการจัดการเหตุขัดข้อง

Jira Service Management
เทมเพลตข้อมูลการจัดการเหตุขัดข้อง

เทมเพลตข้อมูลการจัดการเหตุขัดข้อง

เทมเพลตนี้ช่วยจัดระเบียบข้อมูลที่จำเป็นสำหรับวิเคราะห์กระบวนการจัดการเหตุขัดข้อง โดยระบุคุณลักษณะที่ควรเก็บ กิจกรรมหลักที่ควรติดตาม และวิธีดึงข้อมูลจากระบบต้นทาง คุณจึงมีข้อมูลพร้อมสำหรับเริ่มปรับปรุงเวิร์กโฟลว์การแก้ไขเหตุขัดข้อง.
  • คุณลักษณะที่แนะนำให้เก็บ
  • กิจกรรมสำคัญที่ควรติดตาม
  • แนวทางดึงข้อมูลจาก Jira Service Management
เพิ่งเริ่มใช้บันทึกเหตุการณ์ใช่ไหม เรียนรู้ วิธีสร้าง event log สำหรับ process mining.

คุณลักษณะของการจัดการเหตุขัดข้อง

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

ตัวอย่าง
บริการยืนยันตัวตนแดชบอร์ดรายงานแอปมือถือ
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมในการจัดการเหตุขัดข้อง

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

คู่มือการดึงข้อมูล

วิธีดึงข้อมูลจาก Jira Service Management

พร้อมเริ่มต้นหรือยัง?

ใช้เทมเพลตข้อมูลนี้ปรับปรุงการจัดการเหตุขัดข้อง ค้นหาจุดที่ไม่มีประสิทธิภาพ และลดเวลาแก้ไข เริ่มปรับปรุงกระบวนการของคุณได้วันนี้.

ปรับปรุงการจัดการเหตุขัดข้อง แก้ไขเหตุได้เร็วขึ้น

ลด MTTR ลง 35% และเพิ่มความพึงพอใจของผู้ใช้ด้วยกระบวนการที่คล่องตัวขึ้น.

เริ่มทดลองใช้ฟรี

ไม่ต้องใช้บัตรเครดิต • ตั้งค่าเสร็จใน 5 นาที