Différent par conception. Différent pour ce qui vient ensuite.

Le contenu de cette page a été traduit automatiquement par un service tiers.

Après près de 30 ans dans le secteur de la gestion du cycle de vie des produits, j’ai appris que le PLM ne reste jamais vraiment immobile.

J’ai passé 15 ans chez Siemens, 10 ans chez PTC, et cela fait maintenant deux ans que je travaille chez Aras. Au cours de cette période, j’ai vu le PLM évoluer à travers plusieurs ères distinctes. Chacune d’elles a été façonnée par de nouvelles exigences métier, une complexité croissante des produits et les technologies disponibles à l’époque.

Ce qui était au départ essentiellement un moyen de gérer des fichiers d’ingénierie est devenu un socle essentiel pour la façon dont les entreprises conçoivent, fabriquent, entretiennent et améliorent en permanence des produits de plus en plus complexes.

Le secteur a réalisé d’énormes progrès. Mais il a également accumulé de la complexité. Aujourd’hui, de nombreux industriels doivent composer avec des informations produit fragmentées, des systèmes fortement personnalisés, des processus déconnectés et des décennies de connaissances d’ingénierie précieuses réparties entre de multiples systèmes et applications.

Aujourd’hui, l’intelligence artificielle crée un nouveau tournant majeur.

La véritable question va au-delà de l’ajout de fonctionnalités d’IA au PLM. La valeur à long terme dépend de la capacité de l’environnement PLM sous-jacent à fournir le contexte connecté, l’adaptabilité et la gouvernance dont l’IA a besoin. C’est pourquoi je pense qu’être différent est important.

Le PLM a commencé par répondre à un besoin immédiat de l’ingénierie

Les origines du PLM moderne remontent à un besoin concret : les entreprises qui adoptaient des outils de CAO avaient besoin d’un moyen fiable de stocker, contrôler et gérer leurs fichiers d’ingénierie.

À mesure que la conception numérique se généralisait, les industriels devaient savoir quel dessin était à jour, qui l’avait modifié et quelle version avait été validée. La gestion des données produit est apparue pour apporter de la rigueur face à l’augmentation rapide du volume d’informations numériques liées à l’ingénierie.

À partir de là, le périmètre s’est élargi.

Les entreprises ont commencé à gérer les nomenclatures, les structures produit, les documents, les révisions, les approbations et les modifications techniques. Le PLM a dépassé le simple stockage de fichiers pour devenir un système permettant de contrôler la définition du produit.

Il s’agissait d’une avancée importante, mais les systèmes créés à cette époque étaient naturellement façonnés par les problématiques et les contraintes technologiques du moment.

Ils étaient souvent centrés sur les services d’ingénierie, les environnements de CAO et des données produit fortement structurées. Ils étaient généralement déployés sous la forme de vastes implémentations monolithiques conçues pour standardiser les processus et maintenir un contrôle strict.

Pour répondre aux défis de cette époque, cette approche avait du sens.

Le PLM s’est étendu à l’ensemble de l’entreprise

À mesure que les produits et les organisations devenaient plus complexes, les entreprises attendaient davantage du PLM.

Les équipes d’ingénierie ne travaillaient plus au sein d’un même site ou d’une seule discipline. Les entreprises devaient collaborer entre des centres de développement répartis dans le monde, des unités commerciales, des fournisseurs, des sites de production et des organisations de service.

Le PLM s’est étendu pour prendre en charge des processus plus larges, notamment la gestion des exigences, la qualité, la planification de la fabrication, la collaboration avec les fournisseurs, la gestion des configurations, l’ingénierie des systèmes et le service.

La relation entre le PLM et les autres systèmes d’entreprise est également devenue de plus en plus importante. Le développement produit ne pouvait plus fonctionner indépendamment de l’ERP, du MES, de la chaîne d’approvisionnement, de la qualité et des autres systèmes opérationnels.

Les entreprises voulaient pouvoir concevoir partout et fabriquer partout. Elles avaient besoin d’environnements fédérés capables de prendre en charge des équipes réparties dans le monde entier tout en maintenant le contrôle des configurations et des modifications produit.

La notion de cycle de vie du produit dépassait désormais largement le cadre du service d’ingénierie.

Mais à mesure que le PLM étendait son périmètre, les implémentations devenaient souvent plus complexes. Les systèmes étaient personnalisés pour prendre en charge des processus très spécifiques. Les intégrations se multipliaient. Les mises à niveau devenaient difficiles. Dans certains cas, les entreprises consacraient tellement d’efforts à préserver le système qu’elles avaient mis en place que son adaptation à de nouvelles exigences métier devenait un projet majeur.

Le système conçu pour gérer le changement n’était pas toujours lui-même facile à faire évoluer.

Le SaaS a changé le modèle de déploiement, mais la transition a été difficile

La transition majeure suivante du secteur a été celle du cloud et du SaaS.

La proposition de valeur était claire. Les entreprises pouvaient réduire leurs responsabilités en matière d’infrastructure, simplifier les opérations, améliorer l’accessibilité et adopter plus régulièrement de nouvelles fonctionnalités. Pour de nombreuses organisations, le SaaS représentait l’avenir des logiciels d’entreprise.

Mais le passage d’un PLM traditionnel sur site au SaaS s’est révélé bien plus difficile que la destination elle-même.

De nombreux environnements PLM établis ont été construits au fil des années, voire des décennies. Ils comprenaient des personnalisations étendues, des intégrations, des structures de données et des processus reflétant la manière dont chaque entreprise concevait et livrait ses produits. Le passage de ces environnements au SaaS était rarement aussi simple que le transfert de l’installation existante vers le cloud.

Dans de nombreux cas, les fournisseurs ont dû revoir en profondeur l’architecture de leurs offres pour le SaaS. Les clients se sont alors retrouvés face à ce qui pouvait s’apparenter à une nouvelle implémentation : migration des données, reconstruction des intégrations, refonte des processus, formation des utilisateurs et décision quant aux années de personnalisations qui pouvaient, ou devaient, être conservées.

Les avantages du SaaS peuvent être convaincants, mais le coût, les perturbations et les efforts organisationnels nécessaires pour y parvenir peuvent être considérables.

Cela a mis en évidence un problème important du modèle PLM traditionnel. Une entreprise pouvait percevoir la valeur stratégique d’une migration vers le SaaS tout en restant limitée par la complexité de son environnement existant. La technologie avait progressé, mais le client ne pouvait pas nécessairement en tirer parti sans repartir pratiquement de zéro.

Le passage du logiciel au cloud n’a pas automatiquement résolu toutes les limites associées au PLM traditionnel.

Un système rigide fourni en mode SaaS reste un système rigide. Une application standardisée peut être plus facile à exploiter, mais elle peut aussi obliger les entreprises à se conformer à des processus qui ne correspondent pas à la manière dont elles créent des produits différenciés ou servent leurs clients.

La question centrale est donc devenue plus importante que l’endroit où le logiciel était hébergé :

Comment une organisation peut-elle moderniser son environnement PLM sans abandonner les connaissances produit, les processus, les intégrations et la valeur métier qu’elle a mis des années à créer ?

Cette question est particulièrement importante parce que le développement produit ne cesse jamais d’évoluer. Des acquisitions ont lieu. Les réglementations changent. De nouvelles disciplines d’ingénierie interviennent. Les produits intègrent davantage de logiciels et d’électronique. Les chaînes d’approvisionnement évoluent. De nouveaux modèles économiques apparaissent.

Les industriels ne devraient pas avoir à entreprendre une nouvelle réimplémentation coûteuse chaque fois que les technologies d’entreprise entrent dans une nouvelle ère.

Nous sommes entrés dans l’ère de l’IA

Aujourd’hui, le secteur traverse une nouvelle transition majeure.

L’intelligence artificielle a le potentiel de transformer la manière dont les ingénieurs recherchent des informations, évaluent des alternatives, identifient les risques, accomplissent des tâches répétitives et prennent des décisions tout au long du cycle de vie du produit.

Mais l’IA ne peut pas produire des résultats fiables à partir d’informations déconnectées et mal gouvernées.

Un système d’IA peut être capable de générer une réponse techniquement plausible. Dans un environnement industriel, une réponse plausible ne suffit pas. Les ingénieurs doivent savoir à quelle configuration produit la réponse s’applique, si les informations sous-jacentes sont à jour, qui les a approuvées, quelles exigences les régissent et comment une action proposée pourrait affecter la fabrication, la qualité, la conformité, les coûts ou le service.

L’IA industrielle a besoin de contexte.

Ce contexte provient des relations entre les exigences, les pièces, les documents, les logiciels, les simulations, les modifications, les fournisseurs, les plans de fabrication, les dossiers qualité et les actifs physiques.

En d’autres termes, l’IA a besoin de la continuité numérique.

C’est pourquoi je ne considère pas l’ère de l’IA comme une simple occasion supplémentaire d’ajouter des fonctionnalités au PLM. Elle permet de déterminer si le socle PLM est capable de connecter les informations, de préserver la gouvernance, de prendre en charge l’évolution des processus et de rendre les connaissances produit accessibles aux personnes comme aux systèmes intelligents.

Pourquoi Aras est différent par conception

Ce qui m’a attiré chez Aras n’était pas simplement un autre ensemble d’applications PLM. C’était une philosophie de conception différente.

Aras a été conçu en partant du principe que les exigences métier continueraient d’évoluer.

Son architecture basée sur des modèles permet aux organisations de faire évoluer les modèles de données, les workflows, les relations et les applications sans traiter chaque changement comme une personnalisation logicielle traditionnelle. Son approche ouverte permet aux entreprises de connecter les informations dans l’ensemble de leur environnement d’entreprise. Sa philosophie de mise à niveau vise à aider les clients à préserver ce qu’ils ont construit tout en continuant à adopter de nouvelles fonctionnalités de la plateforme.

Il ne s’agit pas simplement de différences techniques.

Elles déterminent si une entreprise peut répondre à une nouvelle réglementation sans lancer un programme de remplacement sur plusieurs années. Elles déterminent si une entreprise acquise peut être intégrée à une continuité numérique commune. Elles déterminent si les équipes d’ingénierie, de fabrication, de qualité, les fournisseurs et les équipes de service peuvent travailler à partir d’un contexte produit connecté.

Et de plus en plus, elles déterminent si l’IA peut être intégrée à de véritables processus du cycle de vie des produits plutôt que de fonctionner comme une expérimentation déconnectée.

Aras n’exige pas que chaque élément d’information produit soit copié dans un référentiel unique. La plateforme peut connecter et gouverner les informations entre les systèmes existants tout en fournissant les relations et le contexte nécessaires pour comprendre le produit tout au long de son cycle de vie.

Cette approche est particulièrement importante dans les environnements d’entreprise fragmentés qui existent aujourd’hui.

Être différent doit créer une valeur différenciée

Être différent n’a pas de valeur en soi.

La valeur vient de ce que cette différence permet aux clients de faire.

Elle leur permet de se moderniser sans devoir constamment repartir de zéro.

Elle leur permet d’étendre le PLM à de nouveaux processus métier à mesure que les besoins évoluent.

Elle leur permet de connecter les systèmes et les informations existants plutôt que de supposer que chaque application peut être remplacée.

Elle leur permet de préserver des décennies de connaissances d’ingénierie tout en adoptant de nouvelles technologies.

Et elle leur permet de se préparer à l’IA en établissant le contexte produit connecté et gouverné dont les systèmes intelligents ont besoin.

Voilà ce que signifie pour moi « différent par conception ». Il ne s’agit pas simplement d’une affirmation concernant l’architecture logicielle. C’est un engagement à aider les clients à continuer d’évoluer.

L’IA ne sera pas la dernière ère

L’IA est la vague technologique qui définit notre époque, mais elle ne sera pas la dernière.

De nouvelles technologies, de nouveaux modèles opérationnels, de nouvelles réglementations et de nouvelles formes de complexité produit continueront d’émerger. Dans dix ans, les industriels seront confrontés à des exigences que nous ne pouvons pas encore prévoir pleinement aujourd’hui.

La capacité la plus importante ne sera donc peut-être pas celle d’anticiper tous les besoins futurs.

Ce sera peut-être la capacité à s’adapter lorsque cet avenir arrivera.

Le PLM a commencé par gérer les données de CAO. Il s’est étendu à la gestion des structures produit et des processus d’entreprise. Il a évolué pour prendre en charge la collaboration mondiale, les écosystèmes connectés, la continuité numérique et désormais l’IA.

La prochaine ère apportera un nouvel ensemble d’exigences.

Les entreprises ne devraient pas avoir à abandonner les connaissances produit, les processus et les fondations numériques qu’elles ont mis des décennies à construire chaque fois que le secteur entre dans une nouvelle phase.

Elles ont besoin d’une plateforme conçue pour évoluer avec elles.

C’est pourquoi je pense qu’Aras est différent par conception.

Différent et conçu pour s’adapter à ce qui vient ensuite.