RPA introduces a new paradigm in office automation: Software robots.
I, a positive person by excellence, prefer titles such as “The next step to improve the world”, or “All the good things you need to know about X”. However, the final title reflects the content, that’s what’s important.
When we first talked to a person about RPA and looked at their brain what we saw was, at least, surprising.
We noticed how he imagines small (or big) machines manipulating the keyboard of computers with scalpels (or big maces) as more or less with retractable fingers.
When we continue the conversation and begin to introduce the word software into it, while still observing the thoughts of our interlocutor, we arrive at something even more surprising: we see piles and piles of documents and dozens of robots turning the pages one by one and reading, reading, and reading.
Yes, RPA are physical robots that read documents, machines whose main mission is to apply revolutionary (non-existent) optical character recognition (OCR) techniques, which will manage to sort, classify, and introduce all that information into our client’s archaic systems.
Well, I’m afraid not.
There is something revolutionary about RPA, but not on a physical level, rather on a concept level. RPA are programs that use other programs. It is not something revolutionary for the average computer scientist but for the general public it may seem like rocket science.
RPA arrives to fill a gap, usually due to poor integration, between different systems. Previously, a long and costly project involving time and money was necessary to achieve an integration smaller than desired by the client and much smaller sold by the supplier. Now, with RPA, only a small project of only a few weeks is necessary, where the requirements are extraordinarily easy to obtain, and the results very easy to measure.
The requirements are easy to obtain since, to a great extent, they are limited to using the existing applications; in many occasions as people do and in many other cases in a more efficient way, always doing the work much faster.
The result is simple to measure. It is an arithmetic question: data processed, time invested, cost of robotization.
RPA allows us to carry out these types of projects even when the client does not have control over the systems, as in the case with BPOs or medium-sized companies who do not have their own software.
However, and going back to what the novel interlocutor in these matters imagines RPA to be, perhaps we are the wrong ones, why?
Perhaps our vision is vitiated by knowledge, although it seems incredible, these things happen even in the best families, the different level of knowledge about a subject among the people involved in a conversation can cause communication problems, directly related to what happens when you begin talking about RPA.
When I was young, back in the old 20th century, before the millennials and streaming of TV, as I started talking about something technical with someone else, the first thing I did was to ask them how much they knew about it, so I could adjust my vocabulary and expressions. It was an anti-frustration preventive measure that achieved just the opposite effect: irritating the other party. With time I learned that it was better to start from the bottom, there would always be time to speak at another level.
Most likely, the same thing will happen with RPA, but without the preventive measure and without starting from the bottom, a mistake. Surely, we should start talking about software robots instead of RPA. Software robots is an expression that comes closer to what you really want to express when you say robotic process automation (RPA) and is even a more rare combination of words for anyone.
Software Robots leaves no room for doubt as to what kind of software is being built, in RPA there is no software anywhere. It also makes it clear that this software performs tasks autonomously, just like any robot. Of course, the best way to test motion is to run it, as we are computer scientists: we will do tests!
We have carried out various experiments, paying special attention to the first reactions and questions observed by audiences. Let it be known that this is not a real scientific experiment, only a sampling of reactions.
Beginning the conversation and introducing the concept of software robots, the interlocutor thinks of traditional system integration but with a more agile approach. He also thinks that the robot will use the applications as they are right now, without changes in them, and that he will use them as if he were a person.
From there, he starts thinking about his business. He thinks he needs to have system users for the robots, he thinks about passwords, roles, permissions. He thinks he needs a certain control panel to know what each robot does, on what computer, if there is one waiting for execution.Think about what RPA is, what we want you to think about when we talk about it, curiously without ever mentioning RPA.
It seems that for computer scientists what is RPA, for users is software robot. This wouldn’t be the first time we’ve made a mistake with the naming of something.
CTO at Jidoka.