Processus : repérez vos bons candidats pour la RPA
La RPA est un très bon outil d’automatisation. Mais il n’est pas adapté à tous les processus. Voici dix critères pour sélectionner ceux de votre entreprise qui sont le plus adaptés à cette technologie et qui en tireront le plus de valeur.
La Robotic Process Automation (RPA) est la nouvelle méthode pour automatiser les processus métiers. Elle s’inscrit dans la longue lignée des outils d’intégration (Middleware, ETL), de développements (APIs) et du BPM. Le Gartner considère d’ailleurs que l’intérêt de la RPA est d’être utilisé conjointement à ces technologies dans le cadre de ce que le cabinet d’analystes appelle « l’hyper automatisation ».
Reste que les bots RPA – autonomes ou supervisés, seuls ou combinés dans une stratégie de bout en bout – possèdent leurs propres spécificités. À la différence des outils qui les ont précédés, ils automatisent en passant par les interfaces des applications, sur le poste de travail, en imitant les manipulations des utilisateurs – là où les autres méthodes sont historiquement centrées sur le back-end et sur la couche applicative elle-même.
Jean-François Pruvot –
BluePrism
« Ce sont des approches différentes […] La RPA s’appuie sur les interfaces. L’énorme avantage c’est que l’on n’a pas besoin de savoir comment cela se passe derrière », résume Jean-François Pruvot, Vice-Président Europe du sud de BluePrism.
La RPA peut donc prendre en charge ce qui n’a pu être automatisé par ailleurs. « Par exemple : quand il n’y a pas d’API », ajoute Arnaud Lagarde, Directeur Europe du sud d’Automation Anywhere. Ce genre de cas se présenterait souvent sur le terrain, comme lorsqu’une entreprise souhaite migrer des données de ses anciens OS/390 ou AS/400 vers un nouveau système. Un casse-tête que la RPA peut résoudre plus rapidement – en passant par l’interface utilisateur de l’application mainframe – que par un développement souvent lourd et coûteux.
D’ailleurs, même quand les APIs ou d’autres moyens existent, la relative rapidité de mise en place de la RPA peut en faire une bonne option. Plusieurs acteurs majeurs du secteur ciblant les grands déploiements de bots considèrent, par exemple, la fin du support de SAP pour ECC (et les migrations de données vers HANA ou vers d’autres SGBD qu’elle implique) comme une opportunité pour la RPA.
Bref, la RPA est (souvent) un bon outil. À condition de l’appliquer au bon processus, et donc de connaître le profil type de celui-ci.
Quel process automatiser avec de la RPA ?
Arnaud Lagarde –
Automation Anywhere
« Il faut que le processus soit répétitif, structuré, avec des données en entrée à la fois structurées et numérisées, et avec du volume à traiter », liste Arnaud Lagarde - qui précise bien que, pour lui, il s’agit là d’un profil pour une utilisation de base de la RPA, mais que d’autres, plus évoluées sont possibles (lire ci-après).
« Le processus doit également être stable dans le temps et s’appuyer sur des règles de logiques », complète-t-il.
BluePrism confirme ce portrait type, avec quelques nuances supplémentaires. Il faut que le processus soit effectivement « documenté, avec une forte intensité en volume, et sur des données structurées », mais aussi « itératif » – c’est à dire linéaire avec des actions qui s’enchaînent et non avec des actions en parallèle. Autre précision, pour Jean-François Pruvot, le processus idéal implique « des back-offices disparates et multiples ».
Toujours selon l’expert de BluePrism, le processus doit par ailleurs avoir « le moins d’exceptions possible à gérer – qu’elles soient techniques ou fonctionnelles ». Dans le cas des exceptions, en effet, le bot doit s’interrompre pour demander l’intervention de l’humain qui reprend alors la main pour valider et/ou trancher d’éventuelles incohérences, ou apporter des précisions nécessaires au bon déroulement du processus.
Sébastien Gontran –
UIPath
Toutes les tâches d’un processus ne doivent cependant pas forcément être automatisées pour que le processus reste éligible, nuance Sébastien Gontran, Technical Consultant chez UIPath. « L’éligibilité se prononce sur l’ensemble du processus, ce qui signifie qu’un processus peut être automatisé – même si une minorité de ses tâches sont automatisables – s’il répond bien aux critères de faisabilité communément admis pour les processus RPA », résume-t-il.
Il ajoute aux critères cités par BluePrism et par Automation Anywhere, qu’il faut que le processus possède « de nombreuses étapes manuelles » qui sont autant « de risques d’erreurs ».
Un ROI sinon pas de RPA
La RPA n’étant pas gratuite, trois experts s’accordent aussi sur le fait qu’il faut sélectionner un process dont l’automatisation a un résultat évaluable de manière objective (nombre d’heures/hommes gagnées, réduction de coûts, baisse du nombre d’erreurs, respect des délais, etc.) et un ROI réel. D’où l’importance d’avoir un processus « avec du volume », insistent bien Jean-François Pruvot et Arnaud Lagarde.
Dit autrement, et au risque d’enfoncer une porte ouverte, le processus visé doit avoir une automatisation qui génère de la valeur et une valeur quantifiable.
Dans le cas contraire, certains processus identifiés comme éligibles avec les critères de faisabilité ne doivent pas être retenus, avertit Sébastien Gontran de UIPath : « par exemple, le processus de clôture [annuelle] des comptes d’une organisation ne sera [a priori] pas automatisé, car même s’il est répétable (basé sur des règles) et répétitif (tous les ans), la fréquence (1 fois par an) ramenée au coût de développement fait que les gains escomptés ne franchissent pas le seuil a minima de l’indicateur économique ».
« Human in the Loop » : les processus « à exceptions » également éligibles
Un gros problème de ce portrait type est qu’il ne toucherait que 20 % des processus des entreprises, estime le responsable d’Automation Anywhere.
La première limite pour que la RPA s’adapte à plus de cas, est celle soulevée par BluePrism sur les exceptions. Dans l’absolu néanmoins, des processus « à exceptions » restent parfaitement éligibles à la RPA, si on aborde le projet dans une optique dite de « Human in the Loop ».
« C’est là où l’on commence à introduire la notion “d’équipe”, au-delà du “un humain, un bot”. »
Jean-François PruvotBluePrism
Pour Automation Anywhere, c’est d’ailleurs une des évolutions clef de la RPA par rapport au Robotic Desktop Automation (un bot purement local, attaché à un seul poste de travail) que de créer des équipes transverses, qui mélangent des bots et des utilisateurs humains. « C’est là où l’on commence à introduire la notion “d’équipe”, au-delà du “un humain, un bot” », confirme Jean-François Pruvot. « Le bot commence sa tâche, puis fait appel à un humain – l’employé A – puis il va chercher une information chez l’employé B, puis il continue sa tâche, et ainsi de suite ».
La notion d’exception peut donc être gérée avec l’« humain dans la boucle », même si, inévitablement, cette méthode ralentit l’exécution et apporte des contraintes supplémentaires (comme le fait que les employés doivent être présents pour que l’automatisation continue).
L’IA pour une RPA appliqué aux processus à données non structurées
Une autre évolution clef est l’arrivée de l’Intelligence Artificielle dans la RPA. L’IA permet de rendre encore plus de processus éligibles à cette forme d’automatisation en faisant sauter une autre barrière : celle des données structurées.
« Beaucoup de processus traitent des données non structurées ou semi-structurées, qui sont dans des documents comme des PDF ou des Word. »
Arnaud LagardeAutomation Anywhere
« Beaucoup de processus traitent des données non structurées ou semi-structurées, qui sont dans des documents comme des PDF ou des Word », note Arnaud Lagarde. En traitant ce problème en amont, l’informatique cognitive et l’OCR intelligent permettraient de passer de 20 % à plus de 50 % des processus automatisables par la RPA.
Concrètement, avec l’Intelligence Artificielle, la RPA peut « lire » une facture ou une commande, en comprendre les champs (adresse, nom, lignes de produits, total, TVA, etc.), en extraire les données clefs (prix, nombre d’unités commandées, etc.), les vérifier à la volée (le total de la commande correspond-il bien à la somme des lignes produit), puis les ventiler et les ingérer dans les systèmes concernés (comptable, supply chain, CRM, etc.).
Dans l’exemple ci-dessus, si l’IA trouve une incohérence dans la facture entre la somme des items et le total, ou si le document est illisible, alors un utilisateur recevra une notification pour gérer manuellement le problème puis donner le feu vert au bot de la RPA pour qu’il continue son travail.
La RPA peut donc aussi traiter des processus à données non structurées, mais il faut cependant garder à l’esprit que ces modules (« IQ Bots » chez Automation Anywhere par exemple) ont un coût supplémentaire non négligeable. Et que toute IA doit être entraînée, ce qui prend forcément du temps.
Conclusion : les 10 critères à respecter pour la RPA
Un bon candidat pour la RPA est donc un processus :
répétitif
manuel avec des risques d’erreur
itératif
structuré et bien documenté
stable dans le temps
qui s’appuie sur des règles de logiques
qui implique des back-offices disparates et multiples
avec une forte intensité en volume (pour le ROI)
avec le moins d’exceptions possible (sauf à entrer dans une logique plus complexe de « Man in the Loop »)
avec des données en entrée numérisées et structurées (sauf à utiliser l’IA ; moyennant un coût additionnel)
Jean-François Pruvot –
Arnaud Lagarde –
Sébastien Gontran –
