Process automation in mid-sized companies: where to start?

Five steps

• Document: describe a process from start to finish, with everyone involved and every intermediate stop. Not an idealised version — the real one.
• Assess: frequency, duration, error-proneness and accessibility of the systems. This yields a ranking, often a surprising one.
• Start small: automate one sub-step, not the whole process. Capturing and assigning is almost always enough to begin with.
• Measure: after four to six weeks, check what actually happened — and what the exceptions were.
• Extend: add the next step, using what the measurement taught you.

This approach has one drawback: it does not deliver the target picture immediately. It has one advantage: after six weeks you know what your data really looks like — and that almost always changes the plan.

Documenting a process without glossing over it

Documenting is the step that yields the most and where the most goes wrong. Two things help:

• Ask the person who carries out the process every day — not the one who described it.
• Ask about the most recent case, not the normal case. "How was it yesterday?" produces different answers from "how does this work?".

Note the workarounds too: the spreadsheet someone maintains on the side, the email to oneself as a reminder, the printout for the filing. These workarounds are not negligence, but pointers to a gap in the system — and often the real finding.

The right first candidate

It has four properties: it runs at least weekly, it is owned by one department, it touches at most two systems, and it does no harm if it stalls in the first week.

What is not suitable as a first candidate: the process with the greatest perceived pain. It is usually the most complex, touches the most departments and has the most exceptions. It comes second or third — with the experience from the first.

Four mistakes that cost at the start

• Starting with the tool. First the process, then the question of what to use. The other way round produces a solution still looking for its problem.
• Saving the exceptions for later. They are not the fringe, they are a quarter of cases. What should happen when data is missing belongs in the first plan.
• Making nobody responsible. An automated process needs a person who notices when it stands still.
• Too big too soon. A project that delivers nothing until after six months loses the people who would have to carry it.