ทำไมโครงการ BI ของคุณจะล้มเหลว
ก่อนที่จะสร้าง Report แรก
ผมเห็นโครงการ BI ล้มเหลวในรูปแบบเดิมซ้ำๆ มาตลอด 25 ปี ไม่ใช่ตอนส่งมอบ ไม่ใช่ตอน testing แต่ล้มเหลวในสองสัปดาห์แรก ตอนที่ใครบางคนเขียน specification จากสิ่งที่คนพูดในห้องประชุม
รูปแบบที่เกิดซ้ำ: มีการนัดประชุม workshop ผู้บริหารระดับสูงเริ่มพูด ทุกคนปรับตัวตาม BA จดบันทึกและเรียกมันว่า specification สองเดือนต่อมา report ถูกส่งมอบ ไม่มีใครใช้มัน
Specification บันทึก Consensus ไม่ใช่ความจริง
การสนทนาในการประชุมผลิต consensus Consensus ไม่ใช่ความจริง เมื่อคนที่อาวุโสที่สุดพูดก่อน คำตอบต่อๆ มาทุกคำตอบจะปรับตัวตาม เมื่อผู้คนถูกถามต่อหน้าเพื่อนร่วมงาน พวกเขาจะให้คำตอบที่มีความเสี่ยงทางการเมืองน้อยที่สุด
นักวิเคราะห์ที่เงียบซึ่งรู้ว่า report ควรมีอะไรจะไม่พูด การโต้แย้ง VP ในห้องประชุมไม่ใช่สิ่งที่คนส่วนใหญ่จะทำ ดังนั้น BA จึงจดสิ่งที่ VP พูด โครงการก็ดำเนินต่อไปบนฐานของความสุภาพ
อคติเชิงลำดับชั้น: ฆาตกรเงียบของโครงการ BI
ผลลัพธ์ที่ได้คือ hierarchy ที่กำหนดทุกคำตอบ สิ่งที่ได้รับคือ specification ที่เขียนขึ้นทาง การเมือง ปลอดภัยทางการเมืองและถูกต้องทางเทคนิคไม่ใช่สิ่งเดียวกัน
ผลกระทบที่ตามมาคาดเดาได้: change request ที่ไม่มีวันสิ้นสุด report ที่ต้องสร้างใหม่สามหรือสี่ครั้ง อัตรา adoption ต่ำกว่า 20% หกเดือนหลัง deploy สิ่งเหล่านี้ไม่ใช่ความล้มเหลวด้านการสร้าง แต่เป็นความล้มเหลวด้าน discovery ที่โผล่ขึ้นมาหลังจากที่ใช้งบประมาณไปแล้ว
หรือถูกถามในสถานการณ์ที่ความซื่อสัตย์มีความเสี่ยงทางวิชาชีพ
Input แบบไม่ระบุตัวตนลบตัวกรองลำดับชั้น
การแก้ไขคือการเปลี่ยนแปลงโครงสร้างเดียว: ทำ discovery ก่อนการสร้าง ไม่ใช่ workshop แต่เป็นกระบวนการที่ผู้มีส่วนได้ส่วนเสียให้ input แบบไม่ระบุตัวตน โดยไม่มีลำดับชั้นมากำหนดคำตอบ ครอบคลุมทุกบทบาทที่สัมผัสกับ report
ถ้าคุณกำลังดำเนินโครงการ BI อยู่ตอนนี้ ถามคำถามเดียว: specification ถูกสร้างขึ้นจากสิ่งที่ผู้มีส่วนได้ส่วนเสียพูดในการประชุมหรือไม่? หรือจากสิ่งที่พวกเขาพูดเมื่อแรงกดดันจากลำดับชั้นถูกกำจัดออก?
ถ้าคำตอบคือการประชุม specification นั้นมี assumptions ที่ยังไม่ได้รับการทดสอบ มันจะโผล่ขึ้นมาเป็น change request ไม่ใช่ถ้า — แต่เมื่อไร และมากเท่าไร
ทำ discovery ก่อนการสร้าง
ถ้า specification ของคุณถูกสร้างขึ้นจากสิ่งที่คนพูดในการประชุม change request กำลังรอคิวอยู่แล้ว WizEmp ทำ structured discovery ที่ใช้เวลาเป็นวัน ไม่ใช่เดือนที่คุณเสียไปกับการแก้ specification ที่ผิดหลังส่งมอบ
คุยกับเราคำถามที่พบบ่อย
เหตุใดการรวบรวม requirements จากผู้มีส่วนได้ส่วนเสียในการประชุมจึงไม่ได้ผล?
การประชุมสร้าง consensus ไม่ใช่ความจริง ในสภาพแวดล้อมแบบลำดับชั้น คนที่อาวุโสน้อยกว่ามักจะไม่ท้าทายมุมมองของผู้บริหาร ผลลัพธ์ที่ได้คือ requirements ที่สะท้อนถึงสิ่งที่คนในห้องประชุมยอมรับ ไม่ใช่สิ่งที่ผู้ใช้งานจริงต้องการ
อคติเชิงลำดับชั้นส่งผลต่อโครงการ BI อย่างไร?
ผู้บริหารระดับสูงกำหนด requirements แต่บ่อยครั้งพวกเขาไม่ใช่ผู้ใช้งาน report จริง ผู้จัดการระดับกลางและนักวิเคราะห์จะไม่พูดขัดแย้งในการประชุมที่มีผู้บังคับบัญชา ช่องว่างนี้ทำให้สร้าง report ที่ถูกต้องแต่ไม่มีประโยชน์
Input แบบไม่ระบุตัวตนช่วยแก้ปัญหานี้ได้อย่างไร?
เมื่อผู้มีส่วนได้ส่วนเสียสามารถให้ input โดยไม่ต้องแสดงตัวตน ตัวกรองลำดับชั้นจะถูกลบออก คนที่ไม่เคยพูดในการประชุมจะบอกคุณว่า report อะไรที่พวกเขาต้องการจริงๆ ซึ่งมักจะแตกต่างจากสิ่งที่ผู้บริหารคิดว่าพวกเขาต้องการ
WizEmp แก้ปัญหาอคติเชิงลำดับชั้นใน BI อย่างไร?
กระบวนการ Wit ของ WizEmp รวบรวม input จากผู้มีส่วนได้ส่วนเสียทุกระดับผ่านช่องทางที่มีโครงสร้างซึ่งออกแบบมาเพื่อลด hierarchy bias ผลลัพธ์จะถูกสังเคราะห์เป็น Shield of Truth™ ที่ทุกคนที่มีส่วนได้ส่วนเสียเซ็น