Le système d'information décisionnel est la pierre angulaire de l'entreprise afin de produire des tableaux de bord pour aider la prise de décision. Nous allons découvrir son rôle et sa structuration.

Le système d’information décisionnel représente l’ensemble des ressources (humaines, matérielles et logicielles) afin d’agréger, de consolider, d’historiser et de présenter les données d’une organisation afin d’aider à la prise de décision.

  • Que veut-on dire par consolider ? Il s’agit de donner de la cohérence aux données de l’organisation qui sont par nature hétérogènes et réparties sur différents systèmes métiers : par exemple le système de gestion de la relation client (CRM), le système ressources humaines (RH), le système dédiée aux finances etc.

  • Que veut-on dire par donner de la cohérence ? Il s’agit de s’assurer, qu’à une question donnée, par exemple “Quel est le bénéfice brut généré par notre chaîne de magasins durant la période de Noël sur la région Europe” il n’y ait qu’une seule et unique réponse. Il s’agit donc ici de définir ce qu’est un bénéfice brut, la période de Noël et le périmètre de la région Europe.

  • Que veut-on dire par historiser ? Il s’agit de conserver les données sur de longues périodes avant de pouvoir observer leur évolution dans le temps. Pour cela, certains défis sont à résoudre, notamment sur la manière de mettre en cohérence des données dont la définition peut évoluer au cours du temps.

Vue globale d’un système d’information décisionnel

Le système d’information décisionnel d’une organisation est alimentée par les données de son systèmes d’information opérationnel qui sert à gérer le quotidien de l’activité. Le schéma ci-dessous place sur sa gauche les données du système opérationnel qui peut être composé de différentes sources de données. Ici nous avons les différents ERP (Enterprise Ressource Planning) qui permettent de gérer des processus métiers tels que le CRM (Customer Relationship Management), les RH (Ressources Humaines), les finances …

Un système d’information décisionnel est structuré en trois zones principales :

  • La zone ETL (pour Extract, Transform, Load en anglais) où l’on effectue les traitements sur les données : cette zone doit être réservée aux développeurs. En aucun cas un utilisateur final ne devrait pouvoir y avoir accès car les données n’y sont pas encore forcément dans un état cohérent.
  • La zone de stockage des données : historiquement nous avions ici un entrepôt de données (data warehouse en anglais) reposant sur une technologie OLAP. Désormais nous pouvons imaginer d’autres types de stockage de données comme le stockage in-memory ou les systèmes de données distribués (HDFS, …). Cependant, quel que soit le format ou le support de stockage choisi, la modélisation dimensionnelle est une excellente approche pour structurer les données de manière logique et de permettre d’y accéder.
  • La zone de restitution des données qui couvre tous les outils qui génèrent des rapports ou des tableaux de bord. Cette zone peut permettre aussi de fournir des données à un niveau atomique pour des tâches de machine learning.

Le data warehouse : différentes architectures

Les solutions techniques pour gérer les données décisionnelles appartiennent à la catégorie de traitement de données dite OLAP. Elles prennent en compte les besoins spécifiques liées à l’explotation de données décisionnelles : des requêtes complexes basées sur des agrégats, peu de mises à jour en temps réel et une gestion de l’historique des données.

Les données décisionnelles sont stockées au sein d’un data warehouse dont on peut donner la définition suivante :

Un data warehouse est une base de données structurée de manière spécifique de façon à stocker, indexer et permettre l’interrogation de données décisionnelles.

Il existe deux principales approches pour structure un data warehouse : celle de Kimball et celle d’Inmon. Ces approches correspondent à deux visions différentes et chacune peut être pertinente selon le contexte. Il n’y a donc pas de bonne ou mauvaise approche même si l’approche de Kimball est généralement préférée car elle est par nature plus incrémentale et permet de simplifier la conduite d’un projet décisionnel.

Dans le cadre de cet enseignement nous allons systématiquement nous placer dans l’approche de Kimball.

Approche de Kimball

Source du schéma : Star Schema. Adamson, Christopher. Osborne/McGraw-Hill, 2010, page 293.

L’entrepôt de données :

  • est basé sur une modélisation dimensionnelle des données,
  • est structuré en datamarts, chacun d’entre eux est modélisé par un schéma en étoile et permet d’analyser un processus métier,
  • s’incrémente en construisant un nouveau datamart pour chaque nouveau processus à analyser (grâce à l’architecture en bus),
  • est accédé directement par les applications analytiques.

Approche d’Inmon

Source du schéma : Star Schema. Adamson, Christopher. Osborne/McGraw-Hill, 2010, page 293.

L’entrepôt de données :

  • contient toutes les données relatives aux différents processus de l’entreprise à analyser,
  • contient les données modélisées en troisième forme normale,
  • ne peut être accédé directement par les applications analytiques.

Des datamarts au format dimensionel sont ensuite créés pour chaque processus à analyser afin de permettre l’accès aux données.

Lectures sur ce thème

Lecture Comparison of Bill Inmon and Ralph Kimball paradigm, consulté le 18 octobre 2019

Lecture Data Warehouse Architecture – Kimball and Inmon methodologies, consulté le 18 octobre 2019

Lecture Data Warehouse Design – Inmon versus Kimball, consulté le 18 octobre 2019