A l’heure du customer-centric, le Référentiel Client Unique (RCU) est au coeur des projets d’entreprise.. Véritable pierre angulaire de la vision 360°, le RCU peut se résumer à une application qui contient l’unicité de l’identité de vos clients. Cependant, par expérience nous constatons que le plus souvent les données clients sont disséminées au sein du SI de l’entreprise et absolument pas centralisées entraînant :
- de très nombreux doublons,
- un manque de complétude,
- un risque majeur d’avoir des données disparates.
Plus qu’un simple projet data, la mise en oeuvre d’un RCU doit s’envisager comme un projet “vivant” à démarrer simplement et rapidement pour répondre aux premiers cas d’usages. Une fois validés, ils vont permettre de faire évoluer le RCU pour l’enrichir. Avec le temps, il pourra alors prendre une dimension centrale au sein de l’organisation data de votre entreprise. L’agilité est le maître mot pour envisager sereinement la réalisation d’un Référentiel Client Unique.
En d’autres termes : Démarrez simplement pour le déployer rapidement avant de l’enrichir progressivement !
Nous avons orienté ce premier article autour des pièges à éviter pour la mise en place de votre RCU en se basant sur nos retours d’expérience, qu’ils soient issus d’échange avec nos prospects ou vécus avec nos clients.
Tout imaginer tout de suite
A terme, votre RCU a pour vocation d’être le réceptacle de toutes vos données clients. Il doit devenir LE référentiel de la connaissance client, avec pour enjeux de mieux maîtriser et d’améliorer les relations avec vos clients. Un vaste objectif qui vous entraîne vers de nombreux et variés domaines d’application. Chacun de ces cas d’usage peut demander des efforts conséquents qui vont complexifier la mise en oeuvre de votre RCU.
Il est bien entendu clé de réfléchir à l’ensemble des usages cibles. Cette réflexion macro est nécessaire pour définir la roadmap globale de la réalisation. Cependant trop d’entreprises ont tendance à outrepasser cette vision macro en cherchant à tout prix à tout envisager dès la phase de conception : prévoir et spécifier tous les cas d’usages, envisager de centraliser tout de suite toutes les données disponibles etc.
Tous vos cas d’usage potentiels se trouvent dès lors embarqués au sein d’un seul et même projet protéiforme. Sa perception sera sans appel : une vision de sa mise en oeuvre qui apparaîtra à vos équipes longue, complexe et surtout coûteuse. Il n’est pas rare d’avoir des entreprises qui évoquent le sujets RCU pendant des années créant à la fois une inquiétude et une attente inassouvie. Le RCU devient une sorte de “serpent de mer” avec comme risque majeur de n’être que déceptif voire de ne jamais exister.
Il est alors recommandé de ne planifier qu’un ou deux use cases pour démarrer puis de progresser ensuite de manière incrémentale. Ce choix permet d’envisager une phase de conception et une première mise en oeuvre plus courte. Vous serez plus rapidement en mesure de livrer des premiers cas d’usages opérationnels à vos équipes. Cela permettra aussi d’avoir les premiers retours d’expérience pour enrichir et améliorer les usages existants et mieux appréhender les usages à venir. L’adoption du RCU au sein de vos équipes n’en sera que plus aisée.
Ne pas se tromper de cible : le vrai sujet d’un RCU, c’est la déduplication
Il ne faut pas oublier que la déduplication est la vraie valeur d’un RCU : dédupliquer les clients venant de vos différents systèmes. C’est la clé autour de laquelle vous pourrez bâtir vos cas d’usage et leur apporter la valeur attendue.
Référentiel Client UNIQUE, la terminologie est claire, c’est à partir du RCU que vous serez en mesure de connaître individuellement chacun de vos clients. Il s’agit bel et bien de l’objectif premier de ces projets.
Tout d’abord, il est nécessaire de gérer toutes les sources de données clients puis de traiter la déduplication (sur la base d’une dizaine de champs à comparer comme le nom, le prénom, l’email…etc).
Ensuite, il faut déployer une solution de visualisation de la donnée afin de visualiser :
- les données clients rapprochées,
- les ordres de grandeur métriques essentielles et importantes (par exemple, le nombre de clients, nombre d’emails…etc).
Ce n’est qu’ensuite que vous pouvez prévoir d’ajouter les KPIs à calculer et à enrichir pour traiter vos premiers cas d’usage (rarement plus de 30 KPIs sont nécessaires).
La mécanique de mise en oeuvre du RCU est alors à votre disposition et surtout vous avez défini et testé l’algorithme qui permet de rapprocher les contacts d’une même source ou de différentes sources. Le socle de votre RCU est alors opérationnel.
Vous pouvez ainsi profiter des premiers bénéfices, directs, réels, et mesurables d’avoir des données clientes saines et dédoublonnées ainsi que du retour d’expériences de vos premiers cas d’usage. Ce sont autant d’éléments nécessaires pour enrichir et améliorer votre RCU en vue des cas d’usage à suivre (nouvelles sources de données, nouveaux KPIs, différentes formes d’exposition de vos données…etc).
Vigilance sur vos sources de données !
Quelque soit le niveau de maîtrise de vos données, dans la réalité des projets data et des entreprises, une source de donnée n’est jamais si évidente et immédiate à “brancher” sur un nouveau système, surtout quand le principe même du système est de pouvoir intégrer toutes vos sources de données.
Pour certains, une source des données est un simple fichier CSV pour d’autres plusieurs fichiers XML ou encore une source de données correspond à plusieurs fichiers qu’il faut pouvoir réconcilier.
L’expérience des projets d’intégration de données montre qu’il existe toujours un nombre de flux, de fichiers, d’APIs supérieurs et/ou plus complexes que prévu.
Aux flux à traiter, il faut ajouter la qualité même de vos données qui peuvent avoir un impact fort sur la manière de les ingérer dans un RCU. Par exemple, la gestion d’un pays associé à un contact peut être pertinente pour “normaliser” un numéro de téléphone (mis au format international) mais peut-être que vos sources ne possèdent pas cette information ou alors que sa normalisation est différente d’une source à une autre (codification sur 2 ou 3 caractères, plus ou moins personnalisée…etc). Il est donc important de pouvoir regarder les données de chaque système pour étudier les règles d’ingestion à prévoir et éviter les pièges.
Cette phase de traitement de la donnée amène, à terme, à manipuler la totalité des données clients de l’entreprise. Il peut rapidement émerger certains sujets qui avaient (peut-être) été “laissés sous le tapis”.
Ce sont les principes fonctionnels qui doivent vous guider ; traiter d’un coup tous les éventuels problèmes de data de votre SI sera long et fastidieux.
Pour pallier à ces risques, il est essentiel et primordial :
- de vérifier, en amont du projet, les champs utiles à la déduplication et les règles de valorisation de ces champs dans vos systèmes sources pour anticiper les problèmes lors de l’ingestion,
- de traiter les données sources par sources en fonction des cas d’usage (gestion des KPI),
- que les responsables des données sources soient parties prenantes du projet RCU ; et pas seulement quand ils ont un peu de disponibilité mais comme de vraies ressources embarquées sur le projet de réalisation,
- que la recette commence à l’ingestion, dès que sources sont disponibles pour vérifier d’ores et déjà leur bonne ingestion.
Initialiser votre RCU
A la fin de votre projet RCU, vous allez devoir procéder à la phase d’initialisation de ce dernier. Vous allez, alors, devoir ingérer toutes les données de vos sources sur X années. Cette initialisation est nécessaire pour avoir une première version de votre RCU.
Il est important lors de cet import initial des données, de prendre en considération que les différentes sources peuvent avoir des historiques différents ou encore porter des règles différentes au niveau RGPD.
La profondeur d’historique peut avoir un impact conséquent sur la stratégie d’initialisation des données et donc sur l’ingestion (qui est pourtant traiter en début de projet). Les sources n’ont pas toujours la même profondeur d’historique.
De même, la RGPD peut imposer des choix dans le traitement de cette historique et des KPIs associés.
Par exemple, il n’est globalement pas possible de stocker des transactions au delà de 3 ans ; alors pourquoi chercher à tout prix à remonter 10 ans d’historique de tickets de caisse ?.
Il est donc primordial de réfléchir à la stratégie d’initialisation des données en amont du projet pour connaître les impacts sur l’ingestion et sur le calcul des KPIs.
Il convient de faire le point sur les besoins en terme de KPIs et de RGPD pour définir la profondeur d’historique nécessaire.
L’impact peut être conséquent sur le volume des données et donc sur la performance et les temps de traitement de la donnée ; deux points qui peuvent avoir des impacts budgétaires non négligeables.
Et surtout, ne pensez pas qu’en une semaine vous aurez initialisé votre RCU de manière définitive. Une initialisation sera faite à plusieurs reprises (pour pallier au correctif, aux éventuels problèmes des données sources…) et ce n’est pas grave. Plus le processus qui gère cette initialisation aura été automatisé, plus il sera facile de la refaire : Le temps de bien intégrer toutes vos données.
Ne sous estimez pas les temps de vérification
Comme souvent dans les projets Data – voire dans tous les projets informatiques et encore en 2020 – cette phase est généralement sous-estimée bien qu’elle soit critique pour l’ensemble du projet.
Il est important de se poser avant le démarrage les questions suivantes :
- Qui est responsable de cette phase, quel est son profil (plutôt métier ou plutôt technique) ?
- Si le profil est plutôt métier, ne pas oublier un outil visuel pour aider à “voir” les données,
- Si le profil est plutôt technique, il optera probablement pour des requêtes SQL à titre de recette.
Mais recetter un RCU, c’est aussi :
- Vérifier les règles d’ingestion,
- Vérifier la déduplication,
- Recetter le calcul des KPIS,
- Tester la chaîne de traitement sur des volumes de données importants et volumineux.
La recette démarre dès le début de projet !
Les premiers tests doivent impérativement se faire à partir de jeux de données qui ne peuvent pas se baser sur vos données réelles. Il est nécessaire de créer des fichiers de tests avec des données fictives pour vous permettre de prévoir les différents cas de figure en fonction des règles retenues (ingestion), de l’algorithme développé (déduplication) ou des règles de calculs (KPIs). Démarrez par les cas simples et classiques puis traitez les cas plus complexes tout en sachant mettre des limites à vos cas de test. Attention aux cas qui n’arrivent qu’une fois sur 1.000.000 ! La déduplication n’est pas parfaite et elle ne le sera jamais. Ainsi, chercher à traiter tous les cas possibles et envisageables est voué à l’échec.
Une fois la recette effectuée sur des jeux de tests, des tests supplémentaires sont à effectuer sur les données cibles à partir d’un RCU initialisé.
Il est peu probable, qu’une fois le RCU initialisé il soit possible de valider chacun des contacts mais il est important de définir une série d’indicateurs et de métriques qui permettent de s’assurer de la qualité globale du RCU :
- lancer l’initialisation année par année, avec pourquoi pas des tests plusieurs fois sur la même année pour vérifier que les résultats soient cohérents,
- compter le nombre de lignes client en entrée pour chacune des sources et le nombre de lignes en sortie,
- compter le nombre d’emails par contact et comparez-le à votre source la plus fiable sur les emails,
- prendre un échantillon de clients et suivre leur traitement dans chacune des phases ; ingestion, déduplication, calcul des KPIs.
Ces tests de validation du RCU sont complexes et demandent un fort investissement (préparation, temps des tests…etc). Ils est impératif de les prendre en considération très tôt dans l’organisation du projet (en particulier, pour préparer les fichiers de tests) et ils doivent s’articuler autour d’une petite équipe qui pourra lui être dédiée.
Identity : Le RCU pré-packagé par Ysance
Ces derniers années, Ysance a développé de nombreux projets RCU et a décidé il y a 18 mois de créer un RCU générique, pré-packagé qui contient le code, les algorithmes, le modèle d’architecture cloud et la méthode de projet… permettant ainsi à une entreprise de bénéficier d’un core-model puissant et éprouvé, hébergé dans son propre environnement cloud. Les entreprises accèdent ainsi au code source et peuvent démarrer plus sereinement ces projets vus souvent comme complexes.
Identity permet de réduire ainsi les risques d’un projet RCU tant fonctionnels que techniques. Il comprend une couche d’ingestion simple et paramétrable pour traiter autant de flux et colonnes que nécessaires. Architecturé pour le Cloud, il est conçu pour s’intégrer sur vos stack logicielles et vos contraintes de sécurité.
Un nombre de KPIs prédéfini qui permettent d’assurer le coeur d’un RCU : la déduplication.
Les besoins spécifiques peuvent alors être adressés au cas par cas en fonction des use cases à mettre en oeuvre. L’existence d’un socle déjà éprouvé permet de limiter les risques et le temps à passer sur la partie recette pour permettre à nos clients de se concentrer sur l’essentiel : leur besoin et le traitement des use cases pour faire évoluer le socle au besoin.
Conclusion
Nous espérons que ces retours d’expériences et différents conseils vous éclaireront et vous permettront envie de réaliser votre projet avec plus de sérénité et en mode agile.
À suivre
Au cours d’une série d’articles, nous reviendrons sur plusieurs thématiques autour de la mise en oeuvre de tels projets, qui sont si structurants pour les entreprises à l’heure du customer-centric.
Guillaume M. Delivery Manager, a piloté près de 15 projets RCU chez des clients de toutes tailles. Il anime de nombreux webinars à ce sujet.
