Vous êtes sur la page 1sur 97
1 Contexte général Projet de fin d’études Conception et développement d’une solution de reporting avancé
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

2

Contexte général

« 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)

3

Contexte général

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.

vifs

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

Par

la

même

occasion,

Nous

en

profitons

pour

exprimer

nos

4

Contexte général

4 Contexte général Résumé Les tableaux de bord constituent aujourd’hui un outil incontournable de la stratégie

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.

5

Contexte général

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.

6

Contexte général

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

7

Contexte général

Chapitre I Contexte général

8

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

9

Contexte général

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

sont générés sur ces données. Le schéma suivant résume ces étapes Figure 1: Chaîne de valeur

Figure 1: Chaîne de valeur décisionelle

10

Contexte général

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

11

Contexte général

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.

12

Contexte général

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.

13

Contexte général

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

14

Contexte général

Chapitre II Méthodologie du travail

15

Contexte général

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 :

16

Contexte général

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

17

Contexte général

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.

18

Contexte général

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

19

Contexte général

1.

Identification

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

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 2 : Identification de l'entreprise Analyse des structures de l'entreprise pour identifier les processus, activités et acteurs concernés.

2.

Conception

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

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 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

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.

Comment le faire ?

La technologie est au service des utilisateurs de terrain

4.

Amélioration permanente

Etape 10 : Audit Suivi permanent du système

Le système correspond-il toujours aux attentes ?

20

Contexte général

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

Volet humain

Volet

Domaine

stratégique

financier

d’application

Balanced

Stratégie

Dirigiste: Manque

Coûteuse

Stratégie d’Entreprise

Scoreban

prédéfinie

de participation

d

(BSC)

du personnel

Navigateu

Prise en

Enquête sur le

Pas de

Gestion d’Entreprise

r

Skandia

considération

capital humain

moyens

 

des facteurs

financiers

immatériels

dans

l’élaboration de

la stratégie

GIMSI

S’adapte à toute stratégie mise en place

Coopérative :

Peu de

Pilotage

Forte implication du personnel

moyens

d’entreprise/organism

financiers

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.

21

Contexte général

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.

Tâches de l’étape

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.

Tâches de l’étape

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.

Tâches de l’étape

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

22

Contexte général

Tâches de l’étape

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.

Tâches de l’étape

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.

Tâches de l’étape

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.

Tâches de l’étape

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.

23

Contexte général

 

Tâche

Durée

Date début

Date fin

tâche

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

3j

Lun 02/05/11

Jeu 05/05/11

multidimensionnelle

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

24

Contexte général

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 :

1 er 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

26

Phase d’identification

26 Phase d’identification Figure 2: Procédure d'assistance GID C’est le premier niveau d’assistance (PRGID) qui

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.

27

Phase d’identification

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

28

Phase d’identification

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.

Le centre d’assistance GID utilise le logiciel JIRA . JIRA est un système de suivi de

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.

29

Phase d’identification

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.

Projet REQ Projet SGID
Projet REQ
Projet SGID

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 :

30

Phase d’identification

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

31

Phase d’identification

31 Phase d’identification Figure 4: Workflow JIRA On constate que le référent peut :  Lancer

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

 
 

Centre d’assistance

Equipe fonctionnelle

 
 

Equipe Déploiement technique

Equipe Déploiement technique Equipe Technique

Equipe Technique

Equipe Déploiement technique Equipe Technique

Figure 5: Workflow axes de service

32

Phase d’identification

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.

34

Phase de conception

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.

35

Phase de conception

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 :

les fonctions qu’un tableau de bord GIMSI doit remplir : Figure 6: Fonctions du tableau de

Figure 6: Fonctions du tableau de bord 3

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 :

36

Phase de conception

« 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) :

37

Phase de conception

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ù

38

Phase de conception

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.

39

Phase de conception

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.

40

Phase de conception

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.

41

Phase de conception

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.

niveau hiérarchique dans une table de dimension à part. Figure 7 : Exemple d’un schéma en

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

à part. Figure 7 : Exemple d’un schéma en étoile Figure 8 : Exemple d’un schéma

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.

42

Phase de conception

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

les schémas de modélisation avec le logiciel PowerAMC . Power AMC est un logiciel de modélisation.

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).

physique de notre datawarehouse (schéma en étoile). Figure 9 : Modèle en étoile du Datawarehouse Etude

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.

43

Phase de conception

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.

20 tables qui seront d’utilité pour notre projet. Figure 10: Modèle partiel de la base de

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.

44

Phase de conception

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

Clé primaire, interne à la table et connue à seulement à l’utilisateur chargé du projet.

Project.id

Pkey

Project

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

45

Phase de conception

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

.

des bases de données tests tout au long de notre travail . Oracle SQL Developer est

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 :

46

Phase de conception

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

Champ Look

Up

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

nodeassociatio

Dim_demand

No_demande_i

d

n

e

d

projet_demande_key

Pkey

Jiraissue

-

-

date_resolution_deman

Resolutiondate

Jiraissue

-

-

de

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

47

Phase de conception

Table dim_type

Champ

 

Champ source

Table

   

datawarehouse

 

source

No_type_id(p)

 

-

 

-

Code_type

ID

 

Issuetype

 

Type_demande

Pname

Issuetype

 

Table dim_membre

 

Champ

Champ source

Table source

 

datawarehouse

No_membre_id(p)

 

-

 

-

Code_membre

ID

 

Membershipbase

Nom_membre

User_name

 

Membershipbase

Table dim_priorite

 

Champ

Champ source

 

Table source

 

datawarehouse

 

No_priorite_id(p)

 

-

 

-

Priorite

Pname

 

Priority

 

Code_priorite

Sequence

 

Priority

 

Table dim_file

Champ

Champ source

 

Table source

 

datawarehouse

 

Code_file

ID

Component

 

Nom_file

Cname

 

Component

 

No_file_id(p)

 

-

 

-

Code_projet

Project

 

Component

 

Table dim_DR

Champ

Champ source

 

Table source

datawarehouse

 

Code_dr

Code

DR.xls

 

Nom_dr

DR

DR.xls

 

No_dr_id(p)

-

 

-

48

Phase de conception

Table dim_referent

Champ datawarehouse

Champ source

Table source

Champ Look

Table Look

Up

Up

Code_referent/tresorerie

Code

Referent.xls

-

-

Nom_referent

Rapporteur

Referent.xls

-

-

JIRA

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

Referent.xls

-

-

jiradb

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.

49

Phase de conception

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.

50

Phase de conception

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.

décisionelle avec des capacités intégrés d’ETL, de data mining, de reporting, de tableaux de bord et

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 :

d’une table nécessitant une transformation directe : Figure 11: etl_dim_type Les données sélectionnées sont

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

56 Mise en œuvre Figure 12: etl_file_demande Et une autre pour le reste des champs Figure

Figure 12: etl_file_demande

Et une autre pour le reste des champs

12: etl_file_demande Et une autre pour le reste des champs Figure 13: etl_dim_demande Cette transformation remplit

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

57 Mise en œuvre Figure 14: etl_dim_referent Cette transformation est alimentée depuis deux sources Excel, le

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 :

faits, nous avons utilisé les transformations suivantes : Figure 15: Alimentation des clés étrangères de la

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

58 Mise en œuvre Figure 16: Mesures de la table de faits  Cette transformation remplit

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

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.

à la réactivité globale du centre suite à une demande. Figure 17: Cube Reactivité Cube RéactivitéREQ

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

62 Mise en œuvre Figure 18: Réactivité_REQ Cube ReactivitéREQSGID : Contient toutes les dimensions sauf que

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

63 Mise en œuvre Figure 19: Cube ReactiviteREQSGID Alimentation du tableau de bord Pour alimenter le

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.

de Pentaho User Console afin qu’il soit consultable. Figure 20: Pentaho User Console-Interface de démarrage

Figure 20: Pentaho User Console-Interface de démarrage

64

Mise en œuvre

Exemples de restitution

64 Mise en œuvre Exemples de restitution Figure 21: Analyse par Direction Régionale

Figure 21: Analyse par Direction Régionale

65

Mise en œuvre

65 Mise en œuvre Figure 22: Analyse par assigné (par membre)

Figure 22: Analyse par assigné (par membre)

66

Mise en œuvre

66 Mise en œuvre

67

Mise en œuvre

67 Mise en œuvre

68

Mise en œuvre

68 Mise en œuvre Figure 23: Analyse par référent selon 3 indicateurs à la fois

Figure 23: Analyse par référent selon 3 indicateurs à la fois

69

Mise en œuvre

69 Mise en œuvre Figure 24: Analyse par date et par trésorerie suivant 3 indicateurs à

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.