There is a moment on most manufacturing ERP programmes where someone says, with relief, “we’ll catch that in UAT.”
It is worth noticing what that sentence assumes. It assumes user acceptance testing is a net that will find unknown things. And it will — that is exactly the problem. If UAT is finding out how the process works, it is not a test. It is requirements gathering with a go-live date attached.
The problem
A test compares an outcome against an expectation. No expectation, no test. So the quality of a UAT is bounded entirely by how precisely the future-state process was described beforehand — and on manufacturing programmes it frequently was not, for a specific and understandable reason: the current-state process was never written down either. It lives in the heads of people who have run it for fifteen years.
What then happens in UAT is that a user is asked to execute a scenario, discovers the system does not do what they expected, and raises a defect. Sometimes that is a real defect. Frequently it is a difference between the designed process and the undocumented one — and those two things arrive in the tracker looking identical.
Two failure modes follow. Real defects get triaged as change requests and deferred. And genuine process design decisions get made by whoever is triaging the tracker, at speed, under schedule pressure, usually without the manufacturing engineer who understands the physical consequence in the room.
A framework: the test is the chain, not the transaction
Manufacturing ERP testing fragments almost by default. IT verifies that transactions post. Each function verifies its own steps. Everyone passes. The process still does not work, because the expensive defects live at the handoffs — where an engineering revision becomes a routing, where a routing becomes executable work, where an inspection result is supposed to stop a delivery.
The structure that actually works is the one a manufacturing engineer would recognize:
Start from a real business situation — a specific customer order for a specific configured product. Execute it end to end in one continuous thread: engineering release, BOM and routing, material planning, procurement, receiving, incoming inspection, production execution, in-process and final quality, warehousing, shipment, financial posting. Same order, same material, same document set, all the way through.
Then, for each stage, state three things in advance, exactly as you would for an equipment acceptance criterion: what is being validated, how it is verified, and what evidence constitutes a pass. If you cannot write the third column for a stage, you do not have a test for that stage — you have an activity.
Worked example: test the thing that should be impossible
The highest-value rows in a manufacturing validation are the quality rows, and they need a particular kind of test.
Consider incoming inspection. The weak version confirms that the inspection plan is configured against the material and that an inspection lot is created. That confirms configuration. The strong version does something else: it takes a material that has been rejected, and then tries to consume it in a production order. If that succeeds, the control does not exist, whatever the configuration screen says.
Same for the shipment block. Do not verify that a nonconformance can be recorded against a finished unit. Raise one, then attempt to create and post the delivery. A quality block that does not actually prevent a delivery is worse than no block at all, because the organization now believes it is protected and has stopped watching.
This is the ERP equivalent of inducing a fault to verify an interlock rather than reading the interlock’s configuration — the same test philosophy I would apply to a controls section of a FAT. You do not verify a protective function by inspecting it. You verify it by trying to defeat it.
Engineering implication
Two consequences follow, and both are about sequence.
Document the future-state process before UAT, not as an output of it. The work instruction inventory is not a training deliverable to be completed after testing. It is the expectation the test compares against, and it is a prerequisite. A user cannot be ready for — or meaningfully test — a process step that has no current work instruction.
Define the closure standard at the moment a defect is raised. Owner, corrective action, objective evidence, retest by the user, site sign-off. Set the required evidence type at raising time, before anyone knows what it will cost to produce. Set it at closing time and closure becomes a negotiation that schedule always wins — which is how “we know why that happens” ends up in a closure field and the same defect reappears in week two of production.
That is the same discipline as closing a nonconformance, applied to a process defect instead of a physical one, and it is the mechanism I have found holds up under pressure. Not because people are more rigorous, but because the standard was agreed while it was still cheap to agree.
Takeaway
UAT should confirm that a documented future-state process executes end to end, by the people who will run it, with a stated pass condition for every stage — including a failed attempt to get past every quality control.
If it is discovering the process instead, the programme does not have a testing problem. It has a process-definition problem, and it is about to find out how expensive that is on a fixed date.