Emergency Production Order Resequencing: A System RFP Guide for Factories

After production orders have been released to the shop floor, a key customer asks for one order to run today. A system for emergency production order resequencing must do more than let a planner drag a bar on a chart. It must show the orders displaced, materials already picked, equipment in use, work in process (WIP), and promises to other customers, then preserve who authorized the insertion. This guide focuses on post-release dispatch sequence changes for Thai factories combining ERP, APS, production management, and MES.

What changes, and what does not

Here, a priority change means changing which of several already released orders a work center will process next. It does not itself change ordered quantity, BOM, routing, or the production order version. Those transactions need the controls in our released production order change guide. If work must be divided or combined, see production order split and merge control. The decision here is which existing order runs next.

Suppose orders A, B, and C wait at one assembly line. B has a customer pickup this afternoon. Sales asks to insert urgent order X after A. Moving X forward may delay B, consume a component reserved for C, and add a changeover. A flag saying “X is top priority” proves none of those effects acceptable. Treat the old and proposed queue, revised completion times, material allocations, WIP, alternatives, customer communication, and approval as one decision.

Microsoft describes a released production order as available for shop-floor execution and material picking. A post-release change therefore has to account for execution, not only the planning chart. Oracle describes a dispatch list that can review and adjust operation start times and sequences on a resource, followed by a schedule repair. These are product-specific examples, not promises that every system behaves identically.

Define “urgent” and the decision rights first

“The customer is in a hurry” means different things to different shifts. Classify requests, for example customer line-stop prevention, quality replacement, routine pull-forward, or internal stock replenishment. Require the requester to supply the original request and desired time. A category informs comparison; it does not automatically grant priority. Consider contractual obligations, potential loss, existing committed dates, and feasibility. A workflow where any unplanned demand passes simply because someone calls it urgent will soon lose credibility.

Separate the right to request from the right to apply. Sales records the customer request; the planner simulates alternatives; materials and quality staff check stock and hold status; the shop-floor supervisor assesses changeover and safety; the sales owner checks customers who may be delayed. The plant names the final approver. If a night-shift supervisor has emergency authority, define the conditions, when retrospective approval is due, and what can still be reversed if it is refused. Authorization may vary by delay, customer class, cost, or safety and quality impact, but start with a comprehensible matrix and refine it from exception history.

Set a frozen boundary by operation state

A frozen horizon is not merely “today’s plan cannot move.” A job in progress, a job with fixtures installed, an order whose components have been picked, and one tied to an arranged pickup present different reversal costs. Oracle Production Scheduling provides a product-specific fixed time fence that can firm released work orders starting within it when the option is selected. That feature alone does not define every shop-floor exception or approval. Define the planning fence and execution-state restrictions separately.

At minimum, distinguish unprepared, allocated, picked, setting up, running, under quality decision, and completed. An unprepared job may allow routine simulation. A picked job needs a return and reallocation owner. Setup needs a recovery estimate. Removing a running job from a screen does not stop a machine; automatic overwrite must be blocked until the supervisor confirms a safe state. Quality-held WIP cannot be dispatched by a scheduling override. Put the state transition rule in both approval and MES execution paths.

Decide whether the boundary covers a line, a machine, a time interval, or an event. A two-hour freeze may expire while a stopped machine makes no progress. Protecting “the job now running and the next committed job” can sometimes match the floor better. The right rule depends on process, setup, material handling, and labor. Replay actual emergencies and verify that work which cannot safely be stopped cannot be moved. An exception to the boundary needs a reason, authorized person, and effective time.

Test an insertion against four constraints

Materials. On-hand stock is not necessarily available to X. Separate allocation to another order, quality hold, lot rules, substitute restrictions, expected replenishment, and physical picking. If reallocating a component to X prevents B from starting, show X’s feasibility and B’s delay together. If parts are borrowed, record their original allocation, replenishment deadline, and whether a customer-approved substitute is involved.

Capacity. Include setup family, tooling, inspection equipment, maintenance outages, qualified workers, and shift boundaries, not only machine free time. Microsoft documents finite-capacity planning that considers reservations and moves work later when capacity is missing. With finite materials, the start requires capacity and material at the same time. If a “free” slot looks implausible, check whether manual reservations, shared tooling, or subcontract steps are absent from the data. For the underlying model, see our capacity calendar and production scheduling guide.

WIP. If B’s preceding step is complete and its container is already beside the line, inserting X may create a storage problem. Some processes limit the time between steps or enforce FIFO for quality. Check whether B’s WIP exceeds its wait limit, C’s upstream station becomes starved, or the downstream inspection queue overflows. Display inter-operation WIP and storage capacity, with alternate locations and quality conditions.

Customer promises. A one-hour factory delay may miss a once-daily truck and shift customer arrival by a day. In another case a shipping buffer absorbs it. Keep operation completion, factory dispatch, estimated customer arrival, and the formally promised time separate. Replanning must not silently overwrite the promise. List all displaced orders and the customer contacts required. Our delivery-date management RFP guide explains the date distinction in more detail.

Show displaced orders, not just the new top priority

Approval should focus on what is sacrificed. Put old and new sequences side by side, highlight each moved order, and compare expected start, finish, dispatch, and arrival in the same units. Show material gaps, extra changeovers, overtime or outsourcing, quality holds, and WIP storage risks separately. Even a claim of “no impact” needs the calculated resource scope, horizon, timestamp, and missing events.

Define tie-breaks among orders with the same priority. A possible order of tests is committed delivery, material readiness, setup similarity, request time, and contractual obligation. A weighted score alone cannot authorize breaking a promise. Treat safety, quality, and binding commitments as hard constraints; use changeover efficiency for optimization within those limits. Save the rule version and input snapshot so a later rule change does not rewrite why an earlier request was approved.

Make the APS, ERP, and MES boundary explicit

ERP often owns orders, allocation, inventory, cost, and customer commitments. APS may calculate candidate sequences from material and capacity. MES owns the next job displayed and execution events. Yet never infer ownership merely from product labels. Define the authoritative system per event. “APS owns candidate plan; MES owns dispatched sequence; workflow owns approved request and customer impact” is possible, provided everyone can identify the one active version on the floor.

Do not send an APS simulation to shop-floor devices. After approval, recheck current execution and constraints, then send an effective time and version to MES. MES acknowledges receipt and updates only unstarted operations. If an operation has started or the machine or material state has changed, it returns a conflict rather than silently overwriting. Use request ID and version for idempotent retry after a timeout. Record send, receipt, device update, operator confirmation, and actual start as distinct events. Give supervisors a defined fallback for offline devices.

Paper job lists also matter. A printed morning queue and a changed tablet queue can lead operators to follow different instructions. Print version or expiry time, assign old-copy withdrawal, and make the current instruction obvious. Standardize Thai, Japanese, and English terms for requested, approved, applied, and acknowledged; do not rely on color alone. Show plant time zone explicitly and test conversion against UTC ERP timestamps.

Write scenario-based RFP requirements

“Drag-and-drop supported” is a weak requirement. Ask vendors to demonstrate: A→B→C have been released; B is committed for next-day arrival; X is requested after A; X’s stock is allocated to B; inserting X makes B a day late at the customer. The system must display the constraint and delta, leave MES unchanged before approval, and retain the original queue if rejected. Use anonymized real resources, shifts, components, WIP, and customer conditions, not only vendor sample data.

Describe the full path: request and reason code, alternative queues, frozen rules, material/capacity/WIP/promise impact, approval, dispatch and device acknowledgement, cancellation and recalculation, audit and notification. Specify performance and freshness: how quickly does a candidate return, how old may shop-floor events be, what happens on a state change, and why was no feasible option found? Set thresholds from measured plant needs rather than the vague word “real time.”

Nonfunctional requirements include offline operation, idempotent retry, concurrent requests, role changes, log retention, monitoring, backup, recovery reconciliation, and multilingual devices. When Y is approved while X is still being simulated for the same machine, X’s old candidate must be revalidated before approval. Microsoft’s scheduling-engine documentation gives one product-specific example of capacity reservation conflict in parallel scheduling. Regardless of vendor, a current-state recheck is a useful acceptance case.

Data quality determines whether a “best sequence” is credible

Calculation cannot repair inconsistent inputs. Ten parts in ERP may mean only three usable parts after quality hold and allocation. A missing holiday makes the promised completion wrong. Build a small data register for the pilot line: item, lot, allocation, routing, resource, worker qualification, shift, and customer order line. Give every data set an owner and permitted delay. If a required input is absent, “decision unavailable” is safer than a green result calculated on an empty field.

Event freshness is especially important. If A’s start reaches MES thirty minutes late, APS may wrongly treat it as moveable. Define how approval handles network loss, night-shift entry delays, and corrected actuals. A temporary supervisor confirmation can guard a resource with delayed events. Preserve what was known at decision time alongside later corrections; do not quietly rewrite history.

Separate confirmed and estimated materials and capacity. Supplier promise, warehouse receipt, quality release, and line picking are different events. Calendar capacity and a machine actually released from maintenance are different too. Show uncertain inputs and the evaluation time per candidate, rather than one green status. Improving event capture and master data may bring more value than adding another optimization algorithm.

Include a human fallback for exceptions

Night-shift APS outages, disconnected MES devices, and urgent calls when the sales approver is unavailable require a controlled paper or offline request. Record request ID, resource, old/proposed sequence, running operation, material check, displaced customer, interim approver, effective time, and whom the floor was told. If approval is verbal, record who said what and when, then reconcile it into the official history after recovery. An outage is when traceability matters most.

Before bulk re-sending a plan after recovery, fetch which operations started, finished, or stopped during the outage. Do not overwrite physical progress with an old plan. Let the supervisor reconcile differences. If a printed instruction conflicts with a terminal, operators must have a plant-defined stop-and-confirm procedure, not a personal choice. Equipment safety remains a hard constraint even when a delivery is urgent.

Cross-border communication needs an owner too. A late-afternoon request in Thailand may come from a Japanese head office and affect the next morning’s export truck. Decide who may approve a changed customer promise and by when the customer must be told. A sent notification is not customer consent. If work is resequenced before agreement, make that exposure explicit in approval.

Questions to ask vendors during selection

Ask each vendor to reproduce three failures, not merely show a polished Gantt chart. First, B starts after the simulation but before X is approved: will the old candidate be rejected? Second, another department reallocates material: will the system prevent double use? Third, MES receives a message but its reply times out: can a retry apply the sequence exactly once, and who confirms the floor received it?

Distinguish possible, standard, configurable, and custom-developed. Dragging order cards may be standard while calculating customer-arrival impact is custom. Role configuration may be standard while Thai reason codes or shop-floor display have limits. Record demonstrated product version, prerequisite data, license, maintenance, outage procedure, and upgrade compatibility per requirement. A cheap license can conceal expensive, unusable approval-screen work.

Map every vendor answer back to an acceptance condition. If a product cannot display affected customers itself, can integration with ERP order lines and shipping schedules supply it? If the approver still cannot see the impact, the requirement is unmet. Conversely, a reliable request, impact, approval, and dispatch flow on one line may be a sound first release even without whole-factory optimization. Evidence for handling the specified exceptions matters more than a feature count.

FAT and SAT must test rejection paths

FAT should verify configured rules before using the real plant; SAT should confirm actual equipment, devices, network, and users through shop-floor acknowledgement. Define these terms in the contract. Write tests with inputs, expected outputs, logs, and owners, not “screen displayed.” Replace example thresholds with plant measurements.

In SAT, observe whether a supervisor and operator identify the same next job from the device and paper. Test a disconnected terminal, shift handover, misunderstood material label, Thai interface, and network failover. A “no impact” result deserves scrutiny for omitted operations or stale events. Run exceptions over several days and compare insertion volume, approval delay, replanning, and plan-to-actual variance with a baseline.

Start with one line, then extend

Choose a line with frequent emergency insertions and measurable customer impact. Reconstruct perhaps 10–20 historical requests, mixing approved, rejected, and failed cases, including the queue, authorization, materials, shop-floor state, and delivery effect. This is an illustrative pilot sample, not an industry benchmark. Missing records themselves identify a control gap; separate data problems from undefined policy.

Next, make execution states and time trustworthy. A second-by-second frozen check cannot help if job starts reach MES thirty minutes late. Verify IDs across order, operation, resource, lot, and customer order line and write an ERP–APS–MES event contract. During parallel running, display candidates but let humans authorize application; compare decisions with the old phone-and-spreadsheet process. Classify differences as data, rule, approval, or device synchronization before expanding automatic dispatch.

Measure both benefit and harm: response time to urgent requests, unauthorized insertions, delayed displaced orders, added changeovers, time spent finding material, and rework from obsolete job lists. Fix denominators such as requests, resource hours, or affected customer lines. A system that speeds X while repeatedly delaying normal orders is not necessarily improving the plant. A short pilot cannot prove seasonal or long-cycle gains.

Store each approval as searchable data

Screenshots alone cannot answer later why B was delayed. Give each request a unique ID and structure requester, reason, original customer message, resource, operation, urgent order, displaced orders, old/new queue, simulation time, input timestamp, rule version, approver, and effective time. Use free text for context, not the only place for key evidence. Keep every simulation version; link the approved version to the one actually dispatched.

Materials and customer promises may change later in other systems. Save the important values seen at approval time together with source IDs and timestamps. If B’s promise is renegotiated tomorrow, the system should still show which promise the approver saw today. Set retention, access, and correction controls under company policy. RFPs can specify who may search an audit case and how quickly it must be retrieved.

Cancellation is not always one “undo” button. Picked material may need return or transfer. A customer already told about delay needs a correction. Devices that received X’s queue need a cancellation version and acknowledgement. Once work starts, another planning request may be safer than reversal. Define these boundaries by state so “approved” does not remain on screen while the floor runs a different instruction.

Measure the operating result of each sequence change

Do not measure only how many minutes X finished early. Track time from request to feasible answer, cases needing data correction, overdue approvals, failed dispatches, and promise violations among displaced orders separately. A faster answer followed by more material-related failures is not an improvement. More rejected insertions can be healthy if the plant explains why quickly and agrees on alternatives with customers.

Keep denominators distinct: per insertion request, per affected customer line, and per resource hour. For displaced work, record not only on-time rate but delay magnitude and advance-notification rate. Save the forecast immediately before and after the request so an order already late is not blamed on the insertion. If customer receipt events are unavailable, label shipment time as a proxy rather than calling it customer arrival.

Include floor burden: added changeovers, tooling moves, WIP transfers, material returns, and withdrawal of obsolete instructions. Review a few cases weekly with the people doing the work. Ask which constraint was missed and which approval stalled, then change a specific data field, authority rule, or terminal display. Avoid turning every observation into an unverified monetary estimate.

Close the case only after customer communication

An applied queue is not a completed case if B’s customer is unaware of a changed arrival. Assign each affected customer order line to a sales owner and set a contact deadline. Communication should state the revised shipment outlook, available alternatives such as partial delivery or another truck, and the next update time. Record when the plan was approved and when the customer accepted an alternative as different events. If customer consent is contractually required, make it an approval prerequisite.

For X’s customer, keep desired time separate from the formally committed time. If the simulation is feasible but component quality release is pending, say it is conditional. Keep desired time, simulated result, approved promise, factory completion, dispatch, and receipt separately. If a condition fails, assign an owner to update the customer. This evaluates success against a promise, not merely a machine start.

Transport sits outside the production line but changes the decision. Check whether B can still catch the truck, whether expedited freight is needed, and whether export paperwork deadlines are met. If the planning engine does not model transport, require confirmation from logistics or sales before approval. Visible unresolved conditions and a responsible reviewer are more valuable than pretending one application knows everything.

Customer contact may require several updates after another machine outage. Link calls, emails, alternatives, and reply deadlines to the case ID so a substitute sales owner can reconstruct events. Preserve both original and renegotiated promises; otherwise later analysis cannot separate factory-caused delay from a customer-requested change. Even a “no customer impact” conclusion should show the scope and exclusions used. Subcontract steps, warehouse holidays, and carrier cutoffs may have been missed. Audit cases classified as no impact against actual delay and feed missed constraints back into the rules. Close the case after checking X and displaced orders through completion, shipment, and required customer communication, with owners and due times for any unresolved difference.

Example decision: insert X or decline it

Assume A is running, B’s material is picked, C is unprepared, and X may prevent a customer line stop. X has components but B’s setup uses a shared fixture. Option 1 inserts X after A, adds two fixture changes, and delays B’s factory finish while still meeting its truck. Option 2 completes B first, reducing setup but missing X’s requested arrival. The planner presents both, materials staff confirm X’s lot status, and the supervisor checks that the change cannot cause a mistaken start while A runs. The approver compares the benefit to X against the burden on B.

The result can change with one fact. If B’s truck runs only once a day and option 1 moves B’s arrival to the next day, option 1 must not pass automatically. Ask B’s customer owner about an alternate truck or partial shipment, or examine another machine, overtime, or subcontracting. Declining X can be the right answer. The system’s job is to explain quickly and reproducibly what can be done and why something cannot. This scenario is illustrative; its times and constraints are not typical values.

Frequent failures

Adding only a “highest priority” flag

A flag states intent. Recalculate material and capacity and show shortages before approval, then revalidate just before application.

Letting sales and the floor keep different queues

Define an authoritative version, dispatch status, and terminal acknowledgement. Otherwise sales Excel, APS, and MES can all claim to be current.

Freezing too much or too little

An entire day locked prevents useful exceptions; no restriction moves setup and running jobs. Use operation state plus authorized exceptions, then refine from rejected cases.

Overwriting a promise with a plan date

Keep the commitment; show the gap and route it to approval and customer communication.

Leaving an obsolete MES or paper list after approval

Approval is not application. Track send, receipt, device update, operator confirmation, and start separately, with a recovery owner.

FAQ: urgent insertions and dispatch priority

Can APS alone manage urgent order insertions?

APS may calculate options, but without current starts, stops, and material issues it may approve an impossible one. Define ERP order/allocation, MES execution, and approval workflow integration. A single product may perform several roles; authoritative events still need definition.

Who should approve a production sequence change?

There is no universal title. The approver needs authority over displaced customer commitments, material, setup/overtime, and safety or quality impact. Separate requester and approver, specify emergency provisional authority, and save which impacts the approver saw.

How many hours should the frozen window be?

There is no universal number. Protect running work, picked material, setup, subcontracting, and transport commitments by event, adding a time window where useful. Replay historical cases to test whether uninterruptible work stays protected.

When is an order change needed instead of resequencing?

Changing quantity, BOM, route, or lot structure goes beyond queue order. Use version control or split/merge procedures with quality and cost review, then return the resulting orders to scheduling.

What should the first RFP demo contain?

Insert X into released A→B→C. Add material conflict, a delayed customer arrival for B, and A already running. Demand one flow through proposal, rejection reasons, impact, approval, MES dispatch, device acknowledgement, and retry after communications loss.

Conclusion

Post-release resequencing is a decision about protecting existing orders and customer commitments while responding to urgency. Design urgency and authority, frozen conditions, material/capacity/WIP/arrival impact, displaced-order visibility, authoritative ERP–APS–MES boundaries, versioned dispatch, and audit as one workflow. RFP, FAT, and SAT should include rejection, concurrent requests, changed floor state, outages, and cancellation as well as a successful insertion.

If your Thai factory is mapping urgent insertions or preparing RFP test cases, contact TOMAS TECH with a sample line, its orders, materials, devices, and customer commitments. We can help define where approval and synchronization should sit while using your existing systems.

References

• Oracle: Analysis and Adjustment Using the Dispatch List
• Oracle: How You Review a Dispatch List
• Microsoft: Release production orders
• Microsoft: Operations scheduling
• Microsoft: Job scheduling
• Oracle: Schedule Parameters
• Oracle: Solve and Repair Behavior
• Microsoft: Improve scheduling engine performance

*Vendor documentation illustrates possible behavior. Validate permissions, thresholds, performance, and interfaces against your actual plant and contract.*