Le référentiel Personnes est au centre de la gestion de la relation client et de la gestion des risques.
A l’heure où les systèmes CRM deviennent la tour de contrôle du SI devant les applications de gestion, la fiabilité du référentiel prend une nouvelle importance.
C’est quoi le problème ?
Si le besoin semble simple à définir :
« Je veux centraliser la liste de mes clients, leurs coordonnées et leurs contrats et constituer un référentiel unique, maitre sur celui des applications de gestion »,
la mise en œuvre semble particulièrement compliquée pour les organisations qui s’y lancent.
Le poids de l’histoire de l’entreprise et de ses SI historiques pèse sur le projet et rend difficile jusqu’à l’identification exhaustive des référentiels à unifier.
Dans les groupes issus de rachats et de fusions, il n’est pas rare que plusieurs applications couvrent le même pan fonctionnel, parfois même avec des équipes de gestion différentes.
Une segmentation par produit existe également souvent, liée à la couverture des applications de gestion et leur capacité à intégrer rapidement un nouveau produit.
Ainsi, la première tâche consiste à identifier TOUS les référentiels utilisés.
Bien souvent, on néglige cette étape fondamentale pour se précipiter vers la mise en œuvre d’une solution ou d’un outil. Il sera compliqué de mettre en œuvre une solutions complète si on n’a pas considéré l’étendue du projet. Il sera facile de passer à côté d’un point critique qui au mieux retardera la mise en œuvre.
Identifier TOUS les référentiels utilisés
L’armée des clones
Les doubles dans les systèmes d’informations sont légion. Dans les systèmes bien gérés, on peut considérer qu’ils représentent environ 5%. Cela peut monter à plus de 30% pour certains systèmes.
Les doubles sont parfois légitimes et liés aux limitations d’applications anciennes dont la conception initiale n’avait pas pris en compte la possibilité pour un client d’avoir plusieurs contrats. J’ai souvenir d’avoir migré des systèmes d’assurance de personnes où l’identifiant de l’assuré était le numéro INSEE. Les gestionnaires contournaient cette limitation en modifiant la clé du numéro INSEE (Le contrôle sur la clé avait été levé) afin d’être en mesure de créer un nouveau contrat pour une personne qui en avait déjà un ou plusieurs.
Parfois les doubles sont délibérément créés par les gestionnaires eux-mêmes. J’ai en tête l’exemple d’une banque dans laquelle des chargés de clientèle avaient créé des doubles pour ouvrir plus d’un PEL… Parfois, ce sont les clients qui biaisent : nous avons rencontré des cas semblables lors de fusion bancaires où on découvrait qu’un même client possédait plusieurs PEL dans plusieurs banques du même groupe.
Sachant que l’on ne peut légalement posséder plus d’un PEL, on voit bien dans cet exemple, que le dédoublonnage et la mise en œuvre d’un référentiel unique peuvent avoir des impacts métiers inattendus.
Ainsi, un état des lieux des doubles en base, par référentiel de chaque application et de manière globale est à réaliser très tôt pour mesurer l’étendue des dégâts et cadrer le projet en toute connaissance de cause.
Faire un diagnostic doublons sur chacun des référentiels existants et globalement
Cette opération n’est pas si simple. Il ne suffit pas de comparer les noms, prénoms, dates de naissance. L’expérience montre que ces informations ne sont pas totalement fiables. Un contrat ouvert sous un nom d’épouse sera difficilement rapproché d’un contrat ouvert sous un nom de jeune fille. Les noms composés ou à particule sont rarement saisis de manière uniforme. Etc…
Il est donc nécessaire de mettre en œuvre des algorithmes de phonémisation et d’utiliser toutes les informations dont on dispose pour affiner la mesure. Ainsi, on ajoutera à l’équation l’historique des téléphones, des mels, des RIB et celui des adresses. Pour les adresses, il sera nécessaire de les normaliser sur le référentiel postal pour avoir une comparaison discriminante.
Dans tous les cas, il y aura des zones de doute où l’utilisateur devra trancher. Nous y reviendrons.
Et les personnes morales ?
Quand on parle de personnes, on pense tout de suite à personnes physiques. Mais le sujet est le même pour les entreprises avec des difficultés complémentaires : Une entreprise peut changer de nom, de SIRET, être TUPée (fusion) avec une autre etc…
Il conviendra donc de garder cela en tête et de mettre en place un système qui tiendra compte de ces difficultés d’identification.
Les flux et les reflux
Dans un système d’information complexe, il existe de nombreuses interfaces entre les applications et avec l’extérieur.
D’importants flux de données circulent pour synchroniser les applications. Les données référentielles locales font largement partie des données synchronisées.
C’est donc sur un système complexe, cyclique voire parfois chaotique, d’échange d’informations que l’on a l’ambition de poser un référentiel maître qui devra imposer sa loi.
Il est nécessaire de référencer tous les flux existants avant d’aller plus loin
Un anneau pour les gouverner tous
Un des objectifs du référentiel unique est de permettre de diminuer les actes de gestion. Lors d’un changement d’adresse, de coordonnées ou de RIB, on pourra souhaiter propager ce changement dans tous les systèmes de gestion.
Là encore, un exemple vécu à partager avec vous : Toujours dans la banque et après une campagne de dédoublonnage ayant pour objectif de regrouper les courriers pour réduire les frais d’affranchissement (c’était avant internet je l’avoue), quelques clients ont eu des problèmes conjugaux quand le conjoint a découvert des comptes dont ils n’avaient pas connaissance…
Aujourd’hui, dans les systèmes modernes, les adresses sont en principe gérées au niveau du contrat. Il faut tenir compte des préférences de chacun des clients : certains voudront tout centraliser à leur résidence principale, d’autre recevoir à leur résidence secondaire ce qui concerne celle-ci. Idem pour les RIB. Chacun gère son budget comme il l’entend.
Ainsi une modélisation des préférences des clients sur l’ensemble des axes de propagation des informations que l’on envisage est impératif.
Modéliser les préférences des clients sur la mise à jour automatique
Alors on fait comment ?
La bonne approche nous semble être de collecter en amont de la réflexion, l’ensemble des informations nécessaires à l’élaboration de la solution.
Ensuite, il faut considérer que le système ne sera jamais parfait et en tirer les conclusions.
Un META REFERENTIEL qui agrège comme « personne unique » tous les identifiants des référentiels périphériques parait la meilleure solution.
On ne cherche pas à forcer systématiquement les référentiels périphériques, on pilote leur cycle de vie.
Un moteur de règle de mise à jour s’appuiera sur ce référentiel central et sur les préférences des clients pour propager les informations qui doivent l’être.
Bien sûr, on historise toutes les modifications en conservant les anciennes valeurs et la règle responsable de la mise à jour. Cela servira plus tôt qu’on ne le pense.
Ce mode de fonctionnement permet de fiabiliser les référentiels périphériques au fil de l’eau, de manière disjointe avec pour seul impact sur le Méta Référentiel, le fait de mettre à jour les informations relatives aux référentiels périphériques fiabilisés au sein de celui-ci.
En outre, On s’affranchira ainsi des problématiques de collision de planning entre le projet de référentiel central et les éventuels projets sur les applications métier.
Mettre en œuvre un META REFERENTIEL qui agrège les identifiants des applications périphériques et les préférences de mises à jour automatiques des clients.
La logique c’est flou
L’initialisation du référentiel est une étape critique qu’il est nécessaire d’optimiser. Une validation manuelle systématique n’est pas envisageable sur tous les dossiers. Le gestionnaire passerait en effet trop de temps à valider des doublons évidents ou invalider de faux doublons là aussi rapprochés à tort de manière évidente.
La logique de rapprochement que nous utilisons est une logique floue. C’est-à-dire que nous constituons des groupes de doublons potentiels et y associons une probabilité de vraisemblance. On règle les seuils de contrôle manuel. On pourra choisir par exemple, de valider automatiquement les groupes au-delà de 77% de probabilité et d’invalider automatiquement les groupes au-dessous de 51%.
Le paramétrage de l’outil de rapprochement est parfois assez fin car il nécessite de pondérer spécifiquement les différents critères de rapprochement en fonction de leur présence ou non dans les bases et de leur date de fraicheur si on dispose de cette information.
Mettre en place des procédures automatiques à chaque fois que cela est possible.
L’arbre qui cache la forêt
On nous cite souvent des exemples de faux doublons : Même nom et prénom et même adresse ou presque. Certes, de tels cas peuvent exister mais ils sont rares. Faut-il mettre en place une procédure manuelle systématique de validation pour quelques cas ? La question mérite d’être posée, la réponse dépend de la tolérance aux erreurs que l’on s’accorde.
Dans tous les cas, il est sage de prévoir un processus de correction des erreurs.
Un Méta Référentiel permettra de corriger facilement une erreur . Il « suffira » de supprimer le lien entre les identifiants des personnes rapprochées à tort. Si les règles de mise à jour ont été correctement implémentées, les flux devraient propager correctement les corrections. Par sécurité, on pourra prévoir de forcer la mise à jour en mode contrôlé par le gestionnaire et de tagger les personnes comme « faux doublons ».
Peser les cas particuliers pour définir les processus. Enregistrer les exceptions aux règles automatiques.
Attention aux données financières
De manière évidente, on sécurisera la mise à jour des données financières des clients pour éviter des prélèvements à tort, remboursements indus ou usurpation d’identité. La mise à jour d’un RIB devra faire l’objet d’une procédure sécurisée.
En conclusion
La mise en œuvre d’un référentiel personnes est un projet complexe, dont la mise en œuvre dépend fortement des particularités des applications et processus métiers en place, ainsi que des flux existants au sein du SI. Il est nécessaire de collecter en amont toutes les informations permettant de prendre les bonnes orientations. Il faut avoir en tête que l’on ne pourra sans doute jamais atteindre 100% de fiabilité. La solution doit donc être tolérante aux erreurs et permettre aux différents projets métiers en cours ou à venir de vivre leur vie sans impacter les autres.
Je profite de l’occasion pour signaler que nous disposons d’outils de dédoublonnage puissants et du savoir-faire de mise en œuvre.
Ces outils sont adaptés pour les études préalables, la constitution du référentiel et sont disponibles sous forme de modules pour intégration dans vos chaines de mise à jour.
Comme toujours chez Move, pas de coût de licence si nous réalisons le projet…
Image par Reimund Bertrams de Pixabay
