1 INFOCENTRE BI / BW

BW (Business Information Warehouse) désormais appelé BI (Business Intelligence) est à la

fois l’entrepôt de données et l’outil de Reporting Décisionnel de SAP. Il est nativement
intégré aux autres composantes de SAP.

Il s’agit donc bien d’une solution Infocentre progicielle, intégrée à l’ensemble des autres
composants (SAP HCM pour le transactionnel fonctionnel, SAP Netweaver pour
l’infrastructure et SAP Portal pour la publication d’états sur le portail.

BW extrait, transforme, stocke et restitue les données de systèmes opérationnels externes. ·

BW permet de fournir un reporting agrégé multi-axes sur des quantités très importantes de
données hétérogènes. · Les données sont envoyées depuis les systèmes sources vers BW
via des extracteurs standards, éventuellement complétés par des extracteurs spécifiques.

Schématiquement, on peut représenter ainsi la solution BW :

1.1.1 Principe d’architechture de BW

1.1.2 Principe de fonctionnement de SAP BI

Les données sont chargées successivement dans différents conteneurs BW : infoObjets

pour les données de base (comptes de contrat, partenaires, etc.), ODS et cubes pour les
données transactionnelles (paiements, échéanciers, etc.).

Au cours de ces chargements, les données peuvent subir différentes transformations.

Analyse :
• L’analyse des données s’effectue en réalisant des états/requêtes, basés sur les cubes et
éventuellement les ODS.
• Différentes requêtes restituent l’information. Ces requêtes permettent de mettre en forme
l’information et d’offrir la possibilité de naviguer dans les données selon différents axes
d’analyse.
• Ces reports sont réalisés dans un premier temps avec l’outil Query Designer, puis dans un
second temps avec l’outil Web Query Designer. L’objectif de ce projet est de rendre ces
reports disponibles pour une interface Web.

Alimentation de l’infocentre

L’alimentation de l’infocentre est réalisée uniquement depuis l’instance ECC par l’interface
standard SAPI (service API).

L’extraction en standard des données SAP ECC par SAP BI est basée sur le principe de
Business Content :
• un ensemble de plus de 5000 objets standards pré-paramétrés dans le système SAP BI,
définissant un « contenu standard ».
• un ensemble d’extracteurs standards dans le système SAP ECC, correspondant au
contenu standard BW. L’existence de ces extracteurs est tributaire de l’installation, sur le
système ECC, du Plug-in adapté. L’installation du Plug-in BW sur le système ECC est un
pré-requis d’un projet décisionnel BI SAP. Il est fourni par l’administration comme un
module SAP.

Chargement des données

Toutes les données extraites de SAP ECC 6.0 sont chargées selon le schéma suivant :

Les chargements sont programmés par un processus spécifique à BI de lancement de

BATCHS appelé INFOPACKAGE. Celui-ci détermine les sources et destinations des
données, les règles de filtrage éventuelles, et intervient dans la transformation des données.

Les INFOPACKAGES sont organisés en chaînes de traitement garantissant l’intégrité

fonctionnelle du chargement (en chargeant par exemple les données de base essentielles
avant les attributs qui les caractérisent).

Ces chargements se font une première fois en mode FULL pour alimenter l’instance BI au
départ, puis par incrément (mode incrémental) dont le rythme peut être quotidien ou
hebdomadaire.

Ce processus de chargement est standard et respecte totalement les règles d’intégrité.

La PSA est une structure intermédiaire d’indexation des données du point de vue de BI. La
PSA alimente les ODS.

1.1.2.1Données transactionnelles et données de base

Ce sont les deux types de données que BW extrait des systèmes opérationnels. Les
données transactionnelles représentent l’ensemble des mouvements réalisés dans le
système opérationnel (paie, mesures administratives,…). Elles sont complexes dans la
mesure où elles sont constituées de plusieurs informations (nature de la donnée, date, entité
rattachée…) tandis que les données de base sont unitaires (Nom de l’employé, numéro de
rue…). Les données de base peuvent être de trois types : attributs (autres info-objets), textes
et hiérarchies.

1.1.2.2 Règles de transfert et de mise à jour

L’extraction des données transactionnelles ou de bases depuis les systèmes opérationnels

vers les objets de stockage est régit selon des règles dites de transfert et de mise à jour. Ces
règles identifient les données à extraire ainsi que leur destination dans leur lieu de stockage.
Elles déterminent quel(s) traitement(s) éventuel(s) ces données vont subir avant d’être
stockées dans l’entrepôt de données. Par exemple, une règle de transfert consistera à
récupérer dans SAP toutes les dates de demandes de mutation mais à n’en retenir que le
mois et l’année avant stockage dans l’entrepôt.

En résumé, elles gèrent l’alimentation en données des objets de stockage constituant

l’entrepôt de données. L’entrepôt de données permet de stocker des informations de sources
hétérogènes pour obtenir par la suite des analyses croisées adéquates. Les requêtes
lancées depuis le Sap Bex, viennent « piocher » des données dans cet entrepôt avant
d’afficher le résultat sous forme de tableur dans Excel ou sous forme Web dans le portail.

Note : Par entrepôt de données, on entend généralement l’ensemble des objets de stockage
(Info-Objet, ODS et Cube)

1.1.2.3 Rafraîchissement des données

Selon la périodicité de changement des données, le rafraîchissement est quotidien,

hebdomadaire ou mensuel. Les données de base, qui ont une périodicité de changement
importante, sont rafraîchies une fois par semaine ou une fois par mois. A l’inverse, les
données transactionnelles sont en constante évolution, ceci étant le résultat des actions des
utilisateurs et des nuits applicatives successives. Elles sont donc rafraîchies chaque nuit.
Pour quelques exceptions (taxe municipales, départementales, produit constatés
d’avance…) le rafraîchissement est mensuel. Au cours de ce passage, les données
subissent éventuellement un traitement particulier en fonction des informations que l’on
souhaite visualiser dans chaque report.

Les données des cubes sont mises à jour en batch et non pas en continu (au fil de l’eau),
c’est-à dire qu’une donnée enregistrée dans les systèmes opérationnels n’impacte pas
immédiatement le résultat des requêtes. Une fréquence de rafraîchissement est donc définie
pour chaque cube.

1.1.2.4Objets techniques utilisés

Afin de mieux appréhender le fonctionnement de la solution et en préparation de la

Conception Générale, nous avons listé les principaux objets contenus dans BW
Le schéma en étoile :

Le schéma en étoile correspond à la vision éclatée d’un cube BW. Celui-ci reprend
l’ensemble des caractéristiques disponibles pour la navigation dans un état et l’ensemble
des ratios associés. Le schéma en étoile permet de voir tous les axes disponibles pour le
reporting. Ces axes sont rangés par dimension (domaine), les mêmes que nous retrouvons
dans les cubes. Au centre du schéma en étoile schéma sont listés les ratios disponibles.

L’infoCube :

L’infocube est le modèle de base de stockage d’informations dans BW. C’est une base
multidimensionnelle : elle permet une analyse agrégée et rapide des données. L’infoCube
est représenté par son schéma en étoile (cf. ci-dessus).

Les données sont stockées de manière agrégées dans le cube, selon les caractéristiques
disponibles. Par exemple, en reprenant le cube précédent, sur les 6 lignes ci-dessous
arrivant depuis le système source dans le cube, 3 lignes seront stockées.

Le Multicube / Multiprovider :

Un multicube ou multiprovider est une vision consolidée de plusieurs cubes. Il permet de

joindre des données hétérogènes pour des analyses croisées. Il ne stocke physiquement
pas de données. Un multicube permet de faire du reporting sur des données provenant de
plusieurs cubes. Par exemple, dans certains cas, pour des raisons de performances et de
volumétrie, les données sont stockées par années dans des cubes différents. Dans ce cas,
un multicube permet de consolider les données des différentes années dans les états.

Exemple :
Un multicube ne permet pas de croiser des données, il ne fait pas de jointures. Le multicube
ne fait que rassembler des données.

La table ODS / Datastore :

La table ODS est la table de détail dans BW. Elle stocke l’information de manière unitaire et
permet de gérer des chargements en mode delta. Elle est souvent utilisée comme
intermédiaire entre le système source et le cube BW. Les données des tables ODS ne
peuvent pas en général être exploitées directement dans les requêtes BW. Cela est toutefois
possible via une option particulière, moyennant des performances très amoindries sur la
requête.

L’Extracteur :

L’extracteur est l’outil standard SAP pour extraire les données depuis le système
transactionnel vers BW. SAP livre un grand nombre d’extracteur en standard. Il est
néanmoins possible d’étendre les extracteurs standards dans le cas ou les données extraites
vers BW ne sont pas suffisantes. Il est également possible de créer de nouveaux extracteurs
spécifiques en cas de besoin. L’extracteur est caractérisé par son mode d’extraction..
Chaque extracteur peut extraire les données soit en Full, soit en Delta. L’extraction Full
correspond à une mise à jour « annule-remplace » qui consiste à (re)extraire l’ensemble des
données existantes. L’extraction delta nécessite la gestion de pointeurs de dernière
modification dans le système transactionnel, il permet de n’extraire que les dernières
données créées ou modifiées dans les systèmes sources, ie les données pas encore
extraites dans BW.

1.1.2.5Les Reports générés

Le suivi d’une activité croise souvent plusieurs indicateurs de manière transverse, et se fait à
travers la lecture de documents appelés « reports » ou « états ». Il existe deux types de
reports :
• Les reports opérationnels : ce sont des états relativement simples, en général figés avec
peu d’axes d’analyse. Ils ne sont pas destinés en général au pilotage de la performance
mais permettent plutôt aux acteurs SI de traiter des tâches identifiées, de suivre les erreurs
et rejets du système.
 • Les reports décisionnels : ces états permettent une analyse globale de la performance. Ils
ont une vocation analytique et combinent donc beaucoup d’axes de navigation. Par ailleurs,
ils traitent des informations consolidées sur de très grands volumes. Ils permettent des
analyses de tendances, de suivi global et de pilotage sous différentes vues. La plupart des
«états » de pilotage de la performance sont des états décisionnels donnant à la fois une
vision au niveau individuel des données mais également des consolidations par niveau
hiérarchique.

Enfin, BW permet d’effectuer un certain nombre de retraitements de données à des fins de

confort de reporting. Exemple : la sélection de certains axes en particulier donne une vision
du report adaptée au besoin du lecteur. Les états peuvent affichés soit sous forme Excel,
soit publié sur le portail, en affichage Web.

Les extracteurs standard de SAP seront utilisés et adaptés aux zones propres à L’institut
Télécom pour mettre en œuvre les infocubes de données nécessaires aux éditions ansi que
les requêtes..

1.1.3 Périmètre BI de notre offre

La qualification du déploiement BI à la lecture du cahier des charges fait ressortir les
paramètres suivants :
• Aucune étude recensant des restitutions aussi bien « opérationnelles » que «
décisionnelles » ainsi qu’une liste de fonctionnalités de restitutions attendues
• Sources de données uniquement en provenance d’ECC6 HR et FI/CO
• Adaptation du standard ECC6 HR, d’où présence de développements spécifiques dans les
SI sources
• Reporting et pilotage : SAP BI 7.0
• Portails de restitution : SAP EP 7
• ETL : BW

Afin d’intégrer l’ensemble de ces paramètres, nous préconisons la construction d’un socle de
données hébergé dans un entrepôt de données ayant les principales caractéristiques
suivantes :
• Extractions/Chargements :
♦ Utilisation de la partie ETL de BI 7.0 (data transfert process DTP ou
datasource en version BW 3.x + infosource) pour les sources SAP R/3 : le
spécifique identifié à ce jour limite l’utilisation des Business Contents
(préparamétrage standard) de BI 7.0. Nous intégrons donc une adaptation de
ce standard (exemple : extension des datasource et recours à l’ABAP pour
les users-exit BW notamment) afin de prendre en compte les besoins propres
de l’Institut Télécom l’Air.
♦ Aspect Temps Réel : en plus des fonctionnalités de reporting standard côté
ECC6, nous proposons d’exploiter les nouvelles fonctionnalités de BI 7.0 pour
traiter cet aspect. Cependant, nous éprouverons la stabilité de ces nouvelles
fonctionnalités en phase de conception et n’excluons pas un arbitrage avec
l’utilisation des « remote cubes » dans certains cas (accès direct aux bases
du SI source).
• Stockage/Transformation :
♦ Utilisation de BI 7.0 : nous suggérons d’utiliser les structures de stockage
proposées par le Business Contents (infoproviders de type datastores
(nouveaux ODS en version 7.0), infocubes, multiproviders et infosets). Ces
structures devront cependant être adaptées aux besoins de l’Institut Télécom
et, de fait, prendront en compte les aménagements des extractions
(datasources/infosources) et seront optimisées pour les besoins de
navigation et de reporting. Nous avons prévu de compléter cette approche par
le paramétrage de nouvelles structures de stockages.
• Restitutions :
♦ Utilisation de BI 7.0 : nous estimons que les restitutions seront, pour la
plupart, spécifiques aux besoins des utilisateurs de l’Institut Télécom.
L’exploitation du Business Contents est, de facto, réduite voire inapplicable
(sauf pour faciliter l’expression des besoins lors des ateliers prévus en phase
de conception. Nous envisageons donc de construire les restitutions qui
seront décrites en phase de conception et de les mettre à disposition des
utilisateurs via le media (Bex, Web, Portail) et le mode (push/pull) les plus
appropriés à leurs besoins/droits d’accès. La charte graphique sera respectée
pour ces restitutions.
 ♦ Utilisation de BI Accelerator : comptant parmi les nouvelles fonctionnalités de
BI 7.0, le BI Accelerator, notamment proposé par HP en partenariat avec
SAP, permet d’accélérer de façon importante la génération des requêtes en
optimisant l’accès aux infocubes (via une indexation automatisée des
dimensions des cubes et le chargement des données en RAM). Dans l’état
actuel de nos connaissances, nous estimons que cet outil n’est pas requis
pour le périmètre Orchestra. Cette hypothèse pourra cependant être revue et
discutée avec l’Armée de l’Air lors de la phase de conception.
• Plan de jobs : « process chains » appelés aussi « processus applicatifs » BI 7.0,
éventuellement déclenchés par un ordonnanceur externe à SAP. Les process Chains sont
créées pour automatiser les chargements.

Les extractions identifiées à partir du dossier des salariés sont les suivantes :
• La situation actuelle (affectation, identité, classement, adresse, horaire, ) ;
• L’historique des Maladies et accidents du travail ;
• L’historique des contrats et avenants ;
• Les flux externes entrant (mesure d’entrée);
• Les flux externes sortant (mesure de sortie);
• Les flux internes (détachements et mutations) ;
• L’historiques des formations / compétences / qualifications ;
• L’historique des plans de roulements ;
• L’historique des absences ;
• L’historique des handicaps ;
• L’historique des rémunérations de base.

Notre offre comprend aussi la mise en œuvre de 5 structures multidimensionnelles, la

création de 40 objets ou tables, ainsi que la mise en œuvre de 10 restitutions identifiées
pendant la phase de conception.

Notre offre ne couvre pas l’achat des licences et des machines nécessaires à la mise en
œuvre de BI.
2 PRÉSENTATION DE L’INFOCENTRE BO

Les grandes étapes de mise en œuvre d’un infocentre sont :

• La collecte des données
• La réception des données
• La gestion du référentiel
• La préparation et le chargement des données
• Le stockage et la préparation des données

2.1.1.1.1.1 Collecte des données

La collecte constitue l’étape préalable à l’intégration des données dans le système

décisionnel. Elle couvre les fonctions :
• D’extraction,
• D’organisation et de contrôle d’acheminement des données,
• D’entreposage des fichiers de données collectées,
• D’activation des traitements de contrôle et chargement appropriés.

Communément, pour les besoins d’interfaçage des systèmes décisionnels avec des
systèmes sources, deux modes « d’extraction » sont envisageables :
• Le mode « pull » : c’est RH@psodie qui prend en charge l’extraction des données dans les
systèmes sources. Cette technique présente l’avantage de n’avoir à construire et à maintenir
qu’une interface unique. En contrepartie, elle peut induire des adhérences entre les systèmes
qui peuvent entraver leur évolutivité, mais aussi, engendrer des difficultés de synchronisation,
voire des perturbations, de planning lorsque la construction des systèmes est parallélisée ;
 • Le mode « push » : les données sont mises à disposition de RH@psodie au format de fichiers
plats par les systèmes sources (ou mis à disposition dans une base de publication).

La stratégie de collecte des données est un des points adressés durant la phase de
conception générale de RH@psodie.

Quelle que soit leur origine et leur mode de collecte, il convient ensuite d’entreposer les
données dans un espace tampon constitué de tables, que nous appellerons « operational
data store (ODS) ».

Des comptes-rendus (logs) sont produits pour restituer le statut d’exécution des traitements
et signaler les éventuelles anomalies détectées.

2.1.1.1.1.2 Réception des données

Le processus de réception des données intègre les traitements :

• Contrôle d’intégrité des fichiers (exemple : respect des normes de nommage, conformité du
nombre de lignes, conformité et cohérence des informations présentes dans un enregistrement
d’entête, etc.),
• Contrôle des séquences (rupture de numérotation, etc.),
• Contrôle syntaxique des enregistrements (format, présence de champs obligatoires, domaine
de valeurs, etc.),
• Gestion des erreurs, exceptions et rejets,
• Archivage des fichiers sources.

En cas d’anomalie détectée et rejet du fichier – mauvais format, contenu illisible, etc. –,
l’exploitant de RH@psodie peut demander la réémission du fichier concerné à l’opérateur ou
au système émetteur.

A des fins d’administration fonctionnelle et technique, la réception de chaque fichier source

est tracée dans une table de suivi spécifique, mise à jour avec notamment le nom du
nouveau fichier, ses date et heure d’arrivée, son origine, sa taille, etc.

2.1.1.1.1.3 La gestion du Référentiel

La gestion de référentiel permet en particulier de répondre aux objectifs de cohérence et de

normalisation des données qui sont dévolus à RH@psodie.

Par contrainte de délai ou de budget, il est concevable que, dans un premier temps, cette
fonction adresse principalement les registres :
• Contrôles d’intégrité référentielle : conformité des informations à charger par rapport à des
valeurs de référence,
• Homogénéisation des référentiels des différents systèmes sources ; c’est-à-dire la
transcodification de valeurs d’origine en valeurs cibles gérées dans RH@psodie,
• Structuration des axes d’analyse et valorisation de leurs hiérarchies. Informations qui sont
utilisées pour les traitements d’agrégation, d’analyse et de restitution,
• Paramétrages techniques (référentiels des traitements) qui permettent d’assurer la
communication d’informations aux autres composants de RH@psodie : variables de calcul,
localisation de fichiers, horodatage de traitements, paramètres de sécurité, seuils de tolérance,
…
Au delà, la gestion de référentiel peut être étendue aux métadonnées, à une gestion
sophistiquée ou ensembliste (connexion à des annuaires d’entreprise, …) des profils et des
droits d’accès des utilisateurs.

2.1.1.1.1.4 Préparation et chargement des données

La préparation consiste à exploiter, fichier par fichier, les informations collectées. L’ensemble
fonctionnel comprend les fonctions de :
• Contrôle des données :Ce module doit s’assurer, de façon automatisée, de la qualité des
données reçues de systèmes amont. Différents contrôles sont mis en place et s’assurent :
o De la qualité des informations de référentiel (par exemple, le poste de l’agent est-il
bien rattaché au référentiel emploi) ;
o De l’absence de doublons ;
o De la satisfaction de règles d’intégrité fonctionnelle (i.e. métier) ou de domaine
(exemple : quantité supérieure à 0, ou inférieure à X en fonction de l’unité de
mesure…).
• Gestion des rejets : Dans le cas où l’enregistrement traité ne satisfait pas les différents
contrôles qualité, celui-ci est écarté dans une table de rejet de manière à être facilement et
rapidement identifié par l’administrateur fonctionnel. En fonction du type de rejet, seulement les
lignes qui ne respectent pas les règles définies seront rejetées ou bien le fichier en entier. Le
fichier rejeté doit donc être corrigé puis réintégré dans le système.
• Chargement : Le chargement consiste à enchaîner les opérations qui permettent de disposer
d’informations structurées, réconciliées et filtrées. A chaque fichier source correspond une
table de chargement dans la zone de collecte. Le format de la table reste très proche de la
structure du fichier et permet de stocker l’ensemble des informations utiles à l’alimentation de
l’entrepôt de données. Une fois le chargement achevé, les informations sont prêtes pour
alimenter l’entrepôt de données détaillé, puis les vues métiers (datamarts).

2.1.1.1.1.5 Stockage et préparation de la présentation des données

L’entrepôt de données détaillé constitue un sous-ensemble de la base de données

permettant le stockage des données élémentaires ou atomiques.

La préconisation du Titulaire est de mettre en œuvre un entrepôt de données détaillé

reposant sur un modèle neutre, indépendant des sources de données et très peu
dénormalisé. Il vise à décrire les objets métier manipulés par les utilisateurs et à constituer le
socle pérenne et évolutif de RH@psodie.

A partir de l’entrepôt de données détaillé, les informations sont agrégées et les indicateurs
sont calculés afin de répondre aux besoins métiers spécifiques, puis sont stockées dans les
vues métier (datamarts) qui peuvent prendre la forme de tables de la base de données, d’un
schéma spécifique de base de données, ou bien de cubes OLAP. Les solutions idoines sont
considérées et entérinées en phase de conception générale (compromis entre utilisation,
simplicité d’implémentation et performance).

2.1.1.1.1.6 Alimentation du datamart technique

Il s’agit des fonctions transverses, intégrées à toutes les étapes – de la collecte des données
sources à l’alimentation des vues métiers – qui, opportunément, en fonction des besoins
avérés, permettent de mettre en œuvre :
 • Des mécanismes de traçabilité (exemple : réponse à des obligations règlementaires),
• Des mécanismes d’évaluation et d’historisation d’indicateurs de qualité des données
(qualification des informations) voire de performances d’alimentation ou de temps de réponse
moyens de génération d’états décisionnels.

Le contenu et le niveau de détail du datamart technique seront adressés lors des phases de
conceptions.

2.1.1.1.1.7 Analyses et restitutions

Cette partie consiste à mettre à disposition des utilisateurs, en se basant sur les données
des vues métiers :
• Des états de restitution standards qui sont utilisés de manière périodique (bilans, tableaux de
bord mensuels, …),
• Un outil de restitution permettant la création de rapports personnalisés (requêtes ad hoc),
• Des outils et programmes permettant d’effectuer des analyses statistiques avancées (réservés
à une population limitée d’utilisateurs).

La description des états, tableaux de bord, et alertes à fournir sera adressé en phase de
cadrage et de spécifications.

2.1.1.1.1.8 Administration-Suivi

L’administration fonctionnelle consiste en diverses opérations :

• Maintien à jour des données de référence,
• Maintien à jour des tables de transcodification,
• Paramétrage de l’exécution de traitements,
• Accès aux comptes-rendus de chargement,
• Consultation/validation des rejets de traitements,
• Gestion utilisateurs (sécurité d’accès) : fonction à usage d’un administrateur « central » qui
permet une gestion simple de l’accessibilité aux ressources de l’application,
• Déclenchement d’une procédure simple de purge avec archivage des données.

2.1.1.1.2Mise en œuvre de l’infocentre pour le projet RH@psodie

Les extractions identifiées à partir du dossier du marin sont les suivantes :

• La situation actuelle du marin (affectation, identité, classement, adresse, position,modalité de
service,…)
• L’historique des Maladies et accidents du travail
• L’historique des contrats et avenants
• L’historique des activités
• L’historique des engagements
• Les flux externes entrant
• Les flux externes sortant
 • Les flux internes (détachements et mutations)
• L’historique des avancements / classement
• L’historiques des formations / compétences / qualifications / spécialités
• L’historique des sanctions
• L’historique des modalités d’activité
• L’historique des décisions
• L’historique des absences
• L’historique des handicaps
• L’historique des notations

Notre offre comprend aussi la mise en œuvre de 5 structures multidimensionnelles, la

création de 40 objets ou tables, ainsi que les restitutions du processus de GPEEC
mentionnées dans l’annexe
‘ANX_Annexe_CdCF_07_Tableaux_de_bord_et_autres_referentiels_d_aide_a_la_decision.x
ls’ :
• R-10 -318 - Liste des officiers à convoquer
• R-10 -319 - Graphique descriptif de la synthèse de l’évaluation haut potentiel sur le critère
compétences managériales
• R-10 -320 - Graphique descriptif de la synthèse de l’évaluation haut potentiel sur le critère
Dimensions liées à la réflexion et évolution sur plusieurs années
• R-10 -321 - Graphique descriptif de la synthèse de l’évaluation haut potentiel sur le critère
dimensions liées à l’action et évolution sur plusieurs années
• R-10 -322 - Graphique descriptif de la synthèse de l’évaluation haut potentiel sur le critère
dimensions liées à la relation et évolution sur plusieurs années
• R-10 -323 - Graphique descriptif de la synthèse de l’évaluation haut potentiel sur le critère
compétences managériales
• R-10 -324 - Graphique descriptif de la synthèse de l’évaluation haut potentiel sur le critère
Dimensions liées à la réflexion et évolution sur plusieurs années
• R-10 -325 - Graphique descriptif de la synthèse de l’évaluation haut potentiel sur le critère
dimensions liées à l’action et évolution sur plusieurs années
• R-10 -326 - Graphique descriptif de la synthèse de l’évaluation haut potentiel sur le critère
dimensions liées à la relation et évolution sur plusieurs années

Ainsi que les deux restitutions présentées dans la fiche de processus 9.2 – Gestion des
effectifs concernant :
• Le suivi mensuel des effectifs de la Marine
• La détermination des Effectifs Moyens Réalisés
Les autres restitutions évoquées dans les fiches processus de pilotage des RH n’étant pas
mentionnées dans l’annexe décrivant l’ensemble des requêtes à produire dans le cadre du
projet RH@psodie sont exclues du périmètre des prestations attendues.

La phase de conception permettra de définir :

• · La modélisation des cubes ou ensembles de données logiques permettant l’alimentation de
l’univers BO.
 • · Réalisation des structures multidimensionnelles
• · La définition des flux et transferts des données vers BO, avec pour chaque flux, les critères
d’extraction et les règles de transcodification.
• · La gestion des autorisations / profils d’accès

La description technique de l’interface antre SAP et l’univers BO est décrite dans le chapitre
3 – Volet technique.

2.1.2 Chapitre 3 – Volet Technique : Business Objects

2.1.2.1Présentation

Les objectifs assigné à l’infocentre :

• Doter la Marine Nationale de restitutions prêtes à l’emploi afin de répondre à différents besoins
:

o éclairer la construction du dialogue de gestion en facilitant l’accès à des

données homogènes multithématiques ;

o mettre à disposition des gestionnaires RH des tableaux de bord de pilotage ;

o faciliter la construction des reportings réglementaires ;

o participer à l’analyse des coûts.

• Mettre à disposition des environnements d’interrogations simples :

o pour répondre à des besoins de pilotage plus spécifiques ;

o pour des interrogations libres sur des grands thèmes ;

o pour comparer, regrouper et analyser des données dans le temps en se

basant sur un référentiel partagé, contrôler la cohérence entre les différentes
données en provenance des applications existantes.

2.1.2.2Architecture applicative

BusinessObjects Enterprise est un système multi-niveau. Bien que les composants se voient
attribuer diverses tâches, ils peuvent être regroupés logiquement en fonction du type
de travail qu'ils exécutent. BusinessObjects Enterprise comporte cinq niveaux :
• le niveau client ;
• le niveau application ;
• le niveau intelligence ;
• le niveau traitement ;
• le niveau données.

Pour plus de souplesse, de fiabilité et d'extensibilité, les composants formant chacun de ces
niveaux peuvent être installés sur une ou plusieurs machines.

Les principes de base de l'architecture ainsi que la description des cinq niveaux sont décrits
en détail dans le « Guide d'administration de BusinessObjects Enterprise » accessible sur le
web : http://support.businessobjects.com/documentation/product_guides/default.asp. Les
principaux composants de l'installation du serveur BusinessObjects XI R2 sont:
• BO XI R2 est une application Java exécutée sur le serveur d’application Tomcat.
• Référentiel BO XI : C’est un schéma dans une base de données Oracle contenant
quelques tables qui stockent des données de sécurité. Les documents et univers n’étant
pas stockés dans le référentiel, le référentiel BO XI contient des pointeurs vers les dossiers
du systèmes d’exploitation contenant les fichiers documents et univers
• Fichiers et document univers : Les documents et univers Business Objects sont stockés sur
le système de fichiers Linux.
• Bases métiers : Elles contiennent les données interrogées par les documents Business
Objects
Les composants de l’installation côté client, à destination des utilisateurs finaux, sont les suivants :
• Navigateur Internet : Il est possible d’utiliser Internet Explorer et Firefox
• Desktop Intelligence : il s’agit d’un client lourd permettant d’exécuter des requêtes sur les
bases métier
• Designer : client lourd permettant de construire les univers sur lesquels les utilisateurs
s’appuient pour construire leurs requêtes.
• Assistant d’importation : permet de recopier des univers et documents d’un référentiel
Business Objects à un autre. Il doit pouvoir accéder à la base de données contenant les
référentiels Business Objects.

Figure 2.2.3.2.1 : Architecture applicative de l’infocentre RH@psodie

2.1.2.3Environnements Business Objects

Les besoins en environnement sont les suivants :
• DEV : Développement et paramétrage de l’infocentre
• REC : Recette fonctionnelle et initialisation des données
• FOR : Formation
• PPR : Pré-production
• PRD : Production. Il sera dupliqué sur le site de secours à Bordeaux.
Un environnement est toujours construit à partir d’un autre environnement source. Le
mécanisme de construction d’un nouvel environnement consiste à transférer le
paramétrage, les référentiels, l’enveloppe des programmes, des fichiers et des tables,
L’outil de passage fourni par Business Objects sera utilisé pour construire un nouvel
environnement.
Il existe deux types de transferts pour transférer les modifications d’un environnement à
l’autre :
• Les copies brutes, ou duplications
• Les livraisons
Les copies brutes sont utilisées pour l’initialisation des nouveaux environnements. Elles
sont effectuées en utilisant une procédure de clonage manuelle. Cette procédure inclut les
opérations suivantes : installation d’un environnement cible, transfert des données au
niveau de la base Oracle, transfert des univers et des rapports avec l’assistant
d’importation de Business Objects et modification du paramétrage de l’accès aux données.
Les livraisons concernent des transferts beaucoup plus légers en termes de volumétrie.
Une procédure de livraison est fournie, indiquant les opérations à effectuer sur les
différents composants (PL/SQL, rapports, paramétrages fonctionnels, etc…)
Une copie brute sera exécutée pour initialiser le site de secours mais aucune livraison ne
sera effectuée. Le site de secours sera tenu à jour par restauration systématique des
sauvegardes réalisées sur le site de produciton.

Figure 2.2.3.3.1 : Transfert des modifications de l’infocentre