Data Lab & Data Office : si loin, si proches

Œuvrant tous deux sur le sujet si stratégique de la donnée, il n’est pas rare que Data Lab et Data Office se marchent sur les pieds et peinent à travailler de concert. Pourtant, ces deux pôles sont-ils voués à rivaliser et être incompris l’un de l’autre ? Comment parvenir à faire rimer « go to market » avec gouvernance et gestion des données ? Cet article vise à apporter éclairage et bonnes pratiques pour parvenir à un modus operandi optimal entre ces deux offres de services complémentaires que sont Data Factory et Data Office.

Au commencement était la donnée

A l’heure actuelle, on ne compte plus les entreprises qui, désireuses de prendre le tournant de la donnée, créent un pôle en charge du développement de services et/ou d’outils data-driven. On les retrouvera souvent nommé « Data Lab », « Data Factory », « Pôle Digital », etc.

Ces initiatives reposent sur la bonne exploitation des données présentes dans l’organisation (ou acquises par ailleurs) pour en tirer de la valeur pour les activités de l’entreprise, que ce soit pour l’aide à la décision, pour anticiper les tendances de demain, pour améliorer la gestion et la maintenance de leurs infrastructures, etc. Ces Data Products sont bien souvent la vitrine de l’offre de services data de l’entreprise, ils génèrent des bénéfices quantifiables via des actions concrètes et claires pour tous.

Concomitamment à la mise en place de Data Lab, ou suivant de peu dans le temps, les organisations se sont dotées d’un Data Office : nous en parlons régulièrement dans nos articles, le Data Office a dans ses objectifs d’assurer les différentes prérogatives et initiatives nécessaires à la bonne gouvernance et gestion des données de l’entreprise. Ceci passant par la définition et l’application de politiques et standards, par le déploiement de rôles et responsabilités, par le catalogage et la cartographie du patrimoine data, etc. Autant d’actions vues, à tort, comme plutôt théoriques et abstraites. Et c’est sans compter les nombreux autres chantiers portés par le Data Office, la gestion de la qualité des données étant un exemple des plus concrets.

Les raisons de la colère

De fait, il est courant que les projets Data considèrent le Data Office comme un frein au delivery, ne cessant de dresser des embuches et contraintes ralentissant le cycle de développement de leurs produits ou services : à quoi bon perdre du temps à documenter la donnée, à modéliser les données manipulées par le projet, à établir le lignage des données clés, etc. Tout cela est certes intéressant et utile, mais ne doit pas primer sur la livraison en continu des fonctionnalités et évolutions du produit pour le bien du métier. « Le mieux est l’ennemi du bien », business first donc !

De son côté, le Data Office voit midi à sa porte et focalise logiquement sur son agenda et ses priorités : ceux-ci sont souvent à l’échelle de l’organisation toute entière et souvent orientés sur des temporalités de moyen voire long terme. Si Rome ne s’est pas faite en un jour, la gouvernance efficace et durable des données de l’entreprise nécessitera endurance et patience, rien de solide ne se construisant dans la précipitation. De ce fait, les projets Data sont vus comme brouillons, désordonnés et toujours trop pressés, ce qui amène immanquablement à des problématiques des plus gênantes lorsqu’on passe du MVP à la production industrialisée.

Des objectifs irréconciliables ?

Pardonnez-moi cette tarte à la crème mais les deux parties ont à la fois raison et tort : les projets Data ne peuvent faire autrement que pencher principalement vers le delivery alors que la Data Office est formaté pour lorgner surtout sur des thématiques de plus long terme.

Ayant travaillé la plupart du temps au service de CDO, il serait logique que je donne raison à ces acteurs uniquement ; fort heureusement, mes dernières missions m’ont amené à travailler étroitement avec des équipes développant des data products, ce qui m’a permis de mieux toucher du doigt les contraintes et façons de travailler d’acteurs aussi variés que des data engineers, data scientists, data analysts, product owners, etc.

De fait, à mon grand étonnement à l’époque, la plupart de ces acteurs comprend l’intérêt des activités portées par la Data Office et tous les bénéfices qu’ils peuvent en retirer,.

De plus, si les conditions ne sont pas réunies pour que du temps et des ressources soient dédiés à la bonne gestion des données, il ne faut pas attendre mieux qu’un « best effort », c’est-à-dire pas grand-chose, de la part des équipes projets. Il ne s’agit donc pas de mauvaise volonté des équipes Projet mais bien souvent de manques : manque de sensibilisation, manque de temps consacré au sujet, manque d’intérêt et d’investissement des décideurs et responsables, etc.

Face à ces carences et problématiques de gestion des données, des actions correctrices sont fréquemment lancées, attardons-nous d’abord sur certaines initiatives malheureuses, l’échec ayant au moins la vertu de marquer l’esprit et inspirer des solutions.

Fausses bonnes idées et erreurs fréquentes

• Evitez la posture coercitive: s’il est un réflexe bien humain face à un problème, c’est bien celui de dégainer le bâton contre les importuns ne respectant pas les règles. Dans le cadre d’une organisation, face à des projets ou acteurs n’appliquant pas les guidelines de gestion des données, employer la contrainte sera la plupart du temps une perte de temps : ce n’est pas en demandant au management de faire pression sur leurs équipes pour que tel process soit suivi, que la situation évoluera positivement ; contraindre sans expliquer/sensibiliser, c’est l’échec assuré.
  De surcroit, en plus de manquer d’efficacité, cette attitude donnera une image négative du Data Office et des principes qu’il porte.
• Ne pas céder à la passivité non plus: corolaire logique du point précédent, la méthode trop douce risque fortement d’échouer également. De fait, il est capital de ne pas laisser apparaitre le data management comme une « feature nice-to-have » : la gestion des données nécessite volontarisme et force de conviction, il ne s’agit pas d’une discipline que l’on applique quand on en a le temps ou l’envie. La qualité des données, la bonne gestion des données de référence, la connaissance de vos datasets, ce sont autant de sujets clés dont on ne peut faire l’économie ; et c’est au Data Office, tel Sisyphe, de répéter encore et encore ses actions de sensibilisation et d’acculturation auprès des acteurs Projet et de les accompagner sur le chemin du « Data Management by design ».
• Ne limitez pas le data management à la seule gestion de la qualité des données: comme dit au point précédent, la gestion de la qualité des données est un pan central du data management; pour autant, loin s’en faut, ce n’est pas le seul. Bien souvent, lors de missions d’accompagnements de projets Data, au moment de définir une feuille de route des sujets Data Management à adresser, mes interlocuteurs n’avaient que la qualité en tête. Effectivement, il s’agit d’une problématique clé, mais il ne faut pas oublier d’adresser les autres champs de la gestion des données si l’on souhaite agir efficacement sur la qualité.

A titre d’illustration, si vous rencontrez un problème sur les données d’un système-source qui sont manifestement truffées d’erreurs, il sera nécessaire, pour traiter le mal à la source, dans un premier temps de comprendre et qualifier la donnée en erreur, de reconstituer le lineage, de cartographier les flux lui étant liés, de documenter/récupérer le(s) process opérationnel(s) manipulant la donnée. Soit un ensemble d’activités sur différents champs du Data Management d’abord pour ensuite adresser correctement la qualité de la donnée.

La roue DAMA plaçant la gouvernance des données comme centre et pivot des autres activités Data

Autre écueil à noter : il est fréquent que les problématiques, jugées par les projets comme relatives à la qualité des données, n’aient finalement rien à voir avec la qualité. Par exemple, un dataset qui n’est pas correctement mis-à-jour relèvera plus d’un souci sur l’ingestion des données ou sur les droits d’accès au sein du datalake par exemple. Ces amalgames paraissent exagérés, ils sont pourtant courants.

Afin de terminer cet article sur une note positive et optimiste sur ce sujet complexe, laissez-moi vous partager quelques brefs exemples d’initiatives et principes ayant fait leurs preuves en mission en tant que Data Officer.

Quelques conseils pour la route

• Pour chacune de vos initiatives orientées Data Management, présentez systématiquement les bénéfices concrets et quantifiés que le métier et/ou le projet pourra en retirer : cela facilitera logiquement la réussite et portée de votre action.

• Appuyez-vous sur des relais dans les régions/domaines/départements: d’où l’importance d’identifier, nommer et animer les titulaires des rôles clés de l’organisation data (data owners, data stewards, data governors, data custodians, etc.)
• Impliquez et responsabilisez le Métier dans les actions de Data Management: trop souvent, on n’ose pas déranger le métier sur les actions de gestion des données, pourtant il est indispensable qu’il se saisisse lui aussi de ce sujet, c’est lui qui dispose de l’ownership sur la donnée après tout.
  A titre d’exemple, la phase de scoping est bien trop souvent faite sans s’attarder sur les aspects Data Management, ce qui a bien souvent des conséquences néfastes pour le passage en production et sur l’industrialisation d’un projet/produit data.
• Préparez-vous à expliquer maintes et maintes fois l’intérêt de l’accompagnement des projets par le Data Office: travailler sur les sujets de gouvernance et gestion des données, c’est savoir répéter sans faiblir les mêmes messages et communications de sensibilisation, mobilisation, formation. Il faut reprendre continuellement son bâton de pèlerin pour faire progresser la diffusion des principes et bonnes pratiques de gouvernance des données dans l’entreprise, c’est le lot inévitable de la conduite du changement.
• Last but not least, veillez à ce que Data Office et Data Lab définissent leurs actions complémentaires en alignement sur la stratégie de l’entreprise et des métiers : car s’il est capital que Data Office et Data Lab se synchronisent et mutualisent leurs efforts dans un but commun, encore faut-il que ce cap unique soit bien celui décidé et suivi par l’Entreprise. Sans cela, cette collaboration vertueuse des entités data risque d’être stérile voire contre-productive. Comme disait souvent un de mes clients, « le salut viendra des métiers », cette devise s’applique plus que parfaitement ici pour rappeler l’importance de calquer les actions des Data Office & Data Lab sur la stratégie business de l’organisation.
  Point subsidiaire du propos précédent : il est indispensable de garder en permanence à l’esprit que Data Lab et Data Office agissent pour le bénéfice des acteurs opérationnels, ce qui correspond in fine à la concrétisation de l’alignement de ces 2 pôles sur la stratégie métier. Cela peut paraitre évident mais il s’agit d’éviter se limiter à la focale high level (échelon stratégique) mais bien de veiller à ce que Projets Data et Data Office répondent aux besoins concrets et quotidiens du métier (échelon tactique), sans quoi ils seront vus comme des agents déconnectés de la réalité et des besoins des opérationnels.

Epilogue

Je pourrai écrire encore des volumes sur le sujet mais je pense que ces quelques conseils et retours d’expérience sont suffisants pour atteindre l’objectif fixé pour cet article : revenir sur les écueils classiques des collaborations entre Data Office et Projets/Produits Data, analyser les causes de ces problèmes et proposer des solutions ou, à minima, des pistes d’amélioration.

J’ose espérer que cet article aura permis à nos lecteurs de prendre conscience de l’importance de l’alignement des stratégies et objectifs entre gardiens du Data Management et producteurs de produits/services data : cet enjeu parait évident après explication, mais il est finalement fréquemment ignoré/négligé car jugée secondaire alors qu’il s’agit bien souvent de l’obstacle principal pour un go-to-market rapide (problème d’accès aux données, mauvaise compréhension des données, scalabilité très complexe, incapacité à traiter les défauts de qualité, etc.).

Dans un prochain article, nous nous attacherons à aborder plus concrètement comment peut s’opérer l’intégration des principes et bonnes pratiques de gestion des données dans le fonctionnement des équipes projet (notamment celles fonctionnant en mode Agile), de bout en bout du cycle de vie d’un projet/produit data. Il s’agit là d’une problématique centrale du sujet, ô combien d’actualité, du Data Mesh, nous avons déjà hâte de creuser ce point ensemble !