Organigramme d'analyse des causes profondes (modèle d'arbre de décision)
Un organigramme d'analyse des causes profondes dessiné sous forme d'arbre de décision : neuf tests acheminent un problème vers 5 pourquoi, une arête de poisson, un arbre de défaillance, une escalade ou un arrêt documenté.
Qu'est-ce que le processus organigramme d'analyse des causes profondes (modèle d'arbre de décision) ?
Deux diagrammes différents sont appelés organigramme d’analyse des causes profondes. La première est une cartographie des processus : elle indique ce qui se passe ensuite et qui le fait, depuis le problème soulevé jusqu'au confinement, à la collecte de preuves, à l'analyse, à la vérification et au transfert vers l'action corrective. Celui-ci est l’organigramme du processus d’analyse des causes profondes chez /fr/templates/organigramme-du-processus-d-analyse-des-causes-profondes. Cette page est d'un autre type : un arbre de décision. Il répond quelle technique utiliser pour résoudre le problème qui vous est présenté et qui a le pouvoir de décider.
La distinction est importante car les techniques ne sont pas interchangeables. 5 Whys suit une chaîne causale unique et fonctionne lorsqu'une équipe possède cette chaîne de bout en bout. Un diagramme en arête de poisson, ou diagramme d'Ishikawa, répartit la recherche sur plusieurs catégories (méthode, machine, matériau, personnes, mesure, environnement) et convient aux problèmes où plusieurs facteurs se combinent de manière plausible. Un arbre de défaillances fonctionne à rebours à partir d'une défaillance définie en passant par la logique de la manière dont les composants et les conditions la produisent, qui associe les défaillances techniques à une spécification sur laquelle tester. Laissée indécise, la méthode par défaut est celle utilisée par l'animateur la dernière fois, et l'enquête hérite discrètement de l'angle mort de cet outil.
Le tableau ci-dessous comprend neuf questions et quatre points finaux, répartis sur quatre voies, indiquant qui répond à chaque question plutôt que qui fait le travail. Les questions vont de savoir si le problème est limité, en passant par si les preuves existent déjà et si elles sont suffisantes, jusqu'à savoir s'il s'agit d'un événement unique ou d'un schéma récurrent et si l'échec est technique, humain ou systémique. Les branches se terminent par quatre résultats nommés : une cause acceptée et un CAPA soulevé, une escalade vers une enquête formelle, un retour à la collecte de preuves et une clôture avec une limitation des données documentées. Rien ne renvoie à une voie heureuse, car une véritable enquête ne se termine pas toujours par une cause prouvée.
Ce que couvre cet organigramme
Dans ce modèle
- Quatre voies de droits de décision (propriétaire du processus, responsable de l'enquête, examinateur qualité et gestion) réparties en cinq étapes : définir le problème, vérifier les preuves, choisir la méthode, exécuter l'analyse et vérifier et décider.
- Deux portes d'entrée avant de choisir une technique : "Problème **clairement défini** ?" renvoie un Non pour limiter l'énoncé du problème et redemande, et « Des preuves déjà disponibles ? » fractionnements Disponible à partir de Doit rassembler donc la collecte est une étape plutôt qu'une hypothèse.
- Un "Données **suffisantes** pour analyser ?" gate appartenant au réviseur Qualité, dont la branche Insuffisante se termine par "Retour à la collecte de preuves" au lieu de permettre de sélectionner une méthode sur des données fines. Le test de suffisance est écrit sur le nœud sous forme de commentaire.
- Le sélecteur de méthode lui-même : « Événement unique ou récurrent ? envoie Récurrent directement sur une arête de poisson, et "Nature de l’échec ?" itinéraires techniques vers un arbre de défaillances, humains vers 5 pourquoi et systémiques vers une arête de poisson.
- Un « Vous avez atteint une cause contrôlable ? la vérification après les 5 pourquoi : le oui passe à la vérification, le non redirige le problème vers une arête de poisson plutôt que d'accepter une chaîne qui dépasse tout ce que l'organisation peut changer.
- La division finale : « Cause vérifiée par des preuves ? sépare Vérifié de l'hypothèse, « Plus de preuves peuvent être obtenues ? » soit revient à la collection, soit se termine avec une limitation de données documentée, et « Cause sous contrôle local ? » se termine par « Cause acceptée, CAPA soulevée » ou « Passer à une enquête formelle ».
Quand utiliser ce modèle
- Les enquêtes utilisent la technique que connaît l’animateur, et vous voulez que la méthode soit choisie en fonction du problème plutôt que par habitude.
- Vous rédigez ou révisez une RCA ou une procédure de gestion des problèmes et avez besoin que les règles de sélection de méthode soient enregistrées à côté des étapes du processus.
- Les équipes continuent d’exécuter 5 Pourquoi sur des problèmes multifactoriels et s’arrêtent à la première réponse qui semble plausible.
- Vous avez besoin d'une manière définie d'arrêter (une limitation de données documentée ou une escalade) au lieu d'une cause spéculative écrite pour fermer l'enregistrement.
- Vous souhaitez que le déclencheur de remontée d'information soit convenu à l'avance, afin que les causes liées à un fournisseur, à un autre site ou à une politique quittent l'équipe locale au lieu de rester en son sein.
Comment cela fonctionne
Renommez les voies en l'honneur de vos véritables décideurs
Les voies ici sont des droits de décision, pas des départements : propriétaire du processus, responsable de l'enquête, réviseur qualité, direction. Remplacez-les par des rôles qui répondent véritablement à chaque question de votre organisation et, dans la mesure du possible, séparez le responsable de l'enquête du propriétaire du processus. Une enquête menée par le responsable du processus tend à trancher sur des causes qu'il est facile d'énoncer.
Écrivez la règle d'énoncé du problème sur la première porte
"Problème clairement défini ?" ne fonctionne que si quelqu'un a dit ce que signifie défini. Le test habituel est que la déclaration indique ce qui a échoué, où, quand et à quelle fréquence, et ne mentionne aucune cause. Une instruction qui contient déjà la cause (le plus souvent une version de l'erreur de l'opérateur) transforme le reste de l'arborescence en un exercice de confirmation.
Définir le seuil de suffisance sur la porte de données
Décidez quelles « Données suffisantes pour analyser ? » requiert avant d’en avoir besoin : une chronologie qui peut être reconstruite, des échantillons ou des journaux conservés encore à l’intérieur de leur fenêtre de conservation, et au moins un compte rendu de première main. Signalez les articles périssables, car ceux-ci déterminent la rapidité avec laquelle la collecte doit avoir lieu. Sans seuil écrit, la branche Insuffisant n'est jamais prise et la méthode est choisie en fonction de ce qui se trouve à portée de main.
Fixez vos propres règles de sélection de méthode
Le routage dans ce tableau (récurrent vers une arête de poisson, technique vers un arbre de défaillances, humain vers 5 pourquoi, systémique vers une arête de poisson) est un défaut défendable, pas une loi. Adaptez-le aux techniques auxquelles vos collaborateurs sont réellement formés et ajoutez celles que vous utilisez, comme l'analyse du changement ou l'analyse des obstacles. Ce qui compte, c'est que la règle existe et soit visible sur le diagramme, afin que le choix puisse être contesté lors de la révision.
Définir la règle d’arrêt des 5 Pourquoi et la voie à suivre
« Atteint une cause contrôlable ? » est le nœud qui empêche les 5 pourquoi de se heurter à la météo ou à l’économie. Arrêtez-vous à la dernière raison pour laquelle votre organisation peut changer. Si la chaîne s'épuise avant cela, ou se divise en plusieurs réponses plausibles, le problème est multifactoriel et la branche Non la déplace sur une arête de poisson plutôt que de laisser passer une fine chaîne.
Acceptez le déclencheur d'escalade et conservez la version des deux diagrammes.
Notez quelles sont les forces « Cause sous contrôle local ? » à l'agence locale Beyond : causes appartenant à un autre site, à un fournisseur ou à une politique que cette équipe ne peut pas modifier ; événements à signaler à un régulateur ou à un client ; tout ce qui concerne la sécurité ou le produit déjà expédié. Liez ensuite cet arbre de décision à l'organigramme du processus d'analyse des causes profondes de bout en bout, et conservez les deux sous contrôle de version avec leurs approbations capturées, afin que les enquêteurs et les réviseurs travaillent à partir de la même version autorisée.
Questions fréquentes
Un organigramme d'analyse des causes profondes est-il une cartographie des processus ou un arbre de décision ?
Cela peut être l’un ou l’autre, et les deux répondent à des questions différentes. Une cartographie des processus répond à ce qui se passe ensuite et à qui le fait : soulever le problème, le contenir, collecter des preuves, analyser, vérifier, transmettre au CAPA. Un arbre de décision (cette page) répond quelle technique appliquer et qui décide, et ses branches aboutissent à des résultats différents plutôt que de converger sur un seul chemin. La plupart des organisations ont besoin des deux : le schéma de processus pour la procédure, l'arbre de décision pour les appels à jugement qu'il contient. Si vous souhaitez un flux de bout en bout, utilisez l'organigramme du processus d'analyse des causes profondes sur /fr/templates/organigramme-du-processus-d-analyse-des-causes-profondes.
Comment choisir entre 5 Pourquoi, une arête de poisson et un arbre de défauts ?
Par la forme du problème, ce que testent les deux décisions méthodologiques présentées dans ce graphique. 5 Pourquoi convient à une chaîne causale unique appartenant à une équipe, où chaque réponse devient la question suivante. Un diagramme en arête de poisson, ou diagramme d'Ishikawa, convient à un problème où plusieurs catégories peuvent être impliquées (méthode, machine, matériau, personnes, mesure, environnement) car il force l'équipe à dépasser la première branche plausible. Un arbre de défaillances convient à une défaillance technique avec un événement principal définissable et des composants dont vous pouvez parcourir la logique de défaillance en revenant en arrière. Un modèle récurrent mérite presque toujours une arête de poisson en premier, car la récurrence signifie généralement des conditions plutôt qu'une chaîne ponctuelle. De nombreuses enquêtes en utilisent deux : générer des candidats sur une arête de poisson, puis exécuter 5 pourquoi dans la branche étayée par les preuves.
Que se passe-t-il lorsque les 5 Pourquoi n’atteignent pas une cause que nous contrôlons ?
C'est ce que propose la formule « Atteint une cause contrôlable ? » la décision est pour. Si la chaîne dépasse tout ce que votre organisation peut changer, ou se divise en plusieurs réponses tout aussi plausibles, la branche Non déplace le problème sur une arête de poisson au lieu d'accepter le dernier maillon comme cause première. Il s’agit du mode d’échec le plus courant dans la pratique : une chaîne est suivie jusqu’à ce qu’elle atteigne quelque chose d’incontestable mais d’inactionnable, comme la pression du marché ou la nature humaine, et une action est de toute façon écrite contre elle.
Que doit faire l’organigramme lorsque les preuves ont disparu ?
Donnez-lui un résultat nommé plutôt que de le laisser comme un vide. Cet arbre en a deux. Avant l'analyse, « Données suffisantes pour analyser ? » peut envoyer le dossier vers « Retour à la collecte de preuves », qui s'arrête plutôt que de continuer sur des données minces. Après l'analyse, lorsqu'une cause n'est encore qu'une hypothèse, « Davantage de preuves peuvent-elles être obtenues ? soit revient à la collection, soit se termine à « Fermer avec une limitation de données ». Clôturer avec une limitation déclarée est un résultat légitime et génère normalement une action qui lui est propre : rendre les données manquantes disponibles la prochaine fois.
Une norme exige-t-elle une méthode particulière d’analyse des causes profondes ?
Les normes communes des systèmes de management vous obligent à déterminer les causes d’une non-conformité et à agir pour qu’elle ne se reproduise pas, mais elles ne prescrivent pas comment. La clause 10.2 de la norme ISO 9001 est rédigée de cette façon, et la norme ISO 13485 adopte la même approche pour les actions correctives et préventives. Cela vous laisse le choix de la méthode, c’est précisément pourquoi cela mérite d’être documenté. Un arbre de décision comme celui-ci, avec les tests écrits sur les nœuds, montre à un auditeur que la technique a été sélectionnée en fonction de critères énoncés plutôt que par préférence, et la réponse reste cohérente quelle que soit la personne qui mène l'enquête.