中文翻译《ASPICE in practice》之“ACQ.4 供应商监控”

仅供参考，欢迎指正！

2.1 ACQ.4 供应商监控

2.1.1 目的

供应商监控过程的目的是根据商定的要求监控供应商的绩效。

除了讨论供应商监控之外，这个过程还涉及与供应商的合作和沟通。 合作的基础是选择供应商并且客户与供应商之间存在合同协议。

MAN 过程和 SUP 过程中的方法可应用于供应商监控，例如项目管理、风险管理、测量和变更管理，但客户在此应用它们来监控供应商。

如果开发外包给供应商，则必须协调过程接口。 除了工程过程之外，还应该协调特别的支持过程，例如配置管理、变更管理和质量保证。

有关供应商管理的更多信息，请参阅：

1.  [SA-CMM 1999] 软件获取能力成熟度模型
2.  [DoD 1998] 软件采购最佳实践计划
3.  [PPSM 1998] 过程专业供应商管理第 1-7 部分

2.1.2 汽车行业特有的特点

在 ECU 的开发过程中，汽车制造商和供应商经常密切合作。 在某些情况下，开发几乎完全由供应商完成，而其他汽车制造商可能会购买已经开发的组件，只需要进行少量修改。

复杂的电子汽车组件通常由多个合作供应商开发。 这种网络化的发展经常会产生商业伙伴关系。 通常，其中一个供应商被委托充当系统供应商，其任务包括控制其他供应商。

这通常会导致供应商关系的整个层次结构，即一个供应商（“一级”）从自己的分包商（“二级”）那里获取更多的系统组件，但仍然控制着合作。 通常，客户规定供应商分包特定的二级供应商。 在汽车开发中，供应商的选择和控制通常具有特别重要的意义。

评估员注意事项

如果供应商（一级）有分包商（二级），则仅在 OEM 供应商评估中评估此过程。 它评估供应商如何监控和控制自己的供应商。 如果开发是分包的或者购买的产品组件需要适应项目的要求，则应用该过程。 如果仅购买资源用于开发活动（通常称为“车身租赁”），或者购买不需要任何改造的标准产品（“COTS 产品”），则过程评估就没有意义。 这是因为 ACQ.4 需要开发过程的强大互连，但这在这些情况下并不适用。

a. 在这种情况下，租赁员工按照客户流程工作； 如果需要，他们会像内部员工一样在评估中受到质疑。

b. COTS 商业现货。

2.1.3 基本实践

BP1：就联合流程和联合接口达成一致。

就联合流程和联合接口、责任、联合活动的类型和频率、沟通、会议、状态报告和审查达成协议。 至少就变更管理、问题管理、质量保证和客户验收的过程和界面达成一致。

注：本流程中的术语“客户”是指被评估方。 供应商一词是指被评估方的供应商。

在项目执行期间，必须协调并记录客户和供应商之间的过程和接口。 这包括以下内容：

1. 关于定期会议和审查的协议（参见BP2至4）。
2. 通信和接口的规划和控制，例如通过通信计划（见图3-5和第3章，对GP 2.1.6的审议）。
3. 有关工作产品和信息交换的规则，例如，应提供哪些工作产品、数据交换格式、传输方法（例如，电子邮件加密或通过公共服务器进行通信，相互访问联合项目数据和文档） )。
4. 角色和职责的协调。
5. 规划和协调共同活动的流程和工作流程。基本实践至少要求变更管理和问题解决管理、质量保证和验收。 还建议制定联合测试规则（至少涉及联合协调的测试策略）以及配置管理规则，包括客户提供的产品的发布计划以及跨组织边界的一致可追溯性（另请参见第 2.24 节）。
6. 定义处理问题的升级路径； 如果涉及多个供应商，这一点尤其重要。 由各方代表组成的指导委员会可以作为最高决策机构。
7. 例如，使用常见的未决问题列表（OIL，见图 2-3）跟踪未决问题。 如果有多个供应商，则可能会出现相同的问题，如上一个项目符号的脚注中所解释的那样。
8. 关于供应商向客户出具项目状态报告以及交换项目计划的规则。
9. 客户和供应商在质量保证方面的合作。

在客户和供应商之间建立联合项目团队是一种良好的做法。 这样，双方就可以分配可靠的（主要）角色（例如，负责 ECU 功能开发的工程师），他们可以从项目一开始就进行合作。

BP2：交换所有相关信息。

建立并维护客户和供应商之间所有商定信息、流程和接口的沟通。

按照 BP1 中的约定，定期交换信息。 在整个项目期间必须保留商定的沟通。

BP3：与供应商一起审查技术开发。

定期与供应商一起审查开发情况，涵盖技术方面、问题和风险。

项目中必须保持持续的沟通，特别是在技术方面，以确保供应商了解技术要求，并确保所有工作都按计划正确完成。 这主要通过定期项目会议来完成，会议重点关注技术问题、问题和风险。 在大多数情况下，开发项目过程中有很多技术问题需要澄清，并且根据 BP5，所有这些问题都必须跟踪直至完成。

此外，技术工作产品和文件应在联合技术审查中进行评估，特别是以下类型：

1. 客户需求规格/系统需求规格
2. 系统架构（对于系统供应商而言）
3. 软件架构
4. 接口规格
5. 测试计划
6. “测试准备”
7. 用户文档及其他已商定的开发文档
8. 验收测试（关于客户验收）

我们认为，在开发过程中尽早采用适当的审查方法（例如检查）进行技术审查是有益的（另见 SUP.4）。

BP4：审核供应商的进度。 

定期审查供应商在进度、质量和成本方面的进展，并跟踪问题以成功完成并执行风险缓解活动。

定期检查供应商的进度。 根据计划检查项目进度，并讨论重大问题（包括质量问题）、风险和进度（特别是截止日期变化和预测）。 如果工作按时间和材料计费，则还会根据成本计划检查应计成本。 此外，还评估了成本预测。

Automotive SPICE 还要求针对已识别的风险启动缓解活动，并跟踪已识别的问题和措施直至完成（参见 BP5）。 因此，项目中的风险管理（参见 MAN.5）必须扩展到涵盖客户与供应商合作产生的风险。

如果要在客户项目中整合和协调多个供应商，则这种做法尤其重要。 在这种情况下，所有供应商活动的总体项目状态和客户的活动都必须作为一个整体进行组合和监控。 在这种情况下，建议（向所有利益相关者）公开沟通总体状况，以便每个人都了解他们对总体工作的贡献。 这种透明度还有一个额外的好处，那就是它间接创造了竞争，从而促进了项目的进展（没有人想成为最后一个）。 为了能够客观地跟踪供应商的项目进度，我们建议通过指标来跟踪进度（参见 MAN.6 和图 2-27）。

进度监控还应包括对正在运行的项目中商定的改进措施（BP6）的监控。

经验报告

供应商经常以非常乐观的态度介绍项目进展。 因此，客户应该严格质疑这些估计（例如，在状态报告或项目计划中）。 此外，应尽早商定初始交付，以便更好地跟踪当前项目状态。

通常，问题是由于客户合作不善造成的； 通常，供应商必须等待很长时间才能得到答复（例如，技术问题），可能需要很长时间才能做出决定，或者急需的领域专家无法或仅部分可用。 网络开发的另一个问题是客户提供的组件通常无法按时提供或不足（例如用于测试目的的原型）。

BP5：跟踪未清项目。

记录发现的未清项目，将其传递给供应商并跟踪它们直至关闭。

为了确保所有已确定的未清项目按计划关闭，应使用通用的未清问题列表（OIL，见图 2-3）来系统地跟踪这些问题。 该列表可用于跟踪客户和供应商的未决问题。

图 2-3 未决问题列表 (OIL) 的示例布局

BP6：采取行动纠正偏差。

在未实现商定目标时采取行动，纠正与商定项目计划的偏差，并防止已发现的问题再次发生。

如果在项目过程中及其进展监测过程中发现与计划的偏差，表明无法实现商定的目标，则必须采取适当的措施。 除了要求采取措施纠正此类偏离计划外，Automotive SPICE 还要求采取措施消除或消除其原因。

BP7：同意变更。

对任何一方提出的商定活动的变更进行协商，并将结果记录在协议中。

在项目的整个生命周期中，必须在客户和供应商之间部署明确且系统的变更管理过程（参见 SUP.10）。 除了协调变更之外，还需要记录结果。 这里必须指出，变更可能不仅涉及技术问题，还涉及定义的流程、实践、协议、合同等。

经验报告

在固定价格项目中，如果实施变更导致供应商成本增加，客户与供应商的关系通常会受到损害。 因此，许多客户回避发出正式的变更请求； 相反，更改请求会非正式地传递给供应商或隐藏为错误报告。 在系统开发中，如果应用新技术并且项目结果是演进过程的结果，这种情况就会加剧。 在这种情况下，需求只能定义不充分（即不完整或细节不足），并且只能在开发过程中一点一点地传递给供应商。 在这种情况下，必须相应地调整变更管理流程。 例如，可以达成协议，通过变更管理流程正式引入变更请求，但它们仅在特定条件下才变得具有成本效益。

2.1.4 指定工作产品

02-01 承诺/协议

任何类型的有效且具有约束力的协议。 协议必须记录下来，以便可验证并对所有各方具有约束力（例如，作为商定会议记录的一部分，甚至可能通过签名确认）。 ACQ.4 指客户和供应商之间的协议。

13-01验收记录

根据 [Hindel et al. 2006],验收记录由实际记录本身和所附的缺陷清单组成。 有关缺陷列表的基本信息可在 SUP.9、工作产品 15-12（问题状态报告）中找到。 验收记录应包含以下附加信息：

1. 项目数据（项目名称、订单号、订单日期、客户等）
2. 根据发布计划接受的所有产品的列表，除了实际（子）系统外，还包括所有交付的文档和随附材料（收件人、交付日期、标识符（包括版本信息等）
3. 日期、地点、参与验收过程的各方（包括分配给供应商或客户）
4. 验收类型（例如，部分验收或最终验收）
5. 与验收相关的其他输入和/或输出文档的参考
6. 测试或验证结果
7. 验收结果（以及，如果需要，后续步骤，例如缺陷纠正或重新验收）
8. 客户和供应商双方签名

13-09会议支持记录

客户和供应商之间的会议应使用包含以下内容的会议记录进行记录：

1. 会议目的、议程、地点、日期和时间以及参与者
2. 做出的决定和其他相关结果
3. 未解决的问题（如果需要，这可以是一个单独的列表，见图 2-3）
4. 如有必要，下次计划会议的日期
5. 分发列表

13-14 进度状态记录

请参阅 MAN.3，工作产品 15-06（项目状态报告）。

13-16 变更请求

解释参见 SUP.10

13-17 客户要求

客户向供应商发出的变更请求。 解释参见 SUP.10

2.1.5 Level 2 的特点

论绩效管理

在项目开始时，必须根据BP1（协调流程接口、协调角色和职责、定义升级路径等）协调和规划客户和供应商之间的沟通。 在项目过程中，所有定期会议、进度审查和验收（部分和最终）均已计划，并跟踪其绩效和合规性。

关于工作产品管理 

作为沟通过程的一部分，根据 BP1 达成一致的所有供应商工作产品都将接受审查，并置于版本和变更管理控制之下。 除了商定的中间和最终交付外，这还适用于供应商商定的计划文件和进度报告。 如果需要，变更请求也将被审查。 人们可能还希望就建立联合配置管理系统达成一致，并对工作产品进行相应的版本控制和更改。