Dashboards de direction vs dashboards opérationnels

Le mot « dashboard » cache deux artefacts réellement différents. Le dashboard de direction que le directeur financier consulte deux fois par semaine, entre deux réunions, pour voir si le trimestre est toujours sur la trajectoire. Le dashboard opérationnel que le responsable du support garde ouvert dans un onglet de navigateur toute la journée, rafraîchi toutes les quelques minutes, pour router le travail entrant et attraper une file qui commence à s’engorger. Même mot, même outil de BI, souvent le même concepteur ; des métiers très différents, des formes très différentes.

L’erreur la plus courante au niveau de l’artefact, c’est de concevoir un seul dashboard et d’essayer de lui faire servir les deux publics. Le dirigeant le trouve trop détaillé et trop bruyant. L’utilisateur opérationnel le trouve trop agrégé et trop lent. Aucun des deux ne l’utilise longtemps. La correction est rarement un meilleur dashboard unique ; c’est de reconnaître que les deux sont des artefacts différents avec des règles de conception différentes.

Cet article est la version comparative de la conversation. Il s’associe à l’article sur la discipline de conception de dashboards, qui couvre les règles de conception qui s’appliquent aux dashboards en général ; ici, l’angle porte sur les deux formes spécifiques qu’un dashboard qui fonctionne prend une fois qu’on sait quel métier il fait.

La manière la plus claire de distinguer les deux artefacts, c’est de regarder le métier de l’utilisateur au moment où il ouvre le dashboard.

Un dirigeant ouvre un dashboard pour répondre à un petit ensemble de questions de pilotage : le trimestre est-il sur la trajectoire, sommes-nous en avance ou en retard, où sont les surprises, qu’est-ce que je devrai aborder la semaine prochaine en comité de direction. Les questions portent sur la position, la trajectoire et l’exception. Elles se lisent en quelques minutes, souvent sur un téléphone, entre deux autres réunions. Les décisions qu’elles soutiennent sont hebdomadaires, mensuelles, parfois trimestrielles.

Un utilisateur opérationnel ouvre un dashboard pour répondre à un autre ensemble de questions : qu’y a-t-il dans ma file en ce moment, quel dossier je prends en suivant, y a-t-il un pic auquel je dois réagir, quelque chose s’est-il cassé dans la dernière heure. Les questions portent sur du travail précis, des tickets précis, des clients précis. Elles se lisent en continu, parfois pendant des heures d’affilée, souvent sur un poste à côté du reste des outils de travail. Les décisions qu’elles soutiennent se prennent à la minute ou à l’heure.

L’écart devient évident quand on écrit les questions côte à côte. Un dashboard conçu pour le premier ensemble ne peut pas répondre au second sans devenir écrasant. Un dashboard conçu pour le second ne peut pas répondre au premier sans devenir inutile au dirigeant. Les deux artefacts divergent au niveau de la question, avant qu’un seul graphique n’ait été dessiné.

Un dashboard de direction est une vue petite, synthétique, riche en comparaisons, conçue pour être lue vite et faire agir par délégation, pas par intervention directe.

La forme est constante. Cinq à sept métriques titre, chacune avec une comparaison claire (contre la période précédente, contre l’objectif, contre la prévision). Une tendance visible sur chaque métrique sans avoir à cliquer. Une lecture du « et donc » qui tient en une phrase : « en avance sur le chiffre d’affaires, en retard sur la rétention, la charge support monte ». La page ne demande pas d’interprétation ; la réponse est dessus.

Le détail est disponible, mais en cliquant. Le dirigeant peut entrer dans une métrique pour voir la ventilation, les segments, la vue régionale, mais la page d’accueil est la réponse, pas la navigation. La cadence de rafraîchissement est quotidienne ou hebdomadaire. Le chiffre d’hier suffit pour la plupart des décisions de direction ; le rafraîchissement intra-journée vaut rarement sa complexité.

Là où les dashboards de direction échouent : ils accumulent des métriques jusqu’à ne plus rien synthétiser, ils perdent leurs comparaisons et deviennent des murs de chiffres absolus, ils sont liés depuis trop d’endroits et deviennent une vue « état général » qui ne soutient aucune décision précise, et ils sont hérités par un public qui ne les lit plus mais pour lequel personne n’ose retirer la page.

Un dashboard opérationnel est un outil de travail, gardé ouvert pendant la garde de l’utilisateur, rafraîchi en continu, et intégré au workflow qu’il soutient.

La forme est différente. Moins de chiffres titre agrégés, plus de files, plus de filtres, plus de drill-downs vers l’enregistrement précis sur lequel l’utilisateur doit agir. Le dashboard opérationnel d’un responsable support n’affiche pas « tickets résolus ce mois-ci » ; il affiche « tickets actuellement en attente au-delà du SLA, classés par priorité, avec un clic vers chacun ». Le dashboard opérationnel d’un dispatcher logistique n’affiche pas « temps de livraison moyen ce trimestre » ; il affiche « véhicules actuellement en retard sur planning, avec leur dernière position et leur prochain arrêt ».

Le rafraîchissement est quasi temps réel, souvent en moins d’une minute, parce que les décisions que le dashboard soutient ne peuvent pas attendre demain. Le dashboard est intégré aux systèmes opérationnels dans lesquels l’utilisateur travaille déjà, pour que l’action soit à un clic plutôt qu’à trois onglets. La propriété revient au responsable opérationnel, pas au sponsor exécutif ; les métriques évoluent à mesure que la réalité opérationnelle évolue, et le dashboard est mis à jour en continu, pas « possédé » par une revue trimestrielle.

Là où les dashboards opérationnels échouent : ils sont traités comme des tableaux d’affichage plutôt que comme des outils de travail, le signal de fraîcheur est absent ou faux et l’utilisateur commence à se méfier de la vue en direct, les drill-downs ne mènent pas vraiment à l’action que l’utilisateur doit faire, ou le dashboard est construit dans un outil qui ne peut pas suivre la cadence de rafraîchissement que le travail exige.

Mettre les deux artefacts côte à côte rend les divergences explicites, et explique pourquoi un seul dashboard satisfait rarement les deux.

Public : un petit nombre de dirigeants, responsables ou administrateurs pour le premier ; un nombre plus large d’utilisateurs opérationnels pour le second.

Cadence de décision : hebdomadaire à trimestrielle pour le premier ; à la minute ou à l’heure pour le second.

Forme des métriques : chiffres titre agrégés avec comparaisons pour le premier ; vues granulaires par enregistrement ou par file pour le second.

Rafraîchissement : quotidien ou hebdomadaire suffit pour le premier ; quasi temps réel exigé pour le second.

Profondeur de drill-down : un clic vers une ventilation pour le premier ; plusieurs niveaux jusqu’à l’enregistrement actionnable pour le second.

Outillage : un outil de BI avec rafraîchissement programmé et liens partageables pour le premier ; un outil opérationnel intégré aux systèmes de workflow pour le second, souvent custom ou embarqué.

Propriété : le responsable de fonction dont le dashboard soutient la décision pour le premier ; le responsable opérationnel dont l’équipe l’utilise au quotidien pour le second.

Mode d’échec : trop détaillé, ne synthétise plus pour le premier ; trop agrégé, plus actionnable pour le second.

Ce ne sont pas des préférences. Ce sont des contraintes de conception différentes qui découlent de métiers d’utilisateur différents. Un seul artefact qui fait des compromis sur chaque ligne ci-dessus est un artefact qui fait des compromis sur chaque métier.

Deux schémas d’échec reviennent, et les reconnaître est ce qui casse le cycle de l’équipe qui essaie de construire « un dashboard pour tout le monde ».

Le premier, c’est le dashboard opérationnel qui se fait passer pour un dashboard de direction. La vue du directeur financier est un console de trente graphiques avec tous les segments, tous les drill-downs, tous les compteurs en direct. Le dirigeant l’ouvre une fois, décide que c’est pour quelqu’un d’autre, et demande « le seul chiffre » par e-mail. La correction, c’est d’extraire les métriques titre dans un dashboard de direction séparé, beaucoup plus petit, et de garder la vue opérationnelle pour les personnes qui y travaillent réellement.

Le second, c’est le dashboard de direction qui se fait passer pour opérationnel. La vue « live » de l’équipe support est le même résumé mensuel que lit l’équipe de direction, avec les mêmes agrégations et la même donnée d’hier. L’équipe l’ouvre, n’y voit rien d’actionnable, et revient à la file de tickets dans son outil de helpdesk. La correction, c’est de construire une vue opérationnelle séparée, intégrée aux outils opérationnels, avec la cadence de rafraîchissement que le travail exige réellement.

Le coût de deux dashboards est bien plus petit que le coût d’un dashboard auquel personne ne fait confiance pour bien faire l’un ou l’autre métier.

Les dashboards de direction et les dashboards opérationnels ne sont pas deux réglages du même artefact. Ce sont deux artefacts qui partagent un nom, conçus pour des publics différents, des décisions différentes, des cadences différentes et des outils différents. Les organisations qui obtiennent une valeur mesurable de leurs dashboards sont celles qui traitent les deux comme des problèmes de conception séparés, avec des propriétaires séparés et des critères séparés de « est-ce que ça fonctionne », et qui résistent à la tentation récurrente de construire une seule vue qui compromet sur les deux métiers.

Le contexte plus large, dont la stratégie data, la discipline de conception et les décisions d’ingénierie qui sous-tendent les deux types de dashboard, est rassemblé dans le cluster systèmes de données et performance. Et lorsque la question passe de « il nous faut un meilleur dashboard » à « il nous faut concevoir deux dashboards différents pour deux publics différents, avec deux cadences différentes et deux propriétaires différents », c’est exactement ce sur quoi mon accompagnement analyse de données et aide à la décision est centré.