La pratique du lean management dans l’IT

de Marie-Pia Ignace, Christian Ignace, Régis Medina et Antoine Contal

Après un précédent livre traitant plus particulièrement du Kanban, voici maintenant un livre qui prend une perspective un peu plus large, en présentant une déclinaison de la philosophie Lean issue du monde automobile dans le monde informatique et télécom.
La première partie présente le Lean de façon théorique, et la deuxième illustre les concepts et outils utilisés au moyen de différentes études de cas qui ont été traitées par les auteurs tous coachs Lean

Première Partie: La théorie

Le décor est planté avec un historique des principales méthodes de management industriel ayant amené peu à peu au Lean.

On trouve en premier lieu le Taylorisme, appelé aussi Organisation Scientifique du Travail qui démarre peu avant la première guerre mondiale, puis qui s’ancre définitivement comme méthode industrielle efficace pour alimenter l’effort de guerre, et donc la mode perdurera jusqu’à bien après la deuxième guerre mondiale.

Le Lean, plus récent, est né au Japon chez Toyota après la deuxième guerre, car le Taylorisme impliquant une production de masse et donc d’approvisionnement de masse n’était plus possible du fait de la dévastation du pays. Il fallait donc trouver le moyen de produire de façon plus économique, à la demande, et raccourcir le plus possible le moment entre la commande et celui de son paiement.

Le Lean tient plus d’une philosophie que d’une méthodologie, et que l’on résume par “apporter le maximum de valeur au client au moindre coût pour l’entreprise et cela de façon durable” et qui se décline en trois points de la façon suivante:

• Trouver où est la vraie valeur pour le client, comment l’identifier puis la créer
  • soit de façon directe dans le produit pour le client,
  • soit en apportant de la valeur au collaborateurs de l’entreprise pour qu’ils puissent à leur tour consacrer + de temps à créer de la valeur pour le client

• Eliminer les gaspillages du processus de production
  • Eviter les surproductions (trop ou trop tôt) engendrant du stock non vendable de suite
  • Eviter le manque de qualité obligeant à un retoucher un travail censé être fini
  • Eviter les attentes inutiles entre les phases de production
  • Eviter de créer du stock partiellement fini, donc invendable en l’état
  • Eviter le transport (ex: passage d’info entre personnes)
  • Eviter les gestes inutiles (perdre du temps à chercher des infos ou des outils)
  • Eviter les étapes inutiles (réunion sans point d’actions, documents que personne ne lit)
  • Eviter la variabilité dans la demande créant des à coups dans la production

• Améliorer la qualité
  • Améliorer la compétence des personnes
  • Rendre les problèmes visibles dès que possible pour pouvoir les corriger aussi dès que possible et donc à moindre coût

En support à cette philosophie du Lean, Toyota a créé au fur à mesure plusieurs concepts et outils pour les aider à la mise en oeuvre.

•  Le juste à temps: Le but est d’adapter (en + ou en -) la production dynamiquement pour suivre la demande du client. Cela se traduit par moins d’attente (si la demande est élevée) et évite la création de stock non vendable de suite (gaspillage) si demande faible.

En appui de cette notion de juste à temps on définit aussi les concepts et pratiques suivants:

• le “takt time” = délai idéal entre deux livraisons pour livrer au même rythme qu’arrivent les demandes client.
• le flux continu: but: éliminer toutes les attentes entre les tâches (voir éliminer les tâches elles mêmes) n’apportant pas de valeur au client dans le processus de fabrication/livraison.
• le flux tiré: la demande est tirée/déclenchée par la commande du client => minimiser les stocks, les tâches de production/livraison sont ordonnancées en fonction de l’intérêt du client
• le flux pièce à pièce : Idéal de fonctionnement où il n’y a aucun stock et livraison d’un produit à la fois
• Le Jidoka (Construire de la qualité à l’intérieur du processus de fabrication/livraison). Le but est d’éviter de produire tout un lot de produit avec des défauts.
  • Chacun des employés quelque soit son niveau a le devoir et le moyen d’arrêter la production dès qu’un défaut de qualité est détecté. En informatique cela peut être l’utilisation de Test Driven Development: Tests auto déclenchés dès livraison lot logiciel
  • Rendre les problèmes visibles dès que possible. Après la crise due à un problème, retrospective et action pour éviter que ce même problème se reproduise

Il n’existe pas d’organisme de certification du lean comme CMMI ou ITIL pour la gestion de projet. Le Lean se veut être plus un voyage vers un objectif inatteignable, mais aussi un voyage que l’on peut démarrer immédiatement de là où on se trouve (un peu comme un pélerinage)

On retrouve cependant des moyens similaires suivant les implémentations:

• Management visuel pour
  • visualiser la production
  • visualiser les problèmes dès qu’ils apparaissent et réagir et corriger le problème dès qu’il est détecté pour protéger le client
• Agir à froid (après correction du problème) pour trouver la cause profonde du problème et éviter qu’il ne se reproduise
• Améliorer les pratiques du management pour soutenir les points précédents (Kaizen)
  • Inciter tous les collaborateurs quelque soit leur niveau à rendre les problèmes visible
  • Corrolaire aider à augmenter l’expertise des collaborateurs (à tous les niveaux) dans la recherche des causes profondes des problèmes et des solutions pérennes.
• Gemba: Politique incitant à aller voir sur le terrain ce qui se passe réellement par opposition aux réunions de crise basées sur du reporting de personnes qui n’ont rien vu
• Observation du travail des utilisateurs pour identifier les “gaspillages” qui peuvent être supprimés
• PDCA (Plan Do Check Act) Cycle d’amélioration continue
  • Plan: Identifier un indicateur mesurable illustrant un problème à résoudre et un objectif. Ex: nombre de tickets de support par semaine max
  • Identifier une correction minimale (même superficielle, le but est d’acquérir de la connaissance sur le problème/fonctionnement du systeme) pour la prochaine fois
  • Do: Mettre en oeuvre le plan
  • Check: Etudier les impacts du plan sur le problème à résoudre
  • Act: imaginer de nouvelles corrections et retour à l’étape Plan

Seconde Partie: La pratique

Dans la seconde partie, le livre aborde plusieurs exemples concrets en lien avec l’informatique, et les télécom incluant les phases de développement et de support. Chaque cas concret met l’accent sur une des pratiques indiquées plus haut.

On rencontrera successivement le coach lean aidant une SSII à maitriser ses délais de livraisons logiciel de façon incrémentale, pour au final aboutir à une livraison en flux continu.
Puis ensuite aider un service de support informatique à réduire de façon importante les délais de correction des incidents, en identifiant et supprimant de gros gaspillage dans la chaine de résolution et aussi en mettant en place des formations entre membres de l’équipe afin de faire monter en compétence tous les collaborateurs.
Et bien d’autres exemple que je vous incite à aller découvrir.

Conclusions:

En conclusion, ce qu’il faut retenir.

• Le Lean est + une philosophie qu’un ensemble de règles à suivre. Rien n’est obligatoire, en lean on démarre où l’on est et on déroule le PDCA.
• Il y a par contre énormement d’outils complémentaires qui peuvent être mis en oeuvre comme l’analyse de problème à la racine (Root Cause Analysis), ou l’identification de valeur dans un flux de production (Stream Value Mapping), Obeya, Kanban, etc…
• Le lean est particulièrement recommandé quand l’équipe est déjà installée et est hermétique aux règles du Scrum par exemple.
• A l’inverse si l’équipe vient de se former, il peut être utile de commencer par du Scrum pour que tout le monde acquiere les mêmes réflexes avant de bouger progressivement vers plus de Lean.

Si vous voulez approfondir le sujet, voici d’autres résumé de lectures traitant de sujets proches et commentées sur ce blog: Lean Management (dans le monde de la banque), Kanban pour l’IT (plus orienté outil)

(Je remercie Florence Préault de Operae Partners de m’avoir gracieusement fait parvenir ce livre. N’hésitez pas à faire de même si vous avez un livre intéressant dans les domaines d’intérêt de ce blog)