mise en place de système décisionnel de la société caisse
TRANSCRIPT
UNIVERSITE D’ANTANANARIVO Ecole Supérieure Polytechnique d’Antananarivo
Mémoire de fin d’Etudes pour l’obtention du Diplôme d’Etudes Supérieures Spécialisées en Technologies Nouvelles de Systèmes d’Information.
(DESS-TNSI)
Mise en place de Système décisionnel de la
société Caisse d’Epargne de Madagascar
Réalisé par : RAMAMONJY Marie Florence Yvette
Soutenu le 30 Septembre 2009
Membres du jury :
Président : o Professeur RAMANANTSIZEHENA Pascal
Directeur de l’Ecole Supérieure Polytechnique • Examinateurs :
o Professeur RASTEFANO Elisé Chef du Département Electronique à l’ESPA o Monsieur RAVALISON Andrianaivomalala Docteur en Ingénierie de Projets Industriels o Monsieur RANDRIANASOLO Léon Responsable de la Formation DESS-TNSI à l’ESPA
• Rapporteur : o Professeur ANDRIANAHARISON Yvon Chef du Département Génie Electrique à l’ESPA
• Encadreur Professionnel : o Madame ANDRIAMAMPANDRY Miangaly Directeur Technique et Qualité d’INGENOSYA
Promotion 2008
TABLE DE MATIERES
REMERCIEMENTS .......................................................................................................... 1 LISTE DES FIGURES ...................................................................................................... 2 LISTE DES TABLEAUX .................................................................................................... 3 GLOSSAIRE .................................................................................................................. 4 INTRODUCTION .......................................................................................................... 1 PARTIE I :................................................................................................................... 3 CONTEXTE GENERAL ................................................................................................... 3 CHAPITRE 1 .................................................................................................................. 4 1. Identification ............................................................................................................ 4 2. Les activités de la société ........................................................................................... 4
2.1 Prestation ........................................................................................................... 4 2.2 La politique qualité .............................................................................................. 4
CHAPITRE 2 .................................................................................................................. 5 DESCRIPTION DU PROJET A LA CAISSE D’EPARGNE DE MADAGASCAR (CEM) ....................... 5 1. Historique de la création de la Caisse d’Epargne ............................................................ 5 2. La mission des caisses d’Epargne ................................................................................ 5 3. Description de la Société Caisse d’Epargne de Madagascar ............................................. 5
3.1 Direction Générale (DG), Direction Générale adjoint (DGA) ....................................... 6 3.2 Direction du Système d’Information ....................................................................... 6 3.3 Direction des Etudes / Direction du Réseau et Exploitation ........................................ 6 3.4 Direction du Contrôle de Gestion ........................................................................... 6 3.5 Direction de l’Administration Générale .................................................................... 6 3.6 Direction Financière ............................................................................................. 7 3.7 Direction des Audits Internes ................................................................................ 7 3.8 Direction des Affaires Juridiques et Contentieuses .................................................... 7
4. Organigramme de CEM .............................................................................................. 8 5. Description des besoins décisionnels de CEM ................................................................. 9 6. Description des Fonctionnalités de l’application ............................................................. 9 CHAPITRE 3 .................................................................................................................10 LA BUSINESS INTELLIGENCE ET LA SOLUTION OPEN SOURCE ..........................................10 1. Les principaux concepts du Business Intelligence ..........................................................10
1.1 Qu’est ce que la Business Intelligence? ................................................................. 10 1.2 Différence entre les systèmes opérationnels et les systèmes décisionnels ................. 10 1.3 Pourquoi la Business Intelligence? ....................................................................... 10 1.4 Qui a besoin du Business Intelligence? ................................................................. 11
2. Architecture de la Business Intelligence .......................................................................11 2.1 Phase d’alimentation .......................................................................................... 12 2.2 Phase de stockage ............................................................................................. 12 2.3 Phase de restitution ........................................................................................... 13
PARTIE II ..................................................................................................................14 METHODOLOGIE ........................................................................................................14 CHAPITRE 1 .................................................................................................................15 ETAPE DU PROJET DECISIONNEL ....................................................................................15 1. Le préalable du projet ...............................................................................................15
1.1 Etude du domaine métier.................................................................................... 15 1.2 Interview des acteurs clés du métier .................................................................... 15 1.3 Découpage des besoins en thèmes/sujets ............................................................. 16 1.4 Analyse des données .......................................................................................... 16 1.5 Spécification des flux de données ........................................................................ 17
2. Modélisation d’un datawarehouse ...............................................................................17 2.1 Qu’est ce que le datawarehouse ? ........................................................................ 17 2.2 Données thématique .......................................................................................... 17 2.3 Données intégrées ............................................................................................. 17 2.4 Données non volatiles ........................................................................................ 18 2.5 Données historisées ........................................................................................... 18 2.6 Structure d’un datawarehouse ............................................................................. 18
3. Spécification des restitutions ......................................................................................22 4. Choix des progiciels de la Business Intelligence ............................................................22 CHAPITRE 2 .................................................................................................................23 LES PROGICIELS DE LA BUSINESS INTELLIGENCE ............................................................23 1. Qu’est ce que l’Open Source ? ....................................................................................23 2. Les critères du choix des progiciels de la Business Intelligence .......................................23 3. Pentaho ..................................................................................................................23
3.1 Outils et composants décisionnels de Pentaho ....................................................... 23 3.2 Portail Web ....................................................................................................... 25
4. Vanilla.....................................................................................................................26 4.1 Architecture du Platform Vanilla ........................................................................... 26 4.2 Outils et composants décisionnels de Vanilla ......................................................... 26
CHAPITRE 3 .................................................................................................................30 CONCEPTION DU PROJET BUSINESS INTELLIGENCE DE LA CEM .........................................30 1 Collecte des besoins décisionnels ................................................................................30
1.1 Etude du domaine métier de CEM ........................................................................ 30 1.2 Interview des acteurs clés du métier .................................................................... 30 1.3 Découpage des besoins en thèmes/sujets ............................................................. 30
2 Analyse des données ................................................................................................31 3 Spécification des flux de données ...............................................................................32 4 Modélisation d’un datawarehouse ...............................................................................33 5. La restitution ...........................................................................................................33
5.1 Les tableaux de bord .......................................................................................... 33 5.2 Spécification des indicateurs ............................................................................... 33 5.3 Les principaux axes d’analyse ............................................................................. 34 5.4 Les utilisateurs .................................................................................................. 36 5.5 Choix de logiciels ............................................................................................... 36 5.6 Justification de choix .......................................................................................... 37 5.7 Le choix entre les progiciels PENTAHO et VANILLA ................................................. 38 5.8 Choix de l’architecture adopté pour le système décisionnel de CEM .......................... 40 5.9 Choix du plateforme ........................................................................................... 41
PARTIE III .................................................................................................................42 REALISATION DU PROJET BUSINESS INTELLIGENCE DE LA CAISSE D’EPARGNE DE
MADAGASCAR ............................................................................................................42 CHAPITRE 1 .................................................................................................................43
ARCHITECTURE DU SYSTEME ET DEMARCHE A SUIVRE POUR LA REALISATION DU SYSTEME DECISIONNEL ..............................................................................................................43 1. Architecture du système ............................................................................................43 2. Démarche à suivre ...................................................................................................44 CHAPITRE 2 .................................................................................................................45 REALISATION DU DATAWAREHOUSE ..............................................................................45 1. Etape de la réalisation du datawarehouse ....................................................................45
1.1 Alimentation de l’ODS ........................................................................................ 45 1.2 Alimentation du datawarehouse ........................................................................... 47 1.3 Mise à jour du datawarehouse ............................................................................ 47
CHAPITRE 3 .................................................................................................................49 ANALYSE MULTIDIMENSIONNELLE ..................................................................................49 1. Qu’est ce qu’un cube ? ..............................................................................................49 2. Le processus de la création de cube ............................................................................50
2.1 Définition de source de données .......................................................................... 50 2.2 Définition des tables de fait et les tables de dimension ........................................... 51 2.3 Définition des relations entre les tables ................................................................ 51 2.4 Choix des axes d’analyse et leurs hiérarchies respectives ...................................... 52 2.5 Choix des mesures............................................................................................. 52
3. Création du cube ......................................................................................................52 4. Navigation dans le cube ............................................................................................53 5. Export de cube vers un fichier ....................................................................................54 6. Type de rapport créé par FreeAnalysisWeb ..................................................................55 CHAPITRE 4 .................................................................................................................56
LE REPORTING .............................................................................................................56 1. FreeMetadata ...........................................................................................................56
1.1 Connexion à la base ........................................................................................... 56 1.2 Définition des tables de dimension et des tables de fait .......................................... 56 1.3 Définition des relations entre les tables ................................................................ 57 1.4 Création de Business Model................................................................................. 57 1.5 Création des business Tables .............................................................................. 57 1.6 Création des Ressources ..................................................................................... 58 1.7 Création de Business Package ............................................................................. 58
2. Définition de sécurité des métadonnées ......................................................................60 3. Export de métadonnée vers le serveur ........................................................................61 4. Création de rapport Simple ........................................................................................62
4.1 Connexion au portail web de Vanilla ..................................................................... 62 4.2 Choix de groupe ................................................................................................ 63 4.3 Choix de l’outil utilisé pour la création de rapport .................................................. 63 4.4 Choix de template du rapport .............................................................................. 64 4.5 Sélection des sources de données ........................................................................ 64 4.6 Sélection de Business modèle et de Business package ............................................ 65 4.7 Sélection des champs constituants le contenu du rapport ....................................... 65 4.8 Choix de format de rapport ................................................................................. 65 4.9 Exemple de rapport de format Excel ..................................................................... 66
5. Création de rapport avec Birt .....................................................................................66 5.1 Définition de source de données .......................................................................... 67 5.2 Type de rapport créé par Birt .............................................................................. 68
CONCLUSION .............................................................................................................69 WEBOGRAPHIE ..........................................................................................................70 ANNEXE ......................................................................................................................71 Extrait de la modélisation du datawarehouse ...................................................................71
REMERCIEMENTS
Je tiens à exprimer mes remerciements les personnes qui ont contribué à l’élaboration
de ce mémoire, notamment, à la réalisation de mon stage chez INGENOSYA Madagascar, ainsi
qu’au déroulement de mes études à la TNSI.
Professeur Pascal RAMANANTSIZEHENA, Directeur de l’Ecole Supérieure Polytechnique
d’Antananarivo, de m’avoir accueillir dans son Etablissement.
Monsieur Léon RANDRIANASOLO, Responsable de la Formation, pour l’effort qu’il a
déployé pour réaliser notre formation jusqu’au bout.
Monsieur Jean Jacques RAKOTOARIVELO, DIRECTEUR DU SYSTEME D'INFORMATION de
la Société Caisse d’Epargne de Madagascar, de nous avoir accepter d’accéder dans leur Société
pour faciliter la réalisation de ce mémoire.
Monsieur Jean Luc RAJAONA, Directeur Général de la Société INGENOSYA Madagascar,
pour m’avoir engagé en tant que stagiaire dans son entreprise.
Madame Miangaly ANDRIAMAMPANDRY, Directeur Technique et Qualité de INGENOSYA
Madagascar, pour m’avoir encadré durant le stage.
Toute l’équipe d’INGENOSYA, pour leur accueil chaleureux m’ayant permis de m’intégrer
sans problème au sein de la Société.
Les enseignants de la TNSI, les membres de GOTICOM pour la formation qu’ils nous ont
dispensée et les conseils qui nous ont été très utiles dans notre intégration professionnelle.
Les étudiants de la TNSI, pour l’entraide et les expériences partagées.
Professeur Yvon ANDRIANAHARISON, mon Encadreur pédagogique, qui n’a pas ménagé
son temps pour effectuer la relecture, la correction et la soutenance de ce document.
Je tiens aussi à exprimer mes remerciements aux président et membres de jury qui vont
porter leur jugement sur ce travail.
Enfin, j’aimerais aussi témoigner une profonde reconnaissance à :
– Ma famille et mes proches, plus particulièrement à mon mari et à mon enfant
pour leur soutien pendant toute la durée de la réalisation de ce mémoire.
– Tous ceux qui ont contribué directement ou indirectement à l’exécution du
présent travail.
LISTE DES FIGURES
Figure 1: Architecture du Business Intelligence ............................................................................... 11 Figure 2:Processus des données depuis la production jusqu'aux utilisateurs ....................................... 13 Figure 3 : Nettoyage des données ................................................................................................. 17 Figure 4: Structure de la table de dimension .................................................................................. 19 Figure 5: Structure de la table de fait ............................................................................................ 19 Figure 6: Modèle en étoile ........................................................................................................... 20 Figure 7: Modèle en flocon ........................................................................................................... 21 Figure 8: Interface de MetadataEditor ........................................................................................... 24 Figure 9: Interface de Report Designer .......................................................................................... 24 Figure 10: Interface du Schema Designer ..................................................................................... 25 Figure 11: Interface Web de Pentaho ............................................................................................ 25 Figure 12: Architecture de Vanilla ................................................................................................. 26 Figure 13: Environnement de FreeMetadata ................................................................................... 28 Figure 14: Environnement de FASD ............................................................................................... 29 Figure 15: Environnement de l'Entreprise Service ........................................................................... 29 Figure 16: Hiérarchie de l’axe Temps ............................................................................................ 34 Figure 17: Organisation de CEM .................................................................................................... 35 Figure 18: Hiérarchie de l’axe Client .............................................................................................. 35 Figure 19: Hiérarchie de l’axe Produit ............................................................................................ 35 Figure 20: Architecture de BI de CEM ............................................................................................ 40 Figure 21: Mode de connexion au serveur Vanilla ............................................................................ 41 Figure 22: Architecture du logiciel ................................................................................................. 43 Figure 23: Extraction des données sources Excel ............................................................................ 45 Figure 24: Contenu du fichier à extraire ........................................................................................ 46 Figure 25: Extraction des données de Oracle ................................................................................. 46 Figure 26: Extraction des données des différentes ODS ................................................................... 46 Figure 27: Tâche de l'alimentation de l'ODS ................................................................................... 47 Figure 28: Alimentation du datawarehouse ................................................................................... 47 Figure 29: Alimentation du datawarehouse ................................................................................... 47 Figure 30: Planification des tâches ................................................................................................ 48 Figure 31: Représentation de cube ................................................................................................ 49 Figure 32: L’environnement de l’outil FASD .................................................................................... 50 Figure 33: Connexion à la base .................................................................................................... 50 Figure 34: Choix des tables de dimension et de fait ........................................................................ 51 Figure 35: Définition des relations entre les tables .......................................................................... 51 Figure 36: Définition des axes de dimension .................................................................................. 52 Figure 37: Définition des mesures ................................................................................................. 52 Figure 38: Création de cube ......................................................................................................... 52 Figure 39: Navigation drill-up dans un cube ................................................................................... 53 Figure 40: Navigation drill-down dans un cube ............................................................................... 54 Figure 41: Navigation drill-down dans un cube ............................................................................... 54 Figure 42: Export de cube vers Excel (PDF, Html) ........................................................................... 55 Figure 43: Rapport en Excel ......................................................................................................... 55 Figure 44:Connexion à la base ..................................................................................................... 56 Figure 45: Choix des tables de fait et de dimension ........................................................................ 56 Figure 46: Définition des liaisons entre les tables ............................................................................ 57 Figure 47: Création de Business model .......................................................................................... 57 Figure 48: Création de Business table ........................................................................................... 58 Figure 49: Création de filtre ......................................................................................................... 58 Figure 50: Création de Business package ...................................................................................... 58 Figure 51: Test de Business package ............................................................................................. 59 Figure 52: Choix des colonnes pour le requête ............................................................................... 59 Figure 53: Résultat de la requête .................................................................................................. 60 Figure 54: Ajout de sécurité à la métadonnée ................................................................................ 60 Figure 55: Icône de l'export de métadonnée au serveur .................................................................. 61 Figure 56: Définition des paramètres de connexion au serveur ......................................................... 61 Figure 57: Choix de dossier où on va mettre la métadonnée ............................................................ 61 Figure 58: Attribution de nom à la métadonnée .............................................................................. 62 Figure 59: Métadonnée au serveur ................................................................................................ 62 Figure 60: Fenêtre de l'authentification ......................................................................................... 63 Figure 61: Choix du groupe d'utilisateur ........................................................................................ 63 Figure 62: Choix de template ....................................................................................................... 64 Figure 63: Sélection de métadonnée ............................................................................................. 64
Figure 64: Choix de business model et de business package ............................................................ 65 Figure 65: Sélection des champs pour le rapport ............................................................................ 65 Figure 66: Choix de format du rapport .......................................................................................... 65 Figure 67: Extrait du rapport en Excel de suivi de mouvement ........................................................ 66 Figure 68: Environnement de Birt ................................................................................................. 67 Figure 69: Choix de métadonnée .................................................................................................. 67 Figure 70: Extrait du rapport créé en Birt de suivi de mouvement ..................................................... 68
LISTE DES TABLEAUX
Tableau 1: Différence entre décisionnel et opérationnel ................................................................... 10 Tableau 2: Extrait de découpage des besoins en thèmes/sujets ........................................................ 31 Tableau 3: Extrait de dictionnaire de données ................................................................................ 32 Tableau 4: Extraits des indicateurs de CEM .................................................................................... 34 Tableau 5: Extrait de liste des utilisateurs avec leur groupe ............................................................. 36 Tableau 6: Comparaison entre PENTAHO et VANILLA .................................................................... 38
GLOSSAIRE
Agrégation : Regroupement de données par une fonction de calcul. L’agrégation la plus
utilisée est la somme (cumul). Peuvent être également mentionnées les termes suivants :
moyenne, minimum, écart type (liste non exhaustive). Le terme consolidation peut être
utilisé dans le cas du cumul.
Analyse multidimensionnelle : concept qui définit les analyses effectuées par croisement
de plus de trois dimensions (ou ensemble de données du même type ou encore axes).
Axe d´analyse : Thème fonctionnel regroupant les informations permettant d’analyser les
résultats de l’entreprise. Typiquement, les axes reflètent la perception que l’entreprise a de
son environnement : client, produit, géographie, temps etc.
Base de données multidimensionnelle : une base de données multidimensionnelle par
opposition à une base de donnée relationnelle est une base dénormalisée ou il existe une table
centrale (table de fait) liée à toutes les autres tables (tables de dimension).
BI : Business Intelligence.
Birt : Business Intelligence Report Tools ; Outil open source utilisé pour la création des rapports
Business process : Activité au sein d’une Entreprise ; (par exemple Facture, commande ce
sont des Business process).
Champ : Attribut d’une table d’une base de données. Chaque champ ou colonne correspond
à une caractéristique précise de l’enregistrement de la table.
Clé étrangère : Code d’une table référençant un enregistrement d’une autre table.
Clé primaire : Code identifiant de manière unique un enregistrement dans une table.
Cube : représentation abstraite d'informations multidimensionnelles où chaque donnée est localisée
dans la base de données par un jeu de coordonnées.
Datamart : petit entrepôt de données à l'échelle d'un département ou succursale d'une
grande société. Généralement un datamart déverse ses données chez sa mère qui est le
datawarehouse
Datawarehouse : ou entrepôt de données. Base dans laquelle les données sont centralisées
et organisées pour le support d´un processus d ´aide à la décision.
Dimension : Axes dans les on fait l’analyse des indicateurs.
Drill-down: faire un drill-down, c'est avoir un niveau de détails sur les données. Par exemple
Supposons qu'on veuille voir le détail des ventes pour le premier trimestre de l'année 1997.On
dit qu'on fait un drill-down sur l'axe (ou dimension) temps. C'est à dire qu'on ne veut pas voir
seulement les données de l'année 1997 mais descendre à un niveau de détail plus bas.
Drill-up: est le contraire de drill-down. C'est donc faire de l'agrégation (ou résumé) des
données.
ETL : un outil ETL (Extraction/Transformation/Loading) permet à partir de diverses sources de
données, d'extraire de l'information, de faire des transformations afin de nettoyer les données
et de charger des données utiles dans l'entrepôt de données.Les sources de données peuvent
être diverses (HTML,XML,Base de données, fichiers texte, tableurs, ERP etc..).
FASD : FreeAnalysisSchemaDesigner est l’outil de vanilla qui sert à créer des cubes.
Historisation : désignant le fait de conserver l’historique des modifications subies par une
même information au cours du temps.
Historiser : action de mettre en place une historisation pour une information donnée.
Indicateur : statistique, suivie au fil du temps, qui présente les tendances d´une condition
ou d´un phénomène, au-delà des propriétés de la statistique elle-même. Les indicateurs
permettent d´obtenir de l´information supplémentaire. Ils offrent un moyen d´évaluer les
progrès en vue d´un objectif. On peut concevoir toute sortes d´indicateurs : mesure de la
rentabilité, des ventes, de l´évolution des clients, etc.
Jointure : Relation entre deux tables.
Mesure : une mesure est une quantité présente dans la table de fait qui permet de mesurer
les faits. Par exemple, nombre de vente ou prix unitaire sont des exemples de mesures.
Métadonnées : Les métadonnées, c'est-à-dire des données concernant les données,
constituent une base de connaissance permettant d’expliquer le contenu des autres bases
Modélisation dimensionnelle : Technique de modélisation qui diffère de celle des
systèmes d’information, consistant à organiser les données (indicateurs) autour de
dimensions.
Nettoyage de données : Processus visant à homogénéiser les données pour les rendre exploitables.
Le nettoyage des données assure leur intégrité en éliminant les doublons, en corrigeant
l´orthographe et en supprimant ou complétant les champs non renseignés. Les opérations de
nettoyage peuvent également couvrir le filtrage, l´agrégation, la vérification de relations…
Niveau de hiérarchie : un niveau de hiérarchie se définit au niveau des tables de
dimensions. Cela permet d'agréger les données. Par exemple, supposons qu'on ait la
dimension région contenant la liste des villes, on pourrait faire un niveau de hiérarchie(niveau
1) classant les villes en région, ensuite un niveau plus bas qui les classerait en département
(niveau 2).
ODS : Operational Data source qui est ni plus ni moins qu'un espace intermédiaire dans
lequel l'ETL lit et transforme les données.
OLTP : OnLine Transactonal Processing. Il s'agit des traitements transactionnels. Par exemple,
les logiciels des caisses enregistreuses des chaines de magasins font du OLTP.
OLAP : OnLine Analytical Processing. Opposé à l'OLTP, faire de l'OLAP signifie faire de
l'analyse de données. Analyser les ventes, détecter les fraudes, prospecter des clients font
partie du processus OLAP.
Outil de restitution : ensemble des outils (requêteurs, tableaux de bord, etc.) permettant
de restituer le résultat d´une analyse.
Portail : Interface Internet procurant aux membres de l’organisation, un point d’entrée
unique pour tout un ensemble de services comme des informations institutionnelles, la
gestion documentaire et l’accès aux applications d’entreprise.
Serveur d'analyse : un serveur d'analyse ou serveur OLAP est un serveur de base de
données multidimensionnelle. Exemple : Analysis Server est un serveur de bases
multidimensionnelles.
Référentiel (repository) : Ensemble structuré d’information (base de données) constituant
un cadre commun à plusieurs applications.
Requête (à une base de données) : Instruction SQL exécutée sur une base de données.
SI : Le Système d’Information de l’entreprise définit l’ensemble des moyens par lesquels les
acteurs créent, échangent, gèrent et stockent les informations dont ils ont besoin pour
l’exercice de leurs activités.
SID : Sous ensemble du SI spécialisé dans l’aide à la décision.
Table de fait : comme son nom l'indique, une table de fait est une table contenant tous les
faits du SI et dont dépendent toutes les autres tables. Cette table ne contient que des clés
étrangères venant des tables de dimension et des valeurs numériques appelées mesure.
Exemple de table de fait : table des Ventes
Tables de dimension : les tables de dimension sont des tables servant d'axes d'analyse. On
peut par exemple analyser les ventes (table de fait) suivant l'axe des temps (table de
dimension) pour indiquer par exemple pendant quel trimestre de l'année les ventes ont
explosé.
Vue : Terme générique désignant un sous-ensemble. Dans le cadre du SQL, il s’agit de la
consultation des informations sur un ensemble de colonnes de plusieurs tables créant une
table logique accessible en lecture.
CEM: Caisse d’Epargne de Madagascar
CGB : c’est une application ERP produit par la société Capital Banking System.
PDI : Pentaho Data Integration
1
INTRODUCTION
Etant donné le développement du monde bancaire à Madagascar, les décideurs de Caisse
d’Epargne de Madagascar (CEM) se soucient de la façon dont ils doivent se positionner par
rapport à ses concurrents. Ils posent des questions comme Qui sont nos clients, Pourquoi
sont-ils nos clients, Comment les conserver ou les faire revenir, Ces clients sont-ils
intéressants pour nous. Les décideurs de CEM doivent connaître l’agence qui a fait le plus
grand nombre d’ouverture de compte dans l’année de la même façon, ils veulent savoir
l’agence qui a fait le plus grand nombre de fermeture de compte, les produits qui intéressent
le plus leurs clients.
Pour répondre à ses attentes, la Caisse d’Epargne de Madagascar a fait appel à la société
INGENOSYA pour réaliser leur projet décisionnel. Pour développer le système décisionnel de
CEM, INGENOSYA a proposé un logiciel open source avec une architecture basée sur un
développement 100% JAVA. Le choix de cette architecture résulte de l’expérience de la Société
en matière de mise en place d’un système décisionnel dans un environnement existant et aussi
pour répondre à toutes les fonctionnalités demandées par la CEM dans les termes de
référence.
Le marché de l'informatique décisionnelle reste en croissance régulière et offre une belle
visibilité grâce aux progrès technologiques continus, aux nouvelles architectures informatiques
(client/serveur), à la mise en place de nouveaux logiciels et aux nouvelles stratégies
d'entreprise. Les outils d'aide à la décision donnaient aux dirigeants des Entreprises des
indicateurs et analyses concernant l'état de leurs business. Pour être plus réactives, les
dirigeants doivent s'appuyer sur des informations traitées et élaborées. La Business
Intelligence (BI) ou informatique décisionnelle soutient ces exigences de gestion des systèmes
d'aide à la décision, qui se caractérisent par leur capacité à traiter des données hétérogènes et
par la mise à disposition d'outils d'analyse qui facilitent l'évaluation d'hypothèses métiers
directement exploitables. L’objectif principal du Business Intelligence est de transformer le
système d’information qui avait une vocation de production à un système d’information
décisionnel dont la vocation de pilotage devient majeure.
Les données du système de production comme ORACLE, MYSQL, SQL Server et les
fichiers plats comme Excel, CSV sont chargées dans le datawarehouse via l’ODS qui est la base
de donnée intermédiaire. Elles doivent passer par plusieurs transformations comme le
nettoyage, le filtrage, l’agrégation avant d’être chargées dans le datawarehouse. La création
de ce datawarehouse constitue 80% de travail dans la réalisation de système décisionnel.
Lorsque le datawarehouse est monté, les administrateurs peuvent construire des
métadonnées et des cubes qui vont être envoyés au serveur afin que l’on puisse les utiliser
2
comme source de données pour la création rapport. Pour consulter ces rapports via l’interface
web, les utilisateurs doivent s’authentifier car tous les rapports sont sécurisés.
Le présent travail de mémoire s’est déroulé au sein de la société INGENOSYA dont
l’intitulé est « Mise en place du Système Décisionnel de la Caisse d’Epargne de
Madagascar». Il se divise en trois parties. La première partie décrit la description générale de
la Société INGENOSYA où j’ai effectué mon stage de fin d’Etude et de la Société Caisse d’
Epargne de Madagascar qui est le propriétaire du projet décisionnel là mettre en place. Dans la
deuxième partie, nous mettons en évidence les différentes méthodes pour la réalisation du
projet et la troisième partie est consacrée à la réalisation du projet.
3
PARTIE I :
CONTEXTE GENERAL
4
CHAPITRE 1
PRESENTATION DE LA SOCIETE INGENOSYA
1. Identification
Ingenosya est une société de conseil et d’ingénierie en systèmes d’informations. Filiale
d’une société française, elle a été créée en 1999 et emploie plus de 40 collaborateurs dont :
• La Direction ;
• Les chefs de projets ;
• Une équipe de réalisation encadrée par les chefs de projets.
2. Les activités de la société
L'activité d'Ingenosya est structurée autour de 2 pôles :
• Les systèmes d’information autour de SGBD;
• Le E-business (internet/intranet).
2.1 Prestation
Les prestations d'INGENOSYA sont:
• La maîtrise d'œuvre de projets d'intégration de systèmes (mode forfait) ;
• La délégation de compétences (mode régie) ;
• L’audit, le conseil et la formation ;
Ingenosya est spécialisée dans l’expertise technologique, le conseil, le développement de
solutions applicatives, le testing, l’architecture des systèmes d’information, la business
intelligence, et l’intégration de systèmes.
2.2 La politique qualité
L'orientation volontariste d’INGENOSYA vers la Qualité correspond aux quatre motivations
principales des marchés internationaux et à l'obligation du marché off-shore :
• la qualité correspond à une préoccupation forte de toute maîtrise d'ouvrage,
• la qualité devient un atout primordial dans le monde concurrentiel,
• la qualité est le moyen privilégié d'accroissement de la performance,
• la qualité est le seul moyen de rendre une relation de sous-traitance off-shore
récurrente.
La recherche de la qualité constitue une préoccupation constante d’INGENOSYA. Le Contrôle
Qualité est systématiquement mis en œuvre sur tous les projets avec déclinaison et production
d'un Plan Qualité Projet.
5
CHAPITRE 2
DESCRIPTION DU PROJET A LA CAISSE D’EPARGNE DE MADAGASCAR (CEM)
1. Historique de la création de la Caisse d’Epargne
La Caisse d’Epargne Madagascar est créée en 1918 par le Régime colonial, la société a
toujours fonctionné en tant que section au sein de l’Administration Postale. Depuis l’année
1999, la gestion de la société est privatisée. Actuellement la CEM est constitué de 19 agences
reparties dans toute l’île.
2. La mission des caisses d’Epargne
La Caisse d’Epargne Madagascar a été créée pour encourager, collecter et sécuriser les
ressources financières de personnes faibles revenues ne pouvant pas bénéficier des
services financiers des grandes banques commerciales. Grâce au niveau peu élevé du
dépôt exigé à l’ouverture des comptes et à la possibilité de traiter les transactions de faible
montant, les caisses d’Epargne offrent des services à une clientèle qui autrement ne
pourrait en bénéficier. Depuis toujours, la caisse d’Epargne est la seule institution
accessible à la totalité de la population.
L’activité principale de CEM est de vendre les produits comme:
– le Livret d’Epargne
– le Compte spécial épargne,
– le Compte spécial retraite.
3. Description de la Société Caisse d’Epargne de Madagascar
CEM est constituée de neuf directions
- Direction Générale
- Direction Générale Adjoint
- Direction de l’Administration Générale
- Direction des Systèmes d’Information
- Direction du Contrôle de Gestion
- Direction de l’Audit Interne
- Direction des Affaires Juridique et Contentieux
- Direction des Etudes et de l’Exploitation
- Direction Financière
Et chaque direction est divisée en une ou plusieurs services
6
3.1 Direction Générale (DG), Direction Générale adjoint (DGA)
Sous l’autorité du Directeur Général, le DGA seconde le DG. Il est force de proposition
par rapport à la politique générale de la CEM à proposer au niveau Conseil d’Administration.
La mission de la Direction est de :
– élaborer le plan de travail en début d’exercice suivant les objectifs globaux décidés par le
Conseil d’Administration et en assure le suivi de la politique en termes d’actions.
– travailler en étroite collaboration avec les directions opérationnelles
3.2 Direction du Système d’Information
La Direction est constituée de 3 services:
– Service Etudes et Exploitation,
– Service maintenance et réseau,
– Service Contrôle qualité des données.
La mission de la Direction du Système d’information est de :
– Garantir le bon fonctionnement du Système d’Information
– Défendre et définir la politique et stratégies du Système d’Information par rapport à la
Direction Générale
– Elaborer des besoins matériels et logiciels vis-à-vis des prestataires
3.3 Direction des Etudes / Direction du Réseau et Exploitation
La Direction du Réseau et Exploitation est divisée en trois services :
– Service d’Exploitation
– Service de Contrôle des Opérations
– Service d’Appui aux Agences
L’objectif principal est de satisfaire les clients par secteur d’activité.
3.4 Direction du Contrôle de Gestion
La direction Contrôle de Gestion (DCG) a pour mission d’assurer la rentabilité de la CEM. Elle
est constituée par un service :
– Service Suivi et Contrôle
Le service Suivi et Contrôle a pour mission de répartir le budget dans toutes les agences de la
CEM grâce aux clés de répartition et de suivre sa réalisation.
3.5 Direction de l’Administration Générale
La Direction de l’Administration Générale est composée de deux services :
– Service des Ressources Humaines
– Service Logistique et Approvisionnement
7
La Direction de l’Administration Générale a pour mission de gérer et superviser les services des
Ressources Humaines et logistique c'est-à-dire :
– l’administration du personnel de la CEM ;
– la gestion des facturations rattachées à la Direction Générale
– la gestion des parcs automobile, des agents de sécurité et d’hygiène
– la gestion des approvisionnements et la gestion des stocks ainsi que l’inventaire physique
et théorique des matériels.
3.6 Direction Financière
La Direction est constituée de 2 services :
– Service Comptabilité
– Service Trésorerie
Elle a pour mission de :
– régler le niveau de trésorerie des agences
– visualiser les situations des agences pour les placements
– établir les états financiers de toutes les agences : épargnant, facture, stock,
immobilisation …
3.7 Direction des Audits Internes
La Direction des Audits Internes est constituée de trois services :
– Service de Métier
– Service de Gestion
– Service d’Inspection
La Direction a pour mission de vérifier :
– la comptabilité, la norme et la trésorerie
– la validité des données au niveau des agences
3.8 Direction des Affaires Juridiques et Contentieuses
La Direction des Affaires Juridiques et Contentieuses est constituée de 2 services :
– Service Affaires Juridiques et Contentieuses
– Service Archives et Documentation
La Direction a pour mission de :
– défendre et protéger les intérêts de l’Entreprise
– apporter conseils et assistance à la Société dans le domaine juridique
– travailler en étroite collaboration avec les Directeurs de même niveau structurel, les
Chefs d’Agence sur les questions de droit
– veiller au strict respect des textes législatifs et règlementaires en vigueur
8
4. Organigramme de CEM
CONSEIL D’ADMINISTRATION
DIRECTION GENERALE
DIRECTION GENERALE ADJOINT
Direction du Contrôle de
Gestion
Direction de l’Audit Interne
Direction des Affaires Juridiques et Contentieux
Direction Financière
Direction Commerciale et
Marketing
Direction de l’Administration
Générale
Service SUIVI-
CONTROLE
Service de l’Audit Interne
Orienté Exploitation
Service de l’Audit Interne Orienté Gestion
Service ORIENTATION
DE RECHERCHES QUALITATIVES
Service COMPTABILITE
Service TRESORERIE
ET ENGAGEMENT
Service Produit Livret d’Epargne I
Service Produits
CSR/CSE
Service Appui aux Agences
Service Contrôle des Opérations
Service RESSOURCES HUMAINES
Service LOGISTIQUE
APPROVISIONNEMENT
Service TRAITEMENT
DES DONNEES
Service SYSTEMES ET
RESEAUX
Service ARCHIVES
ET DOCUMENTATION
Direction du Système
d’Information
Service ETUDE
ET EXPLOITATION
Centre de Service
Clientèle
WESTERN UNION
Service ETUDES
RECHERCHE DVPT
Service JURIDIQUE ET CONTENTIEUX
Service SECURITE DES
DONNEES
Service Inspection
Département PRMP - 3 UGPM
FIEFE
Service RELATION PUBLIQUE
9
5. Description des besoins décisionnels de CEM
Le système d’information décisionnel (SID) de la CEM concerne celui du siège et de ses
19 agences réparties sur l’ensemble du pays. Il constitue un outil central du processus de
décision, de contrôle des résultats et d’ajustement des moyens et objectifs.
Les orientations stratégiques de l’entreprise sont déclinées en objectifs avec les moyens pour
les atteindre. Le SID mesure les performances attendues avec les données disponibles via des
indicateurs. Ces indicateurs doivent être fiables et non contestables. Le SID fournit une
information synthétique et consolidée. Il s’agit en quelque sorte du « tableau de bord »
informatisé des dirigeants, produisant des rapports, des graphiques et des tableaux faciles et
rapides à consulter.
L’apport du système d’information décisionnel se situe au niveau de la présentation des
indicateurs de pilotage. Ils sont exprimés selon les grands axes d’analyse de l’activité de
l’entreprise : par exemple les axes produits, secteur d’activité. Ces derniers permettent
d’exprimer et de présenter les indicateurs selon les vues d’analyses variées, par exemple du
plus consolidés au plus détaillés.
Le SID tire ses données des applications opérationnelles. Par conséquent, le flux d’information
est unidirectionnel du système opérationnel vers le système décisionnel.
6. Description des Fonctionnalités de l’application
Les fonctionnalités attendues du système décisionnel sont les suivants :
– Mise à jour automatique du datawarehouse
– Possibilités de traitement des données extraites : incluant la conversion et agrégats
de données de différentes sources et de différents formats
– Fonctions de recherche avec des niveaux de détails variables
– Manipulation des données multidimensionnelles (axes
produit/client/agence/temps…)
– Edition de divers tableaux de bord
– Fonctions de cryptage, gestion sécurisée des droits d’accès aux données
– Utilisation en mode Web
– Interface d’export de données selon un format compatible avec des logiciels de type
tableur
– Sécurité d’accès aux documents décisionnels via un portail web sécurisé.
10
CHAPITRE 3
LA BUSINESS INTELLIGENCE ET LA SOLUTION OPEN SOURCE
1. Les principaux concepts du Business Intelligence
1.1 Qu’est ce que la Business Intelligence?
La Business intelligence ou informatique décisionnelle en français, c’est l’exploitation
des données de l’entreprise dans le but de faciliter la prise de décision par les décideurs.
Pour pouvoir obtenir une vision synthétique de l’ensemble de l’entreprise, il convient
donc de filtrer, croiser et reclasser les données dans un entrepôt de données central. Cet
entrepôt de données va permettre aux responsables de l’entreprise et aux analystes de
prendre connaissance des données à un niveau global et ainsi prendre des décisions plus
pertinentes, d’où le nom d’informatique décisionnelle.
1.2 Différence entre les systèmes opérationnels et les systèmes décisionnels
• Le but de la BI est d'aider à la prise de décision et de permettre des analyses précises,
complexes et de grande envergure dans les entreprises.
• Les systèmes opérationnels font tourner l'entreprise. Ils assistent la production et la vie
quotidienne de celle-ci.
La différence entre le monde opérationnel et décisionnel peut être résumée ainsi :
Tableau 1: Différence entre décisionnel et opérationnel
1.3 Pourquoi la Business Intelligence?
Tout d'abord, la Business Intelligence ou système décisionnel ne concerne que les
entreprises qui gèrent un historique de leurs événements passés. Les entreprises qui viennent
de naître n'ont souvent pas besoin de faire du décisionnel car elles n'ont pas encore besoin de
catégoriser ou de fidéliser leurs clients. Le souci majeur pour elles serait plutôt d'avoir le
Décisionnel Opérationnel
Gros volumes de données à gérer. Petits volumes de données à gérer.
Nombre d'utilisateur restreint (décideurs, analystes). Utilisé par toute l'entreprise. Données en lecture seule. Données en lecture - Écriture. Rapidité moyenne comparée aux systèmes opérationnels.
Réponses très rapides.
Niveau de granularité très grand (on peut avoir des résumés sur ce qui c'est passé durant les 10 dernières années par exemple).
Niveau de granularité fin.
Centralisés (on peut avoir toutes les données de l'entreprise dans une seule structure). Décentralisés.
11
maximum de clients et c'est après en avoir récupéré un grand nombre qu'elles penseront
certainement à les fidéliser et leur proposer d'autres produits susceptibles de les intéresser.
1.4 Qui a besoin du Business Intelligence?
Les décideurs sont les principaux utilisateurs des Business Intelligence. Ils ont besoin de
nombreuses informations et d’indicateurs sur les activités de leurs entreprises pour pouvoir
effectuer les bons choix. En général, ces décideurs sont des marketeurs ou analystes donc
leurs fonctions sont d’établir des plans marketing qui leur permettent de mieux cibler leurs
clients, de les fidéliser etc. Et pour cela, ils ont besoin d'indicateurs et des données résumées
de leurs activités. Contrairement aux systèmes relationnels où les utilisateurs chercheront à
connaître leurs transactions pour faire un bilan, les systèmes décisionnels eux cherchent plutôt
à donner un aperçu global pour connaître les tendances des clients.
2. Architecture de la Business Intelligence
La Business Intelligence compose le système d’information décisionnel de l’entreprise. Un
système décisionnel est composé de trois phases:
– Phase d’alimentation
– Phase de stockage
– Phase de restitution
Le schéma d'architecture de Business Intelligence est le suivant :
Figure 1: Architecture du Business Intelligence
OracleOracleOracleOracle
Excel
ODS
EEEExtraction
TTTTransformation
Chargement Chargement Chargement Chargement
DWH
Cube
Datamart
Reporting
Base de donnéesBase de donnéesBase de donnéesBase de données
Phase d’alimentation Phase de
stockage Phase de
Restitution
DatawarehouseDatawarehouseDatawarehouseDatawarehouse
EEEExtraction
Transformation
Chargement
12
2.1 Phase d’alimentation
Les phases de l'alimentation du datawarehouse sont les suivantes :
- Découvrir quelles sont les données à faire migrer.
- L’acquisition des données se déroule en trois phases :
• l’extraction,
• la transformation et
• le chargement.
Un logiciel ETL permet d’assurer la phase d’alimentation du datawarehouse.
Pour extraire les données, il convient d'aller chercher les données là où elles se trouvent.
Connecté aux différentes applications et bases de données, l'outil d'ETL se charge de récupérer
ces données et de les centraliser dans un datawarehouse pour une fréquence fixée.
2.1.1 L'extraction des données
L’extraction des données consiste à collecter les données utiles dans le système
de production. Pour rafraîchir la base décisionnelle, il faut identifier les données ayant évolué
afin d’extraire le minimum de données, puis planifier ces extractions afin d’éviter les
saturations du système de production.
Dans l’architecture ci-dessus, on dispose deux sources de données:
• la base Oracle et
• les fichiers Excel
Ces deux sources de données d’entreprise sont utilisées en entrée pour être mises en
commun dans un stockage de donnée intermédiaire appelé ODS (Operational Data Store).
2.1.2 La transformation des données
Les données issues de cet ODS doivent passer par plusieurs transformations avant
d’être chargées dans le datawarehouse c'est-à-dire les données doivent être nettoyées, filtrées
et agrégées.
2.1.3 Le chargement des données
Le chargement est la dernière phase de l’alimentation du datawarehouse. C’est une
phase délicate notamment lorsque les volumes sont importants, comme les données dans
un datawarehouse ne peuvent plus être effacées ni modifiées dans ce cas il faut bien s’assurer
que les données qu’on va chargées ne comportent plus d’erreur.
2.2 Phase de stockage
Ensuite, une fois le datawarehouse est monté, on pourrait créer différentes types des
données telles que :
- les métadonnées
13
- les cubes et
- les datamarts.
Les données dans les cubes et métadonnées sont extraites dans des serveurs d'analyse
ou serveurs OLAP sous forme de cubes de données ou de métadonnées afin d'être analysées.
On appelle « cube» une représentation des données selon des axes. Cette structure présente
de nombreux avantages pour des applications de Business Intelligence, en particulier la
capacité à faire évoluer, recalculer et transformer les tableaux de bord.
2.3 Phase de restitution
Cette phase appelée reporting, se charge de présenter les informations à valeur ajoutée
de telle sorte qu'elles apparaissent de la façon la plus lisible possible dans le cadre de l’aide à
la décision. Les données sont principalement modélisées par des représentations à base de
requêtes afin de constituer des tableaux de bord ou des rapports via des outils d'analyse
décisionnelle.
La figure suivante montre le processus des données depuis la base de production
jusqu’aux utilisateurs finaux.
Figure 2:Processus des données depuis la production jusqu'aux utilisateurs
14
PARTIE II
METHODOLOGIE
15
CHAPITRE 1
ETAPE DU PROJET DECISIONNEL
1. Le préalable du projet
1.1 Etude du domaine métier
Cette étape est fondamentale. En effet, si vous voulez travailler dans le décisionnel
vous êtes obligé de connaître le métier de l'entreprise pour laquelle vous allez travailler. Alors
si vous êtes nouveaux, familiarisez-vous avec les termes utilisés, regardez sur l'intranet de
l'entreprise ou sur leur site.
1.2 Interview des acteurs clés du métier
Un autre élément tout aussi important que l'étude de l'environnement est la
connaissance des acteurs métiers. Si on ne connaît pas bien l'organigramme on pourrait se
planter sur les bonnes questions à poser aux bonnes personnes. Il y a deux types d’acteurs
qu’on doit interviewer :
– les acteurs opérationnels
– les acteurs décisionnels
1.2.1 Les acteurs opérationnels
Cette catégorie regroupe tous les acteurs intervenant dans le processus de
production de données. Ce sont autant les responsables de production des différentes
directions de la société que les acteurs intervenant du point de vue technique sur le
système d’information de l’entreprise et chargés de mettre à disposition les données
nécessaires à l’alimentation du système décisionnel.
Ainsi les besoins de cette catégorie d’utilisateurs du portail décisionnel s’articuleront
autour de questions semblables suivantes :
– Comment rendre disponibles en un même endroit et au même moment des
informations provenant d’unités de production différentes utilisant divers systèmes
de stockage de données?
– Comment assurer la cohérence des informations fournies sur le portail décisionnel?
– Qui a accès à quelle information et sous quelle forme ?
– Comment organiser la circulation des documents ?
– Comment élaborer l’information synthétique destinée à la prise de décision ?
– Comment améliorer la vitesse de la mise à disposition de l’information ?
16
1.2.2 Les acteurs décisionnels
Etre détenteurs du pouvoir de décision, cette catégorie d’utilisateurs joue un rôle
primordial lors de l’étude. C’est en collaboration avec les décideurs que seront
détaillées toutes les fonctionnalités du portail décisionnel. La démarche usuelle consiste a
recueillir les besoins exprimes par les décideurs a travers des interviews et parfois des «
check-list ». L’implication des utilisateurs décideurs permettra ainsi de répondre, entre autres,
aux questions suivantes :
– quels sont les indicateurs stratégiques que le décideur voudrait observer ?
– quelle est la pertinence de chacun de ces indicateurs pour l’entreprise ?
– quels sont les paramètres (axes d’analyse) à prendre en compte ?
– sous quelle forme l’information doit-elle être présentée ? (rapports, tableau de bord,
graphiques, …)
– comment le décideur va-t-il accéder à l’information ?
– comment sécuriser les informations ?
– avec quelle fréquence l’information doit-elle être actualisée ?
1.3 Découpage des besoins en thèmes/sujets
Après l’interview, il est toujours bien de faire un compte rendu de réunion. Cela permet
par la suite de dégager les différents business process à implémenter dans le business model.
A partir des comptes rendus de réunion il faudra d'abord classer les besoins en thèmes ou
sujets d'analyse. Comme dans les domaines de ventes, le responsable de voudra étendre ses
produits dans le maximum de régions possibles et pour cela lors de l'interview il demandera à
pouvoir disposer d'un outil qui lui permettra de bien évaluer les zones fluides en terme de
vente. De même, lors de l'interview de la personne clé du département marketing, ce dernier
voudra analyser les catégories de produits qui susciteront le plus d'intéressements de la part
de la jeune clientèle. Ces deux besoins différents seront classés dans 2 thèmes ou sujets
différents.
1.4 Analyse des données
Après avoir collecté les besoins décisionnels en termes de tableau de bord et avoir recensé les
sources de données disponibles, la réalisation de projet passe à une étape suivante qui est
l’analyse des données. Cette étape consiste à
– étudier si un tel indicateur demandé par une telle direction est réalisable ou non et les
données nécessaires au calcul de cet indicateur est elle disponible dans leur base de
production.
– instaurer de langage commun pour qualifier chaque notion et supprimer les ambiguïtés
en les consignant dans le dictionnaire des données extraites du système d’information.
– définir la granularité de chaque donnée.
17
1.5 Spécification des flux de données
Cet étape a pour objectif de définir le parcours de données depuis l’extraction des
données de production jusqu’au datawarehouse.
Après la collecte des données, un outil d’ETL permettra de nettoyer, consolider les
données de l’entreprise pour l’alimenter dans le datawarehouse.
Le flux est associé à une fréquence d’exécution des traitements (traitement journalier,
hebdomadaire, mensuel, sur événement, à la demande de l’administrateur).
Le flux partant des données de production (fichiers, base de données) vers l’ODS.
2. Modélisation d’un datawarehouse
2.1 Qu’est ce que le datawarehouse ?
Un datawarehouse appelé aussi entrepôt de données est défini comme une collection
de données thématiques, intégrées, non volatiles, historisées, et organisées pour la prise de
décision [Inmon 96]. Il permet de produire des rapports qui répondent à la question Que
s’est-il passé ? mais il peut être également conçu pour répondre à la question analytique
Pourquoi est-ce que cela s’est passé? et à la question pronostique Que va-t-il se passer?
2.2 Données thématique
Les données dans le datawarehouse sont structurées autour de thèmes ce qui facilite
l’analyse transversale. Pour éviter le doublonnage des données, on regroupe les différents
sujets dans une structure commune. Ainsi, si le sujet client contient des informations dans les
sujets marketing, ventes, analyse financière, on regroupe ces trois sujets au sein du thème
client. Dès lors, chaque donnée n’est présente qu’à un endroit et le datawarehouse joue bien
un rôle de point focal.
2.3 Données intégrées
Les données sont mises en forme selon un standard afin d’obtenir la transversalité
recherchée. Cela nécessite une forte normalisation, une bonne gestion des référentiels et de la
cohérence, une parfaite maîtrise de la sémantique et des règles de gestion des données
manipulées. Lors de l’alimentation des données, ces dernières sont hétérogènes et proviennent
des sources différentes. Il faut doter ces données d’une codification unique et pertinente afin
qu’elles puissent aisément s’intégrer dans le datawarehouse. Il faudra donc faire appel à des
conventions de nommage, des structures de codage, qualifier les mesures et réaliser
l’intégration de la sémantique. Voici un exemple d’unification de codage:
Figure 3 : Nettoyage des données
Ar Fmg
Ariary
Ar
18
2.4 Données non volatiles
Les données intégrées dans le datawarehouse ne peuvent subir aucune altération. Cela
se justifie pour assurer la fiabilité des résultats des requêtes. Ainsi, une même requête lancée
à plusieurs mois d’intervalle donnera toujours les mêmes résultats. Cela permet au
datawarehouse d’acquérir au cours du temps un historique détaillé de l’activité de l’entreprise.
Ceci s’oppose fondamentalement à la logique des systèmes de production qui remettent à jour
les données qui sont de nature volatiles.
2.5 Données historisées
L’ensemble des données qui sont intégrées dans le datawarehouse contient un
ensemble de caractéristiques qui sont datées. L’historisation est nécessaire pour suivre dans le
temps l’évolution des différentes valeurs des indicateurs à analyser. Ainsi, un référentiel temps
doit être associé aux données afin de permettre l’identification dans la durée de valeurs
précises. Si tel n’était pas le cas, l’analyse ne serait pas possible, le suivi de l’évolution non
plus. Cela rejoint la notion de non volatilité expliquée précédemment.
2.6 Structure d’un datawarehouse
On distingue habituellement deux types de tables dans un datawarehouse :
1. les tables de dimension et
2. les tables de faits.
2.6.1 Table de dimension
On entend par dimension les axes avec lesquels on veut faire l'analyse. Dans le monde
du système décisionnel, un business process représente une activité d’une entreprise et les
objets qui entrent en jeu dans cette activité constituent eux les dimensions. Alors si l'on
considère le business process commandes, les acteurs qui participent à l'activité peuvent être
le client, le produit et certainement le temps.
Les dimensions sont les points de vue depuis lesquels les mesures peuvent être observées
2.6.2 Structure de table de dimension
La table de dimension est constituée de :
– Clé technique : c’est la clé primaire de la table de dimension
– Clé naturelle : c’est la clé primaire de la table source.
– Numéro de version : c’est le numéro de version de donnée, il assure la gestion de
l’historisation des données.
– Date de début plage (date_from): date de la dernière mise à jour des données
– Date de fin plage (date_to) : date de la mise à jour des données
En général, la table de dimension a la structure suivante :
19
Clé technique
Clé naturelle
Attribut 1
Attribut 2
- - - - - -
Attribut n
Numéro de version
Date de début plage
Date de fin plage
Figure 4: Structure de la table de dimension
2.6.3 Table de fait
Un fait est tout ce qu'on voudra analyser. Pour détecter les tables de faits, il faudra se
servir des éléments recueillis lors de la phase d’interview c'est à dire des différents business
process. Il faudra donc pour chaque business process se demander quels sont les éléments
dont on souhaite mesurer. Par exemple, pour le business process commandes, on pourrait
définir les mesures suivantes : prix unitaire, prix d'achat, etc.
2.6.4 Structure de table de fait
La table de fait est constituée de:
– plusieurs clés appelés clés techniques reliant la table de fait aux tables de dimension.
– attributs appelés mesures.
Les mesures ce sont les indicateurs de performance d’une entreprise. Ces valeurs sont le
résultat d’une opération d’agrégation des données.
La table de fait contient la structure suivante :
Figure 5: Structure de la table de fait
idTek_Dim1
idTek_Dim2
idTek_Dim3
mesure1
mesure2
mesure3
20
2.6.5 Type de modèle
L’objectif majeur d’un système décisionnel est l’analyse de la performance. On mesure
cette performance au travers des indicateurs que l’on a retenus lors de la phase d’analyse
des données. Ces indicateurs vont donc être la base de la modélisation dimensionnelle et être
regroupés dans une table dite table des faits. Et les axes dans lesquels on va observer
l’évolution de ces indicateurs sont mis dans des tables appelées tables de dimension.
Dans la construction de datawarehouse, deux types de modèles sont généralement
utilisés :
– Modèle en étoile et
– Modèle en flocon
2.6.5.1 Modèle en étoile
Le modèle en étoile est constitué :
– de table de fait et
– des plusieurs tables de dimension à un niveau.
Figure 6: Modèle en étoile
Dans un schéma en étoile, une table centrale de faits contenant les faits à analyser,
référence les tables de dimensions par des clefs étrangères. Chaque dimension est décrite par
une seule table dont les attributs représentent les diverses granularités possibles.
Avantages :
– Facilité de navigation
– Performances : nombre de jointures limité ; gestion des données creuses.
– Gestion des agrégats
Inconvénients :
– Toutes les dimensions ne concernent pas les mesures
21
– Redondances dans les dimensions
– Alimentation complexe.
2.6.5.2 Modèle en flocon
Le modèle en flocon est constitué :
– de table de fait et
– de plusieurs niveaux de tables de dimensions.
Figure 7: Modèle en flocon
Dans un schéma en flocon, cette même table de faits, référence les tables de
dimensions de premier niveau, au même titre que le schéma en étoile. La différence réside
dans le fait que les dimensions sont décrites par une succession de tables représentant la
granularité de l'information. Ce schéma évite les redondances d’information mais nécessite des
jointures lors des agrégats de ces dimensions.
Avantage :
– réduction du volume,
Inconvénients :
– navigation difficile,
– nombreuses jointures.
22
3. Spécification des restitutions
L’objectif de cette étape est de proposer un premier niveau de description des restitutions
aux utilisateurs et de spécifier les services du portail. D’après les données des comptes rendus
d’interviews et les dictionnaires des données extraites, on a pu :
– spécifier les indicateurs,
– spécifier les types de rapports, le type d’analyses,
– spécifier les axes d’analyse majeurs,
– spécifier les utilisateurs.
4. Choix des progiciels de la Business Intelligence
Après la modélisation, le choix des progiciels de la Business Intelligence répondant trois
besoins fondamentaux :
– collecter, nettoyer et consolider les données de l'entreprise étendue
– stocker les données
– exploiter l'information de l'entreprise étendue
Pour mettre en place un système décisionnel, la société prestataire a deux choix, soit:
– développer un logiciel propre à la société
– choisir un logiciel et l’adapter aux besoins de la société.
Ces deux solutions ont chacune leur avantage et leur inconvénient.
23
CHAPITRE 2
LES PROGICIELS DE LA BUSINESS INTELLIGENCE
1. Qu’est ce que l’Open Source ?
L’Open Source est appelé aussi code source libre en Français désigne le logiciel dont la
licence dite libre donne à chacun le droit d'utiliser, d'étudier, de modifier, de dupliquer, et de
diffuser le dit logiciel.
2. Les critères du choix des progiciels de la Business Intelligence
Les progiciels de la Business Intelligence répondent à trois besoins :
– collecter, nettoyer et consolider les données de l'entreprise étendue
– stocker les données
– exploiter l'information de l'entreprise étendue.
Actuellement plusieurs types de logiciels Open Sources de BI sont disponibles. Mais notre
choix est tourné autour de deux outils :
– Pentaho
– Vanilla.
3. Pentaho
Pentaho est une suite logicielle qui permet la distribution de fonctionnalités et
documents décisionnels à un grand nombre de personnes par l'intermédiaire d'une application
Web ou un portail. Il est possible de consulter des états, d'utiliser les fonctions d'exploration de
données de Mondrian/JPivot, et de créer des tableaux de bord.
3.1 Outils et composants décisionnels de Pentaho
Pentaho porte sur toute la chaîne décisionnelle et utilise différents outils et
composants décisionnels open source :
– Pour la collecte et l'intégration des différentes bases de on utilise Kettle.
– Pour la création de la métadonnée : MetaDataEditor
– Pour la présentation des données et des rapports on utilise : Report Designer
– Pour la création de cube : Schema WorkBench
– Pour la diffusion (portail) : JBoss Portal, TOMCAT
3.1.1 Kettle
Kettle est un ETL open source appelé aussi Pentaho Data Integration (PDI) qui permet
de concevoir et exécuter des opérations de manipulation et de transformation de données.
Kettle permet de créer deux types de processus :
24
• les transformations : traitements effectués au niveau d'une ou plusieurs bases de données
comprenant des opérations de lecture, de manipulation et d'écriture.
• les tâches : traitements de plus haut niveau, combinant des actions telles que l'exécution
d'une transformation Kettle, l'envoi d'un mail, le téléchargement d'un fichier ou le lancement
d'une application. Il est possible d'exécuter des actions différentes en fonction de la réussite ou
de l'échec de chaque étape.
3.1.2 MetaDataEditor
Le MetaDataEditor est un module de pentaho utilisé pour la création de métadonnée.
Son interface principale est la suivante :
Figure 8: Interface de MetadataEditor
3.1.3 ReportDesigner
Le ReportDesigner est un outil dans pentaho destiné pour la création de rapport. Son
interface principale est la suivante :
Figure 9: Interface de Report Designer
25
3.1.4 Schema WorkBench
Le Schema workbench est un outil contenu dans le progiciel Pentaho. Il sert à construire
des cubes multidimensionnels et permet de faire des requêtes MDX (Multi Dimensional
eXpression) qui est un langage pour les bases de données multidimensionnelles.
L’interface principale du Schema workbench est comme suit :
Figure 10: Interface du Schema Designer
3.2 Portail Web
L’interface web de Pentaho :
Figure 11: Interface Web de Pentaho
26
4. Vanilla
4.1 Architecture du Platform Vanilla
Le progiciel Vanilla est constitué :
- d’un portail,
- d’un référentiel qui enregistre tous les développements : modèles, rapports,
ressources, dossiers du portail,
- d’un outil appelé EnterpriseServices qui assure la gestion de sécurité et la
configuration.
Figure 12: Architecture de Vanilla
4.2 Outils et composants décisionnels de Vanilla
Vanilla est un logiciel Open Source créé par la fondation BPM. Il est constitué de trois types de
modules :
- modules Web
- modules java
- module de gestion de sécurité
• Modules Web
Le module web de vanilla est constitué par :
27
- un portail web pour la diffusion des documents au travers d’une interface Web, la
gestion des utilisateurs et des sécurités, la consultation de rapports créés en Birt.
- un module FreeAnalysisWeb utilisé pour la visualisation de cube, avec des fonctions de
tableurs intégrés.
- un module FreeWebReport utilisé pour la création de rapports Web à partir des
métadonnées sécurisées
• Module java
Le module java de vanilla est constitué par :
- un module FreeMetadata, pour la création des modèles de métadonnées.
- un module FreeAnalysisSchemaDesigner, pour la création des cubes à partir de source
des données SQL.
- Un outil Birt pour la création de rapports, avec utilisation de source de données
FreeMetadata.
- un module FreeAnalysis, pour la création de modèles Olap avec utilisation de source
de données le cube.
• Module de gestion de sécurité
Le module de gestion de sécurité appelé Enterprise Services assure les fonctions
suivantes :
- une gestion des utilisateurs, des groupes, des rôles et des sécurités d’accès aux
différents objets
- une interface d'exploration du contenu du référentiel (visualisation XML des
documents),
- une fonction de déploiement de packages entre serveur par import/export de
différents objets entre serveurs
- des fonctions d'analyse d'impact et de référence croisée entre les documents (par
exemple : quels sont les rapports qui sont créés à partir de tel document de méta
données).
4.2.1 FreeMetaData
C’est un module de vanilla qui permet de présenter et d’organiser les données
provenant de différentes sources de données sous la forme de packages sécurisés, orientés
« vue métier », avec des stratégies de jointures et une gestion des accès conformes aux
contraintes de déploiement en entreprise.
Pour attribuer de sécurité aux objets, il faut que le serveur vanilla soit démarré afin de
récupérer tous les groupes des utilisateurs.
L’interface principale du logiciel est divisée en deux parties :
28
Figure 13: Environnement de FreeMetadata
- la partie de gauche permet de naviguer dans les différents objets du document
- et la partie droite affiche les différentes propriétés de l'objet sélectionné.
La partie gauche est composée de 3 parties distinctes, chaque partie correspondant à
une étape précise du cycle de création et maintenance d'un document de type «méta
données» :
DataSources: spécification des différentes sources de données, avec les tables et vues des
différentes bases à intégrer au modèle.
Resources: prompt et filtres.
Business Models: conversion de chemin physique en chemin logique « business »
Business Package : Partie d'un business modèle destinée au reporting utilisateur.
4.2.2 FreeAnalysisSchemaDesigner
Le FreeAnalysisSchemaDesigner (FASD) est une des modules de Vanilla utilisée pour la
conception des cubes.
L'interface du FreeAnalysisSchemaDesigner contient 6 panneaux :
Datasources : contient les tables de faits et de dimensions, et les relations entre les tables
Dimensions : permet de créer des dimensions, hierarchies et niveaux
Measures : gestion des mesures
Cubes : gestion des cubes et des cubes virtuels
Properties : panneau de saisie des propriétés
Dimension security: gestion des sécurités sur les cubes
29
Figure 14: Environnement de FASD
4.2.3 Enterprise Services
L’Enterprise Services est une interface Java conçue afin de gérer la sécurité, le contenu
du portail, les connexions aux sources de données, le déploiement des packages, la gestion
des référentiels. C’est par ce module qu’on va créer les utilisateurs et les groupes aux quels ils
appartiennent.
L’interface principale de l’Entreprise Services est illustrée par la figure suivante :
Figure 15: Environnement de l'Entreprise Service
30
CHAPITRE 3
CONCEPTION DU PROJET BUSINESS INTELLIGENCE DE LA CEM
Pour bien mener le pilotage de la Société CEM, les dirigeants de la société ne doivent pas
seulement avoir une vue verticale de ses métiers (Système de gestion) mais ils doivent avoir
une vue plutôt transversale (Système décisionnel), dans ce cas ils ont eu l’idée d’améliorer leur
système d’information en mettant en place un système de Business Intelligence. La mise en
place de ce système a été assurée par la Société INGENOSYA.
1 Collecte des besoins décisionnels
1.1 Etude du domaine métier de CEM
Pour connaitre et comprendre les métiers, les processus et les indicateurs clés
permettant de répondre la problématique de CEM, l’équipe d’INGENOSYA font des collectes
des besoins décisionnels de CEM en passant par toutes les directions en interviewant tous les
différents dirigeants de la société et en demandant les types de tableau de bord qu’ils peuvent
obtenir actuellement et leurs attentes sur le logiciel qu’on va mettre en place.
1.2 Interview des acteurs clés du métier
Cette interview ne concerne pas seulement les dirigeants mais aussi les acteurs
opérationnels afin de connaître toutes les sources des données de la société, et d’avoir une
idée sur les bases de données qu’ils ont utilisées et la mise à jour de ces données. C’est par les
acteurs opérationnels qu’on peut obtenir les formules des indicateurs demandés par les
directeurs dans le tableau de bord.
1.3 Découpage des besoins en thèmes/sujets
Le projet décisionnel peut être découpé en plusieurs domaines, et les domaines peuvent
être découpés en plusieurs thèmes. Dans le cadre du projet décisionnel de CEM, les domaines
sont représentés par les Services et les thèmes correspondent aux activités existant au niveau
de chaque service.
31
Voici un classement des données par thème, par domaine et par application d’origine : Tableau 2: Extrait de découpage des besoins en thèmes/sujets
Domaine Thème d’analyse Données Application d’origine
Ressources Humaines
Gestion de congés de personnel
nombre de retard, nombre d’absence, nombre de congés
Fichier Excel
Gestion des Etats des retenus sur salaire
Montant des frais médicaux, montant des avances, montant des prêts alloué, montant des retenus sur salaire
CGB
Gestion de carrière
Nombre de personnel participant à une formation, montant des formations, nombre de personnel ayant tel diplôme, nombre de formations attribuées par CEM
Fichier Excel
Suivi des frais médicaux
montant de frais médicaux, nombre de repos médical, nombre de consultation médicale
Fichier Excel
Entreprises prestataires médicaux
Dépenses pour les entreprises prestataires médicaux
Fichier Excel
Etudes et Exploitation Suivi des opérations
Nombre Ouverture de compte, Nombre Ouverture de compte, Montant du premier versement, Nombre du versement ultérieur, Montant du versement ultérieur, Nombre de fermeture de compte, Nombre de compte sans mouvement depuis plus de 3 mois, Montant total du solde par produit
CGB
2 Analyse des données
Par la voie de collecte des besoins décisionnels de CEM et l’interview effectuée aux opérateurs,
on obtient le dictionnaire de données.
Le tableau suivant indique l’extrait de dictionnaire de données obtenu:
32
Tableau 3: Extrait de dictionnaire de données
MOT SIGNIFICATION absence Absence sans permission id…. Numéro d’identification unique à incrémenter pour
chaque enregistrement Libelle… Nom ou description unique portant le numéro
d’identification Montant… montant ou prix en Ariary nomPersonnel Nom et prénom de l’employé sexe Sexe de l’employé poste Poste occupé par l’employé au sein du service LieuDeJouissance Adresse exacte du lieu où est l’employé pendant son
absence ou congé titreFormation Titre de la formation Duree de la Formation Durée d’une formation en jour spécialité spécialité de l’employé participationCEM Montant de l’indemnité attribuée par la CEM pour une
consultation médicale participationPersonnel Montant payé par l’employé pour une consultation
médicale IM Numéro d’immatriculation des agents (sécurités et
ménage) nombreAbsJour Nombre d’absence par jour (1 pour une demi-journée et
2 pour une journée d’absence) dateHeure Date et heure de début de mission d’un chauffeur dureeHeure Durée en heure de la mission par jour Nombre de mission Nombre de mission par jour d’un chauffeur Agence Secteur congé Absence accordée après une permission
3 Spécification des flux de données
Actuellement, les seules données sources opérationnelles disponibles seront issues des
données de l’application métier et des données comptables, appelées données des applications
« CGB ». Certaines directions utilisent des fichiers Excel pour leurs besoins opérationnels.
Suite à la demande de la CEM, nous avons élaboré des fichiers Excel sources. Leur remplissage
s’effectuerait aux soins de la CEM. A l’heure actuelle, ils sont au nombre de 57. Le nombre
important de fichiers à manipuler et à mettre à jour contribue à amenuiser la robustesse de
l’application sans compter que la mise à jour de ces fichiers nécessite une synchronisation fine
entre eux.
Dans un premier temps, les données vont être extraites et transformées pour être
alimentées dans un ODS, puis elles seront agrégées, filtrées avant d’être stockées dans le
datawarehouse (DWH). L’alimentation du datawarehouse peut être manuelle, elle peut être
aussi automatique grâce à l’outil planificateur de tâche appelé « quartz » du pentaho. Pour
l’alimentation automatique, elle est associée à une fréquence qui est fixée par l’administrateur,
cette fréquence peut être:
- journalière
- hebdomadaire
- mensuelle
33
En cas d’erreurs, la gestion de rejets doit être disponible dans le flux. Les rejets sont de
plusieurs types :
- données non référencées,
- données manquantes,
- données ne respectant pas le format attendu.
Si l’extraction s’effectue depuis un fichier Excel, le système génère un fichier qui
contient les lignes en erreur (pour un traitement ultérieur manuel). L’administrateur peut
décider de « rejouer » manuellement pour exécuter de nouveau une intégration qui a échouée.
Seules les lignes qui ont échouées seront intégrées dans nouvelle exécution.
4 Modélisation d’un datawarehouse
Pour la mise en place du Datawarehouse de CEM, le type de modélisation choisi est le
Modèle en étoile. Ce choix est dû à la performance de ce type de model par rapport au model
en flocon.
5. La restitution
5.1 Les tableaux de bord
Les tableaux de bord demandés par CEM peuvent se présenter de différentes formes :
– Liste
– Rapport croisé
– Rapport avec graphe
– Rapport paramétré
Ce tableau de bord est constitué des indicateurs et des axes d’analyse.
5.2 Spécification des indicateurs
Les indicateurs représentent les mesures existantes au niveau des activités de CEM. Le
tableau suivant représente les exemples d’indicateurs du domaine Etude et Exploitation de
CEM.
34
Tableau 4: Extraits des indicateurs de CEM
Indicateur
Solde du compte des différents produits Solde du compte des dépôts à terme Montant du budget par produits Montant des réalisations par produits Solde du compte des investisseurs institutionnels Solde du compte des entreprises Solde du compte des particuliers Nombre de comptes des investisseurs institutionnels
Nombre de comptes des entreprises
Nombre de comptes des particuliers
Nombre de comptes ouverts en dépôt à vue
Nombre de comptes ouverts en dépôt à terme
Nombre de comptes ouverts en bon de caisse
Nombre de comptes ouverts en compte épargne
Nombre de comptes ouverts en Autres ressources
Solde des crédits à court terme
Solde des crédits à moyen terme
Solde des crédits à long terme
Solde des mobilisations de créances
Solde des mobilisations de créances
Solde des avances sur marchandises
5.3 Les principaux axes d’analyse
5.3.1 L’axe temps
Dans le monde du décisionnel, la dimension temps est une dimension universelle. La
figure suivante représente la dimension temps avec ses hiérarchies :
Figure 16: Hiérarchie de l’axe Temps
5.3.2 L’axe organisation
Il s’agit d’une description d’un point de vue macroscopique de l’organisation sur laquelle
porte l’analyse. La figure ci-dessous représente l’axe d’organisation de la Caisse d’Epargne de
Madagascar sur laquelle porte notre étude.
Année Mois Jour
35
Figure 17: Organisation de CEM
5.3.3 L’axe client
Il s’agit de la description des hiérarchies des clients («Client», «Catégorie de client»).
Un client peut être un investisseur, une entreprise ou un particulier si l’on prend l’exemple des
situations d’épargne de la CEM.
Figure 18: Hiérarchie de l’axe Client
5.3.4 L’axe produit
C’est une description des hiérarchies des produits («Produit», «Catégorie de produit»,
«Type de produit»). Toujours dans l’exemple de la situation d’épargne de la CEM, un type de
produit peut être un compte épargne, une catégorie de produit peut être un livret d’épargne et
le produit est «Mitsimbina».
Figure 19: Hiérarchie de l’axe Produit
CEM
Siège Agences
Directions
Services
Type de produit
Catégorie de produit
Produit
Catégorie de client
Client
36
5.4 Les utilisateurs
Les utilisateurs regroupent les personnels ayant accès au portail décisionnel. Ces
utilisateurs, pour accéder au portail, ils doivent appartenir à un ou plusieurs groupes. Ces
derniers portent la sécurité du portail. Dans le cadre de ce projet, le groupe correspond au
service existant dans la direction de CEM.
Pour accéder au portail, l’utilisateur doit s’authentifier avec un «login» et un «mot de passe».
Voici donc, un extrait de liste des utilisateurs avec leur groupe :
Tableau 5: Extrait de liste des utilisateurs avec leur groupe
Groupe Utilisateur Ressources Humaines • Directeur de l’Administration Générale
• Chef de service Ressources Humaines • Utilisateur(s) Ressources Humaines
Exploitation • Directeur des Etudes • Chef de service Exploitation • Utilisateur(s) Exploitation
Contrôle des opérations • Directeur des Etudes • Chef de service contrôle des opérations • Utilisateur(s) contrôle des opérations
Suivi et contrôle • Directeur du contrôle de gestion • Chef de service suivi et contrôle • Utilisateur(s) suivi et contrôle
Comptabilité • Directeur financier • Chef de service comptabilité • Utilisateur(s) comptabilité
Etudes et exploitation • Directeur du système d’information • Chef de service études et exploitation • Utilisateur(s) études et exploitation
Maintenance et réseau • Directeur du système d’information • Chef de service maintenance et réseau • Utilisateur(s) maintenance et réseau
Inspection
• Directeur des audits internes • Inspecteur(s)
Affaires juridiques et contentieuses
• Conseiller juridique • Utilisateur AJC
5.5 Choix de logiciels
L’objectif de cette étape est d’évaluer et de sélectionner les briques logicielles du
marché nécessaire à la construction du portail décisionnel. Les portails décisionnels sont
principalement construits avec des briques logicielles du marché, rarement avec des solutions
spécifiques. Une part importante des critères d’évaluation des produits concerne des
caractéristiques techniques. Le poids de l’évaluation technique est identique à celui des critères
fonctionnels. Les enjeux techniques concernent les performances.
5.5.1 Les briques logicielles de gestion des flux (ETL)
Les critères principaux de sélection d’un logiciel de gestion de flux sont :
• La capacité à pouvoir gérer des transformations complexes ;
37
• La facilité du développement et du paramétrage ;
• La maintenabilité des développements effectués ;
• La facilité d’intégration dans l’environnement d’exploitation du système informatique.
5.5.2 Les briques logicielles de stockage
Parmi les critères de sélection d’un logiciel de stockage figure son aptitude à gérer
efficacement les contraintes de stockage, inhérentes aux systèmes décisionnels ; le produit
doit être conçu dans cet objectif. Sa capacité à gérer de très gros volumes de données ainsi
que sa capacité à gérer des cubes OLAP constituent des critères de sélection supplémentaires.
5.5.3 Les briques logicielles de restitution
Le choix du logiciel de restitution porte sur les services proposés aux utilisateurs.
Une manière d’évaluer la restitution consiste à réaliser une maquette ou un prototype.
L’évaluation peut porter, au moins sur les cinq axes suivants :
• le nombre d’utilisateurs simultanés ;
• les types de restitutions proposés (les rapports prédéfinis, les requêtes à la demande, la
navigation multidimensionnelle) ;
• la performance de la restitution, liée au temps de réponse (confort de la navigation) ;
• la complexité des états de restitution ;
• la volumétrie des données consultables.
5.6 Justification de choix
Le choix le plus difficile dans tout projet décisionnel consiste à déterminer quelle méthode
doit être mise en œuvre :
• faut-il créer du code spécifique (procédures SQL, code Java ou autre)?
• faut-il acheter un logiciel spécifique?
La première solution semble intéressante, car elle permet de rester au plus près des
spécificités métiers des données à traiter, tout en s'affranchissant des contraintes liées à
l'achat et l'utilisation d'un ETL propriétaire. Cependant, cette solution peut s'avérer coûteuse à
long terme, tout simplement car l'évolutivité constante des données métier entraîne un
nécessaire adaptation des traitements d'intégration. Celle-ci n'est pas toujours facile à
gérer, surtout si les équipes projets évoluent au cours du temps.
La deuxième solution va permettre de mettre en oeuvre très rapidement les traitements
d'intégration, avec cependant des coûts élevés (achat des licences, formations,...) et ceci dès
la phase de démarrage du projet.
38
Il existe désormais une solution alternative: utiliser de logiciel Open Source. En utilisant
ce type de logiciel, on bénéficie de tous ses avantages tout en gardant une maîtrise sur des
coûts. Ces derniers sont en effet réduits aux coûts de formation initiale de l'outil. Aucune
licence n'est à payer dans ce modèle économique. C'est donc dans cette 3ème approche que
se positionnent les logiciels « Vanilla » et « Pentaho ».
Dès lors que la CEM s’engagera à respecter les termes des licences de logiciel libre, la
CEM est parfaitement autorisée à les exploiter pour la mise en service de leur système.
5.7 Le choix entre les progiciels PENTAHO et VANILLA
L’application décisionnelle qu’on va placer est destinée aux décideurs de CEM, ces
groupes de personnes ne sont pas forcement des informaticiens. Puisque l’objectif est que
chaque utilisateur doit être capable de créer ses propres rapports, dans ce cas le critère de
CEM repose surtout sur la facilité de manipulation du logiciel et la version doit être française.
Le tableau donné ci-dessous illustre la comparaison entre le progiciel Pentaho et
Vanilla.
Tableau 6: Comparaison entre PENTAHO et VANILLA
OUTIL D’ETL
POINTS
FORTS
PENTAHO VANILLA
• Outil pentaho data Integration pour le traitement des données ;
• Gestion de plusieurs types de transformations (agrégation, calcul…) ;
• Manipulation facile (par simple glisser/déposer) ;
• Installation facile, ne nécessite pas de configuration ;
• Possibilité de traitement des erreurs de saisies ou de formats des données ;
• Gestion de plusieurs types de sources de données (simple fichier, base de donnée…) ;
• Existe en version française.
POINTS
FAIBLES
L’outil ETL n’est pas intégré dans vanilla.
OUTIL DE
STOCKAGE
POINTS
FORTS
• Outil Schema Workbench pour la création de cube ;
• Cube Mondrian supporté par la plupart des outils
• Outil FreeAnalysisSchemaDesigner (FASD) pour la création de cube ;
• Facilité de création des cubes (en faisant glisser/déposer des
39
de reporting. mesures et des axes d’analyses)
• Ne nécessite aucune configuration après installation (il suffit de choisir les drivers et les bases de données pour chaque cube)
• Version française
POINTS
FAIBLES
• Création complexe des cubes ;
• Configuration fastidieuse de l’outil (driver, choix de la base de donnée) ;
• Pas de version française.
• Le logiciel n’est pas stable
• Le cube FASD n’est compatibles qu’avec les outils de reporting de vanilla et le portail de vanilla.
OUTIL DE
RESTITUTION
POINTS
FORTS
• l’outil « report designer » pour la création de rapport ;
• l’outil « design studio » pour la création de tableau de bord ;
• « report designer » est un générateur d’état complet (graphique, rapport paramétrable et personnalisable.
• Les outils « freeWebReport », « freeAnalysis », « freeAnalysisWeb » pour la création de rapport ;
• l’outil « freedashboard » pour la création de tableaux de bord ;
• Eclipse BIRT avec les plugins de Vanilla pour réaliser des états BIRT ;
• les outils de création de rapport sont facile à utiliser même pour les utilisateurs non-informaticiens ;
• version française.
• •
• •
POINTS
FAIBLES
• Difficulté de manipulation des 2 outils surtout pour les simples utilisateurs (non-informaticien) ;
• Difficulte sur l’export vers le serveur.
• Pas de version française.
• les rapports ne sont pas personnalisables sauf pour les états BIRT mais il existe quand même des templates (format de rapport prédéfini).
PORTAIL
DECISIONNEL
POINTS
FORTS
• gestion des droits d’accès grâce à une page d’authentification.
• Configuration aisée de l’accès à distance (accès au portail à partir de l’adresse IP) ;
• Configuration simple du changement de port ;
• Gestion sécurisée des droits d’accès au portail ;
• Gestion sécurisée des droits d’accès aux
40
données (un utilisateur ne peut accéder qu’aux données du groupe qui lui appartient) ;
• Page d’accueil personnalisable ;
• Interface dynamique utilisant le framework GWT ;
• Possibilité de choix de langue.
POINTS
FAIBLES
• Pas de gestion des droits accès aux données (toutes les données sont accessibles par tous les utilisateurs) ;
• configuration fastidieuse de l’accès au portail (accès à distance, changement de port).
5.8 Choix de l’architecture adopté pour le système décisionnel de CEM
Après avoir étudié les avantages et les inconvénients de ces deux progiciels, on a pu dégager
l’architecture suivante :
Figure 20: Architecture de BI de CEM
PDI
PENTAHO
VANILLA
SERVEUR VANILLA TOMCAT
Excel
CGB
ODS
PDI
DWH
FREEMETADA FASD
METADONNEEE
CUBE
41
5.9 Choix du plateforme
Pour le choix de plateforme, l’architecture est comme suit :
– Le serveur de base de donnée utilisé est l’Oracle 10g sous linux REDHATT5.
– le serveur vanilla est mis sous linux
– le PDI est mis sous linux.
Pour atteindre le serveur vanilla, les clients doivent se connecter via le serveur apache,
celle-ci est faite afin d’éviter la saturation de vanilla lorsque plusieurs clients doivent se
connecter en même temps.
Figure 21: Mode de connexion au serveur Vanilla
42
PARTIE III
REALISATION DU PROJET BUSINESS
INTELLIGENCE DE LA CAISSE D’EPARGNE DE
MADAGASCAR
43
CHAPITRE 1
ARCHITECTURE DU SYSTEME ET DEMARCHE A SUIVRE POUR LA REALISATION DU SYSTEME DECISIONNEL
1. Architecture du système
Figure 22: Architecture du logiciel
Source de données
Pentaho Data Integration
DWH
FASD
CUBE
Serveur Mysql
Export
FREEMETADATA
Métadonnées
Export
FREEANALYSIS
Rapport en format PDF,Excel,html
FREEWEBREPORT
FREEANALYSISWEB
Création
Création
Création
44
2. Démarche à suivre
Les étapes illustrées ci-dessous décrivent la démarche de la réalisation du système
décisionnel de CEM. Tout d’abord, il faut :
– créer les bases de données nommé datawarehouse
– créer les cubes
– créer les métadonnées
– exporter les cubes et les métadonnées créés vers le serveur
– créer les rapports à partir des métadonnées en utilisant le FreeWebReport
– créer les rapports à partir des cubes en utilisant l’outil FreeAnalysisWeb
Avec des métadonnées exportées aux serveurs, on peut aussi créer des rapports complexes
en utilisant l’outil BIRT.
45
CHAPITRE 2
REALISATION DU DATAWAREHOUSE
1. Etape de la réalisation du datawarehouse
En ce qui concerne le datawarehouse, la réalisation se fait en trois étapes :
– Alimentation de l’ODS
– Alimentation Du datawarehouse
– Mise à jour du datawarehouse
1.1 Alimentation de l’ODS
Les données à extraire proviennent de différentes sources. Dans cette étape, il faut
déplacer les données de leurs sources, qui sont les bases de données opérationnelles du CEM,
vers une zone temporaire appelée ODS où elles subiront des transformations et seront
nettoyées.
Un des grands problèmes de la fusion se pose sur le traitement des données venant de
sources plates comme les fichiers Excel. Il faut maintenir une surveillance du système
d’information pour pouvoir les identifier et s’assurer que ce sont les bonnes données qui sont
recensées. De plus, la forme des données des fichiers Excel qui est souvent non structurée
accentue la difficulté. Pour être utiles, ces données nécessitent un reformatage pour pouvoir
les incorporer dans une forme exploitable pour l’entreprise.
Pour effectuer celle-ci, l’outil PDI devrait se connecter à ces différentes sources afin de
pouvoir extraire leurs informations.
Figure 23: Extraction des données sources Excel
La figure 24 montre le nom du fichier Excel à extraire et ses contenus :
46
Figure 24: Contenu du fichier à extraire
La figure 23, montre que les données venant de l’Excel doivent être traitées, nettoyées
et validées par l’étape Validation des données. Les données valide vont être chargées dans
l’ODS tant dis que les données rejetées vont dans un fichier Excel afin que l’on puisse les
corriger ultérieurement.
La figure suivante représente l’extraction des données venant des sources Oracle :
Figure 25: Extraction des données de Oracle
Après avoir obtenu les données de ces sources, l’ETL se charge du chargement de ces deux
ODS dans un ODS principal.
Figure 26: Extraction des données des différentes ODS
Les données sont généralement fusionnées dans un O.D.S.
47
L’alimentation de l’ODS peut être résumée dans une seule tâche comme indiqué dans la figure
suivante :
Figure 27: Tâche de l'alimentation de l'ODS
1.2 Alimentation du datawarehouse
Les données de l’ODS doivent être traitées, agrégées avant d’être chargées dans le
datawarehouse
Figure 28: Alimentation du datawarehouse
1.3 Mise à jour du datawarehouse
La mise à jour du datawarehouse est effectuée d’une fréquence fixée, celle-ci peut être :
– Journalière
– Hebdomadaire
– Mensuelle
Mais, pour le cas de CEM, il ont choisit la mise à jour hebdomadaire. L’outil ETL assure la mise
à jour du datawarehouse à l’aide de planificateur de tâche appelé Quartz qui est incorporé
dans le logiciel. La figure suivante montre l’ensemble de l’opération de réalisation du
datawarehouse avec sa mise à jour automatique.
Figure 29: Alimentation du datawarehouse
48
Pour planifier la mise à jour automatique de tâche, il suffit de cliquer double sur le début de
tâche nommé START et la fenêtre suivante est ouverte :
– cocher sur la case Répéter,
– choisir la fréquence de la mise à jour et
– laisser le PDI ouvert.
Figure 30: Planification des tâches
49
CHAPITRE 3
ANALYSE MULTIDIMENSIONNELLE
Dans ce chapitre, les données du datawarehouse sont structurées de façon
multidimensionnelle à l’aide d’un cube.
1. Qu’est ce qu’un cube ?
Un cube c'est la vision ou l'analyse des données d'un datawarehouse sous plusieurs dimensions
et comme son nom l'indique il est dynamique.
Il est constitué de deux éléments principaux :
– les mesures, ces sont des valeurs numériques que l’on compare, ils sont le résultat
d’une opération d’agrégat des données
– les dimensions, ces sont les axes d’analyses, ils sont les points de vues depuis lesquels
les mesures peuvent être observées. Ces dimensions peuvent être hiérarchisées,
prenons l’exemple de la dimension temps, elle peut être hiérarchisée en Année -
Trimestre – Mois ou Année - Mois - Jour, pour la dimension on peut avoir comme
hiérarchie Région – Ville – Catégorie de client, on parle alors d'attributs (ou
"membres") hiérarchisés de la dimension.
La figure 31 illustre la représentation de cube sous forme des axes, la figure montre que les
éléments à mesurer ce sont le nombre de client et le montant de l’opération, ces deux
mesures sont analysées suivant l’axe Agence, Temps et Client.
Figure 31: Représentation de cube
50
Chaque cellule de la structure multidimensionnelle représente la consolidation d'une donnée
numérique (dans le cas échéant c’est le nombre de client et le montant de l’opération) pour
l'intersection entre chaque attribut de chaque dimension. Cette consolidation peut être simple
(somme, moyenne) ou complexe. Les données consolidées sont appelées "mesures".
Le cube est créé à partir de l’outil de vanilla appelé «FreeAnalysisSchemaDesigner» (FASD).
L’environnement de l’outil FASD est présenté comme suit :
Figure 32: L’environnement de l’outil FASD
2. Le processus de la création de cube
2.1 Définition de source de données
Figure 33: Connexion à la base
51
2.2 Définition des tables de fait et les tables de dimension
Figure 34: Choix des tables de dimension et de fait
2.3 Définition des relations entre les tables
Figure 35: Définition des relations entre les tables
52
2.4 Choix des axes d’analyse et leurs hiérarchies respectives
Figure 36: Définition des axes de dimension
2.5 Choix des mesures
Figure 37: Définition des mesures
3. Création du cube
Figure 38: Création de cube
L’intérêt de l’analyse multidimensionnelle est de pouvoir lire les données selon le niveau
de détail cherché grâce à une navigation « drill-up / drill-down ».
53
La fonction « drill-up » permet d’effectuer l’analyse sur un niveau global, il s’agit donc d’avoir
des mesures agrégées (par année ou par agence par exemple).
La fonction « drill-down » quant à elle, effectue l’analyse sur un niveau plus détaillé (par mois
ou par service).
Les axes d’analyses (dimensions) choisis pour observer les mouvements (versement - retrait)
effectuées au niveau de Caisse d’Epargne de Madagascar sont :
� Agence
� Temps
� Produit
� Operation
Dans la figure 36, les axes sont hiérarchisés comme suit :
� axe Agence : Ville – Agence
� axe Temps : Année – Trimestre – Mois
� axe Produit : Ensemble_Produit – Type_Produit – Categorie_Produit – Produit.
� axe Operation : Type_Operation.
Avec le cube SuiviMouvement de la figure 38, on peut connaître par exemple le nombre et
le montant (mesures) d’opération VERSEMENT effectués dans la ville d’ANTANANARIVO
pour l’Agence TSARALALANA dans le TROISIEME TRIMESTRE de l’année 2008 pour le
produit COMPTES LIVRET MIHARY IMPRIMABLE de catégorie LIVRET D’EPARGNE.
4. Navigation dans le cube
Pour naviguer dans le cube, deux outils peuvent être utilisés:
– FreeAnalysis (module java) et
– FreeAnalysisWeb (module web).
Les deux offrent quasiment les mêmes résultats.
Figure 39: Navigation drill-up dans un cube
En faisant un clic double sur Tous les Agences et sur Tous les Temps, on obtient les
nombres d’opération et les volumes correspondant aux opérations effectuées dans les
différentes villes par année. Comme la montre la figure ci-dessous:
54
Figure 40: Navigation drill-down dans un cube
En continuant de cliquer double sur la Ville d’Antananarivo, on obtient les détails des
opérations effectuées dans toutes les agences d’Antananarivo.
Figure 41: Navigation drill-down dans un cube
5. Export de cube vers un fichier
On peut exporter le cube sous différents formats (PDF, Html et Excel) en cliquant sur
l’icône marqué ci-dessous.
55
Figure 42: Export de cube vers Excel (PDF, Html)
6. Type de rapport créé par FreeAnalysisWeb
En exportant le rapport vers Excel, on a la forme suivante :
Figure 43: Rapport en Excel
56
CHAPITRE 4
LE REPORTING
1. FreeMetadata
Le processus de la création de métadonnée est illustré par les étapes suivantes :
1.1 Connexion à la base
Figure 44:Connexion à la base
1.2 Définition des tables de dimension et des tables de fait
Figure 45: Choix des tables de fait et de dimension
57
1.3 Définition des relations entre les tables
Figure 46: Définition des liaisons entre les tables
1.4 Création de Business Model
Le business model est constitué de :
– business table
– Ressource
– business package
Figure 47: Création de Business model
1.5 Création des business Tables
Les business tables ces sont des tables métiers, c'est-à-dire des tables du datawarehouse
mais avec le nom des tables et des champs définissent de façon plus claires aux utilisateurs
finaux.
58
Figure 48: Création de Business table
1.6 Création des Ressources
Les ressources sont constituées des simples filtres et des prompts c'est-à-dire des filtres
dynamiques. Ces filtres sont très importants dans l’affichage de rapport.
Figure 49: Création de filtre
1.7 Création de Business Package
Pour créer le Business Package, il suffit de cocher les business tables, les ressources qui
devront participer à la création de rapport.
Figure 50: Création de Business package
59
Pour tester la validité de la métadonnée, il faut le tester à partir de Business package en
faisant de requête dans Query Builder.
Figure 51: Test de Business package
Dans cette fenêtre, on choisit les champs pour faire la requête. Et on clique sur Run
pour l’exécuter.
Figure 52: Choix des colonnes pour le requête
L’affichage suivant montre que la métadonnée créée est correcte.
60
Figure 53: Résultat de la requête
2. Définition de sécurité des métadonnées
La sécurité des rapports est très importante dans le monde de BI. Avec vanilla, on peut
mettre de sécurité sur chaque Business tables, Business Model et sur chaque Business
Package. L’absence de cette sécurité pourrait entraîner la non visibilité du Business Package et
Business Model lors de la création de rapport dans l’interface Web ou dans le BIRT.
Pour mettre la sécurité sur le Business Model (Business tables, Business Package), il
suffit de sélectionner le Business Model à sécuriser et cocher les groupes qui ont le droit d’y
accéder.
Figure 54: Ajout de sécurité à la métadonnée
61
3. Export de métadonnée vers le serveur
Pour que les utilisateurs puissent créer de rapport à partir des métadonnées, il faut les
exporter vers le serveur de vanilla. Pour le réaliser, il suffit de cliquer sur l’icône Repository
Connection.
Figure 55: Icône de l'export de métadonnée au serveur
Ici, on définit les paramètres de connexion du serveur de Vanilla
Figure 56: Définition des paramètres de connexion au serveur
Dans cette étape, on sélectionne le dossier où on va mettre la métadonnée et on clique
sur le petit cube.
Figure 57: Choix de dossier où on va mettre la métadonnée
L’étape suivante consiste à donner de nom à la métadonnée et définir le nom du groupe
qui exporte la métadonnée vers le serveur.
62
Figure 58: Attribution de nom à la métadonnée
La figure suivante montre que la métadonnée est exportée au serveur, dans ce cas on
peut créer de rapport à partir de cette métadonnée.
Figure 59: Métadonnée au serveur
4. Création de rapport Simple
Avec les métadonnées exportés au serveur, on peut créer de rapport simple à l’aide de
l’outil Web de Vanilla appelé FreeWebReport. Les sous titres suivants illustrent l’étape à suivre
pour créer le rapport à l’aide de FreeWebReport.
4.1 Connexion au portail web de Vanilla
L’accès au portail est sécurisé, c'est-à-dire, il faut que les utilisateurs s’authentifient
avant de consulter les données de l’entreprise.
63
Figure 60: Fenêtre de l'authentification
4.2 Choix de groupe
Après l’authentification, il faut choisir un groupe si l’utilisateur appartient à plusieurs
groupes à la fois.
Figure 61: Choix du groupe d'utilisateur
Les groupes qui sont affichés correspondent aux groupes auxquels le Directeur Général peut
accéder.
4.3 Choix de l’outil utilisé pour la création de rapport
Deux outils sont disponibles pour créer des rapports ou des tableaux de bords via le portail
décisionnel :
• FreeAnalysisWeb
• FreeWebReport
64
FreeAnalysisWeb permet de naviguer dans un cube et créer un rapport à partir du résultat.
Le rapport peut être exporté sous fichier Excel, pdf …
FreeWebReport utilise les données du datawarehouse pour créer des rapports détaillés. Le
rapport peut être exporté sous fichier Excel, pdf …
4.4 Choix de template du rapport
Figure 62: Choix de template
4.5 Sélection des sources de données
Figure 63: Sélection de métadonnée
65
4.6 Sélection de Business modèle et de Business package
Figure 64: Choix de business model et de business package
4.7 Sélection des champs constituants le contenu du rapport
Figure 65: Sélection des champs pour le rapport
4.8 Choix de format de rapport
Il y a deux types de format de rapport dans le FreeWebReport : Excel et PDF.
Figure 66: Choix de format du rapport
66
4.9 Exemple de rapport de format Excel
Rapport DE Suivi des mouvements
Agence Année Mois Type de Produit Produit Operation Nombre Montant
AMBANIDIA 2006
NOVEMBRE COMPTE EPARGNE
CPTES LIVRET MIHARY IMPRIMABLE VERSEMENT 14 1094000
NOVEMBRE COMPTE EPARGNE
CPTES LIV SOMBINIAINA IMPRIMABLE VERSEMENT 5 38100
DÉCEMBRE COMPTE EPARGNE
CPTES LIV MAT NON IMPRIMABLE RETRAIT 1 -220000
DÉCEMBRE COMPTE EPARGNE
CPTES LIV MITSIMBINA IMPRIMABLE RETRAIT 240 -75914490
DÉCEMBRE COMPTE EPARGNE
CPTES LIV MITSIMBINA IMPRIMABLE VERSEMENT 355 148707015.4
SEPTEMBRE COMPTE EPARGNE
CPTES LIV MITSIMBINA IMPRIMABLE VERSEMENT 196 46748965
SEPTEMBRE COMPTE EPARGNE
CPTES LIVRET MIHARY IMPRIMABLE VERSEMENT 11 2134000
OCTOBRE COMPTE EPARGNE
CPTES LIV MAT NON IMPRIMABLE VERSEMENT 1 480000
OCTOBRE COMPTE EPARGNE
CPTES LIV MITSIMBINA IMPRIMABLE VERSEMENT 340 133924174.8
NOVEMBRE COMPTE EPARGNE
CPTES LIVRET MIHARY IMPRIMABLE RETRAIT 19 -3204300
NOVEMBRE COMPTE EPARGNE
CPTES LIV MITSIMBINA IMPRIMABLE VERSEMENT 327 76053500
Figure 67: Extrait du rapport en Excel de suivi de mouvement
5. Création de rapport avec Birt
Le BIRT (Business Intelligence and Reporting Tool) est un outil open source basé sur
Eclipse, utilisé pour la création de rapport dans des applications web. Vanilla apporte de
plugins dans BIRT afin d’intégrer la source de donnée de Freemedata dans Birt. Avec Birt on
peut créer de rapport paramétré, rapport croisé.
La figure suivante présente l’environnement de Birt :
67
Figure 68: Environnement de Birt
5.1 Définition de source de données
Pour créer de rapport dans Birt, on peut utiliser les métadonnées et la base de données
comme source de données, mais il est conseiller d’utiliser les métadonnées pour raison de
sécurité de données.
Figure 69: Choix de métadonnée
68
5.2 Type de rapport créé par Birt
La figure suivante montre le type de rapport créé par Birt :
Figure 70: Extrait du rapport créé en Birt de suivi de mouvement
Les valeurs négatives dans le rapport indique le montant du retrait.
69
CONCLUSION
En conclusion, le projet est actuellement en cours de réalisation, la validation de la
cohérence des informations fournies sur le portail décisionnel est effectuée à partir des
données existantes dans leurs bases actuelles et des améliorations sont encore à envisager. La
réalisation de ce projet décisionnel présente des avantages pour la société CEM car après la
formation fournie aux utilisateurs de ce système, ils ont pu constater que l’outil va vraiment
faciliter leur travail. En ce qui concerne l’analyse et la comparaison de la rentabilité des
agences, ils n’allaient plus chercher les données partout mais juste faire un drill down et de
drill up sur le cube. Comme la gestion des assiduités de personnel, Le responsable de
ressources humaines peut reconnaître très vite la direction qui a le plus grand nombre
d’absence dans une année. Pour la Direction des Etudes et des Exploitations, l’outil leurs
permet de connaître qui sont les agences qui ont effectué de grand nombre de versement
durant l’année dernière et qui ont fait de grand nombre de retrait, quels sont les comptes
sans mouvement pendant 3 mois. La nouvelle application apporte vraiment de l’aide aux
dirigeants de CEM sur la prise de décision au fonctionnement interne de l’entreprise et à la
stratégie adoptée face à ses concurrents comme les autres banques. Personnellement,
travailler sur ce projet est bénéfique pour moi, car dans ce projet j’ai travaillé en tant que
développeur informatique mais lors des interviews avec les personnels de CEM, on arrive à
comprendre les différents métiers de CEM.
Puisque le décisionnel n’invente pas de données pour remplir le datawarehouse, mais il
prend comme source le CGB et le fichier Excel donc le remplissage de ce fichier de façon
rigoureuse est très important.
WEBOGRAPHIE
Sites web consultés :
http://www.ingenosya.mg
http://www.pentaho.com
http://www.bpm-conseil.com
http://www.smile.fr/
http://www.decideo.fr/
http://www.developpez.com/
http://www.commentcamarche.net/
http://www.informatiquedecisionnelle.com/
http://www.piloter.org/business-intelligence/
http://phortail.org/
http://www.systemeetl.com/
http://www.e-rural.net/ccm/entreprise/business-intelligence.htm
http://www.progilibre.com/
http://www.osbi.fr/
http://sourceforge.net/
http://www.systemeetl.com/
ANNEXE
Extrait de la modélisation du datawarehouse
MaintenanceInfo_Agence
MaintenanceInfo_Temps
Assiduité_Agence
Assiduité_TypeAbsence
Assiduité_Temps
InterventionJuridique_Agence
InterventionJuridique_Temps
SituatBudg_RubCompta
SituatBudg_Temps
SituatBudg_Agence
Operation_Temps
Operation_ProduitOperation_TypeOperation
Operation_Agence
dim_Temps
idTekPeriodeMois_IdMois_CourtMois_LongTrimestreTrimestre_CourtTrimestre_LonAnnee
integerintegerchar(20)char(20)integerchar(10)char(20)integer
<pk>
dim_TypeAbsence
idTekTypeAbsenceAbsenceType_Absence
integerchar(50)char(50)
<pk>
dim_Produit
idTekProduitl ibelle_Produitcat_Produittype_Produitclasse_Produit
integerchar(50)char(50)char(50)char(50)
<pk>
dim_TypeOperation
idTekTypeOperationlibelle_TypeOperation
integerchar(50)
<pk>
dim_Agence
idTekDirAgenceDirection_AgenceCat_AgenceVille
integerchar(50)char(50)char(50)
<pk>
Suivi_Maintenance
idTekDirAgenceidTekPeriodeposteduree_AppelEnMinuteduree_ReponseEnMinutecout_Assistancenb_Appelnb_AppelResolunbAppel/CEMtaux_AppelResolutpsMoyResEnJour
integerintegerchar(50)numeric(3,1)numeric(3,1)numeric(9,2)integerintegernumeric(2,2)numeric(2,2)numeric(2,1)
<pk,fk1><pk,fk2>
Suivi_Assiduité
idTekDirAgenceidTekTypeAbsenceidTekPeriodenombre_Absentduree_Absence
integerintegerintegerintegerfloat(1)
<pk,fk1><pk,fk2><pk,fk3>
suivi_InterventionJuridique
idTekDirAgenceidTekPeriodeDossiers_Traitesnb_Intervention
integerintegerchar(50)integer
<pk,fk1><pk,fk2>
dim_RubCompta
idTekRCnum_RClibelle_RCcat_RCtype_RCclasse_RC
integerintegerchar(50)char(50)char(50)char(50)
<pk>
suivi_SituationBudgetaire
idTekRCidTekPeriodeidTekDirAgencemontant_Budgetcumul_Réaliationtaux_Realisationbudget_Restant
integerintegerintegernumeric(45,2)numeric(45,2)numeric(6,2)numeric(45,2)
<pk,fk1><pk,fk2><pk,fk3>
suivi_Operation
idTekPeriodeidTekProduitidTekTypeOperationidTekDirAgencenb_OperPrevmnt_OperPrevnb_OperRealmnt_OperReal
integerintegerintegerintegerintegernumeric(45,2)integernumeric(45,2)
<pk,fk1><pk,fk2><pk,fk3><pk,fk4>
Nom : RAMAMONJY Prénoms : Marie Florence Yvette Adresse : Lgt 276 Cité Ambohipo Tél : 0324625162 Titre de mémoire : Mise en place de Système décisionnel de la société Caisse d’Epargne de Madagascar. Nombre de pages : 69 Nombre de tables : 6 Nombre de figures : 70
RESUME
Le système décisionnel mis en place dans la Société Caisse d’Epargne de Madagascar (CEM) a pour
objectif de collecter les données de la société et les transformer en informations stratégiques pour prendre de meilleures décisions et améliorer la performance de la société. IL est constitué de quatre fonction fondamentale du systèmes décisionnel, à savoir l’extraction, le stockage, la restitution et le reporting.
L’élément de base du système décisionnel est le datawarehouse ou entrepôt de données. Pour construire le datawarehouse de CEM, on a dû extraire les données de leurs système d’information (Excel et Oracle) et on les met dans une base de donnée intermédiaire appelée ODS, les données issues de l’ODS ont dues passer par plusieurs transformations comme le filtrage, le nettoyage, l’aggrégation avant de les mettre dans le datawarehouse. Dans la mise en place du système décisionnel de CEM, la construction d’un datawarehouse constitue le 80% de temps de travail. L’outil ETL utilisé pour la contruction de datawarehouse est le Pentaho Data Intégration (PDI).
Une fois que le datawarehouse est monté, on a pu construire des cubes et des métadonnées, c’est la phase de restitution. Avec le cube restitué, on a pu faire de l’analyse multidimensionnelle en faisant de drill down et drill up lors de la naviguation dans le cube.
Après la phase de restitution, on a pu passer à la phase de reporting ou présentation, c’est à dire la création des tableaux de bord, des états c’est la partie qui intéresse le plus les analystes. Avec les métadonnées construites, on a pu créer des rapports et des tableaux de bord avec des outils comme BIRT et FreeWebReport. Et c’est à partir des tableaux de bord et des états créés que les analystes et les dirigeants font leurs analyses avant de prendre de décision pour l’avenir de leur société. Mots-clés : Système décisionnel, projet décisionnel, datawarehouse, analyse multidimensionnelle, métadonnée.
ABSTRACT
The Business intelligence implemented in the Company Caisse d'Epargne of Madagascar (CEM) aims to collect company data and transform it into strategic information to make better decisions and improve the performance of the company. It consists of four basic function of Business intelligence, namely the extraction, storage, recovery and reporting. The basic element in the Business Intelligence is the data warehouse. To build the data warehouse of CEM, we had to extract data from their information system (Excel, Oracle) and we put them in a database intermediate called ODS, data from the ODS were due to go through several transformations such as filtering, cleansing, aggregation before putting in the data warehouse. In the implementation of CEM’s Business Intelligence, building a data warehouse is the 80% of working time. The ETL tool used for the contruction of data warehouse is the Pentaho Data Integration (PDI). Once the data warehouse is installed, we have built the cubes and metadata, the restitution phase. With the cube returned, we were able to multivariate analysis by drill down and drill up when operating in the cube. After the restitution phase, we have passed the phase of reporting or presentation, ie the creation of dashboards, reports that the party most interested analysts. With the metadata built, it was able to create reports and dashboards with tools such as BIRT and FreeWebReport. And from dashboards and reports created that analysts and executives do their analysis before taking decisions for the future of their society. Keywords : Business intelligence, Business intelligence Project, datawarehouse, analysis multidimensional, metadata.