Last updated on 27 septembre 2024

Sommaire :

Introduction
Exemples de « à côté » avec les conséquences
Pourquoi il ne faut pas être « à côté » ? L’argument du langage métier
Pourquoi il ne faut pas être « à côté » ? L’argument de la gouvernance
Et c’est une faiblesse que le data mesh a cerné
Mais bon il faut quand même faire aussi avec le « à côté »
Conclusion
Annexes 1 – Références data literacy « à côté »
Annexe 2 – Références domaines métier / domaines data

Mise à jour du 27/09/24 – Voir l’addenda en fin d’article suite à la publication d’une contribution – « Retours d’expérience gouvernance des données » : https://www.datassence.fr/2024/09/23/retours-dexperience-gouvernance-des-donnees/.

Introduction

Je n’aime pas la data « à côté » et j’en ai déjà parlé sur datassence.fr.

« La data « à côté » n’est pas une bonne idée » -> https://www.datassence.fr/2023/07/17/revue-data-du-mois-juin-2023/#_ftn4 et « Arrêtons la data « à côté » -> https://www.datassence.fr/2023/04/12/revue-data-du-mois-mars-2023/#_ftn5

A force de voir et de vivre des situations « à côté », je me lance ici dans une explication de texte.

Ces situations, sont pénibles, sources de tension, d’inefficacité. Et pourtant beaucoup d’acteurs métier, data et IT les vivent.

Par la data « à côté » j’entends des moyens, des organisations, des principes de gouvernance, des outils dédiés aux données, en parallèle de l’existant, du quotidien et de l’environnement métier (et de fait aussi de son S.I.).

Cette situation « à côté », n’est pas sans lien avec le stress et le turn over de la profession de CDO (voir « La précarité du rôle de CDO Chief Data Officer : un rôle de plus en plus difficile – mal compris et avec un taux faible de réussite » -> https://www.datassence.fr/2023/07/17/revue-data-du-mois-juin-2023/#_ftn3 et « Le stress data : chief data officer, data engineer, data scientist … personne n’y échappe » -> https://www.datassence.fr/2023/05/11/revue-data-du-mois-avril-2023/#_ftnref1 ). Voir aussi l’article du Harvard Business Review – https://hbr.org/2023/06/why-chief-data-and-ai-officers-are-set-up-to-fail.

Exemples de « à côté » avec les conséquences

1) Une filière (organisation et mission) data en propre qui vient compléter l’organisation existante (un CDO et son data office, des CDO délégués et des équipes data en parallèle de l’organisation existante) :

Conséquence : un dialogue à trois métier-data-IT (+ d’interfaces, + de traductions, + d’incompréhensions, + de tensions, + de délai, + d’effort), une dilution des responsabilités (ce n’est pas à moi de…, que me vaut cette demande, cet ordre qui vient de l’extérieur…).

2) Une équipe centrale « experte » en données qui a pour mission de porter les enjeux de la data pour l’ensemble de l’entreprise :

Conséquence : un effort de compréhension des données et de leur contexte qui ne sera jamais au niveau des métiers, un positionnement goulet d’étranglement, un risque d’obésité pour absorber toutes les situations métier avec perte de sens (appliquer des règles, traiter de plus en plus de données sans comprendre), un risque de diktat politique mal compris et toujours la déresponsabilisation des métiers (ce n’est pas mon problème, c’est l’équipe data centrale qui en a la charge).

3) Une gouvernance des données sous responsabilité de l’IT : L’expérience montre que l’IT n’est pas légitime. Ce n’est pas à l’IT de diriger la mise en place. Et pourtant c’est majoritairement là qu’elle se construit (voir l’éclairant baromètre Metradata de l’ESSEC à ce sujet – https://chairestratgouvinfo.essec.edu ) !

Conséquence : une responsabilité mal placée (l’IT doit décider d’ordres métier, le métier se déresponsabilise du sujet).

4) Des outils de data management (inventaire, catalogage, lineage…) confiés à une cellule centrale en charge de renseigner les données (méta) à la main en mode déclaratif, voire en mode connecté :

Conséquence : un effort très souvent vain et épuisant de maintien à jour. Et à chaque réunion sur un problème data, obligation en début de séance, de refaire une cartographie de la situation existante que tout le monde partagerait (le temps passé à refaire les lineage explose !)

5) Un socle technique de type datalake initié par l’IT comme point de regroupement, de partage, de confrontation, de traitement des données. L’IT décide « à côté » tout ce qu’implique un datalake en termes métier (validité des sources, modélisation, alimentation cohérente avec le cycle de vie des données, connaissance du contexte associé aux données pour les interpréter, contrôle des usages, respect de la réglementation…).

Conséquence : une crainte dans le partage de ses données (qui va y avoir accès, pour quels usages), la peur d’être dépouillé d’une part de ses prérogatives, de concurrence d’un autre métier, la méfiance quant à la bonne interprétation de ses données par des tiers, pour quels gains ?

6) Une initiative curative de mise en qualité d’un stock de données par une task force de consultants extérieurs :

Conséquence : un effort one shot, rarement atteint à 100%, qui devient rapidement obsolète et à refaire.

7) La production d’un dictionnaire de données confié à un duo de consultant junior, ou au dernier arrivé qui a du temps :

Conséquence : erreurs de compréhension et donc de définition, jargonnage non compris, définitions qui varient en fonction de contextes non pris en compte, différence de terminologie non perçue, oubli de la terminologie portée par le S.I. (SAP !) … c’est une perte de temps, hors sol pour les métiers (sauf si on recherche les frictions … pour les traiter -> interopérabilité sémantique). D’autres en parle : https://www.nicolaaskham.com/blog/2023/9/20/is-data-governance-jargon-really-needed et https://www.analytic-translator.com/blog/real-life-examples-of-poor-communication

8) Et encore : un datalab central côté IT, les grandes messes de data literacy, des domaines data comme découpage supplémentaire, etc

Voir aussi « Les data scientists dans tous leurs états » -> https://www.datassence.fr/2023/01/10/revue-data-du-mois-decembre-2022/#_ftn5d

Le schéma suivant résume ces situations :

– Être « à côté » de la responsabilité business et métier et de son organisation (domaines)

– Être « à côté » de la connaissance business et métier

– Être « à côté » des outils et moyens S.I. du quotidien métier

Pourquoi il ne faut pas être « à côté » ? L’argument du langage métier

Les données sont partie prenante du langage courant des métiers.

A ce titre elles participent aux fonctions du langage naturel (dans la communication, l’explication, la décision, le questionnement… jusqu’à la fonction performative)

Exemples :

1) Extrême : la revue d’un processus majeur chez XXXF, + de 200 slides auxquels sont associés une vingtaine de fichiers xls, avec en ordre de grandeur (estimation au visuel !) ~une vingtaine de données par slides en moyennes (entre pas de données et une soixantaine sur le même slides) .. Soit environ 4000 données incluses dans les éléments de langage (données élémentaires et indicateurs) !

A fin février 2021, X,4 millions de TLLL franchi avec la pose intensive du CompteurCaptetou et les résultats de l’indicateur ACZ55B sont à 96,75% pour un objectif à 96,4%.
Les transferts vers les CCC devraient également chuter alors qu’elles pèsent 15% des retours avec un taux de sat en 2020 de 80,6%
670 frais facturés en 2019 contre 237 en 2020 soit une baisse de 65%
…. Dans la continuité des tablettes sumériennes prémisses à la comptabilité il y a plus de 5000 ans … mais avec un facteur d’échelle gigantesque !!

2) Parce que les métiers ont comme environnement quotidien le « langage » issu du système d’information (processus, activités et services supportés par des systèmes) : « j’ai enregistré la référence produit XXX avec un taux de YYY », « le contrat XXX est bloqué dans le transfert de ce matin »…

Rappel une donnée seule n’a pas de sens. Il y a besoin de son contexte pour en tirer de l’information, du sens, de la valeur et de la confiance (voir https://www.datassence.fr/2023/05/11/revue-data-du-mois-avril-2023/#_ftn4 ). Être en dehors de ce contexte, c’est être « à côté » de cela.

Le « à côté » parle mal métier en étant en dehors de son contexte et peut remettre en cause le bien parlé du métier en essayant d’imposer des définitions de langage de données hors contexte… provocant alors des tensions et frictions … jusqu’au rejet.

Pourquoi il ne faut pas être « à côté » ? L’argument de la gouvernance

Les données ont un impact directe et indirecte sur une majorité d’activités métier. Confier leur gouvernance à un tier, revient à abandonner une part de sa responsabilité sur un élément critique.

Mettre en place une gouvernance des données c’est s’assurer d’être aligné et intégré à l’existant métier … et non pas « à côté ».

Qui porte la responsabilité de la gouvernance, où la positionner ?

On rencontre plusieurs situations : côté IT, côté Métier, côté d’une filière data dédiée représentée par un CDO, mixte IT-CDO-Métier.

La bonne réponse est côté Métier. Au plus près de la connaissance des données, de leur contexte et surtout de la responsabilité métier en jeu.

Il ne s’agit pas non plus d’inventer un nouveau découpage organisationnel de type domaine data mais de coller à l’organisation métier existante (voir exemples et références en annexe).

Quel style de gouvernance mettre en place ?

Par style on entend la forme organisationnelle de la gouvernance. Plusieurs styles sont possibles : gouvernance centralisée, gouvernance décentralisée, gouvernance fédérée.

La réponse à la question est une gouvernance fédérée. Et le paradigme data mesh est une piste à prendre en compte (même si ce dernier peut passer pour une vision utopiste par rapport au poids de l’existant). Attention pour certains types de données, une gouvernance de type fiducie des données peut s’avérer plus efficace (sujet d’un prochain article).

Qui instancie et met en place la gouvernance ?

Par instancier, on entend définir les points de gouvernance (une politique des données, une analyse de maturité, par exemples). Et par mettre en place : faire appliquer les points de gouvernance.

La réponse (de bon sens) est : ceux qui vont devoir l’appliquer !

Comment la gouvernance doit se mettre en place, se décliner ?

Il n’y a pas de débat … pas « à côté » des gouvernances métier et IT.

Elle doit être alignée et intégrée à ces deux gouvernances. Le tout doit être cohérent.

La matrice suivante illustre cet alignement, cette intégration et la cohérence d’ensemble.

Elle doit être adaptée à chaque situation, c’est-à-dire aux formes existantes de la gouvernance d’entreprise et IT.

La matrice permet :

De positionner les points de gouvernance aux bons endroits (intégration et alignement attendus)
De « ratisser » ces points
De faire que l’ensemble des points de gouvernance forme un tout cohérent, ne soient pas isolés – non reliés (exemple d’un glossaire métier « en l’air » et qui finit au placard),
De réduire les frictions, les recouvrements avec les pratiques existantes.

Elle se parcourt verticalement de façon descendante et ascendante et horizontalement :

Déclinaison de la stratégie, à la tactique – cadres-règles à appliquer, jusqu’à l’opérationnel (quotidien, projet)
Remontée de l’opérationnel (exemple initiative locale en réponse à un besoin) vers le tactique (partage avec d’autres domaines) puis le stratégique (promotion à l’échelle de l’entreprise)
Intégration dans les niveaux de gouvernance existants sans en réinventer

Exemple classique : mise en place d’une gouvernance pour répondre à une autorité de régulation (ex BCBS239). Tentation de satisfaire le régulateur par un projet / système dédié… la matrice permet de prendre du recul. Et à la place d’un système dédié, traiter le besoin dans une vision plus large et qui pourquoi pas par effet de rebond produit de la valeur (qui ne se réduit pas à l’effort de compliance).

Exemples de points de gouvernance :

Des règles de contrôle et mise en qualité
Une politique de sécurité des données intégrée à la politique globale de sécurité
Un volet avis data dans les dossiers d’urbanisation et d’architecture SI
Des rôles data à faire porter et décrit dans des fiches de poste
Des moyens de traçabilité des mouvements de données intégrés dans les infrastructures IT
Un processus de promotion et d’industrialisation des initiatives locales data
Etc.

Et c’est une faiblesse que le data mesh a cerné

Référence : Dehghani, Zhamak. Data Mesh. O’Reilly Media. Édition du Kindle.

La gouvernance sur un modèle du passé n’est plus suffisante, d’initiative informatique avec un modèle organisationnel parallèle à l’entreprise et non intégré à l’entreprise

Chapter 5. Principle of Federated Computational Governance
- « In the past, governance has relied heavily on manual interventions, complex central processes of data validation and certification, and establishing global canonical modeling of data with minimal support for change, often engaged too late after the fact. This approach to governance simply won’t work for the decentralized data mesh. »
- Dehghani, Zhamak. Data Mesh (English Edition) (p. 145). O’Reilly Media. Édition du Kindle.

Attention à la sous-traitance de la gouvernance confiée à un tier

«Federated team : Data mesh governance is a collective responsibility, yet with clear accountability of domains; unlike many existing governance functions, it is not outsourced to a third party. »
- Dehghani, Zhamak. Data Mesh (English Edition) (p. 160). O’Reilly Media. Édition du Kindle.

Une gouvernance avec des processus centraux n’est pas efficace

« Reduce Coordination of Data Governance :
- The central and heavily manual processes of data governance inhibit agility in data sharing. Data mesh reduces governance coordination friction through two functions: Automating and embedding policies as code in each data product Delegating central responsibilities of governance to individual domain data product owners These changes are implemented by data mesh’s federated and computational data governance model. »
- Dehghani, Zhamak. Data Mesh (English Edition) (pp. 209-210). O’Reilly Media. Édition du Kindle.

Mais bon il faut quand même faire aussi avec le « à côté »

L’existant S.I. ne permet pas autre chose (que du descriptif manuel voire connecté pour récupérer les données sur les données). Et au vu du poids de cet existant, c’est utopiste de le transformer pour basculer vers une approche complètement intégrée.

La complexité est telle que seul un œil extérieur capable d’obtenir une vue de haut peut tenter d’appréhender certains problèmes data (chaos data : copies, mouvements, enfouies, shadow, chez des tiers, dans les nuages mais où).

La data n’est pas toujours au centre de tous les problèmes d’un métier !

Impossible de traiter toutes les données … il faut en laisser de côté !

La culture data métier n’est pas au niveau minimum suffisant. C’est quoi une donnée ? Se débarrasser du problème avec une équipe data.

Sans aller jusque-là, l’accompagnement par des ressources data est souvent nécessaire. Le métier n’a pas la possibilité de maîtriser toutes les subtilités. Sa responsabilité centrale porte sur l’usage, la valorisation des données au service de son business / métier. A déléguer, les responsabilités dérivées : sécurité, data management, exposition, acquisition de données…

Conclusion

Pourquoi mettre la data « à côté » du métier, de son langage, de son contexte, de son environnement ?

Même si c’est parfois difficile, il faut tout faire pour qu’elle soit intégrée, alignée dans toutes les composantes métier.

C’est tout l’enjeu de la gouvernance des données et par rebond de la data literacy (voir https://www.datassence.fr/2022/11/25/data-literacy-vivre-la-data-au-quotidien/ ).

Et pour cela il y a besoin d’un super héros.

Addenda du 27/08/2024 – Suite retours d’expérience gouvernance des données

En revenant sur 10 ans d’expériences en data gouvernance, je suis naturellement tombé sur des situations « à côté ». Cet addenda vient compléter à la fois cet article et les retours d’expérience en data gouvernance présentés ici : https://www.datassence.fr/2024/09/23/retours-dexperience-gouvernance-des-donnees/

1) On ne donne pas les moyens aux « développeurs » data (data analyst, data scientist, développeurs de pipelines de données, de data products) d’être alignés sur le métier.

Une éternel redécouverte des principes de base du génie logiciel et du temps des analystes-programmeurs, un « développeur » data est aussi un analyste capable de comprendre un métier sous l’angle des données.

Il faut être capable de favoriser (sans friction) leur immersion dans les métiers.

Les mettre dans une équipe centrale les éloigne des métiers.

La question de leur place dans l’organisation est un point clé.

2) Vécu, une équipe data gouvernance positionnée dans l’équipe relation client d’une direction digitale. Autant dire que personne ne les écoutait.

3) Le self data est fait pour ne pas être « à côté ». Mais le self data ne concerne pas uniquement des moyens de développement par soi-même. Cela concerne la capacité à connaître les données, y accéder facilement par soi-même. Les data catalogues, data products catalogues doivent parler aux métiers. Idem pour la data observabilité, etc.

La difficulté numéro 1 pour une plate-forme self data, c’est sa capacité à embarquer le contexte nécessaire à la bonne interprétation des données. Contexte sous forme de métadonnées (exemples : description de la source de données, lineage, sémantique associée, règles et classification des données en fonction de réglementations, de politiques). Et ce contexte évolue.

Il ne faut pas être « à côté » du contexte des données.

Et cela conditionne la capacité à intégrer des données d’un autre domaine métier pour ses besoins.

La circulation des données entre domaines crée de la valeur. Sans le contexte, l’intégration de données externes à son domaine est inefficace.

NB : c’est aussi une des limites des stacks data centralisés … savoir gérer le contexte des données.

Par défaut cela repose sur l’équipe centrale, qui ne peut pas maîtriser l’ensemble des contextes et encore moins leur évolution. La solution c’est d’être immergé dans le domaine. L’équipe centrale se concentrant sur l’appui aux domaines et les sujets transverses.

Voir aussi pour cela les retours d’expérience des responsables d’équipe BI/Datawarehouse qui ont du faire avec la limites de ne pas pouvoir maîtriser l’ensemble des données (en vision centrale) et qui s’en sortent pour partie par la spécificité du décisionnel qui repose sur un sous-ensemble de données que l’on va figer à un instant T (versus par exemple les données opérationnelles, transactionnelles, événementielles).

4) L’équipe de données centrale est nécessaire, une facilité, mais elle doit connaître ses limites.

Elle ne peut pas maîtriser l’ensemble des métiers, des contextes de données.

Elle ne peut pas être responsable des données.

Elle ne peut pas être l’unique source de vérité.

Elle peut s’en sortir par une offre générique (un processus de traitement des besoins métier) qui est souvent frustrant en termes d’efficacité pour les domaines métiers… qui ont besoin du sur mesure « immédiatement » (la donnée est au cœur de leur quotidien).

5) La distribution des rôles data ne doit pas être « à côté ».

C’est à la gouvernance de définir les rôles data (data owner, data product owner, data steward, data owner délégué NB qui est une aberration !).

Un des critères d’attribution est la proximité métier du rôle.

NB : un autre critère vécu (hors du sujet « à côté »), c’est le risque de chevauchement entre rôles explicites et implicites. Par exemple implicitement un data analyst peut se retrouver à réaliser des tâches de data stewardship.

6) Souvent une des premières actions de gouvernance est de lancer la construction d’un glossaire, d’un dictionnaire de données, d’une liste de métriques dans l’idée d’inventaire mais également de normalisation / de création d’une couche sémantique.

C’est une bonne idée. Mais cette action ne peut être menée que par les experts métiers, qui maîtrisent les subtilités cachées, la cohérence entre concepts, les frontières avec d’autres domaines (NB : j’ai vécu dans le cadre d’un projet 360°, toutes les subtilités qu’il peut y avoir sur un seul terme – « une intervention » – entre la vision travaux, la vision maintenance, la vision client, la vision marketing, la vision financière, etc.).

La mener (« à côté ») par des stagiaires (vécu), par des intervenants externes, par une équipe transverse ne marche pas.

Finalement ce livrable est rare dans les entreprises (il peut exister localement mais plus difficilement à l’échelle de l’organisation).

Difficile de mobiliser les experts métier sur cela.

Se concentrer d’abord sur les concepts partagés, frontières entre domaines est une bonne approche (là où il faut réduire les frictions, faciliter la circulation de données).

Annexe 1 – Références – data literacy « à côté »

« Ce n’est en fait pas surprenant . Les dirigeants embauchent des data scientists hautement qualifiés qui utilisent des outils complexes que la plupart des non-analystes ne comprennent pas. Dans le même temps, la plupart des scientifiques des données ne sont pas familiarisés avec les opérations commerciales. Trop souvent, il y a une déconnexion entre les équipes analytiques et commerciales, ce qui entraîne des retouches coûteuses et du gaspillage. » (traduction Google translate)

Sources :

https://content.dataversity.net/rs/656-WMW-918/images/2023_April_EEDL.pdf (voir slide 31 – « If we think about data literacy …….. separately vs. within context »).

https://www.analytic-translator.com/

https://thedataliteracyproject.org/

Annexe 2 – Références – domaines métier / domaines data

Domaine métier – Exemples :

Une entité, une direction, une équipe (le marketing, la finance, la facturation, les risques opérationnels, le centre d’appel)
Un processus transverse (de bout en bout, un parcours client) – mis sous contrôle (approche matricielle)
Voire un ensemble de sources cohérentes pour un ensemble de données placé sous responsabilité/connaissance des utilisateurs quotidiens (l’ERP, les outils du marketing, le système de gestion de la maintenance – GMAO)

Références :

https://www.nicolaaskham.com/blog/2022/7/6/what-is-a-data-domain
https://www.castordoc.com/blog/you-dont-need-data-domains-yet
DCAM – Data Management Capability Assessment Model – Logical Data Domain https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWOk4G

Voir aussi le cas de domaines transverses, de niveau entreprise https://www.datassence.fr/2023/03/30/data-mesh-et-referentiels-de-donnees-dentreprise-est-ce-compatible/