Migration de données ERP : bonnes pratiques et pièges courants

La migration des données est l’endroit où les implémentations ERP réussissent ou échouent au niveau le plus fondamental. Vous pouvez concevoir une architecture système parfaite, configurer le logiciel parfaitement et former les utilisateurs de manière complète, puis faire échouer la mise en œuvre parce que les données qui l'alimentent sont erronées.

Le terme « migration de données » semble technique et opérationnel. En pratique, il s’agit d’un exercice à l’échelle de l’organisation visant à faire face à la dette accumulée en matière de qualité des données au cours des années d’exploitation. Enregistrements clients en double, codes produits incohérents, inventaires non rapprochés, informations manquantes sur les fournisseurs et structures de données existantes qui ne correspondent pas clairement aux modèles de données ERP modernes : ces problèmes ne disparaissent pas parce qu'un nouveau système a été installé. Ils migrent et provoquent des problèmes dans le nouveau système qui sont parfois plus coûteux à résoudre que dans l'ancien.

Ce guide couvre le cycle de vie complet de la migration des données avec des conseils spécifiques et exploitables pour chaque phase et des descriptions honnêtes des pièges rencontrés par la plupart des migrations ERP.

Points clés à retenir

La migration des données est généralement la phase la plus sous-estimée de la mise en œuvre d'un ERP (budget 3 à 5x les estimations initiales)

Commencer l'évaluation de la qualité des données six à douze semaines avant le lancement de la mise en œuvre

Ne migrez jamais de données incorrectes : nettoyez-les d'abord, migrez ensuite les données propres.

L'approche "il suffit de tout migrer et de le nettoyer plus tard" échoue de manière fiable

Établir la propriété des données avant la migration : qui est responsable de la qualité de chaque entité de données ?

Créez des règles de validation avant la migration, pas pendant

Prévoyez deux à trois tests de migration avant la migration de basculement

Les données historiques et les soldes d'ouverture sont des problèmes distincts avec des solutions différentes

Les quatre types de données dans une migration ERP

Toutes les données d’une migration ERP ne sont pas créées égales. Comprendre les quatre types et leurs défis distincts en matière de migration est la première étape pour planifier une migration réussie.

Type 1 : Données de base

Les données de base constituent la base de chaque transaction : enregistrements clients, enregistrements fournisseurs, produits (articles), plan comptable, employés et hiérarchies d'entrepôts/emplacements. La qualité des données de base détermine directement la qualité des données de transaction : si un enregistrement client est dupliqué, chaque transaction associée à ce client aggravera le problème de duplication.

La migration des données de référence est généralement la phase la plus exigeante en main-d'œuvre, car elle nécessite des décisions commerciales concernant chaque problème de qualité des données rencontré. Les enregistrements clients en double doivent-ils être fusionnés ? Si oui, lequel fait autorité ? Comment normaliser les produits dont les unités de mesure sont incohérentes ?

Type 2 : Soldes d'ouverture

Les soldes d'ouverture représentent la situation financière de l'entreprise au moment de la mise en service : comptes clients (qui vous doit de l'argent), comptes créditeurs (à qui vous devez de l'argent), valeurs des stocks (quel stock vous détenez et à quel prix) et les soldes des comptes du grand livre. Les soldes d’ouverture doivent être précis au centime près : un écart de 0,01 $ dans les comptes clients entraînera des problèmes de rapprochement pendant des mois.

Les soldes d'ouverture sont validés par rapport à l'état de clôture du système existant et doivent être rapprochés avec précision avant que la mise en service puisse avoir lieu. Cette validation révèle souvent des écarts entre l'ancien système et l'état réel de l'entreprise (factures enregistrées mais jamais envoyées, stocks consommés mais non enregistrés, paiements reçus mais non appliqués).

Type 3 : Historique des transactions

L'historique des transactions est l'enregistrement de ce qui s'est passé : bons de commande, factures de vente, mouvements de stocks, dossiers RH, etc. Contrairement aux soldes d'ouverture, l'historique des transactions n'a pas besoin d'être parfaitement précis pour permettre les opérations - il doit être suffisamment précis à des fins de reporting, d'audit et de référence.

Pour la plupart des implémentations, l’historique des transactions des deux à trois dernières années est suffisant. L’historique plus ancien peut généralement être archivé dans l’ancien système à titre de référence plutôt que migré vers le nouvel ERP.

Type 4 : Données de configuration

Les données de configuration ne sont pas des données commerciales mais plutôt les paramètres qui permettent au système de se comporter correctement : conditions de paiement, taux de taxe, règles de tarification, configurations de flux de travail, rôles d'utilisateur, etc. Bien que cela fasse techniquement partie de la « migration », cela est plus précisément décrit comme une réplication de configuration, c'est-à-dire recréer les règles métier du système existant dans le modèle de configuration du nouvel ERP.

Phase 1 : Découverte et évaluation des données

La phase de découverte des données devrait commencer six à douze semaines avant le lancement de la mise en œuvre, et non une fois que la mise en œuvre est déjà en cours. La découverte de graves problèmes de qualité des données pendant la mise en œuvre, plutôt qu’avant, est la cause la plus courante de dépassement du calendrier ERP.

L'inventaire des données :

Cataloguez chaque entité de données qui existe dans le(s) système(s) existant(s) :

Quelles entités existent (clients, fournisseurs, produits, employés, etc.)
Où vit chaque entité (quel ou quels systèmes)
Combien d'enregistrements existent pour chaque entité
Dans quel format se trouvent les données (base de données relationnelle, fichiers plats, feuilles de calcul)
Qui est le propriétaire de l'entreprise responsable de la qualité de chaque entité

L'évaluation de la qualité des données :

Pour chaque grande entité, réaliser une évaluation quantitative de la qualité couvrant :

exhaustivité (quel pourcentage d'enregistrements tous les champs obligatoires sont-ils renseignés ?)
Unicité (quel pourcentage d'enregistrements sont des doublons ou des quasi-doublons ?)
Cohérence (les mêmes valeurs sont-elles représentées de manière cohérente dans tous les enregistrements et dans tous les systèmes ?)
Exactitude (vérification ponctuelle d'un échantillon de dossiers par rapport à la vérité terrain : inventaire physique, factures réelles des fournisseurs, correspondance réelle des clients)

Résultats typiques en matière de qualité dans les migrations ERP du marché intermédiaire :

8 à 20 % des enregistrements clients sont des doublons ou quasi-duplés
15 à 35 % des enregistrements de produits contiennent des données d'unité de mesure manquantes ou incohérentes
10 à 25 % des enregistrements d'inventaire ont des soldes qui ne correspondent pas au décompte physique le plus récent
Comptes généraux existants qui n'ont pas été utilisés depuis des années et qui devraient être supprimés
Enregistrements d'employés avec des conventions de dénomination incohérentes, des champs manquants ou des informations de rôle obsolètes

L'évaluation des risques migratoires :

Sur la base de l'évaluation de la qualité des données, classez chaque entité de données par risque de migration :

Faible risque : données propres, mappage clair vers la nouvelle structure ERP, format standard
Risque moyen : quelques problèmes de qualité, nécessite un nettoyage mais gérable
Risque élevé : problèmes de qualité importants, structure ambiguë ou exigences de cartographie complexes

Les entités à haut risque ont besoin de délais plus longs, d'une implication dédiée des propriétaires d'entreprise et d'outils ou de scripts de nettoyage de données potentiellement spécialisés.

Phase 2 : Nettoyage des données

C’est dans le nettoyage des données que se déroule le véritable travail – et la vraie valeur – de la migration des données. L’objectif est d’amener chaque entité de données à un niveau de qualité adapté à la migration vers le nouvel ERP.

Ne migrez jamais de mauvaises données. La tentation de migrer les données maintenant et de les nettoyer plus tard est forte, surtout lorsque le nettoyage prend plus de temps que prévu. Résistez-y. Les mauvaises données dans un nouvel ERP sont pires que les mauvaises données dans un système existant car :

Les règles de validation du nouvel ERP signaleront les erreurs ignorées par l'ancien système, créant ainsi des problèmes opérationnels immédiats.
Les utilisateurs qui rencontrent des problèmes de qualité des données dans le nouvel ERP blâment le nouveau système et non les problèmes sous-jacents de qualité des données.
Le nettoyage des données après la migration nécessite de comprendre le modèle de données du nouvel ERP, ce qui est plus difficile que le nettoyage des données dans la structure existante familière.

Processus de nettoyage des données :

Pour chaque entité à risque élevé et moyen, appliquez un processus de nettoyage structuré :

Extrayez les données de l'ancien système vers un environnement de test
Exécutez des règles de validation automatisées pour identifier tous les problèmes de qualité
Hiérarchiser les problèmes par volume et impact (100 enregistrements clients en double > 5 codes postaux de fournisseurs manquants)
Résoudre les problèmes liés à la contribution du propriétaire de l'entreprise (quel est l'enregistrement faisant autorité en cas de conflit entre deux enregistrements client ?)
Documenter les décisions et les résolutions pour la piste d'audit
Réexécutez les règles de validation pour confirmer que tous les problèmes sont résolus
Obtenez l'approbation du propriétaire de l'entreprise sur les données nettoyées avant la migration

Outils de nettoyage des données :

ECOSIRE utilise des scripts Python personnalisés pour la validation et la transformation automatisées, combinés à Excel ou Google Sheets pour l'examen et l'approbation par les propriétaires d'entreprise des décisions relatives aux dossiers individuels. Pour les très grands ensembles de données, les outils ETL dédiés (Pentaho, Talend ou équivalents cloud natifs) offrent de meilleures performances et une meilleure journalisation d'audit.

Phase 3 : Mappage et transformation des données

Le mappage des données définit la façon dont les données de la structure du système existant sont mappées à la structure de données du nouvel ERP. Il s’agit d’un exercice technique nécessitant d’importantes contributions commerciales.

Défis de cartographie structurelle :

Les systèmes existants ont souvent des structures de données qui ne correspondent pas clairement aux structures ERP modernes. Défis courants :

Restructuration du plan comptable : le plan comptable existant peut comporter des centaines de comptes qui doivent être consolidés dans une structure plus claire dans le nouvel ERP. Chaque décision de consolidation nécessite la contribution de l’équipe financière.
Modifications de la hiérarchie des produits : les anciens catalogues de produits ont souvent des hiérarchies ad hoc qui doivent être restructurées dans le modèle de catégorie/sous-catégorie de l'ERP. Chaque produit doit être mappé à sa nouvelle catégorie.
Reconfiguration multi-devises : si l'entreprise s'est développée pour fonctionner dans plusieurs devises depuis la mise en œuvre de l'ancien système, la configuration des devises dans le nouvel ERP doit refléter l'état actuel, et non l'historique.

Règles de transformation :

Au-delà de la cartographie structurelle, les données doivent souvent être transformées avant de répondre aux exigences de format du nouveau système. Les règles de transformation doivent être documentées avant l'exécution de la migration et examinées par le propriétaire de l'entreprise. Transformations courantes :

Standardisation du nom (tous les clients au format First Last, tous les fournisseurs avec nom légal enregistré)
Normalisation du format des numéros de téléphone (tous les numéros au format international E.164)
Validation et normalisation des adresses (validation du code postal, normalisation du code pays)
Conversion d'unités de mesure (enregistrements historiques dans les unités héritées convertis en unités standard ERP)
Mappage des codes d'état (codes d'état du système hérité mappés aux valeurs d'état ERP)

Le document de cartographie des données :

Produisez un document formel de mappage de données qui montre, pour chaque champ de l'ancien système, le champ correspondant dans le nouvel ERP, toute transformation appliquée et la règle métier régissant le mappage. Ce document est indispensable pour :

Validation du script de migration par rapport au comportement prévu
Résolution des écarts découverts lors des tests
Prise en charge des requêtes d'audit après la mise en ligne

Phase 4 : Développement et tests de migration

Une fois le nettoyage terminé et le mappage documenté, les scripts de migration peuvent être développés et testés.

Développement de scripts de migration :

Les scripts de migration extraient les données nettoyées de l'environnement intermédiaire, appliquent les transformations conformément au document de mappage et chargent les données transformées dans le nouvel ERP. ECOSIRE développe des scripts de migration en Python, en utilisant l'API Odoo XML-RPC pour le chargement. Les scripts incluent :

Validation avant la migration (confirmer que les données dans l'environnement de test correspondent à l'ensemble de données nettoyé approuvé)
Traitement par lots avec journalisation des erreurs (enregistrez tous les enregistrements dont le chargement ne parvient pas à être examiné manuellement)
Validation post-migration (confirmer que les données chargées correspondent aux nombres et valeurs attendus)
Capacité de restauration (si une migration produit des résultats inattendus, possibilité de réinitialiser l'ERP à son état d'avant la migration)

Tests de migration :

Prévoyez deux à trois exécutions de migration test avant la migration par basculement :

Test d'exécution 1 (semaine X) : Valider les fonctionnalités de base du script de migration et identifier les éventuelles erreurs de transformation
Test 2 (semaine X+2) : Valider par rapport à un ensemble de données plus complet et plus propre ; produire le premier rapport de validation complet
Test d'exécution 3 / répétition générale (semaine X+4) : migration complète de bout en bout sur l'ensemble de données final nettoyé, chronométrée, avec le processus de basculement exécuté exactement comme il le sera le jour de la mise en ligne.

Chaque exécution de test doit produire un rapport de validation comparant les données migrées aux nombres, valeurs et contraintes d'intégrité référentielle attendus. Les divergences doivent être résolues avant le prochain test.

Phase 5 : Rapprochement du solde d'ouverture

Le rapprochement du solde d'ouverture est distinct de la migration des données de base et de l'historique des transactions, car il nécessite une précision financière à un moment précis plutôt que simplement l'exhaustivité des données.

Le processus de réconciliation :

À la date de transition convenue, extrayez les soldes de clôture du système existant pour chaque entité financière : ancienneté des comptes clients, ancienneté des comptes fournisseurs, valeurs des stocks par emplacement, soldes des comptes généraux. Ceux-ci deviennent les soldes d'ouverture dans le nouvel ERP.

Rapprochez les soldes extraits avec :

Les relevés bancaires les plus récents (pour les comptes espèces)
Le plus récent rapport sur la vieillissement des comptes clients confirmé avec le personnel d'AR
Le plus récent rapport chronologique des comptes créditeurs confirmé auprès du personnel d'AP
Le dernier inventaire physique ajusté des mouvements depuis la date d'inventaire

Tout écart entre le solde extrait et la vérité terrain doit être résolu avant la mise en service. Transférez l’écart dans le nouveau système et cela entraînera des problèmes de réconciliation pendant des mois.

Le problème de la facture "toujours ouverte" :

Dans la plupart des systèmes comptables existants, il existe un certain nombre de factures qui sont techniquement ouvertes (pas entièrement payées) mais qui sont fonctionnellement mortes : contestées, irrécouvrables ou abandonnées administrativement. Ces factures « éternellement ouvertes » ne doivent pas être migrées en tant qu’AR ouvertes. Ils doivent être radiés ou marqués comme irrécouvrables avant la migration. L’équipe financière doit prendre des décisions explicites pour chacun d’entre eux.

Phase 6 : Planification et exécution du basculement

Le basculement est le moment où l’ancien système s’arrête et où le nouvel ERP démarre. La planification de la séquence de basculement évite avec précision le chaos le jour de la mise en service.

Le plan de bascule :

Documentez chaque étape du processus de basculement avec :

Qui effectue l'étape
Durée estimée de l'étape
Dépendances (ce qui doit être complété avant le début de cette étape)
Contrôle de validation (comment vous confirmez que l'étape est terminée et correcte)
Action de restauration (que faire si cette étape échoue)

Un basculement typique pour une entreprise de 100 personnes prend entre 8 et 16 heures. Le basculement est généralement programmé sur un week-end afin de minimiser les perturbations des activités.

Séquence de basculement :

Gel du système existant : aucune nouvelle transaction autorisée
Extrait final des données du système existant
Validation finale et nettoyage des données (tous les problèmes découverts depuis le dernier test)
Exécution du script de migration pour les données de base
Migration et validation du solde d’ouverture
Migration de l'historique des transactions (en cas de migration de l'historique récent)
Examen complet du rapport de validation et approbation par le service financier
Validation de la configuration du système (tous les paramètres sont corrects)
Ouverture d’un nouvel ERP

Pièges courants et comment les éviter

Piège 1 : tout migrer

L’envie de migrer toutes les données historiques est compréhensible mais souvent contre-productive. Il faut des semaines pour migrer, valider et charger dix ans d'historique de transactions provenant d'un système existant, et la plupart ne seront jamais interrogés. Définissez un horizon de migration (généralement deux à trois ans) et archivez l'historique plus ancien dans l'ancien système plutôt que de le migrer.

Piège 2 : supposer que les données du système existant sont la source de vérité

Les données du système existant sont souvent erronées. Si vous le considérez comme faisant autorité, vous migrez les erreurs dans le nouveau système. Les décomptes physiques, les relevés bancaires et les relevés des fournisseurs sont de meilleures sources de vérité pour les soldes d'ouverture que les rapports des systèmes existants.

Piège 3 : aucun environnement de test

Migrer directement vers la production sans tester dans un environnement sandbox présente un risque élevé. Maintenez toujours un environnement de test qui reflète la production pour la phase de test de migration.

Piège 4 : Implication insuffisante des propriétaires d'entreprise

Les décisions de nettoyage et de cartographie des données nécessitent un jugement commercial dont les équipes techniques ne disposent pas. Une implication insuffisante des propriétaires d'entreprise conduit les équipes techniques à prendre de mauvaises décisions commerciales, ce qui crée des problèmes de qualité des données qui se transforment en problèmes opérationnels après la mise en service.

Piège 5 : Pas de plan de restauration

Chaque mise en service doit avoir un plan de restauration explicite : si le nouveau système ne fonctionne pas correctement dans les premières 24 à 48 heures, quel est le processus pour revenir à l'ancien système ? Avoir ce plan prêt réduit la pression nécessaire pour prendre des décisions hâtives en cas de crise.

Questions fréquemment posées

Combien de temps devons-nous prévoir la migration des données dans une implémentation ERP ?

Pour une entreprise de taille moyenne (100 à 300 employés, 2 à 5 systèmes de sources de données), prévoyez six à dix semaines pour la migration des données en tant que phase dédiée, en commençant une fois que la configuration est suffisamment complète pour établir la structure de données cible. De plus, prévoyez quatre à six semaines avant le lancement de la mise en œuvre pour l’évaluation de la qualité des données et le nettoyage initial. L’investissement total dans la migration des données est généralement de dix à seize semaines, entre la première évaluation et le basculement.

Devrions-nous nettoyer les données avant ou pendant la mise en œuvre ?

Avant, toujours. Le nettoyage des données qui s'effectue parallèlement à la mise en œuvre utilise les mêmes ressources de propriétaire d'entreprise dont l'équipe de mise en œuvre a besoin pour la validation et les tests de configuration. Cela retarde également le calendrier de migration, car le nettoyage dépend de décisions commerciales qui prennent du temps à être prises. Commencer le nettoyage des données six à douze semaines avant le lancement de la mise en œuvre est l’approche la plus efficace.

ECOSIRE peut-il migrer les données de n'importe quel ERP existant ?

ECOSIRE a créé des outils de migration pour SAP Business One, QuickBooks (ordinateur de bureau et en ligne), Sage 50 et Sage 100, Microsoft Dynamics (GP, NAV, BC) et plusieurs plateformes spécifiques à l'industrie. Pour les autres systèmes, l'approche de migration est conçue en fonction du format d'exportation disponible : base de données SQL, XML, exportations CSV ou accès API. Aucun système existant n'a pu être migré, bien que l'effort varie considérablement selon le système source.

Quel est le coût typique de la migration des données dans une mise en œuvre d'un ERP ?

Pour les mises en œuvre d'ECOSIRE, la migration des données représente généralement 15 à 25 % du coût total de mise en œuvre. Pour une mise en œuvre de 150 000 $, le coût de migration des données est compris entre 22 000 et 37 000 $. La plage dépend principalement de la qualité des données (qualité inférieure = coût de nettoyage plus élevé) et du volume (plus d'enregistrements = plus de temps de développement et de validation des scripts). Les problèmes de qualité des données découverts après le début de la migration peuvent augmenter considérablement ce coût, c'est pourquoi l'investissement dans l'évaluation préalable à la mise en œuvre est si précieux.

Prochaines étapes

Si vous planifiez une mise en œuvre d'un ERP et souhaitez obtenir de l'aide pour évaluer la qualité de vos données avant de prendre des engagements en matière de calendrier et de budget, ECOSIRE propose une évaluation de l'état de préparation des données qui évalue vos entités de données clés, identifie les problèmes de qualité et fournit des estimations réalistes pour la phase de migration.

Apprenez-en davantage sur la pratique de migration Odoo d'ECOSIRE sur /services/odoo/migration.

ERP Data Migration: Best Practices and Common Pitfalls