Hands On with Robotic Process Automation (RPA) - What I did on my winter vacation

Every year, during the Christmas break, I take advantage of the quiet time in the office, by immersing myself in a learning project of some new technology. This year, it was Robotic Process Automation (RPAs), and I thought I wanted to share with you some of my experiences.

A software 'robot' (or RPA) is a software application that replicates the actions of a human being interacting with the user interface of a computer system. For example, the execution of data entry into an ERP system - or indeed a full end-to-end business process - would be a typical activity for a software robot. The software robot operates on the user interface (UI) in the same way that a human would; this is a significant departure from traditional forms of IT integration which have historically been based on Application Programming Interfaces (or APIs)  - courtesy: Wikipedia

With cooperation from our Financial Shared Services center in Poland, I decided try my hand at building a robot from scratch that could automatically parse through the nearly nested 70 if/then statements (mirrors the complexity of different tax jurisdictions around the world) of the right way to enter a non-purchase order payable request into our Oracle E-Business Suite ERP system.  

Here is what I learned:

Good RPA tools are free! - I fully expected to be using a watered-down freemium trial version or having to shell out $$$ to buy a license, but to my amazement, many of these tools are free! UIPAth has a fully functioning free community edition, and Workfusion's RPA Express (which is what I used for this project) needs to go to great lengths on its website to convince people there is no cost to using their tool, even deployed at enterprise scale. I simply downloaded it, installed it and started building.  

RPA doesn't need IT people - This is both awesome and terrifying. It's awesome, because with no training or reading documentation I was able in only 10 minutes to build and use a functioning bot. By the end of the day, I had completed the 178 step workflow that enters non-POs into our ERP system - WITHOUT A LINE OF CODE! It's terrifying, of how easy it is to imagine 100's of freeware bots with secure password in plain-text running on people's laptops all over the place. Then it dawned on me. We, in IT, have it all wrong. Our business partners don't need IT to create RPA bots, they need us to design and deploy a scalable and safe ecosystem with which to deploy bots. The bots should be part of an organized, cohesive army, not a chaotic, insurgent militia.

RPA tools are shockingly good!  - I had to admit, I had low expectations starting out. After all, how good can a codeless, drag and drop workflow tool that is free, possibly be? And Oracle, ugh. Its a pure Java app that only really works on Internet Explorer 11 with Java 8.1 Well, I was shocked to see in testing that it was 100/100 in successful runs. Every mouse, click and keystroke recorded without error, regardless of latency or performance of the application. 

RPA tools are weak at rules and data processing - These tools need to have input data formatted in a particular way. In my use case, there were dozens of if/then statements. RPA tools are designed to push through data entry tasks, not evaluate the quality of the data being ingested. There really is no substitute here for good old-fashioned scripting, ETL routines and stored procedures for your run of the mill complex data or nested condition statements. I guess IT people are still important in helping with RPA after all! 

Using RPA tools are an awesome way to document a process - There is no way around it. You cannot deploy a bot without an excruciatingly detailed understanding of a business process. Each keystroke and mouse click are scripted. The documentation that was created to make the bot come to life was really some of the best requirements/training documentation I've seen. Its in plain English, has lots of screen shots and goes into minute detail about how corner cases need to be handled. I found myself finding actual waste in our process, e.g. why are we asking people to fill out a supplier description when the ERP system can populate it automatically with a supplier number? Going through the process of trying to deploy a bot would make for a really great Lean for Six Sigma tool!

RPA tools seem almost too easy for their own good - After 6-7 hours of building this bot, something kept gnawing at me? Why are we even building a bot in the first place? And why is it being fed by a spreadsheet - I mean really, for as much money as we spend on IT, why are we still resorting to this? Shouldn't we just built an API directly into the ERP system to process this transaction? It would take a hundredth of the time to enter a transaction, and wouldn't require specialized software on servers. I kept thinking, this seems like a really inefficient way to do something more efficiently. But alas, unless and until we in IT become as easy to work with as a bot is to construct, people will always take the path of least resistance. A good standard for us to live up to might be: is it easier to deal with IT or to build a bot?

I'll close by saying how much I enjoyed this project, and I walked away with a new found appreciation for RPA bots particularly for citizen developers. I also walked away with a sense of how important it is, to have a clear strategy on when, how and how not to deploy them to ensure they don't create more problems than they solve. While at first blush, RPAs might be a hammer that makes everything look like a nail, it is nonetheless a valuable tool that puts control back in the hands of users and it's clear its something we and all IT departments should be exploring and using to our advantage.

Greg