La technique des 5 pourquoi : Bases, exemples et conseils

Quand vous êtes confronté à un problème persistant ou récurrent, que faites-vous ?

Il existe 2 solutions – Essayer simplement de résoudre le problème et passer à autre chose Ou enquêter et analyser pour voir quelle est la véritable source du problème afin qu’il ne refasse pas surface. 5 Whys, est une technique éprouvée et largement utilisée pour  » l’analyse des causes profondes  » qui permet d’identifier la ou les causes contribuant à l’apparition du problème.

Cet article vous fait découvrir l’histoire des 5 Whys, ses bases et ses exemples, la procédure correcte pour mener une analyse 5 Whys et quelques conseils & de bonnes pratiques sur les 5 Whys.

Histoire des 5 Whys

La technique des 5 Whys a été inventée à l’origine par Sakichi Toyoda, le fondateur de Toyota Industries Co. et père de la révolution industrielle japonaise.

Toutefois, le mérite d’avoir amené les 5 pourquoi à une mise en œuvre généralisée revient à Taiichi Ohno, pionnier du système de production Toyota.

Selon le site Web de l’entreprise Toyota:

Quand un problème surgissait, Taiichi Ohno encourageait son personnel à explorer les problèmes de première main jusqu’à ce que les causes profondes soient trouvées. « Observez l’atelier de production sans idées préconçues », conseillait-il. « Demandez ‘pourquoi’ cinq fois à propos de chaque question. »

Toyota croit en l’approche ‘aller voir et clarifier’. Lorsqu’un problème survient avec une machine de fabrication, la solution n’est pas trouvée en regardant certaines données historiques ou un manuel. Une déduction est faite en comprenant le problème, en posant des questions aux personnes qui y travaillent, en inspectant et en prenant ensuite une décision.

La mise en œuvre continue de pratiques comme les 5 pourquoi a fait de Toyota le plus grand constructeur automobile du monde.

Les principes de base des 5 Whys

L’une des principales raisons pour lesquelles les 5 Whys sont si populaires en tant que technique d’analyse des causes profondes est sa simplicité.

Lorsqu’un problème ou une question survient, il suffit de demander « Pourquoi le problème est-il survenu ? » (au moins) 5 fois aux personnes qui y travaillent. C’est tout. Il n’y a pas d’étapes fantaisistes pas d’acronymes et il n’y a pas besoin d’une quelconque mémorisation.

5 Whys fonctionne sur la prémisse que « Chaque problème a une cause derrière lui mais une analyse superficielle ne dépeindra que les symptômes. Une enquête persistante est nécessaire pour trouver la cause réelle (la cause profonde) derrière le problème afin que des solutions durables puissent être prises et que le problème ne refasse pas surface. »

Par exemple – Considérons que Jack est malade avec des nausées et va chez le médecin tout en s’attendant à obtenir des médicaments pour traiter les nausées. Cependant, la nausée n’est qu’un « symptôme » du problème et le traiter ne signifie pas que nous traitons la véritable cause de la nausée. Les investigations du médecin révèlent qu’il a également mal au ventre et un diagnostic plus poussé confirme que Jack souffre  » en réalité  » d’une infection de l’estomac.

Donc, ce qui semblait être un problème n’était qu’un  » symptôme  » d’un problème réel et si Jack avait traité uniquement ses nausées sans aller chez le médecin, elles auraient refait surface. (Une autre leçon ici – n’essayez pas d’être un médecin quand vous ne l’êtes pas 😉 )

Comprendre les 5 Pourquoi avec des exemples

Pour utiliser efficacement les 5 Pourquoi, il faut avoir un  » regard interrogatif  » sur les problèmes et ne pas les prendre au premier degré.

Exemple 1 : Prenons un exemple dans le domaine de la fabrication.

Énoncé du problème : La bande transporteuse de la ligne de production principale s’est arrêtée

1. Pourquoi le tapis roulant s’est-il arrêté ?
La poulie principale responsable de la rotation du tapis ne fonctionne pas

2. Pourquoi la poulie principale ne tourne-t-elle pas ?
Parce qu’elle ne reçoit pas assez de puissance du moteur

3. Pourquoi ne reçoit-elle pas assez de puissance du moteur ?
Parce que le moteur a cessé de fonctionner

4. Pourquoi le moteur a-t-il cessé de fonctionner ?
Les enroulements du moteur avaient brûlé

5. Pourquoi les enroulements ont-ils brûlé ?
Le moteur était chargé au-delà de sa capacité de puissance

6. Pourquoi le moteur a-t-il été surchargé ?
Bien qu’il y ait des spécifications sur la fréquence de charge autorisée toutes les heures, il n’y avait pas d’instructions sur le poids maximal de la charge.

Cause fondamentale : Donc vous voyez, nous avons eu besoin de 6 pourquoi pour finalement déchiffrer que le poids de la charge sur le moteur était supérieur à sa capacité et maintenant nous devons soit remplacer le moteur par un moteur plus puissant, soit restreindre le poids de charge maximal autorisé sur le tapis roulant à la fois.

Exemple 2 : Voici un autre exemple de notre industrie des technologies de l’information (TI).

Énoncé du problème : Pendant le temps des tests d’acceptation par l’utilisateur (UAT), un problème est observé par le client

1. Pourquoi le problème a été rencontré par le client
Selon le responsable technique, l’équipe de test n’a pas signalé un tel problème à l’équipe de développement

2. Pourquoi l’équipe de test n’a pas pu attraper le problème
L’équipe de test a effectué uniquement des tests de sanité et non des tests de régression complets

3. Pourquoi l’équipe de test n’a effectué que des tests de sanité
Parce qu’elle n’avait pas assez de temps pour effectuer un test fonctionnel approfondi de l’application complète

4. Pourquoi il n’y avait pas assez de temps pour un test fonctionnel approfondi
Parce que le build est arrivé seulement un jour avant les délais de l’UAT et que les tests fonctionnels approfondis prennent au moins 3 jours

5. Pourquoi le build n’a-t-il été donné qu’un jour avant l’UAT ?
Parce que l’équipe de développement a pris plus que le temps estimé pour résoudre certains bugs.

Dans cet exemple, nous voyons qu’il y a 2 causes racines plutôt qu’une seule :

Première cause racine : Les membres de l’équipe ne sont pas en mesure de donner des estimations correctes autour de leurs fonctionnalités et il y a un besoin de formation sur les techniques d’estimation et leur mise en œuvre.

Deuxième cause fondamentale : Il y a un problème avec la gestion du projet car idéalement, un gel de code devrait se produire au moins 4 jours avant l’UAT mais ici l’équipe travaillait à la correction des bugs jusqu’au tout dernier jour.

Procédure pour mener une analyse 5 Whys

Voici les étapes clés du processus global pour mener une analyse 5 Whys approfondie :

Etape 1 – Rassembler les membres de l’équipe concernés

Lorsque vous êtes confronté à un problème, la première étape logique est de rassembler les membres de l’équipe concernés. Il s’agit des personnes qui travaillent sur l’équipement, le processus ou le projet qui fait face au problème et qui ont rencontré le problème de première main.

Dans notre exemple de fabrication ci-dessus, l’opérateur de la bande transporteuse, l’ingénieur de soutien, le responsable de l’équipe et l’électricien devraient être les membres pertinents.

De même, dans l’exemple informatique ci-dessus, l’analyste commercial, le responsable technique, le responsable des tests et les développeurs travaillant sur les correctifs devraient être les membres pertinents.

La raison pour laquelle il faut réunir chaque membre pertinent est d’obtenir un point de vue différent du problème en question. Chaque membre a sa propre façon de voir le problème et écouter les récits de toutes les personnes associées au problème donne une vue à 360 degrés – quelque chose de très important lorsqu’on cherche la cause profonde.

Un  » modérateur  » ou un  » facilitateur  » de réunion peut même être désigné pour recueillir et analyser tous les résultats dans le cas d’une grande équipe.

Etape 2 – Définir l’énoncé du problème

Une fois l’équipe disponible, il est temps de définir le problème réel. La portée du problème ne doit pas être trop grande ou vous pourriez finir par avoir beaucoup de causes profondes et elle ne doit pas être trop étroite non plus car vous pourriez finir par traiter un autre symptôme.

L’énoncé du problème doit être équilibré et bref tout en donnant une explication claire du problème rencontré.

En prenant l’exemple ci-dessus de la bande transporteuse, vous ne devriez pas prendre  » le retard dans le traitement des marchandises  » comme énoncé du problème car il sera trop large de la portée et aussi vous ne devriez pas prendre  » la panne du moteur  » comme la portée car il sera trop étroit.

Lorsque vous définissez le problème, vous pouvez vouloir que les membres individuels définissent ce qu’ils pensent être le problème et fassent une liste de leurs réponses. Ces réponses peuvent ensuite être discutées pour parvenir à un consensus sur l’énoncé du problème.

Étape 3 – Demander pourquoi ?

Cette étape vous invite à demander aux membres de votre équipe pourquoi l’énoncé du problème s’est produit et à noter leurs réponses.

Puis, demandez  » Pourquoi  » leurs réponses se sont produites.

Répéter. Au moins 4 fois de plus.

À chaque étape, la réponse doit être notée et doit constituer la base du  » Pourquoi  » suivant. Puisque la technique des 5 pourquoi dépend de la relation de  » cause à effet « , il est impératif de s’assurer que la réponse à chaque  » Pourquoi  » est une réponse logique qui s’appuie sur une preuve.

Si vous vous demandez pourquoi nous devons répéter le processus de demander Pourquoi au moins 5 fois, voici la réponse – Demander un pourquoi une ou deux fois équivaut à juste gratter la surface du problème et à traiter les symptômes initiaux avec le problème de refaire surface plus tôt. En essayant diligemment de sonder la raison derrière chacune des réponses, vous dépasserez toutes les suppositions ou spéculations autour du problème et vous dirigerez vers la question réelle.

Le  » modérateur  » ou  » facilitateur  » doit veiller à ne pas se fier aux réponses émotionnelles des participants mais se concentrer sur les réponses qui sont soutenues par des faits.

Par exemple, dans l’exemple informatique ci-dessus, en se fiant uniquement à la parole du responsable technique, il semblait que l’équipe de test soit entièrement fautive de ne pas avoir pu trouver le bug. Cependant, un sondage plus approfondi met au jour le problème réel de la gestion de projet et des compétences d’estimation de l’équipe.

Une fois que la cause première réelle est déterrée, il faut alors en discuter séparément pour trouver les actions correctives et les contre-mesures afin de s’assurer que les problèmes sont finalement abordés et ne se reproduiront plus.

Avantages de la technique des 5 pourquoi

  • Encourage la résolution collaborative des problèmes
  • Inculque les sentiments d’ouverture au sein de l’équipe car le point de vue de chacun des membres est pris en compte
  • Simple, facile à suivre sans nécessiter d’analyse statistique ou d’outils supplémentaires
  • Aide à atteindre un consensus à l’amiable sur les domaines présentant des problèmes plutôt que de chercher des fautes ou de blâmer des individus

Limites de la technique des 5 pourquoi

  • Les 5 pourquoi est une technique qui prend du temps et qui implique des sondages profonds.consommatrice de temps et implique un approfondissement et une évaluation approfondie de tous les faits
  • Les 5 Pourquoi ne peuvent pas être effectués de manière isolée et nécessitent la disponibilité des membres de l’équipe associés
  • Parfois, il n’est pas possible d’isoler une seule cause profonde par le biais de cette technique
  • Les facilitateurs doivent être suffisamment expérimentés pour être en mesure de poser la « bonne » question Pourquoi
  • Le succès de cette technique dépend de ses participants i.c’est-à-dire que si des personnes ne sont pas disponibles, le groupe restant peut ne pas être en mesure de trouver la bonne réponse à la question Pourquoi.

Technique des 5 Pourquoi – Conseils et meilleures pratiques

  1. Ne faites jamais la cause fondamentale seule car indépendamment, vous ne serez jamais en mesure d’atteindre le cœur même du problème
  2. Assurez-vous qu’il y a un consensus des membres de l’équipe tout en rédigeant l’énoncé du problème
  3. Ne vous arrêtez pas aux seuls 5 Pourquoi et essayez de voir si le problème peut encore être décomposé. Des problèmes plus complexes pourraient nécessiter des investigations plus poussées.
  4. La technique devrait également être utilisée en conjonction avec d’autres techniques où les conclusions des 5 Pourquoi peuvent être validées par des données quantitatives
  5. C’est le processus qui doit être évalué et non les personnes. Dépassez les erreurs des personnes et vous verrez les failles du processus (examinez l’exemple de l’informatique ci-dessus)

Wind-Up

5 Whys est une technique simple d’analyse des causes profondes qui est élémentaire mais immensément efficace. Si elle est réalisée avec le bon ensemble de participants, elle conduira à la découverte de processus et de procédures défectueux et permettra de s’attaquer aux causes réelles plutôt qu’aux simples symptômes.

Rappellez-vous – « Les gens n’échouent pas, les processus oui »

.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *