Stop Automating Old Processes. Design New Ones Instead.

Companies are rapidly increasing AI investment, but enterprise returns remain elusive. BCG’s January 2026 “AI Radar,” surveying 640 CEOs across 16 markets, reports that corporations expect to roughly double AI spending this year, from 0.8% of revenue to about 1.7%. Yet PwC’s 2026 “Global CEO Survey” finds that only 12% of CEOs report both revenue and cost benefits, while McKinsey QuantumBlack’s April 2026 analysis finds that 60% of organizations still see no enterprise-wide EBIT impact—even as nearly eight in 10 use generative AI in at least one business function. This kind of mismatch between our expectations of technology and the returns to our investment in it is not exactly new. In 1990, Michael Hammer warned in these pages that incumbent companies were squandering the opportunities afforded by IT by pointing it at existing processes instead of redesigning the processes to leverage the technology’s capabilities. Three decades later, his warning is as urgent as ever. In a recent HBR article, Vivian Lee, Linda Mantia, and Jon McNeill document what comes next: agentic-AI-native startups have compressed the capital and time needed to enter markets to a fraction of the incumbent curve. Their prescription for incumbents—rearchitect before you automate—is exactly right. The harder question is how. We recommend treating the workflow, not the individual task, as the object of redesign. This method then asks managers to make three decisions: what should change, where human authority should remain, and how the process should respond when the model is uncertain or wrong. We created and refined this framework over the last three years with dozens of companies and hundreds of executive education participants at our institutions, and had them apply this approach to processes within their companies and document the outcomes. Redesign the Workflow, Not the Task In 2025, Deloitte Australia agreed to partially refund the Australian government after a report it produced for the Department of Employment and Workplace Relations was found to contain fabricated references, nonexistent academic papers, and a made-up legal quote. A revised version disclosed that Azure OpenAI had been used in preparing the report. The lesson is not that professional-services firms should never use gen AI. It is that the firm had inserted gen AI into a high-accountability process without a strong enough verification gate. An official report is not just text. It is the visible output of an evidence chain. The value lies not in producing pages faster but in producing defensible findings supported by verifiable sources. Once that outcome is correctly named, the operating requirement changes: AI may draft, summarize, or check completeness, but every legal citation, empirical claim, and source-dependent statement requires a verification step before it becomes official. Compare Wayfair. Its catalog includes roughly 30 million items, and inconsistent product attributes can damage search, recommendations, merchandising, and returns. Working with OpenAI, Wayfair embedded models into the catalog and supplier-support workflow, correcting 2.5 million product tags and automating 41,000 supplier-support tickets per month. Those figures demonstrate the scale of the redesigned workflow, not by themselves its business value; that value must ultimately be assessed through catalog accuracy, customer search and conversion, supplier resolution quality, and returns. The important point is not the choice of technology vendor. It is that Wayfair redesigned the operating process: define the tag, extract the attribute, use confidence thresholds, route low-confidence fields for human or supplier confirmation, and let the system learn from corrections. The Deloitte–Wayfair contrast is not about who used AI and who did not. Both did. It is about the scope of the intervention. Deloitte applied gen AI to one task—drafting—inside a process whose value depended on a broader evidence chain. Wayfair redesigned the workflow around the technology, making definitions, thresholds, handoffs, exceptions, and feedback loops explicit. The lesson is simple: redesign the workflow, not just the task. When companies automate a task without redesigning the surrounding workflow, they tend to fail in four predictable ways. As shown in exhibit 1, they can: Accelerate tasks, not value. In the Deloitte case, the easy task to accelerate was report drafting. But the outcome-producing work was source verification. A faster report that weakens the evidence chain is a quality failure requiring a refund, not an efficiency gain. Ignore the unhappy outcome. Apple’s 2025 news-notification summaries looked like a routine summarization feature until false summaries of sensitive news stories appeared under publishers’ brands. Summarizing with AI was not the challenge with offering this service. It was knowing what to do when the model is unsure, the story is sensitive, or a correction would be more damaging than silence. Ignore end-to-end flow. Coding agents can dramatically increase the volume of code produced while shifting the constraint to code review, integration testing, security review, or deployment. The local productivity gain is real, but the development cycle does not improve (and may even slow down) unless the entire flow is redesigned. The question is not only whether the agent can write code. It is whether the surrounding workflow can absorb, verify, integrate, and safely deploy what the agent produces. Optimize the wrong metric. A customer service agent can raise ticket closure rates by ending interactions quickly, increasing repeat contacts, and leaving underlying problems unresolved. The tempting metrics for AI agents are often throughput measures: tickets closed, code produced, reports drafted, handoffs avoided. But the question about scale is different: Did resolution quality, conversion, uptime, safety, or customer trust improve? If a pilot cannot name the guardrails that make its primary KPI safe, it is not ready for scaling. Four Ways AI Pilots Become Automated Messes AI automates messes in four ways. For each mode, this table shows what goes wrong, what produced the error, and the questions to ask in order to better target AI implementation. Failure mode What goes wrong Design error Diagnostic question Failure mode Accelerating tasks, not creating value What goes wrong Task execution speeds up; performance does not improve. Design error The intervention targets an activity rather than the outcome-producing work. Diagnostic question Where does this workflow actually create value, and is AI changing that? Failure mode Ignoring the unhappy outcome What goes wrong The demo works; real operations break it. Design error The design covers standard cases but not missing data, ambiguity, exceptions, or handoffs. Diagnostic question What happens when the case is messy? Failure mode Ignoring end-to-end flow What goes wrong One team improves; the bottleneck moves downstream. Design error The process boundary is drawn too narrowly, creating local rather than systemwide optimization. Diagnostic question Where will the bottleneck move? Failure mode Optimizing the wrong metric What goes wrong The dashboard improves; outcomes deteriorate. Design error Success is defined by speed or activity rather than the desired outcome. Diagnostic question What outcome must improve, and what guardrails prevent gaming? Source: Masha Shunko, Serguei Netessine Decision 1: Choose What to Redesign Before launching a pilot, managers should run three tests on the process. The first two (outcome and constraint) determine whether and how the work should be redesigned. The compounding test helps determine where to begin by identifying opportunities in which corrections and expert judgments improve the next cycle. The outcome test. What outcome does the customer or user value? By value, we mean that desired outcome—not the volume of intermediate work completed. In Deloitte’s case, the buyer did not want pages; it wanted reliable assurance about an automated welfare-compliance system. In Wayfair’s case, the shopper does not want a well-tagged database; she wants to find the right product and trust what the listing says. Once the outcome is named, the current artifact (the report, dashboard, memo, or ticket) can be judged against the job it is supposed to do. The constraint test. For each step, what constraint was it designed to work around, and does that constraint still bind? Wayfair’s legacy catalog-correction process relied on suppliers and manual review because humans could not continuously inspect millions of SKUs. GenAI loosened that constraint, but not every constraint disappeared: ambiguous attributes and low-confidence corrections still required human or supplier confirmation. The right move was not blanket automation. It was a new workflow with confidence thresholds. The compounding test. Does this step build an asset that makes the next cycle faster, better, or more defensible? A venture-capital diligence review can produce more than a memo; it can add to a query-able store of patterns about founder risk, contract gaps, valuation benchmarks, and market signals. A catalog correction can improve the tag definition, synonym list, and confidence rule for the next product. Compounding is not a requirement for every worthwhile redesign. It is a prioritization criterion: all else equal, begin where corrections and expert judgments create reusable organizational learning. Together, the tests create a decision rule. Preserve or amplify work that directly produces the desired outcome and still requires scarce human judgment. Redesign work that is built around the constraints AI has loosened. Compress necessary coordination and compliance overhead. Eliminate activities that neither contribute to the outcome nor address a binding constraint. In Lean terms, automating muda merely produces cheaper muda. The best early AI pilots are not necessarily targeted at the biggest problems. They are applied to activities that are close to the desired outcome, consume expert time without requiring expert judgment, use digital inputs, can be checked quickly, and create learning that improves the next cycle. Decision 2: Decide Where Human Authority Remains Naming the outcome-producing workflow tells you what to redesign. Deciding where AI stops and human authority begins tells you how to govern the redesign. Everyone agrees that a human should be in the loop; almost no one specifies what that means. A human can evaluate, approve, audit, override, rubber-stamp, or merely absorb blame. What matters is where people intervene, on what, and with what authority. The 4A (Assist-Approve-Audit-Automate) framework gives that specification. Assist. In this mode, the AI provides suggestions, drafts, analysis, and options, while a human evaluates the output, exercises judgment, and acts. It is best used when stakes are high, judgment is tacit, or cases are low frequency. Approve. In this mode, the AI prepares an action or recommendation but a human must approve the decision before execution. It is best used when the speed of a process is important but there remains some risk and uncertainty around outcomes. Audit. In this mode, the AI makes a decision and executes on it. Humans oversee the process through random reviewing and intervene to correct systemic errors. It is best used in high-volume processes in which errors are visible and reversible, and where retrospective reviews can detect whether the system is drifting away from intended outcomes. Automate. In this mode, the AI executes within guardrails that are defined by humans, who intervene only in exceptional circumstances. It works best for standardized tasks that are frequent, low risk, and bounded by enforceable rules. Choosing among the modes is not a matter of taste but of two questions: who gets hurt if something goes wrong, and whether the organization can undo it. Retain more human control—Assist or Approve—when stakes are high or actions are difficult to reverse. Delegate more execution—Audit or Automate—when errors are visible, inexpensive, and readily corrected. Recent agentic coding incidents show what happens when authority, permissions, and stop lines are not explicit. In July 2025, SaaStr founder Jason Lemkin reported that Replit’s AI coding tool deleted a production database despite written instructions not to change code without permission, then generated fake records and reports. In April 2026, PocketOS founder Jer Crane reported that a Cursor agent deleted the company’s production database and backups in seconds after finding an overly broad API token. In both cases, the management issue was permissions and stop lines, not only model behavior. These are not merely model failures. They are examples of agentic AI operating in Automate mode for irreversible actions, without an approval gate and without separation between staging and production credentials. Irreversible actions initiated by an agent should default to Approve unless the action is tightly bounded by independently enforced controls: the agent prepares, a human approves, and the action executes. The approval step may introduce friction, but that cost should be compared with the expected cost of an irreversible failure. The goal of the 4A framework is not to be conservative everywhere. It is to be deliberate everywhere. Trust is not a communication campaign. It is an operating design. Decision 3: Design the Unhappy Path First Most AI demos show standard cases. Real operations are full of exceptions: the field is missing, the policy is ambiguous, the deck contradicts the financials, the agent hits a credential mismatch. These are not edge cases. They are the work. A redesigned workflow makes the unhappy path explicit. Managers should answer five questions before scaling: How will the system recognize uncertainty? What conditions trigger escalation? Who has the authority to resolve the exception? How can an action be stopped or reversed? How will corrections improve the next cycle? If critical information is missing, escalate. If model confidence is low, state the uncertainty rather than presenting a fluent guess. If a recommendation conflicts with a constraint, stop and escalate. If a human overrides the system, log the decision and review the pattern. Irreversible actions require approval or a tested rollback mechanism; repeated exceptions should prompt updates to the workflow, policy, or model. The goal is not perfect performance on demo cases; it is intelligible degradation on messy ones. Trust is built around the model in the process, not in the model itself. Your Next AI Pilot Ask any team proposing an AI pilot to complete this sentence: We will improve [outcome] in [end-to-end process] by redesigning [workflow], using AI to [role], with humans retaining authority over [judgment/control], exceptions routed through [escalation path], success measured by [primary KPI], and performance protected by [guardrails]. If they cannot complete it, they do not have a transformation project—only a technology experiment. . . . Hammer’s warning still stands: do not use powerful technology to mechanize old work. Use it to invent better work. The competitive advantage will not come from automating most tasks. It will come from redesigning work around the outcomes that matter, deliberately assigning authority, and building processes that remain reliable even when conditions are messy. Companies that do that will create better work. Those that do not will simply produce faster messes.

Stop Automating Old Processes. Design New Ones Instead.

Summary.

Partner Center