Map before you mandate

Practice differed at every terminal, and nobody had written the differences down

An 8 to 10 week sprint, February 2026. A European logistics operator, around €1.5B revenue. Part 1 of 4 in Assembly or Acquisition. Part 2 is the total nobody had added up. Part 3 is the inventory that had to exist before anything could be outsourced. Part 4 is the diagnostic that tells the two problems apart.

The operator ran fleet maintenance and control across a network of terminals, and each terminal worked slightly differently. Management knew this. What they did not have was a written account of how the differences actually broke down.

That gap matters more than it sounds. Knowing that sites differ justifies a concern. Writing a standard needs more: where practice differs, by how much, and why. Only evidence gives you that.

The data already existed. Fleet information sat in different teams and different systems, recorded in formats that did not line up. So the same fault could recur at four terminals and look like four unrelated problems.

Missing data and mismatched data look alike and cost very differently. If the data is missing, you buy a system to collect it. If the data exists but every site records it its own way, no system fixes that. Somebody has to work out what each terminal means by the words they all use.

A blueprint takes days and has an owner. The evidence takes weeks and has none.

Most multi-site programmes start by drafting the standard. It is quick, one central team can do it, and it produces something to put in front of a steering committee.

It usually breaks at the second site. Sooner or later a standard written without evidence contradicts a local practice that exists for a good operational reason. A terminal might sequence its checks differently because of how its yard is laid out, and the new standard says otherwise. The people expected to follow it now have grounds to question everything else in it. From that point the document stops working as a standard and starts working as an opening position, with every clause argued one at a time.

So the map costs the most, and the map is the piece no one has time to build. The case record puts it plainly: central teams were accountable for fleet availability across many terminals, and with those teams focused on daily operations there was little time to step back, review current practices, and define clear improvements without disrupting the business.

The people who could build the map are the people whose absence would stop the network. In a business that is running, they never get released. That is why this gap stays open year after year.

Five processes, and one number we report as a potential rather than a result

The number worth questioning is the five. A network that genuinely differs site by site could justify fifty standardized processes, and nobody reads a fifty-process document twice. Cutting the observed variation down to five is where the analysis sits. Five is our judgment about what has to be the same everywhere, not a count of what already is.

The 15% is an opportunity rather than an achievement. The record names concrete levers to raise fleet availability and cut avoidable downtime. Turning those levers into 15% takes a rollout, and the rollout sat outside this engagement.

A network that could not trace a repeat fault can now hold every terminal to the same five processes

What that enables. Central teams can now point to a defined process instead of arguing each exception on its merits. A fault that shows up at three terminals reads as one cause rather than three complaints. And the efficiency case carries a number and a named list of levers, which is what a budget or headcount request needs to survive a finance review.

Hold back the blueprint, and keep the standard small

Write no target-state document in the first three weeks. The pressure to produce one is real, because a blueprint looks like progress and a map does not. But a blueprint built on assumption fails at the second site, and that failure never shows up in a budget line. You pay for it in the credibility of the programme, at the moment the programme most needs credibility.

Standardize only what has to be the same. Whatever the map shows, the standard should cover the smallest set of processes that genuinely need to match. Let local practice stay local. Every clause you standardize is a clause somebody has to enforce, review and defend for as long as the standard lasts, and enforcement capacity is every bit as scarce as the capacity that built the map.

Three boundaries we set on purpose, and would set again

Rollout. The 15% only becomes real through an implementation we did not run. We built the processes and clarified the roles. We did not watch the terminals adopt them, or check whether adoption held. We do not report numbers we have not seen.

Whether five is the right number. Five reflects the evidence available inside the engagement window. Another analyst reading the same interviews could defend four or six. The hard cases are terminals that keep a local exception for a sound reason that only surfaces later.

How long the map stays accurate. Terminals open and close, and systems get replaced. A map describes the network on the day you finish it. The standard outlives the evidence underneath it, and few organizations put a review date on a map. That is how a standard ends up being enforced against a network it no longer describes.

Clarity and direction that would have taken internal teams months to establish

That is how the Head of Operations described the outcome.

Read it carefully. He does not say his team could not have done the work. He says it would have taken them far longer. That is the honest trade in most of these programmes, and it holds up better stated plainly than dressed up as expertise the client lacked.

Next, part 2. A €10B producer was carrying €5m a year in cost from fragmented supplier quality processes across its mills. Three functions each saw a piece of it. None of them saw the total. Part 2 explains why that is structural rather than a lapse in attention.

The series in one paragraph. Four engagements, one request, two problems. Fleet maintenance, supplier quality and finance services were assembly problems. The evidence already existed, spread across sites in words that did not match, and the client was buying protected time and a method to reconcile it. The machinery catalogue was acquisition. Three of the four things it needed sat with competitors and customers, and no amount of internal time would have produced them. The two questions in part 4 tell the problems apart before you scope anything.

Every figure here comes from one case record, reproduced with its own qualification

The record. All figures come from the SprintlyWorks case record for Standardizing Fleet Maintenance and Control Operations, February 2026: 5 standardized processes with clarified roles and governance; a 15% fleet efficiency uplift stated as a potential against identified levers; more than 30 stakeholder interviews.

What we leave out. We describe the client rather than naming it. We leave out terminal-level operating detail on purpose, because it is the part of the engagement most useful to a competitor and the transferable part is the method that produced the map. We do not claim that fleet efficiency improved by 15%.

About this work. SprintlyWorks runs 8 to 10 week sprints for industrial companies that need a written account of how their sites work today, a single harmonized process, or a service catalogue, and cannot release the people who would build it. We work at the sites, reconcile what we find into one structure, and hand over something the client can act on.

Running a standardization programme, or about to scope one? Answer the two questions in part 4 and send us what you get. If it is assembly work, we will tell you what an internal team would need. If it is acquisition work, we will tell you what evidence you are missing.