เทมเพลตข้อมูลการจัดการการเปลี่ยนแปลงของคุณ

Jira Service Management
เทมเพลตข้อมูลการจัดการการเปลี่ยนแปลงของคุณ

เทมเพลตข้อมูลการจัดการการเปลี่ยนแปลงของคุณ

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

แอตทริบิวต์การจัดการการเปลี่ยนแปลง

ฟิลด์ข้อมูลเหล่านี้เป็นรายการที่แนะนำให้ใส่ในบันทึกเหตุการณ์ เพื่อวิเคราะห์กระบวนการจัดการการเปลี่ยนแปลงได้ครบถ้วน.
5 จำเป็น 7 แนะนำ 7 ไม่บังคับ
ชื่อ คำอธิบาย
ID คำขอเปลี่ยนแปลง
ChangeRequestId
รหัสเฉพาะของคำขอเปลี่ยนแปลงแต่ละรายการ ใช้รวมกิจกรรมที่เกี่ยวข้องทั้งหมดตั้งแต่สร้างจนถึงปิดคำขอ.
คำอธิบาย

ID คำขอเปลี่ยนแปลงเป็นคีย์หลักที่ใช้ระบุโครงการเปลี่ยนแปลงแต่ละรายการใน Jira Service Management โดยไม่ซ้ำกัน และทำหน้าที่เป็นรหัสกรณีสำหรับ process mining เพื่อเชื่อมโยงเหตุการณ์ การเปลี่ยนสถานะ และการอัปเดตทั้งหมดให้เห็นกระบวนการตั้งแต่ต้นจนจบ

ในการวิเคราะห์ ID นี้ช่วยสร้างวงจรชีวิตทั้งหมดของการเปลี่ยนแปลงแต่ละรายการขึ้นใหม่ และจำเป็นต่อการติดตามการเปลี่ยนแปลงในแต่ละขั้นตอน เช่น การประเมินความเสี่ยง การอนุมัติ การนำไปใช้ และการทบทวน เมตริก KPI และแดชบอร์ดทั้งหมดใช้คุณลักษณะนี้เพื่อรวบรวมและเชื่อมโยงข้อมูลเหตุการณ์ของการเปลี่ยนแปลงแต่ละรายการได้อย่างถูกต้อง.

เหตุผลที่สำคัญ

นี่คือรหัสกรณีพื้นฐานที่ช่วยติดตามเส้นทางทั้งหมดของคำขอเปลี่ยนแปลงและวิเคราะห์ผลการดำเนินงานได้.

แหล่งข้อมูล

นี่คือ Jira Issue Key มาตรฐาน ซึ่งอยู่ในฟิลด์ key ของ issue ประเภทคำขอเปลี่ยนแปลง.

ตัวอย่าง
ITSM-1024CHG-2023-001CR-5921
กิจกรรม
ActivityName
ชื่อของเหตุการณ์ทางธุรกิจหรืองานเฉพาะที่เกิดขึ้นในกระบวนการจัดการการเปลี่ยนแปลง.
คำอธิบาย

คุณลักษณะนี้บันทึกชื่อกิจกรรมที่เกิดขึ้น ณ เวลาหนึ่งในคำขอเปลี่ยนแปลง โดยดึงข้อมูลจากการเปลี่ยนสถานะ ขั้นตอนในเวิร์กโฟลว์ หรือรายการบันทึกเฉพาะใน Jira เช่น 'ส่งคำขอเปลี่ยนแปลงให้ตรวจสอบ' หรือ 'เริ่มนำไปใช้'

การวิเคราะห์ลำดับและความถี่ของกิจกรรมเหล่านี้เป็นหัวใจของ process mining ช่วยค้นหาเส้นทางกระบวนการที่เกิดขึ้นจริง ระบุคอขวดระหว่างขั้นตอน และเปรียบเทียบรูปแบบกระบวนการกับขั้นตอนการปฏิบัติงานมาตรฐาน.

เหตุผลที่สำคัญ

คุณลักษณะนี้กำหนดขั้นตอนของกระบวนการ ซึ่งจำเป็นต่อการค้นหาแผนผังกระบวนการ วิเคราะห์รูปแบบที่แตกต่าง และระบุคอขวด.

แหล่งข้อมูล

โดยทั่วไปดึงข้อมูลจากประวัติ Jira issue โดยเฉพาะการเปลี่ยนสถานะหรือการอัปเดตฟิลด์ที่กำหนดเองซึ่งใช้ระบุหมุดหมายของกระบวนการ.

ตัวอย่าง
อนุมัติคำขอเปลี่ยนแปลงประเมินความเสี่ยงแล้วนำการเปลี่ยนแปลงไปใช้แล้วทบทวนหลังนำไปใช้เสร็จแล้ว
เวลาเริ่มต้น
EventTime
เวลาที่ระบุอย่างแม่นยำว่าเกิดกิจกรรมหรือเหตุการณ์หนึ่งขึ้นเมื่อใด.
คำอธิบาย

เวลาเริ่มต้นหรือเวลาของเหตุการณ์ระบุวันและเวลาที่บันทึกกิจกรรมของคำขอเปลี่ยนแปลงอย่างแม่นยำ กิจกรรมทุกอย่างในบันทึกเหตุการณ์ ตั้งแต่สร้างจนถึงปิดคำขอ จะมีเวลาที่เกี่ยวข้องกำกับไว้

คุณลักษณะนี้สำคัญต่อการวิเคราะห์ตามเวลาใน process mining ใช้คำนวณระยะเวลารอบ ระยะห่างระหว่างกิจกรรม เวลารอ และลำดับเหตุการณ์ อีกทั้งเป็นพื้นฐานสำหรับติดตามผลการดำเนินงาน คำนวณการปฏิบัติตาม SLA และระบุคอขวด.

เหตุผลที่สำคัญ

เวลานี้เป็นพื้นฐานของการวิเคราะห์ผลการดำเนินงานและระยะเวลา ช่วยคำนวณระยะเวลารอบและระบุความล่าช้า.

แหล่งข้อมูล

เวลาของแต่ละรายการในบันทึกประวัติ Jira issue สำหรับเหตุการณ์สร้างรายการ ให้ใช้ฟิลด์ created.

ตัวอย่าง
2023-10-26T10:00:00Z2023-11-01T14:35:10Z2023-11-05T09:00:00Z
ระบบต้นทาง
SourceSystem
ระบุระบบที่ใช้ดึงข้อมูลการจัดการการเปลี่ยนแปลง.
คำอธิบาย

คุณลักษณะนี้ระบุระบบต้นทางของข้อมูลกระบวนการ ในกรณีนี้ ค่าจะเป็น 'Jira Service Management' เสมอ

ในองค์กรที่รวมข้อมูลจากหลายระบบ ฟิลด์นี้จำเป็นต่อการติดตามที่มาของข้อมูล การแก้ไขปัญหา และการทำความเข้าใจความแตกต่างของกระบวนการในแต่ละระบบ ทั้งยังช่วยให้ทราบชัดเจนว่าข้อมูลที่นำมาวิเคราะห์มาจากที่ใด.

เหตุผลที่สำคัญ

ระบุที่มาของข้อมูลอย่างชัดเจน ซึ่งจำเป็นเมื่อรวมข้อมูลจากหลายระบบหรือใช้เพื่อการตรวจสอบ.

แหล่งข้อมูล

นี่คือค่าคงที่ที่เพิ่มระหว่างการดึงข้อมูลเพื่อระบุแหล่งที่มาของชุดข้อมูล.

ตัวอย่าง
Jira Service Management
อัปเดตข้อมูลล่าสุด
LastDataUpdate
เวลาที่ระบุว่ามีการรีเฟรชหรือดึงข้อมูลของระเบียนนี้ครั้งล่าสุดเมื่อใด.
คำอธิบาย

คุณลักษณะนี้บันทึกวันและเวลาที่ดึงข้อมูลจากระบบต้นทางครั้งล่าสุด เพื่อแสดงว่าข้อมูลในเครื่องมือ process mining เป็นข้อมูลล่าสุดเพียงใด

การวิเคราะห์คุณลักษณะนี้ช่วยให้ผู้ใช้ทราบว่าข้อมูลกระบวนการเป็นปัจจุบันแค่ไหน ซึ่งสำคัญต่อแดชบอร์ดการปฏิบัติการและการติดตามแบบเรียลไทม์ อีกทั้งช่วยให้เข้าใจบริบทของผลวิเคราะห์และป้องกันการตัดสินใจจากข้อมูลเก่า.

เหตุผลที่สำคัญ

แสดงว่าข้อมูลเป็นปัจจุบันเพียงใด เพื่อให้การวิเคราะห์เกี่ยวข้องกับสถานการณ์และอิงข้อมูลล่าสุด.

แหล่งข้อมูล

นี่คือฟิลด์เมทาดาทาที่เครื่องมือดึงข้อมูลกรอกเมื่อดึงข้อมูล.

ตัวอย่าง
2024-01-15T02:00:00Z2024-01-16T02:00:00Z
ประเภทการเปลี่ยนแปลง
ChangeRequestType
การจัดประเภทการเปลี่ยนแปลง เช่น มาตรฐาน ปกติ หรือฉุกเฉิน.
คำอธิบาย

ประเภทการเปลี่ยนแปลงใช้จัดหมวดหมู่คำขอตามลักษณะ ความเร่งด่วน และผลกระทบ ประเภทที่พบบ่อย ได้แก่ 'มาตรฐาน' สำหรับการเปลี่ยนแปลงความเสี่ยงต่ำที่อนุมัติไว้ล่วงหน้า 'ปกติ' สำหรับการเปลี่ยนแปลงทั่วไปที่ต้องผ่านการอนุมัติครบถ้วน และ 'ฉุกเฉิน' สำหรับการเปลี่ยนแปลงเร่งด่วนเพื่อแก้ไขเหตุขัดข้อง

ข้อมูลนี้จำเป็นต่อการวิเคราะห์กระบวนการ เพราะคำขอแต่ละประเภทมักมีเส้นทางการทำงานและ SLA ต่างกัน ใช้คำนวณ KPI 'อัตราการเปลี่ยนแปลงฉุกเฉิน' และกรองแดชบอร์ดเพื่อเปรียบเทียบประสิทธิภาพและความเสี่ยงของแต่ละประเภท.

เหตุผลที่สำคัญ

ช่วยแบ่งข้อมูลตามประเภทเพื่อวิเคราะห์ workflow ที่แตกต่างกัน เช่น การเปลี่ยนแปลงมาตรฐานเทียบกับการเปลี่ยนแปลงฉุกเฉิน ซึ่งมีความคาดหวังด้านประสิทธิภาพและความเสี่ยงไม่เหมือนกัน.

แหล่งข้อมูล

โดยทั่วไปเป็นฟิลด์ที่กำหนดเองในโปรเจกต์ Jira Service Management ชื่อฟิลด์อาจแตกต่างกัน แต่ส่วนใหญ่มักใช้ชื่อ 'ประเภทการเปลี่ยนแปลง'.

ตัวอย่าง
มาตรฐานปกติฉุกเฉิน
ผู้รับผิดชอบ
Assignee
ผู้ใช้ที่รับผิดชอบดำเนินการกับคำขอเปลี่ยนแปลงในขณะนั้น.
คำอธิบาย

ผู้รับผิดชอบคือผู้ใช้ที่ดูแลขั้นตอนหรือกิจกรรมปัจจุบันใน workflow การจัดการการเปลี่ยนแปลง ผู้รับผิดชอบอาจเปลี่ยนหลายครั้งตลอดวงจรของคำขอ เมื่อมีการส่งต่องานระหว่างบุคคลหรือทีม

แอตทริบิวต์นี้ใช้วิเคราะห์การกระจายภาระงาน ระบุคอขวดที่เกี่ยวข้องกับผู้ใช้แต่ละราย และทำความเข้าใจการจัดสรรทรัพยากร แดชบอร์ด 'ภาระงานกิจกรรมของทีมเปลี่ยนแปลง' ใช้ข้อมูลนี้แสดงว่าบุคคลหรือกลุ่มใดรับผิดชอบกิจกรรมมากที่สุด.

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

นี่คือฟิลด์มาตรฐาน assignee ในรายการ Jira.

ตัวอย่าง
Alice JohnsonBob WilliamsCharlie Brown
ระดับความเสี่ยง
RiskLevel
ระดับความเสี่ยงที่ประเมินไว้สำหรับการเปลี่ยนแปลง เช่น ต่ำ ปานกลาง หรือสูง.
คำอธิบาย

กระบวนการจัดการการเปลี่ยนแปลงส่วนใหญ่กำหนดให้ประเมินระดับความเสี่ยง เพื่อจัดประเภทผลกระทบด้านลบที่อาจเกิดขึ้นจากการเปลี่ยนแปลง โดยประเมินในขั้นตอนการประเมินความเสี่ยง และมักใช้กำหนด workflow การอนุมัติ

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

เหตุผลที่สำคัญ

ช่วยวิเคราะห์ว่าการควบคุมกระบวนการและ workflow การอนุมัติเหมาะกับระดับความเสี่ยงแต่ละแบบหรือไม่ และช่วยเปรียบเทียบระดับความเสี่ยงกับอัตราความล้มเหลวของการเปลี่ยนแปลง.

แหล่งข้อมูล

โดยทั่วไปเป็นฟิลด์ที่กำหนดเองใน Jira Service Management ชื่อที่พบบ่อย ได้แก่ 'ระดับความเสี่ยง' หรือ 'ผลกระทบ'.

ตัวอย่าง
ต่ำปานกลางสูงวิกฤต
ลำดับความสำคัญ
Priority
ระดับความสำคัญทางธุรกิจที่กำหนดให้กับคำขอเปลี่ยนแปลง.
คำอธิบาย

ฟิลด์ลำดับความสำคัญช่วยให้ทีมจัดลำดับคำขอเปลี่ยนแปลงที่ต้องดำเนินการ โดยสะท้อนทั้งผลกระทบและความเร่งด่วน และใช้ประกอบการวางแผนกำหนดเวลาและจัดสรรทรัพยากร

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

เหตุผลที่สำคัญ

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

แหล่งข้อมูล

นี่คือฟิลด์มาตรฐาน priority ในรายการ Jira.

ตัวอย่าง
สูงสุดสูงปานกลางต่ำ
วันที่เป้าหมายในการดำเนินการให้เสร็จ
TargetCompletionDate
กำหนดเวลาที่วางแผนไว้หรือกำหนดเวลาตามข้อตกลงระดับการให้บริการ (SLA) สำหรับดำเนินการคำขอเปลี่ยนแปลงให้เสร็จ.
คำอธิบาย

แอตทริบิวต์นี้เก็บวันที่คาดว่าจะดำเนินการคำขอเปลี่ยนแปลงให้เสร็จ เพื่อให้เป็นไปตาม SLA และใช้เป็นเกณฑ์เปรียบเทียบกับเวลาที่ดำเนินการเสร็จจริง

วันที่นี้เป็นข้อมูลหลักสำหรับติดตามผลการดำเนินงานเทียบกับข้อตกลง ใช้เป็นพื้นฐานของแดชบอร์ด 'ติดตามประสิทธิภาพ SLA ของการเปลี่ยนแปลง' และ KPI 'อัตราการปฏิบัติตาม SLA ของการเปลี่ยนแปลง' เมื่อเปรียบเทียบวันที่แก้ไขเสร็จจริงกับวันที่เป้าหมาย องค์กรจะประเมินประสิทธิภาพการให้บริการได้.

เหตุผลที่สำคัญ

เป็นข้อมูลหลักสำหรับคำนวณการปฏิบัติตาม SLA และระบุคำขอเปลี่ยนแปลงที่เสี่ยงจะเกินกำหนด.

แหล่งข้อมูล

มักใช้ฟิลด์ duedate ใน Jira หรือค่าจากตัวชี้วัด SLA ที่ตั้งค่าไว้ใน Jira Service Management.

ตัวอย่าง
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T09:00:00Z
สถานะ SLA
SLAStatus
ระบุว่าดำเนินการคำขอเปลี่ยนแปลงเสร็จภายในวันที่เป้าหมายหรือไม่.
คำอธิบาย

แอตทริบิวต์นี้คำนวณโดยเปรียบเทียบวันที่แก้ไขคำขอเปลี่ยนแปลงเสร็จจริงกับ 'วันที่เป้าหมายในการดำเนินการให้เสร็จ' ผลลัพธ์เป็นสถานะที่เข้าใจง่าย เช่น 'เป็นไปตามกำหนด' หรือ 'เกินกำหนด'

สถานะนี้ช่วยให้เห็นผลการดำเนินงานได้ทันทีบนแดชบอร์ด 'ติดตามประสิทธิภาพ SLA ของการเปลี่ยนแปลง' และช่วยสร้าง KPI เช่น 'อัตราการปฏิบัติตาม SLA ของการเปลี่ยนแปลง' ได้ง่ายขึ้น เพราะคำนวณสถานะของแต่ละรายการไว้แล้ว คุณจึงกรองและสรุปข้อมูลเพื่อดูว่าการเปลี่ยนแปลงประเภทใด ทีมใด หรือบริการใดมักไม่เป็นไปตาม SLA.

เหตุผลที่สำคัญ

ให้ผลลัพธ์ที่ชัดเจนว่าแต่ละกรณีเป็นไปตาม SLA หรือไม่ ช่วยให้รายงานและวิเคราะห์การปฏิบัติตาม SLA ได้ง่ายขึ้น.

แหล่งข้อมูล

คำนวณโดยเปรียบเทียบเวลาประทับของกิจกรรม 'ปิดคำขอเปลี่ยนแปลง' ขั้นสุดท้ายกับแอตทริบิวต์ 'TargetCompletionDate'.

ตัวอย่าง
เป็นไปตามกำหนดเกินกำหนด
สถานะการเปลี่ยนแปลง
ChangeRequestStatus
สถานะปัจจุบันหรือสถานะในอดีตของคำขอเปลี่ยนแปลง ณ เวลาที่เกิดเหตุการณ์.
คำอธิบาย

แอตทริบิวต์นี้ระบุสถานะของคำขอเปลี่ยนแปลง เช่น 'รออนุมัติ' 'กำลังดำเนินการ' หรือ 'ปิดแล้ว' ฟิลด์สถานะเป็นส่วนสำคัญของ workflow engine ใน Jira และการเปลี่ยนสถานะเป็นปัจจัยหลักที่กำหนดเส้นทางการทำงานของกระบวนการ

การวิเคราะห์สถานะช่วยติดตามความคืบหน้าของคำขอเปลี่ยนแปลงที่ยังดำเนินอยู่ และดูผลลัพธ์ของรายการที่เสร็จแล้ว เช่น 'ปิดแล้ว - สำเร็จ' หรือ 'ปิดแล้ว - ไม่สำเร็จ' ข้อมูลนี้จำเป็นต่อการสร้างแดชบอร์ดปริมาณงานที่ดำเนินการเสร็จ และวิเคราะห์การทำงานซ้ำเมื่อสถานะย้อนกลับไปยังขั้นตอนก่อนหน้า.

เหตุผลที่สำคัญ

ช่วยให้เห็นความคืบหน้าและผลลัพธ์สุดท้ายของคำขอเปลี่ยนแปลงได้ชัดเจน ซึ่งจำเป็นต่อการวิเคราะห์ปริมาณงานที่ดำเนินการเสร็จและการทำงานซ้ำ.

แหล่งข้อมูล

นี่คือฟิลด์มาตรฐาน status ของรายการ Jira สถานะที่เลือกได้กำหนดไว้ในการตั้งค่า workflow ของโปรเจกต์.

ตัวอย่าง
การวางแผนรออนุมัติกำลังดำเนินการปิดแล้วยกเลิกแล้ว
ทีม
Team
ทีมหรือกลุ่มที่รับผิดชอบคำขอเปลี่ยนแปลงหรือกิจกรรมใดกิจกรรมหนึ่ง.
คำอธิบาย

แอตทริบิวต์นี้ระบุทีมที่ได้รับมอบหมายให้ดำเนินการเปลี่ยนแปลง แม้ Jira จะมีฟิลด์ 'ผู้รับผิดชอบ' สำหรับระบุบุคคล แต่ก็มักใช้ฟิลด์ 'ทีม' มอบหมายงานให้กลุ่มงาน เช่น 'ทีมปฏิบัติการเครือข่าย' หรือ 'ผู้ดูแลฐานข้อมูล'

ข้อมูลนี้จำเป็นต่อแดชบอร์ด 'ภาระงานกิจกรรมของทีมเปลี่ยนแปลง' เพราะช่วยวิเคราะห์ประสิทธิภาพและคอขวดในระดับทีม แทนที่จะดูเฉพาะรายบุคคล ซึ่งมักเป็นประโยชน์ต่อการวางแผนและบริหารทรัพยากรมากกว่า.

เหตุผลที่สำคัญ

ช่วยวิเคราะห์ภาระงานและประสิทธิภาพในระดับทีมหรือแผนก พร้อมชี้ให้เห็นคอขวดที่เกิดขึ้นในระบบ.

แหล่งข้อมูล

โดยทั่วไปเป็นฟิลด์ที่กำหนดเองใน Jira เนื่องจากไม่มีฟิลด์ 'ทีม' มาตรฐาน ฟิลด์นี้อาจเป็นชนิด 'Group Picker' หรือรายการตัวเลือกแบบง่าย.

ตัวอย่าง
ทีมโครงสร้างพื้นฐานบริการหลักฝ่ายสนับสนุนแอปพลิเคชัน
บริการทางธุรกิจ
BusinessService
บริการทางธุรกิจหรือแอปพลิเคชันที่ได้รับผลกระทบจากการเปลี่ยนแปลง.
คำอธิบาย

แอตทริบิวต์นี้เชื่อมโยงคำขอเปลี่ยนแปลงกับบริการทางธุรกิจที่ระบุไว้ในฐานข้อมูลการจัดการการกำหนดค่า (CMDB) เช่น 'บริการอีเมล' หรือ 'CRM ลูกค้า' ซึ่งเป็นแนวคิดสำคัญในการทำความเข้าใจผลกระทบทางธุรกิจของการเปลี่ยนแปลง

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

เหตุผลที่สำคัญ

เชื่อมโยงการเปลี่ยนแปลงทางเทคนิคกับผลกระทบทางธุรกิจ ช่วยจัดลำดับความสำคัญและวิเคราะห์ความเสี่ยงตามความสำคัญของบริการที่ได้รับผลกระทบ.

แหล่งข้อมูล

มักเป็นฟิลด์ที่กำหนดเองใน JSM ซึ่งเชื่อมโยงกับ Jira Assets (เดิมชื่อ Insight) หรือ CMDB อื่น.

ตัวอย่าง
เว็บไซต์องค์กรSAP ERPวิกิภายในองค์กร
ปัญหาหลังนำไปใช้
PostImplementationIssue
ค่าสถานะที่ระบุว่ามีการเชื่อมโยงเหตุขัดข้องหรือปัญหากับการเปลี่ยนแปลงนี้หลังนำไปใช้หรือไม่.
คำอธิบาย

แอตทริบิวต์นี้ระบุว่าการเปลี่ยนแปลงส่งผลเสียหรือไม่ เช่น ทำให้เกิดเหตุขัดข้องในระบบจริง โดยมักตรวจสอบจากการเชื่อมโยงรายการคำขอเปลี่ยนแปลงกับรายการเหตุขัดข้องอย่างน้อยหนึ่งรายการใน Jira

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

เหตุผลที่สำคัญ

วัดคุณภาพและความสำเร็จของการเปลี่ยนแปลงโดยตรง ด้วยการติดตามว่ามีปัญหาในการปฏิบัติการตามมาหรือไม่.

แหล่งข้อมูล

โดยทั่วไปคำนวณจากการตรวจสอบรายการที่เชื่อมโยงใน Jira โดยเฉพาะกรณีที่รายการ Change มีลิงก์ 'เกิดจาก' ซึ่งเชื่อมโยงมาจากรายการ Incident.

ตัวอย่าง
truefalse
เป็นการทำงานซ้ำ
IsRework
ค่าสถานะบูลีนที่เป็นจริงเมื่อคำขอเปลี่ยนแปลงผ่านวงจรการทำงานซ้ำ.
คำอธิบาย

แอตทริบิวต์ที่คำนวณนี้ระบุคำขอเปลี่ยนแปลงที่ถูกส่งกลับไปยังขั้นตอนก่อนหน้าเพื่อแก้ไข เช่น จาก 'รออนุมัติ' กลับไปยัง 'การวางแผน' ซึ่งบ่งชี้ว่าคำขอที่ส่งมาครั้งแรกไม่ครบถ้วน ไม่ถูกต้อง หรือไม่เป็นไปตามเกณฑ์ที่กำหนด

ค่าสถานะนี้ใช้คำนวณ KPI 'อัตราการทำงานซ้ำของการเปลี่ยนแปลง' และแสดงข้อมูลในแดชบอร์ด 'การวิเคราะห์การทำงานซ้ำและการปฏิเสธคำขอเปลี่ยนแปลง' นักวิเคราะห์สามารถกรองกรณีที่มีการทำงานซ้ำเพื่อค้นหาสาเหตุ เช่น วางแผนเบื้องต้นไม่ดี ข้อกำหนดไม่ชัดเจน หรือประเมินความเสี่ยงไม่เพียงพอ.

เหตุผลที่สำคัญ

ช่วยชี้ให้เห็นความไม่มีประสิทธิภาพของกระบวนการ โดยระบุกรณีที่ต้องทำงานเพิ่มเติมนอกแผนอย่างชัดเจน เพื่อนำไปวิเคราะห์สาเหตุของการทำงานซ้ำ.

แหล่งข้อมูล

คำนวณจากการวิเคราะห์ลำดับกิจกรรมในบันทึกเหตุการณ์ โดยตรวจพบการทำงานซ้ำเมื่อกิจกรรมในขั้นตอนหลังตามด้วยกิจกรรมในขั้นตอนก่อนหน้า.

ตัวอย่าง
truefalse
ผลการแก้ไข
Resolution
ผลลัพธ์สุดท้ายของคำขอเปลี่ยนแปลงที่ปิดแล้ว ซึ่งระบุว่าดำเนินการเสร็จอย่างไร.
คำอธิบาย

เมื่อปิดคำขอเปลี่ยนแปลง ฟิลด์ผลการแก้ไขจะระบุรายละเอียดของผลลัพธ์ เช่น 'เสร็จแล้ว' หมายถึงสำเร็จ ส่วน 'ไม่ดำเนินการ' หรือ 'รายการซ้ำ' ระบุเหตุผลอื่นในการปิด ฟิลด์นี้ให้ข้อมูลมากกว่าการดูสถานะ 'ปิดแล้ว' เพียงอย่างเดียว

แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์อัตราความสำเร็จและความล้มเหลวของการเปลี่ยนแปลง ตัวอย่างเช่น KPI 'อัตราปัญหาหลังนำไปใช้' จะวิเคราะห์ได้ชัดเจนขึ้นเมื่อกรองรายการที่มีผลการแก้ไขเป็น 'ล้มเหลว' หรือ 'ย้อนกลับ' นอกจากนี้ยังช่วยแยกการเปลี่ยนแปลงที่นำไปใช้สำเร็จออกจากรายการที่ยกเลิกหรือถูกปฏิเสธหลังอนุมัติ.

เหตุผลที่สำคัญ

ให้รายละเอียดผลลัพธ์สุดท้ายของการเปลี่ยนแปลง ซึ่งจำเป็นต่อการคำนวณอัตราความสำเร็จและความล้มเหลวอย่างแม่นยำ.

แหล่งข้อมูล

นี่คือฟิลด์มาตรฐาน resolution ใน Jira ซึ่งโดยทั่วไปจะกำหนดค่าเมื่อรายการเปลี่ยนไปอยู่ในหมวดสถานะ 'เสร็จแล้ว'.

ตัวอย่าง
เสร็จแล้วไม่ดำเนินการรายการซ้ำยกเลิกแล้วย้อนกลับ
ผู้แจ้ง
Reporter
ผู้ใช้ที่สร้างหรือส่งคำขอเปลี่ยนแปลงในตอนแรก.
คำอธิบาย

ผู้แจ้งคือบุคคลที่สร้างรายการคำขอเปลี่ยนแปลงใน Jira ซึ่งมักเป็นเจ้าของการเปลี่ยนแปลงหรือผู้เริ่มดำเนินการแทนทีม

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

เหตุผลที่สำคัญ

ช่วยระบุแหล่งที่มาของคำขอเปลี่ยนแปลง เพื่อนำไปวิเคราะห์และปรับปรุงคุณภาพของคำขอที่ส่งเข้ามาในครั้งแรก.

แหล่งข้อมูล

นี่คือฟิลด์มาตรฐาน reporter ในรายการ Jira.

ตัวอย่าง
David MillerEva GreenFrank Wright
เหตุผลในการเปลี่ยนแปลง
ChangeReason
เหตุผลหรือความจำเป็นทางธุรกิจที่เสนอให้มีการเปลี่ยนแปลง.
คำอธิบาย

แอตทริบิวต์นี้บันทึกเหตุผลเบื้องหลังการเปลี่ยนแปลง เช่น 'ติดตั้งฟีเจอร์ใหม่' 'แก้ไขข้อบกพร่อง' หรือ 'อัปเกรดโครงสร้างพื้นฐาน' จึงให้บริบทสำคัญเพิ่มเติมจากสรุปหรือคำอธิบาย

ในการวิเคราะห์ สามารถเปรียบเทียบเหตุผลของการเปลี่ยนแปลงกับตัวชี้วัดอื่น เช่น ระยะเวลาดำเนินการ อัตราความล้มเหลว และระดับความเสี่ยง เพื่อหาคำตอบว่า 'คำขอแก้ไขข้อบกพร่องได้รับอนุมัติเร็วกว่าการติดตั้งฟีเจอร์ใหม่หรือไม่' หรือ 'การอัปเกรดโครงสร้างพื้นฐานมีอัตราความล้มเหลวสูงกว่าหรือไม่'.

เหตุผลที่สำคัญ

ให้บริบททางธุรกิจที่ช่วยวิเคราะห์ได้ลึกขึ้น โดยเปรียบเทียบวัตถุประสงค์ของการเปลี่ยนแปลงกับประสิทธิภาพและผลลัพธ์.

แหล่งข้อมูล

โดยทั่วไปเป็นฟิลด์ที่กำหนดเองใน Jira Service Management ซึ่งมักเป็นรายการตัวเลือกหรือฟิลด์ข้อความ.

ตัวอย่าง
แพตช์ความปลอดภัยอัปเกรดซอฟต์แวร์ติดตั้งฮาร์ดแวร์ใหม่
จำเป็น แนะนำ ไม่บังคับ

กิจกรรมการจัดการการเปลี่ยนแปลง

ขั้นตอนและจุดสำคัญเหล่านี้ควรบันทึกไว้ในบันทึกเหตุการณ์ เพื่อค้นพบกระบวนการจัดการการเปลี่ยนแปลงได้อย่างถูกต้อง.
5 แนะนำ 8 ไม่บังคับ
กิจกรรม คำอธิบาย
คำขอเปลี่ยนแปลงรออนุมัติ
ระบุว่าคำขอเปลี่ยนแปลงผ่านการตรวจสอบเบื้องต้นแล้วและกำลังรอการตัดสินใจอย่างเป็นทางการจาก Change Advisory Board (CAB) หรือผู้อนุมัติที่ได้รับมอบหมาย โดยบันทึกจากการเปลี่ยนสถานะในเวิร์กโฟลว์ เช่น เป็น 'Pending Approval' หรือ 'Awaiting CAB'.
เหตุผลที่สำคัญ

กิจกรรมนี้ช่วยวัดเวลารออนุมัติและระบุคอขวดในขั้นตอนตัดสินใจ ซึ่งส่งผลโดยตรงต่อ KPI ระยะเวลารอบการอนุมัติการเปลี่ยนแปลง.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนเป็นสถานะรออนุมัติ เช่น 'Pending CAB Approval' หรือ 'Awaiting Approval'.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็นสถานะ 'Awaiting Approval' ที่กำหนดไว้.

ประเภทเหตุการณ์ inferred
นำการเปลี่ยนแปลงไปใช้แล้ว
หมุดหมายสำคัญที่ระบุว่างานที่เกี่ยวข้องกับการเปลี่ยนแปลงเสร็จสิ้นแล้ว โดยบันทึกจากการเปลี่ยนสถานะในเวิร์กโฟลว์ Jira เป็นสถานะ เช่น 'Implemented' หรือ 'Pending Verification'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนเป็น 'Implemented' หรือ 'Pending Post-Implementation Review'.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็น 'Implemented' หรือสถานะที่มีความหมายใกล้เคียง.

ประเภทเหตุการณ์ inferred
ปิดคำขอเปลี่ยนแปลง
หมายถึงการปิดคำขอเปลี่ยนแปลงขั้นสุดท้าย ซึ่งแสดงว่ากิจกรรมที่เกี่ยวข้องทั้งหมดเสร็จสิ้นแล้ว บันทึกเมื่อสถานะ Jira issue เปลี่ยนเป็นสถานะสิ้นสุดที่แก้ไขแล้ว เช่น 'Closed' หรือ 'Done'.
เหตุผลที่สำคัญ

นี่คือจุดสิ้นสุดหลักของกระบวนการ ใช้คำนวณระยะเวลารอบทั้งหมดและตรวจสอบการปฏิบัติตาม SLA.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนเป็นสถานะปิดขั้นสุดท้าย โดยทั่วไปจะกำหนดค่าฟิลด์ resolution ในเวลาเดียวกัน.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็น 'Closed' หรือ 'Done'.

ประเภทเหตุการณ์ inferred
สร้างคำขอเปลี่ยนแปลง
หมายถึงการสร้างรายการคำขอเปลี่ยนแปลงใน Jira Service Management เป็นครั้งแรก ระบบจะบันทึกเหตุการณ์นี้พร้อมเวลาที่สร้าง เมื่อบันทึก issue ประเภท 'Change' ใหม่เป็นครั้งแรก.
เหตุผลที่สำคัญ

นี่คือจุดเริ่มต้นของคำขอเปลี่ยนแปลงทั้งหมด ซึ่งจำเป็นต่อการวัดระยะเวลารวมและวิเคราะห์ปริมาณการเปลี่ยนแปลงที่เข้ามาในแต่ละช่วงเวลา.

แหล่งข้อมูล

ดึงข้อมูลจากเวลาที่ระบุในช่อง 'created' ของ Jira issue ซึ่งเป็นช่องมาตรฐานของระบบที่มีในทุก issue และเรียกดูได้จากประวัติ issue หรือ API.

บันทึก

ใช้เวลาจากช่อง 'created' ของ Jira issue.

ประเภทเหตุการณ์ explicit
อนุมัติคำขอเปลี่ยนแปลง
หมุดหมายสำคัญที่แสดงว่าการเปลี่ยนแปลงได้รับอนุมัติให้นำไปใช้แล้ว โดยทั่วไปอนุมานจากการเปลี่ยนสถานะในเวิร์กโฟลว์ Jira เป็นสถานะ เช่น 'Approved' หรือ 'Ready for Implementation'.
เหตุผลที่สำคัญ

เหตุการณ์นี้เป็นจุดสิ้นสุดของรอบการอนุมัติและจุดเริ่มต้นของขั้นตอนการนำไปใช้ จำเป็นต่อการวัดระยะเวลารอบการอนุมัติและติดตามการเปลี่ยนแปลงที่ไม่ได้รับอนุญาต.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนเป็นสถานะ 'Approved'.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็น 'Approved' หรือ 'Ready to Implement'.

ประเภทเหตุการณ์ inferred
กำหนดเวลาการเปลี่ยนแปลง
ระบุว่าการเปลี่ยนแปลงที่ได้รับอนุมัติมีกำหนดช่วงเวลาสำหรับนำไปใช้ โดยอนุมานจากการกรอกหรืออัปเดตฟิลด์ 'Planned start date' และ 'Planned end date' ใน Jira issue.
เหตุผลที่สำคัญ

กิจกรรมนี้ช่วยให้เห็นการวางแผนการเปลี่ยนแปลงล่วงหน้า ใช้บริหารทรัพยากรและประเมินระยะเวลาตั้งแต่อนุมัติจนถึงกำหนดนำไปใช้.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยบันทึกเวลาที่กรอกฟิลด์วันที่ เช่น 'Planned start date' หรือ 'Change window'.

บันทึก

ติดตามเวลาที่กรอกฟิลด์ 'Planned start date'.

ประเภทเหตุการณ์ inferred
ทดสอบแล้ว
หมายถึงการทดสอบหลังนำไปใช้เสร็จสิ้น เพื่อยืนยันว่าการเปลี่ยนแปลงทำงานได้ตามที่ต้องการ โดยอาจบันทึกเป็นสถานะแยก เช่น 'In Testing' หรืออนุมานจากความคิดเห็นหรือการอัปเดตของทีม QA หลังเหตุการณ์ 'Change Implemented'.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

อนุมานได้จากการเปลี่ยนสถานะเป็น 'Testing' หรือ 'Under Test' หรือวิเคราะห์ความคิดเห็นและการเปลี่ยนผู้รับผิดชอบในประวัติ issue หลังนำไปใช้.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็น 'In Testing' หรือใช้ข้อมูลจากความคิดเห็น.

ประเภทเหตุการณ์ inferred
ทบทวนหลังนำไปใช้เสร็จแล้ว
ระบุว่าการทบทวนอย่างเป็นทางการเพื่อประเมินผลของการเปลี่ยนแปลงและรวบรวมบทเรียนเสร็จสิ้นแล้ว โดยทั่วไปบันทึกจากการเปลี่ยนสถานะในเวิร์กโฟลว์ เช่น จาก 'Post-Implementation Review' เป็น 'Verified'.
เหตุผลที่สำคัญ

กิจกรรมนี้จำเป็นต่อการปรับปรุงกระบวนการ การวัดระยะเวลารอบการทบทวนช่วยให้มั่นใจว่าได้รวบรวมบทเรียนไว้อย่างทันท่วงที.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนออกจากสถานะ 'Post-Implementation Review'.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนจาก 'PIR' ไปยังสถานะถัดไป.

ประเภทเหตุการณ์ inferred
ปฏิเสธคำขอเปลี่ยนแปลง
หมายถึงการปฏิเสธคำขอเปลี่ยนแปลงอย่างเป็นทางการ ซึ่งโดยทั่วไปจะส่งกลับไปยังผู้ขอเพื่อขอข้อมูลเพิ่มเติมหรือยกเลิกคำขอ โดยบันทึกจากการเปลี่ยนสถานะในเวิร์กโฟลว์ Jira เป็น 'Rejected' หรือ 'Needs More Info'.
เหตุผลที่สำคัญ

การติดตามการปฏิเสธมีความสำคัญต่อการวิเคราะห์อัตราการทำงานซ้ำของการเปลี่ยนแปลง หากกิจกรรมนี้เกิดขึ้นบ่อย แสดงว่าคำขอเปลี่ยนแปลงที่ส่งมาตั้งแต่แรกอาจมีคุณภาพไม่เพียงพอ.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนเป็นสถานะ 'Rejected' หรือสถานะสิ้นสุดที่มีความหมายใกล้เคียง.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็น 'Rejected' หรือ 'Declined'.

ประเภทเหตุการณ์ inferred
ประเมินความเสี่ยงแล้ว
หมายถึงการประเมินความเสี่ยงและผลกระทบของการเปลี่ยนแปลงที่เสนอเสร็จสิ้น โดยมักอนุมานจากประวัติ issue เมื่อมีการกรอกหรืออัปเดตฟิลด์ที่กำหนดเองเกี่ยวกับความเสี่ยง เช่น 'Risk Level' หรือ 'Impact'.
เหตุผลที่สำคัญ

การวิเคราะห์กิจกรรมนี้ช่วยประเมินความแม่นยำของการประเมินความเสี่ยงและตรวจสอบการปฏิบัติตามนโยบายการเปลี่ยนแปลง อีกทั้งจำเป็นต่อการคำนวณ KPI ที่อิงกับความเสี่ยง เช่น อัตราความล้มเหลวของการเปลี่ยนแปลงแยกตามระดับความเสี่ยง.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยบันทึกเวลาที่มีการกำหนดหรือเปลี่ยนค่าฟิลด์ เช่น 'Risk Level', 'Impact' หรือ 'Urgency' เป็นครั้งแรก.

บันทึก

ติดตามเวลาที่กรอกข้อมูลในฟิลด์ เช่น 'Risk Level' หรือ 'Impact' เป็นครั้งแรก.

ประเภทเหตุการณ์ inferred
ยกเลิกคำขอเปลี่ยนแปลง
หมายถึงการยุติคำขอเปลี่ยนแปลงก่อนนำไปใช้หรือดำเนินการเสร็จสิ้น บันทึกเมื่อสถานะ Jira issue เปลี่ยนเป็นสถานะสิ้นสุด เช่น 'Canceled' หรือ 'Withdrawn'.
เหตุผลที่สำคัญ

จุดสิ้นสุดอีกแบบนี้ช่วยวิเคราะห์สาเหตุที่ยกเลิกการเปลี่ยนแปลง หากอัตราการยกเลิกสูง อาจบ่งชี้ว่าการวางแผนเบื้องต้นไม่ดีหรือมีการเปลี่ยนลำดับความสำคัญทางธุรกิจ.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนเป็นสถานะ 'Canceled' และมีการกำหนด resolution ที่เกี่ยวข้อง.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็น 'Canceled' หรือ 'Withdrawn'.

ประเภทเหตุการณ์ inferred
เริ่มนำการเปลี่ยนแปลงไปใช้
ระบุจุดเริ่มต้นของการนำการเปลี่ยนแปลงที่ได้รับอนุมัติไปใช้ในทางเทคนิค โดยทั่วไปบันทึกจากการเปลี่ยนสถานะใน Jira จาก 'Approved' หรือ 'Scheduled' เป็น 'In Progress' หรือ 'Implementing'.
เหตุผลที่สำคัญ

กิจกรรมนี้เป็นจุดเริ่มต้นในการวัดระยะเวลานำไปใช้เฉลี่ย และช่วยระบุคอขวดในช่วงดำเนินการ.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนเป็นสถานะกำลังดำเนินการ เช่น 'In Progress'.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็น 'In Progress' หรือ 'Implementing'.

ประเภทเหตุการณ์ inferred
ส่งคำขอเปลี่ยนแปลงเพื่อทบทวน
ระบุจุดที่กรอกข้อมูลเบื้องต้นของคำขอเปลี่ยนแปลงครบแล้วและส่งเข้ารับการประเมินอย่างเป็นทางการ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะในเวิร์กโฟลว์ Jira เช่น จาก 'Draft' เป็น 'Pending Review'.
เหตุผลที่สำคัญ

กิจกรรมนี้เป็นจุดเริ่มต้นของรอบการอนุมัติ การวัดเวลาตั้งแต่ขั้นตอนนี้จนถึงการอนุมัติจำเป็นต่อการคำนวณ KPI ระยะเวลารอบการอนุมัติและระบุคอขวดในช่วงต้น.

แหล่งข้อมูล

อนุมานจากประวัติ Jira issue โดยระบุเวลาที่ช่อง 'status' เปลี่ยนเป็นสถานะตรวจสอบ เช่น 'Pending Review' หรือ 'Awaiting Assessment'.

บันทึก

ติดตามเวลาที่สถานะเปลี่ยนเป็น 'Pending Review', 'Submitted' หรือสถานะอื่นที่มีความหมายใกล้เคียง.

ประเภทเหตุการณ์ inferred
แนะนำ ไม่บังคับ

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

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

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

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

ยกระดับการจัดการการเปลี่ยนแปลง เพิ่มอัตราความสำเร็จเป็น 95%

ลดการเปลี่ยนแปลงที่ล้มเหลว และเพิ่มอัตราความสำเร็จเป็น 95% ได้ง่ายขึ้น.

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

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