Les prémisses du Data Management

Au fils des années, les systèmes d’information des banques ont du s’adapter à une augmentation des exigences réglementaires, à de nouveaux produits et à de nouveaux modes opératoires. L’année 2007 a révélé que de nombreuses banques avaient des lacunes dans leurs capacités à fournir des reportings risque complets et précis dans des délais serrés. Par conséquent, le Comité de Bâle sur la Supervision Bancaire a défini 14 principes en janvier 2013 (BCBS 239) visant à renforcer la capacité d’agrégation des données risques et leur reporting.

De nouveaux challenges

Les banques ont déployé les principes BCBS 239 afin d’améliorer la qualité de l’information utilisée pour produire les reportings. Cependant, le data management ne se limite pas à une exigence réglementaire mais reste un impératif pour le business.  Dans un contexte de multiplicité des systèmes et d’usage diversifié par de nombreux départements, les données peuvent facilement se fragmenter, se dupliquer et ne plus être à jour. Alors que les Data Management Offices cherchent à étendre leur périmètre à l’ensemble des données de la banque et pas seulement aux données risque/finance, les constats suivants restent toujours d’actualité :

• Des volumes toujours plus importants de données utilisant des golden sources, des systèmes et des processus différents
• Un manque uniformisation des concepts (grammaire commune) menant à des incohérences
• Une augmentation constante des demandes du régulateur de fournir des analyses de plus en plus granulaires sur les données (TRIM, etc.)

La nécessité d’évaluer la maturité des Data Management Offices (DMO)

Sous l’impulsion du BCBS 239, les banques ont nommé des Chief Data Officers qui ont structuré des Data Management Offices au sein des fonctions (Risque, Finance, Compliance, ALM, etc.) et au sein des métiers (Retail, CIB, Leasing, Asset Management, etc.). Avec des mandats qui s’étendent de plus en plus au-delà du réglementaire, il paraît important pour les Chief Data Officers d’effectuer une évaluation de leur organisation afin d’en identifier les forces et les faiblesses.

Cette évaluation devra couvrir les dimensions suivantes :

• La gouvernance des données – Data Governance
• Le dictionnaire de données – Data Dictionary
• La qualité des données – Data Quality
• Le cheminement applicatif des données – Data Lineage
• L’architecture des données – Data Architecture

Data Governance

L’évaluation de la Data Governance doit s’effectuer selon deux principaux axes :

• Le périmètre. En effet si certains DMO voient leur scope se limiter au réglementaire (BCBS 239, GDPR notamment), d’autres étendent leurs champs d’actions à l’Analytics, à l’IA et à la veille des nouvelles technologies. Data Managers et Data Scientists peuvent ainsi cohabiter au sein d’une même direction.
• Les Rôles et Responsabilités qui continuent à évoluer avec l’extension du périmètre des DMO. Certaines fonctions sont de plus en plus impliquées dans les travaux des DMO, c’est notamment le cas des équipes de Contrôle Permanent qui assurent le rôle de la seconde ligne de défense et qui intègrent la dimension data dans leurs plans de contrôle opérationnels.

Data Dictionary

La mise à niveau du dictionnaire de données reste encore un chantier important au sein des établissements bancaires. En effet, des problématiques de divergence continuent à se poser entre des dictionnaires locaux (de niveau filiales) et des dictionnaires centraux (de niveau Groupe). L’enjeu principal réside dans la capacité des DMO à faire adopter un langage commun tout en gardant les spécificités, lorsqu’elles existent, du métier auquel ils sont rattachés. Se posent également toujours des problématiques de multiplicité de dictionnaires sous différents formats (Excel, glossaire, etc.) au sein d’une même direction ou d’un même métier alors qu’un unique dictionnaire structuré correctement apporterait des bénéfices certains à l’ensemble des utilisateurs. La maintenance du dictionnaire reste également un enjeu de taille car elle nécessite que les différents acteurs (data owner, contrôle permanent, etc.) aient bien en tête que cet outil doit vivre au gré des évolutions réglementaires et métiers.

Data Quality

Des indicateurs qualité – KPIs – ont été élaborés dans de nombreuses directions. Ils suivent souvent une nomenclature commune (cohérence, unicité, exactitude, fraîcheur…) et sont monitorés via des instances dédiées qui suivent les plans de remédiation.

Les principales problématiques rencontrées sur les indicateurs qualité restent cependant :

• Des divergences entre KPIs locaux et KPIs centraux, compte tenu de spécificités d’usage au sein d’entités et de filiales avec des métiers très spécialisés. Dans ce type de cas, les filiales sont amenées à justifier les écarts.
• La capacité des acteurs à créer des KPIs. Des nouveaux outils tendent en effet à se développer pour permettre à des acteurs non experts au sens IT (requêtage…) de créer plus facilement des KPIs qui répondent à leurs besoins et qui permettent de détecter de manière optimale les sources de non qualité.
• Le positionnement des indicateurs et leur nature même. En effet, le schéma classique de production d’indicateurs sur la donnée unitaire en bout de chaîne (en sortie de Datawarehouse par exemple) n’est plus toujours suffisant pour réduire le risque de non qualité. De nouvelles réflexions émergent sur la qualité même des reportings internes (temps de production, comparaison de seuils d’une période à une autre, exactitude et validité de l’ensemble du contenu, etc.), ce qui nécessite une adhésion encore plus forte de l’ensemble des acteurs aux enjeux de qualité.

Data Lineage

Ce chantier est probablement le plus complexe de tous. Il a nécessité des investissements importants en termes de solutions informatiques mais reste toujours d’actualité. En effet, produire le cheminement applicatif d’une donnée via une solution présuppose que cette dernière soit connectée à l’ensemble du système d’information et qu’elle puisse s’adapter à d’éventuelles évolutions de ce système.

Les exigences des régulateurs (notamment dans le cadre d’audit de modèles) ont prouvé qu’il est parfois plus efficace, voire incontournable, de produire « manuellement » le data lineage lorsque les délais sont serrés et qu’il est nécessaire de fournir l’ensemble des contrôles et des règles de transformation.

Se pose alors la question de la nature même du data lineage qui n’est pas toujours très claire. Si les lineages techniques sont réalisables via des outils une fois les phases, parfois très chronophages, de POC et de paramétrage réalisées ; la réalisation de lineages dits métier ou fonctionnel reste beaucoup plus complexe.

Data Architecture

Bien que cela ne rentre pas toujours directement dans le scope de responsabilités du Chief Data Officer, les travaux du DMO peuvent apporter une impulsion pour revoir l’architecture IT.

En effet, les projets liés à la Data Quality et au Data Lineage ont notamment de fortes adhérences avec l’architecture technique et fonctionnelle. Les démarches autour de la data donnent ainsi l’occasion d’optimiser et de rationaliser le SI, ce qui peut se traduire par des décommissionnements d’outils ou par la convergence de flux de données (risque et finance par exemple).

Ces travaux nécessitent au préalable un audit très orienté data qui consiste par exemple à :

• Identifier les doublons de données dans différents systèmes
• Identifier les outils et/ou technologies non performantes (temps de production d’informations, temps nécessaire pour faire une évolution, stock d’anomalies significatif, etc.) ou obsolètes (codage en dur, etc.)

Conclusion

Le Data Management a tracé un chemin qui reste encore à parcourir. Tous les chantiers décrits précédemment sont fortement interconnectés. Evaluer leurs maturités permettrait aux CDO de revoir leurs priorités et de définir leurs futures roadmaps.