Rapport de fin d'étudesrime.emi.ac.ma/ressources_numériques/MISE EN PLACE D... · 2012-05-31 · 2011 III Rapport Projet de Fin d’Etudes -2012 Dédicaces Je dédie ce travail

I

Rapport Projet de Fin d’Etudes 2011-2012

II


Dédicaces Je dédie ce travail à : Ma mère :

Qui m’a toujours comblé d’amour et d’affection. Son dévouement et ses

sacrifices resteront pour moi une ligne de conduite, sa patience et sa

compréhension un emblème.

Avec tout mon amour et ma reconnaissance.

Mon père :

A qui je dois tout, pour toute la compréhension, l’aide et la confiance

qu’il m’a toujours accordées.

En témoignage de mon infinie reconnaissance et ma profonde gratitude.

Mes deux sœurs Hanane et Ouissal :

Vous êtes une partie de moi-même, alors, trouvez dans ce travail

l’expression de mes vœux les plus ardents de bonheur et de réussite.

Mon chère amie et camarade de stage Meryem :

Pour toi seule, dont la sympathie, la compréhension et le soutien n’ont

d’égal, je dédie ce travail.

Briller davantage, sera pour toi mon souhait le Plus cher.

Mon cher ami Saad :

Pour moi, tu n’es pas seulement un ami d’enfance mais aussi un frère.

Les sacrifices que tu as consentis pour mon bien être sont sans bornes.

Que ce travail te traduit ma profonde affection, ma gratitude et mes

respects.

Tous ceux que j’aime et qui m’aiment.

Yassine

III


Dédicaces

Je dédie ce travail :

A ma mère, pour son amour, son dévouement sans égal, et son soutien, puisse dieu la garder,

A mon père, auquel je dois le plus grand respect pour son

expérience, et qui sans ses encouragements en toutes circonstances, ses

sacrifices et son soutien jamais je n’aurai pu être ce que je suis,

A mon cher petit frère Othmane,

A mon cher ami et collègue de travail Yassine, pour son soutien, sa

présence et ses délicates attentions,

A toute ma famille,

A tous mes amis et à toutes les personnes qui m’ont soutenu de

près ou de loin,

Meryem

IV


REMERCIEMENTS

Avant d’entamer ce rapport, nous tenons à témoigner notre profonde

gratitude à toutes les personnes qui ont participé de loin ou de près à

l’élaboration de ce travail.

Nos sincères remerciements sont à adresser à notre parrain de stage M.

Abdelkader MHAYI, Chef du service des études et de la coordination à la

division de l’informatique et des méthodes du ministère de la santé, et à M. Saïd

ZOUMMANE pour l’intérêt et le professionnalisme avec lesquels ils ont suivi la

progression de notre travail, et pour leurs aides et conseils fructueux qu’ils n’ont

cessé de nous prodiguer durant toute la durée de notre projet.

Nous tenons à exprimer notre profonde gratitude, ainsi que nos vifs

remerciements et nos sentiments les plus respectueux à M. Driss GHANAMI,

notre professeur, qui a fait preuve de disponibilité à chaque fois que nous avions

besoin de son soutien. Son encadrement et ses conseils nous ont été d'un appui

considérable.

Nos remerciements vont également à M. Samir BENNANI, qui a accepté

de nous faire l’honneur de présider notre jury, à Mlle Sara BOUCHIKHI, notre

rapporteuse de soutenance, ainsi qu’à tout le personnel de la division de

l’informatique et des méthodes du ministère de la santé, qui nous ont soutenu et

coopéré avec nous tout au long de notre stage.

Enfin nous ne saurions oublier l’intégrité du corps enseignant du génie

informatique pour nous avoir dispensés une formation de qualité durant ces trois

dernières années.

V


RESUME

Durant les dix dernières années, l’informatique décisionnelle a prouvé sa capacité à

simuler l’avenir et à anticiper les tendances du marché. En effet, elle offre aux responsables

la possibilité de maîtriser l’information stratégique et de rehausser leurs performances.

Notre projet de fin d’études au sein du ministère de la santé s’aligne parfaitement sur

cette vision. L’objectif de notre projet est de mettre en place une solution décisionnelle afin de

mieux gérer l’ensemble des informations médicales et administratives relatives au système

d’information hospitalier. Nous nous sommes particulièrement intéressés aux services des

urgences et des consultations externes.

Dans cet intérêt, nous avons veillé à suivre une démarche coopérative de gestion,

fondée sur les bons principes de l’informatique décisionnelle qui est la méthodologie

«GIMSI». Ensuite, tout en respectant les étapes de cette méthode de gestion, nous avons

débuté par définir l’environnement concernant les besoins du ministère ainsi que les objectifs

de notre projet, et avant de nous pencher sur l’aspect conceptuel pour la modélisation

multidimensionnelle de nos données relatives aux services des urgences et des consultations

externes, il a fallu, tout d’abord, procéder par rétro-ingénierie de la base de données source

afin d’établir un modèle conceptuel de données qui nous a été utile pour réaliser notre travail.

Nous avons également entamé l’élaboration des indicateurs clés et des axes d’analyse pour

concevoir les modèles multidimensionnels des datamarts «Urgences» et «Consultations

Externes». Par la suite, on a entamé la partie relative à la mise en œuvre de notre travail en

utilisant la suite Microsoft SQL Server 2008 R2, et ce, en commençant par la phase

d’extraction, transformation et chargement des données, ensuite la création des cubes OLAP

avant de générer les rapports relatifs aux deux services.

Le travail réalisé dans notre projet de fin d’études constitue un moyen de prédilection

des responsables du ministère de la santé qui met à leur disposition de l’information

pertinente pouvant aider à la bonne prise de décision concernant la gestion hospitalière.

VI


ABSTRACT

During the last decade, the business intelligence has proven its ability to simulate the

future and to anticipate the market trends. Indeed, it provides to managers the possibility to

manage strategic information and to enhance their performance.

Our graduation project conducted at the ministry of health aims at the establishment of

a Business Intelligence solution so as to manage better medical and administrative

information related to the hospital information system (HIS). We were particularly interested

in the «Emergencies» and «External Consultations» services.

In this interest, we were sure to follow a cooperative approach of project management

based on the best fundamentals of the Business Intelligence; this approach is named «GIMSI».

By following the steps of this method, we started our project by defining the ministry

of health needs’ so as the objectives of our project, and before we fulfill the conceptual aspect

concerning the multidimensional modeling of data, it was necessary to appeal to the reverse

engineering of our data source so as to establish a conceptual model that would be helpful for

the achievement of our work. Also, we set a list of key performance indicators and the axes of

analysis following a serie of interviews with the ministry managers, after which logical

multidimensional models were designed. The establishment of such information system

requires the use of very specific tools, in our case; we used Microsoft SQL Server 2008 R2.

This suite allowed us to go through the extracting, transforming and loading data process, the

creation of OLAP cubes and finally the generation of reports and statistics.

Thus, our graduation project is a useful way to provide the ministry of health

managers’ relevant information that may assist them in making the right decisions related to

the hospitals management.

VII


ملخص

.أثبت نظام دعم و اتخاذ القرارات قدرته على التنبؤ وتوقع اتجاهات السوق ,خالل العقد الماضي

بالفعل، فهو يمنح المسؤولين القدرة على التحكم في المعطيات و الرفع من قيمتها.

تنفيذ حل والهدف من مشروعنا هو مشروع تخرجنا في وزارة الصحة يحاذي تماما هذه الرؤية.

أفضل لجميع المعلومات الطبية واإلدارية المتعلقة بنظام معلومات استقصاء المعلومات من أجل إدارة

.الخارجية العيادات المستشفى. نهتم اهتماما خاصا بأقسام الطوارئ و

، مبني على المبادئ ”GIMSI“في هذه المنوال تأكدنا من اتباع نهج تعاوني لإلدارة يدعى

الجانب حاولنا تسليط الضوء على ,لمنهجية استقصاء المعلومات، ومع احترام خطوات هذا النهجالسليمة

و ذلك بعد دراسة معمقة الخاص بتصميم النموذجين المتعلقين بقسمي المستعجالت و العيادات الخارجية

يم نموذج شامل متعدد بعد ذلك تم تحديد مؤشرات األداء الرئيسية و كذا محاور التحليل لتصم .للنظم القائمة

، بدأ R2 00 revre QQS MICROSOFT باستخدام قمنا ،المشروعومن أجل تحقيق هذا .األبعاد

قبل استخراج التقارير "OLAP" من مرحلة االستخراج، وتحويل وتحميل البيانات، ثم خلق مكعبات

المتعلقة بكل الخدمات.

لما توفره لهم ناجعة لمسؤولي وزارة الصحة األعمال المنجزة في مشروع تخرجنا تعتبر وسيلة

.الخاصة بإدارة المستشفى يمكن أن تساعدهم في اتخاذ القرارات المناسبة من معلومات

VIII


Liste des figures

Figure I-1 : Logo du Ministère de la Santé ................................................................................ 2

Figure I-2 : Organigramme du Ministère de la santé ................................................................. 3

Figure I-3 : Chaine décisionnelle [7] .......................................................................................... 4

Figure I-4 : Modèle en étoile [7] ................................................................................................ 6

Figure I-5 : Modèle de schéma en flocon [7] ............................................................................. 7

Figure I-6 : Modèle en constellation [7] ...................................................................................... 7

Figure I-7 : Diagramme de Gantt de l’avancement .................................................................. 12

Figure I-8 : Organisation de l’hôpital [5] ................................................................................. 13

Figure II-1 : Diagramme d’activités d’un passage aux urgences ............................................. 16

Figure II-2 : Modèle conceptuel de données ............................................................................ 18

Figure II-3 : Modèle en étoile du datamart « Urgences » ........................................................ 26

Figure II-4 : Modèle en étoile du datamart consultations externes .......................................... 27

Figure II-5 : Schéma du Datawarehouse .................................................................................. 28

Figure III-1 : Les outils de MS SQL Server 2008 R2 [12] ...................................................... 31

Figure III-2 : Architecture fonctionnelle d’Oracle BI Suite [15] ............................................. 31

Figure III-3 : Fonctionnalités de Pentaho ................................................................................. 32

Figure III-4 : Architecture fonctionnelle de la suite Microsoft SQL Server 2008 R2 [13] ..... 35

Figure IV-1 : Processus ETL de la dimension Personnel Sanitaire ......................................... 40

Figure IV-2 : Processus ETL de la dimension Services ........................................................... 41

Figure IV-3 : Processus ETL de la table de fait « Fait_Urgences » ......................................... 42

Figure IV-4 : Interface de SSAS .............................................................................................. 44

Figure IV-5 : Exemple d’analyse sur le cube des Urgences .................................................... 45

Figure IV-6 : Exemple de rapport réalisé à l’aide de Report Builder ...................................... 46

Figure IV-7 : Rapport sur les consultations externes par sexes ............................................... 46

Figure IV-8 : Un tableau de bord pour les urgences ................................................................ 47

Liste des tableaux

Tableau I-1 : Les 10 étapes de la méthode GIMSI [4] ............................................................. 10

Tableau I-2 : Tableau des tâches .............................................................................................. 11

Tableau II-1 : Description des tables ........................................................................................ 19

Tableau II-2 : Les dimensions hiérarchiques ........................................................................... 23

Tableau II-3 : Axe d’analyse Géographie ................................................................................ 24

Tableau III-1 : Tableau comparatif des suites décisionnelles choisies .................................... 32

Tableau III-2 : Principaux fonctionnalités de MS SQL Server 2008 R2 [13] .......................... 34

Tableau III-3 : Architecture technique de la suite MS SQL Server 2008 R2[13] .................... 36

Tableau III-4 : Découpage fonctionnel de MS SharePoint 2010 ............................................. 37

IX


Sigles et abréviations

DIM Division de l’informatique et des méthodes

SIH Système d’information hospitalier

SIS Système d’information sanitaire

SIG-HO Système de gestion hospitalière

KPI Key performance indicator (Indicateur de performance)

BIDS Business Intelligence Development Studio

SSIS SQL Server Integration Services

SSAS SQL Server Analysis Services

SSRS SQL Server Reporting Services

ETL Extraction-Transformation-Chargement

OLAP Online Analytical Processing

BI Business Intelligence

ERP Entreprise Resource Planning

SGBD Système de gestion de bases de données

OLTP On-Line Transactional Processing

ROLAP Relational OLAP

MOLAP Multidimensional OLAP

HOLAP Hybrid OLAP

DWH Datawarehouse (Entrepôt de données)

MS Microsoft

OS Open source

MDX Multidimensional Expressions

X


Sommaire

Introduction ................................................................................................................................ 1

I. Présentation générale du projet ........................................................................................... 2

1. Présentation de l’organisme d’accueil : .......................................................................... 2

1.1. Objectifs du ministère de la santé : ...................................................................................... 2

1.2. Organisation du ministère de la santé : ................................................................................ 3

1.3. Division de l’informatique et des méthodes : ...................................................................... 3

2. Cadre général du projet : ................................................................................................. 4

2.1. Définition de l’informatique décisionnelle : ........................................................................ 4

2.2. Architecture décisionnelle : ................................................................................................. 4

2.3. Processus d’Extraction, Transformation et Chargement : ................................................... 5

2.4. Modélisation dimensionnelle : ............................................................................................ 5

2.5. Serveur OLAP : ................................................................................................................... 7

3. Cadre spécifique du projet : ............................................................................................ 8

3.1. Contexte du projet : ............................................................................................................. 8

3.2. Problématique : .................................................................................................................... 8

3.3. Objectifs et démarches : ...................................................................................................... 9

3.4. Planning du projet : ........................................................................................................... 11

4. Identification de l’environnement : ............................................................................... 12

4.1. Système d’information sanitaire: ....................................................................................... 12

4.2. Système d’information hospitalier : .................................................................................. 12

4.3. Le progiciel de gestion intégré « KEWAN » .................................................................... 13

II. Conception ........................................................................................................................ 14

1. Analyse de l’existant : ................................................................................................... 14

1.1. Retro-Ingénierie : .............................................................................................................. 15

1.2. Modèle conceptuel de données .......................................................................................... 17

2. Conception multidimensionnelle ................................................................................... 20

2.1. Détermination des KPI ...................................................................................................... 20

2.2. Détermination des axes d’analyse ..................................................................................... 22

2.3. Description détaillée des axes d’analyse ........................................................................... 24

2.4. Conception des modèles multidimensionnels.................................................................... 25

III. Présentation des outils utilisés....................................................................................... 30

1. Comparaison des suites décisionnelles : ....................................................................... 30

XI


1.1. Présentation des suites décisionnelles : ............................................................................. 30

1.2. Tableau comparatif des suites BI : .................................................................................... 32

2. Présentation de la suite Microsoft SQL Server 2008 R2 : ............................................ 33

2.1. Principaux composants et fonctionnalités : ....................................................................... 33

2.2. Fonctionnalités détaillées par produits : ............................................................................ 34

2.3. Architecture fonctionnelle : ............................................................................................... 35

2.4. Architecture technique : .................................................................................................... 35

2.5. Stratégie vis-à-vis du monde de la santé ........................................................................... 36

3. Présentation de Microsoft SharePoint 2010 .................................................................. 36

IV. Réalisation ..................................................................................................................... 39

1. Phase d’extraction, transformation et chargement: ....................................................... 39

2. Phase de création des cubes OLAP ............................................................................... 43

3. Génération des rapports ................................................................................................. 45

4. Génération des tableaux de bord ................................................................................... 46

V. Conclusion générale .......................................................................................................... 49

Glossaire ................................................................................................................................... 50

Bibliographie ............................................................................................................................ 51

Annexe 1 : Méthodologie de conduite de projet GIMSI .......................................................... 53

Annexe 2 : Caractéristiques de l’outil DbVisualiser ................................................................ 61

Annexe 3 : L’outil Report Builder 3.0 ..................................................................................... 65

1


Introduction

L'hôpital est un établissement de production des soins. Il utilise à cette fin

des ressources humaines, matérielles et financières. Son organisation et sa gestion

obéissent à des règles et des procédures qui doivent être claires, précises et bien

comprises par l'ensemble des acteurs. La mission et les objectifs de l'hôpital

deviennent la finalité première de cette organisation. Le système de santé

marocain a réalisé des évolutions notables et ce par l'introduction de nouveaux

outils de gestion, et d'autonomie financière pour l'amélioration de la qualité des

services. Pour cela, la mise en place d'un système d'information décisionnel

s'avère fondamentale comme outil de gestion des différents matériels et ressources

et aussi comme outil de prise de décision.

A cet égard, la Division de l’Informatique et des Méthodes, dans le cadre

des objectifs de la réforme hospitalière qui vise à doter l'hôpital public de

structures et de méthodes modernes de gestion, opte pour une solution

décisionnelle afin de mieux gérer les différents services du système d’information

hospitalier. On appelle une solution décisionnelle une solution informatique

permettant l’analyse des données d’une entreprise, afin d’en dégager des

informations qualitatives nouvelles, qui seront la base de décisions, qu’elles soient

tactiques ou stratégiques.

Dans ce cadre s’inscrit notre projet de fin d’études qui consiste en la mise

en place d’une solution décisionnelle pour le ministère de la santé afin de mieux

gérer l’ensemble des informations médicales et administratives relatives au

système d’information hospitalier. Notre mission a débuté d’abord par une étude

approfondie de ce dernier ainsi qu’une étude des besoins, ensuite, on s’est orienté

vers l’aspect conception suivi par une étude de l’outil de travail avant de nous

pencher sur la réalisation de notre projet.

2


Chapitre 1

I. Présentation générale du projet

Afin de mettre en évidence le contexte dans lequel s’inscrit notre projet, ce chapitre

présente, dans un premier temps, l’organisme d’accueil dans lequel notre stage a été effectué, le

ministère de la santé. Il aborde, dans un second temps une étude bibliographique sur

l’informatique décisionnelle suivie par le contexte, les objectifs et la planification de notre

projet, finalement une étude du système d’information de l’environnement dans lequel s’inscrit

notre projet.

1. Présentation de l’organisme d’accueil :

1.1. Objectifs du ministère de la santé :

Figure ‎I-1 : Logo du Ministère de la Santé

Le ministère de la santé est chargé de l'élaboration et de la mise en oeuvre de la

politique gouvernementale en matière de santé. Il agit, en liaison avec les départements

concernés, en vue de promouvoir le bien-être physique, mental et social des habitants.

Dans le cadre de la stratégie 2008-2012 adoptée par le ministère de la santé et qui

consiste à permettre au système national de la Santé de jouer pleinement son rôle, les objectifs

suivants doivent être atteints [2] :

Moraliser le secteur de la santé.

Assurer l'équité de l'offre de soins entre régions et entre le milieu rural et urbain.

Faciliter l'accès aux soins pour les plus démunis et surtout pour la population rurale.

Rendre au citoyen la confiance dans le système de santé par l'amélioration de l'accueil,

l'information, les urgences, la propreté, l'équité, la disponibilité des médicaments, etc.

Réduire le coût des soins de santé et des médicaments.

Renforcer la veille et la sécurité sanitaire.

3


1.2. Organisation du ministère de la santé :

La figure I-2 présente l’organigramme du ministère de la santé [W1].

Figure ‎I-2 : Organigramme du Ministère de la santé

1.3. Division de l’informatique et des méthodes :

La Division de l’informatique et des Méthodes (DIM) est chargée de :

Animer les activités informatiques du ministère par l’élaboration et la gestion d’un

schéma directeur ainsi que par des travaux d’études et de réalisation.

Apporter son appui technique en matière d’informatisation aux services centraux et aux

services extérieurs.

Définition des besoins du Ministère de la Santé en fournitures informatiques en

concertation avec les utilisateurs.

Gestion de l’ensemble de la documentation technique du Ministère de la Santé.

4


2. Cadre général du projet :

Le présent projet vise à mettre en place une solution d’aide à la décision et cadre ainsi

avec les systèmes d’information décisionnels (SID). Pour mieux comprendre les concepts

inhérents à ce domaine, nous étions amenées à mener une étude bibliographique que nous

présentons dans ce qui suit.

2.1. Définition de l’informatique décisionnelle :

Avant de nous pencher sur les composants de la chaine décisionnelle, il est important

de définir l’informatique décisionnelle ou la BI (Business intelligence) et parfois appelée tout

simplement « le décisionnel ». Elle peut être définie comme l'exploitation des données de

l'organisme dans le but de faciliter la prise de décision par les décideurs, c'est-à-dire la

compréhension du fonctionnement actuel et l'anticipation des actions pour un pilotage éclairé

de l'organisme.

Les outils décisionnels sont basés sur l'exploitation d'un système

d'information décisionnel alimenté grâce à l'extraction de données diverses à partir des

données de production, d'informations concernant l'organisme ou son entourage et de données

économiques.

2.2. Architecture décisionnelle :

Une architecture BI, illustrée par la figure I.3, est un ensemble de concepts, de méthodes,

de technologies et d’outils (logiciels ou matériels) permettant de répondre aux besoins

stratégiques de l’entreprise.

Figure ‎I-3 : Chaine décisionnelle [7]

Cette architecture fait intervenir l’entrepôt de données ou datawarehouse, qui peut être

défini comme un point de stockage de toutes les données utilisées par le système pour

5


analyser les informations. C’est un ensemble de données historisées variant dans le temps,

organisé par sujets, consolidé dans une base de données unique, géré dans un environnement

de stockage particulier, aidant à la prise de décision dans l’entreprise. [9]

Cet entrepôt rassemble des données issues de plusieurs sources hétérogènes (bases de

production de l'entreprise, fichiers plats, documents web, etc.). Ces données sont extraites,

transformées et chargées au moyen d’outils ETL (Extraction, Transformation, Loading)

durant la phase d’alimentation.

Le Datawarehouse est généralement constitué de plusieurs Datamarts qui sont des

petits magasins de données. Chaque Datamart concerne un domaine bien particulier comme la

vente, l’achat ou la finance.

Pour permettre leur analyse interactive et rapide, les données d’un entrepôt sont

ensuite représentées de manière multidimensionnelle sous forme de cubes de données et

analysées par des serveurs OLAP que nous allons présenter par la suite.

Des générateurs de rapport sont également utilisés durant la phase d’analyse afin de

permettre aux utilisateurs finaux ou décideurs de mieux appréhender et interpréter les résultats

d'analyses.

2.3. Processus d’Extraction, Transformation et Chargement :

Les processus ETL (Extraction, Transformation et Chargement) prennent en charge la

récupération des données depuis l'ensemble des sources opérationnelles existantes et de les

charger vers le système décisionnel:

Extraction des données des bases de données opérationnelles (ERP, SGBD, fichiers,

etc.)

Transformation de ces données pour nettoyer, conformer, standardiser, documenter et

corriger.

Chargement des données dans le système décisionnel: Datawarehouse, Datamart, ou

Cube.

2.4. Modélisation dimensionnelle :

Un projet décisionnel comprend très souvent la mise en place d’un datawarehouse. Sa

modélisation est un travail important qui n’autorise pratiquement aucune erreur. Même sur

deux projets traitant les mêmes données, on peut obtenir deux modélisations pertinentes très

différentes. Ceci vient du fait qu’une modélisation décisionnelle dépend étroitement des

besoins du client et des objectifs du projet décisionnel.

La modélisation de l’entrepôt de données peut suivre l’un des modèles

multidimensionnels de construction de données, à savoir le modèle en étoile, le modèle en

flocon ou le modèle en constellation. Ces modèles font intervenir une table de faits ainsi que

des tables de dimensions.

6


En effet, la table de faits contient les données (faits) qui représentent la valeur des

mesures (KPI) sur lesquelles va porter l’analyse, quant aux dimensions, elles présentent les

axes avec lesquels on veut faire l’analyse. On trouve par exemple une dimension client, une

dimension produit, etc.

Schéma en étoile

Un modèle en étoile se caractérise par la présence de branches autour de la table de

fait. C’est une façon de mettre en relation les dimensions et les faits dans un entrepôt de

données. Le principe consiste à ce que les dimensions soient directement reliées à une table de

fait.

Dans le schéma en étoile, la table de fait contient les clés primaires des tables de

dimensions qui sont reliées avec elle. Le schéma suivant montre un exemple d’un schéma en

étoile avec une table de fait et cinq tables de dimensions.

Figure ‎I-4 : Modèle en étoile [7]

Schéma en flocon:

Un autre modèle de mise en relation des dimensions et des faits dans un entrepôt de

données est le modèle en flocon de neige. Le principe étant qu'il peut exister des hiérarchies

de dimensions et qu'elles soient reliées à la table de faits. Avec ce schéma, chacune des

dimensions est décomposée selon sa hiérarchie. Par exemple: Date, Mois, Année.

La figure ci-dessous montre un exemple d’un schéma en flocon de neige.

7


Figure ‎I-5 : Modèle de schéma en flocon [7]

Modèle en constellation:

La modélisation en constellation consiste à utiliser plusieurs modèles en étoiles et qui

ont des tables de dimensions communes. Un modèle en constellation comprend donc

plusieurs tables de faits et des tables de dimensions communes ou non à ces tables de faits.

Figure ‎I-6 : Modèle en constellation [7]

2.5. Serveur OLAP :

Le serveur OLAP ou le serveur d’analyse est un serveur de base de données

multidimensionnelle. Il est opposé au serveur OLTP et a pour but d'organiser les données à

analyser par domaine/thème et d'en ressortir des résultats pertinents pour le décideur.

8


Il existe trois approches pour la modélisation d’un datawarehouse :

MOLAP : Multidimensional OLAP

- La structure de stockage est en cube.

- Accès direct aux données dans le cube.

ROLAP : Relational OLAP

- Les Données sont stockées dans un SGBD relationnel.

- Un moteur OLAP permet de simuler le comportement d'un SGBD multidimensionnel.

HOLAP : Hybrid OLAP

- Les données sont stockées dans un SGBD relationnel (données de base).

- La structure de stockage est en cube (données agrégées).

3. Cadre spécifique du projet :

3.1. Contexte du projet :

Le ministère de la santé dispose d’un système d’information qui se compose de :

Système d’information sanitaire.

Système d’information Ressources Humaines.

Système d’information des marchés financiers.

Système d’information des équipements.

Dans le cadre de l’amélioration de son système d’information hospitalier, le ministère

de la santé a mis en place un projet pour « la fourniture et installation de progiciels pour le

système d’information hospitalier avec intégration », le projet concerne cinq hôpitaux de cinq

villes du pays, une société espagnole maître d’ouvrage a implanté en premier lieu un progiciel

nommé « KEWAN » à l’hôpital Hassan II d’Agadir avant de poursuivre l’implantation dans

les quatre sites restants. [3]

Puisque toutes les activités du ministère se présentent sous forme de projets et que la

bonne conduite de ces derniers et la gestion efficace des différentes ressources est l’objectif de

tout organisme, la nécessité d’une vision d’ensemble des activités et d’un suivi précis acquiert

toute son importance dans la stratégie du ministère.

A cet égard, le ministère de la santé a jugé nécessaire d’améliorer les services de son

système d’information par la mise en place d’une solution d’aide à la décision afin d’assurer une

gestion efficace des ressources matérielles, financières et humaines.

Pour ce qui est de notre travail, nous nous sommes focalisés sur l’aspect hospitalier. De

ce fait, notre projet est concentré autour du système d’information hospitalier.

3.2. Problématique :

Dans le cadre de la réforme hospitalière qui contribue au déploiement des fondations de

l’hôpital de demain, le ministère de la santé fournit des efforts considérables pour améliorer le

niveau de la santé au Maroc et améliorer son système d’information de gestion hospitalière

9


« SIG-Ho ». Ce dernier occupe une place prépondérante dans le système de santé marocain et

permet au ministère de la santé de regrouper, classifier et emmagasiner l’information qui pourrait

être utile pour les activités futures du ministère.

Malgré les efforts notables du ministère de la santé, force est de constater aujourd’hui, le

système de santé marocain souffre de quelques dysfonctionnements tels que la difficulté d’accès

aux soins, la gestion non satisfaisante des hôpitaux, et aussi les difficultés liées aux ressources

humaines. A cet égard, le ministère de la santé a mis en évidence le besoin d’intégrer l’aspect

décisionnel au système d’information existant afin de mieux gérer toutes les données en

dégageant des informations qualitatives nouvelles qui seront la base de décisions importantes

telles que l’octroi des budgets par centre hospitalier, la répartition du personnel sur les hôpitaux,

le besoin des équipements médicaux par centre hospitalier, etc.

L’intégration de ce type de solutions au ministère de la santé va permettre le

développement de ce dernier sur le niveau technologie de l’information et va lui fournir des

statistiques permettant le bon suivi des différentes activités hospitalières. Tâche qu’on ne saurait

effectuer sans avoir en main des indicateurs clés. A cet égard, s’annonce la nécessité et le besoin

d’établir des KPI (Key performance indicator) afin que les responsables puissent en extraire des

informations qui leur serviront au meilleur accomplissement de leurs objectifs.

3.3. Objectifs et démarches :

Nos objectifs, vis-à-vis de la problématique est de fournir un outil décisionnel qui

permettra aux responsables du ministère de la santé de:

• Contrôler la répartition des budgets aux différents établissements de santé.

• Prévoir tout manque de ressources humaines ou matérielles dans les services des

établissements sanitaires.

• Visualiser des rapports sur des épidémies données, leurs taux et zones de propagations.

• Avoir une image sur l’aspect gestionnaire des centres hospitaliers : retards des rendez-

vous, etc.

Concernant la démarche du projet, nous avons adopté une démarche qualité de conduite

de projets appelée GIMSI, qui est une méthode coopérative et complète de conception de

systèmes d'aide à la décision. Cette méthode définit un cadre méthodologique afin de mieux

formaliser les conditions de réussite des projets tableaux de bord et privilégie la coopération et le

partage de la connaissance. [4]

En effet, notre choix est dû à plusieurs raisons :

• La méthode GIMSI permet de réaliser le projet décisionnel dans sa totalité, de la

conception à la mise en œuvre.

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

• GIMSI est une approche centrée sur le décideur.

10


• L’utilisation de GIMSI est gratuite.

• La méthode s’intéresse aussi à l’aspect développement durable du système.

La méthode GIMSI est structurée en 10 étapes bien identifiées, regroupées en 4 phases

thématiques :

Tableau ‎I-1 : Les 10 étapes de la méthode GIMSI [4]

1- Identification

Quel est le contexte ?

Etape 1 : Environnement de l'entreprise Analyse de l'environnement économique et de la

stratégie de l'entreprise afin de définir le périmètre et

la portée du projet.

Etape 2 : Identification de l'entreprise

Analyse des structures de l'entreprise pour identifier

les processus, activités et acteurs concernés.

2- Conception

Que faut-il faire ?

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.

Etape 5 : Choix des indicateurs Choix des indicateurs en fonction des objectifs

choisis, du contexte et des acteurs concernés

Etape 6 : Collecte des informations Identification des informations nécessaires à la

construction des indicateurs

Etape 7 : Le système de tableau de bord

Construction du système de tableau de bord, contrôle

de la cohérence globale

3- Mise‎en‎œuvre

Comment le faire ?

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

3-Amélioration permanente

Le système correspond-il

toujours aux attentes ?

Etape 10 : Audit

Suivi permanent du système

Nous donnons plus de détails sur cette méthode dans l’annexe 1.

11


3.4. Planning du projet :

Afin de mieux organiser notre projet, nous avons présenté sous forme de diagramme

de Gantt l’ensemble des tâches ainsi que leurs durées, tout en respectant la méthode GIMSI

adoptée pour la réalisation du projet.

Le tableau ci-dessous récapitule l’ensemble des tâches ainsi que leurs durées :

Tableau ‎I-2 : Tableau des tâches

N° Nom Durée Début Fin Prédécesseurs

1 Identification 19 jours 07/02/2012 02/03/2012

2 Etude de l’environnement 12 jours 07/02/2012 22/02/2012

3 Formation 15 jours 13/02/2012 02/02/2012

4 Formation SSIS 5 jours 13/02/2012 17/02/2012

5 Formation SSAS 5 jours 20/02/2012 24/02/2012 4

6 Formation SSRS 5 jours 27/02/2012 02/03/2012 5

7 Conception 18 jours 05/03/2012 28/04/2012 1

8 Analyse de l’existant et KPI 7 jours 05/03/2012 13/03/2012

9 Modélisation multidimensionnelle 11 jours 14/03/2012 28/03/2012 8

10 Mise‎en‎œuvre‎ 31 jours 29/04/2012 09/05/2012 7, 3

11 Processus ETL 10 jours 29/04/2012 11/04/2012 4

12 Cubes OLAP 7 jours 12/04/2012 20/04/2012 11, 5

13 Reporting 14 jours 23/04/2012 10/05/2012 12, 6

14 Amélioration 5 jours 11/04/2012 17/07/2012 10

15 Audit du système et Formation 5 jours 11/04/2012 17/04/2012 13

16 Rédaction du rapport 57 jours 01/04/2012 17/05/2012

Le graphique ci-dessous (Figure I-7) schématise le déroulement des différentes phases

pendant toute la durée du stage. Des avances et des retards sur des tâches ont été marqués, la

première phase d’identification est marquée par une avance de 2 jours, la phase de conception

a connu un retard au niveau de l’analyse de l’existant à cause de la rétro-ingénierie de la base

de production, cette étape était imprévisible et nous a couté 5 jours, enfin la phase de mise en

œuvre a couté 2 jours de plus à cause de certains problèmes d’insertions lors du processus

ETL.

12


Figure ‎I-7 : Diagramme de Gantt‎de‎l’avancement

4. Identification de l’environnement :

4.1. Système d’information sanitaire:

Le système d’information sanitaire peut être défini comme un système d’information

global regroupant tous les types d’acteurs et ressources de santé. Il est structuré comme suit:

Réseau des soins de santé de base:

Sous-système d’information SMI/PF : Santé maternelle et infantile, planification

familiale, hygiène scolaire et universitaire, information et communication.

Sous-système d’information des soins curatifs.

Sous-système d’information de la surveillance épidémiologique.

Système d’information de gestion des hôpitaux : SIG-HO.

Mortalité et morbidité.

Enquêtes et études.

4.2. Système d’information hospitalier :

Le Système d’Information Hospitalier (SIH) est un système permettant un traitement

intégré de l’information, garantissant sa cohérence et son intégration dans un milieu

13


hospitalier. Le SIH est caractérisé par la multiplicité et diversité des entités fonctionnelles

qu’il met en jeu.

Les différentes entités fonctionnelles connectées par un Système d’information

hospitalier sont présentées dans la figure I-8 :

Figure ‎I-8 :‎Organisation‎de‎l’hôpital [5]

4.3. Le progiciel de gestion intégré « KEWAN »

KEWAN, le PGI édité par une société espagnole spécifique pour le domaine sanitaire

et qui intègre l’ensemble des services hospitaliers ainsi que la logistique, les finances et

d’autres domaines, a été la solution choisie par le Ministère de la Santé du Maroc pour la

gestion informatisée d’un groupe d’hôpitaux publics desquels l’Hôpital Hassan II d’Agadir

est à la tête.

_________________________________________________________________________

Dans ce chapitre, nous avons pu présenter brièvement le ministère de la santé ainsi

que la DIM. Ensuite, nous avons précisé le cadre général et spécifique de notre projet, avant

de nous pencher sur une étude des SIG-HO. Il est à noter que notre projet entre dans le cadre

d’un des grands projets au Maroc mené par le Ministère de la santé, afin de permettre au

système national de santé de jouer pleinement son rôle, et ce en améliorant ses services, à

commencer par son système d’information pour s’offrir une meilleure ouverture sur les

différents établissements sanitaires du pays.

14


Chapitre 2

II. Conception

Dans ce chapitre, nous présenterons le cœur de notre travail qui consiste en la

conception de l’entrepôt de données, il s’agit en effet de la deuxième phase de la méthode de

gestion projet GIMSI intitulée « Conception ». Pour ce faire, nous débuterons par présenter

un modèle conceptuel de données établi par rétro-ingénierie, ensuite nous détaillerons les

indicateurs recueillis ainsi que les différentes dimensions et leurs hiérarchies et nous

clôturons ce chapitre par le schéma de notre conception multidimensionnelle.

1. Analyse de l’existant :

Cette phase correspond à la quatrième étape de la méthodologie de conduite de projet

GIMSI : «Construction du tableau de bord». Elle vise à analyser la structure du fond du

tableau de bord des décideurs et la relation entre les informations.

Les données sur lesquelles portera notre analyse sont issues de la base de données

SQL Server relative au progiciel de gestion intégré « KEWAN » implémenté dans l’hôpital

Hassan II d’Agadir. La base de données en question contient plus de 1700 tables dont la

plupart ont des noms qui ne fournissent aucune information sur leurs contenus, et les noms

des champs sont en langue espagnole, de plus aucune description des tables n’est disponible.

Or l’établissement des indicateurs clés et la conception de notre entrepôt de données

nécessitent une description des tables de la base de données source afin d’en extraire les

informations qui nous seront utiles ainsi que les relations entre eux. De ce fait, on a été amené

à procéder par rétro-ingénierie afin d’établir un modèle conceptuel des données.

Vu le grand nombre des tables de la base de données et la durée de notre stage qui se

posent comme des contraintes majeures, nous nous sommes intéressés aux services relatifs

aux urgences et aux consultations externes.

En effet, notre choix s’est penché vers le service des urgences vu sa particularité

comme étant le service actif jour et nuit et qui accueille le plus grand nombre de patients, par

la suite, sa gestion et son amélioration est d’une grande importance. Notre deuxième choix

concerne l’aspect des consultations externes, car ce dernier reflète aux acteurs de notre

solution l’image de gestion de l’établissement sanitaire en question quant aux rendez-vous,

leur planification et leur respect par le personnel.

15


1.1. Retro-Ingénierie :

La rétro-ingénierie ou reverse engineering, également appelée rétro-conception, est

l'activité qui consiste à étudier un objet pour en déterminer le fonctionnement interne ou la

méthode de fabrication [W3].

Pour réaliser notre rétro-ingénierie, il a fallu relever les relations existantes entre les

tables de la base de données, nous avons utilisé l’outil DbVisualizer 8.0.8 qui offre dans sa

version gratuite la fonctionnalité d’affichage des contraintes d’intégrité référentielles entre les

tables d’une base de données. Une description de cet outil est présentée dans l’annexe 2.

Nous avons cherché les tables inhérentes aux urgences et aux consultations externes,

pour dégager les relations entre les différentes tables, nous nous sommes basés également sur

l’existence ou non des clés communes grâce à l’outil DbVisualizer 8.0.8. Une documentation

autour de ces deux services nous a été fournie pour nous aider à comprendre l’intérêt des

différents champs.

Le schéma si dessous résume les principales étapes du passage d’un patient aux

urgences :

http://fr.wikipedia.org/wiki/Objet

http://fr.wikipedia.org/wiki/Fabrication

16


Figure ‎II-1 :‎Diagramme‎d’activités d’un‎passage‎aux‎urgences

Quant au service des consultations externes, on y retrouve les patients passés par le

service des urgences et dont le diagnostic a nécessité une consultation externe chez un

spécialiste. Le patient ramène une feuille de référence et se dirige vers le service approprié

dans le centre des consultations externes le jour du rendez-vous.

Les consultations externes peuvent aboutir soit à une hospitalisation du patient, un

transfert à un autre centre ou bien un suivi du patient ce qui donne naissance à un deuxième

rendez-vous.

Notre analyse a abouti aux tables EMEP et APPO qui contiennent les données

relatives aux urgences et aux consultations externes. Par la suite les tables en relation avec

EMEP et APPO ont été dégagées, puis une analyse approfondie de ces données s’est avérée

17


nécessaire afin d’éliminer les tables vides et de garder les tables qui contiennent les

informations pertinentes.

1.2. Modèle conceptuel de données

La rétro-ingénierie nous a mené à établir un modèle conceptuel de données qui a

permis de représenter et de mettre en clair les données relatives aux deux services auxquels

nous nous intéressons, la figure qui suit contient les principales tables auxquelles a abouti

notre rétro-ingénierie.

18


Figure ‎II-2 : Modèle conceptuel de données

19


La description des tables est donnée dans le tableau suivant :

Tableau ‎II-1 : Description des tables

Nom de la table Description

Personnes Contient toutes les informations concernant le personnel

de l’hôpital et les patients : Nom, Prénom, sexe, date de

naissance, etc.

Patients Contient des informations relatives aux patients de

l’hôpital : Date de prise en charge, Adresse, groupe

sanguin, poids, etc.

Geographie Contient des pays tels que : Maroc, Belgique, Espagne,

France, Italie. Le Maroc avec plus de détails sur les

régions, les villes et les provinces.

Cent_Serv_Activ Cette table contient des champs relatifs aux centres, les

services de chaque centre, et les types d’activités de

chaque service tel que : Chirurgie générale, Cardiologie,

etc.

Episode C’est une table qui contient toutes les épisodes, une

épisode étant une entrée à l’hôpital, un patient peut avoir

plusieurs épisodes s’il est hospitalisé plusieurs fois. Elle

contient le type d’activité relatif à l’épisode (Urgences,

Accouchement…), la clé du patient, la date de début et

de fin de l’épisode, etc.

Episode_Service Cette table stocke le service où est entrée chaque

épisode, d’autre informations telles que la date d’entrée,

etc.

Diagnostiques Dans cette table se trouve le diagnostique de chaque

épisode et le code du médecin ayant relevé ce

diagnostique.

Urgences C’est la table qui concerne les entrées en urgences, elle

contient le code de l’épisode en question, le code du

degré d’urgence, de la destination en sortie d’urgences et

du motif d’admission en urgences, etc.

Sortie_Dest Contient le code de la destination en sortie d’urgences,

et la description de la sortie : Domicile, Hospitalisation,

Consultation externe, Mort, etc.

Motif_Sortie Contient le code du motif de la sortie des urgences, et sa

description : Mort, Guérison, etc.

Motif_Admis Contient le code du motif d’admission en urgences et sa

20


description : Intoxication, Accident de travail, Maladie,

etc.

Degre_Urg Contient le code du degré de l’urgence et sa description :

Basse, Moyenne, Haute.

Services Contient tous les services de l’hôpital, le code et la

description correspondante.

Personnel_Sanit Contient Les informations qui concernent les médecins,

leurs codes dans la table Personnes, le code du service

auquel le médecin appartient.

Consul_Ext C’est la table qui contient les informations qui

concernent les consultations externes, pour chaque

épisode on trouve son code dans la table Cahier_Consul

et le code du patient.

Cahier_Consul Il s’agit de la table des rendez-vous, c’est dans cette

table qu’on trouve les dates des rendez-vous, la date et

l’heure dans lesquelles le patient a pris le rendez-vous,

etc.

Resultat_RV Il s’agit de la table des résultats d’un rendez-vous, dans

laquelle nous trouvons les différents résultats qui

peuvent être soit un changement de traitement, un

transfert à un autre centre, etc.

Consul_Echec Cette table contient les raisons pour lesquelles peut

échouer un rendez-vous, à savoir non présentation du

patient ou du médecin, ou décès du patient.

Consul_Type Les différents types de rendez-vous sont stockés dans

cette table.

Consul_motif Pour chaque rendez-vous, le motif est stocké dans cette

table.

Clip Dans cette table, un numéro de document est attaché à

chaque patient qui vient d’entrer à l’hôpital.

Consul_Etat Cette table contient les différents états possibles

d’un rendez-vous, à savoir : Réalisé, En attente, etc.

2. Conception multidimensionnelle

2.1. Détermination des KPI

Le DWH doit contenir des informations utiles servant à extraire des mesures intitulées

des KPI ou des indicateurs clés. Afin de recenser l’ensemble de ces informations, nous nous

21


sommes basés sur les informations recueillies suite à une série d’interviews auprès du

ministère de la santé. Cette phase correspond à la cinquième étape de la méthode de conduite

de projet GIMSI : « Choix des indicateurs », cette étape est présentée plus en détail dans

l’annexe 1, aussi bien que les critères auxquels doivent répondre ces indicateurs clés.

Nous avons recensé un ensemble d’indicateurs clés qui couvrent tous les besoins du

ministère de la santé en matière de prise de décisions, relativement aux services des urgences

et des consultations externes, ces indicateurs sont les suivants :

Urgences :

Nombre des patients.

Le suivi de cet indicateur permettra d’évaluer le nombre des patients servis en

urgence, il permettra aux décideurs d’avoir une vision sur plusieurs axes d’analyse qui seront

détaillés par la suite, on distinguera à titre d’exemple : Le nombre des patients appartenant à

une tranche d’âge donnée et pour qui on a relevé un diagnostic donné.

L’analyse de cet indicateur par rapport à l’axe du temps permettra de suivre l’activité

du service des urgences à travers le temps, d’en dégager des informations telles que les jours

de la semaine pendant lesquels on constate un grand nombre d’admission en urgence, et la

croissance de ce nombre dans le temps nécessitera l’engagement de nouvelles ressources

matérielles et humaines pour garantir les soins en urgences pour tout le monde.

Un autre exemple, relatif à l’évaluation du nombre des patients arrivés en ambulance,

permet aux responsables du ministère de mieux gérer l’octroi des budgets en analysant le

besoin des centres hospitaliers en termes de ressources financières.

Moyenne quotidienne et mensuelle des patients servis en urgences.

Il s’agit de la mesure précédente mais en terme de moyenne quotidienne et mensuelle,

il est plus pratique de pouvoir faire des analyses sur des moyennes, car il est facile de faire des

constatations quant au changement de ces mesures, ces indicateurs fournissent plus

d’informations même en absence de l’axe du temps.

Exemple :

- La moyenne quotidienne des femmes admises en urgences à cause d’une violence.

- La moyenne mensuelle des enfants morts en urgence.

D’autre part, l’analyse de cet indicateur permet de dégager, par exemple, la moyenne

quotidienne ou mensuelle des patients servis en urgence atteints de la tuberculose ou bien de

la cholera, ainsi que leurs emplacements. De ce fait, cet indicateur peut servir aux

responsables comme moyen de suivre l’évolution de certaines épidémies ainsi que leurs zones

de propagation.

Nombre Patients avec Sortie des Urgences.

22


Cet indicateur calcule le nombre de patients qui sont sortis des urgences.

Contrairement aux indicateurs précédents, cette mesure ne prend pas en considération les cas

qui sont toujours en service des urgences au moment de l’analyse.

Moyenne quotidienne et mensuelle des patients avec sortie des urgences.

Ce sont les moyennes quotidiennes et mensuelles relativement à la mesure précédente.

Consultations externes :

Nombre des consultations externes.

C’est la mesure qui concerne le nombre des patients dont le diagnostic au service des

urgences nécessite une consultation externe chez un spécialiste, les consultations externes se

font en dehors du centre hospitalier, dans le cas de l’hôpital HASSAN II d’Agadir, c’est le

centre de diagnostic qui est chargé de recevoir les patients en consultations.

L’analyse de cette mesure par rapport aux services de l’hôpital permet aux

responsables de prévoir tout manque de ressources humaines ou matérielles dans les services

d’un établissement sanitaire. Ainsi lorsqu’on remarque une augmentation du nombre des

consultations externes dans un service donné, les responsables devraient affecter plus de

personnel sanitaire dans ce service et fournir plus de ressources matérielles comme les

équipements médicaux, vis-à-vis des centres de consultations externes.

Retard rendez-vous.

C’est l’indicateur qui mesure la durée en jours entre la date d’entrée du patient en

urgences et la date du rendez-vous de la consultation externe, à travers cette mesure on juge la

gestion des rendez-vous du centre hospitalier, ce qui reflète l’image de ce dernier. Par

exemple, les retards des rendez-vous doivent être en fonction de la gravité des cas qui se

présentent en urgences, ainsi un rendez-vous d’un cas de gravité moyenne doit être retardé par

rapport à celui d’un patient présentant un état plus grave.

Ainsi l’analyse de cet indicateur par rapport au personnel d’un hôpital permet d’évaluer la

disponibilité ou le besoin en termes de médecin et d’infirmiers ce qui pourrait expliquer aux

responsables du ministère de la santé les retards des rendez-vous. De ce fait, ils affecteraient

plus de personnel afin d’améliorer la qualité de gestion des établissements sanitaires.

2.2. Détermination des axes d’analyse

L’analyse des indicateurs clés recueillis auprès des responsables du ministère de la

santé va être effectuée selon différents axes d’analyse. Ces derniers ont été élaborés selon le

besoin des responsables et aussi selon la disponibilité des données.

Suite à l’analyse des besoins qu’on a menée, il a été nécessaire de prévoir la création

des dimensions suivantes et qui sont relatives aux services des urgences et des consultations

externes :

23


- Temps.

- Age.

- Sexe.

- Services.

- Personnel sanitaire.

- Géographie du patient.

- Diagnostique.

- Centre.

- Motif d’admission en urgences.

- Motif de sortie des urgences.

- Destination en sortie d’urgences.

- Degré d’urgence.

- Cas judiciaire oui ou non.

- Cas ouvert oui ou non.

- Cas nouveau oui ou non.

- Affiliation

- Type du rendez-vous.

- Date de création du rendez-vous.

- Date du rendez-vous.

- Etat du rendez-vous.

- Résultat du rendez-vous.

- Agenda.

La prise en considération des différentes dimensions et de leurs hiérarchies s’avère

d’une grande importance car elle permet d’analyser les données avec plus de précision et à un

niveau de granularité très fin. Parmi les dimensions citées ci-dessus, on a pu repérer quelques-

unes hiérarchiques, le tableau suivant nous donne la liste de ces dimensions avec leurs

hiérarchies.

Tableau ‎II-2 : Les dimensions hiérarchiques

Dimensions

Hiérarchie

Temps

Année => Semestre => Trimestre => Mois => Jour.

Services

Centre => Zone => Service => unité.

Géographie du

patient

Pays => Région => Provence => Département => Provence par

département.

Diagnostique

Diagnostic de fréquentation => Diagnostique détaillé.

Age

Rang âge => âge.

24


2.3. Description détaillée des axes d’analyse

Dans cette partie, nous nous intéresserons à la description détaillée des axes d’analyse

cités auparavant. En effet, cette description nous sera d’une très grande utilité lors de la phase

d’extraction, transformation et chargement des données de la base de données source.

Ci-dessous, la description des axes d’analyse Géographie et Temps :

La dimension Géographie: Nous nous sommes intéressés à cet axe qui permet de faire

l’analyse de l’ensemble des indicateurs selon la géographie, et aussi avec un niveau de

précision élevé, compte tenu de la hiérarchisation de cette dimension. Cette table de

dimension se caractérise par le fait qu’elle est commune aux services des urgences et

des consultations externes.

Le tableau qui suit capitalise l’ensemble des informations relatives à cette table de

dimension :

Tableau ‎II-3 :‎Axe‎d’analyse Géographie

Axe de l’analyse: Géographie

Identifiant Dim_Geographie

Description Cette dimension permet de faire les

différentes analyses selon les pays, region,

provence,etc.

Sources de données Créée à partir de la table Geographie

Attributs

Terr_id - Clé primaire de la table Dim_Geographie.

- Type de données: Int.

- Source de données: Geographie.

Terr_idfath - Correspond à l’identifiant de la région à

laquelle appartient celle de la ligne.

- Type de données: int.


terrcode - Attribut indiquant le code de la région.

- Type de données: Char(15)


territoire - Attribut indiquant le nom de la région ou de

la ville,etc.

- Type de données: Char(50)


La dimension Temps: Toutes nos analyses se font par rapport à l’axe du temps dans le

but de visualiser des rapports périodiques. La possibilité d’effectuer les analyses des

différentes mesures selon l’axe du temps et selon un niveau de granularité très fin, est

d’une très grande importance dans le domaine des urgences et des consultations

externes, compte tenu de la hiérarchisation de cet axe qui se présente comme suit:

Année => Semestre => Trimestre => Mois => Jour.

25


2.4. Conception des modèles multidimensionnels

Cette phase nous place dans la septième étape de la méthodologie de conduite de travail

GIMSI «Système de tableau de bord ».

Nous avons adopté une approche ascendante pour la construction de notre entrepôt de

données. « Cette approche nommée «Bottom-Up» consiste à aller du bas vers le haut,

autrement dit, commencer par concevoir les datamarts et les regrouper par la suite jusqu’à

l’obtention du datawarehouse» [W4]. Dans notre cas, il s’agit de la construction des deux

datamarts des urgences et des consultations externes.

Choix du modèle multidimensionnel :

Nous avons présenté dans le deuxième chapitre les différents schémas d’un DWH : en

étoile et en flocon. Dans notre cas nous avons opté pour le modèle en étoile, qui est le modèle

classique. Il est considéré comme étant le modèle le plus simple et qui offre une grande

facilité de navigation.

Nous avons choisi ce modèle pour plusieurs raisons à citer :

les requêtes sont plus rapides sur un schéma en étoile.

L’adaptabilité de ce modèle aux cardinalités 1-n entre la table de fait et les tables de

dimensions, ce qui est le cas pour les relations entre les faits et les dimensions que

nous avons relevés.

l’ETL est plus simple avec un schéma en étoile.

L’espace occupé par les tables de dimension est négligeable devant celui de la table

des faits, en effet la majorité des tables de dimensions que nous avons recueillies ne

sont pas volumineuses.

Performances : Nombre de jointures limité, gestion des données creuses.

Bien que le modèle en étoile présente quelques inconvénients comme la redondance

dans les dimensions, surtout dans les dimensions qui présentent une hiérarchie, mais il s’agit

du modèle le plus adapté à notre cas.

Datamart «Urgences»:

La table de fait «Fait_Urgences» contient des données issues de tables sources

différentes, relatives au passage des patients par les urgences, telles le numéro de l’épisode, la

date d’arrivée, le degré d’urgence, la cause de l’urgence, ainsi que les informations

personnelles du patient telles que son âge, la zone géographique à laquelle il appartient, son

sexe, etc.

Les données servant d’axes d’analyse sont saisies en tant que clés étrangères référant à

des tables de dimensions qui contiennent l’intégrité des données de chaque dimension.

La figure suivante représente le modèle multidimensionnel de ce datamart.

26


Figure ‎II-3 : Modèle en étoile du datamart « Urgences »

Datamart «Consultations Externes»:

D’autre part, nous avons construit le modèle multidimensionnel du Datamart

«Consultations Externes» à l’aide d’une table de fait reliée à treize tables de dimensions.

La table de fait nommée «Fait_Consul.Ext» contient des données qui proviennent de

différentes tables sources différentes, elles permettent de calculer les indicateurs relatifs aux

consultations externes, chaque entrée est un épisode identifie par un code. Un épisode a une

date d’arrivée, un état de rendez-vous, un résultat de rendez-vous, un type de rendez-vous

ainsi qu’un retard du rendez-vous.

Dim_Afiliation

Afiliation_Id

Afiliation

Dim_Age

Age_Id

Age

RangAge_Id

RangAge

Dim_Centre

centre_Id

centre

Dim_CSTA

CSTA_Id

CENT_Id

CENTRE

SERV_Id

SERVICE

TACTCODE

TACT

CSTA

Dim_DestSortieUrg

Destination_Id

DestinationSortie

Dim_Diag

Diag_Id

diagdesc

diagtype

Diag_IdFath

Dim_EpisCasJud

EpisCasJud_Id

EpisCasJud

Dim_EpisCasNouv

EpisCasNouv_Id

EpisCasNouv

Dim_EpisOuvert

EpisOuvert_Id

EpisOuvert

Dim_Geographie

terr_Id

terr_Idfath

terrcode

territoire

Dim_MotifSortieUrg

MotifSortie_Id

MotifSortie

Dim_Temps

DATE

ANNEE

SEME

SEMEDESC

TRIM

TRIMDESC

MOIS

MOISDESC

DATEDESC

Dim_UrgCause

UrgCause_Id

UrgMotif

Dim_UrgGrade

UrgGrade_Id

UrgGrade

Fait_Urgences

EPIS_KEY

EpisOuvert_Id

EpisCasNouv_Id

EpisCasJud_Id

EPIS_DATE_INIT

CSTA_Id

DestinationSortie_Id

MotifSortie_Id

UrgCause_Id

UrgGrade_Id

Id_Sexe

Age_Id

centre_Id

terr_Id

Diag_Id

Afiliation_Id

Dim_Sexe

Id_Sexe

Sexe

27


La table de fait «Fait_Consul.Ext» contient les clés primaires de toutes les tables de

dimensions avec lesquelles elle est liée.

Figure ‎II-4 : Modèle en étoile du datamart consultations externes

Le Datawarehouse:

La conglomération des deux Datamarts «Urgences» et «Consultations Externes» donne le

modèle multidimensionnel de notre datawarehouse modélisé par un schéma en constellation

qui relie les deux tables de faits et les tables de dimensions partagées.

Fait_Consul.Ext

EPIS_KEY

PERS_KEY

PersSani_Id

Id_Age

Id_Sexe

terr_Id

BOOK_KEY

Date_RV

Id_Prestation

CSTA_Id

Id_EtatRV

Id_TypeRV

Id_ResultatRv

DIAG_KEY

BOOKDATEBOOK

Id_RVProg

Agenda_Id

Jours_Retard

Dim_TypeRV

Id_TypeRV

Type_RV

Dim_Temps

DATE

ANNEE

SEME

SEMEDESC

TRIM

TRIMDESC

MOIS

MOISDESC

DATEDESC

Dim_RVProg

Id_RVProg

RendezVs_Prog

Dim_ResultatRV

Id_ResultatRv

Resultat_RV

Dim_PersonnelSani

PersSani_Id

Id_Sexe

PersNomComplet

Dim_Geographie

terr_Id

terr_Idfath

terrcode

territoire

Dim_EtatRV

Id_EtatRV

EtatRV

Dim_Diag

Diag_Id

diagdesc

diagtype

Diag_IdFath

Dim_CSTA

CSTA_Id

CENT_Id

CENTRE

SERV_Id

SERVICE

TACTCODE

TACT

CSTA

Dim_Agenda

Agenda_Id

Agenda_Nom

Dim_Age

Age_Id

Age

RangAge_Id

RangAge

Dim_Prestation

Id_Prestation

Prestation_Id_Par

Prescode

Prestation

Dim_Sexe

Id_Sexe

Sexe

28


Figure ‎II-5 : Schéma du Datawarehouse

Dim

_A

filiatio

n

Afilia

tion_Id

Afilia

tion

Dim

_A

ge

Age_Id

Age

RangA

ge_Id

RangA

ge

Dim

_A

ge

nd

a

Agenda_Id

Agenda_Nom

Dim

_C

en

tre

centre

_Id

centre

Dim

_C

ST

AC

STA

_Id

CEN

T_Id

CEN

TR

E

SER

V_Id

SER

VIC

E

TA

CTC

OD

E

TA

CT

CSTA

Dim

_D

estS

ortie

Urg

Destin

atio

n_Id

Destin

atio

nSortie

Dim

_D

iag

Dia

g_Id

dia

gdesc

dia

gty

pe

Dia

g_Id

Fath

Dim

_E

pis

Ca

sJu

d

EpisC

asJu

d_Id

EpisC

asJu

d

Dim

_E

pis

Ca

sN

ou

vEpisC

asN

ouv_Id

EpisC

asN

ouv

Dim

_E

pis

Ou

ve

rtEpisO

uvert_

Id

EpisO

uvert

Dim

_E

tatR

V

Id_Eta

tRV

Eta

tRV

Dim

_G

eo

gra

ph

iete

rr_Id

terr_

Idfa

th

terrco

de

territo

ire

Dim

_M

otifS

ortie

Urg

MotifS

ortie

_Id

MotifS

ortie

Dim

_P

ers

on

ne

lSa

ni

PersS

ani_

Id

Id_Sexe

PersN

om

Com

ple

t

Dim

_P

resta

tion

Id_Pre

statio

n

Pre

statio

n_Id

_Par

Pre

scode

Pre

statio

n

Dim

_R

esu

ltatR

V

Id_Resu

ltatR

v

Resu

ltat_

RV

Dim

_R

VP

rog

Id_RVPro

g

RendezV

s_Pro

g

Dim

_T

em

ps

DA

TE

AN

NEE

SEM

E

SEM

ED

ESC

TR

IM

TR

IMD

ESC

MO

IS

MO

ISD

ESC

DA

TED

ESC

Dim

_T

yp

eR

V

Id_TypeRV

Type_RV

Dim

_U

rgC

au

se

Urg

Cause

_Id

Urg

Motif

Dim

_U

rgG

rad

e

Urg

Gra

de_Id

Urg

Gra

de

Fa

it_C

on

su

l.Ex

tEPIS

_KEY

PER

S_KEY

PersS

ani_

Id

Id_A

ge

Id_Sexe

terr_

Id

BO

OK_KEY

Date

_R

V

Id_Pre

statio

n

CSTA

_Id

Id_Eta

tRV

Id_TypeR

V

Id_R

esu

ltatR

v

DIA

G_KEY

BO

OKD

ATEBO

OK

Id_R

VPro

g

Agenda_Id

Jours_

Reta

rd

Fa

it_U

rge

nce

sEPIS

_KEY

EpisO

uvert_

Id

EpisC

asN

ouv_Id

EpisC

asJu

d_Id

EPIS

_D

ATE_IN

IT

CSTA

_Id

Destin

atio

nSortie

_Id

MotifS

ortie

_Id

Urg

Cause

_Id

Urg

Gra

de_Id

Id_Sexe

Age_Id

centre

_Id

terr_

Id

Dia

g_Id

Afilia

tion_Id

Dim

_S

ex

eId

_Sexe

Sexe

29


_________________________________________________________________________

Au cours de ce chapitre, nous avons touché aux différents aspects conceptuels de notre

projet, à partir du recueil des indicateurs clés de performance, jusqu’à l’établissement des

modèles multidimensionnels pour l’analyse de ces indicateurs. Nous allons consacrer le

chapitre suivant à la présentation des outils utilisés pour réaliser notre travail.

30


Chapitre 3

III. Présentation des outils utilisés

Le chargement de notre datawarehouse fait intervenir la suite Microsoft SQL Server

2008 R2 que nous avons choisie pour la réalisation de notre projet, ce choix est en

adéquation avec la politique du ministère de la santé, qui fait intervenir les produits

Microsoft dans la réalisation de tous ses projets informatiques, ceci garantit une

interopérabilité souple entre les différents systèmes du ministère, et à notre solution un suivi

et une maintenance à long terme par les compétences techniques de l’organisme. Le présent

chapitre présente une comparaison entre la suite BI de Microsoft et quelques suites présentes

sur le marché, ainsi qu’une étude technique et fonctionnelle des produits Microsoft utilisés.

1. Comparaison des suites décisionnelles :

Le choix de notre outil de travail va en concordance avec la politique du ministère de

la santé qui utilise les produits Microsoft pour la réalisation de tous ses projets informatiques.

Néanmoins, nous avons choisi de faire une étude comparative de la suite Microsoft avec

quelques suites BI présentes sur le marché.

Dans le domaine du BI, les outils propriétaires tel que Microsoft offrent un grand

nombre de fonctionnalités avec un haut niveau de performance. Cependant, l’utilisation de ces

outils entraine des coûts élevés de licence, de formation ou de support technique. Quant aux

solutions Open Source telles que Pentaho, Jaspersoft ou SpagoBI, ce sont des outils à code

ouvert qu’on peut consulter librement. Ces outils ont aussi la capacité de répondre à un grand

nombre de besoins en matière de BI avec un coût minimum et une capacité d’adaptabilité

assez importante. [W8]

A cet égard, nous avons mené, dans le cadre de notre travail, une étude comparative

entre deux suites propriétaires qui sont Microsoft, Oracle et une suite Open Source qui est

Pentaho.

1.1. Présentation des suites décisionnelles :

Microsoft SQL Server 2008 R2 : Cette suite, produit de Microsoft, intègre

l'ensemble des briques nécessaires à la construction d'un système d'information

décisionnel. En effet, cette plateforme s’accompagne de nombreux outils pour

intégrer, analyser et afficher les données, tout en garantissant une haute performance,

elle repose sur les outils suivants : SQL Server Integration services (SSIS), SQL

Server Analysis Services (SSAS) et SQL Server Reporting Services (SSRS).

31


Figure III-1 : Les outils de MS SQL Server 2008 R2 [12]

Oracle Business Intelligence Suite: Concurrente de Microsoft, la solution Business

Intelligence d’Oracle est une plateforme complète du système décisionnel qui fournit

toute la gamme de fonctionnalités d’analyse et de production de rapports. la

plateforme contient une base de données, un outil d'intégration de données (ETL), des

requêteurs, et un portail permettant de publier des tableaux de bord. [15]

Figure ‎III-2 :‎Architecture‎fonctionnelle‎d’Oracle‎BI‎Suite‎[15]

Pentaho: Cette suite est considérée comme le leader des suites de BI dans le monde

de l’Open Source. C’est une plateforme décisionnelle extrêmement complète et auto-

suffisante, qui permet non seulement d’utiliser les différents outils décisionnels open

source depuis une interface unique et simple d’utilisation, mais aussi d’étendre et de

combiner leurs fonctionnalités grâce à l’utilisation d’un moteur de workflow. Elle

32


repose sur JFreeReport pour les rapports, Weka pour le datamining, PDI pour l'ETL, et

Mondrian pour le serveur OLAP.[ W6]

Figure ‎III-3 : Fonctionnalités de Pentaho

1.2. Tableau comparatif des suites BI :

Le tableau suivant présente les fonctionnalités des trois suites décisionnelles :

Tableau ‎III-1 : Tableau comparatif des suites décisionnelles choisies

Fonctionnalités

Microsoft Oracle Pentaho

Alimentation

-Chargement des données

externes par fichier plat.

-Chargement de toute

source de données.

-Chargement des données

externes par fichier plat.

-Chargement de toute

source de données.

-Connexion à

n’importe quelle

base de données

au travers d’un

driver JDBC.

Stockage

-Cube OLAP.

-Entrepôt de données.

-Datamarts métiers.

-Cube OLAP.

-Entrepôt de données.

-Datamarts métiers

-SGBD avec

l’option OLAP.

Administration

-Outil de gestion du

dictionnaire de données.

-Gestion de la sécurité et

des reprises après incident

-Outil de gestion du

dictionnaire de données.

-Gestion de la sécurité et

des reprises après incident

- Administration

des actions depuis

une interface

spécifique.

Analyse

-Statistiques.

-Analyse

multidimensionnelle.

- Extraction des données à

un format de type tableur.

-Statistiques.

-Analyse

multidimensionnelle.

- Extraction des données à

un format de type tableur.

-Connexion à

n’importe quelle

base de données

relationnelle.

-Possibilité

33


d’exécuter des

requêtes MDX.

Reporting et

tableaux de

bord

-Tableaux de bord

personnalisables et

interactifs.

-Mise à disposition d'une

interface graphique de

construction de tableaux

de bord personnalisés et de

restitutions dans un portail

décisionnel.

-Tableaux de bord

standards et interactifs.

-Mise à disposition d'une

interface graphique de

construction de tableaux

de bord personnalisés.

-Support de

sources de

données multiples

dans les mêmes

rapports.

- Support de sous

rapports.

Suite à cette comparaison nous pouvons conclure que certes, les outils Open Source

offrent un ensemble de fonctionnalités assez performantes mais restent dépassés par les suites

propriétaires telles Microsoft ou Oracle. Ces deux dernières suites sont concurrentes et

proposent toutes les deux plusieurs composants qui répondent aux besoins des entreprises et

couvrent l’ensemble de la chaine décisionnelle avec un niveau de performance assez élevé

mais la suite Microsoft reste meilleure que celle d’Oracle vu qu’elle est moins chère, facile à

intégrer avec SharePoint et Microsoft Office et elle offre un niveau de sécurité plus élevé.

2. Présentation de la suite Microsoft SQL Server 2008 R2 :

La suite décisionnelle de Microsoft reposant sur le socle de SQL Server 2008 R2 permet:

L'analyse à postériori de la situation de l’entreprise (passé).

La restitution des tendances probables de l’activité à court et moyen terme

(prévisions).

La production d’une vision comptable de l’entreprise non seulement conforme,

correcte mais aussi globale.

La mise en place d’une communication aisée, efficace et automatisable des tableaux

de bord, documents, graphiques et rapports mensuels.

2.1. Principaux composants et fonctionnalités :

En plus de son moteur, SQL Server 2008 R2 contient trois plateformes, indispensables

pour réaliser un projet en Business Intelligence. [12]

SQL Server Integration Services: qui permet d’intégrer des données provenant de

différentes sources pour les ranger dans un entrepôt central.

SQL Server Analysis Services: qui permet d’analyser les données, agrégées lors de

S.S.I.S., grâce à des fonctions d’analyse multidimensionnelle.

SQL Server Reporting Services: qui permet de créer, gérer et publier des rapports

résultant des analyses réalisées lors de SSAS.

34


L’outil avec lequel on va réaliser notre travail : SQL Server 2008 R2 couvre

l’ensemble des étapes nécessaires à la réalisation d’un projet BI, le tableau suivant présente

l’ensemble des fonctionnalités offertes par cet outil.

Tableau ‎III-2 : Principaux fonctionnalités de MS SQL Server 2008 R2 [13]

Rôle

Nom‎de‎l’outil Fonctionnalités

Alimentation

SQL SERVER Integration

services

-Outil d’extraction (Type ETL).

-Chargement de toute source de

données.

-Audit des erreurs et des rejets.

Stockage

SQL SERVER Analysis services

-Entrepôts de données.

-Cubes OLAP.

-Datamarts métiers.

Reporting et

tableaux de bord

SQL SERVER Reporting

services

Report Builder

SharePoint Portal server

-Tableaux de bord personnalisés.

-Tableaux de bord interactifs.

-Interface graphique de construction

de tableaux de bord personnalisés.

-Fonctionnalités de Reporting de

masse.

- Mise à disposition des restitutions

dans un portail décisionnel.

Administration

SQL SERVER Management

studio

-Outil de gestion du dictionnaire de

données.

-Gestion de la sécurité.

-Gestion des reprises après

incidents.

2.2. Fonctionnalités détaillées par produits :

SQL Server Integration Services : L’ETL de Microsoft SSIS (SQL Server Integration

Services) permet d’alimenter un système d’information décisionnel à partir de sources

de données hétérogènes : base de données Oracle, OLEDB, fichiers (plats, XML,

Excel), etc.

L’entrepôt de données constitué doit être une base de données SQL Server. SSIS

permet également d’alimenter des cubes (Analysis Services) et peut s’interfacer avec

Reporting Services. [W5]

SQL Server Analysis Services: Le moteur Analysis Services permet de gérer des

cubes afin d’effectuer des analyses multidimensionnelles. Il intègre par ailleurs un

moteur de Datamining, fourni avec des algorithmes prédéfinis, qui offre des

35


fonctionnalités d’analyse avancées et un accès aux cubes Analysis Services. Il

s’intègre parfaitement aux outils Office. [W5]

SQL Server Reporting Services : SQL Server Reporting Services offre toutes les

fonctionnalités de Reporting avec la possibilité pour des utilisateurs avancés de créer

leurs propres rapports, via le Report Builder. Cet environnement de génération de

rapports met à disposition des utilisateurs un large choix de sources de données, de

formats de sortie (HTML, PDF, Excel etc.) et de canaux de distribution (email,

fichier…). SSRS est à même d’attaquer des sources SQL Server et non SQL Server.

[W5]

Portail d’entreprise: Office SharePoint est la solution portail de Microsoft mais il est

possible d’intégrer les tableaux de bord issus des différents produits Microsoft dans un

portail d’entreprise. [W5]

2.3. Architecture fonctionnelle :

L’architecture fonctionnelle de la plate-forme BI de Microsoft est représentée dans la

figure qui suit :

Figure ‎III-4 : Architecture fonctionnelle de la suite Microsoft SQL Server 2008 R2 [13]

2.4. Architecture technique :

Microsoft est un acteur majeur dans le domaine décisionnel qui observe une forte

croissance depuis quelques années (environ 30% du marché mondial) et élargit sa gamme de

produits de manière à offrir à ce jour l’un des produits les plus complets du marché

décisionnel.

Cette plateforme modulaire, intégrée, et interopérable s’appuyant sur des standards

dispose d’une forte évolutivité. Le tableau suivant résume l’architecture technique de la suite

décisionnelle de Microsoft :

36


Tableau ‎III-3 : Architecture technique de la suite MS SQL Server 2008 R2[13]

Options Fonctionnalités

Type d’architecture -Client/Serveur.

-Web.

Technologie d’architecture WEB -.Net.

Navigateurs préconisés

-Internet Explorer.

-Firefox.

-Google Chrome.

-Netscape.

-Opera.

Systèmes d’exploitation -Windows Server.

Stockage des données

-Base de données : SQL Server.

-Nombre d’accès simultanés: Pas de

contrainte particulière.

Modèle de données. -Modélisation à la demande.

Mode de calcul des agrégats

-ROLAP.

-HOLAP.

-MOLAP.

Interopérabilité avec d’autres outils du

marché

-Interopérabilité avec toutes les bases de

données relationnelles ou

multidimensionnelles compatibles OLEDB

ou ADOMD.Net.

Sécurité

-Gestion de comptes et de mots de passe

personnalisés, gestion de profils utilisateurs,

http, etc.

2.5. Stratégie vis-à-vis du monde de la santé

Microsoft a pour stratégie de démocratiser le décisionnel en offrant une solution très

complète et simple d’utilisation.

Des partenariats avec des sociétés telles qu’Alicante et Keyrus dans le domaine de la

santé permettent à Microsoft de proposer des offres spécifiques métier qui peuvent être

distribuées par des sociétés de services locales ou nationales :

Références Alicante : Centre Hospitalier Arras, Groupe AHNAC, Centre Hospitalier

Universitaire Nice, CH Creil, CH Senlis, etc.

Références KEYRUS : CH Foch, Hospices Civils de Lyon, etc.

Aujourd’hui SQL Server est utilisé par 400 établissements de santé.

3. Présentation de Microsoft SharePoint 2010

SharePoint est un portail regroupant une suite d’outils permettant aux

entreprises d’optimiser le cycle de vie de l’information non ou peu structurée, à l’intérieur

comme à l'extérieur de leur organisation. Basé sur une technologie web, SharePoint est une

37


solution de gestion et de partage de l’information (Enterprise Content Management ou ECM)

offrant :

L'intégration de processus métier et de workflow.

Un Framework de « business intelligence » permettant d’agréger des données métiers

et de créer des tableaux de bords (pilotage d'entreprise et aide à la décision).

Un outil de gestion de contenu (CMS).

Des espaces collaboratifs (gestion de documents, mise à disposition d’espaces de

travail ou de wikis).

Des services de gestion documentaire.

Un moteur de recherche indexant de multiples sources d’information tel que les sites

SharePoint ou les documents stockés.

Une intégration parfaite avec les outils bureautique Microsoft.

Un Framework permettant une intégration technique et fonctionnelle complète et sur

mesure.

La figure suivante représente le découpage fonctionnel de MS SharePoint 2010 :

Tableau ‎III-4 : Découpage fonctionnel de MS SharePoint 2010

Le Framework « Business Intelligence »

Le but des outils de ce Framework est de consolider, rassembler, homogénéiser,

synthétiser l'information dispersée à l'intérieur comme à l'extérieur de l'entreprise pour la

rendre disponible aux directions marketing, ressources humaines, finances, commerciales…

tout en organisant le partage de cette information dans un cadre sécurisé grâce à la mise en

place d'un portail Intranet décisionnel.[14]

SharePoint 2010 embarque un ensemble de briques permettant de construire ces

Intranets. La solution propose des moyens de diffusion de rapports, de mise en place

d'indicateurs, de visualisation d'informations décisionnelles utilisant Excel.

Il contient aussi :

Performance Point Services : Application qui permet d’analyser en détails les

performances de l’organisation. Elle permet aux utilisateurs de créer des tableaux de

38


bord d’aide à la décision de manière centralisée et toujours à jour, avec des

composants WebPart de cartes de performances, de rapports et de filtres qui

contiennent des visualisations de données interactives.

PowerPivot (extraction, consolidation, analyse de données simplifiée et à la demande)

accessible dans Excel ou via SharePoint.

Visio : affichez vos informations décisionnelles sous forme de schéma Visio.

Associées aux autres composants de SharePoint 2010, ces solutions permettent de

construire simplement un portail décisionnel collaboratif sans égal.

_________________________________________________________________________

Au terme de ce chapitre, nous avons présenté une étude comparative de quelques

suites décisionnelles, et ce pour montrer les points forts de la plate-forme BI de Microsoft et

l’emplacement de cette solution dans le monde des outils décisionnels, ensuite nous nous

sommes concentrés sur les produits de la gamme Microsoft que nous envisageons d’utiliser

pour la réalisation de notre projet, la suite décisionnelle MS SQL Server 2008 R2 et l’outil

MS SharePoint 2010 pour le partage de données. Finalement, nous rappelons que le choix de

ces outils a été effectué conformément à la politique du ministère de la santé pour les projets

informatiques, la mise en œuvre de notre solution sera détaillée au cours du chapitre suivant.

39


Chapitre 4

IV. Réalisation

Ce dernier chapitre est consacré à l’étape de la mise en œuvre de la solution qui constitue

l’avant dernière phase de la méthodologie de conduite de projets GIMSI, cette phase a

consisté en trois étapes. Dans un premier temps, nous étions amenées à mettre en œuvre le

processus d’alimentation des datamarts «Urgences» et «Consultations Externes». L’étape

suivante a consisté en la création des cubes OLAP. La dernière étape a consisté en

l’élaboration des rapports et des tableaux de bord, et ce, en utilisant les différents

composants Microsoft présentés dans le chapitre précédent. Nous décrivons, dans ce

chapitre, les détails relatifs à chaque étape.

1. Phase d’extraction, transformation et chargement:

La phase ETL est la première phase de la réalisation d’un projet décisionnel, sa finalité

est de construire l’entrepôt de données. A cet égard, nous avons abordé la plateforme SQL

Server Integration services (SSIS) qui permet d’extraire les données à partir d’une ou

plusieurs bases de production sources, les transformer à l’aide d’une série d’opérations et de

transformations si besoin, et finalement les charger dans le datawarehouse. C’est au moyen de

cet outil que nous avons réalisé cette phase ETL.

Pour réaliser cette étape dont la finalité est d’alimenter nos deux Datamarts

«Urgences» et «Consultation Externes», nous avons appliqué, aux données extraites de la

base de production source, les transformations et les opérations nécessaires telles que les tris,

les jointures, les conversions de types ainsi que d’autres opérations, avant de les charger dans

les datamarts. Quant au chargement, on a commencé par charger, tout d’abord, les tables de

dimensions avant de charger les tables de faits afin de respecter les contraintes d’intégrité lors

du chargement des clés étrangères dans les tables de faits.

Le rafraichissement des datamarts se fait chaque semaine de façon automatique, en

effet les tables des datamarts sont alimentées de façon automatique chaque fin de semaine, à

l’exception des tables qui n’ont besoin d’être alimentées qu’une seule fois, comme la

dimension Temps, Sexe, etc.

Nous citons ci-après, à titre d’exemple, les processus ETL concernant les dimensions

Personnel Sanitaire, Services et la table de fait «Fait_Urgences».

Pour la dimension Dim_PersonnelSani, nous l’avons alimenté à partir de deux tables

différentes qui sont la table «Cstahper» et la table «Pers», la première contient le personnel

sanitaire et les différents services auxquels ils sont affectés, la deuxième contient toutes les

informations concernant une personne telles que son nom complet et son sexe, etc.

40


Les données extraites de ces deux tables ont subi des transformations et des opérations

telles que les tris, les jointures de fusion avant d’être chargées dans la table de dimension

Dim_PersonnelSani.

La figure qui suit présente cette phase d’extraction, transformation et chargement de

cette table de dimension.

Figure ‎IV-1 : Processus ETL de la dimension Personnel Sanitaire

Les transformations présentées dans la figure ci-dessus sont :

Nouvelles lignes : Il s’agit d’une transformation de recherche qui exécute une requête

pour ne retourner que les lignes qui ont été insérées dans la base de production depuis

le dernier chargement de la table, et les lignes modifiées. Cette opération sert aux

rafraichissements automatiques de la table et est effectuée au début du chargement de

chaque table qui nécessite un rafraichissement régulier. [16]

Les tris: Cette transformation permet de trier les lignes du flux de données. Pour

configurer cette tâche, nous devons spécifier les colonnes à trier ainsi que leur ordre de

tri. Les tris sont indispensables avant toute opération de jointure de fusion. [16]

Suppression des doublons: « C’est une transformation de recherche qui permet

d’effectuer des recherches en utilisant une logique de correspondance» [16]. Dans

notre cas, on a utilisé une suppression des doublons des données issues de la table

source «Cstahper». En effet, une personne dans cette table peut être affectée à

plusieurs services, donc on ne sélectionne que les identifiants distincts du personnel

sanitaire.

Les jointures de fusion: «Cette transformation permet la fusion de deux flux de

données qui doivent être triés de la même manière. Pour configurer cette tâche, il

suffit de choisir le type de jointure que l’on souhaite utiliser puis de sélectionner les

41


colonnes à fusionner » [16]. Dans notre cas, nous récupérons le sexe et le nom complet

de chaque personne par une jointure entre les deux tables.

Pour la dimension Services, nous l’avons alimenté à partir de quatre tables différentes

comme il est illustré sur la figure ci-dessous.

Nous avons effectué des jointures entre ces tables ; une jointure entre les deux

premières tables, une deuxième jointure entre le résultat de la première jointure et la troisième

table et finalement une dernière jointure avec la quatrième table.

Figure ‎IV-2 : Processus ETL de la dimension Services

En ce qui concerne l’alimentation de la table de fait, on a fait appel à sept tables

différentes. Nous illustrons dans la figure qui suit la série de transformations et d’opérations

effectuées sur les données issues de ces tables avant qu’elles ne soient chargées dans la table

de fait «Fait_Urgences». En effet, nous avons effectué des jointures de fusion deux à deux

entre ces tables, des tris, et finalement une transformation d’une grande importance qui est la

colonne dérivée. En effet, cette transformation crée de nouvelles valeurs de colonnes en

appliquant des expressions aux colonnes d’entrée. Dans notre cas, nous avons utilisé cette

transformation pour effacer les blancs, remplacer les valeurs NULL par 0, et finalement pour

calculer l’âge du patient à partir de sa date de naissance et la date de sa prise en charge.

42


Figure ‎IV-3 : Processus ETL de la table de fait « Fait_Urgences »

43


Enfin, une configuration est nécessaire au niveau de SQL Server Agent pour rendre le

chargement des différentes dimensions de l’entrepôt de données automatique. Il s’agit de

définir un travail de type SQL Server Intégration Services qui exécute des étapes dans un

ordre précis, pour charger les tables de dimensions en premier suivies par les tables de fait.

Cette exécution se fait chaque fin de semaine de façon automatique.

2. Phase de création des cubes OLAP

Après avoir construit et alimenté les deux datamarts, vient l’étape d’élaboration des

cubes OLAP. En effet, un cube est une structure multidimensionnelle qui contient des

dimensions et des mesures, les dimensions définissent la structure du cube tandis que les

mesures fournissent les valeurs numériques présentant un intérêt pour l'utilisateur final. Cette

étape est primordiale dans tout projet décisionnel puisqu’elle nous permet, par la suite,

d’effectuer les analyses sur les indicateurs de performance.

A cet effet, la suite Microsoft propose son moteur OLAP SQL Server Analysis

Services qui permet d’analyser les données grâce à des fonctions d’analyse

multidimensionnelle. SQL Server Analysis Services utilise à la fois des composants serveur et

clients pour fournir des fonctionnalités OLAP et d'exploration des données, le composant

serveur est implémenté comme un service Microsoft Windows et les clients communiquent

avec Analysis Services à l'aide de la norme publique XMLA pour transmettre des requêtes en

langage MDX. [W8]

MDX (Multidimensional Expressions) est un langage de requêtes sur les bases de

données multidimensionnelles, il permet d’explorer les cubes OLAP, interroger les données

qui y sont contenues et les manipuler.

La création d’un cube OLAP consiste en la détermination des tables qui entreront dans

l’analyse, ensuite la détermination des KPI et puis la construction des dimensions, leurs

attributs et leurs hiérarchies. La figure suivante illustre l’interface de SSAS utilisée pour la

construction des deux cubes OLAP « Urgences » et « Consultations externes ».

44


Figure ‎IV-4 : Interface de SSAS

Comme le montre la figure, la création du cube « Urgences » met en jeu la table de fait

et les tables de dimensions du datamart relatif aux urgences. Les mesures qu’on vise à

calculer peuvent être classées en deux types :

Mesure: « Calculée directement à partir des données du datawarehouse» [17]. Dans

notre cas, on peut citer, à titre d’exemple, le nombre de patients en urgence, le nombre

des consultations externes.

Membre calculé: « est un membre dont la valeur est calculée en utilisant une

expression MDX» [17]. Dans notre cas, la moyenne mensuelle des patients avec sortie

des urgences, ou bien la moyenne quotidienne des patients servis en urgences sont des

membres calculés.

La création des dimensions se fait au niveau de l’explorateur de solution (à droite de

l’écran), à l’aide de l’assistant de création de dimensions auquel nous indiquons la table, le

nom et les attributs de la dimension. La hiérarchie de la dimension sera configurée au niveau

de sa structure.

Une fois la création terminée, on déploie les cubes dans le serveur de SQL Server 2008

Analysis services, par la suite, nous pouvons analyser nos indicateurs selon les axes d’analyses

définis préalablement. La figure qui suit présente une analyse de la Moyenne mensuelle des

patients servis en urgences selon les dimensions de l’âge et du motif de l’admission en urgences.

45


Figure ‎IV-5 : Exemple‎d’analyse‎sur‎le‎cube‎des‎Urgences

Les cubes subissent une opération de re-processing chaque fin de semaine de façon

automatique, ceci afin de rafraichir les données qu’ils contiennent et prendre en comptes les

nouvelles insertions au DWH dans l’analyse OLAP.

3. Génération des rapports

Pour réaliser les rapports, nous avons utilisé l’outil Report Builder 3.0, qui est un

composant de SQL Server Reporting Services, c’est un générateur de rapports entièrement

intégré à Reporting Services et qui met à disposition toutes les fonctionnalités de création de

rapports (cf. Annexe 3).

Parmi les rapports réalisés à l’aide de Report Builder 3.0 nous donnons à titre

d’exemple le rapport qui permet de visualiser la moyenne mensuelle des patients servis en

urgences pendant les trois dernières années (Figure IV-6) et celui visualisant le nombre de

consultations externes par sexes (Figure IV-7).

46


Figure ‎IV-6 :‎Exemple‎de‎rapport‎réalisé‎à‎l’aide‎de‎Report‎Builder

Figure ‎IV-7 : Rapport sur les consultations externes par sexes

Après la réalisation de chaque rapport, il est déployé dans le serveur de SQL Server

Reporting Services, ces rapports sont après visualisables via le service web Report Server qui

est une interface de communication entre les utilisateurs, les programmes clients et le serveur

de rapports SSRS.

4. Génération des tableaux de bord

Afin de diffuser les rapports réalisés et élaborer les tableaux de bords, on a utilisé un

outil de Microsoft nommé SharePoint Server 2010 qui fournit par le biais de son service

PerformancePoint Services des fonctionnalités d'analyse décisionnelle (BI) performantes

aidant les organisations à gérer leurs données, ceci en créant des tableaux de bord à l’aide du

47


concepteur PerformancePoint Dashboard Designer, les diffusant par la suite au plus grand

nombre d’utilisateurs.

La figure qui suit présente un exemple de tableau de bord qui concerne les urgences

créé à l’aide de cet outil :

Figure ‎IV-8 : Un tableau de bord pour les urgences

L’accès des utilisateurs à ces tableaux de bord se fait en respectant les droits qui leur

sont octroyés et les rôles qui leur sont affectés. En effet, SharePoint Server 2010 gère les

informations d’identification de l’utilisateur et sécurise l’accès au contenu des tableaux de

bord et à ses sources de données sous-jacentes en définissant par défaut les groupes

d’utilisateurs suivants:

Administrateurs: Ils ont le droit d’attribuer et modifier les autorisations des utilisateurs

pour les éléments de tableau de bord.

Collaborateurs: Ils ont le droit de créer les éléments de tableau de bord Performance

Point et les enregistrer dans les bibliothèques de documents.

Lecteurs: Ils ont le droit d’afficher et utiliser les éléments de tableau de bord.

48


Ces groupes sont personnalisables, comme on peut créer de nouveaux groupes selon

les besoins de l’organisme.

Une fois l’authentification validée, une nouvelle session est créée, et la page offre à

l’utilisateur l’ensemble des fonctionnalités disponibles selon son profil telles que la

navigation dans les cubes, l’affichage des tableaux de bord, etc. Dans le cas de

l’administrateur, il a le droit de visualiser les différents rapports et tableaux de bords, en

ajouter de nouveaux et aussi contrôler l’accès des autres utilisateurs.

_________________________________________________________________________

La réalisation de la solution décisionnelle fût l’occasion de combiner un ensemble

d’outils et de techniques présentés dans les chapitres précédents, durant le présent chapitre,

nous avons passé en vue les étapes de cette phase, l’ETL, la création des cubes OLAP et

finalement la réalisation des rapports et tableaux de bords. Néanmoins, La méthodologie

GIMSI ne s’arrête pas à la phase de mise en place, mais exige une amélioration permanente

par un audit du système, la phase que nous n’avons pas pu réaliser pour des contraintes de

temps.

49


V. Conclusion générale

Au terme de ce travail, nous rappelons que notre projet de fin d’étude s’est déroulé au

sein de la direction de l’informatique et des méthodes du ministère de la santé. Dans ce cadre,

nous étions chargés de mettre en place une solution décisionnelle.

Ce projet nous a permis d’approfondir nos connaissances acquises en matière de

l’informatique décisionnelle et aussi d’acquérir une première expérience professionnelle dans

ce domaine. A prime abord, nous avons veillé à adopter une méthodologie de conduite de

projets spécifique aux systèmes décisionnels qui est la méthode «GIMSI» afin de mieux

formaliser les conditions de réussite de notre projet décisionnel. En respectant les étapes de

cette méthodologie, nous avons commencé par définir les besoins du ministère de la santé, les

objectifs de notre projet afin de mieux cerner le périmètre et la portée de notre travail et aussi

on a défini un planning qui nous a permis de préciser les tâches nécessaires à la réalisation de

notre projet. Une analyse de l’existant a été effectuée avant d’entamer l’aspect conceptuel qui

a consisté à définir les axes d’analyses, les indicateurs clés suite à une série d’interviews avec

les responsables, et finalement la conception des modèles multidimensionnels. La réalisation a

constitué la dernière étape de notre travail et a consisté en l’alimentation des datamarts, la

création des cubes OLAP, et ce, en utilisant les plateformes offertes par la suite Microsoft. La

mise en place d’une application web pour la restitution des données sous forme de rapports et

tableaux de bord a été réalisée à l’aide de l’outil SharePoint 2010.

Quant aux perspectives envisagées suite à notre projet, nous proposons un audit du

système réalisé pour assurer un bon fonctionnement par la suite. Nous proposons également

de dispenser une formation au profit d’une équipe de la DIM afin qu’elle enchaine sur le

travail qu’on a réalisé et d’intégrer d’autres services à cette solution telles que le service

d’hospitalisation, des accouchements et bien d’autres dans le but d’avoir une vision

d’ensemble de toutes les activités hospitalières.

50


Glossaire

BI (Business

Intelligence)

Ensemble des moyens, des outils et des méthodes qui permettent

de collecter, consolider, modéliser et restituer les données,

matérielles ou immatérielles d'une entreprise en vue d'offrir une

aide à la décision et de permettre aux responsables de la stratégie

d'entreprise d’avoir une vue d’ensemble de l’activité traitée.

GIMSI Généralisation de l'accès aux Informations décisionnelles en

s'appuyant sur une Méthodologie d'inspiration Systémique

facilitant l'expression des Individualités de l'entreprise

OLAP (On-Line Analytical Processing) Mode de stockage optimisé

pour l’analyse. Les données sont stockées dans un cube à n

dimensions.

OLTP

(On-Line Transactional Processing) Mode de stockage optimisé

pour les applications transactionnelles.

SID Ensemble de données organisées de façon spécifique, facilement

accessible et appropriée à la prise de décision ou encore une

représentation intelligente de ces données au travers d'outils

spécialisés. La finalité d'un système décisionnel est le pilotage de

l'entreprise.

Tableau de bord

Document de référence utilisé par les utilisateurs du système

d'information de décision. Il indique des valeurs d'indices qui

décrivent l'évolution de faits utiles au processus de décision.

Carte de

performance

Dans les Services PerformancePoint dans Microsoft SharePoint

Server 2010, les cartes de performances sont des objets de

première classe qui sont stockés en tant que types de contenu

dans le référentiel PerformancePoint Services, ce sont des vues

basées sur des grilles qui affichent des indicateurs de

performance clé (KPI) et des données de dimension.

51


Bibliographie

[1]- MINISTERE DE LA

SANTE, (1994).

Décret n° 2-94-285 du 17 joumada Il 1415.


SANTE, (2007).

Stratégie 2008-2012.


SANTE, (Juin 2005).

Projet de financement et de gestion du secteur de la santé

« PFGSS », fourniture et installation de progiciels pour le

système d’information hospitalier avec intégration.

[4]- FERNANDEZ,

(Septembre 2008).

Les nouveaux tableaux de bord des managers-Le projet

décisionnel dans sa totalité, 4ème édition, Editions

d'Organisation Eyrolles.


SANTE, (2010).

Cadre nominatif du système d’information de gestion des

hôpitaux.

[6]- S.BENNANI, (2012). Cours systèmes d’aide à la décision.

[7]- C.VENGENOT. Datawarehouse, Laboratoire de bases de données.

[8]- Le projet décisionnel,

enjeux, modèles et

architecture du

datawarehouse, (6 novembre

1997).

Le projet décisionnel, enjeux, modèles et architecture du

datawarehouse Edition Eyrolles

[9]- H. ELGHAZEL Fouille de données-Datamining.

[10]- BERNARD

EPINASSE, (2009).

Entrepôt de données 2.

[11]-Didier DONSEZ Conception de bases décisionnelles.

[12]-VALENTIN PAULINE. Introduction à la BI avec SQL Server 2008, V. 1.

[13]- OHAYNON,

GABRIEL, (2007).

Projet bibliographique : guides d’utilisations des outils

décisionnels.

[14]- MICROSOFT, (2010). Guide d’évaluation de Microsoft SharePoint 2010 pour les

professionnels de l’informatique.

[15]- MIKE DONOHUE Introduction to Oracle Business Intelligence Standard Edition

One.

[16]- Thibault Denizet SSIS Implémenter un flux.

[17]-FESNEAU, DUCHER,

(Avril 2002)

L’informatique décisionnelle.

[W1] L’organisation du ministère de la santé public, disponible sur la

page :

http://srvweb.sante.gov.ma/Organigramme/Pages/default.aspx

Visitée le mois de Mars 2012.

[W2] Blog du Chef de projets, tout sur la Business Intelligence :

http://www.chefdeprojets.com/business-intelligence

Date de publication : 05/12/2008

[W3] http://fr.wikipedia.org/wiki/Rétroingénierie

Dernière modification le 20/03/2012, visité le 05/03/2012

[W4] Conception d’un entrepôt de données (Data Warehouse), par

Yazid Grim, disponible sur la page :

http://srvweb.sante.gov.ma/Organigramme/Pages/default.aspx

http://www.chefdeprojets.com/business-intelligence

http://fr.wikipedia.org/wiki/Rétroingénierie

52


http://grim.developpez.com/cours/businessintelligence/concepts/

conception-datawarehouse/

Page visitée le mois de Février 2012

[W5] La documentation en ligne de SQL Server 2008 R2, disponible

dans la librairie MSDN de Microsoft sur la page :

http://msdn.microsoft.com/fr-fr/library/ms130214(v=sql.105)

[W6] http://www.pentaho.com/explore/products/

Page visité en mois de Février 2012

[W7] « La liste des plates-formes décisionnelles généralistes », Le

blog du monde de la Business Intelligence.

http://www.legrandbi.com/liste-plates-formes-decisionnelles/

Publiée le 04/06/2009, visitée en Mars 2012

[W8] Référence aux langages pris en charge par SQL Server [MDX]:

http://msdn.microsoft.com/fr-

fr/library/ms145506(v=sql.90).aspx

Visitée en Avril 2012

[W9] Etapes de création de tableaux de bord avec des listes,

disponible sur la page :

http://www.learningsharepoint.com/2010/08/31/create-

dashboard-with-list-in-sharepoint-2010/

Publiée le 08/31/2010, visitée le mois de Mai 2012.

http://grim.developpez.com/cours/businessintelligence/concepts/conception-datawarehouse/

http://grim.developpez.com/cours/businessintelligence/concepts/conception-datawarehouse/


http://www.pentaho.com/explore/products/

http://www.legrandbi.com/liste-plates-formes-decisionnelles/


http://msdn.microsoft.com/fr-fr/library/ms145506(v=sql.90).aspx

http://msdn.microsoft.com/fr-fr/library/ms145506(v=sql.90).aspx

http://www.learningsharepoint.com/2010/08/31/create-dashboard-with-list-in-sharepoint-2010/

http://www.learningsharepoint.com/2010/08/31/create-dashboard-with-list-in-sharepoint-2010/

53


Annexe 1 : Méthodologie de conduite de projet GIMSI

La méthode GIMSI est une méthode coopérative de conception de systèmes d'aide à la

décision et plus précisément d'assistance au pilotage par tableaux de bord, elle développe une

approche coopérative centrée sur l’humain décideur. La démarche met en cohérence le

pilotage de la performance, la stratégie exprimée et les outils de la Business Intelligence au

sein même de l’organisation.

La méthode GIMSI est structurée en 10 étapes, chacune traitant une préoccupation

particulière du projet. Chacune des 10 étapes marque un seuil identifiable dans l’avancement

du système. Nous allons présenter les quatre phases de GIMSI afin de pouvoir traiter les

phases d’un projet BI, les dix étapes seront présentées plus en détail :

1-Les quatre phases

Phase 1. Identification

Quel est le contexte ?

Au cours des étapes 1 et 2, nous étudierons successivement l’environnement de

l’entreprise en terme de marché et de stratégie, puis les structures de l’entreprise

(l’organisation et les personnes).

Phase 2. Conception

Que faut-il faire ?

À l’étape 3, nous aborderons une méthode pratique pour définir les objectifs tactiques

locaux en accord avec les enjeux de l’entreprise. Puis, aux étapes 4 et 5, nous étudierons le

tableau de bord et nous choisirons les indicateurs. L’étape 6 sera consacrée à la collecte des

informations et nous construirons le système de tableau de bord à l’étape 7.

Phase 3. Mise en œuvre

Comment le faire ?

Maintenant nous sommes armés pour choisir le progiciel. Nous définirons à l’étape 8

une méthode rationnelle pour choisir sans être influencé par les annonces marketing et les

campagnes journalistiques. Nous étudierons l’intégration et le déploiement de la solution à

l’étape 9.

Phase 4. Suivi permanent

Le système correspond-il toujours aux attentes?

Nous nous assurerons, selon un processus d’amélioration permanente, de l’adéquation

entre le système et les nouveaux besoins des utilisateurs. Nous traiterons de l’audit du

système à l’étape 10.

2-Les dix étapes

Etape‎1‎:‎Environnement‎de‎l’entreprise

54


Objectifs de l’étape :

Au cours de cette étape, nous allons identifier l’entreprise en termes de marché, de

stratégie et de management.

Nous pourrons alors :

Définir la portée et le périmètre de l’étude.

Contrôler la finalité.

Mesurer l’engagement de la direction et la participation du personnel

Évaluer la difficulté.

Au cours de cette première étape d’identification, l’entreprise est analysée en termes

de :

Marché

Quels sont sa clientèle, sa concurrence, son environnement, ses produits, ses

fournisseurs et partenaires... ?

Ressources

Quelle est sa capacité à intégrer des solutions de haute technologie?

Management

Quel type de management pratique-t-elle et délègue-t-elle les pouvoirs ?

Culture

Quels sont les impacts de la culture d’entreprise sur ses structures ?

Stratégie

Comment se positionne-t-elle sur l’échiquier et comment envisage-t-elle son

devenir ?

En résultat seront identifiés :

1. La portée du projet.

2. Le niveau d’engagement de la direction.

3. Une première appréciation de la difficulté.

4. Une première appréciation du degré de coopération potentielle.

Etape‎2‎:‎Identification‎de‎la‎structure‎de‎l’entreprise


Au cours de cette étape, nous allons étudier la structure de l’entreprise :

Identification des processus cibles.

Identification des activités concernées.

Identification des acteurs.

Constitution des groupes de travail.

Au cours de cette deuxième étape d’identification, l’entreprise est analysée en termes de :

1- Métiers

Quels sont les métiers pratiqués par l’entreprise ?

55


2- Processus

Identification des processus concernés par le projet, mise en évidence des points

d’interface sensibles.

3- Activités

Identification de l’ensemble des activités de tous les processus sélectionnés.

En résultat, seront identifiés :

Les processus et les activités critiques.

Les hommes concernés sur le terrain par le projet.

Constitution des groupes de travail.

Etape 3 : Définition des objectifs


Pour décider, il faut un objectif.

Au cours de cette étape, nous choisirons les objectifs les plus adaptés pour décider.

Nous analyserons les critères de choix définissant un « bon » objectif.

Nous étudierons une méthode efficace pour les sélectionner.

Au cours de cette première étape de conception, les objectifs correspondant à l’application

locale de la stratégie choisie sont identifiés.

Chaque objectif sera caractérisé et évalué avant d’être sélectionné selon les 6 critères

suivants :

Borné

L’objectif est limité dans le temps.

Mesurable

Définition d’une métrique.

Accessible

Quels moyens, quelles contraintes, quels risques.

Réaliste

Quelle méthode d’accès.

Fédérateur

Adhésion globale.

Constructif

Contribue aux objectifs globaux.

En résultat, chaque groupe de travail dispose de la description de ses quelques objectifs de

progrès.

56


Etape 4 : Construction du tableau de bord


Au cours de cette étape, nous analyserons la structure du tableau de bord du décideur et

notamment, la relation entre les informations de l’entreprise et les indicateurs.

Au cours de cette deuxième étape de conception, le tableau de bord est défini.

Rôle et fonctions du tableau de bord :

Le tableau de bord assure une perception cohérente de la mesure de la performance.

Le tableau de bord ne comporte qu’un nombre d’indicateurs limité : 7±2 indicateurs

sont suffisants.

Le tableau de bord ne comporte que des indicateurs porteurs d’un sens précis pour son

utilisateur.

Le tableau de bord est un instrument personnel et un outil de communication. Le

tableau de bord est intrinsèquement cohérent.

Les fonctions du tableau de bord

Etape 5 : choix des indicateurs


Il est maintenant temps de choisir les indicateurs. Nous analyserons les critères et la

méthode de choix d’un bon indicateur adapté aux besoins des décideurs.

Sélection et construction des indicateurs.

Chaque indicateur sera caractérisé et évalué avant d’être sélectionné selon les 5 critères

suivants :

Temps réel

Il est rafraîchi suffisamment fréquemment afin de permettre la prise de décision dans

les meilleures conditions.

57


Mesure un ou plusieurs objectifs

Il mesure la performance selon un ou plusieurs objectifs.

Induit l’action

Selon l’information portée, il déclenche une ou plusieurs actions.

Constructible

C’est le résultat de l’étape suivante.

Présentable sur le poste de travail

Il est « ergonomiquement » présentable sur le poste de travail de manière à ce que

l’information et le sens porté soient compris le mieux possible.

En résultat, chaque groupe de travail dispose de ses indicateurs pertinents en fonction de

ses objectifs de progrès.

Etape 6 : la collecte‎d’information‎:


Une fois les indicateurs choisis, nous allons les construire avec les informations à notre

disposition.

Au cours de cette étape, nous allons étudier une méthode d’évaluation des informations

nécessaires pour la construction des indicateurs.

Les informations utilisées pour construire les indicateurs sont sélectionnées en fonction

des critères suivants :

Accessible techniquement.

L’information est disponible physiquement, elle est accessible au sein de

l’infrastructure existante.

L’information est disponible logiquement

Elle est nettoyée, vérifiée et consolidée.

Disponible « politiquement »

L’acteur produisant ou utilisant habituellement cette information est prêt en faire

partager les règles d’usage.

Pérenne

Elle ne disparaîtra pas sans prévenir.

58


Degré de confiance

Les utilisateurs ont foi en cette information.

Coût

On connaît le coût d’obtention de l’information.

Simplicité de la règle de construction.

En résultat : la liste des informations utilisées pour bâtir les indicateurs.

Etape 7 : le système de tableaux de bord

Objectifs de l’étape

Le décideur et son tableau de bord ne sont pas isolés. Nous étudierons au cours de cette

étape les liens et échanges entre les différents tableaux de bord et nous assurerons la

cohérence globale.

Cette étape traite la question de la cohérence globale du système de tableaux de bord.

Être autonome, ce n’est pas être isolé.

Les décideurs partagent et communiquent, notamment en utilisant des systèmes de

messagerie et de groupware. Ils échangent des informations construites et analysées.

C’est ainsi que chacun enrichit sa compréhension des problèmes.

Cette approche est grandement préférable aux techniques habituelles de reporting et de

consolidation successives qui, au contraire, appauvrissent l’information.

Ces échanges de connaissances se déroulent autant dans le sens horizontal que vertical.

Une fois le système en activité, pour éviter les dérives et garantir la cohérence globale

avec la stratégie déployée, la direction pourra périodiquement procéder à des audits dans des

conditions clairement définies et acceptées.

59


Etape 8 : choix du progiciel


Après avoir étudié les principaux concepts des outils de la Business Intelligence (BI) et

analysé l’offre du marché, nous définirons une méthode d’évaluation des outils en fonction de

nos propres besoins. Nous illustrerons cette étude avec l’exemple de l’entreprise GEM.

Le système décisionnel se compose des 3 principaux éléments :

La collecte avec notamment les outils d’ETL et les datawarehouse, datamart.

Le déploiement avec les portails et l’Internet/Intranet.

L’exploitation avec les outils de présentation et d’analyse (OLAP).

Pour sélectionner le produit de présentation adéquat, il est important de commencer par

identifier les critères de choix propres à l’entreprise et à son besoin. Les produits seront

confrontés et comparés sous l’éclairage de cette grille.

Etape 9 : intégration et dépoilement de la solution


Au cours de cette étape, nous étudierons les différentes phases de l’intégration et du

déploiement de la solution :

Configuration des progiciels.

Développements spécifiques.

Intégration à l’existant technologique et structurel de l’entreprise.

Déploiement de la solution.

La phase d’intégration et de déploiement n’est pas la plus facile ni la moins coûteuse du

projet.

Pour bien la préparer, il est bon de tenir compte :

Des contraintes propres aux produits choisis

Formation, adaptations techniques, configuration et personnalisation des outils...

Des contraintes propres à l’entreprise

Processus, infrastructure existante sur le plan physique et logique...

Du coût total

En n’oubliant pas l’ensemble des coûts accessoires.

De la durée

Il est préférable de répéter plusieurs projets courts que de se lancer dans un projet

global.

On considérera également, à leur juste valeur, les questions de sécurité, de maintenance et

de documentation.

Etape‎10‎:‎l’audit‎du‎système


60


Avec le temps, l’entreprise évolue. Nous nous assurerons périodiquement de la cohérence

du système avec les nouveaux besoins de l’entreprise et des utilisateurs.

Au cours de cette étape, nous étudierons une approche pratique de l’audit périodique du

système.

L’audit a pour objet d’analyser la pertinence du système installé et de définir les actions

nécessaires pour l’améliorer.

Il comporte 4 opérations principales :

Identification des axes d’amélioration

Réalisée en fonction des attentes de l’entreprise.

Interview et collecte des avis

Le point de vue valorisé des utilisateurs pour chaque axe.

Analyse des résultats

Repérage des axes devant être améliorés.

Définitions des actions d’amélioration.

61


Annexe 2 : Caractéristiques de l’outil DbVisualiser

DbVisualizer est un outil pour les développeurs et les administrateurs de bases de

données, riche, intuitif et multi-base de données, fournissant une interface unique et puissante

à travers une grande variété de systèmes d'exploitation. Avec son interface facile à utiliser,

DbVisualizer est l'un des outils d’exploration de bases de données les plus efficaces, il

fonctionne sur tous les principaux systèmes d'exploitation et prend en charge tous les

principaux SGBDR qui sont disponibles. DbVisualizer s’intègre de façon transparente avec le

système d'exploitation utilisé.

Caractéristiques :

Connexions simultanées de bases de données :

DbVisualizer supporte plusieurs connexions de base de données simultanées, il permet

une connexion facile aux bases de données. L'Assistant de connexion facilite le procédé de

définition des paramètres de la connexion pour chaque base de données supportée.

Connexions simultanées de BD

62


Graphiques d'intégrité référentielle :

DbVisualizer génère automatiquement des graphes d’intégrité référentielle (mapping

clé primaire/clé étrangère). Les objets du graphique sont positionnés automatiquement avec

un chevauchement minimal. Les graphiques peuvent être imprimés et exportés à des fins de

documentation.

Schéma de base de données

Les grilles de données :

Les informations de la base de données sont souvent affichées au format de grille. Les

grilles en DbVisualizer supportent des opérations telles le tri, le filtrage, les calculs simples,

mobiliser les colonnes et la gestion de l’apparition des colonnes. La grille de données peut

être exportée dans des formats de fichiers tels que CSV, HTML, XML et SQL insert

déclarations.

Explorateur de bases de données :

L'explorateur de base de données organise les objets de la base dans une structure

arborescente. Les connexions des bases de données peuvent être regroupées et les objets

filtrés. Les informations affichées dans l'explorateur de base de données dépendent de la base

63


de données actuelle. Quand un objet est sélectionné, des informations détaillées sont affichées

dans les vues de l'objet.

Exploration de BD et grilles de données

Support de base de données étendue :

Pour la majorité des bases de données, il existe un support étendu pour visualiser et

gérer les objets de bases de données spécifiques, telles les déclencheurs, procédures stockées,

les alias, les définitions de l'utilisateur : Les types, les fichiers de données, les utilisateurs et

plus encore.

Editeurs des Tableau de données :

Les données du tableau peuvent être éditées directement dans le grille de données ou

dans un éditeur de formulaire. En plus de l'édition de texte, DbVisualizer aussi supporte

l'édition de données binaires, BLOB et CLOB. Formats d'images communs tels que GIF,

PNG et JPG sont reconnus et affichés dans un visionneur d’image.

Puissant éditeur SQL :

L'éditeur SQL dispose d’une auto-complétion pour compléter automatiquement les

noms de tables et de colonnes lors de la saisie, de couleur mise en évidence, exécution de

scripts, de multiples ensembles de résultats et l'édition de ces derniers.

64


Moniteur :

La fonction du moniteur est puissante, affichant n’importe quel résultat de requête

définie comme une ligne, bar, tarte ou graphique. La fonction du moniteur prend en charge les

mises à jour automatiques et le résultat est une vue instantanée graphique de résultats de la

requête présentée soit dans la plaine le style de données ou sous forme de graphiques

puissants.

Exportation/Importation de données :

Les données des tables peuvent être exportées dans une variété de formats de fichiers.

Les fonctionnalités d'importation de données permettent d'importer des données provenant de

CSV (Comma Separated Values) vers des tables ou des grilles de bases de données.

65


Annexe 3 : L’outil Report Builder 3.0

Présentation :

Report Builder 3.0 est un outil de création de rapport Reporting Services qui permet de

générer des rapports à partir de nombreux types différents de sources de données et de les

publier sur un serveur de rapports ou un site SharePoint. Les rapports que vous créez peuvent

être consultés dans le Générateur de rapports, dans un navigateur Web ou dans le cadre d'une

application Microsoft Windows ou d'un site SharePoint.

Report Builder 3.0 introduit des visualisations supplémentaires par rapport à Reporting

Services, y compris des cartes, des lignes de tendance et des codes à bar qui peuvent aider à

produire de nouvelles connaissances bien au-delà de ce qui peut être réalisé avec des tables et

de tableaux standards. Report Builder 3.0 permet aussi de réutiliser des parties de rapport

existantes comme les blocs de construction pour créer de nouveaux rapports. En plus, les

utilisateurs constateront des améliorations de performances significatives avec des

améliorations à la capacité d'utiliser Report Builder en mode serveur. Cela permet une

création rapide de rapports avec la mise en cache des ensembles de données sur le serveur de

rapports lors de la bascule entre les modes design et visualisation.

Caractéristiques spécifiques :

Les caractéristiques spécifiques à Report Builder 3.0 sont axées autour de la

simplification du processus de création et d’édition des rapports et des requêtes et comprend

les éléments suivants:

Des assistants faciles à utiliser pour la création des tables, matrices, secteurs et cartes

de régions.

66


Prise en charge de l’ouverture et l’édition directe des rapports stockés sur le serveur de

rapports.

Support de l'utilisation des ressources serveur, tels que les sources de données

partagées.

Des concepteurs de requêtes pour les sources de données multiples, y compris un

concepteur de requêtes Microsoft SQL Server spécifique.

Documents

Rapport de fin d'étudesrime.emi.ac.ma/ressources_numériques/MISE EN PLACE D... · 2012-05-31 · 2011 III Rapport Projet de Fin d’Etudes -2012 Dédicaces Je dédie ce travail