Séverine Gérard-Travert, Consultante Senior Finance chez SimCorp France
Les projets de mise en place de data warehouses (DWH) sont en train de se multiplier dans les sociétés de gestion et les compagnies d’assurance. Toutefois, avant de lancer un tel projet qui est complexe, la société de gestion doit vérifier qu’il réponde aux besoins de ses utilisateurs métier – un data warehouse étant propre à chaque société.
Un projet, oui mais avec un objectif clair et une réflexion préalable sur les données
Ces entrepôts de données sont principalement alimentés par les bases de données opérationnelles ; ils peuvent également intégrer des données externes en provenance de fournisseurs de référentiels, de teneurs de compte, etc.
Cependant, la société de gestion doit avoir en tête qu’un DWH ne résoudra pas toutes ses problématiques de données. Au contraire, le déploiement pourrait même être ralenti dans le cas où les données ne seraient pas maîtrisées. Les problématiques sont multiples : homonymes, incohérences entre les sources, clés manquantes, timing du déversement, etc. Un travail préparatoire sur les données est donc requis – et surtout à ne pas sous-estimer. Il conduit entre autre à la construction d’un dictionnaire de données, très utile tant pour les administrateurs que les utilisateurs du DWH.
Seconde question sur les données : à quoi serviront-elles et quel est le niveau de flexibilité requis ? La réponse à cette question détermine le choix de la structure de données du DWH (étoile, flocons, ...), et la définition du niveau d’agrégation à mettre en œuvre.
L’adoption d’un modèle de données en étoile, le plus courant, permet notamment d’avoir des niveaux d’agrégation et des axes d’analyse très dynamiques pour la plus grande joie des end-users. Cependant, ce type de DWH devient vite très volumineux (plusieurs Go, voire To) et sa réactivité décroît avec sa taille. Un arbitrage doit être fait entre la construction de tables de requêtage en agrégeant les données par ETL ou en rendant les agrégations dynamiques avec les outils OLAP.
3ème point : les données stockées dans un DWH resteront inchangées, contrairement à une base opérationnelle où une transaction financière rétroactive peut les modifier et donc impacter les reportings de stocks et d’opérations s’ils sont rejoués. En effet, selon la définition du DWH par Bill Inmon, « le Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d’un processus d’aide à la décision ». Cette caractéristique du DWH est utile, par exemple, aux sociétés devant produire des états comptables qui doivent tenir compte des périodes de clôture ou encore aux sociétés produisant des reportings client mentionnant le détail d’une analyse plusieurs mois après la production de ceux-ci.
D’une manière générale, un DWH est constitué de stocks d’actifs et de caractéristiques des actifs auxquels s’ajoutent des indicateurs. Principalement vu comme un outil d’aide à la décision, le DWH est souvent utilisé pour construire des tableaux de bord basés sur des agrégations d’indicateurs intégrant des données transverses. C’est notamment le cas dans le secteur de l’assurance où Solvabilité II impose aux compagnies d’éditer des rapports très détaillés sur leur gestion de portefeuille, intégrant une grande variété de données à l’image des états détaillés des placements à fournir à l’ACP.
De l’usage des DWH par les sociétés de gestion
La majorité des DWH déployés à ce jour couvre des besoins de reporting et/ou de mise en conformité règlementaire, les données étant partagées par les Front, Middle et Back office. A ce titre, mettre en place un DWH, en respectant les phases préparatoires mentionnées ci-dessus, garantit l’unicité, la qualité et la consistance des données tout en rationalisant leur organisation.
Dans le cas où un seul métier est concerné, il convient de parler plutôt de datamart (sorte de mini-DWH orienté par métier) qui a une taille inférieure aux DWH. Pour la trésorerie, il contiendra les mouvements de cash prévisionnels; en gestion des risques et de la compliance, ce seront les historiques de la VAR et les calculs de volatilité qui seront historisés ; en marketing, le datamart servira à produire des indicateurs de performance et de risque, des graphiques de répartition sous plusieurs axes (type d’actifs, zone géographique, secteur...).
DWH ou datamart, toujours est-il que ces entrepôts de données offrent plusieurs atouts. Parmi les plus importants :
- Il facilite l'édition rapide des reportings ;
- Il autorise l’intégration de données externes dans les restitutions, ce qui aurait été compliqué à faire dans une base opérationnelle ;
- Il constitue une base centralisée pour différents métiers qui partagent ainsi un lexique/langage commun ;
- Il décharge les bases de données opérationnelles des sollicitations en lecture, parfois importantes, qui sont susceptibles de ralentir les temps de réponse de la base opérationnelle utilisée notamment par les gérants.
Garantir le succès de son projet
Pour profiter à plein de ces atouts, quelques points, garants de la réussite du projet, sont à respecter. Outre les problématiques traditionnelles de construction (choix de l’outil, définition du modèle de données), il est important de bien identifier les besoins et de commencer tôt l’établissement du dictionnaire de données ainsi que le nettoyage en amont des données.
Mieux vaut aussi opter pour une structure flexible et ouverte, capable de s’adapter à l’évolution des besoins de l’entreprise - et donc capable de prendre en compte n’importe quel type de donnée au fil du temps. Toutefois, il faut veiller à ne pas complexifier le modèle car cela rendra la maintenance et la réalisation de reporting plus lourdes.
Autre point de vigilance : il faut sélectionner les données importées dans le data warehouse de manière à contrôler le volume des données mais également à disposer d’un niveau d’agrégation bien dosé par les outils d’ETL. Par exemple, dans le secteur Assurance, les DWH réunissent beaucoup de données comptables combinées à des données marché de référence ; dans l’asset management, les données sont majoritairement des données opérationnelles produites par les plateformes buy-side
DWH or not DWH ?
Finalement, avec ces quelques éléments, on voit qu’un projet de data warehouse ne consiste pas juste en la mise en place d’une nouvelle base de données centralisée. Le projet apporte des réponses à certains besoins métier qu’il est essentiel de définir et d’exprimer avant de lancer un projet. Outre la production de KPI correspondant à une démarche BI et/ou de balanced scorecard, il peut devenir un atout par rapport aux enjeux métier propres à la gestion d’actifs dans les institutions financières comme chez les assureurs.
Alors ? Pensez-vous avoir besoin d'un datawarehouse ?
Un projet, oui mais avec un objectif clair et une réflexion préalable sur les données
Ces entrepôts de données sont principalement alimentés par les bases de données opérationnelles ; ils peuvent également intégrer des données externes en provenance de fournisseurs de référentiels, de teneurs de compte, etc.
Cependant, la société de gestion doit avoir en tête qu’un DWH ne résoudra pas toutes ses problématiques de données. Au contraire, le déploiement pourrait même être ralenti dans le cas où les données ne seraient pas maîtrisées. Les problématiques sont multiples : homonymes, incohérences entre les sources, clés manquantes, timing du déversement, etc. Un travail préparatoire sur les données est donc requis – et surtout à ne pas sous-estimer. Il conduit entre autre à la construction d’un dictionnaire de données, très utile tant pour les administrateurs que les utilisateurs du DWH.
Seconde question sur les données : à quoi serviront-elles et quel est le niveau de flexibilité requis ? La réponse à cette question détermine le choix de la structure de données du DWH (étoile, flocons, ...), et la définition du niveau d’agrégation à mettre en œuvre.
L’adoption d’un modèle de données en étoile, le plus courant, permet notamment d’avoir des niveaux d’agrégation et des axes d’analyse très dynamiques pour la plus grande joie des end-users. Cependant, ce type de DWH devient vite très volumineux (plusieurs Go, voire To) et sa réactivité décroît avec sa taille. Un arbitrage doit être fait entre la construction de tables de requêtage en agrégeant les données par ETL ou en rendant les agrégations dynamiques avec les outils OLAP.
3ème point : les données stockées dans un DWH resteront inchangées, contrairement à une base opérationnelle où une transaction financière rétroactive peut les modifier et donc impacter les reportings de stocks et d’opérations s’ils sont rejoués. En effet, selon la définition du DWH par Bill Inmon, « le Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d’un processus d’aide à la décision ». Cette caractéristique du DWH est utile, par exemple, aux sociétés devant produire des états comptables qui doivent tenir compte des périodes de clôture ou encore aux sociétés produisant des reportings client mentionnant le détail d’une analyse plusieurs mois après la production de ceux-ci.
D’une manière générale, un DWH est constitué de stocks d’actifs et de caractéristiques des actifs auxquels s’ajoutent des indicateurs. Principalement vu comme un outil d’aide à la décision, le DWH est souvent utilisé pour construire des tableaux de bord basés sur des agrégations d’indicateurs intégrant des données transverses. C’est notamment le cas dans le secteur de l’assurance où Solvabilité II impose aux compagnies d’éditer des rapports très détaillés sur leur gestion de portefeuille, intégrant une grande variété de données à l’image des états détaillés des placements à fournir à l’ACP.
De l’usage des DWH par les sociétés de gestion
La majorité des DWH déployés à ce jour couvre des besoins de reporting et/ou de mise en conformité règlementaire, les données étant partagées par les Front, Middle et Back office. A ce titre, mettre en place un DWH, en respectant les phases préparatoires mentionnées ci-dessus, garantit l’unicité, la qualité et la consistance des données tout en rationalisant leur organisation.
Dans le cas où un seul métier est concerné, il convient de parler plutôt de datamart (sorte de mini-DWH orienté par métier) qui a une taille inférieure aux DWH. Pour la trésorerie, il contiendra les mouvements de cash prévisionnels; en gestion des risques et de la compliance, ce seront les historiques de la VAR et les calculs de volatilité qui seront historisés ; en marketing, le datamart servira à produire des indicateurs de performance et de risque, des graphiques de répartition sous plusieurs axes (type d’actifs, zone géographique, secteur...).
DWH ou datamart, toujours est-il que ces entrepôts de données offrent plusieurs atouts. Parmi les plus importants :
- Il facilite l'édition rapide des reportings ;
- Il autorise l’intégration de données externes dans les restitutions, ce qui aurait été compliqué à faire dans une base opérationnelle ;
- Il constitue une base centralisée pour différents métiers qui partagent ainsi un lexique/langage commun ;
- Il décharge les bases de données opérationnelles des sollicitations en lecture, parfois importantes, qui sont susceptibles de ralentir les temps de réponse de la base opérationnelle utilisée notamment par les gérants.
Garantir le succès de son projet
Pour profiter à plein de ces atouts, quelques points, garants de la réussite du projet, sont à respecter. Outre les problématiques traditionnelles de construction (choix de l’outil, définition du modèle de données), il est important de bien identifier les besoins et de commencer tôt l’établissement du dictionnaire de données ainsi que le nettoyage en amont des données.
Mieux vaut aussi opter pour une structure flexible et ouverte, capable de s’adapter à l’évolution des besoins de l’entreprise - et donc capable de prendre en compte n’importe quel type de donnée au fil du temps. Toutefois, il faut veiller à ne pas complexifier le modèle car cela rendra la maintenance et la réalisation de reporting plus lourdes.
Autre point de vigilance : il faut sélectionner les données importées dans le data warehouse de manière à contrôler le volume des données mais également à disposer d’un niveau d’agrégation bien dosé par les outils d’ETL. Par exemple, dans le secteur Assurance, les DWH réunissent beaucoup de données comptables combinées à des données marché de référence ; dans l’asset management, les données sont majoritairement des données opérationnelles produites par les plateformes buy-side
DWH or not DWH ?
Finalement, avec ces quelques éléments, on voit qu’un projet de data warehouse ne consiste pas juste en la mise en place d’une nouvelle base de données centralisée. Le projet apporte des réponses à certains besoins métier qu’il est essentiel de définir et d’exprimer avant de lancer un projet. Outre la production de KPI correspondant à une démarche BI et/ou de balanced scorecard, il peut devenir un atout par rapport aux enjeux métier propres à la gestion d’actifs dans les institutions financières comme chez les assureurs.
Alors ? Pensez-vous avoir besoin d'un datawarehouse ?