ความท้าทายของ Process Mining: ทำอย่างไรให้โครงการเดินหน้าตามแผน

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

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

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

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

ดูขั้นตอนตรวจสอบข้อบกพร่องที่พบบ่อยในบันทึกเหตุการณ์ได้ที่ ตรวจสอบบันทึกของคุณกับข้อบกพร่อง 4 ประเภทที่พบบ่อย.

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

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

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

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

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

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

อาการ: ทีมของคุณใช้เวลาเตรียมการเชื่อมต่อหรือเรียนรู้เครื่องมือมากกว่าหาคำตอบเกี่ยวกับกระบวนการ ทุกครั้งที่ต้องเปลี่ยนแปลงก็ต้องขอความช่วยเหลือจากผู้เชี่ยวชาญ

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

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

สาเหตุที่เป็นไปได้: ยังไม่ได้ข้อสรุปเรื่องการเข้าถึงข้อมูล ผู้เป็นเจ้าของข้อมูล หรือข้อกำหนดในการเตรียมข้อมูล

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

สาเหตุที่เป็นไปได้: ขอบเขตงานไม่ได้เชื่อมโยงกับการตัดสินใจเรื่องใดเรื่องหนึ่ง

แนวทางแก้ไข: กลับไปทบทวนคำถามตั้งต้น แล้วพักการวิเคราะห์กระบวนการอื่นไว้ก่อนจนกว่าจะวิเคราะห์เรื่องแรกเสร็จ

สาเหตุที่เป็นไปได้: เหตุการณ์ขาดหาย ชื่อกิจกรรมไม่ตรงกัน หรือขอบเขตกระบวนการไม่ชัดเจน

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

**สาเหตุที่เป็นไปได้:**ทีมไม่มีค่าฐานหรือ KPI ที่ตกลงร่วมกัน

**สิ่งที่ควรทำ:**บันทึก KPI ปัจจุบัน แล้วกำหนดว่าจะวัดซ้ำเมื่อใดและอย่างไร

สาเหตุที่เป็นไปได้: ไม่มีผู้รับผิดชอบการตัดสินใจหรือขั้นตอนถัดไป

สิ่งที่ควรทำ: มอบหมายผู้รับผิดชอบ ตกลงแนวทางดำเนินการ และกำหนดวันทบทวนผล

สาเหตุที่เป็นไปได้: โครงการนี้ออกแบบขึ้นโดยไม่ได้ให้คนที่ทำงานจริงเข้ามามีส่วนร่วม

สิ่งที่ควรทำ: ให้คนเหล่านั้นช่วยตรวจสอบกระบวนการและเลือกคำถามที่จะศึกษา

สาเหตุที่เป็นไปได้: เวิร์กโฟลว์ซับซ้อนเกินไป หรือความรู้อยู่กับคนใดคนหนึ่ง

สิ่งที่ควรทำ: บันทึกขั้นตอนให้ชัดเจน และพัฒนาทักษะของผู้ที่จะดูแลการวิเคราะห์ต่อ

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

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

**วิธีป้องกัน:**กำหนดขอบเขตกระบวนการและมุ่งดูเฉพาะจุดสำคัญที่เกี่ยวข้องกับคำถาม ใช้ process mining ดูความแตกต่างระหว่างกรณี แล้วตรวจสอบรูปแบบที่เกี่ยวข้องกับปัญหา ให้ผู้ปฏิบัติงานช่วยยืนยันว่าข้อมูลเหตุการณ์แสดงสิ่งที่เกิดขึ้นจริง

อาการ: แต่ละทีมเรียกกิจกรรมเดียวกันต่างกัน หรือไม่เห็นตรงกันว่ากรณีหนึ่งเสร็จสมบูรณ์เมื่อใด

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

**วิธีป้องกัน:**ตกลงร่วมกันว่ากรณีหนึ่งหมายถึงอะไร และกิจกรรมสำคัญแต่ละรายการหมายถึงอะไร ก่อนนำผลมาเปรียบเทียบ บันทึกสมมติฐานและการแปลงข้อมูลไว้ เพื่อให้ทบทวนและวิเคราะห์ซ้ำได้

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

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

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

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

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

**วิธีป้องกัน:**อธิบายเป้าหมาย ขอบเขต และข้อจำกัดของการวิเคราะห์ ให้เจ้าของกระบวนการและทีมหน้างานมีส่วนร่วมตั้งแต่เนิ่นๆ และเชื่อมโยงงานกับเป้าหมายการปฏิบัติการที่ชัดเจน แบ่งปันหลักฐานและสมมติฐาน ไม่ใช่แค่ข้อสรุป

อาการ: งานชะงักเมื่อไม่มีนักวิเคราะห์คนใดคนหนึ่งอยู่ หรือทีมอื่นดูแลการวิเคราะห์ต่อไม่ได้

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

**วิธีป้องกัน:**บันทึกกระบวนการ คำจำกัดความของข้อมูล และการตัดสินใจ ฝึกอบรมผู้ที่จะใช้ผลการวิเคราะห์ และกำหนดวิธีขอแก้ไขหรือทบทวนผลให้ชัดเจน Center of Excellence ช่วยประสานงานระหว่างทีมได้ แต่ไม่ได้มาแทนที่เจ้าของกระบวนการ

อาการ: โครงการนำร่องจบลง แต่ไม่มีใครวางแผนว่าจะทำต่อ ปรับแนวทาง หรือยุติ

สาเหตุ: ทีมมองว่าโครงการนำร่องคือผลลัพธ์สุดท้าย แทนที่จะใช้ทดสอบแนวทางที่ทำซ้ำได้

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