Diagramme d'Ishikawa : Un guide

Grâce au diagramme d’Ishikawa, les ingénieurs peuvent mieux comprendre les défauts des processus de fabrication. Mais aujourd’hui, de nombreux spécialistes du marketing utilisent le diagramme d’Ishikawa pour analyser des situations complexes et trouver la solution la plus efficace pour leur entreprise.

Quand l’utiliser ?

Les diagrammes d’Ishikawa peuvent être utiles dans toute situation où il est nécessaire d’analyser des problèmes complexes ou d’identifier les causes des problèmes dans un système. Les équipes les utilisent souvent dans la fabrication, le marketing, le développement de produits et d’autres domaines qui impliquent de travailler avec des personnes, des processus et des procédures. Voici quelques situations courantes dans lesquelles les diagrammes d’Ishikawa peuvent être utiles :

• Lors de l’identification des causes profondes d’un problème
• Lors d’un brainstorming pour trouver des solutions à un problème
• Lors du développement ou de l’amélioration d’un processus
• Lors de l’analyse des données provenant d’enquêtes auprès des clients
• Lors de l’évaluation des résultats d’une campagne de marketing
• Lors du dépannage d’un problème avec un produit ou un service
• Lorsque la planification de projets ou initiatives futurs

Avantages

Les diagrammes d’Ishikawa présentent plusieurs avantages, notamment :

1. Ils aident à identifier les causes profondes des problèmes.
2. Ils aident les membres de l’équipe à communiquer et à partager des idées plus efficacement.
3. Ils permettent aux équipes d’organiser visuellement des informations complexes.
4. Ils peuvent être utilisés pour trouver des solutions à des problèmes.
5. Ils permettent aux équipes de suivre les progrès et de planifier les actions futures.

Inconvénients

Les diagrammes d’Ishikawa présentent quelques inconvénients à prendre en compte, notamment :

1. Leur création peut prendre beaucoup de temps.
2. Ils peuvent être difficiles à interpréter s’ils ne sont pas bien conçus.
3. Ils peuvent être biaisés ou incomplets si les membres de l’équipe ne participent pas activement au processus d’analyse.
4. Il peut y avoir un risque de se concentrer trop fortement sur les facteurs individuels au lieu de considérer comment ils pourraient interagir les uns avec les autres.
5. Elles peuvent être difficiles à appliquer dans des situations où de multiples facteurs interdépendants sont impliqués.

Quels sont les 6M du diagramme d’Ishikawa ?

Les 6M du diagramme d’Ishikawa sont des facteurs critiques utilisés pour identifier et analyser les problèmes d’un système. Ces facteurs sont les suivants :

1. Matériel – Il s’agit de tout composant physique ou non physique du système, y compris les personnes, les ressources et les outils.
2. Méthode/Processus – Il s’agit des méthodes et des procédures utilisées pour produire ou fournir le produit ou le service.
3. Machine – Il s’agit des machines et des équipements utilisés pour créer ou fournir le produit ou le service.
4. Mesure – Il s’agit des outils et des méthodes utilisés pour mesurer les progrès et les performances.
5. Main-d’œuvre – Il s’agit des personnes impliquées dans la production ou la livraison du produit ou du service.
6. Mère Nature (environnement) – Il s’agit des facteurs externes qui affectent le système, notamment la météo, la géographie et la réglementation.

Le processus de réalisation d’un diagramme d’Ishikawa

Pour générer un diagramme Ishikawa, il y a quelques étapes à suivre :

Étape 1 : Définir le problème

Commencez par définir clairement le problème que vous essayez de résoudre à l’aide de votre diagramme en arête de poisson. Il peut s’agir d’un problème de qualité, du mécontentement des employés ou de tout autre problème que vous souhaitez comprendre et améliorer. Vous pouvez utiliser des listes de contrôle sur papier ou des feuilles de calcul pour définir les problèmes ou utiliser des outils spécifiques tels qu’SafetyCulture (iAuditor) pour capturer et organiser vos données spécifiques.

Conseils pour la définition des problèmes :

• Soyez aussi précis que possible lorsque vous définissez votre problème. Il sera plus facile d’identifier les causes profondes par la suite.
• Assurez-vous que tous les membres de votre équipe comprennent le problème de la même manière. Utilisez un énoncé du problème pour vous assurer que tout le monde est sur la même longueur d’onde.

Étape 2 : Décider des principales catégories de causes

En classant les causes potentielles dans différentes catégories, il est plus facile d’identifier les causes profondes par la suite. Vous pouvez utiliser les 6M comme point de départ pour vous aider à choisir les types de clés.

Étape 3 : Identifier les causes possibles dans chaque catégorie

Une fois que vous avez déterminé vos catégories clés, vous pouvez commencer à réfléchir aux causes possibles pour chacune d’entre elles. Considérez tous les facteurs qui pourraient affecter votre processus ou votre produit et notez-les comme des causes potentielles. Vous trouverez ci-dessous un exemple de causes possibles dans chaque catégorie en utilisant les 6M (Matériel, Méthode, Machine, Mesure, Main-d’oeuvre et Mère Nature).

Étape 4 : Trier et hiérarchiser les causes potentielles

Une fois que vous avez une liste de causes possibles, il est utile de les trier et de les classer par ordre de priorité en fonction de leur probabilité d’être des causes profondes. Cela vous aidera à concentrer vos efforts sur les raisons les plus probables.

Il existe plusieurs outils de gestion de la qualité que vous pouvez utiliser pour trier et classer par ordre de priorité les causes potentielles ; en voici quelques-uns :

• Les 5 pourquoi : Cette technique peut être utilisée pour aller jusqu’à la cause profonde en demandant cinq fois « pourquoi ».
• Analyse Pareto : Cette technique peut vous aider à hiérarchiser les causes potentielles en identifiant les plus courantes.
• Analyse des modes de défaillance et de leurs effets (AMDE) : Cet outil d’analyse des risques peut vous aider à hiérarchiser les causes possibles en fonction de leur impact potentiel.

Étape 5 : tester les causes potentielles

Après avoir trié et hiérarchisé vos causes potentielles, il est temps de commencer à les tester pour voir s’il s’agit de causes profondes. La recherche des causes possibles peut s’effectuer de plusieurs manières :

Option A : Carte de processus

En partant du problème principal, vous pouvez créer une carte des processus pour tester différentes causes potentielles. En utilisant une carte des processus, vous pouvez identifier les lacunes de votre système qui peuvent conduire à la cause profonde de votre problème.

Option B : Remue-méninges

Vous pouvez également utiliser des techniques de remue-méninges pour identifier les solutions potentielles qui pourraient s’attaquer à la cause profonde de votre problème. C’est un excellent moyen d’obtenir la contribution des différents membres de l’équipe et des parties prenantes.

Exemple de diagramme en arête de poisson

Vous trouverez ci-dessous un exemple de diagramme en arête de poisson pour une entreprise de industrie. Dans ce scénario, l’entreprise utilise les 6M pour mieux comprendre les causes du problème, qui est qu’un une partie du produit n’est pas dans la bonne taille.

Le problème est énoncé à droite, les causes possibles du problème étant énumérées dans les côtes sous chaque catégorie de 6Ms.

Analyse des causes profondes facilitée pour les équipes distantes

L’un des principaux défis auxquels les équipes à distance sont confrontées lorsqu’elles effectuent une analyse des causes profondes est de coordonner et de communiquer efficacement. Cela peut être difficile, surtout si les membres de l’équipe sont répartis sur différents fuseaux horaires.

Un autre défi consiste à s’assurer que les tâches ou les suivis sont attribués à la bonne personne ou équipe. Dans une configuration à distance, il est facile d’oublier qui est responsable de quoi et de suivre les tâches qui ne sont pas attribuées immédiatement. Cependant, il existe des outils comme SafetyCulture (anciennement iAuditor) qui peut vous aider à résoudre ce problème.

 

SafetyCulture (anciennement iAuditor)