Quels sont les principaux risques d’un projet en Master Data Management (MDM) ?

Il faudrait peut-être rédiger un jour un dictionnaire des termes vagues de l’IT. Le MDM, ou Master Data Management, y figurerait vraisemblablement en bonne place tant le concept semble élastique, surtout dans les mains des éditeurs habiles à forger des pseudo-concepts spécialement concoctés pour vanter les mérites de leur solution. Si les termes sont parfois vagues, les problèmes liés au manque d’harmonisation des données sont en revanche bien réels.
Un seul chiffre donne le vertige : 611 milliards de dollars. C’est le coût engendré par des données de mauvaise qualité, supporté chaque année par les entreprises américaines   Certes, d’un point de vue conceptuel le problème de l’harmonisation et de l’intégrité des données n’est pas nouveau. Il remonte à l’invention des premières bases de données relationnelles il y a maintenant plus de 40 ans. Cependant, l’ouverture progressive des systèmes d’information et la multiplication des opérations de fusion-acquisition depuis une dizaine d’années ont rendu ce problème d’harmonisation de plus en plus aigu, au point de menacer parfois la pérennité même d’un SI.
Convenons d’appeler MDM l’ensemble des processus et des outils qui permettent d’harmoniser la définition de données métiers partagées entre plusieurs applications. En d’autres termes, l’objectif d’une démarche MDM est de constituer, pour un jeu limité de données métiers, un référentiel pérenne qui fera office de point de vérité unique pour toutes les applications du SI. Par données maîtresses ou référentielles on entend le plus souvent des entités métiers dont le cycle de mise à jour est relativement lent par rapport à celui des données transactionnelles. Les produits, les données financières et les tiers d’une entreprise sont les catégories les plus communes.
Notre contribution pour dissiper les brumes tenaces autour du sigle MDM se résumera en trois questions simples qui synthétisent l’expérience de SQLI sur des projets de type MDM. 

Existe-t-il une démarche standard pour un projet MDM ?

Dans les grandes lignes chaque projet de type MDM se subdivise en quatre phases :

1. Un état des lieux durant lequel on modélise les données, les processus et les flux existants.
2. Une définition de la gouvernance des données. C’est là que réside le gros du travail. Il s’agit d’une part d’établir un ensemble de définitions partagées pour les données métiers qui feront partie du référentiel. Le travail d’harmonisation se fera au cas par cas, il n’existe pas à notre connaissance d’algorithme infaillible qui permettrait de définir à coup sûr un modèle cohérent et utile. D’autre part, il s’agit de désigner les responsables du cycle de vie des données, une tâche souvent délicate car liée à des enjeux éminemment politiques.
3. La mise en œuvre correspond au projet IT de migration des données, à l’évolution des systèmes existants et à la mise en place de la solution MDM. Il s’agit en réalité d’un projet IT classique d’harmonisation de données.
4. Une phase d’adaptation continue durant laquelle les données sont contrôlées et corrigées au quotidien.

Hormis ces quatre phases, chaque projet MDM est spécifique.

Quelles sont les principaux risques d’un projet MDM ?

Selon notre expérience les erreurs récurrentes dans les projets MDM sont liées pour l’essentiel à la sous-estimation du temps et de l’énergie nécessaires à certaines tâches.

1. La première erreur est de sous-estimer le temps nécessaire pour dresser une cartographie fiable de l’existant. En effet, le plus souvent les définitions des données sont à la fois disséminées dans plusieurs unités, pas forcément habituées à collaborer, et entachées de contradictions sémantiques dont il faut prendre note avant d’entamer le travail d’harmonisation proprement dit.
2. La seconde erreur est sans doute la plus grave et aussi, hélas, la plus fréquente. Elle consiste à considérer un projet de MDM comme un projet IT classique et à négliger l’essentiel qui est la mise en place d’une solide gouvernance des données. Celle-ci devra attribuer des droits et des responsabilités pour la définition et la mise à jour des données maîtresses. C’est à ce stade qu’il faudra en particulier aplanir tous les différents politiques.
3. Enfin, la dernière erreur est de voir trop grand.  La complexité combinatoire de la tâche d’harmonisation de quelques dizaines d’entités métiers, avec leurs attributs et leurs associations, peut rapidement s’avérer colossale. Il convient donc de se restreindre à un ensemble d’entités métiers dont l’harmonisation sera directement porteuse de valeur ajoutée pour les métiers.

Pour juguler ces risques se pose alors la dernière question : 

Comment organiser un projet MDM ?

Comme tout projet d’intégration significatif, le MDM est avant tout un projet transverse à l’entreprise. La direction en particulier devra sponsoriser le projet et, le cas échéant, intervenir pour aplanir les tensions liées à la possession des données et pour trancher les décisions sur lesquelles aucun consensus n’émerge.

Enfin, n’oublions jamais la célèbre loi de Conway  qui affirme que toute organisation reproduit, dans les systèmes qu’elle conçoit, ses propres structures de communication. Que l’on pourrait reformuler en disant que les machines communiquent plus aisément, ce qui est bien l’objectif du MDM, lorsque les être humains font de même. Hélas, chacun le sait, aucun algorithme fiable pour cette tâche n’a encore été découvert.

Article paru sur le JDN.