73677630-Rapport-PFE

1 Contexte général

Projet de fin d’études

Conception et développement d’une solution de reporting avancé

et d’analyse multidimensionnelle afin d’étendre les capacités de

l’outil JIRA au sein de l’entité GID

Réalisé par

LOUTFI Ismail

TAOUR Marouane

Membres de Jury

Mr. DAHCHOUR Mohamed

(Président)

Mr. ZAOUIA Abdellah (Encadrant

interne)

Mr. AIRROUTCHE Imade (Ecandrant

externe)

ANNEE UNIVERSITAIRE: 2010-11


« Agir d’abord, rectifier ensuite s’il y a lieu, reprendre

tout à zéro s’il le faut, mais ne jamais rester inactif à la

recherche du parfait ».

Jean Cocteau 1

1 Poète, graphiste, dessinateur, dramaturge et cinéaste français (1889-1963)


Remerciements

Au terme de ce travail, il nous est agréable de nous acquitter d’une dette

de reconnaissance auprès de toutes les personnes dont l’intervention au cours de

ce stage, a favorisé son aboutissement.

Nous tenons à remercier M. JOUHAR Houcine le Directeur de l’Unité

Etudes et Solutions de nous avoir accordé l’opportunité de passer ce stage au

sein de l’entité GID.

Nous tenons à remercier tout particulièrement et à témoigner toute notre

reconnaissance aux personnes suivantes, pour l’expérience enrichissante et

pleine d’intérêt qu’elles nous ont fait vivre tout au long de la période du stage

ainsi que pour leur disponibilité, conseils et suivi: Notre encadrant au sein de

la Trésorerie Générale du Royaume M. AIRROUCHTE Imade ainsi que nos

encadrants au sein de l’INPT Messieurs DAHCHOUR Mohamed et ZAOUIA

Abdellah.

Nous tenons également à présenter nos profonds respects et

reconnaissance à M. TIJANI Nadir Directeur du Centre d’assistance de l’entité

GID, et à l’ensemble des membres de l’équipe GID pour leurs disponibilité et

qualités humaines.

Par la même occasion, Nous en profitons pour exprimer nos vifs

remerciements à tous ceux qui ont contribué de près ou de loin au bon

déroulement de ce travail


Résumé

Les tableaux de bord constituent aujourd’hui un outil incontournable de la

stratégie d’entreprise et des systèmes d’aide à la décision. Les tableaux de bord

sont en effet le composant clé d'un management de la performance maitrisé. La

maîtrise de la conception des tableaux de bord de pilotage conditionne la

réussite de la mise en place d'une stratégie gagnante. Les tableaux de bord

assistent les managers dans n’importe quel niveau de l’organisme, et fournissent

la vue d’ensemble dont les décideurs ont besoin pour contrôler l’état et les

opportunités des affaires. Ils peuvent aussi supporter l’interaction avec les

données, comme la fouille dans les détails profonds de ces derniers pour tirer

l’information utile.

Ce projet vise à implémenter cet instrument dans le but de mesure de la

performance et d’amélioration du processus de prise de décision.


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 für strategisches Management

und für Entscheidungsunterstützungsysteme. Sie sind ein Schlüsselsbestandteil

eines überwachten Leistungsmanagements. Gute aufgebaute

Geschäftsarmaturenbretter könnten eindeutige und auch starke Mittel um die

Geschäftswissen zu vorstellen und zu kontrollieren. Armaturenbretter

unterstützen Managers auf allen Ebenen, und besorgen ihnen die schnelle

Übersicht die die Entscheidungsträger brauchen um die Gesundheit und die

Gelegenheiten ihres Geschäfts zu überwachen. Die Armaturenbretter können

auch die Wirkung mit den Daten unterstützen, wie zum Beispiel die

Untersuchung von Einzelteilen um die nützliche Information zu bekommen.

Dieses Projekt zielt die Entwerfung und die Ausführung dieses Instrument mit

dem Zweck, die Leistung zu messen und der Entscheidungsprozess zu

verbessern.


Sommaire

Contexte général ...................................................................................................................................... 8

Méthodologie de travail ......................................................................................................................... 15

Phase d’identification ............................................................................................................................ 25

Phase de conception .............................................................................................................................. 33

Mise en œuvre ....................................................................................................................................... 51

Amélioration permanente ...................................................................................................................... 71

Conclusion ............................................................................................................................................. 72

Références ............................................................................................................................................. 77

Charte de projet ..................................................................................................................................... 79


Chapitre I

Contexte général


I. Contexte général

Le projet décisionnel

Informatique décisionnelle (Business Intelligence)

L'informatique décisionnelle désigne l'ensemble des outils informatiques et des différentes

technologies utilisées dans le but de permettre aux organisations de faire un meilleure usage

de leur flot de données, en facilitant l'accès à l'information et à l'analyse de celle-ci, offrant

ainsi une aide précieuse pour la prise de décisions.

L'informatique décisionnelle joue un rôle de premier plan dans les entreprises d'envergure,

particulièrement dans les départements de la finance.

L'informatique décisionnelle permet notamment le stockage des données, en conservant leur

aspect temporel, permettant ainsi de faire état de la progression de l'entreprise et de l'atteinte

des objectifs fixés.

L'informatique décisionnelle permet également de faire des prévisions en se basant sur les

données passées.

Un outil de Business Intelligence aide par exemple au contrôle 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 Intégrée,

permettant l'obtention d'un système d'informations homogène pour l'ensemble de l'entreprise.

Avec l'augmentation du nombre d'informations, l'apparition d'infrastructures plus importantes

et performantes a été nécessaire (Data Warehouse, Data mining, OLAP,…).

Le marché de l'informatique décisionnelle reste en croissance régulière et offre une belle

visibilité grâce aux progrès technologiques continus, aux nouvelles architectures

informatiques (Internet, client-serveur, SOA), à la mise en place de nouveaux logiciels et aux

nouvelles stratégies d'entreprise (fusion/acquisitions, gestion client).

Le reporting est probablement l'application la plus utilisée encore aujourd'hui de

l’informatique décisionnelle, il permet aux gestionnaires :

de sélectionner des données relatives à telle période, telle production, tel secteur de

clientèle, etc.,

de trier, regrouper ou répartir ces données selon les critères de leur choix,

de réaliser divers calculs (totaux, moyennes, écarts, comparatif d'une période à l'autre,

...),

de présenter les résultats d’une manière synthétique ou détaillée, le plus souvent

graphique selon leurs besoins ou les attentes des dirigeants de l’entreprise.

Le Projet décisionnel

Dans une entreprise, le volume de données traitées croît rapidement avec le temps. Ces

données peuvent provenir, des fournisseurs, des clients, de l’environnement etc. Cette quantité

de données augmente en fonction du secteur et de l'activité de l’entreprise. Par exemple, dans


la grande distribution, les quantités de données collectées chaque jour sont énormes

(notamment lorsque les magasins collectent les tickets des caisses).

L'entreprise dispose de plusieurs options pour traiter ce flux de données :

les données anciennes sont effacées et l'entreprise ne conserve que les données actives

ou un historique récent,

les données sont stockées dans une base et l'entreprise n'envisage pas d'usage

immédiat

les données sont stockées au fur et à mesure qu’elles arrivent de manière cohérente

pour qu’elles soient exploitables directement.

Le projet décisionnel correspond à cette dernière option. Il s’agit de traiter les données et de

les stocker de manière cohérente au fur et à mesure qu’elles se présentent. C’est pour cela que

le projet décisionnel est un projet sans limite dans le temps. Pour mener à bien ces projets

décisionnels, il existe une multitude d'outils, chacun étant plus ou moins adapté à la taille de

l'entreprise, à la structure des données existantes et au type d'analyse désiré.

Une chaîne de valeur décisionnelle simplifiée se présente comme suit :

Des SGBD relationnels et d'autres systèmes qui contiennent les données

d'exploitation.

Un ETL extrait les données pertinentes et les charge dans l'ODS du datawarehouse.

Les données sont structurées dans le datawarehouse.

Des datamarts qui exploitent une technologie X-OLAP sont mis à jour à partir du

datawarehouse.

Des rapports sont générés sur ces données.

Le schéma suivant résume ces étapes

Figure 1: Chaîne de valeur décisionelle


Le Reporting

Le reporting est l'opération consistant, pour une entreprise, à faire rapport de son activité.

C'est la présentation périodique de rapports et bilans analytiques sur les activités et résultats

d'une organisation, d'une unité de travail ou du responsable d'une fonction, destinée à en

informer ceux chargés de les superviser en interne ou en externe, ou tout simplement

concernés par ces activités ou résultat

Les outils de reporting proposent la réalisation de rapports selon un format prédéterminé. Les

bases de données sont interrogées selon les requêtes SQL préparées lors de l'élaboration du

modèle. Le rapport peut ensuite être diffusé sur l'Intranet, périodiquement en automatique ou

ponctuellement à la demande.

L'outil d'élaboration du modèle du rapport offre bien entendu des fonctions spécifiques de

calcul et de présentation (graphiques) afin de concevoir des comptes rendus particulièrement

seyants et pertinents.

1. Organisme d’accueil : La Trésorerie générale du royaume

La Trésorerie Générale du Royaume constitue l’une des administrations les plus importantes

du Ministère des Finances et de la Privatisation et à travers laquelle transite l’ensemble des

flux financiers et comptables de l’Etat et des collectivités locales. Elle est également au centre

d’un maillage institutionnel constitué d’administrations publiques, d’établissements publics,

de collectivités locales et d’autres grandes institutions financières tous concernés par la

gestion des deniers publics. La TGR a initié un grand projet de modernisation dont la vision

stratégique est sous-tendue par deux objectifs fondamentaux à savoir : - La contribution à

l’amélioration substantielle de la gestion des finances publiques. - L’amélioration du service

rendu aux clients et partenaires.

Missions de la Trésorerie Générale du Royaume

1- Le recouvrement des créances publiques

La TGR assure, par le biais de son vaste réseau de comptables publics, la perception des

recettes fiscales et non fiscales, à travers notamment :

la gestion du contentieux administratif et judiciaire relatif au recouvrement et

l’assistance des percepteurs en la matière;

la prise en charge des ordres de recettes au titre du budget général de l’Etat, des

budgets annexes et des comptes spéciaux du Trésor;

la centralisation des prises en charges et des recouvrements au titre des amendes

et condamnations pécuniaires;

la gestion des comptes de prêts et d’avances accordées par le trésor et de «fonds

de roulement» consentis par des organismes de financement des projets publics;

l’élaboration des statistiques concernant la situation du recouvrement de créances

publiques;

2- Le contrôle et le paiement des dépenses publiques

La TGR assure le contrôle et le règlement des dépenses publiques. Ainsi, le réseau de la TGR

est chargé de contrôler la régularité des engagements de la quasi-totalité des dépenses de

l’Etat. Elle assure à travers son réseau de comptables, le règlement desdites dépenses. En


effet, au vu des propositions d’engagement et des ordres de paiement transmis par les

ordonnateurs accrédités, les services de la TGR procèdent au règlement des créances de l’Etat.

La Trésorerie Générale assure également par le biais de la Paierie Principale des

Rémunérations (PPR), le contrôle et le traitement de la paie de prés 650.000 fonctionnaires.

3- La gestion des finances locales

A travers son réseau de trésoriers et receveurs communaux, la TGR assure la gestion des

budgets de 1659 collectivités locales, de 86 groupements et de 41 arrondissements,

En effet, la TGR procède au recouvrement de leurs créances, au règlement des leurs dépenses

et à la paie de leur personnel.

La TGR met à contribution également son expertise en offrant le conseil et l’assistance

nécessaires aux collectivités locales .Ce conseil qui est de nature juridique et financière,

concerne, entre autres, la modernisation des procédures comptables, l’analyse financière et

l’élaboration des tableaux de bord.

4- La gestion des dépôts au Trésor

La TGR assure la mission de gestion des dépôts au Trésor. Elle participe à travers cette

activité au financement de la trésorerie de l’Etat. A ce titre, elle gère les comptes des

entreprises et établissements publics qui sont soumis à l’obligation de dépôt de leurs fonds au

trésor. Cette activité est étendue également à la gestion des dépôts d’autres personnes morales

ou privées.

5- La production de l’information financière et comptable

La TGR assure la centralisation des opérations comptables de l’Etat et des collectivités locales

et de ce fait elle constitue une référence en matière de production et de valorisation de

l’information comptable de l’Etat et des collectivités locales.

La production de l’information comptable permet ainsi de :

- décrire précisément les opérations budgétaires et financières.

- restituer rapidement une information fiable et indispensable à la prise de décision.

- préparer les documents relatifs à la reddition des comptes.

Organisation

la TGR est organisée comme suit :

Direction de Réglementation et de la Normalisation Comptable.

Direction du Pilotage des métiers et de l’Animation du Réseau.

Direction de l’Appui et de la Gestion des Ressources.

Centre National de Traitements.

Entité chargée du Projet de Gestion Intégrée de la Dépense.

Direction du Contrôle et du Développement.

Division de l’Inspection.

Entité chargée du Projet de Gestion Intégrée de la Dépense

Dans le cadre de la mise en œuvre du Système de Gestion Intégrée de la Dépense (GID), une

entité projet chargée dudit système a été créée au sein de la Trésorerie Générale du Royaume

par décision n° 139/04/TGR du 15 octobre 2004. Cette structure a pour mission d’assurer la

réalisation et la mise en œuvre du Système GID, en le généralisant à l’ensemble des acteurs

impliqués dans l’exécution de la dépense publique.


Le système GID (Gestion Intégrée de Dépense)

Dans le cadre des grandes réformes de modernisation et de promotion pour la bonne

gouvernance, le projet GID se veut être le vecteur promotionnel de la gestion rationnelle des

dépenses publiques et ce grâce à une utilisation efficiente des nouvelles technologies de

l’information et de la communication.

Le système GID (système de Gestion Intégrée de la Dépense) est un système d’information

qui permet aux partenaires de la dépense de travailler sur un objectif commun structuré en

tâches à l’aide d’outils de traitement et de communication.

La mise en place du système GID a permis l’optimisation de la gestion de la dépense publique

dans les meilleures conditions de fiabilité, célérité et efficacité.

En effet, l’environnement actuel se caractérise par des exigences de plus en plus accrues, en

termes de qualité de service, de transparence, d’efficacité et d’efficience. Or, l’exécution de la

dépense publique qui représente un moyen important d’exécution des politiques

gouvernementales accuse une certaine lourdeur des contrôles exercés, des interprétations

disparates de certains concepts de la gestion de la dépense et la non généralisation des

systèmes d’évaluation de l’efficacité de ses services.

Par ailleurs, Il existe une certaine disparité au niveau de l’utilisation des Technologies de

l’Information et de la Communication qui supportent le métier de la dépense et qui est

essentiellement due à un manque de coordination dans le développement de certains systèmes

et à leur faible niveau d’intégration.

L’impact sur le processus de la dépense se traduit par un allongement des coûts et des délais

de réalisation de la commande publique, ainsi qu’au retard dans l’élaboration des comptes

administratifs et des projets de Lois de Règlement. Et par conséquent, il est difficile d’avoir

une vision globale de l’exécution du budget. Par ailleurs, des ressources importantes sont

mobilisées pour la gestion de la dépense au détriment des vrais métiers de chacun des

départements ministériels, tout en favorisant la multiplication des coûts d’acquisition et de

maintenance des systèmes et des équipements informatiques relatifs à la gestion de la

dépense.

Dès lors, il est nécessaire de concevoir et de mettre en œuvre un système d’information

budgétaire et comptable unifié et commun à l’ensemble des acteurs, visant la rationalisation et

l’optimisation de la gestion publique, à travers notamment une utilisation avisée des nouvelles

technologies de l’information et de la communication.

La finalité globale du système GID consiste à permettre aux intervenants dans le processus

d’exécution de la dépense de se doter d’un outil performant de gestion qui répond à leurs

besoins, tout en étant parfaitement intégré aux systèmes de leurs partenaires, en vue de leur

assurer la réalisation de leurs prérogatives dans les meilleures conditions de fiabilité et de

célérité requises. Ainsi le système GID devrait constituer à terme :

Un levier de modernisation de l’Administration.

Un socle de mise en œuvre des réformes budgétaires.


Un outil capable de fournir, en temps réel, l’information nécessaire aux prises de

décisions.

Le système GID vise à atteindre les objectifs suivants:

Réduire les délais de traitement des actes de la dépense.

Optimiser les coûts de traitement des actes.

Disposer en temps réel de l’information budgétaire et comptable.

Offrir un service de qualité aux acteurs de la dépense publique

L’envergure et la complexité du projet exigent la mise en place d’une équipe forte composée

d’experts fonctionnels et techniques, mais dans le cadre d’une organisation souple, capable

d’évoluer en fonction de la montée en charge du projet, en l’occurrence les nombreux

chantiers fonctionnels et techniques auxquels il donnera lieu.

L’organisation actuelle de l’entité projet GID est comme suit:

Mission Conduite du Changement

Mission Expertises Métiers

Unité Etudes et Développement, qui englobe :

Mission Etudes et Intégration des Solutions Informatiques

Mission Infrastructures Technologiques

Unité Organisation et Support Partenaires

Mission Support aux Partenaires

Mission Organisation Planification et Contrôle


Chapitre II

Méthodologie du travail


II. Méthodologie de travail

Nécessité d’une démarche de travail

Un projet professionnel nécessite une démarche claire et bien structurée. La démarche est

nécessaire pour :

Organiser le travail.

Assurer une traçabilité au sein du projet.

Identifier clairement les différentes phases.

Mener le projet dans les bonnes pratiques.

Choix de la démarche

Il existe plusieurs méthodes d’exécution de projets tableau de bords, chaque démarche est

adaptée à une stratégie ou à un ensemble de stratégies. En effet, le projet tableau de bord

dépend fortement de la stratégie mise en place/souhaitée et chaque démarche implique une

approche différente suivant cette stratégie. Une étude benchmarking s’impose pour

déterminer les avantages et les limites de chaque démarche et son degré d’adaptation à notre

projet.

Etude Benchmarking

Nous avons recensé trois démarches qui comptent parmi les plus utilisés pour les projets

tableaux de bord. Elles sont :

Démarche du tableau de bord prospectif (Balanced Scoreband/BSC).

Démarche Skandia.

Démarche GIMSI.

Présentation des démarches

La Balanced Scoreband (BSC)

Lancée en 1992 par Robert S. Kaplan et David Norton, c’est une méthode visant à mesurer les

activités d'une entreprise en quatre perspectives principales : Apprentissage, processus, clients

et finances. Au préalable, la vision, les valeurs et la mission de l'entité doivent être

explicitées, en vue de donner aux managers une compréhension globale de leur organisation.

L'élément nouveau déterminant s'attache non seulement aux résultats financiers, mais aussi

aux questions humaines qui amènent ces résultats, afin que les organisations se concentrent

sur l'avenir et agissent dans leur meilleur intérêt à long terme.

Le type de tableau de bord décrit 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 :


1. Traduire la vision en objectifs opérationnels ;

2. Communiquer la vision et la décliner en performance individuelle ;

3. Planification d'activité ;

4. Feedback et apprentissage, puis ajustement de la stratégie en fonction.

Ces 4 processus correspondent aux 4 perspectives suivantes: Financière, Client, Processus

Internes, Apprentissage et Organisationnel.

Perspective Financière

- Quelle est la valeur créée pour les actionnaires ?

Perspective Client

- Quelle est la valeur créée pour les clients ?

Perspective Processus Internes

- Quelle est la performance des processus-clés de la réussite ?

Perspective Apprentissage Organisationnel

- Quelle est notre capacité à progresser ?

La Balanced Scoreband essaye de réaliser 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 passée et les indicateurs

"prospectifs"

Equilibre entre la perception externe et la performance réalisée interne

Navigateur Skandia

Le navigateur Skandia (ou tableau de bord dit « suédois ») place les compétences et les

ressources humaines au centre des préoccupations de l’entreprise. Ce tableau de bord à

l’avantage de pousser de manière flagrante l’entreprise à se remettre en question et à sans

cesse innover. De plus, il prend en compte des valeurs immatérielles indispensables à la

réussite et à la pérennité de l’entreprise. Enfin, il s’intègre parfaitement dans le contexte

économique, social et environnemental actuel en perpétuel mouvement et dans lequel la

reconnaissance des salariés demeure plus que jamais primordial.

La raison d’être de ce tableau de bord est qu’il se fonde sur une dimension sociétale. Cela

signifie que les réflexions des entreprises prennent en compte l’impact de leurs activités sur

l’environnement social et environnemental.

Les indicateurs propres à ce tableau de bord reprennent une partie des indicateurs du BSC

mais en intègre de nouveaux comme par exemple le temps consacré aux clients rapporté au

temps de présence des collaborateurs. Dans cet exemple, la valeur des individus (client et

collaborateur) est clairement prioritaire.

Les biens immatériels mis en avant

Les biens immatériels sont des actifs qui ne peuvent être comptabilisés à l'actif du bilan mais

qui, pourtant, jouent un rôle majeur dans la réussite de l'entreprise. Ce peut être par exemple

la localisation de l'entreprise (est-elle proche d'infrastructures ou au beau milieu de la


campagne profonde). Pour comprendre comment le navigateur intègre ces éléments, l’analyse

des quatre axes du navigateur est indispensable:

L’axe humain

Occupant une place centrale, cela marque une volonté de placer les relations, les compétences

et les ressources humaines au centre des préoccupations de l’entreprise. Il prend en compte

d’une part le capital humain et d’autre part le capital structurel.

Le capital humain concerne principalement des résultats d’enquêtes internes comme la

motivation du salarié, la fierté d’appartenance à son entreprise, les sentiments des salariés face

à leur employeur etc. Cependant, le capital humain associe à ses différents ratios d’autres

mesures comme le taux d’absentéisme, le taux de formation, etc. plus génériques.

Le capital structurel, lui, mesure la capacité relationnelle de l’entreprise en calculant trois

facteurs :

Les relations avec les tiers de l’entreprises (actionnaires, banques, fournisseurs,

clients, salariés etc.). Cela peut se traduire par des taux de rencontre ou de partenariats

par exemple.

La capacité de l’entreprise à motiver ses collaborateurs Le dynamisme de l’entreprise. Ici des indicateurs basiques comme le taux de

croissance du CA, la mesure de la recherche et développement, la pénétration des

nouveaux produits mais aussi des indicateurs axés autour de l’humain comme le taux

d’embauche et de départ, la notoriété, le taux de participations des salariés aux

événements de l'entreprise etc.

L’axe financier

L’axe financier, « le toit », représente le passé de l’entreprise. Outre les ratios habituels, il met

en avant des indicateurs orientés sur la personne. Ce peut être par exemple le coût de la

relation client ou le bénéfice par salarié.

L’axe client

Ici, comme le Balanced Scoreband, l’axe client met en avant des notions de fidélité, de

potentiel de l’entreprise à conquérir de nouveaux clients ou encore un taux de réclamations ou

de SAV.

L’axe processus

Le processus, ici, signifie l’informatique. Cela comprend donc des mesures de taux de

renouvellement du parc informatique, le taux de maintenance / panne des serveurs. Comme

les autres axes, l’humain est au centre des mesures. On peut ainsi trouver des taux de

formation à l’outil informatique, mesure des compétences des salariés etc.


L’axe innovation et développement

Comment l’entreprise appréhende son marché futur ? Les mesures de ce volet évaluent

l’entreprise sur des ratios concernant les nouveaux besoins des clients, le nombre de nouveaux

produits sortis, le taux de recherche et développement etc.

Démarche GIMSI

GIMSI est une méthode de conduite du projet de pilotage de la performance centrée sur

l'homme décideur en situation, et définit un cadre méthodologique afin de mieux formaliser

les conditions de réussites des projets tableaux de bord.

La méthode GIMSI recentre la question du projet tableaux de bord sur les 3 questions

essentielles :

Dynamiser la création de valeurs dans une orientation transversale (découpage en

processus et démarche de progrès continu)

Positionner les besoins de l'acteur en situation de décision au cœur du processus afin

de considérer à sa juste valeur la prise de risques inhérente aux nouveaux modes de

fonctionnement des entreprises.

Contribuer à la destruction du mur existant encore entre les solutions technologiques

opérationnelles et les attentes des utilisateurs.

Structurée en 10 étapes, la méthode s'inscrit naturellement dans un mode de management

moderne fondé sur un principe de gouvernance généralisée privilégiant la prise de décision

répartie. Multiplier les points de décision, rapprocher le processus décisionnel au plus près du

terrain, là où se situe l'information, là où l'action est possible, est en effet l'unique moyen de

maîtriser la complexité croissante des organisations.

Les décideurs ne sont pas isolés. La méthode GIMSI favorise la coopération entre les

décideurs, le partage de la connaissance et l'intégration performante des outils et techniques

de la Business Intelligence.

Etapes de la démarche GIMSI

La démarche GIMSI est structurée en 10 étapes bien identifiées et regroupées en 4 phases

thématiques. Le tableau suivant représente les différentes phases et étapes de la démarche


1. Identification

Quel est le contexte?

Réalité de l'environnement concurrentiel,

forces et faiblesses de l'organisation,

identification concrète des axes stratégiques

et des points d'intervention

Etape 1 : Environnement de

l'entreprise

Analyse de l'environnement

économique et de la stratégie de

l'entreprise afin de définir le

périmètre et la portée du projet

Etape 2 : Identification de

l'entreprise

Analyse des structures de l'entreprise

pour identifier les processus,

activités et acteurs concernés.

2. Conception

Que faut-il faire ?

Une démarche centrée sur le décideur de

terrain en situation, point central du

processus de décision et par conséquent du

système de pilotage de la performance

Etape 3 : Définition des objectifs

Sélection des objectifs tactiques de

chaque équipe en fonction de la

stratégie générale

Etape 4 : Construction du tableau de

bord

Définition 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 concernés

Etape 6 : Collecte des informations

Identification des informations

nécessaires à la construction des

indicateurs

Etape 7 : Le système de tableau de

bord

Construction du système de tableau

de bord, contrôle de la cohérence

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 sélection

pour le choix des progiciels adéquats

Etape 9 : Intégration et déploiement

Implantation des progiciels,

déploiement à l'entreprise.

4. Amélioration permanente

Le système correspond-il toujours aux

attentes ?

Etape 10 : Audit

Suivi permanent du système


Comparaison des démarches et choix de la démarche du projet

Après l’étude des trois méthodes, il serait possible de faire la comparaison suivante tenant en

compte les principaux volets de chacune des stratégies:

Méthode Volet

stratégique

Volet humain Volet

financier

Domaine

d’application

Balanced

Scoreban

d (BSC)

Stratégie

prédéfinie

Dirigiste: Manque

de participation

du personnel

Coûteuse Stratégie d’Entreprise

Navigateu

r Skandia

Prise en

considération

des facteurs

immatériels

dans

l’élaboration de

la stratégie

Enquête sur le

capital humain

Pas de

moyens

financiers

Gestion d’Entreprise

GIMSI S’adapte à toute

stratégie mise en

place

Coopérative :

Forte implication

du personnel

Peu de

moyens

financiers

Pilotage

d’entreprise/organism

es

Grâce à cette étude benchmarking, nous constatons que la méthode GIMSI est celle la plus

adaptée à notre projet. Cela est dû à plusieurs raisons:

GIMSI s’adapte à la stratégie mise en place, ce qui est nécessaire pour notre projet.

Le modèle de management participatif adopté par GIMSI fait que le projet soit

motivant.

Les tableaux de bord GIMSI sont orientés aux métiers de pilotage, ce qui est en parfait

accord avec la finalité de notre projet.

L’utilisation de GIMSI est gratuite.

La méthode GIMSI permet en outre de :

Réaliser le projet décisionnel dans sa totalité, de la conception à la mise en action.

Choisir les indicateurs de performance les mieux adaptés à chaque situation.

Adopter une approche centrée sur le décideur.

Fiabiliser les informations dès la collecte des données.

S’intéresser à l’aspect développement durable du système.

1. Adaptation de la démarche au contexte du projet

Dans cette partie nous allons lister les différents étapes et tâches de notre projet structurés

selon la démarche choisie, GIMSI.


Phase I : Identification

Etape 1 : Environnement de l’entreprise

Dans cette première étape il s’agit d’identifier les spécificités de l’organisme, son « marché »,

sa stratégie ainsi que le management pratiqué.

Tâches de l’étape

Détermination de l’organisme concerné.

Organisation de l’assistance

Objectifs stratégiques.

Mode de Management.

Clients de l’organisme.

Etape 2 : Identification des processus

Il s’agit dans cette étape de d’étudier les métiers spécifiques du centre d’assistance, d’analyser

les différents interactions, ainsi que d’identifier les processus critiques.


Cycles de vie fonctionnels

Analyse de différentes interactions

Workflows.

Phase II : Conception

Etape 3 : Choix des objectifs

Cette partie s’intéresse à la démarche à suivre pour sélectionner les objectifs en parfait accord

avec les finalités stratégiques.


Caractéristiques d’un objectif

Collecte du besoin

Formulation du besoin

Etape 4 : Tableau de bord

Caractéristiques du tableau de bord.

Etape 5 : Choix des indicateurs KPI

Dans cette partie nous allons expliquer la méthode suivie pour bien choisir les indicateurs

pertinents de mesure de la performance.


Caractéristiques des KPI.

Choix des KPI.

Elaboration du cahier de charge et de la fiche du projet.

Etape 6 : Collecte des informations

Cette phase s’intéresse à la collecte des informations décisionnelles à partir des données

sources



Modélisation multidimensionnelle.

Schéma multidimensionnel.

Etude des données sources.

Mapping.

Table de faits : Algorithmes et calcul.

Etape 7 : Système du tableau de bord

Cette étape s’intéresse au partage de la connaissance au sein de l’équipe des décideurs

afin de faire une prise de décision pleinement efficace.


Prise de la décision en groupe

Phase III : Mise en œuvre

Etape 8 : Choix de l’outil décisionnel

Cette étape s’intéresse du choix de l’outil décisionnel à utiliser, Dans le cas de notre

projet, nous ne serons pas amenés à faire un choix de l’outil, l’outil étant imposé par

l’entité GID. L’outil BI utilisé est Pentaho BI Suite.


Généralités sur les outils BI.

Présentation de l’outil Pentaho.

Etape 9 : Déploiement et Intégration

Dans cette étape, nous allons exposer la mise en œuvre technique de la solution, son

déploiement, ainsi que son intégration au système de reporting existant.


Alimentation du datawarehouse.

Analyse de données

Alimentation du tableau de bord.

Intégration de la solution.

Phase IV : Amélioration permanente

Etape 10 : Audit du système

Planification du projet

L’élaboration d’un planning nous permettra d’organiser notre projet dans le temps ainsi que

de savoir le degré de liaison entre différentes tâches.

Le tableau ci-dessus résume l’organisation des tâches de notre projet.


N°

tâche

Tâche Durée Date début Date fin

1 Documentation sur l'organisme

d'accueil

2j Mer 16/03/11 Ven 18/03/11

2 Documentation métier 4j Lun 21/03/11 Lun 28/03/11

3 Documentation Business

Intelligence

5j Lun 21/03/11 Mar 29/03/11

4 Documentation Gestion de projet 2j Lun 21/03/11 Mer 23/03/11

5 Etude benchmarking de la

démarche

6,79j Mar 29/03/11 Ven 08/04/11

6 Etude de l’environnement 3j Lun 11/04/11 Jeu 14/04/11

7 Etude des processus métier 3,14j Lun 11/04/11 Jeu 14/04/11

8 Etude des enjeux et des objectifs 0,5j Ven 15/04/11 Ven 15/04/11

9 Collecte du besoin 2,36j Lun 18/04/11 Mer 20/04/11

10 Formulation du besoin 0,79j Jeu 21/04/11 Jeu 21/04/11

11 Négociation du tableau de bord 3j Mar 19/04/11 Ven 22/04/11

12 Négociation des KPI 2,36j Mar 19/04/11 Jeu 21/04/11

13 Formulation des KPI 0,64j Ven 22/04/11 Ven 22/04/11

14 Etablissement du plan du projet 3j Lun 25/04/11 Jeu 28/04/11

15 Elaboration de la charte du projet 4,57j Lun 25/04/11 Lun 02/05/11

16 Elaboration du cahier de charges 4,57j Lun 25/04/11 Lun 02/05/11

17 Modélisation

multidimensionnelle

3j Lun 02/05/11 Jeu 05/05/11

18 Etablissement du schéma

multidimensionnel

1j Ven 06/05/11 Lun 09/05/11

19 Etude des données sources 8,36j Mar 10/05/11 Mar 24/05/11

20 Mapping 3j Ven 13/05/11 Mer 18/05/11

21 Conception de la table de faits 3j Jeu 19/05/11 Mar 24/05/11

22 Documentation sur l'outil BI 2j Lun 23/05/11 Mer 25/05/11

23 Processus ETL 7j Mer 25/05/11 Mar 07/06/11

24 Analyse OLAP 2,21j Mer 08/06/11 Ven 10/06/11

25 Restitution des données 2,21j Lun 13/06/11 Mer 15/06/11

26 Tests de la solution 0,79j Mer 15/06/11 Jeu 16/06/11

27 Intégration de la solution 0,79j Jeu 16/06/11 Ven 17/06/11

28 Rédaction du rapport de stage 22j Lun 09/05/11 Ven 17/06/11


Chapitre III

Phase d’identification

25 Phase d’identification

III. Phase d’identification

Etape 1 : Environnement de l’entreprise

Détermination de l’organisme concerné

L’organisme pour lequel notre projet est destiné est le centre d’assistance au sein de l’entité

GID, il est chargé du métier d’assistance aux utilisateurs (au sens ITIL) de ce système.

Définition de l’assistance au sens ITIL : En informatique, les services d'assistance, ou

support aux utilisateurs, correspondent aux activités de Service support (ITIL) du

référentiel ITIL. Ils consistent à aider les utilisateurs à résoudre un problème dans l'utilisation

d'un logiciel.

L'expression support technique (technical support) quelquefois employée met l'accent sur le

fait que ces services s'appuient sur des outils techniques tels que le téléphone, le courrier

électronique, les logiciels de gestion des services d'assistance, ou le Web.

Les services d'assistance sont réalisés par des équipes rassemblées dans un centre d'assistance,

ou réparties sur plusieurs sites dans des cellules d'assistance, de taille plus réduite.

Le centre d’assistance est au niveau de la mission Planification, Organisation et Contrôle.

Organisation de l’assistance

Le service d’assistance GID est organisé selon 3 niveaux :

1er

niveau: Personnes Ressources GID au niveau de chaque acteur.

2ème

niveau: 124 référents GID au niveau des trésoreries TM/TP. (Les référents GID

sont ressources relevant des Trésoreries Ministérielles, Provinciales et Préfectorales.

Les Référents GID sont chargés de promouvoir le système GID au niveau des

ordonnateurs).

3ème

niveau: Centre d’assistance GID.

Procédure de la gestion des incidents

La procédure d’assistance respecte le schéma suivant


Figure 2: Procédure d'assistance GID

C’est le premier niveau d’assistance (PRGID) qui traite en premier les demandes d’assistance,

s’il n’arrive pas à les résoudre ils seront transférés au deuxième niveau (référents), sinon ils

seront transférés au troisième niveau (centre d’assistance). Le troisième niveau est supposé

capable de résoudre tous les incidents puisque il dispose des ressources humaines et

logistiques lui permettant de résoudre tous types d’incidents dans le système.

Objectifs stratégiques

Ses objectifs stratégiques peuvent être résumés dans trois grands objectifs:

Enregistrer les incidents signalés par les utilisateurs et suivre leur résolution;

Qualifier et consigner les améliorations fonctionnelles souhaitées;

Apporter les éclaircissements et explications nécessaires.


Mode de Management

L’assistance GID est organisé selon le référentiel ITIL Version 2, plus exactement le premier

livre « Soutien de services » (Service support) qui décrivant 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 d’assistance ITIL ainsi que les cinq processus du métier d’assistance.

1. Le centre de services (Service Desk)

2. La gestion des incidents (Incident Management)

3. La gestion des problèmes (Problem Management)

4. La gestion des changements (Change Management)

5. La gestion des mises en production (Release Management)

6. La gestion des configurations (Configuration Management)

Le processus concernant notre projet est le processus « Gestion des incidents ».

La définition ITIL de l'objectif de la Gestion des Incidents est la suivante :

Restaurer aussi vite que possible le fonctionnement normal des services et minimiser

l’impact négatif sur les activités métiers et s’assurer ainsi que les meilleurs niveaux de

qualité de service et de disponibilité sont maintenus.2

Le « fonctionnement normal des services » s’entend ici comme le fonctionnement des

services dans les limites des Contrats de Niveaux de Service (SLAs).

Clients de l’organisme

Les « Clients » externes du centre sont les référents GID.

Les référents GID sont des ressources relevant des Trésoreries Ministérielles, Provinciales et

Préfectorales, ils sont chargés de promouvoir le système GID au niveau des ordonnateurs. Les

ordonnateurs étant des acteurs de la dépense publique et par conséquent des utilisateurs du

système GID.

Il existe 124 référents au niveau du territoire national.

Etape 2: Identification des processus

Cycle de vie fonctionnel

Le cycle de vie de l'incident est :

Détection et enregistrement

Classification et support initial

Investigation

Résolution

2 Bibliothèque ITIL V2


Clôture

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 s’appellent « Logiciels de gestion des services

d’assistance » (Issue tracking systems).

Le centre d’assistance GID utilise le logiciel JIRA.

JIRA est un système de suivi de bugs, un système de gestion des incidents, et un système de

gestion de projets développé par Atlassian Software Systems. Il a remplacé l’outil OTRS au

niveau de l’entité GID. Il permet, entre autres, de signaler les anomalies et suivre leur

résolution ainsi que d’assurer une traçabilité de tous les échanges.

Atlassian propose JIRA gratuitement pour les projets open source et les organisations non

commerciales ainsi qu’une réduction de 50% pour les licences universitaires. À partir de la

version 3.13, une licence personnelle gratuite est aussi disponible pour un usage non-

commercial. Cette licence n'inclut pas le support de l'application par Atlassian, et est limitée à

trois utilisateurs.

En raison de sa licence gratuite pour les projets open source, plusieurs groupes de

développeurs ont adopté JIRA pour leurs projets comme JBoss, Spring Framework et

OpenSymphony.

Demandes dans JIRA

Les demandes d’assistance reçus par le centre d’assistance sont tous enregistrées dans la base

de données du système JIRA.

Etant les interlocuteurs directs du centre d’assistance, les référents peuvent interagir avec le

système et créer des demandes d’assistance, chaque demande suit une procédure de réalisation

selon son type et son degré de complexité.

Types de demandes:

Incident(Bug) : Anomalie dans GID.

Correction de données : Demande de correction de données, hors corrections traitées

par le module de correction de données.

Demande d’information : Demande d’informations quelconques par un utilisateur.

Amélioration : Proposition de fonctionnalité à intégrer dans GID.

Tâche : Demande relative au référentiel et à la gestion des utilisateurs.

Analyse des différents interactions

En réalité, le troisième niveau d’assistance ne se limite pas au centre d’assistance. Il y a

d’autres entités qui pourraient intervenir dans le processus de résolution des incidents,

dépendamment de la nature de l’incident/demande.


Les acteurs de la résolution des incidents sont regroupés dans quatre équipes :

Equipe Déploiement : Au niveau du centre d’assistance, il qualifie l’incident.

Equipe Fonctionnelle : Traite les incidents transférés par le centre d’assistance.

Equipe Technique : Composée de développeurs, elle intervient pour la correction des

incidents dans le code.

Equipe Déploiement technique : Déploie les solutions élaborées par l’équipe

technique.

L'objectif de la gestion des incidents est la remise en service des applications, dans les délais

les plus courts, en minimisant l’impact sur les utilisateurs.

Le centre d’assistance prend en charge toutes les demandes reçues. Pour faire une demande au

centre d’assistance, le référent ouvre un ticket de la demande qui est reçu par le centre

d’assistance par l’intermédiaire du système JIRA. Le centre d’assistance et ouvre un projet dit

projet REQ (ou projet assistance aux utilisateurs) pour la résolution de la demande. Chaque

projet REQ est identifié grâce à un code.

Le centre d’assistance n’ayant pas une vocation technique mais plutôt métier, il arrive qu’il ne

soit pas capable de résoudre certains demandes d’assistance. C’est ici que les équipes

fonctionnel et technique interviennent dans le processus.

Une demande non résolue par le centre d’assistance est transférée à l’équipe fonctionnelle qui

ouvre à son tour un nouveau projet dit projet SGID (système GID) concernant la demande,

l’équipe déploiement (qui dépend directement du centre d’assistance) crée un lien entre ce

projet SGID et le projet REQ correspondant, ce dernier reste ouvert jusqu'à la résolution de

l’incident.

L’équipe technique se charge de la résolution technique des incidents qui nécessitent une

correction dans le code source du système, l’équipe déploiement technique déploie les

solutions élaborées par l’équipe technique.

Figure 3: Interaction REQ/GID

Il est nécessaire de signaler que les différents projets sont organisés par files ; Une file est une

composante bien définie d’un projet d’assistance et qui peut entrer dans la composition de

plusieurs projets.

Les files qui interviennent dans les projets d’assistance sont :

Projet REQ

Projet SGID


Gestion des engagements.

Suivi de l’exécution.

Gestion des ordonnancements.

Gestion des régies.

Situations.

Référentiel des acteurs GID.

Module de correction des données.

Environnement de formation.

Sécurité.

Gestion des crédits.

Gestion des comptes utilisateurs.

Problèmes de connexion.

Clôture d’exercice et écriture de fin d’année.

Reprise des anciennes dépenses.

Gestion des oppositions.

Règlement.

Chargement des budgets.

Gestion des certificats SSL.

Recherche.

Autres types d’incidents.

Création de la dépense.

Reporting.

Workflows

Notre projet concerne deux workflows (processus de travail):

Le workflow de traitement des demandes d’assistance au sein de JIRA (workflow

JIRA).

Le workflow d’une demande du point de vue axes du service (workflow axes du

service).

En effet, le workflow JIRA représente à lui seul les différentes interactions entre les référents

et le centre d’assistance ainsi que les états d’une demande, mais il ne représente pas les

interactions au-delà du centre d’assistance. C’est pour ça que le deuxième workflow est

nécessaire.

Workflow JIRA

Le schéma suivant représente le processus de traitement des demandes dans JIRA


Figure 4: Workflow JIRA

On constate que le référent peut :

Lancer la demande.

Fermer la demande.

Réouvrir une demande traitée (s’il n’est pas satisfait pas le traitement de la

demande).

Workflow axes du service

Le schéma suivant, représentant le workflow des axes des services, représente les différentes

interactions entre les axes de l’assistance GID

Figure 5: Workflow axes de service

Centre d’assistance Equipe fonctionnelle

Equipe Technique Equipe Déploiement

technique


Chapitre IV

Phase de conception

33 Phase de conception

IV. Phase de conception

Etape 3 : Choix des objectifs

Caractéristiques d’un objectif :

Les objectifs doivent être choisis et non imposés, choisis directement par les décideurs eux-

mêmes sous forme de besoin exprimé. C’est à nous, maîtres d’œuvres, de formaliser ces

objectifs et les énoncer sous forme d’objectifs directement réalisables.

Selon la démarche GIMSI, un bon objectif est un objectif :

1. Mesurable : l'objectif s'exprime en fonction d'une unité de mesure

2. Borné : l'objectif est impérativement défini dans une dimension de temps

3. Réaliste : la Méthode pour l'atteindre est tout à fait plausible

4. Accessible : les moyens sont disponibles, les risques limités

5. Fédérateur : l'objectif recueille l'adhésion de la majorité

6. Constructif : l'objectif contribue à la démarche de progrès

Démarche de choix des objectifs

Collecte du besoin (Business Requirements Definition)

Ayant acquis le background nécessaire sur l’aspect métier pendant les deux premières phases,

nous pouvons entamer la collecte directe du besoin.

Pour le faire, il faut faire des Interviews et des réunions avec des acteurs clés du métier

Voir l’annexe « liste de réunions » pour consulter la liste des réunions de collecte du besoin.

La connaissance et l'interview des acteurs métiers est un élément tout aussi important que

l’étude de l’environnement. Afin de mener bien cette tâche, il a faudra tout d'abord bien

connaître l'organigramme de l'entreprise et savoir les rôles de chacun au sein de l’organisme.

Si on ne connaît 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 détecter les enjeux de chaque acteur,

c’est nécessaire vu que ça fournit une idée sur le degré d’implication et de fédération à

l’objectif de chacun.

Formulation du besoin

Le besoin exprimé par le centre d’assistance peut être résumé en:

Le besoin exprimé par le centre d’assistance concerne le temps de réactivité du centre vis-à-

vis des demandes reçues. En effet, le centre d’assistance joue un rôle fondamental dans la

résolution de tous genres de problèmes rencontrées par les utilisateurs du système GID et doit

répondre le plutôt possible aux demandes d’assistance reçues vu l’importance cruciale du

système GID pour l’exécution de la dépense publique et par conséquent pour l’économie ainsi

que pour la stabilité du pays.


Par conséquent, un besoin de la mesure de la performance du centre d’assistance s’impose

afin de piloter d’une manière efficace l’activité du centre et de détecter d’éventuels

dysfonctionnements pour les améliorer par la suite.

L’efficacité du service offert par le centre d’assistance peut être mesurée sur deux aspects :

Le temps de réponse du centre aux demandes (ou temps de réactivité du centre).

La qualité des solutions offertes par le centre.

Notre projet s’intéresse au premier aspect : La réactivité du centre d’assistance. C’est le sujet

principal d’analyse.

Les workflows concernant la demande d’assistance nous permet de savoir les actions liées à

chaque demande, le rôle de chaque acteur au sein du processus ainsi que d’identifier les

différentes intersections/ identifications pour évider la redondance (cas d’un workflow

concernant plusieurs objectifs).

Le tableau suivant résume ces aspects :

Thème d’analyse Workflow Acteurs

Réactivité du centre

d’assistance

Workflow JIRA.

Workflow axes de

service.

Centre d’assistance, axe

déploiement, axe

fonctionnel, axe

technique, référent.

Etape 4 : Construction du tableau de bord

Le tableau de bord est le moyen qui permet à l’utilisateur du système décisionnel d’interagir

avec ce dernier, il représente les différents indicateurs nécessaires pour le pilotage de

l’activité. Cette étape traite la construction un tableau de bord "passeur de sens" pour une

assistance efficace à la prise de décision.

Un tableau de bord GIMSI est un tableau de bord dit « at a glance », cela veut dire qu’il doit

offrir une idée sur la situation d’un premier coup d’œil. De plus, le tableau de bord doit être

capable de répondre à ces trois questions :

Quoi?: Que se passe-t-il?

Pourquoi?: Pourquoi cela se passe-t-il ainsi?

Comment?: Comment dénouer la situation afin de revenir à un état sous contrôle?

Afin d’assurer que ces aspects soient vérifiés, nous avons opté pour un tableau de bord ayant

les caractéristiques suivantes:

Facilement accessible et utilisable: Ne nécessitant aucun savoir informatique

spécifique.


Interactif : Les rapports générés ne sont pas typiques, mais plutôt construits

directement par les utilisateurs grâce à une interface graphique facile à utiliser.

Accès à distance : accès par interface web à partir des terminaux des utilisateurs.

Accès personnalisé : accessible à travers un compte pour chaque utilisateur.

A doit d’accès différents : Chaque utilisateur a accès aux données le concernant.

Restitution: Représentation de résultats sous forme de tableaux et de graphes de

différents types.

Le schéma suivant résume les fonctions qu’un tableau de bord GIMSI doit remplir :

Figure 6: Fonctions du tableau de bord3

Le succès de cette étape dépend largement de l’étape suivante, celle du choix des indicateurs.

Les détails concernant la construction technique du tableau de bord se trouvent au niveau du

chapitre suivant.

Etape 5 : Choix des indicateurs

Caractéristiques des KPI

La définition GIMSI d’un 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 braquées sur un aspect critique de la performance

globale de l’organisation. »4

Pour en faciliter l'utilisation et mieux en cerner l'usage il est habituel de classer les indicateurs

selon 3 catégories en relation avec le type d'information transmise et les attentes des

décideurs.

Indicateurs d'alerte Ce type d'indicateur de type tout ou rien, signale un état anormal

du système sous contrôle nécessitant une action, immédiate ou non. Un franchissement

de seuil critique par exemple entre dans cette catégorie d'indicateur.

Indicateurs d'équilibration Ce type d'indicateur étroitement lié aux objectifs est un peu

la boussole du décideur. Il informe sur l'état du système sous contrôle 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 réviser ?

Les KPI doivent :

Directement choisis par le(s) décideur(s), ou tirés directement des besoins exprimés par ces

derniers.

Appartiennent à ceux qui l’utilisent : Pour que le tableau de bord remplisse bien ce rôle de

réducteur de risques, il est important que le décideur ou le groupe de décideurs aient foi dans

les indicateurs présentés. Car c'est surtout en exploitant son intuition que l'on prend les

meilleures décisions. Les indicateurs seront choisis par les utilisateurs.

En relation avec le champ d’action du décideur : Il ne peut exister sur un tableau de bord

d'indicateurs importants, peut-être au niveau de l'entreprise, mais inopérants au niveau local.

Si le décideur ou l'équipe ne dispose pas des moyens d'action ou ne se sent pas préoccupé 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 réelle et claire de l’existant : à remplir

Pas très nombreux : Les indicateurs sont nécessairement en nombre restreint. De 4 à 10

indicateurs sont en général bien suffisants pour assurer le pilotage d'une activité.

Choix des KPI

Nous avons choisi cinq KPI pour la mesure de la réactivité du centre d’assistance, ils sont à la

fois des indicateurs d’alerte (ils permettent d’alerter le décideur quand à un retard éventuel),

d’équilibration (visent à équilibrer la répartition de travail sur différents trésoreries) et

d’anticipation (puisqu’ils permettent d’anticiper la quantité de travail à partir de la

performance dans le présent) :

4 Les nouveaux tableaux de bord des managers Editions Organisation

http://www.nodesway.com/methode/nouveaux_tableaux_de_bord.htm


Réactivité globale de la demande: Mesure le temps que prend une demande pour être traitée.

Réactivité du projet REQ : Mesure le temps écoulé pour une demande dès sa réception

(ouverture du projet REQ) jusqu'à sa clôture (fermeture du projet REQ). C’est le temps

significatif pour un client extérieur du centre (le référent).

Réactivité avant la création du projet GID: Mesure le temps après ouverture du projet REQ

et avant ouverture du projet GID.

Réactivité projet GID: Mesure le temps que dure un projet GID

Réactivité après la clôture projet GID: Mesure le temps écoulé après la fermeture d’un

projet GID et la fermeture du projet REQ.

Ces 5 KPIs seront nommés respectivement: Réactivité_global, Réactivité_REQ,

Réactivité_avantGID, Réactivité_SGID, Réactivité_aprèsGID.

Ces KPIs seront calculés suivant des axes d’analyse choisies et constitueront les mesures de la

table de faits. Nous allons attaquer cet aspect dans la phase de la modélisation dimensionnelle.

Elaboration de la charte du projet et du cahier de charges

La charte du projet et la fiche du projet sont des documents nécessaires pour chaque projet,

ces documents formalisent le besoin et responsabilisent le Maître d’œuvre ainsi que le maître

d’ouvrage.

La charte du projet est projet est un document qui définit et autorise formellement un projet.

Son contenu permet d’enlever toute ambiguïté aux différents acteurs du projet. Ceux-ci

peuvent avoir des points d’intérêt différents, notamment dans les entreprises ayant une

structure matricielle projets-fonctions. Avec la charte, le projet est lié à l’organisation de

l’entreprise.

L’un des buts de la charte, signée par les différentes parties, est de donner à un directeur du

projet nommé l’autorité suffisante pour mener à bout le projet. Le sponsor, initiateur interne

du projet, est également nommé ; il doit avoir une position appropriée pour pouvoir donner

des arbitrages.

Le contenu de la charte peut détailler les thèmes suivants.

· Description du projet : nom, but et livrables, justification liée au contexte, périmètre, voire

retour sur investissement. Les projets doivent être MALINS :

utilisant des objectifs Mesurables par des indicateurs ;

ayant des buts Atteignables ;

Limités dans le temps et dans leurs périmètres ;

Intégrés à la stratégie de l’entreprise ou d’un portefeuille de projets ;

Nouveaux par rapport au réalisé de l’entreprise (sinon on parle de production) ;

Spécifiques car liés à une demande, un besoin, un marché.

Le cahier de charge est Un « cahier des charges » est un document contractuel décrivant ce

qui est attendu du maître d'œuvre (MOE) par le maître d'ouvrage (MOA).

Il s'agit donc d'un document décrivant de la façon la plus précise possible, avec un

vocabulaire simple, les besoins auxquels le maître d'œuvre doit répondre. Dans la mesure où


seul le maître d'œuvre est réellement compétent pour proposer une solution technique

appropriée, le cahier des charges doit préférentiellement faire apparaître le besoin de manière

fonctionnelle, indépendamment de toute solution technique, sauf à préciser l'environnement

technique dans lequel la solution demandée doit s'insérer. Il s'agit ainsi d'un document

permettant d'une part de garantir au maître d'ouvrage que les livrables seront conformes à ce

qui est écrit, d'autre part d'éviter que le maître d'ouvrage modifie son souhait au fur et à

mesure du projet et demande au maître d'œuvre des nouvelles fonctionnalités non prévues

initialement.

Un cahier des charges doit également contenir tous les éléments permettant au maître d'œuvre

de juger de la taille du projet et de sa complexité afin d'être en mesure de proposer une offre

la plus adaptée possible en termes de coût, de délai, de ressources humaines et d'assurance

qualité.

Il s'agit à ce titre d'un document de référence, permettant de lever toute ambiguïté sur ce qui

était attendu, ainsi qu'un outil de dialogue permettant au maître d'œuvre d'interroger le maître

d'ouvrage afin d'affiner sa compréhension de la demande. Un cahier des charges n'est pas pour

autant nécessairement statique. Son contenu peut tout à fait être modifié au cours du projet,

même si dans l'idéal tout devrait être défini dès le début, 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 modèle « Volere ».

Etape 6: Collecte des informations

Maintenant que le besoin est connu, il faut commencer par construire le cœur de tout système

de reporting, le datawarehouse.

Pour le faire il faut :

Faire une analyse multidimensionnelle afin d’identifier les différents dimensions et

mesures dans le datawarehouse.

Modéliser le datawarehouse grâce à un schéma de modélisation de datawarehouse

(Datawarehousing).

Etudier les sources de données qui vont alimenter le datawarehouse.

Etablir un mapping entre les données sources et les champs du datawarehouse.

Concevoir des algorithmes pour alimenter la table de faits.

Modélisation multidimensionnelle

La modélisation dimensionnelle structure les données d'une façon très différente de la

structure en 3FN (3ème forme normale) fréquemment utilisée par les modélisateurs des

systèmes OLTP. La modélisation dimensionnelle produit ce qu'on appelle le modèle

dimensionnel.


Définitions

Une dimension est un ensemble de données du même type, permettant de structurer la base

multidimensionnelle. Une dimension est parfois appelée un axe. Temps, pays, produit sont

des dimensions classiques.

Un fait est une donnée observable que l'on possède sur un sujet et que l'on veut étudier, selon

divers axes d'analyse (les dimensions).

Les « faits », dans un datawarehouse sont normalement numériques, puisque d'ordre

quantitatif.

Une mesure est un hypercube, le plus souvent de type entier ou décimal, structuré par des

dimensions.

Dimensions et faits

Une dimension correspond à un axe d’analyse de la problématique du projet, elle est

nécessairement un facteur dont dépend l’aspect que l’objectif du projet essaye de mesurer.

A chaque dimension est attribuée 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 indépendante de ces attributs.

Les tables de faits représentent des associations dont l’existence d’une occurrence dépend

de l’existence des occurrences correspondantes dans les tables dimensionnelles, c’est-à-

dire la table de fait contient l’ensemble des mesures correspondant aux informations de

l’activité à analyser. Mais rappelons que certaines tables de faits peuvent contenir aucun

attribut et représentent que des liaisons entre tables dimensionnelles.

Tous les éléments qui pointent sur la table de faits sont liés à une sémantique exprimable

par une phrase. Par conséquent, la table de faits est la matérialisation d’une association

entre n entités.

Les caractéristiques d’une table de faits sont :

Une table de faits contient les valeurs numériques de ce qu’on désire mesurer

(mesures).

Une table de fait contient les clés associées aux dimensions. Il s’agit des clés

étrangères dans la table de faits;

En général une table de fait contient un petit nombre de colonnes;

Une table de fait contient plus d’enregistrements qu’une table de dimension;

Les informations dans une table de fait sont caractérisées par :

Elles sont numériques et sont utilisés pour faire des opérations.

Les données doivent être additives ou semi-additives.

Toutes les colonnes représentant les faits dans la table de fait doivent référer et

avoir un lien direct aux clés de dimensions dans la même table;

Pour détecter la/les table(s) de fait(s), il faudra se servir des éléments recueillis lors de la

phase précédente, notamment les workflows et les objectifs. Il faudra donc pour chaque

workflow se demander quels sont les éléments dont on souhaite mesurer la magnitude (il faut

répondre à la question : Qu'est-ce qu'on mesure ?). Les objets qui entrent en jeu dans l’activité

représentée par le workflow constituent eux les dimensions.


Dimensions retenues

Les axes d’analyse que nous allons insérer dans notre modèle sont :

Le temps.

La file de projet.

La trésorerie de laquelle la demande provient.

Direction régionale (DR) de laquelle la demande provient.

Assigné chargé de la résolution de la demande.

La priorité de demande.

Le type de demande (types JIRA).

Pour ces axes d’analyse correspondent respectivement les dimensions suivantes :

dim_date.

dim_file.

dim_Trésorerie.

dim_DR.

dim_Membre.

dim_priorité.

dim_type.

dim_demandes.

Mesures retenues

Les mesures retenues dans notre table de faits sont les KPI déjà définis dans l’étape

précédente :

Réactivité_global.

Réactivité_REQ.

Réactivité_avantGID.

Réactivité_aprèsGID.

Réactivité_SGID.

Schéma multidimensionnel

Schémas de modélisation

Il existe trois schémas de modélisation largement utilisés pour modéliser les datawarehouse.

En termes Merise, ces schémas sont les MPD (Modèle physique de données) de la base de

données décisionnelle (datawarehouse).

Schéma en étoile (Star schema) : Arrangement de tables dans une base de données

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 modèle conceptuel de données permet

de retrouver cette forme en étoile.


Schéma en constellation (Constellation schema) : C’est un schéma constitués de

schémas en étoiles ayant des dimensions en commun.

Schéma en flocons de neige (Snowflake schema) : Le schéma en flocons de neige est

une variante du schéma en étoile. Dans la théorie la différence réside dans la simple

normalisation des tables de dimensions. Il est donc tout simplement question de mettre

les attributs de chaque niveau hiérarchique dans une table de dimension à part.

Figure 7: Exemple d’un schéma en étoile

Figure 8: Exemple d’un schéma en flocons de neige

Choix du schéma de modélisation

Nous avons choisi le schéma de modélisation en étoile pour les raisons suivantes :

C’est un schéma stable.

Limite le nombre de jointures.

Optimise les requêtes des utilisateurs.

Intègre facilement de nouvelles demandes des utilisateurs.

Simple à créer et intuitivement compréhensible par les utilisateurs finaux.

En termes Merise, le MPD est à lui seul utilisé pour modéliser les datawarehouses.


Nous avons réalisé les schémas de modélisation avec le logiciel PowerAMC.

Power AMC est un logiciel de modélisation. Il permet de modéliser les traitements

informatiques et leurs bases de données associées. 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 commercialisée par Sybase sous la

marque PowerDesigner. PowerAMC supporte différents types de modèles de bases de

données.

Le Modèle Physique des Données (MPD) décrit « les structures de données telles qu’elles

sont enregistrées sur les supports physiques »5. C’est le modèle « final», et sa structure dépend

étroitement de l’environnement matériel et logiciel d’exploitation des bases de données.

Voici le modèle physique de notre datawarehouse (schéma en étoile).

Figure 9 : Modèle en étoile du Datawarehouse

Etude des données sources

Nous avons constaté que la base de données du système de suivi des incidents JIRA contient

la plupart des données nécessaires pour charger le datawarehouse. Pour les données restantes,

étant invariables avec le temps, nous les avons stockés au niveau de fichiers Excel avant de

les charger grâce aux transformations.

Base de données JIRA

La base de données du système JIRA contient toutes les données relevant d’une action

réalisée dans le système, JIRA stocke toutes les données relatives à un projet ou une demande

donnée afin d’assurer la traçabilité des projets et pour documenter l’activité du service.

5 A. Flory, « Bases de Données, conception et réalisation », Economica 1987.


Afin d’avoir une vue claire de la base de données JIRA, il faut absolument faire une

modélisation de cette base. Nous avons créé un modèle partiel de la base grâce à l’outil

MySQL Workbench.

MySQL Workbench est un outil de conception visuelle des bases de données, il intègre le

développement SQL, l’administration et la conception et la création des bases de données

dans un seul environnement de développement intégré pour les bases de données MySQL.

Nous avons utilisé MySQL Workbench version 5.2 Community Edition.

La base de données JIRA est une base de données relationnelle gérée par Oracle (Version 10g

Express) ordonnée selon 105 tables, nous avons retenu dans notre modèle partiel 20 tables qui

seront d’utilité pour notre projet.

Figure 10: Modèle partiel de la base de données de JIRA

Nous allons présenter les tables les plus utilisés de la base de données JIRA:

Table jiraissue

La table la plus utilisée de la base de données est la table jiraissue, elle contient les

enregistrements de chaque incident traité, elle est liée à plusieurs autres tables.


La clé primaire de la plupart des tables est un numéro qui est invisible pour les utilisateurs.

Le tableau ci-dessous représente les champs de la table jiraissue :

Colonne Description Clé étrangère vers

Id

Pkey

Project

Clé primaire, interne à la table

et connue à seulement à

l’utilisateur chargé du projet.

Project.id

Reporter Rapporteur de l’incident -

Assignee Personne affectée à la

résolution

-

Issuetype Type de la demande Issuetype.id

Summary Résumé de la demande -

Description Description de la demande -

Environment Environement de la solution -

Priority Priorité de la demande Priority.id

Resolution Résolution de la demande Resolution.id

Issuestatus Statut actuel de la demande Issuestatus.id

Created Création de la demande -

Updated Mise à jour de la demande -

Duedate Date limite -

Votes Votes JIRA -

Timeoriginalestimate Estimation initiale -

Timeestimate Estimation du temps -

Timespent Temps écoulé pour la résolution -

Workflow_id Workflow Os_wfentry.id

Security Niveau de sécurité SchemeIssueSecurityLevels.i

D

Fixfor Deprecated -

Component Deprecated -

Les champs timeoriginalestimate, timeestimate et surtout time_spent aurait été d’une grande

utilité pour notre projet et aurait facilité largement la tâche d’extraction des données sources,

mais ce champ étant vide pour la plupart du projet. Nous devons rechercher les données

temporelles dans d’autres tables de la base de données JIRA.

Autres tables communes

Historique de modifications

Les tables changegroup et changeitem stockent l’historique des changements. Une entrée

indique une ensemble de changements d’un ou de plusieurs champs qui ont eu lieu a même

moment. Le changement dans chaque champ individuel est décrit dans changeitem, de

plusieurs est décrit dans changegroup. Donc la relation entre ces deux tables est une relation

(1,n). La relation à la table jiraissue est réalisée à travers changegroup.issueid.

Work Log


La table worklog suit le temps de connexion d’un compte à un incident donné de chaque

compte d’un assigné. La relation avec jiraissue est à travers worklog.issueid.

Attributs d’un incident

Les tables resolution, issuestatus, issuetype et priority fournissent le nom et les métadonnées

concernant les états de résolution, les statuts, les types et des priorités des demandes.

Projets et catégories de projets

Les tables project et projectcategory décrivent les projets JIRA et leurs catégories. La table

nodeassociation est une table non normalisée contenant le lien entre les projets et les

catégories de ces derniers.

Composants de projet

La table component définit les composants du projet, la table nodeassociation contient les

liens entre les composants et les demandes.

Membres de groupes

La table membershipbase définit les membres de chaque groupe de JIRA.

Liens

Les tables issuelink et issuelinktype décrivent les liens entre les différents demandes et

incidents dans JIRA.

Quant au contenu des tables de la base de données JIRA (ainsi que celui du datawarehouse

localement hébergé). Nous avons utilisé l’éditeur de base de données Oracle SQL Developer

pour le consulter. Nous avons utilisé cet outil aussi pour créer le datawarehouse et le

éventuellement le modifier, ainsi que des bases de données tests tout au long de notre travail

.

Oracle SQL Developer est un EDI (Environnement de développement intégré) pour faire du

SQL sur les bases de données 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 données non Oracle. Oracle SQL Developer fonctionne avec IBM

DB2, Microsoft Access, Microsoft SQL Server, MySQL, Sybase Adaptive Server, et les bases

de données Teradata.

La version utilisée pour le projet est Oracle SQL Developer Version 2.1.1.64.

Autres sources de données

Les données suivantes ne se trouvent pas au niveau de la base de données JIRA :


Les directions régionales et les trésoreries desquelles proviennent les demandes, ainsi

que les types de ces trésoreries (s’il s’agit de trésoreries ministérielles ou

préfectorales).

Les référents qui ouvrent les demandes.

Ces données étant importants pour le pilotage de l’activité, il fallait les extraire d’autres

sources de données. Nous avons stocké ces données disponibles sur d’autres supports dans

deux fichiers Excel : dr.xls et referent.xls.

Mapping

L’opération du mapping consiste à faire la correspondance entre les données sources et les

champs du datawarehouse afin de charger correctement ce dernier. C’est l’étape précédente

(étude des données sources) qui nous permettra de mener à bien cette étape

Cette opération présente des difficultés vu que les données contenues dans des champs JIRA

ne portent aucune valeur informationnelle pour l’utilisateur, dans ce cas il faut pointer sur

d’autres tables contenant les données utiles. Cette opération se fait grâce à un composant look

up.

Les tables ci-dessous montrent le mapping pour les différents champs (les champs avec (p)

sont les clés primaires des tables) :

Table dim_demandes

Champ datawarehouse Champ source Table source Table Look

Up

Champ Look

Up

code_demande ID Jiraissue - -

type_demande issuetype_ID Jiraissue Issuetype pname

reporter_demande Reporter Jiraissue - -

assigne_demande Assignee Jiraissue - -

priorite_demande Priority_ID Jiraissue Priority pname

resolution_demande Resolution_ID Jiraissue Resolution pname

file_demande Source_node_i

d

nodeassociatio

n

Dim_demand

e

No_demande_i

d

projet_demande_key Pkey Jiraissue - -

date_resolution_deman

de

Resolutiondate Jiraissue - -

date_creation_demande Created Jiraissue - -

status_demande Issuestatus_ID Jiraissue Issuestatus pname

no_demande_id (p) - - - -

projet_demande Project_ID Jiraissue Project pname

code_demande_liee ID jiraissue linktype ID

nom_demande_liee ID jiraissue linktype source


Table dim_type

Champ

datawarehouse

Champ source Table

source

No_type_id(p) - -

Code_type ID Issuetype

Type_demande Pname Issuetype

Table dim_membre

Champ

datawarehouse

Champ source Table source

No_membre_id(p) - -

Code_membre ID Membershipbase

Nom_membre User_name Membershipbase

Table dim_priorite

Champ

datawarehouse


No_priorite_id(p) - -

Priorite Pname Priority

Code_priorite Sequence Priority

Table dim_file

Champ

datawarehouse


Code_file ID Component

Nom_file Cname Component

No_file_id(p) - -

Code_projet Project Component

Table dim_DR

Champ

datawarehouse


Code_dr Code DR.xls

Nom_dr DR DR.xls

No_dr_id(p) - -


Table dim_referent

Champ datawarehouse Champ source Table source Champ Look

Up

Table Look

Up

Code_referent/tresorerie Code Referent.xls - -

Nom_referent Rapporteur

JIRA

Referent.xls - -

Tresorerie_referent Trésorerie Referent.xls - -

No_referent_id (p) - - - -

Type_tresorerie_referent DR/TM Referent.xls - -

No_dr_id Code Referent.xls Code DR.xls

Jiradb_nom_referent Nom Référent

jiradb

Referent.xls - -

Pour la table dim_date, la structure de que nous avons adopté pour cette table est celle adoptée

par l’entité GID. Une procédure SQL interne à l’entité GID permet l’alimentation de la table

dim_date.

Table de faits : Algorithme et calcul

La table de faits contient, à côté des clés étrangères la liant aux tables de dimensions, les

mesures.

Les mesures sont calculables à partir des dimensions et de leurs attributs, grâce à des

programmes.

Nous allons présenter les algorithmes permettant le calcul de chacune des dimensions :

Réactivité_global: C’est la différence temporelle entre la date de résolution de la demande et

la date de création de la demande.

Réactivité_REQ: Il y a deux cas ;

Cas ou le projet REQ n’est pas lié à un projet SGID : C’est la différence entre la date

de résolution de la demande et la date de création de la demande pour les projets REQ

non liés à un projet SGID.

Cas ou le projet REQ est lié à un projet SGID : C’est la différence entre la date de

résolution de la demande et la date de création de la demande pour les projets REQ, en

tranchant le temps consommé par le projet SGID.

Réactivité_avantGID: C’est la différence temporelle entre la date de création du projet SGID

et la date de création de la demande.

Réactivité_aprèsGID: C’est la différence temporelle entre la date de résolution de la demande

et la date de résolution du projet SGID.

Réactivité_SGID :C’est la différence temporelle entre la date de résolution du projet SGID et

sa date de création.


Il faut prendre en considération les contraintes d’anomalies de workflow lors de l’élaboration

des programmes de calcul des mesures (comme par exemple la fermeture du projet REQ

avant le projet SGID correspondant).

Etape 7 : Système du tableau de bord

La démarche GIMSI donne une grande importance au partage de la connaissance et à

combattre l’isolement du décideur. Le processus de prise de la décision doit répondre au

principe de l’intelligence collective et doit impliquer tous les acteurs pour qu’ils soient

motivés et par conséquent s’investissent dans la réalisation des objectifs souhaités.

Pour un partage de la connaissance et une prise de décision décentralisée, nous avons eu

l’idée de créer des tableaux de bord destinés au personnel de la TGR participant dans le

processus de résolution des incidents. Ces tableaux seront aussi alimentés par le

datawarehouse conçu, mais les données restituées à chaque membre de l’équipe seront les

données qui concernent les tâches au niveau desquelles il a intervenu, et n’aura pas accès aux

données concernant ses collègues. Des schémas et des cubes seront créés spécifiquement pour

usage personnel de chaque membre.

Cette opération permet à chaque membre de contrôler sa performance et de l’améliorer par la

suite ainsi que bien répartir son travail ainsi que partager implicitement la connaissance des

problèmes et la conscience d’éventuels retards. Cela permettra aux membres de bien apprécier

les problèmes rencontrés, de participer à la prise de la décision ainsi que de s’investir dans

d’éventuels plans d’ajustement.


Chapitre V

Mise en œuvre

51 Mise en œuvre

V. Mise en œuvre

Etape 8 : Choix de l’outil décisionnel

Cette étape s’intéresse du choix de l’outil décisionnel à utiliser. Cette étape est d’importance

capitale vu que le marché de la Business Intelligence est en pleine effervescence et que

beaucoup d’outils sont disponibles sur le marché. Ce dynamisme est d'autant plus vrai pour

les outils logiciels décisionnels de tableaux de bord. Dans tous les cas, la technologie de la

Business Intelligence, dans sa déclinaison Informatique Décisionnelle, est tout à fait

opérationnelle.

La mise en œuvre d'un véritable outil d'assistance à la décision est actuellement plutôt une

question de méthode que de puissance des progiciels décisionnels proposés par le marché. Ce

propos est aussi vrai pour les produits propriétaires 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 sélectionner l'outil le plus adéquat aux besoins exprimés,

désormais connus grâce aux étapes préalables du déroulement du projet, et d'anticiper sur les

besoins à court et moyen terme.

Le choix de l’outil décisionnel doit prendre en considération :

La qualité gestion des données.

L’ergonomie d'utilisation.

La facilité de développement.

La capacité de déploiement.

La sécurité.

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 données du

système GID (notamment celle de JIRA), pour ne conserver que celles qui nous seront

utiles par la suite.

L’alimentation du datawarehouse par ces informations qui nous seront utiles.

Création et définition d’un ensemble de cubes, dimensions et hiérarchies.

Une interface, via laquelle on peut interroger les cubes crée, y extraire les informations

voulues et les afficher, selon le besoin, sous plusieurs formats possibles (diagrammes,

tableaux croisés…).

Le Pentaho BI Suite est l’une des offres logicielles les plus complètes pour la réalisation de

projet BI. Nous allons consacrer cette partie à la présentation de cet outil choisi par l’équipe

GID pour la réalisation des projets décisionnels.

Pentaho BI Suite permet de couvrir les domaines principaux d’un projet de Business

Intelligence et ceci au travers de différents logiciels appartenant à Pentaho ou intégrables dans

l’offre de l’éditeur.

Pentaho BI Suite est une suite logicielle Open source d’informatique décisionelle avec des

capacités intégrés d’ETL, 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 présente assez peu de différences fonctionnelles par rapport à la version EE

et peut donc être utilisée en production pour la gestion complète d'un système d'information

décisionnel.

La différence essentielle entre ces 2 versions porte principalement sur le support éditeur

auprès de Pentaho dans la version EE.

Pentaho utilise un modèle d’abonnement éliminant les frais de licence. Sous ce modèle

d’abonnement, Pentaho fournit le support, des services et des améliorations du produit en

contrepartie d’un abonnement annuel.

Pentaho BI suite comprend plusieurs composants logiciels, chaque composant permet de

traiter une partie du projet BI. Le tableau suivant présente les composants du la suite Pentaho :

53 Mise en œuvre

Produit Description

Pentaho Data Integration Le Pentaho Data Integration, dont le nom de code est

Kettle, consiste en un noyau moteur ETL, ainsi que des

applications à interface graphique d’utilisation permettant

à l’utilisateur de définir les jobs et les transformations.

Pentaho Analysis Services 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

spécifications de l’interface OLAP4J.

Pentaho Reporting Pentaho Reporting est composé d’un noyau moteur de

reporting, capable de générer des rapports basés XML.

Plusieurs outils ont été développés autour du moteur de

reporting, notamment des designers à interface graphique

guidant l’utilisateur dans le processus de création de

rapports en utilisant seulement des outils graphiques.

Pentaho Data Mining Pentaho Data Mining (Nom de code: Weka) est un

ensemble d’outils pour le data mining. Ses règles de

classification, de régression et d’association ainsi que ses

groupes d’algorithmes permettent de faite l’analyse de

l’existant ainsi que l’analyse prédictive.

Pentaho DashBoard Pentaho Dashboard est une plateforme intégrée qui offre

une vue globale des données, l’utilisateur peut voir toutes

sortes de rapports interactifs, de graphes et de cubes crées

par les outils Pentaho tel que le Pentaho Report Designer.

C’est aussi une interface tableau de bord offrant une vue

centralisée des mouvements des données du business,

ainsi permettant de les contrôler et de prendre des

décisions.

Pentaho for Apache Hadoop Pentaho for Hadoop facilite la gestion de données

intensive par l’outil Apache Hadoop et fournit des

alternatives ETL et d’analyse de données simplifies pour

les utilisateurs d’Hadoop.

Le tableau ci-dessous liste les différents composants qu’nous allons utiliser pour notre projet

par type d’activité :

Type d’activité Solution Pentaho

ETL Pentaho Data Integration (PDI).

Analyse OLAP Pentaho Analysis (Mondrian+JPivot),

Schema Workbench.

Tableau de bord Pentaho Dashboard.

Reporting Pentaho Reporting (JFree Report), Pentaho

Report Designer.

54 Mise en œuvre

Etape 9 : Déploiement et intégration

Alimentation du datawarehouse

L’alimentation d’un datawarehouse se fait grâce à un processus ETL.

Les processus ETL (Extraction, Transformation et Chargement) sont les composants les plus

critiques - et les plus importants - d’une infrastructure décisionnelle. Bien que cachés de

l’utilisateur de la plate-forme décisionnelle, les processus ETL rassemblent les données à

partir des systèmes opérationnels et les pré-traitent pour les outils d’analyse et de reporting.

La précision et la vitesse de la plate-forme décisionnelle toute entière dépendent des processus

ETL.

Les processus d’ETL (Extraction, Transformation et Chargement) regroupent plusieurs

étapes, qui ont pour objet de transférer des données depuis les applications de production vers

les systèmes décisionnels :

Extraction de données des applications et des bases de données de production (ERP,

CRM, SGBDR, fichiers, etc.)

Transformation de ces données pour les réconcilier entre les différentes sources, pour

effectuer des calculs ou du découpage de texte, pour les enrichir avec des données

externes et aussi pour respecter le format requis par les système cibles (Troisième

Forme Normale, Schéma en Etoile, Dimensions à Evolution Lente, etc.)

Chargement des données résultantes dans les différentes applications décisionnelles :

Data Warehouse ou Enterprise Data Warehouse, Datamarts, applications OLAP

(Online Analytical Processing) ou “cubes”, etc.

La latence des processus d’ETL varie du mode batch (parfois mensuel ou hebdomadaire, le

plus souvent quotidien) jusqu’au quasi-temps réel avec des rafraîchissements plus fréquents

(toutes les heures, toutes les minutes, etc.).

L’implémentation de processus d’ETL efficaces et fiables comprend de nombreux challenges.

Les volumes de données sont en croissance exponentielle, et les processus d’ETL

doivent traiter des quantités importantes de données granulaires (produits vendus,

appels téléphoniques, transactions bancaires, etc.). Certains systèmes décisionnels sont

mis à jour de façon incrémentale, alors que d’autres sont rechargés dans leur totalité à

chaque itération.

Alors que les systèmes d’information se complexifient, la variété des sources de

données s’accroît également. Les processus d’ETL doivent disposer d’une large

palette de connecteurs à des progiciels (ERP, CRM, etc.), bases de données,

mainframes, fichiers, Services Web etc.

Les structures et applications décisionnelles incluent des data warehouses, des data

marts, des applications OLAP - pour l’analyse, le reporting, les tableaux de bord, le

scorecarding, etc. Toutes ces structures cibles présentent des besoins différents en

termes de transformation de données, ainsi que des latences différentes.

Les transformations des processus d’ETL peuvent être très complexes. Les données

doivent être agrégées, parées, calculées, traitées statistiquement, etc. Certaines

transformations spécifiques au décisionnel sont aussi requises, comme les Dimensions

à Evolution Lente.

55 Mise en œuvre

Alors que le décisionnel se rapproche du temps réel, les data warehouses et data marts

doivent être rafraîchis plus souvent, dans des fenêtres de chargement toujours plus

courtes.

Mise en œuvre des processus ETL

Pour chaque table, nous allons construire une ou plusieurs transformations (selon le besoin)

basée sur les mappings et les algorithmes expliqués dans l’étape « 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 même schéma, ça dépend de la source de données et des

fonctionnalités requises (look ups par exemple).

Dim_type est un exemple d’une table nécessitant une transformation directe :

Figure 11: etl_dim_type

Les données sélectionnées sont chargés directement de la table issuetype vers la table

dim_type.

Dim_demandes est un exemple d’une table nécessitant 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 l’utilisation des look ups

pour remplir des champs (comme démontré dans les tables de mapping). Filter row filtre les

demandes REQ seulement (comme ça on n’encombre pas le datawarehouse par des données

inutiles pour le décideur et qui risquent d’atténuer les performances du système de reporting

ainsi que consommer des Go supplémentaires). Le rôle du composant « if field value is null »

est d’affecter des valeurs numériques pour les champs n’ayant 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 négatifs

par exemple).

Dim_réferent est un exemple d’une table ayant des fichiers Excel comme sources de données

57 Mise en œuvre

Figure 14: etl_dim_referent

Cette transformation est alimentée depuis deux sources Excel, le flux de données est fusionné

dans la table cible dim_referent.

Pour la table de faits, nous avons utilisé les transformations suivantes :

Figure 15: Alimentation des clés étrangères de la table de faits

Cette transformation alimente les champs des clés étrangères de la table de faits, ce sont les

champs marquant la dépendance entre cette dernière et les tables des dimensions.

58 Mise en œuvre

Figure 16: Mesures de la table de faits

Cette transformation remplit les 5 mesures, à savoir : réactivité_global,

réactivité_REQ, réactivité_avantGID. réactivité_aprèsGID. réactivité_SGID.

Le premier stream concerne les mesures 4 dernières mesures.

L’input « dim_demandes » ne sélectionne que les demandes résolues (grâce à des requêtes

écrites dans l’input). 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 numériques, il faut d’abord attribuer des valeurs numériques pour

le champ « code_demande_liee ».

Le traitement « constant » concerne les demandes ou un projet SGID a eu lieu

(code_demande_liee différent de 0).

Le traitement « constant 2 » concerne les demandes dont les projets de résolution ne passent

pas par SGID (Résolues 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 liée qui a été créé dans le SGID.

La composante « Calculator » effectue les calculs nécessaires 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 qu’on ferme le projet SGID).

Le dernier « Look up » retourne les IDs des demandes filtrés pour établir le mapping

dans Insert/Update.

Pour le deuxième traitement :

Absence du projet SGID, on a besoin du calculator pour implémenter l’algorithme et effectuer

les calculs ainsi qu’un look up pour la correspondance des demandes.

59 Mise en œuvre

Le deuxième stream calcule la mesure reactivite_global.

Analyse de données

Une fois les données stockées, nettoyées, consolidées et accessibles, elles sont utilisables.

Selon les besoins, différents types d'outils d'extraction et d'exploitation seront envisagés.

Les principaux outils d’analyse de données sont :

Analyse statistiques : Les principaux types d’analyse statistique sont ceux basés sur

l’analyse OLAP (multidimensionnelles) et le langage R.

Les arbres de décision: Un outil fort pratique lorsqu'il s'agit de répartir une population

en groupes homogènes selon des critères bien précis, appelés variables de

segmentation.

Le Data Mining.

Le Text Mining.

Nous avons choisi la technologie OLAP pour l’analyse des données contenues dans le

datawarehouse pour les raisons suivantes :

Elle permet l’analyse multidimensionnelle requise dans les spécifications du projet.

Elle permettra par la suite de générer des rapports personnalisés facilement construits

par le décideur.

C’est une technologie mise en œuvre dans le système existant.

L’OLAP

L’OLAP (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 synthèse. OLAP s'inscrit dans un système

décisionnel, également dit de gestion, qui est dédié au management de l’entreprise pour

l’aider au pilotage de l’activité en offrant une vision transversale de l’entreprise.

Ce type d'application s'oppose au traitement de transactions en ligne (anglais online

transaction processing abr. OLTP) qui s'inscrit dans un système opérationnel, c'est-à-dire

dédié aux métiers de l’entreprise pour les assister dans leurs tâches de gestion quotidiennes.

Ce terme a été défini par Edgar Frank Codd en 1993 au travers de 12 règles que doit respecter

une base de données si elle veut adhérer au concept OLAP :

1. Vue conceptuelle multidimensionnelle

2. Transparence

3. Accessibilité

4. Constance des temps de réponses

5. Architecture client-serveur

6. Indépendance des dimensions

7. Gestion des matrices creuses

8. Accès multi-utilisateurs

9. Pas de restrictions sur les opérations inter et intra dimensions

10. Manipulation aisée des données

60 Mise en œuvre

11. Simplicité des rapports

12. Nombre illimité de dimensions et nombre illimité d'éléments sur les dimensions

Ce concept a été appliqué à un modèle virtuel de représentation de donnée appelé cube ou

hypercube OLAP qui peut être mis en œuvre de différentes façons.

Un hypercube OLAP (ou cube OLAP) est une représentation abstraite d'informations

multidimensionnelles exclusivement numérique utilisé par l'approche OLAP (acronyme de

On-line Analytical Processing). Cette structure est prévue à des fins d'analyses interactives

par une ou plusieurs personnes (souvent ni informaticiens ni statisticiens) du métier que ces

données sont censées représenter.

Les cubes OLAP ont les caractéristiques suivantes :

Obtenir des informations déjà agrégées selon les besoins de l’utilisateur.

Simplicité et rapidité d’accès

Capacité à manipuler les données agrégées selon différentes dimensions

Un cube utilise les fonctions classiques d’agrégation : min, max, count, sum, avg, mais

peut utiliser des fonctions d’agrégations spécifiques

L'hypercube OLAP donne accès à des fonctions d'extraction de l'information (pour

visualisation, analyse ou traitement), et à des fonctions de requête en langage MDX

(comparable à SQL pour une base de données 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 requêtes de type OLAP.

MDX signifie "Multi-Dimensional Expressions". Microsoft a proposé le langage MDX

comme standard des interrogations multi dimensionnelles.

Les fonctions d’extraction sont :

Rotate : sélection du couple de dimensions à cibler,

Slicing : extraction d'une tranche d'information,

Scoping : extraction d'un bloc de données (opération plus générale que le slicing),

Drill-up : synthèse des informations en fonction d'une dimension (exemple de drill-up

sur l'axe temps : passer de la présentation de l'information jour par jour sur une année,

à une valeur synthétique pour l'année),

Drill-down : c'est l'équivalent d'un « zoom », opération inverse du drill-up,

Drill-through : lorsqu'on ne dispose que de données agrégées (indicateurs totalisés), le

drill through permet d'accéder au détail élémentaire des informations (voir notamment

les outils H-OLAP).

Conception des Cubes

Nous commençons par concevoir des schémas. Les schémas correspondent à un scénario. Le

schéma contient plusieurs cubes pour l’analyse des différentes situations du scénario.

Les schémas conçus sont :

61 Mise en œuvre

Un schéma destiné au directeur du centre d’assistance (MOA), contenant trois cubes. Le

directeur du centre a accès à toutes les données du datawarehouse.

Des schémas destinés à chaque membre du centre d’assistance : Dans le cadre de la démarche

GIMSI, démarche favorisant une approche coopérative de prise de décision, nous avons

décidé de concevoir des cubes pour les membres du centre d’assistance pour que chacun

d’eux peut avoir une vue de leur performance et l’améliorer par la suite. Cependant, l’accès

sera filtré de telle sorte que chaque membre du personnel ne peut accéder qu’aux données

relatives à son activité.

Les cubes destinés au directeur du centre sont :

Cube Reactivité: Contient toutes les dimensions et la mesure reactivité_global. Il s’intéresse

à la réactivité globale du centre suite à une demande.

Figure 17: Cube Reactivité

Cube RéactivitéREQ: Contient toutes les dimensions sauf que pour la dimension

dim_demandes nous avons pris en compte juste les demandes qui ont été résolues par le projet

REQ sans passer par un projet SGID, il contient aussi la mesure reactivité_REQ. Ce cube

s’intéresse aux demandes résolues grâce à un projet REQ seulement.

62 Mise en œuvre

Figure 18: Réactivité_REQ

Cube ReactivitéREQSGID : Contient toutes les dimensions sauf que pour la dimension

dim_demandes nous avons pris en compte juste les demandes qui ont été résolues en passant

par un projet SGID (et bien sûr par un projet REQ). Il contient aussi les mesures

Réactivité_avantGID, Réactivité_aprèsGID et Réactivité_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 opération 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 répertoire de Pentaho User Console afin qu’il soit

consultable.

Figure 20: Pentaho User Console-Interface de démarrage

64 Mise en œuvre

Exemples de restitution

Figure 21: Analyse par Direction Régionale

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 référent selon 3 indicateurs à la fois

69 Mise en œuvre

Figure 24: Analyse par date et par trésorerie suivant 3 indicateurs à la fois

Intégration de la solution

Pour intégrer la solution, il faut :

Héberger le datawarehouse dans un serveur.

Connecter le datawarehouse au serveur JIRA.

Assurer l’accès au datawarehouse par tous les utilisateurs.

Installer l’outil Pentaho, les transformations et les cubes dans tous les terminaux des

utilisateurs.

Publication des schémas (et des cubes) concernant chaque utilisateur.

70 Mise en œuvre

Chapitre VI

Amélioration permanente

71 Amélioration permanente

VI. Amélioration permanente

Etape 10 : Audit du système

Méthode d'audit pour garantir la durabilité de la performance du système de pilotage.

Avec le temps, l'organisation évolue, les stratégies changent, les décideurs acquièrent de

l'expérience. Pour toutes ces raisons, il est prudent de s'assurer régulièrement de la cohérence

du système avec les besoins actualisés de l'organisation et les attentes des utilisateurs. Adopter

l'habitude de l'audit méthodique et périodique est vraisemblablement la meilleure solution

pour garantir la durabilité de la performance intrinsèque du système de pilotage.

En tant que stagiaires ne faisant pas partie de l’équipe décisionnel permanente de l’entité GID,

nous ne pouvons pas se charger de l’audit permanent du système, par conséquent cette étape

n’est pas traitée, strictu sensu, dans notre projet. C’est plutôt la manière dont nous avons

conçu et développé le système qui fera de lui un système susceptible d’évoluer suivant les

nouveaux besoins et capable de s’adapter au changement.

Les éléments pris en considération pendant la conception et le développement du système

sont :

Les algorithmes de calcul que nous avons utilisé sont valables pour tous genres de

projets du centre d’assistance puisque les données sources proviennent de la Base de

données JIRA au niveau de laquelle toutes les données sont stockées.

Les clés des différentes tables sont indépendants des données sources, ce qui réduit la

dépendance des données, facilite les modifications au niveau du datawarehouse et

permet de garder la traçabilité après une éventuelle modification.

L’ajout d’une nouvelle file, d’une nouvelle trésorerie ou d’un membre va être intégré

directement dans les rapports sans avoir besoin à la moindre configurer le système ou

à modifier le datawarehouse.

Le modèle une étoile permet un ajout aisé de nouvelles dimensions à partir du modèle

existant sans avoir besoin de refaire tout le modèle.

72

Conclusion

A titre de conclusion, notre stage de fin d’études au sein de la Trésorerie

Générale du Royaume nous a permis d’atteindre le but recherché. En effet, ce

stage a été pour nous une occasion sans précédent pour mener un projet dans les

bonnes pratiques du métier et aussi au sein d’un organisme suivant un mode de

management de systèmes d’informations de bonnes pratiques. Le stage a été

bénéfique sur le plan technique vu que nous avons pu maitriser la chaîne de

valeur entière d’un projet BI en utilisant un outil Open source. L’informatique

décisionnelle est un domaine très large et très prometteur avec plusieurs champs

d’application, et le fait d’être ingénieur spécialiste dans ce domaine, c’est avoir

le sens d’analyse, de conception et d’organisation, et c’est aussi avoir le sens

d’engagement envers la communauté et assumer toutes les responsabilités qui

lui ont été attribuées vu l’importance cruciale de cette discipline pour la stratégie

de l’organisme.

Pour conclure, il semble intéressant de mettre en évidence que choisir cette

vocation et devenir ingénieur en décisionnel est une bonne chose. Mais ce qui

est meilleur, c’est d’user de tout son savoir-faire dans ce domaine pour une

bonne cause qui est augmenter la qualité des services offerts par l’administration

marocaine pour assurer une fluidité des processus administratives de la finance

publique et ainsi satisfaire au flux de travail croissant que les instances

compétentes doivent régler ainsi que pousser à l’avant ce domaine des

Technologies d’Information et de Communication qui prend un place bien

particulière dans le processus de la modernisation de l’administration et de

l’économie marocaines.

73 Conclusion

Liste de figures

Figure 1: Chaîne de valeur décisionelle ................................................................................................... 9

Figure 2: Procédure 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 d’un schéma en étoile ............................................................................................. 41

Figure 8: Exemple d’un schéma en flocons de neige ............................................................................ 41

Figure 9 : Modèle en étoile du Datawarehouse .................................................................................... 42

Figure 10: Modèle partiel de la base de données 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 clés étrangères de la table de faits ......................................................... 57

Figure 16: Mesures de la table de faits ................................................................................................. 58

Figure 17: Cube Reactivité ..................................................................................................................... 61

Figure 18: Réactivité_REQ ..................................................................................................................... 62

Figure 19: Cube ReactiviteREQSGID ...................................................................................................... 63

Figure 20: Pentaho User Console-Interface de démarrage ................................................................... 63

Figure 21: Analyse par Direction Régionale .......................................................................................... 64

Figure 22: Analyse par assigné (par membre) ....................................................................................... 65

Figure 23: Analyse par référent selon 3 indicateurs à la fois ................................................................ 68

Figure 24: Analyse par date et par trésorerie suivant 3 indicateurs à la fois ........................................ 69

Figure 25: Workflow JIRA ...................................................................................................................... 93

Figure 26: Workflow axes de service ..................................................................................................... 93

74 Conclusion

Glossaire

Agrégation: Action de calculer les valeurs associées aux positions parents des dimensions

hiérarchiques. Cette agrégation peut être une somme, une moyenne, ou tout autre processus plus

complexe comme la deuxième plus forte valeur.

Aiguillage: Orientation de la demande d’un axe vers un autre.

Assistance (aux utilisateurs): Service aidant les utilisateurs à résoudre un incident ou un problème

lors de l’utilisation d’un logiciel et assurant que le client a accès à un service informatique approprié.

Attribut : Un fait décrivant 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 donnée définie 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 données

éparses.

Centre d’assistance: au service chargé de répondre aux demandes d'assistance émanant des

utilisateurs de produits ou de services

Cube: Le plus souvent, synonyme d'hypercube.

Datamart : L'ensemble des données se rapportant à un des métiers de l'entreprise. Plusieurs datamart

forment le datawarehouse de l'entreprise.

Datawarehouse : Entrepôt de données. Ce terme anglais est utilisé pour désigner l'ensemble des

informations d'une entreprise, enregistrées sous un format informatique.

Demande (d’assistance) : demande faite par l'utilisateur d'une application informatique, concernant

un incident rencontré, une évolution souhaitée, ou une mauvaise compréhension des règles de gestion.

Dimension : Un ensemble de données du même type, permettant de structurer la base

multidimensionnelle. Une dimension est parfois appelée un axe. Chaque cellule d'une mesure est

associée à une seule position de chaque dimension. Temps, pays, produit sont des dimensions

classiques.

DOLAP : Desktop OLAP. Ce terme désigne un petit produit OLAP faisant de l'analyse

multidimensionnelle en local. Il peut y avoir une mini base multidimensionnelle (façon Personal

Express), ou bien de l'extraction de cube (façon Business Objects).

DSS : Decision Support System, ou système d'information décisionnel. C'est un système

d'interrogation et de présentation des données adapté pour l'aide à la décision. Le terme français

équivalent est SIAD, ou Système d'Information d'Aide à la Décision. Un autre terme anglais est EIS,

ou Executive Information System.

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#Dimension

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#Hypercube

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#Hypercube

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#Mesure

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#Position

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 partagée. Ces cinq termes ont tous leur importance dans la définition de la

technologie OLAP.

Formule : C'est un hypercube virtuel, c'est à dire que les valeurs obtenues sont le plus souvent

calculées à la volée mais non stockée dans la base de données.

GID : Gestion Intégrée de la Dépense.

Hiérarchie : Les positions d'une dimension organisées selon une série de relations 1-n en cascade.

Cette organisation de données est comparable à un arbre logique, ou chaque membre n'a pas plus d'un

père mais un nombre quelconque d'enfants.

HOLAP : Hybrid OLAP. Désigne les outils d'analyse multidimensionnelle qui récupèrent les données

dans des bases relationnelles ou multidimensionnelles, de manière transparente pour l'utilisateur.

Hypercube : Une construction multidimensionnelle formée de la conjonction de plusieurs dimensions.

Chaque cellule est définie par un seul membre de chaque dimension.

Incident : arrêt ou dégradation d'un service.

Logiciel de gestion des services d'assistance: Logiciel applicatif qui gère les services d'assistance

dans des organisations dédiées à ce type d'activité (comme les centres d'assistance ou les cellules

d'assistance réparties.

MDB : Multidimensional DataBase. Permet le stockage, le traitement et la restitution de données

multidimensionnelles.

Mesure : Un hypercube, le plus souvent de type entier ou décimal, structuré par des dimensions.

Salaire, Prix, Quantité, Coût sont des mesures classiques.

MOLAP : Multidimensional OLAP. Ce terme désigne plus spécifiquement une technologie de

stockage cartésien. MOLAP s'oppose à ROLAP. Pour le premier, les jointures sont déja faites, ce qui

explique les performances. Dans le second, les jointures entre les tables de dimension et de fait sont

effectuées au moment de la requête.

Multicube : Une construction multidimensionnelle formée de plusieurs hypercubes partageant

certaines dimensions.

Multidimensionnel : Structure de données ayant au moins trois dimensions indépendantes.

Niveau hiérarchique : Au sein d'une hiérarchie, les positions sont en général organisées en niveaux.

Les positions d'un même niveau correspondent à une classification précise. Par exemple, on peut

concevoir une dimension "temps", pour laquelle les jours sont au niveau 1, les mois au niveau 2 et les

années au niveau 3.

OLAP : Littéralement, On-Line Analytical Processing. Désigne une catégorie d'applications et de

technologies permettant de collecter, stocker, traiter et restituer des données multidimensionnelles, à

des fins d'analyse. Une autre définition est résumée dans l'acronyme FASMI (Fast Analysis of Shared

Multidimensional Information), ou analyse rapide d'information multidimensionnelle partagée. Les

outils OLAP doivent respecter 12 règles précises que vous pouvez découvrir à cette page.

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#OLAP

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#Cellule


http://bernard.lupin.pagesperso-orange.fr/glossair.htm#ROLAP

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#FASMI

http://bernard.lupin.pagesperso-orange.fr/plus.htm

76 Conclusion

Position : Une valeur d'une dimension.

PRGID : Personne Ressource GID.

Problème: Origine d'un ou de plusieurs incidents récurrents

Processus métier: Succession imposée de tâches à réaliser concernant un métier donné.

Qualification: Désignation du type d’un incident.

RDBMS : Relational DataBase Management System. Permet le stockage, le traitement et la restitution

de données stockées dans des tables relationnelles. Son équivalent français est SGBDR, ou Système de

Gestion de Base de Données Relationnelle.

Référent : Assistants de second niveau (au niveau des Trésoreries).

Relation : Une relation entre les positions de deux dimensions distinctes permet d'effectuer facilement

des calculs à la volée pour définir de nouvelles formules.

REQ : Projet « assistance aux utilisateurs ».

ROLAP : Relational OLAP. Il s'agit d'un ou plusieurs schémas en étoile stockés dans une base

relationnelle. Cette technique permet de faire de l'analyse multidimensionnelle à partir de données

stockées dans des bases relationnelles.

Services d'assistance : Ou services support aux utilisateurs. Ce sont les services qui consistent à aider

les utilisateurs à résoudre un problème dans l'utilisation d'un logiciel.

SGBDR : Système de Gestion de Base de Données Relationnelle. Equivalent de RDBMS.

SIAD : Système d'Information d'Aide à la Décision. Equivalent de EIS.

Schéma en étoile : Arrangement de tables dans une base de données 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 modèle

conceptuel de données permet de retrouver cette forme en étoile.

Utilisateur: Personnes utilisant le système GID.

Variable : En général synonyme de mesure.

Workflow: flux d'informations au sein d'une organisation. Le terme désigne aussi la modélisation et la

gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la

réalisation d'un processus métier.


http://bernard.lupin.pagesperso-orange.fr/glossair.htm#SGBDR

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#RDBMS

http://bernard.lupin.pagesperso-orange.fr/glossair.htm#Mesure

77 Références

Références

Bibliographie

JEAN MARIE GOUARNE; Le Projet Décisionnel, Enjeux, Modèles, architecture du

Data Warehouse. Editions Eyrolles, 1997.

ALAIN FERNANDEZ; Le nouveau tableau de bord des managers ; Editions Eyrolles,

2011.

ALAIN FERNANDEZ ; l’essentiel 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 structurée 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; Présentation Analyse et conception d’un

projet BI ; 2008

RACHID BENNIS ; Cours La modélisation en étoile ; 2010-VA SIM.

Webographie

Wikipedia anglaise: en.wikipedia.org

Wikipedia française: fr.wikipedia.org

Wiki GID: wiki.gid.gov.ma

Site Web de la Trésorerie Générale du Royaume: www.tgr.gov.ma

MSDN Library (français) : 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 Références

Annexes

79 Charte de projet

Charte de projet

Conception et développement d’une solution de reporting avancé et d’analyse

multidimensionnelle afin d’étendre les capacités de l’outil JIRA au sein de l’entité GID

Noms et prénom des Stagiaires LOUTFI Ismail.

TAOUR Marouane.

Organisme d’accueil Trésorerie Générale du Royaume

Date de cette version 02 mai 2011 Version finale

Encadrant Interne (INPT) Mr. DAHCHOUR Mohammed

Mr. ZAOUIA Abdellah

[email protected]

[email protected]

Encadrant Externe (Organisme

d’accueil)

Mr. AIRROUCHTE Imade [email protected]

Distribution

Ce document devra être distribué a :

Nom Fonction

Mr. AIRROUTCHE Imade Encadrant externe du projet

Mr. DAHCHOUR Mohammed Encadrant interne du projet

Mr. ZAOUIA Abdellah Encadrant interne du projet

Mr. TIJANI Nadir Maitre d’ouvrage

80 Charte de projet

OBJECTIF DU DOCUMENT

L’objectif de ce document est d’assembler toute la documentation relative à la gestion du

projet PFE à savoir :

1. l’approche et la stratégie de réalisation du projet

2. la procédure de gestion des risques.

3. La procédure de gestion du changement.

4. le plan de communication

5. le plan de projet

DESCRIPTION DU PROJET

1. Contexte :

GID est un système budgétaire et comptable unifié et commun à l’ensemble des acteurs de la dépense

publique qui vise à atteindre les objectifs suivants :




Offrir un service de qualité aux acteurs de la dépense publique.

L’entité GID assure aussi un service d’assistance aux utilisateurs du système GID par le biais du

centre d’assistance GID, c’est le service chargé de répondre aux demandes d’assistance aux

utilisateurs et par conséquent assurer le bon fonctionnement du système et la durabilité des

transactions.

C’est ainsi qu’est né le besoin de mesure de la performance du service d’assistance. Le tableau de bord

développé doit en priorité remplir les grandes fonctionnalités suivantes :

Reporting sur le temps de réactivité du service.

Reporting sur la qualité du service.

2. Intérêt du projet :

Le projet s’inscrit dans une logique de développement durable et permet l’amélioration

continue de la qualité de service fournie par le centre d’assistance.

Mesure de la performance du centre d’assistance, identification des axes d’amélioration, prise

de décision plus pertinente concernant les processus d’assistance.

3. But du projet :

Mise en œuvre d'un système 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 d’assistance.

5. Résultats attendus

Le produit final : Tableau de bord pour le reporting listant des indicateurs concernant les

différents axes précisés par le maitre d’ouvrage.

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 données et de

processus métier, définition des objectifs, construction du tableau de bord, choix des

indicateurs, conception et alimentation du datawareshouse, conception de datamarts et de

cubes OLAP, restitution de données.

Exclusions: Choix de le solution BI, sécurité du système, audit permanent du système.

7. Contraintes de projet

Le projet doit être réalisé en 3 mois.

Le système décisionnel doit correspondre aux exigences métiers du centre d'assistance.

L'utilisation des outils techniques suivants:

SGBD : Oracle.

Suite BI: Pentaho BI Suite.

En outre le système doit vérifier :

Accès à distance à la base de données décisionnelle.

Capacité minimale de 40 Go.

Inclusion de la présentation graphique de données.

Démarche claire et méthodique du travail.

Planification du projet.

Confidentialité : Existence de données confidentielles (les données contenues dans la base de

données de JIRA).

82 Charte de projet

8. Analyse de la valeur du projet :

Objectifs stratégiques Valeur présente Valeur future Valeur ajoutée

Technologique Mapping et

Reporting se font

manuellement par

l’option de

recherche de l’outil

JIRA ou à base de

tableaux Excel.

Mapping et

Reporting plus

développés grâce

à un système

décisionnel

indépendant.

Simplification de

la recherche dans la

base de données et

création de plus

d’options.

Clientèle (référents) Reporting ne

prenant pas en

considération

l’interaction du

référent avec le

centre d’assistance.

Reporting

destiné au

référent pour ses

activités en

relation avec le

centre

d’assistance.

Meilleur service

d’assistance pour le

référent.

Organisationnel/Fonctionnel Mesure de

performance se fait

grâce au rapport

demandes

arrivés/demandes

résolues.

Nouveaux

critères à

prendre en

considération

dans la mesure

de la

performance.

Meilleur mesure et

contrôle de la

performance,

responsabilisation

des différents

acteurs.

83 Charte de projet

9. Analyse des parties prenantes

Parties prenantes Enjeux Influence Actions potentielles

Centre d’assistance

(MOA)

Gain :

Réalisation du

projet.

Développement des

processus métier et

fluidité du travail.

Perte:

Absence d’outil de

mesure de

performance pour le

centre d’assistance.

Spécification des

besoins.

Exigence de délai.

Elaboration du cahier

de charge.

Suivi du MOE quant

au respect du cahier

de charge, à la qualité

exigée et aux

livrables.

Elèves stagiaires

(MOE)

Gain:

Réussite du projet

de Fin

d'Etudes.Formation

au cycle ingénieur

d'état.

Laisser une bonne

image de soi-même

et de l'institut de

formation.

Perte:

Image de marque de

l'institut. Image de

soi-même. Perte de

temps. Mauvaises

conséquences sur le

début de la carrière

professionnelle.

Une bonne/mauvaise

réponse technique et

métier aux exigences

du cahier de charge.

Respect du cahier de

Charge.

Elaboration d'une

bonne solution

répondant aux

exigences de la charte

du projet.

Encadrants Gain:

Augmentation du

nombre d'étudiants

encadrés.

Capitalisation de

l'expérience.

Perte:

Temps et effort.

L’encadrement influe

la qualité globale du

projet.

Fournir l'encadrement

et l'assistance

nécessaires au MOE

(étudiants stagiaires).

84 Charte de projet

10. Prérequis en matière de connaissance :

-Business Intelligence (Datawarehousing, OLAP, restitution de données…)

-Conception et Gestion de bases de données

-Modélisation des processus.

-Conception de modèles de données.

-Languages requis : SQL, MDX, UML, XML, JAVA.

-Outils requis : Pentaho BI suite, Oracle, JIRA, logiciels de modélisation ( PowerAMC),

Modélisation par Merise.

STRATÉGIE DE RÉALISATION

1. Stratégie 1 : Il existe un MOE qui réalise le projet pour le compte d’un maitre

d’ouvrage, et vous autant que stagiaire PFEs, vous travailler avec le MOE.

2. Stratégie 2 : Il existe un MOE externe qui réalise le projet pour le compte d’un maitre

d’ouvrage, et vous autant que stagiaire PFEs, vous travailler avec l’équipe Interne

MOA

3. Stratégie 3 : Il existe une équipe interne qui va réaliser le projet et vous autant que

stagiaire PFEs, vous travailler avec l’équipe interne.

Stratégie de réalisation choisie

Pour le projet

La position des différentes ressources déployées

(matérielles et humaines) par rapport à l'organisme ainsi

que le rapport Pertinence/Risque très intéressant nous

pousse à choisir la stratégie de réalisation conjointe du

projet.

PROCEDURE DE GESTION DES RISQUES

Il s’agit 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 résumer toutes les activités de gestion de risque qui sont

prévues 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

Description du risques Impact du risque Mesures

préventives

Compréhension du

besoin

Mauvaise compréhension

du CDC par le MOE

Refaire le CDC Délivrer des

livrables.

Réunions

régulières avec le

MOA.

Mauvaise

conception et

spécification du

projet.

Conception/spécification

non identiques au cahier des

spécifications.

Mauvaise solution

et non compatibilité

de la solution avec

l'existant.

Utiliser un cycle

de vie en V ou en

cascade avec

feedback.

Délai Terminer plus tard que

prévu

Retarder la

soutenance du

projet.

Non disponibilité

des différents

encadrants pendant

la soutenance.

Etablir une

planification du

projet.

Panne matérielle

ou logicielle

Panne des machines ou des

environnements de travail.

Endommagement

ou perte des

fichiers.

Prévoir des copies

des fichiers et une

machine back-up

PROCEDURE DE GESTION DE CHANGEMENT

L’objectif de cette procédure est d’identifier, d’évaluer et de contrôler tout changement potentiel

pouvant impacter les réalisations planifiées. Elle comprend généralement les cinq activités de base

suivantes :

Collecter

Examiner

Proposer

Décider

Mettre en œuvre

86 Charte de projet

Identifiant Description de la modification Impact de la modification

Encadrant Changement au niveau de

l’encadrant.

Retard du travail.

Eventuel changement de la

démarche.

Outil technique (Pentaho

BI Suite)

Changement de l’outil de travail. Problèmes de compatibilité.

Version JIRA Changement de version. Pas de changement majeur, la

base de données reste la même.

PROCEDURE DE GESTION DE LA COMMUNICATION

L’objectif de cette procédure est de préparer le plan de communication du projet, il s’agit de :

–Déterminer les événements nécessitant une communication.

–Définir la personne responsable de la communication de l'information.

–Définir le public.

–Définir l’objectif de la communication.

–Définir les médias de communication.

–Définir le moment de la communication, la périodicité ou la fréquence de diffusion.

–Définir les livrables de communication.

Evénement Objectif de la

communication

Public Cibles Médias utilisés

Démarrage

d’une étape

Information des parties

prenantes.

Implication dans la

démarche.

Encadrants.

MOA.

Présentation.

Mail.

Fin d’une

étape du projet

Information des parties

prenantes.

Encadrants.

MOA.

Présentation.

Mail.

PLAN DE PROJET

Cette partie est utilisée pour décrire les éléments quand doit planifier dans le projet, il s’agit de définir

les :

Dépendances entre les phases et les tâches

Elaboration des échéanciers : date début, date fin

Le tableau suivant résume les tâches du projet :

87 Charte de projet

N°

tâche

Tâche Durée Date début Date fin

1 Documentation sur l'organisme

d'accueil

2j Mer 16/03/11 Ven 18/03/11

2 Documentation métier 4j Lun 21/03/11 Lun 28/03/11

3 Documentation Business

Intelligence

5j Lun 21/03/11 Mar 29/03/11

4 Documentation Gestion de projet 2j Lun 21/03/11 Mer 23/03/11

5 Etude benchmarking de la démarche 6,79j Mar 29/03/11 Ven 08/04/11

6 Etude de l’environnement 3j Lun 11/04/11 Jeu 14/04/11

7 Etude des processus métier 3,14j Lun 11/04/11 Jeu 14/04/11

8 Etude des enjeux et des objectifs 0,5j Ven 15/04/11 Ven 15/04/11

9 Collecte du besoin 2,36j Lun 18/04/11 Mer 20/04/11

10 Formulation du besoin 0,79j Jeu 21/04/11 Jeu 21/04/11

11 Négociation du tableau de bord 3j Mar 19/04/11 Ven 22/04/11

12 Négociation des KPI 2,36j Mar 19/04/11 Jeu 21/04/11

13 Formulation des KPI 0,64j Ven 22/04/11 Ven 22/04/11

14 Etablissement du plan du projet 3j Lun 25/04/11 Jeu 28/04/11

15 Elaboration de la charte du projet 4,57j Lun 25/04/11 Lun 02/05/11

16 Elaboration du cahier de charges 4,57j Lun 25/04/11 Lun 02/05/11

17 Modélisation multidimensionnelle 3j Lun 02/05/11 Jeu 05/05/11

18 Etablissement du schéma

multidimensionnel

1j Ven 06/05/11 Lun 09/05/11

19 Etude des données sources 8,36j Mar 10/05/11 Mar 24/05/11

20 Mapping 3j Ven 13/05/11 Mer 18/05/11

21 Conception de la table de faits 3j Jeu 19/05/11 Mar 24/05/11

22 Documentation sur l'outil BI 2j Lun 23/05/11 Mer 25/05/11

23 Processus ETL 7j Mer 25/05/11 Mar 07/06/11

24 Analyse OLAP 2,21j Mer 08/06/11 Ven 10/06/11

25 Restitution des données 2,21j Lun 13/06/11 Mer 15/06/11

26 Tests de la solution 0,79j Mer 15/06/11 Jeu 16/06/11

27 Intégration de la solution 0,79j Jeu 16/06/11 Ven 17/06/11

28 Rédaction du rapport de stage 22j Lun 09/05/11 Ven 17/06/11

88 Charte de projet

Cahier des charges

Conception et développement d’une solution de reporting avancé et d’analyse

multidimensionnelle afin d’étendre les capacités de l’outil JIRA au sein de

l’entité GID

Nous reconnaissons que ce document utilise des éléments soumis au copyright, provenant du Modèle

de cahier des charges Volere. Copyright © 1995 – 2007 the Atlantic Systems Guild Limited

Ces spécifications ont été rédigées 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 système budgétaire et comptable unifié et commun à l’ensemble des acteurs de la dépense

publique qui vise à atteindre les objectifs suivants :




Offrir un service de qualité aux acteurs de la dépense publique.

L’entité GID assure aussi un service d’assistance aux utilisateurs du système GID par le biais du

centre d’assistance GID, c’est le service chargé de répondre aux demandes d’assistance aux

utilisateurs et par conséquent assurer le bon fonctionnement du système et la durabilité des

transactions.

C’est ainsi qu’est né le besoin de mesure de la performance du service d’assistance. Le tableau de bord

développé doit répondre au besoin suivant :

- Reporting sur le temps de réactivité du service.

Objectifs du projet

Mesurer le temps de réactivité du service

Enjeu

Le temps de réactivité du service est un aspect majeur impactant la performance du centre d’assistance

et a des impacts majeurs sur l’utilisation du système GID.

Mesure de la performance

La mesure s’effectue grâce à des Indicateurs clés de performance (KPI), en vue de réduire le temps de

réactivité du centre ainsi que d’assurer une souplesse lors du transfert des demandes entre les

différents axes d’assistance.

Les parties prenantes

Maîtrise d’ouvrage :

Le centre d’assistance en la personne de son directeur Mr. TIJANI Nadir suit le projet et est amené à

décider des grandes orientations et objectifs prises lors des réunions effectués tout au long de ce stage.

Maîtrise d'œuvre :

La maîtrise d’œuvre est assurée par les deux étudiants stagiaires Mr. LOUTFI Ismail & Mr. TAOUR

Marouane.

Autres intervenants sur le projet :

Assurent l’encadrement et le suivi du projet à travers les deux étudiants stagiaires Mr. LOUTFI Ismail

& Mr. TAOUR Marouane:

Mr. AIRROUCHTE Imade, Ingénieur BI au sein de la Trésorerie Générale du Royaume.

90 Charte de projet

Mr. DAHCHOUR Mohammed : Professeur à l’Institut National des Postes et

Télécommunications.

Mr. ZAOUIA Abdellah: Professeur à l’Institut National des Postes et Télécommunications.

Utilisateurs finaux

Centre d’assistance.

Contraintes

Contraintes liées à l’environnement

Contraintes sur la solution

Contraintes techniques

Le système décisionnel doit correspondre aux exigences métiers du centre d'assistance.

L'utilisation des outils techniques suivants:

SGBD : Oracle.

Suite BI: Pentaho BI Suite.

En outre le système doit vérifier :

Accès à distance à la base de données décisionnelle.

Capacité minimale de 40 Go.

Inclusion de la présentation graphique de données.

Autres dimensions du projet

Démarche claire et méthodique du travail.

Planification de projet.

Confidentialité : Existence de données confidentielles (les données contenues dans la base de

données JIRA).

Environnement de fonctionnement du système actuel

Pentaho User Console.

Outils techniques utilisés :

Outils techniques

SGBD : Oracle 10g.

Suite BI : Pentaho BI suite.

Lieux de fonctionnement prévus

Terminaux des utilisateurs

Contraintes de calendrier

Clôture du projet le 16 juin 2011

Contraintes de budget

Néant

91 Charte de projet

Conventions de dénomination

Définitions

Aiguillage : Orientation de la demande d’un axe vers un autre.

Assistance (aux utilisateurs): Service aidant les utilisateurs à résoudre un incident ou un problème

lors de l’utilisation d’un logiciel et assurant que le client a accès à un service informatique approprié.

Bug : Erreur dans un programme informatique pouvant perturber son fonctionnement.

Client : demandeur de service.

Demande (d’assistance) : Demande faite par l'utilisateur d'une application informatique, concernant

un incident rencontré, une évolution souhaitée, ou une mauvaise compréhension des règles de gestion.

GID : Gestion Intégrée de la Dépense.

Incident : arrêt ou dégradation d'un service.

PRGID : Personne Ressource GID.

Problème : origine d'un ou de plusieurs incidents récurrents

Qualification : Désignation du type d’un incident.

Référent : Assistants de second niveau (au niveaux des Trésoreries).

REQ : Projet « assistance aux utilisateurs »

Utilisateur : Personnes utilisant le système GID.

Faits pertinents et hypothèses

Faits

Nombre de demandes gérés par jour ? (ainsi que leurs types)

Règles métier

Gestion des demandes :

Le centre d’assistance prend en charge toutes les demandes reçues. Pour faire une demande au centre

d’assistance, le référent ouvre un ticket de la demande qui est reçu par le centre d’assistance par

l’intermédiaire du système JIRA. Le centre d’assistance et ouvre un projet dit projet REQ (ou projet

assistance aux utilisateurs) pour la résolution de la demande. Chaque projet REQ est identifié grâce à

un code.

Le centre d’assistance n’ayant pas une vocation technique mais plutôt métier, il arrive qu’il ne soit pas

capable de résoudre certains demandes d’assistance. C’est ici que les équipes fonctionnel et technique

interviennent dans le processus.

Une demande non résolue par le centre d’assistance est transférée à l’équipe fonctionnelle qui ouvre à

son tour un nouveau projet dit projet SGID (système GID) concernant la demande, l’équipe

déploiement (qui dépend directement du centre d’assistance) crée un lien entre ce projet SGID et le

projet REQ correspondant, ce dernier reste ouvert jusqu'à la résolution de l’incident.

92 Charte de projet

L’équipe technique se charge de la résolution technique des incidents qui nécessitent une correction

dans le code source du système, l’équipe déploiement technique déploie les solutions élaborées par

l’équipe technique.

Etat des demandes dans JIRA:

Il y a cinq états qu’une demande peut avoir dans JIRA :

Ouverte.

En cours de traitement.

Traitée.

Réouverte.

Fermée.

Exigences fonctionnelles

Portée du projet (description de l’existant)

La situation actuelle

Reporting sur le temps de réactivité:

Pas de reporting prenant en considération la dimension temps, les informations sont tirés

manuellement en consultant le temps d’ouverture et de fermeture.

Historique de demandes:

Pas de reporting avancé sur l’historique des demandes ainsi que leur résolution

Evénements métiers :

Ouverture de la demande (Ticket).

Ouverture du projet REQ.

Qualification de la demande.

Traitement de la demande.

Création du projet SGID.

Liaison du projet SGID au projet REQ.

Transfert de la demande du centre d’assistance vers l’équipe fonctionnelle.

Transfert de la demande de l’équipe fonctionnelle vers l’équipe technique.

Résolution technique de l’incident.

Déploiement de la solution technique.

Transfert de la demande de l’équipe technique vers l’équipe fonctionnelle.

Transfert de la demande de l’équipe fonctionnelle vers le centre d’assistance.

Réponse au référent.

Réouverture par le référent.

93 Charte de projet

Liste des exigences fonctionnelles

Descriptif des processus métiers

Il faut respecter les processus métiers suivants

Workflow JIRA :

Le schéma suivant représente le processus de traitement des demandes dans JIRA

Figure 25: Workflow JIRA

Workflow axes des services :

Le schéma suivant, représentant le workflow des axes des services, représente les différentes

interactions entre les axes de l’assistance GID

Figure 26: Workflow axes de service

Centre d’assistance Equipe fonctionnelle

Equipe Technique Equipe Déploiement

technique

94 Charte de projet

Gestion de l’historique :

Stocké au niveau de la base de données JIRA.

Exigences liées à 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 affectées au projet.

Il est prévu, pendant la durée du projet :

Les stagiaires: Mr. LOUTFI Ismail, Mr. TAOUR Marouane.

Les encadrents: Mr. AIRROUCHTE Imade, Mr. DAHCHOUR Mohammed, Mr. ZAOUIA

Abdellah.

Risques

Compréhension du besoin: Mauvaise compréhension du CDC par le MOE.

Mauvaise conception et spécification du projet: Conception/spécification non identiques au

besoin.

Délai: Terminer plus tard que prévu.

Panne matérielle ou logicielle : Panne des machines ou des environnements du travail.

Coûts

Sans objet.

95 Charte de projet

Table de matières

Contenu I. Contexte général .............................................................................................................................. 8

Le projet décisionnel ........................................................................................................................... 8

Informatique décisionnelle (Business Intelligence) ........................................................................ 8

Le Projet décisionnel ....................................................................................................................... 8

Le Reporting .................................................................................................................................. 10

1. Organisme d’accueil : La Trésorerie générale du royaume ..................................................... 10

Missions de la Trésorerie Générale du Royaume .......................................................................... 10

Organisation .................................................................................................................................. 11

Entité chargée du Projet de Gestion Intégrée de la Dépense ......................................................... 11

II. Méthodologie de travail ............................................................................................................... 15

Nécessité d’une démarche de travail ............................................................................................... 15

Choix de la démarche ....................................................................................................................... 15

Etude Benchmarking ..................................................................................................................... 15

Comparaison des démarches et choix de la démarche du projet ................................................... 20

1. Adaptation de la démarche au contexte du projet ...................................................................... 20

Phase I : Identification ................................................................................................................... 21

Phase II : Conception .................................................................................................................... 21

Phase III : Mise en œuvre .............................................................................................................. 22

Phase IV : Amélioration permanente ............................................................................................ 22

Planification du projet ....................................................................................................................... 22

III. Phase d’identification ................................................................................................................ 25

Etape 1 : Environnement de l’entreprise ........................................................................................... 25

Détermination de l’organisme concerné ........................................................................................ 25

Organisation de l’assistance .......................................................................................................... 25

Procédure de la gestion des incidents ............................................................................................ 25

Objectifs stratégiques .................................................................................................................... 26

Mode de Management ................................................................................................................... 27

Clients de l’organisme ................................................................................................................... 27

Etape 2: Identification des processus .............................................................................................. 27

Cycle de vie fonctionnel ................................................................................................................ 27

96 Charte de projet

Analyse des différents interactions ................................................................................................ 28

Workflows ..................................................................................................................................... 30

IV. Phase de conception .................................................................................................................. 33

Etape 3 : Choix des objectifs ............................................................................................................. 33

Caractéristiques d’un objectif : .................................................................................................. 33

Démarche de choix des objectifs ................................................................................................ 33

Etape 4 : Construction du tableau de bord ................................................................................... 34

Etape 5 : Choix des indicateurs ...................................................................................................... 35

Caractéristiques 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

Modélisation multidimensionnelle ................................................................................................ 38

Schéma multidimensionnel ........................................................................................................... 40

Etape 7 : Système du tableau de bord ................................................................................................ 49

V. Mise en œuvre ............................................................................................................................... 51

Etape 8 : Choix de l’outil décisionnel ............................................................................................... 51

Etape 9 : Déploiement et intégration ................................................................................................. 54

Alimentation du datawarehouse .................................................................................................... 54

Analyse de données ....................................................................................................................... 59

Alimentation du tableau de bord ................................................................................................... 63

Intégration de la solution ............................................................................................................... 69

VI. Amélioration permanente .......................................................................................................... 71

Etape 10 : Audit du système .............................................................................................................. 71

Conclusion ............................................................................................................................................. 72

Références ............................................................................................................................................. 77

Bibliographie ..................................................................................................................................... 77

Webographie .................................................................................................................................... 77

Charte de projet ..................................................................................................................................... 79

DESCRIPTION DU PROJET ..................................................................................................... 80

STRATÉGIE DE RÉALISATION ............................................................................................. 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 liées à l’environnement .............................................................................................. 90

Terminaux des utilisateurs ............................................................................................................. 90

Conventions de dénomination ....................................................................................................... 91

Faits pertinents et hypothèses ........................................................................................................ 91

Exigences fonctionnelles ................................................................................................................... 92

Portée du projet (description de l’existant).................................................................................... 92

Liste des exigences fonctionnelles ................................................................................................ 93

Exigences liées à la construction de la solution ................................................................................ 94

Mise en œuvre ............................................................................................................................... 94

Risques .......................................................................................................................................... 94

Coûts .............................................................................................................................................. 94

73677630-Rapport-PFE

Documents

Transcript of 73677630-Rapport-PFE