Common Problems in Manual Production Tracking With Spreadsheets

A rundown of the concrete failure modes that show up when a spreadsheet is used to track a live production process rather than a static record, and the point at which a manual, spreadsheet-based process stops being reliable enough to run a physical operation on.

A shared spreadsheet works when one or two people update it carefully. It stops working once there are several people, several stages, and real consequences for the numbers being wrong: stock that does not match what is on the shelf, a delivery that does not match what was scanned, a report that was already stale by the time someone read it.

These problems are easy to dismiss individually. A duplicate entry here, a stale copy there. But they compound, and by the time they are visible, the operation has usually already made a decision based on wrong numbers.

• No validation. A spreadsheet accepts whatever is typed into it, including numbers that do not reflect what happened and serials that were never accepted.
• No single source of truth. Multiple copies drift apart, and nobody is sure which one is current.
• No audit trail. It is rarely clear who changed what, or when, once something looks wrong.
• Delayed visibility. Problems surface in a weekly review, long after they happened on the floor.

Watch for the moment when people start keeping their own private copies of a shared sheet, to be safe. That is usually the sign. A private copy is a vote of no confidence in the shared one, and once two copies exist the question of which number is right has no answer the sheet can give.

That is also why the decision to move off spreadsheets is less about scale than it looks. A small operation with three people can cross this line; a large one with disciplined habits can stay on the right side of it for a long time. The question is whether the numbers can still be trusted.

Before RPOMS, the router-refurbishment programme I work on ran on spreadsheets. The system that replaced them is deliberately built around these exact failure modes rather than around a generic data-entry pattern.

• Validation at the point of entry: a serial is checked against configurable detection rules, and a packing screen checks it against the registry instead of trusting a typed value.
• One record per unit, with stock derived from the full history of adjustments and consumption rather than stored as a running total that can quietly diverge.
• Imports staged before they are written, so duplicates are surfaced for a row-by-row decision rather than discovered afterwards. The mechanics are in Staged CSV Import for Operational Data.
• A delivery that cannot be saved unless the scanned load matches the quantity it was raised for, so the mismatch is caught at the door rather than in a report.
• Figures entered once, with the dashboard and the stock deduction updated in the same step, so the numbers reflect what is happening rather than what was last typed in.

A digital system does not need to be complex to be worth it. It needs to remove the specific failure modes a spreadsheet has, and it only works if it fits how the operation actually runs, not the other way around.

These are not reasons to dislike spreadsheets in general. They are reasons a live, physical process usually outgrows one, and the moment it does is visible in behaviour before it is visible in the numbers.