Skip to Content

The 4 Persistent Myths of RPA

Doug Ross
October 18, 2018

Your Robot Reality Check

Few topics are hotter areas of enterprise discussion and activity than Robotic Process Automation (RPA). The return-on-investment (ROI) for a bot project can sometimes be jaw-dropping. The time-to-market for building and deploying a bot is often shockingly quick. But RPA is no silver bullet. Our company — Capgemini — has been building and maintaining bots at scale for more than five years. We’ve seen the good, the bad, and the ugly. And our experiences can help dispel some of the intrigue regarding the claims of RPA. The following are a few of our favorite RPA myths:

4. “You can do it without IT”

Some RPA vendors rightfully point out that bots can be developed by business people with a minimum of technical experience. This is often true, but the picture is far from complete. For a bot to maintain value over a long period of time, several best practices should be considered:
  • Bots should be reviewed for resiliency, error-handling and security
  • Bots should employ enterprise standards (e.g., shared component libraries to help prevent widespread breakage during application upgrades) and patterns
  • Bots should be part of your Configuration Management Database (CMDB) and IT Service Management (ITSM) strategy
The last point is a key one: without ITSM awareness, the change management process for applications can be fraught with even more peril than normal. A bot that relies upon an application that is changing underneath it is a recipe for an outage.

3. “You can do it without app owners”

Application owners are the subject-matter experts in their domain. A bot designer who assumes that he or she knows enough about the application to automate activities without consulting the app owner could be making a mistake. For example, does the bot designer know:
  • What are all of the planned maintenance or freeze windows for the application?
  • Are there peak processing times that bots should avoid (e.g., month-end, quarter-end, etc.) to prevent a “bot-based denial-of-service attack”?
  • Are there stability issues in certain corners of the app that could hinder automation?
My personal recommendation is to use an app-owner questionnaire to root out a set of key characteristics of the application to reduce the risks associated with building bots that depend upon it.

2. “Calculating ROI is simple”

Building a business case for a particular bot often appears deceivingly simple. On the benefit side, examining transaction counts, cycle times, exception rates, and other variables may be a good start. But we have found that these metrics are often insufficient to understand overall benefit (e.g., cycle time reduction, error-rate reduction, rework avoidance, etc.). Similarly, on the cost side, we recommend a holistic view of TCO (total cost of ownership): apart from the bot license and maintenance we recommend calculating the costs of infrastructure, operations/support personnel; and related elements of the solution. Further, from a risk perspective, not all bots are created equal. As part of an ROI calculation, consider using a risk framework to address potential challenges in creating bots or maintaining benefits over a relevant time horizon. Without a disciplined approach to calculating ROI, your bots may not meet the desired benchmarks that represent a successful implementation.

1. “It’s easy to maintain the benefits of RPA”

No matter how good a job you do at calculating ROI for your RPA projects, there remains a key challenge for those building bots: namely, how do we maintain the benefits of automation? We would simply state that maintaining benefits over 12, 18 or 24 months is a frequently overlooked area of the RPA lifecycle. What can erode the benefits of your bot investments?
  • Failure to understand the risks associated with automating a given process
  • A limited understanding of the characteristics and lifecycle of underlying applications
  • Lack of line-of-sight into the IT strategic roadmap, which could render your automation obsolete
  • Missing or incomplete ITSM data that ties the bot to the rest of the IT landscape, which could lead to outages during otherwise routine and low-risk change management processes
At the end of the day, RPA governance is a critical and foundational element of an automation program. Without effective governance, the benefits of your bots can degrade quickly and — sometimes — abruptly.

Rationalized RPA

As stated earlier, RPA is not a panacea when it comes to legacy integration challenges, operational inefficiencies, and long overlooked technical debt. It is certainly a valuable tool — one that continues to evolve at a rapid pace — which can drive significant business benefit with modest expenses. But a rational, holistic and disciplined plan to designing, building and operating bot ecosystems is, in our view, a necessity for building a successful RPA program. Doug Ross is a National Solutions Architect for RPA and AI at Sogeti USA, the engineering and technology arm of Capgemini America. You can contact him at doug.ross@us.sogeti.com .

About the author

VP, National Solutions Architect – AI and RPA | USA
Doug Ross is the former CTO at Western & Southern Financial Group, a Fortune 500 diversified financial services company. While there, Ross won a ComputerWorld Premier 100 Award as well as an SMA Innovation in Action Award for innovative solutions that helped the organization open new and highly profitable distribution channels.

    Comments

    Leave a Reply

    Your email address will not be published. Required fields are marked *