[Total : 1    Moyenne : 5/5]
L’analyse de problème est utilisée pour trouver la cause racine à l’apparition d’un problème. 

Introduction

L’analyse de problème est utilisée pour trouver la cause racine à l’apparition d’un problème. Elle permet de rechercher les informations pertinentes et de guider la recherche jusqu’à la cause racine.

Les 2 principes

Un standard est identifié et on sait le comparer à la situation problématique.

Dans la majorité des cas, la cause d’un problème est liée à un changement qui a engendré un effet indésirable.

Etape 1 : Définir le problème

L’analyse d’un problème commence par la définition de celui-ci. Dans la méthodologie Kepner Tregoe, et comme dans la plupart des autres (8D, PDCA…), cette étape est cruciale pour obtenir de bons résultats. L’enjeu est de définir le sujet ainsi que la mesure qui qualifie le problème, ce que l’on appelle le Goal Question Metric (GQM). Cette étape est identique à la définition du Business Case et du Problem Statement utilisés dans la charte de projet du DMAIC.

On va décrire le problème en une ou deux phrases et cela de manière chiffrée. On pourra par exemple définir un problème d’email comme cela :

Le système d’envoie d’email est tombé en panne après que la 3ème équipe d’ingénieur ait installé la soft XXX sur le serveur d’échange YYY

Etape 2 : Décrire le problème

L’enjeu de cette étape est de récolter et analyser les informations nécessaires pour identifier la bonne cause racine. Ceci via l’observation et la description du problème rencontré. Pour cela, la méthode développée par les créateurs consiste à s’appuyer sur un QQOQCCP croisée avec Est / N’est Pas.

Cette notion de Est / N’est Pas a pour but de ne pas s’éparpiller et de plus rapidement cibler la cause. Plus précisément, et ceci pour éviter toutefois de ne pas prendre en compte certain critère, les créateurs de la méthode indique « Peut Etre, mais N’Est Pas ».

Etape 3 : Lister les causes possibles

Nous l’avons évoqué ci-dessus, l’hypothèse retenue par la méthode est que la plupart des problèmes sont apparus suite à un changement quelconque. Pour l’identifier, la méthode demande à rajouter une colonne qu’est la différence. En effet, pour chaque élément listé précédemment, on recherche s’il y a eu une différence par rapport à une situation classique ou tout simplement une différence (changement d’équipe, après nettoyage…).

Ensuite, on liste l’ensemble des causes potentielles en s’appuyant sur le fait que l’hypothèse retenue de base est que la cause s’appuie sur la différence qu’il y a entre 2 situations.

Est

N’est pas

Différence

Cause potentielle

Quoi

Quel est le problème ?

Qu’est ce qui n’est pas le problème ?

Quelle est la différence ?

Quelle est la cause possible ?

Quand

Quand le problème est apparu ?

Quand le premier a t’il été découvert ?

Quand le problème n’a t’il pu apparaître ?

Quand le dernier a t’il été découvert ?

Quelle est la différence de temps ?

Quelle est la différence de temps entre le premier et le dernier ?

Quelle est la cause possible ?

Où le problème a eu lieu ?

Où le problème n’a t’il pu avoir lieu ?

Quelle est la différence ?

Quelle est la cause possible ?

Qui

Qui a découvert le problème ?

Qui n’a pas découvert le problème ?

Quelle est la différence ?

Quelle est la cause possible ?

Comment Comment les unités sont elles affectées ? Comment ne sont elles pas affectées ? Quelle est la différence ? Quelle est la cause possible ?

Combien

Combien d’unités ont été impacté ?

Combien d’unités n’ont pas été impacté ?

Quelle est la différence ?

Quelle est la cause possible ?

Etape 4 – Tester les causes

A ce niveau l’enjeu est de savoir quelle est l’hypothèse qui permettrait de valider la cause potentielle. On va devoir répondre à la question suivante :

Si ____ est la cause du problème de ____, comment peut il expliquer les informations  EST et N’EST PAS ?

Par exemple, si une cause potentielle du problème est le serveur d’échange a un problème, alors cette hypothèse n’est valide que s’il n’y a le problème qu’avec ce serveur.

Ensuite, on vient mettre un niveau de probabilité pour cette cause : Sans doute, Peut être et sans doute pas.

Etape 5 – Vérifier la cause la plus probable

Pour la ou les causes les plus probables, on va les confronter via une matrice de contradiction, aux éléments de la description du problème. Autrement dit, est ce que la cause que nous avons identifiée comme fortement probable, peut-elle répondre à la situation que nous avons décrite dans la matrice initiale.

Notre cause correspond t’elle à la description du problème ?

Est 

N’est pas

Quoi

Oui

Non

Quand

Non

Non

Oui

non

Qui

Non

Non

Comment

Oui

Non

Combien

Oui

Non

 

2 situations peuvent se présenter :

  • Notre cause correspond à l’ensemble des points de la description du problème (on peut mettre Oui dans toutes les cases) : il y a une forte probabilité que la cause identifiée soit la bonne. Il nous reste plus qu’à le valider en effectuant des essais.
  • Notre cause ne répond pas ou que partiellement à la description du problème (le tableau se compose alors de Oui et de Non ou que de Non) : dans ce cas, il y a une forte probabilité que notre cause ne soit pas la bonne. On doit alors remettre en cause la description du problème si nous pensons que la cause est sans doute la bonne, sinon, il faudra rechercher une autre cause.

Source

C. H. Kepner, B. B. Tregoe (1980) – Le manager rationnel : méthodes d’analyse de problèmes et de prise de décision

C. H. Kepner, B. B. Tregoe (1981) – The new rational manager

J. Kosina (2004) – Quality improvement methods for identification and solving of large and complex problems

Share This