Retour aux Bases : Déchiffrer les Typologies de Hub MDM

Cet article continue notre série d’articles « Retour aux Bases » ou « La Gestion des Données est simple ». Dans un article précédent, j’ai décrit la classification des données communément admise et défini les données master, de référence et golden.

Ces données master/de référence/golden sont habituellement stockées et gérées dans une base centrale: le Hub MDM.

Typologies de Hub

Il y a plusieurs typologies (ou modèles, patterns, styles) identifiées pour un hub MDM.

Hub de Type Registry

Dans ce type de hub, les données master sont éditées et restent dans les systèmes sources. Le hub stocke un index vers ces données sources, et garde une trace des références entre les données sources en doublon. En outre, ce style hub stocke habituellement les attributs utilisés à des fins de dé-doublonnage (matching).

La distribution des données master est effectuée en aval par fédération des données sources. Les processus de transformation et de consolidation des données sources en données golden sont réalisés à la demande.

Cette approche est complètement non-intrusive et préserve les données exclusivement dans les applications source. Cette typologie permet l’accès aux données golden en lecture seule via des requêtes fédérées. La fédération des données à la volée lève des questions et des défis technologiques relatifs à la performance, particulièrement quand des données volumineuses ou des stratégies de transformation et de consolidation complexes entrent en jeu.

Hub de Type Consolidation

Dans ce modèle, les données master sont copiées à partir des applications sources, puis dé-doublonnées et consolidées dans le hub; Les données golden physiquement créées dans le hub sont alors disponibles pour distribution aux applications en aval ou pour consommation directe par les utilisateurs métier et les intendants de données.

Ce style de hub est aussi peu intrusif que le style registry. Puisque les données golden sont stockées dans le hub, les problèmes de performances liés aux stratégies de transformations et consolidations complexes disparaissent, et des processus d’intendance (« stewardship ») peuvent être exécutés et orchestrés dans le hub.

L’intendance est un ensemble de processus et de politiques qui s’exécutent sur le hub. Ils comprennent la saisie des données (pour complétion ou correction des données du hub), la gestion des doublons (pour les faux doublons ou les cas particuliers) et la gestion des rejets.

Hub de Type Coexistence

Cette typologie est similaire au hub de type Consolidation. Elle ajoute une boucle de retour des données golden vers les applications sources.

Ce style est non intrusif du point de vue de l’utilisateur final, mais amène d’importants défis techniques et organisationnels pour approuver et mettre en œuvre le processus de retour des données golden.

La réalisation d’une boucle non pas au niveau des données de l’application, mais au niveau de l’interface utilisateur simplifie le problème. Une telle boucle peut être mise en place sous la forme de portlets affichant dans l’interface les « clients similaires dans les autres systèmes » ou la « fiche client golden » correspondant à l’enregistrement client affiché ou en cours d’édition par l’utilisateur.

Hub Centralisé/Transactionnel

Dans ce modèle, les données master sont entièrement migrées et nettoyées dans le hub MDM. Ce dernier devient le fournisseur unique de données master, et les données master sont exclusivement saisies dans le hub par le biais de processus et workflows de saisie. Toutes les applications se réfèrent au hub pour leurs données master.

Cette typologie garantit le plus haut niveau de qualité pour les données master, mais est extrêmement intrusif sur les processus techniques et métier existants; Il oblige à les repenser autour du hub MDM.

Ce style s’applique pour créer des données golden ex nihilo, c’est à dire lorsque ces données n’existent pas de manière formelle au niveau opérationnel. Par exemple, pour remplacer les « Feuilles Excel de Centres de Coûts », ou les «Bases MS Access des Employés » stockées sur les disques durs et boîtes email des utilisateurs.

Une utilisation radicale de ce style est le remplacement des applications opérationnelles d’édition des données master par le Hub MDM. Bien qu’il soit possible de le faire, un tel déplacement de l’édition sur le hub MDM est un risque majeur pour les processus opérationnels existants, comme illustré dans le scénario suivant:

Un commercial est au téléphone avec un nouveau client. Il passe de son application CRM ou de gestion des offres à l’application MDM pour commencer la création du nouveau client, puis attend que ce nouveau client soit validé par les intendants de données pour le voir d’apparaître dans son CRM, ce qui lui permet finalement de passer la commande.

Inutile de dire qu’un tel processus peut prendre beaucoup de temps, alors que le client attend au téléphone ! Ce processus pourrait en effet garantir une qualité supérieure des données client, mais transformerait ce simple processus de commande en un véritable cauchemar.

Une Typologie Pour Tout Gouverner?

Aucune des typologies décrites ci-dessus n’est un modèle magique pour gouverner toutes les données master.

Selon le domaine, les applications sources ou les données master envisagées dans le hub MDM, il est possible vouloir stocker toutes les données ou uniquement les références, ou se positionner entre ces deux points. Il est possible de vouloir de la consolidation, avec quelques fonctionnalités de saisie, ou de la saisie seule pour certaines données.

Ajoutez à cela le fait que le hub MDM évoluera au fil du temps pour inclure de nouveaux domaines ou de nouvelles données, avec des exigences différentes qui rendront obligatoire le passage à une autre typologie.

Par exemple, dans un hub multi-domaines complet:

  • Les données des clients seraient gérées dans un style coexistence, agrégeant des données du CRM, du site web, etc., avec une boucle de retour vers le système CRM.
  • Les données des produits seraient gérées dans un style consolidation (à partir du PLM et de l’ERP), avec des attributs supplémentaires et des processus de validation gérés dans le plus pur style transactionnel.
  • Les données sensibles seraient traitées dans un style registry pour la conformité réglementaire.
  • Les données financières seraient traitées dans un style transactionnel pour remplacer les feuilles de calcul Excel et pour supporter des workflows de saisie et de validation.

Le choix d’un style n’est pas une décision technique. Il doit être conduit par les besoins du métier. En outre, ce choix n’est pas gravé dans la pierre. Il évolue au fil du temps. Par conséquent, le hub doit prendre en charge tous ces styles de manière native. Une telle plate-forme multi-styles se définit comme un Hub de Convergence.

Typologie de Hub MDM: Convergence

Semarchy Convergence 1.3 a été spécialement conçu non seulement pour supporter toutes les typologies de hub, mais également pour fournir un cadre global permettant de mélanger ces typologies – Registry, Consolidation, Coexistence et Centralisé/Transactionnel – au sein du même hub. Cette différence simple mais fondamentale permet une vraie implémentation de MDM Évolutionnaire™ qui évolue dans le temps au rythme des besoins du métier.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *