The value most implementations leave behind.
An implementation ends when the system goes live and the contract closes. But the organisation only starts learning what it actually needs on about day 91 — and by then the project team has gone, the budget is closed, and every improvement request is treated as a support ticket rather than a design decision.
So the ERP freezes in the shape it had at go-live. Approvals that were added defensively stay for a decade. Screens carry fields nobody fills. Reports are exported to Excel and then re-formatted by hand every month. None of this is broken, so support never touches it — and the gap between what the platform could do and what the organisation gets from it widens every year.
What an optimisation engagement usually finds.
Work still happening outside the ERP
Spreadsheets, email approvals and WhatsApp threads carrying steps the system was supposed to own.
Approvals that no longer control anything
Three signatures on a purchase under a thousand dirhams, added once after an incident and never reviewed.
Reports nobody trusts
Each department maintains its own version because the definitions behind the standard report were never agreed.
Screens built for the project, not the user
Twenty fields where four are used, and a navigation path that takes six clicks to reach a daily task.
Performance degrading quietly
Scheduled actions overrunning into working hours, and reports that time out at month-end.
Customisations now redundant
Code written three versions ago to do something standard Odoo now does natively, still being maintained.
What the engagement actually includes.
Usage analysis
We instrument the system and read what actually happens in it — which modules carry real volume, which screens are abandoned mid-task, and where users leave the ERP to finish their work elsewhere.
Process simplification
Steps removed rather than automated where possible. An approval that adds two days and catches nothing is deleted, not digitised — and the control it was meant to provide is replaced with an exception report.
Automation
Repetitive work identified and removed: approvals under threshold, notifications, document generation, reconciliation, scheduled reporting, escalations and data synchronisation.
Customisation rationalisation
Every extension assessed against current standard Odoo: keep, replace with standard, refactor or remove. This is usually where the largest maintenance saving sits.
Performance tuning
Database, queries, custom code, scheduled actions and integrations profiled and corrected — with a measured before-and-after on the operations users actually complain about.
Reporting redesign
One agreed definition per metric, then dashboards designed for the person who reads them — the supervisor with a daily decision, not the executive with a monthly review.
A five-stage cycle, repeatable annually.
Four verdicts for every extension you own.
This matters most on environments implemented three or more versions ago. Odoo has absorbed a great deal into standard since then, and code written to fill a gap that no longer exists is pure maintenance cost.
Still required, still the best available answer, and upgrade-safe. Documented and left alone.
Standard Odoo now does this. The extension is retired and the process moves onto the standard capability.
The requirement is genuine but the implementation carries upgrade risk. Rewritten against current framework practice.
Nobody uses it. Usage data shows zero activity, and removing it reduces both risk and cost.
Support asks why something is not working. Optimisation asks how it could work better. They are different engagements and they need different budgets.
A prioritised improvement backlog, and the first wave delivered.
Optimisation is not a report. The assessment produces a ranked backlog, and the engagement delivers the top of it so the value is proven before the next wave is funded.
Optimisation is mostly configuration, not development. These are the levers we use, roughly in the order we prefer them.
Ranges observed on Al Jawad engagements. Your targets are agreed in assessment, before the work starts.
How is this different from support?
Support restores what is broken. Optimisation changes what works but works badly. A support contract will never remove an unnecessary approval, because the approval is not a fault.
Do we need to upgrade first?
Not usually. Optimisation often reduces the cost of the eventual upgrade, because retiring redundant customisation is the single biggest driver of upgrade effort.
How long before we see something?
The assessment takes two to three weeks; the first wave lands in the four to six weeks after that. We deliberately sequence quick, visible items first — adoption improves when users see the system responding to them.
ERP governance after go-live.
The decision log is the asset. Most programmes throw it away at handover.
ERP StrategyWhy ERP projects fail at the operational layer.
Implementations rarely fail technically. They fail at the point where the software meets a process nobody agreed to change.
Start a conversation.
Choose the one that fits where you are. None of them is a sales call. Each is an advisory conversation calibrated to a specific question.