Mais pourquoi donc mettre en place un data warehouse (unique) au niveau de l’entreprise ? Quelle est son utilité ? Pourquoi ne pas tout simplement mettre en place lors de chaque projet décisionnel un data mart pour stocker les données nécessaires au reporting ou à l’analyse ? Ce sont les questions auxquelles nous allons essayer de répondre dans cet article.
Imaginons le cas d’une entreprise industrielle classique dont la gestion opérationnelle est assurée par différents SIO (achats, ventes, fabrication, RH …). Cette entreprise souhaitant piloter la performance de ses différents processus métier, elle met en œuvre au cours du temps plusieurs projets décisionnels pour, par exemple, suivre les ventes réalisées, les campagnes marketing ou encore faire du contrôle de gestion. Lors de chaque projet, la mise en œuvre consiste à collecter les données utiles dans un (ou le plus souvent plusieurs) SIO, à les transformer, à les charger dans un data mart modélisé en fonction des besoins de restitution et enfin à les analyser au travers d’un outil de restitution. Après plusieurs projets réalisés, on peut aboutir par exemple à la situation du schéma suivant.
La partie gauche de la figure représente les systèmes d’information opérationnels (SIO) de l’entreprise et la partie droite son système d’information décisionnel (SID). Ce dernier est constitué de 3 couches correspondant à l’acquisition et à la transformation des données (ETL), à leur stockage dans les data marts et à leur restitution (analyse exploratoire et production de rapports via des outils de restitution, parfois par l’intermédiaire de cubes OLAP).
Dans cette architecture, les data marts ont été construits indépendamment les uns des autres et ne sont pas « intégrés » les uns aux autres : on dit parfois qu’ils sont « en silo ».
Lors de la mise en œuvre des premiers projets décisionnels de l’entreprise, cette architecture possède un avantage certain : elle permet une « victoire rapide » (Quick Win dans le jargon SI). En effet, la mise en place des premiers data marts ne nécessite ni d’avoir une vision d’ensemble des données de l’entreprise, ni de définir un langage commun partagé par les différents départements de l’entreprise : le département qui a besoin de construire son data mart le conçoit comme il l’entend, avec sa propre vision des données présentes dans les SIO et il n’extrait des applications source que les données dont il a besoin, en fonction de ses usages.
Cependant, même s’il a pu permettre des « victoires rapides », aucun architecte digne de ce nom ne peut aujourd’hui recommander l’adoption de ce type d’architecture dans le cadre de la mise en place d’un SID à l’échelle d’une entreprise ou d’une organisation. En effet, les inconvénients de ce type d’architecture se font de plus en plus ressentir au fur et à mesure de la mise en place de nouveaux data marts :
- Chaque nouveau data mart requiert la mise en œuvre de nouveaux traitements ETL et nécessite parfois d’extraire depuis une application source les mêmes données que celles extraites pour les besoins d’un autre data mart. Nous aboutissons donc très rapidement à une redondance des traitements d’extraction des données source (ce qui peut impacter négativement les performances des systèmes transactionnels) et à une redondance des traitements d’alimentation des différents data marts, posant là aussi des problèmes de performance et surtout une démultiplication des efforts de maintenance.
- Les différents data marts étant conçus indépendamment les uns des autres, ils contiennent souvent des données identiques mais nommées différemment de par l’absence d’adoption d’un langage commun. Au-delà du surcoût de stockage et de maintenance engendré par la redondance des données stockées dans ces différents data marts en silo, le principal inconvénient est ici engendré par l’absence de langage commun qui entraîne la possibilité que différents départements de l’entreprise produisent des restitutions incohérentes entre elles, aboutissant à une « guerre du chiffre » entre les départements et à une frustration du « top management » de l’entreprise.
- En termes de restitutions d’informations, la présence de différents data marts construits sans vision d’ensemble et probablement avec des technologies de stockage différentes rend très laborieuse voire impossible la production de tableaux de bord de synthèse exploitant des données présentes dans plusieurs data marts.
C’est de ce constat qu’est né le concept de Data Warehouse d’Entreprise (Enterprise Data Warehouse – EDW) dont l’objectif est de pallier ces inconvénients en mettant en œuvre des traitements et une couche de stockage unifiés à l’échelle de l’entreprise.
Dans les prochains articles, nous étudierons les SID s’appuyant sur un EDW, en décrivant et analysant les différentes architectures possibles.
Auteur
- Fort d'une expérience de 20 ans dans la BI, j'interviens en tant qu’architecte et modélisateur d’entrepôts de données. Je suis également l’auteur du livre "Modélisation des Systèmes d’Information Décisionnels" dont le but est de mettre en exergue des patterns avec leurs avantages et inconvénients.
