Twelve questions to ask an ERP vendor

An ERP presentation is a performance, and that is not a complaint — the vendor shows what their system does best, as anyone would. The problem is that a decision about the system a company will use for ten years gets made on the strength of that ninety minutes.

The questions below were chosen by one criterion: that they cannot be answered with a slide prepared in advance. They are ordered by the stage of the conversation rather than by importance.

On scope and price

1. **What exactly is NOT in the scope of this proposal?** The answer is more informative than the list of what is. A vendor without a ready list of exclusions has either not thought about your case or does not want to write it down.
2. **How is a change that is not a defect charged?** Processes change and so does the law. It is worth knowing whether a change is a priced item, part of maintenance, or something negotiated afresh each time.
3. **What happens to the price when the user count grows by a third?** And in reverse — can it shrink. A contract that only grows penalises a company that restructures.
4. **Which part of the work is yours and which is ours?** Without a clear split by phase, your own team's hours will turn up as a surprise.

On data

1. **What does migration look like and who reconciles the opening balances?** Ask to what accuracy it is reconciled. “To the last unit” and “approximately” are two different projects.
2. **In what form do we get our data if we leave?** This is the most important question on the list and the least often asked. The answer should include format and coverage — not merely “of course you get it”.
3. **Who on your side can access our data, and under what conditions?** Support that can enter production data without approval and without a trail is a risk that stays invisible until it happens.

On regulation and localization

1. **Who maintains statutory compliance — you or a partner?** On foreign systems the answer is usually a partner, which means another vendor, another price and another upgrade cycle. That is not a flaw, but it has to be known before signing.
2. **How does the system calculate for a period when different rules applied?** Correcting last year's payroll or VAT requires the parameters that applied then. A system storing only current values forces a manual reconstruction.

On life after go-live

1. **What does an upgrade look like and what happens to our customisations?** If adaptations were made in the core, every upgrade is a project. Ask where changes live and whether an upgrade can overwrite them.
2. **What is the support response time and what is contractually defined?** Ask for a number, not a description. “We respond quickly” is not an obligation.
3. **What happens if the cutover goes wrong, and up to what moment is a return possible?** A vendor who has not considered this has planned their schedule, not your risk.

What to ask to see rather than hear

Alongside the questions go three requests that turn a demo from a performance into a check.

• **Your data, not theirs.** Send a few of your own items, partners and one messy supplier invoice in advance. A system running on a prepared sample proves nothing.
• **One flow end to end.** Not by module — from order to payment, through every step, including the one where something goes wrong.
• **The exceptions screen.** Ask to see what the system does when it is not sure. That is the one part of the software never shown in a sales meeting and used every day in operation.

One closing note: ask us these questions too. A list tailored so that only one system passes would serve neither you nor us — and it would be recognisable on first reading.