In short: Setting safety stock node by node makes each stage protect itself against the same uncertainty, so the variability is counted and paid for several times over. Two model families dominate, the guaranteed service model from Graves and Willems in 2000 that most commercial systems implement, and the stochastic service line running back to Clark and Scarf in 1960, which assumes something different about a stage that cannot deliver. The exact dynamic programming result holds on trees, and a network where two plants can supply one distribution centre is a general acyclic graph the recursion does not cover. Published reduction ranges sit around ten to thirty per cent, with the top of that range belonging to networks that were badly configured to start with.
Set safety stock node by node and every node protects itself against the same uncertainty. The plant holds a buffer because demand is variable. The central warehouse holds a buffer because demand is variable. Each regional site holds a buffer for the same reason. The variability was counted four times and paid for four times, and none of those four decisions was wrong on its own terms.
This is the problem multi-echelon inventory optimization exists to solve, and the reason it consistently releases cash in networks that are already well run at the local level. Published reduction ranges sit somewhere around ten to thirty percent, and I would treat the top of that range as the outcome for networks that were badly configured to begin with rather than as a typical result.
The methods are older and more settled than the marketing implies. Two families, both from the operations research literature, and they answer subtly different questions.
The guaranteed service model
The first family comes from Graves and Willems, published in 2000, and it is the one most commercial systems implement. The framing is unusual and takes a minute to sit with.
Every stage in the network quotes a service time to the stage downstream of it. That is a commitment: if you order from me, I will deliver in this many days. Every stage also faces an inbound service time, which is the longest of the service times quoted to it by its own suppliers.
Given an inbound service time, a processing time at the stage, and a service time the stage has committed to quote outward, the net replenishment time is inbound plus processing minus committed. That is the window the stage has to cover from stock, and it must be at least zero. The stage carries safety stock sized against demand variability over that window.
The interesting move is that demand variability is assumed bounded, and each stage aggregates the variability of everything downstream that depends on it, combining independent streams in the usual root sum of squares way. The total cost is the sum across stages of the holding cost times the buffer.
The decision variables are the committed service times. Set them all to zero and every stage holds a large buffer, because each has to cover its whole processing time from stock. Set an intermediate stage's committed time high and it holds almost nothing, pushing the burden downstream. The optimisation finds the assignment that minimises total holding cost across the network while still meeting whatever the customer-facing stages are required to quote externally.
A small example makes the mechanism visible. Take a central distribution centre supplied from a plant on a 14 day lead time, feeding four regional sites on a 3 day lead time each. Regional demand runs at 100 units a day with a standard deviation of 30. The four streams are independent, so pooled demand at the centre is 400 a day with a standard deviation of 60, which is 30 times the square root of four. Eppen established that square root relationship for the multi-location case in Management Science in 1979, and it is why the answer is never to hold everything locally.
Buffer each stage at a 95% service factor of 1.645 against its net replenishment time.
Assignment one, every stage quotes zero days to the stage below it. The centre covers 14 days: 1.645 times 60 times the square root of 14, or 369 units. Each region covers 3 days: 1.645 times 30 times the square root of 3, or 85 units, so 342 across the four. Total 711.
Assignment two, the centre quotes its full 14 days and holds nothing itself. Each region's net replenishment time becomes 14 plus 3, or 17 days, giving 203 units each and 814 across the four. Total 814, which is worse than doing nothing clever.
Assignment three, the centre quotes zero and each region quotes 3 days to its own customers. The regions' net replenishment time falls to zero and they hold nothing. Total 369.
Same network, same service factor, three integer assignments, and total buffer ranging from 369 to 814 units. The optimiser is searching over exactly this. Assignment three halves the stock by moving three days of the promise onto the customer, which is a commercial decision that deserves to be taken deliberately rather than discovered in a solver output.
On a tree, this can be solved exactly by dynamic programming. Graves and Willems gave the recursion, and there is an important correction in the 2003 erratum where adjacent subtree contributions have to be minimised over a range of service times rather than evaluated at a point. Implementations that miss that detail produce answers that look plausible and are not optimal, which is worth asking about when a vendor tells you their solve is exact.
The stochastic service model
The second family goes back further, to Clark and Scarf in 1960, and it makes a different assumption about what happens when a stage cannot deliver.
Guaranteed service assumes an upstream stage always meets its committed time, and handles the extreme cases by treating demand as bounded, with anything beyond the bound managed by some operational escape such as expediting. Stochastic service allows an upstream stage to fail and models the resulting delay as it propagates downstream.
The stochastic view is more faithful to how networks actually misbehave. It is also much harder to solve, with exact results limited largely to serial systems, solved by decomposing the problem into a sequence of newsvendor problems on echelon inventory positions with critical ratios derived stage by stage.
The practical position most implementations land on is guaranteed service for the network optimisation, because it scales to real topologies, with the awareness that it will understate risk when upstream reliability is genuinely poor. If your plants miss their commitments routinely, the guaranteed service answer is optimistic and the honest response is to fix the upstream reliability rather than to model around it.
General networks and what happens to the guarantee
The exact dynamic programming result holds on trees. Many real networks are not trees. As soon as a distribution centre can be supplied by two plants, or a component feeds two assemblies, you have a general acyclic graph and the tree recursion does not apply.
The usual approach is a heuristic search over the integer service time assignments, typically a hill climb with random restarts. It gives good answers and offers no optimality guarantee, which is fine as long as everybody understands that is what they have. The useful validation is to run the heuristic on tree instances where the exact answer is computable and confirm it recovers the optimum. If a vendor cannot tell you whether their general network solve is exact or heuristic, that is informative on its own.
What the results actually look like
Three patterns show up repeatedly when a network is optimised for the first time, and they are worth anticipating because two of them are politically difficult.
Buffers concentrate upstream and at the point of differentiation. The optimiser tends to hold generic inventory as far back as it can, because a unit of generic stock covers demand variability for every downstream variant that shares it, while a unit of finished stock covers only one. This is risk pooling working through the objective function, and it is the mathematical form of the postponement argument.
Some nodes go to zero. The model will frequently recommend that an intermediate stage hold nothing at all, quoting its full processing time outward and letting the downstream stage carry the buffer. Site managers experience this as being asked to run without a safety net, and it is worth explaining before the numbers land, because a site that quietly rebuilds its buffer will restore the cost you just removed and no report will show it.
The service and cost curve is steeper than expected at the top. The last point of service costs several times what the previous point cost. Running the frontier and putting the marginal cost of moving from 97% to 98% in front of the commercial team is often the most valuable output of the whole exercise, independent of any reallocation.
The inputs that decide whether this works
The mathematics is the easy part. The failure mode is nearly always the input data, and four things do most of the damage.
Network topology has to be right, including which nodes can actually supply which. Most master data contains historical lanes that are no longer used and current lanes nobody recorded.
Processing times must be real elapsed times rather than standard times from a routing table. The gap between the two is often substantial and always in the same direction.
Demand variability has to be measured at the right node and the right grain, after correcting for stockouts. If your history is censored, your variability estimate is understated and every buffer in the network inherits the error.
Holding cost has to differentiate by item and stage. A single company-wide carrying rate applied uniformly will produce a plausible-looking answer that has thrown away the main lever, since the whole point is to hold cheap things generously and expensive things sparingly.
If those four are not in place, the optimisation will still run and produce numbers. That is the dangerous part, because an unvalidated multi-echelon result carries an authority it has not earned.
Where it does not apply well
Two situations where I would be cautious about the whole approach.
Very short life cycle products, where the item is obsolete before the network reaches steady state. These models assume a stationary demand process and an equilibrium policy, and neither holds for a product with a nine-week commercial life. The relevant machinery there is closer to a newsvendor with markdown than to echelon optimisation.
Networks dominated by a single large customer. The variance pooling that gives multi-echelon its advantage assumes many independent demand streams. When one customer accounts for half your volume, their ordering pattern is the demand process, and the right response is a collaborative arrangement with that customer rather than a cleverer buffer.
There is also a governance limit worth stating. A multi-echelon result is a network-level optimum, and network-level optima are only stable if the incentives at each node are aligned with them. A site measured on its own local service level will not comply with a recommendation to hold nothing, and it should not be expected to. Change the measure before changing the buffer, or the model's answer and the organisation's behaviour will diverge within a quarter.
The map that finds the duplication is a query rather than a project. For each item, take the days of cover at every stage in its chain and add them up, then compare the total against the end-to-end pipeline time from plant to customer. A chain with a 14 day inbound leg and a 3 day outbound leg carries 17 days of exposure, so an item showing 46 days of summed cover across its stages is holding roughly three copies of the same protection. Sort by the gap multiplied by unit cost, and the top of that list is where the cash sits.
The reason this remains worth doing despite all of that is the size of the prize. Most networks are holding several copies of the same protection, and the cash released by removing the duplicates is available without any change to service. Start by mapping where the same variability is currently being covered more than once. That map is usually persuasive before any optimisation has been run.