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

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

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

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

แอตทริบิวต์การจัดการปัญหา

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

ตัวอย่าง
การเฝ้าติดตามเชิงรุกการยกระดับเหตุขัดข้องการแจ้งเตือนจากผู้ให้บริการ
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมการจัดการปัญหา

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

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

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

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

เปลี่ยนข้อมูลการจัดการปัญหาให้เป็นข้อมูลเชิงลึกที่นำไปใช้ได้จริง ดาวน์โหลดคู่มือหรือติดต่อทีมสนับสนุนเพื่อเริ่มต้นใช้ process mining.

ปรับปรุงขั้นตอนการจัดการปัญหาได้ตั้งแต่วันนี้

ลดระยะเวลาตั้งแต่เริ่มจนจบลง 30% และเพิ่มเสถียรภาพให้ระบบ IT.

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

ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.