[MUSIC] Along the course of my discussions with many CIOs, I tend to see questions around organization coming back and forth. Should we be centralized, should we decentralize? Should we be organized by businesses? Should we be organized by technologies? What do we want to put off shore? By the way, how far should our internal resources get involved into execution and delivery? And what should we leave to outsources? There is no single way to define the right IT organization. I'd say there are three items to be kept in mind. The first one is what is the company expecting from me. If I have to reduce the cost dramatically, maybe I have to centralize. If I have to be more agile, more adaptable, maybe I have to decentralize and get much closer to the business. Then the second item is, you never start green fields, you always have a legacy landscape. If you start with a legacy, that's very fragmented with lots of applications in every country, in every technology. Then you very well know that you cannot centralize very quickly all your organization. Because you have to manage your transition where the resources with the knowledge that you might have kept locally will have to be regrouped. And then the third item you have to keep in mind, is that you should not design an organization that is contradictory with the organization logic of your company. If your company is organized by region, the decision rights are in the regions. The needs are expressed in the region. It's more difficult to make an organization of IT by business lines work. It's going to be more challenging. Very often, given the business dynamics, it's a sound practice to change your organization every three to five years. Because the business very often has changed its organization. One new business line switched from business line to by region organization. New functions and grouping. So it's good to follow. And also it's a good way to rechallenge your teams outside the status quo. Now if you want to think about IT organization design, you have to think beyond the organization structure. It's not only about the right boxes and the right hierarchy. You have to think about your decision buddies. Who decides on what? What are all the right committees? What are all the right decision processes? Do you have the right control loops? On economics, on architecture and technology, on security, on project portfolio. Then you have to think about your processes. Do I have the right project management methodology. Do I need one? Do I need two or three? And last but not least is around how to make people engage, lead, take risks. Do their job and be on their job. And this is about defining the right, what we call organization enablers. You will will have the right role mandates, I know what's my role mandate. I know my accountabilities, I know what the others role mandates and accountabilities are. I know my rights, I know his rights. So we know how to operate. We have the right KPIs that are aligned with our strategy. We have the right reward mechanism. On that, Antoine will show you much more details and concrete examples on how to articulate those organization enablers. To make the whole organization structure processes and governance work together.
