Gouvernance des données

Introduction

« Data is the new oil » est un refrain qui revient perpétuellement depuis bon nombre d’années. L’analogie nous amène à imaginer la richesse dont on pourrait bénéficier en explorant les gisements des données présentes dans nos entreprises.

La donnée permet en effet de créer de la valeur pour une entité, cependant cela n’est possible qu’au travers d’une exploitation faite intelligemment.

De fait, l’exploitation des données est devenue un enjeu majeur au sein des organisations au XXIème siècle. Toutefois, plusieurs obstacles se dressent et une question revient régulièrement : quel cadre définir afin de maximiser les bénéfices à obtenir de cet actif clé ?

L’un des éléments majeurs pour atteindre cet objectif est de s’organiser et de déterminer un modèle opérationnel adapté ayant pour but de définir un cadre articulant les rôles et les responsabilités qui en découlent. C’est le sujet même de cet article : les rôles de la gouvernance Data.

Où en sommes-nous ? Etat des lieux des organisations et prise de recul

Comme vu précédemment, l’une des étapes essentielles liées à la gestion des données consiste à déterminer le modèle opérationnel le mieux adapté.

A ce titre, qu’en est-il des actions menées ces dernières années par les organisations sur cette thématique ?

Au cours de ces cinq à dix dernières années, de nombreuses initiatives ont été conduites et cela a abouti à retrouver systématiquement les mêmes rôles types liés à la gouvernance des données, à savoir : le Chief Data Officer (CDO) / Data Office, le Data Owner, le Data Steward ainsi que le Data ou IT Custodian

Figure 1 : Rôles types liés à la gouvernance des données

Le constat est le suivant : une tendance générale a recouvert le marché sur la thématique des rôles, en effet la majorité des organisations ont suivi les recommandations des ouvrages de référence ou bien ont appliqué par effet de mimétisme les mêmes modèles opérationnels que leurs voisins.

Cette démarche théorique entraine nécessairement des problématiques causées par un modèle opérationnel standardisé qui fonctionne « sur le papier » mais qui dans les faits s’opérationnalise avec difficulté. On retrouve là les forces et les limites de tout Framework :  il faut prendre ce dernier pour ce qu’il est à savoir un modèle suggéré mais nécessitant d’être adapté, retouché et contextualisé.

Le simple fait de poser des rôles normalisés au sein d’une organisation sans même avoir une vision / stratégie Data suivie d’un accompagnement au changement implique des difficultés à opérer lesdits changements et à avoir des rôles concrètement incarnés par les équipes.

En opposition, un modèle opérationnel fiable et pertinent aide à créer la responsabilisation en assurant les bonnes fonctions au sein de l’organisation, il n’est en aucun cas un organigramme ; autrement dit, il ne s’agit pas de mettre des noms dans des boîtes.

Nous notons un certain nombre d’écueils communs dans la formalisation et l’opérationnalisation de ces rôles. Ainsi, l’objectif de cet article est de faire un rappel sur les réflexions à mener dans le bon ordre, les postures traditionnelles associées aux rôles qui doivent être incarnés, ainsi que les raisons d’être associées à chaque rôle.

Une réflexion séquentielle à respecter

L’un des aspects les plus importants dans la définition des rôles et donc du modèle opérationnel est le respect d’une réflexion séquentielle. Il est nécessaire d’avoir un cheminement descendant qui va nous permettre d’aboutir sur la définition des rôles.

• La première étape à réaliser en amont consiste à faire une analyse / audit de son environnement. Cette étape primordiale permet de poser les bases et de définir quels sont les enjeux vis-à-vis de la donnée. Cet audit doit se faire vis-à-vis d’objectifs ou d’une stratégie métier définie, et ce dernier aidera ainsi à mieux évaluer quels sont les enjeux, les axes de travail ainsi que les points de douleur sur la donnée sur l’ensemble des aspects (process, people, technology). C’est ainsi que l’on pourra partir sereinement d’une « Stratégie Data » alignée sur les priorités métiers.
• Par la suite il est nécessaire de définir quelles sont les pratiques que l’on veut induire dans l’organisation afin d’amener un changement structurel et visible sur la gestion des données. Contrairement à ce qu’on pourrait penser, la notion de rôle n’intervient pas de facto ici car elle n’est pas une réponse en soit. Le plus important dans un premier temps est de définir les comportements que l’on veut systématiser et/ou promouvoir, qui se traduiront dans un ensemble de « politiques » présentant les règles et bonnes pratiques.
• Après quoi il est essentiel de décliner les postures qu’il sera nécessaire de voir incarnées dans l’organisation afin de voir ces politiques respectées au quotidien.
• Enfin, pour chacune de ces postures définies, l’objectif est dans un premier temps d’identifier les personnes légitimes en face puis de définir comment ces dernières peuvent s’incarner au sein de l’organisation. Autrement dit, comment elles s’adaptent au contexte de l’organisation et quelles en sont les conséquences (exemple : extension du périmètre de responsabilités à un poste déjà défini, création d’un nouveau rôle, etc.)
• C’est alors là que la notion de « rôles » arrive, car on va alors chercher soit à développer des postures que l’on veut voir incarner dans des rôles existants, et/ou chercher à mettre en place de nouveaux rôles qui assureront une ou plusieurs des postures attendues et nécessaires afin d’amener la bonne application des politiques data définies.
• Notons qu’il est primordial d’accompagner ces personnes et les différentes équipes dans ce changement structurel à travers un support et un suivi quotidien.

Figure 2 : Définition des rôles – Etapes séquentielles à respecter

Ne pas respecter cet ordre séquentiel augmente fortement le risque de proposer un operating model non adapté car décorrélé du contexte métier et organisationnel

Les huit « quick tips » de Pramana

1. Ne partez pas sur des rôles préfabriqués avec des responsabilités « pré-packagées». Ex : si le rôle pré-packagé type de « Data owner » ne fait pas sens chez vous, divisez ses spécificités entre plusieurs autres rôles, potentiellement existants ; et si son nommage fait débat, n’hésitez pas à le revoir également. Seule importe la capacité à effectivement amener des changements de comportements en lien avec vos objectifs data.
2. Ne préférez pas absolument la création de nouveaux rôles à l’ajustement des responsabilités et postures d’un rôle existant. Ce réflexe est une erreur car une approche trop « invasive » ou « disruptive » peut avoir des effets néfastes sur les équipes : effet de surenchère, difficulté à accepter trop de changement d’un coup, etc.
3. Evitez de vous lancer dans l’exercice de rédaction d’un RACI exhaustif: vous perdrez vite de vue l’essentiel à savoir les comportements clés à induire (le Quoi) et les postures clés à incarner (le Comment). De plus le RACI exhaustif est toujours difficile à appréhender, comprendre, opérationnaliser et maintenir dans le temps.
4. Un modèle opérationnel « opérationnalisable » doit s’appuyer sur une stratégie, et une stratégie implique une priorisation voire des renoncements : n’essayez pas d’être exhaustifs à tout prix, définissez les comportements souhaités et les postures en accord avec votre stratégie, c’est-à-dire vos objectifs prioritaires (ex : vous voulez des données de meilleure qualité, alors les comportements à induire vont devoir porter essentiellement sur cet aspect)
5. Evitez de penser tout résoudre avec des comités en favorisant le « consensus à tout prix ». Un modèle opérationnel de gouvernance des données doit, pour être efficient, minimiser le recours systématique à des comités car cela amène, outre un manque d’efficacité influant négativement sur le time-to-market data, une dilution de la responsabilité sur les données.
6. Ne noyez pas dès le démarrage vos équipes avec des indicateurs. Mettez en place le nombre d’indicateurs minimum (en lien avec votre stratégie data), ajustez au fur et à mesure leur nature ainsi que leur nombre en fonction de vos besoins et de la montée en maturité de vos équipes.
7. Favorisez la création d’une communauté avant la création de rôles distincts qui peuvent engendrer du cloisonnement, particulièrement au lancement de votre programme de gouvernance.
8. N’attendez pas forcément la création ou l’officialisation de rôles data pour commencer à travailler sur les comportements cibles et les politiques.

Conclusion

Pour conclure et comme vu à travers l’ensemble de cet article, il est nécessaire pour une organisation qui a volonté à opérer de manière efficiente, de ne pas partir de “modèles” de rôles ou fiches de postes standardisés et par la suite les calquer sur son organisation. Il est en effet primordial en premier lieu de définir quels sont les changements de comportements que l’on veut obtenir, puis dans un second temps de les induire sous certaines postures au sein de son organisation.

Les rôles au sein de la gouvernance Data ne sont pas une recette toute prête et chaque contexte organisationnel nécessitera des adaptations et un accompagnement au changement non négligeable.

Pour aller plus loin et vous aider à appliquer certains conseils ci-dessus, notre consultant Vincent Thorette a pris le temps de décrire dans un article le rôle de Data Owner et d’expliquer comment l’embarquer en 6 étapes dans votre démarche de Gouvernance des données.

Et si vous avez bien suivi cet article, il ne vous aura pas échappé qu’avant de se lancer dans la définition et le déploiement d’une organisation avec des nouveaux rôles, il faut tout d’abord définir une Stratégie Data servant vos enjeux métiers. Mais comment faire ? Stay tuned car Pramana vous prépare de belles choses sur ce volet pour 2023…