Proposer une migration ERP : quelles données au démarrage ?

Lorsqu’une entreprise change d’ERP, « nous reprenons les données » semble désigner une seule tâche. Ton offre cache plusieurs décisions : quelles informations seront nécessaires au début du travail, quelles opérations ouvertes continueront et quelles données anciennes resteront accessibles par un moyen à clarifier séparément ? Une limite convenue aide le client à préparer le démarrage et à comprendre les prestations. Elle évite aussi qu’un souhait général de remplacement devienne implicitement une commande pour reproduire tout le passé.

Ce texte s’adresse aux fournisseurs ERP et intégrateurs qui délimitent la migration avant leur offre. Les questions et documents proposés relèvent de ton conseil, pas d’informations automatiquement livrées avec une demande. Tous les exemples sont fictifs. Le texte ne fixe aucune règle juridique de conservation ou de suppression. Le client clarifie séparément l’accès futur avec les spécialistes concernés. Ne promets aucune fonction d’import avant l’examen des environnements source et cible réellement utilisés.

Pars du premier jour de travail

Demande au client de décrire une tâche complète dans le nouvel ERP. Un commerçant fictif veut poursuivre une commande existante et en créer une nouvelle. Quels articles, partenaires et quantités ouvertes faut-il connaître ? Tu obtiens une première liste de catégories de données, pas encore une liste technique d’import. Pour ton offre, établis d’abord le travail prévu après la bascule et les informations réellement nécessaires.

Examine un second processus avec d’autres personnes. Les achats devront peut-être suivre un approvisionnement déjà confirmé. Demande s’il sera ressaisi ou repris et quels liens doivent rester. Deux tâches concrètes soulèvent d’autres questions que « toutes les données ». Note aussi les processus hors du premier démarrage. Le client peut ainsi apprécier un début volontairement limité sans renoncer à ses souhaits futurs.

Sépare référentiels et travail inachevé

Classe les informations selon leur rôle. Les données de référence décrivent par exemple les articles et partenaires ; les opérations ouvertes représentent le travail restant. Une fiche client seule n’explique pas quelle commande reste à livrer. Pour chaque catégorie, demande quelle opération devra être possible dans le nouveau système. Ton offre acquiert une structure métier vérifiable sans connaître les tables de l’ancienne application.

Discute les liens entre catégories. Une commande ouverte peut nécessiter des articles et partenaires correctement rapprochés dans la cible. Demande si le client comprend les correspondances, pas seulement si les deux listes existent. Si un ancien numéro change d’usage, désigne un responsable de cette décision. Un enregistrement importé avec succès ne prouve pas à lui seul que les collaborateurs peuvent accomplir le travail prévu.

Donne un chemin de décision propre à l’historique

Demande l’usage attendu des anciennes opérations. Le commerce souhaite-t-il consulter des commandes, la direction des comparaisons, ou les collaborateurs des pièces anciennes ? Ces besoins ne demandent pas forcément la même solution. Note chaque objectif avant de décider la reprise. Le client peut distinguer les données de démarrage d’un accès historique à clarifier séparément. Ne promets ni comparabilité complète des anciens états ni archivage précis sans étude.

Indique quels historiques restent hors de la migration prévue. Cela n’autorise pas leur suppression. Clarifie qui examine leur traitement ultérieur chez le client et quelle décision est nécessaire avant l’arrêt de l’ancien système. Associe les spécialistes concernés si des questions juridiques ou fiscales interviennent. Ta limite décrit la prestation de migration ; elle ne remplace pas cette appréciation. Un point ouvert conscient vaut mieux qu’une reprise intégrale silencieusement supposée.

Identifie la source réelle de chaque catégorie

Demande la source de chaque ensemble nécessaire. Les articles peuvent être dans l’ERP, des correspondances supplémentaires dans un tableau et les achats ouverts dans une autre application. Qui entretient chaque source et de quel moment reflète-t-elle l’état ? Un fichier bien nommé n’est pas encore un ensemble actuel confirmé. Des descriptions et exemples inventés suffisent d’abord. Les vrais exports passent ensuite par une revue appropriée, convenue avec des responsables.

Si plusieurs sources contiennent la même information, une décision métier doit fixer la version de référence. Discute par exemple le libellé article à retenir en cas de contradiction. Ne crée pas toi-même une règle d’après des fichiers apparemment plausibles. Le client confirme l’état souhaité ; ton équipe étudie sa reprise. La responsabilité du contenu reste traçable et l’implémentation reçoit une base claire au lieu de décider implicitement du nettoyage pendant l’import.

Conviens de tâches de nettoyage concrètes

Parle des problèmes de données à travers leur effet au démarrage. Doublons articles, correspondances absentes et unités contradictoires demandent des décisions différentes. Qui les examine côté métier et quel état nettoyé doit recevoir l’équipe de migration ? « Le client fournit des données propres » reste trop vague. Nomme catégorie et résultat. Si ton entreprise propose réellement le nettoyage, délimite aussi ce service sans le fondre silencieusement dans l’import technique.

Prévois les cas encore indécidables. Faut-il différer un article contesté, une solution temporaire est-elle nécessaire ou le point bloque-t-il la tâche initiale ? Réponds à partir du travail indispensable au démarrage. N’invente aucun taux d’erreur généralement acceptable. Conviens de qui décide chaque cas ouvert et de la manière de consigner son traitement. Le client pourra prendre une décision de périmètre consciente.

Vérifie un jeu d’exemple relié

Demande aux spécialistes de choisir un petit jeu significatif montrant les liens nécessaires, par exemple un article, sa relation avec un partenaire et une commande ouverte. Tu peux tout inventer lors du premier conseil. L’utilisation de données adaptées aux tests ultérieurs sera convenue séparément. La sélection doit aussi représenter une particularité réellement prévue du processus, pas uniquement le cas standard le plus facile que chacun attend déjà.

Conviens avant le test de l’appréciation métier : peut-on reconnaître la commande reprise, comprendre sa quantité ouverte et réaliser l’action suivante ? Qui le confirme pour quel ensemble ? Un message de fin d’import ne répond pas. Note séparément traitement technique et utilisabilité métier. Si une partie échoue, étudie précisément si la source, la correspondance ou la poursuite du travail doit être décrite autrement.

Prévois les changements entre essai et bascule

Les données peuvent évoluer entre un essai et le changement prévu. Qui continue à travailler, et quelles catégories sont concernées ? Faudra-t-il un nouvel état complet ou un procédé validé pour les changements ? La décision technique suit le travail réel et les capacités des systèmes. Pour l’offre, il faut surtout distinguer l’état d’essai de l’état définitif et attribuer la dernière actualisation à quelqu’un.

Parcours une modification tardive. Dans le cas fictif, une commande est partiellement livrée après l’essai. Quelle quantité ouverte doit apparaître dans le nouveau système et qui la confirme ? Sans réponse claire, la reprise de cette opération reste insuffisamment décrite. Consigne la question et son responsable. Elle entre alors dans la clarification ciblée plutôt que de devenir un supplément imprévu pendant la bascule réelle.

Attribue clairement la contribution du client

Désigne pour chaque catégorie une personne capable d’expliquer le contenu et d’obtenir les décisions métier. Ce n’est pas forcément celle qui produit techniquement l’export. Demande qui organise la vérification après reprise et répond aux écarts. Le client voit sa contribution nécessaire, et ton équipe peut décrire ses propres tâches. Une attribution par ensembles réels est plus utile qu’une promesse générale de coopération.

Résume le périmètre en liste lisible ou texte bref : catégorie, source, usage initial, état prévu, responsables, revue et exclusions. Place les prérequis techniques ouverts à côté. Si des informations centrales manquent, propose une analyse limitée si elle fait partie de tes prestations réelles. Décris son résultat sans promettre automatiquement une réalisation ultérieure. Le client choisit consciemment entre clarification supplémentaire et migration suffisamment décrite.

Compare deux limites de reprise différentes

La première offre fictive reprend seulement les articles et partenaires confirmés pour démarrer, ainsi que certaines commandes ouvertes. Les anciennes opérations terminées restent hors migration ; leur accès futur est une autre décision du client. La seconde rend également d’anciens mouvements utilisables dans la cible. Compare selon l’usage souhaité. Davantage de données ne rend pas cette seconde option meilleure à soi seul ; le bénéfice confirmé compte.

Pour chaque catégorie supplémentaire, demande quel travail serait impossible sans elle. S’il s’agit seulement d’une consultation occasionnelle, clarifie d’abord l’accès adapté. Si une opération ouverte doit être traitée quotidiennement, son utilisabilité appartient directement à la décision de démarrage. Cela permet de prioriser concrètement, sans remplacer l’étude technique ni autoriser la suppression d’informations ou l’arrêt de l’ancien système.

Enfin, demande au client de résumer ce qui sera disponible et ce qui reste volontairement ouvert. S’il cite une catégorie absente de ta description, résous l’écart avant l’offre. Consigne ensuite l’état confirmé et les responsables. Une extension pourra s’y rattacher sans présenter après coup la prestation initiale comme plus large que ce qui a réellement été convenu.

Contexte de la source

Le guide Microsoft de gestion des données Dynamics 365 cite notamment référentiels et opérations ouvertes comme données de migration. Ce contexte terminologique ne prouve aucune capacité de ta solution et ne constitue pas une instruction juridique de conservation.

Engage de nouveaux projets ERP

Les leads ERP webRichtung ouvrent des échanges avec des entreprises en Allemagne qui recherchent des offres ERP. Domaine de processus, système actuel, stade de préparation, localisation et coordonnées donnent le point de départ. Tu précises toi-même la migration. Inscris ton entreprise et prépare la commande dans webRichtung Customer ; le prix actuel apparaît avant l’engagement ferme.