Robotic Process Automation


What is a Robot?

The word "robot" comes from the Czech "robota" and means "compulsory labor". That fits the bill quite well. The Robotic Industries Association (RIA) on the other hand defines a robot in a more modern sense:

"A robot is a reprogrammable, multifunctional manipulator designed to move material, parts, tools or specialized devices through variable programmed motions for the performance of a variety of tasks."


When someone born before Generation X thinks about a robot, the first things to come to mind will likely be the amiable droids from Star Wars, R2D2 and C3PO. These could, case in point, be called "robots" by the RIA definition.

It is common marketing practice to exaggerate function and form greatly. The "robotic lawnmower" you might have to keep your grass cut or the "robotic vacuum" that runs through your home office at night, sucking up the detritus of a working day are
not true robots by that definition. They are not reprogrammable, nor are they multifunctional. They are simply machines, though some manufacturers are now turning to AI to add "Intelligence" to the path a robotic lawnmower (or vacuum) takes.

But R2D2 and C3PO are capable of so much more than manipulation. What the RIA definition lacks, of course, is any mention of intelligence or cognition. The definition covers industrial robots that are
programmed by humans to interact with their environment, not necessarily to learn from it (although here, too, a lot of research is being done to add true "intelligence" to industrial robots).

What is a Robotic Process Automation?

Now that we have a clearer picture of what a robot is, what is meant by Robotic Process Automation (RPA)? The RIA definition is, for the most part, quite fitting: RPA involves software that can be programmed to manipulate other software, as a human operator might, "for the performance of a variety of tasks". The Institute for Robotic Process Automation goes into more detail here.

Take the example of a bank fulfilling various compliance regulations when setting up a new mortgage contract. Here, the application form is very likely on paper. The core Banking system, in which the accounts are set up, probably sports a web interface but may still be host-based (i.e. a Terminal interface). A credit check would likely be a web portal, a
webservice or - in some cases - a text-based query-response system. Throw in a legacy banking database running on a host system with a text-based terminal and you have the daily grind of a mortgage specialist.

While humans can certainly be trained to operate these different systems to pull and push information (and they are), these activities hardly use the cognitive complexity of a human mind.

This is where RPA comes in. With the flexibility of the RPA interface, each interaction with a particular system is set up to work with the system as a human operator would. Modern RPA systems do not require any programming - all setup is done in a similar fashion as showing a new worker how to perform the tasks.

This has two advantages: for one, software robot setup can usually be performed by the knowledge workers that know the procedures by heart. Also, the system operated on will not "realize" that it is being manipulated by another software. This second advantage isn't important for internal banking systems, as these normally do not have "robot detection" algorithms.
Information services that operate externally, such as pay-per-use services, often do. Some of these services are provided on a cost-per-account basis.

Once RPA is implemented to interact with the service, it can do so highly efficiently and with a single user account for the entire organization - which obviously isn't in the interest of the provider. Also, because robots are highly scalable