The outcome of an ERP project does not depend on the product alone. The consultancy's process knowledge, project governance, data migration approach, development discipline and post go-live support model all affect the result directly. This article lists concrete questions to ask and what belongs in the contract.
Product and team are assessed together
An ERP is not plug and play. The product gives a framework for building processes; the implementation team shapes that framework around the business. Two teams working with the same product can produce different results:
- your bill of material can be built to match reality or stay superficial,
- cost can genuinely be calculated or appear only as stock movement,
- integrations can be observable or leave you blind at every failure.
This does not mean the product is unimportant. Product choice sets the scope and the limits; the team determines how much of it is realised within those limits. Both belong in the assessment.
Areas to assess
Sector experience
How many projects at a similar scale in your sector, and which processes were built in them. Even when customer names cannot be shared, sector, scale and scope should be describable.
Process knowledge
Whether they understand your process before showing screens. A good indicator: was the first meeting a product presentation, or a process conversation?
Technical team
Who will work on the consulting, development, integration and data sides. How many projects is the team running at once? That question is often the most revealing.
Data migration approach
Whether master data, open transactions and history are treated separately, and who validates them against which control totals.
Development method
Which platform-supported layer development happens in, and how its upgrade impact will be documented.
Integration experience
Experience on endpoints such as banks, e-documents, POS, e-commerce, WMS and the shop floor; their approach to error handling, retries and reconciliation.
Project management and governance
How scope changes are managed, the decision mechanism, progress reporting and risk tracking.
Testing and UAT
Where test data comes from, whether testing uses real data, and who runs acceptance testing.
Post go-live support
Hypercare duration, response and resolution times defined separately, and what the support scope covers.
Documentation
The scope and delivery format of process, configuration, development and integration documents.
Key-person dependency
Whether one person carries the project, whether a handover procedure exists, and the plan for developing key users.
References
Installations live in production in a similar sector, and the ability to ask project questions in the reference call.
Commercial transparency
Unit prices for out-of-scope requests, the change process, and clarity between licence and service lines.
What belongs in the contract
These are not matters of goodwill; they must be written:
- Scope list — item by item, each marked standard / configuration / development / integration.
- Acceptance criteria — testable sentences for each main process.
- Assigned team — roles, experience and a minimum person-day commitment.
- Data migration scope — which data sets, which date range, who validates.
- Integration list — which system, which direction, what frequency, what happens on failure.
- Training — how many people, how many hours, for which roles.
- Cut-over criteria — the conditions without which go-live does not happen, and the rollback plan.
- Support — scope, response and resolution times, pricing.
- Documentation and transferability — which documents are delivered, in which format.
- Data and development ownership — access rights and handover conditions at project end.
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 can mean configuration cost has been deferred past signature.
- A firm that cannot give references. Even without names, sector, scale and scope should be describable.
- A firm promising percentages without defining measurement. "We will raise stock accuracy by 30%" is meaningless without a baseline measurement.
- A team dependent on one person. If one person carries the project, it stops when they leave.
- A firm that proposes development for every request. Selling development where standard functionality or integration would do quietly grows the TCO.
How we work
So that you can ask us the same questions, we state our own method plainly:
- Process and fit-gap first. Before looking at screens we map processes and mark what is standard and what needs configuration, development or integration.
- Written scope and acceptance criteria. We use testable sentences instead of "went live".
- We do not start from a single product perspective. We work across different ERP ecosystems, and if your current system is adequate we recommend keeping it.
- We can run analysis and implementation together. We do not leave the roadmap as a report; configuration, development, integration and data migration can run under the same project umbrella.
- No unmeasured outcome commitments. We do not predict how much will improve; we state what becomes measurable.
A good ERP consultancy does not sell development for every request: where standard functionality is enough it should recommend the standard, where integration is the better answer it should recommend integration, and where replacing the ERP is unnecessary it should recommend improving the existing system.
Our detailed approach is on the ERP consulting and development page. How we run product selection is in the ERP selection guide, and a criteria-based comparison of candidates is in alternatives in the ERP ecosystem.
Frequently asked questions
The vendor's own partner, or an independent consultant?
A vendor partner knows the product more deeply and may have a direct channel to the manufacturer. Giving selection advice to a separate party can bring a different perspective on product choice, but it adds cost and is not necessary at every scale. What matters is knowing from the start who is a party to what.
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. There is a marked difference between a single company with standard production and limited integrations and a multi-company, integration-heavy scope. 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 period exposes gaps in the rule set. Make sure support covers it and that response and resolution times are written separately.
Will we become dependent on the consultancy?
That is a risk manageable through contract and method. When documentation scope, key user training, configuration records, data ownership and handover conditions are defined at the contract stage, dependency drops markedly.