Case study 03 · Manufacturing systems

End-to-End Manufacturing Process Validation for ERP Transformation

Validating that an engineer-to-order manufacturing process can actually be executed — order to invoice — before two plants are allowed to run production on a new system. The engineering problem is acceptance criteria; the hard part is closure discipline.

Project record

Professional

Project type: Professional project
Domain: Manufacturing systems / ERP transformation
Role: SAP Business Implementation Project Manager, Industrial Pumps
Methods: End-to-end scenario design · Acceptance criteria definition · Readiness assessment · Issue-closure governance · Process documentation control
Date: 2026 — ongoing
Data: Scenario abstracted to a fictional industrial equipment manufacturer
Confidentiality: No employer configuration, master data, test records, defect data or site readiness reporting is disclosed. The structure of the method is described; the content is generic.

How this case study is written

The work described here is real and ongoing. The scenario used to illustrate it is not: it is a generic engineer-to-order industrial equipment manufacturer, built to show the shape of an end-to-end validation without reproducing any employer’s process design, configuration or test evidence.

Context

An SAP S/4HANA deployment across two industrial pump manufacturing plants supporting more than $200M in operations. Engineered-to-order and configured products, long lead times, significant purchased content, and quality requirements that are contractual rather than optional.

My remit is manufacturing-process readiness: making sure the manufacturing process can be executed end to end in the new system, by the people who will have to execute it, before production is released onto it. That involves Engineering, Quality, Supply Chain, Planning, Operations and IT, none of whom report to me — which makes the governance as much of the deliverable as the testing.

Problem

ERP testing has a characteristic failure mode: it fragments. IT validates that transactions post. Each function validates its own steps. Everyone passes, and the process still does not work, because nobody tested the handoffs — the points where an engineering revision becomes a routing, where a routing becomes executable work, where an inspection is supposed to block a shipment.

The second failure mode is closure. In a schedule-driven program, a defect that is understood tends to get treated as a defect that is resolved. “We know why that happens” becomes a closure note. Then it recurs at go-live, when it costs production.

So the problem was not “test the system.” It was: define what constitutes proof that a manufacturing process is executable, and build a closure gate strong enough to hold under schedule pressure.

Constraints

Two sites with genuinely different process realities, on one program timeline and one system design.
Cross-functional ownership with no direct authority — closure had to be enforced by an agreed standard of evidence rather than by hierarchy.
Engineered-to-order products, so a large share of what happens per order is defined per order, and the validation had to prove the mechanism rather than one part number.
Committed deployment dates, which is the condition under which evidence standards quietly erode.
Work instructions and process documentation for both sites were incomplete at the start and were a prerequisite for user readiness, not a follow-up task.

My role

I lead manufacturing-process readiness for the deployment: I develop and execute the end-to-end validation scenarios, coordinate the functions through them, own the work-instruction and process-documentation inventory for both sites, and built the issue-closure governance the program now runs on. I also own the readiness reporting that leadership uses to judge whether a site is ready.

Approach — validate the chain, not the transactions

A manufacturing process is a chain of handoffs. Validation has to traverse the whole chain in one continuous thread, with the same order, the same material and the same document set, because the defects worth finding live at the joints.

Customer order
Engineering release
BOM & routing
MRP
Procurement
Receiving
Production
Quality
Warehouse
Shipment
Invoice

Each scenario starts from a real business situation — a configured customer order — and is executed by the people who will own that step in production. Every stage carries the same three things a manufacturing acceptance criterion carries: what is being validated, how it is verified, and what evidence constitutes a pass.

Worked scenario — engineer-to-order pump

A customer-configured engineered product moving from sales order through engineering release, planning, procurement, production, quality and shipment to financial posting. Abstracted to a generic industrial equipment manufacturer.

Engineer-to-order validation scenario

Illustrative — generic manufacturer

Stage	System area	What is validated	Evidence of pass
Order intake	Order to cash	A customer-configured engineered product can be entered with the correct variant, pricing and delivery commitment.	Sales order with the configuration and dates the business expected, not a workaround entry.
Engineering release	Engineering / PLM interface	The engineering deliverable releases to manufacturing at a controlled revision, and the revision is the one manufacturing will build to.	Released document set at a specific revision, traceable to the order.
BOM & routing	Production planning	The bill of material and routing are created and executable — every operation has a work center, a time and a resource that exists.	BOM and routing records reviewed by the manufacturing engineer who has to run them.
Material planning	MRP	Demand generates the correct supply: make items become production orders, buy items become purchase requisitions, with dates that respect lead time.	MRP result compared against the manually expected supply plan for the same demand.
Procurement	Materials management	Requisitions convert to purchase orders against the correct approved source, with the specified quality requirements attached.	Purchase order carrying the specification and inspection requirement, to the intended supplier.
Receiving	Inventory / warehouse management	Receipt posts to the correct stock type, and material requiring inspection lands in inspection stock rather than unrestricted stock.	Material document showing stock type, location and quantity; inspection lot created.
Incoming quality	Quality management	The inspection is triggered by the material and its specification, results can be recorded, and a rejection actually blocks consumption.	Inspection lot with recorded results and a usage decision; rejected stock demonstrably unavailable to production.
Production execution	Production planning	The order can be released, confirmed operation by operation, and consume components as the physical process does.	Order confirmations and goods issues consistent with the routing and the physical build sequence.
In-process & final quality	Quality management	In-process inspection points fire at the right operations; a nonconformance can be raised, dispositioned and blocked from shipment.	Inspection records at the defined operations; nonconformance record with disposition and evidence of blocking.
Warehousing	Inventory / warehouse management	Finished goods post to the correct location with the traceability the product requires — serial or batch as applicable.	Stock record with the traceability identifier resolvable back to the production order.
Shipment	Logistics execution	The correct product ships against the correct order, with required documentation, and the shipment cannot proceed with an open quality block.	Delivery and shipping documents; demonstrated block on a unit with an open nonconformance.
Financial integration	Finance interface	Production, inventory movements and shipment produce the expected financial postings — the process is not "validated" until the numbers land correctly.	Posting documents reconciled against the expected cost and revenue treatment.

Scroll table horizontally →

Two rows in that table carry most of the risk, and both are quality rows. An inspection that does not trigger is invisible until something ships. A quality block that does not actually prevent a delivery is worse than no block at all, because the organization believes it is protected. Both are validated by attempting the thing that should be impossible — trying to ship a unit with an open nonconformance — rather than by confirming the configuration looks right.

Issue-closure governance

This is the part I would keep if I could only keep one. It is the same discipline as closing a manufacturing nonconformance, applied to a process defect.

Issue identified
Raised against a scenario step, with the expected result and the actual result both recorded.
Owner assigned
A named person in the owning function — not a team, not a workstream.
Severity classified
Critical issues block site sign-off. The classification is agreed at logging, before anyone knows how hard the fix will be.
Corrective action
Configuration, master data, process design or work instruction — whichever is actually wrong.
Objective evidence
The evidence type is defined when the issue is logged, so closure cannot be negotiated later.
Retest
Re-executed in the end-to-end thread, by the user, not demonstrated by the person who fixed it.
Site sign-off
The site accepts the step, per site, because the two plants do not run identically.
ClosedClosed
Closure means retested and signed off. An explanation is not a closure.

The rule that does the work

Every critical defect requires defined ownership, corrective action, objective evidence, retest and site sign-off before it is considered closed. No step in that sequence can be substituted by an explanation, a status update, or confidence that it will be fine in production.

Readiness assessment

Readiness is not one number. A site can be fully tested and completely unready, if the testing was done by the project team rather than by the users who will run it on Monday.

Readiness dimensions and the question each one answers

Dimension	Question it must answer
Process readiness	Has the end-to-end process been executed successfully in the system, by the people who will run it, at each site?
Data readiness	Is master data — material, BOM, routing, work center, source list, inspection plan — complete and correct enough to execute, not merely loaded?
User readiness	Have the actual users executed their own transactions, or has a project team executed on their behalf?
Documentation readiness	Does a current work instruction exist for every process step a user is expected to perform?
Issue closure	Are all critical defects closed with objective evidence and a retest, rather than closed as "explained"?
Cutover readiness	Is there an agreed sequence, owner and fallback position for every step of the transition itself?

Scroll table horizontally →

These dimensions drive the readiness reporting: defect aging, closure status by severity and owner, documentation coverage against the process inventory, and site readiness by dimension. The reporting exists to support a decision — go, go with a contingency, or hold — so every chart on it has to change somebody’s mind about that decision, or it does not belong there.

Engineering judgment

What decision had to be made?: Is a site ready to release production onto the new system? It is the same structural decision as an equipment buy-off: a release gate with defined criteria, evaluated against evidence, under schedule pressure that argues for saying yes.
What evidence mattered?: Successful end-to-end execution of the manufacturing process by the site’s own users; zero open critical defects, each closed with its defined evidence and a retest; master data sufficient to execute rather than merely loaded; current work instructions covering every step a user is expected to perform; and a cutover plan with an owner and a fallback for each step. Test coverage statistics are not evidence — a high pass rate across fragmented tests says nothing about whether the chain holds.
What would cause me to change the decision?: An open critical defect in the quality chain — an inspection that does not trigger, or a block that does not prevent shipment — holds the gate regardless of program pressure, because the failure mode is shipping nonconforming product. Conversely, I would not hold a site for open low-severity items or incomplete nice-to-have reporting; those are managed after go-live with a named owner. The distinction is whether the open item can put nonconforming product in front of a customer or stop production outright.

Engineering Decision

Site readiness gate (illustrative application of the criteria)

READY WITH ACTIONS — conditional on critical-defect closure

Basis

The end-to-end manufacturing process has been executed by site users across every stage of the chain, including the quality blocks. Remaining open items are non-critical and have named owners and dates. Critical-defect closure is the only outstanding gate condition.

Conditions to clear the gate

Zero open critical defects, each closed with its defined objective evidence and a retest executed by the user
Work instructions current for every process step in the site inventory
Master data sufficient to execute the process, verified by execution rather than by load counts
Cutover sequence agreed with an owner and a fallback position per step
Hypercare support model staffed and agreed by function

Illustrative example of the gate structure · not an employer readiness record

Result

The program runs on an end-to-end validation approach rather than function-by-function testing, with a closure standard that is applied uniformly: ownership, corrective action, objective evidence, retest, site sign-off. Both sites have a process-documentation inventory that is tracked rather than assumed, and leadership has readiness reporting that reports readiness rather than activity.

The work is ongoing, so the honest statement of outcome is about the mechanism, not a final number. What I can say is that the closure gate has already stopped defects from being closed as “understood,” which is the specific failure this governance was built to prevent.

What I learned

A transformation is a quality problem in different clothing. Requirements, acceptance criteria, nonconformance, corrective action, objective evidence, release gate. The vocabulary changes; the discipline does not.

Test the thing that should be impossible. Confirming that a control is configured is not the same as confirming it works. The only convincing validation of a quality block is a failed attempt to get past it.

Closure standards must be set before anyone knows the cost. If the evidence type is defined when the issue is logged, closure is a factual question. If it is defined at closing time, it becomes a negotiation, and schedule wins.

Documentation is a prerequisite, not a deliverable. A user cannot be ready for a process step that has no current work instruction, no matter how much training was delivered.

Tools & methods

SAP S/4HANA (QM, PP, MM, IM/EWM)
End-to-end scenario design
Acceptance criteria
Defect governance
Readiness assessment
Process documentation control
Power BI
SQL

Limitations

This case study describes methodology. The scenario, the readiness example and the decision card are illustrative constructions on a generic manufacturer — they are not employer process designs, configuration, test records or readiness reporting. Acceptance thresholds on an actual program are set by that program’s governance, not by this page.

The closure discipline here is the same one applied to physical equipment in Production Equipment Run-Off & Acceptance and to supplier equipment in the liquid cooling skid study.