Design the Operating Model

A workflow can be automated and still be unowned

A process diagram shows where work moves. It may say little about who can resolve an ambiguous case, change a policy or accept the consequences of a decision. Those gaps become more consequential when a system can act faster than the organization can respond.

Use the operating case from the previous phase to define the outcome this design must serve. Follow a representative case from trigger to result, then follow one that arrives incomplete, crosses a boundary or requires an exception. The second journey reveals whether the design can operate beyond the demonstration.

Ownership begins here in practical terms, even though formal transfer comes later. The future Operating owner should be shaping the design, accepting its obligations and identifying the resources needed to sustain it.

Who can stop the work, resolve the exception and restart it—and will that person be available?

Five design choices leadership must make

Where should the work change?

Map the current flow and the intended flow, including queues, handoffs and duplicate checks. Remove unnecessary work before deciding which remaining activities need automation or AI. Judge the design by the end outcome: a faster step that increases downstream rework may weaken the operating case.

Which decisions can the system make?

Separate providing information, recommending an action and executing it. For each consequential decision, state the allowed action, its limits, the evidence required and the Outcome owner. Identify decisions people must retain. A broad instruction to keep a human involved leaves the timing and responsibility unresolved.

What happens outside the boundary?

Define how missing information, conflicting rules, unusual cases and unavailable services are handled. Give each exception a destination, response expectation and fallback. Estimate the workload this creates. A review queue with no funded capacity is an unfinished design.

What knowledge and access does the work require?

Identify the records, definitions and policies that support each decision, who owns them and who may see them. Distinguish knowing a value from having authority to act on it. Access to an invoice does not establish permission to change a supplier's payment details.

How will the operation stay accountable?

Assign responsibility for outcomes, service support, knowledge changes, controls and improvement. Agree how teams will review performance and resolve trade-offs. Include the funding and skills these responsibilities need. Suppliers may deliver part of the service; the enterprise still needs an owner who can make operating decisions.

Design the exception before the happy path

Hypothetical example, continuing the invoice opportunity.

An AI assistant can identify a missing goods receipt and prepare a request to Procurement. That does not mean it can approve payment. Finance retains payment authority; Procurement owns receipt resolution; the assistant records the evidence and routes the case.

Now test the difficult case: the supplier says goods arrived, the receipt is absent, and the usual approver is unavailable. The design needs a named substitute with the appropriate authority, a visible queue and a decision about how long the case may remain unresolved. An instruction to “escalate to a human” provides none of these.

First exercise: walk the case through the intended roles using actual policy and a realistic workload. If nobody can take the next action within the required time, revise the operating design before increasing system autonomy.

• Can the Operating owner explain how the proposed work design improves the agreed outcome?
• Are recommendation, execution and approval rights distinct for each consequential decision?
• Does every material exception have a destination, an available owner and enough response capacity?
• Can authorized people pause, override and resume the operation without depending on the original project team?
• Have the people doing the work tested the design against difficult cases and realistic demand?
• Are the knowledge, access, support and funding obligations assigned and accepted?

Choose the next commitment

Proceed to build when the work, decision rights and support obligations are sufficiently clear to implement. Rework the design where a consequential decision or exception remains unowned. Return to the operating case if the support burden or required authority materially changes the value proposition.

Design will continue during delivery. Record which changes the team may make and which require the Operating owner's decision.

Record the review decision as Expand, Continue, Narrow, Redesign or Stop. The phase gate states the next delivery commitment; a pause, fallback or rollback remains an operational control.