Press "Enter" to skip to content

Je n’aime pas la data « à côté »

Dernière modification le 8 décembre 2023

Sommaire :

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.

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/


Tous droits réservés – datassence.fr. Cet article a été publié originellement sur www.datassence.fr.

L’attribut alt de cette image est vide, son nom de fichier est Datassence_Logo1_1.png.

Les commentaires sont fermés.