What an ERP Consultant Does

The Short Answer

An ERP implementation consultant turns the way your business actually operates into a working ERP system and a team that can run it. The real job is making and recording decisions: which processes change, which data moves, what "done" means, and when you are safe to go live. Configuration is the smallest part. A good consultant leaves you with written decisions, tested workflows and people who can use the system without phoning them. A weak one leaves you with a configured database that only they understand.

That definition is broader than most job descriptions. Most describe the role as "configure the modules, migrate the data, train the users". Those tasks are real, but they are what the consultant produces. What you are paying for is judgement about your processes and the discipline to write that judgement down. The rest of this post breaks the role into what happens in each phase, what you should expect to receive, and how to tell early whether the person you hired is doing the job.

The Role Next to Its Neighbours

The same title covers several different jobs. When a proposal says "consultant", it helps to know which of these you are actually getting:

Implementation (functional) consultant — owns process design, configuration decisions, testing and training. Produces a decision log, a configured system, test scripts and trained users. Not their job: writing custom code or running your business.
Technical consultant / developer — owns custom modules, integrations and data migration scripts. Produces version-controlled code, migration scripts and integration tests. Not their job: deciding how your sales process should work.
Project manager — owns the plan, timeline, budget and risks. Produces the plan, status reports and a risk register. Not their job: knowing the right accounting configuration.
Solution architect — owns how the ERP fits with every other system. Produces an integration map and data ownership rules. Not their job: configuring individual screens.
Your internal project owner — owns business decisions and sign-off. Produces approved decisions and available staff. This role cannot be outsourced.

On a small project one person often wears the first four roles. That is fine, as long as you know it and the work of each hat still gets done. The last item is the one that most often goes missing. No consultant can replace an internal owner who has the authority to say "yes, we will change how purchasing approves orders".

What the Consultant Does, Phase by Phase

1. Discovery: learning how the business really works

The consultant's first job is to find out how work actually moves through your company. What is written in the process manual matters less. In practice that means sitting with the people who raise orders, receive stock, issue invoices and close the month, and following a real transaction from end to end.

What a good consultant produces here:

A process map for each core flow — quote to cash, procure to pay, stock movement, month-end close — including the exceptions (partial deliveries, returns, credit notes, the customer who pays in two currencies).
A requirements list tagged by necessity. Legal and tax requirements, operational must-haves and preferences are different things and should be labelled differently.
A list of the data you will need to move, with an honest note on its quality.

The key skill in discovery is asking "why" until the answer is a real business reason. Plenty of the processes people describe are workarounds for the limits of their old system. Rebuilding those workarounds in a new ERP is the most expensive mistake available at this stage. What that looks like in practice is covered in Odoo implementation mistakes to avoid.

2. Fit-gap: deciding what changes

For every requirement the consultant decides whether standard features cover it, configuration covers it, or it genuinely needs custom work. Then they tell you plainly which of your processes should change to fit the standard.

This is where consultants differ most. A consultant who says yes to everything is easy to work with in month one and very costly for every year after, because each customisation has to be ported on every upgrade. A consultant who pushes back with reasons ("the standard approval flow does this; your three-step manual sign-off exists because the old system had no approval flow") is doing the job.

The output you should expect is a fit-gap document: each requirement, how it will be met, and who decided. If a customisation is approved, the reason is written next to it.

3. Design and configuration: building to the decisions

Only now does configuration start: company structure, chart of accounts, taxes, warehouses, routes, pricelists, approval rules, user roles. The consultant configures to the fit-gap decisions and records anything that was not obvious. For example: why two warehouses rather than one with locations, or why a particular invoicing policy.

Two habits separate careful consultants here:

They configure in a staging environment and promote changes deliberately. They never experiment on a live database.
They keep a configuration log. Six months after go-live, someone will ask why a setting is the way it is. The answer should be in a document, not in the consultant's memory.

4. Data migration: moving what matters, cleanly

The consultant decides what moves and how clean it has to be. Migration scripts may be written by a technical colleague. Typical decisions:

Open balances and open documents move. Full transaction history often stays in the old system as a read-only archive.
Master data (customers, suppliers, products) gets deduplicated and cleaned before import, by the people who own it.
Every migration is rehearsed on a copy, with before-and-after checks on record counts and balances, before it runs for real.

A consultant who treats migration as "we'll import the spreadsheets the week before go-live" is taking a risk with your books. A trial migration with a reconciliation you can read is the minimum.

5. Testing: proving the system works on your real work

User acceptance testing (UAT) is where the consultant proves the design against reality. They write test scripts based on your actual transactions, including the awkward ones: cancellations, refunds, back-orders, month-end close. Then the people who will use the system every day run those scripts. Managers watching a demo is not testing.

The consultant's job is to run testing well and report on it honestly: what passed, what failed, what was fixed, and what is still open with a workaround. That report is the basis for the go/no-go decision.

6. Training and documentation: making themselves unnecessary

Good training is role-based. Warehouse staff learn receiving and picking on their own screens with their own products; they do not sit through a tour of every module. The consultant also leaves short written procedures for tasks that are rare but important, such as year-end steps, adding a new tax or onboarding a new user.

I think the best test of a consultant is how little you need them three months after go-live. If every small question still needs them, the knowledge transfer did not happen.

7. Go-live and hypercare: the cutover and the first weeks

The consultant plans the cutover: when the old system freezes, when the final migration runs, who checks what, and what the rollback plan is if a check fails. After go-live comes a period of close support ("hypercare"). Issues get fixed fast, and the patterns in them show where training or configuration needs another pass.

Hypercare should have an end date and a handover: to your internal owner, to a support arrangement, or both.

What You Should Receive — a Checklist

Whoever you hire, these are the artefacts that show the role was actually performed. Ask for them by name in the proposal.

Process maps for each core flow, including exceptions
Requirements list, tagged legal / operational / preference
Fit-gap document with a decision and an owner for every requirement
Configuration log (what was set, and why when it was not obvious)
Data migration plan, trial-run results and reconciliation
UAT scripts and a written results report
Role-based training material and short procedures for rare tasks
Cutover plan with named checks and a rollback path
A handover document for whoever supports the system afterwards

If a proposal lists only "configuration, migration, training", ask where the decisions will be written down. The answer tells you a lot.

How to Tell If Your Consultant Is Doing the Job

Good signs

They ask to see real transactions early: last month's invoices, a messy return, the spreadsheet everyone secretly relies on.
They say no, with reasons. Every "no" comes with the standard alternative and what it saves you.
They put decisions in writing and ask you to confirm them. It feels bureaucratic in week two and saves arguments in month six.
They insist on an internal owner and will not start design without one.
They talk about upgrades before go-live. Anyone thinking about the second year of the system is thinking about your total cost.

Warning signs

Configuration starts before discovery ends. Screens appear quickly and look like progress. In reality they are guesses.
Every request is accepted. Customisation count grows and nobody can say which items are legal requirements and which are habits.
No staging environment, or changes made directly on the live database "because it's faster".
Testing is a demo. The consultant clicks, stakeholders nod, nobody from the warehouse or accounts has run their own transactions.
Knowledge lives in one head. You cannot find out why something is configured a certain way without asking the consultant.

None of these are dramatic on their own, and each is visible in the first few weeks. That is the time to raise them, while changing course is still cheap.

Consultant, In-House, or Both?

You do not always need a full-time consultant for the whole project. What I recommend depends on three questions:

Do you have someone internally with the time and authority to own it? If not, fix that first. A consultant cannot make your business decisions for you.
How far are your processes from the ERP's standard? Close to standard means shorter, focused help. Far from standard (manufacturing, multi-company, regulated accounting) means you need senior judgement throughout.
Is there a migration or integration? Moving years of data or connecting marketplaces and e-commerce is where do-it-yourself projects most often stall, and where targeted expert time pays back.

Whatever you decide, settle the scope, data and ownership questions first; the pillar post on what to settle before an ERP implementation starts walks through them.

For small and mid-sized businesses with standard processes, a short, time-boxed engagement often works better than a long open-ended one. Discovery, fit-gap, configuration, migration, testing and go-live run back to back, with one senior person accountable for all of them. That is the shape of my Odoo implementation sprint: four weeks from discovery to go-live, followed by two weeks of post-launch support, rather than an indefinite retainer. It is built for businesses of up to about 50 users on standard apps, so it is not the right shape for every project. Complex multi-company or manufacturing setups need a longer plan. But whatever format you choose, the role should include every phase above.

If you are comparing the kinds of people who can fill this role, I compare the options for the Odoo market in freelancer vs agency vs partner.

Questions to Ask Before You Hire One

Use these in the first call. The answers matter less than whether the consultant has clearly thought about them before:

Who, by name, will do the discovery and the configuration? Will that person stay for the whole project?
What will you hand over at the end of discovery, and what does a fit-gap document look like from you?
How do you decide whether a requirement gets customised?
Where do you configure: staging or live? How are changes promoted?
How will you prove the data migration is complete and correct?
Who writes the UAT scripts and who runs them?
What happens in the first weeks after go-live, and when does your support end?
If we stop working together, what documentation will let someone else take over?

Frequently Asked Questions

What is the difference between an ERP consultant and an ERP developer?

An ERP consultant decides how the system should support your processes: requirements, fit-gap, configuration, testing and training. A developer writes the custom code, integrations and migration scripts that the consultant's decisions call for. On small projects one person may do both. The two skills are still different, and a project needs both to be covered.

Do I need an ERP implementation consultant for a small business?

Not always. If your processes are close to the ERP's standard, you have few users and an internal person can own the project, you can implement the core yourself. Bring in targeted help for the three areas where do-it-yourself projects usually stall: accounting and tax setup, data migration, and integrations with other systems.

How long is an ERP consultant involved in a project?

It depends on scope. The involvement should always cover discovery, fit-gap, configuration, migration, testing, training, go-live and a defined support period afterwards. Focused projects with standard processes can run in weeks. Multi-company, manufacturing or heavily integrated projects take longer. What matters is that every phase has a written output and the engagement has a clear end.

What documents should an ERP consultant give me?

At minimum: process maps, a requirements list, a fit-gap document with decisions and owners, a configuration log, a data migration plan with reconciliation results, UAT scripts and results, training material, a cutover plan and a handover document. If these do not exist at the end, the knowledge stays with the consultant, not with your company.

How do I know if my ERP consultant is not doing a good job?

Watch for configuration starting before discovery is finished, every request being accepted without pushback, changes made directly on the live system, testing that is only a demo, and decisions that exist only in the consultant's head. Each of these shows up in the first few weeks, when changing course is still cheap.

What an ERP Implementation Consultant Actually Does