We used to automate the process as we found it
A bad process running at machine speed is a bad process arriving faster. What we changed is that the description now comes before the automation.
Because automation makes an existing process faster and more consistent, including its mistakes and its unnecessary steps. If the process was carrying a manual correction somebody performed quietly, removing the human removes the correction and the errors reach the customer instead.
What we used to get wrong
We would map the process as described in the meeting and build to that map. It was efficient, the client recognised their own process, and the result was frequently worse than what it replaced.
The reason was always the same. The described process was not the real one. Somewhere in the middle a person was checking something, fixing an obviously wrong figure, or making an exception for a customer everybody knows. None of that was in the description, because it was never considered part of the job.
Where the hidden work lives
It concentrates in a few predictable places: the handover between two teams, the moment a record is copied from one system to another, and any step where somebody sorts exceptions from the ordinary flow.
Those are the same points automation is usually pointed at, because they look like the wasteful parts. Some of them are. Some of them are the quality control.
- Whatever the person fixes without mentioning it
- The exceptions handled by recognising a name
- The check that happens because of one incident years ago
- The judgement about what is urgent that nobody wrote down
How we scope it now
The first deliverable is a written description of the process as actually performed, produced by watching it rather than by asking about it. Every step gets a note on what happens when it goes wrong today and who notices.
Only then does anything get automated, and the steps that were quietly acting as checks are either kept as checks or replaced with something explicit. The automation is smaller and the result survives its first bad week.
The measure that should have been agreed first
Speed is the easiest thing to improve and the least useful thing to promise. The measure that matters is usually error rate, or the number of cases that need a human afterwards, and it should be recorded before anything changes.
Without that baseline the project can only be judged on feeling, and the feeling in month two is always that it used to be fine.
What to take from this
- 01Automation reproduces the real process, including its silent corrections
- 02Hidden work lives at handovers, copies and exception handling
- 03Describe the process by watching it, not by asking about it
- 04Record the error rate before you change anything
Ask the question directly
- Is this an argument against automating at all?
- No. It is an argument for automating the process you actually have, which is usually smaller and stranger than the one on the slide.
- How long does watching the process take?
- For a single workflow, days rather than weeks. It is far cheaper than discovering the missing check through the customers who received the output.
- What if the people doing it cannot explain their own steps?
- That is normal and it is the point. Expertise stops being conscious, which is exactly why a description gathered in a meeting is unreliable.
Related answers
AI transformation
Most AI projects fail because they add a chat box next to the problem instead of removing the step that costs the hours. We start from the workflow, and from the systems and the data underneath it.
Growth transformation
Organic accounts, reputation, lifecycle and conversion run as one programme, with fractional leadership above it for the companies that need the seniority before they can justify the salary.
Bring the decision you are stuck on
A call, forty five minutes, no deck. We will tell you if we are the wrong firm.