How do you decide between an ERP and a best-of-breed point solution?

Decide it by counting records, not by company size. Write down the five or six nouns the business argues about: customer or site, order or contract, item or SKU, invoice, and person or shift. For each noun, name every function that writes to it and every function that only reads it. Then ask one question of each writer: must another function see this write as authoritative before the day ends? A noun with two or more authoritative same-day writers belongs in one system. A noun with one writer and many readers is a point solution plus an export. Count the nouns that fail. Zero or one failing noun means buy the point solution. Three or more means you are buying a core whether you like it or not. Two means the decision is genuinely open, and the cheaper answer is usually to move one of the two writers rather than to buy a suite.

erpification.com · the definition, and the service

Erpification / Guides / ERP or point solution

ERP or point solution

Q: When is an integration enough instead of a single system?

An integration is enough when one system can be named master for the record and every other system holds a read-only copy. The deciding variable is how stale that copy may be before something breaks: real time, same day, weekly, or month-end only. Make every claim for real time earn it by naming the breakage and how fast it arrives; a row where nobody can name what breaks takes a nightly file instead. An integration is not enough when two systems can both change the same field and neither has been declared master. That is an ownership problem rather than an integration problem, and no connector fixes it. Four questions settle whether a planned integration will hold: can you name the master for this record, does the shared entity carry the same permanent identifier on both sides, can a named non-engineer see a failed sync and fix it, and is the sync idempotent so that re-running it after a failure creates no duplicates.

Q: Is it true that most ERP implementations fail?

The widely repeated figure should not be used, because the definition rather than the number is the problem. The wording that gets quoted is that implementations fail to meet their original business goals, which is not the same claim as failing. Vendor and consultancy pages collapse the two. Run three questions against whichever version you are shown: which outcome was counted, over what population, and against whose stated goal. No version on offer answers all three, and no counter-figure belongs here either, because a second unsourced percentage would be the same mistake. The useful question is not a failure rate but which decision gate produced the outcome.

An ERP is what you buy when two functions must write to the same row. Everything else is a copy, and copies are cheap. The decision is a count, not a philosophy, and this page is the procedure for running it.

Guide · updated 2026-10-17

On this page

The shared-record test, twenty minutes
Writers, readers, and staleness as the deciding column
The two-week rekeying log
The mastership rule, as a go or no-go
The identifier precondition
Where the pain lives, and the counter-check
The reversibility check, per tool
Three years, with the lines vendors leave out
“We’ll just integrate it”, four questions
If several records fail, what goes in first
The numbers to refuse

Every comparison of ERP against best of breed stops at the level of the function. How many departments are affected, how big the company is, which revenue band it sits in. None of that is the question a practitioner actually faces, which is narrower and answerable: do two functions both need to change the same field and have the other see it as true? Payroll touches every department and still needs no shared record, because one function writes it and everyone else receives a report. A quote and an invoice touch two people and absolutely do need one.

The shared-record test, twenty minutes

Run it with the two or three people who argue about data, on paper, before any demo is booked. Six steps, and it produces a number. If it is still running after twenty minutes, stop: the disagreement you have just uncovered about who owns which field is a more useful finding than the count would have been.

List the nounscustomer or site, order or contract, item, invoice, person or shift
Name the writersevery function allowed to change it
Name the readersevery function that only looks
Ask the day-end questionmust another function see this write as true today
Count the failuresnouns with two or more same-day writers
Read the countthat number is the answer

The readingZero or one failing noun: buy the point solution and an export. Three or more: you are buying a core whether you like it or not. Two: the decision is genuinely open, and moving one of the two writers is usually cheaper than buying a suite.

The word “authoritative” is doing the work. A point solution that holds a read-only copy of the customer list is a non-event. A point solution that can change the customer’s address is a second truth. The usual advice treats those two cases identically, and they are not remotely the same purchase.

Writers, readers, and staleness as the deciding column

Then write the test out as a table, with one column nobody else asks for: how stale may the copy be before something breaks. That column, not the integration column, decides between an API, a nightly file and a single system. Expect the room to claim real time for every row, then make each claim earn it: name the breakage and name how fast it arrives. A row where nobody can name what breaks does not need real time; it needs a nightly file.

Record	Writes it	Only reads it	Staleness tolerated	What breaks when the copy is stale
Customer or site	Sales on creation, finance on billing details, operations on access and site notes	Marketing, support, reporting	Same day	An invoice posted to a superseded billing contact, or a crew sent to an address that changed last week
Order or contract	Sales on signature, operations on scheduling, finance on the amount invoiced	Management reporting	Real time	Work scheduled that was never signed, or signed work nobody scheduled. This is the row that usually decides the purchase
Item or SKU	Procurement on cost and supplier, product on specification	Sales, warehouse, finance	Weekly	A quote priced on a cost that moved, which shows up as margin erosion a month later
Invoice	Finance only, in practice	Sales, operations, collections	Same day	Collections chasing an invoice already paid, or a renewal discussion held without knowing the last one is unpaid
Person or shift	Operations on the roster, payroll on rates and hours approved	Finance, managers	Month-end only, for pay	Nothing, until the pay run. One writer per field here, which is why payroll stays a specialist tool
Stock on hand	Warehouse on counts and movements	Sales, e-commerce, finance	Real time, if you sell what you hold	Selling what is not there. Overselling is the one symptom where a nightly file is never sufficient

Fill the staleness column with the business, not with the person who will build the connector. The answer “real time” is free to say and expensive to buy, and in most columns it is wrong.

The two-week rekeying log

The test above relies on what people believe about their own process. The log checks it. For ten working days, everyone logs each time they type a value that already exists in another system: which record, which two systems, who did it, how long it took. One shared sheet, four columns, no analysis until the ten days are up.

Then apply the rule. The same record rekeyed daily by two different departments is a core-system signal. A record rekeyed monthly by one person is not. Buy the export and keep the point solution. This replaces “are we big enough” with something observable, and it is the only part of the decision that produces evidence a sceptical colleague cannot argue with.

It also makes room for the case nobody selling software will put in writing: living with double entry is sometimes correct. A low-volume handoff that one person performs once a month is cheaper to retype than to integrate, and it stays cheaper for years. Saying so would cost a vendor a sale, which is why you will not find it on a comparison page. Where headcount stops predicting the answer entirely is covered in ERP for a 50-person company.

The mastership rule, as a go or no-go

A point solution is safe exactly as long as you can name one system as master for its record, with the others holding read-only copies. The moment two systems can both change the same field and neither has been declared master, you do not have an integration problem. You have an ownership problem, and no connector fixes it.

This is also the organisational precondition every comparison page omits. If two functions cannot agree today who owns a field, buying a suite does not settle it. It relocates the argument into a configuration workshop with a day rate attached. Declaring the master costs nothing, can be done this week, and is the only part of the decision that survives whichever product you eventually buy.

The identifier precondition

Here is the differentiator that is available free, because no ranking page touches it. You cannot buy your way out of a shared-record problem until every system carries the same permanent code for the shared entity. A company that integrates before that spends the money twice. The sequence is fixed.

01 Declare the master

aOne system per record, written down
bNamed owner, not a team
cEveryone else read-only

02 Issue the code

aThe master issues it, permanently
bSite code, SKU, client code
cRequired on every record in every system
dIncluding the spreadsheets

03 Then build the integration

aMatch on the code, never on a name
bReject rows without one

Teams that run step three before step two end up matching records on company name or street address. That silently creates duplicates, which surface months later as two invoices for one site and a reporting total nobody can tie. If you have done an integration before and remember it technically working while the numbers stayed wrong, this was the reason. The same problem, in its migration form, is the subject of the data migration checklist.

Where the pain lives, and the counter-check

The shared-record test tells you whether breadth is needed. It does not tell you whether depth is needed, and the inverse claim deserves saying out loud: depth beats breadth whenever the pain lives inside one function’s own workflow. Breadth beats depth only where the handoff is.

Where does the pain show up when you describe it to someone outside the company?

Inside one function → buy depth

One team hurting, in the detail of its own work

Pick paths, route order, scheduling constraints, field protocol, warehouse put-away, campaign sequencing. Buy the specialist tool. The suite’s module in that exact area will be shallower, and no amount of breadth makes a shallow module deep.

Across the handoff → buy breadth

Functions disagreeing about the same fact

Sales says signed, operations says not scheduled, finance says not invoiced. Depth cannot help this. Any symptom you can phrase as “X says one thing, Y says another” is a shared-record symptom, whatever department raised it.

Multi-entity and multi-currency belong on the right-hand branch, although they are always listed as feature bullets. One client appearing as two records with two tax treatments is a record problem wearing a feature label.

The reversibility check, per tool

Lock-in is discussed as a property of suites and never of point solutions. That is backwards often enough to matter. Run one question on every tool before purchase, including the ones already installed: if we drop this in three years, what leaves with it?

A tool that owns a workflow but no master record is reversible through a bounded piece of work you can scope in advance: export, cancel, re-key the open items. A tool that has quietly become the only home of a record is as hard to leave as a suite while delivering none of a suite’s benefit, and nobody decided it should be. Hence the standing rule, worth writing into the system inventory: a tool may own a workflow freely. It may own a record only because you chose it as master on purpose.

Three years, with the lines vendors leave out

Point solutions win on licence and lose on the lines below it. Build this table for both candidate stacks over three years, and put a real salary against the reconciliation hours, because that is the line that decides it.

Line	Who usually prices it
Licence or subscription	On both quotes. The only line the comparison usually covers
Implementation and configuration	On the suite quote, rarely on the point-solution one
Data migration and clean-up	Under-quoted on both. Mostly your team’s hours
Integration build, per connector per direction	Quoted per connector, which halves the apparent count
Someone owning the failed-sync queue, by name	Nobody. A standing cost for as long as the stack exists
Mapping maintenance when either vendor ships a breaking upgrade	Nobody. Arrives on each vendor’s release schedule, which is not yours
Month-end reconciliation hours that remain	Nobody. An API does not make a tie-out disappear

The reconciliation work that survives an integration is the systematically unpriced item in this decision. Connectors get priced; the standing human cost of the failed-sync queue, the mapping maintenance and the month-end tie-out does not. Check it on the quote in front of you: count the lines that name a person and a recurring hour rather than a one-off build. If the only recurring line on the page is the subscription, the quote has priced the plumbing and left the operating cost with you, unstated.

“We’ll just integrate it”, four questions

Any no means the integration becomes your new manual process. Ask all four before signing, and ask them of the person who will own it afterwards rather than of the salesperson.

Can you name the master for this record? One system, written down.
Does the shared entity carry the same permanent identifier on both sides? Not a name, not an address.
Can a non-engineer see a failed sync and fix it, and who is that person? A queue nobody watches is a silent data loss with a dashboard.
Is the sync idempotent, so that re-running it after a failure creates no duplicates?

Vendors answer the first three in a demo and never the fourth, because the fourth is a property of their code rather than of their slide. Put it in the demo script instead: the scripted demo on your own data grades each step Native, Configured or Promised, and an idempotent sync is exactly the kind of claim that turns out to be Promised.

If several records fail, what goes in first

Every comparison page lands on “hybrid is the answer” and stops there, which is the point at which it becomes useless, because where to draw the line is the reader’s actual question. Here is the line.

Three or more failing records does not mean buying every module at once. Order the modules by where money and external commitments cross functions first: quote, order, invoice, cash. Leave the depth-heavy field operations on a specialist tool, wired to the new core with the identifier it now issues. Finance and the commercial record first, field execution last, because that is the order in which a wrong record costs cash rather than inconvenience. Going record by record is allowed, and it is the version of this project that tends to finish. The sequence inside each of those steps is the subject of the six stages, and the account structure that has to be settled before the first of them is in a chart of accounts you will not regret.

The numbers to refuse

This topic attracts figures with no traceable source, and they are quoted on both sides of the argument. Four worth refusing by name, with the reason.

“Seventy per cent of ERP implementations fail.” Attributed in circulation to more than one analyst house, and the two claims are not the same claim: the wording that gets quoted is “fail to meet their original business goals”, which is not failure. Vendor pages collapse the two. Run three questions against whichever version you are shown: which outcome was counted, over what population, and against whose stated goal. No version on offer answers all three. There is no counter-figure here either, because publishing a second unsourced percentage would be the same mistake, and the definition rather than the number is what is broken. What to use instead is in why ERP implementations fail, without the statistics.

Three-year total cost stated as a multiple of the licence fee. Repeated as “one study found”, with no study named, no sample and no date. The mechanism is real and worth planning for, as the table above does. The multiple is not a measurement.

Precise savings claims: hours recovered per week, a percentage fall in double entry, a payback period in months. These trace to single marketing pages, quoted to one decimal place, with no method, sample or baseline definition. The precision is the tell. Run your own rekeying log instead and you will have a number that is actually about your company.

Connector price bands presented as market rates. Figures for a nightly read-only connector or a real-time bidirectional one are one agency’s rate card in one market. Usable as “what one agency charges”, never as “what it costs”. Get two quotes priced per connector per direction and you have your own band.

Before any of thisIf the count comes out at zero or one, the honest next step is not a shortlist. Run the readiness check, twenty scored statements that say when the answer is no, and read outgrown QuickBooks, or outgrown your process, which separates a software problem from a process one.