MIGRATION des DONNEES du Système d’Information des TPE / PME
Cet article ne prétend pas être exhaustif sur la migration des données d’un ERP vers un autre ERP. Des ouvrages très complets existent sur le sujet. Simplement, l’expérience nous montre que tout le monde veut aller très vite dans la récupération de ses données et « oublie » certaines étapes.
La bonne récupération des données conditionne l’évolution du système d’information des TPE / PME. Le client ne se rend pas compte des difficultés et pense souvent que cette opération est aisée. Le revendeur informatique pêche par excès de confiance (surtout le commercial) et sous-estime le nombre de cas particuliers et d’exceptions à traiter.
Il y a mille et une façons d’utiliser un ERP, c’est pour cela que la récupération des données vers un autre système (que ce soit chez le même Editeur ou un autre Editeur) peut vite devenir un casse-tête chinois si on n’y prend pas garde.
Une migration de données d’un ERP (Comptabilité – Gestion commerciale – Gestion de production – CRM) peut être un projet simple ou complexe selon la méthodologie employée, mais qui reste, de toute façon, coûteuse, car consommatrice de beaucoup de temps. Les données de l’entreprise ont de la valeur et les récupérer vers un autre système représente un coût non négligeable, mais qui en vaut la peine.
Ce sont des opérations simples si elles sont bien définies au préalable avec la bonne chronologie. C’est là souvent où le bât blesse.
Ces opérations doivent faire l’objet d’une analyse préalable bien trop souvent occultée ou sous-estimée par le client et la société en charge de migrer les données vers le nouveau système d’information.
L’Etude
Cette étude commence par l’analyse de la base source avec des critères tels que :
La volumétrie, (il est préférable de savoir si la base de données comporte 2 000 articles ou 200 000 articles), ne serait-ce que pour les temps de traitements,
Les fonctionnalités utilisées par les logiciels actuels, (certaines n’existent peut-être pas dans le système cible, tout du moins en standard ou sous la forme actuelle),
Identifier les anomalies sur le contenu des données,
Identifier les incompatibilités à priori entre les bases sources et les bases cibles.
(Par exemple, un caractère utilisé dans un code article qui ne serait pas autorisé dans le système cible, donc une décision est à prendre en concertation avec le client et avant de faire la migration).
Un second travail doit être fait pour préparer la réalisation de la migration proprement dite :
Préparation de la base de destination avec certains paramètres non transférables,
Spécification des règles de migration entre les tables sources et les tables destinations,
Spécifications des tables de transcodage,
Validation du paramétrage du système cible avec le client,
Fiabilisation des données et requêtes complémentaires
Enrichissement des données.
Vous ne devez surtout pas minimiser cette étape d’étude initiale.
Celle-ci va vous permettre de savoir si la récupération des données vers le système cible se passera bien, si vous allez avoir des incohérences ou des incompatibilités. C’est important aussi de valider l’intégrité de la base d’origine, qui présente parfois quelques lacunes ou incohérences. Cette analyse va donc vous conforter sur la faisabilité de la migration, les difficultés prévisibles, voir anticiper des corrections de la part des utilisateurs du système source.
Tout ce travail d’analyse et d’étude préalable va se concrétiser par la production d’un cahier des charges qui valide le périmètre, définit la stratégie et décrit les règles et spécifications de la migration, qui décrit également les contrôles qualité qui seront effectués, les intervenants nécessaires à chaque étape et établit un planning prévisionnel du projet.
Enfin, vous allez avoir tous les éléments techniques pour établir votre devis.
Sauter cette étape, c’est risquer d’être dépendant de surprises plus ou moins lourdes de conséquences au cours de la migration. Enfin, comment voulez-vous maîtriser vos coûts et vos plannings si vous ne mesurez pas l’ampleur des tâches à accomplir !
La réalisation technique
La réalisation technique de la migration nécessite soit la réalisation de programmes adaptés, soit l’utilisation de programmes du marché qui vont exécuter la transcription des données.
Mieux vous aurez préparés la phase initiale, et plus votre migration se passera bien. Le temps que vous aurez passé en préparation sera largement regagné lors de l’exécution de la migration.
Les contrôles
Le contrôle statique est important car il vous permet de voir tout de suite si le volume de données de la base cible correspond à celui de votre base d’origine. Ensuite, avec les états standards des nouveaux logiciels, vous devez pouvoir retrouver le même C.A. / Clients, C.A. / Fournisseurs, C.A. / Articles que dans le système source. Vous devez ainsi avoir un certain nombre d’indicateurs qui vont vous permettre de valider la migration des données. C’est la validation statique.
Par contre, cela ne veut pas dire que les fonctionnalités désirées à partir de la nouvelle base de données et les nouveaux logiciels sont pleinement opérationnels. Certaines fonctionnalités peuvent être défaillantes, bien que les données transférées soient bonnes, tout simplement :
Parce qu’il manque une valeur par défaut sur un champ nécessaire à la fonctionnalité,
Parce que l’on a transféré une donnée qui n’est pas compatible,
Parce qu’un paramétrage n’a pas encore été effectué ou mal effectué.
Il s’agit du contrôle dynamique des fonctionnalités avec la nouvelle base de données.
Les bascules
Il est certain que d’effectuer ces contrôles, au combien nécessaires, sont vitaux mais prennent du temps, l’exploitation étant alors immobilisée chez le client. Les dirigeants de la société cliente pressent alors pour redémarrer au plus vite, en supposant qu’il n’y ait pas d’erreurs.
Pour toutes ces raisons, nous conseillons de faire une première migration qui permette de valider tous les points, indépendamment de l’exploitation (Bascule à blanc). Comme cela, personne n’est sous stress. Cela permet de valider l’ensemble des données migrées et de prendre le temps de faire un travail de qualité.
Cette bascule à blanc peut aussi se faire en deux étapes : validation des fichiers de base (clients/fournisseurs /Articles/Tarifs/…) puis validation de l’historique des autres données (documents Ventes/Achats /Fabrication/CRM, …).
Lorsque les éléments ont été validés avec le client, une seconde migration peut être envisagée, exploitation arrêtée cette fois. Le temps est compté, et l’erreur n’est pas admise. Pour certaines données, il n’est pas nécessaire de tout récupérer à nouveau, seulement le delta des données créées, ou modifiées. Cela n’est pas vrai pour tout et il faut prendre en compte les relations entre les données pour respecter l’intégrité de la base de données. En principe, les temps de traitement de cette seconde récupération de données sont beaucoup plus courts que lors de la première migration. Une recette de la base de données doit être validée par votre client avant la mise en exploitation selon tous les critères statiques et dynamiques définis précédemment.
Enfin, il peut être nécessaire d’effectuer des requêtes pour fiabiliser certaines données ou enrichir des données avec des compléments d’informations.
Cette démarche de bascule ne prend pas en compte d’autres logiciels qui seraient connectés à l’ancien logiciel et dont il conviendra d’intégrer des tests de raccordement à la nouvelle base de données lors de l’étude initiale.
Réussir sa migration, c’est suivre une méthodologie dont l’étude initiale est le point de départ !
Etude initiale de la migration à effectuer,
Migration effectuée selon des spécifications rigoureuses,
Contrôles statique et dynamique des données,
Bascules des données à blanc et en exploitation,
Fiabilisation et enrichissement des données.
Une migration de données ne se résume donc pas simplement à exécuter des programmes de migration. Ce n’est qu’une étape.
Réussir sa migration, c’est maîtriser sa méthodologie, effectuer une planification rigoureuse des opérations, assurer la coordination de tous les acteurs impliqués dans cette migration et que chacun soit réactif aux imprévus.
Merci d’apporter vos expériences de migration
Idée reçue : Une analyse approfondie est inutile.
L’étude initiale est superficielle ou inexistante : grave erreur. Un client ne vous reprochera jamais de prendre des précautions pour obtenir un résultat satisfaisant. Par contre, si vous lui livrer une base non conforme et pas opérationnelle, vous allez entendre du pays.
Vous pouvez trouver certains outils pour vous aider à analyser et structurer l’étude initiale de la migration.
Idée reçue : Le logiciel de migration de données fait tout
Utiliser des logiciels de migration tout fait du commerce simplifie les tâches, structure la migration des données, fait gagner du temps mais ne peut pas tout faire. Il ne peut pas décider à votre place ou celle de votre client. Ces logiciels ne feront pas l’analyse pour vous, ni les contrôles, ni les bascules, ni la fiabilisation et l’enrichissement des données.
Idée reçue : Pourquoi perdre du temps en contrôles ?
Notre migration de données est forcément bonne !
Vous pouvez également trouver certains outils pour effectuer automatiquement des contrôles statiques. Par contre, il faudra définir des scenarios de tests dynamiques en fonction des logiciels de destination et de leur base de données.