Doculabs recently hosted its second client summit focused on robotic process automation (RPA), an area currently of great interest to many of our clients, particularly in financial services. (For conclusions from our inaugural summit, see "Lessons from Doculabs’ Robotics Process Automation Summit.")
The half-day gathering was different from what you generally find at an industry conference. Attendees were able to speak candidly about what’s working and what’s not working in their respective organizations when it comes to RPA. There was no need to hype the industry, or RPA in general, or to brag about success. Instead, there was a healthy dose of realism.
The discussion also surfaced some of the myths you’re likely to hear about RPA or read in press reports on the subject. I can report to you that our summit participants did some significant myth-busting, specifically around the following eight claims that are commonly being made these days about RPA.
Let’s take them on, one at a time:
1. Everybody’s doing RPA.
Like high-school sex, there’s lots of talk, but a lot less real action. Today, you often hear the big consulting firms talk about the hundreds of bots they’ve deployed for a client.
The truth is that even the most active of firms might have deployed only 50 live bots. When counting both development and test, we’re seeing about 100 bots, max. If a firm started its RPA process 6 to 12 months ago, it’s likely to have closer to 10 or 20 bots in production or in the pipeline.
2. The business case for RPA is excellent.
This simply isn’t the case. Going in, many of our clients had estimated (or hoped) they could eliminate three FTEs per bot, on average. Their experience is closer to one-half FTE in Year 1, and perhaps 1.5 FTEs later, at a steady-state run rate.
3. Bots are relatively inexpensive to build.
Early on, suppliers suggested that it would cost $40,000 per bot to design, build, test, and deploy. Our clients estimate that the cost is double that—i.e. closer to $80,000. And that doesn’t include Day 2 support.
4. The business can use RPA without assistance, with no need for IT.
This may be a half-truth / half-myth. I’d say that yes, there is less need for IT, but time will tell. Much depends on the experience of the firm building the bot. Certainly there’s a lot of variation in terms of sophistication when it comes to designing bots. As a result, there’s a great variance on the level of IT support needed once bots are built, tested, and in production.
Certainly, we’ll still need IT to deploy the bot in various environments. And we’ll need IT to deal with integration issues and provide contingency planning.
5. Day 2 support will work out fine.
This is another half-truth. When it comes to RPA, Day 2 support really hasn’t been at the top of the agenda for many organizations. That’s because many of the systems robots interact with are in a state of flux as modernization occurs.
But Day 2 support needs to be discussed. How do we ensure modernization efforts don’t make some business-critical system burp?
6. The people who know the tasks are happy to help develop robots.
Oops-- these are the same people who quickly figured out that their jobs were on the line! Renaming an RPA program “Efficiency Improvement” or “Additional Automation” doesn’t fool anyone.
There’s a big potential workforce impact that any organization considering rolling out RPA must address.
7. RPA software tools are enterprise-class.
No, they are not. Scheduling, performance monitoring, reporting, scaling, and even licensing remain immature.
8. Agile development pairs perfectly with RPA; setting up a “factory” is easy.
Yes and no. Agile principles are applicable here, but stitching together multiple bots to support an entire process is hard to do—really hard. QA and testing are taking longer than any of our summit participants anticipated.
We continue to believe in the importance and applicability of RPA for many business cases. But for many organizations, RPA is likely to be a short-term solution for a longer-term problem around process automation.
At the end of the day, it pays to look before you make the leap. All the usual steps apply: Identify appropriate use cases. Define your requirements. Select the tool that best meets those requirements. And have an effective plan for rolling it out—a plan that includes assessing your organizational readiness and doing the appropriate change management.
Take a look at our services in RPA Assessment and Roadmap. We'll take you through each of these steps, helping you navigate this new technology landscape so that you can steer clear of those eight myths and the associated pitfalls.