一、服务目录不等于服务清单：理解其本质角色

1.从“列表”到“体系”：服务目录的真正意义

在讲授 ITIL 4 DSV 课程时，我一再强调这样一个观点：服务目录从来都不只是一个简单的服务清单，而是组织服务能力、服务对象、资源配置、交付机制的综合表达。它既是用户认知服务的窗口，也是服务管理者协调资源、规范运营的核心依据。

在 ITIL 4 框架下，服务目录的定位不仅仅是“管理工具”，更是一种“价值展现”的平台。它承载的不只是服务名称，更是每项服务背后的价值承诺与运营能力。这一点，如果没有深刻理解，往往会导致目录建设流于形式。

2.服务目录要能“说清楚”也要“对得上”

很多组织做了目录，但却做不到用户点击能找到所需、提交能触发流程、遇事能追溯责任。目录不是文件，而是活系统，它必须具备可操作性、可执行性、可追责性。否则，再美观的目录也无法承载 ITIL 4 所要求的价值交付能力。

二、区分业务服务目录与技术服务目录的关键意义

1.两个视角，两种用途

在 ITIL 4 的服务设计方法论中，我们区分了“面向用户的业务服务目录”与“面向运营团队的技术服务目录”。业务服务目录回答的是“我能获得什么服务”，而技术服务目录回答的是“我要提供哪些技术资源来支持这些服务”。

很多组织在实施过程中混淆了这两者，导致目录信息复杂冗余，既不利于用户理解，也不利于后台管理。我一直建议大家在目录建设初期，就要明确面向对象、用途场景与管理方式的差异。

2.业务服务目录是信任承诺，技术服务目录是能力配置

一个面向业务的目录，需要体现出服务对象是谁、使用场景是什么、可支持的服务时间范围、问题响应机制等等；而技术服务目录则侧重于系统清单、组件依赖关系、支持策略等。这种结构上的分层，正是 ITIL 4 提出“面向价值建构服务”的具体体现。

三、五大核心信息构成高效服务目录的基础

1.服务内容清晰定义：让用户“看得懂”

服务内容要以用户语言清晰描述，避免使用内部术语和技术编码。比如，“用户权限调整服务”就比“AD域修改流程”更具可理解性。我们要站在用户认知的角度描述，而不是站在技术配置的角度编写。

2.服务对象界定明确：避免“谁都能提，谁都没用”

服务对象是确保服务触达精准的重要一环。只有界定清楚服务适用于哪些用户群体，才能避免目录中出现“有名无实”的服务项。尤其是在集团型企业中，部门权限、岗位级别等信息需要提前设定好服务访问逻辑。

3.支持时间与可用性：明确服务能否随时交付

服务并非总是7x24小时可用，有些服务受限于技术窗口、运营人力、外部依赖。将支持时间和可用性写清楚，是对用户预期管理的第一步，也能在服务中断或变更时，快速定位责任区间。

4.服务级别指标SLA嵌入目录中

在 ITIL 4 DSV 的SLA管理设计中，服务目录不仅是签订SLA的前提，更是跟踪SLA达成情况的基础。没有嵌入指标的目录，是无法形成有效运营机制的目录。这些指标可以包括响应时间、恢复时间、可用性百分比等，具体需结合服务特性设定。

5.服务流程跳转链接或联系方式：确保目录能“触发服务”

再漂亮的目录，如果无法直接触发服务请求流程，也就是“无源之水”。服务目录必须集成进企业服务门户、自助平台或移动端工具中，实现用户点击即可进入请求流程，才能真正发挥它在 ITIL 4 服务价值链中的联通作用。

四、服务目录在服务管理全流程中的核心作用

1.SLA签订的基础载体

服务目录是 SLA 构建的前提，目录中所定义的服务内容与指标，是 SLA 协议中必须参照的部分。如果目录中没有标准定义，SLA 只能靠模糊协商，最终可能导致交付过程中责任不清、标准不一。

2.服务运营的“控制台”

在实际服务运营中，服务目录提供了统一的服务资源调度基础。运维团队可以基于目录了解每项服务背后的支撑系统、人员资源、接口依赖，进而实现更精准的资源匹配与问题排查。

3.持续改进的指标源与问题镜像

通过服务目录中定义的服务项目和服务指标，我们可以收集用户满意度、请求频率、失败率等信息，从而发现哪些服务需要优化、哪些指标需要调整。这种结构化的数据视角，使得 ITIL 4 的持续改进机制具备可执行的依据。

五、案例剖析：大商所的服务目录结构与实践

在课程中我曾介绍过大商所（某金融基础设施机构）服务目录体系的设计经验。他们将所有对内对外服务，统一划分为六大服务域、十八类服务项，每项服务都设定了清晰的责任团队、标准指标与流程对接点。

特别值得一提的是，他们还根据服务对象不同设计了双视图目录结构：外部用户看到的是业务服务视图，内部支持团队则使用技术服务视图，彼此关联但各自清晰。这种设计大幅提升了目录的使用效率，也强化了 ITIL 4 在实际组织运营中的落地能力。

ITIL 4大师级课程官方授权讲师长河老师原创，末经许可，不得转载

20

20

20

20