Lean, Agile, Six Sigma, Kanban, Scrum, théorie des contraintes, TPM : quelles différences, et laquelle pour une usine ?

La réponse courte, pour un dirigeant qui n’a pas le temps de lire la suite : le Lean et Six Sigma travaillent sur le procédé, la théorie des contraintes dit où travailler, la TPM fait tenir les machines, et l’Agile, Scrum et le Kanban logiciel ont été pensés pour des équipes qui écrivent du logiciel ou conduisent des projets. Une PME qui fabrique commence par le Lean, sur son goulot, sort Six Sigma quand un défaut résiste, et peut emprunter à l’Agile quelques rituels courts pour ses équipes. Elle n’a pas besoin d’un Scrum Master dans l’atelier.

La suite explique pourquoi, approche par approche : d’où elle vient, quel problème elle résout, ce qu’elle mesure et pour qui elle a été pensée. Les faits viennent des textes fondateurs, cités en bas de page. Ce qui relève de mon avis est écrit à la première personne.

Le Lean : faire avancer le produit, pas les gens

D’où il vient. Du système de production de Toyota, formalisé par Taiichi Ohno, qui l’a décrit lui-même dans Toyota Production System (édition japonaise en 1978, anglaise en 1988). Le mot « lean » s’est répandu plus tard, avec The Machine That Changed the World de Womack, Jones et Roos en 1990, qui comparait les usines automobiles du monde entier. En 1996, dans Lean Thinking, Womack et Jones en ont tiré cinq principes : la valeur vue par le client, la chaîne de valeur, le flux, la production tirée, la recherche de la perfection.

Le problème qu’il résout. Le délai. Ohno décrivait son travail comme le fait de regarder le temps qui sépare la commande du client de l’encaissement, puis de le raccourcir en retirant tout ce qui n’apporte pas de valeur : le stock, les attentes, les transports, les retouches, les gestes inutiles.

Ce qu’il mesure. Le délai de traversée, l’en-cours, la part du temps qui transforme réellement le produit, le rendement des machines qui limitent le flux. Le produit et la machine, jamais la personne.

Pour qui. Tout flux répétitif, de l’atelier au bureau qui traite des dossiers, quelle que soit la taille de l’entreprise.

Pourquoi je le mets en premier

Le Lean est, à mes yeux, la plus humaine de ces approches. Il crée de la valeur en misant sur l’intelligence du groupe : ceux qui font le travail savent où il coince, et une démarche qui ne leur demande rien n’obtient rien. Et il tient en une phrase, qui évite le contresens le plus répandu : le Lean, c’est vouloir que le produit avance plus vite, pas les gens. Le jour où une démarche Lean presse les opérateurs au lieu de fluidifier le flux, elle a changé de nature.

Le guide du Lean manufacturing le suit sur un atelier, du diagnostic au gain mesuré, et la page philosophie Lean en donne les piliers.

Six Sigma : réduire la variation

D’où il vient. De Motorola, dans les années 1980, comme le racontent Mikel Harry et Richard Schroeder, qui ont contribué à le diffuser. Sigma, la lettre grecque, désigne l’écart-type, c’est-à-dire la dispersion d’un procédé.

Le problème qu’il résout. Les défauts qui viennent de la dispersion : une cote qui sort de tolérance de temps en temps, sans que personne sache dire pourquoi. Il n’y a là ni gaspillage visible ni goulot, il y a de la variation, et elle ne se traite pas à l’intuition.

Ce qu’il mesure. La capabilité du procédé (Cp, Cpk) et le nombre de défauts par million d’occasions. Un procédé « six sigma » vise 3,4 défauts par million, en tenant compte du décalage de 1,5 écart-type admis sur le long terme. La démarche suit cinq étapes, DMAIC : définir, mesurer, analyser, améliorer, contrôler. Et avant de mesurer le procédé, on vérifie le moyen de mesure.

Pour qui. Les procédés répétitifs et mesurables où la non-qualité coûte cher. Une grande partie des surcoûts d’une usine vient de la non-qualité : c’est là que Six Sigma rapporte.

Le Lean et Six Sigma ne répondent pas à la même question, et c’est pour cela qu’ils vont ensemble. Michael George a popularisé leur réunion sous le nom de Lean Six Sigma en 2002. L’excellence opérationnelle, c’est Lean plus Six Sigma : l’un retire les temps morts, l’autre les défauts, et les deux agissent sur le procédé. Pour le calcul, voir le guide de la capabilité et l’offre mesure et capabilité.

La TPM : des machines qui tiennent

D’où elle vient. Du Japon. Seiichi Nakajima l’a fait connaître hors du Japon avec Introduction to TPM (1988). TPM signifie Total Productive Maintenance, maintenance productive totale.

Le problème qu’elle résout. Les pannes, les microarrêts, les ralentissements et les défauts dus à la machine. Son idée centrale : l’opérateur est le mieux placé pour voir dériver sa machine, parce qu’il est devant toute la journée. La maintenance autonome lui confie le nettoyage, le graissage et les contrôles simples ; la maintenance traite le lourd.

Ce qu’elle mesure. Le taux de rendement synthétique, le TRS (en anglais OEE), et les six grandes pertes qui le font baisser. Nakajima est celui qui a posé cet indicateur.

Pour qui. Les ateliers où c’est la machine qui donne la cadence. Le guide du TRS détaille le calcul, et le calculateur de TRS le fait en ligne.

La théorie des contraintes : tout se joue au goulot

D’où elle vient. D’un roman. Dans The Goal (1984), Eliyahu Goldratt et Jeff Cox racontent un directeur d’usine qui doit redresser son site. Goldratt a ensuite formalisé la méthode, notamment dans un livre de 1990 qui en pose les cinq étapes.

Le problème qu’elle résout. L’effort dispersé. Une usine sort ce que sort son poste le plus lent, la contrainte, ou goulot. Une heure perdue au goulot est perdue pour toute l’usine ; une heure gagnée ailleurs ne change rien à ce qui sort. Les cinq étapes : identifier la contrainte, l’exploiter au mieux, subordonner tout le reste à son rythme, l’élever, puis recommencer, parce que la contrainte change de place.

Ce qu’elle mesure. Trois grandeurs, posées dans The Goal : le débit (l’argent que l’usine génère par ses ventes), les stocks, et les dépenses de fonctionnement. Pour piloter la production, Goldratt a proposé le « tambour-tampon-corde » (The Race, 1986) : le goulot donne le rythme, un tampon le protège, et la corde empêche l’amont de lancer plus que ce qu’il peut absorber.

Pour qui. Les flux à plusieurs étapes avec un poste nettement plus chargé que les autres, c’est-à-dire la plupart des ateliers.

L’Agile : un manifeste écrit pour le logiciel

D’où il vient. Du Manifeste pour le développement Agile de logiciels, écrit par dix-sept personnes réunies à Snowbird, dans l’Utah, du 11 au 13 février 2001. Y étaient représentées des méthodes de développement déjà existantes, dont Extreme Programming et Scrum. L’Agile n’est donc pas une méthode : c’est un socle de valeurs, que plusieurs méthodes partagent.

Le problème qu’il résout. Les projets logiciels conduits comme des chantiers figés : un cahier des charges complet au départ, une livraison des mois plus tard, et un résultat qui ne correspond plus au besoin. Le manifeste préfère quatre choses à quatre autres : les personnes et leurs échanges plutôt que les processus et les outils, un logiciel qui fonctionne plutôt qu’une documentation exhaustive, la collaboration avec le client plutôt que la négociation du contrat, l’adaptation au changement plutôt que le suivi d’un plan.

Ce qu’il mesure. Un logiciel qui fonctionne : c’est, selon l’un de ses douze principes, la principale mesure d’avancement.

Pour qui. Les équipes qui développent du logiciel, et plus largement les projets dont le besoin est incertain ou change en route.

Scrum : un cadre de travail en sprints

D’où il vient. Ken Schwaber et Jeff Sutherland l’ont présenté ensemble en 1995, à la conférence OOPSLA, puis décrit dans le Scrum Guide, dont la première version date de 2010 et la dernière de novembre 2020. Le mot vient du rugby, la mêlée. Il avait servi en 1986 à Hirotaka Takeuchi et Ikujiro Nonaka pour décrire, dans la Harvard Business Review, la façon dont des industriels, japonais pour la plupart, développaient leurs produits nouveaux.

Le problème qu’il résout. Comment une petite équipe livre un produit complexe sans plan figé. Le travail avance par sprints d’un mois au plus. Chaque sprint commence par une planification, se suit par une mêlée quotidienne de quinze minutes, et se termine par une revue de ce qui a été produit et une rétrospective sur la façon de travailler. Trois responsabilités : le propriétaire du produit, le Scrum Master, les développeurs. Le guide de 2020 le dit lui-même : Scrum repose sur l’empirisme et sur la pensée Lean.

Ce qu’il mesure. À la fin de chaque sprint, un incrément de produit réellement terminé, selon une définition de « terminé » connue de tous.

Pour qui. Une équipe produit, de dix personnes en général au plus selon le guide, devant un besoin qui évolue. Dans une usine, Scrum sert pour un projet : industrialiser un produit nouveau, développer un outil interne. Pas pour piloter une ligne qui tourne au rythme des commandes.

Kanban : un mot, deux outils

Le kanban de Toyota. Kanban veut dire « étiquette ». Chez Toyota, c’est le signal physique qui autorise un poste à produire ou à réapprovisionner : tant que l’aval n’a pas consommé et renvoyé l’étiquette, l’amont ne fabrique pas. Ohno raconte en avoir trouvé l’idée dans les supermarchés américains, où le rayon n’est réassorti qu’une fois vidé. Le nombre d’étiquettes plafonne l’en-cours : c’est l’outil de la production tirée.

La méthode Kanban du logiciel. David J. Anderson l’a décrite en 2010 pour le travail intellectuel : rendre le travail visible sur un tableau, limiter le travail en cours à chaque étape, gérer le flux, et partir de l’organisation existante au lieu de tout réorganiser d’un coup. Elle mesure le délai de traversée de chaque demande, le débit et l’en-cours. La loi de Little, démontrée par John Little en 1961, relie les trois : à débit égal, plus il y a d’en-cours, plus le délai s’allonge.

Ce qu’ils ont en commun. La même racine : on n’accepte pas plus de travail qu’on ne peut en finir. Le Kanban logiciel est un cousin du kanban d’atelier, pas son équivalent.

Le tableau comparatif

Les colonnes « où ça marche » et « où ça échoue » sont mon avis de praticien, pas une citation des textes fondateurs.

Les confusions qui coûtent cher

Le kanban de Toyota n’est pas le Kanban logiciel. Coller des tâches sur un tableau à colonnes dans l’atelier n’est pas un kanban : rien n’y empêche l’amont de produire. Un kanban d’atelier, c’est une étiquette qui circule avec le contenant et qui, absente, interdit de fabriquer. À l’inverse, une équipe de méthodes ou de maintenance peut très bien tenir un tableau Kanban à la façon d’Anderson, à condition de limiter son en-cours.

Le Lean startup n’est pas le Lean manufacturing. Eric Ries a publié The Lean Startup en 2011 pour créer un produit ou une entreprise dans l’incertitude : construire une version minimale, mesurer la réaction des clients, apprendre, recommencer. Il revendique l’inspiration de Toyota, mais il répond à une autre question, « faut-il fabriquer ce produit ? », et non « comment le fabriquer sans délai ni défaut ? ». Il ne dit rien du goulot de votre atelier.

L’Agile n’est pas né en usine. Le Manifeste est un texte de développeurs de logiciel. Le lien avec l’industrie passe par le développement de produits nouveaux, l’article de Takeuchi et Nonaka dont Scrum tire son nom, et par l’héritage Lean revendiqué dans le Scrum Guide. Il a bien existé un « agile manufacturing », défini en 1991 dans un rapport de l’université Lehigh sur la stratégie industrielle, mais c’est une autre notion, sans lien avec le Manifeste. Transposer les sprints sur une ligne de production revient à découper en tranches d’un mois un travail dont le rythme est déjà fixé par les commandes.

Le Lean n’est pas un plan de réduction d’effectifs. Si une démarche Lean sert une seule fois à supprimer des postes, plus personne n’y contribuera ensuite. Le temps libéré se réinvestit en capacité, en qualité ou en conditions de travail.

Laquelle pour une PME qui fabrique ?

Le Lean d’abord, sur le goulot, avec Six Sigma dès qu’un défaut résiste. C’est ma réponse, et elle tient à la nature des problèmes que je vois le plus souvent dans une entreprise qui fabrique : des délais trop longs, de l’en-cours partout, des heures perdues sur une machine, des défauts que l’on trie au lieu de les supprimer. Ce sont des problèmes de procédé, et le Lean et Six Sigma sont les deux approches qui travaillent sur le procédé.

L’Agile, Scrum et le Kanban logiciel ne sont pas faits pour la ligne. Ils restent utiles autour : pour un projet d’industrialisation, pour le développement d’un outil interne, pour une équipe de méthodes qui croule sous les demandes.

Comment elles se combinent

1. La théorie des contraintes dit où travailler. On cherche le goulot, et on y concentre l’effort. Améliorer un poste qui n’est pas le goulot ne fait rien sortir de plus.
2. Le Lean retire les pertes autour du goulot. Changements de série raccourcis, poste rangé, flux tiré par kanban pour que l’amont ne produise pas plus que le goulot n’absorbe. C’est l’étape « subordonner » de Goldratt, faite avec les outils de Toyota.
3. La TPM fait tenir la machine goulot. On mesure son TRS, on attaque ses six grandes pertes, et l’opérateur devient le premier à voir les dérives.
4. Six Sigma traite le défaut qui résiste. Quand la cause n’est pas connue, on vérifie le moyen de mesure, on calcule la capabilité, on déroule le DMAIC.
5. Les rituels courts, en partie empruntés à l’Agile, font tenir l’équipe. Un point quotidien d’un quart d’heure devant un tableau SQCDP, et, de l’Agile, la rétrospective : régulièrement, l’équipe regarde comment elle travaille, pas seulement ce qu’elle a produit. Un chantier d’amélioration de quelques jours, à l’objectif fixé d’avance, ressemble d’ailleurs beaucoup à un sprint.

Ces cinq étapes correspondent à trois des offres d’uon : pertes d’atelier et TRS pour trouver et traiter le goulot, mesure et capabilité pour le défaut qui résiste, management Lean pour les rituels qui font tenir le gain.

Ce que je déconseille

Acheter une méthode comme un paquet. Un Scrum Master dans un atelier qui n’a pas encore mesuré où partent ses heures, des ceintures Six Sigma formées avant le premier chantier, un tableau Kanban numérique installé avant que le flux soit stable : chaque fois, l’outil arrive avant la question, et il ne sert à rien.

Comment mettre en place le Lean management

On ne commence pas par former tout le monde, ni par acheter un logiciel. On commence par voir.

1. Aller sur le terrain et mesurer où partent les heures. Le TRS du goulot, l’en-cours, le délai de traversée. C’est l’objet de l’audit de l’atelier.
2. Choisir un seul chantier, sur le goulot, et le conduire avec ceux qui font le travail. Ce sont eux qui trouvent la solution, et eux qui la feront tenir.
3. Formaliser le problème sur une page, avec un rapport A3 : situation, cause, actions, résultat attendu.
4. Installer un rituel court qui fait remonter les problèmes chaque jour, comme le point SQCDP.
5. Mesurer le résultat, l’afficher, puis passer au goulot suivant. Un chantier sans résultat chiffré et affiché ne mobilise personne pour le suivant.

Le Lean management n’est pas une couche de réunions posée sur l’atelier. C’est la façon dont l’encadrement aide les équipes à résoudre leurs problèmes, chaque jour, au plus près du terrain.