Repair or Re-Optimize? Choosing How Hard to React When a Schedule Breaks

Every planner knows the moment: a machine goes down, a crew is late, a delivery slips, and the schedule that was fine an hour ago no longer is. There are broadly two ways to respond. You can repair the schedule — shift the affected operations later and leave everything else alone. Or you can re-optimize it — hand the whole problem back to the solver with the new constraint and accept whatever it produces.

Neither is always right. Repairs are fast and predictable but can leave a lot of value on the table. Full re-optimization finds a better plan but takes longer, can reshuffle work that people have already started preparing for, and occasionally produces a schedule that looks very different from the one the floor is following.

§ 01What a Repair Is Good At

A right-shift repair pushes the affected operations, and everything that depends on them, later in time. It changes as little as possible. On a large schedule it is close to instantaneous, and it keeps the plan recognizable to the people executing it: the sequence on most machines doesn't move.

Its weakness is that it never looks for a better arrangement. If a long outage hits a bottleneck machine, simply waiting it out can cascade delays through dozens of downstream operations when a different sequence would have absorbed the hit.

§ 02What Re-Optimization Is Good At

Re-solving with the new constraint lets the solver reconsider sequence and assignment everywhere. For a long disruption, or one on a critical resource, the difference in tardiness or cost can be substantial.

The costs are time and stability. On large instances, a full re-solve takes seconds to minutes rather than milliseconds, and every re-solve risks schedule nervousness: operations moving around for marginal gains, which erodes trust on the floor.

§ 03Three Questions That Decide It

In practice, three things matter. First, how long is the disruption compared with the slack already in the schedule? A delay that fits inside existing slack is a repair; one that is several times larger usually isn't. Second, does it hit a bottleneck? Disruptions on non-critical resources can usually be absorbed locally; disruptions on bottlenecks rarely can. Third, how sure are you about the disruption itself? If the report is vague — “should be fixed soon” — acting automatically in either direction is premature, and a person should confirm the reading first.

This is the decision rule GenOR-Twin uses. It compares the disruption's duration with the schedule's average slack, checks bottleneck status, and requires a confidence of 0.85 in its reading of the report before acting on its own. Below that, it asks a person to check one interpretation instead of rebuilding anything.

§ 04Make the Choice Explicit

The worst outcome is not picking the wrong response; it is picking one by habit. Teams that always repair leave value on the table during major disruptions. Teams that always re-solve churn their plans during minor ones. Writing the rule down — even as a simple threshold on slack and bottleneck status — turns an instinct into something that can be reviewed, tuned and, eventually, automated.