Eight capabilities in two groups: the operating model—how work, decisions, adoption and performance are designed—and the technology that runs it. Each is plotted against the six layers of the operating model. These are areas of expertise, not packaged offers.
01Capability landscape8 capabilities · 2 groups · 6 layers
Capability landscape
CapabilityPOSDAM
AOperating modelHow work, decisions, adoption and performance are designed
01 · Operating model
Process Architecture
Current-state analysis, target-state design and process governance: stages, decision points, ownership, handoffs, approvals, exceptions and SLAs—defined before anything is automated.
Operating model coverageProcessOperating modelSystemsDataAutomationMeasurement
Processprimary
Operating modelsupporting
Systemssupporting
Datasupporting
Automationsupporting
Measurementprimary
Shows up as
Approvals nobody really owns
Handoffs that lose context
Exceptions handled in email
Questions that change the design
Which decision does each approval actually make—and on what evidence?
Where does accountability transfer, and what must be true at that moment?
BTechnologyThe systems, data, automation and AI that run the operation
01 · Operating model
Process Architecture
Current-state analysis, target-state design and process governance: stages, decision points, ownership, handoffs, approvals, exceptions and SLAs—defined before anything is automated.
Operating model coverageProcessOperating modelSystemsDataAutomationMeasurement
Processprimary
Operating modelsupporting
Systemssupporting
Datasupporting
Automationsupporting
Measurementprimary
Shows up as
Approvals nobody really owns
Handoffs that lose context
Exceptions handled in email
Questions that change the design
Which decision does each approval actually make—and on what evidence?
Where does accountability transfer, and what must be true at that moment?
AOperating modelHow work, decisions, adoption and performance are designed
01Process ArchitectureCurrent-state analysis, target-state design and process governance: stages, decision points, ownership, handoffs, approvals, exceptions and SLAs—defined before anything is automated.PrimaryProcessSupportingOperating modelSupportingSystemsSupportingDataSupportingAutomationPrimaryMeasurement
02Digital Operating ModelValue streams, ownership, decision rights, governance and measurement—designed together, then mapped to the processes, systems and data expected to support them.SupportingProcessPrimaryOperating modelSupportingSystemsSupportingDataSupportingAutomationPrimaryMeasurement
03Change & AdoptionAdoption designed into the solution: operating habits, roles, incentives, enablement and the signals that show whether a new commercial process is actually followed.SupportingProcessPrimaryOperating modelSupportingSystemsSupportingDataNot in scopeAutomationPrimaryMeasurement
08Revenue OperationsPipeline stages, handoffs, forecasts and management cadence designed as one commercial operating system.PrimaryProcessPrimaryOperating modelSupportingSystemsSupportingDataNot in scopeAutomationPrimaryMeasurement
BTechnologyThe systems, data, automation and AI that run the operation
04Systems & CRM ArchitectureAn agreed customer lifecycle encoded in the CRM, and platform boundaries across CRM, ERP, integration and data—drawn from capabilities and ownership, not from the order in which tools were bought.SupportingProcessSupportingOperating modelPrimarySystemsPrimaryDataSupportingAutomationNot in scopeMeasurement
05Data & IntegrationsIdentity, contracts, state and recovery across CRM, ERP and the data platform—and operational data shaped into governed signals, each with an owner, a definition and an action it should change.SupportingProcessSupportingOperating modelPrimarySystemsPrimaryDataSupportingAutomationSupportingMeasurement
06AutomationRouting, approvals, orchestration and lifecycle automation that remove coordination work without hiding policy, ownership or exceptions.SupportingProcessSupportingOperating modelSupportingSystemsNot in scopeDataPrimaryAutomationNot in scopeMeasurement
07AI & Agentic WorkflowsAI workflows with explicit confidence, authority, observability and stopping points—people at the consequential boundary.SupportingProcessNot in scopeOperating modelSupportingSystemsSupportingDataPrimaryAutomationNot in scopeMeasurement
Primary—where the capability makes decisionsSupporting—shapes or is shaped by itOutside the capability
03Reading the columnsThe operating model stack
01Process
Which stages, decisions and exceptions does the outcome require?
Stage & decision model
02Operating model
Who owns each stage, decision and handoff?
Decision-rights matrix
03Systems
Which system acts at each step—and which one is authoritative?
Process-to-system map
04Data
Which information is required, and who may create or change it?
Data ownership matrix
05Automation
Which work is deterministic enough to automate, and where must a person decide?
Automation boundary
06Measurement
How do we know the operation works—and who acts on the signal?
KPI ownership model
04Method / Second LayerProcess · systems · data
The obvious requirement is only the first layer.
I make the assumptions underneath a request visible before they become expensive system behavior—whether the request is about a process, a system or data.
Apply the method to
Visible requirement
“We need an approval process.”
First layer
Add an approval step to the flow.
That is a step. It is not yet a decision model.
4 of 12 questions surfaced
Second layer — what the request leaves unsaid
An approval without a named decision becomes a formality people learn to click through.