Is RPA the next Y2K?

RPA.

It's a big deal.

For the unaware, the tech industry has created another acronym (because it's our speciality), and this one means "Robotic Process Automation".

What a fabulous name! Sadly it's not as exciting as it sounds. It has nothing to do with interesting devices running around being really helpful, making things, picking things up over here and putting them back down again over there for us, bringing coffee, and generally keeping humanity amused, lazy, or unemployed... or, better still, out of actual danger, doing things we perhaps don't want to do, or shouldn't do, or just can't do safely. Such as vacuuming. That ticks enough of the boxes.

No. This RPA stuff is usually all about providing a life support system to tech that's been around an awfully long time and wrapping it in products and services, almost as a life hack. It's essentially about glueing legacy systems together or hooking them up to contemporary systems, and automating tasks such as data movement between them, simulating system usage, and, well, removing the tedium of an operator which carries the benefit or reducing human error (now you can blame the machine) and doing it much faster and more efficiently than was possible before (now when it screws up, it does it at unprecedented speeds), and generally speaking, license fees tend to be cheaper than salaries. This is not an exhaustive list of reasons businesses are looking to RPA to gain competitive advantage; just some of the key ones.

So there's a lot going for it. Really, there is. And I do advocate using RPA in the right place. What business doesn't want to do more, do it faster, and do it cheaper? Outside of public transport businesses anyway (wait, did I write that out loud?!)



Here's the thing...

It's a timebomb waiting to happen.



Wait, what!? That's a strong statement.

Yeah. Perhaps.

Remember Y2K? Remember how the world was going to end because of all the systems that didn't know how to calculate 1 + 99 = 2000? It was apocalyptic scale mass hysteria. For real. To us human types, 1 + 99 = 2000 was unbelievably obvious.

There was an awful lot of checking, patching, and subsequent testing needed to refactor lots of systems to persuade them that 1 + 99, was, in fact, 2000, and not 100. Or 0. Or 1. That would just be silly.

As a result, there were an awful lot of people coming out of retirement to hit the contract market in programming languages, operating systems, and systems, where there simply wasn't the knowledge in the contemporary workforce to deal with the situation. Why? Because the world moved on. And the systems didn't. It's pretty much that simple.

So RPA is, to all intents and purposes, an enabler for forming exactly this situation. A permission slip at least; because the root causes of the problems that your RPA projects are looking to get around likely aren't getting fixed.

Rewind a moment... I used a really important word back there - refactor. So important in fact, I rather fancied using bold italics this time around.

That's the right way of fixing whatever problem you're trying to overcome by using RPA. Most people will associate "refactoring" purely with coding; altering your code to be better and evolve it as better design patterns emerge, or a more performant way of doing a thing is figured out, or new language constructs are developed. In this context though, it's also your business processes, and beyond, that likely need refactoring.

So go ahead, use RPA. Absolutely. I give it a thumbs up.

Don't do just RPA though. If you do that you are building up your technical debt (and all debts become due sooner or later!) and also your process debt; stifling the very business you're trying to improve.

So if you're employing the use of RPA, you need to look at the core reason you're using it and refactor your business model, your business processes, the technical architecture it's all built upon, your data, your interactions... everything.

Whatever you're trying to hide away or ignore with RPA, bring it out. Look at it. Examine it. Understand it. Diligently.

Get a continuous improvement team together to own what good looks like. Empower them to pull in key stakeholders, and to go do all the right things - not just the cheap things.

Your business will thank you for it, your employees will thank you for it, and crucially, your customers will thank you for it. And so will your balance sheet.

So don't let your RPA become your BAU or you'll create your own Y2K and become RIP.

And that, frankly, is just too many acronyms.