Etienne de Susanne
Duration: 57 min
Views: 456
5 likes
Published: March 15, 2024

Transcript (Translated)

[00:00:00] Ladies and gentlemen, good morning. Thank you, thank you for coming in such numbers. I'm very impressed by the almost full room.
[00:00:12] My name is Étienne de Suzanne and I am the IT manager for the Euro Master group. Can you hear me well? Is that okay? It's perfect. What I'm proposing to you today is a scientific experiment. We're going to look at what happens in the head of a Command and Control manager, with a slightly military tendency, when exposed to agile methods, then lean methods. So, this guinea pig, that's me. And I'm going to share with you what I've experienced. And then, in a second phase, we're going to look at what it does to the company. What is the result actually? Does it change anything and if so, what?
[00:00:48] What I propose is that at any time, if there's a question of understanding, if I don't express myself clearly, or if there are words you don't understand, tell me, and we'll explain them. And we'll keep more fundamental questions about the results, the debate, etc., for the end. We'll set aside 10 minutes at the end for a Q&A session. So the story, it begins not far from here, in Créteil. My first job was to take care of traffic jams on the motorways in Île-de-France. Well, yes, it didn't produce exceptional results. Uh, but at that moment, I had software developed for traffic management, so travel time calculation, display on signs, stats for bison futé, etc. And in fact, I launched public tenders to develop software. And public procurement has many qualities, but it's not very flexible. What's not in the specifications isn't delivered, and it's a V-cycle, it's a caricature of a V-cycle. So it kind of formatted me. After 6 years, I joined the Michelin group in Clermont-Ferrand and I had a completely normal career as an IT manager, first as a project leader, sorry, project manager. Then, uh, lapsus, then I took care of large programs. So in two big areas, I was in charge of tire distribution, having the right tire at the right time for the right customer. And I was in charge of service offers for fleets. So these are tire leasing offers where Michelin remains the owner of the tire and bills for kilometers driven.
[00:02:20] Uh, in 2008, I went to the United States. I was in charge of the IT team that managed all the supply chain and logistics software. I did that for 3 years, then I came back to France. And then I had the chance to work on a big program of profound change in customer service, a program of several hundred million euros, a 10-year roadmap. Uh, we do the architecture analysis, we structure the delivery into projects, we set up a milestone control system, checklists, quality assurance, and I'm in the process of staffing the teams. So I'm in the middle of ramping up staffing. And it's at this moment that the group's IT department decides to send me a young consultant, Nicolas, who comes to explain to me that I would be much more effective if I used more agile methods. So, with this extremely structured steering system, the last thing I want is for a young rogue to come unscrewing bolts everywhere without me being able to control him. I immediately perceive Nicolas as a threat. And since he comes from management, I can't just reject him, so I'm going to have a trick to get rid of him. I assign him to a project that I'm sure will fail.
[00:03:39] New technology, new business process, direct customer impact. All that has never been tested, and we have 6 months to deliver. In V-cycle, there's just no chance it will work. And when I do that, I have a double intention: at a minimum, I hope that Nicolas will exhaust himself trying to make this project work, which cannot function, and I will send him back to his sender in three or four months. At best, if the project crashes and makes too much noise, I'll blame these new unreliable methods and I will commit to bringing the project back under control with the real Command and Control methods, the ones that work. Uh, so it's a very cynical approach. But something strange happens. I do that, and I don't hear about the project anymore. Silence.
[00:04:29] A project that crashes makes noise. We hear about it. Nothing there. So I'm going to ask questions. Is the project going well? Oh yeah, great!
[00:04:37] After three months, I acquire the conviction that they are trying to fool me. The project cannot work. They tell me everything is fine, so I decide to go see what's happening on the project floor. So at the moment I push the door, what I expect to find are teams under tension, conflictual situations, a frustrated sponsor, in short, a project situation that's not going well. I open the door to the project floor, and what I discover is... it's post-its. It's the Lascaux cave, there are everywhere, on the walls. They made a duck with yellow post-its on one of the windows. And then, there are two people in a corner who are taping pieces of red wool between post-its. It's crazy. We have planning tools for that.
[00:05:18] However, there's something that surprises me: there's no conflict. It's not tense. It's even studious. They're working. It even smells a bit like brains in that open space. It's weird. I decide to go see the sponsor. So there, I expect to be rejected, huh? So, helmet, shield, I advance towards the sponsor, and then, surprise, the sponsor is ecstatic. Great project, it's going very well, cooperation, value. We're going into production in three weeks. Ah, I have an anxiety, it's not possible that we go into production in three weeks, and then I have a shock actually. A double shock, the first one, I'm scared because I have the feeling, I realize that I'm missing out on something huge. I feel like being Kodak in front of the digital camera saying "Oh, crappy definition, it will never work." Keep making film. And then, I have that, and at the same time, I have an epiphany. I tell myself, but if that did that on this project that was doomed or that wasn't going to work. What could it do on a program scale?
[00:06:22] So there, suddenly, I grab Nicolas, I'm still a bit arrogant at that moment. Nicolas, come here, come here, come here, explain your thing to me, post-it, wool, whatever. And then, fortunately, fortunately, Nicolas is not cynical, he explains to me. And I understand the potential of the transformation, and together, we are going to deploy the agile method across the entire program. To do a safe transformation. And it works very, very well, with the exception of a difficult deployment in North America. We deliver all projects on time, on budget, with the expected value. And I had just never done that in my career.
[00:06:57] So everyone is super happy. Everyone is super happy, except me. First, it's a bit vexing, this thing. It's been 15 years that I've been failing, and I hadn't noticed. And then, uh, I don't understand why it works. I see that it works, that it works better, but I don't understand why. So I bombard Nicolas with questions.
[00:07:15] He answers as best he can, and after a while he tells me, "Listen, Etienne, you know as much as I do. If you want to go further, you need to discover Lean Management." He says, "Go to Paris, to Catherine Chabiron and Michael Balet, and train in Lean Management." Well, I'm really dumbfounded there. I just got agile full in the face, he's talking about Lean Management, he's talking about Toyota. What is Toyota doing there? I don't make cars, I make IT. I don't understand anything, but nevertheless, I learned to trust Nicolas, and I do what he tells me without understanding.
[00:07:48] So I go, I find myself in the middle of about forty industrialists who talk about problems of furnace temperature stability in firing, oxidation inside copper tubes, etc., at ultra-high frequency. I don't understand anything they're saying. But there's a brilliant thing: I discover Lean in its industrial juice. And that's great. So, the industrialists, they are like us. They make bugs. A bug in industrial is a faulty part. And the big problem is that you have to put it somewhere. So it takes up space, it can be small or big, so we put it there. And a factory crashes. So when it starts making faulty parts, it makes a lot, and it makes piles like that. And the workshop manager, every morning when he enters his workshop, he sees his pile of faulty parts. And he walks past it, he can't ignore it, it grows every day. Me, the bugs, I don't see them, do I? They're in Jira or in Service Now, I don't go there every day. And even if I go, it's complicated. You have to make a report, filters, you have to have the rights, etc. So in reality, I don't see them. So if I don't see them, it's not my problem.
[00:08:50] The workshop manager, he sees his pile of faulty parts every morning. And for a year, I do that, I make parallels between industry and IT. The little train, CI/CD, etc. And uh, so I finish the CES Lean. I come out last, by the small door. But I still do it. And uh, Michelin is going to trust me a lot. Because at that moment, they entrust me with the direction of an IT team that works on data. So it's the team that will build the data lakes, it's the team that deals with integration, etc., for the entire group. It's a passionate job, I jump on it, I'm super happy. It's my beautiful medal of Lean manager, and I tell myself, I'm going to make a Lean management team. Great. I go for it, and it fails. So it fails completely. Why? Because, and this is the first lesson I learn, it's that I tried to change my management team before changing myself.
[00:09:49] It's not after a few months of Lean training that you become a Lean manager, it's a very deep, very Copernican transformation, actually, and I honestly think we can't do it alone. That's the second lesson, you have to start with yourself, you have to be exemplary, it's essential. And you have to get help. You can't go it alone. It's not possible to change alone, it's really too hard. Well, I didn't manage it. I added a little word which is Hai Sensei. It means yes, master.
[00:10:18] So for a manager who has 20 years of experience, a bit of ego, to have a young upstart come and give advice on things that have absolutely nothing to do with the current concern. Arrive and what's more, he's incapable of predicting the result that will come out of it. He says, you have to do that, you have to go do a Gemba at such and such a place. But why and what will it do, we don't know. Uh, it's a bit difficult anyway, there you go. So you need a certain dose of humility and selflessness to listen to your sensei or your coach, and in fact, it's indispensable. And also, you shouldn't hit him, because when you're a manager, you have the floor, you know how to talk, and so you know how to easily reframe someone with words. And when you're irritated, you tend to do it, to do it badly, and to do it in a brutal way. You particularly shouldn't do it with the coach. Because his job is to come sideways, to come shake things up, to come irritate, and it's always at the wrong time, actually, it can't fall at the right time.
[00:11:15] You have to accept that permanently by your side. Otherwise, if we don't do it, we don't really change. So it's indispensable. And it's not easy.
[00:11:26] The second point is that I have often seen Michelin make transformations where one or two coaches come and transform both the team and its manager for a few months, reorganizing the production system in agile or lean. And uh, and then after a while they leave, so they are in light accompaniment. I personally found that not very sustainable. In fact, often what will happen is that at best, the manager will try to accompany the transformation, but he is transformed, it's not him who transforms his team accompanied by his coach. And it's important because then, he suffers a lot. It's not his management mode that he brings, but he suffers the transformation. And very quickly, when the coach leaves and the first difficulties arise, he will revert to his old reflexes. And at worst, he's as cynical as I was a few years ago, and he'll simply sabotage the thing. So, in fact, I learned to approach it a bit differently. What I do is I do what I did for myself. That is, I organize a year of Lean training. I put the managers together in an academy. So we launched it with Sophie Dufaux, who is an internal consultant at Michelin, and then the Operae cabinet, and we trained the managers in Lean, giving them a year's head start, actually. So that they can absorb the method and then be able to make it their management style and give it back to their team and take their team with them.
[00:12:56] And the last point is that in IT, we have an incredible chance, it's that we have a lot of problems, and it's a source of value and a very easy way to start in Lean, in fact.
[00:13:13] Uh, what I propose is that we start looking a bit at the results, what this journey and this transformation and these first steps in Lean have achieved. So, what you see here, all these indicators are built the same way. On the left is the past, so you'll see year by year, a column with the result. On the right is the current year, month by month, there are 12 columns. If the column is red, it means we haven't reached the objective. If it's blue, actually it's green, I'm colorblind, so I don't see the difference between green and red, so for me it's blue and red. And if it's blue, it means we've reached the objective.
[00:13:50] What we observe here is the average number of incidents every month. That is, the number of times a user had to call support and tell us, "Guys, it's not working, I can't work, it's stuck, it's broken," etc. There are no alerts, no automatic incidents. There are only cases where a user is impacted. And you see that in 2018, when we start, on average, there are 568 incidents every month. 568 times every month, a user called us saying, "I can't access the BI, I can't edit my report," etc., etc. We embark on a problem-solving approach, PDCA, QRQC, etc. And after a year, we manage to reduce this number to 457. That is, we save 111 incidents, we prevent 111 incidents every month on average. That's -20%, well, it's not bad. Not bad, but meh, finally, is it that good?
[00:14:49] So there I find myself with my boss who tells me, "Well, Etienne, you're burning a fortune in Kaizen." So the Kaizen time, so I when I launch the problem-solving approach, I try to dedicate half a day a week where we stop producing projects and we work on improving ourselves, on solving our problems. It's very, very difficult. In IT, we track the time we spend. We allocate it to projects. And we tend to saturate time by allocating all the time to projects. And we have the woodcutter's syndrome who doesn't have time to sharpen his saw. When we say it like that, it doesn't make sense, but it's a reality, in fact. It's very, very hard to get the teams to stop producing for half a day and solve problems. They feel like they're stealing from the company, not working, they use it to finish what they were behind on, but not to solve problems. I find that very difficult, but I still do it. That has a cost because when you have a team of several hundred people, and you dedicate half a day a week, it costs 1 million euros in the case we're in. So I invest 1 million euros, and my boss tells me, "Etienne, you invested 1 million euros, but where are the results?" And so I find myself facing the difficulty of justifying this Lean approach, in fact. And uh, there's the wrong method, which consists of saying, "Well, I do it, but the others don't, boss, it's much better for me," but that doesn't work, of course. So we tried to value it, to say, "But finally, what does it bring to the company?" So what we did for that, we calculated the time spent by IT people to resolve an incident, and the time spent by users to avoid it, bypass it, reprocess data, redo things that hadn't worked, etc.
[00:16:30] So it's purely time spent, valued at the payroll cost. And we ignore the impact on inventory, we ignore the impact on customers, we ignore the company's image, we don't count any of that because it's subject to discussion. We only take what we know how to count and we take the lowest possible values for it to be reasonable.
[00:16:49] And we reach roughly these figures, that is, a severity 1, the most serious, is 10,000 euros, and we degrade them down to severity 4, which is 250 euros. We know the distribution of the 111 incidents we avoid, you know. And so when we value these 111 incidents at the unit cost of an incident, we get about half a million per month, which is 6 million euros after 2 years.
[00:17:14] So there, we have an approach where by investing 2 million euros in Kaizen over 2 years, we have a payback of 6 million euros.
[00:17:23] in cost avoidance, it's not really savings because we're not going to let people go. It's cost avoidance. So what do we do with all that time? Because 6 million euros, that's starting to be a lot. In fact, they are in the budget, people are available to do something. Well, we're going to initiate quality approaches, automation, alerting, monitoring, self-healing, automatic problem resolution. And the machine gets carried away and more and more we avoid, we improve quality, we avoid incidents.
[00:17:51] My conclusion is that if you do Lean, even if you only do problem solving, there's already a monstrous payback, in fact.
[00:18:01] So there's a book that talks about a gold mine in Lean. And in fact, it's true, it's that when you start to touch quality and the number of incidents, there's a real gold mine. I didn't believe it when I read the book, I thought it was an image, but in fact, it's true. It really crashes. in fact, they are within the budget, people are available to do something, well, we are going to implement quality approaches, automation, alerting, monitoring, self-healing, automatic problem resolution. And the machine is improving more and more, we avoid, we improve quality, we avoid incidents. My conclusion is that if you do lean, even if you only do problem resolution, there's already a monstrous payback in fact. So there's a book that talks about gold mine in lean. And in fact, it's true, it's that when you start to touch quality and the number of incidents, there's a real gold mine. I didn't believe it when I read the book, I said to myself, it's an image, but in fact it's true. It really works.
[00:18:19] So, at that moment, I'm working with Pierre Jannes, who is just in the next room trying to fold paper airplanes. And one day he tells me, Etienne, you have to make a customer wall in your visual management. What is that thing? So, we don't really know what to do, but well, I do what he tells me, it's say sensei. So, that's what the first step is what you see on the left there, the brown paper. So we put a nice customer title at the top, at that moment we tell ourselves that our users, our customers are not happy, so we put a red smiley face. And then you see here, an ambitious annual measurement plan with three measures. Because we were never going to see the customers to ask them what was going on. However, they write to us, in general, they write to us when they are not happy there, and what we do is we print the angry emails and we stick them on the brown paper. To please Pierre, to do something because we didn't know what to put on his customer wall.
[00:19:15] And we do that. So after the second generation, it's the magnetic board in the middle. So you see that we still have our measurement plan, but there we have something, it's the first NPS. We do an NPS, it's the first time. And here, you don't see it, but there are 15 pages of verbatim printed, because in fact, when we asked the users, they had a lot of things to tell us, they answered us, we found ourselves facing several hundred verbatim that we didn't know what to do with. We hadn't planned that at all. So, to please Pierre, we stuck it on the customer wall. And then after that we got a bit to work, we analyzed them, we made some Pareto charts, we found there were some Pareto chart heads, we started to solve the problems of our users. But for us, it was very new. The third generation, it's the digital version, COVID passed through, so we had to digitize our, our, our obeya in fact. And you see that there are starting to be recurring measures, twice a year for those who are still on two releases per year, at each sprint for those who are on sprint, we count how many customer surveys we do and you see that we manage to do up to 17 per month from August, starting from zero. And then we have our first NPS measures, they are there. We had started at -4 the year before, and you see, we have fun at the beginning. We go to the nicest customers, the ones we know will answer well, so we start with NPS at 75, 50 and everything is fine. Then as we progress, we hit hard cases. Or the frankly unhappy ones here. And that was very simple. It's a super important functionality that users were waiting for, that we had developed, put into prod, and that they weren't using. But we didn't know it. Since they didn't see the functionality, well, there was no ticket about it, no news. When we asked them the question, they said, it's impossible, we've been waiting for this functionality for a year, it's still not there and all. And in fact, it was in prod. Except that we had forgotten to open the network routes in the firewalls so that we could access it. So no one was accessing it, it was that stupid. In three days it was resolved. But we didn't know it, in fact, we didn't see it.
[00:21:21] So in fact, by addressing our customers, we discover very, very simple veins of value, very easily accessible, and we manage to improve the NPS. So at the beginning it's very easy, then it's a bit harder obviously because we come across deep, difficult cases.
[00:21:41] So the fact of seeing your customer and of seeing their satisfaction and of seeing their presence in the Obeya, it makes it very real. Very often, especially in a global group like Michelin, we don't see our customers because they are in business departments in several places on the planet, in the United States, in China, in Thailand, etc. So we meet them quite rarely in fact. And the fact of having them in the Obeya, every time the management team is present with us, it has a real value because we take care of what we see. Remember the pile of parts, the pile of defects.
[00:22:12] If I don't see it, I don't deal with it, the customer is the same. It's not easy, mind you, there are two years of work between the brown paper version where we didn't know what to do, and then a slightly structured measurement plan with NPS that drives progress, there are two years of work. That's it. It's long to get into it in fact.
[00:22:33] So I learned the importance of visual management, I learned something else, it's that uh using measurement as the sole arbiter of success has enormous value. Because it's not emotional. It's just a metric, it works or it doesn't work, that's how it is and we can attack the root causes without getting into conflicts of position, power, resentment, things like that. And it helps to make progress very quickly. There's another important thing, it's that the team measures its performance for itself. It's not reporting to the boss. It's whether the work I do works or doesn't work and what I need to do to make it work better.
[00:23:14] I care about my users, not the sponsor, or not only the sponsor. Thank you.
[00:23:25] So, the teams in all this, how are they doing? They are suffering from lean, it's putting pressure on them, what's going on and all. So we did something, as we had a bit of agile culture, in fact there was a team mood system. So there are daily meetings, team meetings, stand-ups and everyone puts their team mood. It's red, green or orange. It can be for any reason, my boiler broke down, I took a cold shower, I'm fed up, I'm red today, but it can be more seriously, it's been three days that I'm trying to test the test environment and it's still not available, I can't do it, it's frustrating, I'm fed up.
[00:23:56] We're going to be blocked again, we won't be able to deliver. I'm red. And uh, what I do is I collect all these moods and I calculate something called the Net Happiness Score. So what is this thing? It's a kind of NPS. So I take all the greens, I subtract the oranges and the reds and I divide by the number of voters. And and and I look at what it gives over time. So what you see there is three years of Net Happiness Score.
[00:24:22] Uh, we start, you see, so I had set the bar at 50, in a totally arbitrary way. In fact, at the beginning, I hadn't set any bar at all because I didn't want there to be an objective. Because you absolutely must not set an objective there, otherwise it will spoil the whole system, you will bias, you will break the thermometer in fact. Uh, I use it in two ways. When it's in the red, it's when the teams are in difficulty. So there I stop bringing challenge and I take a posture of help. So I do gemba, gemba, gemba to understand where it's difficult and I do my blue chef, I smooth out, I solve the problems, I facilitate the interfaces, I realign the objectives and so on. I come to help the teams. Eventually I bring in competence, expertise with our partners and so on.
[00:25:07] And when it's blue, when everything is going well, uh, that's when I bring the challenge. We're going to remove some of the flow, uh, increase the, uh, the objectives. So it's a bit difficult because it completely conflicts with the annual sequence of objectives and variable pay of large companies, but but but in fact it allows to press at the right time, at the moment when we can be heard, we can be listened to, and on the contrary, to come and help when needed. There's a funny thing, there's a seasonality in it. You'll notice that in August, we always have phenomenal scores. So in fact, the best way to be happy at work is still to go on vacation. So I let you meditate on this profound discovery there. Uh, so what you see anyway is that the overall trend is improving. Uh, the red moods disappear in fact. Because we solve the problems. And in fact, in lean, well, people are much happier, the team members. Those who suffer are the managers, not the team members.
[00:26:12] If we look a bit at the balance sheet after three years of lean transformation at Michelin in this data team there. What do we observe? So, we observe the user satisfaction, you've seen it, we went from I don't know to +4, to +60 in NPS. Quality, you've seen it, we've reduced the number of incidents, and that's where we get the millions, 3 million euros per year. Uh, we've reduced them by about a quarter. It doesn't work miracles, uh, it's not divided by 10, but already a quarter, it, it creates a lot of value. Time to market, we do EDI flows, and at that time, on average, to release an EDI flow, when I arrive, it takes 6 months, it's not rare, it happens in several places, that, and uh, in two years, we managed to reach 3 weeks. And I think now they are at about 10 days time to market. So it continued to progress after my departure.
[00:27:05] Which is very reassuring. Uh, and finally, the Net Happiness Score, the teams are much happier.
[00:27:14] After all these results, one day my boss calls me and tells me, Etienne, well, not bad, the team has progressed super well and all. We would like to offer you to take responsibility for the IT of the Euromaster group. So Euromaster, in fact, is a 100% subsidiary of the Michelin group. And uh, we offer services to fleets and to drivers, around tires and rapid vehicle maintenance, with a big focus on safety. So that's who we are. We are quite known for our our activity, we are quite known by the general public for our light vehicle activity. Uh, and in fact a large part of our activity is on industrial vehicles.
[00:27:52] Uh, it's a company that has a European network of garages in fact. So there are 1500 directly owned points of sale, so a very distributed IT system, 10,000 employees and 1500 mobile vehicles, small vans that come to repair your car or your tires on your parking lot.
[00:28:12] And you see that we are all over Europe, from Turkey to Scotland, from Finland to Portugal, we are everywhere.
[00:28:19] IT is not great at Euromaster. Uh, I arrived a year and a half ago, and uh, IT is perceived and it is very expensive. Uh, it doesn't create much business value, it doesn't really support business initiatives. It's very obsolete, complicated, fragmented, uh, the processes are not unified and there is a breakdown of trust between IT and the business. So it's not a beautiful, clean Greenfield, it's a normal medium-sized company that grew quickly through successive acquisitions and its information system is a reflection of this growth and it's difficult. It's difficult. So when we arrive in a situation like that, where do we start in fact?
[00:28:59] So the first thing I do, I arrive on September 1st, September 15th, I block in my agenda, every Thursday at 3 p.m., one hour of problem solving. I give responsibility to the head of support to bring a problem to solve each week. He has the choice, there are only problems in support, so there you go. But he chooses. He chooses which problem he brings to solve. And we mobilize the entire IT department, the entire management team, compulsory participation, uh, to solve the problem.
[00:29:28] So mandatory means exemplary, it means that no matter what, every Thursday at 3 p.m., I will be in this problem resolution meeting and so later I will have a Gordian problem of choice to make, uh, on that day which is a Thursday.
[00:29:43] Of course, I set up a Kaizen time and so I protect half a day per week for Kaizen, where the team has time to solve the problems.
[00:29:54] Uh, and finally I set up a visual management.
[00:29:58] So, the first visual management I had to do, I was still working with Pierre at that time, and one day he told me, Etienne, what do you want to succeed in?
[00:30:10] So I tell him, it's easy. I want projects to arrive on time and solve problems in support. He says no, no, no. You are a project manager, you deal with projects. Jean-Claude, the head of support, deals with solving problems, he does it very well, don't worry. But you, boss, boss of the team, what do you want to achieve? And there, I was unable to say what I wanted to achieve. I had never thought about it. So the advantage of not being alone is that when we are sinking like this, he catches me and says, listen, if you don't know what to do, you can already do customer satisfaction, quality cost, lead time and it will be pretty good. I jump on the lifesaver and uh, and I do that. And my first visual management is that, and since then it hasn't evolved much.
[00:30:49] Uh, it, it has that look. What I did is that I still split the run activities and the build activities into two parts. I put the user satisfaction first. Then the quality that contributed to the user satisfaction, then the acceleration or the time to market. And I didn't keep the costs. I put that on another panel which are the support objectives, in fact. These are the success objectives or the result objectives. I have two objectives of means. So, notably the green IT, notably the budget, uh, career management, trades, etc. But all of that comes in support of these success ambitions that are there.
[00:31:33] There are some that I find upon my arrival. And you see that I don't have a Net Promoter Score, we don't measure anything about user satisfaction on the build. We have nothing in terms of on-time delivery and time to market. So on-time delivery is, do I do what I said? Do I deliver on time? And once we deliver on time, we can ask ourselves the question, can I go faster? The time to market. But you have to take them in that order. For now, there's nothing. Uh, however, I find the mean time to repair, I find the number of incidents and I find the change failed. Does that sound about right? Is that okay? Is that good?
[00:32:08] And there is one that doesn't exist and that I create quite easily and quickly, it's what I call the Green Days. So the Green Days, I inherited it from the Michelin experience. Every day, I take one representative from the business in one country and he will give a color to the day, red, orange, green. Green, we were able to do our job with IT, no problem.
[00:32:28] Orange, it went badly, there are centers that couldn't operate, but globally it worked more or less, and red, everything is broken, there are transversal functions that are down, it's purely a feeling, he doesn't have to justify, he decides.
[00:32:41] What I want to capture is the users' feeling.
[00:32:50] So the Green Day.
[00:32:53] Uh, Euromaster's business is a seasonal business. We work very hard in November, December to mount winter tires, and very hard in March, April to mount summer tires. And in January, February, we have a trough, and then we have a trough during the summer in fact, where we are really under-active. An Euromaster center, in November, in general, there's a tent and a Jean-Boris on the parking lot, with tire mounting machines, temporary workers, and it cranks out a vehicle every 10 minutes, every quarter of an hour, it really works hard. And it's at that moment that the information system chooses to crash. So we can no longer make quotes, we can no longer invoice, we no longer have authorization to work on fleet management, it's hell. I'll let you imagine, a center manager facing a customer, I can mount your tires for you, trust me, you'll see, it's not expensive. Uh and we do it really well, but I can't print a quote for you, I'm sorry. And you won't stay, huh. Or else, uh, we couldn't make a quote for you. That's it, your car is ready, here it is, I can't print an invoice for you, I'll send it to your home. I'll let you imagine the efforts to recover an invoice sent to the home.
[00:34:03] And in addition, the center manager, after having worked a whole day from 7 a.m. to 6 p.m., at full speed, getting a vehicle out every 10 minutes, stays until 8 p.m. to print the invoices when they are available. It's horrible, in fact. And there, what we measure is, uh, well, it's the periods that are yellow there, the 3-4 are March-April, 10-11 uh, October-November. And you see, the availability rate of the information system collapses to 25%. That means it works one day out of four. It's, it's really awful. And so we focus on that. In fact, we try to solve that problem. Uh, and you see that we're getting there more or less. First summer campaign there, it's already better. Well, better is a way of speaking, it's 50%. One day out of two it doesn't work. And then uh, the winter campaign of last October, we were almost at the objective of, first objective of 70%. So in fact, by implementing problem resolution, a focus on customer perception with very, very simple measurement tools, it's just, well, there's one correspondent who decides if it's red, green, orange, that's all. We manage to make considerable progress and to focus on the right objective.
[00:35:10] We went back up, we were at 70% of the objective, we did 74 this year, we see it there, yeah. And we set the objective for 2024 at 80.
[00:35:24] Uh, so I believe, uh, in users, so I know there are one or two somewhat provocative conference titles about users, I've seen them.
[00:35:34] Uh, you have to coddle the users. I say it and I write it like that, coddle the users, you have to coddle the users. It's super important. Because in fact, if we don't do it, one day someone else will do it in our place. So if you want to keep your job, you have to worry about the users. You have to write down your ambitions, what you want to achieve. It's quite difficult in fact. Remember earlier, the first time he wanted me to do it, I couldn't and now I force myself to write the ambitions. And I force my teams to do it. So this system of ambition, there's something there.
[00:36:07] Uh, I write my intention, what I want to achieve. And I ask my managers to be inspired by that, to be inspired by the feedback from their users to write their own ambitions. It's important that they write them down, I force them to do it, but I don't choose what they are going to write. And I ask them to present it to me, to tell me about it. And in fact, it's a contract of intention, that is to say, I express my intention and they give me in return what they understood and what they intend to do to contribute to these intentions, to my intentions, in the particular context of their technology and their users. And I don't need all of my intentions to be reflected in theirs. There can be one that has nothing to do with what I ask. One or more. But it is necessary that globally, the meaning and the orientation are reflected. This contract of intention is very important because it is the key to autonomy. It is that once we agree on what we are trying to do. I no longer need to be in command and control. The intention, he declared it to me, what I am going to verify is that his monitoring system, his obeya, measures that he succeeds in his intention. That is very important, I need to see it. Because eventually I will also need to help him. Because it could be difficult. And so in fact, the abandonment of command and control, it is done for the benefit of this empowerment, of this declared intention and of the measurement system that allows to verify that I manage to do what I said I was going to do. It's very reassuring for everyone. It's reassuring for me individually, I've gained in serenity, I'm much less stressed. It's very reassuring for my boss because it's displayed in the hallway and that he comes to see and he sees. In France, we have the culture of the surprise inspection. A command and control boss, what does he do? He bursts in one day, asks a question on a subject, and if we answer well, it's good, it's under control, and if we don't answer well, it's not good, it's not under control, and then he starts to drill down. And in fact, it's catastrophic because we spend, we are constantly monitored, explored, etc. And to get out of that, in fact, you have to expose yourself considerably. The fact of sticking your performance on your wall kills the culture of the surprise inspection. It's very reassuring for everyone. It's reassuring for me personally. I've gained serenity, I'm much less stressed. It's very reassuring for my boss because it's displayed in the hallway and he comes to see and he sees. In France, we have the culture of the surprise inspection. A boss who commissions a control, what does he do? He shows up one day, asks a question on a subject, and if we answer well, it's good, it's under control, and if we don't answer well, it's not good, it's not under control, and then he starts to do a drill down. And in fact, it's catastrophic because we are constantly monitored, explored, etcetera. And to get out of that, in fact, you have to expose yourself considerably. The act of posting one's performance on one's wall kills the culture of surprise inspection.
[00:38:23] And then, of course, we relaunch a lean academy to give the 10 managers, or 12 managers who were in the academy, the necessary head start. So we are always in partnership with Opera, we are relaunching this academy with Sophie.
[00:38:40] Uh, I would like to share with you two measures on incidents. So you saw that there is a fairly significant quality problem. What you see there is the average number of severity 1 incidents, the very serious incidents that occur every month. So there are about ten of them, on average, and you see that there is a lot of variability. We have incident peaks at 18, sometimes we are at 4 or 6. So we can do quite well. But during the peak season, the moment when we need IT to work, we have an incident peak of about 18, uh, about 16, 15 around there. So we implement problem resolution, QRQC, user satisfaction, etcetera, and we have managed quite well. to stabilize this number of incidents. You see that right now, we are around, we have a minimum repeatable at 4. This is the objective for 2024.
[00:39:34] So that worked pretty well. I had a bad surprise when I look at incidents in their totality. Uh, what you see there is the average number of open incidents every month. Always the same definition, it's a user who calls support to solve a problem.
[00:39:52] We are at 610. I do as usual, I set a target of 1% every month, 12% at the end of the year, sometimes 10 when I neutralize August, December. And we reach it, we even overperform. So I'm very happy. We still have that peak during the peak season that displeases me, but it's improving well, the trend is good. 2023, it continues, we continue to improve and then bang, in June, bad surprise, the number of incidents goes up. I ask myself, is it an incident? Well, we get going, PDCA, root cause analysis and all. Then we analyze the incidents, but first, the data quality is catastrophic.
[00:40:27] It's super hard to read in the incidents what is the application, the group, etcetera. We don't see it well. And then on top of that, we don't find anything really striking. There's a release on the management tool in the centers that wasn't terrible, it caused 47 more incidents, but it's not very significant. Then the following month it continues to explode 789. A little break in August and then back in September, bang, it goes up even more. So it's all hands on deck, we do a very in-depth analysis of the thing. And we realize that, in fact, users had so little confidence in IT that they weren't even calling anymore to log incidents. They called a friend, they managed. There are centers that print every evening the complete schedule for the next day, in case IT crashes. Every evening.
[00:41:14] And in fact, what's happening there is that by dint of dealing with problems, we have recreated trust and users have started logging tickets again. There are no more incidents, but there are many more tickets. It's just that we weren't seeing them. We had a monstrous blind spot. So on one hand, that's very, very good. On the other hand, it poses two difficulties, which is that I had set a nice objective for a variable share based on the reduction in the number of incidents, and there, the situation, it's quite delicate and a bit complicated. Because it's very, very good that users log more incidents. However, behind each incident, there is a real problem that needs to be solved, there is a real quality problem. But well, the indicator, well, zero. There you go. So it's a moment when you have to be a bit strong managerially and believe in its approach of performance management, performance as the sole judge of the team's peace. Guys, that's it, that's it. There you go.
[00:42:11] Uh. So it continues to get worse, or better, as you like, we have more and more incidents, uh, ticket incidents, and we can work on the causes of our problems because now we see them.
[00:42:24] Uh, after a year of transformation at Euromaster, where are we? It's been a year and a few months now.
[00:42:31] So first, uh, you see the user satisfaction, so we don't have NPS yet, we're starting to have the first NPS measurements now. We make, uh, 13 points of improvement on Green Days, we went from 74% and our goal is 80. Uh, on product quality, uh, well, you saw, I can't measure a decrease in the number of incidents, it's exploding. But, uh, when we look at critical incidents, uh, that has improved a lot. You remember the peaks at 18, we don't see them anymore and now we are at 4. So we have not only stabilized the variability, but even improved the average. Time to market has also improved a lot, I didn't go into it, but the Mean Time To Repair has been divided by four. Uh, and on severity 1 incidents, roughly the same, we went from roughly two days to four hours.
[00:43:23] And uh, the success conditions. So there, I have two measures. Uh, Michelin, in the entirety of the group, conducts an annual survey of its employees to measure three major performances, which are. engagement, empowerment and managerial quality. And uh, in general, in these big surveys, we gain one, when we gain one or two points per year, we can be quite happy, and there we have increased by 10 points at once on uh, on engagement.
[00:43:57] Uh, if I look at the team mood, we don't have very clear gains yet. We are in the first year where we have variability there. You're not going to see very significant gains yet. Well, I hope they'll come.
[00:44:12] Voilà. And we have, I think, 10 minutes, a quarter of an hour left, approximately, to answer your questions and discuss the subject. Uh, Sarah has a microphone for you if you have any questions, uh, and, uh, and I'll try to answer as best I can.
[00:44:35] Hello, first of all, thank you for this very interesting presentation. I'm from France Travail and we're in the process of setting up lean, notably problem analysis. And I'm wondering about how you support the teams, especially for doing Kaizen in half a day.
[00:44:50] To do what, sorry? To do the Kaizen in half a day?
[00:44:53] And how do you support the teams in this work, in fact?
[00:44:56] Me as a manager, huh? Or globally in the organization?
[00:45:03] So, basically, me, me, the first thing is exemplary. That is to say, the resolution of problems on Thursdays at 3 PM is sacred. I, I, you really have to go every time. Uh, second thing, uh, is the problem-solving method. We tend to take shortcuts, a problem, a solution, and in fact, you have to learn to sit down to think. And that's what the PDCA or QRQC method helps a lot with. So there's a methodical aspect.
[00:45:33] where we're going to sit down to, uh, first, is it serious? What is the context, the process in which we are working? What do we want to achieve, what is the objective? Uh, what are the hypothetical causes and then the root causes? And when we've done that, we start thinking about the resolution, apart from the two or three urgent customer protection actions.
[00:45:54] And we will measure. We will measure that we are indeed solving the problem. Uh, and then, uh, there's a challenge I've always had in Lean, it's how to maintain the sacred fire of continuous progress. So that, it's, uh, I, I, apart from managerial posture, I don't know, I haven't found a miracle. In fact, it's something you have to maintain. It's like the hearth in a house, you have to add logs, you have to blow on the fire and all that because otherwise it goes out. I don't know if that answers the question.
[00:46:24] No, I'm not sure, well, I'm not sure I understood everything. Does the whole team participate?
[00:46:30] So, in the 3 PM session, the entire management team participates compulsorily, the IT management, plus the people who are concerned by the subject. Plus all volunteers.
[00:46:43] So among the volunteers, these are people who are interested in coming to listen to learn, in fact, uh, I don't make it mandatory. It's uh, and it's a bit the measure of the success of the thing. Uh, I don't make it mandatory. So typically, there we will find people who are far from the central office, people from other countries who come to listen because they learn a lot about how it works, and it allows them to explain what's happening afterwards. Uh, we will find curious people, and, uh, and that's it.
[00:47:15] Okay. So you have a part of problem analysis at the management level. Yes. And you have for each team, uh, a half-day dedicated each week for their problem analysis. Yes, exactly, Kaizen.
[00:47:27] Exactly. And the team, do all the people in the team participate? And how is the team supported to do this problem analysis during the half-day?
[00:47:36] So, yes, all the people in the team participate in Kaizen, that's mandatory, and the Kaizen must be done as a team, not individually. Uh, they are accompanied by coaching. At the beginning, the Kaizen, you have to leave it a bit free, because in fact, it has to be the moment when the team meets and starts working together on its problems. Uh, and as it gets set up, I use coaching to force the team to tackle formal problem resolutions. But not at the beginning. And very often at the beginning, they do very simple things, like describing who they are, talking about their identity, the projects they are doing, uh, making a success wall, things like that, it's not serious, it's not serious. At the beginning, it's an appropriation phase. And after a few months, you have to start to frame so that, uh, Kaizen is used for problem resolution. From my experience.
[00:48:30] Okay, thanks.
[00:48:37] Thank you for this presentation.
[00:48:38] Hello.
[00:48:39] Just, I would have liked to listen to you, to hear you on the topic of agility at scale, because we understand that you performed well, whether at Michelin or at Euromaster, within a DSI. So congratulations for that, for these results. How did it go with the rest of the company? The HR, what is your general feedback?
[00:48:58] So, uh, the Lean-Agile transformation at Michelin is essentially on the IT perimeter. It's not a transformation, Michelin is not an agile or Lean company, uh, but it is Lean compatible. That is to say, the fundamental values of Michelin are compatible with the Toyota Way. Respect for the customer, respect for facts, uh, all that, uh, respect for people, it's been in Michelin's DNA since the 1920s. And uh, and in fact, that created a welcoming ground for Lean. But to my knowledge, the essential part of the Lean approach, demanding in the sense of the Toyota Production System and the Toyota Way, this demand for measurement, for problem research, etcetera, we find it essentially in IT. Uh, on the other hand, what happens is that after a while, it's still quite impressive, the results, what. And it ends up being seen. And so, in IT, we work permanently with the business people and there are people in the business who say, but at the same time, I would like to do that too, I would like to learn how to do that. And so little by little in the academies, so we did several, we welcomed our business colleagues who worked with us every day. And so they did a PDCA and then in the business, the value of the PDCAs is hallucinatory, what. As much as in IT it's quite interesting, but when we start doing them in business departments, we get tens of millions of euros per PDCA. It's really impressive. So it's done by contagion, by, by, by replication, in fact, by exemplarity.
[00:50:43] Uh, thank you very much for the presentation, it was super interesting. I have a question, what I retain is that to lead this type of transformation, there is a certain level of sponsorship that is important. Uh, in this case, you, uh, and then, you were talking about your own transformation, which was brought about by a young person. Uh, when we lack sponsorship to change a company, do you have any tips to make sure that we can bring about a transformation even when the group doesn't necessarily think it needs it?
[00:51:14] Uh, that's very mysterious. What makes someone suddenly switch? In my team, we did an academy for a year, and there was one guy in the academy, one of the managers, who couldn't take it anymore. School, exercises, all that. And uh, Chloé at Eurofin had the pleasure of hosting us. We did a field visit to her materials analysis laboratory, which is Lean. And uh, and in fact, it completely transformed this manager. And two weeks later, he had done a visual management that was absolutely amazing.
[00:51:49] What happened at Eurofin? What emotion did this materials analysis laboratory create within the group? I don't know. Uh, but in fact, I think there is always a common element, an emotional shock. There's a moment, we see something, and we say, "Ah, yeah." And so I have a lot of respect for the Lean-Agile coaches because in fact, they have to create an emotional shock, uh, and it's very hard to do. Uh, one of the things Nicolas had done one day, to enter the Michelin headquarters site, there are some kind of turnstile barriers. We badge and we pass through this barrier. And, uh, one day. We had a steering committee at 1 PM, it was noon, we had to go eat at the canteen, there's always a bit of a queue, people, we were a bit late. Uh and then Nicolas tells me, "Here, can you pass me your badge?" I don't really understand why, I pass him my badge. He passes the turnstile, he stands on the other side and he waits. Nicolas, what are you doing? Give me my badge. He tells me no. Oh, that warms me up a bit. Nicolas, it's okay, give me my badge. No.
[00:52:52] I'm getting annoyed. Nicolas, stop your nonsense, we have a steering committee at 1 PM, we're going to be late, give me my badge. He holds the badge through the gate, he keeps it, he holds it and he tells me, "You see that? That's what you make your teams endure every day." What are you talking about? He tells me, "You see, when a DevOps does a release, a checklist as big as your arm, to be able to put something into production that he built himself and for which he created the process of end-to-end, that's what you do." When a project manager, he's obliged to go up three hierarchical levels to be able to move a blind, that's what you do. He hits like that, boom boom boom. I said, "It's okay, Nicolas, stop hitting, I understood. I understood." And in fact, uh, uh. You need a certain trust, you need a personality match between the coach and the manager. You need emotional shocks, moments of realization, and you have to create them. Uh. You still need someone in the company to be a sponsor of the thing, huh. At least the method department. Otherwise, uh, it's going to be complicated.
[00:54:10] Thank you. In the continuity, Nicolas, what mandate did he have on the project that was going to fail and that finally did not fail?
[00:54:16] Wait, I didn't hear well. What mandate on? On the project that was supposed to fail, Nicolas, what mandate did he have?
[00:54:21] Ah, none? It was, uh, it was a coach.
[00:54:24] Okay, but what was he allowed to do and not do, in fact? Was he allowed to apply his agility fully?
[00:54:28] Yes. No.
[00:54:29] In fact, I didn't care. He had carte blanche because anyway the project was going to fail.
[00:54:35] In fact, I had just put him there for him to wear himself out. Uh, so he could do what he wanted. Anyway, I wasn't taking any risks, I was convinced that the project wouldn't be on time. So, uh, at best, uh, at minimum he was wearing himself out, at best he was serving as a scapegoat. So, on the contrary, the more he did, the better it was. No, no, there, really, uh.
[00:54:58] After that, however, when we were transforming the program together, I had to understand, so it was a bit hard for him because he had to explain to me and that I accept. But, uh, and then on top of that, I had to carry it to the program management.
[00:55:13] Uh. Thanks. Behind.
[00:55:23] Thank you very much for the presentation, it's super, well, the flow, the explanation, the storytelling, it's great.
[00:55:28] Thank you.
[00:55:29] Uh, and especially on the part, effectively, uh, uh, people, let's say, team, which I don't often see in Lean, effectively, this measure of mood, following the mood like that, it's often Lean is a bit cold, and I think it brings a bit of warmth to the team.
[00:55:45] Uh, that's why I wanted to ask you, effectively, it was about, uh, uh, Nicolas, in fact. Uh, when he, he went over the program and, well, for you, it was that 'AHA moment', that is to say, the moment when he made his project that was the emotional shock, or did it happen gradually?
[00:56:08] No, it was a shock from a, well, you have to realize that at the time. I don't know what a Gemba is, I manage from my office, uh, or from a meeting room where the project managers come to do reporting. I never set foot on the shop floor, it's quite rare. And when I do, it's because I'm doing surprise inspections, core sampling. So it's not a good sign. And uh, and so, there's this crisis of confidence at some point between this project that I'm told is going well and me being convinced in the reality I've built in my head that it's not going well, in fact. And I do what I call at the time a low-altitude pass, in fact it's a kind of Gemba, but and I go there and and there it's, I hadn't seen all the post-its, all that, the wool strings.
[00:56:49] Uh, the team that collaborated so harmoniously, all that, these are emotional shocks that really happen in, in, in an hour, what. No, it wasn't, it wasn't progressive. Then after, the learning of why, how it works, the methods, what needs to be changed, all that was long. It's, it's, it's two years in real life, approximately, what. Uh, but the shock is immediate. In my case.
[00:57:14] Thank you.
[00:57:16] Thank you. Thank you.