What is Robotic Process Automation?
NXT Gen Technologies’ client, Julio Gonzalez, Chief Information Officer of US Med in Doral, Florida contributed to our blog post this month. He shares his insight about RPA.
Is RPA a fancy macro? In short, yes. Robotic Process Automation, or RPA, has become a mature product born from the old keystroke recorders available for many years. Many large companies today use RPA, and you may have already experienced this when you are chatting with customer service or inputting data into a workflow system. RPA uses automation bots that have conversational Artificial Intelligence (AI), which simulates a human conversation and understanding of the customers’ intents and needs to perform automated tasks.
Back in the computer dark ages, when PCs had 640K RAM and Windows was a mere dream, some productivity tools such as Lotus 123 (think Excel’s grandfather) had built in macro capability. You could put together scripts that were simply keystroke sequences to automate repetitive work. More recently, keystroke recording tools could replicate any keystroke, and typically included mouse movements and clicks, to automate anything that could be repeated. The limitations with these recorders were any tasks that required significant workflow or timing, or locations of mouse clicks were random.
Today’s RPA tools are about as similar to keystroke recorders as skateboards are to cars. They both have wheels and get you around, but that’s about it! RPA tools such as UI Path, Blue Prizm, and Automate are complete development environments that offer full programming capability to handle any workflow and logic you can conceive of as well as capability to interface directly with many technologies (Windows Powershell, VMWare, etc.), business tools (Dynamics and Salesforce), and generic integrations using JSON and other APIs. As with so many technologies, companies such as Pega Systems (a strong supplier of workflow management software) and ServiceNow, among others, have blurred the definition of RPA by expanding their tools to include RPA type capability. In my eyes, while Pega and Service now have some RPA capability, it is the ability to replace the human interaction that makes the difference for me. Yeah, yeah, I know, slim difference. Here’s why….
US MED’s entry into RPA originated from the need to minimize the effort of a group of employees processing customers on a third-party website. The vendor providing the website would not provide an EDI service or webhook we could leverage to process the data and the employees were multitasking. Consequently, specific tasks were falling behind. Using the RPA tool’s Internet Explorer integration, we were able to develop a “bot” that did all the processing the employees were supposed to do manually. This was successfully done continuously and without interruption. The automation read from a database, accessed the third-party website, looked up the customer, entered data, collected data, and downloaded attachments, all while making decisions based on the type of customer and information provided on the screen. This kind of variability could never have been handled by a simple keystroke recorder, and the interactivity is not something Pega or ServiceNow could handle, to my knowledge. We have since developed several other workflows for other functionality on the same third-party website as well as other automations to handle EDI activities, scheduled report creation and distribution, etc.
Some of the more exciting RPA capability is taking workflows to the next level. Imagine a service desk ticket is created for a new web server, or multiples, to be added to the web cluster to increase capacity for an upcoming advertising campaign. An RPA tool could monitor your ticketing system, trigger automated provisioning of the web server, (for example VMWare) add the new server to the cluster, and close the ticket, all without anyone having to review the request or be involved in any other way. An RPA tool could also handle business-oriented tasks that an employee would typically handle such as data intake provided by a customer. Usually that information would be reviewed and processed by an employee, perhaps between two different systems, make the appropriate decision and complete the process. RPA tools can also be used to process interactive and background jobs minimizing some of the scheduling issues often found with job scheduling systems.
As RPA technologies mature further, they will continue to gain functionality and integration capabilities, the lines between RPA and other technologies will blur even further.