简介这份资源是德国汽车工业协会VDA发布的VDA 2 EN 6th 2020英文版指南聚焦供应链质量保障中的生产过程与产品批准PPA环节面向汽车行业质量管理、供应商审核及供应链合规相关从业者与学习者。内容围绕PPA流程展开涵盖合格供应商选择、设计验证、过程能力分析、初始样件批准、批量生产与质量监控等关键节点并延伸至数据管理、实时监控与质量改进计划的制定为构建标准化质量管理框架提供理论与实践支持。资源为单一PDF文件压缩包约341KB便于下载后直接查阅与检索。目前已有531人学习下载适合需要系统了解VDA 2最新版要求、对照自身质量管理体系查漏补缺的读者参考使用。1. 从一份被内部水印锁死的 PPA 手册说起如果你在汽车供应链做质量或项目工程师大概率遇到过这种局面客户甩过来一份 VDA 2 的 PPA 要求问你“提交等级怎么定、初始样件算不算、软件要不要单独批”你翻遍公司共享盘只找到 2012 年的第五版附录里的提交清单还是老结构。这份 VDA 2 EN 6th 2020 就是来填这个坑的——它是德国汽车工业协会质量管理中心发布的《供应链质量保障生产过程和产品批准PPA》第六次修订版2020 年 4 月定稿正文加九个附录把 PPA 从启动、协议、执行到偏差处理整条链路重新捋了一遍。适合谁看主机厂和 Tier 1 里负责新零件导入、PPAP/PPA 文件包编制、供应商质量放行的人以及需要把 PPA 和 AIAG 的 PPAP 对齐的跨区域项目组。它不教你写代码但教你判断“这份材料到底该不该交、交给谁、什么时候交”。2. 第六版到底改了什么从提交等级到软件批准的结构变化2.1 取消提交等级改为“协议 自评估”双轮驱动第五版最被诟病的一点是提交等级Submission Levels——供应商按等级交文件客户按等级收文件双方都容易陷入“为了凑等级而交”的形式主义。第六版直接把提交等级拿掉了换成两个动作一是组织和客户就 PPA 的范围、内容、时间计划达成协议Agreement on the PPA procedure二是组织自己对产品和生产过程做自评估Self-assessment。这个改动的逻辑是客户期望千差万别产品复杂度也不同与其用固定等级框死不如让双方在项目早期把“交什么”谈清楚。自评估的结果直接决定提交文件的多少——自评估做得扎实提交量就降下来自评估糊弄客户照样会追着要。常见做法是在项目启动会上就把 PPA 协议模板附录 2过一遍逐项确认哪些交付物适用、哪些不适用把结论写进协议里签字。这一步不做后面一定扯皮。2.2 软件批准被正式纳入 PPA 范围第六版明确把软件含嵌入式软件纳入 PPA 的批准对象附录 5 专门给了 PPA 软件封面页。这意味着以前“硬件走 PPA、软件走另一套”的做法不再成立。对于带 ECU、传感器、智能执行器的零件软件版本、软件成熟度、软件与硬件的匹配验证都要在 PPA 文件包里体现。实际操作中软件批准和硬件批准可以并行推进但最终客户决策时看的是软硬件合在一起的成熟度。2.3 与 AIAG PPAP 的交付物对齐附录 9 给了一张 PPA 与 PPAP 的对比表这是给同时供德系和美系客户的供应商看的。核心差异在于PPAP 有明确的提交等级Level 1-5PPA 第六版没有PPAP 的 PSWPart Submission Warrant在 PPA 里对应的是 PPA 报告封面页附录 4加零件历史附录 6。对齐的目的是让供应商能用一套底层数据同时生成两套文件包减少重复劳动。但注意对齐不等于等同——客户特定要求CSR仍然优先。2.4 触发矩阵什么情况下必须重新做 PPA附录 7 和附录 8 是触发矩阵的说明和矩阵本身。触发矩阵回答的是一个很实际的问题量产后发生了变更换材料、换设备、换场地、改图纸、软件升级要不要重新提交 PPA矩阵按变更类型和影响程度给出“必须重新批准 / 通知即可 / 无需动作”三档判断。这个工具用好了能省大量无效沟通用不好就是漏批或过度批。提示触发矩阵的判断依据是“对产品特性、过程特性、客户接口的影响”不是变更大小。一个看似很小的材料批次变更如果影响到了关键特性照样触发重新批准。3. 把 PPA 流程拆成可执行的五步从启动到客户决策3.1 启动与协议谁发起、谈什么、什么时候签PPA 流程的启动通常由客户在询价阶段或定点后发出要求但第六版强调“组织也可以主动发起”。启动后第一件事是约定 PPA 协议协议内容至少覆盖适用零件范围、交付物清单基于附录 1 的 Table 1 裁剪、提交时间节点、客户决策方式、偏差处理路径。协议模板在附录 2但不要直接填模板了事——模板里的每一项都要和客户逐条确认。一个可复用的协议检查清单如下检查项确认内容常见遗漏零件范围零件号、版本、变更状态变型件是否覆盖交付物按 Table 1 逐项勾选软件交付物漏勾时间节点初始样件提交日、PPA 报告提交日与项目里程碑脱节决策方式客户书面批准 / 有条件批准 / 拒绝未约定回复时限偏差处理谁提出、谁批准、如何记录口头同意未留痕协议签完后组织内部要把交付物任务分解到人尤其是初始样件的生产计划——初始样件必须用批量生产设备、在批量生产条件下制造这一点在 6.1 节写得很死。用试制设备或手工样件代替客户有权直接拒收。3.2 生产过程批准初始样件与过程能力生产过程批准的核心证据是初始样件Initial Samples。第六版对初始样件的定义没有松动必须完全用批量生产设备、在批量生产条件下制造。其他样件如手工样件、试制样件不能用于 PPA。初始样件的数量、标识、测量报告要求通常在 PPA 协议里约定没有约定时按客户标准执行。过程能力方面PPA 要求对关键特性做过程能力分析Cpk / Ppk。常见做法是初始样件阶段用 Ppk批量阶段用 CpkPpk 的目标值通常要求 ≥ 1.67Cpk ≥ 1.33但具体数值以客户要求为准。如果过程能力不达标不能直接交 PPA 报告要先走偏差处理6.3 节。3.3 产品批准尺寸、材料、功能与软件产品批准覆盖四个维度尺寸Layout Inspection、材料Declaration of Constituent Materials、功能Functional Testing、软件Software Approval。尺寸检验要求全尺寸报告材料声明要求按客户指定的格式提交IMDS 或客户自有系统功能测试要求覆盖图纸和规范上的所有功能特性。软件批准在附录 5 有专门的封面页需要填写软件版本、软件成熟度、软硬件匹配验证结论。一个容易翻车的地方是尺寸报告只测了图纸上的标注尺寸漏了未标注但影响装配的参考尺寸。客户审核时发现直接退回。稳妥做法是把图纸上所有尺寸含参考尺寸和规范上的所有功能特性列成矩阵逐项确认测量方法和结果。3.4 偏差处理与客户决策PPA 执行过程中出现偏差过程能力不足、尺寸超差、材料替代、软件缺陷时不能隐瞒要走偏差处理流程。第六版 6.3 节要求偏差必须书面记录包括偏差描述、原因分析、临时措施、长期措施、对产品的影响评估。客户决策有三种结果批准Full Approval、有条件批准Conditional Approval、拒绝Rejection。有条件批准通常附带整改期限和追加提交要求。注意有条件批准不等于可以批量供货。在整改完成并通过客户验证之前供货状态仍然受限具体以客户书面通知为准。3.5 保留期与再提交PPA 文件的保留期在 8 节有规定通常是零件停产后若干年具体年限以客户要求为准。保留期内如果发生触发矩阵定义的变更需要重新提交 PPA。重新提交的范围可以比首次小但触发矩阵判定为“必须重新批准”的变更不能只做通知。4. 附录里的九个工具Table 1、自评估表、触发矩阵怎么用4.1 附录 1 Table 1交付物清单的裁剪逻辑Table 1 是 PPA 交付物的总清单但第六版明确说这不是“每项都要交”。裁剪逻辑是先看零件类型新零件 / 变更零件 / 沿用零件再看客户特定要求最后看自评估结果。自评估得分高的组织可以申请减少部分交付物如过程审核报告、部分尺寸报告。但涉及安全特性Safety Characteristics和法规要求的交付物不能裁剪。4.2 附录 3 自评估表怎么打分才不会被客户挑战自评估表覆盖产品设计和生产过程两个维度每个维度下有若干问题按成熟度打分。打分的依据是客观证据不是主观感觉。常见做法是每个问题对应一份证据文件如 DFMEA、PFMEA、控制计划、过程流程图打分时附上证据编号。客户审核时会抽查证据如果打分高但证据弱整个自评估的可信度就没了。4.3 附录 8 触发矩阵变更管理的判断工具触发矩阵是一个二维表纵轴是变更类型设计变更、过程变更、材料变更、场地变更、软件变更等横轴是影响程度对产品特性、过程特性、客户接口的影响。交叉点给出动作重新批准、通知、无需动作。使用时的关键是“影响程度”的判断要有依据不能拍脑袋。建议由跨职能团队设计、工艺、质量、采购一起判定并记录判定理由。4.4 附录 9 PPA vs PPAP一张表看懂两套体系的差异维度VDA 2 PPA第六版AIAG PPAP提交等级无改为协议 自评估Level 1-5初始样件必须批量条件必须批量条件软件批准纳入 PPA附录 5视客户要求报告封面附录 4 PPA 报告封面PSW零件历史附录 6无直接对应触发矩阵附录 8变更管理流程这张表的实际用法是同时供德系和美系客户时用一套底层数据尺寸报告、材料报告、过程能力报告分别生成 PPA 和 PPAP 文件包避免重复测量和重复测试。5. 避坑与排查五个真实翻车场景5.1 初始样件用了试制设备客户直接拒收现象PPA 报告提交后客户审核发现初始样件的生产设备与批量生产设备不一致整包退回。原因项目赶进度试制设备空闲就先用试制设备做了样件以为“尺寸合格就行”。解决初始样件必须用批量生产设备、在批量生产条件下制造。如果批量设备尚未到位要么等设备到位要么和客户协商调整 PPA 时间计划不能先用试制样件顶上。5.2 自评估打分过高客户抽查证据对不上现象自评估表上过程审核项打了高分客户抽查时发现过程审核报告是两年前的且未覆盖新产线。原因自评估由一个人闭门填写没有跨职能评审打分依据是“以前做过”。解决自评估必须由跨职能团队完成每项打分附证据编号和日期。证据过期或范围不符的要么补做要么降分。5.3 软件版本变更未触发重新批准现象量产后软件从 V1.2 升级到 V1.3供应商认为“只是小版本修复”未通知客户客户在售后发现问题后追溯。原因触发矩阵未使用或使用了但把软件变更归为“无需动作”。解决软件变更必须走触发矩阵判定。涉及功能、性能、接口、安全特性的软件变更通常触发重新批准纯界面文字修改可归为通知类。判定理由要记录。5.4 偏差处理只有口头同意没有书面记录现象过程能力不达标供应商口头向客户工程师说明客户口头说“先交吧”后续客户换人后不认账。原因偏差处理未按 6.3 节要求书面化。解决任何偏差都要有书面记录包括客户书面回复。口头同意只能作为临时沟通不能作为 PPA 批准依据。5.5 保留期文件丢失客户追溯时无法提供现象零件停产后第三年客户因售后问题追溯 PPA 文件供应商发现部分尺寸报告和过程能力报告已丢失。原因未按 8 节要求建立保留期管理制度文件散落在个人电脑里。解决PPA 文件包在提交客户的同时要在组织内部归档到受控系统保留期按客户要求设定到期前评估是否延长。6. 进阶用法用触发矩阵和自评估把 PPA 工作量压下来触发矩阵和自评估表这两个工具用好了能显著减少 PPA 的重复工作量。我自己的习惯是在项目启动阶段就把触发矩阵的判定规则和客户对齐把“什么变更需要重新批准”写进 PPA 协议。这样量产后发生变更时不需要每次重新谈判直接查矩阵执行。自评估表则用来做内部预审——在正式提交客户之前先按自评估表过一遍把证据薄弱的项补强把可以裁剪的交付物和客户确认。这样正式提交时客户审核的退回率会低很多。一个具体的操作技巧是把触发矩阵和自评估表做成 Excel 工具触发矩阵用下拉菜单选择变更类型和影响程度自动输出动作建议自评估表每项关联证据文件链接打分时强制填写证据编号。这样跨职能团队填写时不容易漏项客户审核时也能快速追溯。验证方法方面可以在下一个变更项目上做一次对照一组按老流程走不查矩阵、不填自评估一组按新流程走比较两组的 PPA 提交次数、客户退回次数和项目周期。通常新流程的首次提交通过率会明显更高因为交付物清单在协议阶段就对齐了不会出现“交了客户不要的、客户要的没交”的情况。从那以后我每次接手新零件的 PPA都强制走一遍“协议确认 → 自评估预审 → 触发矩阵判定”这三步哪怕项目再赶也不跳过。希望帮到你。本文还有配套的精品资源点击获取
