Tony Abel, a managing director at consulting firm Protiviti, met recently with SearchCIO to share some of his experiences in delivering robotic process automation (RPA) services to the firm’s primarily Fortune 100 clients.
Robotic process automation technology, sometimes referred to as software robots, automates high-volume, repeatable tasks done by humans, such as queries, calculations and maintenance of records and transactions. The software is designed to mimic how employees interact with their computer interfaces to complete these rules-based tasks, from logging in to the relevant applications to capturing and entering data, performing calculations and logging out.
RPA technology, while not new, is emerging as a major new driver of business process efficiency, with costs savings of up to 300% and more. The eye-popping ROI, say experts, is due in part to the new software platforms with AI and machine learning capabilities that allow these bot-enabled gains to scale from one-off projects to enterprise-wide transformation. Protiviti partners with three of the major technology platform providers in the RPA market space: Blue Prism, Automation Anywhere and UiPath.
Abel comes to the RPA services field armed with many years of experience in supply chain process improvement, where management approaches like Lean and kaizen drive optimization. Any RPA engagement, Abel said, begins with first identifying processes ripe for improvement. “We really try to lead with the business problem. We don’t go in with a hammer looking for nail.”
Here are edited excerpts from my briefing on Protiviti’s approach to RPA services.
Questions for Protiviti’s Tony Abel on RPA services
Do you improve the business process first or automate the existing process as is, figuring any bot will be more efficient than humans?
Tony Abel: It is an interesting question. RPA is certainly not a capability or approach you slap on a broken process. The way I describe it with clients is that there is some level of standardization required. You may not take it from its current state to a fully efficient process — the goal of automation — but you do have to standardize that process to the degree that once a bot is developed and implemented against that process, it’s running consistently. You can have some variations — and bots are intelligent enough to know, “When it looks like this, do it this way, when it looks like that, do it another way.” But you don’t want too many variations in the process, primarily because of the data that sits behind the process. Bots do really well with structured data; with unstructured data they tend to kind of fall on their face — there’s lots of exceptions dropping out; it requires so much manual effort just to administer the bot that it becomes not that effective in driving efficiency, which is what you’re after.
So RPA is somewhere in between of what you do with more traditional ways of improving a process and just slapping a bot on top of a broken process and hope you get the efficiency.
What’s a common example of process standardization that companies do to get bot-ready?
Abel: So, in a lot of cases, it’s dealing with things like one business unit processing invoices differently than another business unit. Certainly, you can build individual automation within each of those processes, but the real value is if you can standardize them. Let’s assume for a minute they are not all that different. If you can get them to operate their invoicing processes more similarly, then you implement a bot that runs at a much higher level across those two divisions, as opposed to point solutions within each. That’s one level of standardization I talk a lot about. And then, frankly, the quality of the data that underlies the process is probably the most important driver of getting to an effective bot.
I’m sure it varies with every organization, but can you a give a sense of how long it takes to standardize a process to the point where it operates consistently?
Abel: It does depend on the company. We’ve done proofs of concept for RPA services in a matter of weeks for straightforward use cases. An example is user provisioning in an IT department. There’s usually not a ton of standardization that happens in that process, and the rules are pretty easy to identify — most of these IT organizations have this documented. That allows for a pretty quick few weeks to get a proof of concept out, watch the bot run in a test environment and start thinking about how you can get it into production.
When it’s a much more comprehensive process — I used the invoice processing example — anything in that realm does tend to get much involved. Let’s say we’re looking at a three-way match business process of a purchase order (PO), a receipt and an invoice. There tends to be a lot of exceptions in that process. Here’s one: a company has received five of the 10 widgets it ordered on the PO, but the requester has now decided that all it wants is five, so how do we, as a business — in an automated fashion — add awareness that this is the case, versus, say, the an automated process for the company that is still buying all 10 widgets?
So it takes a little bit more process definition work up front when it’s a comprehensive process like that, and that can take some time, because you really have to build those rules to be pretty precise. And where they can’t be precise, then you need to know that it will require some subjective decisioning — and that’s where the bot has to stop. The bot can take you through all the finite rules-based logic very quickly, very efficiently, but when it gets to the ‘Now we need a human to weigh in and make a subjective decision,” the bot has to stop, the human action has to be made and the bot can then be fired up for the rest of the process.
What’s the ROI on a successful RPA implementation, ballpark?
Abel: We’re probably seeing that a bot in an automated process is 70% faster and more efficient, and more cost-efficient. than a human performing the same activity.