In short: An optimisation searches for the best configuration under expected conditions, while a simulation steps a clock, which is how you see what a node that is adequate on average does in a bad fortnight. The mechanics are ordinary, with weekly demand drawn from a fitted distribution, inventory position compared against a base stock level, and orders arriving after a lead time that is itself random. Disruptions are worth scheduling on purpose, closing the largest site for three weeks or halving a supplier's capacity, rather than waiting to observe one. Record the seed with every result, and settle the replication count arithmetically before claiming a difference between two configurations is real.
The network model comes back with five sites, a cost improvement in the high single digits, and every service constraint satisfied. It gets presented, questioned lightly, and approved. Eleven weeks into the new network a supplier lands two containers late into the largest site during the same fortnight that demand runs eleven percent above plan, and the site runs out of dock and pick capacity days before it runs out of stock. Orders that were meant to ship on Tuesday ship on Friday, the backlog rolls into the following week, and the recovery takes a month.
Nothing about that week existed in the model. The model had no weeks in it. It had an annual demand figure, an annual capacity figure, and a comparison between the two that came out comfortable, which is what a model built on averages will always say about a node that is adequate on average. Filling that gap is what a simulation is for, and it is the reason the two methods belong in sequence.
Optimisation and simulation answer different questions
An optimisation searches a space of decisions for the configuration that minimises a cost function subject to constraints, evaluated under expected conditions. Its output is a decision: open these sites, assign this demand there, hold this much.
A simulation takes one fixed configuration and plays time forward, drawing every uncertain quantity from a distribution rather than setting it to its mean. Its output is a distribution of outcomes for a decision you already made.
You cannot simulate your way to a good configuration, because the decision space is combinatorial and each evaluation costs you a full run rather than a matrix multiplication. You cannot optimise your way to a risk profile either, because the objective function averaged away the variability you now want to look at. The productive division of labour is to optimise first, come away with the two to four configurations sitting near the flat bottom of the cost curve, and then simulate those against each other. The optimiser genuinely cannot separate them, since they fall inside the error of its own cost inputs. The simulation can, because they behave differently under stress even when they cost the same on average.
What the weekly clock shows you
The mechanics are ordinary. The model steps a week at a time. At each node, for each item, demand is drawn from a fitted distribution. Inventory position is compared against a base stock level and a replenishment order is placed for the difference. Orders arrive after a lead time that is itself drawn from a distribution. Unmet demand is backordered or lost according to the policy you set. Capacity at each node is finite, so a week's throughput requirement above capacity spills into the following week. Run three or four simulated years, repeat with different random draws, and look at what came out.
Four things appear that a deterministic model cannot produce.
Queueing at constrained nodes. Cost and delay are convex in utilisation, so the average of the behaviour is worse than the behaviour at the average. In the simplest textbook queue, expected work waiting is the square of utilisation divided by one minus utilisation. At seventy percent that is 1.6 units of work; at eighty-five percent it is 4.8; at ninety-five percent it is 18. A distribution centre is not that queue, and the convexity carries anyway. A deterministic model looks at a node running at eighty-five percent of capacity on average and reports that it fits. The simulation shows you the weeks at a hundred and ten percent, the spill into the following week, and how long the node takes to work the backlog off.
Correlated failures. Deterministic models treat a demand spike and a supply delay as separate events with separate allowances. In the real network they arrive in the same week, often for the same underlying reason, and a buffer sized independently for each is not sized for both together. Correlation across demand nodes matters just as much, because the pooling benefit that justified consolidating the network assumes the nodes are not all having a bad week simultaneously. Feed the simulation a common demand factor and the pooling benefit shrinks, sometimes enough to change which configuration wins.
The service distribution rather than the service mean. A design that meets a ninety-eight percent service target on average can deliver ninety-nine and a half in forty weeks of the year and eighty-eight in the other twelve. Customers experience the twelve. Report the fifth percentile of weekly service, the count of weeks below whatever number is written into your customer agreements, and the longest run of consecutive bad weeks, because those are quantities a customer service director recognises from their own inbox. A mean is a weak summary of a bounded, left-skewed quantity, and service is exactly that.
Transient behaviour. A steady-state model has removed, by construction, the period during which a new configuration is settling. That period is when the new site is learning to pick, the base stock levels are wrong because they were set from the old network's lead times, and the transfers are still in flight.
Running a disruption on purpose
The second use of the model is scheduled disruption. Close the largest site for three weeks starting in week twenty. Halve a supplier's capacity from week ten to week twenty-two. Add six weeks to an ocean lane. Take a plant offline for a maintenance overrun.
What comes back is more useful than a headline cost. You get time to recover, which is the number executives actually ask for. You get peak backorder and where it accumulated. You see whether the network self-heals or whether the backlog compounds because the recovery weeks were already near capacity. And you find out which nodes absorbed the load, which is often a site nobody expected to be in the recovery path.
Two habits make disruption runs worth the compute. Run the same disruption against each candidate configuration using the same random seed, so the demand path is identical and the only difference between the arms is the design. That is common random numbers, the paired-comparison technique treated in Law and Kelton's Simulation Modeling and Analysis, and its effect on the arithmetic below is substantial. And vary the start week, because a three-week outage during the pre-peak build is a different event from the same outage in January, and averaging over start weeks hides both.
Seeds, or it did not happen
Every stochastic path in the model should run from an explicit, recorded seed, and the result should be stored with the seed attached, because a pointer to a config file that gets overwritten next Tuesday is worth nothing.
There are three reasons and they all bite eventually. The first is auditability. Somebody in finance will ask you to reproduce a number six weeks after you produced it, and a model that gives a different answer each time it runs, with no explanation of why, is generating anecdotes. The second is debugging. When a run produces an outcome that looks wrong, you need to replay exactly that path and step through the week where it went strange, which is impossible without the seed. The third is the paired comparison described above, which requires you to drive two configurations with the same demand and lead time draws.
Version the inputs with the run as well. A rerun that quietly used a refitted demand distribution is a different experiment wearing the same name, and the difference will be attributed to the design change rather than to the refit.
How many replications before a difference is real
This is where most simulation work in planning goes wrong, and the fix is arithmetic rather than judgement.
You are comparing two configurations on some outcome, usually annual cost or weeks below service. Run both under the same seeds and take the difference within each replication. The half-width of the confidence interval on the mean difference shrinks with the square root of the number of replications, so halving the interval takes four times the runs.
The procedure is short. Run a pilot of fifteen or twenty paired replications. Compute the standard deviation of the paired difference. Decide the smallest difference you would act on, and set your target half-width below it. Then the number of replications you need is approximately the square of 1.96 times that standard deviation divided by the half-width.
Numbers make it concrete. Suppose the mean annual cost difference between two configurations comes out at four hundred thousand, and the standard deviation of the paired difference across the pilot is nine hundred thousand. For a half-width of two hundred thousand at ninety-five percent confidence, you need roughly the square of 1.96 times nine over two, which is about seventy-eight replications. Now suppose common random numbers cut the paired standard deviation to four hundred thousand, which is a realistic effect when the two configurations share most of their demand process. The same calculation gives about sixteen. The required effort falls with the square of the standard deviation, which is the practical reason to insist on paired seeds before anyone runs anything.
Two more rules of thumb belong with it. Discard a warm-up period so the arbitrary starting inventory does not dominate the early weeks; the usual approach is Welch's, which plots the ensemble average of a key output by week across replications and truncates where the line flattens. And treat small replication counts honestly. Three replications is decoration. Below about twenty you should not report a difference at all unless it is enormous. If two configurations remain inside the confidence interval after a hundred paired replications, they are the same to this model, and you should choose between them on grounds it does not contain.
Where this stops
A simulation is worth exactly what its input distributions are worth, and fitting those needs history most businesses have not kept in a usable form.
Demand distributions have to be fitted per node and per item at the grain the model steps. What you almost certainly have is shipment history, which is censored by what you were able to supply and shaped by your own past allocation rules, so it understates variability in exactly the periods that matter. Recovering true demand from censored history is a separate piece of work and it should happen before the fitting rather than after the results are questioned.
Lead time distributions need actual receipt dates against promised dates, which usually live in a receiving system nobody has ever extracted for planning purposes. Using a contractual lead time with an assumed variance produces a model that is confident and wrong in the same direction every time.
Correlation is the hardest input of the three. Estimating a full correlation matrix across nodes requires far more data than estimating means, and two years of weekly history gives you around a hundred observations, which supports a handful of parameters, well short of a matrix with hundreds of free entries. The workable fallback is a single common factor with one loading per node, stated openly as an assumption and varied across runs to see how much it matters.
All of which leads to the right way to read the output. The absolute numbers carry the full uncertainty of the fitted inputs, so quoting the simulated annual cost as a budget figure is overreach. Comparisons between configurations under identical inputs are far more reliable, because the input error is common to both arms and cancels in the difference. Use it to rank designs and to size recovery times, and be careful about lifting a single number out of it.
Take the two configurations you are currently arguing about, run twenty paired replications from recorded seeds, and look at the fifth percentile of weekly service in each rather than the mean, which will usually tell you within an afternoon whether you have a real difference or two names for the same design.