Robotic Process Automation: The Top 3 Reasons Your Company Is Struggling
Not long ago, UiPath announced a Series C funding placing them at a valuation of $3 billion. Back in July, Automation Anywhere raised their Series A funding placing them at a valuation of $1.8 billion. In just a couple years Robotic Process Automation (RPA) has gone from something most companies have never heard of, to nearly all fortune 500 sized companies investigating whether this technology can work within their organization. With all this growth, growing pains are much more prevalent than either consulting firms or vendors are willing to admit since their sales depend on an image that RPA is fast, easy, and cost-effective. The top three area’s companies are struggling will be analyzed.
The Top Three Areas of Failure
Before diving directly into the problem areas; imagine this scenario first. You’re a Vice President in the Finance department of a Fortune 500 company and you’ve recently learned that the company has invested in an RPA platform. You want to bring some cost savings and efficiency to your department, so you get a couple leaders together to figure out what use cases you can automate. Everything you have heard is RPA has a quick turn around time and you can automate repeatable tasks that some of your employees are doing. You end up with a list of things that your team wants to automate. Since the IT department hired an offshore firm, they want the “process requirements” in the form of a Word document that articulates step by step what they are automating so they can build it. You think that in just six to eight weeks you will have this robot working away 24 hours a day performing this process that your team once was. Four weeks in, the problems start to come up.
The developers are stating the requirements they were provided were incorrect due to many system errors they ran into. After the business spent a week trying to determine what went wrong, it turns out the process that John Doe was using, who provided the requirements, relies entirely on the way he formats his data in Excel before he inputs the data into another system. Digging deep into this, it’s discovered that people within the department format their data in all different ways. While all of this is going on, the developer is just sitting around waiting for someone to figure out what the “proper” requirements are.
The business ends up spending four weeks trying to “fix” the process so the correct requirements can be provided to the developers. Problems in development continue to come up and time is lost due to the time difference between the onshore business and the offshore development team. When all is said and done, the automation that should have taken six weeks has now taken four months. Using this case study as an example, lets deep dive into how this scenario seems to continually play out at companies.
Improper Process Assessment
There are two primary aspects to assessing a process for Robotic Process Automation:
1. The Business Case
2. Technical Feasibility
Business Case
More times than not, you’ll be looking at many processes before determining which use case to automate. In order to do this, you need to prioritize your automations. Cost (or time) savings should always be a primary driver of prioritization. Automation’s entire purpose is to provide value back to the company at the enterprise level. At the department level, it should be to make your area more efficient. Both efficiency and value can be directly tied to hard dollars. Looking at an example business case can help further explain how to look at each process.
When crunching the numbers, I personally look at processes for a full calendar year. How many people, how much time, how often and how much are they paid? Those are the key metrics that need to be understood. There are three objective measures to look at from those metrics:
- Yearly Process Cost
- FTE Equivalent
- NPV
The process cost is going to give you an idea of what this process costs the business every year. The FTE equivalent tells you how many people the bot is going to “replace” if the automation is in place. Most importantly, the NPV is going to tell you if the investment to develop this bot has a payback. If you are making decisions on processes to automate without understanding the business case behind it, it’s critical for you to rethink your entire strategy. But what about other types of savings?
I’ll admit, there are a ton of benefits of automation. Some examples of other types of savings can be seen below.
- Re-purposing employee time to focus on higher value tasks
- Avoiding cost by automating something versus building, buying, or employing someone
- Greater process accuracy and quality
While these are important benefits, if you find yourself in a position where you are looking at a use case that ONLY provides these tertiary benefits then there are likely better opportunities that you have not evaluated.
Technical Feasibility
Part of every process assessment needs to include a technical assessment of the process. Ideally, this is an architect with intimate knowledge of the RPA tool. There is a very good reason behind this technical assessment; you cannot 100% automate many processes. If your business case assumed 100% of the processes being automated but only 50% of them can be, the business case will easily fall apart. Most importantly the technical architect should be able to estimate development time. This is how you will be able to setup your NPV model to ensure your accounting for development time in your investment. What exactly is being looked at from a technical standpoint?
There are several important aspects to look at when evaluating processes for RPA. The Architect should be looking at how complex the decision making is when moving from each step in the process. How clean and consistent is the data required to execute on? Is it unstructured in nature like many different invoice templates in PDF form or is it highly structured data living in a SQL database that’s easily retrievable? The architect should be looking at how the different applications will be interfaced to make these important decisions. You don’t want to get four weeks into development only to realize you need to develop a custom component within the bot in order to get your data. Your six-week automation could now be twelve in one single failure in the evaluation phase.
Offshore Development
I believe offshoring to be one of the biggest issues preventing Robotic Process Automation in being successful. RPA development happens primarily offshore for most companies in my experience. Companies hire third-party consulting and staffing firms to provide the technical expertise to do RPA development. There is an incorrect mindset that you can throw some requirements into a Word document and send it to a developer in another country to execute. While this may work for some types of development, doing this with Robotic Process Automation is the worst thing you can possibly do (this is my opinion I am sure others have their own). Why is it the worst thing you can do?
The types of processes that are automated with Robotic Process Automation are inherently manually high-volume tasks. Most of the time, you’re lucky if there’ documentation of any kind. If there is documentation, it's not going to be to ‘click level’ required to develop a bot. Keep in mind, 20 people might have been doing this process differently at that click level. For a developer to make a solid automation, it requires good collaboration with a process SME (Subject Matter Expert) and an excellent understanding of what the business process is.
More times than not when using offshore resources, someone onshore decides what that click level documentation looks like and throws it over the ocean where the developer has no context on the business process and develops off a Word document. Remember, we are taking a process that was completely manual where 20 people might have done it differently and some Business Analyst spent way too long creating a document with requirements that are in no way 100% correct. This is the offshore breakdown. I’ve spoken to companies (too many unfortunately) that are spending upwards of six months to develop an automation that should have taken six to eight weeks. Offshoring is one of the primary causes of this long development time (the time zone difference is just icing on the cake). Having developers that cannot handle process ambiguity and require step by step guides will kill your automation value.
Process Evaluation
Evaluation of process is one of the biggest areas I see fail or lead to incorrect assumptions. Understanding how an automation (a bot) is performing is the single most important factor of the entire process. You cannot assume you’re getting value out of an automation just because it’s in production. You need an effective way of measuring what that bot is doing. Let’s clear up some confusion here.
What is the confusion exactly? Companies, managers, Robotic Process Automation platforms that only measure bot execution but believe that they are measuring value. What do I mean bot execution? When a bot is performing a process, it is executing it. Many platforms will provide metrics on how many hours a bot worked or how long it was utilized during execution among some other data points. I see companies then take this metric as what the cost savings are. Unfortunately, this is wrong.
Many companies and managers fail to establish a proper business case before developing the automation. When that step is missed, it's nearly impossible to understand the real value you're getting from the bot. The real payback you're getting from the bot is the time savings from the people, not from the time it takes the bot to do the work. Often there is a deviation from how long a bot takes to perform a task compared to a human. Sometimes it is faster and sometimes it takes longer for the bot to complete a process due to some things that need to happen during the process that aren’t being done by a human (this isn’t usually the case, but it happens). To measure cost savings and value, you need to measure what was taken from people. Let’s walk through an example.
Let’s use the previous business case as an example. If it takes 20 minutes for the average invoice to be processed when a person performs the process, then you’re measuring cost savings for a bot by counting the number of transactions the bot performed and then multiplying that number by 20 minutes and adding in the average hourly rate.
Ideally, you're either able to get a hold of your bot execution data in Excel format, or you can setup a Tableau/Power BI dashboard that has the capability of pulling in the execution data from the SQL database of the RPA platform and then comparing that to the business case. For myself personally, I believe automating everything that surrounds automation to be key. Having a dashboard that will automatically display the data you need is the place you want to go, not spending five hours every month figuring out how your bot performed.
Conclusion
There are a lot of lessons that can be learned in the exciting area of Robotic Process Automation. To truly understand how to build a scalable, efficient, and resilient Robotic Process Automation Program, it’s important to learn from key trends and to not repeat the same failures that others have experienced. Every organization has unique ways of operating and regardless of how your company operates, the three areas of failure that I have seen over the years is agnostic to industry and operating model. Success in Robotic Process Automation is critical to a company’s growth and it is my goal to help companies avoid some of the most common mistakes when building a Robotic Process Automation Program.
