The Operational Shadow Model

Most supply chain organizations already have a model.

It may not live in Python. It may not be written as a MILP. It may not have clean version control, a mathematical objective, solver logs, or a data pipeline. But it exists.

It lives in planner judgment, buyer overrides, expedite rules, spreadsheet tabs, Slack messages, supplier phone calls, email approvals, manual exceptions, and the sentence every operations team knows too well: “We usually just handle that case manually.”

That is the operational shadow model.

It is the real decision system operating underneath the official one.

When companies build analytical systems, they often document the formal process and ignore the shadow process. They map the ERP workflow. They pull the historical transactions. They interview a few subject matter experts. They define the decision variables, constraints, and objective function. Then they build the model as if the recorded system is the business.

But the recorded system is often only the residue of the business.

The real decision process includes the things people did because the official system was incomplete.

Why the shadow model matters

A replenishment system might show that a buyer ordered 10,000 units.

That is a transaction.

It does not tell you that the buyer wanted 14,000 units, but finance pushed back on cash. It does not tell you that the supplier quietly warned them about a production delay. It does not tell you that the transportation team had no container space. It does not tell you that the merchant wanted to protect a promotional display. It does not tell you that the buyer intentionally overrode the forecast because a similar item failed last year.

The historical order quantity is not always the historical decision.

Sometimes it is the final compromise after five hidden constraints collided.

This matters because optimization systems learn from, compare against, and eventually replace pieces of this process. If the system does not understand why the human did what they did, it may label the wrong thing as irrational.

A model might say, “The planner ordered too much.”

The planner might say, “No, I was protecting against a vendor that misses half its appointments during peak season.”

Both can be right if the model never encoded vendor reliability as a decision-relevant uncertainty.

The dangerous version of automation

The dangerous version of automation is not a model that makes mistakes.

Every model makes mistakes.

The dangerous version is a model that removes human judgment before it understands what that judgment was compensating for.

This is how good analytics projects lose trust. They improve the clean metric and damage the messy business.

The forecast improves, but the buy gets worse. The solver objective improves, but planners override every recommendation. Inventory falls, but service collapses in a region nobody represented correctly. The allocation looks efficient, but field teams know a customer relationship was just damaged.

The common explanation is that operators resisted change.

Sometimes that is true. More often, the model failed to represent operational reality deeply enough.

In practice, many manual overrides are not emotional reactions. They are undocumented constraints.

Some are bad habits. Some are politics. Some are local incentives. But some are extremely valuable information that never made it into the formal data model.

A serious decision system has to separate those cases.

Treat overrides as data, not embarrassment

Many teams treat planner overrides as a failure mode.

They build a recommendation engine, show the system answer, measure adoption, and then get frustrated when people adjust the recommendation. This creates the wrong culture. It turns the planner into an obstacle instead of a sensor.

A better approach is to instrument the override.

When a buyer changes an order quantity, ask why in a structured but lightweight way. Was the issue supplier reliability, case pack logic, cash pressure, presentation minimums, demand uncertainty, capacity, upcoming promotion, data quality, or local knowledge?

Do not make the user write an essay. Do not build a bureaucratic approval system that punishes honesty. Give them practical reason codes and allow short notes when needed.

Then study the pattern.

If 70 percent of overrides are caused by minimum display quantities, the model is missing a merchandising constraint.

If overrides spike for specific vendors, the model is missing supplier reliability.

If overrides appear near month-end, the model may be colliding with financial incentives.

If overrides are concentrated in a few planners, maybe the training is poor, the policy is unclear, or the local team is solving a different business problem than leadership thinks.

The override log is not just compliance data.

It is the backlog for the next version of the decision system.

The model should explain the tradeoff, not just the answer

Operational teams rarely trust a recommendation just because it is mathematically optimal.

They want to know what tradeoff the model is making.

Why did it buy less? Why did it hold inventory in one node and starve another? Why did it delay a purchase order? Why did it choose a more expensive transportation option? Why did it consolidate orders this week instead of next week?

A good decision system should not only output the chosen action. It should expose the economic logic behind the action.

This does not mean showing everyone dual values, reduced costs, branch-and-bound logs, or a wall of mathematical notation. Those are useful for the modeling team. They are not always useful for the operator.

The operator needs a translation layer:

• This recommendation saves cash but increases stockout risk.
• This allocation protects the highest-margin demand first.
• This buy is delayed because the next supplier price break is not worth the added inventory.
• This item is constrained by cube, not by budget.
• This order is larger than usual because the model is protecting against lead time uncertainty.

The goal is not to make the model sound smart.

The goal is to make the decision inspectable.

When people can inspect the tradeoff, they can challenge the right part of the system. They stop saying “the model is wrong” and start saying “the service risk is understated” or “the supplier calendar is wrong” or “that promotion should be treated as committed demand.”

That is a much better conversation.

Shadow constraints become real constraints

In a mature optimization workflow, the shadow model slowly becomes visible.

The hidden case pack rule becomes a real constraint. The informal supplier calendar becomes structured input data. The planner’s emergency expedite rule becomes a penalty term. The executive preference for strategic accounts becomes an explicit service priority. The manual buying cadence becomes a modeled policy choice.

This is how optimization systems improve in production.

Not by pretending the first formulation is complete.

Not by declaring that humans are biased and the model is rational.

Not by hiding all complexity behind a dashboard.

The system improves by repeatedly converting operational judgment into explicit decision logic.

That does not mean every human rule should be preserved. Some rules are legacy nonsense. Some are local optimizations that damage the network. Some exist only because the old system could not solve the real problem.

But you cannot remove a rule intelligently until you understand what job it was doing.

A practical implementation pattern

A strong deployment pattern is to run the new decision policy beside the current process before fully automating anything.

For each decision cycle, capture four things:

1. What the current human or legacy process decided.
2. What the new model recommended.
3. Where the recommendations differed.
4. Why the operator accepted, rejected, or modified the model recommendation.

This creates a practical learning loop.

If the model is consistently better, trust builds naturally. If the model is wrong, the team learns why before the mistake is scaled. If the operator is wrong, the evidence becomes visible without turning the discussion into a personality contest.

This is especially valuable in supply chain because the consequences of decisions arrive late.

A bad buy may not reveal itself for months. A bad allocation may look fine until a region stocks out. A bad cadence policy may look efficient until emergency freight appears. A bad forecast may not matter if the downstream decision is robust, while a good forecast may still produce a bad decision if the cost structure is wrong.

The shadow period gives the organization time to compare policies under real operating conditions.

Executives should ask for the shadow model

Executives do not need to inspect every constraint matrix.

But they should ask a few simple questions before funding or scaling an optimization system:

What manual decisions happen after the official process?

Which overrides are common enough that they should become part of the model?

Where do planners distrust the recommendation, and is that distrust justified?

What business tradeoffs does the system expose to users?

What reason codes are captured when people reject a recommendation?

How will the team decide whether an override indicates model weakness, data weakness, training weakness, or legitimate local context?

These questions are not soft change-management questions. They are decision architecture questions.

A company cannot own a decision system if it cannot see how decisions are actually made.

The real standard

The standard for a supply chain optimization system is not whether it solved a mathematical formulation.

That is necessary, but not sufficient.

The standard is whether it can survive contact with the operating floor, the buyer desk, the supplier base, the finance meeting, the executive review, and the next exception that was not in the prototype.

This is why the operational shadow model matters.

It reminds us that the goal is not to replace messy human judgment with clean mathematical output. The goal is to understand the decision well enough that the organization can improve it deliberately.

Some of that improvement will come from better forecasts.

Some will come from stronger formulations.

Some will come from simulation, replay testing, solver diagnostics, and policy evaluation.

But a lot of it will come from something less glamorous: watching how people actually decide, learning why they do it that way, and converting the useful parts into a system that can scale.

Optimization does not become real when the solver finishes.

It becomes real when the organization changes the way it makes decisions.