Why Optimization Needs Simulation

Why Optimization Needs Simulation

Every optimization model makes a bargain. To find the best answer in reasonable time, it simplifies the problem: demand is treated as a known quantity, lead times as fixed values, supplier reliability as a single number. These aren't errors in judgment. They're necessary trade-offs. Without them, the algorithms would be computationally intractable, and you'd never get an answer in time to act on it.

The problem is that reality doesn't honor the simplification.

Demand swings 20–30% from forecast routinely. Lead times stretch without warning. A supplier running a 98% on-time rate is still failing you 2% of the time, and that 2% has a way of concentrating at the worst possible moments. The optimization was technically correct. It was optimal for a world that doesn't quite exist.

This is the gap simulation is designed to close.

What Simulation Actually Changes

When I describe this to people unfamiliar with the mechanics, I use a simple frame:

Optimization tells you the best route. Simulation lets you drive it in traffic, in rain, during construction, before you commit to it.

More precisely: simulation replaces the fixed assumptions in your optimization model with probability distributions fitted to how your system actually behaves. Instead of "demand is 10,000 units," you draw from a distribution that reflects observed demand variability. Instead of "lead time is 14 days," you sample from the distribution of actual lead times in your historical data. Instead of "the machine is always available," you model the breakdown frequencies and repair times your operations actually experience. Run that process thousands of times, and instead of a single outcome, you get a range, with the probability of each outcome attached.

The result changes the conversation. "This plan saves $4.2 million" becomes "this decision is expected to save $3.9M — but the range runs from $2.1M to $5.8M depending on conditions, with roughly a 15% chance of service failures during peak season." That's a different thing to present to leadership, and a more honest one.

The Case For Running Them Together

Where I think simulation is genuinely underused is not as a validation step after the optimizer runs. It belongs as part of an iterative loop with the optimizer itself.

The workflow that actually produces robust decisions looks like this: run the optimizer, simulate the results, identify where the decision breaks under realistic conditions, adjust the model constraints or objective function, optimize again. Repeat until you have something that performs well not just at the expected values, but across the distribution of plausible futures.

Optimizers are, by design, optimistic. Simulation reveals what happens when the assumptions are wrong, which they always are, to varying degrees.

A Worked Example

A regional distributor consolidating from five distribution centers to three is a straightforward optimization problem. The model says the consolidation saves $6.1 million annually: less real estate, better transportation efficiency, tighter inventory.

Without simulation, the analysis goes to leadership, the numbers look good, the project gets approved. Eighteen months later, the network is hitting service failures every time demand spikes above forecast: expedited shipments, unhappy customers, and actual savings of around $1.3 million once you account for the costs.

With simulation, the team runs the proposed network through several thousand demand scenarios before anyone approves anything. What they learn: median savings are closer to $4.8 million (optimizers tend to be optimistic about the upside), there's roughly a 20% probability of service failures during Q4, and there's one specific vulnerability. If a particular DC hits capacity during peak, the failure cascades across the network.

That finding changes the decision. Flexible capacity options are preserved, safety stock is repositioned, contingency triggers are built in for peak season. The project goes forward, with an accurate picture of the risk.

Final result: $4.4 million in savings, service levels intact. The optimization was still worth running. Simulation made it trustworthy.

Why this Loop is Finally Practical

Historically, the reason organizations skipped this loop wasn't skepticism about simulation's value. It was friction. Optimization and simulation tools lived in separate environments, maintained by different teams, operating on different data models. Running the optimize-simulate-refine cycle meant manual data transfers, format conversions, and enough engineering overhead that most organizations could only justify it for their largest strategic decisions.

At Lyric, we built simulation as a native capability within the same environment where optimization runs. Distribution fitting happens automatically from historical data. The simulation engine scales to thousands of scenarios. Because the models share a data layer, the optimize-simulate-refine loop runs without moving data between systems.

The practical effect: this workflow becomes accessible for tactical and operational decisions, not just annual strategic reviews. Weekly replenishment policies, production split decisions, inventory positioning — the same rigor that used to be reserved for network redesign can be applied to supply chain decisions routinely.

Two Tools. One Decision You Can Trust

Every supply chain decision carries uncertainty.

The question isn't whether to accept that. It's whether you've characterized it before you commit, or after.

Optimization is the right tool for finding the best answer to a well-posed problem. Simulation is what lets you check whether your problem was well-posed in the first place.

Used together, they close the gap between the decision that looked right and the decision that holds up.

If you want to see what your optimization models look like when simulation is running alongside them, we'd like to show you.