La migration des données vers un système PLM est souvent une entreprise très complexe, où l’environnement commercial et les modes d’exploitation des données jouent un rôle clé. Une migration – qu’est-ce que c’est, quelles sont les approches les plus courantes et quels défis attendent chacune d’entre elles? Ces questions et d’autres sont répondues dans cet article.
Qu’est-ce qu’une migration de données et quand en avez-vous besoin?
Une migration de données est le processus de transfert de données d’un système (source) à un autre (cible / destination).
Habituellement, les migrations de données PLM résultent de :
- Remplacer un système de gestion des données existant (peut-être même un système PLM) par un autre.
- Ingestion de données d’un autre système dans le système PLM principal d’une entreprise (par exemple, après l’acquisition d’une entreprise).
- Fusion de plusieurs ensembles de données en un seul système de sources de vérité.
- Scissions et scissions d’entreprises (organisationnelles et systèmes seulement).
- Nettoyer les données d’une organisation.
Valeur d’une migration appropriée vers les entreprises
Imaginez Tesla ou Apple perdre leurs bases de données contenant leurs définitions de produits, la documentation, l’historique des changements et plus encore. Oui, ils ont certains des ingénieurs les plus brillants au monde, alors ils seraient probablement en mesure de reconstituer leur base de connaissances et leurs ensembles de données dans la plupart des cas… finalement… Cependant, peu importe à quel point ils sont brillants, une telle chose pourrait mener à leur chute – ou du moins à de graves problèmes à court et à moyen terme, ainsi qu’à plus de quelques licenciements.
Imaginez maintenant que votre organisation passe d’un ancien système PDM à un nouveau PLM brillant. Imaginez que vos modèles CAO soigneusement conçus, construits sur des dizaines d’années et câlinés chaque nuit avec des téraoctets de méta-données bougeront avec vous. Imaginez ce qui se passerait si vous perdiez, disons… 20 % de ces données pendant le passage à PLM parce que la migration n’a pas été effectuée correctement.
Seriez-vous prêt à prendre ce risque ?
De nos jours, les organisations ne sont souvent rien sans leurs données. C’est pourquoi elles les protègent si étroitement contre la concurrence, mais aussi contre les pertes. Assurer l’exhaustivité et la cohérence des données de l’entreprise crée des emplois pour d’innombrables ingénieurs et administrateurs de bases de données dans le monde entier.
Les migrations résultent du changement, qui provoque automatiquement beaucoup de scepticisme à son égard. Cependant, ils font partie intégrante de ce changement et ne peuvent souvent pas être évités, c’est-à-dire à moins que nous voulions perdre nos précieuses données, n’est-ce pas?
Que puis-je faire pour sécuriser mes précieuses informations ?
Une bonne stratégie de migration, suivie d’une exécution minutieuse, rend la douleur de passer à un nouveau système beaucoup moins ressentie dans toute l’organisation. Il est essentiel de s’assurer que l’ensemble de données de votre système cible / destination est complet et que vos ingénieurs peuvent commencer à l’utiliser efficacement dès le premier jour, presque comme s’il n’y avait aucun changement.
De plus, une migration correctement exécutée permettra à votre organisation d’identifier les problèmes non détectés dans vos ensembles de données, créant la possibilité de les corriger lors de la migration. Croyez-le ou non, mais parfois les ensembles de données migrés sont en fait plus complets et plus cohérents que les sources, et des données de meilleure qualité équivalent à un travail et à des produits de meilleure qualité.
Ce qu’une migration de données n’est pas
- Mise à niveau d’une application / d’un système sans aucune modification de la base de données.
- Mise à niveau de la base de données sans modification du modèle de données.
Types et approches des migrations de données :
Big Bang
Une migration « Big Bang » signifie déplacer l’ensemble des données et la base d’utilisateurs du système source vers le système cible en une seule fois, ce qui entraîne la désactivation complète ou le verrouillage du système cible et l’entreprise commence à utiliser le nouveau système. Il s’agit de loin de l’approche la plus courante en matière de migrations lorsque le but ultime est de retirer/remplacer complètement le système source.
L’inconvénient de cette approche est la nécessité de verrouiller l’accès aux anciens et aux nouveaux systèmes pendant l’exécution de la migration. Cette « panne de courant » pour les utilisateurs peut durer jusqu’à quelques jours, mais les migrations sont souvent exécutées pendant la fin de semaine pour atténuer l’impact sur l’entreprise.
Une migration « Big Bang » ne signifie pas que cela se fait sans préparation. S’il est correctement exécuté, il doit suivre l’approche décrite à la section 3. Aperçu du processus de migration.
De plus, le passage de l’ensemble de l’organisation à un nouveau système peut nécessiter des efforts importants pour former le personnel à utiliser efficacement les nouveaux logiciels afin de ne pas paralyser l’organisation après la migration.
Big Bang axé sur l’utilisateur
Alors qu’une migration traditionnelle « Big Bang » déplace tous les utilisateurs et toutes les données (pertinentes) vers un nouveau système en même temps, certains optent pour une stratégie plus complexe où toutes les données ne sont pas déplacées vers le nouveau système jusqu’au tout dernier moment jusqu’à ce que les utilisateurs commencent réellement à l’utiliser.
Initialement, un instantané du système source est créé (ou parfois le système source est cloné dans son intégralité), les données pertinentes sont identifiées et migrées dans le système cible, tout en continuant à travailler dans le système source. Ensuite, un delta entre l’instantané et l’état actuel du système source est identifié et migré vers le système cible avec tous les utilisateurs.
Cette approche permet de réduire au minimum le black-out résultant d’une approche traditionnelle de « Big Bang », mais nécessite une attention particulière pour être utilisée dans le calcul et l’importation du delta afin de ne pas corrompre les données commerciales.
Par étapes / Progressif
Imaginez une organisation travaillant dans des ministères, chacun utilisant un ensemble de données relativement indépendant dans le système source. Une migration progressive permettrait à chacun de ces ministères d’accéder au système cible de façon indépendante, un à la fois.
Cela prolonge la durée de vie du système source, mais permet de débusquer tous les problèmes avec le système cible avant que l’ensemble de l’utilisateur de base sur elle, résultant ainsi une expérience globale beaucoup plus lisse pour l’entreprise. Elle permet également à une organisation de répartir la formation du personnel sur une plus longue période, ce qui la rend beaucoup moins douloureuse.
Cependant, comme vous pouvez l’imaginer, il n’y a pas que le soleil et les arcs-en-ciel. Cette approche est assez complexe et nécessite des efforts supplémentaires tant au niveau organisationnel que technique, car les données du système source peuvent être encore vivantes, même si elles ont déjà été migrées vers le système cible. Un processus doit être défini et mis en œuvre pour traiter ces chevauchements (et/ou écarts) entre les parties de migration, ainsi que les besoins des utilisateurs pour accéder aux données qui ne sont pas encore présentes dans le système cible.
Cela peut se faire en s’assurant que chaque objet a un « maître » clairement identifié (c.-à-d. soit le système source ou le système cible) à un moment donné – et en veillant à ce que l’équipe de migration et les utilisateurs soient au courant de cela et s’abstiennent d’apporter des modifications dans le « hors-plan ».
Bien qu’on nous ait demandé à maintes reprises d’effectuer une migration progressive, il était habituellement impossible d’identifier des fragments de données utilisés par un seul ministère, ce qui est une condition préalable à l’utilisation de cette approche. En raison de ces interdépendances, nous avons généralement fini par recommander (et exécuter) soit un Big Bang ou une migration progressive.
Coexistence
C’est peut-être l’approche la plus délicate pour une migration. En fait, les outils de migration existants (pour Windchill, et je suppose qu’il en va de même pour d’autres grands systèmes PLM) ne prennent pas en charge ce type de migration. Je laisserai la description ici pour référence et sensibilisation, mais n’oubliez pas que cette approche n’est peut-être pas possible dans une migration PLM.
Une migration de coexistence suppose que les systèmes source et cible doivent être synchronisés suffisamment longtemps pour que la migration soit terminée, et que l’un d’eux puisse être utilisé à tout moment. Pour ce faire, il faut établir une interface de communication bidirectionnelle entre les deux systèmes pour s’assurer que les données sont bien synchronisées.
Cette approche vise à minimiser l’impact de la migration, permettant une transition beaucoup plus facile vers un nouveau système PLM et relativement plus facile de détection et de correction des erreurs.
Du côté négatif, comme mentionné précédemment, ce genre de migration est beaucoup plus difficile à exécuter : non seulement en raison de la nécessité de synchroniser constamment les deux systèmes, mais aussi la performance prend un coup et les tests peuvent être difficiles. De plus, si les données de votre système source sont mauvaises, elles le seront également dans le nouveau système (ce qu’on appelle parfois « GIGO », c’est-à-dire l’entrée et la sortie des déchets).
Aperçu du processus de migration :
Pour mieux comprendre le processus de migration des données, nous devons d’abord comprendre le concept sous-jacent. La plupart des migrations sont fondées sur ce qu’on appelle l’ETL.
ETL signifie Extract-Transform-Load, qui est la dénomination (méthodologie) la plus courante pour aborder les migrations de données, qui est devenue populaire dans les années 1970. Il divise chaque migration en itérations comprenant les phases suivantes :
- Extraire : sortir les données du système source (-s) dans une zone de transit
- Transformation : appliquer la transformation des données pour aligner le modèle de données existant/source sur le modèle cible. C’est là que des modifications et/ou des corrections sont apportées aux données. Il est également courant pour cette phase de filtrer les données qui sont censées se retrouver dans le système cible. Un tel filtrage peut comprendre, par exemple, l’enlèvement de déchets ou d’anciens articles inutiles.
- Charger : Récupérer les données transformées dans le système cible.
Un processus d’extraction, de transformation et de chargement des données approprié permettra de s’assurer que les données obtenues sont conformes aux exigences et aux normes en identifiant et en réglant tout problème de qualité des données dans le système source (-s).
Exemple :
Souvent, vous pouvez voir une abréviation ETVL, qui ajoute « Validation » dans le mélange, mais la plupart des professionnels supposent que la validation est un must de toute façon et omettent simplement le « V » dans le nommage.
Éléments nécessaires pour réussir :
- Définition adéquate des modèles de données sources et cibles
Passer d’un système à un autre – sauf s’il s’agit d’une mise à niveau d’une version du même système (mais ce n’est pas vraiment une migration) – signifie que vous passerez d’un modèle de données à un modèle complètement différent. Il se peut qu’ils ne soient pas bien alignés et que des travaux doivent être effectués pour cartographier chaque élément d’information important (comme les attributs des objets, etc.) de la source à la cible. Cela devrait être fait comme un exercice initial pour détecter rapidement (et de façon évidente) les écarts entre les modèles de données qui pourraient compromettre l’ensemble de la migration.
- Coopération d’Experts en la Matière (EM)
Soyons francs : il y aura toujours des problèmes avec les données sources, ou comment elles devraient se traduire dans le modèle de données cible. Ces questions ne peuvent être réglées correctement que si les PME d’une organisation peuvent fournir des conseils sur ce qui est important, ce qui est correct et ce qui ne l’est pas. Ces EM doivent être à la disposition de l’équipe de migration sans frais généraux évitables et/ou retard pour assurer que la migration se déroule sans heurts.
- Communication
Comme dans toute vie, la communication est essentielle : entre les dirigeants d’entreprise et l’équipe de migration, les PME de l’organisation et l’équipe de migration, les PME et les cadres, etc. Des objectifs, des jalons, des échéanciers et des résultats bien définis et étroitement surveillés assurent la transparence de l’ensemble du processus et contribuent grandement au succès de la mobilisation.
- Équipe expérimentée pour préparer et exécuter la migration
Vous ne voulez généralement pas que les stagiaires ou les nouveaux employés s’amusent avec les systèmes cruciaux pour votre entreprise. Il en va de même pour les migrations. Si vous n’avez pas l’expertise nécessaire pour effectuer une migration à l’interne, faites appel à un bon fournisseur de services ou à un bon intégrateur de système qui peut compléter votre équipe, vous guider pendant le projet – ou prendre la responsabilité entièrement. Ne soyez pas bon marché, cependant : Vos précieuses données pourraient ne pas aimer être traitées d’une manière non professionnelle. Rappelez-vous que vous ne paieriez pas seulement pour les heures de travail pendant le projet de migration, mais pour les années d’expérience et d’expertise.
Étapes préalables à la migration (planification)
Commencez par remplir un questionnaire de base en posant des questions comme :
- Quels sont les systèmes source et cible (y compris les versions)?
- Quelles sont les bases de données source et cible (y compris la version)?
- Combien de types d’objets voulez-vous migrer (pièces, fichiers CAD, documents, etc.) ?
- Combien d’objets de chaque type voulez-vous migrer ?
- Voulez-vous seulement migrer les dernières versions, ou toute l’histoire?
- Avez-vous une personnalisation du modèle de données ou du système source qui devrait être recréé dans l’environnement cible?
- Serez-vous en mesure de fournir des environnements de mise en scène qui refléteront votre production?
… et ainsi de suite. Veuillez communiquer avec CONTACT pour obtenir un questionnaire complet si vous souhaitez passer à PTC Windchill PLM.
Les réponses à des questions comme celles-ci donneront aux experts en migration une idée de la complexité du processus et de l’effort requis pour le mener à bien. Il permettra également d’identifier les risques précoces, tels que l’incompatibilité des types de données entre les systèmes source et cible.
Une fois cela fait, planifiez une séance (ou plusieurs séances) entre les EM de votre organisation et l’équipe de migration. Cette séance devrait suivre un ordre du jour permettant à l’équipe de migration de comprendre votre environnement actuel et les données qui y résident, ainsi que de leur donner une idée de ce à quoi devrait ressembler le résultat de la migration.
La séance (-s) devrait donner lieu à la création d’un plan détaillé pour votre migration, qui devrait comprendre les premières estimations des échéanciers et des jalons. Ne vous fiez pas aveuglément aux estimations à l’avance – c’est le premier moment où vous pouvez obtenir une estimation relativement précise des coûts et des efforts.
Une fois le plan terminé et accepté par le secteur d’activité, l’équipe de migration peut commencer à « se salir les mains » et effectuer la première migration de test.
Pourquoi tester?
Parce que vous ne pouvez jamais supposer que tout se passera parfaitement bien dès le départ.
Pourquoi tester les migrations ?
Une migration typique peut être un processus long et complexe, traitant d’énormes quantités de données créées dans le système source pendant de nombreuses années. Il y aura des problèmes avec ces données. Il est toutefois impossible de dire d’emblée combien de problèmes il y aura. Il est possible que l’ensemble de données sources soit assez bien aligné avec le modèle de données cible. Il est également possible que les données sources soient en très mauvais état et qu’elles nécessitent beaucoup de travail pour être claires.
C’est là que les migrations test entrent en jeu.
Il est fortement recommandé de ne pas supposer que l’ensemble de données migré initialement est complet ou exempt d’erreurs. Au contraire, la première exécution entraînera probablement une multitude d’erreurs, ce qui entraînera un ensemble de données incomplètes. Le nettoyage des données et la création du script de transformation démarrent alors, permettant d’éliminer les erreurs identifiées lors de la première exécution.
La deuxième migration de test utilise les éléments susmentionnés pour résoudre les problèmes liés aux données, ce qui donne un ensemble de données plus complet après le deuxième passage.
Cependant, de nombreuses erreurs resteront inaperçues lors du premier essai, car certaines peuvent être liées et/ou provoquer une réaction en chaîne. Ne soyez donc pas surpris si le deuxième passage entraîne de nouveaux problèmes non détectés.
Rincer et répéter, l’équipe de migration aborde ces nouveaux problèmes et améliore leurs scripts pour assurer une qualité de données encore meilleure pour un 3e, 4e ou n-e test de migration réussi. Chaque passe est validée par les principaux utilisateurs du client et chaque passe nous rapproche de 100% d’exhaustivité et d’intégrité des données transformées.
Il revient aux utilisateurs clés et à l’équipe de migration de définir quel pourcentage d’exhaustivité est acceptable par l’entreprise, qu’il s’agisse de 100 % ou d’un pourcentage inférieur. Une fois ce niveau atteint, une dernière migration de répétition doit être effectuée avant la migration de production pour confirmer le bon comportement de tous les scripts.
Le nombre de migrations de tests dépend des progrès réalisés dans la résolution des problèmes, qui est en corrélation directe avec la complexité et la qualité des données.
Veuillez noter qu’il devrait être de l’intérêt et de la responsabilité des principaux utilisateurs d’une organisation de valider les données après chaque essai. Après tout, si quelqu’un va subir une perte de données pendant la migration, ce sera lui.
Problèmes courants dans les migrations de données PLM
- Qualité des données (source)
Souvent, les organisations ne savent pas à quel point leurs données sont compliquées tant qu’elles n’ont pas changé de système. C’est là que la collaboration avec les PME et l’efficacité de votre équipe de migration entrent en jeu. Ces problèmes peuvent tous (ou du moins en grande partie) être corrigés au cours du « T » du processus d’extraction, de transformation et de chargement des données.
Évidemment, vous ne voulez pas le faire manuellement (bonne chance avec des centaines de milliers d’objets…), donc l’automatisation et le script jouent un rôle inestimable ici. L’équipe de migration, si elle est guidée correctement par des PME, peut s’assurer que votre système cible possède des données de qualité que votre organisation n’a peut-être jamais vues auparavant.
- Données (systèmes) en constante évolution
Que vous effectuiez une migration « Big Bang » ou une migration progressive, l’ensemble de données évoluera constamment, à moins que vous ne soyez prêt à interrompre vos activités pendant environ un mois (sic!). Les données nouvelles et mises à jour représentent toujours un certain risque pour le processus de migration, car de nouveaux problèmes peuvent survenir qui n’ont pas été identifiés dans les migrations de test.
Les migrations de test appropriées atténuent ce risque de manière significative, cependant, et tout problème avec les données après une migration peut toujours être mis à jour après l’exécution. Assurez-vous simplement que votre équipe de migration est là pour vous soutenir après la migration, du moins pendant un certain temps.
- Performance
Lors de la migration vers un système PLM, vous aurez probablement besoin de déplacer d’énormes quantités de données. Cela prend du temps, que vous utilisiez le Cloud sur place ou presque à l’infini. Cependant, de nombreux éléments d’un processus de migration peuvent être automatisés via des scripts, y compris le nettoyage des données. S’ils sont écrits incorrectement, ces scripts nuiront gravement à la performance du processus de migration.
Assurez-vous toujours de comparer les performances des migrations de test avant d’exécuter une migration de production pour vous assurer que vos exigences en matière de délais (temps d’arrêt du système acceptable avant le passage à la production, etc.) sont respectées. Si ce n’est pas le cas, pensez à vous doter de meilleurs experts pour optimiser davantage. Rappelez-vous, cependant, que vous ne pouvez pas optimiser et compresser indéfiniment. Déplacer de grandes quantités de données prend parfois tout simplement du temps et il n’y aura pas grand-chose que vous pouvez faire à ce sujet.
Veuillez noter que la liste ci-dessus n’est pas exhaustive. Il ne mentionne que les problèmes les plus courants (et problématiques) auxquels nous avons été confrontés au cours des 15 dernières années. Une analyse approfondie de votre système actuel vous aidera à identifier les risques et les goulets d’étranglement potentiels, alors assurez-vous de prêter suffisamment attention aux ateliers et activités préalables à la migration.
L’histoire d’une migration réussie de PLM par le client
C’est le bon moment pour examiner un exemple de migration de données TTPSC effectuée pour un grand client automobile utilisant le système PLM Windchill de PTC. Cette migration particulière visait à faire passer ce client d’une instance Cloud entièrement gérée à l’externe à un environnement Cloud personnalisé basé sur AWS où il aurait le plein contrôle de tous les composants du système tout en maintenant des niveaux élevés d’automatisation. Parallèlement, la version de Windchill passerait de 11.0 M030 (source) à 11.1 M020.
Du point de vue de la migration, les plus grands défis étaient les suivants :
- déplacer de nombreux objets de types non pris en charge, ce qui a nécessité la création d’extracteurs et de chargeurs personnalisés, y compris les plans de projet, les demandes de promotion, les discussions, etc.
- déplacer les utilisateurs tout en modifiant les groupes et les rôles
- déplacer les flux de travail personnalisés existants, y compris l’historique complet des modifications (particulièrement compliqué et nécessitant beaucoup d’analyse et de préparation).
Il y avait une exigence intéressante pour ce projet, à savoir une date d’achèvement immuable, corrélée avec la fin de l’accord du client avec le fournisseur PLM géré. Cela a forcé l’équipe à aligner son plan sur une échéance fixe. Cependant, comme le montre le fait que le projet a été mené à bien, même les processus complexes (comme la migration des données) peuvent être quelque peu ajustés pour s’adapter à certaines circonstances.
Au total, plus de 1 600 000 (un million six cent mille) objets ont été migrés (tous avec succès). L’ensemble du projet (y compris la mise en place de l’infrastructure et l’automatisation avancée autour de celle-ci – en savoir plus sur DevOps et l’automatisation pour les systèmes PLM ici) a pris environ 5 mois. En conséquence, le client a reçu un nouveau système dans la dernière version stable avec toutes les données migrées, toutes configurées dans une infrastructure Cloud personnalisée permettant l’optimisation des coûts d’infrastructure, la reprise après sinistre, le contrôle de la disponibilité et l’approvisionnement rapide (en heures tout au plus) de nouveaux prêts-utiliser les environnements à des fins de développement et à d’autres fins. Il va sans dire que le client était extrêmement satisfait du résultat.
Vous trouverez plus d’informations sur ce projet dans une réussite
Résumé
Pourquoi ai-je pris tout votre temps pour lire ce qui précède?
La réponse est simple : Faire prendre conscience de ce qui peut être l’aspect le plus important de votre nouvelle (ou mise à jour) mise en œuvre PLM. Bien que vos beaux flux de travail et déclencheurs complexes et/ou automatisés puissent être très utiles, ce sont en fait des informations (données) qui constituent la propriété intellectuelle d’une organisation et constituent la base de ses opérations.
Maintenant, j’espère que vous comprenez quels types de migrations de données peuvent être effectuées, quelles approches peuvent être appliquées, à quoi ressemble un processus de migration, et pourquoi il a besoin de l’attention et de l’effort qui peuvent parfois à première vue sembler pas entièrement nécessaire. Je sais que cela peut être accablant, car les migrations sont un sujet complexe et souvent difficile.
Dans tous les cas, assurez-vous toujours de laisser les migrations de données entre les mains de professionnels – internes ou externes – pour vous assurer que votre entreprise ne perd pas la chose la plus importante qu’elle possède : ses données.