In short: the ERP system that wins a selection is not the one with the longest feature list but the one that carries your processes with the least adaptation, and keeps doing so over time. The five critical capabilities not to miss are: fit with your processes, Turkish localisation and regulatory compliance, integration capability, the data model and data ownership, and the deployment model with release management. The order in which you assess them matters too: scope first, product second.
Most ERP selections start with a feature comparison table. The candidates' presentations are placed side by side, every row is marked «yes» or «no», and the system with the most «yes» marks moves ahead. The method is easy but misleading: the presence of a feature does not tell you how that feature will work in your own workflow. This article looks at the five capabilities that really decide an ERP selection, and at how to test each of them.
1. Fit with your processes: flows, not features
The first and most critical capability is how far the software covers your processes with its standard functionality. A selection made without seeing how each flow, from order to shipment and from purchasing to production, will run in the software comes back in the middle of the project as «that is not how we run this process».
The way to test it is to describe the processes in a shared language. BPMN, an international standard for modelling business processes, lets your team and the candidates look at the same flow. The analysis that shows whether each need is met by standard software capability is called Gap / Fit: a «fit» is a need met by standard functionality, a «gap» is a need that requires adaptation, development or a change to the process.
The question to ask is not «Does this feature exist?» but «How does our flow run in this software as standard, and where does it need adapting?»
2. Turkish localisation and regulatory compliance
For a manufacturer operating in Türkiye, the accounting and document flow of an ERP system has to follow local regulation. Electronic documents such as the e-Invoice, the e-Archive invoice and the e-Waybill are subject to the e-Document rules of the Turkish Revenue Administration (GIB), and statutory books to its e-Ledger application. The processing of personal data falls under the Turkish Personal Data Protection Law (KVKK, Law No. 6698).
The point to watch is whether localisation is delivered in the core of the software, in an add-on module or through a third-party connection. Each option creates a different maintenance and upgrade responsibility. Ask the candidates to show how these documents are produced end to end, and who updates them, and how, when the regulation changes.
3. Integration capability and open interfaces
An ERP system does not work alone. CRM, the manufacturing execution system (MES), planning, e-commerce and banking systems all exchange data with it. That makes documented, versioned application programming interfaces (APIs), protected by access rights, one of the most valuable capabilities an ERP system can have.
Ask three questions when you assess them: Are the interfaces openly documented? How is backward compatibility kept across upgrades? Who will be responsible for maintaining the integrations? Undocumented or project-specific connections are the items that create the most work at the first upgrade.
4. Data model, reporting and data ownership
The value of an ERP system is measured by how reliable its data is. The master data structure (materials, bills of materials, customers, suppliers), the traceability of transactions and an audit trail showing who changed what, and when, are critical capabilities.
An equally important question is data ownership: Will you be able to export your data in standard formats whenever you want? Will reporting need a separate tool? For a cloud solution, where the data is held and how it is handed back to you when the contract ends should also be settled during the selection.
5. Deployment model, release management and sustainability
Whether the software runs as a cloud subscription (SaaS), on your own servers or in a cloud environment reserved for you is not only a technical choice. The cloud computing definition of the US National Institute of Standards and Technology (NIST) is a useful reference for clarifying how responsibilities divide between these models.
The deployment model sets how often upgrades come, how customisations move to new releases and who carries the maintenance load. Ask the candidates: How does the move to a new release work, how are customisations affected by it, and for how long are older releases supported?
Feature list or process fit?
The same five headings give very different results under two different views:
| Heading | A feature-list assessment | A process-fit assessment |
|---|---|---|
| Process fit | «There is a production module.» | How does your own production flow run as standard, and where does it need adapting? |
| Localisation | «e-Invoice is supported.» | How are the documents produced end to end, and who updates them when the regulation changes? |
| Integration | «An API is available.» | Are the interfaces documented and versioned, and who maintains them? |
| Data | «There is a reporting module.» | Does the data model meet the need, and can you take your data out in a standard format? |
| Deployment and releases | «Cloud and on-premises options exist.» | How do customisations move to new releases, and who carries the maintenance load? |
The right order: scope first, product second
To assess these five capabilities meaningfully, you first need to know what you are assessing. A product comparison made while the scope is still unclear is like tailoring a suit without taking measurements.
In the MindDX approach this order is deliberate. Assess structures the current state and the need and validates the scope with evidence; its output is the Validated Scope, and the product decision comes after that evidence. The full Gap / Fit analysis, which shows whether each need is met by standard capability, is produced in Implement. The feature discussion then rests on evidence rather than assumptions.
If you are comparing offers, see our article on the five critical line items in an ERP quote.
Conclusion
What decides an ERP selection is not how much the software can do, but how little adaptation it needs to carry your business, and how sustainably it does so. Process fit, localisation, integration, data and release management are five faces of that one question.
Would you like to start your selection with evidence?
Sources
- Object Management Group — Business Process Model and Notation (BPMN) 2.0
- Turkish Revenue Administration (GIB) — e-Document portal (in Turkish)
- Turkish Revenue Administration (GIB) — e-Ledger portal (in Turkish)
- Personal Data Protection Authority (KVKK) — Personal Data Protection Law
- Law No. 6698 on the Protection of Personal Data — official text (in Turkish)
- NIST SP 800-145 — The NIST Definition of Cloud Computing