203 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle M@n@gement Copies of this article can be made free of charge and without securing permission, for purposes of teaching, research, or library reserve. Consent to other kinds of copying, such as that for creating new works, or for resale, must be obtained from both the journal editor(s) and the author(s). M@n@gement is a double-blind refereed journal where articles are published in their original lan- guage as soon as they have been accepted. For a free subscription to M@n@gement, and more information: http://www.management-aims.com © 2009 M@n@gement and the author(s). Valéry Merminod, Caroline Mothe Frantz Rowe 2009 Effets de Product Lifecycle Management sur la fia- bilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement, 12(4), 294-331. M@n@gement est la revue officielle de l’AIMS M@n@gement is the journal official of AIMS ISSN: 1286-4892 Editors: Emmanuel Josserand, HEC, Université de Genève (Editor in Chief) Jean-Luc Arrègle, EDHEC (editor) Stewart Clegg, University of Technology, Sydney (editor) Martin Kornberger, University of Technology, Sydney (editor) Philippe Monin, EM Lyon (Editor) José Pla-Barber, Universitat de València (editor) Linda Rouleau, HEC Montréal (editor) Michael Tushman, Harvard Business School (editor) Thibaut Bardon, Universté Paris-Dauphine, CREPA - HEC, Université de Genève (editorial assistant) Florence Villeseche, HEC, Université de Genève (editorial assistant) Martin G. Evans, University of Toronto (editor emeritus) Bernard Forgues, EMLyon Business School (editor emeritus) Volume 12, No. 4. Special Issue: “Fiabilité et résilience comme dimensions de la performance organisationnelle” Guest Editors: Erik Hollnagel, Benoît Journé et Hervé Laroche. 294 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit Valéry Merminod Caroline Mothe Frantz Rowe Professeur SKEMA Business School, chercheur associé au LEMNA Valery.merminod@ceram.fr Professeur des Universités, IREGE, Université de Savoie Caroline.Mothe@univ-savoie.fr Professeur des Universités, LEMNA, Université de Nantes Chercheur associé SKEMA Business School frantz.rowe@univ-nantes.fr Si de nombreuses recherches sont consacrées aux contextes de haute fiabilité, un nombre relativement limité de travaux se focalisent sur la fiabilité des processus plus classiques dans l’industrie ou les services. Dans ces situations plus traditionnelles d’amélioration de la performance, le critère de fiabilité est souvent couplé à celui de la productivité. Cet article appréhende la contribution de la technologie Product Lifecycle Management (PLM) à la fiabilité et à la productivité du processus de développement de nouveaux produits. À travers une étude de cas longitudinale au sein d’un groupe industriel du petit électroménager, nous étudions les effets de PLM sur la productivité et la fiabilité à travers l’intégration des connaissances explicites, les routines et la vigilance des acteurs. Nous mettons en avant le caractère non antagoniste de la productivité et de la fiabilité dans deux contextes différents, le codéveloppement et le développement interne, et discutons les effets conjoints de PLM et du contexte sur ces deux dimensions de la performance. Mots clés : développement de nouveaux produits, Product Lifecycle Management, per- formance, productivité, fiabilité, intégration des connaissances, routines, vigilance. Although much research is devoted to high reliability contexts, relatively few works focus on the reliability of more conventional processes in industry or services. In these more traditional situations of performance improvement, the criterion of reliability is often cou- pled with that of productivity. This article captures the contribution of Product Lifecycle Management (PLM) technology to the reliability and productivity of new product develo- pment. Through a longitudinal case study within an industrial group of small appliances, we study the effects of PLM on productivity and reliability through explicit knowledge integration, routines and actors’ vigilance. We highlight the non-adversarial nature of productivity and reliability in two different contexts, co-development and internal develo- pment, and discuss the joint effects of PLM and of context on these two dimensions of performance. Keywords : New Product Development, Product Lifecycle Management, Performance, Productivity, Reliability. 295 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle INTRODUCTION Deux tendances de fond influencent le management du développement produit depuis le milieu des années 1990 : la croissance des projets de codéveloppement et la distanciation accrue des équipes de développe- ment. Cette distanciation est souvent supportée par des technologies de l’information et de la communication (TIC) qui servent d’espace de travail collaboratif virtuel (Nijssen et Frambach, 2000 ; Nambisan, 2003). Pour supporter un processus de développement produit de plus en plus distribué, les entreprises multiplient la mise en place de TIC. Au-delà des outils de conception assistée par ordinateur (CAO) s’imposent des technologies émergentes pour gérer les objets de connaissance des projets et remplacer un système d’information composé d’outils hétéro- gènes qui se sont, historiquement, superposés. Les organisations ont ainsi de plus en plus recours à la technologie PLM (Product Lifecycle Management) dans le but d’intégrer, de fluidifier et d’améliorer la per- formance du développement produit. L’objectif de cet article est d’analyser la contribution de PLM à la per- formance du processus de développement, performance appréhendée sous l’angle de la fiabilité et la productivité. Les processus de déve- loppement produit sont aujourd’hui dominés par une forte pression sur les délais. Mettant en avant que des rentes peuvent venir à la fois d’un processus plus rapide et plus productif que celui des concurrents et d’une valeur du produit supérieure pour le client, Verona (1999) indique que la mesure de l’efficience du processus de développement se fait en termes de temps d’avance sur les concurrents et de productivité. Un des challenges pour ces processus sous pression temporelle constante est de gérer, en parallèle, la fiabilité de ce processus afin de garantir la qualité du produit final. Mais fiabilité et productivité vont-elles de pair ou sont-elles deux orientations antagonistes ? Cette question, essentielle en management de projet et dans le domaine des organi- sations soumises à des risques majeurs, a déjà été débattue. Les re- cherches sur ces environnements à risque élevé montrent que l’objectif de fiabilité est antagonique à celui de productivité (Weick et Roberts, 1993). Si le dilemme entre rapidité et temps d’apprentissage (donc fia- bilité) est identifié (Hatchuel, 1994 ; Bourgeon, 2002), la contradiction apparaît comme moins évidente dans des industries plus classiques où l’objectif d’un très haut niveau de fiabilité n’est pas vital et peut entraîner une baisse de la productivité. Les rares recherches empiriques dans ce domaine confortent l’idée d’un antagonisme. Ainsi, Brion (2005), dans son article sur une entreprise de téléphonie mobile, met en évidence que le temps de développement découlant du choix de fiabilisation des processus s’est allongé. Dans le bâtiment, la vitesse de coordination permise par la télécopie et le téléphone, qui permet de gagner en pro- ductivité par rapport aux réunions, peut se révéler dangereuse pour réaliser les objectifs de résultat si la planification des lots, et donc la fiabilité, n’est pas respectée (Marciniak et Rowe, 1999). Dans les industries classiques, la fiabilité du processus de dévelop- pement produit ne peut être assimilée à des problèmes de sécurité et de sûreté de fonctionnement. Compte tenu des résultats encore mi- 296 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle tigés sur le dilemme productivité/fiabilité, il semble donc intéressant de contribuer à ce débat et d’examiner si la fiabilité est véritablement antagonique de la performance, et plus particulièrement de la produc- tivité (Weick et Roberts, 1993) et, si oui, dans quelles conditions. Notre recherche pose ainsi la question de la compatibilité de la produc- tivité et de la fiabilité dans les activités de R & D dans l’industrie manu- facturière en l’abordant selon le contexte de développement. En effet, comme pour d’autres technologies de l’information, l’impact de PLM risque de dépendre du contexte dans lequel cette technologie est mise en œuvre. Nous distinguons le développement interne, c’est-à-dire un développement intra-organisationnel, du codéveloppement, corres- pondant à un contexte interorganisationnel avec des prestataires ex- ternes (Calvi et al., 2005). Dans le cas du développement interne, les espaces de relations sont déjà bien structurés. Ici, soit PLM augmente conjointement la productivité et la fiabilité du processus de développe- ment, soit les tâches supportées par la technologie ralentissent la pro- ductivité malgré les gains de fiabilité – comme pour des organisations soumises à des risques majeurs. Dans le cas du codéveloppement, les relations sont plus complexes, notamment à cause des différences culturelles. Cependant, lorsque les relations sont peu récurrentes et peu structurées, on peut supposer que, après une courte phase d’ap- prentissage, PLM favorise la productivité et la fiabilité. Cette différence de contexte de développement n’ayant pas fait l’objet d’une recherche préalable, comparer les effets respectifs de PLM sur la productivité et la fiabilité selon ce contexte constitue un enjeu clé pour les entreprises aujourd’hui, à l’heure où le processus de développement est de plus en plus dispersé. Dans une première partie, cet article propose un cadre conceptuel de la performance (sous l’angle de la fiabilité et de la productivité) du pro- cessus de développement produit. La deuxième partie décrit la métho- dologie ainsi que l’étude de cas. Nous discutons les résultats dans une troisième partie avant de conclure. PRODUCTIVITÉ ET FIABILITÉ DU PROCESSUS DE DÉVELOPPEMENT PRODUIT De nombreux travaux (Brown et Eisenhardt, 1995 ; Takikonda et Mon- toya-Weiss, 2001 ; Mallick et Schroeder, 2005) ont été consacrés à la performance du développement produit. Parmi les critères de perfor- mance les plus cités, on trouve le temps de développement (Clark et Fujimoto, 1991 ; Brown et Eisenhardt, 1995 ; Takikonda et Rosenthal, 2000), la performance du produit (Clark et Fujimoto, 1991 ; Takikonda et Montoya-Weiss, 2001), les coûts de production (Meyer et Utterback, 1997 ; Takikonda et Rosenthal, 2000), le succès marché (Meyer et Utterback, 1997), le succès financier (Brown et Eisenhardt, 1995) et le succès commercial (Zirger et Maidique, 1990). Si mesurer la performance du développement produit reste difficile (Meyer et Utterback, 1997), d’autant qu’il s’agit souvent de mesurer 297 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle des projets disparates, le choix de la mesure l’est tout autant compte tenu de la quantité des critères disponibles (75 ont été identifiés dans la littérature). Notre choix s’est porté sur la productivité et la fiabilité. En effet, la préoccupation essentielle en matière de développement produit est de raccourcir le délai de développement en réduisant la complexité du projet en transférant certaines tâches aux fournisseurs (Clark et Fujimoto, 1990 ; Calvi et al., 2005 ; Malhotra et al., 2005) ou en en diminuant la durée. Par ailleurs, la nécessité de « sortir » des pro- duits dans de bonnes conditions de qualité implique une fiabilité élevée du processus de développement. Garantir un bon niveau de fiabilité du processus de développement est donc essentiel, même si cette fiabilité peut être difficile à allier à la productivité et à une logique de réduction du délai de développement. Les organisations sont donc confrontées à un management paradoxal, contraintes tant à la fiabilité qu’à la produc- tivité du processus de développement pour assurer la tenue de délais exigeants et une qualité élevée des nouveaux produits. Après avoir caractérisé le développement produit et traité l’intégration des connaissances comme une problématique clé de ce processus, nous présentons la technologie PLM (I.1). Nous appréhendons ensuite la fiabilité (I.2) et la productivité (I.3) comme éléments clés de la perfor- mance du processus de développement produit. Caractéristiques du développement produit et émer- gence de PLM Le développement produit correspond à une activité de spécification construite à partir d’un cahier des charges donné et contrainte par les compétences disponibles (Brown et Eisenhardt, 1995 ; Le Masson et al., 2006). Il correspond à un processus contrôlé afin de spécifier un système qui doit répondre à des critères définis de qualité, coût et délai (Le Masson et al., 2006). Le développement produit, souvent fondé sur un mode d’organisation projet (Garel, 1999), est critique puisqu’il assu- re la mise sur le marché de nouveaux produits. C’est un processus par nature complexe, incertain et contingent, qui repose sur une multitude de fonctions comme le marketing, le bureau d’étude (BE), la logistique, la qualité (Terssac et Friedberg, 1996). Se pose ainsi la question cru- ciale de l’intégration des différentes connaissances possédées par une grande diversité d’acteurs. Intégration des connaissances : une problématique clé du déve- loppement produit Le management des connaissances a été l’objet d’une importante lit- térature, notamment depuis l’article séminal de Nonaka (1994). Grant (1996) s’est, le premier, attaché au concept d’intégration des connais- sances, qu’il définit comme la capacité organisationnelle clé de la firme. Les capacités internes d’intégration des différents types de connaissan- ces sont considérées comme une variable cruciale, avec les capacités technologiques, de la performance du processus de développement (Verona, 1999). L’intégration des connaissances fait partie de ce que Kusunoki et al. (1998) appellent, pour le développement produit, les ca- pacités processuelles (process capabilities). Elle représente la phase 298 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle 3 (combinaison, qui comprend l’intégration) du modèle SECI (Nonaka et al., 2000). Cette intégration des connaissances est particulièrement complexe dans le cadre du développement produit du fait de la spécialisation des acteurs qui appartiennent à des univers cognitifs divers et qui dispo- sent de répertoires de connaissances hétérogènes (Hoopes et Postrel, 1999 ; Carlile, 2002, 2004). La difficulté d’un engagement rapide dans l’action collective, propre aux équipes projet, rend d’ailleurs d’autant plus nécessaire un répertoire partagé pouvant être mobilisé rapide- ment (Chanal, 2003). De Luca et al. (2009) définissent l’intégration des connaissances comme les mécanismes formels qui assurent l’assimi- lation, l’analyse et l’interprétation des connaissances scientifiques et marketing. Ils montrent que l’intégration des connaissances joue un rôle modérateur sur le lien entre l’orientation marché des entreprises de biotechnologies italiennes et l’efficacité de leur R & D. De manière plus spécifique au processus de développement produit, Hoopes et Postrel (1999) retiennent les dimensions de partage, de coordination et de coopération pour analyser l’intégration des connaissances dans le processus de développement produit : – Le partage de connaissances est assimilé à la compétence de mana- gement de la circulation des différents inputs et des interactions entre acteurs. Le partage repose sur ces interactions entre acteurs dispo- sant d’expertises différentes et qui concourent à un objectif commun. – La coordination consiste à gérer des activités interdépendantes orien- tées vers un objectif commun (Malone et Crowston, 1994). Elle requiert une compréhension de la gestion de la distribution des connaissances et des expertises. – La coopération correspond à la manière dont « les individus équili- brent leurs actions entre leur intérêt personnel et l’intérêt de la firme » (Hoopes et Postrel 1999, p. 839). Nous ne retenons pas la coopération comme composante de l’intégration des connaissances car elle éma- ne de la volonté propre des acteurs, et non d’un support de médiation des échanges comme une TIC. Nous considérons que la coopération relève de constructions sociales et politiques et que, dans ce cadre, la contribution des TIC est assez limitée. Outre le partage et la coordination, nous appréhendons l’intégration des connaissances à travers une troisième dimension, la réutilisation (ou capitalisation) des connaissances, que Sambamurthy et Subramani (2005) prennent en compte dans le management des connaissances par les TIC. La réutilisation consiste à capitaliser sur les connaissances afin de pouvoir les utiliser ultérieurement. L’intégration des connais- sances est donc vue ici, dans le cadre du développement produit, à travers le partage, la coordination et la capitalisation. Nous cherchons à montrer que PLM améliore la fiabilité et la productivité, notamment grâce à l’intégration des connaissances que cette technologie permet. Contribution de PLM à la performance du développement produit Les recherches consacrées à l’impact des TIC sur la performance des organisations montrent une influence tantôt positive, tantôt néga- tive (Short et Venkatraman, 1992 ; Strassman, 1997). Certains voient le système d’information comme un contributeur direct à l’avantage 299 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle concurrentiel (Short et Venkatraman, 1992). D’autres mettent en avant les effets contingents des ressources TIC (Strassman, 1997) et ques- tionnent la relation causale directe, les TIC ayant alors une contribution indirecte à la performance (Weill, 1992 ; Rowe, 1994 ; Brynjolfsson et Hitt, 1996). L’apport des TIC à la performance du développement produit a été démontré, que ce soit dans un cadre intra-organisationnel (Iansiti et MacCormack, 1997) ou interorganisationnel (Pavlou et El Sawy, 2006). Cependant, ces recherches, faiblement contextualisées, éclairent peu sur les mécanismes de contribution des TIC à la performance du dé- veloppement produit. Nous focalisons notre recherche sur une tech- nologie émergente, Product Lifecycle Management (PLM), qui permet d’intégrer les connaissances explicites des acteurs projet. La technologie PLM trouve son origine dans les systèmes de gestion des données techniques (SGDT) qui permettent de stocker des don- nées techniques relatives aux produits comme les gammes, les no- menclatures, les plans produits. Les solutions PLM sont apparues à la fin des années 1990 lorsque ces technologies ont été capables de gérer les objets (plans, spécifications, nomenclatures) de l’ensemble des acteurs associés au développement produit : marketing, design, BE, qualité, normes, etc. (Batenburg et al., 2005 ; Pol et al., 2005). PLM, initialement adoptée dans l’aéronautique et l’automobile, s’est progressivement diffusée dans d’autres industries plus traditionnelles au début des années 2000 avec des solutions développées par des éditeurs comme Dassault System, Siemens ou PTC. Les fonctionnalités principales de PLM sont articulées autour du stoc- kage et de la capitalisation des connaissances explicites, de leur par- tage, de la communication et du pilotage de projets. PLM repose sur une base de données unique des objets et sur une interface homme- machine unique pour tous les acteurs du développement produit. Elle facilite une vision unifiée des connaissances relatives au produit dans le cadre de la collaboration intra-organisationnelle et interorganisation- nelle (Mostefai et Batouche, 2005). PLM est donc une technologie « intégrée » (Mostefai et Batouche, 2005) permettant de regrouper dans une application unique les informations relatives au projet, au produit et au processus de développement. Elle permet de disposer d’une re- présentation virtuelle d’un produit physique et de gérer virtuellement la collaboration tout au long du processus de développement grâce au stockage, à la coordination et au contrôle de toutes les informations relatives au développement : spécifications fonctionnelles, nomencla- tures, caractéristiques techniques, processus d’industrialisation (Grie- ves, 2006). Cette technologie supporte une approche processus de dé- veloppement produit structurée avec une logique de passage d’étapes (cf. Cooper et Kleinschmidt, 1990) qui repose sur cinq jalons clés : défi- nition du périmètre, conception de la solution, développement, tests et lancement. Après avoir précisé les contours de l’application PLM, nous allons préciser le concept de fiabilité. 300 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle La fiabilité : une première dimension de la performance du développement produit La fiabilité peut être définie comme la capacité à produire collective- ment avec une qualité minimale prédéfinie, et ce de manière répétitive (Hannan et Freeman, 1984). Alors que la qualité s’applique à l’objet développé, au produit fini, la fiabilité s’applique au processus de dé- veloppement produit. Elle est essentielle pour garantir la qualité du produit fini et le respect du délai de sortie de ce dernier. La fiabilité n’est pas seulement l’atteinte d’un niveau d’objectifs prédéfinis ; elle représente également la faculté de contrôler la variation des résultats (Deming, 1982). La fiabilité provient d’une approche focalisée sur les contraintes opérationnelles (Weick et al., 2000). L’objectif est d’iden- tifier rapidement les problèmes de développement afin de réaliser les ajustements nécessaires au plus tôt pour améliorer le respect des en- gagements (Butler et Gray, 2006 ; Yassine, 2007) et de réduire tant les problèmes de qualité liés aux erreurs (Thomke et Fujimoto, 2000) que le risque qu’un projet ne se réalise pas conformément aux prévisions de date d’achèvement, de coût et de spécifications (Giard, 1991). Nous traitons d’abord des dimensions de la fiabilité (respect des délais et diminution des erreurs) puis des moyens pour améliorer la fiabilité du processus (routines et vigilance). Dimensions de la fiabilité : respect des délais et diminution des erreurs Le respect des délais des projets constitue une dimension clé de la performance du développement produit (Marciniak et Pagerie, 1999). Toutefois une difficulté réside dans le mode de calcul du retard moyen des projets, plusieurs moyens de le mesurer coexistant (Garel, 1999). Nous retenons l’approche stage gate de Cooper et Kleinschmidt (1990) et l’estimation de durée faite au début de la phase de conception. Nous analysons l’écart entre le planifié et le réalisé à la date de fin de dé- veloppement, qui correspond à la fin du processus d’industrialisation du produit avec l’autorisation de mise en production de masse du pro- duit. La diminution des erreurs va de pair avec l’autre dimension de la fia- bilité, le respect des délais. Dans le cadre du développement produit, la détection et la correction des problèmes dès la phase amont de conception permettent d’améliorer le respect du délai de développe- ment et la qualité du produit fini. Si les problèmes sont identifiés tard, les coûts de résolution sont souvent plus importants et la nature des problèmes plus complexe (Hatchuel, 1994 ; Brown et Eisenhardt, 1995 ; Nambisan, 2003). Une approche pour réduire les erreurs dans le pro- cessus de développement produit consiste à améliorer la qualité des échanges entre les acteurs en réduisant les erreurs de communica- tion1. Dans ce cadre, nous mobilisons le concept de glitch (Hoopes et Postrel, 1999), qui correspond à une erreur de communication, à un problème dans l’échange de connaissances, à un résultat insatisfai- sant dans le cadre de relations d’échanges entre deux ou plusieurs acteurs. Les glitches peuvent être évités si les acteurs disposent d’un répertoire de connaissance commun et sont capables de comprendre et d’interpréter la connaissance échangée. Ils peuvent être identifiés 1. Cette approche est imparfaite pour deux raisons. D’une part, certaines erreurs de conception ne peuvent être détectées lors de la phase de R & D. D’autre part, il faut se garder de vouloir systématiquement éliminer toute erreur sans en débattre car l’« erreur » fait partie de notre fonction- nement cognitif (Gilbert et al., 2007) et, d’un point de vue interpersonnel, n’est peut-être qu’un désaccord d’interprétations des représentations. Dans une approche pragmatique, la communication sert préci- sément à traiter les malentendus plus que des erreurs (Boullier, 1995) sous peine d’en supporter les conséquences. 301 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle par les déclarations d’erreurs directement liées aux problèmes de cir- culation des connaissances sur les projets. Hoopes et Postrel (1999) ont défini quatre types de glitch : a. les problèmes de synchronisation et de non-respect des procédures d’échange et de communication ; b. le cas où les procédures d’échange sont respectées mais où une contrainte clé n’a pas été communiquée par un acteur alors qu’elle tou- che les autres acteurs ; c. le cas du partage de connaissances comple- xes où une contrainte d’un acteur n’est pas comprise par le récepteur car le problème est difficile à régler ; d. un problème non résolu à cause de l’incompréhension réciproque des contraintes entre acteurs liée à la complexité de la connaissance en question. Vecteurs de fiabilité : routines et vigilance des acteurs Les routines organisationnelles permettent d’améliorer la fiabilité (Hard- grave et al., 2003 ; Butler et Gray, 2006) en réduisant les risques et en augmentant la qualité des systèmes (Hardgrave et al., 2003). Que ce soit à un niveau organisationnel ou individuel, les routines sont de puis- sants vecteurs pour assurer la fiabilité et une certaine forme d’efficacité dans l’atteinte des objectifs (Butler et Gray, 2006). Un des objectifs de l’institutionnalisation de contrôles et de « bonnes pratiques » repose en effet sur la réduction des erreurs et de la variation des résultats. La fiabilité passe ainsi par la mise en place d’une variété de structures, no- tamment de contrôle (Lyytinen et al., 1998). Si les routines sont essen- tielles pour améliorer la fiabilité du processus de développement pro- duit, elles présentent néanmoins des limites ; elles préparent mal aux situations d’incertitude (Clarke, 1993) et permettent, certes, de réduire les erreurs humaines simples, mais pas de résoudre des problèmes complexes, car elles ne prévoient que des situations et des contextes connus et préétablis (Journé, 2005). Les routines contribuent donc au respect des procédures de développement produit mais ne sont pas suffisantes pour assurer une fiabilité globale du processus. La fiabilité repose aussi sur la vigilance personnelle et collective des acteurs (But- ler et Gray, 2006). Alors que la fiabilité par les routines permet de réduire les situations d’erreurs humaines simples, les approches fondées sur la vigilance des acteurs se focalisent sur la contextualisation des problèmes et les ex- pertises des acteurs pour les résoudre (Weick et al., 2000). Pour aug- menter la fiabilité dans les activités de développement, il faut motiver les acteurs, maintenir leur attention tout en leur laissant des marges de manœuvre, ce que permet une approche « semi-structurée » (Okhuy- sen et Eisenhardt, 2002). En effet, solutionner un problème complexe ne relève pas toujours d’un choix entre des options existantes, mais le plus souvent de la création de nouvelles solutions (Weick et al., 2000). La différence essentielle entre la fiabilisation par les routines et celle par la vigilance des acteurs réside dans la place laissée aux acteurs dans la prise de décision (Butler et Gray, 2006). La vigilance des ac- teurs peut intervenir à deux niveaux. Au niveau individuel, elle passe par la mise en place de systèmes d’incitation (formations, procédures, primes pour respect d’objectifs de formalisation de connaissances par exemple) pour encourager les acteurs à améliorer la fiabilité du déve- loppement produit. Au niveau collectif, elle repose sur des décisions 302 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle fondées sur des confrontations d’expertises (Weick et al., 2000). La vigilance collective implique le passage d’une logique hiérarchique et centralisée à une logique partagée et plus décentralisée. Elle requiert des capacités de détection rapide des problèmes et des opportunités. La fiabilité dépend donc à la fois des routines organisationnelles et du comportement des acteurs à travers leur vigilante implication. Ces deux approches sont appréhendées comme complémentaires. Une structuration minimale du processus de développement peut être réa- lisée grâce à l’aide de technologies intégrant tous les acteurs du dé- veloppement produit comme PLM. La mise en place de PLM vise ainsi à modifier les routines organisationnelles et l’implication des acteurs afin d’améliorer la fiabilité du processus de développement (baisse des erreurs et réduction des délais). La productivité : une deuxième dimension de la perfor- mance du développement Afin de rester compétitives, les organisations cherchent à réduire le temps de développement des produits. Cette nécessaire accélération du processus de développement a toujours été, et reste, une des pré- occupations clefs du développement de nouveaux produits (Cooper et Kleinschmidt, 1990 ; Clark et Fujimoto, 1991 ; Brown et Eisenhardt, 1997 ; Iansiti et MacCormack, 1997). Un des moyens pour accélérer le développement produit est d’en améliorer la productivité, qui peut être vue à travers la productivité en valeur, l’efficience ou la productivité en nature (Rowe, 1994). – La productivité en valeur correspond au rapport entre l’output mesu- ré en valeur monétaire et les ressources consommées. Par exemple, la croissance du chiffre d’affaires par tête est un objectif stratégique qui s’exprime en productivité en valeur. Mais, sauf exception, le chiffre d’affaires dépend lui-même de tellement de variables qu’il est illusoire de pouvoir démontrer quoi que ce soit à partir d’un output tel que le chiffre d’affaires ou la marge sur un produit. – Il convient donc de trouver un instrument de mesure de la produc- tivité qui soit plus proche de la problématique du traitement de l’effi- cience du processus étudié. Une organisation améliore son efficience si elle consomme moins pour produire autant ou si elle maintient son niveau de dépenses en produisant davantage. Classiquement, le coût unitaire d’un projet et, ici, le rapport entre le taux de renouvellement des produits et les ressources consommées issus du processus de développement sont considérés comme des indicateurs d’efficience. – La productivité en nature compare quant à elle les quantités produi- tes à l’effectif donné. Elle est mesurée par des indicateurs physiques comme le nombre de projets gérés rapporté à l’effectif (productivité apparente du travail) ou comme le nombre d’heures par projet. C’est cette productivité en nature que nous retenons car, comparant les quantités produites à l’effectif donné, elle fournit des indicateurs simples et opérationnels qui ont l’avantage de coller à la réalité du pro- cessus de développement produit. Sous réserve que la complexité des projets soit stable au sein d’une même famille de produits, on peut, en 303 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle suivant la productivité en nature, en déduire la contribution des chan- gements organisationnels et de la mise en œuvre de technologies de l’information comme PLM. La mesure du temps passé sur les principa- les opérations de développement produit, et donc du délai de dévelop- pement, constitue la mesure empiriquement retenue par les ingénieurs et les personnes en charge des réorganisations et des changements. Ainsi, Torkzadeh et al. (2005) définissent la productivité liée à la tech- nologie comme « la manière dont une application informatique améliore le rendement de l’utilisateur mesuré en unité de temps » (ibid., p. 108). Ce gain de rendement relatif est à la fois la mesure la plus pragmatique et celle qui permet d’identifier précisément les effets des fonctionnalités d’une technologie sur la productivité des individus au niveau de leurs tâches (Kraut et al., 1989 ; Goodhue et Thompson, 1995 ; Banker et al., 2001; Torkzadeh et al., 2005). Il reste toutefois difficile de mesurer la productivité en nature sur un processus de développement produit, celui-ci étant peu structuré au début du projet et comprenant de nom- breuses itérations entre les acteurs sur un même objet. Nous tentons de surmonter cette difficulté en mesurant les gains de productivité en nature suite au déploiement de PLM de plusieurs manières : nombre de projets gérés par effectif et par an, temps de réalisation des tâches, et temps de développement. Cette analyse permet d’examiner si les gains de productivité en nature ont une traduction stratégique, que ce soit à travers la capacité à développer plus de nouveaux produits ou par la ré- duction du temps de cycle. Si de nombreuses recherches ont porté sur la productivité, le lien entre l’intégration des connaissances (permises par PLM notamment) et la productivité n’a pas été démontré. Les développements qui précèdent sur la vigilance des acteurs et les routines organisationnelles comme vecteurs de fiabilité, ainsi que sur le rôle clé supposé de l’intégration des connaissances pour la fiabilité, mais aussi la productivité (même si ces liens théoriques n’ont pas été démontrés dans la littérature), nous conduisent à proposer le cadre conceptuel exploratoire qui suit (cf. figure 1). Il sera mis à l’épreuve dans deux contextes de développement différents, le développement interne et le codéveloppement, afin d’identifier un possible impact dif- férencié de PLM sur la performance du processus de développement selon le contexte de développement. Figure 1. Cadre conceptuel 304 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle UNE ÉTUDE DE CAS LONGITUDINALE DANS DEUX CONTEXTES Nous présentons ici la méthodologie qualitative longitudinale ainsi que l’étude de cas et les deux contextes de développement. Méthodologie Étude de cas longitudinale rétrospective et par observation directe Cette recherche est fondée sur l’analyse des changements avant et après l’introduction de PLM sur une famille de produits d’une entre- prise. Mesurer les gains de productivité et de fiabilité liés à la mise en place de TIC est difficile dans le cas de projets de développement de nouveaux produits, ceux-ci se caractérisant par de nombreuses incerti- tudes. Pour isoler la contribution des TIC, il conviendrait d’identifier les autres facteurs qui peuvent potentiellement contribuer à expliquer les gains de productivité et de fiabilité – comme le niveau d’externalisation du produit fini, les mouvements de personnel avec les effets d’expé- rience, la complexité des projets ou le degré de nouveauté des projets. En nous focalisant sur une seule famille de produits, nous neutralisons un grand nombre de ces facteurs – à l’exception du niveau d’externa- lisation du produit fini qui peut varier à l’intérieur d’une même famille, mais qui est pris en compte dans le contexte de développement. Notre approche est fondée sur une étude de cas longitudinale qui com- bine approche rétrospective dans le cas du développement interne et par observation directe dans le cas du codéveloppement (Leonard- Barton, 1990 ; Eisenhardt et Graebner, 2007). Les études rétrospecti- ves recomposent un événement dans le temps après que celui-ci s’est déroulé et font appel à des données secondaires archivées et à des données primaires retraçant l’évolution d’un phénomène. L’observa- tion directe pendant trois années a permis de tester et de rejeter par des expérimentations de l’esprit de nombreuses hypothèses (Camp- bell, 1975). De plus, l’observation ayant lieu avant, pendant et après l’introduction de PLM, le design de la recherche est amélioré (Camp- bell, 1988), même si on ne peut considérer avoir écarté tous les biais liés à l’observation. Le mode de collecte et d’analyse des données est essentiel pour garantir l’objectivité des données collectées et com- prendre le phénomène étudié. Collecte de données Les entretiens, les observations et les données secondaires (courriels et objets historisés notamment) ont constitué les données principales dans cette recherche. Pour limiter les problèmes d’oubli et de rationali- sation a posteriori concernant les entretiens rétrospectifs liés au cas de développement interne, nous avons recoupé les entretiens entre eux, et avec des données secondaires. Nous avons demandé aux personnes interrogées de repositionner, dans un premier temps, les événements historiquement et, seulement dans un second temps, d’établir les liens entre les événements. Pour accroître la validité interne, nous avons stocké la quasi-totalité des données (entretiens, documents, courriels, statistiques liées aux tâches de développement produit) sous forme 305 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle électronique dans une application dédiée aux méthodes qualitatives : l’application Nvivo de l’éditeur QCR. L’analyse intra-cas repose sur le principe de triangulation des données : entretiens, observation, données secondaires et statistiques effectuées à partir de l’application PLM. La triangulation par les méthodes passe par le recours à l’observation participante et non participante, à des entretiens enregistrés et non enregistrés, à une analyse documentaire ainsi qu’à des artefacts tels que les analyses de logs applicatifs dans PLM (cf. tableau 1). Tableau 1. Collecte des données COLLECTE DES DONNEES phase de l’analyse longitudinale avant PLM pendant l’implémentation de PLM après PLM Entretiens collectifs non enregistrés 12 8 12 indépendants non enregistrés 24 22 26 individuels non enregistrés N/A N/A 25 Collecte de données secondaires Données secondaires Tous les documents : mail, pro- cédures, spécifications, compte rendus de réunion Documents sur le paramé- trage, options de paramétrage, tests... Eléments de communica- tion, formations, mails... Observations Notes de terrain, observation du terrain 3 jours par semaine pendant 3 ans Notes de terrain quotidiennes Notes de terrain quotidiennes Notes de terrain quotidi- ennes Artefacts Artefacts Statistiques et comptages dans les applications de développe- ment produit qui sont encore accessibles car historiques Statistiques sur PLM pour nombre de projet, objets validés, objets avec indices de révision... date de déploiement de la technologie PLM Développement interne : Février 2004 Co-développement : janvier 2007 Dates Durée de l’analyse De février 2006 à juin 2008 Nous avons conduit des entretiens avec les acteurs des projets en dé- veloppement interne et en co-développement pour identifier la nature des gains de productivité. Ces entretiens ont été réalisés auprès d’ac- teurs aux profils très différents : marketing, ingénieur développement, technicien qualité, directeur général, etc. (cf. annexe 1 pour la liste des 25 entretiens). D’une durée moyenne de 1 h 30, ces vingt-cinq entre- tiens ont été enregistrés et retranscrits intégralement, puis validés par les acteurs. Nous avons demandé de présenter la situation avant et après l’introduction de PLM afin d’examiner les changements. Dans un deuxième temps, les données statistiques sur les gains (cf. annexes 2 et 3) ont été récupérées et analysées de deux façons dif- férentes : – Récupération des éléments donnés pour vérifier la qualité des in- formations reçues. Les informations concernant la période précédant l’introduction de PLM sont essentiellement les documents élaborés pendant la phase d’analyse des besoins dans le cadre de la mise en place de PLM, donc des données secondaires archivées – comme les organigrammes et les cartographies des applications informatiques ou la formalisation des processus. Nous avons collecté des statistiques 306 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle sur les projets et sur les objets dans les applications utilisées avant PLM et dans l’application PLM. – Vérification avec des collègues issus du même service et avec les responsables hiérarchiques, validation avec les chefs de service, les directeurs industriel et marketing de l’activité et avec la direction R & D et marketing groupe. Nous avons aussi conduit une centaine d’entretiens individuels et col- lectifs, non enregistrés, en tant qu’observateur participant du projet PLM pendant trois ans. Nous avons ensuite mené, dans une dernière étape, une analyse détaillée des artefacts de productivité et fiabilité suite au déploiement de PLM. Codage Nous avons réalisé une analyse descriptive puis un codage axial des données. L’analyse descriptive consiste à regrouper des catégories par thème. Ces catégories correspondent aux unités de sens choisies ayant une signification proche (Huberman et Miles, 1991). Concrète- ment, nous avons intégré les données collectées, comme les entre- tiens, dans le logiciel Nvivo. Après avoir finalisé la catégorisation des- criptive, l’analyse explicative a été faite grâce à un codage de second niveau, dit « axial » (Strauss et Corbin, 1990). Description du cas Le groupe étudié est un des leaders mondiaux du petit électroména- ger. Ce groupe français est marqué par une culture d’intégration forte née des nombreuses opérations de croissance externe menées depuis plus de trente ans. Il intervient sur des marchés internationaux avec une contrainte d’innovation continue et répétée pour survivre et croître. Pour assurer une plus grande réactivité, il cherche à développer des synergies entre les sites et externalise une part croissante des com- posants industriels et des produits finis, surtout en Chine. Toutefois, 40 % des produits finis sont encore fabriqués en Europe. Ce groupe développe plus de 200 nouveaux produits par an avec une équipe de R & D de plus de 500 personnes. PLM constitue un outil triplement stratégique pour ce groupe industriel : « Il y a un aspect discipline des processus qui est stratégique. Le premier élément stratégique [de PLM] c’est de rigoriser nos processus [de R & D]. Une fois que PLM est déployé, ces processus sont non seulement clairs mais aussi lisibles, c’est pratiquement impossible de s’en affranchir. Il est temps de les durcir maintenant, à la fois pour des raisons de qualité mais aussi parce que le groupe continue à s’agrandir et que le besoin de standardisation est de plus en plus important » (directeur R & D groupe). Dans ce groupe, rigueur et fiabilité du processus sont synonymes. Les deux autres objectifs stratégiques assignés à PLM sont la recherche de gains de productivité et l’aptitude de PLM à accompagner le mou- vement de distribution géographique des équipes et du codéveloppe- ment sur une même plate-forme technique. La famille « Soin du linge » est composée des fers à repasser, centra- les vapeur et détacheurs. Cette activité, qui constitue un contributeur important du résultat global de ce groupe industriel, est répartie sur plusieurs sites en Europe (France et Allemagne) et en Chine (Shan- 307 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle ghai, Hong Kong notamment). Le développement des produits repo- se sur une problématique de conception plus que d’industrialisation. Les produits conçus disposent d’une nomenclature importante (autour d’une centaine de composants) et peuvent se révéler relativement complexes, techniquement parlant, notamment à cause des problèmes de sécurité des produits. À partir de trois ou quatre modèles génériques par projet, des variantes de produits finis sont déclinées, variantes qui correspondent aux spécificités géographiques, électriques, juridiques et culturelles des pays de commercialisation visés. Le temps moyen de développement d’un fer à repasser est de 12 mois. En développement interne, le bureau d’étude (BE) principal est basé en France et développe une dizaine de projets par an. Il comprend une trentaine de personnes dont six chefs de produits, une quinzaine de techniciens et deux gestionnaires des données techniques. Les projets de développement interne sont considérés comme des projets comple- xes car ils contiennent des évolutions en termes d’architecture du pro- duit fini et de nouveauté technologique. Les ressources humaines pour le développement interne sont localisées en France et en Allemagne pour les équipes techniques, et en France au siège de l’activité pour les équipes marketing. À l’inverse, pour le codéveloppement, les projets sont essentiellement liés au renouvellement et à l’animation des gammes, relativement sim- ples au niveau technologique. Les ressources pour le codéveloppe- ment produit sont réparties entre l’Europe (France et Allemagne) pour le BE et le marketing, et la Chine pour les équipes support. L’équipe dédiée au co-développement est constituée de trois chefs de projet (ingénieurs) basés en France, trois ingénieurs support en Chine, locali- sés chez des fournisseurs (ou proches), et deux techniciens qualité en Chine. Ces acteurs en Chine ont pour objectif de faciliter le transfert de connaissances et l’accompagnement des fournisseurs dans le déve- loppement produit. En 2004, ce groupe industriel a décidé de déployer PLM et a choisi la solution TeamCenter Engineering (TCE) de l’éditeur Siemens, un des trois leaders mondiaux. L’objectif était de mieux intégrer et d’har- moniser le processus de développement produit, auparavant morcelé. Avant PLM, les informations liées aux projets étaient gérées sur format papier dans plusieurs applications hétérogènes et décentralisées. Les informations de gestion et de production étaient disponibles dans SAP, les 2D et 3D dans les applications CAO. Les informations techniques étaient gérées dans une application dédiée de type SGDT. La solution PLM représente un coût de 730 000 euros pour « Soin du linge ». La solution PLM retenue dispose de fonctionnalités de communication, de stockage et de consolidation (cf. Pavlou et El Sawy, 2006), synthéti- sées dans l’annexe 4. 308 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle RÉSULTATS Nous présentons les résultats de la contribution de PLM à la fiabi- lité (III.1) et à la productivité du processus de développement produit (III.2). Ces résultats empiriques nous conduisent à élaborer certaines propositions. Contribution de PLM à la fiabilité du processus de dé- veloppement produit Après avoir traité des dimensions de la fiabilité, nous identifions les moyens permettant d’améliorer la fiabilité et les limites de la contribu- tion de PLM à la fiabilité du processus de développement produit. Mesure de la fiabilité du développement produit selon le contexte Respect des délais : réduction du délai moyen des retards sur les pro- jets. Suite au déploiement de PLM, nous constatons une baisse des retards sur les échéances clés des projets (cf. tableau 2). Ainsi, le retard moyen est passé de 20 à 12 jours sur les projets de développe- ment interne, et de 13 à 9 sur le codéveloppement, ce qui signifie que le respect des engagements sur les projets s’est amélioré. La propor- tion des projets ayant un retard de moins de 30 jours augmente, ce qui témoigne d’une amélioration de la fiabilité des projets et d’une meilleu- re garantie quant à la date de commercialisation. Cette amélioration s’explique en partie par le fait que PLM permet de mieux structurer et de respecter les jalons clés des projets et, par là même, d’anticiper et de traiter plus rapidement des erreurs simples dans le partage de connaissances explicites ou des risques identifiés sur les projets. Tableau 2. Moyenne des retards sur les projets Retard moyen sur le delai de développement prévu Avant PLM Après PLM Projets de développement interne + 20 jours +12 jours Nombre de projets de développement interne 10 13 % de projets de développement interne ayant moins de 30 jours de retard 76% 80% Projets de co-développement + 13 jours +9 jours Nombre de projets de co-développement 10 15 % de projets de co-développement ayant moins de 30 jours de retard 79% 82% S’il est difficile d’établir une relation causale directe entre l’arrivée de PLM et la réduction des retards sur les projets, plusieurs éléments per- mettent cependant d’associer cette réduction des retards au déploie- ment de PLM. En effet, d’une part, sur la période analysée, la com- plexité technique moyenne des projets n’a pas évolué. D’autre part, il n’y a pas eu non plus de mouvements importants dans les équipes, qui auraient pu avoir un impact sur la maturité des compétences des acteurs. Par ailleurs, l’analyse des entretiens montre que les acteurs associent une partie significative des gains en termes de délai au dé- ploiement de PLM, qui permet, selon eux, de mieux structurer le projet, d’améliorer le partage des connaissances explicites et de réduire les erreurs de coordination. Diminution des erreurs. La diminution des erreurs dans le processus de développement produit est analysée au travers des erreurs dans 309 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle les échanges de connaissances sur le projet. Quatre types de glit- ches (Hoopes et Postrel, 1999) ont été identifiés (cf. tableau 3). Nous constatons une diminution des glitches liés aux routines (glitch 1) et au respect des procédures (glitch 2). PLM permet de disposer, quasiment en temps réel, de l’intégralité des informations partagées sur le projet à un endroit unique. PLM a introduit plus de rigueur dans la gestion des jalons clés des projets et dans la définition d’un répertoire commun de management du projet accessible à tous les acteurs projet, ce qui évite certaines erreurs de communication sur les projets. Avant PLM, le partage des connaissances explicites était morcelé entre différen- tes applications métiers, ce qui ne permettait pas de disposer d’une vision consolidée de l’état d’avancement d’un projet. Les glitches rési- duels (3 et 4) correspondent à des problèmes complexes d’échange de connaissances. Les TIC asynchrones ne sont que de peu d’utilité pour faciliter le partage de ce type de connaissances comportant un haut niveau d’interdépendance ou de nouveauté. Difficilement formalisable, ce type de partage nécessite donc des interactions synchrones entre acteurs. Par ailleurs, la nature même de ces connaissances comple- xes, souvent tacites, explique le peu d’effet de PLM pour résoudre ce type de glitch. Cela nous permet d’avancer la proposition suivante2: P1 : PLM améliore la fiabilité du processus de développement pro- duit, mesurée par la baisse des erreurs et la réduction des retards sur les projets. Tableau 3. Erreurs de communication dans le processus de dévelop- pement produit Erreurs de communica- tion sur le processus de développe- ment produit Développement interne Co développement Exemples de glitches Fonctionnalité PLM faciitant la résolution du glitch Volume de glitches avant PLM Glitches résolus après PLM Volume de glitches avant PLM Glitches résolus après PLM Glitch 1 : manque de synchronisa- tion entre les ac- teurs ou manque de routines organisation- nelles faible quasi- totalité fort quasi- to- talité Difficultés pour retrouver des informations échangées entre les acteurs due à un probleme de stockage des données produit et rojet : multiples outils utilisés Structure de stockage des données unique avec localisation des objets projet et produit Difficulté de traçabilité sur les versions des documents échangés. Exemple des cahiers des charges marketing avec des modifications des besoins non prises en copte par les autres départements Statut et indice de réunion sur otus les objets : traçabilité Manque de communication sur l’état d’avancement du projet en global pour l’ensemble des acteurs. Exemple : retard sur certaines étapes partiel- lement ou non répercutées à l’ensemble des acteurs au projet Notification et alertes Glitch 2 : les procédures sont respectées mais une contrainte clef n’a pas tét communiquée Relative- ment faible Une grande partie Fort Une grande partie Manque de représentation partagés entre tous les acteurs projet en phase de conception. Les éléments 2D et 3D étaient réservés aux personnes disposent d’outil CAO. Certaines erreurs de conception produit n’étaient pas détectées par la qualité ou les normes en phase amont de conception. Retards sur certaines taches car une contrainte n’a pas été communiquée un bon moment : exemple de changements dans le cahier des charges maarketing non répercuté à l’ensemble des acteurs Visualisateur 2D et 3D disponibles pour tous les acteurs Validation et diffusion des connaissances explicites par des workflows Glitch 3 : com- plexité du partage de connaissances : connaissance non appropriée par une partie : souvent le ré- cepteur Relative- ment faible Un nombre limité Relative- ment fort Un nom- bre limité Difiiculté d’identification des contraintes techniques en phase de concep- tion produit pour certains acteurs. Exemple de l’équipe SAV qui n’avait pas de support pour avoir une représentation du futur produit Difficultés pour comprendre les contraintes mutuelles entre acteurs dis- posent de différentes répertoires de connaissance. Exemple de rapports laboratoires qui sont trop techniques pour être compris par les équipes marketing et qui impactent la date et le qualité du produit Visualisateur 2D et 3D disponibles pour tous les acteurs Pas de fonctionnalité PLM pour résoudre le glitch Glitch 4 : com- plexité du partage de connaissance : connaissance ambiguë pour l’emetteur et le récepteur Relative- ment faible Aucun Relative- ment fort Aucun Difficultés pour gérer la production de nouvelles connaissances pour des acteurs qui maîtrisent mal une nouvelle technologie. Difficultés pour gérer les interdépendances entre acteurs multiples surtout sur la phase de conception. Ainsi, en co développement, l’intégration des contraintes du fournisseur, du chef de projet et des acheteurs se révèle souvent complexe à résoudre. Elle nécessite des contacts directs pour solutionner les divergences. Pas de fonctionnalité PLM pour résoudre le glitch Pas de fonctionnalité PLM pour résoudre le glitch 2. Nous remercions un évaluateur anonyme qui a fait la suggestion d’aboutir à des propositions et en a également formulé quelques-unes. 310 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Des gains de fiabilité plus importants dans le contexte du codévelop- pement. Les gains de fiabilité liés à PLM sont plus importants pour le codéveloppement que pour le développement interne. Ce résultat est logique dans la mesure où des routines de fiabilisation et une forte coordination, facilitée par la colocalisation des acteurs préexistaient à PLM au sein du développement interne. Dans le cas du codévelop- pement, pour lequel la répartition géographique des acteurs (France, Allemagne, Chine) et l’appartenance à des sociétés différentes limitent le répertoire de connaissances commun entre les acteurs, PLM contri- bue à renforcer ce répertoire en définissant un espace de partage, des règles communes, des objets de connaissances prédéfinis (Mer- minod, 2007). L’accès à des fonctionnalités de représentation comme le visualisateur 3D et l’existence de fonctionnalités de traçababilité des échanges renforcent la fiabilisation des processus d’échange entre ac- teurs, tant internes au groupe qu’externes à celui-ci. PLM a donc mis l’accent sur les routines organisationnelles, les règles communes dans la coordination opérationnelle des projets et l’implication collective des acteurs et a amélioré la fiabilité du processus de co-développement. P2 : L’amélioration de la fiabilité grâce à PLM est plus sensible dans les contextes de codéveloppement que de développement interne Moyens permettant les gains de fiabilité Il ressort des résultats que les composantes de l’intégration des connaissances, et notamment le partage et la coordination, semblent favoriser les routines et la vigilance des acteurs. Routines organisationnelles et intégration des connaissances explici- tes. PLM a indirectement permis d’améliorer la fiabilité du processus par une meilleure coordination grâce à davantage de structuration des routines organisationnelles. L’approche stage gate de PLM pour la coordination projet oblige les acteurs à formaliser davantage les ob- jets de connaissances et à introduire plus de rigueur dans le déve- loppement produit. Les échanges entre acteurs sont facilités par les workflows de validation et de diffusion des objets qui permettent aux acteurs de s’assurer que les objets sont transmis et leurs contraintes intégrées. Ainsi, les contrôles sur les jalons clés du projet sont renfor- cés. PLM renforce également la fiabilité par un partage plus général d’ob- jets clés. En développement interne, 75 % des objets clés des jalons étaient partagés ; quasiment 100 % le sont avec PLM. Pour le codé- veloppement nous passons de 60 % avant PLM à 95 %. Ces objets sont mieux contrôlés puisqu’ils sont validés dans PLM (de 20 % à 90 % pour le codéveloppement, cf. tableau 4). PLM permet donc d’améliorer les routines organisationnelles par un meilleur partage et une meilleure coordination du projet : « PLM force à respecter les procédures groupe, à savoir le respect des prin- cipales échéances projet. Avec PLM, tout le monde a une manière identique de stocker, des règles ont été définies » (directeur général industrie groupe, juin 2007) 311 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Tableau 4. Nature des routines organisationnelles améliorées Nature Projets de développement interne Projets de co-développement Avant PLM Après PLM Avant PLM Après PLM Existance des objets du projet dans arborescence projet ~ 60% ~ 90% ~ 40% ~ 90% Existence du statut d’avancement sur les objets ~ 10% ~ 50% ~ 5% ~ 40% Exhaustivité des objets prédéfinis sur les jalons clefs du projet ~ 75% ~ 99% ~ 60% ~ 95% Validation des objets clefs du projet par le management intermédiaire ~ 40% ~ 90% ~ 20% ~ 90% Workflows peu processus clefs aucun processus clefs Nos observations et les entretiens montrent donc que l’amélioration re- lative de la fiabilité par PLM est non seulement réelle mais plus grande dans le cadre du codéveloppement que dans le cas du développement interne – ce qui va dans le sens de nos propositions 1 et 2. Par ailleurs, nous constatons que, si les routines sont améliorées, c’est essentiel- lement grâce à l’intégration des connaissances explicites (notamment le partage et la coordination) que permet PLM. La dimension « réuti- lisation des connaissances » joue surtout dans la durée, notamment entre projets, la fiabilisation du stockage des connaissances explicites du projet dans PLM permettant de capitaliser sur les connaissances existantes avec un niveau satisfaisant de confiance sur la qualité des données. P3 : L’intégration des connaissances explicites permise par PLM renforce les routines organisationnelles Vigilance des acteurs et intégration des connaissances explicites. PLM a permis l’amélioration de la transparence dans le partage des connais- sances projet et, indirectement, d’améliorer la vigilance des acteurs. Une traçabilité dans le partage des objets est assurée grâce à l’histo- risation des objets déposés dans PLM. Il est ainsi possible de voir qui a déposé l’objet, qui l’a modifié et quand, et de faire ainsi l’historisation des modifications. Il s’agit d’un système incitatif qui pousse les acteurs du projet à renforcer leur attention pour respecter les tâches du pro- cessus de développement. Les acteurs déclarent a posteriori être da- vantage sensibilisés individuellement à la fiabilisation du processus de développement produit. Les douze acteurs interrogés du co-dévelop- pement considèrent que la plus grande structuration du processus qui s’appuie sur PLM permet d’augmenter la vigilance. En revanche, seuls sept sur treize acteurs du développement interne estiment que PLM a renforcé leur vigilance dans une optique de fiabilisation du processus de développement3. « PLM a permis de renforcer les règles sur le processus de développement, d’amener plus de rigueur. Cet outil a fait évoluer le comportement des équipes en Chine qui sont plus vigilantes sur la qualité des documents échangés. Elles ont tendance aussi à détecter plus tôt les problèmes sur les projets » (chef de projet codéveloppement, juin 2007). 3. Dans une certaine mesure, PLM a égale- ment permis de limiter certains jeux politiques d’acteurs qui consistent à ne pas diffuser l’information (Hatchuel, 1994). Ainsi, avant PLM, certains « jouaient » avec le morcellement des connaissances explicites stockées dans plusieurs applications. Avec PLM, le partage des connaissances projet est plus transparent. Nous avons ainsi mis en évidence une réduc- tion de l’asymétrie informationnelle entre les acteurs projet grâce à PLM. 312 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle La coordination projet est davantage décentralisée avec PLM grâce à la centralisation des objets et à la définition de règles et de contrôles automatisés. Cela participe au renforcement de la vigilance réciproque entre les acteurs. Grâce à PLM, ils peuvent mieux se coordonner di- rectement et ainsi mieux anticiper les problèmes sans intervention du chef de projet qui devait très souvent assurer un rôle de pivot dans la relation avant la mise en place de PLM. PLM a permis un renforcement de la confrontation des expertises notamment sur la phase de concep- tion. Ainsi, la mise à disposition du visualisateur 3D pour l’ensemble des acteurs permet à ces derniers d’analyser très tôt les éventuelles erreurs ou problèmes de conception. Le département qualité a ainsi pu détecter des problèmes plus tôt sur plusieurs projets. Cependant, la vigilance collective sur les projets ne dépend que partiellement de PLM. En effet, la culture organisationnelle, l’organisation, la complexité des produits sont autant de facteurs qui peuvent influencer la vigilance collective des acteurs. P4 : L’intégration des connaissances explicites permise par PLM améliore la vigilance des acteurs. Limites de la contribution de PLM à la fiabilité du processus de développement PLM : support d’intégration de connaissances matures. 75 % des échanges sur les phases préliminaires de conception restent réalisés par courriel ou par interaction directe. Le courriel est considéré comme plus intuitif et permet de mieux contextualiser les échanges et de li- miter la diffusion des objets à un nombre restreint de personnes. Les courriels font souvent 5 à 6 pages, détaillant les éléments de contexte de l’échange de documents alors que PLM se limite au traitement d’ob- jets faiblement contextualisés. PLM apparaît principalement comme un outil d’intégration des connaissances matures et peu comme une solution qui supporte les processus émergents de conception. Contribution de PLM à la productivité du processus de développement produit Nous présentons ici les résultats concernant la mesure de la produc- tivité à travers la productivité en nature et le temps de développement produit puis l’effet de l’intégration des connaissances sur les gains de productivité ainsi que leurs limites. Mesure des gains de productivité en nature selon le contexte Productivité en nature. Pour le développement interne, nous consta- tons une augmentation de 30 % des projets par an avec une légère baisse des effectifs (cf. tableau 5). La productivité apparente du tra- vail est ainsi améliorée de 33 %. Dans le cadre du codéveloppement, cette amélioration est de 10 %, compte tenu d’une augmentation de 26 % de l’effectif, hors fournisseurs chinois en charge d’une partie de la conception et de l’industrialisation. 313 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Tableau 5. Gains de productivité apparente du travail et gain de temps relatif Nature Avant PLM Après PLM Evolution en % Développement interne Nombre de projets par an 10 13 30% Effectif interne 76 74 -3% Productivité apparente du travail 0,13 0,18 33% Gain de rendement relatif 9,7% Co développement Nombre de projets par an 10 15 50% Effectif interne 15 19 26% Productivité apparente du travail 0;67 0,79 10% Gain de rendement relatif 7,1% Le gain de rendement relatif, calculé à partir des temps de réalisation des tâches de développement déclarés par les acteurs avant et après PLM (cf. annexes 2 et 3), est de 9,7 % pour le développement interne et de 7,1 % en codéveloppement (tableau 5). Ces résultats permettent d’établir des gains de productivité moins importants pour le codéve- loppement. Ces gains sont principalement imputables à PLM. En effet, en raisonnant globalement pour les deux contextes, les effectifs sont relativement stables : de 2000 à 2007 comme de 2004 à 2007, les effectifs de développement ne varient que de 8 % par an en moyenne. Ces mouvements concernent principalement les acteurs du marketing. Ainsi, on peut considérer que les gains de productivité sont bien liés à l’introduction de l’outil et non à des changements liés à des personnels nouveaux plus qualifiés. Ce sont bien les mêmes personnes, pour la plupart, qui ont fait l’objet de la comparaison. Les gains de productivité par type d’acteurs, tant pour le codévelop- pement que pour le développement interne, sont fournis dans les an- nexes 2 et 3. Ils se répartissent de manière relativement homogène entre tous les métiers du développement produit. Temps de développement produit. PLM ne contribue pas à réduire si- gnificativement le temps de développement des nouveaux produits. En effet, il existe un temps incompressible de développement, un chemin critique sur le projet qui n’est pas touché par les gains de productivité (tableau 6). Tableau 6. Durée moyenne des projets avant et après PLM Durée moyenne de développement en mois Avant PLM Après PLM Evolution en %Nb projets Durée Nb Projets Durée Projets de développement interne 10 12,5 mois 13 12 mois 4% Projet de co-développement 10 10 mois 15 10 mois 0% Si PLM permet de gérer plus facilement davantage de projets en pa- rallèle, cette technologie ne permet des gains dans le temps de dé- veloppement qu’à la marge. PLM permet une meilleure parallélisation des projets, mais pas de réduire le délai global de développement. En 314 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle fait, PLM améliore la productivité des tâches unitaires à faible valeur ajoutée : « PLM ne permet pas de réduire le temps de développement du produit mais de gagner de la productivité sur certaines tâches. Le développement produit passe par des jalons incontournables ; PLM permet probablement de gérer plus de projets en parallèle. Quand je suis arrivé, on gérait un à deux projets pilotes, maintenant on est plutôt à trois ou quatre projets par pilote » (Pilote projet « Soin du linge », juin 2007). P5 : PLM améliore la productivité en nature du processus de dé- veloppement produit. P6 : L’amélioration de la productivité en nature grâce à PLM est plus sensible dans les contextes de développement interne que de codéveloppement. Intégration des connaissances et gains de productivité L’intégration des connaissances explicites constitue un moyen d’amé- liorer la productivité du processus de développement produit. La pro- ductivité de PLM passe par la capacité de l’application à améliorer les tâches de partage, de coordination des équipes et de réutilisation des connaissances (cf. tableau 7). Tableau 7. Productivité par l’intégration des connaissances explicites Ana lyse situation avant/après déploiement de PLM Développement interne Co-développement Intégration des connaissances Description Gains de productivité en % Gains de productivité en % Partage • Centralisation des ojets projets • Structuration espace projet et objets clefs • Visualisateur 3D disponible pour tous 5,8 % 2,9 % Coordination • Workflows • Tableaux de bord • Statuts des objets 3,1 % 2,9 % Réutilisation • Standardisation gestion de l’espace projet • Fonctions de recherche • Cas d’emploi 0,8 % 1,3 % Total 9,7 % 7,1 % Partage des connaissances. C’est à ce niveau que l’amélioration de productivité constatée est la plus forte. Elle peut s’expliquer par certaines fonctionnalités de PLM, qui assure un accès immédiat aux connaissances explicites du projet grâce à une centralisation dans une seule base de données. PLM permet ainsi de passer d’un mode d’inté- gration des connaissances assuré par un pivot, le chef de projet, à un mode d’intégration plus décentralisé avec une disponibilité en temps réelle des objets partagés pour tous les acteurs. Les workflows contri- buent à fluidifier la circulation de connaissances explicites comme la validation de documents clés. Grâce à PLM, on observe une améliora- tion de la productivité avec des gains sur des micro-processus et sur des tâches unitaires comme la génération automatique de documents (fiche technique) à partir de composants stockés dans PLM. Des outils permettent aussi une représentation partagée du nouveau produit sur 315 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle la phase de conception grâce à la mise à disposition d’un visualisateur 3D accessible à tous les acteurs. Cette fonctionnalité de PLM facilite le travail de validation des options de conception aussi bien pour les chefs de projet que pour les acteurs marketing, qualité et/ou normes. Avant PLM, seuls les techniciens disposaient d’outils de conception assistée par ordinateur (CAO) pour visualiser les produits en 2 ou 3 D. Les gains de productivité dans le partage des connaissances explicites sont plus importants dans le cadre du développement interne (5,8 %) que dans celui du codéveloppement (2,9 %). Cette différence s’expli- que par le fait que le partage des connaissances est amélioré entre ressources intra-organisationnelles pour le codéveloppement, mais plus difficilement avec les fournisseurs, qui accèdent indirectement aux connaissances par l’intermédiaire de l’acteur du groupe localisé chez eux. Ils n’ont pas d’accès direct à PLM pour des raisons de sécurité de l’accès à l’application. Coordination. Les gains de productivité dans la coordination sont assez sensibles, avec 3,1 % pour le développement interne et 2,9 % pour le codéve- loppement produit. L’usage de PLM permet d’expliquer ces gains de productivité, notamment dans le monitoring des projets grâce à la consolidation automatique des données projet dans des tableaux de bord. PLM facilite la coordination par ajustements mutuels grâce à la centralisation des connaissances explicites du projet à un endroit uni- que ainsi que la prise en compte des prescriptions réciproques et des contraintes entre acteurs. Ainsi, le responsable marketing qui met à disposition une nouvelle version de cahier des charges sait que PLM constitue le référentiel projet et que les acteurs du monde technique se doivent de prendre en compte les nouvelles révisions d’objets dans PLM. Cela était moins facile auparavant avec les courriels. Réutilisation des connaissances. Les gains dans la réutilisation de connaissances explicites sont plus relatifs avec respectivement 0,8 % pour le développement interne et 1,3 % pour le co-développement. Cela s’explique par le fait que l’utili- sation de PLM pour les projets est relativement récente : la reprise des données des anciennes applications vers PLM a été limitée aux projets en cours lors de la migration. Plusieurs fonctionnalités permettent d’ex- pliquer les gains sur la réutilisation d’objets. Les acteurs projet peuvent plus aisément réutiliser des connaissances explicites d’anciens projets ou de projets gérés par d’autres acteurs grâce à la structuration de l’es- pace de stockage des connaissances explicites des projets dans PLM. PLM permet aussi de capitaliser les connaissances de tous les servi- ces associés au développement produit. Le service industrialisation bé- néficie ainsi de la structuration des connaissances explicites dans PLM – qui facilite la réutilisation de plans par exemple. Avant PLM, la réutili- sation de connaissances d’anciens projets était marginale – et celle de composants industriels quasiment inexistante. L’existence d’une base de données unique pour tous les projets favorise la réutilisation d’objets tels que le planning ou la décomposition du coût de revient produit. Les objets documentaires (cahier des charges par exemple) sont égale- ment réutilisés. 316 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle P7 : L’intégration des connaissances explicites permise par PLM améliore la productivité en nature du processus de développe- ment produit. Des gains de productivité liés à PLM à relativiser PLM permet d’automatiser certaines tâches du développement pro- duit mais ne solutionne pas les problèmes de collaboration comple- xes. PLM constitue une application structurante qui supporte certaines compétences organisationnelles comme l’intégration des connaissan- ces explicites sur le processus de développement et partiellement les compétences opérationnelles (à travers le visualisateur 3D par exem- ple). DISCUSSION ET CONCLUSION Nous avons mis en évidence que PLM facilite une structuration mini- male (Okhuysen et Eisenhardt, 2002) du processus de développement produit, ce qui permet, in fine, d’améliorer la performance en termes de productivité et de fiabilité. Une approche longitudinale a permis de mieux contextualiser les résultats et de réaliser une analyse détaillée par variation de la situation avant et après l’introduction de PLM. Nos propositions sont supportées par les résultats qui peuvent être synthé- tisés en quatre points : – La fiabilité, mesurée par la baisse des délais et des erreurs, est amé- liorée par le renforcement des routines et la vigilance des acteurs. Il ressort que ces deux aspects sont liés à l’intégration des connaissan- ces explicites que permet PLM. – PLM contribue aux gains de productivité en nature sur les tâches grâce à l’intégration des connaissances mais ne permet pas de réduire le temps de développement produit, celles-ci n’étant pas sur le chemin critique. – Dans le groupe étudié, et dans les deux contextes analysés, fiabilité et productivité s’accroissent toutes les deux et n’apparaissent donc pas complètement antagonistes. – Toutefois, dans le contexte du codéveloppement, la fiabilité du pro- cessus augmente davantage que la productivité ; c’est l’inverse dans le cas du développement interne. Nous discutons plus précisément des trois résultats suivants : la com- binaison de la productivité et de la fiabilité du développement produit, l’influence du contexte sur les résultats en matière de performance, et l’intégration des connaissances explicites, grâce à laquelle PLM per- met cette amélioration conjointe de la productivité et de la fiabilité. Combiner productivité et fiabilité du développement pro- duit dans les environnements industriels classiques Les entreprises industrielles classiques peuvent-elles combiner pro- ductivité et fiabilité dans le développement produit ? Si plusieurs tra- vaux tendent à montrer que d’autres types d’entreprises doivent faire un choix entre ces deux dimensions de la performance (Weick et Roberts, 317 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle 1993), notre recherche met en avant le caractère non antagoniste des deux dimensions, et ce dans les deux contextes étudiés. Ainsi, dans l’activité de développement produit du secteur manufacturier, le respect des échéances clés du projet et la qualité du produit fini représentent des critères aussi essentiels que les gains de productivité (Marciniak et Pagerie, 1999) et PLM contribue à conjuguer fiabilité et productivité. PLM renforce les routines sans trop alourdir les tâches, ce qui accroît la fiabilité par le contrôle et la validation des objets clés à certaines éta- pes importantes du processus4. Les routines intégrées dans le système éliminent certaines redondances – à l’inverse de ce qui se produit dans les environnements de haute fiabilité, qui nécessitent des redondan- ces dans les processus de contrôle et des simulations d’incidents pour améliorer les capacités organisationnelles et individuelles à faire face à des situations complexes et nouvelles (Weick et Roberts, 1993 ; Weick et alii, 1999). Certes, au sein du groupe étudié, le manque de fiabilité sur le développement n’a pas de conséquence vitale, comme c’est le cas pour le nucléaire, l’atterrissage sur un porte-avions ou la gestion d’un incendie. Cependant, face aux conséquences stratégiques liées au non-respect des temps de développement et de qualité vis-à-vis des clients, les entreprises cherchent à fiabiliser leurs processus. Dans le cadre de la fiabilisation d’un développement « classique », il est donc important de disposer d’une démarche structurée et d’outils de contrôle qui permettent de combiner productivité et fiabilité. Cette démarche reste « semi-structurée » (Okhuysen et Eisenhardt, 2002) dans la mesure où les outils n’exercent pas un contrôle permanent mais laissent une latitude décisionnelle indispensable dans le dévelop- pement produit et renforcent la vigilance. La « discipline » et la rigueur ne signifient pas le conformisme, mais le respect de certaines routines et l’attention plus grande à ce qui est rendu visible par PLM. Malgré le caractère déjà bien structuré du développement interne, productivité et fiabilité ne sont pas antagonistes. La contribution des TIC à la productivité et la fiabilité : fonction du contexte de développement Une comparaison des résultats entre le codéveloppement des produits finis et le développement interne montre que la contribution de PLM à la productivité et à la fiabilité varie en fonction de l’environnement dans lequel est réalisé le développement. Productivité Dans le contexte du codéveloppement, PLM permet d’améliorer la flui- dité dans la circulation des connaissances mais les gains globaux de productivité liés à PLM (consolidation, workflows, tableaux de bord) sont relativement limités. Ils sont principalement focalisés sur les chefs de projet (cf. annexe 2). Au contraire, les gains de productivité dans les projets de développement interne sont significatifs, notamment grâce à l’automatisation de micro-processus (workflows) et à la rationalisation de certaines tâches du développement produit. Le fait que les gains de pro- ductivité soient plus élevés dans le cas du développement interne que dans celui du co-développement s’explique de plusieurs manières. PLM couvre un périmètre d’intégration des connaissances plus large 4. Si nous n’avons pas explicitement étudié l’effet des routines et de la vigilance sur la productivité, c’est parce qu’il est vraisemblable que cet effet prenne la forme d’une courbe en U inversé, donc difficile à mesurer : dans un premier temps, la productivité serait améliorée par les routines et l’implication des acteurs, mais elle risque de se dégrader si les routines et la vigilance des acteurs atteignent un certain seuil. 318 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle dans le cadre du développement interne que dans celui du codéve- loppement où le fournisseur garde la maîtrise des outils de GPAO, dispose de son propre logiciel de CAO et ne partage qu’une partie des données projet avec son client. Même si PLM est accessible depuis les sites des fournisseurs chinois pour les équipes de notre cas, les données projet ne sont pas intégrées automatiquement sur les outils de GPAO ou sur les ERP, contrairement aux processus de développe- ment interne. Dans ceux-ci, les acteurs disposent d’un répertoire de connaissances commun plus large et peuvent plus facilement partager des objets. Dans le cadre du développement interne, le couplage de PLM avec des contacts en face à face réguliers permet des gains substantiels de productivité. Dans le cadre du codéveloppement, PLM facilite l’intégra- tion de connaissances explicites, donc des gains de productivité, mais n’est d’aucun secours pour solutionner les problèmes de conception et d’industrialisation complexes qui nécessitent des déplacements d’ex- perts venus d’Europe. En résumé, le niveau d’intégration technique et la proximité géographi- que et structurelle des acteurs expliquent la différence en matière de gains de productivité entre les deux modes de développement. Fiabilité Les gains de fiabilité dans le processus de développement sont appa- rus, au contraire, comme plus limités dans le cadre du développement interne que dans celui du codéveloppement. PLM est structurant et permet d’introduire davantage de transparence dans l’intégration des connaissances d’acteurs distants disposant de répertoires de connais- sances partagées limités. Le co-développement nécessite une plus grande contractualisation des échanges que le développement inter- ne. Dans ce cadre, les fonctionnalités de PLM liées à la traçabilité des opérations et le renforcement des routines améliorent la fiabilité (cf. figure 3). Les acteurs du codéveloppement se sentent plus vigilants suite à la mise en place de PLM car ils disposent de l’ensemble des ob- jets projet qu’ils peuvent analyser, ce qui leur permet de détecter plus tôt d’éventuels problèmes de conception ou d’industrialisation. Dans le cadre du développement interne, les gains de fiabilité sont plus limités. Ces gains passent davantage par une augmentation de la vigilance des acteurs (Weick et Roberts, 1993 ; Brion, 2005) que par le renforcement des routines, qui existaient déjà. Enfin, l’élargissement du périmètre d’intégration des connaissances grâce à PLM permet à tous les acteurs du projet de disposer en temps réel des connaissan- ces explicites du projet. Nous avons mis en évidence que l’intégra- tion des connaissances influence également directement la fiabilité du processus de développement produit, sans passer seulement par les routines ou la vigilance (cf. figure 2). En développement interne, l’in- tégration des connaissances liée à PLM sur un périmètre plus large (ensemble des acteurs projet partageant les connaissances explicites dans le même espace virtuel) a eu une influence plus significative sur la fiabilité que les changements au niveau des routines et de la vigi- lance des acteurs. Les routines et la vigilance individuelle étaient déjà développées dans cet environnement. Mais c’est surtout le partage 319 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle transversal des objets sur un périmètre plus large qui influence la fia- bilité, à la fois directement et indirectement par le renforcement de la vigilance collective. Pour le codéveloppement, l’effet de l’intégration sur les routines et sur la vigilance a été plus significatif que l’élargissement du périmètre d’intégration, car le niveau initial des routines et de la vigilance était faible. Figure 2. Gains relatifs de l’usage de PLM dans le développement interne Figure 3. Gains relatifs de l’usage de PLM dans le codéveloppement Les résultats de cette recherche nous invitent aussi à approfondir le concept de vigilance (Butler et Gray, 2006), traduction de mindfulness, mais qui, au plan théorique, pourrait se traduire également par « ouver- ture » et « implication », termes que nous avons parfois utilisés. Il est intéressant que « rigueur » soit le terme qui revienne le plus souvent comme synonyme de fiabilité sur le terrain. Il signifie à la fois respect du plan et de la logique de passage d’étapes clés, mais aussi attention 320 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle renforcée à ce que l’on voit et à ce que l’on fait. La vigilance a donc une dimension perceptuelle favorisée par la lisibilité des représentations fournies par les outils. Elle s’applique aussi bien à soi qu’aux autres acteurs et présente une dimension de responsabilité et d’implication dans l’action. Dans le codéveloppement, PLM permet une attention à ce que l’on voit individuellement et un renforcement de l’implication vis-à-vis de ce que l’on fait, mais aussi une meilleure vision globale du projet – surtout pour les fournisseurs étrangers – qui, elle-même, renforce la routine du passage d’étapes à respecter. Dans le déve- loppement interne, PLM a permis l’accès en temps réel à toutes les connaissances explicites du projet, et ce pour tous les acteurs. Cela a joué un rôle plus important dans les gains de fiabilité que l’évolution des routines déjà mises en place et de la vigilance individuelle déjà présente avant PLM. L’intégration des connaissances explicites pour amé- liorer la performance Dans les contextes de haute fiabilité, la richesse de la communication entre les acteurs est facilitée par la culture organisationnelle et un ré- pertoire de connaissances tacites partagées est essentiel (Weick et Roberts, 1993). Dans les contextes plus « classiques », le média de communication mobilisé peut être moins « riche » (au sens de la théo- rie de la richesse des médias ; cf. Daft et Lengel, 1986). L’objectif du développement produit du groupe étudié ne requiert pas uniquement de solutionner des problèmes complexes mais également d’échanger et de partager des objets simples avec tous les acteurs projet. Le ca- ractère simultané du partage est certes encore plus essentiel dans les contextes de haute fiabilité (Weick et al., 2000 ; Journé, 2005) que dans ceux d’une fiabilité « classique » en environnement industriel, mais un partage synchronisé entre les acteurs du processus de déve- loppement est nécessaire dans les deux cas. PLM permet de renforcer la démarche organisationnelle collective de fiabilisation du processus de développement à travers une applica- tion unique pour tous les acteurs projet, qui remplace une multitude d’espaces de stockage individuels et une démarche de fiabilisation du processus morcelée. Le déploiement de PLM améliore la transpa- rence dans le partage de connaissances explicites sur les projets et, indirectement, la vigilance réciproque (Weick et Roberts, 1993 ; Brion, 2005). Ainsi, la mise à disposition des informations clés du projet à l’ensemble des acteurs permet de renforcer la capacité des équipes à s’auto-adapter plus rapidement, et de façon adéquate, à des condi- tions imprévues et nouvelles (Brion, 2005). Nous avons mis en évidence que la nature de l’intégration des connais- sances explicites est différente dans les contextes de développement interne et de codéveloppement. Ainsi, en développement interne, PLM facilite principalement la réutilisation des connaissances explicites et optimise le partage et la coordination sur les projets. Dans le codéve- loppement, PLM améliore surtout le partage et la coordination entre des acteurs distants mais ne contribue que marginalement à la réuti- 321 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle lisation des connaissances, les projets étant souvent négociés de ma- nière opportuniste en fonction des expertises techniques des fournis- seurs. Contrairement au développement interne où les compétences sont mutualisées et réutilisées, l’approche en co-développement est davantage ponctuelle dans le groupe industriel étudié. L’intégration des connaissances paraît donc être un concept fécond pour expliquer la performance du processus de développement pro- duit (Verona, 1999 ; De Luca et alii, 2009). Cependant, si les outils tels que PLM gèrent l’intégration des connaissances explicites (objets, documents, procédures, règles), le registre du tacite (représentations du monde, relations interpersonnelles, culture organisationnelle) et des interactions entre tacite et explicite (Chanal, 2003) n’a pas été appro- fondi. Conclusion et perspectives de recherche PLM contribue à améliorer conjointement la productivité et la fiabilité du développement produit à travers l’intégration des connaissances explicites pour la plupart des acteurs concernés. Cette amélioration conjointe est un résultat original qui complète ceux des travaux plus connus sur la haute fiabilité. En dépit de ses limites, PLM permet de mieux structurer le processus de développement et de centraliser les données projet, ce qui renforce la transparence dans l’intégration des connaissances explicites. L’examen approfondi du phénomène dans deux contextes différents d’une même entreprise montre que celui du développement interne favorise davantage les gains de productivité que de fiabilité, alors que c’est l’inverse dans le contexte du codévelop- pement. Ces gains sont liés à PLM et à la création induite de nouvelles routines dans le codéveloppement et plutôt au renforcement induit de la vigilance dans le développement interne. Ce travail exploratoire comporte certaines limites conceptuelles et mé- thodologiques qui permettent d’envisager des recherches futures. Si l’impact de l’intégration des connaissances explicites permise par PLM sur la performance du développement produit a été mieux compris, l’effet direct de la vigilance et des routines n’a été envisagé que sur la fiabilité ; une étude complémentaire pourrait être envisagée pour la pro- ductivité. La typologie des projets de développement produit retenue est partielle. Nous nous sommes limités à une distinction entre projets de développement interne et de codéveloppement. Une distinction plus fine des spécificités des projets permettrait probablement d’enrichir ce travail. Nous pourrions notamment introduire la complexité des projets5 au niveau technologique, organisationnel ou de marché, ou la matu- rité de la relation avec les fournisseurs. Il serait pertinent d’envisager des recherches approfondies sur les configurations de relations avec les fournisseurs pour préciser leurs spécificités dans l’intégration des connaissances. Cette recherche, limitée à la technologie PLM, pourrait aussi être pro- longée en intégrant une perspective plus large avec une analyse du portefeuille des TIC disponibles dans les organisations. Si PLM consti- tue une technologie émergente adoptée par un nombre croissant d’or- 5. Un projet est dit complexe (Bac- carini, 1996) lorsqu’il est composé de beaucoup d’éléments en interaction, l’opérationnalisation se faisant à partir du nombre d’éléments du système (différencia- tion) et du degré d’interaction et de relations entre ces éléments (interdépendance). 322 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle ganisations industrielles, il n’en demeure pas moins vrai que d’autres technologies coexistent dans un portefeuille technologique plus large : CAO, messagerie électronique, outils de web conférence, etc. Il serait également intéressant de travailler sur les connaissances tacites dans les projets et sur l’importance de la volonté de coopérer en s’appuyant sur le concept de confiance dans le cadre de l’intégration de ce type de connaissances. Cela permettrait notamment d’analyser l’impact du facteur culturel dans le codéveloppement. PLM renforce l’interdépen- dance des tâches et rend donc le partage des connaissances moins dépendant de la confiance à un niveau inter-individuel. Reste que la confiance, à un niveau interorganisationnel, est un préalable néces- saire afin que la technologie PLM puisse être mise en place. Enfin, cette exploration repose sur deux études de cas enchâssées dans une même entreprise. Il serait intéressant de comparer ces résul- tats avec d’autres entreprises et dans d’autres secteurs d’activité. Le processus de développement produit du petit électroménager est re- lativement simple : une comparaison avec des processus de dévelop- pement plus complexes, comme dans l’aéronautique ou l’automobile, permettrait d’enrichir ces résultats. Valéry Merminod est professeur associé de Management des Systèmes d’In- formation à SKEMA Business School. Ses recherches portent sur l’usage des TIC dans le cadre du développement de nouveaux produits et plus particuliè- rement dans des environnements inter organisationnels. Caroline Mothe est Professeur des Universités à l’Institut de Management de l’Université de Savoie et dirige l’équipe Innovation et Réseaux de l’IREGE. Ses recherches portent sur le management de l’innovation, les coopérations inter- organisationnelles et la gouvernance des pôles de compétitivité. Frantz Rowe a été professeur à l’ENST Paris et Harvard University. Ancien ré- dacteur en chef de Systèmes d’Information et Management et co-chair d’ICIS 2008, il est associate editor de European Journal of Information Systems. Ses recherches portent sur les effets des technologies sur la transformation des organisations. 323 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle REFERENCES . Baccarini, D. (1996). The concept of complexity – a review. International Journal of Project Mana- gement, 14(4), 201-204. . Banker, R., Chang, H., & Kao, Y. (2001). Impact of information technology on pu- blic accounting firm productivity. Journal of Information Systems, 16(2), 209- 222. . Batenburg, R., Helms, R., & Versendaal, J. (2005). The maturity of product lifecycle mana- gement in Dutch organizations: A stra- tegic alignment perspective, PLM’05: International conference on product life cycle management, Lyon, France, http://www.cs.uu.nl/research/techreps/ repo/CS-2005/2005-009.pdf . Bourgeon, L. (2002). Temporal context of organizational lear- ning in new product development pro- jects. Creativity and Innovation Mana- gement, 11(3), 175-183. . Boullier, D. (1995). L’usager, l’utilisateur et le récepteur: 12 ans d’exploration dans les machines à communiquer, Habilitation à Diriger des Recherches, Université Michel de Mon- taigne. . Brion, S. (2005). La coordination par la vigilance collec- tive réciproque. Revue Française de Gestion, 154(1), 143-157. . Brown, S. L., & Eisenhardt, K. (1995). Product development: past research, present findings and future directions. Academy of Management Review, 20(2), 343-378. . Brown, S. L., & Eisenhardt, K. M. (1997). The art of continuous change: linking complexity theory and time-paced evo- lution in relentlessly shifting organiza- tions. Administrative Science Quarterly, 42(1), 1-35. . Brynjolfsson, E., & Hitt, L. (1996). Paradox lost? Firm-level evidence on the return to information systems spen- ding. Management Science, 42(4), 541- 558. . Butler, B., & Gray, P. (2006). Reliability, mindfulness and information systems. MIS Quarterly, 30(2), 211- 224. . Calvi, R., Blanco, E., & Koike, T. (2005). Coopérer en conception pour améliorer les supply chains de demain. Un défi pour les entreprises virtuelles. Revue Française de Gestion, 156(31), 187- 202. . Campbell, D. T. (1975). Degrees of freedom and the case stu- dy. Comparative Political Studies, 8(2), 178-193. . Campbell, D. T. (1988). Methodology and Epistemology for So- cial Science: Selected Papers. E. S. Overman, Chicago: The University of Chicago Press. . Carlile, P. (2002). A pragmatic view of knowledge and boundaries: boundary objects in new product development. Organization Science, 13(4), 442-455. . Carlile, P. (2004). Transferring, translating and transfor- ming: An integrative framework for ma- naging knowledge across boundaries. Organization Science, 15(5), 558-568. . Chanal, V. (2003). Management des connaissances et in- novation : de nouveaux enjeux pour les systèmes d’information. In M.L. Caron- Fasan & N. Lesca, Présent et Futurs des systèmes d’information (pp. 267- 289). Paris: PUG. . Clark, K., & Fujimoto, T. (1990). The power of product integrity. Harvard Business Review, 68(6), 107-118. . Clark, K., & Fujimoto, T. (1991). Product Development Performance: strategy, organization and management in the world auto industry. Boston, MA: Harvard Business School. . Clarke, L. (1993). The disqualification heuristic: when do organizations misperceive risk?. Re- search in Social Problems and Public Policy, 5(1), 289-312. . Cooper, R., & Kleinschmidt, E. (1990), Stage Gate systems for new product success. Marketing Management, 4(1), 20-24. . Daft, R., & Lengel, R. (1986). Organizational information require- ments, media richness and structural design. Management Science, 32(5), 554-571. 324 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle . De Luca, L., Verona, G., & Vi-De Luca, L., Verona, G., & Vi- cari, S. (2009). Market orientation and R&D effective- ness in high technology firms: An em- pirical investigation in the biotechnology industry. Journal of Product Innovation Management, forthcoming. . Deming, W. (1982). Out of the crisis. Cambridge, MA: MIT Center for Advanced Engineering Stu- dy. . Eisenhardt, K. M., & Graeb-Eisenhardt, K. M., & Graeb- ner, M. (2007). Theory building from cases: opportuni- ties and challenges. Academy of Mana- gement Journal, 50(1), 25-32. . Garel, G. (1999). La mesure et la réduction des délais de développement des produits nouveaux. Recherche et Applications en Marke- ting, 14(2), 29-47. . Giard, V. (1991). Gestion de projets. Paris: Economica. . Gilbert, C., Amalberti, R., La-Gilbert, C., Amalberti, R., La- roche, H., & Paries, J. (2007). Errors and failures: towards a new safety paradigm. Journal of Risk Re- search, 10(7), 959-975. . Goodhue, D., & Thompson, R. (1995). Task-technology fit and individual per- formance. Management Information Systems Quarterly, 19(2), 213-236. . Grant, R. M. (1996). Prospering in dynamically competitive environments: organizational capability as knowledge integration. Organization Science, 7(4), 375-387. . Grieves, M. (2006). Product Lifecycle Management: Driving the Next Generation of Lean Manage- ment. New York, NY: McGraw Hill. . Hannan, M. T., & Freeman, J. (1984). Structural inertia and organizational change. American Sociological Review, 49(2), 149-164. . Hardgrave, B., Davis, F., & Riemenschneider, C. (2003). Investigating determinants of software developers’ intentions to follow metho- dologies. Journal of Management Infor- mation Systems, 20(1), 123-152. . Hatchuel, A. (1994). Apprentissages collectifs et activités de conception. Revue Française de Ges- tion, 99, 20-36. . Hoopes, D., & Postrel, S. (1999). Shared Knowledge, Glitches, and Pro- duct Development Performance. Strate- gic Management Journal, 20, 837-865. . Iansiti, M., & MacCormack, A. (1997). Developing products on Internet time. Harvard Business Review, 75(5), 108- 117. . Journé, B. (2005). Etudier le management de l’imprévu : méthode dynamique d’observation in situ. Finance Contrôle Stratégie, 8(4), 63-91. . Kraut, R., Sumais, S., Koch, S., & Kling, R. (1989). Computerization, productivity and qua- lity of work-life. Communications of the ACM, 32(2), 220-238. . Kusunoki, K., Nonaka, I., & Nagata, A. (1998). Organizational Capabilities in Product Development of Japanese Firms: A Conceptual Framework and Empirical Findings. Organization Science, 9(6), 699-718. . Le Masson, P., Hatchuel, A., & Weil, B. (2006). Les processus d’innovation : concep- tion innovante et croissance des entre- prises. Paris: Hermès Lavoisier. . Leonard-Barton, D. (1990). A dual methodology for case studies: synergistic use of longitudinal single site with replicated multiple sites. Orga- nization Science, 1(3), 248-266. . Lyytinen, K., Mathiassen, L., & Ropponen, J. (1998). Attention shaping and software risks: a categorical analysis of four classical approaches. Information Systems Re- search, 9(3), 233-255. . Malhotra, A., Gosain, S., & El Sawy, O. (2005). Absorptive capacity configurations in supply chains: gearing for partner ena- bled market knowledge creation. Mana- gement Information Systems Quarterly, 29(1), 145-187. . Mallick, D. N., & Schroeder, R. G. (2005). An integrated framework for measuring product development performance in high technology industries. Production and Operations Management, 14(2), 142-158. . Malone, T., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM computing surveys, 26(1), 87-120. 325 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle . Marciniak, R., & Pagerie, M. (1999). Gestion de projet : guide pratique de la réussite de tous vos projets et produits industriels. Paris: Weka. . Marciniak, R., & Rowe, F. (1999). Styles de coordination avec les sous- traitants, expérience commune et per- formance économique : le cas de trois projets dans le bâtiment. Systèmes d’In- formation et Management, 4(2), 37-64. . Merminod, V. (2007). TIC, partage des connaissances et fiabi- lité du développement produit distribué : une approche par le «glitch» au sein du Groupe SEB. Systèmes d’Information et Management, 12(1), 11-38. . Meyer, M., & Utterback, J. (1997). Metrics for managing research and de- velopment in the context of the product family. Management Science, 43(1), 88- 112. . Mostefai, S., & Batouche, M. (2005). Data integration in Product Lifecycle Management: an ontology-based ap- proach, PLM’05: International confer- ence on product life cycle management, Lyon, France. . Nambisan, S. (2003). Information systems as a reference dis- cipline for new product development. Management Information Systems Quarterly, 27(1), 1-18. . Nijssen, D., & Frambach, R. (2000). Determinants of the adoption of new product development tools by industrial firms. Industrial Marketing Manage- ment, 29(2), 121-131. . Nonaka, I. (1994). Dynamic Theory of Organizational Knowledge Creation. Organization Science, 5(1), 14-37. . Nonaka, I., Toyama, R., & Konno, N. (2000). SECI, Ba and leadership: a unified model of dynamic knowledge creation. Long Range Planning, 33(1), 5-34. . Okhuysen, G., & Eisenhardt, K. M. (2002). Integrating knowledge in groups: How formal interventions enable flexibility. Organization Science, 13(4), 370-386. . Pavlou, P. A., & El Sawy, O. (2006). From IT leveraging competence to com- petitive advantage in turbulent environ- ments: the case of new product develo- pment. Information Systems Research, 17(3), 198-230. . Pol, G., Jared, G., Merlo, C., & Legardeur, J. (2005). From PDM systems to integrated pro- ject management systems: a case stu- dy, PLM’05: International conference on product life cycle management, Lyon, France. . Roberts, K. H. (1990). Some characteristics of one type of high reliability organization. Organiza- tion Science, 1(2), 160-176. . Rowe, F. (1994). Des banques et des réseaux : Producti- vité et avantages concurrentiels. Paris: Economica. . Short, J., & Venkatraman, N. (1992). Beyond business process redesign: redefining Baxter’s business network. Sloan Management Review, 34(1), 7-21. . Stark, J. (2004). Product Lifecycle Management - 21st century Paradigm for Product Realiza- tion. Berlin: Springer Verlag, Decision Engineering Series. . Strassman, P. (1997). The squandered computer. New Ca- naan, Connecticut: The Information Economics Press. . Takikonda, M., & Montoya- Weiss, M. (2001). Integrating operations and marketing perspectives of product innovation: the influence of organizational process fac- tors and capabilities on development performance. Management Science, 47(1), 151-172. . Takikonda, M., & Rosenthal, S. (2000). Successful implementation of product development projects: balancing fir- mness and flexibility in the innovation process. Journal of Operations Mana- gement, 18(1), 401-425. . Terssac, G., & Friedberg, E. (1996). Coopération et Conception. Toulouse: Octares Edition. . Thomke, S., & Fujimoto, T. (2000). The effect of «front-loading» problem solving on product development perfor- mance. Journal of Product Innovation Management, 17(2), 128-142. 326 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle . Torkzadeh, G., Koufteros, X., & Doll, J. W. (2005). Confirmatory factor analysis and fac- torial invariance of the impact of infor- mation technology instrument. OMEGA, 33(2), 107-118. . Verona, G. (1999). A resource based view of product de- velopment. Academy of Management Review, 24(1), 132-142. . Weick, K., & Roberts, K. (1993). Collective mind in organizations: heedful interrelating on flight desks. Administra- tive Science Quarterly, 38(3), 357-381. . Weick, K., Sutcliffe, K., & Obstfeld, D. (1999). Organizing for high reliability: proces- ses of collective mindfulness. Research in Organizational Behaviour, 1(21), 81- 123. . Weick, K., & Sutcliffe, K. (2000). High reliability: The power of mindful- ness. In Leader to leader, San Francisco: Drucker Foundation/Jossey-Bass. . Weill, P. (1992). The relationship between investment in Information Technologies and firm performance: a study of valve industry. Information Systems Research, 3(4), 307-331. . Yassine, A. (2007). Investigating product development process reliability and robutness using simulation. Journal of Engineering De- sign, 18(6), 545-561. . Zirger, B., & Maidique, M. (1990). A model of new product development: an empirical test. Management Science, 36(1), 867-883. 327 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Annexe 1. Fonction des vingt-cinq personnes interrogées Fonction Nombre Directeur R&D Groupe Responsable processus R&D Groupe Directeur Industriel Activité Directeur Marketing Activité Directeur BE Pilote projet Gestionnaire Données Techniques Responsable CAO Projeteur Qualité Technicien Méthode d’Industrialisation Normes Asistante marketing Chef de produit 1 1 1 1 1 3 2 1 2 3 2 2 2 3 Total 25 328 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Département Acteur Nombre d’acteurs Gains de productivité en % Bureau d’étude Bureau d’étude Bureau d’étude Bureau d’étude Qualité Qualité Normes Industrialisation Marketing Techniciens CAO Gestionnaire Données Techniques Chef de projet Directeur Bureau d’Etude Techniciens laboratoire Qualité conception Techniciens normes Technicien d’industrialisation Chef de produit et assistante marketing 14 2 6 1 10 10 2 20 9 8,0% 10,7% 9,8% 3,3% 12,6% 7,4% 7,0% 10,5% 6,4% Total 74 9,7% Annexe 2. Gains de productivité par type d’acteurs Gains de productivité pour les projets de développement interne* (*) Pour le détail des calculs, voir annexe 3. Gains de productivité sur les projets de codéveloppement** (**) L’ensemble des calculs sera fourni sur demande. Département Acteur Nombre d’acteurs Gains de productivité en % Bureau d’étude Bureau d’étude Bureau d’étude Support Chine Support Chine Marketing Chef de projet Gestionnaire Données Techniques Normes Ingénieur développement Chine Qualité Chine Marketing 3 1 1 3 2 9 9,1% 6,7% 6,3% 7,9% 6.5% 6,4% Total 19 7,1% 329 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Annexe 3. Gains de productivité réalisés en développement interne Services concernés Gain Type de gain Détail sur le gain Gain final Temps gagné (en heure) % de gains par équipe Pilote Projet Coordina- tion Répondre aux questions des acteurs qualité achat, laboratoire, méthodes 2 heures par semaine 6 pilotes projets 504 Pilote Projet Partage Gain visualisateur CAO 1,5 heure par semaine 42 semaines 375 Pilote Projet Coordina- tion Gain dans les échanges avec la SMI : mise à disposition des plans et des investissement 1/2 heure par semaine 42 semaines 126 Pilote Projet Coordina- tion Gain dans la préparation des réunions de projet 1 heure pour chaque réunion 12 réunions dans l’année qui nécessitent travail sur plan 3D 60 Pilote Projet Réutilisa- tion Gain dans la recherche d’information sur des projets en cours ou terminée 1 heure par semaine 42 semaines 152 Pilote Projet Partage Temps de contrôle sur la standardisation des objectifs stockés dans les projets PLM Contrôle du respect des jalons clefs du projet 1,5 heure par semaine 42 semaines -378 6 Pilote Projet Nombre d’heures réalisées par le service par an 9600 942 9,8 Directeur BE Coordina- tion Gain sur la centralisation des données projet pour le pilotage : consolidation informatique et viewer 3D Gain de 15 minutes par jour 5 jours 42 semaines 52,5 Directeur BE Coordina- tion Réactivité à un problème de production sur un cablage de produit en plein mois d’aout grâce à la traçabilité sur les tests qualités réalisés Pas de reprise sur 3 à 4 jours de produc- tion 3000 produits finis fabriqués par jour -> 3000*4 = 15000 produits 1 Directeur BE 1600 52,5 3,3 Laboratoire Partage Centralisation informations projet sur une seule base pour technicien 2 heures par projet 10 projets Laboratoire Coordina- tion Gestion des demandes d’essai labo 400 à 600 demandes d’essai par an Gain de productivité : 1 secrétaire Laboratoire Réutilisa- tion Gain archivage des données dans PLM 1 heure par semaine 9 techniciens 42 semaines par an Responsable laboratoire Partage Centralisation de toutes les données projet : CR RP, compte rendus... 2 heures par mois 10 mois 10 per- sonnes au laboratoire Nombre d’heures réalisées par le service par an 16000 2018 12,6 Qualité Con- ception Viewer 3D pour les pièces et les produits finis 2 heures par mois 10 mois 20 Qualité Achat Gain sur recherche de plans 8 heures de gain par an et par technicien Effectif ; 6 techniciens 4 heurs par réparatrice Effectif : 2 réparatrices 56 Qualité Achat Gains sur workflow validation DE par le chef de service Gain de 3 heures par semaine 42 semaines 6 techniciens et 2 réparatrices 1006 Qualité Fabri- cation Gain de temps dans la recherche de plans 1/4 heure par jour pour les 2 techniciens superieurs 42 semaines 105 10 per- sonnes à la Qualité conception et achat Nombre d’heures réalisées par le service par an 16000 1189 7,4 330 Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Services concernés Gain Type de gain Détail sur le gain Gain final Temps gagné (en heure) % de gains par équipe Normes Partage Gain de temps sur traitement demande d’essai 1 heure par demande d’essai (DE) 225 DE en 2006 225 2 personnes aux normes Nombre d’heures réalisées par le service par an 3200 225 7,0 Industrialisation Partage Gains pour techniciens : mise à disposition de tous les plans dans la même base 2,5 heures par semaine 42 semaines 16 technicien 1680 Industrialisation Partage Gains pour les ingénieurs d’industrialisation dans la recherche d’éléments techniques sur le projet ou les produits finis 2 heures par jour 42 semaines 4 ingénieurs 1680 Industrialisation Coordina- tion Gains sur partage d’informations avec le pilote projet : plan 3D, validation grâce aux workflows 2 heures par semaine 4 ingènieurs 336 Industrialisation Partage Temps de chargement des plans industriels dans PLM plus long que dans l’ancienne application 1/2 heure par semaine 42 semaines 16 techniciens -336 20 personnes à l’indutrialisation Nombre d’heures réalisées par le service par an 3200 3360 10,5 Marketing Partage Représentation 3D 1,5 heure par semaine 42 semaines 5 chefs de produit 315 Assistante Marketing Partage Recherche fiches techniques sur les vari- antes de produit fini 2 heures par semaine 42 semaines 4 assistantes marketing 336 Assistante Marketing Réutilisa- tion Recompilation de gammes de produits finis 1 heure par semaine 42 semaines 4 assistantes marketing 168 Marketing Réutilisa- tion Recherches sur des projets passés : budget, planning projet ... 2 heures par mois donc 1/2 heure par semaine 42 semaines 5 chefs de produit 924 6,4 9 peronnes au market- ing Nombre d’heures réalisées par le service par an 14400 924 6,4 Total 118400 11515,4 9,7 331 Valéry Merminod, Caroline Mothe, Frantz Rowe M@n@gement vol. 12 no. 4, 2009, 294-331 Special Issue: Fiabilité et résilience comme dimensions de la performance organisationnelle Annexe 4. Principales fonctionnalités de la technologie PLM Typologie (Pavlou et El Samy, 2006) Fonctionnalités PLM Communication et partage Stockage et Capitalisation Consolidation Visualisateur 3D Structure projet figée Tableau de bord Workflows pour diffuser et valider des objets Unicité de la donnée ; stock- age unique à un emplacement prédéterminé et classification des objets Recherche multi critères Généralisation automatique d’objets en format pdf Traçabilité à travers indice de révision et statut de l’objet Cas de l’emploi : recherche de produits finis associés à un com- posant donné