Stage one: RPA implementation challenges before you automate anything
Nothing has been built yet, which makes this the cheapest stage to get things right and the one organisations move through fastest. Every problem here costs a conversation now and a rebuild later.
Choosing the wrong process
The most expensive mistake in RPA, and it happens in week one.
What it looks like: a bot that works, that nobody misses when it is switched off. Or one that took three months to build for a process that runs forty times a year.
Why it happens: the first process is usually chosen because somebody complained loudly about it, or because it demonstrates well. Neither is a measure of value. A process that is painful is not automatically a process that is worth automating, and the two get conflated in the enthusiasm of a pilot.
What to do now: rank your candidate processes by volume multiplied by stability, and ignore the loudest voice. A boring high-volume process with unchanging rules beats an interesting one every time.
What prevents it next time: a standing selection test that anybody can apply, which is below. Our note on how RPA is transforming business processes covers the shapes of work that suit automation in more depth.
Automating a process nobody has written down
What it looks like: the bot goes live and immediately hits cases the team handles daily but never mentioned, because to them those cases are not exceptions, they are just Tuesday.
Why it happens: four people do the process four ways. The version you documented is whichever person you sat with, and they described what they are supposed to do rather than what they do. Nobody was hiding anything; the variation is invisible from inside it.
What to do now: watch the work rather than asking about it, and watch more than one person. If a process mining or task mining tool is available, use it, because it shows the paths people actually take rather than the one they remember. Then write the process down as a standard operating procedure and have the team correct it, which is where the real version surfaces.
What prevents it next time: treat the written process as a deliverable of its own, signed off before any bot is built. Automating an undocumented process means automating whichever version you happened to see.
No owner on the business side
What it looks like: IT builds the bot, IT deploys the bot, and when the bot does something wrong the conversation begins with everyone establishing that it was not their decision.
Why it happens: automation is bought as a technology initiative, so it gets a technology owner. But a bot enforces a business rule, and the person who can say what the rule should be does not work in IT.
What to do now: name one person in the business who owns each automated process, by name and not by team. They sign off what the bot does, they decide what happens to exceptions, and they are the person the results belong to.
What prevents it next time: make a named business owner a condition of building anything. No owner, no bot. This one rule removes more downstream trouble than any technical decision on this page.
A process-selection test you can run in one meeting
Five questions. A process that fails any of the first three is not ready.
Volume. How many times a day or week does this run? Automation earns its keep on repetition, and a monthly process rarely justifies the build and the maintenance behind it.
Stability. Has this process changed in the last year, and is it about to? A process being redesigned, or sitting on a system due for replacement, is not a candidate.
Rule clarity. Can somebody write down every decision as a rule, without using the word usually? If judgement is required, a bot can prepare the work but a person still has to decide.
Input format. Is the input structured and consistent? Free text, scanned images and email attachments all mean additional technology and a lower success rate.
Exception ownership. When the bot cannot proceed, who picks it up? If the answer is nobody, you are building a queue rather than an automation.
