OLAP, vous avez dit OLAP ?

Le titre est une vraie question. En effet, je me suis rapidement rendu compte qu’au-delà du reporting (rapports PDF ou Excel, avec ou sans graphique, avec une interactivité limitée), la palette d’outils décisonnels mis à disposition des employés en entreprise est très limitée, voire inexistante.

Pour rentrer dans le vif du sujet et d’un point de vue utilisateur, la technologie OLAP souvent appelée « cube OLAP », pourrait être comparée à un tableau croisé dynamique (TCD) mais en mieux, comparaison évidemment limitée au vue de la puissance d’un outil OLAP.

Un cube OLAP permet donc de naviguer parmi des données numériques selon des axes d’analyse appelées « dimensions ». La navigation consiste principalement à passer d’un niveau d’agrégation à un autre, en passant par exemple d’un tableau par année au même tableau présentant le même indicateur mais détaillé sur les mois. Concernant les dimensions, elles permettent d’observer le ou les indicateurs au croisement des dimensions choisies par l’utilisateur. Les données de l’activité de l’entreprise sont donc enfin accessibles, manipulables librement par l’utilisateur selon toutes les combinaisons de dimensions possibles.

Cube OLAP et Tableau Croisé Dynamique

A ce stade, on peut légitimement se demander la différence avec un bête TCD disponible dans tout bon tableur. Il y a évidemment des différences :

– le cube OLAP permet de visualiser un volume de données plus conséquent qu’avec un TCD principalement par le fait qu’il s’appuie soit sur une base de données (chargement des données utiles seulement, utilisation d’index), soit mieux, sur un fichier précalculé (appelée base multidimensionnelle). Le mieux étant de choisir et/ou combiner différentes techniques selon les cas, sachant que l’on peut aussi sous-traiter une partie des traitements en local.

– montée en charge : par rapport au point précédent, il faut reconnaître que c’est plutôt lors de la montée en charge que le problème de capacité et de performance s’observe. Avec un TCD, si ses données augmentent sans cesse, le problème c’est qu’un jour on se retrouve devant un mur. Avec un cube OLAP, il y a des techniques pour optimiser l’accès aux données et continuer à obtenir des temps de réponses satisfaisants.

– le cube OLAP respecte le principe SVOT, tant recherché en Business Intelligence, SVOT signifiant Single Version of the Truth, une seule version de la vérité. Combien de fois en réunion, chacun ramenant son TCD, on se retrouve avec des valeurs de CA différentes pour le même mois ou la même semaine ? Chacun ayant bidouillé son extraction de données, on ne sait plus de quoi on parle. Ce qui nous amène, nous, à parler de la …

– … sécurité, inexistante dans un TCD ! Aucune garantie de la fraîcheur des données, aucun contrôle des fuites de données (TCD oubliés sur une clé USB, etc). Alors qu’avec un cube OLAP, l’accès est contrôlé, la sécurité peut aussi se définir à la cellule, les données sont actualisées régulièrement (pas de vieilles versions qui traînent).

– la mise en œuvre : dans le cas d’un TCD, il faut réaliser la collecte/extraction des données, concevoir le tableau puis naviguer pour réaliser l’analyse. Avec un cube OLAP, les deux premières étapes font partie des traitements de données de la cellule infocentre, l’utilisateur n’a plus qu’à naviguer et se concentrer sur son analyse. Il ne fait pas des tâches d’informaticien. Pour la cellule infocentre, la réalisation d’un cube est rentable : chaque développement (dimension, mesure calculée) peut être réutilisé dans plusieurs cubes, ce qui confirme encore plus le principe SVOT, les nomenclatures de l’entreprise (type de clients, zones géographiques, etc.) sont bien les mêmes dans tous les cubes.

– enfin, pour moi, la principale différence est que la visualisation d’un cube OLAP est nécessairement le résultat d’une requête, à la manière du SQL pour une base relationnelle. Ceci sous-entend une syntaxe spécifique aux données multidimensionelles, ici le MDX. Autrement dit, il est impossible avec un TCD de retrouver rapidement différents états de navigation car il n’existe pas de standard. SQL et MDX sont deux standards normalisés et bien employés par les offres logicielles.

Cube OLAP et Reporting

Ceci étant dit, on peut en profiter pour comparer les cubes OLAP au reporting :

– le reporting est statique, aucune souplesse de navigation, au mieux une invite avant l’exécution pour éviter l’affichage de trop de données.

– le reporting permet le traitement de données non numériques (listings) et le calcul d’indicateurs trop complexes.

– un des effets pervers du reporting est, surtout quand il est pré-généré puis mis à disposition sur un portail, la profusion de données disponibles mais paradoxalement inacessibles car trop difficiles à retrouver vue la quantité.

– mais dans OLAP, il y a « O » qui veut dire « online » et la navigation d’un cube se fait souvent en mode connecté même si on peut en partie le contourner (technique D-OLAP).

– l’autre petit point noir d’OLAP par rapport au reporting, c’est de ne pas pouvoir emmener (point précédent) tout un ensemble de données : on navigue, on observe les données d’un point de vue puis on change un axe, on observe puis on continue à progresser dans notre vision. On peut cependant voir cela comme une limitation aux fuites de données.

Ces comparaisons nous ont permis de mettre en lumière les limites du reporting classique et de son pendant pour le contourner « à la main » : le tableau croisé dynamique. Cependant, mon propos n’est pas de dénigrer ces outils mais plutôt d’insister à dire qu’il existe autre chose : la technologie OLAP, pas assez exploitée malgré sa puissance et sa facilité de mise en œuvre (une première maquette peut être réalisée en une demi-journée, installation incluse).

Avantages

Je ne vais pas recopier et détailler ici toutes les fonctionnalités disponibles avec un cube OLAP (slicing, drill-down, drill-through, etc.), de la littérature existe déjà sur le web. Je vais simplement reprendre les avantages déjà abordés.

Un cube OLAP, c’est donc l’accès sécurisé aux données numériques de l’entreprise, permettant leur visualisation selon des axes d’analyse communs à toute l’entreprise. Les indicateurs (ou mesures) peuvent être observées en croisant à volonté les dimensions et à n’importe quel niveau (hiérarchies sur le temps, les zones géographiques, etc.).

Pour l’utilisateur, c’est un outil disponible, simple, facile à utiliser (manipulable à la souris) et garantissant son autonomie. Une fois le cube conçu et validé par tous, la dépendance de l’utilisateur au service informatique diminue très fortement. L’exemple que j’aime donner est celui de l’utilisateur qui présente un tableau en réunion. Un participant veut un détail sur une valeur ou observer l’indicateur par commercial ou usine ? Pas de problème, dynamiquement et en un clic, le tableau évolue pour répondre à la question !

Pour la direction informatique, c’est d’abord l’opportunité de dévoiler un aspect non technique de ses compétences en démontrant sa capacité d’analyse métier et sa rigueur dans le développement. Ensuite, la maintenance est relativement réduite et ce qui a déjà été développé peut servir pour de nouveaux cubes.

Mais … comme dans tout projet décisionnel, il y a trois phases à ne pas louper pour réussir :

1. la phase d’analyse métier, souvent bâclée car on se presse pour avoir un premier cube,

2. la phase de préparation des données : les données doivent être nettoyées mais pourraient l’être en amont (dates farfelues, chaînes de caractères vides, etc.). Et les règles métier sorties de l’analyse métier ne correspondent pas à la réalité (cardinalité, champs obligatoires ou pas, etc.). Dans cette phase, je suis d’avis de proposer rapidement une maquette du cube qui va servir à se rendre compte du besoin mais aussi à nettoyer en amont les données par raffinements successifs. Pour moi, ce travail fait intégralement partie de l’analyse métier, on découvre parfois comment fonctionne réellement son SI !

3. le moment où l’utilisateur se retrouve seul devant son fabuleux cube OLAP … Et c’est là que le bât blesse : le décisionnel est un domaine bien particulier. Il ne suffit pas de former techniquement l’utilisateur à la manipulation ergonomique du cube. Il faut aussi le former à l’analyse des données métier. S’il ne comprend pas ce que le cube lui donne, comment l’exploiter ensuite, comment prendre les bonnes décisions ? Et je ne parle même pas du cas où l’utilisateur va utiliser le cube en réunion mais ne saura pas apporter la valeur ajoutée qualitative face aux chiffres.

Bref, sans maîtrise la puissance n’est rien ! Et c’est précisément là que les experts de Pentalog Institute peuvent vous aider en vous accompagnant lors ces phases délicates, en plus du développement à proprement parler.

Cet article a été rédigé par Ludovic Gilbon, ex Consultant Décisionnel Pentalog Institute