How do you decide what to automate first?
Work out why the work exists before you work out how to speed it up. A large share of the tasks that look like obvious automation candidates are there to absorb a failure somewhere upstream, and automating those makes the failure permanent and cheaper to ignore.
Written for transformation, operations and automation leaders holding a backlog of candidates. Reviewed .
The question that gets skipped
Most automation backlogs are ranked by effort and volume: how many times a month does this happen, and how hard would it be to build. Both are reasonable questions and neither is the first one.
The first question is why the work exists. A task that runs two hundred times a month is a strong candidate on volume alone, but if a hundred and twenty of those runs exist to correct something that went wrong earlier, the volume is a symptom. Automating it removes the pain that would otherwise have forced someone to fix the cause.
John Seddon named this failure demand: demand created by a failure to do something, or to do it right, for the customer. It is worth separating from genuine demand before ranking anything, because the two call for opposite responses.
A workable order
The sequencing heuristic usually written as eliminate, simplify, integrate, automate has been part of process redesign practice for decades, and it survives because the order is doing real work. Each step is cheaper and more durable than the one after it.
- Eliminate. Can this stop entirely? Trace the step to the requirement it serves, then check whether the requirement still holds. Policies outlive their reasons, and steps outlive the policies.
- Simplify. If it has to happen, does it have to happen this way? Approvals that nobody has ever rejected, checks duplicated by a later check, and forms with fields no one reads are all removable without any technology.
- Integrate. If it has to happen this way, can two systems talk instead of a person carrying data between them? This is often mistaken for automation, and it is usually the better answer.
- Automate. What is left is the honest candidate. It is a smaller list than the one you started with, and the things on it stay useful for longer.
Why the order gets reversed in practice
Automation is the step with a vendor attached. Elimination has no product, no licence and no implementation partner, so nobody arrives at your door offering it, and it does not appear in a tool evaluation.
It is also the step that requires an uncomfortable conversation. Removing a check means someone accepting the risk of not doing it. Removing a report means telling its recipient that nobody reads it. Automating the same check or report avoids both conversations while looking like progress, which is exactly why it is so often chosen.
The evidence you need to decide
The decision is not hard once you can see three things at once, and hard to make responsibly when you cannot.
- What the step is for. The requirement, policy, contract or standard that the step exists to satisfy, so you can ask whether it still applies rather than assuming it does.
- What actually happens. The real sequence including the workarounds, not the version in the procedure document, because the gap between them is usually where the removable work lives.
- What it is connected to. Which systems, teams and downstream steps depend on this one, so that removing it is a decision rather than a surprise.
A cheap test before you build
Ask the people who do the work what would happen if the step simply stopped next Monday. The answers sort themselves quickly. Some steps have a clear and immediate consequence. Some have a consequence that turns out to be a preference. And some produce a long pause, which is its own kind of answer.
Then ask who would notice. A step whose output has no identifiable reader is not a candidate for automation. It is a candidate for deletion, and deleting it costs nothing to try, because you can always start it again.
Where a model of the work helps
The reason this ordering is skipped is rarely disagreement with it. It is that answering the three evidence questions for every candidate is slow, and the automation backlog has a date on it.
That is the gap Valstra built Omni to close: a model that holds processes, the systems they run on and the documents that govern them together, so the requirement behind a step and the things that depend on it are visible at the same time as the step itself. The ordering above does not need a product, and it works with a whiteboard. It just needs the evidence to be reachable in less time than the shortcut takes.
Common questions
- Is this an argument against automation?
- No. It is an argument for automating a shorter and better chosen list. Work that survives elimination and simplification is usually worth automating properly, and the business case for it is stronger because nobody can later ask why you automated something that should have stopped.
- What is failure demand?
- Demand created by a failure to do something, or to do it right, for the customer. The term is John Seddon's. A chase-up call about an order that was never confirmed is failure demand; the original order is not.
- How do we tell failure demand from real demand?
- Sample the work and ask, for each item, what would have had to happen for this to never arrive. If the answer names something inside your own organisation, it is failure demand. It is a rough test and it is usually enough to change the ranking.
- Our backlog is already approved. Is it too late?
- Applying the question to the top three candidates costs a conversation each. If it changes nothing you have lost an afternoon, and if it removes one of them you have saved a build and everything that build would have locked in.
See it against your own processes
A demo runs on your material, not a canned dataset. Bring a process you find hard to explain.