Regional trains (RPA) or high speed trains (API) ?

TGV is used much less than regional trains

In a recent post of one of my RPA community colleagues, a traditional IT developer who pivoted his RPA company to an API company, told us to use API over RPA, whenever API exists. This is like saying always take the TGV if you go from Paris to London. This obviously caused me to search for examples where this is simply not true. As a person who is in the middle of this political battle, I have plenty of examples.

But before my example, I think it is very useful to paraphrase the ex-UiPath evangelist Guy Kirkwood, now retired, who told this simple analogy: RPA is like a regional train (he might have said car, but I adapted the example), while API is like a high-speed train. API is to be used whenever you want to go from point A to point B, fast. Let’s say you want to go from Paris to London. You do not need to stop in between, you are in a hurry and do not want to admire any landscape. Then, yes, that is a great choice, if you can afford the high price of the TGV. But if you want to make a stop in Belgium, to pick up a friend before going to London for another friend’s bachelor’s party, or you want to pick your father from Lille before going to see your sister in London, then the high speed train is not serving your purpose, and you will take a couple of regional trains that offer the flexibility you need, even though it will take you a bit more time to your destination. This is a good example of when to use API and when to use RPA, and traditional IT simply refuses this choice, saying it’s always more advantageous to take the high-speed train, which is simply not true.

Actually, I went to check this example with real data. I went to check the revenues of TGVs in France versus the revenues of the regional trains, and guess what I found. The regional trains have by far a higher revenue than the TGV, which is logical and obvious, except for the traditional IT who still thinks the TGV would be the only option possible moving from point A to point B. Even when it comes to job creation or profitability, API (TGV) cannot beat RPA (Regional trains), and this is something we see in automation or in transporation.

First column is TGV, while second column is Regional trains

With prices up to 10 times the cost of RPA, API based solutions are expensive. Please explain to me, as I am yet to understand, why would you pay 10 times more for something that does exactly the same thing as the other? Even though UiPath accepts that RPA has a higher maintenance cost than API, I respectfully disagree with that, as I found that you also need at least 2-4 hours monthly to maintain an API, which is in line with the cost of maintaining a mature RPA bot.

Trust me, I have done RPA since 2017 and I know what I am saying. A mature RPA bot needs at most 2-4 hours of maintenance every month, some RPA bots needing almost zero touch for as long as years. Another article I found spends some time comparing the two solutions and RPA clearly overtakes API in 4 categories (implementation complexity, time to market, cost, learning curve), while API is only superior in 1 category (maintenance). I excluded the scalability category from this comparison as I do not agree with the author of that article that you cannot scale RPA. Maybe this is a misunderstanding, that is why I excluded it.

In another article that promotes large hybrid approaches of both API and RPA when doing digital transformation, the author mentions that API is “strategic”, which cannot be more wrong. In my opinion, API cannot be “strategic” for the simple reason that RPA includes API, but API cannot include RPA. Therefore, the real strategic one is RPA.

Let’s move on. Another article gives three main advantages for RPA compared to API: being focused on a single platform, or how others call it, being platform-agnostic, the fact that is less reliant on IT experts, and mainly because of its cost advantage. Similarly, another article gives 5 reasons why RPA is better than API, among them the fact that API is risky, that it consumes more resources and time. Another opinion is more balanced and thinks a hybrid approach with both RPA and API is ideal. However, they prove the industry is now confused whether the costs of maintaining an API is less than the cost of maintaining a bot, with this article being opposed to the common belief in the industry that the cost of maintaining an API is less than the cost of maintaining a bot. They also end their view with this sentence: in case of frequent changes in the process, it is preferable to use RPA. With this sentence, it is clear that in an ever-changing environment, the use cases for API become less and less.

RPA is by far the more flexible solution. As I explained in the beginning of my article, API is useful when you really want to go fast from A to B, which is not the majority of the cases. More often, you use the RPA platform and within it call an API where it exists between two applications and can be easily used, which is not so often. A process includes some data exchanges between two systems, but the data exchanges between two systems are never the whole process.

Usually, the process starts with some insights and decision making and that should be left to the human, which can be automated with RPA. Finally, another article recognizes that in most cases RPA is preferable to an API, which is in line with what all the practitioners in the field of process automation observed. Except some people, like the one which I mentioned at the beginning of this article and who pivoted his RPA company to API. But it seems he did not read any literature, he was just misinformed by the likes of Microsoft, Apple, Facebook, SAP, Salesforce, which want RPA to disappear, but which obviously will not happen any time soon.

Unless IT starts understanding that RPA is here to revolutionize the whole office work, they will be required only to set a couple of APIs once in a while. That will be the new role of IT, together with security, which will be a far cry from its role it pretends to have today in driving business growth.

What will be the next step for RPA?

Learn from the past mistakes

Maybe the Orchestrator platform, or in terms of software for developing
these bots. UiPath solution is something that is kind of written in stone, or are there some other software that maybe are having additional features or a bit more flexibility. I don’t know this is something that is in the scope, or maybe should constrain ourselves to UiPath solution. Overall, I think that the current processes are working quite fine. Obviously, not all of them, but in many cases we have seen that it’s rather related to the currently
used business processes and systems.

I think we need to gather the feedback, what went well, what not so well, then we analyze the lessons that we learned from the previous projects and it really depends on what went well or not so well. You should establish a
plan to improve implementation. Which really depends, because there is no fixed answer for that. But I think the process is to learn from the past and improve.

What I have in my mind is the documentation. It’s not even who should do, but how should we do it. In my opinion, the way we do it, huge documentation in Word is not appropriate.

I think that RPA could be used to replace all the HR related things. I know that many companies, I know ours as well, are still relying on human workforce, for example to pay salaries, which isn’t bad necessarily, because a human can control all the numbers and so on, but at the other side, human can make mistakes with numbers. So, I think companies should focus on automating salary payments, or payments in general, and anything related to money could be automated, because if a robot is fed well, with details, then from that moment, it should work without any problem. And there are still humans to help. And I heard that many companies still rely on software or hardware which are from the 1970s, 1980s or even older. Because they are working fine, but you never know what happens. And
such things can be done by automated robots. And I think companies should focus on such things, not improving the software, but immediately implement automation in such cases. So financial things actually.

Before going to the next step, we have to all learn from the failures of the past implementations, from the previous phases. So make sure you try to avoid these kinds of issues in the future, make sure you got everything written in a professional way, and the level of communication could be accurate and understand the business needs. There is way to implement future projects, but you have to avoid the repetitive issues appearing, and understand the rationale behind it.

Currently we are in the era of stupid bots, right? The next one is supposed to be smarter ones. We’re supposed to have smarter and smarter bots and more abilities for the bot for example. Currently the bot cannot understand human language. If our customers write an email to us, the bot cannot read it, they don’t understand. The next generation of bots is supposed to have
more on AI, more Machine Learning and more Natural Language Processing. So, they can understand the email, and then we come to non-human work only.

I remember there were some chats about the optical readers. So I think that the optical reader field can open a lot of opportunities. Because we still have many processes which are based on the paper. And on the paper means on the scanned documents, for example. Having an optical reader for that it can improve a lot. And of course, I am thinking about the cash
application. So having the bot able to read what this payment is for would help a lot. Because we still have manual cash application performed.

I can think only about one. It was strangely easy to build a bot, but it’s very hard to maintain a bot. So, I would go in the way where the necessary changes that are coming out from the business could be more easily applied within the process. Meaning, there are some working parameters of the bots, and they could be hardcoded within the scripts, could be exported to external config files, and a way easier how to maintain the process is when we could work on external files and the logic was clearly
described. So, I would go in this place as a next step of RPA process. To make it easier to maintain, to apply any changes in the future.

What does the industry say?

According to SearchITChannel, next step is what Forrester calls “digital worker analytics”, or what has recently been called process mining or task mining. This kind of analytics is not only great for discovery, but also for the much needed standardization. Additionally, intelligence can be pursued to accommodate for the exceptional scenarios, according to the same article. Finally, an alternative direction for a part of the RPA vendors is ease-of-use.

According to RockingRobots which quotes various characters in the industry, it is various kind of intelligence that is the next step for RPA, be it document understanding or conversations AI.

According to Dynatos, combining RPA with workflow orchestration, unstructured data capture, OCR, machine learning, advanced analytics and e-signature converges into the next level of RPA, intelligent automation.