ทำไมโครงการ 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 ไม่ใช่ถ้า — แต่เมื่อไร และมากเท่าไร