# Gestion des données de référence

La gestion des données de référence ou gestion des données maîtres (GDR, plus connue sous le vocable anglais de master data management ou MDM) est une branche des technologies de l'information qui définit un ensemble de concepts et de processus visant à définir, stocker, maintenir, distribuer et imposer une vue complète, fiable et à jour des données référentielles au sein d’un système d’information, indépendamment des canaux de communications, du secteur d'activité ou des subdivisions métiers ou géographiques.
Les données référentielles sous-tendent l’ensemble du système d’information, ce qui explique pourquoi leur gestion est devenue un enjeu crucial dans toutes les organisations depuis une dizaine d’années. Classiquement, trois types de données référentielles sont la cible de la GDR : les données « clients/fournisseurs », les données « produits » et les données « financières ».
La gestion des données de référence est considérée comme une brique de l'architecture d'un système d'information durable. Le Master Data Management est composé de PIM + DAM + CMS. Ainsi les données sont centralisées en un seul et unique fichier, autrement dit le référentiel unique (Single Source of Truth).

## Enjeux de la gestion de données référentielles

Les systèmes informatiques des organisations sont utilisés par différentes fonctions métier (par exemple, la fonction système d'informations, la fonction communiquant, la fonction marketing : produit, marque, client, packaging, etc, la r&d, ou encore la fonction commerciale). Ces systèmes divers partagent nécessairement des données de référence (telles que les données : produits, clients, fournisseurs, localisation, reporting financier pour les comptes consolidés, etc.).
Les enjeux de la gestion de données référentielles pour une organisation sont de cinq types :
* Sécuriser et rendre fiable ces données référentielles d'une façon cohérente à travers chacun de ses systèmes ;
* Optimiser l'efficacité opérationnelle des équipes communication, marketing, r&d et commerciale en mettant à disposition la donnée ;
* Conserver le contrôle de la qualité et l'homogénéité tout en offrant davantage de matériel et de données marketing ;
* Gérer de gros volumes et atteindre l'agilité à l'échelle industrielle ;
* S'inscrire dans un process de data qualité en gérant l'enrichissement de la donnée de façon collaborative grâce à des flux de validation.

## Problème

Dans de nombreuses organisations actuelles, les données référentielles sont dispersées dans le paysage applicatif, on parle alors de silos de données.
Les données référentielles sont encodées, stockées et gérées dans chacun des systèmes qui les utilisent. Les données opérationnelles dans chacune des applications clientes sont formatées au moyen de ces données référentielles avant d’être envoyées et centralisées dans un entrepôt de données (data warehouse). À des fins de rapport ou de tableau de bord (reporting ou dashboarding), un sous-ensemble de l’entrepôt est extrait avec, par exemple les données financières et stockées dans un Datamart. Le rapport proprement dit se fait sur le Datamart et non directement sur l’entrepôt de données pour des raisons de sécurité et de performance.
Cette situation présente les risques suivants :
* Coût de maintenance et effort opérationnel importants : les données référentielles doivent être maintenues séparément dans une multitude d’applications distinctes, ce qui nécessite du temps et requiert des encodages multiples d’une même information.
* Risque d’incohérence : la multiplicité des définitions et des versions induit un risque d’incohérence entre les différents systèmes puisqu’un changement dans un système n’est pas automatiquement répercuté dans les autres. Ceci pose aussi la question de la préservation de l'intégrité des données.
* Faible contrôle des données : comme les données référentielles existent en de multiples endroits sous de multiples formes, aucun système ne peut revendiquer la propriété d’une donnée référentielle (qui en est le maître ?). De ce fait, il n’y a pas de véritable contrôle sur quel système utilise quelles données référentielles et avec quels privilèges.
* Absence d’unicité et de cohérence : lorsque deux applications utilisent des versions différentes de la même donnée référentielle, il est impossible de déterminer quelle version est la bonne; il est souvent fait référence à ce principe dans la littérature sous le terme « single version of the truth ».

## Solution type
### Schéma applicatif de la solution

La GDR vise donc à améliorer de façon durable la qualité, la maintenabilité et l’accessibilité des données référentielles à tous les niveaux de l’organisation.
À la différence de l’architecture précédente, les données référentielles ne sont plus maintenues qu’à un seul endroit et distribuées régulièrement aux applications clientes en fonction de la fréquence nécessaire ; (dans le cas de l'exemple, la fréquence de la mise à jour est hebdomadaire, la fréquence dépend du type d'application considéré).
Cette architecture présente également la particularité de mettre en place une relation « maître-esclave » avec un « push » vers les clients ; une relation pull ou push-pull est tout aussi envisageable.

### Implémentation de la solution

Les risques présentés peuvent être circonscrits en implémentant un système central de gestion de données référentielles. De ce fait :
* Les données référentielles sont encodées et maintenues en un seul endroit, ce qui diminue le coût opérationnel lié à la maintenance et à l’encodage.
* Le système est le maître des données. Il les contrôle en sélectionnant quelles données il transmet à quel système.
* Le système contient une seule version active (il peut exister plusieurs versions inactives, tant passées que futures ; c’est même recommandé pour une meilleure flexibilité de la solution). Il est donc le garant de la seule version de la vérité et en cas de litige, sa version tient lieu de version officielle.
L’architecture générique d’un système de gestion de données référentielles est composée de 6 blocs fonctionnels :
* La gestion du cycle de vie (data lifecycle) qui définit et implémente tous les processus, les rôles et les responsabilités liés à un changement dans la solution. Exemples : processus de création d’une nouvelle donnée référentielle, modification des droits d’un utilisateur, etc. Ces processus font à la fois intervenir des acteurs, leurs responsabilités et les composants logiques de la solution touchés par la modification.
* L’administration, qui se charge de la gestion de la solution au moyen de droits et privilèges accordés aux différents acteurs. Exemples : définition d’un administrateur « business », d’un administrateur « IT » et d’utilisateurs, avec pour chacun quelles sont ses prérogatives.
* Le stockage concerne le stockage physique des données référentielles ainsi que leurs relations internes (entre deux données référentielles d’un même type) et externes (avec des données référentielles d’autre type).
* La gestion des métadonnées s’occupe de toutes les données à propos des données référentielles (métadonnées) et définit quels types de métadonnées sont considérés (information absolue ou par « delta », historique, définitions, etc.).
* La gestion de l’accès aux données concerne non seulement la manière dont les données référentielles sont mises à la disposition des systèmes « clients » mais aussi la manière dont les données référentielles sont capturées. C’est dans ce composant que sont définis les types d’interfaces entrée-sortie (utilisateur, programme, online ou par lot, etc.), les débits, les fréquences, la politique de réception/distribution (push, pull, push-and-pull), etc.
* Les règles directrices (data guidelines) : elles assurent la conformité du système avec les règles générales, les standards, l’horizon d’application et la stratégie définie autour du système. Exemples de lignes directrices : le système ne peut stocker que des données financières, les données manipulées appartiennent uniquement au département Finance, pour chaque donnée référentielle, un propriétaire doit être défini, etc. Ces règles sont implémentées dans l’outil en définissant des règles logiques qui sont exécutées par des routines (ex : définir des champs obligatoires et prévoir des messages d’erreurs s’ils ne sont pas remplis, requérir une validation par un responsable avant de sauver les données, etc.).

## Principaux domaines d'application
### Gestion de données référentielles « Produit »

La GDR dans la gestion des produits (produit, articles, fiches techniques...) permet de centraliser au sein d'un référentiel les données intervenant dans les processus de référencement (grande distribution) et de développement de produit (industrie).
Le principal problème concerne la gestion collaborative d'enrichissement, puisqu’il s'agira de coordonner la complétion de la fiche produit par différents intervenants et différents métiers avant consommation (intégration avec un système PLM, diffusion à des partenaires externes...)

### Gestion de données référentielles « Tiers »

La GDR dans la gestion de tiers (clients, fournisseurs, consommateurs, employés, etc.) intervient pour consolider différents canaux d'acquisition d'informations relatives à des personnes physiques et/ou morales.
La principale problématique concerne la consolidation, et par conséquent la capacité de rapprochement d'informations provenant de sources diverses, leur enrichissement et le contrôle de leur validité (cohérence avec le monde réel pour une adresse), avant mise à disposition d'applications de type gestion de la relation client, logistique ou comptable.

### Gestion de données référentielles « Finance »

Les données financières sont utilisées dans deux optiques :
* l'établissement des comptes annuels et consolidés, ceci afin de s'acquitter de ses obligations légales envers l'état et les instances légales (ex: le calcul de l'impôt des sociétés est calculé sur base des résultats déclarés dans les comptes annuels), envers les actionnaires existants et potentiels (les comptes représentent une source d'information primordiale dans une décision d'achat/vente d'actions) et envers la maison-mère dans le cas d'une filiale (consolidation au niveau du groupe).
* l'établissement de rapports de gestion, afin d'aider les instances dirigeantes à mesurer les effets de leurs décisions et les performances, à leur fournir les informations nécessaires pour le développement d'une stratégie et d'un plan d'action, à identifier les faiblesses et les forces de l'organisation...
Étant donné que les données référentielles « Finance » organisent et soutiennent les données financières, l'on comprend aisément l'importance d'un système de GDR dans toute société, en particulier dans les institutions financières. Les données référentielles financières se présentent souvent sous la forme de hiérarchies (ex : plan comptable) ; pour cette raison, certains outils se sont spécialisés dans la gestion des données référentielles financières en proposant un modèle hiérarchique plutôt qu'un modèle de données classique. C'est le cas par exemple de la solution Hyperion DRM d'Oracle.

## Offre

L'offre est importante et variée. Certains fournisseurs proposent d'ailleurs plusieurs solutions identiques pour répondre à la même problématique. Cette situation est due à la consolidation du marché qui a lieu depuis quelques années et qui se marque par des rachats en grand nombre. Des projets de grande envergure sont mis en place chez chacun des grands acteurs afin de rationaliser et de consolider l'offre de solutions.
Ci-dessous, une liste non exhaustive de solutions sur le marché :
* Informatica MDM Saas
* Stibo Systems STEP
* Semarchy xDM Data Management
* Galilée Master Data Management
* IBM Infosphere MDM
* Oracle Data Relationship Management
* Orchestra Networks EBX devenu Tibco EBX