Guides กลยุทธ์ดิจิทัล

Data Readiness: ต้องเตรียมข้อมูลอย่างไรก่อนทำ Dashboard, BI หรือ AI

คู่มือเตรียมข้อมูลก่อนทำ Dashboard, BI หรือ AI ตั้งแต่คำถามธุรกิจ เจ้าของข้อมูล นิยาม ตัวชี้วัด คุณภาพ lineage สิทธิ์เข้าถึง ไปจนถึงเกณฑ์พร้อมใช้งาน

ทีมงานตรวจสอบตารางข้อมูลและกราฟบนหน้าจอ เพื่อเตรียมข้อมูลให้พร้อมสำหรับ Dashboard, BI และ AI

START HERE

ทำความเข้าใจหัวข้อนี้ก่อนเริ่ม

ความหมาย: Data Readiness หรือความพร้อมของข้อมูลคือระดับที่ข้อมูลเหมาะและเพียงพอสำหรับงานหนึ่งงานที่ระบุไว้ เช่น Dashboard, BI หรือ AI โดยทีมรู้แหล่งที่มา เจ้าของ ความหมาย คุณภาพ วิธีเชื่อม สิทธิ์ และข้อจำกัดของข้อมูล ความพร้อมจึงไม่ได้แปลว่าข้อมูลทุกชุดต้องสมบูรณ์ หรือข้อมูลชุดเดียวจะพร้อมสำหรับทุกวัตถุประสงค์
อธิบายเพิ่มเติม: Data Readiness ไม่ได้แปลว่าต้องมีข้อมูลสมบูรณ์ทั้งหมด แต่ต้องรู้ว่าข้อมูลใดตอบคำถามธุรกิจ แหล่งใดเป็นระบบหลักที่ถือข้อมูลจริง (system of record) ใครเป็นเจ้าของ นิยามตัวเลขตรงกันหรือไม่ เชื่อมข้อมูลด้วยรหัสใด และข้อจำกัดใดต้องบอกผู้ใช้ หากเป็น AI ต้องเพิ่มการตรวจความเป็นตัวแทน ความเป็นส่วนตัว ความเอนเอียง และวิธีประเมินผลลัพธ์ตามความเสี่ยง
ตัวอย่าง: ตัวอย่างเช่น Dashboard รายได้ต้องตกลงก่อนว่าใช้ยอดสั่งซื้อ ยอดออกใบแจ้งหนี้ หรือยอดรับเงินจริง จากนั้นเชื่อมเลขลูกค้าและวันที่จาก CRM กับระบบบัญชี ตรวจรายการยกเลิกและข้อมูลซ้ำ ระบุผู้อนุมัตินิยาม และเทียบยอดรวมกับบัญชีก่อนเปิดให้ผู้บริหารใช้

ผลลัพธ์ที่คุณจะได้

คุณจะได้หลักฐานความพร้อมของข้อมูลสำหรับหนึ่ง Dashboard, BI หรือ AI Use case โดยระบุคำถาม แหล่ง เจ้าของ นิยาม คุณภาพ การเชื่อม Lineage สิทธิ์ และข้อจำกัดที่ผู้ใช้ต้องรู้

SCOPE

ขอบเขตของคู่มือนี้

เหมาะสำหรับ

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

ยังไม่เหมาะเมื่อ

ยังไม่มี Use case หรือผู้ใช้ปลายทางชัดเจน หรือกำลังพยายามทำความสะอาดข้อมูลทั้งองค์กรโดยไม่มีเกณฑ์ว่าอะไรคือข้อมูลที่เหมาะกับการใช้

BEFORE YOU START

สิ่งที่ควรเตรียมให้พร้อม

คำถามและการตัดสินใจ

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

เจ้าของข้อมูลอนุญาตให้ใช้ Sample ที่ปลอดภัยและเป็นตัวแทนสำหรับ Profile และทดสอบ
เจ้าของนิยามและระบบต้นทาง

มีผู้ตอบได้ว่าค่าแต่ละตัวหมายถึงอะไรและเกิดจากกระบวนการใด

STEP BY STEP

ขั้นตอนการลงมือทำ

กำหนดคำถามและระดับรายละเอียด

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

ผู้รับผิดชอบ
เจ้าของ Use case

ผลลัพธ์ที่ต้องได้
Use-case brief และ Acceptance questions

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

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

ผู้รับผิดชอบ
Data owner

ผลลัพธ์ที่ต้องได้
Source and ownership map

วิธีตรวจสอบ
ทุก Metric สำคัญย้อนกลับไปยังแหล่งและผู้รับผิดชอบได้หนึ่งเส้นทาง
ตกลงนิยามทางธุรกิจ

สร้างพจนานุกรมข้อมูล ระบุความหมาย สูตร หน่วย ช่วงเวลา และระดับรายละเอียดของแต่ละแถว (grain) ให้เจ้าของธุรกิจและข้อมูลอนุมัติ

ผู้รับผิดชอบ
เจ้าของกระบวนการและ Analyst

ผลลัพธ์ที่ต้องได้
Metric or feature dictionary

วิธีตรวจสอบ
ผู้ใช้สองทีมคำนวณจาก Sample เดียวกันแล้วได้ความหมายและผลตรงกัน
วัดคุณภาพตามความเสียหายของ Use case

Profile Completeness, Accuracy, Consistency, Timeliness, Validity และ Uniqueness เฉพาะฟิลด์สำคัญ พร้อมตั้ง Threshold ตามผลกระทบ ไม่ใช่ต้องสมบูรณ์ทุกค่า

ผู้รับผิดชอบ
Data steward

ผลลัพธ์ที่ต้องได้
Quality profile, threshold และ Issue list

วิธีตรวจสอบ
ทุกปัญหาถูกจัดเป็น Blocker, Disclosed limitation หรือ Improvement พร้อมเจ้าของ
ทดสอบการเชื่อมและระดับข้อมูล

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

ผู้รับผิดชอบ
Data engineer หรือ Analyst

ผลลัพธ์ที่ต้องได้
ผลทดสอบการเชื่อมและบันทึกการกระทบยอด

วิธีตรวจสอบ
ยอดรวมและจำนวนรายการก่อน/หลัง Join อธิบายความต่างได้ภายใน Threshold
บันทึกที่มาและการเปลี่ยนแปลง

บันทึกเส้นทางข้อมูลตั้งแต่ต้นทาง ผ่านการแปลง จนถึงรายงานหรือโมเดล (data lineage) พร้อมเจ้าของ รุ่น และวิธีตรวจย้อนกลับเมื่อผลลัพธ์ผิดปกติ

ผู้รับผิดชอบ
ทีมข้อมูล

ผลลัพธ์ที่ต้องได้
Lineage diagram และ Transformation log

วิธีตรวจสอบ
เลือกหนึ่งตัวเลขหรือคำตอบแล้วตามกลับไปยัง Record ต้นทางและกฎแปลงได้
กำหนดสิทธิ์ Retention และการรับการเปลี่ยนแปลง

กำหนดผู้ดู/แก้/ส่งออก ระยะเก็บ การ Mask/ลบ และวิธีแจ้งเมื่อ Schema, Definition หรือ Source เปลี่ยน พร้อมเจ้าของอนุมัติ

ผู้รับผิดชอบ
เจ้าของข้อมูลและ Security/Privacy

ผลลัพธ์ที่ต้องได้
Access matrix, retention decision และ Change rule

วิธีตรวจสอบ
ทดสอบสิทธิ์ผู้ใช้ตัวแทนและจำลองการเปลี่ยนหนึ่งฟิลด์แล้ว Alert/Owner ทำงานตามกติกา

IF / THEN

เงื่อนไขที่ทำให้เส้นทางเปลี่ยน

ถ้าฟิลด์สำคัญไม่ผ่าน Threshold และทำให้ตัดสินใจผิด ให้หยุดการใช้และกลับไปแก้ที่ Source หรือจำกัด Scope ไปยังขั้นตอนที่เกี่ยวข้อง
ถ้าจำนวนหรือยอดรวมเปลี่ยนหลัง Join โดยอธิบายไม่ได้ ห้ามสร้าง Report/Model ต่อจนกว่าจะพิสูจน์ Cardinality และ Duplicate ไปยังขั้นตอนที่เกี่ยวข้อง

ความพร้อมต่างกันตามสิ่งที่จะสร้าง

Dashboard

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

BI

นอกจากรายงาน ต้องมีกติกากลางที่ทำให้หลายทีมใช้ความหมายและสูตรเดียวกัน รองรับการเจาะดูรายละเอียด และควบคุมสิทธิ์ตามบทบาท

AI

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

ตัวอย่าง: Dashboard รายได้

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

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

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

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

SUCCESS SIGNALS

ตัวชี้วัดว่าทำสำเร็จ

ฟิลด์สำคัญผ่าน Threshold

ฟิลด์ที่มีผลต่อการตัดสินใจผ่านเกณฑ์ หรือมีข้อจำกัดที่ผู้ใช้เห็นและยอมรับอย่างชัดเจน

แหล่งตรวจวัด: Quality profile

การกระทบยอดอธิบายได้

Sample output กระทบยอดกับ Source ภายในเกณฑ์และอธิบาย Missing/Duplicate ได้

แหล่งตรวจวัด: Reconciliation record

ปัญหามีเจ้าของและเวลาแก้

ทุก Blocker และ Improvement มีเจ้าของ ลำดับความสำคัญ วันติดตาม และสถานะที่ตรวจได้

แหล่งตรวจวัด: Issue register

COMPLETION CHECK

ตรวจว่าคู่มือนี้เสร็จสมบูรณ์

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

NEXT ACTION

ขั้นตอนต่อไป

สร้าง Pilot ขนาดเล็กด้วย Data contract นี้ แล้วติดตามทั้งผลลัพธ์ทางธุรกิจและ Data-quality incidents ก่อนเพิ่มแหล่งข้อมูล ผู้ใช้ หรือความอัตโนมัติ

SOURCES / VERIFIED REFERENCES

แหล่งอ้างอิง

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

The Government Data Quality Framework — GOV.UK (เปิดในแท็บใหม่) Government · ตรวจสอบล่าสุด 4 ก.ย. 2569
NIST AI Resource Center (เปิดในแท็บใหม่) Government · ตรวจสอบล่าสุด 4 ก.ย. 2569

NEXT STEP / ROADMAP

ยังไม่แน่ใจว่าธุรกิจควรเริ่มจากระบบใด?

ตอบคำถามสั้น ๆ เพื่อมองเห็นจุดเริ่มต้นและลำดับถัดไปของ Digital Roadmap ที่เหมาะกับบริบทธุรกิจของคุณ

วาง Roadmap ธุรกิจของคุณ

ทำความเข้าใจหัวข้อนี้ก่อนเริ่ม

ผลลัพธ์ที่คุณจะได้

ขอบเขตของคู่มือนี้

เหมาะสำหรับ

ยังไม่เหมาะเมื่อ

สิ่งที่ควรเตรียมให้พร้อม

คำถามและการตัดสินใจ

สิทธิ์เข้าถึงตัวอย่างข้อมูล

เจ้าของนิยามและระบบต้นทาง

ขั้นตอนการลงมือทำ

กำหนดคำถามและระดับรายละเอียด

ระบุแหล่งและเจ้าของข้อมูล

ตกลงนิยามทางธุรกิจ

วัดคุณภาพตามความเสียหายของ Use case

ทดสอบการเชื่อมและระดับข้อมูล

บันทึกที่มาและการเปลี่ยนแปลง

กำหนดสิทธิ์ Retention และการรับการเปลี่ยนแปลง