3 raisons pour lesquelles la culture data ne prend pas au sein de la DSI
Quand on pense data, on pense souvent IT – alors comment imaginer que les “acteurs DSI” aient besoin de mieux comprendre les données ? Les personnes qui construisent et exploitent des systèmes transportant et transformant les données de l’organisation ne sont-elles pas les mieux à même de connaître ces données ?
L’expérience nous montre justement un certain nombre d’incompréhensions mais également de pratiques sous-optimales de data management par les acteurs DSI. Est-ce de la faute de ces acteurs ? Si vous connaissez AEKIDEN vous connaissez notre approche systémique : les acteurs y sont rarement pour quelque chose, c’est plutôt l’operating model (le système de fonctionnement de l’organisation) qui est en cause.
Cet article va donc mettre au jour les raisons de ces incompréhensions et mauvaises pratiques avant de présenter les solutions et leviers de leur transformation.
3 raisons pour lesquelles l’IT peut ne pas être au rdv sur la data
La priorité donnée aux fonctions
Par définition une DSI a pour mission de fournir à ses métiers des données et des fonctions. Or étrangement, la pression qui s’exerce sur un département projet pointe son énergie vers l’aboutissement de ceux-ci – et donc en premier lieu le logiciel ou le progiciel, le reporting ou l’algorithme, l’interface ou l’API. Pas si étrange me direz-vous… mais où sont les données dans tout ça ?
Dans l’exécution des projets, les données sont au mieux le parent pauvre (ex: reprise des données tardive et peu attentive à la qualité des données) et le plus souvent une questions laissée aux mains des métiers. Un projet ou un produit, délivré en Waterfall ou en Agile, c’est toujours une course contre la montre : on priorise, on choisit et in fine le plan de départ est rarement respecté (potentiellement pour le mieux). Mais si, dès le lancement, les données n’ont pas pris une place importante dans l’esprit et le budget des acteurs (PO, CdP, PMO, BA, etc.) alors elles n’ont aucune chance de se voir accorder l’énergie nécessaire.
Des concepts encore flous
La “conceptologie” et ses paladins “conceptologues” sont les premiers responsables du flou qui règne autour des notions relatives aux données. Une grande partie de nos missions, même quand elles sont mandées par le CDO, commencent par clarifier et détourer ce que sont Data Governance et Data Management. Quelles en sont les disciplines et compétences nécessaires, ou encore quels acteurs doivent porter ces sujets.
Le mot “Gouvernance” lui-même est souvent attaché, dans l’esprit d’un acteur non sachant, à des mécaniques complexes articulées autour d’un plaisir coupable nommé “réunionite aigüe” et dont la valeur productive est proche de zéro. Alors parler “Data Governance”, c’est oser associer deux concepts intangibles – seuls les professionnels peuvent s’y risquer, ne faîtes pas ça chez vous !
Plus sérieusement, pour les concepts utiles du domaine, un consensus a émergé grâce à certains auteurs (Ladley, McGivray), à certains frameworks (DAMA), mais avant tout grâce à l’expérience de terrain de nos consultants. Il conviendra de toujours personnaliser ces concepts opérationnels à la culture et aux réalités de l’organisation mais convenons dès maintenant que si leur perception peut être encore floue, leur sens et leurs limites sont bien maîtrisées par les professionnels du sujet.
L’effet Babel
Parler des “acteurs DSI” comme d’une communauté homogène est une gageure. Les spécialités et les rôles sont nombreux au sein de l’IT et ils ne parlent pas non plus le même langage. Les chefs de projets, les AE, les dev, les ops, les devops, les sysops et autres se préoccupent tous de facettes différentes du SI et ont à ce titre un rapport différent avec les données. Chacun est dans son couloir de nage, concentré comme attendu sur son expertise et n’accorde quasiment pas d’attention à l’usage que les autres ont des données. L’architecte d’entreprise va concevoir un data model quand un ops ne s’inquiètera que du docker qui recevra les données : si chacun fait bien son travail, rien ne sert vraiment de se parler et a fortiori d’échanger sur la valeur des données dont on traite. Ainsi les concepts du domaine comme le sens des données sont très peu partagés au sein même de la DSI.
Cet effet Babel, les concepts flous ou encore la trop forte priorité donnée aux fonctions ne sont pas indépassables. Une culture data au sein de la DSI est tout à fait envisageable, à condition de bien s’y prendre.
Les leviers pour booster la culture data au sein de la DSI
Voyons ensemble quelques bonnes pratiques qui assurent d’une meilleure culture data au sein de la DSI.
Des pratiques projet alignées sur l’orientation data driven
Démarrons par la réalité des pratiques car sans réalité opérationnelle, rien ne sert d’espérer l’évolution des esprits.
La conscience de la valeur des données d’un projet est une dimension à investiguer lors des premières phases exploratoires. Qui bénéficiera des données du projet ? Quels seront les usages réalisables à partir des données du projet ? Bref, quelle valeur attendre des données du périmètre ?
Ces questions et leurs corolaires les plus fondamentaux (quelles sont les données du périmètre ? quelle est la qualité des données du périmètre ?) produisent un grand avantage quand elles sont instruites avant toute phase d’arbitrage projet. Cela assure non seulement que ces questions sont abordées, que leurs réponses sont conscientisées mais également que les budgets sont en adéquation avec le traitement à en faire : maîtriser la sémantique métier, modéliser les données, remettre en qualité des données, corriger la source d’un problème de dysqualité, etc.
Comme souvent, la culture data est mesurable aux budgets alloués aux données sur les projets. 😉
Visons des projets “Data by design” !
Un data ownership model partagé entre métier et IT
Quand on évoque le data ownership, on pense, à raison, aux acteurs métiers. Il est pourtant tout aussi important de désigner des responsables sur les données côté DSI. Par exemple, quid d’un “data custodian” côté DSI qui serait le pendant du data steward métier ? En ayant en tête les différents types d’acteurs IT évoqué supra, vous pouvez même en imaginer plusieurs – selon les périmètres et les spécialités.
Ce double maillage des responsabilités sur la donnée et le travail de cohérence à faire par ces acteurs sur une même donnée (comitologie, travaux en commun), tout au long de son cycle de vie, est un des premiers facilitateurs d’une culture data également portée par la DSI.
Des acteurs IT formés
Non, faire partie de la DSI n’implique pas de tout connaître du data driven côté IT. Cela apporte d’ailleurs son lot d’idées préconçues sur le sujet.
Alors oui, les acteurs DSI doivent être formés, professionnalisés sur ces sujets de même qu’ils sont formés à l’agilité, aux nouvelles architectures, etc. C’est en prime un excellent atout dans l’expérience collaborateur – et nous avons tous besoin d’équipes investies.
Pour certains collaborateurs, une acculturation data suffit. Pour ceux qui prennent un rôle dédié, une formation d’approfondissement est nécessaire, en la complétant d’un ou deux modules de spécialisation selon les activités prises en charge.
Naturellement, à quoi sert une culture data des acteurs IT si les métiers ne montent pas également en maturité sur le sujet.
Afin de professionnaliser vos équipes sur les sujets data, AEKIDEN dispose d’un catalogue de formations adaptées à votre contexte qui font le tour du sujet et qui sont données par des consultants réalisant eux-mêmes les travaux dont ils transmettent les apprentissages.
Vous pouvez demander notre catalogue de formation via notre formulaire de contact.