ERP Change Management: Getting Your Team to Actually Use It
A system nobody uses is the most expensive kind of failure, because the money is already spent. Adoption is not a training session at the end. It is a workstream with an owner, a plan and a number you check every week.
Most ERP projects that disappoint do not fail at go-live. They fail quietly over the following three months. The system is live, the licences are paid, and the sales team still keeps its own order sheet, the warehouse still counts stock on paper, and finance rebuilds the month-end report in Excel because nobody trusts the numbers on screen.
That is an adoption failure, and in the projects we are asked to rescue it is one of the most common patterns we see. The good news is that adoption can be planned and measured like any other workstream. This guide sets out how to run ERP change management in a UAE business, from the first workshop to the weeks after launch.
Key takeaways
- Adoption is a workstream with a named owner and a sign-off, not a training session the week before go-live.
- Train by role, on each person's real daily tasks, using your own migrated data rather than demo records.
- Switch the old spreadsheets and workarounds off on a set date, or they will outlive the new system.
- Measure usage every week after go-live: late transactions, documents created outside the system and reports still built in Excel.
- Write adoption into the implementation contract, with post-launch support and a usage check before the final payment.
Why adoption fails after go-live
People do not reject a new system because they dislike software. They reject it because the workaround they already have feels faster and safer, and nothing in the rollout proved otherwise. Three causes come up again and again.
The training was generic. A single session in a meeting room, run on demo data, covering every menu in the module. Two weeks later nobody remembers it, and the one person who does becomes the unofficial help desk.
The old tools never closed. If the shared order spreadsheet still works on the morning after go-live, it will still be in use six months later. Every parallel tool splits the data and makes the system look wrong, which gives people another reason not to use it.
Nobody owned it. The implementation partner configured the system and left. Inside the business, adoption belonged to everyone, which means it belonged to no one. We covered this pattern from the contract side in why ERP projects fail in the GCC. This guide is the practical plan that closes it.
Name an owner for every process before you configure anything
Change management starts in the blueprint phase, not at training. For each core process, such as sales orders, purchasing, stock, invoicing and month-end close, name one process owner from inside the business. This is the person who signs off how the process will run in the new system and who answers for whether their team uses it.
Process owners should be people the team already listens to, usually a senior user or a line manager, not the IT contact. Give them time in the project plan. If the sales manager is expected to own the order process while hitting a full target, adoption will lose every time.
Alongside the owners, pick one or two key users per department. They join the configuration workshops, test with real data and become the first point of help after launch. In a multi-branch business, that means at least one key user per branch, not one for the whole company.
Explain what changes for each role, in plain terms
A company-wide announcement that "we are moving to a new ERP" does nothing for a storekeeper in Al Quoz or a sales coordinator in Abu Dhabi. Each role needs to hear three things: what they will do differently, what they will stop doing, and what they get in return.
| Role | What changes | What they gain |
|---|---|---|
| Sales | Quotes and orders created in the system, not in a spreadsheet or on WhatsApp | Live stock and pricing before promising a customer, no chasing the warehouse |
| Warehouse | Every receipt, transfer and delivery scanned or entered at the time it happens | Fewer stock counts, fewer disputes about what was sent |
| Purchasing | Purchase orders raised against reorder levels in the system | No more urgent orders discovered from a sales complaint |
| Finance | Invoices, payments and VAT come from transactions already in the system | Month-end built from live data, not rebuilt from exports |
| Management | Decisions taken from system reports, not from a separate pack | One version of the numbers across every branch |
Most UAE teams are multinational and multilingual. Short role guides and screen recordings in the languages your team actually works in will do more than a long manual in English that nobody opens.
Train by role, on real tasks, with your own data
The most effective training we run looks less like a course and more like a rehearsal. Each role works through its actual daily tasks, start to finish, in a test copy of the system loaded with the business's own migrated customers, products and opening stock.
- Short sessions per role, not one long session per module. A warehouse user does not need to see the accounting menus.
- Real scenarios, such as a partial delivery, a customer return or a price change, because those are the moments people fall back to the old way.
- A one-page task card for each daily job, kept at the desk or on the phone.
- A second round after go-live, in the first and third weeks, when the real questions appear.
Training on your own data matters for a second reason. If the first time users see their customers and stock in the new system is the morning of go-live, any error in the migration lands on them, and trust is lost on day one. A clean, reconciled migration is part of adoption, which is why we treat it as its own workstream in our data migration checklist.
Switch the old way off on a fixed date
Every business has its workarounds: the shared order sheet, the stock notebook, the WhatsApp group where branches request transfers. Make a list of them during the blueprint phase and agree a date for each one to close. On that date the file is archived as read-only, and the process owner makes clear that a transaction that is not in the system did not happen.
This feels harsh, and it is the single step that most often decides whether adoption sticks. Results like the ones we can point to depend on it. At Al Eatemad Butchery, a multi-branch food retailer, stock is unified across the branches and order processing time fell 60 percent. A result like that is only possible when every branch processes its orders in the system, not around it. At Palaces Jewellery, every piece is serialised and traceable across showroom and workshop, which holds only if every movement is recorded at the time it happens.
Measure adoption every week after go-live
Do not ask the team whether they are using the system. Look. A short weekly check for the first two to three months will show where the old habits are surviving.
| Check | What it tells you |
|---|---|
| Transactions entered late, such as deliveries or invoices posted days after the event | The work is being done somewhere else first and typed in afterwards |
| Documents created outside the system, such as manual quotes or invoices | A workaround is still open |
| Reports still built in Excel for management | People do not trust the system's numbers, often a data or configuration issue |
| Help requests by user and by topic | Which role or process needs another training round |
| Logins by user | Who has quietly stopped using the system altogether |
Review the results with the process owners each week. When a gap appears, fix the cause, which might be a missing field, a slow screen or a step that makes no sense for a branch, and then retrain the people affected. Adoption problems are often configuration problems in disguise.
Write adoption into the contract
If adoption matters, it belongs in the proposal you sign. Ask your implementation partner to show, in writing, how they will deliver it:
- Role-based training on your migrated data, with the sessions and roles listed.
- A defined period of post-launch support on site or on call, not only a ticket queue.
- A usage review with your process owners after the first month, before the final milestone is paid.
- Named senior consultants on the rollout, not only on the sale.
A partner who is paid in full at go-live has no reason to care whether your team is still using the system in month three. Tie the last payment to a stable, adopted system and the incentives line up. If your project has already gone live and adoption has stalled, it is usually recoverable. Our guide to rescuing a failed ERP implementation sets out how to fix the workflows people bypass and retrain role by role.
Worried your team will not use the new system?
Talk to a senior consultant before go-live. We will look at your rollout plan, your training approach and the workarounds most likely to survive, and show you where adoption is at risk.
Book a discovery call →