NOTES FROM THE GEMBA – Somfy’s R&D department is applying Lean Thinking to close knowledge gaps, improve collaboration, and boost innovation and technical competence.

Words: Catherine Chabiron

Leading the market today doesn’t mean you’ll stay ahead tomorrow. This is a constant challenge for Somfy, a French pioneer in motorized shutters and today a worldwide specialist in connected equipment for the home – from shutters to blinds and curtains, from gates and garage doors to locks, heating, lighting, cameras and alarms.

I have travelled down to the French Alps to visit them, more specifically to Cluses, a town with a long tradition of supplying the nearby Swiss watchmaking industry (Geneva is only 45 kilometers away).  In 1969, as bar turning and high-precision machining thrived all around them, Somfy invented the tubular actuator (motor) that would replace man-handled cranks in shutters.

I am meeting Sebastien Fonta, R&D Vice-President at Somfy Group, and Jean Christophe Deshayes, R&D manager. Some of the R&D teams have, over the past two years, experimented with Lean Engineering, and I am eager to learn what they have changed and learned. Sebastien has a past in operations and is, therefore, familiar with lean in manufacturing. When he moved to R&D, however, he discovered that the pace of projects, the interdependence between complex deliverables, the variability of task content, and the technical issues made it very difficult to apply manufacturing flow performance concepts and tools. This is the reason Sebastien and Jean Christophe secured the help of a lean engineering sensei and author Cecile Roche.

INCREASE PRODUCT COMPETENCE

To learn more about this new approach, accompanied by Jean Christophe , I go pay a visit to Linda, who manages a project that is representative of what the teams have achieved over the past two years. Jean Christophe is the enthusiastic facilitator of the lean engineering approach at Somfy R&D.

In line with Somfy’s current R&D strategy, Linda’s remit is to create technical objects that can be re-used from one project to another (referred to as “technical bricks”), to prevent hazards from new equipment, save time in development, and reduce costs. Right now, Jean Christophe tells me, roughly 20% of the 120 projects R&D is working on are brick developments, while the rest is new products or new solutions. Solutions are typically the combination of different products – actuators, sensors, software, box connections – that are designed to solve an end-user problem. An example is a connected window that opens automatically to air the room when the sensors detect the need.

Bricks can be developed on cycle, as part of a new product or solution project (Linda’s brick, for example, is being created on cycle together with an interior blind solution): the theory on the brick is confronted with reality as it must be delivered in parallel to a real-life project for a customer.

Alternatively, bricks can be developed off-cycle, with less time-to-market pressure but with the risk that the brick’s irrelevance to the market is detected too late.  

Linda explains that the brick her team is working on is a small motor for interior blinds: the tube below contains the motor itself, the gearbox (reducing the motor speed from 3000 rpm to 20 rpm to create a torque effect) and the control card. She has brought a prototype so that I can understand the different parts involved in the design (a good design engineer will always have the product in hand when discussing issues).

When Cecile, their lean sensei, stepped in, the motor brick project was creating tension as it was running late, thus jeopardizing the overall project delivery. The team was under pressure and far from serene. According to Jean Christophe, Cecile wasn’t surprised. “We have been able to work on causes related to planning changes since then, and as she predicted, most of the actual planning shifts issues we have stem from late changes, new technologies or both”. Key decisions must be handled as early as possible in a project to contain costs and stick to the scheduled time-to-market.

Cecile decided to focus the team back to the customer’s key value expectations.

Assessing such expectations is often a real challenge in engineering, as design engineers rarely meet the final customer. Somfy’s final customers are the end-users of the blinds or shutters, but there’s normally a “middleman” delivering the solution: shutter or gate providers, for example, will incorporate the motorisation inside their own products; dedicated installers will fit it to new buildings or existing homes; DIY or online stores will deliver motor, sensor, box connection units. Top customer issues, if any, are handled by Somfy quality engineers, not R&D.

Linda confirms that, despite this, they managed to bring in marketers and have them sit around a table to discuss end-user expectations. Not surprisingly, the noise came up as a key point of attention:  since they design a small motor for interior blinds, the motor must be as close to silent as possible. Unfortunately, the prototype motor was not, but they were not sure why. This is typically what Cecile calls a “knowledge gap,” something must be identified and eliminated as early in the project as possible.

IDENTIFY AND ELIMINATE KNOWLEDGE GAPS

They engaged in a thorough problem-solving session, and that meant looking at all the elements inside and outside the tube, such as the remote control of the actuator, trying to understand how those would impact each other.  This led the team to complete a causal influence diagram, showing which decision on material or design impacted what. Causal diagrams are a key step in problem investigation as they enable a thorough analysis of all the potential factors. From there, it’s possible to discuss which hypotheses one wants to test.

Causal influence diagrams are also a key process to better understand a product, its interdependencies, how the options and decisions made at one stage could impact other parts of the product and its overall integration. Lean in engineering has really taught us to focus on “what we don’t know,” and to dig deep until we can make the right decision.

It turned out that the noise issue had mechanic causes, which could be corrected quickly. Linda smiles: “This was an eye-opener. It offered a systematic approach to spot our knowledge gaps, forced us to talk and learn from one another, to write down what we knew and what we were not sure of.”

MY SOLUTION IS OFTEN SOMEBODY ELSE’S PROBLEM

Causal trees are a great opportunity to increase competence when you manage to talk to experts from different systems (things like mechanics, electromagnetics, or software in this instance). All the project leaders I talk to during my visit to Somfy say the same thing: you learn about your own trade when you start thorough discussions on causal influences and interfaces with experts. The only difficulty, Linda says, is to “gather experts around a table. They’re all very busy and will only show up if we have an issue.” Then again, isn’t it what jidoka is all about? Spot a problem (a knowledge gap), pull the andon, and investigate with knowledgeable people.

Confronting different points of view from different stakeholders can be extremely useful in a project. Linda says Cecile urged them to work on changes, which are of course necessary in a project, but can become quite the headache. Design changes that are not properly communicated can lead to unforeseen results. Scope changes required by stakeholders (from customers to marketers), if systematically agreed to, can jeopardize the project in terms of quality and timing.

It is, therefore, of the utmost importance to ensure that all changes are tracked, whether they are deemed minor or major, and discussed, and that all stakeholders are allowed to check the impact on their own deliverables. Linda used a simple template but found to her great surprise, as they completed it, that a change in material on the rotor axis had been decided without the expert being aware of it. Electro-magnetic and motor performance could be at stake.

Linda confirms that the template is still regularly used by the team and that discussions continue. When they reached the prototyping phase, they had noise once again but soon managed to find the causes:

• The prototype’s assembly had been a quick and dirty job, as they wanted to show the software expert what they expected from him. Forcing the parts down the shell had distorted some of them, thus creating the noise.
• The software used for prototypes was not sending the right signals.  

Jean Christophe agrees: “Tracking and discussing changes has another advantage. We have seen people become very emotional during projects, claiming they were not listened to and predicting we would fail. Cecile made them work on their own assessment of the risk’s probability if nothing was done, then on possible countermeasures, then again on the risk’s probability once the countermeasure was in place. This proved to be a great way to show empathy while bringing the conversation back to facts and data, and a good start to further pursue discussion and collaboration.”

A SEQUENCE OF KEY DECISIONS

Projects are too often reduced to a sequence of deliverables, of things to do under a time constraint. A project manager will feel they are either permanently waiting for others or drowning in new requests.  

We already saw with Linda how Lean Thinking helped her create opportunities for collaboration at regular intervals and in-depth conversations with key stakeholders about knowledge gaps, problem solving, changes and associated risks.

But if we dig deeper, we will soon start to see a project not only as a series of deliverables (you do have to produce CAD, documentation, bills of materials, quality control, tests), but also as a sequence of decisions on the product and the process. I can almost see those of you who are familiar with projects in engineering or IT raising their brows: “Yes, we know that, isn’t it what project gates are supposed to do?”

Project gate systems, even when designed with the best of intentions, soon turn to bureaucracy. This may not be true in your case, but passing the gate will often mean producing the correct quality documentation or a load of specifications rather than discussing actual technical options on the product or the architecture that best fulfils customer expectations.  

Cecile asked Linda and the team to work on those technical decisions, even if the project was already well on its way:

• Which knowledge gaps do we still have (on what customers expect, on the product, the software, acoustics, etc...)?  
• When will we solve them and what decision will we need to take then? Cecile encouraged the team to envisage several options – a counter-intuitive approach since our brain wants to save energy as soon as a solution has been found and move quickly on to the “doing” part. Once several options were on the paper, the next decision was how and when to choose one, or whether the team needed to work two of those in parallel as they were not yet sure which one was the best and then decide.
• What sequence of technical key decisions should we consequently adopt? Are some of those dependent on others? Which one comes first?  

Working on the sequence of technical key decisions is another opportunity to re-focus on the customer, the usage, the learning. In other words, to take a step back, away from the endless list of deliverables.

INCREASE COMPETENCE ON COLLABORATION

This collaborative effort on the key technical decisions sequence is the backbone of pull scheduling.  As mentioned above, the traditional way to look at project delivery is the completion of tasks at given due dates. Conversely, pull scheduling will focus on the flow of knowledge, at far smaller time intervals.

In the example below, extracted from Cecile’s book The Lean Engineering Travel Guide, you can see the interaction between key decisions and how units of knowledge paced at regular intervals will be pulled to take that key decision. The Antenna team (in green) needs to decide which power transmitter to use by the end of Week 18 and will pull from Manufacturing (in yellow) the result of the comparison between 50W and 100W power transmitters. To that effect, Manufacturing will have pulled from Antenna the environmental constraints by the end of Week 17.

Discussions on pull scheduling had a great effect on Linda’s project team:

1. Pull scheduling provides sense and direction because all the activities are directly linked to the key decisions to be made.
2. They clarify when a piece of information will be needed and what for. This will require discussion (maybe even negotiation) but will create a sense of commitment once an agreement is reached. It’s a true exercise of cognitive empathy: you may not feel the same way as the other, but at least you understand what it feels like.
3. They involve all stakeholders, not only the project team core team.

In other words, pull scheduling triggers collaboration on the right subjects, just as jidoka on an assembly line focuses management’s priorities on quality (“There is an issue with that part”) and delivery (“I can’t do the assembly in time”), rather than plant meetings, an internal process to be improved, or a report to be prepared.  

In addition, says Linda, “we log the result of each key decision, and the reason why, as soon as we make one. If problems occur at a later stage, this is a reliable traceability tool of the choices we made and when.” Not to mention a great opportunity for knowledge capitalization.

Focusing on the key decisions and the pull scheduling to achieve them is another opportunity to sit together and reflect on scope changes: how do these affect our sequence of decisions? What additional knowledge gap do we need to address? Can we do it and still keep the project on track? Can we postpone the scope change? If not, what else can we postpone?

TEST ONE, LEARN ONE

“The project moved on more serenely after that,” says Linda. It is now in the industrialization phase and the internal customer – the project manager for the interior blinds’ actuator – is now much more confident in the motor’s performance.

When prompted, Linda recalls another final interesting session with Cecile: they needed to test the full viability of the product, components and all. But it seemed no one felt responsible for the final integration testing. This is a real issue in projects, since you must divide the big elephant (the final product or solution) into small parts for two reasons: first, a specific technology (mechanics or software, for example) will require the appropriate expert; and second, you simply need to make the big project easier to manage by cutting it into chunks. In the end, however, you must test the integration of the different elements and check whether the whole set is working as it should.

Linda shows me pictures taken at the time: “Again a great collaboration moment. We started drafting the sequence of tests, just as we had done the sequence of decisions, so that we would bring in one new module at a time. As Cecile phrased it, ‘you won’t learn if you test everything together, you need to do it step by step and learn from any mishaps’.

As we leave Linda, she shares one final reflection with us: “We can’t continue to deal with problems only as they arise and be rocked in the boat when they do. We need to take time early on, with all the stakeholders, to identify the key decisions to be taken, the knowledge gaps to be filled, and the necessary trade-offs. Key decisions and events will then pull the tasks as and when needed. It’s not a waste of time if you want peace of mind. There will always be technical contingencies, but they will be more manageable”.

DEVELOP YOUR HUMAN CAPITAL

As we debrief at the end of the gemba walk, I ask Sebastien whether the experience with Cecile made him change his mind. He confirms that, in two years, he has moved from “a KPI approach obsessed by the on-time delivery of projects” to the belief that “since engineers enjoy ideation, innovation and clever solutions, we need to sell them the desire to learn”. He now sees lean engineering as an opportunity to increase competence both on the product and on collaboration, to the extent that it is now a fundamental part of Somfy’s R&D strategy.  

Jean Christophe concurs: “The teams agreed to be questioned and challenged during those sessions, and to work hard in-between, because the tools were relevant, and because they saw significant and positive results for their project. They have developed their ability to spot and discuss the right issues; they have learned from each other and boosted collaboration. The difference couldn’t be more evident.”  

Developing human competence is – or, at least, should be – a key concern in an organization. AI offers and will continue to develop multiple ways to calculate quicker, to react faster, to identify factors and causes more systematically. But it cannot do kaizen, define a strategy or develop a competitive advantage for us. It has no empathy for customers or suppliers, and it does not check the working conditions for employees. Humans do.

_THE AUTHOR