Rescheduling Policy Matters as Much as the Optimization Method

At 07:00 the schedule is beautiful. A clean production sequence, machines balanced, the whole week reading as one smooth run. At 09:00 a machine stops. By noon, the schedule pinned to the wall and the schedule anyone would build now are two different documents, and no one can say exactly when they diverged, or why.

The algorithm did its job, and the schedule it built was good. What failed is the response: nobody decided what should happen to the schedule when the plant stopped cooperating. When a schedule breaks, who decides what gets rebuilt, and does anyone decide it on purpose?

The default that arrives with the tool: re-run and take whatever comes back

In a plant with no scheduling algorithm at all, the week is built in a spreadsheet, and a disruption means the planning team rebuilding it by hand, with no quick way to see what the outage did downstream. That is a real problem, and it may be the one you have.

The trap does not disappear when a scheduling tool arrives; it changes shape. The new default becomes: run the algorithm again, and accept whatever it returns. The algorithm is fine. What goes wrong is churn. A small input change produces a large schedule change, the schedule keeps moving, and the floor stops treating it as a commitment.

That matters because a schedule's function is to be something people can work against. A schedule that moves every time something moves stops performing that function; crews stop trusting the times on it, and it becomes just another document. The bottleneck is not optimization quality. It is regeneration left ungoverned: rebuilding the schedule instead of adjusting it, with nobody deciding between the two.

The contrarian claim: the regeneration policy is the bottleneck

This post argues that the optimization method is not what separates trustworthy schedules from useless ones. The regeneration policy is. A great optimization run is worthless if the schedule is discarded at the first disruption. What keeps a schedule trustworthy is the policy that decides when to regenerate, what to rebuild, and what to freeze.

Rescheduling has been studied for decades as a distinct problem, with its own decisions layered on top of the optimizer; a 2003 Journal of Scheduling framework paper already mapped the field.

Policy has three levers

When to regenerate: the trigger. The literature distinguishes event-driven, periodic, and hybrid trigger policies. Policy is the usual name for this tier, though the sources are not consistent about it. For a planner the point is simpler: when the schedule breaks, the first question is whether this change earns a re-run at all.

What to rebuild: the reach. The spectrum runs from "rebuild everything" to "only delay what is affected." Complete rescheduling treats the schedule as disposable and builds a new one; partial rescheduling holds some parts and revises the rest. Both are studied options, and both have a place.

What to freeze: the anchor. What stays fixed determines what the optimizer can still improve. A full rebuild can rearrange the production sequence to find a lower-changeover arrangement; holding the sequence fixed leaves machine assignments and timing as the only degrees of freedom. Freeze is the lever between "everything may move" and "nothing moves."

These three levers sit on top of any optimizer, in any tool. The algorithm answers "given the rebuild, what is the best schedule?" The policy answers the more important question first: "given the disruption, what should the rebuild even be?"

The honest trade-off

The argument here is for policy, not for freezing. The other side of it:

• Freezing costs a little optimality. Holding parts of the schedule fixed leaves the optimizer fewer degrees of freedom to work with.
• More regeneration is not automatically better. Which policy wins depends on the disruption pattern a plant actually faces, so the choice is worth making deliberately rather than by default.
• Some disruptions should not trigger regeneration at all. A planner who has entered conservative transfer times or a realistic calendar has already given the schedule room to absorb a small disturbance without a re-run.
• Churn is sometimes a deliberate business choice, not an accident.

A plant can over-react to the same disruption and get churn, or under-react and keep a stale schedule. That tension is why the decision deserves to be made in advance.

Three modes, three regeneration stances

In Schantt, the three scheduling modes are the three regeneration stances, the product expression of the policy rather than a taxonomy of disruptions:

Auto mode: rebuild the whole schedule. The algorithm re-decides the production sequence, machine assignments, and timing, and builds the schedule from scratch. This is the stance for broad, known-in-advance changes where sequencing freedom is acceptable.

Semi-Auto mode: keep the production sequence. The production sequence stays fixed, exactly as the planner entered it; the algorithm re-optimizes machine assignments and timing within it. Semi-Auto does not simply delay the affected operations and push the rest later: it re-optimizes around the frozen sequence. This is the freeze lever made concrete.

Manual mode: hand-author the schedule. When authoring from scratch, the planner writes the schedule row by row. Schantt validates routing, machine compatibility, position rules, and calendar constraints, and runs no optimization. The schedule stands as authored. This is the extreme freeze case.

How does a disruption enter the schedule at all? As modeled capacity, entered by the planner. A downtime window, for one machine or factory-wide, is subtracted from working capacity before scheduling, so the re-run routes work around it. A calendar exception, a holiday or an overtime date, overrides the calendars for that date. The workflow is always planner-triggered: the planner enters the change, the planner re-runs, the planner picks the mode. The tool never silently reschedules. In Auto and Semi-Auto, every re-run optimizes to a single objective: minimize total production time.

Write the policy before the next disruption

None of this requires a policy manual. It requires deciding, in advance, what to do in a handful of cases:

• For a broad change known in advance, a planned shutdown or a holiday week, rebuild the whole schedule. Choose Auto mode.
• For a localized disruption where the sequence the floor is set up to run should stand, keep the sequence and re-optimize around it. Choose Semi-Auto mode.
• Where the schedule must mirror a decision already committed end to end, author it yourself. Where a targeted hand correction is all the disruption calls for, choose Manual mode too: any schedule reopens in it regardless of the mode that created it, and the update applies only the rows the planner changes or deletes, leaving everything else as it stands.

The schedule is regenerated repeatedly through a disrupted week; the point is that each regeneration is a choice, not a reflex. So write the policy down: when you will regenerate, what you will rebuild, what you will freeze. Then let the tool carry out those choices.

The next disruption is not in question

Only the response is. The optimizer will do its part; the policy decides how much of the schedule a re-run may touch. Software with distinct regeneration stances does more than produce schedules: it lets the plant govern how its schedule evolves. That is how a schedule survives contact with the plant and stays worth trusting.