How to automate processes without making your operation more complex

The mistake is the order, not the tool

Most automation projects begin with a choice of software and end with a process that works the same as before, only now it has a licence. The order is backwards. A tool does not simplify anything: it repeats faster whatever you tell it to repeat, including the parts that should not exist.

The right order has three steps, and only the third one involves buying anything: describe, prune, automate.

Describe the process as it is, not as it should be

Write down what actually happens, step by step, with the names of who does each thing and how long each step waits. Not the official version: the real one, including the spreadsheet somebody keeps on the side because the system does not do what they need.

This step alone usually pays for itself. It is very common for the description to be the first time the whole process has existed in one place, and for two people to discover they each thought the other was doing a check that nobody was doing.

Prune before you build

Almost every process carries steps that exist for reasons nobody remembers. The usual suspects:

• The step that exists because something happened once. A mistake years ago created a control that has been running ever since, long after the cause disappeared.
• The double approval. Two signatures where the second one has never, not once, disagreed with the first.
• The report nobody reads. Easy to detect: stop producing it for a month and see who asks.
• The data entered twice. The same figure typed into two places, which guarantees that one day they will differ.

Pruning is free and it is where most of the gain is. Automating a step you could have deleted is paying to keep it forever.

What deserves to be automated, and what does not

Automate what is repetitive, what is done the same way every time, and what goes wrong out of tiredness rather than ignorance: copying data between systems, sending a document that always goes to the same place, producing a report whose shape never changes, checking that two figures match.

Do not automate what requires judgement. Deciding whether an expense belongs to a project, whether a client gets more credit, whether a difference is worth investigating — those are decisions, and a rule that pretends to make them will be wrong in exactly the cases that matter. What you can automate there is the preparation: get the decision to the right person with everything they need to decide in one minute.

The test that you did not complicate anything

It is a simple one. Explain the new process to someone who does not work in that area. If you need to explain it twice, or if the explanation contains the phrase “except when” more than once, it is not simpler: it is the same complexity with a tool on top.

The second test is who can run it. If the new process only works when one specific person is there, nothing was automated. A dependency was created.

Start where it is boring

The temptation is to start with the most visible process. It is usually the worst choice: it is the one with the most exceptions, the most people involved and the most opinions. Start with something small, repetitive and dull, finish it, and let the team see that it works. The second one is much easier to get agreed.

Three questions before automating anything

1. Can I describe this process on one page, as it really happens today?
2. Which of these steps would survive if I deleted it tomorrow?
3. Does this step need judgement, or only patience?

If the answer to the first is no, the automation project has not started yet, whatever the software says.

At FusHer Services we do this before touching any tool, because it is the part that decides whether the rest is worth it. If you want to look at one of your processes this way, write to us.