Why Your Production Schedule Is Obsolete by Lunch

The phrase describes a specific, measurable event. A schedule is published at the start of the shift — printed, posted to a dispatch screen, or read out in a morning meeting. Within a few hours, enough of its assumptions have failed that following it literally would produce a worse outcome than ignoring it. Supervisors know this before anyone says it out loud: they stop looking at the sheet and start making sequencing decisions from memory, from the whiteboard, and from whichever customer called most recently.

Decay is worth measuring because it converts a recurring argument into a number. Most shops have a version of the same dispute: the planner believes the floor ignores the plan, and the floor believes the plan was never realistic. Both statements can be true at once, and neither can be settled without data. If half of the day's operations move within four hours, the schedule is not being disobeyed — it is being overtaken.

It is also worth being direct about what decay is not. In high-mix, low-volume manufacturing, a plan that diverges within hours is a signal, not a discipline failure. The inputs to that plan genuinely change several times a shift: run times in high-mix work are estimates, routings are unique to the job, one qualified operator may cover three machines, and customers reprioritise after the work has started. A plan built on inputs that move will move. Treating that as a behavioural problem — more meetings, firmer instructions, a stricter tone in the morning stand-up — attacks a symptom and leaves the mechanism untouched.

The useful question is narrower: when the plan is overtaken, what recalculates it? In most shops the honest answer is a person, from memory, under time pressure, without visibility of the downstream consequences. That is where the cost sits. The lost hours are not in the divergence itself but in the unmanaged response to it — the setups run out of sequence, the expedite accepted without knowing what it displaces, the second shift starting with no agreed order of work.

Across discrete shops the same six mechanisms account for most of the decay. The symptom is what the floor notices; the cause is the mechanism underneath it; the third column is where to look first, before concluding anything about software.

Two things stand out when a shop actually works through this table. First, at least two of the six are normally data problems rather than scheduling problems — inaccurate standards and unrecorded completions in particular. Second, the causes interact. Optimistic standards create queues; queues make every date fragile; fragile dates make expediting feel necessary; expediting destroys setup sequences and pushes actual times further from standard. That loop is why single fixes often disappoint.

Several of the most effective interventions cost nothing but agreement. They are worth doing first, both because they may be sufficient and because they make any later system evaluation far more honest.

• A frozen window. Agree a period at the front of the schedule — commonly the current shift — in which the sequence does not change except through a defined emergency process. Beyond the window, replan freely. This protects setups already in progress and gives supervisors a stable horizon to work against, which is often the difference between a plan being followed and a plan being abandoned at 10 AM.
• WIP limits. Releasing more work than the constraint can absorb does not increase output; it increases queue length, and long queues make every promised date sensitive to small delays. Capping released work at each work centre shortens queues, reduces the number of jobs whose dates can move, and makes what remains far more predictable.
• A capacity buffer. Planning a work centre at one hundred per cent of theoretical capacity guarantees decay, because it leaves no room for the variability that is certain to occur. Many shops plan the constraint at eighty to ninety per cent of available hours and absorb the difference. The correct number is shop-specific and should be derived from measured variability rather than copied.
• Schedule governance for rush orders. Decide who may accept an expedite, what information they must see before accepting it, and where the decision is recorded. The most valuable part is the second clause: an expedite accepted with visible knowledge of which jobs it pushes late is a business decision, while one accepted blind is simply a transfer of lateness to a customer who has not called yet.

None of these require a purchase. All of them are difficult in a different way, because they require operations, sales and management to agree in advance on rules that will occasionally be inconvenient.

Once the governance is in place, three capabilities are hard to reproduce manually at any real scale.

Faster feedback from the floor. A schedule cannot respond to events it does not know about. If completions are recorded on paper and keyed the next morning, the best possible plan is a day behind reality. Shortening that loop — operator terminals, machine monitoring, or simply a disciplined reporting cadence at the constraint — is a prerequisite for everything else. It is also frequently the single change with the largest effect, and it can be made independently of any scheduling engine.

Finite-capacity replanning. Recalculating a sequence across machines, operators, setups, materials and outside processing is a combinatorial problem. A planner can do it for one work centre. Nobody can do it for forty, several times a day, while also answering the phone. This is what a finite-capacity scheduler exists for: not to produce a prettier chart, but to recompute a feasible order of work against the constraints that actually apply once something has changed.

Planned-versus-actual drift. Measuring decay by hand is possible for a week and unsustainable as a habit. Systems that retain the plan as issued and compare it to what ran give a shop its decay rate per work centre — which is the number that tells you where to intervene. Drift measurement is also the honest way to evaluate a scheduling purchase after the fact: if decay at the constraint has not fallen, the system has not yet done its job.

A short decision path, in order. Stop at the first honest "no".

1. Are routings and standard times trustworthy? If actual hours differ from standards by a wide and inconsistent margin, the plan is built on sand. Fix the data. No scheduling system repairs routings nobody believes.
2. Do completions reach the system within an hour or two? If not, the delay is your ceiling on schedule accuracy. Shorten the reporting loop before evaluating engines.
3. Is the load beyond the shop's real capacity? If the constraint is booked at more hours than it can physically run, this is a capacity and order-acceptance problem. Software will describe it accurately and change nothing.
4. Is the sequence unmanaged after the morning? If the plan has no owner from mid-morning onward, start with governance: a frozen window, an expedite rule, and a defined handover between shifts.
5. Does everything above hold, and the plan still decays? Then the problem is genuinely computational — too many interacting constraints changing too often for a person to resequence by hand. That is the case dedicated finite-capacity scheduling is built for.

There is an opposite failure that gets far less attention. A high-mix schedule that never moves is also wrong. If the sequence published on Monday is still the sequence on Friday in a shop running unique routings and variable run times, one of three things is true: the plan is not being followed and nobody is updating it, the buffers are so large that the plan is not really constraining anything, or the shop is far less high-mix than it believes.

Legitimate reasons for a schedule to change include an operation completing materially early or late, an absence or a skill mismatch at a staffed work centre, material arriving or slipping, an outside-processing return moving, a breakdown, and an accepted expedite. Each of these changes what should run next, and a schedule that does not reflect them is stable only because it has stopped being consulted.

The goal is therefore not a stable schedule. It is a current one, with stability where stability matters — inside the frozen window, at setups already underway, and in the promised dates given to customers. Change beyond that horizon is the system working.

Skody is a scheduling and decision layer that reads production data from the ERP a shop already runs and recomputes a finite-capacity sequence when that data changes — machines, operators and skills, setup families, material readiness and outside processing all treated as constraints. It is not an ERP and does not provide inventory, purchasing or costing.

The dependency is worth stating plainly, because it decides whether the approach works: Skody inherits the quality of the data it reads. If routings are incomplete, standards have not been reviewed in years, or completions are recorded a day late, the schedule will be recomputed accurately from information that is wrong. Shops in that position get more from fixing routings and shortening the reporting loop first. Shops with roughly ten machines or fewer, where one person can hold the whole plan in their head, are also usually faster with a whiteboard.

Where it does fit is the fifth case in the decision path above: data is reasonable, feedback is reasonably fast, capacity is not structurally short, and the plan still decays because too many constraints interact too often for manual resequencing to keep up.