Automatisation : LCL met en marche 30 robots sur son back office
La banque a fait le choix d’UiPath pour se lancer l’automatisation de processus (RPA). Une démarche lancée en 2016 qui se déploie rapidement dans les multiples caisses de la banque.
Tout commence fin 2015 : la banque océanienne ANZ Bank annonce avoir déployé avec succès une centaine de robots logiciels sur ses processus et annonce en déployer 100 supplémentaires en 2016. Pour Stéphane Lebrument, directeur métier adjoint de LCL, cela constitue un point de départ, suffisamment pour que le spécialiste s’intéresse sérieusement au RPA (Robotic Process Automation). Début 2016, il s’intéresse donc aux logiciels du marché, à commencer par les solutions les plus fréquemment évoquées par les analyses : les plateformes d‘UiPath, Blue Prism (l’inventeur de la terminologie RPA) et Automation Anywhere qui avait été choisi par ANZ.
« UiPath s’est alors démarqué de ses concurrents car on peut télécharger leur solution pour l’essayer. Des vidéos sont en ligne pour comprendre l’utilisation basique du produit, jusqu’à une utilisation très avancée. Il est possible de se former seul sur le produit », justifie-t-il, ajoutant que l’éditeur dispose également d’une grille tarifaire transparente. « Ils donnent des prix, ce qui permet de faire une estimation fine du coût réel. » Cette approche permet à Stéphane Lebrument d’évaluer la solution de l’éditeur roumain sur un processus. Celui-ci récupère des informations dans le SI legacy de LCL, traite des documents bureautiques et envoie des emails. « Nous avons pu vérifier que le processus était effectivement automatisable et ce que l’on pouvait attendre de cette automatisation. Le résultat fut que le robot s’est montré 4,7 fois plus rapide que moi. » Une collaboratrice de Stéphane Lebrument est alors chargée d’analyser les 800 processus de back office de LCL. « Nous avons estimé ce que nous pouvions automatiser et quel taux d’automatisation global nous pouvions espérer. Nous avons obtenu la valeur de 9,8% ».
Une première expérimentation sur les données réelles
Suite à cette première évaluation, le projet d’une expérimentation plus large est présenté à la direction. « Je n’ai pas souhaité faire de PoC, explique Stéphane Lebrument. Je connaissais l’outil et je voulais aller jusqu’au bout de la démarche et aller en production. Une expérimentation permettait de gérer le dialogue social, afin d’avoir l’avis des représentants du personnel avant de passer à l’étape de généralisation. »
Pour cette expérimentation, plutôt que de choisir des activités où il sera possible d’obtenir les gains les plus importants, Stéphane Lebrument préfère choisir 6 activités sur des périmètres différents. Il sélectionne plusieurs applications, avec des niveaux de complexité et de criticité bancaire différents. « Cette approche nous permettait de positionner les curseurs d’éligibilité, le ROI et de mesurer l’impact auprès des collaborateurs et de l’organisation globale. Choisir des processus qui avaient parfois peu de chance d’être automatisés nous permettait de bien identifier ce que l’on peut prendre et ce que l’on ne peut pas inclure dans le RPA. »
L’expérimentation est alors lancée sur ces 6 activités. A l’issue de l’expérimentation, 5 des 6 activités sont généralisées. « L’activité liée aux crédits professionnels a certes pu être automatisée mais n’offrait pas un ROI suffisant pour pouvoir être généralisée, notamment lorsqu’on doit demander aux collaborateurs de réaliser des tâches supplémentaires pour alimenter le robot en données. Le gain est nul, donc cela ne vaut pas la peine d’être automatisé », explique-t-il.
Une cellule RPA est mise en place à l’issue de l’expérimentation
A l’issue de l’expérimentation, une cellule RPA est mise en place avec le concours des équipes IT de LCL. Le RPA passe alors au stade industriel, avec de nouvelles activités automatisées tous les 4 mois. Fin 2018, une cinquantaine d’activités seront automatisées uniquement au niveau des back-offices de la banque. Le périmètre a été étendu à d’autres directions, dont son activité conformité. L’empreinte du RPA n’aura de cesse de s’étendre chez LCL au-delà du seul back office.
Une grille d’inégibilité est mise en place pour filtrer les activités, puis celles-ci sont évaluées via une matrice qui pondère l’activité sur plusieurs critères. Le responsable souligne le rôle clé du métier dans ce projet de déploiement RPA : « Nous avions un sponsor dans chaque direction métier. Leur vocation est de faire le liant avec les équipes opérationnelles. Nous travaillons en mode semi-agile et pluridisciplinaire. Une cellule RPA est constituée de binômes, avec un analyste et un designer. L’analyste doit comprendre comment l’activité est traitée, doit imaginer l’activité avec le robot et le designer doit apprendre au robot à traiter l’opération au moyen du Studio UiPath ».
La méthodologie mise en place par LCL comprend un volet relationnel : quand l’analyste échange avec le collaborateur sur son métier, le rendez-vous est systématiquement filmé afin de rien laisser échapper au moment de la conception du robot. « Les collaborateurs sont bien souvent moteurs dans les changements des processus et beaucoup moins ceux que l’on considère comme les experts métier. Les opérationnels proposent les activités suivantes à automatiser. Ils sont stressés au début quand ils ne connaissent pas le RPA, mais ils comprennent que cela porte finalement sur les travaux les moins intéressants, ce qui est bien souvent en deçà de leur niveau de compétences. »
Pour Stéphane Lebrument, il ne faut jamais chercher à modéliser 100% d’une activité au moyen du RPA : « C’est une erreur que l’on fait fréquemment. Il faut identifier le cas général, celui qui, pour une complexité minimale, va apporter un gain maximal. Les cas plus pointus sont laissés aux collaborateurs, les cas généraux aux robots. » Par exemple, le RPA va automatiser le processus d’ouverture de compte pour le cas le plus général, c'est-à-dire les célibataires ou les gens mariés, mais il va aiguillier les autres cas vers les collaborateurs humains.
Des robots testés sur les bases de production
De manière assez unique, les robots modélisés par l’UiPath Studio sont testés par l’expert métier directement sur les données de production. « Nous avons mené une grande partie de nos tests en production car le RPA est multi-applications par construction. Pour tester de bout en bout un modèle, il faut des environnements de tests qui soient capables de reproduire l’ensemble de ces environnements, avec des comportements identiques à ceux de la production. Il faut que les écrans et les données soient identiques à celles de la production, car on apprend au robot sur cet environnement », rappelle le spécialiste.
De même, il faut alimenter le robot en données cohérentes pour traiter l’ensemble des cas. Dans une approche agile où de nouveaux robots sont livrés tous les 4 mois, mettre en place un environnement de test 100% représentatif de ce que trouvera ensuite le robot dans le SI, demande beaucoup trop de temps, assure le spécialiste. La solution trouvée par l’équipe RPA du LCL consiste ainsi à former et habiliter l’analyste qui a travaillé sur la modélisation du processus. De cette manière, celui-ci va valider manuellement les données générées par le robot dans les bases de production en plaçant des points d’arrêt aux endroits où le robot va écrire ses données.
Autre difficulté, le LCL a dû faire face aux évolutions des interfaces utilisateurs des différentes applications utilisées par ses robots : « le RPA utilise des interfaces comme le ferait un collaborateur, explique Stéphane Lebrument. Quand une interface évolue, cela perturbe le robot. Prévenir l’ensemble des chefs de projets qu’un robot utilise leur application et que, à chaque modification, ils doivent prévenir la cellule RPA ne fonctionne pas. Le plus simple était de mettre en place un méta-robot qui vérifie dans les environnements de recette si des applications font l’objet d’une nouvelle livraison. » De même qu’un robot, baptisé R2D2, est chargé de gérer l’ensemble des mots de passe utilisés par les robots.
Des robots qui remplacent… les stagiaires vacances
Si la robotisation des tâches fait couler beaucoup d’encre en termes de destruction d’emploi, Stéphane Lebrument voit les choses autrement : « Les opérations confiées au RPA sont des activités mécaniques, répétitives, sans valeur ajoutée. Ce sont celles que l’on confie souvent aux auxiliaires de vacances, des collaborateurs qui n’ont pas, a priori, de connaissances bancaires et qui traitent des volumes d’opérations en suivant des règles sur lesquelles ils ont été formés. Chaque fois que vous embauchez des stagiaires pour traiter des opérations pendant les vacances, ce sont très probablement des activités éligibles au RPA », confie-t-il.
De l’expérience de LCL, il ressort que le RPA augmente la qualité des processus en éliminant l’erreur humaine, augmente le niveau d’auditabilité et la conformité de ces processus. Cette automatisation permet de créer de nouveaux services conçus comme un assemblage d’outils existants. I étaient impossibles de mettre en place ces services, faute de compétences.
Selon des chiffres collectés par Stéphane Lebrument, 10% de la charge de travail globale de LCL pourrait être confiée à des robots. Le directeur métier adjoint ajoute : « nous pouvons automatiser une activité éligible au RPA à 45%. Cela se déploie en 2 à 4 mois, pour un ROI inférieur à 1 an. Ce sont les données collectées après avoir déployé 30 robots sur 17 activités, ce qui a représenté un gain en temps de travail de 35 ETP (Equivalent temps plein) ».
