Every enterprise resource planning vendor now demonstrates the same capabilities. Natural language query over the ledger, drafted journal entries, invoice matching, forecast generation, an assistant in the corner of every screen. Sit through four vendor presentations in a week and the demonstrations become interchangeable, which is a genuine problem for a selection committee whose scoring model was built around feature comparison. Feature parity does not mean the systems are equivalent. It means the differences have moved somewhere the demonstration cannot show you.
When every vendor can show you the same demonstration, the scorecard stops measuring anything. The differences that remain are in the data model, the extensibility and the partner — none of which appear in a scripted session
Here is what an enterprise resource planning selection should actually evaluate now that the feature column has collapsed.
Where the real differences sit
The data model. Assistant quality is downstream of structure. A system with a coherent, well-normalised model and consistent master data produces good answers; one with thirty years of accreted tables and three competing customer records produces confident nonsense. This is the single largest determinant of whether the capability works for you, and it is invisible in a demonstration because the demonstration runs on clean data. Extensibility and the boundary of configuration. Every organisation does something non-standard. What matters is whether the non-standard part can be built in a supported way that survives upgrades, and whether the assistant capability extends to it or stops at the standard objects. The partner. Still the strongest predictor of implementation outcome, and now more so. Assistant features shift the work from configuration to data preparation and process redesign, which is a different skill set from the one most implementation teams have. The upgrade and change cadence. Model features change frequently and without release notes at some vendors. Ask how changes are communicated and whether you can defer them.
How to test rather than watch
Run the demonstration on your own data. Not a sanitised extract — a real one, with the duplicate suppliers and the inconsistent cost centres and the three entities that code things differently. Vendors resist this and the resistance is itself informative. Then ask three questions whose answers cannot be scripted. Where does inference happen. What happens when the output is wrong. Which of these features were generally available six months ago and which are roadmap items shown in a controlled environment.
| Area | Evidence to request |
|---|---|
| Data model | Known expected answers on representative imperfect records. |
| Extensibility | A supported test of the non-standard process and its upgrade path. |
| Partner | Named delivery staff and comparable references. |
| Change and availability | Release status, inference location and change controls. |
| Regional output | Actual required filings and Arabic/RTL output tests. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What to stop scoring
Feature checklists in the artificial intelligence category, because every vendor scores full marks and the column contributes nothing. Replace it with a weighted assessment of data model fit, extensibility and partner capability, and accept that those are harder to score and more predictive.
Practical Guidance for ERP Selection Consultation
- Run the demonstration on your own messy data, not the vendor's.
- Score data model fit above feature coverage.
- Assess the partner's data and process skills, not just product certifications.
- Ask which features are generally available today.
- Test extensibility on your one genuinely non-standard process.
- Establish the change cadence and whether you can defer.
- Drop the artificial intelligence feature column from the scorecard.
- Weight total cost over five years, including the data work.
The Regional Angle
The first factor that should carry more weight in a Gulf selection than anywhere else is statutory coverage, and it is precisely where the feature-parity story breaks down. Saudi e-invoicing integration, Emirati corporate tax and value added tax treatment, wage protection filing, end-of-service calculation and free zone entity structures are handled properly by a narrow set of products and approximately by the rest. No assistant capability compensates for a system that cannot produce a compliant filing, and this is the criterion most likely to eliminate vendors on substance rather than preference. The second concerns partner capacity, which in this market is the binding constraint more often than product choice. The regional implementation market is thin at the senior end, the same small number of experienced consultants circulate between firms, and a strong product delivered by a weak team produces a worse outcome than the reverse. Ask for the specific individuals, not the firm's credentials, and put key personnel commitments in the contract — because the partner named in the proposal and the team that arrives in month three are frequently different populations. The third is about Arabic and it cuts both ways. Regional organisations need Arabic interfaces, Arabic document handling and often Arabic reporting for statutory purposes, and vendor claims here are uneven — an English-first product with an Arabic translation layer behaves differently from one built bilingually, particularly in printed documents and right-to-left layouts. Test the actual outputs you must produce, in Arabic, during the evaluation rather than accepting a language support checkbox.
The objection worth taking seriously
The strongest objection is that this advice makes selection unmanageable. Feature scorecards exist because a committee of people with different priorities needs a defensible, comparable basis for a large decision, and replacing them with qualitative judgements about data model fit and partner quality produces a process that cannot be audited, cannot be explained to a board and is far more vulnerable to the preference of whoever is loudest. Checklists are crude, but they are crude in a way that is transparent. That is a legitimate concern about governance and the risk of an unfalsifiable selection is real. The response is not to abandon structure but to score the right things. Data model fit can be tested concretely — run your own data through and count the answers that are wrong. Partner capability can be assessed by naming individuals and checking references on comparable projects. Extensibility can be tested by building one thing. Those are all more objective than a feature column in which every vendor scores identically and which therefore discriminates between nothing. Keep the scorecard, keep the audit trail, and replace the dimensions that have stopped carrying information with ones that have not.
Common Questions
Does the assistant capability matter at all in selection?
As a qualifier, not a differentiator. Everyone has it. What differs is whether it works on your data, which is a data model question.
Should we insist on testing with our own data?
Yes. It is the single most informative hour in the entire process, and a vendor that will not accommodate it is telling you why.
How much weight should the partner carry?
More than the product for most mid-market selections. Implementation quality has always dominated outcomes and the shift toward data work has widened the gap.
What should we expect over the next twelve months?
Expect the demonstrations to converge further as agent capabilities become standard. Expect vendors to compete on data model coherence once feature marketing exhausts itself. Expect partner capacity to tighten as migration deadlines elsewhere absorb consultants. And expect selections decided on statutory coverage and partner strength rather than on capability claims.
ERP Selection Consultation — we replace the column where every vendor scores full marks with the tests that actually separate them.