Do You Need an ERP, or Do You Need Your Systems to Talk to Each Other?
The sentence usually arrives fully formed. "We've outgrown this. We need an ERP."
It arrives after a bad quarter. A physical count that didn't match the system. A month-end close that ran eleven business days. A customer invoiced twice, then chased for the second one. Someone senior says it out loud, nobody disagrees, and within weeks there is a shortlist, a demo calendar, and a line item in next year's budget.
That sentence is a conclusion, not a diagnosis. And for a large share of mid-market operators who reach it, it is the right feeling attached to the wrong cause. What they are describing is usually an integration problem and a system-of-record problem, stated in the vocabulary of a software category. Those are different failures, they cost very different amounts to fix, and confusing them is expensive in one specific direction: an ERP program is measured in quarters and internal headcount, while an integration program is measured in weeks and does not require anyone to relearn their job.
There is a test that separates the two. It takes about an hour with the right five people in the room, and it is worth running before the first vendor demo rather than after the third.
Why the conclusion lands on "ERP"
Look at the symptoms that produce it:
The same order exists in three systems with three different statuses.
Finance closes the month by exporting to spreadsheets and reconciling by hand.
Nobody can answer "what did we actually ship last week" without asking two people.
Inventory on the website disagrees with inventory in the warehouse.
Every new operations hire learns a set of manual steps that exist only to bridge two tools.
Every one of these is real, and none of them names its own cause. All five are equally consistent with "we don't have an ERP" and with "we own perfectly adequate systems that were never connected, and never had an owner assigned to each piece of data." That is why the diagnosis has to be made deliberately rather than by consensus in a bad meeting.
Three failures that look identical from the outside
A capability problem is when something the business must do has no system to do it in. You cannot hold a partial receipt against a purchase order. You cannot cost a work order. There is nowhere to record landed cost. The software does not represent the thing, so people represent it in a spreadsheet. This is the failure an ERP actually solves.
An integration problem is when every capability exists somewhere, but the data does not move between systems, or moves overnight when it needs to move in seconds, or moves in both directions and the two copies fight. Nothing is missing. Nothing is connected.
A system-of-record problem is the quiet third one. Two systems both hold the customer, and no one has ever agreed which is authoritative. Sales updates one, finance updates the other, and both are right in their own building. Buying a third system does not settle that argument. It adds a party to it.
Most companies that say "we need an ERP" have some of the second and a lot of the third.
The test
Run these five questions in order. Write the answers down, because the pattern across the five is the answer — not any one of them alone.
1. Name the system of record for each core object. Customer, product, order, inventory, invoice, employee. One system per object, out loud, with everyone agreeing. If you can do this cleanly, you do not have an ERP problem — you have an integration problem, and a solvable one. If two systems both claim an object, that is a governance failure and no purchase fixes it. If an object has no home at all, that is your first genuine ERP signal.
2. Take last month's worst operational failure and trace it backwards. Find the step where the data stopped moving. Failures that trace back to someone re-keying, a nightly file that didn't run, or a field that means two different things in two systems are integration failures. Failures that trace back to "the system can't represent that" are capability failures.
3. Count the transactions no system is holding. Where do work orders, landed cost, multi-warehouse allocation, and revenue recognition live today? If the honest answer for three or more of them is "a spreadsheet one person maintains," the capability is genuinely missing. This is the strongest single ERP signal on the list, because a spreadsheet doing production work is a system of record nobody is accountable for.
4. Ask whether the fix is a field or a process. If the fix is a mapping, a trigger, or an agreement about who edits what, it is integration work. If the fix requires the general ledger itself to behave differently — different costing method, different revenue timing, different inventory valuation — you are in ERP territory.
5. Ask what survives a perfect sync. This is the one that decides it. Imagine every record is correct and current in every system by tomorrow morning. Nothing is re-keyed, nothing is stale, everything reconciles. Now go back to the list of problems that started the ERP conversation. Which ones are still there?
Whatever survives is the ERP case. In our experience it is a far shorter list than the one that opened the meeting — and occasionally it is empty.
Reading the result
Zero to two ERP signals. The problem is connection and governance. Fix it as an integration program with named data owners. This is measured in weeks, costs a fraction of a replatform, and nobody has to learn a new system to keep their job.
Three or more, especially on questions 3 and 5. There is a real capability gap and an ERP is a legitimate answer. Even then, sequence matters — see below.
A split result — clear capability gaps in one function, clean systems everywhere else — usually points at one system, not a suite. A distributor missing warehouse capability needs a warehouse system connected properly, not a finance replatform to get it.
If it is an integration problem
Fix it in this order, because the order is what makes it cheap:
Assign the system of record for every core object, in writing. This costs nothing and returns more than any software purchase on the table. Half the "data quality" complaints in a mid-market business are two departments both being correct.
Connect the flows that carry money and commitments first. Quote to order to invoice to payment, and inventory. Marketing data can wait a quarter; a wrong invoice cannot.
Make the sync observable. An integration nobody monitors is a manual process with a delay built in. Someone must see it fail, on the day it fails.
Retire the manual bridging steps deliberately. They do not disappear on their own. People keep the old spreadsheet running "just in case," and that is how a fixed system quietly un-fixes itself.
This is ordinary work, and it is the work we do most often. Connecting the applications a business already pays for closes a surprising share of the gap that gets attributed to a missing ERP, and connecting Zoho to the rest of the stack is usually where it starts, because the CRM and the accounting system are where the money actually moves.
If it genuinely is an ERP problem
Then integration is not the alternative. It is the first phase.
An ERP does not arrive connected to your warehouse system, your ecommerce platform, your EDI partners, or your field service tooling. Those connections get built, and their quality decides whether the ERP becomes the operating system of the business or an expensive general ledger with a data entry team attached. ERP integration in a distribution business is a good look at how much of the value sits in the connections rather than the platform.
And before anyone commits to building the thing from scratch, the economics of a custom ERP build are worth reading, because they rarely favor the build.
One more reason to be slow. The mid-market ERP field is in motion — the vendors that were the default answer five years ago are not the only credible answers now, and more are arriving. An ERP chosen today is a commitment measured in years. That argues for spending an hour on the diagnosis, and for fixing the integration and governance problems either way, since that work is required in every version of the future.
Common questions
Can integration work be wasted if we buy an ERP later?
Rarely, if it is done in the right order. Naming a system of record for each object is portable — it is a decision about your business, not about a platform. Point-to-point connections built for a system you later retire are the part that gets thrown away, which is a reason to fix the data ownership first and build the connections second.
How long does this diagnosis take?
The five questions above take about an hour with operations, finance, and whoever actually maintains the spreadsheets. Verifying the answers against real transaction data takes a few days. That is short enough that there is no good reason to skip it.
What if the answer comes back "integration" but leadership already decided on an ERP?
Then run the integration program anyway and treat it as the first phase of the ERP program. It reduces scope, it exposes the data problems before they are migrated into a new system, and it is the only version of this where the answer being "no ERP" costs nothing.
Where we stand on this
We would rather tell a client they do not need the thing they came in asking for. That is easier to say when being wrong has a price: our discovery is no-risk — you pay for it only if you proceed to implementation — and our estimates are guaranteed, so if we size the work low, we absorb the difference. A firm that eats its own estimating errors has every incentive to diagnose the problem correctly the first time.
If the answer is integration, that is our integration practice. If it is an ERP, the connections and the ongoing operation of them are Managed Technical Operations, and that continues after go-live, when most of the real failures actually happen.
Run the five questions before the demos. An hour spent on the diagnosis is the cheapest hour in the whole decision.
Comments