Direct answer: An NPI (new product introduction) / APQP-PPAP capability page cannot just say "we support APQP/PPAP and can work with customers." It should state where projects come from, the phases, who owns and delivers what at each phase, what inputs the customer must provide, how DFMEA/PFMEA/control plans connect, how trial production and takt time are validated, how MSA and initial capability are judged, how PPAP submission levels and PSW work, how ramp-up/safe launch exit, whether a change triggers a new PPAP, and what must not be published. Otherwise, when a customer asks "what PPAP level can you submit, how many trial parts, what Ppk can you achieve, how soon after a change do you resubmit," the answer becomes an ad-hoc meeting.
This guide is for project, quality, process, production, sales and website teams at manufacturers in Changzhou and nearby industrial areas. It explains how to build and accept an NPI/APQP-PPAP capability page. Information is current to 2026-11-02. It is a review of public standards and project practice, not an APQP/PPAP manual, IATF audit or legal advice; the specific phases, deliverables, submission levels, capability targets and change requirements depend on the customer's CSR (customer-specific requirements), contract, AIAG manual version and company procedures.
APQP is the structured method for taking a new project from requirements to production; PPAP is the pre-production submission proving the process is capable. Neither is proven by saying "we can cooperate". The PPAP level only decides what is submitted to the customer, not what must be prepared internally—all elements must be prepared and retained. Trial production, takt time, MSA, capability, PSW and change control are the points a customer uses to judge launch risk.
How does the NPI page relate to sample, OEM/ODM, quality and PCN pages?
The sample page answers "how samples are made, approved and first articles confirmed"; the OEM/ODM page answers "whether we build to drawing/sample and what the capability boundary is"; the quality page answers "system, inspection, PPM and complaints"; the PCN page answers "how post-production changes/end-of-life are notified"; the NPI/APQP-PPAP page answers "how a new project is managed from kickoff to production approval, what is delivered at each phase, how the customer participates and how PPAP is submitted." A sample is one step in NPI, not the whole of APQP; PPAP is not "the sample passed".
The common break is: sales says "we do APQP" but there are no gate reviews and deliverables depend on individual experience; the customer asks for PPAP Level 3 and the supplier submits only a PSW and a few dimensional reports; trial production uses lab or hand-built samples rather than production tooling and takt time; MSA is skipped so capability data is unreliable; the PSW is signed but safe launch is not done and the first three months generate batch problems; a design/process/supplier change is not followed by a new PPAP. A page that states phases, deliverables, validation, submission and change gives sales, project and quality one playbook.
| Page/entry | Answers | Audience | Cannot replace |
|---|---|---|---|
| Sample page | Sampling, sample approval, first article | Customer, project, quality | APQP phases and PPAP |
| OEM/ODM page | Build-to-drawing/sample, capability boundary | Customer, sales | Project plan and production approval |
| NPI/APQP-PPAP page | Phases, deliverables, trials, capability, submission | Customer SQE, project | Customer CSR/contract |
| Quality page | System, inspection, PPM, complaints | Customer, quality | New-project phase evidence |
| PCN page | Post-production change/EOL notice | Customer, quality | Re-PPAP before the change |
This page map is editorial; APQP/PPAP are AIAG industry methods, and their application follows the customer CSR, contract and manual version.
What are the APQP phases and deliverables?
AIAG APQP is commonly described in five phases: plan and define, product design and development, process design and development, product and process validation, and launch/feedback/assessment/corrective action. Each phase has inputs, activities, outputs and a gate review; the output of one phase is the input to the next. Not every company does product design (in build-to-print work the customer may own it), but process design, validation, PPAP and launch feedback cannot be skipped. The page can show a phase-deliverable-customer-participation table, but should not reproduce the manual.
Deliverables should land in documents and owners: phase 1 design goals, quality/reliability goals, preliminary BOM/process flow, special-characteristic list; phase 2 DFMEA, design verification plan (DVP), design reviews, prototypes; phase 3 process flow, PFMEA, control plan, work instructions, MSA plan, packaging specification; phase 4 trial run, MSA, initial capability, dimensional/material/performance tests, PPAP/PSW; phase 5 ramp-up, safe launch, customer feedback, lessons learned and corrective action. Each phase needs "who approves, what evidence, and what happens if it fails".
| Phase | Core question | Typical deliverables | Customer involvement |
|---|---|---|---|
| 1 Plan/define | What does the customer need and what are the targets | Targets, preliminary BOM/flow, special characteristics, project plan | Requirement/timing confirmation |
| 2 Product design | Can the design meet requirements | DFMEA, DVP, design reviews, prototypes | Design freeze/approval |
| 3 Process design | Can the process make it consistently | Flow chart, PFMEA, control plan, work instructions | Process/tooling review |
| 4 Validation | Do trial run and takt time meet targets | Trial run, MSA, capability, tests, PPAP/PSW | PPAP approval |
| 5 Feedback | Is production stable after launch | Ramp-up, safe launch, feedback, corrective action, lessons learned | Performance/exit confirmation |
The five-phase description follows the common AIAG APQP 3rd edition (2024) structure; specific phase names, deliverables and gates follow the customer CSR, manual version and company procedures.
What inputs should a project collect at kickoff?
At minimum: customer requirements/technical specification, drawings/CAD/models, applicable standards/regulations, BOM/materials, special characteristics, capacity/takt time/batch size, delivery milestones, packaging/logistics, quality targets (PPM/capability), PPAP level and submission list, customer CSR, change rules, and confidentiality/data requirements. If the inputs are unclear, the later DFMEA/PFMEA/control plan is guesswork. The kickoff meeting should confirm "who provides what, which version, and when it is frozen", with a record.
The page can turn "what the customer must provide" into a checklist to reduce back-and-forth: RFQ/technical agreement, drawing revision, key dimensions/special characteristics, annual volume/takt/batch, target delivery/SOP, PPAP level, test/certification requirements, packaging/labelling, customer contacts/systems (portal/EDI). It should also state "what we deliver": project plan, DFMEA/PFMEA, control plan, MSA/capability, PPAP package, PSW, ramp-up plan. Do not write "customer provides" as "customer bears everything", nor "we deliver" as "approval guaranteed".
| Input | What to confirm | Version/evidence | Common gap |
|---|---|---|---|
| Requirements/spec | Function, performance, regulations, acceptance | Technical agreement | Verbal requirements |
| Drawings/model | Revision, key dimensions, special characteristics | Drawing list | Mixed revisions |
| Capacity/takt | Annual volume, batch, SOP, peak | Forecast | Annual volume only |
| Quality targets | PPM, capability, PPAP level | CSR/quality agreement | No level stated |
| Packaging/logistics | Packaging, labels, delivery window | Packaging spec | Left to pre-production |
| Change/confidentiality | Change notice, data use, NDA | Agreement/portal | No rules |
This input list is editorial; specifics follow the customer CSR, technical agreement, drawings and project plan.
How do DFMEA, PFMEA and the control plan connect?
DFMEA addresses design failure modes; PFMEA addresses process failure modes; the control plan turns "special characteristics/failure modes/controls/reaction plans" into shop-floor steps. The three must line up: special characteristics from the DFMEA feed the PFMEA and control plan; high-risk PFMEA items have prevention/detection controls; the control plan states sample, frequency, method, record and reaction plan. They are not three independent documents, and "we have the documents" is not enough—the risk-control-verification chain must be visible.
The page can describe "how we do it", but must not publish customer drawings, special-characteristic lists, FMEA ratings or process parameters. It can publish: cross-functional team, FMEA review timing, the link between control plan and work instructions, reaction/isolation/traceability, and updates after change. At a customer audit, the evidence must be "version, approval, training, shop-floor execution", not just a template.
| Document | Answers | Key linkage | Common gap |
|---|---|---|---|
| DFMEA | Where design may fail | Special characteristics/design controls | Never updated |
| PFMEA | Where the process may fail | Step/cause/prevention/detection | Copied template |
| Control plan | How the floor controls it | Sample/frequency/method/reaction | Does not match the floor |
| Work instruction | What the operator does | Key steps/parameters/records | No training |
| Reaction plan | What happens on abnormality | Isolation/traceability/notification | Only says "rework" |
FMEA/control-plan methods follow AIAG (and AIAG-VDA) manuals and the customer CSR; this article does not reproduce the manuals.
How should trial production, takt time and capacity be validated?
PPAP samples and data must come from a "significant production run": production tooling, gauging, materials, process, operators and site, run at the production rate. The common AIAG default is one to eight hours of production with at least 300 consecutive parts, unless the customer specifies otherwise. A trial run is not "a few hand-built good samples" or "the lab tuned to the best condition"; it must show the process is stable under production conditions and record takt time, downtime, abnormalities and capacity.
Capacity validation compares "customer takt time vs actual takt time", including the bottleneck, changeover, downtime, yield and staffing/shifts; theoretical equipment capacity is not enough. Low-volume or one-off projects may adjust the sample size with customer agreement, but this must be documented in the PPAP/project file. The page can say "we run trial production/takt validation to the customer's rate and provide capacity evidence", but must not promise "unlimited capacity/any expedite".
| Item | Requirement | Evidence | Common gap |
|---|---|---|---|
| Production conditions | Production tooling/gauges/materials/site/operators | Trial record | Hand-built samples |
| Quantity/duration | Commonly 1-8 hours, at least 300 consecutive parts (or customer-specified) | Production report | Only dozens of parts |
| Takt time | Run at the customer's required rate | Takt record | Lab rate |
| Capacity | Bottleneck/changeover/downtime/yield | Capacity calculation | Theoretical capacity |
| Abnormality | Downtime/nonconformity/isolation/correction | Exception record | Not recorded |
The common significant-production-run default comes from the AIAG PPAP manual; specific quantity, duration and capacity evidence follow the customer CSR/contract.
How should MSA and initial capability be described?
MSA first proves the gauge/measurement system can distinguish parts, then capability can be discussed; the common GR&R criteria are under 10% acceptable, 10-30% conditionally acceptable, and over 30% unacceptable (customer CSR governs). Initial process capability commonly requires Ppk of at least 1.67, and ongoing capability Cpk of at least 1.33; low-volume or special characteristics may use other indices or sample sizes. Capability data must come from a stable, controlled process running under production conditions, not selected good data; if it fails, use 100% inspection/sorting/improvement, not edited reports.
The page can say "we perform MSA, initial capability, dimensional/material/performance tests and submit per customer requirements", but must not publish the customer's actual capability values, test data or defect rates. Measures for insufficient capability (100% inspection, tightened inspection, rework, line stop, improvement) should be stated; do not treat "Ppk met" as a permanent guarantee, because production varies with people, machine, material, method and environment.
| Item | Common criterion | Evidence | Common gap |
|---|---|---|---|
| MSA/GR&R | <10% acceptable; 10-30% conditional; >30% unacceptable | MSA report | Skipped/fabricated |
| Initial capability | Commonly Ppk ≥1.67 | Capability study | Insufficient sample |
| Ongoing capability | Commonly Cpk ≥1.33 | Control chart/data | Only good lots reported |
| Dimensional/material/performance | Per drawing/standard/customer | Test reports | Incomplete scope |
| Failure measures | 100%/tightened/improvement/line stop | Action record | Data edited |
MSA and Ppk/Cpk criteria are common industry practice; specifics follow the customer CSR, AIAG manual version and product characteristics.
How do PPAP submission levels, PSW and customer approval work?
AIAG PPAP has five submission levels: Level 1 submits the PSW only (plus the AAR for appearance items); Level 2 submits the PSW, samples and limited supporting data; Level 3 submits the PSW, samples and complete supporting data; Level 4 submits the PSW plus other customer-defined items; Level 5 reviews the PSW, samples and complete data at the supplier's site. When the customer does not specify, the common default is Level 3; but the level only decides what is submitted—all elements must be prepared and retained. The PSW is a summary declaration, not a synonym for "customer approved".
Customer dispositions are commonly approved, interim approval and rejected. Interim approval must state the reason, containment, resubmission deadline and next submission; rejection requires correction and resubmission. The page can say "we prepare the PPAP package per customer requirements and support PSW signing and correction", but must not say "guaranteed first-time approval/Level 3 guaranteed". PPAP files contain customer drawings, special characteristics and capability data and must not be published.
| PPAP element | What to prepare | Evidence | Common gap |
|---|---|---|---|
| Design records/changes | Drawings, models, engineering change documents | Controlled documents | Revision mismatch |
| FMEA/flow/control plan | DFMEA, PFMEA, process flow, control plan | Approved versions | Not aligned |
| MSA/dimensional/material/performance | Measurement system, full dimensions, material/performance tests | Reports | Incomplete scope |
| Initial capability | Ppk/control chart, sample and data | Capability report | Insufficient sample |
| Samples/master/gauge | Production samples, master sample, gauge list | Identification/records | No identification |
| PSW/AAR | PSW, appearance approval if applicable | Signed forms | Incomplete data |
This element list is an editorial summary; the complete elements and submit/retain requirements follow the AIAG PPAP manual and customer CSR.
| Level | What is submitted | What is retained | Common misuse |
|---|---|---|---|
| Level 1 | PSW (AAR for appearance items) | Other elements retained internally | Assumed nothing to prepare |
| Level 2 | PSW + samples + limited data | Complete data retained | Incomplete data |
| Level 3 | PSW + samples + complete data | Full package retained | Missed default |
| Level 4 | PSW + customer-defined items | Per customer | CSR ignored |
| Level 5 | On-site review of PSW + samples + complete data | Available on site | Site package incomplete |
The level definitions and default Level 3 come from the AIAG PPAP manual (commonly the 4th edition); specifics follow the customer CSR/contract and manual version.
How should ramp-up, safe launch and exit be described?
PPAP approval does not mean production is stable. Ramp-up must manage capacity increase, training, supplier material, yield/takt time, inventory/delivery; safe launch means tightened inspection/containment of key characteristics in the early production period, for a defined number of lots/days/quantity, with quantified exit criteria before returning to normal. Exit criteria should cover defect rate, PPM, complaints, capability, delivery and closure of containment findings.
The page can say "we have a ramp-up/safe-launch plan and submit performance per customer requirements", but must not promise "zero defects/no complaints". Issues found during ramp-up should feed corrective action/lessons learned and update the PFMEA/control plan; the customer may require early production containment (ESI/GP-12 etc.), with the name and duration per CSR. The page must not publish customer names, volumes or defect data.
| Item | What to do | Evidence | Common gap |
|---|---|---|---|
| Ramp-up plan | Capacity/people/material/yield | Ramp-up chart | Firefighting |
| Safe launch | Tightened inspection/containment, lots/period | Containment record | No exit definition |
| Exit criteria | PPM/complaints/capability/delivery | Performance data | Exit by feeling |
| Issue closure | Corrective action/lessons learned | 8D/updated documents | Rework only |
| Customer communication | Weekly report/abnormality/change | Meeting/email | Only good news |
The name, duration and exit criteria of safe launch/early containment follow the customer CSR/contract; this article does not promise specific performance.
When is a new PPAP required after a change?
It depends on the change type and customer rules. Common triggers: new part/drawing, engineering change, tooling/mould/gauge change, material/supplier change, process/method/site change, resumption after tooling has been idle for a period, or a major capability/quality problem. Many customers require a new PPAP (possibly at a different level) and updates to the PFMEA/control plan/work instructions; "ship first, submit later" is not acceptable. Before the change, assess, approve, validate, notify the customer and resubmit PPAP as required.
The page can say "changes are assessed/notified/re-PPAP per customer requirements", but must not turn change management into "no notice needed for any change". Post-production changes also involve the PCN page (change notification); the NPI page explains "how to revalidate/resubmit after a change", the PCN page explains "how to notify the customer". The two must agree—one cannot say "no notice" while the other says "must approve".
| Change type | Common requirement | Evidence | Common gap |
|---|---|---|---|
| Design/drawing | Assess, validate, re-PPAP | ECN/PPAP | Do first, report later |
| Tooling/mould/gauge | Validate, capability, PPAP | Tooling acceptance | No revalidation |
| Material/supplier | Approve, test, PPAP | Material certificate | Hidden substitution |
| Process/site | Assess, notify, revalidate | Change record | No notice |
| Resume after idle | Re-PPAP per customer rule | Resumption assessment | Restart directly |
Change triggers and re-PPAP requirements follow the customer CSR/contract, AIAG PPAP manual and company change procedure.
What should the page say, and what must not be published?
A public page should include: NPI process/phases, roles and gates, inputs the customer must provide, how DFMEA/PFMEA/control plan/PPAP connect, trial/takt/capacity validation, MSA/capability criteria, PPAP levels/PSW/approval status, ramp-up/safe launch, re-PPAP after change, and a contact route. Do not publish: customer names/drawings/special characteristics, FMEA ratings, capability data, PPAP files, prices, unapproved projects, or complaint details.
Wording must be precise: "we prepare APQP/PPAP per customer CSR and support trial/takt/MSA/capability/PSW", not "approval guaranteed/zero defects/any project". Not having IATF 16949 does not mean APQP/PPAP cannot be done, but "we do APQP" must not be written as "certified"; if certified, state the scope/body/validity, and never use a certificate to replace customer approval. Keep versions and dates when updating.
| Page wording | Problem | Suggested wording | Basis |
|---|---|---|---|
| "APQP/PPAP supported" | Too vague to verify | State phases/deliverables/levels/roles | Customer CSR |
| "PPAP approval guaranteed" | Cannot promise customer approval | "Support preparation/correction" | Customer approval right |
| "300 parts is enough" | Ignores conditions/customer rules | State production conditions/takt/customer requirement | AIAG PPAP |
| "Ppk 1.67 forever" | Production varies | State initial/ongoing indices and measures | Industry practice |
| "No need to notify changes" | Violates customer/PPAP rules | State assessment/notice/re-PPAP | CSR/contract |
| "IATF certified" | Scope/validity unclear | State scope/body/validity | Certificate |
These red lines are editorial; whether customer/certification requirements are met is determined by the customer audit and certification body, and this is not an audit conclusion.
Go-live acceptance checklist
Ten checks: phases and gates, customer inputs, DFMEA/PFMEA/control-plan linkage, trial/takt/capacity, MSA/capability, PPAP levels/PSW, ramp-up/safe launch, re-PPAP after change, public boundaries, and updates/evidence. Each needs an owner, evidence and review date. The pass condition is not "the page says APQP is supported", but that a customer can see the phases, deliverables, validation and approval path, and sales does not treat it as a guarantee.
Before go-live, run one real new project through: customer inputs → kickoff → phase deliverables → trial/takt → MSA/capability → PPAP/PSW → ramp-up/safe launch → change. Any step that fails is a gap in the page or the process.
| Check | Pass condition | Evidence | If it fails |
|---|---|---|---|
| Phases/gates | Five phases/deliverables/approvers stated | Project plan | Add process |
| Customer inputs | Requirements/drawings/capacity/CSR/level | Input list | Add list |
| FMEA/CP | Risk-control-verification linked | Documents/floor | Add linkage |
| Trial/takt | Production conditions/quantity/takt | Trial record | Redo trial |
| MSA/capability | Criteria/sample/measures | Reports | Add studies |
| PPAP/PSW | Level/elements/approval status | PPAP package | Add submission |
| Ramp/safe launch | Plan/containment/exit criteria | Records | Add plan |
| Change | Triggers/notice/re-PPAP | Change record | Add process |
| Boundaries | No customer/drawing/data disclosure | Page test | Remove |
| Update | Date/version/reviewer | Version record | Add update |
This checklist is editorial; specific APQP/PPAP requirements follow the customer CSR, contract, manual version and company procedures.
Who should read this, who should not, and what decisions does it support?
It suits manufacturers in Changzhou and nearby areas with OEM/tier-1 new projects, build-to-print work, auto parts, equipment, electronics or export business, where customers ask about APQP/PPAP, trial runs, takt time, MSA, capability or change control; it also suits buyers/SQEs assessing a supplier's new-project capability. It does not suit pure standard-product businesses with no new projects, or teams wanting one page to replace customer audits/PPAP files.
Read it if you are in project, quality, process, production, sales or a website vendor; you are building an NPI/APQP-PPAP page, cleaning up phase deliverables, responding to a customer SQE audit, preparing PPAP, or handling re-submission after a change; or you need to answer "how do you do APQP, what PPAP level can you submit, how many trial parts, what Ppk, what happens after a change." Skip it if you treat "APQP supported" as capability, promise "approval guaranteed" without phase evidence, or want a template to replace project files. It supports self-review of phases, inputs, FMEA/control plan, trial/takt, MSA/capability, PPAP/PSW, ramp-up and change.
Lingyi Information is a website development and enterprise AI project provider, not an APQP/PPAP training, audit or certification body. This article is not a substitute for the AIAG manuals, customer CSR, IATF audit or legal advice. Changzhou projects are delivered remotely or on site as confirmed per project; Lingyi is one candidate, does not claim a local office or team, and does not promise PPAP approval, certification, conversion or inquiries.
FAQ
Is "APQP/PPAP supported" enough on the website?
No. State the phases, deliverables, roles, customer inputs, trial/takt, MSA/capability, PPAP levels/PSW, ramp-up and change rules; otherwise the customer cannot tell whether you have done it or only say it. Do not promise "approval guaranteed"—approval belongs to the customer.
Is PPAP Level 3 the default?
When the customer does not specify, the AIAG PPAP manual's common default is Level 3; but the level only decides what is submitted—all elements must be prepared and retained. The customer may specify another level in the purchase order/CSR; follow the customer.
How many parts/how long is a significant production run?
The common AIAG default is one to eight hours of production with at least 300 consecutive parts, using production tooling/gauges/materials/process/operators/site, unless the customer specifies otherwise. Low-volume or special projects may adjust with customer agreement, documented in the PPAP/project file.
What Ppk/Cpk is required?
Common industry practice is initial Ppk ≥1.67 and ongoing Cpk ≥1.33, with MSA GR&R under 10% acceptable, 10-30% conditional and over 30% unacceptable; these are not universal legal requirements—the customer CSR, characteristic importance and manual version govern. If not met, use 100% inspection/improvement, not edited data.
Does a change always require a new PPAP?
It depends on the change type and customer rules. Design/drawing, tooling/mould/gauge, material/supplier, process/site and resumption after idle commonly trigger reassessment/submission; many customers require a new PPAP and updated PFMEA/control plan. Do not ship first and submit later, and do not omit notification.
Can we do APQP/PPAP without IATF 16949?
Yes. APQP/PPAP are AIAG industry methods; IATF 16949 is an automotive quality management system certification. A customer may require certification, or may only require APQP/PPAP execution. Do not write "certified" without it; if certified, state the scope/body/validity.
One-sentence takeaway
A Changzhou manufacturer's NPI/APQP-PPAP capability page should not say "APQP/PPAP supported". It should turn phases and gates, customer inputs, DFMEA/PFMEA/control plan, trial/takt, MSA/capability, PPAP levels/PSW, ramp-up/safe launch and re-PPAP after change into a verifiable checklist—so a customer can see how you take a new project to production.
Method and limitations
This is a review of public standards and project practice, not an audit or legal opinion on any company's APQP/PPAP, IATF certification, customer approval or contract. No undisclosed customer drawings, FMEAs, capability data or PPAP files were used. Phases, checklists, criteria and the acceptance checklist are editorial suggestions, not APQP/PPAP audit conclusions. Specific phases, deliverables, levels, criteria and change requirements depend on the customer CSR, contract, AIAG manual version and company procedures.
Sources and scope
Information is current to 2026-11-02. The following are public official/industry pages; their scope, version and wording control.
- GB/T 19001-2016, Quality management systems—Requirements, clauses 8.3 (design and development), 8.5.1 (control of production and service provision), 8.5.6 (control of changes) and 8.6 (release of products and services): National Standards Full-Text Public System. System requirements for design, production control, change and release; does not prescribe APQP/PPAP templates.
- AIAG Quality Core Tools (APQP, Control Plan, PPAP, FMEA, MSA, SPC): Automotive Industry Action Group. Industry definitions and manual system for the core tools; specific phases, levels and criteria follow the manual version.
- AIAG PPAP (Production Part Approval Process) manual page: AIAG. Industry source for PPAP submission levels, PSW and the significant production run.
- Product Quality Law of the PRC (2018 amendment), Article 26: Hami Municipal People's Government (NPC text reprint). The producer is responsible for the quality of its products.