Over the last several years, Robotic Process Automation (RPA) has drummed up excitement among IT and business alike. It promises a bright future of humans leveraging robots to automate repetitive and mundane tasks, freeing themselves up for more creative work. But, what RPA really is, it’s worth a reality check.
What RPA Really Is?
Robotic Process Automation (RPA), a technology that uses software robots to automate repetitive tasks and manual processes to enhance the work of yours to execute repetitive and often mundane work.
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 have 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 you 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.
The solution to these and hundreds of other pain points across your organization? Robotic Process Automation (RPA) enhances the work of yours by interacting with websites, business and desktop applications, databases and people to execute repetitive and often mundane work. Think high volume, high value and high stakes.
• High volume, highly repetitive processes are easy targets for automation, as they take significant time that could be spent on work that requires more human thinking and empathy. Getting bogged down in these processes can ultimately throttle your organization’s ability to grow and scale.
• High value processes are extremely important to your organization, such as “money” processes like sales quotes or those that create a better customer experience and reduce churn.
• High stakes processes could land your company in trouble with mistakes or delays. Perhaps a copy-and-paste error results in a costly compliance violation, or a process backlog causes routine missing of deadlines.
When automation opportunities are everywhere, how do you prioritize them?
Why One Should Avoid RPA?
RPA sounds attractive, but there are a number of caveats that cannot be ignored.
It is Resource-Intensive
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.
It is Fragile
The problem with a bot impersonating a user is that bots - without a lot of foresight – are not 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.
It Can Raise Security Issues
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.
The Bigger Issue to Think
RPA is not really robotic process automation. It is robotic task automation. There is 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. 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.
