Apprendre d’abord ou échouer encore ?

A l’occasion d’une interview, l’investisseur Peter Thiel, co-fondateur de PayPal puis du géant du big data Palantir, faisait remarquer qu’apprendre de ses erreurs n’était pas une si bonne idée - un message à l’opposé du « Fail fast, fail often » pourtant cher à la Silicon Valley. Il est vrai qu’avec une logique d’apprentissage par l’erreur, l’éducation coûte cher - surtout quand il s’agit de celle du CEO. Mais puisque qu’on présente le lean comme une stratégie d’apprentissage, qu’est-ce que cela veut dire pour un dirigeant ?

Pour étudier la question, rendons-nous sur le gemba. Le CEO d’une belle scale-up française mène une visite auprès d’une équipe chargée d’un projet de migration lancé il y a plusieurs mois. Ce projet fait suite à l’acquisition d’un concurrent européen par la scale-up, l’objectif stratégique principal de l’année passée – autant dire qu’il s’agit d’un sujet central. Plusieurs milliers de clients doivent cesser d’utiliser la solution acquise pour passer sur celle de cette startup, qui va devenir la solution de référence, mais voilà : après déjà plusieurs mois, seuls quelques dizaines de clients ont sauté le pas et de nombreux autres ont décidé de partir.

Comment aborderiez-vous la visite ?

Malheureusement, la stratégie des dirigeants consiste souvent... à ne pas se mouiller. Une première valeur sûre pour cela consiste à donner au manager en charge du projet des objectifs ambitieux et lui laisser la responsabilité de trouver une solution. “Alors, quel est ton plan d’action pour avoir migré tout le monde d’ici 4 mois ?” La beauté de l’approche, c’est d’une part qu’il n’est pas très difficile de trouver des objectifs, et d’autre part qu’en cas d’échec c’est le manager en charge du projet qui endosse la responsabilité.

Une autre façon sûre de ne pas se mouiller consiste pour le dirigeant à se faire une idée de ce qu’il ferait lui-même s’il s’occupait du projet, puis de décrire cette “solution” au manager pour qu’il la mette en place - tout en se demandant pourquoi le manager n’est pas fichu de la voir tout seul. Là encore le risque est réduit : en cas d’échec, il suffira de reprocher au manager de n’avoir pas su mettre en place une solution qui pourtant était évidente.

La suite du film est malheureusement bien connue. Le manager ne s’en sort pas, et le dirigeant finit par le faire partir d’une façon ou d’une autre. Les managers intermédiaires se suivent et l’entreprise stagne.

Ce qui fait perdurer le système, c’est que le dirigeant, lui, reste au-dessus de la mêlée - il est bien au-dessus de ces incapables !

Comment faire mieux que cela ? Quelle serait une façon apprenante d’aborder la situation ?

La réponse lean consiste à aller sur le terrain, certes, mais ce n’est pas si simple. Il y a déjà la gêne des premières fois, lorsque les équipes ne sont pas familiarisées avec l’exercice et que le dirigeant lui-même ne sait pas comment mener la conversation. Et surtout, comment les aider ? Les équipes connaissent bien mieux les détails du quotidien, il n’est pas possible pour le dirigeant d’avoir réponse à tout.

Reprenons notre exemple de migration. Le dirigeant demande à voir les visuels que l’équipe utilise pour savoir si le projet se passe bien ou pas, et comment ils s’y prennent pour avancer. Il apparaît en les regardant que l’équipe a lancé le projet en faisant émerger la liste, conséquente, des fonctionnalités qui distinguent les deux produits. Elle est en attente des développements correspondant qui devraient réduire l’écart, ce qui pourrait s’étendre sur des semaines.

Au fil de l’échange, le dirigeant note deux choses. D’une part, l’équipe raisonne en pourcentages et en généralités, et pas en clients individuels. D’autre part, les échanges avec les clients, portés par des personnes issues de l’équipe produit, sont tournés vers l’identification des fonctionnalités manquantes.

Puisque l’équipe cherche des fonctionnalités à développer, elle trouve des fonctionnalités à développer !

Dans cette situation, il serait tentant de répondre à ce qui semble être les attentes de l’équipe en arbitrant sur les fonctionnalités à prioriser pour, en apparence, “débloquer” le projet. Le dirigeant lean va au contraire revenir en arrière et changer la méthode d’analyse du problème. Il déporte le regard sur deux sujets :

● Au lieu de regarder des populations de centaines de clients, il propose d’aller voir un client après l’autre pour rentrer dans la richesse de chaque contexte spécifique. L’équipe pourra accélérer plus tard, quand elle en saura davantage.

● Au lieu de regarder un produit fictif qui serait la somme des fonctionnalités des deux solutions, il propose d’explorer les facteurs qui décideraient le client à adopter la nouvelle solution. Que pourrait-il y gagner ? Que risquerait-il de perdre ? Comment le faire changer de perspective sur la perte pour que la transition soit la plus fluide ? Après tout, il y a déjà des milliers de clients qui utilisent cette solution en France et les pratiques ne sont pas très éloignées, aussi il devrait être possible de passer d’une solution à l’autre sans partir dans de grands développements.

En d’autres termes, l’équipe pensait qu’elle faisait évoluer un produit, alors qu’elle est en train de mettre au point un savoir-faire commercial pour soutenir l’adoption d’un produit existant.

Mais ce qu’il faut voir derrière ce changement, c’est que le dirigeant change la façon d’apprendre. Dans l’approche “fonctionnalités”, l’équipe était partie pour mener les développements et on aurait vu ensuite si les clients migraient. Dans la nouvelle approche, on commence par apprendre auprès de clients individuels. En d’autres termes, l’apprentissage précède l’action, et le dirigeant se mouille pour déclencher cet apprentissage.

Ce qui permet au dirigeant lean d’opérer ce changement, c’est la maîtrise des méthodes d’analyse qui permettent d’étudier les problèmes qui se présentent. Dans cet exemple, notre dirigeant s’est appuyé sur le modèle Value Analysis / Value Engineering qui lui permet d’analyser des problèmes d’adoption des produits. Mais prenons un pas de recul. D’une manière plus générale, l’ensemble du TPS est une collection de méthodes d’analyse :

● L’approche Value Analysis / Value Engineering décrit des méthodes d’analyse des problèmes de valeur pour les clients

● Le Juste-à-Temps décrit des méthodes d’analyse des problèmes de coordination et de délais

● Le Jidoka décrit des méthodes d’analyse des problèmes de qualité et de productivité

● Le socle du TPS décrit des méthodes d’analyse des problèmes de conditions de travail et d’utilisation des équipements

Comment l’utiliser en pratique ? Le dirigeant lean s’appuie sur les visites terrain pour discuter des priorités des équipes, puis pour se mettre d’accord avec elles sur la méthode d’analyse qui permettra d’apprendre avant d’avoir fait l’action... plutôt qu’après avoir échoué.

Quel est le prochain changement que vous vous apprêtez à mener ? Que devez-vous apprendre avant de l’opérer ? Avec quelle méthode d’analyse ?

Régis Medina

Téléchargez le PDF

Cet article Apprendre d’abord ou échouer encore ? est apparu en premier sur Institut Lean France.