mardi 16 novembre 2010

De la bonne utilisation de Qlikview

Je rebondis sur un très bon article publié sur le site decideo.fr :
DÉCISIONNEL : VERS DE NOUVEAUX MODÈLES DE CONSTRUCTION

En synthèse, il explique pourquoi les projets décisionnels mettent en place des structures de bases de données dédiées à l'analyse et indépendantes des systèmes de production. Et il préconise à juste titre de créer 2 espaces d'analyse : un espace industrialisé et maîtrisé par la DSI, et un espace (que je qualifierais de "bac à sable") dans lequel les directions métier (les utilisateurs) vont pouvoir manipuler à leur guise les données.
Si on applique ce principe à Qlikview, on peut préconiser de mettre en place un datawarehouse (l'espace industrialisé) sur lequel vont s'appuyer les modèles Qlikview développés pour (ou par) les directions métier.

En plus de respecter les principes ci-dessus (et de fournir aux utilisateurs des données contrôlées, nettoyées, ...), cette manière de procéder possède un avantage majeur : les modèles de données construits dans le datawarehouse sont beaucoup plus simples à comprendre que les modèles de données des systèmes de production et donc facilement maîtrisables par les utilisateurs.
Or, aujourd'hui, les modèles de données construits dans Qlikview et basés sur les modèles de données de production sont incroyablement complexes à maintenir et vont à l'encontre du discours de Qlikview comme quoi il permet de laisser la main aux utilisateurs.

Quand je vois le nombre de sociétés de services proposer des offres verticales s'appuyant directement sur les modèles de données des ERP, je me dis qu'il y a péril en la demeure (pour les DSI et à terme pour les utilisateurs).
Loin de moi l'idée de dénigrer l'outil (Qlikview) qui apporte une bouffée d'air dans un domaine qui s'endormait sur ses lauriers et qui apporte un formidable outil aux utilisateurs, mais c'est plutôt la manière de l'utiliser qui me fait peur.

C'est pourquoi la solution que 6 IT commercialise (http://www.6it.fr/pack-performance.htm) utilise Qlikview comme outil de restitution mais repose sur un modèle de données de type décisionnel (tables de fait et tables de dimension) et des jobs d'alimentation (Talend) incluant contrôle et nettoyage des données.
Cela permet par ailleurs de proposer une alternative à Qlikview - Digdash - en tant qu'outil de dashboarding, basé sur le même modèle de données.