La migration de données est le chantier le plus systématiquement sous-estimé de tous les programmes ERP que j'ai pilotés. Le prestataire chiffre trois mois de travail sur les données. La réalité tombe entre six et neuf. À la bascule, la moitié de l'équipe éteint des incendies liés aux doublons et le comité de pilotage demande pourquoi personne ne l'a signalé plus tôt.
J'ai conçu cet estimateur pour faire avancer cette conversation de quelques mois. Il dimensionne le travail par objet de données, par volume et par ERP cible, et il fournit une estimation en jours-hommes, une fourchette de coûts et une approche de migration recommandée. Il est neutre vis-à-vis des éditeurs et couvre SAP S/4HANA, SAP ECC, Oracle Fusion Cloud, Oracle E-Business Suite, ainsi que Microsoft Dynamics 365 et AX.
Le résultat est une fourchette, pas un chiffre unique, parce que la réalité est une fourchette. Les variables qui font le plus bouger le chiffre sont la qualité des données, le nombre de systèmes sources et la quantité d'historique que vous choisissez de reprendre.
Choisissez votre ERP cible. Ajoutez les objets de données du périmètre et les volumes d'enregistrements attendus pour chacun. Renseignez l'indicateur de qualité des données en toute honnêteté. L'estimateur renvoie l'effort par objet, une fourchette totale en jours-hommes, une fourchette de coûts et une approche recommandée (Migration Cockpit, LSMW, ETL sur mesure ou hybride).
Tout s'exécute dans votre navigateur. Rien n'est envoyé nulle part. Rien n'est enregistré. Modifiez les données saisies aussi souvent que nécessaire pour mettre le résultat à l'épreuve de vos propres hypothèses.
- Données de base client : donneur d'ordre, réceptionnaire de marchandises, payeur, destinataire de facture, relations, fonctions partenaire
- Données de base fournisseur : fiches fournisseurs, conditions de paiement, retenue à la source, coordonnées bancaires
- Données de base article : données générales, vues division, vues ventes, MRP, comptabilité et calcul des coûts
- Comptes du grand livre et plan comptable : coûts primaires et secondaires, hiérarchies
- Centres de coûts, centres de profit, ordres internes : données de base du contrôle de gestion
- Commandes d'achat ouvertes : en-tête, postes, répartitions, imputations
- Commandes clients ouvertes : en-tête, postes, conditions, données partenaire
- Factures ouvertes (fournisseurs et clients) : postes ouverts avec affectations et règles de lettrage
- Soldes de stock : par emplacement de stockage, par lot, stocks spéciaux
- Transactions financières historiques : écritures, soldes, report à nouveau de fin d'exercice
- Données de base immobilisations et historique des amortissements : par classe d'immobilisations et domaine d'évaluation
- Données de base RH : employés, unités organisationnelles, postes lorsque SuccessFactors ou HCM entre dans le périmètre
Renseignez les détails de votre migration
Les champs marqués d'un * sont obligatoires.
Le schéma est toujours le même. Le cadrage se déroule en ateliers, en présence des propriétaires des systèmes. Ils vous disent que les données sont « globalement propres ». L'estimation se construit sur cette affirmation. Personne n'exécute la moindre requête de profilage avant que le chiffre n'entre dans le business case.
Un client industriel m'a affirmé que ses références d'articles étaient standardisées. Nous avons extrait les données et trouvé 12 formats différents en usage. Sur un autre programme, le système de référence des notes clients s'est révélé être un champ personnalisé que personne n'avait documenté, et trois ans d'historique ont disparu parce que le mapping l'avait manqué. Sur une migration financière, la seule personne qui comprenait l'ancien plan comptable avait pris sa retraite cinq ans plus tôt.
Le moment coûteux, c'est de découvrir ces problèmes pendant la répétition de bascule, pas pendant la planification. Une correction de qualité des données découverte à la deuxième semaine de cadrage coûte des jours. La même correction découverte lors de la troisième bascule à blanc coûte au programme des semaines, parfois un trimestre. À ce stade, les dates sont publiques, le réseau de conduite du changement est mobilisé et repousser le go-live devient un sujet de conseil d'administration.
La bonne démarche consiste à profiler les données avant de signer l'estimation. Exécutez de vraies requêtes sur la source. Comptez les doublons. Comptez les valeurs nulles. Comptez les enregistrements qui ne respectent pas aujourd'hui les règles sur les champs obligatoires de votre système cible. L'estimateur part du principe que vous le ferez. La fourchette de coûts s'élargit nettement quand vous renseignez l'indicateur de qualité des données avec honnêteté.
La bonne approche dépend de l'ERP cible, des volumes de données et du nombre de systèmes sources à consolider. Voici, dans les grandes lignes, ce que je choisis, avec l'effort exprimé par rapport à l'option la plus simple.
| Approche | Idéal pour | Multiplicateur d'effort | Outils |
|---|---|---|---|
| SAP Migration Cockpit (LTMC / LTMOM) | S/4HANA greenfield, objets standard, volumes moyens | 1,0× | LTMC, LTMOM, modèles fournis par SAP |
| LSMW | ECC, migrations de systèmes hérités, programmes encore sur des versions plus anciennes | 1,2× | LSMW, sessions BDC enregistrées |
| ETL sur mesure via SAP BTP / Integration Suite | Gros volumes, transformations complexes, consolidation multisources | 2,0× | BTP, CPI, SAP Data Services, Syniti, SNP |
| Hybride (Cockpit + ETL) | Conversions S/4HANA brownfield et migrations sélectives | 1,5× | Cockpit pour les données de base, ETL pour l'historique transactionnel |
| Natif Oracle | Cibles Oracle Fusion Cloud et EBS | 1,3× | FBDI, ADFdi, Oracle GoldenGate |
| Dynamics Data Management Framework | Cibles Dynamics 365 F&O et AX | 1,3× | Entités DMF, Azure Data Factory |
L'ETL sur mesure est le plus flexible et le plus coûteux. Le test honnête pour savoir si vous en avez besoin : vos données sources enfreignent-elles les règles standard de la cible d'une manière qu'aucun modèle ne peut corriger sans logique enregistrement par enregistrement ? Si la réponse est non, restez sur les outils livrés.
- SAP S/4HANA (greenfield, brownfield, sélectif)
- SAP ECC (toujours pertinent pour les paysages parallèles et les migrations tardives)
- Oracle Fusion Cloud ERP
- Oracle E-Business Suite (R12)
- Microsoft Dynamics 365 Finance and Operations
- Microsoft Dynamics AX (2009, 2012)
- Les directeurs de programme qui dimensionnent le chantier données avant que l'intégrateur ne s'engage sur un chiffre.
- Les responsables de la migration de données qui confrontent leur estimation interne à une référence indépendante.
- Les DSI et les directeurs financiers qui vérifient la cohérence de la ligne données dans un budget de mise en œuvre de plusieurs millions de dollars.
- Les conseillers indépendants qui produisent des chiffres défendables dans leurs propositions ou leurs revues d'assurance.
- Les équipes ERP internes qui construisent le business case sans payer une mission de cadrage à part.
- Un chiffre défendable, rapidement. Une estimation en jours-hommes objet par objet plutôt qu'une supposition unique.
- Neutre vis-à-vis des éditeurs. Construit à partir de schémas observés sur des programmes SAP, Oracle et Microsoft, et non à partir du playbook d'un seul éditeur.
- Recommandation d'approche. Il indique si Migration Cockpit, LSMW, un ETL sur mesure ou une approche hybride constitue le bon point de départ.
- Sensible au volume et à la qualité. La fourchette de coûts s'élargit quand la qualité des données baisse, comme sur les vrais programmes.
- Gratuit, dans le navigateur, sans inscription. Rien ne quitte votre machine. Actualisez et recommencez aussi souvent que nécessaire.
Quelle est la précision des estimations de migration de données de cet outil ?
Les chiffres reflètent les schémas que j'ai observés sur des programmes SAP, Oracle et Dynamics au cours des 25 dernières années. Ils sont conçus pour ancrer une discussion de planification, pas pour remplacer un exercice de profilage sur vos données réelles.
Le principal levier de précision, c'est d'avoir exécuté des requêtes de profilage sur la source. Une fourchette bâtie sur un indicateur de qualité des données honnête tient la route. Une fourchette bâtie sur l'optimisme des ateliers, non. Utilisez le résultat de l'estimateur comme chiffre de référence dans votre discussion avec l'intégrateur. Si son estimation est nettement plus basse, demandez quelle hypothèse de qualité des données il retient et comment il l'a validée.
Faut-il migrer l'historique des transactions financières ou seulement les postes ouverts ?
Pour la plupart des programmes, la bonne réponse est : postes ouverts plus soldes d'ouverture, avec un historique qui reste consultable dans l'ancien système via une archive en lecture seule ou une couche de reporting. Migrer tout l'historique transactionnel multiplie l'effort, ralentit les rapprochements et rentabilise rarement son coût.
L'exception concerne les secteurs réglementés où la conservation légale impose que l'historique vive dans le système de référence, ou les entreprises pour lesquelles des comparaisons glissantes d'une année sur l'autre dans le nouveau système sont un vrai besoin opérationnel. Dans les deux cas, le multiplicateur d'effort de l'estimateur pour les données historiques traduit la charge plus lourde.
Quelle approche de migration l'outil recommande-t-il ?
Il choisit le point de départ selon l'ERP cible, l'ensemble d'objets et les volumes. Un S/4HANA greenfield avec des objets standard aboutit généralement à Migration Cockpit. Les conversions brownfield et les migrations sélectives penchent vers une approche hybride. Des volumes importants, plusieurs systèmes sources ou de fortes transformations orientent la recommandation vers un ETL sur mesure sur BTP, ou vers une plateforme équivalente côté Oracle ou Microsoft.
La recommandation n'est qu'un point de départ. La vraie décision se prend après une preuve de concept sur un échantillon de vos données, pas à partir d'un calculateur. Considérez le résultat comme l'hypothèse de travail que vous emportez dans cet exercice.
Puis-je exporter le plan ou le partager avec mon équipe ?
Le calculateur s'exécute entièrement dans le navigateur. Vous pouvez faire une capture d'écran du résultat ou copier les chiffres par objet dans votre propre tableur de planification. Il n'y a ni compte, ni export PDF, et rien n'est stocké côté serveur. C'est voulu. Si vous souhaitez une analyse plus détaillée des chiffres, réservez un appel de 30 minutes et apportez la capture d'écran.
Couvre-t-il les données hors données de base, comme le paramétrage et la sécurité ?
Non. L'estimateur ne couvre que les données de base et les données transactionnelles. Les données de paramétrage, les rôles de sécurité, les développements spécifiques et les objets d'intégration relèvent d'autres chantiers, avec leurs propres facteurs d'effort, et ne doivent pas être mélangés à la ligne données. Les fondre dans un seul chiffre est l'une des raisons pour lesquelles les estimations de migration de données explosent dès la phase de planification.
Comment gère-t-il les déploiements multirégions et multi-entités ?
L'estimateur dimensionne un seul événement de migration. Pour un déploiement multirégions, lancez-le une fois par vague et additionnez les vagues, avec un facteur de réduction pour les modèles, les mappings et l'outillage réutilisés à partir de la première vague. D'après mon expérience, la deuxième vague coûte environ 60 à 70 % de la première, la troisième descend autour de 50 %, puis cela se stabilise. Les objets de données réglementaires locaux (fiscalité, paie, banque) sont généralement la part qui ne se réutilise pas proprement.
L'outil fonctionne-t-il pour les conversions brownfield d'ECC vers S/4HANA ?
Oui, et il ajuste l'effort à la baisse pour les objets qui se convertissent sur place par rapport à ceux qui exigent un nouveau mapping. Une conversion brownfield représente généralement 40 à 60 % de l'effort données d'une migration greenfield équivalente, car les structures clients, fournisseurs, articles et plan comptable se reportent sans nouvelle extraction. Le plus gros chantier est généralement la conversion vers Business Partner et l'impact du nouveau grand livre sur les écritures historiques.
Le calculateur est-il gratuit ?
Oui. Pas d'inscription, pas de demande d'e-mail, pas de paiement. Le calcul s'exécute dans votre navigateur et rien n'est stocké ni envoyé nulle part. Si vous voulez de l'aide pour construire le dossier de migration de données une fois que vous avez un chiffre, réservez un appel de 30 minutes.