pixone3d - Fotolia
BOSTON -- Robotic process automation is among the most talked-about technologies today. Not understanding what it means in 2019 may feel akin to not knowing what Games of Thrones is about or who Taylor Swift is. In truth, you're not alone.
Here at the IFS World Conference, Bob De Caux, VP of AI and RPA at IFS, clears up the confusion around robotic process automation and explains RPA basics.
How would you define robotic process automation?
Bob De Caux: Robotic process automation is [metaphorically] a software robot sitting in front of your computer, seeing everything a human would and interacting with the screen in the way that a human would. It's not intelligent -- you tell it what to do, and it performs those [rules-based, repetitive] tasks.
What are some examples of robotic process automation?
De Caux: A classic example or use case is when you've got purchase order data stored within Excel or a number of different files. RPA gives the ability to bring that data together into one file to check for duplicates and errors. Then it can log in to another application ... and go into all the different fields and populate them with the correct information over and over again. So it's a fairly monotonous data entry task. It's very repeatable, very high volume. And it consists of tasks that are potentially prone to error. That's where RPA can help. It doesn't need to make any decisions; it's just picking up the data and moving it.
What are the benefits of RPA?
De Caux: People worry that automation is about replacement and a reduction of jobs. At the moment, that's not really how it's going. Instead, RPA is freeing people up from those very monotonous, repetitive tasks, allowing them to focus on higher-value tasks such as things that do require a decision, things that are more valuable, where you need to invest some time and effort to execute.
The other thing is that if you set the bots up well, and you can create an ecosystem of them doing the work -- they never sleep, they can work 24/7, and they're not going to make mistakes. And that allows you to be a lot more productive and a lot faster. The big technological benefit of robotic process automation is the ability to just sit it at the top of the software you've got already and go to work. You don't need to code, you don't need to change anything you're doing. RPA has been very successful in getting up and running and [its popularity] has grown quickly. It's been very easy for it to proliferate and for people to see easy value, because you demonstrate taking data from one place and putting into another. That's something that's definitely going to save time.
In terms of RPA basics, what's one example of where it shows real benefits?
De Caux: Where RPA has been particularly successful is in financial institutions, where they just have huge amounts of data and repetitive processes. It's very easy for a financial institution to show the efficiencies of robotic process automation. They can show it in terms of hours saved, cost savings and so on.
With ERP vendors, it's very much a case of how people interact with the systems. At IFS, our view of how we want to automate processes within our software is very different from how RPA can interact with us. So we think of RPA as an external tool. It's how other systems can talk to IFS, bringing data in and taking data out.
But within our system, we prefer business process optimization. To take advantage of data we get from how people use our system, we can use artificial intelligence, we can use machine learning to make recommendations for how they could do the work way better and understand the way they interact with the software in a way that an RPA provider can't do because they're on the outside looking in.
Business process optimization and robotic process automation can coexist, but RPA can never be the full automation story.
What are some of the downsides of robotic process automation? How might someone have expectations that are too high?
De Caux: RPA is very easy to get up and running, which is both a blessing and a curse. One common thing that RPA does is offer recording functionality [i.e., the ability to record the steps of a process]. So you can press record and do a series of clicks and moves. And it will record that and replicate it. That can work very well for capturing processes. But if you're not a subject matter expert, if you're not doing the process properly, or if many people are trying to record the same process independently, it can be very hard to maintain, it's not necessarily going to be easy to scale. And I think the other main limitation is that when you're using the user interface to determine steps, if there are changes to that user interface or there are new versions of the software, it can be very hard for those processes to adapt. You can end up having to store different processes that are going to work in very specific environments. And that's gradually going to snowball [complexity].
What are some examples of that?
De Caux: If we go back to that purchase order, for example, we're bringing data into the file, and we are searching on a screen for the specific fields that we want to enter into the cost. Those fields will exist in a certain place on the screen. How RPA tends to work is you label that field. It will be able to identify that field using computer vision. And so it will know where to go and place that data. But if that field moves completely or if it's labeled differently, then the RPA software is going to struggle to know where to put the data. So those processes aren't as robust as something like an API, where you can just bypass [the look of the screen] to find an absolute abstract concept on a database.