เทมเพลตข้อมูลการจัดการปัญหา
เทมเพลตข้อมูลการจัดการปัญหา
- ฟิลด์ข้อมูลสำคัญสำหรับวิเคราะห์สาเหตุที่แท้จริง
- หมุดหมายมาตรฐานของกระบวนการสำหรับติดตาม
- คำแนะนำเฉพาะสำหรับดึงข้อมูลจาก BMC Helix ITSM
แอตทริบิวต์การจัดการปัญหา
| ชื่อ | คำอธิบาย | ||
|---|---|---|---|
|
Problem Record
ProblemRecord
|
ตัวระบุเฉพาะของกรณีตรวจสอบปัญหา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ใช้เป็นตัวระบุหลักของกรณีในกระบวนการจัดการปัญหา ใน BMC Helix ITSM โดยทั่วไปคือช่อง 'Problem ID' เช่น PBI00000012345 ในฟอร์ม PBM:Problem Investigation ซึ่งเชื่อมโยงกิจกรรมที่เกี่ยวข้องทั้งหมด ตั้งแต่บันทึกปัญหาครั้งแรกจนถึงการปิดกรณีและการทบทวนหลังนำไปใช้ ในการวิเคราะห์ process mining แอตทริบิวต์นี้ใช้จัดกลุ่มเหตุการณ์แต่ละรายการให้เป็นกระบวนการเดียวกัน นักวิเคราะห์จึงเห็นภาพการดำเนินงานตั้งแต่ต้นจนจบของการตรวจสอบปัญหาแต่ละกรณี หากไม่มีตัวระบุนี้ ก็จะเชื่อมโยงลำดับการทำงานของทีมสนับสนุนและผู้ประสานงานแต่ละคนไม่ได้ ช่องนี้ทำหน้าที่เป็นคีย์หลักของบันทึกเหตุการณ์ และจำเป็นต่อการรวมข้อมูลระดับกรณี เช่น การคำนวณระยะเวลาดำเนินการทั้งหมดของแต่ละปัญหา หรือการนับจำนวนปัญหาในแต่ละระดับความสำคัญ.
เหตุผลที่สำคัญ
เป็นคีย์พื้นฐานที่จำเป็นต่อการสร้างมุมมองกระบวนการและติดตามวงจรชีวิตของปัญหาแต่ละรายการ.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Problem ID'
ตัวอย่าง
PBI00000004512PBI00000004513PBI00000004514
|
|||
|
กิจกรรม
Activity
|
งานหรือเหตุการณ์เปลี่ยนสถานะที่เกิดขึ้น. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงขั้นตอนที่เกิดขึ้นในวงจรการจัดการปัญหา เช่น 'บันทึก Problem Record', 'ระบุสาเหตุที่แท้จริงแล้ว' หรือ 'อัปเดตฐานข้อมูลวิธีแก้ไข' ใน BMC Helix มักได้ข้อมูลจากประวัติสถานะ บันทึกการตรวจสอบ หรือเวลาที่บันทึกรายการในโมดูล Problem Investigation แอตทริบิวต์นี้เป็นหัวใจของการค้นพบกระบวนการ เครื่องมือ process mining จะวิเคราะห์ลำดับกิจกรรมเหล่านี้เพื่อสร้างแผนผังกระบวนการ และแสดงขั้นตอนการทำงานจริงเทียบกับกระบวนการที่ออกแบบไว้ ทั้งยังช่วยให้เห็นการวนซ้ำ การทำงานซ้ำ และขั้นตอนที่ต่างจากวิธีปฏิบัติงานมาตรฐาน ชื่อกิจกรรมที่ถูกต้องช่วยให้เข้าใจว่าเกิดอะไรขึ้นจริงในแต่ละช่วงของกระบวนการ ข้อมูลนี้ใช้วัดระยะเวลาระหว่างขั้นตอน เช่น เวลาตั้งแต่ระบุสาเหตุที่แท้จริงจนถึงเริ่มคำขอเปลี่ยนแปลง.
เหตุผลที่สำคัญ
กำหนดโหนดในแผนผังกระบวนการและช่วยแสดงภาพเวิร์กโฟลว์.
แหล่งข้อมูล
ได้จากประวัติสถานะ PBM:Problem Investigation หรือ PBM:AuditLogSystem
ตัวอย่าง
บันทึก Problem Recordมอบหมายให้ทีมสนับสนุนเริ่มตรวจสอบปัญหาระบุสาเหตุที่แท้จริง
|
|||
|
เวลาที่เกิดเหตุการณ์
EventTime
|
วันและเวลาที่กิจกรรมเกิดขึ้น. | ||
|
คำอธิบาย
แอตทริบิวต์นี้บันทึกวันและเวลาที่กิจกรรมเกิดขึ้นอย่างแม่นยำ ใน BMC Helix ITSM จะตรงกับช่องต่างๆ เช่น 'Submit Date', 'Last Modified Date' หรือเวลาที่บันทึกไว้ในตารางประวัติเมื่อสถานะเปลี่ยนแปลง ในการวิเคราะห์ แอตทริบิวต์นี้ใช้เรียงลำดับเหตุการณ์ตามเวลาและคำนวณระยะเวลา ช่วยวัดเวลาระหว่างจุดต่างๆ ในกระบวนการ เช่น 'Investigation Cycle Time' หรือ 'Workaround Publication Lead Time' การบันทึกเวลาที่แม่นยำมีความสำคัญต่อการค้นหาคอขวด เมื่อนำเวลาของเหตุการณ์ที่เกิดขึ้นต่อเนื่องกันมาเปรียบเทียบ นักวิเคราะห์จะระบุได้ว่าความล่าช้าเกิดขึ้นตรงไหน ไม่ว่าจะเป็นช่วงมอบหมายงานครั้งแรกหรือช่วงทบทวนขั้นสุดท้าย.
เหตุผลที่สำคัญ
ใช้คำนวณ KPI ที่อิงตามระยะเวลาทั้งหมดและเรียงลำดับเหตุการณ์.
แหล่งข้อมูล
ตารางประวัติหรือบันทึกการตรวจสอบที่เชื่อมโยงกับ PBM:Problem Investigation
ตัวอย่าง
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:20:10Z
|
|||
|
ระบบต้นทาง
SourceSystem
|
ระบบที่เป็นแหล่งที่มาของข้อมูล. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุระบบซอฟต์แวร์ที่ดึงข้อมูลกระบวนการมาใช้ ในกรณีนี้คือ 'BMC Helix ITSM' แอตทริบิวต์นี้สำคัญเป็นพิเศษในสภาพแวดล้อมที่มีหลายระบบ ซึ่ง process mining อาจรวมข้อมูลจากเครื่องมือ ITSM ระบบพัฒนา หรือเครื่องมือของผู้ให้บริการภายนอกหลายรายการ ในการวิเคราะห์ ช่องนี้ทำหน้าที่เป็นแท็กข้อมูลกำกับเพื่อยืนยันแหล่งที่มาของระเบียน หากมุมมอง process mining รวมข้อมูลการจัดการปัญหาจาก BMC Helix กับข้อมูลการพัฒนาซอฟต์แวร์จากอีกระบบ เช่น Jira แอตทริบิวต์นี้จะช่วยแยกผลวิเคราะห์ตามระบบต้นทาง นอกจากนี้ยังช่วยแก้ไขปัญหาทางเทคนิค หากพบปัญหาคุณภาพข้อมูล วิศวกรข้อมูลจะตรวจสอบย้อนกลับไปยังขั้นตอนดึงข้อมูลหรือฐานข้อมูลต้นทางที่เกี่ยวข้องได้.
เหตุผลที่สำคัญ
ช่วยตรวจสอบย้อนกลับและให้บริบท โดยเฉพาะเมื่อดูมุมมองกระบวนการที่รวมข้อมูลจากหลายระบบ.
แหล่งข้อมูล
กำหนดค่าไว้ในขั้นตอนดึงข้อมูล
ตัวอย่าง
BMC Helix ITSMRemedy OnDemandBMC ITSM Prod
|
|||
|
อัปเดตข้อมูลล่าสุด
LastDataUpdate
|
วันและเวลาที่ดึงข้อมูลหรือรีเฟรชข้อมูลครั้งล่าสุด. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุเวลาที่โหลดข้อมูลเข้าสู่แอปพลิเคชัน process mining ครั้งล่าสุด โดยช่วยให้นักวิเคราะห์ทราบว่าข้อมูลที่กำลังดูเป็นข้อมูลล่าสุดเพียงใด โดยทั่วไปสคริปต์ดึงข้อมูลหรือเครื่องมือ data pipeline จะเป็นผู้กำหนดค่า ในการวิเคราะห์ ข้อมูลนี้ช่วยป้องกันการตัดสินใจจากข้อมูลเก่า ตัวอย่างเช่น หากผู้จัดการดู 'Open Problem Records' การทราบว่าข้อมูลอัปเดตเมื่อหนึ่งชั่วโมงก่อนหรือหนึ่งสัปดาห์ก่อนย่อมส่งผลต่อการตีความภาระงานปัจจุบัน แอตทริบิวต์นี้ยังใช้กับการโหลดข้อมูลแบบเพิ่มเฉพาะส่วนที่เปลี่ยนแปลง โดยติดตามเวลาอัปเดตล่าสุด กระบวนการ ETL จึงดึงเฉพาะระเบียนที่เปลี่ยนแปลงนับจากการดึงข้อมูลครั้งก่อน ช่วยเพิ่มประสิทธิภาพและลดภาระของระบบ.
เหตุผลที่สำคัญ
ช่วยให้ข้อมูลเป็นปัจจุบันและสนับสนุนแนวทางโหลดข้อมูลแบบเพิ่มเฉพาะส่วนที่เปลี่ยนแปลง.
แหล่งข้อมูล
เวลาของระบบ ณ ขณะที่ดึงข้อมูล
ตัวอย่าง
2023-11-01T00:00:00Z2023-11-01T12:00:00Z
|
|||
|
Service CI
ServiceCI
|
บริการทางธุรกิจหรือรายการกำหนดค่าหลักที่ได้รับผลกระทบ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุ Service Configuration Item (CI) ที่เกี่ยวข้องกับปัญหา เช่น 'บริการอีเมล', 'SAP ERP' หรือ 'เครือข่าย Wi-Fi' ใน BMC Helix มักเป็นช่อง 'Service+' หรือความสัมพันธ์กับ CI หลัก ในการวิเคราะห์ แอตทริบิวต์นี้ช่วยแยกระเบียนปัญหาตามผลิตภัณฑ์หรือบริการ ทำให้ผู้บริหารฝ่าย IT เข้าใจว่าบริการใดมีความเปราะบางและก่อให้เกิดการตรวจสอบปัญหามากที่สุด ข้อมูลนี้ยังช่วยเพิ่มมิติด้านผลิตภัณฑ์ให้แดชบอร์ด 'Throughput and Priority Volume' เมื่อนำแอตทริบิวต์นี้มาเปรียบเทียบกับ 'Investigation Cycle Time' จะเห็นได้ว่าบริการที่ซับซ้อนบางประเภท เช่น ระบบธนาคารหลัก ต้องใช้เวลาตรวจสอบนานกว่าบริการทั่วไปอย่างงานพิมพ์หรือไม่.
เหตุผลที่สำคัญ
เชื่อมโยงประสิทธิภาพของกระบวนการกับผลิตภัณฑ์หรือบริการทางธุรกิจที่เกี่ยวข้อง.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'ServiceCI' หรือ 'CI Name'
ตัวอย่าง
บริการอีเมลระบบเงินเดือนVPN ขององค์กร
|
|||
|
กลุ่มสนับสนุน
SupportGroup
|
ทีมเทคนิคที่ได้รับมอบหมายให้ตรวจสอบปัญหาในขณะนั้น. | ||
|
คำอธิบาย
แอตทริบิวต์นี้แสดงกลุ่มสนับสนุนที่รับผิดชอบระเบียนปัญหาในเวลาที่เกิดเหตุการณ์ เช่น 'Server Admin' หรือ 'Database Support' ใน BMC Helix จะตรงกับช่อง 'Assigned Group' แอตทริบิวต์นี้สำคัญต่อแดชบอร์ด 'Support Group Workload Distribution' และ 'Support Group Reassignment Analysis' นักวิเคราะห์สามารถแยกดูแผนผังกระบวนการตามทีม เพื่อดูว่ากลุ่มใดรับงานมากที่สุดและกลุ่มใดเป็นคอขวดในขั้นตอนตรวจสอบปัญหา การวิเคราะห์การส่งต่องานระหว่างกลุ่มสนับสนุนช่วยค้นหาการส่งงานวนไปมา โดยทิกเก็ตถูกส่งระหว่างทีมโดยไม่มีการแก้ไขปัญหา ซึ่งมักบ่งชี้ว่าความรับผิดชอบไม่ชัดเจนหรือการจัดการความรู้ในองค์กรยังไม่เพียงพอ.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์การทำงานในระดับองค์กรและค้นหาคอขวดในระดับทีม.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Assigned Group'
ตัวอย่าง
ฝ่ายบริการผู้ใช้ระดับ 1ฝ่ายสนับสนุนส่วนงานหลังบ้านฝ่ายดูแลระบบเครือข่าย
|
|||
|
จำนวน Incident ที่เกี่ยวข้อง
RelatedIncidentCount
|
จำนวน Incident ที่เชื่อมโยงกับระเบียนปัญหานี้. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ใช้จำนวน Incident ที่เกี่ยวข้องเพื่อวัดผลกระทบของปัญหา ใน BMC Helix โดยทั่วไปจะนับระเบียนในแบบฟอร์ม HPD:Help Desk ที่เชื่อมโยงกับระเบียน PBM ข้อมูลนี้ใช้คำนวณ KPI 'Incident Linkage Density' หากมี Incident จำนวนมาก แสดงว่าปัญหาส่งผลกระทบสูงและสร้างภาระให้ฝ่ายบริการ การนำข้อมูลนี้ไปเทียบกับ 'Priority' ช่วยตรวจสอบว่าปัญหาที่เกิดขึ้นบ่อยได้รับการจัดการเป็นเรื่องเร่งด่วนจริงหรือไม่ ข้อมูลนี้ยังช่วยจัดลำดับงานค้าง ระเบียนปัญหาที่เชื่อมโยงกับ Incident 500 รายการควรได้รับการจัดลำดับก่อนปัญหา 'Critical' ที่มี Incident เพียงรายการเดียว เพราะการแก้ปัญหาแรกจะช่วยลดภาระงานของฝ่ายบริการได้มากกว่า.
เหตุผลที่สำคัญ
ใช้วัดผลกระทบต่อการปฏิบัติงานและความเดือดร้อนของผู้ใช้ที่เกิดจากปัญหา.
แหล่งข้อมูล
คำนวณจากจำนวนแถวที่เกี่ยวข้องใน HPD:Associations หรือ HPD:Help Desk
ตัวอย่าง
15120
|
|||
|
ผิด SLA หรือไม่
IsSLABreached
|
แฟล็กระบุว่าการแก้ไขปัญหาใช้เวลาเกินกำหนดหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์ค่าจริง/เท็จนี้ระบุว่าระเบียนปัญหาผิด SLA หรือไม่ โดยคำนวณจากการเปรียบเทียบเวลาประทับ 'Resolution Verified' กับ 'SLA Due Date' หรือดึงข้อมูลโดยตรงจากสถานะ SLM ข้อมูลนี้สำคัญต่อแดชบอร์ด 'SLA Compliance and Breach Trends' เพราะช่วยแบ่งกระบวนการเป็นสองกลุ่มได้ชัดเจน คือทำตามข้อกำหนดและไม่ทำตามข้อกำหนด จึงตรวจสอบลักษณะของกรณีที่ไม่สำเร็จได้ง่ายขึ้น เช่น 'กรณีที่ผิด SLA เกี่ยวข้องกับ Support Group X ทุกครั้งหรือไม่' ข้อมูลนี้ยังเป็นตัวกรองหลักสำหรับวิเคราะห์สาเหตุรากของความล้มเหลวในกระบวนการ นักวิเคราะห์กรอง 'IsSLABreached = True' แล้วตรวจสอบแผนผังกระบวนการเพื่อดูว่าเสียเวลาในขั้นตอนไหน เช่น รอการอนุมัติจากผู้ขายนานเกินไป.
เหตุผลที่สำคัญ
ช่วยให้การรายงานการปฏิบัติตามข้อกำหนดและการวิเคราะห์ความล้มเหลวทำได้ง่ายขึ้น.
แหล่งข้อมูล
แบบฟอร์ม SLM:Measurement หรือค่าที่คำนวณได้
ตัวอย่าง
truefalse
|
|||
|
ผู้ประสานงานการจัดการปัญหา
ProblemCoordinator
|
ผู้ใช้ที่ได้รับมอบหมายให้ประสานงานการตรวจสอบ. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุชื่อผู้รับผิดชอบระเบียนปัญหา ใน BMC Helix ITSM จะตรงกับช่อง 'Problem Coordinator' บุคคลนี้ดูแลวงจรการทำงานของปัญหา แม้จะมอบหมายงานบางส่วนให้ผู้อื่น แอตทริบิวต์นี้สนับสนุนแดชบอร์ด 'Support Group Workload Distribution' ช่วยให้ผู้จัดการเห็นว่ามีผู้ใดรับงานตรวจสอบมากเกินไป ขณะที่ผู้อื่นยังมีขีดความสามารถเหลืออยู่หรือไม่ นอกจากนี้ยังใช้วิเคราะห์ประสิทธิภาพรายบุคคล เพื่อค้นหาความต้องการด้านการฝึกอบรมหรือผู้ที่ทำงานได้ดี ใน process mining ช่องนี้ทำหน้าที่เป็นแอตทริบิวต์ทรัพยากร ช่วยแสดงภาพการส่งต่องานระหว่างบุคคล และชี้ให้เห็นจุดที่กระบวนการพึ่งพาผู้เชี่ยวชาญคนใดคนหนึ่งมากเกินไปจนเสี่ยงต่อการหยุดชะงัก.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์ทรัพยากรและปรับสมดุลภาระงานในระดับบุคคล.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Problem Coordinator'
ตัวอย่าง
John DoeJane Smithผู้ดูแลระบบ
|
|||
|
ระดับความสำคัญ
Priority
|
ระดับความสำคัญของปัญหาที่คำนวณจากผลกระทบและความเร่งด่วน. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุระดับความสำคัญของระเบียนปัญหา เช่น วิกฤต สูง ปานกลาง หรือต่ำ ใน BMC Helix โดยทั่วไปค่านี้คำนวณจากตัวเลือกผลกระทบและความเร่งด่วน ในการวิเคราะห์ แอตทริบิวต์นี้ใช้กับแดชบอร์ด 'Throughput and Priority Volume' ช่วยให้องค์กรตรวจสอบได้ว่าจัดสรรทรัพยากรสอดคล้องกับความต้องการทางธุรกิจหรือไม่ ตัวอย่างเช่น ปัญหาระดับ 'Critical' ควรได้รับการมอบหมายงานครั้งแรกเร็วกว่าและใช้เวลาดำเนินการโดยรวมน้อยกว่าปัญหาระดับ 'Low' การกรองตามระดับความสำคัญช่วยให้มุ่งปรับปรุงจุดที่จำเป็น คอขวดในกระบวนการระดับ 'Low' อาจยอมรับได้ แต่ความล่าช้าแบบเดียวกันในกระบวนการระดับ 'Critical' ถือเป็นความเสี่ยงสำคัญต่อความต่อเนื่องทางธุรกิจและการปฏิบัติตาม SLA.
เหตุผลที่สำคัญ
ช่วยแบ่งผลวิเคราะห์ตามความสำคัญต่อธุรกิจและสนับสนุนการวิเคราะห์ SLA.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Priority'
ตัวอย่าง
วิกฤตสูงปานกลางต่ำ
|
|||
|
วันครบกำหนดตาม SLA
SLADueDate
|
วันและเวลาที่กำหนดให้แก้ไขปัญหาให้เสร็จสิ้น. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุกำหนดเวลาแก้ไขปัญหาตามข้อตกลงระดับการให้บริการ ใน BMC Helix มักใช้ช่อง 'Target Resolution Date' หรือเวลาประทับของหมุดหมาย SLA ที่คำนวณไว้ ข้อมูลนี้เป็นเกณฑ์อ้างอิงสำหรับแดชบอร์ด 'SLA Compliance and Breach Trends' ระบบจะเปรียบเทียบเวลาประทับนี้กับเวลาของกิจกรรม 'Resolution Verified' เพื่อคำนวณว่าทำได้ตาม SLA หรือไม่ เมื่อนำวันที่นี้มาแสดง นักวิเคราะห์จะเห็นว่าทีมแก้ปัญหาได้ก่อนกำหนดนานแค่ไหน หรือมักเสร็จก่อนผิด SLA เพียงไม่กี่นาที ข้อมูลนี้ช่วยวางแผนกำลังคนและทรัพยากร.
เหตุผลที่สำคัญ
ใช้เป็นจุดอ้างอิงในการคำนวณตัวชี้วัดด้านการปฏิบัติตามข้อกำหนดและความตรงต่อเวลา.
แหล่งข้อมูล
แบบฟอร์ม PBM:Problem Investigation ช่อง 'Target Resolution Date'
ตัวอย่าง
2023-12-01T17:00:00Z2023-12-02T09:00:00Z
|
|||
|
สาเหตุที่เริ่มตรวจสอบ
InvestigationDriver
|
เหตุผลที่เริ่มตรวจสอบปัญหา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้จัดประเภทสาเหตุที่เริ่มสร้างระเบียนปัญหา เช่น 'จำนวนเหตุขัดข้อง', 'เหตุขัดข้องร้ายแรง', 'การแจ้งเตือนจากผู้ให้บริการ' หรือ 'การวิเคราะห์แนวโน้มเชิงรุก' ใน BMC Helix จะตรงกับช่อง 'Investigation Driver' แอตทริบิวต์นี้สนับสนุนแดชบอร์ด 'Proactive Identification Trends' ช่วยให้องค์กรวัดการเปลี่ยนจากการแก้ปัญหาเฉพาะหน้าเมื่อเกิดเหตุขัดข้อง ไปสู่การจัดการปัญหาเชิงรุกที่ช่วยระบุความเสี่ยงก่อนเกิดเหตุ การวิเคราะห์ขั้นตอนกระบวนการตาม 'Investigation Driver' อาจเผยให้เห็นรูปแบบการทำงานที่แตกต่างกัน ตัวอย่างเช่น ปัญหาที่พบจากการทำงานเชิงรุกอาจค้างอยู่ในคิวนานกว่า เพราะยังไม่ทำให้บริการหยุดชะงักทันที ขณะที่ปัญหาจาก 'Major Incident' มักเร่งดำเนินการให้เสร็จโดยเร็ว.
เหตุผลที่สำคัญ
ช่วยแยกงานเชิงรับออกจากงานเชิงรุก ซึ่งเป็นตัวชี้วัดสำคัญของระดับความพร้อมในการจัดการกระบวนการ.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Investigation Driver'
ตัวอย่าง
เชิงรับเชิงรุกเหตุขัดข้องที่เกิดซ้ำ
|
|||
|
หมวดหมู่สาเหตุที่แท้จริง
RootCauseCategory
|
การจัดประเภทสาเหตุเบื้องหลังของปัญหา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุหมวดหมู่ที่เลือกเมื่อพบสาเหตุที่แท้จริง เช่น 'ข้อผิดพลาดของซอฟต์แวร์', 'อุปกรณ์ขัดข้อง' หรือ 'ช่องว่างในกระบวนการ' ใน BMC Helix โดยทั่วไปจะเลือกจากเมนู 'Root Cause' หรือ 'Generic Categorization' แอตทริบิวต์นี้จำเป็นต่อมุมมอง 'Fix Effectiveness and Quality' ช่วยให้องค์กรเปรียบเทียบสาเหตุที่แท้จริงแต่ละประเภทกับอัตราการทำงานซ้ำหรือระยะเวลาตรวจสอบที่ยาวนาน ตัวอย่างเช่น อาจพบว่าปัญหา 'ข้อผิดพลาดของซอฟต์แวร์' ใช้เวลาแก้ไขนานกว่าปัญหา 'อุปกรณ์ขัดข้อง' ถึงสองเท่าอย่างสม่ำเสมอ นอกจากนี้ยังใช้คำนวณ 'Root Cause Categorization Rate' หากช่องนี้มีค่า 'Unknown' หรือ 'Other' ในสัดส่วนสูง อาจแสดงว่าจำเป็นต้องฝึกอบรมด้านเทคนิคเพิ่มเติมหรือเพิ่มตัวเลือกการจัดหมวดหมู่ให้ละเอียดขึ้น.
เหตุผลที่สำคัญ
ช่วยวิเคราะห์แนวโน้มของปัญหาเชิงระบบและสนับสนุนการจัดการปัญหาเชิงรุก.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่องในแท็บ 'Root Cause' หรือการจัดหมวดหมู่
ตัวอย่าง
โมดูลซอฟต์แวร์โครงสร้างพื้นฐานเครือข่ายความผิดพลาดของบุคลากร
|
|||
|
ID คำขอเปลี่ยนแปลงที่เกี่ยวข้อง
RelatedChangeRequestId
|
รหัสคำขอเปลี่ยนแปลงที่สร้างขึ้นเพื่อแก้ไขปัญหา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้เก็บ ID ของคำขอเปลี่ยนแปลง (เช่น CRQ0000...) ที่เชื่อมโยงกับระเบียนปัญหา ซึ่งแสดงการเปลี่ยนจากขั้นตอนตรวจสอบไปสู่การนำวิธีแก้ไขถาวรไปใช้ ข้อมูลนี้จำเป็นต่อ KPI 'Root Cause to Change Lead Time' โดยช่วยให้ process mining วัดเวลาที่ผ่านไประหว่างการระบุสาเหตุรากกับการเริ่มกระบวนการเปลี่ยนแปลง ซึ่งเป็นจุดส่งต่องานที่มักทำให้การดำเนินงานล่าช้า ข้อมูลนี้ยังช่วยตรวจสอบความครบถ้วนของกระบวนการ หากปิดระเบียนปัญหาด้วยสถานะ 'Completed' แต่ไม่มีคำขอเปลี่ยนแปลงที่เกี่ยวข้องหรือวิธีแก้ปัญหาชั่วคราว อาจหมายถึงกระบวนการไม่เป็นไปตามข้อกำหนด โดยพบสาเหตุรากแล้วแต่ยังไม่ได้แก้ไขจริง.
เหตุผลที่สำคัญ
เชื่อมกระบวนการจัดการปัญหากับกระบวนการจัดการการเปลี่ยนแปลง.
แหล่งข้อมูล
แท็บ PBM:Investigation Associations หรือ Relationship
ตัวอย่าง
CRQ00000021345CRQ00000021346
|
|||
|
จำนวนครั้งที่เปลี่ยนกลุ่ม
ReassignmentCount
|
จำนวนครั้งทั้งหมดที่มีการเปลี่ยนกลุ่มสนับสนุน. | ||
|
คำอธิบาย
แอตทริบิวต์นี้นับจำนวนครั้งที่กิจกรรม 'Assigned to Support Group' เกิดขึ้นในแต่ละกรณี เป็นตัวชี้วัดโดยตรงของความติดขัดในกระบวนการและประสิทธิภาพการส่งต่องาน ข้อมูลนี้ใช้สร้างแผนภูมิ 'Support Group Reassignment Analysis' หากค่าสูงหรือมีการส่งงานวนไปมา อาจหมายถึงการคัดแยกเบื้องต้นไม่แม่นยำ หรือไม่มีผู้รับผิดชอบที่ชัดเจนสำหรับปัญหาซับซ้อน และยังเป็นสัญญาณว่ารอบเวลาดำเนินการอาจยาวขึ้น ผู้จัดการใช้ข้อมูลนี้เพื่อหาโอกาสในการฝึกอบรม หากฝ่ายบริการส่งปัญหา 'Database' ไปให้ 'Network' ก่อนเป็นประจำ แล้ว 'Network' ส่งกลับไปที่ 'Database' จำนวนครั้งที่เปลี่ยนกลุ่มจะเพิ่มขึ้น ซึ่งชี้ให้เห็นว่าควรปรับปรุงแนวทางวินิจฉัยเบื้องต้น.
เหตุผลที่สำคัญ
ช่วยระบุงานที่สูญเปล่า ความติดขัด และการขาดผู้รับผิดชอบในกระบวนการ.
แหล่งข้อมูล
คำนวณจากประวัติกิจกรรม
ตัวอย่าง
015
|
|||
|
ภูมิภาค
Region
|
ภูมิภาคทางภูมิศาสตร์ที่เกี่ยวข้องกับปัญหา. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ระบุพื้นที่ทางภูมิศาสตร์ (เช่น 'North America', 'EMEA') ที่ปัญหาเกิดขึ้นหรือพื้นที่ที่กำลังจัดการปัญหา ใน BMC Helix มักพบข้อมูลนี้ในช่อง 'Region' หรือ 'Site' ที่เชื่อมโยงกับผู้แจ้งหรือทรัพย์สินที่ได้รับผลกระทบ ข้อมูลนี้ช่วยแบ่งผลการวิเคราะห์ตามภูมิภาค และช่วยระบุว่าภูมิภาคใดมีปัญหาจำนวนมากหรือใช้เวลาแก้ไขนานกว่า ซึ่งอาจชี้ให้เห็นความแตกต่างด้านจำนวนบุคลากรสนับสนุนหรือคุณภาพโครงสร้างพื้นฐานในแต่ละพื้นที่ องค์กรที่ดำเนินงานทั่วโลกใช้ข้อมูลนี้เพื่อตรวจสอบว่าการให้บริการเป็นไปอย่างสม่ำเสมอหรือไม่ หาก 'Investigation Cycle Time' ใน 'APAC' นานกว่า 'NAM' ถึงสองเท่า ก็เป็นสัญญาณให้ตรวจสอบการจัดสรรทรัพยากรหรือการปฏิบัติตามกระบวนการในภูมิภาคนั้น.
เหตุผลที่สำคัญ
ช่วยเปรียบเทียบประสิทธิภาพของกระบวนการในแต่ละภูมิภาค.
แหล่งข้อมูล
แบบฟอร์ม PBM:Problem Investigation ช่อง 'Region'
ตัวอย่าง
ทวีปอเมริกาEMEAAPAC
|
|||
|
ระยะเวลาการตรวจสอบปัญหา
InvestigationCycleTime
|
ระยะเวลาตั้งแต่เริ่มตรวจสอบจนระบุสาเหตุรากได้. | ||
|
คำอธิบาย
แอตทริบิวต์นี้คำนวณระยะเวลาระหว่างกิจกรรม 'Investigation Commenced' กับ 'Root Cause Identified' ซึ่งเป็นช่วงเวลาหลักที่กระบวนการจัดการปัญหาสร้างคุณค่า ตัวชี้วัดนี้ใช้ในแดชบอร์ด 'Root Cause Investigation Cycle Time' เพื่อช่วยให้ผู้จัดการเข้าใจความซับซ้อนทางเทคนิคของปัญหาและประสิทธิภาพของทีมตรวจสอบ หากใช้เวลาสั้นผิดปกติ อาจเป็นการคาดเดา ส่วนการใช้เวลานานมากอาจหมายถึงการตรวจสอบหยุดชะงัก เมื่อนำตัวชี้วัดนี้ไปเปรียบเทียบระหว่าง 'Support Groups' และ 'Priorities' องค์กรจะระบุได้ว่าทีมใดต้องการเครื่องมือ การฝึกอบรม หรือการสนับสนุนจากผู้ขายเพิ่มเติม เพื่อวินิจฉัยปัญหาได้เร็วขึ้น.
เหตุผลที่สำคัญ
เป็นตัวชี้วัดหลักด้านประสิทธิภาพของขั้นตอนตรวจสอบทางเทคนิค.
แหล่งข้อมูล
คำนวณจากเวลาประทับของกิจกรรม
ตัวอย่าง
4500000120000
|
|||
|
สถานะวิธีแก้ปัญหาชั่วคราว
WorkaroundStatus
|
ระบุว่าพบและเผยแพร่วิธีแก้ปัญหาชั่วคราวที่ใช้ได้แล้วหรือไม่. | ||
|
คำอธิบาย
แอตทริบิวต์นี้ติดตามสถานะของวิธีแก้ปัญหาชั่วคราว (Workaround) ซึ่งอาจเก็บเป็นค่าจริง/เท็จอย่างง่าย (Has Workaround) หรือเป็นข้อความสถานะ ใน BMC Helix มักพิจารณาจากการมีข้อความในช่อง 'Workaround' หรือสถานะที่กำหนดไว้ ข้อมูลนี้เป็นหัวใจสำคัญของแดชบอร์ด 'Workaround Publication Performance' ซึ่งช่วยประเมินว่าทีมลดผลกระทบได้ดีเพียงใดระหว่างค้นหาสาเหตุราก เมื่อกรองมุมมองกระบวนการด้วย 'No Workaround' จะเห็นกรณีที่ธุรกิจได้รับผลกระทบเต็มที่ระหว่างการตรวจสอบ ข้อมูลนี้ยังช่วยตรวจสอบคุณภาพด้วย โดยทั่วไป การปิดระเบียนปัญหาโดยไม่มีวิธีแก้ไขถาวร (คำขอเปลี่ยนแปลง) และไม่มีวิธีแก้ปัญหาชั่วคราว ถือเป็นความล้มเหลวของกระบวนการที่ควรนำมาทบทวน.
เหตุผลที่สำคัญ
ใช้วัดประสิทธิผลในการลดผลกระทบระหว่างการตรวจสอบ.
แหล่งข้อมูล
แบบฟอร์ม PBM:Problem Investigation ตรวจสอบเนื้อหาในช่อง 'Workaround'
ตัวอย่าง
ใช้งานอยู่ไม่มีเลิกใช้งาน
|
|||
กิจกรรมการจัดการปัญหา
| กิจกรรม | คำอธิบาย | ||
|---|---|---|---|
|
กำหนดวิธีแก้ปัญหาชั่วคราว
|
การกรอกหรืออัปเดตข้อความในช่อง Workaround ของระเบียนปัญหา เหตุการณ์นี้แสดงว่ามีการบันทึกวิธีแก้ปัญหาชั่วคราวแล้ว. | ||
|
เหตุผลที่สำคัญ
ใช้สนับสนุน KPI 'Workaround Publication Lead Time' และแสดงว่ามีการบรรเทาผลกระทบจากเหตุขัดข้อง.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, การเปลี่ยนแปลงในช่องข้อความ 'Workaround'.
บันทึก
เปรียบเทียบเนื้อหาในช่อง 'Workaround' เพื่อตรวจจับการอัปเดตที่ไม่ใช่ค่าว่าง
ประเภทเหตุการณ์
inferred
|
|||
|
ตรวจสอบผลการแก้ไข
|
จุดที่ยืนยันแล้วว่าวิธีแก้ไขถาวรได้ผล ระบบอนุมานเหตุการณ์นี้เมื่อ Status เปลี่ยนเป็น 'Solution Implemented' หรือ 'Completed'. | ||
|
เหตุผลที่สำคัญ
ใช้คำนวณ 'Problem SLA Adherence Rate' และยืนยันว่าการทำงานด้านเทคนิคเสร็จสิ้นแล้ว.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Status' = 'Solution Implemented' หรือ 'Completed'.
บันทึก
เปรียบเทียบช่องสถานะเพื่อตรวจจับการเปลี่ยนเป็น Solution Implemented
ประเภทเหตุการณ์
inferred
|
|||
|
บันทึก Problem Record
|
การสร้างระเบียน Problem Investigation ในระบบครั้งแรก ระบบจะบันทึกเหตุการณ์นี้เมื่อบันทึกรายการใหม่ในฟอร์ม PBM:Problem Investigation. | ||
|
เหตุผลที่สำคัญ
ระบุจุดเริ่มต้นของกระบวนการ ใช้คำนวณระยะเวลาดำเนินการทั้งหมดและตัวชี้วัดการตอบสนองเบื้องต้น.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, เวลาในช่อง 'Submit Date' หรือบันทึกการสร้างที่มี 'Status' = 'Draft'.
บันทึก
บันทึกเมื่อสร้างระเบียน PBM:Problem Investigation
ประเภทเหตุการณ์
explicit
|
|||
|
ปิด Problem Record
|
การปิดระเบียนปัญหาขั้นสุดท้ายในส่วนงานธุรการ เหตุการณ์นี้สิ้นสุดกระบวนการ. | ||
|
เหตุผลที่สำคัญ
เหตุการณ์สิ้นสุดมาตรฐาน จำเป็นต่อการวิเคราะห์ระยะเวลาดำเนินการทั้งหมดและคำนวณ 'Incident Linkage Density'.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Status' = 'Closed'.
บันทึก
เปรียบเทียบช่องสถานะเพื่อตรวจจับการเปลี่ยนเป็น Closed
ประเภทเหตุการณ์
inferred
|
|||
|
มอบหมายให้ทีมสนับสนุน
|
การมอบหมายระเบียนปัญหาให้ทีมเทคนิคที่ระบุ ระบบบันทึกเหตุการณ์นี้เมื่อตรวจพบการเปลี่ยนแปลงในช่อง 'Assigned Group'. | ||
|
เหตุผลที่สำคัญ
จำเป็นต่อการวัดการส่งต่องาน การส่งงานไปมาหลายครั้ง และ KPI 'Mean Time to Initial Assignment'.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ประวัติช่อง 'Assigned Group' หรือบันทึกการตรวจสอบ.
บันทึก
เปรียบเทียบค่าในช่อง 'Assigned Group' ก่อนและหลังอัปเดต
ประเภทเหตุการณ์
inferred
|
|||
|
ยกเลิก Problem Record
|
การยุติระเบียนปัญหาก่อนแก้ไขเสร็จ ระบบบันทึกเหตุการณ์นี้เมื่อสถานะเปลี่ยนเป็น 'Cancelled' หรือ 'Rejected'. | ||
|
เหตุผลที่สำคัญ
ช่วยระบุงานที่เสียเปล่าหรือรายการซ้ำที่ถูกต้อง เป็นจุดสิ้นสุดอีกแบบหนึ่งของกระบวนการ.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Status' = 'Cancelled' หรือ 'Rejected'.
บันทึก
เปรียบเทียบช่องสถานะเพื่อตรวจจับการเปลี่ยนเป็น Cancelled
ประเภทเหตุการณ์
inferred
|
|||
|
ระบุสาเหตุที่แท้จริง
|
จุดที่ระเบียนปัญหาเปลี่ยนเป็นสถานะซึ่งแสดงว่าทราบสาเหตุแล้ว ระบบอนุมานเหตุการณ์นี้เมื่อ Status เปลี่ยนเป็น 'Root Cause Identified'. | ||
|
เหตุผลที่สำคัญ
หมุดหมายสำคัญสำหรับแดชบอร์ด 'Root Cause Investigation Cycle Time' และแสดงการเปลี่ยนจากการวิเคราะห์ไปสู่การหาแนวทางแก้ไข.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Status' = 'Root Cause Identified'.
บันทึก
เปรียบเทียบช่องสถานะเพื่อตรวจจับการเปลี่ยนเป็น Root Cause Identified
ประเภทเหตุการณ์
inferred
|
|||
|
เริ่มคำขอเปลี่ยนแปลง
|
การเชื่อมโยง Infrastructure Change Request กับ Problem Investigation เป็นสัญญาณเริ่มต้นของขั้นตอนการนำไปใช้. | ||
|
เหตุผลที่สำคัญ
จำเป็นต่อ KPI 'Root Cause to Change Lead Time' และช่วยค้นหาจุดแยกการทำงานระหว่างกระบวนการ Problem และ Change.
แหล่งข้อมูล
ตาราง PBM:Investigation_Associations หรือการกรอกช่อง 'Infrastructure Change ID'.
บันทึก
บันทึกเมื่อสร้างการเชื่อมโยงใน PBM:Investigation_Associations
ประเภทเหตุการณ์
explicit
|
|||
|
เริ่มตรวจสอบปัญหา
|
ระเบียนปัญหาเปลี่ยนเข้าสู่ขั้นตอนวิเคราะห์ที่กำลังดำเนินการ ระบบอนุมานเหตุการณ์นี้เมื่อช่อง Status เปลี่ยนเป็น 'Under Investigation'. | ||
|
เหตุผลที่สำคัญ
ระบุจุดเริ่มต้นของการทำงานจริง และใช้สนับสนุน KPI 'Investigation Cycle Time'.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Status' = 'Under Investigation'.
บันทึก
เปรียบเทียบช่องสถานะเพื่อตรวจจับการเปลี่ยนเป็น Under Investigation
ประเภทเหตุการณ์
inferred
|
|||
|
ดำเนินการทบทวนหลังนำไปใช้
|
การสิ้นสุดขั้นตอน PIR ซึ่งบันทึกได้จากการเปลี่ยนสถานะออกจากสถานะ PIR หรือการปิดงาน PIR ที่เชื่อมโยงอยู่. | ||
|
เหตุผลที่สำคัญ
สนับสนุน 'Post Implementation Review Compliance' และการตรวจสอบคุณภาพกระบวนการโดยตรง.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation โดยตรวจสอบแฟล็ก 'PIR Required' หรือการทำงานที่เชื่อมโยงซึ่งมีประเภทงานเป็น 'PIR' จนเสร็จสมบูรณ์.
บันทึก
อนุมานจากการสิ้นสุดสถานะ PIR หรือการปิดงาน PIR
ประเภทเหตุการณ์
inferred
|
|||
|
เปลี่ยนผู้ประสานงาน
|
การเปลี่ยนผู้ประสานงาน Problem ภายในกลุ่มสนับสนุน ระบบบันทึกเหตุการณ์นี้เมื่อตรวจสอบช่อง 'Problem Coordinator'. | ||
|
เหตุผลที่สำคัญ
ช่วยวิเคราะห์การกระจายภาระงานและคอขวดด้านทรัพยากรของแต่ละคน.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ประวัติช่อง 'Problem Coordinator'.
บันทึก
เปรียบเทียบค่าในช่อง 'Problem Coordinator' ก่อนและหลังอัปเดต
ประเภทเหตุการณ์
inferred
|
|||
|
ยกระดับเป็น Known Error
|
การสร้างระเบียน Known Error ที่เชื่อมโยงกับการตรวจสอบปัญหา เป็นเหตุการณ์สร้างระเบียนที่เกี่ยวข้อง. | ||
|
เหตุผลที่สำคัญ
แสดงว่ามีการบันทึกปัญหาอย่างเป็นทางการ เพื่อสื่อสารในวงกว้างและติดตามในระยะยาว.
แหล่งข้อมูล
สร้างระเบียนใน PBM:Known Error และเชื่อมโยงกับ PBM:Problem Investigation ID.
บันทึก
บันทึกเมื่อสร้างระเบียน PBM:Known Error
ประเภทเหตุการณ์
explicit
|
|||
|
อัปเดตฐานข้อมูลวิธีแก้ไข
|
ระเบียนเปลี่ยนเป็นสถานะ 'Solution Database' ซึ่งแสดงว่ามีการเสนอหรือระบุวิธีแก้ไขถาวรแล้ว. | ||
|
เหตุผลที่สำคัญ
ติดตามความคืบหน้าในการกำหนดวิธีแก้ไขก่อนนำไปใช้.
แหล่งข้อมูล
ฟอร์ม PBM:Problem Investigation, ช่อง 'Status' = 'Solution Database'.
บันทึก
เปรียบเทียบช่องสถานะเพื่อตรวจจับการเปลี่ยนเป็น Solution Database
ประเภทเหตุการณ์
inferred
|
|||
คู่มือการดึงข้อมูล
พร้อมเริ่มต้นหรือยัง?
นำเทมเพลตนี้ไปใช้กับข้อมูล BMC Helix ITSM ของคุณวันนี้ เพื่อเพิ่มเสถียรภาพในการให้บริการ หากมีคำถามเกี่ยวกับการตั้งค่า ทีมงานของเราพร้อมช่วยเหลือ.
แก้คอขวดในการจัดการปัญหาได้ตั้งแต่วันนี้
ลดระยะเวลาของกระบวนการลง 30% และเพิ่มเสถียรภาพในการให้บริการ.
ไม่ต้องใช้บัตรเครดิต ตั้งค่าเสร็จได้ในไม่กี่นาที.