ไม่มีใครเป็นเจ้าของข้อมูล จึงไม่มีใครเชื่อรายงาน
ผมเคยเห็นกรณีนี้ในทีมการเงินทีมหนึ่งเมื่อปีที่แล้ว พวกเขาสร้างรายงานรายได้ขึ้นมา CFO เปิดดูแล้วถามว่าทำไมตัวเลขไม่ตรงกับที่นำเสนอในบอร์ดเมื่อเดือนก่อน นักพัฒนา BI ตรวจ query ดู ตัวเลขถูกต้อง ข้อมูลมาจากระบบที่ทุกคนเห็นชอบ แต่ไม่มีใครพอใจ
ฝ่ายการเงินคำนวณรายได้วิธีหนึ่ง ฝ่ายขายคำนวณต่างออกไป พอรายงานออกมาใช้นิยามของฝ่ายการเงิน ฝ่ายขายเห็นตัวเลขไม่ตรงกับ spreadsheet ตัวเองก็หยุดเชื่อรายงานทันที
ถ้าองค์กรของคุณกำลังเจอเรื่องนี้อยู่ รายงานไม่ใช่ต้นเหตุ ต้นเหตุเก่ากว่านั้น ไม่มีใครเคยรับผิดชอบในการตกลงกันว่า "รายได้" แปลว่าอะไร
เรื่องนี้เกิดซ้ำในองค์กรส่วนใหญ่ที่ทีมการเงินและทีมขายแยกกัน ทีมภูมิภาคนับธุรกรรมเดียวกันคนละงวดรายงาน การตลาดกับ customer success ไม่ตรงกันว่า engagement คืออะไร ทุกทีมสร้างนิยามที่ใช้ได้กับ spreadsheet ตัวเอง พอมีรายงานรวมศูนย์ออกมา ตัวเลขขัดกับทุก mental model ในห้องประชุม
ส่วนใหญ่โทษ dashboard ทั้งที่ความขัดแย้งมีอยู่มาตลอด แค่มองไม่เห็นเพราะแต่ละคนดูข้อมูลของตัวเอง พอเผยแพร่รายงานเดียว ก็บังคับให้องค์กรยอมรับว่านิยามไม่เคยตรงกันตั้งแต่แรก
นั่นแหละคือจุดที่ต้องตัดสินใจ
ความเป็นเจ้าของข้อมูลจะโยนให้ทีม BI รับผิดชอบไม่ได้ คนที่นิยาม metric และตัดสินว่าระบบไหนคือแหล่งข้อมูลหลักต้องตัดสินใจร่วมกัน นักพัฒนา BI แค่ implement ตามที่ธุรกิจตกลงกัน ไม่ใช่คนทำข้อตกลง แล้วเมื่อรายงานแสดงตัวเลขขัดกับ mental model ของ stakeholder นักพัฒนาก็โดนโทษ ทั้งที่ไม่ใช่คนสร้างความขัดแย้ง
เมื่อ CFO, VP of Sales และ Controller นั่งลงด้วยกันเป็นครั้งแรกเพื่อนิยาม "รายได้" จริงๆ บทสนทนานั้นอึดอัด พวกเขาพบว่ารายงานตัวเลขต่างกันมาตลอด spreadsheet ของทีมหนึ่งเป็นฐานการตัดสินใจมาสองปีแล้ว ต้องแก้ และต้องใช้เวลา
แต่บทสนทนานั้นต้องเกิดก่อนสร้างรายงาน ไม่ใช่หลัง
ทุกอาทิตย์ที่รอ มีคนสร้าง dashboard ใหม่บนความขัดแย้งเดิม คลังรายงานโตขึ้น ความเชื่อถือใน BI หาย นักพัฒนาไม่ได้ส่งมอบอะไรใหม่ แต่ใช้เวลาแก้ต่างเรื่องคุณภาพข้อมูลแทน
session เดียวที่มีโครงสร้างดีจะดึงความขัดแย้งทุกอย่างที่องค์กรแบกรับเงียบๆ ออกมา นิยามว่าระบบไหนคือ source ตกลงสูตรคำนวณและงวดรายงาน ตัดสินใจว่าใครเป็นเจ้าของแต่ละ metric ทั้งหมดนี้ก่อนที่จะโหลดข้อมูลแถวแรก
นั่นคือวิธีหยุดรับช่วง "ความไม่ไว้วางใจ" ต่อจากคนอื่น
เมื่อการเงินและฝ่ายขายรายงานตัวเลขต่างกันจากระบบเดียวกัน ปัญหาไม่ใช่ข้อมูล ไม่ใช่รายงาน แต่คือไม่มีใครเคยตกลงกันเรื่องนิยาม บทสนทนานั้นต้องเกิดก่อนสร้างรายงาน รอนานแค่ไหน รายงานก็ถูกสร้างทับบนความขัดแย้งเดิมมากเท่านั้น → เริ่ม session data ownership
นิยามก่อน สร้างทีหลัง
ทุกอาทิตย์ที่ยังไม่มีการตกลงกันเรื่องนิยาม ก็มีรายงานใหม่ถูกสร้างทับบนความขัดแย้งเดิม session เดียวช่วยดึงทุกความขัดแย้งออกมาก่อนที่จะโหลดข้อมูลแถวแรก
คุยกับเราคำถามที่พบบ่อย
ความต่างระหว่างปัญหาคุณภาพข้อมูลกับปัญหานิยามคืออะไร?
ปัญหาคุณภาพข้อมูลคือระบบต้นทางมีข้อมูลไม่ครบหรือผิดพลาด ปัญหานิยามคือสองแผนกดูข้อมูลเดียวกันแต่คำนวณต่างกัน รายงานอาจถูกต้องทางเทคนิคแต่ล้มเหลวได้ เพราะไม่ได้แก้ความขัดแย้งด้านนิยามก่อนสร้าง
ถ้ามี spreadsheet คู่แข่งอยู่แล้ว ยัง align ทันไหม?
ทัน นี่คือช่วงเวลาที่เหมาะสมพอดี การมี spreadsheet หลายชุดพิสูจน์ว่านิยามไม่เคยถูกกำหนดอย่างเป็นทางการ รายงานสร้างแรงกดดันให้แก้ไขในที่สุด ซึ่งเป็นประโยชน์ ทางเลือกคือให้ stakeholder คัดเลือกรายงานที่ตัวเองอยากเชื่อไปอีกปี
session data ownership ใช้เวลานานแค่ไหน?
session เดียวใช้เวลาประมาณ 2 ถึง 4 ชั่วโมง ต้องการคนที่เหมาะสม คือคนที่เป็นเจ้าของ metric คนที่ดูแลข้อมูลต้นทาง และคนที่ใช้ตัวเลขนั้นตัดสินใจจริงๆ คนมากขึ้นถกนานขึ้น คนน้อยเกินไปข้อตกลงไม่ยั่ง
ถ้า align นิยามได้แล้วแต่ข้อมูลในระบบยังไม่ตรงกับสูตรที่ตกลง จะทำอย่างไร?
แปลว่าเจอปัญหาคุณภาพข้อมูลจริงๆ และรู้แล้วว่าต้องแก้ตรงไหน รู้ว่าระบบต้นทางต้องปรับก่อนเผยแพร่ นั่นคือความก้าวหน้า องค์กรส่วนใหญ่ไม่เคยไปถึงจุดนี้ เพราะยังแย่งกันนิยามตัวเลขอยู่