Diagramme d'Ishikawa

Définition, contenu et origine

Définition : le diagramme d'Ishikawa, également connu sous les noms de diagramme en épi, diagramme de Herringbone, diagramme de cause à effet ou Fishikawa, est un diagramme causal développé par Kaoru Ishikawa. Il sert à représenter systématiquement les causes potentielles d'un événement donné. Ishikawa a introduit cette méthode en 1968.

Contenu et origine : le diagramme est une forme de représentation visuelle qui permet une analyse structurée des problèmes en montrant toutes les causes possibles de manière ordonnée. Développé à l'origine dans le cadre de la gestion de la qualité au Japon, il est aujourd'hui utilisé dans le monde entier dans différents secteurs pour aider à analyser les causes et à trouver des solutions aux problèmes.

Objectifs et utilité

Objectifs :

• Déterminer systématiquement le plus grand nombre possible de causes d'un problème afin d'éviter les conclusions hâtives et prématurées.

• Représentation structurée et visuelle des causes définies afin de permettre une meilleure compréhension et une analyse complète.

Bénéfices :

• Favoriser une compréhension plus approfondie des causes d'un problème grâce au travail d'équipe et à la discussion.

• Augmentation de la probabilité d'identifier les véritables causes d'un problème.

• Aide à l'élaboration d'actions ciblées pour résoudre le problème.

• Amélioration de la communication et de la collaboration au sein de l'équipe grâce à la création et à l'analyse communes du diagramme.

Application et procédure

Application : un diagramme d'Ishikawa est utilisé pour analyser les causes d'un problème dans différents domaines. Il peut être utilisé dans la production, les services, la santé et bien d'autres domaines.

Procédure à suivre :

1. Mise en place de l'équipe : constitution d'une équipe pluridisciplinaire.

1. Définition du problème : formulation précise du problème à analyser.

1. Identifier les principales catégories : Détermination des principales catégories de causes possibles, telles que les matériaux, les méthodes, les personnes, les machines, l'environnement et la mesure.

1. Collecte d'idées : brainstorming et collecte des causes possibles attribuées aux catégories principales.

1. Identification des sous-causes : Analyse détaillée par un questionnement répété (« Pourquoi cela se produit-il ? ») pour identifier les sous-causes.

1. Visualisation : création du diagramme d'Ishikawa pour une représentation ordonnée de toutes les causes et sous-causes.

1. Évaluation et mesures à prendre : Évaluation des causes, identification des causes les plus importantes et définition de mesures ciblées pour résoudre le problème.

Exemple d'application

Contexte

Une entreprise de développement de logiciels rencontre des problèmes récurrents liés au nombre élevé d'erreurs logicielles (bugs) dans ses applications. Ces bugs entraînent des retards dans la mise sur le marché, une augmentation des coûts de support et l'insatisfaction des clients. Malgré plusieurs phases de test et de révision du code, de nombreux bugs continuent à être découverts dans l'environnement de production.

Procédure

Mise en place de l'équipe :

• Une équipe multidisciplinaire a été constituée, composée de développeurs de logiciels, de testeurs, de chefs de projet et de spécialistes de l'assurance qualité. L'objectif était d'inclure toutes les perspectives pertinentes.

Définition du problème :

• Le problème a été défini comme « un nombre élevé d'erreurs logicielles dans l'environnement de production ». Cette définition a été formulée de manière précise afin de garantir une compréhension commune.

Principales catégories de causes :

• Les principales catégories ont été définies sur la base des causes typiques du processus de développement logiciel :

• Matériels (outils et technologies) : Outils de développement manquants ou insuffisants, technologies obsolètes.

• Méthodes : Processus de développement inefficaces, méthodes de test insuffisantes.

• Personnes : Manque d'expérience ou de formation des développeurs, problèmes de communication au sein de l'équipe.

• Machines (infrastructure) : Matériel informatique insuffisant, problèmes de réseau.

• Environnement : exigences imprécises, changements dans les spécifications du projet.

• Mesure : contrôles de qualité insuffisants, manque de métriques pour l'analyse des erreurs.

Collecte d'idées :

• L'équipe a recueilli les causes possibles des erreurs logicielles et les a classées dans les principales catégories. Cela s'est fait par des séances de brainstorming et des discussions.

Identifier les sous-causes :

• Pour chaque cause principale, des sous-causes ont été identifiées en posant la question « Pourquoi cela se produit-il ? Ces sous-causes ont été placées sur des axes latéraux plus petits dans le diagramme d'Ishikawa.

Diagrammes complémentaires :

• Pour les domaines particulièrement complexes, des diagrammes d'Ishikawa supplémentaires ont été créés afin de permettre une analyse détaillée.

Évaluation et mesures :

• La probabilité d'occurrence de chaque cause a été évaluée conjointement. Les causes probables vérifiées par des données ou un consensus d'équipe ont été marquées en vert. Les causes exclues en rouge et les causes à confirmer en orange.

• Sur la base de cette analyse, des mesures ciblées ont été définies pour réduire les erreurs, comme par exemple l'introduction de nouvelles méthodes de test, la formation des développeurs et l'amélioration de l'infrastructure de développement.

Résultat

• Réduction des erreurs : la mise en œuvre des mesures identifiées a entraîné une réduction significative de 70% des erreurs logicielles.

• Amélioration des processus : La révision des processus de développement et de test a débouché sur des procédures plus efficaces et une meilleure assurance qualité.

• Développement des collaborateurs : des programmes de formation ciblés ont permis d'augmenter les compétences des développeurs, ce qui a eu un effet positif sur le nombre d'erreurs.

• Satisfaction des clients : la réduction du nombre d'erreurs a entraîné une augmentation de la satisfaction des clients et une diminution des demandes d'assistance.

Références

• Ishikawa, K. (1968). Guide du contrôle de la qualité. Tokyo : Asian Productivity Organization.

• Juran, J. M. (1988). Juran's Quality Control Handbook. McGraw-Hill.

• Tague, N. R. (2005). La boîte à outils de la qualité. ASQ Quality Press.

• Basu, R. (2004). Implementing Quality : A Practical Guide to Tools and Techniques. Thomson Learning.

• ChatGPT : Excellence de la gestion de la qualité