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:
- You have a candidate design and need to know whether it holds up under realistic variance.
- The question is about time: when stockouts happen, how inventory moves, how the network recovers after a demand spike.
- Policy is the variable: order points, order quantities, where safety stock sits, how often you replenish.
- You need to see the shape of a failure, not just its probability.
Don’t reach for simulation when:
- You’re still choosing among thousands of candidate designs. Simulation evaluates a design; it doesn’t search the design space. Use optimization to narrow the field first.
- You want a single provably best answer. Simulation gives you an outcome, not the optimum.
- You don’t have a design yet. Simulating nothing tells you nothing, so start with greenfield or facility selection.
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:
- You need good starting points for a simulation’s inputs. Reorder points, structure and sourcing are all simulation inputs, and optimization calculations can supply them.
- You want to see the efficient frontier of a system and what each near-optimal choice implies.
- You want a more robust answer. Optimization needs a host of assumptions. Simulation describes the system, so many of the things optimization assumes away, such as competition for scarce resources over time, can be explored.
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:
- Consume: demand draws stock at a consuming site.
- Check inventory: a site compares its position against its ordering policy.
- Place order: the position has fallen below the order point, so an order goes upstream.
- Fill order: the supplier allocates what it can against that order.
- Ship and deliver: material moves along a lane and arrives after the lane’s transit time.
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 replication, not a distribution. Each model runs once. You get one future, not the spread of futures. A real study runs many replications with different seeds and reports the range. A single trajectory can be lucky.
- Results are deterministic. Running the same model again returns the same numbers. That’s deliberate, because it makes the demo quotable and reproducible, but it means you can’t re-roll to see variance here.
- Warm-up is included. A 30-day run starts from a seeded inventory position, and the opening days reflect that seeding rather than steady state. Judge the trend, not day one.
- Fixed parameters. The public demos run the sample models as authored. Changing order points, lead times or demand patterns is desktop work.
- Simulation reports; it doesn’t choose. It shows how a policy affects inventory and stockouts. Picking the policy is up to you, or to an optimizer.
- The model is only as good as its inputs. Lane transit times, demand profiles and starting stock are authored assumptions. Simulation carries them through faithfully, errors included.
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:
- Simple Supply Chain: Simulation Dynamics’ original teaching model. A single-SKU chain from a Long Beach supplier through Memphis to New York, run for 200 simulated days through a demand spike.
- Cookie Production: a Nashville plant feeding 12 regional DCs and 36 retail customer zones, three per DC, over 30 simulated days.
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.