Every ERP project starts with a hope that nobody says out loud: that the new system will sort out the things people won't.
It won't. Software is a multiplier. Put it over a disciplined team and you get a disciplined team moving faster. Put it over a business where nobody owns the data, approvals depend on who's shouting, and the real numbers live in someone's private spreadsheet, and you get all of that at speed, with a licence fee attached.
What amplification actually looks like
We see the same patterns across Australian SMEs. Healthcare and NDIS providers, wine importers and producers, manufacturers. Different industries, identical failure modes.
Nobody trusts the numbers. Before Odoo, the monthly report was late and wrong. After Odoo, it's on time and wrong, because the underlying data entry habits didn't change. Faster reporting of bad data is not an improvement. It's a louder version of the same problem.
Workarounds get encoded. Someone built a manual process five years ago to get around a broken step. The step got fixed. The workaround stayed. During implementation it gets described as "how we do things" and lands in the configuration. Now it's permanent and everyone else has to follow it.
Shadow spreadsheets migrate. A business that runs on side spreadsheets will keep running on side spreadsheets after go-live. The ERP becomes a system of record that nobody uses to make decisions. You've bought an expensive filing cabinet.
Bottlenecks become policy. If one person insists on approving everything, that habit turns into a workflow rule. What was an annoyance is now enforced by the system, and the delay it causes is measurable, permanent and defended.
Blame gets an audit trail. In a low trust business, the first thing people do with a new system is work out who to point at. Every timestamp becomes evidence. Adoption stalls because logging your work honestly is now a risk.
The reverse is equally true. Teams that own their numbers, close things off properly and tell the truth about problems get enormous leverage out of the same software. Same product, same consultants, opposite outcome.
Three sectors, same pattern
Healthcare and NDIS. Service delivery gets recorded days late because the field team was never held to same-day entry. Plan managers query the claim, the claim gets adjusted, and nobody updates the source. Asset registers for equipment on hire drift from reality because returns are logged when someone gets around to it. Odoo will happily generate a claim from whatever it's given. Compliance evidence is only as good as the habit behind it.
Wine. Stock in the system, stock in the warehouse and stock in bond are three different numbers, and everyone has quietly accepted that. Samples leave without paperwork because that's how the trade works. Landed cost gets estimated once and never corrected, so nobody knows the true margin per SKU by vintage. Put an ERP over that and you get precise reporting on numbers that were never true. WET and excise treatment is the same story: the system applies the rule you configured, not the rule you should have agreed on.
Manufacturing. There is the BOM in the system and there is the BOM the shop floor actually uses. If the gap between them was tolerated before, it survives implementation, and every costing report after go-live is fiction. Scrap goes unrecorded because recording it invites questions. Work orders get closed in a batch on Friday, so WIP is meaningless mid-week. None of that is a software problem. It's whether the business has decided that what happens on the floor gets written down as it happens.
The OODA loop cuts both ways
The loop is Observe, Orient, Decide, Act. Most ERP projects are sold as an improvement to Act. Faster quoting. Faster invoicing. Faster dispatch.
Act is the easy part. If Observe is unreliable because stock counts are guesses, and Orient is contested because finance and operations disagree on what a job costs, then all you've done is shorten the time between bad information and expensive decisions. The loop still turns, just faster in the wrong direction.
The businesses that get value out of an implementation fix Observe and Orient first. What is true, who says so, and how do we know. The software then does what it's good at.
What to sort before you configure anything
None of this requires a consultant. It requires a decision.
- Name the owner of every master data set. Customers, products, suppliers, price lists, employees. One person accountable for each. Not a committee.
- Decide once, in writing. How do we cost a job. What counts as delivered. When is revenue recognised. If these are argued monthly now, they'll be argued monthly forever, with a system in the middle.
- Kill the parallel spreadsheet before go-live, not after. If it survives the first month it survives the first year. Say it out loud: after cutover, if it isn't in Odoo it didn't happen.
- Separate the process problem from the system problem. Half of what gets raised in requirements workshops is a management issue in technical clothing. Configuring around it makes it structural.
- Agree what happens when someone doesn't use the system. If the answer is nothing, you have your adoption forecast.
- Pick a single set of numbers for the leadership meeting. From the system. Even when they're uncomfortable. Especially then.
Where Odoo helps and where it can't
Odoo is genuinely good at removing the causes of a certain kind of friction. One database instead of seven applications. Sales, inventory, projects, timesheets and accounting connected, so a change in one place shows up everywhere. Automation of the repetitive work that people currently do badly because it's boring.
For NDIS and healthcare equipment providers, that means service, rentals, compliance and billing in one place instead of stitched together after the fact. For wine, it means lot and vintage traceability, landed cost, and WET handled in the same ledger as sales and stock. For manufacturers, it means BOMs, routings, work orders and actual costs connected, so quoting is based on what production really costs rather than a number from 2019.
What it can't do is make someone care about accurate stock counts. It can't force a manager to make a decision. It can't create accountability where none exists. Configuration is not culture, and no amount of custom development substitutes for a conversation that nobody wants to have.
Implementations fail for cultural reasons far more often than technical ones. The technical problems have answers. The others need someone in the business to change their mind.
The honest version
If your business runs well and you're held back by systems, an ERP implementation will deliver a return quickly. That's the straightforward case and we do a lot of them.
If your business doesn't run well, be clear-eyed. The system will surface every gap within weeks. That's useful, as long as you've decided in advance that surfacing problems is the point and not a reason to blame the software.
The best outcome from an implementation is often the six weeks of process work before anyone touches a configuration screen. That's where the culture question gets settled. What follows is comparatively easy.