符合 ITIL 的服务目录的深度指南

随着数字化转型的不断加速，越来越多的组织发现 IT 已成为创造更大价值和获得竞争优势的重要推动力。终端用户在日常工作中依赖 IT 部门提供多种关键服务。例如： 工作站、互联网、电子邮件、软件支持等。

这些服务需要以结构化、易访问的界面呈现给终端用户，并配有清晰的文档说明。这样可以帮助用户明确：1、提供哪些服务；2、服务如何申请；3、服务何时交付

对于 IT 团队来说，清晰的服务结构也意味着可以通过标准化工作流程来提供服务，并确保收集一致且完整的信息。如果缺乏这样的界面，终端用户将无法清楚了解自己可以申请哪些服务。这可能导致服务台被大量无法处理的请求淹没、用户频繁咨询服务内容、IT 技术人员花费大量时间处理无效请求。进而会使 IT 人员无法专注于其他关键 IT 工作。

同时，由于服务内容没有清晰地传达给用户，服务请求的协调和交付也会变得更加困难。随着客户满意度下降和 IT 生产力降低，最终受影响的是整个企业。

那么，如何解决这些问题并提供良好的用户体验？

企业需要建立一种统一的界面或流程，能够满足所有利益相关方的需求，并且简化端到端服务交付流程。

作为 ITSM 的关键实践之一，服务目录管理能够有效解决上述问题。

本指南旨在介绍：什么是 IT 服务目录、高效服务目录的核心要素、服务目录的最佳实践，以及如何选择合适服务目录软件。

服务请求管理：高效处理用户服务请求

服务请求管理是 IT 部门最重要的职能之一，与事件、问题以及变更管理并列。服务请求管理是一项 ITSM 实践，通过该实践，IT 服务交付团队能够以用户友好的方式处理用户发起的请求，同时遵守既定的服务级别目标（SLA）。

什么是服务请求？

服务请求是终端用户向 IT 服务台提交的正式请求，用于启动某项服务操作。

常见的服务请求包括：

• 信息请求（如：查询云存储空间限制）
• 访问权限请求（如：申请访问某个文档或网络资源）
• 资源申请请求（如：申请新的手机、笔记本电脑或软件）

服务请求基于预定义的工作流程来履行，这些流程可能简单，也可能复杂。无论复杂程度如何。这些工作流都需要标准化，可重复执行，能够在约定的服务级别内完成服务交付。

服务请求管理流程

服务目录：高效服务请求管理的助推器

服务目录是服务请求生命周期中的关键组成部分，包括：

• 为终端用户提供 IT 服务的透明度。
• 帮助技术人员高效地交付服务。
• 帮助组织评估 IT 服务的需求与供给情况。

IT 服务目录（IT Service Catalog）是一个集中的信息源，用于提供组织 IT 部门所提供的所有 IT 服务及其准确说明。

服务目录本质上是一个集中式数据库，记录当前可用的 IT 服务信息。它是 IT 服务组合（Service Portfolio） 的一个子集。服务目录就像一个 IT 服务“商店”：终端用户（无论是内部员工还是外部用户）可以根据服务目录中的信息，通过 IT 服务台申请所需的服务或产品。

斯坦福大学公开的 IT 服务目录

在讨论服务目录时，另一个经常出现的概念是 服务组合（Service Portfolio）。

什么是服务组合（Service Portfolio）？

服务组合是记录组织所有 IT 服务和产品完整生命周期的文档。它通常包含三类信息：已退役的服务、当前正在提供的服务、未来计划推出的服务。服务组合通常是一个内部管理文档，用于帮助 IT 部门和管理层了解：哪些服务已经成功、哪些服务效果不佳、未来应该重点发展哪些服务。

示例

假设某公司员工的工作站目前使用 Windows 10。如果该公司过去曾使用 Windows XP 或 Windows 7，那么在服务组合中就会包含与这些旧系统相关的服务，同时也会记录：与 Windows 10 相关的服务，以及未来计划部署的新操作系统相关的服务。

作为服务组合的一个子集，而 IT 服务目录只包含当前提供的服务，有时也可能包含即将上线的服务。

服务目录的两种视图

IT 服务目录通常会针对不同受众提供不同视图。虽然服务目录主要是为终端用户提供服务信息，但 IT 技术人员也会根据服务目录来执行服务交付。因此，服务目录通常包含两种视角：

• 业务服务视图（Business Service View）：这是终端用户在访问服务目录时看到的内容。主要包含：服务说明、服务规格、服务费用、服务级别协议（SLA）。这类信息通常避免复杂技术术语，以便用户更容易理解。
• 技术服务视图（Technical Service View）：技术视图主要面向 IT 团队，用于支持服务交付。内容通常包括：审批流程、技术文档、工作流程、安全策略、服务交付流程。这些信息帮助 IT 团队更高效地执行服务。

在本指南中，“服务目录”这一术语通常同时包含业务视图和技术视图两个部分，以便更好地理解。

服务目录的组成

服务目录为终端用户澄清所提供的服务，通常包含以下信息：

• 服务类别
• 服务描述
• 服务可用性
• 服务级别协议（SLA）
• 服务负责人
• 服务费用（如需要）

需要注意的是，这并不是完整列表。组织可以根据实际需求增加更多信息。

以下是服务类别的一个示例：

在 ServiceDesk Plus 中对 IT 服务的默认分类。

简明、准确的信息是高效服务目录的基础。服务目录旨在帮助终端用户理解有哪些服务可用，并让用户对服务履行有一个合理预期。

为什么企业需要服务目录？

为了更好地理解服务目录的重要性，我们来看两个常见场景。

 场景一：IT 资产申请

一名市场分析师因为各种原因（新入职，转岗，晋升等）需要一台新的笔记本电脑以及必要的办公软件来完成日常工作。

于是他向系统管理员发送邮件，申请一台 MacBook Pro 和 Microsoft Office 2019。系统管理员回复称，根据该分析师的职位，只允许配置戴尔笔记本，而且公司仅采购了 Microsoft Office 2018 的授权。

接下来问题接踵而至：分配给该岗位的工作站型号是什么？设备交付时间是多少？经过多次邮件往返、沟通和等待，这名分析师终于成功提交了服务请求，并进入经理审批流程。

原本一个简单的 IT 请求，却因为信息不清晰而变得复杂。

场景二：员工入职流程

招聘经理提交一个服务请求，为即将入职的新员工准备相关资源。

员工入职请求通常会涉及多个部门，如人力资源、 行政后勤、IT部门 和财务或薪资部门。每个部门需要完成不同的任务，例如：

• 配置发放IT 设备
• 准备工位
• HR 入职培训

招聘经理需要与多个技术人员沟通并协调这些任务。

如果他不清楚 IT 部门提供的入职服务内容，就会面临和前面市场分析师类似的问题，只是复杂程度更高。

大量邮件往返不仅造成延误，还严重影响：新员工的工作效率和 IT 服务台的工作效率

在上述两个场景中，问题的根本原因都是：服务信息缺乏清晰和统一的沟通。同时，IT 服务台也因为缺乏标准化流程而难以高效处理请求。

IT 服务目录正是为了解决这些问题而存在的。它能够帮助组织实现：清晰的服务信息展示、标准化的服务申请流程、高效的服务交付管理。

从而实现更加顺畅的 IT 服务交付。

ITIL 服务目录管理的核心价值：从本质上来说，服务目录就像餐厅的菜单或电商平台的商品列表。如果没有菜单，用户在点单时就会非常困难。

服务目录不仅能为终端用户带来便利，也能为组织带来多方面的价值。

1. 简化与终端用户的沟通

   设计良好的服务目录可以作为终端用户获取服务信息的统一入口，用户可以在其中查看所有可用服务以及相关属性，例如：可用性、服务级别协议（SLA）、服务费用和服务负责人。

   回到前面提到的员工入职场景：如果 IT 部门拥有完善的服务目录，招聘经理就可以直接查看所有入职相关服务及其属性。从而免去大量反复沟通，提升流程透明度，大幅加快入职流程。

   服务请求表单示例

   如果没有服务目录，终端用户往往对可用服务缺乏了解。这会导致服务台需要处理大量基础咨询，从而降低整体工作效率。

2. 服务交付标准化

   服务目录通过提供结构化的服务列表和明确的交付参数，帮助组织实现服务交付的标准化。

   再次以员工入职为例：

   新员工需要根据其角色获得多项 IT 资源，如新工作站、邮箱账户以及业务软件的访问权限。有通过服务目录，组织可以将这些资源打包为一个服务套餐（Service Offering）。同时，IT 团队可以为该服务配置：标准审批流程、自动化工作流、任务分配规则。这样服务台就可以高效地处理更多的入职请求。对于 IT 团队来说，这意味着只需按照预配置的或自动或手动的流程操作，即可完成服务交付。

3. 优化服务交付成本

   通过跟踪各类服务的服务需求、使用频率、资源消耗。组织可以利用服务目录分析服务，例如哪些服务对业务价值最高或占用了过多资源却价值较低。

   通过这些分析，IT 管理者可以将资源集中在关键业务服务上、淘汰低价值或低使用率的服务。最终帮助组织更好地实现业务目标

4. 增强自助服务能力

   很多组织已经在自助服务门户中提供：事件管理和知识库文章。当服务目录与自助服务门户整合后，用户就可以通过一个入口完成所有 IT 请求，这样就形成了一个统一的 IT 服务入口。

   统一的自助服务门户。

   此外，服务目录还可以与事件管理进行关联。例如：

   用户在提交事件时可以选择被影响的相关业务服务，这样 IT 团队可以更快识别对业务影响最大的事件并优先处理。

   此外一些高频请求（例如密码重置）可以通过服务目录实现自助服务(用户申请后，系统自动执行，无需人工参与)。这样可以：减少一线支持（L1）工单数量、将简单问题前移到用户侧解决。这种模式被称为 Shift Left，可以显著提升 IT 团队的整体效率。

5. 助力持续服务改进（CSI）

   持续服务改进是IT 服务管理 (ITSM)生命周期中的重要组成部分。服务目录汇总了：所有服务列表、支撑服务的流程、相关资源信息。因此它可以作为重要的数据来源，用于生成服务报告、分析服务需求、优化服务供给以及提升用户满意度

服务目录并没有一个统一的标准模板，每个组织都会根据自身的业务需求、IT 能力以及管理目标来设计服务目录的结构。不过，通过一些实际案例，可以帮助我们理解服务目录在现实中的应用方式，以及它如何帮助组织优化服务交付流程。这些组织通过服务目录向用户清晰展示 IT 服务内容，并实现标准化的服务交付流程。

康奈尔大学的 IT 服务目录

弗吉尼亚大学医疗系统的服务目录。

构建高效 IT 服务目录的七个步骤

当组织决定实施服务目录时，需要确保目录需要即满足终端用户需求又提升服务台效率还能实现标准化服务交付。

下面是这七个步骤，可以帮助企业构建一个既能提升业务价值，又能改善用户体验的 IT 服务目录。为了更好地理解，我们将继续使用员工入职服务（Employee Onboarding）作为示例。

第一步：理解业务目标并识别利益相关者

实施服务目录的第一步是理解企业的业务目标以及用户需求。

可以从以下问题开始：

• 企业的业务目标是什么？

• 谁是利益相关者？

• 不同角色的服务需求是什么？

以新员工入职为例，尝试回答以上问题。

业务目标是什么？

高效为新员工办理入职并开通所需服务。

在这一阶段，组织通常需要审查现有服务交付方式并调研利益相关者需求。

在大型企业中，员工可享受的 IT 服务取决于其职位、部门、地点等。终端用户应只能查看和申请自己有资格使用的服务。因此，在实施服务目录之前，需要明确服务权限边界。

第二步：定义并分类服务

接下来，需要定义并分类服务。全面梳理 IT 部门提供的所有服务、服务的支持工作流程以及各服务对应的服务交付时限。

合理的分类让终端用户更方便地所找到需要的服务并快速发起。

示例：

在上图中，你可以看到员工入职和离职服务被归类于“用户管理”类别。

同时还可以记录并优化 IT 服务履行流程。IT 团队可以识别缺失的服务，并新增必要的服务。

第三步：制定服务 SLA 和工作流程

当 IT 部门定义并分类完服务供给列表后，就该为每项服务创建服务级别协议（SLA）并定义对应工作流程。设定切实可行的履行指标是确保服务顺畅交付的关键。

针对员工入职服务：

ServiceDesk Plus 中入职的服务级别协议

ServiceDesk Plus 中的多级审批工作流

步骤四：设计服务交付策略

接下来需要明确每项服务的履行团队。

具体包括：建立支持组、指定服务负责人（Service Owner）以及定义任务如何分配

为各服务供给映射相应工作流。若服务供给涉及审批，还需通知相应审批人。

员工入职需要完成的任务：

 ServiceDesk Plus 配置的服务履行团队。

此外，服务目录通常还需要一个集中管理团队负责维护目录内容，确保信息始终准确和最新。

第五步：设计服务目录

服务目录的设计需要重点关注用户体验。需要做到：结构清晰、分类合理、界面友好。

服务信息应当清晰展示，例如：服务费用、服务可用性、预计完成时间。

在收集用户信息时，应避免过长的表单。更好的做法是使用动态表单（Dynamic Forms）提供友好界面。

带有 SLA 和费用信息的员工入职请求表单

同时，用户在提交请求后应该能够实时查看请求状态，以提高流程透明度。

第六步：发布服务目录并与自助门户集成

当服务目录及其工作流经过充分测试后，服务目录需要发布到自助服务门户（Self-Service Portal）。该门户为终端用户提供统一入口，用于提交事件工单、服务请求及信息咨询请求。为了提升使用效率，应具备关键词搜索功能，并将常用服务置顶，减少终端用户检索服务的时间。

目录的易访问性至关重要。你的服务目录应能通过移动APP、邮件和 Web 表单等多种平台与渠道进行访问。

在实施过程中，建议：可先在某一部门或某一服务类别进行试点，再根据反馈扩展至其他部门。

第七步：持续服务改进（CSI）

在目录上线后，持续监控关键绩效指标 (KPI)也是至关重要的。这些指标有助于识别优势与不足，从而据此提升服务目录的效率与效能。

展示多项 KPI 的服务台仪表板。

常见指标如下，通过这些数据，IT 团队可以不断优化服务目录的结构和服务流程。

• 技术人员生产力（SLA 内完成的请求数量）
• 服务台整体效率
• 未处理请求数量（Backlog）

企业在构建服务目录时，不应将其视为“最终目标”，而应将其视为提升服务交付效率、实现业务目标的工具。以下是一些行业最佳实践，帮助你将服务目录真正转化为创造业务价值的核心能力。

1. 从高频服务开始构建

   在前文我们提到，定义服务是最重要的步骤之一。在定义服务内容时，建议优先选择：使用频率最高的服务以及对业务影响最大的服务。这有助于在终端用户中快速推广目录并帮助用户建立使用习惯。后续再逐步扩展到更多服务，实现全组织覆盖。

2. 做好用户教育，推动早期采用

   服务目录上线初期，用户往往不熟悉如何使用。因此需要通过以下方式推动：用户培训（Workshop）、使用指南和内部宣导。帮助用户了解如何提交服务请求并理解服务目录的价值。这一步对于服务目录的成功落地来说是至关重要的。

3. 持续与利益相关者沟通

   服务目录不是“一次性项目”，而是一个持续优化的过程。与利益相关者的沟通不仅在规划实施服务目录时重要，更是一项需要定期执行的持续性实践，用于评估用户满意度以及目录对业务的价值。

   常见方式包括：

   CSAT 满意度调查：

   在每次服务请求确认关闭后发送调查，可以判断此次服务体验是否令人满意。汇总调查结果，可用于评估用户体验。

   定期评审会议：

   定期召开包括 IT 团队成员、管理层和各部门终端用户的利益相关者评审会议，评估服务目录的表现并收集改进建议。

4. 构建严谨的 SLA 体系

   SLA（服务级别协议） 是服务交付的基石。一个好的 SLA 应具备：明确的交付时间目标、清晰的服务范围、合理的用户预期。因此，为每项服务制定专属 SLA 至关重要，既要规定现实的可行的履行目标，同时，还需要设计预警机制（在即将违反SLA时执行）和升级机制（在已经违反SLA时执行）。这样可以显著提升用户满意度。

5. 自动化重复性任务，提升服务台效率

   及时履行服务请求是每个服务台的重要目标。其中一种方式就是自动化。包括工单分类、分配支持人员以及状态更新通知等。自动化能够缩短请求处理时间，减少人为错误，提升整体效率。

   自动向终端用户发送进度更新通知，可进一步优化履行流程，终端用户无需频繁致电或发邮件催问，亦不会重复提交工单。

   让技术人员从这些琐碎工作中解放出来，进而把精力集中在真正的服务交付过程上。

6. 将相关服务打包为服务套餐

   根据热门需求，将不同服务进行打包，可简化服务目录。典型例子就是员工入职。一般而言，入职需要多个部门协作完成多项任务。诸如发放 IT 设备、开通 IT 服务访问权限和分配工位等服务，都可以在目录中打包为单一服务项。对于终端用户，只需提交一个请求，不需要再理解复杂的流程。

7. 提供用户友好的界面

   服务目录的核心之一是“好用”。通过直观、易访问的界面，让终端用户更容易提交请求。例如，对于简单需求，如果必须填写很长的表单，终端用户会非常沮丧。（如前所述，动态表单可以帮助避免这一问题。）

   作为服务目录入口的自助门户，应通过移动应用或网页等多种平台供终端用户访问。将最热门的服务置顶，以减少用户搜索时间。

   在服务目录的用户体验上多花些心思，将有助于服务台提供更佳的用户体验，从而提高服务目录的使用率。

8. 使用 SMART 原则衡量指标

   当服务目录上线后，服务台将产生大量数据。服务台经理往往倾向于通过众多指标分析这些数据，但不是所有数据都有价值。建议只关注符合 SMART 原则 的指标：S - 具体 (Specific)、M - 可衡量 (Measurable)、A - 可行动 (Actionable)、R - 可复用 (Repeatable)、T - 及时 (Timely)

   例如：SLA 达成率、请求处理时长、用户满意度、工单积压量等。关注符合上述标准的指标，并基于这些数据持续优化服务目录。

   服务目录是一个持续演进的系统：随着业务和客户需求的变化，服务目录也需要不断进行优化和调整。

选择 ITIL 服务目录工具的关键因素：在你决定实施服务目录之后，下一步就就是选择合适的软件工具。服务目录的核心目标是为用户提供一个简单易用的服务入口，以便访问和申请服务。

所选软件应具备强大的自动化能力，同时在实施和使用上不过于复杂。

Gartner 预测，90% 的组织会在未评估自身成熟度的情况下，盲目选择 ITSM 工具。 这会导致组织选择的工具成本高昂，实施困难，还无法带来预期的投资回报。

Gartner 基于 ITSM 能力及与 IT 运维管理 (ITOM) 解决方案的集成状况，将 ITSM 工具分为基础型、中级型和高级型。建议组织可以先评估自身成熟度，再选择与自身成熟度相匹配的工具。或足够灵活、可适用于不同成熟度组织的 ITSM 工具。

以下列出选择服务目录工具时应关注的几个关键能力：

• 与其他 ITSM 流程的紧密集成

  服务目录不是孤立存在的。当服务目录工具与事件管理、CMDB 及 IT 资产管理等其他 ITSM 流程集成时，才能发挥其全部的价值。

  提供给终端用户的所有服务（如网络、设备、系统）本质上都是由 CI（配置项）组成的。配置项 (CI) 都应存储在组织的CMDB 中。因此，服务目录需要关联 CI、支持服务与资产的映射以及支持服务级分析与报表。为满足报表需求，服务台团队还需要从事件、问题和变更管理中提取与服务目录关联的数据。

• 服务目录除了作为集中的功能性的集中的服务信息源之外，还需要具备能评估自身服务状况的能力。

  功能清单：

  功能	作用
  与 CMDB 集成，并将 CI 与服务关联	向终端用户提供服务并汇报 CI 性能
  创建多个服务类别，并将类别与事件工单关联	评估与特定服务关联的事件数量

• 合规与数据安全能力

  服务台日常会处理邮箱、电话等个人身份信息 (PII)。这些联系方式在员工入职、资产发放甚至密码重置等服务请求中都必不可少。

  随着全球范围内 GDPR（欧盟）、LGPD（巴西）、CCPA（美国）等数据保护法规的出台，组织就需要使用符合这些法规的 ITSM 工具。

  功能清单：

  功能	作用
  能够将字段标记为 PII	区分个人数据
  服务专属表单（模板）	仅采集相关信息
  支持对 PII 字段加密	提供安全保护
  技术人员基于角色的访问限制	践行按需共享

• 强大的报表与分析能力

  前文中，我们讨论了用来评估服务目录有效性的关键指标。要在海量数据中进行深度分析，服务目录工具需要具备丰富、开箱即用的报表功能，以及可视化仪表盘展示 KPI 实时监控数据。

• 功能清单：

  功能	作用
  多种类型报表，如矩阵报表、汇总报表和审计报表	深入洞察服务目录数据
  可自定义仪表板	实时监控 KPI
  定时报表，支持常规 CSI 活动	将报表邮件发送给指定利益相关者，推动 CSI
  技术人员基于角色的访问限制	践行按需共享

• 沟通与协作能力

  服务目录的本质是连接用户与 IT 团队。与利益相关者高效沟通是成功服务目录的前提之一。确保选择的服务目录工具具备下列能力。

  功能清单：

  功能	作用
  自动实时通知服务请求处理进度	防止重复提单，并让请求人随时知情
  技术人员预置回复	更快回应常见问题
  多种沟通渠道，如邮件、短信和推送通知	支持从不同平台发起请求

  以上功能有助于让所有利益相关者保持同步，简化沟通流程。

• 支持企业服务管理（ESM）

  服务目录不应该只服务 IT。虽然我们最初讨论的是“IT”服务目录，但数字化转型已渗透到所有企业业务职能中。成熟的 ITSM 思维方式正被越来越多地应用于其他业务部门，如行政后勤、人力资源以及财务，由此催生了企业级服务管理 (ESM)。

  因此，服务目录工具应未来可能需要的向 ESM 拓展能力，例如为不同部门的服务目录提供统一自助门户。

  功能清单：

  功能	作用
  集中请求门户	允许终端用户通过单一门户访问不同部门的服务目录
  独立服务台实例	让各部门拥有独立维护其服务目录的自主权
  针对每个服务台实例内置专属目录和模板	定义部门专属服务目录及热门服务模板
  跨部门的服务自动化	为不同目录实施独立自动化规则

  你未来很可能不是在选“IT 工具”，而是在选一个企业级服务平台。

• AI、自动化与智能能力

  “未来将有 70% 的员工将通过对话式平台与各种系统进行交互”

  在人工智能 (AI) 加持下，聊天机器人可以提升服务台效率，帮助技术人员分流工单，将精力集中到业务关键职能上。

  目前大多数 ITSM 解决方案提供的自动化能力仍是静态的，仅能针对特定场景定义规则。

  而聊天机器人则利用机器学习 (ML)，可以自行学习历史数据，自动处理工单。

  功能清单：

  功能	作用
  可进行开单、编辑工单等简单操作的对话式机器人	充当终端用户的第一接触点
  智能操作，如自动工单分类、坐席分配以及履行简单请求（如密码重置）	通过检索application数据库，为复杂问题提供答案

  关注具备 AI 和 ML 能力的服务目录工具，以便为 IT 服务目录做好未来规划。

服务目录是一个出色的工具，用于有序、无缝地交付服务，同时让组织的服务与业务目标保持一致。但是，许多组织的服务目录项目因为一些本可避免的错误而表现不佳，用户不买账甚至无法实现预期 ROI。

• 误区一：使用“IT语言”而非业务语言

最常见的错误，是用技术术语而非业务语言来定义服务目录。请尽量避免在描述服务属性时使用技术行话，从而让终端用户更容易理解和申请服务。错误示例：申请 VPN 权限，问题：VPN 是专业词汇，业务可能不懂。正式方式：申请远程办公访问权限。

原则：面向用户写，而不是面向技术人员写

• 误区二：服务分类过于细碎

在为 IT 部门提供的所有服务进行分类时，要注意避免过度细化。过细的分类会让终端用户找不到服务，导致使用体验差。

目录层级应保持简洁，控制在两到三层。

• 误区三：提交请求后不沟通

请求人期望可以了解整个请求履行的过程。不让请求人了解工单状态，会导致请求人频繁打电话或发邮件，甚至重复开单。正确做法是确保 IT 服务台在服务请求生命周期中与终端用户保持持续的沟通。

• 误区四：假设用户需求

很多服务目录项目失败的核心原因就是：未能围绕终端用户期望和业务目标构建目录。不应该是“我们觉得用户需要这个服务”，而是“用户实际需要什么？”，正确做法是：做用户调研、基于业务场景设计服务、以业务价值为导向。

本节将介绍一些常见的容易混淆的 IT 术语。

服务目录 vs. 自助服务门户

IT 服务目录和自助门户紧密相连，常被误认为是同一概念。正如本指南开头所定义，服务目录是是一个“数据集合”，包含所有 IT 服务信息。而自助服务门户则是连接终端用户和 IT 部门的唯一节点，它提供一个操作入口，用户通过它提交请求，查询工单状态、浏览知识库等。

例如，终端用户登录自助门户后，可以执行各式各样的操作，包括：

• 提交事件（中断、访问问题等故障）
• 请求服务（入职请求或新资产请求）—— 基于服务目录
• 浏览知识库，查找已知错误的应对方案
• 查看服务中断和维护的相关公告

简而言之，自助门户让终端用户可以访问 IT 服务目录。

注意：服务目录也可以独立于自助门户存在，正如在“最佳实践”一节中所述，当服务目录与其他 ITSM 流程集成时，才能发挥其最大价值。

服务目录 vs. 产品目录

要区分服务目录和产品目录，首先需要理解什么是“服务”，什么是“产品”。

用一个更简单的例子解释：打印机是产品，而给某人开通所在楼层的打印机访问权限，则是一项服务。

产品目录和服务目录的目标受众也不同。服务目录的通常是面向员工，而产品目录通常面向外部客户。

服务目录 vs. CMDB

IT 部门常常对 CMDB 与服务目录之间的关系感到困惑。下面通过拆解 CMDB 概念来澄清这一点。

CMDB 作为集中存储整个 IT 环境数据的仓库，CMDB 是一个有信息枢纽，用于存放有关你 IT 环境的每一个关键信息。它存储所有业务得以运转的组件——配置项（CI）——的信息，并对它们的关系和依赖进行建模，从而能够展示 IT 系统的不同细粒度的架构。

示例：公司有一个核心业务系统 CRM。CRM 的相关组件（如 CRM 应用系统，应用服务器，数据库，使用人，管理者等组件及其关系）会作为 CI 和 CI 关系存储在 CMDB 中。

“CRM 系统访问权限申请”就是服务目录中的一项服务。在为该员工开通 CRM 系统访问权限后，就需要在 CMDB 的关系中记录这一关系，以便后续进行 CRM 系统变更或停机维护时，能够通知到所有的受影响人员。

服务目录主要说明了“提供什么服务”。CMDB主要说明了“服务依赖什么资源”。两者相互绑定，相互依赖。

业务服务视图 vs. 技术服务视图

我们在前文中简要提到过服务目录的两种视图。

部分 ITSM 专家喜欢把这两种视图称为“业务服务目录”和“技术服务目录”。很多人误以为这是两个目录，其实不是，它们只是同一个服务目录的两种视角。

技术服务视图和业务服务视图的示例：

ServiceDesk Plus 中入职服务的技术服务视图。技术服务视图包含具体任务分配、审批流和 关联SLA 等底层工作流。

ServiceDesk Plus 中入职服务的业务服务视图。

业务服务视图是用于展示业务信息，方便用户理解的。技术服务视图是帮助技术人员具体执行业务服务的。两种视图正是通过这种方式彼此协作，帮助 IT 提升效率并实现业务目标。

无论处于哪个行业，如今企业在业务的各个环节都越来越依赖 IT 提供的数字化能力。

IT 部门早已不再只是员工“报障修电脑”的支持角色，而是推动企业实现业务成果的重要驱动力。IT 服务目录正是在 IT 与终端用户之间搭建起的一座关键桥梁，帮助组织实现高效、可感知且令人满意的服务交付。

如果企业希望最大化服务目录带来的价值，就必须实施一个用户友好（易用、易找、易理解）、可扩展（支持业务增长）且面向未来（具备持续改进能力）的服务目录体系。

业务服务视图：

以业务语言描述服务内容，面向终端用户的服务目录视角。

配置管理数据库 (CMDB)：

用于存储和管理组织内核心业务关联的硬件，软件及其关系的数据库。

企业服务管理 (ESM)：

将成熟的 ITSM 理念与实践扩展到企业的一种方法论。

通用数据保护条例 (GDPR)：

欧盟针对数据保护与隐私制定的法律法规。

巴西通用数据保护法 (LGPD)：

巴西制定的数据保护与隐私法律。

产品目录：

面向企业客户的 IT 产品信息集合。

自助服务门户：

终端用户访问的入口网站，用于提交工单（事件或请求）或查阅知识库。

服务目录：

集中展示组织 IT 部门所提供的所有在用服务的数据库。

服务级别协议 (SLA)：

服务提供方与用户之间约定服务水平及违约处理机制的协议。

服务组合：

记录组织所有 IT 服务及产品完整生命周期的集合。

服务请求：

终端用户向 IT 服务台提交的、用于触发某项服务交付的正式请求。

技术服务视图：

面向 IT 技术人员的服务目录视角，以技术语言描述流程与实现细节。