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