Pour assurer la réussite d’un projet de Master Data Management, il s’agit de procéder avec méthode et rigueur. Entre bonnes pratiques de gestion de projets IT, compréhension des enjeux du MDM et prise en compte des impacts sur la gouvernance de la donnée, les écueils sont nombreux !
Le MDM a vocation à devenir le point de vérité de l’information pour toutes les applications du système d’information; c’est donc un projet structurant impliquant de la conduite du changement et une vision transversale au niveau de l’organisation. Ainsi, on ne mène pas un projet de Master Data Management comme on piloterait un projet de GED (Gestion Electronique de Documents), de PIM (Product Information Management) ou de DAM (Digital Asset Management).
Quelle est la cartographie des données du Système d’Information ? Quelles données faut-il intégrer et en provenance de quelles applications sources ? Quels sont leurs niveaux de fiabilité et de qualité ? Comment anticiper les évolutions de l’organisation qui impacteront le Master Data Management dans les années à venir ?
TOP 10 des mauvaises pratiques pour rater son projet MDM
01. Vouloir tout construire et brancher d’un coup
Le pire ennemi d’un projet MDM (Master Data Management) consiste à vouloir tout construire et tout brancher d’un seul coup ; la fameuse approche OFF/ON. Cette approche entraîne des effets dévastateurs par un effet tunnel évident et par l’absence d’un rodage des processus de gouvernance.
Il faut au contraire encourager l’itérativité et l’agilité pour adapter le référentiel et l’organisation.
02. Appréhender le projet MDM comme un sujet purement technique
Un projet MDM est un projet d’entreprise et non un projet IT. Il ne peut se limiter à une centralisation technique de données, il doit permettre l’obtention et la maintenance d’un point de vérité unique.
Pour cela, les acteurs métiers doivent être totalement impliqués dans le programme dès son initialisation pour garantir la valorisation du capital data.
03. Reporter le sujet de la qualité de données à « plus tard »
L’approche itérative doit être pertinente ; il est préférable de progresser périmètre par périmètre, mais en s’imposant la construction d’un socle fiable étape après étape.
L’acceptation d’un tel programme se trouve dans l’amélioration et la confiance de la qualité des données fournies et non à la vitesse de construction d’une base de données.
04. Faire abstraction de la diffusion de l’information dans le projet MDM
Un programme de gestion des données de références a du sens si et seulement si il est exploité. Il est donc crucial de ne pas omettre la notion de branchement au SI, et éventuellement à un écosystème partenaire. L’usage d’un bus d’entreprise (ESB) ou d’un portail d’API (API Management) démultiplie le ROI d’une telle initiative.
05. Ne pas rattacher ce projet MDM aux enjeux réglementaires
Il est commun de dissocier le réglementaire de la gestion des données d’une organisation, ne serait ce que par un découpage naturel du cadre de responsabilité. Pour autant, un référentiel de données maîtres simplifie grandement la mise en place et le respect d’un grand nombre de réglementation. On peut par exemple identifier l’importance des axes de ventilations dans un contexte bancaire (Bale) ou assurance (Solvency), et bien sûr la maîtrise des données sensibles avec la GDPR.
06. Imposer le changement porté par le projet MDM sans l’accompagner
Un projet MDM ne s’impose pas, il se construit collectivement. A l’instar de la mise en place de tout processus, les collaborateurs doivent comprendre le sens et l’intérêt commun de l’organisation. L’accompagnement au changement est une composante essentielle de projet MDM réussi.
07. Faire abstraction du cycle de vie des données de références
Les données d’une organisation dispose d’un cycle de vie qu’il ne faut pas omettre, ce cycle est souvent révélateur de qualités ou de dysfonctionnements. La définition d’une gouvernance adaptée doit répondre à une transition maîtrisée et juste. Un programme MDM (Master Data Management) ne doit pas porter le fardeau d’une refonte organisationnelle de vos processus, il doit en être le catalyseur.
08. Mélanger les genres : PIM/CRM/BAM/MDM
Le marché de la gestion des données est riche, voir déconcertant dans certains cas. Pour garantir un choix juste, il convient de bien définir les objectifs de votre organisation et le cadre que vous souhaitiez lui donner. L’identification de la solution idoine découlera naturellement de cette étape initiale et vous permettra de passer outre les « grandes tendances » du marché.
09. Oublier l’histoire des données
Les données d’une organisation ont une histoire passée qu’il faut intégrer durant la conception et la préparation des données pour leur reprise initiale. La mise en qualité des données repose donc sur un profilage de qualité, permettant d’adapter les traitements d’acquisition, de redressement et d’enrichissement des données. Il est nécessaire de prendre en compte cette histoire pour garantir l’amélioration continue des données.
10. Isoler le projet MDM
De par sa nature « référentielle » un projet MDM a vocation à fournir une information de qualité pour tout autre projet, en tant que point de vérité.
Il est donc essentiel de synchroniser la construction d’un référentiel avec les autres projets pour éviter les redéveloppements et simplifier l’intégration du référentiel.
Interview : deux retours d’expérience sur l’accompagnement réussi de projets MDM
Initier la transformation et mettre en œuvre les projets de MDM soulève encore et toujours des questions de méthodes et requiert une maîtrise des bonnes pratiques. Dans cette interview, Isabelle François, nous partage ses retours d’expérience sur deux projets de mise en place d’une solution de data management.
Pourrais-tu nous partager les contextes des deux projets MDM que tu as accompagnés ?
Isabelle François : Le premier retour d’expérience s’est déroulé au sein d’un groupe industriel leader de l’emballage plastique alimentaire. Le contexte projet suit un schéma que l’on retrouve souvent : l’entreprise prévoyait de changer d’ERP d’ici un an et désirait anticiper ce projet majeur. Il souhaitait donc centraliser et mettre en qualité l’ensemble des données afin d’être prêt le jour de la bascule sur le nouvel ERP.
L’enjeu était aussi de nettoyer la donnée et de disposer d’une solution robuste, capable de diffuser l’information vers les applications sources. La priorité portait sur les objets articles et fournisseurs. En effet, la donnée était auparavant très peu centralisée, avec des requêtes techniques qui transitaient dans chaque application source. Impossible pour le siège de disposer d’une vision consolidée et agrégée des données ! On retrouvait des problématiques classiques comme la redondance d’information. Chaque application créait par exemple elle-même son fournisseur. On imagine bien les impacts que cela peut avoir au sein d’un grand groupe international…
Le deuxième projet a pris place dans un groupe international du secteur de la santé, avec des problématiques similaires. Les tiers pouvaient avoir plusieurs facettes : clients, fournisseurs… et le siège avait besoin d’avoir une vue d’ensemble des implications entre les tiers.
Les enjeux étaient stratégiques : faut-il mettre en place une centrale d’achat ? Comment disposer d’une vision globale et consolidée des flux entre toutes les entités ? Avec des applications cloisonnées qui ont chacune leur propre logique et sont concentrées sur leur périmètre métier, c’est extrêmement compliqué à harmoniser.
Isabelle François – Product Manager – Blueway Software
MDM : Comment améliorer la qualité et la traçabilité de vos données dans votre SI ?
La mise en place et l’organisation du projet de master data management a été similaire ?
I.C : Non ! Ce n’est pas parce que la cible est la même que la mise en place suit le même déroulé. Ces deux projets en sont un bon exemple. Il faut s’adapter à la maturité de l’entreprise et aux ressources internes.
Dans les deux cas, les projets MDM ont débuté par l’entité « fournisseur ». Il est souvent préférable de mettre en place les automatismes et les bonnes pratiques sur un objet plus simple, et ensuite d’ouvrir le périmètre à des entités plus complexes, comme le « produit » par exemple.
Au sein du groupe pharmaceutique, ce sont les équipes internes qui ont piloté la reprise de données au sein de notre logiciel MDM. Il y avait en parallèle un enjeu fort de mettre en place des processus pour la saisie des nouveaux fournisseurs ainsi que l’évolution et l’extension des fournisseurs existants. C’est nous qui avons pris la main sur cette dimension au travers de notre brique BPM (Business Process Management).
C’est au travers de cette brique BPM que s’est construit le « golden record » ou version de référence de la donnée. Ainsi, ces processus garantissent l’unicité de la donnée fournisseur en permettant aux intervenants de saisir les informations et de les enrichir au travers d’une suite d’interfaces. Chaque rôle va compléter et valider la donnée. Le BPM peut ensuite diffuser l’information vers les autres applications, SAP en particulier.
Dans le projet au sein du groupe industriel, nous avons coaché l’équipe du client et nous les avons guidés tout au long du projet. La première étape que nous avons pilotée, a été la reprise de données avec une trentaine de sources différentes ! Il y avait dans ce projet MDM un vrai enjeu d’industrialiser la reprise de donnée et de développer un service central pour la mettre en forme et l’intégrer dans le MDM.
Pour industrialiser la reprise de donnée, il fallait à tout prix éviter de multiplier les services selon les applications sources. Cela aurait été un vrai risque pour la mise en qualité et l’unicité de la donnée.
Isabelle François – Product Manager – Blueway Software
Les données étaient ainsi récupérées automatiquement dans Data Governance, le Master Data Management de Blueway, en provenance de sources très variées et avec des formats hétérogènes, puis analysées et renvoyées aux sources une fois mises en qualité. En l’espace de trois mois, nous avons réussi à intégrer toutes les datas fournisseurs en provenant de plus de 30 sources, un vrai challenge ! Le premier mois, nous avons rapidement identifié les erreurs de formats, de saisie, de doublon… au sein des applications sources. Les équipes métiers du client avaient parfaitement compris les enjeux du MDM et ont été très réactives pour effectuer les corrections.
Avec ce processus industriel, les sources pouvaient continuer d’alimenter le MDM automatiquement, en attendant l’intégration du nouvel ERP.
MDM versus PIM : frères ennemis ou dream team ?
Y a-t-il eu des contraintes spécifiques pour déployer ces solutions de data management ?
I.C : Au sein du groupe pharmaceutique, les contraintes portaient avant tout sur les règles fonctionnelles très pointues à mettre en place au sein du logiciel BPM (Business Process Management). Par exemple, les règles de saisie variaient selon les types de fournisseurs, la gestion de droits imposait un routage très fin des tâches et des données selon la société et l’utilisateur…
L’objectif était de contrôler toute création ou modification de fournisseur, quelle que soit la société du groupe. Il s’agissait d’arrêter de créer des fournisseurs dans chaque application et tout centraliser au sein du BPM de notre Plateforme de données Phoenix pour ensuite redistribuer l’information vers les applications sources.
La dimension internationale des deux projets a aussi impliqué d’avoir des applications entièrement multilingues. Ce sont des enjeux courants, mais qui revêtent des impacts particuliers dans le cas de solutions de data management.
Comme toujours, le cadrage des règles en amont, en évitant les modifications en cours de projet, est un vrai facilitateur pour éviter des impacts sur le planning. Changer les règles du jeu en cours de route implique de relancer des batteries de tests !
Isabelle François – Product Manager – Blueway Software
Avec l’arrivée du marketing dans le projet sur la partie catalogue, une fois l’entité fournisseurs traitée, on s’est aussi rendu compte de l’importance d’adapter la démarche selon les utilisateurs. Le marketing portait par exemple beaucoup plus d’importance à l’ergonomie des écrans que les utilisateurs de l’ERP. Nous avons ainsi fait évoluer l’interface pour répondre à leurs besoins et faciliter l’adoption de la solution.
Y a-t-il des points que tu souhaiterais mettre en lumière sur ces projets de data management ?
I.C : Avoir des équipes côté client disponibles, investies et avec des rôles bien définis est un vrai gage de succès. Par exemple, dans l’un des projets, l’équipe client était constituée du sponsor du projet pour valider les grandes orientations, d’un interlocuteur technique et d’une personne externe qui travaillait sur la modélisation de la donnée. Un bon trio !
L’industrialisation de la reprise de la donnée était une démarche très intéressante et qui a vraiment accéléré et fiabilisé le déroulement du projet. C’était aussi l’occasion de confirmer que Phoenix était adapté pour de la récupération massive de données.
Ces projets ont aussi permis d’avancer sur le produit. Être à l’écoute du client pour répondre précisément à son besoin et intégrer les bonnes idées dans les prochaines versions de nos solutions fait partie de notre ADN. Nous sommes une PME, nous savons être agiles !
Isabelle François – Product Manager – Blueway Software
Pour conclure, ces deux projets sont des bons exemples des atouts de Blueway. Notre client industriel nous avait sélectionné pour notre capacité à industrialiser la reprise de donnée, sans développement lourd, et servir de solution robuste en attendant la mise en place de l’ERP. Pour notre client pharmaceutique, c’est le lien entre BPM et MDM qui a fait la différence.
Dans ces deux cas, des enjeux qui peuvent paraître distincts : MDM, BPM, ESB, APIM, Data Catalog… sont en fait très complémentaires pour réussir les projets autour de la donnée. C’est cette conviction qui est à l’origine de notre plateforme de données Phoenix !
Echangez sur vos problématiques de qualité de données avec un expert Blueway !
