The Solver Was Right and the Plant Overrode It

A rule a planner will run beats an optimal solution they will override in the dark.

That sentence has cost me more arguments than anything else I believe, so it is worth being precise about what it does and does not claim. It is not a claim that heuristics are as good as optimization. They usually are not. It is a claim that the objective function you are actually optimizing includes a term for whether the answer gets used, and that most projects set that term to zero and then act surprised.

The failure mode is not the one that gets discussed

Ask an operations research team why a project did not land and you will hear about the model. The formulation was too slow. The data was not clean enough. The scope crept. Someone will say the business did not understand the value.

Those are real problems and they are not the common one. The common one is that the model worked, produced a defensible answer, and the person running the schedule on Tuesday quietly did something else. Nobody escalates this. The planner is not sabotaging anything; they are doing their job with a tool that did not earn its place, and the tool is a suggestion they are free to decline.

This failure is hard to see precisely because it is silent. An infeasible model announces itself. A twelve-hour solve announces itself. A model that is overridden produces a dashboard showing it is live, an adoption number somebody computed generously, and a plant that runs the way it ran before.

Three reasons a correct model gets overridden

The model answers a question nobody was choosing between. The brief was “build us an optimizer,” which names a deliverable rather than a decision. Somewhere behind it is a real choice with an owner and a date, and the model is only useful if it changes which alternative that person picks. When the brief is absorbed without that question being asked, the model optimizes something adjacent to the decision and its output is, correctly, not decisive.

A bargaining position was encoded as physics. Someone in a meeting said a plant would never accept a certain sequence, and that preference went into the formulation as a hard constraint. Once a dislike is in the solver as a hard constraint, the ranking of alternatives is no longer a ranking. It is a search for a point that satisfies two slogans, and often no such point exists. The model then either returns infeasible, which at least is honest, or returns a corner solution nobody wants and everybody blames on the mathematics.

Nobody can approximate the answer by hand. This is the one that does the most damage, and it is the least discussed. If you cannot get within range of your own model’s recommendation on the back of an envelope, you do not yet know what is driving it, and you are going to have to stand in a room and explain what is driving it. An analyst who can say that most of the benefit comes from about four hundred slow-moving expensive parts, and that the optimizer is mainly finding a better split within that group, has an argument. An analyst who can only say that the model recommends it has a black box and a hope. The envelope is how you find the sentence, and the sentence is what the recommendation is actually made of.

The test that settles it

Take the sequence your model recommends. Take the sequence the planner actually ran, after whatever adjustments they made without telling anyone. Compare them to what the existing heuristic, the three rules the planner has always used, would have produced.

If the overridden result matches the heuristic, the model did not pay rent. It cost a quarter and produced the answer the plant already had. That is not a communication problem and no amount of change management fixes it.

If the model encodes coupled constraints that the heuristic silently violates, and those violations are expensive, then it might be paying rent. Notice where that claim lives. The rent is in the constraints, not in the solver. Write it down as a specific claim, then go and check whether the violations are real and what they cost. That is usually a query and a week in the plant. It is almost never a better formulation.

The staged version, which is slower and works

Start with a rule that is legible to the person who will run it. Three classes, a threshold, something they can explain to their own manager without opening a laptop. It will be worse than optimal and it will be run.

Then measure what the legible rule leaves on the table. Not what the model could theoretically capture: what the remaining error actually costs, in units of consequence. If that number is large enough to pay for the complexity, add the complexity, and add it against a specific claim about which constraint the simple rule is violating.

I have watched this work in allocation, in scheduling, and in ordering. I have also watched teams skip to the cathedral and spend a year explaining why nobody moved in.

This is not an argument against mathematics

It would be a cheap conclusion, and it is not the one I hold. I have spent a career building these models and written two books on formulating them. The point is narrower and less comfortable.

Optimization in an operating environment is mathematics with an adoption constraint. The constraint is real, it binds, and leaving it out of the problem does not make it go away. It just means you solved a relaxation and shipped the answer to a different problem than the one the organization has.

If the elegant model survives only by being ignored, then the heuristic is the real rule and the model is a brochure.