C'est un sujet qui revient souvent, aussi je réponds de façon globale à tous ceux qui m'ont demandé des retours d'expérience.

Tout d'abord c'est un aspect très important à ne pas négliger car constituer un référentiel à partir de données non fiables va aller à l'encontre du but recherché par les référentiels. En effet on va globalement baisser la qualité du SI car toutes les applications vont partager des informations erronées alors que lorsqu’une application avaient des données erronées elle ne polluait pas les autres.

Mes expériences de direction de mise en place de MDM, m’ont permis affiner une démarche qui fonctionne.
Elle consiste en 3 points fondamentaux :

1. Choisir parmi les sources disponibles celle qui est de meilleure qualité (c’est souvent une question de confiance : par exemple une application de demande de crédit va vérifier les informations client de façon très précises, alors que l’application de service après vente acceptera n’importe quelle adresse). Bien souvent il y a une application cœur métier ou un progiciel où l’on trouvera la bonne source car les deux avaient mis en place un certain nombre de contrôles de leurs données.

2. Réaliser une extraction des différentes sources et détecter les doublons, il faut aussi bien définir ce que l’on appelle un doublon (en général sur une partie seule des données et non la totalité). On peut automatiser un ensemble de traitement, mais il restera une phase manuelle où les MOA devront sélectionner les bonnes données. On aura alors un fichier exhaustif et correct des données à importer.

3. Il faut également dans l’outil de MDM bien définir tous les contrôles que l’on veut voir appliquer chaque fois que l’on crée ou modifie des données. Ces contrôles doivent s’appliquer lors de l’initialisation du référentiel avec le fichier sensé correct. Les rejets devront être traités par les MOA.

Ces points sont bien sûr, une trame à adapter aux impératifs de l’entreprise. Par exemple, lors de la mise en place d’un référentiel Produits pour Arpège (regroupement de Caisses d’Epargne), ce travail a été fait sur une Caisse puis rapproché avec les 13 autres Caisses ce qui a permis de constituer un référentiel Groupe, puis chaque Caisse en hérite et peut en surcharger certaines parties et donc disposer de son propre référentiel dérivé de celui du Groupe.

Enfin, les référentiels pour les développements, les tests, la qualification et recette, sont obtenus par extraction de sous ensemble du référentiel de production et ajout de cas d’erreurs pour permettre aussi de tester le comportement des applications en cas d’erreur.
Dernier point mis en œuvre, une extraction régulière des données en production et une comparaison avec le référentiel permet de vérifier qu’il n’y a pas de divergence. On ne peut pas toujours empêcher un développeur, lors d’une maintenance à chaud, de modifier directement une donnée dans un progiciel ou une base sans passer par l’interface de l’outil de MDM.
jeudi 16 avril 2009