How we run a gap analysis before implementing Odoo
The step that sets a project's cost and timeline before a single setting is configured, and what you receive at the end of it.
On every one of our 40+ Odoo projects, the client's first question has been the same: “How much does an Odoo implementation cost?” The only honest answer is that we don't know yet, and any company that gives you a figure before sitting down with your departments is guessing. A gap analysis is how we turn that guess into a price, a scope and a timeline we can commit to.
This article explains exactly what we do in this step, who from your team should take part, and what comes out of it.
Why we don't quote before the gap analysis
Five factors set the cost of an Odoo project: the number of apps, the number of users, the amount of customization, the quality of the data to be migrated, and the edition (Community or Enterprise). Three of those five can't be known from a single call. Customization in particular is the line item that doubles the budget when it's discovered late.
That's why we contract the analysis separately from the implementation. You pay for a short analysis with a clear scope, and at the end you receive a report you can take to any other company. If you don't like our proposal afterwards, you still have documentation of your processes that you didn't have before.
What we mean by a “gap”: three types
A gap is any difference between how a department works today and how Odoo works out of the box. We classify every gap as one of three types, and each type calls for a different decision:
| Type | Example | Usual decision |
|---|---|---|
| Covered by Odoo out of the box | Approving purchase orders above a set amount | Configuration only, no development cost |
| Needs customization | An invoice layout that a major customer requires | We estimate and document the development hours |
| Better to change the process | Recording sales a week after delivery | We change the way of working, not the system |
The third type is the most important and the hardest. Many “requirements” that seem essential are really habits that formed around the limits of Excel or the old system. Our job is to ask “why?” twice before we write “customization”.
How the workshops run
Who attends
Not the general manager alone, and not the IT manager alone. We need the people who actually carry out each process: the storekeeper, not only the warehouse manager, and the accountant who posts the entries, not only the finance manager. The real gaps show up with the people who press the buttons.
What we ask
We trace every process from start to finish with simple questions. Who starts it? What document does it produce? Who approves it? Where is it recorded? What happens when it goes wrong? That last question uncovers most of the gaps: returns, cancelled invoices, stock counts that don't match.
What we document
For each process: a simple diagram of the steps, the documents going in and out, the people and their roles, and the exceptions. Then its counterpart in Odoo: the app, the screen and the setting. We write it in Arabic, in the language of your business rather than the language of the system.
Mapping processes to Odoo apps
After the workshops, we map every process to Odoo apps. This is often where it turns out that the company needs fewer apps than it imagined, and that one or two can wait for a second phase. Implementing Sales, Inventory and Accounting first, then Manufacturing or HR three months later, succeeds more often than implementing everything at once.
This is also where we settle the Community or Enterprise question: if every gap is of the first or third type, and you don't need Payroll, Studio or the mobile app, Community may be enough.
What you receive at the end of the analysis
How long it takes and what it costs
For a small or mid-sized company with three to five apps: one to two weeks of work, including two to four days of workshops at your premises or remotely. The fee is fixed and stated up front, and it's deducted from the implementation project if you go ahead with us.
Common mistakes we see
- Documenting what “should” happen instead of what does. The new system will be built on reality. If we document the ideal, we'll find the gaps after go-live.
- Skipping a small department. Maintenance or returns looks marginal until it holds up invoicing.
- Treating training as out of scope. In the analysis we decide who needs which level of training, because a system nobody uses has no value.
Key takeaways
- No figure before the analysis: customization and data quality don't show up in a phone call.
- Every gap is one of three types: configuration, customization or a process change, and the third is the cheapest.
- The people who run each process must attend the workshops, and so must the decision-maker.
- You receive a report you can use with anyone, and a real proposal.
