Fix the Process Before You Automate It: Why AI on a Broken Workflow Multiplies the Mess

In the summer of 1990, Harvard Business Review ran an essay by Michael Hammer titled Reengineering Work: Don't Automate, Obliterate. His complaint was that companies were pouring money into computers to speed up work that should never have existed in the first place. Paving the cowpaths, he called it. Thirty-six years later we're doing it again with generative AI, except the paving crew now works at machine speed and the cowpath gets a chat interface.

I keep watching the same movie in mid-market companies. A team picks a painful workflow, buys or builds an AI tool for it, demos something impressive in week three, and then six months later the pilot is quietly shelved because every output needed so much checking that nobody trusted the thing. When I dig into these stalls, the workflow underneath the tool turns out to be the weak point far more often than the model does. The handoffs were never clear, the inputs were never consistent, and the exceptions were never counted. The AI inherited all of it, then ran it faster.

The research backs this up, and it's worth walking through before you sign your next statement of work.

What the failed pilots have in common

MIT's NANDA initiative published a study in August 2025 called The GenAI Divide: State of AI in Business, built on 150 executive interviews, a survey of 350 employees, and an analysis of 300 public AI deployments. The headline traveled everywhere: the researchers found that roughly 95% of enterprise GenAI pilots delivered no measurable P&L impact, despite an estimated $30 to 40 billion in enterprise spending. The root causes got far less attention than the number. The stalled pilots shared traits that had almost nothing to do with model quality. The tools didn't retain feedback or learn from corrections, and they were never integrated into the actual workflow, so they sat beside the work instead of inside it.

Flip it around and the successful 5% look boringly consistent. They embedded a tool inside one specific workflow, adapted it to context, and expanded from a narrow, high-value foothold. The same study found that buying from specialized vendors succeeded about 67% of the time while internal builds succeeded only about a third as often, and I'd argue that gap is mostly a process-understanding gap. A vendor that has sold into fifty AP departments has been forced to learn what invoice workflows actually look like, exceptions and all. An internal team automating its own process usually starts from the SOP document, which describes a process that exists mainly inside the SOP document.

The pattern shows up at the top of the house too. IBM's Institute for Business Value surveyed 2,000 CEOs in 2025 and found that only 25% of AI initiatives had delivered their expected ROI, and only 16% had scaled across the enterprise. The tools arrived, but the operating model around them never moved.

How a broken workflow multiplies through AI

A broken manual process has two features that hide its brokenness. It's slow, which caps the damage it can do per day. And it's full of humans quietly patching it. Someone in AP knows that a particular supplier always puts the PO number in the wrong field, and fixes it without telling anyone. Someone in sales ops knows that deals from one region need the currency double-checked. None of this is written down, because to the people doing it, it just feels like common sense rather than a process step.

Automation removes the speed cap and the patch layer at the same time. The tool executes the documented process, which was never the real process, and executes it fast. Three defects do most of the damage:

• Unclear handoffs. When a handoff between two people is fuzzy, they negotiate it in Slack and the work limps through. When an automated handoff is fuzzy, the system guesses what the next step needs, and the error surfaces three steps downstream where it's expensive to trace. Ownership of the mistake evaporates too, because everyone can point at the tool.
• Exception-heavy branches. Automation eats the clean cases and leaves people a concentrated stream of the hardest ones, stripped of the context they used to absorb by handling easy cases in between. If 30% of your volume is exceptions, the automation mostly reorganizes work into a worse queue, and the hard cases still land on humans, now colder and later.
• Bad inputs. GenAI is a fluency machine, and fluency reads as confidence. A wrong number in a messy spreadsheet invites a second look. The same wrong number inside a clean, well-written AI summary sails through review, because polish is the proxy reviewers use for care. Garbage in used to produce garbage out. Now it produces garbage with perfect formatting, at volume.

A worked example with invoices

Say your AP team handles 1,200 invoices a month through three intake channels: an email inbox, a supplier portal, and PDFs that field managers photograph and forward from their phones. About 30% of invoices mismatch their PO somehow, mostly because two long-standing suppliers format line items differently than your ERP expects. One processor works each invoice end to end and resolves most mismatches at first touch, because she recognizes the suppliers on sight.

Now bolt an extraction and matching tool onto that process exactly as it stands. The 840 clean invoices flow through beautifully and the demo looks fantastic. The other 360 land in an exceptions queue days later, in front of whoever picks up the queue, minus all the context the original processor carried in her head. Each exception now takes longer to resolve than a full invoice used to. A few near-miss mismatches auto-approve and get paid wrong, so you're also running supplier claw-backs, which is the most miserable rework in finance. Cycle time on the happy path drops impressively, total labor barely moves, and error cost goes up. Within two quarters someone asks why the AI is underperforming, and the honest answer is that the tool is doing its job on a process that needed its 30% exception branch fixed before anyone went shopping.

The cheap fix was available the whole time. Two phone calls asking those suppliers to standardize their line-item format, plus one rule about the photo-forwarding channel, would have pushed the exception rate into single digits before a single vendor demo.

Why smart teams bolt it on anyway

Some of it is default settings. Gartner expects 40% of enterprise applications to include task-specific AI agents by the end of 2026, up from under 5% in 2025. Automation now arrives inside software you already own, one release note at a time, so there's no procurement moment forcing anyone to ask whether the underlying process deserves to run faster. The agent just shows up in the ERP.

Adoption is also running way ahead of integration. The U.S. Chamber of Commerce found that 58% of small businesses now use generative AI, up from 40% in 2024. That's a lot of tools in a lot of buildings. In most companies I talk to, though, the tools sit beside the workflow rather than inside it. A drafting assistant here, a meeting summarizer there. Each one is individually useful, and none of them is wired into how work moves between people, which is exactly the divide the MIT researchers were describing.

And some of it is honest fear of falling behind. In the same IBM survey, nearly two-thirds of CEOs admitted they invest in new technology before they have a clear understanding of its value. I don't judge the instinct. But it produces a predictable behavior where the AI project starts because it can start, while the process work never starts because it has no vendor, no demo, and no launch date. Nobody gets applause at a board meeting for deleting an approval step, even when that's the most valuable change available.

The sequence: map, remove, standardize, then automate

Here's the lightweight version I'd run on any workflow before an automation dollar gets spent. It's deliberately simple, because the sophistication belongs in the build, later.

1. Map the process as it actually runs. Skip the SOP and skip what the manager remembers in a meeting. Sit with the two or three people who do the work and walk through the last ten real instances end to end. Write down every input, every handoff, every decision point, and every spot where someone says well, usually, except. Count the exceptions honestly. Ninety minutes per process is usually enough, and it's the highest-leverage ninety minutes of the entire effort.
2. Remove the steps that shouldn't exist. Mature processes accumulate scar tissue. An approval added after an incident in 2019 that nobody can describe anymore. A weekly report nobody opens. Data typed twice because two systems stopped syncing during a migration and everyone just adapted. Kill these before optimizing anything, since a deleted step is the only form of automation that never produces a wrong output. This is the part of Hammer's argument that survives fully intact. Before speeding a step up, ask why it exists at all.
3. Standardize the inputs. A surprising share of what gets blamed on model accuracy is really input chaos. Collapse intake to one channel where you can. Require the fields you need at the door and bounce what's malformed. Template the recurring documents. If suppliers send invoices six different ways, a phone call that fixes three of them will do more for extraction accuracy than any amount of prompt engineering.
4. Automate what remains, against a defined outcome. Pick the metric before the build: cycle time, touches per item, error rate, whatever fits. Route exceptions to a named person rather than a shared inbox. Instrument the thing so you know within a month whether the metric moved. In most stalled pilots I've looked at, nobody had written down what success would measure, which made success unfalsifiable and the pilot unkillable.

None of this is proprietary. Hammer would recognize every step from 1990. We run a formalized version of this sequence as the front end of our PATH audits at FirmAdapt, and the honest truth is that the whiteboard edition catches most of what matters for free.

A quick readiness test

The compressed version is five questions you can ask about any workflow that's a candidate for AI:

• Can the person who owns it describe the happy path in under a page?
• Do you know the actual exception rate from counting it, and is it under roughly 20%?
• Does every handoff have a named owner on both the sending and receiving side?
• Do inputs arrive in a predictable format through a known channel?
• Can you state, in one sentence, the metric the automation has to move?

Two or more noes means the process needs work before it needs software. The useful part is that each no points straight at its own repair. A fuzzy happy path means go map it. A high exception rate means find the top two causes and kill them at the source. Unpredictable inputs mean standardize intake. No metric means you'd be building something you can't evaluate, so define what better looks like before anyone opens a vendor deck.

What to do Monday morning

Pick the one workflow people complain about most. Book ninety minutes with the two people who actually run it and map the last ten instances the way I described. Then run a one-week tally. Every time an instance leaves the happy path, someone makes a tick mark and writes three words about why. A shared note or a piece of paper taped to a monitor genuinely works. By Friday you'll have your exception rate and your top three causes, which is more process intelligence than most AI pilots ever collect.

Then delete one step, standardize one input, and measure for another week. Decide about automation after that, with real numbers in hand. Sometimes the cleanup makes the automation case stronger and the build simpler, because the tool only has to handle work that deserves to exist. Sometimes the cleanup captures most of the value by itself and the software can wait a quarter. Either way, you stay out of the failure pattern MIT documented, where a capable tool gets bolted onto an unexamined workflow and the mess just runs faster. Ninety minutes and a tick sheet are cheap insurance.