Projets RPA : se poser les bonnes questions

Après les processus comptables et financiers, la Robotic Process Automation (RPA) s'invite désormais dans de nombreux autres métiers ou secteurs d'activité, tels que la supply chain ou encore l'assurance. Mais les objectifs ainsi que la faisabilité opérationnelle ou économique doivent être questionnés avant tout projet, pour lesquels d'autres solutions peuvent s'avérer suffisantes.

RPA : quels objectifs ?

Dans les organisations, la robotisation (physique ou logique) n'est pas synonyme de licenciements massifs. Dans la réalité, elle soulage plutôt les collaborateurs de tâches répétitives et pénibles, permet de limiter le recours à des CDD et autres intérimaires lors des pics activité ou encore d'accompagner la croissance à effectifs constants.

Dans tous les cas, rien ne peut remplacer l'intelligence humaine : il est ainsi beaucoup plus juste de parler de « cobotisation » (collaboration hommes-robots). En matière de RPA, l'objectif est plus de cibler la mise en oeuvre de processus semi manuels, lesquels sont automatisés à 80 % (idéalement) pour des tâches sans réelle valeur ajoutée. Les 20 % restant nécessitant une décision humaine.

La mise en place de processus automatisés poursuit à la fois des objectifs quantitatifs (réduction des coûts pour générer des gains de productivité et améliorer les marges) et des objectifs qualitatifs (réduction des délais de traitement, des erreurs de saisie, de la pénibilité au travail, amélioration de la relation clients.). Quand l'objectif est de réaliser des gains de productivité, il s'agit toutefois d'anticiper le déploiement des compétences libérées vers d'autres activités à plus forte valeur ajoutée ou d'autres postes, avec de la formation notamment.

Comment identifier les processus éligibles à la RPA ?

Avant toute chose, il faut bien comprendre que la RPA est un projet IT, autour d'une plateforme dédiée : son étude, son déploiement et sa maintenance impliquent une multiplicité des processus éligibles. Car à elle seule, l'automatisation d'un seul processus ne rentabilisera jamais l'investissement de départ. Dès la genèse du projet, il s'agit donc d'identifier un certain nombre de processus éligibles au sein de différents départements de l'entreprise, pour lesquels le ROI peut être atteint rapidement.

Ce qui inclut deux étapes : l'idéation d'une part, qui consiste à imaginer un processus sous sa future forme automatisée. Et la faisabilité opérationnelle et économique d'autre part : soit l'éligibilité du mode opératoire à l'automatisation et la nouvelle organisation qui en résultera.
Pour aider la démarche, des collaborateurs ayant des fiches de postes de travail identiques qui contiennent des tâches répétitives, similaires et à faible valeur ajoutée, sont souvent un bon indicateur d'un gisement d'automatisation.

Si les services administratifs, comptables et financiers, et plus globalement les fonctions supports, ont été les précurseurs de l'automatisation des processus, la RPA intéresse aujourd'hui de plus en plus les métiers. C'est le cas par exemple de la supply chain avec l'automatisation de la saisie de données des ordres de transport, du traitement ou du déclenchement de commandes. Ou encore, dans le domaine de l'assurance, de l'automatisation de certains processus liés à la relation client ou à la gestion de dossiers, pour lesquels l'humain ne traite alors que les exceptions.

Quant à l'éventualité de coupler la RPA avec de l'intelligence artificielle et du machine learning, si cela reste bien sûr envisageable, la complexité et les coûts liés à ces technologies et le temps d'apprentissage sont à mettre dans la balance avant de se lancer.

La RPA est-elle la solution dans tous les cas ?

Si la RPA est capable de beaucoup, ce n'est pas une raison pour la déployer partout ! En réalité, tout dépend de la stratégie SI de l'organisation, et de l'existant. Ainsi, en présence de batch capables de gérer 80 % du processus, leur remplacement par la RPA n'a que peu d'intérêt. De la même façon, plus un système d'information est ouvert, notamment par la présence d'API, plus il est en mesure de répondre à de nombreux cas d'automatisation.

À l'inverse, plus un SI est fermé, plus la RPA trouve généralement son intérêt. Car s'il est toujours possible demander à un éditeur le développement d'un web service spécifique par exemple, cet élément devra être maintenu dans le temps. Dans ce cas précis, la RPA permet de conserver une certaine autonomie.

Quant à la préexistence d'une solution de Business Process Management (BPM), celle-ci ne remplit pas tout à fait le même rôle : pour faire simple, le BPM, dans son rôle d'organisation des processus, est le cerveau, là où la RPA, qui permet d'automatiser des aspects opérationnels normalement traités par des opérateurs, représente les bras et les jambes.

En résumé, tout ce qui peut être réalisé sur un PC est potentiellement automatisable, et la RPA est particulièrement adaptée à l'automatisation de modes opératoires multi-applications.

Pour autant, il n'est ni possible ni souhaitable de chercher à tout automatiser : des opérations resteront du ressort de l'humain, comme c'est le cas de la décision du montant d'une remise commerciale ou encore de l'étude de fond d'un dossier (et pas seulement de la présence des pièces). Et quoi qu'il en soit, le rapport valeur attendue / investissement de départ doit être soigneusement étudié avant de se lancer dans tout projet d'automatisation, car c'est bien sur l'optimisation des coûts et des performances que seront jugés les projets RPA

Jérôme Blanchard, Responsable de l'offre RPA - Hardis Group.