Le contexte
Le client était une équipe Customer Success d'environ 50 personnes, chacune facturant du temps sur des projets clients. À cette taille, la rentabilité et le taux d'utilisation cessent d'être des indicateurs qu'on peut suivre de mémoire ou en demandant autour de soi. Les managers avaient besoin d'une vision fiable et à jour des deux, sans dépendre de quelqu'un qui compile les chiffres à la main chaque semaine.
Le problème
L'équipe n'avait aucune visibilité sur les deux chiffres qui comptaient le plus pour l'activité, la rentabilité par projet et le taux d'utilisation par personne. Le temps était suivi dans Harvest, mais rien ne reliait ces données au portefeuille de projets et aux tableaux de bord de gestion, qui vivaient dans Smartsheet. Les managers devaient consulter deux systèmes déconnectés et faire les calculs eux-mêmes, généralement trop tard pour agir.
Avant
- Aucune visibilité sur la rentabilité des projets
- Aucune visibilité sur le taux d'utilisation des consultants
- Les données de suivi du temps (Harvest) restaient séparées du portefeuille de projets dans Smartsheet
- Le reporting, quand il existait, était manuel, occasionnel et déjà obsolète au moment d'être consulté
Ce que nous avons construit
Phase 1, un pont manuel
La première version a été construite avec les outils disponibles à l'époque, avant que Bridge, DataMesh et Pivot App ne fassent partie du tableau. Chaque semaine, les données étaient exportées manuellement depuis Harvest puis nettoyées dans Excel avec Power Query. Ces données transformées étaient ensuite poussées dans Smartsheet via Data Shuttle. Ce n'était pas automatisé de bout en bout, mais cela a mis les chiffres de rentabilité et de taux d'utilisation devant les managers pour la première fois.
Phase 2, l'automatisation complète
Une fois Bridge, DataMesh et Pivot App entrés dans le périmètre, nous avons reconstruit tout le flux pour supprimer entièrement les étapes manuelles. Le rapport de rentabilité a suivi le même chemin, d'abord construit et calculé dans Excel, puis reconstruit sur la même intégration API Harvest et API Smartsheet dans Bridge.
La rentabilité n'était pas seulement affichée dans un tableau de bord isolé. Une fois dans Smartsheet, elle était incluse dans le portefeuille de projets et dans chaque plan de projet individuel, pour que les chefs de projet voient exactement où en était leur propre projet sans avoir à consulter un rapport séparé. J'ai aussi ajouté un indicateur de rentabilité prédictive, calculé à partir de la rentabilité actuelle rapportée au pourcentage d'avancement du projet, pour que les chefs de projet voient où le projet était en train de se diriger, pas seulement où il en était aujourd'hui.
Comment fonctionne l'automatisation
A interval régulier, un workflow Bridge appelle l'API Harvest pour récupérer les dernières entrées de temps. Un module JavaScript dans Bridge façonne cette réponse brute dans la structure dont Smartsheet a besoin, en faisant correspondre les personnes et les projets avec les enregistrements existants plutôt que de créer des doublons, puis appelle l'API Smartsheet pour écrire les données. À partir de là, DataMesh synchronise les entrées transformées dans le portefeuille de projets et dans chaque plan de projet, et Pivot App agrège les entrées brutes dans les vues par projet et par personne que les managers consultent. Aucun export manuel, aucune étape Excel, et personne n'a besoin de se souvenir de lancer quoi que ce soit.
Obstacles
Faire en sorte que les gens rentrent réellement leur temps
Ce process ne reflète la réalité que si les gens saisissent leur temps régulièrement. Automatiser le flux de données ne règle pas ce problème à lui seul, et un chiffre de rentabilité ou de taux d'utilisation construit sur une semaine d'entrées de temps manquantes est pire que pas de chiffre du tout, car il donne l'impression d'être fiable alors qu'il ne l'est pas. Cela signifie que le travail ne s'arrêtait pas une fois le process en place. J'ai aussi dû construire un rapport qui signale précisément où le suivi du temps prend du retard, par personne et par projet, pour que les managers puissent relancer les entrées manquantes avant que les chiffres de rentabilité et de taux d'utilisation ne soient pris pour argent comptant. De tout ce projet, c'est cet élément qui détermine si le reste peut être considéré comme fiable.
Les limites de lignes
À l'époque où ceci a été construit, les feuilles Smartsheet étaient plafonnées à 5000 lignes. Les entrées de temps Harvest s'accumulent vite sur 50 personnes, le workflow Bridge devait donc limiter la quantité d'historique importée à chaque exécution plutôt que de tout importer. Ce plafond a depuis été relevé, mais la leçon de fond reste valable, plus il y a de lignes dans une feuille, plus les performances ralentissent et plus il y a de risques que quelque chose tourne mal dans Smartsheet ou dans Bridge. Garder les volumes de lignes bas est donc resté un objectif de conception même après le relèvement du plafond.
Agréger avant que les données n'atteignent Smartsheet
L'API Harvest ne contient pas toujours nativement les données dans la forme nécessaire au reporting de rentabilité et du taux d'utilisation. Plutôt que d'importer tout brut et d'agréger ensuite dans Smartsheet, le module JavaScript dans Bridge effectue cette agrégation avant l'écriture des données. Cela a permis de garder les volumes de lignes aussi bas que possible sur les jeux de données volumineux, et d'éviter de faire porter cette charge de traitement à Smartsheet lui-même.
Repérer les échecs de Bridge
Il arrive que des workflows Bridge échouent en cours d'exécution, et une exécution échouée peut laisser les données obsolètes sans que personne ne s'en aperçoive tout de suite. Pour détecter cela, DataMesh a été configuré pour ajouter chaque jour de nouvelles lignes dans la feuille agrégée plutôt que de remplacer tout le jeu de données, avec une automatisation séparée qui archive les lignes qui ne sont plus présentes dans l'import, sauf si l'écart entre les deux est inhabituellement important, ce qui suggérerait plutôt une exécution échouée que des données réellement supprimées.
En plus de cela, un rapport sur le tableau de bord quotidien compare le nombre de lignes de la feuille d'import à celui de la feuille agrégée, de sorte qu'un échec de Bridge se traduit par un écart visible plutôt que de passer inaperçu jusqu'à ce que quelqu'un remette les chiffres en question.
Après
- Suivi quotidien et automatisé de la rentabilité par projet, visible directement dans le portefeuille de projets et dans chaque plan de projet pour les chefs de projet
- Rentabilité prédictive par projet, projetant où il va atterrir en fonction de la rentabilité actuelle rapportée au pourcentage d'avancement
- Tableaux de bord de taux d'utilisation par personne et par équipe pour les managers
- Données centralisées récupérées directement depuis l'outil de suivi du temps via API, plus aucune étape d'export manuel dans le processus
- Indicateurs d'alerte précoce intégrés aux tableaux de bord, pour que les managers voient qu'un projet dérive avant que cela ne devienne un problème
- Un rapport de conformité du suivi du temps, pour que les écarts dans les données soient repérés et relancés au lieu de fausser les chiffres sans que personne ne le remarque
Les managers sont passés d'une absence de réponse fiable à la question "où en est ce projet financièrement" à la consultation d'un tableau de bord qui se met à jour tout seul. Les chefs de projet ont obtenu la même visibilité directement dans leurs propres plans de projet, sans avoir à aller la chercher. Et parce que le process signale les endroits où le suivi du temps prend du retard, l'équipe a pu faire confiance aux chiffres plutôt que de les traiter comme une estimation approximative.
Pourquoi c'est important
L'intérêt ici n'était pas seulement d'automatiser un rapport. C'était de boucler la boucle entre deux systèmes qui ne s'étaient jamais parlé, et de le faire d'une manière automatisée, puisque le même schéma API Harvest et Bridge alimente désormais à la fois le reporting de rentabilité et celui du taux d'utilisation, une seule intégration faisant le travail qui prenait autrefois des exports manuel et des fichiers Excel.
La raison pour laquelle ce projet nécessitait une construction sur mesure plutôt qu'un connecteur prêt à l'emploi est que les intégrations natives et tierces entre Harvest et Smartsheet déplacent surtout des données dans un seul sens, comme créer un projet ou synchroniser une seule ligne de feuille de temps. Aucune d'entre elles ne calcule la rentabilité, ne l'agrège dans un portefeuille de projets, ni ne construit un tableau de bord de taux d'utilisation à partir de cela. Si vous avez déjà buté sur ce même mur, c'est exactement ce type de problématique que ce genre de construction Bridge et DataMesh sous Smartsheet est conçu pour combler.
Par contre soyons clair sur le coût, ce setup technique, Bridge, DataMesh, Data Shuttle et Pivot App, n'a de sens que si vous disposez déjà de ces applications premium ou que vous êtes prêt à y investir. Pour les équipes qui le sont, le résultat est un tableau de bord de rentabilité et de taux d'utilisation qui se met à jour tout seul chaque jour, au lieu d'un tableur que quelqu'un doit reconstruire chaque semaine.
Si votre équipe suit le temps dans Harvest, ou dans un autre outil, mais ne peut toujours pas répondre à la question "quels projets sont rentables en ce moment" sans sortir un rapport manuel, contactez-moi pour discuter de ce à quoi pourrait ressembler un tableau de bord de rentabilité ou de taux d'utilisation Smartsheet pour votre équipe.
