Point de départ :

Imaginons une filiale E.T. possédant 100 agences en France qui décide, pour des besoins de gouvernance, de maîtrise de sa donnée et d’amélioration de ses services, de connaître l’ensemble de ses clients au sein du groupe.
Chaque agence possède sa propre base client. Le problème est qu’il arrive parfois que les agences rentrent en concurrence entre elles car elles n’ont aucune visibilité sur le référentiel client de l’agence voisine. Au-delà d’engendrer des efforts humains inutiles, cela décrédibilise l’action de démarchage mais aussi de relation auprès des clients de la société. Elle souffre, qui plus est, d’une qualité moyenne de ses données de références dans certaines de ses agences.
Le point de départ est donc le besoin de faire converger plusieurs référentiels existants ayant la même valeur métier au sein du SI.

Objectif :

L’objectif est de traduire ce besoin de convergence par la mise en place d’un référentiel unique de données clients, d’améliorer la qualité de ces données et de pouvoir les redistribuer au sein des différentes agences et/ou applications du SI. Dans notre cas, la filiale souhaite utiliser le MDM[1] OneData fourni par Software AG.
Ce principe de convergence est appelé d’un point de vue « analyse de donnée » et par l’application, consolidation. Cette consolidation comprend plusieurs étapes :

1) Acquisition de la donnée :

L’entreprise nous fournit une source de donnée par agence, par fichier plat CSV (phase d’initialisation par BATCH) dans un premier temps, puis en mode fil de l’eau par message JMS dans un second temps. Dans les deux cas, un projet de mapping sera à créer avec les objets métiers OneData.

2) Nettoyage de la donnée :

La donnée doit être nettoyée, on parle d’étape de « cleansing ». Pour cela, nous avons la possibilité de créer un projet de cleansing directement dans OneData, qui sera appliqué à un ou plusieurs champs de notre objet métier, par exemple supprimer tous les caractères non alpha-numériques de la raison sociale de notre client, tout mettre en majuscule… d’autres règles de nettoyage peuvent être mises en place en faisant appel à des services de l’Integration Server webMethods.

3) Dédoublonnage :

Le dédoublonnage correspond à l’étape de « matching ». L’enregistrement consolidé sera soit :

• Créé comme nouvelle donnée de référence.
• Lié automatiquement à un client déjà existant dans le MDM.
• Laissé en statut « nettoyé/non assigné » et fera l’objet d’un matching manuel.

Pour cela, comme pour le projet de « cleansing », un projet de « matching » devra être créé pour définir les champs sur lesquels nous allons appliquer des règles de correspondance à partir de nos données de références déjà présentes dans le MDM. Des seuils pour définir les paliers entre création, matching et manual-match, seront définis. L’action sera menée en fonction du score obtenu lors du processus de « matching »,à savoir que pour chaque type de champ, nous pouvons également appliquer des algorithmes différents : Jaro-Winkler, Levenshtein, Damerau-Levenshtein… en fonction de nature de la donnée (adresse, numéro de téléphone, raison sociale,…) afin d’améliorer nos chances de matching.

4) Enrichissement :

Une fois notre client nettoyé, dédoublonné, il est possible d’appliquer un enrichissement de la donnée de référence (compléter notre client avec son siret ou sa géolocalisation par exemple). Cet enrichissement peut-être défini directement dans l’outil OneData qui dispose de sa propre base d’enrichissement Locate (fichier plat fourni avec l’outil et mis à jour régulièrement via l’UpdateManager webMethods). Des liens avec des prestataires externes peuvent également être mis en place (des appels via webservice déclenchés par des services IS comme pour le « cleansing »).

5) Partage de la donnée :

Une fois notre base de référence mise à jour, comme pour l’étape d’acquisition de données, il est possible de distribuer l’information de plusieurs manières : fichiers CSV, JMS,… Cette redistribution permet donc à notre filiale de récupérer des informations clients propres au sein de son SI.
Chacune de ces étapes pourra être détaillée lors des prochains articles OneData.

Avantages :

• Multiples connecteurs pour acquisition et distribution de la donnée.
• Puissance de correspondance une fois les projets de cleansing et matching bien définis.
• Enrichissement des données inclus dans le produit.

Contraintes :

• Bien connaître le niveau de qualité de données avant consolidation afin de créer les règles de matching les plus précises possibles.
• Bien que cela offre plus de flexibilité, la procédure de manual-match peut être assez complexe et lourde à mettre en place si l’on n’utilise pas les fonctionnalités natives (en utilisant du BPM avec des écrans CAF par exemple).
• Ergonomie de l’outil à améliorer.

[1] Master Data Management