Etienne de Susanne nous a présentés lors de la conférence FlowCon 4 années de déploiement du lean management, d’abord chez Michelin en tant que dirigeant de l’entité « Customer Experience » puis de DSI d’Euromaster. J’ai passé un excellent moment !
Ce texte n’a pas pour vocation de transcrire toute la conférence. Il s’agit d’un ensemble de points qui m’ont intéressée, classés en deux parties :
Qu’obtient-on quand on déploie le lean à l’échelle d’un département ou d’une DSI ?
Google Cloud définit l’IA générative ou l’intelligence artificielle générative comme « l’utilisation de l’IA pour créer de nouveaux contenus, comme du texte, des images, de la musique, de l’audio et des vidéos ». Le lean dans les activités de service est l’une de nos principales expertises et nos clients s’intéressent bien sûr à l’IA générative. Donc nous aussi. On pourrait par exemple imaginer que nos clients banque, assurance ou société de gestion d’actifs exploitent l’IA générative pour construire plus vite et avec moins d’effort les reportings qu’ils ont l’obligation de produire. Il y en a des quantités ! Un domaine d’application par excellence : les reportings sur les milliers de fonds d’investissement existants. Ils sont produits sur des bases très régulières, allant de la semaine à l’année, et ont une structure très standardisée.
L’aspect le plus spécifique du lean IT est le suivant : l’impérieuse nécessité de regarder de quoi on parle. Dans ce monde de knowledge workers, tout prend la forme d’une variable. Ceci est une demande et cela est une évolution (parfois fonctionnelle, parfois corrective), cela est un incident et ceci est une alerte, etc, etc, etc. Idem dans la production : un environnement, une instance, …
Une fois que la nature de ce dont on parle est posée, tout le monde s’en satisfait. On en arrive à bâtir des « processus cathédrales » sans savoir du tout de quoi il s’agit.
Je croise un jour de mai Olivier, l’un des patrons de la production informatique d’une entreprise du CAC 40. Nous avions eu l’occasion d’animer ensemble le déploiement du lean sur un pan important de son département et nous nous entendions bien. Je le vois exténué et j’en suis bien désolée.
Dans cet article, je vous propose de regarder un évènement précis qui a décidé du résultat d’un A3 que j’ai conduit il y a quelques temps.
L’objet de ce A3 était la réduction du nombre d’incidents générés par une production informatique. A la fin de l’exercice du A3, le nombre d’incidents de cette production est passé de 185 / jour (stable) à 99 / jour (stable) en 10 mois. Le gain obtenu par l’entreprise sur toute cette période a été estimé à 3,7M€, rien que sur le coût de traitement.
Est-ce que mon A3 a fait un « tout droit » vers son résultat ? Absolument pas ! Cet article est le récit du virage pris, qui a évité l’échec et atteint le succès.
Délivrer de la valeur au client, dans les délais et en respectant la qualité requise est l’enjeu premier d’une équipe IT, et de toute équipe quel que soit son domaine d’activité.
Dans cet article, je vais vous parler d’une équipe IT (PO et développeurs) que j’ai accompagnée et qui avait justement des difficultés : elle avait très peu délivré sur ses derniers sprints et connaissait des problèmes de qualité.
Cette recherche m’a été inspirée par une question récurrente qui se pose en informatique : comment travailler de façon lean avec ses fournisseurs et prestataires ?
Prenons par exemple un contrat cadre qui permet de mobiliser des responsables d’équipe, des développeurs ou des testeurs via une entreprise de service numérique : dans la mesure où ils ne sont pas salariés de l’entreprise, peut-on leur demander de travailler en flux tiré ? Ou ont-ils toute latitude pour s’organiser ? Et dans ce cas, comment engager des actions de résolution de problèmes pour améliorer le fonctionnement entre les deux entreprises ?
Achille et la tortue, ou comment accélérer prodigieusement la vitesse de réalisation des nouveaux développements informatiques
Zénon d’Elée, au 5e siècle avant notre ère, énonçait son paradoxe bien connu : la tortue est 100 pas devant Achille ; ils font la course. Le temps qu’Achille fasse les 100 pas, la tortue en a fait 10 ; le temps qu’Achille couvre ces 10 pas, la tortue en a fait un ; si les choses continuent ainsi de suite, jamais Achille ne devrait rattraper la tortue ; et pourtant il la rattrape évidemment. Comment cela se peut-il donc ?
Une simple suite géométrique dont la convergence est fournie par la formule suivante : a / (1-q) soit 100/ (1-0,1) soit 100/0,9 = 111,11 mètres.
Fin de la course.
Il n’empêche que la belle mécanique théorique du 1/10 de plus à l’infini séduit nos esprits depuis 2500 ans. Et continue de le faire.
« L’évidence des sens est parfois fallacieuse », disait Parménide. Si les biais cognitifs n’étaient pas si attirants, nous ne nous égarerions point dans leurs pièges…
Supposons maintenant que la tortue avance en ligne droite du départ à l’arrivée, en prenant la bonne direction à chaque fois.
Et que Achille se trompe simplement de direction deux fois sur 10, à chaque pas.
Leader et manager lean, vous changez de poste. Par quoi commencer ?
Après trois ou cinq années d’efforts et d’amélioration continue, qui ont abouti à des résultats époustouflants obtenus par vos équipes gonflées à bloc, vous vous apprêtez à prendre un nouveau poste, une petite larme à l’œil et la poitrine gonflée par le vent du large.
Ailleurs, que ce soit dans une autre entité du même groupe ou dans une autre entreprise, vous vous apprêtez à quitter votre joli système lean un peu hors norme, qui tourne comme un coucou suisse, pour un autre quadrant régi par d’autres paradigmes plus traditionnels. Voire carrément normatifs. Aïe !
Ce que le lean vous a apporté, à vous et à vos équipes, est si structurant que vous n’avez pas du tout l’intention d’y renoncer. Comment allez-vous donc bien pouvoir vous y prendre ?
Inès manage une équipe de support informatique qui a en charge la résolution des incidents et la réponse à un ensemble de demandes d’aide arrivant au fil de l’eau. Inès cherche à s’approprier les pratiques managériales du lean :
Elle a donc défini un premier challenge pour ses équipes : accélérer sur le traitement des incidents, avec comme premier pallier de respecter les engagements de service (SLA) auxquels son service a souscrit.
Exemple de SLA : cinq jours pour retrouver un fonctionnement informatique normal pour des incidents de criticité moyenne.
L’équipe construit sa 1ère mesure : le taux de retard dans la remise en service est de 27 %. Il y a donc matière à s’améliorer !
Gemba
L’équipe commence par mieux comprendre d’où viennent ces retards. Ils extraient un ensemble d’incidents, les analysent un par un et les organisent en « pareto », c’est-à-dire en piles d’incidents ayant la même caractéristique.
Ils sont surpris de découvrir que certaines familles comportent un nombre significatif d’incidents de même nature, alors qu’ils les croyaient plutôt uniques.
Kaizen
Arnaud, l’un des membres de l’équipe, propose de prendre en charge les incidents liés à la facturation entre l’entreprise et ses clients. Inès se réjouit de voir le kaizen commencer.
Elle continue dans sa posture de « manager as a coach » et cherche maintenant à ce qu’Arnaud comprenne bien l’importance du sujet qu’il travaille avant d’engager l’amélioration. Arnaud arrive à la liste suivante :
Les problèmes de facturation créent des tensions entre l’entreprise et la comptabilité de ses clients,
La législation oblige à un règlement des factures sous 45 jours, délai difficile à tenir s’il y a un incident,
Le département Finance se plaint d’avoir des incertitudes sur la facturation et le chiffre d’affaires.
Une fois l’impact posé, Arnaud entre maintenant dans la recherche de causes.
Dans son gemba, il lui apparait très vite que le standard de traitement des tickets n’est pas respecté. A titre d’exemple, sur l’un des incidents, l’équipe attend une validation externe du « métier » sur une solution très technique, sur laquelle le métier n’a pourtant pas de compétence particulière. Le temps s’allonge et le SLA n’est pas respecté.
D’autre part, les incidents ouverts disparaissent du radar des équipes « métier ». Chacun reçoit nominativement les incidents sur lesquels sa contribution est attendue. Il n’en existe aucune liste récapitulative et, avec un peu d’inattention, les incidents disparaissent. Beaucoup ne savent pas qu’ils ont un incident à regarder et une action à conduire.
Arnaud propose à Inès de retravailler les standards avec les « métiers » puis d’y former leurs interlocuteurs. A titre de pense-bête, il propose aussi de donner à leurs interlocuteurs « métiers » l’accès à leur management visuel du flux des tickets et de faire un point hebdomadaire pour voir s’il y a des problèmes particuliers.
Une fois ces actions conduites, le taux d’incidents hors SLA descend de 27 % à 15 %. Arnaud en est bien fier.
A la question d’Inès de savoir ce qui l’a le plus marqué dans son PDCA, il explique avoir été très étonné par les impacts concrets des incidents informatiques. Lui voyait une panne comme une panne de machine, et non comme un vrai risque commercial et financier.
L’histoire ne s’arrête pas là
Inès est guidée dans son parcours de manager lean par un coach lean expérimenté. Arnaud et elle profitent d’une de ses visites pour lui présenter le PDCA. A l’issue d’un échange à trois autour des questions du coach, la recommandation qu’il laisse est de réfléchir à deux points :
Question 1 pour Arnaud : Construire et partager un standard a manifestement permis de passer une marche mais il reste encore 15 % des incidents résolus hors SLA. Pourquoi ? Il faut retourner sur le terrain et creuser au-delà des problèmes les plus évidents.
Question 2 pour Inès : Comment faire vivre un standard et son usage sur le long terme ? Au moment où les bonnes volontés se mobilisent pour le construire, chacun progresse dans sa compréhension du processus. Mais ensuite, on oublie, les gens changent et les bonnes pratiques risquent de disparaitre.
Et vous, lecteur, qu’auriez-vous laissé comme question à Arnaud et Inès ?
Trop d’info tue l’info, il faut simplifier : Non. Ce n’est pas l’excès mais la rétention d’information qui tue la collaboration, en particulier la rétention involontaire basée sur l’illusion “ce que je sais les autres le savent aussi, il est donc inutile d’en parler”. Et si la réalité est complexe, il est contre-productif de chercher à en simplifier la représentation à outrance. Comprendre ensemble, voir ensemble, agir ensemble.
Pour produire deux fois plus, il faut évidemment deux fois plus de monde. Non. Pour produire deux fois plus Il suffit de trouver et d’éliminer à peine 10 % des gaspillages inhérents au fonctionnement aberrant actuel. Démontré des centaines, des milliers, des millions de fois par les millions de personnes qui ont essayé à travers le monde, depuis des dizaines d’années que le lean existe. Mais toujours aussi in-croyable.
Sur un grand projet, on finit toujours par être obligé de sacrifier soit la qualité, soit les délais, soit les coûts. Non. Sacrifier la qualité amène immanquablement à sacrifier les délais, donc les coûts. Trois pour le prix d’un seul ! L’illusion du quick and dirty aboutit immanquablement dans les faits à disgusting and so late.
Mieux vaut commencer par le plus compliqué, comme cela tout le reste sera beaucoup plus facile ensuite. Non. Il ne viendrait à l’idée de personne de commencer la découverte des mathématiques par le plus compliqué, comme les équations de Shroedinger, de Maxwell, ou de Black et Sholtes, au motif que le théorème de Thales serait plus facile à comprendre ensuite, même si c’est vrai. Et pourtant on continue.
Éviter de rédiger une documentation de toute manière toujours obsolète, c’est éviter un gaspillage. Non. Se passer de documentation, en particulier en exploitation, est bien évidemment le meilleur moyen de créer des montagnes d’erreurs à corriger sans la moindre boussole : pour éviter la traversée du Jura une fois, on devra escalader le Mont Blanc chaque jour. Excellent choix, puisque ce sont deux équipes différentes.
La vérité est dans le code et nulle part ailleurs. Non. La seule vérité dans le code, c’est qu’il mériterait un bon refactoring qu’on ne trouve jamais le temps de réaliser. Cf point 14.
C’est toujours le plombier précédent qui a fait du sale boulot. Oui. Plombier ou dev, PO ou chef de projet, manager ou DSI, il a toujours soigneusement appliqué les 15 autres préceptes en étant convaincu de faire bien.
Les erreurs, en particulier humaines, sont inévitables. Non. Presque toutes les erreurs humaines ont une cause racine évitable. Il faut juste chercher un peu plus loin que la simple réponse au premier pourquoi ?
Les incidents de production sont chaque fois différents. Non. Si les manifestations d’un incident en production sont très souvent différentes, leurs causes racines tournent toutes autour des mêmes familles de banalités crasses : absence de monitoring, de tests, de maintenance préventive, de gestion de l’obsolescence, de séparation homme-machine, de formation, de formalisation de la connaissance ou de standard. Qui se résument à une seule : absence de budget, donc de volonté, de ne rien céder sur la qualité. Point.
Zéro défaut, c’est juste impossible. Non. Dans l’industrie on compte les défauts en ppm (partie par million), quand dans l’industrie logicielle on les compte en ppc (partie par centième, ou encore pourcentage) soit 1 000 000 / 100 = une tolérance à l’erreur 10 000 fois plus élevée. Impossible, vraiment le zéro défaut ?
Avec une bonne réorganisation, on résout beaucoup de problèmes. Non. On n’aura rien amélioré du tout avec une reorg : ni le processus, ni la manière de l’opérer, ni les connaissances des collaborateurs, ni les pratiques managériales, sauf par grand hasard. On aura juste dégradé les réseaux et collaborations informelles existantes et repoussé l’acceptation du problème à la troisième enveloppe.
Le plus important, c’est d’éviter que les gens ne perdent du temps à se tourner les pouces sans rien produire. Non. Le plus important, c’est d’éviter que le flux de production ne soit interrompu, ce qui n’a rien à voir avec une soi-disant “optimisation” de l’activité des personnes.
Si on pouvait recruter plus d’experts bien formés, ça irait beaucoup mieux. Non. Il n’y a aucun expert disponible dehors ; les seuls experts du sujet sont ceux qui triment chez nous sans répit depuis trois ans sur le sujet. Donc le problème est ailleurs. Peut-être dans le temps riquiqui que nous consacrons à former efficacement ceux de nos collaborateurs moins experts, sans parler des prestataires ?
Charger les gens à 110 % c’est les rendre plus efficients. Non. Charger au maximum les équipes, c’est les empêcher délibérément de prendre le recul, i.e. le temps nécessaire pour résoudre définitivement certains de leurs irritants. La plus grande, et la plus classique des erreurs managériales, sans doute possible.
Le plus important dans une réunion c’est de la finir à l’heure pour ne pas démarrer en retard la suivante. Non. Dans une réunion l’important c’est de faire participer les bonnes personnes sans en oublier ni en manquer.
Le client ne sait jamais ce qu’il veut, rien ne sert de perdre trop de temps avec lui ; mieux vaut un PO ou une AMOA qui parle en son nom. Non. Le client sait très bien ce qu’il veut. C’est nous qui ne nous intéressons pas vraiment à ses usages, au motif fréquent que ce serait vraiment trop “chronophage”.
Il vaut mieux ne pas participer à une réunion d’une heure trente si c’est pour ne s’exprimer que 5 minutes, on aura évité de perdre 1h25 de son temps. Non. Il vaut mieux disposer au plus tôt des informations qui nous auraient évité une erreur de conception d’architecture remettant en cause toute la réalisation du projet de 18 mois à dix jours du « go live ».
Une pensée émue pour tous ces grands projets Louvois, Scribe, Sirhen, ONP, LUMM, dégommés dans les rapports de la Cour des Comptes : hommage aux grands projets tombés au champ de déshonneur de l’IT, embourbés dans ces 17 biais cognitifs si bien partagés.
Vous souhaitez être accompagnés ou connaître nos offres ? Contactez-nous à l’adresse contact at operaepartners point com, par téléphone au 01 40 05 96 88 ou avec le formulaire ci-dessous :
Better, faster, together 