RPA : de l’opportunisme technologique vers une facilité organisée
Après des années d’une liberté technologique inédite, la montée en puissance des sujets de gouvernance semble indiquer l’atteinte d’un point d’équilibre entre les ninjas du Digital, les samouraïs de l’IT, et l’autonomie grandissante des métiers avec la technologie. Le sujet de la gouvernance RPA, comme celui de la gouvernance des API, devient central.
Dès son lancement, le RPA a bénéficié de la bouffée d’air qu’il représentait : des projets courts, simples, menés en séquence par des collaborateurs ou des consultants pas forcément très techniques, et des résultats immédiats. Cette liberté a pourtant un prix, et des effets de bords sont rapidement apparus.
Un exemple : lorsque les processus métier sont robotisés via les interfaces graphiques, on comprend aisément qu’une modification de cette interface peut impacter le fonctionnement du robot. Cela peut se produire lors de la livraison d’une nouvelle version d’une application, comme, par exemple, dans le cas d’une application SaaS, dont les mises à jour peuvent être fréquentes et imprévisibles, entraînant le non-fonctionnement du robot.
Rapprocher le cycle de vie des applications de celui des processus RPA est un élément-clé de la gouvernance à mettre en place. Cela nécessite des procédures ad hoc et un suivi précis du plan de livraison des applicatifs, sans quoi les surprises peuvent être de taille.
En effet, le déploiement de processus RPA s’apparente encore parfois un peu trop à du shadow IT, via une automatisation de surface qui n’a que peu d’adhérence avec le système d’information et peut aller jusqu’à en compliquer la gouvernance. Nombreux sont les processus qui simulent directement le travail d’un utilisateur et omet de passer par les connecteurs et les API.
Un autre élément de la gouvernance RPA est ainsi de déterminer quand le travail de surface est la meilleure alternative à un travail en profondeur via les services prévus à cet effet. On rappellera que, pour beaucoup, le RPA est bien davantage de l’intégration que de l’intelligence artificielle et qu’à ce titre, les architectes devraient être consultés dans son application, ce qui est encore loin d’être le cas.
Dans le cas contraire, les bénéfices métier peuvent être compensés par des coûts IT induits difficiles à estimer, au détriment de la DSI et de son image, sans qu’elle en soit pourtant directement responsable. Ce point est d’autant plus difficile à défendre que les bénéfices métier sont importants et le retour sur investissement rapide.
Ce faisant, le sujet de la visibilité donnée aux projets RPA et de leur priorisation devient un point d’équilibre entre métier et IT. Et de facto les coûts sont là : développement, maintenance, opérations, formation… rien d’exceptionnel en l’occurrence, mais le RPA ne déroge pas à la règle.
Ainsi, et d’une manière générale, l’objet de la gouvernance RPA est de rechercher un équilibre qui soit un optimum acceptable par l’ensemble des parties.
La gouvernance du RPA : les règles pour un optimum
1) Une uniformisation des études d’opportunité RPA
• Challenger le RPA versus l’intégration middleware orchestrée (et intégralement pilotée par le SI)
• Fournir un cadre homogène aux études ROI (alignement des hypothèses et abaques de chiffrage)
2) Une massification des robots
• Identifier et documenter en central les dépendances en amont et en aval des activités robotisées
– définir les rôles et responsabilités de chaque partie prenante des processus robotisés
• Etudier la massification des robots en production (internalisée ou externalisé)
– limiter le nombre d’organisations en charge de leur MCO
– limiter le nombre de solutions (éditeurs et versions) pour limiter la complexité de maintenance
– bénéficier d’un effet économique d’échelle (négociation sur les runtime des robots)
– uniformiser les KPIs et SLAs
• Cadrer l’externalisation des robots en production
– définir un modèle de partage des gains avec le partenaire
– définir un cadre contractuel standard encadrant sans ambiguïté le partage des gains (en tenant compte des adhérences sur toute la chaîne de valeur)
– mesurer les écarts entre gains théoriques et réels, ajustement en conséquence des abaques
– vérifier en interne le maintien en qualité des opérations à robotisation externalisée
• Cadrer l’internalisation des robots en production
– définir une autorité RPA qui pilotera les demandes et la production
– proposer un cadre outillé pour les déploiements internes (environnements, base de connaissance, règles d’architecture, …) + gouvernance technique
3) Une vision centrée sur l’humain
La gouvernance du RPA doit intégrer une vision centrée sur l’humain. En effet, l’impact humain de la robotisation sur les activités humaines peut être potentiellement important, et peut embarquer des risques de résistance aux changements ou de démobilisation significatifs. Par ailleurs, la robotisation provoque généralement la suppression des activités nécessitant le moins de qualifications. Ce constat est le même dans le monde industriel.
Le volet humain de la gouvernance du RPA doit donc s’inscrire dans une réflexion plus globale sur la robotisation des activités et ses impacts. L’intégration des coûts de requalification des ressources robotisées est l’un des enjeux les plus importants sur le plan éthique auxquels doit répondre la gouvernance du RPA.
