Scaling ERP transformations beyond go-live

Name: Implement Consulting Group
Price range: $

Why standardisation must balance global templates with local business reality

Published

5 June 2026

Most ERP transformations begin with a simple ambition: one system, one way of working, and a single global template. But real scalability is not achieved at go-live. It is achieved afterwards, when the organisation can reuse that template to roll out faster, with fewer redesign debates and clearer trade-offs between standardisation and local business reality.

From system replacement to operating model

Organisations that grow through acquisitions often inherit a fragmented landscape: multiple ERP systems, different local processes, and competing interpretations of what ‘good’ looks like.

The ERP transformation programme Implement Consulting Group has been part of over the past two and a half years began with a familiar ambition: to consolidate the system landscape and establish a common operating model across business areas. But at this scale, replacing technology is only one part of the challenge. The harder task is creating a platform for transparency, control, and growth.

In short, treating ERP as an IT delivery exercise is misleading. It is, fundamentally, a business design challenge.

Standardisation is a design decision

Standardisation is attractive because it promises lower complexity, better data, simpler support, and faster deployment. But it is not inherently valuable everywhere. Over-standardise and you risk losing business fit. Under-standardise and you lose scale.

The real work is to make these trade-offs explicit. Where does a global template create value through consistency, transparency, and control? And where does local variation protect revenue, margin, or customer experience?

These decisions need to be made early, before process preferences quietly harden into system design choices.

Value sits at the edges of the system

In many transformations, the most difficult questions do not sit inside the clean core process. They emerge at the edges of the business, where the organisation interacts with customers, suppliers, partners, and local markets. This is where value is created and exchanged.

Change how sales agreements are structured, and you can influence revenue. Change purchasing models or supplier terms, and you can influence cost, availability, or margin. These are not simply process decisions. They are decisions about business value.

The real question is not “should we standardise this?”, but “what value do we gain from standardisation – and what value do we risk losing?”

Test the template under complexity

A solution that works once is not yet a template. A template is only proven when it works again in a different context, under real operational pressure.

This is why “start small” is often misunderstood. Small does not mean simple. In fact, the early deployments should be deliberately complex. Not the easiest site or the cleanest use case, but a tightly defined scope that is difficult enough to test whether the template actually holds.

This is what builds credibility. Once the organisation has seen the template perform under pressure, later rollouts can focus on fit-gap decisions rather than redesign. That shift is significant – both in governance and in mindset.

In practice

Proving the template before scaling

In a recent ERP transformation for an international food and consumer goods company, the programme deliberately started with a clearly defined but operationally complex scope.

The objective was not simply to achieve a successful go-live. It was to test whether the future template could handle real business complexity across multiple business models and their underlying processes.

Once the template had been proven in this context, subsequent rollouts started from a different position entirely. The conversation shifted from “will this work here?” to “what are the real gaps we need to manage locally?”

That shift created both speed and credibility.

Deployment speed comes from discipline

Once the template is proven, the programme changes character. The focus shifts from implementation to deployment. This requires discipline: prioritising fit-gap over customisation, changing ways of working before changing the system, protecting the integrity of the template where possible, and assessing deviations based on business value.

It also requires careful sequencing. In one rollout, an external logistics partner changed systems at the same time as the ERP deployment. On paper, this looked manageable. In practice, it created significant change load across both organisations.

The lesson is simple: do not only manage your own ERP transformation. Manage the transformation load across the ecosystem.

Success is when the question changes

ERP programmes are often measured by time, budget, and scope. Those dimensions matter, but they are not enough. The real signal of success is when the question changes.

After a first country rollout covering production and distribution, the next rollout was able to validate the same template with minimal friction in a new site. Core flows held, and the business could operate in the test environment almost immediately.

At that point, the conversation shifted from “does this solution work?” to “how fast can we scale it?” That is the moment ERP stops being a programme and becomes part of how the organisation operates.