In this article
- Challenge: The stakeholder missing from the project room
- Case illustration: The receiving desk that broke stock visibility
- Approach: Make frontline staff operational co-designers
- 1. Select users by transaction volume and operational risk
- 2. Run fit-to-standard workshops around real work
- 3. Put frontline users into user acceptance testing
- 4. Keep super-users on the floor after go-live
- Results: Measure adoption through operational indicators
- Worked example: A small team can still create a large control gap
- Quote
- Frequently Asked Questions
- What is ERP user adoption?
- Which frontline users should join an ERP implementation?
- How long should we measure adoption after go-live?
- Should a business delay go-live if users are not ready?
A receiving clerk in Bulawayo has a supplier truck waiting at the loading bay, a network interruption, and a new ERP rule that says stock cannot move until the receipt is posted. If that clerk was not involved in designing the exception process, the clerk will use a notebook, update the system later, and create a stock variance that head office sees only after replenishment has already been ordered.
That is where ERP user adoption becomes an operational priority, not simply a training metric. For Zimbabwean businesses rolling out Odoo ERP across branches, warehouses and field teams, involving the people who post receipts, approve purchases and count stock helps create reliable visibility, faster decisions and smoother operations.
Challenge: The stakeholder missing from the project room
ERP projects usually have an executive sponsor, a project manager, department heads and selected super-users. The missing group is often the people who perform the highest-volume transactions: warehouse clerks, cashiers, buyers, production supervisors and field technicians.
This is a costly omission because operational users know where the documented process differs from the work actually performed. A buyer may know the purchase approval policy. The receiving clerk knows that a supplier can arrive after the branch manager has left, that connectivity can fail during a delivery, and that an incorrect unit of measure can hold up an entire receipt.
SAP implementation guidance is clear on the division of responsibility: users help define the business processes that drive ERP configuration. Early and continuous involvement in specification and system selection reduces resistance because users can see their operating reality reflected in the process.
The mistake we see most often is counting attendance at training as proof of adoption. A person can complete training, receive an Odoo user licence and still return to a spreadsheet or paper register when an exception occurs. That is a signal to improve the workflow with input from the people who execute it.
Case illustration: The receiving desk that broke stock visibility
Consider a Zimbabwean retailer with several branches, which we will call Sable Traders. Its project team configured inventory receiving around a standard rule: post the supplier delivery before stock is available for sale, but branch receiving clerks had not joined the fit-to-standard workshops. When network interruptions occurred, clerks recorded deliveries offline and posted them later, so the system showed stock in the wrong branch or no stock at all.
Training completion was high, yet manual stock adjustments increased and replenishment decisions became less reliable. The business then observed receiving shifts, designed an exception workflow for interrupted connectivity, appointed clerk super-users and measured same-day receipt posting, inventory variance, stock-outs, manual adjustments and support tickets. This is a composite illustration grounded in user-participation research.
The lesson is practical: do not ask frontline staff only whether they βlikeβ the ERP. Invite them to demonstrate their most frequent transactions in a process walk-through, including what happens when the normal route fails. This reveals improvements before they disrupt service.
Approach: Make frontline staff operational co-designers
We recommend treating frontline users as co-designers of the Odoo ERP implementation. They should not be brought in only when configuration is complete and training dates have been booked.
1. Select users by transaction volume and operational risk
Start with the transactions that affect cash, stock, customer service or compliance records. Include the people who complete purchase receipts, stock adjustments, sales returns, cash-up entries, work orders and service visits.
A manager can explain the policy. The employee processing frequent receipts can show where the policy fails in practice. Addressing these gaps early helps prevent workarounds from spreading across branches and improves the accuracy of shared information.
For each site, identify at least one operational representative for each critical process. A branch cashier should represent cash and returns. A warehouse clerk should represent receiving and stock movement. A field technician should represent mobile job completion and parts consumption.
2. Run fit-to-standard workshops around real work
Use a real supplier delivery, a real return or a real stock discrepancy in the workshop. Ask the user to show each step, each approval and each document used. Then ask what happens when the delivery is short, the supplier invoice differs from the purchase order, or the network is unavailable.
The step project teams often skip is documenting exceptions. Standard Odoo workflows can provide a controlled base process, but local operating rules must define who can override a transaction, what evidence is retained and how the exception is reviewed. That creates an auditable process rather than an informal workaround.
For Zimbabwean groups with branches in Harare, Bulawayo and smaller operating sites, test the workflow in the actual work setting. A process that works in a head-office demonstration may fail at a branch receiving point if the user must switch between a delivery note, a paper log and an unavailable connection.
3. Put frontline users into user acceptance testing
User acceptance testing should include transaction completion, exceptions and correction paths. It should not be limited to confirming that screens open and reports display.
Give each role a short set of realistic scenarios. Measure whether the user completes the transaction without assistance, whether the first entry is correct, and whether the system records the operational evidence required for review. A failed scenario is useful because it points to a configuration, master-data or process-design decision before go-live.
4. Keep super-users on the floor after go-live
A super-user should support the first receiving shift, month-end stock count or branch cash-up, not sit only in a project status meeting. Support tickets and exception logs tell the implementation team where users are struggling and where the workflow needs adjustment.
Industry implementation guidance reinforces the value of ongoing, in-application support. Practical guidance and timely assistance help employees build confidence, complete transactions correctly and realise the benefits of the new system. Enablement belongs in the implementation plan from the beginning.
Results: Measure adoption through operational indicators
Go-live status is a delivery milestone. Real value comes when employees use the ERP consistently to improve stock accuracy, customer service, reporting and everyday decisions.
Implementation guidance recommends measuring user adoption, process efficiency and transaction quality. At Serpa, we focus on adoption by role, site, module and transaction so management can see where the ERP is delivering value and where targeted support will help.
| Operational indicator | What to measure | Why it matters | | Active user rate | Active users as a share of assigned users, by role | Identifies licensed users who have returned to old methods. | | ERP transaction rate | Share of receipts, invoices, stock moves or work orders completed in Odoo ERP rather than paper or spreadsheets | Shows whether the system is becoming the operational record. | | First-time-right rate | Transactions completed correctly without correction or reversal | Measures practical competence, not course attendance. | | Exception and rework rate | Overrides, manual adjustments, reversals and repeat entries | Reveals workflow gaps and weak master data. | | Helpdesk tickets by team | Tickets by role, branch and transaction type | Shows where support and process redesign are needed. | | Process cycle time | Order-to-cash, procure-to-pay and stock-adjustment cycle times | Connects user behaviour to cash flow and operational throughput. | | Inventory accuracy | Difference between recorded and counted stock | Tests whether warehouse adoption is producing reliable visibility. | Β Set a baseline before go-live, then review adoption regularly as teams settle into the new processes. Comparing performance with the starting position helps management recognise improvements, respond to friction and sustain the benefits of the investment.
Do not declare failure if performance dips during the initial adjustment. Early challenges can reveal where employees need more training, better master data or a clearer process. Investigate errors and workarounds promptly, then improve the workflow before temporary habits become permanent.
Worked example: A small team can still create a large control gap
Take a retailer with a small operations team. Management may assume that a modest user population makes adoption straightforward, but a cashier using an offline returns register can leave customer credits and stock records out of sync. If the business measures only licences issued, it may miss the issue until reconciliation. A focused adoption review can protect customer experience and strengthen inventory control.
The better measure is how consistently returns are processed in Odoo ERP, how accurately transactions are completed and how quickly exceptions are resolved. Reducing repetitive corrections gives staff more time to serve customers and helps management trust the information used for decisions.
Quote
> βThe ERP is adopted when the person doing the work can complete the normal transaction and the messy exception without leaving the system.β
This is the standard we use when assessing operational readiness. It puts the test where it belongs: on the shop floor, at the receiving desk and in the field, rather than on a go-live dashboard.
Frequently Asked Questions
What is ERP user adoption?
ERP user adoption is the extent to which people use the ERP for their required work, complete transactions correctly and stop relying on parallel spreadsheets or paper records. Training completion is one input, but it is not proof of adoption.
Which frontline users should join an ERP implementation?
Include people who execute high-volume or high-risk transactions, such as receiving clerks, buyers, cashiers, shop-floor supervisors and field technicians. Select them by the process they perform, not by job seniority.
How long should we measure adoption after go-live?
Review adoption regularly after go-live, with closer attention during the initial transition. This helps management distinguish temporary learning challenges from workflow problems and provides time to reinforce good habits and improve performance.
Should a business delay go-live if users are not ready?
If user acceptance testing shows that critical roles cannot complete normal and exception transactions accurately, improve the process before deployment. A well-prepared launch helps protect stock accuracy, customer service and the confidence of the teams who will use the system every day.
A Zimbabwean ERP implementation succeeds when operational teams can rely on the same controlled processes that management uses for reporting. Serpa helps businesses improve frontline readiness, strengthen Odoo ERP adoption and build dependable workflows that support efficient operations and confident growth. Contact Serpa to discuss your requirements and request a tailored quote for ERP implementation and user adoption support.