La précédente partie avait permis de fluidifier notre chaine de batch. Essayons d’optimiser le flux…
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 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 :
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) :
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.
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.
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 »…