Débutant

Kanban Day 2015 : Toyota Boshoku / Faurecia

KanbanDayLe 28 mai dernier a eu lieu le Kanban Day 2015, un nouvel événement permettant aux praticiens du Kanban et de l’Agilité de se retrouver pour partager leurs expériences et savoir-faire. Une jolie surprise de cet événement est la session Toyota Boshoku / Faurecia.

Cette session fut présentée par Matthieu Moulin. Il s’agit d’une rétrospective sur une expérience professionnelle chez Faurecia, entreprise valencienne travaillant pour Toyota Boshoku. Le sujet est donc de raconter comment fonctionne le Lean dans la perspective, non pas des méthodes agiles, mais de celle d’une journée-type dans une usine d’assemblage automobile.

Cette session a eu le mérite de mettre fin à certains mythes : si vous êtes persuadés que Kanban est une méthode agile ou que le Lean est une philosophie agile pour réduire les coûts, vous avez manqué quelque chose si vous n’avez pas pu y assister.

Voyage au pays du Lean

Après une mise en contexte rapide dans le monde des usines automobiles, la session est organisée autour d’une journée-type d’un travailleur dans une usine d’assemblage. Dans le cas qui nous intéresse, cela concerne le montage des sièges avant de la Toyota Yaris. Nous ne sommes donc pas dans un contexte agile, pourtant des notions communes nous interpellent rapidement :

  • Les cérémonies permettant aux équipes de faire le passage de relais dans une organisation en 3×8.
  • L’utilisation massive du management visuel et la capacité à voir instantanément l’état de la production à un instant.

Analogies confondantes (Copyright : Toyota UK, via Flickr)

Analogies confondantes (Copyright : Toyota UK, via Flickr)


Donc, avant même d’aborder ce qu’est un Kanban, on retrouve beaucoup de similitudes avec l’Agilité. On comprend rapidement que le Lean, formalisé à partir du TPS (Toyota Production System), n’est pas juste une approche permettant de chasser le gaspillage, réduisant celui-ci à un simple système permettant de maximiser les bénéfices.

Toyota c’est avant tout une entreprise qui a failli disparaître et qui, pour survivre, a dû renouer avec la capacité à faire de l’argent dans les années 60. Nous sommes donc loin de la maximisation de bénéfices, mais plutôt dans une logique où, pour rester en vie, il faut prendre la décision la plus pragmatique possible instant après instant.

« Le Lean n’est pas un système servant à réduire les coûts »

Cette façon d’établir une stratégie par des règles simples et pragmatiques, en étant ancré dans le présent et non l’anticipation, est très culturelle. Le jeu de Go, équivalent des échecs en Asie, est très représentatif de cette façon d’aborder la survie, en gérant avant tout le moment présent. Le Toyota Production System prit naissance dans ce contexte, afin de solidifier et surtout pérenniser l’entreprise, en augmentant sa résilience et non ses profits.

L’origine du Kanban

Le Kanban n’est pas un grand tableau où l’on déplace un post-it de colonne en colonne. Ce n’est pas une méthode agile. Kanban est un terme japonais pour désigner un panneau d’indication. Dans le contexte d’une usine automobile, c’est une fiche cartonnée fixée sur les caisses contenant les pièces à assembler sur une chaîne de montage. Pour plus de renseignements, voici l’article Wikipedia sur Kanban et sur l’utilisation d’origine de ce terme.

Historiquement, voici ce qu'est un kanban

Historiquement, voici ce qu’est un kanban

Cette session rappelle qu’il ne suffit pas d’utiliser un outil pour faire en sorte qu’une organisation devienne agile. D’autant plus quand l’outil en question n’a rien à voir avec l’Agilité. Par exemple, le fait d’utiliser un tournevis ne suffit pas à justifier que l’on fasse de la mécanique et non de la menuiserie, cela dépend uniquement de ce que l’on en fait.

«Le kanban, historiquement n’est pas une méthode agile, ni même un outil agile, juste un outil »

Les indicateurs clefs

Comme à chaque fois que l’on aborde l’utilisation de Kanban, les notions de temps de cycle, de cadence, et de délai de mise en œuvre sont abordées. Par contre, la notion de l’encours prend une dimension très intéressante dans le contexte d’une chaîne de montage. L’encours est tout ce qui se trouve entre l’approvisionnement en amont et la livraison en aval. Cela comprend donc :

  • Toutes les pièces en cours de montage
  • Les stocks
  • La demande

Plus on a de visibilité au niveau de la demande, plus on peut anticiper et réduire les stocks. Cela appuie la nécessité de réduire la variabilité, afin de lisser la production (Heijunka). La notion de stock existe dans l’utilisation IT de Kanban : par exemple, un indicateur est la limite haute de l’encours d’une activité. Un système qui reste fluide avec une limite haute faible indique une bonne santé du système.

Un principe fort qui a été rappelé dans l’utilisation des formules pour ajuster un système Kanban est le suivant :

« On ne fait pas coller le système au résultat d’une formule, on fait ce qu’il faut pour que le système fonctionne, et on itère pour ajuster et trouver le bon nombre »

Des applications à l’agilité

Si le Lean n’est pas, par définition, une approche agile, il met en avant des principes qui sont communs avec l’Agilité. On pensera, par exemple, à l’importance que l’on donne à la résolution des problèmes, pour s’améliorer.

J’ai été très surpris sur le retour d’expérience de l’usine de montage concernant la gestion des problèmes et ce que l’on appelle le principe du « Stop The Line ». Pour beaucoup, le Stop The Line signifie qu’en cas de problème, on arrête tout, on se rassemble pour résoudre le problème et on continue. Dans le cas de l’usine d’assemblage, une poignée rouge est tirée en cas de défaut constaté. Par contre cela ne stoppe pas la production pour autant. En effet la finalité, est de signaler le problème, d’attirer l’attention de l’équipe sur ce dernier. Ensuite une fiche est remplie et accompagne la pièce défectueuse qui atterrit dans un bac rouge. De cette façon, on s’assure que le problème est pris en charge. Donc, on n’arrête la ligne de production que si c’est nécessaire, le point étant surtout de signaler le défaut et de solidariser toute l’équipe sur la résolution du problème.

Dans les équipes agiles, quand le serveur d’intégration continue ne parvient pas à construire un livrable, du fait d’une modification d’un collaborateur, on constate un phénomène « bonnet d’âne ». Le principe du Stop The Line n’encourage pas ce comportement, au contraire.

 « La poignée rouge, en cas d’incident, sert à signaler un problème pour que l’équipe se concentre  dessus et non à arrêter la ligne de production »

Revenir aux sources permet de voir que le plus important n’est pas de coller à un système de règles, mais de savoir rebondir face à une situation nouvelle. Attention aux dogmes, donc. L’Agilité doit normalement challenger une organisation sur sa capacité à coller à des principes forts, et non sa capacité à créer des règles.

La résolution des problèmes, dans le cas de l’usine de montage, montre une chose qui est commune à l’Agilité. Les outils sont parfois complexes, le 8D par exemple n’est pas simple du tout à maîtriser. Le plus important n’est pas la connaissance exacte de comment utiliser l’outil, mais plutôt l’acquisition de l’expérience en l’utilisant régulièrement, la pratique étant très importante. Une approche scolaire des outils empêche souvent de résoudre les problèmes.

« Résoudre les problèmes s’apprend par la pratique et non par l’apprentissage des outils »

Nous retrouvons ce qui a inspiré le management visuel dans la conception des espaces de travail dans l’usine : tout doit être visible dans l’usine, en un coup d’œil on doit tout pouvoir analyser.

Une session qui a du sens

Matthieu Moulin a beau ne pas être un agiliste, en tout cas c’est ce qu’il déclare, sa session a été particulièrement utile à tous les agilistes présents, en leur permettant de sortir de l’approche outils grâce à une approche historique revenant aux sources. La session s’est achevée sur l’anecdote de la rencontre entre Matthieu et Maître To-Yoda, dont a découlé un échange mettant en valeur le principe suivant :

« Il faut traiter la complexité en rendant des choses difficiles simples »

Cela pourrait être la devise de tout agiliste. Si nous analysons le Manifeste agile, “les individus et leurs interactions plutôt que les processus et les outils”, l’importance du facteur humain est commune avec le Lean. L’agilité, comme le Lean, sont des transformations avant tout basées sur le pragmatisme auquel on ajoute des principes qui nous garantissent de ne pas dériver. Cette session nous a donc permis de revenir certes aux sources, mais surtout aux bases. Une agréable surprise dans le cadre de ce Kanban Day 2015.

Nombre de vue : 135

COMMENTAIRES 1 commentaire

  1. Au début des années 2000, on m’avait dit “l’informaticien est le nouvel OS (Ouvrier Spécialisé)”. L’un produit des objets concrets, l’autre produit des lignes de code. L’un et l’autre ont la même reconnaissance managériale.

    Il est donc logique de leur appliquer le même type de gestion, surtout quand celle qui fonctionne bien est celle qui reconnait la prédominance de l’humain.

AJOUTER UN COMMENTAIRE