ERP Implementation: Test a Factory Handoff Before Go-Live

An ERP implementation is not ready for a factory handoff just because a consultant can complete the demonstration. Before go-live, ask the people who will use the system to perform the agreed workflow with their own approved roles, representative data, and normal work instructions. Record where they need help, where access is wrong, and where the software produces an incorrect result.

This guide is for small manufacturing owners and implementation leads preparing operational acceptance. It turns a receiving-to-quality-to-production handoff into a test you can repeat. It does not replace the wider deployment, migration, integration, security, or recovery checks required by your project.

Separate training, testing, and acceptance

Training teaches someone how to do the work. A rehearsal checks what happens when people perform it. Acceptance is the accountable business owner's decision that the agreed requirements have been met, with evidence and any explicitly accepted limitations.

Keep these records separate. Attendance confirms participation, not task competence. A successful task confirms one observed result, not the readiness of every shift or process. An acceptance signature should identify the tested scope rather than saying only that the ERP is approved.

Microsoft's implementation testing guidance describes role-based process testing, negative scenarios, and user acceptance testing involving trained business users. Apply those principles to your chosen system; this is not a claim that Ploqy is a Microsoft implementation partner or follows a vendor-specific certification process.

Complete the relevant data-migration checks before relying on the rehearsal's starting balances. Today's question is whether people can execute and hand over work, not how to import opening stock.

Write one test card before opening the software

Choose a workflow whose failure would disrupt the first live shift. Document the trigger, starting records, responsible roles, expected result at each handoff, and evidence to retain. Use a clearly identified test environment with non-confidential representative records. Prevent test messages or transactions from reaching real suppliers, customers, or production integrations.

A useful card includes the system version, relevant configuration, test-data version, device, user role, and date. Give each action a short identifier so that a failed step can be found and rerun. State which job aids are permitted: normal written instructions may be part of the intended process, whereas a trainer taking over is an intervention.

Set expected outcomes before testing. Otherwise, a team can unintentionally redefine success around whatever the screen happens to do. Have the process owners agree on role boundaries rather than letting the test invent the factory's operating policy.

Rehearse a three-role factory handoff

Hypothetical example: purchase receipt R-210 contains 20 pieces of component C-10. The factory's defined test process puts all incoming pieces on inspection hold. Quality may release them; stores may record receipt and issue released material; production may confirm receipt against job J-210. These roles and quantities are illustrative, not a Ploqy customer result or universal factory procedure.

1. Stores records receipt: using the stores test account, record 20 pieces into the designated held location. Expected evidence: receipt reference, item, unit, quantity, status, and the quality team's next task.
2. Stores tries an issue too early: attempt to issue six held pieces to J-210. The expected result is a clear refusal with no stock issue posted. This is a passed negative test, not a failed workflow.
3. Quality takes over: a quality user finds R-210 through the normal queue, performs the test's defined review, releases 18 pieces, and leaves two held with a reason and owner.
4. Stores issues released material: issue six of the 18 released pieces to J-210. Expected remaining stores quantity: 12 released plus two held. The six issued pieces belong in the job's material record.
5. Production confirms the handoff: the production user locates J-210, identifies the six issued pieces, and records the agreed acknowledgment without creating a second stock issue.

An inventory system for manufacturers should represent the agreed stock meanings consistently across these roles. Here, the original 20 pieces reconcile to 12 released in stores, two held in stores, and six issued to the job. The exercise is about the handoff, not producing or consuming those six pieces.

Ask each participant how they knew it was their turn. A verbal prompt from the consultant can hide a missing queue, notification, or ownership rule. A notification itself is not proof that the next user can find and complete the task.

Observe without turning the rehearsal into another demo

Train participants first, then let them perform the test with the approved aids. An observer records the outcome and any intervention. If someone becomes stuck, pause and help as needed, but do not mark the original attempt as independently completed after the trainer finishes it.

Keep the session focused on the process, not personal blame. Confusing labels, missing instructions, incorrect data, and unsuitable permissions can all produce hesitation. Record what was observed before assigning a cause. Do not interpret speed alone as competence, especially when a careful user is correctly checking a hold or revision.

For each step, retain the expected result, actual result, transaction reference or sanitized screenshot, assistance used, issue owner, and retest result. A screenshot of a green status is weaker evidence than the actual resulting record and its history.

Separate defects, permissions, and training gaps

Use the same failed observation to guide different investigations. Suppose the quality user cannot release the 18 pieces:

• Permission or configuration issue: the agreed quality role should perform release but cannot. The administrator investigates the approved role mapping and configuration. Do not grant broad administrator access just to finish the test.
• Training or instruction gap: the authorized action works, but the user cannot locate it or understand the next step. Improve the relevant instruction and practice, then repeat the task.
• Software or process defect: the user follows the agreed route, but the result is incorrect, or the workflow cannot express the approved split. Record reproducible steps and route it to the responsible implementation owner.
• Test-data problem: the receipt is in the wrong starting state or references an invalid setup. Correct the controlled test data and rerun, preserving why the first attempt was invalid.

These are investigation categories, not automatic diagnoses. More than one cause may apply. Keep the original failure and the evidence that supports the eventual classification.

Also test a prohibited action with a clear expected refusal. In this example, a stores account must not perform the quality release. If it can, that is a control failure even if every legitimate task works.

Retest the chain, not only the repaired screen

After a fix, repeat the affected action using the intended role. Then run the relevant downstream handoff. Changing a release permission can affect what stores can see or do; changing a status rule can alter the next queue. Confirm that the previously blocked action remains blocked where required.

Use a resettable test case or a fresh set of traceable references. Reusing partially completed records without a reset can hide duplicate transactions or make the second run easier for the wrong reason. Keep the original results and identify the new test run.

Include the person who provides cover when the usual owner is absent. Verify the approved delegation route and coverage for relevant shifts, devices, and language needs. Do not share a privileged account or assume one successful day-shift user represents everyone.

Make a scoped go-live decision

Build a short evidence pack: the agreed test card, participant roles, observed results, unresolved issues, fixes and retests, approved work instructions, and first-shift support contacts. Record who can decide to stop the affected workflow and how activity will be captured while a problem is investigated.

Define blocking issues in advance. Wrong stock changes, unauthorized releases, and inability to complete a critical handoff are examples that need explicit resolution or a formally reviewed safe operating alternative before that scope starts. Do not average them away inside an overall pass percentage.

Close the review with seven questions:

1. Did ordinary users complete every critical action with their intended permissions?
2. Did prohibited actions fail without changing operational records?
3. Could each next owner find the work without an undocumented verbal prompt?
4. Do the resulting records and quantities match the agreed expectations?
5. Were interventions classified, addressed, and retested with evidence?
6. Can an authorized backup user complete the same handoff?
7. Are remaining limits, support ownership, and the scope of acceptance recorded?

This is one part of ERP readiness, not a guarantee of a trouble-free launch. Use it alongside the broader project controls and the focused-scope principles in our manufacturing software selection guide.