Where to start with process automation: choosing the first process

Why start with a single process

A broad programme demands decisions about dozens of processes at once, before anyone has relevant experience. The usual result is a long list of priorities and nothing running.

One finished process delivers three things no document can: a real result, tested integrations, and team experience. Expanding from that is far cheaper than expanding from assumptions.

Four criteria worth applying

Not every irritating process is a good candidate. Four questions are usually enough, and none of them requires a tool:

• Repetition — does it happen at least a few times a week? Automating a rare process usually costs more than doing it by hand.
• Volume — how many person-hours a month does it actually consume? If the answer is “we do not know”, the first step is measurement, not automation.
• Cost of error — what does one mistake cost? Where errors are expensive, automation pays even without saving time.
• Data availability — is the data reachable through interfaces? If it exists only in email and people’s heads, the data comes first.

Where it usually goes wrong

The first mistake is choosing by irritation rather than by clarity of result. The most irritating process is often complicated precisely because it is full of exceptions.

The second is automating the process exactly as it stands. If the flow accreted over several years, automation simply speeds up a bad arrangement. Ask which steps are needed at all before encoding them.

The third is leaving boundaries undefined. It must be clear what the system does alone, where human approval is required, and what happens when something unexpected occurs.

What the first step looks like

A week is usually enough to know whether a process is suitable. In that time you measure the current state, document the flow including exceptions, confirm the data is reachable, and agree what will count as success.

Only then does technical work begin. This order looks slower, but it removes the most common cause of failure — a solution that works in a demo and never reaches production.