Diagramme d'Ishikawa

Le diagramme d'Ishikawa, aussi appelé diagramme en arêtes de poisson, permet de formaliser toutes les cause possibles d'un évènement, en les classant dans 5 catégories appelées 5M (méthodes, milieu, matières, main d'oeuvre et matériel).


 Pour un service qualité, il existe deux utilisations possible, que nous allons détailler.

1. Trouver les causes d'un défaut ponctuel (une réclamation qualité, par exemple)
Après avoir bien détaillé le défaut, il s'agit d'organiser un brainstorming, et de trouver toutes les causes possibles qui ont pu conduire à ce défaut. Après avoir parcouru les 5M, vous vous retrouvez avec une foule de causes possibles, dépendant de l'imagination des participants. Il s'agit ensuite d'éliminer toutes celles qui n'ont pas pu causer le défaut, pour mettre en avant les causes réelles, et les éradiquer.
C'est pour moi la mauvaise manière d'utiliser cet outil. En effet, le brainstorming va monopoliser du temps et des ressources, et va accoucher d'une foule de causes possibles, dont la majorité n'a rien à voir avec le défaut que vous devez traiter. Ce sera une perte de temps, qui nuira à votre réactivité et repoussera d'autant la mise en place d'actions correctives. Au final, vous vous retrouverez avec un diagramme des causes complet, mais dont vous ne vous resservirez sans doute plus jamais.
Dans ce type de situation, je conseillerai plutôt un 5 Why, qui est plus simple à mettre en œuvre et vous mènera plus rapidement aux causes du problème.

Capitaliser le retour d'expérience pour les défauts complexes et récurrents
Dans certains cas, les causes possibles d'un défaut font entrer en compte une multitude de critère. Le défaut réapparaît sans arrêt, parce qu'à chaque fois que vous avez traité une cause, un autre paramètre va dériver. C'est le cas par exemple, d'assemblage complexe, avec plusieurs composants et de nombreuses cotes, agissant toute sur un même paramètre de sortie.

Dans un cas comme celui-ci, vous ne pouvez pas recommencer une analyse à zéro à chaque fois que le défaut réapparaît, et on ne peut pas se contenter d'affirmer "Je pense que ça vient de ceci ou de celà parce que c'était la cause la semaine dernière". Le diagramme d'Ishikawa peut donc être une base solide de toutes les causes possibles pour un défaut complexe et récurrent. Une fois qu'il est construit, à chaque nouvelle dérive, il suffit de reprendre les causes une par une et des les éliminer jusqu'à ce qu'il ne restent que celles qui ont causé le défaut.  Et si on en trouve de nouvelles, on peut les ajouter au diagramme de façon à capitaliser l'information.
Dans ce type de situation, le diagramme en arête de poisson permet de gagner réellement du temps et de ne pas tourner en rond, en passant à coté de la cause du défaut, alors qu'on a déjà du y faire face plusieurs mois auparavant.

Pour aller plus loin, un livre écrit par Kaoru Ishikawa, qui détaille bon nombre d'outils qualité, illustrés avec des exemples pratiques, essentiels à ceux qui veulent se perfectionner dans ce domaine : 

 

Savoir utiliser le retour d'expérience

Il n'y a rien de plus irritant pour un client que de recevoir sans cesse des pièces présentant les même défauts. Il est donc essentiel de les éradiquer une fois pour toute.
Les outils d'analyse (5 why, arbres de défaillances, 8D) permettent de trouver les causes des défauts et de les éliminer, mais il s'agit aussi de ne pas les voir réapparaître sur un nouveau projet, ou à l'occasion d'un changement de fournisseur.  Avec les changements d'organisations et le turn over du personnel, une partie des informations non écrites peuvent se perdre. L'étape suivante consiste à pérenniser ces améliorations.

Il s'agit donc de créer un document très simple, qui permet de lister l'ensemble des défauts connus, et des actions correctives qui ont été mises en place, pour éliminer la cause d'occurrence du défaut et la cause de non détection. Il peut s'appliquer sur les produits que vous fabriquez et sur les composants que vous utilisez.

Pour vos produits, ce document doit être un des éléments entrant de votre AMDEC et du plan de surveillance. Pour les fournisseurs, il doit leur être envoyé dès le début du projets, qu'ils puissent eux aussi l'intégrer dans leurs analyses qualité. Il doit être complété, défaut par défaut, afin qu'on puisse constater que chaque item a bien été pris en compte et que les solutions apportées permettent d'éviter toute récurrence du défaut.

Complété à chaque apparition d'un nouveau défaut, il deviendra un support indispensable de toute organisation qualité, particulièrement utile lorsqu'il s'agira de justifier des contrôles ou des essais. Une exigence qualité ayant un coût, il faut pouvoir la motiver avec sérieux pour qu'elle soit prise en compte. Présenter une exigence en s'appuyant sur un défaut précis avec un bilan détaillé (apparu à telle date, ayant causé une réclamation client, vous ayant obligé à jeter X pièces...) a beaucoup plus d'impact qu'une vague rumeur d'un défaut dont on ne sait plus ce qu'étaient réellement les impacts.

Je vous propose un modèle de retour d'expérience, sur lequel vous pourrez vous appuyer pour créer le votre.

Le 5 Pourquoi ? (5 why ?)

Il s'agit d'un outil simple d'analyse d'un défaut. Il s'applique sur le cause d'occurrence du défaut (pourquoi on l'a créé) et sur la cause de non détection (pourquoi il n'a pas été écarté par les contrôles existants). La cause de non détection est souvent oublié, dans les faits, et c'est évidemment une erreur. Pour avoir une analyse complète, il faut traiter ces deux volets !

Pour l'appliquer, il suffit de décrire le défaut, de façon précise, et de se demander pourquoi il a été créé. Lorsqu'on a une cause, et se demande à nouveau pourquoi cette cause a pu apparaître, et ce 5 fois de suite. L'objectif de base est de ne pas se contenter de la cause la plus évidente, qui nous apparaît immédiatement (le 1er pourquoi), mais d'aller plus loin, jusqu'à la cause racine (le 5e pourquoi).

Prenons l'exemple d'une carte électronique, qui ne fonctionnerait pas. Au premier pourquoi, on va mettre en évidence qu'un composant électronique est non conforme. Si vous en restez là, vous changerez le composant, cette carte électronique fonctionnera, mais le problème peut ressurgir à tout moment. Il faut donc chercher la cause racine pour éradiquer définitivement le défaut. Le deuxième pourquoi met en évidence que le composant défectueux est brulé. Au final, on conclut que la cause racine est une reprise manuelle avec un fer à souder inadapté. En corrigeant ce problème, on supprime la cause racine et on éradique définitivement ce défaut.

Dans un 5 why simple, chaque "Pourquoi ?" apporte une seule réponse. Pour que l'outil prenne sa pleine ampleur, on peut lister l'ensemble des réponse possibles à chaque "Pourquoi ?", ce qui finit par créer un arbre de défaillance complet. On se retrouve alors avec diverses causes possibles, qu'il s'agit de vérifier une par une, et de classer par ordre d'importance, afin de traiter en premier les causes principales.

N'hésitez pas à aller voir cet exemple de "5 Pourquoi ?" !