ERP Implementation Lessons Nobody Tells You First

A trading company in Jebel Ali runs thirty-two product lines across three legal entities. Approvals travel via WhatsApp. Landed cost is calculated in a spreadsheet that only one person fully understands. Then the company selects an ERP, signs a contract, and discovers — three months and a significant sum into the project — that nobody has documented how the landed cost actually works. The consultant is waiting. The meter is running.

This is not an unusual story. It is the normal one.

Why Operations Experience Alone Won't Prepare You

Running a warehouse, managing a procurement team, or closing month-end books gives you deep knowledge of what your business does. It does not prepare you for the question an ERP project asks first: how does it do it, precisely, in a form a system can replicate?

Industry research shows that 50–75% of ERP projects exceed budget, miss timelines, or fail to deliver expected business value ^[2]. The pattern behind that number is consistent: leadership alignment never happens, process documentation does not exist before kickoff, and data migration complexity gets discovered late ^[2]. Software vendors are frequently blamed. The software is rarely the problem ^[1].

Operations professionals know their domain. What they often lack is the meta-skill of process articulation — describing a workflow at the level of precision a configuration decision requires. "We approve POs over AED 50,000 at director level" is a start. "We approve them unless it's a freight forwarder on our preferred list, in which case the operations manager can clear it, except during Ramadan when the director is reachable only by phone and we sometimes process them anyway and reconcile later" is the real process. An ERP needs the second version. Most pre-project conversations only surface the first.

The gap between operational fluency and process documentation is where most Gulf projects begin losing money before a single screen is configured.

What Functional Consultants Actually Do (and What They Leave to You)

A functional consultant is not a business analyst who will figure out your company for you. They are a translator: they take documented business logic and map it into the configuration options the ERP allows.

During implementation, a functional consultant will run discovery workshops, write functional specifications, validate that configuration matches requirements, and guide user acceptance testing. They will also flag when your requirements exceed standard configuration and require custom development — at which point cost and timelines expand.

What they will not do: make your process decisions. They cannot tell you whether a three-way match should happen at goods receipt or invoice posting. They cannot decide which cost centre a particular expense type should hit. They cannot resolve the disagreement between your finance director and your operations manager about how intercompany transactions should be recorded. These are business decisions. They sit on your side of the table, and arriving at workshops without them is the single fastest way to extend a project by months and run up implementation day rates on facilitated arguments rather than configuration work ^[3].

The businesses that move through implementation cleanly are the ones whose internal project champion walks in with a process map for every critical flow — not a perfect map, but a decided one.

The Five Phases Where Gulf Projects Most Often Stall

Every credible ERP methodology covers roughly the same ground: discovery and scoping, process design, system configuration, testing, and go-live with post-go-live stabilisation ^[2]. Gulf projects tend to stall at predictable points within that sequence.

1. Discovery — Scope creep starts here. Stakeholders hear "we can configure almost anything" and interpret it as "we can have everything we currently do plus everything we wished we had." A disciplined scoping exercise — what is in, what is out, what is a phase two — rarely happens without someone forcing it.

2. Data migration — This is where undocumented tribal knowledge surfaces. Customer master data with seventeen variations of the same legal entity name. Item codes that were never standardised after a 2019 acquisition. Chart of accounts that no longer maps to how the business actually operates. Cleaning this data takes time that was not budgeted because nobody audited it before the project started ^[2].

3. Integration — Gulf businesses frequently run third-party logistics, customs clearance platforms, and local bank portals that have no standard ERP connector. Each integration is a small project within the project. They accumulate.

4. User acceptance testing (UAT) — UAT requires users to test against real scenarios using real data. When users are also running the business day-to-day — as is common in lean Gulf operations teams — UAT gets compressed, signed off superficially, and the issues surface on go-live day instead.

5. Go-live and stabilisation — The first Ramadan or quarter-end after go-live is the real test. Freight cutoff dates, volume spikes, and approval workflows that nobody tested under load all reveal themselves here. Teams that budgeted for post-go-live hypercare survive it. Teams that assumed the project ended at go-live find themselves in an informal second project.

Odoo vs SAP vs Dynamics: How Implementation Complexity Differs in Practice

The three platforms Gulf buyers most commonly evaluate differ less in feature lists than in the type of implementation work they demand.

Odoo is modular and relatively fast to deploy for a business with clear, documented processes. That last clause is the trap. Odoo's flexibility means ambiguity becomes technical debt immediately — modules get activated, customisations get built, and by month four you have a system configured around your current chaos rather than a cleaned-up version of your operations. How you layer AI decision support onto Odoo later compounds this: a messy data model makes intelligent automation unreliable. Odoo rewards businesses that do their process homework before touching the system.

SAP S/4HANA has a more rigid data model, which is simultaneously its biggest constraint and its biggest discipline enforcer. You cannot easily configure around a bad process decision — the system pushes back. That rigidity requires heavier upfront change management and longer discovery phases. For Gulf businesses considering the S/4HANA migration question specifically, the SAP 2027 deadline creates pressure to move, but pressure is a poor substitute for readiness. For AI-capability comparisons between platforms, Odoo vs SAP on AI features for GCC operations covers the practical landscape.

Dynamics 365 sits between the two in implementation complexity. Its Power Platform integrations are genuinely useful for Gulf businesses that need to connect legacy systems or build approval workflows. The hidden cost is licensing and environment architecture — multi-entity, multi-currency setups in the Gulf frequently hit complexity that the sales demo did not show. The WMS integration guide for Business Central is one concrete example of where this gap shows up in warehouse operations.

For manufacturing buyers specifically, how to choose an ERP vendor for manufacturing goes deeper on the selection criteria that actually matter.

What Vendor Sales Decks Don't Cover: The Pre-Implementation Checklist

Most vendor presentations show a clean implementation roadmap. What they omit is the internal work that has to happen before that roadmap starts.

Before selecting a platform — let alone signing a contract — a Gulf business should have completed:

1. A process inventory: every core operational flow documented at the level of "who does what, under what conditions, with what exceptions." Not the idealised version. The real one, including the WhatsApp approvals and the manual workarounds.

2. A data audit: customer master, supplier master, item master, and chart of accounts reviewed for duplicates, gaps, and misalignments. This audit typically takes longer than expected and reveals more problems than anyone wants to find — which is exactly why it needs to happen before the project clock starts.

3. An integration map: every system the ERP will need to talk to, with an honest assessment of whether a standard connector exists or custom work is required.

4. A change-readiness assessment: who in the organisation will resist, who will champion, and whether the internal project lead has the authority and time to run the project properly. A functional consultant cannot compensate for absent internal ownership ^[1].

5. A scope boundary decision: what the first phase must do, and what it explicitly will not do. Phase two is only achievable if phase one ships.

The WhatsApp-to-ERP gap is a useful lens here — Gulf businesses that have normalised chat-based approvals and decisions have more undocumented process than they realise, and it surfaces during implementation at the worst possible moment.

Tarsyn's View: Start with Process Documentation, Not Software Selection

The most common mistake we see Gulf buyers make is sequencing the decision wrong: they select the software, then try to fit their operations into it. The sales process encourages this. Vendor demos are compelling. Reference customers sound convincing. Procurement timelines create urgency.

But the software choice matters less than the process clarity you bring to it. A business that has documented its workflows, cleaned its data, and decided its edge cases will implement any of the three major platforms successfully. A business that has done none of that will struggle with all of them — and will spend implementation day rates discovering decisions they could have made in an internal workshop for a fraction of the cost ^[3].

We are direct about this with clients: the right first investment is usually a structured process and readiness audit, not a software selection exercise. That audit tells you what you are genuinely asking a system to do, surfaces the gaps that will cause project pain, and gives any implementation partner a foundation to work from rather than a blank page to fill in at your expense.

If you are at the beginning of this journey, the Tarsyn Audit is designed precisely for this: an honest assessment of operational readiness before any ERP or automation investment. We charge the same whether the outcome is "go ahead" or "not yet." The value is in knowing which one it is before you sign anything.

For businesses also thinking about AI capability on top of their ERP, the ERP AI readiness audit covers the additional layer of readiness that AI features require — and why a poorly implemented ERP makes AI additions worse, not better.

Process documentation is not glamorous. It does not appear in vendor demos. But it is the only work that determines whether your ERP runs your business or runs alongside it, politely ignored.