Dédicaces « Agir d’abord, rectifier ensuite s’il y a lieu, reprendre tout à zéro s’il le faut, mais ne jamais rester inactif à la recherche du parfait. » Jean Cocteau Il est naturel que ma pensée la plus forte aille vers ma mère, à qui je dois la vie et une part essentielle de ma personnalité. Qu’elle sache que l’amour qu’elle me donne continue à m’animer et me permet d’envisager l’avenir comme un défi. Ce travail est dédié à l’âme de ma grand-mère, qui m’a toujours encouragé et motivé dans mes études. Je ne saurais oublier de remercier toutes les personnes qui me sont chères, en particulier mes frères. J’associe à mes remerciements l’ensemble des étudiants du master ISIC pour l’ambiance chaleureuse du travail. -Mokhtar BICHIOU- i Remerciements La réalisation de ce mémoire a été possible grâce au concours de plusieurs personnes à qui je voudrais témoigner toute ma reconnaissance. J’adresse tout d’abord mes remerciements à mon directeur de mémoire, Monsieur Amara BENJEDDOU . Présent et disponible, il a encouragé mes initiatives par le biais de la grande liberté d’action qu’il m’a autorisée. Je remercie vivement les membres du jury pour leur présence très appréciée et pour l’hon- neur qu’ils me font en acceptant d’évaluer mon travail. Je désire aussi adresser mes sincères remerciements à mon encadrant professionnel Mon- sieur Nabil MAJOUL qui m’a fourni les outils nécessaires à la réalisation de ce projet. Je le remercie ainsi pour ses conseils et ses critiques.. Je tiens à remercier sincèrement tout le personnel de la société Targa-consult pour sa sym- pathie et sa bonne humeur. Enfin, je remercie mon ami Wissem EL HAMMI que j’aime pour sa sincère amitié et confiance, et à qui je dois ma reconnaissance et mon attachement. -Mokhtar BICHIOU- « Je crois qu’on ne peut mieux vivre qu’en cherchant à devenir meilleur, ni plus agréable- ment qu’en ayant pleine conscience de son amélioration. » SOCRATE ii Liste des acronymes BI B usiness I ntelligence DSI D épartement des S ystèmes d’ I nformations DW D ata W arehouse ETL E xtract, T ransform and L oad ISIC I ngénierie des S ystèmes d’ I nformation et des C onnaissances SGBD S ystème de G estion de B ase de D onnées SGBDR S ystème de G estion de B ases de D onnées R elationnelles SQL S tructured Q uery L anguage ERP E nterprise R esource P lanning PGI P rogiciel de G estion I ntégré IT I nformation T echnology MDX M ulti D imensional e X pression iii Table des figures 1.1 Pyramide modélisant le processus de la BI[2] . . . . . . . . . . . . . . . . . . 4 1.2 Flux informationnel lié au processus BI[2] . . . . . . . . . . . . . . . . . . . . 4 1.3 le data warehouse d’après Ralph Kimball . . . . . . . . . . . . . . . . . . . . 5 1.4 les différents flux de l’entrepôt de données[5] . . . . . . . . . . . . . . . . . . 6 2.1 Diagramme d’activité modélisant l’édition des rapports . . . . . . . . . . . . . 11 3.1 Modèle Physique de Données . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1 Le quadrant magique des fournisseurs de BI et d’analytiques . . . . . 24 4.2 Configuration de la connexion à la source de données . . . . . . . . . . . . . . 25 4.3 Sélection de la table à partir de la source de données avec Talend . . . . . . . . 26 4.4 Nettoyage de la table F COMPTET . . . . . . . . . . . . . . . . . . . . . . . 26 4.5 Connexion à la source de données avec _Tableau . . . . . . . . . . . . . . . . . 27 4.6 La manière de connexion aux données . . . . . . . . . . . . . . . . . . . . . . 28 4.7 Page de démarrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.8 Aperçu global sur la situation de l’entreprise . . . . . . . . . . . . . . . . . . . 30 4.9 Tableau de bord d’analyse des ventes . . . . . . . . . . . . . . . . . . . . . . . 31 4.10 Tableau de bord d’analyse de la marge brute . . . . . . . . . . . . . . . . . . . 32 4.11 Infobulle d’indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.12 Analyse des ventes par rapport au mois précédent . . . . . . . . . . . . . . . . 33 4.13 Tableau de bord comparatif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.14 Analyse des valeurs aberrantes . . . . . . . . . . . . . . . . . . . . . . . . . . 35 B.1 Connexion avec R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 B.2 Connexion Rserve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 B.3 Création d’un champ calculé avec Tableau . . . . . . . . . . . . . . . . . . . . 41 B.4 Scripte R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 C.1 Chronogramme de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 iv Liste des tableaux 1.1 Le dimensionnel VS le relationnel . . . . . . . . . . . . . . . . . . . . 6 1.2 Caractéristiques d’un bon indicateur . . . . . . . . . . . . . . . . . . . 8 3.1 Descriptif de la table F DOCENTET . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Descriptif de la table F DOCLIGNE . . . . . . . . . . . . . . . . . . . . . . . 19 3.3 Descriptif de la table F ARTICLE . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4 Descriptif de la table F COMPTET . . . . . . . . . . . . . . . . . . . . . . . 20 3.5 Descriptif de la table F COLLABORATEUR . . . . . . . . . . . . . . . . . . 20 3.6 Descriptif de la table F ECRITUREC . . . . . . . . . . . . . . . . . . . . . . 21 v Table des matières Introduction générale 1 I Aspects théoriques 2 1 Etat de l’art 3 1.1 Théorie de la BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1 Définition de la BI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.2 Le data warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.3 Le data mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Bases de données relationnelles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2.1 La Modélisation relationnelle . . . . . . . . . . . . . . . . . . . . . . 6 1.2.2 Le dimensionnel VS le relationnel . . . . . . . . . . . . . . . . . . . . 6 1.3 Tableau de bord et indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.1 Définition d’un tableau de bord . . . . . . . . . . . . . . . . . . . . . 7 1.3.2 Pourquoi un tableau de bord ? . . . . . . . . . . . . . . . . . . . . . . 7 1.3.3 Un tableau de bord comment ? . . . . . . . . . . . . . . . . . . . . . . 7 1.3.4 Comment Avoir un tableau de bord efficace ? . . . . . . . . . . . . . . 8 1.3.5 Définition d’un indicateur . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3.6 Caractéristiques d’un bon indicateur . . . . . . . . . . . . . . . . . . 8 1.3.7 Principales erreurs à éviter . . . . . . . . . . . . . . . . . . . . . . . . 9 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2 Cadre du projet 10 2.1 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.2 Activités de Targa-consult . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1 Description du système existant . . . . . . . . . . . . . . . . . . . . . 11 2.3 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4 Contexte du projet et solution proposée . . . . . . . . . . . . . . . . . . . . . 12 2.5 Méthodologie de réalisation adoptée . . . . . . . . . . . . . . . . . . . . . . . 12 2.5.1 Approches de collecte d’informations . . . . . . . . . . . . . . . . . . 13 2.5.2 Approches utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5.3 Préparation de l’entretien . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.6 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 vi 2.6.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.6.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 II Solution décisionnelle 16 3 Conception de la solution 17 3.1 Modélisation Sage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1 Outil utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.2 Processus de modélisation . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2.3 Liste des tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3 Modèle physique de données (MPD) . . . . . . . . . . . . . . . . . . . . . . . 21 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4 Réalisation 23 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Environnement et outils de travail . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.1 Configuration matérielle . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.2 Architecture technique . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.3 Nettoyage des données . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.4 Connexion à la source de données . . . . . . . . . . . . . . . . . . . . 27 4.3 Présentation des indicateurs utilisés . . . . . . . . . . . . . . . . . . . . . . . 27 4.4 Interfaces homme machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4.1 Page de démarrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4.2 Aperçu global sur la situation de l’entreprise . . . . . . . . . . . . . . 29 4.4.3 Analyse des ventes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4.4 Analyse de la marge brute . . . . . . . . . . . . . . . . . . . . . . . . 31 4.4.5 Analyse comparative . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.6 Analyse des marges avec des scripts R . . . . . . . . . . . . . . . . . . 34 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Conclusion générale 35 Bibliographie 37 Nétographie 38 A Questionnaires d’analyse des besoins 39 A.1 Conduite de l’entretien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 A.2 Questionnaire 1 (collecte des besoins en terme d’analyse) . . . . . . 39 A.3 Questionnaire 2 (les indicateurs les plus utilisés) . . . . . . . . . . . 39 vii B Intégration de R avec Tableau Desktop 40 B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 B.2 Configuration d’une connexion Rserve avec Tableau Desktop . . . 40 B.3 Champs calculés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 C Chronogramme de travail 43 viii Introduction générale L’entreprise évolue dans un environnement en perpétuel changement. Dans ce contexte, l’information demeure la clé de sa réussite. Pour l’efficacité de prise des décisions, un système d’information ainsi que les outils d’aide à la décision sont indispensables. Les entreprises ayant réalisé des bénéfices sont en grande partie celles qui ont pu utiliser minutieusement leurs propres informations et dans certains cas celles de leurs concurrents. Afin d’assurer le suivi de ses processus, la majorité de ces entreprises ont fait recours à un système d’intégrité de données (ERP). Les bases de ce type de systèmes seront les données réelles de l’entreprise. De ce fait, l’étude, la planification ainsi que les estimations seront plus proches de la réalité. A partir de cette collecte et de cette intégrité de données, la notion de tableaux de bord a eu sens et pourra être un indicateur sur l’activité de l’entreprise. Notre projet de mastère s’inscrit dans ce contexte. Il s’agit de concevoir et de mettre en place une solution décisionnelle qui pourrait servir toute entreprise utilisant l’ERP Sage . L’idée consiste à se connecter à une base de données Sage et à générer automatiquement des tableaux de bord, afin d’aider les décideurs à exploiter la masse importante d’information disponible. Ce travail s’inscrit dans le cadre d’un projet de fin d’études, en vue de l’obtention du Diplôme de Mastère Professionnel en Ingénierie des Systèmes d’Information et des Connaissances. Il a été mené intégralement au sein du cabinet de conseil Targa-consult , conformément au planning de travail de l’annexe 3. Ce rapport se compose de quatre chapitres. Le premier sera consacré à la présentation des aspects théoriques du domaine de l’informatique décisionnelle. Le deuxième chapitre traitera la présentation du cadre du projet, l’analyse des spécifications ainsi que l’étude de l’existant. Le troisième chapitre sera dédié à la conception de la solution ; la réalisation de cette solution fera également l’objet du quatrième chapitre. 1 Première partie Aspects théoriques 2 Chapitre 1 Etat de l’art Introduction Dans un contexte où les sources d’information sont actuellement éclatées, volumineuses et complexes, il y a un réel besoin de les consolider et de les analyser afin d’avoir une vision globale et d’optimiser le patrimoine informationnel de l’entreprise. Or, trop d’informations tuent l’information . Pour assurer sa pérennité, l’entreprise est en effet confrontée à un double défi : Gérer l’immense quantité de données externes et internes auxquelles elle a de plus en plus facilement accès, La transformer en informations utiles à un pilotage efficace de son action s’adaptant à l’évolution continue de son environnement. Conscients de cet enjeu, la plus part des entreprises, quels que soient leurs secteurs d’activité, font le choix de mettre en place un Système d’Information Décisionnel (SID) qui permet de décliner leur fonctionnement global et leurs performances en une batterie de tableaux de bord pertinents. Nous présenterons dans ce chapitre les différents aspects des systèmes d’information décisionnels. Ainsi qu’une comparaison entre la modélisation relationnelle et la modélisation dimensionnelle. 1.1 Théorie de la BI 1.1.1 Définition de la BI L’informatique décisionnelle, dite Business Intelligence (BI) , est un module permettant de collecter, d’analyser et de traiter toutes les données d’une entreprise selon des critères tels que le type de produit, la région ou la saison. Les résultats vont notamment permettre aux dirigeants d’obtenir une vue d’ensemble sur leurs activités, une meilleure compréhension du comportement client et une meilleure réactivité face au marché . Le processus de la BI peut se schématiser de la manière suivante. 3 Figure 1.1 – Pyramide modélisant le processus de la BI[2] Le chemin informationnel peut aussi être modélisé conformément au schéma de la figure 1.2. Il s’agit du cheminement depuis les données brutes provenant des systèmes d’informations sources (ERP, CRM...), jusqu’à la production de reportings et d’autres tableaux de bord. Figure 1.2 – Flux informationnel lié au processus BI[2] 1.1.2 Le data warehouse Un data warehouse ou entrepôt de données est utilisé pour collecter et stocker de manière définitive des informations provenant d’autres bases de données. Selon Bill Inmon, « Le data warehouse est une collection de données orientées sujet, intégrées, non volatiles, historisées, résumées, organisées pour le support d’un processus d’aide à la décision. »[3]. 4 D’après Ralph Kimball, le data warehouse peut être représenté comme le montre la figure 1.3 suivante : Figure 1.3 – le data warehouse d’après Ralph Kimball 1.1.3 Le data mart Nous retrouvons dans la littérature plusieurs définitions. Nous allons étudier deux des plus importantes : D’après Inmon : « Le data mart est issu d’un flux de données provenant du data warehouse. Contrairement à ce dernier qui présente le détail des données pour toute l’entreprise, il a vocation à présenter la donnée de manière spécialisée, agrégée et regroupée fonctionnellement. » Selon Kimball : « Le data mart est un sous-ensemble du data warehouse, constitué de tables au niveau détaillé et à des niveaux plus agrégés, permettant de restituer tout le spectre d’une activité métier. L’ensemble du data mart de l’entreprise constitue le data warehouse. » Un data mart est donc un sous ensemble du data warehouse qui permet de restituer l’information liée à un métier. Un data warehouse est constitué de plusieurs data marts. Nous traduisons data mart par magasin de données (mise à disposition de l’information classifiée, comme un magasin met à disposition des marchandises par rayon). La figure 1.4 ci-dessous offre une visibilité sur les différents flux de l’entrepôt de données (data warehouse) . Nous définirons tous ces composants afin de comprendre le principe global. 5 Figure 1.4 – les différents flux de l’entrepôt de données[5] 1.2 Bases de données relationnelles Les bases de données représentent aujourd’hui une part essentielle de la majorité des systèmes d’informations. Elles resolvent toute en résolvant d’une manière puissante et efficace le stockage de données complexes et nombreuses. 1.2.1 La Modélisation relationnelle La modélisation relationnelle sert à définir des relations entre les entités ; ce qui se traduit par la schématisation de ces relations sous forme de tables à deux dimensions. 1.2.2 Le dimensionnel VS le relationnel Le tableau ci-dessous présente une comparaison entre la modélisation dimensionnelle ainsi que la modélisation relationnelle Le dimensionnel Le relationnel Ne respecte aucune forme des 3 formes normales Respecte les 3 formes normales Les mêmes données peuvent être présentés plusieurs fois Ne supporte pas la redondance de données Langage de requêtage : MDX Langage de requêtage : SQL Les données sont archivées (historisées) Les données sont mises-à-jour Bases archivées -> l’historique de l’activité Bases de production -> l’activité présente Orienté sujet Orienté processus Table 1.1 – Le dimensionnel VS le relationnel Au niveau de notre solution, nous allons utiliser la modélisation relationnelle, adoptée au niveau de la base de données du progiciel de gestion intégré Sage . 6 1.3 Tableau de bord et indicateurs 1.3.1 Définition d’un tableau de bord Plusieurs spécialistes en gestion, dont Claude ALAZARD, Sabine SEPARI et Abdelhamid EL GADI, ont proposé de nombreuses définitions de tableau de bord. Selon les deux premiers, « Un tableau de bord est un ensemble d’indicateurs organisés en système suivi par la même équipe ou le même responsable pour aider à décider, à coordonner, à contrôler les actions d’un service. Le tableau de bord est un instrument de communication et de décision qui permet au contrôleur de gestion d’attirer l’attention du responsable sur les points clés de sa gestion afin de l’améliorer [1]. Selon Abdelhamid EL GADI, « Le tableau de bord est constitué par un ensemble de renseignements judicieusement choisis (chiffres, ratios, graphiques), qui constituent la synthèse des documents de l’ensemble de l’exploitation et qui, par une présentation pratique, doivent permettre aux dirigeants, sans recherche ni perte de temps, de se faire une opinion exacte et précise de la situation de l’entité concernée »[4]. On peut conclure que le tableau de bord est un outil de pilotage et de gestion efficace pour le suivi de toutes les activités de l’entreprise. 1.3.2 Pourquoi un tableau de bord ? Un tableau de bord constitue un outil de synthèse et de visualisation indispensable pour suivre toutes les actions liées à l’activité de l’entreprise. C’est un outil très important pour l’aide à la décision qui remplit notamment les rôles suivants : Un tableau de bord doit servir à tirer la sonnette d’alarme au bon moment. Et pour cela, la mise en forme graphique aide indéniablement. C’est ensuite un moyen d’apprentissage, car le chef d’entreprise tire des conclusions sur les écarts constatés et les actions mises en place pour corriger le tir. Enfin, il permet également au chef d’entreprise de se projeter en avant et d’avoir ainsi des informations pour établir ses prévisions. 1.3.3 Un tableau de bord comment ? Pour être un outil de pilotage et de gestion efficace, un tableau de bord doit donner une image synthétique et compréhensible en un coup d’oeil de la situation de l’entreprise, d’un service, d’un projet. Pour cela, il doit être conçu selon deux principes : Il doit être constitué d’indicateurs clés de performances fiables et pertinents.. Il doit être lisible en un coup d’oeil. Par conséquent, le tableau de bord doit idéalement prendre au moins en partie la forme de tableaux, graphiques, camemberts, etc. Cette mise en forme graphique et pratique facilitera la lecture et permettra de tirer la sonnette d’alarme plus rapidement au besoin. 7 1.3.4 Comment Avoir un tableau de bord e ffi cace ? Pour qu’un tableau de bord soit efficace, il faut veiller à : y faire figurer uniquement les indicateurs essentiels et éviter de mettre trop d’informations, déterminer correctement le circuit de l’information qui sert à l’alimenter, le mettre à disposition des bonnes personnes. 1.3.5 Définition d’un indicateur Le dictionnaire de la qualité rédigé par Michel Périgord et Jean-Pierre Fournier (Afnor, 1993) définit l’indicateur comme « caractéristique choisi, estimé par des méthodes statistiques ou déterminé par le calcul, permettant d’identifier qualitativement ou quantitativement, une amélioration positive ou négative du comportement d’une variable qui lui est associée ». En effet, on distingue trois types d’indicateurs : Indicateurs clé de performance (KPI) : Les Indicateurs Clé de Performance (ICP), appelés le plus souvent KPI ( Key Performance Indicator ), sont des indicateurs d’aide à la décision dont le but est de générer des rapports détaillés sur l’évolution des facteurs clés de succès des activités d’une entreprise. Leur principale utilité consiste donc à évaluer les performances des actions qui ont été mises en place en fonction des objectifs définis . Les indicateurs de pilotage : Ils permettent de mesurer une situation ou un risque, de donner une alerte ou au contraire de signifier l’avancement correct du projet . Il peut s’agir selon le cas d’un indicateur de suivi ou d’un indicateur de résultat. Enfin les indicateurs dits « d’éclairage » : Afin d’éviter le cloisonnement entre les services ou les départements de l’entreprise, il est intéressant d’adjoindre aux indicateurs propres, des indicateurs en provenance d’autres services. Il s’agit alors d’indicateurs d’éclairages . 1.3.6 Caractéristiques d’un bon indicateur L’élément essentiel dans la mise en place d’un tableau de bord réside dans la recherche des indicateurs de performance qui la composent. Le tableau ci-dessous présente les principales caractéristiques d’un bon indicateur. Pertinence indicateurs arrimés à la gestion, cohérents à travers les divers paliers ou secteurs Qualité précision de la définition, mesure, paramètres, rigueur possible dans l’interprétation Convivialité facilité d’utilisation, visualisation, compréhension Faisabilité localisation, disponibilité, coût des données, responsabilité de les produire et fournir Table 1.2 – Caractéristiques d’un bon indicateur 8 1.3.7 Principales erreurs à éviter Le principal objectif en matière de tableaux de bord est de comprendre les principales mesures et de collaborer pour des décisions plus avisées. Voici les cinq pièges qui peuvent éloigner de cet objectif. Utiliser des mesures que personne ne comprend ; Encombrer le tableau de bord de graphiques inutiles et de gadgets inintelligibles ; Sous-estimer le temps ou les ressources nécessaires pour créer et tenir à jour le tableau de bord ; Utiliser des mesures sans rapport avec les objectifs ; Utiliser des diagrammes et graphiques inefficaces et mal conçus. 1.4 Conclusion Ce premier chapitre a permis de définir les éléments importants utilisés dans un projet BI. Tout d’abord, nous avons explicité le concept de la BI. Ensuite, nous avons défini toutes les notions connexes à un projet décisionnel. Enfin, nous avons explicité les notions d’indicateur et de tableau de bord. Dans le chapitre suivant, nous allons élaborer une étude de l’existant afin de concrétiser les besoins de la société Targa-consult. 9 Chapitre 2 Cadre du projet Introduction Dans ce chapitre, nous allons présenter d’abord l’organisme d’accueil Targa-consult , ensuite l’analyse approfondie de l’existant, les spécifications des besoins et puis une synthèse et des critiques. Enfin, nous allons présenter la méthodologie de réalisation adoptée ainsi que l’expression des besoins fonctionnels et non fonctionnels concernant notre projet. 2.1 Organisme d’accueil 2.1.1 Présentation Targa-consult est un cabinet de conseil spécialisé en intégration de systèmes. Grâce à ses équipes de consultants expérimentés, Targa-consult dispose d’une capacité de compréhension globale de l’ensemble des domaines du consulting "Métier", "Processus" et d’intégration de systèmes. Depuis 2012 Targa-consult tâche d’accélérer son développement en proposant ses services aussi bien aux marchés financiers (banques et assurances) comme à l’industrie et aux professionnels des télécommunications . 2.1.2 Activités de Targa-consult Les principales activités de Targa-consult sont organisées en quatre grandes unités : Stratégie : Targa-consult aide les entreprises à définir leurs objectifs et leurs plans d’action en proposant différents modes de gouvernances et des plans de transformation. Business Consulting : A travers ses plateformes intégrées, Targa-consult propose aux entreprises une meilleure organisation des plans d’actions et des processus pour améliorer les performances de leurs clients. Système d’intégration : Targa-consult offre aux entreprises la possibilité de couvrir tous les aspects de développement que ce soit pour les fonctions opérationnelles, décisionnelles et pilotage ou études (solutions bancaires, pilotage, études, data warehouse, intelligence artificielle). 10 IT consulting : L’objectif de Targa-consult est de proposer un niveau d’expertise avancé sur des problématiques purement techniques auxquelles les entreprises peuvent être confrontées soit dans leur fonctionnement quotidien soit lors de la mise en place de nouveaux systèmes ou progiciels. 2.2 Étude de l’existant La phase étude de l’existant est très importante avant le développement de chaque projet décisionnel. Elle permet d’appréhender le déroulement du processus depuis l’acquisition des données jusqu’à l’élaboration des rapports afin de proposer une solution adéquate aux besoins des utilisateurs. 2.2.1 Description du système existant Nous avons constaté que la plupart des sociétés qui utilisent Sage comme ERP font recours au département informatique en cas de besoin d’un rapport ou d’un tableau de bord. Ce recours est souvent pénalisant dans la mesure où l’information peut ne pas être communiquée au bon moment. A titre d’exemple, nous avons repris dans la figure ci-dessous le cas d’un processus d’une société de distribution des lubrifiants pour examiner le cheminement depuis le lancement de la demande jusqu’à l’obtention des rapports. Figure 2.1 – Diagramme d’activité modélisant l’édition des rapports Ce processus s’articule autour des quatre phases suivantes : Phase 1 : Contact du département informatique pour avoir un rapport selon les besoins ; Phase 2 : Accès au serveur et extraction des données nécessaires à partir de la base de données SQL server de l’ERP Sage ; Phase 3 : Élaboration des rapports et transfert ; Phase 4 : Réunion pour la prise de décisions. 2.3 Critique de l’existant Cette étude nous a permis d’identifier certains dysfonctionnements dans le processus d’élaboration des rapports. Nous en citons notamment : 11 Difficultés dans l’élaboration des rapports puisqu’ils sont générés à la demande. Forte dépendance du département informatique. Lenteur dans la procédure d’élaboration au vu du chemin que subissent les requêtes entre les différents intervenants des différents départements. Ces défauts constatés poussent inévitablement vers une solution qui permet à chaque département d’avoir ses propres rapports rapidement et automatiquement. 2.4 Contexte du projet et solution proposée Les problèmes et les difficultés étant passés en revue, nous allons par la suite opter pour une solution décisionnelle qui aura pour but de faire sortir la BI du département informatique aux départements métier. Cette solution décisionnelle consistera à permettre à toute entreprise utilisant Sage comme ERP de créer ses propres tableaux de bord en utilisant sa propre base de données Sage . Cette solution devra, par ailleurs, satisfaire les exigences suivantes : Visualisation claire et simplifiée de tous les indicateurs de performance. Facilité dans la création des rapports et de reportings. Réduction du nombre d’intervenants dans l’élaboration des rapports. Interface, intuitive et ergonomique. 2.5 Méthodologie de réalisation adoptée Un tableau de bord, rappelons-le, est un outil essentiel de management opérationnel, fonctionnel et stratégique. Pour la réalisation des différents tableaux de bord, nous sommes passés par les étapes suivantes : 1. Identification et délimitation des responsabilités Cette étape consiste à se renseigner sur les objectifs des utilisateurs finaux par le biais des réunions, des entretiens, des questionnaires ou d’autres approches. Par la suite on passe au choix des indicateurs. Vers la fin de cette étape on serait en mesure de déduire les objectifs quantitatifs et qualitatifs de l’organisation. 2. Implication des équipes dans la mise en oeuvre Identifier toutes les personnes concernées par le tableau de bord. 3. Formalisation des processus de traitement de l’information Une fois les deux précédentes étapes sont réalisées, on définit les objectifs mesurables pour chacun des indicateurs pertinents. On sélectionne ensuite les sources de données à utiliser afin d’effectuer les traitements nécessaires pour l’alimentation des différents tableaux de bord. 4. Mise en place et essai du tableau de bord (validation des résultats) C’est la pha...
Conception et Mise en Place d’une Solution Décisionnelle pour la BI avec Sage ERP
1/51
100%
Rendu du PDF...