Multi-Site Maintenance Standardisation: How to Do It Without Losing Local Knowledge
When five sites do the same job differently, some of that is drift and some of it is knowledge. From head office they look identical. Here is how to tell them apart before you standardise.
Somebody at head office looks across five plants. All five do maintenance differently. Different codes, different forms, different ways of counting the same thing. It looks like waste, so a project starts.
Eighteen months later there is a thick common procedure, three sites are quietly ignoring it, and the numbers still do not compare. If you have lived through one of these, you know the pattern.
The idea is sound. Comparing sites is genuinely valuable. The trouble is almost always in what gets standardised.
Two kinds of difference
When sites do something differently, there are only two possible reasons, and they need opposite treatment.
The first is drift. Nobody ever agreed a common way, so five sites invented five. There is no reason behind the difference other than history. This kind of difference costs you and gives nothing back.
The second is a fix. A site changed something because their kit, their weather or their product needed it. The pump check is monthly instead of quarterly because that plant sits near the coast and everything rusts faster. That difference is knowledge, not mess.
From a spreadsheet in head office, the two look identical. That is the whole problem, and it is why so many of these projects go wrong.
Standardise the language, not the work
Here is the distinction that makes the rest easy.
Standardise the things that let sites talk to each other. Failure codes. Asset naming. What a work order must contain when it closes. How criticality is decided. How each metric is calculated.
Leave local the things that depend on the actual equipment and conditions. The order of steps on a specific machine. Inspection frequency. Crew structure. Which spares are worth holding on that site.
Get the first list right and you can compare sites properly. That was the point. Force the second list and you lose the local judgement that keeps those plants running.
Ask why before you change anything
Before standardising any practice, go and ask the site why they do it their way. Not as a challenge, as a genuine question.
You will get three kinds of answer. Sometimes it is a good reason you did not know about. The standard now needs to allow for it. Sometimes it is history, and the person doing it will tell you plainly that nobody ever said otherwise. Occasionally it is a better method than the one you were about to impose, and the right move is to spread it rather than replace it.
This conversation is not a delay. It is the difference between a standard people follow and one they work around.
Start with the numbers, not the procedures
If you are only going to do one thing, make it this.
Agree how each metric is calculated across every site, in writing, with worked examples. Get everyone counting downtime the same way, deciding what a planned job is the same way, using the same failure codes.
Almost nobody starts here. It is less visible than a smart new procedure. But without it, every comparison between sites means nothing, and the whole job was wasted. One site looks better than another, and nobody can say whether that is real or just a different way of counting.
Agreeing the numbers also causes far less friction than agreeing procedures. You are not telling anyone how to do their job. You are agreeing what the words mean.
Let the best site write it
The fastest way to lose a room is to arrive with a procedure written by people who have not done the work.
Find the site that does this thing well, and let them write the first version. Then have the other sites mark it up. What arrives is usually better than anything head office would have drafted, and more importantly it belongs to somebody.
This also settles the politics quietly. It is much easier to take a method from another plant that clearly does it well than from an office that does not.
Build in a way to say no
Every standard needs an honest way to opt out. Without one, sites still opt out. They just do it quietly, and you never get to see it.
Make it simple. A site can deviate if they say what they are doing instead and why. One paragraph, reviewed once a year.
Two things come from this. Sites stop feeling the standard is being done to them. And that list of opt outs becomes the most useful page you have. If four sites opt out of the same rule, the rule is wrong.
Expect it to take longer than the plan says
These programmes are usually scheduled as if the work were writing documents. The writing is the fast part.
The slow part is the visits and the conversations. It is working out which differences are knowledge and which are just drift. You cannot rush that, and skipping it is what produces a standard nobody follows.
Plan for a small number of things done properly across all sites, rather than everything done partially. Three standards that every plant genuinely uses beat thirty that live in a folder.
What good looks like afterwards
You will know it worked when two things are true.
Someone can put five sites' numbers side by side and argue about performance rather than about definitions. And a technician moving between plants finds the paperwork familiar, while the local way of handling that particular machine is still intact.
That is the goal. Not five identical plants, which is neither possible nor desirable, but five plants that can learn from each other because they finally speak the same language.
