L’essor du terme B2B2C est le marqueur d’une tendance de fond : il est de plus en plus nécessaire de s’intéresser pas seulement à son client direct mais également à l’écosystème qui l’entoure, en particulier, aux clients de son clients. Mais voilà, toutes les DSIs n’avaient pas prévu le coup et les systèmes d’informations peinent bien souvent à faire rentrer cette notion sans forcer. Je vous propose aujourd’hui un panorama des modèles qui peuvent être mis en place pour structurer sur le tard la « connaissance client ».

Connaissance client : Construire un référentiel quand on part de rien

Par connaissance client, nous désignons ici les informations d’identité, de coordonnées, de contexte, d’usage et d’historique qu’une entreprise est en mesure de capter sur un client ou consommateur. Dans le cas idéal, cette information a été modélisée une bonne fois pour toute et l’ensemble des applications ont utilisé le même modèle (on parle parfois de Modèle Objet Métier, MOM).

Note : ce propos s’applique également à d’autres types de données mais de notre expérience, c’est sur la notion de client que les choses sont souvent les plus compliquées.

L’eldorado, le référentiel client centralisé, le vrai

Dans ce cas, on peut mettre en place un « vrai » référentiel. Cette brique centrale détient les données de référence sur tous les clients de l’entreprise (ou les clients des clients). Il attribue à chacun un numéro unique qui permet à toutes les autres applications de l’identifier sans ambiguïté. Il est propriétaire des données : si une application veut créer ou modifier un client, elle en fait la demande au référentiel et ce dernier répercute sur l’ensemble des applications la mise à jour. Le tout, en temps réel si besoin, s’il vous plait.

Dans le modèle d’un référentiel centralisé, une application demande une modification et toutes en bénéficie

Construire ce référentiel client est simple lorsqu’on s’y prend assez tôt. Mais que faire alors quand cette notion de client n’a pas été modélisée et partagée assez tôt ? Après tout, un outil de production peut fonctionner en exécutant seulement des ordres de fabrication, un outil logistique en gérant seulement des adresses de livraison, et un SAV sans historique des interactions avec le client… ils feront un job moyen, mais ça peut suffire au début. Que faire quand le coup est parti et que toutes les applications ont déjà leur modélisation partielle et mutuellement incompatibles ?

Je pourrais vous dire qu’il faut tout refaire mais honnêtement, à part que ça fait vivre les consultants, je pense que c’est une prise de risque énorme pour un gain difficile à quantifier dans un dossier de go/no-go. Si vous avez déjà prévu de refaire l’application X ou Y, alors oui pour y intégrer au passage une exigence de cohérence avec le modèle et les SI client mais sinon… Alors que faire quand il n’y a RIEN et que tout va MAL ?

Premier baby step vers la connaissance client : la base de consolidation

Il s’agit ici de rassembler en un endroit l’ensemble de la connaissance client. Pour en faire quoi ? Bah, à ce stade, rien d’autre que la regarder, et c’est déjà pas mal. Ça intéressera particulièrement un SAV ou un accueil client d’avoir accès à l’historique de la relation. Ça intéressera aussi le marketing de pouvoir estimer l’efficacité de ses campagnes.

Cette base se compose nécessairement :

• d’un mécanisme d’alimentation (l’ensemble des applications viennent copier leurs données quelque part dans cette base),
• d’un mécanisme de mise en qualité (ce numéro de portable commence par 01… il est probablement mal rangé),
• d’un mécanisme de rapprochement (en partant du principe qu’il n’y a pas d’identifiant unique partagé par tous les SI, il va falloir faire des comparaisons a minima entre les identités & coordonnées des clients pour tenter de reconstruire toutes les facettes d’un client),
• d’un mécanisme de consolidation (ok, vous avez trouvé 3 sources de données qui concernent un même client… mais si son prénom n’est pas écrit pareil dans l’une des 3 sources, on fait quoi ?),
• d’un mécanisme d’exposition… pour que des portails puissent venir piocher dans ces données.

La base de consolidation rassemble simplement toutes les informations client disponibles au sein de l’entreprise

Notons qu’à ce stade, il n’est pas question de rediffuser l’information mise en qualité, juste de le visualiser dans un portail.

Deuxième pas de géant : immatriculer et diffuser des données de qualité

Une fois que vous avez développé un algorithme de rapprochement & consolidation fiable, vient le moment délicat où il faut appuyer sur le gros bouton rouge, et commencer à renvoyer des données aux autres applications. Deux types d’informations peuvent être avantageusement rediffusées :

1. Un identifiant client unique… bah oui ! Sans vous en rendre compte, avec cette alimentation et cet algorithme de rapprochement, vous avez toutes les informations en main pour dédoublonner les informations client et produire LA LISTE des vrais clients… et leur coller un numéro. En faisant ça, vous venez de construire les routes que l’application A et B pourront utiliser pour échanger des informations client sans solliciter cette base centrale… à condition que ces applications détiennent une information de suffisamment bonne qualité
2. Ce qui nous amène à 2 : pour toutes les données pour lesquels aucun SI ne possède un niveau de fiabilité suffisant… et bien votre base de consolidation, elle, possède ce qui se fait de mieux puisqu’elle a rapproché et consolidé tout ce qui existe. Ainsi, si le nom de famille n’est complet ou fiable qu’à 70% dans chacun de vos SI pris séparément, il est probable que dans la base de conso, ce taux soit bien plus élevé.

Si ça n’est pas le cas, alors il faut retravailler sur les algorithmes de consolidation, ou alors intégrer des sources externes de données pour booster le niveau de qualité et de complétude… pour alors mettre en place du data stewardship (fancy word pour dire que des humains ont explicitement la responsabilité d’organiser la mise en qualité les données).

Référentiel décentralisé : tout est rangé mais pas au même endroit

Si vous avez fait ça, vous avez ce qu’on appelle un référentiel décentralisé. Chaque information est rangée quelque part (même si ça n’est pas dans une base unique) et est accessible facilement (via votre id unique !).

Le dernier pas est un vrai marathon, à la vitesse du 400 m

Récapitulons : si vous avez réalisé le contenu des 2 derniers paragraphes, vous avez, malgré une très mauvaise organisation initiale de vos données client, un base dans laquelle l’ensemble des données sont accessibles (mais peut-être pas les données créées le jour même), vous avez un identifiant unique qui permet à 2 applications de partager leurs infos sur un client pour répondre à un cas d’usage précis et vous avez une démarche de mise en qualité des données (là encore, peut-être pas en temps réel).

Vous l’aurez compris, ce qui vous manque c’est le temps réel, ou une fraîcheur suffisante pour les usages : à quoi sert de savoir le produit acheté par un client trois jours après que le SAV a traité sa demande ?

Si un nouveau client ou prospect appelle un de vos services le matin et un autre l’après-midi, les deux applications vont créer un client et votre système central d’immatriculation ne saura peut-être pas retrouver pour le deuxième le numéro qu’il a donné au premier…

Comme ça, ça a l’air très spécifique, mais dès qu’on possède plusieurs services proposés par plusieurs entités de l’entreprise entre lesquelles on tente de créer des synergies, ça vient assez vite.

Pour vraiment franchir ce dernier pas du temps réel, il faut hélas, lancer un programme complet qui repart de 0 dans la construction d’un référentiel technologiquement prévu pour faire du transactionnel synchrone en haute dispo (c’est à dire du temps réel disponible pour tout le monde tout le temps). Mais, courage, tout cela n’était pas en vain : la mise en place de cette base de consolidation et de cette immatriculation ont permis à l’entreprise de gagner en maturité et lui a donné des chances de réussir ce chantier fondamentalement compliqué.