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 ! ;-)

Quel indicateur pour votre projet Lean Six Sigma… ?

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

C’est fait… vous êtes décidé : vous vous lancez dans un projet lean six sigma… ! Vous avez finalisé votre « project charter », vous avez défini vos process avec des « process map » des « value stream map »…etc. Et vous arrivez donc à l’étape cruciale du choix de votre indicateur. Quel sera votre Y ? Cette valeur que vous allez suivre dans le temps, analyser, décortiquer dans les moindre détail pour savoir de quoi il se constitue, les phénomènes qui l’amène à varier…etc. Pour les projets de lean manufacturing cette étape est moins cruciale car l’indicateur est souvent le nombre de défauts constaté sur la chaîne de production ou des indicateurs de productivité. Mais dans les services nous allons voir que le choix est moins aisé.

L’élément fondamental : votre Y doit révéler votre problématique ! (Comme dirait l’autre : ça va sans dire mais ça va mieux en le disant) C'est-à-dire que si votre indicateur évolue comme vous le souhaitez, le problème que vous aviez identifié au démarrage de votre projet doit être éradiqué. J’avais suivi le projet LSS d’un responsable compte clé. Sa problématique était que ses clients s’engageaient 6 mois à l’avance et que le jour J de la promo il pouvait y avoir des ruptures ou des retards de livraison qui faisaient que son client n’avait pas la marchandise qu’il avait commandée. Le premier réflexe du green belt fût de regarder du côté des ruptures, la facilité le conduisit donc à choisir le taux de service comme indicateur. Alors posons nous la question : est-ce que si j’améliore mon taux de service, je suis sûr que mon client qui m’envoi sa commande 6 mois à l’avance sera livré ? Et bien non ! Le taux de service comptabilise la fraction de la commande qui est livré. Il n’y a donc aucune notion de temps dans cet indicateur. Si le client est livré de la totalité de sa commande avec 15 jours de retard le taux de service de cette commande sera de 100%. Le réflexe inverse peut être de choisir le délai entre la date de livraison demandée et la date de livraison finale de la commande. Mais là encore si nous nous basons sur ce qui est livré en retard, cela signifie que nous écartons ce qui n’est jamais livré… Cet indicateur n’est donc pas révélateur de notre problématique. Ici le Y le plus proche de la problématique de notre green belt est l’OTD (On Time Delivery) qui représente la fraction de la commande qui est livré dans les temps. Alors oui le nombre de jours de retard et le nombre de ruptures joueront sur notre Y mais il peut y avoir bien d’autres indicateurs en liaison avec notre problématique. Par exemple si une commande n’a pas atteint le minimum de commande, elle aura beau avoir du stock et un mode de livraison ultra performant… la commande ne sera jamais livrée car jamais validée…voilà donc un nouvel indicateur en lien avec notre problématique : le nombre de commande bloquées. Tous ces indicateurs qui gravitent autour de notre problématique nous aideront dans la phase d’analyse… mais il faut bien l’admettre : pendant la phase de sélection de notre Y : ils nous encombrent l’esprit et rendent difficile le choix de notre indicateur principal.

Pour conclure : lorsque vous choisissez votre Y vous n’avez qu’une question à vous poser : Si j’améliore cette indicateur est-ce je suis sûr que mon problème disparaît ?

N’hésitez pas à me soumettre des problématiques en commentaire si vous rencontrez des doutes dans le choix de votre indicateur LSS ! ;-)