Automation makes work happen faster. That only helps if the work makes sense in the first place.
Say an employee copies the same customer information into three systems. Automating that task would save time and reduce manual errors. On the surface, it’s an obvious win.
But I’d want to understand why three systems need the same information. Which one owns the record? What happens when they disagree? Does each system genuinely need a copy, or is the employee compensating for an integration that was never built?
If we automate the copying without answering those questions, we haven’t fixed the operating problem. We’ve made the workaround faster and harder to see.
That’s the risk. Automation doesn’t just scale efficiency. It scales the decisions, assumptions, and workarounds already built into the process.
How reasonable processes become messy
Most inefficient workflows weren’t designed badly from the start.
A step was added because a system couldn’t do something. An approval prevented a costly mistake. A spreadsheet gave one team information it couldn’t get anywhere else. Someone started producing a report because a leader needed it every Friday.
Each decision probably made sense at the time.
Then the systems changed, the people changed, and the original constraint disappeared. The workaround stayed. New employees learned it as part of the job, and eventually the company stopped seeing it as a workaround at all.
Now AI can perform many of these tasks, so the temptation is to hand the existing process to a tool and call the result efficiency.
That may relieve an immediate pain point. It can also preserve years of accumulated friction without asking whether the work still deserves to exist.
Find the friction beneath the task
When I map how information and work move through a company, I tend to find three kinds of friction.
The first is information friction. Someone has to search several systems, compare conflicting records, or ask around before they can begin the work they were actually hired to do. Automation may help gather that context, but the better answer might be establishing one reliable source.
The second is workflow friction. People repeat predictable steps, route routine requests, or wait for approvals that rarely change the outcome. Some of this work is a good candidate for automation once the normal path and the real exceptions are clear.
The third is structural friction. Several teams, products, or business units maintain separate versions of the same capability. Each process may look reasonable on its own. The duplication becomes visible only when you compare them.
Structural friction is where automation can create the most expensive illusion of progress. Improving each process separately feels productive, but the company ends up investing in faster versions of the same overlapping work.
Consolidation changes what is possible
I saw this while working with a consumer technology company that supported three related digital products.
Each product had developed its own support workflows, content, reporting, product knowledge, and operational habits. We could have improved or automated each operation separately. That would have saved time within each team, but it also would have reinforced three versions of a capability the company largely shared.
Instead, I worked to understand what was genuinely different and what had simply developed separately.
The common work moved into a shared product model. Differences that mattered to the individual products remained as exceptions. We didn’t force everything into one identical process, but we stopped treating every historical difference as a permanent requirement.
That work reduced duplicated workflows by roughly 60 percent. Reporting overhead fell by about 80 percent, and roughly 70 percent of the system moved onto shared infrastructure.
The important choice happened before any automation. We defined the shared capability, decided where variation was necessary, and established ownership around the common work.
After that, future improvements could be built once and used much more broadly.
Some work should simply stop
Consolidation isn’t always the answer. Some processes have outlived their purpose and should end.
A weekly report may continue even though nobody uses it to make a decision. An approval may remain because of a failure that hasn’t happened in years. A team may still copy information into a spreadsheet because an old system once lacked a field that was added three versions ago.
Automating this work makes it cheaper, but it also lets the work survive without scrutiny.
So before deciding how to automate a process, I ask why it exists. Then I follow the answer to the business outcome.
What decision does this report support? What risk does this approval control? Why do three teams maintain the same information?
If the report no longer supports a decision, stop producing it. If an approval exists to catch one unusual situation, route that exception instead of slowing every normal case. If several teams maintain the same information, establish shared ownership instead of automating several maintenance processes.
Removing unnecessary work often creates value faster than automating it. It also leaves the company with fewer systems, rules, and exceptions to support later.
A shared location is not a shared capability
Companies sometimes respond to fragmentation by moving everything into one place. That can help, but centralization alone isn’t redesign.
A company can put hundreds of support articles into one repository and still have no clear owner for keeping them current. It can move every process into a shared workspace while employees continue following undocumented exceptions. It can consolidate reporting into one dashboard without agreeing on what decisions the numbers should drive.
The information is together, but the operating problem remains.
A shared location becomes useful when ownership and execution change with it. Someone needs to decide what is authoritative, how it gets updated, how disagreements are resolved, and how the information reaches the next person or system that needs it.
Without those decisions, automation simply gets a cleaner place to find stale or conflicting information.
Fix, remove, then automate
The sequence I use is straightforward.
First, map what the business knows and how the work actually happens. Look across the people, systems, decisions, and handoffs involved. Then identify the friction beneath the visible task.
Simplify what has become unnecessarily complicated. Consolidate work that belongs together. Remove work that no longer produces a useful outcome. Once that is done, automate what remains.
That sequence usually changes the opportunity.
Instead of building an agent that searches five systems, the company may establish one reliable source and connect it to the workflow. Instead of automating three versions of a report, it may create one shared decision process. Instead of teaching AI every exception in a long approval chain, it may remove the approvals that no longer protect anything.
The automation that remains is smaller, clearer, and easier to trust because it reflects a process people can understand.
Automation is a multiplier. Before using it to scale the work, make sure you’re comfortable scaling the operating choices underneath it.