olly - stock.adobe.com

Processus : repérez vos bons candidats pour le RPA

Le 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.

Cet article se trouve également dans ce contenu premium en téléchargement : Applications et données: Applications et Données n°8 : Processus : les bons candidats pour le RPA

Le 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 du RPA est d’être utilisé conjointement à ces technologies dans le cadre de ce que le cabinet d’analystes appelle « l’hyper automatisation ».

Suite de l'article ci-dessous

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. A 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 BluePrismJean-François Pruvot -
BluePrism

« Ce sont des approches différentes […] Le 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.

Le 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 le 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 du 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 le RPA.

Bref, le 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 du RPA ?

Arnaud Lagarde – Automation Anywhere 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 du 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 possibles à 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 - UIPathSé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

Le RPA n’étant pas gratuit, 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 le 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 au 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 du 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 un RPA appliqué aux processus à données non structurées

Une autre évolution clef est l’arrivée de l’Intelligence Artificielle dans le 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 le RPA.

Concrètement, avec l’Intelligence Artificielle, le 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 du RPA pour qu’il continue son travail.

Le 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 le RPA

Un bon candidat pour le RPA est donc un processus :

  1. répétitif
  2. manuel avec des risques d’erreur
  3. itératif
  4. structuré et bien documenté
  5. stable dans le temps
  6. qui s’appuie sur des règles de logiques
  7. qui implique des back-offices disparates et multiples
  8. avec une forte intensité en volume (pour le ROI)
  9. avec le moins d’exceptions possible (sauf à entrer dans une logique plus complexe de « Man in the Loop »)
  10. avec des données en entrée numérisées et structurées (sauf à utiliser l’IA ; moyennant un coût additionnel)

Pour approfondir sur BPM

Close