Production scheduling when reality does not match the plan

Automated production scheduling is a decision about rescheduling, not about optimisation

The sequence is the easy half. Automated production scheduling is sold as an optimiser - a better order of jobs than the planner would have written - but the plan is obsolete almost as soon as it is published, and the software’s real job is the one the scheduling literature names directly: rescheduling, the process of updating an existing production schedule in response to disruptions or other changes. So the decision in front of a plant is not whether to automate the sequence. It is which of four arrangements it can live with: no schedule at all, with dispatching rules and pull signals deciding at the machine; a periodic plan regenerated by the ERP or a spreadsheet and repaired by hand between runs; a finite-capacity scheduler running an explicit rescheduling policy; or a scheduler built for the plant. Foxnut Studios sells the fourth arrangement - systems built to order and handed over - and so has an interest in this comparison, which is exactly why it is worth stating up front that the fourth arrangement is the right answer least often. What that kind of build has to leave behind, whichever process it runs, is set out in what a scheduling system’s owner is left holding.

The four arrangements, and what actually separates them

What separates them is not sophistication but where the decision is made and what happens when the plan breaks. Read down the last two rows before the first two: the failure mode and the ownership question decide this more often than the quality of the sequence does.

The last row is not a footnote. An arrangement nobody owns degrades quietly: the constraint model drifts out of date, the planner stops trusting the output, and the plant reverts to the first row while still paying for the third.

What the decision turns on

Six structural dimensions decide this, and on production scheduling they read unusually: the exception rate is extreme, the regulatory exposure is close to nil, and the payback condition is a property of one resource rather than of the whole plant.

Two of those rows do most of the work. The volume row says the buying question is local, not global: a plant with one saturated machine and long changeovers has a scheduling problem, and a plant with slack across every resource mostly does not, however many orders it takes. The regulatory row says something quieter but just as useful, which is that almost nothing here has to be defended to an outside party - so the reasons to be cautious about automating a schedule are operational, and the usual argument about explainability and attestation simply does not apply.

The reversibility row is where the design decision lives. A schedule can be rebuilt at any moment, so a naive system rebuilds it constantly - and a plan that changes every hour is one nobody can stage material against or plan a shift around. The three repair degrees exist precisely to trade plan quality against stability, and a scheduler that does not expose that trade as a setting has made it for the plant without telling anyone.

When to choose each

Each arrangement wins a genuine category of plant and fails in a characteristic way. The failure modes are not symmetrical, which is why the order of these four matters more than the sophistication of any one of them.

When dispatching rules and pull win

They win when no resource is saturated, changeovers are short or sequence-independent, and jobs finish comfortably inside the planning period. Under those conditions the order in which jobs run is close to irrelevant to the outcome, and the plant is better served by a rule at the machine - shortest processing time, earliest due date, a kanban signal - than by a plan that will be wrong before the shift ends. It is also the arrangement with the lowest total cost of ownership by a wide margin, because there is nothing to maintain. The failure mode is invisibility: because no plan exists, the shortfall shows up as buffers, expedited orders and supervisor time rather than as a missed schedule, and a plant can run this way for years without anyone being able to say what it costs.

When a periodic plan wins

It wins when disruption is real but slow, so a plan regenerated weekly or nightly and repaired by hand in between stays close enough to true. This is where most plants actually live, and it is often the honest answer: the ERP’s planning run or a well-maintained sheet, plus a planner who knows the shop, is a working rescheduling policy - a periodic one. The failure mode is that the repair work is uncounted. Every rush order and every late delivery is absorbed by a person editing a sequence, and because that labour is never itemised, the plant cannot tell whether it is paying more in planner hours than a scheduler would cost. The question worth asking is not how good the plan is, but how many hours a week are spent putting it back together.

When a finite-capacity scheduler wins

It wins on a bottleneck with sequence-dependent setups, in a plant stable enough that a constraint model stays true between updates - which is the case its own vendor scopes it to. If the ERP already includes such a module, this is configuration work rather than a purchase, and it should be settled before any build is considered. The failure mode is model drift. A scheduler is only as good as its model of routings, capacities, setup matrices and calendars, and that model is a maintained asset with an owner and a review cycle. When it stops matching the plant, output stops being feasible, planners start overriding it, and the licence continues to renew for a system nobody follows.

When a scheduler built for the plant wins

It wins in the narrow case where the constraint structure is genuinely not what the standard products model - re-entrant flow, a coupled set of resources, a sequencing rule specific to the process - and where the plant already has trustworthy shop-floor feedback to reschedule against. That combination is uncommon, and the honest reading of the evidence is that most plants that believe they are in it are actually in the previous case with an unconfigured module. The failure mode is the sim-to-real gap: a model that performs well against a simulation of the plant, and worse than the planner against the plant, because the omitted constraints - transport between cells, buffer limits, breakdowns, stochastic run times - are the ones that decide real feasibility. A build that does not begin from the plant’s actual disruption record is a build optimising a problem the plant does not have.

What this comparison usually gets wrong

The pitch is aimed at the shop where the plan breaks, and the evidence points at the shop where it mostly holds. Applicability studies of advanced planning and scheduling systems report that they fit smooth shops better than socio-technical ones, because environmental uncertainty defeats the system’s ability to produce a feasible schedule at all: the constant change is not the thing the software solves, it is the thing that stops the software working. That is close to the opposite of how the category is sold, and it inverts the usual buying instinct. A plant whose schedule never survives contact with the day is describing a reason the scheduler may not fit, not a reason it is overdue.

Two related distortions follow. The first is that the field’s research has historically been graded on the wrong thing: a review of flow-shop scheduling studies found under three per cent had any grounding in real-world settings, and the simplification of scheduling into a static, deterministic optimisation problem is named in the literature as a direct cause of the gap between what the methods can do and what plants can use. Vendor benchmark numbers inherit that simplification. The second is that firms with genuinely uncertain scheduling tasks have been found to care about generating a quick, feasible schedule, while firms with low uncertainty are the ones focused on optimisation - so the disrupted plant and the stable plant are not buying the same product, even when the demo is identical.

There is one more thing the comparison collapses, and it belongs to a prior decision rather than this one. Whether a scheduling problem needs an autonomous system at all, or a deterministic workflow, or a rule, is a separate question with its own answer, and it is worth settling before choosing between the four arrangements here rather than after.

The verdict

The evidence supports automating production scheduling in a narrower band than the category claims, and for a different reason than the one usually given. The band is: a saturated resource, sequence-dependent setups, cycle times long enough that sequence decides throughput, and a shop stable enough that a constraint model stays true between updates. Inside that band the incumbent finite-capacity scheduler is the first thing to try, because it is already licensed in most plants that need it and its vendor scopes it to exactly this case. Outside that band, the correct answer is usually a rule at the machine or a periodic plan with a planner, and the money is better spent removing a source of disruption than optimising around it.

The reason is the one the profile table makes structural. Exception variance on this process is not high in the way it is high on an invoice queue, where the exceptions are a minority to be routed; here disruption is the schedule’s normal condition, and a system that does not have an explicit answer for when and how to revise - periodic, event-driven, or a hybrid of the two, repairing by right-shift, partial rescheduling or full regeneration - has not addressed the process at all. That answer is a policy decision about how much instability the plant can absorb, and it is not a setting an optimiser can derive.

What follows for a buyer is a different first question. Not “which scheduling product is best”, and not “can AI schedule the plant”, but: how often is the plan currently revised, what triggers a revision, how many hours a week go into repairing it, and does the shop floor report status accurately enough that a system could tell. A plant that can answer those four is in a position to choose between the arrangements above on evidence. A plant that cannot is being asked to buy an optimiser for a problem it has not yet measured, and the studio’s position is that measuring it first is cheaper than any of the four. Tell us how often your plan gets revised and we will say honestly which of the four arrangements, if any, is worth buying.

The part most pages leave out

When not to choose Foxnut Studios

Situations where another option is the better call, and where we say so in the first conversation rather than the fourth.

• The plant already owns a finite-capacity scheduler inside its ERP or MES and has never switched it on, or runs it with the constraint model left at the defaults. That software, and the studio says so. The incumbent scheduler is configuration work, not a build, and paying for a custom system to do what an unconfigured licence already does is the wrong purchase.
• The constraint is not a bottleneck resource with sequence-dependent setups, and jobs finish well inside the planning period, so the order they run in barely moves the outcome. The planner who already writes the week's sequence, unchanged. Where sequencing genuinely does not decide anything, a pull signal or a dispatching rule at the machine is the cheaper correct answer, and the published condition for a scheduler paying back is high resource utilisation, not plant size.
• The shop is disrupted so continuously that no schedule survives the shift it was written for, and the plan is overridden on the floor before the day is out. A redesigned process, not an automated one. The evidence runs the opposite way to the sales pitch: scheduling systems fit stable shops better than turbulent ones, because constant change defeats the model rather than being solved by it. Removing a source of disruption beats optimising around it.
• Job status, machine state and actual run times are offline - on a clipboard, in a whiteboard column, or in a supervisor's head - and are entered into a system hours later, if at all. The organisation itself, doing the documentation work first. A scheduler that cannot see what actually happened cannot reschedule; it can only reprint. Data scattered across several systems is workable, and the studio works with that routinely. Data that exists only on paper is not, and no consultant can fix that from outside.

Sources

1. Vieira, Herrmann and Lin, 'Rescheduling manufacturing systems: a framework of strategies, policies, and methods', Journal of Scheduling 6(1), 2003 - author manuscript hosted by the University of Maryland Institute for Systems Research Retrieved 6 August 2026
2. Romero-Silva, Santos and Hurtado-Hernandez, 'A conceptual framework of the applicability of production scheduling from a contingency theory approach: addressing the theory-practice gap', Production Planning and Control, open access, published online 19 May 2022 Retrieved 6 August 2026
3. Hoss, Schelling and Klarmann, 'A Production Scheduling Framework for Reinforcement Learning Under Real-World Constraints', arXiv:2506.13566, submitted 16 June 2025 Retrieved 6 August 2026
4. SAP Help Portal, 'Production Planning and Detailed Scheduling (PP/DS)', SAP SCM 7.0 EHP2 product documentation Retrieved 6 August 2026

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is what an AI engagement covers and what you keep.