Le long intérim PLM: une pièce, deux systèmes de référence, aucune date de bascule

Un groupe mécatronique européen remplace le système qui conserve ses données d’ingénierie depuis deux décennies - et la partie la plus difficile n’est pas la nouvelle plateforme. Ce sont les années durant lesquelles les deux plateformes sont en service simultanément. Ce groupe a préparé le programme dans les règles de l’art, et y a pourtant été confronté. C’est le cas de presque toutes les entreprises qui migrent des données d’ingénierie.

Une plateforme, plusieurs cultures d’ingénierie et un bibliothécaire que personne ne peut éteindre

Le groupe rassemble plusieurs activités industrielles aux cultures d’ingénierie, processus et outils spécialisés historiquement distincts. Chacune a développé ses propres méthodes de conception, son propre environnement CAO et ses propres données de référence. Pendant des années, les données produits ont été conservées dans un système PDM interne fonctionnant aux côtés de SAP et servant, en pratique, de bibliothèque technique pour les modèles CAO et les plans.

L’organisation déploie désormais une plateforme PLM unifiée et hautement adaptable pour standardiser la gestion des données produits dans l’ensemble de l’entreprise. L’ambition couvre le cycle en V complet : exigences clients et produits, architecture système, vérification et validation, nomenclatures d’ingénierie et de fabrication, ainsi qu’une interface claire avec l’ERP. La gouvernance est exemplaire - un cabinet de conseil indépendant en systèmes d’ingénierie a été sollicité très tôt pour challenger les besoins et définir l’architecture cible, un intégrateur spécialisé s’occupe de la configuration, des sprints agiles avec vélocité mesurée sont mis en place, et un référent métier accompagne chaque communauté d’ingénierie afin que personne ne s’écarte du modèle commun. Une première version sera déployée dans quelques semaines.

Le programme fonctionne. Ce qu’il a également révélé, c’est la partie de la carte que personne n’avait dessinée : l’état dans lequel l’entreprise va réellement vivre au cours des prochaines années.

Point de défaillance #1

Vous ne pouvez pas effectuer une migration de données d’ingénierie en « Big Bang »

La bascule d’un ERP peut se faire en un long week-end. On gèle les transactions le vendredi, on charge le nouveau cœur, on ouvre le lundi et on gère deux semaines un peu agitées. Les données d’ingénierie ne se comportent pas ainsi. Une pièce n’est pas une simple ligne - c’est un modèle CAO natif avec des révisions, des liens vers d’autres modèles, un plan, un historique de modifications et une place dans des assemblages qui sont encore fabriqués et vendus aujourd’hui. Le volume et la profondeur technique de ces données rendent toute rupture nette impossible.

Le groupe fait donc ce que finit par faire toute organisation d’ingénierie : exécuter une réplication bidirectionnelle maître-esclave entre l’ancien PDM et le nouveau PLM, et migrer les gammes de produits une par une. Pas pour un week-end. Pour des mois qui se transforment en années.

Ce qui fait discrètement de la période intérimaire la véritable architecture. Dans cet état, l’autorité sur un objet est décidée par une date. Une pièce créée avant le transfert de sa gamme est maîtrisée dans l’ancien PDM et répliquée dans le PLM. Une pièce créée après est maîtrisée dans le PLM et répliquée en sens inverse. Les deux affirmations sont correctes. La règle qui détermine laquelle s’applique n’existe dans aucun système.

Le problème surgit au moment de la réutilisation - or la réutilisation est tout l’intérêt d’un PLM. Un nouvel assemblage intègre un composant conçu il y a dix ans. Ce composant se trouve côté hérité ; l’assemblage est construit côté nouveau système. Quelle révision est la bonne ? Quel processus de modification le régit ? Une mauvaise réponse vous fera valider un produit basé sur une définition obsolète. Interrogez les deux catalogues : chacun vous répondra avec certitude.

Une migration ERP prend un week-end. Une migration de données d’ingénierie prend une époque.

Point de défaillance #2

Quand un flux de données rompt, la première étape est de savoir à qui il appartient

Comptabilisez les acteurs présents sur la chaîne technique entre un modèle CAO et un article ERP : l’éditeur de la plateforme, le fournisseur des connecteurs CAO tiers, l’intégrateur chargé de la configuration, le cabinet de conseil garant de l’architecture cible, l’IT interne et les référents métier opérationnels. Six organisations, toutes compétentes, chacune responsable de son propre composant.

Imaginez maintenant qu’un flux s’interrompe. L’anomalie se situe-t-elle dans le cœur du PLM, dans le connecteur CAO, dans le modèle de configuration ou dans le paramétrage interne ? Impossible de le déterminer à partir du simple symptôme. Le diagnostic se fait donc par élimination, en traversant les frontières organisationnelles. Or, chaque frontière dispose de son propre système de tickets - un outil interne d’un côté, un portail fournisseur de l’autre, sans état partagé ni calendrier commun. Le temps de résolution d’un défaut est principalement consommé par ses allers-retours entre acteurs.

Il ne s’agit pas d’une défaillance d’un fournisseur. Le problème est structurel et mérite d’être nommé clairement : dans un système assemblé projet par projet, chaque partie possède sa boîte, mais personne ne possède ce qui circule entre les boîtes. L’intégration est traitée comme un sous-produit du dernier projet qui en a eu besoin - elle n’a donc ni propriétaire, ni feuille de route, ni suite de tests, ni cycle de vie propre.

Chaque fournisseur possède une boîte. Personne ne possède les flèches.

Point de défaillance #3

Configurable ne veut pas dire architecturé

La plateforme a été choisie pour son ouverture, et c’est exactement ce qu’elle offre. Le prix d’une page blanche, cependant, est qu’il faut la remplir. Chaque état d’objet, chaque transition, chaque schéma d’approbation, chaque cycle de vie - la vie d’une exigence, l’anatomie d’une modification - doit être spécifié à partir de zéro, au sein d’une entreprise qui n’a jamais eu à formaliser ces règles par écrit. L’équipe décrit cela comme la sensation de réinventer ce qui devrait être fourni en standard. Des fonctionnalités en apparence triviales nécessitent des mois de configuration et de tests.

Les droits d’accès sont le domaine où cela fait le plus mal. Plusieurs communautés d’ingénierie, des sites en Europe et en Asie, et des projets transversaux : quatre à cinq niveaux de sécurité, une vingtaine de rôles et des règles conditionnelles par-dessus - une pièce rattachée à un projet inter-divisions outrepasse les restrictions qui s’appliqueraient normalement. La modélisation a consommé beaucoup plus d’heures et de tests que prévu, et génère encore des erreurs lors de l’instanciation de nouveaux objets.

Aucun de ces efforts n’est gâché - définir la manière dont votre entreprise caractérise une pièce, une modification ou une validation est un vrai travail intellectuel, qui résistera mieux aux montées de version que du code spécifique. Mais observez où cela est consigné : le modèle de données de l’entreprise se retrouve encodé sous forme de configuration dans la plateforme d’un seul éditeur. Il ne peut pas être réutilisé côté ERP, ne peut pas régir le PDM hérité pendant la phase transitoire, et ne migrera pas vers la plateforme suivante.

Ce que la cible exige réellement

Dix prix, et un seul est utile ici

L’image cible est claire et classique dans ce secteur : un fil conducteur numérique ininterrompu, de l’exigence client jusqu’à la validation finale ; un lien automatisé et bidirectionnel entre le PLM qui définit le produit et le processus, l’ERP qui gère les achats, la logistique et les coûts, et le MES qui pilote l’atelier ; la conception mécanique, électronique et logicielle embarquée réunie au même endroit ; et un contexte utile restitué à l’ingénieur - ce que coûte réellement une pièce, si son test de qualification a réussi - sans ajouter le moindre champ à remplir.

C’est cette dernière ambition qui soulève la question décisive pour l’ensemble de l’architecture. SAP conserve environ dix types de prix différents pour une pièce. Lequel doit figurer dans le PLM ? Le coût standard ? Le dernier prix d’achat ? Le prix prévisionnel pour la période à venir ? Chaque réponse est pertinente pour un service et trompeuse pour un autre - et chaque réponse qui implique de copier la valeur devient fausse dès le lendemain.

La même question se pose pour le statut de test conservé dans une base de données de qualification interne, et de nouveau pour les modifications : le processus de modification du PLM et les ordres de modification de l’ERP doivent s’aligner, alors qu’aujourd’hui le pont entre les deux repose encore en partie sur l’intervention humaine.

Le problème résumé en une image
Une bibliothèque qui déménage vers un nouveau bâtiment, étagère par étagère, sur plusieurs années. Les deux bâtiments sont ouverts. Les deux catalogues sont exacts pour leurs propres étagères et faux pour celles de l’autre. Qu’un livre se trouve dans l’ancienne ou la nouvelle aile dépend de son moment d’arrivée - et cette règle n’a jamais été inscrite dans aucun des deux catalogues. Elle réside chez les personnes qui effectuent le déménagement. Interrogez le catalogue et vous obtiendrez une réponse affirmée. Interrogez le lecteur qui s’est rendu dans le mauvais bâtiment et vous obtiendrez la vérité.

La solution

Pas un meilleur pont entre deux systèmes - une couche au-dessus des deux

Le premier réflexe est de renforcer la réplication entre l’ancien PDM et le nouveau PLM, puis de consolider la passerelle vers l’ERP, avant d’en créer une efficace vers le MES à son arrivée. C’est la reconstruction classique du problème n×m, projet après projet : chaque nouveau système multiplie les liaisons, chaque mise à niveau de plateforme les fragilise, et lorsque le PDM hérité est enfin éteint, les passerelles créées pour l’intérim sont jetées avec lui. Des années de travail délibérément jetables.

L’alternative consiste à placer une couche d’intégration au-dessus des systèmes, détenue par le métier plutôt que par un projet spécifique, accomplissant cinq missions :

• Une définition unique de la pièce, au-dessus des deux systèmes de référence. Le PDM hérité conserve ses codes, le nouveau PLM conserve les siens, et la couche les associe à une définition unique au niveau métier. La règle liée à la date cesse d’être une connaissance empirique pour devenir une partie intégrante du modèle - lisible, vérifiable et identique pour tous.
• Lier au lieu de copier. Les dix prix restent dans SAP. La couche référence en temps réel celui qui a du sens dans le contexte donné, au moment où l’ingénieur le consulte. Rien n’est répliqué dans le PLM, rien ne devient obsolète, et la question passe de « quel prix doit-on copier ? » à « quel prix désigne-t-on ici ? ».
• Traiter le temps comme une dimension à part entière. Un environnement en cours de migration voit ses structures évoluer en permanence. Enregistrer le moment où une définition, un maître ou une hiérarchie a changé permet de relire un assemblage vieux de dix ans par rapport aux structures de l’époque - au lieu d’être réinterprété à votre insu par le modèle d’aujourd’hui.
• Connecter une seule fois, pas en n×m. La CAO, le PDM hérité, le PLM, SAP et la base de données de tests se connectent chacun une seule fois à la couche, et non entre eux. Lorsque le MES arrive, il rejoint le modèle plutôt que d’ajouter du câblage - et les connexions temporaires ne deviennent plus du travail perdu.
• Attribuer un responsable au flux. L’intégration devient un élément disposant d’un cycle de vie propre - versionné, testé, documenté, géré - plutôt qu’un produit dérivé du dernier projet qui en avait besoin. Définir les responsabilités autour du flux et non autour des boîtes est ce qui met fin aux renvois de balle.

Rien ici ne remplace le programme PLM, et rien n’a besoin d’être migré pour que cela fonctionne. Les systèmes restent exactement là où ils sont ; la couche se place au-dessus et démarre petit - un objet, la pièce, et un flux. Le reste s’étend selon les besoins.

Ce que cela change

Un programme réduit de moitié et un périmètre opérationnel en quelques mois

La différence ne réside pas dans l’élégance architecturale. Elle réside dans le calendrier. Interconnecter les systèmes les uns aux autres projet après projet est précisément ce qui transforme l’intégration en une décennie de travail : chaque nouveau système multiplie les liaisons, chaque mise à niveau de plateforme les met en danger, et les passerelles construites pour la transition sont jetées lorsque le système hérité est enfin éteint. Connecter chaque système une seule fois à une couche qui détient le modèle élimine la majeure partie de ce travail avant même qu’il ne soit créé.

Dans des environnements comparables, le constat est constant : une feuille de route d’intégration qui s’étalerait autrement sur près d’une décennie se réduit à environ la moitié de cette durée - et un premier périmètre opérationnel est déployé en quelques mois, au lieu des deux à trois ans requis par une approche plateforme par plateforme avant que quoi que ce soit ne soit exploitable. La raison n’est pas la vitesse d’exécution mais le séquencement : le premier objet que vous modélisez est utile en soi, avant même que le second système ne soit connecté. Il s’agit d’ordres de grandeur constatés sur des programmes similaires, et non d’une prévision pour un environnement particulier.

C’est précisément le cœur de métier de boTec. Trente ans d’expérience dans les industries de transformation et de production, plus de cent connecteurs prêts à l’emploi et une démarche qui débute par votre modèle économique plutôt que par nos logiciels : DataBridge constitue la couche, et le projet consiste à construire le modèle sur celle-ci en collaboration avec vos équipes. Votre programme PLM poursuit son cours. Votre ERP reste inchangé. Rien n’est migré pour mettre en place ce socle - et les données comme le modèle restent exportables, garantissant que cette fondation ne devienne jamais la prochaine solution dans laquelle vous êtes verrouillé.

La période transitoire n’est pas une phase à subir. Pendant plusieurs années, elle constitue l’architecture que vous exploitez réellement.

La leçon s’applique partout

Quatre signes que votre état transitoire est devenu permanent sans le dire

Les détails présentés ici sont issus de la mécatronique, mais le schéma reste le même dès qu’un système cœur est remplacé - chimie, pharmacie, énergie, équipement industriel, agroalimentaire. Chaque fois que l’objet est trop lourd pour être déplacé en un week-end, une longue période de coexistence s’ensuit, accompagnée des quatre mêmes signaux :

• Deux systèmes de référence pour le même objet, avec une autorité déterminée par une date plutôt que par une règle explicite et accessible.
• Des interruptions de flux de données diagnostiquées par élimination entre au moins trois fournisseurs, répartis sur autant de systèmes de ticketing.
• Une logique d’intégration qui n’existe que dans la configuration d’une seule plateforme - et qui ne peut donc ni régir le système que vous quittez, ni celui que vous acquerrez à l’avenir.
• Une architecture cible sans schéma représentant l’état transitoire - la situation dans laquelle vous vivrez le plus longtemps est celle que personne n’a conçue.

La voie à suivre ne consiste pas à réduire de force la durée de l’intérim. Elle consiste à cesser de le traiter comme un désagrément temporaire et à lui donner un modèle : une définition d’un objet critique, maintenue au-dessus des systèmes qui le stockent, afin que l’ancien système puisse être éteint naturellement et le nouveau remplacé un jour sans heurts. Une fondation capable de survivre aux plateformes sous-jacentes est exactement la raison d’être de boTec DataBridge.