When can I use RPA?

Having explored what Robotic Process Automation (RPA) is, the key benefits and how to approach it, let’s look at the all-important question of when to use it. Here are 4 simple rules to help you quickly evaluate whether a task is ripe for automation.

Whether you are looking at RPA from a technology or an operational perspective, the same minimum requirements apply for implementation. A word of warning: readiness does not always go hand in hand with suitability. Some processes eligible on paper may not actually create enough added value to merit automation. On the other hand, processes that would deliver the highest value if automated must respect these minimum requirements for RPA implementation.

Rule N° 1: Electronic and digital data sources only

First and foremost, data sources for automation should be electronic and digital. Since we are talking about software robots this may seem obvious, but for clarity’s sake let’s run through them. Typical examples of suitable data sources include emails, Word documents, Excel files, text files, digital PDFs, or any data provided directly from an application. Sources such as paper mail, phone calls or meetings/discussions cannot be used, although smart software, such as Optical Character Recognition (OCR) and deep convolutional neural networks, can “translate” some of these sources into an RPA understandable format. More on this in a future article.

Rule N° 2: Structured and standardized inputs

Data inputs should be sufficiently standardized so that the RPA software can interpret and understand them. Although experienced configurators might find smart workarounds in some cases, the layout of the source should be predictable and information should always be found in the same place. Typically, robots will have a hard time understanding “free text” inputs such as comment boxes. On the other hand, sources such as Excel files, core banking systems, Enterprise Resource Planning software (ERPs) and Customer Relationship Management tools (CRMs) are a boon for RPA because they provide a systematic, structured information stream with high accessibility. File formats such as Word documents and digital PDFs (i.e.: not scanned documents) that can be structured and used by the robot fall somewhere in the middle and will typically require more effort. Here again, the scope of action of RPA can be increased by using complementary tools like Natural Language Processing (NLP).

Focus on repetitive, time-consuming tasks that do not bring any value within workflows

Rule N° 3: Rules based!

Look for processes that abide by rules. The robot must be able to make decisions based on fixed criteria, and the outcomes must be defined beforehand. For the more technical – or experienced – among you, this means that the robot will follow an “if, then, else” structure. These are at the heart of the robot’s execution because they will define what it does in which situation. This is usually the most time-consuming part of evaluating a potential candidate for automation. When asked, most people will say that a task or process is based on “analysis” and “experience”. However, when digging deeper we regularly see that there are some underlying criteria that define its execution. Nonetheless, be aware that rules will more often than not require extra unforeseen inputs, and these inputs may not be available in a digital and/or structured way.

Rule N° 4: Low number of exceptions

Finally, you are looking for a process with a relatively low number of exceptions. The two keywords here are “relatively” and “exceptions”. Let’s start with the latter. When talking about exceptions in RPA, we mean cases that for some business reason, do not follow the typical processing flow in a significant manner. For example, in the banking industry, a customer account blocking process might require special attention for certain types of clients. When this is the case, the robot is taught to detect these occurrences based on provided criteria and then informs the business so that they can be handled manually . The second keyword is relatively. Although this can widely differ depending on the context (such as volumes, complexity and value drivers), a good balance to aim for in practice is 80-20: only 20% of cases should be exceptions, and the remaining 80% should be part of the normal flow. Once automated, this means that the 20% of exception cases should take 80% of the remaining manual processing time, while the automated 80% of cases will only require 20% (or less) of the time.

These rules may seem quite strict, but experience shows that the potential for RPA is still high. Remember: your goal should not be to automate entire business workflows all in one go, but rather to focus on repetitive, time-consuming tasks that do not bring any value within workflows. These value pockets, together with value drivers, are the target of what we call process scoping, and this will be the topic of my next piece in this series.

Author: Tolga Bayrak