Digital transformation has been the buzz word over the last couple of years within the field of Robotic Process Automation (RPA) and is considered one of the key enablers. Early adopters and investors of RPA technology are showing impressive results. But this is not the case for everyone. Some are struggling to realize the promised outcomes. The reasons for this are many, but from our experience, there are a number of common denominators as to why RPA initiatives are unsuccessful. In this blog, we focus on four of the most common reasons:
- Process selection
- Process redesign
- Required capabilities within your organization
- The capabilities of the service provider
1. Process selection
Selecting the right process may seem like an easy task, but in our experience this is a crucial first step, with which many organizations end up struggling. There are still a number of misconceptions about what a robot is, how it operates and what its limitations are.
“A process equals a robot”
Unfortunately this is not always the case. Not every process is suited for automation with RPA technology. Good candidates include processes that are rule-based, have limited exception handling and are based on structured inputs. If a process has semi-structured or unstructured data then other solutions, such as artificial Intelligence, should be considered. Return on investment depreciates due to longer development times and higher license costs, and the risk vs. reward must play a greater part in the business case determination.
“High volume processes make good RPA candidates”
Although the potential benefits of process automation are usually high in relation to the volume of a process and the full time equivalents (FTEs) working on it, there is often more complexity embedded than a cursory scan may yield. Identifying the right candidates for RPA begins with the right methodology, starting with opportunity identification and feasibility assessment. Equally important is coaching organizations’ business units to understand the real benefits of introducing RPA and what is and is not feasible. Failure to get this message across, may soon turn into a swamp of exceptions and process redesigns, leading to long development times, frustration and lack of results.
2. Process redesign
As already mentioned, not every process is suitable for RPA. Automating an inefficient process could result in building an inefficient robot. There are important questions that should be answered before automating a process. Is it necessary to automate every step of the current process? Are handoffs still required? Creating a robot that executes its tasks efficiently and effectively without unneeded complexity will decrease runtime, eradicate errors and provide a more stable process. By questioning why certain steps are done and if they are still valid, we sometimes realize that there is no reasoning behind certain processes. It seems a no brainer, but in daily practice this is a harsh reality many organizations face. Process redesign should be considered as an important step after the opportunity identification and feasibility selection has been completed.
The risks of failing to address un-optimized processes can lead to an unwelcome business case. Where originally the forecast predicted a 70-80% reduction in the number of FTEs, the actual number is closer to 25-30%. A failing RPA business case presents an organization with a dilemma. Should the organization continue nonetheless with robot implementation, or should the organization stop and try to understand the root cause of the failing business case.
A recommended approach to gain the most out of your RPA initiatives and to set the clocks is to begin reviewing your processes both with process experts and process operators. Challenging questions like “Are we aligned on the process?”, ”What are the steps that are executed and what exceptions do we encounter?”, “How do we handle them?” and “What is the percentage of first pass right pass without triggering exception management?” will start driving good RPA onboarding practices.
3. Required capabilities within your organization
As RPA (and also AI) is moving from hype to realization and organizations continue to learn about this technology, service providers are usually necessary to support the organizations in building their automation capability. As mentioned above, this starts with a clear understanding of what RPA is and what it can and cannot do, including educating the organization as to where ownership of RPA should be introduced. RPA is different in the sense that initiatives, ownership and responsibilities should be defined within the business. The CFO should own the RPA agenda and be the driving force behind this. Therefore, it becomes even more crucial that the possibilities and limitations of RPA are clear. This is not only important during the pilot phase, where the first benefits of RPA should be realized, but also when embedding RPA within your organization, where process operators and process experts become the driving force of identifying processes that could be suitable for implementing robotics.
4. The capabilities of the service provider
Your RPA provider should be able to support your RPA journey from beginning to end, with process and functional knowledge as well as understanding the tooling and building of robots. It is important to know your provider’s framework and let them explain how they will use it in your specific case. Failing to have a strong framework for RPA can result in disappointment and the failure to achieve full automation potential within your organization.
Have you started with RPA and are failing to meet the results that were promised? Are you not able to meet the projected timelines and are losing trust of the business because you are not able to deliver? Ask us about our RPA Quality Audit to assess your RPA initiatives with our proven framework and expertise in this area.
Find out more about this topic:
- Part 1: Center of Excellence & Operating Models: Why RPA is more than just a software
- Part 3: The robot user-ID: handling RPA within existing rights & permissions structures
About the author: In his position as Managing Consultant, Jos Bel has an extensive base in finance and strategy. His focus of advisory lies in Robotic Process Automation and Artificial Intelligence. He is part of the Corporate Strategy Team in Germany and the Netherlands. If you have any further questions, please don’t hesitate to contact the author Jos Bel.