The science of batch size - Donald G Reinerstsen at FlowCon France 2019

[00:00:00] Bonjour monsieur mesdames, euh je ne parlerai pas français parce que je parle comme une vache espagnole. Euh, il sera beaucoup plus efficace pour moi de faire cette présentation en anglais. Et euh, il s'agira de la taille de lot. Euh, je pense que certaines personnes, j'ai entendu dire qu'elles utilisent la taille de batch ici. Donc je suppose que vous utilisez les deux termes. Je pense que le terme traditionnel est la taille de lot. Hum, il s'agira de la science de la taille des lots. Donc je pense que ma supposition est que très peu d'entre vous diraient qu'une grande taille de lot est bonne. Et donc si je disais qu'une plus petite taille de lot est bonne, vous seriez tous d'accord avec moi. Et si je vous donnais des raisons pour lesquelles une petite taille de lot était bonne, euh, cela ne vous dirait pas beaucoup de choses nouvelles. Je vais donc examiner plus quantitativement la question de la taille des lots, euh moins comme une philosophie et plus comme un problème quantitatif. Et euh, et je crois que c'est utile parce que lorsque vous dites à votre patron que nous allons introduire une réduction de la taille des lots d'une certaine quantité, c'est et votre patron vous demande, quel effet cela aura-t-il sur mon coût, mon temps de cycle ou ma qualité, euh, il serait utile pour vous de pouvoir donner une réponse plus quantitative et moins qualitative. D'accord. Je vais donc vous montrer une partie de la science, c'est ce que j'appelle la science derrière la taille des lots. Les choses que je veux, oh, d'abord je veux remercier tous nos sponsors parce que c'est pourquoi je suis ici, sinon je ne serais pas ici. Euh, les choses dont je vais parler sont : premièrement, je veux donner une petite définition du vocabulaire autour de la taille des lots, euh juste pour être clair, juste pour vous donner un peu de contexte sur la façon dont je définis la taille des lots, pourquoi cela s'est avéré être un problème dans de nombreux processus de développement. Euh, la différence entre le fait de le considérer en termes de slogans comme le flux pièce à pièce et de le considérer plus économiquement en termes de choses. Ensuite, je veux parler de euh et je vais vous donner un petit exemple de taille de lot ici et ensuite je veux parler un peu des effets que vous obtenez lorsque vous réduisez la taille de lot et quel type de plage quantitative vous allez voir avec certains types de changements de taille de lot.
[00:03:03] Ensuite, je vais aborder le concept de taille de lot optimale. En fait, le travail original quantifiant la taille optimale des lots a été réalisé en 1913, il y a 106 ans, vous savez, 50 ans avant qu'il n'y ait un, enfin pas 50, 40 ans avant qu'il n'y ait un système de production Toyota, les gens s'inquiétaient de l'économie de la taille des lots et avaient une réponse qui est encore vraie aujourd'hui. Hum, et la principale chose contrôlable, la chose la plus importante que Toyota a apportée à la question de la taille des lots, c'est qu'avant Toyota, tout le monde agissait comme si le coût de transaction était fixe. Ainsi, une usine américaine de matrices d'estampage finissait par faire fonctionner sa machine d'estampage pendant une semaine parce qu'il fallait une journée pour changer la machine. Euh, Toyota est arrivé et a dit, vous appelez ça un coût fixe, que se passerait-il si vous le changiez ? Et ils ont dit, pouvez-vous changer la machine en 12 heures, deux heures, une heure, moins de 10 minutes ? Et ils ont réalisé des réductions d'ordre de grandeur des coûts de transaction, c'est la clé qui débloque la taille des lots, et cela leur a permis de travailler de manière rentable avec de très petits lots. Maintenant, euh, vous tous dans le logiciel avez vécu la même expérience, atteignant probablement des réductions de taille de lot qui sont trois ou quatre ordres de grandeur supérieurs aux réductions de taille de lot qui ont été atteintes chez Toyota. Parce que si vous regardez ce que nous avons fait pour automatiser les processus de test, en allant, vous savez, les gens qui testaient autrefois une fois tous les 30 jours, qui testent maintenant en quelques secondes, euh en temps réel sur le système. Le coût de transaction associé à la réalisation d'un test a chuté de manière très spectaculaire dans les logiciels, plus que probablement tout autre domaine de l'ingénierie partout dans le monde. Je vais donc parler un peu de cette question du coût de transaction et euh de certaines des choses que nous faisons pour y travailler. Ensuite, je veux parler de la question de la priorisation des plus petits lots. Si tout est un dans un grand lot, si je mets 40 personnes dans un bus et que je demande et qu'elles me demandent qui arrivera en premier, ma réponse sera : vous arriverez tous en premier parce que notre intention est que tout le monde dans le bus arrive à destination en même temps. Euh, si je mets 40 personnes dans 10 voitures, quatre personnes par voiture, j'ai maintenant l'opportunité de dire que certaines choses peuvent aller de l'avant par rapport à d'autres. Et cette opportunité que certaines choses aillent de l'avant par rapport à d'autres, qui est inexistante dans le monde des grands lots, finit par nous être très précieuse économiquement. Je vais donc parler un peu de la priorisation. Et en particulier, je parlerai des concepts de la tâche la plus courte pondérée en premier et euh, vous savez, et je traiterai de cela. Ensuite, la dernière chose dont je veux parler est de savoir quelles sont les conditions limitantes qui pourraient nous empêcher de fabriquer des lots aussi petits que nous le souhaiterions, des choses qui nous empêcheraient d'obtenir des avantages de la réduction de la taille des lots. Donc c'est ce que je m'attends à couvrir. Euh, nous allons commencer par la façon dont je conçois la taille des lots, parce que je pense que la taille des lots est associée à la fois aux transferts d'informations, je la considère comme associée à la dépense d'argent dans les programmes. Vous savez, pour moi, la taille du lot est la quantité d'informations, d'argent ou d'autres choses qui est transférée d'un état à un autre à un seul moment donné. Donc le concept clé est que quelque chose change d'état, il y a un coût associé au changement de cet état à cet instant précis, et tout ce qui change d'état en même temps est ce que nous appelons le lot. Or, les développeurs de produits n'ont historiquement pas accordé une grande attention à la taille des lots, beaucoup moins d'attention que les fabricants. Mais c'est parce que dans le développement de produits, notre produit de travail, nous n'avons pas non plus accordé beaucoup d'attention à l'inventaire au fil des ans. Et le problème est que ce sur quoi nous travaillons dans le développement de produits est l'information, et l'information est intrinsèquement invisible. Et parce que l'information est invisible, nous ne voyons pas nos stocks, nous ne voyons pas nos files d'attente, nous ne voyons pas le flux dans notre processus, et nous ne voyons pas la taille des lots. Vous devez donc faire, contrairement à la fabrication où la taille des lots vous crie dessus lorsque vous vous promenez dans l'atelier, cela ne se produit pas dans un processus de développement. Euh, le, le fait qu'il soit invisible, nous l'avons en quelque sorte sous-géré historiquement. Euh, j'allais, j'enseignais des cours au Caltech, une université en Californie, des cours pour cadres et pendant environ 15 ans, je demandais aux gens : avez-vous un programme formel pour réduire la taille des lots dans votre processus de développement ? Et seulement 3% des personnes dans les organisations de développement avaient un programme de réduction de la taille des lots. Vous savez, pratiquement 100% des personnes dans la fabrication ont des programmes de réduction de la taille des lots. Mais ce n'était tout simplement pas un problème historique pour nous parce que nous ne l'avons pas vraiment défini comme un problème. Maintenant, où avons-nous des problèmes de taille de lot ? Ils sont partout dans nos processus parce que, comme ils sont invisibles, il n'y a pas de prédateurs naturels pour les grandes tailles de lot, donc ils prospèrent dans nos processus. Euh, nous faisons des projets trop grands, nous finançons des projets avec de grosses sommes d'argent. Il faut autant d'efforts pour demander une grosse somme d'argent qu'une petite somme d'argent, donc les gens demandent de grosses sommes d'argent. Nous utilisons des processus à portes de phases, des processus à portes de jalon où je dois terminer une phase avant de commencer l'autre phase. Et si vous considérez cela du point de vue de la taille des lots, si je dois définir 100% des exigences avant de commencer la phase de conception, ce transfert de lot entre les exigences et la conception représente 100% du produit du travail, ce qui correspond à la taille maximale théorique du lot. Vous ne pourriez pas concevoir un processus de développement qui prendrait plus de temps qu'un processus de porte d'étape qui vous permettrait de fonctionner en une seule phase à la fois. Vous pouvez essentiellement réduire de moitié le temps de cycle de pratiquement n'importe quel processus de porte d'étape si vous donnez simplement la permission aux gens de travailler en phases superposées au lieu de phases séquentielles. Mais c'était un problème fondamental de taille des lots que 50% des entreprises américaines avec lesquelles j'ai travaillé avaient des processus de porte d'étape où elles pensaient qu'il était bon de fonctionner en une seule phase à la fois. Les gens ont essayé de définir toutes les exigences avant de commencer la conception, ils font la planification de projet en élaborant un plan détaillé qui s'étend sur 18 mois dans le futur avec 10 000 activités, puis 30 jours après le début du processus, ils doivent refaire le plan. Euh, Scrum et Agile ont absolument bouleversé cela parce que maintenant vous ne faites pas de détails, si la durée de votre sprint est de deux semaines, vous n'essayez pas de dire ce que les gens vont faire quotidiennement euh au-delà de l'horizon de deux semaines. Vous ne planifiez pas ces dates. Et moins vous avez d'activités pré-planifiées, plus le coût de périssabilité est bas et moins vous faites de pré-replanification, car cela aussi est un problème de taille de lot. Euh, cela se produit dans de nombreux autres domaines avec les tests, avec la publication des dessins, euh la publication de fabrication, l'étude de marché, le prototypage. Je vais juste utiliser un petit exemple de publication de dessin pour vous montrer un peu les mécanismes de ce qui se passe. Et voici ce que j'ai fait : j'ai pris deux entreprises différentes, elles fabriquent exactement le même produit, mais elles ont un protocole différent qu'elles utilisent pour la façon dont elles traitent le travail. Donc, du côté gauche, ils réalisent 10 semaines de dessins, les concepteurs réalisent 10 semaines de dessins, puis ils tiennent une revue de conception sur les dessins, et ensuite, après que les dessins ont été examinés, ceci est une entreprise de produits mécaniques, l'étape suivante est que les dessins vont à la planification des matériaux, de sorte que les personnes chargées de la planification des matériaux commencent à réfléchir aux matériaux que nous devons commander pour pouvoir fabriquer ces choses. Les personnes du côté droit, leur philosophie est que nous allons faire une revue des dessins une fois par semaine, dès que nous une fois par semaine, en fait, nous allons le faire tous les mercredis après-midi à 13h. Et donc, quels que soient les dessins terminés au cours des sept derniers jours, nous les examinons et ensuite, une fois la revue terminée, nous rentrons chez nous. C'est donc une revue qui est faite par les mêmes personnes, au même endroit, à la même heure chaque semaine. C'est fait à une cadence régulière et j'en parlerai plus tard.
[00:13:25] Les personnes de gauche diraient : « J'aime mes grandes revues de dessins parce que j'obtiens une revue de très haute fidélité. Je vois tous les dessins en même temps, euh et cela rend ma revue très efficace. » Euh ils disent, je n'ai qu'une seule réunion à faire au lieu d'avoir 10 réunions sur la période de 10 semaines.
[00:13:49] Eh bien, vous pourriez tester cela. Vous tous dans le logiciel connaissez la réponse à cela cependant, c'est qu'il fut un temps, nous avions l'habitude de dire, vous ne pouviez faire des tests système que lorsque le système entier était complet, que vous ne pouviez rien apprendre d'un système à moins que le système entier ne soit complet. Nous faisions donc une intégration big bang à la fin d'un processus. Et puis nous avons été assez intelligents pour l'examiner et poser la question : tout ce que nous trouvons dans l'intégration du système, est-ce quelque chose qui n'aurait pu être trouvé que lorsque 100% de l'équipement, du système, était prêt ? Et nous avons découvert que 75 à 80% de ces éléments auraient pu être trouvés en amont, en dehors du chemin critique du programme. Nous avons donc commencé à pousser, nous avons commencé à modifier les processus de test en amont pour pouvoir obtenir les informations plus tôt. Et il en va de même pour la revue de dessin dans un processus de conception mécanique. Il y aura une poignée de problèmes qui nécessitent d'avoir l'ensemble du système. La grande majorité des problèmes sont des choses qui concernent des composants adjacents et ils peuvent être examinés très efficacement lors de revues plus petites.
[00:15:05] La question du temps de réunion. Euh, l'idée que si j'ai une réunion toutes les 10 semaines, euh cela prend moins de temps qu'une réunion chaque semaine. Hum, la plupart d'entre vous ont probablement été dans des organisations logicielles qui, il était une fois, faisaient des réunions d'équipe hebdomadaires et sont probablement passées à des stand-ups quotidiens euh dans les équipes. Et si vous calculez mentalement combien de temps cela a pris lors d'une réunion hebdomadaire et combien de temps cela prend lors de cinq stand-ups quotidiens, quel chiffre est faux, quel chiffre est plus élevé ? Pensez-vous que les réunions hebdomadaires prenaient moins de temps que les stand-ups quotidiens ? Aucune preuve de cela. Tous ceux à qui je parle dans le logiciel, vous savez, des stand-ups quotidiens de 15 minutes, euh, vous savez, cela vous coûte presque deux heures par semaine, peut-être, selon le nombre de jours que vous travaillez et des choses comme ça. Les réunions d'équipe hebdomadaires duraient invariablement de quatre heures ou plus et des choses comme ça. Nous n'obtenions jamais deux heures de réunions lorsque nous faisions des réunions d'équipe hebdomadaires. C'est donc un peu une illusion. Il y a d'autres choses intéressantes qui se produisent quand un ingénieur reçoit-il des retours sur son dessin ? Le premier dessin réalisé sur le processus de gauche, ils reçoivent des retours 10 semaines plus tard. S'ils font une mauvaise hypothèse concernant une tolérance de fabrication, ils découvrent qu'ils ont fait cette mauvaise hypothèse 10 semaines plus tard, ils ont l'opportunité d'intégrer cette mauvaise hypothèse dans 200 autres dessins. Et encore une fois, nous avons appris cette leçon dans le logiciel. Le programmeur fait une mauvaise hypothèse sur un protocole, vous lui donnez un retour 24 heures plus tard, il arrête d'intégrer la mauvaise hypothèse dans son travail, ce qu'il fait. D'autres personnes arrêtent de concevoir des choses qui en dépendent. Maintenant, il y a une autre dimension intéressante à cela si vous regardez le rythme auquel les dessins sont livrés, dans le processus de gauche, vous vous retrouvez avec ce grand tsunami de travail. Les gens de la planification des matériaux ne font rien pendant 10 semaines et puis tout d'un coup 200 dessins arrivent et les gens disent : pourquoi n'avez-vous pas, quand allez-vous finir les 200 dessins et ce genre de choses. C'est intrinsèque aux grands lots, c'est que vous amplifiez la variabilité nue du flux dans un processus. Et je ne vais pas aborder les questions de file d'attente aujourd'hui, mais si vous êtes conscient du fait à quel point les courbes de file d'attente deviennent raides à mesure que vous augmentez la charge dans un processus et des choses comme ça, l'amplification de la variabilité aggrave chaque problème de file d'attente que vous avez. Les gens l'appelleront l'éléphant traversant le boa constrictor et d'autres choses parce que vous surchargez progressivement de nombreuses étapes d'un processus.
[00:18:10] Maintenant, euh, nous avons des approches non quantitatives pour gérer la taille des lots et l'une d'entre elles est ce grand slogan du lean manufacturing, qui est le flux pièce par pièce représente la perfection. Et puis maintenant, certaines personnes aimeraient penser, oh, eh bien, si c'est l'objectif auquel nous devrions aspirer, pourquoi ne nous concentrons-nous pas simplement sur cela comme étant l'unité correcte euh pour travailler. Euh, je vous montrerai quand nous aborderons la question de la taille de lot optimale, euh que le flux pièce à pièce n'est pas la bonne réponse. Je pourrais probablement vous en donner une instantiation rapide. La plupart d'entre vous sont familiers avec les réseaux à commutation de paquets, les réseaux à commutation de paquets, la taille des paquets, qu'est-ce que la taille des paquets du nombre d'octets que nous mettons dans un paquet ? Pourquoi ne mettons-nous pas un octet par paquet ? Et si un est le nombre magique, pourquoi n'utilisons-nous pas un octet par paquet ? Et la réponse est la surcharge. Nous aurons mille octets dans un paquet car ce serait absolument absurde. Il y a un compromis associé entre le coût de transaction et la charge utile que vous livrez. Donc vous voulez vraiment demander quel est le bon numéro. Euh, la taille des lots affecte fondamentalement l'économie d'un processus de développement. Finalement, je vous montrerai un peu les calculs plus tard, mais en fin de compte, vous vous posez la question : est-il moins cher de faire avancer ce travail que de le retenir ? Et lorsque vous atteignez un point où ces deux coûts sont égaux, cela représente le point optimal auquel vous transférez le travail. pourquoi n'utilisons-nous pas un octet par paquet ? Et la réponse est la surcharge. que nous aurons mille octets dans un paquet parce que ce serait absolument ridicule. Il y a un compromis associé entre le coût de transaction et la charge utile que vous livrez. Alors, vous voulez vraiment demander quel est le bon numéro ? La taille des lots affecte fondamentalement l'économie d'un processus de développement. En fin de compte, je vous montrerai un peu les calculs plus tard, mais en fin de compte, vous posez la question : est-il moins cher de faire avancer ce travail que de le retenir ? Et quand vous atteignez un point où ces deux coûts sont égaux, cela représente le point optimal auquel vous transférez le travail. La plupart des développeurs, et c'est toujours un compromis entre le coût de transaction et le coût de détention. La plupart des développeurs surestiment le coût de transaction et ne comprennent pas le coût de détention. Et en particulier dans le développement, car l'un de nos principaux coûts de détention est le coût du délai, que se passe-t-il lorsque vous retirez un produit précieux du marché ? Et seulement environ 15 % des développeurs connaissent le coût du délai de leurs projets. D'accord ? Donc, je pense qu'un flux en une seule pièce est en quelque sorte comme un phare. Il vous mène dans la bonne direction, mais comme quelqu'un l'a dit un jour à propos des phares, ce n'est pas parce qu'il vous mène dans la bonne direction que, lorsque vous atteignez le phare, vous devez faire tourner votre voilier en cercle autour du phare encore et encore. C'est juste un chemin, vous devriez continuer vers le port où vous essayez d'arriver. Euh, et le flux d'une seule pièce n'est pas vraiment la réponse pour nous dans le développement de produits. Maintenant, pourquoi voudrions-nous réduire la taille des lots ? Euh, je vais remettre cet exemple. J'ai parlé de certains problèmes, laissez-moi parler de ce qui se passerait si je réduisais la taille des lots de 10 fois. La première chose qui va se passer est que mon inventaire de travaux en cours diminue d'un facteur 10. Parce que cette zone ombrée en rouge sur ce graphique, c'est l'inventaire des travaux en cours. Et la surface de ces 10 petits triangles est en fait 1/10e de la surface du grand triangle. Vous obtenez donc une amélioration de 10 fois de votre inventaire des travaux en cours. Votre temps sur le chemin critique, euh, dans le processus de gauche, la révision des dessins est sur le chemin critique pendant 10 semaines, dans le processus de droite, la révision des dessins n'est sur le chemin critique que pendant une semaine. Vous avez donc réduit le temps, ce qui est ce à quoi on s'attendrait si les stocks diminuaient, n'est-ce pas ? La plupart d'entre vous connaissent la formule de Little : réduire les stocks d'un facteur 10 améliore le temps de cycle d'un facteur 10. D'accord, donc vous réduisez le temps sur le chemin critique d'un facteur 10. Vous réduisez la taille des tsunamis de travail d'un facteur 10. Vous fournissez des retours critiques aux gens 10 fois plus rapidement, apprenant que je concevais selon la mauvaise dimension, vous le découvrez une semaine après le début du processus au lieu de 10 semaines après le début du processus. Vous réduisez le temps d'attente pour les articles de valeur. Si vous avez des articles individuels sur lesquels vous voulez commencer à travailler avant d'autres articles, lorsque vous avez 10 petits lots, vous avez la possibilité de mettre certains de ces articles dans le premier lot, le premier lot qui est livré après une semaine, au lieu du lot qui est livré en un grand lot après 10 semaines. Et donc, euh, la réduction de la taille des lots vous permet toujours de sortir des éléments du chemin critique dans les processus. Et le dernier point que je voudrais soulever est que cela entraîne normalement une réduction des coûts de transaction. Et euh, c'est simplement parce que lorsque vous avez, lorsque vous avez modifié le processus et que vous avez maintenant 10 fois plus de réunions. Lorsque vous étiez dans le processus de gauche, vous avez dit : nous allons avoir une réunion d'examen des dessins, réunissons les bonnes personnes, vérifions les calendriers de chacun et coordonnons cela. Eh bien, au moment où vous avez une réunion hebdomadaire, vous en avez marre de vérifier les calendriers et de réajuster les dates et d'autres choses comme ça. Alors ce que la plupart des gens font, c'est qu'ils disent, nous faisons cela si fréquemment, nous devrions devenir bons à le faire, et nous devrions le faire à un rythme synchronisé pour le rendre facile à faire. Et en fait, euh, c'est certainement ce qui s'est passé, et à mesure que nous commencions à tester par lots de plus en plus petits, nous avions une plus grande incitation à automatiser les tests, et à mesure que nous automatisions davantage les tests, nous sommes passés à des lots de plus en plus petits dans le processus. Ce sont donc en quelque sorte les effets quantitatifs et opérationnels de cela. Euh, il y a un certain nombre d'autres choses qui se produisent en dehors de celles-ci. J'ai parlé de l'effet du temps de cycle, de la variabilité et du feedback plus lent. Le risque plus élevé est un élément très important et j'en parlerai dans un instant. Euh, évidemment, il y a plus de frais généraux s'il y a euh, s'il y a plus de stock. Euh, moins d'efficacité, vous ne penseriez pas, beaucoup de gens utilisent de gros lots parce qu'ils pensent qu'ils sont efficaces. Et je mettrai un PDF à disposition de ceci, euh, après la conférence et tout ça, donc vous aurez, il y aura une vidéo, j'en suis sûr, mais je m'assurerai que ce document soit disponible pour vous afin que vous n'ayez pas à vous soucier de tout photographier. Euh, vous devriez juste écouter ce que je dis car ce que je dis n'est pas nécessairement sur la diapositive. Euh, les gros lots réduisent la motivation dans un processus. Et il y a d'autres effets comme le glissement non linéaire et les spirales mortelles. Je ne vais pas en parler, mais vous pouvez les trouver dans le livre. Ces petites références que j'ai comme B10, qui font référence à une section particulière des principes du flux de développement de produits, donc vous pouvez les retrouver si vous voulez les retrouver. Maintenant, euh, voici un exemple de réduction de la taille des lots qui a eu lieu dans le monde du développement logiciel. Je parlais avec une équipe chez Hewlett-Packard qui développait des imprimantes laser. Ils étaient très bons dans ce domaine. Ils ne pouvaient pas évaluer quelqu'un d'autre et trouver quelqu'un faisant un meilleur travail. Alors ils sont revenus aux principes de base et ont dit, nous devons réduire la taille des lots dans le processus, peut-être que cela fera une différence. Ils sont allés voir les deux gars là-bas à Boise, Idaho, l'un s'appelait Brett Dodd, l'autre Sterling Mortenson. Ils sont allés voir leur patron et ont dit : nous avons une très bonne idée pour réduire la taille des lots dans le développement de micrologiciels. Six mois plus tard, ils avaient réduit le travail en cours d'un facteur 10 et le temps de cycle de leur processus était 10 fois plus rapide. Et je pense, euh, qu'à cette époque, c'était l'ancienne ère du P, ce n'est pas le P d'aujourd'hui. C'était dans les années 90 et euh, et ils avaient beaucoup de liberté pour faire des choses intelligentes à l'époque et ils en ont profité. Euh, quel genre de changements ont-ils observé lorsque la taille des lots a été réduite ? Ils avaient de plus petits changements dans le code, de plus petits changements rendaient la complexité du débogage beaucoup plus facile. Parce que si vous changez une ligne dans le code, une seule ligne peut être cassée, deux lignes, c'est la ligne un ou la ligne deux ou une interaction entre un et deux. Les interactions augmentent avec environ deux à la puissance n, et vous compliquez massivement votre problème pour trouver des problèmes, euh, la difficulté de trouver des problèmes si vous finissez par apporter des modifications importantes par lots dans le code. Ils avaient moins de bugs ouverts actifs à un moment donné. Ce qui signifiait qu'ils devaient faire moins de rapports d'état, euh cela signifiait que les systèmes qu'ils testaient étaient plus, fonctionnaient mieux, donc ils avaient plus de temps de disponibilité sur leurs systèmes de test et cela signifiait que les systèmes qu'ils testaient produisaient plus de validité dans les tests. Ils avaient un temps de cycle plus rapide grâce au processus car lorsque vous réduisez la quantité de WIP, vous accélérez le temps de transit. Euh, une division de HP me disait, euh, dans l'un de leurs processus, ils assignaient un bug à un programmeur dès que le bug arrivait. Ils ont dit, la première chose qu'ils feraient serait de le trier et de déterminer la gravité, si c'était un bug important, ils l'assigneraient ensuite à un programmeur parce qu'ils l'ont assigné si rapidement, ils avaient de nombreux bugs en cours. Combien de bogues avaient-ils en cours de traitement ? Ils m'ont dit : nous mettons tellement de temps entre le moment où nous assignons un bogue et le moment où nous le corrigeons, que nous corrigeons des bogues dans du code qui se trouve dans des modules qui n'existent plus dans le système. Au moment où nous finissons par implémenter le correctif, il n'est même plus dans le système. Donc, ils ont fini par faire ce que je pense que vous feriez probablement, c'est-à-dire : nous avons besoin d'une contrainte de WIP sur ce sur quoi nous travaillons. Travaillons sur une quantité illimitée de choses, afin que le temps de transit soit rapide, afin que le monde ne change pas pendant que nous travaillons. Et c'est certainement ce qu'ils ont expérimenté chez HP. Les exigences changeaient moins lorsque quelque chose était en cours pendant une période plus courte. Parce que vous opérez dans un monde en mutation et vous n'allez pas éliminer ce problème de monde en mutation. Euh, cela a également fourni un feedback plus rapide avec un temps de cycle plus court, de sorte que les programmeurs pouvaient encore se souvenir de ce sur quoi ils travaillaient au moment où ils recevaient le feedback, ce qui a rendu le processus beaucoup plus efficace.
[00:29:29] Maintenant, permettez-moi de parler un peu plus du risque, que les petits lots ont intrinsèquement moins de risque pour un certain nombre de raisons différentes. Euh, et l'une d'entre elles est en fait extrêmement importante en termes d'euh, d'économie. Donc, j'ai parlé du problème, ils passent moins de temps en vol et sont moins vulnérables aux changements technologiques ou aux changements du marché. Euh, il y a aussi intrinsèquement moins de risques à travailler sur des modules plus petits, euh. Par exemple, je pourrais prendre l'exemple en économie, si je disais, voudriez-vous lancer une pièce, vous savez, face ou pile, et vous obtenez si vous, si vous choisissez la bonne, euh, je vous laisserai parier 100 $ et si vous choisissez correctement, soit face soit pile, je vous donnerai 100 $ de plus. Maintenant, je pourrais mettre en place la même expérience en disant : au lieu de vous faire parier 100 $, je vous laisserai parier 5 $ 20 fois de suite. Maintenant, quelle est la différence entre les deux, la valeur attendue des deux jeux est la même. Mais quel est le risque dans ces jeux ? Dans le premier jeu, vous avez 50 % de chances de perdre 100 $. Quelle est votre probabilité de perdre 100 $ si vous placez 20 paris qui ont chacun 50 % de chances de succès ? C'est vraiment une chance sur un million. Vous avez totalement éliminé la probabilité de ruine qui est la plus associée aux très grands lots. Les choses qui s'autodétruisent sont celles que vous faites en très grands lots. Maintenant, l'autre chose intéressante qu'un petit lot fait pour vous, c'est qu'il vous permet d'utiliser les informations générées par ce petit lot pour modifier ce que vous faites. Et je vais vous donner juste pour tronquer rapidement les mauvaises choses. Et je vais vous donner en quelque sorte un petit problème jouet qui l'illustre. Euh, je vais vous vendre un billet de loterie qui rapporte 3 000 $ si vous choisissez le bon numéro à trois chiffres. Et je vais vous faire payer 3 $ pour jouer à ce jeu. Eh bien, vous vous rendriez très vite compte qu'il y a une chance sur mille de gagner 3 000 $, ce qui vaut 3 $, donc c'est un jeu à somme nulle. Maintenant, je vais vous proposer une autre façon de jouer au jeu. Je dirai que je vous facturerai toujours 3 $ pour trois chiffres, mais je vous laisserai choisir le premier chiffre, puis je vous donnerai un retour sur le premier chiffre, et ensuite vous pourrez décider si vous voulez acheter le deuxième chiffre, et ensuite je vous donnerai un retour sur le deuxième chiffre, et vous pourrez décider si vous voulez acheter le troisième chiffre. À quoi ressemble l'économie du deuxième jeu ? L'économie ressemble à ceci : il y a 100 % de chances que j'achète le premier chiffre, il y a 10 % de chances que j'achète le deuxième chiffre, et il y a 1 % de chances que j'achète le troisième chiffre. Maintenant, pourquoi l'économie a-t-elle changé ? C'est la question intéressante. Parce que le gain est toujours de 3 000 $, la probabilité de gagner est toujours d'une chance sur mille, et le coût pour jouer est toujours de 3 $ pour acheter trois chiffres. Quelqu'un formé en finance regarderait cela et dirait que la différence dans le deuxième jeu est que vous avez deux options de fermeture. Vous avez deux options intégrées à ce jeu qui vous permettent de tronquer les mauvais chemins tôt. Ainsi, vous profitez des bons chemins, mais vous tronquez le coût des mauvais chemins. Et si certains d'entre vous ont lu les travaux de Nassim Taleb sur l'anti-fragilité et des choses similaires, c'est l'essence même de ce que vous faites en anti-fragilité pour obtenir de meilleurs résultats en présence de variabilité que vous n'en obtenez dans une plus grande stabilité. Ce que vous devez être capable de faire, c'est d'acheter des informations par petits lots et vous devez exploiter ces informations pour placer des paris plus grands ou plus petits sur des résultats qui sont bons ou mauvais. Et donc, euh, il est intéressant de noter que la petite taille des lots est l'une des choses qui ouvre intrinsèquement la porte à l'optionalité dans les processus de développement de produits. Tant que toutes les informations arrivent en un seul gros lot, vous ne pourrez rien faire d'astucieux pour moduler vos investissements sur la queue négative d'une distribution par rapport à la queue positive. Voyez, traditionnellement, nous nous sommes toujours concentrés sur la réduction de l'étendue de la distribution. Mais je pense qu'à l'heure actuelle, je dirais que la meilleure réflexion est qu'une distribution peut avoir deux queues, mais si je peux fermer la queue négative tôt et que je peux amplifier la queue positive, alors la variabilité n'est plus mon ennemi. Et c'est la façon dont les processus évoluent.
[00:35:05] Taille optimale du lot. Euh, c'est ce qu'on appelle la taille de lot économique ou la quantité économique de commande. Les travaux originaux sur ce sujet ont été réalisés en 1913, euh, il y avait un certain Fred Ford Harris qui a écrit un article dans le magazine Factory Management. Les gens euh, les gens qui n'étaient pas du monde de la fabrication n'en savaient pas grand-chose. Et il a dit : il n'y a pas beaucoup d'hommes qui comprennent la théorie sous-jacente à la taille économique des lots, donc une connaissance de celle-ci devrait être d'une valeur considérable. Cette affirmation est vraie, la seule façon dont je la modifierais aujourd'hui est que l'ingénierie n'est plus une profession exclusivement masculine. Donc je prolongerais cette affirmation en disant, il n'y a pas non plus beaucoup de femmes qui comprennent la théorie sous-jacente de la taille économique des lots. Parce qu'ils passent par les mêmes écoles qui ne les enseignent pas. Ils n'enseignent pas le mâle. Et mon fils vient de sortir de l'école d'ingénieurs il y a environ cinq ans et je peux vous garantir, et il est allé dans une bonne école, euh, mais je vous garantis que, à moins d'être ingénieur industriel, ils n'apprennent rien sur la taille des lots, bien qu'ils finissent par être impliqués tous les jours dans l'ingénierie. Et ceci, c'est la courbe qu'il a obtenue. Je vais vous montrer ceci, euh, sous une forme légèrement différente, mais ce n'est pas une nouvelle connaissance que je vous expose. Cela existe depuis un certain temps.
[00:36:37] Euh, il y a une sorte de courbe illustrative de, euh, la taille de lot optimale. Euh, l'une des façons dont je simplifie l'explication de la taille des lots. est que je prends l'exemple de, euh, si ma famille mangeait des œufs au petit-déjeuner tous les jours et que je décidais que je suis le père et que c'est moi qui fais les règles, et que je disais, nous allons trop souvent au supermarché, alors je pense que ce que nous devrions faire, c'est acheter pour un an d'œufs à la fois. Et tout le monde a dit que c'était fou, mais disons foo. Mais j'ai dit, non, non, non, ça a du sens. Donc j'achète des œufs pour un an et je résous ma situation, je suis du côté droit de la courbe, mon coût de transaction est très faible. Je vais au supermarché une fois. Mais mon coût de possession est très élevé. Même un réfrigérateur américain ne peut pas contenir un an d'œufs. Alors je vais acheter un autre réfrigérateur, je vais immobiliser de l'argent dans les œufs, et les œufs vont périr, donc j'aurai un coût de possession associé à eux. Alors mes enfants vont chercher sur Google et dire, Papa, tu dois apprendre à utiliser Internet. Et nous l'avons cherché sur Google, nous avons trouvé la réponse. C'était un flux unitaire. Euh, je dis, d'accord, je sais que ça ne marche pas. Si ça ne marche pas, le contraire doit être la réponse parfaite. Donc, à partir de maintenant, nous mangeons un œuf, nous achetons un œuf, nous mangeons un œuf, nous achetons un œuf. J'ai besoin de place pour un œuf dans mon réfrigérateur, mais je me rends au supermarché plusieurs fois par jour. Et c'est l'essence du compromis. Le compromis, la bonne réponse n'est jamais à un extrême ou à l'autre et ainsi de suite. Parce que vous essayez de contrebalancer deux effets. Dans ce cas, l'un est linéaire, l'autre est hyperbolique, mais ces problèmes de courbe en U. Mais ces courbes en U sont aussi un grand cadeau pour vous. Parce que lorsque vous êtes près du bas de la courbe en U, vous n'avez pas besoin d'une réponse très exacte. Ce que je dis aux gens en termes de, je dis en fait aux gens, ne vous donnez pas la peine de faire un calcul de la taille de lot économique. J'ai dit, vous savez, il y a 99% de chances que vous soyez du bon côté de la courbe parce que vous sous-estimez les coûts de possession. Vous ne savez pas quel est votre coût de retard, donc vous sous-estimez les coûts de possession. Vous surpondérez le coût de transaction. Donc je dis, allez-y et essayez de réduire la taille de votre lot dans la fourchette de 33% à 50%. Maintenant, pourquoi est-ce que je choisis 33% ? Parce que si vous faites les calculs sur cette courbe d'optimisation, si je me déplace de 33%, même si je suis au point optimal, si je me déplace de 33% en dessous de l'optimum, j'aurai une augmentation de moins de 10% du coût total. C'est donc une chose incroyablement sûre de réduire la taille du lot d'un tiers et d'observer ce qui se passe. Et c'est encore plus sûr parce que la taille du lot a un bouton d'annulation, et si vous décidez que la réduction de la taille du lot n'a pas fonctionné, alors vous pouvez revenir à votre taille d'origine. Parce que vous pouvez réduire les dommages causés en diminuant la taille des lots. 33 % à 50 %. Maintenant, pourquoi je choisis 33 % ? Parce que si vous faites le calcul sur cette courbe d'optimisation, si je me déplace de 33 % même si je suis au point optimal, si je me déplace de 33 % en dessous de l'optimum, je ferai moins de 10 % d'augmentation du coût total. Donc, c'est une chose incroyablement sûre de réduire la taille du lot d'un tiers et de voir ce qui se passe. Et c'est encore plus sûr parce que la taille du lot a un bouton d'annulation, et si vous décidez que la réduction de la taille du lot n'a pas fonctionné, alors vous pouvez revenir à votre original parce que vous pouvez réduire les dégâts faits en réduisant la taille du lot. Alors que, si vous décidez que vous devez embaucher 10 ingénieurs de plus et que vous décidez ensuite que c'est une erreur, cela devient un problème beaucoup plus compliqué. Ainsi, la taille des lots et la production en cours sont deux techniques si attrayantes pour nous, du point de vue de la gestion, car elles comportent des boutons d'annulation et nous pouvons essayer quelque chose et l'annuler si cela ne fonctionne pas. Maintenant, les vrais calculs derrière la taille de lot économique, ce n'est rien de très compliqué, ce que vous faites, c'est que vous construisez une équation de coût total qui additionne le coût de possession et le coût de transaction. Comme la plupart des problèmes d'optimisation, vous prenez la dérivée de l'équation, la mettez à zéro et résolvez pour trouver le minimum. Et quand vous faites cela, vous obtenez cette formule dans la boîte bleue selon laquelle la taille de lot optimale est proportionnelle à quelques facteurs, la seule chose que je veux que vous reteniez de cette formule est que le F dans cette équation, qui est le coût fixe par transaction, le coût de transaction, est sous le signe de la racine carrée. Donc, si votre patron vient vous voir et, euh, et vous dit : « Je veux réduire la taille du lot d'un facteur 10 », qu'allez-vous devoir faire au coût de transaction ? Vous devrez réduire le coût de transaction d'un facteur 100. Vous devez avoir une attente raisonnable quant à la relation entre la réduction des coûts de transaction et la taille optimale du lot. Et cela rend encore plus impressionnant de voir ce qui s'est passé dans l'industrie du logiciel avec la taille des lots que nous utilisons pour les tests, car cela implique que nous avons probablement eu au moins six ordres de grandeur de réduction des coûts de transaction au sein de l'industrie du logiciel, liés à la question des tests. Et cela nous dit aussi, vous savez, quand nous avons commencé à coder par très petits lots et qu'ensuite nous nous apprêtions à le déployer et que nous déployions toujours par grands lots, cela a indiqué la réponse à la question de savoir comment réparer le problème de déploiement. Pourquoi déployons-nous par grands lots, nous avons un coût de transaction élevé, comment résoudre si nous réduisons le coût de transaction, alors nous pourrions être en mesure de déployer par petits lots. Et c'est donc exactement la même voie mathématiquement, le problème est résolu en utilisant le même outil en, euh, en DevOps qu'en codage. Maintenant, vous pouvez faire une autre chose avec cette équation, qui est de réinsérer la taille de lot optimale dans l'équation du coût total et de demander quel est le coût total à la taille de lot optimale. Et ce que vous obtenez est, euh, cette formule, et encore une fois, elle a le coût fixe sous le signe de la racine carrée. Mais cela a une implication très importante car cela signifie que non seulement je permets des tailles de lot plus petites lorsque je réduis les coûts de transaction, mais en même temps je diminue le coût total d'un processus. Ainsi, lorsque votre patron demande d'où viendra l'argent pour payer la taille des lots, la réponse est que l'argent provient de la réduction de la taille des lots. Et sur ce graphique, c'est un graphique un peu chargé, mais euh, mais j'ai besoin de toutes les lignes. La ligne bleue est mon ancien coût de transaction. La ligne rouge est mon ancien coût total, et j'avais une ancienne taille de lot optimale. J'ai réduit le coût de transaction jusqu'à la ligne magenta, cette nouvelle ligne magenta est mon nouveau coût de transaction, et la ligne verte est ma nouvelle courbe de coût total. Donc, vous voyez deux choses qui se sont passées avec ce graphique, ce coût total. Premièrement, j'ai déplacé le minimum vers la gauche, ce qui permet une petite taille de lot. L'autre chose que j'ai faite, c'est que j'ai réduit le coût total au point optimal. La plupart des gens comprennent donc le coût de transaction, l'effet sur la taille des lots, euh, je ne trouve pas que la plupart des gens comprennent vraiment l'effet sur le coût total. Et c'est assez important si les gens vous interrogent sur ce qui va arriver au coût total.
[00:44:47] Okay, donc, concrètement, j'ai mentionné ceci : vous êtes susceptible d'être du bon côté de la courbe, essayez de réduire de 33 à 50 %, euh, vous pouvez inverser la direction, euh, si vous avez fait quelque chose de mal si les coûts augmentent. Et puis mon point de vue est le suivant : supposez que vous n'êtes pas au point optimal, continuez à réduire jusqu'à ce que les performances se stabilisent, puis concentrez-vous sur la réduction des coûts de transaction, et ensuite vous recommencez à réduire la taille du lot.
[00:45:19] D'accord, réduire les coûts de transaction. Euh, il y a un certain nombre de choses que nous pouvons faire, euh, vous avez vu la plupart de cela dans l'industrie du logiciel, nous, euh, automatisons pour réduire les coûts de transaction. Euh, des cadences régulières réduisent beaucoup les frais généraux de coordination et cela nous aide beaucoup. La synchronisation pour partager les coûts de transaction est une technique très intéressante, euh, un peu sous-utilisée et je vais vous donner un petit exemple de cela, euh, je ne vais pas vous donner un exemple d'ingénierie parce que cela prend trop de temps à expliquer, je vais vous donner un exemple de fabrication et puis améliorer le rapport signal sur bruit pour que les petits lots fonctionnent mieux. Euh, sur la question de la synchronisation, euh, si nous pouvons faire en sorte que plusieurs lots se produisent en même temps, même s'ils proviennent de programmes différents, nous pouvons souvent créer un coût de transaction virtuel qui est inférieur au coût de transaction réel. Et un bon exemple de cela dans, euh, dans le travail en usine est, et dans une usine, nous avons beaucoup de vis et d'écrous, un boulon, et vous ne voulez pas avoir un système Kanban qui finit par dire, dès que nous manquons du boulon d'une certaine taille. Vous ne voulez pas avoir un système Kanban qui finit par dire dès que nous manquons d'une certaine taille, alors nous devons réapprovisionner parce que vous enverriez des camions 50 fois par jour à cet étage de l'usine. Alors ce qui est réellement fait, et vous paieriez ce coût de transaction de faire un réapprovisionnement. Ce qui est généralement fait dans la plupart des usines, c'est que vous envoyez un camion rempli d'écrous et de boulons, et ils réapprovisionnent tous les niveaux de stock en même temps, puis ils peuvent revenir le lendemain et réapprovisionner les niveaux de stock et d'autres choses. Vous ne faites pas toutes ces transactions individuelles. Et ce que cela fait, c'est que cela crée une sorte de coût de transaction virtuel associé au réapprovisionnement, qui est beaucoup plus bas que ce que vous auriez si vous ne réapprovisionniez qu'une chose à la fois. Euh, sur la question du rapport signal/bruit, euh, c'est un exemple intéressant qui est apparu dans la voile. C'était la Coupe de l'America en 1995, quand la Nouvelle-Zélande a battu l'équipe américaine. L'équipe américaine avait de gros superordinateurs et des choses comme ça, l'équipe néo-zélandaise, et donc l'équipe américaine identifiait un changement de conception et le faisait tourner sur un superordinateur, puis modifiait son yacht, le mettait à l'eau et voyait ce qu'elle accomplissait. L'équipe néo-zélandaise a fait quelque chose de très intéressant : ils ont dit que nous allions construire deux yachts identiques, nous allons en modifier un et garder l'autre tel quel. Ensuite, ce que nous ferons, c'est que nous les ferons naviguer l'un contre l'autre. Or, cela garantissait que les conditions de vent et de mer étaient identiques, ce qui éliminait une source majeure de bruit dans le processus de test. Parce qu'ils ont réduit le bruit dans le processus de test, ils ont pu apporter des changements beaucoup plus petits à la conception de leur quille et autres. Ils ont fait beaucoup plus d'itérations sur leur conception que l'équipe américaine. Et ils ont remporté cette Coupe de l'America en particulier, ils ont gagné comme cinq des cinq premières courses, je veux dire, c'était juste, c'était, c'était absolument, euh, un désastre pour l'équipe américaine. Et c'était la petite Nouvelle-Zélande sans beaucoup d'argent et sans superordinateurs, ils l'ont juste fait sur la base de leur intelligence. D'accord, la priorisation des plus petits lots. Vous ne pouvez pas prioriser lorsque vous avez un gros lot parce que tout arrive dans le même lot.
[00:49:21] Pour les plus petits lots, euh, nous avons généralement tendance à utiliser une technique appelée "weighted shortest job first" (le travail le plus court pondéré en premier), et je vais supposer que la plupart d'entre vous ont une idée, euh, de ce que c'est. Euh, je vais juste vous montrer un petit diagramme là-dessus. Euh, je peux représenter le coût de différentes séquences de travail en faisant de l'axe horizontal le temps et de l'axe vertical le coût du retard. Et ce diagramme dit que la zone devant, sur le diagramme supérieur, la zone devant la boîte numéro deux, est le temps d'attente du travail numéro deux (projet deux) multiplié par la hauteur du projet deux, qui est le coût du retard. Donc, si cela attend trois mois pour un coût de 3 millions de dollars par mois, cela représente 9 millions de dollars de coût de retard. Maintenant, pour le dernier, j'ai inversé l'ordre, ce sont trois travaux homogènes, de durée identique, de coût de retard identique. Et ce que vous voyez, c'est que peu importe l'ordre, je vais obtenir la même taille de la zone ombrée en rouge, euh, et donc il n'y a pas de différence dans le système de priorité que j'utilise. Je passe au monde du développement produit où j'ai des coûts de retard différents, 10, 3 et un, et des durées différentes, j'utilise alors le "weighted shortest job first", l'intention est de retarder les tâches qui ont le faible coût de retard, de faire les tâches qui ont la plus petite durée. J'ai juste représenté cela en utilisant la même méthode pour montrer le coût du retard comme la zone ombrée en rouge et ce que vous voyez, c'est une réduction de 96% du coût du retard sans changer le nombre de tâches, la capacité, la demande, euh, ni même le nombre dans le système. C'est pourquoi la méthode "Weighted Shortest Job First" a tant intéressé Dean Leffingwell lorsqu'il l'a rencontrée. Maintenant, de réelles opportunités de faire les choses dans différentes séquences si vous avez des lots plus petits. Si tout est lié dans un gros lot, cela ne fonctionnera pas pour vous. Maintenant, la dernière chose que je veux mentionner est ce qui pourrait mal tourner, et l'un des plus grands problèmes que nous pourrions avoir est les dépendances. Parce que si vous voulez vraiment utiliser de petits lots, vous devez aborder le problème de l'architecture pour découpler les systèmes de manière à pouvoir utiliser cela. Et sur la diapositive suivante, il y a tout un tas de choses que nous faisons, euh, je ne vais pas entrer dans les détails. Mais sur cette prochaine diapositive, je représente ce qui arrive à ce coût de retard que je calculais si je dois introduire les modules un, deux et trois ou les projets un, deux et trois exactement au même moment. Parce que je ne tire aucun avantage à terminer le projet un tôt si je dois attendre de le commercialiser jusqu'à ce que les projets deux et trois soient également terminés. Donc ce que vous voyez, c'est que cette zone rouge ombragée ne change pas du tout, il n'y a pas d'économies en utilisant le travail le plus court pondéré en premier sur les activités dépendantes. Parce que si vous ne pouvez pas le sortir plus tôt, vous ne finirez pas par gagner de l'argent en priorisant sur la base du coût du retard. D'accord, et maintenant, quand vous pouvez introduire des choses séparément, c'est ce qui vous permet de le faire.
[00:53:08] D'accord, et puis il y a beaucoup de fois où les grands lots peuvent être fondamentalement nécessaires, euh, et à cause des coûts de transaction et des économies d'échelle et tout, euh, je n'entrerai pas dans les détails. Je vais juste résumer rapidement, euh. La première chose que j'aimerais que vous reteniez, c'est que la réduction de la taille des lots améliore tout : le temps de cycle, la qualité, l'efficacité et le risque. La deuxième chose est que vous pouvez commencer avec des slogans, mais je vous recommanderais vraiment de vous tourner vers, euh, la science et l'économie si vous voulez vraiment aller loin. Troisièmement, je dirais que les petits lots créent des options exploitables, et si vous êtes intéressé par l'antifragilité et certaines des choses, euh, les asymétries de gains, c'est l'un des outils clés que vous utilisez. La taille correcte du lot est une question quantitative. C'est une courbe en U, donc vous n'avez pas besoin d'une taille de lot parfaite dans le processus. Vous permettez des lots plus petits avec des coûts de transaction. Le coût de transaction réduit à la fois le coût total, réduit le coût total, et en conséquence il s'autofinance. Une cadence régulière réduit également les coûts de transaction et de coordination. Les petits lots vous permettent de commencer à séquencer le travail intelligemment, vous ne pouvez même pas le séquencer s'il est tout en un seul grand lot.
[00:54:25] Et puis, euh, la dernière chose que je mentionnerais, je ne l'ai pas mentionnée avant, mais je fais toujours la taille des lots avant de travailler sur les goulots d'étranglement dans un processus. Parce que la taille du lot peut créer une telle variation dans le flux de travail, une fois que vous avez fixé la taille du lot, vous pourriez découvrir que vous n'avez aucun problème de file d'attente. De toute façon. D'accord. Donc c'est ce que je voulais finir avant 4h, 4h pile. Donc, euh, au moins j'ai atteint un objectif aujourd'hui.
[00:55:02] Je peux prendre, d'accord. Une question.
[00:55:15] Mais je dirai aussi que ce n'est pas un hasard si j'ai mon email et mon livre sur la première page de la présentation et des choses comme ça, je réponds aux questions par email. Et vous pourriez même me poser des questions en français, mais ne vous attendez pas à obtenir une réponse en français.
[00:55:31] C'était ma question, quand ferez-vous une présentation en français ?
[00:55:37] Ah, c'est une autre paire de manches. OK.
[00:55:44] Merci pour le français prêt.
[00:55:46] D'accord. Merci beaucoup.
[00:55:50] D'accord, revenons aux affaires. En fait, ma vraie question était de savoir, euh, quand vous commencez à, euh, définir une taille de lot, je suppose que vous avez besoin de, euh, rafraîchir et remettre en question ces tailles de lot, euh, au fur et à mesure parce que peut-être que vous avez, euh, défini des paramètres au départ et qu'ensuite avec le temps, euh, vous constatez que ce n'est pas vraiment, euh, pratique ou, euh, pertinent et vous devez remettre en question. Donc, y a-t-il, je dirais, euh, une sorte de délai pour faire cela ?
[00:56:25] Euh, non, mais je vais juste dire, permettez-moi de revenir à la dernière diapositive, euh, dans ce dimensionnement des lots, il n'y a pas de substitut à la réflexion, je veux dire, ce ne sera jamais terriblement simple. Je pense, euh, ce que vous trouverez, c'est qu'il y a souvent beaucoup de choses que vous pouvez faire. Vous pourriez en fait faire je veux dire, j'ai vu des gens faire des réductions majeures de la taille des lots en une semaine parce que d'habitude il s'agit juste de fixer des nombres sur ce qu'ils font. Ils très très rarement si vous n'avez pas rencontré le problème du coût de transaction, souvent ce n'est qu'un nombre arbitrairement programmé associé à la façon dont ils travaillent. Donc, il peut être extrêmement rapide d'apporter les modifications de taille de lot jusqu'à ce que vous arriviez à celles qui nécessitent des modifications de coût de transaction. Euh, et il y a, vous savez, quand nous avions l'habitude de configurer des environnements pour exécuter des tests et des choses comme ça, euh, cela nous prenait beaucoup de temps et c'était un coût de transaction élevé, et maintenant nous avons des environnements scriptés permanents qui sont disponibles en continu à la demande, mais ce passage de la configuration manuelle à la configuration automatisée et permanente et d'autres choses comme ça, euh, vous savez, nos conteneurs, eh bien, ça ne s'est pas fait du jour au lendemain. Cela a demandé beaucoup de travail. D'accord, bonne question. Très bien.
[00:57:54] Merci, oh.
[00:57:56] Ai-je la permission de prendre ? Non, c'est dommage. Vous pouvez me poser une question après que j'aie libéré les gens. D'accord, merci beaucoup. Merci.

Transcription (Traduit)