Discussion :

[Geo55]

Merci Feyrehr pour ta contribution.

Nous sommes justement en pleine réflexion au sein de mon entreprise quant à conserver nos outils Business Objects (actuellement en XI R2) en migrant vers la nouvelle version de BO (XI 3 ou BI 4), ou bien passer à Qlikview.

Il nous faut peser le pour et le contre, mais surtout voir si Qlikview apporte quelque chose de plus qu'à BO. Je me posais justement la question de la restitution de données, qui est pour moi est très importante en cas d'abandon de BO.

Qu'entends tu Feyrehr par reporting de masse ?
Le gérant d'une société d'intégration m'a bien expliqué qu'il était tout à fait possible de réaliser des rapports.

Pour te répondre par rapport à l'ETL, evidemment nous ne souhaitons modéliser qu'une partie des données de notre ERP et que nous avons ciblées. Au niveau modélisation, j'ai retenu que chaque table doit avoir un champ commun avec une autre pour être relier, et ceci sans faire de boucle -> obligation de modèle en étoile donc manque de flexibilité à mon avis...

En revanche, là ou un ETL est très intuitif par une gestion graphique des règles d'alimentation et jobs, l'association des données dans Qlikview nécessite un peu de scripting, lorsqu'on souhaite lier 2 champs qui ne sont pas commun par exemple

Si quelqu'un a un retour à faire sur les nécessités de développement qu'implique Qlikview, n'hésitez pas.

Au niveau architecture, c'est une solution tout en un, au niveau restitution, ETL et base de données tout est intégrer. Ce qui nous affranchit des coûts de licences liés à BO, l'ETL Data integrator et la base Oracle pour stocker notre entrepôt.

Nos études portant sur les coûts de licences et maintenance nous a permis de voir qu'une solution Qlikview serait rentable au bout de 2 ans par rapport à BO, où les licences ne sont pas données

Ca fait réfléchir...

[luatwork]

effectivement, il est possible de créer des rapports avec Qlikview, mais on perd l'intérêt principal de l'outil, qui est de pouvoir cliquer (et voir) pour pousser son analyse plus loin qu'une simple photo.
a mes yeux, un reporting n'est qu'une photo, un instantané, qui donne une vue directe pour une situation, comme par exemple le meilleur employé du mois, respect de SLA sur une durée définie...
un tableau de bord, tel que peut donner Qlikview correspond à un tableau de bord (oui, je sais, facile...) d'un véhicule : une action sur un quelconque levier/bouton/pédale... modifiera cette vue, et donc la réflexion. par exemple, tu appuies sur la pédale d’accélérateur, tu roules plus vite, ton analyse portera sur "ma vitesse est elle dans la limite autorisée ?"

personnellement, j'utilise Qlikview pour ces besoins, et Crystal Reports pour le reporting (que je sors directement en PDF, pour affichage)

ensuite, sur la notion de coûts, il est important de prendre en compte le disponibilité quasi immédiate des applis développées, et la facilité d'utilisation
là où tu pouvais attendre des mois pour avoir un résultat, ton appli QV pourra être distribuée très rapidement, même si elle n'est pas complète
en terme d'utilisation, peu de formation, donc un gain immédiat : ton utilisateur sait cliquer ? bah il est formé, suivant !
tu verras aussi que le nb de fichiers Excel qui transite va considérablement baisser...

il est clair par contre, qu'en terme de développement, il faut aussi revoir sa façon de penser : on est loin du modèle de données Merise... et il est facile de se retrouver avec une boucle, à cause de ce maudit Merise !...

bon courage
A+
Lulu

[Geo55]

Merci à toi pour ta contribution

Je suis d'accord les analyses Qlikview ressemble tout à fait au tableau de bord de ta voiture.

Depuis mon dernier message, nous avons eu une démonstration Qlikview dans laquelle j'ai invité une utilisatrice pilote du service commercial : elle a été plutôt séduite par son utilisation.

Quand à ta remarque sur Crystal Reports, tu préconises donc de conserver des outils BO en complément à QV ? Si tu peux donner ton avis ça peut être interessant. Car certaines entreprises sont très satisfaites de QV mais possède également des outils BO en complément.

La modélisation est la partie qui me fait peur : je ne sais pas ce que va donné notre modèle là-dedans mais bon un intégrateur m'a fait un retour sur ce modèle me disant qu'il est tout à fait intégrable en 3 jours dans leur offre de prototytage !

Alors là, coup de chapeau à ces messieurs s'ils permettent en 3 jours d'être opérationnel et autonome sur tes analyses.

Et niveau coûts encore une fois, QV frappe fort et reste indéniablement moins cher que les licences BO.

[FxIzeL]

Quand à ta remarque sur Crystal Reports, tu préconises donc de conserver des outils BO en complément à QV ? Si tu peux donner ton avis ça peut être interessant. Car certaines entreprises sont très satisfaites de QV mais possède également des outils BO en complément.

Nous avons la même philosophie chez nous. Les rapports qui vont aller en atelier (version papier) sont développés en Crystal Reports et permet ainsi de réponde à un autre besoin que Qlikview et aussi économiser des licences.

[scheu]

Je rejoins les avis positifs précédemment évoqués

Le seul bémol que je citerais est côté administration système pour le service informatique.
Qlikview extrait en effet les données des bases pour les stocker localement sur le serveur d'appli Qlikview, et ensuite les monter en mémoire pour les restituer aux utilisateurs dans les rapports.
Bien que Qlikview compresse les données, les grosses volumétries manipulées nécessitent d'avoir quand-même beaucoup de RAM (on a chez nous des serveurs de 32 Go de RAM et ça commence à faire juste) donc attention à bien dimensionner son serveur ou à prévoir des slots disponibles pour ajouter de la RAM
C'est le prix à payer pour avoir des résultats rapides et fluides à chaque clic (normal les données sont en mémoire).

Alors que BO par exemple interroge la base, donc les requêtes, bien que plus longues à s'exécuter, permettent de manipuler des très grosses volumétries.
Avec un décisionnel de 500 Go, en gros Qlikview est limite, ou alors il faut faire des tables aggrégées et n'attaquer que ces tables pour réduire la volumétrie

Dire que Qlikview est plus performant en temps de réponse que BO, c'est logique car c'est oublier que le serveur Qlikview coûte bien souvent beaucoup cher que le serveur BO
Sinon pour le côté utilisation, facilité de prise en main, je trouve effectivement Qlikview beaucoup mieux que BO

[PhunkyBob]

Dire que Qlikview est plus performant en temps de réponse que BO, c'est logique car c'est oublier que le serveur Qlikview coûte bien souvent beaucoup cher que le serveur BO

Vous vouliez dire que QlikView est plus cher que BO ?
Je ne crois pas, non...


J'entends beaucoup de personnes essayer de comparer QlikView à BO, à tort. Pire, j'ai des clients qui veulent refaire ce qu'ils ont dans BO avec QlikView "parce que QlikView ça coute moins cher et c'est plus rapide".

C'est une grosse erreur de raisonner comme ça !

Comme l'a déjà dit Feyrehr, QV est un outil d'analyse et BO un outil de reporting.
En gros, BO va être parfait pour imprimer un état à un instant T, avec un certain contexte.
QV va permettre de rechercher une information en donnant une interface conviviale pour changer dynamiquement le contexte. En gros, on va tourner / zoomer sur une mesure, jusqu'à ce qu'on trouve les informations qu'on recherche.
Il permet aussi de présenter de manière très visuelle les données, et il se trouve que c'est plutôt simple à faire.

L'utilisation finale n'est pas vraiment la même, mais beaucoup de personnes font l'amalgame...

Si on écoute les commerciaux, BO est capable de faire de l'analyse, et QV est capable de faire du reporting.
Dans les fait, c'est à moitié vrai, car la tâche sera assez contraignante...
Vous n'aurez jamais de temps de réponse correcte avec une analyse faite avec un BO, et vous aurez du mal à faire des tableaux aux petits oignons avec QV (gestion des ruptures, etc...).


Pour ce qui est de la modélisation, toujours la même erreur est commise : essayer de refaire ce qu'on a déjà ailleurs (généralement un modèle relationnel) avec QlikView (avec un modèle associatif).


Pour répondre au fait que "Microsoft se fait bouffer", il faut voir que la nouveauté de QV, c'est de faire une analyse associative basée sur un modèle vectoriel, le tout passé en mémoire. Ca fait 19 ans que le produit existe (on est à la version 11) et est fait pour fonctionner comme ça. Même si dans un premier temps, ce n'était pas top (la mémoire coutait super cher il y a 20 ans !), QlikTech a une sacrée avance par rapport à ses concurrents qui ne s'intéressent à cette architecture que depuis récemment. Microsoft a beau être Microsoft, c'est chaud de rattraper 20 ans d'expérience en si peu de temps.
Mais je ne doute pas qu'ils y arrivent un jour.


Pour répondre à la question de "c'est quoi un modèle vectoriel", pour résumer :

Dans un modèle de BDD traditionnel, si j'ai une table "Villes" qui contient des villes et des pays, je vais avoir ça :




Une fois modélisé, je me rends compte que ça prend de la place, car pour chaque ligne de "Ville", je perds 32 octets pour stocker le pays.
J'ai 6 fois "France", j'ai donc 6 * 32 octets de monopolisés.
Comme je me souviens de mes cours de SGBDR, je transforme mon modèle comme ça :




J'optimise énormément la taille de ma base et il me suffit de faire des relations entre les identifiants (champ "Pays_PK" et "Pays_FK") pour connaitre le pays (format chaine) correspondant à une ville.
Je n'ai plus qu'1 seule fois "France" = 1 * 32 octets et 6 entiers qui servent d'identifiant = 6 * 1 octet.
Pour simplifier, on va considérer que le stockage des entiers est négligeable, donc notre base de données va être considérablement allégée, car rien que la table des pays est divisée par 6 en taille !


Or, si je charge ma première table (celle qui contient les chaines de la ville et du pays dans la même table), le modèle vectoriel de QV va stocker comme ça en mémoire :



même si tout vient de (et va dans) la même table !

Donc au niveau place, encore une fois, on fait beaucoup d'économie.


Niveau place, on gagne un peu par rapport au modèle relationnel (pas besoin de gérer les identifiants qui servent de clé), mais surtout, niveau compréhension du modèle, c'est carrément plus simple (car QV l'affichera comme le premier tableau) !

En plus, si QV n'a pas de relation a géré (données dans 2 tables différentes), alors ses calculs seront d'autant plus efficaces.


Voilà, j'espère que ça répond un peu à la question...



Personnellement, je fais du décisionnel depuis plusieurs années, j'ai fait beaucoup de BO puis beaucoup de Cognos, mais depuis que j'ai découvert QlikView (version 8.5), j'ai tout fait pour ne travailler que sur cette techno.

Pour moi (en tant que consultant / expert QV qui gagne sa vie avec cet outil), le seul "défaut" de QV c'est qu'on fait les choses trop facilement et trop rapidement, donc on a du mal à facturer beaucoup de jours quand il n'y a pas grand chose à faire
Installation d'un environnement en 1 journée, développement d'un projet moyen en quelques jours, ...
Alors qu'avec un BO, si vous annoncez à votre client qu'il vous faut plusieurs jours de développement pour rajouter 1 dimension et modifier 1 graph du reporting, ça ne le choquera pas du tout.

[TomDuBouchon]

... Alors qu'avec un BO, si vous annoncez à votre client qu'il vous faut plusieurs jours de développement pour rajouter 1 dimension et modifier 1 graph du reporting, ça ne le choquera pas du tout.

J'en prends bonne note Non faut peut-être pas exagérer quand même. Ca prend plus de temps, oui, mais pas à ce point

En tout cas, merci pour toutes ces informations, qui sont très intéressantes.

[BigData]

Bonjour Ensiaste2006,

Es-tu sûr du numéro de la revue 01 Informatique...car je n'ai pas trouvé l'article .

A +