Gestion des données de référence

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

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[1].

Enjeux de la gestion de données référentielles[modifier | modifier le code]

Les systèmes informatiques des grandes entreprises sont utilisés par différentes fonctions métier (par exemple le marketing, la recherche et développement, les ventes, les finances), à différents endroits, dans différents pays.

Ces systèmes divers ont besoin de partager des données référentielles (par exemple les produits, les clients ou les fournisseurs, le reporting financier pour les comptes consolidés, etc.). Il est donc critique pour une entreprise d'utiliser ces données référentielles d'une façon cohérente à travers chacun des systèmes informatiques.

Problème[modifier | modifier le code]

Modèle d'un système d'information sans MDM
Modèle d'un système d'information sans MDM

Dans de nombreuses organisations actuelles, les données référentielles sont dispersées dans le paysage applicatif comme l’illustre la figure ci-contre.

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 "rapportage" (reporting) , un sous-ensemble de l’entrepôt est extrait avec, par exemple les données financières et stockées dans un Datamart. Le "rapportage" 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é : 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[modifier | modifier le code]

Schéma applicatif de la solution[modifier | modifier le code]

Modèle d'un système d'information avec MDM
Modèle d'un système d'information avec MDM

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 figure ci-contre présente ce à quoi la GDR tend.

À 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[modifier | modifier le code]

Les risques présentés au paragraphe précédent 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.


Le diagramme ci-contre décrit l’architecture générique d’un système de gestion de données référentielles, composée de 6 blocs fonctionnels :

Modules d'une solution typique de MDM
Modules d'une solution typique de gestion de données référentielles
  1. 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.
  2. 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.
  3. 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)
  4. 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.
  5. 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.
  6. 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[modifier | modifier le code]

Gestion de données référentielles « Produit »[modifier | modifier le code]

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 »[modifier | modifier le code]

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 »[modifier | modifier le code]

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[modifier | modifier le code]

Comme le montrent les listes non-exhaustives ci-dessous, 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.

  • DataFlux qMDM[2]
  • EBX (Orchestra Networks) [3],[4]
  • FullTilt Solutions (QAD)
  • GENFI (Agena 3000)
  • Hybris
  • JDA Software (Enterprise architecture)
  • IBM InfoSphere MDM Server (IBM), dérivé en différents module en fonction des données de références[5]
  • Kalido MDM (Kalido)[6]
  • Informatica MDM[7]
  • MDM Framework (GXS)
  • One Data (SoftWare AG)
  • Purisma (D&B)
  • SAP Netweaver MDM (SAP)
  • Sun MDM Suite (Oracle)
  • TIBCO CIM (Tibco Software) [8]
  • WebSphere Product Center (IBM) [3]
  • Semarchy Convergence for MDM (Semarchy)[9]
  • SQL Server Master Data Services (Microsoft)[10]
  • BLUEWAY V5.5 (Blueway software) [11]
  • DataEXchanger X [12]
  • Talend Enterprise MDM (Talend) [13]
  • Datadecision (Datastem)[14]

Outils dédiés à un domaine particulier[modifier | modifier le code]

  • Oracle Hyperion Data Relationship Management ou Hyperion DRM (Oracle) - Finance
  • Oracle Product Data Hub (Oracle) - Produit
  • h'product manager (Heiler Software) - Produit
  • Oracle Customer Data Hub (Oracle) - Tiers

Notes et références[modifier | modifier le code]

  1. Systèmes d'information et développement durable, Hermès Science, p. 222-234
  2. http://www.dataflux.com/Products/qMDM.aspx
  3. a et b http://axelkamalak.eu/doc/mdm.pdf
  4. http://www.orchestranetworks.com
  5. http://www-01.ibm.com/software/data/master-data-management/
  6. http://www.kalido.com/master-data-management.htm
  7. http://www.informatica.com/fr/products_services/mdm/Pages/index.aspx
  8. http://www.tibco.com/products/soa/mdm/collaborative-information-manager/default.jsp
  9. http://www.semarchy.com/fr/convergence/
  10. http://www.microsoft.com/france/serveur-cloud/sql/2008R2/piliers-de-loffre.aspx
  11. www.blueway.fr
  12. www.dataexchanger.com
  13. http://www.talend.com/products/mdm
  14. http://www.datadecision.com

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Bibliographie[modifier | modifier le code]

  • « MDM - Enjeux et méthodes de la gestion des données » de Franck Régnier-Pécastaing, Michel Gabassi et Jacques Finet, Collection InfoPro - Management des Systèmes d'Information, éditions Dunod (2008).
  • « Data Management : qualité des données et compétitivité » de Christophe Brasseur, Collection Management et informatique, éditions Hermès Science - Lavoisier (2005).
  • Les apports de la méthode MDM dans la performance du SI des entreprises. - http://axelkamalak.eu/doc/mdm.pdf -