一、ISO/IEC 20000-1:2018 8.2 标准原文
条款要求：组织应对服务组合进行管理，并对服务交付进行策划，对新服务或变更服务进行策划，以确保服务在整个生命周期内得到一致、受控和可评价的管理。服务组合应反映组织提供、开发、变更和退出的服务全貌。
二、标准条款解读说明
2.1 服务组合核心内容表
| 组成部分 | 核心内容 | 管理目标 |
|---|---|---|
| 现有服务 | 已上线并持续交付的服务 | 保障稳定运行和持续改进 |
| 新服务 | 正在设计、准备上线的服务 | 确保上线前充分策划和验证 |
| 变更服务 | 发生重大调整的既有服务 | 控制变更影响和交付连续性 |
| 退役服务 | 不再提供或已迁移的服务 | 有序退出、减少历史风险 |
2.2 核心理解
服务组合管理是ISO 20000区别于“只管运维现场”的重要体现。很多组织只关注已经上线的系统如何运维，却没有用统一视角管理服务的引入、升级、整合和退出，导致服务目录混乱、责任不清、资源被低价值服务长期占用。
服务组合的价值，在于帮助组织从全局判断“我们到底在提供哪些服务、这些服务处于什么状态、应该继续投入还是调整退出”。在此基础上，组织才能更合理地分配预算、设定优先级、规划人员和控制变更风险。对多服务、多客户、多地点的IT组织而言，服务组合更是治理复杂度的核心抓手。
2.3 服务组合与服务目录的差别必须讲清楚
很多组织在实施8.2时，会把服务组合和服务目录混为一体。实际上，服务目录更偏向客户可见的服务呈现，回答“用户可以申请什么、获得什么”；而服务组合更偏向管理层视角，回答“组织当前在管理哪些服务、这些服务处于什么状态、需要多少资源、面临什么风险”。两者相关但并不相同。若只维护目录而没有组合，管理层看不到全局；若只有组合而没有目录，客户体验又会失焦。
服务组合条款成熟后，组织会逐步建立“服务全景认知”。这个认知不仅帮助体系审核，更帮助经营判断。例如哪些服务适合标准化，哪些服务已不再值得继续投入，哪些新服务应先以试运行方式引入。换句话说，服务组合管理其实是服务治理中的产品组合思维在IT服务领域的体现。
三、实施要点
3.1 建立统一服务视图
- 梳理组织当前全部在管服务，明确服务名称、服务对象、状态、负责人、关键依赖和服务级别。
- 区分在运行、在建、在变更、待退役等不同状态，避免把所有服务放在同一层面管理。
3.2 让服务组合支撑资源决策
- 通过服务重要性、收入贡献、业务影响、风险等级等因素确定投入优先级。
- 对重复建设、低价值或长期无人维护的服务进行整合或退出评估。
3.3 与其他过程联动
- 服务组合要与服务级别、供应商、容量、连续性、预算和变更过程保持一致。
- 任何新增或重大调整服务，都应同步更新服务组合、服务目录和责任矩阵。
3.4 定期评审服务结构
- 通过管理评审、客户例会和业务规划，定期判断服务组合是否仍符合组织战略。
- 对长期投诉、成本高企或价值下降的服务启动调整评估。
3.5 让服务组合成为管理动作，而不是静态台账
- 对每项服务明确状态变化触发条件，例如立项通过、试运行启动、正式接管、重大变更、准备退役等，避免状态长期模糊。
- 在新服务评审、预算编制、供应商调整和能力规划时强制引用服务组合信息，确保组合真正进入管理决策。
- 对高价值或高风险服务建立更细颗粒度的治理信息，如关键客户、关键依赖、关键窗口和恢复要求。
- 定期用服务组合视角审视是否存在“组织还在维护、客户已经很少使用”的历史服务，及时释放无效占用资源。
四、常用工具与实施方法
| 工具/方法 | 用途 | 输出 |
|---|---|---|
| 服务组合台账 | 统一管理服务全景 | 服务组合清单 |
| 服务生命周期状态图 | 呈现服务当前所处阶段 | 状态管理图 |
| 服务价值评估 | 支持优先级和投入判断 | 价值/风险分析结果 |
| 服务评审机制 | 定期决定新增、调整和退出 | 评审纪要 |
| 服务目录联动 | 保持客户视角与治理视角一致 | 目录更新记录 |
五、典型案例
案例一：服务越来越多但无人知道全貌
某集团IT部门长期新增系统和支持项，却没有统一的服务组合视图，导致多个类似服务并存、责任重叠、预算浪费。实施8.2后，组织首次建立服务组合台账，对重复服务进行整合，对低价值服务提出退役计划，资源使用效率显著改善。
案例二：新服务上线前先纳入组合管理
某云服务商推出新客户门户前，先将其纳入服务组合评审，明确目标客户、支持方式、SLA草案和依赖资源。由于服务在上线前就被纳入统一治理，新服务交付过程更平稳，后续责任划分也更清晰。
案例三：低价值服务退出带来的治理优化
某集团长期保留多项早年建设的小型内部服务，虽然使用量极低，但监控、备份、权限和供应商合同依然持续消耗资源。重做8.2时，组织以服务组合为依据，对这些服务逐项评估业务价值、风险和维护成本，最终将其中一部分整合，一部分正式退役。服务数量减少后，团队反而更能把资源集中到高价值服务上，这正体现了服务组合管理的战略价值。
对发表型文章而言，8.2 的亮点在于它把IT服务管理从“处理工单”提升到“治理服务资产”的层面，这也是ISO 20000区别于单纯运维规范的重要地方。
在很多组织中，一旦服务组合开始稳定运转，管理层会明显感觉服务决策变得更“有抓手”。因为预算、风险、供应商、能力和目标都能围绕具体服务展开，不再停留在抽象讨论。这种服务化视角，正是8.2最值得强调的管理价值。
服务组合管理做深以后，组织对“新增什么、保留什么、加强什么、退出什么”的判断会越来越清楚。服务不再只是被动积累的历史结果，而会成为可规划、可优化、可调整的治理对象。
从这个角度看，8.2 真正建立的是一种面向未来的服务治理视角。它帮助组织把注意力从眼前的个别工单和个别系统，拉回到整个服务版图的演化上来。
服务组合越清楚，组织越不容易在资源和优先级上陷入长期被动。
从这个意义上说，服务组合并不是后台台账，而是服务治理的方向盘。方向盘越稳，组织面对新增服务、旧服务退出和资源重配时就越不容易失去判断。
因此，8.2 最终帮助组织建立的，不只是服务清单，而是面向未来持续调整服务结构的能力。
这也是服务治理逐步成熟的体现。
当组织开始用服务组合讨论优先级、资源和退出时，服务管理就不再只是维持现状，而开始具备主动塑造服务结构的能力。这也是8.2真正想带来的变化。
六、成文信息管理要求
- 保留服务组合清单、服务状态信息、服务负责人信息和评审记录。
- 保留新增、调整、退役服务的立项、审批、影响分析和目录更新记录。
- 服务组合与服务目录、SLA、预算和容量计划之间应保持可追溯关系。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 把服务组合当静态清单 | 只有名称，没有状态和治理信息 | 补充生命周期、责任、依赖和价值信息 |
| 只管理上线服务 | 新服务和退役服务无人统筹 | 覆盖设计、变更和退出全生命周期 |
| 服务组合与目录脱节 | 内部管理和客户看到的服务不一致 | 建立同步更新机制 |
| 长期不评审 | 旧服务长期保留，占用资源 | 定期开展服务价值和风险评审 |