La revue d'itération a encore commencé en retard. Quelqu'un propose de mettre un rappel dans les agendas, tout le monde acquiesce et la réunion suivante démarre à l'heure. Trois semaines plus tard, le retard revient sous une autre forme.
Le rappel traitait le symptôme sans toucher à la cause. Remonter de l'un à l'autre demande une méthode que la bonne volonté ne remplace pas, surtout dans une équipe où chacun voit le problème depuis son poste.
Deux outils servent ce travail depuis des décennies dans l'industrie japonaise puis dans les équipes de service et de logiciel. Ils tiennent sur une feuille de paperboard. Leur difficulté tient moins à leur mécanique qu'à ce qu'ils font aux personnes autour de la table.
Que sont le diagramme d'Ishikawa et les cinq pourquoi ?
Ce sont deux outils d'analyse de cause qui répondent à la même question par deux mouvements opposés. Le diagramme d'Ishikawa élargit le regard en rangeant toutes les causes possibles d'un effet par familles. Les cinq pourquoi creusent en profondeur, une réponse après l'autre, jusqu'à la condition qui produit le problème.
Le diagramme d'Ishikawa ouvre l'éventail des causes
Le problème s'écrit à droite, dans la tête d'un poisson. Une arête centrale le relie à des arêtes secondaires, une par famille de causes. Dans Gemba Kaizen, Masaaki Imai, consultant en management, en retient cinq, matières, machines, main-d'œuvre, mesures et méthodes, auxquelles il ajoute l'environnement selon les cas. Il présente l'outil comme l'un des sept outils de base de la résolution de problème, destiné à trouver la ou les causes réelles. On l'appelle aussi diagramme causes-effets ou diagramme en arêtes de poisson.
Les cinq pourquoi descendent le long d'une chaîne
On part d'un fait et on demande pourquoi il s'est produit. La réponse devient le sujet de la question suivante. Le chiffre cinq indique un ordre de grandeur. Il force à dépasser la première explication, celle qu'on donne par habitude, pour atteindre ce que le glossaire de Taiichi Ohno, ingénieur industriel, appelle la cause réelle, cachée sous la cause apparente. Le même glossaire résume la démarche d'une formule, « 5W = 1H », cinq pourquoi pour un comment.
D'où viennent ces deux outils ?
Ils viennent de deux hommes et de deux histoires que la pratique a fini par réunir. L'ingénieur de Toyota qui a fait des cinq pourquoi une méthode n'a pas dessiné le diagramme, le professeur qui a donné son nom au diagramme n'a pas formalisé les cinq pourquoi. Les supports de formation les présentent souvent ensemble au point de brouiller cette double origine.
Ohno et l'habitude de regarder
Ohno consacre aux cinq pourquoi une section de Toyota Production System, publié au Japon en 1978 et traduit en anglais en 1988. Il y écrit que le système de production Toyota s'est construit sur la pratique de cette démarche. Il en donne aussi la filiation. Selon lui, la procédure vient de l'habitude d'observer de l'inventeur Sakichi Toyoda. Jeune homme, celui-ci avait passé des journées entières à regarder tisser la grand-mère de la maison voisine.
Ohno applique la question à son propre système autant qu'aux pannes. Pourquoi un opérateur de Toyota ne tient-il qu'une machine quand une ouvrière du tissage en surveille quarante à cinquante ? La réponse a conduit à l'arrêt automatique des machines. Pourquoi produit-on trop de pièces ? Celle-ci a mené au contrôle visuel, puis au kanban. Le même chapitre contient l'exemple de la machine arrêtée par un fusible, détaillé dans l'article sur le gemba et la visite de terrain selon Taiichi Ohno.
Ishikawa et le contrôle qualité japonais
Kaoru Ishikawa (1915-1989), ingénieur chimiste, a enseigné à l'université de Tokyo. Il a joué selon Imai un rôle décisif dans le mouvement de la qualité et des cercles de qualité au Japon. Dans Gemba Kaizen, Imai le désigne comme celui qui a développé le diagramme causes-effets, nommé d'après lui.
Imai lui attribue aussi une formule qui éclaire tout le diagramme, « le processus suivant est le client ». Elle est née, raconte-t-il dans Kaizen (1986), d'une enquête sur des rayures dans une aciérie. Ishikawa avait suggéré à un ingénieur d'examiner le problème avec l'équipe du procédé suivant, ce qui avait d'abord semblé incongru à son interlocuteur. Un problème, dans cette logique, est tout ce qui gêne quelqu'un en aval.
Un diagramme souvent livré sans son auteur
Le diagramme circule fréquemment sans le nom d'Ishikawa. Kaizen d'Imai le décrit en 1986 sans l'attribuer. Agile Retrospectives le présente sous le nom de Fishbone, sans auteur. Le manuel de certification Lean Six Sigma Master Black Belt publié en 2018 par The Council for Six Sigma Certification le développe sur quatre pages sans jamais citer Ishikawa. L'outil est passé dans le domaine commun, ce qui n'efface pas sa généalogie.
Comment mener les cinq pourquoi en équipe ?
En binômes ou en petits groupes, un quart d'heure suffit quand le problème est bien posé. Esther Derby et Diana Larsen, facilitatrices, en donnent dans Agile Retrospectives une version prête à l'emploi. Les groupes comptent quatre personnes au plus. L'une demande pourquoi, l'autre répond, puis la question repart de la réponse.
- Partir d'un fait daté. « La revue de jeudi a commencé avec vingt minutes de retard » se prête à l'exercice. « On n'est jamais à l'heure » déclenche une plaidoirie.
- Répondre par ce qui s'est passé. Chaque réponse décrit un événement ou une condition que l'on peut vérifier.
- Noter ce qui sort du quatrième ou du cinquième pourquoi. C'est la consigne de Derby et Larsen. Les premières réponses décrivent souvent l'incident lui-même.
- Mettre les chaînes en commun. Chaque groupe présente ce qu'il a trouvé, ce qui alimente ensuite le choix des actions.
Leur exemple tient en cinq lignes. La revue a commencé en retard parce que la salle n'était pas libre. Elle n'était pas libre parce qu'on avait oublié de l'inscrire au planning. L'oubli tient à l'absence de Charlie, malade ce jour-là, lui seul réservant la salle d'habitude. Il en est seul chargé parce que l'équipe jugeait la chose sans importance. Elle la jugeait sans importance faute d'avoir mesuré le temps perdu. La réponse utile apparaît au moment où la chaîne quitte l'incident pour atteindre une condition, une tâche portée par une seule personne que l'équipe peut maintenant inscrire dans sa préparation.
Proportionner l'effort au symptôme
Eric Ries, entrepreneur, a repris les cinq pourquoi d'Ohno dans The Lean Startup (2011) en y ajoutant une règle de dosage. À chaque niveau de la chaîne, l'équipe investit à proportion de la gravité du symptôme. Une panne mineure appelle une correction modeste à chaque étage. Si le problème revient, l'analyse suivante ira un cran plus loin. Ce réglage évite les deux écueils habituels, le rafistolage qui laisse tout en place et le grand chantier lancé pour un incident isolé.
Comment construire un diagramme d'Ishikawa avec une équipe ?
Une demi-heure à une heure, un paperboard et des notes repositionnables suffisent. Derby et Larsen réservent l'outil aux rétrospectives longues, quand un problème mérite qu'on regarde au-delà des symptômes.
- Écrire le problème dans la tête du poisson, avec ce qu'on sait du quoi, du qui, du quand, du où et du pourquoi.
- Nommer les arêtes. Derby et Larsen proposent trois jeux de familles, méthodes, machines, matériaux et effectifs, ou bien lieu, procédure, personnes et politiques, ou encore environnement, fournisseurs, systèmes et compétences. L'équipe peut les combiner ou inventer les siennes.
- Remplir famille par famille. Pour chaque arête, la question porte sur ce qui, dans cette famille, cause ou influence le problème. Les réponses vont sur des notes collées le long de l'arête.
- Creuser chaque cause en demandant pourquoi elle se produit, avec des ramifications supplémentaires au besoin.
- Repérer les causes qui reviennent dans plusieurs familles. Les deux autrices y voient les causes peut-être les plus probables.
Leur exemple vient d'une équipe de développement dont la compilation du logiciel a cassé cinq fois en deux semaines. L'animateur a choisi quatre arêtes, compétences, systèmes, environnement et effectifs. En relisant les notes, l'équipe a vu deux causes ressortir sur plusieurs arêtes. L'une tenait à des membres peu expérimentés qui travaillaient seuls.
Le diagramme et les cinq pourquoi s'enchaînent bien. L'arête ouvre les pistes, puis une ou deux causes retenues passent aux cinq pourquoi pour descendre jusqu'à la condition qui les produit.
Lequel choisir selon le problème ?
Le choix dépend de ce que l'équipe sait déjà. Quand une piste domine et qu'il faut la suivre jusqu'au bout, les cinq pourquoi vont plus vite. Quand personne ne sait d'où vient le problème, ou que chacun en voit une cause différente, le diagramme évite de s'enfermer trop tôt dans une seule explication.
| Critère | Cinq pourquoi | Diagramme d'Ishikawa |
|---|---|---|
| Origine | Pratique de Toyota décrite par Taiichi Ohno (1978), adaptée selon lui de l'habitude d'observer de Sakichi Toyoda | Diagramme causes-effets attribué à Kaoru Ishikawa par Masaaki Imai |
| Mouvement | En profondeur, une chaîne | En largeur, plusieurs familles de causes |
| Durée en rétrospective | 15 à 20 minutes | 30 à 60 minutes |
| Format de groupe | Binômes ou groupes de quatre au plus | Toute l'équipe ou petits groupes par arête |
| Ce qu'il produit | Une condition sous-jacente sur laquelle agir | Les causes les plus probables, celles qui reviennent dans plusieurs familles |
| Quand l'arrêter | Quand la réponse devient une condition sur laquelle l'équipe peut agir | Quand les causes sortent du contrôle ou de l'influence de l'équipe |
| Piège principal | Une chaîne unique qui écarte les autres causes, ou qui finit sur une personne | Le diagramme rempli pris pour un résultat |
Aucun des deux ne remplace le travail de diagnostic qui le précède. Écrire l'écart observé sans cause ni solution, lister plusieurs explications candidates puis les trier relèvent d'une discipline que décrit l'article sur le PDCA et le rasoir d'Ockham pour diagnostiquer un problème. Le diagramme et les cinq pourquoi alimentent cette étape sans la contourner.
Où ces outils se retournent-ils contre l'équipe ?
Ils se retournent contre elle dès que la recherche de la cause devient la recherche d'un responsable. La mécanique reste identique, la question change de cible. Une équipe qui a vécu une séance de ce genre en garde le souvenir et répond prudemment à la suivante.
Les cinq accusations
Ries a donné un nom à cette dérive, les « Five Blames ». Au lieu de chercher ce qui s'est passé, les coéquipiers frustrés se renvoient la faute. Le but des cinq pourquoi, écrit-il, est de faire voir que les problèmes chroniques viennent d'un mauvais processus et rarement de mauvaises personnes. Il recommande de réunir dans la salle tous ceux que le problème a touchés, ceux qui l'ont découvert comme ceux qui ont tenté de le corriger. L'absent, observe-t-il, finit en cible. Quand le blâme surgit malgré tout, les personnes les plus haut placées de la pièce répètent une formule, honte à nous d'avoir rendu cette erreur si facile à commettre.
La question « pourquoi » porte en elle ce risque. Adressée à une personne plutôt qu'à un fait, elle sonne comme une demande de justification et appelle une défense. Formuler chaque question sur l'événement (« pourquoi la salle n'était-elle pas libre ? ») plutôt que sur l'individu (« pourquoi ne l'as-tu pas réservée ? ») change la nature des réponses. La sécurité psychologique d'une équipe se joue aussi dans ces détails de grammaire, de même que la peur que le statisticien W. Edwards Deming demandait de chasser fausse les réponses avant même qu'on les écrive.
L'arête de la main-d'œuvre
Sur le diagramme, l'arête des personnes attire les reproches. « Manque de rigueur » ou « erreur de saisie » s'y écrivent vite et ferment la discussion. Derby et Larsen signalent d'ailleurs que la catégorie autrefois appelée main-d'œuvre est devenue « Staffing », les effectifs. Une cause notée sur cette arête gagne à être reformulée en condition de travail. Une erreur de saisie devient un formulaire qui permet l'erreur, une charge qui empêche la relecture, une compétence jamais transmise.
La chaîne unique
Les cinq pourquoi suivent une seule réponse à chaque étage, alors qu'un problème réel en a souvent plusieurs. Le groupe retient la première explication plausible et ne voit plus les autres. Faire produire plusieurs réponses au premier pourquoi, puis suivre les deux plus solides, limite ce rétrécissement. Le diagramme corrige le même défaut par construction.
Le diagramme pris pour le résultat
Un poisson couvert de notes donne une impression de travail accompli. Derby et Larsen préviennent qu'un diagramme entièrement ramifié n'est pas le livrable d'une rétrospective. Elles ajoutent une précaution sur l'énergie du groupe. Quand l'essentiel des causes échappe au contrôle de l'équipe, les fouiller toutes la vide de son élan et mieux vaut choisir une autre activité. Ce critère vaut pour une rétrospective. Pour un diagnostic qui remontera à la direction, au contraire, nommer une cause qu'on ne maîtrise pas reste utile, à condition de dire qui peut agir dessus.
Ces outils conviennent mal aux tensions relationnelles. Chercher la cause d'un conflit entre deux personnes conduit souvent à l'une d'elles. Pour ce type de situation, l'approche orientée solution part de ce qui fonctionne déjà et laisse de côté l'archéologie des causes. Quand une cause est connue de tous sans jamais être dite, le problème relève souvent des routines défensives par lesquelles une organisation contourne ce qui la gêne. Un schéma les fait rarement parler à lui seul.
Que faire une fois la cause trouvée ?
Il faut agir sur elle puis empêcher qu'elle revienne. Une analyse qui s'arrête au constat laisse l'équipe avec une explication de plus et un problème intact.
Imai range cette suite dans les cinq règles d'or du management du terrain qu'il décrit dans Gemba Kaizen. Aller d'abord sur le lieu du problème, examiner l'objet concerné, prendre une contre-mesure provisoire sur place, trouver la cause racine, puis standardiser pour empêcher la récidive. Les cinq pourquoi et le diagramme occupent la quatrième marche. Les trois premières leur fournissent des faits, la dernière les rend utiles.
Dans une équipe de bureau, standardiser revient souvent à modifier une liste de préparation, une règle de réunion ou une définition de ce qui est terminé. L'équipe de l'exemple de Derby et Larsen conclut qu'elle pourrait ajouter la réservation de salle à la liste de préparation de ses revues. Faute de cette descente, écrit Ohno, on se contente de remplacer le fusible et la panne revient quelques mois plus tard. Ce geste de standardisation inscrit ces outils dans le kaizen, l'amélioration continue par petits pas, où chaque problème résolu devient le nouveau point de départ.
Ishikawa lui-même invitait à garder un doute sur les chiffres. Imai rapporte son conseil de parler avec des faits et des données, puis de douter des données qu'on voit. Une cause trouvée en salle reste une hypothèse tant que l'équipe ne l'a pas vérifiée là où le travail se fait. Le diagnostic sert aussi contre les biais cognitifs qui faussent les décisions, à condition de confronter la cause retenue aux faits avant de la graver dans un standard.
D'où je parle
J'accompagne des équipes, des managers et des CODIR depuis 2012, dans une carrière commencée en 1998 dont quatorze ans à manager des équipes. Je suis aussi formateur certifié en Intervention Orientée Solution, une approche qui travaille à partir des ressources déjà présentes dans l'équipe. Les deux familles d'outils se complètent, l'analyse causale pour un processus qui produit le même défaut, la recherche de solutions pour ce qui se joue entre les personnes.
Questions fréquentes
Le chiffre indique un ordre de grandeur. Il oblige à dépasser les premières réponses, celles qui décrivent l'incident. Certaines chaînes atteignent une condition utile au troisième pourquoi, d'autres en demandent davantage. Derby et Larsen font noter ce qui sort du quatrième ou du cinquième.
Les familles industrielles (matières, machines, main-d'œuvre, mesures, méthodes) s'adaptent mal à un service ou à une équipe projet. Derby et Larsen proposent lieu, procédure, personnes et politiques, ou environnement, fournisseurs, systèmes et compétences. L'équipe peut aussi définir ses propres familles avant de commencer.
Non. Taiichi Ohno décrit les cinq pourquoi comme une pratique de Toyota, adaptée selon lui de l'habitude d'observer de Sakichi Toyoda. Le diagramme causes-effets porte le nom de Kaoru Ishikawa, à qui Masaaki Imai en attribue le développement. Les deux outils ont été réunis par la pratique.
En posant chaque question sur un fait plutôt que sur une personne, en réunissant tous ceux que le problème a touchés et en reformulant toute cause individuelle en condition de travail. Eric Ries demande aux personnes les plus haut placées de rappeler qu'une erreur facile à commettre engage d'abord l'organisation.
Oui. Agile Retrospectives les classe dans la phase où l'équipe cherche à comprendre pourquoi les choses se sont passées ainsi, avant de décider quoi faire. Les cinq pourquoi tiennent dans une rétrospective d'itération, le diagramme demande une rétrospective plus longue.
Par la dernière occurrence, datée et décrite sans cause ni solution. Lancez ensuite un quart d'heure de cinq pourquoi en binômes sur ce fait précis, puis comparez les chaînes. Si elles divergent, passez au diagramme. Pour choisir l'outil adapté à votre contexte, réservons un échange de 30 minutes.
Le même problème revient dans votre équipe ?
Que vous soyez dirigeant, manager ou DRH, un premier échange permet de distinguer ce qui relève d'une analyse de cause de ce qui se joue entre les personnes avant de choisir une démarche.
Réserver un échange découverte (30 min)Allez plus loin
- Toyota Production System, Beyond Large-Scale Production La source primaire des cinq pourquoi, avec l'exemple de la machine arrêtée et la formule cinq pourquoi pour un comment. Voir le livre →
- Gemba Kaizen Le kaizen pratiqué sur le terrain, ses cinq règles d'or et le diagramme d'Ishikawa parmi les outils de résolution de problème. Voir le livre →
- Kaizen, la clé de la compétitivité japonaise Une amélioration continue et graduelle impliquant tout le monde, avec les apports d'Ishikawa et d'Ohno crédités nommément. Voir le livre →
- Agile Retrospectives, Making Good Teams Great Des activités de rétrospective décrites pas à pas, parmi lesquelles les cinq pourquoi et le diagramme en arêtes de poisson. Voir le livre →
- Lean Startup L'entrepreneuriat comme une forme de management, avec une version des cinq pourquoi proportionnée au symptôme. Voir le livre →
Liens affiliés
