When To Use RPA & What To Do Before?
When to you use RPA? Every business has processes that help it to deliver value at which customers. The processes are often supported by people, technology and data in each step. When a step is automated, the people are freed up to do other things. The problem is two different processes might have been built independently. And if there is a need to communicate between the two, then some integration needs to happen.
One easy way to do the integration is to help people read information off of one system and enter it into the other. This type of integration is relatively easy to do, because you can hire and train people to do it. Since people are easily trainable, they can integrate across two or three or four or more processes. But the integration only works as fast as the humans can transfer information from one process to another.
Humans get tired and often make mistakes, resulting in poor outcomes. Another approach would be to integrate the applications themselves. But this turns out to be much harder and more expensive and could take months. What if we could take the easiest way to integrate processes, which is human based and automated with systems? That will reduce both the process execution time and errors. That’s essentially what RPA or Robotic Process Automation does.
So how does RPA work?
It watches a human perform the tasks and just records the steps, as they access the different user interfaces of different systems. Then the steps can be played back for every instance of process execution. For example, it can copy say the account number from one screen and paste it onto another. This is how information is transferred from one process to another.
RPA is not artificial intelligence. On the other hand, it’s much simpler. All it knows how to do is to record and replay a script. For example, RPA’s can’t understand or analyze text, it can’t recognize objects and images, and cannot identify fraudulent transactions. When you use RPA, you’re not changing the process, just automating the integration. The human bottleneck in the process is removed.
Even RPA cannot handle a specific situation, It just alerts a human who can take care of such exceptions. But if you think that the process itself needs to be changed, because there’s a new way of doing things, perhaps, then RPA is not the way to go.
Say you walk into a bank to get a personal loan, the banker might look at your checking account might ask you for information about your primary residence, might get information about your retirement account, information about your credit cards, your life insurance and other assets. Since the systems are not integrated, the banker essentially accesses the different systems to get a financial picture of you. There you have a candidate for an RPA.
Using this financial picture as the basis, the bank can approve or reject your loan. To automate the process, the bank could use RPA. But what if the ability for anyone to repay their loan actually depends only on their income and their credit history. In this case, a new bank loan approval process has to be designed and implemented. This process will provide greater customer experience and a lower default rate. To change or create a new loan application process, the bank should take a business transformation perspective, as opposed to a process optimization perspective.
In the first case, you would redesign the customer experience and the associated processes and re-implement many aspects of it. In the second case, you could use RPA to make the current processes faster. The bottom line is this. If you simply want to integrate your existing processes so they become faster with less errors, then use RPA. If you want to redesign the user experience and simplify the processes, perhaps because your business requirements have changed, then don’t use RPA.
RPA is ideal for automation, not transformation and needs to be coupled with process mining and enterprise wide planning initiatives to gain maximum value.