Guide

How to buy ERP without becoming a statistic

Most ERP buying advice is about choosing a product. The evidence says the product is the cause of failure roughly four percent of the time — so this guide is mostly about the other ninety-six: the decisions you settle before you shortlist, and the questions that actually separate vendors.

Get a second opinion

Send your requirements or a vendor quote. We will tell you plainly where we think the selection is going wrong.

1 / 3
Written from rescue engagementsVendor-neutralIncludes when to buy nothing

Before you look

Four decisions, settled and written down.

If these are unresolved when configuration starts, the project will produce work that has to be redone. This is the largest single cause of failure and it happens before a vendor is even chosen.

Chart of accounts

Fewer accounts than you have now, with dimensions doing the work sub-accounts used to. Every report you will ever run inherits this, and changing it after go-live means restating history.

Entity and dimension model

What is an entity, a department, a location, a class, a project. Most struggling implementations encoded three of these into one field because nobody chose.

Approval matrix

Who approves what, at what threshold, with what delegation when they are away. Vague here produces a workflow everyone routes around within a quarter.

Close calendar

What happens on which day, who owns each task, what the sign-off asserts. A close designed during selection runs; one improvised afterwards does not.

The test for whether they are settled

Someone with authority can state each one in a sentence, and nobody in the room disagrees. "We will decide that during testing" means it is not settled, and nothing that shapes the data model can be decided during testing.

Where time goes

Buyers under-invest in three phases.

Requirements, scenario demos, and references. Each one is cheap relative to implementation and each one is routinely compressed to make a date.

typical elapsed weeks · highlighted phases are where buyers under-investRealising you need to look · usually 6–18 months of tolerating itBuilding requirements3w · the phase that determines everythingShortlisting2w · three products, not tenDemos & scenarios4w · your data, your workflows, or it proves nothingReferences & diligence2w · two customers who left, not just two who stayedNegotiation3w · licence and implementation, togetherImplementation20w · where the decision is actually tested

Eight questions that separate vendors

Feature checklists do not discriminate — every product in this category will tick almost every box, and the ones they cannot tick they will roadmap. These eight are harder to answer well and the answers vary enormously.

  1. Show me a month-end close in this system, start to signed, on data shaped like ours.
  2. What does the implementation cost, and is that number from you or from a partner?
  3. Which two customers most like us have left in the last two years, and may we speak to one?
  4. What happens to our customisations at your next major version upgrade?
  5. What is in cost of revenue versus operating expense in your standard chart, and why?
  6. Can our auditor get a read-only role with drill-down to source documents?
  7. What is your published uptime, and where is the status history?
  8. If we leave in three years, what exactly do we get, in what format?

Why the reference question is phrased that way

Every vendor has three delighted customers ready to take your call. Asking for customers who left is a different question, and the response tells you more than the reference would. A vendor who names two and offers an introduction is confident. One who says nobody has left is either very new or not answering.

Ask for a reference who left. The answer to that question is more informative than the call you would have had.

Demo on your data or do not demo

A scripted demo proves the software works on the vendor’s data, which was never in doubt. Send a real chart of accounts, a month of real transactions, and three workflows that are awkward in your current system. Ask them to run those, live.

What you are testing is not whether the product can do it — it usually can — but how much configuration or customisation it takes, and whether the person demoing understands accounting or only understands the software. That second one predicts implementation quality better than anything else available to you at this stage.

Negotiate licence and implementation together

The most common and most expensive mistake in this process is signing the licence and then scoping the implementation. Once the software contract is signed, every ounce of leverage you had is gone, and implementation is where the larger and less predictable number lives.

Negotiate both, from both parties, before either is signed. Get the implementation scope in writing with a fixed price or a hard cap, get the assumptions listed, and get the change-order rate agreed in advance. A partner unwilling to fix a price has told you their scope is not settled, which is information.

Two more things worth insisting on: a defined exit — what you get, in what format, if you leave in three years — and a named implementation lead who will still be there at go-live, written into the statement of work.

When the right answer is to buy nothing

A meaningful share of companies that start an ERP search should not finish it. If your close works, you have one entity, and the specific pain is a reporting gap or manual AP, those are solvable without replacing your ledger and for a fraction of the cost and risk.

The honest test: write down the three things that would be different a year after go-live. If all three are reports, you have a reporting problem. If they are all about manual work, you have an automation problem. Neither requires a new general ledger, and both are cheaper to fix directly.

Our interest, disclosed

We sell an ERP platform and implementation services, so this guide is not disinterested. It is written from rescue engagements rather than from marketing, and where our advice would cost us a sale — buy nothing, keep your current system, take a reference from a customer who left — we have said so anyway.

Questions

Common follow-ups.

How long should a selection take?
Eleven to fourteen weeks from starting requirements to a signed contract is healthy for the mid-market. Faster usually means requirements were skipped, which shows up in month four of implementation rather than during selection.
Do we need a consultant to run the selection?
Not usually below $50M if you have a controller who can own it. Above that, or with multiple entities and a complex structure, an independent advisor is worth it — but check they take no vendor commissions, because most do.
Should we issue an RFP?
For most mid-market buyers, no. A well-written requirements document plus scenario demos on your own data gets better information faster. RFPs mostly reward vendors who are good at answering RFPs.
How many products should we shortlist?
Three. Two is not a comparison and five is a research project that will stall. The selection tool is built to shorten a long list to three.
What if we get it wrong?
Most bad outcomes are recoverable and are about the implementation rather than the product — roughly four in five stalled projects we assess can be finished on the system already bought. Switching vendors without diagnosing the cause tends to reproduce it.

Get a second opinion before you sign.

Send your shortlist, requirements, or a vendor quote. We will tell you plainly what we would do differently.