Un tableur est un bon outil pour une installation de 40 pièces, et prétendre le contraire est la façon la plus rapide pour un éditeur de logiciel de perdre sa crédibilité auprès des gens qui mènent réellement des projets.
La question intéressante n’est pas de savoir si les tableurs fonctionnent. C’est de savoir quelles propriétés précises cessent de tenir quand un projet grossit, et comment remarquer que la ligne a été franchie avant la fenêtre d’installation plutôt que pendant.
Six propriétés, à peu près dans l’ordre où elles lâchent.
1. Les écritures simultanées pendant un déchargement
Le déchargement d’un conteneur est le seul moment où plusieurs personnes doivent écrire dans le même dossier en même temps. Un réceptionnaire à la porte, une deuxième personne qui compte, un superviseur qui consigne un dommage.
Un tableur partagé gère cela mal d’une façon particulière : il ne signale rien. La dernière sauvegarde l’emporte, en silence, et le compte saisi vingt minutes plus tôt a disparu sans laisser de trace.
L’échec est silencieux, ce qui explique qu’il soit généralement découvert en fin de projet, pendant la réconciliation, plutôt que le jour même. À ce moment-là, le conteneur est déchargé, les gens présents sont passés à autre chose, et le seul recours est un recomptage physique.
Ce qui remplace cela n’est pas « une base de données » dans l’abstrait. C’est que chaque transaction — cette ligne, cette quantité, cet opérateur, cet horodatage — soit consignée séparément, donc deux personnes qui comptent en même temps produisent deux dossiers plutôt qu’un écrasement.
2. Un emplacement qui reste vrai après un déplacement
Tout tableur de projet a une colonne d’emplacement. Elle est exacte le jour où elle est remplie et se dégrade ensuite, parce que le tableur n’a aucun lien avec le déplacement physique.
Quelqu’un déplace une palette pour faire de la place à un conteneur entrant. Le tableur ne le sait pas. Trois semaines plus tard, un cueilleur se rend à l’emplacement noté, ne trouve rien, et soit il cherche, soit il déclare la pièce manquante.
La propriété qui compte est que le déplacement mette à jour le dossier — l’emplacement est une conséquence de la transaction plutôt qu’un champ que quelqu’un pense à modifier. C’est aussi pourquoi « on sera disciplinés » ne survit pas à une semaine chargée : cela fait reposer l’étape la moins fiable sur le moment le plus sous pression.
3. Des photos rattachées à la pièce qu’elles documentent
Les photos de dommage se prennent au téléphone. Sur un projet mené au tableur, elles vivent ensuite dans une pellicule, une conversation de groupe, ou un dossier partagé nommé par date.
Six semaines plus tard, quand un fournisseur conteste une réclamation, quelqu’un doit retrouver la photo de ce buffet précis. Si la photo n’est pas rattachée à un dossier qui identifie la pièce, la réception, l’horodatage et l’opérateur, alors en pratique ce n’est pas une preuve — c’est l’image d’un buffet abîmé qui aurait pu être prise n’importe où.
C’est la propriété dont la conséquence financière est la plus nette. Le coût de l’échec n’est pas administratif : c’est le montant que vous ne récupérez pas auprès du transporteur ou du fournisseur.
4. Empêcher une pièce abîmée de partir
C’est celle qu’un tableur ne peut réellement pas faire, quel que soit le niveau de discipline.
Une ligne surlignée est un message à un humain qui la lira peut-être. Elle n’empêche pas un cueilleur de cueillir, et le jour où un projet charge trois camions, le cueilleur ne lit pas l’onglet des dommages.
Empêcher l’expédition exige une application dans le chemin de la transaction : un statut d’emplacement qui refuse le déplacement, une quantité retenue qui sort la pièce de la disponibilité, une tâche qui bloque au lieu de se terminer. Ce sont des propriétés du système, pas du processus, et c’est pourquoi une retenue dans un WMS et une retenue dans un tableur ne sont pas le même mot.
5. La chaîne de responsabilité
« Qui a fait quoi, et quand » ne se répond dans un tableur que par l’historique de versions, et seulement faiblement : il dit quel compte a modifié une cellule, pas quel opérateur a physiquement compté la palette.
Sur un petit mandat, cela compte rarement. Sur un gros, cela compte deux fois — une fois pour expliquer un écart, une fois quand un client pose une question précise sur la façon dont une pièce abîmée est arrivée chez lui.
Une identité d’opérateur et un horodatage système sur la transaction ne sont pas de la bureaucratie. C’est la différence entre un projet où les écarts s’expliquent et un projet où ils s’absorbent.
6. La responsabilité de la prochaine étape
Un tableur sous-entend la responsabilité par un nom dans une colonne. Il ne peut pas exprimer un état.
Dans une cellule, il n’y a aucune différence entre « assigné et en cours », « assigné et bloqué parce que la pièce est abîmée » et « assigné à quelqu’un qui est parti ». Les trois se ressemblent.
Des tâches assignées avec un statut — incluant un état bloqué avec un motif — transforment cela en travail visible. L’état bloqué est le plus utile : c’est lui qui permet à un opérateur de s’arrêter et de signaler plutôt que d’improviser un chiffre pour fermer la ligne.
Les signaux que la ligne est franchie
Plutôt qu’un seuil de références, surveillez ceci. Deux éléments ou plus, de façon récurrente, et le tableur a cessé d’être l’option économique :
- Quelqu’un occupe désormais un poste à temps plein à tenir le suivi plutôt qu’à faire tourner l’entrepôt.
- Vous réconciliez un comptage physique contre la feuille plus d’une fois par projet.
- Un client pose une question de statut et la réponse honnête exige d’aller marcher dans l’entrepôt.
- Les photos de dommage doivent être cherchées dans plus d’un système.
- Les affectations par pièce ou par étage sont refaites parce que le marquage initial n’est pas fiable.
- Le calendrier d’installation a glissé et mettre la feuille à jour a pris plus d’une heure.
- Une pièce abîmée est déjà partie vers un chantier au moins une fois.
Ce dernier point pèse lourd. C’est le seul de la liste qu’un client voit.
À quoi ressemble la suite
Quitter un tableur ne consiste pas à le remplacer par un tableur plus sophistiqué. Il s’agit d’acquérir les propriétés ci-dessus :
- Des transactions consignées séparément, donc le travail simultané ne s’écrase pas
- Un emplacement qui découle du déplacement plutôt que d’une modification manuelle
- Des preuves rattachées à la pièce, à la réception et à l’opérateur
- Des retenues que le système applique au lieu de les signaler
- Une identité d’opérateur et un horodatage sur chaque action
- Du travail sous forme de tâches assignées avec un véritable état bloqué
- Destination, pièce, étage, kit et séquence sur la ligne elle-même
- Une vue client en lecture seule qui supprime l’envoi hebdomadaire
Si vous pesez le changement, le guide des tableurs vers un WMS couvre la mécanique de transition, et la page logistique FF&E et de projet montre comment ces propriétés sont modélisées pour le travail de projet.