เทมเพลตข้อมูลการจัดการปัญหา
เทมเพลตข้อมูลการจัดการปัญหา
- แอตทริบิวต์ที่แนะนำสำหรับการวิเคราะห์เชิงลึก
- หมุดหมายของกระบวนการที่ควรบันทึกในบันทึกเหตุการณ์
- คำแนะนำทางเทคนิคสำหรับการดึงข้อมูล
แอตทริบิวต์การจัดการปัญหา
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
กิจกรรม
ActivityName
|
การดำเนินการหรือการเปลี่ยนสถานะที่เกิดขึ้นกับรายการปัญหา. | ||
|
คำอธิบาย
คุณสมบัตินี้บันทึกชื่อเหตุการณ์หรือการเปลี่ยนสถานะที่เกิดขึ้นในวงจรการจัดการปัญหา ตัวอย่างเช่น 'บันทึกปัญหา', 'เปลี่ยนสถานะเป็นกำลังตรวจสอบ' หรือ 'ระบุสาเหตุที่แท้จริงแล้ว' ข้อมูลนี้จำเป็นต่อการทำแผนที่กระบวนการและระบุลำดับขั้นตอนที่ใช้แก้ปัญหา ใน process mining กิจกรรมเหล่านี้เป็นจุดต่างๆ บนแผนผังกระบวนการ.
เหตุผลที่สำคัญ
กำหนดขั้นตอนในแผนผังกระบวนการและช่วยวิเคราะห์รูปแบบต่างๆ ของกระบวนการ.
แหล่งข้อมูล
Jira Changelog (History) หรือการเปลี่ยนสถานะ Issue
ตัวอย่าง
สร้างรายการปัญหาเริ่มการตรวจสอบระบุสาเหตุที่แท้จริงอัปเดตวิธีแก้ปัญหาชั่วคราวปิดรายการปัญหา
|
|||
|
ระบบต้นทาง
SourceSystem
|
ชื่อระบบที่เป็นแหล่งที่มาของข้อมูล. | ||
|
คำอธิบาย
ระบุระบบซอฟต์แวร์ที่ดึงข้อมูลกระบวนการมา ในกรณีนี้ ค่าจะเป็น 'Jira Service Management' เสมอ คุณสมบัตินี้มีประโยชน์เป็นพิเศษในสภาพแวดล้อมที่ใช้หลายระบบ เพราะช่วยแยกแหล่งข้อมูลได้ แต่สำหรับมุมมองนี้ ใช้เป็นตัวระบุแหล่งที่มาของข้อมูลแบบคงที่เป็นหลัก.
เหตุผลที่สำคัญ
ระบุที่มาของข้อมูล โดยเฉพาะเมื่อนำไปรวมกับข้อมูล IT Service Management จากระบบอื่น.
แหล่งข้อมูล
กำหนดค่าไว้ล่วงหน้าหรือกำหนดจากการตั้งค่าระบบ
ตัวอย่าง
Jira Service ManagementJira CloudJSM-Prod
|
|||
|
รายการปัญหา
ProblemKey
|
รหัสเฉพาะที่กำหนดให้กับรายการปัญหาใน Jira Service Management. | ||
|
คำอธิบาย
คุณสมบัตินี้ทำหน้าที่เป็น Case ID หลักสำหรับการวิเคราะห์ process mining โดยเป็นคีย์เฉพาะ เช่น PM-1001 ที่ Jira Service Management สร้างขึ้นเมื่อมีรายการปัญหาใหม่ ระบบใช้คีย์นี้จัดกลุ่มกิจกรรม การเปลี่ยนสถานะ และการอัปเดตที่เกี่ยวข้องทั้งหมดให้เป็นกระบวนการเดียวกัน คุณสมบัตินี้ช่วยแสดงวงจรของปัญหาได้ครบถ้วน ตั้งแต่การตรวจพบครั้งแรก การตรวจสอบ ไปจนถึงการปิดรายการ.
เหตุผลที่สำคัญ
เป็นคีย์พื้นฐานที่จำเป็นต่อการสร้างขั้นตอนกระบวนการขึ้นใหม่และติดตามรายการปัญหาแต่ละรายการ.
แหล่งข้อมูล
ตาราง Issue, ฟิลด์ 'Key' หรือ 'Issue Key'
ตัวอย่าง
PM-1023PM-4099PRB-3321PM-5001
|
|||
|
เวลา
EventTimestamp
|
วันที่และเวลาที่กิจกรรมเกิดขึ้นอย่างแน่นอน. | ||
|
คำอธิบาย
คุณสมบัตินี้บันทึกเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ ใช้เรียงลำดับเหตุการณ์ตามเวลาและคำนวณระยะเวลาระหว่างขั้นตอน การบันทึกเวลาอย่างถูกต้องจำเป็นต่อการคำนวณระยะเวลารอบงาน เช่น เวลาตั้งแต่ 'บันทึกปัญหา' จนถึง 'ระบุสาเหตุที่แท้จริง' และการวิเคราะห์ปริมาณงานที่ดำเนินการในแต่ละช่วงเวลา.
เหตุผลที่สำคัญ
ใช้คำนวณ KPI ที่อิงเวลาและเรียงลำดับเหตุการณ์ได้อย่างถูกต้อง.
แหล่งข้อมูล
วันที่สร้าง Jira Changelog หรือวันที่สร้าง Issue
ตัวอย่าง
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:00Z
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
เวลาที่ดึงข้อมูลหรืออัปเดตข้อมูลล่าสุด. | ||
|
คำอธิบาย
ระบุเวลาที่ซิงโครไนซ์ชุดข้อมูลกับ Jira Service Management ที่ใช้งานจริงครั้งล่าสุด เพื่อให้นักวิเคราะห์ทราบว่าข้อมูลเป็นปัจจุบันเพียงใด ใช้ตรวจสอบว่าผลการวิเคราะห์สะท้อนสถานะล่าสุดของกระบวนการหรือไม่ และช่วยระบุความล่าช้าของข้อมูลที่อาจเกิดขึ้น.
เหตุผลที่สำคัญ
ช่วยให้ข้อมูลเป็นปัจจุบันและเพิ่มความมั่นใจในผลการวิเคราะห์.
แหล่งข้อมูล
เวลาประทับ ETL
ตัวอย่าง
2023-11-01T12:00:00Z2023-11-02T00:00:00Z
|
|||
|
กลุ่มสนับสนุนที่ได้รับมอบหมาย
SupportGroup
|
ทีมเทคนิคหรือกลุ่มที่ได้รับมอบหมายให้ตรวจสอบปัญหาในขณะนั้น. | ||
|
คำอธิบาย
ระบุทีมที่รับผิดชอบระเบียนปัญหา ณ เวลาที่เกิดเหตุ ใน Jira Service Management มักเชื่อมโยงกับ 'Component' หรือฟิลด์ที่กำหนดเอง เช่น 'Support Group' แอตทริบิวต์นี้จำเป็นต่อแดชบอร์ด 'คอขวดในการส่งต่องานระหว่างกลุ่มสนับสนุน' ซึ่งช่วยให้นักวิเคราะห์เห็นว่าปัญหาถูกส่งต่อระหว่างทีมอย่างไร และค้างอยู่กับทีมใดนานที่สุด.
เหตุผลที่สำคัญ
จำเป็นต่อการวิเคราะห์กระบวนการในระดับองค์กรและระบุปัญหาการทำงานร่วมกันระหว่างทีม.
แหล่งข้อมูล
ฟิลด์ 'Component' ของปัญหา หรือฟิลด์ที่กำหนดเอง 'Support Group'
ตัวอย่าง
การดูแลระบบฐานข้อมูลการปฏิบัติการเครือข่ายฝ่ายสนับสนุนแอปพลิเคชันระดับ 2
|
|||
|
ความสำคัญ
Priority
|
ระดับความสำคัญที่กำหนดให้กับระเบียนปัญหา. | ||
|
คำอธิบาย
ระบุความเร่งด่วนและผลกระทบของปัญหา โดยทั่วไปมีระดับตั้งแต่ 'ต่ำ' ถึง 'วิกฤต' ใช้แบ่งกลุ่มการวิเคราะห์และตรวจสอบว่าปัญหาที่มีความสำคัญสูงได้รับการแก้ไขภายในเป้าหมาย SLA หรือไม่ การวิเคราะห์แอตทริบิวต์นี้ในแดชบอร์ด 'การปฏิบัติตาม SLA และแนวโน้มเป้าหมาย' ช่วยตรวจสอบว่ามีการจัดลำดับความสำคัญของความเสี่ยงทางธุรกิจอย่างเหมาะสมหรือไม่.
เหตุผลที่สำคัญ
ช่วยแบ่งกลุ่มผลการดำเนินงานของกระบวนการตามความสำคัญต่อธุรกิจ.
แหล่งข้อมูล
ฟิลด์ 'Priority' ของปัญหา
ตัวอย่าง
สูงสุดสูงปานกลางต่ำ
|
|||
|
ผู้ใช้
UserKey
|
รหัสเฉพาะหรือชื่อของผู้ใช้ที่ดำเนินกิจกรรม. | ||
|
คำอธิบาย
ระบุตัวบุคคลหรือบัญชีระบบที่รับผิดชอบดำเนินกิจกรรมนั้น เช่น 'ผู้รับมอบหมาย' ที่อัปเดตระเบียน หรือ 'ผู้เขียน' ที่เปลี่ยนสถานะ ข้อมูลนี้ใช้วิเคราะห์การใช้ทรัพยากร ระบุคอขวดในการส่งต่องานระหว่างผู้ใช้ และตรวจสอบความรับผิดชอบในกระบวนการจัดการปัญหา.
เหตุผลที่สำคัญ
สำคัญต่อการวิเคราะห์การส่งต่องาน การแบ่งแยกหน้าที่ และภาระงานของทรัพยากร.
แหล่งข้อมูล
ฟิลด์ 'author' ในประวัติการเปลี่ยนแปลงของ Jira หรือฟิลด์ 'assignee' ในปัญหา
ตัวอย่าง
j.smithsystem_automationm.doe
|
|||
|
สรุปปัญหา
ProblemSummary
|
ข้อความสั้นหรือชื่อเรื่องของระเบียนปัญหา. | ||
|
คำอธิบาย
แสดงสรุปใจความสำคัญของระเบียนปัญหา แม้จะเป็นข้อความเป็นหลัก แต่ก็ช่วยให้นักวิเคราะห์เข้าใจบริบทเมื่อตรวจสอบแต่ละกรณีในเครื่องมือ process mining ใช้ค้นหาด้วยคำสำคัญและวิเคราะห์เชิงคุณภาพเกี่ยวกับประเภทของปัญหาที่บันทึกไว้.
เหตุผลที่สำคัญ
ให้บริบทที่อ่านเข้าใจได้สำหรับรหัสกรณี.
แหล่งข้อมูล
ฟิลด์ 'Summary' ของปัญหา
ตัวอย่าง
หมดเวลาการเชื่อมต่อฐานข้อมูลในภูมิภาค EUเวลาแฝงของบริการอีเมลเพิ่มสูงขึ้นคิวประมวลผลคำสั่งซื้อค้าง
|
|||
|
หมวดหมู่สาเหตุที่แท้จริง
RootCauseCategory
|
การจัดประเภทสาเหตุที่แท้จริงของปัญหา. | ||
|
คำอธิบาย
จัดหมวดหมู่ความขัดข้องทางเทคนิคหรือกระบวนการที่ทำให้เกิดปัญหา เช่น 'ข้อบกพร่องของซอฟต์แวร์' 'ข้อผิดพลาดจากบุคคล' หรือ 'ฮาร์ดแวร์ขัดข้อง' โดยมักเป็นฟิลด์ที่กำหนดเองใน Jira Service Management แอตทริบิวต์นี้ใช้กับแดชบอร์ด 'การกระจายตามหมวดหมู่สาเหตุที่แท้จริง' เพื่อช่วยวางแผนลงทุนด้านโครงสร้างพื้นฐานหรือการฝึกอบรม และป้องกันไม่ให้ปัญหาเกิดซ้ำ.
เหตุผลที่สำคัญ
ช่วยระบุปัญหาเชิงระบบและกำหนดแนวทางป้องกัน.
แหล่งข้อมูล
ฟิลด์ที่กำหนดเอง 'Root Cause' หรือ 'Root Cause Category'
ตัวอย่าง
ข้อบกพร่องของซอฟต์แวร์ข้อผิดพลาดในการกำหนดค่าปัญหาด้านขีดความสามารถปัญหาจากผู้ให้บริการ
|
|||
|
คำขอเปลี่ยนแปลงที่เชื่อมโยง
LinkedChangeRequest
|
รหัสคำขอเปลี่ยนแปลงที่เชื่อมโยงกับปัญหานี้. | ||
|
คำอธิบาย
จัดเก็บ ID ของคำขอเปลี่ยนแปลง (RFC) ที่สร้างขึ้นเพื่อดำเนินการแก้ไขถาวร ลิงก์นี้จำเป็นต่อแดชบอร์ด 'ความล่าช้าก่อนเริ่มคำขอเปลี่ยนแปลง' เชื่อมกระบวนการจัดการปัญหากับกระบวนการจัดการการเปลี่ยนแปลง เพื่อให้วิเคราะห์ข้ามกระบวนการได้.
เหตุผลที่สำคัญ
เชื่อมการตรวจสอบปัญหาเข้ากับการแก้ไขในกระบวนการจัดการการเปลี่ยนแปลง.
แหล่งข้อมูล
ลิงก์ปัญหาที่มีประเภทเป็น 'แก้ไขโดย' หรือประเภทที่คล้ายกัน
ตัวอย่าง
CR-404CHG-1099CR-5512
|
|||
|
จำนวนเหตุขัดข้องที่เชื่อมโยง
LinkedIncidentCount
|
จำนวนเหตุขัดข้องที่เชื่อมโยงกับระเบียนปัญหานี้. | ||
|
คำอธิบาย
จำนวน ticket เหตุขัดข้องที่เชื่อมโยงกับระเบียนปัญหา แอตทริบิวต์นี้ใช้วัดผลกระทบของปัญหาต่อกลุ่มผู้ใช้ ใช้ใน KPI 'ระดับการเชื่อมโยงเหตุขัดข้องกับปัญหา' เพื่อจัดลำดับความสำคัญของปัญหาที่ทำให้เกิด ticket ขอรับการสนับสนุนจำนวนมากที่สุด.
เหตุผลที่สำคัญ
ใช้วัดผลกระทบทางธุรกิจจากจำนวนเหตุขัดข้อง.
แหล่งข้อมูล
จำนวนลิงก์ในตาราง 'issuelinks' ที่มีประเภทเป็น 'Problem/Incident'
ตัวอย่าง
011550
|
|||
|
ดำเนินการ PIR แล้ว
ReviewStatus
|
ระบุว่ามีการทบทวนหลังนำไปใช้ (PIR) หรือไม่. | ||
|
คำอธิบาย
ติดตามว่ามีกิจกรรมหรือสถานะ 'การทบทวนหลังนำไปใช้' ในกรณีหรือไม่ จำเป็นต่อแดชบอร์ด 'การปฏิบัติตามข้อกำหนดการทบทวนหลังนำไปใช้' ช่วยตรวจสอบว่าองค์กรปฏิบัติตามข้อกำหนดด้านการกำกับดูแลเพื่อปรับปรุงอย่างต่อเนื่องหรือไม่.
เหตุผลที่สำคัญ
ตัวชี้วัดการปฏิบัติตามข้อกำหนดเพื่อการเรียนรู้ขององค์กร.
แหล่งข้อมูล
ฟิลด์ที่กำหนดเอง 'PIR Status' หรือการมีกิจกรรม 'PIR'
ตัวอย่าง
เสร็จสมบูรณ์รอดำเนินการไม่จำเป็น
|
|||
|
เปิดอีกครั้งหรือไม่
IsReopened
|
ตัวบ่งชี้ว่ามีการเปิดปัญหาอีกครั้งหลังปิดแล้วหรือไม่. | ||
|
คำอธิบาย
ค่าจริง/เท็จที่กำหนดเป็นจริงเมื่อสถานะของระเบียนปัญหาเปลี่ยนจากปิดกลับมาเป็นเปิด ใช้ในการวิเคราะห์ 'อัตราการเปิดปัญหาอีกครั้ง' หากมีการเปิดปัญหาอีกครั้งบ่อยครั้ง อาจบ่งชี้ว่าวิธีแก้ไขถาวรยังไม่มีคุณภาพ หรือขั้นตอนตรวจสอบยังไม่เพียงพอ.
เหตุผลที่สำคัญ
ตัวชี้วัดคุณภาพของประสิทธิผลในการแก้ไขปัญหา.
แหล่งข้อมูล
คำนวณจากการเปลี่ยนสถานะ
ตัวอย่าง
truefalse
|
|||
|
ผู้รายงาน
ReporterName
|
ผู้ใช้ที่บันทึกระเบียนปัญหาเป็นคนแรก. | ||
|
คำอธิบาย
ระบุผู้ที่สร้างระเบียนปัญหา ซึ่งไม่ใช่ผู้รับมอบหมาย การวิเคราะห์ผู้รายงานช่วยให้เข้าใจว่าปัญหาถูกตรวจพบจากที่ใด เช่น เจ้าหน้าที่ Service Desk หรือผู้ดูแลระบบ ช่วยเพิ่มบริบทให้การวิเคราะห์ 'เชิงรุกเทียบกับเชิงรับ'.
เหตุผลที่สำคัญ
ระบุแหล่งที่มาของการแจ้งปัญหา.
แหล่งข้อมูล
ฟิลด์ 'Reporter' ของปัญหา
ตัวอย่าง
monitoring_servicehelpdesk_leadnetwork_admin
|
|||
|
มีวิธีแก้ไขชั่วคราว
WorkaroundDetails
|
ระบุว่ามีการบันทึกวิธีแก้ไขชั่วคราวสำหรับปัญหาหรือไม่. | ||
|
คำอธิบาย
บันทึกว่ามีข้อความวิธีแก้ไขชั่วคราวหรือมีการเผยแพร่แล้วหรือไม่ ช่วยให้องค์กรติดตาม 'ความเร็วในการเผยแพร่วิธีแก้ไขชั่วคราว' การวิเคราะห์ฟิลด์นี้ช่วยให้ทราบว่าทีมฟื้นฟูเสถียรภาพของบริการได้เร็วเพียงใด ก่อนจะพบวิธีแก้ไขถาวร.
เหตุผลที่สำคัญ
ใช้วัดความเร็วในการบรรเทาปัญหาเบื้องต้นให้ธุรกิจ.
แหล่งข้อมูล
ฟิลด์ที่กำหนดเอง 'Workaround'
ตัวอย่าง
เริ่มบริการใหม่ล้างแคชของเบราว์เซอร์ไม่มีข้อมูล
|
|||
|
รหัสการแก้ไข
ResolutionCode
|
รหัสที่ระบุวิธีแก้ไขปัญหา. | ||
|
คำอธิบาย
ระบุผลลัพธ์สุดท้ายของระเบียนปัญหา เช่น 'แก้ไขแล้ว' 'ไม่ดำเนินการแก้ไข' 'รายการซ้ำ' หรือ 'ไม่สามารถทำซ้ำได้' ใช้แยกปัญหาที่แก้ไขสำเร็จออกจากรายการที่ปิดด้วยเหตุผลด้านการจัดการ เพื่อให้การคำนวณ KPI เช่น 'เวลาเฉลี่ยจนทราบสาเหตุที่แท้จริง' ถูกต้อง.
เหตุผลที่สำคัญ
แยกการแก้ไขที่ได้ผลออกจากการปิดรายการด้วยเหตุผลด้านการจัดการ.
แหล่งข้อมูล
ฟิลด์ 'Resolution' ของปัญหา
ตัวอย่าง
เสร็จแล้วไม่ดำเนินการรายการซ้ำไม่สามารถทำซ้ำได้
|
|||
|
วันที่สร้าง
CreatedDate
|
วันที่สร้างระเบียนปัญหา. | ||
|
คำอธิบาย
เวลาที่บันทึกปัญหาในระบบเป็นครั้งแรก แม้เวลาของเหตุการณ์จะใช้ระบุเวลาที่กิจกรรมเกิดขึ้น แต่แอตทริบิวต์นี้มักใช้กรองข้อมูลในภาพรวม เช่น 'แสดงปัญหาทั้งหมดที่สร้างในไตรมาส 1' ใช้เป็นจุดอ้างอิงสำหรับวิเคราะห์อายุของปัญหา.
เหตุผลที่สำคัญ
วันที่อ้างอิงสำหรับวิเคราะห์อายุของปัญหาและปริมาณรายการที่รับเข้ามา.
แหล่งข้อมูล
ฟิลด์ 'Created' ของปัญหา
ตัวอย่าง
2023-01-012023-06-15
|
|||
|
สถานะการผิด SLA
SlaBreachStatus
|
ระบุว่าระเบียนปัญหาผิดข้อตกลงระดับการให้บริการหรือไม่. | ||
|
คำอธิบาย
ฟิลด์ค่าจริง/เท็จหรือฟิลด์สถานะที่ระบุว่าเวลาแก้ไขเกินเป้าหมายที่ตกลงกันไว้หรือไม่ ข้อมูลนี้ช่วยในการวิเคราะห์แดชบอร์ด 'การปฏิบัติตาม SLA และแนวโน้มเป้าหมาย' ช่วยชี้กรณีที่อาจทำให้องค์กรเผชิญความเสี่ยงด้านการปฏิบัติตามข้อกำหนดหรือบทลงโทษ.
เหตุผลที่สำคัญ
สำคัญต่อการติดตามการปฏิบัติตามข้อกำหนดและผลการดำเนินงาน.
แหล่งข้อมูล
ตรรกะของฟิลด์ SLA ใน Jira Service Management
ตัวอย่าง
เป็นไปตามเป้าหมายผิดเป้าหมายหยุดชั่วคราว
|
|||
|
แหล่งที่ตรวจพบ
DetectionSource
|
วิธีที่ใช้ระบุปัญหา เช่น เชิงรุกหรือเชิงรับ. | ||
|
คำอธิบาย
ระบุที่มาของการตรวจพบปัญหา ค่าที่พบบ่อย ได้แก่ 'การเฝ้าติดตามเชิงรุก' 'เหตุขัดข้องที่แจ้งผ่าน Service Desk' หรือ 'การแจ้งเตือนจากผู้ให้บริการ' ใช้แอตทริบิวต์นี้ในแดชบอร์ด 'การตรวจพบเชิงรุกเทียบกับเชิงรับ' เพื่อวัดระดับความพร้อมของกระบวนการจัดการปัญหา.
เหตุผลที่สำคัญ
ใช้วัดระดับความพร้อมของกระบวนการและประสิทธิภาพของระบบเฝ้าติดตาม.
แหล่งข้อมูล
ฟิลด์ที่กำหนดเอง 'Source' หรือ 'Detection Source'
ตัวอย่าง
การเฝ้าติดตามเชิงรุกการยกระดับเหตุขัดข้องการแจ้งเตือนจากผู้ให้บริการ
|
|||
กิจกรรมการจัดการปัญหา
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
เชื่อมโยงเหตุขัดข้องกับปัญหา
|
การเชื่อมโยง Ticket เหตุขัดข้องที่เกี่ยวข้องกับรายการปัญหา บันทึกไว้ในตารางลิงก์ Issue หรือประวัติ. | ||
|
เหตุผลที่สำคัญ
ใช้ระบุผลกระทบและขอบเขตของปัญหา จำเป็นต่อ KPI 'ความลึกของการเชื่อมโยงเหตุขัดข้องกับปัญหา' และการจัดลำดับตามผลกระทบต่อธุรกิจ.
แหล่งข้อมูล
ลิงก์ Jira Issue: สร้างลิงก์ประเภท 'causes' หรือ 'relates to'
บันทึก
บันทึกเมื่อสร้างลิงก์ Issue
ประเภทเหตุการณ์
explicit
|
|||
|
ปิดรายการปัญหา
|
จุดสิ้นสุดของวงจรการจัดการปัญหา บันทึกไว้อย่างชัดเจนเมื่อสถานะเปลี่ยนเป็น 'Closed'. | ||
|
เหตุผลที่สำคัญ
จุดสิ้นสุดที่แน่นอนของกระบวนการ จำเป็นต่อการคำนวณระยะเวลารวมและอัตราการปิดรายการ.
แหล่งข้อมูล
ประวัติ Jira Issue: เปลี่ยนสถานะเป็น 'Closed'
บันทึก
บันทึกเมื่อสถานะเปลี่ยนเป็น Closed
ประเภทเหตุการณ์
explicit
|
|||
|
มอบหมายให้กลุ่มสนับสนุน
|
การมอบหมายรายการปัญหาให้ทีมเทคนิคหรือกลุ่มสนับสนุนที่ระบุ ติดตามได้จากการเปลี่ยนแปลงฟิลด์ที่กำหนดเอง 'Support Group' หรือฟิลด์ 'Assignee' หากไม่ได้ใช้กลุ่ม. | ||
|
เหตุผลที่สำคัญ
จำเป็นต่อการวิเคราะห์การส่งต่องานและคอขวดระหว่างทีม การส่งต่องานบ่อยครั้งอาจบ่งชี้ว่าการกำหนดเส้นทางงานไม่มีประสิทธิภาพ.
แหล่งข้อมูล
ประวัติ Jira Issue: ฟิลด์ 'Support Group' หรือ 'Assignee' เปลี่ยนแปลง
บันทึก
บันทึกเมื่อฟิลด์ผู้รับผิดชอบเปลี่ยนแปลง
ประเภทเหตุการณ์
explicit
|
|||
|
ยืนยันผลการแก้ไข
|
การยืนยันว่าการแก้ไขช่วยแก้ปัญหาได้จริง อนุมานได้จากการเปลี่ยนสถานะเป็น 'Resolved' หรือสถานะ 'Verified' โดยเฉพาะ. | ||
|
เหตุผลที่สำคัญ
จุดตรวจสอบคุณภาพเพื่อให้มั่นใจว่าวิธีแก้ได้ผล ความล่าช้าตรงนี้อาจบ่งชี้คอขวดในการทดสอบหรือการยอมรับจากผู้ใช้.
แหล่งข้อมูล
ประวัติ Jira Issue: เปลี่ยนสถานะเป็น 'Resolved' หรือ 'Verified'
บันทึก
เปรียบเทียบการอัปเดตฟิลด์สถานะ
ประเภทเหตุการณ์
inferred
|
|||
|
ระบุสาเหตุที่แท้จริง
|
จุดที่มีการบันทึกสาเหตุเบื้องหลังอย่างเป็นทางการ อนุมานได้จากการเปลี่ยนสถานะเป็น 'Root Cause Identified' หรือการกรอกฟิลด์ 'Root Cause'. | ||
|
เหตุผลที่สำคัญ
หมุดหมายสำคัญที่สิ้นสุดช่วงการตรวจสอบ จำเป็นต่อการคำนวณ 'เวลาเฉลี่ยจนค้นพบสาเหตุที่แท้จริง'.
แหล่งข้อมูล
ประวัติ Jira Issue: เปลี่ยนสถานะเป็น 'Root Cause Identified' หรือกรอกฟิลด์ 'Root Cause'
บันทึก
เปรียบเทียบฟิลด์สถานะหรือตรวจสอบว่ามีการกรอกฟิลด์หรือไม่
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มการตรวจสอบ
|
เปลี่ยนสถานะปัญหาเป็นสถานะที่กำลังตรวจสอบ เช่น 'Under Investigation' หรือ 'In Progress' ซึ่งเป็นจุดเริ่มต้นของช่วงที่เริ่มลงมือทำงาน. | ||
|
เหตุผลที่สำคัญ
เริ่มจับเวลารอบการตรวจสอบ ช่วยแยกเวลารอในงานค้างออกจากเวลาที่ใช้วิเคราะห์จริง.
แหล่งข้อมูล
ประวัติ Jira Issue: เปลี่ยนสถานะเป็น 'Under Investigation' หรือ 'In Progress'
บันทึก
เปรียบเทียบการอัปเดตฟิลด์สถานะ
ประเภทเหตุการณ์
inferred
|
|||
|
สร้างรายการปัญหา
|
เหตุการณ์แรกเมื่อสร้าง Ticket ปัญหาในระบบ โดยบันทึกไว้ในประวัติ Issue เป็นเวลาที่สร้างรายการ. | ||
|
เหตุผลที่สำคัญ
ระบุจุดเริ่มต้นของวงจรการจัดการปัญหาและใช้วิเคราะห์จำนวนรายการ จำเป็นต่อการคำนวณอัตราการดำเนินงานและอัตรารับรายการเข้า.
แหล่งข้อมูล
ตาราง Jira Issue: เวลาที่สร้างรายการ หรือแท็บ History: เหตุการณ์ Issue Created
บันทึก
บันทึกเมื่อระบบยืนยันการสร้าง Issue
ประเภทเหตุการณ์
explicit
|
|||
|
อัปเดตวิธีแก้ปัญหาชั่วคราว
|
การกรอกหรืออัปเดตฟิลด์ข้อความ 'Workaround' เหตุการณ์นี้แสดงว่ามีการบันทึกวิธีแก้ปัญหาชั่วคราวแล้ว. | ||
|
เหตุผลที่สำคัญ
ใช้วัดความรวดเร็วในการบรรเทาผลกระทบต่อธุรกิจ จำเป็นต่อ KPI 'ระยะเวลาจนมีวิธีแก้ปัญหาชั่วคราว'.
แหล่งข้อมูล
ประวัติ Jira Issue: ฟิลด์ 'Workaround' เปลี่ยนแปลง (ไม่เป็นค่าว่าง)
บันทึก
บันทึกเมื่อมีการแก้ไขฟิลด์ Workaround
ประเภทเหตุการณ์
explicit
|
|||
|
เชื่อมโยงคำขอเปลี่ยนแปลง
|
การเชื่อมโยง Request for Change (RFC) กับรายการปัญหา แสดงว่าเริ่มกระบวนการแก้ไขถาวรแล้ว. | ||
|
เหตุผลที่สำคัญ
ใช้วัดระยะเวลาตั้งแต่ระบุสาเหตุได้จนถึงเริ่มแก้ไข สนับสนุน KPI 'ความล่าช้าในการส่งต่อไปจัดการการเปลี่ยนแปลง'.
แหล่งข้อมูล
ลิงก์ Jira Issue: สร้างลิงก์ประเภท 'is fixed by' หรือเชื่อมโยงกับ Issue ประเภท 'Change'
บันทึก
บันทึกเมื่อสร้างลิงก์ไปยัง Issue ประเภท Change
ประเภทเหตุการณ์
explicit
|
|||
|
ทบทวนหลังนำไปใช้
|
การทบทวนหลังนำวิธีแก้ไปใช้ บันทึกได้จากการเปลี่ยนสถานะเป็น 'In Review' หรือการอัปเดตฟิลด์เฉพาะของ PIR. | ||
|
เหตุผลที่สำคัญ
กิจกรรมด้านการปฏิบัติตามข้อกำหนดที่ช่วยบันทึกบทเรียนที่ได้รับ สนับสนุนการวิเคราะห์ 'การปฏิบัติตามข้อกำหนดในการทบทวนหลังนำไปใช้'.
แหล่งข้อมูล
ประวัติ Jira Issue: เปลี่ยนสถานะเป็น 'In Review' หรืออัปเดตฟิลด์ 'PIR Notes'
บันทึก
เปรียบเทียบฟิลด์สถานะหรือการอัปเดตฟิลด์ PIR
ประเภทเหตุการณ์
inferred
|
|||
|
นำวิธีแก้ถาวรไปใช้
|
การเปลี่ยนสถานะที่แสดงว่านำวิธีแก้ไปใช้แล้ว โดยทั่วไปอนุมานได้จากการเปลี่ยนสถานะเป็น 'Implementing' หรือ 'Fixed'. | ||
|
เหตุผลที่สำคัญ
ระบุจุดสิ้นสุดของการแก้ไขทางเทคนิค ใช้วัดระยะเวลารอบการนำไปใช้.
แหล่งข้อมูล
ประวัติ Jira Issue: เปลี่ยนสถานะเป็น 'Implemented', 'Pending Verification' หรือ 'Fixed'
บันทึก
เปรียบเทียบการอัปเดตฟิลด์สถานะ
ประเภทเหตุการณ์
inferred
|
|||
|
เปลี่ยนระดับความสำคัญของปัญหา
|
การอัปเดตฟิลด์ Priority ของรายการปัญหา ตรวจจับได้จากการติดตามการเปลี่ยนแปลงฟิลด์ 'Priority' ในแท็บ History. | ||
|
เหตุผลที่สำคัญ
แสดงว่ามีการยกระดับหรือลดระดับความสำคัญของปัญหา การวิเคราะห์ข้อมูลนี้ช่วยตรวจสอบความแม่นยำของการคัดกรองเบื้องต้นและอายุของงานค้างที่มีความสำคัญสูง.
แหล่งข้อมูล
ประวัติ Jira Issue: ฟิลด์ 'Priority' เปลี่ยนจากค่าเดิมเป็นค่าใหม่
บันทึก
บันทึกเมื่อมีการอัปเดตฟิลด์ Priority
ประเภทเหตุการณ์
explicit
|
|||
|
เปิดปัญหากลับมาดำเนินการ
|
เปลี่ยนสถานะปัญหาจาก 'Resolved' หรือ 'Closed' กลับไปเป็นสถานะที่กำลังดำเนินการ แสดงว่าวิธีแก้ไม่ได้ผลหรือมีการปฏิเสธผลการแก้ไข. | ||
|
เหตุผลที่สำคัญ
ตัวชี้วัดคุณภาพหลัก อัตราการเปิดรายการซ้ำที่สูงบ่งชี้ว่าการวิเคราะห์สาเหตุที่แท้จริงหรือการทดสอบไม่มีประสิทธิภาพ.
แหล่งข้อมูล
ประวัติ Jira Issue: เปลี่ยนสถานะจาก 'Closed'/'Resolved' เป็น 'Open'/'In Progress'
บันทึก
เปรียบเทียบลำดับการเปลี่ยนสถานะ
ประเภทเหตุการณ์
inferred
|
|||
|
ไม่เป็นไปตาม SLA
|
เหตุการณ์ที่แสดงว่าเวลาแก้ปัญหาเกินระยะเวลาที่กำหนดไว้ใน Service Level Agreement คำนวณโดยเปรียบเทียบวันที่เป้าหมายของ SLA กับวันที่แก้ปัญหาเสร็จ. | ||
|
เหตุผลที่สำคัญ
จำเป็นต่อการรายงานการปฏิบัติตามข้อกำหนด ช่วยระบุระดับความสำคัญหรือหมวดหมู่ที่พลาดเป้าหมายบ่อยที่สุด.
แหล่งข้อมูล
บันทึก SLA ของ Jira Service Management: 'Time to Resolution' เกินเป้าหมาย หรือคำนวณจากข้อมูล
บันทึก
คำนวณจากข้อมูลฟิลด์ SLA หรือเปรียบเทียบ Due Date กับ Resolution Date
ประเภทเหตุการณ์
calculated
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
เปลี่ยนข้อมูลการจัดการปัญหาให้เป็นข้อมูลเชิงลึกที่นำไปใช้ได้จริง ดาวน์โหลดคู่มือหรือติดต่อทีมสนับสนุนเพื่อเริ่มต้นใช้ process mining.
ปรับปรุงขั้นตอนการจัดการปัญหาได้ตั้งแต่วันนี้
ลดระยะเวลาตั้งแต่เริ่มจนจบลง 30% และเพิ่มเสถียรภาพให้ระบบ IT.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.