Record every local variation with a reason, owner, scope, cost and review date
Local differences are decisions, not habits. Each one is classified—global change, configuration, local extension or rejected—and recorded with its reason, owner, scope, cost and review date.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01Context
A global commercial model allowed subsidiaries to “adapt where needed”. Three years later there were more than a hundred local differences, nobody could say why most of them existed, several subsidiaries had solved the same constraint differently, and global KPIs needed correction tables to compare.
02Decision drivers
- D01
Legal and market constraints are real
- D02
Preferences must not become architecture
- D03
Global KPIs must stay comparable
- D04
Differences several subsidiaries share should become global
03Options considered
No variation allowed
Homogeneous markets
Cost: Workarounds outside the systemLocal administrators decide
Independent businesses
Cost: Untracked divergence; no comparabilityA classified, owned, reviewed variation register
One model across subsidiaries with real constraints
Cost: A register and a governance route to run04Decision
Classify every local request by its reason—legal requirement, customer or market requirement, ERP or system constraint, operating-model difference, or preference—and decide an outcome: global change, configurable variation, local extension, or rejection. Record every accepted variation with its reason, owner, scope, cost and review date; renew, merge into the core or retire it at review. Record rejections with their reason. Platform implementation follows ADR 006: configuration, never forks.
05Consequences
- Every difference has an owner and an expiry.
- Shared differences surface and move into the global core.
- Preferences are declined consistently, with a recorded reason.
- Global KPIs stay comparable because definitions never vary—only values.
06Revisit when
The organization operates as independent businesses with no shared customers or reporting.
Variation is so rare that a register costs more than it saves.
07Where this decision is applied
Cases that take this decision, and why it matters there.
- Operating-model case / 01Designing a global commercial operating model across subsidiariesOne commercial operating model for many subsidiaries: a global core, governed local variation, ownership that survives handoffs, a governance model with decision rights, clear system responsibilities and KPIs that stay comparable.
- Operating-model case / 05Governing operating-model change after go-liveThe operating model as a product: change requests classified by domain, decided by named owners with evidence and time limits, released in versions—so the model keeps improving after the project ends.
- Adoption case / 02Designing adoption for a multi-subsidiary CRM rolloutA global CRM deployed across subsidiaries with different maturity, roles, data quality, local tools and management habits: readiness assessed per unit, waves sequenced by readiness, enablement by role, champions with time, and adoption compared by level in local context.