You can try this experiment: search "is RPA dead?" on Google. Most of the articles you will find are so incredibly biased that it can be hilarious: articles sponsored by RPA companies saying that Robotic Process Automation is very much alive and healthy, articles sponsored by competing products trying to hammer another nail into the RPA coffin. The formula "is X technology dead?" for clickbait is not new, but people seem to have really gone to town with Robotic Process Automation. Everyone is trying to jump onto the RPA Dead or Not Dead train on one side or the other. The least entertaining ones will go for a Depends approach, because they always do. There seems to be more consensus on the internet about whether Elvis Presley really did die (he apparently did not, by the way) or whether the moon landing was real (it was, sorry conspiracy theorists) than about whether RPA is dead or not.
Which begs a whole different question: why is it so important to establish if Robotic Process Automation is dead? This is the question that is probably more intriguing, because I believe the answer will give us a glimpse into the true problem of RPA, and yes there is indeed a problem with RPA, that much is evident from the level of controversy. Admitting to that problem starts with acknowledging that the whole thing is not about ending the use of a technology, but about ending a hype.
Robotic Process Automation rose to prominence during the 2010s, and by the time the Pandemic hit it was basically what the general public thought of when they thought of automation. What was the secret of success? Probably the same as that of most successful products: good timing and even better advertising. RPA went big just in time to surf the first stage of the automation fad. From the mid 2010s or so onwards, any article with the word Automation on it was instant clickbait, and those articles started mentioning RPA more and more. There were other tools for automating, some that had seen more widespread use in the years prior, namely Business Process Management. However, RPA had something BPM did not at the time: it was visually striking, and well presented. You looked at the outcome of Robotic Process Automation and the Process part was not even in it, it was more like "holy crap an actual robot is imitating my clicks on the screen and doing my job for me."
And that is the second thing: The name. It had the word Robot in it. Yes, the word was invented by a Czech writer and popularized by a Russian-born American writer, you can look it up, but that is not important right now. Whereas Business Process Management sounds like something that is simultaneously below your paygrade if you are a C level executive, and above your paygrade if you are not, the word Robot appeals to everyone, from the top board member to their four-year old kid. So Robotic Process Automation had two of the most clickbaitable words in the actual name, and it did something which was easy to explain and very easy to comprehend once you saw it in action. In short, the perfect recipe for one of the most hyped-up products in this century. Besides all that, and to be fair, it was a useful product that filled a gap in the market that was not being properly serviced.
So, why are we not still sailing the blue seas of Robotic Process Automation, following the path of RPA anywhere it may take us? Because the fact that RPA sold like hot bread prompted its use for everything, even for things RPA was not designed for. Like MacGyver dismantling an atomic bomb with his Swiss army knife, it looks awesome, just maybe not very practical. Swiss army knives are great, but you would not want to take your car to a mechanic and see that the mechanic is going to be using one as their only tool to fix your transmission, regardless of how like Richard Dean Anderson he may look.
There are many great automation tools out there. Besides Business Process Management, low-code and no-code automation platforms for example have always been a go-to solution for implementers, because they are flexible and yes, they can integrate RPA as well.
Regardless of this, the hype got out of control more than a bit. The most important Robotic Process Automation vendors did a lot of their business through reseller partners; these partners joined the gold rush, pushed the popular product and tried to fit it into every use case, very often to the detriment of their clients, for example installing a robot to operate over a user interface that would change a month later and break the robot, instead of just calling an API. All because Application Programming Interface sounds boring and Robot sounds fun. This made some people very angry, namely experts who have always wanted to use the best tool for the job, which sometimes includes RPA and is not limited to RPA.
What aspects of Robotic Process Automation have they been bashing for a while now? Price, for one. RPA is expensive, and the pricing is not very flexible, whereas other tools out there have developed a pricing model that allows adjustments based on execution time and specific business metrics. Maintenance is another critical aspect: RPA requires ongoing attention whenever it interacts with operating systems, servers, machines, and infrastructure. This means always. Low-code tends to be more resilient. RPA requires a complex and resource-intensive infrastructure setup, which in the heyday of RPA was more than welcome by implementers who could make a hefty sum with drawn out projects, but at the end of the day is just not good for the client. Neither is the fact that, as mentioned earlier, something as simple as calling an API is made quite complex if one wants to do it using RPA.
Robotic Process Automation does excel in areas other tools do not, for example UI automation. This is even in the name of one of the biggest and fastest-growing RPA companies in the world. RPA is specifically designed for tasks that involve interaction with user interfaces, whereas BMP and low-code focus on backend processes and integrations. Then again, the whole problem with RPA was never about what RPA can and cannot do, rather about the way what RPA can actually do was communicated, and later amplified when marketed and sold.
Imagine people who love dogs and people who love animals in general. Whenever a Dog Person says to an Animal Person "I have a dog", the Animal Person wants to hear about it, because they are interested in all pets. However, when an Animal Person says "I have a cat," the Dog Person always says "I prefer dogs" and they proceed to talk about their dog. Dog People are completely oblivious to this, but it makes them terrible conversationalists, as it alienates owners of all other pets. The same happens between Robotic Process Automation companies and other technology-agnostic service providers or low-code automation companies. When a use case is shown to a general automation company, they will say "we can do this using a combination of tools, including RPA." If the same case is shown to an RPA company, they will say "we can do this using only RPA," which is of course not true, but is fashionable to say. This dispute is bad enough when there are two parties trying to agree, but then the clients get caught in the middle. That is when things get nasty. Clients are afraid of being oversold on technology, so more than one automation company has been talking to a client when they hear the rebuke: "what do you mean a combination of tools? We just talked to another provider, and they said they can do this using only RPA."
All of this has strained communications a lot, and as communications break down, many automation companies get fed up, try not to use RPA altogether (even in scenarios where it is useful) and we end up with people talking about the death of RPA and other people googling about it, which is right where we started.
All of the above has been happening for a few years now. As early as 2019 HFS was already predicting the downfall of RPA. The hype, which never stopped regardless, had another, more recent, undesirable side effect. We mentioned that Robotic Process Automation vendors did a lot of business through reseller partners; most of their business in fact. RPA companies were aggressively pushing their product through partners, not only using the RPA Can Do Everything argument, but also giving out really great margins to their reseller partners. A reseller partner could get up to 45% of the list price as margin if they played the game well. This is no longer the case. RPA vendors have started to realize that, since their product now sells itself and everyone wants to sell it for them, they no longer need to reward the partners that have been with them for the better part of a decade. This article will name no names, but when a 45% margin suddenly turns into 15%, a lot of implementers are ready to jump ship and adopt other tools, suddenly realizing that there is more that RPA cannot do than what it can actually do. Dropping profit margins will do that to people.
In conclusion, regardless of whether or not RPA is dead, what is surely dying is the hype, and with it the principle of ineffability that seemed to halo around Robotic Process Automation for a few years. The technology world seems finally ready to embrace other solutions. Low-code and no-code are on the rise, bringing with them the promise of a client-centric approach based on outcomes, using the best tools for the job. And yes, on occasion those tools may even include Robotic Process Automation.