pfeasmaaelouraoui

UNIVERSITE MOHAMMED V AGDAL ECOLE MOHAMMADIA D’INGENIEURS

Département : Génie Informatique Section : Systèmes d’Information

Mémoire de Projet de Fin d’Etudes N° INF 09 /12

Conception et mise en place d’un système décisionnel pour le suivi du flux de stock du compte ATAC

Réalisé par: Mle. NADIA BENHACHEM Mle. ASMAA ELOURAOUI Dirigé par: Mme. LAILA BENHLIMA M.SLIMANE BAH M.SAID ABOUKS

Année 2011-2012

Dédicaces A ta mémoire papa, enfin ta petite fille qui avait que 5ans achève son parcours universitaire. J’aurai aimé que tu sois là mais je sais que tu assiste d’en haut et j’espère que tu es fier de ta petite KHRIBIKA. Je te rends hommage cher papa et je te dédie ce modeste travail. A toi maman, pour la première fois je réalise que les mots ne servent à rien et quoi que je dise je ne saurai exprimer ma gratitude à ton égard. Tu as vraiment consenti tant de sacrifices pour faire de moi la personne que je suis aujourd’hui. Que Dieu le tout puissant te béni chère maman. A mes chers frères Younes et Karim je vous adore tant. A ux plus belles sœurs du monde Saloua et Mouna . A ma clique du lycée militaire Meryem,Hoda,Hakima,Zineb,Fatima,Fadoua…, merci de m’avoir appris le vrai sens de l’amitié. A mes chers amis hajjatiii, Fidaa, Safaa,Laila,Sarra ,adnane,adel merci d’être les meilleurs amis du monde . A tous ceux qui ont marqué ma vie et que j’ai oublié de citer. Je vous dédie ce modeste travail avec l’expression de ma profonde gratitude Asmaa…..

I

Dédicaces Aux deux êtres qui ont donné sens à mon existence, à mes chers parents : Aucun remerciement, aucun mot d’amour, aucune expression de gratitude ne sera suffisante pour vous exprimer mon respect et ma reconnaissance pour tous vos sacrifices déployés afin de m’élever dignement et d’assurer mon éducation dans les meilleures conditions. Merci pour votre amour inconditionné, votre capacité à me pardonner, votre confiance qui m’a couronnée. Que ce travail humble devant le votre soit pour vous un témoignage de ma vive reconnaissance et de mon amour filial. A ma très chère sœurette Sanaa Merci pour tes encouragements, ta confiance, ta présence et ton soutien dans les moments difficiles. Tu es pour moi la meilleure sœur au monde. J’espère que tous tes rêves soient exhaussés et je te souhaite tout le bonheur du monde ma chérie. A mon oncle Samir et ma chère tante Fouzia Franchement je ne trouve pas les expressions pour vous remercier, vous m’avez toujours considéré comme votre fille, vous étiez toujours là à me soutenir et à m’indiquer la bonne voie sans toutefois attendre de récompense. Vous êtes pour moi le plus magnifique modèle de générosité, de labeur et de persévérance. Merci pour vos efforts fournis afin de me soutenir… Merci pour le temps que vous avez consacré à mon futur… A Mon oncle Simohamed et ma chère tante Atika Vous êtes très chers à moi vous les deux, vous avez contribué de près à ma réussite, vous n’avez jamais hésité à me soutenir dans le meilleur et dans le pire. Milles merci pour vos encouragements, votre soutien et vos prières… Pour votre volonté ardente de me voir réussir… Pour votre bienveillance sur mon avenir… Je vous aime tant … A ma très chère grand-mère Toute ma reconnaissance pour ton amour, tes encouragements et ta tendresse. Que dieu te garde et te préserve pour nous. A mes adorables cousines et cousins : Dounia, Anis, Réda et ma petite Hiba Pour votre soutien et votre amour, pour tous les agréables moments que nous avons partagé ensemble, je vous dédie ce travail et je vous souhaite une vie pleine de bonheur et de réussite. A mes amis:Soukaina, Laila, Hanaa, Meriem,Soukaina hadane,Ilham,imane, Mohammed,Anass chaouki,Mostafa,Smail,Hassan,Youssef,Anas douras Merci d’être toujours là pour moi …

Nadia… II

REMRECIEMENTS

Au terme de ce travail, nous tenons à remercier vivement et profondément tous ceux qui ont contribué de près ou de loin à sa réalisation. De prime à bord, nous souhaitons exprimer toute notre gratitude à nos encadrants à l’Ecole Mohammadia d’Ingénieurs, Madame Laila Benhlima et Monsieur Slimane Bah qui nous ont soutenu tout au long de notre projet avec leurs directives pertinentes et leurs remarques très constructives. Nos ardents remerciements s’adressent également à Monsieur Said Abouks, Ingénieur d’état au sein de l’équipe ATAC du groupe HP CDG, pour la qualité de son encadrement, sa permanente disponibilité, et ses précieux conseils qui nous ont permis de mener à bien notre stage. Nous remercions chaleureusement Monsieur Anass Elouradani, Ingénieur et membre de l’équipe ATAC, pour son soutien, sa collaboration, ses orientations et ses explications enrichissantes. Nous exprimons également toute notre reconnaissance à Monsieur Mohamed Hadid, chef de l’équipe ATAC qui nous a fait l’honneur de nous confier ce projet, ainsi que tous les membres de l’équipe pour l’agréable ambiance de travail qui nous a permis une meilleure intégration dans un environnement chaleureux et bienveillant. Nos sincères remerciements pour les membres du Jury Madame Ounsa Roudies et Monsieur Driss Ghanami pour le temps qu’ils nous ont réservé afin d’évaluer notre humble travail. Nous tenons à rendre hommage au corps professoral du département informatique qui nous a fourni la matière première pour représenter notre école avec une meilleure image.

III

Résumé Affectées au pôle « Business Intelligence» de l’équipe ATAC au sein du groupe HP CDG, notre projet de fin d’étude s’inscrit dans le cadre de l’informatique décisionnelle. ATAC se charge de la gestion informatique de la totalité des entrepôts et des magasins du client ATAC Market qui représente une filiale de la chaîne des supermarchés du groupe Auchan. Dans ce contexte, et afin d’offrir aux managers du groupe un meilleur usage des données pour leur prise de décision, l’équipe se base actuellement dans son processus décisionnel sur une solution logicielle appelée Mapping. En fait, l’édition des tableaux de bord via cette solution nécessite l’intervention d’un informaticien qui doit sélectionner les tables concernées, élaborer les requêtes, et faire le traçage manuel de l’interface de ses rapports. De plus, l’équipe ATAC ne dispose pas d’un entrepôt de données propre au processus décisionnel, mais accède directement à la base de production pour la restitution des données. Cette méthode s’avère critiquable puisqu’elle augmente le temps de réponse de la base et crée une sorte de concurrence sur l’accès simultané aux données entre les traitements opérationnels et décisionnels. Pour remédier à tous ces problèmes, notre projet vise la mise en place un datamart destiné au suivi des différentes sorties du stock des magasins du compte ATAC. L’alimentation du datamart va s’effectuer en utilisant l’outil Talend. En outre, nous visons à migrer le processus d’analyse et de reporting vers la suite logicielle de Business Object afin

de

faciliter l’édition des tableaux de bord d’un coté, et permettre aux décideurs de consulter les indicateurs et créer eux même leurs propres rapports d’un autre coté, et cela en mettant à leur disposition une représentation métier organisée des données. Notre système va donc permettre de gagner en terme d’autonomie, d’ergonomie des interfaces, et de temps dans l’élaboration des rapports qui va être réduit à quelques secondes .

IV

‫ملخص‬ ‫يندرج مشروع نهاية الدراسة في إطار المعلوميات الهادفة إلى إتخاد القرارات أو ما يعرف‬ ‫ب"‪" Business Intelligence‬‬

‫و قد تم القيام به لدى فريق"‪ "ATAC‬بشركة ‪. HP CDG‬‬

‫يتكلف هذا الفريق بالتسيير المعلومياتي لجميع محالت ومستودعات الزبون"‪ "ATAC‬الذي يمثل‬ ‫إحدى فروع سلسلة المراكز التجارية لمجموعة "‪ ."Auchan‬و في هذا السياق‪ ،‬و من أجل منح‬ ‫مسيري المجموعة أفضل الطرق الستخدام البيانات الالزمة التخاذ القرارات الصائبة يعتمد حاليا‬ ‫الفريق على حل برنامجي يدعى "‪."Mapping‬‬ ‫في الواقع‪ ،‬يتطلب إصدار لوحات القيادة بواسطة هذا الحل تدخل خبير في المعلوميات من أجل‬ ‫إختيار الجداول‪ ،‬وضع الطلبات‪ ،‬وكذا التخطيط اليدوي لواجهة تقاريره‪ .‬زيادة على ذلك‪ ،‬فإن‬ ‫فريق"‪ "ATAC‬ال يمتلك مستودع بيانات خاص بعملية المساعدة على اتخاد القرار‪،‬ولكنه يلج مباشرة‬ ‫إلى قاعدة بيانات اإلنتاج السترجاع البيانات الضرورية ‪ .‬هذه الطريقة تظل غير ناجعة لكونها تزيد‬ ‫من زمن إستجابة القاعدة وتخلق نوعا من المنافسة على الولوج المتزامن إلى البيانات بين العمليات‬ ‫التقريرية والمعالجات العملية اليومية‪.‬‬ ‫من أجل التغلب على كل هذه المشاكل‪ ،‬يستهدف مشروعنا تصميم و إنشاء مستودع للبيانات أو ما‬ ‫يسمى ب "‪ "datamart‬من أجل متابعة مختلف مخارج مخزون محالت "‪ ."ATAC‬سيتم تزويد هذا‬ ‫األخير بالبيانات عن طريق إستعمال "‪ ."Talend‬عالوة على ذلك‪ ،‬نهدف من خالل مشروعنا إلى نقل‬ ‫عملية التحليل وتقديم التقارير أو ما يدعى ب"‪ "Reporting‬إلى مجموعة برامج" ‪Business‬‬ ‫‪ ،"Object‬لتسهيل وضع لوحات القيادة من جهة‪،‬وتمكين صناع القرار من معرفة المؤشرات وإعداد‬ ‫تقاريرهم الخاصة بأنفسهم من جهة أخرى‪ ،‬وذلك من خالل توفير تمثيل وظيفي منظم للبيانات‪.‬‬ ‫سيوفر النظام الذي نسعى إلى إنشائه استقاللية في العمل‪ ،‬وواجهات سهلة االستعمال‪ ،‬وربحا في الوقت‬ ‫الالزم إلعداد التقارير الذي سيتم تقليصه لبضع ثواني‪.‬‬

‫‪V‬‬

Abstract As member of the ATAC team’s business intelligence center within HP CDG group, our project is a part of the decision-making support system. ATAC is responsible of IT management of all warehouses and stores of its customer said “ATAC Market customer”. This later is a subsidiary of the supermarket chain Auchan. ATAC managers, as any manager, have to make the right decisions. Currently, in order to offer to the group’s managers a better use of the huge amount of data for decision making, the ATAC team is using a software solution called Mapping. However, publishing scorecards via this solution requires the involvement of an IT professional. Indeed, this later must select the relevant tables, implement queries, and make manual drawing of reports’ interface. Besides, the ATAC team does not have a specific data warehouse to support decision making. In other words, it retrieves data directly from the production database. This method is questionable as it increases the database response time and creates competition between operational and decision-making treatments due to simultaneous access to data. To address these issues, our project will implement a datamart for monitoring the various outputs of the ATAC account’s stores inventory. The datamart will be fed using the Talend tool. Furthermore, we aim to migrate the analysis and reporting process to the Business Object software suite. The goal is, on one hand, to make scorecards creation easier and on the other hand, to enable decision makers to view and create their own reports thanks to an organized business representation of the data. Therefore, our proposed system will have several benefits: autonomy, ergonomic interfaces, and time-saving for reporting. In fact, time will be reduced to few seconds only.

VI

Liste des abréviations : ABREVIATION

DESIGNATION

APPS

Applicatif Services

BI

Business Intelligence

BPO

Business Process Outsourcing

CA

Chiffre d’Affaires

CDG

Caisse de Dépôt et de Gestion

ERP

Entreprise Resource Planning

ETL

Extract Transform Load

GSD

Global Service Desk

HP

Hewlett Packard

ID

Informatique Décisionnelle

ISO

International Organisation for Standardization

IT

Information Technology

ITIL

Information Technology Infrastructure Library

ITO

Infrastructure Technology Outsourcing

PGC

Produits à Grande Consommation

RCP

Rich Client Platform

SWT

Standard Widget Toolkit

TOS

Talend Open Source

TTC

Toutes Taxes Comprises

TVA

Taxes sur la Valeur Ajoutée

VII

Liste des Figures : Figure 1.1 : Organigramme de l'equipe atac .................................................................................... 5 Figure 1.2 : Interface de l'erp gold ................................................................................................... 7 Figure 1.3 : Schema illustrant la demarche du traçage des tableaux de bord ................................... 9 Figure 1.4 : Planning de deroulement du pfe ................................................................................. 11 Figure 2.1 : Schema de l’organisation geographique du compte atac ............................................ 14 Figure 2.2 : Exemple de la structure marchandise du secteur pgc ............................................... 15 Figure 2.3 : Diagramme de cas d’utilisation decrivant les fonctionnalites du systeme .................. 16 Figure 2.4 : Diagramme de sequence- elaborer un rapport ............................................................ 17 Figure 2.5 : Schema en etoile ......................................................................................................... 19 Figure 2.6 : Schema en en flocon ................................................................................................... 20 Figure 2.7 : Schema conceptuel de l’iteration vente ...................................................................... 22 Figure 2.8 : Schema conceptuel de l’iteration demarque ............................................................... 24 Figure 2.9 : Schema conceptuel de l’iteration rupture de stock ...................................................... 25 Figure 2.10 : Schema conceptuel global du datamart ...................................................................... 26 Figure 2.11 : Processus decisionnel ................................................................................................. 27 Figure 3.1 : Diagramme de radar pour la comparaison des trois etls ............................................. 32 Figure 3.2 : Diagramme radar et le tableau d’evaluation des outils de reporting........................... 36 Figure 4.1 : Chargement de la dimension structure marchandise .................................................. 40 Figure 4.2 : Chargement de la table structure organisation ............................................................ 41 Figure 4.3 : Chargement de la table dimension temps ................................................................... 42 Figure 4.4 : Transformation de la date ........................................................................................... 43 Figure 4.5 : Chargement de la dimension type demarque .............................................................. 43 Figure 4.6 : Chargement de la table de fait vente ........................................................................... 45 Figure 4.7 : Traitement effectue pat le composant taggregaterow ................................................. 45 Figure 4.8 : Planification des jobs .................................................................................................. 45 Figure 4.9 : Temps de chargement de la table de fait demarque .................................................... 46 Figure 4.10 : L’univers ATAC ......................................................................................................... 49 Figure 4.11 : Interface desktop intelligence ..................................................................................... 50 Figure 4.12 : Navigation dans la hierarchie ..................................................................................... 50 Figure 4.13 : Rapport du pourcentage du chiffre d’affaires des magasins dans le reseau sud ......... 52 Figure 4.14 : Evolution du chiffre d’affaires dans le temps ............................................................. 52 Figure 4.15 : Quantite de demarques dans chaque secteur en fonction des types de demarque ...... 53 Figure 4.16 : Diagramme des quantites des demarques ................................................................... 53 Figure 4.17 : Nombre d’article en rupture....................................................................................... 54 Figure 4.18 : Taux de demarque en 2011 ......................................................................................... 54

VIII

Liste des tableaux : TABLEAU 3.1 : ILLUSTRATION DU RESULTAT DE L’EVALUATION……………………. 32 TABLEAU 4.1 : COMPOSANTS DE TALEND UTILISES……………………………………. 39 TABLEAU 4.2 : ETATS REALISES AU PROFIT DU COMPTE ATAC………………………. 51

IX

Sommaire Introduction .......................................................................................................................... 1 Chapitre 1 : Contexte général du projet .............................................................................. 3 1.1

Organisme d’accueil ......................................................................................................... 4

1.1.1

Présentation du groupe HP-CDG ............................................................................... 4

1.1.2

Présentation de l’équipe ATAC ................................................................................. 5

1.2

Cadrage du projet .............................................................................................................. 6

1.2.1

Cadre du projet .......................................................................................................... 6

1.2.2

Description du projet................................................................................................. 6

1.2.3

Etude de l’existant .................................................................................................... 7

1.3

Problématique ................................................................................................................... 9

1.4

Objectifs et solutions ...................................................................................................... 10

1.5

Conduite et démarche du projet .................................................................................... 11

Chapitre 2 : Analyse et conception .................................................................................... 13 2.1

Analyse des besoins......................................................................................................... 14

2.2

Les cas d’utilisation du système ..................................................................................... 16

2.3

Modélisation .................................................................................................................... 18

2.3.1

Notions clés de la modélisation multidimensionnelle .......................................... 18

2.3.1.1 Concept de dimension ............................................................................................ 18 2.3.1.2 Concept de fait ........................................................................................................ 18 2.3.1.3 Modèle de données ................................................................................................. 19 2.3.2

Choix du modèle de données .................................................................................. 20

2.3.3

Modélisation de l’itération vente : ......................................................................... 21

2.3.3.1 Indicateurs recueillis ................................................................................................ 21 2.3.3.2 Dimensions recueillies .............................................................................................. 21 2.3.3.3 Schéma conceptuel de l’itération Vente .................................................................. 22 2.3.4

Modélisation de l’itération démarque et dons aux associations :....................... 23

2.3.4.1 Indicateurs recueillis ................................................................................................ 23 2.3.4.2 Dimensions recueillies .............................................................................................. 23 2.3.4.3 Schéma conceptuel de l’itération Démarque ...................................................... 23 2.3.5

Modélisation de l’itération rupture de stock ....................................................... 24

2.3.5.1 Indicateurs recueillis .............................................................................................. 24 X

2.3.5.2 Dimensions recueillies ........................................................................................... 25 2.3.5.3 Schéma conceptuel de l’itération rupture de stock .............................................. 25 2.3.6

Schéma conceptuel global du datamart ................................................................. 26

Chapitre 3 : Etude comparative des outils ......................................................................... 28 3.1

Outils ETL ......................................................................................................................... 29

3.1.1

Présentation des ETL choisis .................................................................................. 29

3.1.2

Choix de l’outil ETL .................................................................................................. 30

3.2

Outils Reporting ............................................................................................................. 33

3.2.1

Présentation des outils Reporting .......................................................................... 33

3.2.2

Choix de l’outil Reporting ....................................................................................... 34

Chapitre 4 : Réalisation……………………………………………………………..….…38 4.1

Alimentation du Datamart .............................................................................................. 39

4.1.1

Composants Talend utilisés .................................................................................... 39

4.1.2

Alimentation des tables de dimensions ................................................................. 40

4.1.3

Alimentation des tables de faits ........................................................................... 44

4.1.4

Paramétrage de la fréquence de la mise à jour du datamart ............................... 45

4.1.5

Analyse du temps de chargement........................................................................... 46

4.2

Création de l’univers et reporting ................................................................................... 47

4.2.1

Création de l’univers................................................................................................ 47

4.2.2

Analyse et reporting ................................................................................................ 49

4.2.2.1 Analyses multidimensionnelles ................................................................................ 49 4.2.2.2 Reporting .................................................................................................................. 51

Conclusion .......................................................................................................................... 56 Bibliographie et Webographie............................................................................................ 57 Annexes…………...…………………………………………………………………...….59

XI

Introduction Dans leur quête de compétitivité, les entreprises essaient de plus en plus d’exploiter les informations dont elles disposent pour améliorer leur processus de prise de décision. Cependant, face à la multiplication des sources de l’information, le volume des données collectées croît progressivement et rend difficile d’organiser, d’exploiter, ou de comprendre ce qu’expriment ces informations: des tendances, des faiblesses ou des forces cachées. Ce problème

nuit grandement à la stratégie de l’entreprise et la met dans

l’obligation de bien manager ses informations pour en faire un réel avantage concurrentiel.

Tel est le cas pour la chaîne des supermarchés ATAC Market, filiale du groupe Auchan et acteur majeur de la grande distribution en France. Elle dispose de plus de 400 magasins situés dans diverses régions. Ces magasins mettent à la disposition de leurs clients plus de 10 000 références de produits. Dans ce contexte, si le chiffre d’affaires baisse dans une période bien précise, de nombreuses questions se posent : quelle est la gamme de produits touchée par cette baisse ? Dans quel segment de distribution ? Dans quelle région ? Le chiffre d’affaires varie-t-il de la même façon chaque année ?...etc. Pour répondre à ces questions, l’équipe ATAC chargée de la gestion informatique de la chaine des supermarchés ATAC Market utilise la solution logicielle Mapping dans son processus décisionnel. En fait, l’utilisateur de Mapping élabore ses rapports en interrogeant directement la base de production. Ceci augmente le temps de réponse du système puisqu’il nécessite l’exécution d’un certain nombre de jointures et d’agrégations pour obtenir le résultat souhaité. De plus, Mapping adapte une méthode de traçage manuelle des interfaces des rapports, Ce traitement fastidieux peut prendre toute une journée pour l’élaboration d’un seul tableau de bord. Il s’avère donc nécessaire de mettre en place un système propre au processus décisionnel englobant des données ciblées, agrégées et bien structurées avec une interface flexible et facile à utiliser. Ce dernier va permettre alors d’analyser le passé, le présent et de simuler l’avenir pour anticiper les changements de l’entreprise.

1

Ainsi notre projet de fin d’étude s’inscrit dans le cadre de l’informatique décisionnelle (ID) ou le Business Intelligence (BI). Il consiste à mettre en place un système qui répond au besoin de notre client ATAC, et qui permet d’obtenir une vision globale sur l’évolution de son activité. Ainsi ATAC, serait en mesure d’évaluer efficacement le flux de stock dans les différents magasins en traitant les ventes, les démarques (en d’autres terme les pertes produites dans les différents points de vente), ainsi que les diverses causes qui contribuent à la rupture des articles. Pour atteindre ces objectifs, notre projet s’est déroulé en deux phases principales. La première a consisté à créer une base de données décisionnelle (Datamart) qui englobe des données agrégées et bien structurées. Son rôle est d'intégrer et de stocker l'information utile aux décideurs et de conserver l'historique des données qui fera l’objet des analyses effectuées pour des prises de décision. Quant à la deuxième phase, elle permet de représenter les données collectées auparavant sous forme de tableaux de bord ou de graphes permettant ainsi aux managers d’élaborer eux même des rapports selon leurs propres besoins sans avoir recours au service informatique grâce aux fonctionnalités qu’offre l’outil Business Object.

Ce présent rapport se compose de quatre chapitres. Dans le premier nous introduisons le contexte général ainsi que la conduite du notre projet, ensuite nous passons à l’analyse et la modélisation conceptuelle de la base décisionnelle dans le deuxième chapitre. Le troisième chapitre parlera du choix des outils à utiliser, et finalement nous consacrons le dernier chapitre aux étapes de réalisation du projet à savoir la phase d’alimentation du Datamart et la phase de reporting. Enfin

nous ouvrons quelques perspectives pour notre projet

2

Rapport PFE

Chapitre 1 : Contexte général du projet

Chapitre 1

3

Rapport PFE


1.1 Organisme d’accueil : Nous présentons dans cette partie le groupe HP-CDG avec ses différentes activités, ainsi que l’équipe ATAC ou s’est déroulé notre stage. 1.1.1

Présentation du groupe HP-CDG

Le groupe HP-CDG est le résultat d’un partenariat entre HP, le leader mondial du marché IT et la Caisse de dépôt et de gestion (CDG). Ce partenariat vient dans le cadre du développement d’une plateforme de services informatiques tournée vers l’offshore francophone et hispanophone et à destination du marché intérieur marocain. [CDG, 2009] Depuis fin 2009, il est établi dans la technopole de Rabat, Technopolis. Au début de 2012, le capital humain de HP CDG IT Services Maroc s’élève à 715 personnes, la tranche d’âge est majoritairement de 19 à 29 ans. Il est important de noter que HP-CDG a décroché la certification ISO 27001 en Février 2011 et la certification ISO 9001 en Aout. De plus, 72 % des ressources de l'entreprise sont certifiées ITIL v3. 

Les activités de HP CDG :

L'entreprise offre des services dans différents domaines qui sont :  Data Center Services (ITO) : son but est de soutenir les projets et le fonctionnement d'un centre de données, avec comme activités principales : 

La gestion du stockage des données.



La gestion du réseau informatique.

 Global Service Desk (GSD): Point d’accès unique pour toutes les demandes du service informatique, c’est donc l’interface opérationnelle principale entre le service informatique et les utilisateurs.  Service applicatif (APPS) : Assure la conception, l’intégration, le déploiement des équipements applicatifs, ses principales activités sont : 

La maintenance des logiciels.



La mise en place d'une méthode de test aux différentes étapes d'un projet.



L’intégration ERP.



Le développement informatique.



L’assistance à maîtrise d’ouvrage.

4

Rapport PFE


 Business Process Outsourcing (BPO) : Sa principale activité est la réception et le traitement des demandes des clients. [wiki, 2011] Notre projet de fin d’études s’est déroulé dans le cadre du développement informatique du service applicatif APPS au sein de l’équipe ATAC. 1.1.2

Présentation de l’équipe ATAC

La société HP CDG prend en charge la gestion de plusieurs comptes clients parmi lesquels l’enseigne ATAC qui est une chaîne de supermarchés du groupe Auchan en France et qui contient près de 400 Supermarchés et 14 Entrepôts régionaux qui représentent les fournisseurs logistiques des points de vente. [HP CDG, 2012] La gestion de ce compte client est assurée au Maroc par l’équipe Back office ATAC divisée en 3 domaines :  Domaine Gold Stock : se charge du processus logistique, d’inventaire, et de transport ainsi que des détails de la facturation et des délais de livraison des marchandises.  Domaine Gold Central : centralise tous les flux de vente, d’achat et de réapprovisionnement, et travaille sur l’optimisation des prévisions de ventes et des stratégies de réapprovisionnement des stocks.  Domaine BI : gère le flux entre Gold Stock et Gold Central ainsi que le processus décisionnel.

Figure 1.1 : Organigramme de l'équipe ATAC

5

Rapport PFE


Une équipe de support N1 est disponible pour recevoir et répondre aux demandes du client en premier lieu au cas où elle dispose des procédures nécessaires à ce travail, sinon elle renvoie le problème à l’équipe du niveau 2. En plus de l’équipe Back office du Maroc, il y a l’équipe front office située en France qui se charge de la maintenance et de l’évolution des projets. 1.2 Cadrage du projet Après avoir présenté notre organisme d’accueil, nous passons à la présentation du cadre de notre projet ainsi que sa description. 1.2.1

Cadre du projet

Le développement rapide de la technologie, la forte concurrence dans le domaine commercial, le besoin d’une gestion archivée des données ainsi que de connaitre les tendances des clients sont tous des fortes raisons qui ont motivé ATAC pour développer un système d’aide à la décision visant à améliorer sa politique de vente dans ses divers magasins. Relativement à ce fait, notre projet s’inscrit dans le domaine de l’informatique décisionnelle connue en anglais par BI (Business Intelligence). Cette discipline désigne les outils et les méthodes qui permettent de collecter, modéliser et restituer les données d’une entreprise afin de lui donner une vision globale sur son activité, et permettre

aux

dirigeants de se baser sur des indicateurs et des analyses précises dans leurs décisions. Tout cela se fait via un entrepôt de données ( datawarehouse) qui représente une base centralisée de données spécifiques afin de faciliter l’analyse des informations de l’entreprise. Un datamart désigne un sous ensemble du datawarehouse contenant les données d’un secteur particulier exemple (Vente, Ressources humaines…). (Voir annexe E) 1.2.2

Description du projet

L’équipe ATAC où notre projet se déroule gère la totalité des sites (entrepôts et magasins) de l’enseigne en question. Cela nécessite

une étude globale de l’ensemble de ses

supermarchés pour donner aux décideurs les informations nécessaires sur leur activité commerciale, en particulier l’évolution du chiffre d’affaires des ventes qui présente sans doute la raison d’être de tout projet commercial.

6

Rapport PFE


De ce fait, notre travail a visé la mise en place d’un système décisionnel au profit du client ATAC pour le suivi des différents types des sorties du stock de ses magasins à savoir : 

Les ventes.



Les dons aux associations.



Les articles en démarque qui correspondent à l’ensemble des pertes des produits des magasins.

Ce système va pouvoir fournir des données agrégées et analysées aux dirigeants de l’enseigne sous forme de rapports et statistiques précises pour aider et contribuer à l’amélioration de la politique de vente. 1.2.3 Etude de l’existant : Afin de répondre à ses besoins décisionnels, l’équipe ATAC se basait auparavant sur un ensemble d’outils existants que nous allons expliciter dans ce qui suit. o L’ERP GOLD : Tous les membres du groupe Auchan travaillent dans un environnement applicatif identique qui déploie l’ERP G.O.L.D. C’est un progiciel commercialisé par l’éditeur Aldata et conçu spécialement pour répondre aux besoins des industries de la grande distribution du commerce de gros et de la logistique [Aldata, 2012]. G.O.L.D est structuré en deux modules : 

Module Gold Stock



Module Gold Central

Cela justifie la classification des domaines Gold Stock et Central Stock de l’équipe ATAC.

Figure 1.2: Interface de l'ERP GOLD 7

Rapport PFE


Gold offre des fonctionnalités pour aider l’ensemble des grands distributeurs de vente tels que la gestion des opérations en magasin, les prévisions, le réapprovisionnement, la logistique, la distribution, la gestion des fournisseurs…etc. Cette solution repose sur une base de données unique TPXTMI sur laquelle se basera notre projet. o Mapping Suite Pour l’exploitation de cette base de données dans la génération des rapports et des tableaux de bord, l’équipe ATAC utilise Mapping Suite. C’est une solution logicielle qui autorise la création et le pilotage de l’ensemble des éditions sur toute plateforme (iSeries/AS400, Unix, Linux, Windows), quelque soit l’origine des informations (base de données, ERP, fichiers, éditions…) et la destination (papier, mail, fax, Web…). Il faut noter également qu’elle dispose d’un ordonnanceur qui permet d’imprimer les éditions selon un paramétrage personnalisé en fonction du temps et du poste.

ATAC a acquis 3 modules Mapping qui sont principalement : 

SPOOLER MAPPING : ce module permet de visualiser, supprimer, libérer et transférer les spools (fichiers d'édition envoyés vers un périphérique d'impression).



MAPREPORT : permet d'extraire les données des sources diverses.



MAPDRAW : Il inclut une interface de dessin destinée à la réalisation des fonds des pages et une autre permettant d'élaborer les maquettes. [Mapp, 2012]

Malgré la diversité des fonctionnalités que Mapping suite offre, elle son utilisation reste critiquable dans certains points parmi lesquels: 

L’exploitation directe de la base de données : elle accède directement aux données de la base de production ce qui augmente le temps de réponse pour les utilisateurs quotidiens et altère donc les performances de la base.



Traçage des tableaux de bord manuellement. En effet, une fois les données sont restituées depuis la base source, l’utilisateur est amené à tracer lui-même l’interface graphique de ses rapports dans le module MAPDRAW, et cela en indiquant les coordonnées (X, Y, L, H) selon la taille des champs qu’il veut insérer. Cette démarche de traçage est schématisée dans la figure 1.3 suivant :

8

Rapport PFE


Coordonnées (X,Y,Y,Z)

Figure 1.3 : Schéma illustrant la démarche du traçage des tableaux de bord

Ces inconvénients rendent le travail fastidieux et inflexible pour l’équipe BI surtout pour le développement et la maintenance des éditions de reporting opérationnelles ou décisionnelles. A travers l’étude et l’analyse du système existant, nous avons pu dégager un ensemble de failles et de problèmes qui entravaient le bon déroulement du processus décisionnel, ce qui va présenter l’objet de la problématique. 1.3 Problématique L’équipe BI du back office élabore des rapports opérationnels qui traitent l’activité des sites du groupe ATAC quotidiennement, ainsi que d’autre décisionnels pour offrir aux décideurs une vision détaillée et bien analysée sur leur projet. Pour ce faire, elle accède directement à la base de production pour restituer les données. En effet, pour calculer un indicateur donné tel que le chiffre d’affaires par exemple, il faut parcourir la base de données pour effectuer les agrégations et les jointures nécessaires afin d’obtenir le résultat souhaité puisqu’on ne dispose pas des données calculées et agrégées propres à l’analyse. Cette méthode s’avère critiquable puisqu’elle altère la performance de la base ainsi que son temps de réponse qui augmente progressivement en fonction du nombre des traitements à faire, surtout quand il s’agit d’une base aussi volumineuse que celle du client ATAC. De ce

9

Rapport PFE


fait, l’élaboration des rapports prendra un temps assez considérable surtout les rapports décisionnels qui nécessitent une historisation de données à long terme. En outre, la manipulation graphique des interfaces et le traçage manuel des tableaux de bord rend le travail difficile et fastidieux. De plus, l’édition des rapports en utilisant cette solution nécessite l’intervention d’un informaticien qui doit sélectionner les tables concernées, élaborer les requêtes, et faire le traçage manuel de l’interface de ses rapports. Le recours à cette solution crée aussi une sorte de concurrence sur l’accès simultané aux données de production entre les traitements quotidiens effectués dans la base et les requêtes visant à établir les rapports décisionnels. 1.4 Objectifs et solutions Pour répondre à cette problématique, le client ATAC a jugé utile de concevoir et mettre en place un datamart qui englobe tous les indicateurs stratégiques et essentiels à son métier et qui permet d’anticiper sur l’avenir tout en réduisant le temps et les efforts déployés pour assembler, transformer, modéliser et diffuser

les informations aux décideurs et aux

analystes du service commercial. La mise en place du nouveau datamart vise alors à :  Diminuer la charge de génération des rapports et des tableaux de bord sur la base de production.  Produire des rapports sur des données de longue durée d’historisation et avec un temps de réponse acceptable.  Garantir la fiabilité des informations.  Séparer le traitement quotidien effectué dans la base de production des requêtes provenant du processus décisionnel. Le client ATAC décide également de migrer une partie de son processus de reporting vers la suite logicielle de Business Object afin de :  Faciliter le processus grâce à la flexibilité qu’il offre dans l’élaboration des rapports.  Permettre aux décideurs de consulter et éditer même les rapports sans avoir recours au service informatique grâce à sa couche sémantique qui est une présentation des données avec un vocabulaire métier.  Permettre le partage des rapports entre les services concernés.

10

Rapport PFE


Ainsi nous souhaitons assurer un suivi de tous les types des sorties du stock magasin à savoir : les ventes, les articles en démarque et les dons aux associations selon plusieurs axes d’analyse afin de mettre à la disposition des décideurs des informations précises et efficientes sur des indicateurs stratégiques tels que : le chiffre d’affaires de chaque site, les quantités vendues selon les marques des produits, le nombre d’articles en démarque pour un rayon donné … etc. Pour mener à bien notre projet nous décrivons dans la suite la conduite qu’il va adopter. 1.5 Conduite et démarche du projet Pour réaliser la solution proposée, nous avons adopté la démarche suivante :  Etude de l’existant : cette phase sert à connaitre le système de production de l’entreprise, notamment les données utiles pour le projet afin de bien cerner la problématique existante.  Analyse des besoins : cette phase vise à déterminer les besoins des décideurs en termes d’indicateurs à calculer et d’axes à analyser.  Etude comparative et installation des outils : cette phase est consacrée au choix de l’outil le plus adapté aux besoins du projet et aux contraintes techniques de l’entreprise.  Conception et modélisation : cette étape présente le modèle de données du datamart réalisé, tout en se basant sur les besoins exprimés dans la phase précédente.  Réalisation : il s’agit dans cette étape de la création et l’alimentation du datamart et puis son exploitation dans l’édition des rapports via les outils choisis.

Figure 1.4: Planning de déroulement du PFE 11

Rapport PFE


Nous avons adopté dans cette conduite le Prototypage incrémental comme cycle de vie. En effet, le développement suit une démarche incrémentale qui consiste à segmenter le travail en plusieurs itérations (voir figure 1.4). Après l’évaluation et la validation du prototype, on passe au suivant et ce cycle est répété jusqu’à atteindre un produit complet et satisfaisant les besoins du client. [Hugues, 2002] Dans notre cas nous nous sommes focalisées dans un premier temps à analyser, concevoir et réaliser la partie réservée aux ventes et qui représente notre premier prototype, puis nous sommes passées au 2éme prototype en ajoutant le volet des démarques qui inclut aussi les dons aux associations et finalement la dernière partie que nous avons suggérée et qui concerne l’analyse des ruptures des articles en stock. Conclusion : Cette étude nous a permis de connaitre l’environnement du travail, d’analyser l’existant constitué de l’ERP GOLD et de la suite Mapping et de poser finalement la problématique. Pour résoudre cette dernière, nous avons proposé la mise en place d’un nouveau datamart, ainsi que la migration du processus reporting vers la suite logicielle de Business Object. Nous passons dans le chapitre suivant à l’analyse des besoins et la modélisation du datamart que nous souhaitons réalisé.

12

Rapport PFE

Chapitre 2 : Analyse et conception

Chapitre 2

13

Rapport PFE


Nous nous intéressons dans le présent chapitre à l’analyse des besoins du client ATAC, nous décrivons ensuite les différents indicateurs relatifs à cette analyse ainsi qu’aux objectifs cités dans le premier chapitre et en fin nous présentons le modèle de données du datamart que nous avons élaboré. 2.1 Analyse des besoins Notre projet vise à satisfaire les besoins de la série des supermarchés du groupe Auchan qui souhaite faire un suivi des sorties de son stock selon plusieurs axes d’analyse

y

compris : 

L’organisation géographique ou le réseau commercial : représente la structure selon

laquelle les magasins sont organisés géographiquement. En effet, il existe 9 réseaux chacun contient un nombre défini de régions et chaque région englobe plusieurs magasins [HP CDG, 2012]. Cette structure est schématisée comme suit :

Figure 2.1: Schéma de l’organisation géographique du compte ATAC

Les réseaux intégrés contiennent les propres sites d’ATAC par contre les franchisés sont ceux qui commercialisent les produits d’un autre groupe de supermarchés selon un contrat de franchise. 

la structure interne des marchandises : elle décrit l’hiérarchie selon laquelle les

articles sont stockés dans le magasin en partant du secteur jusqu’aux articles et elle est constitué de 7 niveaux hiérarchiques. Afin de bien saisir cette notion d’hiérarchie nous proposons dans la figure 2.2 un exemple de la structure marchandise du secteur des produits à grande consommation (PGC).

14

Rapport PFE


Figure 2.2 : Exemple de la structure marchandise du secteur PGC

Relativement à cette répartition géographique des sites du groupe et prenant en considération le regroupement hiérarchique des articles au sein des magasins, nous avons pu définir les principaux besoins du client ATAC comme suit :  Analyse du chiffre d’affaires réalisé, de la quantité vendue, ainsi que du rendement de la série des supermarchés selon plusieurs axes afin de cibler les zones fortes en terme de rentabilité et chercher à améliorer le rendement des autres. 

Etude des démarques qui correspondent à l’ensemble des pertes des produits des magasins en termes de valeur et de quantité selon les diverses types de démarque (la casse, les produits périmés…) afin de pouvoir calculer le taux de démarque ou de perte par rapport aux ventes réalisées.



Calcul en quantité et en valeur des dons aux associations pour avoir une idée globale sur leur pourcentage par rapport aux bénéfices.

De plus, nous avons jugé qu’il serait aussi judicieux d’analyser les ruptures du stock dans les différents sites, puisqu’elles influencent négativement au bon déroulement du processus des ventes. Ceci aura nécessairement de l’impact sur le chiffre d’affaires de la série qui présente l’objectif et l’indicateur primordial de chaque unité commerciale.

15

Rapport PFE


De ce fait nous avons proposé une analyse des ruptures en suggérant deux autres indicateurs à calculer, à savoir : 

Le nombre des produits en rupture dans les stocks des magasins en fonction des sites, de la structure marchandise, et de la cause de la rupture.



La durée moyenne de rupture des articles dans les différents magasins en fonction du motif de la rupture.

Dans le cadre de cette spécification des besoins du projet, nous avons établi un diagramme de Usecase pour définir aussi bien les acteurs de notre système que les services qu’il offre. 2.2 Les cas d’utilisation du système : Il y a 3 acteurs qui interagissent avec le système que nous avons élaboré à savoir : le décideur, l’analyste de l’équipe marketing et l’administrateur ou l’informaticien de l’équipe BI. Nous résumons les différents services offerts par notre système dans le diagramme suivant :

Figure 2.3: Diagramme de cas d’utilisation décrivant les fonctionnalités du système

Les services offerts par le système sont :  Consultation des rapports : Le décideur ainsi que l’analyste du service commercial et marketing accèdent au système après une authentification puis choisissent parmi les rapports et les tableaux de bord déjà élaborés ceux qu’ils souhaitent visualiser.  Elaboration des rapports : le système offre aussi aux décideurs et aux analystes du service commercial la possibilité de créer leurs propres rapports juste en cliquant sur les indicateurs et les axes selon lesquels ils veulent possibilité, les analystes

les élaborer. Grâce

à cette

marketing de l’enseigne ATAC vont pouvoir suivre les

variations des différents indicateurs. Cela va permettre de cibler les produits de faible 16

Rapport PFE


rentabilité pour analyser les causes de ces variations et proposer aux décideurs des solutions capables d’améliorer le rendement du groupe.  Ajout des indicateurs : l’administrateur du système ou l’informaticien de l’équipe BI du compte ATAC peut ajouter d’autres indicateurs en relation avec les données du datamart selon l’évolution des besoins du groupe.  Paramétrage du système : l’administrateur peut aussi modifier ou rectifier la politique du rafraichissement des données du datamart selon ses besoins. Nous détaillons dans la figure 2.4 le cas d’utilisation de l’élaboration des rapports sous forme du diagramme de séquence.

Figure 2.4: Diagramme de séquence- Elaborer un rapport

Après l’authentification, l’utilisateur choisit d’abord la forme du rapport qu’il souhaite crée, ensuite il indique les indicateurs et les dimensions selon lesquels il veut effectuer ses analyses, et finalement il pose ses conditions souhaitées sur les données pour exécuter et récupérer le rapport à la fin. Apres avoir analysé les besoins du client ATAC et présenté les fonctionnalités de notre système nous passons maintenant aux différentes étapes de sa modélisation.

17

Rapport PFE


2.3 Modélisation Avant d’entamer la modélisation nous étions amenés tout d’abord à collecter et comprendre les données relatives au domaine de la vente du groupe Auchan afin de sélectionner ce qui nous sera utile pour répondre aux besoins établis. Ainsi nous avons suivi les étapes suivantes :  Déterminer les tables sources dans la base de production sur lesquelles nous allons se baser pour récupérer les données nécessaires à notre projet.  Identifier les différents indicateurs de performance à calculer et à exprimer en fonction des besoins expliqués auparavant.  Identifier les dimensions ou les axes d’analyse suivant les besoins des décideurs tout en attribuant à chaque axe une certaine hiérarchie afin d’accroitre le degré d’analyse.  Etablir le schéma conceptuel. Suivant le cycle de vie de notre travail cette démarche a été adoptée dans chaque itération. 2.3.1

Notions clés de la modélisation multidimensionnelle :

Un entrepôt de données est le lieu de stockage centralisé d'un extrait des bases de production, il est organisé suivant

un modèle spécifique qui facilite les traitements

décisionnels. Suivant cette définition, les données à analyser au niveau d'un entrepôt doivent correspondre à une structuration selon plusieurs axes d'analyse pouvant représenter des notions variées telles que le temps, la localisation géographique…etc. On parle alors de modélisation et des traitements multidimensionnels des données. Conceptuellement, cette modélisation multidimensionnelle a donné naissance à deux concepts: fait et dimension [Dw, 2006]

2.3.1.1 Concept de dimension : Une dimension modélise une perspective de l'analyse. Elle contient des attributs permettant de qualifier ou d’expliquer l’activité. Elle peut être aussi munie d'une hiérarchie pour restreindre ou accroître le degré d'analyse. [Dw, 2006] 2.3.1.2 Concept de fait : Le fait modélise le sujet de l'analyse. En effet. C’est une table formée de mesures correspondantes aux informations de l'activité analysée. Ces mesures sont numériques et 18

Rapport PFE


représentent les indicateurs de performances que visent les analystes comme le chiffre d’affaires, la quantité vendue…etc. Cette table contient donc de plus les identifiants des tables de dimensions. [Dw, 2006] 2.3.1.3 Modèle de données : Un modèle de données est une façon de mettre en relation les dimensions et les faits dans un entrepôt de données. Nous présentons trois types de modèles à savoir: le modèle en étoile, le modèle en flocon et le modèle en constellation. [Dw, 2006]  Modèle en étoile: Dans un schéma en étoile comme le montre la figure 2.5, une table centrale de fait référence les tables de dimensions par des clés étrangères. Chaque dimension est décrite par une seule table dont les attributs représentent les diverses granularités possibles. Il est appelé modèle en étoile parce que toutes les dimensions sont directement reliées à la table de faits. [Dw, 2006]

Figure 2.5: Schéma en étoile

 Modèle en flocon : Dans un schéma en flocon illustré dans la figure 2.6, la table de fait référence juste les tables de dimensions du premier niveau. Contrairement au modèle en étoile, ce type de modélisation consiste à décomposer les dimensions en sous hiérarchies. La modélisation en flocon est donc une émanation du modèle en étoile. En effet, le fait est conservé et les dimensions sont éclatées selon l’hiérarchie des paramètres. Nous décrivons le même exemple du modèle en étoile mais cette fois ci en utilisant le modèle en flocon [Dw, 2006] :

19

Rapport PFE


Figure 2.6: Schéma en en flocon

 Modèle en constellation : Une constellation est une série d'étoiles reliées entre elles par des dimensions. Il s'agit donc d'étoiles avec des dimensions en commun. L’objectif est d’avoir un environnement décisionnel où il serait possible de naviguer d'étoile en étoile à la recherche de l'information. [Dw, 2006]

2.3.2

Choix du modèle de données

Pour modéliser notre système décisionnel nous avions le choix entre deux types de modélisation à savoir : le modèle en étoile et le modèle en flocon de neige. Nous avons opté pour le modèle en étoile parce ce nous avons jugé qu’il est le mieux adapté à notre cas d’utilisation puisqu’il est considéré comme étant le modèle le plus simple, surtout au niveau des jointures entre les différentes tables du datamart. En effet, nos tables de dimensions contiennent plusieurs niveaux d’hiérarchie donc le choix du modèle en flocon donnera naissance à des requêtes plus complexes et moins performantes à causes de la multiplicité des jointures. Le modèle en étoile permet donc de faciliter la navigation entre les tables de fait et de dimension et rend la restitution des données plus fluide. En outre, le modèle en flocon est considéré comme étant le mieux adapté pour la cardinalité (n-n) entre les tables de dimensions. Or dans notre cas toutes les dimensions recueillis sont de cardinalité (1-n). En effet, si on prend l’exemple de la structure marchandise, la relation entre les différents niveaux d’hiérarchie est toujours de cardinalité (1-n) : un article appartient à un seul segment et un segment contient plusieurs articles et de

20

Rapport PFE


même pour les autres niveaux de la structure. Par conséquent, le modèle en étoile est très suffisant pour répondre à nos besoins. 2.3.3 Modélisation de l’itération vente : 2.3.3.1 Indicateurs recueillis : En se basant sur les besoins exprimés des utilisateurs finaux de notre système, nous avons pu dégager un ensemble d’indicateurs nécessaires à évaluer les ventes du client ATAC et qui sont : 

Le chiffre d’affaires (CA) ou le montant total des ventes de chaque entité du

réseau commercial du groupe Auchan, et par rapport aux différents niveaux de la structure marchandise (rayon, famille, segment…). Cet indicateur va permettre aux décideurs de distinguer entre les surfaces de ventes de fort rendement et d’autres qui ne réalisent pas un grand chiffre d’affaires. Le CA sera aussi calculé pour une unité de temps bien précise qui va d’une journée à une année par rapport aux marques des produits et leur type afin de montrer aux dirigeants les articles les plus sollicités par les clients. Cet indicateur est calculé via la relation suivante : Chiffre d’affaires TTC (toute taxe comprise) = Prix unitaire TTC * quantité vendue 

La marge ou la rentabilité de la série des supermarchés qui se calcule comme suit Marge = chiffre d’affaires – coût de revient

Le coût de revient présente la somme des dépenses ou des charges mises en œuvre pour la production d’un article de la série. 

Quantité vendue des articles par magasin, par secteur, par marque…etc. et même

par unité de temps ce qui va aider à savoir les périodes de l’année où la consommation augmente et quels sont les types des produits qui sont concernés ?

2.3.3.2 Dimensions recueillies Selon l’analyse des besoins que nous avons effectué et prenant en compte les données disponibles et les indicateurs à calculer, nous avons relevé les dimensions suivantes qui nous ont permis grâce à leur hiérarchie de détailler l’analyse tout en passant d’un niveau de granularité à un autre plus fin et vice versa. 

Dimension temps : C’est l’axe d'analyse le plus fréquent dans la construction des

datamarts. Il est commun à toutes les tables de fait de notre entrepôt de données. Son

21

Rapport PFE


importance vient du fait qu’il permet de situer dans le temps chaque fait enregistré, ainsi que de suivre son évolution périodique. 

Dimension Réseau commercial ou structure de l’organisation géographique. Cette

dimension va permettre de savoir par exemple : les régions qui sont plus rentables, à quel réseau appartiennent-elles ? ...etc. Ce qui va détecter les préférences des clients par secteur géographique. 

Dimension structure marchandise pour détailler l’analyse et pouvoir préciser par

exemple quelle est la famille des produits la plus sollicitée ? quel est le secteur qui génère un grand chiffre d’affaires ?...etc. 2.3.3.3 Schéma conceptuel de l’itération Vente L’identification des indicateurs à calculer et le choix des axes d’analyse nous a mené à élaborer la première table de fait vente illustrée dans la figue 2.7 qui contient toutes les données relatives aux ventes et nécessaires pour le calcul des indicateurs recueillis, à savoir : le chiffre d’affaires, la quantité vendue et la marge ou la rentabilité du groupe. La table vente est aussi liée aux trois dimensions nécessaires au calcul des indicateurs et à l’analyse des données : le réseau commercial, la structure des marchandises et finalement l’axe temps.

Figure 2.7: Schéma conceptuel de l’itération vente

22

Rapport PFE


2.3.4 Modélisation de l’itération démarque et dons aux associations : 2.3.4.1 Indicateurs recueillis ATAC comme toute autre unité commercial enregistre à chaque période du temps une quantité de perte au niveau de ses produits. De ce fait, nous nous sommes intéressées à calculer les indicateurs en relation avec les démarques ainsi que les dons qu’offre le groupe aux associations à savoir :  Quantité des démarques ou de l’ensemble des pertes des produits et cela inclut aussi la quantité des dons aux associations.  Valeur des démarques : présente le coût de perte que génère une démarque.  Taux de démarque : présente la valeur des démarques par rapport au chiffre d’affaires d’une entreprise : Taux de démarque = valeur des démarques / chiffre d’affaires. Ce dernier indicateur permet d’évaluer le poids des pertes des produits dans les différents magasins ce qui permettra de mesurer l'efficacité des pratiques d'entreposage et de gestion du stock. Pour calculer ces mesures nous avions besoin de quatre dimensions. 2.3.4.2 Dimensions recueillies Les démarques seront aussi analysées selon l’échelle temporelle, géographique, et même suivant la structure des marchandises pour déterminer les familles des produits qui enregistrent plus de pertes, les réseaux qui soutiennent plus les associations, etc. Par conséquent cette itération partage avec les ventes les trois dimensions : Temps, Structure marchandise et Réseau commercial. De plus, nous rajoutons une dimension spécifique aux démarques qui est : 

Dimension Type Démarque : Cette dimension définit le type de démarque, s’il

s’agit d’une casse ou un produit périmé par exemple. Elle inclut aussi les dons aux associations puisque tous les deux ne participent pas à l’évolution du chiffre d’affaires. Donc la distinction entre les dons et les pures démarques se fera en spécifiant juste l’id_type correspondant. 2.3.4.3 Schéma conceptuel de l’itération Démarque Le calcul des indicateurs propres à l’itération démarque se fait via la table de fait Démarque qui regroupe toutes les informations liées aux deux types de mouvements : démarques et dons aux associations dans le stock du compte ATAC. Afin de différencier 23

Rapport PFE


entre les dons et les autres démarques nous avons filtré selon le type de démarque comme le montre la figure 2.8. La table de fait Démarque est reliée aux quartes dimensions citées auparavant.

Figure 2.8: Schéma conceptuel de l’itération démarque

2.3.5 Modélisation de l’itération rupture de stock 2.3.5.1 Indicateurs recueillis Toujours dans le cadre de l’amélioration de la politique des ventes du groupe, nous avons proposé d’analyser les ruptures dans le stock des magasins pour remédier à tout problème provenant de ce type d’évènement et altérant par conséquent le bon déroulement du processus vente. Pour ce faire nous avons évalué les mesures suivantes :  Durée rupture : Cet indicateur sert à évaluer la durée que prennent les articles pour réapparaitre dans l’assortiment d’un point de vente donné, en d’autre termes, c’est la durée nécessaire pour qu’un article redevienne disponible dans la liste des produits proposés à la vente après sa rupture.  Nombre d’article : il permet de visualiser le nombre d’article en rupture dans le stock des magasins et de détecter même la cause de ces ruptures, ce qui permettra au groupe d’agir pour les éviter ou au moins les diminuer.

24

Rapport PFE


2.3.5.2 Dimensions recueillies Afin de permettre aux décideurs de prendre les mesures nécessaires et capables de remédier aux problèmes des ruptures du stock nous avons jugé intéressant de connaitre le nombre d’articles en rupture dans chaque zone géographique, la durée moyenne de rupture dans un rayon donné des marchandises… etc. D’où la nécessité d’une analyse selon les trois dimensions : Temps, Structure marchandise et Réseau commercial. En outre, nous avons proposé la dimension suivante :  Dimension Cause Rupture : cette dimension spécifie les différentes causes qui peuvent être à l’origine de la rupture d’un article comme exemple Vente. C'est-à-dire que le produit est suspendu parce qu’il était complètement vendu. Cette dimension aidera à avoir un aperçu sur les causes les plus fréquentes et donc de prévoir des précautions pour éviter ou diminuer les ruptures. 2.3.5.3 Schéma conceptuel de l’itération rupture de stock : Les deux indicateurs proposés : nombre d’article et durée moyenne de rupture vont être calculés dans la table de fait Rupture schématisée dans la figure 2.9. Afin d’assurer l’analyse multidimensionnelle, cette table est reliée aux quartes dimensions déjà explicitée:

Figure 2.9: Schéma conceptuel de l’itération rupture de stock

25

Rapport PFE


2.3.6 Schéma conceptuel global du datamart La suite logique de notre conception nous a mené à concevoir un schéma en constellation pour notre datamart qui consiste à fusionner plusieurs modèles en étoile utilisant des dimensions communes.

Figure 2.10: Schéma conceptuel global du datamart

Ainsi la figure 2.10 englobe les trois tables de fait : vente, démarque et rupture

qui

construisent le schéma final de notre datamart. L’analyse est partagée selon trois dimensions essentielles : temps, réseau commercial et structure marchandise. Les deux autres dimensions spécifiques type démarque et cause rupture feront l’objet de l’analyse des démarques et des ruptures respectivement. Ce dernier schéma va être transformé en réalité à des tables dans un nouveau datamart. Ces tables contiendront les données nécessaires à l’analyse et au reporting. Nous illustrons alors brièvement ce processus décisionnel dans ce qui suit. 2.2 Processus décisionnel : Comme tout projet BI, notre projet passe par un processus décisionnel qui part de la collecte des données jusqu’à leur affichage sous forme d’états de reporting. Nous résumons ainsi les quatre phases de notre chaine décisionnelle dans la figure 2.11. 

Identification des sources de données : pour la collecte des données, nous nous sommes basées sur la base de données oracle de l’ERP GOLD. Il suffit donc de sélectionner les tables nécessaires à notre thématique. 26

Rapport PFE




Alimentation de la base de données décisionnelle : C’est à ce niveau qu’apparait la première couche logicielle de l’environnement décisionnel à savoir l’ETL qui fait le traitement nécessaire et alimente la base décisionnelle destinataire. (Voir annexe E)



Création de l’univers et analyse multidimensionnelle : consiste à créer tout d’abord une représentation métier des données appelée univers avec l’outil Business Object. Cet univers contient les indicateurs calculés et prêts à être analyser selon

les besoins. Une fois l’univers est crée, le système

offre la

possibilité d’analyser les données selon les diverses dimensions et de naviguer dans les différents niveaux hiérarchiques afin de permettre une analyse plus poussé des données. 

Reporting : c’est l’étape finale et le fruit de tout processus BI, elle consiste à créer des états sous plusieurs formes : tableaux, digrammes de camembert, histogramme, etc. Cette bonne représentation des données permet de bien les manager pour en faire un réel support d’aide à la décision. (Voir annexe E)

Figure 2.11: Processus décisionnel

Conclusion : Dans ce chapitre, nous avons relevé un ensemble d’indicateurs stratégiques à calculer suivant des axes d’analyses adéquats. Ensuite nous avons explicité la modélisation de chaque itération du projet en utilisant le modèle en étoile pour donner au final le schéma conceptuel global de notre datamart. Pour mener à bien le processus décisionnel pré décrit qui part de la collecte de données jusqu’à leur présentation sous forme d’états, il faut faire le bon choix des outils utilisés. C’est ce qui fera l’objet du chapitre suivant. 27

Rapport PFE

Chapitre 3 : Etude comparative des outils

Chapitre 3

28

Rapport PFE


Nous avons consacré ce chapitre à la justification du choix des outils utilisés dans les deux phases de notre projet, à savoir l’alimentation du datamart et la phase du reporting pour la présentation des rapports. Pour la première phase, nous avons choisi de comparer entre les Open source «Talend Open Studio», «Pentaho Data Integration » (« Kettle » à l'origine), et « Clover ETL » puisque notre société ne souhaite pas investir financièrement dans l’achat d’une licence d’un logiciel de ce genre. La 2éme partie sera dédiée à la comparaison du « BusinessObject » et « Pentaho Reporting suite ». 3.1 Outils ETL : L’ETL est l'acronyme de « Extract – Transform -Load ». Il permet de faire l’extraction ou le chargement des données depuis différentes sources qui peuvent être hétérogènes, puis leurs transformations afin de les rendre homogènes, et enfin le chargement dans la base cible. Pour réaliser notre datamart, nous avons choisi de comparer entre « Pentaho Data Integration », « Talend Open Studio » et « Clover ETL », car ils nous apparaissent les plus utiles et intéressants à l’heure actuelle comme étant des ETL Open source. Nous présentons dans ce qui suit chacun de ses outils et nous établissons ensuite l’étude comparative selon différents critères. 3.1.1

Présentation des ETL choisis :  Talend Open Studio

Talend Open Studio est développé par Talend en 2006, qui est une société française relativement jeune. Il génère un code spécifique en Java ou Perl pour intégrer les données. Talend Open Studio utilise une interface graphique, le « Job Designer » qui permet la création des processus de manipulation de données. Il contient aussi une palette graphique de plus de 250 composants et connecteurs. [Atol, 2007]  Pentaho Data Integration (Enciennement KETTLE) Pentaho Data Integration est un outil ETL de la suite décisionnelle Open Source Pentaho. Il dispose d'une interface graphique « Spoon » depuis laquelle on peut créer les traitements qui sont stockés dans un référentiel (repository). [Atol, 2007]  Clover ETL Clover a créé deux outils : Clover ETL qui est un framework et Clover.GUI interface graphique facilitant la création de flux de données, mais elle est disponible sous licence commerciale, et tous les deux sont basés sur la technologie Java. Clover met à la 29

Rapport PFE


disposition des utilisateurs une quarantaine de composants de transformation et supporte en natif plusieurs SGBD. [Axege, 2012] 3.1.2

Choix de l’outil ETL :

Nous avons effectué l’étude des 3 outils Talend Open Studio, Pentaho Data Integration et selon plusieurs aspects de comparaison. Nous présentons ci-après une synthèse de la comparaison de ces outils par critère :  Communauté Une communauté dynamique et large d’un outil constitue un critère important pour refléter sa réputation et sa fiabilité. Ainsi nous pensons qu’il serait logique que notre choix opte pour celui qui est soutenu ou financé par un grand organisme ou des experts. Concernant cet aspect, nous signalons un avantage de Talend Open Studio et de Pentaho Data Integration qui sont les plus utilisés au monde, et qui sont tous les deux développés par les sociétés Talend Open Integration solutions et Pentaho. Quant à Clover ETL, il s’avère que sa communauté est beaucoup plus restreinte et moins active que les deux autres. [Atol, 2007] [Axege, 2012]  Ergonomie L’interface Clover ETL nécessite l’installation d’Eclipse sur la machine, Pentaho et Talend disposent d’une interface graphique basée respectivement sur SWT(Standard Widget Toolkit) et Eclipse RCP(Rich Client Platform).Mais Talend reste le plus facile à utiliser du point de vue ergonomique. [Atol, 2007] [Axege, 2012]  Intégration dans une suite BI Talend est partenaire des éditeurs des suites décisionnelles connues sur le marché à savoir SpagoBI et JasperIntelligence, alors que l’intégration de Kattle dans la suite Pentaho est en cours. Par contre, Clover ETL n’a pas été intégré jusqu’à présent. [Atol, 2007] [Axege, 2012]  Documentation La disponibilité de documentation, des supports professionnels et des séminaires de formation sur l’utilisation et les fonctionnalités qu’offre un outil sont nécessaires pour le succès de son déploiement. Actuellement, Les sociétés qui prennent en charge Talend Open Studio et Pentaho Data Integration effectuent de nombreux séminaires qui suscitent un très grand intérêt de la part de la communauté BI. [Atol, 2007] [Axege, 2012]

30

Rapport PFE


 Accessibilité Pour ce critère il faut noter que l’utilisation de l’interface graphique Clover GUI est payante contrairement à Talend Open Source(TOS) et Pentaho Data Integration(PDI). [Atol, 2007] [Axege, 2012]  Compatibilité TOS et PDI gèrent la plupart des SGBD nativement et permettent aussi l’accès à une très grande diversité de fichiers (XML, Excel, CSV, ZIP, etc.). Cependant, Clover ETL, même s'il est compatible avec les principaux formats mais reste moins satisfaisant à ce niveau. [Atol, 2007] [Axege, 2012]  Lecture et écriture dans un SGBD Talend Open Studio montre ici un avantage par rapport aux autres ETL puisqu’il permet : 

La lecture et l’écriture des données complexes des systèmes d’informations géographiques.



un designer graphique de requêtes et sauvegarde exécutées dans un fichier sql.

A ce niveau Les offres de Pentaho Data Integration et Clover ETL sont moins satisfaisantes. Même s’ils permettent, toutefois, l'exécution des procédures stockées, la normalisation et la dénormalisation de tables. [Atol, 2007] [Axege, 2012]  Calcul et transformations TOS et PDI permettent de faire à peu près toutes les transformations envisageables dans le cadre d'un projet, grâce à de nombreux composants. En effet, en termes de fonctionnalités, les composants Talend sont plus que 250 en Java et Perl, alors que Pentaho comprend environ 180 composants. Clover ETL reste moins complet que ses derniers avec environ 57 composants. [Atol, 2007] [Axege, 2012]  Planification Talend dispose d’un Planificateur (scheduler) pour la planification des Jobs. Clover ETL dispose également d’un scheduler intégré, mais juste pour la version payante. En ce qui concerne Pentaho, il est nécessaire d’utiliser un scheduler externe. [Atol, 2007] [Axege, 2012]  Option d’administration Pentaho Data Integration offre d’avantage des services gratuits à ce niveau du fait qu'il a été développé pour exécuter des transformations sur un serveur distant.

31

Rapport PFE


Pour Talend Open Studio, il propose de nombreuses options d’administration dont, cependant, certaines sont payantes. Les options d’administration offertes par Clover ETL, quant à elles, sont toutes payantes. [Atol, 2007] [Axege, 2012]

Pour évaluer les trois outils étudiés, nous avons adopté un système de points sur une échelle de 5. Nous n’avons, toutefois, pas utilisé un système de points pondérés car nous considérons dans notre cas que tous les critères étudiés ont presque le même degré d’importance et d’impact sur le choix de l’outil à adopter. Nous récapitulons ci après dans un tableau le résultat de notre évaluation : TABLEAU 3.1 : ILLUSTRATION DU RESULTAT DE L’EVALUATION

Critère d’évaluation

Talend

Pentaho

Clover.ETL

Communauté documentation

5 5

5 5

3 4

Ergonomie

5

4

4

Accessibilité

5

5

0

Intégration dans une suite BI

5

4

0

Compatibilité

5

5

4

Lecture et écriture dans un SGBD

5

3

3

Calcul et transformations

5

4

3

Planification

5

0

0

Option d’administration

3

5

0

Total

53

44

25

En utilisant le diagramme de radar qui sert comme comparateur multidimensionnel, nous obtenons la représentation suivante :

Option… Planification

6 4 2

Document…

Talend Open Studio

Ergonomie

0 Calcul et…

Accessibilité

Lecture et…

Pentaho Data Integration Clover ETL

Intégration…

Compatibilté

Figure 3.1: Diagramme de radar pour la comparaison des trois ETLs 32

Rapport PFE


On lit sur chaque axe partant du centre, la valeur que prend chaque critère, nous remarquons clairement que Talend Open Studio est en avance par rapport à Pentaho Data Integration et Clover ETL suivant les différents axes. Par conséquent, nous optons pour l’outil Talend Open Studio qui donne des avantages supplémentaires bien utiles dans notre projet. 3.2 Outils Reporting : L’efficacité de certaines solutions open sources permettent réellement d’envisager leur utilisation au sein d'une structure professionnelle. Pour cela nous avons établi une étude comparative entre Business Object que notre client possède, et Pentaho Reporting suite qui se classe devant Jaspersoft et BIRT et les autres outils de reporting selon une étude établie par des experts (Pentaho (47%) des entreprises, devant Jaspersoft (28%), autres(25%) ). Avant de passer à la comparaison nous commençons par présenter chacun de ces outils. [Legran, 2010] 3.2.1

Présentation des outils Reporting :

 Pentaho Reporting suite : 

Présentation :

Pentaho est une plateforme complète d’informatique décisionnelle open source entièrement développée en Java et permettant le reporting simple et l'OLAP. Un autre aspect spécifique de la suite Pentaho, c’est d’être sponsorisée et d’appartenir à la à un organisme privé Pentaho Corporation. 

Modules :

Pentaho intègre ou supporte la plupart des composants décisionnels open sources existants à savoir : 

CUBE DESIGNER : permet la création des cubes afin d’être utilisés par la Suite Pentaho.



PENTAHO ANALYSIS : sert à l’analyse des cubes OLAP.



PENTAHO REPORT DESIGNER : pour la génération de rapports.



BI PENTAHO : la plateforme qui permet la publication des rapports et la réalisation des analyses OLAP sous formes de web services. [Loria, 2008]

33

Rapport PFE


 Business Object :  Présentation : Business Object est avant tout une société franco-américaine née en 1989 et a conçu un outil d'aide à la décision accessible à l'utilisateur final. Il permet l'interrogation, la présentation et l'analyse des données issues d'un système d'informations afin de prendre des décisions. 

Modules :

 DESIGNER : Permet de construire les Univers, les documenter et les mettre à la disposition des équipes utilisatrices. En effet, Un Univers est une représentation totale ou partielle de la base de données adaptée à un métier de l'entreprise ou à un domaine d'application particulier. Il regroupe un ensemble de mots du vocabulaire métier.  DESKTOP INTELLIGENCE : Permet de créer des rapports à partir des univers déjà conçus.  WEB INTELLIGENCE : Permet d’interroger, de mettre en forme et d’analyser les informations des rapports sur le Web.  SUPERVISOR : Gère les droits d'accès, définit les groupes et les utilisateurs, leur affecte des droits sur les différents modules et leur fonctionnalités, et sur les ressources de l’Univers.  OUTILS DE CONVERSION DE RAPPORT : Permet de convertir les rapports desktop intelligence au format web intelligence. [Loria, 2008] 3.2.2 Choix de l’outil Reporting : Après avoir présenté les deux logiciels proposés, nous passons à l’étude comparative qui va s’articuler autour de quatre axes que nous jugeons utile dans le choix de l’outil reporting à savoir : 

Installation



Documentation



IHM



Sécurité

o Installation : 

BusinessObject : l’installation se fait à travers un seul exécutable qui permet d’installer automatiquement la totalité des modules.



Pentaho Reporting suite : disponible sous nombreux formats, mais nécessite de rassembler les exécutables de chaque composant. [Loria, 2008] 34

Rapport PFE


o Documentation :  BusinessObject: plus de 1000 pages disponibles sur le site officiel du BO, permettant de faciliter la manipulation de cet outil en détaillant le fonctionnement à partir des exemples illustratifs.  Pentaho Reporting suite : malheureusement la documentation de qualité est un problème récurrent chez Pentaho pour la suite de reporting, ce qui complique la réussite à se servir des fonctionnalités qu’offrent les différents composants. [Loria, 2008] o IHM Nous analysons ce critère selon deux phases : la création des cubes qui consiste à élaborer les dimensions et les indicateurs, et la phase de présentation des rapports. 

Création des cubes :  BusinessObject : l’interface est agréable, l’utilisateur est guidé par des messages d’erreurs ou d’informations s’il manque des choses importantes, les icônes sont assez parlantes et offrant un nombre important d’options qui facilite la création des dimensions et des mesures en choisissant juste les données et les opérateurs. Les mesures ou les dimensions sont représentées sous forme de mots du vocabulaire professionnel en masquant leur correspondance SQL, on parle alors d’objets. En outre BO adopte aussi la notion de classe qui regroupe ses objets selon le thème (exemple : vente, achat…). Tous ces concepts s’affichent dans l’Univers.  Pentaho : l’interface de Pentaho propose un ensemble de fonctionnalités sous forme d’une ligne de boutants un peu rigides et non parlants et par conséquent la création des mesures et des dimensions nécessite un certain niveau d’innovation. [Loria, 2008]



Présentation des rapports :  BusinessObject : Business Object offre une couche sémantique qui permet de traduire les concepts techniques à un vocabulaire métier afin de permettre aux décideurs non informaticiens d’interroger eux- même de façon intuitive la base de données décisionnelle, ainsi il peut présenter les données restituées sous forme de tableaux, tableaux croisés, des graphes…etc.  Pentaho : la présentation des rapports passe nécessairement par un service informatique. En effet, Pentaho propose un assistant d’édition de rapport qui utilise les concepts technique et nécessite une bonne connaissance de la 35

Rapport PFE


structure de la base de données. En outre, Pentaho lui manque la représentation des rapports en tableaux croisés. [Loria, 2008] o Sécurité :  BusinessObject : L'Univers accède aux données d'un serveur via une connexion SGBDR déjà sécurisée. l'accès aux Univers est géré par le module « SUPERVISOR ». De même, l'accès à certains objets peut être interdit par ce dernier selon leur niveau de confidentialité.  Pentaho : comporte également une plate-forme d'administration (Pentaho Administration Console) qui permet la gestion des droits d'accès, la planification d'évènements, la gestion centralisée des sources de données. Mais cette plateforme reste basique et c’est la version commerciale qui complète les fonctionnalités d’administration et de personnalisation des actions. [Loria, 2008] Pour évaluer ces critères nous suivons le même barème utilisé dans la partie ETL. Nous résumons le résultat dans la figure suivante : outils Business Object Pentaho

Installation 5 3

Documentation

IHM 5 2

Sécurité 5 1

5 3

Installation 5 4 3 2 1 Sécurité

Documentation

0

Business Object Pentaho

IHM

1: Figure 3.2: Diagramme Radar et le tableau d’évaluation des outils de reporting

D’après ce diagramme de radar, Business Object est en avance avec un grand écart. Nous estimons alors qu'il est plus efficace à utiliser que Pentaho, notamment grâce à l'exploration de l’univers qui offre plusieurs fonctionnalités utiles dans l’élaboration des

36

Rapport PFE


rapports décisionnels. De plus, l'investissement consenti par le client ATAC dans l’obtention de sa licence soutient fortement notre choix.

Conclusion : Ce chapitre nous a permis de choisir parmi les outils proposés ceux qui sont les plus adaptés aux besoins de notre travail. En effet, nous avons opté pour l’ETL Talend Open Studio pour le chargement des tables de notre base de données décisionnelle et Business Object pour la représentation des données restituées. Nous mettons en lumière différentes phases de la réalisation de notre projet

37

les

dans le chapitre suivant.

Rapport PFE

Chapitre 4 : Réalisation

Chapitre 4

38

Rapport PFE


Apres avoir conçu le modèle de données du datamart et fait le choix des outils à utiliser, nous présentons dans ce présent chapitre la réalisation du projet en deux grandes parties : alimentation du datamart et création de l’univers et reporting. 4.1 Alimentation du Datamart Cette partie est considérée comme étant la phase la plus délicate. Elle contient trois étapes : l’extraction, la transformation et le chargement des données (voir annexe E). Cette phase intermédiaire dans le projet s’avère importante et demande beaucoup de réflexion et de précision car les données chargées doivent évidemment être complètes et exactes. Nous commençons tout d’abord par donner un aperçu sur les composants de l’outil utilisé, ensuite nous expliquons les détails d’alimentation du datamart. 4.1.1 Composants Talend utilisés : D’après l’étude comparative établie dans le chapitre précédent notre choix a porté sur l’outil Talend que nous avons jugé convenable pour la réalisation de cette phase. Nous présentons ainsi un ensemble de ses composants qui nous ont servi à créer et alimenter nos tables destinataires. TABLEAU 4.1 COMPOSANTS DE TALEND UTILISES

tOracleOutput

permet de lire et extraire les tables à partir de notre base de données source

tOracleOutput

Sert à alimenter des tables de faits et de dimensions nouvellement créées en insérant les données provenant des différentes sources. c’est le composant le plus utilisé dans notre projet, il permet d’effectuer plusieurs opérations à savoir les jointures, le filtrage, les transformations des flux, gère les sorties multiples…

tMap

tFilterRow

ce composant permet de filtrer l’enregistrement selon les conditions souhaitées sur les colonnes.

tFilterColomuns

comme son nom l’indique, il sert à filtrer et choisir des colonnes d’une table source et même a mapper les colonnes sources aux colonnes cibles.

tUniquRow

Ce composant sert à fusionner les entrées dans la même sortie et à supprimer les doublons du flux d’entrée avant de procéder au chargement Ce composant reçoit un flux et l’agrège selon une ou plusieurs colonnes.

tAggregateRow

tReplicate

Il sert à dupliquer un flux de données autant de fois que nécessaire.

39

Rapport PFE


Après avoir présenté les composants utilisés dans cette phase, nous passons aux détails du chargement des tables de notre magasin de données. Pour réaliser cette partie nous avons donné la priorité aux tables de dimensions afin d’assurer les contraintes d’intégrité dans les tables de faits qui contiennent les clés primaires des tables de dimensions. Cette démarche a été suivie pour chaque itération de notre projet. Nous présentons donc en premier lieu le chargement de chaque table de dimensions puis nous détaillerons le traitement appliqué dans l’alimentation d’une des trois tables de fait. 4.1.2 Alimentation des tables de dimensions : Au cours du processus itératif adopté dans notre travail, nous étions amenés à alimenter cinq tables de dimension à savoir : la structure marchandise, le réseau commercial, le temps, le type des démarques et le type des ruptures. Ces deux dernière dimensions sont spécifiques aux itérations démarque et rupture respectivement. Le chargement de ces

tables passe

impérativement par l’exécution des jobs. En effet, un job est un traitement qui permet d’extraire les données et d’y effectuer les transformations nécessaires pour

les stocker

finalement dans les tables destinataires.  Dimension structure marchandise : Cette phase consiste à alimenter la table de dimension structure marchandise qui contient plusieurs niveaux d’hiérarchie comme nous l’avons montré dans la figure 2.2, et par conséquent plusieurs champs à sélectionner et plusieurs jointures à effectuer. Pour ce faire, nous nous sommes basées sur cinq tables sources comme c’est illustré dans la figure 4.1 :

Type et Marque

Différencie les magasins des entrepôts

Jointure

Article RacineSegment-Famille…Secteur

Les unités de vente Libellés

Figure 4.1:Chargement de la dimension Structure Marchandise

40

Rapport PFE


La table « MG_STRUCTURE_MARCHANDISE » contient les identifiants de chaque élément de la structure (article, segment, famille…). Sa petite granularité est « la racine de l’article » à titre d’exemple « Coca Cola ». Par contre la table « ARTUV » permet de récupérer les différentes unités de vente que peut avoir une racine d’un article, pour notre exemple nous aurons (Coca 1/2L, Coca 1L, Coca 2L) comme unités de vente. La table « STRUCTOBJ » contient à son tour les libellés de chaque objet (unité de vente, racine de l’article, segment, famille…), et finalement la table « ATRAC » qui spécifie le type et la marque de chaque article. Le composant tMap_3 fait alors les jointures nécessaires entre ces tables et renvoie le résultat à la table cible « Structure_marchandise ».  Dimension structure organisation De même que pour la dimension marchandise, le chargement de la dimension organisation Consiste à réliser une jointure entre quatres sources : « MG_STRUCTURE_ORGANISATION » qui renvoie les differents identifiants du réseau

commercial (magasin, réseau, région), et trois autres sources qui nous renseignent sur les libellés correspondants à ces codes. La figure 4.2 indique le rôle du composant tMap qui fait le filtrage et la jointure entre les tables .

Jointure avec tMap

Figure 4.2 : Chargement de la table Structure Organisation

 Dimension temps : Suivant le cycle de vie de notre projet, cette table a été alimentée en 3 phases : La première pour stocker les dates liées à la vente, la deuxième phase intègre les dates des démarques, et la dernière rajoute les dates propres aux ruptures. 41

Rapport PFE


Après l’accomplissement des trois itérations nous avons élaboré un seul job décrit dans la figure 4.3, et qui permet d’extraire, de transformer et de récupérer en une seule exécution les dates provenant des trois sources. Source des données de Vente et Démarque

Fusion des dates Filtrage du champ Date

Source des données de rupture

Extraction du mois, jour..

Figure 4.3:Chargement de la table Dimension Temps

Nous avons établi à travers ce job deux jointures à la fois : une entre la table « STOMVT » qui enregistre tous les mouvements des sorties du stock et la table « SIDGENE » qui nous renseigne sur les magasins du compte ATAC, et ceci pour se focaliser sur les ventes et les démarques juste dans les magasins. Une autre entre « ARTRUPT » et « SITDGENE » pour le même but mais concernant les ruptures cette fois ci. Le flux provenant de « SITDGENE » a été dupliqué grâce au composant tReplicat. Ensuite, après avoir filtré les mouvements et converti les champs qui nécessitent ce traitement, nous avons fusionné les différents champs de date avec le composant tUnit pour leur appliquer des procédures de transformation visant à séparer les jours, mois, libellé mois et année et à rajouter même le trimestre comme illustre la figure 4.4 suivante :

42

Rapport PFE


Procédure de transformation

Figure 4.4: Transformation de la date

 Dimension type Démarque et type Rupture : Cette phase consiste à alimenter la table type démarque qui permettra de préciser s’il s’agit d’une

perte produite par une casse, une transformation au niveau de l’article…, ou plutôt un don offert aux associations.

Figure 4.5: Chargement de la dimension type démarque

Comme le montre le job de la figure 4.5, il s’agit de filtrer les enregistrements correspondants aux démarques à partir de la table « STOMVT » et de les joindre

avec la table

de

paramétrage « TRA_PARPOSTES » qui contient la signification des codes restitués afin d’attribuer à chaque identifiant son libellé correspondant. Pour alimenter la table type rupture, nous avons suivi les mêmes démarches mais en se basant cette fois ci sur les données de la table « ARTRUPT » au lieu de « STOMVT». 43

Rapport PFE


4.1.3 Alimentation des tables de faits : Nous étions amenés dans notre projet à alimenter trois tables de fait à savoir : les ventes, les démarques et les ruptures. Nous présentons dans ce qui suit l’alimentation détaillée de la table Vente. Le traitement des autres tables est explicité dans l’annexe A.  Fait Vente : Pour alimenter la table de fait vente nous avons conçu le job illustré dans la figure 4.6 qui est en mesure de calculer les indicateurs suivants : 

La quantité vendue.



Le chiffre d’affaires(CA).



La marge ou la rentabilité.

Pour ce faire, nous avons effectué les traitements suivants explicités dans la figure 4.6 : 

Jointure entre la table qui enregistrent les mouvements de vente (STOMVT) et celle qui renseigne sur les magasins (SITDGENE).



Filtrage des mouvements propres aux ventes.



Conversions des champs de quantité, prix... pour pouvoir leur appliquer des calculs grâce au composant tConvertType.



Calcul de l’indicateur du chiffre d’affaires et de la valeur totale du prix de revient avec le composant tMap_8 et en utilisant les relations suivantes : Chiffre d’affaires = Quantité vendue *prix hors taxe *(1+TVA). Prix de revient = prix de revient unitaire * quantité.



Calcul du chiffre d’affaires, la quantité vendue et du prix de revient pour la plus petite granularité du groupe qui constitue la clé primaire de la table Vente à savoir : le magasin (STMSITE), l’article (STMCINL) et la date du mouvement(STMDMVT). Ce calcul est fait grâce au composant tAggregatRow illustré dans la figure 4.7.



Calcul de la marge via le tMap_2 avec la relation : Marge = chiffre d’affaires – prix de revient. Ce dernier composant identifie aussi la clé de la nouvelle table et envoie les données à la base cible.

44

Rapport PFE


Filtrage des champs nécessaires au calcul des indicateurs de vente

Calcul des indicateurs

Figure 4.6: Chargement de la table de fait Vente

Axes d’analyse

Mesures Figure 4.7:Traitement effectué pat le composant tAggregateRow

4.1.4 Paramétrage de la fréquence de la mise à jour du datamart : Les données d’un datamart doivent être constamment mises à jour. Pour ce faire, nous avons paramétré les actions du rafraichissement que proposent Talend selon notre besoin (voir l’annexe B). En outre, une fois qu’un flux d’extraction-transformation-chargement est défini, il est possible de le déclencher de manière ponctuelle ou périodique. Ceci grâce à un outil de planification de tâches. La figure 4.8 illustre ce planificateur des jobs.

Figure 4.8: Planification des jobs 45

Rapport PFE


Cet ordonnanceur permet d’exécuter les jobs du chargement des tables de fait quotidiennement ainsi que la table de dimension Temps, puisque les magasins effectuent d’une façon permanente leurs transactions de vente. Par contre les autres jobs relatifs aux autres dimensions (structure marchandise, structure organisation, type démarque…) se lancent d’une façon hebdomadaire vu qu’ils évoluent lentement dans le temps. 4.1.5 Analyse du temps de chargement Le temps de chargement ne varie pas beaucoup entre les différentes procédures (jobs) puisque nous utilisons le même type de source à savoir la base de données du client ATAC. Par contre, ce temps peut varier d’une table à une autre et entre l’extraction de la source et le chargement dans la base cible. Ce temps change aussi en fonction du traitement effectué, s’il s’agit d’une jointure simple, d’une transformation ou d’un calcul à faire. Ainsi nous remarquons à travers la figure 4.9 que le temps de l’extraction des données depuis la base source est estimé entre 30 et 40 lignes par secondes, alors que le temps du chargement dans la base de destination peut aller jusqu'à 2100 lignes par secondes. Le calcul se fait aussi rapidement dans Talend dans l’ordre de 2000 lignes par secondes.

Figure 4.9: Temps de chargement de la table de fait Démarque

La table la plus volumineuse de la base est la table « STOMVT » qui contient plus de 5 millions de lignes et qui englobe les différents mouvements des ventes et des démarques. Cependant, la mise à jour du datamart sera quotidienne pour les tables de fait, donc la moyenne des transactions de ventes par exemple qui peuvent être enregistrées chaque jour est de l’ordre de 30.000 lignes. Le chargement de ces lignes se fera approximativement en 10 minutes.

46

Rapport PFE


Après avoir construit et alimenté notre magasin de données, nous passons maintenant à son exploitation dans le processus reporting qui constitue la fin logique de chaque projet BI. Pour ce faire, nous avons utilisé l'outil Business Object présenté dans le troisième chapitre pour mettre tout d’abord à la disposition des décideurs une présentation métier organisée des données, et générer ensuite des rapports et des statistiques qui seront utiles pour le compte ATAC dans sa prise de décision 4.2 Création de l’univers et reporting Nous présentons dans la première partie les étapes suivies dans la création de l’univers puis nous donnons les états réalisés dans la partie reporting. 4.2.1 Création de l’univers Comme nous l’avons présenté dans le chapitre de l’étude comparative des outils, Business Objects dispose d’un module Designer qui permet la création des Univers. En effet, l’univers est une représentation métier des données techniques issues du datamart, Il offre à son utilisateur la possibilité d’interroger la base, d’analyser et d’élaborer des rapports avec son vocabulaire quotidien et sans avoir l'obligation de comprendre le langage SQL, ou la structure complexe de la base de données. (Voir l’annexe C) Dans notre cas, nous avons crée l’univers ATAC à partir des trois tables de fait : vente, démarque et rupture avec les différentes dimensions d’analyses. Pour ce faire nous avons suivi les étapes suivantes :  Création et paramétrage de la connexion au datamart.  Insertion des tables depuis le datamart.  Traitement des ambiguïtés. En effet, l’utilisation multiple d’une table dans l’univers peut causer une certaine ambigüité. Tel est le cas des tables de dimension qui sont partagées entre les trois tables de fait. Pour remédier à ce problème, ils existent plusieurs solutions parmi lesquelles la création des alias c'est-à-dire des noms logiques que nous affectons à des tables tel que la table structure_marchandise2, Temps2, et structure_organisation2 illustrées dans la figure 4.10 dans le cas ou ces tables s’utilisent différemment pour plusieurs fois. Apres avoir crée la connexion, inséré les tables et résolu le problème des ambiguïtés nous sommes passé à la structuration de l’univers sous forme de classes et d’objet.

47

Rapport PFE




Création des objets : l’objet est un élément constitutif de l’univers qui sera directement manipulé par l’utilisateur, vu que c’est une information composés de données de la base mais définie avec le vocabulaire métier. Il y a trois types d’objets :  Dimension

: comme son nom l’indique, elle représente une donnée

qualitative d’un axe d’analyse sur laquelle nous allons effecteur un calcul (ex : magasin, région, réseau...) 

Indicateur

: ce sont les indicateurs unitaires que nous avons calculé

dans la phase de l’alimentation du datamart, mais sur lesquels nous avons appliqué des opérations de comptage ou de moyenne selon les besoins de l’analyse. (ex : nombre d’article en rupture, chiffre d’affaires …).  Objet information

: c’est un objet qui présente généralement un

complément d’information sur une dimension déjà définie (ex. : libellé d’un rayon…) 

Création des classes : une classe est un regroupement thématique des objets. Dans notre cas, et comme c’est indiqué dans la figure 4.10, nous avons crée trois classes : une pour les ventes, une autre pour les ruptures de stock et une troisième pour les démarque. Dans chaque classe, nous avons mis deux sous-classe : une pour les dimensions et une autre propre aux indicateurs afin d’offrir à l’utilisateur une interface bien structurée.

48

Rapport PFE


Figure 4.10: L’Univers ATAC

4.2.2

Analyse et reporting

Avant de passer à la phase de reporting, nous présentons d’abord l’analyse multidimensionnelle qui permet justement d’analyser les indicateurs calculés en fonction des différentes dimensions. 4.2.2.1 Analyses multidimensionnelles Une fois l’univers ATAC est crée, Business Object offre une interface conviviale appelée Desktop Intelligence. C’est une interface dédiée à l’utilisateur final pour lui faciliter l’utilisation des différentes fonctionnalités de l’univers. Grâce à cette interface intuitive, l’utilisateur peut alors effectuer ses analyses et ses rapports de façon autonome sans avoir aucune connaissance technique. En effet, il n’a qu’à glisser les indicateurs et les dimensions nécessaires à son analyse dans l’onglet « objet du résultat » comme c’est illustré dans la figure 4.11 et à préciser ensuite les restrictions et les conditions qu’il souhaite poser dans l’onglet « condition ». Les requêtes SQL correspondantes sont générées automatiquement par le système.

49

Rapport PFE


Figure 4.11: Interface Desktop Intelligence

La figure 4.11 montre l’exemple d’une requête générée automatiquement pour visualiser la quantité des démarques dans les différents magasins de la région « Damien Rancheard » en fonction des types de démarque en 2011. L’utilisateur peut aussi réaliser ses rapports et ses statistiques suivant les différents niveaux. En effet, comme le montre la figure 4.12, il peut naviguer facilement dans la hiérarchie des dimensions lors de son analyse.

Figure 4.12: Navigation dans la hiérarchie

La figure 4.12 montre que nous pouvons détailler le pourcentage du chiffre d’affaires d’un réseau par exemple, juste en cliquant sur ce dernier pour expliciter les pourcentages de ses différentes régions, de même nous pouvons cliquer sur une région pour obtenir le pourcentage du chiffre d’affaires des magasins qui y appartiennent. Cette possibilité de navigation entre les 50

Rapport PFE


niveaux hiérarchiques facilite la visualisation des détails et aide l’utilisateur à aller plus loin dans son analyse. 4.2.2.2 Reporting Le reporting présente le fruit de tout projet décisionnel. Il permet d’étudier, de visualiser et d’exploiter les données de l’entreprise dans l’objectif de les bien manager pour en faire un réel support d’aide à la décision. (Voir l’annexe E) Dans notre cas et afin de répondre aux besoins décisionnels du client ATAC, nous avons établi un certain nombre d’états (Annexe D) sous forme de tableaux croisés ou des graphiques paramétrables comme l’histogramme, les camemberts, les courbes, diagrammes en aires etc. Nous résumons dans le tableau suivant les états réalisés au profit du compte ATAC : Tableau 4.2 : Etats Réalisés au profit du compte ATAC

Etats réalisés Pourcentage du chiffre d’affaires des magasins dans le réseau Sud Evolution du chiffre d’affaires par jour et par rayon au mois de Janvier 2011 Quantité des démarques dans chaque secteur en fonction des types de démarque Nombre d’articles en rupture en fonction du motif Taux de démarques des sous rayons des magasins dans le dernier trimestre de l’année 2011.

Valeur des démarques des régions par type de démarque Rentabilité de chaque réseau. Durée moyenne de rupture comparée entre quatre régions Chiffre d’affaires des dix premiers magasins Evolution de la quantité vendue dans les réseaux par mois et par famille de produit. Pourcentage des dons aux associations dans les régions du réseau Est. Nombre d’articles en rupture dans le magasin VIRTY par famille de produits. Evolution du nombre d’article en rupture depuis l’année 2010 Durée moyenne de rupture des sous familles en fonction des causes de rupture

Nous présentons ainsi quelques exemples de ces états. La figure 4.13 présente un exemple d’état sous forme de diagramme de camemberts qui fournit le pourcentage du chiffre d’affaires réalisé dans chaque magasin du réseau Sud. Ceci donnera aux décideurs une vue

51

Rapport PFE


globale sur leurs sites les plus rentable comme Duplex Paris XV et les aidera à améliorer le rendement des magasins de faible rentabilité comme le magasin Golbey.

pourcentage du chiffre d’affaires des magasins dans le réseau Sud

Figure 4.13: Rapport du pourcentage du chiffre d’affaires des magasins dans le réseau Sud

Pour suivre l’évolution de ce chiffre d’affaires dans une période donnée, nous avons proposé l’état illustré dans la figure 4.14 qui présente cette évolution au mois de Janvier dans les rayons les plus importants des supermarchés du groupe Auchan.

Figure 4.14: Evolution du chiffre d’affaires dans le temps 52

Rapport PFE


Concernant les démarques, le tableau de la figure 4.15 indique leur quantité dans les quatre secteurs de produits en fonction des types de démarques dans l’année 2011.

Figure 4.15 Quantité de démarques dans chaque secteur en fonction des types de démarque

Pour mieux visualiser ces résultats, nous avons accompagné ce tableau avec le diagramme illustré dans la figure 4.16. On constate que les articles périmés et cassés présentent la plus grande quantité de perte.

Figure 4.16: Diagramme des quantités des démarques

Pour les ruptures de stock, la figure 4.17 présente le nombre des articles en rupture dans les différentes régions du réseau Franchise en fonction des causes de ces ruptures. Cet état donne une vision détaillée sur les régions ou se produisent plus de ruptures afin d’inciter les décideurs à prendre les mesures nécessaires pour les éviter ou au moins les diminuer.

53

Rapport PFE


2: Figure 4.17 : Nombre d’article en rupture

La dernière figure 4.18 illustre la valeur des démarques y compris les dons aux associations par rapport au chiffre d’affaires réalisé en 2011. Cette valeur est représentée par l’indicateur taux de démarque que nous avons calculé dans les différents sous- rayons des magasins du compte ATAC.

Figure 4.18: Taux de démarque en 2011

54

Rapport PFE


Conclusion : Ce chapitre a décri

la réalisation de notre système décisionnel. En effet, nous avons

commencé tout d’abord par l’alimentation de notre datamart via l’outil Talend. Ensuite, nous avons crée l’univers ATAC sur lequel s’est effectuée l’analyse multidimensionnelle des indicateurs stratégiques recueillis avec l’outil Business Object, pour finir par la génération des tableaux et des rapports de synthèses exploitables par les preneurs de décision.

55

Conclusion Notre projet de fin d’étude a été pour nous non seulement une étape à franchir pour achever notre parcours académique, mais aussi une grande opportunité de prendre part à un projet réel qui s’inscrit dans le cadre de l’informatique décisionnelle. Cette dernière a pour objectif d’offrir un meilleur usage du flot de données afin d’aider les managers à la prise de décision. Nous rappelons que notre stage qui s’est déroulé au sein de HP CDG consistait à mettre en place un système décisionnel qui facilite l’élaboration des rapports décisionnels au profit du compte ATAC. Ce système a permis alors de gagner en termes de temps, d’ergonomie et d’autonomie grâce au datamart mis en place et à l’univers crée sous Business Object. En effet, le processus reporting dispose désormais d’un entrepôt ciblé, structuré et propre à son traitement. Il est donc devenu indépendant et séparé des traitements quotidiens. L’édition des rapports qui prenait toute une journée auparavant est devenue instantanée en quelque clic seulement. L’affichage du résultat se fait actuellement en glissant juste les indicateurs et les dimensions qui sont représentées par des boutons et peut prendre plusieurs formes, tableau croisé, graphique à barres, à secteurs, à nuages de points…etc. Ainsi un manager qui a peu de connaissances en informatique peut créer un ensemble d’états de reporting selon ses besoins et les visualiser en choisissant le graphe le plus significatif et le plus parlant. Ce stage a également été une occasion pour nous de découvrir le dynamisme et l’enthousiasme qui marquent l’équipe ATAC au sein de HP CDG. Le travail avec cette équipe nous a permis de concrétiser nos connaissances techniques et théoriques ainsi que d’acquérir d’autres propres au monde professionnel. Les difficultés majeures rencontrées durant ce projet résident essentiellement dans la nouveauté des technologies à savoir Talend et Business Object qui nous étaient complètement inconnus au départ. De plus, le travail et la collaboration dans une grande équipe telle que l’équipe ATAC a nécessité de développer plus notre esprit d’équipe afin d’aboutir à nos objectifs ciblés. Comme perspective à ce projet, nous proposons aussi de mettre en place deux autres datamarts. Un pour la gestion des commandes des magasins, et un autre pour le traitement du flux de stock dans les entrepôts. En effet, la série ATAC comprend les magasins ou les surfaces de vente et les entrepôts qui représentent leurs fournisseurs logistiques. L’ensemble de ces datamarts va

mettre en lumière l’activité commerciale de l’intégralité de la série ATAC. 56

Bibliographie et Webographie [CDG, 2009]

: http://www.cdg.ma/index.php?option=com_content&task=view&id=34&Itemid= 249

Site officiel de la caisse de dépôt et de gestion. [Wiki, 2011]

:

http://fr.wikipedia.org/wiki/HP-CDG_IT_services_Maroc

Informations sur le groupe HP CDG. [HPCDG,2012]: Documentation offerte par la société HP CDG. [Aldata, 2012]:

http://www.aldata.com/fr/produits/aldata-gold

Site officiel d’Altdata éditeur de l’ERP GOLD.

[Mapp, 2012] :

http://www.mappingsuite.com/fr/produits/composition-impression-archivagediffusion-pilotage-0032.html.

Site officiel de la suite logicielle Mapping. [Hugues, 2002]: http://users.polytech.unice.fr/~hugues/GL/chapitre2.pdf Description du cycle de vie Prototypage.

[Dw, 2006]

:

http://www.dwfacile.com/Portail_md.htm

Les notions clés de la modélisation multidimensionnelle. [Atol, 2007]

: http://www.atolcd.com/fileadmin/Publications/Atol_CD_Livre_Blanc_ETL_Open_ Source.pdf

Les ETL Open source.

[Axege ,2012] : http://www.axege.com/Evaluation-de-deux-ETL-Clover-ETL-vs-Talend-OpenStudio.html

ETL Clover et Talend Open Studio.

[Legran, 2010] :

http://www.legrandbi.com/2010/01/beyenetwork-third-nature-etude-bipentaho/ 57

Etude Comparative entre les outils de Reporting Open source. [Loria, 2008]

:

http://www.loria.fr/~peguiron/miage/Projet_Bibliographique.pdf

Les outils de Reporting Open source. [Com, 2012]

:

http://www.commentcamarche.net/contents/entreprise/datawarehousedatamart.php3

Les notions sur datawarehouse et datamart

.

58

ANNEXES

Annexe A : Alimentation des tables de fait Démarque et rupture

1. Alimentation de la table de fait Démarque

Figure A1: alimentation de la table de fait Démarque

L’alimentation de la table de fait démarque s’effectue de la même façon à peu près que celle des ventes vue qu’elles sont toutes les deux extraites de la même source, la différence apparait plutôt dans le filtrage et la partie des calculs. En effet, on filtre les champs « STMMOTF » entre 10 et 19 et « STMTMVT » entre 100 et 124 pour avoir les mouvements des démarques et des dons aux associations, puis on calcule les indicateurs recueillis dans cette partie en prenant la valeur absolue des données car elles sont enregistrées négatives dans la base source pour indiquer qu’elles présentent des pertes .

2. Alimentation de la table de fait Rupture: Cette partie se base principalement sur la table « ARTRUP » qui englobe toutes les données concernant les ruptures du stock au sein des magasins ATAC: Afin d’alimenter la table de fait Rupture nous avons établi le job suivant : 59

Figure A2: Chargement de la table de fait Rupture4

Nous avons effectué la jointure entre « ARTRUP » et « Mg_Structure_Marchandise » pour regrouper toutes les données nécessaires à l’identification d’un article en rupture, Ensuite, La partie calcul a consisté à calculer le nombre d’article en rupture ainsi que la durée moyenne que peut prendre ces

articles avant de redevenir disponibles dans la liste des produits

proposés à la vente.

60

Annexe B : Paramétrage du rafraichissement du datamart selon Le besoin

Les données d’un Datamart doivent être constamment mises à jour. Pour ce faire, l’outil Talend permet de choisir la politique de rafraichissement propice à chaque table. En effet , il est possible de choisir comme action sur les données « update or insert » comme le montre la figure A3 si l’on prévoit un nombre de lignes à mettre à jour supérieur à celui des lignes à insérer ou bien «insert or update » dans la situation inverse.

Figure B1: Rafraichissement des tables destinataires

Dans notre cas, nous avons choisi l’action «insert or update » pour toutes les tables de fait ainsi que la dimension temps puisque le nombre d’insertions des mouvements de vente, démarque et rupture sera surement supérieur aux nombres de rafraichissement et c’est pareil pour les dates. Concernant les autres dimensions qui nécessitent plus de mises à jour que d’insertions

nous

avons

opté

pour

61

l’action

«

update

or

insert ».

Annexe C : Univers de Business Object

1. Rôle de l’univers L’univers a comme rôle de fournir une interface simple à utiliser et compréhensible permettant à des exploiteurs de BUSINESS OBJECTS d'exécuter des requêtes dans une base de données afin de créer des rapports et d'effectuer des analyses de données. On utilise DESIGNER pour créer des objets qui représentent les structures de la base de données, par exemple les colonnes et les fonctions de base de données, dont les utilisateurs ont besoin pour accéder et interroger la base, afin d'obtenir les informations nécessaires à leur activité professionnelle. [Loria, 2008]

2. Designer pour créer des univers : DESIGNER offre une interface graphique qui permet de sélectionner et d'afficher des tables dans une base de données. Les tables de bases de données sont représentées par des symboles de tables dans un diagramme de schéma. A partir de cette interface, on peut manipuler des tables, créer des jointures qui lient les tables, créer des tables d'alias et des contextes, et résoudre des boucles dans le schéma. Les utilisateurs BUSINESS OBJECTS ne voient pas ce schéma. [Loria, 2008]

62

Annexe D : Exemple d’états élaborés

Figure D1 : valeur des démarques des régions par type de démarque

63

Figure D2 : Rentabilité des réseaux

Figure D3 : Nombre d’articles en rupture dans le magasin VIRTY par famille de produits

64

Figure D4 : Durée moyenne de rupture comparée entre quatre région

65

Annexe E : Termes usuels du décisionnel : 

Datawarehouse :

Le lieu de stockage intermédiaire des différentes données en vue de la constitution du système d'information décisionnel est appelé entrepôt de données (en anglais datawarehouse). Le datawarehouse est ainsi le lieu unique de consolidation de l'ensemble des données de l'entreprises. Le créateur du concept de DataWareHouse, Bill Inmon, le définit comme suit : « Un datawarehouse est une collection de données thématiques, intégrées, non volatiles et historisées pour la prise de décisions. »

Ses principales caractéristiques sont donc les suivantes :  Orientation sujet du data warehouse : Le DW est organisé autour des sujets majeurs de l’entreprise, contrairement aux données des systèmes de production généralement organisées par processus fonctionnel. L’intérêt de cette organisation est de disposer de l’ensemble des informations utiles sur un sujet, le plus souvent transversal aux structures fonctionnelles et organisationnelles de l’entreprise.  Les données sont intégrées : Les données alimentant le DW proviennent de multiples applications sources hétérogènes. Les données des systèmes de production doivent être converties, reformatées et nettoyées, de façon à être intégrées dans le data warehouse.  Les données sont non-volatiles et historisées : Les données des systèmes opérationnels sont constamment manipulées, modifiées ; elles sont mises à jour à chaque nouvelle transaction. Ainsi, une même requête demandée à quelques semaines d’intervalle pourra fournir des résultats différents. Par opposition, les données du data warehouse sont le reflet d’une photo instantanée des données du système opérationnel. Lorsque intervient un changement important dans les données, une nouvelle photo est prise de façon à ce que le DW garde une trace de l’historique des données. Ainsi, Le DW est arrivé comme une reconnaissance de la valeur et du rôle de l’information, à savoir son utilisation à des fins stratégiques. C’est une plate-forme avec des données de très bonne qualité qui supportent des applications de type informationnel, comme les applications d’aide à la décision, ainsi que les processus dans l’entreprise. Il augmente la productivité des décideurs d’entreprise en consolidant, convertissant, transformant et intégrant les données de 66

différents systèmes opérationnels et en leur fournissant une vue consistante, globale et unifiée de leur entreprise. [Com, 2012] 

Datamart :

Le terme Datamart (littéralement magasin de données) désigne un sous-ensemble du datawarehouse contenant les données du datawarehouse pour un secteur particulier de l'entreprise (département, direction, service, gamme de produit, etc.) en vue de restreindre les données au périmètre métier d’un groupe d’utilisateurs. [Com, 2012] 

ETL :

un outil ETL (Extraction / Transformation / Loading) permet à partir de diverses sources de données, d'extraire de l'information, de faire des transformations afin de nettoyer les données et de charger des données utiles dans le datawarehouse ou le datamart . Les sources de données peuvent être diverses (HTML, XML, base de données, fichiers texte, tableurs, ERP etc.) comùe illustre la figure E1. [Atol, 2007]

Figure E1 : Processus ETL L’acronyme ETL signifie Extract :Extraire Accéder à la majorité des systèmes de stockage de données (SGBD, ERP, fichiers à plat...) afin de récupérer les données identifiées et sélectionnées. Prendre en compte les questions de synchronisation et de périodicité des rafraichissements.

67

Transform :Transformer : Toutes les données ne sont pas utilisables telles quelles. Elles méritent d'être vérifiées, reformatées, nettoyées afin d'éliminer les valeurs aberrantes et les doublons et consolidées. Load :Charger : Insérer les données dans le Datawarehouse ou le Datamart. Elles sont ensuite disponibles pour les différents outils d'analyse et de présentation que sont le Datamining, l'analyse multidimenensionnelle OLAP, les analyses géographiques, les requêteurs et autres reportings et bien sûr les tableaux de bord . 

Reporting :

Les outils de création de rapport (reporting tools) extraient les données et proposent une mise en forme destinée à la diffusion : par impression ou par des services Internet ou Intranet. Ils sont très utilisés pour générer des tableaux de bord conventionnels, qui sont souvent composés et diffusés automatiquement et périodiquement sans demande spécifique des utilisateurs. Ces tableaux de bord peuvent être transformés en graphes pour donner une représentation intelligente des informations afin de faciliter aux décideurs l’analyse et l’interprétation des états. [Loria, 2008]

68

69

pfeasmaaelouraoui

Recommend Documents