When implementing a manufacturing process delay alert system, start with a decision: which production order and operation are at risk, what evidence shows the risk, and who must act before the customer promise is affected? A red progress bar alone does not answer that question. This guide is for production control, plant managers and IT teams in Thailand preparing a request for proposal (RFP) and factory and site acceptance tests (FAT and SAT). All numbers used in examples are design assumptions, not product performance claims or customer results.
Progress visibility and a delay alert answer different questions
Progress visibility shows where an order is now. A delay alert identifies a risk while there is still time to change the outcome. If these objectives are mixed in an RFP, a supplier may demonstrate attractive charts while the plant expects actionable early warning. Define the required decision before choosing the screen.
Microsoft’s production floor execution interface lets workers start and stop jobs, report good and scrap quantities, and update job status. Its Gantt chart presents planned jobs by order or resource, material shortage indicators, delivery dates and capacity load, and supports rescheduling. Actual capture and plan adjustment are distinct functions; a plant must define the rules and ownership between them. SAP’s Shop Floor Dispatching and Monitoring Tool describes monitoring confirmations, operation dates, outages and overload, with supervisors adjusting short-term plans. These product documents are examples of possible functions, not a promise that the same features are included in every edition or project scope.
“Turn red when the planned finish time passes” is too narrow. A successor operation may not start because the predecessor is late; a shift may be off; quality may be holding a lot; or a planner may have approved a new priority. Separate late start, slower-than-expected output, queue dwell, missing data and projected customer delivery impact. Each needs different evidence and a different owner.
Define the unit of comparison: order, lot, operation, resource and shift
A sales order may contain several production orders. A production order may be split into lots. An operation may run on multiple machines. Choosing the wrong unit makes even a mathematically correct alert misleading. At minimum, define production order ID, item, planned quantity, lot or handling unit, operation sequence, planned and actual start and finish, good, scrap and hold quantity, assigned resource, shift, calendar and timestamp of the latest update.
Microsoft describes a production order as containing the item, quantity, planned finish date, material and route. If the ERP owns the released order, send its ID and version to MES, then return operation events. Retain both the prior plan and the approved current plan when a route or date changes. Otherwise an alert may accurately compare a job with an obsolete baseline and still be wrong for the business.
Capture must be quick enough to support early warning. Scanning the lot and narrowing the operation and resource choices often works better than having an operator retype identifiers. Machine signals may capture a count, but they may not explain setup, rework, quality hold or material waiting. Combine reliable automatic data with a short reason-code entry where human context is needed. Record whether a time came from the device, server or ERP, and reconcile clocks before comparing them.
How to detect a delivery delay early
Start with a planned time and quantity for each operation. Compare them with current actuals. Estimate the remaining work from remaining quantity, standard cycle time or recent observed rate, available shift time, setup and material. Then add downstream operations, inspection, packing and dispatch cutoff to determine whether the customer commitment is at risk. Make the assumptions visible so a planner can correct them. A predictive model is not a substitute for a defined schedule, current actuals and an accountable decision.
For illustration, suppose an order requires 400 good units. By 14:00 the plan calls for 300, while actual good output is 240. If the last two hours averaged 40 good units per hour, 160 units still need four processing hours. A simple forecast says 18:00. That forecast becomes unusable if the shift ends at 17:00 and the next shift starts at 20:00, inspection takes another hour, or material covers only 80 units. An alert should show “actuals updated 14:03,” the recent rate of 40 units per hour, the next shift start of 20:00 and the material constraint, not just “late.” These are hypothetical inputs; validate the real routing, yields and calendar for each plant.
Use three layers of rules. First, detect missing facts: no report after planned start, offline terminal or inconsistent clock. Second, detect operation deviation: late start, output gap, rate decline or excessive dwell. Third, calculate commitment impact from the remaining route and available capacity. Do not label missing data as a confirmed delivery delay. Send a data-quality alert to the person who can restore the information.
Prioritize by recoverability as well as lateness. Consider time until commitment, affected quantity, alternative resources, approved customer priority, quality hold and whether intervention can still recover the schedule. Configure initial thresholds by line and revise them from observed false alarms and missed cases. Keep customer priority in an approved master rather than changing it silently after a phone call.
Turn a notification into corrective action
Each alert needs an ID, order, operation and lot, detection time, evidence, projected impact, owner, acknowledgement deadline and state. Keep states such as new, acknowledged, in action, monitoring, resolved and false alarm distinct. “Email opened” is not the same as “lot checked on the floor.” Store who changed the state and when.
Route material shortage to purchasing or stores, breakdown to maintenance, quality hold to quality, and planning mismatch to production control. The handoff should include observed facts, cause code, proposed alternative and decision deadline. Require acknowledgement, especially across night and day shifts, so an unresolved alert is not left in one employee’s inbox. A useful queue shows what can still be recovered, not merely the number of red cards. When a projected delay affects a customer commitment, send confirmed facts and response options to sales; a provisional calculation should not be presented as a confirmed delivery date.
Set escalation times from the plant’s production rhythm. For example, an unacknowledged alert might go to the shift leader after ten minutes, while an unresolved material decision might go to production control after thirty minutes. These are examples, not universal targets. Group repeated alarms from one underlying cause under an order-level case and retain the suppressed event count. Otherwise the system can hide noise without fixing the cause.
MES and ERP progress integration
An initial architecture often assigns sales orders, production orders, due dates, item and route masters to ERP, with starts, completions, quantities, downtime and quality holds recorded by MES or the process system. The actual system of record must be written down for your factory. Microsoft notes that production feedback can record time, material consumption, quantities, status and errors, and that floor execution feedback updates production journals. That describes its product; it does not guarantee automatic integration to a different ERP.
List each interface separately: released order, plan revision, route master, resource calendar, actual event, correction and alert status. For each, specify direction, key, version, frequency, maximum delay, retry, duplicate prevention, reconciliation and owner. “Send completion in thirty seconds” has little value if the receiving ERP imports a batch every fifteen minutes. State which value is authoritative at each stage.
Use a unique event ID to make retries idempotent. Separate transport receipt, business validation and posted result. A duplicate completion must not double good quantity. Corrections need a link to the original event, reason and approval rather than an invisible overwrite. For the related record-control problem, see our manufacturing daily report approval workflow. For a wider cost breakdown including shop-floor devices and interfaces, see the process management system cost guide.
Measure the current operation before requesting quotes
Review a representative recent period, such as four weeks, and trace when a delay was first known, who acted and what happened. Four weeks is a scoping choice, not a statistical benchmark. Include high-impact products, day and night shifts, and at least one line where the owner will participate in a pilot. Record discovery, acknowledgement, cause confirmation, alternative selection and final delivery outcome.
Walk the route of the real information: work ticket, lot label, whiteboard, spreadsheet, verbal call and ERP transaction. “Finished” may mean processing ended, a lot reached inspection, quality released it, or ERP posted inventory. Choose the event relevant to the promise. Specify whether internal timestamps are UTC with local display or stored in local time. Test holidays, shifts and time zones where multiple sites are involved.
Measure timely and correctly keyed actuals, not raw entry count. A record entered next morning can make a report digital but cannot provide an early alert. If one shift has more late entries, examine terminal location, login friction, permissions, language and field count before changing alert thresholds.
What to put in the RFP
Lead with the outcome: how far in advance should a specific type of delay be recognized, who must decide within what time, and what evidence must remain? Categorize requirements as essential for the pilot, later phase and optional. Ask suppliers to state whether each item is standard, configurable or custom.
| Area | Requirement to specify | Acceptance evidence |
|---|---|---|
| Capture | IDs, quantities, states, shifts, timestamps and corrections | Device event and source-data reconciliation |
| Detection | Late start, output gap, rate, dwell and delivery impact as separate rules | Boundary, holiday and normal-case tests |
| Notification | Role-specific route, duplicate suppression and escalation | Sent, received and acknowledged times |
| Action | Cause, owner, deadline, alternative and closure | Audit history by alert ID |
| Integration | System of record, retries, corrections and idempotency | Failure, recovery and duplicate-event tests |
| Operations | Languages, rights, offline work, backup and support | SAT on actual shift and network |
Replace vague “real time” language with measurable intervals: terminal confirmation to current list, detection to notification, and validated MES event to ERP posting. Derive targets from the decision window. Test offline queuing, ordered replay and duplicates. Require audit trails for threshold changes as well as manual closures. A supplier’s “99% detection” claim is meaningless without an agreed true-delay definition, denominator, detection deadline and false-positive method. Use anonymized past incidents as test cases. Show manually entered facts separately from machine-calculated status: a quality hold, material arrival delay or customer priority change may be confirmed by a person, while the resulting schedule forecast is calculated.
FAT and SAT: scenarios worth testing
FAT checks logic and configuration before installation. SAT checks real devices, Wi-Fi, shifts, rights and workflow at the plant. In each test line, link input, expected result, notification owner, stored evidence and pass criterion. Agree these before the demonstration.
Test a correctly progressing order and confirm no alert is raised. Test a late start, including a holiday or shift break. Test an operation behind plan when downstream capacity can still recover the delivery; operation and commitment alerts should differ. Test simultaneous material shortage and machine breakdown while keeping both causes linked to the same order.
Disconnect a terminal, then replay queued actuals. Check how a resolved alert history responds to an event that arrives late. Send an actual event before a revised route arrives. Retry the same completion event and confirm no double count. Transfer an open case to a new shift. Release a quality hold and confirm the correct inspection time is used. Test a late rate decline just before planned finish, a revised customer due date, and unauthorized threshold changes.
In SAT, have Thai-speaking operators and Japanese or English-speaking managers read the same incident. Cause codes and status must mean the same thing in every interface language. Confirm the alert can be acknowledged and acted on even under the actual factory network conditions.
Start with one line and improve the rules
Select a line where delivery risk matters and the production owner can participate. First capture order, operation, quantity and time, while separating late-start from missing-data notices. Next add remaining-time calculation for representative items. Then add downstream delivery impact and cross-functional escalation. This sequence is a practical design option, not a prescribed duration or guarantee.
Run paper or spreadsheet records alongside the new system for a defined period. When totals differ, inspect the physical lot, terminal log, quality record and ERP transaction rather than assuming either source is correct. Matching daily totals can conceal an operation time reported a day late. Decide cutover from timely-entry rate, false-alarm causes, acknowledgement time, recovered cases and unresolved case backlog.
ISO 22400-1 provides an industry-neutral framework for manufacturing-operations KPI concepts and terminology. It does not prescribe an alert threshold for your line. Define the metric name, formula, timestamp and denominator. Review missed and false alerts by case each week: stale master, late actual, flawed rule or misrouted notification. Do not hide a master-data defect by relaxing the threshold.
Measure useful time, not alert volume
More alerts do not mean a better system. Record time gained before a risk becomes irreversible, time to acknowledgement, cause confirmation and corrective action. A case discovered at 10:00 and recovered by changing a machine allocation at 11:00 is stronger evidence than a count of red notifications. An alert ignored until the planned 15:00 finish demonstrates a workflow failure even if the detection algorithm was correct.
Keep separate timestamps for the first human observation, first system detection and actual delay. If a supervisor saw a risk first, retain that fact; identify whether the system was late, the data were missing or the case was out of scope. Avoid crediting every on-time delivery to the alert. Record the action and evidence that plausibly changed the outcome.
False-positive rate and missed-risk rate have different denominators. One measures burden on the floor; the other measures exposure to a customer failure. Ten alerts with two false alarms describe alert burden; ten genuinely risky cases with two missed describe a detection gap. Both happen to be two out of ten, but they cannot be substituted or combined. Label historical cases jointly during the pilot, with “undetermined” available where facts are incomplete. A short pilot does not support a sweeping detection-rate claim. Executives should compare monthly on-time delivery rate with the count and detection time of risks, and the number of preventive actions taken before commitments were missed.
Quality hold, rework and partial delivery
Processing complete is not always available-to-ship. Track hold, awaiting inspection, accepted, reinspection, rework and scrap separately. If rework returns to an earlier operation, record it as a distinct event or route branch; prevent a second good-quantity posting. The display should answer how many units can actually move downstream now.
Partial shipment adds separate commitments. Store the quantity needed for each dispatch, inspection release, packing, customs and transport handover cutoff. A production order may be late overall while the first shipment is safe; it may also finish one day early at the machine but still miss the warehouse handover window and therefore the customer promise. Prioritize the affected promised quantity, not only the order’s total value.
When an urgent job is inserted, keep both the prior and approved revised schedules. The prior promise does not disappear, while operators need to know the current authorized sequence. Alerts should guide a resource decision rather than become a blame counter.
Govern thresholds and role-based views
If shift leaders can never adjust thresholds, false alarms may continue until an administrator is available. If anyone can silence alerts, the most urgent risk can disappear from view. One workable policy is for production control to propose the normal tolerance by item or line and for the accountable plant manager to approve it. Record the change time, reason, proposer and approver. A temporary suppression for scheduled maintenance must have an expiry time and automatically restore the previous threshold or alert rule when the window ends. Decide in advance whether a threshold revision recalculates historical alerts or applies only to future events; preserve the version used for each past decision.
Design views around decisions, not only departments. Sales needs confirmed facts separated from provisional shop-floor estimates before speaking to a customer. Operators need the orders they can act on and the cause information necessary to respond. Executives need an aggregate of unresolved customer impact, decisions awaiting approval and recovery deadlines, rather than every individual alarm. The Thai operator interface and Japanese or English management views should use the same controlled cause-code meanings, verified during acceptance testing.
Cost and ownership in the supplier quote
Compare more than software licence. Ask for separate amounts for route-master preparation, ERP interfaces, terminals and wireless, multilingual screens, notification setup, FAT/SAT, training, night-shift support and post-launch rule tuning. If external messaging is used, include its cost, outage path and data handling. Compare quotes using the same line count, user count, interface list and master-data condition. Our broader production management system comparison helps frame platform choices; the detection and response tests here still need their own scope.
Define who may change thresholds, who updates routes, and who investigates a flood of alarms. State in the contract how many threshold changes are included during the first year, who performs them and what counts as an extra change. Availability of the application is only one service measure; capture, detection, notification and ERP integration each need monitoring ownership. Specify temporary operation if a defect remains at acceptance and which configurations can be reused in the next plant.
Five decisions to settle internally before procurement
First, define the alert population. You need not monitor every order with identical detail on day one. Begin with product families where delay has the greatest customer impact: urgent low-volume work, high-volume items crossing several operations, or products with long inspection lead time. List exclusions explicitly so nobody interprets an order missing from the dashboard as safe. Agree the criteria for adding more lines and items later.
Second, agree what “operation complete” means. The last part leaving a machine, good quantity confirmed, and the next operation accepting a lot are different events. State which event satisfies the plan for each operation. Where quality release is required, keep processing completion separate from availability for shipment. Otherwise each department may have a different, internally correct number.
Third, allocate authority for plan revisions. A shift leader may change the shop-floor sequence without changing the customer commitment. Specify separately who may change operation sequence, production-order finish, and customer due date. Record the previous plan, approved revision, reason and approver. This makes the alert baseline auditable.
Fourth, register constraints before suggesting recovery options. A free machine is not a valid substitute unless it is qualified for the item and the required tooling, material and operator are available. Overtime and subcontracting have quality, safety and contract conditions too. Separate options shown by the system from actions requiring human approval, and name the owner who keeps resource capabilities current.
Fifth, decide when and how to contact the customer. A forecast may change, so do not send a provisional shop-floor alert directly to a customer without a controlled process. Give sales confirmed facts, forecasting assumptions, alternatives and the next update time. Waiting until a delay is certain discards the value of early detection, while presenting an unverified estimate as a fact creates a different risk. Put internal decision deadlines and authority for external communication in the RFP.
Software cannot settle these five decisions by itself. The buyer should draft rules, test them against real delay cases, assign an owner to exceptions and revise the rules. An anonymized order that previously caused a difficult decision is more revealing in a supplier demonstration than an idealized on-time order.
Frequently asked questions
Is spreadsheet color coding enough for process delay alerts?
It may be sufficient for one line with few orders, timely actual entry and a clear owner. Multiple shifts, plan revisions, parallel resources, quality holds and audit requirements make a spreadsheet harder to govern. Measure missed cases and response delay before selecting a system boundary.
Does early delivery-delay detection require AI?
No. An approved plan, correctly keyed actuals, remaining route and working calendar support transparent rules. Predictive models may help with variable cycle times or failure risk, but data quality, versioning, explanation and responsibility still need design. Begin with rules people can verify.
Where should MES–ERP progress integration begin?
Align the production order ID, route version, planned time and actual event ID. Then test corrections, retries, holds and out-of-order delivery. Do not demand every possible bidirectional field on day one; fix the minimum data and acceptance conditions for the delay decision.
What is the minimum RFP, FAT and SAT scope?
Define delay, actual capture time, owner, response, system of record, corrections, retries, holidays and shifts in the RFP. Reproduce normal, boundary, compound-cause, out-of-order and duplicate cases in FAT. Verify actual devices, languages, shift handover and offline recovery in SAT. Passing means the right person can see evidence and record a response, not just that a tile turns red.
Conclusion
A manufacturing process delay alert system is a decision workflow around a common plan and actual record. Separate missing data, operation deviation and delivery impact; assign ownership through resolution; and make every rule testable. Start with one line, compare real cases, refine the thresholds and expand only after the floor can use the alerts.
If your Thai plant is mapping order progress and the delivery risks it wants to detect, contact TOMAS TECH with one missed-delay example and the current plan and actual-data flow. We can discuss a pilot boundary or an RFP draft before you commit to a platform.
