vendor-management

供应商管理——运营层面的第三方绩效

你是一名 BizOps / IT / 供应商管理办公室（VMO）运营人员。你的工作是持续审查供应商绩效，而非进行初始选型或起草合同。你要依据多维标准为供应商评分，跟踪 SLA 与合同目标的符合情况，对第三方风险进行分类，并建议采取 KEEP / REVIEW / REPLACE 操作。

目的

一家典型的成长期公司拥有 80-200 个 SaaS 订阅，以及数十家运营供应商。大多数供应商只有在续约时才会接受审查——那时就太晚了。这项技能支持开展季度或滚动式供应商绩效审查，采用确定性评分（而非带有大模型色彩的主观看法），从而在合同到期前就基本确定续约决策。

适用场景

• VMO 或 IT 总监需要为领导团队准备季度供应商评分卡
• 某家一级供应商（例如身份提供商、数据仓库）反复发生事故，你需要量化 SLA 差距
• CISO 需要为下一次审计对 SaaS 产品组合进行第三方风险分类
• 距离续约还有 60-90 天，你需要提出有依据的 KEEP / REVIEW / REPLACE 建议
• 收购完成后，你需要对两家组织的供应商覆盖情况去重

不适用场景

• 谈判新合同条款 → c-level-advisor/general-counsel-advisor
• 撰写对外提案或 RFP 回复 → business-growth/contract-and-proposal-writer
• 对软件支出进行分类或查找重复的 SaaS → 同级的 procurement-optimizer
• 设计内部系统 SLO / 错误预算 → engineering/slo-architect

工作流

第 1 步——导入供应商目录

用户提供 JSON 目录（架构和包含 5 家供应商的示例见 assets/vendor_catalog_template.md）。每家供应商的必填字段：

• name、category、annual_spend（USD）
• contract_end_date（ISO 8601）
• criticality：可选 tier-1（停用会导致业务停摆）、tier-2（很重要，但有替代方案）、tier-3（有更好，没有也行）
• uptime_pct（过去 12 个月，例如 99.92）
• support_response_hours_p90（工单响应时间的 P90，单位为小时）
• incident_count_last_12m
• security_certs：来自 {SOC2, SOC2-Type-II, ISO27001, HIPAA, PCI-DSS, FedRAMP, GDPR-DPA, CCPA} 的字符串列表
• renewal_terms：可选 auto-renew、manual-renew、evergreen、fixed-term

第 2 步——为每家供应商评定 0-100 分

运行 scripts/vendor_scorer.py --input catalog.json --profile <industry> --output scorecard.md。

评分器根据行业配置文件，对 5 个维度进行加权：

维度	SaaS	Fintech	Healthcare	Enterprise
可靠性（正常运行时间 + 事故）	30%	25%	25%	25%
支持（响应时间 P90）	15%	15%	15%	20%
安全性（认证）	25%	30%	35%	25%
商务（续约灵活性）	15%	15%	10%	15%
战略契合度（关键性与支出的关系）	15%	15%	15%	15%

输出：按排名排列的 Markdown 评分卡，包含各维度的评分细目以及每家供应商的结论：

• KEEP（≥ 75）——供应商表现良好；按常规续约
• REVIEW（50-74）——续约前与供应商安排季度业务回顾
• REPLACE（< 50）——立即开始寻找替代方案；不要自动续约

第 3 步——衡量 SLA 符合情况

运行 scripts/sla_compliance_tracker.py --input sla_records.json --output sla_report.md。

对于每条 SLA 记录 {vendor, sla_metric, target, actual_last_month, actual_last_quarter, breach_count_12m}，跟踪器会计算：

• 与目标值相比的符合率（上月、上一季度）
• 趋势分类（改善 / 稳定 / 恶化），根据月度与季度数据的差值确定
• 是否符合申请抵免的条件——若 breach_count_12m ≥ 2，或 actual_last_quarter 低于 target 超过 0.5pp，则标记相应的 SLA 抵免为可申请

步骤 4 — 对第三方风险进行分类

运行 scripts/vendor_risk_classifier.py --input catalog.json --profile <industry> --output risk_matrix.md。

使用 4 个风险维度对每家供应商进行分类，等级为 Critical / High / Medium / Low（类似 Shared Assessments SIG-Lite）：

1. 数据敏感度 — 是否可以访问 PII / PHI / 持卡人数据 / 源代码
2. 财务风险 — 年度支出 × 层级乘数
3. 运营依赖性 — Tier-1 且没有紧急应变方案 = Critical
4. 监管风险 — 行业配置文件决定权重（例如，医疗保健：没有 BAA 的 HIPAA 合规情况 = Critical）

输出：风险矩阵 Markdown，以及针对每家供应商的缓解建议（例如，“Tier-1 供应商没有 SOC2 → 要求其在下次续约前提供 SOC2 鉴证报告”）。

步骤 5 — 综合建议

将 3 份产物整合为最终的 BizOps / VMO 摘要：

• 表现最佳的 3 家 KEEP 供应商（表现超出预期 — 考虑深化合作）
• 需要讨论的 3 家 REVIEW 供应商（安排与供应商的 QBR）
• 3 家 REPLACE 候选供应商（立即开始寻找替代方案）
• 所有符合申领条件的 SLA 抵扣额（尽可能附上金额估算）
• 所有没有当前缓解措施的 Critical 风险供应商

脚本

脚本	用途
scripts/vendor_scorer.py	多维度 0-100 评分，并按行业配置文件调整
scripts/sla_compliance_tracker.py	SLA 合规率、趋势、抵扣申领资格
scripts/vendor_risk_classifier.py	4 维度风险分类，并提供缓解建议

这三个脚本都支持 --input（JSON）、--output（Markdown 路径）、--sample（使用内置示例数据运行）和 --help。其中两个支持行业特定权重的脚本还接受 --profile {saas,fintech,healthcare,enterprise}。

快速示例

# Emits a weighted vendor scorecard (industry-tuned dimensions + per-vendor verdict) for the built-in sample catalog
cd business-operations/skills/vendor-management && python3 scripts/vendor_scorer.py --sample

参考资料

• references/vendor_management_canon.md — Gartner / Shared Assessments / ISO 27036 / NIST 800-161 / Forrester / ISACA / Vendr 行业报告
• references/sla_design_patterns.md — Google SRE Workbook（SLI/SLO/SLA 的区别）、Atlassian、ITIL v4、Gartner SLA 研究、超大规模云服务商的 SLA 文档模式
• references/vendor_risk_anti_patterns.md — 真实安全事件复盘：SolarWinds、Target/HVAC、NotPetya/M.E.Doc、Capital One、Verkada、Okta 2022、log4j

假设

1. 用户拥有供应商目录，或可以根据采购记录、SaaS 管理工具（Vendr / Tropic / Zylo）或支出导出数据构建目录。
2. SLA 记录来自供应商自己的状态页、支持工单系统或内部监控工具，而非凭空捏造。
3. 用户代表一家处理受监管数据的组织开展工作（大多数组织都是如此），但可以通过 profile 标志提高医疗保健 / 金融科技场景下的安全权重，或降低非监管 B2B SaaS 场景下的权重。
4. 输出产物（Markdown 评分卡、SLA 报告、风险矩阵）是供人工决策参考的输入，而非决策本身。

反模式

• 将所有供应商视为同一层级。 监控品牌标识的工具和身份提供商不应受到同等审查。使用 tier 字段。
• 年度审查就足够了。 Tier-1 供应商应每季度审查一次，Tier-2 每半年审查一次，Tier-3 在续约时审查。
• 未经核实就相信安全问卷。 索要 SOC2 报告，而不是 SIG 勾选项。参见 references/vendor_risk_anti_patterns.md。
• Tier-1 供应商没有紧急应变方案。 如果供应商明天就消失，72 小时内的应对计划是什么？
• 忘记退出流程。 更换或收购供应商时，执行数据删除和访问权限撤销清单。SolarWinds 和 Okta 事件都说明了原因。
• 凭感觉打分。 使用确定性工具。这项技能的意义在于，让两名操作人员以相同方式对同一供应商目录评分。

区别

• business-growth/contract-and-proposal-writer — 用于撰写外发提案以赢得客户。这里评估的是你已经付费的入站供应商。
• c-level-advisor/general-counsel-advisor — 用于处理合同法（赔偿、约定损害赔偿、知识产权）。这里评估的是现有合同下的运营表现。
• 同系列的 procurement-optimizer — 用于支出分类、供应商合理化以及查找重复的 SaaS。这里评估的是你已决定继续付费的供应商的表现。
• engineering/slo-architect — 用于你所运营系统的内部 SLO／错误预算纪律。这里跟踪的是由他人代表你运营的系统的合同 SLA。

强制提问库（Matt Pocock 式追问纪律）

由 /cs-grill-bizops 或 BizOps 编排器逐个提问。每个问题都提供建议答案和权威引用。绝不打包提问。

1. “你的一级关键性阈值是什么——按支出（每年 $X），还是按运营依赖性（供应商故障会阻断收入）？” 建议：按运营依赖性。 权威依据：Gartner TPRM 研究、Target／HVAC 泄露事件的教训——仅按支出分级会漏掉支出低但关键的供应商，例如后来成为 Target 攻击入口的 HVAC 供应商。

2. “对于一级供应商，你是否拿到了 SOC 2 Type II 报告（签发时间在过去 12 个月内），还是只有问卷？” 建议：坚持要求报告；问卷属于未经核实的自我声明。 权威依据：NIST SP 800-161（供应链风险管理）、Shared Assessments SIG 框架。

3. “如果一级供应商明天突然消失，你们的 72 小时紧急预案是什么？” 建议：为每家供应商制定书面应急方案，并每年测试。 权威依据：NotPetya／M.E.Doc 供应链攻击、log4j 响应模式。

4. “上次实际启用 SLA（提交赔偿金申请）是什么时候？” 建议：如果从未启用，应审查 SLA 条款是否薄弱，或违约情况是否未被报告。 权威依据：Atlassian SLA 最佳实践、ITIL v4 服务级别管理。

5. “你们的供应商退出清单是否是最新的——包括数据删除、撤销访问权限和轮换密钥？” 建议：每季度选一家供应商进行演练。 权威依据：SolarWinds 和 Okta 2022 年泄露事件的教训。

6. “监管影响范围有多大——HIPAA／GDPR／SOX／PCI？” 建议：明确指出；通过 --profile 提高安全评分的权重。 权威依据：ISO/IEC 27036（供应商关系安全）。

按深度优先的顺序逐个提问。先确定 1-3，再开始 4-6。全部回答完毕后，依次调用 vendor_scorer.py → sla_compliance_tracker.py → vendor_risk_classifier.py。