La migration vers Windchill est rarement une simple opération d’export, de transformation et d’import. Les projets les plus complexes commencent souvent là où les scénarios de migration standard atteignent leurs limites.

Cette réalité est particulièrement visible dans les projets de séparation d’activité (PLM Carve-Out), de fusion d’environnements PLM ou d’intégration post-acquisition. Dans ces contextes, le système cible n’est généralement pas vide. Avant même le démarrage de la migration, des bibliothèques, des données de référence, des structures produit ou des documents techniques ont souvent déjà été chargés et sont utilisés par les équipes d’ingénierie.

L’enjeu ne consiste alors plus uniquement à migrer des données : il s’agit de les intégrer de manière cohérente dans un environnement déjà opérationnel, sans compromettre l’intégrité du modèle produit.

Un projet mené pour un acteur spécialisé dans les systèmes de transmission, de distribution et de gestion de l’énergie destinés à l’industrie aéronautique illustre parfaitement cette problématique.

Pourquoi les projets de séparation d’activité et de fusion PLM sont-ils plus complexes ?

Lors d’une migration traditionnelle, les données sont transférées vers un environnement neuf. Il faut garantir la correspondance des modèles de données, la préservation des relations entre objets et le maintien de l’historique des versions, mais le risque de conflits reste relativement limité.

Dans un projet de séparation d’activité ou de fusion d’environnements PLM, la situation est très différente. Les organisations déploient souvent leur nouvel environnement progressivement. Pour répondre aux impératifs métier, certaines données sont intégrées avant même la migration complète de l’ancien système :

  • bibliothèques de composants standard ;
  • données de référence ;
  • classifications ;
  • premiers produits ;
  • documentation technique.

Lorsque vient le moment de transférer les données historiques, deux référentiels d’informations produit coexistent déjà. Ils doivent alors être réunis dans un modèle unique, cohérent et exploitable. Dans de nombreux projets, cette étape constitue le défi le plus important de toute la transformation.

Migration d’Oracle Agile PLM vers Windchill

Dans ce projet, les données devaient être migrées d’Oracle Agile PLM vers PTC Windchill. La première phase a consisté à définir conjointement la stratégie de migration :

  • analyse des besoins métier ;
  • préparation des règles de mapping ;
  • définition des transformations entre les deux systèmes ;
  • identification des scénarios potentiels de conflit.

L’extraction des données a été réalisée à l’aide de scripts développés par un partenaire externe. Notre équipe était responsable de leur exécution et participait activement à la définition des exigences fonctionnelles et techniques de la migration. Les données ont ensuite été transformées et préparées pour leur chargement dans Windchill. C’est à ce moment qu’il est devenu évident qu’une approche standard ne permettrait pas de répondre aux exigences du projet.

Quand Windchill n’est pas un environnement vierge

Avant le lancement de la migration, le client avait déjà chargé une partie de ses données dans Windchill, principalement des objets de bibliothèque utilisés comme références à l’échelle de l’organisation. Même si ces données représentaient une faible proportion du volume total à migrer, elles devaient être référencées par les données issues d’Oracle Agile PLM et conserver leurs liens avec les nouveaux objets intégrés.

Le système cible contenait donc déjà des objets portant les mêmes identifiants ou les mêmes noms que certains éléments du jeu de données à migrer. Comment gérer une situation où un objet existe déjà dans Windchill alors que ce même objet figure également dans les données migrées ?

Cette problématique est fréquente dans les projets de séparation d’activité, d’intégration post-acquisition ou de consolidation de plusieurs environnements PLM.

Les limites de Windchill Bulk Migrator

Pour mener la migration, l’outil utilisé était Windchill Bulk Migrator (WBM), la solution de PTC conçue pour les migrations de données à grande échelle. Dans les scénarios classiques, WBM permet :

  • d’importer de nouveaux objets ;
  • de gérer des migrations incrémentales ;
  • de traiter d’importants volumes de données.

Le contexte de ce projet était toutefois particulier. Certains objets déjà présents dans Windchill avaient été créés indépendamment du processus WBM. Les données issues d’Oracle Agile PLM devaient être reliées à ces objets tout en conservant :

  • les relations existantes ;
  • l’historique des versions ;
  • l’intégrité du modèle produit.

Or, les mécanismes standard de WBM n’ont pas été conçus pour ce type de scénario. Le véritable défi ne consistait donc pas à charger les données, mais à fusionner intelligemment deux ensembles d’informations produit coexistants.

Concevoir une stratégie de fusion sur mesure

Plutôt que d’adapter le projet aux limites de l’outil, nous avons choisi de développer une approche spécifique pour gérer la fusion des données.

Lors d’une première itération de test, les objets migrés ont été temporairement renommés afin d’éviter les conflits d’identification. Cette approche simplifiée a permis de valider le reste du processus et de réaliser une migration complète de bout en bout.

Nous avons ensuite travaillé avec le client pour définir les règles de gestion des collisions. Pendant près d’une semaine, différents scénarios métier et techniques ont été analysés afin de déterminer précisément le comportement attendu du système dans chaque situation. Cette phase de conception s’est révélée déterminante pour la réussite du projet.

Chaque collision nécessite une décision spécifique

Le principal défi ne résidait pas uniquement dans la détection des conflits, mais dans la capacité à prendre automatiquement la bonne décision lorsqu’ils survenaient.

Cas n°1 : les données issues d’Agile PLM constituent la référence

Lorsque les informations provenant d’Oracle Agile PLM correspondaient à la version la plus récente d’un produit, la solution développée :

  • identifiait la dernière version de l’objet existant dans Windchill ;
  • importait les données migrées comme nouvelles versions du même objet ;
  • préservait l’ensemble de l’historique et des relations associées.

L’utilisateur conservait ainsi une vision complète de l’évolution du produit.

Cas n°2 : l’objet déjà présent dans Windchill reste la référence

Dans d’autres situations, l’objet déjà existant dans Windchill devait demeurer la source d’information principale. Dans ce cas :

  • aucun doublon n’était créé ;
  • les données migrées n’étaient pas importées comme un nouvel objet ;
  • toutes les relations pointant vers l’objet provenant d’Agile PLM étaient automatiquement redirigées vers l’objet existant.

Cette approche garantissait l’existence d’un référentiel unique et cohérent pour les utilisateurs.

Automatiser pour sécuriser les itérations

Une migration PLM repose toujours sur plusieurs cycles de tests avant la mise en production. Pour garantir la répétabilité du processus, l’ensemble des scripts de transformation et de fusion a été développé puis entièrement automatisé. Le processus couvrait toutes les étapes :

  • import des données depuis les fichiers CSV ;
  • transformation des données ;
  • détection et résolution des collisions ;
  • préparation des jeux de données destinés à Windchill.

Cette automatisation a permis :

  • d’accélérer les itérations de test ;
  • d’améliorer la reproductibilité des résultats ;
  • de réduire les risques d’erreurs manuelles ;
  • de diminuer les délais de préparation avant chaque nouvelle campagne de migration.

Une mise en production maîtrisée

En raison de la sensibilité des données, notre équipe ne disposait pas d’un accès direct à l’environnement de production Windchill. La mise en production a donc été réalisée conjointement avec le client : ses équipes exécutaient les opérations dans l’environnement final, tandis que nous supervisions l’ensemble du processus en temps réel, vérifiions le bon déroulement des opérations et apportions le support technique nécessaire.

Les mécanismes de transformation, de fusion et d’automatisation validés lors des phases de test ont ainsi été appliqués lors de la migration finale, conformément au plan établi.

Au-delà de la migration : garantir la continuité de l’information produit

Ce projet démontre que le principal défi d’une séparation d’activité, d’une intégration post-acquisition ou d’une fusion d’environnements PLM n’est pas nécessairement le transfert des données lui-même. La difficulté réside avant tout dans la capacité à préserver la continuité de l’information produit lorsque le nouvel environnement est déjà en service et contient ses propres données.

Il devient alors indispensable de fusionner intelligemment plusieurs référentiels tout en conservant :

  • l’historique des versions ;
  • les relations entre objets ;
  • la cohérence des structures produit ;
  • l’intégrité globale du modèle de données.

Une migration PLM réussie exige donc bien plus que la maîtrise d’outils tels que Windchill Bulk Migrator. Elle repose avant tout sur une stratégie de transformation et de fusion des données soigneusement définie.

Dans les projets de séparation d’activité, d’intégration post-acquisition ou de fusion d’environnements PLM, le défi majeur n’est souvent pas la migration elle-même, mais la préservation d’une information produit cohérente et fiable. Lorsque le système cible est déjà en service, chaque décision concernant la donnée de référence a un impact sur l’ensemble du modèle produit. Une stratégie de fusion bien conçue devient alors un facteur clé de réussite, au même titre que la migration des données.

Points clés à retenir

  • Dans les projets de séparation d’activité et de fusion d’environnements PLM, les données sont souvent migrées vers un système déjà utilisé par les équipes.
  • Les outils standard de migration ne couvrent pas toujours les scénarios de consolidation entre données migrées et objets existants.
  • La définition de règles de fusion et de gestion des collisions est un facteur clé de réussite.
  • L’automatisation des transformations et du rapprochement des données améliore la qualité des migrations tout en réduisant les délais d’exécution.
  • Une migration PLM ne consiste pas uniquement à déplacer des données : elle doit garantir la continuité de l’information produit et la cohérence du référentiel à long terme.

Conclusion

Chaque décision prise lors de la fusion des données influence directement l’intégrité du modèle produit, la qualité des processus d’ingénierie et l’expérience des utilisateurs. C’est pourquoi la stratégie de fusion doit être considérée comme un élément aussi essentiel que la migration elle-même. Une approche méthodique, associée à des mécanismes de fusion adaptés et à une automatisation rigoureuse, permet de sécuriser la transition et de construire un environnement PLM capable de soutenir durablement les besoins de l’entreprise.