How Manufacturers Should Choose an ERP Vendor

A manufacturer in the Eastern Province recently spent four months evaluating ERP vendors. Demos, site visits, a 90-slide RFP response from a tier-one vendor. They picked the system with the best-looking warehouse module. Eight months into implementation, they discovered the system couldn't handle their multi-level bill of materials without a custom build that cost as much as the licence. Nobody had mapped the BOM structure before the first demo was booked.

This is not an unusual story. It is the usual story.

Why Most ERP Selections Go Wrong Before the Demo

The dominant failure mode in ERP selection isn't picking the wrong vendor. It's shopping before knowing what you need. Manufacturers arrive at vendor conversations with vague requirements — "better inventory visibility", "integrated finance" — and vendors fill the vacuum with polished demonstrations of their strongest features.

The result is a requirements list reverse-engineered from demos rather than built from operations. You end up optimising for what vendors are good at showing, not what your factory actually needs.

A structured selection process starts with requirements definition, then market research, then a long list, then RFI/RFP, then demonstrations, then reference checks — in that order.^[2] Most companies begin at step four. The first three steps are where fit is actually determined.

There's a second failure mode specific to the GCC: importing a selection framework designed for European or North American manufacturers and applying it without adjustment. The localisation requirements are different enough that this reliably produces a shortlist of systems that look right globally but fail operationally on day one.^[3]

The Four Questions to Answer Before You Talk to a Vendor

These aren't discovery questions for the vendor. They're internal questions your team must answer in writing before any external conversation begins.

1. Where are our process gaps, and which ones does software actually fix?

An ERP surfaces data and automates transactions. It does not fix a purchasing process where approvals happen over WhatsApp and land in three different people's personal phones. (If that sounds familiar, read The WhatsApp-to-ERP Gap Is Where GCC Businesses Leak Money before touching an ERP shortlist.) Map your current processes first. Note where the breakdowns are. Classify each: is this a process discipline problem, a data problem, or a systems problem? Only the third category is addressable by an ERP purchase.

2. What is the state of our data, and can it actually migrate?

Production, inventory, purchasing, and finance are all generating data — but if those signals don't connect cleanly, feeding them into a new ERP replicates the chaos at higher cost.^[1] Before vendor evaluation, audit your master data: item codes, supplier records, BOMs, customer records. Count the duplicates. Identify which fields are populated consistently. A data readiness score is a prerequisite for an honest implementation timeline. Systems that look fast to implement often assume clean data. Yours probably isn't.

3. What does our integration surface look like?

List every system the ERP must talk to: CNC machines, WMS, customs clearance portals, bank feeds, government portals (ZATCA, Mofa, port authority systems). Count the integrations. Note which ones have documented APIs and which ones are file-based or manual. This list becomes a technical filter that eliminates vendors before a demo is ever scheduled. It also prevents the classic post-go-live surprise of discovering that your Italian-made press has a proprietary data format nobody thought to mention.

4. What are our regional compliance requirements, and are they built in or bolted on?

This is where GCC-specific evaluation begins. The answer to this question is the subject of the next section.

How to Score ERP Candidates: A Practical Comparison Framework

Once internal questions are answered, vendor evaluation needs structure. A weighted scoring matrix outperforms a feature checklist every time.^[2] Here's a practical five-category framework:

| Category | Weight (suggested) | What to assess | |---|---|---| | Functional fit | 30% | Core manufacturing modules vs. your specific process map; gap analysis; workaround requirements | | Localisation depth | 25% | Arabic RTL interface, ZATCA compliance, WPS integration, Hijri calendar, local bank formats | | Integration capability | 20% | API-first vs. file-based; pre-built connectors to your stack; middleware requirements | | Vendor viability | 15% | Financial stability, GCC customer base, R&D investment, partner ecosystem in-region | | Implementation methodology | 10% | Timeline realism, resource requirements, reference clients in similar industries |

Score each vendor independently before demonstrations, then again after. The delta between pre-demo and post-demo scores tells you how much the vendor's presentation skill is influencing your judgement rather than actual fit. Require vendors to demonstrate with your data, not their sandbox data.^[2]

Reference checks should include direct questions about go-live challenges, not just successes. Ask specifically: "What took longer than the implementation timeline promised?" and "What did you have to customise that the vendor said was standard?"

What GCC and Saudi Manufacturers Need to Check That Others Don't

This is where a Western selection framework falls apart. The following are eliminators — not nice-to-haves — for any manufacturer operating in the GCC.^[3]

Arabic language support — at the interface level, not just document output. Saudi Arabia requires Arabic interfaces for many operational workflows. ZATCA e-invoicing mandates Arabic fields on tax invoices. A system that produces Arabic PDFs but runs an English-only back-office UI creates a permanent two-speed operation where half your workforce is navigating a system in their second language. Required features: RTL interface throughout, Arabic character support in all database fields, bilingual document generation, Arabic-language help and error messages.^[3]

ZATCA Phase 2 compliance — live, not roadmapped. Saudi manufacturers subject to e-invoicing integration (Fatoora) need a vendor who has cleared Phase 2 technical integration with ZATCA, not one who says it's "on the roadmap for Q3." Ask for the ZATCA-certified partner reference in Saudi Arabia. If they can't produce one, move on.

VAT configuration across multiple GCC jurisdictions. UAE runs 5% VAT with quarterly returns. Saudi runs 15% VAT with ZATCA clearance for B2B invoices. Kuwait, Qatar, Oman, and Bahrain each have distinct requirements.^[3] A manufacturer with entities in multiple GCC countries needs a system where each entity's tax treatment is configurable independently, not a global template with manual overrides.

WPS (Wage Protection System) integration. UAE and Saudi Arabia both mandate electronic salary transfer through bank-linked WPS. Your ERP's payroll module must generate WPS-compliant salary files. Many global ERPs support this through local add-ons — verify the add-on is current, locally supported, and not maintained by a single-person consultancy.

Hijri calendar and weekend configuration. The GCC business week runs Sunday through Thursday in most sectors, with Friday–Saturday as the weekend. Hijri calendar support matters for contract milestones, government submissions, and document dating.^[3] Systems that treat this as a display-only setting — rather than a transactional calendar — create downstream errors in aging reports, delivery schedules, and SLA calculations.

In-region support with Arabic-speaking coverage. A vendor with a Dubai or Riyadh office is not the same as a vendor with a technically capable, Arabic-speaking support team in-region. Ask specifically: what is the first-response SLA for P1 issues? Is support handled from the GCC or routed through a global helpdesk? During Ramadan, when operating hours compress and business cycles accelerate, a six-hour time-zone lag to a support centre in the Netherlands is operationally unacceptable.

For a deeper look at how ERP AI capabilities play into this regional picture, Odoo vs SAP: Which ERP's AI Features Actually Work for GCC Operations? covers the practical differences rather than the marketing claims.

Tarsyn's View: Start With the Audit, Not the Shortlist

We talk to GCC manufacturers almost every week who are mid-demo-cycle on an ERP. Most of them haven't mapped their processes. About half don't know the state of their master data. A significant number are evaluating systems that cannot pass the localisation checklist above without substantial custom development.

The ERP vendor selection process is not primarily a technology decision. It's a business readiness assessment that happens to end in a technology purchase. The vendors are not going to tell you to slow down — they have quotas. The implementation partners are not going to tell you your data is too dirty to migrate on time — they bill by the hour.

Our consistent advice: before you build a shortlist, run a structured process and data audit. Not as a box-ticking exercise, but as the document that generates your actual requirements. It tells you which modules matter, which integrations are critical, and — frankly — whether you're ready for an ERP at all or whether you need to fix seventeen spreadsheets and a WhatsApp approval chain first.

That audit is also the document that protects you in contract negotiations. When you can hand a vendor a specific requirements matrix with weighted criteria, you're negotiating from specificity rather than ambiguity. Ambiguity always benefits the vendor.

One more thing: AI capabilities are now a standard part of ERP sales pitches. Before you weight them heavily in your scoring matrix, read Is AI FOMO Pushing You Into SAP RISE Too Early? — it addresses exactly the dynamic where AI marketing accelerates an ERP decision that isn't ready to be made.

The best ERP for your manufacturing operation is the one that fits your mapped processes, clears your compliance requirements, and can be implemented with your actual data. That description is not derived from any vendor's feature list. It comes from knowing your own operation first.

Start there.

---

Mohammed Z is a co-founder at Tarsyn, an automation and AI studio based in Abu Dhabi and Khobar serving GCC operators.