The System Works. So Why Is Nobody Using It?
A familiar story: the project team declares the ERP go-live a success. Data is migrated, screens work, invoices are going out. Two months later the finance manager notices the accountants still keep spreadsheets alongside the system, the warehouse records movements on paper and keys them in at the end of the week, and the sales reps send orders over WhatsApp for someone else to enter. Technically the system runs. The business has not adopted it.
That is the gap between go-live and adoption. Go-live is a technical milestone. Adoption means people actually do their work through the system, trust its numbers and make decisions from them. It does not happen by itself. It takes deliberate work, which is what ERP change management is for.
This guide takes a practical view: why people resist, how to apply the ADKAR model to an ERP project stage by stage, what is specific to Saudi workplaces, and how to measure adoption with numbers rather than impressions.
Why People Resist a New ERP
Resistance is rarely stubbornness. It is a normal reaction to a change in how someone does their job every day. Knowing the source tells you what to fix:
- Job security: when a data entry clerk hears that the system will "automate processes", they hear that their job is at risk.
- Lost expertise: the accountant who knows every cell in a workbook built over ten years is suddenly a beginner.
- Uncomfortable transparency: the system logs who did what and when. Some staff see surveillance rather than a tool.
- A slower start: the first weeks are always slower. An invoice that took two minutes now takes ten until habits form.
- A failed previous attempt: if the company tried a system before and dropped it, people assume this one will go the same way and do not invest in learning it.
- No clear reason: if nobody explains why the company is changing, staff treat it as a management decision that has nothing to do with them.
Notice that almost none of these concern the quality of the software. A strong system can fail on adoption, and an average one can succeed when the change is managed well.
ADKAR Applied to an ERP Project
ADKAR was developed by Jeff Hiatt, founder of Prosci, and is one of the most widely used change models. Its strength is that it focuses on the individual: an organisation changes only when each person in it changes. The five letters are five stages, in order:
| Stage | The employee's question | What the business must provide |
|---|---|---|
| Awareness | Why are we changing? | A clear account of the current problem and its cost |
| Desire | What is in it for me? | A concrete benefit for each role |
| Knowledge | How do I use it? | Hands-on, role-based training |
| Ability | Can I actually do it? | Practice and close support in the first weeks |
| Reinforcement | Will this stick? | Measurement, follow-up and no way back to old tools |
The stages are sequential. Training someone (Knowledge) who is not yet convinced the change is needed (Awareness) or worth it to them (Desire) is wasted effort. Many projects jump straight to training and then wonder why nobody uses what they learned.
Awareness
Management has lived with the decision for months; most staff heard about it in an email. Build awareness with numbers from your own business: how many days the month-end close takes, how many invoices needed correcting last quarter, how often a customer ordered something the system said was in stock but was not. Link the change to external requirements where that is accurate, such as ZATCA e-invoicing or monthly wage files through Mudad. And have the general manager deliver the message in person, branch by branch.
Desire
Awareness explains why the company is changing. Desire explains why I should. The message differs by role. Accountants stop re-keying sales invoices and stop spending the first week of every month reconciling. Storekeepers see the current balance of every item without counting shelves. Sales reps see what is available before promising a delivery date. HR calculates salary, social insurance and the wage protection file from one set of data. Address job fears directly: if nobody is being let go, say so plainly, and explain how roles will shift, for example from data entry to data quality review.
Knowledge
Training is not a product demo. Train each role on its own tasks, not every module. Use the company's real items, customers and accounts in a test environment. Provide a one-page guide and a short video for each recurring task. Train in the language people work in; mixed teams often need both Arabic and English sessions.
Ability
Knowing how to raise a purchase order and doing it confidently under daily pressure are different things. Close that gap with practice and nearby support: a support team reachable throughout working hours in the first weeks, warning managers in advance that productivity will dip temporarily so they do not push teams back to the old way "just for now", and starting with simple transactions before adding complexity.
Reinforcement
The biggest post-launch risk is a quiet return to old tools. Close data entry in the legacy system after the validation period while keeping read access to history. Ask for management reports from the system itself, not from exported spreadsheets. Measure usage regularly and follow up with lagging departments. Recognise people and teams who have mastered the system and helped colleagues.
Build a Network of Change Champions
One of the most effective tactics is a champion, or super-user, in every department and branch: someone respected by colleagues, curious about technology and willing to help. Champions get deeper training earlier, help test the system before go-live, and become the first point of contact for their team.
It works because people ask a colleague more readily than they raise a ticket or ask a manager, and because champions understand how their department actually works. To make it work:
- choose champions for their influence, not because they are the least busy;
- take some of their normal workload off them for the first months, or their day job will win;
- meet them weekly to share problems and fixes, and feed what they hear back to the project team;
- as a rough guide, plan one champion per 15 to 20 users and at least one per branch.
What Is Different in Saudi Workplaces
Change principles are universal, but how they play out depends on the workplace. These are the factors we see most often in Saudi and Gulf companies:
| Factor | Effect on adoption | Response |
|---|---|---|
| Top-down decision making | Staff wait for a clear signal from leadership | Visible sponsorship, with the GM using the system personally |
| Multinational, multilingual teams | Uneven understanding of training and guides | Arabic and English materials and a bilingual interface |
| Relationship-based processes | Steps skipped because "we know this supplier" | Introduce controls gradually and explain why they exist |
| New Saudi hires under localisation plans | Learning the job and the system at once | Longer training path and pairing with a champion |
| Ramadan working hours | Fewer hours and a different rhythm | Avoid go-live in Ramadan or just before year-end |
| Preference for spoken communication | Long written manuals go unread | Short videos and frequent short sessions |
On Ramadan specifically, the Labor Law limits working hours for Muslim employees to six a day or 36 a week during the month, which alone makes it a poor time for go-live or intensive training. The Labor Law amendments in force since February 2025 also require employers to adopt training and qualification policies; a structured training programme on the new system can sit within that policy.
A Six-Month Change Plan
| Period | Main activities | Signal to move on |
|---|---|---|
| Two months before go-live | GM sessions with every department, stakeholder map, expected resistance by team, champions chosen | Every department has a champion; every manager can explain the reason for the change |
| One month before | Champion training, scenario testing with real data, short task guides prepared | Champions complete core tasks unaided |
| Final weeks before | Role-based user training; cut-off date for the old system announced | Most users have finished training for their role |
| First month live | Intensive support, short daily project stand-up, fast issue resolution | Repeat support requests falling week on week |
| Months two and three | Old system closed for entry, usage measured by department, gaps addressed | No parallel spreadsheets in core processes |
| Months four to six | Advanced training, report and process refinements, champion recognition | Management decisions are made from system reports |
For the wider project picture, see our guide to ERP implementation, and for smaller firms, the first 90 days with ERP.
Measuring Adoption With Numbers
"Staff are comfortable with the system" is not a measure. These indicators come straight out of the system:
- Active users: people who logged in and posted transactions this week, against licensed users.
- Share of transactions created in the system: how many sales orders were raised in the system directly, and how many were keyed in later from another source.
- Entry lag: the gap between when something happened and when it was recorded. A long lag means people still work outside the system.
- Support requests: volume should fall, and questions should shift from "how do I" to "could we improve".
- Shadow spreadsheets: every parallel file is a sign of missing trust.
- Month-end close time: a lagging indicator that reflects data quality and discipline.
Break every indicator down by department and branch; a company average hides the teams that are struggling. Our article on ERP implementation KPIs covers more measures.
Mistakes That Kill Adoption
- Big-bang launch without groundwork: every department and module at once multiplies problems at the same moment.
- Ignoring line managers: they are the strongest source of support or resistance. If they are not convinced, their teams drift back.
- Classroom-only training: watching screens without practice does not build ability.
- Keeping the old system as an open fallback: it tells everyone the change is optional.
- Defining success technically: "the system works" is not "people use it".
- Leaders who bypass the system: when the GM asks for an Excel summary instead of opening the report, everyone gets the message.
For other misconceptions that derail projects, see common ERP myths.
Illustrative Scenario: A Second Attempt
Hypothetical example: a food distributor with four branches and around 120 users tried an ERP three years ago; sales drifted back to spreadsheets and WhatsApp. On the second attempt management changed approach. The GM visited every branch with last month's figures: orders delivered short because recorded stock was wrong, and days spent closing the books. Two champions per branch, one from sales and one from the warehouse, tested the system six weeks before go-live. The rollout started with one branch and moved on only once it was stable. The share of orders created directly in the system was shown per branch in the weekly management meeting. The cut-off for the old channels was announced four weeks ahead and held.
The software was not the deciding factor. The difference was that the second attempt dealt with the causes of resistance before launch and measured usage instead of assuming it.
The Vendor's Part in Adoption
Change management is the customer's responsibility first, but the vendor shapes it through training quality, post-launch support and how well screens and reports fit the way the business works. With Tranquil, implementation includes certified training on-site or remote with role-based tracks and 30 days of post-training support, plus customisation of screens, reports and multi-level approvals so the system matches real procedures.
Frequently Asked Questions
What is the difference between implementing and adopting an ERP?
Implementation is configuring the system, migrating data and making it run. Adoption is people doing their daily work through it and trusting its data, with no parallel spreadsheets or after-the-fact entry.
What is the ADKAR model?
A change management model developed by Jeff Hiatt of Prosci. It describes five sequential stages each person goes through: awareness of the need, desire to take part, knowledge of how, ability to do it, and reinforcement to sustain it.
How should we handle an employee who refuses to use the system?
Find out why first; it is usually fear or difficulty. Offer extra training and pair them with their department's champion, and be clear about how their role will change. If refusal continues after genuine support, involve their manager, and never shame anyone publicly.
When should we switch off the old system?
Set and announce a cut-off date for data entry after a short parallel run to verify balances. Keep read-only access to history, but allow no new transactions in the old system.
How many change champions do we need?
Roughly one per 15 to 20 users, with at least one in every branch or major department. You can talk to the Tranquil team about a training plan that fits the size of your organisation.