L’accélération de la digitalisation a pour conséquence la multiplication des systèmes dans le système d’information (SI) de toutes les entreprises. Or les réponses aux enjeux actuels (time-to-market, efficacité, innovation, conformité, etc.) nécessitent l’interopérabilité des systèmes. Résultat, les mêmes données, issues de sources diverses, se retrouvent dans une multitude de systèmes, sous différents formats, utilisées par plusieurs équipes et avec une grande diversité de sens. C’est pourquoi gouverner les données s’avère dans la majorité des grandes entreprises un véritable casse-tête. Si le data stewardship est une des réponses à la complexité croissante de ces environnements, sa mise en place s’avère souvent plus difficile qu’espéré.
De sa genèse à ses ramifications actuelles, il est essentiel de bien comprendre tous les tenants et aboutissants de ce rôle afin d’éviter les pièges et de réussir la mise en place du data stewarship dans votre entreprise. Tour d’horizon de la fonction de data steward dans cet article.
Le rôle du data steward (DP)
Pour bien comprendre la notion de stewardship (et donc le rôle du data steward), il importe de la mettre en perspective avec l’ownership qui est plus intuitif. En effet, les managers ont la responsabilité de prendre des décisions concernant toutes leurs ressources (humaines, IT, matérielles) pour atteindre leurs propres objectifs.
➡ La responsabilité des données
Mais dans le cadre des données utilisées par une grande partie de l’entreprise, cette responsabilité est moindre, même si la donnée « appartient » à un département. En effet, avec l’abolition des silos et l’accroissement de l’interopérabilité des systèmes, ce schéma de possession « une donnée, une entité organisationnelle » devient de plus en plus obsolète dans nombre d’organisations. La data est désormais passée au statut de « bien commun » ou « objet transverse ». Ses usages deviennent multiples et une entité ne peut plus gérer « ses » données pour ses propres besoins uniquement.
Par conséquent, la donnée passe de département en département tout au long de son cycle de vie. Une molécule migrera de la R&D à la vente en passant par la production et le marketing. Voilà comment la donnée favorise les synergies entre les différentes divisions de l’entreprise pour accroître l’efficacité opérationnelle ou la capacité d’innovation de tout l’organisme.
➡ Une approche globale de la donnée
En conséquence, la stratégie data se pense désormais d’abord au niveau de l’entreprise. Il faut prendre en considération les contraintes extérieures (régulation, réputation), les besoins des différents utilisateurs (internes et externes) de la donnée, les opportunités de synergie, etc. C’est donc pour répondre à l’ensemble de ces impératifs que le rôle de data steward a été créé. Les grandes entreprises avec leurs écosystèmes complexes réunissaient toutes les conditions pour en avoir besoin.
Qu’est-ce qu’un Data steward : définition
Le data steward devient ainsi le gardien de la donnée : il intervient pour nommer, définir, contraindre les usages, mettre en qualité, formater ou conseiller ses utilisateurs.
Tous les nouveaux besoins d’usage, les interrogations sur le sens, le cycle de vie, l’obsolescence ou encore les résolutions d’incidents passent en règle générale par lui. Il doit par conséquent être sachant sur son périmètre, bon communiquant et pédagogue car il est souvent amené à faire des choix qui peuvent ne pas convenir à un groupe d’utilisateurs. Autre compétence indispensable : il doit évidemment être rigoureux car la qualité des données qu’il gère est souvent critique pour les processus métiers, les activités de reporting etc.
Qu’est ce que le Data
Stewardship ?
Comment s’inscrit le data stewardship dans la gouvernance des données ?
Lorsqu’une entreprise met en place son programme de gouvernance de données, ce dernier est souvent justifié par quelques constats classiques :
- La donnée est rarement définie ;
- Sa qualité laisse à désirer ;
- Ses règles métier sont inexistantes ou en conflit les unes avec les autres…
Et personne n’en est officiellement responsable : c’est l’état initial. À l’opposé, des données gouvernées sont des données fiables, comprises et dont quelqu’un porte la responsabilité, à la fois des données elles-mêmes mais aussi de la résolution des incidents liés à ces données : c’est l’état final.
La gouvernance des données consiste donc à faire passer les données de l’état initial à l’état final. Et pour ce faire, le data stewardship est le volet opérationnel de la Data Governance, domaine dans lequel la majeure partie du travail quotidien de la gouvernance des données est effectuée. C’est donc le data steward qui « veille à ce que » le nom de la donnée soit standardisé, sa définition validée et ses règles métiers définies. Et ce, tout en accompagnant le data manager et les architectes sur la cartographie des localisations de la donnée au sein des applications, et l’établissement des rôles et des responsabilités de chacun.
Pour résumer : sans stewardship, la gouvernance des données est juste un ensemble de bonnes intentions qui ne sont jamais appliquées.
Les différentes formes de data stewardship
Il existe plusieurs formes adaptables en fonction des spécificités de l’organisation concernée.
1.
Le modèle par domaine métier
Dans le modèle par domaine métier, chaque data steward gère un périmètre métier (subject area) bien défini. Ceci implique que les domaines métiers soient bien définis et délimités (clients, produits, fournisseurs, etc.).
Dans les organisation complexes ou de taille importante, il est souvent nécessaire de scinder un domaine en plusieurs sous-domaines et d’assigner un data steward à chacun de ces sous-domaines. Le domaine métier « Tiers » par exemple peut être décomposé en : fournisseur, prospect etc.
L’avantage majeur de ce modèle repose sur la clarté des périmètres et des limites gérés par chaque data steward. Ces domaines étant homogènes, le data steward peut souvent rapidement arriver à un niveau de maîtrise suffisant du périmètre qu’il gère, lui permettant ainsi de consacrer la majeure partie de son temps à son cœur de métier.
2.
Le modèle par fonction
Le modèle par fonction est quant à lui directement adossé à l’organisation de l’entreprise. Dans celui-ci, chaque data steward gère l’ensemble des données utilisées par un département (finance, ressources humaines, marketing, etc.). Le data steward du domaine marketing pourra ainsi gérer les données clients, les campagnes et promotions. Il peut également couvrir les données produits et financières.
La dépendance à l’organisation constitue sa grande force avec des limites claires. Les objectifs du data steward peuvent être directement associés à ceux du département et mesurés objectivement par ses employées. Ceci rend plus tangible tous les efforts de gouvernance de données et facilite l’onboarding des utilisateurs dans la stratégie de gouvernance car ce travail est effectué au plus près de leurs besoins.
Néanmoins, il présente également certains effets négatifs. Les données transverses étant par essence utilisée par plusieurs départements, dans les organisations immatures ou très politiques, ce type de données est géré à de multiples endroits par différents data stewards. Par conséquent, ce modèle ne favorise pas la collaboration entre les différents data stewards et peut même renforcer les silos existants.
3.
Le modèle par processus
Il existe également un modèle par processus dans lequel un data steward est assigné à un processus métier. Ce modèle est très efficace pour les entreprises qui ont une solide gestion de leur (macro) processus et qui ont bien compris que les processus métiers et les données vont de pair.
En effet, les processus sont exécutés en s’appuyant sur des données d’entrées (inputs) et génèrent des données (output) souvent matérialisées dans des documents. Plusieurs data stewards peuvent être assignés au même processus si celui est complexe. C’est notamment le cas des processus qui font appel à des services externes à l’entreprise.
L’avantage de cette méthode est que le data stewardship devient une extension naturelle du processus avec des objectifs clairs (efficience du processus, time-to-market, qualité du livrable, fiabilité…) et mesurables de façon directe. Les résultats obtenus à l’initialisation du data stewardship sur un processus donné permettront de justifier aisément la nécessité d’assigner des data stewards aux autres processus.
Cependant, tous ces avantages ne peuvent être réalisés que dans des entreprises avec une culture du processus très forte. Autrement, c’est l’échec assuré. Un autre aspect à prendre en compte est la difficulté de désigner un « propriétaire » de la donnée, notamment pour des données utilisées par plusieurs processus. Chaque processus peut ainsi avoir plusieurs définitions et règles métiers si une gouvernance de données n’est pas effective à une échelle plus large que celle du seul processus.
4.
Le modèle par système ou par application
Enfin, il y a le modèle par système ou par application. Historiquement, c’est le premier modèle à avoir été appliqué pour mettre sous contrôle la donnée dans les années 80. À cette époque, peu de gens remettaient en doute la doxa selon laquelle « la data appartient à l’IT ». Ainsi, dans ce modèle, on assigne un data steward aux systèmes qui gèrent la donnée : bases, ERP, applications, etc. C’est une approche par l’IT du stewardship. Il a le gros avantage d’être une introduction simple du concept de stewardship : « une application = une personne ».
La totalité des données de l’organisation peuvent ainsi rapidement être mises sous contrôle en réalisant un inventaire ou une cartographie du SI (liste des applications, bases de données de l’organisation…). Il peut également permettre à l’IT de prendre le leadership sur la gestion de la qualité des données dans les organisations peu familières avec les concepts de gouvernance et de stewardship.
En revanche, ce modèle a pour inconvénient d’être focalisé sur les utilisateurs directs du système concerné, et de ne pas traiter les usages et les besoins à un niveau plus large. Des problèmes de réconciliation peuvent rapidement survenir entre les utilisateurs directs ou « amont » de la donnée, et les utilisateurs indirects ou « aval ». Aussi, il ne faudrait pas qu’au fil du temps, le stewardship exercé par l’IT devienne un « ownership » dans l’esprit des métiers. L’intervention de ces derniers est alors nécessaire durant les échanges autour des politiques et des usages des données.
Astuces et pièges à éviter pour un stewardship réussi
Quel que soit le modèle choisi, il est souvent nécessaire de s’affranchir des idées reçues. Il n’y a rien de pire dans un programme de transformation – car oui, le data stewardship, et plus largement la gouvernance de données, est un projet de conduite du changement – que de s’appuyer sur des principes généraux sans tenir compte des spécificités du cadre dans lequel il est implémenté.
L’impact de la maturité de l’entreprise sur le data stewardship
Ainsi, des préceptes tels que : « Le data stewardship est de la responsabilité du métier et non de l’IT », « Pas de data stewarship sans cadre de gouvernance de données », « Tout le monde est un data steward » sans plus de spécificité sont à bannir. L’organisation de l’activité de stewardship et son mode opératoire doit pouvoir s’adapter aux caractéristiques de l’entreprise : sa taille, sa culture, son mode d’organisation selon qu’il soit centralisé ou décentralisé, etc.
En gouvernance des données, il faut partir du postulat qu’il existe différents niveaux de maturité au sein des entreprises, de l’anarchie aux procédures structurées. De ce fait, le data steward doit être capable d’évoluer dans une culture d’entreprise (n’importe laquelle) tout en sensibilisant et en insufflant le changement. L’idée, c’est de commencer d’où l’on est et de faire évoluer la culture et la maturité de l’entreprise sans provoquer un big bang.
L’importance des objectifs
Autre point d’importance : il ne faut pas se contenter de donner de grands objectifs « vagues » de l’activité de stewardship. Il faut donner aux data stewards des objectifs mesurables, mais aussi apporter de la motivation pour l’exécutant (le data steward) et pour les contributeurs et utilisateurs de la donnée. Un exemple concret d’apport de motivation pour le data steward est la répercussion dans son salaire de la bonne exécution de ses activités de stewardship par la mise en place d’une prime dédiée. Ceci permet de ne pas délaisser la casquette data steward. De même, pour donner envie aux contributeurs et utilisateurs de continuer dans la voie retenue, il est préférable de choisir un périmètre initial soit à forte visibilité, soit à fort ROI.
En conclusion, s’il est établi que les données de l’entreprise sont de mauvaise qualité, alors il sera relativement facile de convaincre le top management du bien fondé de mettre en place des data stewards. Pour accélérer cette décision, un périmètre critique pourra servir de pilote pour démontrer l’apport de ce rôle. De même, si le besoin de réutilisation des données est important, il est fort probable que les conflits sur l’usage, le sens ou le format de la donnée ne soient pas très loin, légitimant plus facilement la mise en place de data stewards.
Pas encore de commentaires