RPA - Lessons from the School of Hard Knocks

Over the last 3-5 years, we have seen quite a wave around RPA….including huge valuations for RPA Upstarts (note I do not call the Startups!). Recently I have had the opportunity to oversee an RPA project at one of my clients….and as it usually happens….reality is a bit different from the hype.

In some sense, when I dove into RPA, it was like a blast from my past……when as a Project Engineer I automated mundane spreadsheet tasks by recording my keystrokes in LotusNotes first (yes, I am that outdated!)….and then graduated to Excel key strokes recording….to writing VBA code to make it a bit more intelligent. Oh…and how can I forget the MS-DOS scripts I wrote to automate batch jobs of air pollution modeling runs….those were the days!

Clearly RPA is significantly better than that…..but is the hype justified? Answer is Yes and No….it depends….the classic consulting answer…..

So what are my lessons learned.

Business & Process Related Lessons

1. Do not automate a broken process – fix it first before automating. You will only make the problems worse by automating such a process.
2. Standardize, modularize, and simplify before automating – if your process has lots of exceptions, it is probably NOT a good fit for RPA.

Governance Related Lessons

1. If you are running an RPA CoE, freeze business case after build decision is made – if you discover along the way that the business case is no longer there, kill that BOT. Move onto the next best process to automate. And for this to work when you have staffed up your CoE (internally or externally), there needs to be a ready pipeline of approved RPA use cases to pick the next best from that pipeline so that effort is not wasted on building a BOT that no longer makes sense and you keep the staff you have built up effectively utilized.
2. Establish clear criteria that are simple and easy to explain and quantify, e.g. BOT should free >2500 FTE hours and Payback should be <= 1 year
3. Consider a formal contract between business/function and RPA CoE. Business/function owns business case and the RPA CoE owns design, build, run & maintain of the BOTs – each one does what they do best!
4. Run short agile sprints to design, build, test, and deploy the BOTs. If new requirements surface, don’t let it break your sprint…complete the current sprint if far along into the sprint and handle the new requirements in the next sprint….and integrate at the end of each sprint….even if it is a partial integration. Note Agile does not mean never ending build because requirements or features are added…in fact it is quite the opposite….it means build in small chunks, test, deploy….learn about defects in Prod…and improve & iterate in the next sprint

IT Related Lessons

1. If an application/system is frequently changing (upgrades, patches, GUI changes), consider using APIs, if available, instead of RPA for that step in the process. RPA works best highly repeatable processes that involve very stable legacy applications that have no APIs to interface with
2. Plan for DEV, TEST, and PROD environment differences because there always are – automate you RPA CI/CD pipeline to frequently put RPA BOT code through the cycle to quickly learn and iterate
3. Plan and solve for VDI related screen resolution issues that will throw your BOT off
4. Have an application expert on the team to exploit it’s full capability in an automation process – note SaaS products like SFDC and SNOW come with Low Code/No Code options that have a library of backend connectors that can be leveraged for integration and automation….exhaust those possibilities first as they will be more robust and scalable and use RPA as the option of “last resort”.
5. Plan for logging, tracing, and error handling logic upfront in the design
6. Ensure availability of enough test data and/or refresh existing test data for re-use
7. Plan for incurring some expenses (and headaches) to run and maintain your BOT - because these are somewhat brittle, they will need tender love & caring.....and you will see a bit of DevOps in action....those who build it may be the best to run, maintain, and operate it!!

In summary, RPA holds promise for a certain set of use cases. Cognitive or AI based RPA is the new rage….but as so often happens….hype is a bit ahead of reality. Long live RPA….yes, it will need to live quite long to achieve complete automation of mundane user tasks!

Disclaimer: Views expressed here are my own and not those of my past employers or my current employer