Scaling tech across sites: the standardisation paradox

Posted in Blog, Latest News on September 23rd, 2026

Key takeaways

Selecting the right technology to use is usually the easy part. Getting multiple sites to adopt a common way of working while keeping enough local autonomy to run well is where the challenge begins.
Sites rarely run different processes, more often they are describing the exact same process in different ways, and that’s a vocabulary gap, not an integration problem.
Greenfield sites are not easier to standardise than brownfield sites. Brownfield can expose legacy constraints while greenfield sites expose alignment gaps.
The question to answer before you scale is not “how do we standardise everything?” It’s “what must we standardise to protect the business case, and what can stay flexible to protect operational performance?”
Governance is not about having more meetings, it’s giving clarity about who decides.

Why do multi-site rollouts stall after a successful pilot?

You can design the right technology solution. You can nail the requirements, value engineer it ruthlessly, and run a flawless proof of value. And then the real project begins: rolling out across multiple sites, where every plant director believes their operation is unique.

The mythology around “global rollouts” says that selecting the right technology is the key challenge. In practice, choosing the technology is often the easy part. The greater challenge is convincing multiple sites to adopt a common way of working while preserving enough local autonomy for each operation to remain effective.

The pattern is consistent. Corporate teams push for standardisation to maximise value and reduce complexity. Local sites push for flexibility to reflect their operational realities. Both positions are valid. The conflict only arises when organisations assume they have to choose one or the other.

Should the first site be a template or a laboratory?

The common approach is to try to solve global standardisation before value has been proven. That produces workshops, discussions and documents, with very little tangible outcome.

The better approach is to treat the first site as a laboratory. Not a pilot, and not yet a template. A laboratory exists to prove five things:

the technology works
the business case is real
the process can be digitised
operators will actually use it
management trusts the data

Only when those five are answered should the conversation turn to scale. Start small. Think enterprise.

Fazer took this route. They resisted the pull towards immediate global rollout and validated the MES platform in a controlled environment at their Vantaa site first, building confidence before scaling investment and proving operational value before discussing enterprise value. Structured discovery produced clear requirements, clear success criteria and controlled scope, which in turn produced better stakeholder alignment and fewer surprises when delivery moved to their Lahti location.

The honest part: discovery took longer than expected. Not because the process was complicated, but because sites had different interpretations of the same process.

Why do sites disagree when they are running the same process?

Because they are not describing it the same way.

Different definitions of OEE. Different interpretations of what counts as downtime. Different production reporting practices. On the surface these look like integration problems. They are not. Integration is rarely the blocker. Vocabulary is.

And a vocabulary gap is really a business architecture gap. If two plants cannot agree what a stop is, no amount of middleware will make their numbers comparable.

Is a greenfield site easier to standardise than a brownfield site?

Conventional thinking says yes. Brownfield sites carry legacy systems, established processes and entrenched ways of working. Greenfield sites offer a clean slate, so standardisation should be simpler.

In reality, the challenge does not disappear. It moves. Instead of replacing existing systems, you are aligning stakeholder understanding, and that turns out to be just as difficult.

Brownfield sites expose legacy constraints. Greenfield sites expose alignment gaps. Both reveal the same underlying issue: no agreement on the business architecture.

In our experience the greenfield site is where enterprise standards get tested hardest, because it forces the organisation to answer questions it has never previously agreed at enterprise level.

What must be standardised, and what must stay local?

This is the paradox at the centre of every multi-site programme, and it has a workable answer.

Standardise what protects the business case. The platform, the data architecture, and the core process logic. Without these, comparison between sites becomes impossible, analytics lose their value, support costs escalate and the ROI quietly disappears.

Leave local what protects operational performance:

Deployment pace. Every site starts from a different maturity level, so readiness varies dramatically.
Change management. Different cultures need different approaches, and different leadership teams need different messaging.
Local priorities. One site may need OEE first, another traceability, another scheduling.

Training. Different operator profiles, shift structures and workforce characteristics.

The learning from Fazer so far is that standardisation succeeds where it visibly strengthens operations, and meets resistance where it feels like control. People defend what protects them. They resist what controls them.

How do you govern the difference?

The most successful global programmes do not create more governance. They create clearer governance. Clear escalation routes achieve more than additional meetings.

Without a defined escalation path, every issue gets renegotiated and every decision becomes political. With one, decisions happen faster, expectations are clear and accountability improves.

A simple way to make this explicit is a RAG decision rights model:

Rad decision model

Zone	Label	Who decides	Contents
Red	Defend the core	Corporate	MES platform, data model, KPI definitions (OEE, downtime), cyber security standards
Amber	Negotiate the middle	Joint	Deployment sequence, functional prioritisation, reporting enhancements, process harmonisation
Green	Flex the edges	Site	Training plans, change champions, adoption strategy, local CI initiatives

The practical value is that a disagreement stops being an argument and becomes a classification exercise: which zone does this sit in, and therefore who decides?

What goes wrong?

Three failure modes come up repeatedly.

Customisation addiction. It always starts with “we only need one small site-specific change”. Enough of those and the enterprise programme is gone: rework, lost time, damaged morale, and eroded board confidence. We saw this beginning at Fazer Vantaa site and advised pausing customisations for later review rather than absorbing them into scope.

Governance by committee. Multiple reviews, no decisions. The organisation feels collaborative while the programme stops moving. Consult widely, decide quickly.

The human problem, which is discussed least. Plant directors have often built successful operations through exactly the local optimisation you are now asking them to give up. When that is not acknowledged, it drives more resistance than any technical limitation ever will. Resistance is frequently not opposition. It is closer to grief. People are being asked to hand over systems they built and processes they own. Treat that as a technical problem and the programme will fail.

Where does this leave the business case?

For the enterprise, a single platform across multiple sites de-risks the investment story.

For operations, the formula is not “follow the template”. It is “protect the standard, improve the operation”. Sites that adopt the core standards and customise smartly outperform both the rigid and the rebellious.

For the commercial forecast, phased site-by-site measurement means the rollout no longer depends on every site delivering identical results. Benefits get measured locally, maturity differences are understood, forecasts reflect operational reality, and the overall business case stays intact. That gives executives confidence and operators realism at the same time.

Where should you start?

Define your core before you define your rollout. Write down what must be standard to protect the business case. Keep the list short and defensible.
Run your first site as a laboratory. Prove the technology, the business case, the process, operator adoption and management trust in the data.
Fix the vocabulary before the integration. Agree OEE, downtime and production reporting definitions at enterprise level. This is business architecture work, not IT work.
Classify decision rights using RAG. Publish it. Make every escalation start with “which zone is this?”
Plan for grief, not just training. Acknowledge what local teams built before you ask them to standardise it.

The playbook most transformations are missing

You need to be able to say, with confidence: “We are standardising on this because the business case depends on it. You have flexibility here because operational excellence depends on your expertise. And here is how we will make that distinction together.”

That credibility, having genuinely thought through what is non-negotiable versus what is negotiable, is what lets you defend a rollout to corporate leadership and local plant teams at the same time.

Identify your core. Identify your edges. Govern them differently.

Frequently asked questions

What should be standardised in a multi-site MES rollout?

Standardise what protects the business case: the platform itself, the data architecture, the core process logic and KPI definitions such as OEE and downtime. Without these, cross-site comparison is impossible, analytics lose value and support costs escalate. Everything else is a candidate for local ownership.

What should sites be allowed to control?

Deployment pace, change management approach, local functional priorities and training. These reflect differences in maturity, culture, workforce and shift structure. Standardising them rarely protects the business case and usually generates resistance, because sites experience it as control rather than support.

Why do multi-site technology rollouts fail?

Most fail on governance rather than technology: unclear decision rights, no escalation path, and accumulated site-specific customisation. A successful proof of value at one site does not transfer automatically, because the second site brings different definitions, different maturity and different leadership.

Are greenfield sites easier to standardise than brownfield sites?

No. Brownfield sites expose legacy constraints. Greenfield sites expose alignment gaps, because there is no existing practice to fall back on and the organisation must finally agree standards it has never formally defined. Both reveal the same issue: a lack of agreed business architecture.

How do you resolve standardisation disputes between corporate and site teams?

Classify the decision before debating it. A RAG model assigns each item to corporate ownership (red), joint governance (amber) or site ownership (green). Disputes then become a classification exercise with a defined escalation route, rather than a repeated negotiation.