Robotic Process Automation (RPA) has had a lot of deserved success in businesses seeking to carry out basic, repetitive tasks ordinarily handled manually; think about filling out forms, extracting data from web pages, and so on. For these specific kinds of activities, RPA works great – it accelerates throughput, minimizes errors, and lowers some kinds of costs.
That said, when organizations try to use RPA to automate business processes, they start to run into trouble. There – I said it.
Mike Fitzmaurice is Chief Evangelist and VP for North America at WEBCON.
Contrary to its name, RPA is not actually designed for “process” automation at all. The key is the term robotic, as RPA is designed for highly-repetitive manual activities. These micro-workflows are designed to simulate human operations at a computer screen; they’re task-focused far more than they are process-focused. They definitely eliminate manual activity, but their ability to automate anything other than basic decision-making is out of scope.
A good example is filling out a form – a data entry task for which RPA is well suited – versus using that form as part of a larger approval or onboarding process that likely involves multiple steps, reviews/approvals, and input from a variety of people across an organization.
Unfortunately, too few organizations recognize this important distinction. To be fair, RPA vendors don’t actively position their tools as “next-generation BPM.” The problem stems from the fact that in their zeal to embrace automation, many organizations, or, if we’re being honest, the consultants that advise them, end up over-extending and over-using RPA. It’s another case of the law of the instrument in action. And it can often lead to failed projects, fragile hacks to compensate for platform limitations, and frustrating results to show for it.
RPA itself is not the problem. I love RPA. But it should be one tool in a well-curated toolbox. It should be combined with a Digital Process Automation (DPA, also referred to as Business Process Management, or BPM for short) solution. It’s about strategy and tactics; both matter, and both require the appropriate tools and skills.
Why use RPA?
There are plenty of reasons for making use of RPA technology, but I’d like to focus on its use in more elaborate projects involving two or more systems that need to be integrated with each other. In those scenarios, having an application call each system’s application programming interface (API) is a lot more efficient, scalable, and reliable – but there are four primary reasons why an organization might turn to RPA instead:
1. There isn’t an API available to handle interaction and integration with an application. An API might even be available, but it could lack functionality, be incredibly cumbersome to use, or require additional licensing.
2. The person or team handling the automation lacks the expertise to work with an API, but they are capable of using RPA to record interactive screen sessions and indicate which information should be entered/read automatically.
3. The people responsible for a system do not want to allow the application developer access to APIs; it could involve service account provisioning, training, testing, and monitoring resources that are not available at present.
4. The goal is to create a proof of concept (POC), and time-to-delivery of an initial prototype for eliciting feedback matters more than other circumstances. This could be a short-term approach with an eye toward using an API-based approach later on.
RPA limitations
Despite its utility, RPA is ill-suited to being a panacea. Common use cases illustrate three prominent tactical limitations:
1. If the application is updated and its user interface changes, an RPA bot becomes invalid. It won’t see what it’s expecting to see and won’t know how to react.
2. Every bot session consumes the resources of a user browser (or even a full desktop) session; a browser or desktop application is being instantiated. It can get very resource intensive at scale, and it’s common for RPA vendors to price their platforms based on the number of bots running simultaneously
3. Some integration depends on identifying database records by unique IDs. While database queries and function calls use them, they aren’t always displayed on the screen. Even when a master item’s ID is visible, there’s no guarantee that visible IDs for line items or linked data (e.g., a purchase request’s equipment list and preferred vendor info) will be displayed. And if an ID isn’t visible, RPA can’t screen-scrape it. Mitigating this by simulating an interactive search can carry risks.
Task versus larger process
But far and away the biggest limitation is strategic, not tactical, and it’s the one referenced at the start of the article: a misunderstanding on the part of users as to what constitutes a task and what is a larger process.
To illustrate, let’s expand on the form-fill (task) versus approval/onboarding (process) example used above. Consider employee onboarding, something that everyone should understand, and which might include:
- Extending an offer
- Negotiating a salary
- Determining a start date
- Allocating office space or making remote work arrangements
- Allocating parking privileges
- Generating security passes and keys
- Procuring and shipping equipment
- Creating network credentials
- Allocating licenses for a variety of software that supports single sign-on
- Creating usernames/passwords for software that doesn’t support single sign-on
- Attending orientation
- Explaining expense reporting
- Explaining travel procedures
- Registering benefits package choices
- Setting up payroll and direct deposit
- Scheduling a review at the end of the initial probationary period
RPA can potentially help speed up several parts of onboarding a new employee. But each of those potential RPA implementations represents an isolated task. The entirety of the onboarding is a process, one that involves multiple parts of the organization (e.g., HR, IT, the group that hired the employee, etc.) and is an amalgamation of individual tasks, decisions, and workflows.
In fact, some of these steps cannot be automated, but they should nevertheless be identified, modeled, monitored, and audited. It’s an example of a managed process consisting of myriad activities, some of which are automated and some of which are not.
The overall point is that RPA is a powerful tool for what it does well – automating tasks – but is ill-suited when targeted at overall digital transformation initiatives. RPA could be used sparingly or widely, but it is a piece, not the whole, of the puzzle.
It comes down to an approach
Given the above understanding of what constitutes a robotic task, then how should an organization think about business process? I’d suggest the following oversimplified yet useful rule of thumb: when you’re thinking about how something should be done, then you’re likely thinking about automating tasks; when you’re thinking about what or whether something should be done and who/what is required to accomplish it, then you’re likely thinking about process.
This can have a significant effect on project management. For example, someone focused solely on activity automation will spend most of their time with an RPA tool but will (hopefully) need to stop and explain what they’re doing to others, and that will require some diagramming/documentation tools. Still, other tools might be needed to model and store data or analyze process metrics. Business process tools tend to work the other way: goals and steps are front and center, while implementation details are kept under the hood to improve clarity.
Fitting RPA into larger processes
RPA isn’t “next generation business process automation.” In fact, RPA isn’t about processes at all. Not by itself, anyway. But business processes typically involve countless activities, and RPA is one of several tools that can be of immense help. An organization’s repertoire ought to include RPA and DPA/BPM tools – among many others.
It’s not just a toolset – it’s a mindset as well. Some automation efforts targeted solely at tactical problems certainly reduce annoyances, mistakes, and time. Many, many independent uses of this approach can add up to aggregate organizational benefit. But that’s more digital assistance than digital transformation. The same things are being done; they’re just not being done manually. The benefit is incremental.
I’d be tempted to conclude with a plea not to think of DPA/BPM as “old school” and RPA as a young upstart that needs to be reined in. Not only is that trite, but it’s inaccurate. RPA isn’t new. Not the idea, anyway. We’ve used this approach for decades when integrating with mainframes, referring to it as “screen scraping.” RPA is, in a very real sense, “page scraping” or “app scraping.” But that doesn’t stop it from being valuable. But like screen scraping way back when, its real value is realized when it’s used a piece of a much bigger picture.
DPA/BPM is more than just glue, by the way. Processes are far more than mere sets of tasks, but even if one looks at nothing but tasks, processes often orchestrate them in elaborate patterns; think about layers of coordinated subtasks, delegations and substitutions, consultations, and roll-up status reporting. And some of these tasks are elaborate workflows in their own right. These kinds of patterns aren’t supported by every DPA/BPM platform on the market, but they’re definitely out of scope for every RPA tool out there.
Summary and conclusion
No single tool is all things to all people. Not only are BPM and RPA two very different technologies aimed at two different kinds of business problems, but they’re also two technologies that can work together very, very well.
The problem isn’t with the technologies, or with vendors. The issue is the corporate impulse to procure and use as few tools as possible and the willingness of some consultants and pundits to push RPA as The Next Big Thing. Each of these issues is understandable, but counterproductive. It’s yet another time that a careful, sober, steady approach to innovation is the one that will win the proverbial race.
We've featured the best productivity tools.
