供应商绩效管理
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @user_3c6cb52e/vendor-management。
技能介绍
问题:续签时才发现问题已经太晚
一家中型公司通常同时挂着 80-200 个 SaaS 订阅和几十个运营类供应商。绝大多数供应商只在续签窗口期被看一次,而那时你已经没有议价筹码,也不清楚过去 12 个月它到底表现如何。等到 identity provider 连续出事故、或者审计前才临时翻安全问卷,往往已经晚了。
这个技能面向 BizOps / IT / VMO 角色,做的是存量供应商的持续绩效复盘,而不是选型或合同起草。
工作方式
输入是一份 JSON 格式的供应商清单,每条至少包含 name、category、annual_spend、contract_end_date、criticality(tier-1/2/3)、uptime_pct、support_response_hours_p90、incident_count_last_12m、security_certs、renewal_terms。随后按四个步骤产出确定性结果:
- 评分:
scripts/vendor_scorer.py按可靠性、支持、安全、商务、战略匹配五个维度打 0-100 分,权重随--profile(saas / fintech / healthcare / enterprise)变化,避免“看起来像 LLM 的主观意见”。 - SLA 核对:
scripts/sla_compliance_tracker.py计算合规率与趋势,低于合同目标 0.5 个百分点即标记可索赔的 SLA credit。 - 风险分级:
scripts/vendor_risk_classifier.py沿数据敏感度、财务敞口、运营依赖、合规暴露四条向量给出 Critical / High / Medium / Low,并附带缓解建议。 - 建议汇总:输出 Top 3 KEEP / REVIEW / REPLACE、可索赔金额、以及无缓解措施的 Critical 供应商清单。
同一目录下的 references 收录了 Gartner、NIST SP 800-161、ISO 27036、Shared Assessments 等资料,以及 SolarWinds、Target、Okta 2022 等真实供应链事故复盘。另有一组 forcing questions,用于在评分前先确认 tier-1 阈值、SOC 2 Type II 报告是否在手、72 小时 break-glass 预案和 offboarding 清单是否可用。
适用边界
它不做新合同谈判(→ general-counsel-advisor)、不写对外方案(→ contract-and-proposal-writer)、不做支出归类和重复 SaaS 排查(→ procurement-optimizer)、也不设计内部 SLO(→ slo-architect)。
几点容易踩的坑:不要把所有供应商当成同一优先级,criticality 字段就是为此存在的;不要只看问卷而不看 SOC 2 报告本身;不要给 tier-1 供应商留一个没有 break-glass 计划的单点依赖;替换或收购后别忘了数据删除与权限回收。所有输出都是给人决策用的输入,不是决策本身。
使用场景
- 季度末要向管理层交付一份覆盖上百个SaaS的供应商评分卡,按行业权重打分并给出KEEP、REVIEW、REPLACE结论。
- 身份提供商连续出事故,需要用uptime、P90响应时长和事故次数量化SLA缺口,并估算可索赔的credit金额。
- 审计前要把整个供应商组合按数据敏感度、财务敞口、运营依赖、合规暴露四条向量做风险分级并附缓解措施。
- 距续签还有60到90天,需要一份可辩护的KEEP、REVIEW、REPLACE建议交给采购与法务,而不是凭感觉决定去留。
适合人员
- BizOps或VMO运营:需要按固定口径给存量供应商打分,保证不同人跑出来的评分卡一致,能直接进季度评审会。
- IT总监或基础设施负责人:需要把tier-1供应商的事故和SLA缺口量化成数字,向管理层解释是否继续合作或要求整改。
- CISO或安全合规岗:需要在审计前对第三方组合做风险分级,并拿到具体缓解措施,例如要求对方提供SOC 2 Type II报告。
- 采购或供应商管理岗:需要在续签窗口前产出可辩护的KEEP、REVIEW、REPLACE建议,作为谈判、缩减或替换的依据。