โรงงานแห่งหนึ่งลงทุนระบบ Dashboard ผู้บริหารระดับหลักล้าน ดึงข้อมูลจากทุกฝ่ายมารวมกัน แล้วเกิดเรื่องที่ทุกคนเคยเจอ: หน้าจอแรกที่เปิดขึ้นมา ยอด “สินค้าเสีย” ของเดือนเดียวกันจากสองฝ่ายไม่เท่ากัน ประชุมสามชั่วโมงกลายเป็นการถกเถียงว่าตัวเลขไหน “ถูก” — คำตอบที่เจ็บที่สุดคือ ไม่มีตัวไหนถูก และไม่มีตัวไหนผิดด้วย เพราะทั้งคู่ตั้งต้นจาก Master Data คนละชุด
นี่คือเหตุผลที่โครงการ Data & Platform ของโรงงานส่วนใหญ่ล้มเหลวไม่ใช่เพราะเทคโนโลยี แต่เพราะไม่มีใครดูแล “ต้นทางความจริง” (Source of Truth) ของข้อมูลพื้นฐาน

Master Data ในโรงงานคืออะไร
Master Data คือข้อมูลหลักที่ไม่ค่อยเปลี่ยนแต่ถูกอ้างอิงทุกที่: รหัสและชื่อวัตถุดิบ, รหัสเครื่องจักร, โครงสร้าง BOM (Bill of Materials), รหัสลูกค้า/ผู้ขาย, หน่วยนับ, และลำดับขั้นกระบวนการผลิต (Routing) ข้อมูลเหล่านี้ต่างจาก Transaction Data (Order, ผลผลิต, Alarm) ตรงที่เปลี่ยนทีเดียวกระทบทุกระบบที่อ้างถึงมัน
ตัวเลขที่องค์กรทั่วโลกเจอเหมือนกัน: งานสำรวจ State of Data Science ของ Anaconda พบว่าทีมข้อมูลใช้เวลาถึง 45% ไปกับการเตรียมและล้างข้อมูล ก่อนจะวิเคราะห์อะไรได้เลย และ Gartner ประเมินว่าคุณภาพข้อมูลที่ต่ำทำให้องค์กรเสียเงินเฉลี่ย 12.9 ล้านดอลลาร์สหรัฐต่อปี ในโรงงาน ต้นทุนที่มองไม่เห็นนี้มาในรูปของพนักงานที่เสียเวลากรองตัวเลขซ้ำ, สต็อกที่ผิดเพราะ BOM ไม่ตรง, และการตัดสินใจที่ช้าเพราะไม่มีใครเชื่อ Dashboard
อาการของโรงงานที่ Master Data มีปัญหา
| อาการที่เห็นหน้างาน | ต้นเหตุที่ Master Data |
|---|---|
| สองฝ่ายรายงานยอดของเดือนเดียวกันไม่ตรงกัน | นิยาม/รหัสสินค้าเสียคนละชุด |
| ตัดสต็อกวัตถุดิบไม่ตรงบ่อยครั้ง | BOM หลายเวอร์ชัน ไม่มีฉบับหลัก |
| Trace งานเสียย้อนหลังเกิน 1 วัน | รหัส Lot ไม่เป็นมาตรฐานเดียวกันทุกสถานี |
| Dashboard ผู้บริหารถูกท้าทายทุกครั้งที่ประชุม | ไม่มี Source of Truth — ทุกรายงานคำนวณจากฐานต่างกัน |
| AI ทำนายความต้องการออกมาเพี้ยน | ข้อมูลอดีตผสมหน่วยนับ/รหัสที่เปลี่ยนไปตามกาลเวลา |
ทางออก: ครอบคลุม 4 เรื่อง ไม่ต้องซื้ออะไรก่อนก็เริ่มได้
- กำหนด Golden Record: เลือกว่ารหัสวัตถุดิบ/เครื่องจักร “ฉบับจริง” อยู่ที่ระบบใด (มักเป็น ERP สำหรับวัตถุดิบ และระบบบำรุงรักษาสำหรับเครื่องจักร) แล้วให้ระบบอื่น ๆ เป็นผู้ตาม ไม่ใช่สร้างของตัวเอง
- ตั้ง Data Owner ที่เป็นคน ไม่ใช่ฝ่าย IT: เจ้าของรหัสวัตถุดิบคือฝ่ายจัดซื้อหรือ QC เจ้าของ BOM คือฝ่ายวิศวกรรม — IT เป็นผู้ให้เครื่องมือ ไม่ใช่ผู้ตัดสินว่าข้อมูลไหนถูก
- ทำ Data Quality Rule ตรวจอัตโนมัติ: เช่น รหัสใหม่ต้องผ่านการอนุมัติก่อนใช้, ตรวจหาคู่ที่เหมือนกัน (Duplicate) ทุกสัปดาห์, หน่วยนับต้องอยู่ในพจนานุกรมที่กำหนด
- เปลี่ยนข้อมูลผ่านกระบวนการเดียว: สร้าง Change Request สำหรับการแก้ Master Data — ห้ามแก้ตรง ๆ ในฐานข้อมูล เพราะการแก้ลับของคนหนึ่งคือความเสียหายของอีกหลายระบบ

จากประสบการณ์ติดตั้งระบบ IoT และ Dashboard ให้โรงงานอุตสาหกรรม ทีมงาน Honey Corporation พบว่าโครงการที่ราบรื่นที่สุดไม่ใช่โครงการที่เทคโนโลยีล้ำสุด แต่คือโครงการที่คู่ค้านิยาม “ตัวเลขอะไรคือความจริง” ได้ตกลงกันตั้งแต่วันแรก — เราจึงเริ่มทุกโครงการด้วยการทำ Data Dictionary ร่วมกับลูกค้าเสมอ ก่อนเขียนโค้ดบรรทัดแรก
Key Takeaways
- ปัญหาตัวเลขไม่ตรงกันส่วนใหญ่ไม่ใช่ Bug แต่เป็น Master Data คนละชุด — แก้ที่ต้นเหตุถูกกว่าแก้ที่ Dashboard
- ทีมข้อมูลเสียเวลา 45% กับการล้างข้อมูล (Anaconda) และคุณภาพข้อมูลต่ำเสียเงินเฉลี่ย 12.9 ล้านดอลลาร์/ปี (Gartner)
- Master Data ของโรงงาน 5 ชุดหลัก: วัตถุดิบ, เครื่องจักร, BOM, ลูกค้า/ผู้ขาย, หน่วยนับ+Routing
- เริ่มได้ทันทีโดยไม่ต้องลงทุนใหม่: กำหนด Golden Record, ตั้ง Data Owner, ทำ Quality Rule, บังคับ Change Request
- Data Owner ต้องเป็นเจ้าของธุรกิจ (จัดซื้อ/QC/วิศวกรรม) ไม่ใช่ฝ่าย IT
- โครงการ AI/Dashboard ทุกชิ้นจะได้ผลเร็วขึ้นมากถ้า Master Data ถูกจัดการก่อน — นี่คือพื้นฐานที่ถูกที่สุดและมักถูกมองข้ามที่สุด
Honey Corporation พร้อมให้คำปรึกษา
ทีมงานของเรามีความเชี่ยวชาญด้านการออกแบบโครงสร้างข้อมูลและระบบ Dashboard สำหรับโรงงานอุตสาหกรรม พร้อมออกแบบและติดตั้งระบบให้เหมาะกับธุรกิจของคุณ
📞 โทร: 09-23242995 | อีเมล: support@honey.co.th
เว็บไซต์: www.honey.co.th
