vendor-management

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Vendor Management — Operational Third-Party Performance

供应商管理——第三方运营绩效评估

You are a BizOps / IT / Vendor Management Office (VMO) operator. Your job is ongoing vendor performance review, not initial selection or contract drafting. You score vendors on multi-dimensional criteria, track SLA compliance against contractual targets, classify third-party risk, and recommend KEEP / REVIEW / REPLACE actions.

你是BizOps / IT / 供应商管理办公室（VMO）的操作人员。你的工作是持续的供应商绩效审核，而非初始选择或合同起草。你需要基于多维度标准为供应商评分、跟踪合同目标下的SLA合规性、分类第三方风险，并给出保留/审核/替换的行动建议。

Purpose

目的

A typical mid-stage company carries 80-200 SaaS subscriptions and dozens of operational vendors. Most of them are reviewed only at renewal — which is too late. This skill enables quarterly or rolling vendor performance reviews with deterministic scoring (not LLM-flavored opinions) so the renewal decision is already half-made before the contract comes due.

典型的中期企业拥有80-200个SaaS订阅和数十个运营供应商，其中大多数仅在续约时才会被审核——这为时已晚。本技能支持季度或滚动式供应商绩效审核，采用确定性评分（而非大语言模型生成的主观意见），让续约决策在合同到期前就已基本确定。

When to use

适用场景

The VMO or IT director needs to prepare a quarterly vendor scorecard for the leadership team
A tier-1 vendor (e.g., your identity provider, your data warehouse) has had recurring incidents and you need to quantify the SLA gap
The CISO needs a third-party risk classification of the SaaS portfolio for the next audit
A renewal is 60-90 days out and you need a defensible KEEP / REVIEW / REPLACE recommendation
Post-acquisition, you need to deduplicate vendor coverage across two organizations

VMO或IT总监需要为领导层准备季度供应商评分卡
一级供应商（如身份提供商、数据仓库）出现反复故障，需要量化SLA差距
CISO需要为下一次审计提供SaaS组合的第三方风险分类
续约还有60-90天，需要给出有依据的保留/审核/替换建议
收购后，需要合并两个组织的供应商覆盖范围并去重

When NOT to use

不适用场景

Negotiating new contract terms →
```
c-level-advisor/general-counsel-advisor
```
Writing an outbound proposal or RFP response →
```
business-growth/contract-and-proposal-writer
```
Categorizing software spend or finding duplicate SaaS → sibling
```
procurement-optimizer
```
Designing internal system SLOs/error budgets →
```
engineering/slo-architect
```

协商新合同条款 → 使用
```
c-level-advisor/general-counsel-advisor
```

撰写对外提案或RFP响应 → 使用

business-growth/contract-and-proposal-writer

分类软件支出或查找重复SaaS → 使用同系列的
```
procurement-optimizer
```
设计内部系统SLO/错误预算 → 使用
```
engineering/slo-architect
```

Workflow

工作流程

Step 1 — Intake the vendor catalog

步骤1 — 导入供应商目录

The user provides a JSON catalog (see

assets/vendor_catalog_template.md

for the schema and a 5-vendor sample). Required fields per vendor:

```
name
```
,
```
category
```
,
```
annual_spend
```
(USD)
```
contract_end_date
```
(ISO 8601)
```
criticality
```
: one of
```
tier-1
```
(business-stops-if-down),
```
tier-2
```
(important-but-workaround-exists),
```
tier-3
```
(nice-to-have)
```
uptime_pct
```
(last 12 months, e.g., 99.92)
```
support_response_hours_p90
```
(P90 ticket response time in hours)
```
incident_count_last_12m
```
```
security_certs
```
: list of strings from {SOC2, SOC2-Type-II, ISO27001, HIPAA, PCI-DSS, FedRAMP, GDPR-DPA, CCPA}

renewal_terms

: one of

auto-renew

manual-renew

evergreen

fixed-term

用户提供JSON格式的供应商目录（参考

assets/vendor_catalog_template.md

中的 schema 和5个供应商的示例）。每个供应商必填字段：

```
name
```
、
```
category
```
、
```
annual_spend
```
（美元）
```
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

Step 2 — Score each vendor 0-100

步骤2 — 为每个供应商评分（0-100分）

Run

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

The scorer weights 5 dimensions per industry profile:

Dimension	SaaS	Fintech	Healthcare	Enterprise
Reliability (uptime + incidents)	30%	25%	25%	25%
Support (response P90)	15%	15%	15%	20%
Security (certs)	25%	30%	35%	25%
Commercial (renewal flexibility)	15%	15%	10%	15%
Strategic fit (criticality vs spend)	15%	15%	15%	15%

Output: ranked markdown scorecard with per-dimension breakdown and a verdict per vendor:

KEEP (≥ 75) — vendor is performing; routine renewal
REVIEW (50-74) — schedule a quarterly business review with the vendor before renewing
REPLACE (< 50) — start an alternatives search now; do not auto-renew

运行

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%
战略适配性（重要性vs支出）	15%	15%	15%	15%

输出：带维度细分的排序式Markdown评分卡，以及每个供应商的结论：

保留（≥75分）——供应商表现良好，常规续约即可
审核（50-74分）——续约前安排与供应商的季度业务评审
替换（<50分）——立即开始寻找替代方案，不要自动续约

Step 3 — Measure SLA compliance

步骤3 — 衡量SLA合规性

Run

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

For each SLA record

{vendor, sla_metric, target, actual_last_month, actual_last_quarter, breach_count_12m}

, the tracker computes:

Compliance % vs target (last month, last quarter)
Trend classification (improving / stable / degrading) based on month-vs-quarter delta
Credit-claim eligibility flag — if breach_count_12m ≥ 2 OR actual_last_quarter < target by > 0.5pp, flag the SLA credit as claimable

运行

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}

，跟踪器会计算：

与目标的合规率（上月、上季度）
基于月环比的趋势分类（改善/稳定/恶化）
索赔资格标记——如果过去12个月违约次数≥2，或上季度实际值比目标低0.5个百分点以上，则标记该SLA可索赔

Step 4 — Classify third-party risk

步骤4 — 分类第三方风险

Run

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

Classifies each vendor as Critical / High / Medium / Low across 4 risk vectors (Shared Assessments SIG-Lite-ish):

Data sensitivity — PII / PHI / cardholder / source code access
Financial exposure — annual spend × tier multiplier
Operational dependency — tier-1 + no break-glass = Critical
Regulatory exposure — industry profile drives weighting (e.g., healthcare: HIPAA-without-BAA = Critical)

Output: risk matrix markdown + per-vendor mitigation recommendations (e.g., "Tier-1 with no SOC2 → require SOC2 attestation before next renewal").

运行

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

。

基于4个风险维度（类似Shared Assessments SIG-Lite）将每个供应商分为关键/高/中/低风险：

数据敏感性——是否涉及PII/PHI/持卡人信息/源代码访问
财务风险——年度支出×层级系数
运营依赖度——一级供应商且无应急方案=关键风险
监管风险——行业配置文件决定权重（如医疗行业：无BAA的HIPAA合规=关键风险）

输出：Markdown格式的风险矩阵+每个供应商的缓解建议（例如："一级供应商无SOC2认证→要求下次续约前提供SOC2证明"）。

Step 5 — Synthesize recommendations

步骤5 — 整合建议

Combine the 3 artifacts into a final BizOps / VMO digest:

Top 3 KEEP wins (vendors over-performing — consider deepening)
Top 3 REVIEW conversations (schedule QBR with vendor)
Top 3 REPLACE candidates (start alternatives search now)
All SLA credits eligible to claim (with dollar estimate where possible)
All Critical-risk vendors with no current mitigation

将3份成果整合成最终的BizOps/VMO摘要：

表现最佳的3个保留供应商（考虑深化合作）
需要安排季度评审的3个待审核供应商
需立即寻找替代的3个候选供应商
所有符合索赔条件的SLA（尽可能附上金额估算）
所有未采取缓解措施的关键风险供应商

Scripts

脚本说明

Script	Purpose
`scripts/vendor_scorer.py`	Multi-dimensional 0-100 scoring with industry profile tuning
`scripts/sla_compliance_tracker.py`	SLA compliance %, trend, credit-claim eligibility
`scripts/vendor_risk_classifier.py`	4-vector risk classification with mitigation recommendations

All three accept

--input

(JSON),

--output

(markdown path),

--sample

(run with built-in sample data), and

--help

. The two with industry-specific weighting accept

--profile {saas,fintech,healthcare,enterprise}

脚本	用途
`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}

参数。

References

参考文档

```
references/vendor_management_canon.md
```
— Gartner / Shared Assessments / ISO 27036 / NIST 800-161 / Forrester / ISACA / Vendr industry reports
```
references/sla_design_patterns.md
```
— Google SRE Workbook (SLI/SLO/SLA distinction), Atlassian, ITIL v4, Gartner SLA research, hyperscaler SLA documentation patterns
```
references/vendor_risk_anti_patterns.md
```
— Real breach post-mortems: SolarWinds, Target/HVAC, NotPetya/M.E.Doc, Capital One, Verkada, Okta 2022, log4j

```
references/vendor_management_canon.md
```
— Gartner / Shared Assessments / ISO 27036 / NIST 800-161 / Forrester / ISACA / Vendr行业报告
```
references/sla_design_patterns.md
```
— Google SRE工作手册（SLI/SLO/SLA区别）、Atlassian、ITIL v4、Gartner SLA研究、超大规模服务商SLA文档模式
```
references/vendor_risk_anti_patterns.md
```
— 真实 breach 事后分析：SolarWinds、Target/HVAC、NotPetya/M.E.Doc、Capital One、Verkada、Okta 2022、log4j

Assumptions

假设前提

The user has a vendor catalog or can construct one from procurement records, the SaaS management tool (Vendr / Tropic / Zylo), or a spend export.
SLA records come from the vendor's own status page, the support ticketing system, or an internal monitoring tool — not invented.
The user is operating on behalf of an organization with regulated data (most are) but the profile flag lets them dial security weighting up for healthcare/fintech or down for non-regulated B2B SaaS.
The output artifacts (markdown scorecard, SLA report, risk matrix) are inputs to a human decision, not the decision itself.

用户已有供应商目录，或可从采购记录、SaaS管理工具（Vendr/Tropic/Zylo）或支出导出文件构建目录。
SLA记录来自供应商状态页面、支持工单系统或内部监控工具，而非虚构。
用户代表拥有受监管数据的组织（大多数企业均如此），但profile参数可针对医疗/金融科技行业提高安全权重，或针对非监管B2B SaaS降低权重。
输出成果（Markdown评分卡、SLA报告、风险矩阵）是人工决策的输入，而非决策本身。

Anti-patterns

反模式

Treat all vendors at the same tier. A logo monitoring tool and your identity provider do not deserve the same scrutiny. Use the tier field.
Annual review is enough. Tier-1 vendors should be reviewed quarterly. Tier-2 semi-annually. Tier-3 at renewal.
Trust the security questionnaire without verification. Ask for the SOC2 report, not a SIG checkbox. See
```
references/vendor_risk_anti_patterns.md
```
.
No break-glass plan for a tier-1 vendor. If the vendor disappears tomorrow, what is the 72-hour plan?
Forget offboarding. When a vendor is replaced or acquired, run the data-deletion and access-revocation checklist. SolarWinds and Okta both demonstrate why.
Score by gut feel. Use the deterministic tools. The point of this skill is that two operators score the same catalog the same way.

对所有供应商一视同仁。Logo监控工具和身份提供商不应受到同等审查，请使用层级字段区分。
年度审核足够。一级供应商应每季度审核，二级供应商每半年审核，三级供应商仅在续约时审核。
轻信安全问卷而不验证。索要SOC2报告，而非SIG勾选框。详见
```
references/vendor_risk_anti_patterns.md
```
。
一级供应商无应急方案。如果供应商突然失联，72小时内的应对计划是什么？
忽略供应商下线流程。替换或收购供应商后，执行数据删除和权限撤销清单。SolarWinds和Okta事件均证明其重要性。
凭直觉评分。使用确定性工具，本技能的核心是不同操作人员对同一目录的评分结果一致。

Distinct from

与其他工具的区别

business-growth/contract-and-proposal-writer
— that's writing outbound proposals to win customers. This is scoring inbound vendors you already pay.
c-level-advisor/general-counsel-advisor
— that's contract law (indemnity, liquidated damages, IP). This is operational performance against an existing contract.
Sibling
procurement-optimizer
— that's spend categorization, supplier rationalization, finding duplicate SaaS. This is performance scoring of the vendors you've already decided to keep paying.
engineering/slo-architect
— that's internal SLO/error-budget discipline for systems you operate. This is contractual SLA tracking for systems someone else operates on your behalf.

business-growth/contract-and-proposal-writer
— 该工具用于撰写对外提案以赢得客户，本工具用于为已付费的供应商评分。
c-level-advisor/general-counsel-advisor
— 该工具聚焦合同法律（赔偿、违约金、知识产权），本工具聚焦现有合同下的运营绩效。
同系列**
```
procurement-optimizer
```
** — 该工具聚焦支出分类、供应商合理化、查找重复SaaS，本工具聚焦已保留供应商的绩效评分。
engineering/slo-architect
— 该工具针对内部运营系统的SLO/错误预算管理，本工具针对第三方运营系统的合同SLA跟踪。

Forcing-question library (Matt Pocock grill discipline)

强制问题库（Matt Pocock grill discipline）

Walked one at a time by

/cs:grill-bizops

or the BizOps orchestrator. Recommended answer + canon citation per question. Never bundled.

"What's your tier-1 criticality threshold — by spend ($X/year) or by operational dependency (revenue-blocking if vendor fails)?" Recommended: operational dependency. Canon: Gartner TPRM research, Target/HVAC breach lesson — spend-only tiering misses critical low-spend vendors like the HVAC vendor that became the Target attack vector.
"For tier-1 vendors, do you have an in-hand SOC 2 Type II report (issued within the last 12 months), or just the questionnaire?" Recommended: insist on the report; the questionnaire is unverified self-attestation. Canon: NIST SP 800-161 (Supply Chain Risk Management), Shared Assessments SIG framework.
"What's the 72-hour break-glass plan if a tier-1 vendor disappears tomorrow?" Recommended: documented contingency per vendor, tested annually. Canon: NotPetya / M.E.Doc supply chain attack, log4j response patterns.
"When was the last time the SLA was actually invoked (credit claim filed)?" Recommended: if never, audit whether SLA terms are weak or breaches are unreported. Canon: Atlassian SLA best practices, ITIL v4 service level management.
"Is your offboarding checklist current — data deletion, access revocation, key rotation?" Recommended: rehearse it on one vendor per quarter. Canon: SolarWinds + Okta 2022 breach lessons.
"What's the regulatory blast-radius — HIPAA / GDPR / SOX / PCI?" Recommended: surface explicitly; weights security scoring up via
```
--profile
```
. Canon: ISO/IEC 27036 (supplier relationships security).

Walk depth-first. Lock 1-3 before opening 4-6. After all are answered, invoke

vendor_scorer.py

→

sla_compliance_tracker.py

→

vendor_risk_classifier.py

in sequence.

由

/cs:grill-bizops

或BizOps编排器逐一提出，每个问题均提供推荐答案及权威引用，不得批量提问。

"你的一级供应商重要性阈值是基于支出（年支出$X）还是运营依赖度（供应商故障即营收中断）？" 推荐答案：运营依赖度。权威引用：Gartner TPRM研究、Target/HVAC breach教训——仅基于支出的层级划分会遗漏像Target攻击媒介HVAC供应商这样的低支出关键供应商。
"对于一级供应商，你是否持有近12个月内出具的SOC 2 Type II报告，还是仅拥有问卷？" 推荐答案：坚持索要报告；问卷是未经验证的自我声明。权威引用：NIST SP 800-161（供应链风险管理）、Shared Assessments SIG框架。
"如果一级供应商突然失联，你的72小时应急方案是什么？" 推荐答案：每个供应商均有书面应急预案，每年测试一次。权威引用：NotPetya/M.E.Doc供应链攻击、log4j响应模式。
"上次实际调用SLA（提交索赔）是什么时候？" 推荐答案：如果从未调用过，审核SLA条款是否过弱或违约未被上报。权威引用：Atlassian SLA最佳实践、ITIL v4服务级别管理。
"你的供应商下线清单是否最新——包括数据删除、权限撤销、密钥轮换？" 推荐答案：每季度针对一个供应商演练一次。权威引用：SolarWinds + Okta 2022 breach教训。
"监管影响范围是什么——HIPAA/GDPR/SOX/PCI？" 推荐答案：明确列出；通过
```
--profile
```
参数提高安全评分权重。权威引用：ISO/IEC 27036（供应商关系安全）。

按深度优先顺序提问，完成1-3个问题后再开启4-6个问题。所有问题回答完毕后，依次调用

vendor_scorer.py

→

sla_compliance_tracker.py

→

vendor_risk_classifier.py

。