What RPA Is, What It’s Not, and Why It Matters


The grand promise of RPA so frequently falls short due to over planning, the inability to identify key automation opportunities, and a disproportionate focus on short-term objectives.

Hollywood pushes a dystopian view of technology, promoting a battle of good vs. evil in a quest to tell a good story and sell more tickets. It’s easy to see how the threat of technology resonates with many people, especially in challenging times. Over three recessions in the last 30 years, according to the National Bureau for Economic Research (NBER), a whopping 88% of job loss took place in “routine,” automatable occupations—meaning such jobs accounted for “essentially all” of the jobs lost in the crises. Meanwhile, McKinsey reports that more than 100 million workers may need to switch occupations by 2030, much of that due to automation and specifically robotic process automation or RPA.

But there is a less popular utopian view of technology — and its positive impact on society — that should be considered. Everyone up and down the organization is being asked to do more with less, and a major misperception for RPA is that automation will reduce operating costs by eliminating headcount. There is no doubt RPA enables a team to do more with less, but in practice, promises of fewer resource requirements too often fail to materialize. When automation is managed and implemented properly, it is about augmenting the human worker – not replacing them.

What then to automate?

There are certain activities where human expertise is unmatched. Concurrently, technology is generally superior for any computational tasks. It is not one versus the other. The ideal solution integrates the particular advantages of human and machine intelligence. There are no hard and fast rules on what to automate – or, more importantly, what not to automate. It varies based on the industry, organization, and activity. To determine whether you should automate a workflow, there are four vital actions to take before your company or department invests time, energy, and budget into a project. Those actions are:

  • Assess the overall process complexity: Leverage insights on the applications involved and the amount of human expertise required to help guide technology selection and determine the feasibility of success.
  • Decide if the process is mission-critical: Is this a necessary function, or are you automating just for the sake of automating?
  • Identify key metrics that will define a winning result: Whether it is speed or scale or accuracy or efficiency, you want to establish the goal line in advance so you know when you can celebrate. 
  • Document your processes: To improve tomorrow, you need to understand where you are today. It’s common sense. No one says they are going to lose 20 pounds but do not know how much they currently weigh. Unfortunately, too many organizations try — and fail — to automate a process that they do not fully understand how they complete today. 

Why RPA matters

Despite its reputation as a panacea for many enterprise ills, RPA often adds to an organization’s technical debt, which will eventually be a significant problem someone has to correct. There is no doubt RPA is fast, efficient, and less expensive than other methods. But it’s more of a band-aid than a cure. With analytics workloads, in particular, data is often generated in legacy mainframes where RPA is used to avoid costly API integrations and other fixes. It provides a temporary fix to get a few more years out of a legacy system, avoiding a costly, time-consuming, and error-prone system upgrade but ignoring the less obvious costs and inefficiencies associated with maintaining the older application like performance, compliance, and security. These issues would typically be addressed by an upgrade but are too often pushed off by deploying RPA as an interim solution. 

The grand promise of RPA so frequently falls short due to over planning, the inability to identify key automation opportunities, and a disproportionate focus on short-term objectives to show wins, regardless of whether they’re aligned with corporate objectives. Many organizations spend 12 to 18 months before getting a single bot into production. 

Jon Knisley

About Jon Knisley

Jon Knisley is Principal Consultant, Automation and Process Excellence at FortressIQ.

Leave a Reply

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