ฟังก์ชันระบบบริหารการผลิต: RFP โรงงานไทย 2026

ฟังก์ชันระบบบริหารการผลิตไม่ควรถูกประเมินด้วย checklist ชื่อฟังก์ชันเพียงอย่างเดียว แม้ผู้ขายตอบว่ามี “วางแผนการผลิต” และ “ควบคุมสินค้าคงคลัง” ก็ยังไม่ทราบว่าใครจะจัดการเมื่อแผนเปลี่ยน วัตถุดิบทดแทน งานเสร็จบางส่วน งาน hold งาน rework หรือระบบสื่อสารขัดข้อง และต้องเหลือหลักฐานอะไร บทความนี้อธิบายวิธีทำ RFP สำหรับโรงงานในไทย โดยใช้ Must/Should/Could แยก standard/configuration/custom และกำหนด master data ข้อยกเว้น สิทธิ์ audit และการเชื่อม ERP ไปจนถึงหลักฐานรับมอบ

ฟังก์ชันระบบบริหารการผลิต: เขียนผลลัพธ์และหลักฐาน ไม่ใช่แค่ชื่อ

ข้อกำหนด RFP ที่ดีต้องเชื่อม 8 ส่วนเข้าด้วยกัน

1. ผลลัพธ์ทางธุรกิจ: สถานะใดต้องถูกต้อง
2. จุดเริ่ม: event เวลา หรือการอนุมัติใดเริ่มกระบวนการ
3. ข้อมูลเข้า: master แผน actual หรือข้อมูลเครื่องจักรใดถูกใช้
4. กฎ: ลำดับความสำคัญ ปริมาณ version วันที่มีผล closing และ boundary
5. ข้อยกเว้น: ของขาด ล่าช้า ของเสีย ยกเลิก rework หรือ outage
6. สิทธิ์: ใครทำ อนุมัติ แก้ไข หรือปลด hold ได้
7. ข้อมูลออก: คำสั่งหน้างาน ERP inventory quality หรือ KPI
8. หลักฐานรับมอบ: test data, log, screen และ API response ที่พิสูจน์ผล

แทนที่จะเขียนว่า “มีฟังก์ชันบันทึกผลผลิต” ควรเขียนว่า “สำหรับ work order ที่ release แล้ว operator บันทึก good/scrap/hold quantity เวลาเริ่ม-จบ เครื่องจักร และ lot ได้ ถ้ายอดรวมเกินคำสั่งต้อง supervisor อนุมัติ ระบบเก็บค่าเดิม/ใหม่ เหตุผล ผู้อนุมัติ และเวลาใน audit log และเมื่อส่ง event เดิมไป ERP ซ้ำต้องไม่สร้าง posting ซ้ำ” ข้อเดียวกันจึงใช้ได้ทั้ง demo ใบเสนอราคา design FAT และ SAT

กำหนดขอบเขตก่อนผสม ERP ระบบผลิต และ machine control

ISA-95 จัดโครงสร้างการเชื่อม enterprise กับ control ด้วยกิจกรรม คำศัพท์ และการแลกเปลี่ยนข้อมูล ในหน้า overview อย่างเป็นทางการ Level 3 คือ manufacturing operations management ส่วน Level 4 คือ business planning/logistics รวม ERP และหน้า ISA ปัจจุบันระบุ ANSI/ISA-95.00.01-2025 ด้วย ISA-95 overview

สิ่งสำคัญใน RFP ไม่ใช่รูป pyramid แต่คือ source of truth และ owner

คำว่า “ERP เป็น master” ยังไม่พอ ต้องระบุว่าเมื่อ ERP หยุด โรงงานทำงานต่อได้หรือไม่ สร้าง item ฉุกเฉินได้อย่างไร และใคร reconcile หลังระบบกลับมา มิฉะนั้นสองระบบอาจแก้ master/inventory พร้อมกันจนไม่เหลือ source of truth

สำหรับแกนเปรียบเทียบผลิตภัณฑ์ อ่าน เปรียบเทียบระบบบริหารการผลิตสำหรับโรงงานไทย และการตัดสินใจ standard กับพัฒนาเองอ่าน การพัฒนาระบบบริหารการผลิตแบบ custom บทความนี้เน้น requirement RFP ก่อนเลือกผลิตภัณฑ์

ใช้ Must/Should/Could เพื่อหยุดคำว่า “ต้องมีทั้งหมด”

หากคัดลอกผลสัมภาษณ์แต่ละฝ่ายเป็นรายการฟังก์ชัน ทุกฝ่ายมักเรียกความต้องการของตนว่า Must จึงควรใช้แนวคิด MoSCoW และกำหนดแต่ละลำดับความสำคัญให้เป็นกฎการตัดสินใจ ไม่ใช่ป้ายความชอบ

Must

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

Should

มีคุณค่าสูงต่อการเริ่มใช้งาน แต่มี workaround แบบจำกัดเวลาได้ ระบุ owner ระยะเวลาที่รับได้ และภาระเพิ่ม หากย้ายไป Phase 2 ต้องมีวันตัดสินใจใหม่

Could

ต้องพิสูจน์คุณค่าหลังข้อมูลและการปฏิบัติงานพร้อม เช่น advanced analytics, AI optimization หรือ UI preference บางอย่าง อาจกำหนด API/การเก็บ history เป็น Must เพื่อไม่ปิดทางอนาคต

Won’t now

ระบุชัดว่าครั้งนี้ไม่รวม machine safety control การออกแบบ costing ทั้งองค์กร หรือการเปลี่ยน WMS ทุกคลัง คำนี้กำหนดขอบเขต estimate/acceptance ไม่ได้แปลว่าไม่ทำตลอดไป

ถ้า requirement ส่วนใหญ่เป็น Must แสดงว่ายังไม่ได้จัดลำดับ ตรวจว่า Must-only อยู่ในงบและเวลา แล้วขอราคา Should/Could แยก

แผนที่ฟังก์ชันสำหรับ RFP ระบบบริหารการผลิต

แผนที่นี้ช่วยป้องกันข้อกำหนดตกหล่น แต่ไม่ใช่ตารางให้คะแนนสุดท้าย ต้องขยายแต่ละแถวที่เกี่ยวข้องเป็น scenario และ acceptance condition

อย่ารวม “planning” เป็นคำเดียว ให้แยก generate, freeze, approve, release, change, replan และ notify ส่วน traceability ต้องระบุทิศทาง เวลา query, split/merge, rework, subcontract, retention และ export

เปลี่ยน requirement ให้ทดสอบและรับมอบได้

ISO/IEC/IEEE 29148:2018 ครอบคลุม requirements engineering และ information items ตลอด lifecycle ฉบับ 2018 ได้รับการ confirm ในปี 2024 แต่ปัจจุบัน ISO แสดงสถานะ “to be revised” และกำลังพัฒนา replacement DIS จึงใช้อ้างอิงฉบับเผยแพร่โดยไม่ถือว่าร่างใหม่ final แล้ว ISO/IEC/IEEE 29148:2018

คอลัมน์ที่แนะนำ: Requirement ID, business purpose/source, priority, assumption/trigger/input, normal/boundary/exception rule, role/approval/separation, output/interface, retention/audit/security, acceptance scenario/expected/evidence, supplier response standard/config/custom/external และ product version/constraint/cost/lead time

ข้อกำหนดที่อ่อน:

รองรับหลายภาษา

ข้อกำหนดที่ทดสอบได้:

FR-UI-014 (Must): operator UI สลับไทย/อังกฤษตาม user ได้ ชื่อ item ใช้ชื่อสองภาษาจาก ERP หากขาดให้แสดง item code และบันทึกใน daily data-quality report การสลับภาษาต้องรักษา work-order ID และสถานะที่กำลังทำ FAT ทำ order เดียวกัน 5 รายการในสองภาษา และตรวจ code, quantity, time ที่บันทึกด้วย export และ audit log

ข้อกำหนดที่อ่อน:

เชื่อม ERP ได้

ข้อกำหนดที่ทดสอบได้:

IF-ERP-021 (Must): ส่ง production result ที่อนุมัติพร้อม event_id ที่ไม่ซ้ำ หาก timeout ให้ retry ด้วย event_id เดิม ถ้า ERP รับแล้วห้าม posting ซ้ำ ข้อผิดพลาดทางธุรกิจกลุ่ม HTTP 4xx ต้องเข้า quarantine ส่วน communication error ให้ใช้ bounded automatic retry ต้องค้น owner, first time, attempt count, payload hash และ final result ได้ SAT จำลอง response หาย แล้วพิสูจน์ว่ามี ERP document เพียง 1 รายการจากหลักฐานสองระบบ

Master data: owner, version และ effective date มาก่อนหน้าจอ

item, BOM, routing, standard time, yield, capacity, shift, holiday, location, specification และ reason code เป็นฐานของแผนและ actual ISO 8000-8:2015 อธิบายแนวคิด information/data quality และเงื่อนไขการวัดใน quality-management process โดยฉบับนี้ confirm ในปี 2022 ISO 8000-8:2015

RFP ต้องกำหนด:

• Owner ระดับ attribute: ERP ดู identity, engineering ดู routing, quality ดู spec, production/maintenance ดู capacity
• แยกผู้สร้างกับผู้อนุมัติ high-risk change; emergency change ต้องหมดอายุ
• แยก global code กับ Thailand-site attribute
• BOM/routing/spec มี version, effective time, expiry, plant scope
• กฎเมื่อ work order ถูก release ก่อน version ใหม่มีผล
• ตรวจ required, format, reference, duplicate, range, unit และชื่อภาษา
• unknown, not applicable และ missing ต้องไม่ใช้ค่าว่างเดียวกัน
• Import เก็บ total, success, failure, warning, exclusion, hash และ replay ไม่ซ้ำ

Migration acceptance ต้องมี population count, transformation rule, exclusion, duplicate, missing, sample reconciliation และ owner approval ไม่ใช่เพียง “load สำเร็จ”

Exception: ออกแบบวิธีหยุดและเริ่มใหม่

หลัง happy path ให้ผู้ขายทดสอบข้อมูลจริงของกรณีต่อไปนี้:

1. วัตถุดิบขาด หรือ physical stock ไม่ตรงระบบ
2. ต้องใช้ substitute ที่รอ customer/quality approval
3. เสร็จบางส่วนและส่งต่องานข้าม shift
4. ของเสียเข้าสู่ rework routing
5. แก้ quantity/lot หลัง complete
6. ย้ายไปเครื่องอื่นหรือ subcontract
7. Plan, BOM หรือ routing เปลี่ยนระหว่างทำงาน
8. Offline event replay หลัง recovery

ทุก exception ต้องมี detector, owner, due time, permitted action, approval, escalation, downstream impact และ release condition รวมถึง owner สำหรับการสร้าง/เลิก reason code

สิทธิ์และ audit: ทำให้ความรับผิดชอบตรวจสอบย้อนหลังได้

แยกสิทธิ์สร้างแผน อนุมัติแผน release งาน บันทึก actual แก้ actual ตัดสิน quality ปลด hold เปลี่ยน master จัดการ user และดู audit

• แยกหน้าที่ create/approve สำหรับ high-risk change
• จำกัด scope ตาม company, plant, line, warehouse, item group
• delegation/emergency access มีเหตุผลและวันหมดอายุ
• รองรับ joiner/mover/leaver รวม contractor
• ห้าม shared human identity; แยก person/device/service account
• ค้น who/when/old/new/why/approval ได้
• ปกป้อง log, synchronize time และกำหนด retention

NIST SP 800-82 Rev.3 ให้แนวทาง OT security โดยคำนึง performance, reliability และ safety NIST ระบุ Rev.3 เป็นฉบับ final และ Rev.4 เป็น draft บทความนี้จึงอ้างอิง Rev.3 ในฐานะฉบับ final ปัจจุบัน NIST SP 800-82 Rev.3 หากระบบผลิตเชื่อมเครื่องจักร ต้องกำหนด network boundary, least privilege, endpoint registration, patch window, backup, recovery และ degraded mode และไม่เชื่อม PoC ระบบธุรกิจตรงกับ machine safety control

การเชื่อม ERP กับระบบการผลิต: ทำสัญญาความหมายของ transaction

งาน Digital Thread ของ NIST เน้นการใช้ซ้ำ แลกเปลี่ยน และ trace ข้อมูลข้าม engineering, manufacturing และ quality NIST Digital Thread RFP จึงต้องกำหนด meaning/lineage ไม่ใช่แค่ field mapping

ทำ interface register ที่มี owner, endpoint, mode, frequency, peak, SLA, retry, monitoring, classification, version-change notice, test environment และ exit process คำว่า “real time” คลุมเครือ ควรระบุ เช่น “95% ของ event ที่อยู่ในขอบเขตต้องถึงปลายทางภายใน 60 วินาที” พร้อมกำหนดช่วงเวลาที่ใช้วัดและตัวหาร ทั้งนี้ต้องกำหนดค่าจากกระบวนการจริงของโรงงาน ไม่คัดลอกตัวเลขตัวอย่าง

ตัดสิน standard, configuration, customization หรือ external

Customization ไม่ได้ผิดโดยอัตโนมัติ ความเสี่ยงคือการตรึงกระบวนการทั่วไปไว้ใน code หรือบังคับกฎที่สร้างความแตกต่างให้เข้ากับ standard process ที่ไม่เหมาะสม

1. Standard: มีใน product version ปัจจุบันโดยไม่เพิ่ม code
2. Configuration: workflow, rule, report หรือ setting ที่อนุมัติ
3. Extension/customization: API, plugin หรือ custom code ที่ต้อง maintain
4. External/process: ระบบอื่นหรือ manual control ที่มี governance

บังคับให้ผู้ขายระบุ product version, license, assumption, limit, demo, extra cost, lead time และผลต่อ upgrade คำว่า configurable ต้องแสดงว่าใครเปลี่ยน อนุมัติ promote rollback และ audit อย่างไร

ถ้ามี custom code ให้ทำสัญญาสิทธิ์ source/artifact, repository, build, dependency, automated test, vulnerability handling, upgrade regression, document, succession และ exit handover

Non-functional requirement ต้องวัดในบริบทโรงงาน

ISO/IEC 25010:2023 กำหนด product-quality model 9 characteristics สำหรับ ICT/software ISO/IEC 25010:2023 แปลงเป็นเกณฑ์ที่วัดได้:

• Performance: normal/peak user, order, event, report และ response distribution
• Availability: service window, planned exclusion, monitoring, notification
• Recovery: RTO/RPO, backup, restore, reconciliation, periodic test
• Compatibility: browser, device, OS, printer, scanner, API version, encoding
• Security: SSO/MFA, access, encryption, secret, audit, vulnerability, patch
• Maintainability: แยก config/code, impact, regression, observability, document
• Usability: ไทย/อังกฤษ การบริหารญี่ปุ่น ถุงมือ ระยะมอง error recovery training
• Data: accuracy, completeness, uniqueness, timeliness, lineage, retention, export

อย่าใส่ “24/7” หรือ “3 วินาที” หากไม่ระบุ transaction, load, percentile, network, time window และเหตุผลทางธุรกิจ

กำหนดหลักฐาน FAT/SAT ตั้งแต่ RFP

Acceptance ไม่ใช่ test ที่ค่อยคิดตอนท้าย ต้องเชื่อม requirement ทุกข้อกับวิธีตรวจและหลักฐานตั้งแต่ RFP

Evidence pack ต้องมี requirement ID, product/config version, date, environment, data, procedure, expected/actual, raw log/output, defect, retest และ approver

FAT พิสูจน์ standard/config/integration/abnormal ใน test/supplier environment ส่วน SAT พิสูจน์ใน network, terminal, printer, label, shift, user และ data volume ของโรงงานไทย FAT ผ่านไม่เท่ากับรับมอบ production

เลือกผู้ขายด้วย Must gate แล้วจึงใช้คะแนนตัวอย่าง 100

Must เป็น Pass/Fail ก่อน เพื่อไม่ให้ราคาชดเชย gap ที่วิกฤต จากนั้นใช้ weighted score ตัวอย่างต่อไปนี้ ซึ่งเป็นสมมติฐาน governance สำหรับวางแผน ไม่ใช่มาตรฐานสากล

ทุก vendor ต้อง demo ด้วยข้อมูลตัวแทนชุดเดียวกัน เก็บ requirement ID, video/evidence, config screen, product version และ custom status

TCO 5 ปีรวม license/subscription, environment, integration, migration, test, training, device, network, support, upgrade, change, local service และ exit export ให้ vendor เสนอราคา ไม่สร้างราคาตลาดสมมติ

เงื่อนไขเพิ่มเติมสำหรับโรงงานไทย

• แยกภาษาหน้าจอ operator จากชื่อ master และ report ผู้บริหาร
• แปล error, reason code, help, training และ support ไม่ใช่แค่ label
• ตกลง owner เรื่อง plan freeze, master approval, month-end ระหว่าง HQ กับไทย
• ทดสอบวันหยุดไทย งานข้าม shift เที่ยงคืน และ ICT timezone
• กำหนดภาษาบริการ เวลา first response, site visit, replacement, escalation
• ตรวจข้อกฎหมาย/นโยบายท้องถิ่นสำหรับ personal data, performance และ camera

BOI Investment Promotion Guide 2026 มีมาตรการยกระดับไปสู่ Smart and Sustainable Industry และเพิ่มประสิทธิภาพด้วย machinery/automation BOI Guide 2026 แต่ระบบไม่ได้มีสิทธิ์โดยอัตโนมัติ ต้องตรวจ activity, timing ก่อนสั่งซื้อ, investment scope, indicator และ deadline กับ BOI/ผู้เชี่ยวชาญ และไม่ใส่ incentive ที่ยังไม่แน่นอนใน business case

Decision gate จาก RFP ถึง production

1. Scope Gate: KPI, boundary, exclusion, sponsor
2. Requirement Gate: Must, owner, scenario, evidence
3. Fit-to-Standard Gate: standard/config/custom/external ด้วย demo จริง
4. Contract Gate: assumption, TCO, responsibility, deliverable, exit, change rate
5. Design Gate: master, access, exception, interface, migration, operation
6. FAT Gate: normal, boundary, abnormal, recovery
7. SAT/Go-live Gate: site, training, cutover, rollback, support
8. Stabilization Gate: defect, data quality, KPI, handover

ทุก gate มี pass, conditional pass, hold, stop ห้ามลด Must เป็น Should แบบเงียบเพราะงานช้า ต้องบันทึก reason, impact, workaround, expiry, approval

ความล้มเหลว RFP ที่พบบ่อย

ให้คะแนนตามจำนวนฟังก์ชัน

ฟังก์ชันที่ไม่ใช้เพิ่มภาระ training, access, test, upgrade ให้คะแนนจาก buyer scenario และ exception evidence

แปลง Excel ปัจจุบันเป็นหน้าจอทั้งหมด

แยก purpose, source, duplicate, approval และ obsolete column งานทั่วไปควรเข้าหา standard ส่วนกฎที่สร้างความต่างค่อยรักษาไว้

รวม “real-time integration” เป็นบรรทัดเดียว

แยก event, latency, volume, replay, reconciliation และ error owner master ทุกตัวไม่จำเป็นต้อง real time

ถือ demo เป็น acceptance

Demo พิสูจน์ possibility, FAT พิสูจน์ config/integration, SAT พิสูจน์หน้างาน และ stabilization พิสูจน์ owner ระยะยาว

ห้าม customization ตามจำนวน

ความเสี่ยงขึ้นกับ impact, owner, upgrade, test และ exit ไม่ใช่จำนวนบรรทัด code เล็กที่หยุดทุก order คือ high risk

Checklist RFP ระบบบริหารการผลิต

• อธิบาย KPI/scope ได้ในหนึ่งหน้าหรือไม่
• กำหนด source/owner ของ ERP, PLM, WMS, QMS, MES, equipment หรือไม่
• priority ทุกข้อมีเหตุผลและ approver หรือไม่
• ทดสอบ shortage, rework, cancel, correction, outage หรือไม่
• master มี owner, version, effective date หรือไม่
• แยก create/approve/correct/release/admin หรือไม่
• ERP interface มี identity, version, unit, time, replay, reconciliation หรือไม่
• ให้ vendor จัด standard/config/custom/external พร้อม version/evidence หรือไม่
• quality, recovery, security, maintainability, language วัดได้หรือไม่
• Requirement ID เชื่อม FAT/SAT/migration/training evidence หรือไม่
• TCO 5 ปีรวม change, upgrade, local support, exit หรือไม่
• Owner ไทยและ HQ อนุมัติ acceptance/change ร่วมกันหรือไม่

สรุป: ออกแบบฟังก์ชันระบบบริหารการผลิตถึงหลักฐานรับมอบ

การเลือกฟังก์ชันระบบบริหารการผลิตไม่ใช่การนับชื่อ ต้องเชื่อมผลลัพธ์ trigger input rule exception authority output และ evidence แล้วจัดลำดับด้วย Must/Should/Could เมื่อกำหนด owner/version ของ master วิธีจัด exception สิทธิ์/audit และ ERP replay/reconciliation ตั้งแต่ต้น จะตัดสิน standard, configuration และ customization ได้อย่างยุติธรรม

TOMAS TECH สนับสนุนโรงงานในไทยด้วย current-state mapping, workshop ไทย/ญี่ปุ่น, RFP, demo scenario, ERP integration และการออกแบบหลักฐาน FAT/SAT แม้ยังไม่เลือกผลิตภัณฑ์หรืองบ ก็เริ่มจาก Must และ system boundary ได้ ติดต่อเรา

คำถามที่พบบ่อยเกี่ยวกับฟังก์ชันระบบบริหารการผลิต

ระบบบริหารการผลิตต้องมีฟังก์ชันอะไรบ้าง?

โดยทั่วไปมี master, demand, planning, dispatch, actual, material/WIP, quality, traceability, exception, cost/KPI interface, access/audit และ operations แต่ไม่ควรทำทุกอย่างเป็น Must ระยะแรก ให้เลือกจาก process และ evidence

วิธีเลือกระบบบริหารการผลิตควรเริ่มจากอะไร?

เริ่มจาก KPI, boundary, responsibility กับ ERP/equipment และ Must ก่อนชื่อผลิตภัณฑ์ แล้วเทียบ scenario และ fit classification เดียวกัน

Must/Should/Could ตัดสินอย่างไร?

Must ขาดแล้วกฎหมาย ลูกค้า safety quality closing continuity หรือ acceptance ล้ม Should มี workaround จำกัดเวลา Could รอทดสอบคุณค่า ต้องบันทึกเหตุผลและผู้อนุมัติเปลี่ยน

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

ไม่จำเป็นต้องห้ามทั้งหมด งานทั่วไปเลือก standard ความต่างไซต์ใช้ configuration ส่วน custom ใช้เมื่อสนับสนุน unique operation และมี owner สำหรับ test, upgrade, exit

การเชื่อม ERP กับระบบการผลิตสำคัญที่สุดตรงไหน?

กำหนด event meaning, unique ID, version, time, unit, response, replay, quarantine, reconciliation และ owner และจำลอง response หายใน SAT เพื่อพิสูจน์ว่าไม่ posting ซ้ำ

แปลหน้าจอเพียงพอสำหรับโรงงานหลายภาษาหรือไม่?

ไม่พอ ต้องรวม master name, error, reason code, help, training, support และ owner ของการเปลี่ยนคำแปล พร้อมทดสอบว่าการสลับภาษาไม่เปลี่ยน code/result

เปรียบเทียบค่าใช้จ่าย RFP อย่างไร?

ใช้สมมติฐาน TCO 5 ปีเดียวกัน ครอบคลุม license, environment, configuration, custom, integration, migration, test, training, device, support, upgrade, change, local service และ exit export

FAT ต่างจาก SAT อย่างไร?

FAT ทดสอบ config, integration, exception ใน test/supplier environment ส่วน SAT ทดสอบ network, device, data, shift และ user จริงของโรงงานไทย

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

• ISA-95 Series
• ISO/IEC/IEEE 29148:2018
• ISO/IEC 25010:2023
• ISO 8000-8:2015
• NIST Digital Thread
• NIST SP 800-82 Rev.3
• Thailand BOI Investment Promotion Guide 2026