ROYAUME DU MAROC - unpan1.un.orgunpan1.un.org/intradoc/groups/public/documents/UN-DPADM/UNPAN... · 4.2.2 Entrepôt de données d’entreprise ... 4.4 STRUCTURE DE GESTION DE L’ENTREPOT

RMA-B07-XXX-0004

25/09/2007

UN | DESAUN | DESAUN | DESAUN | DESA MMSPMMSP

UN | DESAUN | DESAUN | DESAUN | DESA MMSPMMSP

ROYAUME DU MAROC

PROJET E-RH DANS L’ADMINISTRATION PUBLIQUE MAROCAINE

- PREMIÈRE PHASE –

Architecture fonctionnelle et technique pour

l’Infocentre du Personnel de l’État

Royaume du Maroc RMA-B07-XXX-0004Projet e-RH dans l’Administration Publique Marocaine - Première phase Architecture fonctionnelle et technique pour l’Infocentre du Personnel de l’État

25/09/2007

Version 1.0 Page 0/1

___________________________________________________________________________________ Table des matières

UN | DESAUN | DESAUN | DESAUN | DESAUN | DESAUN | DESA

TABLE DES MATIÈRES

1. GÉNÉRALITÉS .............................................................................. 1

1.1 INTRODUCTION ............................................................................1 1.2 ACRONYMES ET GLOSSAIRE...............................................................1

2. CONTEXTE DU PROJET ................................................................. 4

3. SYSTÈME CIBLE ........................................................................... 5

3.1 OBJECTIFS .................................................................................7 3.2 IDENTIFICATION DES CONTRAINTES .....................................................8 3.3 CATÉGORIES D’UTILISATEURS ET AUTORISATIONS .....................................8 3.4 STRATÉGIE DE DEVELOPPEMENT .........................................................9

3.4.1 Stratégie à court terme : Données administratives.................... 10 3.4.2 Stratégie à moyen – long terme : Données qualitatives ............. 11

4. LIGNES DIRECTRICES DU PROJET.............................................. 12

4.1 CONDITIONS REQUISES DE LA SOLUTION ............................................. 12 4.1.1 Conditions requises portant sur les données............................. 13 4.1.2 Conditions requises portant sur les processus d’alimentation de l’entrepôt de données ...................................................................... 15 4.1.3 Conditions requises portant sur la qualité de la donnée.............. 16 4.1.4 Conditions requises portant sur les métadonnées...................... 17 4.1.5 Conditions requises portant sur le portail ................................. 17 4.1.6 Conditions requises architecturales ......................................... 19

4.2 ARCHITECTURE D’APPLICATION DU SYSTEME DECISIONNEL ......................... 20 4.2.1 Zone d’entreposage temporaire.............................................. 21 4.2.2 Entrepôt de données d’entreprise (EDW) ................................. 21 4.2.3 Mini-entrepôts ..................................................................... 21 4.2.4 Plateforme d’alimentation...................................................... 21

a) Stratégies d’alimentation....................................................... 23 b) Politiques d’alimentation ....................................................... 24

4.2.5 Qualité des données ............................................................. 25 4.2.6 Métadonnées ....................................................................... 26 4.2.7 Le portail ............................................................................ 27 4.2.8 Reporting prédéfini............................................................... 29 4.2.9 L’analyse OLAP .................................................................... 31 4.2.10 Les tableaux de bord décisionnels ........................................ 34 4.2.11 Les applications analytiques................................................ 37

4.3 ARCHITECTURES TECHNOLOGIQUES ................................................... 40 4.3.1 Vue d’ensemble des outils d’intégration des données................. 40

a) ETL .................................................................................... 40 b) Cadre général des produits de Qualité des données................... 43

4.3.2 Vue d’ensemble des outils de livraison des informations ............ 45


25/09/2007

Version 1.0 Page 1/1

___________________________________________________________________________________ Table des matières


4.3.3 Vue d’ensemble des outils d’analyse ....................................... 47 4.3.4 Matériel .............................................................................. 47 4.3.5 Infrastructure d’exploitation................................................... 49 4.3.6 Infrastructure d’essai/test ..................................................... 53

4.4 STRUCTURE DE GESTION DE L’ENTREPOT DE DONNEES .............................. 53

5. SERVICES .................................................................................. 56

5.1 FORMATION .............................................................................. 56 5.2 ASSISTANCE ............................................................................. 56

6. INDICATIONS POUR LA GESTION DU PROJET............................ 57

6.1 ANALYSE DU RISQUE .................................................................... 57 6.2 FIGURES PROFESSIONNELLES REQUISES .............................................. 58

FIGURES

Figure 1 - Niveaux de l’entrepôt de données...............................................7 Figure 2 - Cycle de développement itératif .................................................9 Figure 3 –Tableaux de bord décisionnels .................................................. 36 Figure 4 – KPI ...................................................................................... 37 Figure 5 - ETL ...................................................................................... 41 Figure 6 - Magic Quadrant for data Integration Tools, 2006 ........................ 43 Figure 7 - Magic Quadrant for Data Quality Tools, 2007 ............................. 44 Figure 8 - Magic Quadrant for Business Intelligence Platforms, 2007............ 46 Figure 9 - BI Platform Capabilities: Analysis ............................................. 47 Figure 10 - Architecture du système........................................................ 48 Figure 11 - Infrastructure matérielle logique d’exploitation – solution 1 ........ 50 Figure 12 - Infrastructure matérielle logique d’exploitation – solution 2 ........ 51 Figure 13 - Infrastructure matérielle logique d’exploitation – solution 3 ........ 52 Figure 14 - Structure de gestion de l’entrepôt de données .......................... 54


25/09/2007

Version 1.0 Page 1

___________________________________________________________________________________ Généralités


1. GÉNÉRALITÉS

1.1 INTRODUCTION Le présent document fournit un aperçu global de la faisabilité du système décisionnel « Entrepôt de données du personnel de l’État », en décrivant les caractéristiques, les aspects applicatifs et techniques ainsi que la structure de gestion de l’entrepôt des données. Ce document définit le projet dans son ensemble qui permettra, dans une première phase, la réalisation de l’entrepôt de données du personnel de l’État, portant sur les données administratives et, successivement, l’évolution modulaire de ce système à travers l’intégration des données qualitatives. Donc, ce document propose deux solutions qui seront mises en œuvre en deux étapes, l’une à court terme et l’autre à moyen et long terme. Ceci permettra la mise en place de l'infocentre intégré du personnel de l’État (infrastructures matérielles et logicielles). Enfin, ce document fournit les renseignements concernant essentiellement les facteurs de risque, les coûts, les bénéfices et les échéances temporelles du projet à un premier niveau de détail.

1.2 ACRONYMES ET GLOSSAIRE Le paragraphe suivant indique les acronymes et les définitions de tous les termes, d’utilisation courante, nécessaires pour une compréhension correcte et complète du document.

Acronyme Description

CCED Contrôle central des engagements de dépenses de l’État CED Contrôle des engagements de dépenses de l’État CGED Contrôle général des engagements de dépenses de l’État CMR Caisse marocaine des retraites DAAG Direction des affaires administratives et générales DB Direction du budget GRH Gestion des ressources humaines GIPE Gestion intégrée du personnel de l’État GPEC Gestion Prévisionnelle des Emplois et des Compétences MFP Ministère des Finances et de la Privatisation MEN Ministère de l’Éducation nationale MMSP Ministère de la Modernisation des Secteurs Publics ORD Ordonnateurs


25/09/2007

Version 1.0 Page 2

___________________________________________________________________________________ Généralités


Acronyme Description

PB Poste budgétaire PPR Paierie Principale des Rémunérations TGR Trésorerie générale du Royaume TE Tableau des effectifs GISRH Gestion Intégrée du Système des Ressources Humaines

Terme Description

Composantes COM

COM est le standard de référence pour le développement de composantes en environnement Windows.

Mini-entrepôts (DataMarts)

Archives alimentés à partir de l’entrepôt de données d’entreprise, contenant les données agrégées et thématiques, concernant un domaine bien donné.

CWM CWM est une série de spécifications pour le traitement des métadonnées. Ces spécifications fournissent, entre autres, un standard pour la création et à la mémorisation de métadonnées et un standard pour l’échange d’informations contenant des métadonnées parmi les différentes applications à l’aide des interfaces.

Pare-feu (Coupe-feu, Firewall)

Dans le cadre des réseaux d’ordinateurs, un coupe-feu est une composante passive de défense périphérique, un dispositif matériel qui peut accomplir également des fonctions de connexion entre deux ou plusieurs tronçons de réseau.

ETL Processus d’extraction, d’intégration, de transformation et d’enrichissement visant au chargement des bases de données (Extract, Transform and Load)

Fichier journal On appelle journal, un fichier texte où on enregistre les opérations exécutées par un programme informatique.

HTML Langage utilisé pour décrire les documents hypertextuels disponibles sur le Réseau. Il ne s’agit pas d’un langage de programmation, mais d’un langage de balisage, à savoir il décrit le contenu, textuel et non textuel, d’une page Web.

Métadonnées Information à support de la donnée, information des informations.

Portail Site Web accueillant le système de présentation des informations de support à la décision.

Aire/Zone d’entreposage temporaire (Staging Area)

Zone technique où les produits des processus métier sont consolidés, traités par différentes procédures (qualité, synchronisation et historisation) et agrégés ; tout cela avant l’alimentation de l’entrepôt et des mini-entrepôts.

Informatique Décisionnelle (Veille stratégique, Business Intelligence)

Désigne les moyens, les outils et les méthodes qui permettent de collecter, consolider, modéliser et restituer les données d'une entreprise en vue d'offrir une aide à la décision et de permettre aux responsables de la stratégie d’avoir une vue d’ensemble de l’activité traitée.


25/09/2007

Version 1.0 Page 3

___________________________________________________________________________________ Généralités


Terme Description

XML Langage de balisage ouvert et basé sur un texte fournissant les informations, de type structurel et sémantique, concernant les véritables données.

KPI Indicateurs clés de performance (Key Performance Indicators)


25/09/2007

Version 1.0 Page 4

___________________________________________________________________________________ Contexte du projet


2. CONTEXTE DU PROJET

La nécessité de la réalisation d’un «entrepôt de données du personnel de l’État» découle de la conscience acquise des exigences liées à une meilleure planification des politiques portant sur les Ressources Humaines de l’Administration publique du Maroc. La gestion administrative traditionnelle et les systèmes actuellement utilisés, sauf très rares exceptions, ne permettent pas de :

• Disposer de données immédiates et fiables pour évaluer l’état du personnel ;

• Analyser les évolutions de phénomènes clés ; • Identifier en temps utile les situations à corriger ; • Simuler l’impact d’interventions de différente nature (administrative,

organisationnelle, …). Il est essentiel de souligner que la réalisation de systèmes décisionnels ne sera pas d’aide seulement pour les niveaux les plus élevés de gouvernement (les « décideurs »), mais elle fournira des outils de gestion et de planification des Ressources Humaines pour les gérants à plusieurs niveaux de chaque Administration. Dans le document «État des lieux et stratégie e-RH à court, moyen et long terme», on a décrit en détail les systèmes d’information actuels, les bases de données disponibles, les partenaires concernés à différent titre dans la gestion des Ressources Humaines de l'État et les limites du système actuel. L’étude a également mis en évidence les données et les systèmes pouvant représenter une base significative pour la réalisation de l’ «entrepôt de données du personnel de l’État », comme il sera illustré par la suite.


25/09/2007

Version 1.0 Page 5

___________________________________________________________________________________ Système cible


3. SYSTÈME CIBLE

Un infocentre-RH est un système décisionnel constitué par :

• Des référentiels communs (concepts, données et nomenclatures associées); • Un entrepôt de données validées et conformes aux référentiels communs,

alimenté régulièrement à partir des données contenues dans les systèmes présents dans le circuit de gestion des Ressources Humaines;

• Des outils d’analyse et de simulation permettant d’établir des tableaux de bord et d’estimer, par exemple, les départs prévisibles à la retraite ou encore d’évaluer l’impact financier du repyramidage d’un corps ou d’une modification des règles de promotion.

L’entrepôt de données du personnel de l’État, en perspective, se configurera comme une banque de données, unique et certifiée, sur les ressources humaines, prévue pour accueillir et mettre à la disposition des concernés des informations consolidées venant de systèmes source hétérogènes, visant à la aider les décideurs dans leurs mission de gestion des ressources humaines. Les sources de données qui alimenteront l’entrepôt de données seront représentées par les systèmes d’information des institutions suivantes :

• Ministères ; • Paierie Principale des Rémunérations (TGR) ; • Caisse Marocaine des Retraites (CMR) ; • D’autres sources. Le système respectera la structure et les règles des systèmes décisionnels; il s’étalera sur plusieurs niveaux détaillés ci-dessous.

Le premier niveau, concernant les données, est représenté par la zone de «entreposage temporaire» contenant les données de détail certifiées venant des sources indiquées.

Le deuxième niveau est représenté par une base de données, l’entrepôt de données d’entreprise (EDW), constituant l’archive centralisé contenant les données organisées avec le maximum de la granularité et l’histoire, univoques et certifiées. Il est alimenté par la zone d’entreposage temporaire.

Le troisième niveau concerne les bases de données des mini-entrepôts, c’est-à-dire des archives alimentés à partir du EDW, contenant les données agrégées ou/et thématiques (organisées en zones thématiques), soit portant sur une zone thématique bien donnée ou dédiées à une catégorie d’utilisateurs spécifique.

Le dernier niveau est représenté par le portail pour l’accès aux informations qui fournira aux utilisateurs, sur la base de leurs habilitations, les services typiques d’un système décisionnel : reporting prédéfini et personnalisé, accès à


25/09/2007

Version 1.0 Page 6

___________________________________________________________________________________ Système cible


l’environnement de création d’interrogations personnalisées, accès aux informations enrichissant la donnée (métadonnée), accès aux informations concernant la qualité de la donnée et aux tableaux de bord.

Les deux premiers niveaux sont généralement indiqués comme zone dorsale, tandis que le troisième et le quatrième niveau sont généralement indiqués comme zone frontale. Les données élémentaires dans le passage à travers les différents niveaux seront soumises à des processus d’intégration, transformation, enrichissement, appelés ETL (Extraction, transformation et chargement) visant au chargement des bases de données. À l’intérieur du ETL, les données seront soumises à des processus de nettoyage, de contrôle du caractère exhaustif et de validation, ce qui est appelé processus de qualité des données.

L’élaboration d’un entrepôt de données exige une gestion des informations sur les données, généralement appelées « métadonnées », pour laquelle il est nécessaire de garder les traces de toutes les informations visant à définir et à décrire la donnée (la définition, la provenance, la composition…). Ces informations sont gérées, dans une autre archive spécifique : le dépôt d’archives des métadonnées. Ce dernier représente une référence cruciale lors des processus de développement de l'entrepôt de données et de recherche, ainsi que d’extraction des informations qu’il contient. Ces informations peuvent représenter le point d’entrée pour la navigation sur le patrimoine informatif, à l’aide de fonctionnalités mises à la disposition par les outils logiciels, destinées à l’utilisateur final (par ex : le créateur des rapports) et aussi au technicien responsable de la gestion de l’infocentre. Le cadre univoque et certifié de l’information permet de satisfaire, en temps utile, les exigences cognitives de synthèse, en assurant en même temps la cohérence et la fiabilité des informations.


25/09/2007

Version 1.0 Page 7

___________________________________________________________________________________ Système cible


< >< >< >

Données traitées

Données agrégées

Tableaux

de Bord

Acquisition des données

Contrôle qualité< >< >< >

Rapportsd’analyse

Rapportspréformatés

Simulations

< >< >< >Xml

Rolap/Molap

Rapports

Analyses

KPI

Relationnel3FN

Aide à la décision

Vision intégrée, synthétique des indicateurs sur RH

Information organiséeAnalyses dynamiques/préformatées

Données agrégées organisées en DM(par ex. par grade, par région)

Données sur le fonctionnaire

Données provenant de Ministères, TGR, et d'autres sur chaque Fonctionnaire

Figure 1 - Niveaux de l’entrepôt de données

3.1 OBJECTIFS Une solution d’informatique décisionnelle devrait permettre d'extraire, dans ce contexte, des "informations" à partir des données brutes, les analyser et les distribuer à tous les acteurs concernés. Cette solution devrait être basée sur un entrepôt de données où il serait possible de faire confluer le patrimoine de données concernant le personnel, géré par plusieurs départements ministériels. Par conséquent, la disponibilité de ce patrimoine permettrait d’atteindre les objectifs suivants :

• Acquérir une visibilité plus cohérente et plus fine des ressources humaines de la Fonction Publique ;

• Effectuer des études et des analyses, réaliser des tableaux de bord, des simulations permettant d’éclairer les choix en matière de gestion globale des ressources humaines ;

• Harmoniser et rapprocher les données RH entre les différents partenaires ; • Optimiser la mise en œuvre de la Gestion Prévisionnelle des Emplois et des

Compétences (GPEC). Suite à tout cela, la solution devrait assurer:

• La création à moyen – long terme d'une base de données complète concernant le personnel de la Fonction Publique ;

• L’intégration des données à l’aide de sources externes autorisées (par exemple la Direction de la Statistique), de façon à disposer d’une


25/09/2007

Version 1.0 Page 8

___________________________________________________________________________________ Système cible


augmentation remarquable des informations disponibles et, par conséquent, de la possibilité d’analyse ;

• Le caractère exhaustif, l’homogénéisation, la cohérence et l’intégrité des données acquises ;

• Le caractère immédiat dans l’utilisation des données et donc la possibilité pour le MMSP de respecter les obligations qui lui reviennent de façon plus efficace :

La possibilité de rédiger, de façon exhaustive et immédiate, les rapports, parmi lesquels les publications institutionnelles;

La possibilité de créer facilement des rapports pour des analyses improvisées ;

• La disponibilité de fonctionnalités d’analyse des données plus sophistiquées:

Enquêtes basées sur des niveaux avancés d’analyse des données; Fonctionnalités en mesure d’afficher une très grande profondeur historique, en envisageant éventuellement des mécanismes d’homogénéisation des données traitées ;

La couverture des besoins à caractère décisionnel/statistique à travers l’élaboration des indicateurs appropriés d’efficacité de la gestion du personnel ;

• Une action efficace de contrôle et d’enquête accrue concernant les dépenses du personnel de chaque administration ;

• La consultation des données même auprès des bureaux distribués sur le territoire;

• La définition d’une architecture fiable ; • La définition d’une architecture modulable et évolutive au fil des années.

3.2 IDENTIFICATION DES CONTRAINTES Les contraintes principales à considérer pour la solution sont définies par le contexte dans lequel l’infocentre RH s’insère, par conséquent, il serait nécessaire d'envisager un système :

• Évolutif, en mesure de répondre aux besoins des partenaires par priorité ; • Couvrant, d’une manière progressive, les domaines fonctionnels (selon

l’ordre de disponibilité et de priorité) ; • S’opérant initialement sur des départements pilotes.

3.3 CATÉGORIES D’UTILISATEURS ET AUTORISATIONS Le système devrait fournir un éventail de fonctions pour la définition et la gestion de la sécurité applicative. Ainsi, il devra assurer la sécurité des données d’application et en même temps, identifier les droits d’accès des utilisateurs. Chaque utilisateur recevra un nom d’utilisateur, un mot de passe et un profil utilisateur. Le profil utilisateur identifie les privilèges d’accès, en associant à chaque utilisateur ou groupe d’utilisateurs un ou plusieurs rôles. Un rôle définit un ensemble de fonctionnalités (simple consultation des rapports, possibilité d’élaborer de nouveaux plans d’analyse, création


25/09/2007

Version 1.0 Page 9

___________________________________________________________________________________ Système cible


d’utilisateurs, etc.) et des données auxquelles l'utilisateur peut accéder. Les niveaux d’autorisation peuvent être définis de façon totalement correspondante aux exigences organisationnelles et selon le type d’utilisateur prévu. Les profils des utilisateurs peuvent être classés comme suit :

Profil d’utilisateur

Quantité utilisateurs

Autorisation

3.4 STRATÉGIE DE DEVELOPPEMENT En ce qui concerne la méthodologie du développement du nouveau système, il est suggéré d’adopter une approche par démarches successives (ou itérations). À chaque démarche, une nouvelle portion de données est analysée et intégrée dans l’entrepôt de données, en augmentant ainsi le patrimoine informatif du système. Par cette approche « incrémentielle » et « itérative », à travers une série de cycles de développement, les objectifs susmentionnés sont graduellement atteints. Ainsi, au fil des années, les risques de faillite et les délais de livraison du système à l’utilisateur final sont réduits au minimum.

n-ièmeItération

DeuxièmeItération

PremièreItération

Analyse

Réalisation

Essai/Validation

Mise enexploitation

Figure 2 - Cycle de développement itératif


25/09/2007

Version 1.0 Page 10

___________________________________________________________________________________ Système cible


Le processus précédemment décrit est, donc, le résultat de plusieurs projets appelés « itérations » qui diffèrent des phases traditionnelles car chacun d’entre eux produit un résultat immédiatement utilisable par l’utilisateur final. L’itération se compose, à son tour, de phases traditionnelles d’analyse, réalisation, essai/validation et mise en exploitation; elle est accomplie sur la base des résultats acquis lors du cycle précédent de développement, avec un enrichissement réel du potentiel informatif de l’entrepôt de données. Les éléments qui qualifient le processus du développement proposé sont les suivants :

• La définition d’un modèle conceptuel unifié qui représente tout le patrimoine de données géré dans l’entrepôt de données, créé de façon itérative et à travers lequel il est possible de décrire de façon univoque les concepts entamés et les définitions correspondantes ;

• L’élaboration d’un dépôt d’archives unique des données (EDW), où celles-ci sont intégrées et soumises à des procédures de contrôle et de validation en assurant la certification ;

• La création d’un dépôt d’archives des métadonnées, où il est possible de mémoriser les « informations concernant les données »;

• La définition d’un modèle dimensionnel unifié où les dimensions et les mesures ayant la même valeur peuvent être uniques (conformes) ;

• La définition d’un processus qui certifie la qualité des données du système, en assurant que les informations, faisant l’objet de l’analyse, sont correctes par rapport aux données reçues lors de l’entrée dans le système.

La stratégie proposée est cruciale pour le projet de développement car plusieurs acteurs sont concernés. L’acquisition des données possédées par les différentes institutions exigera, en effet, une phase préliminaire et conjointe d’analyse des données et, successivement, la définition d’un protocole de transmission des informations. Ci-après, est illustrée une séquence possible des itérations pour la construction de l’entrepôt de données du personnel de l’État.

3.4.1 Stratégie à court terme : Données administratives

Itération 1 – première conception Dans cette étape, il faudra :

• Concevoir et réaliser aussi bien la zone d’entreposage temporaire que l’entrepôt de données d’entreprise (EDW), afin de collecter les données administratives fournies par la TGR et la CMR ;

• Concevoir et réaliser le mini-entrepôt ; • Concevoir et réaliser les processus d’alimentation de l’entrepôt de données

(ETL) ;


25/09/2007

Version 1.0 Page 11

___________________________________________________________________________________ Système cible


• Concevoir et réaliser les procédures de qualité aptes à assurer la certification de la donnée ;

• Intégrer les métadonnées techniques dans un dépôt d’archives unique (cela dépend du choix de l'outil qu'on envisage d'utiliser) et éventuellement publier les référentiels communs (concepts, données et nomenclatures associées) sur le portail ;

• Concevoir et réaliser tous les systèmes frontaux (portail, contextes d’analyse, rapports, tableaux de bord).

Itération 2 – Renforcement fonctionnel Enrichir les systèmes frontaux existants selon les nouveaux besoins exprimés par les utilisateurs et ajouter des outils et des fonctionnalités d’analyse des données administratives plus sophistiqués (par ex. Simulation, ..).

3.4.2 Stratégie à moyen – long terme : Données qualitatives

Itération 3 – première conception Dans cette étape, il faudra :

• Concevoir et réaliser aussi bien la zone d’entreposage temporaire que l’entrepôt de données d’entreprise (EDW) afin de collecter les données qualitatives fournies par les Ordonnateurs ;

• Concevoir et enrichir les mini-entrepôts existants ou en créer d’autres ; • Concevoir et réaliser les processus d’alimentation (ETL) afin d’enrichir

l’entrepôt de données à l’aide de données nouvelles ; • Concevoir et réaliser les procédures de qualité aptes à assurer la

certification de la donnée ; • Intégrer les métadonnées techniques et les référentiels communs

éventuellement publiées sur le portail ; • Élargir le système frontal (portail, contextes d’analyse, rapports). Itération 4 – Renforcement fonctionnel Enrichir les systèmes frontaux existants selon les nouveaux besoins exprimés par les utilisateurs et ajouter des outils et des fonctionnalités d’analyse des données qualitatives plus sophistiqués (ex. Simulation, ..). Itérations à venir Les itérations à venir suivront l’approche prévue en augmentant d’un côté les informations et de l’autre côté les fonctionnalités et les potentiels d’analyse.


25/09/2007

Version 1.0 Page 12

___________________________________________________________________________________ Lignes générales du projet


4. LIGNES DIRECTRICES DU PROJET

Les lignes directrices illustrent les itérations du Système décisionnel ; elles englobent, également, la définition des conditions requises initiales du projet et une description du système proposé en termes de ses propriétés et des principales modalités de réalisation.

4.1 CONDITIONS REQUISES DE LA SOLUTION Dans ce paragraphe, on décrit les conditions requises initiales du projet portant sur les différents aspects de la solution, aussi bien celles fonctionnelles que celles architecturales et techniques. L’adoption d’outils méthodologiques et technologiques sophistiqués, permettra de parvenir à un modèle « ouvert » qui devra permettre :

• L’acquisition et l’intégration, dans le système, de données venant d’acteurs même extérieurs faisant partie du panorama général du sujet entamé (par example la Direction de la Statistique);

• L’élaboration d’une banque de données unique et certifiée sur le Personnel de l’État ;

• La distribution, à l’aide de modalités simples et intuitives, de l’information pas seulement vers les partenaires de d’Infocentre, mais aussi vers d’autres acteurs faisant parti du processus général d’utilisation des données ;

• La possibilité pour certaines catégories d’utilisateurs d’effectuer tous seuls et de façon improvisée l’analyse des données.

Face aux conditions requises de bases susmentionnées, d’autres conditions s’imposent, plus spécifiques et découlant des objectifs fonctionnels et opérationnels des différentes catégories d’utilisateurs vers lesquelles le système devrait se tourner. Le système décisionnel devrait, en particulier :

• Fournir aux utilisateurs un ensemble de rapports prédéfinis visant à la publication de documents institutionnels ou internes, en mettant en place un nouveau processus de composition du document donné permettant de réduire les délais actuels de production ;

• Fournir un ensemble d’indicateurs mettant en relief les situations critiques remarquées ;

• Permettre aux utilisateurs, bénéficiant des autorisations, de créer et de publier des rapports pour répondre aux questions que les acteurs internes et/ou externes au MMSP leur posent avec une régularité accrue;

• Exporter les informations fournies par le système sous format non propriétaire (par exemple Excel).


25/09/2007

Version 1.0 Page 13



Les paragraphes suivants décrivent les conditions requises du système portant sur les données, les processus d’alimentation et de qualité des données, les métadonnées et l’instrument d’interrogation du patrimoine informatif.

4.1.1 Conditions requises portant sur les données

Potentiellement, tous les personnels civils de l’État - régis par le statut général de la Fonction Publique et les statuts des particuliers - font l’objet de ce système. L’effectif total du personnel civil de la fonction publique se chiffre autour de : 425 7701.

Départements Effectif Ministère de l’Éducation nationale 266660 DGSN 43050 Ministère de la Santé 37729 Ministère de la Justice 21184 Ministère de l'Éducation Nationale, de l'Enseignement Supérieur, de la Formation des Cadres et de la Recherche Scientifique (Enseignement Supérieur)

19358

Ministère des Finances et de la Privatisation 17519 Ministère de l'Intérieur 17000 Ministère de l'Agriculture et du Développement rural et des Pêches Maritimes (Dép. Agriculture et Développement rural)

7355

Ministère de l'Équipement et du Transport (Équipement) 5454 Haut Commissariat aux Eaux et Forêt et la Lutte contre la Désertification

5342

Secrétariat d'État auprès du Premier Ministre, chargé de la Jeunesse

3866

Secrétariat d'État auprès du Ministre de l'aménagement du territoire, de l'eau et de l'environnement, chargé de l'eau.

2768

Ministère des affaires étrangères et de la coopération 2604 Haut Commissariat au Plan 2286 Ministère de l'Équipement et du Transport (Transport) 1806 Ministère de la Culture 1752 Ministère de l'Habitat et de l'Urbanisme 1423 Ministère du Tourisme, de l'Artisanat et de l'Économie sociale (Départ. Tourisme)

1292

Ministère du Tourisme, de l'Artisanat (Départ. Artisanat) 1184 Ministère de l'Agriculture et du Développement rural et des Pêches Maritimes (Dép. Pêches Maritimes)

1182

Ministère des Habous et des affaires islamiques 1167 Ministère de l'Emploi et de la Formation Professionnelle (Emploi)

1073

Ministère de la Défense Nationale 977

1 Source : MMSP 2006 - NON COMPRIS LA DGSN, L’ADMINISTRATION DE LA DEFENSE NATIONALE ET

L’ADMINISTRATION DE LA GENDARMERIE ROYALE


25/09/2007

Version 1.0 Page 14



Ministère de l'Industrie, du Commerce et de la mise à niveau de l'économie

908

Ministère de l'énergie et des mines 868 Ministère de l'Aménagement du Territoire, de l'Eau et de l'Environnement (Aménagement du Territoire et Environnement)

803

Ministère de la Communication 477 Haut commissariat aux anciens résistants et anciens membres de l'armée de libération

422

Secrétariat Général du Gouvernement et Primature 542 Ministère de l'Emploi et de la Formation Professionnelle (Formation Professionnelle)

336

Ministère de la Modernisation des Secteurs Publics 319 Commerce Extérieur 206 Ministère délégué auprès du Premier Ministre, chargé des Affaires économiques et générales

202

Ministère du Développement Social, de la Famille et de la Solidarité

188

Administration de la Gendarmerie Royale 175 Département de la poste, des télécommunications et des technologies de l'information

145

Ministère chargé des Relations avec le Parlement 129 Secrétaire d'État auprès du Ministre du Développement Social, de la Famille et de la Solidarité, chargé de la Famille, de l'Enfance et des Personnes Handicapées

111

Secrétariat d'État chargé de l'Analphabétisme et de l'Éducation non Formelle

110

Total 469.972 Les conditions requises du système portant sur les données sont:

• Les données de type administratif et qualitatif doivent parvenir des fournisseurs sous un format standard unique et concordé et au niveau maximal de détail présent dans les différents systèmes ;

• Le système, résultant de différentes itérations, doit pouvoir acquérir et intégrer, à partir d’autres sources, des données concernant le contexte social et territorial. Ces informations doivent toujours afficher, parmi les métadonnées, la source d'origine;

• Les sources ayant le même contenu, même si partiellement, peuvent être toutes acquises ou bien une source peut être identifiée comme primaire; ces informations doivent toujours afficher, parmi les métadonnées, la source d'origine;

• Les données à caractère descriptif doivent être en français et arabe, par conséquent la banque de données devra être charpentée de sorte à permettre une simple interrogation des données dans les deux langues ;

• La granularité des données présentes dans l’entrepôt de données (EDW) et dans les mini-entrepôts devra être au niveau maximal de détail disponible ;


25/09/2007

Version 1.0 Page 15



• La profondeur historique des données présentes dans le EDW pourrait être, par exemple, de 10 ans ;

• La profondeur historique des données présentes dans les mini-entrepôts et, par conséquent, des données en ligne pourrait être, par exemple, de 5 ans;

• La date initiale de référence de données devra être établie, en envisageant éventuellement le chargement initial des données précédentes ;

• Les données historiques dépassant, par exemple, les 10 ans doivent être gardées hors ligne.

Ci-après la liste de toutes les sources qui alimenteront l'entrepôt de donnés du personnel.

Source Données d’intérêt/Système

Description Fréquence Remarques

TGR

CMR

SIRH Ministériel

Direction de la Statistique

…

Les données, validées et certifiées, extraites de l’entrepôt de données à travers des processus de chargement seront à la disposition de l’utilisateur final pour faire des analyses et des interrogations, dans les mini-entrepôts représentant le système. Les mini-entrepôts seront conceptuellement organisés en contextes d’analyse, à savoir en regroupements homogènes d’informations facilement reconnaissables par l’utilisateur final.

4.1.2 Conditions requises portant sur les processus d’alimentation de l’entrepôt de données

En ce qui concerne les procédures nécessaires pour acquérir les données de leurs différentes sources, les intégrer, les transformer et les charger dans les structures finales (processus ETL), il faut considérer les conditions générales suivantes :

• Réalisation, le cas échéant, d’une mise à jour incrémentale des données ; • Mise en place de l’historique des données ;


25/09/2007

Version 1.0 Page 16



• Organisation des procédures par cible ; • Programmation par événement, sur fenêtre temporelle nocturne et diurne ; • Programmation charpentée à travers des contraintes de précédence et des

parallélismes, gérée par le programmeur ; • Mise en place de la gestion des erreurs. Les conditions requises spécifiques pour l’entrepôt de données en question sont :

• Le processus d’extraction, transformation et chargement de l’entrepôt de données devrait être divisé en deux sous-processus :

le processus de chargement initial concernant les données précédentes ; le processus de chargement systématique ;

• Le processus de chargement initial pourrait englober certains algorithmes d’homogénéisation des données précédentes afin d’assurer la comparaison au fil des années des informations suite aux changements des différentes structures organisationnelles ;

• Le processus de chargement systématique des données devrait afficher une périodicité journalière et être de type incrémental afin de minimiser la fenêtre temporelle de l’opération ;

• La solution technologique devrait prévoir l’acquisition de données à partir de fichiers XML, basés sur un modèle prédéfini et unique afin d'en permettre l'intégration dans l'entrepôt de données;

• Les processus de chargement, à partir de l’identification et de l’extraction des données utiles dans les systèmes source, devraient aboutir à leur acquisition dans le système à travers la mémorisation dans la zone d'entreposage temporaire. Dans cette zone les données seront soumises à des processus de nettoyage, normalisation et filtrage avant d’être chargée, à travers les procédures ETL dans, le premier niveau de l’entrepôt de données. La donnée sera mémorisée de façon persistante et intégrée, au niveau maximal de granularité utile et avec le minimum de redondance possible ;

• Les données tirées de cet environnement devraient être ensuite soumises à d’autres transformations à travers les procédures ETL, découlant des règles métier identifiées lors de l’analyse afin d’atteindre une donnée synthétique et organisée en structures adéquates à une analyse multidimensionnelle.

4.1.3 Conditions requises portant sur la qualité de la donnée

En ce qui concerne la qualité de la donnée, afin d’assurer la certification de l’information, il faudrait appliquer le type de processus de « assainissement des données » schématisé dans les phases principales suivantes :

• Analyse (profilage) : identification des problèmes causant la qualité limitée de la donnée ;

• Amélioration ; analyse des problèmes et mise en place d’actions amélioratrices visant à les résoudre ;


25/09/2007

Version 1.0 Page 17



• Contrôle : élaboration d’un mécanisme de contrôle assurant que la qualité de la donnée est préservée à des niveaux acceptables.

La phase de Contrôle sera effectuée, systématiquement, dans le cadre de toute session d'alimentation du système ; à la phase de Contrôle on confiera la tâche de signaler, à l’aide d’indicateurs donnés, le déclanchement de publication de l’information produite. Il est souhaitable que les processus de gestion et amélioration de la qualité des données soient développés à l’intérieur des processus d’intégration, transformation et chargement des données (ETL). Les méthodes d’évaluation, à mettre en place pour réaliser un suivi correct de la qualité des données, seront spécifiées au cours de la mise en place du projet, après une analyse des conditions requises beaucoup plus détaillée.

4.1.4 Conditions requises portant sur les métadonnées

La condition requise est d’avoir un dépôt d’archives où toutes les métadonnées techniques et opérationnelles puissent converger (la possibilité de cette mise en place dépend du choix de l’outil qu’on envisage d’utiliser). Pour ce qui est des outils, qu’on envisage d’utiliser dans le développement des réitérations, il est nécessaire qu’ils soient compatibles avec le modèle CWM (Modèle de l’entrepôt de données commun), désormais un standard reconnu pour cette technologie et extrêmement diffusé.

4.1.5 Conditions requises portant sur le portail

Les conditions requises spécifiques concernant le système frontal sont:

• Être équipé en interfaces utilisateur – des systèmes simples et intuitifs aptes à satisfaire toute exigence afin de maximiser la productivité tant des utilisateurs finaux que du personnel technique chargé de l’entretien et/ou de l’évolution du système décisionnel;

• Disposer d’un mécanisme de contrôle des accès au système étroitement lié au rôle de l’utilisateur, en assurant une utilisation contrôlée et proportionnée au niveau approprié de responsabilité. Pour définir le scénario d’une session de travail, on peut dire que lors du démarrage du système, l’utilisateur se déclarera au système qui sera à même d’identifier la catégorie d’utilisateurs à laquelle il appartient et de mettre à sa disposition les fonctions répondant à son profil d’utilisation ;

• Disposer de mécanismes permettant la présentation des informations en français ou en arabe ;

• Fournir au personnel responsable de la sécurité toutes les fonctions nécessaires à la gestion des profils utilisateurs ;

• Accéder au patrimoine informatif du système de façon simple et intuitive:

en cas d’analyse improvisée des données, on devra permettre de :


25/09/2007

Version 1.0 Page 18



o sélectionner le contexte d’analyse d’intérêt (où, par contexte d’analyse on fait allusion à un regroupement de données satisfaisant une exigence informative donnée) ;

o formuler sa propre demande de données en naviguant sur les objets immédiatement compréhensibles par l’utilisateur final et représentant les mesures et les dimensions d’analyse ;

o choisir le type de rapport selon lequel il est possible d’afficher le résultat de la recherche (tableau, à domaines croisés, graphique, régler des sauts de pages, en-têtes, etc.) ;

o donner un format définitif aux données du rapport (graphique, à domaines calculés, sauts de pages, en-têtes, etc.) ;

o enregistrer le rapport créé dans des dossiers personnels ou les partager avec d’autres utilisateurs ;

en cas de consultation prédéfinie, pour simplifier l’orientation parmi les nombreux rapports et documents regroupés, il faudra permettre de : o accéder à un ensemble de rapports regroupés par sujet ; o disposer de fonctionnalités de recherche des rapports par mot contenu

dans le titre et/ou, selon l’outil frontal choisi, dans la description ou par mot-clé ;

o afficher les métadonnées sur lesquelles le rapport repose (définitions des objets avec indication claire et directe de la source d’origine, filtres et formules appliqués, détails de production de la recherche et du rapport) afin d’interpréter rapidement les informations contenues et d'en comprendre l'origine.

L’outil d’utilisation du patrimoine informatif sera le portail qui représentera un point unique de consultation du patrimoine informatif et il devra permettre aux différentes catégories d’utilisateurs, sur la base de leurs propres habilitations, de :

• Présenter des différentes modalités de consultation du patrimoine informatif : analyses improvisées, rapports prédéfinis, fonctions de recherche des rapports ;

• Afficher la liste de rapports prédéfinis à la disposition de l’utilisateur ; • Afficher les documents sous différents utilitaires, tels qu’Adobe PDF,

Microsoft Word, Excel ou PowerPoint (possibilité liée au choix de l’outil frontal).

• Naviguer et analyser les données selon les dimensions d’analyses spécifiées;

• Fournir aux résultats de la requête de données, un format de présentation tabulaire ou graphique, ayant la possibilité de choisir parmi les différentes possibilités ;

• Régler des paramètres de sélection sur les rapports (par exemple, demande de paramètres, sélection d’une liste de valeurs, etc.) ;

• Élargir les tableaux et les graphiques vers des niveaux de plus ample détail (zoom avant) et vice-versa (zoom arrière) ;


25/09/2007

Version 1.0 Page 19



• Appliquer des filtres sur les données contenues dans les rapports ; • Analyser les informations consolidées extraites, sans d’autres interrogations

de la base de données (la possibilité d'analyse hors ligne dépend du choix de l'outil frontal) ;

• Exporter des tableaux prédéfinis, des graphiques ou tout simplement des données en fichiers Excel ou PDF ;

• Naviguer rapidement sur les sections de rapports (possibilité dépendant du choix de l’outil frontal, par exemple navigation sur l’arborescence) ;

• Sauver les modifications apportées à un rapport ; • Bénéficier de la possibilité de sauvegarder les instances historiques d’un

document ; • Modifier, déplacer, copier, éliminer et renommer les rapports ; • Envoyer un document à plusieurs utilisateurs avec différentes informations

(selon les droits de l'utilisateur destinataire) ; • Imprimer les rapports ; • Recevoir et classer les rapports ; • Distribuer et échanger les documents entre les utilisateurs ; • Gérer les documents de tiers, tels qu’Adobe PDF, Microsoft Word, Excel ou

PowerPoint.

4.1.6 Conditions requises architecturales

La solution devra satisfaire les conditions requises architecturales suivantes :

• La modularité : simplicité d’adaptation de l’architecture matérielle et logicielle, suite à l’augmentation du nombre d’utilisateurs à satisfaire et de la hausse de volume des données à gérer et élaborer ;

• L’extensibilité : possibilité d’introduire au fil du temps de nouvelles applications ou technologies sans aucun impact sur la conception du projet ;

• La consistance : caractère exhaustif des composantes architecturales, à savoir la présence, pendant une première phase, de toutes les composantes architecturales typiques de l’entrepôt de données au moins de façon minimale ;

• La sécurité : possibilité de contrôler les accès des utilisateurs, en en différenciant les modalités d’utilisation et la visibilité de l’information tant en termes de quantité que de nature, enfin le système devra assurer un très haut niveau de fiabilité ;

• L’administrabilité : simplicité des activités de l’administration du système. D’autres conditions requises contribuant à la définition du dimensionnement du système et influençant donc les choix architecturaux sont :

• La modalité de consultation du patrimoine informatif (frontal) devra être utilisable tant à l’intérieur du MMSP que d’autres Ministères ou Organismes (Extranet) ;

• La quantité d’utilisateurs, dont : utilisateurs du MMSP,


25/09/2007

Version 1.0 Page 20



utilisateurs d’autres Ministères ou Organismes ; • La quantité maximale d’utilisateurs en simultanée ; • La dimension totale des données gérées dans le système en Gbyte par

annualité gérée ; • L’horaire hypothétique de disponibilité journalière (par exemple, la fenêtre

temporelle 8-18) ; • La périodicité des procédures d’alimentation (par exemple, périodicité

journalière où pendant la nuit on met à jour les mini-entrepôts avec les données élaborées par les systèmes d’origine).

4.2 ARCHITECTURE D’APPLICATION DU SYSTEME DECISIONNEL L’image suivante représente la structure du système décisionnel à mettre en place.

P O R

T A I L

SIRHMin3

SIRHMin2

SIRHMin1

SIRHMin6

SIRHMin5

SIRHMin4

@ujour

MinistMinistèèresres

Autres sourcesAutres sources

TGRTGR

Bases spécialisées(datamarts)

P L A T E –

F O R

M E D

‘ALIM

ENTA

TION

CMRCMR

MMSPMMSP

TGRTGR

MinistMinistèèresres

Contrôle de la qualité

Transforma-tion

Synchro-nisation

Histori-sation

Agrégation

Extraction

Entrepôt de Entrepôt de donndonnééesesDonnées

individuelles et agrégées

CMRCMR

Sources Usagers

MMéétadonntadonnééeses

Elaborations Statistiques

Analyse dynamique

Tableaux de bord

Indicateursclés de

performance

Simulation

Tableaux préformatés

Instance responsable de la gestion fonctionnelle et technique

……

DBDB

Figure 4 – La structure du système décisionnel

Il ressort de la figure que la structure du nouveau système décisionnel est la structure traditionnelle des systèmes de ce genre (Entrepôt de données et informatique décisionnelle de type corporatif). Ci-après l’utilisation des différentes composantes.


25/09/2007

Version 1.0 Page 21



4.2.1 Zone d’entreposage temporaire

La zone d’entreposage temporaire sera utilisée pour les différents buts mentionnés ci-dessous :

• Déposer les données venant des systèmes source ; les données, présentes dans les fichiers sous format standard et venant des systèmes alimentant, seront introduites dans des tables relationnelles prédéfinies ;

• Identifier les nouvelles données (celles qui devront être introduites à l’intérieur des structures de l’EDW), en comparant éventuellement les données nouvelles avec celles déjà présentes dans le système afin de définir les données incrémentielles qui devront être élaborées.

Pour des informations plus détaillées, veuillez faire référence aux paragraphes concernant la stratégie d’alimentation et les politiques d’alimentation.

4.2.2 Entrepôt de données d’entreprise (EDW)

L’EDW sera principalement utilisé pour organiser les données du système de sorte à créer une situation congrue, avec une profondeur historique bien donnée, à partir de données venant de sources externes. À ce propos, les données contenues seront organisées en structures normalisées, étant ce type de structure le plus adéquat pour ce but.

4.2.3 Mini-entrepôts

Ils engloberont les données pour les analyses de la part des utilisateurs et ils seront organisés en structures nommées schémas en étoile. Afin de permettre des interrogations, en combinant les données présentes dans plusieurs mini-entrepôts, les dimensions des mini-entrepôts devront être conformes entre elles. Afin de mieux préciser, les dimensions ayant la même valeur, présentes en plusieurs mini-entrepôts devront afficher la même structure et le même contenu; dans les cas où deux mini-entrepôts contiendraient la même dimension, mais à des niveaux de granularité différents, la dimension ayant la profondeur la plus réduite devra être identique à la partie de plus haut niveau de l'autre dimension.

4.2.4 Plateforme d’alimentation

Elle sera composée par les programmes d’alimentation de l’entrepôt de données, dont la tâche consiste à acquérir les données venant des systèmes d’exploitation (et en général de sources externes) sous format standard (xml) et à les traiter afin de les mettre à la disposition des utilisateurs finaux, sous forme adéquate au type d’interrogation requise.

L’alimentation des structures de données des différents environnements de l’entrepôt de données créées ou modifiées pour la réalisation des différents mini-entrepôts sera organisée en unités élaboratrices (PROCÉDURES) dont l’exécution sera contrôlée à l’aide d’un plan d’exécution (PROGRAMMATION).


25/09/2007

Version 1.0 Page 22



La composante d’élaboration (lecture, transformation et écriture des données) est assignée au produit de ETL; la composante de gestion de chaque procédure (contrôle des résultats, gestion des erreurs, arrêt et reprise) sera réalisée en combinant les fonctionnalités natives du produit de ETL et du programmeur.

L’alimentation des différentes composantes de la base de données sera réalisée à travers un macroflux élaborateur intégré dans le macro processus d’alimentation plus général de l’entrepôt de données et organisé dans les phases suivantes :

Phase d’élaboration Buts Enrichissement base de données de la zone d’entreposage temporaire

Préparation de l’information et identification du delta de données faisant l’objet du chargement.

Chargement des données EDW

Intégration et mise en place de l’historique des données.

Chargement des données base de données

Agrégation et personnalisation des données.

Le chargement du système décisionnel sera réalisé selon les étapes suivantes:

• Secours informatique des données : afin de permettre la consultation, les fichiers plats contenant les données alimentant devront être sauvegardés dans des dossiers appropriés ;

• Chargement des données dans la zone d’entreposage temporaire : les données contenues dans chaque fichier seront successivement introduites dans une table correspondante de la composante base de données de la zone d’entreposage temporaire. Lors du chargement, on effectuera un premier assainissement des données (nettoyage de données). L’identification du delta d’intérêt (enregistrements nouveaux, modifiés et éliminés par rapport au chargement précédent) sera réalisée, où il n'existe pas d'indicateurs fiables (par exemple : date/heure de la dernière mise à jour) pour identifier les enregistrements modifiées, en effectuant une comparaison entre les données de la table d'entreposage temporaire, chargé à partir du téléchargement en cours, et les données du dernier téléchargement chargé avec succès (elles sont aussi gardées dans la zone d’entreposage temporaire dans une table homologue) ;

• Chargement des données dans l’EDW : les données présentes dans la zone d’entreposage temporaire seront reliées entre elles et introduites (au niveau de détail le plus élevé possible) dans les tables de l’entrepôt de données d’entreprise, à l’intérieur desquelles on réalisera l’historique des données afin de permettre la reconstruction des situations à une date bien précise ;


25/09/2007

Version 1.0 Page 23



• Chargement des données dans les mini-entrepôts : à partir des données de l’EDW, on alimentera les mini-entrepôts à l’intérieur desquels les informations seront organisées de sorte à pouvoir faire face facilement aux demandes de l'utilisateur final.

a) Stratégies d’alimentation

Dans ce paragraphe, on décrit les principales caractéristiques du macro-processus d’alimentation qui portera les informations des sources des données aux environnements d’entreposage temporaire, à l’EDW et aux mini-entrepôts.

Tenu compte de la volumétrie de données traitées, on a identifié des stratégies d’alimentation ayant pour objectif principal la minimisation de l’engagement, en termes de temps et de ressources, tant sur les systèmes alimentant que sur les fonctionnalités de reporting (disponibilité en ligne des mini-entrepôts par sujet). Il sera également opportun d’adopter une programmation d’alimentation des différentes bases de données composant l’entrepôt de données, pas obligatoirement séquentielle (zone d’entreposage temporaire, EDW et mini-entrepôts), mais répartie en délais et en jours différents selon l’importance des données à afficher pour l’utilisateur final. Le processus d’alimentation suivra, en général, le schéma suivant :

• Les systèmes de gestion mettront à la disposition les données d’intérêt à travers des modalités fiables et sûres ;

• A des intervalles donnés, sera entamé le processus de copie des données susmentionnées dans la zone d’entreposage temporaire ;

• Il serait convenable d'effectuer un chargement incrémentiel des enregistrements (copie « delta » de la table) si les données sources contiennent des indicateurs fiables de « modification de données » (par exemple : date/heure de la dernière mise à jour, qui permettent d’identifier de façon claire et directe seulement les enregistrements avec des modifications effectuées suite à l'élaboration précédente);

• L’exécution du contrôle de synchronisation (réconciliation) seulement pour les données venant de sources différentes, pour lesquelles on prévoit ce traitement et la signalisation des réconciliations éventuellement impossibles;

• Pour les fichiers d’alimentation où il n’existe pas d’indicateurs fiables de «modification des données» on effectuera la copie complète dans une autre table d’entreposage temporaire, qui sera soumise à un autre traitement afin de déterminer les enregistrements variées par rapport au sauvegarde précédent (détermination du « delta ») ;

• Les données présentes dans chaque table « delta » devront être soumises, toujours dans la zone d’entreposage temporaire, aux contrôles de qualité identifiés pour chaque donnée et on devra effectuer les éventuelles signalisations d’incongruité remarquées ;


25/09/2007

Version 1.0 Page 24



• Les données « certifiées » (qui ont réussi tous les contrôles de qualité prévus) seront chargées dans l’EDW ;

• Suite au chargement de l’EDW, on effectuera les opérations d’agrégation pour le chargement des mini-entrepôts ; pour chaque mini-entrepôt, on identifiera la périodicité et la couche horaire pendant laquelle il sera possible d’effectuer l’opération, de sorte à minimiser les délais d’arrêt des fonctions développées sur le mini-entrepôt même. Dans le cas où la présence en ligne de ces informations serait particulièrement importante ou que les délais d’alimentation des mini-entrepôts seraient trop longs, on pourra envisager un double du mini-entrepôt même et effectuer la procédure de chargement suivante :

alimenter tout d’abord la copie du mini-entrepôt (copie « hors ligne») ; effectuer l’aiguillage en ligne du mini-entrepôt venant d’être alimenté ; réaligner l’autre copie du mini-entrepôt.

• Gestion des erreurs : afin d’assurer l’intégralité des données de l’entrepôt de données, en cas d’erreur, les opérations d’alimentation effectueront des «annulations» de façon automatique après l’enregistrement de l’événement en structures de données appropriées pour en permettre la consultation ; pour préciser, en cas d’anomalie, on enregistrera l’erreur vérifiée et on restaurera la situation des données précédant le début du chargement.

b) Politiques d’alimentation

Ce paragraphe schématise les modalités d’extraction, de transfert et de chargement avec les principales transformations effectuées, en termes de :

• Périodicité d’alimentation : même si la fréquence de « modification » des données source est à plusieurs niveaux temporels, il faut considérer le fait que les données peuvent être soumises à plusieurs envois. Ceci dit, il est conseillé de programmer les processus ETL selon la fréquence de mise à jour du type de donnée spécifique ;

• Modalités d’alimentation : afin de réduire, le plus possible, les délais de chargement de l’EDW et des mini-entrepôts, il faudra envisager une première procédure de chargement initial pour alimenter toute la base informative (l’historique et l’actuel) et réaliser une ou plusieurs procédures de chargement « incrémentielles » permettant de mettre à jour l’EDW seulement pour les enregistrements réellement changées par rapport au chargement précédent. Afin d’identifier ces dernières enregistrations, on utilisera, si présente et fiable, la « date de dernière mise à jour », autrement, on effectuera la comparaison entre les données actuelles et les données précédentes (dans la zone d’entreposage temporaire) pour définir les changements vérifiés du dernier chargement ;

• Historique des données : il faut définir la période de maintien en ligne des données à caractère historique ; en plus, ces données pourront être gardées, agrégées selon certaines caractéristiques afin de fournir un reporting spécifique pour des analyses sur l’évolution des phénomènes


25/09/2007

Version 1.0 Page 25



utiles. Il reste également possible de maintenir les données de détail passées récupérables sur demande ;

• Reconstructions des situations à partir des données changées : les données changées (pour lesquelles on a acquis de nouvelles valeurs) ne seront pas effacées physiquement de l’EDW mais elles seront « supprimées » logiquement ; à chaque donnée on associera une période temporelle (date de début validité et date de fin validité), qui sera utilisée pour définir un laps de temps pendant lequel la donnée même affiche une validité.

4.2.5 Qualité des données

Il faudra réaliser des procédures effectuant des contrôles sur les données présentes dans les différents niveaux du système décisionnel (zone d’entreposage temporaire, EDW, mini-entrepôts) afin d’assurer l'exactitude des programmes ETL et assurer, par conséquent, la certification des informations. Les contrôles sur la qualité des données assureront l’utilisateur que les données ont été correctement transférées des systèmes sources vers le système cible. Les résultats des contrôles de qualité (méthodes de qualité) seront enregistrés à l’intérieur de l’entrepôt de données et ils pourront être consultés à tout moment à travers des rapports spécifiques. L’analyse de la qualité d’une donnée peut être effectuée à plusieurs niveaux de précision et dans plusieurs buts. Dans ce paragraphe, on identifie les types de contrôle qui seront effectués :

• Analyse de chaque domaine pour vérifier qu’ils contiennent des valeurs significatives et pour ceux contenant des valeurs significatives, contrôle de la véritable validité en termes de format des domaines, ou valeurs par défaut assignées ;

• Contrôle que l’environnement des données est conforme aux règles établies par l'utilisateur ; ce contrôle se concrétise dans la définition de contrôles sur les tables/fichiers pour s’assurer que les données respectent les critères et les règles métier;

• Contrôle que les données ont été correctement transférées d’un système source à un système cible.

Les outils de qualité des données simplifient la mise en place des contrôles de qualité; ils mettent à la disposition des fonctionnalités de profilage de données et de support au contrôle de l’intégralité structurelle en fournissant et en maintenant les statistiques pertinentes.


25/09/2007

Version 1.0 Page 26



4.2.6 Métadonnées

Il s’agit des données décrivant de façon compréhensible à l’utilisateur du système, les objets présents dans le système décisionnel (programmes ETL, rapports, etc.). Les informations représentées par les métadonnées peuvent être affichées sur deux niveaux de détail. Un premier niveau d’informations adressées au personnel technique gérant l’entrepôt de données.

Un deuxième niveau d’informations adaptées et compréhensibles à l’utilisateur final :

• Source des données ; • Nomenclature ; • Dernière date de transmission. Pour ce qui est des métadonnées techniques, il est proposé de mettre en place un dépôt d’archives unique des métadonnées permettant à l'utilisateur technique de naviguer à l'intérieur du dépôt d’archives même en effectuant des «analyses d’impact» et des «lignages de données » (Data Lineage). L’analyse d’impact consiste à évaluer l’effet d’une modification (modification du programme conceptuel, modification d’un champ d’une table, etc.) sur le système décisionnel ; grâce à ce type d’analyse, il sera par exemple possible d’évaluer dans quelle mesure la modification ou l’ajout d’une colonne sur une table puisse avoir des conséquences sur les différentes composantes de l’entrepôt de données. Le lignage des données consiste à pouvoir identifier l’origine (système source) d’une donnée présente dans un rapport et toutes les transformations auxquelles la donnée même a été soumise. En ce qui concerne les métadonnées d’affaires, la possibilité pour l’utilisateur final de naviguer à l’intérieur des métadonnées mêmes, à travers le portail, dépend de deux facteurs étroitement liés :

• La modalité de gestion des métadonnées : dans le dépôt d’archives unique ou dans un dépôt d’archives approprié (cette possibilité dépend, même dans ce cas-ci, de l’outil qui sera utilisé pour gérer le dépôt d’archives) ;

• Le développement possible d’une application donnée afin de permettre la publication des métadonnées sur le portail (le prix de cette application dépend de l’outil qu’on envisage d’utiliser pour la gestion des métadonnées et des fonctionnalités qu’on envisage de développer. La définition de ce prix exige une analyse spécifique qui peut être effectuée seulement après le choix de l’outil).

Dans le tableau ci-dessous on indique les métadonnées qu’on propose d’intégrer à l’intérieur du dépôt d’archives.


25/09/2007

Version 1.0 Page 27



Métadonnées Description

Modèle conceptuel Le modèle conceptuel de l’information pertinente pour le domaine thématique. On confie à ce modèle la définition de la sémantique de l’information tirée

du système au niveau de granularité maximale.

Modèle Logique/Physique

EDW

Le modèle logique de l’EDW représente l’organisation logique des informations à l’intérieur

de l’EDW (technique d’historique, représentation des hiérarchies, etc.). Le modèle physique reproduit

fidèlement la structure relationnelle de la base de données correspondante.

Modèle de dérivation

conceptuel-logique

Le modèle C2L décrit le processus de dérivation des modèles logiques à partir du modèle conceptuel.

Modèle Logique/Physique

mini-entrepôt

Le modèle logique de l’entrepôt de données représente l’organisation logique des informations à l’intérieur de la base de données du mini-entrepôt (hiérarchies, table des faits, dénormalisation, etc.). Le modèle physique reproduit exactement la structure relationnelle de la base de données.

Couche sémantique mini-

entrepôt

La couche sémantique du mini-entrepôt décrit l’organisation logique et la sémantique des objets (caractéristiques dimensionnelles, non dimensionnelles et dimensions) qui réalisent, au niveau frontal, le modèle dimensionnel du mini-entrepôt.

Rapports Les rapports prédéfinis du mini-entrepôt représentent l’outil opérationnel à travers lequel la plupart des utilisateurs du système reçoivent des informations. Les rapports affichent le résultat du mélange d’un sous-ensemble des mesures et des caractéristiques dimensionnelles de la couche sémantique de l’entrepôt de données.

Programmes ETL Les programmes (application) de ETL de l’entrepôt de données contiennent l’ensemble des procédures d’alimentation des structures physiques des mini-entrepôts à partir des données sources

4.2.7 Le portail

Pour l’utilisation des informations de la part de tous les utilisateurs intéressés, il est nécessaire de disposer d’un point d’accès unique pour toutes les


25/09/2007

Version 1.0 Page 28



fonctionnalités, pas seulement d’utilisation de la donnée, mais aussi de certaines fonctions de configuration (par exemple, la gestion des autorisations d’accès). La solution consiste à intégrer les outils décisionnels et directionnels à l’intérieur d’un portail à travers lequel les utilisateurs finaux externes et internes pourront accéder aux fonctionnalités mises à leur disposition. Cet outil affichera des parties publiques où tout utilisateur pourra consulter les informations mises à la disposition et des parties réservées où il sera possible l’accès seulement suite à une authentification qui en déterminera l’interface pertinente en termes de fonctions et de contenus.

Le reporting prédéfini, les analyses multidimensionnelles, les tableaux de bord, nécessaires pour l’analyse des différents aspects concernant le domaine du personnel de l’État, seront utilisés à travers le portail. Les informations de l’entrepôt de données permettront l’élaboration de statistiques à caractère cognitif et prédictif, dont les résultats seront utilisés pour la production et la publication sur le portail des rapports adressés aux utilisateurs finaux ou à l’utilisation interne. Sur le portail, on publiera, également vers les utilisateurs finaux, les informations concernant le Personnel et on pourra mettre à la disposition des outils de communication et d’interaction (lettres d’information, forums, FAQ, centres d’appel, courrier électronique, etc.). La gestion, l’entretien et la mise à jour du système seront effectués à travers des outils appropriés de la part des utilisateurs autorisés eux aussi par le portail.

Le portail sera organisé dans les sections indiquées dans le tableau ci-dessous:

Section Description Rapport prédéfini

Cette section contient tous les documents publiés réalisés pour l’accès aux informations présentes dans le mini-entrepôt. L’utilisateur ne pourra accéder qu’aux rapports correspondants à son rôle. Les rapports pourront être organisés ou non en sous-menus.

Recherche Toutes les fonctionnalités sont présentes permettant à l’utilisateur de pouvoir accomplir des recherches sur la base de caractéristiques communes bien données.

Accès aux résultats des opérations analytiques

Elle contient les résultats des études menées en utilisant les fonctions analytiques. L’utilisateur ne pourra accéder qu’aux rapports correspondants à son rôle.

Analyses improvisées

Elle contient les fonctionnalités permettant à l’utilisateur final d’analyser les données de façon non prédéfinie.

Qualité Elle contient tous les documents (rapports contenant les méthodes de qualité) concernant


25/09/2007

Version 1.0 Page 29



Section Description l’affichage des niveaux de qualité des données présentes dans le mini-entrepôt.

Métadonnées Elle contient les référentiels communs (concepts, données et nomenclatures associées) organisés de façon à être consultés facilement à travers des fonctions de navigation et/ou de recherche de la part de l’utilisateur final.

Publication Elle contient les fonctionnalités pour la publication des documents et des métadonnées à l’intérieur du portail

Administration Elle contient la fonctionnalité pour l’administration des opérations définies pour les différents types d’affichage des documents et des métadonnées du portail

Support Elle contient tous les documents de support à l’utilisateur pour l’utilisation des informations présentes dans le mini-entrepôt

Nouvelles Toutes les nouvelles concernant les RH sont rapportées

FAQ Toutes les questions plus fréquemment posées sont indiquées

Forum Lieu d’échange d’informations Centre d’appel Références au centre d’appel, en matière de RH

4.2.8 Reporting prédéfini

Reporting prédéfini, il s’agit d’un ensemble de rapports préparés à l’avance à mettre à la disposition des utilisateurs finaux divisés en sujets portant sur le personnel afin de simplifier et de rendre plus rapide la recherche de l’information concernée. L'utilisateur bénéficiera de la possibilité de sélectionner le rapport d'intérêt et de l'afficher, à partir d'une liste de rapports déjà existants. Les utilisateurs ayant l'autorisation d’explorer les informations contenues dans le portail pourront mener des analyses de type OLAP (zoom avant, zoom arrière, analyse par permutation d'axes) grâce à l'accès à l'ensemble des données créé, suite à une interrogation, automatiquement à partir de la composante serveur du produit frontal du système. Ce type d'analyse multidimensionnelle permet à l’utilisateur de « naviguer » dans les informations sur lesquelles le rapport en question repose, analysant un phénomène donné de plusieurs points de vue et à plusieurs niveaux de détail. Les fonctions de type OLAP pourront être directement disponibles dans le navigateur Web sous forme de liens hypertextuels sur enregistrements, tableaux ou graphiques.

L’identification des informations d’intérêt est un processus d’importance cruciale surtout en présence d’un grand nombre de rapports disponibles. Dans ce cas, interviennent d’un côté, les différents types de fonctions de recherche à


25/09/2007

Version 1.0 Page 30



mettre à la disposition des utilisateurs et de l’autre coté, les informations enrichissant les données (métadonnées) sur lesquelles ces fonctions oeuvrent. Certains sujets fondamentaux que le système devra traiter, concernant les aspects administratifs, sont indiqués ci-après à titre d’exemple :

• La composition des effectifs ; • Les mouvements du personnel (mobilité interne, entrées/sorties, …) ; • Les charges de travail ; • Les actes de gestion (titularisations/promotion) ; • Les comportements du personnel (absences/présences, heures

supplémentaires) ; • Les coûts du personnel ; • Les abandons ; • Les accidents de service ; • …

De même, pour les aspects qualitatifs, on pourrait identifier les thèmes suivants :

• La formation ; • Les compétences ; • La carrière professionnelle ; • … Le reporting peut être divisé par sujet mais aussi par niveau de détail et aux différents niveaux de synthèse des informations. Les données peuvent, en effet, fournir une vue d’ensemble du personnel de l’État, et plus en détail, le profil général de chaque unité institutionnelle, le détail des unités organisatrices de premier niveau et ainsi de suite. Ci-après, on propose un schéma avec les principaux niveaux de reporting :

Niveaux de reporting But DestinatairesReporting directionnel de premier niveau

Il analyse au niveau général les phénomènes ayant l’impact le plus significatif sur la gestion du personnel de l’État et utiles à définir les stratégies et les politiques de gestion des ressources humaines de la fonction publique

Reporting directionnel de deuxième niveau

Il analyse au niveau de détail plus élevé les informations portant sur


25/09/2007

Version 1.0 Page 31



Niveaux de reporting But Destinataireschaque unité institutionnelle, il utilise les données agrégées des autres unités pour d'autres possibles étalonnages

Reporting directionnel de troisième niveau

Il analyse au niveau de détail les informations portant sur les unités organisatrices de sa propre unité institutionnelle

Reporting spécialisé Il analyse à plusieurs niveaux de détail les phénomènes spécifiques ressortissant aux unités institutionnelles/organisatrices

Reporting institutionnel C’est le reporting utilisé pour fournir des situations de synthèse du personnel de l’État, tant à l’intérieur qu’à l’extérieur

4.2.9 L’analyse OLAP

Compte tenu de l’importance et de l’organisation des données portant sur le personnel de l’État et de l’intervalle d’historique prévu, l’entrepôt de données exige un outil d’exploration improvisée des informations, à savoir un outil d’interrogation (recherche) et d’affichage (reporting) des données. Pour conduire l’utilisateur dans la composition des requêtes de données, les outils frontaux mettent à leur disposition une série de panneaux qui, pour les phases successives, permet de :

• Sélectionner le sujet d’analyse ; • Choisir le type de rapport selon lequel il est possible d’afficher le résultat de

la recherche (tableau, tabulation en croix, modèle personnalisé) ; • Formuler sa propre recherche ; • Donner un format définitif aux données du rapport (graphique, à domaines

calculés, sauts de pages, en-têtes, etc.).

Principaux champs d’application et d’analyse pouvant être contenus dans un système décisionnel Ressources Humaines :

• Gestion des temps (ex : absentéisme) ; • Gestion des effectifs (ex : effectifs affectés) ; • Productivité (en relation avec les données de production pour des études

par exemple : sur l’efficacité de certains programmes de formation …) ; • Gestion de la masse salariale (ex : étude des charges) ; • Aspects quantitatifs de la gestion de la formation (ex : budgets, effectifs

formés), etc. …


25/09/2007

Version 1.0 Page 32



Les champs les plus qualitatifs peuvent être couverts sous réserve d’une formalisation précise ainsi que de l’homogénéité des définitions (avoir les mêmes significations derrière les mêmes mots). Les axes d’analyse de ces différents champs pouvant être :

• Le temps (analyse rétrospective, simulations, prévisions) ; • La localisation géographique ; • Les fonctions, etc. … Différentes variables peuvent être utilisées comme axe d’analyse en fonction des besoins et des nécessités de chaque organisation. Il est possible ensuite de spécifier les critères de classement et de sélection des données à l’aide de conditions propres ou prédéfinies. Pour les critères de sélection, des opérateurs (>, <, =, between, in, and, or, etc.…..) et des listes de valeurs (telles que par exemple : liste des régions, liste des provinces) sont à la disposition. L’utilisateur se limite donc à sélectionner les objets qui l’intéressent à partir de différentes listes et, dans certains cas, à introduire à travers le clavier, les filtres nécessaires pour sélectionner les informations souhaitées. Cela permettra la formulation de la requête indépendamment de la connaissance de la syntaxe d'un langage d'interrogation de la base de données.

Lorsque l’utilisateur envoie la requête élaborée de façon descriptive, on active les fonctions d’accès à la base de données, visant à gérer les correspondances entre l’affichage du domaine que l’utilisateur possède, et qu’il utilise pour exprimer sa requête, et la structure logique de la base de données.

Les fonctions d’accès accomplissent les tâches principales suivantes :

• Traduction de la requête du niveau utilisateur au niveau nécessaire pour l’interaction avec les services chargés de l’accès à la base de données (en général, il s’agit de commandes SQL) ;

• Contrôle de la congruité des choix de l’utilisateur ; • Agrégation et synthèse des données. Une fois la requête formulée, il est possible de personnaliser le rapport sur lequel on affichera les résultats de la requête en introduisant les données calculées (sommes, pourcentages, fonctions statistiques et mathématiques en général), graphiques, textes, images. Si les caractéristiques des données le permettent, on pourra afficher les informations contenues dans le rapport de façon plus agrégée ou plus détaillée sans devoir modifier la requête de départ. Pour l’élaboration des champs calculés, un ensemble de fonctions statistiques et mathématiques seront disponibles, telles que:

• Moyenne ; • Variance ; • Déviation standard ; • Minimum ;


25/09/2007

Version 1.0 Page 33



• Maximum ; • Niveau ; • Somme ; • Pourcentage. Pour les graphiques, une grande quantité de formats est disponible, tels que :

• Graphiques sectoriels ; • Graphiques à barres (verticales, superposées ou regroupées) ; • Graphiques combinés barres/lignes ; • Graphiques à barres tridimensionnelles ; • Graphiques à couches tridimensionnelles ; • Graphiques de distribution X/Y (nuages de points). Il est possible de créer, sauvegarder, copier les documents considérés comme des ensembles de rapports. Il est également possible d’utiliser les fonctions d’imprimerie ainsi que d’exportation des données présentes dans les documents sous différents formats standard, tels que : Microsoft Excel, ASCII, PDF, etc.….. À partir du même outil de recherche, il possible d’activer la composante permettant l’analyse multidimensionnelle des données. L’utilisateur peut effectuer des analyses multidimensionnelles (« zoom total » et « analyse par permutation d’axes ») sur les données contenues dans le rapport qu’on vient de créer. Lorsqu’un utilisateur envoie une requête, le système chercheur utilise les métadonnées pour créer les commandes nécessaires pour localiser les données souhaitées. Une fois les données obtenues de la base de donnée, on crée automatiquement sur le serveur une structure multidimensionnelle, appelée microcube, grâce à laquelle l’utilisateur même peut mener d’autres analyses multidimensionnelles sans devoir soumettre d’autres requêtes à la base de données. De même, sur les rapports prédéfinis créés et distribués par un expert du domaine, tout utilisateur pourra mener des analyses multidimensionnelles en utilisant les cubes multidimensionnels associés aux rapports susmentionnés. Cela entraîne d’hautes performances pour l’utilisateur, sans que le système ne soit alourdi à cause de charges de travail provoquées par des requêtes complexes effectuées directement sur la base de données.

Les cubes atteints sont des structures multidimensionnelles de données qui œuvrent comme une mémoire cache dynamique et persistante. Du moment qu’ils sont dynamiques, ils peuvent être mis à jour ou redéfinis à tout moment.

Les fonctions principales d’analyse multidimensionnelle supportées par les microcubes sont les suivantes :


25/09/2007

Version 1.0 Page 34



Analyse par permutation d’axes : C’est-à-dire la possibilité de « fragmenter » ou de « tourner » une portion donnée de données agrégées tout au long de n’importe quelle dimension. Veuillez considérer, par exemple, l’absentéisme par région ou produit. Zoom total : C’est-à-dire la capacité de naviguer à travers des hiérarchies d’informations et passer directement à des niveaux de détail plus spécifiques ou d’atteindre une vue plus générale d’un ensemble de données, ou encore de se déplacer latéralement d'un ensemble de données à un autre se trouvant sur le même niveau.

Il est possible de parcourir la hiérarchie des données de référence (par exemple : territoriales, temporelles, etc.) en atteignant pour une donnée son détail ou vice-versa à partir de données de détail, il est possible d’atteindre des données de synthèse. Par exemple, à partir d’un rapport contenant les données régionales concernant la quantité de fonctionnaires par emploi-type, il sera possible d’atteindre, pour une région donnée, leur distribution au niveau provincial, et de procéder donc à l’analyse de l’évolution du phénomène au fil des années, en parcourant la hiérarchie définie par la dimension temporelle et ainsi de suite.

Il est enfin possible de changer la perspective des données du rapport, en transposant la position des variables positionnées en lignes et colonnes ou sur les axes d’un graphique. Par exemple, il est possible de passer de la distribution des fonctionnaires d’une région donnée par emploi-type à la distribution régionale des fonctionnaires pour un emploi-type déterminé de sorte à mener des comparaisons entre la situation de la région et celle des autres régions pour ce type-là d’emploi-type. Les deux types de procédés peuvent être utilisés plusieurs fois de suite afin d’analyser les données extraites. Une autre caractéristique fonctionnelle consiste en la possibilité, pour l’utilisateur, de dépasser le niveau de détail d'une requête associée à un rapport donné. Suite à l’exigence d’augmenter le niveau de détail d’un rapport dynamique prédéfini, l’outil frontal mènera automatiquement une recherche pour identifier, dans la base de données, les données servant au plus haut niveau de détail requis.

4.2.10 Les tableaux de bord décisionnels

Un tableau de bord contient surtout des indicateurs agrégés et des KPI (Indicateurs clé de performances) qui, représentés à l’aide de « tachymètres », feux ou indicateurs graphiques de ce genre, fournissent une vue d’ensemble immédiate de l’évolution totale des phénomènes en question.


25/09/2007

Version 1.0 Page 35



L’élaboration d’un tableau de bord permet d’avoir de façon rapide et efficace un aperçu de l'évolution du phénomène à l'aide de « coup d'œil » rapide. Cela n’exclut pas la possibilité, si nécessaire, de pouvoir accéder à des informations plus détaillées pour pouvoir mener des enquêtes sur le phénomène mis en évidence par la donnée de synthèse.

La solution, indépendamment de l’environnement frontal spécifique choisi, consiste à mettre à la disposition de l’utilisateur, un outil permettant de : • découvrir des tendances cachées pour prévoir l’évolution future. Le

but consiste à fournir aux décideurs les informations nécessaires pour accomplir des opérations proactives, plutôt que réactives, ayant pour but l'amélioration de leur efficacité et la prévention de problèmes possibles ;

• suivre les processus à l’aide d’avis et de graphiques de contrôle. Le but consiste à identifier les processus défaillants et à être avertis lorsqu’un processus se tourne vers la direction erronée.

Le tableau de bord devra prévoir une vue d’ensemble totale des sujets portant sur les Ressources humaines et il affichera la division en « fiches » (onglets) principales organisées selon le domaine d’analyse. À l’intérieur de chaque « fiche », si nécessaire, il y aura d’autres divisions en sous-fiches, où il faudra introduire les indicateurs en format graphique identifiés selon les exigences des différents domaines. Chacun des domaines thématiques pourra être caractérisé par une page principale, dont les buts seront de :

• fournir, de façon immédiate, des mesures de synthèse à même de résumer les KPI et les mesures d’affaires principales pour les utilisateurs directionnels,

• simplifier l’accès aux sections du tableau de bord, afin d’examiner un phénomène à un niveau plus élevé de détail, d’explorer les données en question et d’identifier les causes qui ont déterminé la valeur synthétique du KPI.


25/09/2007

Version 1.0 Page 36



Figure 3 –Tableaux de bord décisionnels

Plus précisément, les indicateurs de caractère juridique-administratif indispensables dans un tableau de bord du personnel sont les suivants :

• Pourcentage d’absentéisme ; • Taux d’occupation de poste de travail ; • Rotation, • … En ce qui concerne le développement des ressources humaines, les indicateurs intéressants peuvent être :

• Taux de présence dans les formations, • Coût de la formation par personne • Jours de formation par personne. Ces KPI doivent être consultables de façon rapide à travers des rapports synthétiques ou à travers la traduction de l’indicateur en utilités graphiques de grand impact. Certaines de ces représentations graphiques affichent la valeur du KPI sur une échelle de type tachymètre ou exprimée à l’aide d’un feu, après une catégorisation en seuils définie par l’utilisateur.


25/09/2007

Version 1.0 Page 37



Figure 4 – KPI

Dans le tableau de bord, il sera également possible de suivre des cas spécifiques (la vérification ou la disparition d’un élément donné) ou le dépassement de seuils donnés définis par l’utilisateur. L’événement devra être considéré comme un élément d’attention exigeant des approfondissements supplémentaires, affichables à travers des liens à des rapports illustrant les raisons de la production de l’avis ou déterminant automatiquement des tâches opérationnelles (par exemple, l’envoi d’un courrier électronique).

À partir de la page initiale, il sera toutefois possible de rappeler les autres applications de reporting ou les applications externes. À travers l’organisation en différents sous niveaux et tâches, on renverra aux fonctionnalités de reporting permettant l’affichage (et naturellement l’utilisation des fonctionnalités OLAP) de rapports prédéfinis organisés de façon hiérarchique. Des brèves descriptions seront également possibles, ainsi que certains liens à d’autres rapports, divisés par sections d’analyse selon le parcours prévu pour l'exploration du domaine thématique.

4.2.11 Les applications analytiques

Les applications analytiques sont des processus de type statistique, simulations, modèles prévisionnels qui appliquent aux données extraites de l’Infocentre, un ensemble d'algorithmes statistiques et mathématiques permettant de fournir des informations cognitives et prévisionnelles sur les phénomènes en question. Dans les applications analytiques, l’interaction utilisateur/système se produit, à travers une interface affichant à l’utilisateur, un ensemble de variables à mettre en valeur ; après les contrôles formels et de contenus, on entame le processus de simulation ou de prévision. Les fonctionnalités de l’application analytique peuvent être classées de la façon suivante :

• Réglage des paramètres de simulation ; • Mise en place des procédures avec une manipulation successive des

données.


25/09/2007

Version 1.0 Page 38



L’ensemble des paramètres définis pour une simulation et les résultats pertinents correspondent à un scénario; il est possible d’associer à un scénario, un numéro d’identification et une description synthétique permettant de l'identifier facilement lors des sessions successives de travail. L’utilisateur a généralement trois possibilités :

• Définir une simulation nouvelle ; • Utiliser une simulation précédemment enregistrée ; • Mettre à jour une simulation déjà menée. Le système assure la sauvegarde des données réglées sur chaque écran, sauf si on en demande explicitement l’annulation. En particulier :

• Si on veut définir une nouvelle simulation, il faudra introduire tous les paramètres nécessaires pour le modèle ;

• Si on veut rappeler un scénario déjà enregistré, il faudra sélectionner le numéro progressif qui l’identifie ou en rechercher la description. Une fois ce choix effectué, tous les domaines d’entrée seront automatiquement remplis par les valeurs correspondantes ;

• Si on veut mettre à jour une simulation déjà enregistrée, en la modifiant partiellement, il est possible de rappeler le scénario comme décrit ci-dessus et d'apporter les modifications sur les données en question.

Les résultats des modifications sont affichés sous forme de rapports contenant les données sous format tabulaire ou graphique. Ci-après, on illustre la description de certaines fonctions analytiques principales significatives dans le cadre des ressources du personnel. Analyse des effectifs - Les analyses de dimensionnement des effectifs permettent de :

• Tracer la tendance historique de consistance et les variations qui se sont vérifiées dans le personnel au cours d’une période (mois, semestre, année) ;

• Comparer l’évolution du personnel dans les différentes unités organisationnelles à l’intérieur de l’Organisation.

Il est possible de faire référence à l’assignation par structure organisationnelle ou par territoire. Le système effectuera l’histoire des assignations à travers la date de prise d’effet qui sera téléchargée par les systèmes d’alimentation. Les analyses sur le dimensionnement permettent de suivre les tendances évolutives des effectifs :

• Evolution des effectifs répartis par classement contractuel ; • Evolution des effectifs par âge, ancienneté de service ; • Evolution des effectifs au niveau territorial.

Le dimensionnement des structures permet d’analyser la distribution des fonctionnaires par hiérarchie organisationnelle, par hiérarchie de responsabilité


25/09/2007

Version 1.0 Page 39



ou par hiérarchie géographique avec un aperçu précis de la situation (photographie du moment) ou avec une profondeur historique. Analyses de la mobilité du personnel

Analyse de la rotation Par cette analyse, il est possible de mettre en évidence les facteurs significatifs qui ont influencé le choix de départ, en affichant la fréquence et les raisons de des sorties. Les raisons de l’événement «démissions» sont les dimensions d’enquête : l’analyse affichera donc la quantité de fonctionnaires pour chaque raison des sorties pour les différentes dimensions d'analyse. Analyse de la mobilité interne L’analyse de la mobilité interne enregistre les déplacements des fonctionnaires pour les différents niveaux hiérarchiques organisationnels. Cette analyse considère, comme point de départ, les déplacements ayant une valeur de gestion (par exemple, les déplacements temporaires ne seront pas pris en considération, mais pourront être traités comme des événements de détail sur le fonctionnaire). Analyse des positions de travail L’analyse Time in position ou des positions de travail a pour but d'analyser le temps moyen de permanence des salariés sur une position ou tâche donnée. Les données de cette analyse mettent en évidence les facteurs significatifs qui ont influencé la permanence dans des classements donnés. Cette recherche est utilisée pour mener des analyses de remplacements ou pour identifier les déroulements de carrière des fonctionnaires, aussi bien pour des raisons contractuelles que pour des raisons méritocratiques. Le résultat de cette analyse est représenté par un tableau bidimensionnel permettant d’examiner plusieurs variables en même temps. Simulation de rémunération L’analyse de révision de la rémunération permet d’évaluer l’impact financier concernant l’augmentation de rémunération tant de la composante fixe que de la partie variable. Cette analyse permet, en temps réel, de bénéficier d’une visualisation des coûts, par unité organisationnelle, par profil professionnel et par classement, par région géographique. Analyses organisationnelles Les analyses organisationnelles permettent d’évaluer de façon rapide et efficace l’évolution de la structure d’une organisation suite à des réorganisations et des simplifications qui se sont produites. Ce type d’analyse se produit à travers la représentation de l’organigramme possédant un langage d’interrogation simple, général et hautement flexible et


25/09/2007

Version 1.0 Page 40



permettant de produire une vaste gamme de représentations organisationnelles.

4.3 ARCHITECTURES TECHNOLOGIQUES L’analyse de la solution architecturale aborde essentiellement deux aspects, où le premier représente une contrainte pour le deuxième :

• Identification des produits logiciels nécessaires pour créer et mettre en place le système décisionnel pour le personnel de l’État ;

• Sélection successive et dimensionnement des structures matériel nécessaires pour soutenir le choix logiciel précédemment identifié.

Pour le choix des solutions, il est nécessaire de tenir compte des facteurs suivants :

• conditions requises fonctionnelles et techniques ; • fonctionnalités offertes par les produits ; • consistance de la solution en termes de caractère exhaustif des

fonctionnalités ; • coûts de la solution ; • ratio coûts/bénéfices ; • niveau de scalabilité et intégrabilité de la solution. Afin de pouvoir effectuer un choix objectif des produits logiciels, il est opportun de synthétiser l’état actuel de la technologie portant sur les systèmes d’informatique décisionnelle. On peut classer les produits en trois grandes catégories :

• Intégration des données – elle comprend les outils ETL, la qualité de la donnée, la gestion des métadonnées, …

• Livraison des informations – elle comprend les outils de reporting, les outils de demande des données improvisée (interrogation ad hoc) et les tableaux de bord ;

• Analyse des données – elle comprend les outils pour l'extraction des données, les simulations, les modèles prédictifs, l’analyse multidimensionnelle (OLAP) et les tableaux de bord prospectifs.

4.3.1 Vue d’ensemble des outils d’intégration des données

a) ETL

Le marché des outils de ETL (Extraction, Transformation et Chargement) est en train de s'évoluer remarquablement vers un scénario différent et innovant par rapport au cadre de référence traditionnel.


25/09/2007

Version 1.0 Page 41



MINI- ENTREPOT DE DONNÉES

ENTREPOT DE DONNÉES

SOURCE DE DONNÉES

ETL

ETL

ETL

ZONE D’ ENTREPOSAGETEMPORAIRE

Figure 5 - ETL

Ces outils ne sont plus limités au cadre traditionnel de l’entrepôt de données, mais ils sont en train de se proposer comme des outils d’interrogation de données dans le sens le plus général du terme. De ce point de vue, on affiche le développement de nouvelles capacités d’extraction des données presque en temps réel et de façon événementielle, ainsi que la possibilité d’accéder en temps réel, et de façon transparente, à des bases de données hétérogènes (EII, intégration de données d’entreprise). Ces fonctions sont également développées dans un esprit tourné vers les services (SOA) ; par conséquent, la plateforme ETL joue le rôle de fournisseur et utilisateur de services dans une architecture d'entreprise complexe, où l'entrepôt de données et l’informatique décisionnelle sont considérés comme des composantes actives dans les processus d’entreprise. D’autres aspects spécifiques pour lesquels on affiche une évolution des outils ETL sont les suivants :

• Amélioration de la productivité et simplicité d’utilisation accrue lors des phases de développement et de déploiement ;

• Elargissement de la portée de données source et cible utilisables ;


25/09/2007

Version 1.0 Page 42



• Amélioration des fonctions de qualité de la donnée (profilage, appariement, standardisation, nettoyage des données, etc.) ;

• Amélioration des fonctions de gestion des métadonnées (analyse de l’impact, intégration avec d’autres outils).

La tendance en cours consiste, en très peu de mots, à considérer le ETL comme une composante intégrée dans une plateforme plus vaste :

• Des entreprises traditionnellement présentes sur le marché des bases de données exploitent les potentiels du « moteur » DBMS (SGBD, système de gestion de base de données) pour réaliser les fonctions ETL intégrées : c’est le cas de Oracle avec l’évolution de la composante Warehouse Builder et de Microsoft SQL 2005, qui a évolué les Services de transformation de données précédents en Services d’intégration du serveur SQL ; un cas différent est représenté par IBM qui n’a pas développé la solution précédente basée sur DB2 (Gestion de l’entrepôt), mais il a acquis la plateforme ETL Ascential ;

• D’autres entreprises, présentes sur le marché de l’informatique décisionnelle, ont développé ou intégré des composantes ETL dans leur propre offre ; c’est le cas, par exemple, de SAS qui a développé ex novo la composante ETL Intégration de données sur sa propre plateforme (comprenant des fonctions de qualité des données de Datadlux) ou de BusinessObjects qui, au contraire, est en train d’enrichir son offre à travers l'acquisition d'outils spécifiques (Intégrateur de données pour les fonctions ETL, Firstlogic pour la gestion de la qualité).

Au cours de l’an 2006, Oracle a concentré son attention sur l’amélioration de sa propre plateforme d’entreposage des données. Il a accompli plusieurs acquisitions stratégiques, telles que Siebel Business Analytics en ce qui concerne la BI et Sunopsis en tant que composante ETL. Cette dernière opération visait, en particulier, à renforcer l’offre Oracle Fusion Middleware, dans laquelle la technologie Sunopsis devrait s’intégrer. Oracle souligne la complémentarité entre les solutions Sunopsis et les siennes, notamment entre l'offre Sunopsis et les fonctions ETL (Extraction, Transformation et Chargement) et de contrôle de la qualité des données intégrées en Oracle Warehouse Builder. La complémentarité est liée au fait que les technologies Sunopsis permettent le chargement à partir de et vers des systèmes cible hétérogènes, y compris les plateformes IBM DB2, Teradata e MS SQL Server. Tout cela permet d’envisager un changement significatif de l’offre Oracle qui jusqu’à présent s'est concentrée surtout sur les fonctionnalités de son propre RDBMS (SGBDR :Système de gestion de base de données relationnel). La figure ci-dessous illustre le cadran magique Gartner Group concernant les outils ETL :


25/09/2007

Version 1.0 Page 43



Figure 6 - Magic Quadrant for data Integration Tools, 2006

Comme l’on peut remarquer à partir de ce dernier « cadran magique », les produits leader de marché sont Informatica et IBM, mais aussi BO et Pervasive Software sont bien placés. Data Trasformation Services de Microsoft est en train de remonter des positions, même s’elle n’appartient pas encore aux outils définis « leader ».

b) Cadre général des produits de Qualité des données

Ces dernières années, les outils sur la qualité des données ont revêtu de plus en plus d’importance. Même pour les solutions de DW, il est fondamental que l’extraction de l’information commence à partir de « données nettoyées », c’est la seule façon de réaliser un EDW qui puisse être la « source de la vérité de l’entreprise ». Pour ce qui est de la qualité, le marché offre des produits affichant toute une série de caractéristiques ; ces outils sont évalués pour les fonctions suivantes:


25/09/2007

Version 1.0 Page 44



• Profilage des données ;

• Appariement des données ;

• Nettoyage et enrichissement des données. On évalue positivement les produits affichant toutes ces caractéristiques et qui, en même temps, sont ouverts et intégrables à l’aide de produits d’autres fournisseurs. Ci-après, on illustre le cadran magique de Gartner en matière d'outils de qualité :

Figure 7 - Magic Quadrant for Data Quality Tools, 2007

Les leaders du marché sont « Business Objects » et « Trillium Software ».


25/09/2007

Version 1.0 Page 45



4.3.2 Vue d’ensemble des outils de livraison des informations

Même l’offre du marché des produits de livraison des informations est en train de s’évoluer rapidement, en offrant des fonctionnalités de plus en plus avancées. Ainsi, l’évolution du marché de l’informatique décisionnelle propose un nouveau classement des produits :

• Plateformes BI (reporting analytique), envisageant des environnements de développement des applications cognitives. Elles affichent l’avantage d’une très haute fonctionnalité analytique et d'un environnement très ouvert aux personnalisations; en termes de désavantages, au contraire, elles semblent des produits complexes, difficiles à apprendre et affichant des difficultés pour la publication des résultats. En général, elles sont représentées par des produits de basse gamme, visant remarquablement à satisfaire les exigences spécifiques de l’industrie informatique. Elles sont généralement liées à un nombre très réduit d’utilisateurs et elles sont peu modulables.

• Plateformes EBS (Suites d’informatique décisionnelle d’entreprise), envisageant des outils très riches en fonctionnalités et de compréhension facile pour l’utilisateur final. L’avantage de ces outils consiste à être déjà équipés en plusieurs fonctionnalités prévues, à pouvoir publier facilement les résultats d'exploitation atteints, à être très « amicaux » avec l’utilisateur final et à être facilement modulables en termes de logiciels et matériels. On englobe généralement dans cette catégorie des produits de gamme moyenne-haute. Elle est fondamentalement liée à un nombre important d’utilisateurs et elle est modulable.

Dans ce contexte, nous allons analyser les plateformes EBIS et en ce qui concerne le positionnement des fournisseurs sur le marché, la dernière analyse de Gartner (voir figure ci-dessous) met en relief la primauté de Business Objects (BOI XI v.2), suivie par Cognos, Hyperion, Oracle et SAS. Placés à des rangs plus bas, nous trouvons Microsoft qui, comme caractéristique principale, offre l'intégration complète avec le monde Microsoft Office. Oracle, comme caractéristique principale, à partir de la version 10.1.2 fournit une application de BI de type "Java-centric", en reposant sur la plateforme Oracle 10g tant pour le RDBMS que pour le serveur d'application.


25/09/2007

Version 1.0 Page 46



Cette évaluation est mise en évidence par le « cadran magique » Gartner suivant:

Figure 8 - Magic Quadrant for Business Intelligence Platforms, 2007

Il faut mettre en relief que la version « XT » de Business Objects est leader de marché en matière de livraison des informations. En effet, en englobant dans le cadre de XI même les potentiels de l’outil Cristal Decision (acquis par BO en 2006), elle couvre tous les aspects d’analyse et de reporting et pour cela elle est définie comme une solution de type « meilleur produit ».


25/09/2007

Version 1.0 Page 47



4.3.3 Vue d’ensemble des outils d’analyse

Le marché des outils pour l’extraction des données, les simulations, les modèles prédictifs et les tableaux de bord prospectifs n’a pas un seul leader. En ce qui concerne l’extraction de données et les modèles prédictifs, nous remarquons la primauté absolue de SAS, tandis qu’en matière de capacités d’analyse multidimensionnelle et de mise en place des tableaux de bord prospectifs, Oracle (qui vient d’acquérir Hyperion) et Microsoft sont considérés très positivement par Gartner, suivis immédiatement par Business Objects et Cognos.

Figure 9 - BI Platform Capabilities: Analysis

4.3.4 Matériel

Pour le choix et le dimensionnement de l’infrastructure matériel, il faudra considérer les caractéristiques ci-après :

• Capacité d’élaboration, en mesure de satisfaire tant la charge du système dorsal de traitement que celui frontal ;

• Difficulté majeure de configuration, pour accueillir toutes les composantes nécessaires pour mettre en place l’Infocentre ;


25/09/2007

Version 1.0 Page 48



• Capacité d’assurer de hauts niveaux de disponibilité et de continuité des activités (Business Continuity);

• Modularité en matière de données et de cycles de réalisation ; • Disponibilité des environnements d’exploitation, d’essai et de test. Nous identifierons trois typologies de machines :

• Serveur Web, réparties en DMZ (zones démilitarisées) et dédiées à donner suite à l'interrogation http de la composante frontale ;

• Serveur d’application, réparties en zones protégées et dédiées à donner suite séparément aux opérations dorsales et aux enquêtes de BI frontales ;

• Serveur DB, réparties en zones protégées qui seront le dépôt des données de l’entrepôt des données et seront spécialisées pour les élaborations que les systèmes dorsaux et frontaux soumettront au RDBMS.

Serveurs WEBServeurs WEB

Figure 10 - Architecture du système


25/09/2007

Version 1.0 Page 49



4.3.5 Infrastructure d’exploitation

Afin d’assurer un très haut niveau de fiabilité et l’équilibrage de charge (Load Balancing), nous envisageons trois types de solution, la première de type «Entreprise » garantissant la fiabilité par des mécanismes de «basculement» Actif-Passif, composée de la façon suivante :

• Deux composantes Web ; • Deux composantes Serveur d’application ; • Deux composantes Serveur DB. Dans la configuration présentée, tandis qu’une machine œuvre l’autre reste en attente et elle est activée à l’aide du logiciel de groupage seulement dans le cas où la première machine ne serait plus disponible (en panne). Cette politique est adoptée tant pour la composante Serveur d’application que pour celle Serveur DB. Ce type de configuration, tout en permettant des niveaux de disponibilité continus (en cas de passage d’une machine à l’autre, on ne dispose pas du service pour quelques minutes), pourrait afficher l’avantage de pouvoir épargner sur le coût des licences car elle permet de payer seulement les licences des produits de la machine active. Dans la figure ci-dessous, on illustre un exemple de la configuration susmentionnée :

Solution 1


25/09/2007

Version 1.0 Page 50



Figure 11 - Infrastructure matérielle logique d’exploitation – solution 1


25/09/2007

Version 1.0 Page 51



Une autre solution possible est la suivante :

• Deux composantes Web ; • Composante serveur d’application ; • Composante Serveur DB. Dans ce cas, on utilise seulement deux Serveurs d’application et la haute fiabilité, toujours de type Actif-Passif, est assurée par des mécanismes de groupage croisé comme décrit dans la figure ci-dessous :

Solution 2


La troisième et dernière solution proposée est la suivante : • deux composantes Web; • composante serveur d’application; • deux composantes Serveur DB. Même dans ce cas, la haute fiabilité est assurée par des mécanismes de « groupage » où une machine est active et l’autre passive comme on peut le remarquer dans la figure ci-après :


25/09/2007

Version 1.0 Page 52



Solution 3


Pour ce qui est de la composante Serveur DB, on envisage quand même deux machines, l’une active et l’autre passive ; dans ce cas, on prévoit une haute fiabilité de type vertical assurée par un logiciel de groupage traditionnel (en effet, la modularité horizontale pour le RDBMS exige la mise en place de mécanismes de fichiers groupés et , éventuellement, des composantes, parfois payant (es. Oracle RAC). La modularité de la composante Serveur d’application est assurée « horizontalement ». Pour toutes les solutions illustrées, on prévoit d'équilibrer la charge HTTP par l'utilisation d’un « Directeur local » distribuant les requêtes aux deux Serveur Web, placés en DMZ.


25/09/2007

Version 1.0 Page 53



En général, la capacité d’élaboration, la modularité de la solution et les niveaux de haute fiabilité découlent de façon significative de la quantité de machines et d'unités centrales dont on peut disposer. De toute façon, le choix des solutions techniques doit tenir compte des fortes contraintes économiques imposées par la « concession » à unités centrales des distributeurs des produits logiciels.

4.3.6 Infrastructure d’essai/test

La mise en place de l’infrastructure d'essai et de test suppose l’utilisation de toutes les composantes, des deux zones frontale et dorsale, et de RDBMS, présents dans l’infrastructure d’exploitation. Par contre, le dimensionnement de ces systèmes peut être différent.

4.4 STRUCTURE DE GESTION DE L’ENTREPOT DE DONNEES À cause de la complexité du contexte (richesse de sources de données, richesse d’environnements et différents types d’utilisateurs) et du choix méthodologique d’une approche évolutive incrémentielle, la mise en place de l’entrepôt de données ne peut pas être ramenée à un seul projet.

Le choix de procéder de façon incrémentielle exige que, une fois le cadre d’orientation identifié, toute initiative de développement et de démarrage, soit conforme et cohérente avec le cadre de référence prédéfini, pour une croissance graduelle et organisée du patrimoine décisionnel. Cela entraîne une approche différente au développement et à la gestion de l’entrepôt de données par rapport aux systèmes de gestion. Il nous faut de nouvelles et différentes attributions de responsabilité et des programmes de formation et d’entraînement pour le personnel concerné.

Afin de gérer le développement, l’entretien et l’évolution du système proposé et d’assurer la cohérence et le succès de l’initiative en question, il serait opportun de créer un Comité de Coordination et de Contrôle des contenus, des fonctions et des technologies utilisées. Ce Comité devrait être composé par un ensemble d’acteurs venant de différents environnements. La figure ci-dessous décrit la proposition d’organisation qui devrait être adoptée afin de gouverner l’entretien et l’évolution de l’entrepôt de données.


25/09/2007

Version 1.0 Page 54



Responsablede l’évolution de l’Infocentre

Responsablede la Coordination

Responsabledes Contenus

Responsable de la Privacy et de la Sécurité

Responsable duDéveloppementet de la

Gestion d’application

ResponsableduPatrimoineInformatif

Responsablede la Gestion Technique

Expert duDomaine Fonctionnel

Expertde Technologies

Gouvernement

Gestion

Expert duDomaine des Données

ResponsabledesStandard et de la Qualité

Support technologique Contrôle











Gouvernement

Gestion











Responsable de la Gestion Technique



Gouvernement

Gestion














Gouvernement

Gestion














Gouvernement

Gestion














Gouvernement

Gestion














Gouvernement

Gestion














Gouvernement

Gestion














Gouvernement

Gestion




Figure 14 - Structure de gestion de l’entrepôt de données

Ci-après, les rôles et les responsabilités des différents acteurs et les structures d’exploitation, prévues ad hoc, pour tout aspect à considérer :

• Un Responsable de la Coordination à l’intérieur de l’entrepôt de données aidé par d’autres conseillers, chacun avec des responsabilités bien données relativement aux questions suivantes :

analyse des exigences cognitives et identification des domaines d’évolution du système (Responsable des évolutions de l’Infocentre) ;

assignation des rôles, des utilisations et des modalités d’utilisation du système (Responsable de la confidentialité et de la sécurité) ;

certification de l’information fournie (Responsable des contenus : données et métadonnées) ;

respect de l’intégrité, de la cohérence et des niveaux de qualité du développement pour tout l’entrepôt de données (Responsable des standards et de la qualité) ;

• Un Responsable du patrimoine informatif aidé, pour chacune des sources de données, par un expert du domaine de données ;

• Un Responsable du développement et de la gestion d’application de l’Infocentre auquel feront référence les membres de l’équipe experts en un domaine fonctionnel spécifique ;

• Un Responsable de la gestion technique chargé des performances du système en termes d'architecture et d'évolution technologique (matériel et


25/09/2007

Version 1.0 Page 55



logiciel) supporté par des experts en technologies dans le cadre de l’informatique décisionnelle.

La nature complexe de l’entrepôt de données considérée, les opérateurs assignés aux structures de « gestion » sont, en général, accompagnés par des experts du secteur selon des contrats de fourniture bien donnés.


25/09/2007

Version 1.0 Page 56

___________________________________________________________________________________ Services


5. SERVICES

5.1 FORMATION La formation aux utilisateurs vise à créer une connaissance approfondie des fonctionnalités et des potentiels du nouveau système et des produits qui seront mis à la disposition. Le service de formation sera fourni :

• Aux utilisateurs «qui consultent», en tout ce qui concerne les fonctionnalités de production de reporting à travers l’outil prévu;

• Aux utilisateurs «gérants complètement l’outil frontal choisi», en tout ce qui concerne les fonctionnalités de production de reporting et d’administration (par exemple la création des rôles d’utilisateurs avec les droits d’accès pertinents);

• Aux «administrateurs de l’infrastructure», en ce qui concerne les aspects architecturaux.

L’outil proposé pour former les utilisateurs qui consultent, considérant leur distribution sur le territoire, est l’apprentissage en ligne à utiliser en ligne sur le Web. Pour les utilisateurs gérants et administrateurs de l’infrastructure, s’agissant d’utilisateurs « centraux » on suggère les traditionnels cours en classe.

5.2 ASSISTANCE Il faut prévoir un service orienté à l’exploitation des applications et à l’assistance des utilisateurs, pour tous les aspects concernant :

• Produits/services ; • Système frontal ; • Système dorsal. En particulier, il faut prévoir un service d’assistance pour les aspects d’utilisation des outils frontaux et notamment :

• Assistance à la réalisation du reporting ; • Assistance technique/fonctionnelle aux utilisateurs pendant la période

initiale d’exploitation des applications ; • Assistance opérationnelle à travers le service des centres d’appels aux

utilisateurs, pour l’utilisation appropriée des fonctions selon les modalités prévues dans les manuels d’utilisation ;

• Assistance aux utilisateurs sur des sujets fonctionnels/administratifs pour la résolution de problèmes d’interprétation des données, en faisant recours, si nécessaire, aux concepteurs du système ou aux experts du sujet ;

• Support spécialisé sur les produits frontaux.


25/09/2007

Version 1.0 Page 57

___________________________________________________________________________________ Indications pour la gestion du projet


6. INDICATIONS POUR LA GESTION DU PROJET

6.1 ANALYSE DU RISQUE Le risque total d’un projet est déterminé par la composition et l’interaction de plusieurs facteurs de risque, indépendants ou reliés entre eux, chacun desquels affiche sa propre probabilité de se vérifier et un impact sur le résultat final. L’approche méthodologique, illustrée ci-après, est orientée vers la description des risques du projet et vers la définition des mesures visant à minimiser les risques mêmes et elle est charpentée selon les points suivants :

• Identification des facteurs de risque du projet ; • Analyse du risque du projet ; • Définition des modalités de gestion du risque. Les facteurs de risques du projet principaux, que nous pouvons ramener surtout au contexte d’application, peuvent être classés en deux typologies, la première liée à des aspects de difficulté, la deuxième à des éléments d’incertitude et ils peuvent suivre le classement suivant :

• Facteurs de risque imputables à la difficulté : importance stratégique du projet ; difficulté du projet proposé ; facteurs de risque imputables à l’organisation ; délais dans la définition des accords institutionnels parmi les différentes parties concernées ;

• Facteurs de risque imputables à l’incertitude : incertitude des conditions requises ; innovation technologique ; facteurs de risque liés à l’utilisation du système ; facteurs de risque dus à l’évolution législative ; facteurs de risque liés à la qualité de la donnée en entrée dans l’entrepôt de données ;

facteurs de risque liés au processus de validation des données. Lors de la phase d’analyse du risque, on élabore un tableau de récapitulation des facteurs de risque et on associe, à chaque facteur, une évaluation qualitative (haute, moyenne et basse). La récapitulation sert à mettre en évidence le point où le risque se concentre et donc le point où il faut concentrer l’attention afin de mettre en place les contre-mesures adéquates.


25/09/2007

Version 1.0 Page 58

___________________________________________________________________________________ Indications pour la gestion du projet


6.2 FIGURES PROFESSIONNELLES REQUISES Les figures professionnelles participant au projet de développement d’un système décisionnel sont : Responsable du projet : assurant la réalisation des actions de contrôle du projet. Chef d’équipe : responsable de chaque groupe de développement. Il assure l’analyse des processus/conditions requises ainsi que du modèle des données. Il fournit au groupe de travail les connaissances spécifiques concernant l’environnement donné choisi pour la solution structurelle. Il intervient sur demande surtout lors de la phase de conception architecturale et de la phase de démarrage du projet. Analyste des affaires : il analyse le contexte d’application d’intérêt et il produit les informations nécessaires pour la définition du modèle de données et de fonctions (classer et caractériser les contenus). Il est chargé du rapport avec le client et il collecte les informations nécessaires pour traduire les exigences du client en modèles d’analyse et fonctions complets, tournés vers l’application des méthodes d’analyse et de modélisation. Il analyse les aspects spécifiques du contexte d’affaires. Il propose des solutions ITC sur la base des conditions requises indiquées par le client. Analyste-programmeur : il analyse le contexte d’application d’intérêt et définit le modèle de données et de fonctions (ERA, Dimensional Fact Model). Il collecte les informations nécessaires pour traduire les exigences du client en modèles d'analyse et fonctions complets, tournés vers l’application des méthodes d’analyse et de modélisation. Expert produit : il produits des logiciels à très haute complexité à partir des documents de conception, en utilisant des produits ou des outils spécifiques. Il accomplit le contrôle, la réalisation et l’essai des procédures informatiques (ETL, reporting, métadonnées, etc.).

Documents

ROYAUME DU MAROC - unpan1.un.orgunpan1.un.org/intradoc/groups/public/documents/UN-DPADM/UNPAN... · 4.2.2 Entrepôt de données d’entreprise ... 4.4 STRUCTURE DE GESTION DE L’ENTREPOT