Deloitte found that 66% of retail executives surveyed plan to restructure their supply chains through onshoring, nearshoring, and supplier diversification if input costs rise, with 59% anticipating positive return on investment from supply chain AI initiatives within 12 months.
Restructuring on that scale is optimisation under a different name, carried out under time pressure. What follows is what supply chain optimisation is for, the sequence that produces results, and the failure mode that consumes most programmes.
What supply chain optimisation is
Supply chain optimisation is the deliberate adjustment of how goods, information, and decisions move through a network in order to improve cost, service, or resilience without degrading the others.
The definition contains the difficulty. Three objectives, and improving any one of them in isolation degrades at least one of the others. Cutting inventory raises stockout risk. Raising service raises transport cost. Building resilience adds buffer that inflates working capital.
MIXMOVE frames optimisation as deciding which trade-off the business intends to make rather than pretending one is available for free. A programme that has not named its trade-off has not started.
Why optimisation became a discipline
For most of industrial history, supply chains were optimised implicitly. Networks were small enough for experienced people to hold in their heads and stable enough that last year’s answer remained roughly correct.
Scale and volatility removed both conditions. Networks grew past the point where anyone could see the whole, and demand stopped repeating itself reliably enough for experience to substitute for analysis.
Why programmes are being reopened now
Margin compression has removed the tolerance for carried inefficiency, which is why cost pressure now produces structural change rather than absorption.
Supply base restructuring introduces new lanes, new suppliers, and new variability into networks that had already removed their buffers.
Emissions became a reported financial line. Under CSRD, transport emissions sit inside statutory disclosure, and under ETS2 they carry a direct cost. A network decision now produces a figure a finance function must defend, which brings optimisation onto the board agenda rather than the operations agenda.
Deloitte found that 30% of retailers surveyed use AI for supply chain visibility, expected to reach 41% within a year.
The local optimum problem
This is where most optimisation programmes lose their value, and it deserves stating plainly.
Every function in a supply chain can improve its own measured performance while making the network worse. Procurement wins better unit prices by ordering larger quantities, which fills the warehouse. The warehouse improves storage utilisation by consolidating putaway, which slows despatch. Transport improves cost per mile by waiting for fuller loads, which extends lead time. Each function reports an improvement. Total cost rises.
The reason is structural. Functions own their internal performance and nobody owns the interfaces between them. That is also where McKinsey locates the waste, finding that blind handoffs between shippers, dispatchers, third-party logistics providers, and carriers account for between 6% and 13% of carrier revenue, with dwell time named as a leading driver.
Optimisation that targets functions produces local optima. Optimisation that targets interfaces produces network results.
The five objectives worth pursuing
Reduce touches per unit. Every physical handling step is cost, time, and error risk. Counting them is the fastest diagnostic available in any network.
Raise utilisation per movement. Measured per leg rather than averaged, because averages conceal exactly the legs where the waste sits.
Shorten the decision cycle. The interval between something changing and the network responding. Long cycles force buffers to cover the gap.
Remove reconciliation. Administrative effort spent making two records agree indicates the underlying event was never captured accurately. This work is pure overhead.
Make the trade-off visible. Where cost, service, and resilience are reported together, decisions get made deliberately. Where they are reported separately, each function optimises its own and the trade-off happens by accident.
The sequence that works
Establish what the network actually does. Actual flows at item level over a full demand cycle. Most programmes optimise against the plan and are surprised by the result.
Name the trade-off. Decide explicitly which of cost, service, and resilience is being prioritised and what is being given up.
Fix the interfaces before the functions. Handoffs are cheaper to change than facilities and produce results in weeks rather than years.
Exhaust orchestration before capital. A congested hub is frequently sequence-constrained rather than space-constrained. Establish which before committing to property.
Measure against the original baseline. Programmes that redefine the baseline mid-course cannot demonstrate whether they worked.
Three failure modes to design against
Optimising to a plan rather than to reality. The most common failure. It produces a network tuned for demand that does not arrive.
Cutting the buffer without replacing what it did. Buffers absorb the gap between plan and reality. Remove one without improving information and the gap converts directly into service failure.
Treating optimisation as a project. Networks drift continuously. A programme that concludes leaves an organisation optimised for conditions that have already changed.
What the evidence shows
Deloitte reports that 66% of retail executives surveyed plan to restructure their supply chains if input costs rise, with 30% using AI for supply chain visibility rising to an expected 41% within a year, and 59% anticipating positive return on investment within 12 months.
McKinsey attributes between 6% and 13% of carrier revenue to waste at handover points, with dwell time identified as a primary driver.
Across MIXMOVE deployments, hub operations have recorded up to 130% higher warehouse hub throughput, up to 80% fewer errors, up to 50% less warehouse space, and up to 58% labour cost savings. Dwell time reductions of 40%, fill rate improvements of 10% to 20%, and up to 15% more billable output have been recorded. The platform is in use across 35+ distribution companies in 20+ countries.
At 3M, a decade of collaboration produced a 35% reduction in transport costs, a 50% reduction in CO₂ emissions, and a 90% truck fill rate.
“By using the MIXMOVE software, 3M managed to reduce transport costs by 35% and CO₂ emissions by 50%.”
— Patrick Van De Vyver, Former Head of EMEA Logistics Operations, 3M
How MIXMOVE optimises the interface
MIXMOVE HUB OS targets the layer where local optimisation fails. Inbound freight is identified at item level on arrival and matched against live outbound commitments, so the decision at the interface is made against network state rather than against the priorities of whichever function owns the next step.
Because the decision happens while freight is still on the dock, the trade-off is made deliberately and in the open. A consignment held for consolidation is a visible choice with a known service consequence rather than an accident of departmental targets.
Recorded throughput gains of up to 130% indicate how much capacity sits inside existing buildings, which is why orchestration is worth exhausting before capital is committed.
MIXMOVE HUB OS operates alongside an existing TMS, WMS, or ERP as an orchestration layer, or as a standalone platform.
MIXMOVE DI provides the measurement layer. Touches, utilisation, dwell, and service performance are reported from what physically happened, with Scope 3 transport reporting structured to ISO 14083 methodology, so cost, service, and emissions can be weighed against each other rather than optimised separately.
Functions optimise themselves and report success. The network pays for the gaps between them. Operations that fix the interface stop funding improvements that make things worse.
Read the MIXMOVE DI overview to see how cost, service, and emissions are measured from the same execution record.
Frequently asked questions
What is the purpose of supply chain optimisation?
To improve cost, service, or resilience without degrading the others. Because the three trade off against each other, the purpose is to make the trade-off deliberately rather than to pursue all three at once.
What are the main objectives of supply chain optimisation?
Reducing touches per unit, raising utilisation per movement, shortening the decision cycle, removing reconciliation effort, and making the cost, service, and resilience trade-off visible in one place.
Where should a supply chain optimisation programme start?
With what the network actually does, measured at item level over a full demand cycle, rather than with what the plan says it does. Interfaces between functions should then be addressed before the functions themselves.
Why do supply chain optimisation programmes fail?
Most commonly because each function optimises its own measured performance while the network gets worse. The cost accumulates at the interfaces between functions, which no function owns.
