Deux, trois voire quatre environnements de gestion du cycle de vie produit cohabitent parfois au sein d’une même organisation industrielle. Ce qui pourrait ressembler à un dysfonctionnement IT relève en réalité d’une réalité opérationnelle complexe, façonnée au fil de décennies d’évolutions industrielles, réglementaires et stratégiques.
Chez les grands groupes aéronautiques, navals ou de défense, cette coexistence de plusieurs générations de PLM n’est pas une exception et est même devenue une norme. Pourtant, elle soulève des questions centrales pour les directions métiers et IT : faut-il chercher à tout prix la convergence vers un PLM unique, ou peut-on organiser durablement cette pluralité ?
Cette série de trois articles explore cette problématique sous tous ses angles. Du diagnostic des causes (article 1) à l’analyse des coûts cachés (article 2), jusqu’aux stratégies d’adaptation ou de sortie envisageables (article 3), nous décryptons les enjeux d’une situation que beaucoup subissent, mais que peu maîtrisent vraiment.
Commençons donc par le commencement. Plusieurs facteurs peuvent amener les entreprises à gérer plusieurs systèmes d’information supportant le PLM.
Des facteurs internes à l’entreprise peuvent être premièrement identifiés.
I - Les industries à cycles de vie produit longs
Quand le produit vit plus longtemps que le système qui l’a conçu
Dans des secteurs tels que l’aéronautique, le naval ou le nucléaire, les produits ont des cycles de vie très longs, se comptant parfois en décennies. Un avion de combat reste en service 40 ans. Un sous-marin nucléaire, 50 ans. Une centrale, encore davantage. Les données de conception doivent alors rester accessibles en continu, pour des raisons légales ou de maintenance du produit. Une réalité qui implique souvent de conserver le système d’origine dans lequel le produit a été développé plutôt que de migrer les données vers un nouveau PLM.
Au sein d’une même entreprise, certains programmes ou produits sont en phase de développement, d’autres sont en phase série, pendant plusieurs années, d’autres encore sont en phase de maintenance. Il est ainsi courant qu’un PLM soit réservé à une phase précise du cycle de vie d’un produit ou à un nouveau programme, ce qui rend inévitable la cohabitation avec d’autres systèmes.
Cette dissociation naturelle entre PLM de conception et PLM de maintien en condition opérationnelle reflète des besoins métiers distincts : le premier accompagne les phases de développement et d’industrialisation, le second prend le relais sur les phases de service avec une gestion souvent plus légère des demandes de modification vie série.
S’ajoutent à cela les contraintes réglementaires strictes imposées par certaines autorités dans l’aéronautique ou la défense (EASA, DGA, etc.) en matière de gestion des données, de traçabilité et de sécurisation des processus. Migrer un programme certifié vers un nouveau PLM peut nécessiter une re-certification partielle et engendrer un coût et un risque que beaucoup d’industriels ne sont pas prêts à assumer pour des programmes en fin de vie.
Conserver des systèmes d’origine obsolètes qui ne sont plus maintenus par les éditeurs pose cependant des problèmes significatifs en termes de maintenance et d’évolution.
Finalement, on voit donc que plusieurs générations de PLM coexistent non par défaut de stratégie, mais par alignement avec les phases de vie des produits eux-mêmes.
II - Les transformations stratégiques et organisationnelles
Fusions, acquisitions et reconfigurations industrielles
Lors d’une fusion, d’une acquisition, d’un rapprochement entre entreprises, ou de l’absorption d’une autre structure, l’entreprise résultante est généralement amenée à lancer des projets d’harmonisation. Ces projets concernent à la fois les processus, les méthodes de travail et, naturellement, les systèmes d’information, souvent initialement hétérogènes.
Cette phase de convergence a pour objectif d’assurer la cohérence opérationnelle et la collaboration entre les équipes, et de garantir la continuité des activités dans un cadre organisationnel commun. L’harmonisation est souvent aussi motivée par une recherche de réduction des coûts de run, ces coûts récurrents de maintien en conditions opérationnelles qui pèsent sur les budgets IT, année après année.
Dans certains cas cependant, la décision peut être prise de conserver deux PLM distincts, notamment lorsque les besoins et les business models sont trop différents pour justifier une convergence complète. Préserver l’indépendance de ces outils permet en effet de maintenir des savoir-faire spécifiques ou encore de faciliter d’éventuelles cessions futures.
L’héritage technologique joue également un rôle majeur. Chaque entreprise arrive avec son propre écosystème : un PLM historique, des customisations métiers, des interfaces avec l’ERP ou le MES. Les différences d’architecture entre générations de PLM (on-premise vs cloud, monolithique vs microservices) rendent l’intégration technique complexe. S’ajoute à cela la multiplicité des éditeurs : un portefeuille applicatif peut inclure des solutions Siemens, Dassault Systèmes, PTC ou SAP, chacune avec ses propres standards et écosystèmes. Harmoniser cet ensemble représente un chantier de plusieurs années, pour un retour sur investissement qui peut être difficile à trouver.
Enfin, on peut également avoir l’introduction d’un nouveau système PLM pour répondre à une évolution des besoins opérationnels liés à un nouveau programme, ou bien à des technologies rendant les systèmes en place obsolètes, ou tout simplement à une transformation profonde de l’entreprise. Quoi qu’il en soit, sa mise en œuvre ne conduit pas automatiquement au décommissionnement des systèmes existants, notamment lorsque le déploiement a été insuffisamment préparé ou qu’un projet en cours a été interrompu. Une fois encore, différents PLM vont donc coexister.
III - Les contraintes de la chaîne de valeur et les stratégies de diversification
Adapter les outils aux réalités du marché
Outre les facteurs internes aux entreprises, certaines contraintes peuvent être liées à leur écosystème externe. L’utilisation de multiples PLM peut notamment provenir de la structuration de la chaîne de valeur, en particulier lorsqu’un fournisseur de rang 1 (fournisseur direct, sans intermédiaire, d’un donneur d’ordre) collabore avec plusieurs donneurs d’ordre.
Certains clients peuvent exiger l’usage de solutions digitales spécifiques, obligeant le fournisseur à gérer simultanément plusieurs environnements. Un même équipementier aéronautique peut ainsi devoir collaborer avec différents donneurs d’ordre via des systèmes distincts, parallèles, tout en maintenant un environnement interne pour ses développements propres.
Cette approche n’est pas nécessairement un problème, elle peut refléter une segmentation métier pertinente, où l’uniformisation technique n’apporterait tout simplement pas de valeur opérationnelle significative.
La coexistence de plusieurs générations de PLM n’est donc pas un phénomène univoque et peut être la conséquence rationnelle de multiples facteurs et contraintes.
Mais au-delà des causes, la question se porte sur le véritable coût de cette coexistence.
Licences, compétences, interopérabilité, gouvernance… Dans notre prochain article, nous dresserons un audit complet des impacts financiers et opérationnels du multi-PLM. Car c’est en mesurant précisément ces impacts que vous pourrez déterminer si votre situation nécessite une action, et a fortiori laquelle.
Lire aussi :
Des questions ? Nos expert.e.s sont là pour vous répondre !
Jean-Baptiste DIDIOT
Senior Partner
Olivia MARTIN
Partner
Adrien ROSSI
Senior Manager
Ludovic DODE
Senior Manager
