Dans le cadre d’un projet ERP, les risques liés à un changement de version sont bien réels et doivent être étudiés en fonction du contexte et des objectifs de l’entreprise. Pourtant, si l’entreprise ne met pas à jour sa solution pendant de nombreuses années, elle peut rencontrer d’autres problèmes : incompatibilité de la nouvelle version avec la version antérieure, appauvrissement des connaissances de ses équipes internes sur la solution donnée, complexification des interfaces, difficulté plus grande à intégrer de nouvelles habitudes de travail, etc. Alors, comment vérifier la pertinence d’une migration ERP ? Quelles sont les clés de son succès? Focus sur le cas Microsoft Dynamics AX et les challenges liés à la migration AX 2009 – AX 2012.

Si les éditeurs de solutions ERP proposent régulièrement de nouvelles versions majeures de leurs applications, l’entreprise ne doit, à aucun moment, se sentir obligée de faire évoluer sa solution, même si les bénéfices annoncés semblent correspondre aux nouveaux besoins fonctionnels de l’entreprise. Il est important de réaliser un diagnostic en amont pour évaluer les bénéfices et les risques liés à une migration. Cette « étude d’opportunité et de faisabilité » doit porter sur les critères déterminants tels que : la définition des périmètres d’application (iso périmètre), la mesure de l’apport de la nouvelle architecture technique (évaluation des gains en termes de réponse, consolidation des serveurs et bénéficier d’une réduction du TCO), l’impact de la nouvelle version sur l’efficacité des processus de l’entreprise, la capacité à fournir les ressources nécessaires au projet (coût de la migration et nécessaire implications des ressources métiers et dirigeants) ou encore la mesure du ROI pour l’entreprise.

A l’issue de cette phase de diagnostic, la DSI pourra définir si elle se lance dans un projet de migration ou le reporte. En général, les principales raisons de ce report sont liées à des bénéfices métier trop faibles, un manque de ressources disponibles, ou encore la nécessité de remettre à plat les processus métier en amont.

Si l’étude d’opportunité valide la décision de migrer, elle aura également permis d’identifier de manière précise les besoins organisationnels et métier (nouveaux bénéfices pour les métiers, périmètre fonctionnel élargi, homogénéisation du SI pour simplifier et fluidifier les flux d’informations etc.) et de valider la demande des utilisateurs par rapport aux objectifs généraux de l’organisation.

La conduite du changement : points de vigilance et facteurs clés de succès

Tout projet de migration  nécessite la mise en place d’une stratégie de conduite du changement. Afin de faciliter l’acception des changements induits par la mise en œuvre d’un nouveau projet, cette démarche doit débuter dès la phase de préparation et se poursuivre pendant toutes les étapes du projet (lancement, études, configuration, déploiement et appropriation).

Ces six étapes sont essentielles afin d’éviter les risques de dérapages du planning et du budget, choisir les collaborateurs métiers et fonctionnels qui seront impliqués dans les prises de décisions et optimiser la planification de ces ressources ou encore bien définir le calendrier de migration en prenant en compte les phases de faible activité (saisonnalité, w-e,…).

La phase d’étude est certainement celle qu’il faut le moins négliger car de ces conclusions, dépendra le succès du projet. Neuf points clés sont à observer de près :

  1. Etudier les adaptations spécifiques de l’ancien système et décider, au cas par cas, si un tel niveau de personnalisation est toujours nécessaire. Certaines fonctionnalités peuvent être intégrées dans la nouvelle version, les procédures et modes opératoires peuvent être revus à cette occasion
  2. Être capable d’arbitrer afin de définir rapidement une solution en cas de refonte ou de rationalisation des processus
  3. Limiter les adaptations spécifiques et privilégier le « standard » afin de faciliter les prochaines migrations et d’éviter les dépassements (budget / délais)
  4. Se rapprocher du modèle de données standard qui s’appuie généralement sur des normes et nomenclatures métier.
  5. Identifier les données et les classer par typologie (statiques, techniques et dynamiques)
  6. Etudier les transactions, les historiques et les statistiques, et sélectionner le mode opératoire de reprise de données en fonction du contexte de l’entreprise (périmètre, format et volume des données, outil de reprise)
  7. Affecter des règles claires de retraitement et d’archivage des données
  8. Ne pas sous-estimer les actions à prévoir concernant la BI, les reportings, les interfaces et la gestion des droits ; la charge liée aux tests (et le coût potentiel engendré par des tests incomplets) ; la charge liée aux reprises de données et les évolutions probables des besoins
  9. Déterminer les plans de sécurité (back up, plan de retour en arrière, etc.)

Suivent la phase de configuration qui doit être ponctuée d’au minimum trois itérations avant la « bascule » réelle et les phases de déploiement et d’appropriation, qui nécessitent la conservation des ressources critiques (préciser), une garantie pour la migration de spécifiques, et de disposer des moyens nécessaires pour sensibiliser et former les équipes internes à ce changement.

Un projet de migration représente aussi un réel challenge au niveau technique : converser une architecture performante, intégration avec les applications connexes, maitriser les risques, assurer l’intégrité des données, stabiliser la solution, maximiser le taux de service etc…

Prenons le cas d’une migration de Microsoft Dynamics AX 2009 vers 2012

Alors que la sortie de Microsoft Dynamics AX2015 est annoncée pour la fin de l’année, nombreuses sont les entreprises à encore utiliser AX 2009 (correspondant à la V3). Celles qui entament l’étape de migration se tournent vers la version AX2012 (R3) dont la couverture fonctionnelle est très large. La version R3 s’est notamment enrichie  au niveau du WMS, TMS, Points de Vente et e-commerce et a déjà fait ses preuves dans beaucoup de structures. Il est donc essentiel qu’une mise à niveau des utilisateurs finaux soit intégrée dans la phase d’appropriation notamment sur le nouveau modèle de données qui représente une des étapes les plus critique d’un projet de migration AX2009 vsAX2012.

Dans ce cadre, le passage d’AX2009 à cette version plus riche permet au client d’éviter des coûts financiers liés à des développements spécifiques, la multiplication d’add-on et de réduire la mobilisation de ressources en interne.

Chez un des leaders des plats cuisinés individuels en France, nous avons pu observer un besoin de soutenir une croissance à l’international, répondre à de nouveaux enjeux commerciaux, et améliorer sa performance sur la gestion des stocks. Le groupe a choisi de migrer sa version AX 2009 vers la version AX 2012, ce qui leur a permis de simplifier leurs flux d’information, optimiser la gestion de leurs stocks à travers la mise à disposition d’un outil WMS et converger vers une technologie bien maitrisée. Ce choix de migration a été pour le groupe une étape stratégique dans le développement de nouveaux horizons (croissance à l’international, amélioration de sa performance globale) ainsi que dans sa compétitivité.

Enfin, pour assurer son succès, un projet de migration doit impliquer un dirigeant – Directeur Général ou Directeur Financier. Il sera le garant du suivi du projet et de la rapidité et de la fluidité du processus de décision, idéalement sans remise en cause.

_________
Ahmed Mahcer est Directeur Général de TVH Consulting