How to automate manual processes, step by step

To automate manual processes well, the order matters more than the tool: describe the process, separate the handling from the judgement, and only then build the narrowest version that can be checked against how it is done today. Teams that start with a tool tend to automate the step that was easiest to demonstrate, not the one that was costing them time.

What does it mean to automate a manual process?

It means a system takes over the handling in a recurring process, the reading, matching, checking and copying, so a person no longer carries information from one place to another by hand. It does not mean removing the people. The decisions, such as accepting a price change or approving an exception, stay with the people who are paid to make them.

If you are still deciding which processes qualify, five manual process examples shows the common shapes, and the questions in what to automate first sort the list.

How do you automate a manual process, step by step?

1. Write the process down as it runs today

List what comes in, what goes out, who touches it and in what order. Include the steps nobody mentioned because they have always been part of the job. This document is usually where the work turns out to be, and it is rarely where the complaints were.

2. Split the handling from the judgement

Mark every step as either handling or judgement. Handling follows rules that could be written down. Judgement needs a person who knows the context. Only the first kind is a candidate, and a process where most steps are judgement is a poor first project.

3. Name the cases the system cannot decide

Before building anything, list the situations where the system should stop and hand the case to a person: a value it cannot read, a record it cannot match, a change outside an agreed range. Writing this list first is what makes the finished system trustworthy rather than merely fast.

4. Build the narrowest version first

Build one input type and one output, not the whole process. Keep the output reviewable: a file or a screen a person checks, rather than a change written straight into a live system. Nothing should write to a system of record until that has been agreed and tested.

5. Run it beside the manual version

Compare its output with what the person produces on the same input, and look at every difference. A difference is either a fault in the system or a rule nobody had written down. Both are worth finding before anyone relies on it.

6. Keep a person on the exceptions

Even a good system hands some cases back. Decide who receives them and how quickly, because a queue nobody owns is how an automated process quietly becomes a worse manual one.

What goes wrong when teams automate manual processes?

Three failures account for most of it. The first is automating a step that was merely annoying, not one that was repeated and costly. The second is skipping the written description, so the system encodes one person’s habits without anyone having agreed they were correct. The third is removing the person from the decision, which means the system has to be right every time, and none of them are, so it gets overridden until people stop trusting it.

When is a consultant worth bringing in?

When the process is not yet written down, or when nobody can say with confidence which steps are handling and which are judgement. That first stage is business process automation consulting in the narrow sense used here: it comes before any build.