Business process automation in Newcastle, NSW: hours back every week.

One that happens often, the same way every time, with no judgement call in it. A two minute job done forty times a week adds up to more than a half day job done once.

The test is simple and it holds up. A job happening the same way every time can be handed over. A job where somebody weighs something up cannot, and trying is what produces the automations people quietly switch off.

What makes a good candidate

• It happens often enough to count.

  Once a week at the very least. Frequency is what makes a small job worth the effort of automating it in the first place.

• It happens the same way every time.

  Same steps, same order, same decision. Where it varies, the variation has to go down on paper before anybody builds anything.

• Nobody has to weigh anything up.

  There is no judgement call anywhere in it. The moment one appears, that step stays with a person and the rest can still be handed over.

• It moves information from A to B.

  From one system to another, or out of somebody's head into a system. That is the shape of nearly every good candidate.

The classic one is data typed into two systems by a person. It is common, it is cheap to fix, and it never makes a list because it feels too small to mention.

business.gov.au keeps its own rundown of the tools, which is a plainer starting point than most vendor sites.

In a small business the repeated jobs land on the people you can least afford to have doing them, and they only happen when somebody remembers them.

In a business with three or ten people, the administration lands wherever there is a gap. That is usually on the owner, or on the one person who is good with computers.

The cost of it is rarely dramatic. It is an evening a week, a job that got missed, and the fact that the whole thing stops the moment that person takes leave.

The other half of it is consistency. A job that happens automatically happens the same way every time, which matters most for the ones only ever noticed when they are missed.

Anything typed in twice, anything starting with a person copying something, and anything waiting on somebody noticing an email. Those three cover most of what is worth doing.

Finding the first one takes a short conversation rather than a review of the whole business.

The questions that find it

• What is getting typed in twice?

  Into two systems, by a person, from the same source. This is the most common one and the cheapest to fix.

• What starts with somebody copying?

  A quote copied into a job, a job copied into an invoice, a form copied into a spreadsheet by hand.

• What waits on somebody noticing?

  An approval, a handover, or a request sitting in an inbox until somebody happens to look at it.

Ask the people doing the work rather than the owner. The answers come back different, and the people doing it usually have a list ready.

Automating a process nobody wrote down, automating a bad process faster, building something only one person understands, and nobody noticing when it silently stops.

Those four cover almost every failure, and all of them are avoidable before anybody builds anything.

What goes wrong

• The process was never written down.

  So the automation ends up as one person's version of it, and everybody else's version of the job breaks.

• A bad process just gets faster.

  Automating a step that should not exist at all makes the problem harder to see rather than smaller.

• Only one person ends up understanding it.

  That is the same fault as the load bearing spreadsheet, moved somewhere considerably less visible.

• It stops quietly one day and nobody notices.

  Something upstream changes and it fails without telling anybody. Nothing needs to alert a person more than an automation does.

That last one is why a good automation makes a noise when it fails. A job done by a person was at least visibly not happening when it stopped.

Ask the people doing the work first. Pick the job that repeats most, write it down properly, build the smallest version of it, then watch that version for a fortnight before starting the next one.

Nothing here is a platform or a system. It is one job at a time, each proved before the next.

1. Ask the people doing the work

What do you do every week that a machine could do instead. They know the answer already, and almost nobody has ever asked them for it.

2. Pick the job that repeats most

Frequency counts for more than size, every time. A small job done every day adds up faster than a large one done monthly.

3. Write it down properly

Every step, in order, including the exceptions. Where three people do it three ways, agreeing on one way is the actual work.

4. Build the smallest version

One job, taken end to end. Not a platform and not a system. One job that used to need a person and now does not.

5. Watch it for a fortnight

Including what it does with the odd cases. And it has to tell somebody when it fails, which somebody tests rather than assumes.

6. Then the next one gets taken

Which is quicker, because by then the connections between the systems already exist and have been proved.

The writing down takes longer than the building on nearly every job. Once one is running, the ones after it go faster because the hard connections already exist.

The order it happens in

• First the jobs go on a list, and one comes off it.

  From the people doing the work rather than from a diagram. Nothing has been built at this stage.

• Then the process goes down on paper.

  Every step, including the exceptions to it. This is the long part, and it belongs to the business.

• Then the smallest version runs, and somebody watches it.

  A fortnight of it, including the odd cases, before anybody looks at the next job.

A business with a process nobody has written down is not ready to automate it yet. Writing it down is worth doing whether or not anything is ever automated.

Ask what happens when it fails, who owns what comes out of it, whether it runs on tools you already have, and what a change costs. The failure question is the one people skip.

These are worth asking of anybody, including this one, so the answers given here are underneath each question.

• What happens when it fails?

  Somebody hears about it straight away. An automation failing silently is worse than the manual job it replaced, because nobody notices for weeks.

• Who owns what comes out of it?

  The business does, in accounts in its own name, including anything holding customer details.

• Does it run on tools I already have?

  Often enough it can. Adding a subscription in order to connect two other subscriptions is always worth questioning.

• What does a change cost?

  Processes change, so this one comes up. A rate and a rough time is the answer.

Plenty of this can be set up by somebody in the business who enjoys it, and some businesses do exactly that. The part worth paying for is usually the writing down and the failure handling.