สถาปัตยกรรมองค์กร ตอนที่ 3: ข้อมูลหลักต้องมีที่เดียว และมีเจ้าของ

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

ข้อมูลเป็นทรัพย์สิน ต้องมีเจ้าของ

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

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

เริ่มจากการกำกับดูแลข้อมูล

ตำราเทียบมาตรฐานสามตัว คือ TOGAF สำหรับภาพรวมสถาปัตยกรรม DMBOK สำหรับรายละเอียดการจัดการข้อมูลแต่ละด้าน และ COBIT สำหรับธรรมาภิบาลไอที ทั้งสามทับซ้อนกันอยู่ตรง การกำกับดูแลข้อมูล (data governance) ผมจึงแนะนำให้โรงงานเริ่มจากตรงนี้ ไม่ต้องรอนำมาตรฐานทั้งเล่มมาใช้

นิยามสิ่งที่ธุรกิจสนใจก่อนออกแบบฐานข้อมูล

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

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

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

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

เก็บข้อมูลที่ไหน

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

ผมใช้หลักนี้ทั้งที่ฟาร์มและในโรงงาน ที่ฟาร์มบ้านรักผัก ข้อมูลดิบทุก 10 วินาทีเก็บที่เครื่อง edge ในบ้าน คลาวด์เก็บเฉพาะสิ่งที่ต้องดูจากนอกบ้าน ในโรงงาน ข้อมูลการผลิตอยู่บนเซิร์ฟเวอร์ภายใน และ AI ก็รันบนเครื่องภายใน

ห้าขั้นเริ่มต้นในโรงงาน

1. ทำรายการข้อมูลหลัก ที่หลายระบบใช้ร่วมกัน ส่วนใหญ่ไม่เกิน 10 เรื่อง เช่น เครื่องจักร สินค้า กระบวนการ พนักงาน ลูกค้า
2. ตั้งเจ้าของทีละเรื่อง เป็นชื่อคนหรือตำแหน่ง ไม่ใช่ชื่อแผนก
3. แก้ที่ต้นทางที่เดียว ระบบอื่นอ่านผ่าน API หรือดึงไปตามรอบ
4. วัดคุณภาพข้อมูลเป็นตัวเลข เช่น จำนวนรหัสที่ไม่มีในทะเบียน แล้วรายงานทุกเดือน
5. ย้ายข้อมูลจากระบบเก่าทีละชุด และตรวจคุณภาพทั้งก่อนและหลังย้าย

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

ตอนที่ 4 เป็นเรื่องชั้นเทคโนโลยี การจัดการการเปลี่ยนแปลง และธรรมาภิบาล พร้อมแผนปีแรกสำหรับโรงงาน

อ้างอิง

ดนัยรัฐ ธนบดีธรรมจารี และ วรัญญา ปุณณวัฒน์. (2565). การออกแบบสถาปัตยกรรมองค์กร. ใน ประมวลสาระชุดวิชาการจัดการเทคโนโลยีดิจิทัลเชิงกลยุทธ์. สำนักพิมพ์มหาวิทยาลัยสุโขทัยธรรมาธิราช. ISBN 978-616-16-2818-5

DAMA International. DAMA-DMBOK: Data Management Body of Knowledge. https://www.dama.org

The Open Group. The TOGAF Standard. https://www.opengroup.org/togaf

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