Vous êtes sur la page 1sur 144
République Algérienne Démocratique et Populaire Ministère de l’Enseignement Supérieur et de la Recherche
République Algérienne Démocratique et Populaire
Ministère de l’Enseignement Supérieur et de la Recherche Scientifique
Institut National de formation en Informatique
Direction de la Post-Graduation et de la Recherche
Mémoire
En vue de l’obtention du
Diplôme de Magister en Informatique
Option : Système d’Information
Présenté par
Ahmed HACIANE
Thème
Conception d’un datawarehouse Orienté
CRM
Soutenu le 09/01/2007 devant le jury composé de :
- Dr. D. E. ZEGOUR, Professeur, INI, Président ;
- Dr. M. AHMED NACER, Professeur, USTHB, Examinateur ;
- Dr. S. AIT AOUDIA, Maître de conférences, INI, Examinateur ;
- Dr. Z. ALIMAZIGHI, Maître de conférences, USTHB, Rapporteur.
2005 – 2006

Remerciements

Remerciements Je tiens à exprimer mes sincères remerciements à Mme. ALIMAZIGHI, maître de conférences à l’USTHB

Je tiens à exprimer mes sincères remerciements à Mme. ALIMAZIGHI, maître de conférences à l’USTHB pour avoir accepté d’encadrer ce mémoire et pour son aide précieuse pour l’’accomplissement de mon travail.

Je tiens aussi à exprimer toute ma reconnaissance aux membres de l’équipe LSI de l’institut d’électronique et d’informatique de l’USTHB pour m’avoir accueilli au sein de leur équipe. Je les remercie et tiens à leur assurer ma profonde gratitude.

Je tiens aussi à remercie M. SELMOUNE de l’équipe LSI pour ses remarques qui m’ont permis d’améliorer la qualité finale de ce mémoire.

Je tiens à remercier très sincèrement l’ensemble des membres du jury qui me font le grand honneur d’avoir accepté de juger mon travail.

Je remercie particulièrement les enseignants et le personnel de la DPGR de l’INI, à leur tête Mme AIT ALI YAHIA, directrice de la PG, pour l’effort considérable qu’ils fournissent pour la bonne marche de la DPGR. Je tiens aussi à remercier mes collègues MM. BALA et CHOUDER pour leur présence permanente à mes côtés. Je leur souhaite la pleine réussite dans leurs travaux.

Je voudrais également exprimer mes remerciements aux personnes extérieures au monde universitaire qui m’ont soutenu. En particulier, je remercie tous mes amis et collègues de travail avec lesquels j’ai passé des moments inoubliables…

Enfin, je remercie tout particulièrement mes parents qui m’ont toujours soutenu et qui m’ont permis de mener à bien mes études. Je tiens à remercier également mon frère et mes deux sœurs qui m’ont soutenu depuis le début. C’est pour eux que je dédie ce mémoire.

Ahmed

Sommaire

Lexique

VI

1. Introduction

1

2. Les systèmes décisionnels « datawarehouses »

4

2.1. Les systèmes d’information décisionnels

4

2.1.1. Qu'est-ce que le décisionnel ?

4

2.1.2. Positionnement du décisionnel au sein du SI

5

2.1.3. Les différentes composantes du décisionnel

5

2.2. Le système datawarehouse

7

2.2.1. Définition du datawarehouse

7

2.2.2. L’architecture

globale du datawarehouse

8

2.2.3. Définition des

concepts

9

2.2.4. Le fonctionnement du système datawarehouse

12

2.3. Les modèles de données du datawarehouse

14

2.3.1. Caractéristiques d’utilisation : OLTP vs OLAP

14

2.3.2. Les techniques de modélisation

16

2.4. Le système datawebhouse

21

2.4.1. L'impact du Web sur le datawarehouse

21

2.4.2. Objectifs du datawebhouse

22

2.4.3. De et vers le Web

23

2.4.4. Amener le Web au datawarehouse

24

2.4.5. Amener le datawarehouse au Web

25

2.5. La gestion du « Temps » dans le datawarehouse

26

2.5.1. Le rôle des données temporelles

26

2.5.2. Les problématiques liées au « Temps »

28

2.5.3. Le temps dans la première génération des datawarehouses

29

3. CRM : Customer Relationship Management

31

3.1.

Introduction au CRM

31

3.1.1. Définition du CRM

31

3.1.2. Les objectifs du CRM

33

3.2.

Les facteurs du CRM

35

 

3.2.1. Le

facteur

humain

35

3.2.2. Le

facteur

organisationnel

36

3.2.3. Le

facteur

technologique

37

3.3. Le cycle de vie du client

38

3.4. Le développement de la relation client

38

 

3.4.1. Les

étapes du développement

38

3.4.2. Les raisons de la prédominance de la relation client

39

3.5. Les fonctionnalités offertes par les systèmes CRM

42

3.6. E-Commerce et la gestion de la relation client via Internet

44

 

3.6.1. Le CRM sur Internet

44

3.6.2. Choisir le bon moyen de communication

46

3.6.3. Les trois règles de succès sur la route du e-commerce

47

3.7. Les composants du CRM

47

 

3.7.1. Les systèmes et données en provenance de l’ERP

47

3.7.2. Les bases de données externes

48

3.7.3. Les

canaux d’interaction

48

3.7.4. Le datawarehouse

48

3.8. La technologie du datawarehouse comme base pour le CRM

49

4.

Conception d’un datawarehouse orienté CRM

52

4.1. Etude de cas : présentation de « ETS Boissons »

52

4.2. Le modèle conceptuel général (MCG) orienté CRM

54

 

4.2.1. Comportement client et circonstances client : le cause-à-effet

55

4.2.2. Le modèle conceptuel général « ETS Boissons »

60

4.3. La méthode du point et la modélisation conceptuelle détaillée

63

 

4.3.1. La limite des méthodes traditionnelles

63

4.3.2. La causalité des changements sur les données

69

4.3.3. Le modèle du « point »

70

4.3.4. La construction du modèle conceptuel détaillé « ETS Boissons »

75

4.4. La modélisation logique du datawarehouse orienté CRM

82

 

4.4.1. L’implémentation de la rétrospection

82

4.4.2. Choisir la solution d’implémentation

89

4.4.4.

Les contraintes de la rétrospection

92

4.5.

L’implémentation physique du système

95

4.5.1. L’architecture physique du datawarehouse orienté CRM

95

4.5.2. La couche VIM

97

4.5.3. L’alimentation du datawarehouse

103

4.5.4. Le modèle physique de données

104

4.5.5. Les applications CRM

109

4.5.6. Synthèse sur l’architecture du système

110

4.6.

Les produits logiciels

111

4.6.1. Les produits ETL

112

4.6.2. Les produits OLAP

114

4.6.3. Les outils de restitution

115

4.6.4. Le

Datamining

116

5. Conclusion et

perspectives

119

6. Références Bibliographiques

123

Sommaire des figures

Chapitre 2 : Les systèmes décisionnels « Datawarehouses » Figure 2.1.1 : Une vision transversale de l’entreprise

4

Figure 2.1.2 : Le décisionnel au sein du système d’information

5

Figure 2.1.3 : Les différents composants du décisionnel

5

Figure 2.2.1 : L’architecture du datawarehouse

8

Figure 2.2.2 : L’architecture du système décisionnel

8

Figure 2.2.3 : L’acquisition des données

12

Figure 2.2.4 : Le processus d’acquisition des données

13

Figure 2.2.5 : L’alimentation des datamarts

13

Figure 2.2.6 : La restitution des données

14

Figure 2.3.1 : Le modèle de données normalisé

17

Figure 2.3.2 : Le modèle de données dénormalisé

18

Figure 2.3.3 : Le modèle de données en étoile

20

Figure 2.3.4 : Le modèle de données en flocon

21

Figure 2.4.1 : Le client, le site Web et le datawebhouse

22

Figure 2.4.2 : Les deux facettes du datawebhouse

23

Figure 2.4.3 : Exemple de datamart du « Clickstream »

25

Chapitre 3 : CRM : Customer Relationship Management Figure 3.1.1 : L’évolution des composantes d’entreprise

32

Figure 3.1.2 : Les objectifs du CRM

34

Figure

3.1.3

: Les

résultats constatés

34

Figure 3.6.1 : Les relations CRM – Datawarehouse

49

Chapitre 4 : Conception d’un datawarehouse orienté CRM Figure 4.1.1 : Le modèle général initial en étoile « ETS Boissons »

53

Figure 4.2.1 : Rappel : le modèle conceptuel général « ETS Boissons »

54

Figure 4.2.2 : MCG : Vue globale « circonstances ‘client’ changeantes »

57

Figure 4.2.3 : MCG : Vue détaillée « circonstances ‘client’ changeantes »

58

Figure 4.2.4 : MCG : Vue globale « Client »

58

Figure 4.2.5 : MCG « ETS Boissons » : Vue détaillée « Client »…

59

Figure 4.2.6 : MCG : Vue globale complète « Client »

59

Figure 4.2.7 : MCG « ETS Boissons » 1/3 : Vue détaillée « Client »…

61

Figure 4.2.8 : MCG « ETS Boissons » 2/3 : Vue détaillée « Client »…

62

Figure 4.2.9 : MCG « ETS Boissons » 3/3 : Vue détaillée « Client »…

62

Figure 4.3.1 : Le modèle du point

71

Figure 4.3.2 : Le modèle du point comportemental « ETS Boissons »

71

Figure 4.3.3 : Exemple d’un modèle du point d’une compagnie de télécom

74

Figure 4.3.4 : Le modèle comportemental initial

76

Figure 4.3.5 : Le modèle du point comportemental affiné « ETS Boissons »

77

Figure 4.4.1 : L’implémentation de la rétrospection en utilisant…

88

Figure 4.4.2 : Le schéma logique des circonstances « clients »

90

Figure 4.5.1 : L’architecture EASI du système

96

Figure 4.5.2 : Le modèle des métadonnées de validation

99

Figure 4.5.3 : Le modèle des métadonnées de transformation

100

Figure 4.5.4 : Le modèle des métadonnées de mappage

101

Figure 4.5.5 : Le modèle complet des métadonnées de la couche VIM

102

Figure 4.5.6 : L’extraction et le chargement des données

103

Figure

4.5.7

:

Le

rafraîchissement des données

104

Figure 4.5.8 : Le modèle physique des circonstances « Clients » non-changeantes

104

Figure 4.5.9 : Le modèle physique des circonstances « Clients » changeantes

105

Figure 4.5.10 : Le modèle physique du comportement

107

Figure 4.5.11 : Le modèle physique des segments dérivés

108

Figure 4.6.1 : Le processus ETL

112

Lexique

Lexique ABC (activity Based Costing) : Méthode d’optimisation des processus. Elle est fondée sur une évaluation

ABC (activity Based Costing) : Méthode d’optimisation des processus. Elle est fondée sur une évaluation au plus juste des coûts de revient de chacune des activités du processus. ACSI (American Customer Satisfaction Index) : Indice américain de mesure de la satisfaction de la clientèle. L’indice reflète les attentes des clients, la qualité réellement perçue ainsi que la valeur perçue. Il peut être décliné au niveau de l’entreprise. http://acsi.asq.org/ Agent intelligent : Programme autonome et personnalisable. Les plus aboutis intègrent des caractéristiques d’auto-apprentissage et de communication avec ses alter-ego pour une action coopérative. Ils sont le plus souvent dédiés aux techniques de recherche et de collecte d’information. Analyse de la valeur (Target Costing) : Approche de conception fondée sur une décomposition en fonctions élémentaires et la mise en exergue du coût d’utilité. En d’autres termes, au moment de la conception, pour chaque fonction prévue d’un produit, on se posera les deux questions : quelle est son utilité ? Quelle est sa valeur ? API Application Programming Interface : C’est une interface de programmation standardisant l’accès à des fonctions spécifiques d’un produit logiciel ou d’une application. Pour l’accès aux bases OLAP, Microsoft est en train d’imposer son standard : OLE DB for OLAP. Balanced Scorecard : Une approche de pilotage d’entreprises proposée par Robert Kaplan et David Norton conseillant de juger toutes les décisions sous l’éclairage de quatre (4) perspectives :

Axe Financier : Comment nous voient les actionnaires ? Axe Client : Comment nous voient les clients ? Axe Processus internes : Quels sont nos avantages ? Axe Apprentissage organisationnel : Allons-nous progresser ? Cette approche rencontre un franc succès aux Etats-Unis. Elle mériterait cependant d’être réactualisée pour considérer les nouveaux rôles des clients et des partenaires. Les adeptes de cette approche pourront, avec profit, la compléter par la méthode GIMSI. Business Intelligence : C’est le nouveau terme pour identifier toutes les fonctions ayant trait à l’aide à la décision. Le terme englobe toute la chaîne décisionnelle, de la collecte en passant par les Datawarehouses et les Datamarts, l’analyse et les tableaux de bord.

Cash-flow : Solde des flux de trésorerie engendré par un investissement à la clôture d’une période. Cross selling : Technique recherchant à améliorer la valeur client en l’incitant à acheter aussi d’autres produits que ceux achetés régulièrement. La réussite du cross selling est conditionnée par le décloisonnement de la fonction marketing. (voir Up selling) CRM : CRM est un acronyme pour « Customer Relationship Management », en français GRC pour « Gestion de la Relation Client ». CRM est un terme de l’industrie des systèmes d’information englobant des méthodologies, des stratégies, des outils logiciels et habituellement des capacités internet qui aide une entreprise à gérer ses relations client d’une manière structurée. Datamart : Entrepôt de données départemental orienté sur un problème spécifique. Datamining : Outil d’analyse mettant en évidence des corrélations insoupçonnées en travaillant sur grand nombre de données. Le terme datamining englobe des techniques différentes comme : les recherches d’association, les arbres de décision, les algorithmes génétiques ou encore les techniques d’apprentissage comme les réseaux de neurones. Datawarehouse : Entrepôt de données. Un datawarehouse centralise les données issues des applications utilisées dans l’entreprise. Les données sont organisées par sujet, horodatées et historisées. Pour réussir son Datawarehouse, il faut en premier abandonner la vision universelle de l’information et se focaliser sur des problèmes particuliers et les traiter un par un. En deuxième, il faut surtout ne pas négliger les travaux de nettoyage qui constituent la tâche la plus lourde du projet. En troisième, il faut adopter un système de gestion des méta- données et le maintenir en permanence dans un esprit de qualité totale. DOLAP Desktop OLAP : C’est une version simple du modèle OLAP pour des analyses multidimensionnelles locales, au sein de la machine client. Drill Down : zoom dans une base OLAP ou comment aller du global au détail. EIS (Executive Information System puis Entreprise Information System) :

Tableau de bord destiné à l’origine au management. Le terme n’a pas survécu à la banalisation des systèmes décisionnels et est remplacé par la « Business Intelligence » ERP (Entreprise Ressource Planning ou Progiciel de gestion intégré) : Outil fédérateur du système d’information, l’ERP intègre les fonctions de l’entreprise comme la comptabilité, la gestion des ressources humaines, la gestion de production… Malgré ses avantages quant au décloisonnement du SI dans l’entreprise, les ERP pèchent cruellement par manque d’ouverture vers les clients, les partenaires et les besoins décisionnels des utilisateurs.

ETL (Extraction Transformation Loading) : Désigne une catégorie d’outils et par extension d’activités dédiées à l’extraction des données des bases de productions, à leur adaptation (nettoyage entre autre) et au stockage dans un système décisionnel, le datawarehouse ou le datamart dans la plupart des cas. GRC : Gestion de la relation client (voir CRM). Groupware : Ce sont les outils destinés à favoriser le travail en équipe. On trouvera notamment la messagerie, les bases d’informations partagées et le workflow. Une gestion de contacts, un agenda partagé, voire des outils de vidéo conférence pouvant compléter la panoplie d’outils. HOLAP Hybrid OLAP : Ce terme décrit les bases assurant le juste compromis entre le modèle MOLAP et ROLAP, MOLAP pour les données les plus souvent utilisées et ROLAP pour les autres. HTML Hyper Text Mark-up Language : Langage de description des pages Web. HTML est un dérivé allégé du langage de documentation SGML. HTTP : Protocole de transfert des pages HTML sur le réseau Internet. Méta Donnée (Meta data) : ou les données sur les données. Les méta-données stockent toutes les informations nécessaires à la vie des données : origine, date de dernière mise à jour, mode de calcul, procédure de transformation… La gestion des méta-données est le point clé de la gestion de la qualité du système d’information. Le manque de standard est aujourd’hui la principale difficulté OIM (Open Information Model) du Meta Data Coalition ou CWM (Common Warehouse MetaData) de l’OGM (Object Management Group). MOLAP Multidimensionnal OLAP : Il s’agit des bases de données intégrant physiquement le modèle OLAP. MTBF (Mean Time Between Failure) : Temps moyen entre deux pannes. MTTR (Mean Time To Repair) : Temps moyen de dépannage. ODBC (Open Data Base Connectivity) : Le standard de Microsoft pour accéder aux bases de données. Les solutions ODBC s’opposent aux interfaces dites « native » propriétaires mais plus performantes. OLAP (On-Line Analytical Processing) : Le concept de base de données multidimensionnelle établi par EF CODD l’inventeur du modèle relationnel. Partant du constat que le modèle classique OLTP (On-Line Transaction Processing) était inadapté aux besoins de l’analyse, EF CODD a formalisé les 18 règles du modèle (gérer, traiter et présenter les données multidimensionnelles).

Reporting : Informations constatant l’activité et entre autre la performance locale transmises selon la voie hiérarchique au niveau supérieur à titre de compte-rendu. Elles seront le plus souvent globalisées pour construire un indice « moyen ». ROLAP Relationnal OLAP : Ce terme décrit les bases de structure relationnelle implantant le modèle OLAP. SFA – Sales Force Automation – : des anciens systèmes qui se bornaient principalement à soutenir la mission du représentant en contact avec le client dans la prise des commandes. UML (Unified Modeling Language) : Langage de modélisation. Il est issu des méthodes d’analyse objet : OOD (Object Oriented Design), OMT (Object Modeling Technique) et OOSE (Object Oriented Software Engineering). Up Selling : Technique recherchant à améliorer la valeur client en l’incitant à augmenter ses achats (en proposant des services complémentaires par exemple). XML (eXtensible Markup Language) : Est un langage « d’écriture » de données. Il dérive de SGML, un langage plus ancien utilisé dans les bases documentaires. Il est beaucoup plus puissant sur le plan des règles et des possibilités de définition et de programmation que HTML. Notamment, il sépare le texte de sa présentation. Il ne remet pas en cause tous les acquis du Web, notamment le protocole HTTP, et peut devenir la norme d’écriture.

Chapitre 1

Chapitre 1 Introduction n Introduction générale ; n Problématique ; n Contribution ; n

Introduction

Chapitre 1 Introduction n Introduction générale ; n Problématique ; n Contribution ; n

n

Introduction générale ;

n

Problématique ;

n

Contribution ;

n

Présentation du mémoire.

Introduction

1. Introduction

Le CRM – Customer Relationship Management – ou GRC en français – Gestion de la Relation Client – a trouvé son origine dans plusieurs études américaines qui ont démontré que fidéliser un client coûtait jusqu’à cinq fois moins cher que d’en conquérir de nouveaux. La mise en place d’une démarche CRM est une stratégie qui va mettre le client au centre de l’entreprise et qui a pour objectif d’en améliorer la rentabilité et de le fidéliser. La gestion de la relation client s’est surtout développée dans les années 90 afin de répondre à l’évolution du contexte économique : passage d’une économie d’offre orientée « produit » – années 50 à 60 – à une économie de demande orientée « marché » – années 70 à 80 – puis « client » – depuis les années 90 –. Et enfin, avec l’avènement du Web, une nouvelle notion est apparue : l’E-CRM, ou le CRM électronique via le Web – années 2000 –.

D’un autre côté, les systèmes décisionnels basés sur les datawarehouses sont apparus depuis le début des années 90 afin de permettre de mesurer la performance de l’entreprise dans son environnement. Cette mesure permet d’assister les décideurs dans leur processus de prise de décision. Ainsi, Les systèmes décisionnels tentent de rendre ce processus le plus efficace possible. Le but principal du datawarehousing est de rendre l’information disponible pour tous les acteurs de l’entreprise. Il n’existe pas de doute sur la valeur de l’information dans l’entreprise, et nous admettons tous que la majorité des entreprises ont une masse d’informations considérable non-exploitée dans leurs systèmes opérationnels. Le datawarehouse peut être la clé qui ouvre la porte vers ces informations.

Au fil des années, les datawarehouses n’ont pas cessé d’évoluer afin d’intégrer des concepts liés aux nouvelles tendances émergentes telle que Internet et aussi, le CRM. Au début de leur apparition, les datawarehouses (de « première génération ») n’ont pas été toujours un succès et cela pour au moins deux raisons :

La première est liée à la sous-estimation de la complexité des projets datawarehouses et la difficulté de la gestion des bases de données décisionnelles. La deuxième raison est, quant-à- elle, liée au fait que dans un projet datawarehouse, il n’est pas possible de définir préalablement les besoins d’une manière précise, et cela au contraire des systèmes opérationnels. Or, l’approche de conception traditionnelle des systèmes d’informations restent toujours largement basée sur la compréhension préalable des besoins.

Introduction

Problématique :

Les entreprises existent pour générer un chiffre d’affaire et un profit et le client y constitue la principale source de revenue. C’est pourquoi, la prise de décision dans l’entreprise doit « être orientée » et « en relation » avec les clients. Cela ne devient possible que si les datawarehouses sont capables de fournir toutes les données nécessaires sur les clients.

Les datawarehouses classiques stockent des données comportementales. Ainsi, ces systèmes permettent de connaître et d’analyser le comportement des clients. Or, les données comportementales ne sont pas suffisantes pour une prise de décision CRM efficace. Pour atteindre cet objectif, les applications CRM doivent être supportées par des datawarehouses conçus autour d’objectifs CRM et qui ne se limitent pas à recueillir que les données comportementales. Ce sont des datawarehouses de « deuxième génération » qui intègrent un nouvel objectif clair : maximiser l’efficacité de la gestion de la relation client (CRM).

Contribution :

Le but de ce mémoire est de traiter les éléments liés à la conception d’un datawarehouse orienté CRM pouvant constituer l’élément de base de toute infrastructure CRM efficace. Dans ce mémoire, une méthodologie complète de conception et d’implémentation de datawarehouses orienté CRM est présentée. Ma contribution personnelle dans ce travail sera de regrouper et de présenter tous les éléments de conception nécessaires d’un datawarehouse orienté CRM en se basant sur les travaux de recherche actuels dans ce domaine et d’appliquer en parallèle la méthode et les concepts sur une étude de cas. Ce mémoire traitera donc tous les aspects liés à la conception d’un datawarehouse orienté CRM. Le sujet principal de ce mémoire est donc le datawarehousing (la construction d’un datawarehouse).

Présentation du mémoire :

Le mémoire est organisé comme suit :

Un Premier chapitre état de l’art sur La première génération des datawarehouses :

Historiquement, la première génération des datawarehouses a été construite sur un certain nombre de principes définis par les gourous de l’industrie des systèmes d’information. Les deux principaux pionniers dans le domaine sont : ‘Ralph KIMBALL’ et ‘Bill INMON’. Ces deux personnes peuvent être considérées comme les fondateurs du datawarehousing puisque ce sont eux qui ont donné les définitions et les principes de conception des datawarehouses qui restent actuellement la référence dans le domaine.

Introduction

Le premier chapitre de ce mémoire donne une introduction sur les datawarehouses de première génération et traite, entre-autres, les points suivants :

Le besoin en systèmes décisionnels,

Comment le datawarehouse peut aider à répondre à ce besoin,

Les différences entre les systèmes opérationnels et les systèmes décisionnels,

Les principaux composants du datawarehouse,

L’importance des données temporelles dans les datawarehouses.

Un deuxième chapitre état de l’art sur La gestion de la relation client :

Après avoir présenté les principes du datawarehousing, nous allons essayer de découvrir l’univers de la gestion de la relation client (en anglais CRM pour : Customer Relationship Management, abréviation que nous allons d’ailleurs utiliser tout-au-long de ce mémoire). L’arrivée des systèmes CRM a tout changé. Le CRM ne peut pas être pratiqué dans une entreprise sans avoir une source majeure d’information. Or, la disponibilité de cette source est la raison d’être des datawarehouses. Ainsi, l’intérêt des datawarehouses a été ainsi revitalisé. Les datawarehouses de première génération attendaient l’apparition du CRM pour évoluer et montrer leur vrai intérêt. Sans le CRM, les datawarehouses auraient tout de même gardés leur importance malgré le fait que les projets datawarehouses sont qualifiés de complexes, chers et à grands risques.

Un troisième chapitre sur La conception d’un datawarehouse de deuxième génération orienté CRM :

Nous allons ensuite entamer le cœur de notre sujet qui est la conception d’un datawarehouse de deuxième génération orienté CRM. Nous rappelons, que dans ce mémoire, nous allons agrémenter notre travail par une étude de cas. L’étude de cas concerne une entreprise classique de commercialisation de boissons implantée sur le territoire national. Un datawarehouse orienté CRM sera conçu pour cette entreprise. Pour ce faire, nous allons produire les modèles conceptuels, logiques et physiques des données et proposer l’architecture physique du système.

Le mémoire se termine par la présentation des axes de recherches actuels et futurs sur les datawarehouses orientés gestion de la relation client.

Chapitre 2

Chapitre 2 Les systèmes décisionnels « Datawarehouses » n Les systèmes d’informations décisionnels ; n

Les systèmes décisionnels « Datawarehouses »

Chapitre 2 Les systèmes décisionnels « Datawarehouses » n Les systèmes d’informations décisionnels ; n

n

Les systèmes d’informations décisionnels ;

n

Le Datawarehouse : définition, objectifs, concepts et architectures ;

n

Les techniques de modélisation décisionnelle ;

n

La gestion du « Temps » dans les datawarehouses.

Les systèmes décisionnels « datawarehouses »

2. Les systèmes décisionnels « datawarehouses »

2.1. Les systèmes d’information décisionnels

2.1.1. Qu’est-ce que le décisionnel ?

Le système d’information décisionnel est un ensemble de données organisées de façon spécifique, facilement accessibles et appropriées à la prise de décision ou encore une représentation intelligente de ces données au travers d’outils spécialisés. La finalité d’un système décisionnel est le pilotage de l’entreprise. Les systèmes de gestion sont dédiés aux métiers de l’entreprise pour les assister dans leurs tâches de gestion quotidiennes, et directement opérationnels car maintenus par les utilisateurs sur le terrain. Les systèmes décisionnels sont dédiés au management de l’entreprise pour l’aider au pilotage de l’activité, et indirectement opérationnels car n’offrant que rarement le moyen d’appliquer les décisions. Ils constituent une synthèse d’informations opérationnelles, internes ou externes, choisies pour leur pertinence et leur transversalité fonctionnelles, et sont basés sur des structures particulières de stockage volumineux (datawarehouses, bases OLAP). Le principal intérêt d’un système décisionnel est d’offrir au décideur une vision transversale de l’entreprise intégrant toutes ses dimensions. [Source : Goglin1998]

Figure 2.1.1 : Une vision transversale de l’entreprise [source : Goglin1998]

Figure 2.1.1 : Une vision transversale de l’entreprise [source : Goglin1998]

Cette vue intégrée peut alors être étudiée par fonction ou par métier.

Les systèmes décisionnels « datawarehouses »

2.1.2. Positionnement du décisionnel au sein du système d’information

D’un point de vue architectural, nous considérerons que nous pénétrons dans le monde du décisionnel dès lors que les données de production sont valorisées en informations. Cette valorisation est effective dès que l’on sort du monde de la production. Sur le schéma suivant, décrivant l’architecture fonctionnelle d’une entreprise, on voit la place prise par le décisionnel au sein d’un système d’information. [Source : Goglin1998]

Figure 2.1.2 : Le décisionnel au sein du système d’information [source : Goglin1998]

Figure 2.1.2 : Le décisionnel au sein du système d’information [source : Goglin1998]

2.1.3. Les différentes composantes du décisionnel

Allié aux nouvelles technologies de communication et de diffusion de l’information, le décisionnel va façonner la nouvelle informatique de demain.

Figure 2.1.3 : Les différents composants du décisionnel [source : Goglin1998]

Figure 2.1.3 : Les différents composants du décisionnel [source : Goglin1998]

Les systèmes décisionnels « datawarehouses »

De façon chronologique, on peut considérer que les premiers systèmes de pilotage ont été constitués par des outils qui, via des requêtes, permettaient de constituer des tableaux de bord. Ces outils se sont ensuite enrichis de fonctionnalités de simulation et d’interfaces de présentation. Ce fût alors l’avènement des outils EIS et SIAD. Ces outils aussi puissants soient-ils, ne permettent que de faire une photographie en deux dimensions d’une situation donnée. On est donc : « capable d’identifier un dysfonctionnement, mais pas d’en connaître la cause ». [Source : Goglin1998] Pour pouvoir rechercher et identifier les causes, il fallait introduire une nouvelle dimension au système « photographique » en deux dimensions existant, la dimension de l’agrégation qui permet d’expliquer l’origine de l’information étudiée. Cette nouvelle dimension a été introduite par les systèmes multidimensionnels au travers des systèmes OLAP (On-Line Analytical Processing). Les outils devenant plus conviviaux et plus puissants, les décideurs s’ingénièrent à trouver de plus en plus d’indicateurs toujours plus astucieux et plus compliqués. La course à l’indicateur était lancée. Elle eut pour principale conséquence de noyer le décideur sous une masse de tableaux de bord et de synthèses dont il n’arrivait plus à extraire la substantifique moelle. On introduisit alors un moyen graphique pour identifier plus vite les informations utiles, ce fut l’introduction du « color-coding » et des systèmes d’information cartographiques qui permettent d’identifier visuellement les informations intéressantes selon les critères du décideur puis de les représenter sous une forme directement exploitable par une équipe de direction. Il devenait alors intéressant de diffuser en « temps réel » toutes ces informations et toutes ces analyses vers tous les cadres concernés. C’est ce qu’allait permettre le développement des réseaux, des activités de « Workflow » et maintenant Internet. Notons que le décisionnel souffre toujours d’un grave manque : Il sait fournir les informations nécessaires au décideur ou trouver des corrélations entre des évènements apparemment non liés, mais ne sait pas assister le décideur dans sa prise de décision. Le décideur devient victime du syndrome de la non prise de décision puisqu’il ne sait pas forcément ni par quel bout commencer, ni, finalement, quelle décision prendre. Il faut connaître les seuils à partir desquels les valeurs des indicateurs sont considérées comme anormales, puis identifier les règles exploitant ces seuils afin de proposer un diagnostic. Ce diagnostic permet de prendre la décision finale. Ces nouveaux outils sont appelés les moteurs de règles de gestion. Leur objectif n’est pas de se substituer au décideur, mais bien de l’assister dans sa prise de décision.

Les systèmes décisionnels « datawarehouses »

2.2. Le système datawarehouse

2.2.1. Définition du datawarehouse

Un datawarehouse est un entrepôt de données. Il s’agit d’un stockage intermédiaire des données issues des applications de production, dans lesquelles les utilisateurs finaux puisent avec des outils de restitution et d’analyse. La définition suivante a été énoncée par ‘Bill Inmon’ :

« Un datawarehouse est une collection de données thématiques, intégrées, non volatiles et historisées organisées pour la prise de décision ».

Un datawarehouse est une collection de données :

Thématiques (orientées sujet) : l’objectif d’un datawarehouse est la prise de décisions autour des activités majeures de l’entreprise. On assemblera à cet effet les informations par thèmes contrairement aux modélisations traditionnelles qui regroupent les informations par fonctions. On pourra ainsi passer d’une vision verticale de l’entreprise à une vision transversale beaucoup plus riche.

Intégrées : la transversalité recherchée sera d’autant plus efficiente que le système d’information sera réellement intégré. Cette intégration nécessitera une forte normalisation, une bonne gestion des référentiels et de la cohérence, une parfaite maîtrise de la sémantique et des règles de gestion s’appliquant aux données manipulées.

Non volatiles (pas de suppression) : afin de conserver la traçabilité des informations et des décisions prises, les informations stockées au sein du datawarehouse ne peuvent être supprimées.

Historisées : outre les problèmes de volumétries, de capacité de stockage et de calcul des machines hébergeant le datawarehouse, ce qui nécessite une historisation régulière des informations stockées, l’historisation est rendue nécessaire en vue de suivre dans le temps l’évolution des différentes valeurs des indicateurs à analyser. De ce fait, un référentiel temporel est nécessaire.

Organisé pour la prise de décision. [Source : Kimball1999]

Les systèmes décisionnels « datawarehouses »

2.2.2. L’architecture globale du datawarehouse

Le schéma suivant illustre l’architecture générique d’un système datawarehouse :

Figure 2.2.1 : L’architecture du datawarehouse [ source : Goglin1998]

Figure 2.2.1 : L’architecture du datawarehouse [source : Goglin1998]

L'architecture des systèmes décisionnels met en jeu quatre éléments essentiels : les sources de données, l'entrepôt de données, les magasins de données et les outils d'analyse et d'interrogation.

Figure 2.2.2 : L’architecture des systèmes décisionnels [source : Teste2000]

Figure 2.2.2 : L’architecture des systèmes décisionnels [source : Teste2000]

Les sources de données sont nombreuses, variées, distribuées et autonomes. Elles peuvent être internes (bases de production) ou externes (Internet, bases des partenaires) à l'entreprise.

Les systèmes décisionnels « datawarehouses »

L'entrepôt de données (datawarehouse) est le lieu de stockage centralisé des informations utiles pour les décideurs. Il met en commun les données provenant des différentes sources et conserve leurs évolutions.

Les magasins de données (datamarts) sont des extraits de l'entrepôt orientés sujet. Les données sont organisées de manière adéquate pour permettre des analyses rapides à des fins de prise de décision.

Les outils d'analyse permettent de manipuler les données suivant des axes d'analyses. L'information est visualisée au travers d'interfaces interactives et fonctionnelles dédiées à des décideurs souvent non informaticiens (directeurs, chefs de services,…).

2.2.3. Définitions des concepts [Source : Goglin1998]

Voici la définition des principaux concepts utilisés dans le domaine du datawarehousing :

Bases de production On appelle, d’une façon générale, bases de production toutes les sources (qu’il s’agit de données de production, d’informations internes ou d’informations externes quel que soit leur mode de stockage) dont il va falloir extraire des données en vue d’alimenter le datawarehouse.

L’alimentation ou transformation Les outils d’alimentation sont utilisés pour extraire les données des bases de production et des bases d’informations internes et externes, pour les convertir, les transformer et enfin les stocker dans le datawarehouse.

La base de données du datawarehouse La base de données est le constituant principal du datawarehouse puisque c’est dans celle-ci que l’on va stocker les informations extraites des bases de production. C’est au sein du SGBD qu’est stocké le dictionnaire du datawarehouse où sont stockées les métadonnées, c’est-à-dire « les données sur les données stockées dans le SGBD » décrivant la manière dont sont constituées les informations stockées.

Les systèmes décisionnels « datawarehouses »

Le datawarehouse est supporté par une base de données relationnelle, multidimensionnelle ou objet, même si celles-ci sont assez rares ou utilisées dans des contextes assez particuliers. Une base de données multidimensionnelle est une base dont les données sont stockées de manière à optimiser l’accès aux informations suivant des requêtes non prévues à sa création.

Datamart Un datamart est un magasin de données. Il s’agit d’une solution départementale d’entrepôt de données (datawarehouse) supportant une partie des données et fonctions de l’entreprise (produit, département, activité, etc.). C’est un sous-ensemble du datawarehouse qui ne contient que les données d’un métier de l’entreprise alors que le datawarehouse contient toutes les données décisionnelles de l’entreprise pour tous les métiers.

OLAP (On Line Analytical Processing) La finalité d’un datawarehouse est d’obtenir des vues multidimensionnelles. Ces vues sont représentées sous la forme d’un cube en trois dimensions sachant qu’une base multidimensionnelle peut comporter de nombreuses dimensions. Les systèmes OLAP mettent en œuvre des technologies permettant de rassembler, gérer, traiter et présenter des données multidimensionnelles à des fins d’analyse et de décision. Un outil OLAP est capable de fournir une information multidimensionnelle partagée pour l’analyse rapide.

Datamining Les outils de datamining, également appelés « forage des données » ou « extraction de la connaissance », s’appuient sur le constat qu’il existe au sein de chaque entreprise des informations dont le sens ou les liens sont cachés dans le gisement des données de l’entreprise. Le datamining permet de faire apparaître des corrélations dans des gisements de données. Le datamining est l’étape logique suivant le datawarehousing puisqu’il consiste en l’analyse des données composant le datawarehouse à l’aide d’outils spécialisés en intelligence artificielle, visant à mettre en exergue des corrélations non apparentes par des analyses de premier niveau.

Les systèmes décisionnels « datawarehouses »

EIS Un EIS (Executive Information System) est un outil de visualisation des données et de navigation, permettant de constituer des tableaux de bord. Il est constitué d’outils qui permettent aux différents niveaux de management d’accéder aux informations essentielles de leur organisation, de les analyser et de les présenter de façon élaborée. Ces outils sont dotés d’une interface graphique très conviviale et très esthétique. L’utilisateur final ne peut visualiser ou exploiter que des informations qui ont été prévues par le concepteur des tableaux de bord. A la différence d’un SIAD, l’EIS ne permet pas à l’utilisateur final de poser une question qui n’aurait pas été prévue initialement.

SIAD Un SIAD (Système Interactif d’Aide à la Décision) est un outil d’analyse et de modélisation des données de l’entreprise qui permet de créer des représentations multidimensionnelles de l’information. Historiquement, il s’agit d’une terminologie et d’outils utilisés avant l’avènement et la maturité du datawarehouse.

Requêteur Un requêteur permet à l’utilisateur final d’accéder aux données de l’entreprise de manière autonome, dans un langage propre à son métier, mais qui nécessite généralement la connaissance de la structure de la base accédée, et ce, en définissant lui-même les informations qu’il veut obtenir ainsi que le format des restitutions souhaitées.

Progiciels Ce sont des applications packagées orientées vers un ou plusieurs métiers dédiés (marketing, logistique, finance, ressources humaines, etc.).

Moteur de règles de gestion Un moteur de règles de gestion est un outil permettant de gérer le patrimoine d’une entreprise qu’est son métier, cristallisé par un ensemble de règles de gestion constituant son expertise et son savoir-faire.

Les systèmes décisionnels « datawarehouses »

Internet/intranet Internet en tant que vecteur de communication normalisé et banalisé répond parfaitement aux problématiques d’accès banalisé et de publication à distance et à faible coût. Internet permet d’envisager, par exemple :

L’envoi par messagerie électronique et donc la publication des analyses effectuées ; La possibilité pour un interlocuteur distant de se connecter pour connaître les dernières évolutions des ventes par exemple ; La mise à disposition, au sein d’un serveur Web par exemple, d’informations internes comme les statistiques de production ou externes comme la présentation de la société.

2.2.4. Le fonctionnement du système datawarehouse

Une fois l’architecture du système connue, nous expliquons son fonctionnement. Un système datawarehouse fonctionne selon les étapes suivantes :

a. L’acquisition des données

DWH OLTP Acquisition de données Figure 2.2.3 : L’acquisition des données
DWH
OLTP
Acquisition de données
Figure 2.2.3 : L’acquisition des données

Cette étape constitue la frontière entre le système décisionnel et les systèmes opérationnels. Cette étape détermine la faisabilité du système. Elle consiste à extraire les données outils des systèmes opérationnels qui dans de nombreux cas sont hétérogènes, diffuses et complexes. La problématique de l’alimentation d’un datawarehouse se résout par la mise en place d’un processus en cinq phases : découvrir, extraire, transformer, transporter et charger.

Les systèmes décisionnels « datawarehouses »

Administrer * Planifier * Surveiller

Administrer * Planifier * Surveiller Transformer Transporter Méta données Fédérer Découvrir Charger Extraire Figure

Transformer

Transporter

Méta données Fédérer
Méta données
Fédérer

Découvrir

Transformer Transporter Méta données Fédérer Découvrir Charger Extraire Figure 2.2.4 : Le processus

Charger

Extraire

Figure 2.2.4 : Le processus d’acquisition de données

b. Le stockage des données dans le datawarehouse (l’entrepôt de données)

C’est le point central de stockage de toutes les données de l’entreprise concernées par le

système décisionnel. Les données du datawarehouse sont, rappelons-le, orientées sujet, intégrées, non volatile et historisées pour le support du processus d’aide à la décision.

c. L’alimentation des datamarts (les magasins de données) DWH ……. Figure 2.2.5 : L’alimentation des
c. L’alimentation des datamarts (les magasins de données)
DWH
…….
Figure 2.2.5 : L’alimentation des datamarts

Finance

Commercial

RH

Le datawarehouse est le sas central de contrôle, garant de la qualité et de l’intégrité de l’information. Son principal objectif est d’optimiser l’approvisionnement des magasins de données.

Chaque magasin de données est conçu pour répondre à un enjeu métier. Les données y sont structurées en fonction de la problématique traitée. Le stockage de données y est généralement multidimensionnel.

Les systèmes décisionnels « datawarehouses »

d. L’exploitation de l’information : la restitution des données

C’est le bout de la chaîne. Il s’agit du point d’utilisation du système par les utilisateurs. La satisfaction de ceux-ci dépend de la capacité des outils de restitution à répondre à leur besoin en information et aide à la décision. Les types de restitution possible sont :

Data marts Data warehouse Figure 2.2.6 : La restitution des données
Data
marts
Data warehouse
Figure 2.2.6 : La restitution des données

Reporting

Cube analysis

Requêtage

Data mining

2.3. Les modèles de données du datawarehouse

Un datawarehouse est une base de données. Ainsi, le modèle de données du datawarehouse est le cœur du système décisionnel. La modélisation d’un système décisionnel nécessite des approches spécifiques car l’utilisation dont ce dernier va faire l’objet différera radicalement de celle des systèmes d’information plus classiques.

2.3.1. Caractéristiques d’utilisation : OLTP vs OLAP [Source : Kimball1999]

Les techniques couramment utilisées pour modéliser les données ont initialement été conçues pour qu’elles s’adaptent à des problématiques qui n’existent pas dans le cadre d’un système décisionnel. Dans la mise en œuvre des systèmes d’informations, nous maîtrisons des approches centrées sur des méthodologies telles que Merise. Dans leurs composantes liées à la modélisation des données, ces méthodes sont précises, standardisées, puissantes et assez peu contestées. Le modèle « entité-association » est le plus utilisé, permettant la création d’un modèle logique relationnel. Toutes les théories liées à ces modèles sont largement utilisées dans les entreprises. Ces techniques sont apparues alors que l’informatique était destinée à l’automatisation des processus à caractère transactionnel. Ces applications sont communément nommées OLTP.

Les systèmes décisionnels « datawarehouses »

Cependant, l’informatique de décision, que certains désignent par OLAP, justifie une remise en cause des méthodes de conception d’un modèle de données.

Caractéristiques d’un contexte OLTP Dans la plupart des systèmes transactionnels, le rôle d’un modèle est de garantir la persistance des données. De fait, la base de données est conçue pour garder la trace d’événements survenus dans l’entreprise. Dans un contexte transactionnel, le modèle de données est destiné à minimiser les redondances, pour préserver la fiabilité et la cohérence du système. Des concepts, tels que les formes normales, les clés uniques, les clés étrangères ou de contraintes d’intégrité référentielle, permettent de garantir constamment l’intégrité de la base de données. L’origine de ce souci de minimisation des redondances découle principalement de ce que les systèmes transactionnels effectuent leurs mises à jour en ligne, éventuellement au travers d’un ensemble d’applications partageant le même modèle de données. Dans un système transactionnel, la conception est orientée processus et le modèle de donnée intervient en support de ceux-ci. De point de vue de l’utilisateur, le modèle de données est totalement transparent. Les requêtes sont toujours prévisibles car elles sont effectuées au travers d’une application le plus souvent développée par la même équipe que celle qui a la charge du modèle de données. Les données sont généralement accédées par des clés, notamment des clés uniques. Une bonne indexation permet de garantir des temps de réponse dépendant davantage du volume de données à traiter pour réaliser la transaction que du volume global de la base de données. Les volumes de données qui doivent être accédés pour traiter une transaction ou retournés en résultat de celle-ci sont limités. Il est très rare qu’une requête transactionnelle nécessite de rassembler ou d’agréger des informations issues d’un grand nombre de tables.

Dans un monde décisionnel (OLAP) Dans un contexte décisionnel, les requêtes sont complexes, les redondances plus difficiles à maîtriser ; l’optimisation consiste à anticiper sur les chemins d’accès aux données qui sont fréquemment employés plutôt qu’à faire des optimisations requête par requête. Un Datawarehouse est une base dédiée au décisionnel. L’information est mise à la disposition des utilisateurs mais les mises à jour ne sont jamais faites en ligne. Les seules mises à jour effectuées sur le Datawarehouse émaneront des systèmes de production, lors des phases de

Les systèmes décisionnels « datawarehouses »

chargement (processus d’acquisition de données). Il devient donc envisageable d’introduire des redondances, à condition de les maîtriser dans le processus d’alimentation. Dans un contexte décisionnel, les requêtes manipulent régulièrement des ensembles. Elles effectuent des sélections ou des restrictions de population, des regroupements, des calculs, des agrégations, etc. Pour répondre aux besoins des utilisateurs, même si le résultat des requêtes peut n’être constitué que de quelques lignes, il faudra très souvent manipuler des volumes importants. Dès lors, obtenir des temps de réponse proportionnels au volume de données résultat d’une requête est beaucoup plus difficile qu’en transactionnel. Il convient d’optimiser les requêtes effectuées fréquemment en prédéfinissant physiquement des sous-ensembles de données, moins importants en taille que les données plus détaillées, mais suffisants pour résoudre les requêtes les plus courantes. Une autre caractéristique du décisionnel veut que les utilisateurs cherchent à mettre en relation des éléments qui a priori ne sont pas corrélés au départ. Pour y parvenir, des requêtes complexes sont nécessaires, interrogeant un nombre important de tables. Face à cette complexité, le Datawarehouse doit pouvoir réagir dans des délais raisonnables. Un Datawarehouse vise à répondre aux besoins des utilisateurs en termes d’informations et non en termes d’applications. Dans un contexte décisionnel, du point de vue de l’administrateur de base de données, une des plus grosses difficultés qui se posent est de gérer l’imprévisible. En effet, les requêtes sont le plus souvent ad hoc, générées par l’utilisateur au travers d’un outil, et il est donc impossible d’optimiser chacune de celles-ci au cas par cas. La dernière caractéristique du monde Datawarehouse est qu’il permet le plus souvent de mettre en place un modèle de données intégré, qui entend être transversal à l’entreprise. Ce modèle se constitue le plus souvent de manière incrémentale, au fur et à mesure des réalisations successives des projets décisionnels de l’entreprise.

2.3.2. Les techniques de modélisation [Source : Franco/Lignerolles2000]

Cinq axes permettent de qualifier un modèle de données décisionnel :

1. La lisibilité du point de vue de l’utilisateur final ;

2. Les performances au chargement ;

3. Les performances liées à l’exécution des requêtes ;

4. L’administration : ce n’est pas tant construire le Datawarehouse que le faire vivre qui pose des problèmes aux entreprises. Il faudra tracer les requêtes et identifier celles qui sont lancées fréquemment, maîtriser et industrialiser tous les processus d’extraction ;

Les systèmes décisionnels « datawarehouses »

5. L’évolutivité qui permet de faire en sorte que le développement d’un datawarehouse soit incrémental, et pas seulement itératif : un développement itératif peut en effet amener à définir plusieurs modules applicatifs, indépendants les uns des autres. Par développement incrémental, l’intégration de chacun des modules doit être considérée dans la mise en œuvre itérative, afin de s’assurer de ce que l’homogénéité globale du système est prise en compte.

a. Le modèle de données normalisé

Soit le modèle de données normalisé présenté dans la page suivante :

En décisionnel, ce modèle permet par exemple de ventiler les chiffres d’affaires par produit, par client, etc. Ce type d’approche est courant dans les entreprises en matière de modélisation. Si le système à mettre en œuvre permet à la fois des sélections et des mises à jour en ligne, elle est adaptée. Dans un contexte décisionnel où les mises à jour en ligne ne sont pas d’actualité, sa pertinence doit être reconsidérée. D’un point de vue décisionnel, la sémantique de ce modèle est faible. Les informations intéressantes pour l’utilisateur n’existent pas a priori, elles doivent être extrapolées. Les indicateurs devront être recalculés dynamiquement à chaque requête.

Gamme Fournisseur ID_Gamme ID_Fourn Pays Libellé Nom Code_pays Obj_marge … Libellé Produit Commande
Gamme
Fournisseur
ID_Gamme
ID_Fourn
Pays
Libellé
Nom
Code_pays
Obj_marge
Libellé
Produit
Commande
ID_Produit
ID_cde
Nom
ID_exp
Code_pays
ID_Client
Caract.
Date
Prix HT
Remise_gale
Coût standard
TVA
LG_CDE
ID
ID_cde
Date
No_ligne
Taux
ID_Produit
Quantité
Remise

Client

ID_Client

Nom

Adresse

Code_pays

Expéditeur

ID_Exp

Code_pays

Nom

Figure 2.3.1 : Le modèle de données normalisé

Les systèmes décisionnels « datawarehouses »

Le modèle est en revanche très complet. Il laisse une marge d’autonomie très forte à l’utilisateur. En réalité, un modèle d’entreprise pourra contenir des centaines ou des milliers d’entités, et donc d’autant de tables au niveau physique. Une requête utilisera peut-être des dizaines de tables et qui sera très complexe à formuler pour l’utilisateur et à traiter pour l’optimiseur de la base de données. Les performances seront donc au mieux médiocres et pire inacceptables. Dans des systèmes décisionnels simples, où un nombre réduit d’utilisateurs lancent peu de requêtes sur un modèle de données de petite envergure, ce type d’approche peut fonctionner. Dans les autres cas, il faut absolument recourir à d’autres techniques.

b. Dénormalisation pour le décisionnel

Cette approche vise à adapter le modèle précédent aux besoins liés au décisionnel. La transformation consiste à dénormaliser et à précalculer certains agrégats, donc à introduire des redondances. Aucune technique formelle de dénormalisation n’existe dans le domaine public. L’approche doit être pragmatique. Aboutir à un tel modèle découle d’une analyse précise des besoins des utilisateurs. Ainsi, le modèle précédent devient :

Fournisseur

ID_fourn

Nom

Pays

Client

ID_client

Nom

Adresse

Code_pays

Nom Pays Client ID_client Nom Adresse Code_pays Produit ID_produit Gamme CA année n-1 CA année n

Produit ID_produit Gamme CA année n-1 CA année n Provenance Coût standard ID_fourn

CA année n-1 CA année n Provenance Coût standard ID_fourn Commande ID_cde PHT PTTC Expéditeur Remise

Commande

ID_cde

PHT

PTTC

Expéditeur

Remise

ID client

ID_cde PHT PTTC Expéditeur Remise ID client LG_CDE ID_cde No_ligne PHT PTTC ID_prod Pays

LG_CDE

ID_cde

No_ligne

PHT

PTTC

ID_prod

Pays

Remise

ID_cde No_ligne PHT PTTC ID_prod Pays Remise Figure 2.3.2 : Le modèle dénormalisé Remarquez que le

Figure 2.3.2 : Le modèle dénormalisé

Remarquez que le modèle contient un nombre de tables plus restreint, chaque table étant associée à un sujet d’intérêt. L’orientation « sujet » rapproche le modèle des besoins des

Les systèmes décisionnels « datawarehouses »

utilisateurs. Le modèle présente un certain nombre d’informations agrégées très fréquemment demandées. Ce modèle est moins complexe que le précédent. Le nombre de tables a été diminué d’un facteur de 2. En appliquant le même facteur pour un modèle normalisé de 200 tables, on aboutit à une centaine de tables, ce qui reste complexe et peu lisible. Le gain en performance par rapport au modèle normalisé est également très relatif. Le nombre de tables a diminué, donc aussi le nombre de jointures nécessaires pour les requêtes décisionnelles. En contrepartie, les tables sont plus grosses. Ainsi, les requêtes seront plus simples mais porteront sur des tables plus volumineuses.

c. La modélisation dimensionnelle

La modélisation dimensionnelle est une approche dédiée aux systèmes décisionnels. Elle part du principe que l’objectif majeur de ce type de système est l’analyse de la ventilation de données quantitatives (les faits) par rapport à des données qualitatives (les dimensions). La modélisation dimensionnelle dérive des concepts qui ont amené à l’émergence des bases de données multidimensionnelles, dites bases OLAP, il y a de cela plus de dix ans (1994). La nouveauté est que ce type de modèle est indépendant de la technologie. Elle peut permettre l’utilisation de toute base de données, qu’elle soit relationnelle, multidimensionnelle, objet… L’objectif majeur d’un système décisionnel est l’analyse de la performance qui se matérialise au travers d’un ensemble d’indicateurs. Ces indicateurs n’ont de sens que mis en relation avec des dimensions d’analyse. Les bases de données OLAP du marché sont des solutions conçues exclusivement pour créer rapidement et exploiter les modèles de type multidimensionnel. Ils offrent à l’utilisateur des outils sophistiqués, permettant de naviguer d’une dimension à une autre, de zoomer sur des informations plus détaillées, etc. Dans le modèle dimensionnel qui suit, les indicateurs de base sont groupés dans une table centrale, dite table de faits. Une table de faits regroupe tous les indicateurs qui partagent le même ensemble de dimensions et qui ne peuvent être déduits d’autres indicateurs.

Les systèmes décisionnels « datawarehouses »

Dimensions

Dimensions

Dimensions Dimensions Produit ID_Produit Nom Gamme Resp Coût standard Packaging Couleur
Dimensions Dimensions Produit ID_Produit Nom Gamme Resp Coût standard Packaging Couleur

Produit

ID_Produit

Nom

Gamme

Resp

Coût standard

Packaging

Couleur

ID_Produit Nom Gamme Resp Coût standard Packaging Couleur Période JJ MM YYY Jour_sem Sem. mois Sem.

Période JJ MM YYY Jour_sem Sem. mois Sem. trimestre Sem. année Mois

Fournisseur

ID_Fourn

Nom

Dept

Type

Nationalité

Table des métriques (Faits)

Type Nationalité … Table des métriques (Faits) Ventes ID_prod ID_fourn JJ MM YYY ID_client … CA
Type Nationalité … Table des métriques (Faits) Ventes ID_prod ID_fourn JJ MM YYY ID_client … CA

Ventes ID_prod ID_fourn JJ MM YYY ID_client

CA

Marges

Unités

ID_fourn JJ MM YYY ID_client … CA Marges Unités Client ID_Client Nom Région Age … Figure
ID_fourn JJ MM YYY ID_client … CA Marges Unités Client ID_Client Nom Région Age … Figure

Client

ID_Client

Nom

Région

Age

Figure 2.3.3 : Le modèle en étoile

… CA Marges Unités Client ID_Client Nom Région Age … Figure 2.3.3 : Le modèle en
… CA Marges Unités Client ID_Client Nom Région Age … Figure 2.3.3 : Le modèle en

Ce type de modèle est nommé « modèle en étoile ». Au centre de l’étoile se trouve la table de « faits ». L’identifiant de cette table de « faits » est une clé multiple composée de la concaténation des clés de chacune des dimensions d’analyse. Autour de cette table figurent tous les éléments caractérisant les dimensions d’analyse. Ces caractéristiques sont regroupées dans des tables de dimensions. Les plus grandes forces de ce type de modèle sont la lisibilité et la performance. La lisibilité tout d’abord : ce modèle est très parlant pour l’utilisateur, et sa finalité est évidente. Il est naturellement orienté sujet et définit clairement les indicateurs d’analyse. La performance ensuite : les chemins d’accès à la base de données sont prévisibles. Il existe d’autres techniques de modélisation multidimensionnelle dérivées de la modélisation en étoile, notamment la « modélisation en flocon » ou « snowflake ». Le flocon est simplement une étoile dont les branches sont elles-mêmes décomposées en sous-hiérarchies. Modéliser en flocon, c’est donc conserver le cœur du modèle en étoile, à savoir les tables de faits et affiner la modélisation des tables de dimensions pour les éclater en sous-tables. Ce type de modélisation est intéressant à deux points de vue. D’une part, il normalise les dimensions, réduisant la taille de chacune des tables. D’autre part, ce modèle permet de formaliser la notion de hiérarchie au sein d’une dimension. Un autre avantage du flocon, c’est qu’il normalise les dimensions en éliminant les redondances qui pourraient s’y produire.

Les systèmes décisionnels « datawarehouses »

Couleur ID_coul Nom Chef produit Produit ID_cp ID_produit Nom ID_famille Prénom ID_cp Remarque ID_couleur
Couleur
ID_coul
Nom
Chef
produit
Produit
ID_cp
ID_produit
Nom
ID_famille
Prénom
ID_cp
Remarque
ID_couleur

Désignation

Coût standard

Gamme Activité ID_gamme ID_famille Nom
Gamme
Activité
ID_gamme
ID_famille
Nom

Fournisseur

ID_fourn

Nom

Dept ID_type ID_Orig Type ID_type Nom
Dept
ID_type
ID_Orig
Type
ID_type
Nom
ID_fourn Nom Dept ID_type ID_Orig Type ID_type Nom Ventes ID_prod ID_fourn JJ MM YYY ID_client CA

Ventes ID_prod ID_fourn JJ MM YYY ID_client

CA

Marges

Unités

Origine ID_orig Nationalité
Origine
ID_orig
Nationalité
Région ID_région Nom Client ID_client Nom,… ID_région ID_activité ID_segment Activité ID_activité
Région
ID_région
Nom
Client
ID_client
Nom,…
ID_région
ID_activité
ID_segment
Activité
ID_activité
Désignation
Segment
ID_segment
Segment
ID_gamme Fourchette Fourchette prix Mois MM N Période JJ MM YYY Saison Code_jour ID_saison ID_semaine
ID_gamme
Fourchette
Fourchette
prix
Mois
MM
N
Période
JJ MM YYY
Saison
Code_jour
ID_saison
ID_semaine
Nom
Remarques
Année
Semaine
Jour_sem
ID_année
ID_semaine
Code_jour
Remarques
Semaine
Nom

Figure 2.3.4 : Le modèle en flocon

2.4. Le système datawebhouse [Source : Kimball/Merz2000]

2.4.1. L’impact du Web sur le datawarehouse

Au cours ce cette décennie, avant que la révolution Web prenne de la vitesse, les organisations informatiques ont appris à publier les actifs en données de l’entreprise à destination des analystes internes et du management. Cet acte de publication est la tâche centrale du datawarehouse. Une décennie d’expérience dans la datawarehouse permet de comprendre avec une relative maturité sa nature et la manière dont les services informatiques peuvent amener les techniques à soutenir la publication de toutes ces données. La révolution du Web n’a certainement pas remplacé le besoin du datawarehouse. En fait, elle a accru chez tout un chacun une attente de voir publiées toutes sortes d’informations de manière transparente sur les interfaces des navigateurs Web. L’auditoire des données du

Les systèmes décisionnels « datawarehouses »

datawarehouse a crû, partant des directions internes pour englober les clients, les partenaires et un groupe plus large d’employés internes. Le fait que le Web se concentre sur l’ « expérience client » a rendu de nombreuses entreprises plus conscientes du fait qu’elles devaient connaître leurs clients et leur donner des informations utiles. La révolution du Web a propulsé le datawarehouse sur le devant de la scène, car dans de nombreux cas, il doit être le moteur qui contrôle ou analyse la pratique du Web. Pour se conformer à ces responsabilités plus importantes, le datawarehouse doit s’ajuster. Sa nature doit être quelque peu différente de ce qu’elle a été ces dix dernières années.

Figure 2.4.1 : Le client, le site Web et le datawebhouse [sourc e : Kimball/Merz2000]

Figure 2.4.1 : Le client, le site Web et le datawebhouse [source : Kimball/Merz2000]

Nous appelons cette renaissance de datawarehouse le datawebhouse.

2.4.2. Les objectifs du datawebhouse

Le datawebhouse est la représentation Web d’un datawarehouse. Il joue un rôle crucial et central dans l’exploitation d’une activité compatible avec le Web. Pour répondre à ses promesses, le datawebhouse :

héberge et publie les données du « Clickstream » et d’autres données comportementales provenant du Web qui induisent une compréhension du comportement du client ;

est mis en conformité avec les autres datamarts distribués de datawarehouse de l’entreprise et ceux situés en amont et en aval de la chaîne d’approvisionnement pour qu’ils puissent être utilisés ensemble ;

Les systèmes décisionnels « datawarehouses »

est une source d’informations adaptative et élastique. Lorsque de nouvelles questions de gestion se posent et au fur et à mesure que de nouvelles sources de données deviennent disponibles, il est essentiel que le datawebhouse réponde avec grâce, c’est-à-dire en permettant aux anciennes applications de s’exécuter sans interruption et sans besoin de reprogrammation, tout en leur permettant de coexister avec les nouvelles questions et les nouvelles données ;

est extensibles aux nouveaux médias du Web, que ce soit les images fixes, les graphiques, le son et la vidéo ;

est un bastion de sécurité qui publie des données à destination des clients, des partenaires commerciaux et des employés de manière appropriée, mais qui, dans le même temps, protège les actifs en données de l’entreprise contre une utilisation non prévue ;

est la base de toute aide à la décision liée au Web. Répétons que le datawebhouse doit permettre à ses utilisateurs de prendre des décisions concernant le Web et son utilisation.

2.4.3. De et vers le Web

Comme nous allons le voir, le datawebhouse a deux facettes :

Figure 2.4.2 : Les deux facettes du datawebhouse [source : Kimball/Merz2000]

Figure 2.4.2 : Les deux facettes du datawebhouse [source : Kimball/Merz2000]

La première décrit comment associer les technologies Web au datawarehouse. Le Web est une immense source de données comportementales : les individus, en effet, interagissent avec leur

Les systèmes décisionnels « datawarehouses »

navigateur sur des sites Web distants. Si les données de ce flux continu de clics (le Clickstream) sont bien souvent brutes et simples, elles constituent néanmoins potentiellement une source d’informations jusque là inégalées sur les actions effectuées par les individus utilisant le Web. Associer les technologies Web au datawarehouse, c’est alimenter le datawebhouse avec cette source de données considérable et indiscipliné, afin de les analyser, mais aussi de les mettre en conformité et les conjuguer aux sources de données plus conventionnelles.

Le second aspect du datawebhouse, concerne l’apport du datawarehouse existant vers le Web. Amener le datawarehouse au Web signifie rendre toutes les interfaces du datawarehouse disponibles sur des navigateurs Web. Amener le datawarehouse au Web signifie aussi résoudre, une fois pour toutes, les problèmes d’un environnement entièrement distribué. Le datawebhouse est une approche totalement différente du datawarehouse entièrement centralisé, car, pas plus que l’Internet, il ne peut être centralisé.

2.4.4. Amener le Web au datawarehouse

a. Les données du Web

Comme présenté dans les sections précédentes, le datawarehouse (traditionnel) est alimenté par les systèmes de traitement transactionnel OLTP. Dans un environnement datawebhouse, nous disposons d’une nouvelle source d’alimentation encore insaisissable : capturer, analyser et comprendre le comportement des utilisateurs qui naviguent sur les sites Web. Le Clickstream est une suite chronologique d’actions atomiques qui peuvent être regroupées en sessions. La trajectoire des actions ayant aboutit à un achat, par exemple, peut être analysée et comprise. Nous pouvons désormais savoir comment un individu nous a contactés, de ses intentions et de la qualité de son expérience. Nous pouvons savoir précisément l’écran qu’il a vu et le temps qu’il a mis à faire ses choix. Nous pouvons observer des signes directs de satisfaction ou d’insatisfaction. Nous nous trouvons donc dans une meilleure position pour répondre efficacement au client individuel.

b. Création des datamarts du Clickstream

La création d'un datamart demande des connaissances de modélisation dimensionnelle. Les dimensions auxquelles nous pouvons penser qui ont un sens (répondant à certaines questions) dans un environnement de Clickstream sont en général de ce type :

Les systèmes décisionnels « datawarehouses »

Dimension page: (URL), Dimension agent de l'utilisateur, Dimension état du caddie de l'utilisateur, Le modèle du datamart est le suivant :

Dimension date ; Dimension session ; Dimension démographique.

Figure 2.4.3 : Exemple de datamart du Clickstream [source Kimball/Merz2000]

Figure 2.4.3 : Exemple de datamart du Clickstream [source Kimball/Merz2000]

2.4.5. Amener le datawarehouse au Web

Publier sur le Web Le datawarehouse est l’endroit où sont publiées les données stratégiques de l’entreprise. Le gestionnaire de datawarehouse est une sorte de rédacteur en chef : il rassemble les entrées de données provenant d’une grande diversité de sources qui sont ensuite réparties sur la « table de composition » ; leur pertinence et leur exhaustivité sont alors évaluées. Puis, elles sont enregistrées sous un format commun et reconnaissable, et publiées à l’attention des lecteurs (utilisateurs finals) du datawarehouse. A la fin des années 1990, l’arrivée du Web a favorisé l’essor du datawarehouse. Le Web amplifie et étend ses possibilités de publication ; il offre de nombreux avantages que l’industrie du datawarehouse n’aurait pas pu créer par elle-même. Le Web est tellement irrésistible que le datawarehouse n’a pas d’autre choix que de monter dans ce train express.

Les systèmes décisionnels « datawarehouses »

2.5. La gestion du « temps » dans le datawarehouse [Source : Todman2001]

Remarque : Le terme « Temps » est utilisé ici et dans le reste de ce mémoire dans le sens donnée « Date/heure ».

Un des points les plus importants dans le processus de conception des datawarehouses est la représentation et le traitement des données temporelles (données sur le « Temps »). L’importance des données temporelles est une des caractéristiques des systèmes décisionnels qui les différencient des systèmes opérationnels. Nous allons essayer dans ce qui suit d’introduire les caractéristiques du « Temps » et son utilisation dans les datawarehouses. Les applications de gestion d’entreprise qui constituent le système opérationnel sont développées pour fonctionner dans l’environnement présent où les données temporelles ne nécessitent pas un traitement particulier. Dans plusieurs cas, ces données « Dates/Heures » ne sont que des attributs descriptifs dans les tables des données. Mais dans un datawarehouse, le « Temps » affecte considérablement la structure du système. Les caractéristiques et les objectifs des datawarehouses engendrent des besoins en données temporelles qui sont différents de ceux du système opérationnel. En l’absence actuel de SGBD temporels où le support des données temporelles serait implicite et où le langage de requête contiendrait des fonctions spécifiques sur le « Temps » afin d’en simplifier la manipulation, les bases de données datawarehouses doivent être conçues pour prendre en considération les besoins temporels et être implémentées sur des SGBDR classiques. En d’autres termes, le support du « Temps » doit être explicitement intégré dans les structures des tables et des requêtes.

2.5.1. Le rôle des données temporelles

Dans un datawarehouse, l’ajout des données temporelles (les données « Date/heure ») permet d’historiser (archiver) les données. Cela signifie que les utilisateurs du datawarehouse peuvent découvrir l’aspect de leur entreprise à n’importe quel moment ou période dans le temps. Ceci permettra la découverte et l’étude des habitudes comportementales dans le temps et de faire des comparaisons entre des périodes similaires ou non-similaires. Avec ces données, nous pouvons réaliser des extrapolations en utilisant des modèles prédictifs afin de nous assister à planifier et à prévoir. Ainsi, nous utiliserons le passé pour essayer de prévoir le futur.

Les systèmes décisionnels « datawarehouses »

La valeur et l’importance des données historiques sont généralement reconnues. La capacité de stockage des données historiques est un des avantages majeurs des datawarehouses et l’absence de ces données dans les systèmes opérationnels est un des facteurs de motivation pour le développement des datawarehouses.

a. Période de validité et date de transaction

Ces deux notions seront utilisées plusieurs fois dans le chapitre 3 (Conception d’un datawarehouse orienté CRM). La date de validité associée à une valeur d’un attribut de donnée représente la date pendant laquelle cette valeur est « vraie » (associée) pour cet attribut. Par exemple, la date de validité

d’une commande correspond à sa date de réception. Ces valeurs d’attributs peuvent être associées :

A un instant donné : définis comme une combinaison unique « Date/Heure ». Un évènement est défini comme étant un fait instantané survenant à un instant « t ».

A une période de temps : définie comme étant le temps entre deux instants.

La date de validité est normalement fournie par l’utilisateur sauf dans des cas particuliers comme dans les appels téléphoniques où la date de validité peut être générée par les équipements techniques. La date de transaction associée à une valeur d’attribut de donnée représente la date de la création (physique) et de la disponibilité de la valeur dans la base de données. Les dates de transaction sont générées par les SGBD. Les dates de transaction peuvent aussi être

représentées par des instants uniques ou des intervalles de temps.

b. Les données comportementales

Dans un datawarehouse dimensionnel, les systèmes sources des données comportementales sont les systèmes de gestion opérationnels tels que les systèmes de facturation ou les systèmes de gestion logistique. Comme nous l’avons déjà expliqué, les systèmes opérationnels ne sont

pas conçus pour « historiser » les données. Par exemple, dans un système de gestion des commandes, une fois qu’une commande est satisfaite et transformée en facture, elle disparaît de la base de données opérationnelle après une certaine période de temps (un maximum d’une année). Le rôle d’un système datawarehouse est de capturer les données appropriées qui ont atteint un certain état leur permettant d’intégrer la base de données du datawarehouse. Les données d’une entité sont généralement intégrées au datawarehouse à la fin du cycle de vie

Les systèmes décisionnels « datawarehouses »

opérationnel de cette entité. Par exemple, les données sur une commande sont intégrées lorsque l’état de celle-ci devient « facturé ». À ce moment, le montant facturé devient un « fait » dans le datawarehouse. Une fois chargée, la donnée « fait » ne changera jamais. L’enregistrement des données comportementales dans les tables de faits est réalisé par des insertions continuelles des données en provenance des systèmes sources. Généralement, chaque « fait » est associé à un attribut « Temps » unique (une combinaison « Date/Heure ») relatif à la constatation de l’évènement. Cet attribut « Temps » correspond, dans l’idéal, à la date de validité du « fait ». En pratique, la date de validité n’est pas toujours disponible et est remplacée par la date de transaction générée par le SGBD.

c. Les données sur les circonstances

Les systèmes opérationnels gèrent des données de référence qui se rapportent à des entités telles que : les clients, les produits, les régions, etc. Ces données sont utilisées pour alimenter les dimensions du datawarehouse. Ce sont les données de circonstance (Voir chapitre 3). Ces entités de référence possèdent un cycle de vie qui est différent du cycle de vie des transactions organisationnelles. Le cycle de vie d’une entité de référence n’est pas toujours clair et peut, parfois, être discontinue. Cela s’applique particulièrement pour l’entité « Clients » (Clients qui changent souvent leurs fournisseurs) ou aussi l’entité « Produits » (Produits saisonniers). Certains attributs d’entités peuvent avoir aussi un cycle de vie discontinu (changement d’adresses, d’employeur, etc.). Le traitement de ces données de circonstance, y compris leurs attributs « Temps », est important pour notre solution datawarehouse. Dans le chapitre 3, nous allons expliquer l’importance des données sur les circonstances et proposer des solutions d’implémentation.

2.5.2. Les problématiques liées au « Temps »

Voici en résumé, quelques problématiques liées aux données temporelles qu’il faut résoudre lors de la conception d’un système datawarehouse.

Identifier et capturer les besoins temporels : la première problématique est d’identifier les besoins en données temporelles. Il n’existe pas actuellement de méthodes pour la résoudre. Les techniques actuelles de modélisation des datawarehouses ne fournissent pas un réel support à cette problématique.

Capturer les changements dimensionnels : Qu’est-ce qui arrive lorsqu’une relation change (ex. : un commercial qui change de département) ? Qu’est-ce qui arrive

Les systèmes décisionnels « datawarehouses »

lorsqu’une relation cesse d’exister (ex. : un commercial quitte l’entreprise) ? Comment le datawarehouse manipule-t-il ces changements dans les valeurs d’attributs (ex. : un produit était bleu, il est maintenant rouge) ? y a-t-il un besoin d’analyser ces performances de vente lorsqu’il était rouge ou bleu ?

La fréquence des captures : Un datawarehouse doit être à jour. La fréquence des changements est une question à laquelle il faut répondre durant la conception d’un datawarehouse.

La synchronisation des changements : Quant un attribut change, un mécanisme doit

se déclencher pour déterminer les attributs dépendants qui doivent aussi changer. L’absence de synchronisation affecte la crédibilité des résultats. Certaines problématiques liées au « Temps » sont inhérentes aux modèles dimensionnels mais il est possible de les surmonter en changeant la méthode de conception de ces modèles.

2.5.3. Le « Temps » dans la première génération des datawarehouses

Le « Temps » a un effet considérable sur les datawarehouses car ces derniers sont des applications temporelles. La propriété temporelle des datawarehouses n’a jamais été réellement reconnue dans la première génération des datawarehouse et, par conséquent, la représentation du « Temps » était, dans la plupart des cas, non adéquate. Dans les modèles dimensionnels, la représentation du « Temps » est largement restreinte à la dimension « Temps ». Cela permet à la table des faits d’être partitionnée en utilisant cette dimension mais ne permet pas une représentation du « Temps » dans les autres dimensions. L’arrivée du CRM a soulevé le problème et a renforcé le besoin d’adopter une approche systématique de traitement du « Temps ». Afin de pouvoir concevoir et construire un datawarehouse orienté client (CRM) qui est capable d’assister les décideurs à résoudre leurs problématiques CRM (ex. : la fuite des clients), nous devons s’assurer que les problématiques liées à la représentation du « Temps » sont proprement traitées. La première génération des datawarehouses (présentée dans ce chapitre) peine pour répondre à des questions orientées CRM du genre « Combien de clients avons-nous actuellement ? ». Avec ce genre de capacité limitée, il est impossible d’avoir des métriques ou des mesures en relation avec les changements dans les circonstances. Dans un environnement CRM, nous devons être capables de soumettre des requêtes temporelles qui nous permettront d’analyser les changements dans les circonstances (données

Les systèmes décisionnels « datawarehouses »

de référence) des clients. Ce type de requêtes n’est pas supporté par les datawarehouses de première génération. Nous pouvons ainsi conclure que dans la première génération des datawarehouse, les attributs des dimensions sont réellement considérés comme des attributs supplémentaires des faits. Quand nous réalisons une jointure entre la table des faits et une table dimension, nous ne faisons que juste étendre les attributs des faits avec ceux de la dimension.

La deuxième génération des datawarehouses, les datawarehouses orientés CRM, proposent une autre vision pour le traitement des besoins temporelles. C’est ce que nous allons découvrir dans le chapitre 4.

Chapitre 3

Chapitre 3 La gestion de la relation client n Gestion de la relation client : définitions,

La gestion de la relation client

Chapitre 3 La gestion de la relation client n Gestion de la relation client : définitions,

n

Gestion de la relation client : définitions, objectifs et résultats ;

n

Le développement de la relation client ;

n

Les fonctionnalités des systèmes de gestion de la relation client ;

n

La technologie du datawarehouse au service de la gestion de la relation client.

Le CRM : Customer Relationship Management

2. Le CRM : Customer Relationship Management

3.1. Introduction au CRM

Dans les années 1970, la domination des producteurs était flagrante. Ces derniers s’intéressaient peu de savoir quels clients achetaient et utilisaient quels produits. Aussi longtemps qu’il y avait assez d’acheteurs, la production était le goulot d’étranglement. Les clients étaient forcés de s’orienter d’après les biens produits. ‘Henry Ford’ avait pour habitude de répondre à la question du nombre de couleurs disponibles pour ces voitures :

Naturellement nous produisons chaque couleur pour autant qu’elle soit noire’. [Dyche2002] Au tournant du siècle, la situation s’est retournée. Nous sommes passés d’un marché de l’offre à un marché de la demande. Ce retournement exige des changements à tous les niveaux de l’entreprise, entre autres des activités marketing et vente qui doivent être soutenues plus systématiquement par des systèmes d’information et des bases de données. Nous le voyons, les entreprises sont en transition ; nous passons d’une organisation tournée vers l’offre, donc orientée produits, pour nous diriger vers des structures orientées sur les processus à accomplir dont le CRM est un exemple. Cependant, il ne faut pas oublier que l’objectif d’amélioration de la relation client est un objectif louable pour autant que l’on sache quelle relation améliorer et cela en fonction de la profitabilité des relations; afin de mieux cerner l’étape de base qu’est la profitabilité du client, le concept de « Customer Lifetime Value » reste l’étape de base de toute démarche CRM.

3.1.1. Définition du CRM

CRM est un acronyme pour « Customer Relationship Management », en français GRC pour « Gestion de la Relation Client ». CRM est un terme de l’industrie des systèmes d’information englobant des méthodologies, des stratégies, des outils logiciels et habituellement des capacités internet qui aide une entreprise à gérer ses relations client d’une manière structurée. [Source : Swift2003] Par exemple, une entreprise pourra construire une base de données clients qui décrit les relations avec suffisamment de détails afin que la direction, les vendeurs, les responsables du service-clients et idéalement les clients eux-mêmes puissent avoir accès à l’information pour effectuer des tâches comme le rapprochement entre les besoins des clients et les planifications produits, la génération d’offres, et la description du profil des clients.

Le CRM : Customer Relationship Management

Mieux gérer les clients n’est pas un concept nouveau; il suffit pour s’en convaincre de considérer les systèmes de rabais mis au point dans les années 1960 afin de fidéliser les clients. Les outils par contre sont nouveaux ; au lieu de prendre des décisions stratégiques basées sur leur propre expérience, les managers utilisent des outils logiciels spécifiques pour prendre ou valider ces dernières. Selon différentes vues de l’industrie, le CRM peut consister à :

Permettre à un département marketing d’une entreprise d’identifier et de viser ses clients les plus profitables, à gérer les campagnes marketing avec des objectifs clairs afin de générer des « leads » de valeur pour la force de vente.

Aider l’organisation dans l’amélioration du « telesales », « account » et « sales management » en optimisant le partage de l’information par les multiples intervenants et en simplifiant les processus existants.

Favoriser le développement de relations individualisées avec les clients dans le but

d’améliorer la satisfaction client et de maximiser les profits. Fournir aux employés les informations et les processus nécessaires pour mieux connaître leurs clients, leurs besoins et bâtir des relations durables entre la société, les clients et les partenaires. [Source : Swift2003] Examinons la figure suivante :

Figure 3.1.1 : L’évolution des composantes d’entreprise. [Sourc e : Flueckiger2000]

Figure 3.1.1 : L’évolution des composantes d’entreprise. [Source : Flueckiger2000]

Le CRM : Customer Relationship Management

La figure ci-dessus montre l’évolution des différentes composantes de l’entreprise tendant vers des modèles de travail collaboratifs non seulement intra-entreprise mais aussi inter- entreprises. Le terme CRM s’est développé rapidement durant ces dernières années et comporte actuellement de nombreuses fonctions associées pour un service clients supérieur. Le CRM est un concept plus complet que son prédécesseur SFA Sales Force Automation – qui se bornait à soutenir la mission du représentant en contact avec le client dans la prise de commandes principalement. Le CRM a pour but d’élargir le concept de SFA par un partage des informations client au sein de la structure et une interface avec le système de gestion interne de l’entreprise ERP.

3.1.2. Les objectifs du CRM

Une tendance très nette se dessine dans la fixation des objectifs des projets CRM. Même si l’augmentation de la productivité de la force de vente reste l’objectif traditionnel principal, les entreprises remarquant que le produit ne fournit plus à long terme un avantage concurrentiel mettent de plus en plus l’accent sur l’amélioration de la relation et des services offerts au client autour du produit. Cette nouvelle manière de vendre exige de l’entreprise qu’elle donne plus d’autonomie à sa force de vente et que les systèmes d’information soutiennent les vendeurs ou « marketers » dans cette nouvelle approche. L’approche globale du client devient aussi de plus en plus au centre des stratégies, tout particulièrement dans les situations où l’approche multicanaux est développée. Le but du CRM sera d’intégrer les fonctions isolées de la chaîne de la relation client. Le graphique ci-dessous illustre les résultats d’une enquête menée auprès d’entreprises ayant effectué des projets CRM. Cette enquête montre les objectifs CRM visés par l’implémentation d’une solution CRM dans ces entreprises. [Source : Flueckiger2000]

Le CRM : Customer Relationship Management

Remarquons par exemple que 50% des entreprises ayant implémenté une solution CRM se sont fixées

Remarquons par exemple que 50% des entreprises ayant implémenté une solution CRM se sont fixées comme

objectif Figure l’amélioration 3.1.2 : Les objectifs de la satisfaction du CRM. des [Source clients : Flueckiger2000]

3.1.3. Les résultats constatés avec le CRM Examinons le graphique ci-dessous :

Figure 3.1.3 : Les résultats du CRM. [Source : Flueckiger2000]

Figure 3.1.3 : Les résultats du CRM. [Source : Flueckiger2000]

Le CRM : Customer Relationship Management

Les chiffres ci-dessus récoltés auprès d’entreprises allemandes ayant mené des projets CRM montrent les augmentations ou les diminutions par poste en pourcentage. Par exemple, nous remarquons que ces entreprises ont constaté une augmentation du taux du succès des offres de 8% et une diminution du taux de réclamation de 5%. [Source : Flueckiger2000] On peut en retenir que, même si le CRM a toujours pour but, parfois non-avoué, d’adapter la structure des coûts de la société, les éléments qui visent le développement des ventes et de la profitabilité deviennent des éléments de plus en plus importants.

3.2. Les facteurs du CRM

Le CRM prend forme en tirant parti du potentiel des composantes humaines, organisationnelles et technologiques à disposition.

3.2.1. Le facteur humain

Les affaires comportent toujours et encore une relation d’homme à homme. Le CRM doit placer l’être humain au centre des préoccupations, que ce soit le client, le collaborateur ou le partenaire. De nombreux projets par le passé ont échoué du fait que l’aspect technologique était prépondérant au détriment du facteur humain. La base pour une relation d’affaires à long terme et pleine de succès est toujours et encore la communication entre une entreprise et son client et vice versa. Pour le client, toute personne avec qui il est en contact représente et personnifie l’entreprise. L’attitude du collaborateur va donc influencer directement le client potentiel ou existant. Il est donc essentiel que les collaborateurs, et tout spécialement ceux en contact direct avec les clients, comprennent les buts du CRM et par là la stratégie de l’entreprise. Pour s’occuper de leurs clients de manière ciblée, ils devront donc connaître leurs missions et leurs compétences. Cependant, cette plus grande marge de manoeuvre gagnée par les collaborateurs qui répondent de leurs actes ne va pas sans poser de questions; en effet, les situations où les compétences sont limitées par la structure apportent une situation de confort non négligeable ; le changement d’état entraînera auprès de la structure des mécontentements qu’il s’agira de gérer en mettant sur pied des programmes d’accompagnement au changement pour mieux canaliser ces rebellions. [Source : Freeland2002]

Le CRM : Customer Relationship Management

3.2.2. Le facteur organisationnel

Le processus est compris comme une suite logique d’activités qui contribuent à la stimulation d’un résultat. Du point de vue de l’entreprise, il existe trois types de processus fondamentaux :

Le processus de développement de nouveaux produits : Cela comporte toutes les activités qui permettent de lancer de nouveaux produits dans un temps, une qualité et un prix définis par la stratégie de l’entreprise.

Le processus de génération et de livraison des commandes : Cela comporte l’acquisition et l’acceptation des commandes, la livraison à temps des commandes, la production d’une facture et son encaissement.

Le processus de la chaîne logistique intégrée : Comporte toutes les activités qui

assurent de manière optimale les flux monétaires, matériels et informationnels en respectant les délais, les contraintes financières et le niveau de qualité fixé. Plutôt que de réaliser ces processus de manière fragmentée et fonctionnelle, les départements doivent être mis en relation selon des chaînes consistantes de manière à assurer la satisfaction des clients. Des flux d’informations des produits et des clients, traversant les différentes fonctions, doivent venir alimenter les personnes qui pourront en avoir besoin. Alors que le client s’adresse à l’entreprise par le biais d’un point d’interaction, ses besoins ont une influence qui vont au-delà du point d’interaction et qui vont toucher la production, la logistique et les finances. L’exemple des sociétés de service est flagrant ; en effet, ces sociétés étaient auparavant organisées par divisions de produits, ce qui signifie que chaque division abordait le client de manière autonome, donc développait ses connaissances client ainsi que son système de base de données de manière indépendante. Les pressions concurrentielles ont amené les banques, par exemple, à introduire le principe du « key account » management qui traite les besoins du client dans sa globalité, même si par la suite, en toile de fond, les tâches sont re-divisées sous forme de spécialités. Cette évolution a été facilitée par les évolutions des possibilités offertes par les systèmes d’information. Une optimisation des processus n’est possible que si seulement l’organisation interne de l’entreprise est structurée de manière à répondre aux besoins des processus. [Source :

Freeland2002]

Le CRM : Customer Relationship Management

3.2.3. Le facteur technologique

La technologie joue un rôle important dans la mise en place d’un système CRM. Elle sert à soutenir certains processus afin que les collaborateurs puissent se concentrer sur les tâches où ils apportent la plus grande valeur ajoutée. La technologie offre au client la possibilité de communiquer avec l’entreprise de plusieurs manières ( multichanelling ) ; que ce soit par téléphone, fax, ou email, une relation peut être construite indépendamment de la distance géographique. L’Internet a des conséquences profondes sur la refonte des processus de travail de l’entreprise. Alors que la part du chiffre d’affaires générée par ce canal de vente reste pour la plupart des entreprises encore modeste, la manière dont les informations peuvent être échangées ou réparties, est en train d’offrir aux entreprises d’énormes opportunités soit en termes de gain de productivité ou sous forme de potentiel de développement (Voir le chapitre 2.4 : le système datawebhouse). L’Intégration des systèmes d’information en vue de l’optimisation des processus Les architectures IT ont cru de manière disparate et sont basées sur des applications diverses provenant de langages de programmation différents. Ce qui signifie que les informations sont gérées de manière non coordonnées avec des bases de données pouvant être tenues, soit sur des feuilles de papier jusqu’aux applications multidimensionnelles. Les informations remplissent les besoins en informations des différents départements mais ne sont pas à la disposition de l’entreprise de manière unifiée. Les données informationnelles en provenance des ventes, des stocks, des fournisseurs devraient être disponibles pour tous ceux qui peuvent créer de la valeur avec. Alors que l’implémentation technique afin d’intégrer ces bases de donnes ne pose pas de problèmes insurmontables, la plus grande difficulté réside dans la détermination et la coordination des flux d’information pour assurer que les informations soient à disposition des intervenants en temps voulu. Le but ultime de l’intégration des bases de données est la création d’un point unique de contact « SPOI – Single Point Of Information » qui pourra être réalisé grâce à la réalisation de différentes interfaces. Par exemple, les différentes informations clients rassemblées dans les différents canaux d’interactions sont rassemblées et coordonnées de manière unifiée afin que ces informations puissent être remises à disposition des autres acteurs de la structure interne ou externe par le biais du SPOI. [Source : Freeland2002]

Le CRM : Customer Relationship Management

3.3. Le cycle de vie du client

La gestion de la relation client se représente aisément par un cycle de vie :

Tout commence par un client potentiel intéressé par les produits ou les services de l’entreprise. Après un premier achat, le client potentiel devient un client réel. L’étape suivante est la création de lien durable avec le client à travers des achats successifs, ce qui signifie l’offre constante de nouveaux produits « cross-selling », le but étant de faire constamment augmenter le chiffre d’affaires généré par le client en le fidélisant. En fin, le client interrompe un jour sa relation avec l’entreprise. Cette interruption peut être graduelle ou subite. Durant le cycle de vie d’un client, le système CRM doit pouvoir aider l’entreprise à réactiver ses clients « dormants » : « Sont-ils momentanément non intéressés ou sont-ils globalement mécontents et donc sur le point d’être perdus ? » Afin d’atteindre ce but, il est essentiel de pouvoir déterminer dans quels segments de clientèle des actions de réactivation valent la peine et de définir les mesures à effectuer. Pour exécuter cette mission, le département marketing nécessite des profils clients détaillés et tenus à jour. Ces informations sont en général déjà disponibles dans l’entreprise dans des systèmes séparés et sous des formes différentes; le système CRM a pour mission de consolider ces données pour pouvoir les utiliser de manière opérationnelle. [Source :

Todman2001]

3.4. Le développement de la relation client

3.4.1. Les étapes du développement

a. La relation de voisinage (- => 2000)

Cette relation était caractérisée par les commerces de voisinage. La pression effectuée par les

grands groupes de la distribution disposant d’organisation d’achat centralisée et d’un concept global a fait disparaître les petits commerces où la composante relationnelle était un élément du marketing déterminant. La disparition de ce type de relation se trouve à différents stades selon le secteur économique ou la région géographique du globe.

Le CRM : Customer Relationship Management

b. Le push marketing (1950 => 1985)

Apparu dans les années d’après-guerre, le push marketing était lié à la production de masse

qui avait pour but de répondre à la demande massive pour des produits peu compliqués. Dans un deuxième temps, les entreprises se sont concentrées sur l’élargissement de l’offre.

c. La segmentation (1970 => 2000)

Les années 70 sont les années de consolidation. Les sociétés cherchent avant tout à rationaliser les coûts de production. Le client n’apparaît plus comme un consommateur de

masse, mais la segmentation fait son apparition.

d. Le service et la qualité (1980 => 2000)

Dans les années 80, les sociétés doivent développer des concepts de qualité et de services autour des produits afin de pouvoir se différencier de la concurrence. Après s’être focalisée sur l’offre, les entreprises commencent des programmes de stimulation

de la demande.

e. La relation client (1995 => 2000)

Depuis le début des années 90, les entreprises remarquent qu’il devient quasi impossible de différencier leur offre de la concurrence. Une solution réside dans l’utilisation des informations relatives au client afin de développer des offres ciblées qui correspondront aux besoins réels du client ; on parlera ici du « one to one marketing ». Ce nouveau type de relation est fortement promu par l’avènement des technologies Internet qui permettent un échange d’informations constant entre les entreprises et le client. [Source : Dyche2002]

3.4.2. Les raisons de la prédominance de la relation client

a. Une croissance ralentie

Il est commun de mentionner que les produits vendus actuellement ne se différencient plus de par leur qualité qui est en principe à la hauteur des attentes des consommateurs qui ont eux- mêmes amélioré leur capacité à sélectionner et leur formation à l’utilisation des produits. Ces facteurs ont pour conséquence de prolonger le cycle de vie des produits et de réduire le taux de renouvellement.

Le CRM : Customer Relationship Management

Une pyramide des âges à la base de plus en plus fragile contribue avec les facteurs mentionnés ci-dessus à créer des situations de saturation des marchés et pousse les sociétés à trouver des solutions de diversification.

b. Une offre banalisée

Les années 90 ont vu les entreprises se concentrer sur l’optimisation des processus internes

entre autres par les « Business Process Reenginering » ainsi que l’implémentation des systèmes de gestion intégrés ERP. Bien que le but de réduction des coûts ait été largement atteint, ces différentes opérations ont amené les entreprises à travailler de manière standardisée et par là à produire de manière plus ou moins standard, ce qui pose le problème de la différenciation.

c. Les clients de plus en plus exigeants

Dans l’ère pré-industrielle, les produits étaient fabriqués par des artisans et directement vendus par ces derniers qui connaissaient donc les goûts et les besoins de leurs clients de par la proximité qui prévalait. Dans l’ère industrielle, les produits sont fabriqués en masse afin de répondre à des besoins standards ; de plus, la montée en puissance des distributeurs allongent le chemin entre le fabriquant et le consommateur. Aussi la globalisation amène le consommateur à avoir le choix entre des produits en provenance des différentes régions du globe. Les sociétés se rendent compte qu’il ne leur est plus possible de se différencier par leur offre produit, mais qu’elles doivent soit bâtir un portefeuille de marques qui leur permettent de vendre leurs produits avec un premium et/ou offrir des services accompagnant le produit. Cependant, même ces méthodes ne permettent bientôt plus aux entreprises de se développer ; elles doivent à nouveau porter leur attention non plus sur l’offre mais sur la demande, soit le client, d’où le développement des stratégies basées sur la relation client. [Source : Dyche2002]

Dans la course à la différentiation, les entreprises ont mis au point les options suivantes :

Rendre la vie du client plus facile

La valeur pour le client n’est plus seulement créée par le produit ou le service en lui-même mais par le fait que ce produit peut être disponible dans de multiples canaux et dans une fenêtre temps plus large. Pour l’entreprise, il est logique que, plus l’acte d’achat est facile, plus la probabilité de générer une vente est grande.

Le CRM : Customer Relationship Management

Il est donc important pour les vendeurs de repousser constamment les variables temps et espace, ce qui peut aller à l’encontre d’une relation personnalisée.

Multiplier les tentations d’achat

Les entreprises démultiplient leurs promotions en offrant des packages différents à des prix différents dans des canaux différents. Ces actions sont lancées de manière centrale mais peuvent très bien être taillée sur les besoins de chaque client afin de répondre à ses besoins potentiels définis. Cependant, la multiplication des actions promotionnelles peut aussi entraîner auprès du consommateur une sorte de saturation qui aurait des conséquences négatives sur la marche des affaires.

Proposer des offres personnalisées

Les nouvelles méthodes de production permettent d’offrir des produits sur-mesure, ce qui est un argument d’achat pour les consommateurs qui cherchent eux aussi à se différencier de la masse. L’exemple de la voiture dont les options sont commandées dans le point de vente, les informations transmises à la fabrique directement afin de permettre la fabrication selon les souhaits du client montre à quel point les implications pour le système d’information peuvent être grandes. Les entreprises entraînées dans une course effrénée aux parts de marchée et aidées par l’évolution des systèmes de production et d’information ont créé des systèmes complexes qui certes offraient des solutions intéressantes pour les clients mais qui pouvaient pénaliser leurs propres résultats financiers et qui ont eu pour conséquence deux grands effets :

1. Un client de plus en plus impliqué dans le processus

- Le client informé : Le client type a appris à se défendre contre les actions marketing en développant un comportement qui l’amène à ne pas nécessairement répondre par la vérité afin de provoquer les actions que lui-même souhaite. Les clients connaissent de mieux en mieux les produits, ont la possibilité de s’informer sur les caractéristiques et les prix par l’intermédiaire de l’internet. Le vendeur doit être perçu comme conseiller et non plus comme un vendeur.

- Le client se sert lui-même : Le client a développé un goût pour le self-service dans le temps et l’espace. Cette nouvelle tendance a aussi été poussée par les entreprises qui y trouvent un intérêt dans la réduction des coûts lorsque différentes opérations ne sont plus effectuées par l’entreprise mais par le client.

Le CRM : Customer Relationship Management

2. La perte de contrôle du client

La croissance importante des canaux d’accès aux clients et des messages contenus dans ces canaux à destination des clients ont eu pour conséquence d’inonder littéralement les consommateurs ; il est donc de plus en plus difficile, même pour les sociétés à gros budget, d’avoir accès au client qui lui-même se protège contre le flot grandissant de messages. La fameuse fidélité client pour les entreprises est une notion de plus en plus théorique ; le client doit à chaque acte d’achat être fidélisé. Le processus de recherche devenant de plus en plus aisé pour le client, on ne peut plus parler de contrôle du client. Toujours plus pour le client a entraîné des conséquences en termes de baisse de rentabilité pour les entreprises par la complexité des produits, l’allongement du cycle de vie et la complexité des opérations. [Source : Dyche2002]

3.5. Les fonctionnalités offertes par les systèmes CRM

Les systèmes CRM dans une entreprise ont la mission de soutenir tous les processus impliquant la relation « client ». A cet effet, tout système CRM dispose de fonctions de base. Selon la branche et la mission, certaines fonctions seront ajoutées. D’un point de vue fonctionnel, la direction des ventes ou les responsables des secteurs auront besoin de masques spécifiques pour la planification des ventes ; une hiérarchisation selon diverses variables sera ici très importante. Le département du contrôle nécessitera par contre une comparaison effectif/budget par région. Pour le management, des informations en rapport avec les actions de la concurrence seront par contre utiles. La définition et la mise-à-jour de la base de données « concurrence » incomberont au département marketing qui recevra les données du service extérieur et des autres sources extérieures. Le tableau suivant résume les fonctionnalités des systèmes de gestion de contacts, SFA (Sales Force Automation) et CRM :

Le CRM : Customer Relationship Management

Fonction

Fonctionnalités

Gestion Contact

App. SFA

App. CRM

Ventes

Planification / Prévision annuelle Base de données clients Key Account Management Channel Management Tracking concurrence Gestion des contacts Préparation des offres Gestion des opportunités Gestion / prise des commandes Gestion des RDV / agenda Reporting Telesales / Callcenter E-Sales Analyses / évaluations Utilisation des notebooks Echange / synchro. des données Communication / emails

 

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Marketing

Planification / Prévision annuelle Marketing direct Database marketing Segmentation du marché Telemarketing / Callcenter Gestion des compagnes Encyclopédie marketing Controlling E-Marketing

   

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Service

Planification / prévision annuelle Teleservice / Callcenter Help Desk Gestion des réclamations Gestion de la qualité Service clients technique E-Service

   

X

X

X

X

X

X

X

Interface

Configuration produit MS Office (Word, Excell, …) Lotus Notes ERP Datawarehouse OLAP Workflow Gestion des documents SI géographique

 

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

L’aperçu des fonctionnalités ci-dessus nous montre que le CRM représente une démarche globale et englobe tous les outils de ses prédécesseurs, comme la gestion des contacts que le SFA (Sales Force Automation), comportaient partiellement. [Source : Flueckiger2000]

Le CRM : Customer Relationship Management

3.6. E-Commerce et La gestion de la relation client via Internet

Quelques années auparavant, organiser une action marketing grand public relevait de l’exploit. L’action nécessitait un investissement financier lourd puisqu’il fallait engager des compagnes publicitaires sur les médias et les journaux ou imprimer des prospectus qu’il fallait après distribuer sur les gens tout en payant bien sûr les employés qui s’en chargeaient. Tout cela car à l’époque, les gens n’étaient pas tous connectés sur Internet. Certains jugeaient inutile d’avoir une adresse email, d’autres ne voulaient pas faire l’investissement financier nécessaire, les restants avaient tout simplement peur de l’Internet. Mais deux ans après, la situation a complètement changé, le coût des connexions Internet a sensiblement baissé et la confiance envers ce moyen de communication a été instaurée. Du coup, tout le monde se trouve désormais sur Internet et la réalité suivante est actuellement claire : « Si vous voulez être un professionnel, vous devrez être présent sur la super autoroute de l’information, Internet ». Quelques années auparavant, on s’inclinait pour argumenter que toutes les entreprises doivent prendre cette autoroute. Aujourd’hui, on s’empresse de trouver des entreprises prospères qui ne conduisent pas sur l’autoroute de l’information dans un sens ou dans un autre. Au fait, on est préparé pour argumenter que l’e-commerce n’est pas négociable si on veut maximiser le succès CRM, quelque soit l’entreprise. Chacun de nous doit mieux apprendre sur Internet pour comprendre comment le e-commerce change et va continuer de changer les attentes des clients et comment il est entrain de changer leurs relations avec les autres fournisseurs de service qui nous sont concurrents.

3.6.1. Le CRM sur Internet

En réalité le e-commerce n’est pas un nouveau terrain. C’est juste une extension d’un domaine que toutes les entreprises possèdent depuis l’avènement du commerce : celui qui consiste à créer, maintenir et étendre les relations clients. Pour jouer les jeux des entreprises de ce siècle, il est important de connaître que peut faire le e-commerce pour vous et comment il est entrain de changer les attentes des clients. En travaillant avec la pierre de touche de votre stratégie CRM, vous serez capable d’utiliser les nouvelles règles et les nouveaux utiles offerts par le e-commerce pour satisfaire vos clients.

[Source : Kimball/Merz2000]

Le CRM : Customer Relationship Management

Internet permet de gérer votre stratégie CRM en trois niveaux :

- Niveau 1 : envoyer les informations aux clients

Internet peut fournir une grande route pour avoir des informations sur l’entreprise, ses produits et ses services, pour ses clients actuels et futurs. Dans son niveau le plus bas, cela

veut dire laisser les clients savoir que l’entreprise est présente et leur montrer comment la contacter. Cela peut commencer par la publication sur le Web d’une brochure qui décrit les produits et les services de l’entreprise et communiquer les adresses et les numéros de téléphones utiles.

- Niveau 2 : recevoir les informations sur les clients

Ce niveau de sophistication signifie que l’entreprise ne fait pas que fournir des informations à

ses clients, mais aussi apprendre plus sur eux. Internet permet de collecter tout type de données utiles, et parfois inutiles, sur les clients. Dans certains cas, cela veut dire que les clients doivent répondre à des questionnaires et fournir des informations utiles. Dans d’autres cas, l’entreprise doit être capable de collecter des informations utiles sans s’interfacer directement avec les clients en analysant les données du « ClickStream ».

- Niveau 3 : les e-ventes

L’entreprise peut aussi utiliser Internet pour vendre ses produits et ses services aux clients. Elle peut tisser des relations avec des clients sans jamais les rencontrer. Cette relation complète peut exister dans ce cyber-espace et être un succès. Avec la technologie actuelle, on peut vendre les produits sur Internet, répondre aux questions des clients, offrir des produits et des services additionnels en se basant uniquement sur des achats antérieurs et surtout évaluer le degrés de satisfaction des clients par rapport à ces offres, le tout sans traiter directement avec eux. [Source : Kimball/Merz2000]

L’entreprise peut aussi fournir un service client en ligne via les moyens suivants :

Les moteurs de recherches : un moteur de recherche sur un site aide les clients à trouver des réponses à leurs questions, localiser les informations et se connecter rapidement au département concerné.

Les FAQs (Frequently Asked Questions) : une page sur le site qui publie et répond aux questions les plus posées par les clients.

L’aide en direct : les clients peuvent de nos jours parler directement avec la personne en charge du service quand ils sont sur le site web en utilisant la technologie de la voix sur IP (VOIP).

Le CRM : Customer Relationship Management

Suivi des commandes en ligne : avec des applications personnalisées, l’entreprise peut permettre aux clients de suivre l’évolution et la progression de leurs commandes. Citons comme exemple l’entreprise « DHL » qui donne la possibilité à ses clients de poursuivre leur courrier en temps réel.

3.6.2. Choisir le bon moyen de communication

« Amazon.com » utilise sa présence sur le Web pour fortifier ses relations clients. Chaque personne peut effectuer des recherches dans la base de données ‘produits’ d’« Amazon ». Après un premier achat, « Amazon » encourage et mène le client à l’achat suivant. Lorsque nous visitons « Amazon.com », nous sommes automatiquement reconnus et salués par un : « Bonjour, nous avons des recommandations pour vous ». « Amazon.com » invite aussi les clients à donner leurs avis après un achat. Les clients se connectent au site et exprime leur degré de satisfaction ou de non satisfaction sur le produit acheté. Pour gérer ses clients en utilisant ce moyen hautement sophistiquée, « Amazon.com » investit un capital financier et un autre humain considérables. Les applications d’ « Amazon.com » représentent actuellement ce qu’il y a de mieux dans le monde du e-commerce et ça marche très bien pour cette entreprise. Les entreprises novices dans le domaine doivent cependant commencer par un investissement plus modeste. Il faut prendre en considération comment l’entreprise et ses départements se connectent actuellement à ses clients. Il faut penser aux clients externes, ceux qui payent de l’argent pour les produits et les services, et les clients internes, les autres départements et les personnes qui dépendent de l’entreprise. Voici la liste de départ :

Les pages jaunes et les répertoires téléphoniques : de plus en plus de clients cherchent les contacts des entreprises sur Internet. Etes-vous listé ? est-ce que les données vous concernant sont à jour ?

Email : est-ce que votre adresse email est facilement accessible à vos clients ?

Site Web : est-ce que votre site Web est passif ? est-ce qu’il contient uniquement des brochures sur vos produits et vos services ? Ou, permet-il à vos clients de faire des recherches sur des informations ou des FAQs ? Les clients peuvent-ils acheter directement sur votre site ? Est-ce que votre site vous permet d’apprendre d’avantage sur vos clients ?

Interaction en direct via le site Web : Les clients peuvent-ils se connecter avec vous sur votre site en utilisant la VOIP ou le partage de documents ?

Le CRM : Customer Relationship Management

3.6.3. Les trois règles de succès sur la route du e-commerce

Durant toute la phase d’implémentation d’une solution e-commerce, il faut toujours avoir en tête ces trois règles de succès :

Le e-commerce n’a pas besoin de coûter très chers.

Le maintien à jour. Les clients attendent que les données sur Internet soient plus à jour que celles sur les brochures imprimées.

La personnalisation des services.

- Le e-commerce n’a pas besoin de coûter très chers

Une simple page (une brochure électronique) qui révèle qu’on est présent dans cette espace et

qui montre la direction pour nous atteindre est mieux qu’une non présence.

- Le Maintien à jour

Cela veut dire tout simplement mettre à jour les données électroniques dès que des changements se produisent sur le terrain de la réalité. Exemple, si un N° de téléphone change, il faut mettre à jour immédiatement la page Web, sinon on risque de perdre idiotement des clients potentiels qui voudraient rentrer en contact avec nous.

- Personnaliser le service

Offrez des services personnalisés aux clients. Une page Web personnalisée est une page qui

essaye de faciliter la vie du client. [Source : Kimball/Merz2000]

3.7. Les composantes d’un système CRM

3.7.1. Les systèmes et données en provenance de l’ERP

La plupart des fonctionnalités d’un système CRM vont demander de pouvoir disposer de données en provenance du système central ERP de l’entreprise. Par exemple, une commande prise par un représentant dans un magasin nécessitera la recherche d’un prix de vente qui provient du système de calcul des prix de revient appartenant à l’ERP. Il pourrait aussi être utile de disposer des informations concernant les limites de crédit du client. Cet accès aux systèmes ERP nécessite une interface et représente une des difficultés techniques du projet CRM. On devra aussi veiller à régler la nécessité de synchronisation des données entre l’ERP et les bases de données répliquées auprès des utilisateurs distants.

Le CRM : Customer Relationship Management

Les droits d’accès aux données sont aussi des points à régler soigneusement, par exemple définir qui est habilité à ouvrir un nouveau compte, est-ce l’utilisateur distant à partir du système CRM ou uniquement l’utilisateur central ayant accès direct à l’ERP.

3.7.2. Les bases de données externes

Les bases de données externes permettent d’intégrer des données provenant non pas de l’entreprise mais de sources externes comme les instituts de sondage. Ces données sont importantes car elles permettent d’aborder la totalité d’un marché et non pas uniquement les produits de la société en question. L’intégration des données provenant de sources différentes dans un référentiel commun pose dans la plupart des cas un problème majeur étant donné que les méthodes de saisie et de traitement sont différentes.

3.7.3. Les canaux d’interaction

Le client est de plus en plus servi à travers de multiples canaux comme le représentant, le « call center », le site web ou le fax. Cette nouvelle situation exige une synchronisation en temps réel entre les canaux. En effet, il arrive encore souvent qu’un produit soit en promotion sur le site web, que le client souhaitant retirer le produit immédiatement au magasin qui lui n’est pas au courant de la promotion en question. Le point d’interaction au moment du contact est l’identité de l’entreprise.

3.7.4. Le datawarehouse

La connaissance du client repose sur des informations quantitatives et qualitatives concernant le client et demande la collaboration de toutes les personnes en contact avec le client. Le datawarehouse comportera non seulement des informations comportementales provenant de l’ERP mais aussi les informations relatives à toutes les interactions entre le client et l’entreprise. Le datawarehouse permettra d’offrir une vision unifiée du client aux différents acteurs dans l’entreprise. Quant à la segmentation, elle pourra être effectuée sur des faits objectifs.

Le CRM : Customer Relationship Management

3.8. La technologie du datawarehouse comme base pour le CRM

Le facteur clé de succès d’un projet CRM est le traitement des données sur les clients. Ainsi, parmi les technologies-clés qui rendent possible le succès du CRM sont le datawarehousing et le datamining. Les différents processus rencontrés dans le cycle du « Marketing » peuvent clairement être divisés en deux domaines :

Il y a tout d’abord le traitement opérationnel des données qui aide les collaborateurs comme élément « Front-End » à mettre en place les activités marketing et enregistre les résultats.

Puis il y a les éventuels systèmes Datawarehouses comme élément « back end » qui analysent les résultats et aident les « Marketers » à élaborer une stratégie et planifier les actions.

La base du datawarehouse orienté CRM est donc les données qui proviennent des différentes sources opérationnelles, par exemple les données transactionnelles en provenance des systèmes ERP, de « Sales Force Automation », de « Campaign Management », des « Call Centers », et plus récemment du commerce électronique ; on pourrait y rajouter les données provenant de sources externes comme les instituts statistiques. Cela nous amène à conclure que le CRM ne peut pas être pratiqué dans une entreprise d’une manière efficace sans avoir une source majeure d’information qui est le datawarehouse. Mais comme nous allons le voir, ce datawarehouse doit intégrer dès sa conception les objectifs CRM de l’entreprise. Et cela nous mène finalement au cœur de notre sujet. Examinons le schéma d’interaction CRM - Datawarehouse suivant :

Très souvent, les données récoltées durant les différentes étapes du processus ne sont pas homogènes

Très souvent, les données récoltées durant les différentes étapes du processus ne sont pas homogènes mais

devront Figure être 3.8.1 analysées : Les relations sur une base CRM consistante. – Datawarehouse. Le système Source de datawarehouse [Flueckiger2000] ‘unifie’ les données et les classes

selon différents sujets comme les clients ou groupe de clients.

Le CRM : Customer Relationship Management

Le transfert de données est donc bidirectionnel :

les données transactionnelles sont importées des systèmes opérationnels dans le datawarehouse qui rend possible des recherches complexes sur une base homogène.

Un retour doit être prévu pour permettre aux résultats des analyses d’être utilisés pour des actions concrètes, par exemple pour permettre au « Call Center » lors d’actions téléphoniques de disposer d’informations fines sur le client pour leur proposer des solutions correspondant à leurs attentes.

Selon les besoins, on pourra avoir accès au datawarehouse de différentes manières. Deux principales manières ressortent : OLAP et le Datamining. La principale différence entre les deux est que la méthode OLAP travaille avec des dimensions et relations prédéfinies alors que le datamining recherche des échantillons nouveaux et non connus au départ qui pourront ensuite servir comme base pour OLAP :

- L’OLAP

OLAP offre un moyen très rapide de considérer et d’analyser des données et des nombres selon différentes perspectives. D’après le centre d’intérêt, les données, par exemple les lignes de produits, les régions et les résultats des analyses peuvent être représentés graphiquement selon différentes vues. De cette manière, les différents départements reçoivent des informations qui correspondent à leurs besoins. Le « Product Manager » reçoit la situation de son groupe de produits dans une région déterminée alors que le « Controller » reçoit le chiffre d’affaires de toute la palette de produits pour un mois donné.

- Le Datamining

Le datamining est approprié pour découvrir les relations non connues. Derrière le concept se trouve une combinaison de différents algorithmes statistiques qui peuvent aider les « Marketers » à découvrir des relations et des tendances. Ce processus complexe nécessite la définition de variables à partir d’un grand nombre de données. Le choix du modèle statistique approprié avec lequel les données doivent être analysées est décisif pour le résultat d’une requête. L’exploitation du potentiel lié au « Cross-Selling » et « Up-Selling » se trouve dans la classification des clients. Dans un segment donné, les clients qui ont des intérêts semblables sont répertoriés et ainsi ciblés par un produit défini. Une des méthodes de « Datamining » est

Le CRM : Customer Relationship Management

l’analyse de clustérisation qui permet de répartir constamment les clients dans de nouveaux groupes. Par exemple, à partir d’une commande de vêtements pour bébés, une maison de vente par correspondance pourra prédire quand l’envoi d’un catalogue spécial pour du matériel d’écolage est approprié. Le but ultime de l’utilisation de système de traitement de l’information dans la relation client est le gain d’avantages compétitifs à travers une meilleure gestion de l’information et une orientation client plus forte.

Le but de notre travail sera donc d’approfondir ces concepts et de construire une solution datawarehouse qui servira de base pour les systèmes CRM.

Dans le reste de ce mémoire, nous allons donner les éléments essentiels de conception et de construction d’un datawarehouse de deuxième génération destiné à supporter les systèmes CRM des entreprises.

Chapitre 4

Chapitre 4 Conception d’un datawarehouse orienté CRM n La méthode du point et la modélisation conceptuelle

Conception d’un datawarehouse orienté CRM

Chapitre 4 Conception d’un datawarehouse orienté CRM n La méthode du point et la modélisation conceptuelle

n

La méthode du point et la modélisation conceptuelle ;

n

La modélisation logique du datawarehouse ;

n

L’implémentation physique du système ;

n

Les produits logiciels.

Conception d’un Datawarehouse orienté CRM

4. Conception d’un Datawarehouse orienté CRM

4.1. Etude de cas : présentation de « ETS boissons »

Pour la suite de cette étude, nous allons construire un Datawarehouse pour le support des activités CRM pour une entreprise de commercialisation de boissons implantée au niveau national. Appelons cette entreprise : « ETS Boissons ».

Durant ce chapitre, Nous allons commencer par construire un modèle conceptuel général de notre datawarehouse qui nous servira de base pour le reste de notre étude. Nous allons ensuite présenter une nouvelle méthode de modélisation adaptée au contexte des datawarehouses de deuxième génération orientés CRM. Cette méthode sera utilisée pour produire le modèle conceptuel détaillé de l’« ETS Boissons ». Nous entamerons par la suite les modélisations logique et physique de la base de données et nous terminerons par présenter et expliquer l’architecture d’implémentation physique du système.

Rappelons que le facteur clé de succès d’un projet CRM est le traitement des données sur les clients. Ainsi, parmi les technologies-clés qui rendent possible le succès du CRM sont le « datawarehousing » et le « datamining ».

Les différents processus métiers CRM peuvent clairement être divisés en deux domaines :

Il y a tout d’abord le traitement opérationnel des données qui aide les collaborateurs comme élément « Front-End » à mettre en place les activités marketing et enregistre les résultats.

Puis, il y a les dispositifs « Datawarehouses » comme élément « Back-End » qui analysent les résultats et aident les « Marketers » à élaborer une stratégie et planifier les actions.

La base du datawarehouse orienté CRM est donc les données qui proviennent des différentes sources opérationnelles, par exemple les données transactionnelles en provenance des systèmes ERP, de « Sales Force Automation », de « Campaign Management », des « Call Centers », et plus récemment du commerce électronique ; on pourrait y rajouter les données provenant de sources externes comme les instituts statistiques.

Conception d’un Datawarehouse orienté CRM

Concernant notre système futur, nous commençons par donner un premier schéma global générique simplifié en étoile de la future solution. Ce schéma nous servira de base pour la suite de notre étude :

Ventes

Boisson

Dépôt

Gestionnaire

Compte

Ventes Boisson Dépôt Gestionnaire Compte Client Temps Figure 4.1.1 : Modèle générale initial en étoile «
Ventes Boisson Dépôt Gestionnaire Compte Client Temps Figure 4.1.1 : Modèle générale initial en étoile «

ClientVentes Boisson Dépôt Gestionnaire Compte Temps Figure 4.1.1 : Modèle générale initial en étoile « ETS

Ventes Boisson Dépôt Gestionnaire Compte Client Temps Figure 4.1.1 : Modèle générale initial en étoile «

TempsVentes Boisson Dépôt Gestionnaire Compte Client Figure 4.1.1 : Modèle générale initial en étoile « ETS

Ventes Boisson Dépôt Gestionnaire Compte Client Temps Figure 4.1.1 : Modèle générale initial en étoile «

Figure 4.1.1 : Modèle générale initial en étoile « ETS Boissons »

Voici aussi quelques attributs de la principale dimension, la dimension « Client » :

Dimension « Client »

 

ID Client (clé primaire)

Nom Client

Adresse

Ville

Wilaya

Code postal

ID Gestionnaire Compte

Dimension « Gestionnaire Compte »

 

ID Gestionnaire Compte

 

Nom Gestionnaire Compte

Ensuite, voici les attributs obligatoires de la table des faites :

Ventes

ID Client (Clé primaire 1)

ID Boisson (Clé primaire 2)

Heure (Clé primaire 3)

ID Dépôt

Quantité

Valeur

Intéressons nous maintenant à la modélisation conceptuelle générale de notre datawarehouse.

Conception d’un Datawarehouse orienté CRM

4.2. Le modèle conceptuel général (MCG) orienté CRM

Le Datawarehousing est devenu actuellement une solution mature. Cependant, l’évolution des entreprises nécessite de faire évoluer aussi les datawarehouses. Les entreprises actuelles ont besoin de maîtriser leur CRM, et pour le satisfaire, l’information sera la clé de succès. Les projets CRM ne peuvent pas réussir sans avoir des informations de « haute qualité », à jour et précise. Nous ne pouvons pas gérer un client sans de telles informations. Ainsi, sans ces informations, nous ne pouvons pas, par exemple, adresser aux clients des communications personnalisées ni d’estimer le risque les perdre. Si nous voulons obtenir de telles informations, nous avons besoin de construire un datawarehouse de « deuxième génération » orienté CRM. Un datawarehouse de deuxième génération est un datawarehouse qui gère les données sur :

Le comportement des clients (données comportementales),

Les circonstances des clients : La distinction entre les circonstances et le comportement, qui sont deux différents types de données, est importante dans la conception du datawarehouse.

La segmentation des clients : La capacité de segmenter les clients d’une manière précise est une des plus importantes propriétés d’un datawarehouse conçu pour supporter une stratégie CRM.

Rappelons le modèle initial de l’entreprise « ETS boissons » :

Ventes

Boisson

Gestionnaire

Gestionnaire

Compte

Compte

Gestionnaire Compte
Gestionnaire Compte
Gestionnaire Compte
Gestionnaire Compte
Ventes Boisson Gestionnaire Compte Client Dépôt Temps Figure 4.2.1 : Rappel : le modèle conceptuel général
Ventes Boisson Gestionnaire Compte Client Dépôt Temps Figure 4.2.1 : Rappel : le modèle conceptuel général

ClientVentes Boisson Gestionnaire Compte Dépôt Temps Figure 4.2.1 : Rappel : le modèle conceptuel général initial

Dépôt

Ventes Boisson Gestionnaire Compte Client Dépôt Temps Figure 4.2.1 : Rappel : le modèle conceptuel général

TempsVentes Boisson Gestionnaire Compte Client Dépôt Figure 4.2.1 : Rappel : le modèle conceptuel général initial

Figure 4.2.1 : Rappel : le modèle conceptuel général initial « ETS Boissons »

Conception d’un Datawarehouse orienté CRM

Les deux premières questions qu’on se pose sont : est-ce que ce modèle contient les informations sur :

Le comportement des clients,

Les circonstances des clients.

Il est évident que la réponse est OUI. La table « Ventes » qui est la table de faits contient des détails sur les ventes aux clients. Ce sont des données comportementales, et c’est une caractéristique des datawarehouses et des datamarts dimensionnels qui précise que la table des faits contient des données comportementales. La dimension « Client » est l’endroit unique où on stocke les informations sur les circonstances clients. Selon ‘Ralph KIMBALL’, le principale rôle de la dimension « Client », et des autres dimensions d’un modèle dimensionnel, est de permettre d’ajouter des contraintes aux requêtes à exécuter sur la table des faits. Les dimensions permettent de regrouper (d’agréger) les faits et apparaissent dans les entêtes des tableaux résultats des requêtes. Nous devons être capables d’effectuer des « Drill Down » et des « Slice & Dice » sur la table des faits. Une solution basée sur un modèle dimensionnel est idéal pour cela. Un modèle dimensionnel est avant tout, un modèle orienté comportement. Il est orienté comportement car son principal objectif est de faciliter l’analyse compréhensive des données comportementales.

4.2.1 Comportement Client et Circonstances Client : le principe du cause-à- effet

Le plus important problème que les entreprises actuelles s’empressent de maîtriser et « la fidélité des clients » et sa directe conséquence : « le mouvement des clients ». Pour mieux comprendre la situation, prenons l’exemple d’un client d’un opérateur de téléphonie mobile et réfléchissons aux raisons qui peuvent pousser ce client à changer d’opérateur :

Probablement qu’il vient de déménager vers une autre adresse et que la couverture réseau de cet opérateur est mauvaise dans la nouvelle région.

Le client a changé d’employeur. Le nouvel employeur lui offre un téléphone portable avec une ligne d’un autre opérateur.

Un enfant du client vient de rentrer à l’université, les dépenses ont augmenté et le père a jugé que le téléphone portable devient désormais un luxe qu’il ne peut plus supporter.

Conception d’un Datawarehouse orienté CRM

Toutes ces situations (circonstances) peuvent être la cause pour laquelle ce client apparaîtra le mois prochain sur la liste des clients ayant cessé leur relation avec cet opérateur. Ça aurait été parfait si l’opérateur avait prédit qu’il s’agissait d’un client à risque. La seule manière de pouvoir réaliser ce classement est d’analyser les données recueillies et d’appliquer sur elles quelques modèles prédictifs qui donneraient un classement du genre :

1 : Client à faible risque,…, 10 : Client à haut risque.

Mais quelles sont ces données là ? Traditionnellement, les datawarehouses sont organisées autour de modèles purement comportementaux. Dans une compagnie de téléphonie mobile, les données comportementales fréquemment utilisées sont liées aux appels téléphoniques :

Type d’appel : national, international,

Durée de l’appel,

Coût de l’appel,

Heure de l’appel,

L’opérateur destination.

Si nous analysons ces données comportementales, qu’est-ce qu’allons-nous trouver ? Peut-être qu’on peut simplement prédire que juste avant le départ du client, il a cessé d’utiliser son téléphone !!! Cependant, « Ce changement brutal de comportement est le résultat d’un changement dans les circonstances ». En partant du fait que les datawarehouses dimensionnels mesurent le comportement, on peut conclure que de tels modèles ne nous aident pas à connaître d’avance les clients que nous risquons de perdre. Nous devons alors être rigoureux et se concentrer beaucoup plus sur les données des circonstances. C’est pourquoi, les datawarehouses de nouvelle génération sont construits comme une base de développement d’applications CRM en incluant le traitement des données de circonstances. Au lieu d’être orientée « Comportement », la nouvelle génération de datawarehouses est qualifiés de « Orientée client ». Et pour construire un modèle orienté client, il faut commencer par modéliser celui-ci. Nous savons maintenant qu’il existe deux types majeurs de données : « comportementales et de circonstances ». Pour le moment, concentrons-nous sur les circonstances.

Conception d’un Datawarehouse orienté CRM

Parmi les données sur les clients que nous voulons stocker figurent :

Client

Nom

Adresse

N° téléphone

Date de naissance

Sexe

Situation familiale

Il est clair que nous aurons besoin de beaucoup plus de données. Mais cette liste sera utilisée comme un exemple pour simplifier notre étude de cas.

Client

Circonstances ‘client’ changeantes

Client Circonstances ‘client’ changeantes Figure 4.2.2 : MCG : Vue globale « circonstances ‘Client’ changeantes

Figure 4.2.2 : MCG : Vue globale « circonstances ‘Client’ changeantes »

Nous commençons par construire un modèle conceptuel général pour les clients. Pour chaque client, nous identifions les attributs qui peuvent changer de valeur et les attributs qui ne changent pas de valeur où ceux dont on ne veut pas suivre les changements et connaître les anciennes valeurs.

Dans notre étude de cas « ETS Boisson », le nom, le n° de téléphone, la date de naissance et le sexe sont des attributs qui ne peuvent pas changer de valeurs ou si elles changent, on n’aura pas besoin de connaître les anciennes valeurs. Pour l’instant, considérons que l’adresse et la situation familiale du client peuvent changer plusieurs fois leurs valeurs.

Conception d’un Datawarehouse orienté CRM

Le modèle sera comme suit :

Situation familiale Ainsi, Figure on garde 4.2.3 la : MCG trace des : Vue changements
Situation familiale Ainsi, Figure on garde 4.2.3 la : MCG trace des : Vue changements

Situation familiale

Situation familiale Ainsi, Figure on garde 4.2.3 la : MCG trace des : Vue changements détaillée

Ainsi, Figure on garde 4.2.3 la : MCG trace des : Vue changements détaillée « d’adresses circonstances et de la ‘Client’ situation changeantes familiale. »

Client

Client Adresse

Adresse

Maintenant, l’autre principal type de données clients que nous devons capturer est le comportement. Les données comportementales résultent des interactions entre le client et l’entreprise. Les modèle conceptuel général que nous essayons de développer doit inclure les données comportementales.

Comportement

client

Client

Circonstances

client

Comportement client Client Circonstances client changeantes Figure 4.2.4 : MCG : Vue globale « Client »
Comportement client Client Circonstances client changeantes Figure 4.2.4 : MCG : Vue globale « Client »

changeantesComportement client Client Circonstances client Figure 4.2.4 : MCG : Vue globale « Client » Comportement client Client Circonstances client Figure 4.2.4 : MCG : Vue globale « Client »

Figure 4.2.4 : MCG : Vue globale « Client »

La relation entre le client et son comportement montre qu’il y’a plusieurs instances comportementales dans le temps. Le modèle actuel que nous proposons pour l’« ETS Boisson » sera comme suit :

Conception d’un Datawarehouse orienté CRM

Adresse Ventes boissons Client Situation familiale
Adresse
Ventes boissons
Client
Situation
familiale

Figure 4.2.5 : MCG « ETS Boissons » : Vue détaillé ‘Client’ : comportement et circonstances

Ce modèle conceptuel général de notre datawarehouse orienté client parait simple. Mais à ce stade, il n’est pas encore complet.

Nous rappelons qu’il existe trois types de données client. Les deux premiers sont les circonstances et le comportement. Le troisième type est les « segments dérivés ». Comme exemples de principaux segments dérivés, nous pouvons lister : « Durée de vie estimée » et « tendance à partir ». En réalité, la classification d’un client par rapport à un segment dérivé se fait sur la base de processus de calcul de type « modèles prédictifs ». Donc, il est préférable de modifier notre modèle afin d’inclure les segments dérivés :

Comportement

     

Circonstances

Client

Client Client

Client

changeantes

changeantes Comportement       Circonstances Client Client   Segments dérivés   Comportement       Circonstances Client Client   Segments dérivés  

 
 
 

Segments dérivés

 

Figure 4.2.6 : MCG : Vue globale complète « Client »

Ce modèle peut être décrit comme le modèle conceptuel général d’un datawarehouse orienté client. Ce MCG constitue un « Template » à partir du quel seront construit dans le futur des modèles conceptuels finalisés.

Conception d’un Datawarehouse orienté CRM

4.2.2 Le modèle conceptuel général « ETS Boissons »

Maintenant que nous avons notre vue MCG « Client », nous pouvons appliquer ses principes pour notre cas pratique. Nous commençons par définir les données client que nous voulons stocker. Dans notre cas, les attributs choisis sont :

Données client

Titre

Nom

Adresse

N° Téléphone

Date de naissance

Sexe

Situation familiale

Détails enfants

Détails épouse

Revenue mensuel

Loisirs et intérêts

Profession

Détails employeur

Ces attributs doivent être divisés en deux types :

Les attributs qui sont relativement statiques (où dont les anciennes valeurs peuvent être supprimées),

Les attributs qui changent de valeur.

Conception d’un Datawarehouse orienté CRM

Données client statiques

 

Titre

Nom

N° Téléphone

Date de naissance

Sexe

Données client dynamiques

 

Adresse

Situation familiale

Détails enfants

Détails épouse

Revenu mensuel

Loisirs et intérêt

Profession

Détails employeur

Construisons maintenant notre vue « Client » du modèle conceptuel global « ETS Boissons »:

Situation Adresses familiale Enfants Epouse Client Revenu Loisir/Intérêt Profession Employeurs
Situation
Adresses
familiale
Enfants
Epouse
Client
Revenu
Loisir/Intérêt
Profession
Employeurs

Figure 4.2.7 : MCG « ETS Boissons » 1/3 : Vue détaillée « Client » : les circonstances

Conception d’un Datawarehouse orienté CRM

Le modèle comportemental sera le suivant :

Ventes boissons Client
Ventes boissons
Client

Figure 4.2.8 : MCG « ETS Boissons » 2/3 : Vue globale « Client » : le comportement

Maintenant, il faut détailler le point relatif aux « segments dérivés ». Voici quelques exemples que nous pouvons appliquer pour l’« ETS Boissons » :

Durée de vie : une bonne classification que toute entreprise doit avoir.

Promotions spéciales : c’est un bon exemple de segment qui peut être très efficace. Si un jour, l’« ETS Boissons » voudrait augmenter les ventes d’une boisson spécifique, elle serait capable de déterminer quel client est susceptible d’acheter ce produit. Cela impliquerait l’analyse préalable des précédents comportements et circonstances.

Notre modèle de segments dérivé sera comme suit :

Promotions spéciales Figure 4.2.9 : MCG « ETS Boissons » 3/3 : Vue détaillée «

Promotions

spéciales Promotions Figure 4.2.9 : MCG « ETS Boissons » 3/3 : Vue détaillée « Client »
spéciales

Figure 4.2.9 : MCG « ETS Boissons » 3/3 : Vue détaillée « Client » : les segments dérivés

Durée de vie

Durée de vie Client

Client

Ainsi, en rassemblant les trois modèles des vues détaillées, nous aboutissons à un modèle conceptuel général d’un datawarehouse orienté client appliqué à un cas pratique. Ce modèle nous accompagnera dans le reste de cette étude.

Remarquez que dans cette conception globale, nous nous sommes intéressés uniquement à la dimension « Client » car par rapport aux datawarehouses classiques, les datawarehouses orientés CRM diffèrent surtout par la manière de traiter cette dimension « Client ».

Nous allons maintenant aborder la construction du modèle conceptuel détaillé.

Conception d’un Datawarehouse orienté CRM

4.3. La méthode du point et la modélisation conceptuelle détaillée

Dans cette section, nous allons commencer par exprimer le besoin d’adopter une méthode de modélisation adaptée aux projets datawarehouses de deuxième génération orientés CRM. Ensuite, nous allons présenter la méthode du point en général sans rentrer dans les détails et nous terminons par la construction du modèle conceptuel détaillé de notre solution Datawarehouse orienté CRM pour l’« ETS Boissons » en se basant sur le modèle conceptuel général (MCG) que nous avons élaboré dans la section précédente.

Nous rappelons que pour pouvoir concevoir un datawarehouse de deuxième génération orienté CRM, nous devons traiter les éléments de modélisation suivants :

Le diagramme conceptuel global orienté « Client » (Modèle orienté « Client ») ;

Les circonstances changeantes et non-changeantes des clients ;

Le comportement des clients ;

Les segments dérivés.

Enfin, notre modèle conceptuel doit être capable de gérer les données temporelles pour chaque élément de conception. Nous allons aussi traiter les changements causals et les dépendances entre les données à capturer. Enfin, nous précisons que cette section s’inspire des travaux de Chris Todman, publiés dans son livre “Designing a Datawarehouse Supporting CRM”; Édition Prentice Hall; 2001.

4.3.1. La limite des méthodes traditionnelles

Le modèle conceptuel de données d’un datawarehouse doit :

Etre simple à comprendre et à utiliser par des non-informaticiens ;

Etre conforme au MCG ;

Supporter les données temporelles.

Le type de modélisation généralement utilisée pour ce type de modèle est l’entité-relation (ER). Ces modèles sont bien maitrisés par les informaticiens mais ils sont, en revanche, difficiles à comprendre par les non-informaticiens. Les modèles « ER » sont sémantiquement très riches et ils sont bien adaptés pour modéliser les systèmes opérationnels. En réalité, pour pouvoir modéliser un système décisionnel, nous n’avons pas besoin de toute cette richesse

Conception d’un Datawarehouse orienté CRM

sémantique mais nous avons plutôt besoin d’un modèle simple, facilement compréhensible par les non-informaticiens et surtout être adapté aux concepts des systèmes décisionnels.

Comme nous le savons déjà, les datawarehouses ne sont pas conçus pour supporter les applications opérationnelles telles que la gestion des ventes où la gestion des stocks. Ils sont conçus pour assister les responsables dans leurs processus de prise de décision. Généralement, les utilisateurs sont incapables d’exprimer clairement leurs besoins en information. Ces utilisateurs savent qu’ils ont des problèmes mais ils ne connaissent pas leurs origines. D’un autre côté, les managers ont des objectifs à atteindre. Leurs performances sont mesurées à l’aide d’indicateur clé de performance (KPI : Key Performance Indicator). Un datawarehouse pourrait aider les décideurs à atteindre leurs objectifs s’ils sont capables d’exprimer précisément les informations dont ils ont besoin pour prendre les bonnes décisions. Nous avons besoin d’un modèle qui permet l’expression du besoin d’une manière participative. Les utilisateurs doivent être capables de construire, valider, modifier et même remplacer par eux-mêmes le modèle conceptuel. Ceci dit, le modèle doit être aussi riche et puissant et permettre ainsi de spécifier les caractéristiques techniques des données afin que les informaticiens puissent développer le modèle logique des données.

a. Le traitement du comportement :

Les besoins temporels des données comportementales (les faits) sont très simples. Une fois enregistrées, ces données ne changent pas. Les faits comportementaux sont dérivés d’une entité opérationnelle qui a atteint un état particulier. Le changement de l’état est causé par un évènement qui s’est produit à un instant donné. Donc, un des attributs du « fait » sera un attribut de « temps » (combinaison Date/Heure). L’attribut « temps » enregistre les informations temporelles lors de la réalisation de l’évènement. Cet attribut sera utilisé de deux manières :

Comme un paramètre d’une contrainte de sélection dans une requête,

Comme un moyen pour joindre les dimensions à des groupements hiérarchiques.

Pour chaque évènement ou changement, nous associons une donnée « temps ». Le besoin en granularité du « temps » diffère d’une application à une autre. Certaines applications ont

Conception d’un Datawarehouse orienté CRM

simplement besoin du « jour » comme la granularité du temps la plus fine. Nous pouvons citer comme exemple :

Vente des voitures des constructeurs pour une compagnie d’assurance,

Analyse des balances comptables d’une banque,

Analyse de ventes des produits dans un hypermarché.

D’autres applications ont besoin d’un grain plus fin qui peut-être l’« heure ». Par exemple :

Analyse du comportement des clients dans un hypermarché,

Contrôle du volume du trafic des voitures.

D’autres applications ont besoin de plus qu’un unique grain de temps. En analysant les exemples précédents, nous nous apercevons qu’au niveau des hypermarchés, nous avons besoin de deux différents granules de temps pour l’analyse des ventes et pour l’analyse du comportement. Toutes les analyses dimensionnelles auront besoin de différents niveau d’agrégation des ces données suivant l’axe du temps.

b. Le traitement des circonstances - rétrospections :

Dans la première génération des datawarehouses dimensionnels, la manière de traiter une valeur d’attribut de dimension en respectant les valeurs antérieures dépend entièrement des besoins liés au partitionnement temporel des faits. Le rôle principal des attributs de dimension est de servir comme contraintes dans les requêtes. Les besoins en partitionnement temporel n’ont pas été convenablement traités dans les datawarehouses de première génération. Principalement, les attributs de dimension existent pour être des paramètres de contraintes de requêtes sur les faits, même si 80 % des requêtes exécutées sont des requêtes de navigation dimensionnelle. Ce n’est que depuis l’émergence du CRM, que nous avons constaté que même les dimensions doivent contenir des données importantes sur l’entreprise comme par exemple la croissance de la clientèle (dimension « Client »). Dans certaines industries, comme dans le secteur des télécommunications, cela devient une impérative. Notre MCG de base (Modèle Conceptuel Général), en étant orienté client, permettra de répondre à des requêtes riches et complexes sur les circonstances clients, bien plus que le permet un modèle traditionnel. De ce fait, le MCG nous impose de traiter en profondeur les aspects non-dimensionnels des clients ; Ce que nous appelons : les circonstances et les segments dérivés.

Conception d’un Datawarehouse orienté CRM

Aussi, chaque composant du modèle qui est sujet à des changements dans le temps doit être évalué pour définir la manière de traiter les valeurs « historiques ». Un composant peut être :

Une entité : un ensemble de circonstances ou une dimension entière.

Une relation : exemple, hiérarchie.

Un attribut : exemple, l’adresse du client.

Pour chaque composant, nous donnons une classification que nous appelons la rétrospection du composant. La rétrospection possède trois valeurs possibles :

Vrai,

Faux,

Permanent.

Une rétrospection dont la valeur est « Vrai » signifie que le composant doit pouvoir nous restituer son historique. Il permet de retourner des enregistrements temporels des données reflétant un partitionnement historisé des valeurs. Chaque valeur de dimension, de relation et d’attribut aura ainsi une durée de vie déterminée.

Une rétrospection dont la valeur est « Faux » signifie que la vision de l’historique sera altérée si les valeurs de données de l’objet changent. En d’autres termes, quand les changements subviennent, les anciennes valeurs seront écrasées et définitivement perdues, comme si les anciennes valeurs n’ont jamais existé.

Une rétrospection dont la valeur est « Permanent » signifie que la valeur de donnée de l’objet ne change jamais.

- La rétrospection et les entités (les dimensions)

La valeur de la rétrospection se rapporte à l’existence de la dimension. Par exemple,

l’existence du client commence avec sa première commande chez l’« ETS Boissons » et l’existence se termine lorsque le client devient inactif.

Rétrospection = Vrai : signifie que la durée de vie de l’entité consiste en un ou plusieurs intervalles de temps. Un client peut ne pas avoir une seule durée de vie continue. Cela reste aussi vrai pour la dimension « Boisson ». Une boisson peut être disponible pendant des intervalles de temps spécifiques, ou la durée de vie entière est ponctuée par des périodes pendant lesquelles une boisson n’est pas disponible.

Conception d’un Datawarehouse orienté CRM

Rétrospection = Faux : signifie que seul l’état actuel de l’existence de l’entité est enregistré. Un exemple pour l’« ETS Boissons » peut être la dimension « Fournisseur ». Il y aurait peut- être le besoin d’être capable de distinguer entre les fournisseurs actuels et les anciens fournisseurs. Pour cela, nous n’avons pas besoin d’enregistrer les périodes de temps pendant lesquelles un tel fournisseur livrait ses boissons à l’« ETS Boissons » en distinguant les autres périodes d’inactivité du fournisseur.

Rétrospection = Permanent : signifie que l’entité existe indéfiniment.

- La rétrospection et les relations

Dans un modèle dimensionnel, le type de cardinalité est toujours « un à plusieurs ». Quand la relation devient temporelle, à cause du besoin d’avoir une rétrospection sur elle, la cardinalité peut devenir « plusieurs à plusieurs ». Il est important que cette information soit ajoutée au modèle sans y ajouter de complexité. La situation avec les relations est similaire avec les entités. C’est l’existence et la durée de vie de la relation qui déterminent la valeur de la rétrospection dans les relations.

Rétrospection = Vrai : signifie que la durée de vie de chaque relation doit être enregistrée et historisée pour que les résultats des requêtes reflètent fidèlement le passé. Dans notre étude de cas, citons l’exemple de la relation entre « Client » et « Région des ventes ». Si un client change de région, il est important que l’ancienne relation de ce client avec l’ancienne région soit gardée.

Rétrospection = Faux : signifie que seules les relations actuelles doivent être enregistrées. Le système n’a pas besoin de garder les anciennes relations. Un exemple de ça est la relation entre « Client » et « Loisirs ». Si les loisirs d’un client changent, nous n’avons pas besoin de garder la trace des anciennes relations.

Rétrospection = Permanent : signifie que la relation ne change jamais.

- La rétrospection et les attributs

Chaque attribut du modèle doit être évalué afin de déterminer s’il a besoin ou non d’un support temporel. Donc, une des propriétés de l’attribut est sa valeur de rétrospection. Et

Conception d’un Datawarehouse orienté CRM

comme dans le cas des autres objets de données, ce besoin ne doit pas ajouter une complexité signifiante au modèle de données.

Rétrospection = Vrai : signifie que nous devons enregistrer et garder toutes les valeurs d’un attribut sur l’axe du temps. Notre exemple sera le « Coût » d’une bouteille de boisson. Comme ce coût change dans le temps, nous devons enregistrer le nouveau coût sans perdre les anciens.

Rétrospection = Faux : signifie que seulement la dernière valeur de l’attribut est sauvegardée. Quand la valeur de l’attribut change, la nouvelle valeur remplace l’ancienne valeur et celle-ci est perdue définitivement.

Rétrospection = Permanent : signifie que la valeur de l’attribut ne change jamais.

- La rétrospection et notre étude de cas :

Dans le tableau suivant, nous listons quelques éléments de données : entités, relations et

attributs de l’« ETS Boissons ». Pour chaque élément, nous donnons une valeur de rétrospection qui satisferait les besoins.

Nom de l’objet

Type

Rétrospection

Raison

Client

Entité

Vrai

Les clients peuvent avoir plusieurs intervalles d’activité. Il est important d’étudier le comportement des clients dans le temps.

Région_Ventes

Entité

Faux

Uniquement la dernière instance est requise. Les régions peuvent être fusionnées ou éclatées. Seule la dernière structure a un intérêt.

Loisirs

Entité

Permanent

Les loisirs, une fois saisis, ne changeront jamais.

Région_V – Client

Relation

Vrai

Il y’a un besoin d’analyser les performances des régions. Et comme les clients changent de régions, nous devons garder l’historique des relations.

Loisirs – Client

Relation

Faux

Seule le loisir actuel est gardé.

Client – Ventes

Relations

Permanent

La relation entre une vente et un client implique que cette vente ne change jamais.

Client.Code_Client

Attribut

Permanent

Attribut clé.

Client.Nom_client

Attribut

Faux

La dernière valeur est suffisante.

Conception d’un Datawarehouse orienté CRM

Nom de l’objet

Type

Rétrospection

Raison

Client.Adresse

Attribut

Vrai

Analyse détaillé par zone ramenée au niveau ville.

Client.Date_affiliation

Attribut

Faux

La dernière valeur est suffisante.

La liste complète des éléments de données du modèle conceptuel de l’« ETS Boissons » est fournie en Annexe 1.

4.3.2. La causalité des changements sur les données

Durant l’analyse des changements sur les valeurs des données, nous devons analyser les causalités existantes entre elles. Il serait suffisant d’identifier les changements causales et d’assumer que les autres changements non identifiées sont non-causales. Cela facilitera la tâche des concepteurs. Comme nous l’avons déjà expliqué, les changements peuvent toucher des attributs ayant une rétrospection avec la valeur « Faux » mais qu’ils ont, du fait qu’ils sont déterminants, un effet sur d’autres attributs qui ont une rétrospection avec la valeur « Vrai ». La capture de ces changements doit être automatisée. Certains mécanismes sont créés pour permettre l’identification des changements au niveau des systèmes opérationnels qui représentent la source de données du datawarehouse. Par exemple, au niveau du SI de l’« ETS boissons » existe une relation entre l’adresse du client et la région de ventes à qui l’adresse appartient. Donc, nous pouvons dire que l’adresse du client détermine la région de ventes. Cette relation est la même utilisée dans le processus de normalisation. Cependant, le but ici est différent et il concerne la synchronisation des changements sur les valeurs des attributs afin d’assurer une consistance temporelle. Ainsi, le terme « causalité » est adopté afin de distinguer ce besoin qui est spécifique au datawarehousing. Le système opérationnel qui enregistre les données détaillées des clients ne se soucie pas des régions de ventes. Quand un client déménage, le fait qu’un changement de région doit être constaté n’est pas apparent. Les concepteurs du datawarehouse doivent gérer ce problème. Sans cela, le datawarehouse peut enregistrer des données inconsistantes. Si l’adresse d’un client change, la région doit être contrôlée et mise à jour et cela, si nécessaire, à l’instant même du changement de l’adresse. Quand les données relatives aux adresses et aux régions se trouvent dans des systèmes sources différents, la synchronisation des ces changements devient difficile à implémenter. Si la synchronisation n’est pas réalisée, certaines requêtes invoquant l’historique des ces attributs peuvent donner des résultats incohérents.