Une question que je me pose depuis plusieurs semaines et qu’en toute transparence, chaque dirigeant devrait se poser. Comment devons-nous « construire une vision » et définir des objectifs stratégiques ?

Devons-nous privilégier l’approche facile et la contraindre à une réalité revêche ? Ou, au contraire, adopter une approche plus ambitieuse et résolue et transformer ce que certains identifient parfois trop vite à « la réalité »,  pour l’aligner avec la vision ?

Un dilemme qu’il est nécessaire d’explorer pour comprendre un des freins essentiels à l’amélioration…

Le problème

Très souvent, je rencontre des dirigeants contraints de réduire leur vision initiale (diviser par 2 la non-qualité, livrer 50 % de projets en plus dans les délais, avoir un Net Promoter Score positif de nos clients) en fonction d’obstacles qui leurs sont présentés sous forme d’impossibilité par leurs équipes.

Je pense à ces dirigeants qui se résignent à avoir des problèmes de qualité sur leurs projets IT car les équipes terrain maintiennent qu’il est impossible de ne pas avoir de bugs dans des logiciels. Des dirigeants dans le bâtiment dont les conducteurs de chantier leur expliquent que c’est normal d’avoir des projets qui perdent de l’argent car ceux qui en rapportent compensent pour ceux qui en perdent. Des dirigeants dans des back-offices de services financiers à qui on explique que l’on ne peut pas réduire la durée d’un processus clef, malgré l’effet direct sur le coût du risque. Des dirigeants dans des assurances à qui la DSI explique qu’il n’est pas possible de faire un projet métier pour moins de 3000 jours/homme.

Cependant, ce n’est pas toujours le cas et la résignation n’est pas une fatalité. Il y a de nombreux exemples de dirigeants visionnaires qui ont su mettre leurs équipes dans le bon contexte pour que celles-ci changent de perspective sur une situation vue comme définitive, puis s’attachent à aligner leurs efforts avec la vision pour atteindre des résultats remarquables.

Cela nécessite évidemment de la détermination mais pas seulement …

Exemple 1 : Taiichi Ohno

Bien évidemment, sur un blog Lean on ne sera pas étonné de retrouver Taiichi Ohno comme incarnation du dirigeant résolu. La mission de Taiichi Ohno : transformer les usines de ce grand groupe automobile afin de ne produire que ce que demande le client, quand le client le souhaite, avec une qualité parfaite. Cela a nécessité de mettre en place le flux tiré, avec une production qui tend vers le pièce à pièce (i.e. sans stock intermédiaire – une vision révolutionnaire), où la chaîne de production s’arrête lorsqu’il y a un défaut. Un système dans lequel la production est lissée, par petits lots.

Arrêtons nous sur ce dernier point. Le Heijunka – lissage de la production – est sans doute un des moins évoqués lorsque l’on parle du Lean pour montrer comment la vision de Ohno a du tordre bien des « réalités » pour être mise en œuvre.

Heijunka et lissage de la charge

Supposons que votre entreprise produit les biens suivants : des A, des B, des C, des D et des E. La demande client chaque semaine est la suivante : 80 A (un produit qui marche super bien), 55 B, 60 C, 40 D et 15E (le produit très haut de gamme). Dans l’organisation standard, raisonnable, ces pièces seront produites durant la semaine, dans cet ordre :

• 80 A le lundi
• 55 B le mardi
• 60 C le mercredi
• 40 D le jeudi
• 15 E le vendredi

Cela ne convient pas à Ohno. Il va vouloir que l’équipe produise chaque jour de la semaine ce qui correspond à l’attente du client (une autre épine dans le pied de ceux qui veulent nous faire croire que le Lean c’est juste du bon sens), c’est à dire, quotidiennement :

• 16 A puis
• 11 B puis
• 12 C puis
• 8 D puis
• 3 E

Cette production lissée, s’améliorant en permanence, en viendra à être affinée, heure par heure.

La raison est la suivante : la production est ajustée en fonction de la demande client. On réduit ainsi le risque de produits fabriqués et non vendus (on pense à ces gigantesques parkings où sont empilés des véhicules neufs qui n’ont pas trouvé preneurs). En outre, on lisse aussi la demande au niveau de nos fournisseurs ce qui leur permet de travailler de façon plus harmonieuse. Enfin cela permet de s’isoler de la variabilité externe de la demande pour se concentrer sur la variabilité interne des processus de l’usine, une variabilité (Mura) à éliminer au même titre que les gaspillages (Muda).

Mais c’est impossible !

… a été la première exclamation des ouvriers de Ohno. Pour réaliser cette vision il leur faut être capable de changer de configuration d’outils (en particulier les presses) très rapidement. Or, chaque changement de presse prend à ce moment plus d’une heure. Ohno les fait travailler sur ce sujet particulier : comment surmonter cette « réalité » pour répondre à la demande de la vision.

Et ses équipes, engagées dans une démarche d’amélioration continue permanente, sont parvenues à ramener le temps nécessaire pour le changement d’outil de plus d’une heure à quelques minutes. Ce qui a permis de mettre en oeuvre le lissage de la production au quotidien puis à l’heure. Un des disciples de Ohno raconte qu’il était de toutes façons plus facile de faire l’impossible pour Ohno que de lui faire comprendre qu’une chose était impossible.

Déconstruire la « réalité » pour pouvoir la transformer

Comment Ohno est-il parvenu à obtenir cela de ses équipes ? En appliquant les principes de management du Lean (Toyota Way) : respect des personnes, gemba (terrain), travail d’équipe, amélioration continue et challenge. Ohno est sans cesse sur le terrain (gemba), pour montrer du respect aux équipes en s’intéressant à leur contexte de travail. Il connait parfaitement les contraintes de leurs métiers et va les challenger avec un questionnement très précis.

Ont-ils les moyens de s’approprier leur poste de travail pour l’améliorer ? Leur manager les aide-t-il à voir les gaspillages qu’ils subissent ou qu’ils font subir à leurs collègues ? Ont-ils une vision claire de la valeur qu’ils créent ? Les standards sont-ils mis à jour régulièrement ? Qu’ont-ils résolu comme problème opérationnel cette semaine ? Quels enseignements en ont-ils tirés ?

C’est ainsi qu’il va leur faire entr’apercevoir une réalité différente et désirable. Il ne s’agit pas d’injonctions arbitraires données depuis un bureau confortable par un leader qui ne connait rien des réalités du quotidien des équipes. Il s’agit d’une démarche maïeutique, experte sur le métier, qui va permettre de déconstruire une perception d’impossibilité.

Exemple 2 : Jez Humble et Continuous Delivery

L’auteur de l’ouvrage référence sur le Continuous Delivery a expliqué durant l’édition 2017 du Lean IT Summit comment il a aidé un client à mettre en place cette pratique de livraison de logiciel afin de livrer de la valeur en continu au client. La vision à terme est la suivante : chaque développeur logiciel « commit » sur le tronc chaque heure (ce qui veut dire que chaque développeur copie dans le référentiel de code source principal du logiciel qui fonctionne, chaque heure). Une vision qui nous amène naturellement à la notion Lean de takt dans l’informatique, fréquence régulière à laquelle on livre de la valeur.

Tronc et branches : l’arbre de la discorde

Une proposition qui semble une aberration pour les développeurs. La raison est que les développeurs préfèrent utiliser une branche de code, i.e. un référentiel temporaire qui leur est propre, pour pouvoir élaborer leur code tranquillement durant quelques jours, sans interaction avec les autres développeurs. Puis, une fois la fonctionnalité développée, ils recopient leur logiciel modifié sur le référentiel principal en utilisant des outils pour corriger les collisions de code (parties de code modifiées simultanément par plusieurs développeurs).

Cette deuxième approche présente plusieurs inconvénients. Le volume de modifications de logiciel est alors important (plusieurs jours de travail). Les problèmes d’intégration qui ne vont pas manquer de survenir sont donc beaucoup plus longs à identifier et à corriger. Par ailleurs la recopie du code d’une branche à une autre représente un gaspillage depuis la perspective du client (transport). L’être humain est soumis à des biais cognitifs qui vont l’inciter à minimiser les inconvénients de son approche et en exagérer les avantages : les développeurs sont donc intimement convaincus que l’on ne peut faire autrement. Une « réalité »  qui ne résiste guère à la mesure et aux faits.

L’approche du code sur le tronc chaque heure relève pour nos développeurs de l’impensable. A ce stade nous avons plusieurs choix. Adapter la réalité à la vision (tu « commites » ton code sur le tronc, chaque heure, nous ne faisons pas de branche) ce qui va permettre de supprimer des gaspillages (recopie de code, longues investigations de problèmes d’intégration) et de contraindre à des pratiques vertueuses (du code par petits lots, testés). Autre alternative : contraindre la vision à une certaine « réalité » : ne pas engager les développeurs dans un débat autour de cette croyance et continuer à gaspiller de l’argent avec les branches.

Là encore, dans le retour de cas de Jez Humble, le dirigeant est allé sur le terrain pour comprendre les obstacles que voyaient les équipes. Il les a questionnées pour déconstruire petit à petit chacun de ces obstacles pour qu’ils voient la possibilité d’amélioration radicale que proposait la Continous Delivery. Et ce faisant, il a multiplié par 8 la productivité des développeurs.

Adapter la « réalité » à la vision

Comment calibrez-vous votre vision ? En fonction de ce que vous voulez/devez accomplir ou en fonctions des contingences d’une « réalité » que vous subissez ?