Qu'est que le MDM ?
Wikipedia pourra vous renseigner...
En résumé l'objectif du MDM, si dans un système d'information une entité (unité de sens, par exemple le client) est stockée dans plusieurs logiciels ou bases de données dont les informations arrivent dans chaque système avec des processus différents. Le MDM va être le lieu ou toutes ces informations vont être consolidées, identifiés et dont on va extraire un enregistrement de référence (en utilisant des règles), souvent appelé Golden Record, qui sera alors redistribué à tous les systèmes pour unifier la notion (le client) dans l'organisation.
Principe
Ici 3 sources de données sont poussées dans le MDM, pour chaque enregistrement il y a une mise en qualité (quatity gate) qui peut s'appuyer sur des règles, des données de références, une base de connaissances.
Puis l'enregistrement est intégré et rapproché par des règles à un cluster qui contient tous les enregistrements d'une même instance d'entité (ex : le client André Dupont).
A partir de tous les enregistrements du cluster d'une instance, un golden record est réalisé en faisant du picking par des règles sur les champs des enregistrements du cluster.
En théorie un cluster doit être composé d'un enregistrement par source, ou moins.
Si dans un cluster, 2 enregistrements de la même source se retrouvent regroupés alors il a un problème, cela demande une remédiation. Il est possible qu'un doublon soit présent dans une des bases, et cela peut nécessiter une intervention métier pour dédoublonner (ex: que faire des points de fidélité dans le CRM qui sont sur deux comptes alors que c'est la même personne ?), et cela montre qu'il a peut-être une amélioration a réalisé au niveau des processus de ce système.
C'est à ce niveau qu'intervient le workflow de remédiation et le rôle du Data Steaward, il est alerté d'un doublon et a pour objectif d'analyser l'origine du problème :
- règles de rapprochement à améliorer (les champs utilisés ne sont pas tous pertinants)
- mise en qualité trop intrusive (modification d'un prénom en utilisant la base de connaissance)
- problème de la base d'origine (doublon réel)
- ...
En suite il doit prendre des actions :
- Correction manuel du cluster et association avec un autre cluster ou création d'un cluster dédié
- Ne rien faire cela n'a pas d'impact métier
- Remonter le problème au responsable de l'application d'origine pour réaliser une intervention métier
- Modifier les règles de rapprochement
L'approche MDM est l'amélioration continue, on ne sait pas encore quelle donnée posera un problème mais le système est prêt à être amélioré, affiné lorsqu'un nouveau cas est rencontré.
Performance et volumétrie
Regroupant l'ensemble des données de l'organisation pour une unité de sens, stockant l'historique pour permettre l'analyse et retracer le comportement d'un cluster, le MDM va nécessiter une volumétrie beaucoup plus importante que les bases des systèmes métier l'alimentant.
Jouant pour chaque nouvelle enregistrement un ensemble de règles pour le rapprochement à un cluster puis réalisant un nouveau Golden record pour ce cluster (ce dernier est aussi stocké), l'ajout dans le MDM d'un enregistrement est coûteuse. Il est peu probable pour que cela puisse être réalisé en temps réel ou de façon synchrone. En consultation on peut avoir une performance correct mais l'utilisation de cache semble indispensable.
La rechercher dans le MDM peut-être coûteuse si on souhaite respecter la même logique que celle utilisé pour le rapprochement (mise en qualité et règle de rapprochement).
Mise en oeuvre
Une fois les unités de sens identifiés, elles représenteront les entités du modèle MDM. Chaque entité doit être sémantiquement indépendante les unes des autres, le modèle MDM n'est pas un modèle relationnel : une table du MDM contient l'intégralité de son sens, le sens d'une entité n'est pas le produits de plusieurs tables, il peut y avoir des relations entre les entités.
Exemple :
Nous souhaitons intégrer à un MDM une entité client, quid de l'adresse. Deux modélisations sont possibles :
- Le client doit avoir une adresse cela faire partie de son unité de sens et permet de le déterminer : une entité client
- L'adresse et le client sont indépendants mais il y a une relation possible entre les deux : une entité client et une entité adresse
Dans le cas 1 les champs de l'adresse (rue, code postal...) sont ajoutés au client, et permettent de différentier les clients aussi bien que le nom et le n° de téléphone. Le déménagement d'un client risque d'avoir pour conséquence la création d'un nouveau client si cela n'est pas spécifiquement géré côté métier.
Dans le cas 2 les champs de l'adresse ne peuvent être un discriminant pour distinguer les clients et l'entité Adresse contiendra un ensemble d'adresse dont l'objectif sera de fournir des adresses le plus juste possible indépendamment des clients. Le volume de données est aussi moins important.
Les 2 approches sont valides, tout dépendant des volumes et des objectifs du MDM. Si vous êtes un opérateur majeur de la grande consommation et que votre base client est très volumineuse et représente une part importante de la population alors le modèle 2 est plus adéquate car l'entité adresse aura une valeur ajoutée, vous arriverez à discriminer les adresses valides et invalide : un nom de rue rencontrée qu'un fois est suspect, vous aurez rapidement exhaustivité des nom de rue. Sur un ensemble plus restreint, comme sur une base client B2B, le modèle 1 sera plus pertinent.
