ปรับปรุงกระบวนการไอที

ปรับปรุงกระบวนการไอที

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

ประวัติทิกเก็ตบอกอะไรได้บ้างเกี่ยวกับการจัดการเหตุการณ์?

เริ่มจากตรวจสอบรูปแบบ 3 รายการ

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

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

process mining ช่วยปรับปรุงกระบวนการด้าน IT ได้อย่างไร?

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

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

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

คุณตรวจสอบแนวปฏิบัติ ITIL ด้านใดได้บ้าง?

ITIL กำหนดแนวปฏิบัติสำหรับการจัดการบริการ process mining ช่วยตรวจสอบข้อมูลเหตุการณ์ที่เกี่ยวข้องกับแนวปฏิบัติเหล่านั้น และเปรียบเทียบเส้นทางตั๋วที่เกิดขึ้นจริงกับกระบวนการที่บันทึกไว้.

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

คุณวัดผลอะไรได้บ้างในกระบวนการ ITSM?

เมื่อมีบันทึกเหตุการณ์ที่เหมาะสม คุณสามารถกำหนด KPI สำหรับเรื่องต่อไปนี้ได้:

• เวลาแก้ไขเหตุขัดข้องและผลตาม SLA
• การส่งต่อและการส่งต่องานต่อเคส
• การเปลี่ยนระดับความสำคัญและความเกี่ยวข้องกับการผิด SLA
• การเปิดเคสซ้ำและการแก้งาน
• เวลาอนุมัติและดำเนินการตามคำขอ
• ผลการเปลี่ยนแปลงและรูปแบบกระบวนการ
• แนวโน้มปริมาณงานและจำนวนงานที่ดำเนินการ

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

จะนำผลวิเคราะห์ไปปรับปรุงงานได้อย่างไร?

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

จากนั้น:

1. ส่งออกประวัติตั๋วที่มีรหัสเคส ชื่อกิจกรรม เวลาที่เกิดเหตุการณ์ และคุณลักษณะที่เกี่ยวข้อง
2. ตรวจสอบว่าข้อมูลเหตุการณ์สะท้อนกระบวนการที่คุณต้องการวิเคราะห์
3. ตรวจดูผังกระบวนการที่ค้นพบ แล้วเปรียบเทียบรูปแบบต่างๆ ตามผลลัพธ์
4. กำหนด KPI ร่วมกับผู้รับผิดชอบบริการ
5. ใช้หลักฐานประกอบการพิจารณาว่าควรปรับกระบวนการอย่างไร.

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

จะสร้าง KPI ที่ผู้บริหารเชื่อถือได้อย่างไร?

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

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

ดูวิธีสร้างแดชบอร์ดกระบวนการและ KPI

ต้องใช้ข้อมูลอะไรเพื่อเริ่มต้น?

เริ่มจากการส่งออกข้อมูลเหตุขัดข้องหรือคำขอที่มีข้อมูลต่อไปนี้:

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

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

ควรเลือกการวิเคราะห์แรกอย่างไร?

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

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

หากต้องการกำหนดเกณฑ์และติดตามสุขภาพกระบวนการ ดูเอกสารสุขภาพกระบวนการ.

วิเคราะห์เส้นทางเหตุขัดข้องหรือคำขอจากข้อมูล ticket ที่ส่งออก