:: – Voici une série d’articles proposée par Clément HOSTACHE,
chef de projet et accessoirement passionné par la Théorie des Contraintes – ::
Dans cette série d’articles, je vous propose de faire un point sur les Thinking Processes (processus de pensée) de la Théorie des Contraintes.
Les TP ont été avancés par Eli Goldratt et ses proches collaborateurs pour permettre aux membres d’une organisation de raisonner en termes de cause et effet comme lui-même le faisait si naturellement.
Plusieurs outils ont été développés pour répondre à différents types de besoins, la totalité d’entre eux permettant théoriquement de réaliser une étude en profondeur de la situation actuelle d’une organisation et de la stratégie qu’elle devrait mettre en place. Certains de ces outils utilisent selon les cas des raisonnements de causalité, ou de suffisance, alors que d’autres utilisent des raisonnements de nécessité.
Les trois questions fondamentales :
Les TP sont articulés pour répondre à trois questions fondamentales dans une démarche d’amélioration continue :
- Que faut-il changer ?
- Vers quoi faut-il changer ?
- Comment faut-il changer ?
Si l’on répond correctement à ces trois questions, nous parviendrons théoriquement à éliminer toute résistance au changement qui en découlera. Je vous propose dans ce premier article de nous pencher sur la première de ces questions, et de découvrir deux outils qui nous permettront d’y répondre.
Que faut-il changer ?
La première étape consiste à identifier ce qu’il faut changer, c’est-à dire trouver la cause profonde (root cause) de la plupart de nos difficultés. C’est ici que le CRT rentre en jeu.
Le Current Reality Tree (CRT), ou l’Arbre de Réalité Courante
Pour réaliser cet arbre, on s’appuie sur les acteurs de notre organisation pour lister tous les effets indésirables du fonctionnement actuel du système dans lequel ils évoluent. Il s’agit des UDEs (UnDesirable Effects), ou « effets indésirables » en français. Lorsque l’on en a identifié six à dix, on tente de les relier par des liens de causalité, en y ajoutant éventuellement certains effets intermédiaires. Nous sommes donc dans le cas d’une analyse utilisant un raisonnement de causalité (ou de suffisance).
On arrive alors à un arbre de réalité courante. Les différents constats posés lors de son élaboration peuvent être classés en trois types :
- Politique interne à notre organisation, sur laquelle on peut agir
- Réalité induite par l’extérieur de l’organisation, qu’on ne peut modifier aisément
- Simple effet résultant de ces deux derniers.
Il est important de savoir faire ces distinctions pour savoir ce sur quoi on peut agir et ce qu’il faut accepter comme existant et difficile à changer.
Le schéma ci-dessus illustre la structure d’un CRT.
Par convention, on utilise une flèche entre deux cases pour illustrer la relation de cause à effet : SI <base de la flèche> ALORS <pointe de la flèche> . Les ellipses mettent en avant la conjonction de deux causes pour arriver à un effet : SI <cause n°1> ALORS <effet> CAR <cause n°2>.
Généralement, le CRT une fois terminé a une forme d’entonnoir. L’UDE se trouvant au plus bas est probablement responsable de l’existence de la plupart des autres. Le CRT nous permet donc de d’identifier par quel bout attaquer la masse de problèmes à première vue indépendants pour obtenir, par une sorte de réaction en chaine, un rapport effort/impact positif le plus important possible.
Le Conflict Resolution Diagram (CRD), ou le Diagramme de Résolution de Conflit
La cause profonde que nous venons d’identifier n’est généralement pas simple à éliminer. Il s’agit la plupart du temps d’un conflit entre deux pensées, supposées servir le même objectif.
La thèse de Goldratt est qu’en fait il n’y a pas besoin de faire de compromis dans ce genre de situation : s’il y a conflit entre deux lignes directrices servant le même objectif, c’est très probablement qu’un des présupposés induisant l’un des deux comportements est faux. Il suffit de l’identifier pour « évaporer » le conflit par une injection. Pour cette raison, Eli Goldratt avait pour coutume d’appeler cet outil l’evaporating cloud. Vous entendrez régulièrement parler d’evacloud, ou de Nuage en français, pour appeler ce diagramme.
Le schéma ci-dessus illustre la structure d’un CRD.
Les flèches simples se lisent comme suit : POUR AVOIR <pointe de la flèche> IL FAUT AVOIR <base de la flèche> . La flèche en forme d’éclair illustre le conflit entre nos deux positions D et D’. B et C sont respectivement les conditions nécessaires pour obtenir D et D’. A est l’objectif commun. Par convention, on place généralement dans D la position en accord avec les règles actuelles de notre système, et en D’ la position qui challenge ces règles.
Les relations de nécessité représentées par des flèches sont généralement fondées sur des présupposés. Une fois le diagramme en place, nous devons trouver quelle flèche contient un présupposé erroné. Notre intuition nous indique généralement la flèche qui nous gêne le plus. L’injection devra répondre aux deux besoins B et C, sans les pénaliser.
C’est le premier pas vers la réponse à la deuxième question (vers quoi faut-il changer), que je vous propose d’étudier dans l’article suivant.
Bonne mise en bouche. J’espère que Clément nous indiquera des exemples opérationnels parlants dans ses prochains articles afin de ne pas rester sur du théorique et de bien comprendre l’efficacité des TP. Ce sont des outils puissants qu’il faut s’approprier avant de bien les utiliser et rien ne vaut de petits exemples concrets.
Merci pour cette série d’articles.
Nicolas
Bonjour,
mes excuses pour la réponse tardive, j’ai eu quelques bricoles personnelles à gérer.
Merci beaucoup pour ce commentaire, c’est encourageant. La première série d’articles que j’ai fournie à Florent n’a pas d’exemple concrets : je me suis focaliser sur une vue d’ensemble des TP et l’explication de leurs principes.
Après la présentation globale, je pense que nous pourrons d’une part proposer d’approfondir certains outils plus en détails, et d’autre part étudier des cas pratiques.
Je suis donc tout à fait d’accord sur l’intérêt de fournir des exemples. Je tenterai dans l’été de rassembler des cas d’école à étudier. Je serais d’ailleurs ravi, si certains de nos lecteurs sont tentés de faire l’expérience, de travailler avec eux sur une analyse complète ou seulement un outil, et d’en partager les résultats avec la communauté d’EOTV.
Bien cordialement,
Clément.