Plan Stability: Frozen Horizons and Schedule Nervousness

A scheduler that recalculates from scratch every time new information arrives will, in principle, always produce the mathematically best plan available at that instant. In practice, that’s often the worst thing it can do. A plant doesn’t run on a solver’s output — it runs on printed dispatch lists, operators who’ve already staged material for the next three jobs, and a supervisor who told the night shift what’s coming. A “better” plan that reshuffles all of that the moment it’s recalculated isn’t an improvement; it’s a disruption dressed up as one.

This tension — between a schedule that’s optimal in theory and one that’s stable enough to actually execute — is one of the oldest problems in production scheduling, and it has a name.

Schedule nervousness

Nervousness is what happens when small, ordinary changes in the input (a new rush order, a slightly revised due date, an order canceled) cause large, disproportionate changes in the output plan — not just adjusting around the new information, but reshuffling work that had nothing to do with it. A rush order dropped into an otherwise-unchanged order book shouldn’t, in a well-behaved scheduler, cause forty unrelated jobs to swap positions. When it does, the schedule is nervous, and nervousness has a real cost that doesn’t show up on any single-run optimality score: material staged for tomorrow’s now-postponed job, operators briefed on a sequence that no longer holds, a supervisor who stops trusting the schedule because it changed again overnight and starts working from memory or a whiteboard instead.

The uncomfortable truth about nervousness is that it’s often a side effect of a scheduler doing exactly what it was told to do — minimize total tardiness, or minimize changeover, or maximize on-time delivery, treating every regeneration as a fresh optimization problem with no memory of what was published last time. A purely re-optimizing scheduler has no concept of “this plan already went to the floor” unless something explicitly tells it to care.

A worked example

A plant publishes tomorrow’s dispatch list at 6pm today: forty operations across six work centers, each with a committed start time the floor is already staging material against. At 9pm, a single rush order comes in, due in three days.

Hand that new order to a scheduler with no memory of what it already published, and it will find the mathematically best place to slot it in — which might mean nudging one work center’s sequence just enough that six other operations shift by twenty minutes each, which cascades into their downstream operations shifting too, until a third of tomorrow’s forty operations carry a different start time than the list the floor already has in hand. Nothing about those other thirteen operations needed to change to accommodate the rush order; they moved because the solver was re-solving everything from scratch and had no reason to prefer the old positions over new ones of equal cost.

The same rush order, handed to a scheduler respecting a next-shift frozen horizon, finds a very different answer: the horizon says tomorrow’s forty operations are untouchable, so the new order gets slotted into open capacity beyond that window, or — if it genuinely cannot fit without disturbing the frozen zone — gets flagged for a planner to make the trade-off explicitly, rather than the system making it silently on the floor’s behalf. Tomorrow’s dispatch list doesn’t change at all. The rush order still gets a real, honest date; it just isn’t manufactured by quietly reshuffling work that was never the problem.

The frozen horizon

The most direct fix is also the simplest: designate a near-term window — the frozen horizon — inside which the schedule is untouchable, no matter what a fresh optimization would prefer. Typically sized to something like the next shift, the next day, or the next few days depending on how far in advance material gets staged and dispatch lists get printed, the frozen horizon draws a hard line: work already inside it keeps its committed time, full stop, and only work beyond that line is fair game for resequencing.

This isn’t a claim that the frozen-horizon plan is more correct than an unconstrained reoptimization — it usually isn’t, by whatever the objective function measures. It’s an acknowledgment that “correct on paper right now” and “executable given what’s already been committed to the floor” are different properties, and inside the frozen horizon, executable wins.

Sizing the horizon is a judgment call, not a formula, and it trades off in a predictable direction: too short, and the scheduler keeps disturbing work that’s already effectively committed — material staged, operators briefed — defeating the purpose. Too long, and the scheduler loses the ability to react to real problems (a genuine emergency, a broken machine) inside a window it’s been told never to touch, which just relocates the pain from “the schedule changed” to “the schedule couldn’t respond to a real emergency.” The right size tracks how far in advance a shop actually commits to its floor — how far ahead material gets staged, dispatch lists get printed, operators get briefed — not a generic industry default.

Replan cadence

Separate from the frozen horizon’s where is the question of when a shop regenerates the plan at all. Three common cadences, each suited to a different kind of operation:

• Daily, pre-shift — the most common pattern. The plan regenerates once, before the shift starts, incorporating whatever changed overnight, and then holds for the day. Predictable, easy for the floor to trust, and well matched to shops where a day’s worth of change accumulates before it’s worth acting on.
• Continuous — the plan can regenerate any time new information arrives, constrained by the frozen horizon so near-term work stays stable regardless of how often the far end of the plan gets recalculated. Suits shops with fast-moving order books or frequent expedites, where waiting for the next scheduled regeneration would mean sitting on information that should change today’s plan.
• Weekly, or on a longer cycle — appropriate for shops with long lead times and low day-to-day volatility, where daily regeneration would just be reprocessing the same inputs and producing the same plan, adding nervousness risk for no benefit.

None of these is more “advanced” than the others — the right cadence is the one that matches how fast a shop’s real inputs actually change, not the shortest interval a system happens to support.

Adherence weighting: biasing toward the plan people already printed

The frozen horizon is a hard rule — untouchable, no exceptions, inside the window. Outside it, most solvers offer a softer tool for the same underlying goal: an adherence weight that biases the solver toward keeping an operation close to its previously published time, even when it isn’t hard-locked. Raise the weight and the solver treats “matches what was already communicated” as a real cost worth avoiding disturbing, trading some theoretical optimality for continuity; lower it and the solver reoptimizes more freely, trading continuity for a plan closer to whatever the objective function’s other priorities would produce unconstrained.

This is the same trade-off that shows up across Measuring a Schedule as “adherence versus everything else” — a shop that got burned by a floor that stopped trusting a schedule that changed every morning will set this weight high; a shop where the floor tolerates change well, and where a slightly stale plan costs real money, will set it low. Both are legitimate configurations of the same knob, tuned to the same kind of business judgment that governs every other trade-off in scheduling.

The human cost of churn

It’s worth naming directly why this matters beyond the metrics: a dispatch list is a commitment. An operator who spent the last hour staging material for job A, based on this morning’s printed sequence, and comes back from break to find job B is now first, has lost real time and — more corrosively — lost a little more trust in the schedule as a source of truth. Enough of that, repeated often enough, and the floor stops treating the schedule as authoritative and starts working from its own informal priorities, which is precisely the manual-scheduling failure mode that a scheduling system exists to replace. A frozen horizon and a sensibly tuned adherence weight aren’t a compromise imposed on an otherwise-perfect optimizer — they’re what makes the optimizer’s output something a shop floor can actually run on.

Related reading

• Measuring a Schedule: OTIF, Tardiness, and Utilization — where adherence sits among the other trade-offs a schedule has to balance.
• What-If Scheduling and Capable-to-Promise — evaluating a hypothetical change without disturbing the live, published plan at all.
• Modeling Real Capacity: Shifts, Calendars, Efficiency, and Parallel Machines — the capacity model a stable plan is built against.
• In Microsoft Dynamics 365 Business Central: Production Order Statuses in BC: What Each One Means for Scheduling — a Released order is BC’s own version of “committed enough that it shouldn’t move casually.”
• In the product: APS Setup Reference — where the frozen horizon is configured.