Manufacturing ERP Features: What to Verify in a Demo

Verify manufacturing ERP features by supplying an input, performing an action and checking the resulting record, including what happens when something goes wrong. “BOM management” on a slide does not tell your planner what happens to a released job when a drawing changes.

Write each requirement as a task. Ask the vendor to perform it on sample data from your factory and keep the record IDs, screenshots or exported results. Use a copy of real data with private customer and supplier details removed.

Start with the handoff that fails

Select one order that passes through sales, stores, production, quality and dispatch. Name the person who accepts each handoff. For a batch manufacturer, that may mean lot status and yield. For a job shop, it may mean drawing revision, customer material and outside processing. The matrix below is an original buyer worksheet; it is not a claim that every ERP, or Optiwise, supplies every behavior without configuration.

Check the record, then test the exception

A successful normal transaction is only one result. Change the quantity, use a wrong unit, omit a required drawing or interrupt the handoff. Ask how the user sees the error and who can correct it. Avoid running fault tests against a live customer account.

For stock tests, agree the location, unit and cutoff time before comparing balances. In the example above, 90 received equals 82 accepted plus 8 rejected; the 10 never delivered are a separate supplier obligation. Mixing rejection with shortage hides the action needed.

ERPNext's BOM documentation gives a concrete example of structured materials and operations. Its stock reconciliation documentation identifies item, warehouse and posting time. Use these as examples of records to inspect, then verify the actual system and version offered to you.

Separate standard behavior from implementation work

Give each test one status: demonstrated, configuration required, custom development required, third-party dependency, or not established. Ask the vendor to put the relevant plan/version, delivery owner, price and acceptance date beside unfinished work. A checkbox labelled “available” hides those distinctions.

Run operator tasks on the intended phone, tablet or shared workstation. Check text size, the steps needed to correct an error and the effect of losing connectivity. Offline support, attachment limits and device compatibility should be demonstrated where they are requirements.

Use the ERP selection guide to build the shortlist, then use this matrix for the deeper evaluation. For an Optiwise production walkthrough, request the same tests and keep unverified requirements on the gap list.

Sign off with the people who operate the workflow

The planner should approve planning outputs, stores should reconcile quantities, quality should approve release rules and finance should approve accounting results. Keep a copy of the tested data and expected outputs. Repeat the failed tests after configuration changes before accepting that part of the implementation.

Questions from manufacturing teams

Which manufacturing ERP features should I test first?

Start with BOMs, material availability, work orders, stock movements and the handoffs that currently cause errors. Add traceability, outsourcing, quality and accounting tests according to your process.

Does a feature listed on a vendor website count as verified?

It is a starting point for a question. Verification requires seeing the relevant behavior in the proposed version and configuration, with records you can inspect.

Who should approve an ERP demo?

The people responsible for the records should approve their part: planning, stores, production, quality and finance. Keep unresolved requirements assigned to an owner.