Manufacturing Process Management System: A Closed-Loop Guide

A manufacturing process management system does not reduce late deliveries merely by displaying a colorful progress board. It must turn a frozen routing and a released work order into reliable WIP states, event timestamps, assigned exceptions, a structured handoff to rescheduling, and traceable evidence of every decision. This guide explains how a factory in Thailand can define that closed-loop operating model and turn it into RFP requirements, PoC scenarios, FAT/SAT acceptance evidence, a phased rollout and a three-year TCO.

What a manufacturing process management system actually manages

The system should answer five operational questions: What is authorized to run? Where is each work order and lot? What happened and when? Who owns the deviation? What approved action is next? A Gantt chart, digital daily report or machine monitor may answer part of the picture, but none is a closed execution process on its own.

The operating boundary normally spans three layers:

• ERP and production management: demand, purchasing, inventory, work orders, deliveries and cost.
• Manufacturing operations: work release, dispatching, WIP state, production results, quality status, exceptions and completion.
• Control and equipment: PLCs, sensors, inspection machines, scales and other assets that observe or control the physical process.

ISA-95 describes Level 3 as manufacturing operations management and Level 4 as business planning and logistics. The practical lesson is to decide which layer is the system of record for each decision and data object before debating whether a product is called MES, MOM or production management. The process management layer typically executes an ERP work order and connects it to shop-floor events.

Process management versus production management

Production management covers a broad horizon from demand and supply through inventory, shipment and cost. Process management concentrates on the shorter execution horizon: what is happening now, what can run next, and what must be escalated. The two should exchange controlled records instead of maintaining editable copies of the same master data.

For example, ERP may own a work order for 1,000 units due Friday. The execution layer records the approved BOM and routing revision, input lots, start/stop/complete events, good and reject quantities, resource identity and exception history. It returns confirmed consumption and completion to ERP. If both systems can silently modify the same routing or quantity, reconciliation becomes inevitable.

For a broader product-selection framework, see our production management system comparison for Thai factories. This article focuses on the operating model after product selection rather than another feature ranking.

The nine-stage closed loop for visible production progress

Progress is not truly visible until the information causes a controlled action. A robust loop connects the following stages and feeds learning back into the next approved standard.

These stages do not have to live in one application. They do need shared identifiers, controlled states, unambiguous timestamps and an explicit transfer of responsibility. A paper note or chat message can support an emergency, but the decision must return to the record within a defined time.

1. Freeze the routing before releasing the work order

A common failure is allowing a routing, BOM or inspection instruction to be overwritten after work has been released. The resulting production result no longer has a stable baseline. Instead, approve the item, BOM revision, routing revision, work instruction, inspection specification and standard time, and bind the applicable revisions to the work order.

“Frozen” does not mean unchangeable forever. An emergency change should record the reason, affected orders and WIP, approver, effective time, old and new revisions, shop-floor notification and disposition of material already in process. Do not silently edit the original order.

A practical work-release gate

Before moving an order from planned to executable, confirm that:

• the BOM, routing and inspection specification are approved and effective;
• required material, tooling, equipment and skills are available or formally excepted;
• substitute material or alternate routing has an approval;
• prerequisite, quality-hold and maintenance restrictions are cleared;
• labels, travelers and terminal screens reference the same order and revision; and
• the releaser and release timestamp are recorded.

If partial release is normal, model the released quantity, remaining supply, affected downstream work and decision authority. An informal “start anyway” outside the system is more dangerous than a controlled partial release.

2. Make WIP state unambiguous

When planning shows “in progress,” the board shows “stopped,” and quality shows “held,” the daily meeting starts with data reconciliation. Define separate state machines for the work order, operation, WIP lot and exception case.

For each state, define who can enter it, required fields, allowed next states and overdue escalation. Decide the colors only after those semantics are agreed.

Quantity conservation belongs in the state model. If 100 units enter an operation and 90 are good while five are rejected, the remaining five cannot disappear. Good, reject, rework, scrap, hold and in-process quantities should reconcile to the input, subject to defined tolerances for weight, continuous material, evaporation or cutting loss. Lot splits and merges must retain parent-child relationships.

3. Capture production results as events with clear time semantics

“When did it happen?” has several answers: when the machine completed the cycle, when the PLC transmitted, when the gateway received, when the server stored, or when an operator entered a late record. A useful event model preserves the relevant distinctions.

At minimum, capture:

• a unique event_id so retries do not create duplicate results;
• work_order_id and operation_id;
• item, lot or serial identity;
• event type such as start, pause, resume, complete, quantity report or quality hold;
• source timestamp and receive timestamp;
• time zone and clock source;
• quantity, unit and reason code;
• source such as PLC, terminal, API or manual input;
• actor such as operator, machine or service account; and
• a reference to the original event when correcting a record.

OPC UA distinguishes SourceTimestamp from ServerTimestamp, and its specifications warn that incorrect timestamps can create interoperability issues. Therefore an RFP should go beyond “real-time capable.” Ask about clock synchronization, local buffering, retry order, late events, duplicate suppression, corrections and time-zone handling.

Automation and manual input are complementary. Cycle, count and equipment-state events are strong automation candidates. Setup reason, material wait, quality judgment and rework classification often require human context. A practical design minimizes touches without pretending that a PLC knows every business reason.

Shop-floor terminals also need glove use, shared sessions, barcode scanning, offline behavior, multilingual labels, correction rights and shift handover. Keep reason codes specific enough to drive action but short enough for consistent selection, and assign an owner to maintain the code list.

4. Turn an alert into an exception with an owner

Sending an email to everyone does not resolve a late order. An exception is a unit of work that must return the process to a controlled state. Give it an owner, deadline, impact, next decision, containment action and escalation rule.

The notification recipient is not necessarily the case owner. Ownership begins when the responsible role acknowledges the case. A transfer from production to maintenance should carry asset ID, stop time, current order and quantity, safe state and restart condition, rather than a free-text “please check.”

Closure also needs evidence: a trial run after repair, quality result and release approval, received material, an approved schedule revision, or a zero-backlog reconciliation after interface recovery. A clicked “close” button is not root-cause evidence.

5. Design the handoff to rescheduling

Detecting delay without passing usable information to planning merely moves the spreadsheet work downstream. At the opposite extreme, automatically rescheduling every time an event arrives creates an unstable plan the floor cannot follow. Define a rescheduling trigger and a decision packet.

The packet should include:

• affected work order, operation, quantity and customer due date;
• current WIP position and quality status;
• variance between planned and predicted completion;
• earliest restart and confidence in the recovery estimate;
• alternate machine, routing, outsourcing or overtime possibilities;
• material, tooling and skill constraints;
• effects on predecessor, successor and competing orders;
• whether already released work may be changed; and
• decision deadline and approver.

Once planning approves a change, send back a versioned priority, scheduled time and resource assignment. The shop floor should acknowledge the revised dispatch list. If an oral emergency instruction is permitted, define how soon it must be recorded and approved.

Factories moving from spreadsheet scheduling toward APS can use the phased approach in our production planning Excel migration guide. In many cases, trusted WIP and capacity feedback is a better first milestone than replacing every planning rule at once.

6. Preserve traceable evidence of decisions and changes

Traceability is broader than raw-material genealogy. Process management must reproduce which approved standard and order were used, what data the decision-maker saw, who authorized a deviation, and what changed as a result.

Retain evidence for:

• approved BOM, routing, work instruction and inspection revisions;
• order creation, approval, release, change and cancellation;
• lot split, merge, consumption, movement and disposition;
• start, pause, resume, completion and correction events;
• hold, deviation, rework, concession and release approvals;
• exception ownership, deadlines, actions and attachments;
• schedule before/after, impact assessment, approval and floor receipt;
• changes to users, roles, masters and interface configuration; and
• messages returned to ERP, acknowledgements, retries and reconciliation.

An audit log is valuable only if users can retrieve it by work order, lot, asset, period, user or exception and reconstruct the sequence. Corrections should preserve the original value, reason, actor, approval and time. Retention should reflect legal, customer, quality and analytical needs rather than an arbitrary “keep everything forever.”

RFP requirements for a manufacturing process management system

Avoid a requirement such as “show progress in real time.” State the scenario, data, performance condition, exception behavior, required evidence and acceptance method. Require vendors to distinguish standard capability, configuration, custom development, partner product and non-support.

Non-functional requirements need measurement conditions. “Three-second response” should state concurrent users, volume, network, screen, measurement point and percentile. Availability should state the service window and exclusions. Backup acceptance should include a restore and reconciliation test.

Where the application connects to OT, changes must respect availability and safety. NIST SP 800-82 Rev. 3 addresses OT security while recognizing performance, reliability and safety requirements. Ask about asset inventory, segmentation, least privilege, remote maintenance, logging, backup, vulnerability handling and validation before production changes rather than assuming ordinary office-IT patching.

Build acceptance evidence through PoC, FAT and SAT

The three stages serve different purposes.

PoC scenarios that reveal real risk

Use a small set of factory data and test failure paths, not only a perfect start and completion:

1. Release an order against the approved routing and prevent execution against an obsolete revision.
2. Split a lot, hold one branch for quality and send the other forward.
3. Disconnect the PLC or gateway and verify ordered, duplicate-free recovery.
4. Correct a wrong quantity while preserving the original event and approval.
5. Stop a machine, predict a missed due date, assign an exception and create a rescheduling case.
6. Change priority and trace the old plan, new plan, approval and floor receipt.
7. Pause ERP integration, retry, then reconcile orders, results and quantities.
8. Confirm an unauthorized user cannot release a quality hold.

Predefine the acceptance evidence: event and API logs, audit records, quantity reconciliation, response time and remaining manual steps. Finding a constraint is not a failed PoC; failing to transfer the constraint into design and contract is.

FAT should link requirement IDs to test cases and retain input, procedure, expected result, actual result, evidence and approver. Defects need severity, workaround, target date and retest. SAT repeats the relevant cases with the Thailand site’s actual network, terminals, scanners, printers, equipment, ERP, shifts, languages and roles. It should also test Wi-Fi gaps, power recovery, shared terminals and night-shift support.

A phased rollout that closes the loop at every step

An all-site launch concentrates master-data, device, training and support risks. Phasing should not mean installing disconnected screens. Each phase should complete an end-to-end loop.

Phase 0: Create a measurable baseline

Map how orders, WIP, results, exceptions and delivery changes move through current documents and systems. Record KPI definitions and sources, examine master duplication, units, timestamps, lot rules and open orders, and establish a baseline period before configuration.

Phase 1: Close one product-family and line loop

Choose a representative line whose outage risk can be controlled. Connect release, execution, WIP, exception and ERP completion. Barcode and terminal input are valid starting points when automatic equipment capture is not ready, provided the records are timely and reconcilable.

Phase 2: Stabilize exception and rescheduling behavior

After normal execution works, operate shortages, failures, defects, rework and priority changes. Review alert volume, unacknowledged cases, overdue cases and misclassification weekly. Compare predicted with actual completion so planning learns whether it can trust the feedback.

Phase 3: Scale a governed template

Separate the common template from true local differences. Standardize identifiers, states, event fields, exception classes, KPIs, roles, interfaces and evidence. Copying the system and allowing unrestricted local changes makes future maintenance grow faster than the number of sites.

Define go-live and rollback criteria: critical defects, master reconciliation, device and interface readiness, user training, support coverage, restore test, procedures and legacy-system disposition. If parallel entry is used, give it a purpose and an end date.

Three-year TCO for process management

Compare candidates using the same site, user, device, volume and currency assumptions. Software price is only one part of the operating commitment.

Include internal effort from production, planning, quality, IT and finance. Do not import a generic percentage improvement as a forecast. Establish your own baseline for progress-checking effort, unrecorded WIP, confirmation delay, exception acknowledgement, rescheduling lead time, reconciliation variance, trace investigation, premium freight and overtime.

For the link between execution data and cost, see our manufacturing cost management system guide.

Connect process KPIs to action

ISO 22400-1 provides an industry-neutral framework for manufacturing operations management KPIs across batch, continuous and discrete manufacturing; the 2014 edition was confirmed in 2025 and remains current. Whether or not a project adopts the standard, it should define purpose, formula, data elements, time range, units and accountability.

Useful candidates include schedule adherence, WIP dwell time, work-order lead time, first-pass yield, exception acknowledgement time and the delay between shop-floor occurrence and ERP confirmation. Every KPI should have an owner, review frequency and action threshold. Daily execution, weekly improvement and monthly management do not need the same dashboard.

Additional checks for factories in Thailand

Treat Thai, English and Japanese language coverage as an operating requirement across reason codes, instructions, alerts, training and support—not merely translated navigation. Confirm shift coverage, local escalation, regional ERP connectivity, data location, electrical and network resilience, and the responsibilities of headquarters, local factory and solution provider.

Thailand BOI material on Smart and Sustainable Industry describes digital technology and software supporting manufacturing processes in the context of efficiency-enhancement measures. Eligibility depends on the activity, timing, investment category and current rules, so never make an incentive the unverified foundation of the business case.

NIST’s Smart Manufacturing Systems Test Bed makes manufacturing data streams and repository resources available for digital-thread and performance research. It is not a product endorsement, but it illustrates why machine data should be structured as reusable events connected to models and performance evidence rather than trapped in a dashboard.

Pre-implementation checklist

If the project team cannot answer even one of the following questions, it is worth completing the operating design before attending another product demonstration.

1. Can the factory identify the BOM, routing and inspection-specification revision used by each work order?
2. Are the conditions and approver for releasing a work order to the shop floor defined?
3. Are the states of the work order, operation, WIP, quality and exception unambiguous?
4. Does the design distinguish the source timestamp from the receipt time and monitor clock synchronization?
5. Are the production-event rules defined for retry, delay, duplication and correction?
6. Are the first owner and due time defined for delay, stoppage, shortage and defect exceptions?
7. Is the information handed to rescheduling defined, together with version control for the plan returned to the shop floor?
8. Can the system reconcile quantity conservation through lot split and merge?
9. Are temporary operation, retry and reconciliation ownership defined for an ERP-interface failure?
10. Are the purpose and pass/fail evidence separated for PoC, FAT and SAT?
11. Are the decision owner and criteria defined for go-live and rollback?
12. Does the three-year TCO include internal effort, interface maintenance, regression testing and contract exit?

Frequently asked questions

Must a manufacturing process management system eliminate every spreadsheet?

No. First establish controlled records for orders, WIP states, production events, exceptions and approvals. Spreadsheets may remain for temporary analysis, but they should not create an ungoverned duplicate system of record.

Can machine data alone provide visible production progress?

Machine events help with cycles, counts and stops, but material wait, quality holds, rework, operator decisions and movement require business context. Link equipment and manual events to the work order, operation and lot.

Does real-time production data automatically prevent late delivery?

No. Detection must trigger an owner, impact assessment, rescheduling handoff, approved plan revision and redispatch. For some decisions, complete and trusted five-minute data is more useful than incomplete second-by-second data.

Are MES and manufacturing process management systems the same?

Terminology varies. Evaluate the governed objects, states, exceptions, interfaces and acceptance evidence, not the product label.

Must a PoC run on one production line for several months?

The purpose of a PoC is to resolve an uncertain hypothesis. What matters is which risk is closed by which evidence, not elapsed time alone. Use representative data to test normal flow, exceptions, communication loss, correction and rescheduling; transfer volume and local-site conditions to FAT and SAT. Keep a pilot that measures operating benefits separate from the PoC so that each decision remains clear.

How should return on investment be measured?

Freeze baseline definitions before implementation and compare the same scope and formula afterward. Record changes in demand, product mix and working days. Do not treat a vendor’s general benchmark as a guaranteed local result.

Conclusion: design who acts after progress becomes visible

The value of a manufacturing process management system is a closed operating loop from approved routing and work release through WIP, timestamped events, exception ownership, rescheduling, reconciliation and standard improvement. Convert broad RFP statements into scenarios and evidence, build acceptance through PoC, FAT and SAT, and include post-go-live operation and change in the three-year TCO. Visibility becomes a delivery-performance tool only when an abnormal condition turns into owned, time-bound work.

TOMAS TECH can help map the current paper, spreadsheet, ERP and equipment-data flow and shape the scope, RFP, PoC and phased rollout for a Thailand factory. Even at the early “which system should own what?” stage, you can contact our team for a practical discussion.

References

• ISA — ISA-95 Series of Standards
• ISO — ISO 22400-1:2014
• OPC Foundation — OPC UA Part 4: DataValue timestamps
• OPC Foundation — OPC UA Part 6: Time synchronization
• NIST — SP 800-82 Rev. 3, Guide to Operational Technology Security
• NIST — Smart Manufacturing Systems Test Bed
• Thailand BOI — Smart and Sustainable Industry
• METI — 2025 White Paper on Manufacturing Industries

*This article reflects public information checked on 30 August 2026 and provides general implementation guidance. Confirm current standards, incentive conditions, contracts, security, quality and legal requirements for the relevant site and industry.*