简介：面向汽车供应链质量管理、供应商开发与PPA（生产过程和产品批准）相关从业者，这份VDA 2第6版（2020）指南围绕如何通过生产过程和产品批准保障供应链质量展开，可作为建立、维护质量管理体系及梳理批准流程的参考。资源包为1个PDF文件，约341KB，内容以VDA-QMC发布的英文版指南为主，便于直接查阅条款结构、术语表述与版权声明，使用前需留意文档中的内部使用限制。已有534人学习或下载。读者可从中了解PPA从供应商选择、设计验证、过程能力分析到初始样件批准、批量生产监控和质量改进的整体框架，并据此对照自身业务梳理质量控制节点、完善批准资料与持续改进思路，适合质量工程师、SQE及供应链管理人员按需查阅。

1. 什么是 PPA：一张“准许量产”的通行证到底批的是什么

去一家常去的馆子，菜好吃你会夸厨师手艺，但敢不敢长期吃，看的是后厨：冰箱温度稳不稳、生熟砧板分不分、出菜节奏乱不乱。VDA 2 里的 PPA（生产过程和产品批准，Production process and product approval）就是这套“看后厨”的规矩。它不只问“这个零件合不合格”，还要问“你那条产线能不能一直做出合格的零件”。

VDA 2 第 6 版 2020 年修订版把这件事写成了一份可谈、可查、可追溯的流程：供货方和客户先就范围、内容、时间表达成一致，再按约定的交付物交出证据，最后由客户给出批准结论。它管的不是某个孤立的样品，而是从新零件、变更件到小批量、变型件的整条放行链路。搞懂 PPA，等于搞懂了汽车供应链里“东西凭什么可以开始批量供货”这句问话的完整答案。

2. PPA 到底批什么：过程批准和产品批准是两条腿

第一次听到“生产过程和产品批准”这个说法，多数人脑子里浮现的画面是：把几个做得漂亮的样品装进盒子寄给客户，然后等一个签字。真去翻 VDA 2 的目录会发现，签字只是最后一格，前面还有一长串动作。这套流程把“批准”切成了两件事：产品批准回答“这一件东西对不对”，过程批准回答“你以后还能不能一直做对”。两条腿都站稳，量产才算放行；只站一条，走两步就会摔。

为什么非要拆成两半？因为在汽车供应链上代价最高的事故，往往不是“样品不合格”，而是“样品合格、量产走样”。样品可以挑最好的设备、最稳的师傅、最慢的节拍做出来；量产要的是连续几个月、几十万件、不同班次都维持在同一水平。把过程和产品分开评估，等于逼着供货方在放行之前，先把“能做出来”和“能一直做出来”这两句话分别拿出证据，而不是用一句“您放心”糊过去。

2.1 过程批准：先证明这条线能一直做出合格的件

过程批准盯的是“生产线本身”这个对象，而不是某一件产品。它要看的证据包括：用的是不是批量生产用的设备与工装、工艺参数有没有被固定下来、工序节拍和人员配置是否就是量产状态、关键工序的能力够不够稳。通俗地说，它审的是“厨房”，不是“这一盘菜”。

这一步最容易被低估。很多团队把精力全砸在样品打磨上，过程文件临时拼凑，结果客户一问“你这道工序的参数量产时怎么监控”就卡住。过程批准的逻辑很朴素：如果一条线在批准阶段就靠人盯人、靠临时调整才能做出好件，那它进入批量后必然靠运气，而靠运气的质量迟早会翻车。

2.2 产品批准：再证明这一件各项指标都过了线

产品批准盯的是“产品符合规范”这件事。尺寸、材料成分、功能性能、外观，逐条对着图纸和技术规范核。VDA 2 的附录里专门给了交付物说明的清单，也把材料成分声明、尺寸检验与功能试验单独列成章节，意思很明确：这些不是可选项，而是产品批准的基本盘。

它和过程批准的关系，有点像考驾照。产品批准是科目二，证明你会开车；过程批准是让你在真实路况里连续跑一个月不出事。只过科目二就上路，短期看不出问题，长期一定要出问题。所以两件事的证据必须能对上：产品批准用的样件，得是过程批准里那条线造出来的，否则两边说的根本不是同一件事。

2.3 初始样件的硬门槛：手工精雕的样件不算数

这是 VDA 2 里最硬的一条定义：用于 PPA 的样件（初始样件），必须是完全用批量生产设备、在批量生产条件下制造出来的产品。不是在批量条件下做出来的其他样件，比如手工打样、试制车间小批试做、实验室里精雕细琢的那几件，都不能用于 PPA。

这条门槛看着不近人情，其实是无数踩坑换来的。手工样件往往尺寸更准、表面更好、装配更顺，因为它慢、它挑人、它可以返工。等切到量产，设备一开快、模具一磨损、班次一换人，问题全冒出来。所以标准的潜台词是：别拿“我能做到的最好状态”来证明“我量产时的普通状态”。

提示：判断一个样件能不能用，只问一句——它是不是在客户将来要收货的那条线上、用同样的设备和条件做出来的。答案是否定，就别往 PPA 里塞。

3. 第 6 版为什么要改：从“交一大摞文件”到“先把话说清楚”

如果把 2012 年的第 5 版比作一次大装修，那 2020 年的第 6 版更像一次“减负 + 对表”。第 5 版已经把 PPA 结构重排过一遍，明确了它对新的或变更的供货范围（包括外部供货和内部自制）提出哪些要求。而第 6 版往前又推了一步：把重点从“按模板交材料”挪到“甲乙双方先谈妥”，同时砍掉了一批在实际执行中只会制造纸张、不产生判断力的环节。理解这次改版的动机，比背下改了哪几条更有用。

3.1 取消提交等级：从统一套餐改成按需点菜

过去 PPA 有“提交等级”的概念，不同等级对应不同厚度的文件包，听起来很整齐，实际执行时经常变形：客户产品的复杂度差异很大，一个结构件和一个电子模块用同一张清单，结果一边嫌多、一边嫌少；再加上不同客户有自己的期待，供货方为了保险，索性按最厚的那一档准备，文件越滚越多。

第 6 版直接取消了提交等级。这个动作背后的判断是：文件的多少不该由一张固定档位表决定，而该由“这批供货范围到底有什么风险、客户到底关心什么”决定。于是流程的起点从“查表”变成了“谈”——先把范围、内容、时间表谈成一个双方都认的约定，再据此决定交什么。这就是 PPA 协议存在的意义。

3.2 自我评估换减量：企业先给自己打分

VDA 2 附录里有一份产品与生产过程的自评估表。它的用法不是“自夸”，而是“自曝”：企业先按统一口径给自家产品和过程打分，把风险点摆出来，再据此决定哪些证据必须交、哪些可以少交。评估做得越实在，需要提交的文件量就越少。

这套设计很聪明，它把“减文件”和“担责任”绑在了一起。想少交材料，就得先证明自己看得清自己的问题；一旦后面出了纰漏，那份自评估就是最直接的对照物。所以自评估不是走形式的打分游戏，它更像是企业给自己签的一份“我知道我哪儿虚”的声明。填表时把分数往高里打的团队，通常在后端付的代价更大。

3.3 软件也进了批准范围

第 6 版把软件纳入了考虑范围，配套还专门给了软件相关的封面表。这一点常被做硬件的团队忽略：一个零件里只要嵌了软件，它的行为就不再只由材料和尺寸决定，版本、参数、刷写状态都会影响最终表现。把软件当成“附带品”处理，等于给整条批准链留了个黑匣子。

实务上的变化是，交付物清单里开始出现和软件状态相关的内容，批准时要能说清“这批货里跑的是哪个版本、这个版本验证过什么”。对习惯了交图纸和检测报告的团队来说，这是需要重新建立习惯的地方。

3.4 和北美那套 PPAP 对表：两种语言开始互认

不同车企体系里流传着不同的批准语言，北美方向大家更熟的是 PPAP。第 6 版做了一件很务实的事：把 PPA 的交付物和 PPAP 的交付物做了协调，还专门附了一份两者的对比说明。对同时给多个体系供货的工厂来说，这意味着不必再维护两套互不相干的材料，很多证据可以一次做、两边用。

但“对齐”不等于“等同”。两份文件的出发点、章节切分、判定口径仍有差别，把它当成“同一个东西的不同叫法”是最常见的误读之一，后面还会专门拆开讲。

4. 一套 PPA 文件包的数据结构：谁在什么时候读哪一页

做质量的人多半有过这种经历：客户来审，十几个人围着一台电脑翻文件夹，翻了二十分钟还没找到那份关键记录。问题不在文件少，而在结构乱。PPA 的交付物其实有一套相当清晰的数据结构——哪份文件在流程的哪个阶段产生、给谁看、回答什么问题，都是定好的。把结构理顺了，整套材料的维护成本会掉一大截。

4.1 PPA 协议：先把范围、内容、时间表钉死

第 6 版反复强调的一件事，是组织和客户要就 PPA 的范围、内容和时间表达成一致。范围指的是这批供货里哪些零件、哪些变型要纳入；内容指的是交哪些交付物、按什么深度交；时间表指的是什么时候交、什么时候评审、什么时候给结论。

这三件事没谈拢，后面全是扯皮。范围含糊，就会出现“我以为这个变型不用报”的争执；内容含糊，就会出现“我交了你还要”的返工；时间表含糊，就会出现样件早做好了但客户排不出评审，产线干等。协议这一步看着最不像技术活，实则决定整个流程的顺滑度。

4.2 触发矩阵：什么情况必须重走一遍

零件不是批准一次就一劳永逸。材料换了、场地搬了、模具大修了、关键分供方换人了，都可能让原来的批准失效。附录里的触发矩阵就是干这个用的：把各类变更列成一张表，对应到需要重新做什么、重新交什么。

它解决的是一个非常现实的困惑——变更太多，人靠记忆判断“这个要不要报”，判断标准还因人而异。有了矩阵，判断从“我觉得”变成“查表”。而且矩阵的用法有专门说明，强调的不是机械对照，而是先识别变更的性质，再决定动作幅度。

4.3 零件履历与偏差流程：把“例外”也写进档案

零件履历这张表，功能类似一个人的病历：这个零件从哪来、经历过哪些变更、每次变更后做了什么验证、谁批的。它平时没人看，一旦出问题，所有人都在找它。偏差流程则管“不符合约定”的情况：允许有例外，但例外必须被记录、被评估、被客户知情并决策，不能悄悄放行。

这两样东西的价值都在事后。顺的时候觉得多余，乱的时候救命。很多团队的后悔药，就是在客户追问“这个尺寸是什么时候开始偏的”时，翻不出一份完整的履历。

4.4 一份文件包长什么样

把上面几块拼起来，一套 PPA 材料包的骨架大致是这样：

ppa_package: agreement: # 协议：范围/内容/时间表，先谈后做 scope: ["新零件", "变更件"] deliverables: ["自评估表", "过程批准记录", "产品批准记录"] schedule: "SOP 前 12 周提交，前 8 周评审" self_assessment: # 自评估：先定位风险，再决定交多少 product_score: 3 # 分数越低风险越高，需附说明 process_score: 2 trigger_matrix: # 触发矩阵：变更来了先查表再动手 triggers: ["材料变更", "场地搬迁", "模具大修"] part_history: # 零件履历：变更与验证的连续记录 entries: ["2020-04 首次批准", "2020-09 材料替代复评"] deviation: # 偏差：允许例外，但必须留痕并让客户决策 open_items: []

这段结构只说明层次关系，不是官方字段。真正值得注意的是注释里的先后次序：协议在最前面，因为后面的每一项都由它授权；自评估排在交付物之前，因为它决定交付物的厚度；触发矩阵和零件履历是长期维护项，不是一次性填完就归档；偏差单独成块，因为它代表“计划外”，不能被混进正常记录里。

注意：结构清晰的文件包，衡量标准不是页数少，而是任何人拿到它，都能在三分钟内定位到“这批货批了什么、依据是什么、还留着什么尾巴”。

5. 常见误区与易混概念：这几个词千万别混着说

5.1 PPA 与 PPAP：不是同一份东西的两个名字

易混点在于，两者都是“量产前的批准”，交付物清单也有大量重叠，看起来像同一套流程在两个地区的叫法。第 6 版还专门做了协调，更容易让人以为可以画等号。

会混是因为重叠部分太显眼：样件、检验报告、过程能力、包装方案，两边都要。但它们的出发点不同，章节切分和判定口径也不一样，各自服务的客户体系有自己的习惯和裁决方式。

区分办法很简单：先问“我这个客户走的是哪套体系”，再按那套的清单和判定逻辑办；需要两边同时交时，用对比说明找出交集，一次做证据、两边分别组装，而不是把一套材料原样丢过去。把两者当同义词，最后吃亏的通常是自己。

5.2 初始样件与普通样件：外观一样，效力完全不同

易混点是两者都能拿在手里，尺寸甚至一模一样，于是被当成同一批东西。真正的差别在“怎么造出来的”：初始样件必须是批量设备、批量条件下的产物。

会混是因为试制车间的手工件往往更漂亮，拿去给客户看更容易留下好印象，团队就有了“先用它顶一下”的冲动。

区分办法是看生产条件，不看外观。用非批量条件做出来的样件，在 PPA 里没有效力，硬塞进去等于给后面的量产埋雷。

5.3 过程批准与产品批准：一个批线，一个批件

易混点是两者都在“批准”这个词底下，交付物又常被打包在一起提交，于是被理解成一道手续。

会混是因为很多小项目里，两件事由同一个人做、在同一周完成，界面模糊了。

区分办法是问“这个证据证明的是线还是件”。证明线的，看设备、参数、能力、稳定性；证明件的，看尺寸、材料、功能、外观。两边都过硬，才算真放行。

5.4 自我评估与免检：省的是文件，不是责任

易混点是自评估能减少提交量，于是被理解成“自己说没问题就行”。

会混是因为减负的效果很直观——表格一填，材料薄了一半，看起来成本降了。

区分办法是记住它的定位：自评估是把风险摆到桌面上，用来决定交什么，而不是给自己发通行证。分数打得漂亮但过程站不住，等客户现场一看，翻车只会更难看。

5.5 保留期与“交完就完事”：档案是要留到以后的

易混点是批准结论一到手，很多人下意识觉得流程结束，材料可以清理。

会混是因为交付和批准是节点，节点有明确的时间点；而保留期是条长线，没有即时反馈。

区分办法是把保留期当成流程的一部分来排计划：哪些记录留多久、存在哪、谁能调出来。等到客户几年后回头查某个批次，翻不出来才是最贵的教训。

6. 什么时候该走 PPA，什么时候别硬套

判断要不要走，看的是“有没有新的或变更的供货范围”，而不是“客户有没有催”。新零件首次供货、材料或结构变更、生产场地搬迁、模具大修、关键分供方更换、变型件增加、小批量试供，这些都在 PPA 的适用面上；VDA 2 还给了分级 PPA 和变型件批准的做法，意思是复杂程度不同，动作幅度可以不同，但“评估过并留下记录”这一步不能省。

反过来，几种情况硬套这套流程反而低效：纯目录件、标准件采购且不涉及生产过程变更的；客户方明确指定了另一套批准流程且书面确认的；内部自制的范围变更但根本没有对外交付界面的。这些情形不是“不用管质量”，而是“别把一份为供应链交付设计的流程，套到不产生交付界面的场景上”，否则只是给自己造文件。

我吃过一次教训：一个自认为“只是换了台设备、参数没变”的活儿，团队判断不用重报，结果客户现场审核时问了一句“新设备的节拍和原来一致吗”，全场安静。设备换了，节拍变了，人员操作习惯也变了，这些都不在图纸上，但都在过程里。从那以后我每次碰到变更，都强制走一遍触发矩阵，哪怕最后结论是“不用重报”，那行结论和依据也必须落成文字。希望帮到你。

本文还有配套的精品资源，点击获取