De l’applicabilité de certains principes du « manufacturing » aux chaînes de batch - Part 2

La précédente partie avait permis de fluidifier notre chaine de batch. Essayons d’optimiser le flux…

Le débit de la chaîne est limité par le débit le plus faible

Notre chaîne de batch exemple s’est au travers des quelques lignes précédentes fluidifiée…En sommes, j’ai maintenant un flux de fichiers qui traverse mon ensemble d’étapes…flux qui me permet alors d’exploiter la théorie des contraintes. La théorie des contraintes a été décrite dans de nombreux ouvrages d’Eliyahu M. Goldratt et la toile regorge d’articles sur ce sujet mais le premier de ces ouvrages à l’introduire reste The Goal.

La théorie des contraintes considère que la performance d’une chaîne est limitée par son maillon le plus faible

La théorie des contraintes cherche à augmenter le « throughput », c'est-à-dire le débit de produits en sortie, d’un traitement ou ensemble d’étapes soumises à un flux de pièces, d’informations. En fait, au sens strict, le « throughput  » serait le débit de produits vendus. Autrement dit, les produits qui ne font plus partie des stocks – car les stocks sont une forme de gaspillage et donc coûtent – et qui ont participé à l’augmentation des revenus (au sens large, car je ne suis pas expert comptable) de l’entreprise. Mais ne soyons pas trop strict… Dans cette recherche d’amélioration, la théorie des contraintes considère que la performance globale d’une chaîne est limitée par son maillon le plus faible et se  décline en 5 points :

• Etape 1 : Identifier la contrainte. Il n’y a pas de recette unique pour cela. Dans The Goal, la contrainte est identifiée par le stock qui se créé en amont de celle-ci. Dans d’autre cas et typiquement en informatique, identifier la contrainte se fera très souvent en mesurant, un temps d’exécution…
• Etape 2 : Exploiter la contrainte de façon productive, c'est-à-dire « qui nous rapproche », par rapport à l’intention. Le moyen le plus simple pour cela reste de faire ce qu’il faut pour que cette dernière ne soit jamais au repos mais cette étape peut amener à des décisions contre nature en décidant par exemple de « ralentir » l’utilisation qui est faite de la contrainte…
• Etape 3 : Subordonner le reste du système à la contrainte. Cela est notamment vrai pour les étapes en amont de cette contrainte. En effet, imaginez que l’étape contraignante ne puisse absorber que les deux tiers du flux issu des étapes amont…Quel est l’intérêt que ces étapes amont continuent à produire au même rythme ? créer du stock en amont de l’étape contraignante ? Quant aux étapes en aval de la contrainte, quel est l’intérêt de les optimiser ? Elles fonctionnent déjà probablement en dessous de leur capacité puisqu’elles sont « calées » sur le flux de la contrainte. En bref, votre système doit être cadencé sur la contrainte.
• Etape 4 : Lever la contrainte. A chaque cas sa solution mais le flux de la chaine ne pourra être augmenté que si le flux que la contrainte peut absorber est augmenté
• Etape 5 : Répéter depuis l’étape 1. Amélioration continue quand tu nous tiens…Force est de constater que la contrainte va se déplacer et qu’un nouveau goulet d’étranglement apparaitra. Ailleurs…

Un traitement informatique qui traite des flux de fichiers voit sa performance limitée par son maillon le plus faible

Dans notre exemple, augmenter mon « throughput » c’est augmenter le nombre de lignes de mes fichiers qui sont traitées dans le temps imparti, celui que l’on appelle classiquement la fenêtre de batch. Imaginons une optimisation de notre chaîne en appliquant la théorie des contraintes (cette théorie s’applique dans la mesure où nous disposons d’un flux de pièces, de lots) :

• Identifier la contrainte. Lorsque l’on regarde le tableau ci-dessous (qui représente les temps de traitements des lots par étape

On détecte que l’étape dont le temps de traitement le plus long est l’étape 3, les accès au référentiel. Ce que l’on analyse également, c’est que les étapes amont étant plus rapides, un stock de fichier va se créer en amont de cette étape 3. En fait, les étapes 1 et 2 seront finies pour l’ensemble des lots avant que l’étape 3 ait fini de traiter son premier lot. De même, les étapes en aval de cette fameuse étape 3, sont plus rapides et on y observe donc des temps d’inactivité. Notre contrainte, notre goulet d’étranglement est donc cette fameuse étape 3.

• Exploiter la contrainte. Cela revient à optimiser, réordonnancer les étapes amont et aval de façon à utiliser de la façon la plus optimum possible la contrainte. Dans notre exemple, cela n’est pas chose simple. Il est difficile de démarrer l’étape 3 en avance de phase…La seule optimisation trouvée sera l’utilisation de tris sur les fichiers  afin de garantir que les accès référentiel ne sont réalisés que si et uniquement si cela est nécessaire et n’a pas déjà été fait préalablement.
• Subordonner le système à la contrainte. Les étapes amont doivent être ralenties ou « calées » sur la contrainte afin d’éviter la constitution de ces stocks en amont de l’étape 3. Ainsi le traitement du second lot d’opérations pourrait commencer environ 15 minutes  avant fin de l’étape 3 du premier lot.

Il y a là une différence importante entre l’informatique et le manufacturing. Le stock en manufacturing coûte (de l’immobilisation….). Cela est nettement moins vrai en informatique où mon stock de fichier en amont de l’étape 3 ne me coute « que » de l’espace disque.

• Lever la contrainte. Les améliorations apportées ne sont potentiellement pas encore suffisantes. Les traitements se passent mieux mais le débit, le « throughput » n’a pas encore vraiment été augmenté, ces accès au référentiel sont encore trop coûteux. Les solutions à mettre en œuvre sont des « classiques » des problématiques d’accès aux référentiels : on peut mettre en place des mécanismes de réplication, des extractions journalières ou même un mécanisme de cache qui permettront de réduire les temps de traitements de l’étape 3 de 90 minutes à quelques minutes. Voici le résultat

• Répéter. La contrainte s’est déplacée…mais ou ? je vous laisse faire l’exercice ;-)

Ces approches issues du manufacturing donnent quelques grilles d’analyse très intéressantes pour nos problématiques IT quotidiennes. En particulier, la théorie des contraintes permet d’adresser les limitations d’ordre 1, d’y passer 80% de son énergie. Du bon sens ? oui mais comme disait l’autre « The common sense is not so common ». Combien de contexte a-t-on croisé où – pour de multiples raisons qui dépassent bien souvent les problématiques technologiques – une énergie considérable est « focusée » sur des choses annexes, au final pour des gains peu significatifs voire des décisions absurdes… Goldratt pousse ses réflexions un peu plus loin en nous proposant de « casser les règles ». Dans notre exemple de chaîne de batch, une règle ancestrale stipule que les traitements batch ne doivent pas démarrer avant 20h. Classiquement, la raison invoquée est que TP et Batch ne peuvent pas fonctionner en même temps. Mais notre contexte est très particulier et les efforts nécessaires ont déjà été réalisés pour lever cette limitation. Alors imaginez si on casse cette règle, si on se permet de traiter les fichiers au « fil de l’eau », toute la journée. Imaginez la marge de progression dont on dispose et qui pourrait nous aider à augmenter notre « throughput »…