Supply chain network design: when to use it, what it needs, and why the baseline is most of the work

About Sachin Bajaj

Business process manager for supply chain network design at AkzoNobel, after fifteen years of network design and optimisation projects at Amazon, Accenture and AkzoNobel. Watch the webinar.

What supply chain network design is for

Every company has a footprint: plants, warehouses, suppliers, sometimes stores and a last-mile network. Supply chain network design is the discipline that decides what that footprint should be. “Whenever you have to take decisions with respect to changes in the footprint, relocation, consolidation, opening new stores, new warehouses, a new manufacturing facility, there needs to be some science behind the decision,” says Sachin Bajaj, who leads network design at AkzoNobel. “Network design is nothing but a science which helps the business take these decisions more accurately, through a data-driven approach.”

The word “strategic” gets attached to it, and the biggest studies are strategic: a merger or divestment, where the head of a business asks the team to check whether the synergies promised to shareholders are really there; or a new plant, where the questions are capacity, capabilities and which customers and warehouses it should serve, on a three-to-five-year horizon. But the same models answer tactical and operational questions. Tariffs are the live example: companies use a network model to see where sourcing from another geography or producing in a plant with a lower tariff exposure would offset the impact. Further down, the method sizes a fleet or chooses transport routes for companies without a transport management system.

It is an optimisation problem, and mostly a MILP

Network design and optimisation are not two things. “Network design is typically an optimisation problem,” Sachin says. The objective is service, cost, or both, and the model is almost always a mixed-integer linear programme: binary variables for the yes-or-no choices (keep this warehouse open, produce this product family here) and continuous variables for flows, costs and capacities. The exceptions are pure flow problems, such as removing triangular shipments and shipping directly to customers, where a plain linear programme is enough.

That has a practical consequence. The standard problems, cost minimisation and service-level improvement, come pre-built in network design software. Customisation starts when the objectives conflict: keep lead times where they are while bringing cost down, for instance. Multi-objective problems need modelling work of their own.

The data a model needs

Sachin's answer to “what inputs do you need” is long on purpose, because the list is what the project is. Master data first: customer locations, warehouse and plant locations, and supplier and supplier's-supplier locations if the study looks beyond the company's own walls. Then product attributes, down to the ones that change how a product moves; in paints, that means white or coloured, opaque or not, solvent-borne or water-borne. Then cost, which drives most decisions: transport costs between every pair of nodes, production cost per plant, and both production and warehousing cost split into fixed and variable components. Rent, overheads and electricity are fixed; labour moves with volume. If production cost is not available, it has to be derived, because comparing the cost of the same material in two plants is exactly the question the model will be asked.

None of this is the network design team's data. It belongs to finance, planning, logistics and commercial, so the project appoints one contact per function who supplies the data and, where it is incomplete, signs off the assumptions the team derives. Companies with a transport management system in place make this far easier; without one, “it's a matter of going through multiple spreadsheets”. Data preparation tools help when the model will be refreshed on a cadence. AkzoNobel used Alteryx for preparation and cleansing and now works in Databricks; for a one-off study, the effort of building a pipeline is not worth it. The dedicated network design tools also ship with data preparators that connect to ERP sources and transform the data inside the tool.

Why the baseline is 60–65% of the work

The number Sachin gives for data collection and baseline building is 60 to 65% of a project's effort and time. The baseline is the replica of today's supply chain in the tool, validated until it reproduces actual costs and flows. “That's mostly the slow aspect of the work. Once you have a baseline, the interesting piece of running the scenarios and comparing them starts.”

This is where network design and day-to-day planning meet, in both directions. The output of a study is consumed by the planning teams: consolidating locations leaves cycle stock roughly where it was but brings safety stock down, a one-off benefit, and the new topology has to reach the people planning demand, supply and capacity. The input often comes from planning too. A warehouse already running at 85–90% in a normal period, with a peak coming, is a network question. So is a product portfolio, customer profile or demand pattern that has drifted a long way from the one the network was built for.

Tools, and a free way to try one

The tool landscape has two families: planning suites with a network design module, and software whose core competency is network design. Sachin's view is that the best tools in the second group cover “99% of the network design problem” out of the box, with occasional workarounds for the rest. For anyone who wants to see one, he points to evaluation licences that let an individual create an account and build a small model, limited in products and customers but enough to learn the shape of the work. Smaller companies have other routes: licence a tool for the two or three months a study takes, use a solver directly if someone on the team knows operations research, or frame the basic model in Excel's solver. The business case for a smaller company is smaller too, since the tool and the data work cost what they cost.

His one wish for the tools is about data they do not have. Transport costs exist for the lanes a company already runs; the lanes it might run have to be simulated elsewhere and fed in. Having that estimation inside the tool would remove a step.

How a project runs, and where it gets stuck

The phases are the same every time: a project charter with the objectives, a soft kick-off with the stakeholders, a steering committee at milestones and a core team meeting weekly; then data collection and validation; the baseline; the scenario phase; and results, reports and close-out. After that, the recommendations go to the regions, who implement them. The network design team steps back but stays involved through a stage-gate process and a playbook of known pitfalls, acting as gatekeeper rather than implementer.

Two things stall projects. The first is data, especially in companies that grew by acquisition and run several ERP instances; getting the right data and getting it validated is where the time goes. The second is modelling the supply chain as if commercial did not exist. “Sometimes we fail to speak to our commercial colleagues,” Sachin says. “They have lead-time requirements and customer SLAs they have promised. Supply chain will say we don't need this location; commercial will have its own point of view.” His team now treats commercial constraints as inputs to scenario design, and judges scenarios on overall value rather than cost alone.

Did the savings land?

The answer to whether network studies deliver is a tracking discipline, not a feeling. Sachin's team separates the modelled savings, what the tool recommends in theory, from the implementable savings, what remains after the practically difficult parts are removed. The implementable number is aligned with the stakeholders, locked into the system as a target for the next twelve months, and tracked month by month with the finance partners until it shows in the P&L. “That's the way we ensure the complete feedback loop, that what we promised is actually landing in our financial records.”

Projects are chosen the same way. Twice a year the team meets the operations directors of each business, translates their priorities into candidate studies, and takes the high-impact ones first. Requests also come sideways, from procurement for a centralised-versus-regional sourcing study, or from finance.

Digital twins, AI and the skills for the job

Asked what a digital twin is beyond a buzzword, Sachin gives the network design answer: a model that is kept updated and used periodically to make decisions, as opposed to a one-off study. On AI, he sees tools where a scenario is described in plain English and a language model builds the model variant, but his team has not tested them and still works the traditional way; promising, not yet proven. For someone in planning who wants to move into network design, the role is “a mix of supply chain analytics and a business role”: understanding how supply chains operate, comfort with data and analytics tools, and the ability to turn data into actionable insight. Learning the tool itself is the easy part.

Your next steps

If a footprint question is on the table, write the charter before touching data: the objective, the stakeholders, the governance. Appoint a data contact in finance, planning, logistics and commercial, and plan for the baseline to take most of the time. Bring commercial into scenario design rather than defending results to them later. Decide up front whether this is a one-off study or a model you will refresh, because that decides the tooling. And separate modelled from implementable savings before anyone quotes a number.

Sachin's own advice is the sentence that runs through the whole session: think about the overall value, not only the cost. The model will find the cheapest network. Whether it is the right one depends on who was in the room when the scenarios were written.