เทมเพลตข้อมูลการจัดการการเปลี่ยนแปลงของคุณ
เทมเพลตข้อมูลการจัดการการเปลี่ยนแปลงของคุณ
นี่คือเทมเพลตข้อมูล process mining ทั่วไปสำหรับ การจัดการการเปลี่ยนแปลง หากต้องการคำแนะนำเฉพาะเจาะจง โปรดใช้เทมเพลตสำหรับระบบนั้น.
เลือกระบบที่ต้องการ- โครงสร้างมาตรฐานสำหรับบันทึกเหตุการณ์การจัดการการเปลี่ยนแปลง.
- ฟิลด์ข้อมูลและขั้นตอนกระบวนการที่แนะนำสำหรับการวิเคราะห์อย่างละเอียด.
- พื้นฐานที่ใช้ได้กับระบบจัดการบริการ IT หลากหลายประเภท.
แอตทริบิวต์การจัดการการเปลี่ยนแปลง
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
| ชื่อกิจกรรม ActivityName | ชื่อเหตุการณ์ทางธุรกิจ งาน หรือการเปลี่ยนสถานะที่เกิดขึ้นในกระบวนการจัดการการเปลี่ยนแปลง. | ||
| คำอธิบาย ชื่อกิจกรรมระบุขั้นตอนหรือหมุดหมายที่ชัดเจนในวงจรคำขอเปลี่ยนแปลง เช่น 'ประเมินความเสี่ยงเสร็จแล้ว' หรือ 'อนุมัติการเปลี่ยนแปลงแล้ว' แต่ละกิจกรรมแสดงช่วงเวลาที่มีการดำเนินการ ตัดสินใจ หรือเปลี่ยนไปสู่ขั้นตอนใหม่ แอตทริบิวต์นี้เป็นพื้นฐานของการสร้างแผนผังกระบวนการ โดยกำหนดโหนดในกราฟกระบวนการให้นักวิเคราะห์เห็นลำดับเหตุการณ์ ระบุเส้นทางที่เกิดขึ้นบ่อย และค้นหาความเบี่ยงเบนจากขั้นตอนมาตรฐาน การวิเคราะห์กิจกรรมช่วยค้นหาคอขวด งานที่ต้องทำซ้ำ และการส่งต่องานที่ไม่มีประสิทธิภาพระหว่างขั้นตอนต่างๆ ของกระบวนการเปลี่ยนแปลง. เหตุผลที่สำคัญ ใช้ระบุขั้นตอนในกระบวนการ ทำให้เห็นลำดับการทำงานและวิเคราะห์คอขวด งานที่ต้องทำซ้ำ และความเบี่ยงเบนได้. แหล่งข้อมูล โดยทั่วไปอยู่ในบันทึกกิจกรรม ประวัติเหตุการณ์ หรือตารางบันทึกการตรวจสอบที่เชื่อมโยงกับคำขอเปลี่ยนแปลง. ตัวอย่าง ส่งคำขอเปลี่ยนแปลงเพื่อตรวจสอบอนุมัติการเปลี่ยนแปลงแล้วเริ่มนำการเปลี่ยนแปลงไปใช้ปิดคำขอเปลี่ยนแปลง | |||
| รหัสคำขอเปลี่ยนแปลง ChangeRequestId | รหัสเฉพาะที่ระบบสร้างขึ้นสำหรับคำขอเปลี่ยนแปลง ใช้เป็นรหัสหลักของเคสเพื่อจัดกลุ่มกิจกรรมและเหตุการณ์ที่เกี่ยวข้องทั้งหมด. | ||
| คำอธิบาย รหัสคำขอเปลี่ยนแปลงเป็นรหัสตัวอักษรและตัวเลขที่ไม่ซ้ำกัน ซึ่งกำหนดให้กับคำขอแต่ละรายการเมื่อสร้างขึ้น รหัสนี้ทำหน้าที่เป็นคีย์หลักของเคสการเปลี่ยนแปลงแต่ละรายการ และเชื่อมโยงงาน การอนุมัติ และบันทึกทั้งหมดตั้งแต่เริ่มต้นจนปิดคำขอ ในการทำ process mining แอตทริบิวต์นี้จำเป็นต่อการสร้างเส้นทางการเปลี่ยนแปลงแต่ละรายการตั้งแต่ต้นจนจบ เมื่อนักวิเคราะห์จัดกลุ่มเหตุการณ์ทั้งหมดด้วยรหัสคำขอเปลี่ยนแปลงเดียวกัน ก็จะเห็นลำดับกระบวนการ คำนวณระยะเวลาของแต่ละเคส และเปรียบเทียบความแตกต่างระหว่างวงจรการเปลี่ยนแปลงได้ รหัสนี้เป็นพื้นฐานของการวิเคราะห์ระดับเคส และช่วยให้เห็นชัดเจนว่าการเปลี่ยนแปลงแต่ละรายการดำเนินไปในระบบอย่างไร. เหตุผลที่สำคัญ รหัสนี้สำคัญต่อการติดตามและเชื่อมโยงเหตุการณ์ทั้งหมดของการเปลี่ยนแปลงแต่ละรายการ จึงเป็นหัวใจของการค้นพบกระบวนการและการตรวจสอบความสอดคล้อง. แหล่งข้อมูล โดยทั่วไปจะอยู่ในส่วนหัวหรือระเบียนหลักของธุรกรรมคำขอเปลี่ยนแปลง. ตัวอย่าง CHG0034501CRQ-10293789123ITSM-CHG-5501 | |||
| เวลาเริ่มเหตุการณ์ EventStartTime | วันและเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์เริ่มต้นขึ้น. | ||
| คำอธิบาย เวลาเริ่มเหตุการณ์ระบุจุดเริ่มต้นของกิจกรรมในวงจรคำขอเปลี่ยนแปลง ค่านี้จำเป็นต่อการเรียงเหตุการณ์ตามลำดับเวลา และคำนวณระยะเวลาของกิจกรรมแต่ละรายการรวมถึงระยะเวลาของเคสทั้งหมด ในการวิเคราะห์กระบวนการ แอตทริบิวต์นี้ใช้เรียงกิจกรรมให้ถูกต้องและเป็นพื้นฐานของบันทึกเหตุการณ์ นอกจากนี้ยังจำเป็นต่อการคำนวณตัวชี้วัดด้านเวลา เช่น รอบเวลาระหว่างกิจกรรม เวลารอ และระยะเวลารวมของเคส การวิเคราะห์เวลาเหล่านี้ช่วยให้องค์กรเห็นว่าขั้นตอนใดใช้เวลามากที่สุด และระบุโอกาสในการเร่งกระบวนการได้. เหตุผลที่สำคัญ จำเป็นต่อการเรียงเหตุการณ์ ค้นหาเส้นทางของกระบวนการ และคำนวณตัวชี้วัดประสิทธิภาพด้านเวลา เช่น รอบเวลาและเวลารอ. แหล่งข้อมูล อยู่ในบันทึกเหตุการณ์หรือบันทึกการตรวจสอบของคำขอเปลี่ยนแปลง โดยอาจใช้ชื่อ 'วันที่สร้าง' 'วันที่เริ่มต้น' หรือ 'การประทับเวลา'. ตัวอย่าง 2023-10-26T09:00:00Z2023-10-26T14:22:10Z2023-10-27T11:05:00Z | |||
| ระบบต้นทาง SourceSystem | ชื่อระบบหรือแอปพลิเคชันที่ใช้ดึงข้อมูลการจัดการการเปลี่ยนแปลง. | ||
| คำอธิบาย แอตทริบิวต์ระบบต้นทางระบุแหล่งที่มาของข้อมูลเหตุการณ์ ในสภาพแวดล้อมที่มีเครื่องมือ ITSM หรือระบบเชื่อมต่อหลายระบบ ฟิลด์นี้ช่วยแยกข้อมูลจากแต่ละแหล่ง เพื่อรักษาความถูกต้องและบริบทของข้อมูล แม้จะไม่ได้ใช้ในการวิเคราะห์ลำดับกระบวนการหลักเสมอไป แต่แอตทริบิวต์นี้มีประโยชน์มากในการตรวจสอบและกำกับดูแลข้อมูล ช่วยแก้ปัญหาการนำเข้าข้อมูล และใช้เปรียบเทียบประสิทธิภาพของกระบวนการระหว่างระบบหรือหน่วยธุรกิจที่ใช้แพลตฟอร์มต่างกันได้ เช่น บริษัทอาจใช้ระบบหนึ่งจัดการการเปลี่ยนแปลงโครงสร้างพื้นฐาน และอีกระบบสำหรับการเปลี่ยนแปลงแอปพลิเคชัน. เหตุผลที่สำคัญ ระบุแหล่งที่มาของข้อมูล ซึ่งจำเป็นต่อการตรวจสอบข้อมูล แก้ปัญหา และวิเคราะห์กระบวนการที่เกี่ยวข้องกับหลายระบบ. แหล่งข้อมูล ข้อมูลนี้อาจจัดเก็บเป็นฟิลด์ในข้อมูลต้นทาง หรือเพิ่มเข้ามาระหว่างการดึงและแปลงข้อมูล (ETL). ตัวอย่าง ServiceNowJira Service ManagementBMC Helix ITSMIvanti Cherwell | |||
| เวลาอัปเดตข้อมูลล่าสุด LastDataUpdate | เวลาที่ระบุว่าข้อมูลของระเบียนนี้ได้รับการรีเฟรชหรือดึงจากระบบต้นทางครั้งล่าสุดเมื่อใด. | ||
| คำอธิบาย เวลาอัปเดตข้อมูลล่าสุดระบุเวลาที่ดึงระเบียนนั้นจากระบบต้นทางครั้งล่าสุด แอตทริบิวต์ข้อมูลกำกับนี้จำเป็นต่อการจัดการไปป์ไลน์ข้อมูลและตรวจสอบว่าข้อมูลที่ใช้วิเคราะห์เป็นข้อมูลล่าสุด แอตทริบิวต์นี้ช่วยให้วิศวกรข้อมูลและนักวิเคราะห์ทราบว่าข้อมูลที่ใช้อยู่เป็นข้อมูลปัจจุบันเพียงใด ใช้ติดตามสถานะของกระบวนการดึงข้อมูล และยืนยันว่าการวิเคราะห์ process mining อ้างอิงข้อมูลที่ใหม่และเกี่ยวข้อง โดยทั่วไปจะไม่ใช้วิเคราะห์กระบวนการโดยตรง แต่สำคัญต่อการกำกับดูแลและความน่าเชื่อถือของข้อมูล. เหตุผลที่สำคัญ ช่วยให้ข้อมูลเป็นปัจจุบันและติดตามสถานะของไปป์ไลน์ข้อมูล ซึ่งจำเป็นต่อความน่าเชื่อถือของการวิเคราะห์กระบวนการ. แหล่งข้อมูล โดยทั่วไปเวลานี้จะถูกสร้างและเพิ่มระหว่างกระบวนการดึง แปลง และโหลดข้อมูล (ETL). ตัวอย่าง 2024-05-20T12:00:00Z2024-05-20T12:05:10Z2024-05-20T12:10:00Z | |||
| ทีมผู้รับผิดชอบ ResponsibleTeam | ทีม กลุ่มงาน หรือคิวที่รับผิดชอบคำขอเปลี่ยนแปลงหรือกิจกรรมเฉพาะในกระบวนการ. | ||
| คำอธิบาย ทีมผู้รับผิดชอบระบุกลุ่มบุคลากรที่ได้รับมอบหมายให้ดำเนินการเปลี่ยนแปลงในแต่ละขั้นตอน เช่น ทีมประเมิน คณะกรรมการอนุมัติอย่าง CAB หรือทีมเทคนิคที่นำการเปลี่ยนแปลงไปใช้ แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์การจัดสรรทรัพยากร การกระจายภาระงาน และการส่งต่องานระหว่างทีม การวิเคราะห์เครือข่ายความสัมพันธ์ช่วยให้เห็นรูปแบบการสื่อสารและคอขวดระหว่างกลุ่มต่างๆ เมื่อวัดเวลาที่แต่ละทีมใช้ดำเนินงาน องค์กรจะระบุได้ว่าทีมใดมีงานล้นมือ หรือมักเกิดความล่าช้าตรงจุดส่งต่อความรับผิดชอบ. เหตุผลที่สำคัญ จำเป็นต่อการวิเคราะห์การส่งต่องานระหว่างทีม ระบุคอขวดด้านทรัพยากร และทำความเข้าใจการกระจายภาระงานทั่วทั้งองค์กร. แหล่งข้อมูล อยู่ในระเบียนคำขอเปลี่ยนแปลงหรือรายละเอียดระดับกิจกรรม โดยอาจใช้ชื่อ 'กลุ่มผู้รับผิดชอบ' หรือ 'ทีม'. ตัวอย่าง CABวิศวกรรมเครือข่ายผู้ดูแลฐานข้อมูลฝ่ายสนับสนุนแอปพลิเคชันระดับ 2 | |||
| บริการที่ได้รับผลกระทบ AffectedBusinessService | บริการทางธุรกิจหลักหรือรายการกำหนดค่า (CI) ที่ได้รับผลกระทบจากการเปลี่ยนแปลง. | ||
| คำอธิบาย บริการทางธุรกิจที่ได้รับผลกระทบระบุความสามารถหลักของธุรกิจ เช่น 'บริการอีเมล' หรือ 'ธนาคารออนไลน์' ซึ่งจะได้รับการเปลี่ยนแปลง นอกจากนี้ยังอาจเป็นรายการกำหนดค่าทางเทคนิค (CI) เช่น เซิร์ฟเวอร์หรือแอปพลิเคชันที่รองรับบริการทางธุรกิจ แอตทริบิวต์นี้ให้บริบททางธุรกิจที่สำคัญแก่กระบวนการจัดการการเปลี่ยนแปลง ช่วยวิเคราะห์ผลกระทบในมุมธุรกิจ ไม่ใช่แค่มองเป็นกิจกรรมด้าน IT นักวิเคราะห์จึงระบุได้ว่าบริการใดมีการเปลี่ยนแปลงบ่อยที่สุด ซึ่งอาจบ่งชี้ถึงความไม่เสถียรหรือการพัฒนาที่เกิดขึ้นบ่อย นอกจากนี้ยังช่วยจัดลำดับความสำคัญและประเมินความเสี่ยง โดยเชื่อมโยงการเปลี่ยนแปลงทางเทคนิคกับงานธุรกิจที่การเปลี่ยนแปลงนั้นรองรับ. เหตุผลที่สำคัญ เชื่อมโยงการเปลี่ยนแปลงด้าน IT กับบริบททางธุรกิจ ช่วยวิเคราะห์ว่ากิจกรรมการเปลี่ยนแปลงส่งผลต่อบริการทางธุรกิจใดมากที่สุดและมีความเสี่ยงอะไรบ้าง. แหล่งข้อมูล อยู่ในระเบียนหลักของคำขอเปลี่ยนแปลง โดยมักเชื่อมโยงจากฐานข้อมูลการจัดการการกำหนดค่า (CMDB). ตัวอย่าง ธนาคารออนไลน์บริการอีเมลSAP ERPSRV_WebApp01 | |||
| ประเภทการเปลี่ยนแปลง ChangeType | การจัดประเภทการเปลี่ยนแปลง เช่น มาตรฐาน ปกติ หรือฉุกเฉิน ซึ่งมักกำหนดเส้นทางของกระบวนการ. | ||
| คำอธิบาย ประเภทการเปลี่ยนแปลงเป็นการจัดหมวดหมู่สำคัญที่กำหนดเวิร์กโฟลว์ ขั้นตอนอนุมัติ และความเร่งด่วนของคำขอเปลี่ยนแปลง โดยทั่วไปการเปลี่ยนแปลงมาตรฐานได้รับอนุมัติล่วงหน้าและมีความเสี่ยงต่ำ ส่วนการเปลี่ยนแปลงปกติต้องผ่านการประเมินและอนุมัติครบทุกขั้นตอน ขณะที่การเปลี่ยนแปลงฉุกเฉินต้องดำเนินการเร่งด่วนตามความจำเป็นทางธุรกิจ การวิเคราะห์กระบวนการแยกตามประเภทการเปลี่ยนแปลงเป็นส่วนสำคัญของการวิเคราะห์การจัดการการเปลี่ยนแปลง ช่วยเปรียบเทียบประสิทธิภาพและการปฏิบัติตามข้อกำหนดของเวิร์กโฟลว์แต่ละแบบ เช่น ตรวจสอบว่าการเปลี่ยนแปลงฉุกเฉินดำเนินไปเร็วขึ้นจริงหรือไม่ หรือการเปลี่ยนแปลงมาตรฐานเป็นไปตามขั้นตอนที่เรียบง่ายและอนุมัติไว้ล่วงหน้าหรือไม่ การแบ่งกลุ่มเช่นนี้ช่วยให้เข้าใจความแตกต่างของกระบวนการและกำกับดูแลได้เหมาะสม. เหตุผลที่สำคัญ แอตทริบิวต์นี้จำเป็นต่อการแบ่งกลุ่มการวิเคราะห์ เพราะประเภทการเปลี่ยนแปลงแต่ละแบบมีเส้นทางกระบวนการ ข้อกำหนดการอนุมัติ และเป้าหมายด้านประสิทธิภาพที่กำหนดไว้ต่างกัน. แหล่งข้อมูล อยู่ในระเบียนหลักหรือข้อมูลส่วนหัวของคำขอเปลี่ยนแปลง. ตัวอย่าง มาตรฐานปกติฉุกเฉินสำคัญ | |||
| ผู้ใช้ที่รับผิดชอบ ResponsibleUser | ผู้ใช้ที่รับผิดชอบคำขอเปลี่ยนแปลงหรือดำเนินงานเฉพาะให้เสร็จสิ้น. | ||
| คำอธิบาย ผู้ใช้ที่รับผิดชอบคือบุคคลที่ได้รับมอบหมายให้ดูแลคำขอเปลี่ยนแปลงหรือกิจกรรม แอตทริบิวต์นี้ช่วยให้เห็นภาระงานและความรับผิดชอบในระดับบุคคลได้ละเอียดกว่าการมอบหมายงานให้ทีม การวิเคราะห์ข้อมูลระดับผู้ใช้ช่วยในการบริหารผลการปฏิบัติงานและระบุโอกาสในการฝึกอบรม อีกทั้งยังช่วยให้เห็นผู้ที่เชี่ยวชาญในกระบวนการหรือผู้ที่อาจต้องการความช่วยเหลือในบางงาน นอกจากนี้ยังใช้วิเคราะห์งานที่ต้องทำซ้ำได้ เช่น ตรวจสอบว่าการเปลี่ยนแปลงที่บุคคลบางคนดูแลมีแนวโน้มถูกปฏิเสธหรือต้องแก้ไขมากกว่าหรือไม่ อย่างไรก็ตาม ควรใช้ข้อมูลนี้เพื่อการพัฒนา ไม่ใช่เพื่อลงโทษ. เหตุผลที่สำคัญ ช่วยให้เห็นภาระงานและผลการปฏิบัติงานของแต่ละบุคคลอย่างละเอียด เพื่อระบุผู้เชี่ยวชาญและความต้องการฝึกอบรมในทีม. แหล่งข้อมูล โดยทั่วไปอยู่ในระเบียนคำขอเปลี่ยนแปลงหรือรายละเอียดระดับงาน โดยมักใช้ชื่อ 'ผู้รับมอบหมาย' หรือ 'มอบหมายให้'. ตัวอย่าง John Smithjane.doeServiceAccountยังไม่ได้มอบหมาย | |||
| ระดับความเสี่ยง RiskLevel | การประเมินความเสี่ยงที่อาจเกิดจากการนำการเปลี่ยนแปลงไปใช้ เช่น 'ต่ำ' 'ปานกลาง' หรือ 'สูง'. | ||
| คำอธิบาย ระดับความเสี่ยงแสดงโอกาสที่การเปลี่ยนแปลงจะล้มเหลวและผลกระทบด้านลบที่อาจเกิดขึ้น การประเมินนี้มีผลต่อระดับการทดสอบ การตรวจสอบ และการอนุมัติที่ต้องดำเนินการ โดยทั่วไปการเปลี่ยนแปลงที่มีความเสี่ยงสูงต้องผ่านการตรวจสอบอย่างเข้มงวดกว่ารายการที่มีความเสี่ยงต่ำ แอตทริบิวต์นี้ช่วยวิเคราะห์กระบวนการโดยพิจารณาจากความเสี่ยง ใช้ตรวจสอบได้ว่าการเปลี่ยนแปลงที่มีความเสี่ยงสูงได้รับการตรวจสอบอย่างเหมาะสมหรือไม่ เช่น ผ่านการพิจารณาจากคณะกรรมการที่ปรึกษาการเปลี่ยนแปลง (CAB) นอกจากนี้ยังใช้เปรียบเทียบระดับความเสี่ยงกับผลลัพธ์ได้ เช่น ตรวจสอบว่าการเปลี่ยนแปลงที่มีความเสี่ยงสูงล้มเหลวบ่อยกว่าหรือไม่ ซึ่งอาจบ่งชี้ว่าควรปรับปรุงการประเมินหรือการลดความเสี่ยง. เหตุผลที่สำคัญ ช่วยตรวจสอบว่าการควบคุมกระบวนการและเวิร์กโฟลว์การอนุมัติสอดคล้องกับระดับความเสี่ยงที่ประเมินไว้หรือไม่. แหล่งข้อมูล อยู่ในข้อมูลส่วนหัวหรือรายละเอียดการประเมินความเสี่ยงของคำขอเปลี่ยนแปลง. ตัวอย่าง สูงปานกลางต่ำสูงมาก | |||
| ลำดับความสำคัญ ChangePriority | ระดับความสำคัญของคำขอเปลี่ยนแปลง ซึ่งโดยทั่วไปพิจารณาจากผลกระทบและความเร่งด่วน. | ||
| คำอธิบาย ลำดับความสำคัญของการเปลี่ยนแปลงใช้จัดระดับความสำคัญของคำขอ ช่วยให้ทีมจัดตารางงานและจัดสรรทรัพยากรได้เหมาะสม เพื่อให้ดำเนินการเปลี่ยนแปลงที่สำคัญที่สุดก่อน โดยมักพิจารณาจากผลกระทบที่อาจเกิดกับธุรกิจและความเร่งด่วนในการนำไปใช้ ในการทำ process mining ลำดับความสำคัญเป็นมิติที่ใช้กรองและเปรียบเทียบข้อมูลได้ นักวิเคราะห์ตรวจสอบได้ว่าการเปลี่ยนแปลงที่มีลำดับความสำคัญสูงดำเนินการเร็วกว่ารายการที่มีลำดับความสำคัญต่ำจริงหรือไม่ หากพบความแตกต่าง อาจเป็นสัญญาณของปัญหาในการจัดสรรทรัพยากร คอขวดด้านการอนุมัติรายการสำคัญ หรือการปฏิบัติตามหลักเกณฑ์จัดลำดับความสำคัญที่ไม่สม่ำเสมอ. เหตุผลที่สำคัญ ช่วยวิเคราะห์ว่าการเปลี่ยนแปลงที่มีความสำคัญสูงดำเนินการเร็วกว่ารายการที่มีความสำคัญต่ำหรือไม่ และตรวจสอบว่านโยบายจัดลำดับความสำคัญได้ผลเพียงใด. แหล่งข้อมูล อยู่ในระเบียนหลักหรือข้อมูลส่วนหัวของคำขอเปลี่ยนแปลง. ตัวอย่าง 1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ | |||
| เวลาสิ้นสุดเหตุการณ์ EventEndTime | วันและเวลาที่แน่นอนซึ่งกิจกรรมหรือเหตุการณ์เสร็จสิ้น. | ||
| คำอธิบาย เวลาสิ้นสุดเหตุการณ์ระบุเวลาที่กิจกรรมเสร็จสิ้น เมื่อนำมาใช้คู่กับเวลาเริ่มเหตุการณ์ จะคำนวณเวลาที่ใช้ดำเนินการในแต่ละขั้นตอนของวงจรการเปลี่ยนแปลงได้อย่างแม่นยำ แอตทริบิวต์นี้เป็นพื้นฐานของการวิเคราะห์ประสิทธิภาพ เวลาที่ต่างกันระหว่างเวลาเริ่มต้นกับเวลาสิ้นสุดแสดง 'เวลาประมวลผล' ของกิจกรรม ส่วนช่วงเวลาระหว่างกิจกรรมหนึ่งสิ้นสุดกับกิจกรรมถัดไปเริ่มแสดง 'เวลารอ' การแยกเวลาสองส่วนนี้ช่วยให้ทราบว่าความล่าช้าเกิดจากงานที่ใช้เวลานานหรือช่วงที่ไม่มีการดำเนินงานระหว่างงาน และนำไปปรับปรุงได้ตรงจุด. เหตุผลที่สำคัญ ใช้คำนวณระยะเวลาของแต่ละกิจกรรมได้อย่างแม่นยำ และช่วยแยกเวลาประมวลผลที่สร้างคุณค่าออกจากเวลารอที่ไม่สร้างคุณค่า. แหล่งข้อมูล มักพบในบันทึกกิจกรรมหรือตารางบันทึกการตรวจสอบ หากไม่มีข้อมูลนี้ บางครั้งอาจคำนวณจากเวลาเริ่มต้นของเหตุการณ์ถัดไปได้. ตัวอย่าง 2023-10-26T09:15:30Z2023-10-26T17:00:00Z2023-10-27T11:55:12Z | |||
| สถานะการเปลี่ยนแปลง ChangeStatus | สถานะปัจจุบันหรือสถานะสุดท้ายของคำขอเปลี่ยนแปลงในวงจรการดำเนินงาน เช่น 'กำลังดำเนินการ' 'รออนุมัติ' หรือ 'ปิดแล้ว'. | ||
| คำอธิบาย สถานะการเปลี่ยนแปลงแสดงขั้นตอนของคำขอ ณ เวลาหนึ่งหรือผลลัพธ์สุดท้าย โดยทั่วไปสถานะจะสอดคล้องกับหมุดหมายสำคัญของกระบวนการและช่วยให้เห็นความคืบหน้าโดยรวม แอตทริบิวต์นี้ใช้ได้สองแบบ หากใช้เป็นข้อมูลสถานะ ณ เวลาหนึ่ง จะแสดงสถานะปัจจุบันของการเปลี่ยนแปลงที่ยังเปิดอยู่ทั้งหมด ซึ่งมีประโยชน์กับแดชบอร์ดการปฏิบัติการที่ติดตามปริมาณงานและงานค้าง หากใช้เป็นข้อมูลเหตุการณ์ การเปลี่ยนสถานะแต่ละครั้งก็นับเป็นกิจกรรมได้ จึงช่วยเพิ่มรายละเอียดให้บันทึกเหตุการณ์เมื่อมีข้อมูลกิจกรรมไม่มาก การวิเคราะห์การเปลี่ยนสถานะช่วยให้เข้าใจวงจรการดำเนินงานและค้นหาจุดที่งานติดขัด. เหตุผลที่สำคัญ แสดงภาพรวมความคืบหน้าของการเปลี่ยนแปลง ช่วยวิเคราะห์คอขวด ปริมาณงานที่ดำเนินการ และสถานะปัจจุบันของงานเปลี่ยนแปลงที่ค้างอยู่. แหล่งข้อมูล อยู่ในระเบียนส่วนหัวของคำขอเปลี่ยนแปลง ส่วนประวัติการเปลี่ยนสถานะอาจอยู่ในบันทึกการตรวจสอบ. ตัวอย่าง ใหม่ประเมินอนุมัติปิดแล้วปฏิเสธแล้ว | |||
| ความเร่งด่วน ChangeUrgency | ความเร่งด่วนของการเปลี่ยนแปลง ซึ่งสะท้อนว่าธุรกิจต้องการให้ดำเนินการเร็วเพียงใด. | ||
| คำอธิบาย ความเร่งด่วนของการเปลี่ยนแปลงแสดงว่าต้องนำไปใช้เร็วเพียงใดจึงจะตอบโจทย์ธุรกิจ โดยพิจารณาความจำเป็นด้านเวลาแยกจากผลกระทบที่อาจเกิดขึ้น การเปลี่ยนแปลงอาจมีผลกระทบต่ำแต่เร่งด่วนสูง เช่น การแก้ปัญหาเล็กน้อยก่อนเริ่มแคมเปญการตลาด ความเร่งด่วนเป็นองค์ประกอบสำคัญในการคำนวณลำดับความสำคัญ และใช้วิเคราะห์ว่ากระบวนการจัดการการเปลี่ยนแปลงดำเนินการได้ทันเวลาหรือไม่ นักวิเคราะห์ตรวจสอบได้ว่าการเปลี่ยนแปลงที่เร่งด่วนได้รับการดำเนินการเร็วขึ้นจริงหรือไม่ การเปรียบเทียบรอบเวลาตามระดับความเร่งด่วนช่วยให้เห็นว่ากระบวนการตอบสนองต่อความต้องการทางธุรกิจได้ดีเพียงใด หรือดำเนินการเปลี่ยนแปลงทุกประเภทด้วยความเร็วเท่ากันโดยไม่คำนึงถึงข้อจำกัดด้านเวลา. เหตุผลที่สำคัญ ช่วยวิเคราะห์ว่ากระบวนการตอบสนองต่อความต้องการทางธุรกิจที่มีข้อจำกัดด้านเวลาได้ดีเพียงใด โดยเปรียบเทียบรอบเวลาตามระดับความเร่งด่วน. แหล่งข้อมูล อยู่ในระเบียนหลักหรือข้อมูลส่วนหัวของคำขอเปลี่ยนแปลง. ตัวอย่าง 1-วิกฤต2-สูง3-ปานกลาง4-ต่ำ | |||
| ผลกระทบ ChangeImpact | ผลกระทบที่ประเมินไว้ของการเปลี่ยนแปลงต่อบริการทางธุรกิจและโครงสร้างพื้นฐานด้าน IT หากการเปลี่ยนแปลงสำเร็จหรือล้มเหลว. | ||
| คำอธิบาย ผลกระทบจากการเปลี่ยนแปลงใช้วัดผลที่อาจเกิดขึ้นกับการปฏิบัติการ บริการ หรือโครงสร้างพื้นฐานของธุรกิจ โดยเป็นข้อมูลสำคัญร่วมกับความเร่งด่วนในการกำหนดลำดับความสำคัญโดยรวม ตัวอย่างเช่น การเปลี่ยนแปลงที่กระทบบริการสำคัญซึ่งลูกค้าใช้งานโดยตรงถือว่ามีผลกระทบสูง การวิเคราะห์ตามระดับผลกระทบช่วยให้มั่นใจว่าการเปลี่ยนแปลงที่กระทบบริการสำคัญได้รับการจัดการอย่างรอบคอบ ใช้ตรวจสอบความสอดคล้องได้ว่าการเปลี่ยนแปลงที่มีผลกระทบสูงผ่านขั้นตอนอนุมัติหรือทดสอบที่กำหนดไว้เสมอหรือไม่ และยังใช้เปรียบเทียบประสิทธิภาพได้ เช่น ตรวจสอบว่าการเปลี่ยนแปลงที่มีผลกระทบสูงใช้เวลานานกว่าเพราะต้องตรวจสอบและทดสอบเพิ่มเติมหรือไม่. เหตุผลที่สำคัญ ช่วยตรวจสอบว่าการเปลี่ยนแปลงที่มีผลกระทบต่อธุรกิจสูงผ่านขั้นตอนตรวจสอบและทดสอบที่เข้มงวดกว่า เพื่อให้มีการกำกับดูแลอย่างเหมาะสม. แหล่งข้อมูล อยู่ในระเบียนหลักหรือข้อมูลส่วนหัวของคำขอเปลี่ยนแปลง. ตัวอย่าง 1-กว้างขวาง/ทั่วถึง2-มีนัยสำคัญ/ขนาดใหญ่3-ปานกลาง/จำกัด4-เล็กน้อย/เฉพาะจุด | |||
| วันที่กำหนดเสร็จ PlannedCompletionDate | วันที่กำหนดหรือวันที่เป้าหมายที่ควรดำเนินการเปลี่ยนแปลงให้เสร็จสิ้น. | ||
| คำอธิบาย วันที่กำหนดเสร็จคือกำหนดเวลาของการเปลี่ยนแปลง ซึ่งมักอิงตามความต้องการทางธุรกิจหรือข้อตกลงระดับการให้บริการ (SLA) ใช้เป็นเกณฑ์วัดความตรงต่อเวลาและประสิทธิภาพของกระบวนการจัดการการเปลี่ยนแปลง แอตทริบิวต์นี้จำเป็นต่อการวิเคราะห์ผลการดำเนินงานตาม SLA เมื่อนำวันที่เสร็จจริงมาเปรียบเทียบกับวันที่กำหนด องค์กรจะคำนวณอัตราการดำเนินงานเสร็จตรงเวลา ซึ่งเป็นตัวชี้วัดประสิทธิภาพสำคัญได้ การวิเคราะห์รายการที่เสร็จไม่ทันกำหนดช่วยค้นหาสาเหตุของความล่าช้า ไม่ว่าจะเกิดจากคอขวดด้านการอนุมัติ ข้อจำกัดด้านทรัพยากร หรือการวางแผนที่ไม่สอดคล้องกับความเป็นจริง. เหตุผลที่สำคัญ เป็นแอตทริบิวต์สำคัญสำหรับวัดการปฏิบัติตาม SLA และการส่งมอบตรงเวลา รวมถึงค้นหาสาเหตุของความล่าช้าในกระบวนการ. แหล่งข้อมูล โดยทั่วไปอยู่ในข้อมูลส่วนหัวของคำขอเปลี่ยนแปลง. ตัวอย่าง 2023-11-15T17:00:00Z2023-11-20T23:59:59Z2023-12-01T12:00:00Z | |||
| เหตุผลของผลลัพธ์ ChangeOutcomeReason | รหัสหรือคำอธิบายผลลัพธ์สุดท้ายของการเปลี่ยนแปลงที่ปิดแล้ว เช่น เหตุผลที่ปฏิเสธหรือยกเลิก. | ||
| คำอธิบาย เหตุผลของผลลัพธ์การเปลี่ยนแปลงให้บริบทว่าทำไมคำขอจึงสิ้นสุดลงในลักษณะนั้น หากดำเนินการสำเร็จ อาจระบุว่า 'สำเร็จ' หากล้มเหลว อาจระบุว่า 'ไม่สำเร็จ เริ่มย้อนกลับการเปลี่ยนแปลงแล้ว' ส่วนคำขอที่ถูกปฏิเสธหรือยกเลิกจะระบุเหตุผล เช่น 'ข้อมูลสนับสนุนไม่เพียงพอ' หรือ 'ผู้ขอยกเลิก' แอตทริบิวต์นี้สำคัญต่อการวิเคราะห์หาสาเหตุรากของการเปลี่ยนแปลงที่ล้มเหลวหรือถูกปฏิเสธ เมื่อจัดหมวดหมู่และวิเคราะห์เหตุผลเหล่านี้ องค์กรจะค้นหารูปแบบความล้มเหลวที่เกิดซ้ำได้ เช่น หากคำขอจำนวนมากถูกปฏิเสธเพราะ 'ข้อมูลไม่ครบถ้วน' แสดงว่าควรปรับปรุงขั้นตอนการส่งคำขอ ข้อมูลนี้ยังช่วยคำนวณและทำความเข้าใจ KPI เช่น อัตราความล้มเหลวของการเปลี่ยนแปลงและอัตราการอนุมัติในครั้งแรก. เหตุผลที่สำคัญ ให้ข้อมูลสำคัญสำหรับวิเคราะห์หาสาเหตุรากของการเปลี่ยนแปลงที่ล้มเหลว ถูกปฏิเสธ หรือยกเลิก และช่วยปรับปรุงคุณภาพของคำขอเปลี่ยนแปลงในอนาคต. แหล่งข้อมูล อยู่ในรายละเอียดการปิดคำขอเปลี่ยนแปลง โดยอาจใช้ชื่อ 'รหัสปิดงาน' 'การแก้ไข' หรือ 'เหตุผลที่ปฏิเสธ'. ตัวอย่าง สำเร็จไม่สำเร็จปฏิเสธ เนื่องจากข้อมูลสนับสนุนไม่เพียงพอผู้ใช้ยกเลิกสำเร็จแต่พบปัญหา | |||
| เหตุผลในการเปลี่ยนแปลง ChangeReason | เหตุผลหรือความจำเป็นทางธุรกิจที่เสนอให้เปลี่ยนแปลง ซึ่งอธิบายว่าทำไมจึงต้องดำเนินการ. | ||
| คำอธิบาย เหตุผลในการเปลี่ยนแปลงเป็นคำอธิบายที่ระบุปัจจัยทางธุรกิจเบื้องหลังคำขอ โดยตอบคำถามว่า 'ทำไมจึงต้องดำเนินการ' พร้อมให้บริบท เช่น 'ติดตั้งแพตช์ความปลอดภัยเพื่อแก้ช่องโหว่ร้ายแรง' หรือ 'เพิ่มฟีเจอร์เพื่อปรับปรุงประสบการณ์ลูกค้า' แม้มักเป็นช่องข้อความอิสระ แต่เมื่อนำมาจัดหมวดหมู่หรือวิเคราะห์ด้วยเทคนิค text mining ก็ให้ข้อมูลเชิงคุณภาพที่เป็นประโยชน์ได้ ช่วยให้เข้าใจความต้องการเปลี่ยนแปลงจากส่วนต่างๆ ของธุรกิจ เช่น การวิเคราะห์อาจพบว่าคำขอจำนวนมากเกิดจากการแก้ข้อบกพร่อง ซึ่งอาจบ่งชี้ถึงปัญหาคุณภาพซอฟต์แวร์ หรือในบางช่วงอาจพบคำขอจำนวนมากที่เกี่ยวข้องกับโครงการเชิงกลยุทธ์. เหตุผลที่สำคัญ ให้บริบททางธุรกิจว่าทำไมจึงเริ่มดำเนินการเปลี่ยนแปลง และช่วยวิเคราะห์ปัจจัยหลักที่ขับเคลื่อนการเปลี่ยนแปลงในองค์กร. แหล่งข้อมูล โดยทั่วไปอยู่ในแบบฟอร์มส่งคำขอเริ่มต้นหรือรายละเอียดส่วนหัวของคำขอเปลี่ยนแปลง. ตัวอย่าง ติดตั้งแพตช์ความปลอดภัยเร่งด่วนปรับปรุงอุปกรณ์ตามวงจรอายุการใช้งานนำฟีเจอร์ใหม่ไปใช้ในไตรมาส 4แก้ไขเหตุขัดข้องในระบบจริง INC012345 | |||
กิจกรรมในการจัดการการเปลี่ยนแปลง
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
| คำขอเปลี่ยนแปลงรออนุมัติ | หมายถึงคำขอเปลี่ยนแปลงผ่านการตรวจสอบเบื้องต้นแล้ว และกำลังรอการตัดสินใจอย่างเป็นทางการจากผู้อนุมัติหรือคณะกรรมการ โดยทั่วไปบันทึกจากการเปลี่ยนสถานะใน workflow เช่น เป็น 'Pending Approval'. | ||
| เหตุผลที่สำคัญ สถานะนี้สำคัญต่อการวัดรอบเวลาการอนุมัติและระบุคอขวดในกระบวนการตัดสินใจ หากใช้เวลานาน มักบ่งชี้ว่า workflow การอนุมัติไม่มีประสิทธิภาพหรือผู้อนุมัติไม่พร้อม. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในประวัติระเบียนการเปลี่ยนแปลงเป็นสถานะ เช่น 'Awaiting Approval', 'Pending CAB' หรือ 'Authorize'. บันทึก ระบุการเปลี่ยนสถานะที่แสดงว่าเริ่มช่วงรอการอนุมัติอย่างเป็นทางการ. ประเภทเหตุการณ์ inferred | |||
| จัดตารางการเปลี่ยนแปลงแล้ว | กิจกรรมนี้บันทึกจุดที่กำหนดช่วงเวลานำการเปลี่ยนแปลงที่อนุมัติแล้วไปใช้ไว้อย่างเป็นทางการ โดยทั่วไปบันทึกเมื่อกรอกวันที่เริ่มต้นและสิ้นสุดตามแผน. | ||
| เหตุผลที่สำคัญ จุดสำคัญนี้แบ่งช่วงการวางแผนออกจากช่วงดำเนินการ การวิเคราะห์เวลาระหว่างการอนุมัติกับการจัดตารางอาจช่วยให้พบงานค้างหรือปัญหาการจัดสรรทรัพยากร. แหล่งข้อมูล อนุมานจากการกรอกหรืออัปเดตฟิลด์ 'Planned Start Date' และ 'Planned End Date' หรือการเปลี่ยนสถานะเป็น 'Scheduled'. บันทึก ใช้เวลาที่สถานะของระเบียนการเปลี่ยนแปลงเป็น 'Scheduled' หรือเวลาที่กำหนดวันที่ตามแผน. ประเภทเหตุการณ์ inferred | |||
| นำการเปลี่ยนแปลงไปใช้แล้ว | จุดสำคัญที่แสดงว่างานที่เกี่ยวข้องกับการเปลี่ยนแปลงเสร็จสิ้นแล้ว โดยทั่วไปบันทึกจากการเปลี่ยนสถานะเป็น 'Implemented' หรือ 'Pending Verification'. | ||
| เหตุผลที่สำคัญ จุดสำคัญนี้เป็นจุดสิ้นสุดของขั้นตอนการนำไปใช้ และจำเป็นต่อการวัดระยะเวลาที่ใช้จริง นอกจากนี้ยังเป็นจุดเริ่มต้นของกิจกรรมหลังนำไปใช้ เช่น การทดสอบและการทบทวน. แหล่งข้อมูล บันทึกจากการเปลี่ยนสถานะในประวัติระเบียนการเปลี่ยนแปลงเป็นสถานะที่แสดงว่าการนำไปใช้เสร็จสิ้น. บันทึก ใช้เวลาที่สถานะของระเบียนการเปลี่ยนแปลงเปลี่ยนเป็น 'Implemented' หรือ 'Completed'. ประเภทเหตุการณ์ inferred | |||
| ปฏิเสธคำขอเปลี่ยนแปลง | หมายถึงผู้อนุมัติปฏิเสธคำขอเปลี่ยนแปลงอย่างเป็นทางการ ทำให้กระบวนการหยุดลง สถานะนี้อาจเป็นสถานะสิ้นสุดของคำขอ หรือทำให้เกิดรอบการแก้ไขงาน. | ||
| เหตุผลที่สำคัญ การติดตามคำขอที่ถูกปฏิเสธเป็นสิ่งสำคัญต่อการคำนวณอัตราความล้มเหลวของการเปลี่ยนแปลงและค้นหาเหตุผลที่พบบ่อย ช่วยให้เห็นปัญหาด้านคุณภาพ การวางแผน หรือเหตุผลประกอบคำขอ. แหล่งข้อมูล บันทึกจากการเปลี่ยนสถานะในประวัติระเบียนการเปลี่ยนแปลงเป็นสถานะ เช่น 'Rejected' หรือ 'Denied'. บันทึก ระบุเวลาที่สถานะของระเบียนการเปลี่ยนแปลงเปลี่ยนเป็น 'Rejected'. ประเภทเหตุการณ์ inferred | |||
| ปิดคำขอเปลี่ยนแปลง | บันทึกว่ากระบวนการจัดการการเปลี่ยนแปลงเสร็จสมบูรณ์อย่างเป็นทางการ เหตุการณ์นี้เกิดขึ้นเมื่อสถานะทิกเก็ตการเปลี่ยนแปลงเปลี่ยนเป็นสถานะสุดท้าย 'Closed' ซึ่งแสดงว่างานทั้งหมดเสร็จแล้ว. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นเหตุการณ์สิ้นสุดหลักเมื่อดำเนินการสำเร็จ และจำเป็นต่อการคำนวณเวลาตั้งแต่ต้นจนจบ แสดงว่าดำเนินการและยอมรับการเปลี่ยนแปลงเรียบร้อยแล้ว. แหล่งข้อมูล บันทึกจากการเปลี่ยนสถานะสุดท้ายของระเบียนการเปลี่ยนแปลงเป็นสถานะที่แก้ไขเสร็จแล้ว เช่น 'Closed' หรือ 'Done'. บันทึก ใช้เวลาที่สถานะเปลี่ยนเป็น 'Closed' ในขั้นตอนสุดท้าย. ประเภทเหตุการณ์ inferred | |||
| สร้างคำขอเปลี่ยนแปลง | กิจกรรมนี้บันทึกการสร้างรายการคำขอเปลี่ยนแปลงในระบบเป็นครั้งแรก ถือเป็นจุดเริ่มต้นอย่างเป็นทางการของกระบวนการจัดการการเปลี่ยนแปลง โดยทั่วไปจะใช้เวลาที่สร้างระเบียนการเปลี่ยนแปลง. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้เป็นเหตุการณ์เริ่มต้นหลักที่จำเป็นต่อการคำนวณเวลารอบการเปลี่ยนแปลงตั้งแต่ต้นจนจบ และใช้เป็นจุดเริ่มต้นในการวัดระยะเวลาที่คำขออยู่ในระบบ. แหล่งข้อมูล โดยทั่วไป เหตุการณ์นี้บันทึกจากเวลาที่สร้างระเบียนคำขอเปลี่ยนแปลงหลักหรือทิกเก็ต. บันทึก ใช้เวลาที่สร้างระเบียนคำขอเปลี่ยนแปลง. ประเภทเหตุการณ์ explicit | |||
| อนุมัติการเปลี่ยนแปลงแล้ว | จุดสำคัญที่แสดงว่าผู้เกี่ยวข้องทุกฝ่ายอนุมัติการเปลี่ยนแปลงให้นำไปใช้แล้ว เหตุการณ์นี้บันทึกเมื่อได้รับอนุมัติครบทุกฝ่ายที่จำเป็น ซึ่งมักทำให้สถานะเปลี่ยนไป. | ||
| เหตุผลที่สำคัญ จุดสำคัญนี้ใช้วัดประสิทธิภาพการอนุมัติและอัตราการอนุมัติผ่านในครั้งแรก อีกทั้งยังแบ่งช่วงการวางแผนและประเมินผลออกจากช่วงจัดตารางและนำไปใช้. แหล่งข้อมูล โดยทั่วไปอนุมานจากการเปลี่ยนสถานะเป็น 'Approved' หรือสถานะที่มีความหมายใกล้เคียง หรือบันทึกจากเวลาของรายการอนุมัติขั้นสุดท้าย. บันทึก บันทึกเวลาที่สถานะอนุมัติโดยรวมของการเปลี่ยนแปลงเปลี่ยนเป็น 'Approved'. ประเภทเหตุการณ์ inferred | |||
| จัดทำแผนการนำไปใช้เสร็จสิ้น | หมายถึงการวางแผนที่จำเป็นสำหรับการเปลี่ยนแปลงเสร็จสิ้นแล้ว รวมถึงแผนการนำไปใช้ การทดสอบ และการย้อนกลับ โดยทั่วไปอนุมานจากการเปลี่ยนสถานะหลังอนุมัติหรือการทำงานวางแผนเสร็จสิ้น. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ใช้วัดระยะเวลาของขั้นตอนการวางแผนโดยละเอียด ความล่าช้าในช่วงนี้อาจกระทบต่อการจัดตารางและดำเนินการเปลี่ยนแปลงให้ทันเวลา. แหล่งข้อมูล โดยทั่วไปอนุมานจากการทำงานเฉพาะด้านการวางแผนเสร็จสิ้น หรือการอัปเดตสถานะที่แสดงว่าการวางแผนเสร็จแล้ว. บันทึก ตรวจสอบการปิดงานวางแผนหรือการเปลี่ยนสถานะจาก 'Approved' เป็น 'Scheduled'. ประเภทเหตุการณ์ inferred | |||
| ทดสอบหลังนำไปใช้เสร็จสิ้น | หมายถึงการทดสอบและตรวจสอบความถูกต้องที่จำเป็นทั้งหมดเสร็จสิ้น เพื่อยืนยันว่าการเปลี่ยนแปลงสำเร็จ อาจมีสถานะแยกต่างหาก หรืออนุมานจากการปิดงานทดสอบ. | ||
| เหตุผลที่สำคัญ การติดตามการทดสอบที่เสร็จสิ้นช่วยวัดระยะเวลาและประสิทธิผลของขั้นตอนการตรวจสอบ ซึ่งเป็นขั้นตอนสำคัญก่อนปิดการเปลี่ยนแปลงอย่างเป็นทางการ. แหล่งข้อมูล โดยทั่วไปอนุมานจากการทำงานทดสอบที่เกี่ยวข้องเสร็จสิ้น หรือการเปลี่ยนสถานะเป็น 'Verification Complete' หรือ 'Testing Done'. บันทึก ตรวจสอบการปิดงานตรวจสอบความถูกต้องหรือการอัปเดตสถานะเฉพาะหลังนำไปใช้. ประเภทเหตุการณ์ inferred | |||
| ทบทวนหลังนำไปใช้เสร็จสิ้น | หมายถึงการทบทวนอย่างเป็นทางการเพื่อประเมินความสำเร็จของการเปลี่ยนแปลงและบันทึกบทเรียนที่ได้รับเสร็จสิ้น โดยทั่วไปบันทึกจากการเปลี่ยนสถานะหรือการปิดงานทบทวน. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้สำคัญต่อการปรับปรุงกระบวนการอย่างต่อเนื่อง การวิเคราะห์เวลาที่ใช้ทำ PIR ให้เสร็จช่วยให้เห็นว่าองค์กรให้ความสำคัญกับการเรียนรู้จากการเปลี่ยนแปลงที่ผ่านมาเพียงใด. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะเป็น 'Review' การทำงาน PIR เสร็จสิ้น หรือการเพิ่มบันทึกการทบทวนหลังนำไปใช้. บันทึก ระบุเวลาที่ปิดงาน Post-Implementation Review หรือเวลาที่สถานะเปลี่ยนออกจาก 'Review'. ประเภทเหตุการณ์ inferred | |||
| ประเมินความเสี่ยงเสร็จสิ้น | กิจกรรมนี้หมายถึงการวิเคราะห์ความเสี่ยงและผลกระทบของการเปลี่ยนแปลงที่เสนอเสร็จสิ้น โดยทั่วไปอนุมานจากการกรอกฟิลด์ที่เกี่ยวข้องกับความเสี่ยง หรือการทำเครื่องหมายว่างานประเมินเฉพาะเสร็จแล้ว. | ||
| เหตุผลที่สำคัญ การวิเคราะห์เวลาที่ใช้ประเมินความเสี่ยงช่วยระบุคอขวดในช่วงต้นของกระบวนการเปลี่ยนแปลง และช่วยให้เข้าใจว่าต้องใช้เวลานานเท่าใดกว่าจะเตรียมการเปลี่ยนแปลงเพื่อขออนุมัติอย่างเป็นทางการ. แหล่งข้อมูล อนุมานจากการอัปเดตสถานะ การทำงานประเมินที่เกี่ยวข้องเสร็จสิ้น หรือการอัปเดตฟิลด์ความเสี่ยงและผลกระทบในระเบียนการเปลี่ยนแปลง. บันทึก ตรวจสอบว่างานประเมินความเสี่ยงเสร็จสิ้น หรือมีการเปลี่ยนสถานะที่แสดงว่าจบขั้นตอนการประเมินแล้ว. ประเภทเหตุการณ์ inferred | |||
| ยกเลิกคำขอเปลี่ยนแปลง | หมายถึงการยุติคำขอเปลี่ยนแปลงก่อนนำไปใช้หรือดำเนินการเสร็จสิ้น เป็นสถานะสิ้นสุดอีกแบบหนึ่ง ซึ่งบันทึกเมื่อสถานะทิกเก็ตเปลี่ยนเป็น 'Canceled' หรือ 'Withdrawn'. | ||
| เหตุผลที่สำคัญ เหตุการณ์นี้เป็นสถานะสิ้นสุดที่แสดงถึงความพยายามที่สูญเปล่า การวิเคราะห์ความถี่และช่วงเวลาที่มีการยกเลิกช่วยให้พบความไม่มีประสิทธิภาพในกระบวนการหรือการเปลี่ยนแปลงลำดับความสำคัญทางธุรกิจ. แหล่งข้อมูล บันทึกจากการเปลี่ยนสถานะของระเบียนการเปลี่ยนแปลงเป็นสถานะสิ้นสุด เช่น 'Canceled' หรือ 'Withdrawn'. บันทึก ใช้เวลาที่สถานะเปลี่ยนเป็น 'Canceled'. ประเภทเหตุการณ์ inferred | |||
| เริ่มนำการเปลี่ยนแปลงไปใช้ | บันทึกการเริ่มดำเนินการเปลี่ยนแปลงที่อนุมัติในทางเทคนิค โดยทั่วไปบันทึกจากการเปลี่ยนสถานะจาก 'Scheduled' เป็น 'In Progress' หรือ 'Implementing'. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ช่วยให้เห็นจุดเริ่มต้นของช่วงเวลาที่ดำเนินการเปลี่ยนแปลงจริง การเปรียบเทียบเวลาเริ่มต้นตามแผนกับเวลาจริงเป็นสิ่งสำคัญในการวิเคราะห์ว่าทำตามกำหนดการได้หรือไม่. แหล่งข้อมูล อนุมานจากการเปลี่ยนสถานะในประวัติระเบียนการเปลี่ยนแปลงเป็นสถานะที่กำลังดำเนินการ เช่น 'In Progress' หรือ 'Implementing'. บันทึก ระบุเวลาที่สถานะเปลี่ยนเป็น 'In Progress'. ประเภทเหตุการณ์ inferred | |||
| ส่งคำขอเปลี่ยนแปลงเพื่อตรวจสอบ | หมายถึงการส่งคำขอเปลี่ยนแปลงที่สร้างขึ้นใหม่อย่างเป็นทางการ เพื่อให้ประเมินหรือพิจารณาเบื้องต้น โดยทั่วไปอนุมานจากสถานะที่เปลี่ยนจาก 'Draft' หรือ 'New' เป็นสถานะที่แสดงว่าพร้อมตรวจสอบแล้ว. | ||
| เหตุผลที่สำคัญ กิจกรรมนี้ช่วยระบุเวลาที่ใช้รวบรวมข้อมูลเบื้องต้นก่อนเริ่มการประเมินอย่างเป็นทางการ และอาจแสดงความล่าช้าในการเตรียมการเปลี่ยนแปลงก่อนเข้าสู่การตรวจสอบครั้งแรก. แหล่งข้อมูล โดยทั่วไปอนุมานจากการเปลี่ยนสถานะในประวัติคำขอเปลี่ยนแปลง เช่น จาก 'New' เป็น 'Assessing' หรือ 'In Review'. บันทึก ระบุการเปลี่ยนสถานะจากฉบับร่างหรือสถานะใหม่ไปเป็นสถานะรอตรวจสอบ. ประเภทเหตุการณ์ inferred | |||
คู่มือการดึงข้อมูล
วิธีดึงข้อมูลแตกต่างกันไปตามระบบ หากต้องการคำแนะนำโดยละเอียด
พร้อมเริ่มต้นหรือยัง?
เริ่มปรับปรุงกระบวนการจัดการการเปลี่ยนแปลงของคุณได้วันนี้ เลือกคู่มือการดึงข้อมูลสำหรับระบบที่ใช้เพื่อดูคำแนะนำเฉพาะ หรือใช้เทมเพลตทั่วไปนี้เป็นแนวทางเริ่มต้น.
ปรับปรุงการจัดการการเปลี่ยนแปลงให้มีประสิทธิภาพสูงสุด
ปรับขั้นตอนการทำงานให้คล่องตัว ลดความเสี่ยง และช่วยให้การนำไปใช้เร็วขึ้น.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จภายในไม่กี่นาที.