Writing
When the spreadsheet is already the system
The spreadsheet running your production schedule is not a failure of discipline. It is a working system with three specific weaknesses, and only one of them is worth fixing first.
Most plants that run production off a spreadsheet did not end up there by accident, and the people maintaining it are usually the ones who understand the operation best. The spreadsheet exists because it was faster than waiting for the ERP to be configured, and it survived because it works.
That is the starting position worth being honest about. The question is not how to stop people using spreadsheets. It is which of the spreadsheet’s actual weaknesses is costing something today.
The three weaknesses, in the order they usually hurt
Nobody owns a row. A spreadsheet records what is true, not who is responsible for changing it. When a job stalls, the sheet shows the stall but not who was expected to act, or by when. The recovery conversation starts with reconstructing who knew what, which is the expensive part.
State is implied, not recorded. A cell turning yellow means something to the person who coloured it. Six weeks later it means something slightly different, and a year later nobody can reconstruct the reasoning. The colour survives; the decision behind it does not.
History is overwritten. Every edit destroys the previous value. When a customer asks why a promised date moved twice, the evidence has already been written over by the current answer.
Only the third is genuinely hard to work around, and it is usually the one that gets noticed last — right up until the moment somebody has to explain a slipped commitment and the record cannot support any version of the story.
What actually changes when the work moves off the sheet
The useful shift is not visibility. Most operations already have visibility; they have a screen somebody watches. The shift is that a state change starts carrying who, when, and why with it, so the record answers questions after the fact rather than requiring someone’s memory.
That is a smaller change than a system replacement and a larger one than a better dashboard. It also means the first move is rarely a migration. Existing records keep ownership of their data while the operating layer reads state from them.
When this is the wrong first move
If the schedule is stable, the team is small enough that ownership is obvious without recording it, and nobody has been asked to reconstruct a decision in the last year, the spreadsheet is not costing anything yet. Building an operating layer around a problem you do not have is how software becomes the drag it was meant to remove.
The signal to watch for is not the spreadsheet. It is the reconstruction: the first time somebody spends an afternoon working out what happened, that afternoon is the cost, and it will recur.
If this post matches something in your own operation, we want to hear about it. Choose whether you are responding directly or offering your own story for publication below.
If this reads like your operation, there are two places to go next.
