Designing a global commercial operating model across subsidiaries
A fictional operating-model case: many subsidiaries, different habits and ERPs, one way of running the commercial business—designed before the platform decides it.
Independently created. Contains no employer or client implementation detail, internal names or figures.
01The outcome
One global core every subsidiary runs, a register of legitimate variation with owners and review dates, one accountable owner for the end-to-end lifecycle, governance that decides within set times, and KPIs comparable across subsidiaries.
Subsidiaries run the commercial business their own way; a global platform is about to be rolled out on top of those differences.
Which decisions are global, which are local—and who owns the end-to-end lifecycle when it crosses subsidiaries?
Design the global core, the variation rules and the ownership model first; roll out the platform as the implementation of that design, subsidiary by subsidiary.
A global B2B company operates through subsidiaries with different roles, legacy habits, ERPs, management maturity and approval rules. Lifecycle words—lead, qualified, won, customer—mean different things in each. Leadership wants one commercial operating model and one platform, without flattening differences that are real.
02The reality · current state
How the organization operates today.
- Roles with the same title do different work in each subsidiary
- Approval rules are local habits, not documented decisions
- Lifecycle definitions differ, so global reports need translation
- Several ERPs impose constraints the global design has never seen
- Nobody owns the lifecycle end to end—only local steps
- A platform rollout plan exists; an operating-model design does not
03Operating model
The design, layer by layer.
- 01Outcome
Comparable commercial performance and one customer lifecycle across subsidiaries, within local legal constraints
- 02Value stream
Lead to cash, with the legal-entity boundary made explicit
- 03Process
One lifecycle and stage semantics; declared variation points
- 04Ownership
A global lifecycle owner; local stage owners; decision owners per decision
- 05Systems
One global CRM; local ERPs behind an integration contract
- 06Data
Global definitions; local legal identifiers as declared extensions
- 07Automation
Global automation only; local rules as configuration
- 08Governance
Global governance with decision rights, a variation register and time limits
- 09Measurement
Global KPI definitions, local target values
04Key dimension · Global core, governed variation, owned lifecycle
Global core, controlled variation, local extension
Three tiers, and a register entry for everything that is not core.
- Lifecycle and stage semantics
- Definitions of customer, order and won
- KPI calculations
- Decision rights for global decisions
- Mandatory controls
- Approval threshold values
- Assignment rules
- Who holds which role
- Local validation steps
- Country legal fields
- Local document checks
- ERP-specific structures behind the integration
| Variation | Reason | Owner | Scope | Cost | Review |
|---|---|---|---|---|---|
| Discount threshold × 1.5 | Market price level | Subsidiary sales director | One legal entity | Configuration | Annual |
| Tax ID check before order | Legal requirement | Local finance | One country | One extension | On law change |
| Merged sales and service role | Small entity | Subsidiary director | One entity | Segregation control added | On headcount change |
The rollout plan follows the register: a subsidiary goes live when its variations are decided, not when its data is migrated.
05Decision rights
Who decides what, with which evidence, within what time.
| Decision | Decides | Approves | Consulted | Evidence | Within |
|---|---|---|---|---|---|
| Change the global lifecycle | Global governance | — | Subsidiaries, process owner, platform owner | Ageing and conversion across subsidiaries | Quarterly |
| Approve a local variation | Global governance | — | Platform owner, local finance | Reason, owner, scope, cost, review date | 4 weeks |
| Set a local approval threshold | Subsidiary director | Global finance | Sales management | Margin and market data | Annual |
| Change a KPI definition | Global data owner | Global governance | Subsidiaries | Metric contract and historical impact | Next period |
06Governance
The forums that run and change the model.
| Forum | Decides | Evidence |
|---|---|---|
| Global operating-model reviewQuarterly | Core changes; variation renewals and retirements | Variation register, exception patterns, KPI comparability |
| Subsidiary operating reviewMonthly | Local actions; variation requests to raise | Local KPIs against global definitions |
| Release boardPer release | What ships to which subsidiaries | Impact on core and registered variations |
07The trade-offs
Credible options, judged against these premises.
One rigid global template
Homogeneous subsidiaries
Cost: Workarounds outside the system; compliance on paperEach subsidiary designs its own model
Independent businesses
Cost: No comparable KPIs, no shared platformGlobal core + governed variation + owned lifecycle
Shared customers, one leadership, real local constraints
Cost: A governance model and a register to run08The second layer
Questions that change the design.
Scope
- Which decisions are global?
- Which are local?
- Who owns the end-to-end lifecycle?
Variation
- Who may approve deviation?
- How are local constraints recorded?
- When does a local variation become global?
Evolution
- How do global KPIs remain comparable?
- How is the model changed over time?
- Which subsidiary goes live first—and why?
09Decisions & outputs
What the work produces.
- 01Operating-model blueprint
- 02Ownership model
- 03Variation register
- 04Governance model
- 05KPI comparability rules
- 06Rollout model