ERP implementation that survives go-live
You bought the licences. Eighteen months later half the company is still running the business from spreadsheets.
What you get
- A process map of how the work is done today, before anything is configured
- A phased rollout where each phase is usable on its own
- Named owners for every module, so nobody waits for the consultant to come back
- A post-go-live period where we stay to fix what the plan could not predict
Eighteen months after go-live, half the company is still on spreadsheets
Finance closes the month on the ERP. Everybody else runs the business next to it. The stores keeper keeps a notebook because a goods receipt takes four screens and there is a truck waiting. Sales quotes from a price list in Excel because the one in the system is a version behind. The monthly pack is rebuilt by hand every month, because nobody in the room trusts a report that came out of the system without being checked against something else first.
None of that is a software fault. It is what happens when a system is configured against a process nobody wrote down. The scope came from a demonstration and a wish list, the users were trained on screens rather than on the work, and the consultant who knew the open items left on the day of go-live — which is the day the real questions start.
The cost is not the licences. It is that you are paying for a system and still paying people to do the work the system was bought to remove, and that every decision is made against a number somebody had to assemble by hand.
Who an ERP implementation in Dubai is actually for
This work fits companies whose operation has outgrown the way it is recorded: more than one legal entity, a free zone company and a mainland one, more than one currency, branches in more than one Gulf market, or a costing problem that generic software does not model — project costing, retention, variation orders, manufacturing that is engineer-to-order.
It fits a company that has already tried once. A failed or half-finished implementation is a normal starting point, and it is usually cheaper to correct than to restart.
It does not fit everyone. A twelve-person trading company on one entity, running accounting software that works, does not have an ERP problem. It has a process problem, and a bigger system will make it slower and more expensive. If that is what the diagnosis finds, that is what we will write, and there is nothing to buy at the end of it. If what you want is the lowest price per user licence, somebody will beat us on that. We are not competing there.
How the engagement runs, and why an independent implementer is not the vendor
We diagnose before we quote delivery. Two weeks inside the operation, mapping how the work is actually done, documenting every system in use including the spreadsheets nobody mentions in meetings, and interviewing the people doing the work rather than only the people who own the budget. The written diagnosis is yours to act on even if you never hire us, including taking it to another firm.
Then a target design: which system holds which truth, one named owner per domain, and what has to be true before go-live. Configuration before customisation. Custom code only where the business genuinely differs from every other business, which is a shorter list than any first workshop produces.
Delivery runs in phases you can stop after, and migration is rehearsed on real data before it is done for real. After cutover we stay, because the plan cannot predict everything and the weeks after go-live decide whether a system is adopted or abandoned.
A vendor's implementation team is measured on modules sold and on hitting a go-live date. We are measured on whether the business is still running on the system in year three. Those are different jobs, and they produce different scopes.
Why ERP projects fail, and it is rarely the software
Master data. Item codes that mean four different things, the same customer entered five times with five spellings, opening balances never agreed with the auditor. Nobody wants to own it, it is not interesting work, and it decides whether the system is believed.
A go-live date fixed before anyone knows what is being migrated. Training built around screens, so a user who has been shown where to click and not why has learned nothing that survives an exception. No named owner, so when two departments disagree about a number the disagreement becomes a new spreadsheet.
And in the UAE specifically: VAT treatment, corporate tax, e-invoicing as it comes into force, Arabic alongside English, and inter-company flows between a free zone entity and a mainland one. These are configuration decisions with legal consequences, and they are the ones a generic template gets wrong quietly.
What determines the cost
Scope, and we will not pretend otherwise on a website. What moves it: the number of legal entities, the number of processes that genuinely differ from standard, the state of the data being migrated, how many existing systems have to stay and be integrated, and how much custom code the operation really needs once the design is finished rather than when it is being wished for.
What we commit to is the order. A written diagnosis first, then a fixed scope at a fixed price before you commit to any delivery work. No open-ended engagement, and no phase that starts before the one before it is usable.
The largest cost in these projects never appears on an invoice. It is the second implementation, bought because the first one was scoped from a demonstration.
How the engagement runs
- 01
Diagnose
Two weeks inside your operation. We map how the work is actually done, where two systems disagree, and what each gap costs you in a month.
- 02
Architect
A target design tied to operating decisions: which system holds which truth, who owns it, and what has to be true before go-live.
- 03
Implement
Delivery in phases you can stop after. We train your team to run it, because a system that only we can operate is a system you do not own.
- 04
Govern
The part everyone skips. Ownership, review cadence and metrics, so the system does not quietly decay back into chaos.
Questions
What people ask before they start this work
How is an ERP implementation priced?
By scope, and the scope is written before the price. We run a diagnosis first, then quote a fixed scope at a fixed price for delivery. What moves the number is how many legal entities go live, how many processes genuinely differ from standard, the state of the data you are migrating, and how many existing systems have to be integrated rather than replaced. We do not price a requirements list we have not tested against your operation.
How long does an ERP implementation take?
Duration is set by three things we can see within the first two weeks: how many entities go live, how clean the master data is, and how fast your side can make decisions. A single-entity finance and inventory rollout is not the same project as five companies with manufacturing and project costing. We phase the work so something is usable early, rather than naming one date two years out and defending it.
Who owns the system after handover?
You do — the database, the configuration, anything written for you and the documentation. Handover is written for your team rather than for our next engagement, and we train named owners per module so nobody waits for a consultant to fly back. Support afterwards is a separate agreement you can end. A system only we can operate is a system you do not own, whatever the contract says.
Our current system works. Should we still replace it?
Probably not. Most of the pain blamed on an ERP is process and data rather than software, and replacing a working system is the most expensive way to fix a process. If the diagnosis finds your existing system is adequate and the problem sits around it, we write that down and there is no implementation to sell. We would rather lose the project than run one that should not exist.
Are you tied to one ERP vendor?
No. We have deep Odoo experience and it is often the right answer for mid-sized operations in the UAE and the GCC, but the diagnosis comes before the product. If a larger platform or the system you already own is the better fit, that is what the report says. A recommendation from a party that sells only one product is not a recommendation, and buyers here have learned to read it that way.
Can you handle Arabic, VAT and multi-company between free zone and mainland?
Yes, and they are design decisions rather than a switch flipped at the end. Arabic and English run side by side, VAT treatment is configured per entity and per transaction type, and inter-company flows between a free zone company and a mainland one are modelled before go-live rather than reconciled after it. Getting this wrong is quiet — the system keeps working and the returns stop matching the books.
What happens if we want to stop after the first phase?
You stop, and what is live stays usable. Every phase is scoped to stand on its own. A phase that only makes sense once the next three are finished is a phase designed to keep a consultant on site. You keep the configuration, the data, the documentation and the trained owners for everything delivered up to that point.
ERP Implementation
Start with a diagnosis
Tell us the symptom in one line. We will come back with what we would look at first and what it would take.
Monday to Friday, 9:00 AM – 6:00 PM (GST)
Prefer we call you?
Leave your WhatsApp number and we will reach out.