RPA Failures: 10 Most Common Reasons and How to Avoid Them

Robotic Process Automation (RPA) is the use of software (“robots” or “bots” in this scenario) to collect and interpret data 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 you are already working on without additional time or resources.

Done right, RPA can be the fastest and most efficient way for you to acquire, improve, and deliver information, and it can help your business cut costs and save time for key employees. See the improvement ideas for the finance, banking, or real estate industry.

However, without the right structure, logic, and customization, RPA projects can go wrong, and many organizations 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.

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 an essential and common mistake that usually leads to the RPA project not achieving its goals.

People are trying to implement RPA before they 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, methods 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 initially intended,
2. or the resulting automation is running in a much more dynamic environment 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. 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.

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%.

This is the biggest mistake I see happening.

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.

Suppose the environment in which the automation operates is more dynamic than expected. In that case, the RPA toolkit must have additional complexity to ensure it can continue working in an ever-changing environment and deliver the right results.

Again, this is 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 you cannot automate any part of these processes – a workflow automation tool can help you deal with repetitive steps in a process that 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.

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 deployed alongside cognitive technology).

We’ve seen an RPA bot break down when encountering scenarios it has not been trained 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.

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. I didn’t expect such an obstacle. This is generally a more significant issue than some think when first deploying RPA.

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

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.

As with any technology initiative, you need metrics to measure results and ensure RPA meets its intended goals. Ensure 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 problem regarding your supplier relationships, especially if you don’t have 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, requiring much 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 significant 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.

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

Companies fail to achieve their RPA goals, 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.

Many managers fail to think holistically about an organization’s culture 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 change the way people do their work and the organization’s behavior as a whole. Consequently, communicating effectively about these changes, listening to employees’ opinions, and ensuring their commitment are essential to success.

Training employees in skills and their ability to navigate this new culture of interaction between bots and humans is also essential. Just as we train new drivers before they hit the road, your employees must understand how to work with RPA technology, build bots, and fulfill 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. Suppose you can manage the contributors’ expectations and ensure that the RPA goals align with the business goals and objectives. In that case, you are more likely to attract the right people for the project while minimizing the risk of failure!

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 needed to complete a task, in which case RPA projects fail.

RPA implementation will run smoothly and will likely yield good results if the operations have undergone 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.

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

Forrester analyst Craig Leclair 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 complexity limit.

This complexity limit can also result from 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.

Again, this requires organizations to evaluate the processes being automated carefully. If the data formats and process steps are not rigid and structured, plan to choose a more suitable tool for DPA, spend significant time pre-labeling and preparing data, or set up a process rule.

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 personal 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 the origin of a digital transformation journey. Still, unless you connect the islands, you’re not going anywhere.

Organizations should consider stepping back and wondering what they want to achieve regarding 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 this were the broader goal of digital transformation, then using RPA in isolation would not achieve it.

The word “scale” also has its 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 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 ideally automate specific steps, such as retrieving data from an initial loan application. However, loan processing and approval require numerous steps in which the application travels through many different departments and systems, extracting data from various sources.

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

To avoid RPA crashing, installing fences for bot deployment is essential so that advanced users are less likely to make mistakes. Bots make creating code more effortless for people outside the core development group. This can lead to the shadowy development of organizations and a lack of oversight.

As with any technology, bots must be properly managed, monitored, and logged. Building and deploying a bot is deceiving – it seems easy to create a deployment. Still, without the technology and support process, the bot will likely cause more headaches and generate more work than if the task is done 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 essential to ask questions about the volatility and repeatability of the job before assigning a bot to it.

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

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

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

Let’s look at an example of three more straightforward problems 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:

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 take six to eight weeks to be ready to go.

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 scaling, error handling, concurrency, or scheduling issues. Consequently, there can be numerous testing cycles and reworking before it is ready to go – adding two-three weeks.

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 to 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.

The good news is that most RPA failures result from human error, not the technology itself. The most important lesson here is that companies can learn from 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 roles.

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

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 leadership must review each implementation step so that local groups 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:

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

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 from bots rather than diagnostic information obtained from most bot installations.

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 (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 RPA solutions, so they ask us to design the technology for them, either with our turnkey solutions or expert knowledge if the client wishes to develop an RPA in-house.

See the process in the healthcare industry you didn’t know can be automated, the benefits, and how you can predict the failures.

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.