第四章：供应商能力评估

好，咱们进入正题。供应商能力评估这块，说白了就是看对方有没有真本事。我见过太多供应商，PPT做得天花乱坠，一到现场就露馅。所以这一章，我重点讲讲怎么透过现象看本质。

4.1 评估供应商的组织结构

组织结构这事儿，很多人觉得看看组织架构图就行了。我告诉你，没那么简单。我曾经遇到一个供应商，架构图画得特别漂亮，什么PMO、质量部、工程部一应俱全。结果一聊，发现质量部就一个人，还是兼职的。

那到底该怎么看？我习惯从三个维度入手：

• 汇报关系：质量部门向谁汇报？如果质量经理向项目经理汇报，那就有问题了。你想想看，质量部门要是受项目进度压力影响，还能客观把关吗？
• 职责划分：系统工程师和软件工程师的职责边界清不清晰？我见过一家公司，系统需求和软件需求混着写，出了bug互相推诿。
• 决策机制：遇到技术分歧时，谁说了算？是技术负责人拍板，还是项目经理拍板？这直接影响到技术决策的质量。

4.2 评估供应商的项目管理能力

项目管理能力，这是我最看重的部分。为什么？因为ASPICE的核心就是过程管理，项目管理能力直接决定了过程执行的质量。

我个人习惯从这几个方面去考察：

4.2.1 项目计划与跟踪

先看他们的项目计划。不是看计划做得多漂亮，而是看计划的颗粒度和更新频率。我遇到过一家供应商，项目计划就一张Excel表，连WBS都没有。这种计划，说白了就是糊弄人的。

真正好的项目计划，应该具备这些特征：

• 任务分解到人天级别
• 有明确的依赖关系和关键路径
• 每周至少更新一次
• 偏差超过10%就要启动纠正措施

4.2.2 风险管理

风险管理这块，很多供应商都是走过场。我曾经审核过一家公司，风险登记册上列了20多条风险，每条的风险等级都是「低」。你信吗？反正我不信。

真正有效的风险管理，应该做到：

• 风险识别要具体，不能泛泛而谈
• 每个风险都要有明确的应对措施
• 风险状态要定期评审和更新
• 高风险项要有升级机制

4.2.3 沟通管理

沟通管理看似简单，其实最容易出问题。我记得有个项目，供应商每周都发周报，但周报里全是「进展顺利」「按计划进行」这种套话。结果到了里程碑评审，才发现一堆问题。

我建议你关注这几个沟通细节：

• 问题升级的渠道和时效性
• 跨团队沟通的机制（比如有没有定期的技术评审会）
• 沟通记录的保存和追溯

4.3 评估供应商的资源与基础设施

资源和基础设施这块，很多人觉得看看设备清单就行了。嗯，没那么简单。我见过一家供应商，设备清单上写着「配备50台高性能工作站」，结果去现场一看，一半是五年前的老机器，跑个编译都要半小时。

4.3.1 人力资源

人力资源评估，我重点关注三点：

评估维度	具体内容	我的经验
人员稳定性	核心团队的离职率、项目周期内的人员变动情况	我一般会问过去一年核心成员的离职率，超过20%就要警惕
技能匹配度	团队成员是否有相关领域的经验，是否有ASPICE培训经历	别只看简历，我建议做一次简单的技术面试
人员备份	关键岗位是否有备份人员	我曾经遇到一个项目，核心架构师一离职，项目直接停摆

4.3.2 工具与设备

工具链这块，我建议你关注的是工具之间的集成度。很多供应商工具买了一大堆，但都是信息孤岛。需求管理用Word，变更管理用Excel，测试管理用Jira，数据根本对不上。

我比较认可的工具链应该是这样的：

• 需求管理工具和测试管理工具能双向追溯
• 配置管理工具和变更管理工具能联动
• 有统一的度量数据采集平台

4.3.3 工作环境

工作环境这块，很多人觉得不重要。其实不然。我曾经去过一家供应商的办公区，工位挤得像沙丁鱼罐头，电话声此起彼伏。这种环境，工程师能静下心来写代码？我不信。

我一般会关注这些细节：

• 是否有独立的开发测试环境
• 网络带宽是否满足需求
• 是否有必要的防静电、温控措施
• 数据安全措施是否到位（比如门禁、监控、数据加密）

4.4 综合评估与打分

好，前面说了这么多，最后怎么综合评估？我习惯用这个简单的打分表：

评估维度	权重	评分标准（1-5分）
组织结构合理性	15%	1分：职责混乱；3分：基本合理；5分：高效协同
项目管理能力	35%	1分：无规范；3分：有规范但执行差；5分：规范且执行到位
人力资源	25%	1分：人员不稳定；3分：基本稳定；5分：团队成熟
工具与基础设施	25%	1分：工具落后；3分：基本满足；5分：工具链完善

总分低于3分的，我建议你慎重考虑。低于2分的，直接pass。别问我为什么，这都是血泪教训换来的。