Préalable à un système décisionnel complet, l'entrepôt de données a d'abord connu un succès dans les secteurs où l'informatique joue un rôle critique, comme la banque et l'assurance. Il s'est depuis largement répandu chez les grands comptes afin d'établir des indicateurs de pilotage à destination des différentes directions métiers de l'entreprise.
Il reste cependant réservé à des catégories d'entreprises bien particulières au vu des investissements qu'il nécessite. Parce qu'il impose de fédérer l'information de l'entreprise et d'établir un référentiel commun à partir des demandes des directions métiers, l'entrepôt de données se construit généralement sur plusieurs années.
C'est aussi un investissement logiciel qu'il faut pouvoir maîtriser. Même si des solutions "tout en un" se développent à l'initiative de grands acteurs comme Oracle, SAP, IBM ou Microsoft, l'entrepôt de données exige un travail en amont via une solution d'ETL, un travail sur la base elle-même par sa conception multidimensionnelle, puis un travail en aval pour extraire l'information la plus pertinente à travers des solutions décisionnelles.
Au vu de la longueur et des investissements du projet, il faudra donc constamment motiver les partenaires du projet (directions métiers, direction générale mais aussi l'équipe informatique), pour éviter les nombreux écueils.
1- Analyser le parc logiciel existant et déterminer les besoins en termes d'outils
"Le marché du datawarehouse a évolué, il s'est élargi d'une part et l'on compte désormais des solutions packagées de type ERP, des outils de suivi temps réel de type BAM, le suivi de flux ou encore des solutions très métiers plus proches de l'élaboration budgétaire. Il existe aussi des éditeurs généralistes comme Oracle qui intègrent à leur offre des briques décisionnelles. Nous voyons aussi apparaître depuis un an et demi des briques Open Source. Il faut analyser toutes ces possibilités", déclarent Guy Piquard et Frédéric Dardant, respectivement architecte système décisionnel et responsable du centre de compétence BI pour Sopra Group.
Pour un grand compte déjà équipé d'une solution SAP, il sera logique d'étudier dans un premier temps le module BW (Business Warehouse) qui propose déjà des fonctions d'entrepôts de données. "En utilisant un système décisionnel derrière une solution de type SAP, la seule source d'information dont l'entreprise aura à se préoccuper sera celle filtrée par SAP. A l'inverse, en partant de zéro, l'entrepôt de données sera en prise directe avec une vingtaine de sources par exemple", déclarent les deux spécialistes de Sopra Group. Enfin, cela simplifie la négociation du prix des licences avec l'éditeur et l'intégration des produits puisque l'entreprise concentre son offre logicielle.
2- Nommer un responsable du projet soutenu par la direction générale
Un projet d'entrepôt de données se veut extrêmement structurant en matière d'harmonisation des données. Le chef de projet sera donc amené à imposer parfois des évolutions sur des applications en amont afin de préparer les données de l'entreprise aux traitements décisionnels en fin de chaîne. Pour obtenir ce pouvoir, il est préférable que l'équipe projet soit soutenue non seulement par la direction informatique mais aussi par la direction générale de l'entreprise.
"Des grands groupes comme France Télécom avec un nombre conséquent de nouveaux projets informatiques ont même décidé d'asservir toutes les données de leurs nouvelles applications à un référentiel maître. C'est un besoin qui est apparu lorsque nous avons voulu dresser le tableau de bord de l'entreprise", soulignent Guy Piquard et Frédéric Dardant.
3- Partir des besoins utilisateurs et ne pas tomber dans le travers d'un infocentre
Une tentation contre laquelle mette en garde les spécialistes des entrepôts de données qui consiste à vouloir bâtir à la direction informatique son propre entrepôt de données en partant des solutions existantes. Si cela peut apparaître comme une bonne solution pour tester à moindre coût les enjeux de l'intégration de données multiples, il n'en est rien en pratique.
"Concevoir un système commence par l'analyse des besoins utilisateurs. A partir de là, on en déduit ce qui doit figurer dans les datamarts, puis par voie de conséquence ce qu'il y aura dans l'entrepôt de données et enfin les flux à construire. Le décisionnel satisfait des requêtes et se tourne vers l'utilisateur. Si l'informatique se constitue son propre infocentre, cela conduit à calculer de mauvais indicateurs qui en bout de chaîne ne seront pas utilisés par les directions métiers, soit un échec pour tout le monde", explique Guy Piquard.
4- Découper le projet en lots
"De tout temps, les premiers écueils du décisionnel ont été les projets pharaoniques. Nous sommes revenus à des démarches itératives avec le temps. Je dirais même que l'effet itératif est de plus en plus court. Dorénavant, l'entreprise ne vise que quelques indicateurs, des sous domaines dans le domaine. Il faut se focaliser sur les éléments à fort ROI pour générer de l'engouement. Cela revient à sélectionner un métier, prendre un sous groupe d'utilisateur et leur bâtir un datamart pour le pilotage des achats par exemple", annonce Frédéric Dardant.
L'autre atout de cette démarche vient du fait qu'elle étale le projet et donc les coûts dans le temps. Elle offre aussi une visibilité à court terme sur les bénéfices que peut apporter un entrepôt de données. Le danger sera de perdre de vue les autres lots et de partir ainsi sur une application isolée et non évolutive.
5- Prévoir une plate-forme évolutive dans le temps
Que ce soit pour le matériel, le logiciel ou encore le modèle de données : le chef de projet ne doit pas perdre de vue l'ensemble de ces lots et la croissance exponentielle de la base décisionnelle. Il faut donc modéliser une plate-forme de données pour qu'elle soit évolutive. Le macro modèle constitue la base du projet sur lequel les lots seront construits. L'estimation du volume doit être la plus précise possible tout en s'accordant une marge d'erreur appréciable.
A prévoir également : les canaux d'utilisation et la localisation des utilisateurs. Ces informations conditionnent pour partie la consommation d'espace disque, de bande passante et le besoin d'efficacité des requêtes. De même, il est conseillé de garder à l'esprit qu'un historique des données et donc une redondance des données seront de mises dans l'entrepôt de données. "Lors de l'étude, il faut tenir compte de la rémanence des données, de l'optimisation des accès aux données, du partitionning avec par exemple des index locaux ou encore la possibilité de monter et démonter des partitions sur ses disques pour améliorer physiquement les temps d'accès aux données", ajoute Guy Piquard.
6- Préférer une nomenclature unique imposée par l'équipe projet
Dès lors que les sources d'informations sur lesquelles reposent l'entrepôt de données s'avèrent multiples, va se poser le problème de la sémantique des données et de la sémantique des nomenclatures. "Il faut mettre les maîtrises d'ouvrage autour de la table et se mettre d'accord sur la définition transverse commune pour une donnée, que ce soit le nombre de ventes ou le chiffre d'affaires, le nombre de contrats ou le nombre de clients. Pour chacun de ces choix, la donnée extraite aura un sens différent", analysent les deux hommes de Sopra Group.
"A chaque fois, c'est une question de cas particulier. Soit on choisit une base maître, et les autres bases deviennent esclaves de son modèle, soit l'entrepôt de données devient la base maître. Le premier cas est la solution la plus facile à mettre en uvre mais s'avère le pire des choix. Si l'entrepôt est connecté à 20 sources différentes, il faudra en permanence réaliser des évolutions fonctionnelles pour les applications. Au contraire, dans la deuxième solution les applications sources peuvent évoluer à leur rythme mais choisir un nouveau référentiel maître représente un casse-tête", note Guy Piquard.
7- Changer sa façon de penser la base de données
Un entrepôt de données diffère largement d'une modélisation en "troisième forme normale" (principe de jointure entre les tables d'une base) où l'objectif consiste à représenter une donnée qu'une seule fois dans le modèle. Cette conception traditionnelle implique de fortes relations entre les tables et engendre des liens coûteux en temps pour les requêtes, à la différence de la structure d'entrepôt qui favorise la multiplication des données.
L'optimisation du temps de traitement passe par la constitution de datamarts. Ces structures sont conçues spécialement pour répondre à des besoins métiers d'un sous groupe de l'entreprise en regroupant sous une même table les informations souhaitées par les directions métiers.
Reste le risque de construire des tables fourre-tout ou de multiplier la création de datamarts au détriment de l'espace disque. Il faut alors redécouper l'entrepôt et repenser ses index pour faire chuter les temps de traitements.
8- Charger une équipe de l'évolution de l'entrepôt
Une fois l'entrepôt construit, une structure dédiée sera chargée de le faire vivre. Sa mission consiste aussi bien à faire évoluer les indicateurs, la nomenclature et les applications. "L'appétit vient en mangeant. Les directions métiers imaginent vite d'autres indicateurs combinés ce qui fait grossir régulièrement la base. L'idéal serait de mettre en place un processus de recueil des besoins et de livrer tous les trois mois une nouvelle version de l'entrepôt de données. La création de nouvelles applications décisionnelles reste guidée par la maîtrise d'ouvrage", concluent les deux hommes de Sopra Group.
|
Dossier 
