How We Map Your Processes Before Automating

Descriptions are always tidier than reality

Ask someone to describe their process and you get the intended version: eleven clean steps. Watch them do it and you get nineteen, four of which exist to work around something broken elsewhere.

That gap is not dishonesty. People describe processes as they were designed, and then describe away the adaptations they have made so instinctively that they no longer register as steps.

The step somebody does not mention because “it is just a quick check” is, four times out of five, the step that has to be understood before anything can be automated.

What we record for every step

• Who does it, by role and by name
• What triggers it — a time, an email, another step, someone asking
• Where the data comes from and where it goes
• How long it takes, timed rather than estimated
• How often it goes wrong, and what happens when it does
• Whether it is a decision, a transformation or a transfer

That last classification does most of the work. Transfers — moving data from one place to another — are almost always automatable. Transformations are usually automatable. Decisions usually are not, and should not be, without a great deal more care.

The exceptions column is where the value hides

For every step we ask what happens when it does not go to plan. The customer sends the wrong file. The supplier's reference does not match. The order arrives after the cut-off.

Exceptions are usually 5–20% of instances and 50–80% of the effort. A system that handles only the happy path automates the easy fifth of the work and leaves the expensive part untouched — then people invent a shadow process for the exceptions and you have two systems.

Timing the steps honestly

We time steps rather than accepting estimates, because estimates are compressed by a factor of two or three. People report the time the task takes when nothing interrupts, which is not the time it takes.

That real table came from one client's morning routine. Estimated at 3.3 hours a week; timed at 13.7. The project's business case was built on the second number, and the client's own reaction to seeing it was what got the project funded.

Turning the map into a build order

Once the map exists, sequencing is straightforward. We score each step on frequency, duration and error rate, and automate in descending order of the product of the three — subject to one rule: never automate a step whose output nobody trusts.

1. High frequency, long duration, high error rate — build first
2. High frequency, short duration — usually a quick win worth doing early
3. Low frequency, long duration — often better left manual
4. Anything involving a judgement call — assist, do not replace

What the map is worth on its own

Several clients have taken the process map, changed three things manually, and captured most of the benefit without commissioning a build. We are entirely happy with that outcome — it is a genuine result and it makes the eventual build better when it comes.

The map is yours either way. It is a document, not a hostage.

Frequently asked questions