4.8 外包与供应商评估
一句话
评估供应商不是 “打分排名”，而是 硬门槛淘汰 + 加权打分 + 敏感性检验：先排除 “不满足合规/稳定底线” 的，再比综合分，最后看 “权重一变，冠军会不会换”。
加权打分实测
5 个维度、3 家供应商（10 分制）：
| 供应商 | 功能 | 稳定 | 安全合规 | 成本 | 服务 |
|---|---|---|---|---|---|
| A | 9 | 7 | 6 | 8 | 7 |
| B | 7 | 9 | 9 | 5 | 8 |
| C | 6 | 6 | 8 | 9 | 6 |
默认权重（功能 .30 / 稳定 .25 / 安全合规 .20 / 成本 .15 / 服务 .10）：
| 供应商 | 得分 | 结论 |
|---|---|---|
| A | 7.55 | — |
| B | 7.70 | 胜出 |
| C | 6.85 | — |
把 “合规/成本” 加重（.15/.25/.25/.25/.10）：A 7.30、B 7.60、C 7.25 —— 冠军没变，但差距从 0.15 收窄到 0.30。这说明 “结论对权重不敏感” 是可接受的前提；反过来，若换个权重就换冠军，说明评分本身不稳健，需要更多证据或更硬的判据。
def score(v, w): return round(sum(w[k]*v[k] for k in w), 2)
print(score({"功能":9,"稳定":7,"安全合规":6,"成本":8,"服务":7}, w_default))
先设硬门槛（不参与打分）
| 门槛 | 判据 |
|---|---|
| 合规 | 是否有等保/ISO/SOC2 等资质（见 3.1 等级保护与网络安全法） |
| 稳定 | SLA 是否 ≥ 99.9%，有无赔付条款 |
| 数据 | 数据能否导出、能否删除、存储在哪 |
| 财务 | 供应商经营状况（避免 “跑路”） |
不满足门槛的，直接淘汰，不允许用 “功能分高” 补。
反模式
| 反模式 | 后果 |
|---|---|
| 只比功能与价格 | 忽略合规/稳定，后期返工 |
| 权重由 “谁声音大” 定 | 结论不可复现，换人即翻案 |
| 不做敏感性分析 | 换个权重就换冠军，决策不稳健 |
| 把 “演示好看” 当 “能落地” | PoC 与生产差异大（见 4.3 技术选型的评估维度） |
| 不写退出条款 | 数据导不出、迁移成本高 |
| 只看报价不看总成本 | 实施/定制/运维费用被低估 |
三条铁律
🔑 先门槛、后打分；合规不达标，功能再强也不选。
🔑 权重必须提前定并留档；否则结论无法复现。
🔑 必须做敏感性分析：权重变一点，结论会不会翻。
自检
Q1 为什么 “硬门槛” 不能折算成分数？
▸ 答案：因为门槛是一票否决：合规不达标、数据不能导出，这些风险无法用 “功能多给 2 分” 抵消。把门槛折成分数，会让 “高分但违规” 的供应商胜出，事后整改成本远超收益。
Q2 敏感性分析具体怎么做？
▸ 答案：把每个权重在合理区间内调整（如成本 .10–.35），重算得分与排名；观察 “冠军是否变化、领先幅度多大”。若小幅调整就换冠军，说明评分不稳，需要补充证据或引入硬判据。
Q3 为什么 “演示效果” 不能代表生产可用性？
▸ 答案：因为演示通常用理想数据与理想环境：小数据量、无并发、无网络抖动。生产上会暴露性能、稳定性、集成复杂度问题。PoC 要按生产规模与真实依赖验证（见 57.1 压测方法论）。
Q4 外包时最该写进合同的技术条款是什么？
▸ 答案：四类：SLA 与赔付、数据归属与导出（含退出时的迁移支持）、安全与审计（渗透测试、日志）、知识产权与代码交付。没有 “数据导出 + 退出支持”，就等于把命门交出去。
Q5 单一供应商风险怎么缓解？
▸ 答案：三条：接口抽象（避免直接依赖厂商 SDK，留适配层）、双供应商/备选方案（至少验证过替代品）、定期退出演练（模拟迁移一次）。成本是 “多一层抽象”，收益是 “不被绑定”。
Q6 评分卡应该由谁维护？
▸ 答案：由技术 + 采购 + 安全 + 业务共同维护：技术定功能/稳定权重，安全定合规门槛，业务定成本与服务权重。单一部门定权重，必然偏向自己的 KPI。
Q7 什么情况下应该 “不选” 而不是 “打折选”？
▸ 答案：当门槛不达标、或敏感性分析显示 “结论不稳” 且无法补证时。勉强选择一个 “高分但擦线” 的供应商，等于把风险延后到上线后——那时换供应商的成本更高。