Michelin is the world’s leading tire manufacturer, with net sales for 2010 of €17.9 billion. As well as producing 150 million tires per year, the group also prints 10 million maps and guides — and, famously, awards top restaurants its much-coveted stars. Headquartered in Clermont-Ferrand in central France, it has 72 plants in 19 countries and marketing operations in 170 countries. Recently, one of its major objectives has been to align global, integrated IT activities more tightly with business priorities by promoting stages terrain (field courses) for the IT teams and applying such approaches as agile methods, a centralized enterprise architecture and “master applications.”  The result: an IT organization that is more responsive to the needs of Michelin’s 50,000 users.

How has Michelin structured its IT operations for maximum global IT integration?

The first step was to create a small enterprise architecture team, of just six to eight architects. These architects work closely with the Direction de Performance, which is in charge of defining the business processes and the related best practices in their respective domains. They are centrally located in Clermont-Ferrand 
and cover all the functional domains — marketing, sales, manufacturing, R&D, supply chain and logistics, and so on — and they define the IT solutions and the associated worldwide roadmaps in their respective fields. These global best practices and the corresponding IT solutions are then used and deployed wherever we have operations. So it’s all about building roadmaps and proposing potential solutions that fit with the global structure of the Michelin business.

How does this work on a local level?

To cover our worldwide presence, we have five IT organizations that are in charge of deploying global solutions locally — not rewriting them, but integrating them within their own legacy environment. Local teams have a platform architect, who is more focused on operational architecture, while global architects work much more upstream with colleagues from the business functions. Their job is to be aware of market conditions, the general business environment, and which kind of new solutions and technologies could be of interest to Michelin. This structure was established by my predecessor, who created this consolidated organization from what was previously a very disparate IT operation.

How have you built on this since you took over as CIO?

Our main objective as an IT team is to contribute to the company’s overall performance. The globally integrated structure and principles were already in place — what I added, when I joined as CIO in 2008, was building greater proximity to the businesses and introducing some flexibility in the IT processes. IT is not outside of the company — it’s inside the business.

How did you achieve that?

I insisted that my team shouldn’t consider themselves service providers for “clients” within Michelin. We do not have clients. We have colleagues who need information systems and technologies to meet their objectives and, if we want to provide the right solutions, our contribution and their contribution are equally essential. So, from the enterprise architects downwards, everyone works very closely with their business colleagues. I want IT managers to have personal objectives that are measured against business performance — not just IT performance.

Can you give an example of how this works in practice?

Something that has helped recently in this area is the use of agile methodologies, which requires teams to work very closely together. I insist that my IT people spend time in the field with sales people, industrial teams in our plants, supply chain managers, and anyone who is a big user of IT. The objective is to deliver a solution — or at least something that clearly demonstrates what the solution could be — through successive interactions, within three to four weeks. Working like this, the IT team’s business colleagues fully acknowledge that asking for the smartest solutions is absolutely useless if they’re unable to state their requirements clearly enough. But the proximity of the teams, and the fact that they’re sharing day-to-day experiences with their colleagues, can help with that situation.

What kind of business value has this approach delivered?

We’re quicker at delivering solutions and have a much better understanding of the business needs. The result is that IT is a major contributor to the performance of Michelin.

And what kind of solutions have been deployed this way?

Michelin is very innovative in its core business, which is about making great tires. We aren’t necessarily as innovative in IT — by that, I mean we aren’t always looking for the latest technologies. Rather, we’re looking for proven technologies that will provide the expected service. An example is our collaboration initiatives: we’ve put a strong emphasis on very simple tools that everyone can use easily. We have a simple tool that allows us to share documents relating to a project, a management team, or whatever. We’re a global company with teams spread all over the world, so we’ve installed audio and videoconferencing tools, which have saved time, money and carbon emissions. But we’re also able to ensure these tools take into account our security and confidentiality requirements, because the IT people understand clearly what these needs are.

How do you ensure your global IT solutions are adapted to different market requirements?

We have globally deployed “master applications,” and in order to protect the core solution created by this master application, we’re currently adjusting our delivery model. This means that localization — for example, adapting solutions for local fiscal requirements — will now be taken into account very early in the process and not during the deployment phase. Last year, we also started a huge ERP-based project. In each stage of the project, we’re ensuring that local requirements, based on specifications and regulatory issues, are taken into account. Locally, we’re focusing the integration work only around the interfaces with the legacy pieces that remain after the deployment of the solution.  But it’s also about discipline — everyone needs a strong desire to protect the concept of the core solution as far as possible.