• Aucun résultat trouvé

Partie I: Synthèse Bibliographique

Chapitre 2: L'éxistant décisionnel

II. Etat du décisionnel au sein du groupe

II.1 Niveau Groupe

A ce niveau de hiérarchie, les utilisateurs ont besoin de chiffres qui concernent l’ensemble du groupe, dans sa fonction de distribution. Ces rapports sont essentiellement livrés par la filiale « ELIT ». Les données étant consolidées à partir des bases de production des « DD » des quatre filiales de distribution. Cela suppose donc, la participation de différents acteurs dispersés sur l’ensemble du territoire national ainsi que sur l’ensemble des filiales distributions.

Dans le meilleur des cas, le rapport demandé concerne des données déjà consolidées et prêtes à l’utilisation. L’élaboration du rapport se fait donc sans grandes difficultés. Sinon, le procédé d’extraction et de consolidation est relancé. Le diagramme suivant donne une vision claire de la manière dont sont consolidées les données et les rapports élaborés en partant de la demande d’un état donné jusqu'à sa production :

Figure II.8 : Diagramme d’activité modélisant l’édition de rapport pour le niveau groupe.

À partir de ce diagramme on peut d’ores et déjà avoir une idée sur le nombre d’intervenants dans cette procédure qui reste une tâche très fastidieuse, surtout dans sa partie consolidation des données. Cette procédure se déroule comme suit:

Phase 1 : les utilisateurs de niveau groupe, principalement des analystes et des décideurs de la DGDS et de la maison mère, formulent leurs requêtes qui sont transmises au département « Systèmes d’information de la distribution » (SID) de la filiale « ELIT ».

Phase 2 : le département SID, en recevant une demande de la part des utilisateurs de niveau groupe, lance la procédure de consolidation des données à partir des différentes DD du groupe. Cette procédure doit faire l’objet d’une validation de la part du directeur études et développement. La demande est ensuite transmise au chef de CTI de chaque DD.

Phase 3 : Les chefs de CTI, en recevant la demande d’extraction, programment une tranche horaire et préparent les scripts d’extraction. L’étape d’extraction aboutit à la transmission de fichier texte vers le département SID.

Remarque : les fichiers, étant d’une taille assez volumineuse, peuvent atteindre une centaine de mégas voire plus. Ces dits fichiers subissent parfois des altérations durant le transfert ou deviennent carrément inutilisables. Dans ce cas les « D.D. » concernées sont recontactées pour une nouvelle extraction ou un nouvel envoi selon la nature du problème. Il arrive parfois, suite à des problèmes réseaux, de recourir au transfert des données sur support physique transportable (CD, clé USB).

Phase 4 : Une fois les données reçues en totalité, la consolidation se fait au niveau du département « SID » manuellement. Cette consolidation permet d’élaborer les rapports voulus.

Phase 5 : Le rapport est validé par le chef de département est et envoyé aux utilisateurs finaux.

Remarque : la procédure se répète généralement quatre fois par an, la consolidation des chiffres se faisant chaque trimestre. Mais cela n’empêche pas le lancement de cette procédure en cas de nécessité.

Sauf en cas de problèmes, toute échange d’information « demandes et fichiers joints » se fait par le biais de la messagerie interne du groupe.

II.2 Niveau Sociétés de Distribution

Pour le niveau « SD », la procédure se déroule exactement comme pour le niveau groupe. A cela près que « ELIT » n’intervient pas à ce niveau là. C’est alors aux ingénieurs de la structure concernée de prendre en charge la consolidation et l’élaboration des rapports. Les différences notées sont :

Emission de la demande : La demande est formulée par les analystes et décideurs des deux directions Commerciale Marketing « DCM » et Comptabilité et Finance « DCF ».

Extraction des données: l’extraction se fait toujours aux niveaux des DD affiliées à la SD. Dans la plupart du temps les données sont transférées directement sous forme de rapports10.

Consolidation des données : la consolidation se fait soit à partir des fichiers de données, soit en se basant sur les rapports transmis par les DD. Cette consolidation se fait toujours de façon manuelle et monopolise les ingénieurs et techniciens de SD.

Remarque : la procédure d’élaboration de rapports au niveau SD se fait généralement chaque fin de mois. Elle peut aussi être lancée en cas de nécessité.

10 Ces rapports obéissent à des canevas prédéfinis.

II.3 Niveau Directions de Distribution

Les consommateurs de rapports au niveau des DD utilisent des rapports livrés directement par leurs CTI. Ces rapports, basés exclusivement sur les données des systèmes transactionnels, sont élaborés et transmis à la demande des managers. Le schéma suivant montre la manière dont sont traitées les demandes de rapport au niveau DD.

La demande est transmise directement du manager vers le chef de CTI via la messagerie interne «lotus de l’entreprise ». Le chef de CTI charge son équipe technique de l’élaboration du rapport demandé qu’il contrôle avant sa transmission à qui de droit.

L’élaboration des rapports se fait à ce niveau soit par le bais du module

« Statistique11 » du SGC, Soit par des requêtes SQL. La présentation du rapport se fait alors selon le canevas demandé.

Remarque : Vu le nombre important de demandes et de sollicitations, certaines DD ont mis à la disposition des managers et des décideurs des systèmes qui fournissent des états statistiques à la demande. Cependant, ces systèmes, en interrogeant directement la base de données transactionnelle en production, offrent des services limités avec des temps de réponse non satisfaisants.

Cette mise en place de systèmes, ne fait qu’encourager le groupe à uniformiser les procédures et méthodes de prise de décision.

11 Ce module a été développé pour fournir un certain nombre de rapports statistiques au niveau DD. Il interagit directement avec la base de données en production et pénalise souvent le système transactionnel.

III. Conclusion

Cette étude nous permet d’avoir une vision générale des procédures d’élaboration de rapports et de consolidation des données. Elle constitue aussi le point de départ pour définir le périmètre du projet en général et de l’étude des besoins en particulier. Elle fait ressortir les insuffisances du système actuel en soulignant les points faibles ou les goulots d’étranglements de ce dernier.

Le chapitre suivant consacré à l’étude des besoins, aidera à détecter ceux des utilisateurs de manière à pouvoir y répondre.

Chapitre III : Définition des besoins.

I. Introduction

Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs.

Cela ne peut, évidemment, se faire sans une étude

Ainsi, il existe deux démarches qui ont été décrites bibliographique, et qui sont: l'approche «

L'application exclusive de l

résultats satisfaisants. La démarche généralement adoptée est une démarche mixte, qui allie entre les deux précédentes dans un souci de prise en considération des besoins des décideurs sans perdre de vue toute possibilit

approche permet donc de recueillir, corriger et de modérer les attentes des utilisateurs dès le départ, tout en détectant d'éventuels besoins non exprimés.

Durant l’étude des besoins on ne peut se lim néanmoins, il faudrait absolument prendre en compte

données des systèmes sources« Les DBA sont les principaux experts sur les applications existantes susceptibles d'aliment

confronter aux réalités certains des thèmes qui surgissent lors des rencontres avec les utilisateurs finaux. » [Kimball, 96]

Figure II.9 : La place de l’étape d’étude des besoins dans un projet Data Warehouse.

Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs.

e sans une étude approfondie de leurs besoins.

Ainsi, il existe deux démarches qui ont été décrites lors de notre synthèse et qui sont: l'approche « Buttom Up » et l'approche « Top Down

e l'une de ces deux approches ne produit nullement des résultats satisfaisants. La démarche généralement adoptée est une démarche mixte, qui allie entre les deux précédentes dans un souci de prise en considération des besoins des décideurs sans perdre de vue toute possibilité et opportunité offerte par les données sources

approche permet donc de recueillir, corriger et de modérer les attentes des utilisateurs dès le départ, tout en détectant d'éventuels besoins non exprimés.

Durant l’étude des besoins on ne peut se limiter aux interviews avec les utilisateurs absolument prendre en compte l’avis des Administrateurs des bases de

Les DBA sont les principaux experts sur les applications existantes susceptibles d'alimenter l'entrepôt de données. Leurs interviews servent à confronter aux réalités certains des thèmes qui surgissent lors des rencontres avec les

[Kimball, 96]

La place de l’étape d’étude des besoins dans un projet Data Warehouse.

Tout Data Warehouse doit être en mesure de répondre aux attentes des utilisateurs.

notre synthèse Top Down ».

approches ne produit nullement des résultats satisfaisants. La démarche généralement adoptée est une démarche mixte, qui allie entre les deux précédentes dans un souci de prise en considération des besoins des décideurs par les données sources. Cette approche permet donc de recueillir, corriger et de modérer les attentes des utilisateurs dès le

iter aux interviews avec les utilisateurs, Administrateurs des bases de Les DBA sont les principaux experts sur les applications données. Leurs interviews servent à confronter aux réalités certains des thèmes qui surgissent lors des rencontres avec les

La place de l’étape d’étude des besoins dans un projet Data Warehouse.

Ce chapitre a pour principale vocation d’exposer et de décrire la démarche adoptée pour la détection des besoins ainsi que la présentation de la synthèse qui en sera faite.

I.1 Description de la démarche d'étude des besoins

Afin de faire une étude aussi complète que possible, nous avons choisi d'adopter une démarche qui nous a permis de combiner, d’une manière assez satisfaisante, entre l'approche

« Buttom Up » et l'approche « Top Down ».

Ainsi, notre démarche peut se résumer au travers des étapes suivantes:

• Étude préliminaire des systèmes sources et interviews sommaires avec les DBA,

• Détection des postes susceptibles d'être porteurs d'informations utiles,

• Planification, préparation et conduite des interviews:

• Utilisation d’autres moyens pour la détection des besoins,

• Rédaction et validation du recueil récapitulatif des besoins,

a. Étude préliminaire des systèmes sources et interviews sommaires avec les DBA Cette étude représente une étape de compréhension des systèmes opérationnels et de leur environnement. Elle a pour mérite de consolider les connaissances acquises durant l’étude de l’existant, ainsi que le jargon et le fonctionnement de l’entreprise. En outre, cette étape permet de détecter, de manière succincte, les postes susceptibles d’interagir avec le Data Warehouse.

Elle est de ce fait indispensable pour un bon recensement des besoins.

Outre les DBA, qui sont pour la plupart des chefs de CTI, les gestionnaires qui se trouvent au sein de l’Elit, et dont la fonction principale est de définir les règles de gestion des applications et de s’assurer du respect des procédures propres à la distribution, ont été une source d’information assez bénéfique, eu égard à leur connaissance des applications du SGC et de leur maîtrise du métier du groupe.

b. Détection des postes susceptibles d'être porteurs d'informations utiles

Vu le grand nombre d’employés activant au sein du groupe SONELGAZ, notamment dans la fonction de distribution, ainsi que la dispersion géographique des filiales, il nous a été, bien sûr, impossible de voir et d’interviewer toute cette population. Ainsi, notre étude s’est axée sur les utilisateurs SDA, SDC.

Cette étape nous a permis, donc, d’identifier, en premier lieu, les services qui peuvent être porteurs d’informations tangibles et qui représentent la population potentiellement utilisatrice du projet. Ces dits services sont classés selon leur appartenance aux différentes structures, indiqué dans le tableau suivant:

Structure Intitulé du poste Nombre total de postes Direction de distribution Directeur régional de distribution 58 (1 chef par DD)

Commercial 58 (1 chef par DD)

Division finance et comptabilité 58 (1 comptable par DD)

Administrateur 58 (1 administrateur par DD)

Société de distribution P.D.G de la SD 4

D.C.M 4

Directeur finance et comptabilité 4

Groupe P.D.G 1

Tableau II.3 : Tableau présentant la population à interviewer.

c. Planification, préparation et conduite des interviews

Avant de détailler cette étape, il est nécessaire de justifier notre choix de l’entretien « interviews » comme méthode de collecte des besoins.

Bien qu’il existe d’autres méthodes d’identification des besoins, les entretiens s’imposent comme étant la valeur sûre dans un tel projet. En effet, cette méthode a l’avantage d’être, plus ou moins, facilement planifiable et d’ouvrir le dialogue avec les interviewés, qui sont pour la plus part des décideurs et des analystes.

Dans le souci de conduire à bien cette étape, qui du reste est très critique et délicate, il est nécessaire de passer par différentes phases, à savoir :

1 La phase de planification

La planification se fait généralement plusieurs jours à l’avance. Elle nous permet de prendre les rendez-vous nécessaires et de prévenir les futurs interviewés de notre arrivée et du motif de cet entretien.

Cette phase, qui est un préalable indispensable, s’est avérée être une tâche très ardue. En effet, la nature organisationnelle et la dispersion des structures liées à la distribution ont posé des problèmes que nous évoquerons plus loin. Cependant ces mêmes facteurs nous ont

poussés à entreprendre ce genre de démarches dans un souci de bonne conduite du projet et afin de ne pas perdre de temps dans des allers et retours improductifs.

Aussi, nous avons essayé de planifier nos entretiens de manière à avoir une certaine alternance entre les interviews des potentiels utilisateurs et les entretiens avec les DBA et les gestionnaires de manière à combiner entre les besoins d’analyse et les potentialités des systèmes sources et de leurs données.

2 La phase de préparation

Une fois la planification de l’entretien terminée, sa préparation doit se faire de telle sorte à ce qu’il se déroule dans les meilleures conditions possibles.

La préparation se résume essentiellement en l’identification des questions à poser, des points à soulever et des thèmes à éviter afin de ne pas trop s’éparpiller.

Les questions à poser sont classées en deux catégories, selon le poste de la personne interviewée. Ainsi certaines questions sont destinées aux décideurs alors que d’autres sont destinées aux analystes.

3 La conduite des entretiens

Dernière phase de l’étape, la conduite des interviews représente la réalisation sur le terrain des phases précédentes. Le but escompté étant d’amener les interviewés, au travers de leurs réponse à nos questions, de présenter leur travail et la manière dont ils procèdent pour le faire.

L’identification des besoins se fera alors en détectant les métriques qu’ils utilisent et les informations sur lesquelles ils s’appuient pour la prise de décision.

d. Autres moyens utilisés pour la détection des besoins

Bien que les entretiens représentent une source importante d’informations et aident grandement à l’identification des besoins des utilisateurs, leur utilisation exclusive n’est pas conseillée dans la construction d’un entrepôt de données. Cela tient principalement au fait que les utilisateurs ne peuvent, même avec la meilleure volonté du monde, exprimer tous leurs besoins.

De ce fait, il est fait appel à l’étude des rapports déjà demandés et des données disponibles a même de fournir des informations exploitables.

L’étude des rapports offre un certain apport à notre démarche d’études des besoins, dans la mesure où les utilisateurs peuvent ne pas mentionner des besoins qui leur paraissent évidents ou qui ne leur viennent pas à l’esprit durant nos interviews, ces derniers peuvent être, en effet, influencés par nos questions.

L’étude des données, quant à elle, sert à détecter des besoins non déclarés et qui peuvent se faire sentir ultérieurement, le but de cette démarche étant de construire un entrepôt de données capable de répondre à ces éventuels nouveaux besoins.

e. Rédaction et validation du recueil récapitulatif des besoins

L’étude des besoins nous a permis de recenser les besoins que nous avons classés par volets spécifiques. Ils peuvent être présentés de la manière suivante :

Volet Détecté Besoins enregistrés (Les critères d’analyse)

Suivi des ventes

Utilisateurs : Ce volet a été évoqué et solliciter à tous les niveaux et par différents postes. Cependant les utilisateurs des services Commerciaux et marketing, de la DCM et de la DFC ont exprimé un vif intérêt pour ce volet.

Besoins : Les utilisateurs ont besoin de connaître l’évolution des ventes et des consommations dans le temps et selon différents critères à savoir : (Zone géographique, type d’abonnement, secteur d’activité)

Suivi des abonnés

Utilisateurs : Services commerciaux, DCM, utilisateurs de la DGDS.

Besoins : ce volet contient les informations relatives à l’apport abonné (résiliations, nouveaux clients,…etc.), l’utilisateur devrait être en mesure de suivre l’évolution de ces chiffres selon différents critères d’analyse:

(Zone géographique, temps, type abonnement, activités).

Suivi des affaires

Utilisateurs : Services commerciaux, DCM.

Besoins : Avoir une vue d’ensemble de l’évolution des affaires et le suivi des taux et les délais de réalisations. L’utilisateur doit être en mesure de faire des analyses selon les critères : (Zone, Type de l’affaire, énergie, temps)

Suivi des recouvrements

Utilisateurs : Services commerciaux, DCM, DFC.

Besoins :Disposer de la possibilité d’analyse par rapport à des axes bien déterminés, qui sont :(Zone, Type d’abonnée, client, énergie, temps)

Tableau II.4 : Synthétisation des besoins recensés.

I.2 Problèmes et obstacles rencontrés

Bien que notre étude des besoins ait donné lieu aux résultats escomptés, à savoir leur identification et leur prise en charge, il n’empêche que le travail ne s’est pas effectué sans obstacles, dont les plus importants sont :

Difficulté de planifier les entretiens à cause de : - La charge de travail qui nous incombe, - L’emploi du temps chargé des interviewés,

- L’organisation du groupe par filiale a limité notre libre circulation au sein du groupe,

- Dispersion géographique des structures d’hébergement d’hébergent des services et les personnes à interviewer,

• L’indisponibilité de personnes concernées par les entretiens et les annulations de dernière minute,

• Les résistances au changement notamment au sein de quelques directions régionales,

• La rétention d’informations sous couvert de confidentialité,

• L’appréhension, par les utilisateurs, du projet et de sa faisabilité,

II. Conclusion

L’étude des besoins est une étape plus que nécessaire dans un projet Data Warehouse.

C’est, en effet, à partir de cette étude que se décidera la manière de construction de l’entrepôt de données et de son architecture.

Cette étude des besoins s’est déroulée sur vingt trois entretiens et a concerné quinze personnes occupant différents postes à des niveaux hiérarchiques différents. L’ensemble des entretiens a duré plus de 33 heures et nous ont permis tout d’abord d’appliquer les méthodes d’analyse et de collecte d’information. Il nous a permis de connaître d’avantage de détails sur les rouages de l’entreprise et d’identifier les besoins analytiques de l’entreprise.

Les besoins étant recensés, la construction du Data Warehouse peut alors commencer.

Cette construction fera l’objet du chapitre suivant.

Chapitre IV :

Conception de la solution

Conception de la zone d’entreposage

I. Introduction

Une fois les besoins des utilisateurs connus, volets de notre Data Warehouse. Pour cela,

dimensionnelle qui est souvent associée aux entrepôts de données avantages.

Cependant, avant de se lancer dans la modélisation, il est intéressant de classer les sujets recensés selon l’intérêt

réalisation. Ce classement nous aidera à choisir l’activité à modéliser en premier manière à garantir des résultats satisfaisant

II. Processus de la modélisation dimensionnelle

La conception d’un modèle dimensionnel passe par cinq étapes essentielles

• Choix de l’activité à modéliser une matrice dite d’analyse des

connaître quelle activité choisir en premier.

s’est fait en collaboration avec les décideurs et illustré dans la figure suivante

Figure II.10 : Analyse des priorités

• Définition de l’activité et de

• Définition des dimensions qui décrivent

• Définir les mesurables du fait,

• Définir les agrégats.

besoins des utilisateurs connus, nous pouvons commencer à concevoir les volets de notre Data Warehouse. Pour cela, nous avons eu recours à la modélisation dimensionnelle qui est souvent associée aux entrepôts de données compte tenu de ses

Cependant, avant de se lancer dans la modélisation, il est intéressant de classer les qu’ils représentent pour l’entreprise et les facilités de réalisation. Ce classement nous aidera à choisir l’activité à modéliser en premier

manière à garantir des résultats satisfaisants pour l’entreprise.

manière à garantir des résultats satisfaisants pour l’entreprise.