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

1.     Définition de la Business Intelligence

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écision et ainsi permettre aux entreprises d’amé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 d’un 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 d’informations en provenance d’applications hétérogènes en limitant l’impact 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 à l’année.

Durant cette collecte la solution d’intégration (le plus souvent un ETL) permettra de s’assurer de la qualité des données collectées en vérifiant la présence de doublons, la correspondance entre les applications, la présence d’enregistrements 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 n’a pas été créé dans l’application de gestion de la relation client).

Phase de modélisation des données :

Les données étant issues d’applications hétérogènes il est nécessaire de créer une modélisation propre à l’entrepô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 l’entrepô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 l’on prend l’exemple d’une table de faits regroupant les ventes, il sera aussi nécessaire de proposer un modèle unifié présentant l’ensemble des propriétés d’une vente issues de plusieurs applications (gestion de la relation client, comptabilité, gestion des contrats…).

Afin d’assurer 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 l’entrepôt de données un maximum de contraintes d’intégrités. Ces contraintes sont généralement de 3 ordres :

• Contrainte d’unicité afin de s’assurer de l’absence 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 s’assurer 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 l’ensemble des colonnes contenant des fichiers (BLOB sous Oracle) ou bien des textes ou descriptions (nous garderons uniquement le libelle principal définissant l’objet).

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 d’obtenir de meilleures performances puisque ces statistiques seront calculées une seule fois à l’alimentation 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 d’un « 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 : l’utilisateur 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 l’univers défini l’utilisateur pourra composer ses rapports à travers une interface simple d’utilisation (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 d’avantages et d’inconvénients.

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 d’intégration choisie).

Solutions de restitution légères :

Beaucoup d’entreprises 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 l’on limite les capacités des utilisateurs en leur proposant uniquement des listes de choix permettant d’agir 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 l’environnement de production et ainsi avoir un impact négatif sur les performances opérationnelles de l’entreprise.

Mécanisme de collecte temps réel :

D’autres vont choisir pour mettre en œuvre la BI dite « temps réel » l’implé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 n’attendra pas la fin de l’intégration de celle-ci dans l’entrepôt BI « temps réel » pour continuer son traitement. Une des solutions pour la mise en place d’un tel mécanisme est l’utilisation de la technologie JMSJava Messaging Service (Java Message Service : protocole d’envoi de petits messages qui sont collectés dans une file d’attente 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 d’utiliser 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 d’informations ainsi que la phase de restitution d’indicateurs d’activité en temps réel sur les processus cœur de métier de l’entreprise (évolutions des ventes, nombre de demandes traitées…). Ce type de solution permet alors d’obtenir assez facilement des indicateurs de performance pour chacune des étapes composant un processus métier et ainsi permettre à l’entreprise 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 d’amélioration continue. Enfin ce type de solution, permet d’automatiser des actions en fonction d’indicateurs. Il est possible par exemple de déclencher l’envoi d’un mail lorsqu’une commande d’un certain montant n’est pas traitée dans le temps imparti.

Quel que soit le mode d’implémentation choisi, les solutions de BI « temps réel » offrent des performances très médiocres lorsque l’on souhaite effectuer des restitutions sur une période de temps assez large (plusieurs mois à quelques années). De plus, ce type de solution n’a pas pour objet d’historiser les données, il n’est donc pas possible avec ce type de solution de comparer l’évolution d’objets (par exemple : comparer entre deux années le prix moyen des cotisations d’assurances). On limite alors le plus souvent ce type de solution à la restitution d’indicateurs se basant sur l’état actuel de l’entreprise et non d’indicateurs mesurant l’évolution sur une période choisie.

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 l’optimisation continue des processus métiers.