Background
There’s a lot of buzz about robotic process automation (RPA) these days, and many companies I consult for are either experimenting with RPA or performing small-scale implementations of it. Now that I’ve been exposed to several modern RPA initiatives, I’m seeing some repeatable patterns, and thought I’d write a quick blog article about them.
A Trip Down Memory Lane
Over twenty years ago, I cut my teeth in information technology (IT) as an intern for a government agency. My career commenced within the deepest bowel of the beast: the infamous help desk. I dealt with angry business users, PCs issues, server hard disk failures, you name it.
The agency was in the midst of a small, yet ambitious IT transformation. At the time, they were moving away from “mainframe everything” and started to embrace PC-based desktops and servers. They were also moving away from the ancient office suite “Novell” to Microsoft Office. Yet for that transformation to be successful, there was a huge hurdle to overcome: converting thousands of Novell WordPerfect files to their Microsoft Word equivalent format. A bulk import/export tool remained elusive, so many alternative options were discussed; everything from consultants to intern labor to co-existence of both applications.
One day, arriving to work early as usual – something curious caught my attention: my colleague’s unattended PC. His mouse was moving about on its own, and windows were opening and closing at a rapid pace. For a moment, I thought my coworker was remotely controlling his PC, but the pattern repeated over and over again: open Microsoft Word. Browse to a particular folder. Grab the next WordPerfect file and open it. Save it as a Microsoft Word document. This process repeated over, and over.
Years later, I would hear about something called “RPA.” The marketing buzz was intriguing. Yet something about this technology was eerily familiar…
RPA Pros and Cons
Robotic process automation is a form of user-interface automation. Unlike application programming interfaces (APIs) which were designed for machine-to-machine communication, user-interface automation mimics a human user in order to manipulate a user interface.
People often wonder: why use one form of automation over another?
APIs
Application programming interfaces were designed for fully “unattended” operations, which means no interactive human intervention required. APIs use machine input/output rather than a graphical user interface. (Think text formats like JSON and XML as well as binary formats.) Some pros and cons of APIs:
Pros:
- Built with automation in mind (and are completely decoupled from the user interface)
- Use secure API credentials with limited scope
- Should scale well to handle many different API callers
- Typically use versioning, which enables API consumers to gradually upgrade to newer API versions without suffering major breakage
- APIs are typically built and maintained by professional software vendors
Cons:
- Require developers / IT staff to integrate with (e.g. develop API consumer applications)
- APIs aren’t always available in all products
- APIs are often limited in their capabilities
- Some software companies charge for their APIs, or require a pricier plan to gain access to APIs
RPA
RPA is something that is “bolted on” to a user interface, and therefore is a separate solution from the application being automated.
Pros:
- Can be stood up with relatively low technical expertise
- Can provide much-needed automation when other means (e.g. APIs) don’t exist
Cons:
- RPA routines (“bots”) need to be trained initially, and often re-trained when the environment changes
- Bots need to be monitored as they can “fall over” when unforeseen events occur
- Since bots mimic human users, they often need user credentials, which are typically far broader than API-based credentials
Common RPA Use Cases
There are many examples of RPA use cases, but to rattle off a few I’ve actually seen:
- Invoice processing – parsing unstructured / semi-structured PDFs submitted by vendors to accounts payable.
- Software testing – security and QA teams often use RPA to test the UI components of applications
- Repetitive end-user tasks – See the introduction paragraph where I explain converting thousands of WordPerfect documents to Word documents, one-by-one
- Malicious use cases – Yes, even bots can be bad! Common examples include click-fraud farms and walled garden web scraping.
Exercising Caution
RPA really shines in specific use cases, such as testing or providing a quick fix of automation where other means simply don’t exist.
However – I remain very, very cautious about recommending RPA as a long-term solution to business process automation. The reason why is due to the fact that RPA is more of a reactive, versus proactive solution. It’s a bit like duct tape: if your bathroom plumbing springs a leak and there’s no expert plumber nearby, you grab some duct tape and stop the leak. It’s ugly, but it gets the job done. Yet when that pipe inevitably leaks again, you’ll be right back to the same set of choices: more duct tape, or call in a professional?
In the invoice processing example, RPA is the duct tape that alleviates some degree of manual labor. (I.e. an accountant scanning a PDF, matching to a PO number, and so on.) Yet the professional plumber approach is not allowing unstructured (and often insecure) PDFs in the first place. Rather, vendors should be submitting invoices through a supplier portal which requests all required information and cleanly maps to appropriate database fields.
Another word of caution relates to the fragility of bots. APIs are typically versioned to maintain backward compatibility, and responsible vendors announce changes to APIs well in advance. User interfaces, on the other hand, can change on a moment’s notice; breaking one or many bots who were previously trained to map to those prior UI layouts.
Additionally – RPA vendors often tout the ability to “bypass the IT department” so that business users are empowered to automate quickly. There’s some degree of truth to this, and if I sat on the business side of the house, you better believe I wouldn’t want to be overly dependent on the IT department for my project’s success. That said, many of these RPA solutions have their roots in Microsoft Windows user interface automation, and consequently, require on-premises infrastructure to operate. Examples include Windows Servers, Windows Desktops, Microsoft SQL servers, and so on. So who is going to manage all of that? It’s either the IT department, or a third-party partner. In the case of the latter, the ROI case for RPA becomes less attractive.
Finally, let’s not forget about security. Bots often use user credentials versus API tokens; especially in scenarios where interactive logins to desktop interfaces are needed. This can be challenging in modern, secure environments which require password changes and multi-factor authentication that routinely changes. (You may need to log a bot in every few hours by providing an MFA token.) And as noted, user-level credentials are typically broader in access than their API token counterparts.
Summary
I don’t intend to be harsh or pessimistic regarding RPA. I simply encourage all to be aware of RPA’s capabilities and use cases before making significant investments in time and money. Understanding where RPA fits in your repertoire of tools is integral for proper application of this technology. It’s not a panacea for automation. Then again, nothing is.
