How to Choose an ERP Consultancy
Short answer: who implements the ERP can matter more than which ERP you choose. The same product delivers very different results with two different teams. This article lists concrete questions to ask a consultancy and what belongs in the contract.
Why the team matters more than the product
An ERP is not plug and play. The product gives you a framework; the implementation team shapes that framework around your business. With the same ERP:
- your bill of material can be built properly or left superficial,
- cost can genuinely be calculated or appear only as stock movement,
- integrations can be observable or leave you blind at every failure.
What creates that difference is not the feature list but the team's sector experience and method.
Questions for evaluation
About the team
- How many people are assigned to us, in which roles? Are they named in the contract?
- How many projects have the assigned consultants delivered in our sector?
- What happens if the team changes mid-project? Is there a handover procedure?
- How many projects is each consultant working on simultaneously?
That last question is often the most revealing. A consultant on five projects has limited time for your bottleneck.
About method
- How is scope documented? Is a process map produced, or does configuration start immediately?
- How are acceptance criteria defined? As "the module went live", or as "this scenario produces this result"?
- Where does test data come from? Is testing done with real data?
- In data migration, what moves and who validates it?
- What is the go-live plan: big bang or phased? Is there a rollback plan?
About commercial terms
- What is the unit price and process for out-of-scope requests? (This produces the most disputes.)
- What support follows go-live, in what scope and for how long?
- Who owns the source code, configuration documents and data?
- How is knowledge transfer guaranteed when the team changes?
What belongs in the contract
These are not matters of goodwill; they must be written:
1. Scope list — item by item, each marked standard / configuration / development.
2. Acceptance criteria — testable sentences for each main process.
3. Assigned team — names, roles and a minimum person-day commitment.
4. Data migration scope — which tables, which date range, who validates.
5. Integration list — which system, which direction, what frequency.
6. Training — how many people, how many hours, for which roles.
7. Go-live criteria — the conditions without which go-live does not happen.
8. Support — response times, scope, pricing.
9. Intellectual property — ownership of configuration and custom development.
Warning signs
- A firm that quotes before analysing your processes. A price given without knowing scope changes during the project.
- A firm saying "everything is standard". No product covers every process as standard; that answer means configuration cost has been deferred past signature.
- A firm that cannot give references. Even when customer names cannot be shared, sector, scale and project scope should be describable.
- A firm promising percentages. Commitments like "we will raise stock accuracy by 30%" are meaningless without a defined measurement method.
- A team dependent on one person. If one person carries the project, it stops when they leave.
How we work
So that you can ask us the same questions, we state our own method plainly:
- Process map first. Before looking at screens we map processes and mark, item by item, what is standard and what needs configuration or development.
- Written scope and acceptance criteria. We use testable sentences instead of "went live".
- Product-independent assessment. If your existing ERP is adequate we recommend keeping it, even at the cost of losing the project.
- No unmeasured outcome commitments. We do not predict how much will improve; we state what becomes measurable.
Our detailed approach is on the [ERP consulting and development page](/en/solutions/erp-consulting). How we run product selection is in the [ERP selection guide](/en/blog/erp-selection-guide), and an honest comparison of candidates in [SAP alternatives](/en/blog/sap-alternatives).
Frequently asked questions
The vendor's own partner, or an independent consultant?
A vendor partner knows the product more deeply and has a direct channel to the manufacturer. An independent consultant can be more neutral about product choice. In practice the healthiest arrangement is separating selection advice from implementation, but that adds cost and is not necessary at every scale.
How are consultancy fees calculated?
Usually per person-day. What matters is which scope those days cover. Person-days quoted without a scope list are a wish, not an estimate.
How long does a project take?
Duration is proportional to scope. A single company with standard production and limited integrations takes a few months; multi-company, integration-heavy structures take markedly longer. When asking for a duration commitment, make sure scope is fixed too.
What happens after go-live?
That is when the real work starts. The first three months expose gaps in the rule set. Make sure support covers that period and that response times are written down.