Has Your Business Outgrown Its Software?

Most operational software is not replaced because it broke.

It is replaced because the business moved and the system stayed where it was.

That gap opens slowly. A workaround here, a spreadsheet there, an exception someone handles by email. Each one is reasonable on the day it is invented. Together, over two or three years, they become the way the company actually runs — and the system becomes a partial record of it.

The difficulty is that none of this presents as failure. Nothing crashes. Nobody raises a ticket that says the platform no longer matches the operation. The cost arrives as effort instead: more coordination, more checking, more people who have to be asked.

Below are nine signs that the gap has opened. They are written as things you can observe from where you sit, not as things you would need an engineer to diagnose. Count the ones you recognise. There is a short guide to reading the total further down.

None of them, on its own, means anything is wrong.

Someone on the team starts keeping a spreadsheet. Then two people are keeping spreadsheets.

They are not doing it to be difficult. They are doing it because the system holds most of what they need and not the part they are accountable for — the approval that has to be tracked, the exception list, the status that does not map to any of the available statuses.

What it indicates. The system models a workflow the business no longer runs. The sheet is not the problem. It is the documentation of the gap, maintained voluntarily by the person closest to it.

What to do with it. Read the sheets before you do anything else. Every column in a shadow spreadsheet is a field the system should have had, and whoever maintains it has already done the requirements analysis.

An order is keyed into the platform. Then the same order is keyed into accounts. Perhaps also into a despatch sheet, or a supplier portal.

What it indicates. An integration gap, not carelessness. Two systems hold the same fact and there is no agreed path between them.

The cost is not the keystrokes. It is that the two records are now independent, and independent records drift. Someone amends one of them. Weeks later the two disagree and nobody can say which is right without asking a person.

This is the sign that scales worst. The chance of a mismatch rises with volume, while the effort of finding one rises with the number of records you have to check. Both curves point the same way. Systems integration and workflow automation is the category of work that closes it.

The order that ships differently. The customer on a negotiated rate. The approval that depends on who is on shift.

Ask where those are recorded and the answer is a person, a message thread, or an email folder.

What it indicates. The data model has nowhere to put the exception, so the exception went somewhere the data model cannot see.

Every operation has exceptions. Mature systems are not the ones with fewer of them. They are the ones where an exception can be recorded, attributed, and found again a year later. When exceptions live outside the system, the system's reports describe a version of the business that does not exist.

There is a task one person completes and nobody else attempts. Not because of permissions — because only they know the sequence.

When they are on leave, that work waits.

What it indicates. Process encoded in a person rather than in the system. This usually reads as a staffing problem and gets treated as one: cross-train somebody, write a runbook. The underlying issue is that the system permits an undefined process to exist at all.

It is also the sign with the sharpest downside, because it turns an ordinary event — somebody leaving — into an operational incident.

Month end takes a week. Two departments produce different figures for the same thing, and the meeting is spent reconciling rather than deciding.

What it indicates. No single source of truth. The number exists in several places, each maintained by a different process, and none of them is authoritative.

The second-order effect is the one that matters. When reporting is slow and contested, people stop asking questions of the data. Decisions revert to instinct — not because anyone chose that, but because the cost of getting an answer came to exceed the value of having one.

You ask for something that sounds small. Add a field. Change who receives a notification. The answer comes back in weeks, and it comes back hedged.

What it indicates. Coupling. The small change touches more of the system than it should, and nobody can be confident about what else will move when it does.

Two things usually sit underneath it. There are no automated tests, so the only way to know something still works is to check it by hand. And there is no clear ownership, so changes are made cautiously by people who did not design the thing they are changing.

The symptom to watch is not the estimate. It is the hedging. Long-term platform support is largely the work of making that hedge unnecessary.

The system is fine, except at month end. Or on the sale day. Or the Monday morning when the whole field team syncs at once.

What it indicates. Architecture tuned for average load. That is a reasonable thing to have built, because average load is what you can observe while building it. But it means the platform is least available exactly when it carries the most.

This sign has an unusually direct commercial reading. The hours you lose are the hours you had the most to gain.

A new starter can be shown the system in an afternoon but cannot work unsupervised for a month.

What it indicates. The system does not reflect the operation, so being competent means knowing both — what the screen says, and what the team actually does about it.

Onboarding time is a useful proxy precisely because nobody games it. It is the length of time it takes to transfer the undocumented layer from one head to another.

You learn an order did not ship because the customer rang. You learn a payment failed when it shows up on a statement.

What it indicates. Monitoring exists at the infrastructure level — servers, uptime, error rates — and nowhere at the level of business events. The platform can tell you it is running. It cannot tell you that nothing has been despatched since Tuesday.

This is the sign most often missed on an internal review, because every dashboard is green. Green dashboards measure the system's opinion of itself.

Now the important qualification. Six or more does not mean rebuild. That is the conclusion people tend to reach, and it is usually the most expensive option available and rarely the right first one.

A high count means the gap between the operation and the system is now wide enough to be costing real money, and that the next move should be a decision rather than a reaction. Several of these signs — re-keying, exceptions with nowhere to live, blindness to business events — are integration and modelling problems that can be resolved without replacing anything.

Which signs cluster matters more than how many there are:

• Signs 1, 2 and 3 together point at the data model.
• Signs 4, 5 and 8 point at undocumented process.
• Signs 6, 7 and 9 point at engineering practice.

Three in one group is a far clearer instruction than six spread evenly across all three.

One engagement we can describe, though not name. A manufacturing group running a packaged ERP alongside a set of spreadsheets and a quantity of institutional knowledge held by a few long-serving people. Signs one, three and four, in the language above.

The instinct in that position is to configure the packaged ERP harder until it fits. That is where these projects usually go wrong: the customisation becomes its own maintenance burden, and the business ends up working around the system it paid to adopt.

What we did instead was model the operation first and build around it, in phases, so each phase was usable on its own. The outcome, stated the way the client's confidentiality allows: the group runs on one system rather than a mixed arrangement, the process was not reorganised to suit the software, and exceptions have somewhere to live.

Read the case study — published anonymously, at the client's request.

Three things, none of which require hiring anyone.

Log the workarounds for two weeks. Ask the team to note every time they step outside the system to get something done. Not to police it — to collect it. Two weeks is enough to see the pattern, and the list will be more accurate than any audit you could commission, because it is written by the people doing the work.

Find the cluster. Group what comes back against the three categories above. You are looking for concentration, not volume.

Decide the response deliberately. Stabilise, integrate and rebuild are three different answers with very different costs. The common error is choosing the last one because the first two were never properly considered.

If it would help to have someone look at it with you, that is what a system review is: an assessment of where the setup is fragile, what will break as usage increases, and what to fix now versus later.

Software rarely announces that it has been outgrown.

It reports the news as friction. A spreadsheet. A second entry. A person who cannot take leave. A month end that takes a week.

None of those is a failure. All of them are information. Read together they say something quite specific: the business has changed shape, and the system has not been changed to match.

The cost of noticing early is a decision. The cost of noticing late is a rebuild.