Gartner : mythes et réalité du MDM

Le MDM (Master Data Management) est un concept en vogue depuis quelques années et, comme tout ce qui est à la mode, est facilement détourné et souvent mal compris. Pour tenter de recentrer les débats, Gartner liste 10 mythes classiques sur le sujet et rétablit ainsi, en "négatif", la "vérité".

Le MDM a pour objectif de résoudre le (vieux) problème des données incohérentes, dupliquées dans différents systèmes, disséminées dans l'entreprise et, finalement, de mauvaise qualité. Vous reconnaissez des situations vécues ? La solution proposée est une "discipline", supportée par des technologies, qui va viser à garantir l'uniformité, l'exactitude, la cohérence sémantique et le "pilotage" des données critiques, partagées à travers l'organisation (les données "maîtresses" ou "master data"). Bien appliquée, elle permet d'améliorer l'agilité et la performance des processus métier.

Mythe n°1 : le MDM est une technologie. La technologie n'intervient qu'en support de l'approche, qui doit se concentrer sur la compréhension des processus métier, de leur fonctionnement et de l'utilisation qu'ils font des données "maîtresses".

Mythe n°2 : le MDM est un projet. En réalité, il s'agira d'un programme à long terme, qui doit transformer en profondeur les méthodes de gestion et d'utilisation des données par les "métiers". Naturellement, ce programme stratégique sera jalonné par une succession de projets.

Mythe n°3 : je n'ai pas besoin de MDM, j'ai un datawarehouse. Votre datawarehouse héberge-t-il une version unique des données utilisées dans toute l'organisation et tous les processus, analytiques et opérationnels ? Probablement pas (et si c'est tout de même le cas, il s'agit d'un contre-emploi du datawarehouse, qui comporte ses propres dangers).

Mythe n°4 : je n'ai pas besoin de MDM, j'utilise un ERP. Votre solution progicielle couvre-t-elle tous les métiers et tous les processus de l'entreprise ? La promesse initiale était peut-être celle-là mais vous avez probablement du ajouter de nouveaux composants dans votre SI par la suite, n'est-ce pas ?

Mythe n°5 : le MDM, c'est pour les grandes entreprises. Dès que vous avez deux processus utilisant des données ("maîtresses") communes, vous risquez d'être confronté aux risques d'hétérogénéité. Que vous l'appeliez ainsi ou pas, que vous utilisiez une solution spécialisée ou non, vous allez "faire" du MDM.

Mythe n°6 : les métadonnées sont la clé du MDM. Les métadonnées, qui définissent (et décrivent) les types de données maîtresses de l'entreprise, sont certes importantes mais leur mise en oeuvre dépend fortement de leur domaine, de leurs modes d'utilisation... La vérité n'est pas unique !

Mythe n°7 : le MDM est un sujet par la DSI. Au contraire ! Ce sont bien le métier et les cas d'utilisation business qui doivent guider la mise en place. La DSI ne doit être qu'un facilitateur et un fournisseur de conseil et de support.

Mythe n°8 : le MDM est un chantier trop vaste. Pris dans son ensemble, le travail à réaliser paraitra effectivement insurmontable. Mais il peut "facilement" être entrepris par étapes, un domaine après l'autre, progressivement.

Mythe n°9 : le MDM, ce n'est pas la gouvernance ni la gestion de la qualité des données. Gouvernance et qualité des données maîtresses sont des composantes essentielles d'un programme de MDM. On pourrait même pousser le raisonnement jusqu'à dire que ces deux sujets définissent le MDM, l'implémentation technologique n'étant qu'un élément de "confort".

Mythe n°10 : toutes les offres sont identiques. Les fournisseurs ont tous des spécialités, par domaine, par industrie, par style d'implémentation... et une sélection avisée doit être réalisée pour trouver la solution la plus adaptée à un contexte donné.

Bien que Gartner ne le place qu'en septième position, j'estime que le point le plus important de cette liste est bien que le MDM n'est pas un projet de DSI, ce qui est logique puisque ce n'est pas une technologie ! Les données, même si elles sont gérées par l'informatique, appartiennent aux utilisateurs "métier", qui sont les premiers concernés par les problèmes qui les affectent et qui doivent donc piloter les solutions à mettre en place. Comme pour beaucoup de "nouveaux" concepts (par exemple, SOA, "Service Oriented Architecture"), c'est en oubliant ce point de vue que de nombreux projets se terminent par des échecs cuisants.