Rappelons d'abord les principes de ces nouveaux outils :
L'affichage des données n'est plus figé et conditionné à l'envoi de requêtes à une base de données (relationnelle ou OLAP) mais tout ou partie des données est chargée en mémoire (du poste client et/ou du serveur), ce qui donne une grande réactivité aux tableaux de bord et une interactivité qui permet d’accélérer l'analyse et la prise de décision.Tout ou partie des axes d'analyse (ou des dimensions) est disponible pour l'utilisateur, qui va pouvoir progressivement raffiner son analyse.
Un indicateur va pouvoir être analysé selon l'ensemble de ses axes d'analyse, à la demande.Les tableaux de bord / graphiques / tableaux sont interactifs : un clic sur une zone d'un graphique va permettre de zoomer (descendre dans le détail) sur une donnée ou filtrer les informations sur cette donnée
Associée à la disponibilité des données en mémoire, ceci permet à l'utilisateur d'analyser très rapidement ses informations et identifier les problèmes / axes d'améliorationDes fonctions de simulation sont fournies qui permettent de faire varier un ou plusieurs paramètre et analyser en temps réel leur impact sur les autres indicateurs
En dehors de Qlikview, je travaille aujourd'hui avec la solution Digdash et j'ai voulu faire un comparatif entre les 2 outils qui se rapprochent assez en termes de fonctionnalités.
Je me suis également appuyé sur les compétences d'un partenaire intégrateur de Qlikview pour valider certains points de Qlikview que je ne connaissais pas forcément en détail.
L'affichage des données n'est plus figé et conditionné à l'envoi de requêtes à une base de données (relationnelle ou OLAP) mais tout ou partie des données est chargée en mémoire (du poste client et/ou du serveur), ce qui donne une grande réactivité aux tableaux de bord et une interactivité qui permet d’accélérer l'analyse et la prise de décision.Tout ou partie des axes d'analyse (ou des dimensions) est disponible pour l'utilisateur, qui va pouvoir progressivement raffiner son analyse.
Un indicateur va pouvoir être analysé selon l'ensemble de ses axes d'analyse, à la demande.Les tableaux de bord / graphiques / tableaux sont interactifs : un clic sur une zone d'un graphique va permettre de zoomer (descendre dans le détail) sur une donnée ou filtrer les informations sur cette donnée
Associée à la disponibilité des données en mémoire, ceci permet à l'utilisateur d'analyser très rapidement ses informations et identifier les problèmes / axes d'améliorationDes fonctions de simulation sont fournies qui permettent de faire varier un ou plusieurs paramètre et analyser en temps réel leur impact sur les autres indicateurs
En dehors de Qlikview, je travaille aujourd'hui avec la solution Digdash et j'ai voulu faire un comparatif entre les 2 outils qui se rapprochent assez en termes de fonctionnalités.
Je me suis également appuyé sur les compétences d'un partenaire intégrateur de Qlikview pour valider certains points de Qlikview que je ne connaissais pas forcément en détail.
Architecture technique
Il y a tout d'abord une grosse différence en termes d'architecture technique, qui peut être un premier facteur de choix en fonction du contexte de l'entreprise :
Qlikview repose sur une architecture Windows, que ce soit pour son client riche (logiciel Windows) ou ses serveurs applicatifs et Web (Windows Server / IIS)
Ce qui le destine en priorité (mais pas seulement) aux entreprises ayant déployé leur SI sur une architecture Windows
Si Qlikview est déployé sur un serveur Web IIS, les tableaux de bord sont disponibles sur navigateur web (Internet Explorer en priorité, mais aussi Firefox, Chrome et Safari, avec un moins bon rendu)
A noter que toutes les fonctionnalités d'affichage ne sont pas disponibles sur tous les navigateurs Web.
A noter également que Qlikview travaille actuellement sur un client web full HTML qui sera disponible sur les plate-formes mobiles (smartphones et tablettes).Digdash repose sur un serveur applicatif développé en java, fonctionnant par défaut avec Tomcat et Apache comme serveur Web
Le client fonctionne sur un navigateur web moderne (Firefox, Chrome, Safari et Internet Explorer 7, 8 et 9)
L'ensemble est donc déployable au choix sur des serveurs Windows ou Linux et des terminaux Windows, Mac, iPad, Android, ...
Qlikview repose sur une architecture Windows, que ce soit pour son client riche (logiciel Windows) ou ses serveurs applicatifs et Web (Windows Server / IIS)
Ce qui le destine en priorité (mais pas seulement) aux entreprises ayant déployé leur SI sur une architecture Windows
Si Qlikview est déployé sur un serveur Web IIS, les tableaux de bord sont disponibles sur navigateur web (Internet Explorer en priorité, mais aussi Firefox, Chrome et Safari, avec un moins bon rendu)
A noter que toutes les fonctionnalités d'affichage ne sont pas disponibles sur tous les navigateurs Web.
A noter également que Qlikview travaille actuellement sur un client web full HTML qui sera disponible sur les plate-formes mobiles (smartphones et tablettes).Digdash repose sur un serveur applicatif développé en java, fonctionnant par défaut avec Tomcat et Apache comme serveur Web
Le client fonctionne sur un navigateur web moderne (Firefox, Chrome, Safari et Internet Explorer 7, 8 et 9)
L'ensemble est donc déployable au choix sur des serveurs Windows ou Linux et des terminaux Windows, Mac, iPad, Android, ...
Internationalisation
En termes de déploiement international, Digdash est conçu de base pour fonctionner en mode multilingue : l'ensemble des libellés (axes, indicateurs) peut être défini dans diverses langues et s'adapte en fonction de la langue de l'utilisateur. Les libellés des dates varient également en fonction de la langue de l'utilisateur.
Qlikview ne gère pas nativement le multilingue. Il est cependant possible de mettre en place un mécanisme de traduction des libellés dans l'interface en les remplaçant par des fonctions retournant le texte.
Il vaut donc mieux prévoir cela dés le départ et seuls les textes sont traduits, pas les noms des champs ni des tables. On profite donc de la souplesse de l'outil pour compenser en partie une fonctionnalité importante qui manque.
Qlikview ne gère pas nativement le multilingue. Il est cependant possible de mettre en place un mécanisme de traduction des libellés dans l'interface en les remplaçant par des fonctions retournant le texte.
Il vaut donc mieux prévoir cela dés le départ et seuls les textes sont traduits, pas les noms des champs ni des tables. On profite donc de la souplesse de l'outil pour compenser en partie une fonctionnalité importante qui manque.
Gestion des utilisateurs / des droits
Digdash gère les utilisateurs dans un annuaire LDAP embarqué ou dans l'annuaire de l'entreprise.
Les droits sont gérés sur 3 niveaux :
Les autorisations (Afficher un tableau de bord, Editer un tableau de bord, ...) peuvent être attribuées à un utilisateurLes groupes d'autorisations permettent de regrouper des autorisations et les attribuer à un utilisateurLes profils permettent de donner des accès aux sources de données (voir plus loin) et aux graphiques des tableaux de bord
Qlikview peut gérer la sécurité lui même ou se connecter à un annuaire d'entreprise (en gérant utilisateurs ou groupes).
On distinguera :
La sécurité au niveau du portail pour définir qui a accès à quelle application,La sécurité au niveau des fonctions dans l'application (droit de rafraîchir, droit d'exporter...),La sécurité pour la visibilité des éléments (affichage conditionnel des onglets ou des objets),La sécurité des données pour masquer tout ou partie des informations de la base en mémoire, voir pour publier des applications réduites aux seules données autorisées.
Les droits sont gérés sur 3 niveaux :
Les autorisations (Afficher un tableau de bord, Editer un tableau de bord, ...) peuvent être attribuées à un utilisateurLes groupes d'autorisations permettent de regrouper des autorisations et les attribuer à un utilisateurLes profils permettent de donner des accès aux sources de données (voir plus loin) et aux graphiques des tableaux de bord
Qlikview peut gérer la sécurité lui même ou se connecter à un annuaire d'entreprise (en gérant utilisateurs ou groupes).
On distinguera :
La sécurité au niveau du portail pour définir qui a accès à quelle application,La sécurité au niveau des fonctions dans l'application (droit de rafraîchir, droit d'exporter...),La sécurité pour la visibilité des éléments (affichage conditionnel des onglets ou des objets),La sécurité des données pour masquer tout ou partie des informations de la base en mémoire, voir pour publier des applications réduites aux seules données autorisées.
Sources et modélisation des données
Digdash sépare clairement la notion de "Modèle de données" et la visualisation de ces données.
Les modèles de données décrivent :
La source des données (base de données, fichier CSV, Excel, ... mais aussi Rapport Business Objects ou Cognos, Cube OLAP), les dimensions qui y sont définies (avec leurs hiérarchies éventuelles), les indicateurs (bruts, ou calculés à partir des indicateurs bruts),la fréquence de rafraîchissement de ces données.
Ces modèles de données sont ensuite utilisés dans les graphiques ou les tableaux. On définit ici :
le mode d'affichage (courbes, colonnes, camemberts, cartographie, ...),les axes et indicateurs qui y seront affichés, leurs paramètres d'affichage et de navigation (zoom, filtre, ...).
On assemble enfin les graphiques et les tableaux dans les pages du tableau de bord.
On conçoit donc plusieurs modèles de données (qu'on pourrait appeler "cubes") élémentaires et indépendants et on les utilise au gré des besoins au sein du tableau de bord.
Le lien entre les différentes sources de données se fera, si besoin, par le nom des axes d'analyse communs aux sources de données.
La conception et la maintenance s'en trouvent grandement simplifiées.
Qlikview, quand à lui, va un peu loin dans la partie alimentation des données, à l'aide d'un langage propriétaire de scripting.
Les relations entre les données sont faites principalement par le nom des "colonnes" de chaque "table" ou requête. L'unicité des noms des colonnes dans le modèle doit être assuré ou résolu à l'aide d'alias.
Pour des modèles de données sources complexes, le script à écrire peut vite représenter plusieurs pages, qu'il faudra bien prendre garde de commenter sous peine de maintenance difficile.
Le schéma des données ainsi constitué définit la source des futurs graphiques et tableaux de bord. On ne définit pas à ce niveau les colonnes qui constitueront les axes (dimensions) et les indicateurs. Cela devra être fait dans chaque objet du tableau de bord.
De même, les éventuels indicateurs calculés devront être dupliqués s'il y a besoin de les afficher dans plusieurs graphiques ou tableaux.
A noter que les formules de calculs utilisées dans les graphiques ou tableaux peuvent être mutualisées sous forme de variable (un peu à la façon de macro). C'est là aussi profiter de la souplesse du produit mais ce n'est pas une fonctionnalité mise en avant.
Les modèles de données décrivent :
La source des données (base de données, fichier CSV, Excel, ... mais aussi Rapport Business Objects ou Cognos, Cube OLAP), les dimensions qui y sont définies (avec leurs hiérarchies éventuelles), les indicateurs (bruts, ou calculés à partir des indicateurs bruts),la fréquence de rafraîchissement de ces données.
Ces modèles de données sont ensuite utilisés dans les graphiques ou les tableaux. On définit ici :
le mode d'affichage (courbes, colonnes, camemberts, cartographie, ...),les axes et indicateurs qui y seront affichés, leurs paramètres d'affichage et de navigation (zoom, filtre, ...).
On assemble enfin les graphiques et les tableaux dans les pages du tableau de bord.
On conçoit donc plusieurs modèles de données (qu'on pourrait appeler "cubes") élémentaires et indépendants et on les utilise au gré des besoins au sein du tableau de bord.
Le lien entre les différentes sources de données se fera, si besoin, par le nom des axes d'analyse communs aux sources de données.
La conception et la maintenance s'en trouvent grandement simplifiées.
Qlikview, quand à lui, va un peu loin dans la partie alimentation des données, à l'aide d'un langage propriétaire de scripting.
Les relations entre les données sont faites principalement par le nom des "colonnes" de chaque "table" ou requête. L'unicité des noms des colonnes dans le modèle doit être assuré ou résolu à l'aide d'alias.
Pour des modèles de données sources complexes, le script à écrire peut vite représenter plusieurs pages, qu'il faudra bien prendre garde de commenter sous peine de maintenance difficile.
Le schéma des données ainsi constitué définit la source des futurs graphiques et tableaux de bord. On ne définit pas à ce niveau les colonnes qui constitueront les axes (dimensions) et les indicateurs. Cela devra être fait dans chaque objet du tableau de bord.
De même, les éventuels indicateurs calculés devront être dupliqués s'il y a besoin de les afficher dans plusieurs graphiques ou tableaux.
A noter que les formules de calculs utilisées dans les graphiques ou tableaux peuvent être mutualisées sous forme de variable (un peu à la façon de macro). C'est là aussi profiter de la souplesse du produit mais ce n'est pas une fonctionnalité mise en avant.
Visualisation des données
Les possibilités de paramétrage offertes par Qlikview sont beaucoup plus riches que celles de Digdash. On sent que le logiciel a pas mal d'années d'expérience et que les paramètres ont été ajoutés au fur et à mesure.
Ils sont répartis dans une dizaine d'onglets.
Le logiciel aurait à mon avis besoin d'un nettoyage car il n'y a pas toujours de logique dans le positionnement des paramètres dans les onglets et en fonction du graphique utilisé, le choix des paramètres est tellement riche qu'on ne sait plus trop quel paramètre choisir pour réaliser le besoin. On s'habitue petit à petit mais la prise en mains s'en trouve ralentie.
Digdash, au contraire, est plus simpliste : il lui manque certains paramètres mais c'est en contrepartie la garantie d'une productivité plus grande et d'une prise en mains plus rapide.
Les 2 outils proposent des listes permettant de filtrer les données sur les différents axes d'analyse disponibles dans le modèle. Ces listes sont positionnables dans les pages.
Digdash propose également, par défaut, d'afficher les listes dans une "barre de filtres", en haut de la page. Les filtres affichés dans cette barre sont paramétrables. Si une hiérarchie a été définie sur l'axe d'analyse (ex : année / mois / jour), les différents niveaux d'analyse sont disponibles sur une même liste.
Il est également possible, dans Digdash, de spécifier un filtre pour chaque objet graphique ou tableau, qui sera utilisé à lors du premier affichage de la page, libre ensuite à l'utilisateur de modifier le filtre.
Il n'y a pas d'équivalence dans Qlikview car tous les objets sont liés entre eux donc filtrés ensemble (sauf exception car on peut verrouiller des objets simplement ou utiliser les fonctions de filtrage : cf. ci dessous)
La comparaison de 2 membres d'un même niveau de hiérarchie (ex : mois M vs mois M-1), passe dans les 2 cas par la création d'indicateurs calculés :
dans Digdash, cela se fait à l'aide d'un assistant graphique qui permet de définir le filtre pour chaque indicateur calculé (=> "mois M" = mois en cours, "mois M-1" = mois en cours - 1)dans Qlikview, cela se fait à l'aide d'une syntaxe de formule (les fameux "set analysis"), qui n'est pas triviale et peut rapidement devenir difficilement maintenable
Par exemple (cas très simple) : Sum({$<cpt_mois={"-1"}>} CA)
Digdash intègre un graphique cartographique, lié à une dimension hiérarchique de type géographie (ex : Département, Région, Pays), que l'on paramètre en reliant chaque niveau de la hiérarchie à un niveau de la cartographie.
La carte est de fait interactive : elle permet de zoomer par exemple sur un pays, d'afficher le détail par région, puis par département d'une région.
Qlikview passe par une intégration de cartes Google Maps, sur lesquelles on affiche des symboles, plus ou moins gros ou de couleurs différentes en fonction de la valeur d'un indicateur.
Il est également possible de zoomer sur la carte et on peut aussi mettre en place un système de choix de la granularité (département, région, pays, ...), mais avec Google Maps ce dernier mécanisme demande un peu de travail préparatoire et ici encore c'est la souplesse du produit qui le permet mais pas une fonctionnalité native.
Il existe également des solutions externes telles que celle proposée par GeoQlik, par exemple, qui propose plus de fonctionnalités mais est un module payant, venant ainsi alourdir la facture.
Enfin, les 2 outils fournissent des fonctions de simulation, en définissant des variables, qui vont entrer dans le calcul d'indicateurs calculés, ces indicateurs étant ensuite affichés dans des graphiques ou tableaux.
La seule différence sur ce point est que la définition des variables et indicateurs calculés va se faire, pour Digdash, dans les sources de données et être utilisé dans un ou plusieurs graphiques ou tableaux, alors que pour Qlikview, la définition des indicateurs calculés va se faire dans chaque graphique / tableau qui doit afficher cet indicateur.
Un des avantages de Qlikview aujourd'hui réside dans sa fonction de recherche dans les axes d'analyse, que ne propose pas Digdash. Mais j'ai cru comprendre que cette fonction était dans la roadmap de Digdash, reste à savoir comment elle va être implémentée ...
Ils sont répartis dans une dizaine d'onglets.
Le logiciel aurait à mon avis besoin d'un nettoyage car il n'y a pas toujours de logique dans le positionnement des paramètres dans les onglets et en fonction du graphique utilisé, le choix des paramètres est tellement riche qu'on ne sait plus trop quel paramètre choisir pour réaliser le besoin. On s'habitue petit à petit mais la prise en mains s'en trouve ralentie.
Digdash, au contraire, est plus simpliste : il lui manque certains paramètres mais c'est en contrepartie la garantie d'une productivité plus grande et d'une prise en mains plus rapide.
Les 2 outils proposent des listes permettant de filtrer les données sur les différents axes d'analyse disponibles dans le modèle. Ces listes sont positionnables dans les pages.
Digdash propose également, par défaut, d'afficher les listes dans une "barre de filtres", en haut de la page. Les filtres affichés dans cette barre sont paramétrables. Si une hiérarchie a été définie sur l'axe d'analyse (ex : année / mois / jour), les différents niveaux d'analyse sont disponibles sur une même liste.
Il est également possible, dans Digdash, de spécifier un filtre pour chaque objet graphique ou tableau, qui sera utilisé à lors du premier affichage de la page, libre ensuite à l'utilisateur de modifier le filtre.
Il n'y a pas d'équivalence dans Qlikview car tous les objets sont liés entre eux donc filtrés ensemble (sauf exception car on peut verrouiller des objets simplement ou utiliser les fonctions de filtrage : cf. ci dessous)
La comparaison de 2 membres d'un même niveau de hiérarchie (ex : mois M vs mois M-1), passe dans les 2 cas par la création d'indicateurs calculés :
dans Digdash, cela se fait à l'aide d'un assistant graphique qui permet de définir le filtre pour chaque indicateur calculé (=> "mois M" = mois en cours, "mois M-1" = mois en cours - 1)dans Qlikview, cela se fait à l'aide d'une syntaxe de formule (les fameux "set analysis"), qui n'est pas triviale et peut rapidement devenir difficilement maintenable
Par exemple (cas très simple) : Sum({$<cpt_mois={"-1"}>} CA)
Digdash intègre un graphique cartographique, lié à une dimension hiérarchique de type géographie (ex : Département, Région, Pays), que l'on paramètre en reliant chaque niveau de la hiérarchie à un niveau de la cartographie.
La carte est de fait interactive : elle permet de zoomer par exemple sur un pays, d'afficher le détail par région, puis par département d'une région.
Qlikview passe par une intégration de cartes Google Maps, sur lesquelles on affiche des symboles, plus ou moins gros ou de couleurs différentes en fonction de la valeur d'un indicateur.
Il est également possible de zoomer sur la carte et on peut aussi mettre en place un système de choix de la granularité (département, région, pays, ...), mais avec Google Maps ce dernier mécanisme demande un peu de travail préparatoire et ici encore c'est la souplesse du produit qui le permet mais pas une fonctionnalité native.
Il existe également des solutions externes telles que celle proposée par GeoQlik, par exemple, qui propose plus de fonctionnalités mais est un module payant, venant ainsi alourdir la facture.
Enfin, les 2 outils fournissent des fonctions de simulation, en définissant des variables, qui vont entrer dans le calcul d'indicateurs calculés, ces indicateurs étant ensuite affichés dans des graphiques ou tableaux.
La seule différence sur ce point est que la définition des variables et indicateurs calculés va se faire, pour Digdash, dans les sources de données et être utilisé dans un ou plusieurs graphiques ou tableaux, alors que pour Qlikview, la définition des indicateurs calculés va se faire dans chaque graphique / tableau qui doit afficher cet indicateur.
Un des avantages de Qlikview aujourd'hui réside dans sa fonction de recherche dans les axes d'analyse, que ne propose pas Digdash. Mais j'ai cru comprendre que cette fonction était dans la roadmap de Digdash, reste à savoir comment elle va être implémentée ...
Conclusion
On se rend compte que les 2 outils sont assez proches en termes de fonctionnalités mais diffèrent sur quelques points majeurs :
L'architecture technique : plus ouverte pour Digdash que pour QlikviewL'internationalisation : native chez Digdash, disponible chez Qlikview en le prévoyant dés le départ et en développant les fonctionnalités à l'aide de son langage de scriptingStructuration des développements : - chez Digdash : Séparation claire de la partie Modèle de données (incluant la définition des axes d'analyse et des indicateurs) et de la partie Visualisation des données
- chez Qlikview : partie alimentation des données plus riche (attention à la maintenance) mais nécessité de définir dans chaque graphique / tableau quelle colonne est un axe ou un indicateur et risque de dupliquer les règles de calcul des indicateurs calculés
Visualisation des données : palette de types d'affichage et de paramètres beaucoup plus riche (trop ?) chez Qlikview, en contrepartie prise en mains et productivité plus grande sur Digdash
En termes de prise en main par les utilisateurs des entreprises, je dirais que si un travail de préparation, structuré et rigoureux, a été mené par les équipes techniques, Qlikview est un outil très riche en fonctionnalités et simple de prise en main.
Digdash, quand à lui, est plus frustre en termes de fonctions graphiques, mais sa structuration et ses fonctions natives et assistées permettent de monter une plate-forme de manière très productive voire de déléguer aux utilisateurs une bonne partie de l'architecture (modèles axes d'analyse / indicateurs notamment).
L'architecture technique : plus ouverte pour Digdash que pour QlikviewL'internationalisation : native chez Digdash, disponible chez Qlikview en le prévoyant dés le départ et en développant les fonctionnalités à l'aide de son langage de scriptingStructuration des développements : - chez Digdash : Séparation claire de la partie Modèle de données (incluant la définition des axes d'analyse et des indicateurs) et de la partie Visualisation des données
- chez Qlikview : partie alimentation des données plus riche (attention à la maintenance) mais nécessité de définir dans chaque graphique / tableau quelle colonne est un axe ou un indicateur et risque de dupliquer les règles de calcul des indicateurs calculés
Visualisation des données : palette de types d'affichage et de paramètres beaucoup plus riche (trop ?) chez Qlikview, en contrepartie prise en mains et productivité plus grande sur Digdash
En termes de prise en main par les utilisateurs des entreprises, je dirais que si un travail de préparation, structuré et rigoureux, a été mené par les équipes techniques, Qlikview est un outil très riche en fonctionnalités et simple de prise en main.
Digdash, quand à lui, est plus frustre en termes de fonctions graphiques, mais sa structuration et ses fonctions natives et assistées permettent de monter une plate-forme de manière très productive voire de déléguer aux utilisateurs une bonne partie de l'architecture (modèles axes d'analyse / indicateurs notamment).