Recommandations pour les tableaux de bord : livre blanc

Ce livre blanc fait partie de notre collection « Depuis les tranchées ». Il décrit certains des défis auxquels vous serez certainement confronté si vous décidez d’utiliser des tableaux de bord dans votre environnement EPM. Il décrit en quoi la présentation agréable d’un tableau de bord peut parfois leurrer les utilisateurs quant à la nécessité d’examiner la qualité des données, notamment les données « héritées » et mises à jour. Il indique de quelle façon les données pour les tableaux de bord doivent faire l’objet d’un processus d’approbation pour garantir leur qualité et leur exhaustivité. Il inclut quelques techniques pour empêcher les personnes de biaiser les données sous leur contrôle et de déformer les informations affichées dans le tableau de bord. Enfin, il présente certaines règles de base dont vous devez tenir compte lors de la création de tableaux de bord dans le cadre de la gestion de projets d’entreprise.

Pour télécharger une version Word de ce livre blanc, voir Recommandations pour les tableaux de bord.

Pour consulter d’autres livres blancs, voir les livres blancs « Depuis les tranchées ».

Recommandations pour les tableaux de bord

Nous sommes forcés de constater que les tableaux de bord ont le vent en poupe. Sous forme de graphiques à barres, d’histogrammes, de graphiques en secteurs ou d’affichages incluant des feux de signalisation, les dirigeants semblent apprécier particulièrement l’instantanéité des réponses offertes par les tableaux de bord.

Site du Centre d’aide à la décision dans SharePoint Server 2010

L’engouement suscité par les tableaux de bord ne risque pas de faiblir alors que la pression de notre culture d’entreprise pousse à fournir des résultats toujours plus vite.

Le secteur des logiciels de gestion de projets est en quelque sorte un modèle pour ce type d’affichage car les données liées à la gestion de projets se prêtent parfaitement à la présentation sous forme de tableaux de bord. Lorsque nous cherchons à identifier le type de données nécessaires pour les tableaux de bord, nous tenons compte des aspects suivants :

  • Les données sont-elles regroupées de manière à pouvoir être présentées et comprises ensemble ?

  • Sont-elles opportunes ?

  • Ont-elles été approuvées et sélectionnées ?

  • Présentent-elles des marqueurs temporels (date et heure) permettant de les différencier ?

Il s’agit exactement du type de données que l’on peut retrouver dans un système Enterprise Project Management (EPM) tel que Microsoft Project Server.

Il n’est donc pas étonnant que la plupart des systèmes EPM, y compris Project Server, incluent des fonctionnalités de conception de tableaux de bord. Dans le cas de Microsoft, ces fonctionnalités sont incluses dans SharePoint Server dans le Centre d’aide à la décision. Ce type de système peut interroger les données SQL et générer des affichages graphiques variés. Par ailleurs, les dirigeants apprécient souvent de pouvoir tester de nouvelles solutions. La pression exercée par les membres de la direction en relation avec la fourniture immédiate de commentaires sur les projets pousse les bureaux de gestion de projets à transmettre des visualisations avant même que les données sous-jacentes ne soient prêtes.

Un jour, alors que j’étais dans les bureaux d’un service informatique pour aider à la création d’un environnement EPM, un responsable m’a demandé : « Pouvez-vous nous préparer un tableau de bord EPM ? »

Ce à quoi j’ai répondu : « Bien sûr. »

Je ne m’attendais pas à ce qu’il me demande : « Pour vendredi, ce serait possible ? »

J’ai répondu : « Oui, mais pas pour ce vendredi. Pour un autre vendredi, pas de problème. »

Ma réponse lui avait visiblement déplu.

Si ce responsable ne manquait évidemment pas d’intelligence, cet exemple illustre la pression à laquelle sont soumises les personnes en relation avec la mise en œuvre d’un processus de prise de décisions rapide.

Les tableaux de bord sont tellement agréables à regarder que nous oublions souvent qu’ils sont sensés représenter les données à l’origine de l’affichage. Par conséquent, avant de nous précipiter sur la conception d’un tableau de bord et sur le choix des couleurs pour les icônes, attardons-nous d’abord sur les défis généralement rencontrés dans le cadre de la conception des tableaux de bord.

Le « syndrome du Magicien d’Oz »

À la fin de l’histoire du Magicien d’Oz, on découvre qu’un humain contrôlait toute cette prétendue mais néanmoins très convaincante « magie ».

Carte de performance Reporting Services indiquant l’état du projet

Des présentations sophistiques contrôlées par des personnes se retrouvent souvent dans les tableaux de bord. Une grande attention est portée à l’esthétique, à l’apparence des graphiques, icônes et palettes de couleurs, voire même aux animations et effets sonores. Le problème vient du fait que personne n’a pensé à relier les données et le tableau de bord. Par conséquent, une personne assise à un bureau doit décider manuellement de la couleur à associer aux indicateurs.

Lorsque vous consultez un tableau de bord pour la première fois, il est toujours judicieux de demander à consulter les données brutes qui se cachent derrière. La question primordiale est : « Qu’est-ce que cela veut dire ? Pouvez-vous me dire ce qu’il y a derrière cet indicateur ? ». Prenez un échantillon de quelques indicateurs et remontez jusqu’aux données auxquelles ils sont liés.

Ce principe s’applique également si vous concevez un tableau de bord. Chaque indicateur doit disposer d’un lien le reliant à une source. Si ce lien est documenté, c’est d’autant mieux. Si Paul gère un tableau de bord en remplissant une feuille de calcul dans laquelle il note ses impressions sur le projet, autant qu’il vous le dise directement. Ce sera plus rapide.

Tout mesurer

« Si ça se mesure, mettons-le dans le tableau de bord » pourrait être la devise de certains créateurs de tableaux de bord.

Carte de performance affichant l’état de plusieurs projets

Il est facile d’être pris au piège de la technologie de création des tableaux de bord et de créer systématiquement un indicateur pour des données mesurables ou compréhensibles. Les listes de coûts peu avenantes se transforment alors en thermomètres se remplissant de rouge, en tachymètres aux aiguilles gigotantes ou en flèches colorées. Cela a l’air amusant, n’est-ce pas ? Essayez de passer une trentaine de minutes sur Excel 2010 (ou 2013) en essayant la nouvelle fonctionnalité de mise en forme conditionnelle.

Le problème vient du fait que les personnes concevant ces tableaux de bord deviennent trop occupées à créer des indicateurs plutôt que de se demander : « En ai-je vraiment besoin ? ». La question est donc : « Devrais-je le faire ? » plutôt que : « Comment le faire ? ».

Il arrive un moment où un tableau de bord se met à ressembler à celui d’une navette spatiale : il vous faudra alors soit des années de pratique pour réussir à le maîtriser, soit envisager une simplification des choses.

Voici une règle de base pour limiter la quantité d’informations affichées : Chaque indicateur doit absolument avoir une action potentielle. Par exemple, si vous avez un indicateur de type « feux de signalisation » et que celui-ci est rouge, quelqu’un est sensé faire quelque chose quand cela se produit. Cela pourrait être : « Lorsque cet indicateur passe au rouge, un responsable de projet doit faire parvenir un rapport détaillé au bureau de gestion de projets. » Dans tous les cas, il faut qu’il y ait une action correspondante.

Prévisions inachevées

Mangeriez-vous un gâteau dans lequel il manque la moitié des ingrédients (surtout si vous ne savez pas lesquels manquent) ? De même, sur un tableau de bord, comment savoir s’il manque des données ?

Indicateurs d’état pour plusieurs mesures de projet (coût, état, qualité, ressources et planning)

Prenons l’exemple de la création de rapports sur la capacité des ressources. Le feu de signalisation des ressources est passé au rouge pour le service informatique. Les responsables souhaitent examiner le problème et grâce aux informations dont ils disposent, ils mettent le doigt dessus. Le passage de l’indicateur au rouge indique que le service informatique est en sureffectif.

Histogramme comparant les projets aux capacités de l’organisation

Ce premier histogramme montre le problème. La ligne rouge représente la capacité de l’organisation. Les histogrammes empilés donnent une idée des besoins propres aux projets en les regroupant. Si ce tableau de bord est présenté à l’équipe de gestion, la décision d’accepter du travail supplémentaire ou de réduire les effectifs sera plus évidente.

Imaginons maintenant que juste avant la mise en application de la réductions des effectifs, quelqu’un décide de vérifier que tous les projets sont bien représentés dans le tableau de bord.

Histogramme ajusté montrant l’état du projet avec la diminution des effectifs prise en compte

Ce n’est pas le cas.

En effet, certains projets apparaissaient dans la légende mais aucun résultat ne leur était associé dans l’histogramme. Où étaient ces résultats ? Peut-être que ces projets n’étaient pas encore publiés. Peut-être que l’objectif général du projet restait encore à définir. Peut-être que les besoins en ressource n’ont pas été définis au niveau approprié. Une fois les données analysées de nouveau, le deuxième histogramme montre qu’il y a en réalité plus de travail que d’employés et que, par conséquent, il faudrait envisager une augmentation du personnel, une augmentation de la capacité contractuelle ou l’allongement des délais dans les projets futurs. La décision est donc radicalement opposée à celle prise suite à l’examen du même affichage avec une partie des données.

Dans le cas présent, le problème ne vient pas de la conception du tableau de bord, mais plutôt de la qualité des données. Plus spécifiquement, l’exhaustivité des données est à l’origine du problème. Dans cet exemple relativement simple, le problème est facilement identifiable. Imaginez maintenant une situation similaire avec des centaines, voire des milliers, de projets et de sous-projets dans un même ensemble de données.

Prendre des décisions sans avoir une vue d’ensemble des données peut donc mener à des analyses erronées. Prendre des décisions sans même savoir que l’on ne possède pas l’ensemble des données peut être, dans le meilleur des cas, déstabilisant.

Ceci peut être évité en révisant les données dans le cadre d’un processus de révision des données ou, éventuellement, en combinant un processus de validation et un indicateur lié à une base de données qui nous informe que nous examinons une image partielle de notre indicateur.

Dates d’utilisation optimale

Peut-être que, comme moi, il vous arrive d’ouvrir votre réfrigérateur pour prendre du fromage. Mais pensez-vous alors à vérifier la date de péremption ? Tant que nous en sommes à parler des données sources qui ont permis d’obtenir cette belle image sur votre tableau de bord, avez-vous une idée de « l’âge » des données ayant permis de générer cet indicateur ?

Il arrive fréquemment d’effectuer un audit d’un indicateur de tableau de bord et de trouver que les données à l’origine de l’indicateur n’ont pas été mises à jour depuis longtemps. La plupart du temps, un responsable parvient à détecter ce type de problème lors des réunions de révision. Les personnes comme lui amènent souvent leurs notes et les polycopiés distribués lors des dernières réunions, et leur regard avisé leur permet d’analyser et de comparer les nouvelles données par rapport aux anciennes.

Des indicateurs identiques peuvent signifier que les choses n’ont pas évolué (ce qui est assez peu probable) ou que les données n’ont pas été mises à jour (cause la plus fréquente). Pour ceux qui travaillent dans la finance, et dépendent des résultats de leur tableur ou d’un ensemble important de tableurs constitué de comptes auxiliaires, il s’agit là d’une erreur commune. Il peut être plus difficile pour les responsables de projet et les personnes chargées d’examiner les données de projet de repérer ces erreurs si ils ne font pas preuve de rigueur.

Graphique à barres empilées affichant les informations de coût sur une année pour différents services

Le pire des scénarios est celui dans lequel certaines données sont mises à jour et donc actualisées, tandis que d’autres ne le sont pas. Le plan prévisionnel a pu être mis à jour sur la moitié des projets, et les valeurs réelles pour la dernière période ont été publiées pour ces projets, mais les chiffres réels ou le plan a été mis à jour pour l’autre moitié des projets. Si le tableau de bord ou les données qui le composent vont être utilisés dans le cadre du processus décisionnel, le niveau d’actualisation des données doit apparaître quelque part.

Ce genre de problèmes peut être résolu par des vérifications simples et des équilibrages des données avant que celles-ci ne soient présentées dans le tableau de bord. Par exemple, un test simple permet de s’assurer que :

  1. Toutes les feuilles de temps collectées pour la période affichée et

  2. les heures totales des feuilles de temps collectées sont globalement équivalentes au total des heures affiché.

Qualité des données

Plus l’apparence est agréable à regarder, moins l’on risque de se demander « d’où viennent ces données et sont-elles fiables ? ». La clarté des informations est un facteur important lorsqu’il s’agit de présenter des informations dans un affichage graphique professionnel. Les personnes qui créent des données à partir d’une base de données peuvent parfois être maintenues à distance de l’origine des données. Un designer graphique récupère des champs vraisemblablement utiles et des méthodes de calcul des indicateurs à partir de ceux-ci. Il peut toutefois facilement oublier de se demander si ces champs sont renseignés dans le cadre d’un processus validé, impliquant une supervision quelconque, ou par calcul, ou si la qualité des données n’est pas assurée par les personnes les saisissant.

Par exemple, nous travaillons sur un projet de développement de logiciels présentant plusieurs problèmes non résolus. S’y ajoute une liste SharePoint de problèmes définie par le département de vérification de la qualité à mesure que la date de publication d’un logiciel approche. Ce type de liste peut indiquer le degré de préparation du logiciel avant sa sortie. Toutefois, si plusieurs groupes utilisent la même liste pour en tirer de nouvelles idées de fonctionnalités et d’améliorations, le seul nombre des problèmes constitue un indicateur inapproprié étant donné que cette liste rassemble diverses données aux visées différentes.

Les données affichées dans un tableau de bord par le biais d’un indicateur doivent donc être vérifiées avant d’être affichées.

Avoir une vue d’ensemble

Retournons au rapport de tableau de bord incluant des feux de signalisation et examinons la ligne correspondant au service informatique.

Mesures du projet (coût, état, qualité, ressources et planning) pour le service informatique

Imaginons que les indicateurs de planification et de coûts de cette ligne sont rouges pour un projet sur un an. En effet, nous ne somme qu’en juin et ces deux indicateurs sont dépassés de plus de 20 %.

Le directeur financier montre des signes d’inquiétude suite à la consultation de ces résultats. Tout s’explique dans la période allant de janvier à juin :

(€,000)

Janvier

Février

Mars

Avril

Mai

Juin

Budget

80

100

120

120

120

120

Réel

100

120

140

140

140

140

Écart

20

20

20

20

20

20

Écart cumulatif

20

40

60

80

100

120

Pour l’instant, le projet dépasse le budget prévu de 120 000 € alors qu’il n’en est arrivé qu’à la moitié. Selon le directeur financier, à ce rythme, le projet coûtera 18 % plus cher que les 1,3 millions d’euros prévus à l’origine. Il faudrait donc envisager d’abandonner le projet.

Cependant, les choses sont bien différentes lorsqu’on les analyse plus attentivement. Les coûts prévus jusqu’à la fin du projet ressemblent à ceci :

(,000s)

Janvier

Février

Mars

Avril

Mai

Juin

Juil

Août

Septembre

Octobre

Novembre

Décembre

Total

Budget

80

100

120

120

120

120

120

120

120

120

100

80

1 320

Réel

100

120

140

140

140

140

120

100

80

40

0

0

1 120

Écart

20

20

20

20

20

20

0

(20)

(40)

(80)

(100)

(80)

(200)

Écart cumulatif

20

40

60

80

100

120

120

100

60

(20)

(120)

(200)

Nous avons donc désormais un aperçu global de la situation. Le projet se déroule en réalité plus vite que prévu : il devrait se terminer à la mi-octobre plutôt qu’en décembre et coûter 200 000 € de moins que prévu initialement.

Voici le genre de défis auxquels s’attendre lorsqu’on utilise des tableaux de bord. Celui-ci était tout à fait correct, mais la raison pour laquelle l’indicateur était rouge était bonne et non mauvaise comme on aurait pu l’imaginer.

Les indicateurs de tableau de bord doivent servir à alerter les dirigeants sur les actions à prendre et sur les points nécessitant une attention particulière. Il doivent également fournir des informations détaillées pour permettre d’avoir une vue globale sur le projet.

Le paradis des « faussaires »

Vous disposez maintenant de plusieurs outils pour que vos tableaux de bord n’induisent pas en erreur les responsables, ce qui est déjà une bonne chose. Toutefois, soyez conscient que dès que les indicateurs des tableaux de bord sont disponibles, les personnes s’en servent aussitôt à leur avantage. Il est compréhensible que des personnes faussent le processus en déformant les données sous leur contrôle, de façon à les faire apparaître meilleures.

Il n’existe pas de moyen d’empêcher les personnes de fausser le processus, mais il est toutefois possible de limiter leurs agissements.

Modifier le processus

Vous pouvez rendre le détournement plus compliqué en modifiant régulièrement le processus. Le mieux est d’essayer de garder une longueur d’avance sur ceux qui pensent le connaître sur le bout des doigts. Toute personne s’y connaissant en optimisation des moteurs de recherche sait également que cela demande beaucoup de travail de modifier constamment le processus et d’entraîner les autres employés en conséquence.

Le bâton sans la carotte

Une autre solution consiste à punir les personnes surprises à fausser les données, bien que ce soit difficile. Ceux qui déforment leurs données ne devraient pas rester impunis. Toutefois, il peut être immoral de blâmer ceux qui ne font que trouver des failles dans le processus.

Vérifications et équilibrages

Il s’agit là des outils les plus efficaces contre les faussaires. Si vos données viennent de sources différentes et que celles-ci doivent s’équilibrer entre elles, il peut être très difficile pour un faussaire de manipuler un seul ensemble de données sous son contrôle et de faire pencher le processus du tableau de bord en sa faveur. Bien sûr, il n’est pas toujours facile de trouver de tels équilibrages et vérifications dans les données. Comme toujours, prudence est mère de sûreté.

Règles de base

Résumons ce que nous avons vu plus haut. Créer des tableaux de bord puissants et esthétiques n’est pas difficile d’un point de vue technique. Il convient toutefois d’appliquer certaines règles de base dans le cadre de votre conception de tableau de bord et de votre processus de gestion de projets pour vous assurer que les décisions qui en découleront seront pertinentes et efficaces.

Voici un résumé des concepts de base que nous avons abordés :

Les indicateurs doivent être reliés à des données sources

Assurez-vous que les indicateurs ne contiennent pas seulement les opinions et les ressentis d’une personne. Ils doivent représenter des données détaillées propres à votre environnement.

Chaque indicateur doit être relié à une action

Chaque indicateur doit impérativement être lié à une action, quelle qu’elle soit. Cela vous permettra d’en conserver un nombre raisonnable.

Les données doivent être complètes ou une indication doit préciser qu’elles ne le sont pas

Assurez-vous que l’affichage précise bien que les données sont complètes ou incomplètes. Cela évite de prendre des décisions avec une vue partielle du projet.

L’affichage doit indiquer le degré d’actualisation des données

Si certaines données peuvent être mises à jour et d’autres non, la date d’actualisation des données doit apparaître sur le tableau de bord de manière à éviter que des décisions inappropriées soient prises sur la base de données obsolètes ou d’un mélange de données obsolètes et nouvelles.

Vérifier régulièrement la qualité des données

Les données liées aux indicateurs d’un tableau de bord doivent être régulièrement révisées et des mises à jour fréquentes sont conseillées pour éviter que certaines personnes ne faussent les processus décisionnels. Certaines organisations implémenteront un processus d’audits réguliers qui examine les indicateurs importants et remonte aux données sources à partir des résultats, pour vérifier les formules et la qualité des données et s’assurer qu’elles n’ont pas changé. Vous ne pouvez évidemment pas faire ceci tout le temps, mais il peut être bon de déterminer régulièrement ce qui fait changer de couleur les feux de signalisation.

En définitive, n’oubliez quand même pas de vous amuser lorsque vous créez vos tableaux de bord !

Références

Pour en apprendre plus sur la création de tableaux de bord avec Microsoft Project Server, je vous conseille de lire quelques articles de qualité sur TechNet :

À propos de l’auteur

Chris Vandersluis est le président et le fondateur de HMS Software. Basée à Montréal (Canada), l’entreprise est un partenaire Microsoft Certified Partner. Diplômé en sciences économiques de l’université McGill, Chris a plus de 30 ans d’expérience dans l’automatisation des systèmes de gestion de projets. Il est membre du Project Management Institute (PMI) depuis de nombreuses années et a participé à la création des chapitres du Microsoft Project Users Group (MPUG) à Montréal, Toronto et Québec. Il a publié des articles dans Fortune, Heavy Construction News, Computing Canada et PMNetwork. Il tient également une chronique régulière pour Project Times. Il enseigne la gestion de projets avancée à l’université McGill et intervient souvent lors d’événements organisés par des associations de gestion de projets en Amérique du Nord et dans le monde entier. HMS Software est l’éditeur du système d’horloge pour les projets TimeControl et est un partenaire Microsoft Project Solution Partner depuis 1995.

Vous pouvez contacter Chris Vandersluis à cette adresse : chris.vandersluis@hms.ca.

Pour consulter d’autres articles en lien avec la gestion des projets d’entreprise rédigés par Chris Vandersluis, rendez-vous sur le site EPM Guidance de HMS Software (http://www.epmguidance.com/?page_id=39).

Développez vos compétences
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

Nous vous remercions pour vos commentaires.

Merci pour vos commentaires. Il serait vraisemblablement utile pour vous de contacter l’un de nos agents du support Office.

×