Élimination des frictions, simplification, flexibilité, adaptabilité, amélioration continue

17-01-2024 08:56:02

Le texte qui suit est temporaire

De manière simpliste, éliminer les frictions revient à huiler les mécanismes de fonctionnement, à éliminer ce qui n'a que très peu de valeur ajoutée, voire pas du tout, ce qui dénature l'information ou en ralentit les flux, ralentit les décisions, les actions. Il s'agit aussi de laisser les décisions se prendre là où elles doivent se prendre et de débrayer les excès hiérarchiques. Il s'agit enfin de faire évoluer les processus autant que les produits et services dans l'optique systématique de la création de valeur.

C'est un bon principe structurel que d'avoir le moins de couches, c'est-à- dire d'avoir une organisation aussi "plate" que possible - ne serait-ce que parce que, comme le dit la théorie de l'information, "chaque relais double le bruit et coupe le message en deux". — Peter Drucker in Management Challenges for the 21^st Century — 1999

Il n'existe pas de champ spécifique réservé à l'élimination des frictions et de son cortège de mesures amies : tous les champs où les femmes et les hommes de l'organisation s'activent sont propices à cet élan massif de simplification et d'optimisation.

Les 8 mudas de Lean nous aident à proposer des pistes d'améliorations en éliminant 8 gâchis habituels. Bien entendu, cette grille de rappel peut nous porter à proposer de véritables innovations mais il s'agit plus d'un état d'esprit, une culture, que d'actions ponctuelles.

L'amélioration continue (kaizen) est une autre de ces armes qui permet d'éliminer les frictions.

À titre d'exemple personnel j'aimerais décrire plusieurs situations que j'ai rencontrées dans ma mission de Transformation Manager auprès d'un syndicat et pour lesquelles je me suis mis en devoir d'éliminer les frictions.

Cas

Cas 1 : Waiting Time dans un projet "my"

Pour un projet "my" — mySyndicat pourrait-on dire — j'ai été mis face à face avec un setup d'équipe pour le moins particulier.

Ce projet "my" avait démarré 2 ans plus tôt, fin 2017, sous la houlette d'un chef de projet qui quittait le syndicat quand le nouveau CIO m'a confié la mission de finaliser le projet et de le mettre le plus rapidement possible en production. Nous étions au mois de mai 2019, le chef de projet s'en allant le 6 juin 2019 avec la promesse que ce projet serait terminé pour son départ.

Malgré tous ses efforts et les miens pour aider l'équipe à finaliser ledit projet, nous nous rendions compte que le progrès escompté ne se matérialisait pas.

Après 15 jours d'observation attentive, je me suis rendu compte qu'on faisait face à plusieurs mudas typiques : defects, movements, et waiting-time, ce dernier étant de loin le plus problématique.

Ce qui se passait était simple dans sa dynamique : le projet était confié en termes de sourcing à une entreprise externe qui assignait ses ressources au projet en fonction de leur charge de travail estimée. 2 à 3 jours pour Pierre, 1 jour pour André, 2 jours pour Daniel, 3 jours pour Antoine, un second chef de projet qui coordonnait les mises à jour dans Jira. Cependant, peu de jours étaient communs. On arrivait alors dans des situations parfaitement kafkaïennes telles que Pierre programmait une fonctionnalité le mardi, fonctionnalité qui devait être étendue par André qui ne venait que le lundi, puis finalisée par Daniel qui se présentait les jeudi et vendredi. Si un bug survenait à quelqu'endroit de la chaîne, il n'était pas rare de devoir attendre 15 jours pour que la fonctionnalité puisse enfin être implémentée. Quand je demandais à chaque intervenant combien de temps cela lui avait pris, il était fréquent qu'on me dise "Oh, quelques minutes !".

Nous étions clairement en face d'une friction / gâchis de type "Waiting- time".

Dès que nous avons pu trouver des jours communs de travail nous avons pu réaliser des progrès importants.

Cas 2 : defects dans le même projet "my"

Malgré la nouvelle dynamique de l'équipe, nous n'arrivions toujours pas à finaliser le projet. Me retournant vers mes notes d'observation, je pris conscience de 2 autres éléments qui nous ralentissaient considérablement, tous 2 liés à des bugs et à leur gestion.

En effet, nous en étions au point où nous pouvions déployer la solution sur l'environnement d'Acceptance de telle sorte que le Business puisse la tester. Cela nous mis au contact d'une série impressionnante de petits bugs que le Business documentait en MS-Word et qu'Antoine passait son temps à copier-coller en Jira. Nouvelle friction, autre gâchis ! Pourquoi le Business ne pouvait-il pas entrer les anomalies directement en Jira lui-même ? Pourquoi payer un chef de projet externe pour recopier des infos de documents Word en Jira ?

Pour résoudre le problème j'ai complétement modifié la mention des defects et ai organisé une communication la plus directe possible instituée d'ailleurs dans un stand-up meeting chaque matin. Nous avons aussi pu libérer Antoine qui préférait d'ailleurs se consacrer à un autre projet chez un autre client dont économie de 20k€/mois.

L'élimination de ce travail inutile est une élimination de friction. Faire l'économie de 20k€/mois enlevait par ailleurs une énorme épine du pied de notre CIO : sacrée friction.

Cas 3 : architecture complexe dans le même projet "my"

La raison fondamentale de notre besoin de disposer de Pierre, d'André, de Daniel, et finalement Antoine s'expliquait par la mise en place d'une architecture informatique trop moderne pour l'organisation. En effet, l'architecture avait été découpée en différentes couches comme c'est généralement recommandé mais était trop complexe pour l'organisation qui ne disposait pas de l'expertise requise pour agir à chaque niveau. Même l'entreprise qui avait établi cette architecture ne pouvait pas offrir des ressources rassemblant en une personne les connaissances nécessaires à chaque couche. De toute évidence, une nouvelle friction.

Cela tombait bien car c'était justement pour ce type de problème que le Directeur Informatiqye m'avait confié la mission de Transformation Digitale.

Cependant, même après avoir dessiné les schémas architecturaux simplifiés — baptisé Kelès —, et un plan de mise en œuvre, je ne suis jamais parvenu à éliminer la terrible friction de cette architecture par trop complexe. Les changements envisagés représentaient une forme de barrière infranchissable faite d'opinions non-verifiées et d'une campagne de discrédit jetant l'opprobre sur la firme extérieure à qui nous avions commandé un audit "architecture". Nouvelle friction donc.

Au moment où j'écris ces lignes, cette architecture, inutilement compliquée, est toujours en place près d'1 an ¾ après le constat original et cause toujours les mêmes difficultés avec pour conséquences délais de développement et coûts.

Cas 4 : Interactions avec le monde externe (fournisseurs, institutions de secteur, …)

Pour le même syndicat, je me suis occupé d'un projet pour lequel nous étions en contact avec une structure inter-syndicale : l'InterOP.

Cette structure avait délégué à un fournisseur externe le soin de développer une solution générique pour tous les organismes de paiement des allocations de chômage selon un accord politique de 2015.

En pleine intégration de cette solution générique, lorsqu'il s'agissait d'obtenir des éclaircissements techniques de la part du fournisseur, le développeur principal de notre équipe était obligé de passer par un représentant de l'IT, lui-même passant par le représentant du syndicat auprès de l'InterOP s'en remettant ainsi à son responsable technique qui devait ensuite contacter le chef de projet nommé auprès du fournisseur, qui au final posait la question au développeur de la solution. Pas moins de 6 intervenants dont certains sans aucune connaissance technique. Inutile de dire que le délai de réponse était particulièrement long et que la réponse elle-même ne correspondait que très rarement à la question technique posée. Pour une petite question on devait parfois attendre entre 2 et 3 semaines avant d'avoir une réponse qui faisait sens. Voilà une des frictions principales à laquelle le projet devait faire face. Il y en eut bien d'autres comme, par exemple, se rendre compte que la documentation fournie ne correspondait pas au produit qui l'accompagnait, ou que le chef de projet du fournisseur avait disparu, ou qu'après avoir nommé un nouveau chef de projet celui-ci découvrit que le développeur avait disparu.

En termes de mudas, nous faisions face à un excès de mouvements, de transports et de temps d'attente. Ces gâchis se trouvaient également répartis sur toute la chaîne, tant au niveau du syndicat, qu'à l'InterOP, et chez le fournisseur.

Pour éviter ces intermédiaires à faible valeur ajoutée et après consultation du Directeur Informatique j'ai sollicité l'autorisation de pouvoir entrer en contact direct avec le technicien du fournisseur tout en garantissant de garder tous les intermédiaires informés (mise en copie de nos demandes). Cela a permis de réduire considérablement le temps de latence entre question et réponse. Élimination du waiting-time. Élimination d'un gâchis, d'une friction.

À l'heure où ces lignes sont écrites, le projet, pourtant entièrement développé, n'a pas encore été mis en production ce qui est un autre gâchis. Les raisons ? Elles sont multiples mais la principale tient au fait qu'elle ne peut être testée qu'avec grande difficulté et sans tests pas d'acceptation finale. Cela m'amène à établir un nouveau constat de friction qu'il va falloir éliminer.

Ce cas je le clôturerai sur une technique : les 5 Why ! Je vous en livre la définition Wikipedia que je serais bien en peine d'améliorer :

Les cinq pourquoi est la base d'une méthode de résolution de problèmes proposée dans un grand nombre de systèmes de qualité.

Il s'agit de poser la question pertinente commençant par un pourquoi afin de trouver la source, la cause principale de la défaillance. Cette méthode de travail est surtout faite pour trouver la cause principale du problème rencontré.

Avec cinq questions commençant par « pourquoi », on essaie de trouver les raisons les plus importantes ayant provoqué la défaillance pour aboutir à la cause principale.»

Cas 8 : Absence de gestion de terrain pratique

Revenant au syndicat, et se focalisant sur la structure même de l'IT, le CIO était confronté à une absence totale de gestion claire et efficace de son département, une situation dont il héritait et qu'il a dû combattre avec acharnement sans pour autant arriver à susciter la compréhension de la Direction. Il ne disposait d'aucun outil informatique sérieux pour gérer le budget du département, ni même de gérer ses commandes, ni par ailleurs pour gérer les contrats, les feuilles de prestations, etc. Son étonnement grandit encore lorsqu'il constata que l'inventaire du matériel n'avait plus été mis à jour depuis 7 ans, depuis 2012.

En ma qualité de Transformation Manager il m'adjoignit à son travail de réflexion et on formula un ensemble de pistes de travail basées sur les conséquences de la situation, conséquences qui, au fond, impactaient le Directeur Informatique lui-même en l'obligeant à un travail administratif aussi récurrent que grotesque : passer de longues minutes à chercher les traces de commandes passées dans une série de feuilles Excel stockées à différents endroits du réseau lorsqu'il s'agissait de donner son approbation pour une facture de fournisseur ; passer un temps précieux à rechercher sur le même réseau la dernière version de différents contrats lorsqu'il s'agissait de signer l'acceptation finale d'un produit ; établir des feuilles Excel créées de toutes pièces pour établir le budget de l'exercice à venir sans avoir un inventaire officiel des coûts préalablement engagés ; ne pas disposer d'une vue agrégée des coûts par fournisseur afin de pouvoir renégocier certains prix; etc.

La résultante de tout cela était que, de toute évidence, le CIO en était réduit à effectuer un travail d'archéologue qui le débordait complètement et l'empêchait d'aller au cœur de sa mission. En l'espèce, tout ceci créait d'intenses frictions dues à l'absence de processus et d'outils adaptés. Il ne s'agissait pas d'optimiser mais ... d'organiser.

Cependant, l'ampleur de la tâche était telle que nous nous trouvions devant un problème de priorisation : il n'était pas possible d'apporter de solution simple sur tant de fronts simultanés et bien que plusieurs outils aient été considérés l'approche qui nous parut la plus efficiente fut de nous en remettre aux 5S de Lean : Seiri, Seiton, Seiso, Seiketsu et Shitsuke (https://fr.m.wikipedia.org/wiki/5S).

Profitant de l'engagement récent d'une responsable PMO, le Directeur Informatique lui confia l'application des 5S, une tâche qui lui prit plusieurs mois, sans pouvoir la terminer d'ailleurs tant le problème était aigu.

To be continued