Les Grands Principes de La BI

Pilotage
et suivi de l'activité
Les concepts, Les grands principes de la BI
6 juin 2008 – Aix En Provence

Agenda
■ Micropole-Univers en Bref
■ Introduction aux concepts de la BI
■ Les besoins utilisateurs
■ Les architectures
■ Lesconditions de réussite
La démarche de mise en œuvre
Les risques
© Micropole-Univers 2008
Micropole-Univers
• Présentation, en bref…
Spécialiste Conseil et Ingénierie Décisionnelle & e-Business
■ Plus de 400 clients, fidèles et satisfaits
- Top 10 : Administration Cantonale des Impôts de l’État de Vaud, BNP Paribas, État de
Fribourg, Orange, Generali, Groupe Banques Populaires, HSBC, Ministère de l’Emploi et de
la Solidarité, Ministère de l’Intérieur, SFR
■ 80 % de récurrence client
■ Environ 1000 collaborateurs
■ Une couverture nationale et européenne
■ Une croissance constante et maîtrisée

CA 2007 : 78,5 M€ - Cotée sur Eurolist
Un accompagnement global
Introduction
• Qu’est ce que la BI
• Intégration des SID avec le reste du SI
Définition de la BI
■ La BI c’est l’art de
- Fournir des solutions d’informations à valeur ajoutée
- Aux utilisateurs (management ou niveau opérationnel)
- Afin de prendre les meilleures décisions
Processus de décision humain
mémoire
■ Je reconnais une personne quand je
la vois parce que je l’ai déjà vue
vue - Je vois la personne
- Je compare cette vision avec ma mémoire
qui a stocké l’image des personnes que je
connais (image + nom)
ouie
Stimuli externes
cerveau
■ J’ai chaud
- S’il fait chaud dehors => c’est normal, je vais
me mettre au frais
toucher - S’il ne fait pas chaud => j’ai de la fièvre => je
vais chez le médecin
• alerter
goût • comprendre => une information isolée a peu de
• corréler valeur
elle n’a de sens que comparée à
odorat d’autres informations
- Contexte
- Mémoire
Stimuli internes
Système d’aide à la décision
Données
historisées ■ Une information isolée a peu de
valeur
Achats - On compare un chiffre à un objectif
(référentiel)
- On suit l’évolution d’un indicateur dans
Systèmes opérants
Logistique BI le temps
- On fédère des données provenant de
plusieurs systèmes pour obtenir une
Comptabilité information à valeur ajoutée
Facturation
Gestion
Relation
client
Système d’aide à la décision
■ Acquérir l’information
- Sources
■ Interfaces avec le reste du système d’information
■ Saisie de données de type objectifs par les utilisateurs
■ Intégration de données externes (concurrence, INSEE, …)
- Traitements
■ Nettoyer, versionner, historiser, fédérer l’information
■ Stocker l’information
■ Restituer l’information à l’utilisateur

- Reporting : Extraire et présenter les données
- Exploration et analyse
- Data mining (corrélations et prédictions)
Les besoins utilisateurs
• Reporting de masse et reporting BI

• Exploration et analyse
• Tableaux de bord et pilotage
Les typologies d'utilisateurs
Utilisateurs
• Tableaux de bord • Rapports paramétrés • Requêtes Ad Hoc

• Portail • Consultation interactive • Rapports à la demande
• Rapports formats divers • Analyse Olap
Consommateur Auteur
Reporting de masse et reporting BI
■ Objectifs
- Fournir une vision opérationnelle de l’activité
- Ce reporting s’adresse à des managers et à leur équipes
- Pour les managers, c’est un outil de management opérationnel (il s’agit plutôt de rapports
numériques)
■ Pour le directeur commercial
- Ventes par responsable de secteur
- Qui est en retard par rapport à ces objectifs
■ Pour le responsable de production
- Ventes par produit
- Etat des stocks
- Etats de production
- Pour les équipes de production, c’est une aide quotidienne pour leur activités
■ Qu’elles sont les commandes à préparer
- Pour les commerciaux c’est un outil de suivi de leur activité
■ Classement des ventes par région/distributeur
■A retenir
- Il s’agit d’une vision a posteriori (basée sur des données existantes)
- Les besoins sont connus a priori
Les caractéristiques
Reporting de masse Reporting BI

■ Des solutions de publication de ■ Logique d'analyse : requête ad hoc et
documents aux formats élaborés pour rapports à la demande
un grand nombre d'utilisateurs - Des documents jetables
- Des documents de production - Utilisation ciblée
■ Données synthétiques (tableaux croisés, graphiques)
- La gestion de grands volumes
■ Nombre restreint d’utilisateurs
■ nombre de pages produites
■ nombre d'utilisateurs ( X 1000 ) - La donnée est plus importante que la forme
- Une richesse et une sophistication des mises - Logique de pull pas de push
en forme des documents - L’usage
■ "au pixels prés" ■ BI : outil End User d'un Système d'Information Décisionnel
- Les modalités de publication ■ L’utilisateur est un auteur
■ multi-canaux ( mail, web, imprimante,…)
■ Multi format ( html, bureautique, fichiers plats,.. )
- La performance et la capacité de montée en
charge des plate formes
- L'usage
■ Des outils mise en œuvre par des développeurs
■ L'utilisateur est un consommateur
Le reporting dans l'entreprise
Reporting de masse Reporting BI
Composante
reporting
Application et ERP Base dédiée DWH

Module
OEM
complémentaire
Exploration et analyse
■ Naviguer dans l’information depuis le niveau le plus agrégé jusqu’au niveau le plus
fin sur un ensemble d’axes d’analyse important (vision pyramidale)
■ Objectif
- Identifier à quel endroit (produit, secteur, période), les objectifs ne sont pas atteints
- Emettre des hypothèses, les valider/invalider
■ A retenir
- Il s’agit d’une vision a posteriori (basée sur des données existantes)
- Contrairement aux rapports et tableaux de bord il s’agit d’une vision sans a priori (je ne sais
pas où est l’information que je cherche)
- Travail très intuitif => cela nécessite des temps de réponse instantanées pour ne pas
nuire à l’intuition
Tableaux de bord et pilotage
■ Objectifs
- Fournir une vision globale et synthétique de l’activité de l’entreprise souvent
en comparaison avec des objectifs pré-définis
- Métaphore du cockpit de pilotage
- KPI plutôt que des indicateurs simples
■A retenir
- Le pilotage peut être vu comme un sous-ensemble du reporting
- Néanmoins …
■ Les indicateurs représentés sont souvent plus composites que les indicateurs utilisés
pour le reporting ou l’analyse
■ La navigation se fait entre écrans plutôt que dans les données (pré-câblage)
■ La notion d’objectifs (suivi temporel ou comparaison par rapport à un objectif) est
omniprésente
Un cadre de référence: Outils et méthodes …
Hypothèses / « FAIRE LES BONNES CHOSES »
Objectifs / choix
d’investissements
PILOTAGE STRATEGIQUE
BSC
Données
financières
consolidées Dashboard
Instructions Scorecard
PILOTAGE Objectifs
Priorités
BUDGETAIRE ET Mesures de
FINANCIER ABC / ABM performance
Besoins /
Données Business Intelligence
Consolidation /
financières Data Warehousing
Elaboration budgétaire
détaillées
SIX SIGMA,
TQM, BPM
Ressources
PILOTAGE OPERATIONNEL
« SE DONNER LES MOYENS » « FAIRE BIEN LES CHOSES »
Les architectures
• Sur systèmes opérants

• Sur copie de système opérant
• Infocentre
• ODS, Datawarehouse et datamart
Une problématique différente du transactionnel
TRANSACTIONNEL SID
■ Destiné aux opérationnels ■ Destiné aux décideurs
■ Assure l'activité au quotidien ■ Permet analyse et prise de décision

■ Mises à jour des données ■ Lecture uniquement des données
■ requêtes simples ■ Requêtes complexes
■ Temps de réponse immédiats ■ Temps de réponse moins critiques
■ Faible volume à chaque transaction ■ Larges volumes manipulés
■ Stockage conçu pour la mise à jour ■ Stockage conçu pour l'extraction et
l’historisation
■ Usage maîtrisé ■ Usage aléatoire
■ Pas de référentiel commun ■ Un référentiel commun
Sur systèmes opérants
■ Besoin
- Reporting standard opérationnel (listes, sections, filtres, tris, …)
■ Limites
- Performances
■ Performances des requêtes (surtout s’il y a des agrégations)
■ Impact sur les performances des systèmes sources en batch ou transactionnel
- Fonctionnel
■ Vision à un instant t
■ Inconsistance des données entre deux instants (liée à des suppressions de données par exemple)
■ Données mono-sources
■ Ni analyse ni drill down
- Maintenabilité
■ Evolutivité limitée (implication de l’informatique à chaque fois qu’on veut modifier une requête)
■ Maintenabilité coûteuse en cas de modification du modèle de données source ou des règles de gestion
- Technique
■ Problèmes techniques dans le cas où le système opérant ne fonctionne pas sur une base de données relationnelle
Sur copie de système opérant
■ Besoin
■ Limites
- Performances
- Fonctionnel
■ Ni analyse ni drill down
- Maintenabilité
■ Limites levées par cette solution

- Performances
- Technique
Infocentre
■ Besoin
- Analyse et drill down
■ Limites
- Fonctionnel

- Fonctionnel
- Performances
- Maintenabilité
- Technique
ODS, Datawarehouse et datamart
■ Besoin
- Analyse et drill down multi-sources

- Fonctionnel
- Performances
- Maintenabilité
- Technique
Architecture recommandée BI
Datamarts relationnels Datamarts OLAP
Tableaux de Requêtes
bord Extract, Transform, Load
Simulation
2
Aggregate level
Références
Data
Meta-data
warehouse Granularité : Modèle détaillé,
transverse & historisé
Extract, Transform, Load
1
ODS Fichiers plats, tables
Operational Data Store
Extract, Transform, Load
Systèmes opérants
SO1 SO2 SO3 SO4
Le rôle du Data Warehouse
■ Fédérer les données
■ Ne pas perturber le fonctionnement du SI transactionnel
■ Garder l’historique des données : dégager des tendances dans le temps
■ Exploiter les données de manière transversale : vision multi-domaine
■ Assurer la cohérence des données : référentiel commun
■ Garantir l’évolutivité
■ Données détaillées
Le rôle des Data marts
■ Le DataMart est une collection de données ORIENTEES SUJETS mise à la disposition des
utilisateurs dans un contexte décisionnel
- Il sert de support aux interfaces décisionnelles

- Il est orienté « utilisateurs » afin de satisfaire l’ensemble de leurs besoins autour du sujet donné
- Données agrégées : Implique une forte dénormalisation des données
■ Deux types de stockage possibles

- relationnel
- multidimensionnel
■ Exemple de décomposition de données : Domaine Facturation
- Niveau DWH : Ensemble des lignes de facture

- Niveau DM : Indicateur Montant Factures ventilé par mois, par client, et par région (niveau de
granularité à déterminer)
Les conditions de réussite
La démarche de mise en œuvre
Les risques
Conditions de réussite
■ « Think big, Start small »
■ Mise en place d’une démarche itérative. Découpage par domaine fonctionnel,

prévoyant le stockage de l’information de détail au niveau du socle de données.
- Evolutivité de la solution
- Réduire le délai de mise à disposition de l’information
■ Exprimer un besoin en matière de :

- Fonctionnalités
- Indicateurs
■ Être capable :
- de prioriser ce besoin
- de parler le même langage (de façon transverse entre les différentes directions métiers)
■ Choisir le bon outillage technologique
■ Avoir un cycle de vie du projet cohérent avec les avancements des projets ‘métier’
Autres points d’attention…
■ Qualité de données
■ Gérer la volumétrie des données

- Profondeur d’historique au sein du DWH vs coût de stockage et temps de réponse
- Mode d’archivage des données
■ Diffusion de l’information
- Multicanaux, multi-formats, etc.
La démarche projet « type »
Init. Validations Client
Livraisons Client
Livraison documentaires MU
Conception
Livraison « technique » MU
Plan
d’assurance 1 2
Mise en oeuvre
qualité
1 – Étude générale
2 – Étude détaillée 1 2 3
Mise en exploitation
1- Développement
2- Tests unitaires
Spéc. Fonctionnelles Géné.
3- Test d’intégration MEP
Mapping des données
Dictionnaire de données
L’application et ses
composants Garantie
Spéc. Fonctionnelles
Détaillées 3
Manuel d’installation 1 2
Spécifications techniques
Normes de développement Manuel d’exploitation
Dossier Architecture Dossier technique de réal. 1 – Recette Usine
Logicielle Rapport de tests unitaires 2 – Recette provisoire
3 – Recette définitive
Plate-forme de Jeux de données
développement Cahier de recettes L’application et ses
composants
Transfert de compétences / Accompagnement

Suivi de Projet / Suivi Qualité / Documentation
Les risques
■ Le périmètre
- Choisir un périmètre moteur
■ Ne pas chercher à tout modéliser
■ Trouver un premier périmètre pour créer un succès et aider à mesurer le ROI
- Préparer dès le début l’accompagnement au changement
■ Le recueil des besoins

- Prévoir le reporting Ad’hoc :
■ Ne pas se contenter de recueillir le besoin à travers des rapports existants ou imaginés
■ méthode de recueil des besoins spécifique
- S’écarter de la finalité :
■ Complexification des demandes,
■ Au final manque d’autonomie des utilisateurs…
■ La disponibilité du client !
- Trop souvent minimisée, malgré les avertissements
Merci pour votre attention
Pour toute information complémentaire, merci de contacter
Guillaume SAMSON
Manager BI - Agence Méditerranée
Tél. + 33 4 42 97 53 90
Fax + 33 4 42 97 53 92
e-mail : gsamson@micropole-univers.com

Les Grands Principes de La BI

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Les Grands Principes de La BI

Transféré par

Droits d'auteur :

Formats disponibles

Pilotage

6 juin 2008 – Aix En Provence

■ Introduction aux concepts de la BI

■ Les besoins utilisateurs

■ Environ 1000 collaborateurs

■ Une couverture nationale et européenne

■ Une croissance constante et maîtrisée

■ Restituer l’information à l’utilisateur

• Reporting de masse et reporting BI

• Tableaux de bord • Rapports paramétrés • Requêtes Ad Hoc

Reporting de masse Reporting BI

Reporting de masse Reporting BI

Application et ERP Base dédiée DWH

• Sur systèmes opérants

■ Destiné aux opérationnels ■ Destiné aux décideurs

■ Assure l'activité au quotidien ■ Permet analyse et prise de décision

■ Usage maîtrisé ■ Usage aléatoire

■ Pas de référentiel commun ■ Un référentiel commun

■ Limites levées par cette solution

■ Limites levées par cette solution

■ Limites levées par cette solution

Datamarts relationnels Datamarts OLAP

Extract, Transform, Load

Operational Data Store

Extract, Transform, Load

SO1 SO2 SO3 SO4

■ Fédérer les données

■ Ne pas perturber le fonctionnement du SI transactionnel

■ Garder l’historique des données : dégager des tendances dans le temps

■ Exploiter les données de manière transversale : vision multi-domaine

■ Assurer la cohérence des données : référentiel commun

- Il sert de support aux interfaces décisionnelles

■ Deux types de stockage possibles

■ Exemple de décomposition de données : Domaine Facturation

- Niveau DWH : Ensemble des lignes de facture

■ « Think big, Start small »

■ Mise en place d’une démarche itérative. Découpage par domaine fonctionnel,

■ Exprimer un besoin en matière de :

■ Choisir le bon outillage technologique

■ Gérer la volumétrie des données

Transfert de compétences / Accompagnement

■ Le recueil des besoins

Pour toute information complémentaire, merci de contacter

Vous aimerez peut-être aussi