La newsletter de l’Institut Lean France : kanban, e-kanban, Lean et informatique

246_logo-ILFNous avons le plaisir de vous faire parvenir la nouvelle e-letter de notre partenaire, l’Institut Lean France, rédigée par Michael Ballé, membre fondateur de L’Institut Lean France.
Lors d’un gemba walk en République Tchèque, j’ai eu l’occasion de voir un e-kanban dans l’usine d’un grand groupe américain.
L’usine, au format défini dans le milieu des années quatre-vingt-dix, propre et bien tenue, un bâtiment récent, des équipements souvent de seconde main, des stocks pléthoriques sur une plate-forme, et une productivité de la main d’œuvre et du capital aussi décevante que ce que l’on trouve dans nos usines (ce qui, d’un certain coté, est assez rassurant).

Et partout, des slogans « Lean », des affichettes du « système de production » de l’entreprise, des panneaux bourrés d’indicateurs qui cachent les cellules sur le terrain, tout le bataclan du faux Lean que l’on connaît bien.
Le e-kanban est en fait une version informatique des kanbans rouge/vert d’antan (sans lanceur).
Le point positif est qu’en moyennant la demande sur la cellule, le e-kanban permet de travailler avec moins de stocks qu’auparavant. En revanche, l’opérateur doit piloter ses changements pour maintenir les stocks de produits finis en état « vert ». L’opérateur n’a aucune notion de sa performance de livraison, ni d’effort de kaizen particulier à faire. Le e-kanban est calculé pour optimiser les changements d’outils, c’est à dire en faire le moins possible sans exploser les stocks ou tomber en panne.L’outil informatique fait ce qu’on lui demande de faire : il reflète les buts de ses concepteurs. En l’occurrence, le e-kanban dénature complètement le kanban non pas parce qu’il est codé, mais parce que la logique du kanban, trente ans après la découverte du juste-à-temps en occident est encore et toujours comprise à l’envers.

Le but d’un kanban est de :

  • Reproduire la demande client le plus fidèlement possible de façon à forcer les cellules à être plus flexible. En commençant par un calcul de takt time pour la cellule, puis de takt time par produit il est possible d’établir un plan pour la journée. En s’imposant des lots de productions fixes en temps (qui permettent de suivre un multiple du takt time), on permet à l’opérateur de se concentrer sur sa valeur ajoutée : changer les productions à un rythme constant et observer tous les problèmes de rebuts, changements, fiabilité des équipements et manque matériaux qui l’empêchent de tenir le plan : le kanban est ainsi un outil de kaizen, et non l’inverse. Les objectifs du kanban sont donc le taux de service et la fréquence des changements d’outils (et donc la réduction du temps de changement).
  • En revanche, dans l’usine, le but du « e-kanban » est de piloter le stock pour arriver à livrer pas trop mal sans trop augmenter les stocks. Les deux obsessions du patron de site sont le TRS de ses machines et le ratio direct/indirect. Par conséquent la fonction logistique est presque inexistante et souvent assurée par des opérateurs de production, avec, pour conséquence une productivité très faible et une confusion totale des flux.

Comme vous pouvez imaginer, la conversation ne fut pas simple. Toutefois (et de manière assez surprenante) l’équipe qui avait développé ce e-kanban était réellement intéressée par le Lean et avait lu de nombreux ouvrages. Au bout de quelques heures de bataille sur le terrain, l’une d’entre eux finit par conclure : « ce n’est pas étonnant que notre système soit si complexe, nous somme montés sur le cheval à l’envers et ce n’est pas facile de chevaucher en regardant la croupe ».

L’équipe s’était préparée à un débat e-kanban contre cartes physiques. Ils ne s’attendaient pas à une mise en cause des principes de base du kanban. Les systèmes IT sont des outils puissants pour faire ce que l’on veut, mais ils reflètent toutes les hypothèses implicites de raisonnement, et c’est pourquoi il est recommandé de faire marcher le système avec papier et crayon avant de le coder.

Une question profonde pour le Lean en IT concerne le principe de Jidoka de « séparation des personnes et des machines » : comment s’assurer que la personne reste meneuse et non pas prisonnière du système. Pour cela, cette visite de site montre qu’en identifiant les variables que le système cherche à optimiser, il est possible d’en comprendre la logique profonde. Comment s’assurer qu’on ne chevauche pas le cheval à l’envers sans s’en rendre compte ? La pensée Lean, sur ce point, est assez claire :

  1. La précision des livraisons – mesurer le taux de service de toute activité
  2. Par le takt time : en moyennant la demande client (pour effacer les variations) et en créant des séquences de travail qui correspondent à un idéal de livraison
  3. Ce qui nécessite flexibilité et disponibilité des équipements (et équipes) pour s’en tenir rigoureusement au plan
  4. Ce qui fait ressortir toutes sortes d’obstacles concrets
  5. Ce qui permet d’aborder des sujets de kaizen un par un et de développer les compétences des équipes par la résolution de problèmes.

Un système informatisé de gestion de production saurait-il suivre cette logique ? C’est, de mon point de vue, un des principaux challenges de l’IT Lean.

Venez échanger sur les challenges de l’IT Lean avec les pionniers du Lean IT et les principaux experts du Lean et de l’Agile au Lean IT Summit les 16 et 17 octobre à Paris. Téléchargez le programme du Summit.A noter dans vos agendas : Journée technique Lean Supply Chain animée par Alain Prioul le 5 novembre à Paris.