Production management workflow improvement in a Thai factory starts with a practical question: what exactly must pass from order entry to planning, from planning to the shop floor, and from finished production to quality and shipment? A flowchart with five department boxes will not answer who can approve a change, which order version is valid, or how a blocked lot is prevented from shipping. This guide helps plant managers, production-control leaders, local supervisors and IT teams turn observed handoffs into an RFP and testable acceptance criteria. Every numerical example or proposed metric below is illustrative, not a market benchmark or a claim about a TOMAS TECH customer.
Start with the customer promise, then locate the failed handoff
“Improve the workflow” can refer to very different losses: a customer revision never reaches planning, a feasible plan reaches a line with insufficient material, or a finished lot reaches the warehouse before quality release. Each needs a different decision point and different data. In the first workshop, ask which customer promise the plant must protect—date, quantity, specification, lot, destination—and identify a recent event that threatened it. Trace that shipment backward through quality disposition, production result, work instruction, approved plan and order revision.
At every boundary, record the trigger, input, owner, decision authority, output, recipient and evidence of receipt. “Sent” and “received” are separate events. An email with a revised plan may have been sent; the night-shift leader may still be working from a printed earlier version. ISO’s published guidance on the process approach discusses process inputs and outputs, interactions and accountability. It is useful as a way to ask these questions; it does not prescribe a particular factory software product.
Map handoffs rather than drawing only department boxes
A useful current-state map has one row per handoff: order to planning, approved plan to production, production result to quality, and quality decision to warehouse. Record what arrived, which version, when it arrived, who acknowledged it, what the next person was allowed to do and the condition that sends the work back. Collect real orders, reports and screenshots to test the map. An idealized workshop diagram is a hypothesis until it matches what the day and night shifts actually do.
In a Thai plant, demand may come from a Japanese headquarters, local material availability may sit in a separate spreadsheet, and floor instructions may be in Thai. Translation and local adaptation are legitimate parts of the workflow. The risks arise when a translated item name, unit, lot identifier, date or time zone no longer points to the same transaction. Give each order, revision and instruction an identifier that remains stable across languages and systems. Keep the original request and the approved factory commitment distinguishable.
| Handoff | Trigger and input | Decision owner | Evidence passed onward | Return condition |
|---|---|---|---|---|
| Order → planning | Customer request, revision, requested date | Sales verifies; planning accepts or challenges | Committed revision, change history | Conflicting item, quantity or date |
| Planning → floor | Approved instruction, material and capacity status | Planner releases; shift leader acknowledges | Instruction ID, version, start conditions | Material shortfall, machine stoppage, stale version |
| Floor → quality | Quantity, defects and lot record | Supervisor reports; quality decides | Actual result, inspection target, hold state | Quantity discrepancy or missing identity |
| Quality → shipment | Release decision and finished-goods ID | Quality releases; warehouse checks | Decision maker, timestamp, target lot | Hold or unmet customer condition |
These are questions to settle locally, not universal software defaults. The plant’s quality rules determine whether an electronic approval is necessary, whether a signed paper form is acceptable, and who can act when an approver is absent.
Fill each register line with a real event
For order to planning, record the original customer document, customer and internal order IDs, product revision, quantity unit, requested date and factory response date. If sales can edit quantity, retain the former value and approval. A verbal change may be shared provisionally with planning, but it should not silently replace a confirmed commitment before the formal instruction arrives. For planning to floor, distinguish the release time from the shift leader’s acknowledgement and readiness decision. List tooling, material, machine reservation, operator qualification and inspection equipment needed to start. A missing jig should leave a reason, owner and resolution time, not make the instruction disappear.
For floor to quality, reconcile input, good, rejected, rework and remaining work-in-process quantities in the same unit. A unit must not appear in two incompatible states. Quality needs the lot identity, instruction and inspection-standard revisions and any sample identifier when it accepts work for examination. For quality to shipment, record not merely that a release message was viewed but which finished-goods IDs and quantities the warehouse matched. If a quality decision is withdrawn after packing starts, identify who can stop picking, loading or carrier handover. Only after these details are clear can the team decide where scanners and terminals belong.
Trace a reduced-quantity order through the whole plant
Consider an illustrative confirmed order whose shipping quantity is reduced. Planning issued an instruction in the morning, some material was already issued, and the night shift expects to use a printed copy. Sales must link the change request to the old revision, its effective date and response deadline instead of overwriting one order field. Planning checks affected instructions, allocations, work in process, finished goods and prepared shipments, decides what can be cancelled, and returns a feasible answer to sales. The revised instruction must block new starts under the old one and reach the specific shift leader who acknowledged it. That leader retrieves or invalidates the old paper copy.
Material already issued may be returned, reassigned to another order or held; warehouse and planning reconcile the quantity. Work in process may be completed, stopped or separately dispositioned under an agreed planning and quality decision. Quality checks whether the changed order affects inspection or labels. Warehouse distinguishes new shippable and held quantities, then picks against the revision promised to the customer. At loading, order revision, item, lot and carton count are checked together. If the customer cancels the change and requests the earlier quantity, create another revision rather than reviving the old one: material and quality status may have moved on in the meantime. The evidence is a chain of decisions and acknowledgements, not merely the new number appearing on every screen.
Order to plan: separate requested demand from committed demand
A customer’s requested date is not automatically a delivery date the factory has confirmed. Store the requested quantity, specification, packing requirement and destination alongside the accepted commitment and its revision. If information is incomplete, indicate whether the order is tentative, awaiting approval or eligible for planning. Planning must be able to identify which revision was used when it built and released a plan.
When orders arrive by EDI or email, keep receipt time separate from internal registration time. Define how item codes and units are mapped and how repeated transmissions are distinguished from changes. If the same order number arrives again, the RFP should ask the vendor to demonstrate revision and difference handling rather than creating a second order. For a deeper treatment of external order messages, see our manufacturing EDI integration guide.
A change must carry its impact: materials already purchased, stock reserved, work orders released, quantities completed, and shipments prepared. The planning owner can decide to keep the current schedule, replan or renegotiate with the customer; the software should present the consequences before silently replacing an approved instruction. The decision, reason, actor and time belong in the history.
Plan to floor: distinguish a feasible schedule from permission to start
The planning team may optimize demand against materials, machines, people and routing. This article focuses on the handoff after planning. A good schedule is of little value if the floor sees the wrong revision or cannot tell whether a missing material blocks the start. The separate finite-capacity planning implementation guide covers scheduling choices; here, define what the production team actually receives.
The work instruction should identify the order, item, version, quantity, operation, equipment or equipment group, required material, expected time, quality cautions and explicit start conditions. “Released but not ready to start” can be a valid state when material allocation is unfinished. A printed instruction needs a version and print timestamp plus a procedure for recalling old copies. A tablet needs a rule for stale cached instructions after a network outage. Shift leaders should acknowledge an instruction only after they can act on it.
Material shortage, breakdown or rush-order interruption can return a work instruction to planning. Do not give every operator unrestricted replanning authority or require headquarters approval for every small local adjustment. Define which changes the shift leader can make, which require the local planning manager, and which change the customer promise and must reach sales.
Floor to quality and shipment: completion is not release
A completed part may still await inspection, concession, missing lot data or customer paperwork. Treat “production complete,” “quality released,” “stock allocated” and “shipped” as separate events. If a plant books completed output directly into shippable stock, it should be able to show which checks already occurred and why that rule is valid. A warehouse needs more than a quantity: order revision, destination, packaging, lot, inspection document and partial-shipment approval may all matter.
GS1’s traceability guidance distinguishes critical tracking events—such as receiving, packing and shipping—from the key data elements describing each event. A plant need not adopt every GS1 standard to benefit from the question: what happened to which object, where, when, and under whose responsibility? Define a trace test from received material lot through work instruction, finished lot and shipped lot. A barcode feature alone does not prove that chain is complete.
Quality holds need operational controls. A held lot should not be allocatable or confirmable for shipment. Release should carry the authorized quality user, reason, time and affected quantity. A colored label on a dashboard does not reliably prevent an accidental dispatch if the transaction still goes through.
Agree on the source of truth at each data boundary
ERP, a production system, MES, WMS and equipment data collection can coexist. “ERP is master” is too broad: the ERP may own the item code, while an approved substitute, local work instruction or machine-specific parameter has a different owner. Financial inventory close and real-time movement do not share the same timing. Assign create, change, approve, publish and reconcile responsibilities per data element.
ISA-95 offers a reference for information exchange between business planning and logistics, commonly called Level 4, and manufacturing operations management, commonly Level 3. It is not a vendor ranking or a promise that one named product covers an entire level. NIST’s functional reference architecture likewise describes manufacturing functions and information flows that can inform component-interface specifications. Use these sources to ask which order, instruction, result, stock and quality events cross a boundary.
For every interface, specify identifiers, revisions, units, source timestamps, delivery acknowledgement, failure codes, retries, duplicate prevention, reconciliation and the person who monitors failures. What happens if ERP is unavailable during a shift? Can the floor record output? Which system reconciles it after recovery? If the same result is transmitted twice, it must not double the finished quantity. An API, file, queue or controlled manual entry can be assessed against the same acceptance scenario. OPC UA can help structure information exchange with devices, but a connection alone does not settle the meaning of a signal; verify semantics, clocks and missing-data handling.
Select exceptions before selecting screens
You need not catalogue every conceivable abnormal condition. Choose a few that can cause a missed promise, wrong stock, skipped quality decision or blocked shipment: order revision, material shortage, approved substitute, breakdown, partial completion, defect, rework, lot hold, partial shipment and communications loss. Prioritize situations that recently occurred or would have a severe effect. Use the plant’s own anonymized documents in vendor demonstrations.
For a shortage scenario, demonstrate when planning sees the shortage, which orders have allocations, who can change a purchase ETA, how the shift leader sees start eligibility, and what happens if a substitute is proposed. A red warning is insufficient if the system cannot retain the BOM revision, approved alternative, quality decision and final manufacturing record. The RFP should describe the approval path when an alternative is allowed; it should never assume all substitutions are permitted.
For a network outage, ask whether local transactions can be held temporarily and, if so, with which user, device and time records. After recovery, show that a replay does not duplicate production results. If offline editing is prohibited, define a controlled paper fallback and the rule for entering it later. The plant must know when to stop work and when to continue; this is an operating decision as much as a software feature.
Define measurements before promising an improvement
A target such as “improve on-time delivery by ten percentage points” is meaningless until the order population, promised-date revision, cutoff time and exclusions are agreed. ISO 22400 provides an industry-neutral framework for manufacturing-operations KPIs; it does not set targets for any particular factory. Baseline the actual workflow using consistent event definitions and choose a small set of indicators connected to the loss you intend to reduce.
| Candidate measure | Illustrative definition | Guard against misreading |
|---|---|---|
| Order-change response time | Receipt of change to approved instruction impact decision | Separate customer waiting time and holidays |
| Instruction acknowledgement rate | In-scope instructions acknowledged by the required shift before deadline | Do not count “sent” as “received” |
| Exception decision time | Event detection to replan-or-keep decision | Distinguish approval queue from system outage |
| Same-day actuals capture | Completed work confirmed before daily close | Distinguish later batch entry |
| Hold-control incidents | Attempts or actual shipments involving held stock | Count prevented attempts separately from dispatches |
These definitions are examples, not recommended performance thresholds. Record baseline duration, product mix, order volume and shift pattern. For low-volume plants, show counts and time distribution alongside percentages. Document staffing or maintenance changes made at the same time so that a later improvement is not attributed to software without evidence.
Turn the workflow into an RFP with seven fields
For each representative scenario, write: (1) triggering event, (2) input and version, (3) business rule, (4) decision authority, (5) normal output, (6) exception and recovery, and (7) acceptance evidence. Attach a real or anonymized form. Ask vendors to classify each response as standard, configuration, additional development, manual workaround or unsupported, with cost and maintenance assumptions. A simple “production planning: yes” checkbox cannot reveal the burden of the workaround.
Consider a customer reducing quantity just before shipment. The input includes order ID and revision, old and new quantity and shipment date. The rule separates completed goods, work in process and purchased materials. Sales communicates with the customer, production control changes the plan, and warehouse waits for an approved dispatch quantity. Evidence should show the old instruction can no longer start, the new revision was acknowledged, and inventory was reconciled. During a demonstration, introduce the change halfway through the process rather than watching only the happy path.
Compare the operating cost as well as the initial quotation: who maintains master data and rules, what happens when the customer changes a process, which languages are supported in training and error handling, which support hours cover the local shift, and who owns migration and recovery. Keep the same scope across all bids.
Write acceptance tests for end-to-end handoffs
Screen-level tests prove that a button works, not that a customer order reaches shipment correctly. Take one realistic test order through planning, production, quality and warehouse, inserting an order revision and a defect. At every boundary inspect ID, revision, timestamp, actor and quantity. Use anonymized plant data or synthetic data that retains the plant’s actual complexity.
| Acceptance scenario | Required evidence | Failure example |
|---|---|---|
| Plan replaced after order revision | Both order revisions and affected instructions traceable; old instruction blocked | Old instruction can still start |
| Floor receives instruction | ID, version, receiving user and time recorded | Only a send log exists |
| Partial completion with quality hold | Completed, held and shippable quantities reconcile separately | All completed units become shippable |
| Recovery and replay | Repeated message does not double-count output | One lot appears twice |
| Pre-shipment check | Order revision, lot, release status and quantity match | Held stock can be confirmed for dispatch |
If a numeric threshold is needed, agree on its measurement conditions in the contract and test plan. A response-time requirement, for example, needs concurrency, data volume, network, screen and repeat-count definitions. Include night shifts, Thai UI text and the time difference to headquarters. Local users should conduct user acceptance tests; IT alone cannot determine whether an operator knows the next action.
Pilot a narrow scope but complete the information loop
A pilot can cover one product family, line or customer, yet it should follow an in-scope order from receipt to shipment. Testing only floor data entry may create records that are linked neither to an approved order revision nor to a quality release and dispatch decision. Narrow the plant boundary without severing the information chain.
A practical sequence is to capture actual events, select scenarios, agree data ownership and authority, configure interfaces, train users in the local language, reconcile parallel operation, then accept the handoffs. This is a sequence of evidence, not a universal timeline. If old and new totals differ during parallel operation, compare periods, units, cutoffs, revisions and held-stock treatment before declaring one system correct. Assign a person to explain and resolve each difference.
Three operating checks specific to a Thai plant
First, test understanding in the working language. Thai screens alone are insufficient if errors, delegated approvals, instructions and support are only available in Japanese or English. Define shared terms for good stock, defect, hold and rework, and ask users to explain what they do after each alert.
Second, set authority for local shift hours. Headquarters may be unavailable when a machine fails or a shipment is urgent. Specify which actions local planning and shift leaders can take, which require quality release, and which change a customer commitment. Document delegation and limits on retrospective approval.
Third, evaluate investment support carefully. Thailand’s BOI publishes measures concerning Smart and Sustainable Industry upgrades and efficiency investment. A particular software project does not qualify automatically. Check the activity, eligible expense, timing and application terms for the actual project, and keep any possible incentive separate from the base-case business value. Measure that value through reduced handoff delay, rework, stock discrepancies or missed dispatch conditions.
FAQ: production management workflow improvement
Where should we begin improving a production management workflow?
Choose one recent delayed, blocked or incorrect order and trace it backward from shipment. At each handoff identify the version, decision, owner and receipt evidence. This reveals a concrete boundary to redesign before drawing an ideal future map.
Can we select production management software first?
You can shortlist products, but compare them against the same order-change, shortage and quality-hold scenarios. Feature counts alone do not disclose how responsibilities and exceptions work. See the production management system comparison for broader product-selection criteria.
What is the minimum useful RFP content?
Include scope, users, customer promise, handoffs, sources of truth, representative scenarios, exceptions, interfaces, authority, migration, local-language training, support and evidence of acceptance. Require each vendor to explain standard, configured and custom behavior separately.
How should improvement be measured?
Select a few measures tied to the initial loss, such as order-change response time or instruction acknowledgement. Define numerator, denominator, start, finish and exclusions before baseline collection. Keep volumes and causes next to rates.
How do ERP, MES and a production system divide responsibility?
Allocate ownership per business event and data field, not product label. Map item master, order, instruction, actuals, quality and inventory, then test outage, replay and reconciliation. ISA-95 provides vocabulary for the exchange between business and manufacturing operations.
Conclusion: make one order traceable all the way to shipment
The goal is a workflow in which a customer request becomes an approved plan, a received instruction, a recorded production result, a quality decision and a controlled shipment—with revision history and exception handling intact. Four compact artefacts—handoff register, data ownership register, exception register and evidence register—give vendors a common problem to solve and users a concrete basis for acceptance.
If you are still deciding which boundary to tackle first at a Thai plant, contact TOMAS TECH with an example form or order-change scenario. The discussion can begin with the workflow before product selection.
Sources
- ISO, *The process approach in ISO 9001*: https://www.iso.org/iso/iso9001_2015_process_approach.pdf
- ISA, *ISA-95 Series of Standards*: https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- NIST, *Reference Architecture for Smart Manufacturing Part 1: Functional Models*: https://www.nist.gov/publications/reference-architecture-smart-manufacturing-part-1-functional-models
- GS1, *Traceability*: https://www.gs1.org/standards/traceability
- ISO, *ISO 22400-1:2014*: https://www.iso.org/standard/56847.html
- OPC Foundation, *OPC Unified Architecture Core*: https://profiles.opcfoundation.org/document/1
- Thailand BOI, *Smart and Sustainable Industry*: https://www.boi.go.th/index.php?language=en&page=smart_sustainable
Sources were checked on 6 October 2026. Workflow examples, metrics and tests are illustrative designs, not customer outcomes.
