La RPA enfin expliquée par quelqu’un qui s’y connait
La RPA ou Automatisation Robotique des Processus est très en vogue mais encore très mal compris. Dans un livre concis intitulé The Practitioner’s Guide to RPA, Jonathan Sireci nous aide à y voir clair : ce qu’est la RPA, pourquoi ce n’est pas l’IA, l’architecture de la RPA, comment identifier les cas d’utilisation de la RPA, les pièges à considérer lors de l’engagement de consultants, le paysage des fournisseurs, les modèles de facturation courants, comment sélectionner un fournisseur, comment constituer une équipe RPA, quelles considérations éthiques en découlent, sont autant que questions auxquelles il s’attache à répondre. Nous l’avons interviewé.
Bonjour Jonathan, alors pourquoi avoir écrit ce livre… maintenant ?
Jonathan Sireci : Il y a un grand fossé dans la littérature RPA entre la théorie et la pratique. Les travaux universitaires aboutissent souvent à des résumés globaux sur la RPA qui fournissent aux cadres une vue d’ensemble mais ne les aident guère à transformer les concepts en réalité. Les ouvrages de conseil sont plus détaillés, mais il existe une tension inhérente entre le désir d’un cabinet de conseil de partager ouvertement des informations et son besoin existentiel de vendre des connaissances sur la manière de rendre opérationnelles les stratégies qu’il recommande. À l’autre extrême, il existe une multitude de livres de type « how to » qui expliquent avec plus ou moins de pertinence les tactiques détaillées de la RPA. L’ironie de ces sources est que plus elles sont détaillées, plus elles sont fragiles. Fragiles dans le sens où les informations détaillées ne vieillissent pas toujours bien et ne peuvent pas être appliquées à l’ensemble des situations représentées par les lecteurs. J’ai écrit « The Project Manager’s Guide to RPA » pour tenter de partager certaines idées pratiques essentielles pour comprendre la réalité de la RPA, que j’ai glanées en menant des preuves de concepts RPA au siège de Walmart en 2015, et qui sont souvent négligées dans la littérature existante. Par exemple, j’ai assisté à une conférence où des personnes se sont vantées d’avoir » 1 000 bots » pour exécuter quelques processus métier. Lorsqu’ils ont partagé les statistiques de volume, il était clair qu’ils utilisaient la définition des bots du fournisseur et, ce faisant, avaient probablement dépensé beaucoup plus d’argent que nécessaire pour l’infrastructure RPA. Pour ceux qui n’ont pas déployé d’infrastructure RPA, cela peut sembler un détail sans importance, mais pour quelqu’un qui a construit et livré des solutions RPA dans un environnement à fort volume, cela a révélé une incompréhension fondamentale de la technologie qui coûtait de l’argent à l’entreprise du présentateur.
Un extrait de votre livre qui vous représente le mieux ?
Jonathan Sireci : En continuant avec l’idée de ce qu’est réellement un « bot » : « L’un des principaux obstacles à la compréhension de la RPA est l’idée même de « robotique ». Si vous êtes comme moi, la première chose qui me vient à l’esprit quand j’entends le mot « robotique », c’est quelque chose de métallique avec un tas de fils qui bourdonnent dans une usine de fabrication de voitures pour souder des pièces d’acier ensemble. Je pense à une Rumba, à Battlebots ou à toutes sortes de machines dotées d’une télécommande que l’on peut toucher, sentir ou écraser contre quelque chose. Pour comprendre la « robotique » dans le contexte de l’APR, il faut mettre de côté les références physiques et considérer le terme plus précis de « robotique logicielle ». Un autre nom pour la « robotique logicielle » est simplement « bots ». Le terme « bot » peut sembler plus familier à beaucoup d’entre vous et il est probable que vous l’ayez déjà entendu dans des contextes négatifs. Si vous avez entendu parler d’une attaque par déni de service (DDoS) sur un site web, ces attaques sont orchestrées par des « bots » ou des machines contrôlées de manière centralisée et exécutant un script commun leur demandant d’accéder à un site web, encore et encore. Ce contexte est à l’origine de la « robotique » (RPA) : un contrôleur central qui dirige des ressources logicielles évolutives pour exécuter un processus commun. C’est aussi la raison pour laquelle je crois qu’il y a tant de startups RPA qui ont des liens avec des organisations gouvernementales de cyberdéfense. Je ne suis plus surpris lorsque je rencontre de nouveaux fournisseurs de RPA dont les dirigeants ont un lien avec la CIA ou l’industrie de la défense. »
Les tendances qui viennent d’émerger et auxquelles vous croyez le plus ?
Jonathan Sireci : RaaS ou « Robotics as a Service » est une tendance émergente qui est là pour rester. De nombreuses entreprises commencent à adopter ce modèle, mais je citerai Qbotica, Rolabotic et Olive Ai. Au lieu d’acheter une infrastructure RPA directement auprès d’un fournisseur, pourquoi ne pas tirer parti des ressources centrales d’une équipe centralisée ? Qbotica et Rolabotic sont des entreprises plus petites mais en croissance rapide qui exploitent ce modèle. Olive Ai est très bien financée et vise spécifiquement l’automatisation des soins de santé. Pourquoi ces entreprises existent-elles ? En bref, la plupart des entreprises ne sont pas très douées pour régir l’utilisation des outils RPA une fois qu’ils sont déployés. Démontrer la valeur, prioriser les cas d’utilisation et maintenir la bonne combinaison de compétences dans les différentes unités commerciales s’avère souvent être un défi trop important. Le modèle RAAS permet de contourner une grande partie de ces difficultés en confiant l’infrastructure et la gouvernance à des personnes qui savent comment s’y prendre. Le lecteur critique notera que cela n’a rien de nouveau. En fait, le RAAS n’est rien d’autre qu’une nouvelle façon de vendre l’externalisation des processus d’entreprise. Accenture, Xerox, les six grandes sociétés de conseil et d’autres utilisent des outils similaires au RAAS depuis des décennies pour créer de la valeur par le biais de la délocalisation. La différence réside dans le modèle de coût et cette innovation est là pour rester.
Si vous deviez donner un conseil à un lecteur de cet article, quel serait-il ?
Jonathan Sireci : Parlez à des personnes qui ont effectivement mis en œuvre ou embarqué un produit RPA. Trouvez des personnes qui peuvent vous aider à comprendre la proposition de valeur, tant sur le plan technique que conceptuel. Les trois entreprises que j’ai mentionnées précédemment sont des exemples de ce qu’il faut rechercher si vous cherchez des alternatives à l’approche des grands acteurs dans ce domaine.
En un mot, quels sont les prochains sujets qui vous passionneront ?
Jonathan Sireci : Il y a beaucoup de travail à faire pour aider à rapprocher la gestion de projet et les compétences fonctionnelles en une seule discipline. Les analystes d’entreprise ne comprennent pas toujours comment un système doit être déployé, tandis que les chefs de projet peuvent être trop concentrés sur le fait de cocher des cases au lieu de réaliser la proposition de valeur. C’est un domaine que j’espère explorer à l’avenir.
Merci Jonathan Sireci
Merci beaucoup Bertrand
Le livre : The Practitioner’s Guide to RPA par Jonathan Sireci