IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Mettre en place un entrepôt de données multidimensionnel

Mettre en place un entrepôt de données multidimensionnel


précédentsommairesuivant

2-E. Une construction itérative en quatre étapes

La construction d'un entrepôt de données multidimensionnel est itérative et incrémentale. Au fur et à  mesure de sa construction l'entrepôt de données doit devenir global et transversal via l'intégration de mesures de processus clés. L'intégration d'un nouveau processus passe par quatre étapes (3):

2-E-1. Étape 1 : sélection d'un processus clé

Le choix du processus clé doit se faire en fonction de son importance au sein de l'organisation. C'est aux stratèges et aux responsables opérationnels de prendre cette décision.

Voici quelques pistes de réflexions pour vous permettre de prioriser vos processus clés :

  • quel est le but premier de mon organisation et quels sont les processus qu'il serait nécessaire d'analyser ? Ici on parle bien de processus et non de départements, de services, ou de divisions... Une organisation est un tout, votre schéma de pensées doit être transversal et d'abord lié aux processus fondamentaux ;
  • quels sont les indicateurs de performance, d'éclairage ou de risque pertinents aux niveaux stratégique, analytique et opérationnel ? Même si les interrogations d'un stratège sont différentes des questions d'une personne opérationnelle, la source de données reste la plupart du temps a même. Pour mettre en place une stratégie de modélisation à  long terme vous devez avoir conscience des besoins aux différents niveaux des prises de décisions ;
  • quels exemples de décisions concrètes pourraient être pris à partir de ce système de mesure, et ce pour chaque personne de chaque niveau mentionné. Si aucune décision ne peut découler de votre système décisionnel c'est qu'il est sans intérêt. N'oubliez jamais qu'à  chaque mesure doit correspondre un ou plusieurs leviers d'actions (plus le niveau s'approche de l'opérationnel, plus les leviers doivent être simples) ;
  • quels gains réels pour l'organisation apporteraient ces décisions : hausse de la productivité ? Optimisation des coûts ? Meilleure réactivité sur les marchés ? Accroissement de la prise de part de marché ? Améliorer la fidélisation clientèle ?

Gardez à  l'esprit que la mise en place et l'évolution d'un système a un coût. L'étape du choix du processus à  modéliser est fondamentale, si celui-ci n'est pas pertinent, les décisions qui en découlent n'auront pas d'impact sur votre activité.

2-E-2. Étape 2 : choix de la granularité stockée

Dans cette étape vous devez faire le choix du niveau de détail de l'information que vous souhaitez conserver.

Exemple, sur un ticket de caisse que conserveriez-vous ? Chaque ligne de produit d'achat ? Chaque produit différent ? Regrouperiez-vous le montant par famille de produits ? Ou seul le montant total vous intéresse ?

Les responsables opérationnels ont tendance à  vouloir tout stocker, et ils ont raison. En effet, plus le degré de granularité est fin plus la capacité d'analyse est élevée (en terme de croisement entre vos différents axes d'analyses). Mais attention, malgré les progrès réalisés dans le traitement  et le stockage de grands volumes de données, plus l'information est détaillée et moins votre possibilité d'historique dans le temps est importante. Le choix cornélien de la granularité stockée est donc rempli de compromis. Dans tous les cas, il doit se faire avec l'aval de l'utilisateur final, du DBA(4) et du responsable de l'entrepôt de données.

2-E-3. Étape 3 : choix des axes d'analyses (dimensions)

Si le mot dimension est utilisé dans la majorité des outils de modélisation, je préfère l'expression « axe d'analyse ». Chaque processus peut-être analysé sous différents axes : par période de temps, par typologie de client, par typologie de produits, par localité, par site de production, etc. Le but de cette étape est de choisir quels sont les axes d'analyse adéquats pour le processus en question. Rappelez-vous que l'architecture d'un entrepôt de données dimensionnel repose sur le principe de « bus », c'est-à -dire que ce sont les données de votre processus qui vont venir se brancher à  vos dimensions et non l'inverse. En d'autres termes, les dimensions définies ici sont communes à  l'ensemble de l'organisation et à  l'ensemble des processus. Avant de créer un nouvel axe d'analyse, veillez à  ce que celui-ci puisse être suffisamment générique pour convenir à  l'ensemble de votre organisation.

Pour trouver les dimensions adéquates au processus mesuré, posez-vous les questions suivantes :

  • à  qui ces données pourraient-elles être utiles ?
  • comment les analystes regrouperaient-ils les données ?
  • comment les analystes filtreraient-ils les données ?
  • quels sont les titres de colonne des rapports actuellement produits ?

Dans tous les cas, faites preuve de bon sens, restez simple et pragmatique et n'essayez pas d'être original. C'est à  partir du croisement de dimensions simples et compréhensibles que vous allez pouvoir prendre des décisions (pour plus de détail, je vous renvoie vers le chapitre dédié aux tables de dimensions). Cette étape du choix des axes d'analyses doit-être faite par une équipe hétérogène (opérationnels, analystes et représentant du système décisionnel en place). Elle doit être simple et naturelle pour tous les intervenants.

2-E-4. Étape 4 : quelles mesures (faits)

Quelles mesures de performance, d'éclairage ou de risque serait-il pertinent de rattacher à  ce processus clé ? Cette réponse doit être fournie à  la fois par des représentants opérationnels expérimentés et des collaborateurs stratégiques (manager, stratège). Ici votre mantra doit être : "Not everything that can be counted counts, and not everything that counts can be counted." [Albert Einstein]. Ce qui compte ne peut pas toujours être compté, et ce qui peut être compté ne compte pas forcément. En gardant cette phrase à  l'esprit vos avez plus chance d'assurer la pérennité de votre système.

Ce qui compte ne peut pas toujours être compté : en effet, votre système décisionnel se limitera toujours à  des faits tangibles. Vos collaborateurs les plus imaginatifs vous proposeront sans doute des techniques pour mesurer certain faits intangibles (exemple : la satisfaction client), si c'est le cas attention... Même s'il est possible de sonder ses clients via un questionnaire et calculer un ratio de satisfaction, ces données de type « exceptionnelles » n'ont rien à  faire dans votre système décisionnel. Celui-ci doit d'abord reposer sur des faits tangibles issus d'activités tracées par votre système d'information (c'est-à-dire : pas de données disponibles de façon récurrente = pas de mesure). Dans ce cas précis, on préférera représenter la satisfaction client à  travers un objectif qui encapsule des mesures tangibles en rapport avec votre activité, exemple : le nombre de réclamations traités, le nombre de retours de marchandises ou le nombre de connexions hebdomadaires,etc.

Ce qui peut être compté ne compte pas forcément : mesurez des faits qui ont un enjeu et un sens pour les décideurs ainsi que pour les opérationnels. Mesurez d'abord des indicateurs actés et connus.  Rappelez-vous que rien n'est gratuit ! Le coût de votre système décisionnel sera proportionnel au nombre de mesures stockées. Plus il y a de mesures, plus il y a de volume de données, plus il y a de source de données différentes, plus il y a de maintenance lors de l'évolution des systèmes opérationnels, plus vous aurez besoin de personnel qualifié affecté à  ces travaux de maintenances, etc. Avant d'intégrer une mesure, vous devez intégrer la notion « pertinence / coût ». Chaque mesure doit représenter un coût raisonnable proportionnel à  la valeur ajoutée qu'elle apporte. Seuls les responsables techniques pourront réellement vous indiquer le coût de l'intégration : volume de données, coût de stockage, coût CPU, coût de maintenance, impact sur le système actuel, etc. Rappelez-vous que vous ne mesurez pas par plaisir mais par nécessité. Les personnes issues des activités opérationnelles avec une forte expérience du métier sont souvent pragmatiques et de très bon conseil.


précédentsommairesuivant
Étapes déterminées par Ralph Kimball et Margy Ross dans le livre « Entrepôts de données Guide pratique de modélisation dimensionnelle »
DBA : Database Aministrator (Administrateur de base de données)

Copyright © 2011 Carlos Da Costa. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.