Every blueprint choice is a business choice first

ERP reaches far beyond finance, and the same authorship question appears across the enterprise.

Operations. Which services belong at group level, in a shared-services center, or inside the businesses? The system can route work to any of them, but it cannot determine which model creates the right accountability and service economics.

People and payroll. Which employment policies should be common, and where do country requirements or labor-market practices justify differences? Technology can accommodate multiple rules, but it should not decide the policy boundary.

Procurement and finance authority. Which decisions sit with the group and which belong with legal entities or operating businesses? An approval workflow merely codifies the answer.

Regulation and statutory reporting. Regional groups will encounter legitimate differences. The UAE's Electronic Invoicing System begins its pilot on 1 July 2026, with mandatory implementation for businesses above the relevant revenue threshold from 1 January 2027. Saudi Arabia's Fatoora program operates through a different integration regime, phasing taxpayers into platform integration by revenue band rather than by a single national date. [1]

Data ownership. Should a customer, supplier, or product be mastered once across the enterprise? If so, who has the authority to create or change the record, and who is accountable when it is wrong?

The e-invoicing example establishes only one point: some process variation has a statutory reason. The broader lesson is that every dimension needs an intentional operating choice before configuration begins.

‍

Fit-to-standard cannot author the operating model

Much of the difficulty in a blueprint debate comes from one word doing three jobs. When a group says it wants to standardize, it can mean any of three things, and the three carry different costs and different limits.

• Policy standardization asks which rules should be common. A single approval threshold, one employment principle, one credit policy. This is the level at which regulation and legal form bite hardest, and the level a group has least freedom to vary once it has chosen.
• Process standardization asks how the work should be performed. Two entities can operate under one common policy and still execute it differently, because volume, labor market, customer expectation, or local infrastructure differ. Insisting on identical process where only the policy needs to be common is the most frequent source of unnecessary rigidity in ERP design.
• Technology standardization asks how the system should implement it. One workflow can serve several processes. Conversely, one process may need different configuration in two jurisdictions because statutory reporting differs, as e-invoicing illustrates.

These come apart in both directions. A group may need one policy and permit several processes. It may equally use one system workflow while the underlying legal policy differs by country. Deciding which of the three is actually in question usually resolves a blueprint argument faster than debating the configuration.

Reducing unnecessary customization is sound technology discipline. The problem starts when fit-to-standard is used to answer questions the enterprise itself has not settled. Software can provide a default, and an implementation partner can explain common design patterns and their implications. Neither can determine the right distribution of authority, service ownership, or control for this particular business.

Fit-to-standard should test variation, not replace business authorship. A local process should survive because its regulatory, customer, or economic logic is clear. A group standard should exist because leadership can explain what consistency creates: stronger control, lower cost, better data, greater scale, or a simpler customer and employee experience. History alone is insufficient justification for local variation, just as system capability alone is insufficient justification for group uniformity.

The Decision-to-Configuration Chain

The discipline we apply on ERP programs is to trace every material configuration backwards to intent, across each dimension the system touches. We call the map the Decision-to-Configuration Chain.

The failure mode is the chain running in reverse. A workshop encounters an unresolved issue and selects a technically workable option; the option shapes the process; repetition turns the process into accepted policy. After enough such decisions, the ERP contains an operating model no executive team explicitly designed.

The system has become the author by default.

Exceptions need authors too

A strong global template should permit legitimate variation without becoming a collection of local preferences, and that requires a burden of proof on both sides. A business requesting an exception should explain the regulatory, customer, or economic reason that makes the difference necessary. The group proposing uniformity should explain the enterprise benefit created by the standard.

This avoids two expensive outcomes: fragmentation reproduced inside a new platform, and excessive uniformity pushed back into spreadsheets, offline approvals, and manual workarounds. It also makes exceptions reviewable, because a difference that was necessary during implementation may cease to be necessary later.

Keep a register of what has not been decided

Unresolved operating-model questions accumulate during design faster than program governance usually registers, and they do not announce themselves. They surface as a workshop that runs long, a design document with a bracketed placeholder, or a decision recorded as agreed by a process lead who had no authority to agree it.

The practical counter is to track them as openly as the program tracks risks and defects. Four columns are enough. The question, stated as a business choice rather than a system option. The accountable business owner, named as a person. The consequence of no decision, meaning what the project will do by default if nobody decides. And the latest decision date, after which changing the configuration becomes expensive.

The third and fourth columns are the ones that change behavior. Naming the default makes explicit that a non-decision is itself a decision, taken by the program on leadership's behalf. Naming the date converts an open question into something with a cost attached, which is the only form in which these questions tend to reach an executive agenda.

A group standard that is doing real work will make at least one business unit worse off in something it currently values. If no unit can name what the standard costs it, the standard is probably describing what everyone already did.

‍

Settle five decisions before the workshop settles them

Before a consequential process enters blueprinting, leadership should answer five questions.

1. What must be common? Identify where common rules, processes, or data create enterprise value.
2. What may legitimately differ? Separate law, customer need, and business-model requirements from inherited practice.
3. Who owns the outcome? Name the executive accountable for the process after the program team leaves.
4. Who owns the data? Define who creates, changes, and approves critical records and who answers for quality.
5. Who can approve an exception? Set the authority, rationale, and review point for deviations from the standard.

Once those decisions exist, the ERP program has a clear job: translate deliberate operating choices into a scalable and controlled system. Without them, a technically successful program can institutionalize decisions leadership did not realize it had delegated.

ERP does not create a common business. It reveals whether leadership has decided what should be common.

‍