Do You Need an ERP, or an Integration? The Five-Question Test.

The sentence usually arrives fully formed. We have outgrown this; we need an enterprise resource planning system. It arrives after a bad quarter, a physical count that did not match the system, a month-end close that ran eleven business days. Somebody senior says it, nobody disagrees, and within weeks there is a shortlist and a line in next year's budget. That sentence is a conclusion, not a diagnosis. For a large share of the companies that reach it, it is the right feeling attached to the wrong cause, and the two causes cost very different amounts to fix.

This video is the test that separates them. It takes about an hour with five people in a room, and it is worth running before the first vendor demo rather than after the third. Everything on screen is a mock demo with sample data: invented systems drawn as plain boxes, invented orders, an invented company. Look at the symptoms that produce the sentence. 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 say what shipped last week without asking two people.

The stock on the website disagrees with the stock in the warehouse. And every new operations hire learns a set of manual steps that exist only to bridge two tools. Every one of those is real. And not one of them names its own cause. All five are equally consistent with we do not have a resource planning system, 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, and not by consensus in a bad meeting.

There are three failures hiding behind those symptoms, and from the outside they look the same. The first is a capability problem: 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 a person represents it in a spreadsheet. This is the failure a resource planning system actually solves. The second is an integration problem: 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. The third is the quiet one, a system-of-record problem. Two systems both hold the customer and nobody has ever agreed which one 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 they need a suite have some of the second and a lot of the third. Run the five questions in order and write the answers down, because the pattern across them is the answer, not any one alone.

Question one: 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 that cleanly, you do not have a suite 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 signal for the suite. Question two: take last month's worst operational failure and trace it backwards to the step where the data stopped moving.

A failure that traces to somebody re-keying, a nightly file that did not run, or a field that means two things in two systems is an integration failure. A failure that traces to the system cannot represent that is a capability failure. Question three: count the transactions no system is holding. Work orders, landed cost, allocation across warehouses, revenue recognition. If the honest answer for three or more of those is a spreadsheet one person maintains, the capability is genuinely missing, and a spreadsheet doing production work is a system of record nobody is accountable for.

This is the strongest single signal on the list. Question four: is the fix a field or a process? A mapping, a trigger, an agreement about who edits what is integration work. A general ledger that has to behave differently, a different costing method, a different revenue timing, is suite territory. Question five decides it. Imagine every record is correct and current in every system by tomorrow morning. Nothing re-keyed, nothing stale, everything reconciles. Now go back to the list of problems that started the conversation. Which ones are still there?

Whatever survives is the case for the suite. In our experience that list is far shorter than the one that opened the meeting, and occasionally it is empty. Zero to two signals: the problem is connection and governance. Fix it as an integration program with named data owners. That is measured in weeks, it costs a fraction of a replatform, and nobody has to learn a new system to keep their job. Three or more, especially on questions three and five: there is a real capability gap and a suite is a legitimate answer, though the order of work still matters.

A split result, clear gaps in one function and 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. And if it is an integration problem, do it in this order. Name the owner of each record first, because every later decision depends on it. Connect the two systems whose disagreement costs the most. Then retire the spreadsheet that was standing in for the missing join. The sentence that started this video may still be true at the end of the test.

It is just true for far fewer companies than say it. Five questions, one hour, five people. Name the record, trace the failure, count the spreadsheets doing production work, ask whether the fix is a field or a process, and ask what survives a perfect sync. If you would like to run the test on your own systems with somebody who has run it before, that is the first hour of a no-risk discovery: you pay only if you go ahead. We are CodeStringers. We design, build and run business systems for companies of fifty to a thousand people, and we would rather connect what you have than sell you what you do not need.

The article with the full test is linked below.