企业官网建设流程全解析

简介：这份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 就是要有证据链：设备清单、工装编号、工艺参数记录、节拍与人员配置。特殊过程（焊接、热处理、涂装、粘接这类结果不能靠后续检验完全验证的工序）还要单独提供过程记录和参数确认，这也是第 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” 是老毛病，正确写法是“新过程”。这类小疏漏在正式文档里很扎眼，交之前至少通读一遍。

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 三种特殊场景：阶梯式、变型、小批量

阶梯式 PPA（stepped 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 是与其他体系的映射表。

附录 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 开始背，而是按“流程—变化—场景—文档”四层过一遍，每层留一个可验证的动作。下面这张表是我自己复习时用的，左边是层次，中间是要能说清的问题，右边是验证方式。能勾满，基本就说明体系在脑子里立起来了。

补漏动作有三个，都不费时间但很有效。第一，把附录 9 的 PPA 与 PPAP 对比表过一遍，用自己的话写出三条“可以复用的证据”和三条“必须重做的证据”，写不出来说明还没真正理解两套体系的边界。第二，挑一个自己做过的零件，用附录 8 的触发矩阵重新评估一次当时的变更，看看按标准是否应该重新走 PPA——这个练习往往能翻出几处当时凭经验放过去的地方。第三，把附录 1 的交付物表裁剪成自己项目的版本，逐行标注“提交/不提交/由自评估决定”，标不下去的行就是知识盲区。

复习到最后，最容易失分的其实不是知识点，而是顺序感。带我的那位前辈说过一句话我记了很久：PPA 的分数不在你交了多少文件，而在你能不能解释每一份文件为什么在这里。从那以后我每次接新项目，都强制走一遍“先协议、再自评估、最后列交付物”的顺序，哪怕客户催得再急也不跳步——跳过的那一步，后面一定会以返工的形式回来。希望这份梳理能帮到你，少走一次弯路就够本了。

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