Résolvez-vous vraiment des problèmes lorsque vous pensez en résoudre ?

resolution-probleme

À bien des égards, le Lean consiste à développer une culture d’autonomie dans la résolution de problèmes. Mais, qu’entend-t-on exactement par « résoudre un problème »?

Initialement publié par Michael Ballé sous le titre « Are you really solving problems when you think you are solving problems? ».

Un problème survient quand un incident dans le processus normal conduit à un écart dans la performance. Un embouteillage inattendu alors que vous allez prendre un train est un problème quand vous arrivez en retard à la gare. Manquer le train pour cette raison est un problème quand vous arrivez trop tard pour une réunion importante. Ne pas être à la réunion est un problème quand vous ne pouvez pas conclure une affaire, et ainsi de suite.

Résoudre des problèmes au sens classique signifie d’abord parvenir à contourner le problème – existe-t-il un autre itinéraire pour attraper ce train ? Y a-t-il une autre façon d’assister à la réunion ? La réunion peut-elle être reportée ? Ensuite, il s’agit de contrôler ou de changer le processus afin que le problème ne se reproduise pas. Devriez-vous partir plus tôt pour compenser les embouteillages alors que la plupart du temps la route est dégagée ? Devriez-vous investir dans un système de surveillance du trafic en temps réel pour être prévenu au plus tôt d’une circulation chargée ? Devriez-vous explorer tous les itinéraires de rechange à l’avance en cas de ralentissement ?

Comme l’indiquent Art Smalley et David Mann, il y a résolution de problèmes, et résolution de problèmes. La résolution de problèmes peut être administrative, basée sur leur détection ou leur prévention. Si nous revenons aux enseignements sur la qualité de Shigeo Shingo, lorsque nous abordons des problèmes de qualité, nous essayons de progresser en 3 étapes :

  • Niveau 1 – post-inspection : compter les morts, pour ainsi dire. Le processus fait ce qu’il fait, puis nous inspectons les mauvaises pièces ou bien le travail mal fait à partir de son résultat. Le tout est mis en forme à la façon d’un audit avec des mesures correctrices post-mortem. Nous gérons le problème une fois qu’il est arrivé.
  • Niveau 2 – l’auto-inspection : apprendre à surveiller les points critiques dans le processus normal pour obtenir l’alerte précoce, arrêter et corriger. Dans les accidents comme dans les incidents de qualité, il y a habituellement un tunnel temporel dans lequel le processus ne fait plus ce qu’il devrait, mais la performance est toujours ok (certains ralentissements sur la route seront stressants, mais vous arriverez toujours à la station à l’heure). Puis il y a un point où la performance chute de façon spectaculaire (cela peut être représenté par une courbe de Taguchi). Les premiers signes d’alerte et la correction instantanée aident à la fois à éviter que les choses tournent vraiment mal et à en apprendre beaucoup plus sur le processus lui-même.
  • Niveau 3: inspection de la source : savoir ce qu’il faut rechercher au préalable pour éviter que le problème ne se produise en premier lieu. C’est le but de l’analyse par les «cinq pourquoi? » Une analyse qui consiste à trouver la véritable cause première dans le processus et à modifier ou surveiller celui-ci.

Si vous pensez mécaniquement lors de la résolution de problèmes, ceux-ci sont soit résolus soit non-résolus. Les pratiques sont bonnes ou mauvaises. L’astuce consiste à passer des mauvaises pratiques aux bonnes.

Mais si vous pensez de façon plus organique, chaque pratique est Yin-Yang – changer une pratique déplace le point d’équilibre. Résoudre le problème en passant de la post-inspection à l’auto-inspection, puis à l’inspection des causes racines, signifie mieux comprendre ce qu’il faut surveiller attentivement dans le processus technique pour éviter une perte de performance désastreuse.

Ce n’est pas facile parce que souvent, le point d’inspection de la cause racine n’est pas nécessairement visible ou simplement corrélé à l’endroit où le symptôme du problème apparait. Pour avoir une idée de la nature systémique de nombreuses questions, regardez ce film stupéfiant sur l’impact environnemental de la réintroduction des loups à Yellowstone. De même, nous avons l’exemple des célèbres cinq exemples pourquoi de Taiichi Ohno :

  1. « Pourquoi le robot s’est-il arrêté ? » Parce qu’il y a eu une surcharge du circuit qui a fait fondre un fusible.
  2. « Pourquoi le circuit était-il en surcharge? » Parce qu’il y avait une lubrification insuffisante sur les roulements, donc ils se sont grippés.
  3. « Pourquoi la lubrification des roulements était-elle insuffisante ? » Le débit de la pompe à huile du robot était insuffisant.
  4. « Pourquoi le débit de la pompe à huile du robot était-il insuffisant ? » L’entrée de la pompe est obstruée par des copeaux de métal.
  5. « Pourquoi l’entrée est-elle obstruée par des copeaux de métal ? » Parce qu’il n’y a pas de filtre sur la pompe.

…déplace l’attention de la surveillance des arrêts du robot, à l’installation et au contrôle d’un filtre sur la pompe (le filtre va finir par s’obstruer). Cependant, la cause : l’absence de filtre sur la pompe n’est pas immédiatement visible lorsque l’on regarde les arrêts du robot – elle doit être découverte parmi des centaines d’autres causes possibles.

Notre attitude explicite vis-à-vis de l’apprentissage est ce qui fait la vraie différence pour la résolution de problèmes :

  1. Les gens n’apprendront pas, ils ne peuvent pas être dérangés et doivent être contraints de faire le travail correctement : cette hypothèse conduit à des solutions « administratives » ou « post-inspection » – demander à quelqu’un d’autre d’inspecter le travail de ceux qui le font et mettre en place des contrôles papier et des vérifications pour prendre des mesures correctrices une fois que le processus a effectivement déraillé.
  2. Les personnes peuvent apprendre si elles répondent à des signes de problèmes très visibles: Il s’agit d’une approche de la résolution de problèmes par la « détection » ou « auto-inspection » – en créant des normes visuellement intuitive (pensez au feu rouge à une intersection). Les personnes qui voient des feux clignotants vont arrêter ce qu’elles font et faire un effort pour revenir dans la norme. En faisant ainsi, elles apprennent ce qu’il faut surveiller, tant que leur attention est guidée par des signes visibles.
  3. Les personnes peuvent avoir une réflexion poussée, et sont capables de découvrir les causes les plus profondes des problèmes: c’est une approche focalisée sur la cause racine, où la personne n’abandonne pas jusqu’à ce que le point focal de la question soit déplacé vers quelque chose de plus facile à surveiller et à contrôler.

Est-ce que la création d’une culture de résolution de problèmes consiste en des plans d’audit et de contrôle des processus ? Ou bien s’agit-il de faire des plans pour soutenir l’apprentissage individuel sur la nature des processus ?

Selon mon expérience, c’est « l’ingrédient magique » que le sensei apporte à votre pratique Lean : vous pousser à passer à travers les niveaux et aller jusqu’à l’apprentissage, même lorsque les symptômes du problème ont disparu et que le « correctif » est en place.

C’est aussi la plus grande erreur que les gens commettent vis à vis de l’obeya et du management visuel en utilisant les écrans pour surveiller les processus, avec toutes sortes de tableaux indicateurs powerpoint sur le mur et des plans d’action, plutôt que de créer des espaces d’apprentissage : qu’essayons-nous actuellement de faire ? Comment réagissent les clients ? Qu’avons-nous découvert ?

La cause racine d’un véritable apprentissage de la résolution des problèmes n’est pas de résoudre le problème lui-même, mais bien votre engagement explicite à apprendre par opposition à l’obsession traditionnelle de contrôler. L’amélioration de la qualité est très différente de l’assurance qualité. Encore plus de paperasse ne vous aidera pas à découvrir une cause racine. Vous devez être là, quand le problème se produit, et plonger votre regard avec les autres autour de vous dans ce qui se passe, formuler des hypothèses erronées jusqu’à ce que, progressivement, les véritables causes en actions deviennent claires.

Michael Ballé.

 

 

Une réflexion sur “Résolvez-vous vraiment des problèmes lorsque vous pensez en résoudre ?

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