Why we document the process before automating it

Every automation project we run starts with somebody watching the work happen. Not reading a process document, watching. The two are never the same, and the difference is where the project succeeds or fails.

The documented process is a description of intent

Process documents describe how the work is supposed to happen. They are written once, usually by someone who does not do the work, and they are accurate on the day they are written. Then reality applies. A system changes, a workaround is invented, a step is skipped because it was never necessary, a new check is added after something went wrong.

None of that reaches the document. Within a year it describes a process that no longer exists.

What shadowing finds

Consistently, in almost every engagement:

• Steps in the document that nobody has performed for years
• Steps performed daily that appear nowhere in the document
• A decision described as a rule that is actually judgement, with the real criteria in somebody's head
• A decision described as judgement that is actually a rule nobody wrote down
• One person doing something differently from everybody else, usually better
• A workaround for a system limitation that was fixed two years ago

Why this matters more for automation than for anything else

A human following a slightly wrong process corrects for it continuously without noticing. They see that a value looks odd and check. They notice that this client is different and adapt. Automation does none of that. It executes exactly what it was built to execute, at volume, without judgement.

Automating a broken process does not produce a broken automation. It produces a very fast broken process.

The exceptions are the actual work

The happy path is usually straightforward and takes a fraction of the build. The exceptions are where the time goes, and they are exactly what does not appear in any documentation.

So the mapping session is largely a hunt for exceptions. What happens when the field is empty? When the customer is in a different country? When the amount is over the threshold? When it is the end of the quarter? Each answer is either a branch in the automation or an explicit routing to a human, and both are fine. What is not fine is discovering them in production.

What the session produces

1. A step by step map of what actually happens, including the exceptions and who handles them
2. A data dictionary: every field, where it comes from, what it can contain, what to do when it does not contain that
3. The decision points, with the real criteria written down
4. An explicit list of what will be automated and what stays human, agreed before anything is built
5. The measurement baseline, so the improvement can be proved afterwards

The cost

Ninety minutes to half a day, depending on the process. It is the cheapest line in any automation project and the one most likely to be cut for time, which is a reliable predictor of the project going badly.