Why this comes first

Most automation projects fail in the description, not in the build.

Somebody describes the process. It gets built. Halfway through testing, three things emerge: an exception nobody mentioned, two people doing it differently, and a step that exists for a reason nobody can remember.

None of that is a technical problem. It is a mapping problem, and it is cheaper to solve before anything is built.

Watch, do not ask

The single most useful piece of advice here.

If you ask somebody how they do a task, you get the procedure — the tidy version, in the right order, without the parts they have stopped noticing.

If you watch, you get the process.

What watching reveals that asking does not:

The step done out of order because it is more convenient.

The check done from memory rather than the sheet.

The spreadsheet somebody keeps because the system does not do something.

The pause while they work out which of two things applies.

That last one is where the judgement is, and it is exactly what you need to identify.

Watch more than one person

If several people do the task, they are doing it differently.

Not because anyone is wrong. Because the procedure left room, and each of them filled it differently.

Which means a decision before you automate: which way is right?

Sometimes both work and you pick one. Sometimes one is better and nobody had noticed. Sometimes the difference reveals a case the procedure never covered.

Automating one person’s version and imposing it on everyone is how automation projects become unpopular.

The questions that work

Four, and the third is the most productive.

“Show me how you do this.” Then watch. Do not interrupt.

“What happens when it goes wrong?” The exceptions.

“What is annoying about this?” The best question available. People are honest about friction in a way they are not about compliance — and friction marks where the process is failing.

“When did this last surprise you?” Surfaces the rare case that would break an automation.

Avoid: “do you follow the procedure?” The answer is yes, and you have learned nothing.

What to write down

Six things, per step.

What happens. The action.

Who does it. By role.

What triggers it. What has to be true for this step to start.

What it needs. Which system, which document, which information.

How long it takes. For your baseline.

What can go wrong. And what happens then.

That last column is the valuable one. It is usually blank in existing documentation and it is where the automation will meet reality.

Finding the judgement points

Mark every place where somebody decides rather than follows.

How to spot them: the person pauses, checks something, or says “it depends”.

Then ask what it depends on.

Two possible answers:

A rule they can state. “If it is over five thousand, it goes to the manager.” That is automatable.

Something they cannot fully articulate. “I look at it and it usually seems fine, but sometimes something feels off.” That is judgement, and it should stay with a person.

The mistake is encoding the second kind as rules. It works until reality produces a case the rules do not cover — and it will.

Question every step

While you have the process written down, use the opportunity.

Per step, three questions:

Why does this exist? If nobody knows, investigate before automating.

Who uses the output? A report nobody reads should be deleted.

What would break if we stopped? Sometimes nothing.

This is the cheapest improvement available. Removing three of eight steps saves more than automating all eight, and costs nothing to maintain.

Do it before choosing a tool, not after.

Measure the baseline

While you are watching, count.

How long does one run take?

How many runs per week?

How often does something go wrong?

How long from trigger to completion?

Without these you cannot say afterwards whether it helped — and “it feels faster” is not a result you can take to anyone.

Get it agreed

Show the map to the people who do the work.

Two things happen:

They correct it. You missed something, or misunderstood a step.

They tell you about a case you never saw. The one that happens twice a year and would have broken everything.

Then get the decision-maker to agree it — particularly on the points where people were doing it differently.

A map nobody has agreed is a map of one person’s version.

How long it takes

Less than people fear and more than they budget.

A single straightforward process: a day or two, including watching and writing up.

A process crossing departments: a week, mostly because of scheduling and disagreement.

Compared to a build that starts on a wrong description, either is cheap.

What good output looks like

One page per process, showing:

The steps in order, with who does each.

The exceptions, and what happens for each.

The judgement points, marked.

The systems touched.

The baseline numbers.

Not a formal notation. Something a colleague can read and recognise.

If a person who does the work reads it and says “yes, that is it” — it is good enough.

The short version

Watch, do not ask. The procedure is the tidy version; the process is what happens.

Watch more than one person, because they are doing it differently and you need to decide which way is right.

Ask what is annoying about it. The most productive question available.

Mark the judgement points and leave those with people. Encoding judgement as rules works until it does not.

And question every step while you are there. Removing a step beats automating it.