Identifying Automation Candidates
The signals that mark a step as automatable, the ones that mislead, and why fixing the process usually beats automating it.
Analysis
Process and task mining are frequently bought to feed an automation programme. The data does identify candidates, and it also identifies steps that should be removed rather than automated.
The signals
High volume, obviously.
Low variation. A step performed identically every time.
Rule-based decisions, where the outcome follows from the inputs.
Copy and paste between systems, which is the clearest signal available and comes only from task mining.
Retyping data that already exists in another system.
Short duration, high frequency, which is where the aggregate time hides.
The signals that mislead
Long duration, which frequently means waiting rather than working and cannot be automated away.
High variation, which usually means judgement and automates badly.
A step everyone complains about, which may be unpleasant rather than automatable.
A step that is slow because the previous one was wrong, where automating it entrenches the error.
Volume alone, without checking whether the step should exist.
The prior question
Should this step exist at all?
A step that only exists because two systems do not talk to each other should be replaced by an integration, not by a robot pretending to be a person.
A reconciliation that exists because data is entered twice should be removed by entering it once.
A check that catches errors from an upstream step should be replaced by preventing the error.
Automating a step that should be eliminated locks in the waste and makes it harder to remove later, because now there is a robot to decommission.
Sizing the candidate properly
Frequency times duration gives the gross time.
Subtract the exception rate, since automation typically handles the standard path and returns the rest to people.
Subtract the handling of the returned exceptions, which is frequently the slower work.
A step with a twenty percent exception rate delivers far less than its volume suggests, and this is where automation business cases most often overstate.
What the data gives an automation project
The exact click sequence, from task mining, which is the specification.
The variant list, which defines what the automation must handle and what it will not.
The exception rate and its causes.
The volume by hour, which sizes the capacity needed.
A baseline to measure against afterwards, from the same log.
Measuring afterwards
The same log, the same query.
Cases handled without human touch, as a proportion.
Exception rate, which usually rises above the estimate.
Cycle time for automated against manual cases.
Total effort, including the exception handling, which is the honest measure and the one most often not taken.
The exception rate discount
Where automation business cases most often overstate.
Automation handles the standard path and returns the rest.
Take the variant coverage: what proportion of cases follow the path being automated.
Subtract the exception handling effort, which is frequently slower per case than the original manual work because context has been lost.
A step with a twenty percent exception rate delivers far less than its volume implies, and the returned exceptions land on the same team.
Model both and present the net, which is the honest figure.
Removing rather than automating
The question to ask before every candidate.
Does this step exist because two systems do not talk to each other? Then the answer is an integration.
Does it exist because data is entered twice? Then enter it once.
Does it check for errors from an upstream step? Then prevent the error.
Does anyone use its output? Frequently no, and the step has outlived its purpose.
Automating a step that should be eliminated locks in the waste and adds a robot to decommission later.
Testing a candidate honestly
High frequency and repetition make something look automatable. Four checks before committing.
Is the input structured and stable? Automation over a screen that changes breaks constantly.
Is the decision rule explicit? Steps that look mechanical frequently carry judgement nobody wrote down.
What proportion of cases follow the path exactly? Automating the happy path leaves the exceptions, which were the expensive part.
Would fixing the upstream cause remove the step entirely? Frequently yes, and that is a better answer than automating it.
Automating a step that should not exist is the most common expensive mistake this field enables.