ERP Demo & Vendor Evaluation Checklist: What to Ask Vendors to Show

On this page

• Demo is not a product tour
• What must be proved
• Same script for everyone
• Realistic data, safely
• How is it delivered?
• Scenario anatomy
• Test the exception
• Follow it into Finance
• Controls and auditability
• Integration failure
• Reporting from the demo
• One signature workflow
• Reproducing what you saw
• Record evidence
• Gates before scores
• Score independently
• Set weights first
• Score is not the decision
• Product vs delivery fit
• Unresolved claims
• Reference validation
• Proof closest to risk
• Demo, scope and price
• Final evidence pack
• Evaluation red flags
• Demonstration script
• Evidence record
• How exactllyERP fits
• Evaluation checklist
• Go deeper

The data is clean. The user knows exactly where to click. The difficult exception does not occur. The integration is available. The report has already been designed.

A good ERP demonstration should leave the buying team with evidence about:

• what worked;
• what did not;
• what is standard;
• what needs configuration;
• what depends on an extension or another product;
• what requires development;
• what still needs proving;
• what the implementation will require.

That is very different from leaving the meeting saying:

“The demo looked impressive.”

An ERP demo is not a product tour

The vendor may naturally want to show:

• dashboards;
• menus;
• features;
• automation;
• mobile screens;
• new technology.

Some of that is useful.

But none of it proves your critical operating workflow.

Instead, begin with situations your organisation must be able to handle.

For example:

Now the software has something to prove.

Decide what must be proved before vendors arrive

Do not write the demo script after seeing Vendor A.

And do not let Vendor B choose a completely different demonstration because its strengths happen to lie somewhere else.

Before the first vendor arrives, classify requirements.

Do not waste demonstration time watching someone prove that a standard field exists if the real buying risk is elsewhere.

Give every vendor the same script

Fair comparison requires comparable evidence.

Give shortlisted vendors:

• the same business scenarios;
• the same assumptions;
• the same representative data;
• the same difficult exceptions;
• the same reports to produce;
• the same evidence questions.

They do not need to demonstrate everything in exactly the same way.

Different ERP architectures may solve the same business problem differently.

That is useful information.

But they should be solving the same problem.

Use realistic data without creating a data-security problem

Buyer data makes a demonstration more useful.

That does not mean handing a sales team your entire production database.

Use enough realism to expose the process.

Depending on the scenario, that might include:

• representative items;
• customer terms;
• approval levels;
• warehouse structure;
• units of measure;
• sample BOM;
• reporting dimensions;
• realistic transaction quantities.

Where actual records contain confidential, personal or commercially sensitive information, use:

• de-identified records;
• representative substitutes;
• synthetic examples that preserve the difficult operating condition.

Before uploading any actual company data into a vendor environment, understand where it will go, who can access it and what happens afterwards.

Make the vendor identify exactly what you are seeing

After every important demonstration step, ask:

How is this capability being delivered?

Use a consistent classification.

The important distinction is not:

Test integrations when something goes wrong

A successful integration message proves only the successful path.

Introduce failure.

For example:

Then ask:

• How does the user know?
• Is processing blocked or queued?
• Can the transaction be retried?
• How is duplicate processing prevented?
• Who monitors the failure?
• What information is logged?
• How does recovery happen?
• How do the two systems reconcile afterwards?

Make management reporting part of the demo

Do not accept a beautiful dashboard that has no relationship to the transactions you have just watched.

Ask the vendor to:

1. enter or process the agreed demonstration transactions;
2. open the management report or dashboard;
3. show the result;
4. drill back towards the originating records where appropriate.

Then change something.

Process an exception.

Reverse a transaction.

Approve something.

Ask:

What does management now see?

This tests whether reporting is connected to the operating record rather than existing as an isolated presentation layer.

Test one signature workflow your industry depends on

Every ERP buyer has common requirements.

Finance. Purchasing. Sales. Inventory. Reporting.

Those do not tell you everything about industry fit.

Choose at least one workflow where your industry becomes operationally distinctive.

The purpose is not to ask:

“Do you have an industry edition?”

It is to ask:

“Can your proposed solution carry this business object and its consequences through the process?”

The detailed industry scenarios belong in the relevant industry evaluation.

For the general method, use the same discipline:

1. trigger
2. →difficult workflow
3. →exception
4. →control
5. →downstream result
6. →evidence

Ask what it takes to reproduce what you just saw

A demonstration can prove that something is possible.

It does not automatically prove what it takes to implement.

After an important scenario, ask:

What has to exist for us to reproduce exactly what you just showed?

Record:

• product/module;
• configuration;
• master data;
• roles;
• integration;
• third-party product;
• extension;
• custom development;
• licence;
• infrastructure/environment;
• implementation service;
• manual step;
• buyer-side responsibility.

Then ask:

This is where Guide 6 connects directly with the pricing and implementation guides.

Evaluate the product and implementation partner separately

A strong ERP product can be poorly implemented.

A strong implementation team cannot manufacture missing product capability without consequences.

If a partner will implement the system, evaluate two things.

Do not let a strong salesperson substitute for either.

And do not assume the senior people in the demonstration are automatically the people who will implement the project.

Ask:

Turn every unresolved claim into a follow-up item

During a demo you will hear phrases such as:

Do not argue.

Record the claim.

Classify the evidence still required.

For example:

• live demonstration;
• screenshot/documentation;
• architecture note;
• implementation estimate;
• commercial clarification;
• reference validation;
• contractual confirmation.

Give it:

• an owner;
• due date;
• decision impact.

Then leave the item unproven until the evidence arrives.

Use customer references to validate specific claims

Do not begin a reference call by asking:

“Are you happy with the ERP?”

You will learn very little.

Instead, choose the claim you need to test.

For example:

A relevant reference is not simply a company in the same industry.

It is a customer whose experience reduces uncertainty about the decision you are making.

Ask for the evidence closest to your actual risk

Suppose you are evaluating batch traceability.

A famous customer logo tells you very little.

Ask:

Which customer actually uses the traceability workflow you demonstrated?

If your concern is a multi-location operation:

Which customer gives us evidence closest to that operating structure?

If your risk is integration:

Which customer uses the connected system or integration pattern closest to ours?

Reconcile the demo with scope, price and implementation

A demonstration creates obligations for the rest of the evaluation.

If a vendor demonstrated:

• an extension;
• a third-party component;
• a custom workflow;
• an integration;
• a special report;
• an additional environment;

ask whether it appears in:

The demonstrated solution and the contracted solution should not quietly become different systems.

Build the final ERP evaluation evidence pack

Before the final decision, consolidate the evidence.

For each major requirement or scenario, the decision team should be able to see:

This is the record that should support the recommendation.

Not a collection of vendor brochures.

How exactllyERP fits into this evaluation

ERP demo & vendor evaluation checklist