An Optimal Solution Is Not the Only Optimal Decision

The Solver Can Be Right and the Decision Can Still Be Weak

A supply chain team builds a mixed-integer optimization model for production allocation.

The objective is contribution margin. The constraints represent plant capacity, demand limits, material availability, minimum runs, and customer commitments. The model solves to proven optimality.

Then the model runs again after a small data refresh. Total profit is effectively unchanged, but the production plan moves thousands of units between plants. One facility gains three changeovers. Another loses a product family it has been making for years. A planner asks why.

The answer is simple: the model may not care.

There can be many different solutions with exactly the same objective value. There can also be solutions separated by a few dollars inside a business problem worth millions. Mathematically, the plans are different. Economically, they are nearly indistinguishable.

Operationally, they may be very different.

This is one of the most important gaps between optimization theory and real decision systems. A solver is designed to find a solution that satisfies the model. It is not automatically designed to find the solution your organization will trust, understand, or execute.

Optimality Often Describes a Plateau

People often imagine optimization like climbing a mountain. There is one highest point. The solver finds it. Done.

Real models often look more like a plateau.

Suppose two plants can make the same product at the same modeled cost. If either plant has enough capacity, many allocations may produce the same objective value. The solver returns one of them.

That does not mean every optimal solution uses the same variable values.

The practical question is often not:

What is the optimal solution?

It is:

Which decisions are common across the optimal or near-optimal set?

Consider an inventory allocation model that returns:

Warehouse A: 4,000 units
Warehouse B: 6,000 units

Perhaps this is equally good:

Warehouse A: 5,000 units
Warehouse B: 5,000 units

And perhaps this is only $40 worse on a $20 million objective:

Warehouse A: 6,000 units
Warehouse B: 4,000 units

If the organization strongly prefers the third plan, reporting only the first plan hides the real decision space.

Tiny Economic Differences Can Create Huge Operational Changes

Optimization models compare solutions using the objective function you gave them.

They do not know which changes will trigger a planning escalation, confuse a supplier, create extra work for a buyer, or make users think the system is unstable unless those consequences are represented.

Yesterday’s recommendation might be:

Buy 10,000 units from Supplier X
Buy 2,000 units from Supplier Y

Today’s recommendation might be:

Buy 2,000 units from Supplier X
Buy 10,000 units from Supplier Y

The forecast barely changed. The economics barely changed. Yet the recommendation flipped.

The model may be behaving correctly. The objective surface is flat near the optimum, while the decision system presents one point on that surface as if it were inevitable.

Users experience this as model volatility. Technical teams often respond by explaining that the new answer is optimal. That explanation rarely helps.

The user is asking a different question:

Why should I change what I was already going to do?

If the economic gain from changing is negligible, the system needs a good answer.

Near-Optimal Solutions Can Matter More Than the Exact Optimum

In practice, I care about the geometry around the best solution.

If one decision is dramatically better than every alternative, the recommendation is strong.

If fifty different plans are within 0.01% of the best objective, the recommendation is weak even if the proof of optimality is strong.

Those statements are not contradictory.

The solver can be highly confident about the best objective value while the organization should be less confident about the exact decision vector.

This matters in supply chain because many decisions contain interchangeable capacity, substitution, timing flexibility, or aggregation. Small coefficient changes can move the optimizer to a different plan without materially changing economics.

A useful question is:

What can I change while staying within an acceptable economic loss?

For example:

profit >= 99.9% of best-known profit

Then explore the decisions inside that region.

Ask which production assignments never change, which suppliers are interchangeable, which order quantities vary widely, and which decisions are sensitive to tiny changes in demand.

This turns optimization from answer generation into decision analysis.

Add Tie-Breaking Deliberately

If multiple solutions are economically equivalent, choose among them intentionally.

A common approach is hierarchical optimization.

First optimize the primary economic objective:

maximize profit

Then preserve that result within a tolerance and optimize a secondary objective:

minimize change from the previous plan

Then perhaps a third:

minimize operational complexity

The sequence might be:

1. Protect economics
2. Preserve stability
3. Reduce complexity
4. Prefer operationally desirable patterns

The order matters.

You do not want a vague preference for stability to destroy meaningful profit. But you also should not accept massive operational churn to gain a trivial amount in a multimillion-dollar plan.

One practical structure is:

Primary solve:
    maximize economic_value(x)

Secondary solve:
    minimize change_cost(x, previous_plan)

subject to:
    economic_value(x) >= best_value - tolerance

The tolerance is a business parameter, not merely a mathematical one.

How much economic value are you willing to exchange for stability? The answer may differ by decision. Changing a display is cheap. Changing a confirmed supplier commitment may create real cost. Moving planned production between plants may create work that the accounting objective does not capture.

Stability Is Not the Same as Freezing the Past

There is a danger here.

Teams sometimes discover model volatility and add so much inertia that the optimization system stops optimizing.

That is not stability. It is a hidden rule to preserve the status quo.

A good stability mechanism asks whether the benefit of changing exceeds the cost of changing.

For a decision variable x, you might represent movement explicitly:

change = |x_new - x_previous|

Then penalize economically meaningful movement.

But the penalty should correspond to reality.

If moving planned volume between warehouses requires no physical movement because the units have not been produced yet, a large stability penalty may be fake economics. If changing a purchase order after supplier confirmation creates fees and labor, the change cost is real.

The goal is not to make the model calm.

The goal is to represent the economics of changing your mind.

Alternative Solutions Are a Diagnostic Tool

When a model has many good solutions, alternatives can reveal structure that one incumbent solution hides.

You do not always need every optimum. For large MILPs, that may be impossible or useless. But a collection of strong alternatives can answer practical questions.

Suppose a network model recommends closing one distribution lane.

If every near-optimal solution closes the lane, that is strong evidence.

If half the near-optimal solutions keep it open with almost no economic penalty, the executive conversation should be different.

The first message is that the lane is structurally unattractive under the modeled economics.

The second is that the model is nearly indifferent and other operational considerations can reasonably decide.

Those are very different management conclusions from the same optimization model.

Replay the Decision, Not Just the Objective

Historical replay is especially useful for detecting unstable optimization systems.

Do not only track objective value, service, inventory, and cost. Also track decision movement:

How many recommendations changed?
How much volume moved?
How many suppliers flipped?
How many production assignments changed?
How many changes were later reversed?

A system that improves modeled profit by 0.02% while rewriting 40% of the plan every week may not be ready for operational use.

Replay also helps distinguish two causes of volatility.

The first is genuine state change. Demand moved. Capacity disappeared. A supplier failed. The decision should change.

The second is model indifference. Tiny data changes cause the optimizer to select a different point from a broad set of equivalent plans.

The first requires responsiveness.

The second requires better decision design.

Separate Solver Behavior From Business Behavior

When a recommendation changes unexpectedly, debug in layers.

Start with the business state:

What data actually changed?

Then inspect the mathematical model:

Did coefficients, bounds, or constraints change?

Then inspect the solution economics:

How much better is the new plan?

Then inspect alternatives:

Was the old plan still feasible?
Was it still near-optimal?

Only then should you jump into solver parameters or algorithmic behavior.

Too many teams reverse this order. They see a different answer and start tuning the solver.

Often the solver is exposing something true about the model: the model does not distinguish between plans that the business considers very different.

That is a modeling problem before it is a solver problem.

Executives Need the Strength of the Recommendation

Many dashboards present optimization recommendations with false precision.

They show:

Produce 18,420 units.

But they do not show whether 18,000 and 19,000 units are economically indistinguishable.

A better decision system communicates both the recommendation and its strength:

Recommended: 18,420 units
Economically similar range: 17,900-19,100 units
Value lost at current plan: 0.03%
Main driver: constrained component capacity

Now the executive knows where precision matters.

This is not about overwhelming users with optimization theory. It is about preventing the software from pretending to know more than the model actually knows.

Decision Ownership Begins Where the Objective Becomes Indifferent

Optimization teams sometimes want the model to decide everything.

That is usually a mistake.

If the economics strongly favor one action, the model should say so.

If several actions are economically equivalent, the system should either use explicit secondary preferences or expose the choice to the person who owns the operational consequences.

Who decides between two nearly equivalent suppliers?

Who decides whether stability is worth 0.1% of modeled profit?

Who owns the cost of changing a production plan?

Who can override a recommendation when the model is genuinely indifferent?

These are not governance questions added after the math. They are part of the decision architecture.

The Production Standard Is Higher Than Proven Optimality

Proving optimality is a remarkable technical achievement.

It is also not the end of the job.

A real optimization system should help the organization understand what must change, what could change, what does not matter economically, what is sensitive, and how much value is actually at stake.

The best solution is not always the most useful output.

Sometimes the most useful output is the set of decisions that remain good. Sometimes it is the cost of preserving the current plan. Sometimes it is evidence that a controversial change appears in every strong alternative. Sometimes it is permission for an operator to choose freely because the model is genuinely indifferent.

That is the deeper lesson.

Optimization should not only tell us where the optimum is. It should tell us how much of the decision really matters.