Si vous avez déjà construit un widget graphique en le pointant directement sur une feuille, vous avez probablement rencontré l'un de ces problèmes : un graphique auquel il manque des lignes, un graphique qui inclut des lignes qu'il ne devrait pas avoir, ou un collègue qui vous demande pourquoi il peut voir des données qu'il ne devrait pas voir. Dans la plupart des cas, la solution n'est pas un autre type de graphique. C'est une source différente. Cet article examine dans quels cas il vaut mieux construire vos widgets graphiques de tableau de bord à partir de rapports plutôt qu'à partir de feuilles.
Construisez un graphique à partir d'une feuille lorsque vous n'avez besoin de données que de cette seule feuille, et que toutes les personnes pouvant voir le tableau de bord ont déjà les droits d’accès sur cette feuille.
Construisez un graphique à partir d'un rapport lorsque vous avez besoin de récupérer des données de plusieurs feuilles, lorsque vous devez filtrer ou remodeler ce qui apparaît avant que cela n'atteigne le graphique, lorsque vous devez montrer ces données à des personnes qui ne devraient pas avoir un accès direct aux feuilles sources, ou lorsque la feuille source reçoit régulièrement de nouvelles lignes au fil du temps.
C'est le critère qui piège le plus souvent les gens, car le problème n'apparaît pas avant plusieurs semaines après la création du graphique. Un widget graphique construit à partir d'une feuille ne lit pas la feuille entière. Il lit une plage fixe que vous avez sélectionnée au moment de sa création. Quand quelqu'un ajoute une nouvelle ligne à cette feuille plus tard, que ce soit via une soumission de formulaire, une intégration, ou simplement en tapant une nouvelle ligne, le graphique ne la récupère pas. Il continue d'afficher la sélection d'origine jusqu'à ce que quelqu'un ouvre le widget et étende manuellement la plage.
C'est gérable si la feuille ne grandit jamais. Cela devient une vraie charge de maintenance sur toute feuille où des lignes sont ajoutées régulièrement : registres d'entrées, feuilles de tickets, saisies de statut hebdomadaires, tout ce qui est alimenté par un formulaire. Un rapport résout ce problème. La sélection de lignes d'un rapport est définie par des critères, pas par une plage fixe, donc toute nouvelle ligne qui correspond au filtre du rapport apparaît dans le graphique dès son prochain rafraîchissement, sans que personne n'ait besoin de retourner toucher le widget et sa source. Si votre feuille source est une cible mouvante, un graphique basé sur une feuille est le mauvais choix, quelle que soit la simplicité apparente du reste.
Un graphique construit à partir d'une feuille ne peut représenter que cette seule feuille. Si vous avez besoin d'un graphique qui agrège le statut de dix feuilles de projet, ou qui affiche chaque ticket ouvert sur tout un portefeuille, une feuille ne peut généralement pas faire cela facilement. Un rapport le peut. Les rapports récupèrent des lignes ou des données de synthèse provenant de plusieurs feuilles, jusqu'à un très grand nombre de feuilles sources, et les présentent comme un seul ensemble de données pour que le graphique puisse les représenter. Dès que votre graphique doit représenter quelque chose de plus d'un seul projet, un rapport cesse d'être optionnel et devient la seule option réaliste.
Un rapport n'est pas le seul moyen d'y arriver. Des formules inter-feuilles ou des liens de cellules peuvent récupérer des données de plusieurs feuilles vers une seule feuille, et un graphique peut ensuite être construit directement à partir de cette feuille consolidée. C'est bon à savoir, mais au-delà d'une poignée de feuilles sources, cela demande généralement une plus longue et plus complexe construction et plus d'entretien qu'un seul rapport faisant le même travail.
Une nuance à connaître si vos feuilles sources continuent de se multiplier, les feuilles de projet créées par Control Center étant le cas le plus évident : un rapport n'inclut automatiquement les nouvelles feuilles que si sa source est définie au niveau de l'espace de travail. Si la source est définie au niveau du dossier, une nouvelle feuille ajoutée à ce dossier plus tard ne rejoint pas automatiquement le rapport. C'est le même piège du "ce qui est nouveau n'apparaît pas tout seul" que la plage fixe du graphique, donc il vaut mieux configurer les rapports sur des espaces de travail plutôt que sur des dossiers partout où le nombre de feuilles est amené à grandir. Et sur des constructions vraiment volumineuses, il faut savoir que les rapports peuvent ralentir ou avoir du mal à s'ouvrir bien avant tout plafond documenté, donc un rapport de portefeuille couvrant plusieurs milliers de feuilles vaut la peine d'être testé tôt plutôt que de supposer qu'il tiendra la charge.
Un rapport vous permet de restreindre l'ensemble de données en amont : seulement les lignes avec une priorité haute, seulement les lignes modifiées au cours des trente derniers jours, seulement les lignes appartenant à une personne en particulier. C'est cet ensemble de données filtré qui alimente le graphique. Cela important pour deux raisons. D'abord, cela garde votre configuration de tableau de bord plus facile à auditer plus tard, car la logique vit à un seul endroit (le rapport) plutôt que dans des rangées de formules complexes dans une feuille. Ensuite, pour de très grandes feuilles, filtrer au niveau du rapport les rend plus efficient, puisque vous ne demandez pas à chaque graphique de parcourir l'ensemble de données a chaque fois.
C'est le point qui piège le plus. Les personnes visualisant un tableau de bord n'ont pas automatiquement besoin d'accès à une feuille simplement parce qu'un graphique du tableau de bord en tire ses données, à condition que ce graphique soit construit à partir d'un rapport plutôt que directement de la feuille.
Autrement dit, les rapports vous permettent de montrer un graphique résumé ou sélectionné à une audience telle que des dirigeants ou des clients, sans leur donner de droits Éditeur ou Lecteur sur les feuilles de travail sous-jacentes. Si vous avez déjà eu besoin de partager un tableau de bord en externe, ou avec une partie prenante qui ne devrait voir que le graphique de synthèse plutôt que chaque ligne de données brutes de projet, un rapport rend cela possible. Un graphique basé sur une feuille ne peut pas offrir cette séparation. Toute personne le visualisant a besoin de son propre droit de partage sur la feuille, un point c'est tout.
Il est très courant de voir une feuille "métriques" ou "helper" dédiée, construite uniquement pour alimenter des graphiques, pleine de formules SUMIFS ou COUNTIFS qui calculent des totaux par statut, par propriétaire, par mois. Parfois, c'est vraiment le bon choix : les graphiques ont besoin d'une véritable logique d'agrégation qui va au-delà de ce que le regroupement d'un rapport peut faire, donc une feuille pilotée par formules est le moyen le plus propre d'y arriver. Mais tout aussi souvent, la vraie raison est que les données sources n'ont jamais été structurées en amont en pensant au graphique, et que la voie du rapport ou du regroupement n'était pas évidente comme alternative. Consultez cet article pour en savoir plus sur la bonne façon de structurer vos données dans Smartsheet, afin de ne pas rencontrer cette limitation et de rester flexible dans vos choix.
Il y a deux choses à savoir avant de se tourner par défaut vers une feuille métriques. D'abord, le widget graphique lit tout ce qui se trouve dans la première ligne et la première colonne de votre sélection comme ses étiquettes, la première ligne devient la légende ou les catégories d'axe et la première colonne devient les étiquettes de ligne, donc un graphique construit directement à partir d'un rapport ou d'une feuille semble souvent faux simplement parce que les étiquettes ne sont pas à l'endroit attendu par le widget (et vous), et non parce que les chiffres sous-jacents sont faux. Corriger la disposition de la source, plutôt que prétraiter les chiffres ailleurs, résout la plupart de ce que les gens cherchent à résoudre avec une feuille métriques.
Ensuite, l'éditeur du widget graphique dispose d'une option "inverser les lignes et les colonnes" qui échange quel axe est lu comme étiquettes et quel axe est lu comme séries de données, sans toucher à la feuille ou au rapport source. Les rapports prennent également en charge le regroupement de lignes et les données de synthèse, qui peuvent alimenter un graphique directement dans de nombreux cas, donc l'écart entre "ce qu'un rapport peut donner à un graphique" et "ce qu'une feuille métriques peut donner à un graphique" est plus restreint qu'il ne l'était auparavant. Cela vaut la peine d'essayer d'abord le regroupement et les options, et de réserver la feuille de métriques aux cas où la logique d'agrégation en a vraiment besoin.
Rien de tout cela ne signifie que les rapports sont toujours la réponse. Si un graphique est censé refléter exactement une seule feuille, sans filtrage ni combinaison nécessaire, et que toutes les personnes visualisant le tableau de bord sont déjà partagées sur cette feuille avec un niveau d'accès approprié, pointer le graphique directement sur la feuille est plus simple et représente un objet de moins à maintenir.
L'exception à connaître : les rapports de synthèse de feuille (des rapports construits à partir des données de synthèse de feuille plutôt que des lignes) sont le seul moyen de combiner des chiffres au niveau synthèse provenant de plusieurs feuilles en un seul graphique. Si vous avez besoin d'un graphique qui agrège plusieurs feuilles de projet en une vue de portefeuille, Il n'y a que les rapports qui en sont capables.
Posez-vous ces questions avant de choisir une source pour chaque graphique :
Une chose à signaler quand on augmente la cadence : les rapports ne peuvent pas être construits à partir d'autres rapports (en tout cas pas sans DataMesh, et sans immédiateté). Si vous vous surprenez à vouloir créer un rapport à partir d'un rapport, c'est généralement le signe que la structure de feuille sous-jacente a besoin d'attention, plutôt que d'avoir besoin d'une couche de reporting supplémentaire. Il est sûrement plus simple de structurer correctement vos données et de construire un nouveau rapport.
Si vous prévoyez de construire des rapports basés sur les mois, vous devriez lire ceci : Les tables de référence indispensables pour structurer Smartsheet. Avec cela, vous serez équipé pour ajouter les mois à toutes vos feuilles afin qu'ils puissent être ajoutés dans vos rapports dans le bon ordre.
Les feuilles conviennent pour des graphiques simples, à source unique, entièrement partagés, sur des données qui restent dans leurs cellules. Dès qu'un graphique a besoin de combiner des feuilles, de filtrer les données avant qu'elles n'atteignent le tableau de bord, de protéger les données sous-jacentes des personnes qui n'ont besoin que de la vue finale, ou de rester à jour à mesure que de nouvelles lignes arrivent, un rapport est l'outil conçu pour cette tâche. Bien faire les choses dès le départ évite beaucoup de reconstructions plus tard, et c'est l'une des lacunes les plus courantes qu'on constate en examinant des tableaux de bord qui ont grandi de manière organique au fil du temps.
Si vous êtes en train de travailler sur un graphique de tableau de bord et que vous souhaitez un second avis sur la structure, contactez-moi via le formulaire de contact ci-dessous et nous l'examinerons ensemble.