Stephen Few sur Tableau 8 (spoiler : il est pas ravi)

Stephen Few, le pape de la datavisualization, nous fait un retour assez sombre sur la nouvelle édition de Tableau (qui devrait sortir sous peu). Vous le savez c’est un sujet qui me tient à cœur puisque je dispose d’une offre Tableau dans mon portefeuille.

Si je n’ai pas eu la chance de tester Tableau 8 moi-même, pour constater de visu les remarques faites par Stephen, je retrouve bien mon feeling général par rapport à l’éditeur dans sa prose. Je vous laisse aller la parcourir!

The new face of Tableau

Alors la situation est-elle critique? Le monde de Tableau s’écroule t-il?

Ou formulé de manière plus pragmatique : Peut-on encore sereinement acheter du Tableau aujourd’hui ?

Oui, évidemment! (répond le revendeur de licences).

Tableau Desktop 7, et bientôt Tableau 8, est pour moi l’un des meilleurs logiciels d’exploration visuelle des données. Il dispose d’une avance considérable qu’il faudra du temps aux autres pour rattraper. Aujourd’hui c’est le plus rapide à prendre en main, le plus flatteur pour l’utilisateur, le plus simple à déployer et maintenir, et à part les copains Spotfire (au licencing incompréhensible) et JMP (nettement moins sexy) il n’y a pas grand monde pour le concurrencer.

Par contre si Tableau, l’éditeur, en faisant des efforts pour plaire à Gartner et au marché (à la veille de son entrée en bourse), va à l’encontre des bonnes pratiques de la dataviz (qui étaient son facteur différenciant jusqu’à présent), il est vitale que les vrais experts indépendants comme Stephen Few tirent la sonnette d’alarme. C’est chose faite!

Espérons que le message passe.

Dilbert du 30/07/2012

Tableau versus PowerPivot : Calcul de commissions

En ce moment je m’amuse beaucoup avec Tableau, et je pense avoir atteint le stade de la compétence consciente – ou bien je suis en pleine désillusion, on ne sait jamais vraiment… Mais à force de formation, de démonstrations, de maquettes, de prototypes et de webcasts (je vous recommande l’advanced training, « live online » tous les mercredi soir à 20h), je commence à me sentir bien avec le produit. La technique d’un côté plus la théorie de l’autre, je maîtrise mon processus de montée en compétence!

Tout ça pour dire que ça fait longtemps que je n’ai pas fait un petit article technique, et que désormais je me sens assez confiant sur Tableau pour me lancer. Evidemment c’est Tableau, donc « technique » c’est un bien grand mot. Avec ce soft on parle plus de recettes, d’astuces, que de code pur et dur. Vous allez voir !

Pour la problématique à traiter je suis parti trouver l’inspiration sur l’excellent blog PowerPivotPro, définitivement le meilleur blog sur PowerPivot à l’heure actuelle. Si d’habitude le blog est tenu par le merveilleux Rob Collie, pour le sujet qui nous intéresse l’auteur du jour est David Churchward. Un grand merci à eux pour cette source d’inspiration (et le classeur de données), et vous l’aurez compris mon objectif va être de résoudre le même cas métier qu’eux en utilisant Tableau plutôt que PowerPivot. Voici les liens vers la série d’articles qui nous intéresse : 1, 2 et 3, j’encourage vivement ceux qui savent ce que DAX veut dire d’aller les consulter, ne serait-ce que pour leur culture personnelle.

Le cas métier est le suivant : calculer les commissions des commerciaux selon un barème par tranche. Pour ce faire on utilisera deux méthodes : la prise en compte du taux maximal comme unique coefficient sur les ventes d’une part, et  d’autre part la ventilation de ce même calcul sur les tranches. Pas de panique, on va détailler ça.

Tout repose sur une table des taux de cette forme :

Illustration - Table des taux

Mes commerciaux sont commissionnés tous les mois. Chaque mois on va donc agréger leur chiffre des ventes par type de produit, puis déterminer la ligne de taux de commission applicable en fonction de sa date de validité et du montant des ventes réalisés. Vu qu’on est pas (complétement) pervers, on pose comme hypothèse qu’un taux ne peut pas changer dans un même mois.

Par exemple, en février 2012 Bob a vendu 80 000$ de café (ça en fait des dosettes) et 60 000$ de thé. Sur cette période (du 01/02/2012 au 29/02/2012), le taux applicable pour ce montant de café est 20% (deuxième ligne du tableau ci-dessus), le taux applicable pour ce montant de thé est 30% (dernière ligne du tableau).

A partir de là, deux méthodes de calcul sont possibles :

  • En taux maximal, Bob touchera 34 000$, soit 20% * 80 000 + 30% * 60 000
  • En ventilation par tranche, Bob touchera 15 000$ pour le café soit 10%*10 000 sur la première tranche plus 20%*70 000 sur la deuxième tranche. On ventile son résultat sur chaque taux intermédiaire plutôt que sur le taux maximal. Il touchera également 17 000$ pour le thé soit 10%*5 000 sur la première tranche plus 30%*55 000 sur la deuxième. Ce calcul est le même que pour nos impôts sur le revenu en fait. Avec cette formule Bob touchera au total 32 000$, évidemment moins qu’avec le taux maximal.

Voilà pour le fond du problème. Si vous avez besoin de plus d’explications, n’hésitez pas à consultez l’article original ou à poser des questions en commentaire.

D’un point de vue source de données, je vais brancher Tableau Desktop directement sur le classeur qu’utilise David Churchward (lien tout en bas de la page). Evidemment je pourrais exploiter le résultat de ses efforts et aspirer directement les infos de son tableau croisé dynamique final, une manière tout à fait convenable dans le quotidien, mais le but de cet article c’est de voir comment implémenter le calcul dans Tableau, donc je ne vais prendre que ses onglets sources. J’en profite pour rappeler que Excel+PowerPivot et Tableau Desktop sont très, très bons amis. Les limites de l’un étant très bien compensées par les forces de l’autre, et vice et versa. Mais c’est un sujet pour un autre jour !

Je dispose donc des éléments suivants :

  • Des commandes :

Source Excel : Orders

  • Des gens (pour faire joli):

Source Excel : People

  • Des types de produit (pour faire joli encore):

Source Excel : Type

  • Des taux par type, par période (From_Date, To_Date) et par tranche de montant (From, To) :

Source Excel : Taux

Vous noterez que pour le moment j’ai simplifié la problématique complète résolue par David Churchward. De son côté il calcule des commissions pour les commerciaux sur leurs ventes, et pour les managers en fonction du résultat de leurs commerciaux. De mon côté je ne calcule que les premières. A mon sens la mécanique est la même, si j’ai le temps je compléterai mais je ne vois pas de difficultés supplémentaires.

Je lance donc Tableau et je me connecte au fichier Excel (note pour les utilisateurs d’Excel 64bit, Tableau peut vous demander de télécharger un driver complémentaire, pas de panique, le message d’erreur est explicite et le driver est ici).

J’ouvre une nouvelle connexion de données de type Excel et je pointe vers le fichier source :

Première connection à Excel

On sent bien dans notre cas que tout le problème réside dans la jointure entre les taux (Rates) et les commandes (Orders). Mon premier réflexe ici est donc de monter 2 connexions de données, une contenant les commandes auxquelles je vais joindre les types de produits et les managers, et une seconde contenant les taux. Une fois les données chargées je pourrai toujours créer un champ calculé avec le langage d’expression de Tableau pour calculer mes commissions.

Roulez jeunesse, je me connecte aux commandes (Orders) et je joins les tables People et Types :

Première connection à Excel avec jointure

On repasse par l’écran d’accueil pour créer dans le même classeur Tableau une deuxième connexion en parallèle de la première :

Deuxième connection à Excel dans le même classeur

Et j’obtiens les champs tant attendus dans Tableau :

Zone de données dans Tableau

Je peux donc monter une première visualisation qui va mélanger mes données en faisant juste un drag and drop de mes champs… ou pas :

Tableau m'avertit que je fais une bétise

Evidemment ce n’est pas magique ! La jointure est complexe, et Tableau ne gère que les LEFT JOIN simples entre les datasets qui ont déjà été chargés.

Ok pour que ça ne marche pas tout seul, j’essaye donc de définir un champ calculé qui vaudrait le taux souhaité quand les conditions de jointures sont bonnes, et 0 sinon, mais sans grand succès.

En effet j’essaye de brasser des données qui n’ont pas du tout le même niveau de granularité. Ne serait-ce que par rapport au temps, dans mon dataset des commandes je suis au jour de la commande, du côté du dataset des taux ma granularité temporelle est la période de validité d’un taux (From/To), et j’attends un résultat au mois… Délicat.

Tableau est avant tout un outil de visualisation, s’il est tout à fait capable de faire des calculs à des niveaux d’agrégation intermédiaires sans difficulté, il nécessite que ces niveaux apparaissent dans la visualisation ! Alors prévoir tout ça dans une visualisation c’est certainement possible pour un jedi, mais pour le commun des mortels, c’est un peu trop velu. Il va falloir trouver une autre manière de faire.

Notez au passage que de son côté PowerPivot se régale de ce genre de problématiques. Son langage d’expression, le DAX, dispose d’une syntaxe qui permet « facilement » d’exprimer des calculs intermédiaires à différents niveaux d’agrégation. Mais on a déjà dit qu’on voulait traiter ce cas avec Tableau, alors insistons un peu !

Mais pas trop! Car heureusement Tableau a plus d’un tour dans son sac, dont un qui me plait particulièrement : il peut attaquer les fichiers Excel en SQL. Oui Monsieur, oui Madame ! Et le SQL c’est un peu mon premier amour, autant vous dire qu’à partir de là, pour moi, le problème se simplifie 🙂

On ferme la connexion sur les taux, elle ne sert à rien, et on modifie la connexion sur les commandes en passant en mode SQL :

Connection à un fichier Excel en SQL

Voici le SQL que j’ai bricolé :

SELECT
       YEAR([Orders$].[Date]) AS [Order_Year]
       ,MONTH([Orders$].[Date]) AS [Order_Month]
       ,[Orders$].[Salesman] AS [Salesman]
       ,[Orders$].[Type] AS [Type]
       ,[Types$].[Type_Name] AS [Type_Name]
       ,[People$].[Manager] AS [Manager]
       ,['Rates (2)$'].[From] AS [From]
       ,['Rates (2)$'].[To] AS [To]

       ,SUM([Orders$].[Value]) AS [Value]
       ,MAX(['Rates (2)$'].[Rate]) AS [Rate]

FROM ( ( [Orders$]
  INNER JOIN [People$] ON [Orders$].[Salesman] = [People$].[Name] )
  INNER JOIN [Types$] ON [Orders$].[Type] = [Types$].[Type_Code] )
  INNER JOIN ['Rates (2)$'] ON
             ([Orders$].[Type] = ['Rates (2)$'].[Type])
       AND ([Orders$].[Date] >= ['Rates (2)$'].[From_Date])
       AND ([Orders$].[Date] <= ['Rates (2)$'].[To_Date])

WHERE
       ['Rates (2)$'].[Rate_Group] = 'Salesperson'

GROUP BY
       YEAR([Orders$].[Date])
       ,MONTH([Orders$].[Date])
       ,[Orders$].[Salesman]
       ,[Orders$].[Type]
       ,[Types$].[Type_Name]
       ,[People$].[Manager]
       ,['Rates (2)$'].[From]
       ,['Rates (2)$'].[To]

Pour ceux que ça effraie, je vous en fais une relecture rapide (cliquez dessus pour le voir en grand):

Relecture du SQL utilisé

Le dataset ainsi composé renvoie les lignes suivantes:

Dataset retourné par la requête SQL sur le fichier Excel source

Vous  noterez qu’à ce moment précis mes données sont « fausses ». En effet le vendeur Adam sur le type AV sur janvier 2012 a ses 54239$ de ventes répétés 4 fois (4 premières lignes au-dessus). C’est complétement normal, on va corriger ça juste après.

Je me permets de faire vite fait sur les dates dans le SQL (juste Mois et Année) parce que je vais utiliser un champ calculé dans Tableau pour régénérer une vraie date complète, qui elle me permettra d’utiliser toutes les fonctions temporelles de l’outil :

Champ calculé Tableau : Mois des commissions

Maintenant que nous sommes dans Tableau, on va recalculer un montant des ventes correct, qui ignore la démultiplication qu’on a observé plus tôt. Pour se faire on va créer un champ calculé qui vaut 0 quand le montant des ventes n’est pas dans la tranche du taux, et ce même montant si c’est le cas. On va dé-multiplier la démultiplication :

Champ calculé Tableau : Ventes corrigées

Une fois qu’on a ce montant, calculer les commissions sur taux maximal devient enfantin :

Champ calculé Tableau : Commissions sur taux maximal

Je vous illustre ça tout de suite pour bien comprendre ce qu’on vient de faire :

Tableau : Illustration du calcul des commissions sur taux maximal

On part de Value qui est retourné par la requête SQL sur toutes les tranches. Sales est passé à 0 si Value n’est pas entre From et To. Et Commission vaut Rate que multiplie Sales. Pas mal non ?

De la même manière, on va calculer un montant de ventes qui lui sera ventilé sur les taux :

Champ calculé Tableau : Ventes par tranche de taux

Ok, celle-là est un peu plus sioux. Voilà l’opération réalisée ligne par ligne :

Illustration du calcul des ventes par tranche

Résultat qu’on utilisera pour calculer les commissions ventilées :

Champ calculé Tableau : Commission par tranche de taux

Et voilà ce que ça donne au niveau fin, pour bien comprendre la mécanique :

Tableau : Illustration du calcul des commissions par tranche

Enfin, voici le résultat final à niveau agrégé. Notez que pour les sales on peut utiliser les 2 mesures qu’on a calculé puisqu’elles s’agrègent correctement (sales et sales (tiered)), mais pas le value original, évidemment :

Tableau : visualisation complète

Pas si difficile que ça en fin de compte ? 🙂

Et pour ceux qui trouveraient que la syntaxe SQL et les champs calculés sont complexes, voici le DAX qui réalise la même chose côté PowerPivot :

=IF(COUNTROWS(VALUES(Dates[MonthEndDate]))=1
   &&COUNTROWS(VALUES(People[Name]))=1
   &&COUNTROWS(VALUES(Types[Type_Code]))=1,
     IF([Sales_Value]=BLANK(),BLANK(),
       CALCULATE([Sales_Value]-MAX(Rates[From]),
          FILTER(Rates,
             Rates[From]<=[Sales_Value]
             &&Rates[To]>=[Sales_Value]
             &&Rates[From_Date]<=MAX(Dates[MonthEndDate])
             &&Rates[To_Date]>=MAX(Dates[MonthEndDate])
             &&Rates[Type]=VALUES(Types[Type_Code])
             &&Rates[Rate_Group]=”Salesperson”
                 )
                )
        ),
    IF(COUNTROWS(VALUES(Dates[MonthEndDate]))=1
      &&COUNTROWS(VALUES(People[Name]))>1
      &&COUNTROWS(VALUES(Types[Type_Code]))=1,
       IF([Sales_Value]=BLANK(),BLANK(),
         CALCULATE([Sales_Value]-MAX(Rates[From]),
          FILTER(Rates,
             Rates[From]<=[Sales_Value]
             &&Rates[To]>=[Sales_Value]
             &&Rates[From_Date]<=MAX(Dates[MonthEndDate])
             &&Rates[To_Date]>=MAX(Dates[MonthEndDate])
             &&Rates[Type]=VALUES(Types[Type_Code])
             &&Rates[Rate_Group]=”Manager”
                 )
                )
        )
      )
)

Après tout est question de goût 😉

Alors voilà, on a chargé nos infos dans Tableau, on les a vérifié, c’est maintenant que le vrai travail de visualisation de données peut commencer. Moi je vais interroger les managers pour connaître leurs interrogations et construire les graphes qui y répondront… Je vous laisse faire de même et poursuivre avec le classeur que voici (à télécharger à travers Tableau Public ci-dessous, en bas à droite de la page qui s’ouvre).

Amusez-vous bien 🙂

Retour de Stephen Few sur l’étude Forrester sur la visualisation de données avancée

Stephen Few est mon nouveau gourou. Tout du moins dans la partie Business Intelligence (décisionnel) de mon activité.

J’ai acheté ses livres et je suis en train de les dévorer. Un compte rendu arrive bientôt, mais à mon sens « Show Me The Numbers » (édition 2012) représente côté visualisation de données ce qu’est « The Datawarehouse Toolkit » (2nd édition) de Kimball côté entrepôt de données. Et ceux qui me connaissent savent à quel point je vénère ce livre, donc ce n’est pas peu dire !

Show Me The Numers : Pareto Chart

D’ailleurs si vous vous souvenez c’est déjà Stephen Few qui m’avait inspiré pour cet article, c’est lui l’auteur du slide, et je suis content puisque désormais j’ai une bible pour chaque côté de la barrière.

Pourquoi vous en reparler maintenant ? Parce que ce bon monsieur a un blog, qu’il a du caractère et qu’il n’a pas sa langue dans sa poche. Donc naturellement il allume joyeusement et régulièrement l’industrie décisionnelle au sens large, et c’est plutôt jouissif.

La dernière en date je n’allais pas spécialement vous la rapporter, mais Stéphane Nardin a bien fait d’insister et j’y suis retourné pour voir que non seulement l’article de Mister Few est bon, mais que les commentaires qui suivent sont excellents.

Je crois que l’ensemble vaut vraiment les 10 minutes de lecture qu’il requiert, mais pour les pressés et les anglophobes je vous la fais en courte :

  • Stephen Few raconte dans l’article comment à la simple lecture de l’extrait gratuit du dernier rapport de Forrester sur la visualisation de données (2500$), il sait que c’est du vent. Morceaux choisis :
    • « … parce que, basé sur ses précédentes publications, je sais que Boris Evelson (un des deux auteurs) ne comprends pas grand-chose à la visualisation de données… »
    • « Personne avec un minimum d’expertise dans la domaine de la visualisation de données ne placerait IBM, Information Builders, SAP et Oracle dans la liste des leaders à côté de Tableau Software, Tibco Spotfire et SAS… »
    • « L’équipe de Forrester fait preuve de ce comportement typique dans le monde de la BI de l’obsession sur la technologie plutôt que sur les compétences et activités qui permettent de réaliser des visualisations efficaces… »
    • « Si vous avez payé pour le rapport de Forrester, demandez à être remboursé. Rappelez-leur qu’avec un tel prix, vient l’attente d’un niveau réel d’expertise. »
  • Dans les commentaires il continue :
    • « Vous pouvez penser que c’est violent de qualifier le rapport de Forrester de mensonges. Peut-être est-ce seulement de l’ignorance. Mais quand on prétend être expert, on se donne la responsabilité de connaître la vérité. Les auteurs ne peuvent pas être omniscients, d’accord, mais ils n’ont pas d’excuse pour ne pas connaître des faits aussi élémentaires ».
    • « Les auteurs de ce rapport, en fait, n’ont aucune expérience en visualisation de données. Ce sont des généralistes de la BI qui n’ont pas pris le temps d’apprendre ce domaine. »
  • Toujours dans les commentaires, il publie une mise à jour après avoir mis la main sur le rapport complet :
    • « Grace à un collègue qui m’a transmis une copie complète du rapport de Forrester, je peux maintenant dire que c’est pire que ce que j’imaginais. »
    • « Si cette étude représente la valeur générale qu’apporte Forrester à ses clients, ces derniers feraient mieux d’arrêter de payer et demander à être remboursés ».
  • Ce sur quoi intervient un certain Kyle McNabb, VP chez Forrester, qui tente de corriger le tir :
    • « Aucun vendeur ne paye pour apparaître dans l’étude » (en réponse à Stephen qui s’interroge sur pourquoi certains vendeurs qui n’ont rien à faire dans la visualisation de données y apparaissent quand même).
    • « Nos recherches sont exhaustives (…) Elles sont construites avec objectivité et en transparence ».
  • Et Stephen se lâche en réponse:
    • « C’était peut-être fatiguant (jeu de mot sur exhausting / exhaustive) pour vos analystes de compiler cette étude à cause de leur ignorance sur le sujet, mais ce rapport est loin d’être exhaustif ».
    • « Forrester produit peut-être des rapports utiles sur d’autres technologies, mais honte sur vous de produire un tel torchon sur la visualisation de données et de le facturer 2500$. »

Ouch.

Mais c’est aussi dans cette réponse finale qu’on touche à mon avis au coeur du problème. Stephen Few y révèle que l’un des auteurs lui a confié qu’il manquait d’expertise sur le sujet, et qu’il souhaitait que Stephen le forme. Seulement Forrester ne paye pas pour ce genre de prestation. Ils fonctionnent sous forme d’échange de bons procédés : la formation est gratuite, et en échange l’organisme cite l’auteur dans ses études, contribuant à sa notoriété, et oriente ses propres clients à la recherche de conseil vers la société de Stephen Few. Comme ce dernier le souligne, ce n’est pas avec ce genre d’arrangement qu’on peut garantir objectivité et transparence

Conclusion : ce n’est qu’un secret de polichinelle, mais les analystes (Forrester, Gartner…) disent un tas de choses qu’il faut savoir prendre avec des grosses pincettes. Personnellement, même quand je suis d’accord avec ce qu’ils publient, je place toujours un disclaimer qui rappelle la qualité incertaine de la source d’information. N’hésitez pas à faire de même !

T+1 semaine, je suis sous l’eau…C’est cool!

Je suis sous l’eau, certes, mais je souhaitais quand même faire un point avec vous une semaine après ma prise de fonction chez BIOS.

Tous ceux qui sont passés par là vous le diront, c’est vraiment éclatant de lancer une nouvelle offre. Tout le monde est en ébullition, les idées fusent et les todo listent explosent. L’ambiance est survoltée, c’est chouette 🙂

Dans ma liste et dans le désordre : la mise en place du partenariat avec l’éditeur, la formation technique poussée – un peu de crédibilité tout de même – la rédaction des différents supports commerciaux, la séduction des premiers prospects, la mise en place d’un premier événement (je vous tiendrai au courant, ce sera début juillet), l’information de l’équipe commerciale sur le pricing, les POCs, le karting (j’ai toujours la chance d’arriver au moment des soirées d’entreprise !), etc, etc…

Et ça ce sont les opérations de « survie » ! Parce que j’ai également été recruté pour mettre en place un blog pour BIOS, avec plein d’idée de comparatifs entre les différents outils BI, que ce soit Microsoft avec SQL Server 2012 et PowerPivot / Power View, mais également Qlikview, Cognos et tous ceux que vous réclamez dans les commentaires 😉

Donc je vous rassure, pas d’inquiétude, mes journées sont pleines.

Un dernier mot tout de même avant de retourner au turbin. Je voulais vous parler de la stratégie de BIOS, qui entretient des partenariats de haut niveau avec des éditeurs qui peuvent apparaître comme concurrents. A première vue cela peut paraître surprenant, mais ça ne l’est pas.

BIOS est un cabinet de conseil spécialisé en décisionnel. L’expertise produit ne vient qu’après le rôle de conseil. Les produits ne sont pas des fins en eux-mêmes, ce sont des outils à mettre en œuvre pour répondre aux problématiques métiers et organisationnels des clients. Dans les faits cela se traduit par la capacité à proposer plusieurs produits, chacun avec ses forces et ses faiblesses, et aider le client à choisir le plus adapté à la situation à résoudre. Dans ces conditions, aucun problème à par exemple faire cohabiter Qlikview et Tableau!

On reparlera de ce sujet, je le trouve crucial pour bien comprendre les offres de service et choisir ses consultants, dès que j’aurai un peu plus de temps…

[Mise à Jour] 22/06/12 – Clarifications

Le changement c’est maintenant!

Rien à voir avec les élections, sauf que pour moi aussi c’est le changement !
Je reviens de vacances, et je reprends la BI ça vous gagne en main, en vous annonçant que j’ai changé de société de conseil pour rejoindre BIOS Consulting. En effet les directeurs associés de BIOS m’ont fait une belle offre pour monter un pôle Tableau Software, j’avais besoin d’air frais, donc j’ai accepté !

BIOS ça peut vous rappeler quelque chose, en effet c’est l’ancienne société d’Aurélien Koppel avant qu’il ne se fasse débaucher par Microsoft. Aujourd’hui c’est Thomas Morisson qui a pris sa place, et moi « j’abandonne » la BI Microsoft pour faire du Tableau. Je mets des guillemets parce que ce n’est juste pas possible, j’aime trop ça pour tout lâcher et  je suis sûr que Thomas saura me débaucher de temps en temps pour lui filer un coup de main 🙂

En attendant me voilà « Chef de pôle – Tableau Software », et je trouve que ça claque bien 😉

On peut se demander pourquoi changer de technologie, surtout alors que SQL Server 2012 déboule avec tous ses nouveaux jouets.

En fait cela vient d’un constat simple : l’offre décisionnelle Microsoft manque vraiment d’un réel outil de visualisation/exploration des données. On en reparlera en détail plus tard – je ferai surement toute une série d’articles sur tous ces produits et Tableau – mais PowerPivot est tout sauf visuel, et Power View est… comment dire ça sans fâcher personne… jeune ?
Donc on a beau faire le plus beau datawarehouse du monde, si le client voit une interface moche, ou ne peut accéder à ses données qu’à travers Excel, c’est difficile de l’en convaincre. Et ça gâche un peu la réussite de la mission. Tout ça Stephen Few en parle bien mieux que moi (et ça dès 2010…), à voir par là.

Et Tableau c’est aussi un produit qui est simple, efficace et puissant, facile à apprendre, et qui permet donc de se consacrer à la problématique du client plutôt qu’à la technique désobéissante. Parfaitement alignée avec ma philosophie tout ça !
Bon bin y’a du boulot, que ce soit sur la montée en compétence ou sur la construction de l’offre. Je vous tiendrai évidemment au courant au fur et à mesure. Souhaitez-moi bonne chance 😉

Petite réflexion autour de l’accélération des technologies

En ce moment l’écosystème décisionnel Microsoft est en ébullition. Avec la sortie de SQL Server 2012, c’est tout un camion de nouvelles technologies qui débarque dans notre petit jardin: le DAX, SSAS Tabular, PowerPivot, Power View, Data Explorer, des gros morceaux de SharePoint qui s’incrustent, Windows 8, les évolutions SSIS, le T-SQL version 2012… On a un peu l’impression d’avoir un nouveau langage / environnement à apprendre tous les 3 jours.

Même en dehors de Microsoft le décisionnel bouge beaucoup, et on commence à parler Tableau, Qlikview, SpotFire, qui eux aussi requièrent une certaine expertise voir une expertise certaine.

Et si on revient chez Microsoft mais qu’on sort de la BI, on voit que ça bouge beaucoup, et que ça en fait s’interroger plus d’un !

Oh mon Dieu, du DAX!!!

Oh mon Dieu, du DAX!!!

Alors je crois que c’est le bon moment pour un petit rappel qui nous vient de 2002, de chez Joel Spolsky :

When I was an Israeli paratrooper a general stopped by to give us a little speech about strategy. In infantry battles, he told us, there is only one strategy: Fire and Motion. You move towards the enemy while firing your weapon. The firing forces him to keep his head down so he can’t fire at you.

Traduit approximativement :

Pendant mon service militaire, un général s’est adressé à nous pour un petit cours de stratégie. Dans les batailles d’infanteries, nous disait-il, il n’y a qu’une stratégie: tirer en mouvement. C’est à dire se déplacer vers l’ennemi tout en tirant dans sa direction. Le fait de tirer lui fait baisser la tête, ce qui permet de se déplacer sans qu’il vous tire dessus.

Qu’il applique à la technologie, quelques paragraphes plus loin:

Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features.

De nouveau traduit approximativement:

Pensez à l’histoire des protocoles d’accès aux données issus de Microsoft. ODBC, RDP, DAO, ADO, OLEDB, ADO.NET – tous tout neuf ! Etaient-ils technologiquement incontournables ? Ou le résultat de l’incompétence du groupe de design concerné ? Peu importe, le résultat c’est un tir de couverture : pendant que la compétition passe son temps à adapter son code elle n’a pas le temps d’écrire de nouvelles fonctionnalités.

Et nous autres, les utilisateurs de ces technologies, on est pris au milieu de la bataille.

Les juniors sont découragés par le nombre de technos à apprendre, les séniors s’offusquent d’avoir à apprendre encore un nouveau langage.

Tout ça c’est du « Fire & Motion » de l’éditeur, il est important de ne pas y succomber, car ce n’est pas notre guerre. Pour l’éviter : déterminer quel est votre objectif – réaliser des projets ? – et accomplissez le sans vous inquiéter de ne pas maîtriser l’ensemble des technologies de l’offre.

Ce qui est important c’est :

  • d’avoir les bases, la théorie essentielle indépendante de la techno : parler à un client de ses besoins, la modélisation dimensionnelle, de la gestion de projet élémentaire…
  • de maîtriser au moins une technologie, et connaître ses limites,
  • de savoir apprendre les autres, uniquement au moment où vous avez besoin d’elles et uniquement ce dont vous avez besoin
  • de savoir demander à l’aide.

Pour tous ces points, il y a la communauté. Abonnez-vous aux blogs, participez à FrenchConnection.BI et au GUSS, contactez les experts, bref, ne restez pas tout seul dans le noir 😉

Jusqu’à la fin de votre vie, plus vous apprendrez, plus vous réaliserez à quel point vous en savez peu. C’est de la philosophie de bas étage, mais c’est à garder en mémoire devant l’énormité du travail de veille technologique qui attend tout développeur / consultant qui se respecte.

Bon courage ! 🙂