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. Par la même occasion, Nous en profitons pour exprimer nos vifs remerciements à tous ceux qui ont contribué de près ou de loin au bon déroulement de ce travail
4 Contexte général
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
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. 2. 3. 4.
Traduire la vision en objectifs opérationnels ; Communiquer la vision et la décliner en performance individuelle ; Planification d'activité ; 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 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
2. Conception Que faut-il faire ?
Une démarche centrée sur le décideur de terrain en situation, point central du processus de décision et par conséquent du système de pilotage de la performance
Etape 1 : Environnement de l'entreprise Analyse de l'environnement économique et de la stratégie de l'entreprise afin de définir le périmètre et la portée du projet Etape 2 : Identification de l'entreprise Analyse des structures de l'entreprise pour identifier les processus, activités et acteurs concernés.
3. Mise en oeuvre Comment le faire ? La technologie est au service des utilisateurs de terrain
4. Amélioration permanente Le système correspond-il toujours aux attentes ?
Etape 3 : Définition des objectifs Sélection des objectifs tactiques de chaque équipe en fonction de la stratégie générale Etape 4 : Construction du tableau de bord Définition du tableau de bord de chaque équipe Etape 5 : Choix des indicateurs Choix des indicateurs en fonction des objectifs choisis, du contexte et des acteurs concernés Etape 6 : Collecte des informations Identification des informations nécessaires à la construction des indicateurs Etape 7 : Le système de tableau de bord Construction du système de tableau de bord, contrôle de la cohérence globale.
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. Etape 10 : Audit Suivi permanent du système
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 stratégique Stratégie prédéfinie
Volet humain
Volet financier Dirigiste: Manque Coûteuse de participation du personnel Enquête sur le Pas de capital humain moyens financiers
Domaine d’application Stratégie d’Entreprise
Peu de moyens financiers
Pilotage d’entreprise/organism es
Balanced Scoreban d (BSC) Navigateu Prise en r Skandia considération des facteurs immatériels dans l’élaboration de la stratégie S’adapte à toute Coopérative : GIMSI stratégie mise en Forte implication place du personnel
Gestion d’Entreprise
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
N° Tâche tâche 1 Documentation sur l'organisme d'accueil 2 Documentation métier
Durée
Date début
Date fin
2j
Mer 16/03/11
Ven 18/03/11
4j
Lun 21/03/11
Lun 28/03/11
3
Documentation Business Intelligence Documentation Gestion de projet
5j
Lun 21/03/11
Mar 29/03/11
2j
Lun 21/03/11
Mer 23/03/11
6,79j
Mar 29/03/11
Ven 08/04/11
6
Etude benchmarking de la démarche 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 10
Collecte du besoin Formulation du besoin
2,36j 0,79j
Lun 18/04/11 Jeu 21/04/11
Mer 20/04/11 Jeu 21/04/11
11
Négociation du tableau de bord
3j
Mar 19/04/11
Ven 22/04/11
12
Négociation des KPI
2,36j
Mar 19/04/11
Jeu 21/04/11
13
Formulation des KPI
0,64j
Ven 22/04/11
Ven 22/04/11
14
Etablissement du plan du projet
3j
Lun 25/04/11
Jeu 28/04/11
15
Elaboration de la charte du projet
4,57j
Lun 25/04/11
Lun 02/05/11
16
Elaboration du cahier de charges
4,57j
Lun 25/04/11
Lun 02/05/11
17
Modélisation multidimensionnelle Etablissement du schéma multidimensionnel
3j
Lun 02/05/11
Jeu 05/05/11
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 21
Mapping Conception de la table de faits
3j 3j
Ven 13/05/11 Jeu 19/05/11
Mer 18/05/11 Mar 24/05/11
22 23 24 25
Documentation sur l'outil BI Processus ETL Analyse OLAP Restitution des données
2j 7j 2,21j 2,21j
Lun 23/05/11 Mer 25/05/11 Mer 08/06/11 Lun 13/06/11
Mer 25/05/11 Mar 07/06/11 Ven 10/06/11 Mer 15/06/11
26 27
Tests de la solution Intégration de la solution
0,79j 0,79j
Mer 15/06/11 Jeu 16/06/11
Jeu 16/06/11 Ven 17/06/11
28
Rédaction du rapport de stage
22j
Lun 09/05/11
Ven 17/06/11
4 5
18
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 :
1er niveau: Personnes Ressources GID au niveau de chaque acteur.
2ème niveau: 124 référents GID au niveau des trésoreries TM/TP. (Les référents GID sont ressources relevant des Trésoreries Ministérielles, Provinciales et Préfectorales. Les Référents GID sont chargés de promouvoir le système GID au niveau des ordonnateurs).
3ème niveau: Centre d’assistance GID.
Procédure de la gestion des incidents La procédure d’assistance respecte le schéma suivant
26 Phase d’identification
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. 2. 3. 4. 5. 6.
Le centre de services (Service Desk) La gestion des incidents (Incident Management) La gestion des problèmes (Problem Management) La gestion des changements (Change Management) La gestion des mises en production (Release Management) La gestion des configurations (Configuration Management)
Le processus concernant notre projet est le processus « Gestion des incidents ». La 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 :
2
Détection et enregistrement Classification et support initial Investigation Résolution
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. 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 noncommercial. 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
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
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 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 euxmê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. 2. 3. 4. 5. 6.
Mesurable : l'objectif s'exprime en fonction d'une unité de mesure Borné : l'objectif est impérativement défini dans une dimension de temps Réaliste : la Méthode pour l'atteindre est tout à fait plausible Accessible : les moyens sont disponibles, les risques limités Fédérateur : l'objectif recueille l'adhésion de la majorité 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 Réactivité du centre d’assistance
Workflow Workflow JIRA. Workflow axes de service.
Acteurs 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 :
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 : 3
Alain Fernandez, Nouveaux tableaux de bord des managers, figure 3.25.
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) : 4
Les nouveaux tableaux de bord des managers Editions Organisation
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.
Figure 7: Exemple d’un schéma en étoile
Figure 8: Exemple d’un schéma en flocons de neige
Choix du schéma de modélisation Nous avons choisi le schéma de modélisation en étoile pour les raisons suivantes :
C’est un schéma stable. Limite le nombre de jointures. Optimise les requêtes des utilisateurs. Intègre facilement de nouvelles demandes des utilisateurs. Simple à créer et intuitivement compréhensible par les utilisateurs finaux.
En termes Merise, le MPD est à lui seul utilisé pour modéliser les datawarehouses.
42 Phase de conception
Nous avons réalisé les schémas de modélisation avec le logiciel PowerAMC.
Power AMC est un logiciel de modélisation. Il permet de modéliser les traitements informatiques et leurs bases de données associées. Créé par SDP sous le nom AMC*Designor, racheté par Powersoft, ce logiciel est produit par Sybase depuis le rachat par cet éditeur en 1995. Hors de France, la version internationale est commercialisée par Sybase sous la marque PowerDesigner. PowerAMC supporte différents types de modèles de bases de données. Le Modèle Physique des Données (MPD) décrit « les structures de données telles qu’elles sont enregistrées sur les supports physiques »5. C’est le modèle « final», et sa structure dépend étroitement de l’environnement matériel et logiciel d’exploitation des bases de données. Voici le modèle physique de notre datawarehouse (schéma en étoile).
Figure 9 : Modèle en étoile du Datawarehouse
Etude des données sources Nous avons constaté que la base de données du système de suivi des incidents JIRA contient la plupart des données nécessaires pour charger le datawarehouse. Pour les données restantes, étant invariables avec le temps, nous les avons stockés au niveau de fichiers Excel avant de les charger grâce aux transformations. Base de données JIRA La base de données du système JIRA contient toutes les données relevant d’une action réalisée dans le système, JIRA stocke toutes les données relatives à un projet ou une demande donnée afin d’assurer la traçabilité des projets et pour documenter l’activité du service.
5
A. Flory, « Bases de Données, conception et réalisation », Economica 1987.
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.
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 Id Pkey Project Reporter Assignee Issuetype Summary Description Environment Priority Resolution Issuestatus Created Updated Duedate Votes Timeoriginalestimate Timeestimate Timespent Workflow_id Security
Description Clé primaire, interne à la table et connue à seulement à l’utilisateur chargé du projet. Rapporteur de l’incident Personne affectée à la résolution Type de la demande Résumé de la demande Description de la demande Environement de la solution Priorité de la demande Résolution de la demande Statut actuel de la demande Création de la demande Mise à jour de la demande Date limite Votes JIRA Estimation initiale Estimation du temps Temps écoulé pour la résolution Workflow Niveau de sécurité
Fixfor Component
Deprecated Deprecated
Clé étrangère vers Project.id
Issuetype.id Priority.id Resolution.id Issuestatus.id Os_wfentry.id SchemeIssueSecurityLevels.i D -
Les champs timeoriginalestimate, timeestimate et surtout time_spent aurait été 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
. 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 code_demande type_demande reporter_demande assigne_demande priorite_demande resolution_demande file_demande projet_demande_key date_resolution_deman de date_creation_demande status_demande no_demande_id (p) projet_demande code_demande_liee nom_demande_liee
ID issuetype_ID Reporter Assignee Priority_ID Resolution_ID Source_node_i d Pkey Resolutiondate
Jiraissue Jiraissue Jiraissue Jiraissue Jiraissue Jiraissue nodeassociatio n Jiraissue Jiraissue
Table Look Up Issuetype Priority Resolution Dim_demand e -
Created Issuestatus_ID Project_ID ID ID
Jiraissue Jiraissue Jiraissue jiraissue jiraissue
Issuestatus Project linktype linktype
Champ Look Up pname pname pname No_demande_i d pname pname ID source
47 Phase de conception
Table dim_type Champ datawarehouse No_type_id(p) Code_type Type_demande
Champ source Table source ID Issuetype Pname Issuetype
Table dim_membre Champ datawarehouse No_membre_id(p) Code_membre Nom_membre
Champ source -
Table source
ID User_name
Membershipbase Membershipbase
Champ source
Table source
Table dim_priorite Champ datawarehouse No_priorite_id(p) Priorite Code_priorite
-
-
Pname Sequence
Priority Priority
Champ source
Table source
ID Cname
Component Component Component
Table dim_file Champ datawarehouse Code_file Nom_file No_file_id(p) Code_projet
Project
Table dim_DR Champ datawarehouse Code_dr Nom_dr No_dr_id(p)
Champ source
Table source
Code DR
DR.xls DR.xls -
-
48 Phase de conception
Table dim_referent Champ datawarehouse
Champ source
Code_referent/tresorerie Code Nom_referent Rapporteur JIRA Tresorerie_referent Trésorerie No_referent_id (p) Type_tresorerie_referent DR/TM No_dr_id Code Jiradb_nom_referent Nom Référent jiradb
Table source Referent.xls Referent.xls Referent.xls Referent.xls Referent.xls Referent.xls
Champ Look Up Code -
Table Look Up DR.xls -
Pour la table dim_date, la structure de que nous avons adopté pour cette table est celle adoptée par l’entité GID. Une procédure SQL interne à l’entité GID permet l’alimentation de la table dim_date. Table de faits : Algorithme et calcul La table de faits contient, à côté des clés étrangères la liant aux tables de dimensions, les mesures. Les mesures sont calculables à partir des dimensions et de leurs attributs, grâce à des programmes. Nous allons présenter les algorithmes permettant le calcul de chacune des dimensions : Réactivité_global: C’est la différence temporelle entre la date de résolution de la demande et la date de création de la demande. Réactivité_REQ: Il y a deux cas ;
Cas ou le projet REQ n’est pas lié à un projet SGID : C’est la différence entre la date de résolution de la demande et la date de création de la demande pour les projets REQ non liés à un projet SGID. Cas ou le projet REQ est lié à un projet SGID : C’est la différence entre la date de résolution de la demande et la date de création de la demande pour les projets REQ, en tranchant le temps consommé par le projet SGID.
Réactivité_avantGID: C’est la différence temporelle entre la date de création du projet SGID et la date de création de la demande. Réactivité_aprèsGID: C’est la différence temporelle entre la date de résolution de la demande et la date de résolution du projet SGID. Réactivité_SGID :C’est la différence temporelle entre la date de résolution du projet SGID et sa date de création.
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.
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 Pentaho Data Integration
Pentaho Analysis Services
Description Le Pentaho Data Integration, dont le nom de code est Kettle, consiste en un noyau moteur ETL, ainsi que des applications à interface graphique d’utilisation permettant à l’utilisateur de définir les jobs et les transformations. Le Pentaho Analysis Services (nom de code: Mondrian OLAP server) est un outil OLAP open source,écrit en Java. Il supporte le langage MDX, le XMLA ainsi que es 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 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 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.
Pentaho DashBoard
Pentaho for Apache Hadoop
Le tableau ci-dessous liste les différents composants qu’nous allons utiliser pour notre projet par type d’activité : Type d’activité ETL Analyse OLAP Tableau de bord Reporting
Solution Pentaho Pentaho Data Integration (PDI). Pentaho Analysis (Mondrian+JPivot), Schema Workbench. Pentaho Dashboard. Pentaho Reporting (JFree Report), Pentaho Report Designer.
54 Mise en œuvre
Etape 9 : Déploiement et intégration Alimentation du datawarehouse L’alimentation d’un datawarehouse se fait grâce à un processus ETL. Les processus ETL (Extraction, Transformation et Chargement) sont les composants les plus critiques - et les plus importants - d’une infrastructure décisionnelle. Bien que cachés de l’utilisateur de la plate-forme décisionnelle, les processus ETL rassemblent les données à partir des systèmes opérationnels et les pré-traitent pour les outils d’analyse et de reporting. La précision et la vitesse de la plate-forme décisionnelle toute entière dépendent des processus ETL. Les processus d’ETL (Extraction, Transformation et Chargement) regroupent plusieurs étapes, qui ont pour objet de transférer des données depuis les applications de production vers les systèmes décisionnels :
Extraction de données des applications et des bases de données de production (ERP, CRM, SGBDR, fichiers, etc.) Transformation de ces données pour les réconcilier entre les différentes sources, pour effectuer des calculs ou du découpage de texte, pour les enrichir avec des données externes et aussi pour respecter le format requis par les système cibles (Troisième Forme Normale, Schéma en Etoile, Dimensions à Evolution Lente, etc.) Chargement des données résultantes dans les différentes applications décisionnelles : Data Warehouse ou Enterprise Data Warehouse, Datamarts, applications OLAP (Online Analytical Processing) ou “cubes”, etc.
La latence des processus d’ETL varie du mode batch (parfois mensuel ou hebdomadaire, le plus souvent quotidien) jusqu’au quasi-temps réel avec des rafraîchissements plus fréquents (toutes les heures, toutes les minutes, etc.). L’implémentation de processus d’ETL efficaces et fiables comprend de nombreux challenges.
Les volumes de données sont en croissance exponentielle, et les processus d’ETL doivent traiter des quantités importantes de données granulaires (produits vendus, appels téléphoniques, transactions bancaires, etc.). Certains systèmes décisionnels sont mis à jour de façon incrémentale, alors que d’autres sont rechargés dans leur totalité à chaque itération. Alors que les systèmes d’information se complexifient, la variété des sources de données s’accroît également. Les processus d’ETL doivent disposer d’une large palette de connecteurs à des progiciels (ERP, CRM, etc.), bases de données, mainframes, fichiers, Services Web etc. Les structures et applications décisionnelles incluent des data warehouses, des data marts, des applications OLAP - pour l’analyse, le reporting, les tableaux de bord, le scorecarding, etc. Toutes ces structures cibles présentent des besoins différents en termes de transformation de données, ainsi que des latences différentes. Les transformations des processus d’ETL peuvent être très complexes. Les données doivent être agrégées, parées, calculées, traitées statistiquement, etc. Certaines transformations spécifiques au décisionnel sont aussi requises, comme les Dimensions à Evolution Lente.
55 Mise en œuvre
Alors que le décisionnel se rapproche du temps réel, les data warehouses et data marts doivent être rafraîchis plus souvent, dans des fenêtres de chargement toujours plus courtes.
Mise en œuvre des processus ETL Pour chaque table, nous allons construire une ou plusieurs transformations (selon le besoin) basée sur les mappings et les algorithmes expliqués dans l’étape « Collecte des informations ». Nous avons donc les transformations suivantes: Etl_dim_demandes & etl_file_demande pour la table dim_demandes. Etl_Dim_type pour la table dim_type. Etl_Dim_membre pour la table dim_membre. Etl_Dim_priorite pour la table dim_priorite. Etl_Dim_ file pour la table dim_file. Etl_dim_dr pour la table dim_dr. Etl_Dim_referent pour la table dim_referent. Etl_Dim_date pour la table dim_date. Etl_reactivite & etl_reactivite_global /projet pour la table reactivite. Les transformations ne suivent pas le même schéma, ça dépend de la source de données et des fonctionnalités requises (look ups par exemple). Dim_type est un exemple d’une table nécessitant une transformation directe :
Figure 11: etl_dim_type
Les données sélectionnées sont chargés directement de la table issuetype vers la table dim_type. Dim_demandes est un exemple d’une table nécessitant une transformation complexe : Une pour le champ file_demande
56 Mise en œuvre
Figure 12: etl_file_demande
Et une autre pour le reste des champs
Figure 13: etl_dim_demande
Cette transformation remplit la table dim_demandes, on constate ici l’utilisation des look ups pour remplir des champs (comme démontré dans les tables de mapping). Filter row filtre les demandes REQ seulement (comme ça on n’encombre pas le datawarehouse par des données inutiles pour le décideur et qui risquent d’atténuer les performances du système de reporting ainsi que consommer des Go supplémentaires). Le rôle du composant « if field value is null » est d’affecter des valeurs numériques pour les champs n’ayant aucune valeur « NULL » afin de pouvoir afficher une information significative concernant les champs et pour ne pas perturber les rapports par des valeurs éventuellement non-significatives (des valeurs négatifs par exemple).
Dim_réferent est un exemple d’une table ayant des fichiers Excel comme sources de données
57 Mise en œuvre
Figure 14: etl_dim_referent
Cette transformation est alimentée depuis deux sources Excel, le flux de données est fusionné dans la table cible dim_referent. Pour la table de faits, nous avons utilisé les transformations suivantes :
Figure 15: Alimentation des clés étrangères de la table de faits
Cette transformation alimente les champs des clés étrangères de la table de faits, ce sont les champs marquant la dépendance entre cette dernière et les tables des dimensions.
58 Mise en œuvre
Figure 16: Mesures de la table de faits
Cette transformation remplit les 5 mesures, à savoir : réactivité_global, réactivité_REQ, réactivité_avantGID. réactivité_aprèsGID. réactivité_SGID.
Le premier stream concerne les mesures 4 dernières mesures. L’input « dim_demandes » ne sélectionne que les demandes résolues (grâce à des requêtes écrites dans l’input). Pour trier les demandes ou le projet SGID est lié à un projet REQ et ceux où il y a pas de liaison entre les deux on a recours à une composante « switch/case », celle-ci ne traitant que des valeurs numériques, il faut d’abord attribuer des valeurs numériques pour le champ « code_demande_liee ». Le traitement « constant » concerne les demandes ou un projet SGID a eu lieu (code_demande_liee différent de 0). Le traitement « constant 2 » concerne les demandes dont les projets de résolution ne passent pas par SGID (Résolues par projets REQ) (code_demande_liee=0). Pour le premier traitement:
La composante « Look up » tire les informations (de la table jiraissue) concernant la demande liée qui a été créé dans le SGID. La composante « Calculator » effectue les calculs nécessaires pour le calcul de la mesure. Les Filter rows servent à filtrer les demandes ayant des anomalies ou des dysfonctionnements comme les demandes ne respectant pas les workflows (exemple : les demandes ou le projet REQ est fermé avant qu’on ferme le projet SGID). Le dernier « Look up » retourne les IDs des demandes filtrés pour établir le mapping dans Insert/Update.
Pour le deuxième traitement : Absence du projet SGID, on a besoin du calculator pour implémenter l’algorithme et effectuer les calculs ainsi qu’un look up pour la correspondance des demandes.
59 Mise en œuvre
Le deuxième stream calcule la mesure reactivite_global. Analyse de données Une fois les données stockées, nettoyées, consolidées et accessibles, elles sont utilisables. Selon les besoins, différents types d'outils d'extraction et d'exploitation seront envisagés. Les principaux outils d’analyse de données sont :
Analyse statistiques : Les principaux types d’analyse statistique sont ceux basés sur l’analyse OLAP (multidimensionnelles) et le langage R. Les arbres de décision: Un outil fort pratique lorsqu'il s'agit de répartir une population en groupes homogènes selon des critères bien précis, appelés variables de segmentation. Le Data Mining. Le Text Mining.
Nous avons choisi la technologie OLAP pour l’analyse des données contenues dans le datawarehouse pour les raisons suivantes :
Elle permet l’analyse multidimensionnelle requise dans les spécifications du projet. Elle permettra par la suite de générer des rapports personnalisés facilement construits par le décideur. C’est une technologie mise en œuvre dans le système existant.
L’OLAP L’OLAP (Online analytical processing, fr : traitement analytique en ligne) est un type d'application informatique orienté vers l'analyse sur-le-champ d'informations selon plusieurs axes, dans le but d'obtenir des rapports de synthèse. OLAP s'inscrit dans un système décisionnel, également dit de gestion, qui est dédié au management de l’entreprise pour l’aider au pilotage de l’activité en offrant une vision transversale de l’entreprise. Ce type d'application s'oppose au traitement de transactions en ligne (anglais online transaction processing abr. OLTP) qui s'inscrit dans un système opérationnel, c'est-à-dire dédié aux métiers de l’entreprise pour les assister dans leurs tâches de gestion quotidiennes. Ce terme a été défini par Edgar Frank Codd en 1993 au travers de 12 règles que doit respecter une base de données si elle veut adhérer au concept OLAP : 1. Vue conceptuelle multidimensionnelle 2. Transparence 3. Accessibilité 4. Constance des temps de réponses 5. Architecture client-serveur 6. Indépendance des dimensions 7. Gestion des matrices creuses 8. Accès multi-utilisateurs 9. Pas de restrictions sur les opérations inter et intra dimensions 10. Manipulation aisée des données
60 Mise en œuvre
11. Simplicité des rapports 12. Nombre illimité de dimensions et nombre illimité d'éléments sur les dimensions Ce concept a été appliqué à un modèle virtuel de représentation de donnée appelé cube ou hypercube OLAP qui peut être mis en œuvre de différentes façons. Un hypercube OLAP (ou cube OLAP) est une représentation abstraite d'informations multidimensionnelles exclusivement numérique utilisé par l'approche OLAP (acronyme de On-line Analytical Processing). Cette structure est prévue à des fins d'analyses interactives par une ou plusieurs personnes (souvent ni informaticiens ni statisticiens) du métier que ces données sont censées représenter. Les cubes OLAP ont les caractéristiques suivantes :
Obtenir des informations déjà agrégées selon les besoins de l’utilisateur. Simplicité et rapidité d’accès Capacité à manipuler les données agrégées selon différentes dimensions Un cube utilise les fonctions classiques d’agrégation : min, max, count, sum, avg, mais peut utiliser des fonctions d’agrégations spécifiques
L'hypercube OLAP donne accès à des fonctions d'extraction de l'information (pour visualisation, analyse ou traitement), et à des fonctions de requête en langage MDX (comparable à SQL pour une base de données relationnelles). Le langage MDX, né au sein des labos Microsoft (SQL Server OLAP), est un langage d'interrogation des bases multidimensionnelles plus adapté que le classique SQL pour le traitement des requêtes de type OLAP. MDX signifie "Multi-Dimensional Expressions". Microsoft a proposé le langage MDX comme standard des interrogations multi dimensionnelles. Les fonctions d’extraction sont :
Rotate : sélection du couple de dimensions à cibler, Slicing : extraction d'une tranche d'information, Scoping : extraction d'un bloc de données (opération plus générale que le slicing), Drill-up : synthèse des informations en fonction d'une dimension (exemple de drill-up sur l'axe temps : passer de la présentation de l'information jour par jour sur une année, à une valeur synthétique pour l'année), Drill-down : c'est l'équivalent d'un « zoom », opération inverse du drill-up, Drill-through : lorsqu'on ne dispose que de données agrégées (indicateurs totalisés), le drill through permet d'accéder au détail élémentaire des informations (voir notamment les outils H-OLAP).
Conception des Cubes Nous commençons par concevoir des schémas. Les schémas correspondent à un scénario. Le schéma contient plusieurs cubes pour l’analyse des différentes situations du scénario. Les schémas conçus sont :
61 Mise en œuvre
Un schéma destiné au directeur du centre d’assistance (MOA), contenant trois cubes. Le directeur du centre a accès à toutes les données du datawarehouse. Des schémas destinés à chaque membre du centre d’assistance : Dans le cadre de la démarche GIMSI, démarche favorisant une approche coopérative de prise de décision, nous avons décidé de concevoir des cubes pour les membres du centre d’assistance pour que chacun d’eux peut avoir une vue de leur performance et l’améliorer par la suite. Cependant, l’accès sera filtré de telle sorte que chaque membre du personnel ne peut accéder qu’aux données relatives à son activité. Les cubes destinés au directeur du centre sont : Cube Reactivité: Contient toutes les dimensions et la mesure reactivité_global. Il s’intéresse à la réactivité globale du centre suite à une demande.
Figure 17: Cube Reactivité
Cube RéactivitéREQ: Contient toutes les dimensions sauf que pour la dimension dim_demandes nous avons pris en compte juste les demandes qui ont été résolues par le projet REQ sans passer par un projet SGID, il contient aussi la mesure reactivité_REQ. Ce cube s’intéresse aux demandes résolues grâce à un projet REQ seulement.
62 Mise en œuvre
Figure 18: Réactivité_REQ
Cube ReactivitéREQSGID : Contient toutes les dimensions sauf que pour la dimension dim_demandes nous avons pris en compte juste les demandes qui ont été résolues en passant par un projet SGID (et bien sûr par un projet REQ). Il contient aussi les mesures Réactivité_avantGID, Réactivité_aprèsGID et Réactivité_SGID.
63 Mise en œuvre
Figure 19: Cube ReactiviteREQSGID
Alimentation du tableau de bord Pour alimenter le tableau de bord, il faut publier le cube. Cette opération permet de charger le tableau de bord et de rendre le cube consultable à travers Pentaho User Console (interface Web du tableau de bord). Il faut sauvegarder le cube dans le répertoire de Pentaho User Console afin qu’il soit consultable.
Figure 20: Pentaho User Console-Interface de démarrage
64 Mise en œuvre
Exemples de restitution
Figure 21: Analyse par Direction Régionale
65 Mise en œuvre
Figure 22: Analyse par assigné (par membre)
66 Mise en œuvre
67 Mise en œuvre
68 Mise en œuvre
Figure 23: Analyse par référent selon 3 indicateurs à la fois
69 Mise en œuvre
Figure 24: Analyse par date et par trésorerie suivant 3 indicateurs à la fois
Intégration de la solution Pour intégrer la solution, il faut :
Héberger le datawarehouse dans un serveur. Connecter le datawarehouse au serveur JIRA. Assurer l’accès au datawarehouse par tous les utilisateurs. Installer l’outil Pentaho, les transformations et les cubes dans tous les terminaux des utilisateurs. Publication des schémas (et des cubes) concernant chaque utilisateur.
70 Mise en œuvre
Chapitre VI Amélioration permanente
71 Amélioration permanente
VI.
Amélioration permanente
Etape 10 : Audit du système Méthode d'audit pour garantir la durabilité de la performance du système de pilotage. Avec le temps, l'organisation évolue, les stratégies changent, les décideurs acquièrent de l'expérience. Pour toutes ces raisons, il est prudent de s'assurer régulièrement de la cohérence du système avec les besoins actualisés de l'organisation et les attentes des utilisateurs. Adopter l'habitude de l'audit méthodique et périodique est vraisemblablement la meilleure solution pour garantir la durabilité de la performance intrinsèque du système de pilotage. En tant que stagiaires ne faisant pas partie de l’équipe décisionnel permanente de l’entité GID, nous ne pouvons pas se charger de l’audit permanent du système, par conséquent cette étape n’est pas traitée, strictu sensu, dans notre projet. C’est plutôt la manière dont nous avons conçu et développé le système qui fera de lui un système susceptible d’évoluer suivant les nouveaux besoins et capable de s’adapter au changement. Les éléments pris en considération pendant la conception et le développement du système sont :
Les algorithmes de calcul que nous avons utilisé sont valables pour tous genres de projets du centre d’assistance puisque les données sources proviennent de la Base de données JIRA au niveau de laquelle toutes les données sont stockées. Les clés des différentes tables sont indépendants des données sources, ce qui réduit la dépendance des données, facilite les modifications au niveau du datawarehouse et permet de garder la traçabilité après une éventuelle modification. L’ajout d’une nouvelle file, d’une nouvelle trésorerie ou d’un membre va être intégré directement dans les rapports sans avoir besoin à la moindre configurer le système ou à modifier le datawarehouse. Le modèle une étoile permet un ajout aisé de nouvelles dimensions à partir du modèle existant sans avoir besoin de refaire tout le modèle.
72
Conclusion
A titre de conclusion, notre stage de fin d’études au sein de la Trésorerie Générale du Royaume nous a permis d’atteindre le but recherché. En effet, ce stage a été pour nous une occasion sans précédent pour mener un projet dans les bonnes pratiques du métier et aussi au sein d’un organisme suivant un mode de management de systèmes d’informations de bonnes pratiques. Le stage a été bénéfique sur le plan technique vu que nous avons pu maitriser la chaîne de valeur entière d’un projet BI en utilisant un outil Open source. L’informatique décisionnelle est un domaine très large et très prometteur avec plusieurs champs d’application, et le fait d’être ingénieur spécialiste dans ce domaine, c’est avoir le sens d’analyse, de conception et d’organisation, et c’est aussi avoir le sens d’engagement envers la communauté et assumer toutes les responsabilités qui lui ont été attribuées vu l’importance cruciale de cette discipline pour la stratégie de l’organisme. Pour conclure, il semble intéressant de mettre en évidence que choisir cette vocation et devenir ingénieur en décisionnel est une bonne chose. Mais ce qui est meilleur, c’est d’user de tout son savoir-faire dans ce domaine pour une bonne cause qui est augmenter la qualité des services offerts par l’administration marocaine pour assurer une fluidité des processus administratives de la finance publique et ainsi satisfaire au flux de travail croissant que les instances compétentes doivent régler ainsi que pousser à l’avant ce domaine des Technologies d’Information et de Communication qui prend un place bien particulière dans le processus de la modernisation de l’administration et de l’économie marocaines.
73 Conclusion
Liste de figures Figure 1: Chaîne de valeur décisionelle ................................................................................................... 9 Figure 2: Procédure d'assistance GID .................................................................................................... 26 Figure 3: Interaction REQ/GID ............................................................................................................... 29 Figure 4: Workflow JIRA ........................................................................................................................ 31 Figure 5: Workflow axes de service ....................................................................................................... 31 Figure 6: Fonctions du tableau de bord ................................................................................................. 35 Figure 7: Exemple d’un schéma en étoile ............................................................................................. 41 Figure 8: Exemple d’un schéma en flocons de neige ............................................................................ 41 Figure 9 : Modèle en étoile du Datawarehouse .................................................................................... 42 Figure 10: Modèle partiel de la base de données de JIRA .................................................................... 43 Figure 11: etl_dim_type ........................................................................................................................ 55 Figure 12: etl_file_demande ................................................................................................................. 56 Figure 13: etl_dim_demande ................................................................................................................ 56 Figure 14: etl_dim_referent .................................................................................................................. 57 Figure 15: Alimentation des clés étrangères de la table de faits ......................................................... 57 Figure 16: Mesures de la table de faits ................................................................................................. 58 Figure 17: Cube Reactivité..................................................................................................................... 61 Figure 18: Réactivité_REQ ..................................................................................................................... 62 Figure 19: Cube ReactiviteREQSGID ...................................................................................................... 63 Figure 20: Pentaho User Console-Interface de démarrage ................................................................... 63 Figure 21: Analyse par Direction Régionale .......................................................................................... 64 Figure 22: Analyse par assigné (par membre) ....................................................................................... 65 Figure 23: Analyse par référent selon 3 indicateurs à la fois ................................................................ 68 Figure 24: Analyse par date et par trésorerie suivant 3 indicateurs à la fois ........................................ 69 Figure 25: Workflow JIRA ...................................................................................................................... 93 Figure 26: Workflow axes de service ..................................................................................................... 93
74 Conclusion
Glossaire Agrégation: Action de calculer les valeurs associées aux positions parents des dimensions hiérarchiques. Cette agrégation peut être une somme, une moyenne, ou tout autre processus plus complexe comme la deuxième plus forte valeur. Aiguillage: Orientation de la demande d’un axe vers un autre. Assistance (aux utilisateurs): Service aidant les utilisateurs à résoudre un incident ou un problème lors de l’utilisation d’un logiciel et assurant que le client a accès à un service informatique approprié. Attribut : Un fait décrivant chaque position d'une dimension. Axe : Correspond à une dimension. Bug : Erreur dans un programme informatique pouvant perturber son fonctionnement. Client : Demandeur de service. Cellule : Une donnée définie par une position de chaque dimension. Les cellules d'un hypercube peuvent être vides ou remplies. Lorsqu'un grand nombre de cellules sont vides, on parle de données éparses. Centre d’assistance: au service chargé de répondre aux demandes d'assistance émanant des utilisateurs de produits ou de services Cube: Le plus souvent, synonyme d'hypercube. Datamart : L'ensemble des données se rapportant à un des métiers de l'entreprise. Plusieurs datamart forment le datawarehouse de l'entreprise. Datawarehouse : Entrepôt de données. Ce terme anglais est utilisé pour désigner l'ensemble des informations d'une entreprise, enregistrées sous un format informatique. Demande (d’assistance) : demande faite par l'utilisateur d'une application informatique, concernant un incident rencontré, une évolution souhaitée, ou une mauvaise compréhension des règles de gestion. Dimension : Un ensemble de données du même type, permettant de structurer la base multidimensionnelle. Une dimension est parfois appelée un axe. Chaque cellule d'une mesure est associée à une seule position de chaque dimension. Temps, pays, produit sont des dimensions classiques. DOLAP : Desktop OLAP. Ce terme désigne un petit produit OLAP faisant de l'analyse multidimensionnelle en local. Il peut y avoir une mini base multidimensionnelle (façon Personal Express), ou bien de l'extraction de cube (façon Business Objects). DSS : Decision Support System, ou système d'information décisionnel. C'est un système d'interrogation et de présentation des données adapté pour l'aide à la décision. Le terme français équivalent est SIAD, ou Système d'Information d'Aide à la Décision. Un autre terme anglais est EIS, ou Executive Information System.
75 Conclusion EIS : Executive Information System. Le terme anglais plus courament utilisé est DSS, ou Decision Support System. FASMI : Fast Analysis of Shared Multidimensional Information, ou analyse rapide d'information multidimensionnelle partagée. Ces cinq termes ont tous leur importance dans la définition de la technologie OLAP. Formule : C'est un hypercube virtuel, c'est à dire que les valeurs obtenues sont le plus souvent calculées à la volée mais non stockée dans la base de données. GID : Gestion Intégrée de la Dépense. Hiérarchie : Les positions d'une dimension organisées selon une série de relations 1-n en cascade. Cette organisation de données est comparable à un arbre logique, ou chaque membre n'a pas plus d'un père mais un nombre quelconque d'enfants. HOLAP : Hybrid OLAP. Désigne les outils d'analyse multidimensionnelle qui récupèrent les données dans des bases relationnelles ou multidimensionnelles, de manière transparente pour l'utilisateur. Hypercube : Une construction multidimensionnelle formée de la conjonction de plusieurs dimensions. Chaque cellule est définie par un seul membre de chaque dimension. Incident : arrêt ou dégradation d'un service.
Logiciel de gestion des services d'assistance: Logiciel applicatif qui gère les services d'assistance dans des organisations dédiées à ce type d'activité (comme les centres d'assistance ou les cellules d'assistance réparties. MDB : Multidimensional DataBase. Permet le stockage, le traitement et la restitution de données multidimensionnelles. Mesure : Un hypercube, le plus souvent de type entier ou décimal, structuré par des dimensions. Salaire, Prix, Quantité, Coût sont des mesures classiques. MOLAP : Multidimensional OLAP. Ce terme désigne plus spécifiquement une technologie de stockage cartésien. MOLAP s'oppose à ROLAP. Pour le premier, les jointures sont déja faites, ce qui explique les performances. Dans le second, les jointures entre les tables de dimension et de fait sont effectuées au moment de la requête. Multicube : Une construction multidimensionnelle formée de plusieurs hypercubes partageant certaines dimensions. Multidimensionnel : Structure de données ayant au moins trois dimensions indépendantes. Niveau hiérarchique : Au sein d'une hiérarchie, les positions sont en général organisées en niveaux. Les positions d'un même niveau correspondent à une classification précise. Par exemple, on peut concevoir une dimension "temps", pour laquelle les jours sont au niveau 1, les mois au niveau 2 et les années au niveau 3. OLAP : Littéralement, On-Line Analytical Processing. Désigne une catégorie d'applications et de technologies permettant de collecter, stocker, traiter et restituer des données multidimensionnelles, à des fins d'analyse. Une autre définition est résumée dans l'acronyme FASMI (Fast Analysis of Shared Multidimensional Information), ou analyse rapide d'information multidimensionnelle partagée. Les outils OLAP doivent respecter 12 règles précises que vous pouvez découvrir à cette page.
76 Conclusion
Position : Une valeur d'une dimension. PRGID : Personne Ressource GID. Problème: Origine d'un ou de plusieurs incidents récurrents Processus métier: Succession imposée de tâches à réaliser concernant un métier donné. Qualification: Désignation du type d’un incident. RDBMS : Relational DataBase Management System. Permet le stockage, le traitement et la restitution de données stockées dans des tables relationnelles. Son équivalent français est SGBDR, ou Système de Gestion de Base de Données Relationnelle. Référent : Assistants de second niveau (au niveau des Trésoreries). Relation : Une relation entre les positions de deux dimensions distinctes permet d'effectuer facilement des calculs à la volée pour définir de nouvelles formules. REQ : Projet « assistance aux utilisateurs ». ROLAP : Relational OLAP. Il s'agit d'un ou plusieurs schémas en étoile stockés dans une base relationnelle. Cette technique permet de faire de l'analyse multidimensionnelle à partir de données stockées dans des bases relationnelles. Services d'assistance : Ou services support aux utilisateurs. Ce sont les services qui consistent à aider les utilisateurs à résoudre un problème dans l'utilisation d'un logiciel. SGBDR : Système de Gestion de Base de Données Relationnelle. Equivalent de RDBMS. SIAD : Système d'Information d'Aide à la Décision. Equivalent de EIS. Schéma en étoile : Arrangement de tables dans une base de données relationnelle. Au centre, on trouve la table de faits, dont les colonnes constituent les mesures du multidimensionnel. Les branches de l'étoile qui rayonnent à partir de la table de fait correspondent aux dimensions. Le modèle conceptuel de données permet de retrouver cette forme en étoile. Utilisateur: Personnes utilisant le système GID. Variable : En général synonyme de mesure. Workflow: flux d'informations au sein d'une organisation. Le terme désigne aussi la modélisation et la gestion informatique de l'ensemble des tâches à accomplir et des différents acteurs impliqués dans la réalisation d'un processus métier.
77 Références
Références Bibliographie
JEAN MARIE GOUARNE; Le Projet Décisionnel, Enjeux, Modèles, architecture du Data Warehouse. Editions Eyrolles, 1997. ALAIN FERNANDEZ; Le nouveau tableau de bord des managers ; Editions Eyrolles, 2011. ALAIN FERNANDEZ ; l’essentiel des tableaux de bord ; Editions Eyrolles, 2011. MARIA CARINA ROLDAN; Pentaho 3.2 Data Integration; Packt Publishing Ltd.; Edition 2010. Alain GARNIER ; L'information non structurée dans l'entreprise - usages et outils ; Hermes - Lavoisier, 2007. PENTAHO INC.; Getting Started with Pentaho Data Integration, Pentaho Documentation. PENTAHO INC.; Pentaho Business Intelligence Suite 3.6, A guide to getting started with MySQL 5.x and Windows; Pentaho Documentation. ATLASSIAN SOFTWARE SYSTEMS, JIRA 4.1 Documentation. itSMF; An Introductionary Overview of ITIL V3; itSMF Ltd, 2007. MOHAMED TASLIMANKA SYLLA; Présentation Analyse et conception d’un projet BI ; 2008 RACHID BENNIS ; Cours La modélisation en étoile ; 2010-VA SIM.
Webographie
Wikipedia anglaise: en.wikipedia.org Wikipedia française: fr.wikipedia.org Wiki GID: wiki.gid.gov.ma Site Web de la Trésorerie Générale du Royaume: www.tgr.gov.ma MSDN Library (français) : http://msdn.microsoft.com/fr-fr/library www.itilfrance.com www.developpez.com www.developpez.net www.piloter.org bernard.lupin.pagesperso-orange.fr www.atlasdumanagement.com
78 Références
Annexes
79 Charte de projet
Charte de projet Conception et développement d’une solution de reporting avancé et d’analyse multidimensionnelle afin d’étendre les capacités de l’outil JIRA au sein de l’entité GID
Noms et prénom des Stagiaires
LOUTFI Ismail. TAOUR Marouane.
Organisme d’accueil Date de cette version Encadrant Interne (INPT)
Trésorerie Générale du Royaume 02 mai 2011 Version finale Mr. DAHCHOUR Mohammed
[email protected] Mr. ZAOUIA Abdellah
[email protected]
Encadrant Externe (Organisme d’accueil)
Mr. AIRROUCHTE Imade
Distribution
Ce document devra être distribué a :
Nom Mr. AIRROUTCHE Imade
Fonction Encadrant externe du projet
Mr. DAHCHOUR Mohammed
Encadrant interne du projet
Mr. ZAOUIA Abdellah Mr. TIJANI Nadir
Encadrant interne du projet Maitre d’ouvrage
[email protected]
80 Charte de projet
OBJECTIF DU DOCUMENT
L’objectif de ce document est d’assembler toute la documentation relative à la gestion du projet PFE à savoir : 1. l’approche et la stratégie de réalisation du projet 2. la procédure de gestion des risques. 3. La procédure de gestion du changement. 4. le plan de communication 5. le plan de projet DESCRIPTION DU PROJET 1.
Contexte :
GID est un système budgétaire et comptable unifié et commun à l’ensemble des acteurs de la dépense publique qui vise à atteindre les objectifs suivants :
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’entité GID assure aussi un service d’assistance aux utilisateurs du système GID par le biais du centre d’assistance GID, c’est le service chargé de répondre aux demandes d’assistance aux utilisateurs et par conséquent assurer le bon fonctionnement du système et la durabilité des transactions. C’est ainsi qu’est né le besoin de mesure de la performance du service d’assistance. Le tableau de bord développé doit en priorité remplir les grandes fonctionnalités suivantes :
Reporting sur le temps de réactivité du service.
Reporting sur la qualité du service.
2.
Intérêt du projet :
Le projet s’inscrit dans une logique de développement durable et permet l’amélioration continue de la qualité de service fournie par le centre d’assistance. Mesure de la performance du centre d’assistance, identification des axes d’amélioration, prise de décision plus pertinente concernant les processus d’assistance.
3.
But du projet : Mise en œuvre d'un système de reporting pour le compte du service d'assistance au sein de l'entité GID.
4.
Objectifs :
81 Charte de projet La mesure de la performance du centre d’assistance.
5.
Résultats attendus
Le produit final : Tableau de bord pour le reporting listant des indicateurs concernant les différents axes précisés par le maitre d’ouvrage. Les livrables (documentation) : Rapport de PFE, Cahier de charges, Charte de projet.
6.
Inclusion et Exclusions
Inclusions: Analyse de l'environnement du centre d'assistance, analyse des données et de processus métier, définition des objectifs, construction du tableau de bord, choix des indicateurs, conception et alimentation du datawareshouse, conception de datamarts et de cubes OLAP, restitution de données. Exclusions: Choix de le solution BI, sécurité du système, audit permanent du système.
7.
Contraintes de projet
Le projet doit être réalisé en 3 mois. Le système décisionnel doit correspondre aux exigences métiers du centre d'assistance. L'utilisation des outils techniques suivants: SGBD : Oracle. Suite BI: Pentaho BI Suite. En outre le système doit vérifier : Accès à distance à la base de données décisionnelle. Capacité minimale de 40 Go. Inclusion de la présentation graphique de données. Démarche claire et méthodique du travail. Planification du projet. Confidentialité : Existence de données confidentielles (les données contenues dans la base de données de JIRA).
82 Charte de projet
8.
Analyse de la valeur du projet :
Objectifs stratégiques Technologique
Clientèle (référents)
Organisationnel/Fonctionnel
Valeur présente Mapping et Reporting se font manuellement par l’option de recherche de l’outil JIRA ou à base de tableaux Excel. Reporting ne prenant pas en considération l’interaction du référent avec le centre d’assistance.
Valeur future Mapping et Reporting plus développés grâce à un système décisionnel indépendant.
Valeur ajoutée Simplification de la recherche dans la base de données et création de plus d’options.
Reporting destiné au référent pour ses activités en relation avec le centre d’assistance. Mesure de Nouveaux performance se fait critères à grâce au rapport prendre en demandes considération arrivés/demandes dans la mesure résolues. de la performance.
Meilleur service d’assistance pour le référent.
Meilleur mesure et contrôle de la performance, responsabilisation des différents acteurs.
83 Charte de projet
9.
Analyse des parties prenantes
Parties prenantes Enjeux Centre d’assistance Gain : Réalisation du (MOA) projet. Développement des processus métier et fluidité du travail. Perte: Absence d’outil de mesure de performance pour le centre d’assistance. Elèves stagiaires Gain: Réussite du projet (MOE) de Fin d'Etudes.Formation au cycle ingénieur d'état. Laisser une bonne image de soi-même et de l'institut de formation. Perte: Image de marque de l'institut. Image de soi-même. Perte de temps. Mauvaises conséquences sur le début de la carrière professionnelle. Encadrants Gain: Augmentation du nombre d'étudiants encadrés. Capitalisation de l'expérience. Perte: Temps et effort.
Influence Actions potentielles Spécification des Elaboration du cahier besoins. de charge. Exigence de délai. Suivi du MOE quant au respect du cahier de charge, à la qualité exigée et aux livrables.
Une bonne/mauvaise réponse technique et métier aux exigences du cahier de charge.
Respect du cahier de Charge. Elaboration d'une bonne solution répondant aux exigences de la charte du projet.
L’encadrement influe Fournir l'encadrement la qualité globale du et l'assistance projet. nécessaires au MOE (étudiants stagiaires).
84 Charte de projet
10. Prérequis en matière de connaissance : -Business Intelligence (Datawarehousing, OLAP, restitution de données…) -Conception et Gestion de bases de données -Modélisation des processus. -Conception de modèles de données. -Languages requis : SQL, MDX, UML, XML, JAVA. -Outils requis : Pentaho BI suite, Oracle, JIRA, logiciels de modélisation ( PowerAMC), Modélisation par Merise.
STRATÉGIE DE RÉALISATION 1. Stratégie 1 : Il existe un MOE qui réalise le projet pour le compte d’un maitre d’ouvrage, et vous autant que stagiaire PFEs, vous travailler avec le MOE. 2. Stratégie 2 : Il existe un MOE externe qui réalise le projet pour le compte d’un maitre d’ouvrage, et vous autant que stagiaire PFEs, vous travailler avec l’équipe Interne MOA 3. Stratégie 3 : Il existe une équipe interne qui va réaliser le projet et vous autant que stagiaire PFEs, vous travailler avec l’équipe interne. Stratégie de réalisation choisie Pour le projet
La position des différentes ressources déployées (matérielles et humaines) par rapport à l'organisme ainsi que le rapport Pertinence/Risque très intéressant nous pousse à choisir la stratégie de réalisation conjointe du projet.
PROCEDURE DE GESTION DES RISQUES Il s’agit de faire une identification en faisant un brainstorming des risques potentiels qui peuvent entraver la bonne marche et la bonne conduite du projet. Un registre de risque est utilisé pour résumer toutes les activités de gestion de risque qui sont prévues ou ont eu lieu, et fournit des informations pour les rapports de fin de phase et de fin du projet.
85 Charte de projet
Identifiant du risque Compréhension du besoin
Description du risques
Impact du risque
Mesures préventives Délivrer des livrables. Réunions régulières avec le MOA.
Mauvaise compréhension du CDC par le MOE
Refaire le CDC
Mauvaise conception et spécification du projet.
Conception/spécification non identiques au cahier des spécifications.
Mauvaise solution et non compatibilité de la solution avec l'existant.
Utiliser un cycle de vie en V ou en cascade avec feedback.
Délai
Terminer plus tard que prévu
Retarder la soutenance du projet. Non disponibilité des différents encadrants pendant la soutenance.
Etablir une planification du projet.
Panne matérielle ou logicielle
Panne des machines ou des environnements de travail.
Endommagement ou perte des fichiers.
Prévoir des copies des fichiers et une machine back-up
PROCEDURE DE GESTION DE CHANGEMENT L’objectif de cette procédure est d’identifier, d’évaluer et de contrôler tout changement potentiel pouvant impacter les réalisations planifiées. Elle comprend généralement les cinq activités de base suivantes :
Collecter Examiner Proposer Décider Mettre en œuvre
86 Charte de projet Identifiant
Description de la modification
Impact de la modification
Encadrant
Changement au niveau de l’encadrant.
Retard du travail. Eventuel changement de la démarche.
Outil technique (Pentaho BI Suite)
Changement de l’outil de travail.
Problèmes de compatibilité.
Version JIRA
Changement de version.
Pas de changement majeur, la base de données reste la même.
PROCEDURE DE GESTION DE LA COMMUNICATION L’objectif de cette procédure est de préparer le plan de communication du projet, il s’agit de : –Déterminer les événements nécessitant une communication. –Définir la personne responsable de la communication de l'information. –Définir le public. –Définir l’objectif de la communication. –Définir les médias de communication. –Définir le moment de la communication, la périodicité ou la fréquence de diffusion. –Définir les livrables de communication.
Evénement Démarrage d’une étape
Fin d’une étape du projet
Objectif de la communication Information des parties prenantes. Implication dans la démarche. Information des parties prenantes.
Public Cibles
Médias utilisés
Encadrants. MOA.
Présentation. Mail.
Encadrants. MOA.
Présentation. Mail.
PLAN DE PROJET Cette partie est utilisée pour décrire les éléments quand doit planifier dans le projet, il s’agit de définir les :
Dépendances entre les phases et les tâches Elaboration des échéanciers : date début, date fin
Le tableau suivant résume les tâches du projet :
87 Charte de projet N° tâche 1
Tâche
Durée
Date début
Date fin
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 10
Collecte du besoin Formulation du besoin
2,36j 0,79j
Lun 18/04/11 Jeu 21/04/11
Mer 20/04/11 Jeu 21/04/11
11
Négociation du tableau de bord
3j
Mar 19/04/11
Ven 22/04/11
12
Négociation des KPI
2,36j
Mar 19/04/11
Jeu 21/04/11
13
Formulation des KPI
0,64j
Ven 22/04/11
Ven 22/04/11
14
Etablissement du plan du projet
3j
Lun 25/04/11
Jeu 28/04/11
15
Elaboration de la charte du projet
4,57j
Lun 25/04/11
Lun 02/05/11
16
Elaboration du cahier de charges
4,57j
Lun 25/04/11
Lun 02/05/11
17
Modélisation multidimensionnelle
3j
Lun 02/05/11
Jeu 05/05/11
18
Etablissement du schéma multidimensionnel
1j
Ven 06/05/11
Lun 09/05/11
19
Etude des données sources
8,36j
Mar 10/05/11
Mar 24/05/11
20 21
Mapping Conception de la table de faits
3j 3j
Ven 13/05/11 Jeu 19/05/11
Mer 18/05/11 Mar 24/05/11
22
Documentation sur l'outil BI
2j
Lun 23/05/11
Mer 25/05/11
23 24 25
Processus ETL Analyse OLAP Restitution des données
7j 2,21j 2,21j
Mer 25/05/11 Mer 08/06/11 Lun 13/06/11
Mar 07/06/11 Ven 10/06/11 Mer 15/06/11
26
Tests de la solution
0,79j
Mer 15/06/11
Jeu 16/06/11
27
Intégration de la solution
0,79j
Jeu 16/06/11
Ven 17/06/11
28
Rédaction du rapport de stage
22j
Lun 09/05/11
Ven 17/06/11
88 Charte de projet
Cahier des charges Conception et développement d’une solution de reporting avancé et d’analyse multidimensionnelle afin d’étendre les capacités de l’outil JIRA au sein de l’entité GID
Nous reconnaissons que ce document utilise des éléments soumis au copyright, provenant du Modèle de cahier des charges Volere. Copyright © 1995 – 2007 the Atlantic Systems Guild Limited
Ces spécifications ont été rédigées par LOUTFI Ismail & TAOUR Marouane le 02 mai 2011.
89 Charte de projet
Lignes directrices du projet Finalité du projet Contexte du projet GID est un système budgétaire et comptable unifié et commun à l’ensemble des acteurs de la dépense publique qui vise à atteindre les objectifs suivants :
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’entité GID assure aussi un service d’assistance aux utilisateurs du système GID par le biais du centre d’assistance GID, c’est le service chargé de répondre aux demandes d’assistance aux utilisateurs et par conséquent assurer le bon fonctionnement du système et la durabilité des transactions. C’est ainsi qu’est né le besoin de mesure de la performance du service d’assistance. Le tableau de bord développé doit répondre au besoin suivant : -
Reporting sur le temps de réactivité du service.
Objectifs du projet Mesurer le temps de réactivité du service Enjeu Le temps de réactivité du service est un aspect majeur impactant la performance du centre d’assistance et a des impacts majeurs sur l’utilisation du système GID. Mesure de la performance La mesure s’effectue grâce à des Indicateurs clés de performance (KPI), en vue de réduire le temps de réactivité du centre ainsi que d’assurer une souplesse lors du transfert des demandes entre les différents axes d’assistance.
Les parties prenantes Maîtrise d’ouvrage : Le centre d’assistance en la personne de son directeur Mr. TIJANI Nadir suit le projet et est amené à décider des grandes orientations et objectifs prises lors des réunions effectués tout au long de ce stage. Maîtrise d'œuvre : La maîtrise d’œuvre est assurée par les deux étudiants stagiaires Mr. LOUTFI Ismail & Mr. TAOUR Marouane. Autres intervenants sur le projet : Assurent l’encadrement et le suivi du projet à travers les deux étudiants stagiaires Mr. LOUTFI Ismail & Mr. TAOUR Marouane:
Mr. AIRROUCHTE Imade, Ingénieur BI au sein de la Trésorerie Générale du Royaume.
90 Charte de projet
Mr. DAHCHOUR Mohammed : Télécommunications.
Mr. ZAOUIA Abdellah: Professeur à l’Institut National des Postes et Télécommunications.
Professeur
à
l’Institut
National
des
Postes
et
Utilisateurs finaux Centre d’assistance.
Contraintes Contraintes liées à l’environnement Contraintes sur la solution Contraintes techniques Le système décisionnel doit correspondre aux exigences métiers du centre d'assistance. L'utilisation des outils techniques suivants: SGBD : Oracle. Suite BI: Pentaho BI Suite. En outre le système doit vérifier : Accès à distance à la base de données décisionnelle. Capacité minimale de 40 Go. Inclusion de la présentation graphique de données. Autres dimensions du projet Démarche claire et méthodique du travail. Planification de projet. Confidentialité : Existence de données confidentielles (les données contenues dans la base de données JIRA). Environnement de fonctionnement du système actuel Pentaho User Console. Outils techniques utilisés : Outils techniques SGBD : Oracle 10g. Suite BI : Pentaho BI suite. Lieux de fonctionnement prévus Terminaux des utilisateurs Contraintes de calendrier Clôture du projet le 16 juin 2011 Contraintes de budget Néant
91 Charte de projet Conventions de dénomination Définitions Aiguillage : Orientation de la demande d’un axe vers un autre. Assistance (aux utilisateurs): Service aidant les utilisateurs à résoudre un incident ou un problème lors de l’utilisation d’un logiciel et assurant que le client a accès à un service informatique approprié. Bug : Erreur dans un programme informatique pouvant perturber son fonctionnement. Client : demandeur de service. Demande (d’assistance) : Demande faite par l'utilisateur d'une application informatique, concernant un incident rencontré, une évolution souhaitée, ou une mauvaise compréhension des règles de gestion. GID : Gestion Intégrée de la Dépense. Incident : arrêt ou dégradation d'un service. PRGID : Personne Ressource GID. Problème : origine d'un ou de plusieurs incidents récurrents Qualification : Désignation du type d’un incident. Référent : Assistants de second niveau (au niveaux des Trésoreries). REQ : Projet « assistance aux utilisateurs » Utilisateur : Personnes utilisant le système GID. Faits pertinents et hypothèses Faits Nombre de demandes gérés par jour ? (ainsi que leurs types) Règles métier Gestion des demandes : Le centre d’assistance prend en charge toutes les demandes reçues. Pour faire une demande au centre d’assistance, le référent ouvre un ticket de la demande qui est reçu par le centre d’assistance par l’intermédiaire du système JIRA. Le centre d’assistance et ouvre un projet dit projet REQ (ou projet assistance aux utilisateurs) pour la résolution de la demande. Chaque projet REQ est identifié grâce à un code. Le centre d’assistance n’ayant pas une vocation technique mais plutôt métier, il arrive qu’il ne soit pas capable de résoudre certains demandes d’assistance. C’est ici que les équipes fonctionnel et technique interviennent dans le processus. Une demande non résolue par le centre d’assistance est transférée à l’équipe fonctionnelle qui ouvre à son tour un nouveau projet dit projet SGID (système GID) concernant la demande, l’équipe déploiement (qui dépend directement du centre d’assistance) crée un lien entre ce projet SGID et le projet REQ correspondant, ce dernier reste ouvert jusqu'à la résolution de l’incident.
92 Charte de projet L’équipe technique se charge de la résolution technique des incidents qui nécessitent une correction dans le code source du système, l’équipe déploiement technique déploie les solutions élaborées par l’équipe technique. Etat des demandes dans JIRA: Il y a cinq états qu’une demande peut avoir dans JIRA :
Ouverte. En cours de traitement. Traitée. Réouverte. Fermée.
Exigences fonctionnelles Portée du projet (description de l’existant) La situation actuelle Reporting sur le temps de réactivité: Pas de reporting prenant en considération la dimension temps, les informations sont tirés manuellement en consultant le temps d’ouverture et de fermeture. Historique de demandes: Pas de reporting avancé sur l’historique des demandes ainsi que leur résolution Evénements métiers : Ouverture de la demande (Ticket).
Ouverture du projet REQ.
Qualification de la demande.
Traitement de la demande.
Création du projet SGID.
Liaison du projet SGID au projet REQ.
Transfert de la demande du centre d’assistance vers l’équipe fonctionnelle.
Transfert de la demande de l’équipe fonctionnelle vers l’équipe technique.
Résolution technique de l’incident.
Déploiement de la solution technique.
Transfert de la demande de l’équipe technique vers l’équipe fonctionnelle.
Transfert de la demande de l’équipe fonctionnelle vers le centre d’assistance.
Réponse au référent.
Réouverture par le référent.
93 Charte de projet Liste des exigences fonctionnelles Descriptif des processus métiers Il faut respecter les processus métiers suivants Workflow JIRA : Le schéma suivant représente le processus de traitement des demandes dans JIRA
Figure 25: Workflow JIRA
Workflow axes des services :
Le schéma suivant, représentant le workflow des axes des services, représente les différentes interactions entre les axes de l’assistance GID
Centre d’assistance
Equipe fonctionnelle
Equipe Déploiement technique
Equipe Technique
Figure 26: Workflow axes de service
94 Charte de projet Gestion de l’historique : Stocké au niveau de la base de données JIRA.
Exigences liées à la construction de la solution Mise en œuvre Planning Global Du 15 /03/2011 au 16/06/2011 Organisation de projet Des personnes ressources seront affectées au projet. Il est prévu, pendant la durée du projet :
Les stagiaires: Mr. LOUTFI Ismail, Mr. TAOUR Marouane. Les encadrents: Mr. AIRROUCHTE Imade, Mr. DAHCHOUR Mohammed, Mr. ZAOUIA Abdellah.
Risques Compréhension du besoin: Mauvaise compréhension du CDC par le MOE.
Mauvaise conception et spécification du projet: Conception/spécification non identiques au besoin.
Délai: Terminer plus tard que prévu.
Panne matérielle ou logicielle : Panne des machines ou des environnements du travail.
Coûts Sans objet.
95 Charte de projet
Table de matières Contenu Contexte général .............................................................................................................................. 8
I.
Le projet décisionnel ........................................................................................................................... 8 Informatique décisionnelle (Business Intelligence) ........................................................................ 8 Le Projet décisionnel....................................................................................................................... 8 Le Reporting .................................................................................................................................. 10 1.
Organisme d’accueil : La Trésorerie générale du royaume ..................................................... 10 Missions de la Trésorerie Générale du Royaume .......................................................................... 10 Organisation .................................................................................................................................. 11 Entité chargée du Projet de Gestion Intégrée de la Dépense ......................................................... 11
II.
Méthodologie de travail ............................................................................................................... 15 Nécessité d’une démarche de travail ............................................................................................... 15 Choix de la démarche ....................................................................................................................... 15 Etude Benchmarking..................................................................................................................... 15 Comparaison des démarches et choix de la démarche du projet ................................................... 20 1.
Adaptation de la démarche au contexte du projet...................................................................... 20 Phase I : Identification ................................................................................................................... 21 Phase II : Conception .................................................................................................................... 21 Phase III : Mise en œuvre .............................................................................................................. 22 Phase IV : Amélioration permanente ............................................................................................ 22
Planification du projet ....................................................................................................................... 22 III.
Phase d’identification ................................................................................................................ 25
Etape 1 : Environnement de l’entreprise ........................................................................................... 25 Détermination de l’organisme concerné ........................................................................................ 25 Organisation de l’assistance .......................................................................................................... 25 Procédure de la gestion des incidents ............................................................................................ 25 Objectifs stratégiques .................................................................................................................... 26 Mode de Management ................................................................................................................... 27 Clients de l’organisme ................................................................................................................... 27 Etape 2: Identification des processus .............................................................................................. 27 Cycle de vie fonctionnel ................................................................................................................ 27
96 Charte de projet Analyse des différents interactions ................................................................................................ 28 Workflows ..................................................................................................................................... 30 IV.
Phase de conception .................................................................................................................. 33
Etape 3 : Choix des objectifs ............................................................................................................. 33 Caractéristiques d’un objectif : .................................................................................................. 33 Démarche de choix des objectifs ................................................................................................ 33 Etape 4 : Construction du tableau de bord ................................................................................... 34 Etape 5 : Choix des indicateurs ...................................................................................................... 35 Caractéristiques des KPI ............................................................................................................ 35 Choix des KPI ............................................................................................................................... 36 Elaboration de la charte du projet et du cahier de charges..................................................... 37 Etape 6: Collecte des informations ................................................................................................ 38 Modélisation multidimensionnelle ................................................................................................ 38 Schéma multidimensionnel ........................................................................................................... 40 Etape 7 : Système du tableau de bord................................................................................................ 49 Mise en œuvre ............................................................................................................................... 51
V.
Etape 8 : Choix de l’outil décisionnel ............................................................................................... 51 Etape 9 : Déploiement et intégration ................................................................................................. 54 Alimentation du datawarehouse .................................................................................................... 54 Analyse de données ....................................................................................................................... 59 Alimentation du tableau de bord ................................................................................................... 63 Intégration de la solution ............................................................................................................... 69 VI.
Amélioration permanente .......................................................................................................... 71
Etape 10 : Audit du système .............................................................................................................. 71 Conclusion ............................................................................................................................................. 72 Références ............................................................................................................................................. 77 Bibliographie ..................................................................................................................................... 77 Webographie .................................................................................................................................... 77 Charte de projet ..................................................................................................................................... 79 DESCRIPTION DU PROJET ..................................................................................................... 80 STRATÉGIE DE RÉALISATION ............................................................................................. 84 PROCEDURE DE GESTION DES RISQUES ........................................................................ 84 PROCEDURE DE GESTION DE CHANGEMENT .............................................................. 85 PROCEDURE DE GESTION DE LA COMMUNICATION ................................................ 86
97 Charte de projet PLAN DE PROJET ....................................................................................................................... 86 Lignes directrices du projet ............................................................................................................... 89 Finalité du projet ........................................................................................................................... 89 Les parties prenantes ..................................................................................................................... 89 Contraintes ........................................................................................................................................ 90 Contraintes liées à l’environnement .............................................................................................. 90 Terminaux des utilisateurs............................................................................................................. 90 Conventions de dénomination ....................................................................................................... 91 Faits pertinents et hypothèses ........................................................................................................ 91 Exigences fonctionnelles ................................................................................................................... 92 Portée du projet (description de l’existant).................................................................................... 92 Liste des exigences fonctionnelles ................................................................................................ 93 Exigences liées à la construction de la solution ................................................................................ 94 Mise en œuvre ............................................................................................................................... 94 Risques .......................................................................................................................................... 94 Coûts.............................................................................................................................................. 94
