Kézako MDM, épisode 4 : les erreurs à éviter sur un projet MDM
Épisode 4 de la série vidéo Kézako MDM : qualité des données, positionnement du Data Hub, format pivot, supervision, périmètre, équipes et expertise.
En résumé : un projet MDM échoue rarement pour une raison technique isolée. Les erreurs les plus fréquentes sont de surévaluer la qualité des données, de placer le Data Hub sur le chemin critique du système d'information, d'oublier le format pivot et la supervision, de choisir un périmètre initial trop large, de ne pas impliquer toutes les équipes dès le pré-cadrage et de manquer d'expertise au démarrage. Stéphan Verdier, Directeur du Pôle Data Management de Kwanzeo, les passe en revue dans ce quatrième épisode de la série Kézako MDM.
Transcription de la vidéo
Bonjour à tous et bienvenue pour ce quatrième épisode de Kézako.data. Je me présente : Stéphan Verdier, Directeur du Pôle Data Management de Kwanzeo. Aujourd'hui, je vais vous parler des erreurs à éviter sur un projet Master Data Management.
Après un rappel de l'épisode 3 sur le Master Data Management, nous aborderons les points suivants : la qualité des données, le positionnement du MDM, le format pivot dans les échanges, la supervision, le périmètre initial du projet, la définition du projet et ses participants, et le manque d'expertise.
Rappel : le Master Data Management
Un MDM centralise toutes les données de référence en un point unique, le Golden Record. Il propose des processus de standardisation, de normalisation, de consolidation, de nettoyage des doublons, de propagation et de traçage des données de référence, ainsi que des outils de reporting, de découverte de la donnée et d'exposition de services de création, de modification et de consultation des données.
Son objectif est de centraliser, standardiser, réconcilier et publier une information qui correspond au business de l'entreprise, de simplifier la prise de décision côté métier comme côté IT, et d'enrichir l'information grâce à un processus de certification défini par le métier. L'Intelligent Data Hub est le nouveau terme pour parler du Master Data Management. Les notions de base sont détaillées dans l'épisode 1.
Erreur n° 1 : surévaluer la qualité des données
Attention à ne pas surévaluer le niveau de qualité des données des applications avant la mise en place d'un Data Hub. La phase de vérification et de profilage de la donnée est nécessaire pour bien appréhender les enjeux et les objectifs d'un projet MDM.
La préparation et le recensement des données prennent du temps, selon l'état des données et le nombre d'applications du système d'information. Certains éditeurs proposent un module « Discovery » qui vérifie la qualité de la donnée en l'injectant dans des tables : il fait gagner beaucoup de temps et centralise toutes les informations. À défaut, des outils de Business Intelligence ou de gouvernance des données peuvent répondre à ce besoin.
Cette étape de préparation, de recensement et de profilage des données de référence peut prendre quelques semaines, voire quelques mois. C'est un chantier à mener en parallèle d'autres sujets, mais à prendre en compte dès le démarrage, pour ne pas rater la date de mise en production du MDM.
Erreur n° 2 : mal positionner le MDM
Attention à ne pas placer le Data Hub sur le chemin critique du projet de restructuration ou d'amélioration du système d'information.
Dans un premier temps, le MDM doit être placé en mode esclave : il n'échange pas les informations en temps réel. C'est une architecture de consolidation, avec un couplage lâche (asynchrone). Les applications continuent d'échanger entre elles sans que le référentiel n'entrave leurs échanges :
- les informations transitent des applications vers le Data Hub grâce à des ETL, par batch ;
- c'est un traitement asynchrone, qui peut être déclenché plusieurs fois par jour ;
- les données ne transitent pas du Data Hub vers les autres applications, ce qui laisse un déphasage entre applications, mais n'entrave pas les échanges existants.
Un projet MDM est complexe, prend du temps et peut mettre en péril d'autres chantiers du système d'information : les échanges interdépendants avec le MDM demandent donc une attention particulière en matière d'architecture.
Lorsque le projet est bien avancé, on passe à une architecture transactionnelle. Les applications n'échangent plus directement entre elles : une plateforme d'échange de type ESB offre des services et réalise les échanges avec le Data Hub, qui diffuse les informations de référence certifiées. Cela évite les échanges en point à point et donne à toutes les applications le même niveau d'information. C'est une architecture orientée service. Pour plus de détails, regardez l'épisode 2 consacré aux architectures autour du MDM.
Erreur n° 3 : oublier le format pivot dans les échanges
L'absence de format pivot dans les échanges inter-applicatifs liés à un Data Hub est une source chronophage d'erreurs et de problèmes d'interprétation de la donnée. Le format pivot doit être pensé dès le début des échanges, au moment même de la modélisation de la plateforme d'échange.
En début de projet, les échanges doivent se faire via un ETL, pour garder un couplage lâche. Le format pivot prépare le passage de l'architecture de consolidation à l'architecture transactionnelle : il sera utilisé par la plateforme d'échange pour exposer les services consommés par le Data Hub et les applications. Au fil du projet, la plateforme proposera des API en temps réel (architecture transactionnelle, orientée service), pour finir sur une architecture centralisée (orientée utilisateur).
Conservez le fonctionnement par ETL même après la mise en production : il sert de secours si la plateforme d'échange en temps réel tombe, ou pour les mises à jour en masse, comme l'intégration d'une nouvelle application dans le MDM.
Pour résumer :
- Échanger via un ETL.
- Démarrer le développement de la plateforme d'échange en temps réel et publier les API de consultation des données du MDM, en mettant en place les premiers éléments de supervision.
- Faire appeler ces API de consultation par les applications qui interagissent avec le MDM, avant qu'elles ne créent des informations.
Erreur n° 4 : repousser la supervision à la fin du projet
En parallèle de la plateforme d'échange, la supervision des échanges doit débuter, avec des métriques et des KPI. Elle fait gagner beaucoup de temps, donne de la visibilité sur l'avancement du projet et fournit des données chiffrées à la direction ou au sponsor.
Cette étape est bien trop souvent réalisée en fin de projet : ce n'est pas ce qu'attendent les sponsors à ce moment-là. La supervision des données doit couvrir :
- les applications sources ;
- les applications cibles ;
- la plateforme d'échange ;
- le Data Hub.
Attention à ne pas sous-estimer les délais de mise en place de cette étape.
Erreur n° 5 : un périmètre initial trop large
Un périmètre de récupération des données trop large fait souvent dériver les délais. Les risques sont les suivants :
- une analyse des informations trop longue ;
- une maintenance corrective qui s'accroît ;
- des problèmes de performance au sein du système d'information ;
- pas de retour d'expérience sur la faisabilité et les problèmes rencontrés ;
- l'insatisfaction des utilisateurs, du sponsor et de la direction ;
- un décalage de la livraison du projet ;
- des équipes plus importantes, puisqu'il y a plus à faire.
Un périmètre restreint permet de gagner en maturité sur tous les volets du projet et d'obtenir des retours d'expérience bien plus utiles pour la suite.
Erreur n° 6 : mal définir le projet et ses participants
L'ensemble des équipes doit travailler conjointement, du pré-cadrage à la mise en production. Le pré-cadrage du besoin est important : il permet de savoir ce qui va être réalisé et ce qui est faisable, d'interroger les différents éditeurs et d'entrevoir les coûts (humains, éditeur, infrastructure…). Au minimum un représentant de chaque équipe doit y participer.
Une fois le besoin exprimé, clairement identifié et réalisable, chaque membre du projet doit être acteur de :
- la participation au cadrage, au kick-off et au dimensionnement des équipes ;
- la constitution et l'estimation du backlog ;
- la mise en place des cérémonies et des réunions ;
- la désignation des représentants aux réunions ;
- le choix du périmètre et du MVP ;
- la définition des premiers jalons ;
- la mise en ordre de marche des équipes.
Les équipes souvent oubliées en début de projet sont les équipes infrastructure et exploitation. Impliquez-les dès le démarrage pour éviter une surcharge de travail en fin de projet : après la mise en production, ce sont elles qui feront tourner le système. Les documents nécessaires au bon fonctionnement de la solution viendront en partie des équipes de développement et des métiers.
Erreur n° 7 : manquer d'expertise
Sur les projets MDM, l'expertise est capitale en début de projet : des experts MDM feront gagner un temps considérable par rapport à des profils juniors. Au fil du projet, le besoin diminue : les experts sont progressivement relayés par des profils juniors et se consacrent au suivi et à la vérification des bonnes pratiques.
N'oubliez pas la montée en compétence des équipes internes, qui prend un temps non négligeable : faites appel à l'éditeur sur ce point. Pour éviter les problèmes techniques, un forfait de jours d'expertise auprès de l'éditeur est conseillé.
Dans le prochain épisode : la roadmap d'un projet MDM.
Pour aller plus loin
Vous souhaitez mettre en place une solution de Master Data Management ou améliorer la gestion de vos données de référence ? Les experts Kwanzeo peuvent travailler avec vos équipes pour concrétiser votre projet, enrichir votre gouvernance des données et renforcer vos équipes.
Questions fréquentes
Quelle est l'erreur la plus fréquente sur la qualité des données d'un projet MDM ?
Surévaluer le niveau de qualité des données avant la mise en place du Data Hub. La préparation, le recensement et le profilage des données de référence peuvent prendre quelques semaines, voire quelques mois : c'est un chantier à prendre en compte dès le démarrage.
Pourquoi utiliser un format pivot dans les échanges avec un MDM ?
L'absence de format pivot dans les échanges inter-applicatifs avec un Data Hub est une source chronophage d'erreurs et de problèmes d'interprétation de la donnée. Pensé dès la modélisation de la plateforme d'échange, il prépare le passage de l'architecture de consolidation à l'architecture transactionnelle.
Quel périmètre choisir pour démarrer un projet MDM ?
Un périmètre restreint. Un périmètre trop large fait souvent dériver les délais : analyse trop longue, maintenance corrective accrue, problèmes de performance, absence de retour d'expérience et insatisfaction des utilisateurs comme du sponsor.
