Marie-Pia Ignace - Gemba

[00:00:06] So we're going to talk about Gemba today. So I wrote it like this, with an M. Know that it's also spelled with an N. I've sometimes had an impassioned lesson on the difference between Gemba and Genchi Genbutsu. So we're going to say that it will be written very well like that. That we're not here for an expert debate and that we're just going to try to understand what Gemba is. So I intervene on April 1st or 2nd, but yesterday I almost put my foot in LinkedIn. And so here's what I found, Boss, everything is going very well. Cool. Just real life. The apps work, projects are progressing, the cloud is top-notch. Thanks to infra. The hackers are repelled, budgets are respected, what a relief. Users are even satisfied. In short, I'm kidding. And so in fact, that's the question of Gemba, it's about knowing what the difference is between myth and reality, and if we want to improve, what reality are we talking about? And so Gemba is the eruption of reality into the imaginary. The imaginary that processes work, the imaginary that all the people we onboard within a team will immediately, by the magic of the certifications they have, the training they have, the support they will benefit from, immediately, they will be super efficient. Imagine that the requirements expression, the user story will be absolutely top and that we will therefore be able to work easily. Well no, all of that is imaginary. And the real question of continuous improvement is where we detach from the imaginary, where are the problems we need to deal with, and how can we find them. And the best way to find them is Gemba. So we're going to talk about the Gemba line, continuous improvement. We're going to start with a Gemba, so it wasn't that team, it was another one, but it's not a big deal. And so one day I go into a big CAC 40 company, which is a large European company, proud of what it is, proud of its results, proud of its technology. And so the boss who takes me tells me, listen, we've talked about Gemba for a very long time, you told me it could be interesting, I'll come and do one with you. OK, super. Where are we going? We're going to my CRM team, so it works for all the business lines of the company. Which is a distribution company, so there are points of sale, it works for all the company's businesses and it does on-demand CRM for various people and especially a lot of marketing. OK, great. So, we arrive in a large room, there are lots of developers and I tell him, but ultimately, uh, I understand this company's business, but what do you expect from it, what's the next step, what's your North Star? He tells me it's not very complicated, actually, today we do a lot of CRM queries, we have more and more data. We're going to need to put more and more intelligence on this data, I would like my CRM team tomorrow to be a cutting-edge team for the company, that we can count on them both to process the data and to extract intelligence from it. For now, it's still relatively basic. I tell him great, and it's going to go well. And it's going to go well. He has two doubts, he has a doubt about whether the team members will be able to acquire these new skills. Very good, nice managerial doubt. And then a second doubt, a bit more diffuse, saying in fact it's really what I want to do, but I see the businesses, they start working with external companies, they just ask us for data, they don't ask us to do anything more, and why don't they go through them?
[00:03:39] OK, let's go see on the ground. So we arrive and the first thing we are entitled to, as we are entitled to it every time, and we're still not on the Gemba, we are entitled to the manager who stands up. With a full assembly and who says, listen, it's very simple, I'm going to explain the process to you. The idea of Gemba is to go see people working, it's not to go see the manager who explains the process to you, the one where everything goes well. So the process, well, you have it there. Nothing groundbreaking, nothing scary either. A request comes from the business, how much it weighs, how much it will cost. Go no go, are we going to arbitrate it because many requests are coming in. And then OK, now I have the go. So very well, we will put it, we will entrust it to someone who will develop it. Finally the person will carry out the development, do the necessary tests, present to the business the nature of the result and then deploy all of that. Does that speak to you, do I need to go into detail, is it very exotic, super innovative? It's just real life. Still no Gemba, the manager well-positioned, everyone standing around him. I say well, very good, but what I would like, and that is really a Gemba gesture. What I would like is to see the last one that came out. The advantage of saying the last one. It's really huge, we say, well, the penultimate one a bit smaller because we don't want to understand all the complexities of the system. We're already going to start getting into it a bit. But the advantage of the last one is that there's no bias, I don't know them, I don't know which is the last one, and it allows for reflection. So there you go, they've planned everything etcetera. And so life will follow, because there are tickets. We manage to follow all of this in the workflow, so the request is in May, the load is in May. We go before the committee to get a go, still in May. Uh, we plan it saying since it's May, we'll plan it for June, and then in fact when we look at the actualization, well, it wasn't June, it was even September, it was October. We see several replannings. And so the business presentation, there we still manage to submit it just after the realization and the production launch, it will be in November. So we are still a bit late. Just real life.
[00:05:43] What happened is that it was actually in June. But the person to whom it was entrusted was a bit late in processing the requests assigned to her. So she didn't manage to include it in her June backlog, so she postponed it, she postponed it to when she was going on vacation. We say it's not a big deal, one day she'll come back from vacation. She'll come back from vacation, she was a lady. One day she'll come back from vacation and that day we'll give it to her, yeah but August wasn't a very good time so we put it in September instead. And then in September, there was still a bit of backlog, two or three things to correct, a bit of tension at the start of the school year, it arrived early October, and there you go. And there you go. Real life.
[00:06:19] And that's the first thing we see. When we say show me the last piece, when we look at the delay since creation, not since it entered the backlog, really since creation, since the moment the client requested it. We say ah, still.
[00:06:34] Still, we might have avenues for improvement if tomorrow we want to be the team that goes from CRM to Big Data for its company, uh, we're going to have to be a little bit more reactive because otherwise there are a lot of external providers. who would be delighted to do the same job, but by being more time to market. Second point of the Gemba, OK, we understood everything, we're going to try to go a little bit further. And so there is this lady who developed everything and we tell her, we manage to ask to go see this lady to finally see how she receives the request and what is the nature of the interventions she makes on this request to be able to answer the business question. You remember the super structured process and so on. And so we're going to see her and the second thing, the second important question is, but ultimately, what needed to be released? Because you are all in your digital world manipulating concepts, and at some point you have to be able to look at it and say, what does it do? Is it a lot of energy, not a lot of energy, a real revolution, a small evolution, and you have to look at the object to form an opinion. And there the object was, we have all our points of sale. For this request, and we wish to integrate our two remote customer relationship centers into it. We had to add 25 characters, the two remote relationship centers each had a codification, we had to add 25 characters to an existing request. Okay? So we went from a super structured process to a process in which we incurred months of delay to finally output 25 characters. When I'm a bit challenging, I say 25 characters over the duration of what we did. That would mean that the lady, if she had worked at the pace, you who come to Flocon, you know what the pace is, it's working at the customer's speed. If she had worked at takt time, no, sorry, if she had smoothed her work over time, she would have typed one character every two weeks to have a smoothed work pace over the period she had to accomplish everything. When you ask an assistant who does typing, she's more like 5 characters per minute. So there you go, 25 characters to add, 6 months delay. It's still impressive what we see in the Gemba. And so ultimately, what do we see? Well, we see that with processes that are absolutely perfect, we find ourselves in situations where we are several months behind schedule. And what we also see is that, in fact, we are still a bit surprised by all the upstream work it represents just to tell Emily, type the 25 characters. Is it really, really worth it to type 25 characters, to do an estimation that would probably take more than a minute? To integrate this estimation into a document that was going to be presented to a committee, which itself was also going to last more than a minute. Then sending it to planning, can you imagine, you have to find people in IT who plan one minute of work for you. The level of trust we have in employees. The level of organization of mastery and control we want to have. But I'm not sure that at Taylor and Ford, we were so much on people's backs. And so afterwards, she does her minute of work. And so when we then debrief with the boss, we can debrief whatever we want because this relationship is a bit complicated, I am what is called a Sensei, meaning I've been doing Lean for an extremely long time. I am precise, I am competent, I see many things, I see clearly that in front of me, I need to adapt my feedback so that people can hear it. Because already there's a bit of shame in having seen that, bosses are not always very comfortable when they see that. And then, they need to be able to tell them to find an improvement action.
[00:10:18] If we tell them their whole system is messed up, some can hear it but not all, far from it. So there you go, we debrief and we ask ourselves, what did we see, what did Gemba bring us? So you've seen, several Gemba actions. The first, what do you want to achieve? And relative to what you want to achieve, does what you've seen allow you to be credible, or are there actions you need to work on? Second Gemba action, not to be interested in the manager's life and opinion. You have teams working and these teams are competent, expert, they do that all day long, no need for a manager to speak for them. So go see the people who work. The third point, ask to look at the last piece. And the fourth point, ask to look at the nature of the work to do it. There you go, and from that, we can start thinking about improvements.
[00:11:15] I do that with my phone, it works well, it works well. Oh darn.
[00:11:22] So.
[00:11:25] There you go. So let's go back a little. What is Gemba? Gemba is a practice that is absolutely embedded within Lean. It's the first practice we must acquire when we are a Lean manager, it's to go to the real place.
[00:11:44] One of the most known experiences, one of the most known stories in terms of Lean management, is Porsche, which wasn't doing very well, today it's a company that makes a lot of money, but that wasn't always the case. who brings a Sensei from Toyota and the Sensei from Toyota refuses to enter Porsche's headquarters. He says no, but wait, I didn't make this whole trip to go into offices. So Porsche's headquarters agrees to go to the factory and there he will start doing his Gemba. So go to the real place. And then we talk about Gemba walk, about going to walk on the ground. So what are we going to do in this Gemba walk? The first thing is that we're going to observe the work ourselves. So the idea is that it's not someone else telling me a story, it's me who's going to look. I know the domain well, I know the domain less well, but what will I be able to understand about our organization, our processes, our customers when I go inside a team and make observations. So by oneself, we look at the real pieces, I ask to look at the last one that came out. Not the hyper theoretical piece of the business asking me blah blah blah, I really ask to have a real one. And then with the real people, meaning not the managers, but the people who work, and it's them who will show me the real processes, the real tools, the real difficulties. That's the first thing. The second thing we're going to do in the Gemba, we're going to try to understand. So we have two brains in the Gemba, we have one that observes and is very attentive to observation, to how to ask questions, to how to say show me, and so on. And then another one that thinks by saying, but actually I wanted to go somewhere, and in what I'm currently seeing, are we going there? So this link between what we call the North Star, what we want to achieve, and what we see on the ground. And finally, the interesting point about the Gemba is the exit point, meaning we're going to agree on that it's here and there that we'd like to improve something. Because it's not just to please ourselves, to have spent a good morning with people and to be able to say to ourselves, hey, last week I was here and next week I'll be there, it's really about seeking a consensus on the topics on which we say, well, it would be worth working on and improving. And so we begin the path of improvement. So, I promised you five types of Gemba. So the first type is already to go look at what comes out. That's what I told you. What's the last piece released, what are the last three, what are the last 10? Uh, three is already pretty good. Three is a real opinion on what's happening. And the nature of this piece. Did it seem easy, did it seem complicated? Go do a Gemba on flow openings, I can tell you it's mind-blowing. The provision of environments, we say to ourselves, but what is the last environment? What? The dev team, did they ask for that environment, that far in the past? And when it needs a test environment, it will be the same, we will again give it delays before reaching it. Go look at the end of a sprint, what comes out? I can assure you that I did this with a whole aeropage of co-directors of IT departments etc., they were there, I asked what came out in the last sprint? User Stories that were reported to the next sprint because they were not finished. Accident corrections because there were User Stories that were released and had generated incidents. Things that hadn't been requested in the sprint, very low value creation. And the team was just unhappy because it was a competent team, ready to fight, and its backlog wasn't much, and its working means weren't what it expected. So there you go, look at the latest pieces, look at the lead times between when a request is made and when something is obtained. Look at the places that create value because I showed you earlier, there are probably a lot of things we do that are just bureaucracy. So if we were to do a real Lean course, I would train you on the seven wastes, on how to see them. But in any case, just with your own expertise, you will be able to see a lot of things. And then look at the back and forth within the process. Because if everything was going well, we would be in a flow where we would take something, realize it, distribute it, and wouldn't talk about it anymore. We wouldn't be saying, I took something, data is missing, I need to go back. I get to my test part, it goes wrong, I need to go back and so on. All the back and forth. Then the principle of Gemba is that we have no qualms, it's not a value judgment, it's nothing, it's just that this piece, it came back. And since it came back, it means something happened. It means that in the specification I received, there's something I didn't quite understand. But and it's not and and it's not me, I mean, I received that, I understood it like that, I did it like that. What prevents me from being able to send them? Is it me, is it my product culture, my knowledge of the domain I work in that is at stake? Is it my product culture, my knowledge of the field I work in that is in question? Is it in the specification itself that it actually generated a form of uncertainty in me? Is there confusion in the data names? Is it etcetera? It's never personal. The idea is always to find where we want to launch the improvement.
[00:16:50] There you go, so the Gemba on what comes out. And ultimately, what was the life of this object that came out somewhere? The second approach, I put it on working conditions. So not in the sense of quality of life and working conditions, but really in the sense of, I just started working, do I have the means to work well?
[00:17:11] Do I know what I have to do today? I think we've regressed a lot with Covid. Before there were still large boards where we saw the pieces, we saw them moving, it was progressing, we knew who was doing what. Uh, not all teams have always managed to recreate that on digital. And we find ourselves with people who say, oh well, I'm going to open my Jira and then they take something. But that's not a product strategy, is it? But well, at some point we kind of lost sight of all that. So do I know what I have to do, do I know what's a priority, do I know where I am? Is it easy to identify the right activity? People who wander around a workflow and randomly pick say, oh, I'll take that one. Exciting, huh. Then, we're going to look at how we take that object and transform it, and we create value, value creation, value repair, because it's the first time we're trying to do it. If so, we are more in value creation than in value repair. Will someone use it somewhere? Sometimes you have to show a bit of imagination to imagine that it will be useful to someone, but why not? And so that, we can look at it. So we observe it, we measure it. There you go.
[00:18:22] And then at some point the person will tell you, well, that's it, I'm done, I'm going to take another piece in my workflow. A small incident, for example. Question, but the one who just worked, is it finished or not finished? Again Flocon, limit the work in progress, huh. All the things I start and don't finish. And why don't I finish it? Because I don't have access to my test environment, because the test suite isn't available, because there's something a bit vague and someone would need to come help me, and so on. But there's no inevitability to that. On the other hand, if we see it, if we stop at it, if we tell ourselves, hey, that's my next challenge, it has value. It allows us to find very concrete avenues for improvement.
[00:19:06] There you go. So that, that's the Gemba on working conditions which will allow one to say, well, ultimately, I took good people. I dropped them into a team, do they have the means to work? Do they have the means to do something well every day? Do they have the means to thrive in their profession? And so we're going to see a lot of things. So I'm talking to you about a Gemba where the manager comes and looks, but it's also an exercise that we can uh do on ourselves, to self-observe. To tell oneself, I spent 2 hours trying to fight against the system. It's still not exciting, nothing has progressed, I don't see which customer I served, I don't see what benefit the company found in these 2 hours of work I just invested. In any case, I didn't enjoy it. So that can be part of my Gemba and my personal improvement plan. There you go. We can do it in different ways. Third type of Gemba.
[00:20:03] No, sorry. I wanted to put. An alert. Gemba is seeing, and seeing is not chitchatting. Blah blah blah blah blah blah. So I'll explain, it's summer, people are on vacation, so there's a lack of staff, so that extends deadlines, and then moreover, blah blah blah and blah blah blah and blah blah blah. I'm on April 2nd, you know. What will happen next summer, I'm willing to anticipate it, but first let's look at what's happening on April 2nd, and next summer we'll see. That doesn't mean we shouldn't anticipate summer, it just means that if we could already improve daily. Today, on what we do, it's really good. And so every time we say, yeah but you understand, if we're sending dollars to Cuba, it's still complicated because, well, there are embargoes. Yeah okay, but the last time we sent dollars to Cuba was 34 months ago, I'd rather know why we have difficulties today issuing our clients' payment to their supplier in Turkey, China, anywhere. There you go. So try to get out of "I'm telling you a story, usually it's not like that, besides there's a more complex case" and say great, but me, I'm not going to spend infinite time doing Gemba at your place. Your job is full of expertise, it's not in the hour and a half we'll spend together that I'll be able to understand all its subtleties. Can we go back to this case, which is an easy case, and as long as I haven't understood it, there's no point in going further. Ah mais tu comprends, alors si jamais c'est des dollars qu'on envoie à Cuba, c'est quand même compliqué parce que bon, il y a des embargos. Oui d'accord, mais la dernière fois qu'on a envoyé des dollars à Cuba, c'était il y a 34 mois. J'aimerais mieux savoir pourquoi est-ce qu'on a des difficultés aujourd'hui à émettre le règlement de nos clients vers son fournisseur en Turquie, en Chine, n'importe où. Voilà. Donc essayez de sortir de je vous raconte une histoire. D'habitude, c'est pas comme ça. D'ailleurs, il y a un cas qui est plus complexe de dire super, mais moi, je vais pas passer à ton faire le gemba chez vous.
[00:21:13] Votre métier est plein d'expertise, c'est pas dans l'heure et demie qu'on va passer ensemble que je vais être capable d'en comprendre toute la finesse. Est-ce qu'on peut revenir sur ce cas-là qui est un cas facile? Et tant que je ne l'ai pas compris, c'est pas la peine de les plus loin.
[00:21:31] Troisième Gemba. Le Gemba dans le produit. Ouvrir le capot et lancer le débat d'experts. Moi, je suis pas une experte, donc c'est pas moi qui lance le débat. Par contre, je peux dire, on va ouvrir le capot. Là, il y a un 7 m de long d'imprimer. C'est une équipe qui fait, qui récupère de la data, qui la nettoie, qui ensuite la donne à une équipe qui va générer du code, qui elle-même va générer de la BIA pour des gens qui ont envie de savoir ce qui se passe à l'intérieur de leur supply chain. Super. Ça se passe pas bien. Ils le savent. Je veux dire, les demandeurs se roulent de colère dans les comités en disant je demande des infos, je les ai pas, c'est lent, quand ça arrive, c'est pas toujours ce que je veux, ça marche pas. Quand vous mettez en prod, ça plante, et cetera. Et donc en recherchant, en fait, ce qu'ils ont compris, c'est que l'équipe data, elle fait vraiment de la data, mais que sur le code, c'est pas obligatoirement sur cœur de métier. Et donc il se disent les les les codeurs disent les dev vont dire aux gens de la data, écoutez, on va regarder sur deux équipes différentes, on va regarder ensemble votre code. Et on va essayer de savoir en ouvrant le capot, s'il y a des endroits sur lesquels on peut peut-être sécuriser, donner un peu de robustesse à l'ensemble. Et ils en impriment sept pages de long. Enfin, c'est moi qui imprime parce que j'ai une imprimante à zéro. Donc au début on dit on la met sur le mur, mais enfin ça marche pas, on la met par terre et cetera. Et donc avec un tech lead, ils vont regarder les les les 7000 lignes de code et ils vont se dire ah ouais, il y a une seule fonction à l'intérieur des 7000 lignes de code. Donc quand on fait un changement, ça impacte la totalité du système. Et donc ils vont travailler avec l'équipe data pour qu'ils arrivent à reséparer les différentes activités à l'intérieur de leur code et à générer de la robustesse là-dedans. Donc, aller faire du Gemba dans le produit, c'est toujours très intéressant. Pourquoi est-ce que mes temps de réponse sont pas bons? Ah ouais, à chaque fois que j'envoie une requête, j'emmène tout l'environnement du client alors qu'en fait, j'ai besoin de cinq data sur le client. Bon ben voilà, aller regarder. Il n'y a pas de fatalité. Mais ça, je pense que vous le savez parce que vous êtes, enfin, vous savez tout ce que c'est que le refactoring et donc c'est la dette technique et cetera. Donc je pense que c'est bon. Alors.
[00:23:33] Ce Gemba là, moi, c'est un Gemba que j'adore.
[00:23:38] C'est un Gemba que personne dans la tech ne fait jamais. Mais si il y a un PO, c'est lui qui me parle du client, blablablablabla.
[00:23:48] Je travaillais chez SARANZA. Vous voyez ce que c'est SARANZA, les chaussures. La DG, 80 personnes de la DSI en face d'elle. Et elle pose la question que je lui avais soufflé. Elle regarde ses développeurs, elle regarde les gens de la DSI, elle les regarde tous dans les yeux. Et elle leur dit, qui a déjà acheté des chaussures chez SARANZA?
[00:24:09] À votre avis? Zéro.
[00:24:16] Donc, il y a des problèmes business, il y a de la concurrence, il y a des des temps de réponse sur le site, vous savez quand on fait du e-commerce, il faut aller très vite à mettre quelque chose dans le panier, très vite à faire le paiement, sinon les gens abandonnent. Donc, il y a un certain nombre de difficultés qui sont identifiées et cetera, des petits problèmes d'ergonomie, un certain nombre de trucs. C'est pas le drame, hein, je veux dire, SARANZA vend des chaussures tous les jours, mais euh dans un monde qui est un monde difficile avec une concurrence qui est permanente, ils ont intérêt à être un cran plus haut.
[00:24:41] Il n'y a pas un dev qui s'est dit je vais acheter une paire de chaussures. Il leur dit mais vous savez, pendant 6 mois, vous pouvez les rendre gratuitement.
[00:24:48] On vous on vous rembourse immédiatement. Donc, prenez n'importe quelle paire de chaussures, mettez-les dans le panier, mettez votre carte bancaire, faites la réception de la paire de chaussures, renvoyez-la, comme ça vous aurez fait à peu près tout le cycle.
[00:25:01] Et vous verrez.
[00:25:04] Je travaillais avec des gens qui euh sont sur des hypermarchés, et dans l'hypermarché, bah il y a l'endroit où on peut acheter son lave-vaisselle, sa télé et cetera, les produits blancs, les produits bruns, donc c'est une vente un peu particulière, hein, c'est pas la même chose que d'acheter du Coca-Cola.
[00:25:17] Et donc une super appli pour les vendeurs qui permet au vendeurs de prendre la commande du client, de prendre son adresse, de lui proposer la garantie supplémentaire, de ci, de ça et cetera. Je leur dis mais vous avez été en boutique, dans l'hyper et vous avez essayé d'acheter mais n'importe quoi juste pour voir si ça marche? Juste pour voir si l'appli elle est fluide, si le vendeur il la met pas comme ça, comme ça. On essaie de trouver de quelle façon ne pas avoir un écran dessus. Vous connaissez le scandale de SNCF Connect? Je veux dire c'est sorti, papa maman ne pouvait plus prendre un billet ensemble. Il fallait que papa prenne un billet, maman prenne un billet et peut-être qu'ils seraient dans le même train, ça c'était à choisir, mais peut-être qu'ils seraient dans le même demi-train et peut-être qu'ils seraient même dans la même voiture et peut-être qu'ils seraient à côté. Il y avait quand même beaucoup de peut-être, hein. Tout tout tout avait été perdu dans la SNCF Connect. Par contre, on pouvait réserver une trottinette à tour, ça, il y a pas de problème, hein. Ça fait un scandale. On leur a dit mais quand même vous l'avez utilisé.
[00:26:15] Ah bon, on l'a fait tester par des cheminoux. Ouais, ben le cheminot c'est pas papa maman, les deux enfants, c'est pas la personne qui va voyager qui a un rendez-vous d'affaires de l'autre côté. Oui. Et les gens disaient mais mon mari l'a pris, il fallait qu'il aille à Nantes. Alors euh il tape Nantes.
[00:26:31] On lui dit vous cherchez la place de Nantes à Paris? Bah non, il fallait qu'il il avait tapé Paris, Nantes et on lui a dit est-ce que vous cherchez la place de Nantes à Paris ou la place de Paris à Nantes? Bah il pensait sur une application de train qu'on allait lui proposer des billets pour aller de Paris à Nantes. Mais rien rien rien. Donc, essayer de comprendre vos clients. Essayer de comprendre la valeur, c'est pas parce que vous êtes quelque part loin dans l'organisation et loin du client que vous n'avez pas accès à ce que ça donne. J'ai vu des équipes qui travaillaient pour du contrôle de gestion et le contrôle de gestion râler en disant c'est long, c'est difficile, on a du mal à se connecter et l'équipe qui disait ouais, c'est de la conduite du changement, ils savent pas trop et cetera. Essayer de faire la requête du contrôle de gestion, essayer de faire leur requête. Et puis on tape, et puis on attend, puis ça charge. Alors on retape et puis ça charge et puis ça plante. Alors on se relogue. Ah bah là tout à coup, vous avez des équipes de dev qui se disent effectivement, ils ont peut-être pas tort de dire que c'est pas top. Voilà. Donc comment est-ce que vous pouvez le faire? Alors il y a plusieurs techniques, hein. Il y a une technique, c'est vie ma vie, hein, j'achète un billet de train si vous êtes à la SNCF, des chaussures si vous êtes chez Saranza. Allez voir sur les réseaux sociaux dès que vous êtes sur quelque chose qui qui est grand public, vous pouvez le faire, hein, si vous vouliez demain organiser, être je sais pas, un acteur du e-commerce, vous auriez tout tous les retours possibles et pas uniquement sur le produit, mais aussi sur le bon Dieu, mais comment j'utilise ma carte de fidélité.
[00:27:54] Comment je vais dans le magasin et je regarde la borne, vous savez quand on il faut qu'on paye soi-même là, je fais mon bip moi-même sur la borne et comment je vois où sont les difficultés des utilisateurs. C'est pas la lune, hein, c'est pas parce qu'on fait de l'informatique qu'on a pas le droit de comprendre ça. On a aussi une vie dans laquelle on est juste des personnes qui allons dans des supermarchés. Donc le vie ma vie, c'est important. Le vie ma vie, ça se peut se traduire notamment par quelque chose qui s'appelle Follow me home. Donc moi, je vous invite à vous souvenir de de ça Follow me home, Ten Thousand Horse program et c'est fait par Intuit. Vous tapez ça sur internet, vous avez des choses qui sont fabuleuses. Donc Intuit, c'est une boîte qui c'est un c'est un éditeur de logiciel qui fait un peu plus de 6 milliards de dollars de chiffre d'affaires. Donc c'est respectable, c'est plus la petite start-up, c'est plus la grosse scale-up, c'est la belle boîte.
[00:28:40] Et donc Intuit, ça existe depuis 1975, donc aussi un petit peu d'antériorité. Et ils ont ce programme en permanence d'aller voir et comme le dit le patron, si don't talk. C'est un peu mieux élevé que aller voir et ne pas voter pas. Mais c'est vraiment l'esprit. Donc, regardez si le sujet vous intéresse, il va vous expliquer ça. Après, il y a d'autres techniques, on peut il y a un certain nombre de techniques pour le faire, mais essayer de comprendre la valeur créée par le client. Parce que quand je vois des équipes informatiques qui me disent en fait, on aimerait planifier par la valeur et des équipes qui n'ont jamais travaillé que sur des personas qui ne représentent rien pour elles. Je me dis la planification par la valeur, bonne chance.
[00:29:25] Et on peut peut-être en arriver d'ailleurs à un point du Gemba qui est comment est-ce qu'on interagit avec les gens.
[00:29:33] Donc je vous en parlerai, il y a vraiment des notions de respect des personnes, il y a des notions de de de de de s'attaquer au processus et jamais aux gens et cetera, il n'empêche qu'à certains moments, on est tellement effaré par ce qu'on voit.
[00:29:47] Qu'est-ce qu'on fait? Non mais c'est vrai, il faut trouver la bonne attitude. Alors moi j'essaie d'être souriante, mais ça marche pour le premier Gemba. Le deuxième au centième, enfin au centième, on n'y arrive jamais au centième, mais au nième quand ils disent mais tu es encore en train de sourire alors qu'on voit encore des trucs horribles, ça les agace. J'essaie d'être souriante, je connais des gens qui par principe font la gueule.
[00:30:09] Par principe font la gueule en disant de toute façon, on voit des choses qui sont tellement dures pour les gens en face, parce que on le voit quand même, on voit que le roi est nu.
[00:30:17] On voit des choses qui sont tellement dures pour les gens en face qu'il faut leur montrer qu'on qu'on a une forme d'empathie par rapport à ça. Alors que moi j'essaie d'être souriante pour arriver à déminer le truc, j'avoue que je ne sais pas exactement ce qu'il faut faire pour peut-être des gens avec lesquels on travaille. Mais mais voilà, comment est-ce qu'on essaie de ne pas se mettre en colère, comment est-ce qu'on essaie de ne pas se projeter en colère sur les personnes d'en face? J'ai vu un patron, je l'ai vu devenir rouge écarlate. Mais vraiment. Et je l'avais prévenu avant, je lui dis écoute, il faudrait que tu sois poker face. Des patrons de plus de 1000 personnes, hein, donc il avait fait une belle carrière, il savait faire énormément de choses dans son organisation, je dis poker face. Vous voyez, il avait vraiment du mal à respirer.
[00:30:59] Donc quelques trucs que je vous laisse là parce que comme ça c'est assez concret. Il n'y a que le terrain qui dit vrai, donc les gens peuvent vous raconter que les délais sont bons si jamais le terrain vous montre que c'est pas ça. Euh il y a aussi un grand jeu, donc je dois le livrer là, on est le 2 avril, je dois le livrer le 10. Le 10 avril, ouais, mais je suis pas tout à fait prêt. Donc ce que je vais proposer à mon interlocuteur, c'est plutôt le 20 avril. Donc je vais le voir, je lui dis écoute le 10, on le prend comme on veut, je serai après, mais par contre pour le 20, je peux m'engager. Est-ce que tu es d'accord? L'autre dit oui, on change la date du 10 au 20. On a oublié la date du 10, il n'y a plus aucune trace nulle part du truc. Et quand on arrive à livrer le 20, on dit tu vois, je suis à l'heure. Et l'autre il vous dit bah bah non, quoi. Donc voilà, seul le terrain dit vrai.
[00:31:35] Donc euh les reportings sont faux. Mais vraiment, les reportings racontent quelque chose, mais ils racontent pas obligatoirement la réalité du terrain. Donc essayer d'aller sur des faits, des faits qui ne sont pas des analyses. Ah ben j'ai vu qu'il ne savait pas parler anglais. Bonne chance pour voir que quelqu'un ne sait pas parler anglais, c'est pas marqué là, non. Donc qu'est-ce que tu as vu? Bah, tu as vu quelque chose, mais certainement pas ça, c'était plutôt une solution que tu aimerais mettre en place. Donc ne voir que des faits.
[00:31:57] Ensuite, savoir que quand on va sur le terrain, on va se confronter à des images que l'on a, à des réalités qui existent et que ces confrontations vont me permettre de se dire bon bah. OK, maintenant si j'accepte avec une forme d'humilité, la réalité telle qu'elle se présente, ce qui est pas simple l'humilité, eh bien je vais pouvoir commencer à entamer un voyage d'amélioration.
[00:32:17] Ensuite, il faut aller voir les gens à leur poste de travail. Il faut regarder le réel. Montrez-moi comment vous y prenez.
[00:32:23] Voilà une de mes Gamba les plus ratées avec un codir, je les ai emmené voir un directeur d'équipe qui avait une dizaine de personnes, qui faisait du ligne depuis un certain temps, et l'équipe.
[00:32:32] Donc on était dans une salle plus petite que ça, enfin, il y avait le codir, il y avait une douzaine de personnes dans le codir. Il dit ben on y va. Bah je dis non mais restez assis, on va se connecter. Puis il commence à on va se connecter. Bah je dis vous croyez pas que votre responsable d'équipe, il est ici, il est à Toulouse. Ah bon. Très bien, donc on se connecte, on voit avec Teams, on voit la tête du type, il dit bonjour, voilà ce que je fais et cetera. Et puis je savais ce que je voulais montrer, je lui dis bah est-ce que tu peux nous montrer ton écran avec ce avec quoi tu travailles. Donc plusieurs plusieurs canaux pour être sollicité de ci, de ça, du Teams, des workload ici et autres. Euh des équipes qui appellent enfin qui appellent de façon numérique, euh des des des métiers et cetera, ça tombait de tous les côtés. Alors il ouvrait son Teams pour retrouver des trucs. Il ouvrait son JIRA pour en retrouver d'autres, c'était dans tous les sens et puis l'équipe par derrière qui répondait tant bien que mal aux questions qui étaient posées.
[00:33:19] On raccroche. Et je leur dis vous avez pensé quoi du Gemba? On est vachement déçu, on aurait voulu aller s'asseoir à côté de quelqu'un. Oui, mais c'est terminé, mon type il est à Toulouse, les développeurs ils sont en Inde, les testeurs ils sont au UK. Donc ce que vous avez vu, c'est la vraie vie du responsable d'équipe. Donc il faut essayer de trouver la vraie vie. L'endroit où ça se passe, même si ça se passe quelque part dans le grand dans le grand système.
[00:33:42] Et puis après, le point d'après, c'est le respect des collaborateurs. Moi, j'étais voir un éditeur de logiciel qui me dit ça marche pas, hein. Ils nous ont mis sur le mur, tous leurs processus, les bacs rouges avec les endroits où ils avaient des difficultés, les allers-retours, quelques éléments de performance et cetera. On y a été, on leur a dit bah attends, mon gars, c'est pas comme ça que ça se passe. Ah bah alors là, ça a été facile, hein. Ils ont tout enlevé, tout mis à la poubelle, ça c'est fini. On ne voit plus rien, respect des collaborateurs. Not guilty. Les gens ne sont pas coupables, c'est nous qui avons créé des systèmes dans notre équipe de management, on a créé des systèmes et on a validé des processus qui font que les gens se retrouvent dans des situations invraisemblables. Qu'est-ce qu'on fait pour les aider?
[00:34:22] Je racontais hier l'histoire du dirigeant qui vient voir quelqu'un qui fait du code et qui compile. Et puis euh le dev lui dit écoute, si tu veux on peut peut-être aller faire autre chose. Il dit non, on va t'attendre la fin de la compilation. Ça c'est sûr qu'on a attendu, hein. Il dit tu compiles combien souvent? Bah ouais, deux trois fois par jour. Ah ben voilà, et puis il y avait 10 personnes autour de lui, hein, donc euh il était pas seul à compiler. Et en fait, il a essayé de comprendre pourquoi est-ce que c'était si lent. Bah c'était quelqu'un qui travaillait dans un bureau. Comme le comptable, comme des tas de gens qui travaillent dans des bureaux.
[00:34:52] Genre qui font les comptes rendus de réunion et cetera et donc il y avait une configuration ordinateur de bureau pour compiler. Pas top. Donc voir les réalités, respecter le collaborateur. Se dire en fait que soit on lui a pas donné les moyens de bien travailler, les processus sont confus, les informations dont il dispose pour travailler sont plus ou moins précises et plus ou moins disponibles, c'est compliqué l'équipe de métier. Et donc ça n'est franchement ça n'est jamais la faute de la personne qu'on a en face de soi. Et donc comment est-ce qu'on peut comprendre ces problèmes et comment sur cette base là ensuite on peut lancer des actions d'amélioration?
[00:35:28] Oups pardon.
[00:35:31] Alors le Gemba du manager. Alors le Gemba du manager, s'il veut aller voir un processus, s'il veut comprendre un client, voir un produit et cetera, on retombe sur les quatre Gemba précédents. Mais là, c'est autre chose. Le manager, il a une équipe, le Gemba du dirigeant, c'est pareil, il a une équipe.
[00:35:47] Et il a envie un de savoir comment fonctionne cette équipe et puis de la soutenir dans sa démarche d'amélioration. Donc on est vraiment dans cette esprit là, soit de l'engager, soit de la soutenir dans cette démarche là. Et donc là, il va vraiment s'intéresser à l'équipe.
[00:35:58] Donc à gauche, c'est quelqu'un qui gère tous les flux interbancaires d'une grande banque française. Donc euh un patron et puis ensuite, il vient voir l'équipe.
[00:36:07] Alors qu'est-ce qu'il voit? Déjà, il y a un minimum de choses qui sont affichées. Alors ça se voit pas bien, mais juste sous son coude, il y a des courbes. Et les courbes elles montent et elles descendent. Et ça permet de se dire si j'ai lancé des actions d'amélioration, j'ai une mesure qui me dit tiens l'action paye ou ne paye pas. Parce que l'idée, c'est pas l'effort de l'amélioration, c'est le bénéfice de l'amélioration. Donc ce que l'on cherche, c'est à trouver une action peut-être super facile, hein. On va pas mesurer l'effort, mais en tout cas un truc qui s'améliore. Donc on va pouvoir avoir une discussion parce que on vient une fois de temps en temps et on va pouvoir se dire depuis la dernière fois, bah tu vois, j'ai mis ça et ça en place et puis regarde, les temps de réponse sont meilleurs, regarde le nombre d'incidents baisse, regarde, il y a ci, il y a ça, mais là encore j'ai une difficulté, on va pouvoir rentrer dans une discussion sur l'amélioration. Voilà. Donc là, c'est le Gemba du manager, c'est pas une interrogation surprise. L'équipe est prévenue qu'il va venir, elle prépare tout pour que ça se passe bien. Le manager, bah il sait qu'il va venir. Donc euh il va être briefé sur ce qu'il va voir pour que il puisse aller sur les bons sujets et vous verrez qu'il y a des sujets sur lesquels on a vraiment besoin de sa contribution. Donc c'est important qu'il puisse les aider les identifier. On est dans un esprit dans ce Gemba, on est dans un esprit qui est ce qu'on appelle le Toyota Way. Donc euh chez Toyota, on parle beaucoup du Toyota Production System. Le juste à temps, le Jidoka.
[00:37:24] Le juste à temps avec tout ce qui touche au flux. Le Jidoka, tout ce qui touche à la qualité. Là, on est sur quelque chose de différent, c'est vraiment le système de management. Ce système de management. Alors c'est Toyota Way début des années 2000. Maintenant, ils ont un truc qui est un peu différent, mais on va rester sur celui-là. Deux axes, le respect des personnes.
[00:37:41] Donc on compte sur chacune des personnes, sur l'intelligence de chacune de ces personnes, on compte sur son dévouement, on compte sur son intérêt pour le client et pour l'entreprise.
[00:37:49] Et puis ensuite, l'amélioration continue parce que de toute façon le monde change et il va en permanence falloir être capable de s'améliorer. Dans une direction qui va bénéficier au client et à l'entreprise.
[00:38:01] Sur la partie respect des personnes, il y a vraiment le respect. C'est-à-dire l'âge, le sexe, les origines et cetera, c'est quelque chose que l'on respecte. Pas toujours simple, hein. Gamba avec la la CTO du groupe Michelin qui gère beaucoup d'infrastructures dans beaucoup d'usines au niveau monde. Elle arrive à 9h le matin, on a prévenu la PO qu'elle serait là à 9h30. Là, c'est pas nous, hein, mais on s'est dit dans l'équipe, il n'y avait qu'une seule fille, on lui a donné le mauvais horaire, elle a eu l'air d'une idiote. Le respect des personnes, c'est quelque chose d'important. Donc le respect des personnes, le respect des personnes. C'est est-ce qu'ils ont été bien formés? Est-ce qu'ils ont les moyens de bien travailler? C'est pas juste quelques règles un peu éthiques, c'est aussi un engagement personnel de l'entreprise sur la la la capacité de travail de ses salariés. Et le travail d'équipe. Donc je vous ai dit, not guilty. C'est toujours une équipe qui réfléchit. Alors ça peut être une équipe dans un sens hiérarchique, responsable d'équipe et son équipe. Ça peut être une équipe dans un sens complètement différent avec euh quelqu'un des opérations, quelqu'un des systèmes d'information et quelqu'un de de l'infra qui se disent mais comment est-ce qu'on va pouvoir réfléchir ensemble? C'est une équipe qui qui se constitue autour d'une problématique client et qui va essayer de travailler quelque chose. Donc voilà, donc euh teamwork. Et de l'autre côté, on va le Gemba, donc aller et voir, être au bon endroit, avoir la discussion avec les vrais personnes sur les vraies pièces, ça c'est important. Tout ça, ça va déclencher le Kaizen et le challenge. Donc le Kaizen, c'est l'envie de changer et d'améliorer, il y a une confière sur le Kaizen. Et le challenge, c'est l'idée de se dire en fait, on va choisir dans dans tout ce que l'on a envie de réussir, le truc que l'on va craquer. Donc c'est pas améliorer n'importe quoi. Et parfois on voit des choses, on voit bien que c'est nul, mais franchement ça n'a aucune incidence. Ouais, c'est un peu agaçant, bah à ce moment-là qu'on les arrête, mais ça n'a aucune incidence. Par contre, on va être sur un vrai sujet client. Pourquoi à chaque fois qu'on fait ça, ça plante? Avec toutes les conséquences que ça euh sur nous, notre organisation, nos weekends éventuellement et notre client. Et voilà. Et donc c'est ça qu'on cherche, le challenge, qu'on se mette d'accord sur un axe d'amélioration.
[00:40:10] Et donc quand notre manager va aller sur le terrain, j'ai une petite pause sur mon téléphone à chaque fois. to manage and improve. There's a colleague on the Kaizen and the challenge is the idea of telling ourselves, in fact, we're going to choose from everything we want to achieve, the thing we're going to crack. So it's not about improving just anything. And sometimes we see things, we see that it's useless, but frankly it has no impact. Yes, it's a bit annoying, that's when we stop them. But it has no impact. However, we would like to be on a real client subject. Why every time we do that, it fails. With all the consequences that that has on us, our organization, our weekends, potentially, and our clients. And there you go, so that's what we're looking for, the challenge, to agree on an area for improvement.
[00:40:10] And so when our manager goes to the field, Ah, I have a little pause on my phone each time. When our manager goes to the field, in fact, he will work on five attitudes, so I've listed them somewhat systematically, but uh, we'll talk about it a bit faster. The first thing is that the manager, the leader, he's going to see the team, he's going to tell them: You are important. That's what commitment is, that's what giving meaning is. Your work is important. When you do something, it has meaning for someone. So when I prepare patterns that go to the field, I tell them, you'll have to say for one minute: You are important. Oh, yes. I made people role-play, you know? I put them in pairs. There's one who says, "You come to my place," uh, the other who says, "Okay, I'm the manager," "How am I going to tell you that your job is important?" Oh, la la la la la la la.
[00:41:04] No? Does it speak to you? There you go.
[00:41:09] So, it's important to create a link. I go to your place, it's important. Moreover, I'm going to be interested in other things, in the things you do. Moreover, I'm doing the Gemba, I'm here, and I'm going to take the time. The second thing we have is the notion of questioning. We don't come to explain life to people. I explain to you, agility is so much better, you're going to work like this, your sprints and stuff, etcetera. Uh, you understood? Yeah, yeah, I understood. Yes, first of all, it's already been explained to me 50 times, uh, and then afterwards, I live this every day. So yes, I mean, you know, we're going to go to the cloud, etcetera. You haven't understood that in fact, it was my job to put all that in the cloud, you know, anyway. There you go. So we don't give lessons when we come to the field, we work on questioning. Why? Show me. What does it give? And then the open questioning. And you don't think that in the era of multi-cloud, it could be interesting to, uh, well, either I don't think so at all because I no longer have a brain, either you want me to say yes because anyway you've already made your decision, but in any case you're not having an exchange with me about my job, about my expertise, about my working conditions. You're just explaining to me, you want this, you're vaguely well-brought up, you put it with a question mark at the end, but we're not in the process of being in a learning company where everyone brings their contribution to collective intelligence.
[00:42:20] So work on questioning. Or, we went that far, it's not just to get the little chouquettes, shake the hands of the little families and hug the babies, we really want to see it. And there, something truly magical happens, that is to say, you are with people who work for the company, who love what they do, who want to succeed and who are so happy to share something. Because we come to see, again, we come to see just to understand, to see, to identify subjects that are going well and not well. And really, the link is made much more than with the manager who goes up on the stage and explains how life could be wonderful if everyone put their own in it. And then we're going to challenge the status quo. Now, that's the slightly difficult part.
[00:43:09] It's gone, we're going to challenge the status quo. Yeah, it's good, P1s and P2s, that's good, they're under control, but P3s.
[00:43:15] We still have a big stock, we're not always on time. And finally what users tell us is that 48 hours to get a new password for them to do their job, it's not great. Could we do something? Yeah, that's how the contract was defined, it's the SLA, it's that piloting, blah blah blah. Okay? So when are we going to manage to agree on a challenge? Look at the password generation that we're going to send back to the person who requested it, and say, 'Well, there's still at least 23 seconds of work.' Can we do it in less than 48 hours? You see? How could we organize ourselves? Because once we've said that, there are still a certain number of impacts on the daily organization. Challenge the status quo, so find the subject. Don't find 50 big subjects. Because there are too many anyway, we don't move anymore. So find the right subject and challenge it. This subject can be brought by the team. The more mature the team is, I showed you a picture earlier. The more mature the team is, the more it is able to say, in relation to our objectives, here is the next challenge we have. So the team can very well say, 'Well, that's what I'm working on.' Or, or she can be challenged by the manager who tells her, 'Well, listen, there you go.' And finally, support. That's why you also have to prepare the. the boss who comes to do the Gemba, we'll tell him, "Listen, you're going to see a certain number of things in the overall, part of it is your fault." Yeah, my fault, no, my fault, it's the organization's fault. Yes, but you're the boss. It's your fault. My computer story there that was too slow, didn't have enough power, one way or another, you're the boss, it's your fault if we don't have computers that can compile quickly. We take it as we want, you know? I mean, it's not the dev who bought his computer at the Fnac, you know? So, there you go. So try to find something in the conversation where you're going to say, "But I thank you, I was interested by this and that, and I take it upon myself to deal with this subject." Because if you want people to fight against the status quo, find avenues for improvement, try, strive, come back, reflect in addition to their normal job, huh? If you think it's important, that's what you told them at the beginning. And if, when you leave, you tell them, "In fact, all this only concerns you," and me, who, anyway, created this structure or am in charge of managing it, I don't care. Well, I don't care, but well, everyone has their job and it's not mine. Uh, and at that moment you're going to lose them. It's that in fact, you're not that interested in improvement. So there's a bit of give and take. It's not the moon, huh?
[00:45:38] It's not the moon, but it's something that will allow people to work in better working conditions. It's perhaps about facilitating relationships with a provider we know badly, it can be quite simple things.
[00:45:57] We did our Gemba, and now we have the choice between the blue pill and the red pill, and that is This is a quick test on general culture. Does it speak to you, the blue pill, the red pill? It's as much my generation as yours. Should I choose the red which is reality and the blue which is the matrix? So there you go. The Gemba is done.
[00:46:28] We've seen a certain number of things. Do we accept reality? Do we embrace it? Do we transform it through improvement? Or do we say, "Yeah, but finally the description of the processes wasn't bad, plus I have a workflow that tells me what I need to do and then
[00:46:43] uh, and then they just have to. They who are upstream, they who are downstream, they just have to accept the situation as it is.
[00:46:53] I don't have much time left, so I wanted to tell you a story about Gemba and Kaizen. We're going to go through it quite quickly, I've put some little photos with little Japanese things because you always have to do something cute. So there you go. There you go, it has nothing to do with cakes, huh? So we're going to do it quite quickly, it's a team that is in a crisis situation, it has to develop an application for payment terminals. When we want to use, when we want to sell this payment terminal in a country, the country must validate a certain number of criteria that will say, 'Yes, the payment terminal will neither spoil the merchant, nor spoil the cardholder, nor spoil the bank.' So, uh, because money sometimes has some strange circuits. And so they don't succeed. And so, how, from the Gemba, do we manage to tell ourselves, 'Well, I understand a certain number of things.' Go see the developers, go see the testers, try to understand. Well, when we discover that the testers and developers are not working on the same product, it's a bit of a shock. There you go, but in a way, when we found it, we managed to realign, you see, that's what Kaizen is. We manage to realign. So we don't say that Nik is right, or that the other is right, we reflect, we cogitate, we try to see. We see actions that serve no purpose, well, as we're really under pressure because it's been a very long time since we launched the application and that the authority that will validate it is two steps away from holding back, we'll have to do it quickly. And so we're going to look for all that, and then the Gemba allows us to launch action plans that are enlightened action plans. on which, well, I told you, we agree on the common vision of the product, how are we going to organize ourselves between the developers and the receivers, how are we going to report the problems more quickly so that the devs can correct them immediately, how are we going to work with our visual to choose our priorities, all that allows us to improve. But it doesn't allow us to improve everything. And there we do more precise Gembas. We're really going to walk along the process. The data, where is it, how do we transport it, what happens to it, etcetera, to understand at what points we made design errors. And so once we've found them, well, afterwards we think, we're going to do things differently, we're going to find a way to get out of it and to clean up our processes. So that's what I wanted to tell you today. What is the Gemba, why is it important? How is the Gemba an action of self-commitment towards the company and towards clients, commitment of the manager towards the collaborators with whom he works. And how the Gemba is really at the origin of improvement actions because what we want is to improve reality with all its weaknesses, but it's not very serious, but really improve it rather than making great plans about the comet saying my model A against your model B, my cloud C against your cloud S.
[00:49:29] The QR code I gave you is the Rex I just presented to you. There are six pages, so it's much more detailed, if you want to understand a story. There you go, it takes you to our blog, we have 700 articles. Uh, there are a lot about the Gemba, but anyway, this time it's really, normally you arrive directly on the Rex. And then the other, well, it's me. There you go. So, my name is Marie-Pierre Ygaz. I created a company called Opera et Partners which has been doing Lean in IT since 2007, so 18 years. Uh, there you go. And so, uh, what else can I tell you? Yes, I am also co-founder of the Institut Lean France.
[00:50:06] So, we only have one desire at the Institut Lean France, it's an association, non-profit, like Flowcon, it's to talk about Lean, to convince and to allow people to understand what true Lean is. I hope you found it interesting.
[00:50:28] We move on to questions.
[00:50:36] Hello, thank you for the conference. I had a question, it was when you do a Gemba, how do you know what you observe is really representative of the system or just a small part?
[00:50:48] So that's an excellent question. That is to say, I was trained in what is called Lean Six Sigma. By very good people in the field who tell you that you need a lot of data, etcetera. I've known data for 40 years too, so I know that you often need much less than you think. What Lean says is that in a certain way, it doesn't matter. First, I told you, you can look at one, you can look at three, you can look at 10. That's already largely enough to form an opinion. It won't describe the whole system, it won't model it. But it will tell you if I look today and now, today and now, I see this and that as improvement. And if I agree to do that all the time, I can talk about continuous retrospective. If I agree to do that all the time, in fact, nothing will escape me. So I don't have to have a representation of all the problems to tell myself, 'I can act there.' And it's a personal exercise anyway, you know. To say, 'Yeah, but finally, it often happens, it doesn't often happen.' Can't we do a little Pareto and so on? Yeah, no, no, no, we're going to already, there you go. Or we tell ourselves, 'Okay, I'll take a few days for the Pareto, but more than a few days is a shame. There you go. It's difficult.
[00:51:54] Hello, good morning. Thank you, Marie-Pia, for the presentation.
[00:51:59] I wanted to know, it's a bit in the continuity of the previous question. During a Gemba, we see a lot of things. And maybe we'll see a lot of dysfunctions. How do we prioritize? How do we take the first one? How do we choose the one we're going to work on?
[00:52:14] So, we're going to see a lot.
[00:52:17] Uh, so, I'm in a situation where I agree with people to do a Gemba together. Whether it's within a team or again a manager who comes, a client, a large ordering party who comes, etcetera, we agree to do a visit together. And we're going to see an enormous amount of things. But it's staggering what you can achieve.
[00:52:42] And when you leave the Gemba, people want your feedback immediately. So you tell them, "Well, wait, we'll debrief for 20 minutes, and we'll come back." 30 minutes, it becomes really difficult. So the idea of saying, "In fact, I'm going to take everything I've seen, I'm going to classify it, etcetera." When we do it just when we do the Gemba, it's often difficult in my position. And so you have to quickly manage to select from everything we've seen,
[00:53:06] among what with the perspective of what the boss told you, to say, 'Well, here and here we're going to act.' The first thing, uh, I would say, is the pebbles that are in the shoes of the collaborators. Because to tell them, 'We're going to improve to make things that will have absolutely marvelous UIs,' while people don't really have the means to work, they have small screens for their UI, good luck to get what they need, huh? So, uh, we're really going to work on the pebbles. because it will show that we are interested in them, that we have empathy for them and that we want them to have the means to work well. Afterwards, we'll be able to start working on more important subjects. I find that subjects that touch the client are subjects that have meaning. The client, quality. So we're often going to go to those subjects. After, if we really want to set up action plans, to say, 'Well, we'll give ourselves a period, we're going to challenge our system, we're going to pass several steps.' First we don't do one Gemba, we do several. For this one, we're going to map a certain number of things, we're going to draw the process, we're going to say, 'It happens five times here, three times there,' we're going to see, there you go. And at that point we'll be able to reflect together on an action plan, telling ourselves if that's what we've seen, what we're starting with. So there are two slightly different stages, there's learning to do your Gemba, or telling yourself we're going to build a medium to long-term action plan. And we invest more or less time depending on the objective we set for ourselves. There you go.
[00:54:34] Hello, thank you very much.
[00:54:37] I was asking myself the question, is it every hierarchical level and, well, is it necessary to go to the highest level of the company's hierarchy to have a maximum impact for the Gambass, the Gumbat, sorry, or is it that it doesn't matter where we hit, it just needs to be motivated people?
[00:54:59] And I had a second question, and I already forgot it, but that's already good.
[00:55:02] We'll answer the first one first. Motivation is super important. That is to say that it can be, we can be two, we say, 'Let's go do a Gemba in the code, we're going to go into a shop that sells our products, we're going to see how it goes.' Really, motivation is important, and it can be a super regular practice, constantly. To tell yourself, 'Well, there was an incident, we're going to try to understand where our first code is, we're going to walk along the process to find it,' etcetera. It's really very important. That being said, uh, at some point, you have managers, leaders, who are going to frame people's work, one way or another, even in agile teams that feel super autonomous. Well, as they are super autonomous and they are agile, it's good that someone gave them permission to do it, because there are other companies where it's not like that. You see, it's not necessarily a revolution that comes from below. And so you also have an interest in having leaders who get a little bit involved. Who come to show that it's important, who come to support people who have the initiative, who try to share their vision with what's happening on the ground. So that's what, I think it's really worth bringing your manager, and when he comes, he tells his managers, 'Yes, I'm interested, so you should be interested too.'
[00:56:09] Because if I, the boss, am interested, well, you shouldn't be caught off guard, so go, look, try to get some benefit from it too. So that's really this managerial alignment that allows us to say, 'Improvement is not just about the people who produce.' It's also the management that wants it. That's the first point. And the second point, uh, there are still a lot of things in your methods, your processes, your tools, the orientations, which come from decisions they made, one way or another, to invest here rather than there, to offshore to India rather than to relocalize here, etcetera.
[00:56:40] And the fact that they come to the field and they manage to see the consequences of their decisions on how people have the means to achieve something, that does them the greatest good. You see, you have, so there you go, motivated people, as soon as you're motivated, go do a Gemba somewhere else. People open their doors, people, well, I find that we are always well received. You really need a very particular situation for us to close ourselves off. People open their doors. So, but on the other hand, you have to explain well what you're doing. Uh, managers can convey the message that improvement is important to them, and they can discover that, in fact, they are making decisions that are perhaps not as favorable to the company as they thought.
[00:57:20] One last question?
[00:57:28] Hello. A small question that I ask myself about Gembas in general.
[00:57:32] Excuse me, I didn't see where you were. Ah, I'm here. There you go, thank you. Yes.
[00:57:38] The question is, uh, your opinion on the balance to find in terms of frequency and duration on the Gembas, according to you, uh, what is the good practice to precisely not be both out of touch with reality and not too intrusive or taking too much time from the teams.
[00:57:57] I tell myself, you see, you are a manager, you are a manager of a perimeter in which you have four or five teams, 50 to 80 people. Doing a Gemba per month in each team is not ridiculous. How did it go this time? We talked about improvement on such a subject, it works, it doesn't work, are there other subjects that emerge, you see, having that conversation. I think once a month is not bad. It's not super aggressive because, well, we know it's the second Monday of the month, or we find a, we find a frequency, we prepare and we have this somewhat continuous conversation. There you go. So, but there we're talking about someone who
[00:58:28] can go see his five teams within the month. I mean, if it takes him 2 hours x 5, it takes him a day and a half, uh, if he's the manager, he has to spend time with the people he works with. There you go. When we go up to other levels of management, we have to live it more as a personal discipline. You have to go see something once a month. And so, well, we're the boss of a domain, we have 200 people, plus service providers, plus clients, etcetera, we tell ourselves, next month, I'll rather go see here or I'll rather go see there. And so we encourage these managers to really have this discipline of saying, 'Once a month I'll see something.' But as the size is quite large, uh, there you go. After, uh, there may be people who say, 'Well, there, we're really on a subject that's important, so I'll come back.' In any case, they make a commitment to come back. And then finally, there may be situations that are a bit critical. I remember a boss of studies who, uh, there was a production launch that went very, very badly. He came to see the team, he told them, 'Listen, there you go, we've fixed it, we've restored it, etcetera, everything is fine.' Uh, however, we need to review the test plan. What did we miss in the test plan that caused the production launch to go so badly? There you go.
[00:59:37] Thank you, Marie-Pia. Thank you.
[00:59:39] Thank you very much, Marie-Pia.

Transcript (Translated)