Le Lean, ce n’est pas pour moi !

Dans mon expérience de coach en Lean Management, il n’est pas rare d’entendre des personnes dire « Le lean, ce n’est pas pour moi ! » tout en refusant la comparaison avec Toyota.

Cette phrase « Le lean, ce n’est pas pour moi ! » et ses variantes font partie des idées fausses (les misconception) qui seront parfois résistantes au changement. Dans la grande majorité des cas, elles tombent dès les premiers résultats. Mais pour certaines personnes, le doute, voire le refus, perdure.

On n’est pas chez Toyota !

Je ne pourrai pas citer l’ensemble des phrases que j’ai entendues depuis que je pratique. En voici un court florilège :

• On n’est pas chez Toyota !
• On n’est pas en train de serrer des boulons comme les ouvriers de Toyota !
• Nous, on n’est pas sur une chaîne de fabrication de voiture !
• On ne fait pas le même métier !
• Ce n’est pas applicable dans notre domaine !
• Nous, on fait de l’IT, pas des voitures !
• Ce n’est pas applicable sur un ERP !
• Tu ne te rends pas compte comme notre système est complexe…
• Notre métier est très intellectuel par rapport à la fabrication d’une voiture !
• Tu sais, chez nous c’est différent !
• …

Alors, en mon fort intérieur, je serre les dents et me force à passer outre les comparaisons méprisantes sur les cols bleus et les cols blancs qui sont d’un autre temps. Le travail des ouvriers, quel qu’il soit, est tout aussi important que celui d’un ingénieur. L’un n’existe pas sans l’autre.

Ce n’est pas pour moi… et pourtant !

Tout d’abord, je m’appuie sur les propos de Tracey Richardson (ancienne de Toyota Motor Manufacturing of Kentucky, co-auteure de The Toyota Engagement Equation, enseignante et sensei TPS / Lean) et ses 4P : Purpose, People, Process et Problem (lire Les 4P pour expliquer qu’on peut pratiquer le Lean partout).

Bizarrement, pour des métiers considérés comme très éloignés, les points communs commencent à apparaître. Les entreprises n’ayant pas ces 4P sont plutôt rares.

Puis, parfois, je pousse le raisonnement plus loin en demandant aux personnes de comparer la photo d’une voiture et celle d’une application Web (ou client lourd). Elles doivent trouver au moins 5 points communs entre ces 2 photos.

Alors… que trouve-t-on ? J’en donne 5, mais il y a bien plus si l’on fait l’effort de chercher.

Un utilisateur

Un utilisateur / client pour utiliser le produit (voiture et application). Sans cet utilisateur / client pour utiliser le produit ou consommer le service, il n’y a aucun intérêt à perdre du temps à le fabriquer.

Une interface homme-machine

Il y a encore une dizaine d’années, on parlait beaucoup d’IHM dans l’IT. L’application est une IHM et la voiture en comprend plusieurs : volant, écran tactile, boîte de vitesse… Les IHM permettent les interactions entre l’utilisateur et le produit. Si elles ne sont pas correctement pensées, l’usage (User eXperience) n’est pas au rendez-vous et le produit risque fort de péricliter.

Un processus de fabrication

Il y a un processus de fabrication pour construire l’application et pour fabriquer la voiture. Sont-ils vraiment différents comme certains l’affirment ? La première réponse (celle de notre cerveau rapide, en référence au livre Système 1 / Système 2 : Les deux vitesses de la pensée de Kahneman) sera certainement « bien sûr que oui ! ». Après quelques secondes de réflexion en faisant usage sur cerveau plus lent, on commencera à douter de notre première réponse.

C’est le produit ou le service qui est différent. Le processus de fabrication est techniquement différent, mais les processus dans leur schématisation, ne sont pas si éloignés qu’on peut le penser.

La préparation de la chaîne de réalisation de l’application logicielle avec sa batterie d’environnements (dev, test, pré-prod, prod) et d’outils comme la CI/CD (intégration continue et déploiement continue) est la même chose que la préparation de la chaîne de fabrication d’une voiture. Tout doit être fonctionnel et disponible sinon la fabrication se grippe et l’usine risque de s’arrêter.

Surcharger le backlog d’un des composants de l’application logicielle alors que l’équipe n’est pas en capacité de produire autant est l’équivalent de la création de stocks intermédiaires très coûteux sur une chaîne industrielle. Les pièces ne sortiront pas plus vite !

On peut aller encore plus loin avec le mix produit. Il n’est pas rare d’avoir des équipes IT qui travaillent sur plusieurs applications en même temps. Toyota fait la même chose dans ses usines : une seule chaîne de fabrication pour plusieurs modèles de voitures (avec les options). Le plan de production (ce que l’équipe doit produire aujourd’hui) dépend de ce que qui est attendu par les clients et pas de ce que l’équipe a envie de faire. C’est la même chose chez Toyota : les voitures sont fabriquées dans l’ordre des commandes des clients.

Un environnement complexe

Une application Web peut contenir des milliers, voire des centaines de milliers de lignes de code qu’il faut assembler tout en intégrant des flux de données. Une voiture, en générale, c’est 30 000 pièces. Une belle boîte de Lego® !

Les pièces de voiture peuvent venir de multiples fournisseurs avec lesquels il est nécessaire de se coordonner sur les livraisons, la qualité des pièces… Il en est de même en développement logiciel, sauf si vous travaillez tout seul dans votre coin, et encore.

Certains sont surpris qu’on parle de pièce dans l’IT, comme dans l’industrie. Mais, un fichier code source, un fichier de paramétrage, un fichier CSS… ne sont rien d’autre que des pièces d’un logiciel informatique, de l’application Web. Une US (User Story) est la représentation physique – une pièce – de quelque chose d’immatérielle. Dans les entreprises IT qui pratiquent vraiment et durablement le Lean, les équipes parlent de pièces qui entrent, qui sortent, qui stagnent… Régis Médina (auteur de Learning to Scale et sensei) l’explique bien dans le podcast de Julie Chevalier (Startup, Scale up, Entreprise Industrielle ou de Service).

Un niveau de qualité

Bien évidemment, la qualité est naturellement présente dans tout ce que nous faisons (produit ou service). Que ce soit pour l’application Web ou pour la voiture, si la qualité n’est pas au rendez-vous alors les clients ne seront pas présents.

Fabriquer une voiture avec des défauts ? Ce sont des rappels de véhicules à plusieurs millions d’euros et une image qui se dégrade. La même chose dans l’IT ? Oui, certains défauts peuvent avoir des conséquences très importantes (défaut de système de paiement, flux de données mal maîtrisés ou pire…)

Exemple réel que je connais bien, car j’étais encore dans cette entreprise à ce moment-là. (Google est votre amis) :

• +1 million de transactions non traitées pendant les jours précédant Noël suite à un problème chez un opérateur (l’entreprise dans laquelle je travaillais) gérant les flux de transaction de paiement ;
• indemnisation vers les magasins lésés : 5 millions € (+ gratuité des transactions pour la même période sur les 2 années suivantes) ;
• tous les médias belges et français en parlent : image de marque dégradée ;

Mais certains diront qu’ils ne sont pas dans ces cas-là.

Le lean, ce n’est pas pour moi ! Ou la peur de l’inconnu

Dire « Le lean, ce n’est pas pour moi ! » est, dans la grande majorité des cas, l’expression de la peur de l’inconnu. C’est nouveau, on ne connaît pas, les personnes sont peu habituées aux changements qui les touchent dans leurs manières de faire.

Quand j’ai commencé à nager, mon premier entraîneur m’a dit ceci :

« Ne te bats jamais avec l’eau, elle aura toujours raison ! »

J’avais 7 sept ans et quarante-cinq ans plus tard, je m’en souviens comme si c’était hier. Je dis la même chose à mes enfants qui apprennent à nager. Ce message voulait dire que je devais apprendre à utiliser l’eau. À m’appuyer sur elle pour ne pas m’épuiser et pouvoir avancer. D’abord doucement, puis de plus en plus vite. Avec des gestes de plus en plus précis et efficaces tout en consommant moins d’énergie.

La natation, comme beaucoup d’autres sports, est un sport exigeant qui nécessite des heures et des heures d’entraînement pour améliorer ses gestes (entrée de la main dans l’eau, gestes sous l’eau, position de la tête pour respirer sans réduire la dynamique…). C’est une sorte de kata comme dans le karaté.

Il en est de même pour le Lean Management dans l’IT, dans les services, dans l’industrie, dans la santé… du moment qu’il est correctement pratiqué. Le Lean, c’est l’eau. Si on se bat contre la démarche, elle nous renverra toujours à nos problèmes de qualité, de vitesse, de compétence, de surcharges de travail, de variabilité… Si on apprend à l’utiliser, un peu chaque jour, à la pratiquer de mieux en mieux, on devient un grand sportif !

Mais certains diront que la natation, ce n’est pas comme développer une application 😅

Le lean se déploie à l’extérieur de Toyota

Je connais des personnes, d’anciens salariés de Toyota, qui ont été formées au Toyota Production System (TPS, on ne parle pas de Lean chez Toyota). Ils travaillent depuis soit dans la grande distribution, soit dans des laboratoires d’analyse (pour le BTP, par exemple), tout en appliquant et transmettant leurs connaissances du TPS / Lean.

Allez, une dernière de Toyota :

“Before you say you can’t do something, try it.”
_{Sakichi Toyoda, fondateur de Toyota}