par Introduction
"Vous avez un problème de référentiel" est surement la phrase que j'ai la plus prononcée au cours des dix dernières années de conseil en SIRH et stratégie de données.
Quelle que soit la taille de l'organisation, quel que soit le projet, quelles que soient les technologies mises en œuvre, les défauts de référentiels généraient des problèmes, parfois vraiment fâcheux.
Pour faire simple, les référentiels sont le langage commun entre toutes ces applications. Ils assurent que la même information pourra être comprise et interprétée de la même manière partout. Chaque référentiel est stocké dans une base de données bien identifiée et unique, où les applications peuvent le retrouver chaque fois qu'elles en ont besoin d'informations à jour.
C'est pourtant une problématique mal comprise
C'est un sujet rébarbatif, complexe et dont la mise en œuvre induit des notions techniques avancées et les professionnels des RH ont parfois du mal à s'en saisir. Et pourtant, il est très important que les métiers soient parties prenantes dans la conception et l'animations des référentiels RH et non RH.
Pour comprendre la nécessité et la valeur des données de références, il faut regarder l'écosystème SIRH dans son ensemble (cf notre premier article Du SIRH à la Data RH (adp.com)) et considérer la gestion de la donnée tout au long de son cycle de vie (cf Le cycle de vie de la donnée RH (adp.com)).
Il faut également préciser que les référentiels existent pour aider les machines et non les humains ; ce sont de grandes listes en partie constituées de codes difficilement interprétables pour les métiers RH et demandant des compétences en tableur Excel ou autre pour être exploitées.
Les libellés sont pour les humains et les codes sont pour les machines.
Mais très couteuses
Le problème des référentiels, c'est que la moindre erreur va se répercuter partout dans les systèmes et l'organisation. les pertes de temps, de sécurité et de fiabilité peuvent être colossales à long terme.Et plus y a d'applications qui communiquent entre elles, plus les problématiques de référentiels deviennent critiques : dans les grandes entreprises, on parle de plusieurs millions d'euro par ans consacrés uniquement à la mise en œuvre et le maintien des référentiels RH.
Les symptômes :
Concrètement, les défaillances dans les référentiels se traduisent de diverses manières partout dans l’organisation et peuvent être masquées au sein du grand sujet de la qualité des données.
Il faut étudier chaque cas en détail pour mettre en évidence les erreurs de référentiels et mesurer leurs impacts sur les autres processus.
Un bon indicateur, bien connu des utilisateurs d'Excel, est la fréquence d'utilisation de la fonction "RECHERCHEV" (ou VLOOKUP en anglais). Le fait, pour les métiers RH, d'avoir à effectuer souvent ce type de traitement pour aligner plusieurs listes issues de plusieurs fichier est clairement un signe que les référentiels associés ne sont pas optimaux.
Les Référentiels RH et non RH
Les référentiels couramment consommés par les applications SIRH sont relativement peu nombreux. Ils sont à la fois complexes à mettre œuvre et à maintenir à jour.
Ils sont par ailleurs hautement stratégiques car ils décrivent l'organisation, la hiérarchie, les emplois, les compétences, les contrats, les collaborateurs, les formations, les établissements…
Ainsi les référentiels sont fortement liés à chaque entreprise et difficilement transposables dans un autre contexte.
Qu'est-ce qu'un bon référentiel ?
On définit 5 axes pour définir la qualité d'un référentiel :
Une problématique courante : Les référentiels concurrents
Pour des raisons souvent historiques, parfois sans réel fondement et toujours par facilité, plusieurs Référentiels coexistent à divers endroits de la structure.
- Des référentiels locaux : les référentiels peuvent n'avoir été construits que pour une petite partie de l'organisation. C'est souvent le cas lorsqu'une entité a été rachetée.
- Des référentiels par activités : Les entreprises peuvent avoir plusieurs grands domaines d'activités très différents les uns des autres : métiers différents, organisations différentes, processus de validation différents…
Ce sont des référentiels privatifs qui fonctionnent de façons concurrentes.
D'un point de vue local, ces référentiels peuvent sembler bien adaptés aux besoins et convenir.
D'un point de vue système ou macroscopique, les référentiels privatifs sont à proscrire
La solution courante pour faire coexister deux référentiels consiste à mettre en place et entretenir des tables de correspondances mais c'est une solution qui n'est pas viable dans le temps.
Idéalement, il faut aligner les référentiels concurrents :
La Golden Source
Pour être sûr que toutes les applications aient la même information au même moment, elles doivent toutes aller la chercher dans une base de données unique (la GOLDEN SOURCE).
Lorsque la mise à jour des données référentielles dans une application est automatisée, on dit que cette application est ASSERVIE au référentiel.
La Golden source et les données référentielles doivent être "sacralisées".
Les données référentielles ne doivent jamais être altérées par traitements à aucun niveau dans le SI.
La gouvernance doit être claire et partagée (cf La gouvernance de la donnée RH (adp.com))
Définir une gouvernance de données efficace et pérenne consiste avant tout à formaliser les réponses à des questions de bons sens :
- Qui a le droit de modifier la Golden Source ?
- Qui vérifie que les données sont intègres et à jour ?
- En cas d'anomalie qui doit prévenir qui, et comment ?
Evolutions : Base NoSQL et IA
Pendant longtemps, la structure des référentiels, quels qu'ils soient, a été formatée par la logique relationnelle des bases de données de type SQL (Structured Query Language).
Néanmoins depuis une dizaine d'années, des logiques de bases de données NoSQL, également appelées "non-relationnelles" se sont démocratisées et introduisent un degré de liberté supplémentaire dans les contraintes citées plus haut.
Autrement dit, les bases NoSQL simplifient grandement les choses mais deux points sont à considérer :
- La cohabitation entre bases relationnelles et non relationnelles :
Dans un écosystème SIRH, il va être de plus en plus courant de rencontrer ces deux logiques et de devoir les faire cohabiter.
Malheureusement, c'est la logique la plus contraignante, c’est-à-dire la logique SQL qui impose la logique générale, ainsi, il faudra encore longtemps réfléchir sur la base de référentiels communs, uniques, homogènes….
- Les logiques NOSQL se prêtent particulièrement aux interfaces applicatives API pour communiquer avec les autres applications. La multiplication des API peut facilement tourner au casse-tête sans une gouvernance rigoureuse et une documentation complète et à jour à tout moment.
Il y a également beaucoup à attendre des Intelligences Artificielles en matière de création, de structuration et de maintenance des référentiels : le rapprochement entre deux données non structurées, qui aujourd'hui ne peuvent être reliées que par un code, une "référence" peut désormais être déduit d'un contexte en levant les ambiguïtés.
L'usage de l'IA de manière "industrialisée" nécessitera néanmoins de prendre toutes les précautions vis à de cet outil en constante évolution.
Une culture DATA comprise et partagée
Pour conclure, investir dans les problématiques de référentiels est un investissement qui s'avère à la fois nécessaire mais également très rentable dans le temps.
Un investissement technique évidemment mais en général celui-ci a été déjà fait. Il reste à investir sur la formation et la sensibilisation de tous les acteurs qui interagissent avec les référentiels.
En effet, la plupart du temps, les référentiels peuvent être perçus comme une contrainte inutile ou mal comprise et ils sont maltraités par simple "ignorance". En outre, les utilisateurs savent rarement comment sont utilisées les données hors de leur périmètre fonctionnel.
De simples campagnes de sensibilisation vers tous les acteurs DATA, pour leur expliquer leur environnement et leur montrer leur place dans l'écosystème SIRH permet à tout le monde d'adopter les bons réflexes vis-à-vis des données, et encore plus sur les données de référence.