Should We Standardise This Globally?

The decision

Organisations operating across countries, business units or regions rarely remain consistent over time. Each part of the business adapts processes, technology and data practices to local needs. Over time, the resulting variation increases cost, complexity and difficulty in managing the enterprise as a whole.

Multiple systems perform similar functions. Reporting definitions differ. Processes vary between business units. Local teams maintain exceptions that headquarters struggles to understand.

Leadership proposes a global standard.

One platform. One process. One set of data definitions. One operating model.

The argument for consistency is compelling. But markets face different regulations, customers have different needs, and some local practices reflect genuine commercial requirements. Others persist because nobody has challenged them.

The executive question is not whether global consistency is desirable in principle.

It is what should be standardised globally, what should remain configurable locally, and what warrants an approved exception.

These are three distinct choices:

• Standardise: Establish a common enterprise approach where consistency improves value, control or visibility.
• Configure: Use a shared capability while allowing controlled differences to meet legitimate local requirements.
• Exception: Permit a distinct local approach when a credible business need justifies the additional cost, complexity or risk.

The right answer depends on the capability or process under consideration. A global security control might require consistency everywhere. A shared technology platform might support different local workflows. A customer-facing process might need more flexibility to reflect market conditions.

Why standardisation becomes an argument about control

Global programmes often frame standardisation as a contest between central consistency and local autonomy.

Headquarters wants fewer systems, common controls and lower operating costs. Local leaders want solutions that reflect their customers, regulations and operating conditions.

Both positions might have merit.

The problem begins when either side treats its preferred approach as the answer before testing the underlying business need.

Standardisation also redistributes authority. It influences who controls design, funding, prioritisation and exceptions. A technically common solution will not remain common unless decision rights are explicit and leaders agree on how competing business interests will be resolved.

Central teams might impose uniformity where local differences are legitimate. Local teams might defend established practices without demonstrating their value.

The result is often an unstable compromise. A global standard is approved, exceptions multiply, and the organisation ends up supporting the common solution alongside the local variations it was meant to replace.

A global standard creates value only when the organisation understands what must be consistent, why it matters and who is accountable for the decision.

What should be standardised?

Not every difference deserves to survive. Not every difference needs to disappear.

The level of consistency should reflect the business outcome and the nature of the capability.

Enterprise controls.

Security, risk and compliance requirements often need common minimum standards. Local obligations might require additional controls, but a local preference should not weaken essential enterprise safeguards.

Core data definitions.

Shared definitions improve enterprise reporting, integration and decision-making. Local attributes and reporting requirements might still be necessary, provided they do not undermine the common data foundation.

Shared technology capabilities.

Common platforms and reusable services reduce duplication and simplify support. The platform does not necessarily require identical workflows, configurations or customer interactions.

Repeatable internal processes.

Processes with similar purposes and operating conditions often benefit from a common design. Material differences in products, regulations or service models deserve separate consideration.

Customer-facing activities.

Consistency might improve quality and brand experience, but identical processes are not always appropriate across different markets. Local responsiveness should be assessed against the value of a common approach.

These distinctions matter because standardisation should be assessed by capability or process, not imposed indiscriminately across the entire operating model.

The objective is a coherent enterprise, not an organisation in which every activity looks identical.

When local variation is justified

Existing variation needs examination rather than automatic acceptance or rejection.

Five situations deserve different treatment.

Regulation and legal obligations.

A market might face binding requirements that differ from those elsewhere. The specific obligation should be understood and the local approach should address it.

Customer and market needs.

A difference might be justified where customer expectations, commercial practices or service requirements create measurable business value.

Material operating differences.

Business units might operate with different products, services or value chains. Forcing identical processes across genuinely different operating contexts might add complexity rather than remove it.

Technology and transition constraints.

Legacy dependencies, acquisition history or contractual commitments might make immediate convergence impractical. A temporary variation needs an accountable owner and a credible transition path.

Historical practice without demonstrated value.

Some differences survive because they have always existed. Familiarity, convenience or local preference alone do not establish a business case.

The important distinction is between a requirement the organisation needs to preserve, a difference that creates measurable value, a temporary constraint and a practice that has never been properly challenged.

Assess the value of convergence

Standardisation has costs as well as benefits.

A common platform might reduce support costs and improve control, but migration introduces expense, disruption and delivery risk. A common process might improve visibility, but forcing uniformity into a different operating context might damage customer experience or create workarounds.

The decision should account for both sides.

Leaders should consider the value of reducing duplication, improving data quality, strengthening controls and simplifying support. They should also consider migration and implementation costs, business disruption, local operating impact and the ongoing cost of maintaining approved variations.

The business case should compare the value of convergence with the cost of variation and the consequences of forcing uniformity.

Where the evidence is incomplete, state the uncertainty openly. An assumption about future savings is not a realised benefit, and a claim of local necessity is not proof of business value.

The aim is not to produce false precision. It is to make the trade-offs visible enough for an informed executive decision.

The executive test

Before approving a global standard, leadership should answer ten questions.

1. Business purpose: Which business outcome is the standardisation intended to improve?

2. Common value: What value comes from sharing the capability, process, platform or control across the enterprise?

3. Existing variation: Which differences exist today, and what explains them?

4. Local requirements: Which variations reflect legal, regulatory, customer or operating needs?

5. Cost of uniformity: What additional cost, risk or business friction would arise from forcing a common approach?

6. Cost of variation: What duplication, complexity, support burden or control weakness comes from retaining differences?

7. Configuration: Can a shared capability accommodate legitimate needs without creating separate solutions?

8. Decision rights: Who owns the global standard, and who has authority to approve a local exception?

9. Accountability: Who owns the business outcome and the ongoing consequences of the standard?

10. Review: What material change would justify revisiting the standard or an approved exception?

The value of these questions lies in the decision they expose. Leadership should be able to explain why a common approach is appropriate, where flexibility is needed and what evidence supports an exception.

Make exceptions deliberate

An exception should not become a permanent alternative simply because it was approved once.

A credible exception needs a documented rationale, a named owner, an assessment of business impact and a clear approval decision. It should also have a review date and, where the constraint is temporary, a transition or retirement plan.

Decision rights should be clear. The global process or capability owner is accountable for the enterprise standard. Local business owners explain market requirements and the consequences of variation. Appropriate governance authority resolves material deviations, while executive sponsors settle disputes where enterprise and local interests remain in conflict.

The level of governance should reflect the materiality of the decision. A minor configuration choice does not require the same scrutiny as a variation affecting enterprise risk, core data or a major technology platform.

Some differences will be necessary, some will be temporary, and others will exist because the organisation has not yet provided a viable common solution.

The aim is to prevent uncontrolled variation without making legitimate local needs impossible to accommodate.

The decision takeaway

Global standardisation should not be an exercise in making every part of the organisation look the same.

Standardise where consistency creates enterprise value. Allow configuration where requirements differ. Permit local variation when a credible business need justifies it.

The executive responsibility is to make those choices explicit, assign accountability and ensure the resulting model serves the business rather than the convenience of central control.