Fifteen years of designing supply chain networks has taught me that most network studies fail before they begin, in the baseline. Here is how to get the foundation, the modelling, and the tool choice right.
Network Optimisation and Tool Selection: A Practitioner's View After Fifteen Years
I have spent fifteen years designing and redesigning supply chain networks, across retail, FMCG, manufacturing, infrastructure, and government, first inside large consulting and planning firms and now at Trace. In that time I have built a lot of models, sat in a lot of steering committees, and watched a lot of network studies either change a business or quietly gather dust. This is not a textbook explanation of supply chain network optimisation. It is a point of view about what separates the network work that lands from the network work that does not.
The headline of that view is simple: the optimisation engine is the least interesting part of the problem. I have seen excellent tools produce useless answers and modest tools produce decisions worth tens of millions, and the difference almost never came down to the solver. It came down to three things that get far less attention than they deserve. Whether the baseline was properly calibrated. Whether the modelling genuinely grappled with uncertainty rather than optimising to a single forecast. And whether the network decision was made together with inventory and ordering mechanics, or in isolation from them. Get those three right and the choice of tool becomes a secondary question. Get them wrong and no platform will save you. What follows is how I think about each, and where tool selection actually fits once the priorities are straight.
What supply chain network optimisation actually is, and why it so often disappoints
Supply chain network optimisation, also called network design, is the discipline of deciding the structural shape of your supply chain: how many distribution centres or plants you should have and where, which customers and regions each should serve, where inventory should sit across the network, and how product should flow from source to shelf. These decisions set the fixed footprint within which all your day-to-day planning then operates. They shape cost and service for years, which is why getting them right matters and why getting them wrong is so painful to unwind.
Network studies disappoint more often than almost any other kind of supply chain work, and I have learned to recognise the pattern early. A study kicks off with energy, a tool is licensed, a model is built at pace, and a sensible-sounding recommendation emerges, to consolidate from four sites to two, or to add a node in a growth region. The deck is polished and the savings are quantified to a suspiciously precise number. Then the recommendation goes nowhere, because when the business looks closely it does not quite trust it. The numbers do not reconcile with what finance sees. The inventory implications were waved through. The model assumed a single demand future everyone knows will not eventuate. So the boldest structural moves get deferred, and the business carries on with a footprint it has half-suspected is wrong for years.
When I unpick why these studies fail, it is almost never the mathematics. The optimisation techniques at the heart of network design are mature, and the commercial tools solve them perfectly well. The failures sit upstream and downstream of the solver: a baseline nobody calibrated, a refusal to model uncertainty honestly, a network question divorced from inventory, and an absence of the executive ownership needed to act on a structural change. The tool gets blamed, or credited, far more than it deserves. So before tools, I want to talk about the things that actually determine whether the work is worth doing.
It begins and ends with the baseline: the calibrated digital twin
If you take one thing from this article, take this. A network model is only as good as the baseline it is built on, and the most common and most expensive mistake I see is teams rushing past the baseline to get to the scenarios. Everything you build on top inherits the flaws underneath.
The baseline is what the industry now calls a digital twin: a model of your current network that reproduces, as faithfully as the data allows, how your supply chain behaves today. The major platforms lean on this language heavily, Coupa, for instance, markets a true digital twin of the extended supply chain, and the concept is sound. But a digital twin is only useful if it is calibrated, and calibration is the step that gets skimped. By calibration I mean tuning the model until it reproduces last year's reality, your actual costs, volumes, flows, and service, within an acceptable tolerance, before you trust it to tell you anything about the future. If the model cannot reproduce what already happened, it has no business forecasting what should happen next.
This is harder and less glamorous than it sounds, which is why it gets rushed. Calibrating a baseline means reconciling the model's freight cost against the freight you actually paid, lane by lane and mode by mode. It means handling and warehousing costs that reflect your real operations, not a generic rate card. It means demand that matches what you actually shipped, and lead times that reflect the variable real world rather than a single number copied from an ERP field. It means finding the awkward reconciling items: costs in the wrong cost centre, inter-site transfers nobody accounts for cleanly, peaks the annual average hides. The test I apply is blunt. Fed last year's demand, does the model reproduce last year's cost and service to within a few per cent? If not, I do not move on. An uncalibrated baseline is worse than no model, because it carries the false authority of precision. A rough spreadsheet invites scrutiny. A polished optimisation model that is quietly wrong gets believed.
The baseline also earns you the right to be believed. When I can show a CFO that our model reproduces their actuals, that it tells them what they already know to be true about last year, the scepticism drains out of the room and every number on top is easier to trust. Skip that step and the whole analysis fights an undertow of doubt. The baseline is not a chore to get through on the way to the scenarios. It is where most of the value, and almost all of the credibility, is won or lost.
Scenario modelling: the value is in the questions, not the solver
Once you have a baseline you trust, scenario modelling is where the value gets created, and the craft is almost entirely in the questions. The solver will optimise whatever you point it at. Whether the exercise is worth anything depends on whether you framed the right decisions.
The scenarios that matter are rarely just "what is the lowest-cost footprint." That is the question everyone asks first and usually the least interesting, because lowest cost in isolation is almost never what the business actually wants. The valuable scenarios explore the real decision space: at what point does consolidation start to break service for which customers; how does the optimal network change if the business grows thirty per cent, shifts toward e-commerce, or wins a major customer in a region you barely serve; what does the network need to look like if a key site is lost to a lease expiry or a disruption; how does an acquisition reshape the answer. A good scenario set brackets the genuinely consequential questions and the genuinely plausible futures, rather than running twenty minor variations to manufacture the appearance of rigour.
The discipline I hold to most firmly is to resist optimising to a single point. It is tempting to take the base-case forecast, optimise to it, and present the result as the answer. But a network tuned perfectly to one forecast is, by construction, fragile to every other forecast, and we know with certainty the single forecast is wrong. The right question is not "what is the optimal network for the expected future" but "what is the network that performs well across the range of futures we might face." That leads into the two techniques that separate serious network work from the rest: sensitivity testing and Monte Carlo analysis.
Sensitivity testing and Monte Carlo: designing for a range of futures
A network recommendation that has not been stress-tested against uncertainty is incomplete, however elegant the optimisation. Structural decisions are ones you live with for years, through conditions you cannot foresee, so the question is never just "is this optimal today" but "how robust is this to what will change."
Sensitivity testing is the simpler layer. It asks how the answer moves as you flex the inputs that matter: fuel and freight, demand volume and mix, labour and property costs, lead times. Its value is in showing which assumptions the recommendation actually hinges on. Sometimes the optimal footprint is stable across a wide range of fuel prices, so you can stop worrying about fuel and act with confidence. Other times the whole recommendation flips on a ten per cent freight movement, which is vital to know before you commit capital. I have seen recommendations that looked compelling at the base case fall apart under sensitivity testing, and I would far rather discover that in the model than two years into a property lease.
Monte Carlo analysis goes further, and for high-stakes decisions it is where the real robustness work happens. Rather than flexing one variable at a time, it runs the network across thousands of randomised scenarios, drawing each uncertain input from a probability distribution and aggregating the results to show the full range of outcomes a design produces. This reframes the decision. Instead of "design A saves two million in the base case," you get "design A saves between half a million and three million across the plausible range and never performs worse than the status quo," against "design B has a higher expected saving but a real tail risk of underperforming today if demand softens." That is a far richer basis for a structural decision, because it lets you choose a network for resilience, the one that performs well across most futures and protects you in the bad ones, rather than the one perfectly tuned to a future that will not arrive.
This matters more now than when I started, because the environment is less stable. McKinsey's research, widely cited across the industry, finds that supply chain disruptions lasting longer than a month now occur every 3.7 years on average and can cost businesses up to 45 per cent of a year's profit over a decade. When disruption on that scale is near-certain over the life of a network decision, designing to a single benign forecast is not optimism, it is negligence. A network designed with uncertainty built in is one you can defend to the board in three years when conditions have moved and the design still holds. deloitte
The decision is strategic enablement, not cost minimisation
A conviction that has only hardened with experience: the best network studies start with "what are we trying to enable," not "how do we save money." A network is the physical expression of a business strategy, and if you design it purely to minimise cost you will often design something that undermines what the business is trying to achieve.
The clearest way to see this is through the customer value proposition, because the network encodes it whether you intend it to or not. The trade-offs in network design, fewer larger sites against more smaller ones, central inventory against forward-positioned inventory, lowest cost against fastest delivery against greatest resilience, are not abstract parameters. They are decisions about what promise you make to which customers. Consolidating to two large distribution centres might be the lowest-cost answer, but if it breaks the next-day promise your best customers buy from you for, you have optimised your way out of your own value proposition. A more distributed, slightly more expensive network might be exactly right if speed and availability are how you win. There is no universal answer, because it depends on what the business is for and which customers matter most.
So I push hard, at the start of every engagement, to get the strategy and the value proposition on the table before we touch the model. Who are we serving, and what do they value: price, speed, availability, breadth, reliability? Which segments are we willing to serve differently? Where is the business heading, into which channels and regions? What is our appetite for resilience versus efficiency, knowing the two genuinely trade off and the last few years have repriced that trade-off for most boards? And where does sustainability sit, because network structure drives a large share of transport emissions, and more of the businesses I work with now treat carbon as a real constraint. Only once those are answered does optimising make sense, because they define what "optimal" means. I would rather spend a day arguing about the value proposition than a month optimising against a goal nobody has examined.
The point too many people miss: network and inventory cannot be decided apart
If the baseline is the thing teams most often skimp, this is the thing they most often get structurally wrong, and it is the most expensive class of error I encounter. Network decisions cannot be made in isolation from inventory and ordering mechanics, because they are not separate problems. They are the same problem at different time horizons, and treating them separately is how businesses arrive at footprints that look optimal on the network model and prove uneconomic in reality.
Here is why they are inseparable. Where you hold inventory is simultaneously a network decision and an inventory decision. The moment you add or remove a node, you change the inventory the network must carry, through the pooling effect: consolidating stock into fewer locations reduces total safety stock, because aggregated demand variability is proportionally smaller, while spreading stock across more forward locations increases it. This is not a second-order detail. The inventory consequence of a footprint change can be large enough to outweigh the transport and facility savings the network model was optimising for. I have seen studies recommend consolidating to fewer sites on transport and overhead savings, only for the move to collapse once someone modelled the inventory, because the forward-positioning the service promise required, combined with the suppliers' ordering constraints, wiped out the saving. The network model said yes. The inventory reality said no. Nobody had put the two in the same room.
Ordering mechanics compound this. Replenishment frequency, minimum order quantities, batch sizes, container and pallet rounding, and order policies all determine how product actually flows through the network and therefore what it truly costs to operate. A network optimised as if product flows in smooth, perfectly divisible streams will mislead you, because real product flows in lumps governed by ordering rules, and those lumps drive inventory, handling, and space. Multi-echelon inventory optimisation, which decides how much buffer to hold at each tier, is really the operational expression of a network design choice, and the two should share one model and one set of assumptions. I have written before, in our guide to supply chain planning for Australia and our work on demand, inventory, and replenishment, about how much value leaks at the seam between disciplines that should be joined. Nowhere is that seam more expensive than between network design and inventory.
The organisational version of this mistake is the one I see most. A strategy team runs the network study and hands over a footprint, while a separate planning team owns inventory on its own assumptions, and the two never reconcile. The result is either a recommendation that ignores its own inventory implications or, worse, a structural change built on transport savings that the inventory reality then undermines. My firm rule is that a network study that does not model the inventory and ordering consequences of each scenario is not finished, however polished the footprint analysis. The network question and the inventory question must be answered together, in one model, by people who are talking to each other. This single discipline, more than any tool or technique, is the difference between network work that holds up and network work that embarrasses everyone a year later.
Choosing the tool: what actually matters
Only now, with the priorities straight, do I come to tools, because this is the order in which they matter. The tool is the last and least of the decisions, and teams routinely over-invest in platform selection while under-investing in the baseline, the uncertainty modelling, and the network-inventory integration that actually determine success. The tool is not irrelevant, though, and the market has shifted enough recently to be worth understanding.
The criteria I care about, in order, are these. Can the tool support a properly calibrated baseline without taking months to stand up. Does it bring optimisation, simulation, and uncertainty analysis together, because a network you cannot stress-test is a network you cannot trust. Can it model inventory and ordering policy alongside network structure, in the same environment, so you avoid the hand-off that causes the most expensive errors. Can the people who will own it after the consultants leave actually use it. And can you re-run it as conditions change, treating network design as a living capability rather than a one-off project.
On the landscape, the picture in 2026 is genuinely in flux. For years the reference point was LLamasoft's Supply Chain Guru, which Coupa acquired in 2020 before Coupa itself was taken private by Thoma Bravo. That product is now sold as Coupa Supply Chain Design and Planning. It remains capable and proven on complex global networks, though the common view is that design investment has slowed under successive owners and the architecture is showing its age, with model construction still tied to the desktop. The most notable newer entrant is Optilogic's Cosmic Frog, built by former LLamasoft people as a cloud-native platform that combines optimisation, simulation, and risk in a single environment with a risk rating on every scenario. Alongside them sit AIMMS, with decades of pedigree in mathematical optimisation and what-if modelling, and anyLogistix, which is built on a simulation engine and is strong where dynamic, stochastic behaviour matters more than pure optimisation. Tellingly, the better modern platforms are converging on exactly the integration I have argued for: policy optimisation, which optimises reorder points and safety stock rules alongside network structure in the same model, is becoming a defining capability. The market is catching up to the idea that network and inventory belong together.
That is the case for GAINS, which is the platform we most often recommend at Trace and the one we have the deepest experience implementing. Its strength for this problem is integration. Network design sits inside a single platform that also runs demand forecasting, multi-echelon inventory optimisation, lead-time prediction, and replenishment, built around decision engineering and designed to overlay your existing systems rather than replace them. That is precisely what stops the network question and the inventory question being answered by two different tools on two sets of assumptions, which is the failure mode that does the most damage. GAINS added dedicated network design through its 2023 acquisition of 3 Tenets Optimization, and pairs it with a mature planning suite and an overlay architecture that keeps implementation cost and disruption low. For the businesses I work with, whose network decisions are inseparable from ongoing planning and inventory, that integration is the thing that matters most, and it is why GAINS is usually my recommendation. The right tool always depends on the problem in front of you, and you should choose it last, against the criteria above, not first against a slick demonstration.
Why network studies fail
To pull the threads together, here is the list I carry in my head, every item of which I have watched happen more than once.
They skip baseline calibration and build sophisticated scenarios on a foundation that cannot reproduce last year. They optimise to a single forecast and produce a network fragile to every future except the one that will not happen. They divorce the network decision from inventory and ordering mechanics, and recommend footprints the inventory reality makes uneconomic. They treat the study as a one-off rather than a living capability, so the model is obsolete within a year. They fall for tool-first thinking, investing in the platform while neglecting what actually matters. They design for cost rather than the customer value proposition, and optimise the business out of its own strategy. And they lack an executive owner and a real decision forum, so the analysis surfaces the right questions but the organisation never finds the resolve to act. Almost none of these are technical failures. They are failures of discipline, framing, and organisation, which is why I spend so little energy on the solver and so much on everything around it.
How Trace Consultants can help
At Trace Consultants, this is core ground for us, and we approach network work the way I have described it, because it is the way it actually pays off.
We build network models on baselines we have genuinely calibrated. Through our strategy and network design work, we stand up a digital twin that reproduces your actual costs, flows, and service, and we earn the right to be believed before modelling a single scenario.
We model the network and the inventory together, never apart. We bring the footprint question and the inventory and replenishment question into one model with one set of assumptions, drawing on our planning and operations capability and our multi-echelon inventory work, so the recommendation holds up against the inventory reality rather than collapsing under it.
We design for uncertainty and for your strategy. We stress-test recommendations with sensitivity and Monte Carlo analysis so the network you choose is robust across the futures you might face, and we anchor the work to your customer value proposition and growth strategy, so we optimise toward what the business is actually for.
We help you choose and implement the right tools, on the right criteria. We select for the ability to calibrate, to model uncertainty, and above all to optimise network and inventory together as a living capability. The platform we most often recommend and have the deepest experience with is GAINS, for the integration reasons above, and our view on technology sits on our technology page. Because the realities differ by sector, we bring practitioners who have done this work in your industry, whether retail or FMCG and manufacturing.
Explore our Strategy and Network Design services →
Speak to an expert at Trace →
Where to begin
If you are contemplating a network study, interrogate two things before you engage anyone or license anything. First, ask whether you can build, or have built, a baseline that genuinely reproduces your current cost and service, because if you cannot, that is the first piece of work and everything else waits behind it. Second, ask whether your network conversation and your inventory conversation are happening in the same room, with the same people and assumptions, or running on separate tracks. If they are separate, fix that before you optimise anything, because the most expensive network mistakes live in that gap.
From there the sequence is straightforward. Calibrate the baseline until you believe it. Frame the scenarios around the strategic decisions and plausible futures that matter, not a single forecast. Stress-test with sensitivity and Monte Carlo so you are choosing a resilient network rather than a fragile one. Model the inventory and ordering consequences of every option alongside the footprint. Anchor the whole thing to your customer value proposition. And choose your tool last, with a clear preference for one that keeps network and inventory together. Do that, and the recommendation will be one your board can act on with confidence.
The bottom line
If I had to compress fifteen years into a sentence, it would be this: the network is the easy part to model and the hard part to get right, and the difference is almost never the software. It is the rigour of the baseline, the honesty with which you treat uncertainty, the refusal to separate the network from the inventory and ordering mechanics that determine its real cost, and the discipline to design toward what the business is for rather than the lowest number on a slide. The tools keep improving, but they remain instruments. They amplify the quality of the thinking around them; they do not substitute for it.
The businesses that get extraordinary value from network optimisation treat it as a strategic, ongoing capability, built on foundations they trust, integrated with their planning, and owned by people senior enough to act on what it reveals. The ones that are disappointed bought a tool and hoped it would do the thinking for them. The footprint of your supply chain shapes your cost and service for years. Design it with more rigour than a single forecast and more honesty than a cost-cutting exercise, and the tool you choose to support it will be the smallest of your worries.
If you are weighing a change to your network, Trace can help you build the baseline, model it properly, and make a structural decision that holds up.
Explore our Strategy and Network Design services →
Speak to an expert at Trace →
Frequently asked questions
What is supply chain network optimisation?
Supply chain network optimisation, or network design, is the discipline of deciding the structural shape of a supply chain: how many facilities to operate and where, which customers or regions each should serve, where to hold inventory, and how product should flow from source to customer. These decisions set the fixed footprint within which all day-to-day planning operates, and they shape cost and service for years, which is why they are made using optimisation, scenario modelling, and simulation rather than judgement alone.
What is a digital twin in network design, and why does calibration matter?
A digital twin here is a model of your current network that reproduces how it behaves today in cost, flow, and service terms. Calibration is the discipline of tuning that model until it reproduces last year's real costs and service within tolerance before you trust it to evaluate future scenarios. It matters because every scenario builds on the baseline, so an uncalibrated baseline produces unreliable answers that carry the false authority of a precise model, which is more dangerous than an obviously rough estimate.
Why can't network and inventory decisions be made separately?
Because they are the same problem at different horizons. Where you hold inventory is both a network and an inventory decision, and changing the footprint changes the inventory the network must carry through the pooling effect, where consolidating stock reduces total safety stock and dispersing it increases stock. That consequence can be large enough to outweigh the transport and facility savings a network study optimises for, so a footprint chosen without modelling its inventory and ordering implications can look optimal on the model yet prove uneconomic in practice.
What is the role of Monte Carlo analysis in network design?
Monte Carlo analysis runs a network design across thousands of randomised scenarios, drawing uncertain inputs such as demand, costs, and lead times from probability distributions rather than fixed values, to reveal the full range of outcomes a design produces. It lets you choose a network for robustness, one that performs well across most plausible futures and protects you in adverse ones, rather than one tuned to a single forecast. Given how frequently major disruptions now occur, designing with uncertainty built in has become essential.
How should I choose a network design tool?
Choose it last, after you have settled the baseline, the uncertainty modelling, and the network-inventory integration, and select on criteria that matter: speed to a calibrated baseline, optimisation and simulation and risk in one place, the ability to model inventory and ordering policy alongside network structure, usability for the team who will own it, and the ability to re-run it as a living capability. The 2026 landscape includes Coupa Supply Chain Design and Planning, the cloud-native Optilogic Cosmic Frog, AIMMS, anyLogistix, and GAINS. For businesses whose network decisions are inseparable from ongoing planning and inventory, an integrated platform such as GAINS, which optimises network and inventory together, is the strongest fit.
Related reading: Supply Chain Planning: A Guide for Australia · Demand, Inventory & Replenishment: Competitive Advantage · How Advanced Planning Systems Transform Supply Chain Planning · S&OP That Actually Works in Australia