Why "We're Not Ready for ERP" Usually Means The Opposite
By Steve Leadbeater
Most of my working week is spent inside one ERP system, tracing why a number came out the way it did. People assume that means chasing bugs. It rarely does. The single most common thing I am asked to explain is not a defect, it is a result of two people looking at the same business and seeing two different figures, and somebody needs to work out which one to believe.
In companies that have not yet consolidated onto a single system, that conversation happens constantly, and it has a very recognisable shape. Sales has a number. Finance has a different number. The warehouse has a third. Operations has a fourth that nobody else has seen. Each one is defended vigorously, and here is the uncomfortable part: each one is usually correct. Correct as of the moment it was taken, from the source it was taken from, on the assumptions that were current that morning.
That is the actual problem, and it is not a spreadsheet problem. A spreadsheet is a snapshot. A business is continuous. Every hour that passes after an export, the gap between the file and reality widens, and nobody can see it widening. By the time the four numbers meet in a meeting, the disagreement is not about arithmetic. It is about which moment in time everyone is standing in.
What the gap actually costs
The costs of running this way do not appear on any invoice, which is exactly why they survive scrutiny for so long. They show up as:
- Reconciliation labour. Skilled people spending days a month proving that two files disagree, then agreeing a third number that neither file will be updated to reflect.
- Decisions made on stale data. Not wrong decisions exactly, but decisions taken against a picture of the business that expired some hours or days ago.
- Promises made against inventory that is not there. The sales commitment that the warehouse cannot fill, discovered at the point of picking rather than the point of promising.
- Delay. The days a question takes to answer, and the decisions that quietly do not get made because nobody wants to open that particular file.
None of this is anybody's fault. It is the arithmetic of running a business on copies.
What a single system actually changes
People sometimes expect me to argue that an ERP system is better because it has more features. That is not the argument. The argument is narrower and more important: it is that there is one record, and it means one thing.
A concrete example from Visibility. When a shipment posts, it writes to shipping history against the release line it came from. That same release line is what AR invoices against, what the order enquiry reads from, and what commission calculations resolve to. There is no export, no re-key, no separate shipping log to reconcile against the sales ledger at month end. The question "did that actually ship, when, and on which invoice" has exactly one answer, and it is available immediately, for that order, years later.
The value is not that the system does something clever. It is that there is nothing left to reconcile, because there was only ever one record to begin with.
Three questions worth asking yourself
- How many separate files feed your month-end numbers, and how many people maintain them?
- How long does it take you, right now, to answer "did order 4471 ship, and has it been invoiced?" Time it properly, including the wait for whoever has to look it up.
- How many times last quarter did you promise stock you turned out not to have?
If those answers are comfortable, you genuinely may not need to change anything yet. If they are not, you are already paying for the system you have decided not to buy. The only question is whether the payment shows up somewhere you can see it.
Contact us to see what one system, one record, actually looks like for your business.
