HAL Id: dumas-01834875
https://dumas.ccsd.cnrs.fr/dumas-01834875
Submitted on 11 Jul 2018
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.
To cite this version:
Éric Zins. Ventes prévisionnelles et propositions de commandes. Ingénierie, finance et science [cs.CE]. 2017. �dumas-01834875�
Conservatoire national des arts et métiers
Centre régional de Lorraine
Mémoire en informatique
Option Systèmes d’information (ISI)
Ventes prévisionnelles et propositions
de commandes
Présenté par
Eric ZINS
Soutenu le 9 février 2017
JURY
Président du Jury :M. Jean-Pierre ARNAUD CNAM - Professeur Titulaire de la chaire de Réseaux
Membres du Jury :
M. Christian DUCLOU Université de Lorraine / Direction du Numérique M. Rachid BEDRI Université de Lorraine / Direction du Numérique M. Michel IANOTTO CentraleSupélec, tuteur du mémoire
M. Pierre MAFFEIS Université de Lorraine / Direction du Numérique M. Benoît MARCHAL Université de Lorraine / Direction du Numérique
Mémoire d’ingénieur Page 1 sur 103 2016/2017
Remerciements
Je tiens avant tout à remercier mon entreprise EURODATA et son directeur général M. Dominique CHOLLOT de m’avoir accordé la réalisation de ce projet.
Je continue par remercier mes collaborateurs du service développement pour l’aide apportée durant la phase de réalisation.
Je remercie également l’ensemble des intervenants du CNAM et surtout M. Michel IANOTTO et M. Christian DUCLOU pour leurs conseils et le suivi de mon mémoire.
Mémoire d’ingénieur Page 2 sur 103 2016/2017
Sommaire
1. INTRODUCTION ... 4
2. PRESENTATION DE L’ENTREPRISE ... 6
2.1. Présentation générale ... 6
2.2. Organigramme du groupe EURODATA ... 7
2.3. Organigramme EURODATA France... 8
2.4. Clients et implantation géographique ... 9
2.4.1. Clients ... 9
2.4.2. Implantation géographique ... 9
2.5. La suite logicielle Edrms ... 11
2.5.1. Présentation générale ... 11
2.5.2. Progiciels stations-service – Partie POS ... 12
2.5.3. Progiciels stations-service – Partie BOS ... 12
2.5.4. Progiciels siège ... 13
2.5.5. Interfaces avec des systèmes tiers ... 13
3. CAHIER DES CHARGES ... 14
3.1. Entrepôt de données ... 14
3.1.1. Présentation de la solution existante ... 14
3.1.2. Etude de la nouvelle solution ... 23
3.2. Propositions de commandes ... 26
3.2.1. Présentation de la solution existante ... 26
3.2.2. Etude de la nouvelle solution : ventes prévisionnelles ... 29
3.2.3. Etude la nouvelle solution : proposition de commandes ... 41
4. ETAT DE L’ART ... 53
4.1. Les langages de programmation ... 53
4.2. Autres techniques de développement de site web ... 56
4.3. Les frameworks ... 57
4.4. Les systèmes de gestion de base de données ... 58
4.5. Protocoles/formats d’échanges entre clients et serveurs ... 59
5. PLANIFICATION ET BUDGET ... 61
5.1. Budget ... 61
5.2. Planning ... 61
6. CONCEPTION, REALISATION ET TESTS ... 62
6.1. Choix technologiques ... 62
6.1.1. Langages ... 62
6.1.2. Bases de données ... 62
6.2. Développement de la partie « Entrepôt de données » ... 62
6.2.1. Modification du modèle de données Oracle : les tables brutes ... 62
6.2.2. Modification du modèle de données Oracle : les tables agrégées ... 63
6.2.3. Modification des scripts d’import des transactions ... 64
6.2.4. Modification des scripts d’agrégation ... 65
Mémoire d’ingénieur Page 3 sur 103 2016/2017
6.3. Développement de la partie « ventes prévisionnelles » ... 69
6.3.1. Modification du modèle de données Edcms ... 69
6.3.2. Programme de génération des ventes prévisionnelles ... 70
6.4. Développement de la partie «propositions de commandes» ... 73
6.4.1. Modification du modèle de données Edcms ... 73
6.4.2. Génération de commandes automatiques ... 74
6.4.3. Modification de l’interface utilisateur ... 76
6.5. Tests ... 83
6.5.1. Les 3 principales typologies de test ... 83
6.5.2. Autres tests réalisés ... 84
6.5.3. Actions complémentaires à réaliser suite aux tests ... 84
6.6. Déploiement de l’application ... 85
7. DOCUMENTATION ... 86
7.1. Documentation technique... 86
7.2. Manuel utilisateur ... 86
8. EXPLOITATION DES RESULTATS ... 87
8.1. Formation des utilisateurs ... 87
8.2. Bilan ... 87
8.3. Estimation du potentiel économique ... 87
8.4. Résultats détaillés et quelques exemples sites/articles ... 88
8.4.1. Identification des effets calendrier sur les ventes... 89
8.4.2. Evolution du stock sur tous les sites ... 89
8.4.3. Evolution des ruptures de stock ... 90
8.4.4. Réduction massive du stock ... 91
8.4.5. Articles avec forte saisonnalité ... 91
8.5. Pistes d’amélioration des algorithmes ... 92
8.5.1. Durée de l’historique des ventes ... 92
8.5.2. Articles avec stock négatif ... 92
8.5.3. Rotation des stocks ... 92
9. CONCLUSIONS ... 93
10. ANNEXES ... 95
11. REFERENCES ... 99
12. LISTE DES SYMBOLES ... 100
Mémoire d’ingénieur Page 4 sur 103 2016/2017
1. INTRODUCTION
Ce mémoire marque le point final de ma formation au CNAM Lorraine, où j’ai été auditeur depuis 2008. Mon premier diplôme obtenu via le CNAM est un titre professionnel RNCP niveau 2 « Concepteur - Architecte informatique » obtenu en janvier 2010. Mon objectif est de compléter ce titre par un diplôme d’ingénieur qui me permettra d’avoir un diplôme en adéquation avec mon poste actuel de directeur technique de la société EURODATA.
Je souhaite présenter ici le contexte, ainsi que certaines problématiques du projet qui m’a été confié. En l’occurrence, ce mémoire a pour but de démontrer mes capacités à être ingénieur. Tel est le cas quand on peut à la fois comprendre l’architecture d’un système informatique, analyser une problématique fonctionnelle, faire des choix de conception et d’optimisation adaptés aux contraintes de performances, et savoir les argumenter. Ce projet consiste à modifier un progiciel existant avec pour objectif de réaliser un moteur de propositions de commande à haute valeur ajoutée qui pourra être commercialisé en tant que module complémentaire.
Dans le cadre de la gestion opérationnelle des réseaux de distributions structurés, EURODATA dispose d’une suite logicielle Edrms (EURODATA Retail Management Suite) permettant à ses clients de gérer tous les flux d’informations entre leur Siège et leurs stations services. Voici les principales fonctions existantes :
• Gestion du réseau de stations services.
• Gestion des référentiels articles et fournisseurs.
• Prix de ventes, prix d’achat actuels et futurs. Aide à la détermination des prix (module « Pricing »).
• Promotions.
• Gestion du stock : inventaires, périmés, cessions, rétrocessions. • Chaîne d’approvisionnement du fournisseur.
• Gestion des clients à crédit. • Calcul de redevances.
• Analyse décisionnelle marketing. • Analyse décisionnelle financière.
Le module « Chaîne d’approvisionnement du fournisseur » ou encore « Supply chain management » permet aujourd’hui au gestionnaire de la base de données centralisée et aux managers/gérants des sites de créer des commandes, de saisir des bordereaux de livraison et enfin d’introduire les factures fournisseurs. Les commandes peuvent être saisies manuellement ou sont générées automatiquement sur la base d’algorithmes tels que : la moyenne des ventes du mois précédent ou le stock minimum. Les commandes automatiques doivent ensuite être validées par l’utilisateur avec ou sans modifications puis expédiées par email ou EDI aux différents fournisseurs.
Mémoire d’ingénieur Page 5 sur 103 2016/2017 Le processus d’automatisation actuel reste incertain car les algorithmes de propositions de commandes associés à des ventes moyennes ne gèrent pas suffisamment de paramètres et les utilisateurs perdent encore trop de temps pour la finalisation de ces commandes. Un système de gestion de stock « state of the art » devrait être capable de gérer automatiquement les réapprovisionnements de manière avancée, sans intervention de l’utilisateur, et proposer ainsi les « business benefits » suivants :
• Réduction / Optimisation des stocks produits. • Réduction des ruptures de stock.
• Réduction des ventes perdues. • Réduction des tâches administratives.
Les spécifications relatives aux propositions de commandes sont organisées en 2 parties : • Génération de ventes prévisionnelles fiables sur lesquelles pourront s’appuyer les
algorithmes de propositions de commande. • Propositions de commandes.
Afin de générer des prévisions de ventes pertinentes, il est nécessaire de disposer d’un historique de ventes des dernières années avec un niveau de granularité assez fin : niveau article / site / jour au minimum. Nous utilisons pour cela un entrepôt de données de type ROLAP (« Relational On-Line Analytical Processing ») sous Oracle dans lequel sont importées toutes les transactions issues des sites. Ces transactions sont ensuite agrégées par article / niveau hiérarchique / période / site / secteur / pays / etc.
Nous nous heurtons malheureusement à une nouvelle limitation liée à la typologie des articles car seuls sont stockés les articles vendus à l’unité et ceux sous forme de composés (pack). Dans ce dernier cas, nous perdons l’information du nombre d’unités présentes dans un pack qui est indispensable pour obtenir un nombre global d’unité vendues (à l’unité et via un pack) :
• Nombre d’articles vendus à l’unité, • Nombre composés vendus (pack),
• Nombre de composants vendus (via un pack).
La modification de l’entrepôt de données est donc un prérequis incontournable au calcul des prévisions de ventes puis des propositions de commandes.
C’est pourquoi, le mémoire est organisé en 2 grandes parties : la première qui est dédiée à la modification de l’entrepôt de données et la deuxième qui traite des propositions de commande.
Mémoire d’ingénieur Page 6 sur 103 2016/2017
2.
PRESENTATION DE L’ENTREPRISE
2.1.
Présentation générale
EURODATA France est une SSII, Société de services en ingénierie informatique, opérant dans le monde du pétrole et filiale d’un groupe allemand du même nom.
Le groupe EURODATA, fondé en 1965, est actuellement présent dans dix pays européens avec quinze filiales et son siège social est basé à Saarbrücken en Allemagne. Le portefeuille du groupe EURODATA comprend des systèmes de facturation et de contrôle, des solutions d’archivage, des systèmes de gestion de réseaux commerciaux puis des « Smart Services » qui permettent l’intégration de données opérationnelles, l’automatisation de processus et du « reporting » temps réel.
Figure 2.1 - Activités du groupe EURODATA
Le fondement de toutes ces prestations est son centre de calcul certifié ISO 27001, un des plus modernes et sécurisé d’Europe, dans lequel sont hébergés tous les serveurs de production.
Le groupe EURODATA emploie plus de 500 personnes à travers l’Europe et fait partie lui-même d’une holding Allemande nommée ETL, European Tax & Law, composée de 700 cabinets comptables qui représentent plus de 6000 collaborateurs.
Le chiffre d’affaires 2015 du groupe EURODATA est de 50 millions d’euros et de 650 millions d’euros pour la holding ETL.
Mémoire d’ingénieur Page 7 sur 103 2016/2017 Depuis 2010, EURODATA France, sous l’impulsion du pétrolier français TOTAL, s’est internationalisée au-delà des frontières Européennes et propose désormais sa suite logicielle Edrms dans le monde entier via un réseau de partenaires ou de distributeurs.
En 2016, on dénombre plus de 12000 stations-service qui sont gérées avec des outils EURODATA.
2.2.
Organigramme du groupe EURODATA
La figure 2.2 ci-dessous présente l’organigramme du groupe EURODATA qui est reparti en trois filiales. On peut constater que la France est la seule filiale en charge des marchés en dehors de l’Europe.
Mémoire d’ingénieur Page 8 sur 103 2016/2017
2.3.
Organigramme EURODATA France
La figure 2.3 ci-dessous montre l’organigramme de la filiale EURODATA France composée de 35 personnes parmi lesquelles 25 sont rattachées au service technique.
Mémoire d’ingénieur Page 9 sur 103 2016/2017
2.4.
Clients et implantation géographique
2.4.1. Clients
La figure 2.4 ci-dessous donne un aperçu des principaux clients d’EURODATA France qui sont majoritairement composés de pétroliers.
Figure 2.4 – Clients EURODATA France
2.4.2. Implantation géographique
La figure 2.5 ci-dessous et le tableau qui suit présentent l’implantation géographique actuelle des solutions d’EURODATA France.
Mémoire d’ingénieur Page 10 sur 103 2016/2017 Pays/régions déployé(e)s
(Sept. 2016)
Pays/régions en cours de déploiement
Allemagne Luxembourg Congo Brazzaville
Angola Maurice (Ile) Kenya
Antilles Maroc Gabon
Belgique Mayotte Ghana
Cameroun Pays-Bas Mali
Egypte Nouvelle Calédonie Mozambique
France Ouganda Nigéria
Guinée Equatoriale Papouasie-Nouvelle Guinée La Réunion
Guyane Tahiti Sénégal
Irlande Tunisie Tanzanie
Iles Fidji Vanuatu Tchad
Mémoire d’ingénieur Page 11 sur 103 2016/2017
2.5.
La suite logicielle Edrms
2.5.1. Présentation générale
Figure 2.6 – Concept global Edrms
Comme on peut le voir sur la figure 2.6 ci-dessus la suite Edrms est organisée en 3 parties : • La partie gauche comprend les progiciels destinés aux gérants de stations-service.
On retrouve deux types de système :
o Le POS (Point Of Sales) ou PDV (Point De Vente) qui est utilisé par le caissier. o Le BOS (Back Office System) ou Système de gestion qui est utilisé par le
gérant.
• La partie centrale comprend les progiciels destinés aux sièges des compagnies pétrolières (directions pays ou zones). On retrouve le système HOS : « Head Office System » ou encore Système de gestion siège.
• La partie droite comprend les interfaces avec des tiers tels que : o Le Progiciel de Gestion Intégré (PGI) du pétrolier. o Les fournisseurs.
Mémoire d’ingénieur Page 12 sur 103 2016/2017 2.5.2. Progiciels stations-service – Partie POS
Le POS est utilisé par le caissier et est principalement en charge de la vente des carburants, des produits boutique mais aussi du lavage, de la restauration et des produits de la baie technique.
En complément de la vente, il assure la gestion de la piste avec la mise à jour des prix des pompes et la récupération des principaux éléments suivants :
• Transactions liées aux carburants, • Jaugeages des cuves,
• Livraisons des carburants.
EURODATA ne dispose pas de logiciel POS carburant mais s’interface avec des systèmes tiers existants tels que : Tokheim, Wayne, Lafon, Micrelec / Micros, Doms.
Lorsqu’un POS est connecté à un système BOS, alors toutes les opérations de créations sont verrouillées et le POS est considéré comme esclave du BOS. L’interface BOS / POS fonctionne en temps réel et un article créé ou modifié sur le BOS est immédiatement envoyé sur le POS. Idem pour une vente émise par le POS, elle est directement importée sur le BOS pour une mise à jour des stocks.
2.5.3. Progiciels stations-service – Partie BOS
Le BOS, Edbos, est utilisé par le gérant et est en charge de la gestion de la station-service. Il permet de gérer :
• Les référentiels articles et fournisseurs (si ce n’est pas géré centralement). • Les prix de ventes, les prix d’achat actuels et futurs des produits.
• Les promotions.
• Les stocks : inventaires, périmés, cessions, rétrocessions. • La chaîne d’approvisionnement du fournisseur.
• Les clients à crédit.
Comme cela a été indiqué précédemment, les opérations réalisées sur le BOS sont envoyées en temps réel sur le POS.
Le BOS EURODATA peut-être installé localement (client Windows) dans la station-service sur un ordinateur de bureau ou être hébergé dans notre centre de calcul si les communications Internet du pays le permettent. Si le BOS EURODATA est hébergé dans notre centre de calcul alors le client local n’est pas nécessaire et seul le navigateur Internet est utilisé.
Au logiciel BOS s’ajoute les principaux modules suivants :
• Edmobile qui est un terminal portable permettant d’effectuer des inventaires, des commandes, des réceptions, etc.
• Edelm (EURODATA Electronic Label Management) qui est un module d’affichage des prix articles sur des étiquettes électroniques.
Mémoire d’ingénieur Page 13 sur 103 2016/2017 2.5.4. Progiciels siège
Les progiciels siège permettent à la direction de la société pétrolière de piloter toutes les activités de son réseau de stations-service. On distingue 4 familles de produits :
• La première catégorie concerne la gestion opérationnelle qui est réalisée avec le progiciel Edcms (EURODATA Central Management System). Le progiciel permet :
o La gestion du réseau des stations services.
o La gestion des référentiels articles et fournisseurs.
o La gestion des prix de ventes, prix d’achat actuels et futurs. Une aide à la détermination des prix (module « Pricing »).
o La gestion des promotions.
o La gestion de la chaîne d’approvisionnement du fournisseur : commandes, bons de livraison et factures.
o Le calcul de redevances.
• La deuxième catégorie concerne l’analyse décisionnelle qui est réalisée avec Edreporting/Edqueries/Edchart qui est un entrepôt de données alimenté à partir de toutes les transactions des stations-service.
• La troisième catégorie concerne l’analyse financière qui est réalisée avec Edfibis (EURODATA Financial Business Intelligence Solution) qui est un entrepôt de données alimenté à partir des écritures comptables des stations ainsi que celles issues des cabinets comptables.
• La quatrième catégorie concerne l’automatisation qui est réalisée avec :
o Ededi (EURODATA Electronic Data Interchange) qui permet d’échanger des fichiers électroniques avec des fournisseurs comme par exemple l’envoi des commandes, la réception des bons de commande et des factures et la réception de l’assortiment fournisseur.
o Edarchive et Edbilling qui permettent de générer puis d’archiver des factures clients.
Lorsqu’un BOS est connecté à un système HOS, alors toutes les opérations de créations sont verrouillées et le BOS est considéré comme esclave du HOS. L’interface HOS / BOS fonctionne en temps réel et un article créé ou modifié sur le HOS est immédiatement envoyé sur le BOS.
Tous les produits siège sont des applications Web et ne nécessitent pas d’installation de client Windows.
2.5.5. Interfaces avec des systèmes tiers
Edrms dispose de nombreuses interfaces avec des systèmes tiers ce qui permet d’échanger efficacement des informations avec les acteurs et les systèmes suivants :
• Système de gestion intégré du pétrolier (PGI) pour lequel des interfaces SAP sont fréquemment nécessaires.
• Fournisseurs dans le cadre des réapprovisionnements : interface EDIFACT par exemple.
Mémoire d’ingénieur Page 14 sur 103 2016/2017
3.
CAHIER DES CHARGES
3.1.
Entrepôt de données
3.1.1. Présentation de la solution existante
3.1.1.1. Description
L’outil décisionnel marketing EURODATA proposé dans la suite logicielle >edrms est nommé >edreporting. Il s’agit d’un entrepôt de données de type ROLAP sous Oracle qui est alimenté quotidiennement à partir des transactions issues d’un système opérationnel de gestion, permettant aux dirigeants de réseaux structurés d’analyser en central les ventes (chiffre d’affaires HT, TTC, quantité, …) et les marges de leurs sites via des fonctionnalités classiques telles que le « benchmark » (comparaison d’un site par rapport à la moyenne d’un secteur ou d’un pays par exemple), le « basket analysis » (analyse des tickets ou du panier), le « crossing analysis » (analyse croisée), segmentation (classification des ventes).
Cette analyse centralisée est uniquement possible à condition d’avoir une base de données centralisée des articles qui doivent être identiques et surtout uniques pour tous les sites. En principe, ce n’est pas un problème pour les articles avec code-barres mais il est très important de veiller à ce que les articles sans code barre (baguette de pain, sandwich, menu, …) ne soient pas créés plusieurs fois avec des codes « courts » différents dans le système. Cette phase, traitée en amont par un progiciel opérationnel de gestion de base de données articles/fournisseurs centralisée nommé >edcms dans la suite logicielle >edrms, n’est pas détaillée dans les pages suivantes mais garantit l’intégrité des sources (données en entrée).
Les back-offices (BOS) installés sur site sont généralement des progiciels fournis par EURODATA (>edbos dans la suite logicielle >edrms) qui récupèrent en temps réels les transactions émises par des caisses (POS tiers généralement) pour assurer une bonne gestion du stock. Ces tickets de caisse sont ensuite envoyés chaque nuit vers notre centre de calcul pour alimenter l’outil décisionnel >edreporting. Les sites émettent en moyenne 350 tickets quotidiennement, eux-mêmes contenant 3 lignes de vente (ou 3 articles). Nous traitons les informations de 2000 sites dans le monde dans cet outil avec 3 années d’antériorité (l’année en cours et les 2 années précédentes) ce qui représente 766 500 000 tickets (2000 * 365 * 3 * 350) ou encore 2 299 500 000 lignes de ticket.
Les données brutes sont importées et intégrées dans la base de données Oracle à l’aide de scripts Perl et PL/SQL exécutés sur un serveur d’import ou encore ODS (Operational Data Store) sous Linux.
Mémoire d’ingénieur Page 15 sur 103 2016/2017 Les données brutes envoyées par les sites sont compressées dans une archive qui va globalement contenir 2 natures d’information : les tickets de ventes (fichier « reporting ») et les moyens de paiement associés (fichier « paymode »).
Ces informations sont ensuite importées dans 3 tables Oracle avec des scripts Perl : • REPORT : le ticket,
• REPORT_LINE : les lignes du ticket,
• PAYMODE : le ou les moyens de paiement utilisés.
Les colonnes de ces tables sont appelées indicateurs ou métriques et permettent de stocker toutes les données de vente telles que :
• Quantité - quantité d’article vendue
• Prix d’achat HT - le prix d’achat utilisé est variable en fonction de la méthode de gestion du client :
o Prix d’achat de référence négocié avec le fournisseur et géré centralement dans la base de données articles >edcms,
o Dernier prix d’achat facturé par le fournisseur obtenu lors de la saisie d’une facture fournisseur sur site (>edbos) ou au siège (>edcms),
o Prix d’achat moyen pondéré qui correspond à la moyenne des prix d’achat facturés dans le temps.
• Prix de vente TTC - prix de vente de l’article au moment de la vente qui peut également être variable en fonction de la méthode de gestion du client :
o Dans le cas de la gestion directe qui signifie que les sites (ou filiales) sont gérés en direct par le siège, il s’agit du prix de vente défini par le siège, o Dans le cas d’une gérance, les prix de vente sont suggérés par le siège et le
gérant du site peut accepter ce prix ou définir son propre prix. Si le contrat de gérance siège/site le permet, le prix de vente du site est utilisé et sinon il s’agit du prix de vente suggéré.
• Chiffre d’affaires TTC : quantité * prix de vente TTC • Chiffre d’affaires HT : quantité * (prix de vente TTC - TVA)
• Marge théorique : Chiffre d’affaires HT - (quantité * Prix d’achat HT)
• Mouvements de stock hors « ventes » - ces informations complémentaires sont envoyées par les back-office suite aux actions de mouvements de stock effectuées par les exploitants de site, voici quelques exemples :
o Ecart d’inventaire : différence entre la quantité comptée lors de l’inventaire et la quantité théorique présente dans le système,
o Périmé : produit ayant dépassé la date limite de consommation et qui a été retiré de la vente,
o Transfert de marchandise : transfert de stock d’un site A vers un site B dans le cas d’un problème d’approvisionnement fournisseur ou sur-stockage avec risque de périmé sur un grand nombre d’articles,
o Autres : consommation interne, cadeau client, etc.
Mémoire d’ingénieur Page 16 sur 103 2016/2017 Les « dimensions » ou encore axes d’analyse permettent de catégoriser des faits et des mesures. Elles sont communes à l'ensemble de l'organisation et voici les 3 principales :
• Produit : il s’agit de l’article vendu ayant un code unique et généralement un ou plusieurs codes à barre rattachés.
• Temps : date et heure de la transaction.
• Site : numéro de station-service et de point de vente (POS) associé.
Chaque dimension est ensuite associée à une hiérarchie : • Hiérarchie jour :
o Semaine, o Mois, o Année. • Hiérarchie produit :
o Catégorie niveau 1 (sous-famille), o Catégorie niveau 2 (famille), o … o Catégorie niveau n. • Hiérarchie site : o Secteur : Nord, Sud, Etc. o Organisation : Total Cameroun, Total Ouganda, Etc. o Zone : Afrique centrale, Moyen-Orient, Etc.
Les hiérarchies associées aux dimensions sont très importantes car elles permettent d’agréger les données de manière cohérente et d’utiliser des opérateurs multidimensionnels tels que :
• « Rotate » : sélection du couple de dimensions à cibler, • « Slicing » : extraction d'une tranche d'information,
• « Scoping » : extraction d'un bloc de données (opération plus générale que le slicing),
• « Drill-up » : synthèse des informations en fonction d'une dimension (exemple de drill-up sur l'axe temps : passer de la présentation de l'information jour par jour sur une année, à une valeur synthétique pour l'année),
• « Drill-down » : c'est l'équivalent d'un « zoom », opération inverse du drill-up, • « Drill-through » : lorsqu'on ne dispose que de données agrégées (indicateurs
totalisés), le « drill through » permet d'accéder au détail élémentaire des informations.
Mémoire d’ingénieur Page 17 sur 103 2016/2017 Ce processus d’agrégation que nous appelons « refresh » (rafraîchissement des données) est exécuté une fois par jour après que toutes les transactions aient été importées. L’heure et le type d’agrégation sont définis dans la table de planification du serveur d’importation ou encore la « crontab ».
La première étape du processus d’agrégation consiste à alimenter une table DAILY_MVTART qui est la somme des ventes par jour / article / site à partir des tables tickets. Cette table est ensuite utilisée pour toutes les agrégations hiérarchiques complémentaires, comme par exemples : • Hiérarchie jour : o WEEKLY_MVTART, o MONTHLY_MVTART, o YEARLY_MVTART. • Hiérarchie produit : o DAILY_MVTFAM, o WEEKLY_ MVTFAM, o MONTHLY_MVTFAM, o YEARLY_ MVTFAM, o Etc. • Hiérarchie site : o MONTHLY_MVTFAM_SEC, o MONTHLY_MVTFAM_ORG, o MONTHLY_MVTFAM_ZON, o Etc.
Mémoire d’ingénieur Page 18 sur 103 2016/2017 3.1.1.2. Architecture matérielle
La figure 3.1 ci-dessous présente l’architecture matérielle site et siège ainsi que les principales tâches associées aux serveurs et PC.
Figure 3.1 – Architecture matérielle et réseau
Le back-office (BOS) récupère en temps réel les tickets de caisse issus du POS.
Base de données Oracle
- Importation des transactions envoyées par le serveur de fichiers dans la base de données Oracle. - Agrégation
Les tickets de caisse « locaux » sont envoyés une fois par jour du BOS vers un serveur de fichiers SFTP dans notre centre de calcul.
Outils de restitution WEB accessibles depuis PC & Smartphone. Réception quotidienne des transactions
Mémoire d’ingénieur Page 19 sur 103 2016/2017 3.1.1.3. Architecture logicielle de l’entrepôt de données et spécifications techniques
Comme on peut le voir sur la figure 3.2, l’architecture logicielle de l’application Edreporting est composée de 3 parties et est appelée architecture 3-tier.
Figure 3.2 – Architecture de l’entrepôt de données
Point de vente / POS (local) :
Le point de vente a déjà été décrit au paragraphe § 2.5.2 « Progiciels stations-service – Partie POS ».
Back-office / BOS (local ou “cloud-based”) :
Le back-office a déjà été décrit au paragraphe § 2.5.3. « Progiciels stations-service – Partie BOS ».
Serveur d’import (Edreporting Import Server) :
Le serveur d’import >edreporting tourne sous Linux CentOS 5.5.
CentOS (Community enterprise Operating System) est une distribution GNU/Linux principalement destinée aux serveurs. Tous ses paquets, à l'exception du logo, sont des paquets compilés à partir des sources de la distribution RHEL (Red Hat Enterprise Linux), éditée par la société Red Hat. Elle est donc quasiment identique à celle-ci.
Utilisée par 20 % des serveurs web Linux, elle est l'une des distributions Linux les plus populaires pour les serveurs web. Depuis novembre 2013, elle est la troisième distribution la plus utilisée sur les serveurs web. La version 5.5 est datée du 14/05/2010.
Ce serveur est en charge de l’import des transactions dans la base de données Oracle ainsi que du processus d’agrégation décrits précédemment.
Mémoire d’ingénieur Page 20 sur 103 2016/2017 Serveur Oracle et entrepôt de données (Edreporting Oracle Database) :
Le serveur Oracle tourne sous Red Hat Enterprise Linux (RHEL) 6 avec Oracle Database 12c.
Red Hat Enterprise Linux est une distribution Linux produite par Red Hat et orientée vers le marché commercial et les serveurs d'entreprise. Red Hat prend en charge chaque version du logiciel pour une durée de 7 ans à 10 ans (depuis RHEL 5).
La version RHEL 6 update 8 est datée du 10/05/2016.
Oracle Database 12c (publiée en juillet 2013) est la base de données classée n° 1 dans le monde. Les fonctionnalités d’optimisation automatique des données permettent de gérer de façon efficace plus de données, à un coût de stockage moindre, tout en améliorant les performances des bases de données. La stabilité est remarquable.
Comme écrit précédemment la base de données/l’entrepôt de données >edreporting est de type ROLAP qui est une technique de modélisation et de stockage des données fondée sur une structure relationnelle.
Datamart (sous-ensemble de l’entrepôt de données)
Le Datamart est un sous-ensemble de l’entrepôt de données, constitué de tables au niveau détail et à des niveaux plus agrégés, permettant de restituer tout le spectre d’une activité métier. L’ensemble des Datamarts constitue l’entrepôt de données.
• Le datamart « Ventes » est alimenté à partir des transactions provenant des POS, • Le datamart « Livraisons » est alimenté à partir des bons de livraison et des factures
fournisseurs provenant des BOS,
• Le datamart « Stock » est alimenté à partir de tous les mouvements de stock hors-ventes.
Serveur Web (Edreporting Web Server) :
Le serveur WEB ou encore serveur http est un logiciel qui héberge des ressources et qui va assurer la communication des données entre un poste client et le serveur en gérant des requêtes qui respectent le protocole de communication Hypertext Transfer Protocol (HTTP).
Le serveur Web tourne sous Windows Server 2012 R2 car un système d’exploitation sous Linux n’aurait pas été capable de gérer les différents types d’applications proposés par
>edreporting.
En effet, les pages Web simples ont été développées avec Webdev (pour lequel Windows est fortement conseillé) et Java EE a été utilisé pour des fonctions non disponibles avec Webdev.
Mémoire d’ingénieur Page 21 sur 103 2016/2017 Webdev de la société PCSOFT est un environnement de développement intégré (EDI ou IDE en anglais) qui offre des outils pour faciliter le développement d’applications informatiques, ceci afin d’augmenter la productivité des développeurs.
Parmi les fonctionnalités "standards" que l’on retrouve dans un EDI, on peut citer notamment :
• L’auto complétion des variables et des fonctions en rapport du contexte dans lequel on se trouve : méthodes de l’objet, fonctions accessibles, etc...
• L’import des bibliothèques et packages nécessaires au bon fonctionnement du programme,
• Une vue qui permet d’inspecter le fichier courant, ce qui permet d’avoir rapidement un aperçu des fonctions et variables déclarées dans le fichier,
• L’intégration des systèmes de gestion de versions, • Un outil intégré pour réaliser les tests,
• Une documentation accessible dans l’éditeur pour le langage utilisé
Une application Webdev nécessite l’utilisation d’un Framework spécifique appelé « Moteur de déploiement Webdev ».
Java EE (Java Enterprise Edition, anciennement J2EE) est un ensemble de spécifications destinées aux applications Web d’entreprise. Tout comme le langage de programmation Java, Java EE est également maintenue par la société Oracle. Cette plate-forme a pour objectif de faciliter le développement d’applications Web, en proposant un ensemble d’API visant à répondre aux problèmes les plus couramment rencontrés par les développeurs. Ces derniers restent libres d’utiliser totalement ou partiellement les spécifications de Java EE. Eclipse est l’IDE utilisé pour les développements Java EE.
Pour terminer, Apache Tomcat est utilisé pour la partie Java EE. Il s’agit d’un serveur HTTP qui est également maintenu par Apache Software Foundation. Il est écrit en Java et fournit aussi un conteneur de servlets et JSP pour Java EE.
L’architecture globale de l’application >edreporting est donc de type 3-tiers :
L'architecture 3-tier (de l'anglais tier signifiant étage ou niveau) est un modèle logique d'architecture applicative qui vise à séparer très nettement trois couches logicielles au sein d'une même application ou système, à modéliser et présenter cette application comme un empilement de trois couches, étages, niveaux ou strates dont le rôle est clairement défini :
• La présentation des données : correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur ;
• Le traitement métier des données : correspondant à la mise en œuvre de l'ensemble des règles de gestion et de la logique applicative ;
• l'accès aux données persistantes (persistancy en anglais) : correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.
Mémoire d’ingénieur Page 22 sur 103 2016/2017 Dans cette approche, les couches communiquent entre elles au travers d'un " modèle d'échange ", et chacune d'entre elles propose un ensemble de services rendus. Les services d'une couche sont mis à disposition de la couche supérieure. On s'interdit par conséquent qu'une couche invoque les services d'une couche plus basse que la couche immédiatement inférieure ou plus haute que la couche immédiatement supérieure (chaque niveau ne communique qu'avec ses voisins immédiats).
3.1.1.4. Limitation de la solution existante
Comme expliqué dans l’introduction, seules les typologies d’articles vendus à l’unité (simple) et sous forme de pack (composé) sont gérées.
Prenons l’exemple d’une bouteille d’eau pouvant être achetée à l’unité ou sous forme de pack de 6 bouteilles :
• Achat de 5 bouteilles à l’unité.
• Achat de 2 packs.
La méthode de stockage dans l’entrepôt de données est la suivante :
Code barre Quantité Prix de vente Chiffre d’affaires
Bouteille à l’unité 8024884117809 5 0,95 4,75
Pack 8024884117125 2 5,70 11,40
Total 7 16,15
La quantité et le chiffre d’affaires global sont corrects mais la quantité ne reflète pas le nombre de bouteilles réellement vendues. Les stocks étant gérés à l’unité et les propositions de commandes basées sur les articles unitaires il est indispensable de stocker les informations de la manière suivante :
Code barre Quantité Prix de vente Chiffre d’affaires
Bouteille à l’unité (simple) 8024884117809 5 0,95 4,75 Pack (composé) 8024884117125 2 5,70 11,40 Bouteille à l’unité (composant) 8024884117809 12 0,95 11,40 Total simple + composant 17 16,15 Total composé 2 11,40
Mémoire d’ingénieur Page 23 sur 103 2016/2017 3.1.2. Etude de la nouvelle solution
3.1.2.1. Spécifications fonctionnelles générales
Les ventes d’articles composants issus d’articles composés (pack, menu, sandwich, forfait réparation, etc.) doivent être stockées directement dans les tables de l’entrepôt de données ce qui nécessite les modifications suivantes :
• Le format d’export des transactions envoyées par les back-office afin d’y inclure l’information des composants vendus via les composés,
• Le modèle de données Oracle de l’entrepôt de données pour gérer la typologie d’article composant,
• Les scripts d’import des transactions dans l’entrepôt de données, • Les scripts d’agrégation,
• Les rapports ou les requêtes générées dans les outils de reporting afin de ne pas cumuler toutes les typologies entre elles et de ne proposer que les options suivantes : (Simple + Composé) ou (Simple + Composant).
3.1.2.2. Modification de l’export des transactions
Le fichier d’export des transactions doit détailler les articles composants vendus dans le cadre d’un article composé.
La première étape consiste à ajouter un type de ligne avec les valeurs prédéfinies suivantes : • 0 = Simple,
• 1 = Composé.
Puis lors de la vente d’un composé, il faut indiquer à la suite les composants associés avec une notion de numéro de sous-ligne à ajouter (la notion de numéro de ligne de ticket étant déjà gérée).
Les modifications à effectuer sont indiquées en rouge ci-dessous :
Champs Valeur Date du mouvement Type de transaction Numéro de client Référence de la transaction Heure du mouvement Numéro de ligne
Type de ligne Typologie de l’article : 0 = Simple
1 = Composé
Numéro de sous-ligne Utilisé pour le détail (composants) des lignes de type 1.
Numéro d’article Libellé
Numéro de catégorie Taux de TVA Quantité Prix d’achat net
Mémoire d’ingénieur Page 24 sur 103 2016/2017 Prix de vente TTC
Montant TTC de la ligne remise déduite Montant HT de la ligne
Remise TTC de la ligne à partir d’une remise effectuée sur la ligne
…
Les lignes rouges du tableau ci-dessous indiquent le résultat attendu : détails des composants exportés juste après la ligne du composé associé.
Date Numéro ticket … Numéro de ligne Type de ligne Numéro de sous-ligne Numéro
article Libellé Quantité …
01/05/2016 1 … 1 0 0 8024884117809 Bouteille d’eau 4 …
01/05/2016 1 … 2 0 0 8024884117125 Bouteille d’eau gazeuse 3 …
01/05/2016 2 … 1 0 0 8024884117809 Bouteille d’eau 5 … 01/05/2016 2 … 2 1 0 8024884117251 Pack d’eau 2 … 01/05/2016 2 … 2 1 1 8024884117809 Bouteille d’eau 12 … 01/05/2016 2 … 3 1 0 8024884112345 Menu business 1 … 01/05/2016 2 … 3 1 1 8024884165478 Sandwich 1 … 01/05/2016 2 … 3 1 2 8024884158254 Boisson gazeuse 1 …
01/05/2016 2 … 4 0 0 8024884117125 Bouteille d’eau gazeuse 2 …
3.1.2.3. Modification du modèle de données Oracle
Toutes les tables qui stockent des ventes, tables brutes ou agrégées, sont à modifier afin d’y inclure la notion de composant.
3.1.2.4. Modification des scripts d’import des transactions
Les scripts en Perl d’import des transactions, exécutés sur le serveur Linux « Edreporting import », en charge de la lecture du fichier d’export des transactions et de l’écriture dans les tables brutes REPORT et REPORT_LINE sont à modifier afin de gérer les informations relatives aux articles composants :
• Type de ligne.
• Numéro de sous-ligne.
3.1.2.5. Modification des scripts d’agrégation
Les scripts Perl d’agrégation également exécutés sur le serveur Linux « Edreporting import » sont à modifier afin de gérer les informations relatives aux articles composants.
Prenons l’exemple de la table DAILY_MVTART qui est la table agrégée de référence (à partir de REPORT et REPORT_LINE) dont voici les règles de gestion à appliquer pour la nouvelle colonne TYPEARTICLE :
SI (RL.LINE_TYPE=0 ET RL.SUBLINE_NUMBER=0) ALORS DAILY_MVTART.TYPEARTICLE=0
Mémoire d’ingénieur Page 25 sur 103 2016/2017 SI (RL.LINE_TYPE=1 ET RL.SUBLINE_NUMBER=0) ALORS
DAILY_MVTART.TYPEARTICLE=1 FIN
SI (RL.LINE_TYPE=2 ET RL.SUBLINE_NUMBER=0) ALORS DAILY_MVTART.TYPEARTICLE=2
FIN
SI (RL.LINE_TYPE=1 OU RL.LINE_TYPE=2) ET RL.SUBLINE_NUMBER<>0 ALORS DAILY_MVTART.TYPEARTICLE=3
FIN
Avec RL = REPORT_LINE
3.1.2.6. Modification de l’interface utilisateur
Les parties suivantes de l’interface utilisateur Edreporting doivent être modifiées : • Processus de création d’un favori
o Sélection des articles à afficher (étape 3/8) : typologies d’articles, o Sélection des colonnes du rapport (étape 5/8),
Mémoire d’ingénieur Page 26 sur 103 2016/2017
3.2.
Propositions de commandes
3.2.1. Présentation de la solution existante
3.2.1.1. Description
L’outil opérationnel de gestion centralisée EURODATA proposé dans la suite logicielle
>edrms est nommé >edcms (Eurodata Central Management System). Il s’agit d’une application de type 3-tiers composée d’une base de données relationnelle SQL Server et d’une application Web développée avec Webdev et Java EE.
Comme cela a été indiqué au paragraphe § 2.5.4, cet outil permet de gérer centralement les aspects suivants :
• Gestion du réseau de stations services.
• Gestion des référentiels articles et fournisseurs.
• Prix de ventes, prix d’achat actuels et futurs. Aide à la détermination des prix (module « Pricing »).
• Promotions.
• Chaîne d’approvisionnement du fournisseur : commandes, livraisons et factures. • Calcul de redevances.
La figure 3.3 ci-dessous présente les principaux modules et fonctions de la solution >edcms.
Figure 3.3 – Principales fonctionnalités Edcms
Nous allons principalement nous intéresser à la gestion des commandes du module « Supply Chain Management » ou encore « Chaîne d’approvisionnement du fournisseur ».
Les commandes peuvent être saisies manuellement ou sont générées automatiquement sur la base d’algorithmes tels que : la moyenne des ventes du mois précédent, atteindre le stock optimum, etc. Les commandes automatiques doivent ensuite être validées par l’utilisateur avec ou sans modifications puis expédiées par email ou EDI aux différents fournisseurs.
Mémoire d’ingénieur Page 27 sur 103 2016/2017 3.2.1.2. Architecture logicielle de la solution Edcms et spécifications techniques
Comme on peut le voir sur la figure 3.4, l’architecture logicielle de l’application Edcms est composée de 3 parties et est appelée architecture 3-tier.
Figure 3.4 – Architecture de la solution Edcms
Point de vente / POS (local) :
Le point de vente a déjà été décrit au paragraphe § 2.5.2 « Progiciels stations-service – Partie POS ».
Back-office / BOS (local ou “cloud-based”) :
Le back-office a déjà été décrit au paragraphe § 2.5.3. « Progiciels stations-service – Partie BOS ».
Serveur d’import (Edcms Import Server) :
Le serveur d’import >edcms tourne sous Linux CentOS 5.5.
Ce serveur est en charge de l’import de données opérationnelles hors transactions dans la solution >edcms.
Serveur SQL Server (Edcms database) :
Le serveur de base de données >edcms tourne sous Windows Server 2012 R2 avec SQL Server 2014. Microsoft SQL Server est un SGBD développé et commercialisé par la société Microsoft et il ne fonctionne que sous les OS Windows.
Mémoire d’ingénieur Page 28 sur 103 2016/2017 Parmi les cinq services proposés par le serveur de base de données, seuls les services (1) et (5) sont utilisés :
1. Le moteur relationnel (OLTP) appelé SQL Server,
2. Le moteur décisionnel (OLAP) appelé SSAS (SQL Server Analysis Services) incluant un moteur de stockage pour les cubes, des algorithmes de forage et différents outils de BI (Business Intelligence),
3. Un ETL (Extract Transform and Load) appelé SSIS (SQL Server Integration Services) destiné à la mise en place de logiques de flux de données, notamment pour alimenter des entrepôts de données (data warehouse),
4. Un outil de génération d'état appelé SSRS (SQL Server Reporting Services) permettant de produire des rapports,
5. Un système de planification de travaux et de gestion d'alerte appelé Agent SQL qui utilise lui aussi les services du moteur SQL.
La solution >edcms n’étant pas destinée à gérer une énorme quantité de données, SQL Server avait été sélectionné au détriment d’Oracle pour des raisons budgétaires.
Serveur Web (Edcms Web Server) :
La configuration du serveur Web >edcms est identique à celle du serveur Web
>edreporting décrite au paragraphe § 3.1.1.3. 3.2.1.3. Limitation de la solution existante
Le processus d’automatisation actuel est essentiellement basé sur des moyennes de ventes, les 30 derniers jours par exemple, et c’est pourquoi, pour des articles à forte saisonnalité, il arrive fréquemment d’obtenir des propositions incorrectes. Prenons le cas d’une proposition de commande exécutée début septembre pour des glaces qui ont été vendues en abondance sur août, le système va proposer un réapprovisionnement trop optimiste pour septembre.
Les commandes doivent être générées automatiquement à partir de ventes prévisionnelles et à partir de propositions de commandes avancées afin de limiter les interventions manuelles des responsables de station.
Les principaux objectifs du réapprovisionnement automatique sont les suivants : • Réduction / Optimisation des stocks produits.
• Réduction des ruptures de stock. • Réduction des ventes perdues. • Réduction des tâches administratives.
Mémoire d’ingénieur Page 29 sur 103 2016/2017 3.2.2. Etude de la nouvelle solution : ventes prévisionnelles
3.2.2.1. Spécifications fonctionnelles générales
Les ventes prévisionnelles brutes sont générées à partir de l’historique des ventes en utilisant une ou plusieurs périodes de référence/comparatives :
• Périodes de référence simples, • Périodes de référence multiples,
• Périodes de référence simples/multiples avec tendance fixe, • Périodes de référence multiples avec tendance calculée, • Moyenne des X derniers jours ou d’une période de référence.
Une fois ces ventes prévisionnelles obtenues, il est nécessaire de les lisser en utilisant ou en combinant les techniques suivantes :
• Moyenne mobile,
• Index de saisonnalité et normalisation, • Lissage exponentiel simple (LES), • Ajustement via une tendance.
Pour terminer, les ventes prévisionnelles corrigées sont encore ajustées en fonction des index suivants :
• Index promotionnel, • Index événementiel,
• Index période de désactivation, • Prévision fixe.
3.2.2.2. Etude des périodes comparatives
Périodes de référence simples
Sélection d’une période de référence : les valeurs de l’année précédente par exemple.
01/06 02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06 …
Demandes A-1 857 795 804 957 1126 1078 1300 1250 1248 1216 …
Prévision 857 795 804 957 1126 1078 1300 1250 1248 1216 …
Prévisions = Demandes A-1.
Type de période : • Annuelle : A-1.
• Mensuelle : M-1 ou M-3 (maximum M-6). • Période libre (mode manuel uniquement)
Mémoire d’ingénieur Page 30 sur 103 2016/2017 Périodes de référence multiples
Moyenne des 2 dernières années par exemple.
01/06 02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06 …
Demandes A-2 857 795 804 957 1126 1078 1300 1250 1248 1216 …
Demandes A-1 869 803 780 961 1200 1070 1324 1286 1252 1226 …
Prévisions 863 799 792 959 1163 1074 1312 1268 1250 1221 …
Prévisions = Moyenne (Demandes A-2, Demandes A-1)
Type de période :
• Annuelle : A-2 et A-1.
• Mensuelle : M-3, M-2, M-1 (maximum M-11). • Période libre (mode manuel uniquement)
La figure 3.5 montre l’évolution de la prévision (moyenne des demandes) par rapport à la demande A-1 et A-2.
Figure 3.5 – Prévisions calculées sur moyenne des 2 dernières années
Périodes de référence simples/multiples avec tendance fixe
Moyenne des 2 dernières années par exemple puis application d’une tendance fixe définie par l’utilisateur. 01/06 02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06 … Demandes A-2 857 795 804 957 1126 1078 1300 1250 1248 1216 … Demandes A-1 869 803 780 961 1200 1070 1324 1286 1252 1226 … Moyenne 863 799 792 959 1163 1074 1312 1268 1250 1221 … Tendance fixe 1,02 1,02 1,02 1,02 1,02 1,02 1,02 1,02 1,02 1,02 … Prévisions 880 815 808 978 1186 1095 1338 1293 1275 1245 …
Mémoire d’ingénieur Page 31 sur 103 2016/2017 Type de période :
• Annuelle : A-2 et A-1.
• Mensuelle : M-3, M-2, M-1 (maximum M-11). • Période libre (mode manuel uniquement)
Périodes de référence multiples avec tendance calculée Calcul de la tendance sur les 2 derniers mois.
01/06 02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06 …
Demandes M-2 857 795 804 957 1126 1078 1300 1250 1248 1216 …
Demandes M-1 869 803 780 961 1200 1070 1324 1286 1252 1226 …
Tendance 1,014 1,0101 0,9701 1,0042 1,0657 0,9926 1,0185 1,0288 1,0032 1,0082 …
Prévisions 881 811 757 965 1279 1062 1348 1323 1256 1236 …
Prévision = (Demande M-1) x Tendance (Demande M-2, Demande M-1)
Type de période :
• Annuelle : A-2 et A-1.
• Mensuelle : M-3 et M-2 (maximum M-11 et M-10). • Période libre (mode manuel uniquement)
La figure 3.6 illustre l’évolution de la prévision avec tendance par rapport à la demande M-1 et M-2.
Mémoire d’ingénieur Page 32 sur 103 2016/2017 Moyenne des X derniers jours ou d’une période de référence
Moyenne des 10 derniers jours par exemple à partir du 02/06.
01/06 31/05 30/05 29/05 28/05 27/05 26/05 25/05 24/05 23/05 …
Demandes 869 803 780 961 1200 1070 1324 1286 1252 1226
02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06 11/06 …
Prévisions moyennes 1077 1077 1077 1077 1077 1077 1077 1077 1077 1077
Prévisions moyennes = Moyenne (Demandes)
3.2.2.3. Etude des lissages de données sur périodes comparatives
Moyenne mobile
Une moyenne mobile permet de « lisser » une série de valeurs exprimées en fonction du temps. Elle permet d'éliminer les fluctuations les moins significatives.
Prenons l’exemple de la série de prévisions ci-dessous :
31/05 01/06 02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06
Prévisions brutes 862 863 799 792 959 1163 1074 1312 1268 1250 1221
Moyenne mobile NS 841 818 850 971 1065 1183 1218 1277 1246 NS
Moyenne mobile 01/06 = Moyenne (Prévision 31/05, Prévision 01/06, Prévision 02/06)
La figure 3.7 présente l’évolution de la moyenne mobile par rapport à la prévision brute.
Mémoire d’ingénieur Page 33 sur 103 2016/2017 Index de saisonnalité et normalisation
L’index de saisonnalité permet de mesurer le poids d’un mois sur la base de la moyenne annuelle. L’opération peut être effectuée en considérant plusieurs années.
01/06 02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06 …
Demandes A-2 857 795 804 957 1126 1078 1300 1250 1248 1216 …
Demandes A-1 869 803 780 961 1200 1070 1324 1286 1252 1226 …
Demandes totales 1726 1598 1584 1918 2326 2148 2624 2536 2500 2442 …
Index 0,81 0,75 0,74 0,90 1,09 1 1,23 1,18 1,17 1,14 …
Index 01/06 : Demande totale 01/06 / Moyenne (Demandes totales 01/06 au 10/06)
La normalisation de la demande consiste à désaisonnaliser c’est-à-dire supprimer les variations liées à la saisonnalité.
Exemple de normalisation : 01/06 02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06 … Demandes M-2 857 795 804 957 1126 1078 1300 1250 1248 1216 … Demandes M-1 869 803 780 961 1200 1070 1324 1286 1252 1226 … Tendance 1,014 1,0101 0,9701 1,0042 1,0657 0,9926 1,0185 1,0288 1,0032 1,0082 … Prévisions 881 811 757 965 1279 1062 1348 1323 1256 1236 … Index 0,81 0,75 0,74 0,90 1,09 1 1,23 1,18 1,17 1,14 … Demande/prévision normalisée 1088 1081 1023 1072 1173 1062 1096 1121 1074 1084 …
Prévision normalisée 01/06 : Prévisions 01/06 / Index 01/06
La figure 3.8 montre l’évolution de la demande normalisée par rapport à la demande brute.
Figure 3.8 – Demandes brutes versus Demandes normalisées
La normalisation des valeurs est indispensable si l’on souhaite appliquer un lissage exponentiel simple.
Mémoire d’ingénieur Page 34 sur 103 2016/2017 Lissage exponentiel simple (LES)
Un lissage exponentiel simple s’applique à des séries chronologiques sans tendance. Le principe consiste à donner plus d’importance aux dernières observations. On cherche à obtenir une valeur lissée en t pour la reporter tout simplement en t+1.
Cette technique est très utilisée, notamment en gestion de stocks quand il existe un très grand nombre de références. Elle est plus réactive que les moyennes car elle prend rapidement en compte une modification de tendance.
La formule est la suivante : LESt = αααα(PREVI)t-1 + (1-αααα)LESt-1
Le coefficient alpha (α), compris entre 0 et 1, s’applique à la dernière réalisation. C’est la constante de lissage (ou coefficient de lissage) que l'on s'est choisie. Évidemment, si elle est égale à 1, on ne fait que reporter en t + 1 l’observation de la période t. Le coefficient (1 – α) s’applique quant à lui à la prévision précédente.
En raison de la formule récurrente du LES, on est obligé de choisir une valeur à partir de laquelle les prévisions seront effectuées. On prend souvent la moyenne des deux ou trois premières observations mais ce choix est arbitraire.
Le choix de la constante de lissage est très important. Si l’on choisit α = 1, on reporte tout simplement la dernière donnée. Ainsi, une valeur élevée de α produit des prévisions très réactives tandis qu’une valeur faible implique un poids du passé plus fort et donc des prévisions davantage lissées.
Prenons l’exemple de la série de prévisions ci-dessous avec α = 0,7 :
31/05 01/06 02/06 03/06 04/06 05/06 06/06 07/06 08/06 09/06 10/06
Prévisions brutes 862 863 799 792 959 1163 1074 1312 1268 1250 1221
Lissage exponentiel s. NS 841 857 816 799 911 1087 1078 1242 1260 1253
La valeur du lissage exponentielle au 01/06 est obtenue en effectuant une valeur moyenne des prévisions au 31/05, 01/06 et 02/06 : (Prévision 31/05 + Prévision 01/06 + Prévision 02/06) / 3.
La valeur du lissage exponentielle au 01/06 est obtenu en effectuant le calcul suivant : (Prévision 01/06) * 0,7 + (LES 01/06) * (1-0,7).
Les figures 3.9, 3.10 et 3.11 suivantes présentent l’évolution des prévisions lissées avec différents coefficient alpha (α) par rapport aux prévisions brutes.
Mémoire d’ingénieur Page 35 sur 103 2016/2017
Figure 3.9 – Prévisions brutes versus Prévisions lissées avec coefficient α = 0,7
Figure 3.10 – Prévisions brutes versus Prévisions lissées avec coefficient α = 0,3
Mémoire d’ingénieur Page 36 sur 103 2016/2017 Ajustement via une tendance
La tendance est calculée via la régression linéaire simple (RLS).
La RLS permet de chercher l'éventuelle relation fonctionnelle linéaire qui existerait entre une valeur explicative (ou indépendante) x et une variable aléatoire à expliquer (ou dépendante) y.
Equation de la droite des moindres carrés : y = mx + b avec
• m : le coefficient de régression
• b : la constante de régression (intercept).
Prenons l’exemple de la série de prévisions ci-dessous :
1 2 3 4 5 6 7 8 9 10 …
Prévision 100 110 115 135 160 179 186 168 165 150 …
Où n est le nombre de valeurs utilisées dans le calcul (n = 10, dans notre exemple).
Détermination du coefficient de régression « m » :
• Soit a1 égal à n fois la somme des valeurs x multipliées par les valeurs y : o a1 = 10 x [(1 * 100) + (2 * 110) + … + (10 * 150)] = 87100
• Soit b1 égal à la somme des valeurs x multipliées par les valeurs y : o b1 = (1 + 2 + … +10) x (100 + 110 + … + 150) = 80740 • Soit c1 égal à n fois la somme des carrés des valeurs x :
o c1 = 10 x (1² + 2² + … + 10²) = 3850 • Soit d1 égal au carré de la somme des valeurs x :
o d1 = (1 + 2 + … + 10)² = 3025
• Soit m = (a1 – b1) / (c1 – d1) = (87100 – 80740) / (3850 – 3025) = 7,71
Détermination de la constante de régression b (intercept) : • Soit e1 égal à la somme des valeurs y :
o e1 = (100 + 110 + … + 150) = 1468
• Soit f1 égal au produit du coefficient de régression et de la somme des valeurs x : o f1 = 7,71 * (1 + 2 + … + 10) = 424
• Soit b = (e1 – f1) / n = (1468 – 424) / 10 = 104,40
L’équation suivante est obtenue : y = 7,71x + 104,40
1 2 3 4 5 6 7 8 9 10 …
Prévisions 100 110 115 135 160 179 186 168 165 150 …
Mémoire d’ingénieur Page 37 sur 103 2016/2017 La figure 3.12 illustre la tendance calculée sur la base des prévisions brutes.
Figure 3.12 – Tendance calculée sur base de l’évolution des prévisions brutes
3.2.2.4. Autres paramètres avec impact sur les ventes
En complément de l’historique des ventes avec périodes comparatives et formules de lissage, les index/paramètres supplémentaires ci-après doivent être gérés :
Index promotionnel :
Dans un premier temps l’index promotionnel sera géré manuellement : si l’utilisateur considère qu’un article en promotion va provoquer une augmentation des ventes de 25% alors un index de 1,25 doit être introduit. Les dates qui correspondent aux périodes promotionnelles à venir sont reprises automatiquement à partir des fiches promotions. Dans un deuxième temps, l’index promotionnel pourrait être calculé automatiquement sur la base de l’historique des ventes périodes normales vs périodes promotionnelles :
• Baisse progressive des ventes avant la période promotionnelle (index<1) • Forte augmentation des ventes au début de la période promotionnelle.
• Diminution progressive des ventes en fin de période promotionnelle avant retour à la normale.
Index événementiel :
Dans un premier temps l’index événementiel sera géré manuellement via l’identification des jours fériés, jours de de fête, périodes de vacances etc. et des index associés dans un calendrier de l’organisation / du site.
Dans un deuxième temps, l’index événementiel sera calculé automatiquement sur la base de l’historique des ventes périodes normales vs périodes événementiels.
Mémoire d’ingénieur Page 38 sur 103 2016/2017 Index période de désactivation :
L’index de période de désactivation est géré manuellement via la saisie des éléments suivants dans un calendrier de l’organisation / du site :
• Jours d’ouverture / jours de fermeture. • Période de désactivation des articles.
3.2.2.5. Résultat attendu avec combinaison des différents paramètres
Le tableau ci-dessous présente un exemple de de calcul de prévision de ventes journalières avec combinaison des différents paramètres détaillés précédemment.
La colonne A du tableau correspond aux jours du mois et on considère que la demande de prévision est exécutée le 5 du mois (ligne 5 du tableau). Les lignes précédentes grisées sont simplément présentes pour indiquer les initialisations de variables nécessaires aux opérations de lissages et calculs de tendances.
La colonne B correspond à la demande (prévision) initiale ou encore appelée « brute » qui a été calculée sur la base des 2 dernières années : moyenne des 2 dernières années avec tendance calculée.
La prévision finale est indiquée dans la colonne N et résulte des différentes opérations réalisées dans les colonnes de C à M qui sont décrites sous le tableau.
P é ri o d e D e m a n d e /P ré v is io n in it ia le In d e x d e sa is o n n a li té P ré v is io n n o rm a li sé e L is sa g e d e l a p ré v is io n ( L E S ) ( αααα = 0 ,4 0 ) T e n d a n ce L is sa g e d e l a te n d a n ce ( L E S ) ( αααα = 0 ,6 0 ) P ré v is io n a v e c te n d a n ce P ré v is io n a v e c in d e x d e sa is o n n a li té In d e x p ro m o ti o n n e l In d e x é v é n e m e n ti e l In d e x p é ri o d e d e d é sa ct iv a ti o n P ré v is io n f ix e (v a le u r p ré d é fi n ie ) P ré v is io n f in a le A B C D E F G H I J K L M N 1 95 0,85 111,76 2 103 0,87 118,39 112,00 3 113 0,92 122,83 114,56 2,56 3,00 4 120 0,98 122,45 117,86 3,31 3,01 5 149 1,12 133,04 119,70 1,83 2,42 125,76 140,85 1,00 1,00 1,00 140 6 162 1,20 135,00 125,03 5,34 3,93 134,87 161,84 1,00 1,00 1,00 162 7 158 1,18 133,90 129,02 3,99 4,53 140,34 165,60 1,00 1,00 0,50 83 8 158 1,15 137,39 130,97 1,95 2,77 137,89 158,57 1,00 1,00 0,25 40 9 146 1,07 136,45 133,54 2,57 2,32 139,34 149,10 1,00 1,00 1,00 149 10 148 0,99 149,49 134,70 1,16 1,73 139,02 137,63 1,00 1,00 1,00 150,00 150 11 147 0,87 168,97 140,62 5,92 4,02 150,66 131,07 1,00 1,00 1,00 150,00 150 12 138 0,88 156,82 151,96 11,34 9,17 174,88 153,90 1,00 1,00 1,00 154 13 138 0,86 160,47 153,90 1,94 5,70 168,16 144,61 0,95 1,00 1,00 137 14 188 0,87 216,09 156,53 2,63 2,35 162,41 141,30 1,25 1,00 1,00 176 15 190 0,85 223,53 180,35 23,83 15,35 218,72 185,91 0,95 1,05 1,05 195
