Voici l’histoire d’une situation déplaisante, d’aucuns l’appelleraient « problème », qui a duré 1 an et qui s’est résolue en à peine un mois. Je propose de vous raconter cette résolution tout d’abord, puis de la sous-titrer en langage Lean.
L’histoire se déroule dans un grand groupe informatique, très engagé dans la production et l’exploitation de données informatiques à destination de nombreux cas d’usage, en particulier la production de rapports hebdomadaires.
Les protagonistes de cette histoire sont au nombre de trois, ils ont chacun leur rapport hebdomadaire représentant sous différents angles les incidents qui se développent chaque jour dans la production informatique du groupe.
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 ?
Better, faster, together 