一、ISO/IEC 20000-1:2018 8.2.2 标准原文
条款要求：组织应对服务组合中的服务进行管理，维护有关服务的信息，并控制服务的新增、变更、组合调整和退出，确保服务信息准确、及时并支持相关管理和运行过程。
二、标准条款解读说明
2.1 服务组合管理要素表
| 要素 | 管理内容 | 目的 |
|---|---|---|
| 服务信息维护 | 服务名称、对象、状态、负责人、依赖、服务级别 | 保证所有相关过程基于同一事实基础运行 |
| 状态控制 | 在建、试运行、正式运行、变更中、退役中等状态 | 明确不同阶段的管理要求 |
| 组合调整 | 新增、合并、拆分、升级、停止服务 | 让服务结构与业务和资源匹配 |
| 信息同步 | 与目录、SLA、预算、容量、报告同步更新 | 避免信息不一致造成管理偏差 |
2.2 核心理解
服务组合管理的难点不在于建立一份清单，而在于保持信息持续准确。很多组织最初会整理一版服务目录，但半年后就与实际情况脱节，新服务未加入、退役服务未删除、负责人已变更却无人更新。这样一来，服务报告、容量规划和供应商管理都失去基础数据，体系很快变成“各过程各自记账”。
8.2.2要求组织把服务组合当作一项持续运营的管理活动。任何服务生命周期变化，都应先在服务组合中反映，再同步触发相关过程更新。只有这样，服务组合才能既支持管理层决策，也支撑一线执行。
2.3 服务组合管理真正难的是“持续正确”
建立一份组合台账并不难，难的是在服务持续变化中保持它始终可信。现实中，很多组织的问题并非不知道应该管理服务组合，而是缺少一套机制确保新服务会被登记、重大变更会被更新、退役服务会被清理、责任变化会被同步。这些动作一旦依赖人工记忆，服务组合很快就会失真。
一旦服务组合失真，很多后续判断都会连锁偏差。预算会投错地方，审核会抽错范围，服务报告会引用过时信息，甚至客户承诺也可能建立在错误的服务定义之上。因此，8.2.2 的深层价值，是保证组织关于“当前服务全貌”的认知始终最新、始终一致。
三、实施要点
3.1 建立服务信息标准
- 统一定义服务最小信息集，如服务名称、描述、客户群体、支持时间、负责人、状态、关键依赖。
- 明确信息维护责任人和更新触发条件。
3.2 建立状态转换规则
- 明确服务从提案、设计、试运行、正式运行到退役的状态及准入条件。
- 关键状态转换应经过评审和批准，不能靠口头宣布。
3.3 保证与周边过程同步
- 服务组合变化后，应同步更新服务目录、SLA、供应商接口、容量计划和预算安排。
- 对退役服务，还要同步处理知识、监控、备份和通知安排。
3.4 设定周期性核对机制
- 按月或按季度核对服务组合与实际交付情况，避免信息失真。
- 可结合管理评审、服务报告和项目上线清单做交叉核验。
3.5 提高服务组合信息的可信度
- 为每项服务设定明确的信息维护责任，不让服务组合变成“大家都能改、也等于没人负责”的共享表。
- 将项目立项、服务接收、重大变更、服务退役和客户签约等关键动作与服务组合更新强制联动。
- 对高风险服务建立更严格的信息核对要求，如依赖关系、支持窗口、连续性等级和关键供应商信息。
- 定期抽查部分服务，从服务组合一路追溯到目录、SLA、工单和报告，检验组合数据是否真实可用。
四、常用工具与实施方法
| 工具/方法 | 用途 | 输出 |
|---|---|---|
| 服务组合数据库 | 集中维护服务信息 | 服务信息库 |
| 状态流转规则 | 控制服务生命周期变化 | 状态管理规则 |
| 组合评审会 | 审议新增、变更和退役服务 | 评审结论 |
| 同步检查表 | 核对周边过程是否更新 | 更新跟踪表 |
| 服务审计 | 验证组合信息准确性 | 核查报告 |
五、典型案例
案例一：退役服务未清理引发管理混乱
某企业一项旧邮件归档服务已停用，但监控、供应商合同和月度报告仍继续纳入，造成资源浪费和信息混乱。实施8.2.2后，组织建立服务退役清单和同步检查机制，避免了“服务已经结束，管理动作还在继续”的低效现象。
案例二：服务组合成为管理层决策基础
某MSP将所有在管服务按收入、风险、满意度和资源占用做组合分析，发现部分定制化小客户服务严重拖累资源。管理层据此调整服务策略，把低价值服务标准化或退出，整体服务利润率和交付稳定性得到改善。
案例三：组合台账与项目清单打通
某企业早期的服务组合维护完全依赖服务经理手工更新，因此经常出现项目已经上线、组合仍未更新的情况。后来组织把项目上线审批、运行接收和服务组合维护串成一条流程，任何新服务只有在组合中建档并完成状态更新后，才视为正式进入运行。这一改动看似简单，却显著提升了组合数据的及时性和可信度。
对外部读者而言，这个条款很有启发意义，因为它揭示了许多服务组织并不是“没有服务治理意识”，而是缺少一套持续维护服务全景信息的机制。
从治理角度看，服务组合管理相当于组织的一张“服务底图”。只有底图是准的，预算、容量、供应商、风险、审核和持续改进这些动作才能建立在共同事实之上。底图不准，后面再多管理动作也容易偏航。
也正因为如此，8.2.2 虽然看起来不像事件管理那样直接面向现场，却对整个体系的长期稳定性影响很大。它决定了组织能否始终看清自己正在管理什么。
当组织能够持续看清这一点时，很多资源冲突、范围争议和优先级混乱都会明显减少，因为服务治理终于建立在清晰、稳定、可更新的共同认知之上。
服务组合管理因此不仅管信息，也在管组织判断力。
一旦组合信息持续准确，组织就能更从容地回答“哪些服务值得继续投、哪些服务应该退、哪些服务需要提升保障等级”这些真正重要的问题。这正是8.2.2在长期治理中的价值所在。
也正因为如此，服务组合管理看似偏静态，实则深深影响着组织后续的动态决策质量。
只要这一点建立起来，很多后续管理动作都会更有依据。
服务组合管理越稳定，组织就越容易在多服务并行、多团队协作和多变化叠加的场景下保持判断一致。这种一致性，本身就是服务治理能力的重要组成部分。
因此，8.2.2 的价值绝不只是把信息维护完整，而是让组织在不断变化的服务环境中始终拥有一张足够准确、足够统一、足够可用的治理底图。
底图越稳定，后续治理动作越不容易偏离方向。
如果没有这张稳定底图，组织会在新增、退役、评审、预算和供应商讨论中不断重复确认基础事实，管理成本也会随之升高。因此，8.2.2 对复杂服务组织尤其重要。
六、成文信息管理要求
- 保留服务组合数据库或台账、服务状态信息和服务评审记录。
- 保留服务新增、变更、退役的申请、批准、同步更新和验证证据。
- 对服务信息核查和不一致纠正，应保留整改闭环记录。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 一次性建表后不维护 | 组合台账越来越不准 | 设责任人、设触发条件、设核对机制 |
| 状态定义不清 | 试运行和正式运行界限模糊 | 建立明确状态流转规则 |
| 组合变化不通知相关过程 | 目录、SLA、预算仍用旧信息 | 建立同步更新和检查机制 |
| 只关注客户可见服务 | 忽略支撑和治理信息，导致管理不完整 | 在组合中保留足够治理属性 |