Six Reasons Robotic Process Automation Is Not Worth It (As Branded and Sold)

As the adoption of automation picks up speed, vendors are in a frenzy to sell licenses for use-cases that RPA was never meant for. This article approaches the topic from a devil's advocate perspective.

If your company is considering an RPA investment then it's important to evaluate the opportunity in a balanced manner to avoid the risk of losing money or negatively impacting the business. If your company has already implemented an automation program but is facing challenges, then you may want to consider how to approach those gaps before they get out of hand.

RPA never makes mistakes — except when it fails

RPA is marketed as never making mistakes. While this is true in as far as it makes a minuscule amount of mistakes, it’s not true in the sense that ‘it never fails.’

Computer vision that RPA relies on is highly reliable but it has its faults. As underlying applications change, its possible for an automation to eventually run into the scenario where it executes an item in a way that no exception is triggered yet the desired effect doesn't take place.

For example, if an automation has to delete a record and then it shuts down the application after making the request, it may continue operating the same way when a popup in the application starts to appear which requires confirmation. Because the automation was developed to shut down the application after clicking delete, it's still able to complete its task, yet the record in question evaded the intended effect and no logging captured it. This isn't a fault of RPA vendors, and it may also not be a fault of RPA developers. But regardless of whether the issue emerged in business analysis, in monitoring, or another aspect of the automation operation or implementation, the fact remains that the consequences of such an error are serious for a business.

We can sit here and argue all day that 'computer vision' is highly accurate and that RPA never makes mistakes — but at the end of the day automation will break and someone will blame the technology and not the ecosystem that it lives within.

Considering RPA as a tool that never makes mistakes oversells the benefit of automation and downplays the amount of controls necessary to run resilient and reliable automation.

Horrible branding and horrible proposition

The proposition of RPA is that companies can assign less technically skilled employees to build automation with little to no code - this myth is explored further in 'Half a Dozen RPA Myths.'

Regarding the proposition of RPA, the little detail missed is that people are accustomed to robots being bad — think Terminator, layoffs, call-tree systems, and chatbots. Even employees that are interested in automating mundane processes will encounter challenges in a culture where doing so threatens the status quo.

On the other hand, process automation has existed for decades. Vendors such as Camunda and Flowable offer mature execution engines for business workflows. These tools support business process modeling and make it a breeze to integrate disparate systems through automation solutions.

From an automation standpoint, RPA is merely a ‘cog’ in the machine of business process management and automation. From a workflow perspective, RPA vendors oversell their orchestration capability as being a great use-case for a variety of needs which are often better handled by native platforms (such as the solutions available within Salesforce or Servicenow) or IPAAS platforms designed specifically for integration (such as Mulesoft).

The branding of certain vendors (which I won’t call out here) using flying robots is another insult to injury. It's a pure oversimplification of the complexity of robots and how people have to interact with them (through IT teams or consultants). Cute bots flying around may seem like a great marketing idea for an advertisement or two, but the fact that it's become the capstone of branding in this space is trite.

Is anyone really buying all these 'propeller heads' as the future?

Nothing is as easy as buying some technology, waving a wand, and automatically automating processes and saving money. Some professionals might read much into this section of the article, saying ‘but my proof of concept was easy and delivered results.’ To that I’ll say keep reading — succeeding at a proof of concept is easy — scaling value delivery from RPA is the challenging part.

Not enough consideration for scalability

The way some IT vendors are pitching use-cases for automation doesn’t factor in all underlying applications that'll get updated on a regular schedule (and will break the robots until maintenance is applied). When a company has a few dozen bots, this is manageable. When it gets to the point where hundreds of bots are in production, then this becomes a nightmare to work around.

Sure, the enterprise requesting automation should take this into account, but consultants and vendors also have a responsibility to pitch savings using a logarithmic return ratio, and not an 'exponential' one.

Automation vendors should also be doing more to offer best practices, and even solutions, to minimize the challenge of scaling. Some IT consultants could be doing better by addressing the challenges of maintaining a growing robot portfolio - especially as technology continues to evolve. One way that automation becomes more resilient is by pushing for API integrations over GUI automation as this ensures that less GUI upgrades will be necessary as underlying applications experience changes.

There are some players in the RPA space that support their clients' growth through an established operating model. Consider for example SmartRPA which offers solutions for intelligent robot orchestration and incident management.

Flawed RPA promises throw process improvement out with the bath water

Some overly excited consultants will tout the ability for RPA to automate processes in a matter of weeks. When this level of excitement is brought in at the executive level to usher in the ‘payroll savings,’ all other process improvement and lean reviews go out the door.

RPA may be worth it, but when coupled with flawed promises and an implementation where process improvement doesn't drive automation, it stops being worth it really fast. Implementations will stretch out from 2 months into 6 months. Subject matter experts will express concerns with how much time they have to spend on requirement gathering and modifications, especially as time passes and changes emerge. This 'automate first, optimize later' approach is a sure-fire way to fail hard and fail fast.

RPA is marketed as a stand-alone solution or 'great bandaid'

Many business users in the space of RPA are ‘applying patches or band aids’ in the name of ‘emerging technology’ for better or worse. If this wasn’t the case, then failure rates of RPA initiatives as high as 50% wouldn't be so common.

Digital transformation is much more beneficial to companies, whether undertaken internally, through consulting initiatives, or through a supplier that offers services in this space.

RPA in of itself is not a catalyst for transformation - it is just a tool like any other. As a company advances in its digital journey, RPA can provide benefits in specific use cases where other solutions are too expensive or take too long to implement.

Arguably, most companies fail in RPA implementations because they aren't in the technology services business and can't replicate RPA success internally. Another challenge for non-IT companies is identifying a trustworthy partner to help them drive successful RPA outcomes. After all, if a client isn't savvy in a particular technology, how will they know if the services procured are worth it until it's too late? One suggestion to work around this risk is to rely on proven IT partners to assist in standing up RPA, or to find the right consultants based on previous results and not sales decks.

RPA is not worth it because it scares employees

If you’d think that the only group of employees that are scared of RPA's ability to cut jobs are business users that complete mundane tasks, then think again.

RPA’s promise to ‘reduce the need for mundane tasks’ can be understood by management as a threat to their employees’ livelihood that they feel responsible for, as well as a threat to management’s own jobs (if less employees are needed then there’s less room for growth or improving quality year over year), and as a threat to ancillary departments.

Consider for example that IT system administrators who are paid to create employee profiles in disparate systems (and to maintain updated records of access) may view RPA as a threat to their own jobs that they've worked very hard to achieve. It's these same administrators that RPA implementation success relies on.

Put simply, the idea of flying robots coming into ‘help out the little guy do less boring work’ is taken as a threat by most employees. I've spoken with business analysts that are threatened by process mining (which is offered by RPA vendors) because it reduces their value regarding process improvement discovery.

RPA also threatens junior level developers since everything they’ve learned, such as setting up automation to scrape data, integrate disparate systems, and other tasks, can all be accomplished by ‘citizen developers’ and the likes that have never studied software development. Nevermind that the idea of citizen developers is a marketing idea utilized by RPA vendors, and that junior developers are actually better served to develop RPA solutions than traditional business users. As long as RPA scares employees, either through marketing that isn't well thought out or messaging from leadership that employees don't fully believe in, it will work against the goals that enterprises set in driving efficiencies through automation.

Footnote:

The term 'Robotic Process Automation' is used due to its popularity in the industry. Process automation is a clearer term that'll ideally replace 'RPA.'