République Algérienne Démocratique et Populaire

Transcription

1 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

2 Remerciements 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.

3 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

4 Sommaire Lexique... VI 1. Introduction Les systèmes décisionnels «datawarehouses» Les systèmes d information décisionnels Qu'est-ce que le décisionnel? Positionnement du décisionnel au sein du SI Les différentes composantes du décisionnel Le système datawarehouse Définition du datawarehouse L architecture globale du datawarehouse Définition des concepts Le fonctionnement du système datawarehouse Les modèles de données du datawarehouse Caractéristiques d utilisation : OLTP vs OLAP Les techniques de modélisation Le système datawebhouse L'impact du Web sur le datawarehouse Objectifs du datawebhouse De et vers le Web Amener le Web au datawarehouse Amener le datawarehouse au Web La gestion du «Temps» dans le datawarehouse Le rôle des données temporelles Les problématiques liées au «Temps» Le temps dans la première génération des datawarehouses CRM : Customer Relationship Management Introduction au CRM Définition du CRM Les objectifs du CRM Les résultats constatés avec le CRM...34

5 3.2. Les facteurs du CRM Le facteur humain Le facteur organisationnel Le facteur technologique Le cycle de vie du client Le développement de la relation client Les étapes du développement Les raisons de la prédominance de la relation client Les fonctionnalités offertes par les systèmes CRM E-Commerce et la gestion de la relation client via Internet Le CRM sur Internet Choisir le bon moyen de communication Les trois règles de succès sur la route du e-commerce Les composants du CRM Les systèmes et données en provenance de l ERP Les bases de données externes Les canaux d interaction Le datawarehouse La technologie du datawarehouse comme base pour le CRM Conception d un datawarehouse orienté CRM Etude de cas : présentation de «ETS Boissons» Le modèle conceptuel général (MCG) orienté CRM Comportement client et circonstances client : le cause-à-effet Le modèle conceptuel général «ETS Boissons» La méthode du point et la modélisation conceptuelle détaillée La limite des méthodes traditionnelles La causalité des changements sur les données Le modèle du «point» La construction du modèle conceptuel détaillé «ETS Boissons» La modélisation logique du datawarehouse orienté CRM L implémentation de la rétrospection Choisir la solution d implémentation Le schéma logique relationnel «Clients»...90

6 Les contraintes de la rétrospection L implémentation physique du système L architecture physique du datawarehouse orienté CRM La couche VIM L alimentation du datawarehouse Le modèle physique de données Les applications CRM Synthèse sur l architecture du système Les produits logiciels Les produits ETL Les produits OLAP Les outils de restitution Le Datamining Conclusion et perspectives Références Bibliographiques...123

7 Sommaire des figures Chapitre 2 : Les systèmes décisionnels «Datawarehouses» Figure : Une vision transversale de l entreprise...4 Figure : Le décisionnel au sein du système d information...5 Figure : Les différents composants du décisionnel...5 Figure : L architecture du datawarehouse...8 Figure : L architecture du système décisionnel...8 Figure : L acquisition des données...12 Figure : Le processus d acquisition des données...13 Figure : L alimentation des datamarts...13 Figure : La restitution des données...14 Figure : Le modèle de données normalisé...17 Figure : Le modèle de données dénormalisé...18 Figure : Le modèle de données en étoile...20 Figure : Le modèle de données en flocon...21 Figure : Le client, le site Web et le datawebhouse...22 Figure : Les deux facettes du datawebhouse...23 Figure : Exemple de datamart du «Clickstream»...25 Chapitre 3 : CRM : Customer Relationship Management Figure : L évolution des composantes d entreprise...32 Figure : Les objectifs du CRM...34 Figure : Les résultats constatés...34 Figure : Les relations CRM Datawarehouse...49 Chapitre 4 : Conception d un datawarehouse orienté CRM Figure : Le modèle général initial en étoile «ETS Boissons»...53 Figure : Rappel : le modèle conceptuel général «ETS Boissons»...54 Figure : MCG : Vue globale «circonstances client changeantes»...57 Figure : MCG : Vue détaillée «circonstances client changeantes»...58 Figure : MCG : Vue globale «Client»...58 Figure : MCG «ETS Boissons» : Vue détaillée «Client»...59

8 Figure : MCG : Vue globale complète «Client»...59 Figure : MCG «ETS Boissons» 1/3 : Vue détaillée «Client»...61 Figure : MCG «ETS Boissons» 2/3 : Vue détaillée «Client»...62 Figure : MCG «ETS Boissons» 3/3 : Vue détaillée «Client»...62 Figure : Le modèle du point...71 Figure : Le modèle du point comportemental «ETS Boissons»...71 Figure : Exemple d un modèle du point d une compagnie de télécom...74 Figure : Le modèle comportemental initial...76 Figure : Le modèle du point comportemental affiné «ETS Boissons»...77 Figure : L implémentation de la rétrospection en utilisant...88 Figure : Le schéma logique des circonstances «clients»...90 Figure : L architecture EASI du système...96 Figure : Le modèle des métadonnées de validation...99 Figure : Le modèle des métadonnées de transformation Figure : Le modèle des métadonnées de mappage Figure : Le modèle complet des métadonnées de la couche VIM Figure : L extraction et le chargement des données Figure : Le rafraîchissement des données Figure : Le modèle physique des circonstances «Clients» non-changeantes Figure : Le modèle physique des circonstances «Clients» changeantes Figure : Le modèle physique du comportement Figure : Le modèle physique des segments dérivés Figure : Le processus ETL...112

9 Lexique 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. 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.

10 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étadonné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.

11 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).

12 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). ML (etensible 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.

13 Chapitre 1 Introduction n Introduction générale ; n Problématique ; n Contribution ; n Présentation du mémoire.

14 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 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. 14

15 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. 15

16 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. 16

17 Chapitre 2 Les systèmes décisionnels «Datawarehouses» 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.

18 Les systèmes décisionnels «datawarehouses» 2. Les systèmes décisionnels «datawarehouses» 2.1. Les systèmes d information décisionnels 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 : Une vision transversale de l entreprise [source : Goglin1998] Cette vue intégrée peut alors être étudiée par fonction ou par métier. 18

19 Les systèmes décisionnels «datawarehouses» 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 : Le décisionnel au sein du système d information [source : Goglin1998] 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 : Les différents composants du décisionnel [source : Goglin1998] 19

20 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. 20

21 Les systèmes décisionnels «datawarehouses» 2.2. Le système datawarehouse 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] 21

22 Les systèmes décisionnels «datawarehouses» L architecture globale du datawarehouse Le schéma suivant illustre l architecture générique d un système datawarehouse : Figure : 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 : 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. 22

23 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, ) 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. 23

24 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. 24

25 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. 25

26 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é 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 OLTP DWH Figure : L acquisition des données Acquisition de 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. 26

27 Les systèmes décisionnels «datawarehouses» Administrer * Planifier * Surveiller Découvrir Méta données Fédérer Charger Extraire Transporter Transformer Figure : 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) Finance Commercial DWH RH Figure : L alimentation des datamarts. 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. 27

28 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 : Reporting Data marts Cube analysis Data warehouse Requêtage Data mining Figure : La restitution des données 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 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. 28

29 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 29

30 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 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 ; 30

31 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 ID_Gamme Libellé Obj_marge TVA ID Date Taux Produit ID_Produit Nom Code_pays Caract. Prix HT Coût standard Fournisseur ID_Fourn Nom LG_CDE ID_cde No_ligne ID_Produit Quantité Remise Pays Code_pays Libellé Commande ID_cde ID_exp ID_Client Date Remise_gale Client ID_Client Nom Adresse Code_pays Expéditeur ID_Exp Code_pays Nom Figure : Le modèle de données normalisé 31

32 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 : Produit ID_produit Gamme CA année n-1 CA année n Provenance Coût standard ID_fourn Fournisseur ID_fourn Nom Pays... LG_CDE ID_cde No_ligne PHT PTTC ID_prod Pays Remise Commande ID_cde PHT PTTC Expéditeur Remise ID_client Client ID_client Nom Adresse Code_pays Figure : 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 32

33 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. 33

34 Les systèmes décisionnels «datawarehouses» Dimensions Produit ID_Produit Nom Gamme Resp Coût standard Packaging Couleur Table des métriques (Faits) Ventes ID_prod ID_fourn JJ MM YYY ID_client Fournisseur ID_Fourn Nom Dept Type Nationalité Dimensions Période JJ MM YYY Jour_sem Sem. mois Sem. trimestre Sem. année Mois CA Marges Unités Client ID_Client Nom Région Age Figure : Le modèle en étoile 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. 34

35 Les systèmes décisionnels «datawarehouses» Chef produit ID_cp Nom Prénom Remarque Couleur ID_coul Nom Produit ID_produit ID_famille ID_cp ID_couleur Désignation Coût standard Ventes ID_prod ID_fourn JJ MM YYY ID_client Fournisseur ID_fourn Nom Dept ID_type ID_Orig Type ID_type Nom Origine ID_orig Nationalité Gamme ID_gamme Nom Fourchette prix Saison ID_saison Nom Remarques Mois MM Nom Activité ID_famille ID_gamme Fourchette prix Période JJ MM YYY Code_jour ID_semaine ID_mois CA Marges Unités Client ID_client Nom, ID_région ID_activité ID_segment Région ID_région Nom Activité ID_activité Désignation Année ID_année Remarques Semaine ID_semaine Semaine Jour_sem Code_jour Nom Segment ID_segment Segment Figure : Le modèle en flocon 2.4. Le système datawebhouse [Source : Kimball/Merz2000] 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 35

36 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 : Le client, le site Web et le datawebhouse [source : Kimball/Merz2000] Nous appelons cette renaissance de datawarehouse le datawebhouse 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 ; 36

37 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 De et vers le Web Comme nous allons le voir, le datawebhouse a deux facettes : Figure : 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 37

38 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é 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 : 38

39 Les systèmes décisionnels «datawarehouses» Dimension page: (URL), Dimension date ; Dimension agent de l'utilisateur, Dimension session ; Dimension état du caddie de l'utilisateur, Dimension démographique. Le modèle du datamart est le suivant : Figure : Exemple de datamart du Clickstream [source Kimball/Merz2000] 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. 39

40 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 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. 40

41 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 41

42 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 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 42

43 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 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 43

44 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. 44

45 Chapitre 3 La gestion de la relation client 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.

46 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 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. 46

47 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 : L évolution des composantes d entreprise. [Source : Flueckiger2000] 47

48 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 interentreprises. 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 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] 48

49 Le CRM : Customer Relationship Management Remarquons par exemple que 50% des entreprises ayant implémenté une solution CRM se sont fixées comme objectif Figure l amélioration : Les objectifs de la satisfaction du CRM. des [Source clients : Flueckiger2000] Les résultats constatés avec le CRM Examinons le graphique ci-dessous : Figure : Les résultats du CRM. [Source : Flueckiger2000] 49

50 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 Les facteurs du CRM Le CRM prend forme en tirant parti du potentiel des composantes humaines, organisationnelles et technologiques à disposition 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] 50

51 Le CRM : Customer Relationship Management 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] 51

52 Le CRM : Customer Relationship Management 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 , 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] 52

53 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 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. 53

54 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] 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 euxmê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. 54

55 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. 55

56 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. 56

57 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 : 57

58 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 / s Marketing Service Interface Planification / Prévision annuelle Marketing direct Database marketing Segmentation du marché Telemarketing / Callcenter Gestion des compagnes Encyclopédie marketing Controlling E-Marketing Planification / prévision annuelle Teleservice / Callcenter Help Desk Gestion des réclamations Gestion de la qualité Service clients technique E-Service Configuration produit MS Office (Word, Excell, ) Lotus Notes ERP Datawarehouse OLAP Workflow Gestion des documents SI géographique 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] 58

59 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 , 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 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] 59

60 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). 60

61 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 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? est-ce que votre adresse 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? 61

62 Le CRM : Customer Relationship Management 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 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. 62

63 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 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 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 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. 63

64 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 mais devront Figure être 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. 64

65 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 65

66 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. 66

67 Chapitre 4 Conception d un datawarehouse orienté CRM 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.

68 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. 68

69 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 : Boisson Gestionnaire Compte Ventes Client Dépôt Temps Figure : 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. 69

70 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» : Boisson Gestionnaire Compte Ventes Client Dépôt Temps Figure : Rappel : le modèle conceptuel général initial «ETS Boissons» 70

71 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 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. 71

72 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. 72

73 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 Figure : 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. 73

74 Conception d un Datawarehouse orienté CRM Le modèle sera comme suit : Client Adresse Situation familiale Ainsi, Figure on garde la : MCG trace des : Vue changements détaillée «d adresses circonstances et de la Client situation changeantes familiale.» 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 changeantes Figure : 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 : 74

75 Conception d un Datawarehouse orienté CRM Adresse Ventes boissons Client Situation familiale Figure : 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 Client Client Circonstances changeantes Segments dérivés Figure : 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. 75

76 Conception d un Datawarehouse orienté CRM 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. 76

77 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»: Adresses Situation familiale Enfants Epouse Client Revenu Loisir/Intérêt Profession Employeurs Figure : MCG «ETS Boissons» 1/3 : Vue détaillée «Client» : les circonstances 77

78 Conception d un Datawarehouse orienté CRM Le modèle comportemental sera le suivant : Client Ventes boissons Figure : 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 : Durée de vie Client Promotions spéciales Figure : MCG «ETS Boissons» 3/3 : Vue détaillée «Client» : les segments dérivés 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é. 78

79 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; 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 79

80 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 80

81 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. 81

82 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. 82

83 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 83

84 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. 84

85 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 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. 85

86 Conception d un Datawarehouse orienté CRM Le modèle du «Point» a. La modélisation par les points [Source : Todman2001] Dans ce qui suit, nous allons présenter une méthodologie de développement des modèles conceptuels pour les datawarehouses. Cette méthodologie est appelée : la méthode du point (en Anglais : Dot Modeling ). La méthode du point est basée sur les pré-requis simplifiés des modèles dimensionnels qui ont été décrits dans le chapitre sur les datawarehouses. C est une méthodologie complète qui permet aux non-informaticiens de construire leurs propres modèles conceptuels qui reflètent leur perception de l entreprise d une manière dimensionnelle. Elle fournit aussi une approche structurée pour la construction du modèle logique (généralement relationnel) à partir du modèle conceptuel. La méthode est apparue en 1997 et elle est, depuis cette date, utilisée dans des projets réels. Elle a reçu des opinions positives des personnes qui l ont utilisée. Le nom a été donné par un utilisateur. Cette dénomination (le point) vient du fait que le centre de la partie comportementale du modèle, les faits, sont représentés par un point. La méthode est apparue comme une sorte d évolution de l utilisation des concepts dimensionnels et elle a évolué pour s adapter aux besoins des modèles orientés clients. Nous commençons par modéliser le comportement. La figure suivante représente la conception d un rapport sous forme d un tableau à deux dimensions. Ce type de rapport est familier et est souvent utilisé pour la restitution des données. Rapport des ventes Produit Client L intersection des deux axes, qui est représenté par un point, contient des données sur la vente d un produit spécifique à un client spécifique. La donnée représentée par le point est généralement numérique. Elle peut être atomique, comme le montant de la vente, ou complexe et peut aussi inclure d autres valeurs comme l unité de vente et le profit dégagé. 86

87 Conception d un Datawarehouse orienté CRM Pour pouvoir représenter plus de trois dimensions dans la méthode du point, le point est placé au centre du diagramme et les dimensions sont ajoutées autour du ledit point. Branche Client Région Produit Fournisseur Ainsi, le modèle adopte la symétrie radiale des schémas en étoile. Figure : Le modèle du point Temps b. Les composants du modèle comportemental du point : Il existe trois composants de base du modèle du point : Le point : il représente les faits. Le nom du modèle dimensionnel est appliqué aux faits. Pour l «ETS Boissons», les faits sont nommés «Ventes». Les dimensions : chaque dimension est représentée dans le modèle par un nom. Les connecteurs : ils sont placés entre les faits et les dimensions de premier niveau et entre les dimensions pour représenter leur structure hiérarchique. Le modèle comportemental de l «ETS Boissons» sera comme suit : Type Région Manager Boisson Ventes Région Vente Client Fournisseur Les attributs des faits et des dimensions Temps ne sont pas représentés sur le modèle. Les attributs Loisir sont décrits séparément du modèle. La même règle est appliquée pour les besoins temporels. Figure : Le modèle du point comportemental de l «ETS Boissons» 87

88 Conception d un Datawarehouse orienté CRM La méthode utilise plusieurs documents de travail. Le premier document représente le modèle conceptuel. Il contient : Le nom de l application ou du modèle (ici : Vente «ETS Boissons»). Le diagramme conceptuel. La liste des attributs de la table des faits (ici : «quantité» et «valeur»). Pour chaque attribut, une brève description est donnée. Le deuxième document est appelé le «document des entités». Il contient : Les dimensions comportementales. Les circonstances clients. Les segments dérivés. Pour chaque entité, les éléments suivants sont précisés : Le nom de la dimension. La valeur de la rétrospection. L attribut clé de la dimension. La fréquence des mises à jour. Pour chaque dimension, les attributs sont listés dans d autres documents. Pour chaque attribut, nous précisons : Le nom de la dimension propriétaire. Le nom de l attribut. La valeur de rétrospection. La fréquence des mises à jour. Les dépendances avec les autres attributs afin de définir les causalités. Une description de l attribut : Métadonnées. La source : d où vient cet attribut. Les transformations : préciser les transformations sur la donnée avant son transfert au datawarehouse. Type de données (ex. : numérique). Les informations sur les hiérarchies des dimensions sont précisées au niveau du document sur les hiérarchies. Le document liste les noms des composants de la hiérarchie et contient aussi : La rétrospection de la hiérarchie. 88

89 Conception d un Datawarehouse orienté CRM La fréquence de la capture. Métadonnées décrivant la hiérarchie. c. Exemple d un modèle du point complet orienté client : Un projet très intéressant a été élaboré au Royaume-Uni pour une grande compagnie de télécommunication. Leur objectif était de construire un modèle de données orienté client qui couvre tous leurs besoins. Plusieurs modèles comportementales du «point» ont été élaborés : Call Usage (Utilisation) : Les types d appels effectués, leur durée, leur coût, Payments (Règlements) : Le client a-t-il payé à temps? Combien de fois a-t-il été relancé? Recurring Revenue (Revenues récurrents) : ex. : la facturation. Nonrecurring Revenue (Revenues Non-récurrents) : ex. : Vente d accessoire. Order Fulfillment (Traitement Commandes) : Combien de temps dure le traitement des commandes clients? Service Events (Evènement de service) : Les réclamations liées au service fourni. Contacts : Chaque contact avec les clients. En termes dimensionnels, cela signifie plusieurs modèles dimensionnels, chacun traitant un sujet précis. Durant l avancement du projet, un seul modèle orienté client a été proposé et couvrant tous les objectifs de l entreprise tels que exprimés par les utilisateurs. La figure suivante illustre sept (7) modèles dimensionnels séparés partageant des dimensions. Cela montre que même dans des situations complexes, il est facile de construire des modèles dimensionnels séparés en utilisant les notations de la modélisation par le point. 89

90 Conception d un Datawarehouse orienté CRM Type Contact Type résultat Utilisation Produit Contact Tarif Base Traitement Commande Compte Type appareil Produit Revenue R Client Type collection Revenue NR Règlement Evènement Service Segments Type évènement Organisation hiérarchique Campagne Figure : Exemple d un modèle du point d une compagnie de télécom 90

91 Conception d un Datawarehouse orienté CRM La construction du modèle conceptuel détaillé «ETS Boissons» Nous allons maintenant construire notre modèle conceptuel pour l «ETS boissons» en utilisant la méthode du point présentée précédemment. Dans la pratique, cette conception sera organisée sous forme d ateliers de développement par étapes. Comme vous l avez constatez, la méthodologie du point n a pas été étudiée en détail. Comme toute méthodologie, la méthode du point se compose d un certain nombre de processus qui s enchaînent dans le but de construire le modèle conceptuel. Les ateliers de travail seront décris dans ce qui suit. Le modèle conceptuel détaillé de l «ETS Boissons» sera fournit en annexe (Annexe 1). a. Atelier 1 : Stratégie de l information L objectif de cet atelier est de permettre aux utilisateurs de développer leur propre modèle qui reflète leur propre perception de leur environnement. L équipe de travail sera composé de consultants experts, utilisateurs clés et des techniciens IT. Le rôle principale des consultants est superviser l atelier, d animer les discutions et d aider l équipe client dans leur processus de conception. La présence d un responsable senior est préconisée. N oublions pas que le facteur clé de succès d un projet datawarehouse est de se concentrer sur le métier et non pas sur la technologie. L atelier commence par définir clairement les objectifs de l entreprise. Ces objectifs doivent être : Mesurables, Limités dans le temps, Orientés clients. Exemple : Augmenter la fidélité client de 5% dans les 3 prochaines années. - Le modèle initial Après une brève explication de la modélisation par le point, les participants commencent à exprimer par le dessin leur vision du système. Nous aurons un modèle qui ressemblerait à ça : 91

92 Conception d un Datawarehouse orienté CRM Revenue Manager Boisson Profession Ventes Région Vente Fournisseur Temps Client Figure - Le comportement : Le modèle comportemental initial Nous expliquons aux participants la signification du point, qui est le comportement. Les attributs de ce point constitueront le noyau du système. Les faits typiques sont «la valeur» et «la quantité». Nous devons aussi inclure des faits dérivés tels que «le profit» et «le retour sur investissement» (ROI). Chaque attribut «fait» doit être numérique et sommable ou semi-sommable. Chaque fait mesurable et participant dans la mesure des objectifs doit avoir sa place dans le datawarehouse. A ce stade, des questions doivent être posées sous forme de requêtes en langage naturel afin de déterminer la manière d utiliser ce fait. Nous devons aussi connaître la granularité du temps pour chaque fait. L idéal est d opter pour la plus fine granularité possible. Généralement, tous les faits partagent la même granularité. Nous terminons par donner une description détaillée de chaque fait retenu. - Les dimensions Nous expliquons aux participants le sens de la dimension, et nous leur laissons le soin d exprimer leur besoin en dimensions. - La construction du modèle Le processus de construction doit être itératif : nous commençons par un modèle initial qui est affiné au fur et à mesure du déroulement des travaux de l atelier. Pendant la construction, les informaticiens doivent traiter les points suivants : La disponibilité des données sources, L architecture de la base de données cible, La qualité des données. L affinement du modèle se fait essentiellement par : 92

93 Conception d un Datawarehouse orienté CRM La combinaison des dimensions, La hiérarchisation des dimensions, L inclusion de certaines suggestions. Voici donc le modèle affiné de l «ETS Boissons» : Région Manager Boisson Région Vente Fournisseur Ventes Client Temps - Documenter le modèle Loisir Figure : Le modèle du point comportemental affiné de l «ETS Boissons» Le modèle est documenté en élaborant les documents de travail déjà introduits et expliqués dans ce chapitre. Parmi les documents les plus importants sont ceux liés aux entités et à la segmentation. Les entités incluent les circonstances client et les dimensions du modèle comportemental. La segmentation est en relation avec les segments dérivés, qui est la dernière composante de notre MCG. b. Atelier 2 : L analyse des composants L objectif de cet atelier et d analyser les composants du modèle créé et d y ajouter d autres éléments de détail. - Définir les attributs L objectif est de définir les attributs de toutes les dimensions du modèle. Pour cela, nous utilisons un document de travail nommé : «Entités et segments». 93

94 Conception d un Datawarehouse orienté CRM Voici donc un premier exemple concernant la dimension «Client» : Modèle du point : Entités et segments Nom entité Rétrospection Fréquence Client Vrai Mensuelle Métadonnée Cette entité contient toutes les données détaillées des clients. Nous devons suivre les cycles de vie discontinus et identifier les clients actifs et non-actifs. Un client actif est celui qui a envoyé une commande durant les derniers 12 mois. Les périodes d inactivité doivent être préservées dans le système. Nom attribut Nom Client PK? N Rétrospection Fréquence Dépendance Faux Mensuelle Non Métadonnée Le nom du client Source Transformation Type donnée ADMIN Client Non Char 25 Nom attribut Adresse client PK? N Rétrospection Fréquence Dépendance Vrai Mensuelle Région Vente Métadonnée L adresse du client Source Transformation Type donnée ADMIN client Non Char 75 Nom attribut Indicateur durée de vie PK? N Rétrospection Fréquence Dépendance Vrai Mensuelle Non Métadonnée Indicateur calculé sur la durée de vie du client. Les valeurs sont de 1 à 20. Source Transformation Type donnée ADMIN client SQL_package_crm_life_value.sql Numérique (2) 94

95 Conception d un Datawarehouse orienté CRM Le second exemple concerne la dimension «Boisson» : Modèle du point : Entités et segments Nom entité Rétrospection Fréquence Boisson Vrai Mensuelle Métadonnée La dimension «Boisson» contient les données sur les boissons vendues par l «ETS Boissons». Ces données incluent les prix et les coûts. Nom attribut Boisson.Coût_bouteille PK? N Rétrospection Fréquence Dépendance Vrai Mensuelle Non Métadonnée Le coût d une bouteille de boisson, net après discount, en TTC et en incluant toutes les charges. Source Transformation Type donnée Stock Non Numérique (7,3) Nom attribut Boisson.Taux_sucre PK? N Rétrospection Fréquence Dépendance Vrai Mensuelle Région Vente Métadonnée La contenance en sucre exprimée en pourcentage. Source Transformation Type donnée Stock Non Numérique (3,1) Et ainsi, pour chaque entité du modèle, nous élaborons le document de conception en respectant le format présenté ci-dessus et en remplissant toutes les cases. - Analyse dimensionnelle des faits Maintenant, pour chaque attribut de fait mesurable, nous examinons les dimensions y sont associées pour définir les fonctions arithmétiques standards qui peuvent y être appliquées. Cela nous permettra de distinguer entre les faits sommables et semi-sommables. Par exemple : Les quantités d un supermarché peuvent être sommées par produit et non pas par client. Les balances bancaires peuvent être sommées à un instant donné mais pas dans le temps. Le retour sur investissement (ROI) et tout autre pourcentage ne peuvent pas être sommés mais on peut déterminer le maximum, le minimum ou la moyenne. Le document édité pour ce besoin s appelle : «document d utilisation de fait». 95

96 Conception d un Datawarehouse orienté CRM Voici un exemple pour notre étude de cas : Modèle du point : utilisation fait Nom modèle : Ventes «ETS Boissons» Nom Fait : Valeur Fréquence : Journalière Dimensions Somme Comptage Moyenne Min. Max. 1. Client????? 2. Boisson????? 3. Fournisseur????? - Hiérarchies et groupements Le but ici est simplement de fournir des métadonnées pour décrire les relations entre les différents niveaux hiérarchiques des dimensions. Le document utilisé ici s appelle : «Hiérarchies et groupements». Voici un exemple : Modèle du point : Hiérarchies et groupements Nom modèle : Ventes «ETS Boissons» Région vente Client Rétrospection Vrai Fréquence Mensuelle Métadonnée Cette hiérarchie enregistre le lien qui existe entre un client et la région de vente où il réside. Le client peut déménager vers une nouvelle adresse dans une autre région de vente. 96

97 Conception d un Datawarehouse orienté CRM - La rétrospection Nous avons déjà expliqué la signification de la rétrospection et son rôle dans les modèles dimensionnels décisionnels. En pratique, il faut être capable d expliquer ce concept à l équipe du client afin qu ils puissent définir par eux-mêmes les valeurs de rétrospection pour chaque entité du modèle. Nous rappelons ici que la rétrospection est la capacité de regarder dans le passé. Chaque objet de base de données peut avoir une des trois valeurs de rétrospection suivantes : Vrai : on garde la trace des changements donc on peut remonter le passé. Faux : On ne garde que la dernière valeur. Le passé est perdu. Permanent : la valeur de change pas. - La granularité de la table «Temps» Nous avons déjà discuté la granularité du temps des faits mesurables. Maintenant, nous devons nous intéresser à la granularité temporelle des dimensions, des hiérarchies et des attributs. Nous devons aussi déterminer le contenu de la table «Temps». Nous rappelons que nous fournirons le détail de la conception dans l annexe 1. Une fois la modélisation conceptuelle terminée, nous abordons la modélisation logique de notre datawarehouse. 97

98 Conception d un Datawarehouse orienté CRM 4.4. La modélisation logique du datawarehouse orienté CRM Dans cette section, nous allons étudier les solutions d implémentation logique de la rétrospection dans les datawarehouses orientés CRM. La rétrospection est une des composantes clés de notre modèle conceptuel qui a été introduite dans la section précédente. Dans cette section, nous allons aussi présenter le modèle logique relationnel (vue «Client» uniquement) de l «ETS boissons», résultat de la transformation du modèle conceptuel. En pratique, les concepteurs ont la tendance de transiter directement du modèle conceptuel au modèle physique sans passer par le modèle logique. Cela implique l écriture du LDD (Langage de Définition de Données) à partir du modèle conceptuel. Cette pratique s est généralisée du fait que les bases de données relationnelles sont devenues la plateforme d implémentation de toutes les applications de base de données. Cela s applique aux systèmes opérationnels ainsi qu aux systèmes décisionnels. Cependant, les datawarehouses peuvent ne pas être implémentés sur des SGBD relationnels mais sur SGBD dimensionnels appelé aussi systèmes OLAP. Actuellement, il n existe pas de standard pour assister les concepteurs à produire des modèles logiques sur des systèmes OLAP propriétaires. Dans ce cas là, une certaine attention doit être accordée au processus de conception logique. Quand le système cible n est pas relationnel, il n est pas possible de produire un modèle physique sauf si les concepteurs ont une bonne connaissance du LDD propriétaire ou du processus d implémentation physique du SGBD en question L implémentation de la rétrospection Avant de passer en revue les solutions, rappelons les besoins qui doivent être satisfaits en premier : - Un «Reporting» actualisé et fiable des faits : dans un modèle dimensionnel, il est important que chaque occurrence de fait soit jointe avec la bonne occurrence dimension et avec la bonne valeur «Temps». En réalité, on reconnaît que généralement cela ne peut pas être satisfait complètement à cause des déficiences qui existent dans le processus de chargement des données opérationnels. - Une mise à jour fiable des changements de données : afin de répondre aux requêtes sur les circonstances clients et la navigation dans les dimensions. Il est important de s assurer que les périodes de validité des dimensions, des relations et des attributs soient 98

99 Conception d un Datawarehouse orienté CRM enregistrées correctement. Une fois encore, la capacité à réaliser cela dépend de la qualité et de la fiabilité des données sources. a. L utilisation des attributs d existence Nous allons maintenant étudier l utilisation des attributs d existence (cycle de vie) comme une approche d implémentation de la rétrospection. Le concept de l existence a été expliqué précédemment (Voir la section 2.5 : La gestion du «Temps» ), mais son application à tous les composants d un datawarehouse peut ne pas être entièrement claire. Le raisonnement est le suivant : Le «besoin temporel» d une entité se rapporte à son existence (i.e. Cycle de vie). Dans certaines circonstances, l existence d une entité est discontinue. Par exemple, une boisson peut être vendue par l «ETS boisson» durant une période de temps ensuite elle est suspendue et retirée des ventes. Cette boisson peut réapparaitre (ré-exister) dans le futur. Cette discontinuité dans le cycle de vie de la boisson peut avoir des conséquences sur les requêtes du genre : «Combien de lignes de produits vendons-nous actuellement?». Un autre exemple concerne les clients. Le retour des clients perdus est entrain de devenir un objectif primordial des entreprises, spécialement dans des domaines comme la télécommunication et les services financiers où la mobilité des clients est grande. Quand un client revient, il est préférable de juste l activer dans le système en gardant les anciennes données et en préservant tout son historique et non pas le créer de nouveau. Une relation qui a besoin d un «support temporel» peut être modélisée en relation n-m. En utilisant la modélisation entité-relation (ER), cette relation va se transformer en une entité intermédiaire entre les deux entités en relation. Comme le besoin temporel d une entité se rapporte à son existence, le traitement de la relation est quasiment le même que le traitement des entités. Un attribut doit réellement être considéré comme une propriété d une entité. L entité est engagée dans une relation avec un ensemble de valeurs. Cette relation est de type n-m. Un attribut qui a besoin d un «support temporel» doit être modélisé sous forme d une entité intermédiaire entre l entité principal et l ensemble de valeurs sans avoir à l ajouter sur le diagramme. Comme pour les entités et les relations, le traitement des attributs se rapporte à l existence de sa valeur pendant une période de temps. 99

100 Conception d un Datawarehouse orienté CRM Le «support temporel» de chaque élément se rapportant aux circonstances client, à la segmentation ou la structure dimensionnelle d un datawarehouse sera implémenté en utilisant les attributs d existence. Si nous avons besoin d un support temporel total, l attribut doit être composé de «la date début» et «la date fin» d existence de l occurrence et qui enregistre ainsi toutes les périodes d existence. Une valeur particulière est assignée à la date fin pour signifier une période en cours. Voici le détail de l implémentation : - Pour le support temporel d une entité qui peut avoir une existence discontinue, une table séparée est requise qui contient la clé primaire de l entité et une période d existence. Si l existence est continue, la période est incluse dans l entité principale. - Pour le support temporel d une relation entre des entités, une table séparée est requise qui contient les clés primaires des entités participantes dans la relation et une période d existence. - Pour le support temporel d un attribut d une entité, une table séparée est requise qui contient la clé primaire de l entité, une période d existence et la valeur de l attribut. Cette solution permet de résoudre beaucoup de problème lors de l exécution des requêtes. Voici quelques exemples : Combien de clients avons-nous perdus durant le dernier trimestre 2005, comparativement à 2004 et 2003? Parmi les clients perdus, combien ont existé durant au moins une année? Parmi ces clients, combien ont changé d interlocuteur à cause d un déménagement dans l année où ils nous ont quittés? Combien de changements de prix a-t-il eu dans l année où ils nous ont quittés? En utilisant notre solution, la première requête peut être exprimée comme suit : Select Q as trimestre, count(*) From CustomerExist ce Where ce.existenceend Between 01/10/2005 and 31/12/2005 Union Select Q as trimestre, count(*) From CustomerExist ce Where ce.existenceend Between 01/10/2004 and 31/12/2004 Union Select Q as trimestre, count(*) From CustomerExist ce Where ce.existenceend Between 01/10/2003 and 31/12/

101 Conception d un Datawarehouse orienté CRM La réponse à la deuxième question est la suivante : Select Q as trimestre, count(*) From CustomerExist ce Where ce.existenceend Between 01/10/2005 and 31/12/2005 And (ce.existenceend ce.existencestart) > 365 Union Select Q as trimestre, count(*) From CustomerExist ce Where ce.existenceend Between 01/10/2004 and 31/12/2004 And (ce.existenceend ce.existencestart) > 365 Union Select Q as trimestre, count(*) From CustomerExist ce Where ce.existenceend Between 01/10/2003 and 31/12/2003 And (ce.existenceend ce.existencestart) > 365 Pour répondre à la troisième question, nous supposons qu il existe un attribut d existence séparé pour la relation entre le client et la zone de vente. La requête aura la syntaxe suivante : Select Q as trimestre, count(*) From CustomerExist ce, CustomerSalesAreaExist csa Where ce.existenceend Between 01/10/2005 and 31/12/2005 And (ce.existenceend ce.existencestart) > 365 And csa.customerstart Between 01/01/2005 and 31/12/2005 Union Select Q as trimestre, count(*) From CustomerExist ce, CustomerSalesAreaExist csa Where ce.existenceend Between 01/10/2004 and 31/12/2004 And (ce.existenceend ce.existencestart) > 365 And csa.customerstart Between 01/01/2004 and 31/12/2004 Union Select Q as trimestre, count(*) From CustomerExist ce, CustomerSalesAreaExist csa Where ce.existenceend Between 01/10/2003 and 31/12/2003 And (ce.existenceend ce.existencestart) > 365 And csa.customerstart Between 01/01/2003 and 31/12/2003 And ce.customercode = csa.customercode And ce.customercode = csa.customercode And ce.customercode = csa.customercode 101

102 Conception d un Datawarehouse orienté CRM Afin de répondre à la quatrième question, nous supposons aussi qu il existe un attribut d existence séparé pour le prix de la boisson. Select Q as quarter, ce.customercode, Count(distinct spe.drinkcode) From CustomerExist ce, SalesPriceExist spe, Sales s, Time t Where ce.existenceend Between 01/10/2005 And 31/12/2005 And (ce.existenceend ce.existencestart) > 365 And ce.customercode = s.customercode And s.drinkcode = spe.drinkcode And s.timecode = t.timecode b. L utilisation de la dimension «Temps» Nous pouvons aussi utiliser la dimension «Temps» afin de simplifier l écriture des requêtes complexes. And t.year = 2003 And spe.existencestart Between 01/10/2005 And 31/12/2005 Group By quarter, ce.customercode Having Count(distinct spe.drinkcode) > 5 Union Select Q as quarter, ce.customercode, Count(distinct spe.drinkcode) From CustomerExist ce, SalesPriceExist spe, Sales s, Time t Where ce.existenceend Between 01/10/2004 And 31/12/2004 And (ce.existenceend ce.existencestart) > 365 And ce.customercode = s.customercode And s.drinkcode = spe.drinkcode And s.timecode = t.timecode And t.year = 2002 And spe.existencestart Between 01/10/2004 And 31/12/2004 Group By quarter, ce.customercode Having Count(distinct spe.drinkcode) > 5 Union Select Q as quarter, ce.customercode, Count(distinct spe.drinkcode) From CustomerExist ce, SalesPriceExist spe, Sales s, Time t Where ce.existenceend Between 01/10/2003 And 31/12/2003 And (ce.existenceend ce.existencestart) > 365 And ce.customercode = s.customercode And s.drinkcode = spe.drinkcode And s.timecode = t.timecode Cette requête And donne t.year la = liste 2001 des clients qui ont quitté l «ETS Boisson And spe.existencestart» dans le dernier trimestre de l année tout Between 01/10/2003 And 31/12/2003 en ayant eu plus de cinq changements de prix dans l année. Group By quarter, ce.customercode Having Count(distinct spe.drinkcode) > 5 Le rôle de la dimension «Temps» est de fournir un mécanisme de regroupement et d expression de contraintes sur les faits. Cependant, il est approprié de permettre aux utilisateurs du datawarehouse d exprimer des contraintes de temps sur d autres composants du modèle en utilisant la même approche que celle concernant les faits. Ralph Kimball [Source : Kimball/Ross2002] proscrit l utilisation de la dimension «Temps» avec les autres dimensions car la sémantique du temps pour les dimensions et différente de sa sémantique pour les faits et cela peut induire en erreur. Cette règle est incluse implicitement dans les modèles en étoile et en flocon puisque la dimension «Temps» est liée uniquement à la table des «Faits». Il n y a pas de relation entre la dimension «Temps» et les autres dimensions. En considérant cela, deux points émergent : 102

103 Conception d un Datawarehouse orienté CRM - Premièrement, la dimension «Temps» fournit une interface simple aux utilisateurs pour formuler les requêtes. Cette interface empêchera les utilisateurs d utiliser la dimension «Temps» avec les autres entités. - Deuxièmement, certaines requêtes de navigation dimensionnelle sont plus faciles à exprimer si les jointures sont permises entre les autres dimensions et la dimension «Temps». Revenant à la première requête de la section précédente : Combien de clients avons-nous perdus durant le dernier trimestre 2005, comparativement à 2004 et 2003? En utilisant la dimension «Temps», la requête peut être exprimée ainsi : Select t.quarter, count(*) From CustomerExist ce, Time t Where ce.existenceend = t.timecode And t.quarter in ( Q4 2005, Q4 2004, Q ) Group By t.quarter La deuxième requête : Parmi les clients perdus, combien ont existé durant au moins une année? devient en utilisant la dimension «Temps» ainsi : Select t.quarter, count(*) From CustomerExist ce, Time t Where ce.existenceend = t.timecode And t.quarter in ( Q4 2005, Q4 2004, Q ) And (ce.existenceend - ce.existencestart) > 365 Group By t.quarter La troisième : Parmi ces clients, combien ont changé d interlocuteur à cause d un déménagement dans l année où ils nous ont quittés? sera exprimée comme suit : Select t1.quarter, count(*) From CustomerExist ce, CustomerSalesArea csa, Time t1, Time t2 Where ce.existenceend = t1.timecode And t1.quarter in ( Q4 2005, Q4 2004, Q ) And (ce.existenceend - ce.existencestart) > 365 And ce.customercode = csa.customercode And csa.existencestart = t2.timecode And t2.year = t1.year Group By t1.quarter 103

104 Conception d un Datawarehouse orienté CRM La quatrième : Combien de changements de prix a-t-il eu dans l année où ils nous ont quittés? sera exprimée comme suit : Select t1.quarter, ce.customercode, Count(distinct spe.drinkcode) From CustomerExist ce, SalesPriceExist spe, Sales s, Time t1, Time t2, Time t3 Where ce.existenceend = t1.timecode And t1.quarter in ( Q4 2005, Q4 2004, Q ) And (ce.existenceend - ce.existencestart) > 365 And ce.customercode = s.customercode And s.drinkcode = spe.drinkcode And spe.existencestart = t2.timecode And s.timecode = t3.timecode And t2.year = t1.year And t3.year = t2.year Group By t1.quarter, ce.customercode Having Count(distinct spe.drinkcode) > 5 Ainsi, nous pouvons conclure qu en mettant en relation la dimension «Temps» avec les autres dimensions, l écriture de certaines requêtes temporelles devient plus simple. Voici une partie du schéma de l «ETS Boisson» modifiée pour inclure ces nouvelles relations : Client Ventes Temps Boisson Figure : L implémentation de la rétrospection en utilisant la dimension «Temps» Ce changement dans l approche conventionnelle de modélisation rend les modèles dimensionnels complexes en perdant leur figure simple. La simplicité est une condition des modèles dimensionnels. En proposant cette idée, nous avons créé un nouveau problème à résoudre. Il est important que la figure dimensionnelle simple soit préservée. En clair, nous ne pouvons pas présenter un tel modèle aux utilisateurs. La solution peut être de supprimer la dimension «Temps» du modèle. Nous avons dit que la dimension «Temps» est toujours incluse dans les modèle dimensionnel car le «Temps» est toujours une dimension d analyse dans les datawarehouses qui sont nativement «historisée». De cela, l inclusion explicite de la dimension «Temps» peut s avérer non-nécessaire et qui devient, de ce fait, implicite. Cela signifie que la présence de la dimension «Temps» sur le 104

105 Conception d un Datawarehouse orienté CRM diagramme ne sera pas explicite, mais posera un problème avec la méthodologie de modélisation conceptuelle entité-relation (ER). Avoir des entités implicites dans le modèle créera une confusion totale. La méthode du point n a pas cette limitation et sera adaptée pour répondre à ce nouveau besoin. Cependant, la dimension «Temps» possède des attributs qui sont différents d une application à une autre et ce n est pas une question qui peut être ignorée. Dans la méthode du point, nous pouvons résoudre ce problème en ajoutant une table qui va satisfaire à ces besoins précédemment couverts par une dimension «Temps» explicite. La table aura comme nom : Temps_Point (Dot_Time). La suppression de la dimension «Temps» explicite du modèle conceptuel et son ajout dans le modèle logique est une étape en avant dans l approche de conception des datawarehouses. C est une manière de reconnaître que les datawarehouses sont de vraies applications temporelles et que le support du temps est implicite dans la solution Choisir la solution d implémentation Le choix d une solution dépend des besoins et du type de datawarehouse en construction. La rétrospection fournit un mécanisme permettant aux circonstances et aux dimensions d être considérées comme une source d information. Si la nécessité de réaliser des analyses historiques sur un composant de la structure dimensionnelle est exprimée alors la valeur de rétrospection de ces composants sera «Vrai». S il y a un besoin en requêtes de durée statique ou de détection de transition alors la solution la plus appropriée est de prévoir des attributs d existence sous forme de date et heure débute et date et heure fin. 105

106 Conception d un Datawarehouse orienté CRM Le choix d une solution se fait suivant le tableau ci-dessous : Val. Circonst. /Dimensions Relations Attributs Vrai Besoin d analyse de durée statique ou de détection de transition? Besoin d analyse de durée statique ou de détection de transition? Besoin d analyse de durée statique ou de détection de transition? Oui Non Oui Non Oui Non Période d existence Marque de temps Période d existence La hiérarchie change-telle souvent? La change-t-elle souvent? hiérarchie Oui Non Oui Non Période d existence Marque de temps Période d existence Marque Faux Attribut d existence Vrai/Faux Attribut d existence Vrai/Faux Attribut d existence Vrai/Faux Perm. Pas de changement Pas de changement Pas de changement de temps Marque de temps Le schéma logique relationnel «Clients» L implémentation d une rétrospection en «Vrai» pour une entité, un attribut ou une relation nécessite l existence d une durée de vie de l objet. Cela doit être implémenté sous forme d une période marquant une «date début» et une «date fin». L introduction de telles périodes change la structure des entités. Par exemple, les circonstances client ont une rétrospection en «Vrai» dans le modèle de l «ETS Boisson». Elle est aussi en «Vrai» pour les relations entre les circonstances client d un côté et les régions de vente et les adresses client de l autre côté. Les périodes d existence doivent être ajoutées à ces objets comme le montrera le schéma et les tableaux suivants. Loisirs Existence Adresse client Client Existence Client Région Ventes Client Région Ventes Figure : Le schéma logiques des circonstances «Clients» Chaque relation du modèle sera décrite dans ce qui suit : 106

107 Conception d un Datawarehouse orienté CRM Relation : Client Code_Client Nom_Client Code_Loisirs Date_Création Clé primaire(code_client) Clé étrangère(code_loisirs référence Loisirs.Code_Loisirs) Relation : Existence Client Code_Client Exist_Client_Début Exist_Client_Fin Clé primaire(code_client, Exist_Client_Début) Clé étrangère(code_client référence Client.Code_Client) Relation : Existence Adresse Client Code_Client Exist_Adr_Client_Début Exist_Adr_Client_Fin Adresse_Client Clé primaire(code_client, Exist_Adr_Client_Début) Clé étrangère(code_client référence Client.Code_Client) Relation : Région Vente Client Code_Client Code_Région_Vente Exist_Code_Région_Vente_Début Exist_Code_Région_Vente_Fin Clé primaire(code_client, Code_Région_Vente, Exist_Code_Région_Vente_Début) Clé étrangère(code_région_vente référence Région Vente.Code_Région_Vente) Clé étrangère(code_client référence Client.Code_Client) Relation : Loisirs Code_Loisir Nom_Loisir Clé primaire(code-loisir) Relation : Région Vente Code_Région_Vente Nom_Région_Vente Clé primaire(code_région_vente) 107

108 Conception d un Datawarehouse orienté CRM Les questions liées aux performances du modèle seront traitées lors de l implémentation de la solution, et certaines dénormalisations du schéma ci-dessus seraient appropriées Les contraintes de la rétrospection Un des rôles du modèle logique est de répondre à toutes les contraintes imposées par l implémentation de la rétrospection. L introduction d un support total du temps ajoute des besoins additionnels en termes de contraintes. a. Les contraintes du double-comptage Le double-comptage se manifeste lorsque la jointure entre plusieurs tables retourne plus d enregistrement que prévu. Ce problème est généralement évité si les règles générales de la modélisation dimensionnelle ont été respectées. Cependant, l introduction des attributs d existence augmente le risque d erreurs en changeant la nature des relations dans un datawarehouse de simples (1:n) à complexes (n:m). Ce problème est plus clair en utilisant des exemples. La table suivante concerne l existence des coûts des bouteilles : Code Boisson Début Fin Coût bouteille /02/ /03/ , /03/2005 A ce jour 47,90 Le coût de la bouteille a un attribut d existence. L existence est continue, mais un changement de coût a eu lieu. Cela a donné naissance à un nouvel enregistrement. La table suivante montre un fait de vente détaillant une vente de la boisson précédente : Code Boisson Jour Quantité Valeur /03/ ,50 En suite, la requête suivante est exécutée et essaye de lister les valeurs de vente et les coûts : Select w.nom_boisson, s.valeur Revenue, sum(s.quantité * w.coût_bouteille) Coût From Ventes s, Boisson w, ExistenceCoutBouteille bce Where w.code_boisson = s.code_boisson And s.code_boisson = bce.code_boisson And s.jour Between bcd.date_début and bce.date_fin Group By w.nom_boisson 108

109 Conception d un Datawarehouse orienté CRM Le résultat retourné est : Nom Boisson Revenue Coût Hamoud 249,50 218,00 Hamoud 249,50 239,50 Le résultat est que la vente a été doublement comptée. Le problème s est manifesté car la date du «31/03/2005» appartient à deux intervalles. La solution de changer la date fin du premier enregistrement à : «30/03/2005». Donc, l entrelacement des périodes d existence dans un modèle dimensionnel est interdit. b. Les contraintes d intégrité référentielle Plusieurs contraintes d intégrité référentielle de base peuvent être citées : - La période d existence d un objet subordonné doit être contenue dans une seule période d existence de l objet subordonnant. - Durant une période d existence d une entité, tous les attributs de l entité doivent existés. Si une entité à une rétrospection «Vrai» : - On peut avoir des attributs avec une valeur de rétrospection «Vrai». Les durées de vie de ces attributs doivent correspondre aux périodes de vie de l entité. Si l entité cesse d exister alors tous ces attributs avec une rétrospection «Vrai» devront cesser d exister au même temps. - On peut avoir des attributs avec une valeur de rétrospection «Faux». Ces attributs peuvent changer uniquement si l attribut d existence de l entité indique qu elle existe. Sinon, ils ne peuvent pas changer de valeur. Si une entité à une rétrospection «Faux» : - On peut avoir des attributs avec une valeur de rétrospection «Vrai». Si l entité cesse d exister, alors les attributs avec une rétrospection «Vrai» doivent cesser d exister au même temps. Quand l entité change de non-existante à existante, ces attributs doivent commencer un nouvel intervalle d existence au même temps. - On peut avoir des attributs avec une valeur de rétrospection «Faux». Ces attributs peuvent changer seulement si l attribut d existence de l entité indique que celle-ci existe. Ils ne peuvent pas changer si l entité n existe pas. c. Les contraintes de suppression 109

110 Conception d un Datawarehouse orienté CRM Il appartient aux concepteurs du datawarehouse de déterminer les valeurs de rétrospection à appliquer pour chaque objet de base de données. Les règles fixant les violations des contraintes d intégrité référentielle relatives aux suppressions (dans les bases de données relationnelles) doivent être appliquées à la notion d existence. Quand une dimension change de statu d existence pour devenir logiquement nonexistante, cela équivaut à une suppression logique de l entité. L application des règles doit être sélective. - La suppression en cascade ne peut être utilisée car elle pourrait supprimer les faits et créer une incohérence dans la base de données. - La suppression des relations ne peut pas être utilisée. Si cela est fait, les requêtes d agrégation des faits en utilisant les dimensions concernées par la suppression donneront des résultats faux. - La seule méthode de traiter avec les changements d existence est d utiliser des effets restrictifs. Cela signifie que quand l existence d une dimension cesse, toutes ses relations de références doivent avoir leurs existences terminées avant de terminer l existence de la dimension. Donc, une attention particulière doit être accordée aux contraintes imposées par l implémentation de la rétrospection. Enfin, nous rappelons que nous avons traités uniquement la modélisation logique de la vue «Clients» car il s agit du seul vrai point qui différencie les datawarehouses orientés CRM des datawarehouses traditionnels. 110

111 Conception d un Datawarehouse orienté CRM 4.5. L implémentation physique du système Dans cette section nous allons étudier quelques points relatifs à l implémentation et au fonctionnement physique du datawarehouse orienté CRM. Le premier point important à traiter dans tous les projets de datawarehouse est celui relatif à son alimentation qui se caractérise par un flux de données continuel des systèmes sources vers le datawarehouse. Ce processus de chargement de données commence par une extraction des données. Les données sont ensuite contrôlées pour déterminer leur qualité avant d être transformées et chargées dans le datawarehouse. La qualité des données est une vraie problématique pour les concepteurs de datawarehouses puisque une mauvaise qualité de données constitue une menace pour la réussite de tout le projet. Aussi, nous devons analyser ce qui se produit au niveau du datawarehouse lorsque des changements se produisent au niveau des systèmes sources. Les changements peuvent être insignifiants sans aucun impact comme ils peuvent être profonds et importants. Citons l exemple de l introduction d un système ERP qui va créer une nouvelle source de données majeure du datawarehouse. Ensuite, il y a la nécessité de faire fonctionner le datawarehouse dans un environnement actif et évolutif. Chaque jour, des nouvelles données sont extraites, contrôlées qualitativement, transformées, chargées et agrégées. Cette section est inspirée des travaux de R. Kimball, M. Ross et C. Todman (voir bibliographie : [Kimball/Ross2002], [Todman2001]) L architecture physique du datawarehouse orienté CRM Rappelons les quatre caractéristiques de base d un SGBD qui sont : 1. Evolutivité. La capacité de la base de données à s adapter aux changements dans l organisation et dans la communauté des utilisateurs. Cela inclue les capacités de monté en charge en terme de volume de données, d applications et d utilisateurs. 2. Disponibilité. S assurer que les données sont structurées et peuvent être vues de différentes manière par des applications différentes et des utilisateurs différents. 3. Partage. Les données sont accédées par l organisation entière. 4. Intégrité. Améliorer la qualité, maintenir l existant et assurer la sécurité. 111

112 Conception d un Datawarehouse orienté CRM Dans un environnement décisionnel, nous ajoutons les contraintes spécifiques suivantes : 1. Les accès utilisateurs sont non-structurés. 2. Le besoin en information concerne un plus grand nombre d utilisateurs avec des besoins différents. 3. Le système doit être capable de répondre aux changements de stratégie d entreprise en un temps minime. 4. Les résultats des requêtes doivent être fiables et cohérents. Afin de répondre à ces besoins, l architecture EASI (Evolvability, Availability, Sharability, Integrity) suivante est proposée : Données externes Segmentation Gestion des contacts Centres d appels Données locales Applications CRM Analyse des vantes Data Mining Analyse des compagnes Données locales Analyse du marché Base de données du Datawarehouse Méta données Processus VIM (Validation, Intégration, Mappage) Systèmes sources Figure : L architecture EASI du système L élément central de cette architecture est la base de données du datawarehouse. Cette base de données contient le niveau le plus détaillé (en termes de granularité) des données que l entreprise a besoin de stocker. Cette base est alimentée par les systèmes opérationnels. Cette base supporte les applications CRM qui sont capables d y puiser les données. Ces applications gèrent aussi leurs propres données. Les applications CRM sont totalement indépendantes. Elles peuvent fournir des données à d autres systèmes et, dans certains cas, mettre à jour les systèmes sources. 112

113 Conception d un Datawarehouse orienté CRM Le point le plus important à noter est que la base de données du datawarehouse est une ressource disponible pour toutes les applications CRM. Nous allons maintenant décrire les autres composants du modèle La couche VIM Avant d être stockées dans le datawarehouse, les données doivent se conformer à des contraintes rigoureuses qui concernent leur structure et leur intégrité. Les données sont traitées dans le processus «VIM» : Validation, Intégration, Mappage. Le processus VIM constitue l élément de base du contrôle de la qualité des données du datawarehouse. a. La validation des données Il s agit de l étape la plus importante du processus. Les prises de décision ne peuvent en aucun cas se baser sur des données de mauvaise qualité. Si la qualité n est pas assurée, les utilisateurs perdront leur confiance dans le système et cesseront de l utiliser. En réalité, Les données sources peuvent être : Absentes (ou partiellement absentes), Erronées, Périmées, Inconsistantes, Confuses. - Données absentes La cause principale de l absence de données est un défaut de rigueur lors de la saisie (collecte) des données au niveau des systèmes sources. Nous pouvons envisager deux approches pour combler cela : L utilisation des valeurs par défaut, Le rejet de l enregistrement : il y a trois types de rejets : Un rejet permanent : l enregistrement est simplement rejeté et ne sera jamais chargé dans le datawarehouse. Un rejet pour correction et réessayage : les données rejetées seront mises dans un fichier particulier pour correction. Après correction, les données vont être soumises de nouveau au processus de validation. Un réessayage automatique : dans certains cas de figure, un simple réessayage suffit à régler le problème. 113

114 Conception d un Datawarehouse orienté CRM - Données erronées Il existe plusieurs types de données erronées : Valeurs n appartenant pas à des intervalles ou listes de valeurs valides : cellesci sont simples à reconnaitre. Exemple : sexe du client = Z au lieu de M/F. Erreurs de référencement qui violent les contraintes d intégrité référentielle : L enregistrement contient une clé étrangère qui ne correspond à aucun enregistrement parent. Quand cette erreur est détectée, il est recommandé de rejeter l enregistrement incriminé car il peut être la cause d incohérences dans les résultats des requêtes. Toutefois, il faut prévoir des processus de traitement de ces erreurs et réessayer pas la suite d intégrer l enregistrement. Erreurs valides : ce sont des erreurs qui sont presque impossibles à détecter. Il s agit de valeurs qui ont été saisies incorrectement mais qui restent valides. Par exemple, on a saisi la valeur 26 dans le champ «âge du client» au lieu de 62. Ces erreurs doivent être corrigées au niveau des systèmes opérationnels. - Données périmées Les données périmées sont le résultat d une fréquence de synchronisation insuffisante des données relatives aux circonstances client changeantes entre les systèmes opérationnels et le datawarehouse. Par exemple, l adresse du client a changé au niveau du système opérationnel mais ce changement n a pas été répercuté au niveau du datawarehouse. La solution pour ce type d erreur est de revoir la fréquence de chargement et de synchronisation des données. - Données inconsistantes L inconsistance des données du datawarehouse est le résultat des dépendances de données que les systèmes opérationnels ne gèrent pas. Prenons l exemple suivant : nous avons créé une segmentation des régions de ventes en se basant sur les adresses client. Cette segmentation est gérée uniquement par le datawarehouse. Quand un client change d adresse, le datawarehouse effectue les ajustements nécessaires au niveau des circonstances clients. Le segment «Région», ou tout autre segment dépendant, sont mis à jour. Ce changement est sous le contrôle exclusif du datawarehouse. Les effets causals des changements de circonstances sur les segments dépendants sont difficiles à gérer et sont souvent sources d inconsistances dans les données. 114

115 Conception d un Datawarehouse orienté CRM - Données confuses Les données confuses peuvent se produire quand un changement de rétrospection est effectué et que la représentation du temps n a pas été corrigée. Par exemple, à cause d une application incorrecte de la rétrospection, lorsqu un changement d adresse se produit, la nouvelle adresse est appliquée aux données comportementales historisées par confusion. La solution : Afin de fournir une approche de validation flexible, nous devons construire des règles de validation en utilisant les métadonnées. Voici un exemple de modèle de validation. Attribut par défaut Attribut Intervalle attribut Liste valeurs attribut Figure : Le modèle des métadonnées de validation Les attributs des tables du modèle de validations sont les suivants : Table : Attribut ID Attribut Nom Table Nom Attribut Type données Rétrospection Table : Intervalle Attribut ID Attribut Valeur Min Valeur Max Table : Attribut par défaut ID Attribut Valeur par défaut 115

116 Conception d un Datawarehouse orienté CRM Table : Liste Valeurs Attribut ID Attribut Valeur b. L intégration des données La deuxième couche du processus «VLM» concerne l intégration des données. Cette couche s assure que le format des données est correct. Cette intégration s assure, par exemple, que toutes les dates soient au format «jj/mm/aaaa». Quand les formats de données sont standardisés au niveau d une entreprise, le besoin de manipuler et de transformer les données est minime. Cette intégration doit être aussi implémentée en utilisant les métadonnées. Notre modèle devient ainsi : Source Attribut Transformation Attribut Attribut Transformation Figure : Le modèle des métadonnées de transformation Les attributs des tables du modèle de validations sont les suivants : Table : Attribut ID Attribut Nom Table Nom Attribut Type données Format donnée Description Table : Source Attribut ID Source Attribut Nom Source Attribut Type Donnée Format Donnée Description Table : Transformation ID Processus Transformation 116

117 Conception d un Datawarehouse orienté CRM Nom Processus Transformation Type Processus Transformation Description Table : Transformation Attribut ID Attribut ID Source Attribut ID Processus Transformation c. Le mappage des données Cette couche mappe les données sources vers le format de destination. Le rôle de cette couche est de faciliter les changements futurs dans les systèmes sources. Afin de répondre à ce besoin, notre modèle de métadonnées devient ainsi : Source Attribut Transformation Attribut Attribut Source Donnée Transformation Figure : Le modèle des métadonnées de mappage 117

118 Conception d un Datawarehouse orienté CRM Les attributs de la source sont : Table : Source Donnée ID Source Nom Source Application Source Type Fichier Format Interface Plateforme Source Processus Extraction Fréquence Extraction Description Table : Source Attribut ID Source ID Source Attribut Nom Source Attribut Type Donnée Format donnée Description Voici enfin le modèle complet des métadonnées du processus «VIM». Liste valeurs attribut Attribut par défaut Attribut Intervalle attribut Source attribut Transformation attribut Source donnée Transformation Figure : Le modèle complet des métadonnées de la couche VIM L alimentation du datawarehouse Le datawarehouse est alimenté à partir des sources de données se trouvant dans l environnement transactionnel de l entreprise. Le processus de chargement des données 118

119 Conception d un Datawarehouse orienté CRM transactionnelles nécessite un traitement périodique des données sources afin de sélectionner les données à intégrer dans le datawarehouse. Les données sélectionnées dans l environnement transactionnel sont soumises au processus «VIM» avant le chargement. Extraction, VIM, Chargement Sources DWH Figure : L extraction et le chargement des données Le processus du chargement à partir des processus transactionnels est d une importance spéciale car beaucoup de ressources machines peuvent être consommées. Il existe deux types de chargement de données vers un datawarehouse : 1. Le chargement initial (un processus One-Shot), 2. les chargements incrémentaux (les mises à jour périodiques). Le chargement initial concerne essentiellement les données sur les circonstances. Ce chargement inclut la création des clients, des produits, des promotions et des données géographiques. Le chargement initial des données comportementales est effectué lorsqu il existe des données historiques qui doivent être chargées. Si le chargement initial échoue, il est relativement simple d annuler la transaction et de recommencer. Cela n est pas toujours applicable avec les chargements incrémentaux de mise à jour. Le chargement incrémental (appelé aussi : rafraichissement des données) est un processus qui est exécuté périodiquement. C est le processus le plus important. Le rafraîchissement des données consomme beaucoup de ressources machines. Il est exécuté selon une fréquence régulière qui peut être quotidienne. La fréquence dépend de la vivacité de l environnement transactionnel de l entreprise. 119

120 Conception d un Datawarehouse orienté CRM La figure suivante illustre ce rafraîchissement : Supprimer Ajouter Modifier Supprimer Ajouter Modifier Sources M-à-j DWH Figure : Le rafraîchissement des données Le modèle physique des données La base de données du datawarehouse est l incarnation physique du Modèle Conceptuel. En clair, le modèle physique est similaire, ou presque, au modèle conceptuel d origine. Néanmoins, le modèle physique dépend du SGBD choisi et des besoins en performance. Supposons que le SGBD choisi est relationnel (ce qui est généralement le cas) et essayons de construire le modèle physique en gardant l aspect général du modèle conceptuel. Voici le modèle présenté en parties : Partie A : Circonstances Client Non-Changeantes (Rétrospection = Faux ou Perm ) Client Figure : Le modèle physique des circonstances «Client» non-changeantes 120

121 Conception d un Datawarehouse orienté CRM Voici les attributs fixes de la table «Client» : Table : Client Titre Nom Date de Naissance Sexe N Téléphone Partie B : Circonstances Clients Changeantes (Rétrospection = Vrai) Adresses Situation familiale Enfants Epouses Clients Revenus Loisirs Professions Employeurs Figure : Le modèle physique des circonstances «Clients» changeantes Les attributs de cette partie sont : Table : Adresses ID Client Adresse Date Début Date Fin Table : Situation familiale ID Client Situation familiale Date Début 121

122 Conception d un Datawarehouse orienté CRM Date Fin Table : Enfants ID Client Nom Enfant Date de naissance Enfant Table : Epouses ID Client Nom Epouse Date de naissance Epouse Table : Revenus ID Client Revenu Date Début Date Fin Table : Loisirs ID Client Loisir Date Début Date Fin Table : Professions ID Client Profession Date Début Date Fin Table : Employeurs ID Client Nom Employeur Adresse Employeur Catégorie Employeur Date Début Date Fin 122

123 Conception d un Datawarehouse orienté CRM Partie C : Le modèle comportemental Classe Fournisseur Boisson Région Ventes Boissons Vente Accessoire Client Visite prise Produit Visite Figure : Le modèle physique du comportement 123

124 Conception d un Datawarehouse orienté CRM Partie D : Les segments dérivés Client Segment Client Type segment marché Segment marché Valeur attribut segment Figure : Le modèle physique des segments dérivés Voici les attributs de ces tables avec un exemple de valeurs d attributs : Table : Type Segment Marché ID Type Segment Marché Description Type Segment Marché LT217 Segment Revenu Table : Segment Marché ID Type Segment Marché LT217 LT217 ID Segment Marché Description Segment Marché Revenu Moyen Revenu Fort Table : Valeur Attribut Segment ID Type Segment Marché LT217 LT217 ID Segment Marché Table Salaires Client Salaires Client Attribut Salaire Salaire Valeur Min. Attribut Valeur Max. Attribut Table : Segment Client ID Client 12LJ49 12LJ49 ID Type Segment Marché LT217 LT217 ID Segment Marché

125 Conception d un Datawarehouse orienté CRM Date Début 21/01/ /03/2005 Date Fin 28/02/2005 Null Vous remarquez dans l exemple que le client 12LJ49 a passé d un segment de marché (Revenu Moyen) à un autre segment (Revenu Fort). Un segment de marché est composé d un certain nombre de valeurs d attribut de segment Les applications CRM Les applications décisionnelles CRM développées auront comme principale source de données la base de données du datawarehouse. Les applications puiseront les données de cette base pour répondre directement aux requêtes ou pour faire des sauvegardes dans leurs propres bases de données, peut être sous forme d agrégats. En plus, les applications pourraient aussi utiliser leurs propres données. Ces données peuvent être internes ou externes fournies par une agence de données (Ex. : Un institut de statistiques). Les applications auront leur propres cycles de traitement, totalement indépendants de celui du datawarehouse. Ces cycles incluent : 1. La capture des données, 2. Les transformations spécifiques aux applications, 3. Le chargement des données, 4. Les accès utilisateurs finaux, 5. La sauvegarde. Cette séparation entre le datawarehouse et les applications signifie que nous pouvons développer et ajouter des applications après la mise en exploitation du datawarehouse. Notre architecture est ainsi complètement évolutive. Les données historisées du datawarehouse seront toujours disponibles pour les nouvelles applications. En général, les applications CRM sont achetées sous forme de «packages». Il existe sur le marché une multitude d offres d applications CRM plus au moins riches en couverture fonctionnelle : Gestion des compagnes, personnalisation des produits, Data Mining, Analyse marché/produits. Il est plus judicieux de ne pas réinventer ces applications même si elles ne fournissent pas 100% des fonctionnalités dont nous avons exprimé le besoin. Ces 125

126 Conception d un Datawarehouse orienté CRM applications ont besoin de données pour fonctionner et notre architecture est capable de les fournir rapidement Synthèse sur l architecture du système L architecture des datawarehouses orientés CRM se caractérise par son respect des principes d évolutivité, de disponibilité, de partage et d intégrité. L objectif du datawarehouse est de rendre les données disponibles pour toutes les applications CRM. Les avantages de cette architecture sont : Elle permet à l entreprise d adopter une approche stratégique de construction des systèmes d information. Cette approche se repose sur l idée que ces systèmes doivent être construits autours d impératives d entreprise et non pas autour de besoins tactiques ou départementaux. Elle supporte l approche incrémentale de développement de systèmes d information. Le ROI (Retour Sur Investissement) est mesurable pour chaque incrément. L ajout de nouvelles applications est relativement simplifié. En garantissant la séparation entre les données et les applications et à un niveau de granularité bas, nous assurons à notre système un support total des changements inévitables de stratégie d entreprise. Les données historisées sont immédiatement disponibles aux nouvelles applications. Le système d information décisionnel est conçu pour aider l entreprise à atteindre ses objectifs. Ce système doit évoluer avec l évolution de ces objectifs. Pour cela, il faut adopter une démarche de construction incrémentale qui présente le moins de risques et qui minimise les coûts afin d aboutir toujours à un système complet et complètement intégré. 126

127 Conception d un Datawarehouse orienté CRM 4.6. Les produits logiciels Il existe actuellement sur le marché une multitude de produits logiciels orientés Datawarehouse et/ou CRM. Certains éditeurs affirment que leurs produits sont capables d augmenter la productivité avec des délais d implémentation très courts. Ces éditeurs assurent aussi que leurs produits prennent en charge le «CRM». L auteur P. Greenberg dans son livre intitulé CRM at the speed of light, 3 rd edition [Greenberg2004] a cité l exemple d un produit logiciel qui était à la base, un outil de requêtage SQL. Depuis son lancement initial, ce produit n a pas subit de grands changements. Actuellement, le produit possède une version Web et une interface OLAP. Il s agit, selon l auteur, d un bon outil de requêtage. Cependant, les fournisseurs de ce produit logiciel affirmaient qu il est à la fois : Un produit de Datawarehousing, Un produit OLAP (Avant le développement de l interface OLAP), Un outil de Datamining, Et un outil CRM. Ces affirmations sont la source d échec de plusieurs projets. Certaines personnes pensent qu on achetant les meilleurs outils sur le marché, ils auront la garantie de réussir leurs projets. Les expériences passées ont prouvé que cette condition n est pas toujours suffisante. Les produits CRM n existent pas Cette phrase révèle une vérité. Il existe certains produits qui aident l entreprise à implémenter une stratégie CRM mais il n y a pas de produits CRM. Le CRM ne se résume pas à un ou plusieurs produits logiciels (voir le chapitre 3 sur le CRM). Dans cette section, nous allons présenter certains types de produits logiciels indispensables pour implémenter une solution Datawarehouse. Nous n allons pas évaluer ou traiter des produits spécifiques mais nous allons décrire leurs caractéristiques et citer des exemples de produits présents sur le marché actuel. 127

128 Conception d un Datawarehouse orienté CRM Les produits ETL (Extraction, Transformation and Loading) Le terme ETL est utilisé pour décrire le processus qui commence par l extraction des données à partir des systèmes sources pour ensuite les modifier et les transformer en une forme acceptée par le datawarehouse pour enfin les charger dans la base de données. Ces outils sont nécessaires pour l implémentation de la couche VIM présentée dans la section précédente. Il existe actuellement sur le marché plusieurs outils ETL qui fournissent des mécanismes d extraction, de transformation et de chargement des données vers les datawarehouses. La figure suivante illustre les composants majeurs de la plupart des produits ETL : Fichiers sources Extraire Transformer Charger Cible Figure : Le processus ETL Cette figure montre que le processus ETL peut être considéré comme étant composé de plusieurs processus distincts. a. L extraction Ce processus accède aux sources et pompe les données nécessaires pour le datawarehouse. Les routines d extraction peuvent être simples dans le cas où le fichier est délivré par le système source ou complexes lorsqu il s agit d essayer d identifier les changements de circonstances clients. Le processus d extraction doit comprendre la signification des données sources afin de n extraire que les données utiles. Les études montrent qu à chaque cycle d extraction, moins de 2% des données sources sont intégrées au datawarehouse. Il est aussi important que l outil d extraction nous permette de descendre au niveau enregistrement afin de définir ce qu on veut extraire. Les données extraites sont enregistrées dans une zone de traitement avant de passer aux autres processus. L outil doit, de ce fait, nous permettre de générer des fichiers intermédiaires de données. b. La transformation 128

129 Conception d un Datawarehouse orienté CRM Dans un produit ETL, la partie liée à la transformation est la plus distinctive et la plus importante. Le traitement VIM que nous avons décris dans la section 4.5 est pris en charge par le processus de transformation. Rappelons que VIM signifie : Validation, Intégration et Mappage des données. L outil ETL doit couvrir toutes les opérations à effectuer durant le processus VIM (voir la section 4.5.2). c. Le chargement Le chargement des données dans le datawarehouse est une source de problèmes. Certains outils opèrent des insertions physiques des enregistrements dans les tables cibles du datawarehouse en utilisant les clauses SQL «Insert». D autres outils exécutent le processus ETL enregistrement par enregistrement. Ce qui signifie que chaque enregistrement est lu à partir du système source, transformé puis chargé dans le datawarehouse, et ainsi de suite. Cette approche est envisageable dans le cas où nous n avons pas de grands volumes de données à transférer. Sinon, cette approche sera la source de goulots d étranglement. Pour traiter de grands volumes de données, il faut utiliser les outils proposés par l éditeur du SGBD du datawarehouse qui sont en général bien adaptés pour ces situations. Il existe deux familles d'etl : Les générateurs : la description des processus d'alimentation aboutit à la génération automatique de code qui sera en suite intégré dans les chaînes d'exploitation. Les moteurs : ils offrent des fonctions d'administration des processus d'alimentation (lancement, répartition des tâches entre sources et cibles, ). Voici un exemple des produits ETL existants sur le marché : Data Stage (Ardent Software) : Moteur/Générateur, Genio (Hummingbird) : Moteur, Informatica : Moteur, ETI Extract : Générateur, WareHouse Administrator (SAS) : Moteur. 129

130 Conception d un Datawarehouse orienté CRM Les produits OLAP OLAP est un concept qui est apparu avec la naissance des datawarehouses. OLAP fait référence à la fois à une méthodologie de structuration dimensionnelle des données dans un contexte décisionnel, et à des techniques utilisées par les systèmes de gestion de bases de données (SGBD) et par les outils de restitution pour faciliter l exploitation de ses structures. Une structure OLAP se définit par rapport à un problème décisionnel. Dans un contexte décisionnel, l utilisateur se posera un certain nombre de questions sur des indicateurs clés accompagnés éventuellement d informations complémentaires telles que : Quoi, quel produit ou quel service, Quand : la date ou la période, A qui : à quel client, Qui : quelles entités dans l entreprise, Où, la localisation de la vente ou du marché Chacun de ces éléments constituera une dimension d analyse pour les indicateurs de ventes. La structure ainsi conçue est communément nommé «Cube OLAP». Les SGBD actuels proposent des modèles de stockage et/ou d accès aux données basé sur cette structure. On parle alors de base de données OLAP. Les techniques d accès aux données OLAP, telle que OLE-DB for OLAP de Microsoft, permettent la navigation dans le cube : l utilisateur peut ainsi zoomer (notion de drill-down), ou changer d axe d analyse (on parle alors de slice & dice). La navigation dans les données OLAP est particulièrement intuitive. Les caractéristiques définis par E. Codd pour les bases OLAP sont [Source : Kimball1999] : Rapide : les temps de réponse doivent être prévisibles et constants. Une réponse en moins de cinq secondes doit être donnée à la plupart des requêtes ad hoc lancées par l utilisateur. Analyse : les outils d accès à la base de données doivent permettre l exécution d analyse sur les données, en y associant des règles de calcul (statistiques, financières, séries temporelles, etc.). Ces analyses peuvent être prédéfinies ou spécifiées de façon appropriée par l utilisateur final. Partage : les données et la structure multidimensionnelle sont potentiellement accessibles par un ensemble d utilisateurs ; les mécanismes de gestion de la sécurité et de la confidentialité des données doivent être proposés. Multidimensionnel : c est la caractéristique de base d OLAP. 130

131 Conception d un Datawarehouse orienté CRM Information : toutes les données doivent être accessibles en mode multidimensionnel, quelle que soit leur localisation. Les contraintes de volumétrie doivent être quasi inexistantes. Les remarquables possibilités d analyse des Bases de données OLAP impliquent toutefois une certaine rigidité du modèle. En effet, tous les besoins utilisateurs doivent être modélisés au préalable. L utilisateur a une latitude extrêmement faible pour faire évoluer le modèle. Un des facteurs différenciateur de la multitude d outils OLAP est le mode de stockage des données, qui permet de diviser cette gamme d outils en plusieurs familles : Les outils MOLAP, les données étant stockées sous une forme multidimensionnelle ; Les outils ROLAP, les données étant stockées sous une forme relationnelle ; Les outils HOLAP, les données étant stockées sous une forme hybride dans des environnements multidimensionnels et relationnels Les outils de restitution Le concept de datawarehouse n intègre l aspect «outils d aide à la décision» qu en bout de la chaîne. C est une composante nécessaire et importante car c est l unique point d entrée visible pour le consommateur de l information. Dans le domaine de la restitution des données, trois grands types de besoins apparaissent : La diffusion d information en masse. L objectif principal en est le partage d information pour une très large population d utilisateurs. Ceux-ci sont relativement passifs par rapport à l information qui leur est accessible : il s agit alors d informations pré-structurées sous la forme de tableaux de bord ou d états prédéfinis. On parle à ce propos de Reporting. L analyse. L utilisateur travaille dans ce cas sur un périmètre fonctionnel précis dont les enjeux ont été préalablement formalisés. Ceux-ci se présentent sous la forme d indicateurs clés de performance. L utilisateur peut alors se servir du système pour découvrir l ensemble des facteurs susceptibles d améliorer cette performance, puis mesurer l impact des décisions que cette analyse a contribué à prendre. Pour notre système, cette analyse touchera le domaine du CRM. L accès aux données en libre-service. L utilisateur est libre de sélectionner les données adéquates en fonction de ses objectifs du moment. [Source : Franco/Lignerolles2000] 131

132 Conception d un Datawarehouse orienté CRM Pour chaque type de besoin, il existe sur le marché des produits qui y sont adaptés, nous pouvons citer quelques exemples : Le domaine du Reporting d entreprise était à l origine dominé par trois spécialistes : Actuate, Seagate Software, avec Seagate Info, et Sqribe, dont la société a été depuis rachetée par Brio. Puis il s est élargi, notamment en raison de l adaptation à ce marché des offres de type requêteur, comme celles de Business Objects ou de Cognos ou des éditeurs d état, comme Oracle Reports. Le marché des outils d analyse OLAP était d abord dominé par les offres MOLAP comme celles de Applix (TM/1), Hyperion (Essbase), Oracle (Express) et Seagate (Holos) ; celles-ci ont depuis évolué vers le modèle HOLAP. Des offres plus légères, orientées micro, comme Powerplay de Cognos où BI/analyze de Hummingbird les ont rejointes sur ce marché. Puis les requêteurs comme Business Object ou Brio ont également intégré le multidimensionnel. Ensuite sont arrivés les outils ROLAP, comme Metacube de Informix, Information advantage DSS de Microstrategy, ou BW de SAP. Enfin, certains acteurs comme Microsoft (OLAP services) ou SAS ont proposé une offre de type HOLAP, intégrant leur propre serveur multidimensionnel, ou un outil susceptible de s appuyer sur une couche de stockage relationnelle. Le marché des requêteurs est de son côté dominé par Brio, Business Object, Cognos et Hummingbird. D autres acteurs non positionnés initialement sur ce marché ont élargi leurs offres : on peut citer Seagate (Info), Oracle (Discoverer) et SAS (SER) Le Datamining Le «Datamining» est un procédé permettant de découvrir des nouvelles corrélations, de nouveaux schémas et de nouvelles relations dans de grandes quantités de données stockées dans des bases, en utilisant aussi bien les techniques de «Pattern recognition» que des techniques statistiques et mathématiques. [Source : Rud2001] Le problème actuel des entreprises n'est plus de récupérer de la donnée, au contraire elles en récupèrent même «trop» dans le sens ou elles n'arrivent pas forcément à la traiter dans le temps voulu. Le but du Datamining est de permettre à la machine d'interpréter les données présentent dans ces bases de données. Ainsi la tâche de compréhension normalement dévolue aux humains est 132

133 Conception d un Datawarehouse orienté CRM affectée sur la machine, qui en échange produit un compte rendu clair et simple de ce qu'elle a trouvée. Le Datamining permet aux entreprises de se focaliser sur les informations les plus importantes de leurs bases de données. Les objectifs du Datamining peuvent être classés en deux grandes catégories : La prédiction automatique des marchés et comportements, La découverte automatique de schémas encore inconnus. La prédiction automatique est simplement une mise en corrélation de données obtenues par la découverte des schémas. En clair la prédiction est une ré-applications des schémas sur les données arrivantes. Parmi les formes de représentation de la connaissance générée par les algorithmes de Datamining, les plus courantes sont : [Source : Rud2001] Les classes qui sont des groupes d'individus ayant des propriétés communes. Le but des classes est de trouver des dénominateurs communs des individus pour permettre, par exemple, de trouver à quelle classe appartient un nouvel individu arrivant. Des associations, c'est-a-dire des règles permettant de savoir quelle condition déclenche quelle conséquence. En utilisant des tickets de caisse, on peut par exemple déduire que les individus achetant un produit x vont certainement acheter le produit y. Des arbres de décision, ce sont des arbres permettant de répondre à des questions ayant un nombre de réponse connu et fini. De tels arbres sont obtenus d'après les valeurs des attributs d'une base d'exemple. Dans le domaine du CRM, les algorithmes de «Datamining» présente une très grande importance dans le processus de la reconnaissance client CKM (Customer Knowledge Management). L Enjeu de la connaissance fine et détaillée des clients est de créer, développer et maintenir des relations profitables pour l entreprise en utilisant les techniques de management de l information «Client». Ces techniques permettent de : détecter les niches marketing, déterminer les profils des clients, modéliser le comportement des clients, 133

134 Conception d un Datawarehouse orienté CRM détecter les besoins en services nouveaux, détecter les potentiels économiques des clients, détecter et expliquer les risques d infidélité, détecter et expliquer les risques d impayés, détecter les tendances des concurrents et des marchés, d améliorer la QoS fournie aux clients, d améliorer la satisfaction des clients, En des termes clairs, Le datamining CRM est un processus de management des données «Client» qui opère à partir sur les données élémentaires pour produire de l information et de la connaissance. Il existe sur le marché tout une gamme d'outils allant de ceux supportant une unique méthode statistique fonctionnant en monoposte sur des volumes de données limités (exemple : Alice ), jusqu'aux outils offrant une palette complète de méthodes statistiques fonctionnant en client/serveur sans limitation de volume (exemple : Les outils SAS ). 134

135 Chapitre 5 Conclusion et perspectives n Les bases de données temporelles ; n Les extensions «SQL OLAP» ; n Les systèmes décisionnels actifs ; n L exploitation des données externes ; n Les données non-structurées.

136 5. Conclusion et perspectives Développer une stratégie CRM est devenu un objectif majeur des entreprises actuelles. Or, la réalité nous a montré que les projets CRM sont des projets risqués et très couteux à mettre en œuvre. Une des conditions nécessaires pour réussir l implémentation d une stratégie CRM est la disponibilité de données «Clients» fiables, pérennes, précises et répondant aux besoins des décideurs permettant ainsi une gestion efficace de la relation clients. Pour satisfaire cette condition, les applications CRM doivent être supportées par des datawarehouses conçus autour d objectifs CRM qui ne se limitent pas à recueillir que les données comportementales. Ce sont les datawarehouses de «deuxième génération» qui intègrent un nouvel objectif clair : maximiser l efficacité de la gestion de la relation client. Alors que les projets de datawarehouses classiques se concentrent sur les faits et les dimensions, les projets de datawarehouses orientés CRM se focalisent sur la dimension «Client» en la structurant de manière à répondre aux objectifs CRM des entreprises. Dans ce mémoire, nous avons traités les éléments nécessaires à la conception et l implémentation d un datawarehouse orienté CRM. Nous avons focalisé notre travail sur la dimension «Clients» ; car pour le reste, le projet diffèrera peu des datawarehouses classiques. La différence entre les datawarehouses de première génération et ceux de la deuxième génération est la manière d aborder la conception de la dimension «Clients». Dans les datawarehouses orientés CRM, les données «Clients» ne se limitent pas à une unique table dimension. La dimension «Client» devient un modèle complet de données qui est le centre du modèle global du datawarehouse. Ce modèle intègre les données sur le comportement, les circonstances et la segmentation des clients. Dans ce mémoire, nous avons principalement traité la modélisation conceptuelle et logique des données «Clients» et proposé une architecture d implémentation physique du datawarehouse. A ce stade, le travail n est certainement pas complet puisque nous n avons pas traité tous les détails de ce projet mais nous espérons pouvoir le faire ultérieurement. Il n existe pas actuellement de standards dans le domaine et beaucoup de travaux de recherche sont menés actuellement sur le concept du datawarehouse du futur.

137 Conclusion et perspectives Le CRM est un des services à valeur ajoutée que les consommateurs d aujourd hui exigent. La question est : que-est ce que le futur amène dans ce domaine? Nous pouvons penser qu il est impossible de prédire cet avenir. Cependant, si nous restons focaliser sur les datawarehouses, il est quasi certain que l architecture de base présentée dans ce mémoire ne va pas changer. Par contre, l implémentation physique va certainement évoluer. Internet, par exemple, va faciliter l émergence de centre de données très larges qui contiennent des centaines, voir des milliers ou même des millions de serveurs interconnectés, gérés par des fournisseurs de service qui vont permettre l externalisation à de larges proportions. Mais les données ne vont pas changer, et notre MCG fournira toujours les données nécessaires pour pouvoir comprendre les clients. Nous présentons dans ce qui suit les axes de recherches actuels dans le domaine des datawarehouses orienté CRM : a. Les bases de données temporelles (les extensions temporelles) Depuis les années 90, plusieurs travaux de recherches ont été menés sur les bases de données temporelles. Une base de données temporelle supporterait nativement certains aspects du «Temps». Nous pouvons penser que tous les SGBD actuels supportent le «Temps» avec l inclusion et l utilisation du type de données «Date/Time». Or, l objectif des bases de données temporelles est tout autre. Une base de données temporelle supporterait les données temporelles nativement par le biais de la structure du SGBD. Le schéma des tables, le processeur de requêtage, etc. doivent avoir une compréhension native du «Temps». Nous avons déjà traité dans ce mémoire certains aspects liés au temps. Les datawarehouses sont des bases de données temporelles sans qu ils soient implémentés sur des SGBD temporels. La communauté des chercheurs a échoué, jusqu à présent, à développer un SGBD temporel. La gestion du «Temps» se fait actuellement en utilisant les attributs de type «Date/Heure». Les recherches dans ce domaine se concentrent sur la manière de modifier le modèle relationnel pour répondre aux besoins «Temporels» sans violer les principes théoriques de la modélisation relationnelle. Des propositions ont été faites concernant les extensions possibles au langage SQL. Ces propositions concernent généralement l ajout d une clause «WHEN» au langage. Jusqu à présent, aucun éditeur de SGBD n a voulu implémenter cette proposition. 137

138 Conclusion et perspectives Peut-être que le problème vient du faite que les tables relationnelles sont à deux dimensions. Le «Temps» ajoute une autre dimension et toutes les tentatives pour trouver une solution se terminent par un échec. La vraie solution n est pas de modifier les SGBD actuels mais de créer un nouveau modèle de bases de données différent du modèle relationnel. b. Les extensions «SQL OLAP» Il existe actuellement plusieurs propositions d extension du langage SQL afin de permettre la prise en charge et l exécution de certaines fonctions OLAP. Voici les principales propositions : Les moyennes mobiles : Il sera possible de spécifier un nombre d enregistrement à inclure dans la moyenne mobile. Par exemple, dans un tableau résultat contenant les ventes mensuelles, nous pouvons calculer des moyennes mobiles pour un nombre de mois spécifié. Nous pouvons, par exemple, créer une moyenne mobile de trois mois qui contient le mois actuel (pointé avec la souris), le mois précédent et le prochain mois. Les groupes d agrégation : Alors que la moyenne mobile est une fonction «d agrégation limitée», il serait possible de définir des agrégations non-limitées afin de permettre la définition de colonnes cumulatives. Un autre développement de cette idée pourrait nous permettre de définir des colonnes d agrégation qui n incluent pas l enregistrement actuel. Par exemple, nous pouvons comparer les ventes de ce mois avec la moyenne des trois mois précédents. Les fonctions de classement : Les utilisateurs d un datawarehouse ont souvent besoin de connaître la liste des TOP «n» des clients, produits ou régions. Cette fonction proposée nous permettra de formuler de telles requêtes. c. Les systèmes décisionnels actifs Les systèmes d aide à la décision actuels sont des systèmes passifs et les datawarehouses n échappent pas à cette règle. Les systèmes décisionnels attendent que d autres applications leur soumettent des requêtes avant de réagir et fournir les réponses. L idée est de construire des systèmes d aide à la décision actifs (semblables aux systèmes experts) qui sauraient reconnaître les informations intéressantes et les fournir sans interventions ou sollicitations 138

139 Conclusion et perspectives externes. Ces systèmes chercheraient en permanence les nouvelles données et réagiraient lorsque des changements importants seraient détectés. Ces systèmes seraient totalement différents des systèmes d alerte traditionnels. d. L exploitation des données externes Certains datawarehouses doivent avoir un accès aux données externes. Les données externes ne sont pas celles importées dans le datawarehouse en utilisant les outils ETL. L intégration des données externes signifie qu en cas de besoin les utilisateurs peuvent accéder à ces données via le système du datawarehouse. Dans l industrie pharmaceutique, par exemple, il existe des centaines de bases de données épidémiologiques tierces à qui les entreprises du secteur peuvent souscrire à un accès. Le datawarehouse doit être en mesure d exploiter ces données. Or, ces bases de données sont très grandes et il est inapproprié d envisager de les copier dans le datawarehouse. Nous pouvons simplement créer des liens vers ces données sans compromettre la sécurité et l intégrité des données internes du datawarehouses. e. Les données non-structurées Les données du datawarehouse sont des données structurées : ces données sont organisées sous forme de lignes et de colonnes, avec des types de données précis. Les données non-structurées sont celles qu on trouve dans les documents, les pages Web, les journaux, etc. Ces données sont aussi importantes que les données structurées. Ces données non-structurées sont très intéressantes puisqu elles sont disponibles plus vite que leur version structurée. L objectif est de pouvoir obtenir, interpréter et présenter les informations issues de ces données aux utilisateurs et d écrire éventuellement des algorithmes de datamining pouvant analyser ces données. Parmi toutes les technologies disponibles aujourd hui, ML (etensible Markup Language) est la plus prometteuse pour fournir une solution d interprétation des données non-structurées. 139

140 Bibliographie

141 Références Bibliographiques 6. Références Bibliographiques Les livres : [Adamson/Venerable1998] Datawarehouse Design Solutions ; C. Adamson, M. Venerable; John Wiley and Sons; [Anderson/Kerr2002] Customer relationship management ; K. Anderson, C. Kerr; McGraw-Hill; [Anton/Vilsoet2002] Customer Relationship Management Technology ; J. Anton, B. Vilsoet; John Wiley and Sons; [Dyche2002] The CRM Handbook: A Business Guide to Customer Relationship Management ; J. Dyche; Addition Wesley; [English2004] Improving Datawarehouse and Business Information Quality: Methods for Reducing Costs and Increasing Profits ; L.P. English; John Wiley and Sons; [Franco/Lignerolles2000] Piloter l entreprise grâce au datawarehouse ; J.M. Franco, S. De Lignerolles; Eyrolles; [Freeland2002] The Ultimate CRM Handbook: Strategies and Concepts for Building Enduring Customer Loyalty and Profitability ; J. Freeland; John Wiley and Sons;

142 Références Bibliographiques [Goglin1998] La construction du datawarehouse : du datamart au dataweb ; J.F. Goglin; Hermes; [Greenberg2004] CRM at the speed of light, 3 rd edition ; P. Greenberg; McGraw-Hill Osborne Media; [IBM1998] Data Modelling Techniques for Data Warehousing ; C. Ballard, D. Herreman, D. Schau, R. Bell, E. Kim, A. Valencic; IBM Redbooks; [Johnson/Gustafsson2000] Improving Customer Satisfaction, loyalty and Profit ; M.D. Johnson, A. Gustafsson; Jossey-Bass (A Wiley Company); [Kimball/Ross2002] The Datawarehouse Toolkit: The Complete Guide to Dimensional Modelling, 2 nd Edition ; R. Kimball, M. Ross; John Wiley and Sons; [Kimball1999] Concevoir et déployer un datawarehouse : guide de conduite de projet ; R. Kimball, L. Reeves, M. Ross, W. Thornwaite; Eyrolles; [Kimball/Merz2000] Le datawebhouse : Analyser le comportement client sur le Web ; R. Kimball, R. Merz; Eyrolles; [Lowenstein2004] One Customer, Divisible: Target, Analyze and Prosper ; M. Lowenstein; John Wiley and Sons;

143 Références Bibliographiques [Reynolds2002] A practical Guide to CRM ; J. Reynolds; CMP Books; [Rud2001] The Datamining Cookbook ; O. Parr Rud; John Wiley and Sons, [Swift2003] Accelerating Customer Relationships: Using CRM and Relationship Technologies ; Ronald S. SWIFT; Prentice Hall; [Todman2001] Designing a Datawarehouse Supporting CRM ; C. Todman; Prentice Hall; [Turk/Bligh2004] CRM Unplugged: Releasing CRM s Strategic Value ; D. Tulk, P. Bligh; John Wiley and Sons;

144 Références Bibliographiques Articles et thèses : [Bauer/Grether/Leach2002] Building Customer Relations over the Internet ; H. H. Bauer, M. Grether, M. Leach; Mannheim University (Germany); [Bret/Soule/Zurfluh2000] Outils méthodologiques pour la conception de bases de données décisionnelles orientées objet ; F. Bret, C. Soule-Dupuy, G. Zurfluh;Université St Hilaire, Canada; [Chaudhuri/Dayal1997] An Overview of Datawarehousing and OLAP Technology ; S. Chaudhuri, U. Dayal; ACM SIGMOD Record; [Codd1993] Providing OLAP to user-analysts: an IT mandate ; E.F. Codd; Technical Report, E.F. Codd and associates; [Dayal/Wuu1992] A uniform approach to processing temporal queries ; Y. Dayal, G.T.J. Wuu; International conference on very large databases, Canada, [Flueckiger2000] Les systèmes TES, Customer Relationship Management ; A. Flueckiger; Gartner Group; [Teste2000] Modélisation et manipulation d entrepôts de données complexes et historisées ; O. TESTE ; Thèse de doctorat, Université P. Sabatier, Toulouse (France) ;