The demo looked incredible. Manufacturing, inventory, CRM, helpdesk, timesheets, e-commerce, expenses, HR — all connected, all in one place. And because most modern ERP platforms don't charge much (or anything) extra per module, there's no obvious reason to hold back. So the project plan gets written with everything in scope, and nine months later the team is still arguing about whether the system is "ready."
Breadth is what kills ERP rollouts far more often than technical difficulty. Every module you switch on is a new set of master data to clean, a new group of people to train, a new set of reports someone has to learn to trust, and a new way for the project to stall. The discipline that separates a smooth go-live from a death march is knowing what to leave off.
Sequence by Dependency, Not Enthusiasm
The natural instinct is to start with whatever the team complains about most. That's usually the wrong order, because the loudest pain is often downstream of data that doesn't exist yet.
Start instead with the spine: the path a dollar takes through your business. For most companies that's quote to order to fulfillment to invoice to cash, plus the general ledger underneath it. Those modules produce the master data — customers, products, pricing, chart of accounts — that everything else consumes. Get them clean and live, and the next wave of modules has something real to plug into.
Modules that primarily consume data should almost always come later. A helpdesk that can't see accurate customer records is worse than the shared inbox it replaced. A manufacturing module built on a product catalog nobody has scrubbed will generate work orders your floor ignores.
A Three-Question Test for Every Module
Before anything makes the day-one list, run it through the same short filter:
- Does the business genuinely stop without it on launch day? Invoicing does. Employee expense claims usually don't.
- Does it depend on data another module owns? If yes, that module ships first — in a separate phase, not the same weekend.
- Is there a named person accountable for using it daily? Not a department. A person, by name, who will notice within a day if it's wrong.
If a module fails any of those questions, it belongs in phase two. That's not a demotion. It's a scheduling decision that protects the modules that matter.
Make "Later" a Real Date
The reason teams resist a phased plan is that they've been burned. "Later" too often means never — the consultants leave, budget dries up, and the module nobody launched becomes a shadow spreadsheet that quietly grows into a second system of record.
So make later concrete. Every deferred module gets a target quarter, a named owner, and a written note explaining what has to be true before it starts. Usually that prerequisite is data quality or a process decision the business hasn't made yet — which is precisely why forcing it into the first go-live would have gone badly.
This also changes the conversation with stakeholders. You aren't telling the service manager no. You're telling them their module launches in Q3, after the customer master is clean, and they'll be configuring it with a team that has actually used the platform for a quarter. That's a better deal than what they'd get on day one, and most people recognize it.
Adoption Is the Only Go-Live Metric That Counts
A module is not live because it's configured. It's live when the people who own that work are doing it in the system, without a parallel spreadsheet, without a workaround, and without a single power user re-entering everyone else's data at the end of the week.
Measure that directly. For each module in scope, identify who should be creating records and check whether they actually are in the first few weeks. Logins tell you nothing. Transactions entered by the right people tell you everything. Where adoption is thin, the cause is almost always one of three things: the process doesn't match how the work really happens, the data they need isn't in there yet, or nobody made it clear the old method is closed.
A narrow go-live gives you the bandwidth to chase all three. A sprawling one buries the signal — when twelve modules are half-adopted, you can't tell which problem to solve first, and the organization concludes that "the ERP doesn't work."
Start by Cutting the Scope You Already Wrote
If you have a project plan in front of you right now, take the module list and sort it into two columns using the three questions above. Most teams find their day-one column is roughly half the size they assumed, and the second wave looks far less intimidating once the foundation is in place.
That sequencing work is where implementations are won or lost, and it's hard to do objectively from inside the project. If you're planning an Odoo rollout — or trying to rescue one that's stalled under its own scope — reach out to Infraxio. We'll help you draw the line between what ships now and what waits, and build the plan that gets the rest live on schedule.