L’approche LEAN appliquée au développement des produits

Dossier : Les Challenges de la crise : conjuguer performance et croissanceMagazine N°668 Octobre 2011
Par Stéphane GAUTROT (89)

REPÈRES
Lean (“ dégrais­sé ”) est une méth­ode de ges­tion de pro­duc­tion ” sans gaspillage “, mise au point au Japon par Toy­ota. Elle recherche la per­for­mance par l’élim­i­na­tion des gaspillages : pro­duc­tion exces­sive, attentes, trans­ports inutiles, stocks, etc., classés en sept catégories.

Pourquoi appli­quer la méth­ode lean aux activ­ités de développe­ment et d’ingénierie ?

Une sta­tis­tique bien con­nue et unanime­ment accep­tée suf­fit à pos­er claire­ment les enjeux d’un développe­ment maîtrisé et réelle­ment effi­cace : 70 % à 80 % des coûts de cycle de vie d’un pro­duit sont déter­minés en fin de phase de con­cep­tion, alors que seuls 10% à 30% des coûts ont été réelle­ment engagés.

La culture du pompier

Quelle sit­u­a­tion obser­vons-nous dans nos entre­pris­es ? Des pro­jets en dépasse­ment de délai, dont les cal­en­dri­ers ont été imposés “par déci­sion du man­age­ment “, sous la pres­sion forte des marchés ou des clients. Un dia­logue de plus en plus dif­fi­cile entre l’en­cadrement et les équipes d’ingénieurs et de tech­ni­ciens, restreint bien sou­vent aux élé­ments de gestion.

Créer les rit­uels de management
Quelles réu­nions, quelle durée, avec quels par­tic­i­pants, à quelle fréquence ? Ces rit­uels garan­tiront que les infor­ma­tions sont effec­tive­ment à jour et exploitées. L’idée est de priv­ilégi­er les réu­nions cour­tes (15 à 45 min­utes) et fréquentes (heb­do­madaire à quo­ti­di­enne, selon la phase du pro­jet). Le gain se situe dans un partage beau­coup plus effi­cace des infor­ma­tions et donc une meilleure antic­i­pa­tion ou une plus grande réac­tiv­ité en cas d’imprévu.

Une com­mu­ni­ca­tion essen­tielle­ment fondée sur les out­ils de mes­sagerie élec­tron­ique et sur les échanges écrits, lais­sant très peu de place à la com­mu­ni­ca­tion visuelle et aux échanges physiques. La mise en avant de la cul­ture du pom­pi­er, celui qui a réus­si, pour se dépêtr­er d’une sit­u­a­tion inex­tri­ca­ble et forte­ment com­pro­mise, à trou­ver la solu­tion par son inven­tiv­ité et sa débrouillardise.

Des proces­sus de tra­vail à la com­plex­ité gran­dis­sante, parce que la com­plex­ité des pro­duits et des organ­i­sa­tions est elle-même gran­dis­sante. Enfin, des impass­es tech­niques nom­breuses, les déci­sions étant pris­es bien sou­vent au plus tôt, au plus vite — n’est-ce pas plus ras­sur­ant ? -, sur des bases tech­niques non explicite­ment validées. Face à cette sit­u­a­tion, les propo­si­tions faites au titre de l’ap­proche dite lean prod­uct devel­op­ment peu­vent être regroupées en trois grandes familles de principes, sous-ten­dues par dif­férentes méth­odes et dif­férents outils.

Éliminer toute forme de gaspillage

Éviter les remis­es en question
Est-il raisonnable de vouloir pren­dre plus de temps dans les phas­es amont, alors que l’on est sys­té­ma­tique­ment en retard ? Il faut com­pren­dre que l’on ira d’au­tant plus vite en con­cep­tion détail­lée que l’on aura fait les bons choix en con­cep­tion générale. On évit­era les remis­es en ques­tion, tou­jours très coû­teuses, dans les phas­es aval du développe­ment, de l’in­dus­tri­al­i­sa­tion et de la mise en production.

Il est pos­si­ble de trans­pos­er au monde du développe­ment les bien con­nues sept formes de gaspillage énumérées en lean man­u­fac­tur­ing. Le principe est alors, pour un proces­sus don­né, de repenser ce proces­sus sous une forme plus sim­ple, avec les acteurs et les clients. Seule­ment 30% à 40% des temps passés par les équipes de développe­ment le sont pour des tâch­es à valeur ajoutée. Les tech­niques de val­ue stream map­ping (car­togra­phie de la chaîne de valeur) peu­vent être util­isées, avec un suc­cès cer­tain. On observe habituelle­ment un gain de l’or­dre de 20 % à 30%.

Promouvoir le management visuel

La com­mu­ni­ca­tion visuelle per­met de percevoir 80% des infor­ma­tions présentées

Plus de 80 % des infor­ma­tions que nous retenons sont des infor­ma­tions que nous avons vues. Le lean prod­uct devel­op­ment encour­age l’u­til­i­sa­tion de tech­niques extrême­ment visuelles pour accom­pa­g­n­er la com­mu­ni­ca­tion et la prise de déci­sion. En pra­tique, cela passe par l’u­til­i­sa­tion de stan­dards de con­cep­tion tels que les lim­it curves (courbes aux lim­ites) ou trade off curves (courbes de sen­si­bil­ité), sous forme de doc­u­ments A3. Ces doc­u­ments per­me­t­tent de matéri­alis­er très sim­ple­ment les inter­valles de solu­tions admis­si­bles pour une appli­ca­tion don­née et de posi­tion­ner visuelle­ment les arbi­trages entre dif­férents métiers. Cela passe égale­ment par la mise en place d’obeyas, espaces dédiés dans lesquels sont affichées et mis­es à jour régulière­ment au cours des réu­nions les infor­ma­tions utiles à l’équipe projet.

Retarder les décisions

Un proces­sus de développe­ment, en par­ti­c­uli­er l’a­mont de ce proces­sus (con­cep­tion prélim­i­naire), est une suc­ces­sion de choix et donc de déci­sions, plus qu’une séquence d’ac­tiv­ités déter­min­istes. L’une des clés pour éviter que ne soit remise en ques­tion la con­cep­tion du pro­duit est la qual­ité de la prise de déci­sion. À quel moment telle déci­sion doit-elle être prise, quels élé­ments objec­tifs jus­ti­fient cette déci­sion ? L’ap­proche du lean prod­uct devel­op­ment sug­gère que les déci­sions soient pris­es le plus tard pos­si­ble (mais pas trop tard) et insiste sur la qual­ité des jus­ti­fi­ca­tions techniques.

Pren­dre les déci­sions le plus tard pos­si­ble sur la base de con­nais­sances validées

Très sou­vent, nous obser­vons qu’au con­traire nous allons pren­dre les déci­sions au plus tôt et fer­mer les portes dès que pos­si­ble. Avons-nous à ce moment-là tous les élé­ments qui per­me­t­tent de con­clure, du point de vue tant de l’ex­pres­sion des besoins que des jus­ti­fi­ca­tions tech­niques ? Ne peut-on pas pren­dre un peu plus de temps pour étudi­er plusieurs alter­na­tives si effec­tive­ment une solu­tion ne paraît pas évi­dente ? La dif­fi­culté sera de définir la séquence des déci­sions ou des choix, de déter­min­er claire­ment les inter­dépen­dances entre cer­tains de ces choix, au besoin d’i­den­ti­fi­er les alter­na­tives et de plan­i­fi­er en con­séquence la séquence de déci­sions, de façon cohérente et syn­chrone entre les métiers — ce sont les méth­odes dites set-based con­cur­rent engi­neer­ing.

Une réduction de 30% du cycle de développement

Qu’en est-il aujour­d’hui du déploiement de ces méth­odes ? Le lean prod­uct devel­op­ment n’a cer­taine­ment pas atteint le même niveau de matu­rité que le lean man­u­fac­tur­ing. Le secteur le plus avancé, prox­im­ité avec l’ini­ti­a­teur nip­pon de ces démarch­es oblige, est celui de l’au­to­mo­bile. Les entre­pris­es du secteur high­tech ont égale­ment avancé de façon sig­ni­fica­tive dans ce domaine. Suiv­ent l’aéro­nau­tique, le spa­tial, l’én­ergie et les équipements indus­triels. Les don­neurs d’or­dre du secteur auto­mo­bile con­sta­tent aujour­d’hui une réduc­tion du cycle de développe­ment de l’or­dre de 30% pour un pro­duit nouveau.

Deux dif­fi­cultés
La com­plex­ité gran­dis­sante des organ­i­sa­tions est prob­a­ble­ment plus con­traig­nante que celle des pro­duits eux-mêmes. Les rachats, fusions et autres restruc­tura­tions ont amené les entre­pris­es à adopter des organ­i­sa­tions très sou­vent peu lis­i­bles et extrême­ment changeantes, induisant une perte de repères. On peut imag­in­er des organ­i­sa­tions con­ser­vant un niveau suff­isant de lis­i­bil­ité et priv­ilé­giant la prox­im­ité et la réac­tiv­ité. Les unités élé­men­taires de con­cep­tion, com­pa­ra­bles aux unités autonomes de pro­duc­tion en lean man­u­fac­tur­ing, appor­tent une réponse.
On peut aus­si douter de notre apti­tude à appli­quer avec toute la dis­ci­pline néces­saire les stan­dards défi­nis (pro­duits, proces­sus, méth­odes). L’Eu­rope, la France en par­ti­c­uli­er, peut-elle être com­parée au Japon ? A min­i­ma, il est impor­tant de con­fi­er le soin de définir les stan­dards à ceux qui devront les met­tre en application.

Commentaire

Ajouter un commentaire

Vin­cent Ginabatrépondre
4 octobre 2011 à 6 h 44 min

Exec­u­tive VP — Euro­prop Inter­na­tion­al
Bra­vo Stéphane pour cette syn­thèse de bonnes pra­tiques ! Certes les secteurs que tu cites ont tous général­isé le lean en développe­ment (sans oubli­er le naval dans les années 1995–2000) mais les grands pro­jets “phares” ont tou­jours autant de mal à être à l’heure. Il y a un con­tribu­teur majeur des déra­pages de pro­jets com­plex­es, que nous appréhen­dons très mal, c’est l’in­sta­bil­ité des spé­ci­fi­ca­tions amont. C’est un fait, même quand il y a des phas­es de con­cep­tion con­jointe client-four­nisseur, parce que les clients eux-mêmes ne vivent pas dans un envi­ron­nement sta­ble. On peut retarder des fran­chisse­ments de jalons mais on risque fort de n’avoir jamais tous les élé­ments pour con­clure… sauf à la fin. On a vu des pro­duits com­plex­es cer­ti­fiés bons pour le ser­vice alors que leurs spé­ci­fi­ca­tions con­tin­u­aient à évoluer en pro­fondeur. Com­ment inté­gr­er cette réal­ité en dévelop­pant “à risque objec­tif” ? A te lire ! Vin­cent Gin­abat (90)

Répondre