Power BI: 15 erreurs courantes chez les débutants 🤔 (2 de 3)

J’ai été la première à offrir des formations Power BI à Montréal (et longtemps la seule), de sorte que j’ai formé un nombre impressionnant d’usagers. La grande majorité des professionnels à qui j’ai enseigné et la grande majorité des professionnels à qui j’enseigne en ce moment sont d’abord et avant tout des usagers d’Excel et ont peu ou pas d’expérience en modélisation de données ou avec d’autres solutions d’intelligence d’affaires. La plupart ont également l’impression qu’apprendre Power BI se fera sans casser des oeufs et qu’ils deviendront autonomes très rapidement. Cet article a pour but de vous donner l’heure juste sur l’apprentissage de Power BI, surtout si vous êtes présentement des usagers Excel. N’allez pas penser que je souhaite vous décourager, bien au contraire! Power BI est une solution extraordinaire, qui est en train d’être implantée dans de nombreuses entreprises et c’est tant mieux! Je suis ravie de voir l’enthousiasme des entreprises pour cette solution extraordinaire de Microsoft. Cet article a simplement pour but de mieux calibrer vos attentes et d’attirer votre attention sur les erreurs Power BI les plus courantes que j’ai observées chez les débutants, justement de façon à faciliter votre apprentissage et vous permettre de bénéficier pleinement de la solution.

Cet article fait suite à l’article Power BI: 15 erreurs courantes chez les débutants (1 de 3).

#6 Ne pas chercher à optimiser les requêtes

Les débutants en Power BI ont tendance à ne pas saisir complètement l’aspect “performance” des requêtes.  Ce faisant, lorsqu’ils écrivent des requêtes dans l’éditeur Power Query, ils ne cherchent pas à les optimiser, i.e. à réduire au minimum les étapes appliquées. Ils peuvent, par exemple, utiliser 10 étapes appliquées (et donc 10 lignes de code, ayant chacune sa lourdeur) pour effectuer une transformation de données qui pourrait être effectuée en une seule étape. Ceci constitue une grave erreur dans Power BI. S’il est vrai que plus l’éditeur de requêtes évolue, moins il devient essentiel de maîtriser le langage M, je suis d’avis qu’une connaissance de base minimum du langage M permettra d’améliorer significativement la performance des requêtes.

De même, il faut se questionner sur les sources de données auxquelles on se connecte. Devrait-on se connecter en mode d’importation de données? En mode de connexion directe? Ou encore avec via les nouveaux modèles composites? Devrait-on se connecter à la base de données complète? À une vue? Devrait-on rédiger une requête SQL dans la requête d’importation? Les débutants en Power BI ont tendance à ignorer ces questions et peuvent donc être confrontés à des problèmes de performance importants.

Modes de connexion aux données sources

#7 Effectuer des transformations dans la source de données

Certains débutants en Power BI ne profitent pas assez de la flexibilité de l’éditeur de requêtes. Ce faisant, ils apportent encore des changements manuels à leurs données sources, avant de les importer dans Power BI, au lieu de laisser l’outil travailler pour eux et automatiser le processus à chaque mise à jour des données. Ceci est une erreur impardonnable avec Power BI.

Par exemple, j’ai vu un apprenant qui devait consolider des données provenant de fichiers hebdomadaires. Chaque semaine, il recevait par courriel un fichier, qui représentait les données de la semaine. Et tous ces fichiers comprenaient un onglet avec un nom différent. Ce faisant, il modifiait manuellement les noms de ces onglets, avant de les enregistrer, afin qu’ils aient tous le même nom et puissent ainsi être importés via l’option “Dossier”. Avec une connaissance minimale du langage M, il n’aurait pas eu à faire de telles modifications.

Voici un article à ce sujet: Excel : Fusionner des fichiers avec des noms d’onglets différents à l’aide de Power Query

Vous devez analyser de grandes quantités de données et les présenter dans des rapports et tableaux de bord, avec des indicateurs de performance pertinents ? Développez vos compétences avec nos formations en Power BI en français ou en anglais.

#8 Faire des calculs dans la source de données

Plusieurs débutants en Power BI ont aussi tendance à faire une bonne partie, voire tous leurs calculs, dans les sources de données. D’abord, il faut savoir que cela peut affecter la performance (voir point #10) mais en surcroît, cela peut aussi créer des problématiques additionnelles. Il s’agit d’une erreur Power BI à éviter à tout prix.

Par exemple, ci-dessous, un cabinet comptable a ajouté une colonne dans ses données sources pour calculer le taux de rotation des stocks de chacun de ses clients et cela sur deux années. Cela peut permettre de créer quelques visualisations comme le taux de rotation moyen par client ou le taux de rotation moyen par année. Par contre, qu’adviendra-t-il quand le cabinet voudra comparer l’écart entre le taux de rotation des stocks du client A avec la moyenne des taux de rotation des stocks est autres clients?

Je suis d’avis qu’il est absolument essentiel de maîtriser les bases du langage DAX pour créer des rapports pertinents dans Power BI. Et un des concepts qu’il faut maîtriser, c’est ce que l’on appelle en anglais le Measure branching où chacune des mesures de notre modèle de données découle d’une autre mesure. Par exemple, on fera:

• Une mesure pour obtenir les ventes (et si la colonne ventes n’existe pas, on n’aura pas besoin de la créer, on pourra utiliser une fonction itérative comme le SUMX par exemple)
• Une mesure pour les coûts
• Une mesure pour les marges (mesure ventes moins mesure coût)
• Une mesure pour les marges en % (mesure marges divisée par mesure ventes)
  • Imaginez ici un instant que vous n’ayez pas calculé les mesures précédentes, la mesure pour les marges en % serait alors plus complexe à écrire
  • Pire encore, imaginez que vous ayez inséré la formule dans une colonne calculée dans la source… pour obtenir le total, vous feriez la somme des % de marges, ce qui fournirait un résultat erroné
  • Le fait de créer une hiérarchie de mesures rend le modèle très souple et facile à déboguer, le cas échéant en plus de permettre d’effectuer des calculs justes

Plus précisément, avec nos données d’inventaire, on pourrait créer la hiérarchie de mesures suivante, qui est très simple:

Ceci nous permettrait de pouvoir comparer aisément le taux de rotation d’un client vs le secteur et ce, pour l’ensemble des années.

#9 Ne pas saisir l’importance du contexte de filtres

Certains débutants ont bien compris l’importance de la normalisation de données et du langage DAX mais ne maîtrisent pas ce que l’on appelle le contexte de filtres des rapports. Voici par exemple ce que j’ai vu chez un client. Celui-ci a construit un rapport complet qui comparait les données de 2017 vs 2016. Ses données sources comprenaient bel et bien une colonne Année. Il avait donc bien normalisé ses données. Il avait aussi utilisé le langage DAX pour créer ses mesures, mais ne saisissant pas très bien le contexte de filtres, il a procédé de la façon suivante:

• Ventes 2016 = CALCULATE ([Ventes], Ventes[Année]=”2016″)
• Ventes 2017 = CALCULATE ([Ventes], Ventes[Année]=”2017″)
• Écart Ventes 2017-2016 = Ventes 2017 – Ventes 2016

Quel est le problème avec cette procédure à votre avis?

Et bien, quand est venu le mois de janvier 2018, le client, pris de panique, m’a passé un coup de fil: “Mais c’est l’enfer Power BI! Tous nos rapports sont à refaire et comme c’est là, ils seront à refaire chaque année!”. N’ayant pas considéré le contexte de filtres et n’ayant pas profité des mesures de Time Intelligence en DAX, mon client se trouvait effectivement dans un fichu pétrin. Il devait maintenant recréer toutes ses mesures pour 2018 et refaire ses visualisations. Cette approche, je l’ai observée chez plusieurs débutants, qui s’en sont mordus les doigts par la suite! C’est une erreur très courante auprès des débutants dans Power BI.

#10 Ne pas optimiser pour la performance

Power BI repose sur un engin qui compresse les données en colonnes. Ce faisant, il est primordial de normaliser les données. Il faudrait toujours viser à ce que les tables de faits ne possèdent que les valeurs à analyser et des clés pour créer des relations avec les tables de dimensions. Rien d’autre. Comme il est plus facile de compresser des nombres que du texte, et comme les tables de faits sont les tables les plus volumineuses d’un modèle de données, le respect de cette règle sera très profitable au niveau de la performance.

De même, les débutants ont tendance à importer beaucoup trop de données (trop de colonnes), comme s’il ne serait plus possible, par la suite, d’ajouter de nouvelles colonnes au besoin. Ceci a un effet direct sur la performance.

Ne manquez pas la suite de cet article: Power BI: 15 erreurs courantes chez les débutants (3 de 3).

Formation complémentaire

Pour débuter votre apprentissage sur ce bonnes bases, inscrivez-vous à notre formation Power BI (niveau 1).

Voici quelques commentaires d’apprenants ayant suivi cette formation :

La mission du CFO masqué est de développer les compétences techniques des analystes et des contrôleurs de gestion en informatique décisionnelle avec Excel et Power BI et favoriser l’atteinte de leur plein potentiel, en stimulant leur autonomie, leur curiosité, leur raisonnement logique, leur esprit critique et leur créativité.