In this article
- Challenge: When every legacy habit becomes code
- Approach: Standardise before commissioning a module
- Use a four-step decision process
- Worked illustration: Simplifying approval variations
- Results: Measure operational control, not deployment activity
- Worked illustration: The spreadsheet workaround
- Quote: The operating principle we apply
- Frequently Asked Questions
- What is included in ERP customisation costs?
- Can standard Odoo upgrades include custom modules?
- When should a Zimbabwean business choose custom code?
- How can a Zimbabwean business request an Odoo customisation quote?
A finance director approves a workflow change because one branch has “always done it this way”. Later, the same exception appears in purchasing, sales and stock adjustments. The Odoo ERP implementation is live, but every upgrade now requires extra compatibility checks, testing and careful planning to avoid disruption.
That is where the long-term impact of ERP customisation becomes clear. A change may solve an immediate request while adding maintenance work to future upgrades. For African organisations running multi-entity operations, the priority is to ensure each change delivers measurable value, stronger controls and a system that remains dependable as the business grows.
Challenge: When every legacy habit becomes code
An ERP should provide one approved record of how a transaction moved through the business. When every department retains its own approvals, fields and exception rules, that record fragments. Reporting becomes harder to compare across branches, managers revert to spreadsheets, and auditors must establish which workflow governed a transaction.
We distinguish three approaches during Odoo ERP implementation:
| Cost line | What it covers | Long-term implication | | Configuration | Standard settings, roles, approval rules and fields available in Odoo | Usually carries lower upgrade risk because it remains within standard application capability. | | Process redesign | Removing duplicate approvals, agreeing policy thresholds and training users on one workflow | Requires management decisions, but can remove recurring code and reporting exceptions. | | Custom code | A module that extends standard Odoo code and is not built with Studio | Creates a recurring obligation for maintenance, compatibility checks, testing and upgrade work. | The distinction matters because a request that sounds technical is often a policy issue. “We need a separate approval route for this branch” may mean the approval limit has never been agreed. If the real problem is a missing policy, custom code preserves uncertainty rather than solving it.
Odoo’s guidance is clear: customised databases cannot be upgraded until custom modules are compatible with the target version. The work includes a code freeze, test database, module installation tests, data-migration scripts, a rehearsal and production deployment. Planning these steps early protects business continuity and reduces avoidable upgrade disruption.
Odoo 19.0 was released in September 2025 and has standard support planned to September 2028. Odoo 20.0 was released in September 2026 and has standard support planned to September 2029. Those dates make version compatibility an active board-level cost consideration, not a technical detail to revisit at the end of an implementation.
Approach: Standardise before commissioning a module
We ask process owners to demonstrate the business benefit of an exception before development begins. This helps preserve consistent operations, simplify reporting and maintain an auditable Odoo environment.
Use a four-step decision process
1. Describe the transaction and policy, not the screen change. State who approves, at what point, under which threshold and why. A request for a button or field is not sufficient because it does not identify the control the business is trying to achieve.
2. Test standard configuration first. Check whether standard approval rules, access rights, automated actions or redesigned responsibilities meet the requirement. This matters because Odoo recommends challenging existing developments against newer standard features and removing redundant code.
3. Quantify the exception. Record transaction volume, affected entities, approval lead time, error rate and financial exposure. If a rule affects only a handful of transactions and has no measurable control benefit, do not create a permanent module for it.
4. Review the full support lifecycle. Assess development alongside future compatibility checks, data migration, test environments, regression testing and user retraining. Standard Odoo application upgrades are covered by the Enterprise upgrade service, but in-house, partner-built and third-party modules are excluded unless a maintenance-of-customisations subscription covers them. A clear support plan helps prevent surprises and protect system reliability.
For Zimbabwean businesses, the right customisation approach depends on operational requirements, implementation scope and the agreed support arrangements. SERPA helps organisations evaluate configuration, process redesign and bespoke development so that the chosen solution improves efficiency without creating unnecessary complexity. Enquire for a tailored quote based on your needs.
Worked illustration: Simplifying approval variations
Consider a distributor with several branches, each using bespoke approval routes inherited from earlier management practices. This is a hypothetical illustration, not a SERPA client result. The variations make reporting inconsistent and create avoidable testing work whenever the system changes.
After reviewing actual approval responsibilities, the distributor replaces overlapping variations with a smaller set of policy-based workflows and retires redundant custom modules. Its team can now monitor approval delays and exceptions consistently across branches, while future upgrades become easier to test and manage.
If SERPA joined the project earlier, we would begin with a group-wide approval policy before accepting workflow specifications. The lasting benefit is clearer accountability, comparable reporting across entities and a more manageable system as operations expand.
Results: Measure operational control, not deployment activity
A live system is not proof that the ERP implementation has improved operations. We recommend a monthly scorecard that shows whether the organisation is gaining standardisation or accumulating technical debt.
| Indicator | What to measure | Why the board should care |
|---|---|---|
| Custom modules | Count by business process and entity | A rising count signals future upgrade scope and fragmented operating rules. |
| Custom-code hours per release | Development and repair effort for each release | This exposes recurring ownership cost that a go-live budget misses. |
| Upgrade-test defects | Defects found during module and regression testing | Defects show where custom behaviour conflicts with the target version. |
| Days of code freeze | Days where changes stop before deployment | Long freezes constrain operational change and increase deployment risk. |
| Order-to-cash cycle time | Time from order to cash receipt | This tests whether controls have improved flow or simply added approvals. |
| Purchase-order approval time | Time awaiting a decision | This identifies whether an exception route is slowing procurement. |
| Inventory adjustment rate | Adjustments as a share of inventory activity | This helps test whether users are working around the approved process. |
| Spreadsheet-based transactions | Transactions completed outside Odoo | Spreadsheets weaken real-time visibility and make audit evidence harder to reconcile. |
| Approved workflow adoption | Percentage following one approved workflow | This is the clearest measure of whether standardisation is actually taking hold. |
Worked illustration: The spreadsheet workaround
Consider a retailer whose stock controller keeps a spreadsheet for urgent stock corrections because the ERP approval sequence was copied from a former system and relies on managers who are often off-site. This is an illustrative example. The workaround weakens visibility and makes it harder to maintain a reliable audit trail.
The right response is not automatically a custom bypass button. The team first measures adjustment volume, time waiting for approval and the value of adjustments. If the evidence shows that the rule is legitimate but too slow, the business can redesign the standard approval threshold and retain an audit trail in Odoo.
Where corrections are genuinely exceptional, we would retain a controlled exception process and train users rather than build another workflow. This supports adoption, preserves accountability and avoids unnecessary complexity during future upgrades.
Quote: The operating principle we apply
> “Standardise the process unless the exception creates measurable business value.”
This is the judgement call behind a controlled Odoo customisation programme. We do not recommend custom code simply because a department has a familiar form or approval sequence. We recommend it where configuration and process redesign cannot meet a defined control, integration or commercial requirement, and where the business accepts the maintenance obligation in writing.
For an Odoo ERP for Africa deployment, that written decision should identify the module owner, source-code repository, supported Odoo versions, test cases, maintenance responsibilities and retirement criteria. This gives the organisation a clear plan for keeping the system reliable and adaptable.
Frequently Asked Questions
What is included in ERP customisation costs?
ERP customisation requires planning beyond initial development. Consider requirements analysis, ongoing source-code maintenance, compatibility with future versions, data migration, testing, deployment and user retraining. Addressing these needs early supports smoother upgrades, stronger controls and more dependable operations.
Can standard Odoo upgrades include custom modules?
Standard Odoo application upgrades are covered under the Enterprise upgrade service. In-house, partner-built and third-party modules are excluded unless they are covered by a maintenance-of-customisations subscription. Confirm this point in the commercial agreement before approving custom work.
When should a Zimbabwean business choose custom code?
Choose custom code when a requirement has measurable control, integration or commercial value that standard configuration and process redesign cannot meet. If the request preserves a low-volume legacy preference without a measurable benefit, do not build it. The future upgrade and testing obligation is unlikely to produce acceptable ROI.
How can a Zimbabwean business request an Odoo customisation quote?
Begin with a review of your business processes, integration requirements, reporting needs and existing custom modules. SERPA can recommend where standard Odoo configuration or process redesign will deliver better value and where custom development is justified. Request a tailored quote based on the agreed scope and support needs.
Speak with the SERPA team to review your custom modules, simplify workflows and prepare for future Odoo upgrades. Enquire for a tailored quote for an implementation and support approach aligned with your business goals.