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éthode de ges­tion de pro­duc­tion » sans gas­pillage « , mise au point au Japon par Toyo­ta. Elle recherche la per­for­mance par l’é­li­mi­na­tion des gas­pillages : pro­duc­tion exces­sive, attentes, trans­ports inutiles, stocks, etc., clas­sés en sept catégories.

Pour­quoi appli­quer la méthode lean aux acti­vi­tés de déve­lop­pe­ment et d’ingénierie ?

Une sta­tis­tique bien connue et una­ni­me­ment accep­tée suf­fit à poser clai­re­ment les enjeux d’un déve­lop­pe­ment maî­tri­sé et réel­le­ment effi­cace : 70 % à 80 % des coûts de cycle de vie d’un pro­duit sont déter­mi­nés en fin de phase de concep­tion, alors que seuls 10% à 30% des coûts ont été réel­le­ment engagés.

La culture du pompier

Quelle situa­tion obser­vons-nous dans nos entre­prises ? Des pro­jets en dépas­se­ment de délai, dont les calen­driers ont été impo­sés « par déci­sion du mana­ge­ment « , sous la pres­sion forte des mar­chés ou des clients. Un dia­logue de plus en plus dif­fi­cile entre l’en­ca­dre­ment et les équipes d’in­gé­nieurs et de tech­ni­ciens, res­treint bien sou­vent aux élé­ments de gestion.

Créer les rituels de management
Quelles réunions, quelle durée, avec quels par­ti­ci­pants, à quelle fré­quence ? Ces rituels garan­ti­ront que les infor­ma­tions sont effec­ti­ve­ment à jour et exploi­tées. L’i­dée est de pri­vi­lé­gier les réunions courtes (15 à 45 minutes) et fré­quentes (heb­do­ma­daire à quo­ti­dienne, selon la phase du pro­jet). Le gain se situe dans un par­tage beau­coup plus effi­cace des infor­ma­tions et donc une meilleure anti­ci­pa­tion ou une plus grande réac­ti­vi­té en cas d’imprévu.

Une com­mu­ni­ca­tion essen­tiel­le­ment fon­dée sur les outils de mes­sa­ge­rie élec­tro­nique et sur les échanges écrits, lais­sant très peu de place à la com­mu­ni­ca­tion visuelle et aux échanges phy­siques. La mise en avant de la culture du pom­pier, celui qui a réus­si, pour se dépê­trer d’une situa­tion inex­tri­cable et for­te­ment com­pro­mise, à trou­ver la solu­tion par son inven­ti­vi­té et sa débrouillardise.

Des pro­ces­sus de tra­vail à la com­plexi­té gran­dis­sante, parce que la com­plexi­té des pro­duits et des orga­ni­sa­tions est elle-même gran­dis­sante. Enfin, des impasses tech­niques nom­breuses, les déci­sions étant prises bien sou­vent au plus tôt, au plus vite – n’est-ce pas plus ras­su­rant ? -, sur des bases tech­niques non expli­ci­te­ment vali­dées. Face à cette situa­tion, les pro­po­si­tions faites au titre de l’ap­proche dite lean pro­duct deve­lop­ment peuvent être regrou­pées en trois grandes familles de prin­cipes, sous-ten­dues par dif­fé­rentes méthodes et dif­fé­rents outils.

Éliminer toute forme de gaspillage

Évi­ter les remises en question
Est-il rai­son­nable de vou­loir prendre plus de temps dans les phases amont, alors que l’on est sys­té­ma­ti­que­ment en retard ? Il faut com­prendre que l’on ira d’au­tant plus vite en concep­tion détaillée que l’on aura fait les bons choix en concep­tion géné­rale. On évi­te­ra les remises en ques­tion, tou­jours très coû­teuses, dans les phases aval du déve­lop­pe­ment, de l’in­dus­tria­li­sa­tion et de la mise en production.

Il est pos­sible de trans­po­ser au monde du déve­lop­pe­ment les bien connues sept formes de gas­pillage énu­mé­rées en lean manu­fac­tu­ring. Le prin­cipe est alors, pour un pro­ces­sus don­né, de repen­ser ce pro­ces­sus sous une forme plus simple, avec les acteurs et les clients. Seule­ment 30% à 40% des temps pas­sés par les équipes de déve­lop­pe­ment le sont pour des tâches à valeur ajou­tée. Les tech­niques de value stream map­ping (car­to­gra­phie de la chaîne de valeur) peuvent être uti­li­sées, avec un suc­cès cer­tain. On observe habi­tuel­le­ment un gain de l’ordre de 20 % à 30%.

Promouvoir le management visuel

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

Plus de 80 % des infor­ma­tions que nous rete­nons sont des infor­ma­tions que nous avons vues. Le lean pro­duct deve­lop­ment encou­rage l’u­ti­li­sa­tion de tech­niques extrê­me­ment visuelles pour accom­pa­gner la com­mu­ni­ca­tion et la prise de déci­sion. En pra­tique, cela passe par l’u­ti­li­sa­tion de stan­dards de concep­tion tels que les limit curves (courbes aux limites) ou trade off curves (courbes de sen­si­bi­li­té), sous forme de docu­ments A3. Ces docu­ments per­mettent de maté­ria­li­ser très sim­ple­ment les inter­valles de solu­tions admis­sibles pour une appli­ca­tion don­née et de posi­tion­ner visuel­le­ment les arbi­trages entre dif­fé­rents métiers. Cela passe éga­le­ment par la mise en place d’obeyas, espaces dédiés dans les­quels sont affi­chées et mises à jour régu­liè­re­ment au cours des réunions les infor­ma­tions utiles à l’é­quipe projet.

Retarder les décisions

Un pro­ces­sus de déve­lop­pe­ment, en par­ti­cu­lier l’a­mont de ce pro­ces­sus (concep­tion pré­li­mi­naire), est une suc­ces­sion de choix et donc de déci­sions, plus qu’une séquence d’ac­ti­vi­tés déter­mi­nistes. L’une des clés pour évi­ter que ne soit remise en ques­tion la concep­tion du pro­duit est la qua­li­té 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 pro­duct deve­lop­ment sug­gère que les déci­sions soient prises le plus tard pos­sible (mais pas trop tard) et insiste sur la qua­li­té des jus­ti­fi­ca­tions techniques.

Prendre les déci­sions le plus tard pos­sible sur la base de connais­sances validées

Très sou­vent, nous obser­vons qu’au contraire nous allons prendre les déci­sions au plus tôt et fer­mer les portes dès que pos­sible. Avons-nous à ce moment-là tous les élé­ments qui per­mettent de conclure, 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 prendre un peu plus de temps pour étu­dier plu­sieurs alter­na­tives si effec­ti­ve­ment une solu­tion ne paraît pas évi­dente ? La dif­fi­cul­té sera de défi­nir la séquence des déci­sions ou des choix, de déter­mi­ner clai­re­ment les inter­dé­pen­dances entre cer­tains de ces choix, au besoin d’i­den­ti­fier les alter­na­tives et de pla­ni­fier en consé­quence la séquence de déci­sions, de façon cohé­rente et syn­chrone entre les métiers – ce sont les méthodes dites set-based concur­rent engi­nee­ring.

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

Qu’en est-il aujourd’­hui du déploie­ment de ces méthodes ? Le lean pro­duct deve­lop­ment n’a cer­tai­ne­ment pas atteint le même niveau de matu­ri­té que le lean manu­fac­tu­ring. Le sec­teur le plus avan­cé, proxi­mi­té avec l’i­ni­tia­teur nip­pon de ces démarches oblige, est celui de l’au­to­mo­bile. Les entre­prises du sec­teur high­tech ont éga­le­ment avan­cé de façon signi­fi­ca­tive dans ce domaine. Suivent l’aé­ro­nau­tique, le spa­tial, l’éner­gie et les équi­pe­ments indus­triels. Les don­neurs d’ordre du sec­teur auto­mo­bile constatent aujourd’­hui une réduc­tion du cycle de déve­lop­pe­ment de l’ordre de 30% pour un pro­duit nouveau.

Deux dif­fi­cul­tés
La com­plexi­té gran­dis­sante des orga­ni­sa­tions est pro­ba­ble­ment plus contrai­gnante que celle des pro­duits eux-mêmes. Les rachats, fusions et autres restruc­tu­ra­tions ont ame­né les entre­prises à adop­ter des orga­ni­sa­tions très sou­vent peu lisibles et extrê­me­ment chan­geantes, indui­sant une perte de repères. On peut ima­gi­ner des orga­ni­sa­tions conser­vant un niveau suf­fi­sant de lisi­bi­li­té et pri­vi­lé­giant la proxi­mi­té et la réac­ti­vi­té. Les uni­tés élé­men­taires de concep­tion, com­pa­rables aux uni­tés auto­nomes de pro­duc­tion en lean manu­fac­tu­ring, apportent une réponse.
On peut aus­si dou­ter de notre apti­tude à appli­quer avec toute la dis­ci­pline néces­saire les stan­dards défi­nis (pro­duits, pro­ces­sus, méthodes). L’Eu­rope, la France en par­ti­cu­lier, peut-elle être com­pa­rée au Japon ? A mini­ma, il est impor­tant de confier le soin de défi­nir les stan­dards à ceux qui devront les mettre en application.

Commentaire

Ajouter un commentaire

Vincent Gina­batrépondre
4 octobre 2011 à 6 h 44 min

Exe­cu­tive VP – Euro­prop Inter­na­tio­nal
Bra­vo Sté­phane pour cette syn­thèse de bonnes pra­tiques ! Certes les sec­teurs que tu cites ont tous géné­ra­li­sé le lean en déve­lop­pe­ment (sans oublier 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 contri­bu­teur majeur des déra­pages de pro­jets com­plexes, que nous appré­hen­dons très mal, c’est l’ins­ta­bi­li­té des spé­ci­fi­ca­tions amont. C’est un fait, même quand il y a des phases de concep­tion conjointe client-four­nis­seur, parce que les clients eux-mêmes ne vivent pas dans un envi­ron­ne­ment stable. On peut retar­der des fran­chis­se­ments de jalons mais on risque fort de n’a­voir jamais tous les élé­ments pour conclure… sauf à la fin. On a vu des pro­duits com­plexes cer­ti­fiés bons pour le ser­vice alors que leurs spé­ci­fi­ca­tions conti­nuaient à évo­luer en pro­fon­deur. Com­ment inté­grer cette réa­li­té en déve­lop­pant « à risque objec­tif » ? A te lire ! Vincent Gina­bat (90)

Répondre