J’adore les tableaux de bord : simples à lire, concis, efficaces… Mais j’adore encore plus les tableaux de bord en ligne : versatile, personalisables, évolutifs… Les tableaux de bord sont à mon sens une des briques essentielles de l’Entreprise 2.0, et un très bon moteur d’implication et de collaboration.
Problème : comment concevoir et déployer des tableaux de bord en ligne ? En fait dès que vous creusez un peu, vous vous rendez compte qu’il existe de nombreux écrits et théories sur le sujet, de même que plusieurs blogs : The Dashboard Spy et Dashboards by Example.
Il existe aussi quantité de fournisseurs de solutions : Corda, The Dashboard Company, BrightPoint…
L’idée derrière ces tableaux de bords en ligne est de pouvoir exploiter au mieux les possibilités des interfaces riches pour proposer une lecture à plusieurs niveaux :
Il existe à ce sujet un projet universitaire très intéressant du nom de ASU Dashboards qui propose ce type d’interaction : une exploitation progressive des données par clic successifs qui permettent d’affiner la granularité des données. Exemple ici : Summary Factbook 2007.
La conception d’un tableau de bord est ainsi un exercice très périlleux qui cumule les complexité de plusieurs disciplines : architecture de l’information, design des interaction, visual thinking…
Si le sujet vous intéresse, je vous recommande de vous plonger dans les différents exemples et études de cas des fournisseurs spécialisés.
(via Social Media Today)
Je suis encore un peu perplexe aujourd’hui sur les technologies à adopter pour créer de bons tableaux de bord. Fondamentalement une technologie de type client riche (adobe flex ou ms Sylverlight) permet à mon sens d’avoir une architecture favorisant l’interaction avec l’utilisateur et surtout permettre d’avoir une présentation des données un peu moins statique. Les exemples que j’ai pu voir aujourd’hui en termes de présentation de données sur des composants Flex m’amènent à penser que la voix est dans ce sens, mais après il y a toujours le pb de la capacité d’adoptions de ce type de Framework, et l’opportunité de son déploiement sur le terrain.
Ben tu as oublié le français leader de la Business Intelligence, Business Objects ? Bah c’est vrai nous sommes allemands maintenant :p
Il est clair que le focus N1 en Dashboarding est l’ergonomie et c’est ce qui nous a poussé à essayer AIR tout récemment : http://labs.businessobjects.com/biwidget/
Par contre je pense que tu mélanges deux workflows assez séparés:
– le dashboarding, c’est pour donner une vue d’ensemble facilement (avec quelques infos détaillées en 1/2 clics, pas plus)
– le drill, ou l’exploration (ta lecture à plusieurs niveaux..) ça ce n’est plus du ressort du dashboard.
Les besoins sont différents dans les deux cas : le dashboard te permet de détecter les problèmes rapidement, l’exploration est là pour te les expliquer (recherche de cause, investigation). Mais ce n’est que mon avis..
{Maz}
Business Objects Labs
“La conception d’un tableau de bord est ainsi un exercice très périlleux qui cumule les complexité de plusieurs disciplines : architecture de l’information, design des interaction, visual thinking…”
Pour ma part, je me permet de nuancer un peu tes propos en avançant que les tableaux de bords sont, traditionnellement, mis en place dans les entreprises par les contrôleurs de gestion. Et que, la discipline “complexe” qui prime à 80% dans l’établissement des tdd, c’est la connaissance du métier que l’on souhaite mesurer…
Le penchant pour le nouvelles technologies d’une certaine population de contrôleur, en entreprise, fait que les tableaux adoptent en partie aujourd’hui les techniques des clients riches, mais bon nombres de tableaux fonctionnent encore sous excel…
Merci pour les liens !
Pour avoir bossé sur une (très) grosse appli de ce type au siècle dernier, je pense que ce sont les traitements arrières qui sont les plus couteux, particulièrement sur de gros S.I hétérogènes. Du coup le budget de l’interface frontale en prends souvent un coup.
J’ignore comment ont évolués les produits du marché comme BO, ont-ils la possiblité de générer ce type d’interface utilisateur ?
merci pour cet article je vais justement bosser sur un projet de ce genre au boulot ;)
@ Imothep > Oui, les contrôleurs de gestion pilotent majoritairement ce type de projet lorsqu’il s’agit d’un TdB en version papier, mais quid d’une version dynamique ?
/Fred
Oui, exactement, ce sont les budgets de l’interface en surface qui s’en retrouve réduit… C’est le cas parce que les décisionnaires sur ces projets continuent de voir le graphisme simplement comme un habillage d’une structure déjà réfléchie dont il a été exclu.
Par ailleurs des graphistes, en général, continuent aussi d’avoir cette vision séparée, et s’imaginent qu’après avoir singé Windows ou OSX avec des effets glossy et deux ombrages ont rempli leur tâche de graphisme écran. C’est pas tous les graphistes bien entendu mais du moins ceux que le marché s’emploie à exploiter très peu cher pour faire du webdesign discount à la chaîne (dont on se demande ce que ça veut dire encore aujourd’hui).
Ces deux acteurs continuent également de voir la question du graphisme par l’ornière de l’esthétique alors qu’il s’agit de design dans lequel le graphisme et l’ergonomie sont des composantes complémentaires qui doivent être pensées en parallèle.
À partir de là c’est sûr que c’est une branche très précise du design qui peine à se faire une place, manque de reconnaissance de part et d’autre, qu’on appelle communément parfois design interactif mais est encore un peu floue et est récupéré un peu maladroitement par diverses pratiques perdues entre l’animation et un graphisme d’information.
Par chance le graphisme en France est encore sous le régime du droit d’auteur, ce qui permet de le considérer comme une création. C’est une malchance dans la mesure ou les agences, SSII et autres structures en charge du développement de projets demandant de l’ergonomie ont du mal à intégrer cette charge de travail dans leur fonctionnement et a gérer cet “achat d’art” et (même pour les graphistes) trouver le bon mode de cession de droits d’auteur sur ce nouveau genre de pratique du design.
Du coup, les droits d’auteur sont souvent galvaudés (dans le meilleur des cas), incompris et bradés et c’est toute la pratique qui s’en retrouve dévalué puis dévalorisée. Comme on le dit souvent, l’argent étant le nerf de la guerre, à un moment donné il est difficile de lâcher des idées d’interfaces et d’ergonomie dont on connait les potentiels pour pas grand chose… Surtout quand on sait que ces idées sont bien plus reconnues, valorisées et rentables à l’étranger chez des éditeurs dont on voit qu’ils ont compris depuis longtemps l’importance du design sur leur produits et leur image (Apple, Microsoft, Adobe…)
Les projets de Dashboards présentés ici ne proposent pas de modèle d’interfaces très recherchées, on est sur des habillages, mais pas sur de vrai modèles interfaces. Ici l’influence graphique qui domine est très “Windows xp” ou Office, un coup de glossy partout, du bord arrondi (le syndrôme du web2.0…) qui donne l’impression que “ça glisse” plus, mais c’est pas parce que c’est vu ailleurs, que ça rempli sa fonction sur les fonctions de bases d’un OS ou que ça a l’étiquette “user friendly” que c’est nécessairement plus souple à manipuler. Il manque souvent un concept, une métaphore générale et des niveaux d’interprétations qui en découleraient, permettant une vrai prise en main. Bref, il manque de la réflexion en terme de sémantique, et du temps de travail, d’expérimentation. Bref, il manque du budget car c’est un travail qui demande énormément de sources, de culture et d’expérience personnelle, de veille, d’analyse et d’anticipation.
Oui, d’ailleurs merci pour ce genre d’article car je vais également travailler sur un même genre de projet, plus ciblé dans l’usage, donc avec une problématique de design et d’ergonomie moins complexe à résoudre.
Pour appuyer les propos d’Imothep, le vrai pb dans l’entreprise n’est pas dans les Interfaces utilisateurs avec des petits bonhomme qui dansent et des gauges en 3D mais dans la collection et le nettoyage des données en amont …. et là ce sont des mois et des mois de travail pour fiabiliser toute cette intégration des données (ETL)
BO et Cognos ont maintenant de très belles interfaces graphiques de dashboarding mais très peu de leurs clients les utilisent au final!
“L’Excellerie” sera encore longtemps de mise …. car ce que l’on oublie souvent c’est que les utilisateurs aiment bien “retrafiquer” leurs données avant de les présenter au final à leur boss…
@ Chris > Merci pour ce long commentaire. Effectivement, il ne faut pas se laisser berner par les coins arrondis et autres effets graphiques : il convient de mener une véritable réflexion de fond sur le “visual thinking”.
C’est dans ce cadre que les métaphores sont très puissantes (ex. les cadrans).
/fred
A mon avis, le tableau de bord n’est pas représentatif de l’Entreprise 2.0. Au contraire, il illustre ce que l’Entreprise 2.0 ne doit ou ne veut pas être.
En effet, le tableau de bord est l’archétype de la vision corporate traditionnelle, c’est à dire l’approche “top-down”. Le tableau de bord est un fantasme de consultant. Il matérialise le désir quasi-orwellien du PDG de pouvoir depuis son bureau non seulement observer l’ensemble de l’activité de son entreprise, mais aussi la piloter. Le tableau de bord d’une entreprise est donc souvent rêvé comme celui d’une voiture. Il permet de voir et de conduire.
Les éditeurs d’ERP (Oracle, SAP) ont bien compris ce fantasme, et c’est comme cela qu’ils vendent leur produits. L’ERP est le tableau de bord ultime.
L’Entreprise 2.0 – en tout cas, ce que j’en ai compris – n’est pas vraiment dans cette démarche de “command and control”. Au contraire, l’Entreprise 2.0 en met l’utilisateur final (le salarié) en avant(approche bottom-up) et prone des valeurs d’autonomie, de rupture des relations hiérarchiques traditionnelles, d’introduction du chaos assez peu compatibles avec le concept de tableau de bord.
Il est aussi très important de souligner que la mise en scène des chiffres et des graphes composant un dashboard est très dépendante de l’information qui doit être transcrite et très souvent, cette mise en scène ne peut pas être la même pour le top management que pour les utilisateurs opérationnels.
Cependant, de beaux graphiques et des belles couleurs sont très importants pour déclencher l’enthousiasme des utilisateurs et ainsi favoriser la consultation régulière de ces données de pilotage.
Je vous invite à découvrir sur le portail http://www.labdecisionnel.com la solution QlikView http://www.labdecisionnel.com/Tutoriels-/-Labos/Laboratoire-QlikView/Decouvrir-l-interface-de-QlikView.html qui est pour moi la solution la plus innovante sur le plan navigations dans les données. http://demo.qliktech.com
Oui, les cadrans sont un début de métaphore au tableau de bord, (automobile ou autre) mais je me demande si les (vrais) appareils à jauges et divers cadrans ont été conçu dans un souci de convivialité. du coup est-ce la métaphore à suivre ? Aussi, quand je vois tout ces camemberts et colonnes, qu’ils soient plats, en 3d ou en reliefs je me dit qu’on peut sans problème relire Edward Tufte ( http://www.edwardtufte.com/tufte/ )… et continuer à cherche quelque chose de plus intuitif, convivial et au final plus informatif.
“@ Imothep > Oui, les contrôleurs de gestion pilotent majoritairement ce type de projet lorsqu’il s’agit d’un TdB en version papier, mais quid d’une version dynamique ?”
La même chose, selon moi ;)
Je connais assez bien le domaine du contrôle de gestion, pour y officier en consultant freelance orienté informatique.
Ce qui se passe est relativement simple, et découle toujours directement de l’orientation du décisionnaire (le PDG très souvent dans les PME, ou les directeurs opérationnels dans les plus grosses structures):
– Soit le décisionnaire est un “old-school”. Auquel cas, il s’attache à demander un rapport mensuel papier, rédigé. Ces personnes préfèrent même que le processus de consolidation des données soit manuel (entendre: saisie et traitement des infos à la main dans un classeur excel). Si on lui propose un tdb “glossy”, il va hurler que rien ne vaut un vrai controle à la main.
Et le seul à intervenir sur le projet de tdb sera le controleur de gestion, qui se voit alors confier le tdb comme une tâche quotidienne.
– Soit le décisionnaire est plus tourné vers l’avenir, et il est ouvert aux tdb dynamique et modernes, et cherche à optimiser ses équipes. Mais il confiera quand même le projet de tdb au contrôleur de gestion, pour la simple et bonne raison que personne d’autre dans l’entreprise n’est vraiment qualifié pour faire le travail en amont à la réalisation technique du tdb. Il ajoutera simplement au cahier des charges qu’il faut un tdb moderne. Charge au contrôleur de gestion d’aller voir son collègue DSI pour réfléchir avec lui à la solution qui sera adopté. Quand il n’y a pas de DSI, le contrôleur prend parfois la “main” hiérarchiquement sur quelques informaticiens, voir des fournisseurs. Parfois même, le contrôleur à la double compétence informatique/gestion.
Le fait est que, dans la très grande majorité des cas, et d’après mon expérience personnelle, les projets de tdb, à l’ancienne ou moderne, sont toujours confiés aux contrôleurs de gestion, qu’ils sont toujours dimensionnés selon les “rêves de grandeur” du décisionnaire, et que le contrôleur se débrouille pour fournir le type de tdb demandé.
Allez voir http://www.woopra.com , ça vaut le coup d’oeil.
Encore faut-il commencer par savoir concevoir des tableaux et des graphiques efficaces, ne présentant que des infos utiles en un minimum d’espace. Et tous les jours je vois nombre de personnes sortir des rapport Excel/Word/PPT/BO etc. illisibles.
Indépendamment des technos il faut se creuser les méninges pour bien penser ses tableaux et graphiques et les rendre pertinents et lisibles, si on veut avoir une chance qu’ils soient lus. Toujours avoir le réflexe de simplifier au max pour l’utilisateur final.
Existe-t-il des outils capables de guider le concepteur de rapports vers le bon type de tableau ou de chart? Des bouquins ou sites web sur le sujet? Rien de tel dans BO ni Excel en tout cas.