ข้อมูลเชิงลึก
บทความเชิงลึกเกี่ยวกับเหตุผลที่โครงการ BI ล้มเหลว วิธีการค้นพบ requirements ที่แท้จริง และวิธีการตัดสินใจด้วยข้อมูลที่เชื่อถือได้
ซีรีส์ 1 · บทความที่ 12
ระหว่างการค้นพบความต้องการกับโค้ดบรรทัดแรก มีเอกสารที่ไม่มีใครเขียน
การค้นพบความต้องการจบลง การสร้างเริ่มต้น และระหว่างนั้นมีเอกสารที่แทบไม่มีใครเขียน change request ที่ตามมาไม่ใช่ scope creep แต่คือข้อกำหนดสำหรับการสร้างที่ทยอยมาถึงทีละชิ้น
อ่านบทความ →ซีรีส์ 1 · บทความที่ 11
วังวนความไม่เชื่อมั่น: ทำไมแดชบอร์ดที่ล้มเหลวแต่ละครั้ง ทำให้โครงการถัดไปขออนุมัติงบยากขึ้น
แดชบอร์ดที่ล้มเหลวแต่ละตัวถูกมองเป็นอุบัติเหตุแยกกัน แต่จริง ๆ มันคือวงจรเดียวที่หล่อเลี้ยงตัวเอง ข้อมูลแย่ ตัวเลขผิด ความเชื่อมั่นหาย ถอยไป Excel งบหด ข้อมูลยิ่งแย่ การเรียกชื่อวงจรให้ถูกคือก้าวแรกของการตัดมัน
อ่านบทความ →ซีรีส์ 1 · บทความที่ 10
รายงานที่คุณเพิ่งสร้างให้เขา เขาอ่านไม่ออก
รายงานผ่านการตรวจทางเทคนิคทุกด่านก็ยังไม่มีใครใช้ได้ เพราะไม่มีใครเช็กว่าคนอ่านอ่านออกไหม การอ่านข้อมูลคือข้อมูลตั้งต้นก่อนวางภาพแรก ไม่ใช่การอบรมที่มาเสริมทีหลัง
อ่านบทความ →ซีรีส์ 1 · บทความที่ 9
ตัวเลขแรกที่ผู้ใช้ตรวจ คือสิ่งที่ตัดสินทุกอย่าง
รายงานที่ผมสร้างตายภายในสี่วินาที ไม่ใช่เพราะข้อผิดพลาด แต่เพราะตัวเลขหนึ่งที่ไม่ตรงกับที่ผู้ใช้เชื่ออยู่แล้ว ตัวเลขแรกที่เขาตรวจ ตัดสินทุกสิ่งที่ตามมา
อ่านบทความ →ซีรีส์ 1 · บทความที่ 8
ที่ปรึกษาสร้างระบบเสร็จแล้วก็จากไป ผมเห็นเรื่องนี้จบได้สามแบบ
ระบบ BI ที่ผมสร้างตายภายในหนึ่งปี ทั้งที่การสร้างไม่มีปัญหา สิ่งที่ตัดสินชะตาของมันไม่เคยเป็นโค้ด แต่เป็นว่ามีใครในองค์กรถูกวางตัวให้เป็นเจ้าของหลังผมจากไปหรือไม่
อ่านบทความ →ซีรีส์ 1 · บทความที่ 7
พจนานุกรมข้อมูลคืออะไรกันแน่ และทำไมโครงการ BI ส่วนใหญ่จึงมองข้าม
ผู้บริหารสองคนอ่านรายงาน Power BI ฉบับเดียวกันแต่ได้ตัวเลขลูกค้าต่างกัน ทั้งคู่ไม่ได้ผิด สิ่งที่ขาดไปคือข้อตกลงที่ไม่มีใครเคยเขียนลงไว้
อ่านบทความ →ซีรีส์ 1 · บทความที่ 6
40 รายงาน ไม่มีการตัดสินใจ: Self-Service BI ให้ผลอะไรกันแน่
Self-service BI สัญญาว่าทุกทีมจะเข้าถึงข้อมูลได้ สิ่งที่หลายองค์กรได้รับกลับเป็นรายงานสี่สิบชิ้นที่ไม่มีใครเชื่อถือ และการตัดสินใจจากแหล่งที่ผิด
อ่านบทความ →ซีรีส์ 1 · บทความที่ 1
ทำไมโครงการ BI ถึงล้มเหลว — ไม่ใช่เพราะเทคโนโลยี
โครงการ BI ส่วนใหญ่ล้มเหลวจาก requirements ที่ผิดพลาด ไม่ใช่จาก code ที่ผิด รูปแบบที่เกิดขึ้นซ้ำๆ และวิธีที่ WizEmp แก้ไขมัน
อ่านบทความ →ซีรีส์ 1 · บทความที่ 2
กับดักการประชุม Stakeholder
ความเงียบในการประชุม stakeholder ไม่ใช่ความเห็นพ้อง มันคือการปกป้องตัวเอง วิธีที่ WizEmp รวบรวม requirements จริงด้วยการไม่ระบุตัวตน
อ่านบทความ →ซีรีส์ 1 · บทความที่ 3
ช่องว่างในข้อกำหนด — ที่นั่งว่างในห้องประชุม
คนที่ใกล้ชิดกับข้อมูลมากที่สุดมักไม่มีสิทธิ์กำหนดว่าข้อมูลควรผลิตอะไร ช่องว่างนี้ทำให้ BI reports พลาดเป้าหมาย
อ่านบทความ →ซีรีส์ 1 · บทความที่ 4
ไม่มีใครเป็นเจ้าของข้อมูล จึงไม่มีใครเชื่อรายงาน
เมื่อไม่มีการกำหนดความเป็นเจ้าของข้อมูลที่ชัดเจน ทีมทุกทีมจะสร้างคำนิยามของตัวเอง ผลลัพธ์คือ dashboard ที่ใช้ตัวเลขต่างกัน และไม่มีใครเชื่อถือตัวเลขของคนอื่น
อ่านบทความ →ซีรีส์ 1 · บทความที่ 5
Change Request ที่ไม่มีวันหยุด: นี่คืออะไรกันแน่
Change request BI ที่ไม่ยอมหยุดหลัง delivery ไม่ใช่ scope creep แต่คือต้นทุน discovery ที่โปรเจกต์ปฏิเสธจ่ายตั้งแต่ต้น ตอนนี้กลับมาในราคาสามเท่า
อ่านบทความ →