What an ERP consultation should actually produce

Most ERP consultations are free, which tells you what they are: a qualified sales conversation with a proposal at the end.

That is not dishonest, and a good one is genuinely useful. But it is worth knowing the difference between a consultation that sells and one that produces something you own.

The test

Could you hand the output to a different vendor and get a comparable quote?

If yes, you have a requirement document. If no — if it only makes sense as an argument for one product — you have a proposal wearing a consultation's clothes.

Both have their place. Only one lets you compare.

What a real consultation leaves behind

A process map of how you work now

Not how you should work. How you actually do, including the workarounds, the parallel registers and the steps that exist because of something that happened in 2019.

If nobody spent time watching your operation, whatever comes next is generic.

A gap list

Where the standard product does what you need, where configuration closes the difference, and where genuine development would be required. Three categories, and the third should be short.

A consultation claiming everything is covered out of the box has not looked hard enough. One claiming everything needs development is quoting a project it wants to sell.

Phases with a first phase that stands alone

A sequence where the first phase delivers something usable by itself. If phase one only makes sense once phase three arrives, you have been sold a whole project described as stages.

An effort estimate you can interrogate

Days by activity — configuration, migration, training, testing, support. Not a single figure.

A number you cannot break down is a number you cannot check, and it is where scope disputes start.

What is required from you

Whose time, how much, and when. Data cleaning, decisions, testing, training attendance.

This is the section most often missing and most often the reason projects slip. A vendor who has not told you what they need from you has not planned the project.

Warning signs

• A demo before anyone asked how you operate
• Pricing quoted before scope is described
• Every requirement met with "yes, we can do that" and no discussion of how
• No mention of what happens after go-live
• Reluctance to name which parts are standard and which are custom

The third is the most common. Enthusiastic agreement with everything means the difficult questions have been deferred to implementation, when they become change requests.

Questions worth asking

1. Which of our requirements are standard, which are configuration, and which need development?
2. What would you recommend we not do in phase one?
3. Which similar business have you implemented this for, and can we speak to them?
4. What typically goes wrong in projects like ours?
5. What do you need from us, and when?

Question two is the most revealing. A consultant who cannot name anything to defer is not advising, they are quoting.

Paying for it

A paid requirement study is worth considering where the project is significant. It changes the relationship — the output belongs to you, it can be used to get comparable quotes, and the consultant is being paid to think rather than to win.

For a small implementation the free consultation is usually proportionate. For anything substantial, the cost of a proper study is small against the cost of choosing wrong.

If you want a study that produces something you can take to any vendor, see how we run ERP consultation or talk to us.