ITIL 4官方核心著作
- Manage
Copy- Actions
Export
Print preview
View Source- Viewers
Children
Comments- Annotations
Attachments (3)
History
Information
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | **申明：** | ||
| 2 | |||
| 3 | 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众 | ||
| 4 | 多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信 | ||
| 5 | 公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。 | ||
| 6 | |||
| 7 | |||
| 8 | 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。 | ||
| 9 | |||
| 10 | |||
| 11 | 本文档翻译工作参与人员： | ||
| 12 | |||
| 13 | 翻译：庄严 | ||
| 14 | |||
| 15 | 审校：黄海燕 | ||
| 16 | |||
| 17 | 总审：长河 | ||
| 18 | |||
| 19 | 审核：李锐 | ||
| 20 | |||
| 21 | 统筹：常宏 | ||
| 22 | |||
| 23 | |||
| 24 | |||
| 25 | ---- | ||
| 26 | {{box cssClass="floatinginfobox" title="**Contents**"}} | ||
| 27 | {{toc/}} | ||
| 28 | {{/box}} | ||
| 29 | = **1 关于本文件** = | ||
| 30 | |||
| 31 | 本文档提供服务目录管理实践实用指南。它分为五个主要部分，涵盖： | ||
| 32 | |||
| 33 | 1. 本实践的一般信息 | ||
| 34 | 1. 本实践相关的流程和活动及其在服务价值链中的作用 | ||
| 35 | 1. 参与本实践的组织和人员 | ||
| 36 | 1. 支持本实践的信息和技术 | ||
| 37 | 1. 对本实践的合作伙伴和供应商的考虑 | ||
| 38 | |||
| 39 | |||
| 40 | == **1.1 ITIL4 资格认证计划** == | ||
| 41 | |||
| 42 | |||
| 43 | 本文档中的部分内容可以作为以下教学大纲的一部分以供检查： | ||
| 44 | |||
| 45 | * ITIL专家：驱动利益相关者价值 | ||
| 46 | |||
| 47 | 详情请参考各部分教学大纲。 | ||
| 48 | |||
| 49 | |||
| 50 | |||
| 51 | ---- | ||
| 52 | |||
| 53 | = **2 一般信息** = | ||
| 54 | |||
| 55 | |||
| 56 | == **2.1 目的和描述** == | ||
| 57 | |||
| 58 | * **关键信息** | ||
| 59 | |||
| 60 | 服务目录管理实践的目的是提供有关所有服务和服务供应的一致信息的唯一来源，并确保相关受众可以使用该信息。 | ||
| 61 | |||
| 62 | 服务目录管理实践确保所有利益相关者都引用有关服务和服务供应的一个唯一的信息源。它还有助于为所有利益相关者提供有关服务和服务供应的相关视图，匹配所有利益相关者的需求和访问级别。 | ||
| 63 | |||
| 64 | 有许多内部和外部利益相关者可以在他们的工作中访问和使用服务和服务供应的各种视图。其中包括用户、现有的/潜在的客户、产品团队、支持团队、供应商经理和关系经理等。他们的服务目录视图在范围、结构和包含来自其他来源的信息上有所不同。例如，内部团队可能需要有关服务的技术细节、支持团队的架构、用户列表，以及不需要或不允许包含在面向用户的服务目录中的其他信息。 | ||
| 65 | |||
| 66 | 服务目录管理实践确保为所有团体提供唯一的服务来源和服务信息，并支持与其他来源的有效信息交换，以及与其他实践相结合，包括服务配置管理、服务财务管理、关系管理、供应商管理、服务请求管理等。 | ||
| 67 | |||
| 68 | 服务目录管理实践涵盖了组织管理的所有服务，包括内部、外部、提供方和使用方。例如，供应商经理的视角可能包括组织所使用的第三方服务以及依赖于它们的组织的服务。 | ||
| 69 | |||
| 70 | |||
| 71 | == **2.2 术语和概念** == | ||
| 72 | |||
| 73 | * **定义：资源** | ||
| 74 | |||
| 75 | 为执行某项活动或实现某一目标所需的人员、材料、财务或其他实体。组织使用的资源可能为组织所有，也可能根据组织与资源所有者的协议使用。 | ||
| 76 | |||
| 77 | 组织的资源可以被配置到产品中为消费者或消费群体提供价值。 | ||
| 78 | |||
| 79 | |||
| 80 | * **定义：产品** | ||
| 81 | |||
| 82 | 组织对资源的配置，旨在为消费者提供价值。 | ||
| 83 | |||
| 84 | 因为一个产品可以用于满足几个不同群体的需求，它并不总是对消费者完全可见，也不是一个消费者群体独有的。例如，软件服务可以为个人用户使用提供简化版本，或者提供更完整的企业版本。产品可以不受消费者的影响而存在。 | ||
| 85 | |||
| 86 | |||
| 87 | * **定义：服务** | ||
| 88 | |||
| 89 | 通过帮助客户达成其所希望的结果，实现价值共创的手段，而无需客户管理特定的成本和风险。 | ||
| 90 | |||
| 91 | 组织提供的服务基于其一个或多个产品。服务在与使用者的交互过程中发生，该交互过程成为一种服务关系。为了建立这种关系，组织必须向潜在的客户提供服务供应，并应签署服务协议。 | ||
| 92 | |||
| 93 | |||
| 94 | * **定义：服务供应** | ||
| 95 | |||
| 96 | 对一个或多个服务的正式描述，旨在满足目标消费者群体的需求。服务供应可能包括货品、对资源的访问以及服务动作。 | ||
| 97 | |||
| 98 | 产品的可见部分表现为一项或多项服务供应。通常在服务目录为潜在客户展示所提供的服务供应。对于现有客户，服务目录提供了有关正在使用的服务以及与之相关的协议的视角。这些视图基于客户组织中的利益相关人的角色。 | ||
| 99 | |||
| 100 | |||
| 101 | * **定义：服务目录** | ||
| 102 | |||
| 103 | 对于特定目标受众的有关服务提供者提供的所有服务和服务供应的结构化信息。 | ||
| 104 | |||
| 105 | “ 服务目录”一词通常是指对服务和服务供应的定制视图。在服务目录实践场景中，它还可以用于收集用作所有服务目录视图的唯一源的服务数据。服务目录可以被集中式数据库管理，或被组织中不同团队管理的多个数据库管理。该实践确保有效的数据集成和服务相关信息的质量。这包括确保服务信息是正确的，更新及时，并且可供相关的利益相关者使用。在多个价值流背景下服务目录管理需要与其他实践紧密集成。 | ||
| 106 | |||
| 107 | |||
| 108 | * **定义：请求目录** | ||
| 109 | |||
| 110 | 一种服务目录的视图，为用户提供现有和新增的服务的服务请求的详细信息。 | ||
| 111 | |||
| 112 | 在与客户交互时请求目录是满足用户并可以被服务提供者的团队使用。作为服务目录实践的一部分，请求目录保持正确且最新的状态。 | ||
| 113 | |||
| 114 | |||
| 115 | == **2.3 范围** == | ||
| 116 | |||
| 117 | 服务目录管理实践的范围包括： | ||
| 118 | |||
| 119 | * 为服务目录定义适当的服务描述结构，使其结构良好并满足利益相关方的需求，包括约定的强制属性和关系。 | ||
| 120 | * 捕获服务信息并保持最新，确保服务目录中的数据的质量。 | ||
| 121 | * 为相关利益相关者团体定义不同量身定制的服务目录视图，一旦约定后就实施服务目录结构的视图和变更。 | ||
| 122 | * 为不同的利益相关者发布服务目录，并管理不同的视图。 | ||
| 123 | |||
| 124 | 尽管有几个活动和责任领域仍然与服务目录管理密切相关，但未包含在服务目录管理实践中。表2.1列出了这些活动和责任领域，并给出可以找到这些活动的相关实践。重要的是要记住，ITIL实践只是价值流的场景中使用的工具的集合；根据情况必要时应合并。 | ||
| 125 | |||
| 126 | |||
| 127 | 表2.1与其他实践指南中描述的服务目录管理实践相关的活动 | ||
| 128 | |||
| 129 | (% style="width:532px" %) | ||
| 130 | |(% style="width:398px" %)**活动**|(% style="width:132px" %)**实践指南** | ||
| 131 | |(% style="width:398px" %)定义和管理服务组合|(% style="width:132px" %)投资组合管理 | ||
| 132 | |(% style="width:398px" %)定义服务和服务供应，包括服务功用和功效的详细信息|(% style="width:132px" %)((( | ||
| 133 | 业务分析 | ||
| 134 | |||
| 135 | 服务设计 | ||
| 136 | ))) | ||
| 137 | |(% style="width:398px" %)与客户和供应商建立服务级别协议|(% style="width:132px" %)((( | ||
| 138 | 服务级别管理 | ||
| 139 | |||
| 140 | 供应商管理 | ||
| 141 | ))) | ||
| 142 | |(% style="width:398px" %)管理服务请求|(% style="width:132px" %)服务请求管理 | ||
| 143 | |(% style="width:398px" %)管理有关服务与其他配置项之间关系的信息|(% style="width:132px" %)服务配置管理 | ||
| 144 | |(% style="width:398px" %)管理有关IT服务资产的信息|(% style="width:132px" %)((( | ||
| 145 | IT资产管理 | ||
| 146 | |||
| 147 | 服务财务管理 | ||
| 148 | ))) | ||
| 149 | |||
| 150 | |||
| 151 | == **2.4 实践成功因素** == | ||
| 152 | |||
| 153 | * **定义：实践成功因素** | ||
| 154 | |||
| 155 | 实践为实现其目的所需的一个复杂的功能部件。 | ||
| 156 | |||
| 157 | 一个实践的成功因素（PSF）不仅仅是一项任务或活动，因为它包括服务管理的所有四维度的组件。 | ||
| 158 | |||
| 159 | 在一个实践中，实践成功因素的活动和资源的性质可能不同，但是它们共同确保实践是有效的。 | ||
| 160 | |||
| 161 | 服务目录管理实践包含以下实践成功因素PSF： | ||
| 162 | |||
| 163 | * 确保组织的服务目录的结构和范围满足组织需求 | ||
| 164 | * 确保服务目录中的信息符合利益相关者当前和预期的需求 | ||
| 165 | |||
| 166 | |||
| 167 | === **2.4.1 确保组织的服务目录的结构和范围满足组织需求** === | ||
| 168 | |||
| 169 | 服务目录的结构和范围应反映业务、产品和服务的组织架构。为确保发生这种情况，服务目录实践应该基于战略管理、架构管理和投资组合管理实践的输入。这个输入有助于回答以下问题： | ||
| 170 | |||
| 171 | * 谁是服务目录视图的目标受众？ | ||
| 172 | * 目标受众对服务目录视图有什么需求？ | ||
| 173 | * 服务目录应包含哪些服务和服务供应？ | ||
| 174 | * 服务描述的合理粒度是多少？ | ||
| 175 | * 用利益相关者可以理解的方式展示服务，需要什么级别的细节？ | ||
| 176 | * 哪一组服务属性足以描述所有服务并适用于所有服务？ | ||
| 177 | * 如何体现产品和服务的关系？ | ||
| 178 | * 需要哪些与服务相关的信息？这些信息从哪里来？ | ||
| 179 | * 如何发布服务目录？ | ||
| 180 | * 如何更新服务目录信息？ | ||
| 181 | * 什么是访问需求和控制？ | ||
| 182 | |||
| 183 | 服务目录规划的其他信息来源包括以下实践：服务级别管理、服务请求管理、关系管理、服务配置管理、服务财务管理和供应商管理。这些实践维护的信息通常包含在服务目录视图中。 | ||
| 184 | |||
| 185 | 在分析了组织的需求和期望之后，执行服务目录设计。它涵盖了所有服务管理四维模型： | ||
| 186 | |||
| 187 | * **组织和人员** 角色和职责，服务所有者，以及参与开发和运营团队 | ||
| 188 | * **信息和技术** 使用的数据和技术，任何数据或技术先决条件 | ||
| 189 | * **合作伙伴和供应商** 第三方的参与、现有协议和合同、合作伙伴的支持水平 | ||
| 190 | * **价值流和流程** 规程和工作流 | ||
| 191 | |||
| 192 | 服务目录设计受持续改进的约束。改进的主要来源是： | ||
| 193 | |||
| 194 | * 定期回顾 | ||
| 195 | * 用户反馈的目录 | ||
| 196 | * 需求中的变更 | ||
| 197 | * 组织架构中的变更 | ||
| 198 | * 技术机会 | ||
| 199 | |||
| 200 | |||
| 201 | === **2.4.2 确保服务目录中的信息符合利益相关者当前和预期的需求** === | ||
| 202 | |||
| 203 | 服务目录的维护、更新和提供应尽可能地自动化。一般不会根据需求手动创建服务目录视图。通常，服务目录是与相关的利益相关者达成共识，并自动进行更新和提供。在需要定制的地方，通常是通过为用户提供视图设置功能来实现的。 | ||
| 204 | |||
| 205 | 本实践确保考虑了不同的利益相关者团体，并根据相关利益相关者团体的期望，在服务目录中为他们定义了定制视图。最受欢迎和最有用的视图可能包括： | ||
| 206 | |||
| 207 | * **用户视图** 提供有关服务和服务供应的信息，从用户角度包含相应的详细信息。例如，服务描述、先决条件、请求服务的规程、服务级别协议、技术和渠道使用情况，以及有关服务支持信息。所有这些信息都应根据用户状态和服务权利进行筛选。 | ||
| 208 | * **客户视图** 从业务角度提供信息，包含约定的服务水平、财务数据、服务绩效和度量、合同要求等信息。此视图可能包括描述客户可用的服务和服务级别的服务提供。需要对客户视图进行筛选，以仅反映与客户和/或客户团体相关的服务和服务提供。新客户和现有客户的视图在服务的详细信息和范围中有所不同。 | ||
| 209 | * **服务提供者视图** 提供服务交付中使用的技术、安全、风险和流程相关信息。这包括使用服务的技术需求、技术解决方案详细信息，安全需求、潜在风险和可能的缓解措施，有关服务的事件和问题信息，等等。根据服务提供者的团队的需要，通常为他们定义多个视图。例如，供应商经理和业务分析人员可能需要不同的服务详细信息。这种裁剪可以通过创建不同的预设视图或为内部目录用户提供灵活的设置来实现。 | ||
| 210 | |||
| 211 | 当服务目录的多个定制视图是可能的和有用的，应避免在不同技术系统内创建单独的或隔离的服务目录，这会增加组织内的隔离和复杂程度。相反，应使用服务数据的唯一存储库来生成约定的定制视图，这对组织有利。服务目录通常作为一个数据库来构建和管理，其中包含服务数据的中央存储库和服务相关数据的其他外部数据源；外部数据源由其他工具提供，支持基于角色的视图和服务仪表板。例如，对于任何给定的服务，核心服务数据存储在服务目录中，而且来自财务、监控和事件、消费者和用户服务系统的数据，在服务目录界面下无缝使用。 | ||
| 212 | |||
| 213 | 为确保服务目录被使用并满足利益相关者的需求，重点要测量和评估服务目录的使用情况。最简单的选择是调查利益相关者的满意度；在许多情况下，使用技术可以直接监视用户体验（使用模式，收藏夹视图设置，搜索请求）。有用的方法还要确保报告、分析和纠正服务目录信息中的错误和不一致。对于面向用户和客户的目录视图，应将目录错误作为事件被处理。 | ||
| 214 | |||
| 215 | 对于服务目录信息质量和利益相关者满意度的理解应作为服务目录和此实践持续改进的输入。 | ||
| 216 | |||
| 217 | 服务目录管理实践包括推广服务目录并确保目录被目标受众采用。采用基于目录用户的积极体验。几种方法和技术对于理解和提升体验可能有用，包括： | ||
| 218 | |||
| 219 | * 约定服务目录功用和功效，并确保满足协议 | ||
| 220 | * 可用性设计 | ||
| 221 | * 确保新用户能够有效使用目录 | ||
| 222 | * 平等对待内部和外部用户 | ||
| 223 | * 监控并改进用户满意度 | ||
| 224 | * 监控并处理反馈 | ||
| 225 | |||
| 226 | 用户和客户的服务目录视图是组织服务总体满意度的一个重要因素。它是服务提供者和服务使用者之间的关键触面之一。它也是服务提供者中最常用的工具之一，因此应该易于使用。 | ||
| 227 | |||
| 228 | 尽管某些服务和服务管理工具需要其特殊技能和用户体验，但服务目录应该为内部和外部用户提供直观、熟悉且流畅的界面。这对于向外部市场上的独立的消费者提供服务的服务提供者尤其重要。在这种情况下，通常用户和消费者角色会合并在一起，并且独立的消费者使用服务提供者发布的服务目录，到契动并同意并使用服务。目录界面中的低效率很容易阻止这些消费者与服务提供商接触。 | ||
| 229 | |||
| 230 | |||
| 231 | == **2.5 关键指标** == | ||
| 232 | |||
| 233 | ITIL实践的有效性和绩效应在每个实践贡献的价值流的背景下进行评估。与任何工具的性能或绩效一样，只能在应用程序的背景内评估实践的性能或绩效。然而，工具在设计和质量上可能会有很大差异，这些差异定义了工具的潜力或能力，根据用途使用工具，工具的能力才能发挥出效果。在度量和报告实践指南中可以找到关于度量、关键绩效指标和其他技术的进一步指导。 | ||
| 234 | |||
| 235 | 服务目录管理实践的关键指标已映射到他的实践成功因素PSF。它们可以用作价值流的背景中的关键绩效指标KPI，以评估服务目录管理实践对这些价值流的效果和效率的贡献。表2.2中给出了一些关键指标的示例。 | ||
| 236 | |||
| 237 | |||
| 238 | 表2.2 实践成功因素的关键指标示例 | ||
| 239 | |||
| 240 | |**实践成功因素**|**关键指标** | ||
| 241 | |确保组织的服务目录的结构和范围满足组织需求|((( | ||
| 242 | * 服务目录的完整性（实际管理但未包含在目录中的服务数量） | ||
| 243 | * 完成组织约定的对服务目录设计的要求 | ||
| 244 | * 目录所需信息源的遗漏，无效或手动集成的数量和影响 | ||
| 245 | * 记录的目录设计改进的实施进度 | ||
| 246 | ))) | ||
| 247 | |确保服务目录中的信息符合利益相关者当前和预期的需求|((( | ||
| 248 | * 利益相关者团体对于目录信息的满意度 | ||
| 249 | * 目录错误的数量和影响（信息不正确，遗漏或过时） | ||
| 250 | * 利益相关者团体对于目录界面的满意度 | ||
| 251 | * 记录的目录内容和界面改进的实施进度 | ||
| 252 | ))) | ||
| 253 | |||
| 254 | |||
| 255 | 将度量标准正确地聚合为复合的指标，将使数据更容易用于价值流的持续管理，以及服务目录管理实践的定期评估和持续改进。这没有唯一的最佳解决方案。 | ||
| 256 | |||
| 257 | 度量标准将基于组织的整体服务战略和优先排序，以及实践所贡献的价值流目标。 | ||
| 258 | |||
| 259 | |||
| 260 | |||
| 261 | ---- | ||
| 262 | |||
| 263 | = **3 价值流和流程** = | ||
| 264 | |||
| 265 | |||
| 266 | == **3.1 价值流的贡献** == | ||
| 267 | |||
| 268 | 像任何其他ITIL 管理实践一样，服务目录管理实践也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。服务目录管理实践与其他实践相结合，可以为消费者提供高质量服务。实践贡献的主要价值链活动是： | ||
| 269 | |||
| 270 | * 契动 | ||
| 271 | * 设计和转换 | ||
| 272 | * 交付和支持 | ||
| 273 | |||
| 274 | 图3.1中显示了服务目录管理实践对服务价值链的贡献。 | ||
| 275 | |||
| 276 | (% style="text-align:center" %) | ||
| 277 | [[image:1641126173900-260.png]] | ||
| 278 | |||
| 279 | 图3.1 服务目录管理对价值链的贡献的热图活动 | ||
| 280 | |||
| 281 | |||
| 282 | == **3.2 流程** == | ||
| 283 | |||
| 284 | 每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。 | ||
| 285 | |||
| 286 | * **定义：流程** | ||
| 287 | |||
| 288 | 一组相互关联或交互的活动，可将输入转换为输出。流程接受一个或多个定义的输入，并将其转换为定义的输出。流程定义动作的顺序及其依赖性。 | ||
| 289 | |||
| 290 | 服务目录管理活动形成两个主要的流程： | ||
| 291 | |||
| 292 | * 定义和维护服务目录数据和标准服务目录视图 | ||
| 293 | * 向约定的目标受众提供并维护最新的服务目录视图。 | ||
| 294 | |||
| 295 | |||
| 296 | === **3.2.1 定义和维护服务目录数据和标准服务目录视图** === | ||
| 297 | |||
| 298 | 该流程专注于根据利益相关者需求，定义、约定和维护服务目录结构、数据和标准视图。它包括表3.1中列出的活动，并将输入转换为输出。 | ||
| 299 | |||
| 300 | 表3.1定义和维护服务目录数据和标准服务目录视图的输入、活动和输出流程 | ||
| 301 | |||
| 302 | |**关键输入**|**活动**|**关键输出** | ||
| 303 | |((( | ||
| 304 | * 组织的架构 | ||
| 305 | * 组织的策略 | ||
| 306 | * 组织的服务组合 | ||
| 307 | * 客户和用户的需求 | ||
| 308 | * 与客户和供应商的合同和协议 | ||
| 309 | * 相关的外部数据源 | ||
| 310 | * 服务目录反馈 | ||
| 311 | * 持续改进登记册 | ||
| 312 | )))|((( | ||
| 313 | * 分析利益相关者对服务目录的需求 | ||
| 314 | * 定义服务目录数据结构 | ||
| 315 | * 为关键利益相关者团体定义并约定的服务目录标准视图 | ||
| 316 | * 收集和维护服务目录数据 | ||
| 317 | )))|((( | ||
| 318 | * 关键服务目录利益相关者团体清单 | ||
| 319 | * 约定的利益相关者的需求 | ||
| 320 | * 服务目录数据结构 | ||
| 321 | * 标准服务目录视图和用户手册 | ||
| 322 | * 新服务数据的模板 | ||
| 323 | * 管理目录工具的需求 | ||
| 324 | * 数据集成需求 | ||
| 325 | * 变更请求 | ||
| 326 | * 发布目录数据 | ||
| 327 | ))) | ||
| 328 | |||
| 329 | |||
| 330 | 图3.2显示流程的工作流程图。 | ||
| 331 | |||
| 332 | |||
| 333 | (% style="text-align:center" %) | ||
| 334 | [[image:1641126209925-530.png]] | ||
| 335 | |||
| 336 | 图3.2 定义和维护服务目录数据和标准服务目录流程的工作流 | ||
| 337 | |||
| 338 | |||
| 339 | 流程可能会有所不同，具体取决于组织的类型和大小，服务的类型和复杂性，服务客户以及服务目录利益相关者。表3.2给出了这些变化的示例。 | ||
| 340 | |||
| 341 | |||
| 342 | 表3.2 活动的定义和维护服务目录数据和标准服务目录视图流程 | ||
| 343 | |||
| 344 | |**活动**|((( | ||
| 345 | **内部服务的服务目录** | ||
| 346 | |||
| 347 | **（“ IT到业务”）** | ||
| 348 | )))|**服务供应商公司的外部服务的服务目录（“ IT作为业务”）** | ||
| 349 | |(% rowspan="2" %)((( | ||
| 350 | 分析利益相关者对于服务目录的需求 | ||
| 351 | |||
| 352 | |||
| 353 | )))|((( | ||
| 354 | 负责服务目录管理的团队分析组织的策略、架构和服务组合。他们识别了关键的利益相关者团体，通常是： | ||
| 355 | |||
| 356 | * IT内部 | ||
| 357 | * 客户 | ||
| 358 | * 用户 | ||
| 359 | |||
| 360 | |||
| 361 | 团队发现并分析利益相关者的需求。这可能涉及关系经理，业务分析人员和用户支持专家。在可能的情况下，与主要利益相关者进行访谈并对其工作进行直接观察。 | ||
| 362 | )))|((( | ||
| 363 | 负责服务目录管理实践的团队分析组织的策略、架构和服务组合。他们识别关键的利益相关者团体，这些利益相关者团体组通常是内部和/或外部用户和客户、内部团队、合作伙伴和供应商 | ||
| 364 | |||
| 365 | 团队发现并分析利益相关者的需求。这可能涉及关系经理，业务分析人员，供应商管理人员和用户支持专家。 | ||
| 366 | |||
| 367 | |||
| 368 | 需求的来源包括： | ||
| 369 | |||
| 370 | * 市场调研 | ||
| 371 | * 基准测试调研 | ||
| 372 | * 现有的市场，或行业标准和最佳实践 | ||
| 373 | * 适用的规章 | ||
| 374 | ))) | ||
| 375 | |(% colspan="2" %)((( | ||
| 376 | 需求分析用于定义以下内容： | ||
| 377 | |||
| 378 | * 服务目录所要求的服务描述粒度 | ||
| 379 | * 适用于所有服务的核心服务数据的结构 | ||
| 380 | * 利益相关者需求数据的来源 | ||
| 381 | ))) | ||
| 382 | |定义服务目录数据结构|(% colspan="2" %)((( | ||
| 383 | 基于收集和分析的需求来定义了服务目录的结构，包括组织中的所有服务通用的核心服务数据和从其他来源获得的特定于视图的数据。 | ||
| 384 | |||
| 385 | 分析得到的数据结构用来定义: | ||
| 386 | |||
| 387 | * 收集和维护数据的技术方法 | ||
| 388 | * 定义和展示标准目录视图的方法 | ||
| 389 | * 自动化和集成需求 | ||
| 390 | |||
| 391 | 在内部或与第三方供应商合作的情况下，自动化和集成需求作为其他自动化需求进行处理。目录技术解决方案的实施不属于本实践的范围。但是服务目录经理作为自动化解决方案的客户，参与所有相关活动。 | ||
| 392 | ))) | ||
| 393 | |为关键利益相关者团体定义并约定的服务目录标准视图|(% colspan="2" %)根据约定的需求和数据结构，定义了关键目录用户组的标准视图。必要时，记录并提交自动化需求；在相关情况下，与目录自动化团队一起合作，来编制设置和使用视图的用户手册。 | ||
| 394 | |收集和维护服务目录数据|(% colspan="2" %)((( | ||
| 395 | * 在满足自动化和集成的所有需求并实施目录自动化解决方案后，按照约定的结构收集和输入约定的数据。 | ||
| 396 | * 在相关情况下，约定、测试和实施数据更新程序和工具。 | ||
| 397 | * 服务目录经理与外部数据所有者合作，以确保及时有效地更新目录。在适用的情况下，与合作伙伴和供应商约定使用数据共享协议或应用程序接口，以确保数据流是结构化的和被管理的。 | ||
| 398 | * 服务目录经理与其他团队合作，以确保目录数据是正确和完整的，自动化工具可以按约定的方式工作，并且满足利益相关者对服务目录的需求。 | ||
| 399 | ))) | ||
| 400 | |||
| 401 | |||
| 402 | === **3.2.2 向约定的目标受众提供和维护最新的服务目录视图** === | ||
| 403 | |||
| 404 | 该流程专注于服务目录的运维。它确保了目录用户对约定目录视图的请求得到及时、正确的满足。 | ||
| 405 | |||
| 406 | 在大多数情况下，此流程完全或很大部分上是自动化的。请求渠道、访问规则、展示的数据及其可视化被约定为服务目录设计和自动化的一部分；目录用户只需“打开”他们需要的目录视图就可以访问它。在某些情况下，由于不常用的请求或不完全的自动化，此流程可能有手工活动。 | ||
| 407 | |||
| 408 | 该流程包括以下活动，并将以下输入转换为输出，如表3.3所示。 | ||
| 409 | |||
| 410 | |||
| 411 | 表3.3为约定的目标受众提供和维护最新的服务目录视图的输入、活动和输出 | ||
| 412 | |||
| 413 | |**关键输入**|**活动**|**关键输出** | ||
| 414 | |((( | ||
| 415 | * 服务目录数据 | ||
| 416 | * 用户和客户反馈，包括表扬和投诉 | ||
| 417 | * 目录用户对目录视图的需求 | ||
| 418 | * 访问规则和控制 | ||
| 419 | * 相关外部数据 | ||
| 420 | )))|((( | ||
| 421 | * 处理服务目录视图的请求 | ||
| 422 | * 验证服务目录请求 | ||
| 423 | * 形成并展示请求的视图 | ||
| 424 | * 请求和处理用户反馈 | ||
| 425 | )))|((( | ||
| 426 | * 服务目录视图 | ||
| 427 | * 反馈数据 | ||
| 428 | * 外部数据查询 | ||
| 429 | ))) | ||
| 430 | |||
| 431 | |||
| 432 | 图3.3显示了提供和维护最新服务目录的工作流。 | ||
| 433 | |||
| 434 | |||
| 435 | (% style="text-align:center" %) | ||
| 436 | [[image:1641126250786-871.png]] | ||
| 437 | |||
| 438 | 图3.3 向约定的目标受众流程提供和维护最新服务目录视图的工作流 | ||
| 439 | |||
| 440 | |||
| 441 | 该流程的活动应该尽可能地自动化。 | ||
| 442 | |||
| 443 | |||
| 444 | 表3.4 向约定的目标受众流程提供和维护最新的服务目录视图的活动 | ||
| 445 | |||
| 446 | |活动|全自动流程|大部分靠手动流程 | ||
| 447 | |处理服务目录视图的请求|目录用户用应用程序接口选择目录视图|((( | ||
| 448 | * 内部目录用户联系服务目录经理；外部用户和客户通过约定的渠道联系服务提供者。 | ||
| 449 | * 收到请求后，服务目录经理确定满足请求所需的数据和数据源。 | ||
| 450 | ))) | ||
| 451 | |验证服务目录请求|((( | ||
| 452 | * 在适用的情况下，目录管理信息系统检查所请求的数据的可用性和质量，包括外部集成。 | ||
| 453 | * 如果验证失败，用户会收到一条相关消息。 | ||
| 454 | )))|((( | ||
| 455 | * 服务目录经理验证请求者对请求的数据和数据可用性的权利。 | ||
| 456 | * 如果验证失败，用户会收到一条相关消息。 | ||
| 457 | ))) | ||
| 458 | |形成并展示请求的视图|所请求的数据用于形成所请求的视图，并以约定的形式展示（通常在屏幕上）。|服务目录经理收集相关的数据并形成请求的视图。它以约定的形式展示给请求者。 | ||
| 459 | |请求和处理用户的反馈|(% colspan="2" %)根据约定的时间表或在验证检查失败的情况下，邀请目录用户留下反馈意见。反馈数据用作目录设计的流程和其他改进倡议的输入。 | ||
| 460 | |||
| 461 | |||
| 462 | 服务目录管理活动由服务目录管理人员和负责服务的开发和运维团队执行，如表3.2和3.4中所述。他们也可能涉及供应商和合作伙伴。这些活动还受到工具和技术的支持（有时是完全或部分自动化）。自动化介绍在第5节。 | ||
| 463 | |||
| 464 | |||
| 465 | |||
| 466 | ---- | ||
| 467 | |||
| 468 | = **4 组织和人员** = | ||
| 469 | |||
| 470 | |||
| 471 | == **4.1 角色，能力和职责** == | ||
| 472 | |||
| 473 | 实践指南没有描述实践管理的角色，例如实践所有者，实践领导者或实践教练。相反，他们专注于每个实践的专家角色。每个角色的结构和命名都可能在组织间是不同的，因此ITIL中定义的任何角色都不应被视为强制性的，甚至也不是推荐的。请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。 | ||
| 474 | |||
| 475 | 流程和活动的场景中描述了角色。每个角色都具有一个基于表4.1中所示的模型的能力类型。 | ||
| 476 | |||
| 477 | 表4.1能力代码和类型 | ||
| 478 | |||
| 479 | |能力代码|能力类型（活动和技能） | ||
| 480 | |**L**|**领导者** 决策，委派，监督其他活动，提供激励和动机，以及评估结果 | ||
| 481 | |**A**|**管理员** 分配任务并确定优先级，保留记录，进行报告，并启动基本改进 | ||
| 482 | |**C**|**协调员/沟通者** 协调多方，维护利益相关者间的沟通，并运行意识宣传活动 | ||
| 483 | |**M**|**方法和技术专家** 设计和实施工作技术，编制程序文档，过程、工作分析和持续改进的咨询 | ||
| 484 | |**T**|**技术专家 **提供技术（IT）专业知识并进行基于专业知识的任务 | ||
| 485 | |||
| 486 | 表4.2显示了服务管理实践活动涉及的角色。 | ||
| 487 | |||
| 488 | |||
| 489 | 表4.2负责服务目录管理活动的角色示例 | ||
| 490 | |||
| 491 | |**活动**|**负责角色**|**能力类型**|**具体技能** | ||
| 492 | |(% colspan="4" %)定义和维护服务目录数据和标准服务目录视图 | ||
| 493 | |分析利益相关者对服务目录的需求|((( | ||
| 494 | 服务目录经理 | ||
| 495 | |||
| 496 | 服务设计者 | ||
| 497 | |||
| 498 | 业务分析员 | ||
| 499 | |||
| 500 | 服务负责人 | ||
| 501 | )))|((( | ||
| 502 | CTA | ||
| 503 | |||
| 504 | |||
| 505 | |||
| 506 | |||
| 507 | )))|((( | ||
| 508 | 理解利益相关者的工作和需求 | ||
| 509 | |||
| 510 | 分析能力，沟通能力 | ||
| 511 | ))) | ||
| 512 | |定义服务目录数据结构|((( | ||
| 513 | 服务目录经理 | ||
| 514 | |||
| 515 | 服务架构师 | ||
| 516 | |||
| 517 | 服务设计者 | ||
| 518 | |||
| 519 | 供应商经理 | ||
| 520 | )))|((( | ||
| 521 | TC | ||
| 522 | |||
| 523 | |||
| 524 | |||
| 525 | )))|((( | ||
| 526 | 理解组织的系统和数据架构 | ||
| 527 | |||
| 528 | 系统分析 | ||
| 529 | |||
| 530 | 沟通技巧 | ||
| 531 | ))) | ||
| 532 | |为关键利益相关者团体定义并约定的服务目录标准视图|((( | ||
| 533 | 服务目录经理 | ||
| 534 | |||
| 535 | 服务架构师 | ||
| 536 | |||
| 537 | 服务设计者 | ||
| 538 | |||
| 539 | 服务负责人 | ||
| 540 | |||
| 541 | 客户关系经理 | ||
| 542 | |||
| 543 | 供应商经理 | ||
| 544 | )))|((( | ||
| 545 | TC | ||
| 546 | |||
| 547 | |||
| 548 | |||
| 549 | )))|((( | ||
| 550 | 理解目录用户的需求 | ||
| 551 | |||
| 552 | 可用工具和用户体验 | ||
| 553 | |||
| 554 | 设计思维 | ||
| 555 | |||
| 556 | 沟通技巧 | ||
| 557 | ))) | ||
| 558 | |收集和维护服务目录数据|((( | ||
| 559 | 服务目录经理 | ||
| 560 | |||
| 561 | 系统负责人 | ||
| 562 | |||
| 563 | 技术专家 | ||
| 564 | )))|T|((( | ||
| 565 | 数据架构的知识 | ||
| 566 | |||
| 567 | 技术能力 | ||
| 568 | ))) | ||
| 569 | |(% colspan="4" %)向约定的目标受众提供和维护最新的服务目录视图 | ||
| 570 | |处理服务目录视图的请求|((( | ||
| 571 | 如果手动： | ||
| 572 | |||
| 573 | 服务目录经理 | ||
| 574 | |||
| 575 | 服务台客服 | ||
| 576 | |||
| 577 | 核算经理 | ||
| 578 | |||
| 579 | 服务负责人 | ||
| 580 | |||
| 581 | 销售经理 | ||
| 582 | )))|C|理解请求者的场景和需求 | ||
| 583 | |验证服务目录请求|((( | ||
| 584 | 如果手动： | ||
| 585 | |||
| 586 | 服务目录经理 | ||
| 587 | )))|((( | ||
| 588 | CTA | ||
| 589 | |||
| 590 | |||
| 591 | |||
| 592 | |||
| 593 | )))|((( | ||
| 594 | 理解目录用户的需求 | ||
| 595 | |||
| 596 | 熟悉服务目录的结构和集成 | ||
| 597 | |||
| 598 | 访问控制和相关工具的技能 | ||
| 599 | ))) | ||
| 600 | |形成并展示请求的视图|((( | ||
| 601 | 如果手动： | ||
| 602 | |||
| 603 | 服务目录经理 | ||
| 604 | )))|TC|((( | ||
| 605 | 技术能力 | ||
| 606 | |||
| 607 | 熟悉服务目录的结构和集成 | ||
| 608 | |||
| 609 | 沟通技巧 | ||
| 610 | ))) | ||
| 611 | |请求和处理用户的反馈|((( | ||
| 612 | 如果是手动： | ||
| 613 | |||
| 614 | 服务目录经理 | ||
| 615 | |||
| 616 | 服务台客服 | ||
| 617 | |||
| 618 | 关系经理 | ||
| 619 | )))|((( | ||
| 620 | C | ||
| 621 | |||
| 622 | |||
| 623 | )))|((( | ||
| 624 | 沟通技巧 | ||
| 625 | |||
| 626 | 了解先前的反馈和改进点情况 | ||
| 627 | ))) | ||
| 628 | |||
| 629 | |||
| 630 | === **4.1.1 服务目录经理角色** === | ||
| 631 | |||
| 632 | 服务目录经理负责组织中的服务目录。角色具有以下主要职责： | ||
| 633 | |||
| 634 | * 定义、设计和维护服务目录 | ||
| 635 | * 理解和管理利益相关者关系 | ||
| 636 | * 不断改进服务目录的结构、自动化和视图 | ||
| 637 | * 有效地将服务目录集成到价值流中 | ||
| 638 | * 与其他团队和角色进行有效合作 | ||
| 639 | * 不断改进此实践 | ||
| 640 | |||
| 641 | 在大型组织中，通常会看到一个或多个员工完全专用于此角色的职位。 | ||
| 642 | |||
| 643 | |||
| 644 | === **4.1.2 组织结构和团队** === | ||
| 645 | |||
| 646 | 如果组织有多个服务目录经理，则服务目录管理团队可能已经形成。这个团队可以由不同组织架构的成员组成，也可以由一个单独组织架构自行支持。 | ||
| 647 | |||
| 648 | 在满足下列条件之一时，更常见的情况是有一个专门的团队来管理服务目录： | ||
| 649 | |||
| 650 | * 服务目录对于组织的业务是复杂且至关重要的。 | ||
| 651 | * 数据目录更新没有足够的自动化，因此需要手动操作。 | ||
| 652 | * 目录的结构和内容不断变化。 | ||
| 653 | |||
| 654 | 服务目录管理团队的成员应一起开发在表4.2中所述的能力和技能。 | ||
| 655 | |||
| 656 | |||
| 657 | |||
| 658 | ---- | ||
| 659 | |||
| 660 | = **5 信息和技术** = | ||
| 661 | |||
| 662 | |||
| 663 | == **5.1 信息交流** == | ||
| 664 | |||
| 665 | 服务目录管理实践的效果基于所使用信息的质量。该信息包括但不限于以下信息： | ||
| 666 | |||
| 667 | * 组织的策略、产品组合和架构 | ||
| 668 | * 组织结构和利益相关者团体 | ||
| 669 | * 服务消费者群体、客户和用户 | ||
| 670 | * 服务及其架构和设计、状态和配置 | ||
| 671 | * 合作伙伴和供应商，包括合同和协议约定 | ||
| 672 | * 规范服务提供的法规、政策和要求 | ||
| 673 | * 服务和服务供应的财务方面（价格、促销、优惠、条款和条件） | ||
| 674 | * 服务提供规程和工作流 | ||
| 675 | * 服务交付和支持团队的联系方式和工作时间表 | ||
| 676 | |||
| 677 | 该信息可以采用各种形式。实践的关键输入和输出在第3节中列出。 | ||
| 678 | |||
| 679 | 服务目录中使用的信息量可能因其约定的用途和结构而有所不同。然而，关键的服务数据通常包括： | ||
| 680 | |||
| 681 | * 服务名称 | ||
| 682 | * 服务说明 | ||
| 683 | * 服务状况 | ||
| 684 | * 服务负责人 | ||
| 685 | * 服务目标受众 | ||
| 686 | |||
| 687 | |||
| 688 | 表5.1包含了通常包含在其他来源的服务目录中的信息示例。 | ||
| 689 | |||
| 690 | |||
| 691 | 表5.1从其他来源获得的服务目录信息示例 | ||
| 692 | |||
| 693 | |**属性**|**资料来源** | ||
| 694 | |服务级别，客户，用户和用户的详细信息，价格，协议的状态以及关键日期，联系方式，可用的服务请求，服务度量指标和关键绩效指标KPI|与客户约定的服务级别协议 | ||
| 695 | |支持服务，相关合同，服务级别，联系方式，约束，状态和关键日期|与供应商约定的服务级别协议 | ||
| 696 | |服务的成本，价格，其他财务数据|服务财务模型，预算，价格表 | ||
| 697 | |相关服务和配置项，支持团队及其联系方式|配置管理数据库, 服务模型 | ||
| 698 | |相关记录（事件，问题，变更）|相应记录 | ||
| 699 | |||
| 700 | |||
| 701 | == **5.2 自动化和工具** == | ||
| 702 | |||
| 703 | 在大多数情况下，服务目录管理实践可以从自动化中获益。在可能和有效的情况下，它可能涉及表5.2中列出的解决办法。 | ||
| 704 | |||
| 705 | 表5.2 服务目录管理活动的自动化解决方案 | ||
| 706 | |||
| 707 | |**流程活动**|**自动化手段**|**关键功能**|**对此实践效果的影响** | ||
| 708 | |(% colspan="4" %)定义和维护服务目录数据和标准服务目录视图 | ||
| 709 | |分析利益相关者对服务目录的需求|通讯和协作工具|((( | ||
| 710 | 需求的收集和评审 | ||
| 711 | |||
| 712 | |||
| 713 | )))|低 | ||
| 714 | |定义服务目录数据结构|数据建模工具|((( | ||
| 715 | 数据建模和可视化 | ||
| 716 | |||
| 717 | |||
| 718 | )))|高 | ||
| 719 | |为关键利益相关者团体提定义并约定的服务目录标准视图|信息系统设计和建模工具|表格设计|高 | ||
| 720 | |收集和维护服务目录数据|((( | ||
| 721 | 数据集成工具，数据库管理工具，专用目录管理工具，集成的服务管理工具集 | ||
| 722 | |||
| 723 | |||
| 724 | )))|初始数量和正在进行的维护的服务目录数据，集成和视图|高 | ||
| 725 | |(% colspan="4" %)为约定的目标受众提供和维护最新的服务目录视图 | ||
| 726 | |((( | ||
| 727 | 处理服务目录视图的需求 | ||
| 728 | |||
| 729 | 验证服务目录请求 | ||
| 730 | |||
| 731 | 形成并展示请求的视图 | ||
| 732 | )))|集成的服务管理工具集，用户门户网站|一个相关的可操作的目录视图的展示|高 | ||
| 733 | |请求和处理用户反馈|集成的服务管理工具集，用户门户网站，满意度调查工具，评级工具|收集用户反馈|中 | ||
| 734 | |||
| 735 | |||
| 736 | |||
| 737 | ---- | ||
| 738 | |||
| 739 | = **6 合作伙伴和供应商** = | ||
| 740 | |||
| 741 | 仅使用自己的资源交付服务的组织很少。大多数（如果不是全部）依赖于其他方的服务，这些服务通常由组织之外的第三方提供（请参阅ITIL Foundation ITIL 4版的2.4：服务关系）。这些依赖关系可能会影响服务目录管理实践，并反映在服务目录中。 | ||
| 742 | |||
| 743 | 此实践有三个主要的注意事项： | ||
| 744 | |||
| 745 | * 服务目录中的第三方服务 | ||
| 746 | * 供应商访问组织的服务目录 | ||
| 747 | * 为服务目录自动化使用的第三方工具 | ||
| 748 | |||
| 749 | |||
| 750 | == **6.1 服务目录中的第三方服务** == | ||
| 751 | |||
| 752 | 一些第三方服务可能在技术上直接提供给组织的客户，而组织则作为唯一责任点和联系方式。服务目录是客户和用户的关键触面，应提供有关第三方服务的正确和最新信息；它应该与其他组织的服务一样可操作。 | ||
| 753 | |||
| 754 | 组织的服务经常依赖于第三方服务，其中许多依赖关系会影响目录中包含的服务属性。 | ||
| 755 | |||
| 756 | 确保组织的服务目录与供应商的数据源及其服务目录集成在一起是非常重要的。该集成应该尽可能是无缝的，以确保相关数据的更新没有延迟，这可能影响到组织服务目录信息的质量。 | ||
| 757 | |||
| 758 | 当组织作为服务集成商或作为集成供应商之一参与复杂的服务网络时，服务目录可能会成为网络参与方之间重要的集成点。 | ||
| 759 | |||
| 760 | |||
| 761 | == **6.2 供应商对组织的服务目录的访问** == | ||
| 762 | |||
| 763 | 是否需要供应商的专家参与组织的服务运营和支持，取决于组织对第三方服务的依赖性。许多组织为供应商和合作伙伴提供有关他们服务的相关信息访问权限，并且服务目录作为关键接口。供应商的专家可能使用与组织的技术团队类似的目录视图，但是具有不同的访问级别。重要的是确保组织中的安全策略和合同义务不受损害，尤其是是在供应商可能有权限访问有关服务消费者和其他供应商的信息的情况下。 | ||
| 764 | |||
| 765 | |||
| 766 | == **6.3 为服务目录自动化使用第三方工具** == | ||
| 767 | |||
| 768 | 服务目录管理实践高度依赖自动化，通常使用第三方专用解决方案来自动化服务目录管理活动。组织在选择集成的服务管理工具集时，重点要考虑对自动化和集成的需求。在服务目录结构设计和回顾期间以及运营期间，很大可能需要将服务目录数据提供给ITSM工具集的供应商或支持伙伴。这种访问意味着在选择ITSM工具集供应商并约定支持合同时，需要进行额外的尽职调查。服务目录集成程度越高，原始数据越敏感。 | ||
| 769 | |||
| 770 | |||
| 771 | |||
| 772 | ---- | ||
| 773 | |||
| 774 | = **7 重要提醒** = | ||
| 775 | |||
| 776 | 本实践指南的大部分内容都应作为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题的目录而非答案列表。使用ITIL 实践指南的内容时，组织应始终遵循ITIL 指导原则： | ||
| 777 | |||
| 778 | * 聚焦价值 | ||
| 779 | * 从你所处的地方开始 | ||
| 780 | * 基于反馈迭代推进 | ||
| 781 | * 协作和提升可视化程度 | ||
| 782 | * 通盘思考和工作 | ||
| 783 | * 保持简单实用 | ||
| 784 | * 优化和自动化 | ||
| 785 | |||
| 786 | 有关指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。 | ||
| 787 | |||
| 788 | |||
| 789 | |||
| 790 | ---- | ||
| 791 | |||
| 792 | = **8 致谢** = | ||
| 793 | |||
| 794 | AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。 | ||
| 795 | |||
| 796 | |||
| 797 | == **8.1 作者** == | ||
| 798 | |||
| 799 | Donka Raytcheva，Antonina Klentsova | ||
| 800 | |||
| 801 | |||
| 802 | == **8.2 审阅者** == | ||
| 803 | |||
| 804 | Dinara Adyrbai， Akshay Anand， Roman Jouravlev | ||
| 805 | |||
| 806 |