You have decided to implement (or replace) an ERP.
You are comparing 3 integrators.
And you have a very common problem: their proposals all look the same.
They all promise:
- a “methodology”
- “workshops”
- a “fast go-live”
- “best practices”
Except that… what makes an ERP project succeed is not visible in polished slide decks.
And if you are not an ERP expert, it is perfectly normal to feel a bit “exposed” when it comes time to choose.
The goal of this article: give you a simple 100-point grid to compare 3 integrators based on concrete evidence, not marketing.
The real risk: not the tool… the project
An ERP project that goes off the rails is expensive. Often in three ways:
- financially (extra days, rework, added options)
- in time (6 months → 12-18 months)
- in energy (demotivated teams, low adoption, “the ERP is useless”)
In most cases, the problem is not “the ERP.”
It is:
- a vague scope (“we’ll see later”)
- poorly prepared data
- unclear interfaces (e-commerce, CRM, accounting, BI…)
- absent governance (who decides? when?)
- uncontrolled changes that blow up the budget
The solution: a scoring grid (no jargon)
The principle is simple:
- you ask the same deliverables from all 3 integrators,
- you rate each criterion from 0 to 5,
- you get a score out of 100.
And most importantly: you spot the red flags (deal-breakers).
How to score (0 to 5)
- 0: absent / refused / vague
- 1: very insufficient
- 2: partial / generic
- 3: acceptable / standard
- 4: solid / tailored to your context
- 5: excellent + proven (examples, documents, references)
Calculating points
For each line:
Points = weight × (score / 5)
Example: weight 12, score 4 → 12 × (4/5) = 9.6 pts
The grid (100 points)
Tip: do not debate “opinions.” Ask for evidence.
A good integrator can show sample deliverables, a named team, and a realistic timeline.
| # | Criterion (plain language) | Weight | What you should ask for (evidence) |
|---|---|---|---|
| 1 | Have they understood your needs? | 10 | A written reformulation + what is included / excluded + risks |
| 2 | Have they done a similar project before? | 10 | 2-3 comparable references + facts (duration, team, challenges, outcome) |
| 3 | How will the project be governed? | 12 | Who decides what (RACI) + meetings (steering/operational committees) + deliverables per phase |
| 4 | Who will actually work on your project? | 12 | Names + roles + availability (%) + senior presence + backup plan |
| 5 | Is the timeline realistic? | 10 | Clear milestones + dependencies + client-side workload + safety buffers |
| 6 | How do they handle your data (the point that breaks everything)? | 10 | Staged migration plan + cleansing + rehearsals before cutover |
| 7 | How do they handle connections with your tools? | 10 | Interface list + who is responsible + security + monitoring |
| 8 | How do we avoid bugs in production? | 8 | Test plan + business scenarios + acceptance criteria + documentation |
| 9 | How will your teams learn and adopt? | 8 | Role-based training plan + key users + materials + adoption strategy |
| 10 | Is the pricing clear (and the total cost)? | 10 | Readable quote + assumptions + options + fixed-price vs T&M + support + exit |
The “deal-breakers” (if the answer is NO = stop or heavy penalty)
These 4 points are your safety net:
-
They refuse to provide written assumptions + exclusions
→ you will discover the “surprises” along the way. -
Impossible to identify the actual team (who does what, when)
→ risk of “senior seller / junior delivery team.” -
Data is handled “at the end” with no staged plan
→ risky cutover, delays, and rollbacks. -
No comparable, verifiable reference (client call)
→ plenty of promises, little proof.
8 Simple Questions to Ask (Even If You Are Not Technical)
Copy and paste these into your next meeting:
- “Can you give me your assumptions and exclusions (in writing)?”
- “Who will be the project manager and who will be the senior lead? Their availability (%)?”
- “Show me a timeline with milestones and what we need to provide on the client side.”
- “Walk me through your data plan: how do we avoid disaster at cutover?”
- “What integrations need to be planned with our tools? Who does what?”
- “How do you manage changes (out-of-scope requests) and the budget impact?”
- “How do you validate that ‘it works’ before going live (testing/acceptance)?”
- “After go-live, what does support look like (SLA, response times, cost, exit)?”
Conclusion: You Don’t Need to Be an ERP Expert
You do not need to know the modules, the APIs, or the acronyms.
You just need one rule:
Don’t choose based on the pitch. Choose based on the evidence.
A clear proposal, an identifiable team, a serious data plan, solid governance…
That is what makes the difference between a project under control and one that derails.
