Spreadsheets are underrated. Flexible, universally understood, and a good one will run a business further than software vendors like to admit.
The question is not whether they are bad. It is how to recognise the point at which yours has become the bottleneck.
The symptoms, in the order they appear
Two people have different numbers. Someone quotes stock from their copy, someone else from theirs, both confident. This is the first real signal and the one most often explained away.
Month-end takes days. Not because the arithmetic is hard, but because the data lives in five files that must be reconciled by hand.
Only one person understands the file. Fourteen tabs, some hidden, a formula nobody will touch. When that person is on leave, decisions wait.
You key the same thing twice. An order entered once for the invoice, again for stock. Eventually they disagree and finding out which is right costs an afternoon.
Simple questions take too long. Which product line made the most margin last quarter? If that is more than a few minutes, you are paying for the delay in decisions not made.
Two or three of these is normal for a growing business. Four or five, consistently, means the spreadsheet now costs more than it saves.
What an ERP actually is
The term is inflated, so plainly: one database that several parts of the business read from and write to, so stock, purchasing, sales, invoicing and reporting refer to the same records.
That is the whole idea. The modules and dashboards sit on top of that single point.
Which is why the honest test of an ERP project is not the feature list. It is whether the numbers now agree.
Off-the-shelf first
We say this even when it costs us the work: try the standard product before commissioning anything bespoke. It is cheaper, supported by someone else, and updated without you paying.
Build only when one of these is genuinely true:
- your process has a step the platform cannot represent, and that step is a real advantage rather than a habit
- per-seat licensing now exceeds what a build would amortise to
- the data you need lives in systems with no viable integration
- an off-the-shelf rollout already failed because the tool fought how the team works
Note what is not on that list: "we are unusual". Most businesses believe they are. Most are not, in the ways software cares about.
Why these projects fail
Two reasons, neither technical.
Scope. Someone decides to replace everything at once. Eighteen months later the budget is gone and the business is still on spreadsheets, because the new system was never finished enough to switch to.
Adoption. The system is built to an idealised process nobody follows, so the team keeps a shadow spreadsheet — and now you have both.
The way through is unglamorous: start with the module that hurts most, get it genuinely live, then add the next. A working stock module beats a complete system still in testing.
Before calling anyone
Two things, both free.
Write down your actual process — not the handbook version, the one people follow, workarounds included. The workarounds are the requirements.
Then count the symptoms honestly. At two, fix the spreadsheet: lock the cells, put it somewhere shared, agree who owns it. At five, the spreadsheet is no longer the thing to fix.
