[MUSIC] Transformation of an IT department is about changing its operating model. I believe changing is changing twice. First, changing in your mind. Then once you're convinced changing in the reality. When you want to change in the IT department, you have to convince all the stakeholders. The corporate management, of course, because they will have to support this transformation program. You will obviously take risks. Your business colleagues, because they will have to understand that you are going to change the way that you operate with them. And three, of course, your teams, because they are the ones that will be mostly impacted by the transformation. So, how to do that? You have to build a diagnosis, that is shared by the whole organization. Where am I today? Where could I be? What could I do differently? Looking at benchmarks, looking at what competitors do, looking at what other companies do. Looking at what the business would like you to do. Once you're clear on your starting and where is it that you want to go. Then you can start to define your roadmap. The transformation should be built around three dimension, cost is not enough. It's not compelling and it doesn't bring enough value. One, can I bring more service to the users? Two, can I create more value and better contribute to the business success? Three, can I be more efficient? And does that bring savings? This is the difference between a transformation plan that will impact the way you operate and bring more value to everybody and a cost cutting program that will just cut the costs. But not changing anything. Just making the reality of your team more difficult. So, on those three dimensions, what could be the target? On service level, you will use the usual KPI's such as number of incidents, time to resolve them, user satisfaction. Even if there's no absolute value in terms of user satisfaction, looking at this starting point and defining target and looking at the progress is already a program in itself. Second, around value, how do I bring more value to the business? Could be around a better percentage of a project milestones met. A better percentage of business case realization, this is a bit tricky, but worthwhile implementing. And of course, it's easier. If we want to just focus on that for a moment, I'd say it's important to set a target that is ambitious enough, but not too ambitious. If I'm too ambitious, let's say I want to do 35% in figures, this is not credible. The teams, they'll think its a joke. They will think at the end of the day we will forge the number so that it looks like success but they know it's not achievable, and maybe the CIO will not stay until the end of the program. If it's not ambitious enough. Let's say 10% in three years. This very much looks like continuous improvement. You just have to do a little bit of cost-cutting. You squeeze a little bit the service provider, you kill one or two projects, and you're done. And nothing's really changing. So very often, we say relevant target is between 20 and 25%. This is enough to really stretch yourself so that you have to reinvent your operating model, and we find this is the right balance between very ambitious and not too ambitious to really transform. We feel if you want to be succesful you will have to steer the program. This is not only about saying, okay, we want to do 25% in three years from now, and good luck. See you in three years. This is about building a road map on a monthly or quarterly basis with tangible milestones. I'm going from 75 development centers to three back offices. I'm going to 120 service providers to 12. I'm going to 24 data centers to two. These are tangible milestones, and you can see the progress along the month to make sure that you are making this transformation at the right at pace. If you want to be successful, you definitely have to buy the teams. Because the teams are the one that will be impacted by the transformation and are the ones to implement the transformation. So what's in it for them? And actually it's one of my best moment when you design a transformation, to think on what's in it for them and to convince the team that it's really going to bring value. And again, this is the difference between a cost cutting program and the transformation program. If you do this transformation right, some of the savings you can reinvest in changing their lives. For example, changing obsolete infrastructure items that fail all the time. For example, hiring top notch guys on strategic domains. Also it's really something that they can be proud of because they did it. Because they used to be a cost center where the business would say you're not good, you cost too much to a value creation center. Thank you, this is great, you are helping us taking the business to the next level in the digital world.
