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.

4 commentaires:

Serge a dit…

Bonjour,
La solution pack performance semble dédiée au métier de la logistique.

Est ce que qu'il est envisageable de l'adapter à d'autre domaine tel que la gestion commerciale.

A Quels segments de marché peut être adressée cette solution : grand compte, PME, TPE, ...

Jean-Marc DUPONT a dit…

Le pack Performance est dédié aux métiers de la Supply chain (logistique et transport).
Ses principes sont adaptables à n'importe quel métier, sous réserve d'avoir la connaissance de ce métier et de ses indicateurs pertinents.
La solution (le budget) est adaptée aux PME, à partir d'une certaine taille afin de pouvoir rentabiliser la solution, et est bien sûr également adaptée aux grands comptes.

jeremy a dit…

"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"

N'est ce pas la base que de ne pas utiliser, pour la BI, le même modèle de données que le modèle de production?

Jean-Marc DUPONT a dit…

Le principe de base est effectivement de construire un modèle (et une base de données) dédiés à l'analyse de données, ce modèle et cette base constituant aussi un référentiel de données unique pour l'entreprise.
Mais Qlikview construit son propre modèle de données (et sa base sous forme de fichiers), basés sur les requêtes définies par l'utilisateur (assez souvent un prestataire de services ou la DSI).
Et la "base de données" Qlikview est propriétaire et pas ou difficilement exploitable par un outil tiers, à la différence d'une base de données décisionnelle.
Et donc, si on ne prend pas garde de construire un modèle et une base de données intermédiaire entre les données de production et la base Qlikview, on risque de perdre la flexibilité et la valeur ajoutée d'un véritable système décisionnel.
(cf. http://blog.6it.fr/2010/10/un-outil-decisionnel-disponible-en.html)

Enregistrer un commentaire