LES DIFFERENCES ENTRE LA BI « CLASSIQUE » ET LA BI « TEMPS REEL »

La Business Intelligence (informatique décisionnelle en français) est un domaine de l’informatique de gestion ayant pour but de collecter, consolider, modéliser et restituer des données internes ou externes à l’entreprise en vue d’offrir une aide à la déc
Jérôme POUSSINEAUMis à jour le 28 Juin 2012
bam-oracle.jpg

1.     Définition de la Business Intelligence

La Business Intelligence (informatique décisionnelle en français) est un domaine de linformatique de gestion ayant pour but de collecter, consolider, modéliser et restituer des données internes ou externes à lentreprise en vue doffrir une aide à la décision et ainsi permettre aux entreprises daméliorer leur pilotage.

Les outils considérés comme appartenant au domaine BI sont principalement les solutions :

  • de collecte de données (ETL, EAI, ESB),
  • de gestion de la qualité de données (DATA QUALITY),
  • de consolidation de données (Data Aggregator, cube OLAP)
  • de modélisation dun univers,
  • de restitution de données sous forme de rapports, courbes ou statistiques.

 

2.     Présentation de la BI dite « classique »

Phase de collecte des données :

La BI dite « classique » permet la collecte dinformations en provenance dapplications hétérogènes en limitant limpact sur ces applications de production via un déclenchement en mode Batch le plus souvent de nuit. La fraîcheur des données est en générale à la journée, mais elle peut dans certains cas être à la semaine, au mois, au trimestre ou même à lannée.

Durant cette collecte la solution dintégration (le plus souvent un ETL) permettra de sassurer de la qualité des données collectées en vérifiant la présence de doublons, la correspondance entre les applications, la présence denregistrements fantômes

Des interventions humaines peuvent être nécessaires à ce niveau pour corriger les différentes erreurs fonctionnelles observées sur les données lors de la phase de collecte. Ces erreurs sont le plus souvent dûes à une faiblesse des applications sources (absence de clés étrangères, doublons) ou bien un défaut dans les mécanismes de synchronisation entre applications (exemple : un client existe bien au niveau comptabilité, par contre, il na pas été créé dans lapplication de gestion de la relation client).

 

Phase de modélisation des données :

Les données étant issues dapplications hétérogènes il est nécessaire de créer une modélisation propre à lentrepôt de données. Durant cette phase les tables de dimensions devront être unifiées et les tables de faits consolidées. Par exemple, prenons la dimension PAYS qui est présente dans la majorité des applications, il est nécessaire de définir de manière unique le code ainsi que le libellé associé à un pays, puis de créer des tables de correspondance entre les différentes tables pays des applications sources. Mais il est aussi nécessaire de proposer le plus grand dénominateur commun possible entre les différentes modélisations de cette table dans chaque application. Toujours en prenant pour exemple la dimension PAYS, pour certaines applications le pays est associé à un secteur commercial, à une zone géographique ou à une monnaie. Il faudra alors que le modèle PAYS pour lentrepôt de données porte toutes ces propriétés propres à chaque application si bien sûr elles présentent un intérêt au niveau de la restitution). Concernant les tables de faits, si lon prend lexemple dune table de faits regroupant les ventes, il sera aussi nécessaire de proposer un modèle unifié présentant lensemble des propriétés dune vente issues de plusieurs applications (gestion de la relation client, comptabilité, gestion des contrats).

Afin dassurer la qualité des données et ainsi la fiabilité des indicateurs obtenus il est préférable de positionner au sein du modèle de lentrepôt de données un maximum de contraintes dintégrités. Ces contraintes sont généralement de 3 ordres :

  • Contrainte dunicité afin de sassurer de labsence de doublons (porté le plus souvent par la PRIMARY KEY ou un INDEX UNIQUE).
  • Contrainte de relation afin de vérifier les relations entre une table de faits et toutes ses tables de dimensions (implémenté via les FOREIGN KEY).
  • Contrainte de format afin de sassurer de la qualité des données pour une colonne (implémenté pour Oracle par les contraintes NOT NULL pour le test de présence et CHECK pour le test de valeurs).

En dernier lieu, pour des raisons de performance, nous ne proposerons pour les tables de dimensions et de fait que des données structurées permettant une analyse comme par exemple des montants, des liens relationnels (lien entre un client et son pays) nous supprimerons donc lensemble des colonnes contenant des fichiers (BLOB sous Oracle) ou bien des textes ou descriptions (nous garderons uniquement le libelle principal définissant lobjet).

 

Phase de consolidation des données :

A la fin de la phase de collecte il sera possible de réaliser une phase de consolidation. Les données issues des tables de faits pourront être consolidées selon une dimension métier. Nous pourrons ainsi créer une table contenant le nombre de ventes par unité de production, une deuxième par secteur géographique, et ainsi de suite. Cette consolidation permettra de faciliter la phase de restitution en offrant directement des statistiques exploitables mais cette consolidation permettra surtout dobtenir de meilleures performances puisque ces statistiques seront calculées une seule fois à lalimentation de ces tables et non en temps réel par le moteur du SGBD lors de la restitution.

 

Phase de restitution des données :

La plupart des solutions de BI classiques permettent pour la phase de restitution, la définition dun « univers ». Un univers BI permet de masquer la complexité du modèle de données aux créateurs des rapports, écrans ou requêtes de restitution (par exemple : lutilisateur pourra manipuler un objet CLIENT au lieu de devoir choisir la table correspondante DWH_CLI). Nous pourrons également y mettre des filtres ce qui permet par exemple de définir deux objets pointant sur la même table mais disposant de filtres différents (exemple : un objet CLIENT qui pointe sur la table DWH_CLI avec un filtre sur la colonne NB_VENTE > 0 et un deuxième objet PROSPECT qui pointe sur la même table mais avec un filtre NB_VENTE=0).

Une fois lunivers défini lutilisateur pourra composer ses rapports à travers une interface simple dutilisation (principe de drag & drop des objets). Les rapports ainsi produits pourront être facilement diffusés sous forme de rapport PDF, écrans Web, emails ou toute autre forme permise par la solution de restitution BI.

 

Les solutions de BI « classique » de par leur fonctionnement en Batch offrent un certain nombre davantages et dinconvénients.

Avantages Inconvénients
La qualité des données est assurée par une intégration inter-applicative et un renforcement des contrôles métiers au sein du modèle. Il est nécessaire de contrôler puis corriger les erreurs d’intégration à la fin de chaque collecte de données.
La consolidation permet d’obtenir un nombre important d’indicateurs par objet métier (table de faits). La fraîcheur des données est limitée à la fréquence de rafraichissement de l’entrepôt. Il est donc difficile de se servir de ce type de BI pour du pilotage opérationnel.
La mise en place d’agrégat permet de pré-calculer un certain nombre de statistiques. Les outils BI « classique » donnent uniquement une vision du passé, ils ne permettent pas de voir ce qui se passe maintenant.

3.     Présentation de la BI dite « temps réel »

La BI « temps » réel correspond à un ensemble de solutions BI permettant une analyse et un traitement des données en quasi temps réel. Ce type de solution permet alors un pilotage opérationnel en offrant une fraicheur de données à la minute (voir une dizaine de minutes selon la solution dintégration choisie).

 

Solutions de restitution légères :

Beaucoup dentreprises vont opter pour mettre en œuvre cette BI dite « temps réel », ces solutions de restitution légères permettant un lien direct aux applications en production. Ce mode de fonctionnement peut être intéressant lorsque lon limite les capacités des utilisateurs en leur proposant uniquement des listes de choix permettant dagir sur les périodes de restitutions ainsi que les dimensions. Il faut dans ce cas éviter à tout prix les requêtes dites « mammouth » qui vont pénaliser les performances de lenvironnement de production et ainsi avoir un impact négatif sur les performances opérationnelles de lentreprise.

 

Mécanisme de collecte temps réel :

Dautres vont choisir pour mettre en œuvre la BI dite « temps réel » limplémentation de mécanismes de collecte de données en temps réel. Afin de ne pas pénaliser les performances de production ces mécanismes devront fonctionner en mode asynchrone, ce qui signifie que le processus portant la modification de la donnée en production nattendra pas la fin de lintégration de celle-ci dans lentrepôt BI « temps réel » pour continuer son traitement. Une des solutions pour la mise en place dun tel mécanisme est lutilisation de la technologie JMSJava Messaging Service (Java Message Service : protocole denvoi de petits messages qui sont collectés dans une file dattente appelé QUEUE ou TOPIC puis qui sont traités par un ou plusieurs processus en écoute sur cette file).

En dernier lieu il est possible dutiliser des solutions de BI « temps réel » capables de collecter nativement les données circulant dans des processus métiers implémentés dans des solutions de type BPM (Business Process Management : atelier logiciel de création de processus métier). Ce type de solution appelé couramment BAM (Business Activity Monitoring) permet de faciliter la collecte dinformations ainsi que la phase de restitution dindicateurs dactivité en temps réel sur les processus cœur de métier de lentreprise (évolutions des ventes, nombre de demandes traitées). Ce type de solution permet alors dobtenir assez facilement des indicateurs de performance pour chacune des étapes composant un processus métier et ainsi permettre à lentreprise de tenir ses engagements en termes de SLA (Service Level Agreement : contrat de service dans lequel on définit le niveau de service souhaité pour un processus métier) mais surtout de mettre en place une politique damélioration continue. Enfin ce type de solution, permet dautomatiser des actions en fonction dindicateurs. Il est possible par exemple de déclencher lenvoi dun mail lorsquune commande dun certain montant nest pas traitée dans le temps imparti.

Quel que soit le mode dimplémentation choisi, les solutions de BI « temps réel » offrent des performances très médiocres lorsque lon souhaite effectuer des restitutions sur une période de temps assez large (plusieurs mois à quelques années). De plus, ce type de solution na pas pour objet dhistoriser les données, il nest donc pas possible avec ce type de solution de comparer lévolution dobjets (par exemple : comparer entre deux années le prix moyen des cotisations dassurances). On limite alors le plus souvent ce type de solution à la restitution dindicateurs se basant sur létat actuel de lentreprise et non dindicateurs mesurant lévolution sur une période choisie.

 

Avantages Inconvénients
Les données sont disponibles en temps réel, il est alors possible d’utiliser la solution pour du pilotage opérationnel Selon le mode d’implémentation sélectionné, les restitutions vont consommer des ressources de l’environnement de production et pourront donc en cas de défaut de conception pénaliser les performances de cet environnement
Les solutions de type BAM permettent de collecter nativement des données issues de solutions BPM Selon le mode d’implémentation sélectionné, il sera nécessaire de positionner des sondes permettant de remonter les données de manière asynchrone à l’entrepôt
Les solutions de type BAM permettent l’amélioration continue en offrant des indicateurs de performance des processus Les solutions de BI « temps réel » ne sont pas adaptées à des restitutions de données sur de longues périodes
Les solutions de type BAM permettent d’automatiser des actions en fonction d’indicateurs

4. Comparatif entre la BI « classique » et la BI « temps réel »

En observant les différences fondamentales entre la BI « classique » et la BI « temps réel » on peut en déduire que ces deux types de solutions sont complémentaires car la première offre des capacités de reporting analytique sur de longues périodes avec un vision du passé et pour un public appartenant aux strates du domaine stratégique et/ou tactique tandis que la deuxième permet des capacités de restitution sur de courtes périodes en temps réel pour du pilotage plutôt opérationnel mais aussi de loptimisation continue des processus métiers.

Critères BI dite « classique » BI dite « temps réel »
Fréquence de rafraichissement des données Journalière, hebdomadaire ou mensuelle Temps réel (quelques minutes à quelques dizaines de minutes)
Période d’analyse des données Longue période (plusieurs semaines à plusieurs années) Courte période (quelques jours à quelques semaines)
Population cible Décisionnaires (niveau stratégique ou tactique) Opérationnels (niveau opérationnel)
Exemples d’indicateurs Evolution des ventes, Evolution de la masse salarial Suivi des ventes en temps réel, Suivi de la production instantanée
Périmètre des données Vision consolidée des tables de faits Vision mono-bloc des tables de fait
Objectifs Permettre une analyse du passé pour en déduire des enseignements permettant d’ajuster ou re-définir la stratégie et/ou le management. Proposer des rapports à date fixe (mensuel, trimestriel ou annuel) permettant de mesurer l’atteinte des objectifs. Permettre une analyse temps réel de l’activité afin d’adapter l’organisation opérationnel à l’évolution de cette activité. Permettre une amélioration continue des processus métier et vérifier le respect du niveau de services (SLA).
Méthodologie privilégiée L’ensemble des données du SI est consolidé dans un entrepôt de données afin de permettre la génération d’un maximum de restitution par la suite. En partant des indicateurs souhaités on va récupérer uniquement les données nécessaires pour permettre la restitution.