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

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

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

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

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

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

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

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

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: number

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

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

ใน process mining แอตทริบิวต์นี้ใช้คำนวณระยะเวลารอบ เวลาประมวลผล และเวลารอระหว่างกิจกรรม จำเป็นต่อแดชบอร์ดที่ใช้วิเคราะห์ผลการดำเนินงาน เช่น Change Approval Cycle Time และ End-to-End Change Process Flow เวลาประทับที่ถูกต้องเป็นพื้นฐานในการค้นหาความล่าช้าและวัดประสิทธิภาพกระบวนการเทียบกับ SLA.

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

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

แหล่งข้อมูล

ตาราง ServiceNow: sys_audit, ฟิลด์: sys_created_on ซึ่งระบุเวลาประทับของการเปลี่ยนแปลงแต่ละรายการที่บันทึกไว้.

ตัวอย่าง
2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:05:00Z
ชื่อกิจกรรม
ActivityName
ชื่อเหตุการณ์หรืองานที่เกิดขึ้นในกระบวนการจัดการการเปลี่ยนแปลง.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ได้จากการเปลี่ยนแปลงฟิลด์ 'state' หรือฟิลด์สถานะสำคัญอื่นๆ ในตาราง 'change_request' ซึ่งมักบันทึกไว้ในตาราง 'sys_audit'.

ตัวอย่าง
อนุมัติ Change Request แล้วเริ่มนำไปใช้ปิด Change Request แล้วยกเลิก Change Request
กลุ่มผู้รับผิดชอบ
AssignmentGroup
ทีมที่รับผิดชอบ Change Request.
คำอธิบาย

กลุ่มผู้รับผิดชอบระบุว่าทีมใดดูแล Change Request อยู่ เช่น 'CAB Approval', 'Network Engineering' หรือ 'Database Administrators' มิตินี้สำคัญต่อการวิเคราะห์ผลการดำเนินงานของกระบวนการในแต่ละฝ่าย

ใช้แอตทริบิวต์นี้วัดประสิทธิภาพระดับทีม ค้นหาคอขวดในกลุ่มต่างๆ และวิเคราะห์ประสิทธิภาพการส่งต่องานระหว่างทีม แดชบอร์ดอย่าง 'Cross-Functional Handoff Efficiency' และ 'Change Implementation Throughput' ใช้ข้อมูลนี้เพื่อระบุความล่าช้าที่เกิดจากการพึ่งพางานระหว่างทีม.

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

ช่วยวิเคราะห์ผลการดำเนินงานแยกตามทีม แสดงคอขวดของแต่ละกลุ่ม และวัดประสิทธิภาพการส่งต่องานระหว่างฝ่ายต่างๆ.

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: assignment_group

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

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

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

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: type

ตัวอย่าง
StandardNormalEmergency
ระดับความเสี่ยง
RiskLevel
ระดับความเสี่ยงที่ประเมินได้ของการเปลี่ยนแปลง เช่น 'High', 'Moderate' หรือ 'Low'.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: risk

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

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

แอตทริบิวต์นี้ให้บริบทสำคัญสำหรับการเปลี่ยนแปลง ใน process mining สามารถแบ่งการวิเคราะห์ตามประเภทสินทรัพย์ที่เปลี่ยนแปลงได้ ตัวอย่างเช่น แดชบอร์ด 'Change Testing Duration Analysis' ใช้แอตทริบิวต์นี้เปรียบเทียบเวลาทดสอบของแอปพลิเคชันหรือระบบต่างๆ เพื่อช่วยค้นหาว่า CI ใดเกี่ยวข้องกับรอบการทดสอบที่ยาวนานกว่า.

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: cmdb_ci

ตัวอย่าง
SAP ERPOracle Database 19cบริการอีเมลWebServer-01
ลำดับความสำคัญ
Priority
ระดับความสำคัญของ Change Request ซึ่งพิจารณาจากผลกระทบและความเร่งด่วน.
คำอธิบาย

ลำดับความสำคัญแสดงความสำคัญของ Change Request และกำหนดลำดับที่ควรดำเนินการ โดยมักพิจารณาจากผลกระทบและความเร่งด่วนของการเปลี่ยนแปลง เช่น 'Critical', 'High', 'Moderate' และ 'Low'

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

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: priority

ตัวอย่าง
1 - วิกฤต2 - สูง3 - ปานกลาง4 - ต่ำ
เวลาสิ้นสุด
EndTime
เวลาที่กิจกรรมสิ้นสุด โดยมักอนุมานจากเวลาเริ่มต้นของกิจกรรมถัดไป.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
2023-10-26T10:05:12Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
สถานะการเปลี่ยนแปลง
ChangeState
สถานะปัจจุบันหรือสถานะในอดีตของ Change Request เช่น 'Assess', 'Authorize', 'Implement' หรือ 'Closed'.
คำอธิบาย

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

ในการวิเคราะห์ ใช้สถานะการเปลี่ยนแปลงเพื่อจัดหมวดหมู่ Case และทำความเข้าใจผลลัพธ์ นอกจากนี้ยังใช้กรองรายการ เช่น วิเคราะห์เฉพาะการเปลี่ยนแปลงที่ 'Closed' หรือค้นหาสาเหตุที่หลายรายการค้างอยู่ในสถานะ 'Authorize' ได้โดยตรง และยังรองรับ KPI เช่น Change Failure Rate เมื่อมีสถานะ 'Failed'.

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

แสดงสถานะของ Change Request ณ จุดหนึ่ง ช่วยวิเคราะห์ผลลัพธ์ กรอง Case และค้นหารายการที่หยุดค้าง.

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: state

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

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

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

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: urgency

ตัวอย่าง
1 - สูง2 - ปานกลาง3 - ต่ำ
เป็นการทำงานซ้ำ
IsRework
ค่าบูลีนที่เป็น true เมื่อกิจกรรมเป็นการทำขั้นตอนเดิมซ้ำในเคสเดียวกัน.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

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

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

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

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: impact

ตัวอย่าง
1 - สูง2 - ปานกลาง3 - ต่ำ
ผู้ใช้ที่ได้รับมอบหมาย
AssignedToUser
ผู้ใช้ที่รับผิดชอบ Change Request ณ เวลาใดเวลาหนึ่ง.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: assigned_to

ตัวอย่าง
Beth AnglinDavid LooAbel Tuter
รหัสการปิดคำขอ
CloseCode
รหัสที่ระบุผลลัพธ์เมื่อปิดคำขอเปลี่ยนแปลง เช่น 'สำเร็จ' หรือ 'ไม่สำเร็จ'.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

ตาราง ServiceNow: change_request, ฟิลด์: close_code

ตัวอย่าง
สำเร็จสำเร็จแต่มีปัญหาไม่สำเร็จ / ย้อนกลับ
ระบบต้นทาง
SourceSystem
ระบบที่ดึงข้อมูลมา โดยทั่วไปคือ 'ServiceNow'.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

ตัวอย่าง
ServiceNowServiceNow_PRODSNOW_ITSM
ระยะเวลาดำเนินการ
CycleTime
เวลารวมตั้งแต่สร้างคำขอเปลี่ยนแปลงจนถึงปิดคำขอ.
คำอธิบาย

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

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

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

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

แหล่งข้อมูล

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

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

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

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

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

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

แหล่งข้อมูล

ดึงข้อมูลได้จากตาราง 'task_sla' ใน ServiceNow ซึ่งติดตาม SLA ของงานต่างๆ เช่น คำขอเปลี่ยนแปลง หรือคำนวณจากฟิลด์วันครบกำหนด.

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

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

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

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

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

แหล่งข้อมูล

ฟิลด์เมทาดาทานี้สร้างขึ้นระหว่างขั้นตอนการดึงและแปลงข้อมูล (ETL) เพื่อระบุเวลาที่ดึงข้อมูล.

ตัวอย่าง
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
จำเป็น แนะนำ ไม่บังคับ

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

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนฟิลด์ 'state' ในตาราง change_request เป็น 'Scheduled' เวลาประทับมาจากรายการบันทึกการตรวจสอบที่เกี่ยวข้อง.

บันทึก

ติดตามการเปลี่ยนแปลงฟิลด์ state เป็น 'Scheduled' ในประวัติการตรวจสอบของตาราง change_request.

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนสถานะออกจาก 'Implement' ไปยังสถานะถัดไป เช่น 'Review' เวลาประทับบันทึกจากประวัติการตรวจสอบฟิลด์ 'state' ในตาราง change_request.

บันทึก

ตรวจหาการเปลี่ยนฟิลด์ 'state' จาก 'Implement' เป็น 'Review'.

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

การติดตามระยะเวลาของขั้นประเมินเป็นหัวใจสำคัญของ KPI 'Avg. Risk Assessment Cycle Time' ช่วยกำหนดมาตรฐานการประเมินและค้นหาจุดที่ใช้เวลาวิเคราะห์นานเกินไป.

แหล่งข้อมูล

อนุมานจากการเปลี่ยนฟิลด์ 'state' ในตาราง change_request จาก 'Assess' เป็น 'Authorize' เวลาของเหตุการณ์บันทึกจากบันทึกการตรวจสอบการเปลี่ยนสถานะนี้.

บันทึก

ตรวจหาการเปลี่ยนฟิลด์ 'state' จาก 'Assess' ไปเป็นสถานะถัดไป เช่น 'Authorize'.

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

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

แหล่งข้อมูล

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

บันทึก

บันทึกเวลาประทับเมื่ออัปเดตฟิลด์ 'state' เป็น 'Closed'.

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

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

แหล่งข้อมูล

อนุมานจากการกำหนดฟิลด์ 'state' ในตาราง change_request เป็น 'Canceled' เวลาประทับมาจากบันทึกการตรวจสอบของการเปลี่ยนสถานะนี้.

บันทึก

บันทึกเวลาประทับเมื่ออัปเดตฟิลด์ 'state' เป็น 'Canceled'.

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

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

แหล่งข้อมูล

เหตุการณ์นี้ตรงกับเวลาที่สร้างรายการ (sys_created_on) ในตาราง change_request ของ ServiceNow.

บันทึก

ใช้เวลาประทับ sys_created_on จากตาราง change_request.

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนฟิลด์ 'approval' ในตาราง change_request เป็น 'approved' เวลาประทับมาจากประวัติการตรวจสอบของการเปลี่ยนแปลงนี้.

บันทึก

บันทึกเวลาประทับเมื่อฟิลด์ 'approval' เปลี่ยนเป็น 'approved'.

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนแปลงของฟิลด์ 'state' ในตาราง change_request โดยทั่วไปคือเปลี่ยนเป็นค่าอย่าง 'Assess' เวลาประทับมาจากประวัติการตรวจสอบ (sys_audit) ของการเปลี่ยนแปลงฟิลด์นี้.

บันทึก

ติดตามการเปลี่ยนแปลงฟิลด์ state เป็น 'Assess' ในประวัติการตรวจสอบของตาราง change_request.

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนฟิลด์ 'approval' ในตาราง change_request เป็น 'rejected' เวลาประทับบันทึกจากประวัติการตรวจสอบ.

บันทึก

บันทึกเวลาประทับเมื่อฟิลด์ 'approval' เปลี่ยนเป็น 'rejected'.

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

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

แหล่งข้อมูล

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

บันทึก

ตรวจจับการเปลี่ยนฟิลด์ 'state' ย้อนกลับโดยไม่เป็นไปตามลำดับในประวัติสถานะ.

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนฟิลด์ 'state' ในตาราง change_request เป็น 'Implement' เวลาประทับมาจากบันทึกการตรวจสอบของการเปลี่ยนสถานะนี้.

บันทึก

บันทึกเวลาประทับของการเปลี่ยนสถานะเป็น 'Implement' จากประวัติการตรวจสอบของ change_request.

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

นี่คือจุดเริ่มต้นของรอบการอนุมัติ การวัดเวลาตั้งแต่เหตุการณ์นี้จนถึง 'Change Approved' ช่วยคำนวณ KPI 'Average Change Approval Time' ได้โดยตรง.

แหล่งข้อมูล

อนุมานจากการเปลี่ยนฟิลด์ 'approval' ในตาราง change_request เป็น 'requested' เวลาประทับบันทึกไว้ในตาราง sys_audit สำหรับฟิลด์นี้.

บันทึก

เวลาประทับเมื่อกำหนดฟิลด์ 'approval' ในตาราง change_request เป็น 'requested'.

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

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

แหล่งข้อมูล

อนุมานจากการเปลี่ยนฟิลด์ 'state' ในตาราง change_request เป็น 'Review' เวลาประทับมาจากบันทึกการตรวจสอบของการเปลี่ยนสถานะนี้.

บันทึก

บันทึกเวลาประทับของการเปลี่ยนสถานะเป็น 'Review' จากประวัติการตรวจสอบของ change_request.

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

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

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

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

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

ลดการเปลี่ยนแปลงที่ล้มเหลว เพิ่มโอกาสสำเร็จในการใช้ ServiceNow ได้ตั้งแต่วันนี้!

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

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

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