How do I compare ERP offers that are structured completely differently?

ERP offers become comparable once you break them down into four blocks: licences, one-off services, running costs and internal effort. After that, check the assumptions behind the effort, above all the number of interfaces, customisations and migration runs. Only those assumptions make the difference visible. Two offers with the same total can describe different projects.

What sits behind the cost blocks: What does a Business Central implementation really cost?

If you want a specific offer reviewed: senior-led second opinion

Step one: reduce everything to four blocks

The first step is mechanical. Take every offer and assign each line to one of four blocks: licence costs, one-off services, running costs after go-live, and the internal effort of your own team. The last block appears in no offer but belongs in the comparison, because it arises for real.

That step alone brings clarity. It frequently turns out that one offer contains items another silently assumes, such as data migration or user training. An offer without those items is not cheaper, it is incomplete.

Also convert all offers to the same period. Licence costs recur, services are one-off. A comparison over five years shows a different picture than a comparison over the implementation year, and five years is the more realistic view.

Step two: make the assumptions visible

The real difference between two offers almost never lies in the daily rate but in the amount of assumed work. So ask about the assumptions behind each block of effort: how many interfaces are costed and to which systems? How many customisations to the standard? How many test migrations? How many days of support after go-live?

Those numbers make two offers comparable at once. An offer assuming two interfaces and one test migration describes a different project than one with five interfaces and three migration runs, even if both quote the same total.

Also ask what happens if an assumption does not hold. A sound offer describes the change process: who determines that additional effort arises, who approves it and on what terms. Without that, you negotiate later under time pressure.

How to recognise an over-optimistic calculation

There are recurring signs. The first is a strikingly short concept phase. If clarifying the processes is costed at a few days, the clarification work is not saved but pushed into the implementation phase, where it is more expensive and puts the deadline at risk.

The second sign is data migration as a lump sum without stated test runs. In most companies master data is not in the state a lump sum assumes, and the rounds that then become necessary appear nowhere.

The third is missing support after go-live. The first weeks in live operation are the moment when users have questions and errors surface. An offer without that phase shifts the effort into your operation, where it arises as lost productivity rather than as an invoice item.

Which questions to ask in a first meeting

Four questions yield more insight in a first meeting than a long presentation. First: which three things will probably be difficult in our project? An experienced provider can name them after one conversation. Anyone who sees only opportunities either did not listen or is selling.

Second: who from your team actually works with us, and for what share of their time? The difference between the person in the sales meeting and the people in the project is one of the most common causes of disappointment.

Third: what share of our requirements does the standard cover without customisation? Fourth: what must we have completed by the project start? Anyone who answers the last question concretely has a realistic picture of the project. Anyone who avoids it is costing clarification work nobody has done yet.