Pourquoi utiliser un Pareto visuel ?

peinturerupestre

Nombreuses sont les histoires de projets informatiques — petits ou grands — qui, dans le meilleur des cas, attendent la fin du cycle en V (voir note en bas de page) pour commencer à se poser des questions pour identifier des actions à mettre en œuvre (si le temps le permet) visant à s’améliorer lors du prochain projet. Lesdites questions s’appuient rarement sur des indicateurs autres que le respect des délais et les charges consommées versus prévues. Le reste des questionnements est souvent fondé sur du ressenti ou, si c’est mesuré, un nombre d’anomalie en recette client sans pour autant avoir dénombré celles détectées en recette interne (avant livraison au client). Pour le dire plus simplement, le questionnement se fait quasi exclusivement sur des données quantitatives, quand elles existent.

Cela parait assez caricatural. Pour autant, ami lecteur, si tu travailles dans le domaine de l’informatique, ne te retrouves-tu pas un peu (beaucoup) dans ces propos ? Je le concède, l’une des difficulté en Lean Management, c’est d’accepter de voir les problèmes. Le Pareto visuel va nous y aider.

En Lean Management, la cible est de livrer au client un produit avec zéro défaut ; c’est le principe de la qualité : protéger le client. Mais c’est aussi une question de respect : ne pas délivrer un produit défectueux à l’équipe suivante. Différentes techniques existent pour éviter les défauts, les détecter au plus tôt et les traiter avant que le produit ne soit livré au client.

Pareto, quésaco ?

Le Pareto, appelé communément «règle des 80-20­» permet, dans notre cas, de déterminer les 20 % de causes potentielles générant 80 % des problèmes. L’intérêt, vous l’aurez compris, est de se concentrer sur ces 20 % qui auront, une fois les causes racines supprimées, un impact positif sur 80 % des problèmes générés. Ce principe se traduit par un diagramme de Pareto comme celui-ci :

pareto

Pourquoi faire un Pareto visuel dynamique ?

Parce qu’il fournit des informations très rapidement au lieu d’attendre la fin du projet et de collecter l’ensemble des données et calculer le graphique avec un tableur. Les équipes de Plastic Omnium ont mis en place cette pratique pour résoudre leurs problèmes, comme Aurore Xémar (Directrice qualité chez Plastic Omnium) nous l’a expliqué au Lean Summit 2016 à Lyon. Je vous entends déjà dire : «Oui, mais l’exemple c’est du service ; rien à voir avec l’informatique !» Je vais vous aider à faire la transposition avec un exemple sur des causes probables d’anomalies détectées en recette client (mais l’exercice peut se faire également en recette interne ou pour les défauts détectés en production).

Je pratiquais il y a déjà plusieurs années ce que nous appelions les causes d’introduction (pour quelle raison l’anomalie a été introduite dans le produit) et les causes de propagation (pour quelle raison l’anomalie n’a pas été détectée lors de sa création avant de se propager dans la chaîne de création de valeur). Concentrons-nous sur les causes d’introduction.

En faisant une rapide analyse des fiches d’anomalies — si elles existent — il est possible de mettre en évidence quelques causes probables d’introduction comme :

  • mauvaise compréhension du besoin = l’équipe n’a pas correctement compris le besoin ;
  • spécifications incomplètes ou incorrectes = des manques ou des défauts dans les spécifications sont en écart avec le besoin initial ;
  • non-conformité avec les spécifications = les fonctionnalités réalisées ne respectent pas ce qui est décrit dans les spécifications ;
  • non-conformité par manque d’expérience sur les technologies utilisées = développeur avec (très) peu ou pas d’expérience sur une technologie utilisée ;
  • non-conformité aux normes applicables = non-respect des normes (sécurité, développement, tests…) requises ;
  • autres.

Évitons les listes à la Prévert pour faciliter l’usage du Pareto visuel dynamique. La construction de ce dernier, pour faire du management visuel, est relativement simple :

  • une feuille A4 ou A3 si le bureau est grand ;
  • six colonnes verticales où chaque colonne représente une des causes probables d’introduction citées ci-dessus ;
  • accrocher un marqueur rouge à côté de la feuille.

Remarque : en Lean, nous utilisons 2 couleurs : vert pour ce qui est bon, rouge pour ce qui n’est pas bon.

Pour comprendre quoi ?

À chaque fois qu’une anomalie est détectée (en recette client dans notre cas), identifiez la cause probable d’introduction et tracez une ligne horizontale dans la colonne concernée. Ainsi, chaque anomalie alimente directement le Pareto visuel et une tendance va rapidement se dessiner.

paretovisuel

L’exemple ci-dessus nous indique — sans graphique de Pareto — que pour 17 anomalies détectées, 7 sont des non-conformités aux spécifications (41 % des défauts) et 5 (29 % des défauts) une mauvaise compréhension par rapport au besoin. Deux causes probables (33 % des causes probables) génèrent 70 % des défauts ; c’est ce qu’on appelle la «tête de Pareto». Il est donc important de s’intéresser rapidement à ces 2 sujets.

Des actions de résolution de problème (PDCA) devront être entreprises sur les 2 sujets pour trouver les causes racines. Ainsi, l’équipe, après avoir vu les problèmes, se met en capacité de comprendre ensemble et d’agir ensemble («voir ensemble, comprendre ensemble, agir ensemble», principe de tout indicateur Lean). Les actions d’amélioration doivent être entreprises rapidement et le manageur de l’équipe doit soutenir ces actions pour ainsi aider l’équipe à

  • réduire la non-valeur ajoutée par suppression des corrections ;
  • faire bon du premier coup et améliorer la qualité du produit ;
  • améliorer la satisfaction du client ;
  • développer les compétences et l’autonomie de chaque collaborateur par la résolution des problèmes.

En Lean Management, la résolution des problèmes et les indicateurs ne sont pas utilisés pour trouver des coupables (se reporter à l’article « Tuer la stigmatisation »).

Note : le cycle en V est un modèle de gestion de projet avec des étapes bien définies et séquentielles. Souvent appelé «effet tunnel», car le client peut ne pas voir son produit avant sa livraison pour validation. Pour plus de détails, voir ici.

Une réflexion sur “Pourquoi utiliser un Pareto visuel ?

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s