La gouvernance des données, au sens large, est une thématique dans l’ère du temps : le volume de données à traiter est exponentiel (avec l’avènement du Big data et de l’intelligence artificielle, entre autres) ; la sécurité des données est au centre de nombreuses polémiques et législations (au niveau GDPR, cybersécurité, et autres) ; l’intensité de la concurrence, la diversification des substituts, la facilité d’entrer sur certains marchés avec l’internationalisation font que le laps de temps pour prendre la bonne décision se raccourcit.
Bien que le nettoyage de données et la mise en place des bonnes pratiques autour de la gouvernance de données puissent se faire à n’importe quel moment du cycle de vie d’un système d’information, il est très fréquent que ces activités ne soient réellement implémentées qu’au moment du passage à un nouveau système. C’est le moment charnière où l’on souhaite repartir d’une base de données propre, avec des processus de gestion qui soient adaptés à la nouvelle solution, pour éviter les écueils du passé et surtout réduire les risques opérationnels associés.
C’est pourquoi la migration de données est définitivement un des tracks les plus critiques d’un projet de digitalisation de type ERP, CRM, GED ou autre. Une nouvelle solution informatique aura bon être de qualité, bien testée et bien adoptée, si la migration de données est un échec, la mise en production et la période de post-go-live seront cauchemardesques pour les utilisateurs finaux de la solution mais aussi pour l’équipe projet qui devra ramasser les pots cassés, et faire des corrections parfois extrêmement compliquées a posteriori.
En effet, de mauvaises Master data impliquent des transactions incorrectes, voire bloquées si des Master data sont manquantes. Cela peut perturber les opérations, entraînant des erreurs ou des blocages dans des activités telles que la production, les transports, ou la facturation. De plus, ces problèmes peuvent également impacter les rapports tactiques et reportings stratégiques, ce qui peut amener à de mauvaises décisions, voire à un manque de décision au moment opportun.
La migration de données est un art, GCP Consulting en a développé une expertise poussée depuis plus d’une dizaine d’années pour accompagner ses clients et faire de ce ‘track’ difficile une pleine réussite. Comment ? En s’assurant de mettre en œuvre les facteurs-clés de succès expérimentés au travers de nombreux projets de digitalisation:
1. Bien calibrer la migration au travers du périmètre de reprise
Il est fréquent que les clients souhaitent migrer TOUTES les données présentes dans leur système d’information actuel vers le nouveau système. Le problème, c’est que cela a un coût : en euros et en temps vu la charge de travail qu’un grand volume de données à nettoyer, à extraire, à transformer et à charger va impliquer.Généralement, ce n’est pas pertinent car des données sont devenues obsolètes ou n’ont plus d’intérêt légal, stratégique ou opérationnel. Il est donc important de bien calibrer, au travers d’ateliers d’analyse dédiés, quelles sont les données qui sont obligatoires et/ou importantes pour le nouveau système, quels sont les besoins de conservation légale mais surtout les besoins en rapidité, en format et en fréquence d’accès des données historiques.
Ces données « historiques » peuvent tout à fait être conservées dans l’outil actuel en lecture seule, si le coût des licences le permet, ou peuvent être chargées dans un outil d’historisation, un data warehouse ou autre.
Une fois que les données vraiment utiles au nouveau système sont identifiées, il faut donc bien définir les règles de reprise pour extraire, transformer et charger uniquement les données utiles. Par exemple, ne reprendre que les clients actifs, ou que les fournisseurs avec postes ouverts et/ou qui ont fait l’objet d’une commande endéans les 2 dernières années.
Une fois que ces règles sont claires, il est possible pour l’IT interne (généralement) d’extraire les données des systèmes actuels pour permettre ensuite leur transformation, si besoin, puis leur chargement dans le nouveau système d’information, de manière très résumée.
2. Coordonner la migration à l’aide d’une planification minutieuse
La migration de données est une activité de projet au même titre que la configuration de la solution (ERP, CRM, autre), que les tests et que les formations. Il est donc primordial d’inclure toutes les activités d’analyse, de nettoyage, d’extraction, de transformation, d’enrichissement, de chargement et de validation dans le planning du projet.
Cela permet d’anticiper toutes les activités pour garantir de respecter le planning et de prévenir toutes les parties prenantes en amont de ce qui est attendu d’elles et à quel moment du projet, avec la charge de travail qui leur incombe.
Cette planification inclut de prévoir plusieurs runs de test de migration à plusieurs moments-clés du projet, notamment en amont des tests d’acceptance visant à valider la solution, pour ensuite faire augmenter la qualité de migration au run de test suivant. Cela doit se dérouler avant les formations des utilisateurs finaux, pour maximiser l’adoption de la solution, et également, pour garantir que le dernier run de migration dans l’environnement de production (et non plus de test) sera un succès pour utiliser les données migrées « dans la vraie vie ».
Le nombre de runs de test à prévoir va évidemment varier en fonction de la durée du projet, du volume de données, de leur complexité, etc. Prévoir plusieurs « pour du beurre » avant de passer en production, est définitivement une bonne pratique, essentielle à la réussite de la migration. Mieux vaut supprimer un run planifié, qu’en ajouter un dans un planning trop serré.
L’objectif est aussi de pouvoir de mieux en mieux calibrer la durée de chaque activité pour que la planification soit de plus en plus précise d’un run à l’autre, jusqu’à pouvoir optimiser la reprise de données en production pendant le basculement officiel de l’ancien au nouveau système.
3. Assurer une bonne répartition et compréhension des rôles et responsabilités
La migration de données peut sembler technique par la nature des activités « ETL » (Extract – Transform – Load), et pourtant c’est une activité davantage métier car les données sont maîtrisées et utilisées par le métier, qui sera le premier à payer les pots cassés dans le cas d’une migration ratée.
C’est pourquoi, pour chaque donnée du périmètre de reprise, il est essentiel de définir les parties prenantes clés de toute la chaîne ETL:
- Le métier, qui va participer à l’analyse des données, au mapping avec le nouveau système et à la définition de la règle de reprise ;
- L’IT interne, qui va généralement être en charge d’adapter ou de développer des programmes d’extraction des systèmes actuels (sauf dans certains cas particuliers où le métier est plus à même de le faire, notamment pour les données financières) ;
- Le métier, qui va transformer les données extraites pour les faire « matcher » avec le format des données à reprendre, fourni par l’intégrateur de la nouvelle solution, lorsque le volume ou la complexité de transformation permet de gérer la transformation manuellement (mais en masse au travers de fonctions Excel par exemple). Sauf dans le cas où la transformation peut être automatisée avec des règles pré-définies dans les programmes d’extraction ou dans un cockpit « ETL » spécifique (du type SAP ADM pour prendre un exemple dans le monde de SAP).
- L’intégrateur de la nouvelle solution est celui qui va ensuite charger les données (master data et données transactionnelles) dans le séquencement pertinent, dans un environnement de test pour commencer, puis en production le cas échéant.
- Le métier va à chaque étape être responsable de valider les données extraites, transformées, chargées, pour s’assurer de maximiser la qualité de la migration.
Même s’il incombe à l’IT d’extraire correctement les données (et parfois de les transformer) sur base de règles pré-définies et à l’intégrateur d’assurer que les x lignes du fichier de chargement, sont effectivement x lignes chargées dans le nouveau système, personne ne sera plus à même de valider la qualité, l’intégrité et l’unicité de la donnée que le métier.
4. Anticiper le nettoyage des données
Nettoyer des données dans un système d’information peut être réalisé à n’importe quel moment de la vie d’une solution informatique, il ne faut pas attendre un nouveau système pour ce faire. Mais comme énoncé en introduction : c’est humain, le déclencheur du nettoyage est souvent un projet de digitalisation, car on veut repartir sur une base de données propre pour le futur.
Et même si toutes les règles de reprise ne sont pas toujours définies en amont ou dès le début du projet de digitalisation, une partie des données est intuitivement dans le périmètre de reprise : les données actives (comptes, clients, fournisseurs, contrats, projets, articles, …). Cela permet de prioriser les activités de nettoyage.
C’est pourquoi nous recommandons d’anticiper tout ce qui peut l’être au niveau du nettoyage des données pour :
- Anticiper une charge de travail qui ne devra pas être parallélisée avec tout le reste de la charge de travail pendant le projet.
- Améliorer la qualité des données en amont du premier run de test de migration.
Pour ce faire, il faut commencer par analyser les données du système actuel, en identifiant les incohérences, les doublons, les erreurs, le non-respect des conventions de nommage, etc., à partir d’extraits des systèmes actuels.
Ensuite, il faut définir les règles de nettoyage pour pouvoir organiser un groupe de travail dédié qui va effectuer les corrections identifiées, soit dans le système actuel (manuellement ou en masse selon les possibilités), soit dans des fichiers de travail qui seront utilisés pour la reprise.
Enfin, vu qu’entre le démarrage du nettoyage en amont ou en début de projet, et le basculement dans la nouvelle solution, il peut s’écouler de nombreux mois, nous suggérons fortement d’identifier les sources des erreurs dans les données pour définir les règles de création et de maintenance dans le système actuel. Cela permet d’éviter que de nouvelles erreurs soient générées pendant le projet et nécessitent des boucles interminables de nettoyage de données. Ce ne sera finalement que bénéfique pour le passage à la nouvelle solution.
5. Adopter un suivi des KPIs de performance de la migration
L’objectif d’une bonne coordination de la migration de données et de l’exécution de plusieurs runs de test de migration avant le basculement en production, est fondamentalement pour assurer :
- L’exhaustivité des données
- L’augmentation de la qualité des données
- La diminution de la durée de migration des données
C’est pourquoi il est essentiel de mesurer les KPIs de performance de chaque run pour garantir que nous allons dans cette direction, en :
- Vérifiant la quantité de données extraites et chargées au travers du taux d’intégration ;
- Mesurant le taux de validation des données par le métier au travers de leurs contrôles en masse et par échantillon.
- Référençant le minutage de chaque activité pour chaque donnée pour s’assurer que lors du basculement en production, la migration prendra le moins de temps possible pour limiter au maximum le ‘freeze’ des opérations.
Des tableaux de bord de suivi de la migration sont donc clés pour un bon
monitoring de toutes ces activités.
6. Aller un cran plus loin au niveau processus et organisation de la gouvernance
La migration de données démarre en même temps que le projet de digitalisation et se termine à la fin du basculement dans le nouveau système d’information. Elle a donc une date de début et une date de fin bien précises. Par contre, ce qui n’est pas toujours bien anticipé et qui fait pourtant partie de la gestion du changement, c’est l’impact que le nouveau modèle de données va avoir sur les processus et l’organisation de la gestion des Master data. En passant à un nouveau système d’information, souvent intégré, les processus doivent évoluer et les responsabilités associées également. En complément du service de coordination de la migration de données, GCP Consulting accompagne aussi ses clients en gestion du changement pour anticiper et faire adopter les nouveaux processus associés, voire définir la nouvelle organisation et s’assurer de son implémentation. Typiquement, cela peut inclure la mise en place d’un service central de gestion de Master data, avec des relais locaux pour certains champs spécifiques, et tout le flux de validation associé, avec un SLA (‘Service Level Agreemet’) pré-défini.
Nous devons bien l’avouer, il y a encore de nombreux facteurs-clés de succès à mettre en place et beaucoup d’erreurs à éviter pour garantir la réussite d’une migration de données, qu’on ne peut résumer dans un article de quelques pages. C’est pourquoi GCP Consulting a créé une formation sur la coordination de la migration de données, pour partager un condensé de son expérience en 3 demi-journées et former des chefs de projet, des responsables ‘migration’, des utilisateurs-clés, et d’autres profils impliqués sur des projets de digitalisation.
N’hésitez pas à consulter notre page GCP Academy et à nous contacter pour plus d’informations sur cette thématique toute aussi passionnante que critique.
Écrit par Christelle Ernotte
MANAGING DIRECTOR LUXEMBOURG, SPÉCIALISTE EN PROJETS DE TRANSFORMATION ET EN MIGRATION DE DONNÉES.
