Robotic Process Automation (RPA) is the use of software (“robots” or “bots” in this scenario) to collect and interpret data in order to automate processes, manipulate data, and exchange it between multiple systems.

It is used to automate slow, manual tasks that take up your employees’ time and can help you scale the business processes that you are already working on without the additional investment of time or resources.

Done right, RPA can be the fastest and most efficient way for you to acquire, improve, and deliver information, and can help your business cut costs and save time for key employees.

However, without the right structure, logic, and customisation, RPA projects can go wrong, and many organisations fail to implement RPA at scale.

Turning to the RPA failure rate, as per EY, while RPA can change the economics and service levels of ongoing manual operations, the experts have seen 30 to 50% of initial RPA projects fail.

Why Do RPA Projects Fail?

RPA can be great for tedious and repetitive processes, but it won’t fix a process that you don’t fully understand or that is oppositely fundamentally broken. This is a basic and common mistake that usually leads to the fact that the RPA project does not achieve its goals.

People are trying to implement RPA before they really know how their processes work. It tends to fail as they constantly discover new exceptions and variations.

Indeed, “exceptions and variations” are not harbingers of RPA success. When evaluating candidate RPA processes, most experts recommend looking for predictable, rule-based processes that repeat regularly. On the other hand, processes that change or don’t follow a predictable path tend to be poorly suited for RPA.

RPA tends to fail in two scenarios:

  1. either the process being automated is not as robotic as it was originally intended,
  2. or the resulting automation is running in an environment that is much more dynamic than previously thought.

In any case, the tool requires much more maintenance and continuous development.

More work on maintenance and continuous development is not the metric you bragged about. In fact, this contradicts in some way why you are considering RPA in the first place: RPA aims to improve the efficiency of processes and reduce the likelihood of human error.

Let’s take a closer look at the 10 main reasons why RPA projects fail.

10 Most Common Reasons for RPA Failures

Despite the obvious benefits, companies often face the issue of why RPA projects fail. It is common for companies to be unaware of the challenges associated with automating robotic processes. According to Forbes, 54% of technology disruptions are due to poor management, while technical issues account for only 3% of disruptions.

#1 The process is more dynamic than you think

This is probably the biggest mistake: it essentially means that you have automated the wrong process.

If the process requires decisions on a case-by-case basis, you still want people to be actively involved.

If the environment in which the automation operates is more dynamic than expected, then the RPA toolkit must have additional complexity to ensure it can continue to operate in an ever-changing environment and still deliver the right results.

Again, this kind of hitting the target. If the process requires decisions on a case-by-case basis, you still want people to be actively involved.

Tasks that involve creative thinking, brainstorming, or interacting with the physical world (such as pulling papers from a filing cabinet) are better performed by humans. This does not mean that you cannot automate any part of these processes – a workflow automation tool can help you deal with repetitive steps in a process that also requires decision-making and human skills. Workflow automation tools and RPA can work together.

The idea is to leave human work to be done by humans. Nobody likes to work on low-value, thoughtless or repetitive work.

#2 The target interface changes, but your RPA bot does not receive a reminder

RPA follows instructions well. It cannot learn on its own or react to unexpected events.

Some people don’t make that distinction as they combine RPA with AI. (RPA is generally dumb as it stands, although we will likely see an increase in use cases when it is deployed alongside cognitive technology.)

We’ve seen an RPA bot break down when it encounters scenarios for which it has not been trained to or instructed to operate. One of the most common examples is changes to the target user interface. To put this in perspective, if the RPA bot has been configured to go to a web page and click in the upper left corner to go to the registration page, it can do so until the bot can find that specific button in the upper left corner of the page.

The problem arises if you move this registration button to the middle of the page – or anywhere other than the top left corner, for that matter. The RPA sequence will stop because the bot will keep looking for it in the upper left corner. From a technical point of view, we are wrong to call it an RPA failure; this is indeed a human error.

The bot works exactly as it was told. It just didn’t expect such an obstacle.

This is generally a bigger issue than some people think when they first deploy RPA.

A common problem with RPA is process rigidity, dependency, and sensitivity of applications or systems that are being automated. The reason for this is that RPA typically uses screen-cleaning technologies with obvious problems that arise when changing user interface screens.

#3 You underestimate the political implications

Here we want to point out another consideration that has nothing to do with the process itself: the political landscape of your organization. As with many technology investments, your chances of success will be higher if senior executives can help you overcome obstacles when they arise.

This can be especially important in organizations where “automation” is a dirty word, often because it makes people paranoid about the safety of their jobs.

Areas of the business that do not attract the attention of key executives can also be poorly suited for RPA, as RPA requires political capital in the form of management support to establish corporate governance and provide annual financial costs to sustain operations.

For those who buy automation and RPA, it doesn’t seem like there is any reason not to, but for some people in the organization, the sale may not be that easy. Without the support of the right people, RPA projects can stop quickly. While participating in these projects, it is recommended that you think well about potential blockers and work with them to overcome any fears or reasons not to use RPA.

#4 You have unrealistic expectations

As with any technology initiative, you need metrics to measure results and ensure RPA meets its intended goals. Just make sure these goals are achievable, and you are not trying to hammer in a nail with a screwdriver.

RPA solutions are not SaaS or cloud services that work immediately. This can be a particular problem in terms of your supplier relationships, especially if you don’t have your own RPA experience.

As a rule, customers expect RPA solutions to work out of the box with limited customization options. RPA solutions are highly recommendatory deployments and require many professional services to deploy, implement, and support in the future. It is very time-consuming and resource-intensive, which requires a lot of manual work.

“A lot of manual work” is what RPA is designed to mitigate, so make sure you do your due diligence.

It is not uncommon for organizations to set goals and expectations when they first launch an RPA project, but these expectations need to be controlled. RPA can be very powerful and bring great benefits, but when working alone, it can only be used for automation, and expectations must be aligned with what is possible, not what you would like to do.

#5 Lack of a coherent platform

Research shows that over 50% of RPA projects cannot grow beyond 10 bots, and over 70% of RPA projects reach a plateau with fewer than 50 bots.

Companies are failing to achieve their RPA goals, and this is largely due to the lack of a coherent platform and the ability to scale modules and intelligence. RPA technologies are more likely to be successful when combined with other intelligent automation solutions such as cognitive capture and process orchestration.

#6 Lack of consistency with stakeholders

Many managers fail to think holistically about the culture of an organization that will need to adapt and support change in its work environment before embarking on its RPA journey.

Mastering new technologies, especially RPA, is not an easy task because they not only change the way people do their work but also change the behavior of the organization as a whole. Consequently, communicating effectively about these changes, listening to employees’ opinions, and ensuring their commitment are essential to success.

It is also important to train employees in skills and their ability to navigate this new culture of interaction between bots and humans. Just as we train new drivers before they hit the road, it’s important that your employees understand how to work with RPA technology, how to build bots, and how to fulfil their new, bot-powered roles.

As in point 3, a lack of alignment with key business stakeholders quickly closes the RPA project. This is due not only to underestimation of the political consequences but also to unrealistic expectations. If you can manage the expectations of the contributors and make sure that the RPA goals align with the business goals and objectives, you are more likely to attract the right people for the project while minimising the risk of failure!

#7 Choosing the wrong process for automation

RPA works best in locations where transactions are repetitive. For example, RPA is changing the retail and CPG industry and does not require human judgment. RPA is not for those methods where human intervention is required to complete a task, in which case RPA projects fail.

RPA implementation will run smoothly and is likely to yield good results if the operations have gone through a selection process through the IT, business, and RPA teams.

Sometimes, the reason for RPA project failure is that your RPA-developer is non-technical. Saying that anyone can develop an RPA code is a big misconception by the public fuelled by the top RPA software companies claiming that the platform is low-code and anyone can become a citizen developer. So, choose an RPA expert carefully.

Read more on how to select the right process for RPA automation in our dedicated article on this topic.

#8 Too much complexity

RPA is powerful – to a certain extent. At this stage in their development, many of the tools available do not handle complexity well. This complexity often manifests itself in too many steps or decision points in the broader process.

Craig Leclair, a Forrester analyst, cites the “Rule of Five,” noting that if you go beyond the five decision points or applications, you probably need another technology, such as digital process automation (DPA).

Thus, organizations must evaluate current and planned RPA deployments – if they have reached or passed the five steps of the process, they have reached the limit of complexity.

This limit of complexity can also be the result of a lack of structure. The “robotic” nature of RPA means that it focuses on well-defined data formats, steps, and results. Throw in unstructured data or process variations, and RPA will crash at best and break at worst.

This again requires organizations to evaluate the processes that are being automated carefully – if the data formats and process steps are not rigid and structured, then plan to either choose a more suitable tool for DPA or spend significant time pre-labeling and preparing data or setting up a process rule.

#9 Impossibility of scaling

Another inherent limitation of RPA is that it automates certain tasks – in other words, it mimics human behavior at the individual work level. This has a significant impact at this micro-level but leads to individual improvements for the macro-organization.

Research firm IDC calls this scenario “islands of innovation” —it’s not bad in itself and might make sense as an origin on a digital transformation journey, but unless you connect the islands, you’re not going anywhere.

Organizations should consider stepping back and wondering what they wanted to achieve in terms of process automation (and whether those goals were met). If it was the automation of a particular task, then, by all means, go to RPA. If, however, this was the broader goal of digital transformation, then using RPA in isolation will not achieve it.

The word “scale” also has its own difficulties with RPA. Vendors use this term to refer to the reliability of their platform – in other words, how many bots it can support. However, from a consumer perspective, this is only half of the equation. The larger business puzzle is whether RPA scales in terms of impact on organizational processes. The short answer is “no.”

An example of both of these spanners in the works (too much complexity (point 8) and scale beyond the level of individual work) can be found in most larger organizational processes.

Take, for example, lending in the financial services industry. RPA can perfectly automate certain steps, such as retrieving data from an initial loan application. But loan processing and approval require numerous steps, in which the application travels through many different departments and systems, extracting data from many different sources along the way.

Expecting RPA alone to transform the entire lending process digitally is a recipe for failure.

#10 Shadow deployment

To avoid RPA crashing, it is important to install fences for bot deployment so that advanced users are less likely to make mistakes. Bots make it easier for people outside the core development group to create code. This can lead to the shadow development of organizations and a lack of oversight.

As with any technology, bots need to be properly managed, monitored, and logged. The ease of building and deploying a bot is deceiving – it seems like it’s easy to create a deployment, but without the technology and support process, the bot is likely to cause more headaches and create more work than just doing the task manually.

IT departments also need to work directly with business users and communicate that RPA is just one tool in their IT toolbox. When determining if a task is suitable for RPA, it is important to ask questions about the volatility and repeatability of the task before assigning a bot to it.

Organizations should seek assistance from successful RPA implementation strategies and consulting services.

The “Multiplier Effect”

More than one of the problems described above is often present or related, creating significant multiplier effects. As our Top 10 RPA failure examples list shows, fixing these problems requires a lot of foresight or outside help.

Unfortunately, if more than one of these problems occurs, which is common, there is a significant multiplication effect that can lead to a loss of faith in RPA or to a project halt.

Let’s look at an example where three simpler problems are encountered in an RPA program. In the scenario below, we want to provide a simple PoC for data cleansing and then quickly deploy it to production to gain tactical benefits:

Case #1

Issue: Using the wrong delivery methodology.

Normal delivery time if problems can be avoided: 2-4 weeks.

With skilled resources and an agile RPA-centric approach, simple sub-processes are usually automated and ready to run in two to four weeks.

Normal delivery time if the problem affects: 10-15 weeks.

If a software delivery method is used, redundant documentation and management gateways can quickly result in the process taking six to eight weeks to be ready to go.

Case #2

Issue: Assuming the skills required to build a PC are sufficient to automate production.

Normal delivery time if problems can be avoided: 2-4 weeks.

Knowing that PoC needs to be launched means that proper design, rigorous development, and unit testing are being used. Hence, the PoC delivery portion can take anywhere from one-two week to two-three weeks to prove it is fully scalable, resilient, and auditable.

Normal delivery time if the problem affects: 10-15 weeks.

If PoC is delivered by insufficiently skilled personnel, then training the robot to process can miss important issues of scaling, error handling, concurrency, or scheduling. Consequently, there can then be numerous cycles of testing and reworking before it is ready to go – adding two-three weeks.

Case #3

Issue: Too much process automation or failure to optimize for RPA.

Normal delivery time if problems can be avoided: 2-4 weeks.

Assuming the focus is on the optimal 70% of the process, it can be automated in two-four weeks.

Normal delivery time if the problem affects: 10-15 weeks.

Continuing to automate the remaining 30% is often associated with convoluted exception handling or multiple happy voyages splits, so delivery times can be doubled by adding two to four weeks.

How to deliver a successful RPA project?

The good news is that most RPA failures are the result of human error, not the technology itself. The most important lesson here is that companies can learn from their past mistakes and generally take a different approach.

Companies must develop a roadmap for the entire RPA implementation process. This ensures that all participants fully understand their role.

Companies should check whether all internal and external stakeholders are consulted to rule out assumptions about outcomes.

This is especially important in projects where there is no external implementation partner. Organizational consistency is critical as the organization alone is responsible.

All teams and management must be fully involved. Top-level management must review each step of the implementation so that local teams devote significant time to automating processes. Everyone should be convinced in advance to use it.

Based on our experience, we recommend that you seek advice from the following departments:

IT teams

The IT teams should be consulted prior to building a roadmap for an RPA solution. The IT department will act as a focal point between teams, both internal and external, as needed. IT will also know if there will be future integration problems with existing systems. If the company already has an RPA implementation, IT should combine both concepts, learning from the previous RPA implementation.

Data and analytics

Data and analytics are included in most management programs, and bots can generate significant amounts of data. If analytics is involved from the beginning, then important decisions are made based on valuable data generated by bots rather than diagnostic information obtained from most bot installations.

HR

HR is critical to alignment. Otherwise, RPA training programs may never be included in the corporate training schedule. RPA training is crucial to cut reliance on RPA consultants and empower employees.

External RPA specialists

External RPA specialists (UiPath consultants particularly, RPA developers) like us are already running many processes for large companies. It makes sense for the business to consult with companies like ours since we have accumulated significant experience in the RPA field.

Most companies don’t have their own RPA solutions, so they ask us to design the technology for them. Either with our turnkey solutions or with the provision of expert knowledge if the client wishes to develop an RPA in-house.

Conclusion

For the reasons listed above, it is clear that RPA should be used for processes that can be automated with a simple and intuitive user interface.

Not all RPA project bugs are the same, and most, if not all, are avoidable. RPA was a new technology five years ago. Today, it is rapidly gaining traction, and the experience of developers and owners has expanded.

Yes, there are a number of reasons why RPA projects fail, but they are all understandable and manageable. Moreover, the relevance of the introduction of this technology is increasing, not decreasing.

Although the list of organizations that have achieved success in large-scale RPA projects is small, it is constantly growing. Businesses that succeed early with this wave of automation will create a structural advantage that their competitors will be hard-pressed to resist.

The 5% of companies that do well with RPA today are demonstrating that the technology really works, and these businesses are creating yet another technological arms race that all organizations must join in order to survive, let alone prosper. Yes, achieving full RPA ROI in one quarter may protect your bonus this year, but successful large-scale bot deployments over the next year or two will protect your job and possibly your career.

This may sound like the same hyperbolic rhetoric that the RPA industry has been at fault for all this time. But no. Rather, it is the inevitable result of a technology demonstrating that it can work when applied correctly and does indeed produce game-changing results. After all, as with PCs, the Internet, and social media, not using RPA is not an option. You just have to do it right.

Moreover, an attempt to automate more and more complex processes within the framework of one task or solution can lead to various errors. Therefore, choosing the right approach is a must.

Flobotics understands RPA processes and provides a hassle-free model for outsourcing RPA implementation. Considering bringing RPA to your organisation? Get in touch with me.

Like the article? Spread the word

Karl Mielnicki

Karl Mielnicki

Expert and fanatic in RPA - Robotic Process Automation with over 5 years of IT experience working for consulting companies and tech startups. UiPath consultant, an accredited BluePrism developer.

View all author post

Let's implement successful RPA project for your business!

Bring the maximum value to your company with the automation!

Get in touch