Vous pouvez jeter vos cahiers de recette !
Le résumé pour les plus pressés
Depuis toujours la phase d’UAT d’un projet de BI repose sur des scénarios lourds et pénibles à exécuter ne garantissant qu’une fiabilité partielle. Ce qui explique aussi pourquoi le Métier - un peu comme vous, toujours pressé ;) - n’a que peu de temps à consacrer aux UAT.
Voici une stratégie alternative qui fait l’unanimité coté Métier et qui consiste à développer une seconde application miroir...
1. Le contexte et sa problématique
Ok, je fais avec ce post un écart à ma ligne éditoriale “Les cas d’usage de la BI” pour parler Méthode. Vous me direz que c’est à contre-courant à une époque où l’entreprise cherche de la réactivité, de la créativité dopée par les méthodes Agiles (I Like). En témoigne mon dernier post sur la méthode Kimball ici qui avait fait un flop...
Les méthodes Agiles ont considérablement simplifié les projets et réduit les risques avec quelques effets de bord, depuis les spécifications non écrites qui génèrent des “On n’avait pas dit ça.” jusqu’à la Recette en mode éclair “On pourrait mettre la version à recetter en Prod, comme ça si c’est ok on gagne du temps ?”.
Tout ceci reste négligeable au regard des bénéfices de la méthode dont le plus important à mes yeux - ayant pratiqué les méthodes en tunnel - étant d’atterrir dans 90% des cas avec une application incomplète certes (objet du prochain sprint) mais sans surprise majeure car construite par itérations et régulièrement montrée aux utilisateurs. De mémoire, le taux de réussite de mes projets BI au début des années 2010 avoisinait les 50%, comprenez qu’un développement sur 2 terminait à la poubelle.
Mais le manque de temps ne fait pas bon ménage avec les tests de Recette...
Bonne nouvelle, l’entreprise gagne en vitesse d’exécution mais dit autrement cela veut aussi dire que le Métier a de moins en moins de temps.
La problématique à résoudre est donc la suivante : Comment organiser au mieux la phase d’UAT, quelle est la stratégie ?
En réalité, la question ne s’adresse pas aux Métiers mais au Dev car il s’agit bien de préparer cette étape en amont pour qu’elle se passe bien. L’objectif est d’entrer sereinement en phase de Recette pour contenir le flux d’anomalies.
Certes quelques remarques clés pour le bon usage de l’application vont remonter mais elles ne seront pas structurantes et donc pas synonymes de refonte du modèle de données ou d’erreurs dans les règles de calcul d’un KPI voire pire de données inexploitables car fausses.
Bref comment sécuriser cette dernière étape clé ?
Franchement, il m’a fallu beaucoup de temps pour trouver la bonne préparation. Voici comment je faisais jusqu’ici :
1. Coder en respectant les principes et la syntaxe de l’éditeur > Relecture simplifiée
2. Comparer en 5 points et sur la granularité la plus fine - par exemple un ticket de caisse d’un client - les données sources et celles chargées dans l’app de BI
3. Vérifier à la main tous les KPIs et dans toutes les dimensions pour le groupe constitués des 5 points précédents
4. Comparer les KPIs avec une source interne faisant déjà référence au niveau Métier. Avant Qlik, il y avait bien du reporting...
5. Faire valider par le Métier le fond puis une fois validé, la forme
Et puis en 2022, suite à une mission pour un Métier peu enclin à passer du temps à recetter, j’ai dû changer de méthode pour celle-ci qui se résume à une action mais attention ça pique les yeux au début :
Recommandé par LinkedIn
1. Charger la même donnée source dans une seconde application - par exemple Excel, Looker ou Tableau - pour y redévelopper la même application sans s’attarder sur la forme, une version brute.
2. Prenons du recul
Je vous laisse y réfléchir mais imaginez une seconde : 2 app pointant sur la même donnée et qui affichent exactement la même chose. Quoi de mieux pour garantir que l’outil de BI cible se contente de faire parler la donnée sans la trahir ?
Et c’est bien là, la grande différence avec toutes les méthodes à scénarios que j’ai pu croiser : qui dit scénario implique que rien n’est exhaustif, seulement des points de contrôle laissant passer des bugs. Adieu les cahiers de recette soi-disant complets, bien lourds et des plus pénibles à lire.
Pour l’avoir testé(s), j’ai fait de ce cas particulier une bonne pratique.
Vive la double compétence en BI - perso j’ai choisi Qlik & Looker !
Si cette approche peut sembler couteuse en première lecture (5 jours de charge en moyenne), dans la pratique elle tombe sous le sens, elle raisonne comme une évidence opérationnelle et cette forme d’évidence reste de mon point de vue, le meilleur témoin d’une bonne pratique.
L'argument le plus inattendu étant “Si on partait sur Looker ?” et le Métier reconsidère l'UAT vue désormais comme un moment d’innovation, un comble quand on connait l’historique et un vrai bonheur pour l’équipe de Dev !
Conclusion
Je vous laisse me dire comment vous faites pour recetter. Et c’est bien l’idée de ce Post : vous faire réagir pour renforcer la bonne pratique avec vos retours d’expériences. A suivre mon retour d'expérience sur comment l'AI pourrait aider à recetter les app de BI.
Neglect to acknowledge that DW/BI success is tied directly to business acceptance. If the users haven't accepted the DW/BI system as a foundation for improved decision making, your efforts have been exercises in futility. Common Pitfalls to Avoid by Kimball
Tous nos dashboards sont donc désormais disponibles sur Looker mais c'est moche !:
Partagez votre expérience et recevez nos articles :