The formal ERP request for proposal is one of the most expensive rituals in enterprise procurement, and it is remarkably bad at its job. A requirements matrix runs to several hundred lines. Vendors answer "fully supported" to almost all of them, because the answer is technically defensible for any product with a configuration layer and a development toolkit. Weighted scoring produces a shortlist separated by two percent. And then the decision gets made on the demonstration, the reference calls and the relationship anyway. The alternative that a growing number of organisations use instead is simpler and unquestionably more informative: write your own real scenarios, bring your own real data, and make each vendor show you the transaction being completed in front of you.
Why requirement matrices fail
The failure is structural, not a matter of writing better questions. Requirements written by a committee describe the current system, not the business need. "Must support three-level approval hierarchy with delegation by value band" is a description of a configuration someone built in 2011, and enshrining it as a requirement selects for whichever product most closely resembles what you already have — including the parts that were mistakes. Binary answers destroy information. There is an enormous difference between native functionality, functionality available through configuration, functionality requiring a partner add-on, and functionality achievable with custom development. All four are "yes" on a scored matrix, and the distinction between them is most of what determines your implementation cost and your upgrade pain. Scoring creates false precision. Assigning weights to two hundred requirements produces a number to three decimal places out of judgements that were guesses. Worse, it moves the decision away from the people who will live with the system and toward whoever controls the spreadsheet. And the process selects for sales capability. Vendors with large bid teams answer formal documents better than vendors with better products. Smaller or more specialised vendors sometimes decline to bid at all, which quietly removes options that might have fitted best.
What scenario-based selection looks like
The method is straightforward and the discipline is in the preparation. Write five to eight real end-to-end scenarios, chosen for difficulty rather than for coverage. The intercompany transaction across two entities and two currencies. The project billed partly on milestones and partly on time. The return of a serialised item that was sold with a discount and is now out of warranty. The month-end close sequence with the eliminations you actually perform. The payroll run with the statutory deductions and the end-of-service accrual. Ordinary transactions tell you nothing; every product handles those. Provide a data extract in advance — real master data, anonymised where necessary. Vendors demonstrating on their own clean demonstration dataset are showing you a product that does not exist in your environment. Your data reveals the transliteration duplicates, the inconsistent units of measure, the customers with six delivery addresses and the chart of accounts nobody has rationalised since 2009. Run the session with the people who do the work, not only with managers and IT. The accounts payable supervisor will ask the question that determines whether the system is usable. Require the vendor to show the configuration, not just the outcome. "How did you make that happen?" is the question that separates native capability from a screen someone built the night before. Record what could not be done. Every scenario will produce two or three points where the answer is a workaround, an add-on or a development item. That list — not the score — is your comparison, and it is also the first draft of your implementation risk register. The process takes less calendar time than an RFP cycle, involves fewer people for fewer hours, and produces a decision the organisation can explain in a sentence.
| Answer behind the yes | Evidence to retain |
|---|---|
| Native capability | The transaction run in the product. |
| Configuration | The configuration used to complete the scenario. |
| Partner module | The dependency and its support owner. |
| Custom development | The gap, proposed build and upgrade implications. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for ERP Selection Facilitation
- Write scenarios, not requirements. Five to eight complete transactions chosen because they are hard, ambiguous or cross-entity. Difficulty is the whole point.
- Send your own data in advance and insist it is used. A demonstration on vendor sample data tells you about the vendor's sample data.
- Put operators in the room. The people who will process the transactions find the problems that managers and consultants do not.
- Ask how, not whether. Native, configured, partner module or custom development — four very different answers that a scored matrix records identically.
- Keep a running list of gaps and workarounds per vendor. This is the real output of the process and becomes your implementation risk register.
- Evaluate the implementation team you will actually get, by name. The named consultants on your project matter more than the logo on the proposal, and this is where most selection processes are careless.
- Check references on the parts that resemble you. Same industry, same entity structure, same country mix, same size. A reference from a different shape of business is decoration.
- Settle commercial terms before preference is public. Data extraction rights, price escalation, sandbox and integration charges, and the consequences of a change of control. Leverage disappears the moment the vendor knows they have won.
The Regional Dimension
ERP selection in the Gulf carries requirements that an off-the-shelf evaluation template will not surface, and they should be written into the scenarios rather than into a requirements annex. Localisation is the decisive test. A scenario set for a regional business should include a Saudi e-invoicing transaction that must be cleared with the authority on the regulator's specification, a UAE VAT return with the treatment of designated-zone and out-of-scope supplies, a corporate tax provision, a payroll run producing a wage protection submission file, and an end-of-service gratuity calculation on a terminated employee with a mid-year salary change. These are not edge cases; they are Tuesday. And the distinction that matters is who owns the localisation: the vendor, a regional partner, or a small local developer. A partner-owned localisation is a dependency on that partner's survival and on their speed when a regulator changes a format with a short notice period — which happens. The entity structure is the second test. Regional groups typically run mainland companies, free-zone entities, a Saudi subsidiary and sometimes an offshore holding company, each with its own licence, statutory reporting and functional currency. The scenario that separates products is the intercompany transaction with elimination and multi-currency revaluation across those entities, followed by a consolidated close. Many mid-market products present well until this point. Bilingual operation is the third. Arabic invoices and statutory documents where required, Arabic and English name fields on the same master record, and search that works across both. Inconsistent transliteration is the leading cause of duplicate customer and supplier records in the region, which is precisely why the demonstration should use your own data rather than a clean set. One commercial note specific to the market: the implementation partner ecosystem is concentrated, the same firm frequently supplies the licence, the implementation and the ongoing support, and staff turnover on regional projects is high. Ask who owns the configuration documentation, what transfers if you change partner, and whether the named consultants are employed by the partner or contracted for the duration of your project.
The objection worth taking seriously
The strongest defence of the formal RFP is that it exists to protect the organisation from its own decision-makers, and that is a real function. A documented, scored, auditable process demonstrates that the selection was fair. For public sector bodies, government-linked entities and organisations with procurement policies requiring competitive tender, this is not optional — the process is a governance control, and a scenario-based evaluation that concludes "we all preferred the second one" will not satisfy an auditor or a tender board. Across much of the Gulf, government and government-linked procurement carries exactly these requirements. There is also a genuine risk in scenario-based selection: it can be captured by whoever is most persuasive in the room, and it privileges demonstration polish over durable qualities like financial stability, security posture and product roadmap, which a structured questionnaire does surface. The workable answer is a hybrid, and it is what most sophisticated buyers now do. Keep the formal document short and restricted to things that genuinely have binary answers: corporate and financial standing, security certifications, data residency, localisation ownership, reference customers, commercial terms. Move functional evaluation entirely into scenarios, and score the scenarios openly with the gap list as the evidence. That satisfies the governance requirement without pretending that a two-hundred-line matrix told you anything about fit.
Common Questions
How many vendors should reach the scenario stage?
Three is usually right, four at most. Scenario sessions are demanding for both sides, and a longer list means shallower evaluation. Use a short qualification step on hard facts — localisation, entity structure, industry references, residency — to get there.
What if vendors refuse to use our data?
Treat the refusal as information. Reluctance usually means the product handles your data shape poorly, or the local team lacks the skill to configure it quickly. Where a full extract is impractical, a representative subset of the messiest master data is enough.
Who should facilitate the process?
Someone who does not sell the software or the implementation, and who understands the process being replaced well enough to design the scenarios. Independence matters most in writing the scenarios, because whoever writes them substantially determines the outcome.
Should AI capability be part of the evaluation?
Yes, but tested rather than discussed. Put it in a scenario: have the system extract an invoice from a scanned Arabic and English PDF, propose the coding, and show the confidence level and the audit record when a human overrides it. That reveals far more than a roadmap slide. The substantive questions are where inference runs relative to your residency obligations, whether your transactional data trains anything, whether the features are included or separately priced, and what evidence exists when an automated suggestion turns out to be wrong. Also worth remembering: AI performance in these products is largely determined by master data quality, which is another argument for demonstrating on your data rather than the vendor's.
ERP Selection Facilitation — a two-hundred-line requirements matrix tells you which vendor writes proposals best; your own hardest transaction, run on your own data, tells you which product fits.