BCP / DRP - The last thing they think of when setting up an RPA CoE

Since 2016-17, we can say quite a few organisations' Robotic Process Automation initiative have reached a point where it operates business critical processes that are fundamental for the entire firm's operations. They are doing their day-to-day business, most of the time everything's fine. Some hasn't faced a major disruption yet, and that's good news. What bothers me that most probably many of them are not even prepared to handle one when it happens.

Disruptions come in various forms: ERP can go down, network can go bust, outage in the server room, some bug sticks into the application server, SQL server says goodbye after not archiving it for years, etc. Needless to say, the severity and the resolution time for them are very different, in some situations RPA teams cannot even do a thing to handle them. But somehow the backlog for the robotic solutions are still stacking up and an enterprise needs to operate at the end of the day.

Here are some tips on how you can handle the flames in a chaos like that.

Process Prioritisation

I'd bet not all processes are business critical what you are running on a daily basis. Some can wait a day or two. When the dust settles, you wouldn't want to act like nothing happened and continue the day as BAU, because some highly critical processes need extra resources to get back to normal processing, so you'd want to focus on them first.

That's why you need to know what kind of processes are running on your infrastructure and how critical are these for the firm's daily business. Unless you know these information, you are making the entire company vulnerable to missing SLAs due to bad prioritisation when everything goes back to normal finally.

Infrastructure

At some companies, it is trivial that they need a High-Availability infrastructure for RPA no matter what. But most still consider it as the COO area's funny little tool they play around with without any impact. Unless your own RPA infrastructure is resilient enough, it is your fault if there's a system outage or security breach that should have been handled on your side ages ago.

The best you can do is a geo-redundant high-availability infrastructure where you always have 20-30% more capacity than it is necessary for your current processes. That would give you some leeway when you play chess with your own processes on which one to run first and where, and which one to shut down temporarily.

Excellent Documentation and Ops SWAT Team

Did you seriously think that you only need to write PDDs for deliveries and once a robotic solution goes live, you'd never need them again? Think again. When all collapses, what would be your last resort? Getting back to manual processing of course. And if it happens years after your solution went live, good luck finding someone on the floor who still remembers how to execute that.

There can be certain scenarios when you have to give that PDD back to the business operations and they need to conduct those processes manually once again. A well-written and maintained PDD in this case helps them a lot with what to do and how to do it.

Now you'd say that BizOps no longer has the capacity to do that if an RPA initiative is successful. I'm sorry to disappoint you, but I think such capacity still needs to be appointed and reserved for such circumstances. The same way you have fire wardens, while your building is not set on fire every week.

RPA Operators

Of course you won't have a smooth RPA operation without having good operators. But how skilful are they? Are they able to quickly detect bugs, or even debug solutions? Do they maintain close relationship with other IT areas? Do they understand and can they maintain the components of the infrastructure? How fast can they react when an underlying system is down?

Acting fast is key, either we are talking about fixing a relatively minor issue, like a changing UI selector, or a major one like an ERP is going down. They have to be able to handle outages, and they need to be prepared for reinitiating the whole infrastructure and process schedules under special circumstances. And under 'prepared', I don't mean just mental preparations, but actual plans they can execute.

So, there you have it. These are my top recommendations to consider when thinking about an RPA Business Continuity or a Disaster Recovery Plan. If you can think of any other aspects, please share them with us between the comments.