Business processes involve performing a sequence of tasks, such as registering a sale, computing value-added tax, sending an invoice, packaging and sending the product, updating the inventory and accounts receivables, etc. These tasks have traditionally been carried out by one or more human operators, with associated issues being a description of duties of each operator, information shared or processed, possible operator errors such as typos or transcription errors, labor costs, and speed of the process. With the emergence of computers, more and more of these traditionally human tasks were automated, i.e., computers were programmed to perform them.
Robotic process automation (RPA) refers to using a virtual robot (more affectionately called “bot” in industry jargon) to perform the tasks that human operators perform by following simple predefined rules such as opening a file, reading a record and sending an email.
Partially driven by the existence of bots that perform these tasks, RPA is currently in vogue. Literature suggests that audit use RPA for its own tasks, although some shortcomings are cited.1 In other words, RPA interest is twofold:
- Enterprises ask audit to evaluate whether a place for bots exists in its own internal practice such as continuous auditing activities where a bot produces a list of exceptions to predefined criteria.
- Enterprises task audit with evaluating RPA risk given its adoption. At the same time, audit must deliver the message that sometimes RPA is used to fix poor planning and, in so doing, creates further risk that would not exist if the whole process had been planned properly.
As alluded to previously, (non-RPA) automation, i.e., software to perform a sequence of tasks, was introduced in the 1970s, if not before. For example, a program could check for a notification in the form of a file, read this file and act on the information. Such an action on the information might involve starting or stopping another task. Such standalone automated programs, often called demons, would run in the background and could, for example, check a directory every minute, discover a new file, open and read that file, and insert selected contents into another program such as a database; or they could take a backup every day at a specified time, using, for instance, the Unix cron command. Applications also communicate in other demonless ways without human involvement or knowledge of the actions, although the human operator is the one who started the application. For instance, when a user uses Hypertext Transfer Protocol Secure (HTTPS) for web browsing, the browser and server negotiate the parameters necessary for a secure connection automatically, i.e., without the user being involved or necessarily aware of any details. The point is that automation has been successfully employed for nearly half a century before RPA. So why is RPA needed? To answer this question, it is important to look at how RPA works and how it differs from plain old automation.
RPA sometimes works analogously to plain old automation and adds new functionality such as reading and deciphering a web page Hypertext Markup Language (HTML), locating data and buttons, reading the data from the web page HTML code, processing data and, ultimately, exporting/presenting results. This works similarly to the former demons, has the same effect a human operator would have, and typically works well (e.g., open a file, read a record, copy or make a decision based on a rule, and process it by sending an email or opening a browser and typing). However, as a result:
- Human operators must store any passwords needed either in cleartext or reversibly decryptable form in the RPA. Unless the application in question works with hash injections (in which case the encrypted password is enough), anyone with access to the RPA can retrieve the passwords. This, of course, is no different in principle than the former demons.
- Particularly for non-web-based applications, RPA may use “screen scraping,” which is considered a last-resort measure and rightly so.2 Screen scraping uses Optical Character Recognition (OCR) to read the screen output just as humans do,3 but does this make sense? Data originally exist in digital form, but RPA requires printing them on the screen and reading them back to digital form. What if the OCR misses a decimal in a US$1000.00 invoice figure and reads one million instead? Or maybe a dust particle sitting on the screen is misread for a decimal point in an accounts receivable form. Human operators cannot easily read digital signals, so visual representations are warranted for humans. However, reading digital signals is the computer’s most natural function. Some vendors claim4 100 percent OCR accuracy and, indeed, sophisticated algorithms using artificial intelligence (AI) are used to improve OCR robustness,5 but this poses risk, especially to audit: Nothing works forever unattended error-free, and vendors typically do not insure against errors or cover possible losses. Indeed, research cites arguments against OCR, finding that “barely imperceptible altercations to images can easily fool a trained deep neural network.”6 Moreover, OCR typically focuses on recognizing characters; it is not always clear if insurers protect against missed or misread decimal points. Could a bad pixel on the screen, dust or lighting issues result in such an error? The literature also lists choosing to automate via RPA, a process where errors are “disproportionately costly,” as an RPA pitfall.7 It is also understood that protection against errors and fallback solutions are not generally available for (screen-scraping) RPA solutions.8
The correct solution is to automate the entire process. Instead of printing on the screen and then reading the original digital data, what could be simpler than automatically reading the digital data? Not only is this less error prone, but it is also much faster and more efficient.
IF HUMANS WANT TO DO A THOROUGH JOB OF CHECKING, THIS PRACTICALLY MEANS REPERFORMING THE TASKS COMPLETED BY THE BOT, HENCE NEGATING ALL ITS ADVANTAGES.
Why is screen-scraping RPA even discussed as a viable solution? The answer is for a variety of reasons, such as closed proprietary systems with poor or no Application Progamming Interfaces (APIs) or interfaces, legacy systems with code written in obsolete programming languages, and/or poor design of these systems. RPA appears as the lesser evil. The system is often designed to employ human operators for routine tasks from the start or the needs evolved and were extended, again using human operators for routine tasks. Of course, the correct solution is to automate routine tasks in the first place, with data available to automated routines that perform these rule-based tasks without the need for humans or screen output. In addition, source code is often unavailable or unmodifiable for either ownership, budgetary or readability reasons, so that automation cannot be built on top or as an extension of the existing system. To be fair, RPA limits dependence on the coder (but increases dependence on the RPA solution).
To address issues such as the misreading of decimals, further human controls are introduced, which is problematic because humans tend to agree with bots, especially when the probability of bot error is low. If humans want to do a thorough job of checking, this practically means reperforming the tasks completed by the bot, hence negating all its advantages. If the task and risk are significant enough to require the attention of humans with questioning mindsets, the task should have been assigned to a human in the first place; better yet, the risk of such errors caused by the bot itself should be eliminated.
All this is not to say that risk associated with any IT system are nonexistent or should be downplayed. Such risk scenarios cover the entire lifetime of RPAs, but are not fundamentally different from those of any IT system from development, operation, ownership, security, logging, monitoring, business continuity, change management, incident management (yes, bots can fail and crash) to retirement.
WHAT AUDIT NEEDS TO KNOW AND DO IS TO BE AWARE OF THE RISK AND MAKE SURE RPA IS USED BECAUSE OF NEED AND NOT POOR PLANNING.
Conclusion
RPA is likely to remain in vogue, mostly due to the cost-cutting attraction of replacing humans with machines. What audit needs to know and do is to be aware of the risk and make sure RPA is used because of need and not poor planning. New systems should not be designed with RPA in mind; they should be automated by design. Access to open source code combined with the knowledge and skill to extend the code are significant advantages. RPA is automation, and automation is, in general, desirable, but screen-scraping RPA is an inefficient and insecure automation that introduces potentially significant risk factors that proper automation eliminates. Because many decision makers do not understand how RPA works, audit must indicate that screen-scraping RPA is a poor substitute for full automation and should be a last, not first, resort solution. To design a new system that automates with RPA makes no sense at all. Instead of looking for a magical action that will somehow fix all problems, the correct way is to think about the process and how to optimize it.
Additional RPA pitfalls exist and, indeed, a number of articles discuss RPA “failures.”9, 10, 11, 12, 13 These mostly focus on their application, not on the technology itself. Currently, RPAs are programmed to do repetitive, nonintelligent (i.e., rule-based) tasks that do not change; in general, they cannot handle unexpected scenarios such as a change in an application’s screen layout; nor do they work out-of-the-box, as customization to the relevant process is, in general, needed. Similarly, processes and tasks do not exist in isolation but typically require input and give output to other tasks and processes. These interdependencies are also important. However, if RPA is a hammer, the world is not a nail, and often better, safer and more efficient ways exist to accomplish the same ultimate goal.
Endnotes
1 Struthers-Kennedy, A.; A. Poulikakos; “RPA: First Steps to Greater Internal Audit Efficiency,” Corporate Compliance Insights, 16 November 2018, https://www.corporatecomplianceinsights.com/rpa-first-steps-to-greater-internal-audit-efficiency/
2 KPMG, “Internal Audit and Robotic Process 2 Automation: Considerations for Assessing and Leveraging Intelligent Automation”
3 Techopedia, “Screen Scraping,” https://www.techopedia.com/definition/16597/screen-scraping
4 UiPath, “Screen Scraping Software for Desktop and Web-Screen Scraping that Works Everywhere,” https://www.uipath.com/solutions/technology/screen-scraping
5 Sporici, D.; “Evaluating the Robustness of OCR Systems,” Coding.Vision, 7 September 2019, https://codingvision.net/ai/evaluating-the-robustness-of-ocr-systems
6 Qian, S.; “Adversarial Robustness of Optical Character Recognition (OCR),” Medium, 19 September 2019, https://medium.com/@sharon.qian.10/adversarial-robustness-of-optical-character-recognition-ocr-91eedc36ef6
7 AIMultiple, “20 RPA Pitfalls and the Checklist for Avoiding Them [2020 update],” 1 January 2020, https://blog.aimultiple.com/rpa-pitfalls/
8 Morphy, E.; “Why RPA Implementation Projects Fail,” CMSWire, 5 March 2019, https://www.cmswire.com/information-management/why-rpa-implementation-projects-fail/
9 Casey, K.; “Why Robotic Process Automation (RPA) Projects Fail: Four Factors,” Enterprisers Project, 18 June 2019, https://enterprisersproject.com/article/2019/6/rpa-robotic-process-automation-why-projects-fail
10 Hewlett, G.; “Five Most Critical Points of Failure in RPA Implementation,” Assurity, 12 November 2019, https://assurity.nz/insights/five-most-critical-points-of-failure-in-rpa-implementation/
11 Iluri, S.; “Top 10 Reasons Why Automation Efforts Fail,” Skan
12 Trefler, A.; “The Big RPA Bubble,” Forbes, 2 December 2018, https://www.forbes.com/sites/cognitiveworld/2018/12/02/the-big-rpa-bubble/
13 Leonards, A.; “What Can We Learn From RPA Failures?” Raconteur, 9 September 2019, https://www.raconteur.net/technology/rpa-failures
Spiros Alexiou, Ph.D., CISA, CSX-F, CIA
Has been an IT auditor for a large company for the last 12 years. He has more than 24 years of experience in IT systems and he has written a number of sophisticated computer programs. He can be reached at spiralexiou@gmail.com.