Redesigning Work Around Outcomes

Which part of the operation actually needs to change?

A customer asks to change an order before dispatch. AI can interpret the email and prepare a response quickly. But if the warehouse has already released the order, that response may promise something the operation cannot deliver. Faster preparation has improved a task. The customer’s outcome still depends on the decision, the handoff and what happens next.

Start by following that whole outcome. Then choose the smallest coherent change that can improve it. Sometimes this means rebuilding a process. Sometimes it means removing one approval, repairing one receiving condition or making reliable context available at a critical decision. The scope should follow the constraint and its dependencies.

My perspective

A redesign earns its place when the business can explain what improves, what remains, who takes responsibility and what evidence would change the decision. AI belongs where it makes that operating design more effective at an acceptable cost and level of risk.

The New Standard for Business Processes in the AI Era sets expectations for the resulting operation. This Framework explains how to carry out the redesign: establish the problem, compare alternatives, specify the changed work and earn the next commitment.

Five questions that lead to an operating commitment

Use this method for an existing operation with a consequential outcome and an identifiable owner. Bring together the people who perform, receive, support and control the work. Begin with case records and access to the operation; a mining platform is optional. The result is a target design, supporting evidence and a recorded decision about what may happen next.

These five questions form a working sequence. New evidence can reopen an earlier answer. Process redesign has an established lineage, including Hammer’s 1990 work and Davenport and Short’s treatment of technology and processes that cross organizational boundaries.^[1–2] This sequence and its application to AI-enabled operations are RPL editorial synthesis, not an independently validated method.

1. What outcome is constrained, and what does actual work show?

Name whose outcome matters and what makes it acceptable. A case being closed is insufficient if the customer must return to correct it. Appoint an Outcome owner accountable for the end-to-end result and the resources needed to achieve it. Define the trigger, end point, included case types, exclusions and follow-up period. Keep the wider outcome boundary visible even when the proposed intervention is narrow.

Build a baseline for a defined period and case mix: accepted outcomes, quality failures, elapsed time, active effort, waiting, repeat work, service interruptions and recurring cost. Include open, rejected and abandoned cases in the starting population. Explain exclusions and report acceptance rates as well as unit cost, so selecting easier cases cannot masquerade as improvement.

Trace ordinary cases and consequential exceptions from their original request to their eventual result. For each transition, record what arrived, what was missing, who decided, which evidence they used, what authority they held, how long work waited and what the next person actually accepted. Ask people to show the messages, spreadsheets, calls and workarounds that made the case move. Separate the active work from the queue around it.

Process mining can reveal recorded paths, repetitions, timing and departures from a reference process. Its event-log basis makes case identifiers, event meaning, timestamps and missing records important.^[3] Task mining can expose captured desktop steps, such as repeated entry and application switching; Microsoft’s current documentation describes this scope for its product.^[4] Check whose work and which applications the recording covers.

Treat those patterns as evidence to investigate. A long gap does not establish why work waited. Neither recording alone establishes customer value, legitimate authority or the quality of a judgment. Interviews explain reasoning; observation reveals coordination; case reconstruction tests those explanations against records. Label an inferred cause as a hypothesis until those sources agree.

Output: an accepted-outcome definition, baseline, case traces and a constraint hypothesis with supporting and conflicting evidence. If the constraint remains uncertain, fund a focused investigation before committing to a solution.

2. What work should change, and which option fits?

For each significant activity, ask what purpose it serves and what would happen if it disappeared. A repeated check may be waste, or it may compensate for unreliable upstream information. Remove the need or replace the control’s purpose before removing the check.

These choices can combine. Simplified intake may use rules for completeness, AI for interpreting free text and a person for a commercial commitment. Retain useful existing automation and interfaces; Modernize the Automation You Already Have examines those asset decisions.

Compare the current route, the simplest credible redesign and the AI-enabled candidate against the same outcome. Record expected benefit, recurring cost, one-time investment, dependencies, reversibility and what remains uncertain. If AI only looks attractive against a needlessly complicated baseline, the option comparison is incomplete.

Output: a reasoned choice, alternatives rejected and work deliberately retained. State which assumption, if disproved, would make another option preferable.

3. Can the changed operation work as a whole?

Describe the target route at the consequential transitions. Specify the trigger, responsible actor, decision, authoritative source and version, permitted action, receiving conditions, exception route and evidence of completion. Define what happens when information conflicts, the receiver is unavailable or the system cannot confirm whether an action completed. An uncertain transaction requires reconciliation before a retry that could duplicate it.

A handoff is complete when the receiving conditions are met and the receiving team accepts responsibility. If a consequential handoff is incomplete, the designated receiving lead must make the authorized decision to accept, return or hold it. Sending a message does not transfer accountability.

Use the six operating dimensions as connected design considerations:

Value & outcomesThe accepted result, service commitments and economic case.

Authority & controlsPermitted actions, human decisions, enforcement and intervention.

Work & decisionsThe changed route, retained work and receiving conditions.

Knowledge & contextThe current sources and case facts required at each decision.

People & capabilityOperating ownership, skills, staffing and capacity for exceptions.

Knowledge and human capability shape what the work can reliably deliver within its authority.

Evidence & adaptationAcceptance tests, monitoring and conditions for revisiting the design.

Operating evidence feeds back into outcomes, work, knowledge, authority and roles. A change in one dimension can require changes across the others.

Keep these in one connected design. A wider authority boundary may require better knowledge, additional controls and more skilled coverage. A faster intake route may overload the receiving team. Follow each consequence upstream, downstream and into shared services: does the design transfer effort, cost, risk, delay or data entry to someone else, including the customer? Name a dependency owner and the evidence that the dependency is ready.

The Operating owner runs the changed route. The Knowledge owner maintains source validity. The Technology owner owns reliable interfaces and enforced controls; the Control lead assesses control sufficiency. The Sponsor resolves commitments beyond the Outcome owner’s remit. Name people for the responsibilities the slice requires, including backup coverage.

For each decision or action, specify Recommend when a person decides; Act for a permitted action while its conditions hold; Escalate when the affected action must be withheld and routed; and Never Delegate for a named human decision. These are authority arrangements, not maturity levels. Use Bounded Autonomy to detail a proposed delegation.

Output: the target operation, owned dependencies and a bounded trial design. Include fallback triggers, the route that remains available, its capacity and the maximum period it can sustain service.

4. What must be demonstrated before use?

Agree acceptance criteria before the trial. The Outcome owner sets the required result with receiving teams and the Control lead; the Operating owner confirms that people can run it. Record the minimum worthwhile improvement, quality limits, exception capacity, cost boundary, duration and follow-up, with explicit pause and rollback triggers. Set thresholds from the operation’s baseline and consequences. A generic success percentage is insufficient.

Separate three commitments:

1. Offline evaluation: test representative ordinary, difficult and failed cases against recorded evidence. Include missing or contradictory facts, stale state, ambiguous requests and attempts to exceed authority. Compare the simpler redesign with the AI-assisted version. Keep a held-out set and record errors by type and consequence.
2. Operational readiness: rehearse access controls, receiving acceptance, peak demand, absent reviewers, outages, uncertain completion and recovery. Confirm training, monitoring, support ownership and finite human fallback capacity. Test what people actually do with an incorrect recommendation.
3. A limited live trial: admit only the agreed cohort, volume and authority under named supervision. Use a matched baseline or contemporaneous comparison where practical; account for case mix and other changes. Follow cases to accepted outcomes and later corrections. Record exclusions and departures from the trial plan.

NIST’s AI RMF supports evaluating performance in conditions resembling deployment and maintaining responsibilities, monitoring and response arrangements.^[5] It does not certify this design. Offline accuracy alone cannot demonstrate service continuity or sustainable human workload; a small live trial cannot establish reliability for every rare failure.

Calculate Cost per accepted outcome from recurring in-scope operating cost divided by accepted outcomes for the same cohort and accounting window. Include failed and repeated attempts, review, correction, support and recovery. Specify the follow-up needed before counting acceptance; show pending cases separately. With no accepted outcomes, the measure is not calculable.

Keep one-time design, integration and transition investment separate. Report released capacity as time available for a stated use. Claim realized savings only when an expense actually changes. Track elapsed time and active effort separately, alongside quality and work displaced to other teams.

Output: an evidence pack that distinguishes tested behavior, demonstrated operating readiness and live results. Authorize only the boundary supported by that evidence.

5. What does the evidence justify next?

Review results after the agreed follow-up and when volume, sources, policies, systems or staffing change. Inspect adverse cases as well as averages. Ask whether the constraint moved, whether benefits persist and whether support and exception costs are accumulating.

• Expand: extend a named cohort, volume or authority boundary when evidence and receiving capacity support that specific extension.
• Continue: retain the current boundary with a clear reason, review date and evidence still needed.
• Narrow: reduce exposure where failures or capacity limits are concentrated while preserving a supported route.
• Redesign: change the operating mechanism when its assumptions, handoffs or dependencies do not hold.
• Stop: retire the named capability or route when dependable operation or sufficient value cannot be justified; confirm how service continues.

A pause or rollback is an immediate operating control. It can precede any review decision. Record who can invoke it and who authorizes resumption. Improvement need not mean more autonomy: a simpler route or retained human decision may be the durable result.

A focused redesign of order changes

Hypothetical example—not a client result. A distributor receives requests to change orders before dispatch. Sales clarifies emails, copies details into the order system and sends a separate warehouse message. Fulfillment finds missing identifiers or conflicting quantities; Sales seeks clarification while dispatch approaches. An authorized salesperson confirms the resolution, and the warehouse fulfills the valid order.

The Operations director is the Outcome owner. The outcome is an accurately resolved request followed by fulfillment consistent with the authorized customer agreement. A justified refusal can be accepted if it is correct, communicated in time and followed by the agreed disposition of the original order. A lost request or avoidable late refusal is a failure. Report accepted changes, valid refusals, failed and pending requests separately.

The proposed initial scope is quantity or delivery-address changes for standard domestic orders before warehouse release. Pricing changes, credit decisions and export orders are excluded. Discovery must test the suspected constraint—an incomplete handoff—against cases including late requests and warehouse rejections. If warehouse capacity or an upstream commercial decision is the real constraint, change the proposal.

The candidate combines removal of duplicate entry, one structured change record, deterministic checks of required fields and current order status, and explicit warehouse acceptance. AI may prepare an internal draft from a free-text request, with links to the original evidence and unresolved fields left visible. Compare this with structured intake and rules alone. The existing order system and fulfillment route remain.

The Customer Operations manager runs the route; the warehouse lead owns receiving acceptance. The Knowledge owner maintains the order-change policy. The Technology owner ensures status checks, access enforcement and recorded completion. AI has Recommend authority for the internal draft. The trial delegates no order update or customer promise to AI. An authorized person makes those commitments.

Consider an order released while the draft is being prepared. The operation must recheck state at the point of the proposed update and prevent an update against an obsolete order version. If the interface cannot enforce that condition, exclude automated updates. Withhold the affected action, preserve the valid original order and route the case to the warehouse lead. Sales owns the customer response; a visible queue and response deadline prevent the unresolved request from disappearing.

The next commitment is discovery plus a bounded evaluation of the handoff design. Before live use, demonstrate correct handling of ordinary requests, conflicting messages, release races, unavailable reviewers and uncertain system responses. Agree numeric acceptance limits from the measured baseline, verify warehouse and Sales coverage, and rehearse the existing manual route.

A subsequent limited trial must show the required improvement in request-to-decision time without worse fulfillment, repeat contacts or warehouse queues. Follow through delivery and an agreed correction window. Include all teams’ recurring effort in Cost per accepted outcome. AI remains only if its incremental contribution over the simpler redesign justifies review and correction cost. A quicker draft alone supports no expansion.

The Work Behind Faster Supplier Payments offers a separate, qualitative operating record of focused scope and retained authority. It illustrates design judgment; it provides no measured validation of this method or evidence of AI-agent performance.

Make the next commitment reviewable

Keep one concise decision record, linked to the detailed case traces, target design and test evidence. A reader who did not attend the workshop should understand the proposed change, its limits and why the next commitment is justified.

For teams using the RPL companion collateral, A01 supplies the core decision record and A11 holds the operating-design detail and case traces. Reference their IDs and versions instead of maintaining competing records. The table above is usable independently of those companions.

The method organizes judgment; it cannot supply missing operational evidence or substitute for specialist control requirements. If accountability crosses teams without an owner able to secure commitments, resolve that dependency before live use. Scale the analysis to the consequences, while keeping outcome acceptance and service continuity explicit.

Leadership takeaway

Authorize a changed operation when the outcome, work, authority, dependencies and evidence form a coherent commitment. Follow the complete result, even when changing only one handoff. Make AI compete with a credible simpler design. Keep useful systems and human judgment where they serve the outcome, and give the receiving teams the capacity to make the change work. The next investment should follow demonstrated value within a stated boundary, with a clear decision when the evidence points elsewhere.

Where to go deeper

Leading the Change to AI-Enabled Operations connects this work to employee consequences, sponsor commitments, manager routines and evidence of appropriate use.

• Operating Model Redesign connects the six design considerations and lets you examine their consequences.
• Digital Operating Model examines what must change together across the operation.
• The Autonomous Enterprise Blueprint places the redesign within wider enterprise foundations and execution responsibilities.

Sources and further reading

Established process-redesign ideas and the sources below inform specific premises. The five-question method, decision record and hypothetical application are RPL editorial synthesis. These sources do not validate the complete Framework.

1. Michael Hammer — Reengineering Work: Don’t Automate, Obliterate
   Harvard Business Review, July–August 1990. Foundational reading.

2. Thomas H. Davenport and James E. Short — The New Industrial Engineering: Information Technology and Business Process Redesign
   MIT Sloan Management Review, July 15, 1990. The publisher’s summary connects information technology with customer-oriented processes across organizational boundaries; no historical performance claim is adopted here.

3. IEEE Task Force on Process Mining — Process Mining Manifesto
   2012. Supports event-log analysis, question-led investigation and attention to data quality and coverage. It is foundational guidance, not a review of current products.

4. Microsoft — Overview of task mining
   Updated December 6, 2025. Documents desktop-action capture in Power Automate; provider benefit statements are not treated as independent outcome evidence.

5. NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0)
   January 2023. GOVERN 2, MEASURE 2.3–2.5 and MANAGE 4.1 support responsibility, contextual evaluation, monitoring and response. NIST’s current framework page identifies version 1.0 as under revision.