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 :
- La précision des livraisons – mesurer le taux de service de toute activité
- 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
- Ce qui nécessite flexibilité et disponibilité des équipements (et équipes) pour s’en tenir rigoureusement au plan
- Ce qui fait ressortir toutes sortes d’obstacles concrets
- 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.