Vous êtes sur la page 1sur 33

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…

© Micropole-Univers 2008
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

© Micropole-Univers 2008
Un accompagnement global

© Micropole-Univers 2008
Introduction

• Qu’est ce que la BI
• Intégration des SID avec le reste du SI

© Micropole-Univers 2008
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

© Micropole-Univers 2008
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
© Micropole-Univers 2008
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

© Micropole-Univers 2008
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)

© Micropole-Univers 2008
Les besoins utilisateurs

• Reporting de masse et reporting BI


• Exploration et analyse
• Tableaux de bord et pilotage

© Micropole-Univers 2008
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

© Micropole-Univers 2008
Les besoins utilisateurs
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

© Micropole-Univers 2008
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

© Micropole-Univers 2008
Le reporting dans l'entreprise

Reporting de masse Reporting BI

Composante
reporting

Application et ERP Base dédiée DWH


Module
OEM
complémentaire

© Micropole-Univers 2008
Les besoins utilisateurs
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

© Micropole-Univers 2008
Les besoins utilisateurs
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

© Micropole-Univers 2008
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 »

© Micropole-Univers 2008
Les architectures

• Sur systèmes opérants


• Sur copie de système opérant
• Infocentre
• ODS, Datawarehouse et datamart

© Micropole-Univers 2008
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

© Micropole-Univers 2008
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

© Micropole-Univers 2008
Sur copie de système opérant

■ Besoin
- Reporting standard opérationnel (listes, sections, filtres, tris, …)

■ Limites
- Performances
■ Performances des requêtes (surtout s’il y a des agrégations)
- 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

■ Limites levées par cette solution


- Performances
■ Impact sur les performances des systèmes sources en batch ou transactionnel
- Technique
■ Problèmes techniques dans le cas où le système opérant ne fonctionne pas sur une base de données relationnelle

© Micropole-Univers 2008
Infocentre

■ Besoin
- Reporting standard opérationnel (listes, sections, filtres, tris, …)
- Analyse et drill down

■ Limites
- Fonctionnel
■ Données mono-sources

■ Limites levées par cette solution


- Fonctionnel
■ Vision à un instant t
■ Inconsistance des données entre deux instants (liée à des suppressions de données par exemple)
- 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
- 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

© Micropole-Univers 2008
ODS, Datawarehouse et datamart

■ Besoin
- Reporting standard opérationnel (listes, sections, filtres, tris, …)
- Analyse et drill down multi-sources

■ Limites levées par cette solution


- Fonctionnel
■ Données mono-sources
■ Vision à un instant t
■ Inconsistance des données entre deux instants (liée à des suppressions de données par exemple)
- 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
- 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

© Micropole-Univers 2008
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

© Micropole-Univers 2008
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

© Micropole-Univers 2008
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)

© Micropole-Univers 2008
Les conditions de réussite
La démarche de mise en œuvre
Les risques

© Micropole-Univers 2008
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’

© Micropole-Univers 2008
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.

© Micropole-Univers 2008
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

© Micropole-Univers 2008
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
© Micropole-Univers 2008
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