Thierry & Tobias - I have 99 Problems - Where Do I Start? The Theory of Constraints Applied (EN)

[00:00:15] Voilà. Ce sont des diapositives. Euh, et nous y sommes. Bonjour à tous, et merci de nous rejoindre pour notre petite discussion sur la théorie des contraintes, qui est bien nommée, j'ai 99 problèmes, dont un est... les diapositives sont en fait assez importantes. Donc, euh, si je peux donner un conseil à quiconque dans l'auditoire, agrandissez vraiment la fenêtre des diapositives. Vous n'avez pas tellement besoin de voir nos visages. Les diapositives sont plus importantes. Euh, au fait, je suis Tobias.
[00:00:46] Et je suis.
[00:00:47] Et mon présentateur ne fonctionne pas, ce qui est un des 99 problèmes. Voilà.
[00:00:55] Et, euh, nous devons, en quelque sorte, vous donner la mise en garde, ce n'est pas une conférence. Euh, c'est en fait plus une conversation. Et, euh, nous avons essayé d'en faire une petite pièce, et nous ne sommes pas des acteurs. Alors, désolé pour ça. Euh, cette histoire, cependant, est, euh, inventée, mais elle est faite de choses que nous avons vécues dans la vie réelle. Donc ce n'est pas complètement irréaliste, c'est en fait très réaliste. Et, euh, les similitudes que vous pourriez trouver avec des entreprises que vous connaissez ou dont vous avez entendu parler sont entièrement intentionnelles. Donc, commençons. Euh, hé Kiry. Je peux te demander quelque chose ? Tu es consultant, n'est-ce pas ?
[00:01:37] Bonjour Tobias. Eh bien, oui, euh, disons que j'essaie de conseiller les entreprises sur l'amélioration de leur performance organisationnelle. Pourquoi demandes-tu ?
[00:01:46] Eh bien, c'est génial parce que j'aurais vraiment besoin de ton aide pour quelque chose. Euh, tu sais, j'ai enfin eu cette promotion dont je t'ai parlé et tu regardes maintenant le responsable informatique de mon entreprise.
[00:01:59] Eh bien, regardez ça. Félicitations. Bien joué, Tobias.
[00:02:02] Oui, eh bien, je ne sais pas trop. Il s'avère que je suis totalement hors de ma zone de confort et j'ai eu du mal avec à peu près tout. ces derniers jours, et pour être honnête, c'est tellement horrible que je ne sais même pas par où commencer.
[00:02:18] Eh bien, maintenant tu me rends curieux. Dis-moi, avec quoi as-tu du mal ?
[00:02:24] D'accord, alors, euh, laisse-moi expliquer. Donc, comme tu le sais, je travaille pour cette banque, et elle n'est pas énorme, ne gère pas de comptes personnels. Il n'y a pas beaucoup de transactions, ce n'est pas très public, mais, euh, nous faisons pas mal d'affaires dans l'immobilier, et nous réalisons environ un demi-milliard d'euros de revenus par an, donc je suppose qu'on pourrait appeler ça un succès. Et, euh, eh bien, pour moi personnellement, tout allait bien quand je ne m'occupais que des ordinateurs. Mais maintenant, je dois me soucier des gens, et j'ai l'impression que, franchement, personne dans le bâtiment n'a la moindre idée de ce qui se passe. Nous n'avons aucune idée de qui travaille sur quoi, où va tout l'argent. Je veux dire, nous avons 100 personnes, 50 projets par an, un énorme budget pour l'IT, genre 50 millions d'euros. Et, eh bien, autant que je puisse voir, rien n'est jamais réellement fait. Le seul projet que je connaisse qui ait vraiment été terminé l'année dernière était une petite version de SAP, et cela a pris trois mois et 15 personnes pour le réaliser.
[00:03:23] Oh, mon Dieu.
[00:03:25] Oh oui, je sais, ça a l'air drôle, mais je suis tout à fait sérieux. Euh, ma promotion est venue avec un engagement. Améliorer la performance informatique de 10% d'ici 2022. Et maintenant, j'ai l'impression de ne même pas savoir ce que cela signifie. Je veux dire, 10% de quoi ?
[00:03:42] D'accord, voyons voir. Cela pourrait prendre du temps. Tout d'abord, comment pensez-vous pouvoir exprimer la performance ?
[00:03:50] Comment puis-je l'exprimer ? Eh bien, je suis désolé, vous devrez expliquer ce que cela signifie.
[00:03:57] Eh bien, comment sauriez-vous que vous êtes productif ? Qu'est-ce que cela signifie d'être productif ?
[00:04:04] En général, tu veux dire. Je veux dire, je dirais que nous sommes productifs quand tout le monde est occupé à faire un travail qui profite à l'entreprise, comme quand nous n'avons pas trop de gens qui flânent et que je n'ai pas à me sentir mal de les payer.
[00:04:16] D'accord, donc les gens sont occupés à faire des choses. Mais sont-ils vraiment productifs alors ?
[00:04:23] Eh bien, oui, je veux dire, ils produisent du code, je suppose, des logiciels.
[00:04:30] D'accord. Donc, nous disons que vous êtes productif lorsque vous accomplissez quelque chose en fonction de votre objectif. Toute action qui rapproche l'organisation de son objectif est considérée comme productive. Toute action qui ne le fait pas, n'est tout simplement pas productive. Donc, la productivité en elle-même n'a pas de sens si vous ne savez pas quel est l'objectif. Et en fait, il n'y a qu'un seul objectif, quelle que soit l'entreprise.
[00:04:55] Eh bien, c'est évident. Je veux dire, nous sommes une banque, donc notre objectif est, eh bien, la paix. Non, je plaisante, c'est l'argent, faire de l'argent.
[00:05:05] Oui, l'objectif de toute organisation est de gagner de l'argent. Je sais, ça sonne vraiment, vraiment mal, mais bon, ça paie les factures.
[00:05:14] Eh bien, tu es sérieux. Je veux dire, qu'en est-il de Greenpeace ou d'Amnesty International ? Ne sont-ils pas censés travailler pour un monde meilleur au moins ? Je veux dire, sauver la planète, tout ce genre de choses.
[00:05:25] Eh bien, oui, bien sûr, ils devraient le faire. Mais ils ont quand même besoin d'argent pour faire leur travail et ils doivent s'assurer qu'ils ne manquent pas d'argent pour pouvoir continuer à faire ce travail.
[00:05:36] D'accord, donc je suppose que ça a du sens. Donc, ce que tu dis, c'est que, quoi que nous fassions, cela devrait viser soit à rendre l'entreprise plus efficace en termes de dépenses, soit à la faire gagner plus, n'est-ce pas ?
[00:05:49] En quelque sorte, oui. Toute action qui vous rapproche de l'argent est productive. Toute action qui vous éloigne de l'argent n'est pas productive. Maintenant, l'important est de savoir ce qui est quoi.
[00:06:04] Oh, mon Dieu. Oh, mon Dieu.
[00:06:09] Ça, ça veut dire que tout notre gros budget IT est jeté par les fenêtres, n'est-ce pas ? Je veux dire, autant tout arrêter si on ne peut pas dire sur quoi les gens travaillent.
[00:06:18] Oui, eh bien, c'est exact, mais ne t'inquiète pas. Tu peux encore arranger ça. À une condition, tu dois savoir quand tu gagnes de l'argent et quand tu n'en gagnes pas.
[00:06:30] D'accord, je comprends. Mais je veux dire, comment je fais ça ? Je veux dire, cette mise à niveau SAP a certainement coûté de l'argent, mais a-t-elle vraiment aidé d'une manière ou d'une autre ? Je veux dire, comment puis-je mesurer cela ?
[00:06:42] Et c'est une question très juste. En effet, comment sauriez-vous que vous gagnez de l'argent ? En fait, il existe un ensemble de métriques pour informer les organisations si elles atteignent leur objectif ou non. Avez-vous une idée de ce que ces métriques pourraient être ?
[00:06:56] Eh bien, généralement, les entreprises ont des chiffres annuels. Donc, revenu brut moins dépenses moins impôts égale bénéfice net.
[00:07:05] Oui, mais le bénéfice net ne suffit pas à lui seul. Donc, vous devez aussi comparer combien d'argent est gagné par rapport à combien d'argent est investi, c'est-à-dire, votre retour sur investissement. Mais il est toujours possible de faire des bénéfices, d'avoir un bon retour sur investissement et de faire faillite. Dans la plupart des cas, le problème est le flux de trésorerie.
[00:07:27] D'accord, donc si j'ai bien compris, je dois d'abord déterminer combien de l'argent que nous dépensons en IT est réellement utilisé pour faire du profit, et en même temps, je dois déterminer combien de liquidités sont disponibles à tout moment ? Euh, je veux dire, je comprends pourquoi, mais ce n'est pas facile. Je ne suis même pas sûr d'avoir l'habilitation de sécurité pour obtenir ces chiffres.
[00:07:50] Et tu soulèves un point très pertinent ici. Donc, en fait, pour tes opérations quotidiennes, tu ne peux pas te fier au bénéfice net, au retour sur investissement et au flux de trésorerie parce que, eh bien, tu n'as pas nécessairement accès à cette information. Tu as donc besoin d'autre chose, quelque chose qui te montre la relation entre la performance globale de l'entreprise et tes opérations quotidiennes. Maintenant, en fait, vous pouvez exprimer le bénéfice net, le retour sur investissement et le flux de trésorerie en termes de débit, de stock et de dépenses d'exploitation, et ce sont ces métriques que vous allez utiliser dans vos opérations quotidiennes.
[00:08:25] Ah, enfin quelque chose me semble familier. Les dépenses d'exploitation, c'est facile. Euh, nos dépenses d'exploitation, c'est l'argent que nous dépensons en salaires, plus l'argent que nous dépensons pour maintenir les ordinateurs en marche, n'est-ce pas ?
[00:08:39] Ou plus précisément, la dépense d'exploitation est tout l'argent que le système dépense afin de transformer le stock en débit.
[00:08:46] Débit. Mmh mmh. Et l'inventaire, tu veux dire les chaises, les tables et les ordinateurs portables ?
[00:08:54] Non, non, non, non, non, il ne s'agit pas des chaises, de la table, des ordinateurs portables et de tout le reste. Eh bien, oui, ils sont en inventaire sur votre bilan, mais dans votre cas, ce n'est pas vraiment le problème. Mais commençons par le débit. Donc, le débit est le taux auquel le système génère de l'argent par les ventes. Et ici, la partie ventes est en fait très importante. Si l'entreprise ne produit que des choses sans les vendre, eh bien, elle fera faillite.
[00:09:22] D'accord, euh, mais nous sommes une banque. Je veux dire, nous ne produisons vraiment rien. Enfin, d'accord, de l'argent, en quelque sorte, mais nous ne vendons pas ça, n'est-ce pas ? Nous vendons des prêts. Oh, d'accord. Eh bien, maintenant que j'y pense, c'est vendre de l'argent, et le prix est le taux d'intérêt. Donc, le débit mesurerait combien d'intérêts ont été collectés au fil du temps.
[00:09:45] Ce serait correct pour la banque en tant qu'organisation. Mais qu'en est-il de votre service informatique ? Comment votre service informatique soutient-il la vente de ces prêts ?
[00:09:54] Oh, de toutes sortes de manières. Je veux dire, nous avons des logiciels de gestion d'actifs qui suivent les prêts et les contrats et les bâtiments que nous aidons à financer, et nous avons des logiciels pour le centre d'appels, et puis il y a la comptabilité et nous aidons à configurer tous ces postes de travail et tout ça, donc l'informatique est à peu près partout. Et rien ne fonctionnerait du tout si ce n'était pas le cas.
[00:10:14] Mais que se passe-t-il si la législation sur les prêts change ou si la banque veut vendre un produit différent, disons un nouveau type de prêt ? La banque peut-elle faire cela sans l'informatique ?
[00:10:25] Ça dépend. Euh, considères-tu Excel comme de l'IT ? Parce que, eh bien, généralement, quand ce genre de choses arrivent, tout le monde panique et ça prend un an avant que nous commencions même à nous lancer dans le développement et, eh bien, les workflows habituellement, nous les mettons en place dans Excel, puis nous demandons aux gens de trouver, euh, de trouver des moyens de contourner le système et ensuite nous attendons que la mise à jour soit faite dans de nombreux, nombreux mois.
[00:10:52] D'accord, donc, si tout cela ne se produisait pas, est-ce que cela impacterait vos ventes, est-ce que cela impacterait votre objectif ?
[00:11:00] Oh, c'est sûr. Je veux dire, si nous ne pouvons pas vendre le nouveau produit, cela signifiera perdre des clients au profit de la concurrence, et si nous ne pouvons pas suivre la législation, eh bien, Je ne veux même pas y penser, c'est le pire des scénarios.
[00:11:14] Eh bien, voilà. Mettre en œuvre ces changements, c'est en fait votre débit, car ils soutiendront les ventes de la banque.
[00:11:22] Mmh mmh. Donc, si mon département voulait améliorer le débit, nous devrions essayer de livrer plus de ces changements ou plus tôt, n'est-ce pas ?
[00:11:32] Exactement, oui. Plus de fonctionnalités livrées signifie plus de débit.
[00:11:36] D'accord, mais je ne comprends toujours pas ce que signifie l'inventaire.
[00:11:41] Euh, je veux dire, nous ne produisons rien d'autre que de l'argent, et l'argent que nous gardons dans le coffre est probablement juste un flux de trésorerie, n'est-ce pas ?
[00:11:49] Donc, l'inventaire est tout l'argent que le système a investi dans l'achat ou la création des choses qu'il a l'intention de vendre.
[00:11:58] Euh, je ne comprends pas. Nous ne créons pas vraiment d'argent, et nous ne l'achetons pas vraiment non plus, donc je suppose que cela ferait un produit génial, mais ça se fait ailleurs.
[00:12:10] D'accord, voyons voir. En tant que service informatique, vous produisez des logiciels qui soutiennent la vente de prêts, n'est-ce pas ?
[00:12:19] Euh, je crois que je comprends maintenant. Donc, si nous dépensons notre budget informatique pour créer un logiciel qui gère les prêts, alors nous avons investi cet argent dans nos futures ventes, et ensuite cela devient un inventaire, n'est-ce pas ?
[00:12:33] Exactement, oui.
[00:12:34] Et si nous ne terminons pas ce programme ou s'il n'est pas publié, alors l'argent que nous avons investi ne contribue pas à l'objectif, et reste donc simplement de l'inventaire.
[00:12:44] Oui, en effet. Les programmes informatiques inachevés et non publiés sont juste de l'inventaire.
[00:12:50] Oh, wow. Euh, eh bien, merci, ça m'a déjà beaucoup aidé. Je vais aller chercher ces chiffres et ensuite voir comment nous nous en sortons. Euh, Je peux te redemander quand j'aurai fini ?
[00:13:07] Bien sûr que tu peux.
[00:13:13] Hé, Kiry, c'est encore moi.
[00:13:16] Bonjour Tobias. Comment vas-tu ? Comment vont les choses dans ton service informatique ?
[00:13:21] Oh, eh bien, nous avons fait beaucoup de recherches ces dernières semaines et j'ai trouvé quelques chiffres, donc ce n'est plus un mystère. Mais eh bien, j'ai toujours l'impression qu'il manque des pièces partout ou du moins je ne vois pas encore l'image complète.
[00:13:37] Euh, mais je vais rapidement, euh, j'ai d'abord une question facile. Donc, nous avons des cas complètement évidents, comme beaucoup d'argent a été investi, nous avons créé un logiciel, le projet est terminé, il est même considéré comme réussi, mais ensuite il ne va jamais en production. Ai-je raison de supposer que cela signifie qu'il n'y a eu aucun débit, mais beaucoup de gaspillage et que cela représente une perte totale ?
[00:14:02] Oui, tu as tout à fait raison. Il n'y a eu aucun débit et tu as perdu de l'argent en créant des stocks et en ayant des dépenses d'exploitation.
[00:14:09] D'accord, comme j'ai dit, c'est facile à trouver et facile à corriger, nous devrions juste arrêter de le faire. Euh, il faut s'assurer que le logiciel est nécessaire ou utile, ou si nous découvrons qu'il ne l'est pas, alors annuler tout le projet.
[00:14:23] Euh, mais ensuite, eh bien, il y a quelques autres projets où nous avons effectivement réussi à faire sortir le logiciel, mais seulement après de graves retards et beaucoup de retravail. Euh, des bugs ont été détectés en QA, des problèmes majeurs avec les opérations sont apparus après que tout ait été terminé, ce genre de choses.
[00:14:40] D'accord. Alors, maintenant je dois te demander quelque chose parce que je pense que cela va être très important. Comment fonctionne votre assurance qualité ?
[00:14:50] Il y a plus d'une façon ?
[00:14:53] Je pense que nous faisons la même chose que tout le monde. Nous passons du temps, faisons un plan, puis nous implémentons le plan, une fois que c'est fait et que c'est publié, ensuite, euh, nous le prenons du développement et mettons le logiciel sur un environnement d'intégration, et ensuite le département QA arrive et passe quelques semaines à exécuter des tests. Jusqu'à ce qu'ils arrêtent de trouver des défauts.
[00:15:15] Et combien de défauts votre QA trouve-t-elle que le développement aurait pu trouver avant ?
[00:15:21] Hmm. Eh bien, je suppose qu'il y en a quelques-uns.
[00:15:26] Eh bien, maintenant que j'y pense, probablement beaucoup.
[00:15:30] Je ne sais pas vraiment. Je sais que parfois ce sont juste des petites choses, comme quand quelque chose a la mauvaise couleur. Mais nous avons des défauts majeurs et parfois le truc ne fonctionne pas du tout, donc nous avons fait ces erreurs beaucoup plus tôt, même pendant la planification.
[00:15:46] D'accord, alors maintenant. Le développement a-t-il des tests d'acceptation automatisés ? Je veux dire par là des tests qui exécutent l'application comme un véritable utilisateur le ferait. Et ces tests sont-ils exécutés en continu à chaque modification du logiciel ?
[00:16:00] Oh, je ne pense pas que nous fassions ça. Je veux dire, nous avons des tests de développeur, bien sûr, mais, euh, eh bien, les gens courent toujours après des délais, donc je pense que le sentiment général est que les tests prennent beaucoup trop de temps et que nous devons livrer plus de fonctionnalités.
[00:16:16] Mais attends une minute. Que se passe-t-il lorsqu'un bug est trouvé par l'AQ ? Comment est-il résolu ?
[00:16:21] Eh bien, toute l'équipe est d'astreinte pendant la QA, donc ils corrigent tout ce que les testeurs trouvent immédiatement jusqu'à ce que tout soit vert.
[00:16:28] Donc, vous dites que vous avez le budget pour avoir des développeurs coûteux d'astreinte pour corriger les bugs sous pression, mais vous n'avez pas le budget pour des tests d'acceptation automatisés, n'est-ce pas ?
[00:16:41] Eh bien, maintenant que tu le dis comme ça. Oui, je veux dire, ça fait vraiment beaucoup d'argent. Euh, donc nous bloquons vraiment toute l'équipe pendant les trois semaines entières, donc cela seul devrait payer pour certains tests. Et je suppose aussi qu'une fois que nous trouvons un bug et que nous le corrigeons, alors tout doit être testé à nouveau, et encore, et encore, car potentiellement nous pourrions introduire de nouveaux bugs, euh, et cela s'accumulera.
[00:17:09] Ah, attends une minute. Donc, vous dites que vous faites tout ça manuellement ? Ça va prendre un temps fou.
[00:17:17] Maintenant, imaginez si le développement avait réellement investi dans des tests d'acceptation automatisés, dès le début, avec l'aide de l'AQ pour définir vos scénarios.
[00:17:27] Maintenant, une fois que vous avez mis en place ces tests et qu'ils s'exécutent en continu, vous commencez à implémenter la fonctionnalité. Maintenant, tant que le test échoue, eh bien, vous savez qu'il y a encore du travail à faire. Une fois que le test passe au vert, vous savez instantanément que la fonctionnalité est terminée et à ce moment-là, vous pouvez la déployer en production en toute sécurité.
[00:17:43] Putain de merde. Euh, c'est énorme. Je veux dire, je viens de réaliser que quand tu casses un truc pendant que tu y travailles encore, c'est aussi beaucoup plus rapide et facile à réparer.
[00:17:55] Exactement. Et vous empêcheriez également que votre QA travaille sur de la ferraille, c'est-à-dire votre logiciel défectueux. Faire travailler la QA sur un logiciel défectueux est juste une perte de temps et une perte d'argent, et en conséquence, eh bien, vous perdez en débit.
[00:18:08] Oh, eh bien, c'est un sacré point d'action. Euh, je pense que nous ferions mieux de commencer les tests automatisés. Euh, merci, ça a encore beaucoup aidé.
[00:18:20] Eh bien, de rien.
[00:18:25] Hé, encore toi, Cheri, ça faisait longtemps.
[00:18:29] Oui, ça faisait un moment. Comment les choses ont-elles évolué dans votre service informatique depuis la dernière fois ?
[00:18:35] Oh, nous avons fait de très grandes améliorations avec les tests automatisés. Euh, notre nombre de bugs a diminué de 80% et nous avons réussi à réduire le temps de QA manuel des deux tiers. Donc maintenant, ce n'est plus qu'une semaine. Et la plus grande amélioration, du moins pour moi, c'est que tout le monde est simplement heureux en le faisant car non seulement il y a moins d'incidents, mais les testeurs sont maintenant impliqués dans la conception des scénarios et ils peuvent voir que tout fonctionne comme prévu au lieu de toujours devoir signaler les mauvaises choses. Donc, oui, les choses s'annoncent bien. Mais, d'accord, je ne sais pas comment expliquer cela. Donc, maintenant que les problèmes de qualité ne sont plus un problème,
[00:19:15] euh, il y a des projets où nous finissons à temps, nous réussissons à réaliser toutes les fonctionnalités et il semble toujours que les résultats ne valent pas le coût, genre même pas proches. Et ceux-là m'inquiètent, pour être honnête, parce que c'est probablement la plupart de nos projets. C'est comme si tout le monde était occupé tout le temps, mais il n'y a juste pas de progrès. bien le faire, car non seulement il y a moins d'incidents, mais les testeurs sont maintenant impliqués dans la conception des scénarios et ils peuvent voir que tout fonctionne, comme prévu, au lieu de toujours devoir signaler les problèmes. Donc, oui, les choses s'annoncent bien. Mais, bon, je ne sais pas comment expliquer ça. Donc, maintenant que les problèmes de qualité ne sont plus un problème, euh il y a des projets où nous finissons à temps, nous parvenons à réaliser toutes les fonctionnalités et on a toujours l'impression que les résultats ne valent pas le coût, genre pas du tout. Et cela m'inquiète, pour être honnête, car c'est probablement la majorité de nos projets. Euh, c'est comme si tout le monde était occupé tout le temps, mais il n'y a tout simplement aucun progrès.
[00:19:38] D'accord, donc vous dites que tout le monde est occupé tout le temps, mais qu'entendez-vous réellement par là ? Travaillent-ils sur des choses qui aident vos clients ?
[00:19:48] Euh, oui, bien sûr, nous avons retiré tout ce qui n'aidait pas à atteindre l'objectif il y a un certain temps, comme vous l'avez suggéré. Euh, je devrais peut-être dire que tout le monde ne travaille pas toujours sur le projet. Euh, presque tout le monde a plus d'un projet et ils ont tous des responsabilités héritées à gérer, vous savez, comme la maintenance sur d'anciens logiciels, des choses comme ça.
[00:20:12] Mais pourquoi ? Pourquoi gardez-vous des gens qui travaillent sur différentes choses qui ne sont pas liées au projet qui est l'objectif ?
[00:20:19] Pourquoi occupons-nous les gens ? Euh, eh bien, parce qu'ils ne sont pas payés à ne rien faire, non ?
[00:20:28] Je veux dire, tout le monde n'est pas toujours nécessaire pour le travail de projet, alors afin d'utiliser au mieux leur capacité, nous essayons de leur donner du travail pour remplir leurs emplois du temps.
[00:20:39] Mmh. D'accord, ça semble intéressant. Mais laissez-moi vous demander quelque chose. Est-ce que tout le monde dans votre équipe a les mêmes compétences ?
[00:20:49] Non, je veux dire, bien sûr que non. Nous avons des développeurs front-end et back-end, des experts en bases de données, des spécialistes de l'IA, ça dépend vraiment du contexte du projet.
[00:21:00] Alors, que se passe-t-il, par exemple, lorsqu'une base de données a besoin d'une mise à jour urgente mais que l'expert est occupé à faire d'autres tâches ?
[00:21:07] D'accord, je suppose qu'alors ils devront juste attendre. Eh bien, ou peut-être quand c'est vraiment urgent, ils peuvent venir à court préavis. Euh, est-ce un problème ? Je veux dire, les gens peuvent juste continuer à faire d'autres choses en attendant, n'est-ce pas ?
[00:21:22] Alors, ce que vous faites ici, c'est équilibrer la capacité de chacun avec les demandes du marché, n'est-ce pas ?
[00:21:29] Je suppose qu'on pourrait dire ça. Ça, et nous essayons juste d'être efficaces.
[00:21:36] Maintenant, le problème avec l'équilibrage des capacités est que c'est un moyen sûr d'aller à la faillite, donc une capacité insuffisante entraînera une perte de débit. et une perte d'argent, et trop de capacité est juste un gaspillage.
[00:21:48] N'est-ce pas exactement pour cela que nous devrions essayer de l'équilibrer ?
[00:21:53] Non, vous ne voulez pas ça. D'accord, je dois vous expliquer quelque chose. Vous devez comprendre qu'il y a une différence entre activer des personnes et utiliser des personnes. Les gens sont activés quand ils font juste des choses pour les occuper. C'est comme appuyer sur l'interrupteur d'une machine qui fonctionne, peu importe si cela bénéficie au système. D'autre part, l'utilisation consiste à employer des personnes pour soutenir l'objectif.
[00:22:20] D'accord, euh, c'est déroutant. Je pensais que nous faisions cela. Je veux dire, toutes les différentes choses sur lesquelles ces gens travaillent sont en quelque sorte importantes, comme pour un projet ou un but. Cela ne signifie-t-il pas qu'ils soutiennent tous l'objectif ?
[00:22:35] Eh bien, si vous considérez l'entreprise dans son ensemble comme un système, oui, vous avez raison, ils soutiennent tous l'objectif, mais chaque projet en soi a un flux de valeur qui agit comme un système autonome. Si les gens sont utilisés sur différents projets, eh bien, vous vous retrouvez avec différents flux de valeur en compétition pour l'attention de ces personnes. En théorie, leur capacité est suffisante, mais les gens ne seront jamais disponibles au moment exact et pour le bon objectif.
[00:23:04] Oh.
[00:23:06] Laissez-moi vous aider ici. Un système est une boîte noire. Des choses entrent par une extrémité et un produit fini, qui représente la valeur client, sort par l'autre extrémité. C'est vrai pour chaque produit. Et c'est pourquoi vous ne pouvez pas regarder l'entreprise dans son ensemble. Vous devez regarder chaque flux de valeur individuellement, car chaque flux de valeur est une telle boîte noire. À moins que le flux de valeur ne dépende réellement de la valeur produite par un autre. De plus, chacun de ces systèmes a une base, un taux de rendement, et cette base est déterminée par exactement un goulot d'étranglement. Avez-vous entendu parler des goulots d'étranglement ?
[00:23:44] Euh, oui, j'en ai, je veux dire, sur les bouteilles, bien sûr. Ha. Euh, mais sérieusement, d'accord, c'est quand il y a un endroit où tous les éléments doivent passer et cela fait s'accumuler tout ce qui est devant tandis que tout ce qui est après reçoit un mince flux, n'est-ce pas ? Mais, euh, comment pouvez-vous être si sûr qu'il n'y en a qu'un ?
[00:24:07] Il peut y avoir plusieurs goulots d'étranglement potentiels dans un système. Mais nous assurons que chaque système n'a qu'un seul goulot d'étranglement directeur à la fois qui contrôle la performance globale du système.
[00:24:19] D'accord. Et comment trouvez-vous ce goulot d'étranglement ?
[00:24:26] Dans la fabrication, c'est assez facile, il suffit d'aller à l'atelier et de chercher des choses qui s'accumulent. En TI, eh bien, c'est moins évident.
[00:24:35] Alors, laissez-moi vous demander quelque chose. Utilisez-vous quelque chose pour visualiser votre travail ? Comme un tableau Scrum ou un Kanban ?
[00:24:42] Nous avons Jira, donc, oui.
[00:24:46] Mmh. Jira, n'est-ce pas ? Bien sûr, vous avez Jira. Qui n'en a pas ? Bon, peu importe. Euh, avez-vous des tickets qui s'accumulent dans une ou plusieurs colonnes ?
[00:24:58] Oh, hé, il y a toujours plus d'une page de tickets sur le tableau, donc nous défilons beaucoup, mais je ne pense pas que nous voyions des accumulations, je veux dire, ça n'a aucun sens de toute façon. Euh, les choses seront en cours jusqu'à ce qu'elles soient terminées. Et selon que vous considérez la colonne 'fait' comme un pilote, mais je suppose que nous ne le faisons pas parce que c'est là que nous obtenons du débit, euh, il n'y a vraiment qu'un seul endroit où ils peuvent s'accumuler et c'est la colonne 'à faire', n'est-ce pas ?
[00:25:27] D'accord, donc nous devons clarifier quelque chose ici. Qu'entendez-vous réellement par 'terminé' ? J'espère que vous voulez dire déployé en production et mis à disposition de vos utilisateurs, n'est-ce pas ?
[00:25:38] Non, bien sûr que non. Je veux dire, nous ne déployons pas tant que la QA n'a pas donné son feu vert. Donc, quand tout est terminé.
[00:25:46] Et pourquoi n'avez-vous pas de QA sur votre tableau alors ?
[00:25:49] QA ? Eh bien, si nous ajoutions cela, alors je suppose que tout s'empilerait là-bas. Jusqu'à la phase finale et ensuite tout se viderait d'un coup. Que cela nous dirait-il ?
[00:26:04] Eh bien, cela vous dirait où se trouve votre goulot d'étranglement, par exemple. Donc, en visualisant toutes les étapes de votre chaîne de valeur jusqu'à la mise en production pour vos utilisateurs, vous pourrez réellement découvrir ce goulot d'étranglement.
[00:26:17] Attendez, attendez, attendez, attendez, euh, est-ce que je comprends bien ? Nous sommes censés déplacer nos éléments de travail en production avant que tout le projet ne soit terminé ? Comme si les utilisateurs verraient des fonctionnalités à moitié existantes ?
[00:26:31] C'est un peu plus subtil. Oui, vous devriez déplacer votre travail en production aussi vite que possible. Non, les utilisateurs ne devraient pas voir des fonctionnalités à moitié existantes, cela ne sert à rien. Cependant, vous pouvez toujours déployer des fonctionnalités inachevées sans que les utilisateurs ne le remarquent réellement. Vous voulez cela parce que cela vous donnera un retour anticipé sur la façon dont ce code se comporte en production, ce qui est très précieux car cela vous permettra de prendre de nouvelles décisions.
[00:26:58] D'accord. Alors, la fonctionnalité serait déployée et testée mais non visible, comme, il y a une différence entre le déploiement et la publication ou plutôt la mise en ligne et la diffusion publique.
[00:27:10] Oui, et vous devriez visualiser tout cela. Également la distinction entre le déploiement et la publication, car il n'y a aucune valeur à accumuler des fonctionnalités non publiées en production, cela aussi crée du stock.
[00:27:21] Wow, euh, ça a du sens. Et en poursuivant cette pensée, je devrais trouver un moyen d'obtenir l'approbation d'une fonctionnalité à la fois au lieu d'avoir une semaine de QA à la fin du projet.
[00:27:37] Euh, en fait, ça ne devrait pas être trop difficile à organiser, les testeurs sont impliqués dans la rédaction des tests d'acceptation, donc ils connaissent déjà le produit et ils savent comment l'équipe fonctionne. Donc, ça ne leur prendrait probablement qu'une demi-heure pour faire une seule fonctionnalité et ils pourraient intervenir chaque fois qu'un test passe au vert.
[00:27:55] Oui, et en agissant ainsi, eh bien, vous améliorerez votre débit.
[00:27:59] Euh, d'accord, laissez-moi bien comprendre. L'idée est de littéralement rationaliser le processus pour livrer chaque élément de travail à travers l'ensemble du système aussi rapidement que possible ?
[00:28:12] Exactement, l'objectif est de créer un flux de travail rapide à travers votre processus de livraison.
[00:28:18] Euh, je comprends, mais cela ne signifie-t-il pas que je dois complètement repenser l'organisation de ma main-d'œuvre ? Genre, assigner tout le monde à un seul projet et un seul, ou mieux encore, à une seule tâche jusqu'à ce que ce soit vraiment entièrement terminé ?
[00:28:35] C'est exact.
[00:28:37] Et en agissant ainsi, eh bien, vous augmentez le débit tout en réduisant simultanément les stocks et les dépenses opérationnelles. En fin de compte, vous améliorez les trois métriques simultanément. Alors que par le passé, vous ne vous concentriez que sur une seule métrique, à savoir vos dépenses opérationnelles en gardant les gens occupés.
[00:28:56] D'accord. Euh, eh bien, ça va être une sacré réunion d'équipe lundi. Euh, je ferais mieux d'y aller. Merci, Julie.
[00:29:07] Hé, Jerry, j'ai une excellente nouvelle. Ça a vraiment marché.
[00:29:14] Fantastique, c'est génial ! Qu'est-ce qui a réellement fonctionné ?
[00:29:18] Eh bien, d'accord, je suppose Alors, bien sûr, les gens n'étaient pas très heureux de s'engager à ne faire qu'un seul projet et réorganiser toutes les choses anciennes a été douloureux, c'est le moins qu'on puisse dire. Euh, mais une fois que tout le monde a compris à quelle vitesse ils obtenaient leurs résultats, ça a juste décollé.
[00:29:38] Eh bien, c'est super. Donc, vous venez d'expérimenter les avantages de gérer vos projets en séquence au lieu de les faire en parallèle. Alors, laissez-moi vous expliquer ce qui s'est passé. Disons que vous avez deux projets, chacun prenant trois mois pour être complété. Si vous les faites en séquence, eh bien, vous devriez terminer le premier après trois mois et le second après six mois, n'est-ce pas ?
[00:30:01] D'autre part, si vous les faites en parallèle, en alternant toutes les deux semaines, que se passe-t-il ? En théorie, le premier projet devrait se terminer après cinq mois et demi. C'est déjà deux mois et demi plus tard que si vous les faites en séquence. Le deuxième projet devrait toujours se terminer après six mois. Eh bien, vous l'espérez. Mais en fait, il faudra encore plus de temps pour terminer les deux projets, car du temps sera perdu en raison des changements de contexte, des temps de configuration et des files d'attente.
[00:30:32] Et si vous avez les mêmes personnes partagées entre deux projets, eh bien, à un moment donné, un projet devra attendre une personne occupée à travailler sur un autre projet. Alors, ce qui semblait être une optimisation astucieuse, eh bien, finit par être un énorme gaspillage.
[00:30:47] D'accord, euh, c'est un bon résumé et, rétrospectivement, totalement évident. Euh, donc comme je le disais, les choses vont bien. Dans l'ensemble, je ne suis plus inquiet pour les améliorations de 10 % que je promets. Parce que nous sommes bien en avance sur ça. Merci. Euh, il y a quelques projets étranges qui me laissent encore perplexe, cependant.
[00:31:09] Euh, ils ressemblent aux autres, mais ils ont d'une manière ou d'une autre d'autres problèmes. Euh, par exemple, euh, nous avons un prestataire externe qui travaille sur un portail client. Et ils ont des dates de livraison fixes tous les six mois et bien sûr, peu importe la rapidité avec laquelle nos équipes livrent le logiciel qui doit se connecter au portail, nous livrons toujours à la même date.
[00:31:31] Euh, ai-je raison de penser qu'ils sont maintenant notre goulot d'étranglement et que nous pouvons faire ce que nous voulons, mais que nous ne pourrons pas améliorer le délai de livraison ?
[00:31:42] Oui, vous avez raison. Donc, la première étape est toujours d'identifier votre goulot d'étranglement. Et dans votre cas, c'est cette tierce partie et leur cadence fixe. Alors, comment pourriez-vous tirer parti de cette connaissance ?
[00:31:56] Tout d'abord, euh, ils ne devraient pas avoir à nous attendre, ou euh, être occupés à faire d'autres choses que le travail sur le portail. Assurez-vous que tout leur temps est utilisé pour livrer des fonctionnalités pertinentes.
[00:32:08] C'est ça. Dans une deuxième étape, vous exploitez le goulot d'étranglement, vous vous assurez que ce goulot ne travaille que sur des choses que personne d'autre ne peut faire.
[00:32:17] D'accord. Euh, et puis je suppose que nous pourrions changer nos propres délais de livraison, par exemple, avoir la même cadence pour ne pas avoir de fonctionnalités à moitié terminées au moment où elles sont déployées et nous correspondons toujours à l'ensemble des changements qu'ils peuvent gérer. Ou mieux encore, euh, devancer leur publication de quelques fonctionnalités afin que nous ayons toujours quelque chose à ajouter au cas où ils pourraient en mettre un petit plus. En d'autres termes, euh, nous devrions complètement synchroniser notre propre production avec la leur, n'est-ce pas ?
[00:32:46] Correct, vous devriez faire ça. Et c'est votre troisième étape. Subordonnez tout le reste au goulot d'étranglement et adaptez-vous toujours à son rythme.
[00:32:53] Oui, je pense que je comprends maintenant. Et et que diriez-vous, une fois que nous aurons réussi à nous synchroniser avec eux, de commencer à leur demander euh la moitié du cycle de publication ? Par exemple, publier la moitié des fonctionnalités tous les trois mois afin d'obtenir un délai de commercialisation plus court et si nous maintenons le reste de la production synchronisé, cela ne devrait pas être trop difficile, n'est-ce pas ?
[00:33:14] C'est une idée très intelligente. Donc, en réduisant de moitié le cycle de publication, vous réduisez la taille des lots, ce qui aura pour conséquence de réduire votre délai de mise sur le marché et d'augmenter le flux de travail, c'est-à-dire votre débit. Et vos utilisateurs obtiendront leurs fonctionnalités plus tôt et vous recevrez des retours plus rapidement. Donc, au final, vous pourrez mieux répondre au marché.
[00:33:33] Sans compter que nous pouvons vendre plus tôt, donc le retour sur investissement sera beaucoup plus rapide.
[00:33:38] Et votre flux de trésorerie augmentera.
[00:33:41] C'est vrai. Euh, j'ai pensé à leur donner accès à notre propre pipeline de livraison afin qu'ils puissent bénéficier de tous les progrès que nous avons faits en matière de tests automatisés et et peut-être que cela aidera à accélérer leur temps et leur propre livraison.
[00:33:57] Eh bien, c'est un très bon point. Donc, jusqu'à présent, tout ce que vous avez fait, c'est mieux utiliser votre goulot d'étranglement en l'exploitant, puis en subordonnant tout le reste au goulot d'étranglement. Cela ne vous a rien coûté du point de vue de l'investissement, vous l'avez en quelque sorte obtenu gratuitement. Ce n'est que maintenant que vous allez dépenser de l'argent en augmentant votre goulot d'étranglement afin de le faire fonctionner plus rapidement et de gérer un débit plus élevé.
[00:34:23] Oui, je pense que je commence vraiment à comprendre. Euh, ce n'est même pas si difficile une fois que vous voyez les schémas.
[00:34:32] En effet, ce n'est pas si difficile, mais eh bien, je dois vous l'accorder, quand on est habitué à la comptabilité analytique classique, cela semble très contre-intuitif.
[00:34:41] Merci. Oh, là là. Euh, bon, d'accord, euh, maintenant il y a juste une autre équipe de projet qui me dérangeait. Et euh, eh bien, maintenant que vous avez expliqué, euh, je peux presque deviner ce que vous allez dire. Alors, il y a un projet, euh, et tout le monde travaille toujours à pleine capacité. Donc, ce n'est pas qu'ils travaillent tous encore sur d'autres projets, c'est juste qu'il y a tellement de choses à faire. Euh, et maintenant, si je comprends bien le concept de cadence fixe, alors ne devraient-ils pas être capables de fonctionner à un rythme synchronisé, euh, mais ils n'y arrivent tout simplement pas, d'une manière ou d'une autre. Euh, quelqu'un attend toujours quelqu'un d'autre, et quand vous leur demandez pourquoi, c'est généralement une excuse bidon du genre le serveur ne démarre pas correctement, ou la connexion internet était lente. Je veux dire, je comprends que des imprévus peuvent arriver, mais la plupart des raisons qu'ils me donnent sont des choses qui pourraient prendre des minutes, mais pas des journées entières ou même des semaines.
[00:35:39] D'accord, donc ce qui se passe ici, ce sont deux phénomènes : les événements dépendants et la fluctuation statistique. Vous avez donc des événements dépendants lorsqu'un événement ou une série d'événements doit avoir lieu avant qu'un autre événement ne puisse commencer. Disons que vous avez un processus linéaire où nous avons deux étapes de traitement et trois étapes de livraison. Les étapes de traitement prennent chacune cinq minutes et chaque étape de livraison prend 10 minutes, donc l'ensemble du processus prend 40 minutes au total. Maintenant imaginez que la première étape de livraison est un peu lente, elle prend 15 minutes. Cela ferait que tout le processus prendrait 45 minutes pour être complété, c'est malheureux, mais pas vraiment un problème.
[00:36:23] Maintenant, imaginons que l'étape de livraison du milieu est lente, elle prend 20 minutes. Encore une fois, cela aura un effet sur le temps de réalisation global, tout le processus prend maintenant 15 minutes. Cela signifie également que la première étape de livraison peut maintenant être exécutée deux fois pendant le temps que l'étape de livraison du milieu livre, elle produira donc deux fois plus de stock. Pendant ce temps, les autres postes de travail derrière l'étape de livraison lente resteraient inactifs parce qu'ils n'auraient rien à faire. Alors, c'est du temps perdu.
[00:36:55] Et cela deviendrait rapidement incontrôlable car vous ne pourriez jamais rattraper l'effet secondaire indésirable.
[00:37:04] Exactement. Maintenant, c'est un exemple linéaire très simple. Dans la vie réelle, les processus sont beaucoup plus complexes, ils peuvent avoir des parties parallèles et des dépendances avec d'autres équipes ou même des entreprises. Même la plus petite irrégularité aurait d'énormes conséquences. Mais le problème, c'est que certaines choses peuvent être planifiées avec précision, mais la plupart des distractions et des légères variations sont tout simplement imprévisibles.
[00:37:31] D'accord, en d'autres termes, nous ne pouvons jamais faire de plans exacts, mais nous devons accepter que les choses iront toujours mal.
[00:37:41] En effet, tous ces événements sont soumis à des fluctuations statistiques. Ainsi, la plupart des facteurs critiques pour la réussite d'un projet ne peuvent être déterminés précisément à l'avance. En fin de compte, vous devez prendre en compte ensemble les deux phénomènes, les événements dépendants et la fluctuation statistique.
[00:37:57] Et nous ne pouvons le résoudre qu'en
[00:38:02] laisser une certaine marge de manœuvre ?
[00:38:07] Oui, j'y venais. Vous devez donc introduire un certain mou pour absorber ces événements imprévisibles. Et c'est pourquoi c'est une mauvaise idée de maintenir votre utilisation proche de 100%, car cela laissera de moins en moins de marge de manœuvre. Et par conséquent, tout événement imprévisible aura un impact énorme sur votre délai de livraison.
[00:38:27] Eh bien, si c'est ce qu'il faut pour qu'ils livrent quoi que ce soit, alors je suppose que ça vaut le budget. Et nous aurons certainement des visages plus heureux en retour, ça c'est sûr. Euh. Oh wow, Jerry, je n'en reviens pas. Ça ne fait que quelques mois. Nous avons complètement réinventé le département informatique et encore quelques changements et maintenant nous avons terminé.
[00:38:50] Whoa, whoa, whoa, calmez-vous. Ce ne sera pas terminé après ces quelques changements supplémentaires. Ne laissez pas l'inertie devenir votre prochain goulot d'étranglement.
[00:39:00] Je ne comprends pas. Que signifie inertie ?
[00:39:06] Eh bien, cela signifie ne soyez pas trop heureux de ce que vous avez accompli. Cela vous rendra complaisant. Une fois que vous supprimez le goulot d'étranglement dans votre département informatique, un autre goulot d'étranglement apparaîtra ailleurs. Et c'est à vous de trouver ce nouveau goulot d'étranglement.
[00:39:19] Oui, je veux dire, vous avez dit qu'il y en a toujours un. Donc, même si celui sur lequel nous travaillions n'est plus le facteur limitant, alors il y aura toujours quelque chose d'autre qui le sera. Et donc, nous devons continuer à répéter les mêmes étapes, n'est-ce pas ?
[00:39:36] Exact, en effet. Donc, le nouveau goulot d'étranglement pourrait être en amont de votre service informatique. Dans les ventes ou le développement de produits, peut-être ne pouvez-vous pas faire approuver les commandes assez rapidement. Ou ce sera en aval de votre service informatique, sur le marché, peut-être que la demande pourrait être plus élevée. Alors, vous devez penser à un meilleur marketing.
[00:39:54] Donc, le monde ne s'arrête pas et les marchés changent. Il est en fait tout à fait logique que cela doive être d'une certaine manière itératif.
[00:40:04] Donc, pour conclure, appelons d'abord le goulot d'étranglement une contrainte désormais. C'est un meilleur terme. Parce que c'est plus générique. Une contrainte pourrait être un département, cela pourrait être des personnes, cela pourrait être un serveur, cela pourrait être une politique. Maintenant, pour améliorer vos performances, eh bien, vous devez répéter les cinq étapes suivantes. Donc, tout d'abord, vous devez identifier la contrainte. Ensuite, vous exploitez la contrainte. Ensuite, vous subordonnez tout à la contrainte. Après quoi vous pouvez élever la contrainte. Et enfin, eh bien, vous répétez. Vous revenez à l'étape un afin d'identifier votre nouvel objectif.
[00:40:42] Et en faisant cela, la qualité est toujours intégrée
[00:40:47] et des tailles de lot réduites.
[00:40:52] Oui, vous l'avez Tobias, bien joué.
[00:40:54] Je suis très doué pour ça.
[00:41:00] D'accord. Alors, à tous, merci, euh, d'être restés avec nous, et nous espérons que vous avez eu autant de plaisir à l'écouter que nous à le créer. Euh, maintenant, nous devons admettre que rien de tout cela n'était notre propre idée, bien sûr.
[00:41:18] Donc, tout cela était basé sur Elia qui a obtenu du travail à l'école, qui a été publié en 1984. Euh, donc ça existe depuis très, très longtemps. Si vous n'avez pas lu le livre 'Le But', eh bien, vous devriez vraiment, vraiment le faire.
[00:41:34] D'accord, et maintenant
[00:41:36] Merci de votre temps.
[00:41:37] Je n'ai aucune idée de comment fonctionne ce truc à distance, mais je suppose que nous allons discuter. Alors, euh, allons-y et je vais probablement devoir prendre une bouteille de whisky avant de commencer. Euh, donc merci à tous.

Transcription (Traduit)