The most common cause of a disappointing automation project is not the technology. It is that the underlying process was never sound, and automating it simply removed the human judgement that had been quietly compensating for the design.
Three failures that survive automation
- Unclear ownership: if nobody owned the outcome before, an automated handoff has nowhere meaningful to hand off to.
- Unnecessary steps: approvals and checks introduced years ago for reasons nobody can now articulate get encoded permanently.
- Poor data at source: automation propagates bad inputs faster and further than a person who would have paused and asked.
Redesign first, and be willing to delete
Before building anything, map the process as it is actually performed and ask four questions of every step: why does this exist, what would happen if it stopped, who acts on its output, and what decision changes as a result? A meaningful proportion of steps in a mature SME process cannot survive that questioning. Removing them is free, immediate and lower risk than any automation.
Only then is it worth asking what the remaining steps require. Typically the answer is a mixture: some steps become fully automated, some become assisted with human approval, and some are best left entirely to people because judgement is the value being added.
Design for exceptions, not the happy path
Demonstrations show the clean case. Operations are defined by the rest: the malformed order, the ambiguous request, the customer who replies to a three-month-old thread. A robust design states explicitly what happens when confidence is low, where the exception queue sits, who monitors it, and how quickly a stuck item becomes visible.
A short pre-build checklist
- The current process is documented as performed, not as intended.
- Redundant steps have been removed before anything is built.
- There is one named owner for the end-to-end outcome.
- Input data quality has been checked at source.
- Exception handling, escalation and monitoring are designed in.
- A baseline measurement exists, so improvement can be proven.
Automation is an amplifier. Applied to a well-designed process it compounds quietly for years. Applied to dysfunction it does exactly the same thing — which is precisely the problem.