Trop rigide, mal adapté à la complexité nouvelle des entreprises, le RACI doit évoluer en matrice des responsabilités.
Chez Alenia nous réalisons beaucoup de missions de conseil sur la mise en place de modèles opérationnels autour de la Production. Dans ces missions il est fondamental de bien comprendre les problèmes qu’on cherche à adresser avant tout. Puis l’étape suivante consiste à comprendre l’existant, où derrière les mêmes mots se cachent des réalités très différentes d’un client à l’autre mais également entre les périmètres d’une même société. Finalement on cherche à établir la cible et le moyen d’y arriver. Un des livrables principaux de ces missions est la rédaction d’un Target Operating Model (TOM).
Dans ce document la quasi-totalité des managers vont s’attendre à trouver un RACI et, à l’inverse, l’absence du RACI jettera un voile de discrédit sur l’intégralité de la démarche. Pour autant, ce même RACI va être un repoussoir absolu pour les équipes qui s’identifient avant tout au manifeste Agile, aux pratiques Devops, et à la notion de Craftsmanship. Nous allons tenter d’analyser pourquoi il existe des positions aussi antagonistes pour un outil qui a maintenant plus de 60 ans d’existence.
On va tout d’abord écarter ce que le RACI n’est pas, n’est plus, n’a jamais été ou pire ce qu’il prétend être mais où il produit l’effet contraire. Voici ce qui ressort à la lecture d’articles et de ChatGPT :
• Contribuer à la formation des employés
• Rendre les employés plus engagés
• Diminuer la frustration des cadres
• Gagner du temps lors des réunions
• Ne pas oublier des collaborateurs dans des échanges de courriers
• Raccourcir les délais de livraison
• Eviter de réaliser des tâches en double
• Eviter d’omettre certaines tâches
• Eviter les incompréhensions au sein de l’équipe
• Rendre les décisions prises transparentes
• Ne pas ralentir le travail avec des processus d’approbations
• S’assurer que toutes les activités sont sous contrôle
• S’assurer que vous avez une autorité en plus des responsabilités…
Si ce n’est pas pour les raisons précédemment citées pourquoi les managers recherchent et demandent systématiquement un RACI ?
C’est généralement le seul moyen connu pour s’assurer qu’on a réfléchi à l’ensemble des tâches d’un processus, d’un projet ou d’une équipe et qu’on a vérifié qu’il y avait bien des acteurs identifiés à chaque étape. Cela arrive généralement lors de la création d’un nouveau processus, d’un nouveau projet ou d’une réorganisation totale ou partielle des équipes. On le constate d’autant plus dans les grandes organisations où il est très difficile de saisir toute la complexité, ce document qui a l’ambition de capturer le tout semble donc être un outil parfait.
Parallèlement à cette vision managériale, on peut s’interroger sur la raison qui font que ces 4 lettres deviennent vite une insulte dans les oreilles des personnes se réclamant de l’Agilité ? Il y a selon moi 3 raisons principales :
La première raison est à chercher du côté du manifeste Agile:
« Les individus et leurs interactions, de préférence aux processus et aux outils.
Des solutions opérationnelles, de préférence à une documentation exhaustive.
La collaboration avec les clients, de préférence aux négociations contractuelles.
La réponse au changement, de préférence au respect d’un plan.
Précisément, même si les éléments à droite ont de la valeur, nous reconnaissons davantage de valeur dans les éléments à gauche »
Le RACI est une documentation qui décrit des processus figés et donc planifiés qui se situent souvent au sein d’un document contractuel même si celui-ci est tacite. Tout cela place le RACI dans les éléments de droites du manifeste et sont donc considérés comme moins importantes, et parfois comme devant être totalement éradiqués dans une lecture la plus extrême.
La seconde raison est que souvent Agilité est associée aux principes de squads, de feature teams de petites tailles, qui se doivent d’être autonomes, tournées vers un objectif précis, et qu’écrire un RACI est donc inutile voir dangereux car il semble imposer à chacun ce qu’il doit faire, comment le faire et en plus avant même de réellement le faire !
La dernière raison est probablement les traumatismes de beaucoup face à des RACI mal pensés, mal rédigés, et qui sont la partie visible de changements subis non désirés voir non désirables.
Tout d’abord toute personne impliquée dans la gestion de changements humains dans de grandes organisations complexes devra toujours s’assurer que ce qu’elle va mettre en place ne va pas casser l’existant. Il est fondamental qu’elle possède un outil pour l’aider à comprendre qui fait quoi, et de vérifier que la cible soit cohérente.
Ensuite les auteurs du manifeste précisent bien que « les éléments à droite ont de la valeur». Il n’est jamais question d’éviter les processus, les documents et une certaine planification quand cela apporte de la valeur.
Enfin je ne connais aucune entreprise qui puissent prétendre à avoir uniquement des petites squads autonomes, le modèle Spotify n’est qu’un modèle théorique, qui inspire et a inspiré beaucoup, à raison, mais qui rappelons-le n’a jamais été appliqué de façon aussi rigoriste par Spotify lui-même.
Dites-vous que si Spotify a une panne pendant les heures non ouvrées de la squad, on ne pourra pas attendre son retour le lendemain matin, il faudra mettre en place des astreintes pour l’intégralité des équipes à un cout élevé sur une grande organisation, qu’il faudra aussi communiquer en interne et en externe, résoudre l’incident qui concerne peut-être un élément d’infra bas niveau... Rien que dans cet exemple il semble extrêmement compliqué de faire intervenir moins de 3 équipes, et nous parlons d’une organisation déjà très bien optimisée. Plus on monte en complexité plus un document s’avère utile pour s’assurer de la cohérence d’ensemble.
Je vous partage maintenant comment on peut rédiger un « RACI » qui apporte de la valeur dans de grandes organisations tout en prenant soin de ne pas déresponsabiliser les équipes car il prétendrait capturer l’intégralité des actions qu’elles auraient le droit de réaliser:
En préambule un RACI ne résout pas les problèmes d’organisation ni de gouvernance, il peut à la limite les faire apparaitre. Par conséquent, on cherche avant tout à simplifier les processus et les gouvernances projets. Lorsqu’il s’agit d’équipes on définit leurs objectifs, leurs raisons d’être et non pas la liste de ce qu’elles doivent faire. Je ne peux que vous recommander la lecture de Turn the ship around de L . David Marquet à ce propos. Si nous prenons notre organisation chez Alenia, le domaine « Recruitment » a une mission : « Find new Alenias, and make sure each candidate experiences an optimal recruitment journey ». On ne précise ni comment ni qui doit faire le recrutement, puisque la solution d’aujourd’hui n’est sûrement pas celle de demain. La meilleure solution sera trouvée par les gens du terrain qui sont responsabilisés, ce qui signifie en tout premier lieu d’être confrontés aux conséquences de leurs actions.
Passons maintenant à la rédaction du RACI :
1. Peu de lignes, dont chacune apporte de la valeur
La création d’un nouveau processus, projet ou même une réorganisation s’inscrit toujours dans un existant et des contraintes. La ligne de crète étant de rédiger les étapes du processus (donc les lignes du tableau) pour que chacune donne un sens et éviter que cela soit trop long ou trop précis car la technologie, les outils et les processus évoluent très rapidement en IT donc on risquerait d’écrire un document périmé et/ou illisible.
2. Peu de colonnes, avec des noms d’équipes clairs
Le but du document est avant tout de s’assurer qu’on ne va rien casser à l’existant avec les changements apportés. Il faut donc préciser les équipes, mais dans une très grande entreprise il y a presque toujours au moins une réorganisation partielle en cours chaque année et des exceptions dans les rôles et responsabilités. Il est donc fondamental de trouver le bon niveau de détail de l’organisation. S’il n’est pas évident de trouver une raison d’être à une équipe, même très grosse, il faut peut-être repenser ce découpage.
3. On abandonne les lettres
Le point le plus discutable du RACI est étrangement les lettres qu’il utilise. Le fait qu’il existe des dizaines de variantes avec d’autres lettres est déjà un signe en soi.
Voici ce que le RACI exposé au début peut donner avec ces considérations. Vous noterez qu’il n’y a plus de lettres, et qu’on préférera l’appeler matrice de responsabilité.
A la lecture de cette matrice, on s’aperçoit qu’il y a de nombreux acteurs différents impliqués dans ce processus d’Incident Management. Chez Alenia nous sommes parfois appelés pour améliorer ce processus, et la création d’un rôle, dit APS, qui permet de gérer les incidents de bout en bout en étant le plus autonome possible pour un maximum de réactivité. Voici ce que peut donner la nouvelle matrice de l’Incident Management quand on créé le rôle APS.
Quoi conclure ? Défendre le RACI mais sans les R, A, C ou I est-ce que ce n’est pas défendre la raclette sans fromage ? Le RACI dans sa forme théorique semble surtout adapté à un environnement statique, avec une complexité d’organisation intermédiaire. Aujourd’hui les sociétés sont de plus en plus complexes et dans des environnements internationaux qui changent en permanence. Faut-il renoncer pour autant ? Je ne le pense pas, cette complexité croissante rend encore plus essentielle la modélisation des interactions si on prend garde à ne pas prétendre couvrir l’intégralité des actions de chaque collaborateur. C’est pour cela que chez Alenia on s’oriente davantage vers des matrices de responsabilités.
