Every manufacturing site runs a version of the same ritual. The scheduling run completes overnight: an optimised sequence, changeovers minimised, due dates protected, capacity balanced. By the time the morning meeting convenes, reality has filed its amendments. An inbound truck is late, a machine failed its start-up checks, two operators called in absent, and a priority order landed from sales. The supervisors do what experienced supervisors always do, repair the plan by hand, and the overnight optimum spends the rest of its day as a reference document.
None of this is a failure of effort, and it is not fixed by a better solver. A schedule is a forecast about the near future of a physical system, and physical systems disagree with forecasts hourly. The design question was never how to compute a perfect schedule. It is how to live well with the fact that no schedule survives contact with the shift.
The rescheduling trap
The instinctive software answer is frequency, rescheduling at every disruption, continuously, optimally. This produces the disease planners call nervousness, and it is worse than the ailment. A full reoptimisation is entitled to reshuffle everything, and it will happily rebuild the entire sequence to harvest minutes of theoretical efficiency. The costs of that churn are real and mostly invisible to the solver: materials staged for a sequence that no longer exists, changeovers begun for jobs that just moved, teams who learn, correctly, that the plan is not worth reading.
A plan that changes completely twice a day is not twice as responsive. It is a plan nobody follows, which returns the plant to manual scheduling with extra steps.
Optimality and instability come bundled. A schedule's value on the floor is a product of its quality and its credibility, and churn spends the credibility.
Disruption as triage, not recomputation
The mature architecture treats disruptions the way a good operation treats any event stream: triage first, and reserve recomputation for the events that earn it.
- Absorb silently where buffers exist. Most disruptions threaten nothing: the late truck arrives inside the slack, the short stoppage fits the buffer. The correct response is no response, and the system's job is to establish that quickly and quietly, rather than announcing every tremor.
- Repair minimally where commitments are threatened. When an event does endanger a due date or a constraint, the objective changes from "optimal schedule" to "smallest stable change that protects the commitment": swap two jobs, shift a batch, hold the rest of the sequence intact. Stability becomes an explicit term in the objective, priced against the theoretical minutes a full reshuffle would recover.
- Rebuild rarely, and knowingly. Some events, the line down for days, the material out for a week, genuinely invalidate the plan. Then a full reoptimisation is right, taken as a visible decision with its disruption cost acknowledged, not as the default response to every event.
Two disciplines make the triage honest. The thresholds are probabilistic. "The late inbound threatens the due date" is a statement with odds, computed from actual arrival and processing variability, not a binary flag. And the triage is scored afterwards: which absorbed events should have triggered repairs, which repairs proved unnecessary, so the thresholds learn from the plant instead of from configuration defaults.
Run this way, the morning meeting becomes a review of the handful of genuine decisions, each arriving with options and odds attached, and the schedule retains the property that makes any plan valuable on a shop floor: the people executing it believe it will still be true after lunch.
A diagnostic worth running at your own site: for one week, count how many of the overnight schedule's first ten jobs actually ran in sequence. That number is your plan's real credibility, and raising it is what Prophesee's manufacturing module is for. See what your schedule churn is costing.