Le Lean, c’est de l’amélioration continue par la résolution de problème.

Voilà une belle phrase que j’ai mis approximativement 2 minutes à retenir et plusieurs mois à comprendre. Tout le Lean est là dans cette phrase, mais il y a tellement de concepts cachés derrière. J’ai déjà abordé le sujet de l’amélioration dans ce billet. Je vais maintenant m’attarder sur la notion de résolution de problèmes.

Une précision quand même sur ce billet : il n’est pas destiné à donner des solutions. Désolé, mais il faudrait bien plus qu’un billet de blog pour énumérer toutes les solutions à tous les problèmes du monde. De plus en Lean, la solution n’est pas synonyme d’une résolution de problèmes. Je précise également que ce billet n’est pas destiné non plus à présenter des méthodes de résolution de problèmes comme le PDCA, l’A3, le PDSA, le PISCARE, etc.

Non, dans ce billet, je vais plutôt m’attarder sur les questions suivantes :

• Quel type de problème allons nous tenter de résoudre en faisant du Lean ?
• Comment sait-on que notre « solution » est bonne ou mauvaise ?
• Comment sait-on que notre problème est résolu ?

Qu’est-ce qu’un problème au sens Lean ?

Le Lean définit le problème comme étant un écart de performance. Cette définition est primordiale à comprendre car c’est grâce à elle que nous allons pouvoir définir notre problème précisément, évaluer l’efficacité de la contre-mesure que nous allons expérimenter, et affirmer que le problème est bel et bien résolu.

A cette définition, Marie Pia Ignace (Fondatrice & CEO d’Operae Partners et présidente de l’Institut Lean France) donne un complément que je vous encourage fortement à garder dans un coin de votre tête :

« Si un problème n’est pas mesurable, ce n’est pas un problème, c’est un souci. »

Marie Pia Ignace

Un problème est donc un écart mesurable. Mais un écart avec quoi ? Et bien tout simplement avec un idéal de fonctionnement qu’il faut définir. Et c’est bien là tout le commencement de la résolution de problème en Lean.

Pour définir un problème, il nous faut donc comprendre le fonctionnement souhaité. Cela passe en premier lieu par la communication avec le client afin de comprendre ce qu’il attend principalement de notre équipe. Mais il faudra également comprendre les attentes de l’équipe elle-même, des équipes transverses, des managers, et de la direction de l’entreprise. On souhaite comprendre dans le détail ce qui est attendu de notre production pour décrire le plus précisément possible notre idéal de performance. Cela peut passer par une analyse des stocks, du takt time, du mix produit, des retours qualités, etc.

Suite à cela, nous allons modéliser notre processus de production en mettant en place notre flux tiré par le client (système Kanban que je décrirai un futur billet) ainsi qu’une liste d’indicateurs de performance clés (KPI en anglais) cohérents avec les attentes du client et la stratégie de l’entreprise. Ces éléments seront alors suivis quotidiennement, et serviront à révéler ces fameux problèmes qui seront donc des écarts entre ce que nous mesurons et ce que nous souhaitons.

Trouver une contre-mesure à un problème et en évaluer l’efficacité

Trouver une contre-mesure n’est pas toujours facile, mais en évaluer l’efficacité l’est encore moins. Le Lean propose d’aborder un problème avec une approche causale. Comme précisé dans l’introduction, je ne détaillerai pas ici la méthode. Que ce soit l’A3, le PISCARE, les 5 pourquoi, le PDCA ou autre, le principe général reste le même : analyser le problème pour en trouver la cause racine et ainsi pouvoir proposer une contre-mesure à expérimenter. Oui, à ce stade, nous ne parlons pas encore de solution, car pour le moment nous n’envisageons que de faire des expérimentations pour tenter d’influencer la cause du problème. Ce sont ces expérimentations que nous appelons des contres-mesure.

Et du coup, comment évaluer la pertinence d’une contre-mesure ?

Souvenez-vous que le problème que l’on souhaite résoudre est un écart de performance avec un idéal de production. Evaluer la contre-mesure, c’est identifier une mesure qui devra être impactée positivement par l’expérimentation de la contre-mesure. Le problème étant déjà une mesure, il suffira parfois d’estimer à nouveau l’écart après la mise en place de la contre-mesure pour en évaluer l’efficacité. Mais parfois, cela n’est pas si simple, et il faut alors chercher à trouver une mesure plus fine en lien avec la cause elle-même.

Un exemple étant toujours plus parlant, supposons qu’une équipe a un retour client sur une nouvelle fonctionnalité livrée récemment. Le problème est remonté très rapidement par un indicateur de qualité faisant un rapport entre les fonctionnalités livrées bonnes et celles qui reviennent en retour client. Nous souhaitons avoir zéro retour client, nous en avons un, on a donc bien un problème mesurable. Cependant, il est un peu trop général car plusieurs causes peuvent affecter ce même indicateur (en Sciences, cela s’appelle un facteur de confusion). En analysant la cause racine de ce retour, il se trouve que celui-ci est lié à un service qui met tellement de temps à répondre qu’il tombe en « timeout ». En effet, lorsqu’on atteint les 100 000 lignes dans une des tables de la base de données, le service tombe. Après analyse technique, l’équipe propose donc une contre-mesure à mettre en place (un index par exemple). Dans ce cas, notre mesure nous permettant de dire que notre contre-mesure est efficace ne sera donc plus l’indicateur de qualité en lui-même, mais la mesure du temps de réponse du service concerné lorsque notre table contient plus de 100 000 lignes. Bien sûr, il faudra auparavant définir cet idéal de temps de réponse. A qui pourrions-nous bien demander ceci pour satisfaire entièrement notre client ? 🙂

Cette mesure va nous garantir l’efficacité de la contre-mesure en faisant une évaluation de la performance avant et après la mise en place de la contre-mesure. Ainsi, nous pourrons affirmer qu’en effet, la contre-mesure est efficace ou pas (auquel cas, une autre contre-mesure devra être trouvée).

Comment sait-on que notre problème est résolu ?

Point de vue Lean, si la mesure de notre problème est bonne, on sait pertinemment que notre problème est corrigé. Mais ne manque-t-il pas quelque chose ??

Souvenez-vous d’un des fondements du Lean : Ce que l’on souhaite, c’est développer les personnes pas la résolution de problèmes (voir ici). Un problème n’est donc véritablement résolu que lorsque :

• La mesure du problème dit qu’on a trouvé la cause et qu’on l’a résolue (contre-mesure efficace)
• On a appris quelque chose nous permettant de nous améliorer et d’assurer que ce type de problème ne se reproduira plus à l’avenir.

Et oui, le Lean c’est avant tout le développement des personnes. Et on ne peut considérer un problème résolu que lorsque la solution a permis d’apprendre quelque chose aux équipes. Cela induit le fait de faire une rétrospective de ce qui s’est passé pour comprendre pourquoi on a raté ce point. En pratique on impactera la manière de travailler de l’équipe par un changement dans le processus de production, dans un standard, sur le management visuel, ou n’importe quoi d’autre.

Et c’est seulement à ce moment là que le problème sera enfin considéré comme « résolu » (point de vue Lean).