An ERP Readiness Assessment Is Only Useful If It Can Tell You Not to Buy
· 9 min read · Faceela
An ERP readiness assessment is a structured check of whether a company is in a state where buying an ERP would help it. Not which system to buy — whether to start at all.
That definition sounds unremarkable until you notice how few assessments honour it. Almost every one you can fill in online is issued by somebody who sells the software, and it has a structural problem it cannot escape: there is no result it can return that ends the conversation. Score high and you are ready to proceed. Score low and you need help getting ready, which is also a service, also billable, also proceeding.
An instrument with no failing grade is not measuring readiness. It is measuring interest, and reporting it back to you in the vocabulary of a diagnosis.
The one test that separates the two
Before you spend twenty minutes on any readiness assessment, ask what its worst outcome says.
If the worst outcome is "you have some gaps — let's talk about a discovery phase", you are holding a qualification form. If the worst outcome is "do not start; here are the three things to fix, none of which we sell", you are holding a diagnostic.
Ours returns the second one, in as many words. The bottom band of the ERP readiness score is headed "Do not start. Buying now would make the current mess permanent, licensed and annual." We publish that because it is the only band that makes the other three mean anything. A scale whose lowest point is still a yes has no scale.
This is not a claim to unusual virtue. It is a consequence of not selling licences. A company that is not ready is a bad project for us too — it goes late, it goes over, and it ends with a system nobody defends. The incentive only bites when the assessment sits with somebody whose revenue does not begin at signature.
What readiness actually means, precisely
Readiness is not enthusiasm, and it is not a budget. It is a small number of specific, checkable conditions:
- The process is one process. Not documented, necessarily — but the same in practice across the people who run it.
- Every master data set has a named owner. A person who can refuse a record, not a department that can discuss one.
- Decisions have a route and a clock. Somebody can settle a cross-department disagreement, and the settling happens in a week rather than a quarter.
- The requirements came from observed work. From walking real transactions, not from a feature list or a template.
- The money covers the whole thing. Implementation, migration, training, internal staff time, contingency, and years two to five.
- Somebody owns the system after go-live. Named, agreed, with time protected in their week.
Every item on that list is fixable without buying anything, and every one of them is much harder to fix once a vendor is on site charging by the day. That asymmetry is the entire argument for assessing readiness before selection rather than during it.
Notice what is not on the list: the size of the company, the age of the current software, the industry, the number of users. Those change what you buy. They do not change whether you are ready.
The questionnaire
Here is the actual instrument, in full, so you can run it on paper if you would rather not fill in a form. Ten questions. Answer as things are, not as they are meant to be — a flattering answer produces a flattering score and no information.
| # | Question | What it is really testing |
|---|---|---|
| 1 | If you asked four people in the same department how a purchase gets approved, how many different answers would you get? | Whether one process exists, or several sharing a name |
| 2 | How much of your customer list would you load into a new system unchanged? | Whether the migration can be priced, or only guessed at |
| 3 | Who is accountable for the customer master — the record set, not the department? | Whether anyone can refuse a duplicate |
| 4 | How much of the executive sponsor's week is in the diary for this project, for the whole project? | Whether decisions have a standing route |
| 5 | What does the approved budget actually cover? | Whether the first real invoice will read as an overrun |
| 6 | Where did your requirements come from? | Whether the list can disqualify any vendor |
| 7 | Has this company tried this before, and was the reason it stalled written down? | What the organisation already believes about projects like this |
| 8 | When the software works differently from the way you do, what happens? | The size of the future customisation bill |
| 9 | When two departments want incompatible things, who decides, and does the decision hold? | Whether scope will be settled or accumulated |
| 10 | Six months after go-live, who owns the system? | Whether the business case will ever be measured |
Each question carries different weight, because the risks are not equal. Sponsorship carries the most, because it is the item whose absence disables the repair of every other item — if nobody can settle an argument, you cannot fix the data ownership problem either. Project history carries the least, because it is the only one that describes the past rather than the present.
The scored version does the arithmetic, returns one of four bands, and — this is the part worth having — attaches a specific flag to every answer that cost you points, saying what to do about that particular answer rather than about your score. Four minutes, no email required to see the result.
The four questions that do the most work
If you only have the appetite for a short version, run these four. In our experience they carry most of the signal.
Question 1, on the four answers. This is the question that predicts the sentence "the system does not work the way we work", said eight months after go-live. Four different answers is not a documentation gap; it is four processes sharing a vocabulary. The implementation will pick one of them — in a configuration workshop, by whoever spoke last — and the other three departments will discover their version lost. Deciding that yourself, in advance, costs a meeting. Deciding it during configuration costs the project's credibility.
Question 3, on who owns the customer master. The cheapest fix on the whole list and the one that changes the most. Moving several disagreeing sources into one database produces one database containing several disagreeing sources, now behind a single authoritative-looking front end. If the honest answer is "anyone can create records, nobody owns them", fix that this month, whatever else you decide. It is free, and data is where implementations actually die.
Question 4, on the sponsor's diary. "Supportive" is not a calendar entry. An ERP project generates several hundred small, irreversible decisions, and the ones that wait are what people later describe as the project running late. The distinction that matters is between an executive who says yes to the project and an executive who has a recurring slot they chair and will not move.
Question 9, on who says no. If the honest answer is "it goes back and forth until someone gives up or the deadline forces it", then scope will be settled by whoever is holding the keyboard in the week it becomes urgent. That scope comes back after go-live as rework, and rework is charged at a rate nobody negotiated.
What each result actually commits you to
A readiness score is only worth taking if the four possible answers lead to four genuinely different next actions. Ours do.
| Result | What it means | The next step it implies |
|---|---|---|
| Ready to start | Nothing structural is missing | Start with scope, not with a shortlist. Write requirements from observed work, script demos on your own data |
| Ready, with two or three things to close | The foundation holds | Set a date for closing the flagged items, earlier than the date you contact vendors |
| Not yet | The gaps are real and none need software | Three or four internal decisions: name data owners, agree who settles disputes, walk one real transaction per process |
| Do not start yet | Buying would formalise the mess | Write the one-paragraph problem statement. Name people, not departments. Then take it again |
The third and fourth results are the reason the instrument exists. "Not yet" is a few weeks of unglamorous internal work — and it is the same few weeks you would otherwise spend arguing with a consultant, at a much better hourly rate.
A point worth saying plainly about the bottom band: scoring there is not a judgement about the company. Fast-growing, well-run businesses land there routinely, usually because the process genuinely has not been written down yet — nobody had time, and growth was the right thing to spend the time on. The problem is only that ERP is the wrong instrument for that condition and an expensive one to discover it with.
Where readiness assessments go wrong in practice
Four failure modes, all common, none of them the questionnaire's fault.
It is filled in by one person. Usually the person who wants the project. Question 1 in particular cannot be answered by one person — that is what it is for. Ask four people separately and count.
It is filled in aspirationally. The answers describe the company as it will be after the improvements everyone agrees are needed. Those improvements have been agreed for some time. Answer for the company that existed last Tuesday.
It is run after the shortlist. By then the assessment cannot change anything: budget is committed, a date has been announced, and a low score reads as an obstacle to be managed rather than as information. Run it before the first vendor conversation, while "not yet" is still an available answer.
It is treated as a gate rather than a plan. The score is not the deliverable. The flagged items are. A company that scores in the second band and closes its three flagged items is in better shape than one that scored in the first band and did nothing, because the second one now has a list and an owner for each item.
After readiness
Passing the assessment settles one question and opens the next. What follows, in the order it usually arrives:
- The requirements themselves, written so they can disqualify somebody: how to write an ERP RFP that gets comparable answers.
- The selection, run so that you are choosing rather than being sold to: how to choose an ERP system in the UAE.
- The demos, scripted on your own data: the questions that make a demo informative.
- The money, including the years the proposal does not price: where the budget actually goes and the five-year total.
- The plan, with the dates that are real: how long an implementation actually takes in the UAE.
And if the project has already started and is not going well, readiness is still the right diagnostic — just applied retrospectively. Most stalled implementations stalled on an item from that list of six, and naming which one is the first step of any recovery worth attempting.
The short version
An ERP readiness assessment measures whether a company is in a state where buying an ERP would help. It is worth taking only if it is capable of saying no, and it is worth taking before the shortlist rather than after it, because that is the only window in which "not yet" is still an answer somebody can act on.
Six conditions decide it: one process, named data owners, decisions with a clock, requirements from observed work, a budget that covers the whole thing, and a named owner after go-live. All six are fixable without buying anything. All six get dramatically more expensive to fix once the meter is running.
Take the ten-question version. Four minutes, four possible results, and one of them tells you to stop.