Before you automate anything

Four questions worth answering about a process before you spend a dollar automating it. Most of the automation projects we are asked to rescue skipped at least two of them.

Automation is the easiest technology decision to get wrong, because the pitch is always the same and it is always appealing: the computer does the boring part, your people do the valuable part. That is genuinely what happens when it works. It is also exactly what is promised when it does not.

The difference is almost never the technology. It is whether the process underneath was worth automating in the first place.

1. Does this process actually happen the same way twice?

Ask three people who do the job to describe it. If you get three different answers, you do not have a process yet, you have a habit. Automating a habit locks in whichever version the loudest person described.

This is the single most common reason automation projects disappoint. The system works precisely as specified, and the specification was one person's account of a job that four people do differently.

2. How often does it run, and how long does it take?

Write down the real numbers. Forty invoices a week at six minutes each is four hours. That is worth automating. Four invoices a week at six minutes each is twenty-four minutes, and no automation will ever pay that back.

The tasks people complain about loudest are often not the tasks costing the most. Measure before you decide.

3. What happens when it goes wrong?

Every process has exceptions. The supplier who invoices in a different format, the customer with the non-standard agreement, the job that needs a manager's judgement. Before you automate, list them and decide who handles each one.

A system that handles ninety per cent of cases and routes the rest to a named person is a good system. A system that handles ninety per cent and silently mishandles the rest is worse than doing nothing, because now nobody is checking.

4. Who owns it after we leave?

Processes change. Pricing changes, suppliers change, the rules change. If no one inside your business can adjust the automation, it will slowly drift out of step with how you actually work, and eventually someone will start doing it by hand again "just for now".

Decide up front who owns it, make sure they were in the room during the build, and make sure they have documentation they can actually use.

The short version

If a process is consistent, high volume, has known exceptions and a named owner, automate it. If it fails any of those, fix that first. The fixing is usually cheaper than the automation, and occasionally it makes the automation unnecessary.