La checklist indispensable pour une migration PLM réussie

L’obsolescence du logiciel, des performances accrues, des innovations technologiques, une meilleure ergonomie ou de nouvelles exigences Métiers vous poussent à envisager un upgrade de votre PLM vers une version plus récente. Les enjeux sont importants (coûts, timing, organisation…) et se lancer dans ce type de projet ne s’improvise pas. Voici donc la checklist indispensable pour une migration PLM réussie.

Avec une trentaine de migrations, en accompagnement de nos clients, éditeurs ou en tant qu’intégrateur, nous avons su acquérir une expérience solide et une vision 360° sur ce type d’opérations. Au fil des ans, nous avons fait murir notre méthodologie pour que chaque migration soit un succès, quel que soit le contexte. Nous vous proposons de la découvrir.

Avant de commencer, petit point rapide de vocabulaire. Une « migration » peut également être appelée upgrade, ou montée de version selon vos interlocuteurs. Théoriquement, les 3 termes impliquent la même chose. Dans cet article, nous parlerons principalement de montée de version majeure.

Qu’est-ce que cela signifie ? En règle générale, les versions logicielles ont une numérotation : X.Y.Z

• X étant le numéro de la version (s’il change, on est sur un upgrade majeur)

• Y étant le numéro de la version release (s’il change, on est sur un upgrade mineur)

• Z étant le numéro de patch (on est souvent plutôt sur du correctif que de l’upgrade) : la théorie voudrait qu’un patch n’impacte pas les aspects métiers/fonctionnels ou techniques, sauf pour y apporter une correction.

EN AMONT DE LA MONTÉE DE VERSION

Les phases amont de préparation et de planning sont les plus importantes.

✅ Avant de commencer votre migration, concentrez-vous sur l’initiation et la construction du planning, en prenant en compte les aspects techniques ET les aspects métiers.

Côté technique :

✅ Analysez et évaluez les impacts côté hosting. Pour une montée de version majeure, de plus en plus d’éditeurs poussent leurs clients vers du SaaS ou du Cloud.

Cela peut également être un bon moyen de simplifier la gestion de votre SI. Dans tous les cas, sachez anticiper les impacts sur tous les aspects de connectivités et donc de sécurités (entrée/sortie de données de votre SI) qui pourront impacter votre planning.

✅ Notez également que le PLM ne sera pas forcément le seul à être impacté.

Prenons un exemple : vous migrez votre PLM, cependant votre version de Windows serveur n’est finalement plus compatible avec votre nouvelle version de PLM. Vous allez fatalement devoir faire évoluer votre serveur. Cela peut également être le cas pour vos outils annexes (Adobe principalement) ou sur la partie SQL.

C’est pourquoi vous devez impérativement évaluer les changements à prévoir en discutant avec l’éditeur en avance de phase. Veillez à rester informés de ces changements via les release notes, afin que tout soit bien intégré dans les phases de tests qui vont suivre.

✅ (Pour une version on premise) Prenez en compte la gestion de vos environnements (DEV, UAT, Pré-Prod, Prod…) et prévoyez que lors de la migration de chaque serveur, vous devrez probablement le doublonner (nouveau serveur en parallèle du serveur en cours de migration). Enfin, dans ce cas de figure, n’oubliez pas de prévoir de la disponibilité chez vos équipes d’infra / de prod, afin qu’elles puissent assurer cette phase et palier ses impacts.

Mon conseil 💡 : pour l’UAT, je vous conseille d’avoir un serveur d’UAT, au moins pendant la phase de migration, qui soit identique au serveur de production. Cela vous permettra d’effectuer l’ensemble de vos tests en conditions réelles.

✅ Gelez toutes les autres évolutions en cours. La migration est un projet complexe, n’allez pas vous rajouter des difficultés supplémentaires en maintenant vos équipes à la fois sur des évolutions et à la fois sur la migration. Il faut que l’ensemble des équipes soient concentrées sur la montée de version pour plus d’efficience. Il est indispensable de travailler avec une roadmap construite et réaliste !

✅ Anticipez les impacts sur le SI. Ne négligez pas les échanges de données entre outils qui doivent être testés.

✅ Ne négligez pas les tests de montée en charge. Ces tests permettent de s’assurer que le PLM pourra continuer à répondre en termes de performances et ainsi éviter des temps de correction souvent très longs par la suite. Prévoyez des phases de dry run avec des serveurs opérationnels pour ces tests.

Côté métier :

En amont de la migration, les équipes métiers ont un rôle extrêmement important à jouer. En effet pendant une montée de version majeure, il y a des nouvelles fonctionnalités, des process qui changent, des impacts sur l’ergonomie ou sur la navigation dans le PLM… Il est donc important d’identifier en amont sur le plan fonctionnel ce qui change, même si vous restez en iso périmètre.

✅ Intégrez autant les équipes métiers que les équipes techniques dans vos réunions de travail.

Gardez bien en tête que ce sont elles qui vont être les garantes de tous les aspects du périmètre fonctionnel. Vous devez impérativement travailler main dans la main sur le contenu de la migration, discuter avec elles des nouvelles fonctionnalités (ergonomie, utilisation etc) et maintenir une communication forte entre les équipes.

Ces réunions vont également permettre aux équipes métiers d’être préparées lorsque vous les solliciterez pour les phases de tests. N’hésitez pas à organiser une petite réunion avec elles avant le recettage, afin de leur présenter toutes les nouveautés et ainsi fluidifier les phases de tests.

Et justement…

✅ Préparez la recette et identifiez des key-users. Les key-users sont les personnes que vous allez solliciter sur cette phase pour revoir l’ensemble des process concernés par la migration, rédiger le cahier de recette et les scenarii de tests et planifier et organiser les sessions d’UAT par métier. Vous serez certainement amenés à organiser plusieurs sessions par métier avec les potentiels incidents, les nouvelles phases de test etc. Souvent très sollicités par le quotidien, les collections, il faut anticiper au maximum leur implication, vu le large périmètre qui peut être à couvrir :

N’oubliez pas qu’au-delà des process purement métiers, il faudra également faire des tests d’intégration avec les autres outils du SI impactés par le PLM, et notamment l’ERP sur des interfaces de style, de matières, de couleurs, de nomenclature etc. C’est une étape extrêmement importante pour un passage en production parfaitement opérationnel.

Grâce tous les éléments énoncés, vous êtes maintenant capable d’estimer les actions à réaliser et les points à piloter en amont :

✅ Définissez les objectifs du projet et son périmètre. L’objectif sera normalement le même pour tout le monde : réussir la migration dans les délais. Le périmètre, en revanche, comme évoqué plus haut couvre un nombre beaucoup plus important d’éléments fonctionnels et techniques à prendre en compte. Assurez-vous donc d’avoir une vision la plus globale possible de tous les éléments et de ne rien oublier.

✅ Identifiez et réservez le temps nécessaire à l’ensemble des acteurs. Prenez en compte que l’éditeur, même s’il est en réalisation, ne sera pas tout seul. Il y aura également les partenaires, les intégrateurs, donc assurez-vous d’identifier toutes les parties prenantes, avec des rôles définis pour chacun. N’oubliez pas d’inclure les personnes qui ne sont pas en full time sur le projet, les équipes de prod par exemple, au risque de voir vos délais allongés par manque de disponibilité à des moments clés du projet.

Dans certains cas l’éditeur peut vous indiquer quelles sont les personnes à solliciter, sinon à vous de les identifier. Si nécessaire, n’hésitez pas à faire intervenir un prestataire externe pour prendre le relai sur les missions quotidiennes pour que vos key-users puissent se consacrer à la migration.

✅ Définissez un RACI, un planning et une date de livraison. Anticipez les périodes de collection et bookez des délais de livraison réalistes. Vous pouvez prévoir un plan B si vous n’êtes pas certains de vos temps. Evitez les plannings trop optimistes afin d’anticiper les phases de retours de tests, les temps d’intervention etc.

✅ Définissez les KPIs, les canaux de communication et la comitologie.

• Pour vos KPIs : listez les lots fonctionnels, fixez les attendus par lots puis validez et testez au fur et à mesure.

• Concernant les canaux de communication : mettez-les en place en amont afin de fluidifier la communication. Ce peut être une conversation Teams, des points de suivi réguliers, un outil de ticketing pour gérer la recette etc.

• Enfin pour la comitologie : fixez par exemple un COPIL mensuel et un Daily meeting de 10 min avec l’ensemble des interlocuteurs. Ces réunions doivent apparaître au planning dès le début.

À ce stade, si toutes les étapes précédentes ont été bien respectées, vous êtes en mesure d’obtenir une estimation réaliste du budget par rapport à l’estimation macro faite au préalable avec l’éditeur.

PENDANT LA MONTÉE DE VERSION

Côté technique : Vous n’avez pas d’actions particulières à prévoir. Vous devez simplement piloter la charge et vous assurer de respecter le planning en parallèle. En cas de dépassement / décalage, levez les alertes et réajustez le planning.

Côté métier : Les équipes métiers vont être extrêmement sollicitées pendant la migration. Elles devront assurer les sessions d’UAT afin de tester l’ensemble des process écrits et identifiés, mais aussi détecter rapidement les incidents pour les traiter. Nous vous recommandons d’utiliser des outils type JIRA pour les tracer et les affecter (soit à l’éditeur soit aux Key-users).

Il est important de faire des meetings de suivi réguliers de ces incidents afin de pouvoir re-tester les process par la suite.

Une fois que ces deux étapes sont finalisées, vous allez pouvoir acter la mise en prod, ou la reporter si nécessaire.

Pour les recettes & UAT n’hésitez pas à vous baser sur une méthode Agile :

APRÈS LA MONTÉE DE VERSION

✅ Formez l’ensemble des utilisateurs. Une nouvelle fois, ce sont les équipes métiers qui vont être fortement sollicitées sur cette phase après la migration. Généralement, on forme uniquement les key users qui eux forment ensuite les utilisateurs finaux.

✅ Mettez à jour les supports de formation avec la nouvelle version du logiciel. Cette phase est primordiale car le jour où l’ensemble des utilisateurs travailleront avec la nouvelle version, tout devra être parfaitement carré.

✅ Accompagnez vos utilisateurs dans la conduite du changement : vous devez vous assurer que vous ne perdez personne en route, que tout le monde a embarqué dans cette nouvelle version avec vous. Vous devez suivre la montée en compétences de vos équipes et évaluer l’adoption de cette nouvelle version pour réajuster l’accompagnement si nécessaire.

✅ Ne négligez pas la phase de hand-over. Cette phase consiste à faciliter la transition entre l’équipe projet et l’équipe run (qui est bien souvent différente). Celle-ci se divise en 3 phases :

• Partager les release notes : communiquer sur les éléments qui ont changé et remonter les interrogations en amont

• Former les équipes run sur tous les aspects qui ont évolué

• Maintenir la disponibilité de l’équipe projet durant la phase post-livraison. Sur les deux semaines qui suivent la migration par exemple, assurez-vous qu’une personne de l’équipe projet pourra venir en renfort des équipes run en cas de besoin.

✅ Réalisez un sanity check lors de la mise en production.

• Définissez des tests de non-régression qui seront à rejouer après la migration

• Assurez-vous de la disponibilité d’un interlocuteur métier durant le week-end de livraison.

L’idée est de sélectionner quelques-uns des tests de non-régression qui seront définis comme prioritaires (par exemple : se connecter, parcourir la liste des produits, créer une nomenclature etc…) et les faire tester pendant le week-end de migration. L’objectif étant de s’assurer que les grandes fonctionnalités soient opérationnelles lors du démarrage le lundi matin.

Pour résumer :

• En amont, assurez-vous de maîtriser l’ensemble des impacts techniques et de l’intégration des équipes métiers

• Planifiez les phases d’UAT et l’ensemble des phases de tests

• Investissez du temps dans la formation et l’accompagnement post migration

• N’oubliez pas le hand-over et le sanity check !

Vous avez à présent toutes les cartes en main pour faire de votre migration une réussite. Gardez en tête que chaque projet est différent et que vous aurez certainement à prévoir des ajustements lors des différentes phases. Cependant en travaillant en mode agile et en communiquant au maximum avec vos équipes, vous garantissez l’efficacité de votre montée de version.

Vous avez un projet lié au PLM et vous souhaitez en discuter ? N’hésitez pas à prendre contact avec moi par mail : thibault.havez@fit-retail.com ou via LinkedIn, je me ferai un plaisir d’échanger avec vous !