Fiche Concept MDM (Master Data Management)

Transcription

FICHE CONCEPT 05
MDM (MASTER DATA MANAGEMENT)
BIEN GERER SES REFERENTIELS DE DONNEES : UN ENJEU
POUR MIEUX PILOTER LA PERFORMANCE DE SON
ETABLISSEMENT
Version 1.0 octobre 2008
GMSIH – 44, Rue de Cambronne – 75015 Paris. Tel : 01 48 56 72 70. Fax : 01 48 56 07 70
Fiche concept 05 :MDM (Master Data Management)
Projet : Bien gérer ses référentiels de données : un
enjeu pour mieux piloter la performance de son
établissement
Version 1.0
Copyright © 2008 GMSIH
Permission vous est donnée de copier et distribuer ce document selon les termes de la
Licence D-GMSIH, Version 2.0 ou ultérieure publiée par le GMSIH.
Une copie de cette licence peut être consultée à l’adresse :
http://www.gmsih.fr/fre/nos_publications/licences_gmsih
Versions du document :
Date
Version
Octobre 2008
1.0
08/10/08
Commentaires
Publication de l’étude
2/12
Statut
Validé
P132_FConcept05_MDM_V1.0
Fiche concept 05 :MDM (Master Data Management)
établissement
Version 1.0
Sommaire
1.
Description du concept et des outils associés .........................................................................5
1.1
Préambule : ..............................................................................................................................5
1.2
Principe : ..................................................................................................................................5
1.3
Architecture : ...........................................................................................................................5
1.4
Choix d'un outil de MDM ........................................................................................................7
1.5
Positionnement des solutions de MDM dans le SIH ...........................................................9
2.
Principaux enjeux pour les établissements de santé ............................................................ 10
3.
Mise en œuvre ........................................................................................................................... 11
3.1
fixer le périmètre : ................................................................................................................ 11
3.2
Les phases d’un projet de MDM ......................................................................................... 11
Liste des Figures
Figure 1 : Faire du MDM sans solution MDM .......................................................................................... 7
Figure 2 : Positionnement des solutions de MDM dans le SIH ............................................................... 9
08/10/08
3/12
Projet : P132 – Référentiels SID dans les ES
Fiche concept 05 : MDM (Master Data Management)
Version 1.0
Définition
Fonctionnalités et outils associés
Master Data signifie Données de référence. Il s'agit des données indispensables
au fonctionnement d'une entité (entreprise, établissement de santé, etc.).
MDM (Master Data Management) ou GDR en français (Gestion des Données de
Références) est une méthode de gestion des données et est devenu, par
extension, le nom donné aux solutions s'appuyant sur cette méthode.
Le MDM désigne à la fois une base de stockage de données maîtres et les outils
de leur gestion. Dans les applications les plus courantes, ces données maîtres
sont de nature référentielle. La base de stockage autorise des fonctions de
recherche et d'étude d'impact.
La gestion MDM couvre les fonctions batch d’import (traitements de contrôle de
cohérence, de fusion de données, de calcul des clefs inverses, d’alimentation et
d’entreposage des données), et d’export (restitution sélective, mapping en sortie,
mise au format, abonnement à une ou un ensemble de donnée(s)).
Elle couvre les fonctions interactives d’administration de la base, et de
paramétrage des règles d’alimentation, d'export, de rapprochement et de fusion
de données).
Elle propose une fonction de workflow qui permet de traiter les données dans
l’ordre et selon les conditions d’un processus de gestion logique à définir selon le
besoin.
Schéma explicatif : Composition d’un système MDM (Source : Forrester research, Inc.)
EII : Entreprise Information Integration
CDI : Customer Data Integration
PIM : Personal Information Management
CDC : Change Data Capture
Exemples d’outils du marché
Etat des lieux (2008)
 Souvent rencontré en établissement de santé
Les éditeurs généralistes reconnus : SAP (solution Netweaver MDM), Oracle
(solution Active Data Hub), Oracle (Hyérion Data relationship management), IBM
(MDM Server 8.0), Microsoft Microsoft MDM (Stratature +EDM), I2 (Solution I2
master Data Management), Teradata (Top master data management),
 Parfois rencontré en établissement de santé
 Rare en établissement de santé
Des solutions spécialisées en développement : Orchestra Networks (Offre EBX
Platform 4.4.0), Siperian (Siperian MDM Hub), Kalido (Offre Kalido 8M), Amalto
(Offre Xtentis), ObjectRiver (ObjectRiver MDM. 4.0), Dataflux (MDM CDI)
08/10/08
4/12
établissement
Version 1.0
1. DESCRIPTION DU CONCEPT ET DES OUTILS ASSOCIES
1.1 PREAMBULE :
La prolifération et l’imbrication croissantes de systèmes hétérogènes supportant les activités métier et
de gestion au sein des SIH ont fait émerger le besoin d’une base centralisée, dépositaire d’une
information fiable pour tous et disponible pour tous. De nouvelles solutions technologiques permettent
de répondre à ce besoin. Ce sont les solutions de MDM (Master Data Management).
1.2 PRINCIPE :
On distingue plusieurs types d'utilisation du MDM:
MDM Opérationnel (O-MDM) : définition, distribution, synchronisation et échange de données de
référence dans une architecture SOA, en vue de garantir la cohérence des données entre
différentes applications opérationnelles.
Application possible en ES : enregistrement d'un patient au moment de son arrivée dans
l’établissement de santé. Les différentes applications, étant informées de cette nouvelle venue, ne
créent pas de doublon.
MDM Analytique (A-MDM) : construction de relations entre données de référence (construction
de dimensions, segments, hiérarchies) en vue de leur exploitation analytique. Les données ainsi
structurées permettent d'alimenter les processus décisionnels de l'entreprise pour agrégation et
analyse.
Application possible en ES : rapprochement de données économiques et financières ou encore
rapprochement de données de ressources humaines et données d’activité par exemple.
MDM Collaboratif (C-MDM) : création ou modification de données de référence par différents
acteurs de l'entreprise en vue de conserver en un seul lieu la source de vérité de la donnée de
référence tout en garantissant son accès par les différentes applications.
Application possible en ES : enrichissement du dossier patient via différentes applications
(imagerie médicale, prescription médicamenteuse…), par exemple.
En général, le MDM est utilisé pour une combinaison de toutes ou parties de ces 3 approches avec,
par exemple, l'émergence du décisionnel en temps réel.
1.3 ARCHITECTURE :
1.3.1.1 Pourquoi associe-t-on SOA et MDM ?
Une architecture orientée services (SOA pour "Service Oriented Architecture") est, par essence,
répartie et décentralisée afin de garantir une souplesse de construction du SI dont on sait
pertinemment qu'il sera constitué de multiples applications. Aussi devient-il prépondérant de placer
l'information au cœur du SI en centralisant les données. Mais cela reste vrai sans solution de MDM.
C'est la gestion des données de référence et la notion même de référentiel, davantage que les outils
qui en découlent, qui sont associées au SOA.
Le MDM est, à ce jour, une des méthodes les plus représentées – et donc outillée – ce qui explique
cette association.
08/10/08
5/12
établissement
Version 1.0
1.3.1.2 Niveau d'intégration d'un MDM
On peut distinguer 3 niveaux de prise en charge des données d'un SI par un système MDM :
Master Identity : les clefs maîtres seulement sont gérées par le système MDM
Master Record : les attributs référentiels directs sont ajoutés
Master Data : gestion de l’entité complète, identifiant + attributs + données corrélées.
Master Identity
Niveau
d’urbanisation
du SI
Forces
Faiblesses
Exemple
d'application
en ES
08/10/08
Master Record
Master Data
Architecture
décentralisée
Synchronisation
du
MDM
Indépendance
des
applicatifs
Système MDM non
intrusif
Les
clefs
sont
l’essentiel
Peu d’empreinte sur le
SI
Imprécision
des
sources
Traçabilité non suivie
Qualité non garantie
Architecture hybride
Références
créées
dans le MDM
Co-dépendance des
applicatifs
Seul l'identifiant du patient
est partagé par l'ensemble
des applications du SIH.
Les
attributs
complémentaires sont
propres à chaque
application.
L'identifiant du Patient
ainsi que ses données
administratives
sont
partagés par l'ensemble
des applications du SIH
Disponibilité en un lieu
unique
Source
référentielle
certifiée
Harmonisation
des
applications
Conflit de règles
Maintenance délicate
Responsabilités floues
6/12
Architecture
centralisée
MDM maître
Synchronisation
applicatifs
des
Réconciliation
des
sources
Toutes
données
maîtres gérées
Dérive
sémantique
empêchée
Empreinte forte sur le
SI
Bénéfices
à
long
terme
difficiles
à
comparer aux coûts
Toutes les données liées
au Patient (identifiant,
données administratives,
DMP, etc.) sont partagées
par toutes les applications
du SIH.
établissement
Version 1.0
1.4 CHOIX D'UN OUTIL DE MDM
Avant d'être une solution logicielle, le MDM est avant tout une méthode et il reste possible de
"construire" une solution "maison" à partir d'outil tels que d'ETL ou EAI (voir fiches concept associés)
(voir la figure ci-dessous).
Figure 1 : Faire du MDM sans solution MDM
1. Un outil de BPM contenant une couche d’intégration applicative amont/aval, ou au contraire, un
outil d’intégration applicative (EAI, APS, ESB, …) comprenant un composant de workflow
‘humain’.
2. Un ETL (alimentation asynchrone) ou un Enterprise Information Integration (EII, alimentation en
temps réel – souvent virtuelle) enrichi d’une fonction de matching et d’une interface d’arbitrage
interactif des doublons logiques;
3. Le même ETL / EII + un requêteur avec sortie écran et fichier;
4. Un mini portail référentiel donnant un accès contrôlé et ordonné aux fonctions de :
Paramétrage des règles d’alimentation de l’ETL / EII, d’ordonnancement du BPM et
d’extraction du requêteur ;
Consultation des rapports de monitoring (suivi de l’activité, surveillance des alertes) ;
Administration des méta-données et arbitrage des doublons logiques.
08/10/08
7/12
établissement
Version 1.0
1.4.1.1 Critères spécifiques
Le "cœur" d’une solution de MDM, qu’on évaluera particulièrement, est composé :
Du modèle de données prévu pour stocker les données de référence : on s’intéressera à sa
généricité, son extensibilité, sa pertinence par rapport aux activités de l’entreprise, les templates
(modèles de données types prévus pour répondre à une modélisation connue) éventuels, la
simplicité de la conception, le typage des entités, la facilité de connexion et d’application d’un
requêteur standard, la gestion de l’historique des occurrences, les modalités de suppression
logique/physique et de modification a posteriori. La présence d’une base inverse est un avantage
et on vérifiera comment elle peut être exploitée pour un meilleur suivi de l’activité du MDM et pour
des analyses d’usage et d’utilisation. La base inverse permet notamment de produire des études
d'impacts et apporte des réponses aux questions "Si je modifie cette donnée, quelles sont les
applicatifs, les transformations, etc. impactés?"
Des fonctions d’import : on cherchera à démarquer leur intérêt par rapport à celles de l’ETL
possédé par l’entreprise : matching, merge, arbitrage interactif, recyclage, reporting d’anomalies.
De fonctionnalités d’administration : on évaluera la capacité à faire évoluer la structure de
stockage sans remise en cause du contenu, l’interface native de consultation du contenu,
l’ergonomie de paramétrage des différentes règles (dédoublonnage, rapprochement d'identifiant,
modifications de format, etc.); concernant le monitoring, on vérifiera la qualité des alertes
proposées, le paramétrage des déclenchements et des réactions au sein de processus,
l’intégration possible dans un "scheduler" applicatif ou un outil de BPM (Business Process
Management – voir fiche concept SOA).
Les outils "périphériques" du MDM sont secondaires car ils peuvent être couverts autrement :
La gestion des processus liés aux référentiels peut être automatisée au moyen d’un outil de BPM
déjà possédé par l’entreprise, ou à travers un EAI s’il existe. L’important est de pouvoir interfacer
la solution.
Les fonctions d’export peuvent être développées à faible coût au moyen d’un ETL et/ou d’un
requêteur.
Avantages concurrentiels :
Plus rares dans les entreprises, et très utiles : les fonctions spécifiques d’évaluation de la qualité
des flux d’import, et les capacités de data cleansing ciblées, voire de scoring qualitatif des
données filtrées (voir le § 3.6 sur la qualité des données). Par exemple, le nettoyage d'un fichier
Excel de réconciliation des Structures (voir le § 5.2 du guide sur la problématique autour du
référentiel des Structures)
Les outils de customisation par le développement spécifique autour de la solution : standard de
programmation (Java, .Net), interopérabilité par la multiplicité des connecteurs
La centralisation des données simplifient, et donc favorisent, la gestion des droits d'accès aux
données. La centralisation permettant, notamment, d'opérer de façon homogène sur les droits
d'accès.
1.4.1.2 Critères génériques
Le prix
Les compétences disponibles sur le marché ou en interne, et donc le niveau de maîtrise possible
de la technologie
Enfin et parce que le marché du MDM est assez mouvant et en cours de stabilisation (rachats et
fusions), on veillera également à s'assurer de la pérennité de la solution et notamment on
s’intéressera aux nombres et à la taille de sites en production, qui peuvent être de bons
indicateurs et qui donnent des garanties même en cas de rachat de l’éditeur.
08/10/08
8/12
établissement
Version 1.0
1.5 POSITIONNEMENT DES SOLUTIONS DE MDM DANS LE SIH
Le premier axe compare les solutions qui
apportent une réponse complète à la
problématique de MDM contre celles n'y
répondant que de manière partielle.
Le second axe compare les solutions qui
peuvent gérer n'importe quel type
données et les solutions limitées soit à
des domaines précis (produits, clients,
etc.) soit dans la nature même des
données gérées (ERP, analyse, etc.)
Figure 2 : Positionnement des
solutions de MDM dans le SIH
EII (Enterprise Information Integration) : ces solutions permettent d'interroger plusieurs sources de
1
données à travers le SI, afin d’apporter une vue unique des données en temps réel .
ETL (Extraction Transformation Loading) et EAI (Enterprise Application Integration) : ces solutions
peuvent être utilisées dans le but d'intégrer des données de référence disparates dans le SI.
Néanmoins, le MDM ne se limite pas à l'intégration des données, aussi ces solutions n’apportent
qu’une réponse partielle au besoin.
BI (Business Intelligence) : les éditeurs spécialisés dans la BI ont annoncé avoir intégré dans leur
plate-forme de BI une solution MDM. Ces solutions sont axées sur l'analyse primaire des données
de référence afin de résoudre des problèmes décisionnels. Mais le MDM doit également gérer les
données de références opérationnelles, ces solutions ne couvrent donc qu’un périmètre restreint
de la gestion des données de référence.
MDM ERP : les éditeurs de solutions packagées modernisent leur plate-forme avec l'ajout de
solution de MDM. Cependant, les fonctionnalités proposées sont souvent limitées aux seules
données de l'ERP et sont difficiles à adapter à d'autres contextes.
Vertical MDM (PIM, CDI, SDM) : historiquement, le MDM a été réalisé en utilisant différentes
solutions verticales : PIM (Product Information Management), CDI (Customer Data Integration) ou
SDM (Spend Data Management). La mise en œuvre d'une solution verticale peut être risquée
pour l'entreprise car elle est limitée à un domaine spécifique et impose souvent un modèle
propriétaire des données de référence.
MDM dédié ("pure play") : des solutions totalement dédiées au MDM ont vu le jour ces dernières
années. Ces solutions proposent de résoudre l'ensemble des problématiques autour du MDM de
manière générique (et non pas limitée à un type ou à une nature de données) et de bout en bout
(gestion de l'ensemble du cycle de vie des données de référence).
1
La grande différence entre un outil EII et un ETL est que le premier accède en temps réel aux données alors que le second
réalise une extraction périodique.
08/10/08
9/12
établissement
Version 1.0
2. PRINCIPAUX ENJEUX POUR LES ETABLISSEMENTS DE SANTE
La réforme de l'assurance maladie a un impact fort sur l'évolution des Systèmes d'Information
Hospitaliers et sa réussite passe nécessairement par l'échange et le partage des informations entre
les différents acteurs de la santé. C'est ce cadre législatif, dans lequel évolue le SIH, qui lui impose
d'être constitué d'une multitude de référentiels dont les données sont issues d’entités autres que les
établissements de santé (Assurance Maladie, GIP CPS, Ministère, etc.) mais utilisées au quotidien par
les ES (nomenclatures : CCAM, NGAP, GHM…, annuaires : RPPS, etc.).
Le SIH est également composé de multiples référentiels spécifiques à l’établissement :
Référentiels d’organisation (structurels) : structures, équipements
Référentiels internes comme le référentiel des patients par exemple
Fréquemment rencontrée, l'architecture en silos des SIH est la cause de redondance des référentiels :
c'est le cas notamment du fichier des structures (voir les paragraphes dédiés à ce sujet sujet dans le
guide). Cette redondance, si elle est maîtrisée, n’est pas forcément un obstacle à l’intégration ou à la
mise en place d’un SID.
Les principaux apports d'une solution MDM résident dans:
L'unicité des données (valeurs, représentations, règles de gestion,…et par là même de toutes les
métadonnées)
L'unicité de la mise à jour de ces données (industrialisation apportant un gain de productivité)
La garantie d'améliorer la qualité des données (pertinence, cohérence et fiabilité)
L'accessibilité à tous les acteurs habilités (internes comme externes)
08/10/08
10/12
établissement
Version 1.0
3. MISE EN ŒUVRE
Mettre en place un MDM correspond à une véritable urbanisation du SI.
3.1 FIXER LE PERIMETRE :
Plusieurs questions permettent de fixer le périmètre :
Quel cycle de vie et quelle architecture pour le MDM ?
Quelles données "maîtres" faut-il administrer et qualifier ?
Qui en certifiera la qualité et comment fera-t-il ?
Quels processus permettent-ils leur enrichissement, comment les régler et les piloter ?
Où stocker les données "maîtres", en quel endroit les mettre à disposition de qui et par quel
moyen ?
Qui sont les consommateurs et les contributeurs ? De quelle manière, dans quelle activité, à quel
moment ?
Quelle est l’infrastructure de substitution où la base des données maîtres sera à ‘équidistance’
des applicatifs consommateurs et contributeurs ? Que substituera-t-on réellement à quoi et de
quelle manière ?
Si un projet de MDM a été correctement cadré, il doit avoir répondu à toutes ces questions.
Une gestion des données maîtres, d’utilité générale doit d’emblée s’aligner sur la cohérence d’une
stratégie de service global.
Le champ d’application du MDM a, par ailleurs, une implication organisationnelle puisqu’il nécessite :
Une structure administrative des données maîtres,
Une organisation des ressources autour du nouveau gisement informationnel,
Une mise en évidence, peut-être aussi un redressement, des processus d’enrichissement,
La mise en place d’une infrastructure technique d’intégration se substituant aux habitudes
applicatives de gestion unitaire existantes.
3.2 LES PHASES D’UN PROJET DE MDM
Les phases d'un projet de MDM sont finalement très proches, en dehors du caractère technologique
lié à l'outil, de celles d'un projet de constitution d'un référentiel et s’intègrent normalement dans une
démarche de type schéma directeur, elle-même alignée au préalable sur le projet d’établissement.
1. Cadrage du projet :
Opportunité : direction, orientations techniques, road map, motivation fonctionnelle, travaux
relatifs à la qualité, importance accordée aux référentiels, aux processus ;
Portée envisageable dans le contexte organisationnel et informatique de l’entreprise ;
Faisabilité : cartographie de l’existant, financement, ressources, conformité stratégique,
ouverture du SI ;
Gains attendus versus coûts probables ;
Décision de faire : périmètre, plan de projet et d’investissement, logiciel ou spécifique, pilote,
délais.
2. Spécification générale :
Recensement et qualification des données du périmètre, identification des risques de non
qualité, critères de certification sémantique et fonctionnelle ;
Modalités d’inscription dans l’architecture du SI, désignation des composants et choix de
l’outillage ;
Recrutement et organisation des ressources d’administration du système, rôles et profils ;
Planification détaillée et constitution des équipes de projet par domaines techniques.
3. Spécification détaillée :
08/10/08
11/12
établissement
Version 1.0
2
Modélisation du Repository , généricité de la structure d’accueil garantissant l’évolutivité ;
Description des règles d’import et d’export ;
Formalisation du processus de gestion référentielle et description des interfaces ;
Montage de la structure de pilotage du projet et de coordination inter disciplines : sponsor,
métiers utilisateurs de la qualité, MOA déléguée sur le suivi des temps et des coûts, experts
techniques, équipe de développement.
4. Mise en œuvre, recettes, mise en exploitation
5. Bilan du pilote
Enfin, comme tout projet participant à l'urbanisation du SI, la démarche se veut progressive. il
conviendra donc de procéder par cycles itératifs et incrémentaux en évaluant de prime abord un
périmètre restreint puis en étendant progressivement: le champ couvert par la solution MDM.
Pour ce faire, il est possible de "jouer" sur 2 axes d'extension du périmètre :
Sur les données elles-mêmes, en débutant par les structures, par exemple ;
Sur le type d'intégration que l'on souhaite mettre en œuvre : Master Identity, Master Record,
Master Data (voir tableau "Niveau d'intégration d'un MDM" ci avant). Attention néanmoins à bien
définir le niveau d'intégration car c'est un choix très structurant pour la suite qu'il peut être difficile
de faire évoluer.
2
Le Repository est une base contenant les données sur les données (méta données) à traiter. L'administration et la gestion de
la solution MDM mise en place sont faites à partir de cette base. La modélisation du Repository consiste donc à définir quelles
seront les données – et les attributs – administrées par la solution MDM.
08/10/08
12/12

Fiche Concept MDM (Master Data Management)

Transcription

Documents pareils

1902ManagerSectoriel

MEDICOS DEL MUNDO ESPAÑA RECHERCHE: COORDINATION

Note de recherche - Le Catalogue de Services

Full Article – PDF

business intelligence / epm e-business cim / crm erp

Dossier de presse - Médecins du Monde

Rapport Inde 20008