Depuis quelque temps déjà, les entreprises font appel, pour des tâches qui répondent à ces 2 caractéristiques – elles sont répétitives et en grand nombre - (typiquement des tâches de back-office), à un outil de RPA (Robotic Process Automation).
L'objectif de RPA est de mettre en place des robots – c'est ainsi que ça s'appelle – pour prendre en charge ces tâches et ainsi se substituer aux salariés qui les réalisent. Ces robots ont la particularité de travailler 24h/24, 7j/7, et sans se "fatiguer", autrement dit sans être en mesure de faire les erreurs qu'un salarié pourrait être amené à faire, du fait justement de cet aspect de répétitivité et qui entraîne de la fatigue et de la lassitude.
On fera appel à du RPA dans un nombre important de départements dans l'entreprise : comptabilité, finances, RH, logistique, etc.
Avant d'aborder le mode de fonctionnement de RPA, l'évidente première critique concerne l'impact de RPA sur l'activité du salarié voire même sur son poste. 2 réponses à ce problème soulevé. D'une part, les robots RPA ne remplacent que les tâches répétitives et sans grande valeur ajoutée, et non toute l'activité du salarié. Par ailleurs, dans le cas où l'activité même du salarié serait menacée – ce qui est possible – cela devrait s'inscrire dans une transformation plus profonde de l'entreprise, autrement dit c'est un problème de management.
Comment fonctionne RPA ?
.Sans préjuger des différences entre les différentes solutions de RPA disponibles sur le marché, d'une façon générale, le RPA fonctionne de la façon suivante.
Le robot ou bot, va émuler donc une tâche spécifique d'un salarié. Il sera créé par un spécialiste RPA qui au fond est un développeur. On parlera d'un "bot creator". Ce bot pourra interagir aussi bien avec des systèmes d'information comme un ERP ou encore des sites Web – du domaine public ou de l'entreprise -, etc.
Concernant la création de bots, il existe une "bot economy", une place de marché où on peut vendre et acheter des bots. Ce qui réduit le temps de création de bots.
Une fois fonctionnel, ce bot sera stocké dans un référentiel de bots – "bots repository" -, prêt à l'emploi. On pourra faire notamment du versionning de bots.
Enfin pour utiliser ces bots, de façon programmée ou à la demande, on fera appel à ce qu'on appelle un "bot runner", un lanceur de bots.
Comment on aborde un projet RPA ?
Comme dans tout projet informatique, on va démarrer par une phase d'analyse fonctionnelle. Où l'on va comprendre ce que fait le salarié, d'une façon particulièrement détaillée, pas à pas, et si possible en faisant des copies d'écran de toutes les tâches qu'il réalise.
Une particularité d'un bot, c'est qu'il n'est pas en mesure d'apprendre. Autrement dit, quand un bot va rencontrer une exception à ce qu'on lui demande de faire, il ne pourra pas le faire et il s'arrêtera vraisemblablement.
L'analyste va donc devoir être particulièrement attentif aux exceptions. Que faire si tel site Intranet n'est pas accessible ? Que faire si le login / mot de passe pour accéder à telle application a été modifié ? Etc.
Une fois que l'analyste détient la description le plus exhaustive possible, aussi bien du fonctionnement normal du processus que de ses exceptions, il va construire le bot. Ce bot n'est autre qu'une liste d'entrées dans un programme informatique – du code – qui émule l'activité du salarié.
Une fois le bot écrit, il sera testé et mis en production dans le centre d'exécution de bots.
Un outil de RPA peut venir se greffer assez naturellement sur un outil de BPM. En effet, il est naturel et facile à faire, de remplacer dans un modèle BPMN - et par la suite dans son exécution -, certaines tâches utilisateurs par des bots.
Même si RPA est un outil :
- qui se vend de façon indépendante
- a un coût bien plus abordable qu'un outil de BPM, et donc son cycle de vente est plus rapide
- est parfois un point d'entrée dans cette démarche d'automatisation de processus, l'outil de BPM suivant
RPA peut être perçu comme une surcouche de BPM.