Part 1) Before You Automate Anything
When a process is slow, expensive or frustrating, the instinct is often to automate it - a workflow, an integration, a new system and, increasingly, AI.
But making a process happen faster doesn’t necessarily make it better; sometimes it just means unnecessary work happens faster.
Before asking “How could we automate this?”, ask two simpler questions:
- Why does this process exist?
- What value does it create?
Processes have a habit of surviving long after their original purpose has disappeared; an approval remains because something once went wrong, a spreadsheet exists because an old system couldn’t do something and a report is still produced because somebody asked for it years ago.
So try completing one sentence:
This process exists because…
Then ask what would actually stop happening if the process disappeared tomorrow.
If you can’t identify a meaningful outcome, don’t automate it; you may have found something you can simply remove.
If the process does have a legitimate purpose, the next question is different:
How much of what happens inside it is actually necessary to achieve that purpose?
Part 2) Understand What You’re Actually Fixing
Once you’ve established that a process has a purpose, look at how it achieves it - this is where complexity tends to accumulate.
Focus on four things:
- Duplication - Is the same information being entered, checked or moved more than once?
- Hand-offs - How many people, teams or systems does the work pass through before reaching the outcome?
- Exceptions - How often does the normal process fail, requiring somebody to intervene or find another route?
- Workarounds - Are spreadsheets, emails or manual steps compensating for something the process or system doesn’t do properly?
None of these automatically means the process is bad. A hand-off might provide necessary expertise, an exception might protect against genuine risk or a manual check might prevent an expensive mistake.
The important question is:
Does this step contribute to the outcome, or does it exist because of the way the process has evolved?
If most of the friction comes from moving information between systems, repeating predictable tasks or applying consistent rules, automation may help.
If the friction comes from unnecessary stages, unclear ownership or constant exceptions, redesign probably comes first.
If parts of the process no longer contribute anything useful? Don’t improve them; Remove them.
Part 3) Automate, Redesign or Remove?
By now, you should have enough information to make the decision.
The framework is deliberately simple:
- Remove it when the process, or a step within it, no longer creates meaningful value.
- Redesign it when the outcome matters but the route to it is unnecessarily complicated.
- Automate it when the process is valuable, understood and reasonably consistent, but people are spending time doing predictable work that technology could do instead.
The order matters: Remove first, redesign second and automate last.
Otherwise, you risk investing in technology to preserve complexity that shouldn’t exist.
Before approving any automation, ask:
If we were designing this process from scratch today, would we still choose to do it this way?
If the answer is no, then don’t automate it yet - simplify it first.
The best automation isn’t the one that makes a bad process faster…
…it’s the one that’s left after you’ve removed everything you didn’t need.
