:: – Voici une série d’articles proposée par Clément HOSTACHE,
chef de projet et accessoirement passionné par la Théorie des Contraintes – ::
Une exploitation plus poussée de l’IO Map
Nous avons découvert précédemment une alternative à l’analyse classique des TP consistant à dresser un diagramme d’interférences (ID) et à s’appuyer dessus pour construire une carte d’objectifs intermédiaires (IO Map).
H. William Dettmer propose lui une exploitation plus poussée de l’IO Map, mais sans utiliser l’ID. L’IO Map garde la même structure ; en revanche, elle va se placer en tout début d’analyse des TP classiques, avant le CRT. Les avantages de cette utilisation seront :
• Un CRT plus précis, plus concis, et construit plus rapidement
• Une utilisation du CRD bien plus robuste
Je vous propose de découvrir comment Bill Dettmer propose d’utiliser l’IO Map pour parvenir remplir ces deux objectifs.
Le constat initial : un problème de benchmark
Mises à part les critiques apportées à l’analyse des TP classiques, Dettmer souligne que la principale difficulté dans l’élaboration d’un CRT est le manque d’une référence standardisée sur laquelle se baser pour savoir ce que devrait être le système. Sans cette dernière, il devient très difficile de faire le tri entre les UDE trop subjectives ou trop vagues, et donc de déterminer ce qui ne va vraiment pas dans le système actuel. A cette difficulté s’ajoute la définition selon lui trop subjective d’un UDE (« N’importe quoi qui arrive dans votre système et que vous n’aimez pas »).
En effet, l’auteur a constaté dans des groupes de travail plusieurs symptômes qui soutiennent cette thèse :
• Trop d’UDEs (parfois jusqu’à 30)
• Trop grande complexité du CRT (qui devient une masse informe)
• UDEs trop vagues ou trop subjectifs
Ces symptômes induisent une perte de temps et d’énergie, mais surtout une perte de focus, ce qui met en danger la pertinence de l’analyse réalisée par le CRT.
La réponse au problème de benchmark : l’IO Map
Dans un premier temps, nous devons nous efforcer des critères de travail permettant de s’affranchir des problèmes associés plus tôt au CRT. Selon Dettmer, quatre suffisent :
• Une définition claire du système en question, et en particulier de ses frontières
• Une expression simple et claire du but de ce système, faisant consensus
• La détermination des facteurs de succès critiques (les CSF vus plus haut), qui sont les bénéfices minimaux, tirés du système, nécessaires pour pouvoir déclarer que le but de ce dernier est atteint
• L’identification de conditions nécessaires à la réalisation des CSF, de nature habituellement fonctionnelles.
Si nous parvenons à répondre à ces quatre critères, nous aurons alors une définition très claire, mesurable, de ce qui devrait se passer dans notre système pour qu’il remplisse son but.
Comme vous devez le pressentir, l’IO Map est la représentation de ce benchmark. Je vous invite à retourner jeter un œil au schéma de l’IO Map de l’article précédent, en remplaçant les cases « IO » par « conditions nécessaires » (nous les utiliserons indifféremment à l’avenir), et de vous demander si c’est bien le cas. Vous devriez ne pas être tout à fait d’accord…
Les frontières du système : champ de contrôle et sphère d’influence
Si vous avez joué le jeu, vous devez avoir remarqué que le premier des quatre critères avancés par Dettmer n’est en fait pas vraiment représenté dans une IO Map. En fait, nous verrons qu’il l’est dans la mesure où tout au long de l’élaboration de notre carte, nous aurons gardé en tête quelles sont les frontières de notre système.
En effet, il est capital d’avoir bien défini, avant de démarrer la recherche de comment devrait fonctionner le système, ce qui en fait partie ou non, au risque de perdre le focus de notre analyse. Je vous propose donc d’éclaircir les notions d’champ de contrôle et de sphère d’influence avant de poursuivre.
Le champ de contrôle contient tous les aspects du système sur lesquels vous avez directement autorité. Il est généralement plus limité que ce que l’on aimerait. Un responsable de la maintenance n’a par exemple pas autorité sur de département des achats. S’il cherche à se procurer des pièces de meilleure qualité pour un prix plus élevé alors que les achats sont évalués sur les économies réalisées, il risque d’avoir des difficultés à obtenir satisfaction. En revanche, s’il juge qu’une corroie devrait être changée sur un appareil, il est peu probable qu’on parvienne à l’empêcher de le faire.
La sphère d’influence est plus large : elle contient tous les aspects sur lesquelles il est possible d’exercer une certaine influence, bien qu’on n’y ait pas directement autorité. Les chefs de projets illustrent bien cette notion : ils n’ont généralement pas d’autorité directe sur les membres de l’équipe projet, mais influencent pourtant leur comportement tout au long de l’exécution du projet.
Tout ce qui ne fait pas partie du champ de contrôle ou de la sphère d’influence de notre système, fait donc partie de l’environnement extérieur.
Nous venons donc de définir clairement les frontières de notre système. Nous devrons nous assurer lors de notre analyse que chaque CSF et condition nécessaire ne soient pas situés à l’extérieur de notre système. Si c’est le cas, il y a une erreur de raisonnement, un problème de définition des limites du système, ou de définition de ses frontières.
Commentaires :
Cet article plante le décor pour une utilisation plus rigoureuse de l’IO Map. Bill Dettmer souligne l’importance du manque de référence (benchmark) et des risques de perte de focus lors de l’élaboration d’un CRT (Current Reality Tree), et clarifie notions de champ de contrôle et de sphère d’influence, nécessaires pour ne pas s’égarer dans des solutions non applicables.
Dans le prochain article, nous allons nous pencher sur les interactions de l’IO Map avec les autres outils des TP, et découvrir comment ce dernier permet de faire le lien entre eux pour fournir une analyse plus robuste.
