Industrie Mag - Le journal de l'industrie.

D’une part, les vétérans, qui ont essayé, sans vraiment réussir, à mettre en œuvre une véritable solution et qui, aguerris, ont appris à vivre avec leur insatisfaction ; d’autre part, les débutants, inconscients des embuches et des frustrations qui les attendent. S’il y a tant de déception, c’est principalement parce que les systèmes de PLM classiques n’ont pas tenu leurs promesses. Pour remédier à cette insatisfaction, il faudrait une solution transparente, flexible, résiliente et réellement efficace.

La gestion du cycle de vie des produits, connue souvent sous son acronyme anglais PLM, est un concept capable de révolutionner le développement et la fabrication de produits industriels. Il est issu d’un concept plus ancien, le Product Data Management ou PDM, francisé sous le sigle GDT (gestion des données techniques). Ce développement, né dans les années 80, reposait à son tour sur les logiciels de CAO (Conception assistée par ordinateur) de l’époque, qui transformaient alors la démarche de conception de produits industriels en générant, autour d’un modèle numérique du produit, toute une masse de données que l’industriel pouvait alors exploiter, à condition de pouvoir la gérer. Dans les années 90, les documents étaient reliés entre eux sur la base de normes ISO 9001 et d’exigences réglementaires et de garantie légale, permettant de mettre en place un processus simple pour la gestion des modifications techniques.

C’est sur ces bases que l’on a ensuite imaginé d’étendre la GDT du bureau d’études à l’ensemble de l’entreprise en créant des systèmes prenant en charge la gestion du cycle de vie des produits. Le PLM devait englober toute la chaîne, de la conception au SAV en passant par toutes les phases de l’industrialisation. Au lieu de confiner les données dans des silos au niveau d’un service, le PLM avait pour ambition de fédérer les ingénieurs, quel que soit leur domaine de compétence (mécanique, électrique ou logiciel) autour d’une plate-forme collaborative unifiée capable de supporter le développement de systèmes complexes. Mises en œuvre correctement, les informations pouvaient être partagées sans entraves par toutes les équipes internes et, au-delà, par l’ensemble des intervenants de l’entreprise étendue.

Le concept était tentant ! Il avait le potentiel de permettre un développement plus efficace des produits, avec un taux d’erreurs réduit, une meilleure utilisation des ressources et des budgets, moins de gaspillage dans la chaîne de production, et des délais de commercialisation plus courts. Au final : une démarche PLM réussie devait permettre de concevoir, de développer, de fabriquer et de maintenir des produits plus vite et plus efficacement.

Le PLM classique : une source de frustration

Or, la réalité a été tout autre : trop souvent, les projets PLM n’ont pas tenu leurs promesses. L’intégration sans entraves à l’échelle de l’entreprise et au-delà, les économies et l’efficacité escomptées – réalisables au prix d’une courte période de customisation – sont restées une chimère. Les projets PLM ne sont pas parvenus à s’imposer au-delà du périmètre du bureau d’études ou des méthodes. Les customisations se sont avérées plus lourdes que prévues, et les fonctionnalités imaginées ont été lentes et coûteuses à déployer.

Les projets PLM classiques se résument en une formule simple : 10-10-100. En effet, 10 % des fonctionnalités attendues sont réalisées ; 10 % des utilisateurs prévus sont réellement connectés au système ; mais 100 % du budget affecté a été consommé.

La notoriété du PLM a donc été sérieusement mise à mal. Nombreuses sont les entreprises à avoir cherché leur salut dans une solution « prête à utiliser », mais qui crée un autre problème : chaque projet PLM est par définition très spécifique, car il doit refléter la structure de l’entreprise et ses produits. Or, ces solutions, bien que plus simples à déployer, n’ont pas la souplesse adéquate pour répondre à la diversité des besoins et induisent des démarches inefficaces. De surcroît, cette rigidité ne permet pas d’accompagner l’évolution des processus rendue nécessaire par les mutations du marché.

Les entreprises se retrouvent dans une impasse. Les modèles commerciaux classiques pratiqués pour les solutions PLM les obligent à dépenser la majeure partie de leur budget en amont du projet pour migrer les données, adapter les processus existants, et palier les lourdeurs de mise en œuvre. Au final, une fois le système PLM en place seule une petite partie des fonctions attendues sont présentes et le budget a été totalement consommé.

Comment en est-on arrivé là ?

Ce bilan de frustration généralisé dans le monde du PLM ne doit rien au hasard. Pour en trouver les causes il faut remonter au-delà du coût élevé des projets classiques, et regarder l’ADN même des principaux fournisseurs et la rigidité technologique des systèmes qu’ils proposent.

Un coup d’œil rapide sur les grands acteurs du secteur et sur l’évolution de leurs offres révèle de grandes similarités. Tout d’abord, ils sont tous issus de l’univers de la CAO/IAO/FAO, leurs offres étant donc ancrées dans des produits ayant évolué par incréments successifs à travers la grande époque de la GDT.

Ces solutions partagent un autre point commun : au lieu de s’appuyer sur un code unique développé en interne, la majorité des systèmes PLM a été développée à partir d’une collection de produits indépendants, rassemblés de force à travers des fusions et autres acquisitions. Aussi, ces systèmes, montés de toute pièce, souffrent déjà d’incohérences internes. Si certains composants mis au point en interne ont été bien intégrés ou alors très largement remaniés, d’autres sont moins bien intégrés et ne fonctionnent pas forcément bien avec le système qui les a accueillis.

Les vétérans du PLM en reconnaîtront les signes : l’impossibilité, par exemple, de créer une nomenclature unique qui intègre l’ensemble des disciplines, ou encore la gestion des modifications techniques qui ne peut être assurée de bout en bout sur l’ensemble du cycle de vie du produit. Si certains éléments des logiciels PLM fonctionnent bien ensemble, la mise en œuvre d’autres fonctionnalités s’avère quasiment impossible car elles ne communiquent pas avec le reste du système.

Le cauchemar de la customisation et de la mise à niveau

Les systèmes PLM classiques présentent souvent l’inconvénient de ne pouvoir s’adapter facilement par customisation ou mise à niveau aux évolutions du marché ni aux besoins individuels des entreprises. En effet, la quasi-totalité des solutions PLM classiques reposent sur une architecture à base de code compilé, car la logique « métier » et les modèles de données sont définis dans le code source. Toute customisation ou enrichissement avec de nouvelles fonctions passe par une refonte lourde de ce code, avec réécriture, correction, puis recompilation pour rétablir les liens entre modules. Il faut alors répercuter la nouvelle version de l’application sur toutes les instances serveurs sur lesquels elle a été déployée.

Pour cela il faut non seulement avoir une connaissance détaillée du code source et des langages de programmation utilisés (différents selon les produits), mais le processus génère des erreurs et peut durer des mois. Par ailleurs, étant donnée la nature « propriétaire » du code, le travail coûte cher et suppose l’intervention de consultants externes validés par le fournisseur du logiciel.

Cette architecture explique aussi la difficulté des mises à niveau : pour chaque nouvelle version du logiciel il faut modifier le code de base et, par conséquent, transférer les customisations et les coder « en dur » dans le nouveau système. Dans le pire des cas, la nouvelle version a tellement évolué par rapport à l’instance d’origine utilisée par le client que la customisation doit être redéveloppée ex nihilo. Dans certaines circonstances, le projet PLM dans son ensemble prend un tel retard que les investissements antérieurs sont en grande partie perdus. Et à la fin, les mises à niveau restent à la charge exclusive du client – une réalité que les grands acteurs du PLM sont toujours prompts à rappeler.

L’entreprise se trouve donc face à un choix cornélien : différer le plus longtemps possible la mise à niveau, et donc passer à côté des avantages que celle-ci aurait pu apporter ; ou alors s’engager dans le processus long et très coûteux de la mise à niveau, sans pouvoir évaluer avec certitude les bénéfices qui en résulteront. Rappelons qu’une entreprise qui constate qu’une nouvelle version ne prendra pas en charge une fonction spécifique existante et précieuse, préférera souvent garder sa version ancienne, quel que soit le coût en termes financiers ou d’opportunité technique manquée.

Par ailleurs, de par la nature propriétaire du logiciel, l’entreprise est liée à son fournisseur, puisque seul celui-ci a accès au code source et pourra, par conséquent, effectuer des modifications ou ajustements, quitte à confier ce travail à un consultant agréé.

Pour beaucoup de projets PLM, ces obstacles signifient que l’entreprise reste très loin de ses objectifs initiaux. La gestion de données CAO est trop souvent encore le point de départ des projets PLM et constitue la première fonction ajoutée au système. L’installation et les customisations requises pour la mise en œuvre de ces fonctions absorbent la totalité du budget prévu pour le projet, interdisant, du coup, la dotation de nouvelles licences à des utilisateurs supplémentaires. Au lieu du système PLM totalement intégré sur lequel elle a misé, l’entreprise se retrouve avec une solution GDT onéreuse et accessible uniquement aux ingénieurs du bureau d’études.

Comment s’assurer de la mise en œuvre d’une solution PLM qui tiendrait ses promesses et réaliserait son potentiel ? Clairement, il ne suffira ni d’éliminer des fonctions individuelles encombrantes ni d’effectuer des modifications superficielles.. La solution consiste à disposer d’une technologie radicalement différente des systèmes classiques.

Pour faire oublier sa réputation ternie, le PLM doit reconstruire son image

Une des clefs du succès consiste à rompre avec le traditionnel ancrage du modèle de données et de sa logique « métier » dans un même code source et à dissocier ainsi modèle et comportement.

Une architecture SOA (orientée services) permet d‘offrir une palette de services liés entre eux (cycles de vie, flux, autorisations…). Ces services sont accessibles à partir de différentes applications : gestion des exigences, gestion de la qualité, et gestion de documents, qui sont stockées sous la forme de structures normalisées dans la base de données. En cas de modification ou d’enrichissement de l’un de ces services, le changement intervient au niveau de la plate-forme, sans modifier le code source des applications. L’avantage est que, indépendamment du nombre de customisations, la technologie au cœur du logiciel reste évolutive et sans incidence sur les applications.

Une plate-forme de ce type, telle que Aras Innovator, s’appuie sur des normes ouvertes et des protocoles Internet standards, assurant transparence et sécurité. Le système s’intègre facilement aux autres environnements logiciels existants dans l’entreprise, et le code est visualisable à tout instant sans outils ni connaissance propriétaires. L’utilisateur conserve ainsi son indépendance par rapport au fournisseur et aux consultants engagés par ce dernier.

Une plate-forme PLM de ce type apporte des avantages considérables. Elle permet en particulier de mettre à jour les applications en temps réel et sans effort de déploiement en les rendant immédiatement accessibles depuis un navigateur HTML classique. Nul besoin de lourds travaux de programmation ou de compilation pour chaque modification mineure.

De plus, en cas de mise à niveau des versions de la plateforme Aras, la couche applicative est largement inchangée, puisque les modifications ne concernent que la plate-forme. Cela permet également de minimiser l’indisponibilité des applications déjà en production

Par ailleurs, Aras assure toutes les mises à niveau des versions pour ses clients, au titre d’un abonnement et sans frais supplémentaire, y compris la migration de toutes les customisations.

Quel avenir pour le PLM ?

S’il est impossible de savoir dans quelle direction la technologie évoluera, les industriels devront être prêts à faire face à l’évolution rapide des tendances du marché. Des produits intelligents et interconnectés ont modifié en profondeur la démarche de développement des produits, avec une dépendance de plus en plus forte avec logiciels embarqués et des cycles de vie qui s’étendent bien au-delà de l’atelier de fabrication. La mondialisation a mis les entreprises en face de nouveaux défis avec une chaîne logistique planétaire et des équipes de conception et de fabrication disparates appelées à collaborer efficacement sur toute la surface du globe.

Quelles que soient les innovations technologiques qui vont impacter à l’avenir le développement de leurs produits, les entreprises devront pouvoir gérer efficacement les énormes quantités de données liées à la configuration complète de leurs produits sur l’ensemble des phases de son cycle de vie, de la définition au service après-vente en passant par la conception, le développement et la fabrication.