Process automation

Before a manual step is removed, it is worth asking what it checks. Is someone there to look at the amount, to approve, or just to copy something across? Automation is about keeping the control and removing the manual work, not removing both.

Four questions before you automate anything

1. How does the flow really work? Not according to the process description, but according to the person who does it every day. Sit next to them and watch. The difference between the two is what you are building for.
2. Which steps have rules you can write down? Those can be automated. Steps where the answer is “it depends” need a person until someone has written down what it depends on.
3. What happens with exceptions? An exception needs a way back into the flow, or it ends up in an email on the side. Build in a way to correct it and carry on.
4. Who needs to see what happened? The auditor, customer service, whoever corrects an exception? That decides what each step should log, and a history that was not written when it happened cannot be created afterwards.

Where we say no

When the process has not settled. If the rules are still changing, or nobody agrees on how the flow should work, the automation sets in stone a version that will soon be wrong. Better to simplify and agree first, then build.

We also say no when the numbers do not add up. Work out how long the step takes, how often it is done and what an error in it costs. Set that against what building and maintaining it costs. Sometimes the answer is no, and then we say so.

Automation connects to real-time data when the flow has to react to events, and to case management when an exception needs to become a case with an owner.