Minisètre de l’Enseignement Supérieur Et de la Recherche Scientifique Université de Tunis
Institut Supérieur de Gestion
Conception et Mise en Place des Tableaux de Bord des Marchés et des Segments
Filière
Licence Appliquée en Informatique Décisionnelle
Elaboré par
Aloui Alaedine
Lazreg Mohamed Amine
Encadré par
Encadrant pédagogique Mme. Kouki Samia
Encadrant professionnel Mme. Mlik Imen
Année universitaire 2017-2018
Dédicace
Ce travail est dédié à mon père Lazher, décédé trop tôt, qui m’a toujours poussé et motivé dans mes études. J’espère que, du monde qui est sien maintenant, il apprécie cet humble geste comme preuve de reconnaissance de la part d’un fils qui a toujours prié pour le salut de son âme. Puisse Dieu, le tout puissant, l’avoir en sa sainte miséricorde !
À ma mère Dalanda, qui m’a accompagné par son soutien, son amour, sa tendresse et pour sa présence en toute circonstance.Qu’elle sache que l’amour qu’elle me donne continue à m’animer et me permet d’envisager l’avenir comme un défi.
Je ne saurais oublier de remercier toutes les personnes qui me sont chères, en particulier mon frère Maher et ma soeur Manel et son époux Ameur.
À toute ma grande famille, pour leurs encouragements et leurs
supports.
À mon ami " Amine " c’était un grand plaisir de travailler avec
toi.
À tous les enseignants de l’ISG qui m’ont supporté. À tous mes amis.
Alaedin
Dédicace
Des phrases aussi éloquentes soient elles ne sauraient saisir le mont d’amour que je peux éprouver pour toi. A celle qui me comble d’amour. Ma mère
A celui qui a tant attendu les fruits de son éducation. Mon père A celui qui ne cesse de me guider vers le droit chemin, tes conseils prodigués m’ont été d’une bienfaisance extrême. Mon frère ainé Omar
A toute ma famille, mes oncles et tantes, cousins et cousines : Merci d’avoir toujours su me pousser à donner le meilleur de moi- même. Merci pour l’élan chaleureux.
A ma confidente et ma meilleure amie qui n’a cessé de m’épauler
et de me soutenir. Maryem
A mon ami " Aladin " : ce fut un réel plaisir de travailler avec
toi. Merci pour ton dévouement, ton implication et ta volonté.
A tous mes amis. A tous ceux et celles qui m’ont enseigné et m’ont fait part de
leurs savoirs.
A tous ceux qui m’ont souhaité " bon courage " : Merci, cette bouffée d’énergie me ressource pour donner le meilleur de moi- même.
Mohamed Amine
Remerciements
Au terme de ce projet, nous désirons adresser nos sincères remerciements à ceux qui nous ont donné leur soutien et qui ont concouru à la réussite de notre travail. C’est ainsi que nous gardons ces quelques lignes reflétant notre profonde gratitude.
Tout d’abord, nous tenons à remercier infiniment notre encadrante et professeur, Mme. Samia KOUKI, pour sa continuelle disponibilité, ses précieux conseils, ses efforts et pour l’accueil chaleureux qu’elle nous a toujours réservé.
Nous adressons nos remerciements également à toute l’équipe de la direction marketing et développement digital pour leur esprit d’équipe et en particulier Mme. Imen MLIK, notre encadrante professionnelle pour son suivi et son encouragement, qui, grâce à sa confiance nous sommes parvenu à accomplir totalement notre mission, et à Mlle. Souad OUERTANI pour tout le temps qu’elle nous a consacré et le partage quotidien de son expertise.
En tout honneur, nous sollicitons les membres du jury de trouver ici l’expression de nos vifs remerciements pour l’intérêt porté à l’égard de ce projet en acceptant de l’examiner mais aussi de l’évaluer.
Nos derniers remerciements, iront à nos parents, nos amis et notre grande famille pour
leur soutien continu tout au long de notre cursus universitaire
Table des matières
Introduction générale
1 Présentation Générale
1.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Présentation du secteur Bancaire
. . . . . . . . . . . . . . . . . . . . . . .
1.3 Présentation de l’organisme d’accueil
. . . . . . . . . . . . . . . . . . . . .
1.4 Organigramme
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Présentation de l’équipe de travail . . . . . . . . . . . . . . . . . . . . . . .
1.6 L’informatique Décisionnelle . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2 Les phases d’un projet Décisionnel
. . . . . . . . . . . . . . . . . .
1.7 Entrepôt de donnée ou DataWarehouse . . . . . . . . . . . . . . . . . . . .
1.7.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2 Caractéristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8 Les Tableaux de Bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.8.1 Les fonctions des tableaux de bord . . . . . . . . . . . . . . . . . .
1.8.2 Les qualités du tableau de bord . . . . . . . . . . . . . . . . . . . .
1.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Cadre du projet
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Présentation du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Existant actuel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
3
3
3
3
4
5
5
5
5
6
6
6
7
7
8
8
9
9
9
9
9
2.3.2 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3
Solution proposé
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Méthodologie Ralph Kimball . . . . . . . . . . . . . . . . . . . . . .
2.5 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1 Besoins fonctionnels
. . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Spécification et analyse du Data Warehouse
3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Modélisation de l’entrepôt de donnée . . . . . . . . . . . . . . . . . . . . .
3.2.1 Modélisation multidimensionnelle . . . . . . . . . . . . . . . . . . .
3.2.2 Représentation et explication du Data Warehouse . . . . . . . . . .
3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Réalisation
4.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Environnement de développement matériel Requis . . . . . . . . . . . . . .
4.2.1 Environnement de développement logiciel . . . . . . . . . . . . . . .
Publicité
4.2.2 Comparaison des outils de visualisation et d’analyse de données
. .
4.2.3 Critère de choix de l’outil
. . . . . . . . . . . . . . . . . . . . . . .
4.2.4 Technologie utilisée
. . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Gestion de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Phase de préparation et nettoyage de donnée . . . . . . . . . . . . .
4.4.2 Phase de restitution de données . . . . . . . . . . . . . . . . . . . .
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conclusion générale
10
10
10
11
13
13
15
15
16
16
16
16
19
25
26
26
26
27
27
30
31
31
32
32
37
46
46
Table des figures
1.1 Organigramme de la BIAT . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Architecture du système d’information décisionnel . . . . . . . . . . . . . .
1.3 Les fonctions du tableau de bord . . . . . . . . . . . . . . . . . . . . . . .
4
6
8
2.1 Cycle de vie de l’approche Bottom Up . . . . . . . . . . . . . . . . . . . .
12
3.1 Exemple d’un modéle en étoile . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Exemple d’un modèle en flocon de neige
. . . . . . . . . . . . . . . . . . .
3.3 Modélisation initiale de l’entrepôt de données
. . . . . . . . . . . . . . . .
3.4 Modélisation finale de l’entrepôt de données
. . . . . . . . . . . . . . . . .
3.5 Modèle en flocon de neige du volet client . . . . . . . . . . . . . . . . . . .
3.6 Modèle en flocon de neige du volet dépôts bancaires
. . . . . . . . . . . .
3.7 Modèle en flocon de neige du volet placement
. . . . . . . . . . . . . . . .
3.8 Modèle en flocon de neige du volet crédit
. . . . . . . . . . . . . . . . . .
3.9 Modèle en flocon de neige du volet pack . . . . . . . . . . . . . . . . . . .
4.1 Logo QlikView . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Logo Tableau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Logo Jaspersoft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Logo Power BI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5 Architecture de QlikView . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 Diagramme de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7 Feuille du volet client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8 Tableau client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.9 Tableau marché client
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
18
19
20
21
22
23
24
25
27
28
29
30
31
32
33
33
34
4.10 Script de calcul de dimension TYPE_AGENCE . . . . . . . . . . . . . . .
4.11 Tableau placement
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.12 Tableau placement par agence . . . . . . . . . . . . . . . . . . . . . . . . .
4.13 Partie 1 du script de l’export
. . . . . . . . . . . . . . . . . . . . . . . . .
4.14 Partie 2 du script de l’export
. . . . . . . . . . . . . . . . . . . . . . . . .
4.15 Partie 3 du script de l’export
. . . . . . . . . . . . . . . . . . . . . . . . .
4.16 Page d’accueil de l’application . . . . . . . . . . . . . . . . . . . . . . . . .
4.17 Tableau de bord pour le suivi du capital client (1) . . . . . . . . . . . . . .
4.18 Tableau de bord pour le suivi du capital client (2) . . . . . . . . . . . . . .
4.19 Tableau de bord pour le suivi du capital client (3) . . . . . . . . . . . . . .
4.20 Tableau de bord pour le suivi des crédits (1) . . . . . . . . . . . . . . . . .
4.21 Tableau de bord pour le suivi des crédits (2) . . . . . . . . . . . . . . . . .
4.22 Tableau de bord pour le suivi des crédits (3) . . . . . . . . . . . . . . . . .
4.23 Tableau de bord pour le suivi des crédits (4) . . . . . . . . . . . . . . . . .
4.24 Tableau de bord pour le suivi des crédits (5) . . . . . . . . . . . . . . . . .
4.25 Tableau de bord pour le suivi des crédits (6) . . . . . . . . . . . . . . . . .
4.26 Tableau de bord pour le suivi des placements (1)
. . . . . . . . . . . . . .
4.27 Tableau de bord pour le suivi des placements (2)
Publicité
. . . . . . . . . . . . . .
4.28 Tableau de bord pour le suivi des placements (3)
. . . . . . . . . . . . . .
4.29 Tableau de bord pour le suivi des placements (4)
. . . . . . . . . . . . . .
4.30 Tableau de bord pour le suivi des placements (5)
. . . . . . . . . . . . . .
34
35
35
36
36
37
37
38
39
39
40
41
41
42
42
43
44
44
45
45
46
Liste des tableaux
2.1 Tableau comparative des deux approches . . . . . . . . . . . . . . . . . . .
11
3.1 Tableau des dimensions partagées . . . . . . . . . . . . . . . . . . . . . . .
20
4.1 Configuration matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Introduction Générale
Face à l’intensification des documents électroniques et à l’accroissement du travail colla- boratif, la mise en place d’une gestion des flux de données dans les systèmes d’information est devenue incontournable.
La réussite d’un projet à but rémunérateur, débute par assurer le sens de l’organisa- tion, de la gestion intelligente, et surtout assurer une stratégie de maîtrise qui permet de présenter à tout moment des informations synthétiques et opérationnelles. Ces informa- tions occupent une place importante au sein d’une entreprise qui vise l’amélioration de sa production, la garantie de la qualité de ses produits et la stabilité de la performance de ses activités.
Dans un monde concurrentiel où l’innovation se démarque, et face aux puissances de traitement, la variété des tableaux de bord, et autres exploits, il est indispensable pour chaque entreprise de posséder un ensemble d’outils décisionnels qui assurent la collecte, la normalisation et l’analyse des données.
C’est dans ce contexte qu’intervient la Business Intelligence, ce concept permet le suivie, la compréhension et le pilotage des informations essentielles aux activités des entreprises vu la force qu’il dispose dans l’interprétation des données variées en temps réel. Cela assure aux entreprises un gain du temps au cours du traitement de données.
L’informatique décisionnelle occupe, depuis déjà des années, le sommet dans la liste des priorités des entreprises vu que les approches classiques se révèlent impuissantes face à la masse de données éparses et multiformes. C’est d’ailleurs dans ce cadre que s’inscrit notre projet au sein de la banque Internationale Arabe de Tunisie « BIAT », qui souhaite se doter d’une application décisionnelle permettant la collecte et le traitement des données produites par la banque dans le but de générer des tableaux de bord qui assurent une vision globale sur le volet commercial de la banque pour une meilleure prise de décision.
Notre travail comporte l’extraction, le chargement et la restitution des données des opé- rations par agence, zone et région qui concernent la direction marketing et développement digital dont le but de contrôler l’activité commerciale, envisager les intentions futures et encercler les défis du marché.
1
Afin de concéder une vision totale et assez détaillée, dans ce présent rapport, nous avons organisé les chapitres de la sorte : Le premier chapitre consiste à mettre le projet dans son cadre, nous allons introduire le secteur bancaire pour ensuite présenter l’organisme d’accueil, le département marketing et développement digital et finir par la réalisation d’une étude théorique. Le deuxième chapitre présente le projet d’une façon générale, l’analyse de l’existant, l’approche de travail, les besoins fonctionnels et les besoins non fonctionnels et la solution proposée nous permettant d’achever le but de notre projet. Le troisième chapitre se focalise sur la structure et la spécification de la data Warehouse et les dimensions utilisés. Finalement, les réalisations feront l’objet du quatrième chapitre qui illustrera un aperçu sur nos résultats.
2
Chapitre 1
Présentation Générale
1.1 Introduction
La présentation de l’environnement général du projet a pour rôle de le mettre dans son
cadre organisationnel. Ce chapitre introduit donc l’organisme d’accueil et l’état de l’art.
1.2 Présentation du secteur Bancaire
Le secteur bancaire a vécu des mutations profondes qui ont aecté l’ensemble de la sphère financière. Pour cela , le système bancaire tunisien, qui est composé essentiellement de la banque centrale, des établissements de crédit, des banques de développement et des banques o-shore, n’a cessé de progresser afin de pouvoir s’adapter aux changements de l’environnement et ce, en passant par la réforme la redéfinition de la profession bancaire, des marchés de capitaux et la restructuration des banques visant à consolider le secteur, améliorer la qualité des actifs, mais également faire face à la baisse des taux et la faiblesse de l’activité économique.
1.3 Présentation de l’organisme d’accueil
La Banque Internationale arabe de Tunisie (BIAT) fondée en 1976 est une banque tunisienne de secteur privé. Étant donné une banque commerciale, son activité se base sur une gamme diversifiée de produits à la fois innovante et complète, et ce, via une force de vente ecace, basée sur un concept évolué de merchandising de ses points de vente. La BIAT occupe le sommet des banques commerciales privées de la place, et globalement la troisième auprès des banques publiques comme elle domine presque 15 % du marché financier.[1]
3
CHAPITRE 1. PRÉSENTATION GÉNÉRALE
1.4 Organigramme
Le pôle banque de détail, désigne la structure de la banque qui est chargée de la gestion des marchés PP (Petit Porteur) et PME (Petite et Moyenne Entreprises) à travers le réseau d’agence. Elle est organisée de la façon suivante :
-Structure régionale :
- 4 directions de régions. - 11 zones (202 Agences). -Structure centrale : 5 directions
Figure 1.1 – Organigramme de la BIAT [2]
4
CHAPITRE 1. PRÉSENTATION GÉNÉRALE
1.5 Présentation de l’équipe de travail
Notre stage a été effectué dans la direction marketing et développement digital dont les
principales activités sont :
- Veille concurrentielle,technologique et stratégique. - Mise à jour et gestion de la base de donnée client. - Segmentation client. - Mise en œuvre d’une stratégie marketing efficace. - Suivi des clients et des produits de la BIAT.
1.6 L’informatique Décisionnelle
1.6.1 Définition
La BI (Business Intelligence) ou l’informatique décisionnelle est une évolution techno- logique qui assure l’analyse des données afin de présenter des informations exploitables par des dirigeants et des décideurs d’entreprises, dans le but de faciliter la prise de décision.
1.6.2 Les phases d’un projet Décisionnel
Un projet de mise en place d’un système décisionnel comporte 4 phases :
a. La phase d’alimentation
Cette phase présente des processus ETL (Extract Transform Load) qui se chargeront de la récupération de toutes les données importantes depuis diverses sources de stockage.
b. La phase de modélisation
Cette phase est dédiée au stockage des données sous une forme adéquate pour être analy- sées ultérieurement. Elle comprend particulièrement l’entrepôt de données (datawarehouse) chargé de rassembler les données. Elle fait également intervenir les notions de datamarts et de cubes nécessaires pour atteindre les attentes métiers.
c. La phase de restitution
Cette phase se préoccupe de la restitution des données sous forme de tableaux de bord, reporting, navigation dans des cubes et des outils orientés statistique.
5
CHAPITRE 1. PRÉSENTATION GÉNÉRALE
d. La phase d’analyse
C’est dans cette phase finale que les utilisateurs prennent part et analysent les informations fournies. Elle peut également faire intervenir des spécialistes pour prélever des estimations futures ou des prévisions, on parle aussi de l’exploration de données ou datamining.
Figure 1.2 – Architecture du système d’information décisionnel [3]
1.7 Entrepôt de donnée ou DataWarehouse
1.7.1 Définition
Le Data Warehouse ou entrepôt de données, est une vision universelle et centralisée de toutes les données de l’entreprise. C’est une disposition qui vise à rassembler les in- formations de l’entreprise pour des buts analytiques et pour aider à la prise de décision stratégique, contrairement aux bases de données.
1.7.2 Caractéristiques
a. Orienté sujet :L’organisation des données se fait par thème. Les données spéci- fiques à un thème, comme les ventes par exemple, sont d’abord extraites des dié- rentes bases OLTP (Online Transaction processing), et par la suite regroupées. b. Intégré :L’intégration les données provenant de diérentes sources utilisant des types de format variés. Ces données seront intégrées avant qu’elles soient proposées à utilisation.
6
CHAPITRE 1. PRÉSENTATION GÉNÉRALE
c. Non volatile :Les données ne subissent pas de mutation au cours des traitements et au fil du temps. d. Historisé :Le Data Warehouse nous permet de visualiser l’évolution d’une va- leur donnée dans le temps. L’archivage dépend de la nature des données, sachant qu’aucune d’entre elles ne mérite d’être archivé.
1.8 Les Tableaux de Bord
Un tableau de bord est un outil de mesure de performance simplifiant le pilotage d’une ou quelques activités dans le contexte d’une approche qui vise le progrès. Le tableau de bord participe à diminuer l’ambiguïté et simplifie la prise de risque essentielle à toutes décisions. Notre projet a comme objectif d’insérer cet outil dans le but de mesurer l’efficacité et d’amélioration du système de prise de décision dans le secteur de marketing en assurant un suivi continu des clients et de la totalité des produits et les prestations offerts par la BIAT.
1.8.1 Les fonctions des tableaux de bord
Les tableaux de bord jouent un rôle essentiel dans le suivi des performances de l’orga-
nisation. Ils remplissent plusieurs fonctions.
1. Responsabilisation : Implication des équipes dans l’identification, la réalisation et le suivi des performances. 2. Communication : Référentiel commun pour les équipes, vision cohérente et par- tagée. 3. Mesure du progrès : Information sur le degré de réalisation des objectifs, mise en évidence des écarts entre prévisions (objectifs) et réalisations grâce aux indicateurs de performance 4. Anticipation : Alertes dès lors qu’une tendance met en évidence un risque ou un problème 5. Aide à la décision : Diagnostic de la situation et analyse de l’information pour faire des choix pertinents.
7
CHAPITRE 1. PRÉSENTATION GÉNÉRALE
1.8.2 Les qualités du tableau de bord
Pour remplir son rôle correctement, Le TB (tableaux de bord) doit répondre à certains
critères de qualité.
1. Exhaustivité : Le TB doit contenir toutes les informations qui aident à la décision. 2. Simplicité : Le TB ne doit contenir que les informations pour l’aide à la décision. Les informations clés sont agrégées pour être significatives et focalisées sur l’essentiel. 3. Pertinence : Le TB reflète les enjeux de l’organisation en mesurant le niveau d’atteinte des objectifs. 4. Actualisation : Le TB établit des mesures en temps réel pour que la prise de décision se fasse en temps réel. 5. Accessibilité : Chaque décideur peut accéder facilement aux données du système d’information dont il a besoin. 6. Lisibilité : Les données contenues dans le TB sont facilement compréhensibles.
Figure 1.3 – Les fonctions du tableau de bord [4]
1.9 Conclusion
Suite à la présentation de l’organisme d’accueil de la BIAT et l’informatique décision- nelle, nous allons définir dans le chapitre suivant le cadre du projet, l’approche de travail, la problématique et la solution proposée.
8
Chapitre 2
Cadre du projet
2.1 Introduction
Dans cette partie nous allons présenter l’analyse de l’existant, la problématique du projet, les besoins fonctionnels et non fonctionnels du projet et la méthodologie du travail que nous avons suivie. L’objectif essentiel de ce deuxième chapitre est la familiarisation avec les grands axes du projet et l’organisation du travail.
2.2 Présentation du projet
La business intelligence est désormais le moyen le plus bénéficiaire des entreprises pour consolider leurs positions dans le secteur concurrentiel, pour cela la BIAT via sa direction Marketing et Développement Digital désire employer une application d’aide à la décision qui permet de faciliter l’avancement du projet « vision360 » à travers la génération des rapports et des tableaux de bord dont la direction Marketing a besoin pour le développement des instruments commerciaux et éclaircir la vision sur les clients.
2.3 Analyse de l’existant
2.3.1 Existant actuel
Le marché du marketing a beaucoup progressé depuis ces dernières années. Auparavant centré sur le produit, le marketing est à présent centré sur le client ce qui a dirigé la direction marketing et développement digital a constater une carence de connaissance sur les client et de suivi des produits. Certes les outils de suivi employés par la banque sont
Publicité
9
CHAPITRE 2. CADRE DU PROJET
satisfaisants mais d’un autre côté ces outils présentent plusieurs déficiences.
2.3.2 Critique de l’existant
Il existe plusieurs insuffisances dans les outils d’analyse utilisés par la BIAT : — Base de donnée non opérationnelle — Absence de quelques indicateurs pertinents — Absence d’un reporting synthétique
2.3.3 Solution proposé
Le décideur doit avoir toujours les outils et les moyens qui facilitent la meilleure prise de décision, pour cette raison une création de tableau de bord de pilotage stratégique et un reporting synthétique doit avoir lieu. La réalisation des tableaux de bord, des rapports interactifs et des indicateurs de perfor- mance permettant la facilitation des tâches des responsables marché et segment quant au suivi des objectifs par rapport à l’avancement du projet, d’où la baisse du risque d’erreur et le taux d’incertitude dans la prise de décision.
2.4 Méthodologie de travail
Un projet professionnel a besoin d’une approche claire et bien structurée. Cette ap- proche reste essentielle pas uniquement pour organiser le travail mais aussi reconnaître les différents échelons et objectifs afin de mener à bien le projet tout en respectant les bonnes pratiques. Depuis bien longtemps, les deux pères de l’informatique décisionnelle ont proposé deux approches de travail de Data Warehouse :
— Bottom Up : Ralph Kimball — Top Down : Bill Inmon
Approche Bottom Up
« Que chacun construise ce qu’il veut, on intégrera ce qu’il faudra quand il faudra !» Ralph Kimball C’est l’approche inverse que l’approche Top Down, elle a pour objectif de fabriquer des petites data marts qui fournissent des réponses à des nécessités extrêmement particulier et ensuite associer les data marts tous ensembles pour fabriquer le Data Warehouse.[5]
10
CHAPITRE 2. CADRE DU PROJET
Approche Top Down
« On ne fait rien tant que tout n’est pas désigné, le Data Warehouse doit être exhaustif ! » Bill Inmon C’est l’approche la plus pesante, la plus contraignante et la plus complète. Elle a pour ob- jectif de concevoir tout l’entrepôt (c’est-à-dire toutes les Data Marts). D’une autre manière élaborer un data Warehouse qui répond aux besoins de toute l’entreprise.[6]
Ce tableau présente une comparaison entre les deux approches :
Caractéristiques Objectifs
Importance de la conception phy- sique Orientation du mo- dèle Accessibilité utilisateurs finaux
aux
Bottom Up(Ralph Kimball) Livrer une solution permettant aux utilisateurs d’avoir aisément et rapidement des réponses à leurs requêtes d’analyse. Peu importante
Top Down(Bill Inmon) Livrer une solution technologiquement valide fondée sur des méthodes et technologie éprouvées des bases de données Importante
Orientées processus d’affaires
Orientées données
Forte
Faible
Table 2.1 – Tableau comparative des deux approches
2.4.1 Méthodologie Ralph Kimball
En se basant sur les besoins et les obligations fonctionnelles et opérationnelles et l’étude comparative entre les deux méthodologies, nous avons choisi de travailler avec l’approche introduite par Ralph Kimball qui propose un processus complet répété pour chaque nou- veau datamart réclamée par les utilisateurs.
11
CHAPITRE 2. CADRE DU PROJET
Figure 2.1 – Cycle de vie de l’approche Bottom Up [7]
Les phases de cette méthodologie sont :
1.Planification du projet • La planification du projet a une grande influence sur la définition du projet. • Elle dépend des besoins, comme expliqué par la flèche à double sens reliant ces deux étapes. 2.Définition des besoins de l’entreprise • Saisir les facteurs clés qui conduisent l’entreprise à déterminer ses besoins. • Les traduire en facteur pour les intégrer lors de l’approche de conception. 3. Définition de l’architecture technique • Définition des outils et les technologies utilisés pour le développement. • Proposer une vision globale de l’architecture technique à appliquer. 4. Sélection et installation des outils • En se reposant sur l’architecture technique, et en répondant aux besoins du projet nous avons choisi d’établir l’outil avec lequel nous allons travailler. 5. Modélisation des données • Déterminer la méthodologie sélectionnée et les différents modèles. • Concevoir le modèle multidimensionnel et identifier les tables des faits et les di- mensions. • Définition des mesures. 6. Développement des éléments de la zone de préparation de données • Préparation de la table de fait et des dimensions.
12
CHAPITRE 2. CADRE DU PROJET
• Définition de la phase d’ETL. 7. Conception du modèle physique • La conception physique comprend la définition du modèle élaboré. 8. Conception de l’application • Préparation des maquettes qui seront élaborer par la suite. 9. Développement de l’application utilisateur • Après avoir effectué la modélisation et les phases de l’ETL nous élaborons nos tableaux de bords. 10. Déploiement • Convergence de la technologie utilisée et des données. • Planification des formations des utilisateurs et mettre un processus de communi- cation. 11. Croissance et Maintenance • Assurer l’optimalité du fonctionnement du système et prévoir l’insertion de nou- velles fonctionnalités. 12. Gestion du projet • Assurer le bon déroulement du projet. • Contrôler l’état d’avancement du projet. • Détecter et résoudre les problèmes.
2.5 Spécification des besoins
2.5.1 Besoins fonctionnels
Etant la première phase dans le cycle de développement du projet, cette phase est la plus importante. En eet, c’est au cours de celle-ci que les besoins des utilisateurs sont déter- minés et précisés. Ces besoins consistent à comprendre le contexte du système et identifier les fonctionnalités et les acteurs les plus pertinents. Donc notre solution proposée va se concentrer sur ces études :
• Intégration des données :
Avec la plateforme QlikView, à partir des sources de données fournies par la BIAT, nous allons créer un modèle dimensionnel qui va permettre au client d’avoir une nouvelle construction de ses données suivant ses besoins. QlikView peut s’intégrer avec tout type de données fournies par la BIAT.
• Réalisation des tableaux de bord :
Après avoir réalisé le datamart contenant toutes les données nécessaires, nous pouvons passer à l’étape de restitution, après l’exploitation des données stockées nous allons avoir
13
CHAPITRE 2. CADRE DU PROJET
des tableaux de bord de pilotage stratégique couvrant plusieurs axes d’analyses. Notre Solution a pour but de faire profiter son utilisateur de l’ensemble de ces volets d’étude, en se basant sur ces différents indicateurs de performance :
— Suivi du capital client :
•Suivi de la répartition des clients • Suivi de l’évolution du capital client par année. • Suivre la répartition des conquêtes et des attritions. • Suivi du taux de conquête et attrition par année. • Suivi des mouvements mensuel moyen des clients.
— Suivi des dépôts et des comptes :
• Suivi du stock comptes • Suivre la vente des comptes (nombre et volume). • Suivi des dépôts moyens et les efforts de collecte. • Top 20 des ventes de compte.
— Suivi des placements :
• Suivi du stock de contrat de placement. • Suivi de la vente des contrats de placement. • Suivi des placements à échoir. • Top 20 des ventes de contrat de placement.
— Suivi des crédits :
• Suivi du nombre de crédits. • Suivi de la production crédit (montant et nombre). • Suivi des encours crédits. • Suivi des crédits moyens. • Suivi des crédits à échoir. • Suivi des crédits conventionnés. • Top 20 des ventes de crédit.
— Suivi des packs :
• Suivi du stock pack. • Suivi de la vente des packs. • Suivi des packs clôturés. • Top 20 des ventes de pack.
14
CHAPITRE 2. CADRE DU PROJET
2.5.2 Besoins non fonctionnels
Toutes les applications d’aide à la prendre en considération les besoins non fonctionnels
et leurs tests :
Sécurité : De nos jours la sécurité des systèmes d’information demeure une chose indispensable pour le bon fonctionnement et la fiabilité de ce dernier, ce qui a mené les entreprises à créer des méthodes d’authentification, la gestion des utilisateurs et des privi- lèges.
Qualité : Facilitation de l’accès aux données et de la diusion de l’information, fiabilité
et traçabilité des données et interaction homme-machine la plus intuitive possible.
Simplicité :Vu que parmi les utilisateurs de l’application, il existe ceux qui n’ont pas nécessairement de grandes connaissances dans le domaine de l’informatique, les fonc- tionnalités de la solution doivent être compréhensibles et simples à manipuler. En eet, la navigation à travers les diérentes rubriques doit être conçue de manière à ce que l’utilisateur s’y retrouve aisément.
Ergonomie : L’ergonomie et la facilité de l’utilisation sont les choses qui attirent le
plus l’utilisateur, pour cela l’interface de l’application doit être conviviale.
Performance : L’application doit répondre à toutes les exigences des utilisateurs d’une manière optimale. La performance de l’application se traduit par un temps d’accès allégé aux diérentes fonctionnalités, un temps d’accès aux données acceptable vu la manipulation d’un Datamart relativement important.
2.6 Conclusion
Durant ce chapitre nous avons commencé par l’étude de l’existant, puis nous avons présenté l’approche de travail de notre projet et finalement nous avons précisé les diffé- rents besoins fonctionnels et non fonctionnels du projet. Dans le chapitre qui suit nous présenterons l’analyse et la spécification de notre entrepôt de données.
15
Chapitre 3
Spécification et analyse du Data Warehouse
3.1 Introduction
Après avoir extrait les conditions que doit satisfaire l’outil utilisé dans l’étape d’identifi- cation des besoins, nous allons nous concentrer sur la spécification et l’analyse de l’entrepôt de données en se référant à la méthode de Ralph Kimball.
3.2 Modélisation de l’entrepôt de donnée
3.2.1 Modélisation multidimensionnelle
Pour mémoire, il existe trois formes normales principales dénommées 1FN, 2FN, 3FN. Les trois formes normales assurent l’atomisation entité, propriétés, relation et la pertinence du schéma relationnel. Le Data Warehouse n’a pas les mêmes exigences ni la même utili- sation. Les modèles de conception sont totalement différents. Ils sont dénormalisés par définition. Nous retenons deux principaux schémas : le schéma en étoile (Star Schema) et le schéma en flocon (Snowflake Schema).
16
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DU DATA WAREHOUSE
(cid:73) Schéma en étoile :
Le schéma en étoile présente une table de fait centrale et des dimensions qui n’ont pas de liaison entre elles,il permet une économie de jointures à l’interrogation, ce qui le rend optimisé et simple pour les requêtes d’analyse.
Figure 3.1 – Exemple d’un modéle en étoile [8]
17
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DU DATA WAREHOUSE
(cid:73) Schéma en flocon de neige :
Le modèle en flocon de neige est une fusion de plusieurs modèles en étoile qui utilisent des dimensions commune, il est composé de plusieurs tables de fait et tables de dimensions.
Figure 3.2 – Exemple d’un modèle en flocon de neige [9]
Au niveau du Data Warehouse, pour arriver à l’exploitation facile des données, nous
devons classifier par sujet fonctionnel préférablement que par application. C’est une méthode de modélisation logique qui a pour but de présenter les données sous une forme standardisée et qui permet des accès très performants. La modélisation multi- dimensionnelle se base sur deux concepts à savoir les faits et les dimensions. Le Data Warehouse de notre solution est formé d’un groupe de Datamarts, où l’intégration des données est assurée par les dimensions partagées entre les magasins de donnée.
18
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DU DATA WAREHOUSE
Finalement d’après l’approche de Ralph Kimball la conception de notre Data Warehouse est décrite comme « Bottom-Up ». Les Datamarts crées au début pour fournir des analyses des secteur d’activité spécifiques et des rapports, seront par la suite intégrés ensemble pour créer le Data Warehouse.
3.2.2 Représentation et explication du Data Warehouse
Tous les Datamarts partagent des dimensions entre eux et chaque Datamart illustre un
volet d’analyse. Notre modèle de l’entrepôt complet est un modèle en constellation conçu à partir des modèles en flocons de neige.
Figure 3.3 – Modélisation initiale de l’entrepôt de données
Après avoir extrait et chargé les données fournies par l’entreprise, nous avons eu le modèle ci-dessus. Dans le but d’assurer une optimisation maximale, nous avons établi des tableaux contenant les données cible que nous allons utiliser par la suite dans la génération des rapports et des tableaux de bord afin de maximiser l’optimisation et minimiser la lourdeur de l’application.
Les tableaux générés sont exportés sous forme de fichiers QVD (Qlikview Data), fina- lement nous avons chargé ces tableaux afin d’avoir une modélisation simple, optimisée et surtout adaptable selon nos besoins.
19
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DU DATA WAREHOUSE
La figure 3.4 nous présentons la modélisation finale de notre entrepôt après avoir chargé
les fichiers QVD exporter à partir des tableaux de donnée établis.
Figure 3.4 – Modélisation finale de l’entrepôt de données
(cid:73)Description des Dimension partagées :
Dimension Agence
Zone
Région
Marché
Segment
Sous- Segment
Description Cette dimension présente les agences du réseau de la banque. Cette dimension présente les différentes zones de chaque région. Cette dimension présente les régions du réseau de la banque. Cette dimension présente les différents marchés des clients de la banque (GE, PME, Part. . . ). Cette dimension présente la segmentation de la banque de sa clientèle. Cette dimension présente les différents sous-segment des clients de la banque
Table 3.1 – Tableau des dimensions partagées
20
CHAPITRE 3. SPÉCIFICATION ET ANALYSE DU DATA WAREHOUSE
Publicité
Ci-dessous la s