Qu'est-ce que le lean ?

Qu’est ce que le « Lean » ?

Cet article est une présentation générale du Lean Management. Vous pouvez le lire en suivant le fil de la conversation qu’il retrace, ou aller directement là où une notion est abordée. Les notions abordées :

• Lean Management
• Respect des gens
• Eliminer le gaspillage
• Amélioration continue
• Kaizen
• PDCA
• Standard
• Management visuel
• Poka Yoke
• Gemba
• Kanban

Alors, qu’est ce que le « Lean » ?

Ce terme « Lean » désigne un ensemble de principes et de pratiques de management et d’organisation. On emploie aussi le terme Lean Management. Cet ensemble est issu de TOYOTA et assure son succès depuis 50 ans.

Quels sont ces principes ?

Le premier, le plus fondamental, est le respect des gens. Il consiste à créer les conditions pour que les collaborateurs s’épanouissent dans ce qu’ils font. Le travail doit être inspirant et motivant. Il doivent être formés, responsabilisés et encouragés à résoudre eux-mêmes les problèmes qu’ils rencontrent dans leur travail quotidien. C’est fondamental car si les principes Lean sont du bon sens, la plus grande difficulté consiste à créer un environnement dans lequel suivre ce bon sens n’est pas dangereux mais standard.

Ah.

Par exemple, un développeur livre son module à la date prévue alors qu’il a de fortes raisons de penser qu’il ne s’intègrera pas au reste de l’application, ce qui nécessitera un effort important de diagnostic et re-livraison par la suite. Le contexte qui le fait agir contre le bon sens est que son responsable hiérarchique est objectivé sur le respect de cette date de livraison.

Ok. Un autre principe ?

Eliminer le gaspillage sur le flux de valeur. Il faut se concentrer sur ce qui crée la valeur pour laquelle le client de l’entreprise est prêt à payer. Toute l’entreprise est au service de cette création de valeur. Elle est créée le long d’un flux de transformation. Dans l’idéal, ce flux est tiré et sans stock pour réagir aux fluctuations de la demande et minimiser l’investissement. Cela signifie que l’on ne commence à produire quelque chose que lorsqu’il y a une demande. On ne produit alors que ce qu’il faut pour cette demande.

J’ai entendu parler de cette histoire de gaspillages. Il y a 7 types. C’est ça ?

Oui. Surproduction, délai, stock, transport, mouvement inutile, processus inutile et défauts. Par exemple attendre 3 jours pour réunir les acteurs en vue de décider d’un choix d’architecture pour un projet est un gaspillage de type « délai » pour le flux de valeur de ce projet.

Je te suggère le petit exercice suivant : quand tu rentres chez toi à la fin de la journée tu cherches un gaspillage auquel tu a été confronté dans la journée pour chacun des 7 types.

Ok, je vais essayer.

Autre principe du Lean : l’amélioration continue pas à pas des performances. Il y a 3 façons de changer :

• Innover : faire quelque chose de nouveau
• Imiter : reprendre quelque chose qui a déjà marché ailleurs
• Améliorer en continu pas à pas : partir de la situation actuelle et la changer petit à petit en s’assurant que chaque changement est une amélioration.

C’est quoi les avantages et inconvénients de chacune de ces façons ?

L’innovation est risquée mais peut faire faire des grands bonds. Elle peut être aussi dommageable pour une organisation car elle est souvent initiée par quelques élus au sacrifice potentiel de l’engagement et du leadership des autres. Par exemple, changer de technologie en informatique, ou changer de processus de développement.

L’imitation n’est pas risquée. Elle est connotée péjorativement en occident. Par exemple à l’école « tu ne copieras pas ». Pourtant c’est un type de changement très efficace qui permet de profiter des innovations des autres sans courir de risque. Aujourd’hui adopter un processus de développement comme SCRUM rentre dans cette catégorie pour beaucoup d’entreprises.

L’amélioration continue pas à pas n’est pas risquée. Elle nécessite un engagement de tout le monde, et une discipline qui assure que chaque pas posé est bien une amélioration. L’amélioration continue est difficile à imiter. TOYOTA la pratique depuis 50 ans. C’est pour cela qu’ils enseignent le Lean à leurs concurrents : ils n’ont pas peur d’être rattrapés.

Le Kaizen c’est quoi ?

Justement. Kaizen est le terme japonais pour « amélioration continue pas à pas ». Dans le Lean la méthode pour appliquer le Kaizen est PDCA.

C’est quoi PDCA ?

PDCA est une méthode d’amélioration continue inventée par E. DEMING dans les années 1950.

Ca veut dire quoi PDCA ?

C’est la première lettre des 4 étapes de la méthode. Elles forment un cycle qui se répète à chaque amélioration : PLAN – DO – CHECK – ACT.

Que fait-on dans chaque étape ?

L’étape PLAN contient 4 parties. Définir ce que l’on veut, comprendre l’écart avec ce que l’on a, choisir une contre mesure et faire une prédiction.

D’abord tu dois identifier ce que tu veux faire : quel est le problème ? Un problème est un écart entre ce que tu observes et ce que tu souhaites. C’est à ce moment que certains problèmes se résolvent juste en explicitant qu’est ce que l’on souhaite (et notamment : qui le souhaite), et quel est le standard actuel.

J’ouvre une parenthèse ici : la notion de standard est quelque chose d’important dans le Lean. C’est très différent de l’image que l’on en a dans les entreprises pré-Lean. Dans ces dernières, les normes et les procédures sont définies par des experts qui les formulent pour qu’elles soient appliquées par d’autres. Dans l’industrie c’est le moyen d’imposer des cadences de travail.

Je demandais à un client « Ce document fait partie du processus standard de gestion de projet ? » « Oh non, le processus standard n’est jamais appliqué. Il marcherait dans l’idéal mais n’est pas applicable ici. » « Depuis combien de temps n’a-t-il pas évolué ? ». « Heu, il n’a pas évolué depuis sa création il y a 3 ans ».

Dans le Lean un standard est l’ensemble des meilleures pratiques que l’on connaît à un moment donné pour effectuer une tâche qui se répète. Ces bonnes pratiques émergent du terrain, de la pratique des opérationnels eux-mêmes. Il n’y a qu’un standard à un moment donné, et il évolue constamment en fonction des leçons que l’on apprend de l’expérience.

Le modèle du Triangle D’or du Management Visuel permet de faire fonctionner un standard. Le management visuel consiste à rendre visible les écarts par rapport au standard. Comme cela il n’est pas besoin d’être courageux pour parler de ces écarts, ils sont traités tout de suite soit en renforçant la formation aux bonnes pratiques, soit en ajustant le standard.

Un triangle ?

Oui. Il faut 3 composantes pour que le standard fonctionne.

• D’abord le standard est écrit, de façon accessible, simple et opérationnelle. Il doit être un support de formation. A ce stade il y a un consensus entre tous ceux qui vont l’appliquer qu’il s’agit de la meilleure façon de faire la tâche.
• Ensuite il faut un mécanisme pour rendre visible les écarts par rapport au standard pour ceux qui l’appliquent. C’est un auto contrôle de qualité. Par exemple un gyrophare qui s’allume quand l’intégration continue échoue au sein d’une équipe de développement.
• Troisième sommet du triangle : la gestion des écarts. Elle doit être provisionnée et organisée afin de traiter les écarts efficacement, soit en renforçant la formation soit en faisant évoluer le standard.

Dans de nombreux cas il manque un élément au triangle et le standard ne fonctionne pas. Par exemple : les développeurs ne sont pas d’accord avec les conventions de code, ou le gyrophare s’allume mais personne ne pense avoir l’autorité d’arrêter ce qu’il fait pour investiguer le problème, etc.

Ok pour le standard. Nous en étions où ?

Oui, refermons la parenthèse du standard. Nous en étions à la phase PLAN du PDCA. La première étape de cette phase consiste à exprimer le problème comme un écart entre ce que l’on observe et le standard.

Ah oui. Ensuite ?

Ensuite, tu analyses cet écart, pour identifier les causes profondes dans l’organisation et dans les processus qui sont responsable du problème. L’important ici est de dépasser le traitement du symptôme. Ce que l’on cherche c’est à ajuster petit à petit l’organisation du travail pour se prévenir définitivement des problèmes. Pour remonter la chaîne de causalité du symptôme aux causes profondes tu appliques la méthode des 5 pourquoi.

Ah oui, tu m’en a déjà parlé.

Il faut faire attention à ce moment de ne pas identifier l’absence d’une solution auquel l’on pense comme étant la cause du problème. Par exemple, quand je dis « le problème c’est qu’il manque des tests unitaires », j’ai une petite voix qui me dis « là, tu es en train de fermer des options ». Différer le jugement pour se donner l’opportunité de connaître le problème avant de passer à la solution permet d’ouvrir le champ des actions possibles.

Nice.

Je continue ?

S’il te plait.

3eme partie de cette étape PLAN : choisir une solution au problème. On appelle cette solution une contre mesure car nous ne sommes pas dans la résolution ponctuelle d’incidents imprévisibles mais dans l’ajustement de processus organisationnels imparfaits qui génèrent des gaspillages.

Pour le choix de la contre mesure nous envisagerons à quel niveau de profondeur il est le plus efficace et pratique d’agir. C’est important que l’analyse du problème se base sur des faits concrets, sans interprétation ni généralisation.

Ensuite nous cherchons la contre mesure en essayant d’abord ce qui permettrait de supprimer par conception la source du problème. C’est le principe de POKA YOKE.

POKA YOKE ?

Oui. Cela signifie « error proofing », ou « anti erreur ». L’exemple le plus parlant est celui des premiers connecteurs série sur les ordinateurs. La position des broches électroniques était symétrique : il était possible de brancher la prise à l’envers, ce qui grillait les composants. Rapidement une solution POKA YOKE fut adoptée en mettant plus de broches en haut qu’en bas, ce qui a rendu impossible un branchement inversé.

Ah oui, je comprends.

Donc le premier type de solution que l’on recherche est de type POKA YOKE car elles sont les plus efficaces. Ensuite nous essayons de trouver comment détecter automatiquement les premiers indices d’apparition de ce problème. Enfin, si nous n’avons toujours pas de solution alors nous organiserons une revue manuelle de détection.

Dans l’informatique, utiliser 2 méthodes de classe plutôt qu’une seule méthode avec un argument optionnel est POKA YOKE. Les tests unitaires automatiques se rangent dans la seconde catégorie de solution. Un installeur qui s’arrêterait automatiquement dès qu’il rencontre un problème entre aussi dans cette seconde catégorie. Les revues de code se rangent dans la troisième catégorie.

Ok.

Dernière partie de l’étape PLAN : après avoir défini le problème, l’avoir analysé et choisi une contre mesure il faut faire une prédiction.

Une prédiction ?

Oui. Jusqu’à maintenant nous avons fait des hypothèses sur le problème, ses causes et l’efficacité de la solution. Un prédiction consiste à décrire ce qui devrait être observé une fois la contre mesure mise en place, en supposant que les hypothèses sont valables. Elle permettra d’infirmer ou de confirmer l’efficacité de la solution. Ce n’est qu’après avoir fait cette observation que nous pourrons dire que ce changement est une amélioration.

Voici une petite histoire qui circule dans le milieu de l’automobile : un manager dans une usine Française souhaite améliorer le temps de traitement des pièces sur un poste critique. Après analyse avec l’ingénieur, ils estiment que l’on peut gagner 12 secondes par pièce en chauffant la pièce à une température particulière avant de la traiter. Ils expérimentent et observent qu’ils gagnent 18 secondes. Les gains financiers sont importants. Ils sabrent le champagne. Au Japon, cette expérimentation serait un échec. Le manager et l’ingénieur serait reparti faire leurs calculs pour comprendre l’écart de 6 secondes qui invalide leurs hypothèses.

Je vois.

Ensuite la phase qui suit PLAN est DO. C’est le moment de l’expérimentation ou l’on va appliquer la contre mesure.

Expérimenter ? J’entends déjà mon boss dire « c’est pas avec mon projet que vous allez jouer à l’apprenti sorcier ! ».

Oui. Et pourtant sans la rigueur de confronter les hypothèses qui fondent chaque changement à l’expérience du terrain nous sommes dans des actes de foi, bien plus magiques et « sorciers », qui participent à faire végéter les organisations dans leurs ornières intellectuelles.

Right.

A la fin du DO nous passons à la phase CHECK où l’on confirme ou infirme que ce changement est bien une amélioration en confrontant ce que nous observons avec la prédiction initiale de la phase PLAN.

La 4eme phase ACT consiste à standardiser le résultat de ce changement. Si c’est un succès alors la contre mesure rejoint le standard et nous pouvons passer à une autre opportunité d’amélioration. Sinon, retour à la compréhension du problème et nouvelle boucle PDCA.

Tu te souviens ce que l’on a dit du standard ?

Oui : il n’y en a qu’un et il évolue constamment.

Exact. PDCA est une méthode simple et son application doit rester simple. Elle doit être applicable par n’importe qui dans l’organisation, à propos de problèmes triviaux comme de restructurations organisationnelles. Le plus complexe c’est de garder la discipline de l’appliquer. Et pour cela, rien de tel que de le faire à deux ou en équipe. Et surtout, garder en tête que c’est sur le GEMBA que l’on apprend.

Le GEMBA ?

Oui, c’est le terme japonais qui désigne le terrain où se produit la valeur ajoutée. Dans une usine, c’est la chaîne de production. Dans l’informatique c’est le plateau projet ou s’écrivent les specs, le design, le code, ou s’exécutent les tests et les mises en production.

Ok. Il y a un autre terme que j’entends aussi : KANBAN

KANBAN est une méthode pour organiser un flux tiré. Après avoir traité un élément, chaque étape demande à l’étape précédente de lui fournir un autre élément à traiter, quelque soit la taille du stock de pièces qui lui reste à traiter. Cela crée un flux de demande qui remonte le flux de création de valeur, depuis la demande client jusqu’à la première étape du processus.

Par exemple dans l’informatique un exemple de flux tiré serait : un client appelle son interlocuteur informatique pour lui dire qu’il veut automatiser une nouvelle tâche dans son application. Cet interlocuteur appelle le responsable de la production pour lui dire qu’il veut que soit installée cette nouvelle fonctionnalité. Celui-ci demande à l’équipe de développement de développer cette fonctionnalité. En fonction du coût intrinsèque que nécessite chacune de ces opérations il peut être nécessaire de créer du stock à chaque étape. Si l’on ne peut faire qu’une seule mise en production par mois, alors il faut empiler les fonctionnalités à livrer. L’approche Lean ne va pas à l’encontre de ce stock, elle oriente l’amélioration vers la diminution de ce coût intrinsèque qui régit la taille du stock.

Merci pour toutes ces explications.

Pas de quoi.

Et la TOC, c’est quoi ?

Heu… une prochaine fois peut-être.