MDM Multi domaines ? Vraiment ?

Clients, Produits, Fournisseurs, Structures, ces termes métier simples ont longtemps permis une segmentation compréhensible du marché des solutions logicielles et développé l’appétit des éditeurs pour des offres technologiques capables d’adresser plusieurs de ces domaines pour en maximiser la valeur et évidemment le revenu.

La multiplication des solutions MDM dites multi domaines aujourd’hui rend cette segmentation caduque et conduit à s’interroger sur la pertinence d’un critère qui pourrait bien n’avoir jamais eu de réelle signification. Revenons aux fondamentaux, avec une approche délibérément provocatrice : une solution de gestion des données de référence n’a pas pour objectif de gérer les données de référence. Même si l’approche référentielle est philosophiquement belle, une entreprise ne se lance pas dans la mise en place d’un référentiel Clients à la seule fin de constituer et gérer ce référentiel. Elle le fera pour répondre à un objectif métier, par exemple améliorer son ciblage marketing ou augmenter son chiffre d’affaire par une meilleure connaissance du client, de son portefeuille et de ses préférences. Une initiative référentielle se positionne donc en support d’un objectif ou besoin métier, comme une partie de la solution et non la solution (on mentionnera les aspects organisationnels de gouvernance, d’éventuelles applications métier consommatrices, etc.).

Il semble donc beaucoup plus pertinent de définir un projet de MDM non pas selon son domaine mais bien selon le cas ou les cas d’usage métier qu’il est censé supporter. Prenons un exemple précis : pour répondre à un besoin de rationalisation et optimisation des achats, on imagine aisément le bénéfice de fournir aux applications opérationnelles ou analytiques une information de référence sur les dimensions Produits mais également Fournisseurs. De la même manière, la rationalisation du monde RH nécessitera l’établissement d’une source unifiée de données Employés mais probablement aussi de données Structures organisationnelles. Les spécificités des solutions MDM propres à supporter ces besoins ne sont donc plus liées aux domaines de données qu’elles adressent mais bien aux cas d’usage métier qui les manipulent. Le mode de manipulation de ces données – c’est-à-dire leur acquisition, leur gestion et leur consommation, en fait leur gouvernance – constitue un critère au moins aussi important que leur « domaine ».

Les analystes ont défini quatre modes, simplifiés, de gouvernance, correspondant chacun à une architecture référentielle particulière, et évidemment à des services MDM spécifiques offerts au reste du SI :
- le mode registre (gouvernance externe au référentiel),
- le mode consolidation (gouvernance interne à posteriori, fréquemment à destination de l’analytique),
- le mode centralisé (gouvernance interne totale, l’acquisition des données se faisant directement au sein du MDM)
- le mode coexistence, un mode hybride entre centralisation et consolidation, appelé aussi transactionnel de par son imbrication dans les processus métier de l’entreprise, la gouvernance étant partagée entre MDM et applications.

Historiquement, les modes d’architecture et les domaines étaient principalement alignés, coup de chance lié au petit nombre de domaines considérés à l’époque (Clients et Produits). Les entreprises, non propriétaires des informations clients, s’appuient sur les applications métier en contact avec ces clients pour acquérir ces informations, et les gouvernent dans le référentiel selon les modes consolidation ou coexistence, dépendant de leur maturité (cas d’usage CDI – Customer Data Integration). Infiniment plus maîtres de leur information produits, les entreprises gardent la main sur leur création et les gouvernent dans le référentiel selon le mode centralisé (cas d’usage PIM – Product Information Management). La multiplication de nouveaux domaines, ainsi que de nouveaux cas d’usage supportés par les référentiels ont modifié cet état de fait et cet alignement simpliste. Pourquoi s’interdire des cas d’usage PDI (Product Data Integration) ou CIM (Customer Information Management), voire xDI et xIM, quel qu’en soit le domaine ? Dans le monde bancaire, on pourra citer l’opérationnalisation de données Produits acquises par l’entité de distribution auprès des entités de production (internes ou externes) ou le référencement manuel de données Tiers (Fournisseurs principalement) dans les projets d’approvisionnement achats.

Il est évident que chacun de ces différents modes de fonctionnement référentiel nécessite un ensemble de capacités spécifiques, d’ordre technique (scalabilité, haute disponibilité, facilité d’intégration) ou fonctionnel (interface utilisateurs métier, support de processus de saisie, qualité de données, etc.). Il est improbable qu’une unique solution puisse les offrir toutes, qu’elle soit « multi domaines » ou non. Il est donc critique d’évaluer les offres logicielles non pas sur leurs capacités à adresser un ou plusieurs domaines, mais bien au regard des besoins fonctionnels et techniques spécifiques des objectifs métiers propres à justifier une stratégie MDM. Anticiper les besoins futurs se révèle ainsi clé pour conserver au MDM sa dimension fondationnelle, au travers d’une solution la plus riche possible, en terme de modèle (aspect « multi domaine »), mais également de services fonctionnels et techniques. C’est ce qu’ont compris certains éditeurs, comme Informatica, en proposant une approche best-of-breed du MDM, sous forme de plateforme modulaire évolutive. Le MDM y acquiert sa maturité : bienvenue dans le « multiples domaines »*…

* Terme utilisé par Gartner pour décrire les solutions logicielles adressant l’ensemble des domaines/use cases avec différents modules intégrables en provenance d’un éditeur unique.

http://blogs.informatica.com/perspectives/fr/author/david-decloux/
David est Responsable de l'équipe d'experts MDM en Europe, il supporte avec brio les équipes locales dans la collecte des besoins, le design des solutions, l'architecture et les POC pour les solutions MDM Informatica. Avant de rejoindre Informatica, David était consultant avant-vente sur l'offre MDM InfoSphere d'IBM. Avant d'intégrer IBM il était chef de projet au sein de KeyMRO (acquise par IBM GBS), où il a acquis une expérience de premier ordre sur le Master Data Management et notamment le PIM (Product Information Management).