Before you automate: what is this process quietly catching?

When you automate a manual process you write down the steps and hand them to a machine. The steps are the part you can see, so the steps are what transfers.

The person doing that job by hand was also noticing — the order that looked odd, the name that was obviously a test entry, the invoice a decimal place out. None of that was in the process document, because nobody thought of it as part of the job. Automate the steps and you get the steps. The noticing does not come along, and nothing announces its absence.

This worksheet takes about twenty minutes and produces a decision for every catch you find.

1. Ask the person who does it one question

Not what are the steps. They will tell you the steps happily, and the steps are the part you already have. Ask:

"When was the last time you caught something?"

Then keep going: what did you stop, what looked wrong, what did you escalate, what did you fix without mentioning it?

That list is the real specification. It is usually short — three or four things — and they will describe every one of them as obvious. The obvious ones are the ones about to disappear.

2. Write each catch down in their words

One line each. Resist tidying them into policies; a catch described as "orders from that one reseller are always wrong on quantity" is more useful than "validate quantities."

| The catch, in their words | How often | What it would cost if it stopped | | ------------------------- | --------- | -------------------------------- | | | | | | | | | | | | |

If the third column is hard to fill in, that is worth knowing before you automate, not after.

3. Pick one of three options for each line — deliberately

There are three honest options, and choosing one on purpose is the exercise:

1. Encode the check. If they catch orders over a threshold, add the threshold. Cheap, and it works for anything with a rule behind it.
2. Keep a human in the loop for that one case. Not for the whole process — for the exception. Automate the ninety percent and route the rest.
3. Accept the loss, in writing. Sometimes a check is not worth its cost. That is a legitimate decision, and it is only legitimate if someone made it. Write the sentence: we no longer catch X, and we decided that.

The failure mode is a fourth option nobody chooses on purpose: the check quietly stops happening and everyone assumes it still does.

4. Watch for the trap in doing this well

When you look closely at a manual process you will often conclude that most of it was unnecessary — and you will usually be right. The steps genuinely were redundant.

But the redundancy was buying margin: slack that absorbed mistakes nobody had catalogued. An accurate account of the parts can support a wrong conclusion about the whole. "This step does nothing" can be entirely true while "so we can drop it" is false, because what the step was doing was not in the step.

5. After you ship, check the thing you decided to keep

If you chose option 1 or 2 for a line, confirm it actually fires — once, by hand, against a real case. A check you meant to encode and a check that is encoded look identical in a process document.

The short version

Automate the work. Before you do, spend twenty minutes asking what the work was catching, and decide out loud what happens to each catch.

The steps you can see are the easy part. The judgement riding along inside them is what you are actually replacing.

This worksheet is the operator version of What the manual process was quietly protecting, which explains the failure mode and why the accurate description is the dangerous one.