You want to automate a workflow, and every supplier you speak to insists on mapping it first. It feels like a way of adding a phase, charging for discovery, and delaying the thing you actually asked for.
The reason is not process theatre. Automation copies what you do exactly, at speed and without judgement, including the steps that are wrong. A broken process automated is a broken process that now fails four times faster and with more confidence, and nobody notices until the mistakes arrive in volume.
What automation actually does to a bad process
- It removes the human who was silently fixing things. Almost every manual process contains someone who spots the obvious error, chases the missing field or knows that this customer is an exception. Automate around them and that correction disappears, along with the knowledge that it was ever happening.
- It hardens the wrong rule. A rule that was a convention becomes a constraint. Nobody can quietly do it differently for the one case where quietly doing it differently was correct.
- It multiplies the error rate. A step that is wrong two per cent of the time, done twenty times a day by hand, is a manageable irritation. Done two thousand times automatically, it is a project to unwind.
- It makes the process harder to change, because now changing it means changing software rather than telling three people something.
- It hides the process. Once it runs by itself, nobody watches it, and a process nobody watches drifts out of correctness without announcing it.
Map, simplify, then automate
Three steps, and the middle one carries almost all the value while being the one that gets dropped when a deadline appears.
- Map what actually happens. Not what the manual says, and not what the manager describes. Sit with the person doing it and write down every step including the ones they apologise for. The workarounds are the most valuable part of the map, because each one is a fault somebody has been absorbing.
- Simplify. Remove steps that exist for a reason that has gone, merge approvals that always approve, delete the field nobody reads, stop producing the report nobody opens. This step frequently delivers most of the benefit for no software spend at all, which is why suppliers who skip it are not acting in your interest.
- Then automate what remains. Which will be a smaller, cheaper and more reliable thing than what you were about to buy.
The uncomfortable implication is that step two often makes the project smaller. We have run mappings that removed the justification for the automation entirely, and told the client so. That is a good outcome for them and a smaller invoice for us, which is precisely why it needs saying out loud.
How to map it in an afternoon
- Follow one real item end to end. One order, one claim, one tenant. Not the general case, an actual one with a name on it.
- Count the handoffs. Every time it moves between people or systems is a place it can wait, and waiting is usually a bigger cost than doing.
- Ask why at every step, twice. The first answer is what the step does. The second is why, and it is frequently because of something that stopped being true.
- Find where things wait. The step that takes four minutes and sits in a queue for two days is the one to fix, and automating the four minutes changes nothing.
- Note every exception. How often, what happens, who decides. Exceptions are where automation projects break, and they are always more common than the first estimate.
- Ask what would happen if this step disappeared. The answers are surprising often enough to be worth the awkwardness.
Keep a human where judgement lives
Simplifying is not the same as removing people from everything, and the distinction matters.
Automate the fetching, the copying, the reminding, the formatting and the filing. Keep a person for anything committing you to money, anything with legal effect, anything a customer will act on, and anything where the cost of being wrong is not symmetric. The pattern that works nearly everywhere is that the software prepares and a person approves, which removes the tedium without removing the judgement.
The failure mode to avoid is a rubber stamp: an approval step that everyone clicks through without reading is worse than no approval, because it creates the appearance of oversight. If a checkpoint is always approved, either remove it honestly or make it show the reviewer something worth looking at.
What good simplification looks like
Since simplify is the vaguest of the three words, here is what it means in practice. These are the changes that come up most often, and almost none of them need software.
| What you find | What is really going on | The change |
|---|---|---|
| An approval that is always granted | It was added after one incident years ago, and it now costs a day of waiting for a decision nobody has ever refused. | Remove it, or convert it to a notification so somebody can object rather than everybody having to wait. |
| The same information entered twice | Two systems that were never connected, and a person acting as the connection. | Connect them, which is the one item here that genuinely needs software. |
| A report produced weekly | Somebody asked for it once, that person has left, and it is still being made. | Stop producing it for a month and see who asks. Frequently nobody does. |
| A step waiting on one named person | A bottleneck disguised as a quality control, usually because nobody else was ever trained. | Widen it, or agree a time limit after which it proceeds anyway. |
| A field that is always the same value | It was needed for a customer or a rule that no longer applies. | Default it, or delete it. Every field you collect is a tax on whoever fills it in. |
| An exception handled by one person's memory | Genuine knowledge that exists nowhere else and disappears when they are on holiday. | Write it down first. Only then decide whether it is a rule or a judgement. |
Five of these six cost nothing and can be done next week. The habit worth building is running this exercise annually rather than only when you are about to buy something.
Automations break, and quietly
Worth planning for, because this is the second most common way these projects disappoint.
- Vendors change their interfaces, usually with notice that went to somebody who has left. Your automation stops, or worse, keeps running against a changed meaning.
- Credentials expire, or someone rotates a password without knowing what depended on it.
- Unexpected data arrives and the automation stops rather than guessing, which is correct behaviour and still needs somebody to notice.
- A required field appears in one system that the other never sends.
- The silent failure is the dangerous one. An automation that stops loudly is an inconvenience. One that keeps running and produces wrong output is a problem you find in an audit.
So budget for alerting to a named person, a readable record of what failed and why, and a safe retry that does not duplicate anything. Those are not extras, they are what makes the automation trustworthy enough to stop checking by hand, which was the point.
Not for you if
The question worth asking before automating anything: if this process were done perfectly by hand, would it still be worth doing? If the honest answer is no, automating it makes you efficient at something you should stop.