Blog de Bruno Orsier

Un article de Bruno Orsier    3 Commentaires

Dans l’atelier I’m not a Bottleneck! I’m a Free Man! les participants reçoivent des chocolats en guise de salaire et de primes (partage du profit). C’est très important pour la convivialité de l’exercice (la douzaine de participants ont joyeusement englouti les quatre sacs de bonbons et chocolats que j’avais apporté – un conseil, prévoyez large), mais c’est surtout important pour illustrer les métriques de la théorie des contraintes. Ces métriques aident à prendre des décisions et à mesurer l’efficacité des actions prises.

Ce billet illustre ces métriques avec les données issues de l’atelier de vendredi.

Ces métriques font partie d’une discipline appelée Throughput accounting, qui semble importante pour les méthodes agiles. Un livre de référence semble être Agile Management for Software Engineering par David J. Anderson, mais je ne l’ai pas encore lu… Si vous l’avez lu, merci de commenter ce billet !

Durant l’atelier ces calculs pour les chapeaux et avions en papier ont été fait en unités « chocolats », c’est-à-dire une feuille vaut tant de chocolats, une paire est vendue tant de chocolats, etc.

Il faut tout d’abord calculer trois variables :

1. Throughput (flux) : mesure de ce qui sort de notre système, généralement en euros (produit des ventes) mais pas obligatoirement. Pour une organisation caritative ce pourrait être un nombre de repas distribués par exemple. Dans l’atelier c’est le produit des ventes des paires produites (les ventes sont en unités « chocolat ») moins les primes (qui servent à partager le produit des ventes).
2. Investissement : l’argent qui est contenu (et bloqué) dans le système pour assurer la production (machines, bâtiments, matières premières). Dans l’atelier ce sont les feuilles de papiers que l’on consomme (en unités « chocolat »).
3. Dépenses opérationnelles : l’argent dépensé pour la réalisation du flux en question (salaires, maintenance, locations, électricité). Dans l’atelier ce sont les salaires (chocolats).

Comme l’indiquent les inventeurs de l’atelier, l’amélioration d’un système doit se faire d’abord en essayant d’augmenter le flux, puis en essayant de diminuer l’investissement, et en dernier recourt en essayant de diminuer les dépenses opérationnelles.

A partir de ces trois variables on calcule deux quantités :

• le profit net = flux moins dépenses opérationnelles
• le retour sur investissement (ROI) = profit net divisé par investissement

Voici ce que cela donne sur les trois sprints de l’atelier de vendredi, durant lequel 0 puis 2 puis 4 paires ont été produites, par 7 d’abord et 8 personnes ensuite.

Comme le montre la figure, le ROI augmente très rapidement au fil des sprints ! Le fichier Excel avec ces calculs est disponible ici, si vous souhaitez jouer avec les paramètres. Vous pouvez notamment constater qu’avec la forte augmentation du ROI, on peut diminuer le prix de vente des paires, ou augmenter les salaires, ou les primes, etc.

Pour finir, quelques notes sur l’animation de l’atelier :

• J’ai peut être été trop insistant sur la prioritisation des objectifs (1- produire le maximum de paires, 2- minimiser la quantité de papier consommée). En tout cas les participants se sont calés sur le rythme du goulot dès le premier sprint, donc nous n’avons pas bien constaté l’accumulation de produits devant le goulot. Il est vrai aussi que les participants étaient tous formés à Scrum, et de plus sensibilisés aux gaspillages du Lean (Software Development). Par contre on a bien constaté l’inactivité derrière le goulot. 
• Dans le deuxième sprint, la qualité des produits était excellente, mais cette qualité a un peu baissé dans le troisième (tout en passant tout de même les tests d’acceptance), en raison du changement de système que nous avions réalisé. Un tel effet est prédit par la théorie, cela fait partie des coûts de l’élévation. En fait il aurait fallu faire un quatrième sprint pour maîtriser tous les changements, mais nous avons manqué de temps (les 3 sprints plus les explications théoriques nous ont pris toute la matinée).
• dans le troisième sprint, j’ai proposé de transformer un des observateurs en « chef d’équipe » (c’est pourquoi il y a une personne de plus dans le calcul ci-dessus), afin d’aider les autres membres de l’équipe. Toutefois cela a plutôt créé un peu de pagaille, car mal formé le chef d’équipe apportait surtout de l’agitation supplémentaire. Dans le débriefing les membres d’équipes ont trouvé qu’il aurait fallu que le chef d’équipe n’intervienne que sur leur demande. Un point intéressant car c’est le principe des ateliers Lean me semble-t-il.
• Le jeu comporte un rôle de « Production », qui consiste à faire les mêmes tests que dans le rôle précédant, « Testeur », et à compter les paires. Ce rôle apparaît comme redondant dès le départ, et n’est donc pas facile à expliquer (il n’y a pas d’indication précise à ce sujet dans la description du jeu). Je me suis tiré en expliquant que ce rôle était en fait chez le client : en raison de la mauvaise qualité des produits qu’on lui livrait jusqu’a présent, le client était obligé de tous les revérifier. Dans les sprints 2 et 3 nous avons éliminé ce rôle en l’intégrant dans le reste de la chaîne de production. Je ne sais pas si quelle était l’intention précise des concepteurs du jeu, il faudra tirer ce point au clair.