04 - Ah, ces fameux dashboards
- Florian Colin
- 4 déc. 2024
- 9 min de lecture
Dernière mise à jour : 18 janv. 2025
"Il y a des dashboards partout, on n'y comprend rien !"
"Non, ne regarde pas celui-là l'information n'est pas fiable dedans, tout le monde le sait..."
"Je n'arrive pas du tout à trouver ce que je veux dans ce rapport, il y a tout sauf ce que je veux."
"Allez, on va encore faire un dashbaord pour faire semblant qu'on prend le sujet, mais personne ne va l'ouvrir et s'en servir c'est sûr !"
Vous avez peut-être déjà entendu ces phrases autour de vous ? Moi, oui ! Dans beaucoup d'entreprises on parle depuis quelques années d'une maladie du dashboard (ou "tableau de bord" en version française). Les avancées technologiques nous permettant de consolider de très grand volume de données, tout le monde s'est dit : "il faut utiliser toutes ces données ! Mais comment?.. Faisons des dashboards !". S'en est suivi une phase d'euphorie où les éditeurs de logiciels de dashboarding ont fait évoluer leurs outils pour faciliter toujours plus la connexion aux sources de données et l'aide à la visualisation si bien que quasiment tout collaborateur dans une entreprise est capable de construire "son" dashboard et souvent avec la technologie de son choix. Et c'est ici que les difficultés sont apparues.
Dans les grands éditeurs du milieu, on peut citer Tableau Software, Microsoft Power BI, Qlik Sense, Google Looker Studio, Google Data Studio, Klipfolio… et ne surtout pas oublier Microsoft Excel ! Beaucoup d'outils ont émergé dans les entreprises, si bien que le parc applicatif s'est complexifié et qu'il est devenu très difficile de s'y retrouver et de mettre de la cohérence entre les différents rapports construits, ce qui complique grandement l'usage. Le premier conseil à cette étape est donc celui-ci : choisissez un seul éditeur officiel pour la majorité des dashboards de votre entreprise, et un éditeur secondaire pour quelques rapports si vous êtes une très grande entreprise et qu'il est important de minimiser les risques (négociation tarifaire, dépendance technologique) en s'assurant de pouvoir transitionner d'une technologie à une autre sans difficulté majeure.
Le deuxième point d'attention est la responsabilisation. Cela paraît peut-être une évidence avec du recul, mais parfois on peut l'oublier lorsque l'on est pris dans l'engouement de mettre des données en forme pour y voir plus clair : tout dashboard doit avoir un responsable ET un processus d'usage. Non, on ne construit pas un dashboard pour répondre à une question que se pose un directeur à un moment donné. Dans ce cas on construit une analyse et on livre une réponse (qui peut inclure des graphiques et un outil ad-hoc), mais cette analyse doit être archivée lorsque la réponse a été fournie et discutée, et l'éventuel dashboard qui aurait aidé à construire la réponse doit être archivé avec elle. Sauf si une forme de suivi doit être initiée et dans ce cas un responsable est identifié et il sera en charge de donner des mises à jours régulièrement par rapport aux chiffres consolidés.
Pour cela, l'approche Business Flow consiste ici à suivre la continuité des actions de l'étape "Connaître" (cf [1]) :
Une fois que l'on a validé les objectifs à atteindre, les jalons (ou "Key Results" dans la démarche OKR) par lesquels on vise de passer, et les métriques qui permettent de vérifier le franchissement de ces jalons (cf [2]), alors on obtient une liste de l'ensemble des métriques que l'on doit être en capacité de calculer et des responsables du suivi de chacune de ces métriques : les "Key Results owners" ;
On identifie les données nécessaires pour calculer chacune de ces métriques et on s'assure qu'elles soient accessibles dans des bases de données (cf [3]) ;
On construit un dashboard de suivi par objectif à atteindre (donc couvrant un ensemble de "Key Results") ou pour des ensembles d'objectifs cohérents, ce dashboard étant la responsabilité de la personne en charge d'atteindre les objectifs (souvent un Directeur, ou un Manager) ;
Le responsable du dashboard est en charge de mettre en place le rituel de suivi des indicateurs présentés, d'expliquer leurs variations, de célébrer les succès lorsque les jalons sont atteints ou de construire des plans d'actions si jamais il observe une déviation par rapport aux cibles. Dans la démarche OKR il s'agit a minima d'une réunion mensuelle de présentation des résultats par rapport aux objectifs et jalons fixés.
Cette méthodologie assure que chaque dashboard soit associé à une personne et à un rituel d'usage, de sorte que si le rituel s'arrête alors le dashboard doit être archivé. Un dashboard qui n'est pas utilisé régulièrement ne doit en aucun cas être référencé dans une base de connaissance de l'entreprise. Dans l'idéal, tout dashboard doit être construit en réponse à un besoin business réel, il doit avoir un cadre d'usage et un retour sur investissement estimé. Faire des dashboards "au cas où", ou en imaginant qu'on va construire un processus d'usage et trouver des utilisateurs a posteriori, est le meilleur moyen de perdre du temps, de l'énergie, de la motivation des équipes et de l'argent. C'est la fausse idée que vous avez peut-être déjà entendu (ou formulée vous-même ?) : "présentons déjà l'ensemble des données dans un dashboard, ensuite on trouvera forcément des gens intéressés pour s'en servir et on travaillera avec eux !". Voici une des meilleures manière de voir ses Data Analysts démissionner en série !
Il est également important de suivre un certain nombre de bonnes pratiques lorsque l'on construit un rapport, dashboard ou tout autre outil de suivi. Et comme pour bon nombre de choses, on peut utiliser un acronyme pour se rappeler des 4 bases : SiReDéC !
Simplicité : Ne pas surcharger chaque page et garantir une navigation la plus simple possible pour accéder à l'information. Beaucoup de matière existe sur l'art de présenter de l'information le plus simplement et efficacement possible (cf [4]) :
Responsabilisation : Le nom et le contact de la personne responsable du dashboard doit être accessible facilement pour répondre à toute question ;
Définitions : Chaque métrique présentée doit être définie clairement (idéalement grâce à un lien vers un dictionnaire des données, cf [3]) de sorte que n'importe qui puisse comprendre le sens des chiffres présentés, même sans appartenir au domaine métier ;
Cible : Chaque métrique présentée doit être accompagner d'une cible de sorte que l'on puisse rapidement répondre à la question "c'est bien ou c'est pas bien ?".
Enfin, une fois que l'on a construit le premier niveau de dashboard permettant de savoir si oui ou non on a réussi à atteindre les jalons que l'on avait ciblés, l'entreprise peut atteindre un premier niveau de suivi très intéressant de ses opérations. On appellera ces dashboards par la suite des "decks de suivi". Et si on atteint effectivement les cibles que l'on s'était fixé alors c'est super, on peut célébrer les victoires avec les équipes impliquées ce qui permet de garder motivation et énergie pour poursuivre les efforts ! Mais que se passe-t-il si on n'atteint pas les cibles ? Les dashboards existent certes, et on peut voir que certaines cases sont rouges, ou que des points sont sous une barre au lieu d'être au-dessus… La question qui vient naturellement est alors : pourquoi ? Qu'est-ce qui explique que l'on ait raté à tel ou tel endroit ? Chez Amazon on appelle ce cheminement "Root cause analysis" (analyse de la cause racine d'un problème). L'idée est d'être capable de décortiquer une métrique pour comprendre ce qui a cloché. Et vous l'aurez compris, les decks de suivi ne contiennent pas la granularité d'information qui permet de creuser dans ce niveau de détails. Ils ne sont pas fait pour ça. Il est donc nécessaire de construire un second niveau de dashboards, que l'on appellera dans la suite "Deep dive decks" en reprenant la terminologie utilisé dans les opérations chez Amazon. Ces rapports doivent permettre d'identifier le plus précisément possible d'où vient un problème rencontré dans une métrique majeure.
Par exemple, si on imagine que votre entreprise travaille dans la livraison de colis à des particuliers, une de vos métriques majeures pourrait être le respect de la promesse de livraison faite à vos clients. Vous pourriez viser une cible mensuelle de 98% de colis livrés dans les temps par exemple. Une fois le mois terminé vous constatez que vous n'avez atteint une performance que de 95% sur cette métrique, il y a donc un delta par rapport à votre cible de 3% (on parle plus souvent en "bps" pour "points de base" puisqu'il s'agit d'un écart et non d'un pourcentage dans ces cas là mais simplifions les choses ici). Où avez-vous raté ? Est-ce une contre-performance sur l'ensemble du mois ou seulement sur quelques jours durant le mois ? Est-ce que la contre-performance arrive plus régulièrement un jour de la semaine en particulier ? Est-ce que les colis en retard provenaient du même site de distribution ? Ou est-ce que le problème a impacté une ville en particulier ? Ou une typologie de colis ? Nous reviendrons sur toute cette démarche dans une partie suivante sur la mise en place de rituels d'animation, mais cela illustre déjà ici pourquoi il est nécessaire de construire des "deep dive reports". Etre capable de creuser dans la donnée, de modifier les axes d'analyse (temporels, spatiaux, modaux, etc.) est ce qui permet de rétrécir le faisceau de présomptions et donc d'aller poser des questions et identifier les défaillances dans nos opérations ou notre stratégie de la manière la plus précise et efficace possible.
Avant de clore cet article, abordons une dernière question cruciale qui a pollué beaucoup d'entreprises. Ces entreprises ont construit, comme le continent de plastique, un continent de dashboards inutiles et inutilisés, qui ont consommé de l'énergie, de la motivation des équipes et de l'argent pour... rien.
Quand est-il très très important de ne pas construire un dashboard ?
Pour "voir" : "parce qu'on ne se rend pas bien compte de ce que les données donneront, donc présentons déjà les données dans un dashboard et après on verra comment on peut utiliser cette matière"
"Pour occuper les équipes : elles n'ont rien à faire en ce moment donc autant qu'elles construisent des dashboards, peut-être qu'on y trouvera une pépite !"
"Pour que les équipes se forment d'elles-mêmes à ces technologies et se les approprient, comme ça elles seront plus à l'aise pour s'en servir après"
"Parce que si on présente les données dans un dashboard et qu'on le diffuse, cela donnera certainement plein d'idées à certains collaborateurs, c'est comme ça qu'on génère de l'innovation !"
Si vous avez déjà entendu ou prononcé l'une de ces phrases, alors il y a de grandes chances que votre entreprise ait contribué à alimenté le continent de dashboards inutiles. Même s'il peut y avoir de bonnes intentions derrière chacune de ces phrases, dans la très grande majorité des cas cela conduit à un échec. Pourquoi ?
Parce qu'un dashboard sans processus d'usage, c'est comme une voiture sans moteur : ça peut être très beau et agréable à regarder de temps en temps, mais ça ne vous emmènera nul part.
C'est par l'usage que n'importe quel dashboard crée de la valeur. Un usage signifie identifier un propriétaire du dashboard et un rituel d'usage à une fréquence donnée (quotidien, hebdomadaire, mensuel, etc.). Le propriétaire du dashboard est le garant du process d'usage. Ce n'est pas forcément lui qui le construit, ou qui le construit en entier. Le propriétaire d'une maison peut gérer la peinture ou poser le parquet dans son salon, mais faire appel à des professionnels pour l'électricité et la plomberie. Ou déléguer toute la construction. Il n'en reste pas moins le propriétaire puisqu'il a l'usage de sa maison. C'est la même logique avec le responsable d'un dashboard.
Ne pas penser l'usage en amont de la création amène au premier gros problème de ces dashboards : "c'est pas mal, mais il manque toujours quelque chose". Ou bien, "je n'aurais pas présenté l'information comme ça". S'enchaîne un dialogue sans fin pour modifier tel ou tel graphe, changer la taille de la police du titre, ajouter ce tableau avec les valeurs, etc. Si vous voulez que les équipes se forment à la création ou à l'usage de dashbaord, alors formez les à cela. S'il est bon que certaines personnes mettent les mains dans la technique de création des dashboards, alors faites le en support d'un processus d'animation et vous ferez d'une pierre deux coups en faisant monter en compétence les équipes ET en créant des idées et de la valeur. Nous vivons parfois avec cette utopie que si on diffuse le plus d'informations possibles, alors étant donné le grand nombre de personnes dans nos entreprises ou nos équipes, au moins une d'entre elles saura dénicher la bonne idée dans tout ce marasme. Bien sûr il est vrai que cela peut arriver. Gagner à la loterie aussi, ça peut arriver, et c'est à peu près aussi fréquent. Donc autant faire en sorte que tous les tickets soient gagnants en adossant chaque dashboard à un usage, non ?
Points clés en résumé :
Les dashboards sont nécessaires pour suivre de manière quantitative les opérations et les progrès d'une entreprise
Minimiser le nombre d'éditeurs de dashboarding au sein d'une entreprise simplifie toute la phase d'animation
Certaines lignes de conduite de construction de dashboard permettent de maximiser l'efficacité dans l'usage, notamment SiReDeC
Il y a 2 niveaux de dashboards à distinguer : les "Decks de suivi" pour les comités d'animation, et les "Deep dive reports" pour identifier les problèmes racines expliquant les contre-performance
Chaque dashboard doit avoir un responsable et un processus d'usage régulier
A suivre : Une fois que l'on sait où on souhaite aller, que des cibles à atteindre sont définies, que le socle de données est construit et alimenté et que les dashboards de suivi et de deep dive sont en place, il est grand temps de se servir de toute cette matière pour démarrer l'animation !
[4] Plusieurs sources d'information qui peuvent être utiles pour agencer au mieux ses dashboards :
Commentaires