My company, Doculabs, recently hosted its second client summit focused on robotic process automation (RPA), an area currently of great interest to many of our clients. During the half-day gathering, attendees spoke candidly about what’s working and what’s not with RPA at their respective organizations. The lack of hype about the industry and RPA in general brought a healthy dose of realism to the discussions.

The summit also surfaced some of the myths you’re likely to hear about RPA. The participants did some significant myth-busting, specifically around the following eight claims that are being made about RPA:

  1. Everybody’s doing RPA.
  2. The business case for RPA is excellent.
  3. Bots are relatively inexpensive to build.
  4. Most bots fully automate activities, without human assistance.
  5. Day 2 support will work out fine.
  6. The people who know the tasks are happy to help develop bots.
  7. RPA software tools are enterprise-class.
  8. Agile development pairs perfectly with RPA; setting up a “factory” is easy.

RPA Fact vs. Fiction

Let’s take a look at each of these in turn and compare with what we found in our conversations with real world practitioners trying to be successful with RPA.

Everybody’s Doing RPA

There’s lots of talk, but a lot less real action on the RPA front. You may hear big consulting firms talk about the hundreds of bots they’ve deployed for a client, yet the truth is that even the most active of firms have deployed perhaps only 50 or so live bots. When counting both what’s in development and what’s in test, we’re seeing about 100 bots, max. If a firm started its RPA process six to 12 months ago, it’s likely they have closer to 10 or 20 bots in production or in the pipeline.

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 full time employees (FTE) per bot, on average. Their experience is closer to 0.5 FTE in the first year, and perhaps 1.5 FTEs later, at a steady-state run rate. 

This myth is also based on looking in the wrong places for the business case. The myth is not just that you can eliminate a lot of FTEs, but that simple FTE elimination is the right case to make for RPA. As with capture and automation, you should also be looking at reducing the low-value, repetitive work that those FTEs do — so they can spend more of their time on higher value work.

Related Article: 7 Things to Consider Before You Invest in a Robotic Process Automation System

Bots Are Relatively Inexpensive to Build

Early on, suppliers suggested it would cost $40,000 per bot to design, build, test and deploy. Our clients estimate the cost is double that — closer to $80,000. And that doesn’t include Day 2 support.

Most Bots Fully Automate Activities, Without Human Assistance

This may be a half-truth / half-myth. Some processes can and should be fully automated — but some should be assisted by a human worker. Many opportunities could be assisted, either “always” or as a first step before trying to fully automate them. For example, in any financial services/insurance process where workers have to approve something based on collected data, the bot collects the data and may make a recommendation, but the human checks the quality of the collected data and makes the decision.

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. But you should plan for several Day 2 issues:

Learning Opportunities

  • Ensuring your bots stay in sync with the systems they interact with.
  • Managing bot updates and version explosion as you maintain hundreds or thousands of bots.
  • Managing RPA exit, as many bots are just temporary duct tape.
  • Managing automation failure — when the bots burp.

Related Article: Is Robotic Process Automation Finally Here?

The People Who Know the Tasks Are Happy to Help Develop Bots

This is almost never the case, as these same people will quickly figure out their jobs are on the line. Renaming an RPA program “Efficiency Improvement” or “Additional Automation” doesn’t fool anyone. 

Any organization considering rolling out RPA must address the potential impact on the workforce, but that depends on getting the business case and opportunities right. As with document capture and automation, one of RPA’s primary benefits is reducing low-value, repetitive activities to free up the same workers to do higher value work — cutting out parts of the workload rather than eliminating entire FTEs.

RPA Software Tools Are Enterprise-Class

Point blank, not true. Scheduling, performance monitoring, reporting, scaling and even licensing remain immature and will require three to five years minimum to reach enterprise-class standards.

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. Quality assurance and testing are taking longer than any of our summit participants anticipated.

Look Before You Leap Into RPA

RPA has a place in many business cases. But for most 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 (and think carefully) 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, have an effective plan for rolling it out — a plan that includes assessing your organizational readiness and doing appropriate change management. If you follow these steps, you’ll have a good chance of succeeding with RPA — which will be a critical part of operational success in the years ahead.

fa-solid fa-hand-paper Learn how you can join our contributor community.