Discussion :

[stylor]

Bonjour à tous,

Je suis consultant junior BI et je viens d'intégrer un projet BI chez un de nos clients. L'IT à décidé pour différentes raisons de changer l'architecture actuelle.
Comme technologie il y a du Postgresql pour les DB et Qlikview pour la partie reporting.

Le projet est en phase de teste et à l'heure actuelle, ils ont décidé de mettre toutes les données dans une seule table sous Postgres pour limiter les jointures et faciliter les requêtes. C'est l'équipe du système opérationnel qui s'occupe de "l'ETL".Pour le moment j'en sais pas plus mais je pense que c'est un batch qui s'occupe de rapatrier les donnés dans cette unique table. On se retrouve avec plus de 100 colonnes et de plus, cette table se trouve dans la DB opérationnelle.
Ceci concerne la partie "inscription" et "call center" point de vue business.

Pour la partie reporting, je résume, ils importent les données dans un fichier QVD une fois par jour (durant la nuit). Ensuite on charge le QVD dans Qlikview.

Vous l'aurez compris, il y a pas mal de chose qui cloche :
-Rassembler tout dans une seule table, on est loin de la vison de Kimball. De plus à terme ça risque d'exploser car pour le moment ce n'est que la partie "inscription" et "call center" mais par la suite on compte répendre la BI à la partie HR, finance etc.
-Concernant cette table, d'après ce que j'ai appris, le DW (enfin ici ça n'a rien d'un DW vu que ce n'est qu'une table) ne doit pas être dans la ou les même(s) DB que le ou les système opérationnels.
-De plus, je pense qu'ils rapatrient toutes les données vers cette table même celles qui ne sont pas nécessaire au reporting je pense. On se retrouve avec un nombre de colonnes immense et a terme ça fait beaucoup de données inutiles.
-Faut-il envisager une solution de cube malgré que c'est du In-memory avec Qlikview ?
-En ce qui concerne l'ETL, je ne comprend pas pourquoi c'est l'équipe opérationnel qui s'en occupe surtout qu'ils n'ont pas de connaissance BI. C'est nous qui devons leur dire les besoins. Autant que ça soit nous qui nous occupions de l'ETL directement avec un vrai outil ETL.
-Il y a certainement d'autres remarques.

J'aimerai un peu votre avis ainsi que votre point vue et des arguments me permettant de convaincre de changer leur vision. Je sais qu'il y a parfois un monde entre la théorie et la pratique mais ici je pense qu'on est pas sur la bonne voie dès le début.

[Jester]

Quelques questions :

• êtes-vous le seul intervenant?
• votre SSII est-elle à fond QlikView?
• le client a-t'il une version sérieuse de QlikView ou une low cost (loca ou même personnal)?

Je pense qu'il s'agit d'un projet BI mal engagé.

• QlikView est un outils d'analyse principalement et ne résout pas l'ensemble des problématiques BI. Donc est-ce que le choix est vraiment judicieux? De plus ça peut vite être très cher.
• Postgresql sera médiocre avec une table de fait de 100 colonnes. Postgresql est très bon pour gérer des tables dimensions qui tiennent en mémoire (jointure bien moins chère que le coût I/O de la table à 100 colonnes). Cela dit, ce n'est pas votre problème mais celui de l'informatique, cf point suivant.
• Si le métier gère la BI, ce n'est pas de la BI. Là c'est l'informatique qui fait des extract de données, ici au format QVD mais ce n'est pas de la BI. A chaque nouveau besoin, ce sera une charge pour l'informatique qui le mettra bien en dessous de la pile. L’existence de la BI est justement pour régler ce problème. Ici c'est l'informatique qui fait un extrait de données pour un contrôleur de gestion (vous).
• La BI c'est beaucoup de connaissances de l'entreprise qui prend donc du temps à apprendre et qu'il est dommage de perdre. Donc si le cœur de la BI c'est un consultant, ça n'a pas de sens. Garder un consultant des années, c'est clairement pas rentable.
• "L'IT à décidé" Le sponsor est la direction informatique ce qui n'est pas bon du tout. La direction financière, voire la direction générale, doivent être impliqués. Là ça fait un peu la direction informatique qui a pensé "Ils nous les brisent à vouloir des données, on va prendre le soft à la mode en BI, un consultant pour quelques mois et hop on sera plus embêté par ces gens". Je caricature, d'autant que c'est une réflexion légitime, mais marche rarement quand c'est dans cet esprit là.

Pour réussir un projet BI, il faut :

• qu'il soit tenu par une personne dans l'entreprise et pas un consultant de passage, la culture de l'entreprise sera plus importante que les compétences techniques.
• être du coté des utilisateurs. Ce n'est pas une guerre contre l'informatique, mais presque. L'informatique a une mine de données que les utilisateur de la BI veulent. La mission de l'informatique ce n'est pas de répondre à ce besoin, mais de faire tourner les opérations. Le besoin venant des utilisateurs BI, il doit être dirigé par ceux-ci. La BI doit être en finance (ou en marketing à la rigueur) et avoir un accès complet aux données informatiques.
• être orienté solution. La BI c'est pas construire des cathédrales de données, c'est répondre aux besoins des utilisateurs pour améliorer la marche de la société en étant durable. Souvent être le gars qui peut lancer la requête SQL en fournir un Excel suffit au bonheur des gens.

Cela étant dit, vous êtes consultant Junior, si c'est votre boite qui a vendu QlikView déjà pas possible de dire le contraire (je ne dis pas que ce n'est pas la bonne solution). Il vous faut voir quel est le sentiments des clients (ceux qui vont utiliser QlikView). Regarder leur besoins et essayez de solutionner les plus simple pour vous afin de montrez que vous êtes dans leur camp (vous pouvez être dans les deux).

Regardez avec l'informatique si c'est possible d'avoir une base Postgresql clone asynchrone de la prod. Ou qu'ils stockent un backup journalier que vous pourriez remonter dans une autre instance Postgresql chaque nuit. Une fois cela établit, utilisez ce clone et QlikView pour répondre aux besoins utilisateurs (avant de faire un entrepôt si possible). En parallèle, vous industrialisez petit à petit et montez une infrastructure BI propre. Le management en BI consiste à décider entre investir (améliorer l'infrastructure, l'ETL et l'entrepôt par exemple) et récolter les dividendes (résoudre des besoins, faire un extract, un rapport, un ETL bidouille pour un utilisateur).

[doc malkovich]

Hum, je n’appellerais pas ça un projet BI dans les règles de l'art

Mettre tout dans une seule table : ça semble du copier/coller du QVD. Pas forcément la meilleure solution. Par contre ça m'étonnerait qu'ils puissent faire ça pour tout ; plus tard il faudra rajouter des tables pour d'autres besoins.

Mettre la table dans le système opérationnel : dans ce cas il faut figer le système le temps du batch pour avoir des données intègres, bon courage

L'ETL est du côté opérationnel : pourquoi pas, s'il n'y a pas grand chose à faire et s'ils ont les compétences ... Mais c'est vrai que c'est du côté BI qu'on trouve cette expertise généralement.

Mais bon, si l'IT a décidé cela dans son coin ce sera dur de les convaincre de revoir l'architecture, surtout venant d'un consultant junior

[stylor]

Tout d'abord je vous remercie pour votre intervention qui me reconforte dans l'idée que ce projet BI est étrange

Je rectifie juste quelque cose par rapport à ce que tu as dis Jester : l'IT s'occupe de l'intégration de données en amont. C'est à dire que c'est eux qui ont créent cette table unique "au besoin de la BI" (moui tu parles... ) et qui s'occupent de la remplir à partir de leur système OLTP (concernant les inscription et centre d'appel pour le moment). Par contre les fichier QVD c'est nous. Donc ensuite, nous chargeons cette table dans un fichier QVD (tous les soirs) et ensuite on charge ce fichier dans Qlikview. On passe par des fichiers QVD car c'est plus performant que si on devait directement se connecter à la DB. Et ça permet aussi d'avoir un load incrément mais ceci n'est pas pour tout de suite. Donc tous les soir on vide le fichier QVD pour le reloader pour le moment. Ca ne me dérange pas trop vu que c'est temporaire et qu'on est en phase d'étude et teste. L'incrémental viendra après si on garde cette solution.

C'est l'IT qui a décidé de revoir l'architecture justement. Je me suis dit que tant qu'a faire, autant faire les choses dans les règles de l'art dés le départ. De plus ça sera une bonne opportunité pour moi d'améliorer mon expertise étant junior. Mais c'est vrai que je ne veux pas paraître comme quelqu'un de prétentieux. Je viens d'arriver il y a une semaine et leur dire que tout ça c'est à la poubelle (j'exagère) je doute que ca va passer ^^.

Comme vous avez pu le constater, j'ai de la chance, le projet vient de commencer et donc ils n'est pas trop tard pour rectifier le tire. Mais le tout est de convaincre et d'expliquer. Dans les prochains jours, je vais avoir des meeting et des discusion pour déjà comprendre le business (étant junior sans grande expérience c'est pas facile pour proposer des solutions sans comprendre). On verra un peu l'état d'esprit et je vous en ferai part. A première vu, la majorité des gens sont jeunes et je pense qu'ils sont ouvert d'esprit mais je me trompe peu-être. Je n'ai pas encore discuté avec les responsables.

Pour répondre aux question :

Oui c'est ma société qui a vendu Qlikview. C'est la version complète avec serveur et tout le tralala.
Il y avait déjà un expert QlikView de chez nous sur place depuis presque 1ans. Ne me demandez pas pourquoi il n'a pas penser à déjà changer les choses petit à petit dès le départ, je ne sais pas. Donc on est 2 consultants + un jeune project manager interne. Il y a aussi d'autres intervenant qui sont plus fonctionnel/business. Les besoins sont rédigé par de ces derniers. C'est donc eux qui s'occupent de discuter avec les end-users, c'est déjà une bonne chose.
Ma SSII n'est pas spécialement à fond Qlikview mais disons que pour le moment ils essayent de s'imposer sur le marché avec cet outil pour faire la différence. J'ai des connaissance en Microsoft BI mais je doute que le client accepterai de changer totalement d'outil comme ça du jour au lendemain et puis ça ne sera pas très crédible de notre part (SSII). En plus, l'equipe IT est plutôt open-source. Je n'ai rien contre, mais qui laisse le projet BI entre les mains des pro. de la BI.

Apparemment les feedback concernant Qlikview sont plutôt positifs. Mon collègue étant là depuis 1ans presque, à déjà étable quelques rapport et dashbord montrant la puissance de cet outil. C'est beau quand on montre mais derrière c'est pas si beau lol mais ça le business s'enfou et ne veut pas savoir car c'est trop "IT". Là ils se rendent compte que ça commence à devenir n'importe quoi d'où leur idée de remanier l'architecture.

Donc je vais voir si il n'est pas possible qu'on prennent en charge l'ETL à leur place avec une solution open-source comme Talend. Ce client est un acteur dans l'énergie (gaz & électricité). Il y a différent process qui interviennent, une masse de données qui ne cesse d'augmenter. Bref, je pense qu'un gros travail d'ETL doit absolument être bien pensé.

Par contre Jester, je n'ai pas très bien compris quand tu dis de ne pas faire un DW dès le départ et de prendre les données directement depuis un "clone" du système OLTP en-dessous de Qlikview directement ? Je pensais justement créer un entrepôt dès le début (dans le cas où j'arriverai à convaincre que leur table unique n'est pas appropriés).

[Jester]

Ce type de projet BI n'est pas isolé, c'est globalement ce qui se passait depuis un an dans la société où je travaille à présent (sauf que le budget consultant était plus réduit, pas de consultant en permanence). J'ai viré la solution à base de Cognos ce qui revient à passer plusieurs années de salaire en sunk costs, il n'y avait rien de concret à part des problèmes.

Pour ce qui est du data warehouse un exemple précis. Mon boss n'est pas content de moi pour mes prouesses technologiques ou mon data warehouse de qualité plus que correcte. Non ce qu'il retient c'est une requête SQL sur le système de compta que j'ai corrigé et intégré dans un Excel. On parle de 2h de travail dont je ne peut pas vraiment dire que c'est de la BI. Pour lui c'est le truc qui a simplifié sa vie en réduisant le temps d'extraction de données comptable de 4h à 2 minutes. Encore cette semaine on me téléphone pour des données, 15 min après je donne un excel qui pointe sur une vue qui pour l'instant tappe sur le clone de la prod. Derrière j'aurais 4-5h de boulot pour l'intégrer proprement dans l'entrepôt de données.

Quand tu dis "Apparemment les feedback concernant Qlikview sont plutôt positifs." est-ce que c'est tu as des indicateurs de l'usage de la plateforme par les clients? Si l'adhésion est bonne no soucy, je suis pas un expert de QlikView. Si ce qu'ils font c'est des exports en Excel alors c'est pas une réussite.

Pour la phrase "C'est donc eux qui s'occupent de discuter avec les end-users, c'est déjà une bonne chose." c'est pas vraiment une bonne chose, c'est la réflexion de l'informaticien ou du dev BI standard. D'un coté on a des clients qui ont des problèmes et un contexte et de l'autre toi avec les solutions que peuvent apporter la BI. Au milieu des types qui ne sont personnellement impliqués ni dans l'un ni dans l'autre pour faire du téléphone arabe. Pas très efficace.

Il ne fait pas venir avec bon votre table de synthèse là c'est n'importe quoi on va reprendre l'ETL. Il faut partir dessus car c'est déjà traité donc plus simple. Une fois une V1 en place, passer au niveau en dessous, il sera toujours temps de prétexter qu'il manque l'info X qu'un directeur a demandé mais que comme vous êtes sympa, vous voulez bien prendre à charge la gestion de cette feature contre un accès à un clone de la BD source. Pour les forcer à avoir un clone, rien de mieux que de mettre la prod à genoux une fois ou deux de manière discrète et trouver un sponsor pour financer le hardware. Comme je l'ai indiqué reprendre un backup de la veille est un très bon début, l'informatique fait forcément des nightly backup, donc vous avez juste à ce qu'ils soient accessible et vous pouvez faire le reste de votre coté en montant un prototype sur votre machine de dev si besoin.

[stylor]

Donc si j'ai bien compris pour résumer, je continue à travailler de leur façon sans vraiment faire de la BI en les suivant dans leur direction et en parallèle je fais un projet BI ? Ils vont se demander pourquoi je ferai ça surtout que c'est le client qui paye et le temps lui coute de l'argent, je pense. Je devrai donc quand même justifier.

Donc si c'est bien ça que vous vouliez dire, ça risque d'être difficile. Je n'aurai certain pas le temps d'être à plein temps sur les 2 plans surtout que je débute et donc ça va me demander plus de temps d'effectuer une tâche ou proposer une solution comparé à quelqu'un avec plus d'xp.

De plus, j'ai du mal à concevoir qu'on ne puisse pas mettre en oeuvre une solution d'ETL dans ce type d'entreprise. Construire des rapport sans aucune certitudes de la qualité des données et de la cohérence me parait dangereux et contre productif au vu de leur différents process et data.

[stylor]

J'ai une réponse pour l'ETL. En faite ils pensent que leur données sont sure vu que ça vient de la base opérationnel donc ça nécessite pas de transformation particulière.

En ce qui concerne le faite de tous mettre dans une seule table dans la base opérationnelle, pour eux ça ne n'engendre pas de problème de performance car ils préfèrent augmenter la RAM du serveur et jouer avec les cluster. Et d'après leur dire c'est plus facile pour la maintenance d'avoir une seule table et plus facile à comprendre vu qu'on a presque plus de jointure.

Et en mettant la logique métier dans la DB, ça permet aussi au gens du business de faire leur reporting sous Excel en se connectant à cette fameuse table directement.

Je suis à moitié convaincu et je reste perplexe sur le long terme. Les concepts de Kimball, best practices que j'ai pu lire sont mise en question finalement.

[Jester]

Pas exactement, l'idée c'est de partir de l'existant et de migrer petit à petit vers une solution cible.

Faire un ETL sur la base source ça prendra du temps et c'est un risque, tant qu'il n'y a pas besoin ce n'est pas justifié. Si ça implique 3 mois sans avancées concrètes ça n'a pas de sens. Mais dès qu'un besoin pourra le justifier, il faut le faire, petit bout par petit bout.

Pour la big table, j'en comprend quelle tient en mémoire, donc là oui ça peut se tenir (quoique techniquement c'est pas évident de faire résider cette table en mémoire sous postgresql alors qu'il y a aussi la base de prod, si tu as des détails dessus je suis preneur). Kimball et autre c'est prévu pour des gros volumes, table > cache en mémoire vive de la base de données.

"ça permet aussi au gens du business de faire leur reporting sous Excel en se connectant à cette fameuse table directement."

Hum, j'aurais tendance à dire que ça sera le réel outil de BI (hors reporting). Du coup on comprend que la table est probablement très petite (<1M de lignes). Il faut que tu suive l'usage et les retours d'Excel par rapport à QlikView.

Tu peux te renseigner sur l'utilisateur des vues dans les bases de données ainsi que powerpivot et les fonctions type cubevalue d'Excel.

Tu peux par exemple proposer de créer des vues sur la big table pour répondre à des besoin spécifiques utilisateurs (formatage différent, vision plus simple). Ensuite proposer de faire des vues qui tappent directement dans les donnés sources (parce que l'info n'est pas encore dans la big table). Puis ensuite de faire un mini ETL parce que pour un besoin la vue est trop lente. Ensuite avoir besoin de données qui ne viennent pas des opérations (par exemple de la compta ou de divers fichiers excel de la finance comme les prévisions). De proche en proche, in fine, tu finis avec une solution BI classique.

Il faut simplifier la vie de l'IT et simplifier la vie des utilisateurs et alors tout est possible.

[stylor]

Ensuite proposer de faire des vues qui tappent directement dans les donnés sources (parce que l'info n'est pas encore dans la big table). Puis ensuite de faire un mini ETL parce que pour un besoin la vue est trop lente.

J'ai pas très bien compris

[doc malkovich]

Je suis à moitié convaincu et je reste perplexe sur le long terme. Les concepts de Kimball, best practices que j'ai pu lire sont mise en question finalement.

Justement, c'est parcequ'ils ont une vision à court terme ... étriquée aussi, en se limitant à Qlikview.

Le mieux serait de reprendre comme vous dites les concepts de Kimball et démontrer les inconvénients de leur solution dans l'avenir ... Ou les laisser faire et aller dans le mur ...

Bon courage pour la suite !

[stylor]

C'est ce que je voulais faire mais c'est difficile d'expliquer pourquoi faire un datawarehouse, pourquoi faire un schéma en étoile plutôt qu'une seule table unique.

[doc malkovich]

Ce n'est pas difficile si on a compris les concepts

Le plus difficile c'est d'avoir en face des personnes fermées qui ont un budget limité ou qui sont sures d'avoir raison

Les principales limites de la table unique sont en effet les problème de volumétrie. A vouloir tout mettre dedans on va avoir une matrice creuse (car les indicateurs n'ont pas tous les mêmes dimensions). Autre point, si on veut étoffer les dimensions comme la dimension temps (qui possède généralement une centaine de colonnes), comment va-t-on avoir ces données dans la table ? Si l'utilisateur veut juste consulter le référentiel produit, va-t-il devoir lire toute la table ?

[Jester]

Mon propos était de dire qu'il faut y aller pas à pas et qu'il ne faut pas partir de l'amont (les données, faire un super data warehouse et tout), mais de l'aval (le besoin, prendre le projet qui est le plus optimal en importance et difficulté et le faire)

Je ne suis pas d'accord avec doc sur le budget limité. On parle quand même d'un investissement qui est déjà à 200-300k€. On est pas loin de l'adage en BI qui dit "3M$, 3 ans, 3 rapports". Par contre j'approuve l'idée du référentiel produit, il faut faire un distinct du coup, ça semble compliqué. Et si un directeur veut les produits dans une hiérarchie qui n'est pas dans le système opérationnel?

[stylor]

qui sont sures d'avoir raison

Les principales limites de la table unique sont en effet les problème de volumétrie. A vouloir tout mettre dedans on va avoir une matrice creuse (car les indicateurs n'ont pas tous les mêmes dimensions). Autre point, si on veut étoffer les dimensions comme la dimension temps (qui possède généralement une centaine de colonnes), comment va-t-on avoir ces données dans la table ? Si l'utilisateur veut juste consulter le référentiel produit, va-t-il devoir lire toute la table ?

Je ne pense pas que ça soit un soucis de budget car niveau hardware ils n'ont pas peur d'investir. J'ai eu un petit meeting aujourd'hui matin et effectivement ils sont sure que leur façon de faire va fonctionner

J'ai justement évoqué le problème de volumétrie mais pour eux ça ne posera pas de problème car apparemment avec de l'optimisation (notamment les clusters) ça se passera bien.

En ce qui concerne la notion de temps, dans cette big table il y a un champs reprenant la date et l'heure de création du record. Et dans Qlikview il est possible de créer une dimension temps qu'on pourrait lier à cette big table.

Par contre oui, si on veut un set de données, il faut charger toute la table en mémoire ou bien filtré dans Qlikview au moment de charger les données et ne prendre que les colonnes dont on a besoin. Pour eux encore une fois, ils préfère ajouter de la RAM pour améliorer les performance en cas de soucis.

Et si un directeur veut les produits dans une hiérarchie qui n'est pas dans le système opérationnel?

Si cette fameuse table ne suffit pas pour répondre à un besoin, la BI doit demander à l'IT de créer une table (ou une autre bricole) permettant de répondre au besoin. Pour résumer, ils veulent mettre la logique business au maximum au niveau DB et les raisons sont :

• Si ils décident de laisser tomber Qlikview pour une autre solution, il suffira d'après eux de clipser le nouvel outil de reporting sans refaire la logique, les calcules etc.
• La maintenance sera plus simple vu que c'est au niveau du système OLTP
• Permettre le reporting sous Excel pour le end-users avancé

Ils ont réponse à tout, je n'ai pas pu les convaincre malgré que je pense avoir compris les conceptes derrière la BI mais eux aussi apparemment ^^
Ils ne veulent pas entendre parler de schéma en étoile non plus, c'est trop compliqué à comprendre pour le business (c'est justement le contraire) et il y aura trop de jointure

[doc malkovich]

On parle quand même d'un investissement qui est déjà à 200-300k€.

Je n'ai pas vu cette échelle de prix, à mon avis tu la déduis de l'achat de Qlikview et du serveur, mais c'est pas ça qui va en faire un projet BI critique pour la boîte ...

Pour eux encore une fois, ils préfère ajouter de la RAM pour améliorer les performance en cas de soucis.

Ce n'est pas l'augmentation de RAM qui va améliorer les performances ; si la volumétrie double il faudra 2x plus de temps pour scanner les données, et ainsi de suite ... Il vaut mieux mettre les données dans plusieurs endroits, la vitesse sera la même ... Et puis il me semble qu'en RAM il y a une taille limite sur un serveur ... et puis la RAM c'est bien pour QV, pas pour excel (hors powerpivot)

Ils ont réponse à tout, je n'ai pas pu les convaincre malgré que je pense avoir compris les conceptes derrière la BI mais eux aussi apparemment ^^

C'est ce que je voulais dire par équipe fermée
Malheureusement dans ce cas si tu te rebelles trop tu risques de les braquer et là c'est foutu
Préviens-les gentiment et comme le conseille Jester essayes d'améliorer certains points au fur et à mesure ...
Bon courage !

[stylor]

Oui c'est ce que je pense faire, essayer petit à petit de les conseiller. Sinon je me dis que ça sera une opportunité pour moi d'améliorer mon expertise sous QV et connaître ce secteur d'activité point de vue business.

Merci pour vos interventions