Rapport PFE

1 Contexte gnral
Projet de fin dtudes
Conception et dveloppement dune solution de reporting avanc et danalyse multidimensionnelle afin dtendre les capacits de loutil JIRA au sein de lentit GID
Ralis par LOUTFI Ismail TAOUR Marouane Membres de Jury Mr. DAHCHOUR Mohamed (Prsident) Mr. ZAOUIA Abdellah (Encadrant interne) Mr. AIRROUTCHE Imade (Ecandrant externe)
ANNEE UNIVERSITAIRE: 2010-11
2 Contexte gnral
Agir dabord, rectifier ensuite sil y a lieu, reprendre tout zro sil le faut, mais ne jamais rester inactif la recherche du parfait .
Jean Cocteau 1
Pote, graphiste, dessinateur, dramaturge et cinaste franais (1889-1963)
3 Contexte gnral
Remerciements
Au terme de ce travail, il nous est agrable de nous acquitter dune dette de reconnaissance auprs de toutes les personnes dont lintervention au cours de ce stage, a favoris son aboutissement. Nous tenons remercier M. JOUHAR Houcine le Directeur de lUnit Etudes et Solutions de nous avoir accord lopportunit de passer ce stage au sein de lentit GID. Nous tenons remercier tout particulirement et tmoigner toute notre reconnaissance aux personnes suivantes, pour lexprience enrichissante et pleine dintrt quelles nous ont fait vivre tout au long de la priode du stage ainsi que pour leur disponibilit, conseils et suivi: Notre encadrant au sein de la Trsorerie Gnrale du Royaume M. AIRROUCHTE Imade ainsi que nos encadrants au sein de lINPT Messieurs DAHCHOUR Mohamed et ZAOUIA Abdellah. Nous tenons galement prsenter nos profonds respects et
reconnaissance M. TIJANI Nadir Directeur du Centre dassistance de lentit GID, et lensemble des membres de lquipe GID pour leurs disponibilit et qualits humaines. Par la mme occasion, Nous en profitons pour exprimer nos vifs remerciements tous ceux qui ont contribu de prs ou de loin au bon droulement de ce travail
4 Contexte gnral
Rsum
Les tableaux de bord constituent aujourdhui un outil incontournable de la stratgie dentreprise et des systmes daide la dcision. Les tableaux de bord sont en effet le composant cl d'un management de la performance maitris. La matrise de la conception des tableaux de bord de pilotage conditionne la russite de la mise en place d'une stratgie gagnante. Les tableaux de bord assistent les managers dans nimporte quel niveau de lorganisme, et fournissent la vue densemble dont les dcideurs ont besoin pour contrler ltat et les opportunits des affaires. Ils peuvent aussi supporter linteraction avec les donnes, comme la fouille dans les dtails profonds de ces derniers pour tirer linformation utile. Ce projet vise implmenter cet instrument dans le but de mesure de la performance et damlioration du processus de prise de dcision.
5 Contexte gnral
Abstract Dashboards are nowadays a main tool of corporate strategy and of Decision support systems. They are the key component of a monitored performance management. Well-designed business dashboards can provide a unique and powerful means to present and monitor business information and can help managers elaborate a winning strategy. Dashboards support managers at any level in an organization, and provide the quick overview that decision makers need to monitor the health and opportunities of the business. They can also support interactions with the data, such as drilling down into the underlying details. This project aims at designing and implementing this instrument with the aim of measuring performance and improving decision making.
Zusammenfassung Armaturenbretter sind derzeit ein Hauptwerkzeug fr strategisches Management und fr Entscheidungsuntersttzungsysteme. Sie sind ein Schlsselsbestandteil eines berwachten Leistungsmanagements. Gute aufgebaute Geschftsarmaturenbretter knnten eindeutige und auch starke Mittel um die Geschftswissen zu vorstellen und zu kontrollieren. Armaturenbretter untersttzen Managers auf allen Ebenen, und besorgen ihnen die schnelle bersicht die die Entscheidungstrger brauchen um die Gesundheit und die Gelegenheiten ihres Geschfts zu berwachen. Die Armaturenbretter knnen auch die Wirkung mit den Daten untersttzen, wie zum Beispiel die Untersuchung von Einzelteilen um die ntzliche Information zu bekommen. Dieses Projekt zielt die Entwerfung und die Ausfhrung dieses Instrument mit dem Zweck, die Leistung zu messen und der Entscheidungsprozess zu verbessern.
6 Contexte gnral
Sommaire
Contexte gnral ...................................................................................................................................... 8 Mthodologie de travail......................................................................................................................... 15 Phase didentification ............................................................................................................................ 25 Phase de conception .............................................................................................................................. 33 Mise en uvre ....................................................................................................................................... 51 Amlioration permanente ...................................................................................................................... 71 Conclusion ............................................................................................................................................. 72 Rfrences ............................................................................................................................................. 77 Charte de projet ..................................................................................................................................... 79
7 Contexte gnral
Chapitre I Contexte gnral
8 Contexte gnral
I.
Contexte gnral
Le projet dcisionnel
Informatique dcisionnelle (Business Intelligence) L'informatique dcisionnelle dsigne l'ensemble des outils informatiques et des diffrentes technologies utilises dans le but de permettre aux organisations de faire un meilleure usage de leur flot de donnes, en facilitant l'accs l'information et l'analyse de celle-ci, offrant ainsi une aide prcieuse pour la prise de dcisions. L'informatique dcisionnelle joue un rle de premier plan dans les entreprises d'envergure, particulirement dans les dpartements de la finance. L'informatique dcisionnelle permet notamment le stockage des donnes, en conservant leur aspect temporel, permettant ainsi de faire tat de la progression de l'entreprise et de l'atteinte des objectifs fixs. L'informatique dcisionnelle permet galement de faire des prvisions en se basant sur les donnes passes. Un outil de Business Intelligence aide par exemple au contrle de gestion, l'analyse des performances commerciales, aux fonctions marketing, l'laboration de plans d'approvisionnement (ou de production), la gestion des ressources humaines. De nombreuses volutions ont eu lieu. Par exemple, celle des progiciels de Gestion Intgre, permettant l'obtention d'un systme d'informations homogne pour l'ensemble de l'entreprise. Avec l'augmentation du nombre d'informations, l'apparition d'infrastructures plus importantes et performantes a t ncessaire (Data Warehouse, Data mining, OLAP,). Le march de l'informatique dcisionnelle reste en croissance rgulire et offre une belle visibilit grce aux progrs technologiques continus, aux nouvelles architectures informatiques (Internet, client-serveur, SOA), la mise en place de nouveaux logiciels et aux nouvelles stratgies d'entreprise (fusion/acquisitions, gestion client). Le reporting est probablement l'application la plus utilise encore aujourd'hui de linformatique dcisionnelle, il permet aux gestionnaires :

de slectionner des donnes relatives telle priode, telle production, tel secteur de clientle, etc., de trier, regrouper ou rpartir ces donnes selon les critres de leur choix, de raliser divers calculs (totaux, moyennes, carts, comparatif d'une priode l'autre, ...), de prsenter les rsultats dune manire synthtique ou dtaille, le plus souvent graphique selon leurs besoins ou les attentes des dirigeants de lentreprise.
Le Projet dcisionnel Dans une entreprise, le volume de donnes traites crot rapidement avec le temps. Ces donnes peuvent provenir, des fournisseurs, des clients, de lenvironnement etc. Cette quantit de donnes augmente en fonction du secteur et de l'activit de lentreprise. Par exemple, dans
9 Contexte gnral
la grande distribution, les quantits de donnes collectes chaque jour sont normes (notamment lorsque les magasins collectent les tickets des caisses). L'entreprise dispose de plusieurs options pour traiter ce flux de donnes :

les donnes anciennes sont effaces et l'entreprise ne conserve que les donnes actives ou un historique rcent, les donnes sont stockes dans une base et l'entreprise n'envisage pas d'usage immdiat les donnes sont stockes au fur et mesure quelles arrivent de manire cohrente pour quelles soient exploitables directement.
Le projet dcisionnel correspond cette dernire option. Il sagit de traiter les donnes et de les stocker de manire cohrente au fur et mesure quelles se prsentent. Cest pour cela que le projet dcisionnel est un projet sans limite dans le temps. Pour mener bien ces projets dcisionnels, il existe une multitude d'outils, chacun tant plus ou moins adapt la taille de l'entreprise, la structure des donnes existantes et au type d'analyse dsir. Une chane de valeur dcisionnelle simplifie se prsente comme suit :

Des SGBD relationnels et d'autres systmes qui contiennent les donnes d'exploitation. Un ETL extrait les donnes pertinentes et les charge dans l'ODS du datawarehouse. Les donnes sont structures dans le datawarehouse. Des datamarts qui exploitent une technologie X-OLAP sont mis jour partir du datawarehouse. Des rapports sont gnrs sur ces donnes.
Le schma suivant rsume ces tapes
Figure 1: Chane de valeur dcisionelle
10 Contexte gnral
Le Reporting Le reporting est l'opration consistant, pour une entreprise, faire rapport de son activit. C'est la prsentation priodique de rapports et bilans analytiques sur les activits et rsultats d'une organisation, d'une unit de travail ou du responsable d'une fonction, destine en informer ceux chargs de les superviser en interne ou en externe, ou tout simplement concerns par ces activits ou rsultat Les outils de reporting proposent la ralisation de rapports selon un format prdtermin. Les bases de donnes sont interroges selon les requtes SQL prpares lors de l'laboration du modle. Le rapport peut ensuite tre diffus sur l'Intranet, priodiquement en automatique ou ponctuellement la demande. L'outil d'laboration du modle du rapport offre bien entendu des fonctions spcifiques de calcul et de prsentation (graphiques) afin de concevoir des comptes rendus particulirement seyants et pertinents.
1. Organisme daccueil : La Trsorerie gnrale du royaume

La Trsorerie Gnrale du Royaume constitue lune des administrations les plus importantes du Ministre des Finances et de la Privatisation et travers laquelle transite lensemble des flux financiers et comptables de lEtat et des collectivits locales. Elle est galement au centre dun maillage institutionnel constitu dadministrations publiques, dtablissements publics, de collectivits locales et dautres grandes institutions financires tous concerns par la gestion des deniers publics. La TGR a initi un grand projet de modernisation dont la vision stratgique est sous-tendue par deux objectifs fondamentaux savoir : - La contribution lamlioration substantielle de la gestion des finances publiques. - Lamlioration du service rendu aux clients et partenaires. Missions de la Trsorerie Gnrale du Royaume 1- Le recouvrement des crances publiques La TGR assure, par le biais de son vaste rseau de comptables publics, la perception des recettes fiscales et non fiscales, travers notamment : la gestion du contentieux administratif et judiciaire relatif au recouvrement et lassistance des percepteurs en la matire; la prise en charge des ordres de recettes au titre du budget gnral de lEtat, des budgets annexes et des comptes spciaux du Trsor; la centralisation des prises en charges et des recouvrements au titre des amendes et condamnations pcuniaires; la gestion des comptes de prts et davances accordes par le trsor et de fonds de roulement consentis par des organismes de financement des projets publics; llaboration des statistiques concernant la situation du recouvrement de crances publiques; 2- Le contrle et le paiement des dpenses publiques La TGR assure le contrle et le rglement des dpenses publiques. Ainsi, le rseau de la TGR est charg de contrler la rgularit des engagements de la quasi-totalit des dpenses de lEtat. Elle assure travers son rseau de comptables, le rglement desdites dpenses. En
11 Contexte gnral
effet, au vu des propositions dengagement et des ordres de paiement transmis par les ordonnateurs accrdits, les services de la TGR procdent au rglement des crances de lEtat. La Trsorerie Gnrale assure galement par le biais de la Paierie Principale des Rmunrations (PPR), le contrle et le traitement de la paie de prs 650.000 fonctionnaires. 3- La gestion des finances locales A travers son rseau de trsoriers et receveurs communaux, la TGR assure la gestion des budgets de 1659 collectivits locales, de 86 groupements et de 41 arrondissements, En effet, la TGR procde au recouvrement de leurs crances, au rglement des leurs dpenses et la paie de leur personnel. La TGR met contribution galement son expertise en offrant le conseil et lassistance ncessaires aux collectivits locales .Ce conseil qui est de nature juridique et financire, concerne, entre autres, la modernisation des procdures comptables, lanalyse financire et llaboration des tableaux de bord. 4- La gestion des dpts au Trsor La TGR assure la mission de gestion des dpts au Trsor. Elle participe travers cette activit au financement de la trsorerie de lEtat. A ce titre, elle gre les comptes des entreprises et tablissements publics qui sont soumis lobligation de dpt de leurs fonds au trsor. Cette activit est tendue galement la gestion des dpts dautres personnes morales ou prives. 5- La production de linformation financire et comptable La TGR assure la centralisation des oprations comptables de lEtat et des collectivits locales et de ce fait elle constitue une rfrence en matire de production et de valorisation de linformation comptable de lEtat et des collectivits locales. La production de linformation comptable permet ainsi de : dcrire prcisment les oprations budgtaires et financires. restituer rapidement une information fiable et indispensable la prise de dcision. prparer les documents relatifs la reddition des comptes. Organisation la TGR est organise comme suit : Direction de Rglementation et de la Normalisation Comptable. Direction du Pilotage des mtiers et de lAnimation du Rseau. Direction de lAppui et de la Gestion des Ressources. Centre National de Traitements. Entit charge du Projet de Gestion Intgre de la Dpense. Direction du Contrle et du Dveloppement. Division de lInspection.
Entit charge du Projet de Gestion Intgre de la Dpense Dans le cadre de la mise en uvre du Systme de Gestion Intgre de la Dpense (GID), une entit projet charge dudit systme a t cre au sein de la Trsorerie Gnrale du Royaume par dcision n 139/04/TGR du 15 octobre 2004. Cette structure a pour mission dassurer la ralisation et la mise en uvre du Systme GID, en le gnralisant lensemble des acteurs impliqus dans lexcution de la dpense publique.
12 Contexte gnral
Le systme GID (Gestion Intgre de Dpense) Dans le cadre des grandes rformes de modernisation et de promotion pour la bonne gouvernance, le projet GID se veut tre le vecteur promotionnel de la gestion rationnelle des dpenses publiques et ce grce une utilisation efficiente des nouvelles technologies de linformation et de la communication. Le systme GID (systme de Gestion Intgre de la Dpense) est un systme dinformation qui permet aux partenaires de la dpense de travailler sur un objectif commun structur en tches laide doutils de traitement et de communication. La mise en place du systme GID a permis loptimisation de la gestion de la dpense publique dans les meilleures conditions de fiabilit, clrit et efficacit. En effet, lenvironnement actuel se caractrise par des exigences de plus en plus accrues, en termes de qualit de service, de transparence, defficacit et defficience. Or, lexcution de la dpense publique qui reprsente un moyen important dexcution des politiques gouvernementales accuse une certaine lourdeur des contrles exercs, des interprtations disparates de certains concepts de la gestion de la dpense et la non gnralisation des systmes dvaluation de lefficacit de ses services. Par ailleurs, Il existe une certaine disparit au niveau de lutilisation des Technologies de lInformation et de la Communication qui supportent le mtier de la dpense et qui est essentiellement due un manque de coordination dans le dveloppement de certains systmes et leur faible niveau dintgration. Limpact sur le processus de la dpense se traduit par un allongement des cots et des dlais de ralisation de la commande publique, ainsi quau retard dans llaboration des comptes administratifs et des projets de Lois de Rglement. Et par consquent, il est difficile davoir une vision globale de lexcution du budget. Par ailleurs, des ressources importantes sont mobilises pour la gestion de la dpense au dtriment des vrais mtiers de chacun des dpartements ministriels, tout en favorisant la multiplication des cots dacquisition et de maintenance des systmes et des quipements informatiques relatifs la gestion de la dpense. Ds lors, il est ncessaire de concevoir et de mettre en uvre un systme dinformation budgtaire et comptable unifi et commun lensemble des acteurs, visant la rationalisation et loptimisation de la gestion publique, travers notamment une utilisation avise des nouvelles technologies de linformation et de la communication. La finalit globale du systme GID consiste permettre aux intervenants dans le processus dexcution de la dpense de se doter dun outil performant de gestion qui rpond leurs besoins, tout en tant parfaitement intgr aux systmes de leurs partenaires, en vue de leur assurer la ralisation de leurs prrogatives dans les meilleures conditions de fiabilit et de clrit requises. Ainsi le systme GID devrait constituer terme : Un levier de modernisation de lAdministration. Un socle de mise en uvre des rformes budgtaires.
13 Contexte gnral
Un outil capable de fournir, en temps rel, linformation ncessaire aux prises de dcisions.
Le systme GID vise atteindre les objectifs suivants: Rduire les dlais de traitement des actes de la dpense. Optimiser les cots de traitement des actes. Disposer en temps rel de linformation budgtaire et comptable. Offrir un service de qualit aux acteurs de la dpense publique
Lenvergure et la complexit du projet exigent la mise en place dune quipe forte compose dexperts fonctionnels et techniques, mais dans le cadre dune organisation souple, capable dvoluer en fonction de la monte en charge du projet, en loccurrence les nombreux chantiers fonctionnels et techniques auxquels il donnera lieu. Lorganisation actuelle de lentit projet GID est comme suit: Mission Conduite du Changement Mission Expertises Mtiers
Unit Etudes et Dveloppement, qui englobe : Mission Etudes et Intgration des Solutions Informatiques Mission Infrastructures Technologiques
Unit Organisation et Support Partenaires Mission Support aux Partenaires Mission Organisation Planification et Contrle
14 Contexte gnral
Chapitre II Mthodologie du travail
15 Contexte gnral
II.
Mthodologie de travail
Ncessit dune dmarche de travail

Un projet professionnel ncessite une dmarche claire et bien structure. La dmarche est ncessaire pour : Organiser le travail. Assurer une traabilit au sein du projet. Identifier clairement les diffrentes phases. Mener le projet dans les bonnes pratiques. Choix de la dmarche Il existe plusieurs mthodes dexcution de projets tableau de bords, chaque dmarche est adapte une stratgie ou un ensemble de stratgies. En effet, le projet tableau de bord dpend fortement de la stratgie mise en place/souhaite et chaque dmarche implique une approche diffrente suivant cette stratgie. Une tude benchmarking simpose pour dterminer les avantages et les limites de chaque dmarche et son degr dadaptation notre projet. Etude Benchmarking Nous avons recens trois dmarches qui comptent parmi les plus utiliss pour les projets tableaux de bord. Elles sont : Dmarche du tableau de bord prospectif (Balanced Scoreband/BSC). Dmarche Skandia. Dmarche GIMSI.
Prsentation des dmarches La Balanced Scoreband (BSC) Lance en 1992 par Robert S. Kaplan et David Norton, cest une mthode visant mesurer les activits d'une entreprise en quatre perspectives principales : Apprentissage, processus, clients et finances. Au pralable, la vision, les valeurs et la mission de l'entit doivent tre explicites, en vue de donner aux managers une comprhension globale de leur organisation. L'lment nouveau dterminant s'attache non seulement aux rsultats financiers, mais aussi aux questions humaines qui amnent ces rsultats, afin que les organisations se concentrent sur l'avenir et agissent dans leur meilleur intrt long terme. Le type de tableau de bord dcrit correspond un tableau de bord respectant le mode de management Balanced Scoreband (dit aussi tableau de bord prospectif ). Mettre au point un tableau de bord BSC inclut quatre processus :
16 Contexte gnral
1. 2. 3. 4.
Traduire la vision en objectifs oprationnels ; Communiquer la vision et la dcliner en performance individuelle ; Planification d'activit ; Feedback et apprentissage, puis ajustement de la stratgie en fonction.
Ces 4 processus correspondent aux 4 perspectives suivantes: Financire, Client, Processus Internes, Apprentissage et Organisationnel.

Perspective Financire - Quelle est la valeur cre pour les actionnaires ? Perspective Client - Quelle est la valeur cre pour les clients ? Perspective Processus Internes - Quelle est la performance des processus-cls de la russite ? Perspective Apprentissage Organisationnel - Quelle est notre capacit progresser ?
La Balanced Scoreband essaye de raliser les quilibres suivants:

Equilibre entre les objectifs court et moyen/long terme Equilibre entre les indicateurs financiers et non-financiers Equilibre entre les indicateurs mesure de la performance passe et les indicateurs "prospectifs" Equilibre entre la perception externe et la performance ralise interne
Navigateur Skandia Le navigateur Skandia (ou tableau de bord dit sudois ) place les comptences et les ressources humaines au centre des proccupations de lentreprise. Ce tableau de bord lavantage de pousser de manire flagrante lentreprise se remettre en question et sans cesse innover. De plus, il prend en compte des valeurs immatrielles indispensables la russite et la prennit de lentreprise. Enfin, il sintgre parfaitement dans le contexte conomique, social et environnemental actuel en perptuel mouvement et dans lequel la reconnaissance des salaris demeure plus que jamais primordial. La raison dtre de ce tableau de bord est quil se fonde sur une dimension socitale. Cela signifie que les rflexions des entreprises prennent en compte limpact de leurs activits sur lenvironnement social et environnemental. Les indicateurs propres ce tableau de bord reprennent une partie des indicateurs du BSC mais en intgre de nouveaux comme par exemple le temps consacr aux clients rapport au temps de prsence des collaborateurs. Dans cet exemple, la valeur des individus (client et collaborateur) est clairement prioritaire. Les biens immatriels mis en avant Les biens immatriels sont des actifs qui ne peuvent tre comptabiliss l'actif du bilan mais qui, pourtant, jouent un rle majeur dans la russite de l'entreprise. Ce peut tre par exemple la localisation de l'entreprise (est-elle proche d'infrastructures ou au beau milieu de la
17 Contexte gnral
campagne profonde). Pour comprendre comment le navigateur intgre ces lments, lanalyse des quatre axes du navigateur est indispensable: Laxe humain Occupant une place centrale, cela marque une volont de placer les relations, les comptences et les ressources humaines au centre des proccupations de lentreprise. Il prend en compte dune part le capital humain et dautre part le capital structurel. Le capital humain concerne principalement des rsultats denqutes internes comme la motivation du salari, la fiert dappartenance son entreprise, les sentiments des salaris face leur employeur etc. Cependant, le capital humain associe ses diffrents ratios dautres mesures comme le taux dabsentisme, le taux de formation, etc. plus gnriques. Le capital structurel, lui, mesure la capacit relationnelle de lentreprise en calculant trois facteurs :
Les relations avec les tiers de lentreprises (actionnaires, banques, fournisseurs, clients, salaris etc.). Cela peut se traduire par des taux de rencontre ou de partenariats par exemple. La capacit de lentreprise motiver ses collaborateurs Le dynamisme de lentreprise. Ici des indicateurs basiques comme le taux de croissance du CA, la mesure de la recherche et dveloppement, la pntration des nouveaux produits mais aussi des indicateurs axs autour de lhumain comme le taux dembauche et de dpart, la notorit, le taux de participations des salaris aux vnements de l'entreprise etc.
Laxe financier Laxe financier, le toit , reprsente le pass de lentreprise. Outre les ratios habituels, il met en avant des indicateurs orients sur la personne. Ce peut tre par exemple le cot de la relation client ou le bnfice par salari. Laxe client Ici, comme le Balanced Scoreband, laxe client met en avant des notions de fidlit, de potentiel de lentreprise conqurir de nouveaux clients ou encore un taux de rclamations ou de SAV. Laxe processus Le processus, ici, signifie linformatique. Cela comprend donc des mesures de taux de renouvellement du parc informatique, le taux de maintenance / panne des serveurs. Comme les autres axes, lhumain est au centre des mesures. On peut ainsi trouver des taux de formation loutil informatique, mesure des comptences des salaris etc.
18 Contexte gnral
Laxe innovation et dveloppement Comment lentreprise apprhende son march futur ? Les mesures de ce volet valuent lentreprise sur des ratios concernant les nouveaux besoins des clients, le nombre de nouveaux produits sortis, le taux de recherche et dveloppement etc. Dmarche GIMSI GIMSI est une mthode de conduite du projet de pilotage de la performance centre sur l'homme dcideur en situation, et dfinit un cadre mthodologique afin de mieux formaliser les conditions de russites des projets tableaux de bord. La mthode GIMSI recentre la question du projet tableaux de bord sur les 3 questions essentielles : Dynamiser la cration de valeurs dans une orientation transversale (dcoupage en processus et dmarche de progrs continu) Positionner les besoins de l'acteur en situation de dcision au cur du processus afin de considrer sa juste valeur la prise de risques inhrente aux nouveaux modes de fonctionnement des entreprises. Contribuer la destruction du mur existant encore entre les solutions technologiques oprationnelles et les attentes des utilisateurs.
Structure en 10 tapes, la mthode s'inscrit naturellement dans un mode de management moderne fond sur un principe de gouvernance gnralise privilgiant la prise de dcision rpartie. Multiplier les points de dcision, rapprocher le processus dcisionnel au plus prs du terrain, l o se situe l'information, l o l'action est possible, est en effet l'unique moyen de matriser la complexit croissante des organisations. Les dcideurs ne sont pas isols. La mthode GIMSI favorise la coopration entre les dcideurs, le partage de la connaissance et l'intgration performante des outils et techniques de la Business Intelligence. Etapes de la dmarche GIMSI La dmarche GIMSI est structure en 10 tapes bien identifies et regroupes en 4 phases thmatiques. Le tableau suivant reprsente les diffrentes phases et tapes de la dmarche
19 Contexte gnral
1. Identification Quel est le contexte? Ralit de l'environnement concurrentiel, forces et faiblesses de l'organisation, identification concrte des axes stratgiques et des points d'intervention
Etape 1 : Environnement de l'entreprise Analyse de l'environnement conomique et de la stratgie de l'entreprise afin de dfinir le primtre et la porte du projet Etape 2 : Identification de l'entreprise Analyse des structures de l'entreprise pour identifier les processus, activits et acteurs concerns.
2. Conception Que faut-il faire ? Une dmarche centre sur le dcideur de terrain en situation, point central du processus de dcision et par consquent du systme de pilotage de la performance
Etape 3 : Dfinition des objectifs Slection des objectifs tactiques de chaque quipe en fonction de la stratgie gnrale Etape 4 : Construction du tableau de bord Dfinition du tableau de bord de chaque quipe Etape 5 : Choix des indicateurs Choix des indicateurs en fonction des objectifs choisis, du contexte et des acteurs concerns Etape 6 : Collecte des informations Identification des informations ncessaires la construction des indicateurs Etape 7 : Le systme de tableau de bord Construction du systme de tableau de bord, contrle de la cohrence globale.
3. Mise en oeuvre Comment le faire ? La technologie est au service des utilisateurs de terrain
Etape 8 : Le choix des progiciels Elaboration de la grille de slection pour le choix des progiciels adquats Etape 9 : Intgration et dploiement Implantation des progiciels, dploiement l'entreprise. Etape 10 : Audit Suivi permanent du systme
4. Amlioration permanente Le systme correspond-il toujours aux attentes ?
20 Contexte gnral
Comparaison des dmarches et choix de la dmarche du projet Aprs ltude des trois mthodes, il serait possible de faire la comparaison suivante tenant en compte les principaux volets de chacune des stratgies: Mthode Volet stratgique Stratgie prdfinie Volet humain Volet financier Dirigiste: Manque Coteuse de participation du personnel Enqute sur le Pas de capital humain moyens financiers Domaine dapplication Stratgie dEntreprise Gestion dEntreprise
Balanced Scoreban d (BSC) Navigateu Prise en r Skandia considration des facteurs immatriels dans llaboration de la stratgie Sadapte toute Cooprative : GIMSI stratgie mise en Forte implication place du personnel
Peu de moyens financiers
Pilotage dentreprise/organism es
Grce cette tude benchmarking, nous constatons que la mthode GIMSI est celle la plus adapte notre projet. Cela est d plusieurs raisons: GIMSI sadapte la stratgie mise en place, ce qui est ncessaire pour notre projet. Le modle de management participatif adopt par GIMSI fait que le projet soit motivant. Les tableaux de bord GIMSI sont orients aux mtiers de pilotage, ce qui est en parfait accord avec la finalit de notre projet. Lutilisation de GIMSI est gratuite.
La mthode GIMSI permet en outre de : Raliser le projet dcisionnel dans sa totalit, de la conception la mise en action. Choisir les indicateurs de performance les mieux adapts chaque situation. Adopter une approche centre sur le dcideur. Fiabiliser les informations ds la collecte des donnes. Sintresser laspect dveloppement durable du systme.
1. Adaptation de la dmarche au contexte du projet Dans cette partie nous allons lister les diffrents tapes et tches de notre projet structurs selon la dmarche choisie, GIMSI.
21 Contexte gnral
Phase I : Identification Etape 1 : Environnement de lentreprise Dans cette premire tape il sagit didentifier les spcificits de lorganisme, son march , sa stratgie ainsi que le management pratiqu. Tches de ltape Dtermination de lorganisme concern. Organisation de lassistance Objectifs stratgiques. Mode de Management. Clients de lorganisme. Etape 2 : Identification des processus Il sagit dans cette tape de dtudier les mtiers spcifiques du centre dassistance, danalyser les diffrents interactions, ainsi que didentifier les processus critiques. Tches de ltape Cycles de vie fonctionnels Analyse de diffrentes interactions Workflows. Phase II : Conception Etape 3 : Choix des objectifs Cette partie sintresse la dmarche suivre pour slectionner les objectifs en parfait accord avec les finalits stratgiques. Tches de ltape Caractristiques dun objectif Collecte du besoin Formulation du besoin Etape 4 : Tableau de bord Caractristiques du tableau de bord. Etape 5 : Choix des indicateurs KPI Dans cette partie nous allons expliquer la mthode suivie pour bien choisir les indicateurs pertinents de mesure de la performance. Tches de ltape Caractristiques des KPI. Choix des KPI. Elaboration du cahier de charge et de la fiche du projet. Etape 6 : Collecte des informations Cette phase sintresse la collecte des informations dcisionnelles partir des donnes sources
22 Contexte gnral
Tches de ltape Modlisation multidimensionnelle. Schma multidimensionnel. Etude des donnes sources. Mapping. Table de faits : Algorithmes et calcul. Etape 7 : Systme du tableau de bord Cette tape sintresse au partage de la connaissance au sein de lquipe des dcideurs afin de faire une prise de dcision pleinement efficace. Tches de ltape Prise de la dcision en groupe Phase III : Mise en uvre Etape 8 : Choix de loutil dcisionnel Cette tape sintresse du choix de loutil dcisionnel utiliser, Dans le cas de notre projet, nous ne serons pas amens faire un choix de loutil, loutil tant impos par lentit GID. Loutil BI utilis est Pentaho BI Suite. Tches de ltape Gnralits sur les outils BI. Prsentation de loutil Pentaho. Etape 9 : Dploiement et Intgration Dans cette tape, nous allons exposer la mise en uvre technique de la solution, son dploiement, ainsi que son intgration au systme de reporting existant. Tches de ltape Alimentation du datawarehouse. Analyse de donnes Alimentation du tableau de bord. Intgration de la solution. Phase IV : Amlioration permanente Etape 10 : Audit du systme Planification du projet Llaboration dun planning nous permettra dorganiser notre projet dans le temps ainsi que de savoir le degr de liaison entre diffrentes tches. Le tableau ci-dessus rsume lorganisation des tches de notre projet.
23 Contexte gnral
N Tche tche 1 Documentation sur l'organisme d'accueil 2 Documentation mtier 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Documentation Business Intelligence Documentation Gestion de projet Etude benchmarking de la dmarche Etude de lenvironnement Etude des processus mtier Etude des enjeux et des objectifs Collecte du besoin Formulation du besoin Ngociation du tableau de bord Ngociation des KPI Formulation des KPI Etablissement du plan du projet Elaboration de la charte du projet Elaboration du cahier de charges Modlisation multidimensionnelle Etablissement du schma multidimensionnel Etude des donnes sources Mapping Conception de la table de faits Documentation sur l'outil BI Processus ETL Analyse OLAP Restitution des donnes Tests de la solution Intgration de la solution Rdaction du rapport de stage
Dure 2j 4j 5j 2j 6,79j 3j 3,14j 0,5j 2,36j 0,79j 3j 2,36j 0,64j 3j 4,57j 4,57j 3j 1j 8,36j 3j 3j 2j 7j 2,21j 2,21j 0,79j 0,79j 22j
Date dbut Mer 16/03/11 Lun 21/03/11 Lun 21/03/11 Lun 21/03/11 Mar 29/03/11 Lun 11/04/11 Lun 11/04/11 Ven 15/04/11 Lun 18/04/11 Jeu 21/04/11 Mar 19/04/11 Mar 19/04/11 Ven 22/04/11 Lun 25/04/11 Lun 25/04/11 Lun 25/04/11 Lun 02/05/11 Ven 06/05/11 Mar 10/05/11 Ven 13/05/11 Jeu 19/05/11 Lun 23/05/11 Mer 25/05/11 Mer 08/06/11 Lun 13/06/11 Mer 15/06/11 Jeu 16/06/11 Lun 09/05/11
Date fin Ven 18/03/11 Lun 28/03/11 Mar 29/03/11 Mer 23/03/11 Ven 08/04/11 Jeu 14/04/11 Jeu 14/04/11 Ven 15/04/11 Mer 20/04/11 Jeu 21/04/11 Ven 22/04/11 Jeu 21/04/11 Ven 22/04/11 Jeu 28/04/11 Lun 02/05/11 Lun 02/05/11 Jeu 05/05/11 Lun 09/05/11 Mar 24/05/11 Mer 18/05/11 Mar 24/05/11 Mer 25/05/11 Mar 07/06/11 Ven 10/06/11 Mer 15/06/11 Jeu 16/06/11 Ven 17/06/11 Ven 17/06/11
24 Contexte gnral
Chapitre III Phase didentification
25 Phase didentification
III.
Phase didentification
Etape 1 : Environnement de lentreprise

Dtermination de lorganisme concern Lorganisme pour lequel notre projet est destin est le centre dassistance au sein de lentit GID, il est charg du mtier dassistance aux utilisateurs (au sens ITIL) de ce systme. Dfinition de lassistance au sens ITIL : En informatique, les services d'assistance, ou support aux utilisateurs, correspondent aux activits de Service support (ITIL) du rfrentiel ITIL. Ils consistent aider les utilisateurs rsoudre un problme dans l'utilisation d'un logiciel. L'expression support technique (technical support) quelquefois employe met l'accent sur le fait que ces services s'appuient sur des outils techniques tels que le tlphone, le courrier lectronique, les logiciels de gestion des services d'assistance, ou le Web. Les services d'assistance sont raliss par des quipes rassembles dans un centre d'assistance, ou rparties sur plusieurs sites dans des cellules d'assistance, de taille plus rduite. Le centre dassistance est au niveau de la mission Planification, Organisation et Contrle. Organisation de lassistance Le service dassistance GID est organis selon 3 niveaux : 1er niveau: Personnes Ressources GID au niveau de chaque acteur. 2me niveau: 124 rfrents GID au niveau des trsoreries TM/TP. (Les rfrents GID sont ressources relevant des Trsoreries Ministrielles, Provinciales et Prfectorales. Les Rfrents GID sont chargs de promouvoir le systme GID au niveau des ordonnateurs). 3me niveau: Centre dassistance GID.
Procdure de la gestion des incidents La procdure dassistance respecte le schma suivant
Figure 2: Procdure d'assistance GID
Cest le premier niveau dassistance (PRGID) qui traite en premier les demandes dassistance, sil narrive pas les rsoudre ils seront transfrs au deuxime niveau (rfrents), sinon ils seront transfrs au troisime niveau (centre dassistance). Le troisime niveau est suppos capable de rsoudre tous les incidents puisque il dispose des ressources humaines et logistiques lui permettant de rsoudre tous types dincidents dans le systme. Objectifs stratgiques Ses objectifs stratgiques peuvent tre rsums dans trois grands objectifs: Enregistrer les incidents signals par les utilisateurs et suivre leur rsolution; Qualifier et consigner les amliorations fonctionnelles souhaites; Apporter les claircissements et explications ncessaires.
Mode de Management Lassistance GID est organis selon le rfrentiel ITIL Version 2, plus exactement le premier livre Soutien de services (Service support) qui dcrivant comment le service informatique assure le support son "client". Le Service support correspond l'activit d'assistance aux utilisateurs. Il comprend la description du centre dassistance ITIL ainsi que les cinq processus du mtier dassistance. 1. 2. 3. 4. 5. 6. Le centre de services (Service Desk) La gestion des incidents (Incident Management) La gestion des problmes (Problem Management) La gestion des changements (Change Management) La gestion des mises en production (Release Management) La gestion des configurations (Configuration Management)
Le processus concernant notre projet est le processus Gestion des incidents . La dfinition ITIL de l'objectif de la Gestion des Incidents est la suivante : Restaurer aussi vite que possible le fonctionnement normal des services et minimiser limpact ngatif sur les activits mtiers et sassurer ainsi que les meilleurs niveaux de qualit de service et de disponibilit sont maintenus.2 Le fonctionnement normal des services sentend ici comme le fonctionnement des services dans les limites des Contrats de Niveaux de Service (SLAs). Clients de lorganisme Les Clients externes du centre sont les rfrents GID. Les rfrents GID sont des ressources relevant des Trsoreries Ministrielles, Provinciales et Prfectorales, ils sont chargs de promouvoir le systme GID au niveau des ordonnateurs. Les ordonnateurs tant des acteurs de la dpense publique et par consquent des utilisateurs du systme GID. Il existe 124 rfrents au niveau du territoire national.
Etape 2: Identification des processus

Cycle de vie fonctionnel Le cycle de vie de l'incident est :

Dtection et enregistrement Classification et support initial Investigation Rsolution
Bibliothque ITIL V2
Clture
Des logiciels existent aujourd'hui qui permettent de faciliter cette gestion. Ils offrent des fonctions de prise d'appel, de suivi des appels, d'aide au diagnostic, de statistiques et de capitalisation des solutions. Ces logiciels sappellent Logiciels de gestion des services dassistance (Issue tracking systems). Le centre dassistance GID utilise le logiciel JIRA. JIRA est un systme de suivi de bugs, un systme de gestion des incidents, et un systme de gestion de projets dvelopp par Atlassian Software Systems. Il a remplac loutil OTRS au niveau de lentit GID. Il permet, entre autres, de signaler les anomalies et suivre leur rsolution ainsi que dassurer une traabilit de tous les changes. Atlassian propose JIRA gratuitement pour les projets open source et les organisations non commerciales ainsi quune rduction de 50% pour les licences universitaires. partir de la version 3.13, une licence personnelle gratuite est aussi disponible pour un usage noncommercial. Cette licence n'inclut pas le support de l'application par Atlassian, et est limite trois utilisateurs. En raison de sa licence gratuite pour les projets open source, plusieurs groupes de dveloppeurs ont adopt JIRA pour leurs projets comme JBoss, Spring Framework et OpenSymphony. Demandes dans JIRA Les demandes dassistance reus par le centre dassistance sont tous enregistres dans la base de donnes du systme JIRA. Etant les interlocuteurs directs du centre dassistance, les rfrents peuvent interagir avec le systme et crer des demandes dassistance, chaque demande suit une procdure de ralisation selon son type et son degr de complexit. Types de demandes: Incident(Bug) : Anomalie dans GID. Correction de donnes : Demande de correction de donnes, hors corrections traites par le module de correction de donnes. Demande dinformation : Demande dinformations quelconques par un utilisateur. Amlioration : Proposition de fonctionnalit intgrer dans GID. Tche : Demande relative au rfrentiel et la gestion des utilisateurs.
Analyse des diffrents interactions En ralit, le troisime niveau dassistance ne se limite pas au centre dassistance. Il y a dautres entits qui pourraient intervenir dans le processus de rsolution des incidents, dpendamment de la nature de lincident/demande.
Les acteurs de la rsolution des incidents sont regroups dans quatre quipes : Equipe Dploiement : Au niveau du centre dassistance, il qualifie lincident. Equipe Fonctionnelle : Traite les incidents transfrs par le centre dassistance. Equipe Technique : Compose de dveloppeurs, elle intervient pour la correction des incidents dans le code. Equipe Dploiement technique : Dploie les solutions labores par lquipe technique.
L'objectif de la gestion des incidents est la remise en service des applications, dans les dlais les plus courts, en minimisant limpact sur les utilisateurs. Le centre dassistance prend en charge toutes les demandes reues. Pour faire une demande au centre dassistance, le rfrent ouvre un ticket de la demande qui est reu par le centre dassistance par lintermdiaire du systme JIRA. Le centre dassistance et ouvre un projet dit projet REQ (ou projet assistance aux utilisateurs) pour la rsolution de la demande. Chaque projet REQ est identifi grce un code. Le centre dassistance nayant pas une vocation technique mais plutt mtier, il arrive quil ne soit pas capable de rsoudre certains demandes dassistance. Cest ici que les quipes fonctionnel et technique interviennent dans le processus. Une demande non rsolue par le centre dassistance est transfre lquipe fonctionnelle qui ouvre son tour un nouveau projet dit projet SGID (systme GID) concernant la demande, lquipe dploiement (qui dpend directement du centre dassistance) cre un lien entre ce projet SGID et le projet REQ correspondant, ce dernier reste ouvert jusqu' la rsolution de lincident. Lquipe technique se charge de la rsolution technique des incidents qui ncessitent une correction dans le code source du systme, lquipe dploiement technique dploie les solutions labores par lquipe technique.
Projet REQ
Projet SGID
Figure 3: Interaction REQ/GID Il est ncessaire de signaler que les diffrents projets sont organiss par files ; Une file est une composante bien dfinie dun projet dassistance et qui peut entrer dans la composition de plusieurs projets. Les files qui interviennent dans les projets dassistance sont :
Gestion des engagements. Suivi de lexcution. Gestion des ordonnancements. Gestion des rgies. Situations. Rfrentiel des acteurs GID. Module de correction des donnes. Environnement de formation. Scurit. Gestion des crdits. Gestion des comptes utilisateurs. Problmes de connexion. Clture dexercice et criture de fin danne. Reprise des anciennes dpenses. Gestion des oppositions. Rglement. Chargement des budgets. Gestion des certificats SSL. Recherche. Autres types dincidents. Cration de la dpense. Reporting.
Workflows Notre projet concerne deux workflows (processus de travail): Le workflow de traitement des demandes dassistance au sein de JIRA (workflow JIRA). Le workflow dune demande du point de vue axes du service (workflow axes du service).
En effet, le workflow JIRA reprsente lui seul les diffrentes interactions entre les rfrents et le centre dassistance ainsi que les tats dune demande, mais il ne reprsente pas les interactions au-del du centre dassistance. Cest pour a que le deuxime workflow est ncessaire. Workflow JIRA Le schma suivant reprsente le processus de traitement des demandes dans JIRA
Figure 4: Workflow JIRA
On constate que le rfrent peut : Lancer la demande. Fermer la demande. Rouvrir une demande traite (sil nest pas satisfait pas le traitement de la demande).
Workflow axes du service Le schma suivant, reprsentant le workflow des axes des services, reprsente les diffrentes interactions entre les axes de lassistance GID
Centre dassistance
Equipe fonctionnelle
Equipe Dploiement technique
Equipe Technique
Figure 5: Workflow axes de service
Chapitre IV Phase de conception
33 Phase de conception
IV.
Phase de conception
Etape 3 : Choix des objectifs

Caractristiques dun objectif : Les objectifs doivent tre choisis et non imposs, choisis directement par les dcideurs euxmmes sous forme de besoin exprim. Cest nous, matres duvres, de formaliser ces objectifs et les noncer sous forme dobjectifs directement ralisables. Selon la dmarche GIMSI, un bon objectif est un objectif : 1. 2. 3. 4. 5. 6. Mesurable : l'objectif s'exprime en fonction d'une unit de mesure Born : l'objectif est imprativement dfini dans une dimension de temps Raliste : la Mthode pour l'atteindre est tout fait plausible Accessible : les moyens sont disponibles, les risques limits Fdrateur : l'objectif recueille l'adhsion de la majorit Constructif : l'objectif contribue la dmarche de progrs
Dmarche de choix des objectifs Collecte du besoin (Business Requirements Definition) Ayant acquis le background ncessaire sur laspect mtier pendant les deux premires phases, nous pouvons entamer la collecte directe du besoin. Pour le faire, il faut faire des Interviews et des runions avec des acteurs cls du mtier Voir lannexe liste de runions pour consulter la liste des runions de collecte du besoin. La connaissance et l'interview des acteurs mtiers est un lment tout aussi important que ltude de lenvironnement. Afin de mener bien cette tche, il a faudra tout d'abord bien connatre l'organigramme de l'entreprise et savoir les rles de chacun au sein de lorganisme. Si on ne connat pas bien l'organigramme on pourrait se planter sur les bonnes questions poser aux bonnes personnes. En plus des besoins de chaque acteur, il faut absolument dtecter les enjeux de chaque acteur, cest ncessaire vu que a fournit une ide sur le degr dimplication et de fdration lobjectif de chacun. Formulation du besoin Le besoin exprim par le centre dassistance peut tre rsum en: Le besoin exprim par le centre dassistance concerne le temps de ractivit du centre vis-vis des demandes reues. En effet, le centre dassistance joue un rle fondamental dans la rsolution de tous genres de problmes rencontres par les utilisateurs du systme GID et doit rpondre le plutt possible aux demandes dassistance reues vu limportance cruciale du systme GID pour lexcution de la dpense publique et par consquent pour lconomie ainsi que pour la stabilit du pays.
Par consquent, un besoin de la mesure de la performance du centre dassistance simpose afin de piloter dune manire efficace lactivit du centre et de dtecter dventuels dysfonctionnements pour les amliorer par la suite. Lefficacit du service offert par le centre dassistance peut tre mesure sur deux aspects : Le temps de rponse du centre aux demandes (ou temps de ractivit du centre). La qualit des solutions offertes par le centre.
Notre projet sintresse au premier aspect : La ractivit du centre dassistance. Cest le sujet principal danalyse. Les workflows concernant la demande dassistance nous permet de savoir les actions lies chaque demande, le rle de chaque acteur au sein du processus ainsi que didentifier les diffrentes intersections/ identifications pour vider la redondance (cas dun workflow concernant plusieurs objectifs). Le tableau suivant rsume ces aspects : Thme danalyse Ractivit du centre dassistance Workflow Workflow JIRA. Workflow axes de service. Acteurs Centre dassistance, axe dploiement, axe fonctionnel, axe technique, rfrent.
Etape 4 : Construction du tableau de bord

Le tableau de bord est le moyen qui permet lutilisateur du systme dcisionnel dinteragir avec ce dernier, il reprsente les diffrents indicateurs ncessaires pour le pilotage de lactivit. Cette tape traite la construction un tableau de bord "passeur de sens" pour une assistance efficace la prise de dcision. Un tableau de bord GIMSI est un tableau de bord dit at a glance , cela veut dire quil doit offrir une ide sur la situation dun premier coup dil. De plus, le tableau de bord doit tre capable de rpondre ces trois questions : Quoi?: Que se passe-t-il? Pourquoi?: Pourquoi cela se passe-t-il ainsi? Comment?: Comment dnouer la situation afin de revenir un tat sous contrle?
Afin dassurer que ces aspects soient vrifis, nous avons opt pour un tableau de bord ayant les caractristiques suivantes: Facilement accessible et utilisable: Ne ncessitant aucun savoir informatique spcifique.
Interactif : Les rapports gnrs ne sont pas typiques, mais plutt construits directement par les utilisateurs grce une interface graphique facile utiliser. Accs distance : accs par interface web partir des terminaux des utilisateurs. Accs personnalis : accessible travers un compte pour chaque utilisateur. A doit daccs diffrents : Chaque utilisateur a accs aux donnes le concernant. Restitution: Reprsentation de rsultats sous forme de tableaux et de graphes de diffrents types.
Le schma suivant rsume les fonctions quun tableau de bord GIMSI doit remplir :
Figure 6: Fonctions du tableau de bord
Le succs de cette tape dpend largement de ltape suivante, celle du choix des indicateurs. Les dtails concernant la construction technique du tableau de bord se trouvent au niveau du chapitre suivant.
Etape 5 : Choix des indicateurs

Caractristiques des KPI La dfinition GIMSI dun KPI (Key Performance Indicator/ Indicateur cl de performance) est la suivante :
3
Alain Fernandez, Nouveaux tableaux de bord des managers, figure 3.25.
Une mesure ou un ensemble de mesures braques sur un aspect critique de la performance globale de lorganisation. 4 Pour en faciliter l'utilisation et mieux en cerner l'usage il est habituel de classer les indicateurs selon 3 catgories en relation avec le type d'information transmise et les attentes des dcideurs. Indicateurs d'alerte Ce type d'indicateur de type tout ou rien, signale un tat anormal du systme sous contrle ncessitant une action, immdiate ou non. Un franchissement de seuil critique par exemple entre dans cette catgorie d'indicateur. Indicateurs d'quilibration Ce type d'indicateur troitement li aux objectifs est un peu la boussole du dcideur. Il informe sur l'tat du systme sous contrle en relation avec les objectifs suivis. Seront-ils tenus ? Indicateurs d'anticipation Un bon tableau de bord est aussi un instrument de prospective. Un bon tableau de bord permet de voir un peu plus loin que le bout de son cran et d'envisager avec une meilleure assise la situation actuelle. Doit-on continuer avec le plan actuel ? Le rviser ?
Les KPI doivent : Directement choisis par le(s) dcideur(s), ou tirs directement des besoins exprims par ces derniers. Appartiennent ceux qui lutilisent : Pour que le tableau de bord remplisse bien ce rle de rducteur de risques, il est important que le dcideur ou le groupe de dcideurs aient foi dans les indicateurs prsents. Car c'est surtout en exploitant son intuition que l'on prend les meilleures dcisions. Les indicateurs seront choisis par les utilisateurs. En relation avec le champ daction du dcideur : Il ne peut exister sur un tableau de bord d'indicateurs importants, peut-tre au niveau de l'entreprise, mais inoprants au niveau local. Si le dcideur ou l'quipe ne dispose pas des moyens d'action ou ne se sent pas proccup par l'indicateur, il ne vaut mieux pas le placer sur le tableau de bord. Il ne fait qu'encombrer ce dernier. Donnent une image relle et claire de lexistant : remplir Pas trs nombreux : Les indicateurs sont ncessairement en nombre restreint. De 4 10 indicateurs sont en gnral bien suffisants pour assurer le pilotage d'une activit. Choix des KPI Nous avons choisi cinq KPI pour la mesure de la ractivit du centre dassistance, ils sont la fois des indicateurs dalerte (ils permettent dalerter le dcideur quand un retard ventuel), dquilibration (visent quilibrer la rpartition de travail sur diffrents trsoreries) et danticipation (puisquils permettent danticiper la quantit de travail partir de la performance dans le prsent) :
4
Les nouveaux tableaux de bord des managers Editions Organisation
Ractivit globale de la demande: Mesure le temps que prend une demande pour tre traite. Ractivit du projet REQ : Mesure le temps coul pour une demande ds sa rception (ouverture du projet REQ) jusqu' sa clture (fermeture du projet REQ). Cest le temps significatif pour un client extrieur du centre (le rfrent). Ractivit avant la cration du projet GID: Mesure le temps aprs ouverture du projet REQ et avant ouverture du projet GID. Ractivit projet GID: Mesure le temps que dure un projet GID Ractivit aprs la clture projet GID: Mesure le temps coul aprs la fermeture dun projet GID et la fermeture du projet REQ. Ces 5 KPIs seront nomms respectivement: Ractivit_global, Ractivit_REQ, Ractivit_avantGID, Ractivit_SGID, Ractivit_aprsGID. Ces KPIs seront calculs suivant des axes danalyse choisies et constitueront les mesures de la table de faits. Nous allons attaquer cet aspect dans la phase de la modlisation dimensionnelle. Elaboration de la charte du projet et du cahier de charges La charte du projet et la fiche du projet sont des documents ncessaires pour chaque projet, ces documents formalisent le besoin et responsabilisent le Matre duvre ainsi que le matre douvrage. La charte du projet est projet est un document qui dfinit et autorise formellement un projet. Son contenu permet denlever toute ambigut aux diffrents acteurs du projet. Ceux-ci peuvent avoir des points dintrt diffrents, notamment dans les entreprises ayant une structure matricielle projets-fonctions. Avec la charte, le projet est li lorganisation de lentreprise. Lun des buts de la charte, signe par les diffrentes parties, est de donner un directeur du projet nomm lautorit suffisante pour mener bout le projet. Le sponsor, initiateur interne du projet, est galement nomm ; il doit avoir une position approprie pour pouvoir donner des arbitrages. Le contenu de la charte peut dtailler les thmes suivants. Description du projet : nom, but et livrables, justification lie au contexte, primtre, voire retour sur investissement. Les projets doivent tre MALINS : utilisant des objectifs Mesurables par des indicateurs ; ayant des buts Atteignables ; Limits dans le temps et dans leurs primtres ; Intgrs la stratgie de lentreprise ou dun portefeuille de projets ; Nouveaux par rapport au ralis de lentreprise (sinon on parle de production) ; Spcifiques car lis une demande, un besoin, un march. Le cahier de charge est Un cahier des charges est un document contractuel dcrivant ce qui est attendu du matre d'uvre (MOE) par le matre d'ouvrage (MOA). Il s'agit donc d'un document dcrivant de la faon la plus prcise possible, avec un vocabulaire simple, les besoins auxquels le matre d'uvre doit rpondre. Dans la mesure o
seul le matre d'uvre est rellement comptent pour proposer une solution technique approprie, le cahier des charges doit prfrentiellement faire apparatre le besoin de manire fonctionnelle, indpendamment de toute solution technique, sauf prciser l'environnement technique dans lequel la solution demande doit s'insrer. Il s'agit ainsi d'un document permettant d'une part de garantir au matre d'ouvrage que les livrables seront conformes ce qui est crit, d'autre part d'viter que le matre d'ouvrage modifie son souhait au fur et mesure du projet et demande au matre d'uvre des nouvelles fonctionnalits non prvues initialement. Un cahier des charges doit galement contenir tous les lments permettant au matre d'uvre de juger de la taille du projet et de sa complexit afin d'tre en mesure de proposer une offre la plus adapte possible en termes de cot, de dlai, de ressources humaines et d'assurance qualit. Il s'agit ce titre d'un document de rfrence, permettant de lever toute ambigut sur ce qui tait attendu, ainsi qu'un outil de dialogue permettant au matre d'uvre d'interroger le matre d'ouvrage afin d'affiner sa comprhension de la demande. Un cahier des charges n'est pas pour autant ncessairement statique. Son contenu peut tout fait tre modifi au cours du projet, mme si dans l'idal tout devrait tre dfini ds le dbut, sur la base d'un avenant accept par les deux parties. La charte de notre projet ainsi que le cahier de charges se trouvent au niveau des annexes de ce rapport. Le cahier de charges suit le modle Volere .
Etape 6: Collecte des informations

Maintenant que le besoin est connu, il faut commencer par construire le cur de tout systme de reporting, le datawarehouse. Pour le faire il faut : Faire une analyse multidimensionnelle afin didentifier les diffrents dimensions et mesures dans le datawarehouse. Modliser le datawarehouse grce un schma de modlisation de datawarehouse (Datawarehousing). Etudier les sources de donnes qui vont alimenter le datawarehouse. Etablir un mapping entre les donnes sources et les champs du datawarehouse. Concevoir des algorithmes pour alimenter la table de faits. Modlisation multidimensionnelle La modlisation dimensionnelle structure les donnes d'une faon trs diffrente de la structure en 3FN (3me forme normale) frquemment utilise par les modlisateurs des systmes OLTP. La modlisation dimensionnelle produit ce qu'on appelle le modle dimensionnel.
Dfinitions Une dimension est un ensemble de donnes du mme type, permettant de structurer la base multidimensionnelle. Une dimension est parfois appele un axe. Temps, pays, produit sont des dimensions classiques. Un fait est une donne observable que l'on possde sur un sujet et que l'on veut tudier, selon divers axes d'analyse (les dimensions). Les faits , dans un datawarehouse sont normalement numriques, puisque d'ordre quantitatif. Une mesure est un hypercube, le plus souvent de type entier ou dcimal, structur par des dimensions. Dimensions et faits Une dimension correspond un axe danalyse de la problmatique du projet, elle est ncessairement un facteur dont dpend laspect que lobjectif du projet essaye de mesurer. A chaque dimension est attribue une table. Il existe autant de tables dimensions que de dimensions. Chaque table dimension contient les attributs de la dimension en question plus une cl primaire indpendante de ces attributs. Les tables de faits reprsentent des associations dont lexistence dune occurrence dpend de lexistence des occurrences correspondantes dans les tables dimensionnelles, cest-dire la table de fait contient lensemble des mesures correspondant aux informations de lactivit analyser. Mais rappelons que certaines tables de faits peuvent contenir aucun attribut et reprsentent que des liaisons entre tables dimensionnelles. Tous les lments qui pointent sur la table de faits sont lis une smantique exprimable par une phrase. Par consquent, la table de faits est la matrialisation dune association entre n entits. Les caractristiques dune table de faits sont : Une table de faits contient les valeurs numriques de ce quon dsire mesurer (mesures). Une table de fait contient les cls associes aux dimensions. Il sagit des cls trangres dans la table de faits; En gnral une table de fait contient un petit nombre de colonnes; Une table de fait contient plus denregistrements quune table de dimension; Les informations dans une table de fait sont caractrises par : Elles sont numriques et sont utiliss pour faire des oprations. Les donnes doivent tre additives ou semi-additives. Toutes les colonnes reprsentant les faits dans la table de fait doivent rfrer et avoir un lien direct aux cls de dimensions dans la mme table; Pour dtecter la/les table(s) de fait(s), il faudra se servir des lments recueillis lors de la phase prcdente, notamment les workflows et les objectifs. Il faudra donc pour chaque workflow se demander quels sont les lments dont on souhaite mesurer la magnitude (il faut rpondre la question : Qu'est-ce qu'on mesure ?). Les objets qui entrent en jeu dans lactivit reprsente par le workflow constituent eux les dimensions.
Dimensions retenues Les axes danalyse que nous allons insrer dans notre modle sont : Le temps. La file de projet. La trsorerie de laquelle la demande provient. Direction rgionale (DR) de laquelle la demande provient. Assign charg de la rsolution de la demande. La priorit de demande. Le type de demande (types JIRA).
Pour ces axes danalyse correspondent respectivement les dimensions suivantes : dim_date. dim_file. dim_Trsorerie. dim_DR. dim_Membre. dim_priorit. dim_type. dim_demandes.
Mesures retenues Les mesures retenues dans notre table de faits sont les KPI dj dfinis dans ltape prcdente : Ractivit_global. Ractivit_REQ. Ractivit_avantGID. Ractivit_aprsGID. Ractivit_SGID.
Schma multidimensionnel Schmas de modlisation Il existe trois schmas de modlisation largement utiliss pour modliser les datawarehouse. En termes Merise, ces schmas sont les MPD (Modle physique de donnes) de la base de donnes dcisionnelle (datawarehouse). Schma en toile (Star schema) : Arrangement de tables dans une base de donnes relationnelle. Au centre, on trouve la table de faits, dont les colonnes constituent les mesures du multidimensionnel. Les branches de l'toile qui rayonnent partir de la table de fait correspondent aux dimensions. Le modle conceptuel de donnes permet de retrouver cette forme en toile.
Schma en constellation (Constellation schema) : Cest un schma constitus de schmas en toiles ayant des dimensions en commun. Schma en flocons de neige (Snowflake schema) : Le schma en flocons de neige est une variante du schma en toile. Dans la thorie la diffrence rside dans la simple normalisation des tables de dimensions. Il est donc tout simplement question de mettre les attributs de chaque niveau hirarchique dans une table de dimension part.
Figure 7: Exemple dun schma en toile
Figure 8: Exemple dun schma en flocons de neige
Choix du schma de modlisation Nous avons choisi le schma de modlisation en toile pour les raisons suivantes : Cest un schma stable. Limite le nombre de jointures. Optimise les requtes des utilisateurs. Intgre facilement de nouvelles demandes des utilisateurs. Simple crer et intuitivement comprhensible par les utilisateurs finaux.
En termes Merise, le MPD est lui seul utilis pour modliser les datawarehouses.
Nous avons ralis les schmas de modlisation avec le logiciel PowerAMC.
Power AMC est un logiciel de modlisation. Il permet de modliser les traitements informatiques et leurs bases de donnes associes. Cr par SDP sous le nom AMC*Designor, rachet par Powersoft, ce logiciel est produit par Sybase depuis le rachat par cet diteur en 1995. Hors de France, la version internationale est commercialise par Sybase sous la marque PowerDesigner. PowerAMC supporte diffrents types de modles de bases de donnes. Le Modle Physique des Donnes (MPD) dcrit les structures de donnes telles quelles sont enregistres sur les supports physiques 5. Cest le modle final, et sa structure dpend troitement de lenvironnement matriel et logiciel dexploitation des bases de donnes. Voici le modle physique de notre datawarehouse (schma en toile).
Figure 9 : Modle en toile du Datawarehouse
Etude des donnes sources Nous avons constat que la base de donnes du systme de suivi des incidents JIRA contient la plupart des donnes ncessaires pour charger le datawarehouse. Pour les donnes restantes, tant invariables avec le temps, nous les avons stocks au niveau de fichiers Excel avant de les charger grce aux transformations. Base de donnes JIRA La base de donnes du systme JIRA contient toutes les donnes relevant dune action ralise dans le systme, JIRA stocke toutes les donnes relatives un projet ou une demande donne afin dassurer la traabilit des projets et pour documenter lactivit du service.
A. Flory, Bases de Donnes, conception et ralisation , Economica 1987.
Afin davoir une vue claire de la base de donnes JIRA, il faut absolument faire une modlisation de cette base. Nous avons cr un modle partiel de la base grce loutil MySQL Workbench. MySQL Workbench est un outil de conception visuelle des bases de donnes, il intgre le dveloppement SQL, ladministration et la conception et la cration des bases de donnes dans un seul environnement de dveloppement intgr pour les bases de donnes MySQL. Nous avons utilis MySQL Workbench version 5.2 Community Edition. La base de donnes JIRA est une base de donnes relationnelle gre par Oracle (Version 10g Express) ordonne selon 105 tables, nous avons retenu dans notre modle partiel 20 tables qui seront dutilit pour notre projet.
Figure 10: Modle partiel de la base de donnes de JIRA
Nous allons prsenter les tables les plus utiliss de la base de donnes JIRA: Table jiraissue La table la plus utilise de la base de donnes est la table jiraissue, elle contient les enregistrements de chaque incident trait, elle est lie plusieurs autres tables.
La cl primaire de la plupart des tables est un numro qui est invisible pour les utilisateurs. Le tableau ci-dessous reprsente les champs de la table jiraissue :
Colonne Id Pkey Project Reporter Assignee Issuetype Summary Description Environment Priority Resolution Issuestatus Created Updated Duedate Votes Timeoriginalestimate Timeestimate Timespent Workflow_id Security Fixfor Component
Description Cl primaire, interne la table et connue seulement lutilisateur charg du projet. Rapporteur de lincident Personne affecte la rsolution Type de la demande Rsum de la demande Description de la demande Environement de la solution Priorit de la demande Rsolution de la demande Statut actuel de la demande Cration de la demande Mise jour de la demande Date limite Votes JIRA Estimation initiale Estimation du temps Temps coul pour la rsolution Workflow Niveau de scurit Deprecated Deprecated
Cl trangre vers Project.id
Issuetype.id Priority.id Resolution.id Issuestatus.id Os_wfentry.id SchemeIssueSecurityLevels.i D -
Les champs timeoriginalestimate, timeestimate et surtout time_spent aurait t dune grande utilit pour notre projet et aurait facilit largement la tche dextraction des donnes sources, mais ce champ tant vide pour la plupart du projet. Nous devons rechercher les donnes temporelles dans dautres tables de la base de donnes JIRA. Autres tables communes Historique de modifications Les tables changegroup et changeitem stockent lhistorique des changements. Une entre indique une ensemble de changements dun ou de plusieurs champs qui ont eu lieu a mme moment. Le changement dans chaque champ individuel est dcrit dans changeitem, de plusieurs est dcrit dans changegroup. Donc la relation entre ces deux tables est une relation (1,n). La relation la table jiraissue est ralise travers changegroup.issueid. Work Log
La table worklog suit le temps de connexion dun compte un incident donn de chaque compte dun assign. La relation avec jiraissue est travers worklog.issueid. Attributs dun incident Les tables resolution, issuestatus, issuetype et priority fournissent le nom et les mtadonnes concernant les tats de rsolution, les statuts, les types et des priorits des demandes. Projets et catgories de projets Les tables project et projectcategory dcrivent les projets JIRA et leurs catgories. La table nodeassociation est une table non normalise contenant le lien entre les projets et les catgories de ces derniers. Composants de projet La table component dfinit les composants du projet, la table nodeassociation contient les liens entre les composants et les demandes. Membres de groupes La table membershipbase dfinit les membres de chaque groupe de JIRA. Liens Les tables issuelink et issuelinktype dcrivent les liens entre les diffrents demandes et incidents dans JIRA. Quant au contenu des tables de la base de donnes JIRA (ainsi que celui du datawarehouse localement hberg). Nous avons utilis lditeur de base de donnes Oracle SQL Developer pour le consulter. Nous avons utilis cet outil aussi pour crer le datawarehouse et le ventuellement le modifier, ainsi que des bases de donnes tests tout au long de notre travail
. Oracle SQL Developer est un EDI (Environnement de dveloppement intgr) pour faire du SQL sur les bases de donnes Oracle. Il est fourni gratuitement par Oracle; il utilise le Java Developement Kit. Oracle SQL Developer supporte les produits Oracle ainsi que des plugins qui permettent de se connecter des bases de donnes non Oracle. Oracle SQL Developer fonctionne avec IBM DB2, Microsoft Access, Microsoft SQL Server, MySQL, Sybase Adaptive Server, et les bases de donnes Teradata. La version utilise pour le projet est Oracle SQL Developer Version 2.1.1.64. Autres sources de donnes Les donnes suivantes ne se trouvent pas au niveau de la base de donnes JIRA :
Les directions rgionales et les trsoreries desquelles proviennent les demandes, ainsi que les types de ces trsoreries (sil sagit de trsoreries ministrielles ou prfectorales). Les rfrents qui ouvrent les demandes.
Ces donnes tant importants pour le pilotage de lactivit, il fallait les extraire dautres sources de donnes. Nous avons stock ces donnes disponibles sur dautres supports dans deux fichiers Excel : dr.xls et referent.xls. Mapping Lopration du mapping consiste faire la correspondance entre les donnes sources et les champs du datawarehouse afin de charger correctement ce dernier. Cest ltape prcdente (tude des donnes sources) qui nous permettra de mener bien cette tape Cette opration prsente des difficults vu que les donnes contenues dans des champs JIRA ne portent aucune valeur informationnelle pour lutilisateur, dans ce cas il faut pointer sur dautres tables contenant les donnes utiles. Cette opration se fait grce un composant look up. Les tables ci-dessous montrent le mapping pour les diffrents champs (les champs avec (p) sont les cls primaires des tables) : Table dim_demandes Champ datawarehouse Champ source Table source code_demande type_demande reporter_demande assigne_demande priorite_demande resolution_demande file_demande projet_demande_key date_resolution_deman de date_creation_demande status_demande no_demande_id (p) projet_demande code_demande_liee nom_demande_liee ID issuetype_ID Reporter Assignee Priority_ID Resolution_ID Source_node_i d Pkey Resolutiondate Created Issuestatus_ID Project_ID ID ID Jiraissue Jiraissue Jiraissue Jiraissue Jiraissue Jiraissue nodeassociatio n Jiraissue Jiraissue Jiraissue Jiraissue Jiraissue jiraissue jiraissue Table Look Up Issuetype Priority Resolution Dim_demand e Issuestatus Project linktype linktype Champ Look Up pname pname pname No_demande_i d pname pname ID source
Table dim_type Champ datawarehouse No_type_id(p) Code_type Type_demande Table dim_membre Champ datawarehouse No_membre_id(p) Code_membre Nom_membre Table dim_priorite Champ datawarehouse No_priorite_id(p) Priorite Code_priorite Champ source Pname Sequence Priority Priority Table source Champ source ID User_name Table source Membershipbase Membershipbase Champ source Table source ID Issuetype Pname Issuetype
Table dim_file Champ datawarehouse Code_file Nom_file No_file_id(p) Code_projet Table dim_DR Champ datawarehouse Code_dr Nom_dr No_dr_id(p) Champ source Code DR Table source DR.xls DR.xls Champ source ID Cname Project Table source Component Component Component
Table dim_referent Champ datawarehouse Champ source Table source Referent.xls Referent.xls Referent.xls Referent.xls Referent.xls Referent.xls Champ Look Up Code Table Look Up DR.xls -
Code_referent/tresorerie Code Nom_referent Rapporteur JIRA Tresorerie_referent Trsorerie No_referent_id (p) Type_tresorerie_referent DR/TM No_dr_id Code Jiradb_nom_referent Nom Rfrent jiradb
Pour la table dim_date, la structure de que nous avons adopt pour cette table est celle adopte par lentit GID. Une procdure SQL interne lentit GID permet lalimentation de la table dim_date. Table de faits : Algorithme et calcul La table de faits contient, ct des cls trangres la liant aux tables de dimensions, les mesures. Les mesures sont calculables partir des dimensions et de leurs attributs, grce des programmes. Nous allons prsenter les algorithmes permettant le calcul de chacune des dimensions : Ractivit_global: Cest la diffrence temporelle entre la date de rsolution de la demande et la date de cration de la demande. Ractivit_REQ: Il y a deux cas ; Cas ou le projet REQ nest pas li un projet SGID : Cest la diffrence entre la date de rsolution de la demande et la date de cration de la demande pour les projets REQ non lis un projet SGID. Cas ou le projet REQ est li un projet SGID : Cest la diffrence entre la date de rsolution de la demande et la date de cration de la demande pour les projets REQ, en tranchant le temps consomm par le projet SGID.
Ractivit_avantGID: Cest la diffrence temporelle entre la date de cration du projet SGID et la date de cration de la demande. Ractivit_aprsGID: Cest la diffrence temporelle entre la date de rsolution de la demande et la date de rsolution du projet SGID. Ractivit_SGID :Cest la diffrence temporelle entre la date de rsolution du projet SGID et sa date de cration.
Il faut prendre en considration les contraintes danomalies de workflow lors de llaboration des programmes de calcul des mesures (comme par exemple la fermeture du projet REQ avant le projet SGID correspondant).
Etape 7 : Systme du tableau de bord

La dmarche GIMSI donne une grande importance au partage de la connaissance et combattre lisolement du dcideur. Le processus de prise de la dcision doit rpondre au principe de lintelligence collective et doit impliquer tous les acteurs pour quils soient motivs et par consquent sinvestissent dans la ralisation des objectifs souhaits. Pour un partage de la connaissance et une prise de dcision dcentralise, nous avons eu lide de crer des tableaux de bord destins au personnel de la TGR participant dans le processus de rsolution des incidents. Ces tableaux seront aussi aliments par le datawarehouse conu, mais les donnes restitues chaque membre de lquipe seront les donnes qui concernent les tches au niveau desquelles il a intervenu, et naura pas accs aux donnes concernant ses collgues. Des schmas et des cubes seront crs spcifiquement pour usage personnel de chaque membre. Cette opration permet chaque membre de contrler sa performance et de lamliorer par la suite ainsi que bien rpartir son travail ainsi que partager implicitement la connaissance des problmes et la conscience dventuels retards. Cela permettra aux membres de bien apprcier les problmes rencontrs, de participer la prise de la dcision ainsi que de sinvestir dans dventuels plans dajustement.
Chapitre V Mise en uvre
51 Mise en uvre
V.
Mise en uvre
Etape 8 : Choix de loutil dcisionnel

Cette tape sintresse du choix de loutil dcisionnel utiliser. Cette tape est dimportance capitale vu que le march de la Business Intelligence est en pleine effervescence et que beaucoup doutils sont disponibles sur le march. Ce dynamisme est d'autant plus vrai pour les outils logiciels dcisionnels de tableaux de bord. Dans tous les cas, la technologie de la Business Intelligence, dans sa dclinaison Informatique Dcisionnelle, est tout fait oprationnelle. La mise en uvre d'un vritable outil d'assistance la dcision est actuellement plutt une question de mthode que de puissance des progiciels dcisionnels proposs par le march. Ce propos est aussi vrai pour les produits propritaires de Business Intelligence que pour la BI en Open Source la croissance pour le moins fulgurante. Pour autant, il sera judicieux de profiter du choix propos par le march pour slectionner l'outil le plus adquat aux besoins exprims, dsormais connus grce aux tapes pralables du droulement du projet, et d'anticiper sur les besoins court et moyen terme. Le choix de loutil dcisionnel doit prendre en considration : La qualit gestion des donnes. Lergonomie d'utilisation. La facilit de dveloppement. La capacit de dploiement. La scurit.
En ce qui concerne notre solution, elle doit remplir plusieurs objectifs, parmi lesquelles nous citons: Le filtrage et la transformation des informations contenues dans la Base de donnes du systme GID (notamment celle de JIRA), pour ne conserver que celles qui nous seront utiles par la suite. Lalimentation du datawarehouse par ces informations qui nous seront utiles. Cration et dfinition dun ensemble de cubes, dimensions et hirarchies. Une interface, via laquelle on peut interroger les cubes cre, y extraire les informations voulues et les afficher, selon le besoin, sous plusieurs formats possibles (diagrammes, tableaux croiss). Le Pentaho BI Suite est lune des offres logicielles les plus compltes pour la ralisation de projet BI. Nous allons consacrer cette partie la prsentation de cet outil choisi par lquipe GID pour la ralisation des projets dcisionnels. Pentaho BI Suite permet de couvrir les domaines principaux dun projet de Business Intelligence et ceci au travers de diffrents logiciels appartenant Pentaho ou intgrables dans loffre de lditeur. Pentaho BI Suite est une suite logicielle Open source dinformatique dcisionelle avec des capacits intgrs dETL, de data mining, de reporting, de tableaux de bord et de workflow.
52 Mise en uvre
Deux versions de Pentaho sont disponibles: La version communautaire Open Source (gratuite) "Pentaho Community Edtion" (CE). La version entreprise (payante) "Pentaho Enterprise Edition" (EE).
La version CE prsente assez peu de diffrences fonctionnelles par rapport la version EE et peut donc tre utilise en production pour la gestion complte d'un systme d'information dcisionnel. La diffrence essentielle entre ces 2 versions porte principalement sur le support diteur auprs de Pentaho dans la version EE. Pentaho utilise un modle dabonnement liminant les frais de licence. Sous ce modle dabonnement, Pentaho fournit le support, des services et des amliorations du produit en contrepartie dun abonnement annuel. Pentaho BI suite comprend plusieurs composants logiciels, chaque composant permet de traiter une partie du projet BI. Le tableau suivant prsente les composants du la suite Pentaho :
53 Mise en uvre
Produit Pentaho Data Integration
Pentaho Analysis Services
Description Le Pentaho Data Integration, dont le nom de code est Kettle, consiste en un noyau moteur ETL, ainsi que des applications interface graphique dutilisation permettant lutilisateur de dfinir les jobs et les transformations. Le Pentaho Analysis Services (nom de code: Mondrian OLAP server) est un outil OLAP open source,crit en Java. Il supporte le langage MDX, le XMLA ainsi que es spcifications de linterface OLAP4J. Pentaho Reporting est compos dun noyau moteur de reporting, capable de gnrer des rapports bass XML. Plusieurs outils ont t dvelopps autour du moteur de reporting, notamment des designers interface graphique guidant lutilisateur dans le processus de cration de rapports en utilisant seulement des outils graphiques.
Pentaho Reporting
Pentaho Data Mining
Pentaho DashBoard
Pentaho for Apache Hadoop
Pentaho Data Mining (Nom de code: Weka) est un ensemble doutils pour le data mining. Ses rgles de classification, de rgression et dassociation ainsi que ses groupes dalgorithmes permettent de faite lanalyse de lexistant ainsi que lanalyse prdictive. Pentaho Dashboard est une plateforme intgre qui offre une vue globale des donnes, lutilisateur peut voir toutes sortes de rapports interactifs, de graphes et de cubes cres par les outils Pentaho tel que le Pentaho Report Designer. Cest aussi une interface tableau de bord offrant une vue centralise des mouvements des donnes du business, ainsi permettant de les contrler et de prendre des dcisions. Pentaho for Hadoop facilite la gestion de donnes intensive par loutil Apache Hadoop et fournit des alternatives ETL et danalyse de donnes simplifies pour les utilisateurs dHadoop.
Le tableau ci-dessous liste les diffrents composants qunous allons utiliser pour notre projet par type dactivit : Type dactivit ETL Analyse OLAP Tableau de bord Reporting Solution Pentaho Pentaho Data Integration (PDI). Pentaho Analysis (Mondrian+JPivot), Schema Workbench. Pentaho Dashboard. Pentaho Reporting (JFree Report), Pentaho Report Designer.
54 Mise en uvre
Etape 9 : Dploiement et intgration Alimentation du datawarehouse Lalimentation dun datawarehouse se fait grce un processus ETL. Les processus ETL (Extraction, Transformation et Chargement) sont les composants les plus critiques - et les plus importants - dune infrastructure dcisionnelle. Bien que cachs de lutilisateur de la plate-forme dcisionnelle, les processus ETL rassemblent les donnes partir des systmes oprationnels et les pr-traitent pour les outils danalyse et de reporting. La prcision et la vitesse de la plate-forme dcisionnelle toute entire dpendent des processus ETL. Les processus dETL (Extraction, Transformation et Chargement) regroupent plusieurs tapes, qui ont pour objet de transfrer des donnes depuis les applications de production vers les systmes dcisionnels :

Extraction de donnes des applications et des bases de donnes de production (ERP, CRM, SGBDR, fichiers, etc.) Transformation de ces donnes pour les rconcilier entre les diffrentes sources, pour effectuer des calculs ou du dcoupage de texte, pour les enrichir avec des donnes externes et aussi pour respecter le format requis par les systme cibles (Troisime Forme Normale, Schma en Etoile, Dimensions Evolution Lente, etc.) Chargement des donnes rsultantes dans les diffrentes applications dcisionnelles : Data Warehouse ou Enterprise Data Warehouse, Datamarts, applications OLAP (Online Analytical Processing) ou cubes, etc.
La latence des processus dETL varie du mode batch (parfois mensuel ou hebdomadaire, le plus souvent quotidien) jusquau quasi-temps rel avec des rafrachissements plus frquents (toutes les heures, toutes les minutes, etc.). Limplmentation de processus dETL efficaces et fiables comprend de nombreux challenges.
Les volumes de donnes sont en croissance exponentielle, et les processus dETL doivent traiter des quantits importantes de donnes granulaires (produits vendus, appels tlphoniques, transactions bancaires, etc.). Certains systmes dcisionnels sont mis jour de faon incrmentale, alors que dautres sont rechargs dans leur totalit chaque itration. Alors que les systmes dinformation se complexifient, la varit des sources de donnes saccrot galement. Les processus dETL doivent disposer dune large palette de connecteurs des progiciels (ERP, CRM, etc.), bases de donnes, mainframes, fichiers, Services Web etc. Les structures et applications dcisionnelles incluent des data warehouses, des data marts, des applications OLAP - pour lanalyse, le reporting, les tableaux de bord, le scorecarding, etc. Toutes ces structures cibles prsentent des besoins diffrents en termes de transformation de donnes, ainsi que des latences diffrentes. Les transformations des processus dETL peuvent tre trs complexes. Les donnes doivent tre agrges, pares, calcules, traites statistiquement, etc. Certaines transformations spcifiques au dcisionnel sont aussi requises, comme les Dimensions Evolution Lente.
55 Mise en uvre
Alors que le dcisionnel se rapproche du temps rel, les data warehouses et data marts doivent tre rafrachis plus souvent, dans des fentres de chargement toujours plus courtes.
Mise en uvre des processus ETL Pour chaque table, nous allons construire une ou plusieurs transformations (selon le besoin) base sur les mappings et les algorithmes expliqus dans ltape Collecte des informations . Nous avons donc les transformations suivantes: Etl_dim_demandes & etl_file_demande pour la table dim_demandes. Etl_Dim_type pour la table dim_type. Etl_Dim_membre pour la table dim_membre. Etl_Dim_priorite pour la table dim_priorite. Etl_Dim_ file pour la table dim_file. Etl_dim_dr pour la table dim_dr. Etl_Dim_referent pour la table dim_referent. Etl_Dim_date pour la table dim_date. Etl_reactivite & etl_reactivite_global /projet pour la table reactivite. Les transformations ne suivent pas le mme schma, a dpend de la source de donnes et des fonctionnalits requises (look ups par exemple). Dim_type est un exemple dune table ncessitant une transformation directe :
Figure 11: etl_dim_type
Les donnes slectionnes sont chargs directement de la table issuetype vers la table dim_type. Dim_demandes est un exemple dune table ncessitant une transformation complexe : Une pour le champ file_demande
56 Mise en uvre
Figure 12: etl_file_demande
Et une autre pour le reste des champs
Figure 13: etl_dim_demande
Cette transformation remplit la table dim_demandes, on constate ici lutilisation des look ups pour remplir des champs (comme dmontr dans les tables de mapping). Filter row filtre les demandes REQ seulement (comme a on nencombre pas le datawarehouse par des donnes inutiles pour le dcideur et qui risquent dattnuer les performances du systme de reporting ainsi que consommer des Go supplmentaires). Le rle du composant if field value is null est daffecter des valeurs numriques pour les champs nayant aucune valeur NULL afin de pouvoir afficher une information significative concernant les champs et pour ne pas perturber les rapports par des valeurs ventuellement non-significatives (des valeurs ngatifs par exemple).
Dim_rferent est un exemple dune table ayant des fichiers Excel comme sources de donnes
57 Mise en uvre
Figure 14: etl_dim_referent
Cette transformation est alimente depuis deux sources Excel, le flux de donnes est fusionn dans la table cible dim_referent. Pour la table de faits, nous avons utilis les transformations suivantes :
Figure 15: Alimentation des cls trangres de la table de faits
Cette transformation alimente les champs des cls trangres de la table de faits, ce sont les champs marquant la dpendance entre cette dernire et les tables des dimensions.
58 Mise en uvre
Figure 16: Mesures de la table de faits
Cette transformation remplit les 5 mesures, savoir : ractivit_global, ractivit_REQ, ractivit_avantGID. ractivit_aprsGID. ractivit_SGID.
Le premier stream concerne les mesures 4 dernires mesures. Linput dim_demandes ne slectionne que les demandes rsolues (grce des requtes crites dans linput). Pour trier les demandes ou le projet SGID est li un projet REQ et ceux o il y a pas de liaison entre les deux on a recours une composante switch/case , celle-ci ne traitant que des valeurs numriques, il faut dabord attribuer des valeurs numriques pour le champ code_demande_liee . Le traitement constant concerne les demandes ou un projet SGID a eu lieu (code_demande_liee diffrent de 0). Le traitement constant 2 concerne les demandes dont les projets de rsolution ne passent pas par SGID (Rsolues par projets REQ) (code_demande_liee=0). Pour le premier traitement: La composante Look up tire les informations (de la table jiraissue) concernant la demande lie qui a t cr dans le SGID. La composante Calculator effectue les calculs ncessaires pour le calcul de la mesure. Les Filter rows servent filtrer les demandes ayant des anomalies ou des dysfonctionnements comme les demandes ne respectant pas les workflows (exemple : les demandes ou le projet REQ est ferm avant quon ferme le projet SGID). Le dernier Look up retourne les IDs des demandes filtrs pour tablir le mapping dans Insert/Update.
Pour le deuxime traitement : Absence du projet SGID, on a besoin du calculator pour implmenter lalgorithme et effectuer les calculs ainsi quun look up pour la correspondance des demandes.
59 Mise en uvre
Le deuxime stream calcule la mesure reactivite_global. Analyse de donnes Une fois les donnes stockes, nettoyes, consolides et accessibles, elles sont utilisables. Selon les besoins, diffrents types d'outils d'extraction et d'exploitation seront envisags. Les principaux outils danalyse de donnes sont : Analyse statistiques : Les principaux types danalyse statistique sont ceux bass sur lanalyse OLAP (multidimensionnelles) et le langage R. Les arbres de dcision: Un outil fort pratique lorsqu'il s'agit de rpartir une population en groupes homognes selon des critres bien prcis, appels variables de segmentation. Le Data Mining. Le Text Mining.
Nous avons choisi la technologie OLAP pour lanalyse des donnes contenues dans le datawarehouse pour les raisons suivantes : Elle permet lanalyse multidimensionnelle requise dans les spcifications du projet. Elle permettra par la suite de gnrer des rapports personnaliss facilement construits par le dcideur. Cest une technologie mise en uvre dans le systme existant.
LOLAP LOLAP (Online analytical processing, fr : traitement analytique en ligne) est un type d'application informatique orient vers l'analyse sur-le-champ d'informations selon plusieurs axes, dans le but d'obtenir des rapports de synthse. OLAP s'inscrit dans un systme dcisionnel, galement dit de gestion, qui est ddi au management de lentreprise pour laider au pilotage de lactivit en offrant une vision transversale de lentreprise. Ce type d'application s'oppose au traitement de transactions en ligne (anglais online transaction processing abr. OLTP) qui s'inscrit dans un systme oprationnel, c'est--dire ddi aux mtiers de lentreprise pour les assister dans leurs tches de gestion quotidiennes. Ce terme a t dfini par Edgar Frank Codd en 1993 au travers de 12 rgles que doit respecter une base de donnes si elle veut adhrer au concept OLAP : 1. Vue conceptuelle multidimensionnelle 2. Transparence 3. Accessibilit 4. Constance des temps de rponses 5. Architecture client-serveur 6. Indpendance des dimensions 7. Gestion des matrices creuses 8. Accs multi-utilisateurs 9. Pas de restrictions sur les oprations inter et intra dimensions 10. Manipulation aise des donnes
60 Mise en uvre
11. Simplicit des rapports 12. Nombre illimit de dimensions et nombre illimit d'lments sur les dimensions Ce concept a t appliqu un modle virtuel de reprsentation de donne appel cube ou hypercube OLAP qui peut tre mis en uvre de diffrentes faons. Un hypercube OLAP (ou cube OLAP) est une reprsentation abstraite d'informations multidimensionnelles exclusivement numrique utilis par l'approche OLAP (acronyme de On-line Analytical Processing). Cette structure est prvue des fins d'analyses interactives par une ou plusieurs personnes (souvent ni informaticiens ni statisticiens) du mtier que ces donnes sont censes reprsenter. Les cubes OLAP ont les caractristiques suivantes :

Obtenir des informations dj agrges selon les besoins de lutilisateur. Simplicit et rapidit daccs Capacit manipuler les donnes agrges selon diffrentes dimensions Un cube utilise les fonctions classiques dagrgation : min, max, count, sum, avg, mais peut utiliser des fonctions dagrgations spcifiques
L'hypercube OLAP donne accs des fonctions d'extraction de l'information (pour visualisation, analyse ou traitement), et des fonctions de requte en langage MDX (comparable SQL pour une base de donnes relationnelles). Le langage MDX, n au sein des labos Microsoft (SQL Server OLAP), est un langage d'interrogation des bases multidimensionnelles plus adapt que le classique SQL pour le traitement des requtes de type OLAP. MDX signifie "Multi-Dimensional Expressions". Microsoft a propos le langage MDX comme standard des interrogations multi dimensionnelles. Les fonctions dextraction sont :

Rotate : slection du couple de dimensions cibler, Slicing : extraction d'une tranche d'information, Scoping : extraction d'un bloc de donnes (opration plus gnrale que le slicing), Drill-up : synthse des informations en fonction d'une dimension (exemple de drill-up sur l'axe temps : passer de la prsentation de l'information jour par jour sur une anne, une valeur synthtique pour l'anne), Drill-down : c'est l'quivalent d'un zoom , opration inverse du drill-up, Drill-through : lorsqu'on ne dispose que de donnes agrges (indicateurs totaliss), le drill through permet d'accder au dtail lmentaire des informations (voir notamment les outils H-OLAP).
Conception des Cubes Nous commenons par concevoir des schmas. Les schmas correspondent un scnario. Le schma contient plusieurs cubes pour lanalyse des diffrentes situations du scnario. Les schmas conus sont :
61 Mise en uvre
Un schma destin au directeur du centre dassistance (MOA), contenant trois cubes. Le directeur du centre a accs toutes les donnes du datawarehouse. Des schmas destins chaque membre du centre dassistance : Dans le cadre de la dmarche GIMSI, dmarche favorisant une approche cooprative de prise de dcision, nous avons dcid de concevoir des cubes pour les membres du centre dassistance pour que chacun deux peut avoir une vue de leur performance et lamliorer par la suite. Cependant, laccs sera filtr de telle sorte que chaque membre du personnel ne peut accder quaux donnes relatives son activit. Les cubes destins au directeur du centre sont : Cube Reactivit: Contient toutes les dimensions et la mesure reactivit_global. Il sintresse la ractivit globale du centre suite une demande.
Figure 17: Cube Reactivit
Cube RactivitREQ: Contient toutes les dimensions sauf que pour la dimension dim_demandes nous avons pris en compte juste les demandes qui ont t rsolues par le projet REQ sans passer par un projet SGID, il contient aussi la mesure reactivit_REQ. Ce cube sintresse aux demandes rsolues grce un projet REQ seulement.
62 Mise en uvre
Figure 18: Ractivit_REQ
Cube ReactivitREQSGID : Contient toutes les dimensions sauf que pour la dimension dim_demandes nous avons pris en compte juste les demandes qui ont t rsolues en passant par un projet SGID (et bien sr par un projet REQ). Il contient aussi les mesures Ractivit_avantGID, Ractivit_aprsGID et Ractivit_SGID.
63 Mise en uvre
Figure 19: Cube ReactiviteREQSGID
Alimentation du tableau de bord Pour alimenter le tableau de bord, il faut publier le cube. Cette opration permet de charger le tableau de bord et de rendre le cube consultable travers Pentaho User Console (interface Web du tableau de bord). Il faut sauvegarder le cube dans le rpertoire de Pentaho User Console afin quil soit consultable.
Figure 20: Pentaho User Console-Interface de dmarrage
64 Mise en uvre
Exemples de restitution
Figure 21: Analyse par Direction Rgionale
65 Mise en uvre
Figure 22: Analyse par assign (par membre)
66 Mise en uvre
67 Mise en uvre
68 Mise en uvre
Figure 23: Analyse par rfrent selon 3 indicateurs la fois
69 Mise en uvre
Figure 24: Analyse par date et par trsorerie suivant 3 indicateurs la fois
Intgration de la solution Pour intgrer la solution, il faut : Hberger le datawarehouse dans un serveur. Connecter le datawarehouse au serveur JIRA. Assurer laccs au datawarehouse par tous les utilisateurs. Installer loutil Pentaho, les transformations et les cubes dans tous les terminaux des utilisateurs. Publication des schmas (et des cubes) concernant chaque utilisateur.
70 Mise en uvre
Chapitre VI Amlioration permanente
71 Amlioration permanente
VI.
Amlioration permanente
Etape 10 : Audit du systme

Mthode d'audit pour garantir la durabilit de la performance du systme de pilotage. Avec le temps, l'organisation volue, les stratgies changent, les dcideurs acquirent de l'exprience. Pour toutes ces raisons, il est prudent de s'assurer rgulirement de la cohrence du systme avec les besoins actualiss de l'organisation et les attentes des utilisateurs. Adopter l'habitude de l'audit mthodique et priodique est vraisemblablement la meilleure solution pour garantir la durabilit de la performance intrinsque du systme de pilotage. En tant que stagiaires ne faisant pas partie de lquipe dcisionnel permanente de lentit GID, nous ne pouvons pas se charger de laudit permanent du systme, par consquent cette tape nest pas traite, strictu sensu, dans notre projet. Cest plutt la manire dont nous avons conu et dvelopp le systme qui fera de lui un systme susceptible dvoluer suivant les nouveaux besoins et capable de sadapter au changement. Les lments pris en considration pendant la conception et le dveloppement du systme sont : Les algorithmes de calcul que nous avons utilis sont valables pour tous genres de projets du centre dassistance puisque les donnes sources proviennent de la Base de donnes JIRA au niveau de laquelle toutes les donnes sont stockes. Les cls des diffrentes tables sont indpendants des donnes sources, ce qui rduit la dpendance des donnes, facilite les modifications au niveau du datawarehouse et permet de garder la traabilit aprs une ventuelle modification. Lajout dune nouvelle file, dune nouvelle trsorerie ou dun membre va tre intgr directement dans les rapports sans avoir besoin la moindre configurer le systme ou modifier le datawarehouse. Le modle une toile permet un ajout ais de nouvelles dimensions partir du modle existant sans avoir besoin de refaire tout le modle.
72
Conclusion
A titre de conclusion, notre stage de fin dtudes au sein de la Trsorerie Gnrale du Royaume nous a permis datteindre le but recherch. En effet, ce stage a t pour nous une occasion sans prcdent pour mener un projet dans les bonnes pratiques du mtier et aussi au sein dun organisme suivant un mode de management de systmes dinformations de bonnes pratiques. Le stage a t bnfique sur le plan technique vu que nous avons pu maitriser la chane de valeur entire dun projet BI en utilisant un outil Open source. Linformatique dcisionnelle est un domaine trs large et trs prometteur avec plusieurs champs dapplication, et le fait dtre ingnieur spcialiste dans ce domaine, cest avoir le sens danalyse, de conception et dorganisation, et cest aussi avoir le sens dengagement envers la communaut et assumer toutes les responsabilits qui lui ont t attribues vu limportance cruciale de cette discipline pour la stratgie de lorganisme. Pour conclure, il semble intressant de mettre en vidence que choisir cette vocation et devenir ingnieur en dcisionnel est une bonne chose. Mais ce qui est meilleur, cest duser de tout son savoir-faire dans ce domaine pour une bonne cause qui est augmenter la qualit des services offerts par ladministration marocaine pour assurer une fluidit des processus administratives de la finance publique et ainsi satisfaire au flux de travail croissant que les instances comptentes doivent rgler ainsi que pousser lavant ce domaine des Technologies dInformation et de Communication qui prend un place bien particulire dans le processus de la modernisation de ladministration et de lconomie marocaines.
73 Conclusion
Liste de figures
Figure 1: Chane de valeur dcisionelle ................................................................................................... 9 Figure 2: Procdure d'assistance GID .................................................................................................... 26 Figure 3: Interaction REQ/GID ............................................................................................................... 29 Figure 4: Workflow JIRA ........................................................................................................................ 31 Figure 5: Workflow axes de service ....................................................................................................... 31 Figure 6: Fonctions du tableau de bord ................................................................................................. 35 Figure 7: Exemple dun schma en toile ............................................................................................. 41 Figure 8: Exemple dun schma en flocons de neige ............................................................................ 41 Figure 9 : Modle en toile du Datawarehouse .................................................................................... 42 Figure 10: Modle partiel de la base de donnes de JIRA .................................................................... 43 Figure 11: etl_dim_type ........................................................................................................................ 55 Figure 12: etl_file_demande ................................................................................................................. 56 Figure 13: etl_dim_demande ................................................................................................................ 56 Figure 14: etl_dim_referent .................................................................................................................. 57 Figure 15: Alimentation des cls trangres de la table de faits ......................................................... 57 Figure 16: Mesures de la table de faits ................................................................................................. 58 Figure 17: Cube Reactivit..................................................................................................................... 61 Figure 18: Ractivit_REQ ..................................................................................................................... 62 Figure 19: Cube ReactiviteREQSGID ...................................................................................................... 63 Figure 20: Pentaho User Console-Interface de dmarrage ................................................................... 63 Figure 21: Analyse par Direction Rgionale .......................................................................................... 64 Figure 22: Analyse par assign (par membre) ....................................................................................... 65 Figure 23: Analyse par rfrent selon 3 indicateurs la fois ................................................................ 68 Figure 24: Analyse par date et par trsorerie suivant 3 indicateurs la fois ........................................ 69 Figure 25: Workflow JIRA ...................................................................................................................... 93 Figure 26: Workflow axes de service ..................................................................................................... 93
74 Conclusion
Glossaire
Agrgation: Action de calculer les valeurs associes aux positions parents des dimensions hirarchiques. Cette agrgation peut tre une somme, une moyenne, ou tout autre processus plus complexe comme la deuxime plus forte valeur. Aiguillage: Orientation de la demande dun axe vers un autre. Assistance (aux utilisateurs): Service aidant les utilisateurs rsoudre un incident ou un problme lors de lutilisation dun logiciel et assurant que le client a accs un service informatique appropri. Attribut : Un fait dcrivant chaque position d'une dimension. Axe : Correspond une dimension. Bug : Erreur dans un programme informatique pouvant perturber son fonctionnement. Client : Demandeur de service. Cellule : Une donne dfinie par une position de chaque dimension. Les cellules d'un hypercube peuvent tre vides ou remplies. Lorsqu'un grand nombre de cellules sont vides, on parle de donnes parses. Centre dassistance: au service charg de rpondre aux demandes d'assistance manant des utilisateurs de produits ou de services Cube: Le plus souvent, synonyme d'hypercube. Datamart : L'ensemble des donnes se rapportant un des mtiers de l'entreprise. Plusieurs datamart forment le datawarehouse de l'entreprise. Datawarehouse : Entrept de donnes. Ce terme anglais est utilis pour dsigner l'ensemble des informations d'une entreprise, enregistres sous un format informatique. Demande (dassistance) : demande faite par l'utilisateur d'une application informatique, concernant un incident rencontr, une volution souhaite, ou une mauvaise comprhension des rgles de gestion. Dimension : Un ensemble de donnes du mme type, permettant de structurer la base multidimensionnelle. Une dimension est parfois appele un axe. Chaque cellule d'une mesure est associe une seule position de chaque dimension. Temps, pays, produit sont des dimensions classiques. DOLAP : Desktop OLAP. Ce terme dsigne un petit produit OLAP faisant de l'analyse multidimensionnelle en local. Il peut y avoir une mini base multidimensionnelle (faon Personal Express), ou bien de l'extraction de cube (faon Business Objects). DSS : Decision Support System, ou systme d'information dcisionnel. C'est un systme d'interrogation et de prsentation des donnes adapt pour l'aide la dcision. Le terme franais quivalent est SIAD, ou Systme d'Information d'Aide la Dcision. Un autre terme anglais est EIS, ou Executive Information System.
75 Conclusion EIS : Executive Information System. Le terme anglais plus courament utilis est DSS, ou Decision Support System. FASMI : Fast Analysis of Shared Multidimensional Information, ou analyse rapide d'information multidimensionnelle partage. Ces cinq termes ont tous leur importance dans la dfinition de la technologie OLAP. Formule : C'est un hypercube virtuel, c'est dire que les valeurs obtenues sont le plus souvent calcules la vole mais non stocke dans la base de donnes. GID : Gestion Intgre de la Dpense. Hirarchie : Les positions d'une dimension organises selon une srie de relations 1-n en cascade. Cette organisation de donnes est comparable un arbre logique, ou chaque membre n'a pas plus d'un pre mais un nombre quelconque d'enfants. HOLAP : Hybrid OLAP. Dsigne les outils d'analyse multidimensionnelle qui rcuprent les donnes dans des bases relationnelles ou multidimensionnelles, de manire transparente pour l'utilisateur. Hypercube : Une construction multidimensionnelle forme de la conjonction de plusieurs dimensions. Chaque cellule est dfinie par un seul membre de chaque dimension. Incident : arrt ou dgradation d'un service.
Logiciel de gestion des services d'assistance: Logiciel applicatif qui gre les services d'assistance dans des organisations ddies ce type d'activit (comme les centres d'assistance ou les cellules d'assistance rparties. MDB : Multidimensional DataBase. Permet le stockage, le traitement et la restitution de donnes multidimensionnelles. Mesure : Un hypercube, le plus souvent de type entier ou dcimal, structur par des dimensions. Salaire, Prix, Quantit, Cot sont des mesures classiques. MOLAP : Multidimensional OLAP. Ce terme dsigne plus spcifiquement une technologie de stockage cartsien. MOLAP s'oppose ROLAP. Pour le premier, les jointures sont dja faites, ce qui explique les performances. Dans le second, les jointures entre les tables de dimension et de fait sont effectues au moment de la requte. Multicube : Une construction multidimensionnelle forme de plusieurs hypercubes partageant certaines dimensions. Multidimensionnel : Structure de donnes ayant au moins trois dimensions indpendantes. Niveau hirarchique : Au sein d'une hirarchie, les positions sont en gnral organises en niveaux. Les positions d'un mme niveau correspondent une classification prcise. Par exemple, on peut concevoir une dimension "temps", pour laquelle les jours sont au niveau 1, les mois au niveau 2 et les annes au niveau 3. OLAP : Littralement, On-Line Analytical Processing. Dsigne une catgorie d'applications et de technologies permettant de collecter, stocker, traiter et restituer des donnes multidimensionnelles, des fins d'analyse. Une autre dfinition est rsume dans l'acronyme FASMI (Fast Analysis of Shared Multidimensional Information), ou analyse rapide d'information multidimensionnelle partage. Les outils OLAP doivent respecter 12 rgles prcises que vous pouvez dcouvrir cette page.
76 Conclusion
Position : Une valeur d'une dimension. PRGID : Personne Ressource GID. Problme: Origine d'un ou de plusieurs incidents rcurrents Processus mtier: Succession impose de tches raliser concernant un mtier donn. Qualification: Dsignation du type dun incident. RDBMS : Relational DataBase Management System. Permet le stockage, le traitement et la restitution de donnes stockes dans des tables relationnelles. Son quivalent franais est SGBDR, ou Systme de Gestion de Base de Donnes Relationnelle. Rfrent : Assistants de second niveau (au niveau des Trsoreries). Relation : Une relation entre les positions de deux dimensions distinctes permet d'effectuer facilement des calculs la vole pour dfinir de nouvelles formules. REQ : Projet assistance aux utilisateurs . ROLAP : Relational OLAP. Il s'agit d'un ou plusieurs schmas en toile stocks dans une base relationnelle. Cette technique permet de faire de l'analyse multidimensionnelle partir de donnes stockes dans des bases relationnelles. Services d'assistance : Ou services support aux utilisateurs. Ce sont les services qui consistent aider les utilisateurs rsoudre un problme dans l'utilisation d'un logiciel. SGBDR : Systme de Gestion de Base de Donnes Relationnelle. Equivalent de RDBMS. SIAD : Systme d'Information d'Aide la Dcision. Equivalent de EIS. Schma en toile : Arrangement de tables dans une base de donnes relationnelle. Au centre, on trouve la table de faits, dont les colonnes constituent les mesures du multidimensionnel. Les branches de l'toile qui rayonnent partir de la table de fait correspondent aux dimensions. Le modle conceptuel de donnes permet de retrouver cette forme en toile. Utilisateur: Personnes utilisant le systme GID. Variable : En gnral synonyme de mesure. Workflow: flux d'informations au sein d'une organisation. Le terme dsigne aussi la modlisation et la gestion informatique de l'ensemble des tches accomplir et des diffrents acteurs impliqus dans la ralisation d'un processus mtier.
77 Rfrences
Rfrences
Bibliographie
JEAN MARIE GOUARNE; Le Projet Dcisionnel, Enjeux, Modles, architecture du Data Warehouse. Editions Eyrolles, 1997. ALAIN FERNANDEZ; Le nouveau tableau de bord des managers ; Editions Eyrolles, 2011. ALAIN FERNANDEZ ; lessentiel des tableaux de bord ; Editions Eyrolles, 2011. MARIA CARINA ROLDAN; Pentaho 3.2 Data Integration; Packt Publishing Ltd.; Edition 2010. Alain GARNIER ; L'information non structure dans l'entreprise - usages et outils ; Hermes - Lavoisier, 2007. PENTAHO INC.; Getting Started with Pentaho Data Integration, Pentaho Documentation. PENTAHO INC.; Pentaho Business Intelligence Suite 3.6, A guide to getting started with MySQL 5.x and Windows; Pentaho Documentation. ATLASSIAN SOFTWARE SYSTEMS, JIRA 4.1 Documentation. itSMF; An Introductionary Overview of ITIL V3; itSMF Ltd, 2007. MOHAMED TASLIMANKA SYLLA; Prsentation Analyse et conception dun projet BI ; 2008 RACHID BENNIS ; Cours La modlisation en toile ; 2010-VA SIM.
Webographie
Wikipedia anglaise: en.wikipedia.org Wikipedia franaise: fr.wikipedia.org Wiki GID: wiki.gid.gov.ma Site Web de la Trsorerie Gnrale du Royaume: www.tgr.gov.ma MSDN Library (franais) : http://msdn.microsoft.com/fr-fr/library www.itilfrance.com www.developpez.com www.developpez.net www.piloter.org bernard.lupin.pagesperso-orange.fr www.atlasdumanagement.com
78 Rfrences
Annexes
79 Charte de projet
Charte de projet
Noms et prnom des Stagiaires Organisme daccueil Date de cette version Encadrant Interne (INPT) Encadrant Externe (Organisme daccueil)
LOUTFI Ismail. TAOUR Marouane. Trsorerie Gnrale du Royaume 02 mai 2011 Version finale Mr. DAHCHOUR Mohammed dahchour@inpt.ac.ma Mr. ZAOUIA Abdellah zaouia@inpt.ac.ma Mr. AIRROUCHTE Imade i.airrouchte@gmail.com
Distribution
Ce document devra tre distribu a :
Nom Mr. AIRROUTCHE Imade Mr. DAHCHOUR Mohammed Mr. ZAOUIA Abdellah Mr. TIJANI Nadir
Fonction Encadrant externe du projet Encadrant interne du projet Encadrant interne du projet Maitre douvrage
80 Charte de projet
OBJECTIF DU DOCUMENT
Lobjectif de ce document est dassembler toute la documentation relative la gestion du projet PFE savoir : 1. lapproche et la stratgie de ralisation du projet 2. la procdure de gestion des risques. 3. La procdure de gestion du changement. 4. le plan de communication 5. le plan de projet DESCRIPTION DU PROJET 1. Contexte :
GID est un systme budgtaire et comptable unifi et commun lensemble des acteurs de la dpense publique qui vise atteindre les objectifs suivants : Rduire les dlais de traitement des actes de la dpense. Optimiser les cots de traitement des actes. Disposer en temps rel de linformation budgtaire et comptable. Offrir un service de qualit aux acteurs de la dpense publique.
Lentit GID assure aussi un service dassistance aux utilisateurs du systme GID par le biais du centre dassistance GID, cest le service charg de rpondre aux demandes dassistance aux utilisateurs et par consquent assurer le bon fonctionnement du systme et la durabilit des transactions. Cest ainsi quest n le besoin de mesure de la performance du service dassistance. Le tableau de bord dvelopp doit en priorit remplir les grandes fonctionnalits suivantes : Reporting sur le temps de ractivit du service. Reporting sur la qualit du service.
2.
Intrt du projet :
Le projet sinscrit dans une logique de dveloppement durable et permet lamlioration continue de la qualit de service fournie par le centre dassistance. Mesure de la performance du centre dassistance, identification des axes damlioration, prise de dcision plus pertinente concernant les processus dassistance.
3.
But du projet :
Mise en uvre d'un systme de reporting pour le compte du service d'assistance au sein de l'entit GID.
4.
Objectifs :
81 Charte de projet La mesure de la performance du centre dassistance.
5.
Rsultats attendus
Le produit final : Tableau de bord pour le reporting listant des indicateurs concernant les diffrents axes prciss par le maitre douvrage. Les livrables (documentation) : Rapport de PFE, Cahier de charges, Charte de projet.
6.
Inclusion et Exclusions
Inclusions: Analyse de l'environnement du centre d'assistance, analyse des donnes et de processus mtier, dfinition des objectifs, construction du tableau de bord, choix des indicateurs, conception et alimentation du datawareshouse, conception de datamarts et de cubes OLAP, restitution de donnes. Exclusions: Choix de le solution BI, scurit du systme, audit permanent du systme.
7.
Contraintes de projet
Le projet doit tre ralis en 3 mois. Le systme dcisionnel doit correspondre aux exigences mtiers du centre d'assistance. L'utilisation des outils techniques suivants: SGBD : Oracle. Suite BI: Pentaho BI Suite. En outre le systme doit vrifier : Accs distance la base de donnes dcisionnelle. Capacit minimale de 40 Go. Inclusion de la prsentation graphique de donnes. Dmarche claire et mthodique du travail. Planification du projet. Confidentialit : Existence de donnes confidentielles (les donnes contenues dans la base de donnes de JIRA).
82 Charte de projet
8.
Analyse de la valeur du projet : Valeur prsente Mapping et Reporting se font manuellement par loption de recherche de loutil JIRA ou base de tableaux Excel. Reporting ne prenant pas en considration linteraction du rfrent avec le centre dassistance. Valeur future Mapping et Reporting plus dvelopps grce un systme dcisionnel indpendant. Valeur ajoute Simplification de la recherche dans la base de donnes et cration de plus doptions.
Objectifs stratgiques Technologique
Clientle (rfrents)
Organisationnel/Fonctionnel
Reporting destin au rfrent pour ses activits en relation avec le centre dassistance. Mesure de Nouveaux performance se fait critres grce au rapport prendre en demandes considration arrivs/demandes dans la mesure rsolues. de la performance.
Meilleur service dassistance pour le rfrent.
Meilleur mesure et contrle de la performance, responsabilisation des diffrents acteurs.
83 Charte de projet
9.
Analyse des parties prenantes Influence Actions potentielles Spcification des Elaboration du cahier besoins. de charge. Exigence de dlai. Suivi du MOE quant au respect du cahier de charge, la qualit exige et aux livrables.
Parties prenantes Enjeux Centre dassistance Gain : Ralisation du (MOA) projet. Dveloppement des processus mtier et fluidit du travail. Perte: Absence doutil de mesure de performance pour le centre dassistance. Elves stagiaires Gain: Russite du projet (MOE) de Fin d'Etudes.Formation au cycle ingnieur d'tat. Laisser une bonne image de soi-mme et de l'institut de formation. Perte: Image de marque de l'institut. Image de soi-mme. Perte de temps. Mauvaises consquences sur le dbut de la carrire professionnelle. Encadrants Gain: Augmentation du nombre d'tudiants encadrs. Capitalisation de l'exprience. Perte: Temps et effort.
Une bonne/mauvaise rponse technique et mtier aux exigences du cahier de charge.
Respect du cahier de Charge. Elaboration d'une bonne solution rpondant aux exigences de la charte du projet.
Lencadrement influe Fournir l'encadrement la qualit globale du et l'assistance projet. ncessaires au MOE (tudiants stagiaires).
84 Charte de projet
10. Prrequis en matire de connaissance : -Business Intelligence (Datawarehousing, OLAP, restitution de donnes) -Conception et Gestion de bases de donnes -Modlisation des processus. -Conception de modles de donnes. -Languages requis : SQL, MDX, UML, XML, JAVA. -Outils requis : Pentaho BI suite, Oracle, JIRA, logiciels de modlisation ( PowerAMC), Modlisation par Merise.
STRATGIE DE RALISATION 1. Stratgie 1 : Il existe un MOE qui ralise le projet pour le compte dun maitre douvrage, et vous autant que stagiaire PFEs, vous travailler avec le MOE. 2. Stratgie 2 : Il existe un MOE externe qui ralise le projet pour le compte dun maitre douvrage, et vous autant que stagiaire PFEs, vous travailler avec lquipe Interne MOA 3. Stratgie 3 : Il existe une quipe interne qui va raliser le projet et vous autant que stagiaire PFEs, vous travailler avec lquipe interne. Stratgie de ralisation choisie Pour le projet La position des diffrentes ressources dployes (matrielles et humaines) par rapport l'organisme ainsi que le rapport Pertinence/Risque trs intressant nous pousse choisir la stratgie de ralisation conjointe du projet.
PROCEDURE DE GESTION DES RISQUES Il sagit de faire une identification en faisant un brainstorming des risques potentiels qui peuvent entraver la bonne marche et la bonne conduite du projet. Un registre de risque est utilis pour rsumer toutes les activits de gestion de risque qui sont prvues ou ont eu lieu, et fournit des informations pour les rapports de fin de phase et de fin du projet.
85 Charte de projet
Identifiant du risque Comprhension du besoin
Description du risques Mauvaise comprhension du CDC par le MOE
Impact du risque Refaire le CDC
Mesures prventives Dlivrer des livrables. Runions rgulires avec le MOA. Utiliser un cycle de vie en V ou en cascade avec feedback. Etablir une planification du projet.
Mauvaise conception et spcification du projet. Dlai
Conception/spcification non identiques au cahier des spcifications.
Mauvaise solution et non compatibilit de la solution avec l'existant. Retarder la soutenance du projet. Non disponibilit des diffrents encadrants pendant la soutenance. Endommagement ou perte des fichiers.
Terminer plus tard que prvu
Panne matrielle ou logicielle
Panne des machines ou des environnements de travail.
Prvoir des copies des fichiers et une machine back-up
PROCEDURE DE GESTION DE CHANGEMENT

Lobjectif de cette procdure est didentifier, dvaluer et de contrler tout changement potentiel pouvant impacter les ralisations planifies. Elle comprend gnralement les cinq activits de base suivantes : Collecter Examiner Proposer Dcider Mettre en uvre
86 Charte de projet Identifiant Encadrant Description de la modification Changement au niveau de lencadrant. Changement de loutil de travail. Changement de version. Impact de la modification Retard du travail. Eventuel changement de la dmarche. Problmes de compatibilit. Pas de changement majeur, la base de donnes reste la mme.
Outil technique (Pentaho BI Suite) Version JIRA
PROCEDURE DE GESTION DE LA COMMUNICATION

Lobjectif de cette procdure est de prparer le plan de communication du projet, il sagit de : Dterminer les vnements ncessitant une communication. Dfinir la personne responsable de la communication de l'information. Dfinir le public. Dfinir lobjectif de la communication. Dfinir les mdias de communication. Dfinir le moment de la communication, la priodicit ou la frquence de diffusion. Dfinir les livrables de communication.
Evnement Dmarrage dune tape
Fin dune tape du projet
Objectif de la communication Information des parties prenantes. Implication dans la dmarche. Information des parties prenantes.
Public Cibles Encadrants. MOA.
Mdias utiliss Prsentation. Mail.
Encadrants. MOA.
Prsentation. Mail.
PLAN DE PROJET
Cette partie est utilise pour dcrire les lments quand doit planifier dans le projet, il sagit de dfinir les : Dpendances entre les phases et les tches Elaboration des chanciers : date dbut, date fin
Le tableau suivant rsume les tches du projet :
87 Charte de projet N tche 1 Tche Documentation sur l'organisme d'accueil Documentation mtier Documentation Business Intelligence Documentation Gestion de projet Etude benchmarking de la dmarche Etude de lenvironnement Etude des processus mtier Etude des enjeux et des objectifs Collecte du besoin Formulation du besoin Ngociation du tableau de bord Ngociation des KPI Formulation des KPI Etablissement du plan du projet Elaboration de la charte du projet Elaboration du cahier de charges Modlisation multidimensionnelle Etablissement du schma multidimensionnel Etude des donnes sources Mapping Conception de la table de faits Documentation sur l'outil BI Processus ETL Analyse OLAP Restitution des donnes Tests de la solution Intgration de la solution Rdaction du rapport de stage Dure 2j Date dbut Mer 16/03/11 Date fin Ven 18/03/11
2 3
4j 5j
Lun 21/03/11 Lun 21/03/11
Lun 28/03/11 Mar 29/03/11
4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
2j 6,79j 3j 3,14j 0,5j 2,36j 0,79j 3j 2,36j 0,64j 3j 4,57j 4,57j 3j 1j 8,36j 3j 3j 2j 7j 2,21j 2,21j 0,79j 0,79j 22j
Lun 21/03/11 Mar 29/03/11 Lun 11/04/11 Lun 11/04/11 Ven 15/04/11 Lun 18/04/11 Jeu 21/04/11 Mar 19/04/11 Mar 19/04/11 Ven 22/04/11 Lun 25/04/11 Lun 25/04/11 Lun 25/04/11 Lun 02/05/11 Ven 06/05/11 Mar 10/05/11 Ven 13/05/11 Jeu 19/05/11 Lun 23/05/11 Mer 25/05/11 Mer 08/06/11 Lun 13/06/11 Mer 15/06/11 Jeu 16/06/11 Lun 09/05/11
Mer 23/03/11 Ven 08/04/11 Jeu 14/04/11 Jeu 14/04/11 Ven 15/04/11 Mer 20/04/11 Jeu 21/04/11 Ven 22/04/11 Jeu 21/04/11 Ven 22/04/11 Jeu 28/04/11 Lun 02/05/11 Lun 02/05/11 Jeu 05/05/11 Lun 09/05/11 Mar 24/05/11 Mer 18/05/11 Mar 24/05/11 Mer 25/05/11 Mar 07/06/11 Ven 10/06/11 Mer 15/06/11 Jeu 16/06/11 Ven 17/06/11 Ven 17/06/11
88 Charte de projet
Cahier des charges

Nous reconnaissons que ce document utilise des lments soumis au copyright, provenant du Modle de cahier des charges Volere. Copyright 1995 2007 the Atlantic Systems Guild Limited
Ces spcifications ont t rdiges par LOUTFI Ismail & TAOUR Marouane le 02 mai 2011.
89 Charte de projet
Lignes directrices du projet

Finalit du projet Contexte du projet GID est un systme budgtaire et comptable unifi et commun lensemble des acteurs de la dpense publique qui vise atteindre les objectifs suivants : Rduire les dlais de traitement des actes de la dpense. Optimiser les cots de traitement des actes. Disposer en temps rel de linformation budgtaire et comptable. Offrir un service de qualit aux acteurs de la dpense publique.
Lentit GID assure aussi un service dassistance aux utilisateurs du systme GID par le biais du centre dassistance GID, cest le service charg de rpondre aux demandes dassistance aux utilisateurs et par consquent assurer le bon fonctionnement du systme et la durabilit des transactions. Cest ainsi quest n le besoin de mesure de la performance du service dassistance. Le tableau de bord dvelopp doit rpondre au besoin suivant : Reporting sur le temps de ractivit du service.
Objectifs du projet Mesurer le temps de ractivit du service Enjeu Le temps de ractivit du service est un aspect majeur impactant la performance du centre dassistance et a des impacts majeurs sur lutilisation du systme GID. Mesure de la performance La mesure seffectue grce des Indicateurs cls de performance (KPI), en vue de rduire le temps de ractivit du centre ainsi que dassurer une souplesse lors du transfert des demandes entre les diffrents axes dassistance.
Les parties prenantes Matrise douvrage : Le centre dassistance en la personne de son directeur Mr. TIJANI Nadir suit le projet et est amen dcider des grandes orientations et objectifs prises lors des runions effectus tout au long de ce stage. Matrise d'uvre : La matrise duvre est assure par les deux tudiants stagiaires Mr. LOUTFI Ismail & Mr. TAOUR Marouane. Autres intervenants sur le projet : Assurent lencadrement et le suivi du projet travers les deux tudiants stagiaires Mr. LOUTFI Ismail & Mr. TAOUR Marouane: Mr. AIRROUCHTE Imade, Ingnieur BI au sein de la Trsorerie Gnrale du Royaume.
90 Charte de projet Mr. DAHCHOUR Mohammed : Tlcommunications. Professeur lInstitut National des Postes et
Mr. ZAOUIA Abdellah: Professeur lInstitut National des Postes et Tlcommunications.
Utilisateurs finaux Centre dassistance.
Contraintes
Contraintes lies lenvironnement Contraintes sur la solution Contraintes techniques Le systme dcisionnel doit correspondre aux exigences mtiers du centre d'assistance. L'utilisation des outils techniques suivants: SGBD : Oracle. Suite BI: Pentaho BI Suite. En outre le systme doit vrifier : Accs distance la base de donnes dcisionnelle. Capacit minimale de 40 Go. Inclusion de la prsentation graphique de donnes. Autres dimensions du projet Dmarche claire et mthodique du travail. Planification de projet. Confidentialit : Existence de donnes confidentielles (les donnes contenues dans la base de donnes JIRA). Environnement de fonctionnement du systme actuel Pentaho User Console. Outils techniques utiliss : Outils techniques SGBD : Oracle 10g. Suite BI : Pentaho BI suite. Lieux de fonctionnement prvus Terminaux des utilisateurs Contraintes de calendrier Clture du projet le 16 juin 2011 Contraintes de budget Nant
91 Charte de projet Conventions de dnomination Dfinitions Aiguillage : Orientation de la demande dun axe vers un autre. Assistance (aux utilisateurs): Service aidant les utilisateurs rsoudre un incident ou un problme lors de lutilisation dun logiciel et assurant que le client a accs un service informatique appropri. Bug : Erreur dans un programme informatique pouvant perturber son fonctionnement. Client : demandeur de service. Demande (dassistance) : Demande faite par l'utilisateur d'une application informatique, concernant un incident rencontr, une volution souhaite, ou une mauvaise comprhension des rgles de gestion. GID : Gestion Intgre de la Dpense. Incident : arrt ou dgradation d'un service. PRGID : Personne Ressource GID. Problme : origine d'un ou de plusieurs incidents rcurrents Qualification : Dsignation du type dun incident. Rfrent : Assistants de second niveau (au niveaux des Trsoreries). REQ : Projet assistance aux utilisateurs Utilisateur : Personnes utilisant le systme GID. Faits pertinents et hypothses Faits Nombre de demandes grs par jour ? (ainsi que leurs types) Rgles mtier Gestion des demandes : Le centre dassistance prend en charge toutes les demandes reues. Pour faire une demande au centre dassistance, le rfrent ouvre un ticket de la demande qui est reu par le centre dassistance par lintermdiaire du systme JIRA. Le centre dassistance et ouvre un projet dit projet REQ (ou projet assistance aux utilisateurs) pour la rsolution de la demande. Chaque projet REQ est identifi grce un code. Le centre dassistance nayant pas une vocation technique mais plutt mtier, il arrive quil ne soit pas capable de rsoudre certains demandes dassistance. Cest ici que les quipes fonctionnel et technique interviennent dans le processus. Une demande non rsolue par le centre dassistance est transfre lquipe fonctionnelle qui ouvre son tour un nouveau projet dit projet SGID (systme GID) concernant la demande, lquipe dploiement (qui dpend directement du centre dassistance) cre un lien entre ce projet SGID et le projet REQ correspondant, ce dernier reste ouvert jusqu' la rsolution de lincident.
92 Charte de projet Lquipe technique se charge de la rsolution technique des incidents qui ncessitent une correction dans le code source du systme, lquipe dploiement technique dploie les solutions labores par lquipe technique. Etat des demandes dans JIRA: Il y a cinq tats quune demande peut avoir dans JIRA : Ouverte. En cours de traitement. Traite. Rouverte. Ferme.
Exigences fonctionnelles
Porte du projet (description de lexistant) La situation actuelle Reporting sur le temps de ractivit: Pas de reporting prenant en considration la dimension temps, les informations sont tirs manuellement en consultant le temps douverture et de fermeture. Historique de demandes: Pas de reporting avanc sur lhistorique des demandes ainsi que leur rsolution Evnements mtiers : Ouverture de la demande (Ticket). Ouverture du projet REQ. Qualification de la demande. Traitement de la demande. Cration du projet SGID. Liaison du projet SGID au projet REQ. Transfert de la demande du centre dassistance vers lquipe fonctionnelle. Transfert de la demande de lquipe fonctionnelle vers lquipe technique. Rsolution technique de lincident. Dploiement de la solution technique. Transfert de la demande de lquipe technique vers lquipe fonctionnelle. Transfert de la demande de lquipe fonctionnelle vers le centre dassistance. Rponse au rfrent. Rouverture par le rfrent.
93 Charte de projet Liste des exigences fonctionnelles Descriptif des processus mtiers Il faut respecter les processus mtiers suivants Workflow JIRA : Le schma suivant reprsente le processus de traitement des demandes dans JIRA
Figure 25: Workflow JIRA
Workflow axes des services :
Le schma suivant, reprsentant le workflow des axes des services, reprsente les diffrentes interactions entre les axes de lassistance GID
Centre dassistance
Equipe fonctionnelle
Equipe Dploiement technique
Equipe Technique
Figure 26: Workflow axes de service
94 Charte de projet Gestion de lhistorique : Stock au niveau de la base de donnes JIRA.
Exigences lies la construction de la solution

Mise en uvre Planning Global Du 15 /03/2011 au 16/06/2011 Organisation de projet Des personnes ressources seront affectes au projet. Il est prvu, pendant la dure du projet : Les stagiaires: Mr. LOUTFI Ismail, Mr. TAOUR Marouane. Les encadrents: Mr. AIRROUCHTE Imade, Mr. DAHCHOUR Mohammed, Mr. ZAOUIA Abdellah.
Risques Comprhension du besoin: Mauvaise comprhension du CDC par le MOE. Mauvaise conception et spcification du projet: Conception/spcification non identiques au besoin. Dlai: Terminer plus tard que prvu. Panne matrielle ou logicielle : Panne des machines ou des environnements du travail.
Cots Sans objet.
95 Charte de projet
Table de matires
Contenu
I. Contexte gnral .............................................................................................................................. 8 Le projet dcisionnel ........................................................................................................................... 8 Informatique dcisionnelle (Business Intelligence) ........................................................................ 8 Le Projet dcisionnel....................................................................................................................... 8 Le Reporting .................................................................................................................................. 10 1. Organisme daccueil : La Trsorerie gnrale du royaume ..................................................... 10 Missions de la Trsorerie Gnrale du Royaume .......................................................................... 10 Organisation .................................................................................................................................. 11 Entit charge du Projet de Gestion Intgre de la Dpense ......................................................... 11 II. Mthodologie de travail ............................................................................................................... 15 Ncessit dune dmarche de travail ............................................................................................... 15 Choix de la dmarche ....................................................................................................................... 15 Etude Benchmarking..................................................................................................................... 15 Comparaison des dmarches et choix de la dmarche du projet ................................................... 20 1. Adaptation de la dmarche au contexte du projet...................................................................... 20 Phase I : Identification ................................................................................................................... 21 Phase II : Conception .................................................................................................................... 21 Phase III : Mise en uvre .............................................................................................................. 22 Phase IV : Amlioration permanente ............................................................................................ 22 Planification du projet ....................................................................................................................... 22 III. Phase didentification ................................................................................................................ 25
Etape 1 : Environnement de lentreprise ........................................................................................... 25 Dtermination de lorganisme concern ........................................................................................ 25 Organisation de lassistance .......................................................................................................... 25 Procdure de la gestion des incidents ............................................................................................ 25 Objectifs stratgiques .................................................................................................................... 26 Mode de Management ................................................................................................................... 27 Clients de lorganisme ................................................................................................................... 27 Etape 2: Identification des processus .............................................................................................. 27 Cycle de vie fonctionnel ................................................................................................................ 27
96 Charte de projet Analyse des diffrents interactions ................................................................................................ 28 Workflows ..................................................................................................................................... 30 IV. Phase de conception .................................................................................................................. 33
Etape 3 : Choix des objectifs ............................................................................................................. 33 Caractristiques dun objectif : .................................................................................................. 33 Dmarche de choix des objectifs ................................................................................................ 33 Etape 4 : Construction du tableau de bord ................................................................................... 34 Etape 5 : Choix des indicateurs ...................................................................................................... 35 Caractristiques des KPI ............................................................................................................ 35 Choix des KPI ............................................................................................................................... 36 Elaboration de la charte du projet et du cahier de charges..................................................... 37 Etape 6: Collecte des informations ................................................................................................ 38 Modlisation multidimensionnelle ................................................................................................ 38 Schma multidimensionnel ........................................................................................................... 40 Etape 7 : Systme du tableau de bord................................................................................................ 49 V. Mise en uvre ............................................................................................................................... 51 Etape 8 : Choix de loutil dcisionnel ............................................................................................... 51 Etape 9 : Dploiement et intgration ................................................................................................. 54 Alimentation du datawarehouse .................................................................................................... 54 Analyse de donnes ....................................................................................................................... 59 Alimentation du tableau de bord ................................................................................................... 63 Intgration de la solution ............................................................................................................... 69 VI. Amlioration permanente .......................................................................................................... 71
Etape 10 : Audit du systme .............................................................................................................. 71 Conclusion ............................................................................................................................................. 72 Rfrences ............................................................................................................................................. 77 Bibliographie ..................................................................................................................................... 77 Webographie .................................................................................................................................... 77 Charte de projet ..................................................................................................................................... 79 DESCRIPTION DU PROJET ..................................................................................................... 80 STRATGIE DE RALISATION ............................................................................................. 84 PROCEDURE DE GESTION DES RISQUES ........................................................................ 84 PROCEDURE DE GESTION DE CHANGEMENT .............................................................. 85 PROCEDURE DE GESTION DE LA COMMUNICATION ................................................ 86
97 Charte de projet PLAN DE PROJET ....................................................................................................................... 86 Lignes directrices du projet ............................................................................................................... 89 Finalit du projet ........................................................................................................................... 89 Les parties prenantes ..................................................................................................................... 89 Contraintes ........................................................................................................................................ 90 Contraintes lies lenvironnement .............................................................................................. 90 Terminaux des utilisateurs............................................................................................................. 90 Conventions de dnomination ....................................................................................................... 91 Faits pertinents et hypothses ........................................................................................................ 91 Exigences fonctionnelles ................................................................................................................... 92 Porte du projet (description de lexistant).................................................................................... 92 Liste des exigences fonctionnelles ................................................................................................ 93 Exigences lies la construction de la solution ................................................................................ 94 Mise en uvre ............................................................................................................................... 94 Risques .......................................................................................................................................... 94 Cots.............................................................................................................................................. 94

Rapport PFE

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Rapport PFE

Uploaded by

Copyright:

Available Formats

1 Contexte gnral

Projet de fin dtudes

ANNEE UNIVERSITAIRE: 2010-11

Pote, graphiste, dessinateur, dramaturge et cinaste franais (1889-1963)

Chapitre I Contexte gnral

Le schma suivant rsume ces tapes

Figure 1: Chane de valeur dcisionelle

1. Organisme daccueil : La Trsorerie gnrale du royaume

Chapitre II Mthodologie du travail

Ncessit dune dmarche de travail

La Balanced Scoreband essaye de raliser les quilibres suivants:

4. Amlioration permanente Le systme correspond-il toujours aux attentes ?

Peu de moyens financiers

Chapitre III Phase didentification

Etape 1 : Environnement de lentreprise

Procdure de la gestion des incidents La procdure dassistance respecte le schma suivant

Figure 2: Procdure d'assistance GID

Etape 2: Identification des processus

Dtection et enregistrement Classification et support initial Investigation Rsolution

Figure 4: Workflow JIRA

Equipe Dploiement technique

Figure 5: Workflow axes de service

Chapitre IV Phase de conception

Etape 3 : Choix des objectifs

Etape 4 : Construction du tableau de bord

Figure 6: Fonctions du tableau de bord

Etape 5 : Choix des indicateurs

Alain Fernandez, Nouveaux tableaux de bord des managers, figure 3.25.

Les nouveaux tableaux de bord des managers Editions Organisation

Etape 6: Collecte des informations

Figure 7: Exemple dun schma en toile

Figure 8: Exemple dun schma en flocons de neige

Nous avons ralis les schmas de modlisation avec le logiciel PowerAMC.

Figure 9 : Modle en toile du Datawarehouse

A. Flory, Bases de Donnes, conception et ralisation , Economica 1987.

Figure 10: Modle partiel de la base de donnes de JIRA

Cl trangre vers Project.id

Issuetype.id Priority.id Resolution.id Issuestatus.id Os_wfentry.id SchemeIssueSecurityLevels.i D -

Etape 7 : Systme du tableau de bord

Chapitre V Mise en uvre

Etape 8 : Choix de loutil dcisionnel

Produit Pentaho Data Integration

Pentaho Analysis Services

Pentaho Data Mining

Pentaho for Apache Hadoop

Figure 11: etl_dim_type

Figure 12: etl_file_demande

Et une autre pour le reste des champs

Figure 13: etl_dim_demande

Figure 14: etl_dim_referent

Figure 15: Alimentation des cls trangres de la table de faits

Figure 16: Mesures de la table de faits

Figure 17: Cube Reactivit

Figure 18: Ractivit_REQ

Figure 19: Cube ReactiviteREQSGID

Figure 20: Pentaho User Console-Interface de dmarrage

Figure 21: Analyse par Direction Rgionale

Figure 22: Analyse par assign (par membre)

Figure 23: Analyse par rfrent selon 3 indicateurs la fois

Chapitre VI Amlioration permanente

Etape 10 : Audit du systme

Ce document devra tre distribu a :

81 Charte de projet La mesure de la performance du centre dassistance.