La BI au service du CRM

Description du CRM existant

Le CRM existant se trouve au niveau du backoffice de la plateforme 2Smobile. Au niveau de la page d’accueil de la plateforme, nous avons la possibilité de consulter un classement (Top 5) des clients, par rapport à leur trafic, suivant une période définie et éventuellement pour un produit choisi.
Au niveau du menu CRM, existent trois sous menus :
Client : Cette partie présente la liste des clients, avec la possibilité de visionner pour chacun d’eux, une liste d’informations par rapport à leur compte et abonnement, mais aussi par rapport au nombre de messages ou campagnes envoyés. Ces derniers sont regroupés en statuts (messages en attente, messages rejetés, messages envoyés etc.).
Facturation : La vue du menu Facturation présente :
A gauche de l’écran un rapport, composée d’un diagramme circulaire montrant, par défaut, la répartition du trafic total par application ; et de trois labels représentant successivement le trafic total en national, le trafic total en international et la somme de ces deux totaux. L’utilisateur a en outre la possibilité de choisir une application comme paramètre, ce qui entraine une mise à jour (filtre) des sections précitées, par rapport à l’application choisie.
A droite de l’écran un rapport, sous forme de tableau, représentant la date du dernier trafic, le trafic par zone et le trafic total pour chaque client. Il y a en outre un filtre pour les produits, un pour la période et un pour les opérateurs, avec possibilité de recherche d’un client. En outre, l’utilisateur peut exporter sous forme de fichier .csv, le rapport.
Dernier Trafic : En ce qui concerne la vue du menu Dernier Trafic, elle comprend un rapport sous forme de tableau, indiquant pour chaque client, la date de son dernier trafic avec comme filtres, la période, « Clients sans trafic » et « Clients avec trafic » (ne fonctionnant pas), avec possibilité de recherche et d’export du rapport sous forme de fichier .csv .
Ainsi, est constitué le CRM de la plateforme existante. Pour s’exécuter, les rapports du CRM prennent environ 2 minutes ou plus si le nombre de filtres augmentent, parfois aucune information ne s’affiche (cas des ruptures de connexions à la base de données), et ce, malgré la présence d’index au niveau de la table concernée.
En plus de l’indexation, d’autres techniques, telles que la diminution de charges du serveur hébergeant la base de données ou encore une dénormalisation partielle de la table stockant les éléments de facturation, ont été effectuées pour alléger la lenteur, mais le problème demeure. Aussi, pour chaque section du CRM, n’avons-nous pas une vue d’ensemble pertinente de l’activité d’un client. En effet, des informations, telles que l’évolution du trafic par client ou encore la possibilité de recevoir des alertes en cas d’arrêt ou de reprise du trafic d’un client, entres autres informations, nous échappent. Sur le plan stratégique, il est assez difficile d’avoir avec le CRM existant, une analyse prédictive permettant d’anticiper tout comportement futur.
C’est dans cette lancée, que nous proposons comme solution, la mise en place d’un système décisionnel, physiquement indépendant de la plateforme 2smobile, afin de combler ces limites du CRM en termes de pertinence, de performance mais aussi d’ergonomie. Avant tout, nous allons d’abord étudier certains concepts fondamentaux de la BI.

Business Intelligence

Encore appelée informatique décisionnelle, le terme Business Intelligence (BI) désigne l’ensemble des moyens, outils et méthodes permettant de collecter, consolider, modéliser et restituer les données, matérielles ou immatérielles, d’une entreprise en vue d’offrir une aide à la décision et de permettre aux responsables de la stratégie d’entreprise d’avoir une vue d’ensemble de l’activité traitée.
Selon Kimball , avant l’utilisation de la BI dans les entreprises, des propos récurrents étaient notés depuis plus de trois décennies:
« Nous recueillons des tonnes de données, mais nous ne pouvons pas y accéder. » « Nous devons découper les données dans tous les sens. » « Les gens du business ont besoin d’accéder facilement aux données. » « Montrez-moi ce qui est important. » « Nous passons des réunions entières à discuter de qui a les bons chiffres plutôt que de prendre des décisions. » « Nous voulons que les gens utilisent l’information pour soutenir une prise de décision plus fondée sur les faits. »
En effet, les systèmes traditionnels présentent plusieurs limites à l’analyse décisionnelle :
La non-crédibilité de l’information : Malgré la diversité des sources (dans le cas où les systèmes sont distribués), les données recueillies à des fins d’analyse, doivent se conformer à un référentiel unique. Par exemple, si deux champs dateCreation, de sources différentes, portent le même libellé, ils ont les mêmes significations ; mais si leurs formats diffèrent cela peut affecter l’intégrité de l’information transmise aux leaders d’entreprise.
L’instabilité de l’information : Les bases transactionnelles sont sujettes à des modifications fréquentes (ajout, suppression, mise à jour). Les données deviennent donc instables et pas ou peu utiles à l’analyse devant aider à la prise de décision (les informations datant d’avant les mises à jour étant perdues). Une difficulté d’accès à l’information : Cette difficulté se traduit notamment par une lenteur dans l’exécution de requêtes, voire une absence de réponse. En effet, les bases de données transactionnelles ne supportent pas les requêtes complexes dédiées à l’analyse et risquent même une indisponibilité si ces dernières sont lourdes. Par conséquent, la surabondance des données, qui sont détaillées, fait que ces systèmes deviennent peu voire pas adaptés à l’analyse.

Système d’Information Décisionnel

Un Système d’Information Décisionnel, désigne l’ensemble des technologies et méthodes qui permettent en bout de chaine, de faciliter la prise de décision. L’architecture d’un SID peut être résumée en trois grandes zones :
La zone de préparation : Elle comprend essentiellement les sources de données à partir desquelles les données d’analyse sont extraites et le système ETL.
Les sources de données : Il s’agit des systèmes opérationnels de stockage qui capturent les transactions de l’entreprise. Ces sources peuvent être sous forme de fichiers plats (XML, CSV etc.) ou de bases de données (MySQL, Oracle, MSSQL etc.)
Ces systèmes sont en général caractérisés par : Un manque de crédibilité et de stabilité (absence d’historisation des données), Une répartition des données sur plusieurs sites, Une hétérogénéité des données : différence dans la structure et le format des données, Une surabondance des données : les données sont détaillées, Les données sont volatiles car subissent des modifications fréquentes. Les principales priorités des systèmes sources sont le traitement des performances et la disponibilité. Les bases de données opérationnelles sont généralement optimisées pour les traitements factuels de type OLTP (On Line Transaction Processing) et sont donc conçus pour répondre aux besoins opérationnels quotidiens d’une entreprise.
Par conséquent, une lenteur est constatée lorsqu’il s’agit de récupérer un grand nombre d’enregistrements et de les agréger instantanément .
Le système ETL : Le système ETL correspond à une zone de travail, des structures de données instanciées et un ensemble de processus.
L’extraction est la première étape du processus consistant à lire les données sources, et en copier celles nécessaires dans le système ETL, pour une manipulation ultérieure. Puis, l’étape des transformations, telles que le nettoyage des données, la correction des fautes d’orthographe, la déduplication ou encore le traitement des éléments manquants, combinant des données provenant de sources multiples ou non, s’en suit. Le système ETL ajoute de la valeur aux données avec ces tâches de nettoyage et de mise en conformité en modifiant les données et en les améliorant . La dernière étape du processus ETL correspond au chargement des données en respectant le schéma de la base dédiée à l’analyse, le Data Warehouse.
La zone de chargement : Elle est essentiellement composée du Data Warehouse, entrepôt de donnée où sont stockées les données nettoyées et éventuellement des vues, sous forme multidimensionnelle, des données appelées cubes.
Définition et caractéristiques du Data Warehouse D’après Bill Inmon (1996): « Le Data Warehouse 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. »
Orientés sujet : Le Data Warehouse regroupe l’ensemble des données jugées pertinentes et partageant une même thématique.
Intégrées : Les données doivent se conformer à un référentiel unique car pouvant provenir de plusieurs sources différentes. Les données intégrées correspondent dès lors aux données homogénéisées afin d’en assurer la cohérence.
Historisées : Contrairement aux bases de production, les données du Data Warehouse persistent dans le temps. Chaque modification au niveau des bases de production correspond à nouvelle insertion au niveau du Data Warehouse. Tous les évènements qui affectent une donnée sont datés.
Non volatiles : Un Data Warehouse veut conserver la traçabilité des informations et des décisions prises. Les données ne sont ni modifiées ni supprimées. Une requête émise sur les mêmes données à plusieurs mois d’intervalles doit donner le même résultat .
Structure du Data Warehouse : Les données provenant des bases de données transactionnelles sont organisées en deux principaux axes au niveau du Data Warehouse : un axe synthétique et un axe historique. Il existe un niveau de détail fin plus ancien , correspondant à l’ensemble des données historisées datant d’une période bien antérieure au présent. Ces données sont généralement conservées si les systèmes sont adaptés au stockage de grandes masses de données. Autrement, dans la plupart des cas, les plus anciennes d’entre elles, si inutiles aux besoins actuels, sont purgées afin d’accroitre l’espace de stockage.
S’en suit un niveau de détail fin actuel, correspondant aux données provenant, récemment, de l’environnement de production.
Ensuite, il y a un niveau de données légèrement agrégées suivant des sous thèmes particuliers (niveau des data marts ou sous entrepôts de données) et un niveau de données hautement agrégées (par exemple le nombre de SMS mensuel par produit ou le parc global par type de service).
Habituellement, les modifications majeures des données se produisent lors du passage du niveau opérationnel au niveau de l’entrepôt de données (Phase d’ETL).
Une fois que les données d’étude du Data Warehouse perdurent, elles passent des détails actuels aux détails les plus anciens. Au fur et à mesure que les données sont agrégées, elles passent des détails actuels à des données légèrement agrégées, puis des données sommairement agrégées aux données hautement agrégées .
En outre, il existe d’autres données au niveau du Data Warehouse, correspondant à des informations sur les données d’étude : les métadonnées.
Ces dernières sont d’une grande importance, car facilitant l’utilisation de l’entrepôt de données. Les métadonnées permettent à tout analyste, d’un système décisionnel considéré, de comprendre facilement les règles et procédures utilisées lors de la mise en place du système, afin de pouvoir ainsi apporter de la valeur ajoutée.
Les métadonnées renseignent dès lors sur des informations relatives à l’entrepôt et aux processus associés (sémantiques et localisation des données, procédures de chargement etc.)
La zone de restitution : La zone de restitution ou de présentation des données correspond à l’étape dans laquelle sont élaborés les rapports et tableaux de bords permettant d’offrir, aux responsables de la stratégie d’entreprise, une vision globale de l’activité de l’entreprise.
Pour se faire, il existe plusieurs outils de reporting permettant de réaliser ces rapports ou tableaux de bord. Certaines de ces technologies offrent, en plus des éléments de reporting, la possibilité d’utiliser des techniques de datamining ou fouille de données, qui permettraient de justifier des résultats, de classer les faits et d’effectuer des prédictions sur les mesures.

Les fonctionnalités du système décisionnel

Les fonctionnalités du système décisionnel regroupent essentiellement celles du système ETL et du reporting. Ainsi, comme principales fonctionnalités de l’ETL nous avons :
Créer une connexion vers la base de production « websms », Créer une connexion vers le Data Warehouse « billingbi », Extraire toutes les données préexistantes depuis la base de production, les transformer (nettoyage, restructuration) et les charger dans le Data Warehouse, Extraire, de façon périodique, les données de la base de production datant des dernières 24h, les transformer (nettoyage, restructuration) et les charger dans le Data Warehouse,
Calculer les périodes agrégées et les charger dans le Data Warehouse, Calculer les données agrégées et les charger dans le Data Warehouse,Définir un workflow pour les données préexistantes, Définir un workflow pour les données quotidiennes,
Comme principales fonctionnalités du reporting nous avons : Se connecter sur le système, Cliquer sur la vue des rapports et tableaux de bords, Choisir un rapport ou un tableau de bord, Définir les paramètres du rapport ou tableau de bord, Choisir une période, Sélectionner un ou plusieurs produits, Sélectionner une ou plusieurs applications, Sélectionner le type de souscription, Sélectionner la destination, Sélectionner le type de service, Exécuter un rapport, Exporter le rapport ou tableau de bord.

L’architecture du système décisionnel

La mise en place d’un système décisionnel est un processus dépendant entièrement de comment l’analyste conçoit sa mise en œuvre à partir des besoins de départ. C’est dans cette optique, que nous avons choisi une architecture simple, tenant compte des besoins de départ mais aussi de la capacité des ressources mises à notre disposition.
Ainsi nous proposons comme solution un système décisionnel essentiellement composé : D’un système ETL : Le système sera composé d’une liste de jobs organisés en deux grands workflows : Un workflow, pour l’extraction, le chargement et la transformation de toutes les données, qui sera exécuté une seule fois,
Un workflow, pour l’extraction, le chargement et la transformation des données du jour précédant le jour de lancement, qui sera exécuté une fois par jour, D’un Data Warehouse.
Il s’agira de créer une base de données relationnelle avec un schéma en étoile. Nous ne prévoyons pas de data mart étant donné que les besoins tournent essentiellement autour d’une thématique principale qu’est la facturation du nombre de SMS envoyé.
La mise en place d’un cube étant facultative bien qu’utile, ne serait pas adéquate car la capacité des ressources (serveurs) mises à notre disposition est assez limitée en terme de performance et d’espace de stockage.
D’un système de reporting : Il s’agira d’utiliser un outil de Business Intelligence, qui sera connecté au Data Warehouse, afin de créer un ensemble de rapports et tableaux de bords qui seront accessible depuis l’outil ou intégrés directement au niveau de la plateforme d’étude.

Table des matières

Chapitre 1 : Introduction générale
1.1.Présentation du sujet
1.1.1. Contexte
1.1.2. Problématique
1.1.3. Objectifs
1.2.Démarche méthodologique
Chapitre 2 : Présentation de l’entreprise
Chapitre 3 : Etude des besoins et de l’existant
3.1.Etude des besoins
3.2.Etude de l’existant
3.2.1. Caractéristiques des données
3.2.2. Description du CRM existant
Chapitre 4 : Définition de concepts
4.1. Business Intelligence
4.2. Système d’Information Décisionnel
4.2.1. La zone de préparation
4.2.2. La zone de chargement
4.2.3. La zone de restitution
Chapitre 5 : Proposition de solution
5.1. Les fonctionnalités du système décisionnel
5.2. L’architecture du système décisionnel
5.3. Le Data Warehouse
Chapitre 6 : Implémentation de la solution proposée
6.1. MySQL
6.2. Talend Open Studio
6.3. SpagoBI
6.4. MySQL Workbench
6.5. PuTTY
6.6. Red Hat Enterprise Linux Server
6.7. WinSCP
6.8. Cron
6.9. FortiClient SSLVPN
Chapitre 7 : Présentation et exploitation des résultats
7.1. Le système E.T.L
7.2. Le reporting
Chapitre 8 : Conclusion et perspectives
Bibliographie