POLINA

Ministère de l’Enseignement Supérieur
et de la Recherche Scientifique
Université de Tunis
Institut Supérieur de Gestion
Rapport de Projet de Fin d’études
Pour l’obtention de la
Licence Appliquée en Informatique Décisionnelle
Mise en place d’un système décisionnel de suivi et de controle de
planning promotionnel des grandes et moyennes surfaces GMS
Entreprise d’accueil :
Poulina Group Holding
Elaboré par :
Ali MEZGHENNI & Nesrine TOUMI
Encadrant académique :
Encadrant professionnel :
Mme. Nadia YAACOUBI
Mme. Ons BOUTIT
Année universitaire : 2018 - 2019
Dédicace
Je dedie ce modeste travail à ma tres chère famille qui m’a toujours soutenu
Je dois à mes parents ce que je suis aujourd’hui et ce que je serai
demain, et je ferai toujours de mon mieux pour rester leur fierté
et ne jamais les décevoir
Nesrine TOUMI
ii
Dédicace
A mes chers parents, pour tous leurs sacrifices, leur soutien et
leurs prières tout au long de mes études.
Ali MEZGHENNI
iii
Remerciements
C’est avec un grand plaisir que nous annonçons l’achèvement de notre mission au sein de
Poulina Group Holding (PGH). Et c’est avec reconnaissance que nous tenons à remercier
tous ceux qui ont contribué dans ce travail.
Nous adressons à Madame Nadia YAACOUBI , notre encadrante pédagogique au sein
de l’Institut Supérieur de Gestion, avec nos sincères remerciements pour le temps et l’effort
qu’elle a accordé pour nous guider et nous aider tout au long du stage.
Dans le même cadre, nous témoignons notre gratitude à toute l’équipe de PGH, et spécialement à Madame Baya HADHRI, Madame Sonia ALOUANE, Madame Ons BOUTIT
qui nous ont bien orienté durant notre projet de fin d’études et qui nous ont soutenu tout au
long de cette période.
Nous remercions également Madame Nour JAMMELI pour sa collaboration et sa cooperation qui ont permis le raffinement de l’élaboration de ce projet ainsi que la compréhension et la maîtrise du metier et du secteur de la vente promotionnelle .
Par cette occasion nous écrivons de même un grand "Merci" à chaque enseignant de
l’Institut Supérieur de Gestion (ISG) qui nous a inspiré, qui nous a conseillé, qui nous a
donné les clés du succès et qui a partagé avec nous sa passion pour l’enseignement et la
recherche scientifique pendant trois ans, vous resteriez dans nos mémoires.
iv
Liste des acronymes
BD : Base de Données
BI : Business Intelligence
DM : Data Mart
ERP : Enterprise Resource Planning
ETL : Extract Transform Load
GIMSI : Généralisation – Information – Méthode – Système - Individualité
MDX : MultiDimensional Expressions
OLAP : OnLine Analytical Processing
SQL : Structured Query Language
SSIS : SQL Server Integration Services
SSAS : SQL Server Analysis Services
SSRS : SQL Server Reporting Services
PGH : Poulina Group Holding
UML : Unified Modeling Language
TB : Tableau de Bord
DW : Data Darehouse
SA : Staging Area
MAJ : Mise A jour
KPI : Ke Performance Indicator
SCD : Slowly Changing Dimension
API : Application Programming Interface
MSBI : Microsoft Business Intelligence
GMS : Grande et Moyennes Surfaces
v
Table des matières
Introduction générale
1
1 Contexte de travail : Identification de l’entreprise et Analyse de l’existant
3
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.1
Identification de l’environnement de Poulina Group Holding . . . . . . . . .
3
1.1.1
Historique de l’organisme d’accueil . . . . . . . . . . . . . . . . . . .
4
1.1.2
Services et prestations de l’entreprise . . . . . . . . . . . . . . . . . .
5
1.1.3
Organisation de l’entreprise . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.4
Direction Informatique . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.1.5
Type de management de Poulina Group Holding . . . . . . . . . . . .
8
1.1.6
Secteur des promotions de vente . . . . . . . . . . . . . . . . . . . . .
8
1.1.6.1
Cible des promotions de vente . . . . . . . . . . . . . . . . .
9
1.1.6.2
Techniques de promotion . . . . . . . . . . . . . . . . . . . .
9
Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2.1
Etude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.2.2
Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
1.2.3
Description de la solution . . . . . . . . . . . . . . . . . . . . . . . .
11
1.2.4
Conception de la solution . . . . . . . . . . . . . . . . . . . . . . . .
12
1.2.4.1
Identification des acteurs du système . . . . . . . . . . . . .
12
1.2.4.2
Production des cas d’utilisation
. . . . . . . . . . . . . . .
13
Planification des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
1.2
1.3
vi
2 Etude comparative : Démarches et Méthodologies
18
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.1
Concept général de l’informatique décisionnelle . . . . . . . . . . . . . . . . .
18
2.2
Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.2.1
Le manifeste agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
2.2.2
Présentation de la méthode SCRUM . . . . . . . . . . . . . . . . . .
20
2.2.3
Présentation de la méthode GIMSI . . . . . . . . . . . . . . . . . . .
20
2.2.4
Méthodologie de travail adoptée . . . . . . . . . . . . . . . . . . . . .
21
Approches de modélisation BI . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.1
Approches Inmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.3.2
Approches Kimball . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.3.3
Approche de modélisation adoptée . . . . . . . . . . . . . . . . . . .
23
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.3
3 Conception générale : Identification des besoins, des indicateurs et Spécification du Tableau de Bord
26
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
3.1
Etude des objectifs et analyse des besoins . . . . . . . . . . . . . . . . . . . .
26
3.1.1
Besoins d’affaires de l’entreprise . . . . . . . . . . . . . . . . . . . . .
26
3.1.2
Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.1.3
Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.2
Construction du tableau de bord . . . . . . . . . . . . . . . . . . . . . . . .
29
3.3
Identification des Indicateurs et des axes d’analyses . . . . . . . . . . . . . .
33
3.4
Collecte des informations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.4.1
Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.4.1.1
Système source . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.4.1.2
Tiers Back-end . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4.1.3
Tiers entrepôt de données . . . . . . . . . . . . . . . . . . .
38
3.4.1.4
Tiers OLAP ou cube de base de données multidimensionnelle
38
3.4.1.5
Tiers Front-end . . . . . . . . . . . . . . . . . . . . . . . . .
38
vii
3.4.2
Modélisation multidimensionnelle . . . . . . . . . . . . . . . . . . . .
38
3.4.2.1
Modèles Schéma en étoile . . . . . . . . . . . . . . . . . . .
39
3.4.2.2
Identifier la granularité . . . . . . . . . . . . . . . . . . . . .
39
3.4.2.3
Spécifier les dimensions . . . . . . . . . . . . . . . . . . . .
39
3.4.2.4
Spécifier la table des faits . . . . . . . . . . . . . . . . . . .
40
3.4.2.5
Modéle à bulles de haut niveau . . . . . . . . . . . . . . . .
40
3.4.2.6
Conception physique détaillée du modèle . . . . . . . . . . .
41
Systéme tableau de bord . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.5
4 Mise en œuvre et amélioration permanente de la solution
48
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.1
Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.1.1
Choix des progiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
4.1.1.1
Etude comparative des outils BI
. . . . . . . . . . . . . . .
49
4.1.1.2
Environnement logiciel choisi . . . . . . . . . . . . . . . . .
50
4.1.1.3
Environnement matériel choisi . . . . . . . . . . . . . . . . .
51
Intégration et déploiement . . . . . . . . . . . . . . . . . . . . . . . .
51
4.1.2.1
Alimentation du DataMart . . . . . . . . . . . . . . . . . .
51
4.1.2.2
Cube OLAP
. . . . . . . . . . . . . . . . . . . . . . . . . .
60
4.1.2.3
Alimentation du tableau de bord . . . . . . . . . . . . . . .
62
4.1.2.4
Validation et test . . . . . . . . . . . . . . . . . . . . . . . .
65
4.1.2.5
Integration . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.1.2
4.1.3
Amélioration permanente
. . . . . . . . . . . . . . . . . . . . . . . .
66
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
Conclusion générale
67
Annexes
71
Annexe 1 : Méthodologie GIMSI
71
viii
Annexe 2 : Approche et principes de Ralph Kimball
75
Annexe 3 : Projet SQL Server Integration Service SSIS
78
Annexe 4 : Projet SQL Server Analysis Service SSAS
87
Annexe 5 : Planification d’un JOB
92
Annexe 6 : Phase de restitution Power BI
95
Annexe 7 :Documentation de la base source
101
Bibliographie
108
Nétographie
108
ix
Table des figures
1.1
Environnement de PGH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
Historique du PGH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3
Organigramme Interne du Groupe Poulina . . . . . . . . . . . . . . . . . . .
7
1.4
Cas d’utilisation général de la solution. . . . . . . . . . . . . . . . . . . . . .
13
1.5
Cas d’utilisation « Gérer le tableau de bord ». . . . . . . . . . . . . . . . . .
14
1.6
Cas d’utilisation « Gérer l’ETL» . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.1
L’approche Top-Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
2.2
L’approche Buttom-Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
3.1
Réalisation d’une maquette
. . . . . . . . . . . . . . . . . . . . . . . . . . .
29
3.2
« Premier niveau consolidé : comparatif entre filiales de PGH » . . . . . . .
30
3.3
« Deuxième niveau de détails : Détails filiales » . . . . . . . . . . . . . . . .
31
3.4
« Troisième niveau de détails : détails produits » . . . . . . . . . . . . . . . .
32
3.5
Architecture technique de la solution . . . . . . . . . . . . . . . . . . . . . .
34
3.6
Modélisation de la base de données sources . . . . . . . . . . . . . . . . . . .
36
3.7
Conception de haut-niveau du modèle en étoile (High-Level Bubble Chart) .
41
3.8
Conception finale du modèle en étoile . . . . . . . . . . . . . . . . . . . . . .
42
4.1
Diagramme de déploiement de la phase d’alimentation des données
. . . . .
52
4.2
Diagramme d’activité d’alimentation des données . . . . . . . . . . . . . . .
53
4.3
Diagramme d’activité d’alimentation des dimensions . . . . . . . . . . . . . .
54
4.4
Diagramme d’activité d’alimentation de la table des faits . . . . . . . . . . .
55
4.5
Authentification SQL Server
56
. . . . . . . . . . . . . . . . . . . . . . . . . .
x
4.6
Hiérarchie d’un projet SSIS . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
4.7
Chargement de table des faits avec SSIS . . . . . . . . . . . . . . . . . . . .
61
4.8
Diagramme de déploiement de la phase de restitution des données . . . . . .
62
4.9
Restitution de données : niveau 1 . . . . . . . . . . . . . . . . . . . . . . . .
63
4.10 Restitution de données : niveau 2 . . . . . . . . . . . . . . . . . . . . . . . .
64
4.11 Restitution de données : niveau 3 . . . . . . . . . . . . . . . . . . . . . . . .
65
4.12 Cycle de vie de Kimball [11] . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
4.13 Implémentation Physique du DataMart Promo . . . . . . . . . . . . . . . . .
78
4.14 Lancement d’un nouveau projet SSIS . . . . . . . . . . . . . . . . . . . . . .
79
4.15 Package SSIS du staging area . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.16 Utilisation des variables pour le staging . . . . . . . . . . . . . . . . . . . . .
80
4.17 Staging pour la table « Action » . . . . . . . . . . . . . . . . . . . . . . . . .
81
4.18 Extraction de l’identifiant du dernier élément stocké pour la table « Action »
81
4.19 Staging pour la table « Filiale » . . . . . . . . . . . . . . . . . . . . . . . . .
82
4.20 Package SSIS d’alimentation du DataMart . . . . . . . . . . . . . . . . . . .
82
4.21 Colonne Dérivée dans SSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
4.22 Flux de contrôle de Dim_Item . . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.23 Flux de contrôle de Dim_Concurrent . . . . . . . . . . . . . . . . . . . . . .
85
4.24 Alimentation de la table des faits . . . . . . . . . . . . . . . . . . . . . . . .
86
4.25 Cube OLAP[12]
87
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.26 Lancement d’un nouveau projet SSAS
. . . . . . . . . . . . . . . . . . . . .
88
4.27 Vue de source de données
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
4.28 Vue de source de données
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.29 Vue de source de données
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
4.30 « Authentification Windows » . . . . . . . . . . . . . . . . . . . . . . . . . .
92
4.31 « Authentification Windows » . . . . . . . . . . . . . . . . . . . . . . . . . .
93
4.32 « Authentification Windows » . . . . . . . . . . . . . . . . . . . . . . . . . .
94
4.33 Outils de restitution de données [13] . . . . . . . . . . . . . . . . . . . . . . .
95
4.34 Tableau de bord de consolidé . . . . . . . . . . . . . . . . . . . . . . . . . .
96
4.35 Deuxième niveau de la filiale GIPA . . . . . . . . . . . . . . . . . . . . . . .
97
xi
4.36 Troisième niveau de la filiale GIPA . . . . . . . . . . . . . . . . . . . . . . .
98
4.37 Deuxième niveau de la filiale Global Trading
. . . . . . . . . . . . . . . . .
99
4.38 Troisième niveau de la filiale Global Trading . . . . . . . . . . . . . . . . . .
100
xii
Liste des tableaux
1.1
Planning du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.1
Tableau comparatif entre Inmon et Kimball . . . . . . . . . . . . . . . . . .
24
3.1
Tableau récapitulatif des objectifs. . . . . . . . . . . . . . . . . . . . . . . . .
27
3.2
Identification des KPIs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
3.3
Collecte d’informations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
3.4
Dimension Enseigne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
3.5
Dimension Action. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.6
Dimension Conurrent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.7
Dimension Filiale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
3.8
Dimension Insertion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.9
Dimension Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.10 Dimension Mécanisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.11 Dimension Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
3.12 Table de faits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
4.1
Top 3 des technologies BI . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
4.2
Environnement matériel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.3
Détails de la phase d’extraction. . . . . . . . . . . . . . . . . . . . . . . . . .
58
4.4
Details de la phase d’extraction. . . . . . . . . . . . . . . . . . . . . . . . . .
59
xiii
Introduction générale
Avec un marché fortement concurrentiel et un environnement hautement complexe les entreprises cherchent toujours les moyens d’évoluer en vue de faire croitre leur chiffre d’affaires
et leur part du marché. Conséquemment dans un climat de forte concurrence, une veille et
surveillance étroite du marché est exigée, pour ne pas se laisser dépasser. A cet égard une
stratégie qui valorise l’information doit être établie, pour pouvoir en extraire des estimations,
des analyses afin de s’orienter vers une prise de décision objective et avec le minimum d’incertitude. L’information dans ce cadre doit être une information fiable et de qualité, pour
parvenir à l’exploiter.
Dans ce cadre la Business Intelligence est apparu. Ce concept englobe les technologies, méthodes et principes, auxquels chaque entreprise accorde une forte priorité. La BI intervient
alors dès la phase de collecte des données. Ces dernières seront stockées dans une structure
bien déterminée pour qu’elles soient traitées. Pour le département commercial de notre entreprise d’accueil, les données volumineuses provenant de plusieurs sources sont précieuses et
leur exploitation est une nécessité pour parvenir à l’amélioration du processus de la prise de
décision à divers niveau de l’entreprise
Dés lors l’objectif du département commercial est l’amélioration de la rentabilité des actions
promotionnelles effectuées dans les enseignes collaborant avec PGH, ainsi que sa capacité de
satisfaire sa clientèle. Dans cette perspective notre projet de fin d’études s’introduit. Il s’agit
de faire intégrer une solution BI, élaborée par les produits Microsoft. Cette solution sera un
outil d’analyse et de suivi des promotions de l’entreprise et de même de ses concurrents au
sein des GMS.
1
Le présent document est le rapport du projet de fin d’étude visant à identifier notre démarche
pour la réalisation d’une solution décisionnelle.
• Chapitre 1
Ce chapitre est dévoué à la présentation générale de PGH ; Environnement, secteurs et
organisation.
• Chapitre 2
Etude comparative des méthodologies de travails et des approches de modélisation ;
• Chapitre 3
Conception générale de la solution élaborée ;
• Chapitre 4
Mise en œuvre, déploiement et intégration. Nous clôturons le présent rapport par une
conclusion générale sur le travail réalisé ainsi que par la présentation de nos perspectives.
2
Contexte de travail
Chapitre 1
Chapitre 1
Contexte de travail : Identification de
l’entreprise et Analyse de l’existant
Introduction
La première partie de ce chapitre va être dédiée à un aperçu global sur l’organisme d’accueil « Poulina Group Holding » nous allons parler de son historique, son organisation et
incontestablement du département dans lequel nous étions affectés. Nous allons évoquer,
ultérieurement le contexte du projet afin de clarifier l’idée maitresse.
1.1
Identification de l’environnement de Poulina Group
Holding
Le groupe Poulina représente un empire dans l’économie tunisienne ainsi que à l’échelle
international. Avec plus que 7 filiales opérant dans divers secteurs, PGH a marqué son nom
en dominant les marchés d’agroalimentaire, d’immobilier, des biens d’équipement et bien
d’autres (Voir figure 1.1).
2018/2019
3
Contexte de travail
Chapitre 1
Figure 1.1 – Environnement de PGH.
1.1.1
Historique de l’organisme d’accueil
Poulina Group Holding (PGH) était fondé en 1967 par 7 entrepreneurs privés. Cette
entreprise a commencé par l’aviculture en Tunisie et a établi dès le début une stratégie d’intégration dans les différentes activités de cette filière. Elle a élargie son secteur d’activité pour
comprendre tous les services et fournitures qu’un éleveur en aura besoin (matériel avicole,
poussins d’un jour, aliments, etc.).
PGH a investi plus tard dans plusieurs secteurs ce qui a créé de la diversification industrielle.
En 2008 PGH est considéré comme une force économique, l’entreprise était introduite en
Bourse (L’évolution du groupe est illustré dans la figure 1.2). C’est avec cette décision et la
variation de ses prestations qu’une autre restructuration de l’entreprise était exigée ; d’où la
centralisation du groupe autours de 8 métiers ; Dans le but de simplifier la gestion, le contrôle
et le suivi de la performance. Cette réorganisation a fait augmenter le nombre des employés
jusqu’à 1200[N1].
2018/2019
4
Contexte de travail
Chapitre 1
Figure 1.2 – Historique du PGH.
1.1.2
Services et prestations de l’entreprise
Comme nous avons mentionné auparavant la recomposition a mis en valeur une dizaine
de métiers représentant les pôles d’activité de la Holding[2] :
• L’intégration avicole
L’entreprise a commencé dans le secteur avicole. Ce Groupe a fait élargir ses activités
pour inclure ; la production, la nutrition animale, la distribution des dindes, poulets,
œufs, viandes, etc. Sa bonne gestion, son contrôle et suivi permanent et son large réseau
lui ont permis de devenir le leader en Tunisie. Il est considéré de nos jours comme
l’acteur principal dans le secteur avicole.
(SNA, Oasis, El Mazraa) ;
• Les produits de grande consommation
À travers ce métier, la Holding commercialise une large gamme de produits tels que
les produits laitiers, jus etc. Le groupe a réussi à marquer son nom dans le secteur
agroalimentaire.
(Gipa, Chahrazed, Medoil Sénégal) ;
2018/2019
5
Contexte de travail
Chapitre 1
• La transformation de l’acier
Aujourd’hui le groupe opère dans la transformation de l’acier, avec un positionnement
strategique vis-à-vis à la concurrence en Tunisie et même dans les pays limitrophes.
(Africaine de Transformation De Métaux, SCI, SGN) ;
• L’emballage
Avec une croissance remarquable du besoin en matière d’emballage le Groupe a pu
s’intégrer et est devenu le leader avec 30 pourcent de part de marché.
(Avi pack, Lin Pack, ITC.) ;
• L’immobilier
Le Groupe a créé en 1997 une nouvelle filiale d’immobilier ETTAAMIR. Cette dernière
est l’un des acteurs incontournables dans ce secteur. Elle a réalisé des projets de haut
standing et elle en a d’autre en cours de réalisation.
(S.P.I. ETTAAMIR) ;
• Le bois et les biens d’équipement
Ce métier date depuis 1975 suite à la création de GAN, société industrielle qui regroupe
2 activités le mobilier de bureau et l’électroménager. PGH se concidére comme une
entreprise dominante avec 60 pourcent du marché.
(MEDMED INDUSTRIES, ESMERALDA, GAN) ;
• Les matériaux de construction
Elle exporte plus de 20 pourcent de la production vers la France, les pays de l’Afrique
et du Maghreb, l’Ouest et même les pays du Golf.
(CARTHAGO CERAMIC, Salambo Ceramic) ;
• Le commerce et les services
La Holding regroupe plusieurs sociétés qui opèrent dans l’import, le commerce international, le conditionnement et même les nouvelles technologies(NTIC). Poulina a introduit la technologie « Tiers3+ » par la création du Data Center en 2012. L’entreprise
a même coopéré avec une société française « Intrinsec » dans le but de créer « Cloud
Temple Tunisia » qui était fondé avec succès. (ASTER INFORMATIQUE, Poulina
Produits Métallique).
2018/2019
6
Contexte de travail
1.1.3
Chapitre 1
Organisation de l’entreprise
PGH possède une structure spécifique qui se résume en 3 parties (voir figure 1.3) :
• Une Direction Générale entourée de coordinateurs ;
• Des unités opérationnelles qui couvrent tous les aspects de gestion ;
• Une direction qui englobe l’audit, le contrôle et l’inspection [3].
Figure 1.3 – Organigramme Interne du Groupe Poulina
1.1.4
Direction Informatique
La direction informatique est considérée comme l’un des piliers de PGH elle est chargée
de l’élaboration des études stratégiques basées sur le système d’information de l’entreprise.
2018/2019
7
Contexte de travail
Chapitre 1
Ce département oriente et dirige le Groupe vers l’informatisation/l’automatisation des processus de travail pour plus de flexibilité et de rapidité. Cette direction est dirigée par le
directeur de développement numérique Mr.Naceur KCHAOU. Sa mission peut se résumer en 4 principaux axes :
• La Mise en pratique d’une stratégie SI ;
• La supervision et le contrôle de l’avancement des projets informatiques ;
• La gestion des ressources du departement informatique ;
• La veille concurrentielle et la détection des opportunités.
1.1.5
Type de management de Poulina Group Holding
Le type de management d’une organisation présente sa politique générale. La stratégie
de Poulina Group Holding se distingue par l’adaptation d’un type de management délégatif
et participatif à la fois ; Ce dernier se repose sur le résultat obtenu par l’implication des
collaborateurs et des consultants dans la prise de décision. En d’autres termes le manager
n’est plus isolé et autoritaire. Nous parlons plutôt de responsabilisation et implication de
tous les acteurs. Ceci assure la motivation et la participation des collaborateurs. Néanmoins
suite au déploiement de la stratégie dans l’organisation il est défiant de la faire passer au
niveau opérationnel. A cet égard il est important de s’assurer du niveau d’engagement de ces
derniers ainsi que de préserver l’autonomie et la créativité des personnes impliquées.
1.1.6
Secteur des promotions de vente
Pour bien concevoir une solution décisionnelle il est primordial de comprendre les fondamentaux du secteur promotionnel. Les promotions sont un avantage dit temporaire qui
vise soit la fidélisation de sa clientèle ou à la séduction et l’attraction des nouveaux clients.
Ces actions promotionnelles se font dans la production alimentaire et également dans les
autres secteurs d’activité commerciale. Ces opérations sont présentes ainsi dans l’étendu de
la grande distribution et elles sont négociées entre les enseignes et les marques, cela se fait
dans le cadre du « Trade Marketing ». .
2018/2019
8
Contexte de travail
1.1.6.1
Chapitre 1
Cible des promotions de vente
Les promotions de vente visent principalement le consommateur, mais aussi elle met en
jeu deux autres facteurs qui sont le distributeur et la force de vente :
• Consommateur : Jouer sur les préférences et les gouts afin de l’inciter à acheter de plus ;
• Distributeur : Pousser les distributeur à vendre les produits ;
• Force de vente : Encourager les vendeurs à faire augmenter leurs chiffres d’affaire.
1.1.6.2
Techniques de promotion
Dans ce domaine nous distinguons plusieurs techniques promotionnelles qui viennent dans
le but de stimuler les ventes.
• Faire baisser les prix des articles ;
• Remettre des titres de remboursement sur le conditionnement de l’article au consommateur ;
• Effectuer des réductions sur un deuxième article acheté ;
• Permettre le consommateur de gagner des lots en nature ou même en espèce après leur
participation à un concours.
1.2
Analyse de l’existant
Cette partie a pour objectif d’étudier dans un premier temps la solution existante afin
d’en dégager les failles et d’identifier ses limites. Cela va être suit par l’explication de la
solution proposée ainsi que la présentation des différents aspects de notre projet.
1.2.1
Etude de l’existant
La stratégie adaptée actuellement par le département commercial est le recours aux actions promotionnelles via les enseignes afin de stimuler la vente de ses produits. Dans ce
cadre PGH voulait suivre le planning promotionnel dans les grandes et moyennes surfaces
(GMS).
2018/2019
9
Contexte de travail
Chapitre 1
Pour se faire elle a mis en place une application web « PROMOTIPS » assurant les tâches
suivantes :
• La saisie du planning promotionnel des GMS ;
• La saisie manuelle des détails relatives à chaque action promotionnelle : Article en
promotion, filiale, concurrent, type d’action, etc ;
• La visualisation des graphiques non-dynamiques comportant un nombre d’indicateurs
(Taux de participation, Nombre d’action, etc.)
L’utilisation des données issues de cette application se fait en moyenne, chaque 2 ou 3 semaines
par un responsable commercial qui traite les données d’une manière classique. Via l’outil
Excel il génère un TB consolidé de rapports qui concernent chaque filiale. Ses rapports
seront communiqués aux dirigeants de la Holding par email.
1.2.2
Problématique
Ces dernières années, les ventes promotionnelles dans les GMS ont connu un développement considérable. Cela se montre principalement au niveau de l’investissement dans les
actions promotionnelles qui représentent le double de celles investies dans la publicité. Ces
dernières assurent un bénéfice remarquable à court terme, or leur capacité d’augmenter les
ventes à long terme est une affaire préoccupante.
Dans ce cadre, et au sein d’une empire comme PGH, un investissement qui dépasse les 2
millions de Dinars par ans dans les opérations promotionnelles exige un système de suivi qui
permet les dirigeant d’évaluer la situations des filiales de PGH et alors d’interagir aux bons
moments.
Néanmoins, actuellement l’analyse des données collectées, n’est pas réalisée d’une façon correcte et périodique, cela peut engendrer une déviation de la trajectoire commerciale, et par
la suite un gaspillage de temps et de ressources. Conséquemment il sera difficile d’effectuer
des estimations et des analyses avancées dans un contexte décisionnel, vu que le département
commercial suit une méthode classique du reporting et par conséquence les tableaux de bord
réalisés ne sont pas réactifs.
2018/2019
10
Contexte de travail
Chapitre 1
Dans ce contexte, notre rôle est de fournir une solution automatisée qui s’inscrit dans le
domaine commercial. Pour le suivi des actions promotionnelles dans les GMS. Elle va servir
pareillement au service comptable qui rencontre des difficultés au niveau de la disponibilité et
l’accessibilité de l’information promotionnelle. Concisément la solution choisie va permettre
de répondre à plusieurs enjeux :
L’axe technique
• L’accessibilité à l’information à tout moment ;
• Le problème de données manquantes et erronées ;
• L’intégrité des données et les erreurs qui peuvent surgir au niveau des tâches manuelles.
• La non réactivité des tableaux de bord existants ;
• L’exploitation directe d’une base de données relationnelle, ce qui engendre un temps
de réponse énorme vu le nombre de jointures existant.
• L’automatisation du processus ETL.
L’axe décisionnel et stratégique
• L’imprécision de la représentation des indicateurs ;
• La possibilité de se comparer avec les concurrents ;
• La facilité de l’auto évaluation et l’analyse de l’information ;
• La securisation des TBs et l’elimination des fichiers Excel non controlés, échangés entre
les acteurs du système.
• La minimisation de risque de la prise de décision.
1.2.3
Description de la solution
Dans le cadre de notre projet de fin d’étude, nous avons conçu une solution BI, respectant
la chaine décisionnelle de l’analyse des données jusqu’au reporting déployée sur un serveur.
Elle permet l’exploitation des données extraites de la base de données de l’application de
suivi des promotions dans les GMS afin de s’assurer en permanence de leur efficacité, leur
rôle ainsi que leur évolution dans le temps.
2018/2019
11
Contexte de travail
Chapitre 1
Cela va être assuré à travers un tableau de bord décisionnel dédié à la comité de direction
générale afin d’évaluer la performance du groupe PGH. Pour récapituler ce projet va résoudre
des problèmes au niveau interne et externe :
• Assurer l’accessibilité et la disponibilité de l’information ;
• Analyser les données et fournir des tableaux de bord dynamiques ;
• Fournir et diffuser des rapports détaillés ;
• Gérer les promotions communiquées et non-communiquées ;
• Suivre les promotions annulées, réalisées ou en attente ;
• Faciliter la prise de décision.
Cette solution sera destinée aux décideurs de l’entreprise. Elle permettra de visualiser les
indicateurs de performance dans une interface conviviale, une interface structurée et facile à
comprendre qui répond à tous les besoins des managers.
1.2.4
Conception de la solution
Dans le but de s’assurer que le développement sera conforme au cahier de charges nous
avons choisi de réaliser des diagrammes de cas d’utilisation de la solution. Cela reflète le
comportement du système proposé ainsi que les acteurs impliqués. Cette phase est une formalisation des étapes de la mise en œuvre du système.
1.2.4.1
Identification des acteurs du système
Notre système met en jeu de deux acteurs principaux ; Le client qui est le décideur et
l’administrateur :
• Le décideur : C’est celui qui exige des fonctionnalités et énonce des besoins. Il va
consulter le TB et imprimer des rapports via un navigateur web avec une authentification implicite ;
• L’administrateur : c’est celui qui, après authentification, s’occupe du système. Il est
chargé de la gestion du tableau de bord, de l’ETL et du cube OLAP .
2018/2019
12
Contexte de travail
1.2.4.2
Chapitre 1
Production des cas d’utilisation
Le cas d’utilisation sert à clarifier les relations entre le système et ses acteurs. Egalement
il permet d’abstraite les exigences fonctionnelles. A cet égard nous avons réalisé :
• Un cas d’utilisation général du système (Voir figure 1.4) ;
Figure 1.4 – Cas d’utilisation général de la solution.
2018/2019
13
Contexte de travail
Chapitre 1
• Un raffinement du cas d’utilisation « Gérer le tableau de bord » (Voir figure
1.5)
Figure 1.5 – Cas d’utilisation « Gérer le tableau de bord ».
2018/2019
14
• Un raffinement du cas d’utilisation « Gérer l’ETL» (Voir figure 1.6)
Figure 1.6 – Cas d’utilisation « Gérer l’ETL»
1.3
Planification des tâches
Peu importe la complexité d’un projet il demeure toujours indispensable de planifier ses
tâches à l’avance. Cela permet de s’assurer que l’équipe est sur la bonne trajectoire. Dans
notre cas nous avons choisi de travailler avec "Gantt Project" ; Un logiciel de gestion de
projet, en vue de planifier nos tâche et de les ordonner en se basant sur la démarche GIMSI
(Voir tableau 1.1).
15
Contexte de travail
Chapitre 1
Ordre
Tâches
Durée
Date debut
Date fin
1
Formation autour de l’approche Kimball
30j
01/02/2019
28/02/2019
2
Formation autour des produits MSBI
15j
15/02/2019
28/02/2019
3
Etude de l’environnement de PGH
2j
01/03/2019
02/03/2019
4
Etude de l’organisme d’accueil
1j
03/03/2019
04/03/2019
5
Familiariser avec le coté metier
4j
05/03/2019
08/03/2019
6
Analyse et documentation des besoins
et des objectifs
2j
09/03/2019
10/03/2019
7
Reunion avec le respensable du département commerciale et identification
des tableaux de bord souhaités
2j
11/03/2019
12/03/2019
8
Negociation des indicateurs
3j
13/03/2019
15/03/2019
9
Documentation des KPIs
1j
16/03/2019
16/03/2019
10
Etude du système tableau de bord
1j
17/03/2019
17/03/2019
11
Identifcation de l’architecture physique
2j
18/03/2019
19/03/2019
12
Etude des données sources
4j
20/03/2019
23/03/2019
13
Modelisation multidimensionnelle
3j
24/03/2019
27/03/2019
14
Implementation physique du modéle
3j
28/03/2019
30/03/2019
15
Alimentation du DM, mapping et
ETL
12j
01/04/2019
11/04/2019
16
Analyse avec cube OLAP
2j
12/04/2019
13/04/2019
17
Deploiement et passage à la restitution
des données
4j
14/04/2019
17/04/2019
18
Preparation de l’intégration de la solution
2j
15/04/2019
16/04/2019
20
Validation du projet et prise d’accord
du département commerciale
5j
17/04/2019
21/04/2019
21
Realisation du rapport
8j
22/04/2019
30/04/2019
Table 1.1 – Planning du projet
2018/2019
16
Contexte de travail
Chapitre 1
Conclusion
Ce chapitre, consacré au contexte général de projet, nous a permis de présenter l’organisme
d’accueil, ainsi que de réaliser une description générale du projet. De même nous avons bien
présenté le secteur des promotions des ventes qui est le cœur de notre projet.
2018/2019
17
Etude comparative : Démarches et méthodologies
Chapitre 2
Chapitre 2
Etude comparative : Démarches et
Méthodologies
Introduction
L’informatique décisionnelle est tout un concept, qui touche non seulement au côté technologique mais il met en valeur aussi l’importance du choix d’une méthodologie de travail.
Ce chapitre sera réservé alors, à une étude comparative dans laquelle nous aborderons les
différentes méthodologies de travail ainsi que les approches de modélisation.
2.1
Concept général de l’informatique décisionnelle
L’informatique décisionnelle, ou encore Business Intelligence, est une discipline assemblant les outils, les moyens et les procès qui assurent la génération des indicateurs ; connus
par le terme KPIs. Ceci permet d’amplifier la précision et l’exactitude de l’information tout
en gardant la simplicité et la facilité de son interrogation. En outre la BI offre la possibilité
de visualiser cette information sous forme compréhensible et présentable [4].
2018/2019
18
Etude comparative : Démarches et méthodologies
Chapitre 2
Pour résumer, l’exploitation de l’information dans le cadre décisionnel se fait comme suit :
• Extraction et collecte de données à partir des systèmes, fichier, etc. ;
• Nettoyage et standardisation des formats des données ;
• Centralisation et stockage de données dans une structure facile à interroger ;
• Traitement de l’information et génération des indicateurs.
Par ailleurs, il est assez important de choisir une démarche spécifique de travail, permettant
de mieux gérer l’avancement et l’auto-évaluation de l’équipe.
2.2
Méthodologie de travail
Une méthodologie de travail est tout simplement la formulation des règles et des bonnes
pratiques extraites à partir des expériences antérieures. Cette formulation assure le bon déroulement d’un projet. En outre les méthodes sont différentes et diverses et constamment
évolutives. Nous sommes passés des méthodes classiques aux méthodes agiles. Le concept
d’agilité vient en 1995 avec l’équipe Rugby, mais le terme "agile" n’apparait que plus tard
en 2001, une collaboration entre des experts en génie logiciel a donné naissance au Manifeste
Agile, qui vient avec le terme agile et qui se base sur ce qui était découvert auparavant.
D’après eux face aux problèmes et besoins actuels les méthodes classiques ne font plus l’affaire. A cet égard l’agilité représente une solution alternative, vu qu’elle assure une flexibilité
et une meilleure gestion du travail collaboratif.
2.2.1
Le manifeste agile
L’agilité s’associe essentiellement aux projets informatiques, néanmoins elle peut être appliquée dans d’autres domaines. Elle offre une communication et une collaboration continues
entre l’équipe et ses clients. Ce qui aide à mieux suivre l’avancement du projet. Le client
reçoit des livrables ; « preuves tangibles de l’avancement du projet » [5]. Une communication
mène à une bonne visibilité. Ainsi, les failles sont détectées dès le début. Les méthodes les
plus populaires en termes d’agilité ce sont SCRUM et GIMSI.
2018/2019
19
Etude comparative : Démarches et méthodologies
2.2.2
Chapitre 2
Présentation de la méthode SCRUM
SCRUM est l’une des méthodes agiles. Cette approche est dédiée principalement aux
projets complexes, essentiellement la mise en place des applications. Elle vise l’amélioration
de la production d’une équipe en assurant la coopération et la coordination entre les individus.
Aussi par l’implication du client tout au long de la réalisation du projet, ainsi qu’elle repose
sur la dynamicité et la diversité des compétences. Le principe est de faire sortir l’équipe du
cadre classique, où le manager donne les ordres, vers un milieu de travail plus flexible dans
lequel l’initiative individuelle est permise d’où le terme équipe « auto-organisé ». En outre
cette approche nécessite que le projet soit réglé en cycles itératifs et incrémentaux. Dans
un intervalle de temps Timeboxing bien déterminé le projet sera rythmé par des réunions
régulières au cours desquelles l’avancement sera discuté et les priorités seront fixées. Durant
ces itérations il est possible de modifier ce qui était élaboré si le client aborde d’autres
exigences.
SCRUM se base sur des intervenants et des artefacts :
• Product Owner : Responsable du produit ; celui qui définit les besoins ;
• Scrum Master : Contrôleur du déroulement du SCRUM tout en facilitant le travail de
l’équipe ;
• Scrum Team : Ensemble d’individus collaborant pour délivrer le produit ou le service ;
• Product Backlog : Liste des exigences et spécifications du produit ;
• Sprint Backlog : Tâches à faire dans un intervalle de temps ;
• Sprint Burn-Down Chart : Graphique d’avancement.
2.2.3
Présentation de la méthode GIMSI
GIMSI dans le même concept de l’agilité était publié sous le nom "Les nouveaux tableaux
de bord pour piloter l’entreprise" en 1998, et vient pour s’associer aux projets décisionnels.
Autrement dit c’est une méthodologie coopérative qui mène au pilotage correcte des organisations ; par l’intermédiaire des Dashboards. Elle est centrée autour la dynamicté des processus
métier, la gestion du risque et l’élimination de la barrière technique qui présentait auparavant
des difficultés face aux utilisateurs du produit décisionnel.
2018/2019
20
Etude comparative : Démarches et méthodologies
Chapitre 2
Ce qui se résume en son acronyme :
G[généralisation] : La méthodologie est applicable dans divers domaines.
I[information] : L’information est la clé pour la prise de décision ;
M[méthode et mesure] : Elle vise de mesurer des indicateurs ;
S[système et systémique] : Partant d’un concept systémique elle assure la construction d’un
système de pilotage ;
I[initiative et individualité] : L’individu est appelé à prendre l’initiative et à être autonome.
[Généralisation de l’accès aux Informations décisionnelles en s’appuyant sur une Méthodologie
d’inspiration Systémique facilitant l’Expression des Individualités de l’Entreprise.]
En outre cette approche correspond au management moderne qui se base sur 10 étapes de
gouvernances (Voir annexe 1).
2.2.4
Méthodologie de travail adoptée
Dans notre cas la méthode GIMSI représente la manière ultime de se lancer dans notre
projet. L’agilité et la flexibilité qu’elle offre nous assure l’obtention d’un produit de qualité
acceptable par le client et les décideurs, autrement dit la conformité de la solution avec leurs
attentes. De plus, elle est plus adaptée à un projet BI que la méthode SCRUM. En effet,
la méthodologie GIMSI, décrit le processus détaillé pour l’obtention d’un TB. La stratégie
suit au sein de l’entreprise, nécessite la planification des « interviews » avec le client afin
de collecter le maximum d’information concernant les problèmes à résoudre ainsi que les
attentes et les besoins à satisfaire. Pour cela des réunions avec l’équipe commerciale ont eu
lieu. Ces dernières nous ont fait comprendre la stratégie et le processus de suivi des actions
promotionnelles adaptés par PGH, ainsi que nous ont permis de détecter quelques problèmes.
2018/2019
21
Etude comparative : Démarches et méthodologies
2.3
Chapitre 2
Approches de modélisation BI
Le concept autour duquel tourne l’environnement décisionnel, est la réalisation d’un entrepôt de données (DW). Son rôle majeur est d’emmagasiner des données « épurées, organisées,
historiées et provenant de plusieurs sources de données, servant aux analyses et à l’aide à la
décision » [8]. Dès lors la question qui se pose c’est quelle structure à adapter, et permet-elle
de satisfaire les besoins fonctionnels ? Pour répondre à cette question nous faisons face à deux
grand concepts ; l’approche Bill Inmon et l’approche Ralph Kimball.
2.3.1
Approches Inmon
L’architecture générale de l’approche «Top-Down », proposée par Inmon, impose la présence de Staging Area, de Data Warehouse et des Data Marts ; c’est une architecture multitiers. Le modèle logique doit être conçu en premier lieu en respectant la normalisation. Ce
modèle évite le maximum la redondance pour plus de cohérence. Il représente également,
une vue globale de l’entreprise, tout en capturant les clés d’entreprise, les attributs, les dépendances ainsi que les relations existantes. Tout cela sera physiquement implémenté pour
représenter le Data Warehouse. La difficulté sera envisagée au niveau de son interrogation
par les requêtes ; vu la normalisation du modèle et les jointures entre les tables. Pour cette
raison Inmon a proposé de construire des DataMarts (voir figure 2.2), chacun reflétant un
département ou processus de l’entreprise de cette manière, nous aurons une seule source de
données qui alimente les DMs, c’est le DW.
Figure 2.1 – L’approche Top-Down
2018/2019
22
Etude comparative : Démarches et méthodologies
2.3.2
Chapitre 2
Approches Kimball
L’approche Kimball aussi connue par le terme « Buttom-Up », est une méthodologie
de réalisation d’un projet décisionnelle. Elle était proposée par Mr Ralph KIMBALL un
informaticien qui s’intéresse à la Business Intelligence (BI). Cette approche se contredit avec
celle de Mr.Inmon qui se repose sur les modèles E-A (entité-association), elle s’oriente vers
le domaine décisionnel, vise principalement la modélisation dimensionnelle et se base sur les
tables de faits et les dimensions. Selon Kimball l’obtention d’un DataWarehouse (DW) ou
entrepôt de données se fait suite à l’union des DataMarts (voir figure 2.3) qui sont construits
de manière incrémentale et intégrée. Ces derniers reflètent une vue détaillée de l’entreprise
comprenant des données atomiques. Représentant chacun un seul schéma en étoile (star
schéma).
NB : Les DataWarehouses ne sont pas physiquement implémentés.
Figure 2.2 – L’approche Buttom-Up
2.3.3
Approche de modélisation adoptée
Les deux approches permettent d’effectuer des analyses avancées sur un volume important
de données atomiques et de différents niveaux de granularité. Par conséquence la modélisation
doit suivre l’une de ces derniers principes. Le choix se fait selon des facteurs bien précis tels
que :
• La cible de la solution décisionnelle :
Est-ce qu’on vise la globalité de l’entreprise ou un département bien précis ;
2018/2019
23
• La durée allouée pour le projet :
Si le projet doit être délivré en urgence (pas plus que 3 mois) l’approche kimball est
plus adaptée. Par contre si l’équipe aurait un intervalle de 4 à 9 mois la méthode Inmon
est possible ;
• Les ressources humaines et financières :
La modélisation Inmon nécessite, plus tard, une large équipe de spécialistes pour maintenir la DW au contraire du modèle Kimball ;
• Les systèmes source :
Inmon est destiné aux systèmes trop dynamiques. Quant à Kimball il travaille sur les
systèmes plus au moins stables ;
• La stratégie managériale adaptée :
L’implémentation d’un tel projet nécessite un esprit ouvert, prêt d’investir dans ce
concept, et conscient de la valeur d’une telle solution. Pour conclure Inmon nécessite
un financement important à l’opposé de Kimball.
Approche Inmon
Approche Kimball
DataWarehouse orienté entreprise
DataWarehouse multidimensionnel
Un système stratégique de pilotage moderne
Un système tactique de pilotage moderne
Les systèmes sources ont un taux de
changement élevé
Les systèmes sources sont assez stables
Des spécialistes dans le côté technique
et le coté métier à la fois sont exigés
Une équipe réduite en nombre pourrait
achever le projet
Table 2.1 – Tableau comparatif entre Inmon et Kimball
En prenant en compte tous les éléments cités, ainsi que les préférences de l’entreprise nous
avons entamé le travail avec le principe Kimball vu les moyens, la cible et la durée de notre
stage.
24
Etude comparative : Démarches et méthodologies
Chapitre 2
Conclusion
Ce chapitre était dédié à une étude comparative, présentant les différentes approches
de modélisation et méthodes de gestion de travail. Nous avons clôturé cette section avec
l’explication de nos choix théoriques. Le chapitre qui suit sera une décortication de notre
projet et les attentes du client.
2018/2019
25
Conception générale
Chapitre 3
Chapitre 3
Conception générale : Identification des
besoins, des indicateurs et Spécification
du Tableau de Bord
Introduction
Avant le lancement du travail il est indispensable de clarifier les aspects du projet. A
cet égard nous allons consacrer cette partie à l’identification de son étendu, cela implique
la description des fonctionnalités de base de la solution ainsi que sa performance. Dans un
autre temps nous allons parler de l’étape de collecte d’informations.
3.1
3.1.1
Etude des objectifs et analyse des besoins
Besoins d’affaires de l’entreprise
Nos besoins d’affaires se résument à mettre en œuvre un système de suivi et de contrôle
des planifications promotionnelles. Cette solution sera délivrée à la direction commerciale et
aux filiales afin de de pouvoir comparer les promotions de PGH et celles de ces concurrents.
2018/2019
26
Conception générale
Chapitre 3
Cela permettra aux décideurs de devenir plus autonomes et conséquemment d’être plus réactifs, et surtout de les permettre de tirer la décision à partir des analyses effectuées avec le
minimum d’incertitude.
Axes
Suivi administratif
Objectifs
Devenir plus réactif, assurer plus de coopération et de
coordination entre le département commerciale, Marketing et la direction générale.
Permettre une
communication.
Veille commerciale
meilleure
Détecter et anticiper des
nouveaux concurrents
Accompagner le département Marketing et commerciale dans la prise des décisions.
Piloter les activités du département commercial de
PGH
S’assurer de la crédibilité
des GMS.
Mieux connaitre ses partenaires et ses filiales.
Table 3.1 – Tableau récapitulatif des objectifs.
3.1.2
Besoins fonctionnels
Les besoins fonctionnels reflètent ce qui est spécifié dans le cahier de charges autrement
dit ce sont les besoins primaires exigés par le client qui sont généralement non-négociables.
Dans le cadre de notre projet, le client voulait obtenir une solution décisionnelle qui se base
sur un entrepôt assemblant les données relatives aux actions promotionnelles. Cela va servir
à la consolidation des tableaux de bord générant des rapports détaillés.
2018/2019
27
Conception générale
Chapitre 3
Pour ce faire nous visons à élaborer des rapports qui se répartissent sur 3 niveaux de granularité :
1.Premier niveau consolidé comportant des comparatifs entre les filiales de PGH
• Générer un Tableau de bord comportant un bilan de suivi des opérations de chaque
filiale dans chaque enseigne ;
• Donner la possibilité de filtrer selon l’année, le mois, le type de l’opération ainsi que
l’enseigne concernée.
2.Deuxiéme niveau de détail filiale
• Générer des rapports pour comparer les opérations de chaque filiale de PGH avec ses
concurrents ;
• Donner la possibilité de filtrer selon l’année, le type de l’opération ainsi que l’enseigne
concernée.
3.Troisiéme niveau de détails produits
• Générer des rapports d’évaluations des actions de chaque filiale selon le produit, la
famille et la gamme.
3.1.3
Besoins non fonctionnels
Les besoins non-fonctionnels sont liés principalement à des obstacles qui peuvent toucher
à la performance de la solution proposée et par la suite son rejet. Ces contraintes sont soient
externes soient internes. L’application alors doit satisfaire les critères suivants :
• Ergonomie et simplicité : L’application proposée doit être présentable tout en garantissant la simplicité, cela inclut le choix des couleurs et de la police ;
• Maintenabilité : Elle est caractérisée par une architecture n-tiers qui assure sa durabilité et sa maintenabilité ;
• Sécurité : La solution décisionnelle que nous avons proposée exige une authentification
de l’administrateur ou du décideur), pour pouvoir accéder.
2018/2019
28
Conception générale
3.2
Chapitre 3
Construction du tableau de bord
Durant cette phase il est primordiale de construire une vue global et générique sur ce
que le client voulait avoir, cette étape consiste à réaliser une maquette approximative qui va
guider l’équipe tout au long de la phase de restitution.
C’est une réalisation schématique des interfaces. Elle décrit leur comportement par rapport à
l’utilisation des acteurs du système. Dans ce cas la maquette était réalisée suite aux réunons
avec le département commercial. C’est une sorte de traduction graphique approximative des
besoins du client.
Figure 3.1 – Réalisation d’une maquette
2018/2019
29
Conception générale
Chapitre 3
• Maquette « Premier niveau consolidé : Comparatif entre filiales de PGH » ;
Figure 3.2 – « Premier niveau consolidé : comparatif entre filiales de PGH »
— Barre de Navigation :
Cette page comprend une barre de navigation contenant les filiales de PGH.
Chaque bouton nous amène vers un rapport détaillé sur la filiale en question ;
— Listes Déroulantes :
Nous trouvons des listes qui sont mises en haut de la page, à gauche. Elles représentent des ltres sur l’année, le Mois et le Type d’action. Ainsi qu’une autre liste
qui est mise en bas de la page, à droite. Elle comporte les enseignes.
— Composants graphiques :
Composant décoratif, mis en haut de la page et à droite et en bas ç gauche.
Représentant le logo de la Holding ou de ses filiales ;
— Composants interactifs :
Un histogramme en haut de la page, une matrice en bas de la page et un graphique
en secteurs en bas de la page.
2018/2019
30
Conception générale
Chapitre 3
• Maquette « Deuxième niveau de détails : Détails filiales » ;
Figure 3.3 – « Deuxième niveau de détails : Détails filiales »
— Barre de Navigation :
Cette page comprend une barre de navigation contenant un bouton "produits". Il
nous amène vers un rapport détaillé sur les produits, familles et gammes vendus
par la liale en question ;
— Listes Déroulantes :
Elles sont mises en haut de la page, à gauche. Les listes représentent des filtres
sur l’année, l’enseigne et le Type d’action ;
— Composants graphiques :
Composant décoratif, mis en haut de la page et à droite et à gauche. Ils représentent le logo de la Holding et celui de la filiale ;
— Composants interactifs :
Un histogramme en haut de la page, une matrice en bas de la page et un graphique
en secteurs en bas de la page.
NB : Même scénario-maquette se répète pour chaque filiale.
2018/2019
31
Conception générale
Chapitre 3
• Maquette « Troisième niveau de détails : détails produits ».
Figure 3.4 – « Troisième niveau de détails : détails produits »
— Barre de Navigation :
Cette page comprend 1 bouton de navigation. Il nous amène vers le rapport précèdent détaillé sur la liale en question. Le bouton est en bas, à gauche de la page ;
— Listes Déroulantes :
Elles sont mises en haut de la page, à gauche. Les listes représentent des filtres
sur l’année, l’enseigne et le Type d’action. ;
— Composants graphiques :
Composant décoratif, mis en haut de la page et à droite et à gauche. Ils représentent le logo de la Holding et celui de la filiale ;
— Composants interactifs :
Un graphique en anneaux est en bas de la page, Un graphique en secteurs est en
haut de la page et deux graphiques à barres empilées, en haut et en bas de la page.
2018/2019
32
Conception générale
3.3
Chapitre 3
Identification des Indicateurs et des axes d’analyses
L’objectif global de PGH, est de stimuler les ventes de certaines gammes de produits. La
Holding adapte alors la stratégie de vente promotionnelle. Cette dernière dépend essentiellement du niveau de stock des articles ainsi qu’elle est influencée par un marché fortement
concurrentiel. A cet égard, la surveillance des enseignes partenaires est indispensable. Conséquemment l’identification des indicateurs de performance ou des KPIs (voir tableau 3.2),
permettra de mesurer la performance et l’efficacité des opérations promotionnelles sur les
vente.
Indicateurs
Description
Total des actions
Nombre total des opérations
promotionnelles de chaque
filiale dans chaque enseigne.
Taux de participation de
chaque filiale
Le rapport entre le nombre
des actions promotionnelles
d’une filiale dans une enseigne et le nombre total des
opérations promotionnelles
proposées par l’enseigne.
Taux de participation de
chaque filiale par rapport à
ses concurrent
Le rapport entre le nombre
des actions promotionnelles
d’une filiale dans une enseigne et le nombre total des
opérations promotionnelles
de ses concurrents proposées par l’enseigne.
Top gamme en promotion
de PGH
Les gammes de produits
PGH les plus apparues en
promotion dans les catalogues et les points de vente.
Flop gamme en promotion
de PGH
Les gammes de produits
PGH les moins apparues
en promotion dans les catalogues et les points de vente.
Table 3.2 – Identification des KPIs
2018/2019
33
Conception générale
3.4
Chapitre 3
Collecte des informations
L’information dans un système décisionnel, est un lien de confiance entre la solution
proposée et le décideur. Pour cela il est indispensable d’accorder le temps à spécifier et
étudier tout d’abord l’architecture technique choisie ainsi que de bien choisir les données
issues des systèmes de production, pour avoir une information certaine plus tard. Par la suite
nous pouvons entamer la modélisation multidimensionnelle.
3.4.1
Architecture technique
Cette étape est une définition globale de la solution. Sa spécification doit être basée sur
l’environnement technologique adopté par l’entreprise. Nous allons, dans ce cadre définir un
plan architectural qui comporte 5 parties (voir figure 3.4)
Figure 3.5 – Architecture technique de la solution
3.4.1.1
Système source
i. Etude descriptive de données sources
A ce niveau nous allons étudier les données sources issues de l’application de suivi et de
contrôle des actions promotionnelles des GMS ayant les caractéristiques décrites dans le
tableau (3.4) :
2018/2019
34
Conception générale
Chapitre 3
Caractéristique
Source
Accssibilité
Données accessibles à partir de la base de données
de l’application de suivi des GMS.
Disponibilté
Données disponibles au sein de l’infrastructure de
l’entreprise.
Cout
Données couteuses en termes de temps et de stockage.
Simplicité
Complexité moyenne
Pérennité
M.A.J Chaque semaine.
Fiabilité
Données fiables même s’elles ne sont pas nettoyées
mais il s’agit d’une information juste.
Table 3.3 – Collecte d’informations.
Pour des raisons de confidentialité nous n’avons pas eu un accès direct au serveur, ces données
étaient livrées comme une image d’une base de données sous format back-up accompagnée
d’une documentation (voir annexe 7). La source comporte 13 tables, nous allons étudier les
11 tables desquelles nous avons tiré les données.
• Table action : Décrit la liste des actions ;
• Table actionFiliale : Décrit les différents statuts des actions dans les différentes Filiales ;
• Table item : Décrit la liste des articles en promotions du groupe PGH ;
• Table itemFamily : Décrit la fiche des articles de la Holding et de ses concurrents ;
• Table product : Décrit la liste des produits ;
• Table family : Décrit la liste des familles ;
• Table gamme : Décrit la liste des gammes ;
• Table filiale : Décrit la liste des filiales ;
• Table magasin : Décrit la liste des magasins ;
• Table concur : Décrit la liste des concurrents aux filiales PGH ;
• Table enseigne : Décrit la liste des enseignes qui sont issus de l’application.
2018/2019
35
Conception générale
Chapitre 3
ii. Conception de la base de données source
Dans cette partie nous allons nous intéresser à la modélisation physique de la base, au niveau
relationnel. La base illustrée dans la figure (3.5) représente 11 tables inter-reliées entre eux.
Figure 3.6 – Modélisation de la base de données sources
Pour simplifier la conception nous avons choisi de mettre en valeur les différentes hiérarchies
et relations existantes entre les tables en utilisant les couleurs.
• Produit, Famille et Gamme
Table Product représente tous les produits existants ; un produit peut inclure une ou
plusieurs familles et une ou plusieurs gammes.
2018/2019
36
Conception générale
Chapitre 3
• Enseigne et Magasin
Table Enseigne représente tous les enseigne existantes ; une enseigne peut avoir une ou
plusieurs magasins.
• Item et ItemFamily
Table ItemFamily représente tous les produits en promotion existants ; un item peut
appartenir à la table Item s’il est un Item de PGH.
3.4.1.2
Tiers Back-end
La zone de préparation ou Back-room, dans laquelle l’ETL aura lieu. Cela résulte des
données standardisées, nettoyées, cohérentes et chargées dans l’entrepôt.
• Extraction de données :
Cela consiste à les dégager à partir des systèmes sources. Cela est critique, vu que
tout le travail va se baser sur le choix des données. Dans ce cas nous disposons d’une
application POMOTIPS, de suivi de grandes et moyennes surfaces ;
• Transformation de données :
Au cours de cette étape la vérification de la cohérence des données se fait, tout comme
toute transformation requise, comme l’élimination des données erronées.
• Chargement de données :
Apres le traitement effectué sur les données, elles seront chargées dans un entrepôt. Dans
notre cas nous avons chargé ces dernières dans une base de données SQL Server.
Il est important de concevoir la manière dont l’ETL va être réaliser, nous citons l’approche :[6]
1.Push : Le push se repose sur le principe de pousse de données du système de production
vers le SA. L’inconvénient est que si le système est occupé, il ne poussera jamais les données.
2.Pull : Le Pull se base sur l’extraction des données de la source vers le Staging. Cette
méthode peut surcharger le système s’il est en cours d’utilisation.
3.Push-Pull : Le système source prépare les données et notifie le Staging que les données
sont prêtes à charger. Le SA les récupère. Au cas où la source est occupée, le Staging envoie
une autre demande.
2018/2019
37
Conception générale
Chapitre 3
Dans notre cas nous allons procéder avec la deuxième approche avec une planification d’un
job qui déclenchera le travail.
3.4.1.3
Tiers entrepôt de données
C’est la zone de stockage des données atomiques, résumées et agrégées. Selon Kimball cette
partie doit "fournir un environnement flexible, évolutif, intégré, granulaire, précis, complet
et cohérent". [7]
3.4.1.4
Tiers OLAP ou cube de base de données multidimensionnelle
Cela incarne la liaison entre le système ETL et la couche de présentation. Se constituant
d’une copie des données atomiques dites "pré-agrégées". Lors de l’envoi d’une requête, c’est
le serveur OLAP qui la prend en charge. Le résultat sera envoyé au cube OLAP.
3.4.1.5
Tiers Front-end
La Front-room illustre la solution analytique élaborée. En d’autres termes c’est la zone
de présentation qui sera livré au client sous forme d’interface abstraite facile à gérer.
3.4.2
Modélisation multidimensionnelle
L’un des principes de la BI c’est qu’elle nécessite deux éléments importants, ce sont
une architecture technique adéquate et une modélisation multidimensionnelle appropriée. La
raison pour laquelle ces deux composants doivent être élaborés c’est que l’utilisation directe
des sources de données pose des problèmes liés au fonctionnement et à la qualité du service
exigé, ainsi qu’au temps de réponse des requêtes, causé par des modèles normalisés qui ne
répondent pas au besoin évolutif. Dans ce cadre Ralph Kimball a travaillé sur la modélisation
avancée qui assure le pilotage d’une entreprise. Dans notre cas nous intéressons à l’approche
"Buttom-Up" de Mr. Ralph.
2018/2019
38
Conception générale
3.4.2.1
Chapitre 3
Modèles Schéma en étoile
Le schéma en étoile, est représenté par un ensemble de dimensions liées à une tables
de faits centrée. Chaque dimension reflète une table regroupant des attributs et est
référencée par une clé primaire. Ces dimension peuvent êtres de différentes granularités.
quant à la table de faits elle assemble les clés primaires des dimensions et les mesures
que nous souhaitons traiter. Le choix d’un "star schéma" est basé principalement sur
le besoins du client ainsi que sur les données collectées. Ce type de modèle assure une
flexibilité et simplicité lors de son exploitation. De même il permet de réduire le temps
d’exécution des requêtes.
3.4.2.2
Identifier la granularité
La granularité dans l’approche Kimball revient à spécifier ce qu’une ligne d’une table
de fait signifie. Elle reflète son niveau de détails. Il est conseillé de détailler son modèle le
plus possible pour éviter toutes complications ultérieures. Cette spécification se fait impérativement avant de déterminer les dimensions et les faits. Cette obligation critique assure
l’obtention d’un modèle simple, clair ainsi que l’acquisition des données atomiques qui assurent le maximum d’analyses avancées et des requêtes d’interrogation. Un modèle moins
granulaire sera vulnérable aux exigences inattendues de certains utilisateurs visant un haut
niveau de détails. Dans notre cas nous intéressons à étudier les produits en promotion vendu
dans les GMS.
3.4.2.3
Spécifier les dimensions
La granularité déterminée auparavant sera le point de départ pour déterminer les dimensions primaires et dégager par la suite plus de dimensions. Le niveau de détails des
dimensions doit être conforme à celui de la «Grain». Cette étape est assez importante que
l’étape précédente, vu que chaque dimension représentera un axe d’analyse. Par conséquence
nous obtenons ces 8 dimensions :
4 DimDate ;
4 DimProduit ;
2018/2019
39
Conception générale
Chapitre 3
4 DimAction ;
4 DimEnseigne ;
4 DimFiliale ;
4 DimConcurrent ;
4 DimInsertion ;
4 DimMecanisme.
3.4.2.4
Spécifier la table des faits
Une table de faits représente toutes les informations liées à un processus métier bien
déterminé. Cette table exprime des évènements ou des transactions bornés dans le temps et
l’espace. Dans notre projet nous disposons d’un fait transactionnel qui ne comprend que les
clés étrangères des dimensions.Il s’agit de «Factless Fact table».
L’insertion d’une ligne se fait seulement si une transaction a eu lieu. Elle est illustrée par une
table promotion :
4 FactPromotion
3.4.2.5
Modéle à bulles de haut niveau
Dans son approche « Buttom-Up », Kimball a bien spécifié une séquence de tâches liées
à la modélisation multidimensionnelle. Sa démarche nous permet d’obtenir un modèle solide
qui répond aux besoins inattendus des décideurs.
Dans ce sens nous avons choisi d’élaborer un modèle initial (voir figure 3.6). C’est le modèle
Bubble Chart de Kimball.
Ce modèle est dédié principalement à une audience sans des connaissances techniques requises. Il met en valeur le processus métier ainsi que la granularité choisie.
2018/2019
40
Conception générale
Chapitre 3
Figure 3.7 – Conception de haut-niveau du modèle en étoile (High-Level Bubble Chart)
3.4.2.6
Conception physique détaillée du modèle
Cette section sera dédiée selon Kimball à la spécification ou conception physique du
modèle adopté (voir figure 3.7). Cela se fait par la documentation du modèle tout en spécifiant
les noms des tables qui doivent être significatifs, les attributs de chaque table, les contraintes
liées à ces dernières ainsi que les clés étrangères et primaires.
2018/2019
41
Conception générale
Chapitre 3
Figure 3.8 – Conception finale du modèle en étoile
Nous déterminons ci-dessous les noms et libellés des tables que nous disposons :
• Dim_Enseigne : Dimension Enseigne (voir tableau 3.4) ;
Attributs
Description
id(PK)
clé artificielle de l’enseigne
(auto_increment)
id_enseigne(NK)
Clé primaire et unique de
l’enseigne
name_enseigne
nom de l’enseigne
Table 3.4 – Dimension Enseigne.
2018/2019
42
Conception générale
Chapitre 3
• Dim_Action : Dimension Action (voir tableau 3.5) ;
Attributs
Description
id(PK)
clé artificielle de l’action
(auto_increment)
id_action(NK)
Clé primaire et unique de
l’action
name_action
nom de l’action
statut
statut de l’action (active,
annulée, inactive)
type
type de l’action (communiquée, non communiquée)
Table 3.5 – Dimension Action.
• Dim_concurrent : Dimension Concurrent(voir tableau 3.6) ;
Attributs
Description
id(PK)
clé
artificielle
(auto_increment)
name_concurrent
nom du concurrent
Table 3.6 – Dimension Conurrent
• Dim_Filiale : Dimension Filiale (voir tableau 3.7) ;
Attributs
Description
id(PK)
clé artificielle de la filiale
(auto_increment)
id_fil(NK)
Clé primaire et unique de la
filiale
name_filia
nom de la filiale
Table 3.7 – Dimension Filiale
2018/2019
43
Conception générale
Chapitre 3
• Dim_insertion : Dimension Insertion (voir tableau 3.9) ;
Attributs
Description
id(PK)
clé artificielle de l’insertion
(auto_increment)
type_insertion
largeur , grandeur dans le
catalogue
Table 3.8 – Dimension Insertion
• Dim_item : Dimension Produit(voir tableau 3.10) ;
Attributs
Description
id(PK)
clé artificielle de l’article
(auto_increment)
id_item(NK)
Clé primaire et unique de
l’article
item_nameFamily
nameFamily de l’article
name_gamme
nom de la gamme de l’article
name_famille
nom de la famille de l’article
name_product
nom de l’article
Table 3.9 – Dimension Item
• Dim_Mecanisme : Dimension Mécanisme (voir tableau 3.10) ;
Attributs
Description
id(PK)
clé artificielle du mécanisme
(auto_increment)
Mecanisme_Type
Mécanisme de l’opération
promotionnelle.
Table 3.10 – Dimension Mécanisme
2018/2019
44
Conception générale
Chapitre 3
• Dim_Date : Dimension Date(voir tableau 3.11) ;
Cette dimension joue le rôle d’un calendrier.
Attributs
Description
Pk_Date(PK)
clé artificielle
Date
Date compléte
NumJourSemaine
numéro du jour dans la semaine
JourSemaine
jour de la semaine
JourSemaine_Libelle
Libellé du jour de la semaine
NumJourMois
numéro du jour du mois
NumJourAnnee
Numero du jour de l’année
NumSemaineMois
Numéro de la semaine du
mois
NumSemaineAnnee
Numéro de la semaine de
l’année
NumMoisAnnee
Numéro du mois de l’année
Mois
le mois
Mois_Libelle
Libellé du mois
Trimestre
Trimestre
Trimestr_Libelle
Libellé de la trimestre
Semestre
Semestre
Semestre_Libelle
Libellé du semestre
Annee
L’année
IsWeekend
Weekend ou pas weekend
Weekend
weekend
Table 3.11 – Dimension Date
NB : Il est important de noter que la dimension Date est de type « Role Playing
Dimension » tirée de l’approche Kimball. Ce type dimension est utilisé si entre la table
de fait et une dimension nous distinguons plus qu’une relation valide.
2018/2019
45
Conception générale
Chapitre 3
Dans ce cas la dimension Date fait référence à deux informations à la fois ; Date début
et date fin. L’implémentation physique de cette dimension sera à l’aide de la clé primaire de « DimDate » qui sera appelé à deux reprises au niveau de chaque ligne de la
table de fait (Date_start_FK et Date_end_FK).
• Fact_Promotion :Table des faits Promotion (voir tableau 3.12).
Attributs
Description
ActionKye(FK)
Clé étrangère de la table Action
FilialeKye(FK)
Clé étrangère de la table Filiale
Date_start_Kye(FK)
Clé étrangère de la table
Date
Date_end_Kye(FK)
Clé étrangère de la table
Date
ItemKye(FK)
Clé étrangère de la table
Item
ConcurrentKye(FK)
Clé étrangère de la table
concurrent
MecanismeKye(FK)
Clé étrangère de la table
Mécanisme
InsertionKye(FK)
Clé étrangère de la table Insertion
EnseigneKye(FK)
Clé étrangère de la table
Enseigne
Table 3.12 – Table de faits
3.5
Systéme tableau de bord
Le tableau de bord est une sorte d’instrument regroupant des indicateurs construits à
partir d’une base massive de données complexes et non-standardisées. A cet égard le choix
des KPIs determine sa qualité.
2018/2019
46
Conception générale
Chapitre 3
Le TB guide les managers et leur façon de piloter une organisation. Il symbolise la clé d’un
mangement de performance. Sa conception le définit et détermine s’il servira comme outils
pertinent de prise de decision.
Dans notre projet nous allons construire un TB GIMSI met en valeur l’importance du partage
et de la communication au sein de l’entreprise. Ce tableau de bord reflète la situation de la
Holding dans le marché promotionnel, dont la typologie est déterminée comme stratégique
Nous parlons dorénavant de la collaboration et de l’élimination de l’isolement du décideur.
Qui résulte la prise de décision collective et décentralisée.
Le TB va être communiqué plus tard aux dirigeants plus précisément à la direction du
département commerciale ainsi qu’à chaque direction des filiales de PGH. La gestion d’accès
aurait lieu selon le type d’acteur du système. Conséquemment chacun pourait suivre sa
performance en vue de l’améliorer.
Cet instrument doit décrire le positionnement de PGH vis à vis à un marché concurrentiel,
tout en s’assurent qu’il soit interactif, accessible à distance et alloué à plusieurs utilisateurs.
Synthèse
Cette section était ciblée à un aperçu sur les besoins exigés par le client. Cette spécification
et conception de la solution va simplifier le travail ultérieur de la modélisation. Nous allons
dans le chapitre suivant étudier la phase de la construction du système tableau de bord en
adaptant cette étape avec le cycle de vie de Kimball. Cette adaptation va décortiquer le
travail et le rendre plus simple et clair.
2018/2019
47
Mise en œuvre et amélioration permanente
Chapitre 4
Chapitre 4
Mise en œuvre et amélioration
permanente de la solution
Introduction
Ce chapitre est consacré à la dernière phase de GIMSI, l’audit et la mise en œuvre qui
englobe le choix technologique ainsi que le déploiement de la solution dans l’entreprise. Précédemment, nous avons choisi de faire une fusion entre GIMSI et Kimball vu qu’ils se complètent
de point de vue théorique et technique, afin d’élaborer une conception générale claire. Désormais il est temps d’enchainer la construction du tableau de bord. Pour se faire nous avons
choisi de détailler cette phase critique cela va nous permettre de tracer un chemin qui va
nous conduire vers notre objectif.
4.1
4.1.1
Mise en œuvre
Choix des progiciels
Indubitablement cette étape est critique. Ce qu’il faut assurer c’est l’objectivité du choix
technologique qui doit mener à l’atteinte de l’objectif final du projet. Ceci est assuré par
l’étude du marché pour parvenir à une sélection adéquate de produits. GIMSI recommande
que cette étape se réalise après a conception générale de la solution.
2018/2019
48
Mise en œuvre et amélioration permanente
Chapitre 4
Néanmoins dans notre cas nous devons prendre en compte le protocole de pilotage de la
Holding, et vu que l’entreprise a adapté, ces dernières années, les produits Microsoft notre
rôles sera l’étude des outils BI disponibles sur le marché pour comprendre les préférences
de PGH, tout en précisant qu’elles se basent sur les contraintes financières ainsi que sur les
besoins techniques qui se résument en 4 étapes :
• La phase de la conception ;
• La réalisation d’ETL ;
• L’élaboration de Data Warehouse ;
• Construction d’un cube OLAP ;
• La concrétisation du Reporting en dégageant des KPIs.
4.1.1.1
Etude comparative des outils BI
• Microsoft Business Intelligence
Durant ces dernières années Microsoft a manifesté un intérêt visible au domaine décisionnel, l’entreprise cible une part importante du marché, et avec les solutions qu’elle
offre nous pouvons dire qu’elle est sur la bonne trajectoire. La plate-forme Microsoft
s’accompagne de divers outils qui permettent d’effectuer tout le processus décisionnel
avec une haute performance. Nous citons :
- SQL Server Reporting Services (SSRS) ;
- SQL Server Analysis Services (SSAS) ;
- SQL Server Intégration services (SSIS) ;
- Microsoft Power BI.
• Oracle Business Intelligence
Une plate-forme fournisse par Oracle, et un concurrent direct aux produits Microsoft.
Avec sa fonctionnalité et sa capacité d’effectuer des analyses avancées et des rapports
détaillés il répond aux besoins décisionnels. Permettant de stocker les données, de réaliser l’ETL ainsi que de publier des tableaux de bords. Par conséquence cette technologie
se classe parmi les outils les plus utilisés par l’intégrateurs.
2018/2019
49
Mise en œuvre et amélioration permanente
Chapitre 4
• Pentaho Business Intelligence
Pentaho de l’autre côté offre une gamme décisionnelle complète regroupant plusieurs
projets open-source.
Le tableau (4.1) illustré ci-dessous représente une comparaison entre les trois technologies :
Fonctionnalité
Microsoft
Oracle
Pentaho
Alimentation
Tous sources de données
Tous sources de données
Tous BDs à travers le
driver JDBC
Stockage
Cube OLAP, Data
Warehouse, DataMart
Cube OLAP, Data
Warehouse, DataMart
SGBD avec l’option
OLAP
Analyse
Analyse multidimensionnelle, statistiques
Analyse multidimensionnelle, statistique
Connexion
à
des
BDs relationnelles,
Requêtes
MDX
possibles
Reporting
TB personnalisé et interactif, Interface graphique simple
TB personnalisé et interactif, Interface graphique simple
TB personnalisé et interactif, Interface graphique simple
Table 4.1 – Top 3 des technologies BI
4.1.1.2
Environnement logiciel choisi
• Conception
La conception dans n’importe quel projet est indispensable vu qu’elle représente le pont
de passage du besoin décrit à la concrétisation de la solution. Ce pont-là sera sous forme
de diagrammes. Pour cela nous allons utiliser le langage UML qui sert à découper le
processus avant sa réalisation. A cet égard nous avons choisi GLIFFY ; un logiciel de
diagrammes web, vu sa simplicité et facilité d’utilisation.
• Outils de développement
Avec la diversité des technologies il est important de focaliser sur notre besoin tout en
prenant en compte le budget alloué à ce projet par l’entreprise. En étudiant ces deux
axes avec les responsables de PGH nous avons opté vers les produits BI Microsoft. Ce
choix évidemment est conforme à la politique de la Holding.
2018/2019
50
Mise en œuvre et amélioration permanente
Chapitre 4
Notre recherche nous a révélé que les solutions Microsoft assurent :
- L’ergonomie ;
- La facilité de l’usage ;
- La sécurité des données ;
- La capacité de deploiement ;
- La sécurité.
4.1.1.3
Environnement matériel choisi
Ce travail était élaboré sur deux machines ayant les caractéristiques représentées dans le
tableau (4.2) suivant :
Processeur
Intel Core I5-5200U
Intel Core I9
Mémoire vive
8GB
16GB
1TB 520GB
1TB 520GB
Windows 10 professionnel
(x64)
Windows 10 professionnel
(x64)
Disque dur
Système d’exploitation
Table 4.2 – Environnement matériel.
4.1.2
Intégration et déploiement
Tout en considérant les spécificités de la solution proposée, le système tableau de bord
doit être pris en compte dans l’entreprise. A delà de l’évaluation des besoins satisfaits il est
important d’aborder le cout de l’intégration et du déploiement. Cette étape est relative aussi
aux contraintes d’adaptation technique et de temps. Egalement il faut prendre en compte
l’infrastructure de l’entreprise.
4.1.2.1
Alimentation du DataMart
Après avoir conçu notre modèle multidimensionnel, nous procédons le chargement des
données dans notre DM.
2018/2019
51
Mise en œuvre et amélioration permanente
Chapitre 4
i. Conception de l’alimentation du Data Mart
Notre DataMart présente une structure dimensionnelle de stockage qui fait intervenir 3 nœuds
représentés par un diagramme de déploiement (voir figure 4.1).
— Serveur SA : Staging Area zone présentant une copie de la base relationnelle.
— Serveur SSIS : Ou s’exécute le processus d’extraction, de transformation et de chargement.
— Serveur DataMart : Magasin de données.
Figure 4.1 – Diagramme de déploiement de la phase d’alimentation des données
NB : La liaison entre ces éléments se fait par l’intermédiaire d’une API assurant une
connexion OLEDB « Object Linking and Embedding Database ». En vue de mieux comprendre le processus d’alimentation nous avons établi 3 cas d’utilisation présentés par les
figures (4.2) (4.3) (4.4).
2018/2019
52
Mise en œuvre et amélioration permanente
Chapitre 4
• Cas d’utilisation global à l’alimentation des données
Figure 4.2 – Diagramme d’activité d’alimentation des données
NB : La planification d’ETL (JOB) est primordiale dans un projet BI. Elle permet de
déterminer le moment et la fréquence d’exécution de ce processus (voir annexe 5). Il est
recommandé que ce dernier soit planifié or les heures l’activité habituelles. L’exécution
dépend alors, du volume de données disponibles (voir figure 4.2).
• Cas d’utilisation spécifique à l’alimentation des dimensions
La première phase consiste à extraire les données qui sont stockées dans la base de données relationnelle notre Back-Up « Promotips ». L’extraction se fait par l’intermédiaire
des clés métier qui éliminent les dédoublements. Par la suite l’ajout des clés artificielles
«surrogate key», permettent de mapper les données sources avec celles chargées dans le
DataMart. La phase final consiste à utiliser la technique SCD ; Dimension à variation
lente. Cela assure la MAJ des dimensions (voir figure 4.3).
2018/2019
53
Mise en œuvre et amélioration permanente
Chapitre 4
Figure 4.3 – Diagramme d’activité d’alimentation des dimensions
NB : « Slowly Changing Dimesion » ou SCD est un élément utilisé pour l’insertion
ou la mise à jour des dimension. Le mecanisme adapté par le SCD est la comparaison
des données de la source avec celles déjà insérées dans les dimensions. Cela se fait par
l’intermédiaire d’une clé professionnelle (Business Kye). Cette technique se repose sur
8 méthodes, parmi lesquels nous citons type 1, type 2 et type 3 :
1. MAJ des dimensions sans historisation ;
2. Insertion des nouvelles lignes avec historisation ;
3. Conservation de plusieurs instance de la même colonne.
2018/2019
54
Mise en œuvre et amélioration permanente
Chapitre 4
• Cas d’utilisation spécifique à l’alimentation de la table des faits
Figure 4.4 – Diagramme d’activité d’alimentation de la table des faits
NB : Son rôle c’est d’homogénéiser les données sources, et de faire une vérification primaire
de leur qualité et de leur formats. En d’autre terme le SA est une « zone d’attente » [6].
Egalement elle permet de minimiser le temps de réponse des requête ainsi que de faire diminuer la charge du flux de données sur le serveur.
ii. Implémentation physique de l’entrepôt de données
Avant d’alimenter le DataMart il faut que nous créions une base conforme au modèle
spécifié. A cet égard nous avons implémenté le modèle multidimensionnel (voir annexe 3)
avec Microsoft SQL Server Developer qui jouera le rôle du DM, assurant l’interrogation facile des données. Pour cela nous avons créé une nouvelle instance de SQL Server
nommé FORM3/FORMATION(voir figure 4.5). Cette instance assure la confidentialité
des données que nous disposons, avec une connexion sécurisée.
2018/2019
55
Mise en œuvre et amélioration permanente
Chapitre 4
Figure 4.5 – Authentification SQL Server
iii. Implémentation et exécution du processus ETL
Le système ETL comprend 34 services. Ces services ou ces « Subsystems », comme l’indique
Mr. Kimball, assurent la phase d’ETL avec cohérence et exhaustivité résultant des données
traitées prêtes aux analyses avancées. Cette phase critique est un défi réel dans les projets
décisionnels vu les enjeux des systèmes sources, des outils, etc. Elle présente 70 pour cent du
travail effectué.
Le produit que nous avons choisi pour l’implémentation du projet est une solution Microsoft.
Cette dernière nous a permis de créer un projet d’intégration SSIS qui suit une hiérarchie bien
spécifique. Il se compose d’un ou plusieurs Packages (voir figure 4.6). Chaque Package pourrait inclure une ou plusieurs tâches (Tasks) ;chacune comportera d’autres éléments Comme
l’illustre la figure (4.7) (voir annexe 3).
Figure 4.6 – Hiérarchie d’un projet SSIS
2018/2019
56
Mise en œuvre et amélioration permanente
Chapitre 4
Nous allons tout de suite décortiquer toutes les étapes de l’implémentation.
• Extraction des données
Dans un premier les données doivent etres extraites à partir de la base « Promotips »
pour les charger dans notre DM nommé « promo ». Ces données seront, par la suite
traitées est chargées dans l’entrepôt.
Dans cette partie il est important de comprendre que notre solution sera déployée dans
l’entreprise. Sa mise en place nécessite qu’elle soit liée à un serveur de données permettant la mise à jour et le chargement régulier des données
Nous avons alors choisi d’ajouter une rubrique permettant la MAJ des données. Cette
rubrique est nommée Staging area (SA)(voir annexe 3). Elle représente une base intermédiaire entre les sources et le système ETL. Dans ce cas toutes les données seront
chargées dans le SA, le DataMart ne sera alimenté que par les tables dites STG (mis
à jour).
Pour se faire il existe 4 méthodes ; Soit de charger les données selon la dernière date
d’extraction ou le dernier identifiant stocké. Nous pouvons utiliser également la technique SCD ou de supprimer le contenu de la table avec la commande « Truncate » et
de la recharger.
— Dernier date d’extraction :
1. Créer une Table au niveau du Back-Up actualisée, sur lequel notre ETL est
pointé, dans lequel nous stockons la date du dernier chargement des données ;
2. Créer des Variables avec SSIS en spécifiant un script SQL assurant l’extraction
de la valeur de la date stockée au niveau du Back-Up.
2018/2019
57
Mise en œuvre et amélioration permanente
Chapitre 4
3. Mettre à jour les données issues du serveur vers le Back-Up, si la date du
système est supérieure à la date sauvegardée dans le back-up.
— Dernier identifiant sauvegardé :
1. Créer des Variables avec SSIS en spécifiant un script SQL assurant l’extraction
de l’identifiant du dernier élément chargé dans le Back-Up ;
2. Mettre à jour les données des tables, issues du serveur vers le Back-Up, ayant
l’identifiant supérieur à celui stocké dans la variable ;
— Technique SCD :
1. MAJ des données en utilisant la technique "Slowly Changing Dimension" de
type 1 sur les tables qui sont de tailles réduites ;
— Recharger les tables :
4. Cela se fait par un script SQL qui utilise la commande "Truncate".Nous supprimmons toutes les données pour les recharger de nouveau. Cette méthode est
utilisée pour les tables qui ne disposent ni de date ni d’identifiant.
NB : Dans notre cas nous avons adapté les 3 dernières méthodes ; Technique SCD pour
les tables « filiale » , « family », « product » et « gamme », Dernier Identifiant pour les
tables « itemFamily », « Item » et « Action » La recharge des données pour la table
« ActionFiliale » (voir annexe 3). Dans un second temps, nous allons nous intéresser
à l’extraction des données du Staging Area, qui vont alimenter les dimensions. Nous
devons alors préciser les tables sources qui vont être utilisées (voir tableau 4.3 et 4.4).
Dimension
Item_Dim
Table Source Utilisée
Information extraite
mk_item
Le code unique de l’article
et son nom.
mk_itemFamily
Le code unique de l’article
et son nom.
mk_gamme
La gamme de l’article.
mk_family
La famille de l’article.
mk_product
Le nom du produit de l’article.
Table 4.3 – Détails de la phase d’extraction.
2018/2019
58
Mise en œuvre et amélioration permanente
Chapitre 4
Dimension
Table Source Utilisée
Information extraite
Insertion_dim
mk_item
Le type de l’insertion de
l’action.
Mec_dim
mk_item
Le mécanisme de l’action.
Enseigne_Dim
mk_enseigne
Le nom et id de l’enseigne.
Filiale_Dim
mk_filiale
Le nom et id de la filiale.
mk_concur
L code et le nom du concurrent.
mk_filiale
Le code et le nom de la
filiale cette table va servir
plus tard pour des raisons
de visualisation.
mk_itemFamily
Le code et le nom du
concurrent
non-existant
dans la table mk_concur.
DateDim
Un script SQL
—–
Act_dim_Dim
Action
L’id, le nom, le statut et le
type de l’action
Concur_Dim
Table 4.4 – Details de la phase d’extraction.
• Transformation des données
La transformation des données est primordiale en vue d’obtenir des rapports et des
analyses significatifs. Pour bien expliquer cette étape nous avons choisi de démontrer
deux exemples de dimensions qui ont nécessité des transformations, ce sont la dimension « Item » et la dimension « Concurrent » .
- Dimension Item :
Cette dimension illustre la hiérarchie des articles en promotion (Produit, Famille,
Gamme).En revanche il y avait des données manquantes ou marquées comme NULL.
Cela engendrera des problèmes au niveau de l’alimentation de la table de faits ainsi
qu’au niveau du cube. Pour résoudre ce souci, nous avons remplacé les données erronées par l’expression « nondisponible » et nous l’avons associé avec une valeur fictive
ajoutée à la dimension (voir annexe 3).
2018/2019
59
Mise en œuvre et amélioration permanente
Chapitre 4
- Dimension Concurrents :
Egalement la dimension concurrent nécessite quelques transformations vu que l’extraction se fait de plusieurs tables. Nous rencontrons un problème de données manquantes
ainsi qu’un problème de caractères spéciaux engendrant une incohérence. Nous avons
choisi pour se cas de remplacer les valeurs manquantes par l’expression « nondisponible », et d’utiliser les colonnes dérivées pour nettoyer les données à l’aide de fonction
"TRIM" et "UPPER", etc.
• Chargement des données
Une fois l’extraction et les transformations requises sont terminées avec succès nous
pouvons finalement charger les données atomiques dans l’entrepôt de données (voir
annexe 3). A cet égard nous utilisons une destination « OLE DB » dans SSIS.
- Chargement des données de la dimension « Item »
- Chargement des données de la dimension « Concurrent »
- Chargement des données de la table des faits
4.1.2.2
Cube OLAP
Apres l’exécution du processus ETL et l’alimentation du DM, nous avons choisi de passer
par un Cube OLAP avant la phase de restitution. Pour obtenir la représentation cubique il
faut valider les étapes suivantes (voir annexe 4) :
-Une source de données pointée sur le DM crée.
-Une vue basée sur la source de données déterminant les tables intervenant dans le cube (une
couche logique).
-Les dimensions et les mesures présentes dans le cube.
2018/2019
60
Mise en œuvre et amélioration permanente
Chapitre 4
Nous obtenons ce schéma illustré dans la figure (4.7) :
Figure 4.7 – Chargement de table des faits avec SSIS
Dans un second temps nous avons choisi d’exploiter le langage MDX pour creer des indicateurs complexes, parmi lesquels :
- Pourcentage de participation de chaque filiale dans chaque enseigne par rapport aux autres
filiales (voir annexe 4).
Porcentage = ( Nombre d’action de la filiale 1 dans l’enseigne x/ Total d’actions de PGH
dans l’enseigne x)*100.
- Pourcentage de participation de chaque filiale dans chaque enseigne par rapport aux concurrents.
Porcentage2 = (Nombre d’action de la filiale 1 dans l’enseigne x/ Total d’actions concurrente
à la filiale dans l’enseigne x)*100.
2018/2019
61
Mise en œuvre et amélioration permanente
4.1.2.3
Chapitre 4
Alimentation du tableau de bord
Dans notre projet nous nous sommes appuyés sur Microsoft Power BI. Ce produit permet
de consolider des TB reflétant la performance d’un département ou secteur précis.
i. Conception de la phase de restitution des données
Figure 4.8 – Diagramme de déploiement de la phase de restitution des données
Dans le même cadre, Power BI nous a permis de construire un tableau de bord comprenant
des rapports périodiques avec la possibilité de les paramétrer. Cela était vérifier via l’architecture illustrée par la figure (4.8), qui met en évidence l’utilisation d’un serveur Power BI
permettant de se connecter sur le serveur SSAS du cube OLAP, lui-même se connecte à un
serveur SSIS.
ii. Restitution des données
Le tableau de bord conçu et réalisé pour des finalités de pilotage stratégique, visualise des
indicateurs de performance de haut niveau. Il offre une vision globale sur les activités promotionnelles, et sera livré au comité de direction afin d’améliorer le processus de prise de
décision avec minimisation des risques.
Le TB est construit de 3 niveaux (voir annexe 6) comme il était énoncé dans la partie des
besoins fonctionnels. Sa décomposition se repose sur 14 rapports liés à 7 différentes filiales
de PGH. En vue de dégager le maximum d’analyses et d’informations nous avons choisi de
consolider 2 rapports (deux niveaux de détails : niveau2 + niveau3) pour chaque filiale.
2018/2019
62
Mise en œuvre et amélioration permanente
Chapitre 4
- Le premier niveau :
Refletant la performance de la Holding, en illustrant le taux de participation de ses filiales.
Figure 4.9 – Restitution de données : niveau 1
Ce niveau présente une vue générale (voir figure 4.9) en fournissant le nombre total d’actions,
des concurrents, des enseignes et des filiales concernés par cette étude. Cette rubrique est
positionnée à droite (5).
Du côté cohérence et interactivité avec les rapports ce tableau de bord dispose de 7 boutons
positionnés à gauche (1). Ces derniers permettent la navigation entre les rapports de chaque
filiale (2éme niveau).
Les éléments clé de cette section ce sont l’histogramme et le graphique en anneau positionnés
au centre (3)(4). Ces composants exposent d’une part la répartition de la totalité des ventes
promotionnelles et l’écart entre les sociétés affiliées. Et d’autre part il comporte un bilan de
suivi des opérations promotionnelles du Groupe par enseigne (6).
2018/2019
63
Mise en œuvre et amélioration permanente
Chapitre 4
- Le deuxième niveau :
Inclut plus de détails et de données atomiques concernant chaque filiale à part ; en visualisant
sa part promotionnelle par rapport à ses concurrents ; Nous prenons l’exemple de GIPA, (figure 4.10).
Figure 4.10 – Restitution de données : niveau 2
Ce niveau est interactif avec la disposition de 7 boutons positionnés à gauche pareillement
au premier niveau. Ces derniers permettent la navigation entre les rapports des differentes
filiale.
D’abord nous trouvons un graphique en en anneau (3), représentant la répartition des opérations communiquées et non-communiquées de la filiale par enseigne. Ensuite nous distinguons
l’intégration de l’axe temporel, qui met en valeur l’évolution des promotions de GIPA par
mois selon l’enseigne avec un graphique linéaire (1). Tout en la comparant avec ses concurrents en visualisant un histogramme en cluster (2) la même information, plus détaillée est
disponible en pourcentage dans la matrice (4).
2018/2019
64
Mise en œuvre et amélioration permanente
Chapitre 4
- Le troisième niveau :
Ce niveau consiste à tirer des informations détaillées sur les articles en promotions (voir figure
4.11).
Pour cela nous avons choisi camembert pour montrer les pourcentages des opérations selon
le produit (1), avec l’évolution des actions des familles des articles par un graphique linéaire
(3) et un histogramme en cluster pour représenter les tops et flops gammes en promotion
(2).
Ce niveau étudie les résultats de GIPA ainsi que de ses concurrents.
Figure 4.11 – Restitution de données : niveau 3
4.1.2.4
Validation et test
En vue de valider les résultats obtenues, nous avons testé chaque élément à part durant
tout le projet. Cela était suit par un test d’intégrité global de la solution dans le but de vérifier
son fonctionnement et sa cohérence sur deux axes différents ; la conformité des rapports
restitués avec les données sources que nous disposons, ainsi que la stabilité du tableau de
bord et de sa performance. Suite aux tests, notre projet était validé par notre encadrent ainsi
que par le département commercial dans le but de l’intégrer.
2018/2019
65
Mise en œuvre et amélioration permanente
4.1.2.5
Chapitre 4
Integration
L’intégration de la solution dans l’entreprise, s’est fait suivant les etapes citées ci-dessous :
• Hébergement du DataMart dans un serveur ;
• Connexion du DataMart au serveur ;
• allocation d’accès aux utilisateurs ;
• Publication du cube OLAP ;
• Publication du tableau de bord.
Dans le cas de notre projet nous avons réalisé cette phase sur un deuxième poste de travail
ayant les droits d’accès au serveur, vu que pour de raison de haute confidentialité nous ne
pouvons pas accéder au serveur sans avoir une matricule (les employés de PGH peuvent
accéder en inserant leur numéro de carte d’identité).
Durant cette phase l’allocation des droits d’accès est primordiale. Le lancement du tableau
de bord sera sur un navigateur Web. L’administrateur permet chaque directeur de consulter
uniquement sa section.
4.1.3
Amélioration permanente
Les systèmes décisionnels sont fondés sur la notion de l’amélioration permanente. Afin
de garantir la performance et la durabilité de la solution réalisée au cours du temps, il faut
s’assurer que les besoins du client sont toujours satisfaits, tout avec l’évolution de l’entreprise
et le changement continu des besoins et stratégies.
A cet égard un audit du système de mesure de la performance et de control régulier doit être
réalisé. L’audit est un outil qui accompagne le pilotage des projets décisionnels.
C’est une manière d’analyse et de détection des problèmes. Elle évalue l’état actuel ainsi
que les prospectives de la solution mise en place. Cette étape se fait par le responsable du
processus métier dit "pilote de processus".
2018/2019
66
Mise en œuvre et amélioration permanente
Chapitre 4
Conclusion
Dans cette partie nous sommes passé de la conception du modèle et de sa alimentation, à
l’implémentation physique qui a donné naissance à un tableau de bord dynamique regroupant
des KPIs de haut niveau. Cette section était accompagnée par des captures d’écran exposant
le côté technique et fonctionnel de la solution élaborée.
2018/2019
67
Conclusion générale
Dans le secteur des ventes promotionnelles et avec un marché fortement concurrentiel le
processus de prise de décision est de plus en plus critique. A cet égard les entreprises exerçant ce métier, doivent mettre en place une stratégie qui valorise l’exploitation des données.
Pour se faire un système d’informations décisionnel doit être mis en place. Ce dernier sert
à l’extraction de la connaissance et au traitement des données dans le but d’en dégager des
indicateurs minimisant l’incertitude du décideur.
Ce travail s’inscrit dans le cadre de projet de fin d’études, consiste à mettre en œuvre une
solution décisionnelle de suivi des actions promotionnelles dans les GMS au sein de Poulina
Group Holding.
Durant la période su stage, nous avons appliqué les connaissances que nous avons acquises
tout le long de notre cursus universitaire. Nous avons eu la chance également d’enrichir nos
compétences techniques au sein de l’équipe BI de la Holding. Dans un premier temps nous
avons entamé ce rapport par une étude du contexte général du sujet, ce qui nous a permis
de révéler les problèmes de suivi du département commercial. Ensuite, nous avons abordé la
phase de conception générale qui englobe les besoins, les indicateurs à dégager, l’étude de la
maquette et la construction du tableau de bord et finalement la phase de collecte de données
qui inclut l’architecture physique ainsi que le modèle multidimensionnel choisi. Une fois la
conception globale est terminée, nous avons étudié les différentes technologies disponibles sur
le marché en vue de justifier notre choix pour les produits MSBI. Enfin, nous avons illustré
la phase de restitution à travers des captures d’écran et des commentaires explicatifs.
Pour conclure, ce stage nous a été bénéfique, mise à part des compétences techniques acquis,
nous avons aussi approfondir nos connaissances concernant la vie professionnelle et l’inté68
gration au sein d’une équipe de travail. Ce stage nous a pareillement, offert l’opportunité
de collaborer avec PGH, et de conquérir une expérience professionnelle. Finalement, Nous
avons réussi à répondre à tous les besoins du client et conformément à des règles des nouvelles
technologies.
En guise de perspectives, notre solution a l’avantage d’être ouverte et extensible, dans ce
contexte que nous envisageons d’étendre notre projet en ajoutant des nouveaux axes à traiter
suivant le besoin du client. Notre réalisation peut, être enrichie par d’autres modules à savoir
un module de prévention à notre application décisionnelle afin de prévoir les produits les plus
rentables en promotions. De même, nous proposons d’enrichir cette solution, par l’ajout du
volet comptable au tableau de bord, cette proposition va rendre notre solution plus impliquée
dans le processus des ventes promotionnelles en assurant non seulement le suivi des opérations
mais aussi le control budgétaire, la rentabilité des actions promotionnelle, etc. Ceci peut être
réalisé par l’extension de notre modèle en étoile pour devenir un modèle en constellations ou
hybride ou même en créant un deuxième DataMart.
69
Annexes
70
Annexe 1 : Méthodologie GIMSI
La méthodologie GIMSI assure l’obtention d’une conception correcte de la solution décisionnelle. Elle comporte 4 grandes étapes qui eux même se répartissent en sous-étapes,
chacune se caractérise par un seuil d’avancement identifiable.
Etape 1 : Identifier le contexte de travail
• Strategie de l’organisation :
Identification de l’environnement de l’entreprise. Cela inclut le volet économique, les
concurrents directs et indirects, la clientèle, les produits, les fournisseurs, les partenaires
ainsi que l’exploration de sa structure qui aide à comprendre le processus de travail et
les acteurs concernés. Egalement il est important de mesurer l’aptitude de l’entreprise
à intégrer des solutions de haute technologie. En résultat nous aurons :
â Le niveau d’engagement de la direction.
â La degré de coopération potentielle.
â La portée du projet.
• Processus de l’organisation :
Egalement la stratégie adoptée par les managers se met en question à cette étape-là.
Une étude approfondie se fait sur le métier concerné et les activités ciblées par le projet
BI.
Etape 2 : Déterminer La conception générale
• Objectifs globaux et locaux :
71
Cela est lié directement au type du management que nous pratiquons au sein de l’organisation. Dès lors le choix de la tactique doit être en concordance avec ce qui était
spécifiée auparavant. Ces objectifs doivent satisfaire aux critères suivants :
â Borné : Limité dans le temps.
â Mesurable : Métrique.
â Accessible : Quels moyens, quelles contraintes, quels risques.
â Réaliste : Quelle méthode d’accès.
â Fédérateur : adhésion globale.
â Constructif : contribue aux objectifs globaux.
• Tableau de bord et conception :
Avec une démarche claire et centrée sur des objectifs bien exprimés, une perception
dynamique et logique sera acquise.si cette phase est réussie l’obtention des KPIs qui
agissent comme un réducteur de risques, et donc la décision sera prise avec moins d’incertitude.
Notons bien qu’un Dashboard doit :
â Comporter pas plus que KPIs.
â Inclure des indicateurs significatifs pour son utilisateur.
â Se présenter comme un outil de communication.
â Etre cohérent.
• Indicateurs de performance :
Une fois le problème est identifié et la conception est prête les décideurs se coopèrent
avec l’équipe BI dans le but de déterminer les indicateurs de performance souhaités.
Un KPI doit être SMART[N8] :
â Spécifique : à votre activité et votre objectif.
â Mesurable : vous devez pouvoir le tracker via votre outil d’analyse d’audience.
â Ambitieux : il doit vous mener au développement de votre activité.
â Réaliste : il doit rester ancrer dans la réalité terrain.
72
â Borné : ancré dans le temps.
• Collecte des données :
Cette étape se résume en l’acquisition des données de différents sources et formats, tout
en vérifiant leur qualité.
L’information doit être [N9] :
âAccessible : Une donnée de qualité doit être présente dans le système d’information
et accessible par les processus et utilisateurs qui l’utilisent.
âValide : La donnée ne porte pas une valeur aberrante, elle se maintient dans la plage
des valeurs acceptables
âConsistante : Si la donnée est redondante et présente en plusieurs endroits à la fois,
elle porte toujours la même valeur à un instant donné.
âPrécise : Elle est jugée suffisamment précise pour l’usage que l’on en attend.
âUtile : Elle répond parfaitement au besoin et à l’usage que l’on en attend.
• Système de tableaux de bord :
A ce niveau le control de la logique entière du système décisionnel se fait suite à la
construction des Dashboards qui assurent la communication et la coordination entre
les acteurs. Au sein de ce système des échanges d’information résumée, nettoyée et
analysée aura lieu. Ce qui résoudre le problème du Reporting classique.
Etape 3 : Réaliser et La mettre en œuvre la solution
• Choix du progiciel :
Face à l’innovation technologique et la diversification des outils sur le marché il est
primordial de bien choisir un outil décisionnel qui répond aux besoins spécifiés.
• Intégration et déploiement :
Il s’agit de déployer la solution dans l’organisation. Tout en prenant en compte les
contraintes liées au produit choisi ; adaptation, cout, formation, durée, infrastructure,
etc.
73
Etape 4 : Améliorer et contrôler la solution
• Audit :
Un suivi permanent de la solution sera assuré par une analyse des résultats qui mène
évidemment au repérage des axes qui doivent être améliorés. «Vérification périodique
de la parfaite adéquation entre le système de pilotage et les besoins exprimés. Méthode
d’audit pour garantir la durabilité de la performance du système de pilotage."[10]
74
Annexe 2 : Cycle de vie de Ralph
KIMBALL
Pour l’élaboration de notre solution décisionnelle nous avons choisi de travailler avec
l’approche Kimball. Ce dernier a consacré sa carrière pour s’approfondir dans le monde
décisionnel. De nos jours en parlant de Ralph Kimball nous parlons de même du cycle de
vie décisionnel. Mr Kimball dans son livre « The data Warehouse Toolkit 3rd édition » a
consacré une grande partie pour expliquer comment gérer un projet décisionnel. Nous avons
alors, fusionnant avec la méthodologie GIMSI en adaptant les étapes du lancement et de la
gestion du projet de GIMSI et la phase d’architecture et de modélisation de Kimball.
Dans son cycle de vie, Kimball parle de 10 étapes qui partent de la planification du projet
au déploiement et maintenance de la solution réalisée.
Figure 4.12 – Cycle de vie de Kimball [11]
75
1. Planification du projet
Définir l’étendu du projet, étudier l’environnement et le degré de maturité de l’entreprise en
termes de qualification t ressource disponibles
2. Définition des besoins
Comprendre les attentes du client et de ses exigences non énoncés, poser les bonnes questions
et tirer l’information du client. ce niveau va préparer le terrain du travail en termes de 3
trajectoire ; La technologie, le modèle et l’interface client.
3. Définition de l’architecture technique
Identifier l’architecture technique pour mettre en place la solution. Il s’agit de déterminer
la vision architecturale globale ce qui dépend des besoins, de l’environnement technique de
l’entreprise.
4. Modélisation dimensionnelle
Mettre en œuvre un modèle multidimensionnelle en procédant avec la détermination :
De la granularité ;
Des dimensions et leurs attribut ;
De la table des faits et ses mesures.
Le modéle obtenue doit inclure les données que nous devons extraire des systèmes sources.
5. Choix technologiques et mis en œuvre
Choisir l’environnement technique une fois l’architecture est spécifiée. Cela inclut les plateformes, les logiciels, SGBD, etc, qui seront installés et testés.
6. Conception et développement du système ETL
Concevoir est développer les étapes d’ETL qui vont résulter des données nettoyées et atomiques alimentant notre magasin de données.
7. Développement de l’application utilisateur
Mettre en place la solution décisionnelle avec finalisation de la construction des tableaux de
bord.
9. Déploiement
Intégrer après validation et test, l’application au sein de l’organisme.
76
10. Maintenance et croissance
S’assurer du fonctionnement durable de la solution ainsi que son évolution avec les changements continue.
77
Annexe 3 : Projet SQL Server
Integration Service SSIS
1. Lancement d’un projet SSIS
• Nouveau projet
Après avoir étudier les données source, concevoir le modèle multidimensionnel et implémenter physiquement le DataMart(voir figure 4.13), il est temps de commencer l’alimentation des dimensions et de la table des faits.
Figure 4.13 – Implémentation Physique du DataMart Promo
78
Pour se faire nous utilisons l’outils Visual Studio 2017, pour la création d’un projet
d’intégration comme le montre la figure (4.14).
Figure 4.14 – Lancement d’un nouveau projet SSIS
79
1. Mise en place du processus ETL
Ce projet comportera toutes les phases du processus ETL. Nous commençons par
l’extraction qui se réalise sur deux étapes :
• L’extraction des données sources vers le staging area. (voir figure 4.15).
Figure 4.15 – Package SSIS du staging area
Durant cette extraction nous utilisant le principe des variables (voir figure 4.16) pour
stocker l’identifiant du dernier élément enregistré, et de même nous avons utilisé la
technique SCD.
Figure 4.16 – Utilisation des variables pour le staging
80
Exemple 1 : Nous illustrons un exemple de staging(voir figure 4.17), de la table «
Action », basé sur l’identifiant dans la figure (4.18)
Figure 4.17 – Staging pour la table « Action »
Figure 4.18 – Extraction de l’identifiant du dernier élément stocké pour la table « Action »
81
Exemple 2 : Nous citons également un exemple de staging(voir figure 4.19), de la
table « Filiale », basé sur « Slowly Changing Dimesion ».
Figure 4.19 – Staging pour la table « Filiale »
• Passage du Staging au DataMart avec un nouveau package (voir figure 4.20)
Figure 4.20 – Package SSIS d’alimentation du DataMart
82
Ce package inclut l’extraction des données du staging vers les dimensions ainsi que leur
transformation. Nous montrons un exemple de rectification des valeurs manquantes par
l’ajout d’une valeur fictive avec la « Colonne Dérivée ». (voir figure 4.21)
Figure 4.21 – Colonne Dérivée dans SSIS
Apres avoir rectifié les données manquante et erronées nous procédons avec leur chargement dans les dimensions. Nous illustrant ci-dessous, les flux de contrôle complets de
la table « Dim_Item »(voir figure 4.22) et « Dim_concurrent »(voir figure 4.23).
L’alimentation des dimensions sera suivi par celle de la table des faits (voir figure 4.24).
83
Figure 4.22 – Flux de contrôle de Dim_Item
84
Figure 4.23 – Flux de contrôle de Dim_Concurrent
85
Figure 4.24 – Alimentation de la table des faits
86
Annexe 4 : Projet SQL Server Analysis
Service SSAS
Figure 4.25 – Cube OLAP[12]
1. OLAP : OnLine Analytical Processing
Pour un stockage dédié au reporting, Le cube OLAP représente une base de données multidimensionnelle. Il se distingue par ses données pré-résumées assurant la rapidité d’exécution
des requetes. Pour son interrogation le cube OLAP dispose d’un langage MDX (Multidimensional Expression), assurant d’effectuer des analyses complexes et avancées. D’une façon
générale il utilise les fonctions classique Min, Max, AVG, COUNT, SUM ainsi que des fonctions spécifiques dédiées aux agrégations.
Il en existe 3 types :
ROLAP : Relational Online Analytical Processing
87
structure relationnelle et plusieurs jointures d’où la complexité des requêtes.
MOLAP : Multidimensional OnLine Analytical Processing.
Elimination du principe relationnel, les données sont stockées suivant une structure multidimensionnelle. Cette dernière assure la restitution des données en pré-calculant tous les
croisements possible.
HOLAP : Hybrid Online Analytical Processing
Alterne entre deux structure, une multidimensionnelle pour les agrégats et une relationnelle
pour les données.
2. Lancement d’un projet SSAS
Dans cette partie nous allons fournir des captures d’écran concernant notre réalisation.
• Nouveau projet (voir figure 4.26)
Avant le passage à la phase de restitution nous avons choisi de créer un cube OLAP
assurant la rapidité des traitements. La création d’un nouveau projet SSAS se fait par
la sélection de « Projet Multidimensionnel » sous la rubrique « Analysis Services ».
Figure 4.26 – Lancement d’un nouveau projet SSAS
88
• Spécification de la connexion (voir figure 4.27)
Une connexion doit être établie avec le DataMart que nous disposons, dans notre cas
il est nommé « Promo ».
Figure 4.27 – Vue de source de données
89
• Nouvelle vue de source de données regroupant les dimensions et les mesure.
Ces étapes résultent la hiérarchie illustrée dans la figure (4.28)
Figure 4.28 – Vue de source de données
90
• Une fois le cube est construit nous pouvons passer à la phase d’analyse et de création
des indicateurs. Nous avons choisis de montrer l’exemple d’indicateur du pourcentage
de participation de chaque filiale par enseigne (voir figure 4.29). Ce dernier se calcule
par la division du nombre d’opérations de la filiale x dans l’enseigne y par la totalité
des opérations de l’enseigne y.
Figure 4.29 – Vue de source de données
91
Annexe 5 : Planification d’un JOB
Suite à l’implémentation de l’ETL et la réalisation des tests de validation nous pouvons
préparer notre solution à être intégrée dans l’entreprise pour se faire il est important de
planifier un JOB qui prend en charge l’exécution des 3 composants de notre projet : Le
staging, l’ETL et le cube OLAP pour permettre finalement l’actualisation du tableau de
bord.
• A cet égard une connexion de type « Authentification Windows », afin d’ajouter un job
à notre « Catalogue » (voir figure 4.30)
Figure 4.30 – « Authentification Windows »
92
• Nous avons ajouté les trois composants comme le montre la figure (4.31).
Figure 4.31 – « Authentification Windows »
93
• Finalement nous précisons la fréquence et la périodicité de son déclenchement (figure
4.32).
Figure 4.32 – « Authentification Windows »
94
Annexe 6 : Phase de restitution Power BI
La phase finale avant l’intégration de la solution consiste à consolider un tableau de bord
dynamique. Nous avons choisi de travailler avec Power BI.
Figure 4.33 – Outils de restitution de données [13]
Nous montrons le tableau de bord construit, avec deux exemples de filiale ; GIPA et Global
Trading.
95
• Tableau de bord de suivi des GMS (voir figure 4.34).
Figure 4.34 – Tableau de bord de consolidé
96
• Rapports consolidés liés à la filiale GIPA :
1. Premier niveau (voir figure 4.35) :
Figure 4.35 – Deuxième niveau de la filiale GIPA
97
2. Troisiéme niveau (voir figure 4.36) :
Figure 4.36 – Troisième niveau de la filiale GIPA
98
• troisiéme niveau consolidé du tableau de bord :
1. Premier niveau (voir figure 4.37) :
Figure 4.37 – Deuxième niveau de la filiale Global Trading
99
2. Deuxième niveau (voir figure 4.38) :
Figure 4.38 – Troisième niveau de la filiale Global Trading
100
Annexe 7 : Documentation de la base
source
Cette section traite nous la base de sonnées source que nous était communiqué par le
responsable. Cette BD est la base du système "Promotips". C’est le manuel du modèle
entité-association.
101
1. Présentation générale
Ce document présente la modèle entité-association du système promotips
102
2 . Structure de base de données :
Table
mk_magasin
mk_enseigne
Mk_action
Mk_ocpics
mk_filiale
mk_actionFiliale
mk_concur
mk_plan
mk_item
mk_itemFamily
mk_gamme
mk_family
mk_product
Description
Table décrit la liste des magasins
Table décrit la liste des enseignes qui sont issus de l’application
merchandising
Table décrit la liste des actions
Table décrit la liste des photos qui sont liées aux actions
Table décrit la liste des filiales
Table décrit les différents status des actions dans les différentes
filiales
Table décrit la liste des concurrents aux filiales PGH
Table décrit la liste des années
Table décrit la liste des articles en promotions
Table décrit la fiche article du groupe POULINA
Table décrit la liste des gammes
Table décrit la liste des familles
Table décrit la liste des produits
3 . Définition des tables :
•
mk_magasin :
Nom de champ
id
addr_magasin
Type de champ
INTEGER
VARCHAR
Description du champ
Identifiant magasin
Addresse magasin
code_merchandising
code_mfg
delegation
delegation_name
magasin_name
ordre_magasin
region
region_name
id_enseigne
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
INTEGER
INTEGER
VARCHAR
INTEGER
Code merchandising
Code MFG
Délégation
Nom Délégation
Nom magasin
Ordre du magasin
Région
Nom du région
Identifiant Enseigne
•
mk_enseigne :
Nom du champ
id
id_merchandiseur
logo
modif_date
Type du champ
INTEGER
INTEGER
VARCHAR
DATE
Description du champ
Identifiant enseigne
Identifiant merchandiseur
Logo
Date modification
103
modif_user
name
ordre
rc
•
Type du champ
INTEGER
VARCHAR
VARCHAR
DATE
VARCHAR
INTEGER
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
DATE
VARCHAR
VARCHAR
INTEGER
INTEGER
Description du champ
Identifiant action
Commentaire
Description
Date de fin
Entrer User
Identifiant action
Nom action
Type du champ
INTEGER
DATE
VARCHAR
VARCHAR
BLOB
INTEGER
Description du champ
Identifiant ocpics
Date entrer
Entrer user
Identifiant entité
Contenu Fichier
Identifiant action
Type du champ
INTEGER
BLOB
VARCHAR
VARCHAR
Description du champ
Identifiant filiale
Logo filiale
Nom filiale
Used
Mois action
Nouvelle action
Date de début
Status
Type
Identifiant plan
Identifiant enseigne
mk_ocpics
Nom du champ
id
enter_date
enter_user
entity
file_content
event_id
•
User Modification
Nom
Ordre de modification
Registre de commerce
mk_action
Nom du champ
id
comment
description
end_date
enter_user
event_id
event_name
mea
mk_exception
month_action
nouvelle_action
repport
start_date
statu
type
plan_id
enseigne
•
VARCHAR
VARCHAR
VARCHAR
VARCHAR
mk_filiale
Nom du champ
id
logo
name
used
104
•
mk_actionFiliale
Nom du champ
calendrier_anim
exception
id_magasin
id_magasinAnim
modif_date
modif_user
statu
filiale
id_action
•
Description du champ
Calendreir anim
exception
Identifiant magasin
Identifiant magasin anim
Modification date
Modification user
Status
Identifiant filiale
Identifiant action
Type du champ
INTEGER
VARCHAR
VARCHAR
VARCHAR
VARCHAR
BLOB
VARHCAR
INTEGER
Description du champ
Identifiant concurrent aux filiale
activity
Addresse
Code
Description
Logo
Nom
Concurrent affiliate
Type du champ
INTEGER
DATE
VARCHAR
VARCHAR
DATE
VARCHAR
VARCHAR
Description du champ
Identifiant plan
Enter date
Enter User
Identifiant entité
Modification Date
Modification user
année
mk_concur
Nom du champ
id
activity
addr
code
description
logo
name
concur_affiliate
•
Type du champ
VARCHAR
VARCHAR
INTEGER
INTEGER
DATE
VARCHAR
VARCHAR
INTEGER
INTEGER
mk_plan
Nom du champ
id
enter_date
enter_user
entity
modif_date
modif_user
year
105
•
•
mk_item
Nom du champ
Type du champ
Description du champ
id
description
end_fact
enter_time
enter_user
entity
family
filiale
initial_price
insertion
item_code
item_um
jeux
mea
mea_price
mecanisme
INTEGER
VARCHAR
DATE
DATE
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
Identifiant Item
description
End Fact
Enter time
Enter user
Identifiant entité
Identifiant famille
Identifiant filiale
Prix initiale
Insertion
Code Item
Um Item
Jeux
Mea
Prix mea
Mecanisme
mk_version
nature
pr_qte
pvente
reduction
start_fact
action_id
plan_id
VARCHAR
VARCHAR
VARHCAR
VARCHAR
VARCHAR
DATE
INTEGER
INTEGER
Mk version
Nature
Qte
Prix vente
Reduction
Start fact
Identifiant action
Identifiant plan
Type du champ
INTEGER
VARCHAR
VARCHAR
VARCHAR
INTEGER
Description du champ
Identifiant product
Code product
Nom product
used
Identifiant filiale
Type du champ
INTEGER
VARCHAR
VARCHAR
VARHCAR
Description du champ
Identifiant family
Code family
Nom family
used
mk_product
Nom du champ
id
code
name
used
filiale
•
mk_family
Nom du champ
id
code
name
used
106
product_id
filiale
•
Identifiant identifiant
Identifiant filiale
Type du champ
INTEGER
VARCHAR
INTEGER
INTEGER
INTEGER
Description du champ
Identifiant gamme
Code gamme
Identifiant famille
Identifiant product
Identifiant filiale
Type du champ
INTEGER
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
BLOB
VARCHAR
VARCHAR
VARCHAR
VARCHAR
VARCHAR
INTEGER
INTEGER
INTEGER
INTEGER
VARCHAR
Description du champ
Identifiant Item Family
code a barre
Identifiant enseigne
Identifiant entity
Item code
Item code concurent
Nom item
Item poulina group holding
Item um
Logo
Nom logo
Identifiant Magasin
Prix
Identifiant Produit
Status
Identifiant gamme
Identifiant family
Identifiant produit
Identifiant filiale
Mk item Family col
mk_gamme
Nom du champ
id
code
family_id
product_id
filiale
•
INTEGER
INTEGER
mk_itemFamily
Nom du champ
id
code_barre
enseigne
entity
item_code
item_conc_code
item_name
item_pgh
item_um
logo
logo_name
magasin
price
product
statu
gamme
family
product_id
filiale
mk_itemFamilycol
107
Bibliographie
[1] Bernard Espinasse, Introduction à l’informatique décisionnelle.
[2] Ralph Kimball, The Data Warehouse Toolkit, 2013.
[3]Les nouveaux tableaux de bord pour les managers.
108
Nétographie
[N1] http ://www.poulinagroupholding.com/fr/profil-du-groupe/, Profil du groupe, dernière
[visite le 01/05/2018].
[N2] http ://www.poulinagroupholding.com/fr/profil-du-groupe/, Profil du groupe, dernière
[visite le 01/05/2018].
[N3] http ://docplayer.fr/8826826-Membre-d-introduction-en-bourse-poulina-group-holdingpgh.html, Membre d’introduction en Bourse POULINA GROUP HOLDING, publié en juillet
2008, dernière [visite le 04/05/2018].
[N4]https ://www.lebigdata.fr/business-intelligence-definition.
[N5] https ://fr.slideshare.net/sirinebargaoui9/mthodes-agiles-vs-mthodes-classiques
[N6] https ://grim.developpez.com/cours/businessintelligence/concepts/conception-datawarehouse/
[N7] https ://grim.developpez.com/articles/concepts/etl/ [N8] http ://infodecisionnel.com/labi-en-generale/datawarehouse/ods-vs-staging-area/ [N9] https ://www.piloter.org/businessintelligence/qualite-des-donnees.htm
[N10] https ://fleid.net/tag/cycle-en-v/
[N11] https ://www.ekko-media.com/indicateurs-de-performance-kpi
[N12]https ://www.google.com/imgres ?imgurl=https
[N13] https ://www.supinfo.com/articles/single/5554-cube-olap-rapports-bases-cube
[N14] https ://powerbi.microsoft.com/fr-fr/
109
Résumé
L’objectif principal de notre travail est l’élaboration d’une solution décisionnelle BI, pour
le suivi et le control de planning promotionnel des grandes et moyennes surfaces GMS.
Ce projet s’agit de consolider un tableau de bord cohérent, simple, dynamique et sécurisé.
Ce dernier sera par la suite déployé et intégré dans l’entreprise. Cette solution va servir
à la direction du département commercial ainsi qu’aux directions des filiales de Poulina
Group Holding. Ce projet vise la veille des opérations promotionnelles de PGH, effectuées
par les enseignes ainsi que la surveillance de l’activité des concurrents, en vue d’améliorer
la performance des ventes promotionnelle et de rectifier la trajectoire commerciale si une
déviation est détectée.
Notre tableau de bord GIMSI est consolidé sur la base d’un modèle multidimensionnel en
étoile suivant le principe de Mr. Kimball en utilisant les produits MSBI. Il est à la disposition
du service commercial, comme instrument de mesure et outils facilitant le processus de prise
de décision, avec la minimisation du risque.
Mots clés : BI, Vente Promotionnelle, MSBI, PGH, processus de prise de décision, Kimball,
schéma en Etoile, Tableau de bord, GIMSI.
110
Abstract
The main goal of our work is the elaboration of a BI solution, to track and control
of promotions planning of medium and large supermarkets GMS. This project is about
consolidating a coherent, simple, dynamic and secure dashboard wich will be deployed and
integrated into the company. This solution will serve sales department as well as Poulina
Group Holding’s subsidiaries. This project aims to maintain an up-to-date knowledge of the
market and to monitor and analyze competitors’s activities, so the Holding could improve
the performance of promotional sales.
Our GIMSI dashboard is consolidated based on a multi-dimensional star model using Kimball
approch and MSBI technology. It is at the disposal of the sales department, as a measuring
instrument and tools facilitating the decision-making process, with the minimum risk.
Keywords : BI, Promotional Sales, MSBI, PGH, Decision Making Process, Kimball, Dashboard, GIMSI.
111