La théorie des contraintes : augmenter son rendement, diminuer son lead-time

Une belle théorie enveloppée dans un roman sympathique

Une lecture aussi enrichissante que distrayante

Réduire radicalement ses encours de développement et augmenter sa productivité pour un investissement minimum : telle est la promesse de la théorie des contraintes. Si l’on ajoute que cette méthode est simple et particulièrement compatible avec une approche agile dans une équipe logiciel, cela fait suffisamment de raisons pour la regarder d’un peu plus près.

La théorie des contraintes (ou ToC pour les habitués) ne date pas d’hier. A la manière du Lean, elle est née dans l’industrie il y a plus de 30 ans et n’a été importée dans le monde du développement que récemment, notamment à l’initiative de partisans de l’Agile. La bible des aficionados de la ToC s’appelle « le But », un roman d’entreprise remarquablement construit qui explique avec une clarté peu commune ses principes et sa mise en oeuvre. Son auteur, Eliahu Goldratt, a ensuite perfectionné son modèle et étendu cette approche au monde des services dans une douzaine d’ouvrages.

Identifier les goulots d’étranglement

Si l’on devait résumer la théorie des contraintes en une phrase, ce serait : « trouvez le goulot d’étranglement de votre système de production, et agissez en conséquence ». En effet, dans un enchaînement de processus, c’est le rythme du plus lent qui conditionne celui de l’ensemble de la chaîne. Imaginez que vous préparez une tarte aux pommes avec un ami : l’un d’entre vous fait la pâte, l’autre découpe les fruits. Ce qui déterminera la vitesse d’exécution de l’ensemble, c’est celui d’entre vous qui aura terminé sa tâche en dernier : inutile d’accélérer la découpe, si quoiqu’il arrive la pâte met plus de temps à être préparée.

Goulot routier

Un exemple de goulot : ce qui détermine le flux, c’est l’endroit où l’écoulement est plus faible (source : wikipedia)

Quand on les cherche, les goulots d’étranglement d’une usine sont assez simples à identifier. Dans une industrie de service comme le logiciel, c’est nettement moins évident. L’organisation des tâches dans un projet logiciel est en effet un système dynamique plus complexe qu’une unité de production manufacturière classique. Là où une usine compte des postes de travail bien définis en général rattachés à des machines spécifiques, le membre d’une équipe de développement va être polyvalent et pourra effectuer au cours de la même journée des tâches de :

  • conception (architecture, modélisation, refactoring)
  • développement (back, front, middleware)
  • tests (fonctionnels, unitaires)
  • configuration et déploiement
  • support et maintenance

… le tout sur des projets potentiellement très différents ! Si ces tâches étaient attachés à des emplacements physiques précis, nous verrions des développeurs changer de poste régulièrement au cours d’une journée, chose peu concevable sur une chaîne de production par exemple.

Malgré cette différence fondamentale, il existe tout de même souvent des goulots persistants dans une équipe menant des projets de développement. Ceux-ci apparaissent aux endroits où une segmentation des responsabilités plus nette s’est faite (de manière préméditée ou non d’ailleurs) : spécifications, tests fonctionnels, ou encore développements front-office sont quelques uns des entonnoirs classiques que j’ai régulièrement rencontrés dans ma carrière.

Pour les identifier, il suffit en général d’ouvrir votre gestionnaire de tâches préféré et de voir ce qui bloque le plus grand nombre d’éléments. Si vous découvrez par exemple que 25% des tâches sont à l’état « en test », il y a fort à parier que le goulot se trouve au niveau de la personne en charge des validations fonctionnelles… ce qui peut paraître peu gênant a priori pour les développeurs mais qui a en réalité de graves conséquences !

Dans ce système dynamique, les goulots peuvent se déplacer : cela signifie donc que, contrairement aux principes habituels de la théorie des contraintes, vous pouvez être amené à travailler sur plusieurs postes en parallèle pour optimiser le tout. Pour faciliter la compréhension, je partirai néanmoins de l’hypothèse que nous avons un goulot unique (approximation en général suffisante) pour la suite de cet article.

Les indicateurs-clés de la ToC

La comptabilité ToC est à la fois simple et opérationnelle pour un manager au quotidien. Elle se résume à quelques chiffres-clés :

  • le Throughput (« flux de sortie » noté « T ») : Chiffre d’affaires brut – coûts totalement variables. Ces derniers correspondent grosso modo aux achats de matière première : ces coûts n’existent donc pas sur les projets logiciels habituels.
  • l’Inventory (ou Investments noté « I ») : c’est l’ensemble des immobilisations, qu’il s’agisse de production immobilisée (les en-cours de production dans notre cas) ou des outils de productions (locaux, machines, licences, etc.)
  • les Operating Expenses (« dépenses de fonctionnement », notées « OE ») : ce sont toutes les dépenses nécessaires au fonctionnement de l’entreprise (ou du service) qui n’ont pas été comptabilisées auparavant. On y trouve principalement des coûts salariaux, mais aussi toutes les charges fixes comme les loyers, les impôts et autres coûts administratifs.

A partir de ces trois catégories comptables, la ToC définit un ensemble d’indicateurs à suivre :

  • Le Net Profit (« résultat net », noté NP) = T – OE
  • Le ROI (retour sur investissement) = NP/I
  • La productivité = T/OE
  • Le cash flow (« flux de trésorerie ») = T – OE – I

Ces définitions (qui font hurler plus d’un comptable) rendent l’optimisation d’une comptabilité ToC beaucoup plus sensible à la réduction des encours qu’une comptabilité classique. Cela nous amène à considérer un indicateur fondamental et trop souvent négligé : le lead-time.

Le lead-time mesure le temps moyen écoulé entre le début de production d’un produit et sa sortie. Un lead-time faible a plusieurs conséquences intéressantes pour une équipe :

  • Cela diminue « I » et augmente donc le ROI et le cash flow
  • Cela augmente la satisfaction des clients puisque les délais moyens sont plus courts
  • Dans le monde logiciel, cela contribue à la motivation des développeurs et des managers qui voient moins de projets traîner dans le temps.

On retrouve en fait ici sous un nouvel angle les vertus des cycles courts prônés aussi bien par les méthodes agiles que par le Lean. Maintenant que les principes sont posés, voyons comment la ToC fonctionne au quotidien.

Les 5 étapes de la démarche ToC

Un des principes forts de la ToC est de concentrer ses efforts d’amélioration là où ça compte le plus. La démarche 5FS (« 5 Focusing Steps ») est là pour le mettre en oeuvre :

  1. Trouver la contrainte : j’ai déjà évoqué ce point plus haut, je n’y reviens pas.
  2. Exploiter la contrainte : il s’agit de mettre au mieux en oeuvre les ressources disponibles pour améliorer la production par unité de temps de la contrainte. Si votre goulot est le poste « développement front », vous allez soulager vos développeurs front de leurs tâches annexes pour qu’ils ne se consacrent qu’à cela.
  3. Subordonner le système à la contrainte : maintenant que votre contrainte fonctionne à plein régime, il faut faire en sorte que les autres étapes produisent à son rythme. On peut appliquer ici le principe du « Drum-Buffer-Rope » : la production est tirée (« rope » => la corde ; on ne produit pas en avance) selon la cadence (« drum » => le tambour) donnée par la contrainte. On doit toutefois toujours laisser un petit stock (« buffer » => le tampon) de choses à faire devant le poste sous contrainte au cas où un incident se produise sur les étapes amont.
  4. Elever la contrainte : si vous voulez passer à la vitesse supérieure, vous devez investir pour augmenter la production de votre contrainte. Vous pouvez le faire soit en améliorant sa productivité, soit en ajoutant des ressources de production supplémentaires à l’endroit où elle se trouve.
  5. Trouver la nouvelle contrainte : en travaillant sur les étapes 2 ou 4, il est possible que vous ayez déplacé le goulot de votre système à un autre endroit. A ce moment-là, on repart pour un tour de boucle façon amélioration continue !
Drum buffer rope

Le Drum Buffer Rope illustré pour une usine classique… mais qui fonctionne aussi pour une usine logicielle ! (source : wikimedia)

Quand et comment utiliser la ToC dans une équipe logiciel ?

Avant de passer à la ToC dans une équipe de développement, je recommande de mettre en place Kanban. C’est en effet une bonne première étape pour plusieurs choses :

  • Formaliser les étapes de votre processus (c’est généralement le cas) d’une manière qui correspond à la réalité du terrain (c’est plus rare !)
  • Améliorer la transparence dans la gestion des tâches
  • Commencer à visualiser le goulot

Vous n’êtes pas obligé de parler de la théorie des contraintes à votre équipe pour la mettre en place. Il est par contre important de sensibiliser tout le monde à la problématique du goulot pour que chacun prenne conscience de sa criticité et se mette à son service.

Nous l’avons évoqué plus haut : la polyvalence permet de désamorcer aisément les goulots en déplaçant les ressources. Cette polyvalence a aussi d’autres vertus : faire prendre conscience des contraintes de ses collègues au quotidien et renforcer la cohésion de l’équipe.

Mais une fois encore, ces conclusions nous font retomber sur quelques leçons souvent déjà apprises à travers Scrum, Lean ou Kanban. La ToC garde néanmoins certaines spécificités (le Drum-Buffer-Rope, la démarche 5FS, la comptabilité ToC) qui valent définitivement le détour pour le développement logiciel, en particulier pour le web en mode agile qui est mon thème de prédilection.

A propos de l’auteur

Ingénieur de formation, j’ai créé ma SSII avec un ami en sortant de l’école en 2004. Après avoir fait beaucoup de projets web et smartphone pendant 10 ans, nous avons revendu la société : lui pour se consacrer à sa passion pour l’art, moi pour l’architecture logicielle.

Partagez vos réflexions 0 commentaires

Partagez vos réflexions :