Un excellent conseil pour améliorer ses graphiques et rapports

C’est Edward Tufte qui l’a remarqué en premier et Stephen Few qui l’a bien vulgarisé : une bonne technique de communication visuelle est de maximiser la quantité d’encre utilisée effectivement pour les données, plutôt que pour la décoration.

Une très bonne illustration de ce principe c’est ce petit GIF, très joliment réalisé par DarkHorse Analytics, des experts canadiens du dataviz. data-ink

A retrouver avec plus de détail dans leur blog (dont une version ralentie).

Power Pivot vers Tabular : I need you!

J’ai besoin d’un coup de main de votre part à tous ! Hier j’écrivais un édito sur le futur de la BI Microsoft, et l’une des idées (améliorer la montée de Power Pivot vers SSAS Tabular) me tient particulièrement à cœur.

J’ai donc écrit un petit message sur le sujet aux copains MVP, et Chris Webb m’a rappelé l’existence d’un ticket Connect de Marco Russo en plein dedans.

Alors vous me voyez arriver avec mes gros sabots, ce serait vraiment vraiment cool si vous alliez voter sur ces différents items pour les faire monter au plus haut dans la liste. Ca aura un vrai impact, les items bien notés étant effectivement lus et considérés par l’équipe de développement de SQL Server.

Une vraie équipe!

Pour voter il suffit juste de disposer d’un compte « Microsoft » (Live ID/Hotmail/celui utilisé pour vos certifs/moi c’est une adresse gmail…), vous pourrez en créer un sur place si besoin, ça prend 2 minutes.

Voici les items concernés:

Merci de voter, et merci de faire passer le mot !

Mettre bout à bout (enchainer) des sources de données dans Excel avec Power Query (Data Explorer)

Un cas d’usage qui pouvait être reproché à Excel, et à Power Pivot également, c’était l’impossibilité de prendre 2 ou plus sources de données identiques et de les mettre bout à bout (en mode UNION pour les SQLeux). Typiquement : j’ai un fichier CSV par mois dans un répertoire, et j’aimerais tous les mettre dans le même tableau Excel pour travailler dessus. Jusqu’alors, la seule solution c’était les copiés/collés successifs à la main, avec tous les risques que ça comporte.

Heureusement Power Query (anciennement Data Explorer) vient à la rescousse ! C’est quoi ? C’est un add-in Excel gratuit, édité par Microsoft, qui sert de mini-ETL à Excel. Sincèrement, c’est peut-être l’outil de BI Self-Service qui enflamme le plus les consultants décisionnel Microsoft en ce moment, alors allez l’installer!

Le mieux pour vous convaincre étant sans doute de passer à la pratique, voici comment employer la chose :

Scénario 1 : 3 tableaux dans le même fichier Excel

  • Pour l’exemple j’ai créé 3 tableaux dans Excel 2013, dans la même feuille ou pas, ça ne change rien, qui contiennent des données à la structure identique:

Append_1

  • Le but : créer une « Query », une requête dans Power Query, sur chacune des tables, pour ensuite les associer en un seul résultat
  • Etape 1 (à répéter 3 fois, une fois par tableau) : a. Je clique dans un tableau (si ce n’est pas fait, n’oubliez pas de « Mettre sous Forme de Tableau » vos données), b. Je vais dans l’onglet Power Query, c. Je créé une Query depuis un Tableau (From Table). Notez que si l’onglet Power Query n’apparait pas, le mieux est de valider qu’il est bien activé (Fichier > Options > Compléments > Gérer : Compléments COM : « Microsoft Power Query for Excel » doit être coché)

Append_2

  • En bleu : l’interface de transformation de données de Power Query, ici on a besoin de rien, donc on valide (Done):

Append_3

  • La Query est créée, elle correspond à un tableau dans un nouvel onglet Excel:

Append_4

  • On répète l’opération 3 fois, une fois par tableau pour obtenir les onglets suivants (oui mon Excel est en anglais, Sheet ou Feuille c’est pareil ;)) :

Append_5

  • Etape 2 : a. On va dans l’onglet Power Query, et b. on choisit « Append »

Append_6

  • Dans l’interface, je choisis 2 Queries, l’ordre n’importe pas ici. Vous noterez que les noms affichés sont les noms des Queries, qui par hasard correspondent ici aux noms des Tableaux. Si vous avez renommé vos Queries, vous retrouverez les nouveaux noms ici:

Append_7

  • Encore une fois, on passe par l’interface de transformation des données de Power Query, encore une fois ici on ne change rien, on valide (Done) :

Append_8

  • Et hop, je me retrouve avec une nouvelle Query qui est la mise bout à bout des 2 premières tables :

Append_9

  • Je répète l’opération, cette fois on prenant dans l’Append le résultat de mon premier Append (Append 1) et le tableau que je n’avais pas pris la première fois :

Append_10

  • Je valide dans l’éditeur et hop, me voilà avec la table complète !

Append_11

  • Chouette non? Alors on peut se dire que c’était beaucoup d’étapes, alors que 3 copiés/collers suffisaient à faire la même chose. Certes. Mais l’avantage énorme des Queries, c’est qu’elles se mettent à jour (cliquer pour zoomer) :

Append_12

  • C’est quand même bien fait non ? 🙂

Scénario 1 – Avancé : Optimisation sur 3 tableaux dans le même fichier Excel

Alors ok, c’est mignon, mais avec la manipulation précédente on se retrouve quand même avec 5 feuilles, et si on ajoute d’autres sources ça va rapidement faire beaucoup trop (2n-1 feuilles avec n sources). Évidemment on peut faire bien mieux, mais il va falloir remonter les manches 😉

  • D’abord il va falloir activer le mode avancé

Append_13

  • Et tant qu’on y est, activez le Fast Combine, ça vous évitera des soucis plus tard :

Append_14

  • Désormais, vous allez pouvoir directement éditer les formules que Power Query utilise pour transformer les données. On retourne donc dans l’interface de transformation des données de Power Query en utilisant une de ces 2 méthodes (ab,ab’c’), ou en créant une nouvelle Query :

Append_15

  • Et dans cette interface, si vous êtes bien passé en mode avancé (voir plus haut), vous devez avoir un petit parchemin à cliquer :

Append_16

  • Qui amène à l’interface de saisie des formules :

Append_17

  • Je vous laisse avec le guide de référence pour voir tout ce qui est possible de faire, perso j’ai la même démarche que dans cet article, je fais toutes les étapes unitairement, et j’essaye d’optimiser ensuite à la main. Dans notre cas :

Append_18

  • En version copiable, à adapter en fonction des noms de vos tableaux (Table1/Table2/Table3) :
let
Source1 = Excel.CurrentWorkbook(){[Name="Table1"]}[Content],
Source2 = Excel.CurrentWorkbook(){[Name="Table2"]}[Content],
Source3 = Excel.CurrentWorkbook(){[Name="Table3"]}[Content],
Source = Table.Combine({Source1,Source2,Source3})
in
Source

Avec cette formule on fait tout en une seule Query, donc un seul onglet, peu importe le nombre de source. Pas mal non ? 🙂

Scénario 2 : 3 fichiers Excel distincts, toujours avec le même format de données

  • Alors de la même manière, on peut faire les fichiers Excel. Je vous donne directement le script, à vous de jouer en manuel pour bien comprendre !

Append_19

let
Source2006 = Excel.Workbook(File.Contents("C:\Temp\2006.xlsx")),
Dataset2006 = Source2006{[Name="Sheet1"]}[Data],
FirstRowAsHeader2006 = Table.PromoteHeaders(Dataset2006),
Source2007 = Excel.Workbook(File.Contents("C:\Temp\2007.xlsx")),
Dataset2007 = Source2007{[Name="Sheet1"]}[Data],
FirstRowAsHeader2007 = Table.PromoteHeaders(Dataset2007),
Source2008 = Excel.Workbook(File.Contents("C:\Temp\2008.xlsx")),
Dataset2008 = Source2008{[Name="Sheet1"]}[Data],
FirstRowAsHeader2008 = Table.PromoteHeaders(Dataset2008),
SourceComplete = Table.Combine({FirstRowAsHeader2006 ,FirstRowAsHeader2007 ,FirstRowAsHeader2008 })
in
SourceComplete

Scénario 3 : 3 fichiers CSV, toujours avec le même format de données

  • Je vous donne directement le script :

Append_20

let
Source2006 = Csv.Document(File.Contents("C:\Temp\2006.csv")),
FirstRowAsHeader2006 = Table.PromoteHeaders(Source2006),
Source2007 = Csv.Document(File.Contents("C:\Temp\2007.csv")),
FirstRowAsHeader2007 = Table.PromoteHeaders(Source2007),
Source2008 = Csv.Document(File.Contents("C:\Temp\2008.csv")),
FirstRowAsHeader2008 = Table.PromoteHeaders(Source2008),
SourceComplete = Table.Combine({FirstRowAsHeader2006 ,FirstRowAsHeader2007 ,FirstRowAsHeader2008 }),
ChangedType = Table.TransformColumnTypes(SourceComplete ,{{"Region", type text}, {"Categorie", type text}, {"Annee", type number}, {"Valeur", type text}})
in
ChangedType
  • Une petite remarque en passant : attention avec les CSV, pour le moment l’interface de Power Query ne permet pas de gérer les séparateurs différents de la virgule, ni nos encodages européens facilement. Pour se faire, il faut modifier sa formule source comme suit:
Csv.Document(File.Contents("C:\Users\Florian\Desktop\2006.csv"), null, ";" , null, 1252)

Avec : votre séparateur, et votre encodage (par défaut 1252 sur Windows, voir le PDF de référence pour les autres – recherchez TextEncoding).

Et après ?

Soit on utilise directement le tableau résultat des Queries Append dans un tableau croisé dynamique, soit on l’ajoute au Data Model et c’est parti pour Power Pivot !

Amusez-vous bien, et n’hésitez pas à venir partager vos trouvailles 😉

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 🙂

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

Projet décisionnel : choisir la bonne technologie dans l’offre Microsoft SQL Server

Je vous parlais tantôt de gestion de projet décisionnel, et en passant je vous disais que le choix d’une technologie pour un projet décisionnel n’était pas une décision anodine. Je voulais vous en dire plus, c’est le moment !

Rappelons d’abord que les projets décisionnels répondent à 3 besoins (cf ma session aux Journées SQL Server pour ceux qui prennent le wagon en route) :

Le décisionnel : Besoin Historisation

Historisation. Les bases de données des applications de l’entreprise sont régulièrement purgées (commandes livrées = commandes effacées du système). Pourtant ces informations sont importantes, il faut les conserver.

Le décisionnel : Besoin Centralisation

Centralisation. Les applications de l’entreprise sont des silos indépendants. Pourtant être capable de croiser ces domaines pour comprendre, par exemple, l’impact des actes commerciaux (CRM) sur les ventes (Logiciel de caisse) est indispensable.

Le décisionnel : Besoin Analyse

Analyse. Mon entreprise est un organisme qui vit dans un environnement. Mes applications (CRM, RH, ERP…) sont des capteurs qui génèrent des informations, des stimuli locaux de ce qu’il se passe dans chaque processus métier. J’aimerai analyser ces informations pour obtenir une image globale et comprendre le monde autour de moi.

Dans un projet décisionnel, on répond à ces 3 besoins à travers 5 fonctions :

  1. L’extraction : à la charge du décisionnel d’aller chercher les données qu’il souhaite
  2. Le nettoyage : ces données doivent être uniformisées et transformées pour être exploitables
  3. Le stockage : on archive les données pour garantir leur pérennité, on les historise pour être capable de comparer le passé au présent
  4. L’analyse : on modélise et interprète les données  pour en tirer un sens
  5. Le reporting : on apporte le résultat des analyses et des requêtes aux utilisateurs

Le décisionnel : 3 Besoins 5 Fonctions
Dans le monde Microsoft, ces fonctions sont assurées par les produits suivants :

Le décisionnel : Produits Microsoft

Ma liste est limitée, il existe d’autres produits (ReportBuilder… et tous les nouveaux sur le Cloud dont Data Explorer) mais on a là les piliers de l’offre.

D’abord on peut se poser la question du pourquoi Microsoft et pas un autre éditeur? Ma réponse c’est que c’est la gamme de produits avec le rapport efficacité / facilité d’usage le plus élevé, et de loin, sur le marché à l’heure actuelle. Notez que ce n’est pas forcément le plus performant sur chaque problématique (Informatica sur l’ETL en temps réel par exemple), ni forcément le plus facile d’utilisation (SSRS…), mais le plus complet, le plus équilibré, celui qui flatte le plus le développeur et l’utilisateur.

On en revient au tableau, pour noter qu’il n’existe au final que 3 domaines ou un choix de technologie existe.

Côté Archivage (je stocke mes données au format source, pour répondre à un besoin d’audit et/ou de sécurité), on stocke directement les fichiers sources sur le disque, ou les tables sans transformation dans la base. Rien de très intéressant par ici. Au passage : attention à ne pas systématiquement utiliser ces données pour vider et régénérer complétement le DWH à tous les chargements. Cette pratique est une bonne pratique uniquement dans certains cas d’utilisation mais pas dans tous. Voir les 2 excellents documents de Marco Russo et Alberto Ferrari sur le sujet, spécifiquement le chapitre « Classification of BI solutions« , dans le PDF introduction.

Côté Reporting, le choix se fait en fonction du type d’utilisation souhaité. Des analyses à la demande ? Excel et les TCD. Du reporting de masse ? SSRS. Du « collaboratif » ? SharePoint et ses Services. Un tableau de bord ? PerformancePoi… non je blague, n’importe quoi d’autre 😉

Le problème avec l’offre jusqu’à aujourd’hui, c’était que le choix de solution de reporting impactait le choix du moteur d’analyse. En effet les tableaux croisés dynamiques d’Excel et les services SharePoint étaient obligatoirement branchés sur du SSAS classique (maintenent BISM-Multidimensional). Heureusement c’est une contrainte qui saute, ou plutôt qui évolue, avec SQL Server 2012 et la refonte de SSAS. Certes cette refonte introduit de nouvelles contraintes (PowerView sur du Tabular), mais elle libère Excel et les TCD.

Ce qui fait que le choix va se faire beaucoup plus librement sur le moteur d’analyse, entre :

  • Monter un datamart répondant à un besoin spécifique directement dans la base SQL
  • Construire un cube : SSAS – BISM Multidimensional
  • Construire un modèle tabulaire : SSAS – BISM Tabular

Et avec Excel 2010 (plus PowerPivot dans certains cas) on peut accéder facilement à ces 3 sources et offrir des tableaux croisés dynamiques bien velus à nos utilisateurs, indépendamment du moteur d’analyse. Ça c’est cool 🙂

La dernière question qui reste est donc quel moteur d’analyse choisir entre SSAS-Multidimensionnal, SSAS-Tabular ou le dB Engine ? La réponse n’est pas encore définitive, elle se précisera au fur et à mesure que nous ferons des projets sur les technos, mais des pistes apparaissent déjà:

  • BISM – Multidimensional : Techno « complexe », données hiérarchisées, grosses volumétries avec reporting à niveau agrégé, relations complexes (many to many…), comparaisons temporelles (mais pas trop les faits en période), des chiffres (pas trop des lettres)
  • BISM – Tabular : Techno simple et performante (elle rattrape les erreurs de développements assez bien), rapide à implémenter, beaucoup plus libre sur le modèle de données, agrège bien mais traite aussi bien le détail, costaud sur le distinct count, attention cependant aux trop grosses volumétries
  • Datamart SQL : J’entends par là des tables d’agrégats bien pensées. Dedans on mettra tout le reste 🙂

Pour plus d’infos, n’hésitez pas à consulter le webcast d’Aurélien Koppel et François Jehl sur le sujet, et n’hésitez pas non plus à en causer dans les commentaires, tous les avis sont bons à prendre!