Eh oui, le kanban est une monnaie virtuelle, auto-générée par un écosystème de production (une usine, une DSI, un process de service) et qui sert à acheter le matériel dont on a besoin pour travailler. Une monnaie qui est utilisée pour accélérer considérablement la livraison des produits, logiciels ou services.

De la monnaie virtuelle à la satisfaction du client

Les ambitions sous-jacentes à l’utilisation du kanban sont à la fois :
1. De caler le rythme de production sur le rythme de commande des clients (produire au takt, en langage Lean),
2. D’avoir un temps de traversée du process égal au temps de construction du produit (produire en flux, toujours en langage Lean).

Le kanban le plus sophistiqué que j’ai compris était dans une usine Toyota de construction de chariots élévateurs : une commande chariot était expédiée 7 jours après la commande par le client. Bien sur, chaque client avait des demandes très spécifiques : poids que devait soulever la fourche, hauteur de la fourche, puissance du moteur, nature du moteur (thermique ou électrique), nature des pneus, etc… Ce délai était parfaitement acceptable pour les clients et l’usine ne produisait que des chariots déjà vendus !

Les kanbans les plus efficaces que j’ai vu mis en œuvre chez Operae Partners ont permis de diviser par 90 des délais de livraison de serveurs ou par 25 des délais d’offres de crédit aux entreprises.
Bref, le kanban, c’est à la fois redoutable en terme d’efficacité, simple à comprendre et, comme toujours en Lean, exigeant en terme de mise en œuvre.

Introduction au kanban

Pour comprendre la magie du kanban, prenons l’exemple d’un process de développement logiciel simplifié : le 1er rédige les spécifications, le 2ème les code et le 3ème les teste.

L’utilisation du kanban a l’air simple :
1. Le testeur achète du code au développeur avec
des kanbans et lui dit qu’il reviendra demain à 9h00

2. Le développeur code pendant la journée

3. Le testeur revient à 9h00. Le développeur lui livre le code.
Le testeur rachète du code et lui dit qu’il reviendra etc…

Principe n°1 – celui qui passe la commande est celui qui est le plus proche du client.
Ici, le testeur passe la commande au développeur et bien sur, le même principe d’achat – production – livraison et ré-achat a lieu entre le développeur et le spécifieur.

Qui passe commande au testeur ? Quelqu’un qui représente le client, un product owner par exemple, ou une personne de la maitrise d’ouvrage, etc… Cela dépend de l’organisation de l’éditeur ou de la DSI.
On parle de créer un “flux tiré” par le client, représenté par les flèches oranges, alors qu’habituellement le travail s’organise par le point d’entrée, en “flux poussé”, représenté par le flux vert du 1er dessin.

Principe n°2 – le paiement déclenche le travail.
Le développeur a les pieds sur terre : il ne codera rien avant d’avoir été payé ! Donc, si le testeur ne lui donne pas son kanban, le développeur est libre de son temps, temps dont il fera tout ce qu’il veut (jouer, dormir, rêver, prendre un café) sauf travailler.

Principe n°3 – le nombre de kanbans est limité (comme le nombre de bitcoins!)
Imaginons que l’ensemble des fonctionnalités produites par l’équipe “spécifieur – développeur – testeur” représente au total 40 unités de valeur et que chacun puisse faire sa quote part de travail sur 4 unités de valeur chaque jour. Il y aura alors au maximum 40 unités de kanban dans la nature, 1 par unité de valeur.

A suivre…. »Le kanban, un bitcoin explosif » dans un prochain billet