Why Supply Chain Optimization Projects Fail

Imagine your network design project has just identified $4.2 million in annual cost savings. The model ran without errors. Leadership is ready to move.

Then someone checks the baseline. The model priced your highest-volume lanes at less-than-truckload rates, but you ship them full truckload. Your current costs are 18 percent lower than the model assumed. Savings are measured against the baseline, so an inflated baseline inflates the savings. Corrected, the number drops to $2.1 million. Half the business case is gone, and nothing changed except one input.

That hypothetical opened the presentation two of SimWell's simulation consultants, Jean-Daniel Mathieu and Ershad Jahagirdar, delivered at the anyLogistix Conference 2026. Their argument, drawn from years of network design and optimization projects across industries: "Most projects don't actually fail because the math is wrong."

They fail earlier, and quieter, than that.

Are you building a model, or answering a question?

Mathieu's team asks the same question at the start of every engagement. Are we building a model, or are we answering a question?

A model is a thing you construct. A question is a decision someone owns. Projects that start with the objective to build a model take longer, cost more, and rarely earn enough stakeholder trust to act on the output. Framing the project around the business decisions that need to be made aligns the modelers and business stakeholders to define the objectives, scenarios to run, and the fidelity required to support the decision. It also keeps the decision owners involved through the project, which is where the trust to act on the output comes from.

The failure modes the talk warns against all come from getting this backwards. A baseline that does not match reality, data issues caught too late to fix cheaply, transportation logic that misrepresents how freight moves, rates and units that do not mean what everyone assumes, a model that answers a question nobody asked, and scenarios that run to completion without a single decision made on the results.

Notice what's not on that list: solver errors, algorithm limitations, computational power.

Before the digital twin, the paper twin

On the team's projects, roughly a quarter of the total effort goes in before any modeling starts. That time goes to understanding the problem, the data, and the supply chain itself.

Jahagirdar's tool for this phase is deliberately low-tech. He calls it the paper twin. Sit down with stakeholders, take a pen, and draw the supply chain. Suppliers, plants, distribution centers, customers. Nodes first, then the lanes and flows that connect them, then the attributes like costs, capacities, and lead times.

"If you can't draw the supply chain on paper," he told the audience, "you won't be able to build the model."

The exercise does two things. It surfaces the organization's actual vocabulary, the sortation centers, satellite stations, and dark stores that don't appear in textbook diagrams but define how the network really operates. And it forces alignment before the expensive work begins. A Sankey diagram of twelve months of shipment history does the same job for flows. Within an hour, you can see which products move where, and, just as valuable, where the data contradicts itself, like inbound volumes that do not match outbound because inventory from a prior period is hiding in the gap.

The work in this phase takes a pen and a room of stakeholders, not software. The model gets built from the supply chain those stakeholders drew and agreed on, and that agreement is where teams start building trust in the model.

Transportation modeling is where projects are won or lost

In these projects, the team spends 30% of their time on transportation.

A network design model compares what your network costs today against what a redesigned network would cost. Today's lanes have real rates, because you ship on them. The redesigned network includes lanes you have never shipped on, and their rates have to be estimated. The savings claim is the difference between a real number and an estimated one, so the estimation method decides how much of the business case you can trust.

The team shared three rules for keeping the transportation costs honest. Do not flatten rates into one per-mile average, because freight cost per mile changes with distance. For full truckload, use regression or benchmark rates by vehicle type and region, because per-mile shortcuts do not work there at all. And verify the units, because a model that measures vehicle capacity in cubic meters while counting product in pallets will distort the load calculations downstream.

"Don't try to be more simple than realistic," Jahagirdar said. The savings number at the end of the project is only as honest as the freight logic underneath it.

Your first model run should expose bad data, not produce an answer

The final practice the team shared is to avoid building constraints as hard rules at the start.

A hard constraint is a condition the model must satisfy, such as delivering every unit of demand or respecting every capacity. Early in a project the data still contains contradictions, and a model built entirely on hard constraints responds to contradictions by producing nothing at all. The result comes back infeasible with no indication of which input broke it. Teams can burn weeks debugging.

The alternative is to start soft. Attach penalties instead of prohibitions, let the model run, and read the penalties as a diagnostic. If a customer's demand went 10 percent unfulfilled, trace why. Maybe a missing lane, a capacity typo, or a product flow restriction nobody documented. Each run reveals the next data issue, and constraints get hardened one at a time as the inputs are verified.

The first model runs are an audit of the data. The answers come later.

Six questions to ask before you fund the project

Mathieu and Jahagirdar built their talk for the people who build models. But every failure mode they described is preventable. Inverted, their list becomes due diligence for leaders considering a model to evaluate changes to their network:

What decision will this model support, who owns it, and by when?
How will the baseline be validated, and will finance sign off on it before scenarios run?
How will transportation costs be modeled, and how will rates be estimated for lanes we've never shipped?
Who is verifying units, rates, and capacities against source systems?
Which business question does each planned scenario answer?
What happens after the results are in? Who reviews them, and what gets decided?

If a proposal can't answer these, the math won't save it.

Jean-Daniel Mathieu and Ershad Jahagirdar are simulation consultants at SimWell. Their full presentation, "Best Practices – Supply Chain Design and Optimization Projects," from the anyLogistix Conference 2026 is available here