简介这份VDA 2 EN 6th 2020 PPA指南面向汽车供应链质量工程师、供应商管理人员及审核从业者聚焦生产过程和产品批准PPA中的质量保障问题。内容围绕供应商选择、设计验证、过程能力分析、初始样件批准、批量生产与质量监控展开并强调质量数据在问题响应与持续改进中的流转价值适合用于建立或对照企业内部的PPA流程。压缩包仅含1个PDF文件约341KB便于在电脑端直接查阅与归档PDF内保留VDA-QMC版权声明及内部使用限制提示使用时需注意合规边界。已有534人学习下载可作为汽车行业质量管理体系学习、供应商审核准备和流程梳理的参考材料帮助读者理解从产品设计到批量产出各阶段的质量控制要点与数据结构化思路。1. 从一次样品被退回说起VDA 2 里的 PPA 到底在批什么有做结构件的朋友碰到过一件事样品尺寸全检合格报告做得漂漂亮亮寄给客户三周后被原样退回。理由不是哪个尺寸超差而是生产记录里写着那批样品是工程师在试模机上一点点调出来的。客户质量工程师只回了一句这不是批产状态。这个场景几乎就是 VDA 2 这份指南存在的理由它讲的核心叫 PPA生产过程和产品批准一套把“我造出来了”确认成“我能一直这么造”的程序。一句话说清PPA 是供应链上下游之间就某个新零件或变更后的零件对生产过程和产品本身做一次正式确认通过了才允许批量交付。它评的不只是产品合不合格更是在评这条产线有没有稳定复制的能力。值得搞懂是因为汽车供应链里最贵的成本常常不是材料而是接口上的来回同一份尺寸报告改三遍格式、样件做好了在等客户排期、模具多开了一个腔没人通知下游。这些摩擦不写在图纸上却实实在在拖慢项目。VDA 2 第 6 版2020 年 4 月修订做的事就是把这些摩擦点固定成一套可以提前约定的动作。2. 它到底批的是什么不是零件合格而是“这条产线能稳定造出合格件”如果把 PPA 理解成“送样给客户看”那基本只理解了三分之一。剩下三分之二藏在两个词里过程、批准。过程指的是设备、工装、检具、人员、参数、环境、节拍这一整套组合批准指的是客户对这个组合给出的正式认可状态而不是一句口头“看着还行”。这两件事叠在一起才构成一次完整的 PPA。理解这一层很关键因为后面所有的文档、表格、自评、触发条件都是围绕“证明这个过程可复制”展开的。搞反了重点就会把精力全花在把报告排版做漂亮上而客户真正想看的是你凭什么认为换一个班次、换一批材料、模具磨损一点之后出来的还是同一个东西。2.1 把 PPA 拆成两半过程批准与产品批准指南把整个程序明确切成两块生产过程批准和产品批准。前者确认的是“造的能力”看的是设备清单与编号、工装与检具状态、过程流程图、控制计划、节拍与产能、关键工序的参数窗口、过程能力研究结果后者确认的是“造出来的东西”看的是尺寸、材料成分、功能试验、外观状态。打个比方这就像开一家餐馆。过程批准是验收厨房灶台是不是固定的、火候稳不稳、厨师是不是那几个人、出餐节拍能不能顶住饭点产品批准是试吃那盘菜。菜好吃但厨房是临时搭的、明天就换地方那这盘菜的好吃没有意义。反过来厨房设备再正规端出来的菜不达标也不能开张。两件事都得过。顺序上产品批准通常以过程批准为前提因为产品是过程的输出。现实项目里两者会并行推进但逻辑依赖不会变过程状态没定产品数据就只是某个瞬间的快照代表不了批产状态。指南里专门强调初始样件必须完全用批产设备和批产条件制造说的就是这层依赖关系。还有一个容易被忽略的点产品批准认可的是一种“产品状态”不是一个批次。所以批准之后图纸版本、材料牌号、软件版本、生产场地任何一项变了这个状态就可能失效需要重新评估。很多质量争议的根源就是把“这批货检验合格”当成了“这个产品已经批准”。2.2 初始样件为什么必须“用正式产线的设备造”指南对初始样件的定义很硬必须完全用批量生产的设备、在批量生产条件下制造出来的产品。它还明确划了一条线——不是完全在批产条件下制造出来的属于“其他样件”其他样件不能用于 PPA。这句话看着像文字游戏实际是一条分水岭。哪些属于“其他样件”手工打磨的、快速成型打出来的、实验室小批量配出来的、借用别的产线凑出来的、拿外购标准件改制出来的、试模阶段参数还没固化就取件的。它们可能完全符合图纸但它们证明不了批产能力。为什么这么较真因为样件是小样本小样本会把差异藏起来。多腔模具里第四腔和第一腔的冷却不一样模具刚开、磨损量还没起来试模时工程师守着机器每件都看一眼正式生产时三班倒、换操作员、环境温湿度波动、节拍被压缩。这些变量在样件阶段统统不出现到了批量阶段集中爆发。用一句血泪经验概括样件合格只能证明“存在一种做出合格件的方法”批产要证明的是“在正常波动下绝大多数件都合格”。类比一下招聘面试表现好只能说明这个人能在那半小时里表现好试用期三个月、换几个项目、赶两次 deadline 之后还稳才说明能力是真的。初始样件的角色相当于让人在真实岗位上干一段时间再看而不是只看面试。所以样件的制造记录必须留得住哪台设备、哪套工装、什么参数、什么批次材料、谁操作、什么时候做的。这些记录不是给审核看的装饰它是“这个样件能代表批产状态”的唯一凭据。记录断了样件就退化成“其他样件”前面做的工作全部作废。2.3 第 6 版删掉“提交等级”之后责任落到了谁头上上一版的逻辑是分级提交客户按等级点菜等级越高交的文件越多供应商照着清单打包就行。第 6 版把这个“提交等级”取消了改成在 PPA 协议里由双方约定范围、内容和时间表。指南给的理由很直白客户的期望各不相同、产品差异太大、可能的文件数量太多用一套固定等级套所有情况反而制造浪费。这个改动方向是对的但它悄悄把责任挪了位置。以前清单是默认值照着交不会错现在清单要谈出来谈漏了就是坑。指南同时强调了组织的执行责任——文件由组织负责编制并对其适用性负责客户不再替你兜底。为了压住文件量第 6 版引入了组织对产品和生产过程的自评估用自评结果去筛选真正需要提交的证据。实际项目里这个变化最容易翻车的地方是“客户口头说随便交点”。口头承诺没有落进协议等客户换了个人接手默认清单又回来了供应商只能返工补文件。所以协议那张表必须在送样之前填完、双方确认哪怕只写三行字。3. 为什么非要这么麻烦供应链接口上的“摩擦成本”从哪来站在单家工厂的角度看PPA 是一堆额外工作写报告、做自评、跑过程能力、陪客户看现场。但把视角拉到整条供应链这些动作其实是在替所有人省钱。一个零件从这家工厂到那家总装厂中间隔着两套质量体系、两套表单习惯、两个项目排期。没有统一动作每次交付都要重新对齐一遍对齐的成本最后都摊进零件价格里。指南的序言里有句话很实在标准化的目的是减少供应商与客户接口之间的摩擦损失。摩擦损失这个词用得很准——它不是某个人做错了什么而是两边节奏不一致自然产生的损耗。PPA 就是把这种损耗提前用约定消化掉。3.1 一次批准替掉几十封来回确认的邮件没有约定程序的时候典型场景是这样的供应商按自己的习惯交了尺寸报告客户说格式不对改完交上去客户说材料声明缺一项补完材料客户说过程能力的数据不是这批样件的再改项目节点已经过了。整个过程没有谁故意为难谁纯粹是两套习惯在碰撞。PPA 的做法是把这个过程前置在动手做样件之前双方先就交付物清单、内容深度、时间节点达成一致。清单一旦定了后面就是照着做而不是边做边猜。听起来只是把沟通提前了实际收益在于消除了“反复猜测对方要什么”的循环。成本账也好算。一条批产线停一天的损失通常是六位数起步而一次完整 PPA 的文档工作量折算成人力也就是几周。用几周换掉一次停线的风险这个交换在任何项目里都划算。真正贵的不是做 PPA是没做 PPA 然后在量产第三个月发现问题。这里还要澄清一个常见误解指南本身写明了它是行业推荐性文件不是法规使用后果由使用者自行负责。真正具有约束力的是客户合同和订单条款。所以“指南里没写”不等于“客户不要”反过来“指南里写了”也不等于“必须原样照抄”。判断依据永远是协议和合同。3.2 触发矩阵什么时候必须把 PPA 重走一遍批产之后才是风险高发期。零件看起来没变但做它的条件变了这类事故最难查。指南用一张触发矩阵来处理这件事把变更类型列成条件对应到是否需要重新走 PPA、走到什么程度。典型触发项包括新零件、新供应商、生产场地迁移、模具复制或转移、材料和分供方变更、工艺或设备变更、软件变更、长时间停产后复产、图纸版本升级。为什么需要一张表而不是靠人判断因为“看起来一样”是最危险的判断。模具从一个车间搬到另一个车间图纸没动、材料没动、设备型号也一样但地基、温湿度、物流路径、操作班组全变了。老师傅凭经验说没事出问题的时候往往就是这种“凭经验说没事”的变更。矩阵的价值在于把判断从个人经验变成团队动作变更一提出来先对照矩阵过一遍该重做的重做该简化的简化。指南还配了分级 PPA、变型批准和小批量等特殊路径就是承认不是所有情况都需要全套动作——同一零件的不同变型可以合并处理小批量可以走简化流程但简化必须是被记录下来的决定不能是悄悄省略。3.3 软件也要进 PPA第 6 版一个明显的变化第 6 版把软件纳入了批准范围还专门准备了软件相关的封面文件。这个变化对习惯了机械件思维的人不太友好但它是必须的。今天的零件里一个执行器、一个控制模块、一个传感器行为很大程度上由烧进去的软件决定。硬件一模一样软件版本差一版输出曲线可能就不同。软件进 PPA 带来的第一个难题是“样件怎么定义”。机械件的样件是实物软件的样件是“特定版本的软件烧录在特定版本的硬件上”两个版本号必须成对记录。第二个难题是变更识别软件改动不一定会改硬件图纸走变更流程时容易被当成“配置调整”漏掉。所以软件版本号、烧录记录、校验值这些信息必须进批准文档和尺寸报告同等对待。指南把软件纳入本质上是承认“产品”这个概念已经不只是几何形状和材料成分。判断一个零件能不能批产得同时看它的物理状态和它的运行逻辑。这条对做嵌入式件的团队尤其重要漏一次软件版本对应关系后面排查故障时就没有后悔药可吃。3.4 批准之后还没完保存期限、材料声明与周期性再验证很多人以为拿到客户批准就结束了其实后半段义务才刚开始。指南里明确列了几项长期要求文件保存期限、组成材料声明、全尺寸检验与功能试验以及偏差处理程序。保存期限决定了出了问题时你能不能自证。批产三年后客户投诉某个批次你需要翻出当年的过程参数、材料批次、检验记录翻不出来就只能认。材料声明则是应对法规和回收要求的基础数据缺了它整车端的合规链条就断一节。全尺寸检验和功能试验不只是批准时做一次它还带有周期性再验证的意味用来确认过程没有随时间漂移。偏差处理是最容易被忽视的一项。批准状态不等于每件产品都完美出现偏差时怎么记录、谁来评估、谁书面同意必须事先约定。没有这条通道现场就会自己发明处理方式而自行发明的处理方式通常不会写进记录。4. PPA 文档为什么像一套数据结构五张表把同一件事说圆把 PPA 的文件摊开看会发现它不像一堆散乱的报告更像一套设计过的数据结构有主键零件号加版本、有字段定义交付物清单、有变更日志零件履历、有校验规则自评表、还有决策表触发矩阵。这个视角挺有用因为一旦把它看成结构你就知道哪张表缺了会导致整个链条断掉而不是机械地按清单凑文件。理解这一点对“数据结构”这个词会有更具体的感受好的结构不是字段越多越好而是每个字段都能回答一个问题且不重复回答同一个问题。4.1 协议表先谈妥范围、内容、时间协议是整套结构的第一张表作用相当于装修开工前那张确认单。它要写清三件事范围即这次批准覆盖哪些零件、哪些变型、哪些生产场地内容即交付物清单和每一项的深度要求时间即各节点的日期和责任人。指南专门为它准备了模板说明这张表在流程里的位置是前置而不是事后补签。为什么协议这么重要因为第 6 版取消了默认的提交等级协议就是唯一的清单来源。协议写得粗后面就靠猜协议写得细后面照着执行。实际项目里最常见的问题不是客户要求高而是要求没写下来双方各自记了一版等到交件时才发现不一致。协议还有一个隐性作用它把“谁决定什么”固定下来。哪些事项供应商可以自评后直接交付哪些必须客户书面确认哪些变更必须先申请写在表里就没有争议空间。质量纠纷里有一大半不是技术分歧而是权限分歧。4.2 自评表把“我准备好了”变成可核对的结论自评表是第 6 版压减文件量的关键机制。组织自己对照产品和生产过程逐条评估得出符合、部分符合、不符合的结论并列出待办项。客户拿到自评结果再决定要看哪些原始证据。这个设计把“全量提交”变成了“按需调阅”。要注意自评不等于自我豁免。它的作用是筛选证据不是替代证据。填“符合”而拿不出支撑材料比不填更糟因为客户会默认你有材料却没提供。自评表填得越老实后面被追问的次数越少——这条几乎是所有做过完整 PPA 的人的共同体会。从数据结构的角度看自评表就是一组布尔校验每个条目对应一个可验证的事实而不是一句形容词。写“过程稳定”没有意义写“关键尺寸的过程能力研究已完成待补多腔模具第四腔数据”才有意义因为它指向一个具体缺口和一个具体动作。4.3 交付物清单与零件履历一个是字段字典一个是变更日志交付物清单规定的是“要交什么、每一项包含哪些要素”相当于字段字典。零件履历记录的是“这个零件从第一次批准到现在经历过什么”相当于变更日志哪次改了材料、哪次换了模具、哪次升了软件版本、每次变更对应哪次批准。这两张表分开看都普通合起来才有威力。清单保证每次提交的结构一致履历保证每次变更可追溯。缺了清单不同项目交的东西没法比较缺了履历一年后没人说得清现在这个状态是怎么来的。现实里最常见的断点是履历。变更发生时大家忙着赶节点履历随手记一句“模具调整”半年后查不出调了什么、调完有没有重新验证。等到客户审核问起来只能靠回忆。4.4 触发矩阵本质是一张决策表触发矩阵看着像一张大表格其实它是一个决策函数输入是变更类型和影响范围输出是“是否重新走 PPA、走到什么程度”。用配置的形式表达会更直观下面这段是示意结构字段名参考指南的附件体系内容为虚构示例不是原文照抄。# 示意结构一份 PPA 记录的最小骨架内容为虚构示例 ppa_record: part: # 产品维度对应产品批准 number: A-0001 variant: [标准型, 加强型] drawing_rev: C # 图纸版本变化会动摇产品批准状态 process: # 过程维度对应过程批准 site: 某工厂二号车间 # 场地迁移通常触发过程重新评估 line_id: L-07 key_equipment: [成型机-01, 检具-03] agreement: # 协议范围、内容、时间 deliverables: [尺寸报告, 材料声明, 过程能力研究, 软件版本清单] due: 2026-03-15 deviation_rule: 偏差须书面申请客户书面同意后方可交付 self_assessment: # 自评筛证据不替代证据 product: 符合 process: 部分符合 open_points: [多腔模具第四腔能力数据待补测] trigger: # 决策输入对应触发矩阵 change_type: 模具复制 software_changed: false requalify: true这段配置的逻辑是把散落的文件压成五个区块每个区块回答一个问题。part和process对应 PPA 的两半是整套记录的主键维度agreement是前置约定决定后面交什么self_assessment是证据筛选器trigger是决策输入。参数上有三处需要特别注意drawing_rev一变产品批准状态基本要重新确认site一变过程批准几乎必然重做software_changed即使硬件没动也要单独评估因为软件改动会改变产品行为而不改变图纸。把这段结构和触发矩阵对照看会发现矩阵并不是额外的 bureaucracy它就是这套数据的一个查询条件给定变更类型返回需要重做哪些区块。理解了这层填表就不再是应付而是在维护一份能被自己和客户同时读懂的状态记录。4.5 偏差与客户决策状态不是二值的指南在批准结果上留了灰度除了批准还有带条件的批准、需要整改后复评、以及不予批准。带条件批准通常附带期限和整改项期限内没闭环状态会退回。这个设计很现实因为批产准备很少有非黑即白的情况。偏差处理程序是配套的出口。发现不符合项时正确动作是记录、评估影响、提出处置方案、取得书面同意而不是现场自行放行。这条写起来平淡实际执行时压力很大——产线在等件客户催货最容易被牺牲的就是那张书面申请。而事后追责时唯一能保护自己的也正是那张纸。5. 最容易混淆的五个概念PPA、PPAP、首件、样件、放行这套体系里的名词密度不低而且很多词看着像同义词实际边界很清楚。搞混一个词往往意味着整段工作做偏方向。下面五个是最常被混的每个都按“混在哪、为什么混、怎么分”说清。5.1 PPA 与 PPAP两套语言说同一件事易混点两者都叫“生产件批准”流程骨架高度相似都要交样件、交文件、等客户点头很多人直接当同义词用。为什么混它们解决的问题确实一样——确认供应链上的过程有能力稳定产出。第 6 版还专门做了交付物层面的协调并附了对比说明两边的文件清单有相当比例可以对应。做过一边的人看另一边会觉得眼熟。怎么区分看来源和默认规则。PPA 是德国汽车行业这套指南里的叫法第 6 版取消了提交等级改由协议约定范围与内容PPAP 是北美体系的叫法长期使用分级提交的逻辑等级决定交哪些文件。同样是交样件一边先谈协议再定清单一边先看等级再点菜。跨国项目里最常见的翻车是拿一边的默认清单去交另一边的客户文件数量看着差不多缺的恰好是对方最在意的那份。5.2 初始样件与普通样件差别不在质量在制造条件易混点两个样件都合格凭什么一个能用、一个不能用。为什么混日常语境里“样件”泛指所有试制件检验合格就算过关。指南里的定义却卡在制造条件上初始样件必须完全用批产设备、在批产条件下制造不完全满足这个条件的属于其他样件不能用于 PPA。怎么区分不看报告看记录。问三个问题就够了——用的是不是批产设备、参数是不是固化后的批产参数、制造时有没有特殊照顾。三个都是“是”才谈得上初始样件。手工修配、试验线小批、试模阶段取件哪怕尺寸全对也只能算其他样件。这条界线不是为了卡人而是因为样件的作用是代表未来批产状态代表不了就没有意义。5.3 产品批准与过程批准一个看输出一个看能力易混点客户签了产品批准很多人就认为整个 PPA 结束了。为什么混产品批准的文件更直观尺寸报告、材料报告、功能试验看得见摸得着过程批准的文件偏“管理”设备清单、控制计划、过程能力容易被当成附件。怎么区分看证据指向什么。产品批准指向“这个状态的产成品符合要求”过程批准指向“这条产线具备重复制造的能力”。两者会同时存在也可能不同步过程批准过了、产品数据还差一项或者产品数据齐了、过程能力还没跑够。判断项目真实进度看的是两者中更慢的那个而不是更快的那份签字。5.4 首件检验、全尺寸检验与 PPA工序动作和跨组织批准不是一回事易混点都是检验都出报告都被塞进同一个文件夹。为什么混形式太像都是一堆测量数据加结论。区别在层级首件检验是工序级的动作每批或每次换型后由生产方自己做确认这一件没问题全尺寸检验是范围更大的验证动作指南把它列为 PPA 的相关要求同时也带有周期性再验证的意味PPA 是跨组织的正式批准结论由客户给出。怎么区分问“谁发起、谁签字、失效条件是什么”。首件检验由生产方发起、内部签字、换型即失效PPA 由协议约定发起、客户签字、变更即可能失效。把首件报告当成 PPA 交付物交上去客户会退把 PPA 当成一次全检内部会漏掉过程能力的部分。5.5 自评与客户审核自己填的表不等于免检易混点自评表填了“符合”就以为客户不会再来现场。为什么混第 6 版确实用自评压减了提交文件量语气上像是“你自己说就行”。怎么区分自评影响的是“交多少文件”不影响“客户信不信”。客户仍然保有决策权也保留现场评估的权利。自评的价值在于把话说清楚、把缺口摆出来自评写得越具体现场审核时被追问的范围越窄。反过来自评全填“符合”却拿不出证据通常招来的是更长时间的现场核查。6. 什么时候该走 PPA什么时候别硬套一张判断表和三条边界判断要不要走 PPA核心不是“客户有没有提”而是“产品状态或过程状态有没有变”。变了一样就得评估两样都变基本要重走。下面这张表是按实际项目整理的粗判逻辑具体仍以协议和合同为准。场景过程状态产品状态建议动作全新零件、新开发全新全新完整 PPA协议先行生产场地迁移改变不变过程重新批准产品视影响复验模具复制或转移改变可能不变触发矩阵评估通常需重新验证材料或分供方变更部分改变可能改变材料声明更新功能与尺寸复验软件版本升级部分改变行为可能改变软件版本记录评估是否重新批准图纸版本升级但尺寸未变不变形式上改变按协议确认是否走简化流程同一厂区、同一设备、仅换工装编号基本不变不变记录变更评估后可能免于重走长时间停产后复产可能漂移不变首件与关键尺寸复验必要时重批三条边界值得单独说。第一条指南是推荐性文件不是法规。它没有强制力真正约束你的是合同和订单。所以“指南要求”这个说法要慎用准确的说法是“协议约定”。反过来客户在合同里写的要求高于指南也完全正常照合同执行。第二条简化必须留痕。分级 PPA、变型批准、小批量简化路径都是指南明确允许的但允许的前提是这次简化被识别、被评估、被记录。悄悄省略和正式简化在事后追责时是天壤之别。第三条文本本身有授权边界。这份资料在页脚带着内部使用与版权声明说明标准文本的传阅和分发是有范围的企业内部学习和对外转发是两回事。需要对照条款逐条核对时翻原件比看二手摘要靠谱尤其是附件里的表格和矩阵摘要在转述时最容易丢字段。我自己的教训是早年接手一个转移项目模具从老厂搬到新厂图纸没动、材料没动、设备型号一样团队一致认为不用重走流程样品直接发了。结果客户在过程能力数据上卡住因为新厂房的温控和物流路径跟老厂不同节拍也被压缩。补做验证花了六周产线等在那里。从那以后我每次接变更不管看起来多小都强制把触发矩阵过一遍把结论写进协议再动手——哪怕结论是“不需要重做”那一行字也得留着。希望帮到你。本文还有配套的精品资源点击获取
