When you think about automating an office job the first thing you ask is whether it can be done, and that's already the wrong question. The one that decides everything is how far you let the system get on its own, because an automation can stop a moment before saving and wait for somebody to say yes, or it can close the case with nobody looking at it
They are two different ways of working, and the choice changes two things at once, the time you save and the risk you take on
Assisted automation
The system does all the hard work, it reads the document, checks the data, opens the program and fills in the fields, then it stops and waits, the person looks at the screen already filled in, confirms it if it's right, and if something is off they correct it and carry on
The manual work doesn't disappear entirely, but instead of filling in the fields by hand you're left reading a screen that's already done. It's the road to prefer while nobody in the company trusts the system yet, which is a perfectly fair reason. Trust gets built by watching what it does for a few weeks, not by reading a promise
Autonomous automation
Here the operation closes by itself, nobody confirms anything, the case comes out done and you find it already recorded in your business software
Two conditions have to hold for that to work. The rules have to be writable in clear terms, meaning that for every case that can come up there is one certain answer. And the incoming data has to be regular enough to be checked automatically
There's a simple test. If, in front of a document, the most experienced person you have would say "it depends", then the system can't decide in her place, because that "it depends" sits in her head and not in a rule written down anywhere
The mixed model, the one you almost always need
In practice almost no process is all black or all white. The ordinary cases, the ones that pass every check, the system simply completes, while the ones that don't add up, an amount out of scale or a code that doesn't exist in your software, get set aside and land in a person's hands
The point is to spend your people's time on the odd cases, which are the only ones that call for any thinking anyway
The questions to ask before you choose
There's no formula, but there are a few things to look at
- What happens if it gets one wrong, a wrong field in a customer record you fix in two minutes, a payment sent to the wrong supplier is another matter
- Who notices, and when, if the error surfaces by itself at the next check you can afford more autonomy, if it stays hidden for months, far less
- How regular the incoming data is, a file exported the same way every time from the same portal is one thing, the PDFs of forty different suppliers are another
- Whether the rules exist in writing or live in the experience of whoever does the job, if they aren't written down the first job is to write them, before automating anything at all
How you actually start
It's worth starting assisted even on a process that will end up autonomous. For the first few weeks the system proposes and a person confirms, and meanwhile you get something you'd never have otherwise, the exact list of the cases where it would have got it wrong
That list is the most useful part of the beginning. Every correction made by hand becomes one more rule, and when the corrections thin out you can drop the confirmation on the cases you've already seen work, keeping it where it's still needed, so autonomy widens by degrees instead of coming on with a switch
A quick way to get a feel for it
Take last month's cases and ask yourself how many were truly ordinary, no exceptions, no calls to the supplier, no "this customer we handle in a special way". You don't need a figure to the decimal point, the sense of whoever does the job every day is fine
Say, with an example made up just to make the point, that out of a hundred cases about seventy run smoothly and thirty have something odd about them. Those seventy are the candidates for autonomy, the others stay assisted, and nobody makes you pick a single mode for the whole process
What has to be known before making an estimate
If you want to see where a process of yours sits, only a few pieces of information matter, which programs get opened, how many steps it takes from start to finish, how many operations there are in a month and how often a non-standard case comes up. With those you can reason, without them you're guessing