For some time now, companies have been calling for tasks that meet these two characteristics - they are repetitive and in high volume - (typically back-office tasks), to a tool of RPA (Robotic Process Automation).
The goal of RPA is to set up robots - that's what they're called - to take over these tasks and thus replace the employees who carry them out. These robots have the particularity of working 24 hours a day, 7 days a week, without getting tired, ie without being able to make the mistakes that an employee could have to make, precisely because of this aspect of repetitiveness. which leads to fatigue and weariness.
RPA will be used in a large number of departments in the company: accounting, finance, HR, logistics, etc.
Before discussing the way RPA works, the obvious first criticism concerns the impact of RPA on the activity of the employee or even on his job. There are 2 answers to this issue. On the one hand, RPA robots replace only repetitive tasks with little added value, and not all the activity of the employee. Moreover, in the event that the employee's own activity would be threatened - which is possible - it should be part of a deeper transformation of the company, in other words it is a management problem.
How does RPA work?
Without pre-empting the differences between the different RPP solutions available on the market, generally the RPA works as follows.
The robot or bot, will emulate therefore a specific task of an employee. It will be created by an RPA specialist who basically is a developer. We will talk about a bot creator. This bot can interact with information systems such as an ERP or websites - public domain or company - etc.
Regarding the creation of bots, there is since March 2018 a "bot economy", a market place where you can sell and buy bots. Which reduces the time of creation of bots
Once functional, this bot will be stored in a "bots repository", ready to use. We will be able to make versionning of bots.
Finally to use these bots, programmed or on demand, we will call what is called a "bot runner", a launcher bots.
How do we approach an RPA project?
As in any IT project, we will start with a functional analysis phase. Where we will understand what the employee does, in a particularly detailed way, step by step, and if possible by making screenshots of all the tasks he performs.
A particular feature of a bot is that it is not able to learn. In other words, when a bot encounters an exception to what it is asked to do, it will not be able to do so and it will likely stop.
The analyst will therefore have to be particularly attentive to the exceptions. What if this Intranet site is not accessible? What if the login / password to access such application has been changed? Etc
Once the analyst has the most exhaustive description of both the normal operation of the process and its exceptions, he will build the bot. This bot is nothing other than a list of entries in a computer program - code - that emulates the activity of the employee.
Once the bot writes, it will be tested and put into production in the bots execution center.
A tool of RPA can be grafted quite naturally on a tool of BPM. Indeed, it is natural and easy to do, to replace in a BPMN model - and later in its execution - some user tasks by bots.
Even though RPA is a tool:
- which sells independently
- at a much more affordable cost than a BPM tool, and thus its sales cycle is faster
- is sometimes an entry point into this process automation approach, the next BPM coming later
RPA can be seen as an overlay of BPM.