A Hand Edit Without a Rule Is Improvisation

The planner moves the job by hand at two in the afternoon. They have done it the same way for years, shifting one product ahead of another because the customer called, because the truck is late, because the floor says the filler will need attention before the weekend. It takes ninety seconds in the schedule. No one else in the plant learns that it happened, or why, or whether it helped.

That ninety-second edit is the subject of this post. Not because manual overrides are wrong. They are often exactly right, and any argument that says otherwise misunderstands the job. The problem is the silence around them. An override made without a rule is a one-off act. The next planner inherits a schedule they cannot fully explain, and the plant can never find out whether the override was a good decision, because nobody wrote down the reasoning.

The override is not the enemy

Planners carry information the schedule does not. A supplier's truck that has not arrived. A call-off from a customer who will not take the goods this week. A machine the floor says is about to misbehave even though the calendar shows it available. In an observational study of schedulers at work, requests from outside triggered most of what the schedulers did, and they spent more time relaying information to the rest of the organization than making scheduling decisions. The planner is a coordination hub. When they reach into the schedule and move a job, they are usually encoding something the model never saw.

That is why a scheduling tool that treats the planner as an obstacle is built wrong. The human judgment is real, it is plant-specific, and it is not going away. The research on why operations-research and AI scheduling techniques see limited uptake in practice points at this gap: the techniques model a clean problem, and the human scheduler handles the messy one. The override is often the correct answer.

The two failure modes of ungoverned overrides

What is dangerous is not the override. It is the absence of a rule around it. That absence produces two failure modes: one touches the schedule too eagerly, the other too quietly.

The first is the plant that overrides reflexively. The planner doubts the tool, nudges jobs around out of habit, and treats the algorithm's schedule as a rough draft that always needs fixing. The human-automation research has a name for this pattern of under-trusting a system. In controlled studies, people avoid an algorithm after seeing it err, even when the algorithm is more accurate than they are. The trigger is the visible mistake, not the overall record.

There is a mirror failure, and a policy worth having constrains it too: the planner who accepts the tool's answer without question because the system said so. Over-trust and under-trust both erase the planner's judgment; only a rule keeps either direction in check.

The second failure mode is the override that nobody records. The edit is made, the day is saved, and the reason evaporates. This one looks harmless, and it is the more corrosive of the two. Nobody can reconstruct why the schedule looks the way it does. The person who made the edit cannot be asked, because they have moved shifts or moved plants. The changeover consequences of moving a job are invisible to the next planner, because the schedule only shows the final result. And the plant cannot learn, because there is no record of what was tried and what it cost in time.

The scheduling literature has already solved the question this raises, at least for software-triggered change. Rescheduling research distinguishes strategies from policies: a policy is the rule that decides when the schedule gets touched. The canonical options are periodic, meaning the schedule is rebuilt on a fixed cadence; event-driven, meaning a defined disturbance triggers the rebuild; and hybrid, a combination of the two. The point is that "when do we touch the schedule" is treated as a decision made in advance, not as something improvised in the moment. This post simply extends the same discipline to the edits a human makes by hand.

What "policy-backed" means in practice

A policy-backed override is one that answers three questions on a single page.

When is a manual override allowed? The plant names its triggers. An unarrived material delivery. A customer call-off. A machine that has dropped out. The triggers can borrow the rescheduling shapes: an event-driven rule ("the sequence may be changed by hand only when a delivery is late") or a hybrid one ("we re-optimize every Friday and hand-edit only inside the week"). What matters is that the plant decides in advance which disturbances are worth touching the schedule for.

Who may make it? The plant names the roles. The answer can be a short list: the planner, the shift lead in their absence, the plant manager for changes that cross a shift boundary. The point of writing the list is not to build a permission bureaucracy. A planner's day is already full of requests from outside; a policy that routes every change through sign-off would grind the coordination role to a halt. The list exists so that an edit is attributable to a role with the standing to make it.

What gets recorded? This is where the tool earns its keep. When the planner edits the schedule, the tool should make the edit visible and bounded: only the rows the planner changed are touched, the same validation runs over the edit as ran over the original build, and the schedule is marked so that anyone opening it knows a person adjusted it rather than an algorithm produced it. The tool records what changed. The policy records why, in the plant's own language, next to the reason the planner already knows.

There is a version of this that happens before the override rather than after it. A scheduling tool with a Semi-Auto mode lets the plant fix the production sequence and lets the software optimize machine assignments within that fixed sequence. That is a policy in advance: the plant decides the rule, the software executes within it. The manual edit is the in-the-moment exception, and it is exactly the case where the written policy matters most.

The changeover ripple

Here is the operational reason the record matters. The time a machine takes to switch between products depends on which product ran before which. Changeover time is sequence-dependent: moving one job ahead of another changes the changeover time at the boundary on both sides, and those changes ripple through the rest of the schedule. The survey literature on scheduling problems with setup times is large precisely because this effect is real.

A planner who moves a job knows the immediate reason, but the changeover ripple may extend far past the row they edited. A policy-backed override accounts for this because it is made knowingly, with the sequence visible, and because the reason is recorded so the effect can be questioned later. An unrecorded override cannot be questioned. The person who made it may have had a good reason; the plant will never be able to weigh that reason against the time the edit actually cost.

From heroics to a habit

The mature plant does not ban manual overrides. It governs them. A documented rule says when an edit is allowed and who may make it. The tool makes the edit visible and bounded, recording what changed and marking the schedule as hand-adjusted. The plant writes down the why. Three things, none of them bureaucracy, and together they turn the planner's heroics into a repeatable, auditable habit.

The override was never the problem. The missing policy was. A scheduling tool's job is to make the policy-backed edit easy and the ungoverned one visible. The plant's job is to write down the rule. Both sides are simple. The discipline is the hard part, and it starts with the next ninety-second edit.