วิธีสร้างแหล่งข้อมูลความจริงหนึ่งเดียว (Single Source of Truth): คู่มือฉบับสมบูรณ์

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

นั่นไม่ใช่ปัญหาเรื่องข้อมูล แต่มันคือปัญหาเรื่องการนิยามที่แฝงตัวมาในคราบของปัญหาข้อมูลต่างหาก

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

คู่มือนี้จะอธิบายความหมายที่แท้จริงของคำนี้ และการตัดสินใจ 4 ประการที่ต้องทำก่อนจะเริ่มแตะต้องสเปรดชีต จากนั้นจะพาไปดูแนวทางแบบทำด้วยตัวเอง (manual) 3 วิธี และข้อจำกัดของแต่ละวิธี

แหล่งข้อมูลความจริงหนึ่งเดียว (single source of truth) คืออะไรกันแน่

คู่มือเกี่ยวกับ SSOT ของ Workday นิยามสิ่งนี้ไว้ว่าเป็น "ระบบรวมศูนย์ที่รวบรวม ทำความสะอาด และเปิดให้ทุกคนเข้าถึงข้อมูลธุรกิจที่สำคัญและเป็นปัจจุบันที่สุดได้อย่างทั่วถึง"

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

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

ในหน้าเดียวกันนั้นระบุว่า ไซโลข้อมูล (data silos) คือสาเหตุหลักของตัวเลขที่ขัดแย้งกัน โดยอธิบายว่ามันคือ "กลุ่มข้อมูลที่ถูกแยกขาดและติดอยู่ในเครื่องมือ สเปรดชีต และเซิร์ฟเวอร์ของแผนกที่ไม่ได้เชื่อมต่อกัน" ลำดับขั้นตอนที่แนะนำจึงเริ่มจากการกำกับดูแล (governance) ไม่ใช่แพลตฟอร์ม: นิยามคำศัพท์, แต่งตั้งผู้รับผิดชอบ, จากนั้นค่อยเลือกเทคโนโลยี, ทำความสะอาดข้อมูล, แล้วจึงทยอยเริ่มใช้งานเป็นระยะๆ

ทำไมสองทีมถึงได้ตัวเลขต่างกัน

สาเหตุมักจะมาจาก 4 ปัจจัยนี้เสมอ และไม่มีข้อไหนที่เป็นเรื่องของวิชาคณิตศาสตร์เลย

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

ขอบเขตเวลาต่างกัน ทีมหนึ่งตัดยอดสิ้นเดือน ณ วันที่ออกใบแจ้งหนี้ (invoice date) อีกทีมตัดยอด ณ วันที่ชำระเงิน (payment date) ทั้งสองวิธีมีเหตุผลรองรับ และตัวเลขจะไม่มีวันตรงกันเลย

ตัวส่วนต่างกัน อัตราส่วนประกอบด้วยสองส่วน เมื่อเปลี่ยนตัวส่วนด้านล่าง เปอร์เซ็นต์ก็เปลี่ยนไปทันทีโดยที่ข้อมูลดิบไม่ได้เปลี่ยนเลยแม้แต่แถวเดียว

ช่วงเวลาที่ดึงข้อมูลต่างกัน ไฟล์หนึ่งดึงข้อมูลวันที่ 1 อีกไฟล์ดึงวันที่ 3 และมีข้อมูลที่ส่งล่าช้าเข้ามาเพิ่มในช่วงเวลา 3 วันนั้นพอดี

4 การตัดสินใจที่ต้องตกลงกันให้ได้ก่อน

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

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

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

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

วิธีการทำด้วยตัวเอง (manual)

ทางเลือกที่ 1: ตรวจสอบและปรับปรุงข้อมูลสองเวอร์ชันแบบบรรทัดต่อบรรทัด

เริ่มต้นจากจุดที่ข้อมูลไม่ตรงกันแทนที่จะเริ่มจากทฤษฎี ดึงรายงานทั้งสองฉบับเข้ามาไว้ในเวิร์กบุ๊กเดียวกัน แล้วจับคู่ข้อมูลด้วย XLOOKUP โดยใช้คีย์ร่วมกัน

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

ระวังป้ายกำกับ (labels) ที่เกือบจะซ้ำกันในระหว่างที่คุณทำด้วย ฟังก์ชัน EXACT จะเปรียบเทียบค่าข้อความสองค่าโดยคำนึงถึงตัวอักษรพิมพ์เล็ก-พิมพ์ใหญ่ (case-sensitive) ซึ่งจะช่วยตรวจจับคู่คำอย่าง "ACME Corp" กับ "Acme Corp." ที่สายตามนุษย์มักจะมองข้ามไปได้

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

ทางเลือกที่ 2: สร้างชุดข้อมูลเดียว แล้วดึงรายงานทุกฉบับมาจากชุดข้อมูลนั้น

รวมข้อมูลก่อน แล้วค่อยทำรายงาน ฟีเจอร์ Power Query's merge รองรับการเชื่อมโยงข้อมูล (join) หลายรูปแบบ รวมถึง anti join ซึ่ง anti join จะแสดงรายการข้อมูลที่มีอยู่ในแหล่งข้อมูลหนึ่งแต่ไม่มีในอีกแหล่งข้อมูลหนึ่ง

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

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

ข้อจำกัดคือเรื่องการบำรุงรักษา เพราะต้องมีใครสักคนคอยกดรีเฟรชข้อมูล และคนๆ นั้นก็จะกลายเป็นคอขวดที่ทุกคนต้องพึ่งพา

ทางเลือกที่ 3: สร้างแท็บนิยามไว้ข้างๆ ตัวเลข

กำหนด 1 แถวต่อ 1 ตัวชี้วัด: ชื่อ, นิยาม, ตัวกรองที่ใช้, ฟิลด์วันที่ที่ใช้, ผู้รับผิดชอบ, วันที่ตรวจสอบล่าสุด

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

ข้อจำกัดคือการเขียนนิยามไม่ได้เป็นการบังคับใช้จริง แท็บนิยามกับสูตรที่ใช้จริงอาจจะคลาดเคลื่อนไปคนละทิศละทาง และมักจะเป็นเช่นนั้นเสมอ

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

จุดที่แนวทางแบบทำด้วยตัวเองเริ่มช้าลง

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

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

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

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

นี่คือเหตุผลว่าทำไมเครื่องมือประเภทนี้จึงเกิดขึ้นมา บทความรวบรวม AI tools for business intelligence without a data team ของเราได้ครอบคลุมถึงเครื่องมือต่างๆ ที่จะช่วยแก้ปัญหานี้

วิธีสร้างด้วย Powerdrill Bloom

ขั้นตอนที่ 1: อัปโหลดไฟล์ข้อมูลที่ขัดแย้งกันทั้งสองไฟล์

อัปโหลดไฟล์ทั้งสองที่ข้อมูลไม่ตรงกันขึ้นไปพร้อมกัน Powerdrill Bloom จะวิเคราะห์โครงสร้างคอลัมน์ (profile) ทันทีที่อัปโหลด ดังนั้น รูปแบบคีย์ที่ไม่ตรงกัน, ป้ายกำกับที่ไม่สอดคล้องกัน และฟิลด์ที่ว่างเปล่าจะถูกตรวจพบก่อนที่จะมีการคำนวณยอดรวมใดๆ เสียอีก

ขั้นตอนที่ 2: ระบุนิยามด้วยภาษาธรรมชาติ (natural language)

อธิบายกฎเกณฑ์แทนที่จะต้องสร้างมันขึ้นมา ระบุชื่อตัวชี้วัด, ข้อมูลแถวที่ต้องการคัดออก, ฟิลด์วันที่ที่ใช้ตัดรอบเวลา และการจัดกลุ่มข้อมูล

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

ขั้นตอนที่ 3: ส่งออกรายงานที่ปรับปรุงข้อมูลให้ตรงกันแล้ว

ส่งออกรายงานที่ปรับปรุงข้อมูลให้ตรงกันแล้วพร้อมแนบนิยามประกอบ

ทำไมวิธีนี้ถึงดีกว่าการตรวจสอบและปรับปรุงข้อมูลด้วยตัวเอง

	แนวทางแบบทำด้วยตัวเอง	Powerdrill Bloom
การค้นหาข้อมูลที่ไม่ตรงกัน	ทำ anti join สำหรับไฟล์แต่ละคู่	ถามว่ามีข้อมูลแถวใดที่ขาดหายไปบ้าง
การตรวจจับป้ายกำกับที่เกือบจะซ้ำกัน	สร้างคอลัมน์ช่วยคำนวณแบบคำนึงถึงตัวพิมพ์เล็ก-ใหญ่	แสดงให้เห็นทันทีเมื่ออัปโหลด
การทดสอบขอบเขตเวลาแบบอื่น	สร้างตัวกรองใหม่และคำนวณยอดรวมใหม่	ระบุกฎอีกแบบแล้วถามคำถามได้เลย
การทำซ้ำในเดือนถัดไป	กดรีเฟรชและหวังว่าจะไม่มีอะไรคลาดเคลื่อน	เปลี่ยนไฟล์ใหม่ แต่ใช้กฎเดิมที่ตั้งไว้

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

ข้อผิดพลาดที่พบบ่อย

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

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

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

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

ตรวจสอบข้อมูลที่ดึงออกมาคนละวันกัน ข้อมูลที่ส่งเข้ามาล่าช้าจะทำให้ดูเหมือนว่าข้อมูลไม่ตรงกัน ควรตรวจสอบเวลาที่ดึงข้อมูล (extraction timestamp) ให้ตรงกันก่อนที่จะเริ่มจับคู่ข้อมูลแต่ละแถว

บันทึกนิยามไว้ในที่ที่ไม่มีใครเปิดดู ควรเก็บนิยามเหล่านั้นไว้ในไฟล์เดียวกับตัวเลข และระบุกฎเกณฑ์ที่ใช้ลงบนแผนภูมิด้วย

ข้ามขั้นตอนการระบุผู้รับผิดชอบ นิยามที่ไม่มีผู้อนุมัติที่ชัดเจนคือนิยามที่จะถูกตีความใหม่ในอนาคต ควรระบุชื่อผู้รับผิดชอบในทุกๆ แถว

บทสรุป

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

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

หากวงจรดังกล่าวทำให้คุณเสียเวลาในช่วงสิ้นเดือน ลองใช้ Powerdrill Bloom กับไฟล์สองไฟล์ที่ข้อมูลไม่ตรงกันดูสิ นอกจากนี้ คุณยังสามารถดูคู่มือของเราเกี่ยวกับการ สร้างแดชบอร์ด KPI จากสเปรดชีต และการ ตั้งเป้าหมาย KPI จากข้อมูลของคุณเอง ได้อีกด้วย สำหรับขั้นตอนการเตรียมข้อมูล สามารถศึกษาเพิ่มเติมได้ที่หน้า การทำความสะอาดข้อมูลด้วย AI (AI data cleaning)

คำถามที่พบบ่อย

แหล่งข้อมูลความจริงหนึ่งเดียว (single source of truth) คืออะไร?

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

ฉันจำเป็นต้องมีคลังข้อมูล (data warehouse) เพื่อสร้างสิ่งนี้หรือไม่?

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

ทำไมรายงานสองฉบับถึงแสดงยอดรวมไม่เท่ากัน?

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

ใครควรเป็นผู้รับผิดชอบนิยามของตัวชี้วัด?

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

ควรทบทวนนิยามบ่อยแค่ไหน?

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