A department brings in an AI tool to speed up approvals. The tool works. Requests that took an hour to prepare now take five minutes. Three months later, approvals take just as long as before.
The tool did its job. The problem was never the preparation. Requests still waited in four queues, for three signatures, under a rule nobody could explain. All the AI did was get the work to the bottleneck faster.
That pattern is common, and it raises a question more leaders should be asking: why are we not fixing the process before we automate it?
The Idea Is Not New. The Temptation Is.
In 1990, Michael Hammer wrote in Harvard Business Review that companies were using technology to speed up old work instead of rethinking it. His advice was blunt: stop paving the cow paths. [1]
His best-known example was Ford’s accounts payable department. The company first hoped to cut headcount by about 20% through better systems. Then it rethought the work itself, changing one basic rule from “we pay when we receive the invoice” to “we pay when we receive the goods.” Where the new process ran, headcount fell by 75%. [1] The gain came from changing the rule, not from processing invoices faster.
More than 30 years later, the same lesson shows up in the AI data. McKinsey’s 2026 State of AI survey found that only 6% of organizations qualify as AI high performers. Nearly three-quarters of those high performers have fundamentally redesigned workflows because of AI. Among everyone else, about one-quarter have. [2] BCG puts it another way: it attributes roughly 10% of AI value to algorithms, 20% to technology and data, and 70% to people and processes. [3]
The organizations getting results from AI are mostly doing process work.
What Automation Does to a Broken Process
When the underlying process is unclear, inconsistent or full of workarounds, automation tends to cause five problems:
- It moves the bottleneck. Faster intake means more work arriving at the same approval step, the same specialist or the same overloaded team.
- It multiplies exceptions. A process that fails 10% of the time produces more failures at higher volume. Exceptions are often still handled by hand, so the manual workload can grow.
- It locks in workarounds. Workarounds that lived in people’s heads get built into the tool’s logic, where they are harder to see and harder to change.
- It hides the problem. When work moved slowly, people could see where it stalled. Once it runs through a system, the failure points become harder to spot.
- It blurs accountability. “The system did it” becomes the answer when a decision is wrong, and no one owns the outcome from end to end.
None of these are technology failures. They are process failures that technology made bigger.
So Why Don’t Organizations Fix the Process First?
In my experience with modernization and public-sector programs, the reason is rarely that leaders don’t know better. It is that the incentives point the other way.
Technology has a sponsor. Process work rarely does. An AI initiative comes with a budget, a vendor, an executive champion and a launch date. Simplifying a process has none of that, even though it often delivers more value.
No one owns the whole process. Each function owns its step. Intake owns intake, finance owns approval, IT owns the system. The delays sit in the handoffs between them, where no single leader has the authority to fix them.
Fixing a process means changing rules, and rules have owners. Removing an approval step or a signature means someone gives up control. Buying a tool asks no one to give anything up. It is the politically easier choice.
The documented process is not the real process. Process maps describe how work is supposed to flow. The actual work runs on workarounds, side spreadsheets and the person who “just knows.” If you automate the documented version, you automate something that doesn’t exist.
Success gets measured by adoption, not outcomes. Many AI programs report logins, users and hours saved per task. Those numbers can rise while cycle time, error rates and service quality stay the same.
What Starting With the Work Looks Like
California’s 2020 unemployment insurance crisis is a useful example, even though it came before today’s AI tools. With hundreds of thousands of claims backlogged, the state formed a strike team. Before recommending any technology, the team spent its review watching work in EDD offices, analyzing system data, reviewing training materials and interviewing hundreds of people. [4]
What they found was specific: a manual identity verification step was the largest driver of the backlog. The fix combined a new verification tool with process changes, including better metrics, outbound calls to claimants and redeployed staff. The team’s long-term recommendation was a modernization covering administrative rules, procedures, operations and technology together. [4][5]
The lesson isn’t that technology was the answer. It’s that the team found the exact point where work got stuck before deciding what to change.
Five Questions to Ask Before You Automate
Before any AI or automation project moves forward, the business owner should be able to answer these:
- Should this step exist at all? Find out where each rule, approval and handoff came from. If no one can explain why it exists, remove it before automating it.
- Where does the work actually wait? Measure waiting time, not just working time. Most delays happen between steps, not inside them.
- Who owns the outcome from start to finish? Name one accountable owner for the whole process, not just for the tool.
- What happens to exceptions? Decide how cases the tool can’t handle will be caught, routed and resolved, and who handles them.
- What will we stop doing? Write down which old steps, reports and workarounds will be retired when the new process goes live. If nothing is retired, you are adding work, not removing it.
If the answers are unclear, the project isn’t ready for automation. It’s ready for process work.
The Leadership Question
AI can make good processes remarkably efficient. It can also make broken processes fail faster, at greater scale and with less visibility. The difference is rarely the technology. It’s whether someone took the time to understand and fix the work first.
Before the next AI pilot gets approved, ask a simple question: if this process ran twice as fast tomorrow, would the outcome actually be better? If the answer is no, automation isn’t the next step. Fixing the process is.
References
- Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate,” Harvard Business Review, July–August 1990. https://folk.idi.ntnu.no/thomasos/paper/hammer_reengineering.pdf
- McKinsey, “The state of AI in 2026: On the road to ROI,” August 25, 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai
- BCG, “AI at Scale: ROI of AI.” https://www.bcg.com/featured-insights/how-to/roi-of-ai
- California Government Operations Agency, EDD Strike Team release, September 19, 2020. https://www.govops.ca.gov/wp-content/uploads/sites/11/2020/10/release.pdf
- ABC7 News, “Unemployment claims paused for 2 weeks as report reveals 600K awaiting benefits in EDD backlog,” September 21, 2020. https://abc7news.com/unemployment-california-edd-backlog-ca-where-are-my-benefits-usa/6469259/
