La théorie des contraintes : c'est compliqué mais pas complexe

Vous vous êtes certainement une fois retrouvé en voiture bloqué derrière un tracteur… sans possibilité de le doubler. Vous étiez contraint de rouler à la même allure que le tracteur, même si votre voiture avait la capacité d’aller bien plus vite.

C’est le principe de la Théorie des Contraintes : un système ne pourra jamais aller plus vite que sa contrainte. Cette approche systémique va chercher à lever la contrainte afin de maximiser la valeur créée par un système de manière pérenne avec les moyens disponibles.

Disons-le, l’acronyme TOC pour Theory Of Constraints ne joue pas en faveur de la Théorie des Contraintes. Faut-il être ‘toqué’ pour comprendre et appliquer la théorie des contraintes ? Eliyahu GOLDRATT – l’inventeur de la TOC – ne l’était pas. Il part de l’hypothèse de base que « le système est compliqué – et non complexe – donc tout est logique ».

Si je connais le système et connais son BUT alors tout devient logique. Je peux alors améliorer le système indéfiniment : "even the sky is not the limit".

La promesse est aussi belle que l’approche est déconcertante de simplicité (en apparence) : si je lève la contrainte du système alors j’augmente la valeur.

Cinq étapes sont nécessaires :

• Identifier la contrainte dans le système,
• Exploiter la contrainte (c’est là que l’approche Lean est pertinente),
• Subordonner tous les processus à la contrainte (c’est là qu’intervient le Drum Buffer Rope ou #DBR),
• Élever la performance de la contrainte,
• Recommencer si la contrainte a changé (et elle changera).
  
  

Il en découle que seule la performance de la contrainte doit être suivie, tous les autres indicateurs de performance (KPI) n’ont aucune utilité.

Mais ce n’est pas parce que vous avez un marteau que vous savez planter des clous. Appliquer la Théorie des Contraintes n’est pas simplement suivre cinq étapes. C’est avant tout une discipline de pensée qui repose sur les "thinking processes".

Une discipline car Eliyahu GOLDRATT met en garde contre les pièges de la logique, notamment de l’inversion de causalité : "Si j’ai l’appendicite ALORS j’ai de la fièvre et mal au ventre" (une condition suffisante) et non "Si j’ai de la fièvre et mal au ventre ALORS j’ai l’appendicite" (une simple corrélation sans nécessairement de relation de cause à effet).

L’évaporation de conflit, ou "evaporating cloud", s’inscrit dans cette discipline. Appliquons-le à la discussion d’un père et de sa fille qui souhaite aller à une soirée :

• Exposer le conflit : "Tu rentres à 22h" vs "Je rentre à minuit",
• Exprimer les besoins : "Je veux ta sécurité" vs "Je veux faire comme les autres",
• Identifier l’objectif commun : "Être heureux en famille",
• Piéger les approximations en identifiant les liens faibles entre l’objectif commun, les besoins et le conflit : "Je veux ta sécurité" et "Tu rentres à 22h", Proposer une injection (solution) sur le lien faible : "J’irai te chercher à minuit",
• Le conflit disparait !
  
  

Attention ! Cela fonctionne si vous vous adressez à un seul et unique système.

Lorsque nous prendrons un problème en compte avec la TOC, nous devrons TOUJOURS définir le SYSTEME, son BUT et les INDICATEURS d’atteinte de ce but. Ainsi, il est IMPOSSIBLE d’AMELIORER un système dont on ne connaît pas le BUT.

Établir une véritable relation de cause à effet afin de résoudre un problème, les premiers pas du parcours certifiant Lean Service Agile niveau Green Belt.