Digital Operating Model

What must change together for the business outcome to improve?

A service team can answer faster while customers still wait for resolution. The missing piece may sit in another function: an outdated policy, a specialist queue, or approval authority that has never moved with the work. Increasing the speed of the first step does little to resolve that dependency.

Research illustrates the distinction. In a randomized field experiment covering 7,137 knowledge workers across 66 firms, individual access to an integrated AI assistant produced time savings, but the researchers did not detect changes in the quantity or composition of tasks. The study measured work patterns; it did not establish the effect of a coordinated operating-model redesign. [1]

My perspective

I would make the connections between teams an explicit investment decision. If an AI initiative depends on another function changing its knowledge, capacity, controls, or authority, that change belongs in the same operating commitment. Approving the tool while leaving those dependencies unfunded creates a promise the business may be unable to keep.

The Digital Operating Model provides a way to make that commitment coherent: define the outcome, trace the work across functions, and decide which operating dimensions must change together.

Six dimensions, one operating system

A Digital Operating Model is the deliberate design of how an enterprise creates value through work, knowledge, decision authority, technology, and human judgment. This Framework examines that design through six interdependent dimensions. It helps an executive sponsor and the leaders of participating functions agree a viable target model and the next investment needed to establish it.

Start with one value stream: the connected work from an initiating need to an accepted business outcome, including exceptions and follow-up. Choose a scope small enough to change, but wide enough to include the teams that determine the result. Use the model before a material redesign, when a pilot reaches several functions, or when operating results diverge from the investment case.

The relationships matter more than equal investment in every dimension. More delegation may require stronger knowledge and better exception coverage. Better knowledge may remove a handoff without requiring additional autonomy. Evaluate the combination needed for the chosen outcome.

Design the six dimensions together

1. Strategy-to-Execution Alignment

Translate the business objective into an outcome the participating teams can jointly deliver. For customer service, that could mean an accurate resolution within the promised time, with acceptable total effort. A target for faster responses alone leaves repeat contacts and downstream work outside the decision.

Assign an outcome owner with authority to resolve competing priorities. Connect local measures to the shared outcome and fund dependencies in the functions that must supply them. Include operating support, knowledge maintenance, review effort, and transition costs. Time released becomes an economic benefit only when the organization can use the capacity or change an actual expense.

Leadership question: Which commitments outside the sponsoring team must be funded for this outcome to become credible?

2. Workflow and Process Intelligence

Trace an ordinary case and a difficult exception through the complete workflow. Identify where the case waits, changes owner, loses context, or returns for rework. At each handoff, specify what the receiving team needs, who accepts responsibility, and what happens when the input is incomplete.

Then decide where to remove work, standardize a rule, use reliable automation, add AI assistance, or retain human judgment. Choose technology against those operating needs and test its actual fitness. A redesign that depends on unavailable integration or unreliable outputs must change its scope.

Leadership question: Does the proposed change improve the complete path to resolution, and can each receiving team absorb the resulting work?

3. Enterprise Knowledge Backbone

Specify the knowledge each consequential decision requires: the authoritative policy, current case facts, relevant history, and conditions that change the answer. The data estate holds records and data products; the knowledge backbone connects their meaning, authority, and permitted use to the work.

Give source owners responsibility for accuracy and change notification. Establish how conflicting versions are resolved and how the workflow responds when required evidence is absent. A retrieval capability cannot settle a policy dispute that the business itself has not resolved.

Leadership question: Who maintains the knowledge this workflow depends on, and what happens to permitted action when that knowledge becomes uncertain?

4. Decision Rights, Governance, and Bounded Autonomy

Make authority explicit across functional boundaries. Identify who may decide, who may execute, who may change the rules, and who may stop the work. Permission to prepare a recommendation does not automatically grant permission to implement it.

NIST's AI Risk Management Framework treats governance as a continuous responsibility across the system lifecycle, with executive responsibility and defined human–AI roles. [2] Here, that principle means authority must remain consistent when work passes between teams, systems, and external providers.

Use an existing executive forum to resolve disagreements that exceed the outcome owner's mandate. Record which leader can change the cross-functional commitment. The Bounded Autonomy Framework develops the detailed operating boundaries; this dimension connects them to the wider work design.

Leadership question: Can everyone involved explain the same limits on action and the same route for resolving an exception?

5. Observability and Operational Drift

Make the outcome and the conditions supporting it visible. Track elapsed resolution time, accepted quality, rework, review burden, costs, and consequential exceptions together. A technical availability measure cannot reveal that cases are accumulating in a human queue.

Operational drift means the work is moving away from its intended conditions or results. The cause may be changed inputs, policy, workload, system behavior, or informal workarounds. NIST recommends tracking risks against actual deployed performance and maintaining monitoring, recovery, and change-management arrangements. [2]

Leadership question: Which signal would cause us to restrict scope, restore a manual route, or reopen the design—and who must act on it?

6. Workforce Capability and Human Judgment

Design the jobs people will actually perform after the change. Account for exception volume, concentration, training, authority, and time to challenge an output. Removing routine work can change the difficulty of what remains; staffing decisions should reflect that workload.

In a customer-support study, Brynjolfsson, Li, and Raymond found that the effects of AI assistance differed substantially by worker experience and skill. Less experienced workers improved speed and quality, while the most experienced group saw small speed gains and small quality declines. This finding is specific to that deployment. [3]

Test the redesigned roles with experienced and newer staff. Preserve routes to learn the underlying work and raise concerns. Leadership question: Can the people receiving exceptions make sound decisions at the volume and complexity the model assumes?

Turn dependencies into an operating commitment

Bring together the outcome owner, affected functional leaders, frontline representatives, and the relevant technology, Knowledge owners, Finance, and Control leads. Bring actual cases, the current workflow, baseline results, known exceptions, operating costs, and the proposed change. Mark unavailable evidence as unknown.

Trace what must change with the proposal

Walk each case through all six dimensions. For every proposed improvement, ask which other dimension must support it. Faster case triage, for example, changes what reaches specialists; it may require current routing knowledge, additional review capacity, clear escalation authority, and measures of final resolution.

Keep expanding the analysis until every material dependency has an owner and an operating response. Stop at the boundary of the chosen outcome: a useful review need not redesign the entire enterprise. The output is a short record of connected changes, including what can remain as it is.

Let the unresolved dependency determine the next move

An unclear outcome calls for reframing. An absent owner or unfunded handoff calls for a revised operating commitment. Missing knowledge or untested system performance calls for a narrower trial. Unreliable controls or insufficient human response capacity calls for limiting the action allowed.

Do not average these conditions into a readiness score. A strong platform cannot compensate for missing authority, and a well-staffed review team cannot establish the truth of an unreliable source. If several conditions remain unknown, the next investment should produce evidence about the most consequential uncertainty.

Where several value streams need the same knowledge service or control capability, make its shared ownership, funding, and service expectations explicit. Reuse becomes practical when a maintained capability can serve more than one operation.

Initialize, Industrialize, Institutionalize

These three stages describe how firmly the operating model is established. They do not measure the amount of autonomy, certify maturity, or require every function to advance together. The transition criteria below are design tests for the chosen value stream.

Initialize

Make the current work visible, agree the connected changes, and run a bounded trial. Move forward when an Outcome owner accepts the model, critical dependencies have owners and funding, and representative cases demonstrate the agreed quality, authority limits, and recovery route. A persuasive demonstration alone does not establish those conditions.

Industrialize

Establish support, source maintenance, role coverage, and monitoring at the intended workload. Test ordinary cases, difficult exceptions, demand peaks, and staff absence. Move forward when performance remains acceptable with the support the business intends to fund, and recurring issues reliably reach owners who can correct them.

Institutionalize

Make the model part of resource allocation, role expectations, operating reviews, and controlled change. Demonstrate that a material policy, demand, or system change leads to coordinated updates across the affected dimensions. When evidence weakens the case, Narrow, Redesign or Stop the capability.

The wider execution responsibilities remain Envision, Plan, Build, Operate, Govern, Improve. They apply within and across these stages; Govern is active from the first commitment. The stages describe how established the operating design has become, while those responsibilities describe the leadership work that sustains it.

The same dimensions can produce different decisions

Hypothetical design scenarios. These examples test the model's logic. They are not client cases, achieved results, or claims that the proposed benefits have been realized.

Equipment-service resolution

A manufacturer proposes AI assistance to resolve equipment-service requests faster. The Operating owner for service delivery traces cases through Customer Support, Parts, and field scheduling. The analysis finds that delays depend on unreliable parts availability and a scheduling queue. Better draft responses would leave those constraints intact.

The connected commitment funds current parts information, agreed scheduling handoffs, specialist capacity, and shared resolution measures. Assistance may retrieve approved guidance and draft a service plan; commitments to customers remain with authorized staff. Conflicting information routes to the responsible specialist.

The next investment therefore changes from a broad assistant rollout to a bounded service redesign. Evidence must show better completed resolutions without increased repeat visits, incorrect promises, or displaced effort. Released support time is expected capacity until management demonstrates how it has been used.

Insurance claim review

An insurer proposes using AI to assemble evidence for a defined class of claims. The Operating owner for claims brings together intake, policy specialists, reviewers, and Control leads. The review finds conflicting policy versions and unclear responsibility for missing documents.

The first commitment establishes authoritative policy context and document ownership, then tests evidence assembly with source traceability. Under this illustrative design, coverage determinations and settlement authority remain with authorized people. Faster preparation does not expand that authority. Conflicting or incomplete evidence must reach a named reviewer.

Evaluate omissions, traceability, reviewer corrections, elapsed decision time, and the complete cost of review. Specialist assessment must establish the obligations applicable to the insurer and jurisdiction. Compared with service scheduling, the consequential decision demands a different authority boundary and evidence standard, even though the same six dimensions organize the work.

Where the Framework stops

This is an editorial decision aid. It does not validate a technology, certify compliance, establish a universal maturity score, or guarantee business results. The scenarios test coherence, not general applicability. A sound outcome may use conventional automation or sustained human assistance. Expand autonomy only when its value, evidence, and operating support justify the change.

Leadership takeaway

The next leadership decision

Choose one value stream and ask each participating leader what must change for the promised outcome to hold. Agree the smallest set of connected changes that can work, name the owners, and fund the dependencies together. Approve expansion when operating evidence supports that complete commitment. The essential executive contribution is making the model coherent enough for the business to own.

Where to go deeper

• The Autonomous Enterprise Blueprint — Connect the operating design with enterprise foundations and the full execution responsibilities.
• Enterprise Knowledge Backbone — Develop the source ownership, context, and knowledge responsibilities required by the work.
• Human-in-the-Loop Synergy — Specify where human judgment enters the workflow and what makes intervention effective.

Sources and further reading

The sources support specific premises. The six-dimension synthesis, application method, and stage transition tests are RePerspective Labs editorial design; the sources do not validate this Framework.

1. Dillon, Jaffe, Immorlica, and Stanton — Shifting Work Patterns with Generative AI
   13 November 2025 revision; first submitted 15 April 2025.
   Randomized field experiment on individual AI access and work patterns. Includes Microsoft researchers; it does not test this operating model.

2. NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0)
   January 2023.
   Voluntary guidance. See GOVERN, MEASURE 3.1, and MANAGE 4.1 for continuing oversight, deployed risk monitoring, and response arrangements.

3. Brynjolfsson, Li, and Raymond — Generative AI at Work
   6 November 2024 revision; first submitted 23 April 2023.
   Customer-support deployment showing different effects by experience and skill. Results are context-specific, not a general benefit forecast.