Marie-Pia Ignace - Andon et flux, juste-à-temps et confiance mutuelle (fr)

[00:00:07] Bonjour. Donc je viens vous parler de de lin dans le monde de la tech et j'espère que ce sera simple, applicable et que vous y trouverez un intérêt.
[00:00:24] Alors un jour, j'ai assisté à à un jeu de rôle, en fait une espèce de jeu de rôle unker au sein d'une réunion, il y avait un certain nombre de personnes d'une même grande entreprise du 40, tous avec des rôles de dirigeant et donc il fallait que ça soit drôle et on leur a dit expliquez quel super-héros vous êtes. Et à partir de ce super-héros, on va essayer de savoir quel métier vous faites, c'était des gens qui se connaissaient assez peu. Et donc voilà, euh, ce qu'il a mis le DCI.
[00:00:50] C'est de ma faute, c'est toujours de ma faute. C'est ma faute quand ça va pas, c'est ma faute quand on arrive pas à faire quelque chose. Toujours de ma faute et la vie n'est quand même pas si simple.
[00:01:02] D'une certaine façon, il avait parfaitement raison, c'est toujours de sa faute. Donc la notion de frustration numérique au sein des entreprises, c'est quelque chose qui est évident aujourd'hui. Là, c'est une enquête qui vient de sortir d'une boîte qui s'appelle Nex Think. Donc euh, le troisième facteur de turnover et d'épuisement professionnel, c'est la qualité des outils numériques mis à à disposition des des des collaborateurs dans l'entreprise. C'est tristoun quand même, hein. Parce que quand on va voir les gens qui bossent dans les DC, dans les dans dans l'infrastructure et cetera, on voit des gens qui sont sympas, qui ont envie de se donner, qui veulent bien faire les choses et le constat, c'est que 20 à 40 % des des gens qui quittent une entreprise peuvent la quitter pour des raisons de qualité des outils numériques.
[00:01:48] Mais qu'est-ce qu'ils en disent les dev et les ops? Alors même chose, je suis allé regarder un peu. Ce que disaient les uns et les autres, il paraît que vous êtes tous passionnés par votre métier, par les challenge thinking qu'il y a, que ça vous tire vers le haut, que ça vous aide à vous lever le matin et à sortir du lit. Tout ça c'est vraiment génial. Je sais pas si c'est votre vie et votre situation personnelle. Moi, j'ai rencontré Jess Humble, donc Jess Humble, c'est quelqu'un qui a écrit The Lean Enterprise, qui était qui fait beaucoup de choses en terme conceptuel et pratique sur le CICD qui est l'un des pères fondateurs du mouvement DevOps, donc un monsieur qui qui qui sait de quoi il parle. Et donc un jour il m'a dit tu sais la raison pour laquelle, mais vraiment la raison pour laquelle je me suis lancé dans Devops, c'est la suivante. Mon rêve personnel, c'était le vendredi à 17h, j'ai les pieds dans la piscine, un Margarita à la main et la vie est belle. Mais comme je suis du côté des Ops, le vendredi à 17h, je me dis mon Dieu mon Dieu, il va se passer un truc ce weekend, ça va encore mal se terminer, il va falloir que je sorte de mon lit, il va falloir que je sois disponible samedi, dimanche, le jour, la nuit. Non, le weekend, c'est pas un moment sympathique. Et donc il s'est dit je vais partir vers DevOps comme ça, on va faire des choses qui vont être bien intégrées, qui vont être mises en production et moi je serai tranquille. Ce qui veut dire que finalement, il y a quand même trois points de vue qui sont assez complémentaires qui sont celui du du DSI tel qu'il leur sent et dans je vous ai parlé de ce DSI bancaire, mais j'ai aussi l'image de la DSI dans dans dans une grande entreprise industrielle française qui disait moi j'ai plus à la cortine, hein?
[00:03:10] Parce que à chaque fois que j'y vais, je suis prise à partie par tout le monde. Donc voilà. Donc ça c'est le point de vue du dirigeant qui trouve que ça n'est pas si facile que ça de s'occuper de l'informatique. Le point de vue de l'utilisateur qui est quand même un peu un peu désolé qui dit est-ce que ma journée va bien démarrer? Est-ce que je vais arriver à tenir ce que je dois tenir cette journée aujourd'hui parce que je n'ai pas une confiance totale dans ce que les le numérique fait pour moi. Et puis finalement, les gens de la tech qui peuvent avoir l'air sympa, souriant, détendu, mais qui qui aimerait tellement avoir des weekends tranquilles. Donc ça, c'est la convergence des des analyses. Alors moi, je suis une experte du Lean management. J'ai commencé à faire du line dans le monde de l'Haïti en 2005, donc je suis un dinosaure du Lean management dans l'Haïti. J'ai fédéré autour de moi toute une équipe de gens dans les années 2000, dont bah régist Medidin qui est intervenuu ce matin, Cécile Dijou qui est intervenuu un peu il y a quelques temps et cetera. Et donc on a essayé d'explorer ce que c'était que le line dans l'Haïti et vous le savez, le line dans l'Haïti c'est une question de voiture.
[00:04:10] Pas obligatoirement dans l'Haïti, mais en tout cas, le line c'est une question de voiture. Donc ça c'est une Lexus. Lexus c'est la marque de luxe de Toyota. C'est une très belle très belle aventure entrepreneuriale et industrielle. Et donc la première fois que je me suis intéressé à l'informatique chez Toyota, en fait, je suis tombé très rapidement sur le Chief Engineer de Lexus qui disait à l'époque, nous avons 12 millions de lignes de code embarqué à l'intérieur de la voiture. Et l'époque c'était il y a plus de 10 ans. Aujourd'hui, il y a des des vrais débats de fond pour savoir s'ils en ont plutôt 50 ou 100 millions de lignes de code. Donc voilà, donc c'est un objet qui est à la fois un objet numérique et on le sait avec Tesla, c'est un objet qui sera de plus en plus numérique. Et puis c'est aussi un objet qui a un moteur, des roues, un embrayage et cetera et donc c'est un objet qui a 12 à 15000 pièces à l'intérieur. Donc avant d'être un objet numérique, c'est un objet manufacturé, un objet d'assemblage avec 12 à 15000 pièces. Et donc l'une des raisons pour lesquelles on s'intéresse depuis très longtemps à Toyota, c'est parce que chez Toyota, on parle de qualité totale. Ça c'est un classement extrêmement récent sur les voitures les plus fiables en 2022, avec un site extrêmement compétent qui s'appelle Vromli et Vromli fait référence à plusieurs autres grosses enquêtes elle aussi ayant référence et étant les grandes références aujourd'hui dans ce domaine-là. Donc la première voiture la plus fiable en 2022 c'est une Lexus, la deuxième c'est une Toyota. Ensuite vous avez encore trois asiatiques, puis vous avez enfin une voiture une marque européenne, vous avez Porsche. Et puis après ça monte, ça monte, ça monte et ça s'arrête à 10 et à 10, il y a toujours pas de français. Donc voilà, donc on a aujourd'hui des objets qui font donc 12 à 15000 pièces assemblées. Euh 50 ou 100 millions de lignes de code embarquées et qui sont considérés comme étant les voitures les plus fiables. Ça vient dire que de façon sous-jacente, il y a un système de production qui est extrêmement fiable. Aussi bien dans le réel que dans le digital.
[00:06:08] Alors là, je vais pas vous faire beaucoup de théorie, hein. C'est pas mon objectif, j'aimerais mieux qu'on qu'on qu'on partage des cas et puis qu'on partage peut-être des choses un peu concrètes à faire. Mais il n'empêche que un tout petit peu de théorie, donc ça c'est extrait d'un d'une publication de l'Institut Lean France ce que j'ai que j'ai cocréé il y a aussi un certain temps. Et donc l'Institut Lean France a un volet qui s'appelle Lean and Learn, je vous ai mis le QR code pour y accéder. On peut cliquer sur n'importe quel mot et on a une définition parfaitement orthodoxe de ce que ça représente. Moi il y en a quoi? Donc le line, c'est une maison, ce matin régist en a reparlé, c'est une maison avec un toit, des piliers, un soubassement, tout ça c'est très bien. Euh donc deux deux deux principes constructifs importants, celui qui est à gauche qui est en fait le principe du juste à temps et celui qui est à droite qui est le principe de la qualité totale. Donc ils sont absolument indissociable. Si on essaie de faire du juste à temps, on ne sortira on n'y arrivera que parce qu'on fera de la qualité totale. Voilà, donc les deux sont extrêmement complémentaires.
[00:07:09] Juste pour info, quand on parle de flux, hein, floconne, c'est c'est c'est du flux. Le flux, c'est un tout petit bout de ce qui est entouré dans ce tout petit pavé qui est en haut à gauche de de la maison ligne. Donc après il y a le flux, le flux tiré, le flux pièce à pièce, le flux tiré lissé et cetera, il y a beaucoup de théorie autour de tout ça. Et moi ce dont je vais vous parler, c'est juste un tout petit bout de ce qui est en haut à droite dans la qualité totale qui est l'Andon. Voilà, un truc qui est vraiment dans le cœur de l'ADN des systèmes des systèmes line mais qui n'est qu'un tout petit bout de ce truc là.
[00:07:44] Voilà, donc qu'est-ce que c'est qu'un Andon, c'est extrêmement simple. Un Andon, c'est un système qui dit stop.
[00:07:50] On s'arrête.
[00:07:52] On a vu un défaut, on s'arrête. On n'est pas capable de tenir le rythme, on s'arrête. Donc, le premier takeaway de ma présentation, c'est se dire à quel moment est-ce que vous considérez que vous allez vous arrêter? Et comme on est dans le Lean, comme on est dans le flux, comme on est dans le juste à temps, et bien on va s'arrêter maintenant, à partir du moment où on voit le défaut. Donc vraiment le donne, c'est juste ça, c'est l'arrêt au défaut.
[00:08:16] Alors c'est comme tous ces systèmes là, ça a l'air extrêmement simple et c'est d'autant plus simple que ça doit être manipulé par des des ouvriers hein, donc des gens qui n'ont pas obligatoirement des qualifications énormes. J'ai rencontré une ingénière qui avait encadré des des équipes dans l'industrie automobile en Allemagne, elle mettait sur son CV, je parle turc. J'ai dit mais comment ça tu parles turc, elle parlait déjà français, anglais, italien et cetera.
[00:08:37] Mais oui, je travaille en Allemagne. Voyez, c'est donc en Allemagne, les ouvriers sont turcs, donc c'est pas si simple que ça d'échanger entre les gens qui parlent des langues différentes. Mais les les objets Lean sont des objets simples. Le Lean, l'Andon, c'est stop. Donc c'est simple, à un moment, j'ai une corde, on parle de la corde Andon, j'ai une corde, je tire sur la corde et cette lumière qui est là au vert parce que tout va bien, et bien, elle va arriver au rouge parce que ça va moins bien qu'on ne le pensait. Exactement maintenant. Moi j'ai suis allé visiter une usine Toyota au Japon de 6000 personnes qui était en quatre blocs hein, le premier bloc c'était de la soudure et le dernier la voiture sortait, c'était de l'assemblage la voiture sortait. Donc c'est en juste à temps, la voiture avance à l'intérieur de de tout ce bloc et de ces 6000 personnes qui travaillent. Dans le premier bloc, il y a un robot soudeur qui a arrêté de fonctionner, l'opérateur qui surveillait la zone a tiré l'Andon, au bout de 10 minutes on nous a dit à nous les visiteurs, écoutez, on va aller voir autre chose.
[00:09:31] On a été dans le dernier bloc, l'usine s'est arrêtée sous nos yeux. C'est-à-dire qu'on arrête maintenant.
[00:09:38] Donc on fait en sorte que le problème de qualité devienne un problème dont on a envie de se saisir. Parce que 6000 personnes qui bossent pas, c'est c'est compliqué quand même.
[00:09:47] C'est compliqué à justifier.
[00:09:49] Donc voilà, donc je je je parle de mes histoires d'Andon, à l'un de l'une des personnes que je coache, donc lui il est il était il est en retraite maintenant, il était directeur de la production informatique d'une grande banque, on s'entendait vraiment bien, on avait fait des choses vraiment sympas ensemble. Et puis un jour, je lui dis écoute peut-être qu'un jour, on pourrait parler d'Andon et de l'arrêt au défaut. Et là, il est en train d'appuyer sur le bouton de l'ascenseur et il m'a dit non pas chez nous. Non, ce serait pas possible. On arrêterait tout. Oui, bah chez Toyota, on arrête tout et là, dans l'informatique, on arrêterait tout. Moi il y en a quoi, on arrêtait quand même plus de choses qu'il ne le pensait. Ça c'était chez lui. Donc des file system des file system qui se remplissent, se remplissent, se remplissent, mettre en place des systèmes d'Andon autour de file système qui se remplissent euh ça permet d'éviter l'incident. Donc voilà. Donc ses équipes faisaient ça depuis un certain temps, la disponibilité des SI s'était amélioré, donc il y a des choses chez lui qui fonctionnaient, c'était pas à l'échelle de toute son organisation, mais en tout cas, ça fonctionnait. La création des environnements. Alors là, c'était une approche différente de l'Andon. Donc créer les environnements pour le dev, les tests, l'après prod, la prod et cetera. Euh les environnements, ça prenait plusieurs semaines et parfois plusieurs mois avant de pouvoir obtenir un environnement. Donc il s'était mis dans l'idée qu'on pourrait avoir une organisation plus de type usine usine d'assemblage comme chez Toyota et dans ce cadre-là, on s'était dit avec cette usine là, à quelle vitesse est-ce qu'on pourrait aller? Et on s'était dit si on arrive à livrer un environnement en 7 jours entre la demande et la mise à disposition, et bien on aura la possibilité d'abord de beaucoup mieux servir les demandeurs et puis surtout de faire disparaître toute la conduite de projet sur la livraison des environnements parce que pour 7 jours, il y a pas besoin de conduite de projet. L'équipe peut s'auto-organiser. Donc voilà, ces gens-là ont fait un certain nombre de choses, sont arrivés à la fin de tout ça, mais moyen en quoi ils ont créé un espèce d'environnement prototype. Donc un espèce de prototype, un prototype représentatif de tout et ils le faisaient tourner très régulièrement. Et ça leur permettait de voir à quel moment leur crason d'environnement rencontrait un défaut et sur la base de ce défaut, ils arrêtaient le process à l'endroit où ils en étaient et ils allaient chercher. Parce qu'en fait l'environnement était dépendant de tas d'autres blocs externes qui eux-même évoluaient en permanence hein donc passer d'une version A à une version B et donc les tout ce qui avait été mis en place pour pouvoir générer les environnements rapidement euh pouvait se retrouver cassé dans un endroit. Et donc la London apparaissait, claque, on arrêtait au défaut, on corrigeait ce qu'il fallait corriger, on partageait ce qu'on avait compris avec les membres de l'équipe et on pouvait continuer à maintenir de la qualité et de la vitesse sur la création des environnements.
[00:12:20] Un autre exemple complètement différent encore, c'est le cryptage de base de données. Donc chez lui, il y avait 10000 bases de données à crypté pour des raisons de cybersécurité. Donc 10000 c'est beaucoup, quand on est dans un esprit Lean, on se dit si j'en fais 10000 sur 2 ans. 2 ans c'est 400 jours, il faudrait que j'en fasse 25 par jour à peu près le calcul. Moi il y en a quoi, la première au bout de 2 ans, elle était toujours pas sortie. Donc ils ont bien compris qu'il y avait un problème de processus là-dedans et donc en fait ils ont déné une forme de processus théorique et ils ont fait avancer la première base à l'intérieur du processus théorique avec un arrêt à chaque défaut. Et donc on corrigeit à l'endroit où on coinçait sur le le cryptage de la base de données. Et puis on avançait, on avançait, on avançait, en 4 mois, ils ont débuggué leur processus et puis ensuite, ils ont pu commencer à à passer à l'échelle. Donc à l'arrêt au défaut pour arriver à stabiliser un processus nouveau, à le maîtriser au sein de l'entreprise.
[00:13:07] Si on parle du dev, là c'est quelqu'un que j'aime beaucoup qui s'appelle Emmanuel Chanon, il il bloque beaucoup moins maintenant, mais enfin, il a laissé pas mal de traces sur internet. Il bosse chez Thalès. Il est à l'époque, il était responsable de l'informatique embarquée d'un d'un bout d'avion, de mémoire c'était le train d'atterrissage. Et donc son son gros client c'était Airbus mais c'était aussi des des gens dans l'armée. Et donc en fait, c'est quelqu'un qui était vraiment un ingénieur du logiciel extrêmement extrêmement expert, moi j'étais très très impressionné par ce qu'il par ce qu'il faisait. Et donc il avait tous tous ses systèmes de de de de de test automatique et il avait mis son petit son petit bonhomme là, son petit bonhomme qui était donc connecté au système et tant que les tests d'intégration se passaient bien, tout allait bien et quand quelque chose ratait, en fait, le petit bonhomme changeait de couleur et donc là, toute l'équipe s'arrêtait.
[00:14:00] C'est-à-dire qu'il y avait un signal qui était donné et toute l'équipe s'arrête, toute l'équipe de dev. Et l'équipe de dev essaie de comprendre ce qui allait se passer. Moi il y en a quoi, l'équipe d'Emmanuel a a été un jour reconnue par Airbus comme étant cette année-là son meilleur fournisseur. Parce qu'en fait, ils étaient tellement bons dans la qualité de ce qu'ils livraient que ils passaient très rapidement c'est c'est il y a il y a des processus de d'acceptation de de du logiciel pour les avions, on le sait on le sait malheureusement. Et donc ils passaient tellement rapidement les différentes étapes, tellement la qualité était bonne au démarrage, que Airbus les a identifié et les a nommé cette année-là leur fournisseur préféré.
[00:14:38] Donc voilà, donc cette histoire de stop. Stop, c'est assez simple, mais ça pose déjà une première question. qui est de savoir, est-ce que vous êtes capable vous de voir vous êtes en train de sortir du délai que vous êtes fixé? Et est-ce que vous êtes capable vous de voir que ce que vous êtes en train de faire génère de la non qualité?
[00:14:57] Et donc ça, ça demande déjà une bonne connaissance du métier sur lequel on est. Un bon niveau de réflexion. Il va peut-être falloir s'y mettre à plusieurs pour dire ça c'est bon, ça c'est pas bon, là tu vois, il y a un défaut, tiens celui-ci, on pensait que ça serait terminé en une demi-journée, une journée, deux jours, 3 jours, bah on y est pas du tout. Donc il faut être capable de de voir cet écart.
[00:15:15] Le Lean parle beaucoup d'écart, de voir cet écart entre la situation qu'on imaginait être la bonne et la situation réelle qui est en train de diverger. Et de voir cet écart maintenant. Est-ce qu'on s'arrête quand on voit le défaut?
[00:15:31] Le deuxième point, c'est qu'une fois qu'on s'est arrêté, il va bien falloir faire quelque chose maintenant, hein.
[00:15:35] Donc on va pas on va pas regarder son système en s'asseyant, puis en se disant bof, qu'est-ce qu'on fait? Donc on va faire deux possibilités. Soit c'est un problème de rythme et il s'est passé quelque chose dans le rythme, vraiment un petit coup de main, ça permettrait de de se remettre à la bonne vitesse et à ce moment-là euh non pardon, ça c'est plus loin. Donc donc la première chose, c'est que qu'est-ce qui vous donne le signal du stop, ça peut être une analyse personnelle ou une alerte machine. Le petit le petit bonhomme là qui clignotait en en vert ou en rouge, ça c'est une alerte machine. Vous avez des tas de systèmes aujourd'hui qui vous permettent de dire non, là la situation n'est pas normale. Je vous alerte tout de suite. Et donc étant alerté, il faut faire quelque chose. Et l'autre point, ça peut être une analyse personnelle, moi je connais le système sur lequel je bosse et puis je suis en train de me dire bah non, le système ne répond pas comme j'aimerais qu'il réponde, je sais pas, ne serait-ce qu'à ne pas de réponse par exemple, c'est ça peut être l'un des éléments. Et donc le voyant, je peux arrêter le système.
[00:16:27] Une fois que qu'on a fait ça, on est bien content, on a arrêté l'ensemble et puis ensuite bah qu'est-ce qu'on fait? Et là on rentre quand même dans des choses un petit peu plus difficiles d'une façon générale. Euh, ça peut se complexifier. Je vois pas pourquoi est-ce que ça sera un point bloquant. En tout cas, le la première réponse c'est qu'il va falloir s'en occuper. Mais s'en occuper sérieusement. Alors s'en occuper, il y a deux possibilités. Donc il y a une possibilité dans laquelle en fait bien en fait on est on a juste besoin d'une aide ponctuelle. On coince sur quelque chose, on n'est pas tout à fait assez rapide. Si quelqu'un vient me donner un coup de main et me décoinse là-dessus, on va pouvoir se remettre dans le cycle normal.
[00:17:05] Quoi que ça veuille dire. Donc c'est juste un besoin d'un renfort ponctuel. Bon, bah très bien. Donc on arrête le système, on lève la main, on a un système d'aide, il y a quelqu'un qui vient, qui dit attends, pendant que tu t'occupes de ça, je m'occupe de ça, on reconverge dans 10 minutes et là ça sera bon, tu seras remis sur ton propre rythme. Voilà. Ça c'est facile. Peut être dans un système qui est plus complexe.
[00:17:28] Dans lequel finalement euh bah ça s'est vraiment arrêté à un vrai défaut qu'on a pas bien maîtrisé et il va falloir qu'on trouve une façon d'adresser ce défaut-là et de l'adresser maintenant. Vous savez que le le coût du défaut entre celui qui est adressé maintenant et celui qui est adressé quand le client le voit, il augmente de façon très exponentielle. Donc on a tout intérêt à s'arrêter tout de suite.
[00:17:50] Donc on va parler de résolution de problèmes. Donc pour ceux qui sont un peu familiarisé avec le Lean, la résolution de problèmes, c'est quelque chose d'hyper normalisé, plan de du check Act. PDCA. Euh en tout cas, il va falloir le mettre en œuvre pour agréablement comprendre quelle est la cause de cet écart de qualité et qu'est-ce qu'il va falloir qu'on fasse pour s'en sortir. Avant de lancer le PDCA, la première chose qu'on fait, on va quand même essayer de faire ce qu'on appelle protéger le client, s'il y a quelque chose qu'on peut faire tout de suite pour remettre le système en marche, on va le faire. On n'est pas obligé de prendre en otage notre client, notre utilisateur sur nos problèmes de qualité. Enfin, il n'empêche qu'à un moment ou un autre, il faut essayer de comprendre qu'est-ce qui s'est passé. Il y a pas de magie, il y a il y a des algorithmes, il y a des tas de choses, mais il y a pas de magie dans l'informatique. Alors je vais vous donner un exemple. Celui-ci il est il est sympa. Je sais pas si vous connaissez le jeu des billes des billes de Deming. Ah. Deux, trois.
[00:18:46] un collègue d'un autre droit pour un histoire de
[00:18:02] pour arriver à comprendre quelle est la cause de cet écart de qualité et qu'est-ce qu'il va falloir qu'on fasse pour s'en sortir. Avant de lancer le PDCA, la première chose qu'on fait, on va quand même essayer de faire ce qu'on appelle protéger le client, s'il y a quelque chose qu'on peut faire tout de suite pour remettre le système en marche, on va le faire. On n'est pas obligé de prendre en otage notre client, notre utilisateur sur nos problèmes de qualité. Enfin, il n'empêche qu'à un moment ou un autre, il faut essayer de comprendre. Qu'est-ce qui s'est passé ? Il y a pas de magie, il y a il y a des algorithmes, il y a des tas de choses, mais il y a pas de magie dans l'informatique.
[00:18:33] Alors, je vais vous donner un exemple, celui-ci, il est il est sympa, je sais pas si vous connaissez le jeu des des billes de de Deming. Ah! 2, 3.
[00:18:44] d'un collègue d'un autre boîte pour l'histoire des billes de Deming
[00:18:50] Les gens Les billes de Deming. Et voilà, donc on a une espèce de boîte avec des billes blanches et des billes rouges et puis on a une une palette, vous voyez, la la la la plaque en bois avec des trous et quand on met la palette, en fait, bah dans chaque trou de la palette, on va mettre une bille et donc on va mettre des billes blanches et des billes rouges. Bon ben voilà, c'est ce qui s'est passé sur cette histoire d'obtenir un certificat. Le jeu de Deming continue beaucoup plus loin que ça. Mais dans cette histoire d'obtenir un certificat, en fait euh c'est c'est des gens qui ont besoin régulièrement d'obtenir des certificats, donc ils envoient leur demande et puis ils récupèrent le certificat, quand tout va bien, tout va bien. Et puis de temps en temps, ça se passe pas bien. Donc on leur a dit, on donne. Si vous récupérez pas le bon certificat, si vous n'arrivez pas à récupérer le certificat, on donne. Donc évidemment, ça marche pas. Alors la personne, c'est un système Lean, la personne qui vient, elle dit bah attends, je vais te montrer comment on fait et puis ça marche. Et lui, il a compris. Ça, ça a duré jusqu'à ce que la personne qui levait la main dise mais tu sais, je fais la même chose que toi, hein. Sauf que moi, ça marche pas. Donc c'est pas une question de geste parce que je t'assure, je fais la même chose que toi. Bah montre-moi, donc le type il fait, ça marche. Ah, tu vois, ça marche. Oui, mais 5 minutes après, on donne, ça marche pas. Et donc là, la résolution de problème les a amené à comprendre qu'en fait ils envoyaient leur requête sur un système qui ensuite il y avait deux deux serveurs, deux machines qui délivraient les les certificats et donc et puis c'était balancé entre les deux, hein. Donc parfois ça allait sur celui de gauche, parfois sur celui de droite. Quand ça allait à droite, on récupérait le certificat, quand ça allait à gauche, ça marchait pas. Parce qu'en fait, le serveur de gauche n'était pas mis à jour comme le serveur de droite. Voyez, donc c'est c'est c'est pas la lune, hein, mais en tout cas, sans ça un système d'Andon, on se retrouve face à un système extrêmement frustrant où parfois ça marche, parfois ça marche pas et on a aucune piste qui vous permet de savoir pourquoi ou pourquoi pas. Donc ça fait des journées qui sont un peu compliquées dans lequel on est en permanence un peu sur l'incertitude, est-ce que je vais y arriver ou non. Donc la qualité, ça permet d'avoir des journées quand même un peu plus zen.
[00:20:45] Alors là, je vais vous parler d'un autre exemple qui est lui est plus intégré, plus plus plus complet, hein, pas juste une anecdote. Donc on a travaillé avec une ESN qui avait notamment des équipes qui faisaient du testing pour je crois que c'était une mutuelle. Donc voilà, donc il y a toute cette équipe qui teste, qui teste, qui teste en permanence pour le compte de la mutuelle et euh vous savez quand on bosse dans une ESN, on n'est pas toujours absolument certain d'obtenir une satisfaction complète de ses clients sur les prestations qu'on délivre. Et là, euh là, c'était un peu tendu avec des menaces de rompre le contrat et d'aller voir quelqu'un d'autre. Donc euh qu'est-ce qu'on peut faire d'un point de vue ligne, on va regarder, on va regarder, on va lancer, on va essayer de comprendre ce qui se passe et notamment l'un des points, donc là c'est le PDCA, donc il est je sais qu'il est un peu petit, enfin pour vous c'est plus grand pour moi. Euh l'un des points qui était embêtant, c'est que les testeurs lançaient leur test et puis ensuite ils déclaraient des anomalies et une fois sur quatre, ils se trompaient dans leur déclaration d'anomalie. C'est-à-dire c'était pas des anomalies, c'était du logiciel qui fonctionnait tel qu'il était prévu fonctionner. Mais comme ils avaient déclaré l'anomalie, il y avait ensuite des tas de recherches de causes, euh c'était un indicateur, ce taux d'anomalie, c'était un indicateur qui euh qui rentrait dans les pénalités de notre SN et cetera. Enfin bref, tout ça, ça ça cassait vraiment les pieds à tout le monde. Donc euh ce sujet-là a été adressé sous forme de PDCA, il y a un PDCA relativement long. Donc la première chose qu'on fait, c'est qu'on va aller chercher les fausses anomalies, on va les regarder, on va essayer de comprendre ce que la raison pour laquelle elles sont là, et finalement, quand on essaie de comprendre, il y a quatre causes qui émergent. Donc euh vous voyez, je vous ai dit que je vous donnerai des des choses simples, hein. Là euh on on fait des croix, hein. C'est vraiment, c'est pas la lune, hein. Donc on fait notre Pareto et puis dans notre Pareto, la première chose, c'est une incompréhension fonctionnelle, c'est-à-dire que nos testeurs, finalement, ne savent pas comment le système doit répondre. Et ne le sachant pas, il déclare l'anomalie. Voilà. Mais il y a d'autres d'autres volets, il y a une mauvaise il y a une plusieurs versions de logiciel qui cohabitent et donc ils vont tester bah la mauvaise version. Ensuite, ils savent pas très bien qu'est-ce qui a déjà été détecté comme anomalie, donc ils vont redéclarer une anomalie sur du code qui a déjà été déclaré en anomalie. Et puis enfin, ils ont un navigateur web qui n'a pas été réinitialisé et donc ça ça va générer des des fausses alertes, des fausses déclarations d'anomalie. Donc ils ont des plans d'action pour chacune de ces quatre de ces quatre items. La mauvaise utilisation de de de de la version du logiciel, c'est un plan d'action assez classique. Les anomalies déjà connues, c'est un peu de communication entre tout le monde. Le navigateur web, on va le rentrer dans les standards de travail des des testeurs. Mais qu'est-ce qu'on va faire de l'incompréhension fonctionnelle? Et donc là, il se forme et c'est le premier Andon que vous voyez ici, il se forme à cette technique d'Andon. Donc vous avez en fait euh les testeurs qui savent que quand ils ont un doute sur anomalie, pas anomalie, il lève la main et il y a un expert de de de de ce de ce logiciel qui vient et qui les aide à prendre la bonne décision entre anomalie et non anomalie. Et il va le faire aussi souvent que nécessaire jusqu'à ce que la il y a une meilleure compréhension du fonctionnement du logiciel par les testeurs. Voilà. Moyennant quoi, ils arrivent à un système qui est beaucoup plus performant, c'est-à-dire que ils passent de 24 % de fausses anomalies à 4 %. Donc ça soulagement pour tout le monde, hein. Je veux dire c'est un soulagement pour le client, c'est un soulagement pour le développeur, c'est un soulagement pour pour le responsable de compte dans le SN en question. On arrive vraiment à calmer le jeu. Mais là, il décide de rentrer vraiment dans ces boucles d'amélioration continue, ils mettent un deuxième système d'Andon qui pour le coup est un peu différent. Et donc dans lequel quand l'Andon est tiré, soit parce que on détecte cette erreur de fausse anomalie, soit parce qu'on continue à avoir un doute, on va rentrer dans un système qui est de dojo. Vous êtes familier avec les notions de dojo? Alors le dojo dans les arts martiaux, ben c'est l'endroit où on s'entraîne à faire des arts martiaux. Euh ça marche pour les petits, les moyens, les grands, ça marche pour les ceintures blanches et les ceintures noires, c'est c'est vraiment l'endroit dans lequel on va s'entraîner et on va s'entraîner souvent avec un maître, en tout cas quand on a un certain niveau d'expertise. Et là le le le dojo line alors c'est l'endroit dans lequel on va pratiquer parce qu'en fait on estime en matière de ligne que apprendre dans la théorie, c'est quand même beaucoup moins performant que d'apprendre par la pratique. Donc en fait, on va binommer avec un expert sur un sujet précis, celui sur lequel on a tiré l'Andon et avec l'expert, on va mieux comprendre le système. Alors le temps dans le dojo, c'est entre 10 et 20 minutes, hein, c'est c'est c'est pas très long, mais on va mieux comprendre le système et puisqu'on va mieux comprendre le système, on va acquérir de la compétence et on va donc être être meilleur après sur son sur son environnement. Donc voilà. Donc on est quand même passé d'un d'un système de résolution de problème sur mes histoires de certificat qui était bon, il fallait le voir, il fallait le chercher, il fallait l'explorer, mais enfin c'était assez facile, à là quelque chose qui va finalement complètement changer les relations à l'intérieur de l'équipe, d'une part sur bah ce qu'elle doit réussir, c'est-à-dire arriver à détecter des anomalies mais des vrais. D'autre part, sur la façon dont elle s'y prend pour le faire et puis sur la façon dont elle peut continuer à monter en compétence. Parce que la compétence, c'est comme les yaourts, il y a une date de péremption. Voilà.
[00:26:02] Alors ça, je l'ai trouvé pour vous parce que pour venir faire cette conférence, j'ai pris le temps d'aller regarder ce qu'on disait dans London et j'ai trouvé que cette conférence était très bien. Donc euh allez-y hein, c'est Devops Enterprise Summit, ça se retrouve assez facilement en tapant Excel. Et donc il y a deux courbes, il y a une bleue et une rouge. Alors la bleue, c'est ce qu'ils appellent le cycle time et la rouge, c'est le nombre de fois où on tire l'Andon. Alors le cycle time dans le line, je vous ai dit qu'on voulait être à juste attendre, donc le temps c'est vachement important. Donc il y a le temps du client, c'est le lead time, je demande, j'obtiens. Ça peut n'avoir rien à voir avec le temps de fabrication, mais en tout cas, c'est le délai pour le client. Il y a le touch time, le temps où quelqu'un au sein de l'entreprise va travailler sur la demande du client. Quoi que ça veuille dire, une minute pour moi, 5 minutes pour lui, 4 minutes pour l'autre. Voilà. Et il y a le cycle time. Alors le cycle time, c'est le temps que je vais mettre moi pour ouvrir une un le process que je dois faire, aller jusqu'à la fin de ce processus et revenir au début du processus. Quand je forme des des gens qui connaissent pas grand-chose aux lignes et qui sont un peu jeunes, je leur amène chez McDo. Et en fait, chez McDo, je leur demande de regarder le cycle time du bonjour au bonjour. Parce qu'en fait, vous avez un certain temps pour servir le client. Chez McDo, c'est bien fait. Ils reviennent très vite au bonjour. Mais dans d'autres entreprises, vous avez un certain temps pour servir le client et ensuite vous allez faire autre chose et après vous revenez et vous reprenez cette activité pour le client. Et donc en fait, votre cycle time, il va tout intégrer, il va aussi intégrer le temps où on va aller chercher du papier à l'autre bout du bâtiment où on va rentrer dans une réunion et cetera et on va se rendre compte qu'en fait, une opération qui dure 10 minutes de touch time va durer 1h40 de cycle time. Et quand on essaie de voir le cycle time, il y a des fois, je vous assure on est très très étonné par ce qu'on trouve. Donc euh voilà. Donc le cycle time, donc ça veut dire que je prends quand je prends ma nuée c'est que à quel moment j'arrête, à quel moment elle est elle est terminée, je reviens au démarrage de la prochaine instruction. Voilà, c'est ça le cycle time. Donc euh ce qu'ils expliquent, ils l'ont ils l'ont vraiment suivi, c'est que moins ils tirent l'Andon, plus le cycle time est long.
[00:28:15] Et donc euh on avance au fil des semaines. Alors au début ils disent ouais, on tire l'Andon, bon, il se passe pas grand-chose. Donc finalement ils se démotivent un peu, ils le tirent moins et le cycle time monte comme ça. Donc ils disent non là, il faut tirer l'Andon, alors comme ils l'ont pas fait depuis un certain temps, ils trouvent, c'est la ligne rouge qui monte, ils trouvent, ils trouvent de quoi s'occuper. Et donc clac, le cycle time redescend. Et puis voilà, et à chaque fois qu'ils lâchent, ça remonte, à chaque fois qu'ils remettent, ça redescend. Donc euh il faudrait peut-être être plus régulier dans leur façon de tirer l'Andon, mais en tout cas euh en tout cas, c'est ce qui explique cette courbe là. Et ils expliquent en fait que l'une des raisons pour lesquelles on a du mal à tirer l'Andon, c'est qu'on le prend comme un élément euh d'évaluation négative personnelle. Si je tire l'Andon, c'est que je sais pas faire, c'est que je suis nul, c'est que c'est pas je suis pas bon, c'est que et cetera. Et donc en fait euh c'est pas du tout dans cet esprit là qu'il faut le faire. Il n'empêche et comme c'est ainsi qu'ils le vivent eux-mêmes, ils ont un peu de mal à le montrer. Chez Toyota, on dit que le vrai problème, c'est de ne pas avoir de problème. Donc en fait, ils vont être très attentifs aux gens qui ne tirent jamais l'Andon. Ils disent bah, s'ils le tirent pas, c'est que c'est qu'ils sont pas intéressés par la qualité. C'est juste ça ce que ça veut dire. Donc voilà, donc mais mais le système Toyota est souvent assez cache en terme de vocabulaire, hein. Donc on n'est pas obligé d'être ou peut-être que si, j'en sais rien, mais en tout cas, on peut on peut choisir des vocabulaires un peu plus faciles. Donc voilà, comment est-ce que on va arriver à se mettre en situation en tant qu'équipe de tirer l'Andon? Donc si on revient à mon système d'Andon, d'abord on dit stop, ce qui veut dire qu'on comprend euh le rythme et qu'on voit la non-qualité. On est capable d'avoir son analyse personnelle en se disant tiens euh euh c'est moi qui ai vu le problème de qualité ou alors c'est le système qui m'alerte sur un problème de qualité. Et on va se mettre en situation d'être capable de lever la main pour dire j'ai un problème, je voudrais de l'aide. Et là, je vous ai pris euh un sujet que que je suis moi assez régulièrement, ça c'est le projet Aristote euh de Google. Donc chez chez Google, ils se sont demandé quels étaient les critères qui faisaient qu'une équipe était performante. Et très rapidement, ils sont arrivés à la conclusion suivante, c'est que ce n'est pas le fait que les membres de l'équipe soient performants. Donc euh soyez tous individuellement super performants. Ceci étant dit, ce qui compte à l'intérieur d'une équipe, c'est un, la psychological safety. Est-ce que je suis est-ce que j'ai une sécurité psychologique au sein de mon équipe? Est-ce que je vais pouvoir expliquer que je rencontre une difficulté? Ça, c'est l'Andon, je lève la main en disant, j'ai besoin d'aide. Voilà, c'est le premier point. Et ils l'ont pas du tout fait parce qu'ils faisaient du line et cetera. Ils ont fait des grosses études à la Google en allant chercher de la data, en confirmant de la data, en recommençant et cetera. Donc en tout cas, l'Andon psychological safety. Le deuxième point, c'est la dependendability. Donc là, c'est le fait que on puisse se dire au sein de mon équipe, chacun d'entre nous est engagé à produire quelque chose de qualité. Et je trouve que ça a un lien direct aussi avec l'Andon parce que quand on tire l'Andon, c'est qu'on se dit, je veux produire quelque chose de qualité. Donc voilà, on est très clair. Ensuite, on est plus quelle est la structure dans laquelle je travaille, quels sont les processus, est-ce que tout ça c'est clair ? Ensuite, est-ce que mon travail a du sens et lequel et ensuite, est-ce que j'ai de l'impact et est-ce que je le connais ? Voilà. Donc ça c'est le projet Aristote. sur qu'est-ce qui fait qu'une équipe est une équipe qui déchire.
[00:31:35] Donc voilà, donc si on veut partir dans ces systèmes d'Andon, il faut vraiment être d'accord les uns avec les autres sur le fait que notre seul intérêt, notre seule motivation à mettre en place le système d'Andon, c'est de mieux réaliser ce qu'on doit réaliser.
[00:31:49] C'est de s'enlever des épines du pied qu'on aura toujours à un moment ou un autre parce que vont revenir les bugs que l'on va corriger, les incidents qui vont mobiliser tout le monde, qu'on en a vraiment plus envie et qu'on en a vraiment plus envie, on est d'accord pour dire là, moi j'ai pas compris comment est-ce qu'il faut que je fasse.
[00:32:13] Ensuite, très bien, on a levé la main. Donc comment est-ce que ça se passe ? Je vous ai donné quelques exemples. Euh mais sur la base de ces exemples, en fait, il y a finalement deux stratégies différentes, il y a l'aide ponctuelle. Ça je l'ai vu, je l'ai vraiment vu dans l'usine Toyota, il y a quelqu'un qui tire l'Andon, il y a un responsable d'équipe qui vient. Et puis euh c'est passionnant de voir des voitures se construire, c'est une carcasse qui avance à une certaine vitesse, la vitesse dépendante de la vitesse à laquelle nous achetons des voitures. Donc la la carcasse avance et puis euh les les gens sur une certaine distance au sol vont assembler dans la voiture ce qu'ils doivent assembler. Là les rétroviseurs, l'autre la batterie, le troisième, je sais pas quoi. Voilà, donc mais chacun à son tour va assembler ce qu'on doit assembler sur la voiture. Et donc le le type tire l'Andon, la lumière s'allume, il y a un responsable d'équipe qui vient. Donc la personne travaillait sur la gauche, le responsable d'équipe se met sur la droite et en fait, il va prendre en charge une partie du travail que devait faire cette personne, mais comme il avait un peu de retard, il pouvait pas le faire afin que quand on arrive au moment où on le donne à l'opérateur d'après, l'opérateur d'après récupère la voiture dans l'état qui était prévu pour pouvoir continuer lui à assembler avec sa part à lui ce qui doit être fait. Donc voilà, donc ça c'est une aide ponctuelle, c'est pas la peine d'en faire un enfin, il faut en faire un système, mais c'est pas la peine d'en faire une histoire hyper je sais pas quoi, enfin un cinéma, c'est c'est c'est assez facile à mettre en place. Le deuxième point donc, c'est la résolution de problème avec le PDCA. Donc le PDCA, c'est plus compliqué, c'est plus exigeant. Vous en faites vous des PDCA?
[00:33:43] Vous savez ce que c'est quand même?
[00:33:46] La résolution de problème.
[00:33:48] Ah, les rétrospectives.
[00:33:50] Non, c'est pas les rétrospectives.
[00:33:57] Le problème, c'est un écart de performance, ce qui veut dire déjà qu'on est d'accord sur sa performance. Ça c'est la définition du problème. Tant qu'on n'a pas d'écarts de performance, on a un souci. Voilà, on a un souci. Oh, je suis embêté, ça râle. Ouais, c'est un souci, c'est pas un écart de performance. Donc c'est un écart de performance qu'on va vouloir résoudre. Donc c'est veut dire qu'on est déjà un peu clair sur sa performance, ce qui est pas très simple, hein. Euh et qu'on va se dire bah franchement d'habitude je marque des buts et là j'en marque plus, donc ma performance est moins bonne. Et comme elle est moins bonne, je vais essayer de résoudre quelque chose. Voilà. Donc et ça se résout de façon scientifique, hein, c'est les cours de CM2 résoudre un problème, c'est d'abord comprendre la situation, aller chercher les causes et quand on a trouvé les causes, c'est agir sur les causes. Mais sur les causes, hein, pas sur ce qu'on a dans la tête et qui euh qu'on aime bien, vraiment sur les causes qu'on a été voir sur le terrain. Donc c'est scientifique, on agit sur les causes. Si en agissant le problème est résolu, c'est qu'on a trouvé une solution. Si en agissant le problème est pas résolu, c'est qu'on peut se dire que l'action ne fait pas partie des solutions et on recommence. Voilà. Donc c'est ça la résolution de problème et à la fin de la résolution de problème, on se dit bon bah très bien, qu'est-ce qui marche, qu'est-ce qui marche pas, qu'est-ce que je garde? Est-ce qu'il y a d'autres problèmes que je pourrais encore creuser. Donc voilà. Donc euh c'est ça la la résolution de problème. Alors la résolution de problème dans un monde lean elle se passe maintenant. Donc la rétrospective, attendre 15 jours pour essayer de se demander pourquoi est-ce qu'on n'a pas réussi à ouvrir un flux 15 jours avant. Ça va être du brainstorming, ça sera pas scientifique. Donc la résolution de problème, elle se passe maintenant sur les sujets qu'on a vu. Donc déjà le matin, se dire le matin, quels étaient les problèmes d'hier, c'est pas mal, mais c'est pas encore tout à fait réactif. Et l'Andon, c'est de se dire maintenant, je vois quelque chose et je veux m'y intéresser. Qu'est-ce qu'on a fait dans notre code qui empêchait notre batterie de test automatique de tourner?
[00:35:43] Globalement, il existe quatre origines au problème. On se décrit dans les 4 M. Donc les personnes, la méthode, les machines et le matériel. Euh quand je vous ai raconté le l'histoire des certificats, on était typiquement sur machine. La machine n'était pas à jour, n'étant pas à jour, elle renvoyait, enfin l'une d'eux n'étant pas à jour, ça renvoyait de façon un peu aléatoire des des des certificats ou pas de certificats. Donc ça, c'est un exemple. Euh quand on en est à réfléchir aux éléments de méthode et euh qu'on arrive à à rentrer dans les dojo, en fait, on est vraiment dans ce cycle là, c'est-à-dire que euh on se dit, on est sur un système que l'on maîtrise mal, on va essayer d'améliorer notre méthode jusqu'à bien comprendre comment elle fonctionne et on va réintégrer cette connaissance vers l'ensemble des collaborateurs. Celui qui a le plus appris c'est celui qui a exploré le sujet. Donc on apprend plus en explorant que en rentrant dans le dojo. Parce qu'on aura testé plusieurs hypothèses, lu des doc dans tous les sens jusqu'à comprendre ce qui ne marche pas et cetera. Celui qui est dans le dojo, on lui a déjà pré-package le savoir. Donc c'est complètement différent. C'est pour ça qu'en ligne, on dit que on est que des coachs parce qu'en fait c'est celui qui trouve la solution qui apprend et l'objectif du coach en ligne, c'est pas d'apprendre lui, c'est de laisser le savoir à la personne qui est en face. Donc voilà. Donc on est vraiment euh dans du craftmanship. On va moi j'ai travaillé euh enfin mes équipes travaillent depuis 5 ans avec une ESN hyper innovante, extrêmement smart et cetera. Euh maintenant leurs user story, elles font 2 heures. Point barre. Tout le temps. Ils ont une croissance comme ça et une qualité parfaite, hein. Donc euh voilà, quelque chose qui savait pas du tout faire il y a 5 ans. Il y a pas de limite à ce que l'on est capable d'apprendre sur le métier qui est le nôtre.
[00:37:34] Alors un exemple de d'expertise que j'aime bien, c'est stack overflow. Donc euh stack overflow, ça ça vous parle quand même plus. Donc on peut poser des questions et puis vous avez des gens qui vous répondent, mais des questions très techniques sur des développements logiciels. Vous avez des gens qui vous répondent. La première réponse validée apporte à son personne qui a répondu des points, c'est comme dans un jeu vidéo. Et donc au bout d'un certain nombre de points, on a des badges et au bout d'un certain nombre de badges, on devient des super-héros. Voilà, donc c'est un système dans laquelle à la fois vous avez la possibilité euh d'une certaine façon, tirer un London, hein, vous savez pas faire, clac clac clac sur stack overflow jusqu'à ce que vous obteniez le système d'aide. Donc voilà, donc ça c'est votre London de votre côté à vous. Et de l'autre côté, ce sont des gens qui valorisent leur expertise parce que bah ils sont capables de répondre à des questions compliquées qui viennent du monde entier. Voilà, donc ça c'est un exemple de système d'aide euh très ouvert qui travaille sur une communauté. Moi je l'ai vu mettre en place de façon très artisanale au sein d'équipes de 60 personnes dans lesquelles les les gens se trouvaient confrontés à des situations qu'ils connaissaient mal et donc ils ouvraient une question et il y avait des gens qui répondaient à la question. Alors les systèmes de badge et cetera au sein de l'entreprise, ils l'avaient pas mis en place, mais c'était vraiment ce système-là. Et tout ce qui pouvait être répondu localement, c'était un vrai bénéfice. Parfois les les collègues pouvaient pas répondre et donc il y avait des experts qui étaient là qui pouvaient répondre et parfois les collègues et les experts ne pouvaient pas et il fallait remonter, c'est remonté comme ça un jour juste que chez IBM en Amérique. Voyez, sur des sujets qui sont de plus en plus précis et de plus en plus pointus. Les gens qui rentrent dans ce système là sont des gens dont la compétence évolue énormément. Mais pas une compétence théorique parce qu'on a lu des livres, passé un QCM et obtenu une certification, mais de la compétence par la pratique parce qu'on se confronte à des situations qui sont de plus en plus compliquées et qu'on est incapable d'y répondre. Donc ça c'est à titre personnel. L'autre bénéfice du système d'Andon, c'est qu'on vous intégrez des gens euh qui euh que vous avez à fort turnover. Ce qui n'arrive pas dans le métier de l'informatique, c'est certain. Donc euh quand vous avez un fort turnover, les gens arrivent avec des compétences un peu techniques, ils vous disent je connais ça, je connais ça, je connais ça, je connais ça, ils connaissent pas du tout votre système, hein. Le nommage de vos bases de données, la façon de rien, ils connaissent rien à tout ça. Donc en fait, vous allez leur demander de faire des choses sur lesquelles ils vont avoir une forme de compétence technique et une incapacité à travailler. Donc s'il lève la main régulièrement en disant là-dessus, je comprends pas ce qu'il faut que je fasse, vous aurez une montée en en compétence qui va être beaucoup plus rapide que si vous leur dites allez, je te lâche comme le chat dans la piscine, on verra bien si tu apprends à nager. Voilà. Donc le système d'Andon. Voilà un peu près ce que je voulais vous dire là-dessus.
[00:40:11] Le point clé, c'est de réfléchir en flux et vraiment en flux, en flux de problème. Donc comment est-ce que mon flux d'activité me génère un flux de problème que je vais résoudre jusqu'à ce que notre qualité de service, la qualité des produits que l'on livre, soit absolument impeccable. Et donc on sort effectivement, je suis désolé de la notion de rétrospective parce que la rétrospective, c'est un batch et c'est trop loin pour arriver à comprendre quelle est la cause de de des problèmes de qualité.
[00:40:42] Voilà ce que je voulais vous raconter aujourd'hui.
[00:40:45] Merci.

Transcription