Date: 09 September 2020
The hot new topic in the IT market these days is RPA… and rightfully so.
There are many benefits that RPA can provide, but there are also many shortcomings and fail points that you need to be aware of before deciding to go down the ‘bot’ route. Success or failure with bots is determined by you and your ability to appropriately identify the process and prepare for your bot.
RPA is definitely an exciting technology as it brings opportunity to everyone and not just developers and programmers. You just need to be able to confidently decide when and where to use RPA so your organisation is geared for success and doesn’t suffer the failures with RPA’s limitations that so many others before you have discovered.
I know what RPA is, but I want to hear your definition…
RPA is the initialism for ‘Robotic Process Automation’. It’s a way to take the manual processes that your employees do on a routine basis and automate it. Think of those employees who have to collect data and information from one system and then key it into another system. RPA would do this automatically, saving that employee time and effort. This scenario is prevalent in areas such as contact centres, finance teams and compliance auditing etc, but processes that can (and should) be automated are found everywhere.
For an example of how it works, let’s say you’re a company that happens to receive A LOT of digital forms. Let’s say those forms contain account numbers and payment amounts. You could set up an RPA bot to capture and access each of those accounts listed in the forms and then have it perform a task to record the payment amount. Nice, right?
This doesn’t sound new…?
Correct. The idea of automating processes is far from new. Automation not only provides efficiency gains and productivity gains, but it can ensure that there are no errors during the process and can minimise risk in your business.
So why is everyone suddenly excited about RPA?
Well, there is a big difference between traditional automation and RPA. If you think of any system you work in, simply put, there is the user interface (or UI) and the backend code. The UI is what the user sees and interacts with, while the backend code is what controls the UI (and these days some architectures prefer the UI workflow to control the backend processes), any interactions and is what makes the system do what it does. Typically, traditional automation is a change to the backend code, while RPA mimics the user interaction on the UI.
This is major because backend code changes can be very difficult to do. It requires a programmer who knows the language and the current system, it requires time and testing, and it could mean some major system changes or upgrades.
This is even more difficult for smaller businesses or businesses without a developer to manage the system changes. RPA is easier to learn and can be self-taught, is faster to complete, and typically never requires a change or upgrade to a legacy system. (The only time when your RPA process needs to change is if there is a change to your legacy system that the RPA process will use). You could set up a bot with RPA within a day (depending on the complexity of the process), where traditional automation would take much longer.
Why would anyone NOT use RPA then?
Here’s the kicker. Most people use RPA without considering any alternatives. RPA sounds awesome so far, right? Which is why it has become so popular. But the one thing that is missing from RPA’s current story is the drawbacks and shortcomings and, if not considered, can cause catastrophic failures to your processes.
There are many pitfalls where, applied inappropriately, RPA can become a major issue rather than a solution. If we’re being honest, RPA is virtually fancy screen-scraping for those who aren’t programmers (which is amazing), but you need to know when you need screen-scraping versus a system overhaul. Unless, of course, you start integrating hyper automation which can then easily transform your limited screen-scraping RPA processes into intelligent automated processes that can change unstructured non-digital data into structured digital information.
Here are some questions you should ask when making a decision about automating a process:
Is my data inconsistent or does my process use paper-based processing?
This is the most common failure. Basic RPA requires structured and standard data to run smoothly. Basic RPA requires digital data. If you utilise a paper form or report that you will need your bot to process, you will need to implement an OCR (Optical Character Recognition) or AI (Artificial Intelligence) type of program to help interpret the data for the bot.
Is my process multi-dimensional?
RPA must use very simple logic rules and objective decisioning. If you have any portion of your process that requires intuition or creative reasoning, the RPA will not be able to perform its function and you would need to look at AI add-ons to cater for more complex process requirements.
Is my process in a steady state?
Because of the RPA nature of needing exact and consistent information, the best candidate for a process is one that is currently unchanging. If you are currently adjusting your process steps, data or outputs, then with each change you make you would have to also then change your bot as well. The opposite of this, however, is that a bot can actually be a good first step to a major system change. Some organisations may choose to use bots as an interim phase to receive initial benefits, while a larger, more extensive project is being designed and developed for traditional automation or system overhaul.
Will my bot need supervision or am I needing a process to be supervised?
Bots do not require supervision. However, it is recommended that you have an alerting and monitoring system and processes in place to alert a team of people if a bot has stopped working or if something has gone wrong. Normally, this will form part of your standard DevOps monitoring processes.
Do I have staff for RPA bot upkeep and maintenance?
RPA bots are not immune to system failures and crashes. You will need to ensure you have someone ready and capable of troubleshooting your bot and implementing a process to get you back up and running.
Do I mind continuous fees?
RPA is done through the purchase of an RPA-enabling system from several companies (we partner with a couple of the most popular ones globally) and most service offers include a monthly or annual licencing fee.
Am I on a tight deadline or budget?
RPA is cheaper and quicker to implement. Remember, if you’re selecting to value time and money, then you’re sacrificing quality. Your solution will not be as sustainable, flexible or fit for your use and purposes. It’s best to think of RPAs as an interim state to help you start seeing benefits of your improvements while on your path to a full-fledged process or system initiative.
Do I have legacy systems that cannot handle APIs?
If your designs and improvements require APIs and your current systems cannot handle them, traditionally your only option would be to scrap the old system and migrate everything to a new one. However, with RPA, you can perform some of the same functions as APIs by using bots instead. Since the bots will sit on the front end of your system, this will not disrupt your legacy systems.
Can I justify the cost of RPA?
RPA may be faster and cheaper than other forms of automation, but that’s not to say it’s free or even cheap! The benefits you receive with RPA are not as vast considering RPA’s limitations, so you will need to make sure that the benefits your bot can provide you will justify the cost of its design and implementation.
Good measurements to consider are:
- Expensive human errors and rework that a bot could prevent
- High cycle times or wait times that a bot could expedite
- High volumes or throughput. If your cycle times are shorter, you will still see major benefits if you have high enough volume
- Scheduling limitations. Can you use a bot to perform tasks overnight or on weekends while your staff are out of the office?
So, as it may be obvious to you now, there are many awesome uses for RPA in a wide variety of industries, but there are just as many limits to what RPA can handle and where RPA will be successful. The most important thing is taking a close look and evaluating your current situation to see if RPA is appropriate for what you need. Otherwise, you may end up with a lot of time wasted building your bot and then a lot more time wasted as you continuously have to change, update and fix your bot.
There are plenty of situations where RPA has been inappropriately implemented and has tanked a project or a company altogether. But there have also been just as many situations where a company elected for expensive traditional automation that it didn’t have the capacity for.
Understanding the pros and cons of the different options for process improvement and automation is key to making the right decision.
