"Bonjour à tous et bienvenue pour ce quatrième épisode de Kézako.data.
Je me présente Stéphan Verdier, Directeur du Pôle Data Management de Kwanzeo.
Aujourd'hui, je vais vous parler des erreurs à éviter sur un projet Master Data Management.
Dans cet épisode, nous allons faire un rappel de l'épisode 3 sur le Master Data Management, aborder et détailler les huit points suivants :
1. Rappel épisode 3 : Le Master Data Management
2. La qualité des données
3. Le positionnement du MDM
4. Le format Pivot dans les échanges
5. La supervision
6. Le périmètre initial du projet
7. La définition du projet et qui participe
8. Le manque d´expertise
1. Le Master Data Management
Dans cette partie, nous allons répondre aux questions suivantes :
> Qu'est-ce que le Master Data Management ?
> Quel est l'objectif du Master Data Management ?
> Quel est l'écosystème d'un Intelligent Data Hub ?
> Qu'est-ce que le Master Data Management ?
- Un MDM centralise toutes les Données de Référence en un point unique le GOLDEN RECORD !
- Un MDM propose des processus de standardisations, de normalisations, de consolidations, de nettoyage des doublons, de propagations et de traçage des données de référence pour une entreprise.
- Un MDM propose aussi des outils de reporting et de découverte de la donnée, de l´exposition de service de création, modification et consultation des données.
> Quel est l'objectif du Master Data Management ?
Son objectif est de :
- Centraliser, standardiser, réconcilier, publier une information qui correspond au business de l´entreprise ;
- Simplifier la prise de décision métier sur les nouveaux besoins et faciliter sa mise en place dans l´organisation.
Mais aussi simplifier la prise de décision côté équipe IT sur la rationalisation des échanges et l´homogénéisation des données.
- Enrichir l´information grâce à un processus de certification qui correspond aux besoins définis par le métier c'est-à-dire centralisation, standardisation, normalisation, vérification des informations, publication du Point de Vérité.
L´lntelligent Data Hub est le nouveau terme pour parler du Master Data Management.
> Quel est l'écosystème d'un Intelligent Data Hub ?
En formant un « Hub de données », l´outil permet de contrôler le flux de données de référence, de l´enrichir, d´améliorer sa qualité et
d'instaurer des moyens de gouvernance.
Le Hub permet de disposer d´une vision complète et coordonnée des données de référence au sein de l´organisation, de l´entreprise. Il offre les moyens de pouvoir diffuser et/ou d'orchestrer l´usage et l´actualisation de ses données.
L'ensemble des briques du SI (opérationnelles et décisionnelles) fourniront un service bien plus efficace !
2. La qualité des données
Dans cette partie, nous allons voir les erreurs à éviter et les conseils sur :
La qualité des données des applications :
> Attention à ne pas surévaluer le niveau de qualité des données avant la mise en place d´un Data Hub.
> Cette phase de vérification et de profilage de la donnée est nécessaire pour bien appréhender les enjeux et les objectifs d´un projet MDM.
> La préparation et le recensement des données prennent du temps en fonction de l´état des données et du nombre d´applications présentes au sein du SI.
> Certains éditeurs proposent un module « Discovery » qui permet de vérifier la qualité de la donnée en injectant celle-ci dans des tables. Ce module fait gagner énormément de temps et centralise toutes les informations.
> Si ce module n´existe pas pour vérifier la donnée, l´utilisation d´outils de BI (Business Intelligence) ou spécialisés dans la gouvernance de donnée pourront répondre à ce besoin.
> Cette étape de préparation, recensement et profilage des données de référence dans les applications, afin de rendre exploitable peut prendre quelques semaines voire quelques mois.
> C´est un chantier à mener en parallèle d´autres sujets, mais à prendre en compte dès le démarrage du projet afin de ne pas rater la date de mise en production du MDM.
3. Le positionnement du MDM
> Attention à ne pas positionner le Data Hub sur le chemin critique du projet de restructuration ou d´amélioration du système d´information.
> Dans un premier temps, le MDM doit être placé en mode esclave, celui-ci n´échangera pas les informations en temps réel, c´est une architecture de consolidation avec un « couplage lâche » (asynchrone).
> Les applications doivent continuer d´échanger entre elles sans que le référentiel n´entrave les échanges.
Pour détailler un peu plus l´Architecture de consolidation (cf. schéma):
> Les informations transitent des applications vers le Data Hub grâce à des ETL, des batchs ...
> C'est un traitement asynchrone qui peut être déclenché plusieurs fois dans une journée.
> En revanche, les données ne transitent pas du Data Hub vers les autres applications …
> Ce qui laisse un déphasage des données entre applications mais n´entrave pas les échanges existants entre les applications.
Un projet MDM est complexe, prend du temps, peut mettre en péril d´autres chantiers du Système d´Information. Les échanges interdépendants avec le MDM doivent donc avoir une attention particulière en termes d´architecture.
Lorsque le projet est bien avancé, l´architecture à mettre en place sera de type transactionnelle. Les applications n´échangent plus directement entre elles mais passent par le Data Hub qui va diffuser les informations de références certifiées du MDM.
Comme je l´ai dit, ensuite l´Architecture à mettre en place est une Architecture transactionnelle.
Dans cette architecture, une plateforme d´échange de type ESB est nécessaire.
Les informations de référence des applications ne passent plus directement dans le Data Hub.
C´est la plateforme qui offre des services et qui fait les échanges entre les applications et le Data Hub.
Cela évite des échanges en point à point entre les applications.
Le but de cette Architecture est que l´ensemble des applications aient le même niveau d´information.
Une application envoie ses informations à la plateforme d´échange, le Data Hub traite la donnée et la plateforme d´échange diffuse la donnée à toutes les applications.
C´est une architecture orientée service.
Pour avoir plus de détails sur les types d´architectures, je vous conseille de regarder notre épisode 2 des Kezako.Data qui parle des différents types d´Architecture autour du MDM.
4. Le format Pivot dans les échanges
> Une absence de format pivot sur les échanges inter-applicatifs en relation avec un Data Hub est une source chronophage d´erreurs et de problèmes d´interprétation de la donnée.
> Le format pivot doit être pensé dès le début des échanges au moment même de la modélisation de la plateforme d´échange.
> Les échanges doivent se faire via un ETL en début de projet pour avoir un couplage lâche (asynchrone).
Le format PIVOT permet de préparer le passage de l´Architecture de consolidation à l´Architecture transactionnelle.
Le format PIVOT sera utilisé dans la plateforme d´échange dans l´exposition des services qui seront consommés par le Data Hub et les applications.
(cf. schéma)
Au fur à mesure de l´avancement du projet, la plateforme d´échange proposera des APIs en temps réel avec une Architecture transactionnelle (orientée service) pour finir sur une Architecture centralisée (orientée utilisateur).
Garder le fonctionnement avec un ETL même après la mise en production du projet dans le cas où la plate-forme d´échange en temps réel tombe ou si des mises à jour en masse sont nécessaire comme initier une nouvelle application dans votre MDM.
En résumé :
1. Echanger via un ETL ;
2. Démarrer le développement de la plate-forme d´échange en temps réel et publier les APIs de consultation des données du MDM en mettant en place les premiers éléments de supervision ;
3. Les applications qui doivent interagir avec le MDM doivent commencer à appeler les APIs de consultation exposées par la plate-forme avant de créer les informations dans ces applications.
5. La supervision
Dans cette partie nous allons voir les erreurs à éviter et les conseils sur la supervision.
> En parallèle de la plate-forme d´échange, la supervision des échanges doit débuter, avec les métriques et les KPI qui vous feront gagner énormément de temps, gagner de la visibilité sur l´avancement du projet et donner des données quantifiées à la direction ou au sponsor.
> Cette étape est nécessaire aux projets et est bien trop souvent réalisé à la fin du projet. Ne surtout pas faire cela car en fin de projet ce n´est pas cela qu´attendent les sponsors.
La supervision des données doit être réalisée :
> Dans les applications sources ;
> Dans les applications cibles ;
> Dans la plateforme d´échanges ;
> Dans le Data Hub
Attention à ne pas sous-estimer les délais de mise en place de cette étape.
6. Le périmètre initial du projet
Un périmètre trop large de récupération des données fait souvent "capoter" les projets en termes de délai, les risques sont les suivants :
1. Analyse des informations trop longue ;
2. Maintenance corrective qui s´accroit ;
3. Problème de performance au sein du SI ;
4. Pas de retour d´expérience sur la faisabilité et les problèmes rencontrés ;
5. Insatisfaction des utilisateurs, du sponsor et de la direction ;
6. Décalage de livraison du projet ;
7. Taille des équipes plus forte, puisqu´il y a plus de choses à faire.
Prendre un périmètre restreint permet de gagner en maturité sur tous les secteurs du projet et aussi à avoir des retours d´expériences bien plus intéressants pour poursuivre le projet.
7. La définition du projet et qui participe
Dans cette partie, nous allons voir les erreurs à éviter et les conseils sur la définition du projet et qui participe.
Attention, l´ensemble des équipes doivent travailler conjointement du pré-cadrage à la mise en production.
La partie pré-cadrage du besoin est importante, elle permet de savoir :
1. Ce qui va être réalisée ;
2. Ce qui est faisable ;
3. D´interviewer les différents éditeurs ;
4. De permettre d´entrevoir les coûts (Humain, Editeur, Machine, …).
Au minimum un représentant de chaque équipe doit être présent dans cette phase.
Une fois que le besoin exprimé, que celui-ci est clairement identifié et réalisé, que les membres du projet sont impliqués, chacun d´entre eux doit être acteur de :
1. La participation au cadrage, au kick-off, au dimensionnement des équipes ;
2. La mise en place et de l´estimation du Backlog ;
3. La mise en place des cérémonies et des réunions ;
4. La définition des représentants aux réunions ;
5. Du choix du périmètre et du MVP ;
6. La définition des premiers jalons ;
7. La mise en ordre de marche des équipes et GO !
Attention, les équipes souvent oubliées en début de projet sont les équipes Infrastructure et Exploitation.
Faites vraiment attention à les impliquer dès le démarrage du projet afin de ne pas avoir une surcharge de travail en fin de projet car après la mise en production, ce sont ces équipes qui auront la charge de faire tourner le système.
N´oublions pas que les documents nécessaires au bon fonctionnement de la solution viendront en partie des équipes de développements et métiers.
8. Le manque d´expertise
Dans cette partie nous allons voir les erreurs à éviter et les conseils sur le manque d´expertise.
Sur les projets MDM, l´expertise est capitale en début de projet, les experts MDM feront gagner un temps considérable par rapport à des juniors.
Au fur à mesure du projet le besoin sera moindre, et les experts seront remplacés par des personnes juniors. Les experts feront plus de suivi et de vérification des bonnes pratiques.
Ne pas oublier la montée en compétence des équipes internes à l´entreprise sur le projet. Cela prend un temps non négligeable, faites appel à l´éditeur sur ce point.
Pour éviter des problèmes techniques, un forfait jour d´expertise par l´Editeur est conseillé.
Merci d'avoir suivi ce quatrième épisode de Kezako.data MDM - Data Hub, n'oubliez pas de vous abonner à notre chaîne YouTube et pour toutes questions ou projets, contactez-moi par mail à : contact@kwanzeo.com ou en remplissant le formulaire.
Stéphan"