Most ERP systems are configured once, at the point the business understands itself least well, and then left alone. Three years later the business has changed and the system has not, so people work around it. The fix is not another implementation. It is treating the system as something that gets revisited on a schedule.
This page covers how to tell a system has stopped fitting, what to change and what to leave, how often to review it, and what it costs to keep a system current.
How do you know the system has stopped fitting?
The symptoms are behavioural before they are technical.
- Spreadsheets reappear. Not the ones that were never replaced. New ones, built after go-live, to do something the system makes awkward.
- Fields are being misused. A notes field holding structured data. A customer reference carrying three pieces of information separated by slashes.
- Reports are rebuilt by hand. The monthly pack starts in the system and is finished in Excel, every month, by the same person.
- New staff are trained on the workaround. This is the clearest signal. The workaround has become the process.
- Nobody can say why a step exists. It was configured for a reason that no longer applies, and nobody has authority to remove it.
None of these are software faults. They are the business having moved.
What actually changes in a business?
More than most people expect over three years, and rarely the things the original scope anticipated.
New revenue lines are the usual driver. A distributor starts selling direct. A manufacturer takes on contract work. A services business productises something. Each one arrives with its own pricing, its own margin question and often its own compliance treatment, and none of them were in the chart of accounts when it was designed.
Then there is scale. Processes that worked with four people approving things informally stop working at twelve. Volume turns a small manual step into a full-time job. Acquisitions add a second entity, a second set of books, and a consolidation requirement nobody planned for.
And regulation moves. Payroll reporting obligations change. Industry schemes get replaced, as Support at Home replaced the Home Care Packages Program on 1 November 2025. A system configured against the old rules keeps applying them.
What should change, and what should stay?
The distinction worth holding is between the foundation and the surface.
The foundation is expensive to change after go-live and should be designed to last: the chart of accounts, the product and customer model, the stock valuation method, the entity structure. Get these wrong and every later change is harder. More on why in Why Your Odoo Implementation Should Start with the Chart.
The surface is meant to move: workflows, approval thresholds, report layouts, price lists, automation rules, the fields a particular team sees. In Odoo most of this is configuration rather than development, which is the practical argument for the platform. A business that has to raise a development ticket to change an approval limit will stop asking.
The failure mode is treating the surface as though it were the foundation. Teams get told a change is impossible when it is a configuration screen, because the only person who knew that left.
How we think about this
Ooda Consulting is named after the OODA Loop, the decision cycle of observe, orient, decide and act. Odoo is the ERP platform we implement; the OODA Loop is how we run the implementation and how we think a system should be maintained afterwards. The two are different things with unfortunately similar names.
Applied to a live system, it is a review rhythm rather than a project:
- Observe. Where have spreadsheets reappeared, and which reports are finished outside the system?
- Orient. Which of those are the business having changed, and which are configuration nobody got to?
- Decide. Pick the small number worth doing this quarter, and say plainly what is not being done.
- Act. Change it, tell the people affected, and check in a month whether the workaround stopped.
The last step is the one that gets skipped. A change nobody is told about does not change behaviour.
How often should the system be reviewed?
Quarterly for the first year after go-live, then twice a year.
The first year matters most because that is when the gap between what was scoped and how people actually work becomes visible. A review in month three catches a workaround before it becomes the process. The same workaround found in year two has been trained into four people and written into a procedure.
A review that works is short and specific: an hour with each team that uses the system daily, asking what they do outside it and why. Not a survey, and not a meeting with managers only. The people doing the work know where the system is awkward.
What does it cost to keep a system current?
Less than the alternative, which is a re-implementation every five years.
Published Australian benchmarks put a replacement ERP project at $15,000 to $25,000 for around 5 users and $40,000 to $70,000 for around 15 users, before licensing. Figures compiled from published Australian partner pricing, August 2026. A support arrangement that keeps the system moving costs a fraction of that, and it means the knowledge of why things were configured a particular way stays with someone.
The real cost of not doing it is harder to see. It is the reporting that takes three days instead of three hours, the staff member whose job is reconciling two systems, and the decision made late because the number was not available.
How we work
Ooda Consulting is based in Sydney at Level 6/201 Kent St and works with SMEs across Australia and New Zealand. The Australian team scopes the work and supports it afterwards, with a dedicated senior developer doing the build.
See Odoo ERP Implementation for how a build is scoped and staged, or Fractional CFO if the reporting is the part that has stopped keeping up.
Frequently asked questions
How often should an ERP system be reviewed after go-live?
Quarterly for the first year, then twice a year. The first year is when the gap between the scoped process and the actual one shows up, and a workaround found at month three is much cheaper to fix than the same one found at year two.
Does changing our processes mean re-implementing Odoo?
Usually not. Workflows, approval thresholds, report layouts, price lists and automation rules are configuration rather than development. What is expensive to change is the foundation: the chart of accounts, the product model and the stock valuation method.
What are the signs our ERP has stopped fitting the business?
New spreadsheets built after go-live, fields being used for something other than their purpose, monthly reports finished by hand in Excel, and new staff being trained on the workaround rather than the system.
Can Odoo handle a new revenue line without a new project?
Often yes, if the chart of accounts and product model were designed with room. A new channel usually needs pricing, a margin view and a tax treatment, all of which are configuration. It becomes a project when the foundation has to be restructured to accommodate it.
Is ongoing support worth it, or should we call someone when something breaks?
Call-when-broken works for faults and fails for fit. Nobody raises a ticket because a process is awkward, so the system drifts quietly until it needs replacing. A review rhythm catches the drift while it is still cheap.
What is the OODA Loop, and what does it have to do with Odoo?
The OODA Loop is a decision cycle, observe, orient, decide and act, and it is what Ooda Consulting is named after. Odoo is the ERP platform we implement. We use the loop as the method for running an implementation and for reviewing a system afterwards, which suits a situation where the picture changes while you are acting on it.
