A better demonstration script for food manufacturing ERP
Most ERP demonstrations can receive ingredients and dispatch finished goods. The more revealing question is what happens when an ingredient changes, a batch is split or a stock hold arrives after allocation. For a food manufacturer, those events determine whether the system can explain how a product was made and where it went.
Ask vendors to demonstrate the awkward transactions in the proposed configuration. Record which ones need custom work and who will support it.
- 01Receive two lotsKeep each source and remaining quantity
- 02Make and splitConnect inputs to each pack format
- 03Apply a stock holdCheck picking and order interfacesDo all interfaces enforce the hold?YesContinue the trace exerciseNoRecord an acceptance gap; repair and retest the restriction before sign-off.
- 04Trace both waysReconcile inputs, outputs and destinations
A software evaluation script, not a prescribed manufacturing procedure. Diagram: NextEdge Labs.
Send the transaction script before the sales meeting
Use a simplified version of your own product and quantity structure. Ask the vendor to show the proposed configuration and identify any customisation needed. The example below is an evaluation exercise, not a prescribed production process.
| Ask the team to… | Inspect the resulting evidence |
|---|---|
| Receive two ingredient lots and use part of each | Both source references and the quantities left over |
| Split the output into two pack sizes | A connection from each finished lot to the production run |
| Allocate stock, then place part of it on hold | The restriction reaches picking and order interfaces |
| Record approved rework in a later batch | The original and later batch remain connected |
| Correct a receipt or production quantity | The original value, correction and affected balances |
| Trace a shipment backwards and an input forwards | Inputs, outputs, stock and customer destinations reconcile |
Source: GS1 · Sections 2.2 and 5: identification and transformation records; the demonstration script is NextEdge Labs’ proposal. Reference details
A recipe change must not rewrite last month
Keep the version used for each batch, planned quantities, actual consumption and approved substitutions. A recipe that changes today should not alter the explanation of goods produced last month. Apply the same discipline to pack specifications.
Substitution needs a decision by the appropriate product and quality owners. Matching two ingredient names is insufficient to establish equivalence. The software should preserve the request, approval and affected batch, including any relevant specification review.
For rework, look beyond the quantity added. Can the system identify its source and every later batch it enters? A generic rework item can make inventory balance while losing the history needed for an investigation.
A hold has to survive the integration
A restricted-stock badge may work perfectly in the ERP while an external order tool continues to reserve the same lot. Test the rules through the interfaces the business will actually use. Include a hold added after an order has already been allocated.
The same principle applies to duplicate messages. Retry a warehouse receipt and confirm it does not create another receipt. Interrupt a posting, then show the operator where the failure appears and how it is resolved. Ask who owns that queue once the implementation partner leaves.
If a specialist traceability tool sits alongside the ERP, demonstrate a reversal in both. A searchable lot history alongside an inconsistent stock ledger creates a second reconciliation task rather than a reliable record.
Separate standard capability from a promise to build it
Classify each demonstrated requirement as available in the proposed configuration, needing configuration work, needing custom code or unsupported. Record dependencies on scanners, scales, printers and other applications. This makes competing proposals easier to compare.
Ask how custom work will be tested after an ERP upgrade, how data can be exported and who can change permissions. Include operational support in the cost: a lower initial licence price can be outweighed by manual reconciliation or fragile interfaces.
An existing ERP may already cover finance and core inventory adequately. If the gap is a receiving screen or a production exception workflow, price a focused application as an option. Compare the work needed for both approaches before treating full replacement as inevitable.
Make acceptance depend on evidence the team can retrieve
Set a baseline for the work that matters: tracing a batch, resolving a stock difference or recovering a failed posting. Repeat those tasks with representative records in the proposed system. Include someone who did not enter the original data.
Keep unresolved gaps in the acceptance record. A missing relationship cannot be offset by a strong score on unrelated features. The buying decision should explain what the system can support at launch, what remains manual and who has accepted each limitation.
Sources and further reading
Sources checked 15 October 2026. The worked examples and software evaluation suggestions are NextEdge Labs’ editorial analysis.
- GS1 Global Traceability StandardGS1 · Release 2.0, August 2017
Reference framework for identification and traceability data. Citing it does not imply that a proposed system is GS1 certified.
Visual credits
AI-generated illustration created for NextEdge Labs; it does not depict a client facility. Workflow diagram by NextEdge Labs. Icons from Lucide (ISC licence).
