Analyse Systémique

The Cash Machine... Kesako !? Ce livre n'apparait pas dans le PMBA...!!! Oui je vous l'accorde, ce livre ne fait pas partis du PMBA et pour cause : il traite de la théorie des contraintes qui est déjà abordé par l'excellentissime livre "Le But" de Golratt (le père fondateur de la TOC - Theory of contraints). Alors comme j'avais déjà lu ce livre l'année dernière (ainsi que "Le management par les contraintes" de M. Marris) il ne me semblait pas très judicieux de le relire. D'autant plus que j'étais resté un peu sur ma faim. Car si "Le but" est génial, il traite exclusivement les problématiques de production. Et j'avoue que malgré mes longs efforts, je n'ai jamais réussi à interpréter la théories aux flux transactionnels. Avec "The Cash Machine" c'est chose faite car ce livre est consacré à 100% aux problématiques des services. Même si je vous recommande très vivement la lecture de ce livre, je voudrais tout de même émettre une petite critique : à mon sens l'approche roman qui est adopté atteint ses limites pédagogiques dans le sens où la méthodologie de mise en oeuvre de la TOC reste peu explicite. J'avoue donc aujourd'hui qu'après avoir lu 4 livres sur la TOC, si je cerne parfaitement les contours des problématiques abordées, je me sens incapable de la mettre en oeuvre sur un projet quelconque...! Mais ca va venir, je ne désespère pas ! ;-) Vous savez pourquoi !? Parce qu'il me reste un livre sur le sujet à lire, et pas des moindres, il s'agit de "Reaching the goal" de John Artur Ricketts. Ce livre explique comment la théorie des contraintes a été mise en oeuvre au sein d'IBM... Tout un programme qu'il me tarde d'attaquer ! ;-P

TOC et Systémique

Comme je viens de vous le dire, "The Cash Machine", comme le But, est un roman qui raconte l'histoire d'un manager qui met en place la TOC. Vous aurez compris qu'il est impossible de faire une analyse systémique sur la base d'un récit. Alors je me suis limité à faire l'analyse systémique du concept de la théorie des contraintes d'une manière générale. Avant de démarrer je voudrais souligner le fait que la théorie des contraintes relève de la systémique. Et vous allez le comprendre dans mon analyse, la TOC illustre parfaitement la puissance de la systémique pour résoudre les problèmes organisationnels de nos entreprises.

TOC, TOC, TOC...! Qui est là !? Je souhaiterais parler à la contrainte SVP ! ;-)

En amont du système, nous avons la matière première. Il peut s'agir de commandes, d'ordres de fabrication, de prospects à démarcher, de nouveaux produits à développer...etc. Bref c'est le flux que vous aurez à gérer de A à Z via votre processus. La matière première c'est le niveau 0 de transformation du flux qui va traverser le processus.

Pour que ce soit plus clair, je vais reprendre le premier exemple de "The Cash Machine"  qui concerne le processus de prospection. La problématique est la suivante : la force de vente est augmentée. Malgré cela, le ventes ne progressent plus.

Ensuite le système (processus global) est composé de plusieurs sous processus, illustrés ici par des réservoirs. Le flux de sorti de chaque réservoir étant équivalent au débit (à la productivité) du processus en question. L'exemple du livre énonce 8 sous processus (ou étapes) pour transformer un prospect en client. Les voici :

1. La sélection
2. La qualification
3. Le recensement des besoins
4. La formalisation des besoins exprimés
5. La présentation démo du produit vendu
6. La valorisation de l'offre
7. La négociation
8. La finalisation de la vente

Imaginez donc que les prospects correspondent aux flux bleus du système. Si on suit le système (le prospect à travers les différentes étapes), nous nous rendons compte que le débit global est égale au débit du processus le moins performant. C'est ce que nous appelons la contrainte du système. Dans ma représentation, on peut s'apercevoir qu'il n'y a pas de problème sur les deux premiers réservoirs car ils arrivent à traiter le flux qui leur est approvisionné. En revanche on visualise sur le troisième sous processus qu'il y a saturation et de fait, qu'il n'arrive pas à faire face au débit du flux en amont de la chaîne. Et quand la contrainte ne parvient pas à absorber le flux qui lui est transmis, cela génère des sur stocks, ce qui induit nécessairement une perte de cash flow et un risque d'obsolescence sur les encours...

Revenons à notre exemple, dans le processus de transformation du prospect en client : c'est le sous processus "Présentation démo du produit vendu" qui fait office de contrainte. Cela signifie que la force de vente aura beau démultiplier ses efforts pour trouver de nouveaux clients potentiels, ceux-ci seront bloqués à un moment donné car la démo ne pourra pas être faite, faute de capacité sur ce sous processus. Dans ce cas, quel pourrait être les surstocks et les pertes engendrées ? Ce serait tout simplement des prospects qui sous contrainte de temps pour le prise de décision d'achat, finirait par choisir la concurrence du fait qu'ils n'ont jamais vu le produit fonctionner et que par ailleurs ils n'ont jamais eu d'offre valorisée (sous processus en aval de la démo). Un prospect perdu dans ce cas c'est un manque à gagner au niveau du chiffre d'affaires mais c'est également une perte sèche des ressources utilisées pour acheminer le prospect jusqu'à ce niveau du processus.

Voilà donc la grande idée de la TOC. Le débit du système dans sa globalité est égale au débit de la ressource contrainte. Ce qui nous amène à dire que l'optimum global n'est pas égale à la somme des optima locaux. Et ça : ça peut paraître rien... Mais c'est énorme ! Qui raisonne comme cela dans nos entreprises !? Qui va se préoccuper de savoir si son travail va finir par engorger le collègue en aval de sa tâche ? Pire... Qui va se soucier de savoir si les objectifs sont en phases pour atteindre un optimum global !? Enfin qui établi des objectifs sur le résultat du processus global plutôt que sur des postes isolés ? PAS GRAND MONDE !!!  (Malgré les plus de 3 millions d'exemplaires vendus du livre "Le But" pourrait-on ajouter...! ):-(

La méthode

Maintenant que vous appréhendez un peu mieux ce qu'est la théorie des contraintes, je vais m'aventurer à vous expliquer la méthodologie d'optimisation du processus global. La méthode énonce 5 étapes :

1. Identifier la contrainte.  La contrainte s'identifie assez aisément puisque c'est la ressource qui a le plus de stock d'en cours à traiter. Donc il suffit d'identifier où se trouve le stock d'en cours le plus important pour trouver le goulot d'étranglement.
2. Exploiter la contrainte. La plupart du temps, une fois qu'ils ont identifié la contrainte, les managers sont tentés d'investir pour élever les capacités de la ressource. C'est une erreur grossière car cela correspond à mettre la charrue avant les bœufs... Donc avant d'investir pour augmenter la capacité de production de la contrainte, il faut d'abord en optimiser son utilisation. Dans notre exemple il s'agira de trouver un moyen d'augmenter le nombre de démos par jour. Cela peut se faire en élargissant les plages horaires, en allouant une durée précise pour chaque démo, en trouvant du personnel de remplacement pour faire des démos pendant la pause de midi, organiser de manière plus formel le planning des démo...etc.
3. Subordonner les autres ressources à la ressource contrainte. C'est à dire que tout le processus doit être cadencé en fonction du rythme donné par la ressource goulot. C'est surement l'étape de la méthodologie la plus difficile à mettre en oeuvre. Il s'agit ici de dire que chacun n'est plus responsable de son poste mais de l'ensemble du processus. De ce fait, tant que la ressource contrainte n'arrive pas à faire face au flux, il faut stopper le flux en amont. Cela signifie dans notre exemple qu'il faille demander au commerciaux de stopper la prospection ! Difficile à entendre mais c'est pourtant vrai. Parcontre les ressources à nouveaux disponibles pourraient se rendre utiles soit pour maximiser l'utilisation de la ressource contrainte, soit pour accélérer le flux en aval de la contrainte. Dans notre exemple les commerciaux seraient réalouer à la finalisation des offres et/ou à faire signer les contrats plutôt que de passer du temps à prospecter (ce qui a pour incidence d'engorger la contrainte).
4. Une fois que nous avons maximisé la ressource goulot, il y a deux hypothèses :
   - Soit la ressource contrainte, une fois optimisée, fait apparaître une nouveaux goulots dans la chaîne. Il peut arriver que ce soit uniquement l'optimisation de la ressource qui ait entraîner un goulot et non la capacité intrinsèque de cette même ressource (d'où l'importance de ne pas investir dans un premier temps pour augmenter la capacité de la contrainte). Dans ce cas il faut reprendre la méthode de manière itérative à la deuxième étape en maximisant la nouvelle ressource contrainte.
   - Soit la ressource contrainte est définitivement identifiée. Dans ce cas il faut élever la contrainte pour augmenter son débit. Cela peut passera généralement par un investissement ou une innovation qui permettra de décupler la  productivité de la ressource. Dans notre exemple il peut s'agir d'investir dans une nouvelle salle équipée pour faire des démonstrations.
5. La dernière étape consiste à revenir à la première. Une fois que la contrainte a été élevée, une autre contrainte doit apparaître dans le système. Il faut donc à nouveau l'optimiser, subordonner les autres à celle-ci...etc. Au final le système doit être en capacité d'absorber un flux qui augmente en continu. Jusqu'au jour ou la contrainte sortira du système. Un marché en saturation par exemple. Il conviendra alors de s'attaquer à la ressource contrainte en dehors du système. Mais là les choses se compliquent car il est plus difficile d'influer sur des éléments qui ne relèvent pas de notre responsabilité directe.

La spécificité des services

La méthodologie que je viens de vous présenter était déjà présente dans "Le But" de Goldratt... Mais si aujourd'hui les choses m'apparaissent plus claires dans la mise en application de la TOC sur les processus transactionnels, c'est que j'étais aveuglé par un phénomène qui ne touche que les hommes : "La loi de Parkinson". Car si il est facile de déterminer la productivité d'un poste de production (définis en général par les spécifications techniques de la machine), il est beaucoup plus difficile d'évaluer la productivité maximale d'une personne qui travail sur un processus transactionnel. Si nous conservons notre exemple : comment définir la capacité de production de la personne en charge des devis (sous processus en aval de la contrainte) ? La Loi de Parkinson nous dis « le travail s’étale de façon à occuper le temps disponible pour son achèvement ». Aussi, si la personne dispose d'une semaine ou d'un journée pour réaliser un devis, celle-ci le réalisera dans le temps qui lui est donnée pour le faire. Il est donc plus difficile dans ce cas de trouver la contrainte car il sera tentant de conserver un léger encours pour garder une souplesse dans la gestion de son travail.

La deuxième difficulté soulevée par ce livre réside dans le multi-tâches. Dans une usine, un poste de travail ne réalise, la plupart du temps, qu'un seul type de tâche. Dans les services, les tâches sont beaucoup plus diverses et une personne peut être amenée à intervenir sur plusieurs méta-processus. Dans ce cas, lequel privilégier ? Si un processus est privilégié, ne devient-on pas la fonction contrainte de l'autre processus...?

A mon humble avis, la complexité que révèlent ces deux points dans la mise en oeuvre de la TOC dans les services m'apparaissent assez important pour que cette méthodologie rencontre encore beaucoup de difficultés à intégrer nos organisations transactionnelles.

Conclusion

J'espère que ce tour d'horizon de la TOC par la présentation du livre The Cash Machine vous aura plu. Je vais creuser le sujet dans mon prochain post en vous présentant "Une nouvelle vision de la comptabilité de gestion" de Pierre JAECK. D'ici là : n'hésitez pas à lire "Le But" et/ou "The Cash Machine"...! Ce sont deux livres incontournables !!! ;-)

Cet ouvrage mérite, sans détour, d'apparaître dans le PMBA (mais ferait-il doublon avec "Le But" !? Pour ceux qui sont plus intéressés par les processus transactionnels (services) : certainement pas ! ;-)