Lors de tout projet ERP, l’étape la plus délicate est sans aucun doute la mise en production. Tout est-il vraiment prêt ? N’avons-nous rien oublié ? Les utilisateurs pourront-ils toujours remplir leurs rôles ?
C’est un peu comme sauter d’un train en marche… pour monter dans un autre train en marche !
Et justement, personne ne souhaite arrêter l’activité pendant quelques jours, ni même quelques heures pour terminer une migration et démarrer avec le nouvel ERP.
Et c’est parfaitement compréhensible. L’entreprise doit continuer à vendre, à livrer, à produire, à facturer. Une migration ERP ne devrait pas pénaliser l’entreprise en mettant l’activité entre parenthèses.
Elle n’a d’ailleurs pas besoin d’être une cascade spectaculaire et dangereuse. Avec une préparation suffisante et les bons choix, il est possible de réduire considérablement les risques et de rendre le passage au nouvel ERP beaucoup plus fluide.
Mais cela suppose de ne pas commettre une première erreur : considérer la migration comme une simple opération informatique.
Il faut bien sûr préparer l’environnement logiciel, exporter et importer les données, effectuer des contrôles et résoudre les éventuelles erreurs de migration.
Mais ce n’est qu’une partie de la migration.
Il faut aussi préparer les équipes, déterminer comment seront traitées les opérations en cours, identifier les activités qui ne peuvent pas être interrompues et savoir quelles décisions prendre si quelque chose ne se passe pas comme prévu.
Ce sont des questions auxquelles l’IT ne peut pas répondre seule.
À partir de là, on ne parle plus simplement d’installer un logiciel et d’exporter puis importer des données, on parle de gestion du risque opérationnel.
S’assurer que les choix techniques servent bien l’objectif visé
Il est d’abord primordial de s’assurer que les décisions techniques prises pendant la préparation du projet sont en phase avec notre objectif de migrer de manière fluide.
Le meilleur exemple est sûrement le choix de la méthode de migration.
Attendre le dernier moment pour transvaser les fiches clients, fournisseurs, produits, etc. peut sembler séduisant pour sa simplicité : il suffit de s’assurer que le format des données est compatible.
Mais que se passe-t-il si, pour une raison ou une autre, un contretemps empêche le passage vers le nouvel ERP au jour J ?
Doit-on refaire l’export/import à la nouvelle date ? Doit-on seulement importer les données qui ont été créées ou modifiées depuis le dernier import ? Peut-on d’ailleurs les identifier depuis l’ancien logiciel ?
Une autre approche consiste à mettre en place un système qui synchronise les deux logiciels, en reproduisant dans le nouvel ERP les opérations effectuées sans l’ancien.
Cette solution permet de réduire les risques au moment de la bascule, puisqu’une grande partie des données du nouvel ERP est déjà à jour, mais elle demande davantage d’énergie et de temps de développement, et donc coûte plus cher.
Le rôle du service informatique ou l’intégrateur est de présenter les différentes options et leurs conséquences, puis d’implémenter la solution choisie, mais le choix, lui, incombe au chef du projet ou à la direction, parce qu’il s’agit d’une décision stratégique.
Définir un plan de migration
Décider de procéder au passage sur le nouvel ERP pendant un week-end ou faire coïncider la date avec un jour férié est souvent une sage décision, mais cela ne constitue qu’une fenêtre de déploiement, pas un plan de migration !
Un plan de migration doit répondre à ce qui se passe avant, pendant, et surtout après la migration.
Voici un exemple à quoi peut ressembler à un plan de migration, les échéances données sont indicatives, chaque projet ERP étant différent, les chiffres devront être rectifiés pour répondre aux réalités de la société.
J-30 : Validation des données et des processus
Durant cette première période, l’accent devrait être mis sur la vérification de la compatibilité des données entre les deux logiciels, et sur la validation des processus. Il est capital de s’assurer que les processus métier de l’entreprise sont correctement traduits dans l’ERP.
Les questions à se poser lors de cette phase sont par exemple :
- Les données sont-elles complètes et cohérentes ?
- Les processus sont-ils correctement reproduits ?
- Les opérations critiques ont-elles été testées ?
- Les écarts entre ancien et nouvel ERP sont-ils connus et acceptés ?
J-7 : Tests grandeur nature
Quand la date de bascule approche, il faut s’assurer que tous les tests possibles ont été validés, l’objectif est d’identifier à l’avance tout ce qui pourrait bloquer ou poser un problème, et d’y remédier avant la date limite.
Il faut d’abord s’assurer que tout le monde a été formé et préparé, si un seul utilisateur n’est pas prêt à 100% pour le passage au nouvel ERP, il faudra y remédier au plus vite.
C’est aussi l’occasion de définir un plan B, si, contre toute attente, quelque chose tourne quand même mal pendant la migration. N’étant jamais à l’abri d’imprévus, il est sage de se préparer à l’avance plutôt que de subir une fois le problème apparu.
Il faut définir à l’avance les critères qui permettront de décider si la bascule peut continuer ou si elle doit être interrompue. Une décision aussi importante ne devrait pas être prise pour la première fois au jour J alors que toute l’équipe est déjà sous pression.
Ces décisions sont en effet plus faciles à prendre quand on a la tête froide, plusieurs jours avant de passer à l’action.
J-1 : Fixer la dernière situation connue de l’ancien logiciel
La veille de la date de bascule est aussi le dernier jour où l’on utilise l’ancien logiciel. Il faut valider les états de stock, identifier les derniers documents enregistrés et recenser les opérations encore en cours.
Il est très important de noter tous ces points parce que la migration définitive en dépend énormément.
Jour J : Piloter la bascule
C’est l’heure de vérité pour le service informatique et pour l’intégrateur. Mais aussi pour les dirigeants : pendant que le service informatique est absorbé par la tâche, il faut que quelqu’un soit aux commandes pour surveiller l’activité et les imprévus et prendre les décisions qui s’imposent.
Si l’IT annonce par exemple que la migration prendra trois heures de plus que prévu, il est important que le chef du projet soit présent et réactif pour dire : « d’accord, on continue malgré le retard », ou bien : « On annule tout et on revient à l’ancien logiciel ».
Cette décision dépend de l’impact sur l’entreprise, c’est à la personne qui pilote cette journée cruciale de prendre cette responsabilité.
J+1 : Gérer les éventuelles anomalies
Le premier jour d’utilisation est toujours délicat, est-ce que tout le monde utilise bien l’ERP ? Est-ce que personne ne continue dans les anciennes pratiques ? Si cette première journée se passe bien, c’est généralement un bon signe pour la suite, mais c’est aussi le moment critique pour empêcher de mauvaises pratiques de s’installer : si un utilisateur commence à maintenir un fichier Excel au lieu d’utiliser l’ERP, il sera plus difficile par la suite de renverser le mouvement.
Le premier signe d’une migration qui échoue n’est pas nécessairement un message d’erreur. Cela peut être de voir vos équipes contourner l’ERP.
J+7 : Évaluer la réussite de la migration
Il est important d’identifier et d’établir une liste de paramètres qui nous permettront de dire clairement si la migration est une réussite.
- Est-ce que l’équipe s’adapte bien au nouvel environnement, ou est-ce que les utilisateurs inventent des contournements ?
- Est-ce qu’on peut “éteindre” l’ancien logiciel sans que personne le regrette ou ait besoin d’y chercher une information ?
- Est-ce que toutes les opérations (achats, ventes, fabrications, paiements) sont bien effectuées comme prévu dans le nouvel ERP ?
- Les stocks sont-ils fiables ?
Répondre à toutes ces questions permettra sans aucun doute de déterminer si la migration s’est bien passée.
J’ai moi-même participé à une migration sur laquelle les utilisateurs n’étaient pas assez bien impliqués.
La première semaine d’utilisation a été très difficile, pas à cause du logiciel : toutes les données étaient prêtes, tous les modules étaient configurés selon les besoins communiqués.
Et pourtant, rien ne semblait fonctionner comme prévu. Les utilisateurs avaient été pris de cours par la mise en production, certains n’étaient même pas au courant qu’on changeait de logiciel. Plus grave encore, certains besoins qui n’avaient encore jamais été communiqués ont fait surface, après la mise en production.
L’ERP donnait alors l’impression d’être incomplet, voir incapable d’effectuer certaines tâches.
Une migration ERP n’est donc jamais une opération à 100% technique, elle demande l’implication de tous les acteurs du projet ERP. Avec une préparation soignée et une planification minutieuse, ce qui pourrait passer pour une cascade hollywoodienne deviendrait une opération tout à fait ennuyeuse, tellement elle est maitrisée de bout en bout. Et c’est l’objectif recherché, ne pas sauter d’un train en marche, mais plutôt bien mesurer les risques et anticiper tout ce qui pourrait casser… avant que ça casse.