Un guide pour trier toute une pile de tableurs, et pas un seul fichier : comment inventorier les tableurs sur lesquels une entreprise fonctionne, décider lesquels garder tels quels, lesquels automatiser et lesquels reconstruire en véritable logiciel, puis organiser la bascule pour que rien ne casse.
Les entreprises en croissance où une pile de tableurs partagés est discrètement devenue le système d'exploitation, et où cela commence à faire mal.
- Un inventaire clair des tableurs sur lesquels votre entreprise fonctionne réellement
- Une décision garder / automatiser / reconstruire pour chacun d'eux
- Une bascule échelonnée qui ne met jamais toute l'entreprise en jeu
À un moment donné, une entreprise cesse de fonctionner sur un logiciel et se met à fonctionner sur une pile de tableurs, un pour les prospects, un pour les projets, un pour les stocks, trois pour les finances, que personne n'a planifiés et dont tout le monde dépend. Les remplacer n'est pas une seule migration ; c'est une décision de portefeuille. Certaines de ces feuilles sont parfaitement bien, d'autres ont juste besoin qu'on cesse de les recopier à la main, et quelques-unes sont devenues discrètement le cœur risqué de l'entreprise. Ce guide explique comment distinguer les unes des autres, et comment les faire basculer sans catastrophe.
Parce qu'une entreprise ne fonctionne pas sur un seul tableur ; elle fonctionne sur une pile de tableurs, et ils ne se valent pas tous. Certains ne contiennent rien de critique et resteront très bien pour toujours. Certains sont très bien, à l'exception de la recopie manuelle d'un fichier à l'autre. Quelques-uns sont devenus le cœur non audité dont l'entreprise dépend réellement, là où un chiffre erroné coûte de l'argent bien réel. Les traiter comme un seul grand projet « remplacer tous les tableurs » est la meilleure façon de faire échouer ces efforts ; la bonne démarche consiste à trier la pile et à agir sur chaque feuille selon ce qu'elle est vraiment.
Si l'approche du tout-en-un-coup échoue, c'est qu'elle est énorme, risquée et le plus souvent inutile. La plupart des tableurs d'une entreprise sont inoffensifs, et les reconstruire n'apporte rien. La valeur est concentrée dans quelques feuilles, celles qui sont porteuses, sujettes aux erreurs et recopiées à la main, et les trouver constitue tout le travail. Un tri vous indique où dépenser vos efforts et, tout aussi important, où ne pas les dépenser.
Le premier geste n'est donc pas de construire quoi que ce soit. C'est de regarder toute la pile et de la trier, car vous ne pouvez pas raisonnablement remplacer ce que vous n'avez pas inventorié.
Prenez un court moment pour lister les tableurs dont l'entreprise dépend réellement et, pour chacun, notez les quelques faits qui décideront de son sort. C'est un exercice sur papier, et c'est l'heure la plus rentable de tout le projet.
Une entreprise de logistique supposait devoir « remplacer tous les tableurs » et se préparait à un chantier colossal. L'inventaire a révélé quatorze feuilles, dont onze étaient inoffensives et parfaitement bien, deux avaient juste besoin que le copier-coller hebdomadaire entre elles soit automatisé, et exactement une, le suivi des expéditions dont tout le monde dépendait et qui cassait chaque mois, constituait le vrai risque. Le projet est passé de « tout reconstruire » à « reconstruire une feuille, automatiser deux coutures, laisser onze tranquilles », et c'est pour cela qu'il a réellement abouti.
Une fois l'inventaire en main, chaque tableur tombe dans l'une des trois catégories, et les faits que vous avez notés désignent clairement laquelle.
Le réflexe, une fois décidé à « quitter les tableurs », est de tous les remplacer, mais c'est presque toujours une erreur. Un tableur est vraiment le meilleur outil pour une tâche simple, à faible risque et à propriétaire unique, et reconstruire celles-là en logiciel ajoute du coût et de la rigidité sans aucun bénéfice. Le gain vient de la reconstruction des quelques feuilles porteuses et de l'automatisation des quelques coutures manuelles, puis du fait de laisser délibérément le reste tranquille. La retenue fait partie de la stratégie.
Une fois que vous savez quelles feuilles reconstruire et quelles coutures automatiser, l'ordre et la méthode vous évitent de miser l'entreprise sur une bascule d'un seul coup.
Ce qui rend cela réalisable aujourd'hui, c'est que reconstruire les quelques feuilles qui le nécessitent ne signifie plus un développeur, un budget et une file d'attente. Vous pouvez décrire le flux de travail derrière un tableur porteur, ses enregistrements, ses règles, qui y touche, et obtenir une application fonctionnelle le jour même, puis la faire tourner aux côtés de la feuille et retirer la feuille une fois qu'elle a gagné votre confiance. La pile qui a grandi par accident se fait remplacer volontairement, une décision réfléchie à la fois, et vous gardez la propriété du logiciel et des données que vous construisez. Décrivez les feuilles qui valent la peine d'être reconstruites et obtenez un logiciel taillé pour elles, pour que le système d'exploitation accidentel devienne celui que vous avez vraiment choisi.
Presque jamais tous. Une entreprise fonctionne sur une pile de tableurs qui ne se valent pas : la plupart sont inoffensifs et très bien, certains ont juste besoin que la recopie manuelle entre eux soit automatisée, et quelques feuilles porteuses et sujettes aux erreurs valent la peine d'être reconstruites en logiciel. Triez la pile et agissez sur chaque feuille selon ce qu'elle est ; la retenue fait partie de la stratégie.
Inventoriez chacun et demandez-vous ce qu'il contient, ce qui casse s'il est faux demain, comment il est relié aux autres feuilles, et à quelle fréquence il déraille déjà. Reconstruisez les feuilles porteuses, sujettes aux erreurs et à plusieurs personnes, là où la validation et les permissions sont rentables ; automatisez les coutures où les feuilles sont recopiées à la main ; et gardez telles quelles les feuilles simples, à faible risque et à propriétaire unique.
La plus risquée d'abord, pas la plus facile. Reconstruisez la seule feuille porteuse et sujette aux erreurs avant les simples, importez les vraies données, et faites tourner le nouveau logiciel aux côtés de la feuille pendant une semaine ou deux comme filet de sécurité. Automatisez ensuite ses coutures manuelles et passez à la suivante. Des pièces qui fonctionnent, l'une après l'autre, valent mieux qu'une bascule d'un seul coup qui casse plusieurs processus à la fois.
Plus dans la plupart des cas. Vous pouvez décrire le flux de travail derrière un tableur porteur, ses enregistrements, ses règles et qui l'utilise, et obtenir une application fonctionnelle le jour même, la faire tourner en parallèle de la feuille, et retirer la feuille une fois qu'elle a gagné votre confiance. C'est ce qui rend le tri et le remplacement des seules feuilles qui comptent réalisables plutôt qu'un grand chantier.