Lean Expert Interview : Catherine Chabiron

A graduate from HEC Business School, Catherine Chabiron has been Lean Office Manager at Faurecia for the last ten years or so after having worked in many different areas such as Marketing, sales, accounting logistics etc … Faurecia is a world top 10 automotive parts manufacturer. While driving the Lean implementation in their IT department, Catherine has had a major contribution in aligning Faurecia IT with the business. She also is a major contributor to the Lean community worldwide as her talks at Lean IT Summit 2011 and 2013 showed.

Her description of how Lean management matches her expectations in terms of management method resonates particularly well with #hypertextual evolution of centers of interest  :

When I discovered Lean management (…), it looked like everything I had seen as being common sense and best practices up to then, unfolded into this management approach.

#hypertextual is very glad she discusses all this and more in this interview …

Hello Catherine, thank you very much for this interview. Could you please introduce yourself and tell us how you get to the Lean topic ?   

My whole work experience has geared me towards Lean, and particularly Lean Office. I have held positions in Marketing and Sales, Accounting, Logistics, Controlling, Internal Controls, IT, I was lucky to be able to move around quite a bit in my career, geographically but also in different jobs, which is not so obvious nowadays where we tend to career up in silos.

I had learned an efficient use of the scientific approach for risk management and problem solving in an earlier position: try to assess the risk (the problem), evaluate the causes and address them.

But when I discovered Lean management in the automotive world, it looked like everything I had seen as being common sense and best practices up to then, unfolded into this management approach. It took me however quite some time to actually grasp the full scope of Lean and start seeing the pitfalls we need to try and circumvent. And I did not escape some of them…

Lean provides a collaborative approach where teams own their own performance improvement, learn to master their delivery and do not depend on bosses or remote process experts to solve process issue

What do you think Lean thinking can bring to IT Organisations ? What have you witnessed in that respect in your own ?  

It is a huge advantage for a sound IT governance. Lean tells you how to organize focus and show the true north (customer satisfaction in terms of quality, delivery and cost). Lean gives the means of an efficient continuous improvement (absolutely necessary in a fast IT changing world), through a scientific approach of problems and knowledge transfer via shared work standards and an endless data and fact collection where things happen.

Lean proposes a more agile delivery through reduced batches, more frequent releases, customer pulled enhancements (user cases). Lean lastly, and most importantly, provides a collaborative approach where teams own their own performance improvement, learn to master their delivery and do not depend on bosses or remote process experts to solve process issues, but grow and learn as they do so.

We have thus progressively moved from an IT provider to a partner

There was a very strong paradigm in your LIS 2013 presentation which echoed Dan Jones statement in his keynote : “we had to move from a technical push mode IT to a customer process focus pull mode IT”.  Can you please elaborate on this statement, what is at stake and how you implemented it in your Faurecia IT ?

Well this is really where we are coming from in Faurecia. 10 years ago, IT was a fragmented activity, embedded in each Branch. The only transverse IT we had was focused on infrastructure and operations. Those are background technical activities and, as such, rather far from user daily life and needs.

It was then decided to group all IT employees as one transverse function, independent of the Branches, with a customer focus that would better serve the interests of a Group that was promoting lean in manufacturing and product development, fast growth and needed IT to adjust quickly.

This is what we have been working on over the past 7 years. We developed a rather intimate understanding of plant flows and issues, by being closer to users but also through pollination, as plant managers, logisticians, lean manufacturing experts moved over to IT. We regularly participate in logistics steering committees that help us understand the latest improvements they seek. We co-animate continuous improvement workshops in Finance or Payroll Shared Service Centers to get a better grasp of their daily concerns.

We have thus progressively moved from an IT provider to a partner, at least on the Finance and Manufacturing side (not there yet on the product development side). And because we know the customer expectations, and can sometimes even anticipate them, we believe we are much closer to a pull mode (work to serve customer needs) than to a push mode (push a new IT release to save time and money on support and operations and hope the users will use it).

An other illustration of this can be the very deliberate choice we have made of insourcing most IT services rather than buy on-the-shelf IT solutions. We have done so after a number of significant disappointments either on the software we bought or on the capacity of the provider to support it or both. This is particularly true of plant systems, where an outage can stop a just-in-time production line and impact the final customer, but the same can be said of reporting tools or critical product design tools. As we insourced, customized or developed our own tools, we found ourselves in a better position to adjust the tools to the user needs.

We have now to ensure the core functionalities IT propose are ergonomic and intuitive

You insist in this presentation on the role of Ergonomy to provide leaner IT services. Can you please explain this and how does this align with the Lean UX approach evangelised by Jeff Gothelf ?

We have successfully developed a number of standard worldwide applications, but we know those to be only the first stage of our effort : we have now to ensure the core functionalities they propose are ergonomic and intuitive. Most of those applications were developed and rolled out with a traditional waterfall approach, as we are more customizers of software, than real software developers.

But we have one or two examples of successful developments with a close cooperation with users (sketching, prototyping, checking, refining etc …) and in quick iterations. One of the latest was a series of quick wins on screen ergonomy, similar to the Lean UX approach you mention, and that was a real success with end users.

Problems are not bad news. Problems should be welcomed because they are an opportunity to learn and change something in our way of work

You are very serious about tracking Customer Satisfaction. How would you explain that many IT organisations in big companies are reluctant in doing so ?

We are tracking user satisfaction on the support every time we close incidents. We also measure satisfaction on training (we have developed remote webinars allowing user interaction with the trainer, rather than eLearning). We also regularly, but not often enough, seek the user’s opinion on the application itself. We are currently discussing a survey at the end of each change delivery, with the user who submitted the initial request.

Another example is when we create a severe failure in a plant, ending up in a customer impact (late delivery for example) : a red alert is then launched by the plant. The problem solving we launch as a consequence is reviewed and challenged by the Industrial Executive Vice President himself, so we can immediately measure how efficient or relevant we have been on the subject. So in short, many opportunities to measure our progress (or our failure) in doing so.

I think the reluctance to track customer satisfaction may stem from the fact that problems can still be seen as a negative feedback. Taiichi Ohno used to say that a production line that never stops is either a perfect line or a line with problems. In the latter case, he argued, if the line never stops, it means problems are never popping up to the surface. And from his point of view, this was very dangerous : bad quality is passed on to the customer, and we miss a chance to understand what happened then and there.

Problems are not bad news. Problems should be welcomed because they are an opportunity to learn and change something in our way of work that was maybe not sufficiently adapted or efficient before that incident.

We believe in insourcing rather than outsourcing, to maintain in house competences on our core services

You have a very challenging target of IT costs significantly lower than your competitors. What is your main strategy to achieve this target ?

We have indeed managed to transform our IT while remaining within the same low % of IT costs vs revenue, and we intend to improve on it. The answer is two-fold :

• We believe in insourcing rather than outsourcing, to maintain in house competences on our core services. As the Group was growing fast, we could not afford to develop those competences in Europe, where our Group stems from, we wanted to develop them mainly where the growth was taking place (Asia, North and South America, East Europe). The reason for that was also the need to be more reactive in terms of time zone (follow-the-sun, follow-the-calendar support). So we had to be creative on how to develop new IT services everywhere in the world, with new and sometimes junior teams, that would ramp up quickly to the expected level. The result of it, in all the benchmark studies we have conducted, is a lower IT cost than most or our peers.
• The second key factor was to move from a patchwork of heterogeneous systems to standard applications (re-use), centrally managed and maintained (and centrally does not necessarily mean European-based), while developing local proximity to users to capture needs and check relevance. We have done so on all our key systems and we believe this was a key contributor to a low cost IT. This can however only be lean if we permanently maintain a local contact with users, recognize the shortcomings of our solutions and regularly integrate improvements and new needs in our standards.

A3 is a fantastic coaching tool, and an opportunity to develop people by giving them a chance to observe, collect data, learn about complex flows of products or data, gain agreement from others on both the causes and the means to address them.

Talking about A3 : you are an expert on the subject (I was lucky enough to attend your masterclass). Can you please tell us how this tool allows to develop autonomous teams (another objective you describe in your session).

The A3 is just the printing format of the supporting template. What is interesting is the underlying scientific approach to problem solving. It starts with the simple concept of PDCA (Plan, Do, Check, Act) and the assumption that a company will be far more efficient if it is :

1. a learning organization
2. relying on all employees to learn and grow, rather than on a few executives.

So the story told on one A3 page has turned out to be a fantastic tool serving many purposes :

• Develop a focus on fact and evidence and a real capacity to waste elimination : the limited space on an A3 format forces you to streamline and eliminate blabla, judgements and opinions, replace long sentences by drawings or flow charts, concentrate on the objective and stay on track.
• Efficiently solve a problem using a scientific approach : problem definition, data collection, potential causes, experiments to eliminate some of those and confirm others, dig down to the actual root cause of confirmed factors, address it, check the result, re-iterate if need be, and close through a change in our way of work so as to make the performance sustainable
• Observe someone documenting a problem solving on an A3, and as he or she does so, coach him or her on the traps, data collection, factor elimination etc … A fantastic coaching tool, and an opportunity to develop people by giving them a chance to observe, collect data, learn about complex flows of products or data, gain agreement from others on both the causes and the means to address them.
• Gain agreement on a solution or a strategy. In its ringi format in Japan, it is the document that circulates from hand to hand or group to group, to secure agreement or collect suggestions on a given approach. The Ringi-sho is an A3.

In its simplest form, a line on a paperboard, describing what is the problem, the potential cause, the action, by whom, for when and the results, it becomes the daily tool for performance correction in a team. If the team cannot solve the issue, or if the factors lie beyond its immediate influence, then the problem will be escalated to an A3 format.

Thus team autonomy starts by the capacity to spot and solve simple problems, within the team’s area of influence, and to maintain or improve the team performance as they develop and improve their work standards. Each problem becomes an opportunity to create or challenge a work standard so that the problem does not happen twice.

Cost effectiveness is one of the targets of Lean, but it will be an end-result, because we have saved on lead time, reduced stocks and wastes, made our customers happier, improved the quality of our products (…) It should never be a starting point nor should Lean be reduced to a productivity approach.

Lean has been having a rather bad reputation lately in France (cf this article in newspaper Le Monde [FR]). How do you feel about this ? How do you interpret sociologists showing a very bad image of Lean ? How would you answer ?

I can’t blame sociologists or unions describing the alleged black side of lean when I hear how some seem to twist the approach. If I refer to the article  you mention, I would like simply to highlight two quotes from it.

In that article, Yves Clot from CNAM confirms taylorism was implemented late, post World War II, in France, possibly more brutally than in other countries. He says : “the same thing is happening now with lean : managers are tempted to push through with productivist versions of the approach.” P. Davezies from Université Lyon I completes it : “Consultants should realize that lean is twisted because this  is what happens with all management fashions : out of a given corpus of practices, leaders pick up what serves them best to promote their strategies.”

Back in the 80s and 90s, the fashion was to launch re-engineering projects. I see those same re-engineering approaches come back, with the same clear productivity objective, but they are now sometimes labelled  kaizen events or lean workshops.  This creates confusion on what Lean Management really is.

Cost effectiveness mind you, is one of the targets of Lean, but it will be an end-result, because we have saved on lead time, reduced stocks and wastes, made our customers happier, improved the quality of our products, consequently increased our turnover, developed learning organizations who will promote continuous improvement etc … It should never be a starting point nor should Lean be reduced to a productivity approach.

We will have to see whether social networks within our IT communities can also help in sharing knowledge

You have been investigating new collaborative online tools and communities lately. What would you expect from such tools and how, from your perspective, it would help to make the company leaner ? 

We are firm believers in the need to learn from your own community of practice.  We are extensively using sharepoint today to that effect.

With new generations of IT employees on boarding, we need to think whether we have the latest / most adapted tools, hence the idea of investigating wikis and check with other IT communities whether the idea of creating an internal IT wikipedia makes sense for some of our activities (support, helpdesks etc ..). And beyond, we will have to see whether social networks within our IT communities can also help in sharing knowledge.

However, those are mere investigations at this stage. Whatever tool we take, spreading knowledge and learning from each other will always boil down to simple questions :

• who will write and contribute to the knowledge sharing ?
• who will check and screen the knowledge compilation to avoid spreading errors
• who will ensure the community is active on this ?

The Lean community has started transposing lean management concepts into IT management

Last question regarding the Lean IT Summit. You have been talking in all 3 Lean IT Summit editions. How do you perceive the evolution of the conference ?  

I only talked in the first and the third editions, but I attended all 3. The difference between the first and the third is very visible : in the first conference, we had the agile community listening to Lean management gurus, and vice versa, with practitioners on both side trying to figure out what agile and lean had in common.

In the third one, we have clearly started to bridge the gap and understand each other much better. Lean is learning from Agile, just as Agile started from Lean concepts. The Lean community has started transposing lean management concepts into IT management. The workshops are showing a vast diversity of applications and content, from software development to data center management and support, not to mention IT in an NGO, where stakeholders are not unhappy users, but remote farmers in severe conditions depending on IT to prevent starvation.

I am very confident we are all on the right path !

Catherine thank you very much !