How to Document a Process Before You Automate It

Automating a process you do not fully understand does not make it better. It makes the confusion faster. The most common reason automation projects disappoint is not the technology. It is that the process people described was not the process people actually follow.

Here is how to document a process properly before you automate any of it.

Watch it being done

Do not start with a workshop or a description. Sit with the person who does the work and watch. Ask them to narrate. You will see steps nobody mentioned, shortcuts, checks done by eye, and decisions made from memory. Those unwritten parts are exactly what an automation has to handle.

Capture the essentials

For each process, record what triggers it, what the inputs are, each step in order, the decisions made along the way and what rules govern them, the systems touched, what the output is and where it goes, how often it runs and how long it takes. Note who does it and who depends on the result.

Find the exceptions

The normal case is easy to describe. The exceptions are where automations break. Ask what happens when the file is late, when a field is blank, when a customer has two accounts, when the total does not match. Get real examples. If you hear that it never happens, ask when it last did.

Separate rules from judgment

Some steps follow clear rules, such as if the amount is under a limit and the vendor is approved, then post it. Others depend on a person's judgment. Rules are good candidates for automation. Judgment calls usually should stay with a person, at least at first, with the automation preparing the case for them.

Build a set of test cases

Collect real examples, including odd ones, and record what the correct outcome is for each. This becomes the test set. After the automation is built, run it against these cases and compare. It is the most reliable way to prove the automation does what the person did, and it will catch things you did not think of.

Measure the baseline

Record how long the process takes today, how often it contains errors and how many people touch it. Without this, you cannot show afterwards that the automation helped, and you will not know whether it did.

Get the process owner to sign off

Show the documented process to the person who owns it and ask them to confirm it. Corrections at this stage cost minutes. Corrections after the build cost weeks.

Decide what stays manual

Not every step needs to be automated. Sometimes the best result is automating the repetitive middle and leaving the first and last steps to a person. Be deliberate about where the human stays in the loop.

What you end up with

A one-page description of the process, a list of exceptions and how each is handled, a set of test cases with expected outcomes, and a baseline for time and errors. That is enough for a developer to build the right thing, and for you to judge whether they did.

This is the groundwork behind work like replacing weekly Excel reports with Python and automating your accounts payable process.

If you have a process you want to automate and are not sure where to begin, reach out. We start with the documentation, because it decides how the rest goes.