Pour faire suite à l’article Le Management Visuel, pour quoi faire ?, je vous propose de voir plus en détails une des techniques du Management Visuel du Lean Management, le Kanban.

Le Kanban est un des éléments-clés du Just-In-time (JIT) du Toyota Production System (TPS). Pensé par Taiichi Ohno dès les années 1950 (lire Taiichi Ohno’s Workplace Management), le Kanban vise à atteindre l’idéal du one-piece flow (nommé également flux continu) tiré et rythmé (takt) par la demande du client.

Le Kanban, sorti de l’industrie automobile, s’est progressivement transformé en un tableau de Management Visuel (service, IT…). Pour autant, il est faux de croire que les cartes Kanban physiques ont disparu. Elles sont toujours présentes dans nombre d’usines et notamment celles de Toyota et de ses fournisseurs dont les processus de fabrications sont connectés à ceux de Toyota (voir les principes du flux des processus connectés décrits par Jeffrey Liker par exemple).

Kanban, c’est quoi ?

Kanban veut dire signal en japonais. Ce signal est le plus souvent matérialisé via une carte (ou fiche cartonnée). C’est l’objet qui va traverser le flux de valeur. Cette fiche cartonnée représente le produit ou le service que le client a demandé (ou un sous-élément de ce produit ou service). On trouve 2 types de carte Kanban : 1) instruction de production et 2) instruction de livraison.

Mais il est important de ne pas se tromper de sens, comme l’indiquent les auteurs de La Stratégie Lean dans leur article Kanban As A Learning Strategy sur Lean.org :

The misunderstanding is that Kanban is about the cards – Kanban is about measuring the response time on every individual demand, a very different concept. In essence, the flow of Kanban cards is a key circulatory system in a learning organization. »
_{Source : Kanban As A Learning Strategy, M. Ballé, D. Jones, J. Chaize, O. Fiume, Lean.org, 2019}

Concrètement, pour un Management Visuel, le Kanban représente à la fois la petite fiche (autocollante ou non) et le tableau sur lequel elle se trouve.

Pour les distinguer, nous parlerons de fiche Kanban et de tableau Kanban.

Kanban, pour rendre visible

Taiichi Ohno disait à propos du Kanban :

“The aim of kanban is to make troubles come to the surface and link than to kaizen activity. I tell people, ‘Let idle people play rather than do unnecessary work.’”

Et c’est bien la finalité d’un tableau visuel de type Kanban : rendre visible dynamiquement les problèmes pour les résoudre les uns après les autres. C’est ce qu’écrivent également les auteurs du livre The Lean Sensei :

“Both andon and kanban were test mechanisms: systems to highlight delivery problems in real time, as and when they happened, so that they could be fixed (with ‘kaizen’, small, continuous step by step improvements) and learning could be capitalized by ongoing upgrading of standards.”

Ou encore Jeffrey Liker et David Meier dans The Toyota Way Fieldbook, a practical guide for implementing Toyota’s 4Ps :

“Sustaining continuous flow also serves to surface any problem that would inhibit that flow. In essence, the creation of flow forces the correction of problems, resulting on reduce waste.”

Personnellement, j’aime la phrase de Michael Ballé à propos du Kanban :

“Kanban is magic because it’s relentless – you can’t argue with the kanban.”

C’est également un formidable outil de communication facilitant les échanges entre les différents membres de l’équipe, mais également avec les parties prenantes (le métier par exemple dans l’IT). En intégrant progressivement le métier (pour continuer sur cet exemple) dans la démarche et en connectant son flux de valeur avec celui de l’équipe de développement, le tableau Kanban révélera les difficultés pour tenir un flux continu tiré par la demande client et avec le bon niveau de qualité à chaque étape des processus connectés.

Bien que ce ne soit pas sa finalité, le tableau Kanban et les points quotidiens d’animation remplacent avantageusement les réunions et comité de suivi de projet. Les parties prenantes étant présentes aux points devant le tableau Kanban, elles ont donc accès à l’ensemble des informations.

Kanban, pour comprendre

Utiliser un Management Visuel, c’est bien, mais il doit servir à comprendre :

• les attentes du client (besoin, délai, qualité…) ;
• le produit ou le service réalisé : l’équipe produit-elle ce qui est nécessaire pour répondre aux besoins du client ?
• le processus pour construire le produit ou le service : est-il efficace (avant d’être efficient) ? Produit-il encore des gaspillages (attente, retouche, transport, geste inutile, étape inutile, stock et surproduction) ?
• l’équipe : a-t-elle toutes les compétences nécessaires pour réussir à tout moment (y compris pendant les absences de certaines personnes-clés) ? Quelles sont les personnes disponibles aujourd’hui ? Quels sont les irritants de l’équipe que le responsable d’équipe et son manageur doivent traiter rapidement pour aider l’équipe à réussir ?

Cécile Roche nous précisait, lors d’une de ses présentations, que le Management Visuel, c’est

«travailler en équipe pour savoir quelles sont les choses importantes à mettre sur les murs qui vont permettre au bon moment de prendre la bonne décision. Suivant chaque cas, il va falloir réfléchir.»

Souvent, nous voyons des équipes nommer Kanban un management visuel «À faire / En cours / Fait». C’est un abus de langage. Certes, il y a les petites fiches (autocollantes ou non), mais ce qui est important dans un Kanban, c’est la matérialisation du flux de valeur ; c’est-à-dire le processus de création du produit ou service. Or, la colonne nommée «En Cours» n’est pas un processus. Si l’équipe traite des tickets de support, le tableau Kanban doit matérialiser le processus de traitement des tickets. Si elle développe du logiciel, le tableau Kanban reproduit le processus de réalisation de l’application. Si l’équipe s’occupe du recrutement des nouveaux collaborateurs, alors le tableau Kanban représentera le processus de recrutement.

Le Kanban s’inscrit – comme tout principe Lean – dans un système d’apprentissage (comprendre le processus, voir le flux qui bouge ou non, voir la non-qualité et agir pour 1) protéger le client et 2) résoudre pour supprimer définitivement les occurrences des problèmes), comme le dit Isao Yoshino

“Process to attain your goals is as important as its result. If you have good results without a good process, you are lucky… but you are not learning.”

En rendant visible le processus et les problèmes qu’il génère, l’équipe peut agir sur le processus lui-même (en faisant de la résolution de problème avec des PDCA) afin d’améliorer la qualité des pièces et accélérer leur réalisation.

Kanban, pour apprendre

Michael Ballé et Godefroy Beauvallet écrivent dans Le Management Lean :

«La valeur du kanban est d’être un vecteur de progrès, car il permet de tirer les flux et donne une architecture aux efforts d’amélioration. Ce n’est pas un système de production, c’est un système d’amélioration continue.»

Le Management Visuel Lean, dont fait partie le tableau Kanban, est un révélateur dynamique de problèmes. C’est en pratiquant durablement le Kanban que s’ouvrent les portes de l’amélioration continue, que je qualifierai de «profonde», car les changements auront un impact structurel durable sur l’entreprise. Ces améliorations porteront sur le respect des engagements de livraison, la réduction du lead-time et, par voie de conséquence, sur la valeur produite par le processus.

Rendre visible le flux (processus de création de valeur) permet de mettre en évidence que tout ne se passe pas de façon linéaire et fluide. Passer d’un flux poussé à un flux tiré permet de changer le fonctionnement des équipes qui passent du mode «Je fais ce qu’il y a à faire» à «Je fais ce qu’il y a à faire en fonction de ce que la prochaine personne (ou la prochaine équipe) a besoin».

Contrairement à ce qu’on pourrait croire, le but du Kanban n’est pas d’adapter la vitesse du flux (lead-time de la pièce qui traverse le flux de création de valeur) au contexte de l’équipe, comme le précise très bien ici Sandrine Olivencia :

“The aim of kanban is not to reduce WIP to match a team’s capacity and to reduce cycle time as agile teams would.”

Bien au contraire, le Kanban permet de révéler tous les problèmes (souvent les uns après les autres) qui empêchent l’équipe de délivrer juste ce qu’il faut, en temps et en heure selon la demande du client, ni plus ni moins. Ce n’est donc pas à l’équipe ou à l’entreprise de décider du rythme de la production, c’est aux clients au travers du rythme (le fameux takt) des commandes.

C’est en se questionnant quotidiennement que l’équipe s’améliore, comme l’indique les auteurs de La stratégie Lean :

«Clé de la qualité et de l’apprentissage, le kanban ne se met jamais en place facilement. Le kanban affectera les capacités à mesure que les tâches en cours seront effectuées plus rapidement et celles en souffrance absorbées de même.»

Les mêmes auteurs précisent leur pensée sur Lean.org :

“In using Kanban we’re not implementing a solution, we are looking for the next step to improve so that we will discover new ways of doing things through teamwork between all stakeholders.”

Un jour, lors d’une formation d’initiation au Kanban dans l’IT, une personne me disait en partant que le Kanban n’est pas adapté à l’agilité car c’est trop rigoureux, trop de contraintes… Ce qu’elle oublie, c’est que pour devenir une équipe agile, il faut beaucoup de rigueur dans la définition et l’usage des règles que l’équipe met en œuvre. De plus, le Kanban s’applique très bien dans des environnements agiles (IT ou même ailleurs) et permet souvent à des équipes pratiquant déjà l’agilité (Scrum ou autre) d’aller beaucoup plus loin.

D’autres souhaitaient mettre dans leur tableau Kanban toutes les pièces qu’elles réalisent au quotidien ; chose impossible si ces pièces n’ont pas les mêmes étapes de fabrication. Choisir son Kanban, c’est choisir le processus sur lequel l’équipe veut s’améliorer ; c’est un choix stratégique à déterminer en fonction des retours des clients, car le but ultime du Kanban, comme du TPS, est de satisfaire pleinement ses clients.

Michael Ballé précise ici :

“The spirit of kaizen is to bring value closer to the final customer. Without Kanban, you can be practicing what you believe is kaizen, but you actually have no compass, no direction-setting, practical, visual, here-and-now tool to see whether the new idea is a step in the right direction or just a random change.”

Pierre Jannez écrit dans son article Scrum Et Le Toyota Production System, Comment Construire Des Équipes Ultra Performantes :

«Il faut considérer le TPS comme un échafaudage dont le but est de rendre visible les problèmes au moment où ils apparaissent. Il faut d’abord construire le système puis le faire fonctionner : 1) Construire le bon management visuel 2) Tirer le flux 3) Identifier les bons problèmes 4) Résoudre les problèmes 5) En tirer les bons enseignements.»

C’est en acceptant de voir tous les problèmes – avec le support du management – et en les résolvant les uns après les autres que l’équipe arrivera, progressivement et par petits pas, à répondre aux attentes de ses clients (fonctionnalité, qualité et vitesse) pour les satisfaire complètement.

Kanban, respect des personnes

Pour réussir, il est nécessaire que les postures managériales soient en capacité d’accepter les problèmes pour apporter tout le soutien et le support nécessaires aux équipes pour les aider à les résoudre. C’est ce que précise Sandrine :

“[…] condition for kanban to work is putting in place a management ‘chain of help’. This means that managers must continuously support teams in resolving tricky problems revealed by the kanban system. This is first a mark of respect that contributes to creating mutual trust between managers and employees.”

et d’ajouter :

“This requires a change of attitude from managers who must support and challenge their teams instead of commanding and controlling them.”

Dans un article sur Lean.org, Michael Ballé décline les compétences Lean additionnelles que doit acquérir un team-leader pour pratiquer le Kanban avec son équipe :

“A kanban system requires additional lean skills from a team leader:
– Know quality characteristics and job sequence;
– Train to standards;
– Upkeep visual management, spot abnormalities;
– Grasp kaizen points;
– Pay attention to preceding and following processes.”

Cécile Roche nous partageait il y a peu son retour d’expérience suite à un Gemba dans son entreprise du sensei Isao Yoshino (lire son article ici) qui explique l’importance des mauvaises nouvelles (problèmes) :

“Bad news first is not for teams, but for managers. It’s a sign of respect for people. Managers who say ‘bad news first’ loud and clear send an extremely positive message to their team. First they tell them ‘it is normal to have problems’ and then ‘I am here to help you.’”

Conclusion

Michael Ballé conclut ainsi son article :

“There’s only one conclusion: if you’re not using Kanban, you’re probably doing something great and improving things here and there, but you can’t call it ‘lean’. Kanban is a harsh discipline, but it’s the first step into the bigger world of true continuous improvement.”

Conclusion partagée par Sandrine Olivencia :

“But kanban is just the start: it shows us the path to improvement, so each person can walk it on their own using kaizen every day. It is the secret to creating a true lean organization. The same way there is no lean without kanban, there can be no kanban without kaizen.”

C’est en pratiquant le Kanban durablement et avec rigueur que la force – celle de transcender les équipes, les processus et l’entreprise – s’installe en vous !

Enfin, je reprendrai les mots de Sandrine Olivencia :

“Kanban is actually a tool for developing and strengthening teamwork across the organization by solving problems together (kaizen).”

Note : article initialement publié par mes soins sur le blog d’Operae Partners et modifié en juillet 2022.