Justesse, Répétabilité, Reproductibilité : GRR pour les intimes...

Ce message est disponible sur le nouveau blog à partir de ce lien

Alors jusqu'ici j'ai fais en sorte de rendre accessible les concepts... Mais là nous commençons à rentrer dans des notions un peu plus obscures pour les managers assoiffés d'opérationnel que nous sommes... ;-)

Si je vous dis ça : c'est parce que cette étape m'est apparue, au premier abord, relativement inutile. L'exemple des Smarties, en guise de formation, ne m'aidant pas particulièrement à apprécier l'opportunité de l'outil...

Je m'en vais de ce pas vous expliquer pourquoi dans un premier temps cet outil m'est apparu inutile, puis le cheminement qui m'a conduit à le juger indispensable dans l'étape Measure du DMAIC.

Le G (Gauge = justesse) R (repeatability) & R (Reproductibility) permet de mesurer la fiabilité du système de mesure du Y.
Dans les processus transactionnels nous avons à faire la plupart du temps à des indicateurs qui sont issus du système d'information. Aussi, si dans un outil décisionnel (type BW, BO, Pentaho...etc.), je réalise deux fois la même requête (repeatability) : il y a peu de chance que l'outil me fournisse deux mesures différentes ! De la même façon pour la reproductibilité, si une autre personne que moi lançait la même requête, j'imagine mal le système me fournir une valeur différente que celle qu'il m'a sortie précédemment...! Enfin par rapport à la justesse de la mesure... Quand bien même, la mesure s'avérait partiellement erronée : quel serait mon pouvoir pour cerner d'où provient l'écart de mesure ?

Voilà pourquoi j'étais sceptique : je ne comprenais pas l'intérêt de vérifier la fiabilité des données émises par un système d'information qui est spécifiquement conçu pour fournir des indicateurs fiables.

Mais si le système est fiable, l'humain lui ne l'est pas... Et si le traitement des informations est réalisé par le système : en amont de cette chaîne de traitements nous avons un être humain qui alimente le système. Donc il est nécessaire de vérifier la variabilité des informations qui sont renseignées dans le système.

Prenons un exemple : dans un service client (hotline) nous avons des opérateurs qui enregistrent des litiges. Les litiges qui sont enregistrés sont affectés à une codification spécifique. Si, selon les opérateurs où l'humeur de l'opérateur, l'interprétation du litige et la codification qui lui est affectée change : nous allons rencontrer des problèmes. Par exemple si des litiges issus d'erreurs des VRP sont enregistrés dans les litiges issus du service client (à la saisie de commande par exemple) : lorsque nous allons travailler sur la réduction des litiges générés par le service client : nous serons bien embêtés car notre Y risque de ne pas évoluer comme nous l'avons prédit (puisqu'il inclut des erreurs des VRP (qui sont hors du projet LSS).

A présent : comment procéder ?
Autant que possible : il est préférable d'obtenir les documents papiers qui sont à l'origine du traitement. Dans notre exemple : on peut imaginer que les appels pour litiges sont suivis d'une confirmation par fax de la part du client pour la déclaration de son litige. Il faut alors recueillir un échantillon de ces déclarations et visualiser dans notre requête si ce qui relève de ce que l'on souhaites mesurer y est bien inclus. Voici un tableau qui illustre mon exemple :

Cet exemple n'illustre que la mesure de la justesse et la répétabilité... (Pour la mesure de la reproductibilité, il eu fallut que je considère que tous les opérateurs étaient amenés à traiter chaque litige...). Ici nous obtenons 80% de fiabilité de notre système de mesure. C'est suffisant ! La pratique des projet LSS a fixé à 80% le seuil de tolérance (nous considérons que si notre indicateur est fiable à 80% minimum, nous agirons sur au moins 80% des causes ce qui nous invite à penser que nos actions auront un impact significatif sur l'indicateur mesuré).

Si j'avais obtenu un taux de fiabilité inférieur à 80% il aurait fallut que je mène des actions pour repasser le test avec succès (formation du personnel, clarification des codifications, resegmentation des classifications de litiges...etc.)

Le test GR&R constitue un "passe droit" pour accéder à l'étape suivante "Analyse". Cette étape est cruciale et si le test de fiabilité du système de mesure ne passe pas alors il ne faut absolument pas avancer sur l'analyse des données. Car si j'analyse des données qui en amont sont mal codifiées : alors mon analyse sera erronée.

J'ai conscience que ce concept de fiabilité de l'indicateur n'est pas aisé à assimiler... aussi n'hésitez pas à poser des questions ou laisser des commentaires ! ;-)