Robotic process automation (RPA) is simple, right? You identify a straightforward process, you automate it, and you rake in the cost savings. Well, not always. Although RPA can result in savings, there are several key pitfalls to be aware of before investing in software automation.
Companies are using RPA more than ever before due to the benefits of improving productivity and quality of data. According to a Harvard Business Review survey of 523 executives across 26 countries in a range of industries, 58% say they have started their automation journey with 38% piloting solutions, which is twice as many as the year before (HBR, “How Companies are using Intelligent Automation to be more Innovative”, 2019).
Hopes and Dreams
Several years ago, I embarked on a robotic process automation journey with the tenacity and enthusiasm of a kid in a candy store. There were so many replicable processes that could be automated, it seemed that the cost savings would be easy to attain. A backlog of processes was generated, the initiative was kicked off with the organization, and the processes were prioritized based on which process would get us the biggest bang for our buck. At the same time, we played with the ‘build vs. buy’ notion and assessed various companies, which claimed expertise in RPA implementation.
Pitfall #1: Vendors Who Claim Seamless and Simple Robotic Process Automation Implementation
The vendors my team assessed had various price structures and they all claimed a return on investment within a year or less. The vendors also had meaty price tags. Something didn’t seem right. So we dug a bit into how these vendors implemented the bots and which were the most used RPA software. Some vendors also claimed expertise in our line of business, but we knew we were too much of a niche market for that to be true. To avoid vendors who were clearly ‘stretching the truth’ and avoid the very high front-end investment required, the company decided to test the waters with internal development.
What we found was that the most complicated part of an RPA implementation was within our own control – standardizing the processes we want to automate. Once we realized this, we leveraged our existing development team to learn the automation software. At the same time, we took a hard look at our backlog to thoroughly vet which processes were truly straightforward and which ones required more polishing.
After clearing this initial hurdle, we got to work on our first use case. We knew it was a big fish to fry, but it would potentially result in a half-million dollars in cost savings by the end of the first year. The process was documented and recorded and the bots were developed and deployed. But a few weeks later, something happened that we weren’t expecting.
Pitfall #2: Relying on Applications outside of your Control
Pitfall #3: Going After the Big Fish Without Practicing on Little Fish
The problem was that we were relying on a 3rd party website to process our transactions (which was part of the manual process). Once the site realized we began using a bot, they informed us that they discouraged the use of bots on their website. Instead, they suggested we use their application programming interfaces (APIs) instead to accomplish the same task. Unfortunately, several months and thousands of dollars were wasted on a set of bots we could never use again. Now we were several months behind in realizing our cost savings because we had put forth efforts on obtaining the big fish. There was clearly a lot we did not know about RPA. We did not address the unknown unknowns and we did not start with smaller processes to test the waters first. We took these lessons to heart. Going forward we pivoted from automating processes that used external applications and focused on prioritizing processes within our own internal systems.
The People Factor
There are non-technical factors to consider when implementing RPA too. One should plan how to get the buy-in from leadership, as well as how to handle the organizational change management aspects. Especially, when people may fear automation could take away their jobs.
Pitfall #4: Communicating robots as a Cure-All Without Articulating What Makes a Successful RPA Candidate
I did not have a problem communicating the RPA idea to the internal leadership team. Everyone was quickly on board. The question was more around, ‘Where do we start?’. I pitched an approach explaining what RPA can do, example timeframes, and likely ROI. More importantly, I shared what makes a good candidate for RPA: a process must be standardized and not include any subjective decision-making. Being transparent with what RPA cannot do is just as important as sharing what RPA can do.
Pitfall #5: Not Addressing People’s Underlying Fear of Job Security
As we vetted the candidate processes for RPA, we needed to engage the people who performed the daily work that was to be automated and their management. At first, we had a misstep: we were not clear with associates that they were not to be replaced by robots. Without this warning, rumors started, and people began to fear the “Coming of the Bots”. When we clarified that we did not plan to replace anyone, but that we planned to remove the mundane repetitive tasks from their daily workload, we saw more engagement (and relieved workers).
Navigating Forward
Costs were incurred through the learning process to be sure. We learned as we went. We spent the necessary time and resources to thoroughly vet our processes. We made the decision to build internally. All these steps helped us save over $1M in the first year. Most of those savings came from not outsourcing the RPA development work, and development is the easy part.
My advice is to spend the time doing your homework on which processes will be the best candidates and start off with small fish robotic process automation candidate processes. Use a quick sprint method to prevent costly throwaway work if a bot does not prove to be successful. Be clear and transparent with both leadership and the individuals impacted by RPA. On top of this, be sure to explain how RPA is not something to be feared, but something to embrace. After all, improved productivity means more time to focus on higher-level activities.
About the author: Alyssa Moy is a Senior Director, Product Strategy & Management at Option Care Health and a member of TSI’s Leaders’ Forum.