How to Evaluate ERP Software in a Demo. Test real business tasks and the exceptions that matter.
An ERP demonstration becomes useful selection evidence when evaluators can follow a business event from its starting conditions to a reconciled outcome, including the exception that makes the work difficult. Watching someone navigate screens is only part of that proof.
Build the session around a small number of consequential scenarios. Give each scenario a defined start, participating roles, an exception, expected outputs, and a record of what remains unproven. That structure helps evaluators separate a capability they observed from a delivery promise they still need to investigate.
Use the proof-test pack below to answer a specific selection question. It cannot replace implementation testing, security assessment, or operational acceptance in the environment the business will actually use.
Choose the decision before writing the script
Begin with the uncertainty that could change the selection. For example: can an order remain understandable when fulfillment, invoicing, and cancellation happen at different times? Can a reviewer identify and recover a failed handoff? Can the business enforce an important approval without depending on a specialist to intervene?
Those questions are more useful than a request to “show order management.” They establish what the session must prove and help contain the agenda.
Choose scenarios using three lenses:
- Consequence: failure would materially affect an important operation or control.
- Uncertainty: existing evidence does not establish how the proposed approach handles it.
- Decision value: the answer could change the shortlist, scope, cost assumption, or delivery plan.
A high-volume routine transaction may deserve attention because small amounts of friction accumulate. A rare exception may deserve attention because its consequences are hard to reverse. The selection team should explain why each scenario is in the pack instead of filling time with every requirement it collected.
Give routine coverage a separate checklist. A proof-test session has limited capacity; it should concentrate observation where it changes a decision.
Build the test around an observable business story
Consider a hypothetical distributor selling replacement components. A customer orders ten units. Six are dispatched, four remain open, and the customer later cancels the remaining quantity. The demonstration must show that fulfillment, invoicing, open demand, and the customer-facing status remain consistent.
The numbers are illustrative test data, not operating benchmarks. The business would replace them with cases that reflect its actual rules, including whether invoicing occurs at dispatch, delivery, or another approved event.
The ordinary flow alone is insufficient. Add a deliberate repeat of the same dispatch message, using the same event identifier. Evaluators need to understand whether the integration recognizes a duplicate, creates another business effect, or relies on an operator to resolve it.
The script should specify the required outcome without dictating every click. Different designs can achieve the same business result. Requiring an exact imitation of the current interface can conceal a simpler approach; accepting a different business outcome can conceal a gap. The facilitator keeps that boundary clear.
Use this proof-test pack
Complete the following fields before inviting a demonstration team to prepare.
Decision question
- What uncertainty are we resolving? ______
- Which requirement IDs and release scope does it affect? ______
- What finding would change our recommendation? ______
Starting conditions
- Synthetic customer, item, order, and reference identifiers: ______
- Opening quantities, balances, statuses, and relevant dates: ______
- Pricing, approval, accounting, and fulfillment rules assumed: ______
- Available stock, reservations, and open transactions: ______
- Which external systems are real, simulated, or absent? ______
People and access
- Roles executing each step and the permissions they should have: ______
- Evaluators responsible for process, control, integration, and reporting observations: ______
- Facilitator, evidence recorder, and business decision owner: ______
Execution and proof
- Normal event sequence: ______
- Exception to introduce and the point where it occurs: ______
- Expected recovery route and prohibited outcomes: ______
- Required documents, statuses, balances, logs, and reports: ______
- Evidence to retain and permitted recording arrangements: ______
- Follow-up owner and decision date for anything not shown: ______
Use synthetic data wherever it can represent the problem. Real customer details, employee information, pricing, and transaction records introduce confidentiality and access considerations. If actual data is necessary, obtain the appropriate authorization and agree what may be shared, retained, and removed.
Agree what has been prepared
Before the session, ask the demonstration team to declare the environment, relevant configuration, additional components, and integrations used. Record which elements are available in the proposed commercial scope and which would need further work.
Preparation is legitimate. A well-prepared environment can make a demonstration far more informative. The important question is what the preparation tells you about the future implementation.
For example, a preconfigured approval rule might be straightforward to reproduce, or it might rely on a separate component and a complex maintenance process. A document generated in advance may illustrate a desired output, but it does not prove the transaction produced it. A simulated external response can help isolate one process, but it leaves the real interface untested.
Ask the team to identify these boundaries openly. Make “not shown in this session” an acceptable response. A process that rewards confident answers over accurate boundaries produces a less useful record.
Observe the handoffs as carefully as the screens
During execution, the evidence recorder follows the business identifiers through each step. When the partial dispatch occurs, evaluators should be able to connect the order line, dispatch event, remaining quantity, invoice basis, and customer-facing status.
Use the relevant business roles where practical. If a presenter uses broad administrative access for convenience, record that limitation and schedule a role-based follow-up. A process completed with exceptional permissions does not establish that ordinary users can perform their work, or that restricted actions remain restricted.
At each handoff, ask:
- What tells the next person there is work to do?
- What information travels with it, and which identifier connects the records?
- How does the receiving step acknowledge acceptance or rejection?
- Who sees a failure, and who is allowed to correct it?
- What evidence shows that the correction did not create an additional effect?
Allow evaluators to note questions without interrupting every action. The facilitator can pause at meaningful checkpoints so the group sees a coherent process while still investigating important uncertainty.
Make recovery visible
In the hypothetical duplicate-dispatch case, a message may be rejected before posting, accepted without producing a second business effect, or handled through an exception process. The organization needs to understand the behavior and decide whether it fits its control and service requirements.
Ask to see the original message identifier, the repeated submission, the receiving status, and the resulting transaction quantities. Then inspect the exception or audit record. A reassuring statement that duplicates are “handled” is not enough to determine what an operator would actually do.
If recovery requires correction, observe the supported correction route. Record who can perform it, what authorization is needed, and how the affected records remain connected. Do not encourage undocumented direct data edits merely to make the scenario finish.
After cancellation of the remaining four units, reconcile the illustrative quantities: ten originally ordered, six fulfilled, four canceled, and none still open. Also examine the relevant invoice and inventory effects under the scenario’s stated rules. Quantity agreement alone does not prove that every financial consequence is correct.
Record evidence status without overstating it
Use four plain-language statuses for each material claim:
Observed. The evaluators saw the required behavior in this session, under recorded conditions.
Repeated. The behavior was executed again under a documented repeat or variation, with a consistent result. State what changed; do not imply that a second run establishes performance at scale.
Proposed. The team described how configuration, development, integration, or an additional component would meet the need, but the complete behavior was not observed.
Not verified. The session did not provide enough evidence to assess the claim, including cases skipped because of time or environment limitations.
Keep these statuses separate from the delivery route. A custom component can be observed today and still carry implementation and support questions. A capability described as standard can remain unverified. Neither label alone establishes fit.
For each observation, capture the scenario version, environment, role, data identifiers, outcome, and evidence reference. Record the scope of the evidence as well as the result. “Approval route observed for one location with a single approver” is more useful than “workflow passed.”
Close the gaps before they disappear into a score
At the end of the session, review the unresolved evidence with the demonstration team and the business owner. Separate three types of follow-up.
A clarification explains something already shown, such as the meaning of a status. A repeat proof executes an omitted or disputed behavior. A delivery commitment concerns work that remains to be designed, built, licensed, or agreed commercially.
Give each follow-up an owner, required evidence, and decision date. The selection lead should know which open items block a recommendation and which can proceed as explicit conditions. Avoid marking an item resolved merely because a written answer arrived.
If a follow-up changes the scenario, preserve the previous version and explain why. Material new information should be shared consistently across comparable evaluations. Otherwise, one candidate may be assessed against an easier problem simply because it presented earlier.
Know what a strong demonstration still cannot prove
A controlled session usually leaves questions about production volumes, migrated data, real integrations, complete role permissions, recovery procedures, and user readiness. List those boundaries in the selection record. Carry the relevant scenarios into later testing rather than treating selection evidence as final acceptance.
The immediate deliverable is modest but valuable: a clear account of what worked, under which conditions, what did not work, and what must be established next. Before the next demonstration, choose one consequential exception and write its expected end state. That single change gives the evaluation a more useful purpose than another tour of features.
