The mistake of automating a process that should not exist
Half the automations we are asked for stop being necessary the moment the process is drawn out. How to tell which ones are actually worth building.
The conversation usually starts the same way: “we have someone who spends two days a month copying this from here to there, can you automate it?” Almost always, yes. The more useful question is a different one: why does it have to be copied at all?
Automating the symptom
A manual handover between two systems is nearly always the scar of an old decision: two departments that bought different tools, a migration left half-finished, a report somebody asked for once that nobody dared stop sending.
Automating that handover makes it faster and cheaper, and at the same time makes it permanent. A painful manual process creates pressure to fix the cause. The same process automated stops hurting and stays forever, with its maintenance and its debt.
Three questions before writing the first flow
- Who consumes the output? If there is no clear answer, or the consumer left the company two years ago, the process does not need automating: it needs deleting.
- What decision changes because of this data? If the answer is “none, we just like having it”, the return is zero however efficient the automation.
- Why is the data not already where it is needed? Sometimes the answer reveals it can be integrated at source, and then the handover disappears rather than getting faster.
What genuinely deserves automating
Not everything is a symptom. Some repetitive work is legitimate and permanent, and there automation genuinely pays:
- Captures that today depend on somebody remembering — inspections, checklists, pre-operational checks. The value is not speed, it is that it stops being forgotten.
- Validations a person gets right 95 % of the time. The remaining 5 % usually costs more than everything else combined.
- Periodic consolidations where the process is well defined and the only manual part is running it.
- Alerts that depend on somebody looking at a dashboard. One threshold that notifies on its own is worth more than ten reports nobody opens.
The best automation is usually the one that removes the process, not the one that speeds it up. It costs less to maintain and it never breaks.
And if the process has to stay as it is
Sometimes the cause cannot be touched: the source system belongs to a third party, regulation requires it, or the cost of changing it exceeds the cost of living with it. Fine — then automate, but knowing you are buying time, not solving the problem. That distinction is worth writing down, because in three years nobody will remember why that flow exists.