Odoo or custom ERP: make the decision around workflows

Put the company’s essential workflows in rows and three possible solutions in columns: configure Odoo, extend or integrate it, or build an independent system. For each intersection, estimate manual steps, impact on employees and customers, and the future cost of change. Weight requirements by business consequence. A billing delay that blocks collection matters more than the colour of a management dashboard. If a distinctive workflow is the reason customers choose your company, do not remove it merely to fit a packaged template.

Run a proof of concept with representative data rather than a tidy sample database. Include real products or services, a customer with special terms, a late supplier, and a user with limited permissions. Observe how exceptions are handled and whether managers can see why a process stopped without calling a developer. Finish with a written record: what works through configuration, what needs custom work, which company process must change, and what remains uncertain until another test.

A modification has more than a build cost. It may need testing after each upgrade, documentation for new employees, and support when an external integration changes. Also measure the cost of leaving a critical workflow outside the system; a focused extension can be cheaper than years of repeated manual work. Conversely, building every standard screen from scratch creates long-term obligations for functions that packaged software already handles competently. Reserve budget for post-launch change instead of spending everything before the first real user logs in.

If a vendor calls a modification “minor”, ask where it lives. Is it a supported configuration, a separate extension, a change to core code, or an external service? These approaches have different upgrade and portability risks. Request an explanation of how it will be tested after a version update and who pays to resolve conflicts. Compare maintainability and responsibility as well as implementation hours. A low initial bid can be expensive if no one can safely change the result later.

Begin with one team or module where outcomes can be measured, then expand once accuracy is proven. Avoid switching finance, warehouse, and sales in a single day unless the process truly requires it and the cutover has been rehearsed. Decide when old data becomes read-only, who resolves discrepancies, and what staff will do if a blocking issue appears. Train people on the scenarios they perform, not a generic tour of menus.

After thirty days, measure completion time, manual corrections, report quality, and dependence on support. If employees continue to work outside the system, investigate whether the cause is training, cumbersome screens, or a genuine functional gap. Do not add another module before understanding why the first has not been adopted. This turns “Odoo versus custom” from a technology debate into an evidence-led improvement programme.

Before signing, ask which processes work without development, what customisation limits exist, who owns code and data, how upgrades and migration will be managed, and what acceptance criteria apply to the first phase.

Do not reduce the decision to an average score that hides a critical failure. Name three non-negotiable conditions, perhaps accurate opening balances, branch-level access, or integration with an existing system. If one solution fails a condition essential to operating the business, ten minor advantages cannot compensate. If both pass, compare time to value, your team’s capacity to manage the system, and the cost of changing a workflow when the market changes. Speak with a vendor’s existing customer whose scale and complexity resemble yours, and ask about month six rather than launch week.

Sometimes the right decision is to delay procurement briefly while cleaning product codes or clarifying account ownership. New software can accelerate an organised operation, but it does not automatically fix contradictory records or ambiguous responsibility. A short preparation phase is worthwhile if it produces a usable data map, process owners, and testable acceptance criteria. It may also reveal that your requirement is smaller, or simply different, than the one described in the original request for proposals. That discovery saves more money than negotiating a slightly lower licence fee for the wrong solution.