toolbox

Root Cause Analysis

Le Root Cause Analysis (RCA) est au cœur des méthodes de résolution des problèmes telles que 8D (pour la gestion des réclamations), DMAIC (pour les problèmes plus complexes liés aux produits ou aux processus), SORA (Situer-Observer-Réfléchir-Agir pour les problèmes simples sur le lieu de travail).

Toutes les méthodes, qu’elles comportent 4, 5, 8 ou 20 étapes, partagent la même philosophie: il faut trouver la cause fondamentale d'un problème afin d'éviter que les solutions proposées ne servent qu’à guérir les symptômes.

Outre les deux outils traditionnels pour RCA (1,2), deux autres (3,4) ont également prouvé leur importance.

Les « 5 Pourquoi »

On se pose 5 fois la question « Pourquoi? » afin de trouver la cause profonde. Les 5 Pourquoi s'appliquent efficacement aux problèmes relativement mineurs d'atelier, combinés aux problèmes d'organisation. Pour les problèmes techniques, de processus ou de produits plus difficiles, on ne dépasse généralement pas le premier pourquoi et on ne trouve pas la cause. Ensuite, on passe à la méthode EST/N'EST PAS, dont il sera question plus loin.

Diagramme « cause et effet »

La première étape est un brainstorming de groupe sur les causes possibles. Celles-ci sont ensuite réparties en catégories telles que l'homme, la machine, le matériel et la méthode. Les causes sont placées dans un « diagramme en chevrons » ou diagramme d'Ishikawa. Facile d'utilisation, la méthodologie a prouvé son utilité et est aussi applicable à un environnement avec peu de données sur un processus, par exemple lors du développement d'un nouveau produit/processus.

Les limites du diagramme d'Ishikawa sont les suivantes:

  • Les causes profondes suggérées sont fondées sur des opinions plutôt que sur des faits.
  • Les interactions entre les causes sont difficiles à visualiser.
  • Les modifications de processus sont peu ou pas abordées.

La liste des causes profondes « potentielles » est longue. La sélection de la cause profonde la plus probable se fait par scoring, ce qui équivaut à une « résolution démocratique des problèmes ». D'après l'expérience de Stanwick, dans de nombreux cas, la véritable cause profonde n'apparaît même pas dans le diagramme!

L’outil EST/N’EST PAS

L'outil EST-N’EST PAS (C.H. Kepner, B.B. Tregoe, 1965) se concentre sur ce que le problème lui-même présente comme des faits. “Let the problem and the data do the talking, not the engineers”.

Les faits sont recueillis selon 4 facteurs: Quoi, Où, Quand et Combien. En fonction de ces facteurs, 2 options sont possibles:

  1. Le problème se produit (« EST »).
  2. On pourrait s'attendre à ce que le problème se produise, mais ce n’est pas le cas (« N’EST PAS »).  
     

La comparaison entre les situations EST et N’EST PAS révèle des différences qui, combinées à des changements, sont les véritables causes du problème. Ainsi, on peut trouver les mécanismes qui expliquent pourquoi le problème se produit ainsi, là, et dans cette mesure (la colonne « EST »), mais aussi pourquoi le problème ne se produit pas différemment, ailleurs, à un moment prévu et pas dans cette mesure (la colonne « N’EST PAS »). Stanwick a appliqué cet outil des dizaines de fois, parfois avec une rapidité surprenante (- de 2 heures) pour trouver la cause de problèmes qui traînaient depuis des jours, des semaines, voire des mois.

Outils statistiques

Depuis l'émergence de la méthode 6-sigma, l'application d'outils statistiques pour déterminer les causes profondes des problèmes a suscité un vif intérêt. Parmi ces outils, on peut citer 2-sample-t, Anova, Regressie, Design of Experiments, Principal Components Analysis...

Business & opérational excellence

node id: 167 nid: 165

Lean

node id: 167 nid: 166

6 Sigma

node id: 167 nid: 167

active

Root Cause Analysis

node id: 167 nid: 168

Évaluation OPEX

node id: 167 nid: 169

Tableau de bord

Développement organisationnel

node id: 167 nid: 172

Insights Discovery

node id: 167 nid: 173

MBTI

node id: 167 nid: 176

Évaluation TAO

node id: 167 nid: 178

Coaching

node id: 167 nid: 992

Agile & SCRUM