A Strategic Look at Robotic Process Automation
By: R Karthik
Tags: Automation, Rpa Solutions, Business Strategy, Alumni Stories

Automation, AI/ML, and Robotic Process Automation (RPA) are the recent buzz words that are ruling the industry, ranging from making claims that it has saved millions of dollars, to it will take away jobs. Some of it is true and some of it is just fluff to grab headlines.

There are times when RPA is important, and there are times it is not. Before we get into the reasons, let’s understand why it is starting to become popular.

1. Inefficiency in the service industry

This is perhaps the number one reason for the emergence of Robotic Process Automation. The service industry, unlike manufacturing, has seen a decline in efficiency over time, instead of increasing efficiency. There are many reasons for this. Many industries have a lot of legacy tools that need support, and need to move data from one screen to another, where a human just copies data from one screen to another. Sometimes the same data needs to be collected in multiple places, because new tools came up when a company acquired another company. It could be due to a regulatory requirement or there may be a transition phase when two tools are being used simultaneously. The list is endless, but the problem of inefficiency is real.

2. Emergence of No Code or Low code solutions

We have finally reached a point in technological development, where we have no code or low code software development. What this means is, that even if you don’t know how to code, you could build an application (app). There are applications that can interact with other applications just as a human would do. For instance, an RPA tool can open an email client (say, Outlook); create an email; and send it out, based on a trigger/event.

Now anyone who does not know how to code, but can make logical statements (a.k.a yes / no statements), can build sufficiently advanced models. Let’s say you need to book a movie ticket. You first pick a movie, then the theater in which you want to watch it, and then the seats. Perhaps you have some favorite theaters, and you also have some preferred seats you always tend to book. Now this operation can be completely done by a Bot; or partially by a Bot, after which you complete the rest. The decision tree looks like this

Watch a movie (Yes / No) If Yes, then which theater? User preference is already saved. Pick based on highest preference How many seats? (user provides input) Seats found (Yes / No)

Now you can ask a Bot to book a movie ticket. This can be in the form of a voice command, or an email or a text. Once the Bot is active and configured, it can go through these steps and book your ticket, or reach out to you when it gets stuck, so you only have to fill the details not available.

3. Self-service model

Businesses are increasingly empowering the last mile worker to build solutions for themselves, to solve their own problem. Now the Business Analyst can build whatever they want, and don’t need to depend on a developer for a technology deployment. There is now an acceptance of this kind of federated model as opposed to the central software development cycle.

4. Computers are becoming faster and cheaper

Computing power has also increased over time, and now we can run multiple applications on a computer without crashing it. Plus, purchasing such computers is also not going to break the bank, if you were getting a physical machine. The same is true for virtual machines. Cloud computing is becoming cheaper than it was in the past. Spinning up a virtual machine for some work is now as easy as a click of a button, and you only pay for the time when it is on.

So, now you can run the RPA tool and a host of other applications it needs to interact with, without the machine having memory issues — which used be very common in the past. If it is on the cloud, then you can turn off the machine once the task is completed.

While the list is not exhaustive these are some of the reasons for the growth of automation. The biggest advantage of automation is self-service. A Business Analyst can go ahead and build a technology solution for her/himself. The Analyst understands business problems and there is no need to discuss the details with a Scrum team, waiting on tech resources to get a solution to be deployed. Soon enough, you start seeing Bot statistics going through the roof, saving FTE resources, and bringing real value to the business.

To Automate, or not to Automate

Here is where things get interesting. Not all businesses need to deploy RPA. Tech stack for businesses becomes obsolete all the time, and they constantly require an upgrade. A lot of the rule-based work can actually be built as a Stored Procedure (S-Procs) in a database and be deployed. The database solutions are highly scalable and require a lot less computing power than RPA solutions. S-Procs have been around since the 1970’s and we know the technology works. One needs to consider this as well along with a host of other things before deploying RPA.

This brings me to the strategic nature of deploying RPA. Let’s take a look.

Think solutions rather than software

At the end of the day, the business needs problems to be solved. RPA is a powerful tool but not without its flaws. Think of it like this “Can a tank take you from your house to your office?” The answer is yes. But is it the best use of a tank? Probably not. You might be better served by taking the Metro, which may wiz you past the traffic and get you to the destination faster. Similarly, if the rules can be put in the database, then that is better. But if the solution is not big enough to be picked up by a Scrum team and is only a short term requirement, then RPA may be the way to go. Nature of input and output

If the nature of input and output is very dynamic, that is, if your inputs and outputs are constantly changing, then RPA is your tool. Let’s say you have multiple methods of receiving input for the same process. It can come as an email attachment to a designated inbox, an IVR system, a chatbot or someone can come to you in-person and provide the input. Now I can hand over the inbox, IVR system input, and the chatbot to the machine and also assist in the in-person application in using a robot. A solution which interacts with all these can be deployed very fast. This could also aid in better human-to-human interaction, if done correctly. However, if my input data is mainly coming in the form of a flat-file or API’s then a database solution may be much better and scalable. Speed of deployment

If you need a solution up and running in a few days and can’t wait, RPA is a great way to go. If however, you do have time and tech resources then building software may bring better ROI. Prototyping

RPA is a great tool for rapid prototyping. You can build a quick Proof of Concept (POC) and show something works (even if it is buggy) and then have the same solution built as a custom software. Support systems and failure recovery

RPA tools are also software. And like all software, they can have downtime. If you have a critical business process that is dependent on the RPA solution, then there is an additional risk of this solution going down, adding one more point of failure. This is something you need to consider before deploying RPA as a solution. So if your data entry system is buggy and goes down often, then the problem could be compounded by deploying RPA. Security

RPA is a powerful tool, and oftentimes, it gets elevated privileges to access other tools. This means that it is important to secure access to the RPA tool. This also means you need to have proper audit trails to ensure that there are logs of what is being done. Picture this: if someone who is not authorized to get access to the RPA tool gets access to it, they can run a riot in your systems.

These are just some of the many decisions which need to be considered before deploying RPA solutions.

The Takeaway

In a nutshell, the business which thinks solutions first, and then deploys the technology, will be far more successful in the long run. If done properly, RPA is amazing. However, if the implementation is poor, your return on investment may actually be negative, which is why thinking strategically with a solution mindset is the way to approach deploying RPA.