ERP Implementation: What to Settle First

ERP implementation is the work of moving a company's core processes (selling, buying, stock, accounting, often production and people) onto one shared system of record and then running the business on it. The software is the smaller part of that work. Most of the risk sits in decisions the business has to make itself: who owns the project, what "done" means, which processes change, whose data goes in, and when the old system is switched off.

That is why the first conversation about an ERP project should not be about modules or features. It should be about the handful of things below. If they are settled early, a sensible implementation plan almost writes itself. If they are not, no plan survives contact with the business.

1. This Is a Business Project That Happens to Involve Software

The most useful reframing I can offer is this: you are not buying a system, you are changing how the company works and using a system to hold the new way in place.

That sounds like a slogan, but it has concrete consequences:

The people who decide are business people. How a quotation is approved, when stock is reserved, who can post a journal entry: these are policy decisions. A consultant can propose them; only the business can make them.
Progress is measured in processes, not screens. "Sales is configured" means nothing. "We can take an order, reserve stock, ship it, invoice it and see the cash land, end to end, on real data" means something.
The hard part is agreement, not configuration. When two departments do the same thing two different ways, the ERP forces a choice. That argument has to happen somewhere. It is far cheaper in a workshop in week one than in production in month six.

If a company treats ERP as an IT purchase and delegates it downward, the project tends to drift into automating whatever everyone does today, including the workarounds, at custom-development cost.

2. Name One Owner Who Can Say No

Every implementation needs a single person on the client side who owns it, and that person needs real authority. Not a coordinator who books meetings, but someone who can settle a disagreement between sales and finance and make it stick.

What to put in place, specifically:

One accountable owner, senior enough to overrule a department head on process questions.
A named key user per area (sales, purchasing, inventory, accounting, production if relevant) who knows how the work is really done, not how the procedure document says it is done.
Protected time. Key users with a full-time job plus the ERP project on top will give the project their leftover hours. Leftover hours produce leftover testing.

A useful early warning sign: if nobody can name the owner in the first meeting, or the answer is "all of us", the project already has a decision-making problem.

3. Write Down What "Done" Means Before You Start

"Go live on the new ERP" is not a goal. It is an event. The goal is whatever business outcome made you start: closing the month faster, knowing true stock levels, stopping double data entry between the web shop and the books, being able to add a second company or warehouse without hiring another clerk.

Before scoping anything, write down three to five outcomes in plain language and how they would recognise each one. For example:

"Month-end close no longer depends on one person's spreadsheet."
"A salesperson can see available stock before promising a date."
"Online orders reach the warehouse without being retyped."

These outcomes do two jobs. They decide what is in scope, because anything that serves none of them is a candidate for phase two. And they give you an honest way to judge the project afterwards, instead of judging it by whether the go-live date held.

4. Scope Processes, Not Modules

The instinct is to scope by module list: CRM, Sales, Inventory, Accounting, Manufacturing. The trouble is that a module list says nothing about how much work each one is. "Inventory" can be one warehouse with simple receipts or five locations with lots, serial numbers, landed costs and drop-shipping.

Scope by end-to-end flows instead. A short list usually covers most of a company:

Flow	Starts with	Ends with	Questions that size it
Order to cash	Quotation or online order	Payment reconciled	Pricing rules? Partial deliveries? Credit limits? Multiple currencies?
Procure to pay	Purchase need	Vendor bill paid	Approval levels? Three-way matching? Landed costs?
Plan to produce	Demand or sales order	Finished goods in stock	Bills of materials depth? Routings? Subcontracting?
Stock control	Receipt	Counted, valued stock	Locations? Lots or serials? Valuation method?
Record to report	Transactions	Closed period, reports	Companies? Consolidation? Tax regimes?

Each row then gets its variations listed explicitly: the returns, the cancellations, the customer who pays in two instalments. The happy path is rarely where the effort goes. The variations are.

5. Your Data Is Your Job

It is tempting to treat data migration as something the implementer "does". The mechanics, yes: mapping, import scripts, validation. But the content is the business's responsibility, because only the business knows which of the three customer records for the same company is the right one.

What to start on immediately, before configuration:

Decide what migrates. Usually: active customers and vendors, active products, open orders, open balances, current stock. Rarely: every historical transaction since the company was founded. History can stay queryable in the old system or an archive.
Clean at the source. Deduplicate customers, retire dead products, fix units of measure. Cleaning inside the new system after import is slower and riskier.
Agree the opening balances with your accountant early, because they are the numbers everyone will check first.
Plan at least two full trial migrations on a copy of the new system before the real one, and compare counts and balances after each.

The early warning sign here is a spreadsheet of customers that nobody will admit to owning. Data with no owner migrates badly.

6. Adapt the Process Before You Customise the Software

Every modern ERP ships with a standard way of doing most things. Every request to change that standard should face one question: is this how we compete, or just how we are used to working?

If it is genuinely how you compete (a pricing model your market expects, a production step that is your edge), customisation is justified and worth doing properly. If it is habit, the cheaper and safer choice is to change the habit. Standard behaviour is tested by everyone who uses the product and carried forward by the vendor at every upgrade. Custom behaviour is tested by you and carried forward at your expense.

The order I recommend for any gap:

Can configuration handle it?
Can a maintained, version-supported add-on handle it?
Can the process change so the standard fits?
Only then: custom development, kept in its own version-controlled module with tests, never edits to the core.

I have written separately about what goes wrong when this order is ignored, in Odoo implementation mistakes to avoid. The same pattern applies to any ERP.

7. Pick the Cutover Before You Pick the Date

It is natural to start with a date. I would rather start with the cutover approach, because it determines what the date has to include.

Approach	What it means	Suits	Main risk
Big bang	Everything switches on one day	Smaller companies with a few tightly linked flows	Everything is new at once; recovery depends on preparation
Phased by process	Finance first, then operations (or the reverse)	Companies where one area is urgent and others can wait	Temporary interfaces between old and new systems
Phased by site or company	One location or entity at a time	Multi-site or multi-company groups	Two systems in parallel for longer; consolidation is harder meanwhile
Parallel run	Old and new both run for a period	High-stakes finance where every figure must reconcile	Double work for staff; only realistic for short periods

Whatever you choose, agree three things in writing: the cutover checklist (what gets frozen, exported, imported and verified, in what order), the go/no-go criteria (tied to test results, not to the calendar), and the fallback plan if the go/no-go says no. A good time for go-live is shortly after a period close rather than in the middle of your busiest season. A date chosen only because it sounds tidy is a weak reason.

8. Testing Is Done by the People Who Will Use It

A demonstration is not a test. A consultant clicking through the happy path while a manager nods is not user acceptance testing.

Real testing looks like this:

Key users run their own scenarios on migrated data, not on demo records.
Every scenario has a pass or fail, including the ugly ones: cancellation, return, partial delivery, a credit note, a month-end close.
Finance reconciles a trial period against the old system, figure by figure, where the stakes justify it.
Failures are logged and retested, and the go/no-go decision reads that log.

If testing keeps getting squeezed because configuration ran late, that is a scheduling signal to act on, not a phase to shorten quietly.

9. Budget for the Months After Go-Live

The first weeks after go-live are when the real questions arrive: a report someone relied on that nobody listed, a document template a customer rejects, a user who was on leave during training. Plan for a period of close support (sometimes called hypercare) with the same people who built the system, and a clear route for small fixes versus new requests.

Beyond that, decide early:

Who administers the system internally once the implementer steps back.
How upgrades will be handled, and how often. Small, regular upgrades are far easier than rare large ones.
Where new requests go, so the backlog does not turn into a string of unplanned customisations.

A Readiness Checklist

Before an implementation starts, you should be able to tick every line below. Each unticked line is a risk worth naming out loud.

One accountable owner with authority to settle process disputes
A named key user per area, with time actually set aside
Three to five written business outcomes and how each will be recognised
Scope written as end-to-end flows, with their variations listed
A decision on what data migrates, with an owner per data set
Agreement that standard behaviour is the default and customisation needs a reason
A chosen cutover approach, draft go/no-go criteria and a fallback plan
Test scenarios owned by key users, including exception cases
A post-go-live support period and an internal system owner named

How to Spot a Project Going Wrong Early

Most troubled implementations give warning weeks or months before go-live. The signs to watch for:

Decisions keep coming back. A process agreed in a workshop is reopened later by someone who was not in the room. That points to an owner problem, not a software problem.
Customisation requests grow while testing shrinks. Effort is going into replicating the old system instead of proving the new one.
The data "will be ready later". Migration is the most common source of go-live surprises; late data means untested data.
Status reports list screens, not flows. "Purchase configured" with no end-to-end test behind it is not progress.
The go-live date is fixed but the go/no-go criteria are not. The calendar has quietly become the decision-maker.

None of these are fatal on their own. Together, they are the reason to pause and re-plan rather than push on.

When a Short, Focused Engagement Fits

Not every company needs a long programme. A small or mid-sized business with a clear owner, standard processes and reasonably clean data can often go live on a focused scope in a matter of weeks, then extend in later phases. That is the shape of my Odoo implementation sprint: four weeks of discovery, setup, migration and testing for a business of up to about 50 users on standard apps, with go-live support afterwards. If your situation involves several companies, heavy manufacturing or a long list of integrations, the honest answer is usually a phased plan instead, and it is better to say so at the start.

Frequently Asked Questions

What is the first step in an ERP implementation?

Before choosing modules or partners, name the accountable owner and write down the business outcomes the project must deliver. Those two decisions determine scope, priorities and how you will judge success. Discovery workshops, process mapping and data planning follow from them.

How long does an ERP implementation take?

It depends mainly on scope, data quality and how quickly the business makes decisions, not on the software. A small company with standard processes and a decisive owner can move in weeks; a multi-company group with manufacturing and many integrations should plan in phases over a longer period. Be wary of any estimate given before the flows and data have been looked at.

Should we customise the ERP to match our current processes?

Only where the process is genuinely how you compete. For everything else, adapting the process to the standard is cheaper to build, safer to upgrade and easier to support. Work through configuration, maintained add-ons and process change before commissioning custom development.

Who should do the data migration?

Both sides, with different jobs. The implementer handles mapping, import tooling and validation. The business decides what migrates, cleans it at the source and signs off the results, including opening balances with the accountant. Run at least two trial migrations before the real one.

What is the most common reason ERP implementations struggle?

In my view it is unresolved ownership. When nobody has authority to settle process disagreements, decisions get reopened, requests turn into customisations, testing is squeezed and the go-live date becomes the only fixed point. Most of the other failure patterns follow from that one.

Planning an ERP project and want to test your readiness before you commit? See the Odoo implementation sprint or get in touch.

ERP Implementation: What to Settle Before You Start