deepread6｜服务目录（Service Catalog）详解

ONEPSOFT | 软考学习知识库

---

deepread6｜服务目录（Service Catalog）详解

一、知识点定位

服务目录是 IT 服务 " 规划设计 " 模块的前端工具，主阵地在 12.1.2 服务目录管理。它不是孤立概念，而是串起整条规划链的关键：

• 12.1.2：服务目录的定义、作用、管理活动（核心）；
• 12.1.1 / 12.1.3 / 12.1.4：客户 " 结合服务目录 " 提服务级别需求 → 供方据此做服务级别设计 → 形成 SLA/OLA/UC（服务目录是 SLA 的前置输入与基准）；
• 体系归属：服务目录属于 ITSS 资源要素（R）中 " 服务设计实现的前期工具 "。

一句话定位：服务目录 = 供方给客户的 " 服务菜单/清单 "——列清楚 " 我能提供什么服务、什么内容、什么级别 "，既是管理客户期望的工具，也是制定 SLA 的基准数据源。

---

二、教材原文精摘

说明：以下为知识库《系统规划与管理师教程（第 2 版）》第 12 章 12.1.2 及关联小节的原文性摘录（环境无法导出逐字原文，已锚定章节号与关键原句）。

① 服务目录的定义（12.1.2）

" 服务目录是整理、分析服务产品和管理客户期望的重要工具，是服务供方为客户所提供的服务的集中信息来源，定义了服务供方所提供服务的全部种类和目标，以确保客户可以准确地看到服务供方可提供的服务范围、内容及相关细节。"

② 服务目录的作用（12.1.2）

" 服务目录可为服务供需双方提供一个准确、一致的中心数据源，同时记录所有服务的状态及信息，能够在识别客户服务需求、制定服务级别协议、运营级别协议及支持合同的过程中发挥支撑作用。"

③ 服务目录管理活动（六步骤，12.1.2）

"(1)成立管理小组。成员至少包括市场销售人员、系统规划与管理人员、信息系统服务工程师，确保视角全面。(2)列举服务清单。包含当前正在提供的及准备开展的服务。(3)确定服务类别与代码。按服务对象的技术维度或服务性质维度分类，赋予唯一代码。(4)编制服务详述。详细描述各项服务的服务内容、服务目标、服务级别、技术实现方法等。(5)评审并发布服务目录。通过内部评审后正式发布，作为供方服务交付和服务管理的基准。(6)完善服务目录。根据市场需求及业务发展趋势持续改进，保持与服务能力一致。"

④ 参考实例结构（表 12-1）

服务目录字段含：服务代码、服务名称、服务内容、服务描述、服务方式、服务时间/小时、服务级别（如 " 网络设备优化：隐患排查 + 性能优化…现场 + 远程集中监控，5×8，响应时间 10/30 分 "）。

⑤ 与 SLA 的关系（12.1.1 / 12.1.3 / 12.1.4）

" 在需求阶段，客户结合服务目录的定义和自身要求，提出服务级别需求。服务供方根据服务级别需求，同时兼顾成本控制和定价，进行服务级别设计，最终形成服务级别协议、运营级别协议和支持合同。"

---

三、逐段解读

1. 服务目录的本质 = " 服务菜单 + 中心数据源 "教材两句话点透：对外它是 " 管理客户期望的工具 "（让客户知道你能干啥、别乱许愿）；对内它是 " 集中信息来源/中心数据源 "（所有服务范围、内容、级别一处可查）。它是 SLA 的前置基准：必须含销售 + 规划 + 工程师三类人，保证 " 市场视角 + 规划视角 + 技术视角 " 齐全；

• 第 (3) 步分类按 " 技术维度或服务性质维度 "；
• 第 (6) 步 " 完善 " 体现持续改进——服务目录不是一次性的，要随业务演进更新。

3. 按技术维度或服务性质维度分类 ， ITIL/ITSS 通用分法是：

• 业务服务目录：面向客户/业务，描述 " 对业务有什么用 "（如 " 邮件服务 "" 协同办公 "）；
• 技术服务目录：面向技术组件，描述 " 底层技术如何实现 "（如 "Exchange 服务器运维 "）。

4. 服务目录 ↔ SLA：基准与落地的因果链：服务目录（能供什么）→ 客户结合目录提服务级别需求 → 供方设计级别 → 签 SLA/OLA/UC**。所以服务目录是 " 需求识别 " 和 " 级别设计 " 的共同输入——这也是为什么 12.1.3 需求识别、12.1.4 级别设计都强调 " 结合服务目录 "。

5. 易错挖坑（选择/案例）

• 服务目录是 " 工具/数据源 "，不是 " 协议 "——SLA 才是协议；
• 管理小组必须含三类人（销售 + 规划 + 工程师），少一类视角就不全；
• 服务目录要 " 持续改进 "（第 6 步），静态目录会脱离服务能力。

---

四、工程实践举例（土木工程类比 + 对照表）

服务目录类比 " 大楼运维公司给业主的《物业服务菜单》" 最直观：

• 你（设施运维公司）接手一栋写字楼，先给业主一本服务目录：列清 " 电梯维保、消防检测、空调清洗、弱电巡检 " 等服务，每项写清内容、方式（现场/远程）、时段（5×8 或 7×24）、响应级别（10/30 分）。业主看着目录挑服务、谈价格、定 SLA。
• 管理六步：成立小组（销售谈合同 + 你做规划 + 机电工程师定方案）→ 列清单（当前能做的 + 准备拓展的充电桩运维）→ 分类编码（按设备类型/按服务性质）→ 编详述（每项内容目标级别）→ 评审发布（内部过审后给业主）→ 完善（新增光伏运维）。
• 没有这本目录，业主就不知道你能干啥、SLA 也没法谈——这正是服务目录 " 管理客户期望 + 支撑 SLA" 的作用。

对照表

维度	教材定义（系规 12.1.2）	土木工程类比	易错点
本质	管理客户期望的工具 + 集中信息来源	《物业服务菜单》	不是协议（SLA 才是）
作用	准确一致的中心数据源，支撑需求识别/SLA/OLA/UC	谈 SLA 的基准	是 SLA 前置输入
管理六步	组→单→类→述→发→善	建菜单六步	小组须含销售 + 规划 + 工程师
分类	技术维度 / 服务性质维度	按设备/按服务性质	业界常扩为业务/技术目录
与 SLA 链	目录→提级别需求→设计→SLA	菜单→挑服务→谈合同	目录是基准，SLA 是成果
参考字段	代码/名称/内容/方式/时间/级别	服务项编号/内容/响应级别	服务内容编码参考规范《GBT 29264-2012《信息技术服务 分类与代码》》

服务目录是运维 " 规划设计 " 章（12.1.2）的入口工具，案例/论文里 " 先建服务目录、再谈 SLA" 是标准过程。