What to automate first, and what to leave alone
When a business decides to automate, the candidate process is usually the one people complain about most. That is a reasonable place to start looking and a poor place to stop, because the most irritating process and the most automatable process are rarely the same thing.
Frequency matters more than complexity
A complicated process that runs twice a month is a worse candidate than a trivial one that runs four hundred times a day. The return on automation is roughly the time saved per run multiplied by the number of runs, and the cost is roughly proportional to how many rules and exceptions have to be encoded. High frequency and low complexity is where those two curves separate most favourably.
This is counter-intuitive in practice, because the complicated monthly process is the one that hurts. It occupies a senior person for two days and everyone remembers it. The four-hundred-times-a-day task is invisible precisely because it has been absorbed into everyone's routine.
The three questions worth asking
- How often does it run, and how long does each run take? If nobody can answer this, measure before building anything.
- Is the decision in the middle of it rule-based or judgement-based? Rules can be encoded. Judgement can sometimes be supported, rarely replaced.
- What happens today when it goes wrong? A process with no defined failure path will not acquire one by being automated — it will just fail faster.
Processes that resist automation
Some processes look automatable and are not. The clearest signal is when the people who run it cannot describe it the same way twice. That usually means the real process contains judgement that has never been written down, and encoding it produces a system that is right most of the time and wrong in ways nobody can predict.
The second signal is a process that exists to compensate for a different broken process upstream. Automating a reconciliation step makes the reconciliation cheaper; it also makes the underlying divergence permanent, because the pain that would eventually have forced a fix has been removed.
Map before you build
The single highest-value step is writing the process down as it actually happens, including the workarounds. Not the documented version, and not the version described in a meeting — the version that includes the spreadsheet someone keeps on their own machine, and the message they send when the system says no.
This exercise routinely changes what gets automated. It also frequently reveals that two steps can be deleted rather than automated, which is a better outcome and a cheaper one.
Start where failure is survivable
A first automation should be something that, if it breaks at 3am, costs an inconvenience rather than an incident. That is not timidity: the first project is where the team learns how the integration behaves, where the edge cases live, and how the monitoring should work. Learning those things on a process that cannot fail safely is an expensive way to find out.