Data Governance Dictionary. Histoire d’une définition

J’ai trouvé les brèves informations suivantes:

« SAPETTES est un élément important de la civilisation Ardrit (voir) de la planète Enteropia (voir). Voir SAPETTARIUM. »

J’ai suivi ce conseil et j’ai lu:

« SAPETTARIUM – dispositifs de sapettage (voir). »

J’ai cherché « Sapettage »; ça disait:

« SAPETTAGE – l’occupation de l’ardrite (voir) de la planète Enteropia (voir). Voir SAPETTES. »

(Les voyages électriques d’Ijon Tichy, Stanisław Lem)

Grâce à mon travail, j’échange régulièrement avec différentes sociétés. Je vois beaucoup d’efforts sur l’amélioration de la qualité des données, la définition des processus métier ou encore la construction de DGDs de différents types.

En quoi cela vous concerne ?

• si vous êtes dans le développement des SI (CRM, ERP, etc) – vous devez pouvoir définir correctement le fonctionnement de votre application et, sans dictionnaire clair, vous êtes condamnés à tourner en rond en mettant en place des « patchs » pour des cas « spécifiques » et/ou « exceptionnels »,
• si vous êtes dans l’intégration de données – c’est pour définir vos « pivots » (aka schemas universels),
• si vous êtes dans le business consulting – c’est pour comprendre les rapports analytiques et les raisons des différences observables,
• si vous êtes dans l’analytique – c’est pour éviter les erreurs et ne pas les répéter les mêmes rapports « mais un peu différents »,
• si vous êtes dans le MDM ou la Data Quality c’est pour vos modèles de données et les règles de gestion,
• etc.

Approches

Ce qui est assez intéressant c’est la variété de définitions que les personnes peuvent donner au même objet métier.

Essayez vous-même : pouvez-vous donner une définition au « client » ? Prenez 5 minutes chrono pour réfléchir.

Voici les approches fréquentes que j’ai vu :

• c’est quelque chose qu’on a dans notre CRM,
• c’est quelque chose dans la table « customer » de notre entrepôt,
• c’est quelque chose avec les champs « nom », « adresse », « siren », « tva », « téléphone », « code CRM », « code comptable », etc,
• c’est quelque chose dans notre système comptable qui est lié aux factures payées.

Il est important de comprendre que les systèmes informatiques sont construits à la base de ces « définitions », les systèmes qui imaginent les nouveaux noms pour ces « objets métier » car la définition-via-modèle veut dire que :

• pour les différents systèmes d’une même entreprise, le modèle « client » ne sera pas le même,
• les personnes n’hésitent pas à ajouter des champs « uniques » dans la définition existante,
• cela change la granularité des listes de clients et un client dans un système peut correspondre à plusieurs dans un autre,
• cela impacte la capacité à faire des flux entre les systèmes,
• …et la société commence un projet de Data Lake/Data Quality sans DGDs.

Exemple. Que pensez-vous d’écritures « client » qui ont pour seule et unique différence un champ « commentaire » dans une facture ? C’est à peu près comme si vous appeliez votre enfant différemment suite à la couleur de t-shirt qu’il a enfilé ce matin… Pourtant, c’est la réalité de grandes multinationales !

Pouvons-nous faire mieux ?

En effet, nous pouvons dire que « client » n’est pas un objet per se, mais le « rôle » de quelqu’un. Appelons ce quelqu’un « personne » (anglais : third party).

Question, pouvons-nous décrire la « personne » en utilisant des mots que la « personne » utilisera elle-même pour se décrire ? Si oui – nous pouvons dire qu’on a capté certaine « réalité » concernant cet objet.

La « personne » peut être :

• un humain (personne physique),
• une « société » / « organisation » (personne morale),
• autre (famille, groupe, etc).

Si nous ignorons qu’il existe une intersection entre ces classes, notamment avec les cas dit « particuliers », nous pouvons commencer organiser les faits :

Cela ne reste qu’un modèle mental, mais ce modèle est déjà suffisant car nous pouvons prédire ce qui constitue la description de la « personne » et ce que correspond seulement à notre vision de cette « personne ».

Ce n’est pas tout. Nous disons souvent « il travaille pour la société ABC ». Que veut-il dire « la société » ?

Heureusement pour nous, la France (contrairement à d’autres pays) a des données disponible en « open data » qui nous permettent de répondre à cette question :

• chaque « société » dispose d’un code TVA (équivalent au SIREN en relation 1-1),
• chaque « société » est divisée en « établissements », « établissement » est généralement équivalent à « la société à l’adresse donné » (a un code SIRET).

Même si le SIREN et le SIRET sont des caractéristiques franco-français, cela nous donne un bon début pour notre modèle :

En regardant ce modèle, nous pouvons voir une hiérarchie se dessiner clairement. Désormais, il est possible de définir un « établissement client », une « société cliente », etc. Nous pouvons également avec cette définition « plus propre » poser les bonnes questions : « dans votre système vos données sont organisées par société, par établissement ou les deux ? ». Croyez-moi beaucoup de sociétés ne se sont pas posés cette question en préparant les DGDs.

Cette « amélioration » de la définition d’un objet métier nous permet également d’auditer la qualité des référentiels car les règles d’unicité sont devenues plus claires.

Note. Même si vous n’avez pas besoin de SIRET pour le fonctionnement de vos processus business ou bien que vous gérez une activité dans un pays où le SIRET n’existe pas, vous pouvez utiliser la définition d’établissement comme « société à l’adresse donné »… et oui, les établissements peuvent avoir des noms propres.

Et ne nous arrêtons pas là ! Ce n’est que le début. Par exemple, quand vous dites « il travaille chez la société Bouygues », c’est à dire, exactement ?

Une recherche rapide sur societe.com nous apprend qu’il existe plein de « Bouygues », notamment :

Vous voulez dire qu’il travaille dans une société qui fait partie de la « groupe » Bouygues ou dans une « branche » Bouygues Telecom ou Bouygues Construction. Si c’est important pour vos processus, vous pouvez modéliser cette « granularité » : les niveaux de Groupe, Branche, Société, Etablissement, Direction, Business Unit, etc.

Analysons notre définition :

• j’espère qu’elle est plus claire qu’une définition « basique »,
• elle révèle les problèmes de modélisation,
• elle montre les niveaux utilisés dans les processus fonctionnels,
• elle donne une idée pour certaines règles de validation de référentiel (TVA doit être unique dans la liste des sociétés, par exemple).

Note. Je dois mentionner une chose importante : le rôle de « client » doit être aussi défini. Souvent, on se retrouve avec 3 personnes – une peut être le demandeur de service pour une autre et la troisième payera cette demande (le trois sont « clients » mais différemment). C’est probablement à ce moment que DGD commencera porter ces fruits.

Stop. Ou peut-on trouver ces définitions ?

Justement, je propose de vérifier si vos consultants en Data Governance disposent d’un livre de W. Kent « Data and Reality » et/ou un livre de L. Silverston « The Data Model Resource Book »…

Non, sérieusement, il y a plusieurs choses :

• votre entreprise n’est pas si spéciale et beaucoup de notions existent dans les « connaissances métier » qu’il faut chercher à comprendre : « sociétés », « établissements »,
• les objets « spécifiques » à votre société ou à votre domaine d’activité sont en mesure d’être extraits en analysant les vrais processus métier, d’où le lien avec Business Process Management,
• certains objets sont « définis » par les règles que la société impose sur les processus : « unique donneur d’ordre par compte ».

Conclusions

• Construire un Data Governance Dictionary c’est du sang et des larmes.
• C’est pour cela que beaucoup de systèmes actuels se basent sur les définitions incorrectes / incomplètes.
• D’où un nombre de douleurs d’intégration et d’analyse de données.
• …et non, ce n’est pas un Data Lake qui va sauver la mise, je vous l’assure.

Bonne santé à vous et à vos systèmes.