Half a Dozen Robotic Process Automation Myths
Android robots that resemble humans closely, but not perfectly, can provoke negative feelings of dislike and eeriness in humans [aka the “Uncanny Valley” effect] (Mathur et al., 2020).
The sentiment of 'uncanniness' has unfortunately made its way to Robotic Process Automation (RPA) efforts. When people learn about RPA, they envision a physical robot being involved in keyboard presses, clicks, and so on.
Even after some time has passed, the 'robotic' part continues to throw stakeholders off and sow confusion. For example: 'even if it's not a physical bot, doesn't that mean that it may still become a bad actor that starts wrecking havoc on our systems?' This type of concern is valid, given that people are conditioned to not trust robots through various films, books, and other media.
RPA should simply be called ‘Process Automation’ or 'Digital Automation.' Robotic Process Automation makes sense in the scope of a fulfillment center which integrates process automation with physical robots. Even so, the physical automation industry refers to the technology as 'robotics' and leave it at that.
There's also an imperative for consultants to start referring to RPA as ‘Intelligent Process Automation;' especially given the growing integration between RPA and Artificial Intelligence. The term 'Intelligent Automation' (IA) leaves a lot to be desired as well since not everything is intelligent. Some bots are merely scripts and have nothing to do with AI.
Given the popularity of the term 'RPA' you'll see it sprinkled throughout to make this content more accessible.
Robots will replace people
Contractors that implement automation solutions often equate Full Time Equivalent savings in a manner that makes it easy to confuse with Full Time Employee savings. For example, if you automate 20% of five employees’ tasks, you end up with an ‘FTE of 1' for a given year.
This proclamation sounds great on sales pitches but doesn't pan out the same in the real world. As they say, 'the devil is in the details,' and if you want to understand the ramifications of this myth/oversimplification, you will benefit from reading The Enterprise Evaluation Dilemma.
Robots run all day, and that makes them great
Consider the study of Asatiani and Penttinen (2016) which states that ‘the promise of RPA is not only to reduce costs (since robots can work around the clock with no salary), but also to eliminate the problems with management and miscommunication...’
It's clear that even research writers have gotten wind of the ‘robots don't need a salary can work all day long’ idea — this is a big win for RPA vendors but also a big red herring for those considering automation solutions' pros and cons.
Most businesses prefer to limit robots’ operations to a specified time frame. Most robots couldn't run 24/7/365 because they would need to go down for maintenance. One might even argue that a bot has a ‘salary’ measured in the resources required to keep it running (and licensed). Nothing is truly ever 'free.'
Most companies also prefer to keep automation running during business hours. If something goes wrong during the day, then not only will customers or employees be more likely to notice, but it'll also get fixed during working hours.
Even employees can work around the clock, but doing so requires a greater investment in maintaining shifts and dealing with shift change-overs. Anything can run around the clock (be it machinery or servers) and the selling point of bots being able to do this is neat but not the end-all-be-all feature.
Don’t let myths impact your company's decision making!
Robots are just macros
Thinking about robots as macros is fit for purposes of understanding what robots are from a development perspective. However, stating that they are ‘just’ macros erodes the value of what RPA truly is.
Let’s consider something slightly unrelated to RPA ... there are languages out there created for software development that have no purpose other than to be esoteric. One of these languages is called 'Brainf**k' and is Turing complete (meaning that it can be used to simulate any Turing machine). However, the language isn't practical or fit for use — it was created was merely to be unique.
If one were to look at a language such as Python and C# and state that it is ‘just Turing complete’ it'd be incorrect to put these two languages in the same boat as Brainf**k. You decide for yourself by examining a code snippet that prints 'Hello World' using this esoteric language:
++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
And compare that to Python:
print("Hello World!")
In the same line of thinking, RPA does fulfill (at a fundamental level) the same type of activity that an Excel macro would. However, what makes it unique is that it can accomplish automation within other Windows applications, within browsers, and across VPN connections.
RPA also comes with full-fledged development suites which doesn't compare to any little macro tool.
A typical macro is difficult to scale dynamically out of the box (for example, the process starts running on one computer, but if volume increases, it spins up execution on 10 more servers). In contrast, companies such as Blue Prism and Automation Anywhere offer orchestration capabilities that can execute thousands of transactions and distribute them across machines. If something goes wrong, the transactions are retried, then the exceptions kick out to a person to handle or document the issue accordingly. All of this can be reported on and analytics can be used to identify exactly how long processes are taking to run, where there are hang-ups, and how much time has been saved compared to completing the work manually.
You can think of RPA as having some macro capabilities, but they aren't merely macros.
RPA development doesn’t require the IT department
The concept of ‘citizen developers’ has been around for a long time. It refers to the concept that employees who aren't traditionally trained in software engineering or IT can develop IT solutions (Definition of Citizen Developer — Gartner Information Technology Glossary, n.d.).
Many professionals have a gripe with this term as it is quite vague. There are no-code solutions, low-code solutions, and high-code solutions available for solving IT gaps. Being a developer, even in a no-code tool set, requires a certain amount of logic and programmatic thinking. Adding 'citizen' in front of it erodes the value one expects from a developer.
Given the existence of ‘CSS Developers' who write cascading style sheet markup, the industry should be able to refer to a 'citizen developer' properly as a ‘Jr. RPA Developer' - someone who uses mostly no-code or low-code tools to deliver value through RPA.
The terminology is important because it means that the same departments which manage software development would have to train, support, and coach Jr. RPA Developers. It would make it clearer that as much as RPA vendors want you to believe anyone can build RPA, it's just not scalable without meaningful training or IT oversight.
Even though a junior RPA developer may be able to deploy attended bots that run on users’ machines, they'd have a hard time deploying bots to servers for higher-volume tasks. By the point that orchestration is required, a need also emerges for a senior developer (or solution architect) to design RPA infrastructure. There's also emerges a need for IT resources to provision servers and credentials that a bot can use. Not to mention that a data team may be needed for storing RPA execution data for record retention, visualization, and other purposes.
The myth that a business user can easily be trained in RPA to automate their own mundane tasks, and that of coworkers, can be a slippery slope that leads to RPA implementation risks and failures.
RPA’s only benefit is cost reduction
If one were to look at RPA as being a driver for improvements which optimize the bottom line, that'd be true. It'd also be true for HR, Legal, and other departments. Dollar savings are a desired result of most businesses given that the goal is to generate as much revenue with as little expense as possible.
However, viewing RPA as an initiative to reduce costs narrows the opportunities available for augmenting businesses. For example, if it costs a lot of money to have employees on for incident management and they come in the next day disgruntled that they had to wake up in the middle of the night to work - you might consider the benefits of automation. In some businesses, RPA can handle basic resets, troubleshooting steps, or at least support those handling incidents in communications, logging, and other time-consuming tasks.
If automating the top 20% most repeatable incident activities helps reduce or improve 20–40% of the incident calls, then that'll literally help your employees sleep better at night. It'll also improve customer experience. Having less turnover from employees will make sure that those with the most knowledge will be more likely to stick around, which will also improve the customer experience. Less expenses on hiring, as well as higher renewal rates for customers, all lead to increased profits.
In other words, if you had an opportunity to automate a process but it'd cost 20% more to run it in an automated manner to receive 80% faster ticket resolution or 25% higher satisfaction, would you do it? If you’re in a competitive landscape where you’re fighting for market margin and your customers’ contracts are worth so much more than the cost of automating a process, you might do it even if within a specific department (such as operations) the direct cost appears to not exceed the benefits.
RPA initiatives are inexpensive
Although the cost of automation infrastructure and licensing may seem affordable to enterprises that have a solution-fit, there are other costs that need to be factored accordingly.
What often becomes prohibitive for companies is the consulting services often require to begin RPA initiatives (and sometimes to operate them). There’s also the investment required internally that spans from business analysts and end users' time, executives' time for governance, and much more.
Management will need to establish a proper RPA program with proper governance, organizational support, and a clear strategy for success. If companies choose to hire internally, there’s also the ramp-up time that needs to be considered.
For large enterprises with a plethora of processes that have a high-volume and are repeatable, chances are high that RPA initiatives can become profitable within a few years. Achieving profitability requires managing automation expenses effectively, tracking all benefits, and meeting goals that drive leading indicators.
If an RPA program initiative gets off on the wrong foot due to misunderstandings such as the ones propagated by the myths in this article, then it can become an expensive undertaking. If those issues aren't resolved promptly, the entire program might go belly up
Now that you've read some of the inherent challenges, remember that you have the power to keep these issues from manifesting within your own company.
Footnote:
The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'
References:
Asatiani, A., & Penttinen, E. (2016). Turning robotic process automation into commercial success – Case OpusCapita. Journal of Information Technology Teaching Cases, 6(2), 67–74. https://doi.org/10.1057/jittc.2016.5
Definition of Citizen Developer - Gartner Information Technology Glossary. (n.d.). Gartner. https://www.gartner.com/en/information-technology/glossary/citizen-developer
Mathur, M. B., Reichling, D. B., Lunardini, F., Geminiani, A., Antonietti, A., Ruijten, P. a. M., Levitan, C. A., Nave, G., Manfredi, D., Bessette-Symons, B., Szuts, A., & Aczel, B. (2020). Uncanny but not confusing: Multisite study of perceptual category confusion in the Uncanny Valley. Computers in Human Behavior. https://doi.org/10.1016/j.chb.2019.08.029