A la recherche d’un moyen pour automatiser vos processus, vous trouvez enfin la solution ! Des paillettes plein les yeux, vous découvrez le RPA et ses bienfaits.
Chez Rhapsodies Conseil, nous aimerions vous proposer une vision raisonnée du RPA.
Pour cela, nous vous proposons d’explorer les points suivants :
Quels sont les attraits du RPA ?
Qu’est-ce que le RPA ? Comment a-t-il évolué ?
Quand l’utiliser ?
Comment sécuriser le lancement d’une initiative RPA ?
Quelles sont les étapes indispensables du cadrage d’un cas d’usage ?
Quelles sont les perspectives futures ?
Les attraits du RPA
Le RPA (Robotic Process Automation) paraît attrayant par rapport à d’autres solutions d’automatisation.
Low code / no code : les solutions proposent souvent des facilités de création de scripts low code ou no code. Celles-ci sont adaptées à des utilisateurs dont le métier n’est pas le développement,
Faibles coûts : les coûts de mise en place sont moins élevés qu’un projet de refonte d’une application,
Rapidité de mise en œuvre : le délai de mise en œuvre, de l’ordre de quelques mois, est plus rapide que pour la plupart des projets.
Sur le papier, ça a l’air parfait pour vous !
Désolée de vous décevoir mais le RPA n’est pas une solution miracle.
Commençons par le début : qu’est-ce que le RPA ?
Revenons aux basiques : le RPA c’est quoi ?
Le RPA est un logiciel d’automatisation des processus métiers (ou IT d’ailleurs). Les scripts reproduisent l’interaction d’un humain avec les IHM des applications.
Le RPA est utilisé sur des processus stables basés sur des données structurées. Et dont le volume est important.
L’idée était de débarrasser les utilisateurs des tâches répétitives et à faible valeur ajoutée. Fini les tâches où nous reproduisons toujours les mêmes clics jusqu’à en devenir fou. Et dont la répétition favorise le risque d’erreur à la longue.
Voici quelques exemples de cas d’usage sur lesquels le RPA peut être utilisé :
vérifier des documents avant de les envoyer à un client,
activer le prélèvement automatique une fois le mandat signé,
mettre à jour des données client…
Le RPA peut être utilisé sur tous types de processus et dans tous les secteurs d’activité.
Vous vous demandez sûrement pourquoi il n’a pas envahi le marché tout de suite ? À cause de ses modalités d’intégration.
Vers davantage de modalités d’intégration
La première limite du RPA était évidemment la fréquence d’évolution du processus métier et des IHM. Par exemple, le bouton “valider” change de place et votre robot est bon pour la casse.
C’est le cas avec les applications maison qui évoluent fréquemment pour répondre à la demande des métiers. Ou les applications SaaS dont la roadmap éditeur n’est pas maîtrisée.
Le RPA a donc évolué pour dépasser cette limite. Les éditeurs se sont mis à proposer de nouvelles capacités d’intégration.
Deux nouvelles capacités ont vu le jour :
intégration grâce des API,
mise à disposition de connecteurs par les éditeurs.
Ces capacités d’intégration sont bien entendu complémentaires avec l’intégration par les IHM. Elles peuvent être utilisées par le même robot.
Cela permet d’étendre le périmètre d’intervention du RPA à de nouveaux processus. Il n’est plus limité à des processus manuels basés sur des applications dont les IHM évoluent peu.
Maintenant que cette limite originelle est dépassée, qu’est-ce qui freine pour l’adopter ? Il reste nécessaire de bien choisir les cas d’usage sur lesquels appliquer du RPA.
Dans quels cas l’utilisation du RPA est-elle pertinente ?
Le RPA est particulièrement pertinent pour :
– des applications qui sont arrivées à maturité, évoluent peu et dont l’intégration avec le Système d’Information ne pourra pas prendre en charge les automatisations souhaitées,
– des petites migrations de données entre deux applications par exemple.
Vos premiers cas d’usage sélectionnés et priorisés, vous trépignez d’impatience !
Pas si vite, nous vous invitons d’abord à prêter attention aux points suivants.
Comment sécuriser le lancement d’une initiative RPA ?
Nous avons relevé trois points d’attention majeurs à considérer :
Réduction des coûts en passant à l’échelle : les coûts du RPA se réduisent lors du passage à l’échelle. C’est-à-dire quand plein de petits robots travaillent de concert au service de votre entreprise. Certes, les premiers cas d’usage sont faciles à trouver. Mais le potentiel n’est pas illimité. En particulier le nombre de cas d’usage avec un fort ROI.
Scalabilité en cas d’évolution de la volumétrie : il faut prendre en compte les évolutions de la volumétrie. Cela permet de dimensionner correctement les robots. La scalabilité verticale est clé dans le cas de processus saisonniers. Sinon, il faudra ajouter d’autres robots pour le même processus. Et cela a un impact non négligeable sur le ROI.
Confidentialité des données : quel niveau de confidentialité en fonction des données manipulées ? Cela conditionne le choix d’hébergement du RPA. En effet, de nombreux éditeurs proposent désormais des solutions Cloud.
Ces points d’attention considérés, foncez sur votre premier cas d’usage ! Nous avons encore quelques conseils dans notre manche, rassurez-vous.
Les étapes indispensables lors du cadrage d’un cas d’usage
De notre point de vue d’architecte (et expert en transformation digitale), plusieurs sujets sont à étudier :
Décrire le processus : pour mettre en place du RPA, le processus doit être décrit finement. Cette description est appelée “pas à pas”. Celle-ci peut être obtenue en documentant le processus. Ou avec l’aide d’un outil de task mining, aussi appelé process discovery. C’est-à-dire l’enregistrement des tâches d’un utilisateur sur son poste de travail. Le task mining est basé sur de l’OCR (Optical Character Recognition), du traitement du langage naturel et du machine learning.
Optimiser le processus : un projet d’automatisation est une opportunité de revoir en profondeur le processus. L’étape dont l’automatisation coûte le moins est celle qu’on supprime.
Ecosystème applicatif : l’identification de l’environnement applicatif du RPA est également crucial. Avec quelles applications doit-il s’interfacer ? Comment peut-il s’interfacer avec chacune d’entre elles ?
Comparer différents scénarios : il faut comparer le RPA à d’autres solutions d’automatisation. Par exemple les plateformes d’intégration industrielles déjà présentes dans votre entreprise. Parfois une bonne vieille API fait très correctement le travail. Elle peut coûter moins cher qu’une démarche RPA. Surtout s’il y a une brique d’API management dans l’entreprise. Et que les équipes sont habituées à manipuler des API. Le RPA, malgré la possibilité d’appeler des API, ne remplace pas une plateforme d’intégration industrielle.
Définir les responsabilités pour le RUN : l’équipe gérant le RUN des robots est souvent celle qui les a mis en place. Il est crucial qu’elle soit au courant quand les applications impliquées évoluent. Et qu’elle puisse faire évoluer les robots en fonction. Sinon, les robots ne fonctionnent plus et elle ne sait pas pourquoi. Elle doit donc être en lien avec les autres équipes au quotidien.
Voilà, vous savez tout ! Le RPA est une solution d’automatisation frugale des processus. Vous l’avez compris, c’est une solution et non une fin en soi.
Cette solution est adaptée si l’entreprise ne dispose pas de plateformes d’intermédiation industrielles. Et qu’il n’y a pas d’autres possibilités d’automatisation au vu des applications concernées. Comme nous l’avons vu, les cas d’usage doivent être rigoureusement sélectionnés et priorisés.
Avant de filer, nous avons un dernier sujet à explorer. L’IA qui révolutionne le marché de l’IT, ne peut-elle pas aider le RPA ? Si, bien sûr, et nous allons voir comment.
Quelles perspectives pour le futur ?
Le RPA bénéficie des apports de l’IA. Il peut interagir avec d’autres technologies, par exemple :
Intelligent Document Processing,
Task mining,
Traitement du langage naturel,
Vision par ordinateur.
On parle dans ce cas d’hyper automatisation. La promesse est la suivante : automatiser des processus moins structurés que ceux concernés par le RPA “classique”.
Cet ensemble de solutions propose des fonctionnalités intéressantes. Cela va permettre d’étendre le périmètre d’intervention du RPA.
D’après le Gartner, d’ici 2025, 90% des éditeurs de RPA proposeront de l’automatisation assistée par de l’IA générative.
En revanche, la mise en place d’une plateforme d’hyper automatisation va clairement au-delà d’un projet classique de RPA. A la fois en termes de coûts et de compétences.
Vous commencez à nous connaître, nous vous conseillons d’en faire une utilisation… Raisonnée.
Quoi de nouveau dans la version 6 de SAFe pour l’architecte solution?
Quoi de nouveau dans la version 6 de SAFe pour l’architecte solution?
25 juillet 2023
– 4 minutes de lecture
Architecture
Thomas Jardinet
Manager Architecture
Salomé Culis
Consultante Architecture
Cet article est le deuxième d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version du framework SAFe.
Après avoir étudié le System Architect, nous allons donc voir en détail les différences pour le Solution Architect avec la précédente version de SAFe.
Une position de “pivot” de l’architecture
Le Solution Architect, positionné entre l’Entreprise Architect et le System Architect, a cela de de particulier qu’il est un réel pivot d’architecture :
De l’Entreprise Architect, il doit prendre en considération les directions stratégiques de l’entreprise.
Du System Architect, il doit prendre en compte les remontées “terrain” des Trains Safe.
Il n’est pas pour autant un simple passe-plat, et encore moins une boîte mail générique, mais un acteur qui doit insuffler une direction technologique à l’ensemble du SI.
Il définit ainsi une vision technique, qu’il définit, cadre, met en place et partage. C’est par exemple à lui d’identifier les futures technologies à mettre en place, et à les instancier en les industrialisant.
Mais revenons un peu à ce rôle de pivot. Il est en effet extrêmement marquant pour moi de voir une citation du livre de Donella H. Meadows “Thinking in Systems”:
“You think that because you understand ‘one’ that you must therefore understand ‘two’ because one and one make two. But you forget that you must also understand ‘and.’ “
Cela ne vous parle peut-être pas, mais cette phrase est une très bonne synthèse (certes très raccourcie) de la théorie des Systèmes développée par l’autrice et son mari. Pensée systémique qui influença l’émergence de l’agilité, en expliquant que la complexité des systèmes se mesure dans le nombre d’acteurs et de leurs interactions.
Théorie des systèmes qui m’est personnellement très chère, considérant à titre personnel comme faisant partie de ma liste de livres à lire absolument. Cette théorie apporte en effet une grille de lecture très intéressante de l’environnement qui nous entoure, en cela qu’elle explique que nous sommes tous liés à ce qui nous entoure, et que nous réagissons par rapport à ce qui nous entoure. N’ayant pas toute la sagacité de ses penseurs, je vous laisserais creuser vous-même cette théorie qui inspire fortement entre autres les travaux du GIEC.
Et cerise sur le gâteau pour moi, certe déjà présente dans la version 5 du framework Safe, nous retrouvons l’idée de “démarche inverse de Conway”, qui consiste à calquer l’organisation sur l’architecture souhaitée, et non l’inverse. Démarche qui ferait de l’Architecte Solution un Architecte d’Entreprise qui s’ignore? Néanmoins, on retiendra que cette démarche inverse de conway fonctionne de manière plus fluide dans une organisation réellement agile et se voulant fluide, comme le recherche le framework Safe.
Et comme cette position d’architecte pivot de solution mais aussi de l’organisation ne provient pas non plus de nulle part, nous allons nous entâcher d’abord à réexpliciter son rôle.
Les responsabilités clés de l’architecte solution
Si nous devions chercher à être synthétique, nous pourrions dire que l’architecte solution est l’architecte “support” de l’Entreprise Architect en définissant avec lui la roadmap solution.
Roadmap solution qui est aussi défini en support avec le System Architect, mais lui en apportant des facilitations, des enablers, et le déchargeant des contingences techniques transverses.
Ainsi les différentes responsabilités du Solution Architect sont les suivantes :
Implementing Lean Systems Engineering :
Mise en place non seulement d’une démarche Devops, transverse aux différents projets, en définissant une architecture toujours prête à évoluer (le fameux Design to Change).
Establishing Solution Intent and Context :
Nouveauté par rapport à la version 5 du framework Safe. Cela consiste d’une certaine manière à un travail de cadrage et de veille. Quelles technologies pour quels nouveaux besoins métier? Et inversement quelles technologies peuvent créer quels besoins métier? Il définit également les différents besoins non fonctionnels et les besoins en termes de respect de la réglementation, mais aussi les “intentions” d’architecture, qui représentent la vision d’architecture souhaitée.
Defining and Communicating Architecture Vision :
Définition de la roadmap solution et de la vision d’architecture, participation aux pré pi-planning et pi-planning, gestion de la charge de ses sujets. Evidemment avec toutes les parties prenantes de l’architecture…
Evolving Solution Architecture with ARTs and Suppliers :
Qu’on pourrait résumer par “support aux développeurs et fournisseurs”, que ce soit sur les aspects d’exploration et d’expérimentation, de modélisation, de revue d’incrément, mais aussi bien évidemment de support à la définition de l’architecture du System avec le System Architect.
Fostering Built-in Quality and the Continuous Delivery Pipeline :
Qui représente la pleine partie DevOps de son travail.. Du développement jusqu’aux infrastructures, en passant par les tests, et bien évidemment la définition de la chaîne CI/CD.
Evolving Live Solutions :
C’est là une nouveauté par rapport à la version 5 du framework Safe. Cela consiste à dire que le Solution Architect doit continuer à suivre la solution passé la mise en production, en s’assurant du respect des besoins non fonctionnels, des contraintes réglementaires, mais aussi de son adaptabilité à de futurs besoins.
Les nouvelles relations du Solution Architect
Le rôle du Solution Architect dans la version 5 était peut-être réductrice. En effet il était auparavant quasiment aggloméré avec les architectes systèmes (vision assez réductrice à mes yeux, comme si un architecte solution ou un architecte system était la même chose). Il n’avait ainsi que des échanges avec l’équipe de Solution Management.
De cette modélisation bi-latérale du rôle du solution architect, la version 6 du framework Safe jette cela par la fenêtre pour le remplacer par un rôle de pivot de 4 équipes distinctes :
L’architecte d’entreprise qui apparaît dans la version 6, pour aligner ensemble l’architecture d’entreprise.
Le STE et les équipes de Solution Management pour piloter les trains de solution, comme précédemment.
Les systems architectes qui sont enfin distingués du “magma d’architectes” pour faire évoluer l’architecture solution.
Et enfin les équipes systèmes (pour faire simple les DevOps) apparaissent elles aussi, qui après tout sont ceux qui instancient l’architecture de solution.
,
Le tout bien évidemment dans une logique de collaboration, et non d’une simple logique purement top-down ou bottom-up.
Si ces sujets vous intéressent…
Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.
Les articles 1 et 2 peuvent en particulier se révéler utiles :
Article 1 : c’est quoi l’Agilité ? Cet article introduit notamment l’agilité à l’échelle et le framework SAFe. Des ateliers favorisant la co-construction de l’architecture sont également évoqués et pourraient se révéler très utiles pour faire participer les différentes parties prenantes avec lesquelles l’architecte collabore. https://www.rhapsodiesconseil.fr/architecture-dentreprise-et-agilite-chapitre-1-cest-quoi-lagilite/
Dans l’article 2, intitulé “ Détournement de valeur(s) en cours.”, nous avions évoqué dans le paragraphe “Les architectes font des plannings sur 5 ans qui sont irréalisables” le besoin de travailler sur des visions à plus court terme, et qui soient réalistes, conformément aux besoins de roadmap technologique des architectes solutions. https://www.rhapsodiesconseil.fr/articles/architecture-et-agilite-chapitre-2-detournement-de-valeurs-en-cours
Et évidemment, je ne peux que vous conseiller la lecture du livre mis en référence par le framework safe 6
Cet article est le premier d’une série présentant les évolutions des rôles des différents architectes dans la nouvelle version du framework SAFe.
Nous allons donc voir en détail les différences pour le System Architect, en particulier sur les sujets d’interactions avec les autres parties prenantes et les responsabilités du System Architect.
Changement de nom pour un nouvel architecte
Un premier point qu’il est important de souligner est le changement de nom de cet acteur lors du passage à la version 6 du framework. Celui-ci passe de “System Architect / Engineering” à “System Architect”, tout simplement.
Cela permet d’éviter une éventuelle confusion avec le Release Train Engineer ou même avec certains concepteurs fonctionnels qui sont plus proches d’un rôle de PO.
Mais ce changement de nom cache un changement beaucoup plus profond du rôle et de la posture de l’architecte système.
La compétence clé de l’architecte système, la collaboration
Dans cette nouvelle version du framework, la notion de collaboration est mise en exergue comme une compétence clé de l’architecte.
En effet, l’architecte système collabore avec différents groupes de parties prenantes :
Le PM et le RTE pour orienter les travaux du Train et contribuer au développement de la vision,
L’architecte solution et l’architecte d’entreprise afin de construire une architecture cohérente aux différents niveaux du framework et de l’entreprise,
Les équipes agiles pour les accompagner dans la mise en place de l’architecture,
D’autres équipes telles que la System Team ou des équipes Shared Services, notamment pour mettre en place des processus d’intégration et de tests automatisés.
Ainsi, l’architecte système doit être capable de travailler avec des acteurs très variés, de les aider à remplir leur rôle et de partager sa vision de l’architecture afin que le Train avance dans la bonne direction.
Nous voyons ici apparaître une notion de base de l’agilité, présente dans le manifeste agile (que vous avez tous sur votre table de nuit ou encadré au-dessus de votre bureau, j’en suis certaine !).
Cette nouvelle version du framework positionne très clairement l’architecte système comme un acteur qui sort de la tour de verre de l’architecture et va s’intégrer au quotidien dans les équipes.
La proximité favorise la collaboration
A titre personnel, en tant qu’architecte sur un programme de refonte de la relation client, j’avais fait le choix d’aller m’installer dans l’open space avec les équipes agiles. Cela permettait de :
Faciliter la collaboration avec elles,
D’être plus facilement impliquée dans des échanges avec le Programme Management et de mieux connaître les priorités pour pouvoir concentrer mes efforts sur les bons sujets,
D’avoir un vrai lien avec les équipes et qu’elles n’hésitent pas à venir me voir pour échanger sur l’architecture.
Au-delà des aspects cités précédemment, je me suis ainsi sentie comme faisant partie du projet à part entière. Je m’étais bien sûr assurée de garder une proximité forte avec mes collègues architectes (nécessaire pour s’aligner aux différents niveaux si vous avez bien suivi !).
Les responsabilités clés de l’architecte système
Vous vous dites peut-être que l’architecte système échange avec beaucoup d’acteurs. Et vous vous demandez peut-être en quoi consiste véritablement son rôle.
En effet, son rôle évolue pour assumer les responsabilités ci-dessous :
Aligner l’architecture avec les priorités Business (grâce à ses échanges avec le PM et les autres architectes),
Définir et communiquer la Vision d’Architecture (notamment auprès des équipes agiles),
Faire évoluer le système avec les équipes,
Favoriser la qualité au fur et à mesure de la construction du système et permettre la mise en place des NFRs (ou exigences non fonctionnelles). L’architecte s’assure qu’ils soient pris en compte dans le backlog et accompagne leur développement par les équipes,
Permettre la mise en place du DevOps et du Continuous Delivery Pipeline (par la collaboration avec la System Team par exemple).
Les deux derniers points notamment impliquent un véritable changement d’état d’esprit. Le travail de l’architecte ne s’arrête pas au moment de la présentation de la Vision d’Architecture, il doit continuer à accompagner le Train opérationnellement au quotidien pour pouvoir remplir l’ensemble de ces responsabilités.
Auparavant définies sous la forme d’une liste à la prévert, les tâches du System Architect deviennent à présent un nombre limité de responsabilités clés.
C’est un vrai shift pour la position de System Architect.
D’un architecte système qui s’assoit sur les “fauteuils pré-positionnés” par ceux qui ont défini le cadre de gouvernance SAFe, nous passons à un vrai acteur et “modeleur” de l’itération locale du framework SAFe.
Il n’est pas cantonné à des tâches définies de manière top-down, mais devient un acteur/décideur/influenceur du système.
Si ces sujets vous intéressent…
Pour plus d’informations sur ces sujets et sur le rôle d’architecte dans un environnement agile, n’hésitez pas à aller voir notre série d’articles sur l’architecture et l’agilité.
Les articles 1 et 4 peuvent en particulier se révéler utiles :
Article 1 : c’est quoi l’Agilité ? Cet article introduit notamment l’agilité à l’échelle et le framework SAFe. Des ateliers favorisant la co-construction de l’architecture sont également évoqués et pourront se révéler très utiles pour faire participer les différentes parties prenantes avec lesquelles l’architecte collabore.
Dans l’article 4, intitulé “Comment les architectes peuvent interagir avec l’agilité ?”, nous avions évoqué le fait d’aller vers des modes de travail plus collaboratifs et d’être véritablement partie prenante de la transformation de l’entreprise.
