Accueil Revues Revue Numéro Article

M@n@gement

2009/4 (Vol. 12)

  • Pages : 112
  • DOI : 10.3917/mana.124.0294
  • Éditeur : AIMS

ALERTES EMAIL - REVUE M@n@gement

Votre alerte a bien été prise en compte.

Vous recevrez un email à chaque nouvelle parution d'un numéro de cette revue.

Fermer

Article précédent Pages 294 - 331

INTRODUCTION

1

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éveloppement. 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érogè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 performance du développement produit.

2

L’objectif de cet article est d’analyser la contribution de PLM à la performance du processus de développement, performance appréhendée sous l’angle de la fiabilité et la productivité. Les processus de développement 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é.

3

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 organisations soumises à des risques majeurs, a déjà été débattue. Les recherches 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 fiabilité) 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 productivité 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).

4

Dans les industries classiques, la fiabilité du processus de développement produit ne peut être assimilée à des problèmes de sécurité et de sûreté de fonctionnement. Compte tenu des résultats encore mitigé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 productivité (Weick et Roberts, 1993) et, si oui, dans quelles conditions.

5

Notre recherche pose ainsi la question de la compatibilité de la productivité et de la fiabilité dans les activités de R & D dans l’industrie manufacturiè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, correspondant à un contexte interorganisationnel avec des prestataires externes (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éveloppement, soit les tâches supportées par la technologie ralentissent la productivité 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’apprentissage, 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é.

6

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 processus de développement produit. La deuxième partie décrit la méthodologie 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

7

De nombreux travaux (Brown et Eisenhardt, 1995 ; Takikonda et Montoya-Weiss, 2001 ; Mallick et Schroeder, 2005) ont été consacrés à la performance du développement produit. Parmi les critères de performance 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).

8

Si mesurer la performance du développement produit reste difficile (Meyer et Utterback, 1997), d’autant qu’il s’agit souvent de mesurer 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 produits 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 productivité du processus de développement pour assurer la tenue de délais exigeants et une qualité élevée des nouveaux produits.

9

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 performance du processus de développement produit.

Caractéristiques du développement produit et émer gence de PLM

10

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 assure 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 cruciale 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

11

Le management des connaissances a été l’objet d’une importante littérature, notamment depuis l’article séminal de Nonaka (1994). Grant (1996) s’est, le premier, attaché au concept d’intégration des connaissances, qu’il définit comme la capacité organisationnelle clé de la firme. Les capacités internes d’intégration des différents types de connaissances 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 capacités processuelles (process capabilities). Elle représente la phase 3 (combinaison, qui comprend l’intégration) du modèle SECI (Nonaka et al., 2000).

12

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 disposent 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é rapidement (Chanal, 2003). De Luca et al. (2009) définissent l’intégration des connaissances comme les mécanismes formels qui assurent l’assimilation, 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 :

13
  • Le partage de connaissances est assimilé à la compétence de management de la circulation des différents inputs et des interactions entre acteurs. Le partage repose sur ces interactions entre acteurs disposant d’expertises différentes et qui concourent à un objectif commun.

  • La coordination consiste à gérer des activités interdépendantes orienté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 équilibrent 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 émane 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.

14

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 connaissances 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

15

Les recherches consacrées à l’impact des TIC sur la performance des organisations montrent une influence tantôt positive, tantôt négative (Short et Venkatraman, 1992 ; Strassman, 1997). Certains voient le système d’information comme un contributeur direct à l’avantage concurrentiel (Short et Venkatraman, 1992). D’autres mettent en avant les effets contingents des ressources TIC (Strassman, 1997) et questionnent la relation causale directe, les TIC ayant alors une contribution indirecte à la performance (Weill, 1992 ; Rowe, 1994 ; Brynjolfsson et Hitt, 1996).

16

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 technologie émergente, Product Lifecycle Management (PLM), qui permet d’intégrer les connaissances explicites des acteurs projet.

17

La technologie PLM trouve son origine dans les systèmes de gestion des données techniques (SGDT) qui permettent de stocker des données techniques relatives aux produits comme les gammes, les nomenclatures, 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.

18

Les fonctionnalités principales de PLM sont articulées autour du stockage et de la capitalisation des connaissances explicites, de leur partage, 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 interorganisationnelle (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 repré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, nomenclatures, caractéristiques techniques, processus d’industrialisation (Grieves, 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éfinition 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é.

La fiabilité : une première dimension de la performance du développement produit

19

La fiabilité peut être définie comme la capacité à produire collectivement 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’identifier 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 engagements (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).

20

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
21

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 produit.

22

La diminution des erreurs va de pair avec l’autre dimension de la fiabilité, 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éveloppement 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 processus de développement produit consiste à améliorer la qualité des échanges entre les acteurs en réduisant les erreurs de communication [1][1]  Cette approche est imparfaite pour deux raisons. D’une.... 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 insatisfaisant 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 par les déclarations d’erreurs directement liées aux problèmes de circulation 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 touche les autres acteurs ; c. le cas du partage de connaissances complexes 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
23

Les routines organisationnelles permettent d’améliorer la fiabilité (Hardgrave 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 puissants 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, notamment de contrôle (Lyytinen et al., 1998). Si les routines sont essentielles pour améliorer la fiabilité du processus de développement produit, 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 (Butler et Gray, 2006).

24

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 expertises des acteurs pour les résoudre (Weick et al., 2000). Pour augmenter 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 » (Okhuysen 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 acteurs 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éveloppement produit. Au niveau collectif, elle repose sur des décisions 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éalisé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

25

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).

26
  • La productivité en valeur correspond au rapport entre l’output mesuré 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 productivité qui soit plus proche de la problématique du traitement de l’efficience 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 produites à 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.

27

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 processus 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 suivant la productivité en nature, en déduire la contribution des changements organisationnels et de la mise en œuvre de technologies de l’information comme PLM. La mesure du temps passé sur les principales opérations de développement produit, et donc du délai de développement, 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 technologie 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 nombreuses 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é.

28

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 différencié de PLM sur la performance du processus de développement selon le contexte de développement.

Figure 1 - Cadre conceptuel

UNE ÉTUDE DE CAS LONGITUDINALE DANS DEUX CONTEXTES

29

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

30

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 entreprise. 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 incertitudes. 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’externalisation 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.

31

Notre approche est fondée sur une étude de cas longitudinale qui combine 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étrospectives 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’observation directe pendant trois années a permis de tester et de rejeter par des expérimentations de l’esprit de nombreuses hypothèses (Campbell, 1975). De plus, l’observation ayant lieu avant, pendant et après l’introduction de PLM, le design de la recherche est amélioré (Campbell, 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 comprendre le phénomène étudié.

Collecte de données

32

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 rationalisation 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 électronique dans une application dédiée aux méthodes qualitatives : l’application Nvivo de l’éditeur QCR.

33

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

34

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’acteurs 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 entretiens 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.

35

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 différentes :

36
  • Récupération des éléments donnés pour vérifier la qualité des informations 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 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.

37

Nous avons aussi conduit une centaine d’entretiens individuels et collectifs, 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

38

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ètement, nous avons intégré les données collectées, comme les entretiens, dans le logiciel Nvivo. Après avoir finalisé la catégorisation descriptive, l’analyse explicative a été faite grâce à un codage de second niveau, dit « axial » (Strauss et Corbin, 1990).

Description du cas

39

Le groupe étudié est un des leaders mondiaux du petit électroménager. 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 composants 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.

40

PLM constitue un outil triplement stratégique pour ce groupe industriel :

41

« 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).

42

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 mouvement de distribution géographique des équipes et du codéveloppement sur une même plate-forme technique.

43

La famille « Soin du linge » est composée des fers à repasser, centrales 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 (Shanghai, Hong Kong notamment). Le développement des produits repose 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.

44

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 complexes car ils contiennent des évolutions en termes d’architecture du produit 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.

45

À l’inverse, pour le codéveloppement, les projets sont essentiellement liés au renouvellement et à l’animation des gammes, relativement simples au niveau technologique. Les ressources pour le codéveloppement 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, localisé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éveloppement produit.

46

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’harmoniser 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 730000 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étisées dans l’annexe 4.

RÉSULTATS

47

Nous présentons les résultats de la contribution de PLM à la fiabilité (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

48

Après avoir traité des dimensions de la fiabilité, nous identifions les moyens permettant d’améliorer la fiabilité et les limites de la contribution de PLM à la fiabilité du processus de développement produit.

Mesure de la fiabilité du développement produit selon le contexte

49

Respect des délais : réduction du délai moyen des retards sur les projets. 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éveloppement 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 proportion 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 meilleure 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

50

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 permettent cependant d’associer cette réduction des retards au déploiement de PLM. En effet, d’une part, sur la période analysée, la complexité 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.

51

Diminution des erreurs. La diminution des erreurs dans le processus de développement produit est analysée au travers des erreurs dans les échanges de connaissances sur le projet. Quatre types de glitches (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érentes 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ésiduels (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 complexes, souvent tacites, explique le peu d’effet de PLM pour résoudre ce type de glitch. Cela nous permet d’avancer la proposition suivante [2][2]  Nous remercions un évaluateur anonyme qui a fait la... :

52

P1 : PLM améliore la fiabilité du processus de développement produit, 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éveloppement produit

53

Des gains de fiabilité plus importants dans le contexte du codéveloppement. 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éveloppement, 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 contribue à renforcer ce répertoire en définissant un espace de partage, des règles communes, des objets de connaissances prédéfinis (Merminod, 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 acteurs, 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.

54

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é

55

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.

56

Routines organisationnelles et intégration des connaissances explicites. 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 objets de connaissances et à introduire plus de rigueur dans le développement 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 renforcés.

57

PLM renforce également la fiabilité par un partage plus général d’objets 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 :

58

« PLM force à respecter les procédures groupe, à savoir le respect des principales é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)

Tableau 4 - Nature des routines organisationnelles améliorées

59

Nos observations et les entretiens montrent donc que l’amélioration relative 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 essentiellement grâce à l’intégration des connaissances explicites (notamment le partage et la coordination) que permet PLM. La dimension « réutilisation 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.

60

P3 : L’intégration des connaissances explicites permise par PLM renforce les routines organisationnelles

61

Vigilance des acteurs et intégration des connaissances explicites. PLM a permis l’amélioration de la transparence dans le partage des connaissances projet et, indirectement, d’améliorer la vigilance des acteurs. Une traçabilité dans le partage des objets est assurée grâce à l’historisation 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 processus de développement. Les acteurs déclarent a posteriori être davantage sensibilisés individuellement à la fiabilisation du processus de développement produit. Les douze acteurs interrogés du co-développement 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éveloppement [3][3]  Dans une certaine mesure, PLM a également permis de....

62

« 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).

63

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 directement 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 conception. 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.

64

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

65

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 limiter 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’objets 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

66

Nous présentons ici les résultats concernant la mesure de la productivité à 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.

67

Mesure des gains de productivité en nature selon le contexte

68

Productivité en nature. Pour le développement interne, nous constatons une augmentation de 30 % des projets par an avec une légère baisse des effectifs (cf. tableau 5). La productivité apparente du travail 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.

Tableau 5 - Gains de productivité apparente du travail et gain de temps relatif

69

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éveloppement. 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.

70

Les gains de productivité par type d’acteurs, tant pour le codéveloppement que pour le développement interne, sont fournis dans les annexes 2 et 3. Ils se répartissent de manière relativement homogène entre tous les métiers du développement produit.

71

Temps de développement produit. PLM ne contribue pas à réduire significativement 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

72

Si PLM permet de gérer plus facilement davantage de projets en parallè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 fait, PLM améliore la productivité des tâches unitaires à faible valeur ajoutée :

73

« 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).

74

P5 : PLM améliore la productivité en nature du processus de développement produit.

75

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é

76

L’intégration des connaissances explicites constitue un moyen d’améliorer la productivité du processus de développement produit. La productivité 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

77

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 contribuent à fluidifier la circulation de connaissances explicites comme la validation de documents clés. Grâce à PLM, on observe une amélioration 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 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.

78

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’explique 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.

79

Les gains de productivité dans la coordination sont assez sensibles, avec 3,1 % pour le développement interne et 2,9 % pour le codéveloppement 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 unique 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.

80

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’utilisation 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’expliquer 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’espace de stockage des connaissances explicites des projets dans PLM. PLM permet aussi de capitaliser les connaissances de tous les services 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éutilisation 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 également réutilisés.

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

81

PLM permet d’automatiser certaines tâches du développement produit mais ne solutionne pas les problèmes de collaboration complexes. PLM constitue une application structurante qui supporte certaines compétences organisationnelles comme l’intégration des connaissances explicites sur le processus de développement et partiellement les compétences opérationnelles (à travers le visualisateur 3D par exemple).

DISCUSSION ET CONCLUSION

82

Nous avons mis en évidence que PLM facilite une structuration minimale (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 :

83
  • 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 connaissances 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 processus augmente davantage que la productivité ; c’est l’inverse dans le cas du développement interne.

84

Nous discutons plus précisément des trois résultats suivants : la combinaison 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 permet 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

85

Les entreprises industrielles classiques peuvent-elles combiner productivité et fiabilité dans le développement produit ? Si plusieurs travaux tendent à montrer que d’autres types d’entreprises doivent faire un choix entre ces deux dimensions de la performance (Weick et Roberts, 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é.

86

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 étapes importantes du processus [4][4]  Si nous n’avons pas explicitement étudié l’effet des.... 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 redondances 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.

87

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éveloppement 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

88

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é

89

Dans le contexte du codéveloppement, PLM permet d’améliorer la fluidité 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 productivité soient plus élevés dans le cas du développement interne que dans celui du co-développement s’explique de plusieurs manières.

90

PLM couvre un périmètre d’intégration des connaissances plus large dans le cadre du développement interne que dans celui du codéveloppement 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éveloppement interne. Dans ceux-ci, les acteurs disposent d’un répertoire de connaissances commun plus large et peuvent plus facilement partager des objets.

91

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égration 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’experts venus d’Europe.

92

En résumé, le niveau d’intégration technique et la proximité géographique et structurelle des acteurs expliquent la différence en matière de gains de productivité entre les deux modes de développement.

Fiabilité

93

Les gains de fiabilité dans le processus de développement sont apparus, 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 connaissances partagées limités. Le co-développement nécessite une plus grande contractualisation des échanges que le développement interne. 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 objets projet qu’ils peuvent analyser, ce qui leur permet de détecter plus tôt d’éventuels problèmes de conception ou d’industrialisation.

94

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 connaissances explicites du projet. Nous avons mis en évidence que l’intégration 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’inté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 vigilance des acteurs. Les routines et la vigilance individuelle étaient déjà développées dans cet environnement. Mais c’est surtout le partage transversal des objets sur un périmètre plus large qui influence la fiabilité, à 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

95

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 « ouverture » 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 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éveloppement 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

96

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éorie 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 caractè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éveloppement est nécessaire dans les deux cas.

97

PLM permet de renforcer la démarche organisationnelle collective de fiabilisation du processus de développement à travers une application 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 transparence 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 conditions imprévues et nouvelles (Brion, 2005).

98

Nous avons mis en évidence que la nature de l’intégration des connaissances 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éveloppement, PLM améliore surtout le partage et la coordination entre des acteurs distants mais ne contribue que marginalement à la réutilisation des connaissances, les projets étant souvent négociés de manière opportuniste en fonction des expertises techniques des fournisseurs. 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é.

99

L’intégration des connaissances paraît donc être un concept fécond pour expliquer la performance du processus de développement produit (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é approfondi.

Conclusion et perspectives de recherche

100

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éveloppement. 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.

101

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 productivité. 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 projets [5][5]  Un projet est dit complexe (Baccarini, 1996) lorsqu’il... au niveau technologique, organisationnel ou de marché, ou la maturité 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.

102

Cette recherche, limitée à la technologie PLM, pourrait aussi être prolongée en intégrant une perspective plus large avec une analyse du portefeuille des TIC disponibles dans les organisations. Si PLM constitue une technologie émergente adoptée par un nombre croissant d’organisations 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épendance 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écessaire afin que la technologie PLM puisse être mise en place.

103

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ésultats avec d’autres entreprises et dans d’autres secteurs d’activité. Le processus de développement produit du petit électroménager est relativement simple : une comparaison avec des processus de développement plus complexes, comme dans l’aéronautique ou l’automobile, permettrait d’enrichir ces résultats.


Annexe

Annexe 1. Fonction des vingt-cinq personnes interrogées

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.

Annexe 3. Gains de productivité réalisés en développement interne

Annexe 4. Principales fonctionnalités de la technologie PLM


REFERENCES

  • ? Baccarini, D. (1996). The concept of complexity – a review. International Journal of Project Management, 14 (4), 201-204.
  • ? Banker, R., Chang, H., & Kao, Y. (2001). Impact of information technology on public accounting firm productivity. Journal of Information Systems, 16 (2), 209- 222.
  • ? Batenburg, R., Helms, R., & Versendaal, J. (2005). The maturity of product lifecycle management in Dutch organizations : A strategic 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 learning in new product development projects. Creativity and Innovation Management, 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 Montaigne.
  • ? Brion, S. (2005). La coordination par la vigilance collective 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 evolution in relentlessly shifting organizations. Administrative Science Quarterly, 42 (1), 1-35.
  • ? Brynjolfsson, E., & Hitt, L. (1996). Paradox lost ? Firm-level evidence on the return to information systems spending. 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 study. Comparative Political Studies, 8 (2), 178-193.
  • ? Campbell, D.T. (1988). Methodology and Epistemology for Social 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 transforming : An integrative framework for managing knowledge across boundaries. Organization Science, 15 (5), 558-568.
  • ? Chanal, V. (2003). Management des connaissances et innovation : 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 ?. Research 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 requirements, media richness and structural design. Management Science, 32 (5), 554-571.
  • ? De Luca, L., Verona, G., & Vi--cari, S. (2009). Market orientation and R&D effectiveness in high technology firms : An empirical 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 Study.
  • ? Eisenhardt, K.M., & Graeb--ner, M. (2007). Theory building from cases : opportunities and challenges. Academy of Management 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 Marketing, 14 (2), 29-47.
  • ? Giard, V. (1991). Gestion de projets. Paris : Economica.
  • ? Gilbert, C., Amalberti, R., La-roche, H., & Paries, J. (2007). Errors and failures : towards a new safety paradigm. Journal of Risk Research, 10 (7), 959-975.
  • ? Goodhue, D., & Thompson, R. (1995). Task-technology fit and individual performance. 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 Management. 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 methodologies. Journal of Management Information Systems, 20 (1), 123-152.
  • ? Hatchuel, A. (1994). Apprentissages collectifs et activités de conception. Revue Française de Gestion, 99, 20-36.
  • ? Hoopes, D., & Postrel, S. (1999). Shared Knowledge, Glitches, and Product Development Performance. Strategic 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 quality 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 : conception innovante et croissance des entreprises. Paris : Hermès Lavoisier.
  • ? Leonard-Barton, D. (1990). A dual methodology for case studies : synergistic use of longitudinal single site with replicated multiple sites. Organization 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 Research, 9 (3), 233-255.
  • ? Malhotra, A., Gosain, S., & El Sawy, O. (2005). Absorptive capacity configurations in supply chains : gearing for partner enabled market knowledge creation. Management 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 studyofcoordination. ACM computing surveys, 26 (1), 87-120.
  • ? 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 performance économique : le cas de trois projets dans le bâtiment. Systèmes d’Information et Management, 4 (2), 37-64.
  • ? Merminod, V. (2007). TIC, partage des connaissances et fiabilité 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 development 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 approach, PLM’05 : International conference on product life cycle management, Lyon, France.
  • ? Nambisan, S. (2003). Information systems as a reference discipline 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 Management, 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 competitive advantage in turbulent environments : the case of new product development. Information Systems Research, 17 (3), 198-230.
  • ? Pol, G., Jared, G., Merlo, C., & Legardeur, J. (2005). From PDM systems to integrated project management systems : a case study, PLM’05 : International conference on product life cycle management, Lyon, France.
  • ? Roberts, K.H. (1990). Some characteristics of one type of high reliability organization. Organization Science, 1 (2), 160-176.
  • ? Rowe, F. (1994). Des banques et des réseaux : Productivité 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 Realization. Berlin : Springer Verlag, Decision Engineering Series.
  • ? Strassman, P. (1997). The squandered computer. New Canaan, Connecticut : The Information Economics Press.
  • ? Takikonda, M., & Montoya-Weiss, M. (2001). Integrating operations and marketing perspectives of product innovation : the influence of organizational process factors and capabilities on development performance. Management Science, 47 (1), 151-172.
  • ? Takikonda, M., & Rosenthal, S. (2000). Successful implementation of product development projects : balancing firmness and flexibility in the innovation process. Journal of Operations Management, 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 performance. Journal of Product Innovation Management, 17 (2), 128-142.
  • ? Torkzadeh, G., Koufteros, X., & Doll, J.W. (2005). Confirmatory factor analysis and factorial invariance of the impact of information technology instrument. OMEGA, 33 (2), 107-118.
  • ? Verona, G. (1999). A resource based view of product development. Academy of Management Review, 24 (1), 132-142.
  • ? Weick, K., & Roberts, K. (1993). Collective mind in organizations : heedful interrelating on flight desks. Administrative Science Quarterly, 38 (3), 357-381.
  • ? Weick, K., Sutcliffe, K., & Obstfeld, D. (1999). Organizing for high reliability : processes of collective mindfulness. Research in Organizational Behaviour, 1 (21), 81- 123.
  • ? Weick, K., & Sutcliffe, K. (2000). High reliability : The power of mindfulness. 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 Design, 18 (6), 545-561.
  • ? Zirger, B., & Maidique, M. (1990). A model of new product development : an empirical test. Management Science, 36 (1), 867-883.

Notes

[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 fonctionnement 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écisément à traiter les malentendus plus que des erreurs (Boullier, 1995) sous peine d’en supporter les conséquences.

[2]

Nous remercions un évaluateur anonyme qui a fait la suggestion d’aboutir à des propositions et en a également formulé quelques-unes.

[3]

Dans une certaine mesure, PLM a également 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éduction de l’asymétrie informationnelle entre les acteurs projet grâce à PLM.

[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.

[5]

Un projet est dit complexe (Baccarini, 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érenciation) et du degré d’interaction et de relations entre ces éléments (interdépendance).

Résumé

Français

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
  • performance
  • productivité
  • fiabilité
  • intégration des connaissances
  • routines
  • vigilance

English

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 coupled with that of productivity. This article captures the contribution of Product Lifecycle Management (PLM) technology to the reliability and productivity of new product development. 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 development, 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

Plan de l'article

  1. INTRODUCTION
  2. PRODUCTIVITÉ ET FIABILITÉ DU PROCESSUS DE DÉVELOPPEMENT PRODUIT
    1. Caractéristiques du développement produit et émer gence de PLM
      1. Intégration des connaissances : une problématique clé du déve loppement produit
      2. Contribution de PLM à la performance du développement produit
        1. La fiabilité : une première dimension de la performance du développement produit
          1. Dimensions de la fiabilité : respect des délais et diminution des erreurs
          2. Vecteurs de fiabilité : routines et vigilance des acteurs
        2. La productivité : une deuxième dimension de la perfor mance du développement
  3. UNE ÉTUDE DE CAS LONGITUDINALE DANS DEUX CONTEXTES
    1. Méthodologie
      1. Étude de cas longitudinale rétrospective et par observation directe
      2. Collecte de données
      3. Codage
    2. Description du cas
  4. RÉSULTATS
    1. Contribution de PLM à la fiabilité du processus de dé veloppement produit
      1. Mesure de la fiabilité du développement produit selon le contexte
      2. Moyens permettant les gains de fiabilité
      3. Limites de la contribution de PLM à la fiabilité du processus de développement
    2. Contribution de PLM à la productivité du processus de développement produit
      1. Intégration des connaissances et gains de productivité
        1. Coordination.
        2. Réutilisation des connaissances.
    3. P7 : L’intégration des connaissances explicites permise par PLM améliore la productivité en nature du processus de développe ment produit.
      1. Des gains de productivité liés à PLM à relativiser
  5. DISCUSSION ET CONCLUSION
    1. Combiner productivité et fiabilité du développement pro duit dans les environnements industriels classiques
    2. La contribution des TIC à la productivité et la fiabilité : fonction du contexte de développement
      1. Productivité
      2. Fiabilité
    3. L’intégration des connaissances explicites pour amé liorer la performance
    4. Conclusion et perspectives de recherche

Pour citer cet article

Merminod Valéry, Mothe Caroline, Rowe Frantz, « Effets de Product Lifecycle Management sur la fiabilité et la productivité : une comparaison entre deux contextes de développement produit », M@n@gement, 4/2009 (Vol. 12), p. 294-331.

URL : http://www.cairn.info/revue-management-2009-4-page-294.htm
DOI : 10.3917/mana.124.0294


Article précédent Pages 294 - 331
© 2010-2014 Cairn.info
back to top
Feedback