พัฒนาระบบบริหารการผลิตแบบ Custom สำหรับโรงงานในไทย

เมื่อโรงงานในประเทศไทยพิจารณา พัฒนาระบบบริหารการผลิตแบบ Custom คำถามแรกไม่ควรเป็น “ใช้แพ็กเกจหรือเขียนใหม่” แต่ควรกำหนดก่อนว่างานใดควรทำให้เป็นมาตรฐาน ความสามารถใดสร้างความได้เปรียบ และขอบเขตความรับผิดชอบข้อมูลของ ERP, MES และเครื่องจักรอยู่ตรงไหน หากขอบเขตเหล่านี้ยังคลุมเครือ ผู้เสนอราคาแต่ละรายจะตีความงานคนละแบบ ทำให้เปรียบเทียบราคาและกำหนดการไม่ได้อย่างเป็นธรรม

บทความนี้จัดทำสำหรับผู้รับผิดชอบการจัดหาระบบบริหารการผลิตของโรงงานในไทย ครอบคลุมการตัดสินใจระหว่างแพ็กเกจ การปรับแต่ง และการพัฒนาเฉพาะ การจัดทำ RFP การใช้ ISA-95 เพื่อแบ่งขอบเขตความต้องการ การย้ายข้อมูล การตรวจรับ การส่งมอบซอร์สโค้ดและงานปฏิบัติการ การเปรียบเทียบ TCO ตลอดจนการทำ Discovery 90 วันและติดตั้งเป็นระยะ บทความไม่ได้แนะนำผลิตภัณฑ์หรือวิธีพัฒนาใดเป็นคำตอบสากล แต่ช่วยเปลี่ยนข้อจำกัดหน้างาน เงื่อนไขการสนับสนุน กฎหมาย และความปลอดภัยให้เป็นหลักฐานที่ใช้เปรียบเทียบได้

การพัฒนาระบบบริหารการผลิตแบบ Custom คืออะไร

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

ส่วนแพ็กเกจคือการปรับกระบวนการขององค์กรให้เข้ากับมาตรฐานในผลิตภัณฑ์ การปรับแต่งคือการคงมาตรฐานไว้แล้วเติมช่องว่างด้วยการตั้งค่า ส่วนขยาย Add-on หรือบริการภายนอก โครงการจริงมักเป็นแบบผสม เช่น ERP เป็นแพ็กเกจ ระบบดำเนินการผลิตเป็นแอปเฉพาะ และการเก็บข้อมูลเครื่องจักรใช้แพลตฟอร์มเดิม ดังนั้นเจ้าของฟังก์ชันและข้อมูลสำคัญกว่าชื่อของวิธีพัฒนา

เมื่อใดควรพิจารณาพัฒนาแบบ Custom

การพัฒนาเฉพาะหรือการปรับแต่งขนาดใหญ่มีเหตุผลเมื่อมีหลายเงื่อนไขต่อไปนี้พร้อมกัน

• ลำดับกระบวนการ ข้อจำกัดการปล่อยงาน การรวมล็อต การเปลี่ยนรุ่น การจ้างช่วง หรือการตัดสินผลตรวจเป็นความได้เปรียบของบริษัท
• การผลิตหลายรุ่นจำนวนน้อย การผลิตตามสั่ง หรือกระบวนการต่อเนื่องไม่ตรงกับสมมติฐานของแพ็กเกจ
• ต้องกำหนดขอบเขตข้อมูลที่สม่ำเสมอระหว่าง ERP, WMS, QMS, ระบบบำรุงรักษา PLC และเครื่องมือวัด
• ภาษาไทย ขั้นอนุมัติ กะการทำงาน และข้อจำกัดเครื่องจักรเป็นเงื่อนไขสำคัญของงานประจำวัน
• ต้นทุนการเปลี่ยนวิธีทำงานเพื่อให้เข้ากับระบบมาตรฐานสูงกว่าการพัฒนาความแตกต่างที่จำเป็น
• องค์กรต้องการปรับปรุงระบบตามลำดับความสำคัญของตนและกำกับซอร์สกับแบบจำลองข้อมูลระยะยาว

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

เมื่อใดแพ็กเกจระบบบริหารการผลิตเหมาะกว่า

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

ฟังก์ชันที่แสดงใน Demo ยังไม่ใช่หลักฐานเพียงพอ ต้องยืนยันว่าใช้ได้ในเวอร์ชันและสัญญาที่เสนอ ต้องตั้งค่าหรือเขียนโค้ดหรือไม่ และส่วนขยายยังใช้ได้เมื่ออัปเกรดหรือไม่ ให้ตัดสินจาก Requirement ID และรายการ Gap ไม่ใช่ชื่อผลิตภัณฑ์

ตารางตัดสินใจ: แพ็กเกจ การปรับแต่ง หรือพัฒนาใหม่

ไม่ควรตัดสินทั้งระบบแบบทางเลือกเดียว ควรเปรียบเทียบแยกตามโดเมน เช่น มาสเตอร์สินค้าและลูกค้าอยู่ใน ERP การติดตาม WIP อยู่ใน MES และอัลกอริทึมผสมสูตรเฉพาะอยู่ในแอปแยก

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

กำหนดขอบเขตการปรับแต่งระบบบริหารการผลิตก่อน

การปรับแต่งดูเหมือนเป็นทางสายกลาง แต่ถ้าขอบเขตไม่ชัดอาจกลายเป็นทางที่ซับซ้อนที่สุด การแก้ Core ของผลิตภัณฑ์โดยตรงอาจต้องนำส่วนต่างกลับมาใช้และทดสอบ Regression ทุกครั้งที่อัปเกรด ควรเลือกการตั้งค่า Public API, Event, Extension Table หรือ External Service ที่ผลิตภัณฑ์รองรับก่อน

ใน RFP ให้ผู้เสนอราคาตอบทุก Requirement ดังนี้

1. เป็นฟังก์ชันมาตรฐานหรือไม่ พิสูจน์ด้วยเวอร์ชันและการตั้งค่าใด
2. เป็นการตั้งค่า Low-code หรือ Custom code
3. แก้ Core ของผลิตภัณฑ์หรือไม่ และควบคุมส่วนต่างอย่างไร
4. ใครตรวจความเข้ากันได้เมื่ออัปเกรด และใครรับค่าใช้จ่าย
5. หากส่วนขยายหยุดทำงาน ธุรกิจดำเนินต่ออย่างไร
6. ส่งออกข้อมูลที่เกี่ยวข้องในรูปแบบที่มีเอกสารได้หรือไม่

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

ใช้ ISA-95 แบ่งขอบเขต ERP, MES และเครื่องจักร

ISA-95 เป็นชุดมาตรฐานสากลสำหรับการบูรณาการระดับองค์กร โลจิสติกส์ ปฏิบัติการผลิต และการควบคุม คำอธิบายทางการของ ISA แบ่ง Level 0 เป็นกระบวนการกายภาพ Level 1 เป็นการตรวจจับและกระทำต่อกระบวนการ Level 2 เป็นการติดตามและควบคุม Level 3 เป็นการบริหารปฏิบัติการผลิต และ Level 4 เป็นการวางแผนธุรกิจและโลจิสติกส์ โดยเน้น Interface ระหว่าง Level 3 กับ 4 เป็นพิเศษ ISA-95 ไม่ใช่ตารางเลือกผลิตภัณฑ์ แต่เป็นแบบอ้างอิงให้ทีมใช้ภาษาเดียวกันเรื่องกิจกรรม ข้อมูล และความรับผิดชอบ

สำหรับการจัดหาระบบบริหารการผลิต สามารถใช้แบ่งขอบเขตได้ดังนี้

ห้ามให้สองระบบเป็น System of Record อิสระสำหรับแนวคิดเดียวกัน หาก MES และ ERP คำนวณสต็อกแยกกันแล้วแก้ส่วนต่างตอนกลางคืน การกู้คืนและการตรวจสอบจะซับซ้อน สำหรับข้อมูลแต่ละชนิดต้องกำหนดระบบหลัก สำเนาอ่านอย่างเดียว สิทธิ์แก้ ความถี่ Sync, Retry, Deduplication, Reconciliation และเจ้าของการแก้มือ

Interface Contract ต้องมีอะไร

ชื่อ API อย่างเดียวไม่ใช่ข้อกำหนด Interface ต้องบันทึกผู้ส่ง ผู้รับ Business Event ฟิลด์ หน่วย Code set เวลา ลำดับ Retry, Timeout, Deduplication, Error notification, Recovery และเจ้าของ Monitoring

เมื่อโรงงานไทยแลกข้อมูลวันเวลากับสำนักงานใหญ่ญี่ปุ่น ต้องกำหนด Time zone เวลา Server เวลาแสดงในประเทศ และ Cut-off การปิดงวด ปริมาณต้องมี Base unit, Display unit, Precision และ Rounding แยก ID ที่ไม่เปลี่ยนจากชื่อแสดงหลายภาษาของสินค้า กระบวนการ เครื่องจักร และล็อต

GS1 Global Traceability Standard ใช้หลัก Identify–Capture–Share และครอบคลุม Event กับข้อมูลตลอดวงจรของสิ่งที่ติดตาม เอกสาร Traceability ของ GS1 ยังอธิบายแนวคิด Critical Tracking Events และ Key Data Elements แม้โรงงานไม่จำเป็นต้องใช้ GS1 ก็สามารถนำคำถามว่า “อะไร เกิดเหตุการณ์ใด เมื่อใด ที่ไหน และต้องเก็บข้อมูลอะไร” ไปใช้ใน RFP ได้

ทำ RFP ให้เป็นข้อตกลงการทำงานที่ตรวจรับได้ ไม่ใช่รายการหน้าจอ

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

โครงสร้าง RFP ที่แนะนำ

เขียน Requirement แบบใคร–เมื่อใด–ทำอะไร–ภายใต้เงื่อนไขใด

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

เชื่อม Requirement ID กับ Scenario, Priority, Rationale, Owner, Realization type, Design, Test ID และ Result เมื่อเปลี่ยนข้อกำหนด ให้ติดตามผลต่อข้อมูล Interface, Permission, Report, Translation, Test และ Training ก่อนประเมินราคา

Nonfunctional ต้องระบุเงื่อนไขการวัด

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

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

คำถามสำหรับบริษัทรับพัฒนาระบบธุรกิจ

เปรียบเทียบความสามารถในการเปลี่ยนข้อกำหนดเป็นหลักฐาน ไม่ใช่จำนวนหน้าของ Proposal

• ใครลงสังเกตงานและตรวจสอบกับผู้ใช้ในโรงงานไทย ใช้ภาษาใด
• รักษา Traceability จาก Requirement ถึง Design, Code และ Test อย่างไร
• แยก Standard, Configuration, Extension และ Custom code อย่างไร
• ออกแบบคุณภาพ Migration, Reconciliation, Rerun และ Rollback อย่างไร
• แยกสาเหตุปัญหาระหว่าง ERP กับผู้ขายเครื่องจักรอย่างไร
• แยก Dev, Test, Production และอนุมัติ Release อย่างไร
• จัดการ Vulnerability, Dependency, Secret และ Access อย่างไร
• ส่งมอบ Source, Build, Operations document และ Cloud contract ในสภาพใด
• เมื่อเปลี่ยนผู้พัฒนา เอกสารและ Training เพียงพอหรือไม่
• หลัง Go-live คิดค่าปรับปรุง จัด Priority รับเหตุฉุกเฉิน และ Warranty อย่างไร

NIST SP 800-218 หรือ Secure Software Development Framework (SSDF) จัดกลุ่มแนวปฏิบัติพัฒนาซอฟต์แวร์อย่างปลอดภัยระดับสูงที่นำไปผนวกกับ Lifecycle เดิมได้ NIST ยังอธิบายว่าผู้ซื้อซอฟต์แวร์ใช้ภาษากลางนี้ในงานจัดหาและสื่อสารกับ Supplier ได้ ใน RFP จึงควรตรวจการป้องกันสภาพแวดล้อมพัฒนา การควบคุมโค้ดและ Dependency การตอบสนองช่องโหว่ ความสมบูรณ์ของ Release และการแก้ Root cause ด้วย Artifact และหลักฐาน ไม่ใช่เพียงคำรับรอง

CISA Secure by Demand Guide ก็สนับสนุนให้ผู้ซื้อถามเรื่อง Security อย่างชัดเจนใน Procurement โรงงานไม่ควรมอบ Security ให้ “มาตรฐานผู้ขาย” โดยไม่ตรวจ ต้องยืนยัน Account, Log, Update, Notification, End-of-support, Backup และ Incident response ก่อนลงนาม

การย้ายข้อมูลคือการส่งต่องาน ไม่ใช่คัดลอกไฟล์

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

จัดทำบัญชีข้อมูลก่อน

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

อนุมัติ Mapping และ Cleansing

กำหนด Old-to-new code, ค่าที่เลิกใช้ การ Merge/Split, Unit conversion, Field length, Rounding, Time zone และ Null treatment หากแก้อัตโนมัติให้บันทึกกฎและจำนวนที่ได้รับผล แล้วให้เจ้าของธุรกิจอนุมัติ ผู้พัฒนาไม่ควรเดาค่าที่ยังตัดสินไม่ได้

ซ้อม Migration และ Reconcile

ก่อน Cutover ให้ทำ Extraction, Transformation, Load, Technical reconciliation, Business reconciliation, Correction และ Rerun ซ้ำ ตรวจมากกว่าจำนวน Record เช่น ผลรวมปริมาณ มูลค่า จำนวนแยกสถานะ Sample lineage ความสัมพันธ์ Parent-child งานเปิด และ Permission

แผน Cutover ต้องมี Data freeze, Final delta, Stop criteria, Go/No-Go, Rollback, การอ่าน Legacy, Audit evidence และ Support desk คำว่า “ย้อนกลับได้” ไม่พอ ต้องซ้อมว่าใครตัดสินเมื่อใดและข้อมูลส่วนใดกลับไปที่จุดใด

แยก FAT, UAT และ SAT ตามวัตถุประสงค์

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

ทดสอบข้อยกเว้น ไม่ใช่เฉพาะ Happy path

นอกจาก Order ปกติจนจบงาน ให้ทดสอบของขาด วัตถุดิบทดแทน การ Split, Rework, Quality hold, เครื่องหยุด, สื่อสารขาด, ข้อความซ้ำ, แก้หลังปิดงวด, ปิด User และ Restore backup หากหยุดเครื่องเพื่อทดสอบไม่ได้อย่างปลอดภัย ต้องอนุมัติวิธี Simulation และ Residual risk

ตกลงเกณฑ์ผ่านล่วงหน้า

กำหนด Severity, ผลที่ต้องผ่าน การจัดการ Defect ค้าง, Retest, Evidence, Conditional acceptance และวันเริ่ม Warranty ก่อนเซ็นสัญญา หากเพิ่งเจรจาคำว่า “ปัญหาเล็กน้อย” ก่อน Go-live การตัดสินใจเดินระบบจะกลายเป็นข้อพิพาททางการค้า

เชื่อม Test ทุกข้อกับ Requirement ID, Prerequisite data, Step, Expected, Actual, Evidence, Tester, Time และ Environment version ภาพหน้าจออาจใช้ได้ แต่เมื่อหลักฐานจริงคือ Log, API result, Database reconcile, Equipment signal หรือ Approval ต้องเก็บสิ่งเหล่านั้นด้วย

สำหรับ Gate และบทบาทของทั้งโครงการ โปรดดู กระบวนการติดตั้งระบบบริหารการผลิต แล้วรวม Concept, Requirement, Design, Migration, Test และ Cutover ไว้ในแผนเดียว

จัดซื้อเงื่อนไขซอร์สโค้ด IP และการส่งต่องานให้ชัด

การได้รับซอร์สไม่ได้ทำให้ระบบ Custom ดูแลต่อได้โดยอัตโนมัติ ต้องมี Build ที่ทำซ้ำได้ Dependency, Environment, การส่งต่อ Secret, Monitoring, Incident process, Data export และ Training

ระบุ Ownership และสิทธิ์ใช้งานในสัญญา

• สิทธิ์ใน Source, Design, Test และ Data model ที่สร้างใหม่
• Background component ของผู้ขาย Third-party library และ OSS license
• สิทธิ์ของบริษัทในเครือและผู้ดูแลรายใหม่ในการแก้ระบบ
• รูปแบบข้อมูล กำหนดเวลา ค่าใช้จ่าย และหลักฐานลบเมื่อสิ้นสัญญา
• สิทธิ์ในทรัพย์สินที่ไม่ใช่โค้ด เช่น ภาพ Font และ Report component
• ผู้ดูแล Repository จุดส่งมอบ และเงื่อนไข Escrow หากจำเป็น

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

สิ่งส่งมอบสำหรับการส่งต่องาน

การตรวจรับสุดท้ายควรให้ทีมลูกค้าสร้างระบบจาก Clean environment ที่ลูกค้าควบคุม Deploy ไป Test, Restore backup และ Release การเปลี่ยนเล็กน้อย หากทำซ้ำได้เฉพาะ Laptop หรือ Account ส่วนตัวของผู้ขาย ยังไม่ถือว่าส่งต่องานเสร็จ

เปรียบเทียบ TCO รวมต้นทุนการเปลี่ยนแปลง

TCO รวม Requirement, Design, Development, License, Cloud, Equipment integration, Migration และ Training รวมถึง Monitoring, Support, Incident, Security update, Product upgrade, Dependency update, Enhancement, Data retention, Audit, Termination และ Future migration

สูตรแนวคิดคือ

TCO = ติดตั้ง + Platform ระหว่างใช้งาน + ปฏิบัติการและซัพพอร์ต + เปลี่ยนแปลง + รับมือความเสี่ยง + ยุติและย้ายออก

ควรเปรียบเทียบหลาย Scenario แทนการสร้างตัวเลขเดียวที่ดูแม่นเกินจริง เช่น เพิ่มโรงงาน ผู้ใช้ ไลน์ ปรับใหญ่ อัปเกรดผลิตภัณฑ์ เปลี่ยนผู้ดูแล และระบบหยุด ใช้สมมติฐานทางการเงินขององค์กรเรื่องช่วงประเมิน Discount rate, Currency และ Internal labor ให้เหมือนกันทุกทางเลือก

จาก Discovery 90 วันสู่การติดตั้งเป็นระยะ

Discovery 90 วันไม่ได้สัญญาว่าระบบเสร็จใน 90 วัน แต่ลดความไม่แน่นอนด้านกระบวนการ ข้อมูล เทคโนโลยี การย้ายข้อมูล และการปฏิบัติการ จนอนุมัติขอบเขตกับวิธีตรวจรับได้ ระยะเวลาต้องปรับตามองค์กร กรอบต่อไปนี้เป็นเพียงตัวอย่างเชิงปฏิบัติ ไม่ใช่ระยะเวลาสากล

วันที่ 1–30: ทำให้งานและขอบเขตมองเห็น

• ยืนยันเป้าหมายธุรกิจ KPI และผู้ตัดสินใจ
• สังเกตกะ ข้อยกเว้น กระดาษ Excel และการกรอกซ้ำในโรงงานไทย
• ทำ Inventory ระบบ เครื่องจักร Interface และ Data owner
• ใช้ ISA-95 ร่างขอบเขต ERP, MES, Equipment และระบบรอบข้าง
• แยกงานที่ควรใช้มาตรฐานออกจากความแตกต่างที่มีเหตุผล

ผลลัพธ์คือ Process map, Issue/KPI register, System context, Data inventory และ Requirement hypothesis

วันที่ 31–60: พิสูจน์ Scenario ตัวแทน

• กำหนด End-to-end scenario สำหรับสินค้าและไลน์ตัวแทน
• ตรวจหน้าจอหลักหรือ Prototype กับผู้ใช้จริง
• ทำ Fit-to-Standard และบันทึก Gap ของแพ็กเกจ
• พิสูจน์ Interface และสมมติฐาน Data quality ที่เสี่ยงในวงเล็ก
• ทดสอบสมมติฐาน Migration, Performance, Security และ Downtime

ผลลัพธ์คือ Requirements traceability, Option comparison, Prototype, Fit/Gap, Technical proof และ Risk register

วันที่ 61–90: ปิด RFP และแผนระยะ

• กำหนดขอบเขตขั้นต่ำที่ทำงานจบ ไม่ใช่เพียง Feature น้อยที่สุด
• วาง Migration, UAT, SAT, Training, Cutover และ Rollback
• ยืนยัน Source, IP, Cloud, Support, SLA และ Transition
• ทำแบบประเมินราคาตาม Requirement และ Supplier scorecard
• อนุมัติ Investment, TCO, Benefit measurement และ Gate ระยะถัดไป

ผลลัพธ์คือ RFP, Phased roadmap, Acceptance plan, Migration plan, Operating model, TCO scenarios และ Decision paper

เลือกระยะที่ปิดวงจรธุรกิจ

แทนที่จะติดตั้งทุกโรงงานพร้อมกัน ให้เลือกไลน์หรือกลุ่มสินค้าตัวแทนและทำวงจรที่ต่อเนื่อง เช่น Dispatch, Actual, WIP, Quality และ Inventory integration หลีกเลี่ยงระยะที่ส่งเพียงหน้าจอหรือเก็บข้อมูลแต่ยังหยุดวิธีเดิมไม่ได้

หลังตรวจรับจึงขยายสู่ไลน์ สินค้า Detailed planning, Maintenance หรือ Costing เพิ่ม ในทุก Gate ให้ประเมิน KPI, Data quality, Adoption, Defect, Support load และ Backlog ก่อนออกแบบระยะถัดไป

ประเด็นเพิ่มเติมสำหรับโรงงานในประเทศไทย

ภาษาหน้างานและการอนุมัติ

หากแปล Requirement ญี่ปุ่นเป็นอังกฤษเพื่อพัฒนา แล้วเพิ่มภาษาไทยตอนท้าย คำในหน้างานจะไม่ตรงกับหน้าจอ ควรสร้าง Glossary ของสินค้า กระบวนการ เครื่องจักร สถานะ Defect และ Downtime reason ตั้งแต่ต้น ให้ Thai key user อนุมัติพร้อม Scenario การแปลต้องรวม Error, Notification, Report, Training และ Runbook ไม่ใช่เฉพาะหน้าจอ

เครือข่ายและเวลาหยุดเครื่อง

แอปที่ทำงานดีในสำนักงานอาจพบข้อจำกัดจาก Wi-Fi โรงงาน Terminal, PLC network, Time sync, Power และ Remote access ต้องยืนยันจุดเชื่อมกับเจ้าของในสถานที่ และทดสอบ Loss, Delay, Reconnection กับ Offline procedure การเชื่อมเครื่องเดิมต้องประเมิน Safety และผลต่อการผลิต ภายใน Downtime window ที่อนุมัติ

บริบท Digital Transformation ในไทย

กรอบ Digital Transformation ของ depa อธิบายการใช้เทคโนโลยีดิจิทัลกับสินค้า บริการ กระบวนการ ประสิทธิภาพ และมูลค่าเพิ่ม ในประกาศเดือนเมษายน 2025 เรื่องผลสำรวจ Digital Density ปี 2024 depa รายงานว่าผู้ผลิตจำนวนมากในกลุ่มตัวอย่างยังใช้ระบบข้อมูลแยกตามแผนกหรือแนวปฏิบัติดิจิทัลระดับเริ่มต้น ข้อมูลนี้ไม่ได้บอกระดับของบริษัทใดบริษัทหนึ่ง แต่เน้นความสำคัญของการกำหนด Integration และ System of record ก่อนเขียนโค้ด

หน้า Smart and Sustainable Industry ปัจจุบันของ BOI ระบุมาตรการและเงื่อนไขสำหรับการเพิ่มประสิทธิภาพภาคผลิตและบริการ แต่โครงการซอฟต์แวร์บริหารการผลิตไม่ได้มีสิทธิ์โดยอัตโนมัติ ต้องตรวจผู้สมัคร กิจกรรม การลงทุน และช่วงยื่นกับ BOI หรือที่ปรึกษาที่มีคุณสมบัติก่อนอ้างอิงสิทธิประโยชน์

FAQ การพัฒนาระบบบริหารการผลิตแบบ Custom

เปรียบเทียบค่าพัฒนาระบบบริหารการผลิตแบบ Custom อย่างไร

ทำสมมติฐานและรายการ Requirement, Design, Integration, Migration, Test, Training, Source transition, Warranty, Operations และ Change ให้เหมือนกัน แบ่งทุกข้อเป็น Standard, Configured, Extended, Custom หรือ Unsupported แล้วเปรียบเทียบผลต่อ Upgrade และ Regression test

แพ็กเกจระบบบริหารการผลิตถูกกว่าพัฒนา Custom หรือไม่

ไม่มีคำตอบเดียว แพ็กเกจมักได้เปรียบเมื่อองค์กรรับ Standard scope ได้มาก ส่วน Custom อาจมีเหตุผลเมื่อมีความแตกต่างสำคัญ Integration ซับซ้อน และเปลี่ยนระยะยาวมาก ต้องเปรียบเทียบ Scenario เดียวกันด้วย TCO รวม Change และ Exit

ควรหลีกเลี่ยงอะไรในการปรับแต่งระบบบริหารการผลิต

หลีกเลี่ยงการแก้ Core โดยไม่มีเอกสาร ส่วนขยายที่ไม่รู้ผลต่อ Upgrade การตั้งค่าที่มีคนเดียวเข้าใจ ข้อมูลส่งออกไม่ได้ และการเปลี่ยนที่ไม่ทดสอบ ใช้ Extension point ที่รองรับและดูแล Delta register กับ Regression suite

สิ่งสำคัญที่สุดใน RFP พัฒนาระบบธุรกิจคืออะไร

ต้องมี Scenario ที่ผู้ใช้ทำให้จบ ขอบเขตความรับผิดชอบระบบและข้อมูล และ Acceptance ที่วัดได้ เชื่อม Exception, Migration, Nonfunctional, Deliverable และ Transition กับ Requirement ID ไม่ใช่ส่งเฉพาะรายการหน้าจอ

จ้างพัฒนาระบบแล้วต้องรับซอร์สโค้ดหรือไม่

สำหรับแอป Custom หรือ Extension สำคัญ ควรพิจารณาเงื่อนไขเพื่อความต่อเนื่อง แต่ Source อย่างเดียวไม่พอ ต้องส่ง Build, Dependency, Environment, Test, Data dictionary, Monitoring, Backup, Permission และ Training ในสภาพที่ลูกค้าทำซ้ำได้

ใช้ ISA-95 แล้วถือว่ากำหนด Requirement เสร็จหรือไม่

ไม่ใช่ ISA-95 เป็นภาษากลางที่ดีสำหรับ Activity, Information และ Integration boundary แต่ไม่ได้ตัดสินกฎโรงงาน Performance, Security, UI, Migration, Acceptance หรือกฎหมาย ต้องนำแบบอ้างอิงไปแปลงเป็น Requirement ที่ทดสอบได้

เริ่มพัฒนาระหว่าง Discovery 90 วันหรือไม่

Prototype และ Technical proof ขนาดเล็กเพื่อทดสอบสมมติฐานเสี่ยงมีประโยชน์ แต่อย่าสะสม Production code บน Architecture ที่ยังไม่อนุมัติ ให้แยก Validation asset ที่ทิ้งได้จาก Asset ที่จะใช้จริงในสัญญาและเกณฑ์คุณภาพ

การย้ายข้อมูลโรงงานไทยต้องระวังอะไร

ตรวจข้อความไทย อังกฤษ ญี่ปุ่น ชื่อเรียกหลายแบบ หน่วย เวลา การกรอก Excel รหัสซ้ำ และ Equipment ID เก่า ให้เจ้าของหน้างานอนุมัติ Mapping กับ Reconciliation และซ้อม Downtime, Delta load, Rollback และ Legacy access

สรุป: จัดซื้อขอบเขต หลักฐาน และการส่งต่อ ไม่ใช่เพียงชื่อวิธีพัฒนา

ความสำเร็จของการพัฒนาระบบบริหารการผลิตแบบ Custom ไม่ได้เริ่มจากการเลือกเขียนใหม่ แต่เริ่มจากการแยกงานมาตรฐานกับความแตกต่างจริง ใช้ ISA-95 เป็นภาษากลางกำหนดขอบเขต ERP, MES และเครื่องจักร และเชื่อม Requirement ทุกข้อกับวิธีทำและหลักฐานตรวจรับ เมื่อ RFP รวม Migration, Exception test, Source/Operations transition และ TCO ก็สามารถเปรียบเทียบแพ็กเกจ การปรับแต่ง และ Custom บนฐานเดียวกัน ใช้ Discovery ลดความไม่แน่นอน แล้วติดตั้งเป็นระยะที่ปิดวงจรงานได้

หากโรงงานในไทยยังอยู่ช่วงวางแนวคิดและยังไม่ได้เลือกวิธีหรือผู้พัฒนา TOMAS TECH สามารถช่วยจัดโครงสร้างงานหน้างาน Fit/Gap, RFP, Migration และ Acceptance criteria ได้ตั้งแต่ข้อมูลยังไม่ครบ ติดต่อ TOMAS TECH พร้อมข้อมูลที่ทราบเกี่ยวกับโรงงาน ระบบปัจจุบัน และปัญหาที่ต้องการแก้ก่อน

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

• NIST SP 800-218: Secure Software Development Framework Version 1.1
• ISA-95 Series of Standards
• GS1 Global Traceability Standard
• GS1 Traceability Standards
• CISA Secure by Demand Guide
• depa Digital Transformation
• depa 2024 Digital Density Survey announcement
• Thailand BOI: Smart and Sustainable Industry