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

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

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

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

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

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

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

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

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

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

แหล่งข้อมูล

สร้างจากการเปลี่ยนสถานะ รายการบันทึก หรือบันทึกเหตุการณ์เฉพาะที่เกี่ยวข้องกับออบเจ็กต์ Change Request ใน Ivanti Cherwell.

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

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปคือรหัสหลักของออบเจ็กต์ธุรกิจ Change Request ใน Ivanti Cherwell.

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

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปพบข้อมูลนี้ในบันทึกการเปลี่ยนสถานะ ประวัติการตรวจสอบ หรือเวลาของรายการบันทึกที่เชื่อมโยงกับออบเจ็กต์ Change Request ใน Ivanti Cherwell.

ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
ระบบต้นทาง
SourceSystem
ระบบบันทึกข้อมูลต้นทางที่ใช้ดึงข้อมูล สำหรับมุมมองนี้คือ 'Ivanti Cherwell'.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปจะกำหนดค่านี้ไว้ระหว่างการดึงและแปลงข้อมูล เพื่อระบุแหล่งที่มาของชุดข้อมูล.

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

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

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

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

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

แหล่งข้อมูล

ระบบสร้างและประทับเวลานี้ลงในแต่ละระเบียนระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL).

ตัวอย่าง
2024-05-21T02:00:00Z
ทีมที่รับผิดชอบการเปลี่ยนแปลง
ChangeTeam
ทีมหรือกลุ่มที่รับผิดชอบคำขอเปลี่ยนแปลงในขณะนั้น.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปข้อมูลนี้จัดเก็บไว้ในฟิลด์ 'Owned By Team' หรือฟิลด์กำหนดกลุ่มที่คล้ายกันในออบเจ็กต์ Change Request.

ตัวอย่าง
ฝ่ายปฏิบัติการเครือข่ายฝ่ายดูแลฐานข้อมูลฝ่ายสนับสนุนแอปพลิเคชัน
ประเภทการเปลี่ยนแปลง
ChangeType
การจัดประเภทการเปลี่ยนแปลง เช่น 'Standard', 'Normal' หรือ 'Emergency'.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ตรงกับฟิลด์จัดประเภทในออบเจ็กต์ธุรกิจ Change Request ซึ่งอาจใช้ชื่อว่า 'Change Type' หรือ 'Category'.

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

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปคือฟิลด์ 'Owned By' หรือ 'Assigned To' ในออบเจ็กต์ธุรกิจ Change Request.

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

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

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

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

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

แหล่งข้อมูล

จัดเก็บค่านี้ไว้ในฟิลด์ 'Risk Level' หรือฟิลด์ที่คล้ายกันในออบเจ็กต์ Change Request โดยทั่วไปจะกรอกข้อมูลระหว่างกิจกรรมประเมินความเสี่ยง.

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

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

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

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

ใช้เป็นเกณฑ์พื้นฐานในการวัดการดำเนินงานตรงเวลาและการปฏิบัติตาม SLA ซึ่งเป็นตัวชี้วัดสำคัญด้านประสิทธิภาพและความน่าเชื่อถือของกระบวนการ.

แหล่งข้อมูล

โดยทั่วไปเป็นฟิลด์วันที่ในออบเจ็กต์ Change Request ซึ่งอาจใช้ชื่อว่า 'Target Date', 'Due Date' หรือ 'SLA Target'.

ตัวอย่าง
2023-11-15T17:00:00Z2023-12-01T23:59:59Z2024-01-10T12:00:00Z
สถานะการเปลี่ยนแปลง
ChangeStatus
สถานะปัจจุบันหรือสถานะสุดท้ายของคำขอเปลี่ยนแปลง เช่น 'Closed', 'Rejected' หรือ 'In Progress'.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ตรงกับฟิลด์ 'Status' ในออบเจ็กต์ธุรกิจ Change Request ของ Ivanti Cherwell.

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

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

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

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

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

แหล่งข้อมูล

แอตทริบิวต์นี้ไม่มีอยู่ในระบบต้นทาง แต่คำนวณระหว่างการแปลงข้อมูลโดยเปรียบเทียบ 'ActualCompletionDate' <= 'TargetCompletionDate'.

ตัวอย่าง
truefalse
บริการที่ได้รับผลกระทบ
ServiceAffected
บริการธุรกิจหลักหรือรายการกำหนดค่า (CI) ที่ได้รับผลกระทบจากการเปลี่ยนแปลง.
คำอธิบาย

ข้อมูลนี้ระบุบริการ IT แอปพลิเคชัน หรือโครงสร้างพื้นฐานหลักที่เป็นเป้าหมายของคำขอเปลี่ยนแปลง และเชื่อมกระบวนการจัดการการเปลี่ยนแปลงเข้ากับภาพรวมการจัดการบริการ IT

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

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

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

แหล่งข้อมูล

โดยทั่วไปเชื่อมโยงจากฐานข้อมูลการจัดการการกำหนดค่า (CMDB) และจัดเก็บไว้ในฟิลด์ 'Primary CI' หรือ 'Service' ของออบเจ็กต์ Change Request.

ตัวอย่าง
บริการอีเมล (Exchange)ระบบ ERP (SAP)สวิตช์เครือข่ายหลัก (CISCO-4500X)
ผู้ส่งคำขอเปลี่ยนแปลง
ChangeSubmitter
ผู้ใช้ที่สร้างหรือส่งคำขอเปลี่ยนแปลงในตอนแรก.
คำอธิบาย

ข้อมูลนี้ระบุผู้เริ่มต้นคำขอเปลี่ยนแปลง ซึ่งอาจไม่ใช่ผู้รับผิดชอบการเปลี่ยนแปลงที่มาดูแลการนำไปใช้ในขั้นตอนถัดไป

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

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

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

แหล่งข้อมูล

โดยทั่วไปคือฟิลด์ 'Created By' หรือ 'Requested By' ในออบเจ็กต์ Change Request.

ตัวอย่าง
Susan MillerDavid ChenMaria Garcia
ระยะเวลารอบการดำเนินการเปลี่ยนแปลง
ImplementationCycleTime
ระยะเวลาตั้งแต่เริ่มดำเนินการเปลี่ยนแปลงจนเสร็จสิ้น ซึ่งคำนวณจากข้อมูลเหตุการณ์.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

คำนวณในเครื่องมือ process mining หรือระหว่างการแปลงข้อมูล โดยหาผลต่างระหว่างเวลาประทับของเหตุการณ์เริ่มต้นและสิ้นสุดการดำเนินการ.

ตัวอย่าง
4 ชั่วโมง 15 นาที1 วัน 2 ชั่วโมง30 นาที
ลำดับความสำคัญของการเปลี่ยนแปลง
ChangePriority
ระดับความสำคัญของคำขอเปลี่ยนแปลง ซึ่งบ่งบอกความเร่งด่วนและผลกระทบต่อธุรกิจ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

โดยทั่วไปคือฟิลด์ 'Priority' ในออบเจ็กต์ Change Request ซึ่งอาจกำหนดด้วยตนเองหรือคำนวณจากฟิลด์ผลกระทบและความเร่งด่วน.

ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
วันที่ดำเนินการเสร็จจริง
ActualCompletionDate
เวลาที่นำการเปลี่ยนแปลงไปใช้จริงและตรวจสอบว่าเสร็จสมบูรณ์แล้ว.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
2023-11-14T16:30:00Z2023-12-03T10:00:00Z2024-01-10T11:45:00Z
หน่วยธุรกิจ
BusinessUnit
หน่วยธุรกิจหรือแผนกที่ร้องขอการเปลี่ยนแปลงหรือจะได้รับประโยชน์จากการเปลี่ยนแปลง.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ข้อมูลนี้อาจอยู่ในฟิลด์ของออบเจ็กต์ Change Request หรือดึงมาจากโปรไฟล์ผู้ใช้ที่ส่งคำขอ.

ตัวอย่าง
การเงินทรัพยากรบุคคลฝ่ายขายและการตลาดการปฏิบัติการ
เหตุผลที่ปฏิเสธ
ChangeRejectionReason
คำอธิบายหรือหมวดหมู่ที่ระบุสาเหตุที่ปฏิเสธคำขอเปลี่ยนแปลง.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

มักบันทึกข้อมูลนี้ไว้ในฟิลด์ 'Rejection Reason' โดยเฉพาะ หรือในฟิลด์หมายเหตุเมื่อเปลี่ยนสถานะเป็น 'Rejected'.

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

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

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

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

แหล่งข้อมูล

อนุมานจากประวัติการตรวจสอบของออบเจ็กต์ Change Request โดยบันทึกเวลาที่ฟิลด์ 'Status' เปลี่ยนเป็น 'อนุมัติแล้ว'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'อนุมัติแล้ว'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติของออบเจ็กต์ Change Request โดยบันทึกเวลาที่ฟิลด์ 'Status' เปลี่ยนเป็น 'Scheduled'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'Scheduled'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการตรวจสอบของออบเจ็กต์ Change Request โดยบันทึกเวลาที่ 'Status' เปลี่ยนเป็นสถานะอย่าง 'Post Implementation Review'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'Post Implementation Review'.

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

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

แหล่งข้อมูล

อนุมานจากบันทึกการตรวจสอบของออบเจ็กต์ Change Request โดยใช้เวลาที่สถานะเปลี่ยนเป็น 'Implemented' หรือ 'Pending Verification'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'Implemented'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติของออบเจ็กต์ Change Request โดยบันทึกเวลาที่ฟิลด์ 'Status' เปลี่ยนจาก 'กำลังประเมิน' เป็นสถานะอย่าง 'รออนุมัติจาก CAB'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'รออนุมัติจาก CAB'.

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

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

แหล่งข้อมูล

อนุมานจากเวลาที่เปลี่ยนสถานะครั้งสุดท้ายเป็น 'Closed' ในประวัติการตรวจสอบของออบเจ็กต์ Change Request.

บันทึก

อนุมานจากการเปลี่ยนสถานะครั้งสุดท้ายเป็น 'Closed'.

ประเภทเหตุการณ์ inferred
สร้าง Change Request
กิจกรรมนี้คือจุดเริ่มต้นของคำขอเปลี่ยนแปลงรายการใหม่ในระบบ โดยทั่วไปจะบันทึกเมื่อสร้างระเบียนใหม่ใน business object ของ Change Request ซึ่งเป็นจุดเริ่มต้นของกระบวนการทั้งหมด.
เหตุผลที่สำคัญ

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

แหล่งข้อมูล

บันทึกเหตุการณ์นี้จากเวลาที่สร้างระเบียน Change Request โดยทั่วไปใน Ivanti Cherwell จะจัดเก็บไว้ในฟิลด์ 'CreatedDateTime' ของ business object ของ Change Request.

บันทึก

บันทึกจากเวลาที่สร้างระเบียนโดยตรง.

ประเภทเหตุการณ์ explicit
Change Request รออนุมัติ
กิจกรรมนี้หมายถึงช่วงเวลาที่คำขอเปลี่ยนแปลงรอการตัดสินใจอย่างเป็นทางการจากคณะกรรมการที่ปรึกษาการเปลี่ยนแปลง (CAB) หรือผู้มีอำนาจอนุมัติรายอื่น อนุมานได้จากสถานะอย่าง 'รออนุมัติ' หรือ 'รอ CAB'.
เหตุผลที่สำคัญ

กิจกรรมนี้เป็นช่วงเวลารอที่สำคัญ การวิเคราะห์ระยะเวลาช่วยระบุคอขวดในเวิร์กโฟลว์การอนุมัติ ซึ่งมักเป็นสาเหตุของความล่าช้าใน Change Management.

แหล่งข้อมูล

บันทึกจากเวลาที่ฟิลด์ 'Status' ใน business object ของ Change Request เปลี่ยนเป็น 'รออนุมัติ' หรือค่าอื่นที่มีความหมายเทียบเท่า.

บันทึก

ระบุจากการเข้าสู่สถานะ 'รออนุมัติ'.

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

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

แหล่งข้อมูล

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

บันทึก

อนุมานจากการเปลี่ยนสถานะจาก 'อนุมัติแล้ว' เป็น 'กำหนดเวลาแล้ว'.

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

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

แหล่งข้อมูล

บันทึกจากเวลาที่สถานะของออบเจ็กต์ Change Request เปลี่ยนแปลง เช่น เปลี่ยนเป็น 'Verification' หรือ 'User Acceptance Testing'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'Verification'.

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

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

แหล่งข้อมูล

อนุมานจากเวลาที่ฟิลด์ 'Status' ในออบเจ็กต์ Change Request เปลี่ยนเป็น 'ปฏิเสธแล้ว' ตามประวัติการตรวจสอบ.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'ปฏิเสธแล้ว'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการตรวจสอบ โดยบันทึกเวลาที่ฟิลด์ 'Status' ของออบเจ็กต์ Change Request เปลี่ยนเป็น 'Cancelled'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'Cancelled'.

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

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

แหล่งข้อมูล

อนุมานจากประวัติการตรวจสอบของออบเจ็กต์ Change Request โดยใช้เวลาที่ฟิลด์ 'Status' เปลี่ยนเป็นค่าอย่าง 'In Progress' หรือ 'Implementing'.

บันทึก

อนุมานจากการเปลี่ยนสถานะเป็น 'In Progress'.

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

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

แหล่งข้อมูล

อนุมานจากบันทึกการตรวจสอบหรือประวัติของออบเจ็กต์ Change Request โดยระบุเวลาที่ฟิลด์ 'Status' เปลี่ยนเป็นค่าอย่าง 'กำลังประเมิน' หรือ 'ส่งแล้ว'.

บันทึก

อนุมานจากการเปลี่ยนสถานะจาก 'ใหม่' เป็น 'กำลังประเมิน'.

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

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

วิธีดึงข้อมูลจาก Ivanti Cherwell

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

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

เพิ่มอัตราความสำเร็จของการเปลี่ยนแปลงเป็น 95%: ปรับปรุง Ivanti Cherwell วันนี้

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

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

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