Everyone knew the terminals were different. Nobody could say how.

Everyone knew the terminals were different. Nobody could say how.

An 8 to 10 week sprint. A €1.5B logistics company. Part one of three on multi-site standardisation. This one is about the map. Part two is about the bill. Part three is about the variation that is not in your process at all.

Fleet maintenance and control practices differed across terminals. That much everybody knew, and nobody was surprised by it. Local teams kept operations running, which is the part worth holding onto, because it is also the reason the variation survived.

What did not exist was a shared view of how maintenance actually worked across the network. Not an opinion about how it worked. A fact-based view.

The page is specific about why. Information on fleet issues existed across teams and systems, but it was scattered and hard to compare, and that made it difficult to spot recurring problems, understand root causes, and see where processes were breaking down.

Read that carefully, because it is not a data problem. The data existed. It was not comparable, which is a different fault and a much more expensive one, because the fix is not a system.

A blueprint is a week of work. Finding out what actually happens is a month.

The temptation in a multi-site business is always to write the standard first. It is fast, it can be done at the centre, and it produces something you can show a board.

It also gets ignored at the second site, and the reason is not politics. It is that a standard written without evidence will contradict something that terminal does for a good local reason, and the moment it does, the whole document loses authority. Once one clause is obviously wrong, every clause is negotiable.

So the expensive half is the map, and the map is the half nobody has capacity for. The page puts it plainly: central teams were responsible for fleet availability across many terminals, and with teams focused on daily operations there was little time to step back, review current practices, and define clear improvements without disrupting the business.

That last clause is the one that matters. Without disrupting the business. The people who could do the mapping are the people whose absence would disrupt the business, and a network that is running is a network nobody will take people out of.

Five processes and one qualified percentage

The five is the deliverable and the fifteen per cent is the prize, and the page is careful to say the prize is a potential rather than a banked improvement. Concrete levers were identified to improve fleet availability and reduce avoidable downtime across terminals. Whether any of it arrives depends on the rollout, which is covered below.

The number worth arguing about is the five. A network of terminals with genuinely divergent practice could justify fifty processes, and a document of fifty processes is a document nobody reads twice. Getting from the real variation to five is the analytical work, and it is a decision about what has to be common rather than a discovery about what is.

The interviews are three weeks. The reconciliation is the rest.

Thirty plus interviews across a terminal network is roughly three working weeks once travel, scheduling and writing up are counted, and that is the visible half.

The invisible half is reconciliation. Thirty accounts of how maintenance works produce thirty vocabularies, and the same word means different things at different terminals. Before anything can be compared, the accounts have to be mapped onto one structure, and that is slower than collecting them.

The client’s Head of Operations put the trade in their own words, and it is a better sentence than anything we would write: the sprint provided clarity and direction that would have taken their internal teams months to establish.

Note what that sentence concedes and what it does not. It does not say their teams could not have done it. It says it would have taken months. That is the whole argument, said by the person who was in a position to know.

Do not write the blueprint first, and do not let anyone else either

If you are standing at the front of a multi-site harmonisation, the single most useful thing you can do is refuse to produce a target-state document in the first three weeks.

The pressure to produce one is real. A blueprint is visible progress and a map is not. But a blueprint built on assumption fails at the second site, and the failure is expensive in a way that does not show up as a cost: it burns the credibility you need for the rollout, and you only get one of those.

The second recommendation is about size. Whatever the map tells you, the standard should be the smallest set of things that genuinely have to be common. Everything that can stay local should stay local, because every clause you standardise is a clause somebody has to enforce forever.

Three things, and the first is the fifteen per cent

Whether the 15% arrives. It is a potential identified against concrete levers, and it becomes real through a rollout this sprint deliberately did not run. We built the processes and clarified the roles. Whether the terminals adopted them, and whether they still use them a year on, we did not observe.

Whether five was the right number. Five is a judgement about what must be common, made with the evidence available in that window. A different and defensible reading of the same interviews would have produced six, or four, and the boundary cases are the ones where a terminal has a good local reason that only becomes visible later.

Whether the map stays true. A network changes. Terminals open, systems get replaced, and a map of current state is accurate on the day it is finished. The standard survives that. The evidence underneath it does not, and nobody has ever put a review date on a map.

Where every figure comes from

From the published case study page, read on the live site this morning. The €1.5B logistics company descriptor, February 2026, the 8 to 10 week sprint, the 30+ stakeholder interviews, the 5 standardized processes delivered with clarified roles and governance, and the 15% fleet efficiency uplift stated as a potential with concrete levers identified. The statement that fleet maintenance and control practices differed across terminals while local teams kept operations running, and that there was no shared view of how maintenance actually worked across the network. The statement that information on fleet issues existed across teams and systems but was scattered and hard to compare. The statement that central teams were responsible for fleet availability across many terminals and had little time to step back without disrupting the business. The three objectives set for the sprint. The client’s Head of Operations described the outcome as clarity and direction that would have taken their internal teams months to establish.

Deliberately not used. Which terminals diverged and how. That is the client’s operating detail and the most directly useful thing in the engagement to anyone competing with them. Every argument here is about the method that produced the map, which is the part that transfers.

Not claimed anywhere. That fleet efficiency improved by 15%. The page says potential and so do we.