VDA 2第6版PPA落地：协议、自评估与文档包管理

简介这份PDF文档为VDA 2 EN第6版2020年4月指南聚焦汽车供应链中的供货质量保障、生产过程与产品批准PPA面向汽车零部件供应商、质量管理及审核人员用于梳理PPA流程中的职责、验证节点和质量控制要求。包内共1个PDF文件大小约341KB便于电脑或移动端查阅适合作为内部培训、供应商审核和体系文件对照的参考资料。内容围绕从设计验证、过程能力分析到初始样件批准、批量生产监控的流程展开并强调数据结构与质量数据管理在问题响应和改进计划中的作用可帮助读者理解PPA各阶段的输入输出及证据要求。文档带有内部使用限定标识使用时需留意版权与合规边界。目前已有534人学习适合需要快速了解VDA 2第6版框架和PPA实施思路的从业者查漏补缺。1. 从目录反推体系VDA 2 第6版管的是哪一段供应链质量很多人第一次翻 VDA 2会以为它是一沓首次样件提交表格翻完目录才发现它更像一份流程协议12 个正文章节加 9 个附录从适用范围、流程启动、协议签订、执行、客户决定一路管到保留期限、材料成分声明和全尺寸检验。它管的对象叫 PPA也就是生产过程与产品批准Production process and product approval范围限定在供应链上新增或变更的供货范围目标是把供应商和客户之间的接口损耗压到最低——约定质量、按时间、按数量、用一条被双方认可的生产过程交付。这份 2020 年 4 月第 6 修订版适合三类人正在准备首次样件提交的项目质量人员、要和客户 SQE 对接的工艺与生产人员、以及备考质量体系却被 PPA 和 PPAP 两个词绕晕的复习者。把它当流程读比当清单读有用得多。2. 流程骨架从启动、协议到客户决定的五个动作VDA 2 的正文前六章是一条直线适用范围 → 启动 → 基本顺序 → 协议 → 执行 → 客户决定。这条直线看起来平淡实际是全篇最容易被跳过、又最容易在后面翻车的部分。很多人直接翻到附录 1 的交付物表就开始准备资料结果做到一半发现范围没约定、提交内容没谈、时间节点和客户理解不一致前面做的全要返工。血泪经验是附录是结果第 2 到第 6 章才是原因顺序反了就会反复补作业。2.1 适用范围与启动先判断这件事到底要不要走 PPA第 2 章 “Range of application” 给出的边界是PPA 针对外部来源和内部来源的新增或变更供货范围。这里有两个关键词——“新增”和“变更”。新增好理解新零件、新产线、新供应商变更才是真正的雷区换模具、换设备、换场地、换原材料牌号、改软件版本都可能触发重新走一遍 PPA而不是简单地在旧报告上改个日期。启动动作第 3 章通常由客户提出也可以由组织主动发起但发起之后第一件事不是做样件而是确认这件事落在 PPA 的适用范围内。这一段里最常被引用、也最容易被忽略的是初始样件的定义。标准明确写PPA 用的样件initial samples必须是完全用批量生产设备、在批量生产条件下制造出来的产品其他样件other samples参照 DIN 55350 第 15 部分是那些没有完全在批量条件下制造出来的产品不能用于 PPA。这句话的分量在于它把“样件”从一个物料概念变成了一个过程证据概念——样件本身合格不够它得是“这条产线、这套工装、这批参数”跑出来的合格。梳理下来会发现一个常见误解有人觉得试制线做出来的件只要检测数据漂亮就能当首次样件交。标准的口径正相反过程来源不对数据再漂亮也不算数。所以启动阶段就要把样件制造计划写清楚哪条线、哪套工装、哪班人、什么参数后面附录 1 的交付物才有支撑。2.2 协议范围、内容、时间三件事必须先谈妥第 5 章 “Agreement on the PPA procedure” 是第 6 版重点强化的部分。前言的措辞很直白这一版强化 PPA 协议目的是在组织和客户之间就 PPA 流程的范围、内容和时间表达成一致。换成日常话说就是在动手做之前双方得先把“做哪些、交什么、什么时候交”写下来。附录 2 给的就是这份协议的表单。为什么这一章值得单独拎出来因为它承担了第 6 版取消提交等级之后的“替代功能”。以前提交量靠等级号一刀切现在等级没了提交量靠协议谈。谈得好双方省事谈不好客户按最严的口径要组织按最省的口径给最后在客户决定环节对撞。协议里我建议至少落死四件事缺一件后面都会扯皮范围哪些零件号、哪些变型、哪些供货范围纳入本次 PPA哪个不纳入。内容交付物清单按附录 1 裁剪到什么程度哪些项因为自评估结果可以减免。时间样件提交日、客户评审窗口、客户决定的预计反馈时间。偏差处理路径出现不符合项时走 6.3 的偏差程序谁提、谁批、多久闭环。这四项里“内容”最容易写得含糊。我的做法是把附录 1 的表 1 直接当底稿逐行标注“提交 / 不提交 / 由自评估决定”双方签字。表格比口头承诺可靠也比邮件往来好追溯。2.3 执行生产过程批准和产品批准是两条腿第 6 章把执行拆成四块6.1 生产过程批准、6.2 产品批准、6.3 PPA 文档与偏差处理程序、6.4 客户对 PPA 流程的决定。很多人把 6.1 和 6.2 混成一件事其实它们的判据完全不同一条腿瘸了都走不到 6.4。维度生产过程批准6.1产品批准6.2审的对象生产线、工装、参数、过程能力样件本身及其检验结果核心问题这条线能不能稳定地做出合格件这批件是否满足图纸与规范典型证据过程能力数据、特殊过程记录、批量条件证明尺寸结果、功能试验、材料成分声明失败后果过程不受控产品数据再好看也不稳产品不合格过程再稳也没意义生产过程批准的关键词是“批量条件”。前面说初始样件必须来自批量设备和批量条件落到 6.1 就是要有证据链设备清单、工装编号、工艺参数记录、节拍与人员配置。特殊过程焊接、热处理、涂装、粘接这类结果不能靠后续检验完全验证的工序还要单独提供过程记录和参数确认这也是第 7 章 “Special processes” 单独成章的原因。产品批准的关键词是“符合性”。尺寸、功能、材料三条线各自出报告第 9 章的材料成分声明和第 10 章的全尺寸检验与功能试验在这里汇合。有一个细节容易被漏全尺寸检验不是抽几个关键尺寸量一下它指的是对图纸上标注的尺寸做完整测量工作量比常规检验大得多排计划时必须单独留时间。6.3 的偏差处理程序是这套流程里的“后悔药”。发现某份交付物暂时给不出、或者某项指标临界不合格正确动作是走偏差程序申报并取得书面处置意见而不是自己判断“问题不大”就先交上去。6.4 客户决定则是终点客户基于前面所有材料给出批准、有条件批准或拒绝。有条件批准最考验人因为条件项必须在约定时间内闭环否则前面的工作等于白做。提示6.3 的偏差程序和“偷偷改数据”是两件性质完全不同的事。前者是流程允许的申报通道后者一旦被发现丢掉的不只是一次批准。3. 四个改版动作取消提交等级、自评估、软件集成与 PPAP 对齐第 6 版前言列出的变化清单不长但每一条都在改写日常做法。把这些变化读透比背附录表格更能应付客户的提问。前言里明确提到的几点是取消提交等级、强化组织的执行责任、引入产品与生产过程自评估以减少提交文件量、修改批准等级、纳入软件、以及与 AIAG 的 PPAP 流程协调交付物。下面按影响面从大到小拆。3.1 取消提交等级从“按号交卷”变成“按协议交卷”第 5 版曾经把 PPA 流程做过一次结构性重构到第 6 版提交等级submission levels被直接取消。前言给的理由很实在客户的期望不同、产品差异大、可能的文档数量太多用一个等级号套所有场景不现实。这个变化带来的连锁反应是责任转移。以前等级号是挡箭牌——“客户让我按某个等级交我就交这些”。现在等级没了交多少由协议约定而协议里写什么取决于组织对自己产品和生产过程的自评估结论。换句话说提交量的决定权部分回到了组织手里同时责任也回到了组织手里。省下来的文件是真省但判断失误带来的返工也是真返工。我见过一个典型翻车某项目把“取消等级”理解成“可以减少提交”在协议里把过程能力报告划掉了理由是产线是老线、历史数据好看。客户评审时问了一句“这次换了工装过程能力凭什么沿用旧数据”整个 PPA 被打回重做。取消等级不等于降低要求它只是把“交什么”从编号规则变成了论证责任。3.2 自评估用一份问卷换回一堆文件自评估附录 3 产品与生产过程自评估配套附录 4 的 PPA 报告与评价封面是第 6 版最实用的一个工具。逻辑很简单组织先按统一口径给自己的产品和过程打分评估结果好提交文件量可以减少评估结果差就得老老实实把证据交全。这相当于把“交多少文件”从拍脑袋变成了有依据的推理。用的时候要注意两点。第一自评估不是自夸评估项要落到证据上比如“过程能力充分”这一项背后得有具体的 Cp/Cpk 数据和取样方案否则客户一问就穿帮。第二自评估结论和实际提交物必须自洽——自评估说过程稳定结果交付物里连过程能力报告都没有这种矛盾在评审时非常刺眼。自评估倾向建议的提交策略风险点各项充分、有历史数据支撑按协议裁剪保留关键证据裁剪过度客户要求补充部分项存疑、缺数据存疑项全交充分项裁剪存疑项描述含糊被整体质疑多项不充分、新process全量提交并附改进计划改进计划无责任人无节点上面第三行里的 “新process” 是老毛病正确写法是“新过程”。这类小疏漏在正式文档里很扎眼交之前至少通读一遍。3.3 软件纳入 PPA附录 5 不是摆设第 6 版把软件集成进了 PPA 体系并单独给了附录 5 “Cover sheet PPA software”。这条变化对做嵌入式件的团队影响最大以前软件版本是“附带的”现在它需要一个独立的封面、独立的版本标识和硬件的批准状态并列管理。实操上的坑在于版本对应关系。硬件样件对应哪个软件版本、这个版本刷在哪批样件上、客户批准的是哪个组合这三件事必须能对上。我建议在文档包里单独建一个软件板块放封面、版本清单和刷写记录不要和硬件报告混在一个文件夹里。第 4 章会给一个具体的目录结构。3.4 与 AIAG PPAP 对齐附录 9 是给跨体系团队省时间的供应链上常见的局面是同一个零件欧洲客户要 PPA北美客户要 PPAP项目组两头准备重复劳动。第 6 版明确做了交付物的协调附录 9 就是 PPA 与 PPAP 的对比表。这张表的价值不在于谁优谁劣而在于让团队知道哪些证据可以复用、哪些必须重做。梳理下来的一般差异是这样的PPAP 以提交等级和要素清单为入口等级号直接决定交什么PPA 第 6 版取消了等级改由协议加自评估确定范围流程感和协商感更强。两者对样件来源、过程审核、材料声明的底层要求高度重叠重叠部分就是可以一次准备、两处复用的部分。附录 9 逐条列了对应关系做双体系项目时把它打印出来贴在工位上比反复问人快。4. 特殊场景与文档包阶梯式 PPA、变型批准、小批量以及附录怎么用正文第 7 到第 10 章处理的是“例外”和“收尾”阶梯式 PPA、变型批准、小批量、保留期限、材料成分声明、全尺寸检验与功能试验。这几章篇幅不大但在实际项目里出问题的频率不低因为它们对应的正是那些“不太标准”的场景而现实中的项目很少完全标准。4.1 三种特殊场景阶梯式、变型、小批量阶梯式 PPAstepped PPA procedure针对的是分阶段推进的项目比如先批准某个工序或某个总成层级再逐级向上批准。它的价值是把一次大批准拆成若干次小批准让长周期项目能提前暴露问题。风险在于阶段划分必须提前约定否则每一级都可能被客户追问“上一级的结论凭什么成立”。变型批准PPA for the approval of variants处理的是一个零件族里多个变型的关系。常见做法是先批一个主变型其余变型通过差异分析覆盖。这里最容易漏的是差异清单——变型之间到底差在哪尺寸、材料、软件还是工艺必须写清楚否则“覆盖”就成了没有依据的推断。小批量small series场景下的 PPA核心矛盾是样本量和过程稳定性。批量小过程能力数据天然不足这时候更要靠协议把判据谈明白用多少样本、接受什么样的置信区间、后续量产爬坡时怎么补充验证。指望用一句“量太小没法做”糊过去通常会在客户决定环节被顶回来。4.2 保留期限、材料声明、全尺寸检验三个收尾动作第 8 章保留期限retention periods规定的是 PPA 相关记录存多久。这件事平时没人管等到客户来做体系审核或者发生质量追溯时才想起找文件是最典型的“用的时候才发现没有”。建议在项目启动时就把保留期限写进文档管理规则和零件生命周期绑定而不是等归档时凭记忆。第 9 章材料成分声明declaration of constituent materials要的是可追溯的材料构成信息。它的难点不在填表而在供应链上游——二级供应商不给数据一级供应商就填不完整。所以这项工作必须前置到采购定点阶段不能等到 PPA 提交前才去要。第 10 章全尺寸检验与功能试验layout inspection and functional testing前面提过它的工作量被严重低估。全尺寸意味着图纸上每一个标注尺寸都要测包括那些平时不检的参考尺寸和理论正确尺寸之外的要素。排期时按常规抽检的工作量估算基本一定会延期。4.3 附录清单就是交付物的数据字典把 9 个附录列出来看会发现它们不是零散的附件而是一套结构化的交付物定义。用数据结构的眼光看附录 1 是字段定义附录 2 到 8 是各类表单的结构约束附录 9 是与其他体系的映射表。附录内容在文档包中的角色附录 1PPA 交付物说明表 1字段清单决定交什么附录 2PPA 流程协议元数据锁定范围与时间附录 3产品与生产过程自评估过滤器决定提交量附录 4PPA 报告与评价封面索引页附录 5PPA 软件封面软件板块的入口附录 6零件历史变更追溯链附录 7触发矩阵使用说明规则解释附录 8触发矩阵变更是否重新触发 PPA 的判定表附录 9PPA 与 PPAP 对比跨体系映射附录 6 的零件历史和附录 8 的触发矩阵是一对。零件历史记录这个零件经历过哪些变更和批准触发矩阵则告诉你什么样的变更需要重新走 PPA、走到哪一步。很多人变更之后直接复用旧报告就是因为没查触发矩阵。把这两个附录当成“变更的入口判断”比当成归档材料有用得多。4.4 用一套目录结构把文档包管起来交付物一多最容易出的问题不是缺内容而是找不到。我习惯按附录的板块划分建目录一个零件一次变更一个包包内按批准逻辑分六段# PPA 文档包目录结构按 VDA 2 第 6 版章节与附录组织 PPA_零件号_变更代号/ ├── 00_协议与触发/ │ ├── PPA-协议.pdf # 附录 2双方签字版 │ ├── 触发矩阵评估.pdf # 附录 7/8说明本次变更为何触发或未触发 │ └── 零件历史.xlsx # 附录 6历次变更与批准记录 ├── 01_自评估/ │ ├── 产品与过程自评估.pdf # 附录 3 │ └── PPA-报告封面.pdf # 附录 4 ├── 02_生产过程批准/ │ ├── 批量条件证明.pdf # 设备、工装、参数记录对应 6.1 │ ├── 过程能力报告.pdf │ └── 特殊过程记录.pdf # 第 7 章涉及的特殊工序 ├── 03_产品批准/ │ ├── 尺寸报告.pdf # 第 10 章全尺寸检验 │ ├── 功能试验报告.pdf │ └── 材料成分声明.pdf # 第 9 章 ├── 04_软件/ │ ├── 软件封面.pdf # 附录 5 │ └── 版本与刷写清单.xlsx └── 05_客户决定/ └── 客户批准结论.pdf # 6.4 的书面结论与条件项闭环记录这套结构的逻辑是跟着批准链走而不是跟着部门走。00 段回答“为什么做、做到什么程度”01 段回答“凭什么少交”02 和 03 段是两条腿的证据04 段独立管软件版本05 段收口。参数上只有三处需要替换零件号、变更代号、以及各段内文件的命名前缀命名前缀建议统一成“板块号-文件类型-版本”例如02-过程能力报告-v1.2.pdf这样排序即版本序。目录建好之后缺件还是靠人眼扫所以我又写了一小段脚本把附录 1 的交付物清单变成一个可校验的字典。好处是每次打包前跑一遍缺什么直接列出来不用一条条对from pathlib import Path # 交付物清单的数据结构板块 - 必备文件 PPA_REQUIRED { 00_协议与触发: [PPA-协议.pdf, 触发矩阵评估.pdf, 零件历史.xlsx], 01_自评估: [产品与过程自评估.pdf, PPA-报告封面.pdf], 02_生产过程批准: [批量条件证明.pdf, 过程能力报告.pdf], 03_产品批准: [尺寸报告.pdf, 功能试验报告.pdf, 材料成分声明.pdf], 04_软件: [软件封面.pdf, 版本与刷写清单.xlsx], 05_客户决定: [客户批准结论.pdf], } def check_package(pkg_dir: Path, skip()): pkg_dir文档包根目录skip本次可整段跳过的板块 missing [] for section, files in PPA_REQUIRED.items(): if section in skip: # 纯硬件件可跳过 04_软件 continue for name in files: if not (pkg_dir / section / name).exists(): missing.append(f{section}/{name}) return missing if __name__ __main__: miss check_package(Path(./PPA_12345_B2)) print(缺件, miss if miss else 无)这段代码没什么技巧价值全在数据结构上把散落在附录 1 里的交付物整理成“板块—文件”的两层字典校验逻辑就自然成立了。pkg_dir传文档包根目录skip用来处理特殊场景——比如纯硬件件不需要软件板块传skip(04_软件,)即可。真正要维护的是PPA_REQUIRED这个字典协议里裁掉的项要从字典里同步删掉否则每次跑都报缺件跑几次就没人看了。5. 易漏点清单PPA 落地时最容易翻车的五处标准和实操之间永远有一段距离这段距离在 PPA 上体现得特别明显因为它的交付物多、参与方多、时间跨度长。下面五条是我梳理下来出错频率最高的地方每条按“漏在哪、为什么漏、怎么补”写。5.1 用非批量条件做出来的样件充当初始样件易漏点样件是试制线或者手工工装做出来的检测数据合格就当成首次样件提交了。为什么漏项目排期紧产线还在调试试制线出件快而且样件本身确实合格从数据上看不出问题。怎么补把样件制造条件作为独立证据收进文档包——设备编号、工装编号、工艺参数记录、生产班次。02 段的“批量条件证明”就是干这个的。如果确实只能用非批量条件出件那是“其他样件”不能用于 PPA得走偏差程序说明并约定后续用批量件补做。5.2 协议没签就先开工范围靠猜易漏点客户口头说“先做着”组织就开始准备交付物做到一半发现范围理解不一致。为什么漏协议流程看起来慢项目进度看起来急先做后补好像是效率更高的选择。怎么补把附录 2 的协议当成启动的前置条件哪怕先用一页纸把范围、内容、时间三件事写清双方确认也强过没有。范围里必须明确零件号和变型清单这个清单后面会直接决定 7.2 变型批准怎么做。5.3 自评估全打高分把过滤器用成了装饰易漏点附录 3 的自评估各项都勾“充分”实际提交文件却支撑不住这些结论。为什么漏自评估的表单看起来像自查问卷勾完就完事没有和交付物清单联动。怎么补每一项自评估结论后面挂一个证据编号指向 02/03 段里的具体文件。勾“过程能力充分”就必须能指到那份过程能力报告。做不到这一点这一项就退回“不充分”老老实实交全。5.4 软件版本游离在 PPA 之外易漏点硬件报告齐全软件版本只在邮件里说过附录 5 的封面没填版本和样件的对应关系也没记录。为什么漏软件更新节奏比硬件快很多人把它当成“后面再刷”的事。怎么补在文档包里固定一个 04_软件 板块封面、版本清单、刷写记录三件套齐全任何一个硬件样件批次的批准结论里都要写明对应的软件版本。变更软件版本时回到触发矩阵判断是否触发重新批准。5.5 变更后不看触发矩阵直接复用旧报告易漏点换了工装或者换了场地觉得零件还是那个零件旧 PPA 报告改个日期继续用。为什么漏附录 8 的触发矩阵需要逐项对照费时间而且旧报告的结论确实“看起来还成立”。怎么补把触发矩阵评估做成变更流程的强制卡点任何变更单提交时必须附一份评估记录写清楚触发了哪几项、需要重新批准到哪一步。这份记录放进 00 段后面客户问起来直接调。注意这五条里有三条的根子都在“00 段”——协议、触发、零件历史。把入口环节做扎实后面四个段的返工会少很多。6. 复习清单一张能勾选的自查表和三个补漏动作复习 VDA 2 不要从附录 1 开始背而是按“流程—变化—场景—文档”四层过一遍每层留一个可验证的动作。下面这张表是我自己复习时用的左边是层次中间是要能说清的问题右边是验证方式。能勾满基本就说明体系在脑子里立起来了。层次要能说清的问题验证方式流程启动、协议、执行、客户决定各自产出什么不看文档手画一遍五步流程图变化第 6 版取消了提交等级后提交量由什么决定用一句话向别人解释协议与自评估的关系场景阶梯式、变型、小批量分别适用于什么项目各举一个自己项目里的例子文档九个附录分别放在文档包哪一段对着目录树指一遍不缺段补漏动作有三个都不费时间但很有效。第一把附录 9 的 PPA 与 PPAP 对比表过一遍用自己的话写出三条“可以复用的证据”和三条“必须重做的证据”写不出来说明还没真正理解两套体系的边界。第二挑一个自己做过的零件用附录 8 的触发矩阵重新评估一次当时的变更看看按标准是否应该重新走 PPA——这个练习往往能翻出几处当时凭经验放过去的地方。第三把附录 1 的交付物表裁剪成自己项目的版本逐行标注“提交/不提交/由自评估决定”标不下去的行就是知识盲区。复习到最后最容易失分的其实不是知识点而是顺序感。带我的那位前辈说过一句话我记了很久PPA 的分数不在你交了多少文件而在你能不能解释每一份文件为什么在这里。从那以后我每次接新项目都强制走一遍“先协议、再自评估、最后列交付物”的顺序哪怕客户催得再急也不跳步——跳过的那一步后面一定会以返工的形式回来。希望这份梳理能帮到你少走一次弯路就够本了。本文还有配套的精品资源点击获取