第三章 供应商审核计划：制定审核计划、确定审核范围与目标、组建审核团队

好，咱们进入正题。审核计划这件事，说白了就是「不打无准备之仗」。我见过太多审核员，到了客户现场才发现「哎？这个项目组怎么还有硬件团队？」或者「这个供应商的ASPICE范围怎么跟合同上写的不一样？」——嗯，这种尴尬，一次就够了。

所以，审核计划不是走流程，它是整个审核活动的「作战地图」。今天我就把这块掰开揉碎了讲清楚。

3.1 制定审核计划：别让计划变成「纸老虎」

我个人习惯，拿到一个供应商审核任务后，第一件事不是翻文档，而是先画时间轴。为什么？因为ASPICE审核最怕的就是时间不够，最后草草收场。

一个标准的审核计划，至少包含以下要素：

• 审核日期与日程安排：每天几点到几点，审核哪个过程域，谁负责提问，谁负责记录。
• 审核地点与方式：现场审核还是远程？如果是远程，网络、摄像头、屏幕共享这些都得提前测一遍。
• 审核对象与接口人：项目经理、开发工程师、测试工程师、质量经理——每个人都要提前约好时间。
• 文档预审清单：哪些文档需要在审核前发过来？比如项目计划、需求规格、测试报告。
• 每日总结与末次会议：每天结束前留30分钟做内部讨论，最后一天留2小时做总结会。

另外，我建议在计划里留出「缓冲时间」。比如你预计审核一个过程域需要2小时，那就排2.5小时。为什么？因为供应商的工程师可能会紧张，说话磕巴，或者突然找不到某个文档。你想想看，这些意外都是常态。

3.2 确定审核范围与目标：别什么都想审

很多新手审核员容易犯一个毛病：恨不得把ASPICE所有过程域都审一遍。结果呢？时间不够，深度不够，最后每个过程都只看了个皮毛。

审核范围怎么定？我一般看三个维度：

维度	说明	我的经验
项目范围	供应商负责开发的子系统或模块	一定要跟合同上的SOW（工作说明书）对齐
过程范围	需要审核的ASPICE过程域	通常选与项目强相关的，比如SYS.2、SWE.1、SWE.6
能力范围	审核到哪个能力等级（CL1还是CL2/CL3）	如果是首次合作，建议先审CL1，别一上来就挑战CL3

举个例子。我之前审核一家做BMS（电池管理系统）的供应商，合同上写的是「负责BMS应用层软件开发」。那我的审核范围就很明确：只审SWE.1到SWE.6，硬件相关的HWE、MEE一概不碰。为什么？因为那不是人家的活儿，你审了也没意义。

3.3 组建审核团队：一个人干不了所有事

我记得刚当审核员那会儿，总觉得自己一个人能搞定所有。结果有一次，我一个人审一个中型项目，从早上8点审到晚上10点，最后脑子都是糊的。第二天发现有个关键问题漏掉了——嗯，从那以后我再也不逞强了。

一个标准的审核团队，通常包括：

• 主审（Lead Assessor）：负责整体把控，主持开闭幕会，协调团队分工。这个人必须有ASPICE主任评估师资质。
• 陪审（Co-Assessor）：负责具体过程域的审核，比如有人专攻需求工程，有人专攻测试。最好有相关技术背景。
• 记录员（Scribe）：负责记录发现项、证据、时间戳。这个角色容易被忽视，但非常重要——没有记录，审核结论就是空话。
• 观察员（Observer）：通常是客户方的人，或者供应商内部的质量人员。他们不参与提问，但可以旁听学习。

另外，团队人数不是越多越好。一般来说，2-3人的核心团队就够了。人多了反而容易乱，而且供应商那边接待也麻烦。你想想看，一个会议室里坐5个审核员，对面坐3个供应商代表，那气氛得多压抑？

3.4 审核计划的常见误区

最后，我总结几个我在项目中踩过的坑，给大家提个醒：

1. 计划太满：每个过程域只排1小时，结果发现供应商的文档体系很乱，光找证据就花了半小时。建议每个过程域至少排1.5小时。
2. 忽略预审：有些审核员到了现场才开始看文档，结果发现文档版本不对，或者关键文档缺失。预审至少提前一周做，把问题暴露在正式审核之前。
3. 目标不清晰：审核目标写得太笼统，比如「评估供应商的过程能力」。结果审核完了，客户问你「到底合不合格？」你答不上来。目标一定要可衡量、可判断。
4. 团队没磨合：主审和陪审是第一次合作，彼此不了解对方的提问风格。建议审核前至少开一次电话会，对齐口径。

好了，关于审核计划这部分，我就讲这么多。说白了，计划做得越细，现场就越顺。别嫌麻烦，这些前期工作，最后都会在审核现场「还给你」——要么是顺畅的节奏，要么是手忙脚乱的补救。你自己选吧。