Case Study: กู้ 87 Interface สปาเกตตี้ด้วยสถาปัตยกรรม ISA-95 — จากตัวเลขไม่ตรงกันสู่แหล่งความจริงเดียว

กรณีศึกษาจากงานติดตั้งจริงของทีม System Integration หลายโครงการในโรงงานอุตสาหกรรมไทย — รายละเอียดบางส่วนปรับปรุงเพื่อความเป็นส่วนตัวของลูกค้า

จุดเริ่มต้น: ไฟล์ Excel หนึ่งไฟล์ที่ไม่มีใครกล้าแตะ

โรงงานผลิตชิ้นส่วนแห่งหนึ่งที่ทีม Honey Corporation เข้าไปช่วย มี “อนุสาวรีย์” อยู่บนเครื่องคอมพิวเตอร์ของหัวหน้าแผนกผลิต — ไฟล์ Excel เก็บรายชื่อ interface ระหว่างระบบ ทั้งหมด 87 รายการ เชื่อมระบบเก็บข้อมูลการผลิต ระบบบริหารจัดการวัตถุดิบ ระบบซื้อ ระบบคลัง และหน้าจอเฝ้าระวังสายการผลิต แทบทุกคู่ บางเส้นวาดตั้งแต่สมัยที่ยังไม่มีใครในทีมปัจจุบันเกิดด้วยซ้ำ

อาการที่โรงงานเจอก่อนมาหาเราคือคลาสสิกสุดๆ ของงานอินทิเกรชันแบบ point-to-point: ตัวเลขบนหน้าจอเฝ้าระวังกับตัวเลขในรายงานสิ้นวันไม่ตรงกัน ทีมไอทีโทษเครื่องจักร ทีมผลิตโทษระบบไอที ไม่มีใครหาต้นตอเจอเพราะทุก interface ถูกเขียนขึ้นคนละยุค คนละมาตรฐาน และคนละสไตล์

ทำไมเรื่องนี้ถึงเกิดซ้ำๆ ทุกโรงงาน: จุดบอดของ “เส้นเชื่อม”

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

ทางออกที่วงการอุตสาหกรรมทั่วโลกใช้คือ มาตรฐาน ISA-95 (หรือ IEC 62264) ซึ่งไม่ใช่ซอฟต์แวร์ แต่คือชุดข้อกำหนดที่แบ่งโรงงานเป็นชั้นๆ พร้อมนิยามข้อมูลที่แลกเปลี่ยนกันระหว่างชั้นให้ชัดเจน ทำให้ทุกระบบพูด “ภาษาเดียวกัน” โดยไม่ต้องเขียน interface เฉพาะทีละคู่

หัวใจของการแก้ปัญหาอยู่ที่รอยต่อระหว่าง Level 3 กับ Level 4 นั่นเอง — จุดที่ “แผน” ต้องกลายเป็น “คำสั่งผลิต” และ “ผลลัพธ์จริง” ต้องไหลกลับไปเป็น “ตัวเลขธุรกิจ”

6 ขั้นตอนที่เราใช้แก้งานนี้จริง

ขั้นที่ 1: ทำแผนที่ interface เดิมทั้งหมด ก่อนแตะอะไร

เราใช้เวลานานที่สุดในขั้นนี้ ไม่ใช่เขียนโค้ด — แต่ไล่สัมภาษณ์เจ้าของระบบทีละเส้น ว่าใครส่งใครรับ ความถี่เท่าไร และ “ถ้าเส้นนี้หายไปพรุ่งนี้ ใครจะรู้ตัวก่อน” ผลคือพบว่าจาก 87 เส้นเดิม มี 23 เส้นที่ไม่มีใครใช้แล้วจริง เหลือเพียง 64 เส้นที่มีชีวิต บทเรียนสำคัญ: อย่าเพิ่มก่อนลด

ขั้นที่ 2: ตั้ง “ผู้ดูแลข้อมูล” ให้ชัดทุกฝั่ง

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

ขั้นที่ 3: ทยอยย้ายเส้นเชื่อมไปบน “สันหลังข้อมูล” กลาง

แทนที่จะเขียน interface ใหม่ 64 เส้น เราวางช่องทางกลางที่ทุกระบบมาเฝ้าฟังและเผยแพร่ข้อมูล จำนวนจุดเชื่อมลดจาก 64 เหลือเท่าจำนวนระบบ ความซับซ้อนลดแบบทันตา

ขั้นที่ 4: ออกแบบ payload ตามนิยามมาตรฐาน

เราออกแบบโครงสร้างข้อมูลที่แลกเปลี่ยนตามแนวทาง ISA-95 — ทั้งคำสั่งผลิต ข้อมูลหลักบุคลากร ความสามารถเครื่องจักร และผลการผลิตย้อนกลับ ชุดข้อกำหนดแบบเปิดเหล่านี้ช่วยให้ทุกฝ่ายเห็นภาพเดียวกันตั้งแต่ก่อนเขียนโค้ดบรรทัดแรก

ขั้นที่ 5: ทยอยย้ายทีละเส้น พร้อมแผนกู้คืน

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

ขั้นที่ 6: วัดผลและส่งต่อการดูแล

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

ผลลัพธ์: ตัวเลขที่เปลี่ยนไปหลัง 9 เดือน

• จำนวน interface ที่ต้องดูแล ลดจาก 87 เหลือ 6 ช่องทางมาตรฐาน (ตามจำนวนระบบ) — พื้นที่เสี่ยงพังลดลงกว่า 90%
• เวลาปิดยอดผลผลิตรายวัน จากเดิมราว 90 นาทีเพราะต้องเทียบตัวเลขด้วยมือ เหลือประมาณ 15 นาที
• ความขัดแย้งเรื่องตัวเลข ระหว่างแผนกแทบหายไป เพราะทุกคนอ้างอิงแหล่งเดียวกัน
• การเพิ่มระบบใหม่ เมื่อโรงงานติดตั้งระบบตรวจสอบคุณภาพเพิ่ม ใช้เวลาเชื่อมต่อเพียงไม่กี่วัน แทนที่จะเป็นโครงการของตัวเองอีกหลายเดือน

สิ่งที่ประทับใจเราที่สุดไม่ใช่เทคโนโลยี แต่คือวันที่หัวหน้าแผนกผลิตบอกว่า “ตอนนี้ผมเปิดหน้าจอเดียวแล้วจบ ไม่ต้องเปิดสี่จอมาเทียบกันเองอีกแล้ว” — วิศวกรอาวุโส ฝ่ายบริการของ Honey Corporation

บทเรียนสำหรับโรงงานที่กำลังจะเริ่ม

• ปัญหา interface คือปัญหาองค์กร ไม่ใช่เทคโนโลยี — ตั้งเจ้าของข้อมูลให้ชัดก่อน แล้วเทคโนโลยีจะง่ายขึ้นเอง
• ตัวเลขที่ไม่ตรงกันมักมีต้นตอที่การปัดเศษและหน่วยวัด — อย่าเพิ่งโทษระบบ ให้ไล่ที่นิยามข้อมูลก่อนเสมอ
• รันขนานก่อนตัดเส้นเดิมเสมอ — งบและเวลาที่ลงไปกับการรันขนานถูกกว่าความเสียหายจากข้อมูลพลาดระหว่างเปลี่ยนผ่านเสมอ
• เลือกมาตรฐานเปิด — ความสามารถในการเปลี่ยนผู้ให้บริการหรือเพิ่มระบบใหม่ในอนาคตมีค่ามากกว่าฟีเจอร์เด็ดๆ ของระบบปิดใดๆ