Digital Operating Model
Technology implements the operating model. It does not define it.
I design how commercial work is owned, governed, measured and supported by systems—so transformation changes the way the organization operates, not only the tools it uses.
Nine layers, from the outcome to how it is measured. Read them top-down, as a design—or bottom-up, the way a platform-first project decides them by accident.
- 01Business outcomeWhat must happen?
- 02Value streamHow is value produced end to end?
- 03ProcessWhat states and decisions exist?
- 04OwnershipWho is accountable?
- 05SystemsWhere is work executed?
- 06DataWhat information is authoritative?
- 07AutomationWhat runs automatically?
- 08GovernanceWho may change the design?
- 09MeasurementHow do we know it works?
Not “implement a new platform”. The redesign of how the organization operates.
The operating model sits between strategy and technology: who owns the outcome, who decides, where work crosses boundaries, how systems support it, how local variation is governed and how performance is measured.
A technology roadmapAn org chartA process mapA governance committeeA CRM implementation planA collection of KPIs
- OutcomeWhat the organization must achieve, in observable terms.
- Value streamThe end-to-end flow that produces it, across departments.
- ProcessThe states, decisions and exception paths the stream needs.
- OwnershipOne accountable owner per stage, decision, system, data set and KPI.
- DecisionsWho decides, approves, recommends, is consulted—per decision.
- SystemsWhere each part of the work is executed and recorded.
- DataWhich information is authoritative, and who may change it.
- AutomationWhat runs by rule, and what stays a human decision.
- GovernanceHow variation, exceptions and change are decided.
- MeasurementKPIs with a definition owner, a business owner and an action.
- 01A system should not make an organizational decision by accident.
If the design does not decide it, the configuration will.
Operating-model layers - 02Shared ownership often means no ownership at the exception.
Every kind of “owner” is named separately.
Ownership - 03Local variation needs an owner, a reason and a review date.
Otherwise every exception becomes permanent architecture.
Global vs local - 04Governance without decision rights is just a meeting.
Who decides what, using which evidence, within what time.
Governance
From outcome to measurement.
Ten moves from what the organization must achieve to how it knows it is working. Platform choices come after the sixth; skipping a step usually means a system quietly makes that decision instead.
01Define the outcome
What are we trying to achieve?
An outcome someone can observe—not “go live”.
- Business outcome
- Customer outcome
- Operational outcome
- Constraints that cannot be traded away
Competing outcomes—speed versus control—must be ranked explicitly
Define the outcome
What are we trying to achieve?
An outcome someone can observe—not “go live”.
- Business outcome
- Customer outcome
- Operational outcome
- Constraints that cannot be traded away
Outcome & constraint statementCompeting outcomes—speed versus control—must be ranked explicitly
Identify the value stream
Which end-to-end flow creates that outcome?
Value moves across functions; organizations are drawn by function.
- Start event
- End event
- Customer and business outcome
- Major stages
- Organizational boundaries
Value stream mapThe waiting time between departments belongs to nobody until it is named
Design the process
Which states and decisions make the value stream work?
States with exit criteria, not department task lists.
- Stages
- Transitions
- Decision points
- Exception paths
Process architectureEvery rejection needs a defined destination state
Assign ownership
Who is accountable for each stage and outcome?
“Owner” is not one concept.
- Accountable owner
- Responsible role
- Escalation
- Handoff
Ownership modelShared ownership often means no ownership at the exception
Define decision rights
Who can decide what?
Exactly one role decides; approval is a separate right.
- Decide
- Approve
- Recommend
- Consult
- Inform
Decision-rights matrixGovernance without decision rights is just a meeting
Map systems
Which platforms support each part?
Systems implement decisions; they should not make them.
- System of action
- System of record
- Capability ownership
- System boundaries
Process-to-system mapA system should not make an organizational decision by accident
Map data ownership
Who owns the information required to operate and decide?
Authority per concept—sometimes per attribute.
- Source
- Authority
- Stewardship
- Derived data
- Lineage
Data ownership modelData quality is owned by whoever can fix it at the source
Define the automation boundary
What should run automatically and what should remain human?
Automate rules; keep judgement visible.
- Automated by rule
- Assisted—a person confirms
- Human decision, with the reason recorded
Automation boundaryAutomating an undefined decision hides the policy gap
Design governance
How are exceptions, local variation and changes controlled?
Who decides what, using which evidence, within what time.
- Variation owner
- Exception owner
- Change authority
- Review cadence
Governance modelLocal variation needs an owner, a reason and a review date
Define measurement
How do we know the operating model works?
Measurement is part of the operating model.
- Process KPIs
- Outcome KPIs
- Owner
- Cadence
- Action
KPI ownership modelA KPI without an owner and an action is reporting noise
The symptoms arrive as “the system doesn’t fit how we work”.
Usually the system fits a decision nobody made. Underneath, an owner, a decision right or a variation rule was never designed.
The global process exists on paper; local teams operate differently.
Usually missingA global core with declared, governed variationOwnership disappears where work crosses from one department to the next.
Usually missingA value-stream owner and handoff contractsA technology choice quietly settles a business decision nobody made.
Usually missingDecision rights defined before configurationSeveral teams believe they own the same customer state.
Usually missingSeparate process, system, data and KPI ownershipLocal exceptions become permanent architecture.
Usually missingA variation register with owners and review datesGovernance forums discuss issues but cannot decide.
Usually missingDecision rights, evidence and a time limit per domainKPIs exist, but nobody owns their definition or the action.
Usually missingA KPI ownership chainThe transformation project ends at go-live; the operating model never changes again.
Usually missingChange control and an operating-model review cadence
Artefacts that let an organization run what it builds.
Each one answers a question a platform rollout plan never asks.
- Outcome & constraint modelWhat must be achieved—and what cannot be traded away?
- Value stream mapWhich end-to-end flow creates the outcome?
- Operating-model blueprintAll nine layers, designed together
- Operating-model roadmapWhich layer changes when—and in which order?
- Process ownership modelWho owns each stage and the end-to-end outcome?
- Decision-rights matrixWho decides, approves, recommends, is consulted?
- Organizational handoff modelWhat “done” means before work changes hands
- Process-to-system mapWhere each stage is executed and recorded
- Process-to-data mapWhich data each decision needs, and who owns it
- Global / local variation registerReason, owner, scope, cost and review date per variation
- Exception governanceOwner, route, time limit and learning per exception type
- Management cadenceWhich forum decides what, from which evidence?
- KPI ownership modelDefinition owner, business owner, computation, action
- Change-control modelWho may change a stage, a rule, a KPI or a boundary?
- Governance modelDomains, decision owners, evidence and time limits
A system should not make an organizational decision by accident.
Nine layers, each with one question, one typical failure and one artefact. Select a layer.
Ownership
- Key question
- Who owns each stage, decision, system, data set and KPI?
- Typical failure
- “The business owns it”—until an exception needs a name.
- Artifact
- Ownership & decision-rights model
Organizations are structured by function. Value moves across them.
The same five functions and six stages, read two ways. In the value-stream view, select a gap to see what falls between departments.
Value moves across departments. The gaps where work changes hands are where operating models fail.
| Function | Lead | Opportunity | Customer | Order | Invoice | Performance |
|---|---|---|---|---|---|---|
| Marketing | Leads | Supports | Supports | |||
| Sales | Supports | Leads | Supports | Leads | Supports | |
| Finance | Supports | Leads | Supports | Leads | Supports | |
| IT / Platform | Supports | Supports | Supports | Supports | Supports | Supports |
| Data | Supports | Supports | Leads |
A won deal waits for customer creation; sales counts it as won, finance has not seen it.
A shared state with an owner of the transition, not two owners of two steps
Shared ownership often means no ownership at the exception.
“Owner” is not one universal concept. For the same piece of work, the process, stage, decision, system, data and KPI owners are often different functions—and each needs a name.
- Commercial operations
Owns The end-to-end flow from won deal to active customer
Not The credit decision
- Inside sales
Owns A complete, correct creation request
Not The legal record
- Finance
Owns Credit and legal validation
Not The commercial relationship
- Commercial systems (CRM) · Finance systems (ERP)
Owns Each platform’s configuration and releases
Not The business rules they run
- Master data
Owns Legal name, tax ID and billing identity
Not Commercial attributes
- Operations
Owns Creation lead time and rejection rate—and acting on them
Not The definition of a customer
Exactly one role decides. Everyone else has a named right.
Seven decisions across seven roles. Select a decision to see who decides, approves, recommends, is consulted and informed—and with which evidence, within what time.
| Decision | Commercial | Finance | Operations | IT / Platform | Data | Local subsidiary | Global governance |
|---|---|---|---|---|---|---|---|
| Recommends | Decides | Consulted | Consulted | Informed | |||
| Recommends | Decides | Informed | |||||
| Recommends | Consulted | Consulted | Consulted | Consulted | Decides | ||
| Recommends | Consulted | Decides | Approves | ||||
| Informed | Consulted | Consulted | Recommends | Decides | |||
| Consulted | Approves | Decides | Consulted | ||||
| Recommends | Approves | Informed | Informed | Decides |
Approve a local variation
- Decides
- Global governance
- Recommends
- Local subsidiary
- Consulted
- Operations, IT / Platform
- Informed
- Finance
- Evidence required
- Reason, owner, scope, cost, review date
- Decided within
- 4 weeks
Local variation needs an owner, a reason and a review date.
A global core that does not vary, variation at declared points, and local extensions only for genuine legal or operational constraints—each recorded with its reason, owner, scope, cost and review date.
- Global coreThe same everywhere. Not negotiable locally.
- Shared lifecycle and stage semantics
- Common definitions of customer, order, won
- Standard KPIs and their calculations
- Mandatory governance and controls
- Configurable variationDifferent values at declared points.
- Approval thresholds per legal entity
- Assignment and territory rules
- Who holds which role
- Local validation steps
- Local extensionOnly for a genuine legal or operational constraint.
- A country-specific legal field
- An additional document check
- A local ERP order type behind the integration
ReasonOwnerScopeCostReview date
| Variation | Tier | Reason | Owner | Scope | Cost | Review |
|---|---|---|---|---|---|---|
| Higher discount threshold | Configurable | Market price level | Subsidiary sales director | One legal entity | Configuration only | Annual |
| Tax ID validation step | Local extension | Legal requirement | Local finance | One country | One extension, tested per release | When the law changes |
| Own stage names | Rejected | Preference | — | — | Breaks comparability | — |
“Can we do it differently here?”
Five checks decide between a global change, a configurable variation, a local extension—or a recorded rejection.
- Legal requirement?No
- Customer or market requirement?Yes
- ERP or system constraint?No
- Operating-model difference?No
- Preference?No
A real market difference at a point the core already declares. Set the value; register it with an owner and a review date.
Governance without decision rights is just a meeting.
Governance answers who decides what, using which evidence, within what time—per domain. Exceptions are routed the same way.
- 01Issue / request
- 02Classify
- 03Owner
- 04Decision
- 05Implement
- 06Review
Process
- Decision owner
- Global process owner
- Evidence
- Stage ageing, exception volume, local feedback
- Within
- Quarterly review; urgent fixes in 2 weeks
- For example
- Add an exit criterion to Qualified
System
- Decision owner
- Platform owner
- Evidence
- Release impact, test results, variation affected
- Within
- Per release
- For example
- Retire a local automation copy
Data
- Decision owner
- Data owner per domain
- Evidence
- Quality metrics, consumers affected
- Within
- Monthly data forum
- For example
- Change the definition of an active customer
KPI
- Decision owner
- Definition owner (with the business owner)
- Evidence
- Metric contract, historical impact
- Within
- Monthly forum; effective next period
- For example
- Change the coverage horizon
Variation
- Decision owner
- Global governance
- Evidence
- Reason, owner, scope, cost, review date
- Within
- 4 weeks
- For example
- Approve a subsidiary threshold
Exception
- Decision owner
- Owner by exception type
- Evidence
- Case record and history
- Within
- By type—hours to days
- For example
- A one-off policy exception
Exception governance
Five kinds of exception, five owners. An exception should either be resolved or teach the operating model something.
| Exception | Owner | Route | Within | Resolution | Learning loop |
|---|---|---|---|---|---|
| Process exceptionAn order that skipped a required step | Process owner | Case to the stage owner | 2 working days | Complete the step or record why not | Recurring causes → process change |
| System failureAn integration message that never arrived | Platform owner | Incident with business impact noted | By severity | Recover and reconcile | Root cause → contract or monitoring change |
| Data quality issueTwo accounts for one legal entity | Data owner | Steward queue | 5 working days | Merge or correct at the source | Source causes → entry rule change |
| Policy exceptionA payment term outside policy | Decision owner (finance) | Approval with reason | 1 working day | Approve once, with an expiry—or reject | Frequent exceptions → policy review |
| Local variation requestA subsidiary wants a different step | Global governance | Variation register | 4 weeks | Global change, configuration, extension or reject | Repeated requests → core change |
A KPI without an owner and an action is reporting noise.
Five rhythms run and change the operating model—from weekly execution to the annual target. Every KPI they use has a definition owner, a business owner, a place it is computed and an action.
Execution review
- Participants
- Team managers
- Evidence
- Pipeline, overdue actions, open exceptions
- Decisions
- Unblock work; escalate exceptions past their time limit
- Outputs
- Actions per item
Performance & recovery
- Participants
- Managers, operations, finance
- Evidence
- Segments, recovery plans, KPI trends
- Decisions
- Accept, escalate or close recovery; KPI actions
- Outputs
- Plan outcomes, escalations
Operating-model review
- Participants
- Process, system and data owners; global governance
- Evidence
- Variation register, exception patterns, stage ageing
- Decisions
- Change the core, renew or retire variations
- Outputs
- Approved changes, updated register
Architecture & process change
- Participants
- Platform owner, process owner, affected subsidiaries
- Evidence
- Change requests, impact, test results
- Decisions
- What ships, what waits
- Outputs
- Release scope, communication
Target & strategic model
- Participants
- Leadership, finance, global governance
- Evidence
- Outcome KPIs, market changes, roadmap
- Decisions
- Targets, priorities, operating-model roadmap
- Outputs
- Target version, roadmap
KPI ownership chain
- Pipeline coverage
- RevOps
- Sales management
- Data platform
- Weekly pipeline review
- Pipeline generation below the agreed multiple
Five organizations, one question: who decides?
Synthetic global B2B scenarios. The standardization case is read here through the operating-model lens; four new cases cover the global model, CRM as operating platform, customer ownership and change after go-live.
- Case 01Selected workGlobal core, governed variation, owned lifecycle
Designing a global commercial operating model 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?
Global CRMLocal ERPsData platformVariation registerProcess ArchitectureSystems & CRM Architecture - Case 02Process case · operating-model lensDecision authority over variation
Standardizing a global commercial process without breaking local operations
A global process is mandated; subsidiaries comply on paper and work around it in practice.
Who has the authority to allow—or refuse—a local difference, and how is that decision governed over time?
Global CRM templateLocal ERPsVariation registerProcess ArchitectureChange & Adoption - Case 03Routines, ownership & retirement
Moving from CRM tool to commercial operating platform
The CRM is implemented, but managers run the business from spreadsheets and each team reads the stages its own way.
Which management routines, decisions and ownerships must move into the CRM before the company actually operates through it?
CRMSpreadsheets (retiring)Data platformCollaboration toolsChange & AdoptionRevenue Operations - Case 04Relationship vs transaction vs data ownership
Designing customer ownership in a multi-subsidiary organization
A group customer buys from several subsidiaries; three teams call it “my account” and nobody can resolve the disagreements.
Who owns the relationship, each transaction and the global account data—and who resolves ownership conflicts?
Global CRMLocal ERPsMaster dataData platformSystems & CRM ArchitectureData & Integrations - Case 05Change authority & versioned evolution
Governing operating-model change after go-live
Two years after go-live, changes arrive as tickets to the platform team; nobody decides whether they change the operating model—so the configuration drifts.
Who may change which part of the operating model, with which evidence, and how is each change released?
CRMChange backlogData platformVariation registerChange & AdoptionSystems & CRM Architecture
Every transformation request has a second layer.
The visible request is where the design starts, not where it ends.
“We need a new CRM for all subsidiaries.”
Select a platform and roll it out country by country.
4 of 6 questions surfaced
If the answer is “we use the new CRM”, the outcome is still missing.
The operating model decides. Process, systems and data implement it.
Digital Operating Model
- Process Architecture
The operating model decides who owns the value stream; process architecture designs its states, decisions and exceptions.
- Systems & CRM Architecture
Systems are assigned responsibilities by the operating model—not the other way round.
- Data & Integrations
Data ownership and authority follow the ownership model, concept by concept.
- Revenue Operations
The commercial cadence and KPI ownership run the operating model week by week.
- Change & Adoption
People operate through the new model only when roles, routines and incentives change with it.
- Automation
The automation boundary is an operating-model decision: which rules run by themselves, which stay human.
Architecture decisions
Cases & writing
A digital operating model is not a platform, an org chart or a committee. It is the coherent design of
- Outcome
- Value stream
- Process
- Ownership
- Decisions
- Systems
- Data
- Automation
- Governance
- Measurement
Design how the organization operates before deciding how the platform should behave.
Technology implements the operating model. It does not define it.
A new platform—and nobody has decided who owns what?
- Who owns your customer lifecycle end to end?
- Which local differences are legal—and which are habit?
- Which forum can actually decide?