Supply Chain

How Supply Chain Simulation Works
A Plan, Played Out Event by Event

An optimizer asks what the best design is. A simulation asks what actually happens when you run that design through time. Here’s how a discrete-event supply chain simulation does it, what to read in its output and where its limits are.

What problem does it solve?

Simulation answers a different question from optimization. Optimization asks “what is the best design?” Simulation asks “what actually happens if we run this design through time?”

A network optimizer hands you a design that’s optimal on average, given aggregate demand, average lead times and capacity it assumes is fully usable. Simulation takes a design and plays it out event by event: this order is placed on day 14, this shipment leaves two days later, this DC runs dry on day 61 because three replenishments landed late in a row. It’s the difference between a plan and a rehearsal.

The value is in what averages hide. A design that shows 97% service on an optimizer’s summary line can be 100% for ten months and very bad for two. Simulation is how you find that out before your customers do.

When to use it, and when not to

Reach for simulation when:

Don’t reach for simulation when:

The table in network optimization explained covers the split in more detail. The short version: optimize to find the candidate, simulate to confirm it holds up.

Reach for both when:

Under the hood: discrete-event simulation

The engine is event-driven, not clock-driven. It doesn’t step forward an hour at a time asking whether anything changed. It keeps a future-event list ordered by time, takes the next event, applies it, schedules whatever that event causes, and jumps the clock straight to the following event. Long quiet stretches cost nothing, and the model spends compute only where something happens.

The event vocabulary for a supply chain model is small:

Inventory position, not on-hand stock, drives reordering: on-hand, plus what’s already on order, minus orders still to fill (and, optionally, minus reserves for periods when demand runs above capacity), compared against the order point. That’s what stops a site from ordering five times while the first truck is still on the road.

Everything downstream, including service level, stockouts and inventory curves, is emergent. Nobody sets a fill rate. It falls out of demand timing, lane transit times, order points and what the supplier happened to have on hand when each order arrived.

What the Sandbox shows you

A run in the Sandbox Networks tier gives you an inventory small-multiples grid (click any series to move it to the detail chart), lane widths on the map weighted by volume, and a replay control that animates shipments along their lanes from creation to delivery. The raw engine output sits under every result, so any number the Sandbox shows can be checked against the records it came from.

Known limitations of the demos

Be clear about what these runs are and aren’t:

One modeling detail you’ll see: in the four-tier chains (plant to DC to customer zone), each DC carries a small base demand of 1 unit per day per SKU that no customer orders. It’s a simple heartbeat for consumption at the DC.

The two simulation demos

Two models run against the engine on request, not from a recorded answer:

For simulation against your own network, with your lanes, your demand history and your policies, parameters you control and many replications, talk to us. The desktop tool runs on your data locally, so your network never leaves your machine.

Sources: discrete-event simulation methodology as taught in OR/SCM courses and commercial supply chain tools; archived enterprise supply chain training material (2013–2015). Simple Supply Chain model: Simulation Dynamics, Inc.

Run a network through 30 days of demand

Cookie Production runs in your browser, with nothing to install and no sign-up.

Open Cookie Production →

Or start with what supply chain simulation is for.