Presque tous les problèmes opérationnels sur lesquels on nous appelle commencent par un tableur qui fonctionnait. C'était le moyen le plus rapide de suivre quelque chose, ça a marché, et l'activité a grandi autour. Personne n'a décidé qu'il deviendrait la référence. Il l'est devenu tout seul.
La question n'est donc pas de savoir si les tableurs sont mauvais. Ils restent difficiles à battre pour une analyse rapide, pour des calculs, et pour un processus qui change encore de forme. La question est de savoir si ce fichier-là a pris en silence un rôle pour lequel il n'a pas été fait, et ce que cela vous coûte de l'y laisser.
Six signes que le tableur a dépassé son rôle
Aucun de ces signes n'est à lui seul une raison de tout reconstruire. Quand plusieurs apparaissent en même temps, le fichier a cessé d'être un tableur pour devenir une infrastructure.
- Deux personnes le modifient en même temps et le travail de l'une disparaît. Vous avez déjà perdu une ligne et l'avez reconstituée de mémoire.
- Il existe une copie appelée final, ou v3, ou le prénom de quelqu'un, et personne ne sait laquelle fait foi.
- Une formule en colonne K décide de quelque chose d'important, une seule personne l'a écrite, et plus personne n'y touche.
- Les filtres et les colonnes masquées servent de gestion des droits, parce que tout le monde ne devrait pas tout voir et que le fichier ne sait pas l'imposer.
- Quelqu'un en ressaisit les données chaque semaine, dans un CRM, une facture ou un autre tableur.
- Former un collègue prend une heure d'explication du fichier, et il se trompe quand même pendant un mois.
Chiffrez ce que l'attente vous coûte
Avant de décider quoi que ce soit, mesurez. Prenez une tâche manuelle récurrente, chronométrez-la honnêtement, puis multipliez : minutes par occurrence, par nombre d'occurrences par semaine, par nombre de personnes concernées.
À titre d'exemple, une ressaisie quotidienne de vingt minutes faite par trois personnes représente cinq heures par semaine, environ deux cent cinquante heures par an. Que cela justifie ou non un remplacement dépend de ce que coûtent ces heures et de ce que ces personnes feraient à la place. Dans tous les cas, vous avez désormais un chiffre plutôt qu'une impression.
Ajoutez ensuite les deux choses que le calcul oublie : ce que coûtent les erreurs quand elles arrivent jusqu'au client, et le risque que la seule personne qui comprend le fichier s'en aille.
Quand le tableur reste la bonne réponse
Beaucoup de tableurs doivent rester des tableurs. Gardez-le si le processus change de forme toutes les deux semaines, parce qu'un logiciel évolue moins vite qu'une colonne. Gardez-le si une seule personne l'utilise, s'il s'agit d'un modèle de calcul plutôt que d'un registre, ou si vous cherchez encore à définir le processus.
Un tableur est aussi le moyen le moins cher de prototyper un processus incertain. Reconstruire trop tôt fige un fonctionnement avant que quiconque sache s'il est le bon, et cela coûte plus cher que d'attendre.
Ce que le remplacement implique vraiment
- Cartographier le processus tel qu'il tourne aujourd'hui, exceptions comprises. C'est dans les exceptions que se cachent les vrais besoins.
- Modéliser les données : ce qu'est une fiche, les états par lesquels elle passe, et les champs réellement utilisés plutôt que simplement présents.
- Définir de vrais droits, pour faire disparaître le bricolage des filtres et des colonnes masquées.
- Importer l'historique. Si la nouvelle application démarre vide alors que des années de données utiles restent dans le tableur, les équipes garderont l'ancien fichier ouvert à côté, et vous aurez ajouté un second système au lieu de remplacer le premier.
- Faire tourner les deux en parallèle sur une période courte et définie, puis arrêter le tableur à une date, pas au ressenti.
- Garder un export. Remplacer un tableur ne doit pas revenir à échanger une dépendance contre une pire, donc les données doivent pouvoir ressortir dans un format exploitable.
Ce qui fait le prix
Le prix de ce type de projet dépend de quatre choses : le nombre de types de fiches, le nombre de systèmes avec lesquels l'outil doit échanger, le nombre d'utilisateurs avec des droits différents, et le fait de devoir reprendre ou non des années d'historique.
Un outil à un seul type de fiche pour une équipe n'a rien à voir avec un système synchronisé avec votre comptabilité et tenant un historique opposable à un régulateur. Tant que ces quatre points ne sont pas connus, une estimation repose sur des hypothèses plutôt que sur le périmètre réel.
Si plusieurs des signes ci-dessus vous parlent, l'étape utile n'est pas un devis. C'est de mesurer la tâche manuelle qui coûte le plus cher, puis de décider si la supprimer se rembourse. C'est l'audit par lequel nous commençons en général, et il vaut la peine d'être fait même si vous ne construisez rien ensuite.