Production management system functions cannot be evaluated with a feature-name checklist alone. A supplier may answer “yes” to production planning and inventory, yet the answer says nothing about who handles a plan revision, substitute material, partial completion, hold, rework or communication outage—and what evidence remains. This guide shows how a Thailand factory can structure an RFP with Must/Should/Could priorities, distinguish standard/configuration/custom work, and define master data, exceptions, authority, audit and ERP integration through acceptance evidence.
Production management system functions: write the outcome and evidence
A useful RFP line does not end with “the system shall have X.” It connects eight elements:
- Business outcome: the state that must be correct.
- Trigger: the event, time or approval that starts processing.
- Input: the master, plan, actual or equipment information used.
- Rule: priority, quantity, version, effective date, close and boundary logic.
- Exception: shortage, delay, defect, cancellation, rework or outage.
- Authority: who may execute, approve, correct and release.
- Output: shop instruction, ERP posting, inventory, quality or KPI result.
- Acceptance evidence: test data, log, screen and API response proving a pass.
Instead of “production actual entry,” write: “For a released work order, the operator records good, scrap and hold quantities, start/end time, equipment and lot. A total above the ordered quantity requires supervisor approval. The audit trail preserves old/new value, reason, approver and time. Resending the same result to ERP does not create a duplicate.” The same requirement can then drive the demo, estimate, design, FAT and SAT.
Define the boundary before mixing ERP, manufacturing and machine control
ISA-95 structures enterprise-control integration through activities, terminology and information exchange. Its public overview places manufacturing operations management at Level 3 and business planning/logistics, including ERP, at Level 4. The ISA page also lists ANSI/ISA-95.00.01-2025. ISA-95 overview
The RFP does not need a decorative pyramid. It needs an authoritative source and owner for each object.
| Information/activity | Likely source | Production-system responsibility | Boundary decision |
|---|---|---|---|
| Customer order/demand | ERP/sales | Reference and convert to production demand | Change, cancellation, priority, version |
| Item/BOM/routing | ERP/PLM/MES | Use the manufacturing version, enrich locally | Issuer, version, effective date, substitute |
| Production plan | ERP/APS/MES | Detail, sequence and release | Freeze, replan, approval |
| Work instruction/actual | MES/production system | Dispatch, collect, manage exceptions/history | Start, complete, cancel, replay |
| Equipment state/measure | PLC/SCADA/IoT | Receive selected data and add context | Clock, quality, missing data, unit |
| Inventory/WIP | ERP/WMS/MES | Reserve, issue, move and reconcile | Ownership, closing, negative stock, count |
| Quality disposition | QMS/MES | Request inspection, hold and receive disposition | Release authority, retest, deviation |
“ERP is master” is still incomplete. Can the floor continue when ERP is unavailable? Can an urgent item be provisionally registered? Who reconciles after recovery? Without those answers, two systems can both correct an item or stock balance and destroy the source of truth.
For product-selection axes, see our production management system comparison for Thailand. For build-versus-fit decisions, see custom development for production management systems. This article focuses on the RFP requirements that come first.
Use Must, Should and Could to stop “everything is mandatory”
If interviews are copied into a feature list, every department calls its request a Must. Use the MoSCoW method and define each priority as a decision rule, not a preference label.
Must
Without it, lawful, safe, quality-compliant, customer-compliant, close-ready or continuity-capable operation—or acceptance—fails. State the exact failure. If a safe workaround works within an accepted time, reconsider whether it is truly Must.
Should
It has high initial value, but a time-bounded workaround exists. Name the workaround, owner, allowable duration and added burden. If deferred to Phase 2, give it a decision date and owner.
Could
Its value must be tested after data and operation mature: advanced analytics, AI optimization or fine UI preferences are common examples. Preserve an API or required history as Must when that protects the future option.
Won’t now
Explicitly exclude machine safety control, enterprise costing redesign or whole-network WMS replacement when outside this release. “Won’t now” defines the estimate and acceptance boundary; it does not mean “never.”
| Priority | Decision question | Evidence required | Change approval |
|---|---|---|---|
| Must | What becomes unlawful, unsafe, stopped or unacceptable? | Policy, customer term, continuity or close rule | Steering Committee |
| Should | How long can we work around it, at what burden? | KPI, labor, quality risk | Process Owner |
| Could | What data tests the value hypothesis? | Hypothesis, measure, date | Product Owner |
| Won’t now | What is outside, and what future trigger reopens it? | Scope map, dependency | Sponsor |
If most requirements are Must, prioritization has failed. Confirm the Must-only scope fits budget and schedule; quote Should and Could separately.
Functional map for the production-management RFP
The map prevents omission; it is not the final scorecard. Expand every applicable row into scenarios and acceptance conditions.
| Domain | Typical Must | Exception to ask | Evidence |
|---|---|---|---|
| Master data | Item, BOM, routing, equipment, calendar, version | Overlapping effectivity, substitute, retirement, emergency | Version diff, approval, import result |
| Production demand | Create/change manufacturing demand | Partial cancel, rush, quantity change | Before/after, impact list |
| Planning/scheduling | Plan against capacity, material and due date | Downtime, absence, delay, frozen horizon | Plan version, warning, approval |
| Dispatch | Send released version to the floor | Stale device, reprint, wrong recipient | Receipt time, version, user |
| Actual collection | Quantity, time, asset, person, lot | Partial, overrun, cancel, duplicate, offline | Raw event, correction history |
| Material/WIP | Reserve, issue, return, move | Substitute, negative stock, fraction, mixed lot | Lot genealogy, reconciliation |
| Quality | Inspection, result, hold, disposition | Retest, concession, deviation, reversal | Spec version, result, e-signature |
| Traceability | Forward/backward material-process-product link | Split, merge, rework, subcontract | Query result and elapsed time |
| Exception management | Stop, shortage, defect, delay | Unclassified, aging, handover | Owner, due date, action history |
| Cost/KPI interface | Send actuals to ERP/BI | Post-close correction, conversion, allocation | Reconciliation, variance reason |
| Access/audit | Role, approval, separation, log | Emergency, delegation, termination, shared device | Access review, audit query |
| Operations | Monitor, backup, recover, change | Network loss, clock drift, patch | Restore test, RTO/RPO evidence |
Break “planning” into generate, freeze, approve, release, change, replan and notify. Break “traceability” into direction, response time, split/merge, rework, subcontracting, retention and export.
Convert a requirement into an acceptable line
ISO/IEC/IEEE 29148:2018 addresses requirements engineering processes and information items across the lifecycle. The 2018 edition was confirmed in 2024; however, ISO now marks it “to be revised” and shows a replacement DIS under development. Use the published edition as the current reference without treating the draft revision as final. ISO/IEC/IEEE 29148:2018
Recommended fields are: requirement ID; business purpose/source; priority; assumptions/trigger/input; normal, boundary and exception rules; role/approval/separation; output and interface; retention/audit/security; acceptance scenario, expected result and evidence; supplier response as standard/configuration/custom/external; product version, constraint, extra cost and lead time.
Weak:
The system shall support multiple languages.
Testable:
FR-UI-014 (Must): The operator UI switches between Thai and English per user. Item names use Thai/English names received from ERP; where absent, show the item code and record the missing translation in a daily data-quality report. Switching preserves work-order ID and in-progress state. FAT completes the same five orders in both languages and confirms identical stored code, quantity and time in an export and audit log.
Weak:
Integrate with ERP.
Testable:
IF-ERP-021 (Must): Send each approved production result with a unique event_id. After timeout, retry with the same event_id; if ERP already accepted it, no duplicate posting is created. HTTP 4xx business-rule errors enter quarantine; communication errors use bounded automatic retry. Owner, first time, attempt count, payload hash and final result remain searchable. SAT drops the response, retries and proves one ERP document with evidence from both systems.
Master-data functions: owner, version and effectivity before screens
Items, BOMs, routing, standard time, yield, capacity, shift, holiday, location, specification and reason codes determine whether planning and actuals can be trusted. ISO 8000-8:2015 addresses information/data-quality concepts and prerequisites for measurement in quality-management processes; the edition was confirmed in 2022. ISO 8000-8:2015
RFP requirements should establish:
- Attribute-level owners: ERP may own basic item identity, engineering the routing, quality the specification and manufacturing/maintenance the capacity.
- Maker/checker for high-risk changes; a tightly limited, expiring emergency process.
- Global versus Thailand-site attributes and who owns each namespace.
- Version, effective time, expiry and plant scope for BOM, routing and specification.
- A rule for work already released when a new version becomes effective.
- Validation of required fields, format, reference, duplicate, range, unit and localized name.
- Distinct meanings for unknown, not applicable and missing.
- Import totals for success, failure, warning, exclusion and hash; safe replay without duplicates.
Migration acceptance needs population count, transformation rules, exclusions, duplicates, missing values, sampled reconciliation and owner approval—not “the file loaded.”
Exception functions: describe how work stops and resumes
After one happy path, require suppliers to run actual exception data:
- Material is short or physical stock disagrees.
- Substitute material requires customer or quality approval.
- A partial quantity completes and crosses a shift.
- A defect moves to rework routing.
- Quantity or lot is corrected after completion.
- Work moves to another asset or subcontractor.
- Plan, BOM or routing changes during execution.
- Offline events replay after recovery.
For every exception, name detector, owner, due time, permitted action, approval, escalation, downstream impact and release condition. Govern reason-code creation and retirement; too many codes become noise, too few become “Other.”
Access and audit: reproduce responsibility
Separate plan creation, plan approval, work release, actual entry, actual correction, quality disposition, hold release, master change, user administration and audit viewing. Define:
- Separation of duties for high-risk create/approve operations.
- Scope by company, plant, line, warehouse and item group.
- Expiring delegation and emergency access with reason.
- Joiner/mover/leaver handling, including contractors.
- No shared human identity; distinguish person, device and service account.
- Searchable who/when/old/new/why/approval history.
- Protected logs, synchronized time and approved retention.
NIST SP 800-82 Rev.3 addresses OT security while respecting performance, reliability and safety needs. NIST lists Rev. 3 as the final publication and Rev. 4 as a draft; this article therefore cites Rev. 3 as the current final version. NIST SP 800-82 Rev.3 If production management connects to equipment, require boundaries, least privilege, registered endpoints, patch windows, backup, recovery and degraded operation. Do not connect a business-system pilot directly to machine safety control.
ERP integration for production management: contract the transaction
NIST’s Digital Thread work addresses reuse, exchange and traceability of information across engineering, manufacturing and quality. NIST Digital Thread Use that principle to define meaning and lineage, not just A-column-to-B-column mapping.
| Contract element | Define | Failure injected at acceptance |
|---|---|---|
| Business event | created/released/started/completed/cancelled/corrected | Out-of-order, post-cancel arrival |
| Identity | order_id, operation_id, event_id, source | Duplicate replay |
| Version | schema, master, plan, BOM/routing | Old or unknown version |
| Time | event/received/posted, timezone, sync | Clock drift, late arrival |
| Unit | base/transaction unit, conversion, rounding | Fraction and mismatched unit |
| Response | accepted/rejected/pending, error code | Lost response, partial success |
| Reprocessing | retry, quarantine, manual correction, replay | Bulk replay after recovery |
| Reconciliation | count, quantity, value, hash, close | Deliberate cross-system difference |
Maintain an interface register with owner, endpoints, mode, frequency, peak, SLA, retry, monitoring, classification, version-change notice, test environment and exit process. “Real time” is vague. For example, define “95% of in-scope events arrive within 60 seconds,” together with the measurement interval and denominator. Derive the target from the factory process; do not copy the template value.
Decide standard, configuration, customization or external process
Customization is not automatically wrong. The danger is freezing a common process in code, or forcing a differentiating rule into a poor standard process.
- Standard: present product version, no additional code.
- Configuration: approved workflow, rule, report or setting.
- Extension/customization: maintained API, plugin or bespoke code.
- External/process: another system or governed manual control.
| Decision axis | Prefer standard | Consider configuration | Custom may be justified when |
|---|---|---|---|
| Differentiation | Common administration | Plant rule | It supports customer value or unique process |
| Change rate | Follow product update | Admin can safely change | Stable rule with accountable owner |
| Quality/compliance | Standard evidence suffices | Validated approval config | Required evidence is otherwise impossible |
| Integration | Public API/connector | Mapping | Unique machine/transaction contract is unavoidable |
| Lifecycle | Vendor maintains | Promote/rollback config | Buyer owns code, tests, upgrade and exit |
Require product version, license, assumptions, limits, demonstrability, extra cost, lead time and upgrade effect. “Configurable” must identify who changes it, how approval, transport, rollback and audit work.
For custom code, contract source/artifact rights, repository, build, dependencies, automated tests, vulnerability handling, upgrade regression, documentation, succession and exit handover.
Do not exile non-functional requirements to an appendix
ISO/IEC 25010:2023 defines a product-quality model with nine characteristics for specifying and evaluating ICT/software quality. ISO/IEC 25010:2023 Convert quality into factory measures:
- Performance: normal/peak users, orders, events, reports and response distribution.
- Availability: service window, planned exclusions, monitoring and notification.
- Recovery: RTO/RPO, backup, restore, reconciliation and periodic test.
- Compatibility: browser, terminal, OS, printer, scanner, API version and encoding.
- Security: SSO/MFA, access, encryption, secrets, audit, vulnerability and patching.
- Maintainability: configuration/code separation, impact, regression, observability, documents.
- Usability: Thai/English UI, Japanese management needs, gloves, distance, error recovery, training.
- Data: accuracy, completeness, uniqueness, timeliness, lineage, retention, deletion and export.
Do not copy “24/7” or “three seconds” without identifying transaction, load, percentile, network, time window and business basis.
Require FAT/SAT acceptance evidence in the RFP
Acceptance is not invented at the end. Link every requirement to method and evidence.
| Method | Best for | Evidence | Warning |
|---|---|---|---|
| Demonstration | Workflow and exception | Recording, operation log, output | Run scenarios outside supplier script |
| Test | Performance, replay, recovery, access | Test sheet, log, API, DB reconciliation | Record environment and volume |
| Inspection | Design, config, document, license | Design, config export, register | Preserve reproducible version |
| Analysis | Capacity, risk, TCO | Formula, assumptions, sensitivity | Separate supplier assumptions |
The evidence pack records requirement ID, product/config version, date, environment, data, procedure, expected and actual result, raw log/output, defect, retest and approver.
FAT proves standard/configuration/integration/abnormal behavior in the supplier or test environment. SAT proves operation on the Thailand plant’s network, terminals, printers, labels, shifts, users and data volume. FAT does not equal production acceptance.
Vendor selection: Must gate, then an illustrative 100 points
Run Must as Pass/Fail so a price score cannot compensate for a critical gap. Then use a weighted comparison. The following is an illustrative governance assumption, not a universal benchmark.
| Evaluation area | Example points | Focus |
|---|---|---|
| Functional fit and exception coverage | 30 | Buyer scenarios; standard/config/custom evidence |
| Master data and integration | 20 | Source, version, replay, reconciliation, change |
| Security, audit and recovery | 15 | Separation, log, outage, RTO/RPO |
| Operability, localization and support | 15 | Thai operation, administration, local support |
| Delivery, acceptance and exit | 10 | Migration, evidence, defect, handover |
| Five-year TCO and commercial clarity | 10 | Assumption, license, change, upgrade, reserve |
| Total | 100 | Compare only after Must passes |
Use the buyer’s same representative data for every demo. Capture requirement ID, video/evidence, config screen, product version and custom-development status.
Five-year TCO should include license/subscription, environment, integration, migration, test, training, devices, network, support, upgrade, change, local service and exit export. Obtain values from bidders; do not invent a market price.
Thailand-specific selection conditions
- Specify operator UI language separately from master-data names and management reports.
- Translate errors, reason codes, help, training and support—not labels alone.
- Agree plan freeze, master approval and monthly-close ownership between headquarters and Thailand.
- Test Thai holidays, shift crossing, midnight and ICT timezone.
- Define support language, hours, initial response, site visit, replacement and escalation.
- Review local law and policy for personal data, operator performance and camera use.
Thailand BOI’s Investment Promotion Guide 2026 includes measures for upgrading toward Smart and Sustainable Industry and efficiency enhancement involving machinery/automation. BOI Guide 2026 This does not make a system automatically eligible. Verify activity, timing before purchase, investment scope, indicator and deadline with BOI or an adviser; do not put uncertain incentives into the business case.
Decision gates from RFP to production
- Scope Gate: approve KPI, process boundary, exclusions and sponsor.
- Requirement Gate: approve Must, owner, scenario and evidence.
- Fit-to-Standard Gate: demonstrate standard/config/custom/external treatment.
- Contract Gate: contract assumptions, TCO, responsibilities, deliverables, exit and change rates.
- Design Gate: approve master, access, exception, interface, migration and operation.
- FAT Gate: prove normal, boundary, abnormal and recovery.
- SAT/Go-live Gate: prove site operation, training, cutover, rollback and support.
- Stabilization Gate: confirm defects, data quality, KPI and operational handover.
Each gate permits pass, conditional pass, hold or stop. Never silently downgrade a Must because the schedule is late; record reason, impact, workaround, expiry and approval.
Common RFP failures
Scoring a product by feature count
Unused functions create training, access, test and upgrade burden. Score completion of buyer scenarios and exception evidence.
Rebuilding today’s spreadsheet as screens
Separate purpose, authoritative data, duplicate, approval and obsolete columns. Move common work toward the standard; protect truly differentiating rules.
Quoting “real-time integration” as one line
Separate event, latency, volume, replay, reconciliation and error owner. Not every master-data exchange must be real time.
Treating a demo as acceptance
Demo proves possibility, FAT configuration/integration, SAT site operation, and stabilization sustained ownership.
Prohibiting customization by count
Risk depends on impact, owner, upgrade, test and exit—not line count. A small component that stops every order is high risk.
Production-system RFP checklist
- Can the KPI and scope be explained on one page?
- Are ERP, PLM, WMS, QMS, MES and equipment sources/owners defined?
- Does every priority have rationale and an approver?
- Are shortage, rework, cancellation, correction and outage tested?
- Do master data have owner, version and effective date?
- Are create/approve/correct/release/admin duties separated?
- Does ERP integration define identity, version, unit, time, replay and reconciliation?
- Must bidders classify standard/config/custom/external with evidence and product version?
- Are quality, recovery, security, maintainability and languages measurable?
- Does each ID link to FAT/SAT/migration/training evidence?
- Does five-year TCO include change, upgrade, local support and exit?
- Do Thailand and headquarters owners jointly approve acceptance and change?
Summary: design production-management functions through acceptance
Selecting production management system functions is not counting names. Connect the business outcome, trigger, input, rule, exception, authority, output and evidence; then sequence investment with Must/Should/Could. When master ownership/version, exception behavior, access/audit and ERP replay/reconciliation are defined early, standard, configuration and customization can be judged fairly.
TOMAS TECH supports Thailand factories with current-state mapping, bilingual requirement workshops, RFPs, supplier demo scenarios, ERP integration and FAT/SAT evidence design. Even before the product and budget are fixed, we can begin with the Must scope and system boundary. Contact us.
FAQ on production management system functions
What functions does a production management system need?
Typical domains are master data, demand, planning, dispatch, actuals, material/WIP, quality, traceability, exception, cost/KPI interface, access/audit and operations. Do not make all of them initial Musts; prioritize by the target process and evidence.
What should we decide first when selecting a production management system?
Decide KPI, process boundary, responsibility with ERP/equipment and Must requirements before product names. Compare the same representative scenarios and fit classification.
How do we classify Must, Should and Could?
Must has a concrete lawful, customer, safety, quality, close, continuity or acceptance failure without it. Should has a time-bounded workaround. Could waits for a value test. Record rationale and change authority.
Should production-management customization be avoided?
Not categorically. Prefer standard for common work and configuration for site variation. Consider custom work where it supports differentiating operations and the buyer can own testing, upgrades and exit.
What matters most in ERP production-management integration?
Contract event meaning, unique identity, version, time, unit, response, replay, quarantine, reconciliation and owner. Inject a lost response during SAT and prove there is one posting.
Is translating the screen enough for a multilingual factory?
No. Include master names, errors, reason codes, help, training, support and translation change ownership. Test that switching language does not change stored codes or results.
How should RFP cost be compared?
Use the same five-year TCO assumptions for license, environment, configuration, custom work, integration, migration, test, training, devices, support, upgrade, change, local service and exit export.
What is the difference between FAT and SAT?
FAT proves configuration, integration and exceptions mainly in a test/supplier environment. SAT proves acceptance on the Thailand plant’s actual network, devices, data, shifts and users.
