Over the last several years, Robotic Process Automation (RPA) has drummed up excitement among IT and business decision-makers alike. It promises a bright future of humans leveraging robots to automate repetitive and mundane tasks, freeing themselves up for more creative work. But it's worth a reality check.
It offers software robots, "bots" for short, that simulate the activity of users operating software manually. They virtually perform keypresses and mouse clicks. They read text from web pages and/or desktop application windows. You can script their behavior, including some conditional branching, and treat that script as a reusable component (a web service, for example).
It's not new. We did this with mainframes two decades ago. We've been doing a basic version of it with recorded macros in applications like Word and Excel.
For specific kinds of activities – the more repetitive, the better – RPA works great. Do your users have to run two applications side by side and manually re-enter information from one into the other? Get a bot to do that instead.
RPA is usually talked about in terms of automating repetitive tasks, but this is usually with an eye toward that bot being exposed to other applications, so they can invoke that bot as a remote component, much like a web service or a remote procedure call.
But shouldn't we be calling those applications' APIs directly instead? Ideally, yes. But sometimes, what's ideal isn't possible.
Sometimes, an application's API doesn't' exist. Sometimes, the vendor charges extra for it. Sometimes, the API is terrible and arcane. In situations like this, an RPA bot can interact with the application's user interface but still appear to other applications as if it were an API.
Not every application's curator is on board with having the system they curate used by someone else. They may block access to APIs. As long as a would-be integrator has access to that application's UI, they can wrap it in a bot and communicate with the bot instead.
Given that a lot of bots are initially built by recording interactive sessions, it can take a lot less time to build a bot than it would take to get API credentials, learn how to use it properly, and actually configure the remote requests. Even when API-based access is the eventual goal, RPA bots might be a good fit for an initial prototype.
RPA sounds attractive, but there are a number of caveats that cannot be ignored.
If you're simulating user activity, you need to run the same environment a user would run. That means browser sessions, and perhaps even desktop sessions. If you want to do this at scale, the logistical, licensing, and hardware costs can add up.
The problem with a bot impersonating a user is that bots – without a lot of foresight – aren't prepared for unexpected circumstances. If an application displays unexpected error messages if an operating system announced an update is available, if an application crashes, if a page is unavailable, etc., bots won't always know what to do. If an application's UI changes without the bot builder being aware of it, bots won't always know what to do.
If I can write a bot that accesses a service using my credentials and make it available to others, I may be effectively granting them the same access to that service that I have. Not everyone will be comfortable with that. Policies can mitigate this – if bot builders heed them.
RPA is, regrettable, poorly named. It's not really robotic process automation. It's robotic task automation. There's nothing in RPA that addresses actual end-to-end business processes, case logic, overall strategic goals and progress against them, and countless other things that are normally the purview of Business Process Management/Digital Process Automation (BPM/DPA).
For example, solving an IT helpdesk ticket can entail reviewing a ticket, assigning it to a caseworker, searching knowledge archives, conferring with the subject matter experts, verifying with the user whether the ticket can be closed, etc. RPA can help with some of this, but the larger process requires a lot of judgment (assessment and decision making); e.g., the manager decides to whom a ticket should be assigned, IT support decides to loop the manager back in with questions about a particularly difficult ticket, the manager or IT Support decides to cancel or reject a ticket, etc.
Without BPM/DPA, RPA merely speeds up the work and maybe reduces errors in places. But without BPM/DPA, there's little chance of transforming it.
The answer here isn't difficult. BPM/DPA processes can make use of any number of RPA bots to accomplish individual tasks as processes progress from start to finish. They already make use of API invocations, so why not bots, too?
Use BPM/DPA to determine what should be done, what its status is, which resources are in play, whether results are addressing goals, and what should happen next depending on what already happened. Use RPA – and APIs, and sometimes manual human task assignments – to execute the tasks that the process needs to have completed.
As long as an application architect is cognizant of the relative – and complementary – roles of RPA and BPM/DPA, RPA becomes a valuable tool to add to an organization's repertoire.
Mike Fitzmaurice, VP of North America and Chief Evangelist at WEBCON
Mike Fitzmaurice, WEBCON's Chief Evangelist, and VP – North America has more than 25 years of product, consulting, evangelism, engineering, and IT management expertise in workflow/business process automation, citizen development, and low-code/no-code solution platforms & strategies. His decade at Microsoft included birthing technical product management and developer evangelism for SharePoint products and technologies.
