L’importance de la Migration de données dans la réussite de son projet ERP

Dans le domaine de la gestion de projet, en particulier dans les systèmes d’information, le choix d’une méthodologie adaptée est absolument essentielle. Cela est d’autant plus vrai pour un projet ERP. EN général on opte pour la méthode en V classique.

Ces phases permettent d’établir un jalonnement structurant pour venir à bout de la majorité des problématiques, et s’avèrent particulièrement adaptées pour les projets ERP. Cependant, en parallèle de ces phases, il y a d’autres activités essentielles à la réussite d’un projet, comme la conduite du changement, la documentation, le pilotage, …Et parmi ces activités parallèles figure le sujet qui nous intéresse aujourd’hui, la Migration de Données.

Il s’agit d’une activité qui est en réalité unvéritable chantier à part entière . Dans les grandes lignes, la migration de données comprend les activités suivantes:

C’est unetâche de fondpuisqu’elle commence dès la phase de Conceptionet s’étend au delà de la mise en production . Or, malheureusement, cette activité estbien souvent reléguée au second plan, car elle n’est pas jugéecomme prioritaire. Ce qui est clairement un erreur car c’est un chantiervéritablement chronophage. Il doit donc être initié au plus tôt pour éviter de se retrouver dans une situation inextricable en fin de projet quand le temps manque…

Nous vous proposons ici de lister quelques bonnes pratiques qui peuvent s’appliquer à chaque projet.

#1- La Transversalité des Données dans un projet ERP

MeltOne porte une attention toute particulière à la migration des données et cela se reflète dans notre approche de la gestion d’un projet.

Prenons l’exemple d’une données structurante dans un projet logistique, la fiche Article. Dans un contexte où les modules logistiques d’achat et de vente de SAP sont utilisés, les données articles constituent le véritable cœur fonctionnel de la solution. C’est ici que sont concentrées les spécificités de chaque produit. On y trouve les données générales des produits (descriptions, poids, conditions de stockage…), les données financières (Taux de TVA applicable sur la vente, données de comptabilisation et valorisation…), les données de planification (Lead-time, taille de lot, stock de sécurité…), ou encore les données liées à la qualité, à l’entreposage, à la fabrication, au calcul du coût de revient… En définitive, ces données proviennent de toutes les fonctions de l’entreprise, et toutes les fonctionnalités de SAP qui ont un impact sur les produits sont représentés dans les données de l’Article.

MeltOne préconise des ateliers dédiés à la migration avec chaque département dès le début du projet pour identifier les complexités liées à la donnée (où, qui, comment). L’objectif étant de mettre en lumière les interdépendances qui peuvent exister entre les différents domaines fonctionnels. Une vision transverse à tous les métiers est essentielle. Non seulement pour une bonne compréhension des enjeux de la migration et la définition d’une stratégie pour la reprise des données, mais aussi pour parvenir à identifier les bonnes règles de gestion et, finalement, pour la réussite d’un projet ERP dans son ensemble.

De fait, une bonne migration requiert l’implication du management aussi bien du côté projet, que du côté métier. Si cette implication fait défaut, à cause d’une mauvaise priorisation ou bien parce qu’on a sous-estimé la charge de travail, cela peut être très critique pour le projet.

2- La Complexité de la Migration

Selon les projets SAP, les données à migrer ne sont pas les mêmes. La complexité de la migration est donc variable d’un projet à l’autre en fonction du périmètre à couvrir. Pour évaluer cette complexité, il est utile de se représenter chaque donnée comme une composante d’une hiérarchie allant du plus simple au plus complexe.

Commençons par le plus simple : les données de base (ou Master data). Elles regroupent les informations basiques qui varient peu, comme l’adresse d’un fournisseur, les dimensions d’un emballage… La fiche Article est un exemple de données de base parmi d’autres (comme les fiches Fournisseur, les Centres de coût, le Plan comptable…).

Dès que l’on agrège ces éléments ensemble au sein d’un niveau plus vaste, par exemple en regroupant plusieurs articles dans une Nomenclature, on monte en complexité, et l’on renforce les dépendances qui peuvent exister entre les différents domaines fonctionnels.

Au-dessus on trouvera les données transactionnelles. Elles correspondent à des données transverses à plusieurs modules de SAP et dont la nature est d’être plus exposées aux changements. Parmi les données transactionnelles on compte par exemple la reprise d’un inventaire, de commandes d’achat, de ventes ouvertes, des soldes GL, des reprises d’immobilisation…

La migration de commandes d’achat nécessite que des données dépendantes de plusieurs modules soient préalablement créées, telles que les articles, les fournisseurs, les données comptables (centre de coûts, ordre interne, comptes comptables, groupes de marchandises…). C’est pourquoi une migration réussie doit respecter strictement un séquencement des objets de migration.

À cet aspect transverse des données transactionnelles s’ajoute une variabilité forte. Ces données ont une vie propre ; une commande d’achat ouverte possède un historique des livraisons ou des paiements déjà effectués qu’il faut aussi prendre en compte dans la migration (paiement/livraison partielle).

MeltOne préconise de limiter au maximum le volume de données transactionnelles à reprendre. En effet, plutôt que de s’atteler à la lourde tâche de migrer de nombreuses commandes d’achat ouvertes, il est souvent plus efficace de les sortir du périmètre de migration, par exemple en se coordonnant avec les fournisseurs pour qu’ils livrent plus tôt et en payant les factures en attente avant le Démarrage. L’idée étant de s’affranchir au maximum d’un travail de réconciliation fastidieux.

Un autre exemple de donnée transactionnelle est la migration d’un inventaire. C’est un objet de migration critique ; une erreur dans la reprise des stocks (quantité, prix) à un impact direct sur la valorisation des stocks en comptabilité. Pour minimiser les risques d’erreur sans totalement interrompre les activités de la vie courante, une bonne pratique consiste à restreindre un tant soit peu les mouvements de stock sur une période donnée (période de « freeze » du stock), et de mettre à profit ce moment pour réaliser un inventaire physique dans l’entrepôt. Une fois la photographie des niveaux de stock obtenue, la migration peut être réalisée à partir d’une représentation fiable de la réalité.

Ainsi, l’anticipation du Go-Live par toutes les équipes de l’entreprise est toujours très bénéfique au bon déroulement d’un projet ERP.

3- La Migration est un Chantier Itératif

Un autre écueil à éviter est de penser qu’un fichier de migration se doit d’être parfait du premier coup. Une migration de donnée de qualité ne s’atteint pas au premier jet. Au contraire, il faut jouer les scénarios d’intégration plusieurs fois.

Pour ce faire, MeltOne recommande de dédier un environnement de test pour jouer les migrations autant de fois que nécessaire. Cela permet de déceler toutes les erreurs en amont, et les résoudre au fur et à mesure qu’elles se présentent. Lorsqu’on doit reprendre des données, provoquer des erreurs d’intégration est un bon signe. Elles permettent d’identifier si d’éventuels points sont à clarifier, si certaines règles de gestion demandent à être réexpliquées ou revues, et mettent en exergue les différences notables qui peuvent exister entre un système Legacy et la nouvelle solution.

MeltOne préconise également l’orchestration de « dry run ». L’objectif est de jouer la reprise des données au complet dans un environnement de test. Il est alors important de respecter la bonne séquence pour s’assurer de la cohérence de l’ensemble, un peu comme une grande répétition générale avant la migration finale dans l’environnement de production.

4- Qu’est-ce qu’une Migration Réussie ?

On peut identifier 4 facteurs clés qui permettent de réussir une migration :

Si vous souhaitez avoir des plus amples informations à ce sujet et notamment sur la gestion d’une migration vers un environnement S/4 Hana, n’hésitez pas à nous contacter : jsaccona@meltone.com.  Nous nous ferons un plaisir de vous répondre dans les plus brefs délais.