Le potentiel transformateur de la RPA

Il ne fait aucun doute que la RPA peut tenir cette promesse. Les organisations du monde entier font état des avantages transformationnels liés à la délégation de tâches de routine à des bots.

Étudions le cas du Bureau de normalisation NBN, l'agence belge responsable de l'élaboration et de la publication des normes. En 2021, elle a déployé un bot chargé de collecter et de saisir les informations relatives aux bulletins de vote, une tâche laborieuse qui était auparavant effectuée manuellement. En conséquence, le NBN est passé de 800 normes publiées par an à 2 150. Comme il a été démontré que chaque norme nouvellement publiée augmentait le produit intérieur brut (PIB) de la Belgique de 2,04 millions d'euros par an³, le bot a eu un impact significatif sur l'économie belge.

Prenons la situation de Primanti Brothers, la célèbre chaîne de restaurants basée à Pittsburgh, en Pennsylvanie. Au cours de ses 89 années d'existence, l'entreprise n'a jamais cessé d'innover. En 2021, elle a identifié une opportunité d'automatiser la production des rapports des ventes quotidiennes provenant de 40 sites à l'aide d'un bot RPA. Chaque responsable régional consacrait auparavant 45 minutes par jour à cette tâche ; elle est désormais effectuée en trois minutes, ce qui permet d’économiser plus de 2 000 heures par an. Grâce à ces précieuses heures gagnées, les responsables peuvent consacrer plus de temps à la satisfaction des fans de la chaîne.

Examinons à présent Credigy, une entreprise spécialisée dans le crédit à la consommation basée à Atlanta, en Géorgie (États-unis). Elle a su voir le potentiel stratégique de la RPA dès 2018, en identifiant les tâches répétitives et routinières de l'entreprise qui pourraient bénéficier de l'automatisation. Les tâches de bas niveau chronophages pour les experts, telles que la vérification manuelle et le changement de nom de milliers de fichiers, ont été déléguées à un bot. Au cours de la première année d'utilisation de la RPA, Credigy a automatisé 25 processus : ainsi, ses analystes hautement qualifiés étaient libres de négocier les contrats complexes qui sous-tendent les solutions financières créatives que la société fournit à ses clients. Depuis, l'automatisation a permis à l'entreprise de gagner encore plus de temps, l'aidant à maintenir un taux de croissance annuel composé à deux chiffres.

Ces exemples montrent ce qui est possible lorsque la RPA est implémentée dans le cadre d'une stratégie orientée métier qui prend le temps d'analyser les processus et d'identifier où l'automatisation peut être la plus efficace.

Cependant, pour la moitié des organisations qui ont déployé la RPA, les résultats n'ont pas été si concluants.⁴ Soit la RPA n'a pas du tout donné le retour sur investissement prévu, soit les premières réussites n'ont pas évolué vers une optimisation continue à l'échelle de l'entreprise.

Cela peut parfois faire penser à un problème logiciel. Toutefois, dans presque tous les cas, le problème ne concerne pas tant la solution RPA que son moyen de déploiement.

En particulier, les critères peu restrictifs d'emploi de la RPA signifient qu'elle est souvent implémentée au sein d'un seul service et ce, en vue d'automatiser des tâches spécifiques chronophages pour les employés ou sources potentielles de goulots d'étranglement et d'inefficacités.

Prenons par exemple le cas d'une organisation qui reçoit des plaintes de la part de fournisseurs concernant des retards de paiement. Le temps passé à saisir manuellement les données des factures papier semble être un problème ; le service financier utilise donc la RPA pour créer un bot qui analyse les factures et saisit les détails dans le système financier SaaS.

Le bot fonctionne bien, mais les délais d'exécution du Procure-to-Pay (P2P) ne semblent pas s’améliorer. Pour finir, la personne qui a développé le bot s’en va. Personne d’autre ne sait comment le maintenir à jour, de sorte que lorsque le fournisseur SaaS met à jour le système financier, le bot tombe en panne.

Cet exemple simple met en évidence plusieurs raisons pour lesquelles les implémentations de la RPA peuvent échouer :

Seule une partie du processus a été prise en compte : les processus « procure-to-pay » et « order-to-cash » font partie des procédures les plus complexes des organisations modernes, couvrant plusieurs services et parties prenantes externes, et comprenant de longues séries de tâches interdépendantes. S'attaquer à une seule partie du processus peut apporter un certain soulagement, mais s'il existe des goulots d'étranglement ailleurs dans la procédure, l'amélioration globale peut être minime, voire inexistante. Une solution isolée appliquée à une partie du processus peut même créer de nouveaux problèmes ou goulots d'étranglement en amont ou en aval.

L'automatisation a été appliquée à un mauvais processus : ce processus impliquait des factures papier, qui pouvaient avoir été envoyées par la poste à l'organisation, triées dans la salle du courrier, transmises au contact du client, et peut-être perdues pendant un certain temps sur un bureau en désordre avant d'être physiquement transmises à la comptabilité. L'automatisation de l'extraction des données à partir de ces factures n'a guère contribué à accélérer l'ensemble du cycle P2P. L'ensemble du processus devait être repensé avant d'appliquer une quelconque automatisation.

Les indicateurs de performance clés n'étaient pas clairs : les dirigeants de l'organisation savaient qu'il y avait un problème, mais n'avaient pas réfléchi à l'amélioration qu'ils souhaitaient voir. Plutôt que de spécifier un résultat souhaité et des KPI mesurables, ils ont simplement appliqué la RPA à l'une des sources d'inefficacité les plus visibles, sans approfondir la question.En prenant du recul et en examinant l'ensemble du processus, ils auraient pu identifier toutes les inefficacités, décider de la manière de les corriger et calculer le retour sur investissement de chaque correctif avant d'agir.

L'utilisation d'outils ad hoc a rendu l'automatisation non durable : le bot a été conçu par une personne du service financier fan de technologie à l'aide d'un outil RPA low-code. Cette personne a trouvé que le logiciel était facile à utiliser, mais ses connaissances ont disparu avec elle lorsqu'elle a quitté son poste. Cela a entraîné la panne du bot, mais s'est aussi révélé être une occasion manquée de faire évoluer l'utilisation de la RPA pour lutter contre d'autres inefficacités.

La gouvernance continue faisait défaut : le bot ayant été construit et déployé de manière ad hoc plutôt que dans le cadre d'une stratégie d'automatisation, personne (et aucun système de surveillance) ne le surveillait, de sorte que personne ne pouvait prédire qu'une mise à jour du système financier allait entraîner sa panne.