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 is really capable of is worth a reality check.
What is RPA?
Robotic Process Automation (RPA) is a technology that uses software robots to automate repetitive tasks and manual processes to execute and enhance the performance of repetitive and often mundane work.
RPA can include software robots, 鈥渂ots鈥� for short, that simulate the activity of users operating software manually, by virtually performing 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). PRA has been used in mainframes as early as two decades ago, and a basic version of it has been used 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.
RPA can provide solutions to hundreds of pain points across an organization. It enhances work performance 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 these processes take up significant time that could be better spent on work that requires more human thinking and empathy. Getting bogged down in these processes can ultimately throttle your organization鈥檚 ability to grow and scale.
- High value processes are extremely important to an organization. RPA processes create a better customer experience and reduce user 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.
With automation opportunities 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鈥檙e 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 announces that an update is available, if an application crashes, if a page is unavailable, etc., bots won鈥檛 always know what to do. If an application鈥檚 UI changes without the bot builder being aware of it, bots won鈥檛 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.
A Bigger Issue to Think About
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, and there is 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 application programming interface (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鈥檚 repertoire.
