Automation Without Redesign Just Makes Bad Processes Faster
- Jerry Justice
- 10 hours ago
- 7 min read

A finance team spends nine days closing the books. Three approvals get routed to people who never actually check anything, they just forward the email because that's the step their predecessor taught them. Someone built a shadow spreadsheet years ago to catch errors the system keeps producing, and now three people quietly maintain it because nobody trusts the official report.
Leadership looks at this and reaches the obvious conclusion. Automate it.
That instinct is understandable. It's also, more often than not, the wrong move made at the wrong time.
Automation Without Redesign Just Moves the Problem Faster
Automation without redesign doesn't remove the broken parts of a process. It just moves them faster, with less visibility, and with far more confidence that they're now correct.
The nine-day close doesn't become a two-day close because a bot now routes the approvals. It becomes a two-day close where the same unnecessary sign-offs happen in minutes instead of days, and the shadow spreadsheet still exists because nobody addressed why the official numbers needed correcting in the first place. Michael Hammer identified this exact trap more than three decades ago in Reengineering Work: Don't Automate, Obliterate, the Harvard Business Reviewarticle that gave the reengineering movement its name. His finding still holds today. Most organizations use technology to speed up processes and rules that are decades out of date rather than break away from them, and speeding up an outdated process rarely produces the dramatic improvement leadership expects. That's not a technology failure. That's a sequencing failure.
Russell Ackoff, the systems thinker who spent much of his career at Wharton studying why organizations solve the wrong problems well, put the underlying principle better than most in Why Doing the Wrong Thing Right Makes It Wronger, a piece built around a recorded Ackoff interview. "It is much better to do the right thing wrong than the wrong thing right," he said. The tighter and faster an organization executes a process aimed at the wrong outcome, the harder that outcome becomes to unwind later.
Why the Instinct to Automate Shows Up First
Executives don't reach for automation because they're careless. They reach for it because it looks like decisive action.
Redesigning a process means admitting the current one doesn't work, then doing the harder work of figuring out why, who owns each step, and which approvals exist for a real reason versus which ones exist because nobody ever removed them. That work is slow, political, and hard to show on a slide.
Automating the process as it stands looks like progress. A vendor demo, a pilot, a launch date. It gives leadership something to announce well before anyone has answered the question that actually matters, which is whether the process deserves to move faster in the first place.
I have watched this exact substitution happen inside operations functions that had every reason to know better, and the pattern is consistent. Automation gets treated as the fix instead of the amplifier it actually is.
W. Edwards Deming named the deeper failure at a February 1993 seminar in Phoenix, in a line The W. Edwards Deming Institute still cites directly: "A bad system will beat a good person every time." Automating a bad system doesn't give good people a fairer fight. It gives the bad system a faster one.
The Approval That Exists to Look Like Control
Approvals deserve their own scrutiny, because they're among the easiest steps to automate and among the hardest habits for an organization to question.
There's a real difference between meaningful control and ceremonial approval. Meaningful control reduces an actual risk, applies real expertise, or places a decision with someone who holds legitimate authority over it. Ceremonial approval just moves the transaction through another inbox so someone can say they looked at it. Automation can remove the friction of a ceremonial approval in seconds. Redesign is what asks whether that approval should have survived at all.
That distinction matters because removing an unnecessary approval usually means confronting a question about trust, authority, or organizational power, and configuring software to route that same approval faster is a way of avoiding the conversation rather than resolving it. The organizational question doesn't disappear when it gets automated. It just moves inside the workflow where it's harder to see.
What Redesign Before Automation Actually Requires
Getting the sequence right starts with three questions that have nothing to do with technology:
What is this process actually trying to accomplish, stated in outcome terms rather than task terms?
Which steps exist because of a real control requirement, and which exist because someone added a workaround years ago that never got removed?
Where do humans currently improvise, override, or route around the official steps to get work done?
Skipping straight to automation without redesign is what turns that third question into next year's incident report instead of this quarter's fix. Every workaround your team has built is a signal that the documented process doesn't match how the work actually gets done. Shigeo Shingo, whose work on the Toyota Production System shaped much of modern lean practice, made the same point about waste in general in Non-Stock Production: The Shingo System of Continuous Improvement: "The most dangerous kind of waste is the waste we do not recognize." A workaround nobody has mapped is exactly that kind of waste. Automate before finding it, and the automation will either break the moment it meets a real-world exception, or it will faithfully replicate a shortcut that was never supposed to become permanent.
Telling the Difference Between Ready and Just Modern Looking
Not every process needs a redesign before it can be automated. Some are genuinely clean, well-documented, and consistent, and automation is the right next step. The challenge for leaders is telling the two apart before committing budget and credibility to the wrong one.
A process is ready for automation when the steps are documented rather than tribal knowledge, the exceptions are known and finite rather than discovered as they occur, ownership of each handoff is clear, and the team can explain why each approval exists in terms of an actual risk it controls.
A process is not ready when people can't agree on how many steps it actually has, when workarounds outnumber the documented steps, when approvals exist because "that's how it's always been done," or when the team has never once tried running the improved version manually before asking for it to be built into software. Taiichi Ohno, the engineer credited with building the Toyota Production System, is remembered for a line the Lean Enterprise Institute has built much of its problem-solving teaching around in spirit if not always word for word: "Having no problems is the biggest problem of all." A team that insists its process has nothing wrong with it is usually a team that has stopped looking. That's the team least ready to automate, not the most.
The honest signal that a process just needs to look modern rather than actually needs automation is when the case for it rests entirely on speed. Speed is a fine outcome. It is a poor starting justification, because a faster version of a broken process is still broken, just less visible about it.
Why AI Raises the Stakes on Sequence
This problem gets more consequential, not less, as artificial intelligence enters the picture. McKinsey examined exactly this gap in The Operating Model Advantage: Why AI Winners Are Rewiring Their Organizations, published in July 2026. The firm found that top performers, defined as companies attributing 5 percent or more of EBIT to AI, are three times more likely to pursue broad operating-model redesign, and twice as likely to redesign their workflows before selecting AI tools at all. Roughly 79 percent of companies skip that redesign step, and McKinsey identifies it as the single factor most strongly correlated with actual financial impact from AI.
The reason is structural. As organizations grow, coordination costs, the review boards, approval layers, and cross-functional committees, keep climbing even after revenue growth flattens out. AI can compress that coordination layer directly, but only if the workflow gets rebuilt around it rather than laid on top of it. Toyota's own resource-allocation process is a useful example. Matching production capacity to demand across suppliers and plants had become a coordination-heavy exercise involving dozens of spreadsheets and weeks of manual reconciliation. Toyota didn't automate that process as it stood. It rebuilt the workflow first, then let AI pull the demand data and walk planners through scenarios in minutes, and the planning team shrank by more than 80 percent through redeployment rather than automation-on-top-of-chaos.
The Board Level Version of This Problem
This isn't only an operations question. It's a capital allocation question, and boards should treat it as one.
Every automation initiative competes for budget, technical talent, and executive attention against other priorities. When that investment goes toward preserving a flawed process at higher speed, the organization doesn't just fail to gain the promised efficiency. It locks in the dysfunction behind a layer of software that's far more expensive and disruptive to unwind later than the manual process ever was. Fixing a workflow is hard. Fixing a workflow after three years of automation vendors, connected tools, and dependent systems have been built around it is a different order of difficulty entirely.
Leaders who ask for the redesign case before approving the automation budget aren't slowing progress. They're protecting the organization from paying twice, once for automation without redesign and again for the redesign it should have had from the start.
The order matters more than the technology choice. Redesign first. Automate second. Every time leadership reverses that order to save a quarter, the organization pays for it later with interest.
ACG Services
ACG works with operations and technology leaders to separate the processes that are genuinely ready for automation from the ones that only need to look modern. Whether the challenge is a workflow buried under years of workarounds or a board asking hard questions about a stalled AI initiative, our team brings the structured redesign discipline that has to come before the technology decision. If your organization is evaluating automation, AI, or broader process modernization and wants a clear-eyed read on whether the underlying workflow can support it, visit us at aspirations-group.com to start that conversation.
Stay Connected With ACG Strategic Insights
ACG Strategic Insights delivers daily perspective on leadership, operations, and strategy for executives building organizations that last. Subscribe here to get tomorrow's insights in your inbox.
Thanks for reading!
~ Jerry Justice
Living to Serve, Serving to Lead™




Comments