Wiki源代码05 ITIL管理实践
由 superadmin 于 2024/04/03, 13:16 最后修改
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | |||
2 | |||
3 | |||
4 | [[阅读下一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/6%20%E5%B0%BE%E6%B3%A8%20ITIL%E7%9A%84%E6%95%85%E4%BA%8B%EF%BC%8C%E4%B8%80%E5%B9%B4%E8%BF%87%E5%8E%BB%E4%BA%86/]] [[返回上一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/4%20%20ITIL%E6%9C%8D%E5%8A%A1%E4%BB%B7%E5%80%BC%E7%B3%BB%E7%BB%9F/]] | ||
5 | |||
6 | {{box cssClass="floatinginfobox" title="**Contents**"}} | ||
7 | {{toc/}} | ||
8 | {{/box}} | ||
9 | |||
10 | = **5 ITIL管理实践** = | ||
11 | |||
12 | |||
13 | |||
14 | ITIL SVS包括14个通用管理实践,17个服务管理实践和三个技术管理实践,所有这些都受服务管理的四个维度的约束(请参阅第3章)。 | ||
15 | |||
16 | |||
17 | (% class="box infomessage" %) | ||
18 | ((( | ||
19 | **关键信息:** | ||
20 | |||
21 | 在ITIL中,管理实践是一组旨在执行工作或实现目标的组织资源。这些实践的起源如下: | ||
22 | |||
23 | ●通用管理实践已经被通用业务管理领域采用并适应于服务管理。 | ||
24 | |||
25 | ●服务管理实践在服务管理和ITSM行业中得到了发展。 | ||
26 | |||
27 | ●为了服务管理的目的,技术管理实践已经从技术管理领域进行了调整,方法是将它们的重点从技术解决方案扩展或转移到IT服务。 | ||
28 | ))) | ||
29 | |||
30 | |||
31 | 表5.1列出了34种ITIL管理实践。 | ||
32 | |||
33 | 表5.1 ITIL管理实践 | ||
34 | |||
35 | [[image:1641706540753-270.png]] | ||
36 | |||
37 | |||
38 | (% class="box" %) | ||
39 | ((( | ||
40 | **ITSM在现代世界:高速服务交付** | ||
41 | |||
42 | 在业务创新和差异化方面,加快上市速度是成功的关键因素。如果一个组织花费太长时间来实现一个新的商业创意,那么其他人可能会更快地完成。因此,组织开始要求IT服务提供商缩短产品上市时间。 | ||
43 | |||
44 | |||
45 | 对于一直使用现代技术的服务提供商来说,这并不是一个很大的挑战。他们采用现代方式扩展其资源,并为项目和产品管理、测试、集成、部署、发布、交付和IT服务支持建立了适当的实践。这些实践已经记录在案,并引发了新的IT管理运动和实践的开发,例如DevOps。但是,对于拥有旧IT架构和IT管理实践的组织而言,这些组织专注于控制和成本效率,新的业务需求带来了更大的挑战。 | ||
46 | |||
47 | 高速服务交付范例包括: | ||
48 | |||
49 | ●专注于为用户快速交付新的和变更的IT服务 | ||
50 | |||
51 | ●持续分析在其生命周期的每个阶段为IT服务提供的反馈 | ||
52 | |||
53 | ●灵活处理反馈,促进IT服务的持续快速改进 | ||
54 | |||
55 | ●服务生命周期的端到端方法,从构思、创建和交付到服务消费 | ||
56 | |||
57 | ●整合产品和服务管理实践 | ||
58 | |||
59 | ●IT基础设施的数字化和云计算的采用 | ||
60 | |||
61 | ●服务交付链的广泛自动化。 | ||
62 | |||
63 | |||
64 | 高速服务交付影响服务提供商的所有实践,包括一般管理实践,服务管理实践和技术管理实践。例如,一个旨在以比其他人更快的速度提供和改进服务的组织需要考虑: | ||
65 | |||
66 | ●敏捷项目管理 | ||
67 | |||
68 | ●敏捷的财务管理 | ||
69 | |||
70 | ●基于产品的组织结构 | ||
71 | |||
72 | ●适应性风险管理,审计和合规管理 | ||
73 | |||
74 | ●灵活的架构管理 | ||
75 | |||
76 | ●特定架构技术解决方案,如微服务 | ||
77 | |||
78 | ●复杂的合作伙伴和供应商环境 | ||
79 | |||
80 | ●持续监控技术创新和实验 | ||
81 | |||
82 | ●以人为本的设计 | ||
83 | |||
84 | ●基础架构管理,专注于云计算。 | ||
85 | |||
86 | |||
87 | 即使提供商的投资组合中只有一些服务需要高速交付,也需要进行大规模的组织变革才能实现这一点,特别是如果组织具有低速服务,实践和习惯的遗留问题。此外,高速服务管理与传统实践相结合的双模IT引入了更多的复杂性和更大的挑战。然而,对于许多现代组织而言,高速服务交付不再是一种选择,而是必需品,它们必须改进其服务管理实践以应对这一挑战。 | ||
88 | ))) | ||
89 | |||
90 | |||
91 | == **5.1 通用管理实践** == | ||
92 | |||
93 | |||
94 | === **5.1.1 架构管理** === | ||
95 | |||
96 | |||
97 | (% class="box infomessage" %) | ||
98 | ((( | ||
99 | **关键信息:** | ||
100 | |||
101 | 架构管理实践的目的是提供对构成组织的所有不同元素的理解,以及这些元素如何相互关联,从而使组织能够有效地实现其当前和未来的目标。它提供了原则、标准和工具,使组织能够以结构化和敏捷的方式管理复杂的变更。 | ||
102 | ))) | ||
103 | |||
104 | |||
105 | 正如现代组织的环境和生态系统变得更加复杂,其挑战也是如此。这些不仅包括如何提高效率和自动化,还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹性。如果没有通过适当的架构管理实践实现可见性和协调,组织可能成为/陷入第三方合同的迷宫,跨不同组织孤岛的不同的流程,为不同客户不必要地定制的各种产品和服务,以及传统基础架构。结果是一个复杂的环境,任何变化都难以实施,并带来更高的风险。 | ||
106 | |||
107 | |||
108 | 完整的架构管理实践应涵盖所有架构领域:业务、服务、信息、技术和环境。对于规模较小且不太复杂的组织,架构师可以开发单一的集成架构。 | ||
109 | |||
110 | |||
111 | (% class="box" %) | ||
112 | ((( | ||
113 | **架构类型:** | ||
114 | |||
115 | |||
116 | **业务架构** | ||
117 | |||
118 | 业务架构允许组织查看其能力,以使其为组织及其客户共同创造价值所需的所有详细活动保持一致。然后将这些与组织的战略进行比较,并执行目标状态与当前能力的差距分析。确定基线和目标状态之间的已确定差距的优先级,并逐步解决这些能力差距。“路线图”描述了从当前状态到未来状态的转变,以实现组织的战略。 | ||
119 | |||
120 | |||
121 | **服务架构** | ||
122 | |||
123 | 服务架构为组织提供了所有服务的视图,包括描述每个服务的结构(服务组件如何组合在一起)和动态(活动、资源流和交互)的服务和服务模型之间的交互。服务模型可以用作多个服务的模板或蓝图。 | ||
124 | |||
125 | |||
126 | **信息系统架构,包括数据和应用程序架构** | ||
127 | |||
128 | 信息架构描述了组织的逻辑和物理数据资产以及数据管理资源。它显示了如何管理和共享信息资源以使组织受益。 | ||
129 | |||
130 | 信息是组织的宝贵资产,具有实际和可衡量的价值。信息是决策的基础,因此它必须始终是完整的、准确的,并且只有经过授权的人员才能访问。因此,在设计和管理信息系统时必须牢记这些概念。 | ||
131 | |||
132 | |||
133 | **技术架构** | ||
134 | |||
135 | 技术架构定义了支持产品和服务的组合所需的软件和硬件基础架构。 | ||
136 | |||
137 | |||
138 | **环境架构** | ||
139 | |||
140 | 环境架构描述了影响组织变革的外部驱动因素,以及环境控制及其管理的所有方面、类型和水平。环境包括发展、技术、商业、运营、组织、政治、经济、法律、监管、生态和社会影响。 | ||
141 | ))) | ||
142 | |||
143 | |||
144 | |||
145 | 图5.1显示了架构管理对服务价值链的贡献,该实践涉及所有价值链活动;但是,它在计划、改进、设计和转换价值链活动中起着至关重要的作用: | ||
146 | |||
147 | * **计划** 架构管理实践负责开发和维护参考架构,描述了业务、信息、数据、应用程序、技术和环境方面的当前和目标架构。这用作所有计划价值链活动的基础。 | ||
148 | * **改进** 通过审查业务、服务、信息、技术和环境架构,便于识别许多改进的机会。 | ||
149 | * **契动** 架构管理实践有助于理解组织为应对新的或服务不足的市场,以及更广泛的产品和服务的做好准备的能力,并能更快地响应不断变化的环境。架构管理实践负责评估组织的能力,以使其为组织及其客户共同创造价值所需的所有详细活动保持一致。 | ||
150 | * **设计和转换** 一旦批准开发新的或变更的产品或服务,架构、设计和构建团队将不断评估产品/服务是否符合投资目标。架构管理实践负责服务架构,该架构描述服务的结构(服务组件如何组合在一起)和动态(活动、资源流和交互)。服务模型可以用作多个服务的模板或蓝图,对于设计和转换活动至关重要。 | ||
151 | * **获取/构建** 参考架构(业务、服务、信息、技术和环境)促进识别需要获取或构建的产品、服务或服务组件。 | ||
152 | * **交付和支持** 参考架构可以作为产品和服务的操作,恢复和维护中的一部分被连续使用。 | ||
153 | |||
154 | (% style="text-align:center" %) | ||
155 | [[image:1640356602416-800.png]] | ||
156 | |||
157 | 图5.1架构管理对价值链活动的贡献热力图 | ||
158 | |||
159 | |||
160 | === **5.1.2 持续改进** === | ||
161 | |||
162 | |||
163 | (% class="box infomessage" %) | ||
164 | ((( | ||
165 | **关键信息:** | ||
166 | |||
167 | 持续改进实践的目的是通过持续改进产品、服务和实践,或任何涉及产品和服务管理的元素,使本组织的实践和服务与不断变化的业务需求保持一致。 | ||
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 | ITIL SVS包括持续改进模型(参见图4.3),该模型可应用于任何类型的改进,从高级组织变更到单个服务和配置项(CI)。该模型在4.6节中描述。 | ||
197 | |||
198 | |||
199 | 在评估当前状态时,可以采用许多技术,例如优势、劣势、机会和威胁(SWOT)分析,平衡记分卡评审,内部和外部评估和审计,或者甚至是几种技术的组合。组织应开发能够满足其需求的方法和技术的能力。 | ||
200 | |||
201 | |||
202 | 在很多地方都可以找到持续改进的方法。精益方法提供了消除浪费的观点。敏捷方法专注于循序渐进地改进。DevOps方法是整体工作的,确保改进不仅设计合理,而且有效应用。尽管有许多可用的方法,但组织不应试图正式使用过多的不同方法。最好选择一些与组织常用的改进类型相适合的关键方法,并培养这些方法。通过这种方式,团队将共同理解如何共同改进,以更快的速度促进更大的变化。 | ||
203 | |||
204 | |||
205 | 但是,这并不意味着组织不应该尝试新的方法或进行创新。应该鼓励组织中具有替代方法技能的人,在有意义的情况下应用它们,如果这种努力成功了,可以将替代方法添加到组织的功能库中。如果取得了更好的结果,旧的方法可能会逐渐退运,转而采用新方法。 | ||
206 | |||
207 | |||
208 | 持续改进是每个人的责任。尽管可能会有一组全职工作人员专注于这项工作,但组织中的每个人都必须理解,积极参与持续改进活动是他们工作的核心部分,这一点至关重要。为了确保这不仅仅是一个好意图,明智的做法是在所有工作描述和每个员工的目标,以及与外部供应商和承包商的合同中加入对持续改进的贡献。 | ||
209 | |||
210 | |||
211 | 组织的最高层需要承担将持续改进嵌入人们思考和工作方式的责任。如果没有他们的领导和对持续改进的明确承诺、态度、行为和文化,就不会发展到在所有层面上都要考虑改进的程度。 | ||
212 | |||
213 | |||
214 | 应向员工提供培训和其他支持帮助,以帮助他们做好准备,为持续改进做出贡献。尽管每个人都应该以某种方式做出贡献,但至少应该有一个专门负责领导持续改进工作并在整个组织中倡导实践的小团队。该团队可以充当协调员、指导者和导师,帮助组织中的其他人培养他们所需的技能,并解决可能遇到的任何困难。 | ||
215 | |||
216 | |||
217 | 当第三方供应商成为服务领域的一部分时,它们也应该成为改进工作的一部分。在签订供应商服务合同时,合同应包括在合同有效期内如何度量、报告和改进服务的详细信息。如果要求供应商提供数据来进行内部改进,那么也应在合同中规定。准确的数据,经过仔细分析和理解,是基于事实的改进决策的基础。持续改进实践应得到相关数据源和数据分析的支持,以确保对每个潜在的改进都有充分的理解和优先级划分。 | ||
218 | |||
219 | |||
220 | 为了跟踪和管理从识别到最终行动的改进想法,组织使用称为持续改进登记册(CIR)的数据库或结构化文档。组织中可以有多个CIR,因为可以在个人、团队、部门、业务单位和组织级别上维护多个CIR。一些组织维护单个主CIR,但是在更细粒度的上对其进行分段以及由谁进行分段。 | ||
221 | |||
222 | |||
223 | 改进构思最初也可以在其他地方和其他实践中获得,例如在项目执行或软件开发活动期间。在这种情况下,记录作为持续不断改进的一部分而提出的改进构思是很重要的。当新的想法被记录下来时,CIR被用于不断重新确定改进机会的优先级。CIR的使用提供了额外的价值,因为它们有助于使事物可见。这不仅限于目前正在进行的工作,而且还包括已经完成的工作以及已经留出以供日后进一步考虑的工作。 | ||
224 | |||
225 | |||
226 | 确切地说,如何构建CIR中的信息,或者在任何给定的组织中调用改进构思的集合并不重要。重要的是,改进构思被捕获、记录、评估、确定优先级并采取适当的行动,以确保组织及其服务始终得到改进。 | ||
227 | |||
228 | |||
229 | 持续改进实践是所有其他实践的开发和维护的组成部分,也是所有服务的完整生命周期,甚至SVS本身的一部分。也就是说,有些实践对持续改进做出了特殊贡献。例如,组织的问题管理实践可以发现将通过持续改进来管理问题。如果没有组织变革管理的关键贡献,通过持续改进而发起的变革可能会失败。许多改进计划将使用项目管理实践来组织和管理其执行。 | ||
230 | |||
231 | (% style="text-align:center" %) | ||
232 | [[image:1640354049638-677.png]] | ||
233 | |||
234 | 图5.2连续改进点对价值链活动的贡献的热力图 | ||
235 | |||
236 | |||
237 | 图5.2显示了持续改进对服务价值链的贡献,实践涉及所有价值链活动: | ||
238 | |||
239 | * **计划** 持续改进实践应用于计划活动、方法和技术,以确保它们与组织的当前目标和环境相关。 | ||
240 | * **改进** 持续改进实践是这一价值链活动的关键。它构建资源和活动,促进组织和SVS各级的改进。 | ||
241 | * **契动、设计和转换、获取/构建、交付和支持 **每一项价值链活动都受制于持续改进,并且持续改进实践应用于所有这些活动。 | ||
242 | |||
243 | |||
244 | |||
245 | |||
246 | |||
247 | === **5.1.3 信息安全管理** === | ||
248 | |||
249 | |||
250 | **关键信息:** | ||
251 | |||
252 | 信息安全管理实践的目的是保护组织开展业务所需的信息。这包括理解和管理信息的保密性、完整性和可用性的风险,以及信息安全的其他方面,例如身份验证(确保某人是他们声称的那个人)和不可抵赖性(确保某人不能否认他们采取了行动)。 | ||
253 | |||
254 | |||
255 | 所需的安全性是通过策略、流程、行为、风险管理和控制措施建立的,必须在以下各项之间保持平衡: | ||
256 | |||
257 | ●**预防:**确保不会发生安全事件 | ||
258 | |||
259 | ●**检测:**快速可靠地检测无法预防的事件 | ||
260 | |||
261 | ●**修正:**从检测到的事件中恢复。 | ||
262 | |||
263 | |||
264 | 在保护组织免受伤害并允许组织创新之间取得平衡也很重要。过于严格的信息安全控制可能弊大于利,也可能被试图更想轻松工作的人所规避。信息安全控制应考虑组织的所有方面,并与其风险偏好保持一致。 | ||
265 | |||
266 | |||
267 | 信息安全管理与其他所有实践相互作用。它创建了每个实践在计划如何完成工作时必须考虑的控制。它还依赖于其他实践来帮助保护信息。 | ||
268 | |||
269 | |||
270 | 信息安全管理必须基于明确理解的治理要求和组织策略,从组织中的最高级别开始。大多数组织都有专门的信息安全团队,负责进行风险评估并定义策略、规程和控制。在高速环境中,信息安全尽可能地集成到日常的开发和运营工作中,将对流程控制的依赖转移到对专业知识和诚信等先决条件的验证上。 | ||
271 | |||
272 | |||
273 | 信息安全严重依赖于整个组织中人们的行为。经过良好培训并注意信息安全策略和其他控制的员工可以帮助检测、预防和修正信息安全事件。训练不足或缺乏动力的员工可能是一个主要的漏洞。 | ||
274 | |||
275 | |||
276 | 需要许多流程和规程来支持信息安全管理。这些包括: | ||
277 | |||
278 | ●信息安全事件管理流程 | ||
279 | |||
280 | ●风险管理流程 | ||
281 | |||
282 | ●控制评审和审计流程 | ||
283 | |||
284 | ●身份和访问管理流程 | ||
285 | |||
286 | ●事态管理 | ||
287 | |||
288 | ●渗透测试,漏洞扫描等规程 | ||
289 | |||
290 | ●管理与信息安全相关变更的规程,例如防火墙配置变更。 | ||
291 | |||
292 | |||
293 | 图5.3显示了信息安全管理对服务价值链的贡献,实践涉及所有价值链活动: | ||
294 | |||
295 | ●**计划:**必须在所有计划活动中考虑信息安全,并且必须将其纳入每项实践和服务中。 | ||
296 | |||
297 | ●**改进:**必须在所有改进价值链活动中考虑信息安全,以确保在进行改进时不会引入漏洞。 | ||
298 | |||
299 | ●**契动:**必须了解和捕获新服务和已变更服务的信息安全要求。从运营到战略,所有级别都必须支持信息安全并鼓励所需的行为。所有利益相关者必须为信息安全做出贡献,包括客户、用户、供应商等。 | ||
300 | |||
301 | ●**设计和转换:**在整个价值链活动中必须考虑安全性,并设计有效的控制将其转换为运营。所有服务的设计和转换必须考虑信息安全方面以及所有其他功用和功效要求。 | ||
302 | |||
303 | ●**获取/构建:**必须根据信息安全管理定义的风险分析、策略、过程和控制,将信息安全构建到所有组件中。无论组件是内部构建还是从供应商采购,这都适用。 | ||
304 | |||
305 | ●**交付和支持:**信息安全事件的检测和修正必须是该价值链活动的一个组成部分。 | ||
306 | |||
307 | |||
308 | (% style="text-align:center" %) | ||
309 | [[image:1640354086430-214.png]] | ||
310 | |||
311 | 图5.3信息安全管理对价值链活动的贡献热力图 | ||
312 | |||
313 | |||
314 | **ITIL故事:艾克苏的信息安全管理** | ||
315 | |||
316 | **苏:**我们的旅行应用程序存储了很多敏感数据,包括客户和信用卡详细信息。我们的任务是确保这些数据是安全的。 | ||
317 | |||
318 | **马可:**我们的合作伙伴也存储和处理了一些数据,他们帮助我们开发了这个应用程序,并继续代表我们支持这个应用程序。 | ||
319 | |||
320 | **拉迪卡:**我们使用这些数据来分析客户需求和我们车队的使用情况,跟踪我们汽车的状况,并分析客户的偏好以创建量身定制的产品。 | ||
321 | |||
322 | **苏:**我们的消费者需要知道他们的数据是安全的,不会被滥用。我们定期接受外部审计,为利益相关方提供保证,并确认符合国家和国际法规。 | ||
323 | |||
324 | **亨利:**作为CIO,我要确保所有在艾克苏工作的人都意识到信息安全的重要性,并遵循艾克苏有关信息安全管理的策略和规程。 | ||
325 | |||
326 | |||
327 | === **5.1.4 知识管理** === | ||
328 | |||
329 | |||
330 | **关键信息:** | ||
331 | |||
332 | 知识管理实践的目的是维护和改进整个组织内信息和知识的有效、高效和便捷的使用。 | ||
333 | |||
334 | |||
335 | 知识是组织最有价值的资产之一。知识管理实践以各种形式提供了一种结构化方法来定义、构建、重用和共享知识(即信息、技能、实践、解决方案和问题)。随着获取和共享知识的方法越来越趋向于数字化解决方案,知识管理的实践变得更加有价值。 | ||
336 | |||
337 | |||
338 | (% style="text-align:center" %) | ||
339 | [[image:1640354114685-875.png]] | ||
340 | |||
341 | 图5.4知识管理对价值链活动的贡献热力图 | ||
342 | |||
343 | |||
344 | 重要的是要理解“知识”,而不仅仅是信息。知识就是在特定环境中对信息的使用。这需要通过知识的使用者和相关情况来理解。例如,对于需要找到快速解决方案的服务台分析师来说,以300页手册的形式提供的信息并不有用。一个更好的适合用途的知识示例可能是一组简化的指令或参考点,这些指令或参考点允许分析员快速找到相关内容。 | ||
345 | |||
346 | |||
347 | 知识管理的目的是确保利益相关者根据其访问级别和其他相关政策,以适当的格式、在适当的级别和适当的时间获取适当的信息。这就需要一个获取知识的程序,包括非结构化知识的开发、捕捉和收获,无论是正式的和书面的知识,还是非正式的和隐性的知识。 | ||
348 | |||
349 | |||
350 | 图5.4显示了知识管理对服务价值链的贡献,实践涉及所有价值链活动: | ||
351 | |||
352 | * **计划:**知识管理有助于组织制定合理的投资组合决策,并定义其战略和其他计划,并支持财务管理。 | ||
353 | * **改进:**此价值链活动是基于对现状和趋势的理解,并辅以历史信息。知识管理为评估成果和改进计划提供了上下文。 | ||
354 | * **契动:**从战略到运营的各个层面的关系都是基于对这些关系的背景和历史的理解。知识管理有助于更好地理解利益相关者。 | ||
355 | * **设计和转换:**与获取/构建价值链活动一样,对可用的解决方案和技术的知识,以及信息的再利用,可以使该价值链活动更加有效。 | ||
356 | * **获取/构建:**通过充分了解可用的解决方案和技术,以及信息的重用,可以显著提高价值链活动的效率。 | ||
357 | * **交付和支持:**通过在标准情况下重复使用解决方案,以及更好地理解需要分析的非标准情境的背景,该领域正在进行的价值链活动可从知识管理中获益。 | ||
358 | |||
359 | |||
360 | **ITIL故事:艾克苏的知识管理** | ||
361 | |||
362 | **拉迪卡:**因为我们在应用程序开发中使用了敏捷部署,所以我们需要确保我们的员工对新功能有最新的知识。同样重要的是,当知识过时,它需要被淘汰。例如,我们最近发现我们的应用程序的打印功能未被我们的客户使用。我们删除了打印,并将其替换为新功能,可以通过电子邮件从应用程序发送信息。作为发布管理的一部分,我们已经向服务台提供了更新的知识文章以反映变更。 | ||
363 | |||
364 | **苏:**知识管理不仅仅是数据收集。在艾克苏,我们专注于开放式沟通和知识共享。为了促进协作和可见性,我们确保在我们的团队和分支机构之间公开共享信息、问题和关注点。 | ||
365 | |||
366 | **亨利:**但我们还需要遵守信息安全政策,确保开放并不意味着粗心大意。 | ||
367 | |||
368 | **马可:**我们正在测试基于AI的新系统,以改进我们在战略规划和用户支持等各个层面的预测和决策。 | ||
369 | |||
370 | |||
371 | === **5.1.5 度量和报告** === | ||
372 | |||
373 | |||
374 | **关键信息:** | ||
375 | |||
376 | 度量和报告实践的目的是通过降低不确定性层级来支持良好的决策和持续改进。这是通过收集各种管理对象的相关数据,并在适当的背景中对这些数据进行有效评估来实现的。管理对象包括但不限于产品和服务、实践和价值链活动、团队和个人,供应商和合作伙伴以及整个组织。 | ||
377 | |||
378 | |||
379 | 其中许多管理对象都是有联系的,它们各自的度量和指标也是如此。例如,要为度量和报告设定明确的目标,就需要理解组织目标。这些可以基于多个领域:利润、增长、竞争优势、客户保留、运营/公共服务等(参见第4.3.1节中关于价值导向原则的重点)。在这种情况下,重要的是在高级和下级目标以及与之相关的目标之间建立明确的关系。 | ||
380 | |||
381 | |||
382 | 对于设定的目标,可以定义运行关键成功因素(CSF)。基于这些CSF,可以约定一组相关的关键绩效指标(KPI),以此度量成功与否。 | ||
383 | |||
384 | |||
385 | **定义**: | ||
386 | |||
387 | ●**关键成功因素(CSF)**实现预期结果的必要前提条件。 | ||
388 | |||
389 | ●**关键绩效指标(KPI)**用于评估实现目标成功与否的重要指标。 | ||
390 | |||
391 | |||
392 | |||
393 | ==== **5.1.5.1 KPI和行为** ==== | ||
394 | |||
395 | 个人的关键绩效指标(KPI)可以作为一种竞争激励因素,如果关键绩效指标(KPI)设定为满足明确的业务目标,这将带来积极的结果。然而,为个人设定目标也可能有消极的一面,从而导致不适当或不适合的行为。如果过多关注单个KPI,通常会发生这种情况。例如,服务台员工可能会被迫缩短通话时间,如果问题得不到妥善处理,这可能会对客户满意度甚至解决时间产生负面影响。 | ||
396 | |||
397 | |||
398 | 理想情况下,应为团队设定运营关键绩效指标(KPI),而不是过于关注个人。这意味着团队作为一个整体所允许的目标和行为可以有一定的灵活性。当然,个人仍然需要一些具体的绩效指导方针,但这应该明确地包含在团队和组织的目标之内,并且所有的目标都应该在为组织提供价值的背景下设定。 | ||
399 | |||
400 | |||
401 | ==== **5.1.5.2 报告** ==== | ||
402 | |||
403 | 作为指标收集的数据通常以报告或仪表板的形式呈现。重要的是要记住,报告旨在支持良好的决策,因此其内容应与信息的接收者相关,并与所需主题相关。报告和仪表板应使收件人能够轻松查看需要完成的操作,然后采取措施。因此,一份好的报告或仪表板应该回答两个主要问题:我们离目标有多远?哪些瓶颈阻碍了我们取得更好的结果? | ||
404 | |||
405 | |||
406 | 图5.5显示了度量和报告对服务价值链的贡献,该实践涉及所有价值链活动: | ||
407 | |||
408 | * **计划:**通过提供有关产品和服务当前绩效的详细信息,度量和报告可实现战略和服务组合决策。 | ||
409 | * **改进:**持续监控和评估绩效,以支持持续改进、调整和创造价值。 | ||
410 | * **契动:**基于以仪表板和报告形式提供的正确、最新和充分的信息,与利益干系人进行契动。 | ||
411 | * **设计和转换:**度量和报告在上线前的每个阶段都为管理决策提供信息。 | ||
412 | * **获取/构建:**该实践可确保所有开发和采购活动的透明度,实现有效管理并与所有其他价值链活动集成。 | ||
413 | * **交付和支持:**产品和服务的持续管理是基于正确、最新和充分的性能信息的。 | ||
414 | |||
415 | (% style="text-align:center" %) | ||
416 | [[image:1640354164666-354.png]] | ||
417 | |||
418 | 图5.5 测量贡献和对价值链活动的报告的热力图 | ||
419 | |||
420 | |||
421 | === **5.1.6 组织变革管理** === | ||
422 | |||
423 | |||
424 | **关键信息:** | ||
425 | |||
426 | 组织变革管理实践的目的是确保组织中的变革顺利、成功地实施,并通过管理变革的人为方面来实现持久的利益。 | ||
427 | |||
428 | |||
429 | 改进总是要求人们改变他们的工作方式、行为方式,有时是他们的角色。无论变革是针对实践、组织结构、与技术相关的,还是引入新的或变更的服务,人都是变革成功的关键。组织变革管理实践旨在确保受变革影响的每个人都接受并支持变革。这是通过消除或减少变革的阻力,消除或解决不利影响,并提供培训、提高意识和其他确保成功过渡到变革状态的方法来实现的。 | ||
430 | |||
431 | |||
432 | 组织变革管理有助于SVS的每个部分,无论哪里都需要参与人员的合作、参与和热情。为使改进举措取得成功,无论变革的程度或范围如何,都有一些对解决人为因素至关重要的元素。组织变革管理必须确保在整个变革过程中建立并维护以下内容: | ||
433 | |||
434 | * **明确且相关的目标:**为了获得支持,变革的目标必须明确,并根据组织的背景对利益干系人有意义。变革必须被认为是具有实际价值的。 | ||
435 | * **强大而坚定的领导:**变革必须得到组织内发起人和日常领导者的积极支持。发起人是一名经理或业务负责人,他将倡导并授权变革。领导者应明显支持并始终如一地传达他们对变革的承诺。 | ||
436 | * **愿意且准备充分的参与者:**要想获得成功,需要有意愿的参与者做出改变。在某种程度上,这种意愿将来自参与者确信变革的重要性。此外,参与者越有准备,就越能通过相关的培训、意识和定期沟通来完成他们做出的变革,他们就越会积极前进。 | ||
437 | * **持续改进:**许多变革都失败了,是因为经过一段时间后,人们又恢复了旧的工作方式。组织变革管理旨在通过定期沟通,解决变革的任何影响和后果,以及发起人和领导者的支持,不断强化变革的价值。当使用度量来验证消息时,价值的交流将更加强大。 | ||
438 | |||
439 | |||
440 | ==== ==== | ||
441 | |||
442 | ==== **5.1.6.1 组织变革管理活动** ==== | ||
443 | |||
444 | 表5.2概述了有效组织变革管理的关键活动。 | ||
445 | |||
446 | 表5.2组织变革管理活动 | ||
447 | |||
448 | |**活动**|**有助于交付** | ||
449 | |产生紧迫感|明确相关目标,愿意参与 | ||
450 | |利害干系人管理|坚定而坚持的参与者 | ||
451 | |发起人管理|坚强而坚定的领导 | ||
452 | |通讯|愿意和有准备的参与者 | ||
453 | |赋权|准备好的参与者 | ||
454 | |抵抗管理|愿意参加的人 | ||
455 | |加强|持续的改进点 | ||
456 | |||
457 | 组织变革管理的活动与许多其他实践的活动相互作用,尤其是持续改进和项目管理。与组织变革管理有重要联系的其他实践包括度量和报告、劳动力和人才管理,以及关系管理。 | ||
458 | |||
459 | |||
460 | 必须识别受变革影响的各种受众,并定义其特征。并非所有的人都会对同样的信息做出响应,也不是所有的人都会受到同样的驱动力。在组织变革管理中,考虑文化差异尤为重要,无论这些差异是基于地理、国籍、企业历史还是其他因素。 | ||
461 | |||
462 | 与其他实践不同,组织变革管理的责任不能转移到外部供应商。组织内部的某个人必须对组织变革管理负责,即使某些或大部分组织变革管理活动的执行被委托给包括供应商在内的其他人或团体。但是,可以寻求外部的专业知识来补充组织的组织变革管理能力。有时,组织会与组织变革管理所需的关键技能相抗争,并且可以从外部供应商的支持和指导中受益。即使使用了外部帮助,整体领导支持仍必须来自组织本身。 | ||
463 | |||
464 | |||
465 | 图5.6显示了组织变革管理对服务价值链的贡献,该实践涉及所有价值链活动: | ||
466 | |||
467 | (% style="text-align:center" %) | ||
468 | [[image:1640356746002-947.png]] | ||
469 | |||
470 | 图5.6组织变革管理对价值链活动的贡献热力图 | ||
471 | |||
472 | |||
473 | * **计划:**关于项目组合级别变更的决策会导致组织变革管理的启动,以支持已批准的计划。 | ||
474 | * **改进:**如果没有适当的组织变革管理,改进就无法持续。 | ||
475 | * **契动:**组织变革管理实践在变革的各个阶段积极地与利益干系人进行契动。 | ||
476 | * **设计和转换:**组织变革管理对于部署新服务或对现有服务进行重大变更至关重要。 | ||
477 | * **获取/构建:**组织变革管理确保项目内部和项目之间的参与和合作。 | ||
478 | * **提供和支持:**组织变革管理在实时运营和支持过程中持续进行,以确保变革已被采纳并得以持续。 | ||
479 | |||
480 | |||
481 | |||
482 | === **5.1.7 组合管理** === | ||
483 | |||
484 | |||
485 | **关键信息:** | ||
486 | |||
487 | 组合管理实践的目的是确保组织具有适当的计划、项目、产品和服务组合,以在其资金和资源限制内执行组织的战略。 | ||
488 | |||
489 | |||
490 | 组合管理是战略决策的协调集合,它们共同实现了组织变革和日常业务的最有效平衡。组合管理通过以下活动实现这一目标: | ||
491 | |||
492 | * 开发和应用系统框架,定义和交付产品、服务、计划和项目的组合,以支持特定的战略和目标。 | ||
493 | * 明确定义产品和服务,并将其与达成一致的成果联系起来,从而确保服务价值链中的所有活动与价值定义和相关的CSF保持一致。 | ||
494 | * 根据资源限制,现有承诺以及组织的战略和目标,评估新产品、服务或项目建议和其他变更举措并确定优先级。 | ||
495 | * 基于对价值、成本、风险、资源限制,相互依赖性以及对现有业务活动的影响的理解,实施战略投资评估和决策流程。 | ||
496 | * 根据产品、服务、计划和项目对组织及其客户的价值,分析和跟踪投资。 | ||
497 | * 监控整个组合的绩效,并根据组织优先级的任何变化提出调整建议。 | ||
498 | * 根据进度、结果、成本、风险、收益和战略贡献方面来评审组合。 | ||
499 | |||
500 | 组合管理在整个组织中如何分配、部署和管理资源方面扮演着重要角色。这有助于将资源和能力与客户成果相结合,作为ITIL SVS中战略执行的一部分。 | ||
501 | |||
502 | |||
503 | 组合管理包含许多不同的组合,包括以下内容: | ||
504 | |||
505 | * **产品/服务组合:**产品/服务组合是由组织管理的全套产品和/或服务,它代表组织在所有客户和市场空间中的承诺和投资。它还代表了当前的合同承诺,新产品和服务开发,以及由于持续改进而启动的持续改进计划。该产品组合还可能包括第三方产品和服务,这些产品和服务是内部和外部客户产品的组成部分。 | ||
506 | * **项目组合:**项目组合用于管理和协调已授权的项目,确保在时间和成本限制内满足目标,并符合规范。项目组合还确保项目不会重复,它们保持在约定的范围内,并且每个项目都有可用的资源。它是用于管理单个项目以及多个项目组成的大型的项目工具。 | ||
507 | * **客户组合:**客户组合由组织的关系管理实践维护,为组合管理实践提供重要输入。客户组合用于记录组织的所有客户,是关系经理对从组织接收产品和/或服务的内部和外部客户的看法。 | ||
508 | |||
509 | 组合管理使用客户组合来确保业务成果、客户和服务之间的关系得到充分理解。它记录了这些联系,并通过关系管理实践与客户进行了验证。 | ||
510 | |||
511 | |||
512 | 敏捷的组合管理: | ||
513 | |||
514 | 从历史上看,衡量方案和项目成功与否的标准是:其执行工作是否按时和在预算范围内完成,以及是否实现了所需的产出、成果和效益。然而,在许多情况下,组织在一直努力证明变革带来的投资回报,人们越来越认识到,只有当方案或项目首先是实施的“正确”倡议时,才有可能取得真正的成功。敏捷组合管理将这一点做得更进一步,它更加注重战略主题的可视化,以及快速重新确定组合优先级,增加工作流程,减少批量工作以及控制长期开发队列长度的能力。 | ||
515 | |||
516 | |||
517 | 传统的组合管理侧重于自上而下的计划,其工作时间较长,但敏捷组合管理采用了敏捷团队所使用的构建-度量-学习周期的概念,并在整个组织范围内应用。团队协同工作,使用模块化设计,并共享调查结果。这就带来了极大的灵活性,从而将重点从继续执行不灵活的计划转变为提供价值并根据业务战略和目标取得切实进展。 | ||
518 | |||
519 | |||
520 | 实施敏捷组合管理的组织在整个业务中尽可能多地进行沟通。他们共享知识并打破组织竖井之间的障碍。 | ||
521 | |||
522 | |||
523 | (% style="text-align:center" %) | ||
524 | [[image:1640354274135-317.png]] | ||
525 | |||
526 | 图5.7组合管理对价值链活动的贡献热力图 | ||
527 | |||
528 | |||
529 | 图5.7显示了组合管理对服务价值链的贡献,该实践涉及所有价值链活动: | ||
530 | |||
531 | * **计划:**组合管理提供有关当前在流水线或目录中的项目、产品和服务状态的重要信息,以及它们被设计为满足哪些战略目标,这对于规划至关重要。组合管理还包括根据进度、价值创造、成本、风险、收益和战略贡献方面审查组合。 | ||
532 | * **改进:**组合管理确定了提高效率和增加协作,消除项目之间重复,识别和降低风险的机会。优先考虑改进措施,如果获得批准,可将其添加到相关组合中。 | ||
533 | * **契动:**当组织确定机会或需求时,将根据组织的战略以及风险评估和资源可用性,决定如何优先考虑这些需求或需求。 | ||
534 | * **设计和转换,获取/构建,交付和支持:**组合管理负责确保明确产品和服务得到明确定义,并将其与业务结果的实现相关联,以便这些价值链活动与价值保持一致。 | ||
535 | |||
536 | |||
537 | |||
538 | === **5.1.8 项目管理** === | ||
539 | |||
540 | |||
541 | **关键信息:** | ||
542 | |||
543 | 项目管理实践的目的是确保组织中的所有项目都能成功交付。这是通过计划、委派、监控和维护对项目所有方面的控制,并保持相关人员的积极性来实现的。 | ||
544 | |||
545 | |||
546 | 项目是对组织进行重大变更的手段之一,可以将其定义为临时结构,其目的是根据约定的商业案例,为交付一个或多个输出(或产品)而创建。它们可能是一个独立的计划,也可能是更大计划的一部分,与其他相互关联的项目一起,以实现更复杂的转型。然而,即使是独立项目,也应该在组织的项目组合中加以考虑。 | ||
547 | |||
548 | |||
549 | 项目的交付方式有不同的方法,瀑布和敏捷方法是最常见的: | ||
550 | |||
551 | * 瀑布方法适用于需求预先知道(并且不太可能发生重大变化)的环境,以及工作定义比交付速度更重要的环境。 | ||
552 | * 敏捷方法在需求不确定且可能随着时间的推移而快速发展(例如,随着业务需求和优先级发生变化)以及交付速度通常优先于精确需求的定义时,效果最佳。 | ||
553 | |||
554 | 成功的项目管理很重要,因为组织必须平衡其需求: | ||
555 | |||
556 | * 有效且高效地维护当前的业务运营 | ||
557 | * 转变业务运营,以改变、生存和在市场中竞争 | ||
558 | * 持续改进其产品和服务。 | ||
559 | |||
560 | 项目与“一切照旧”之间的这种平衡可能会影响许多领域,包括资源(人员、资产、财务)、服务级别、客户关系和生产力,因此必须将组织的容量和能力视为其项目管理方法的一部分。 | ||
561 | |||
562 | |||
563 | 项目取决于项目团队和整个组织内人员的行为。如果没有合适的人在合适的时间参与,那么最好的项目计划也是微不足道。还需要考虑项目与组织之间的关系,因为许多项目团队成员将从业务运营中借调来全职或兼职。 | ||
564 | |||
565 | |||
566 | 图5.8显示了项目管理对服务价值链的贡献,实践涉及所有价值链活动: | ||
567 | |||
568 | * **计划:**项目管理通过方法和工具支持战略和战术计划。 | ||
569 | * **改进:**许多改进措施庞大而复杂,因此项目管理是管理它们的相关实践。 | ||
570 | * **契动:**利益干系人参与是成功交付任何项目的关键因素。项目管理为组织提供利益干系人管理工具和技术。 | ||
571 | * **设计和转换:**实践或服务的设计可以作为项目或大型项目中的迭代进行管理;这同样适用于某些转换。 | ||
572 | * **获取/构建:**获取新资源以及开发和集成通常作为项目执行。各种项目管理技术适用于此活动。 | ||
573 | * **交付和支持:**设计、转换和移交给内部或外部服务消费者以进行运营管理的过程,需要妥善的计划和执行,以确保正常的业务不受损害。项目管理实践确保了这一点。 | ||
574 | |||
575 | (% style="text-align:center" %) | ||
576 | [[image:1640354319996-161.png]] | ||
577 | |||
578 | 图5.8项目管理对价值链活动的贡献热力图 | ||
579 | |||
580 | |||
581 | === **5.1.9 关系管理** === | ||
582 | |||
583 | |||
584 | **关键信息:** | ||
585 | |||
586 | 关系管理实践的目的是在战略和战术层面建立和培育组织与其利益干系人之间的联系。它包括识别、分析、监控和持续改进与利益干系人之间的关系。 | ||
587 | |||
588 | |||
589 | 关系管理实践确保: | ||
590 | |||
591 | * 理解利益干系人的需求和驱动因素,并对产品和服务进行适当的优先排序 | ||
592 | * 利益干系人的满意度很高,并在组织与利益干系人之间建立和维护建设性关系 | ||
593 | * 根据预期的业务结果,有效地建立和阐明客户对新的或变更的产品和服务的优先级 | ||
594 | * 任何利益干系人的投诉和升级都能通过一个同情的(但正式的)流程得到妥善处理 | ||
595 | * 产品和服务有助于为服务消费者和组织创造价值 | ||
596 | * 组织根据其战略和优先级,为所有利益干系人的创造价值 | ||
597 | * 利益干系人需求之间的冲突会得到适当调解。 | ||
598 | |||
599 | 服务提供者很自然地将大部分精力集中在他们与服务消费者(赞助商、客户和用户)的关系上。这是一个非常重要的利益干系人群体;但是,组织应确保他们理解和管理与内部和外部各利益干系人的关系。关系管理实践应适用于所有相关方。这意味着该实践有助于所有服务价值链活动和多个价值流。 | ||
600 | |||
601 | |||
602 | 图5.9显示了关系管理对服务价值链的贡献,实践涉及所有价值链活动: | ||
603 | |||
604 | * **计划:**关系管理提供有关内部和外部客户的要求和期望的信息。它还协助对投资组合进行战略评估和优先排序,并评估当前和未来的市场空间,这是计划的重要方面。 | ||
605 | * **改进:**关系管理旨在通过持续改进,协调和协同与内部和外部客户的不同组织关系,实现目标利益。 | ||
606 | * **契动:**关系管理是负责与内部和外部客户交流,以了解其要求和优先级的实践。 | ||
607 | * **设计和转换:**关系管理作为设计的一部分,在协调内部和外部客户的反馈方面发挥着关键作用。它还确保避免或尽量减少过渡期间对客户造成的不便和不利影响。 | ||
608 | * **获取/构建:**关系管理提供客户要求和优先级,以帮助选择要获取或构建的产品,服务或服务组件。 | ||
609 | * **交付和支持:**关系管理负责确保在组织与客户之间建立和维护高水平的客户满意度和建设性关系。 | ||
610 | |||
611 | (% style="text-align:center" %) | ||
612 | [[image:1640354356604-339.png]] | ||
613 | |||
614 | 图5.9关系管理对价值链活动的贡献热力图 | ||
615 | |||
616 | |||
617 | === **5.1.10 风险管理** === | ||
618 | |||
619 | |||
620 | **关键信息:** | ||
621 | |||
622 | 风险管理实践的目的是确保组织理解并有效地处理风险。管理风险对于确保组织的仍在进行的可持续性和为客户创造价值至关重要。风险管理是所有组织活动的组成部分,因此是组织SVS的核心(有关风险的定义,请参阅第2.5.3节)。 | ||
623 | |||
624 | |||
625 | 风险通常被视为需要避免的东西,因为它与威胁有关,虽然这通常是正确的,但风险也与机会有关。不能抓住机会本身就是一种风险。服务不足的市场空间和未满足的需求的机会成本是需要避免的风险。 | ||
626 | |||
627 | |||
628 | 组织的组合可以映射到要管理的基础风险组合。当服务管理有效时,服务目录和管道中的产品和服务代表了为客户、组织和其他利益干系人创造和获取价值的机会。否则,这些产品和服务可能会带来威胁,因为失败的可能性与它们吸引的需求模式、它们需要的承诺以及它们产生的成本有关。实施策略通常需要变更产品和服务组合,这意味着要管理相关的风险。 | ||
629 | |||
630 | |||
631 | 需要平衡有关风险的决策,以便潜在的利益对组织的价值高于解决风险的成本。例如,创新本质上具有风险,但可以在改进产品和服务,获得竞争优势以及提高灵活性和弹性方面带来重大好处。组织限制其风险暴露的能力也具有相关性。目标应该是对特定情况下的风险进行准确评估,并分析潜在的收益。应确定每个行动方案所呈现的风险和机会,以确定适当的应对措施。 | ||
632 | |||
633 | |||
634 | 要使风险管理有效,风险必须是: | ||
635 | |||
636 | * **确定:**在特定组织活动中,会影响目标实现的不确定性。必须考虑这些不确定性,然后进行描述,以确保达成共识。 | ||
637 | * **评估:**必须对个别风险的概率、影响和接近程度进行评估,以便对其进行优先排序,并了解与组织活动相关的整体风险水平(风险暴露)。 | ||
638 | * **控制:**必须计划适当的风险应对措施,分配所有者和行动者,然后实施、监控和控制。 | ||
639 | |||
640 | 以下原则特别适用于风险管理实践: | ||
641 | |||
642 | * **风险是业务的一部分:**组织应确保妥善管理风险。这并不意味着要避免所有风险。相反,为了确保长期可持续性,需要承担风险。然而,需要根据组织愿意承担的风险水平(即风险偏好)来识别、理解和评估风险,并进行适当的管理和监控。 | ||
643 | * **整个组织的风险管理必须保持一致:**风险管理实践必须全面管理,以实现整个组织的一致性。为确保有效性,应与利益干系人进行持续协商,并为组织的不同部门提供适当的灵活性。这种灵活性将允许开发定制的风险管理规程,以便解决组织单位和/或客户特定情况。 | ||
644 | * **风险管理文化和行为很重要:**组织各级人员展示的适当文化和行为至关重要,必须作为“我们做事方式”的一部分。这将通过行为和信念得到证明,例如: | ||
645 | ** 理解有效的风险管理对组织的可持续性至关重要,并支持实现业务目标 | ||
646 | ** 采取主动风险管理行为 | ||
647 | ** 确保风险管理规程、角色、职责和责任的透明度和清晰度 | ||
648 | ** 积极鼓励并跟进风险、事件和机会的报告 | ||
649 | ** 确保薪酬结构支持期望的行为(即,这不应阻止事件报告,也不应鼓励过度报告) | ||
650 | ** 积极鼓励从组织和其他组织的经验中学习和成长。 | ||
651 | |||
652 | (% class="box" %) | ||
653 | ((( | ||
654 | **ISO 31000:2018风险管理:** | ||
655 | |||
656 | 这些指导原则提供了风险管理目的和原则的总体和一般观点。它们适用于任何类型的组织中的所有级别。ISO 31000规定“风险管理的目的是创造和保护价值”,风险管理“提高绩效,鼓励创新并支持实现目标”。 | ||
657 | ))) | ||
658 | |||
659 | |||
660 | (% style="text-align:center" %) | ||
661 | [[image:1640354395530-179.png]] | ||
662 | |||
663 | 图5.10风险管理对价值链活动的贡献热力图 | ||
664 | |||
665 | |||
666 | 图5.10显示了风险管理对服务价值链的贡献,该实践涉及所有价值链活动: | ||
667 | |||
668 | * **计划:**风险管理为组织的战略和规划提供必要的输入,重点关注可以推动结果变化的风险。这些包括: | ||
669 | ** 转变客户需求和优先事项 | ||
670 | ** 法律和监管方面的变化 | ||
671 | ** 竞争对手 | ||
672 | ** 对供应商和合作伙伴的依赖 | ||
673 | ** 技术变革 | ||
674 | ** 利益干系人要求相互冲突 | ||
675 | * **改进:**所有改进措施应由风险管理部门进行评估和持续控制。该实践为改进优先级划分,计划和评估建立了重要的视角。 | ||
676 | * **契动:**风险管理实践有助于识别关键利益干系人,并根据风险偏好和风险概况等信息优化契动。 | ||
677 | * **设计和转换:**产品和服务设计应当优先考虑风险。例如,它们应该是可扩展的,以支持随时间变化的需求。对于组织而言,新的或变更的服务具有不同级别的风险,应在变更批准之前进行识别和评估。如果获得批准,则应将风险作为变更的一部分进行管理,包括发布、部署和项目。 | ||
678 | * **获取/构建:**风险管理应告知有关获取或构建产品、服务或服务组件的决策。 | ||
679 | * **交付和支持:**风险管理有助于确保持续交付的产品和服务保持在约定的水平,并确保所有事件都根据其引入的风险进行管理。 | ||
680 | |||
681 | |||
682 | |||
683 | === **5.1.11 服务财务管理** === | ||
684 | |||
685 | |||
686 | **关键信息:** | ||
687 | |||
688 | 服务财务管理实践的目的是通过确保有效利用组织的财务资源和投资,来支持组织的服务管理战略和计划。 | ||
689 | |||
690 | |||
691 | 服务财务管理支持理事机构和组织管理层决策,以便最佳地分配财务资源。它提供了与产品和服务相关的预算、成本和核算活动的可视性。为了在SVS的环境中有效,该实践需要与组织的组合管理、项目管理和关系管理的策略和实践保持一致。 | ||
692 | |||
693 | |||
694 | 财务是使组织与其利益干系人进行有效沟通的通用语言。服务财务管理负责管理组织活动的预算、成本、核算和计费,同时充当服务提供者和服务消费者: | ||
695 | |||
696 | * **预算/成本:**这是一项专注于预测和控制组织内资金收入和支出的活动。预算编制包括确定预算的定期谈判周期和对当前预算的持续监控。为实现这一目标,它侧重于捕获预测和实际的服务需求。它将这一需求转化为用于设定预算和费率的预期运营和项目成本,以确保为产品和服务提供充足的资金。基于服务的预算编制旨在理解预算,并根据提供或使用服务的全部成本建立资金模型。 | ||
697 | * **核算:**此活动使组织能够充分考虑其资金支出的方式,使其能够比较预测与实际成本和支出(特别是通过客户,服务和活动/成本中心识别使用和成本的能力)。它通常涉及核算系统,包括分类账、会计科目表和日记账。 | ||
698 | * **计费:**此活动向服务消费者(通常是外部)提供的服务开具正式的发票。值得注意的是,尽管收费是一种可选做法,但所有服务都需要一种融资模式,因为所有成本都需要通过商定的方法获得充足的资金。 | ||
699 | |||
700 | 图5.11显示了服务财务管理对服务价值链的贡献,实践涉及所有价值链活动: | ||
701 | |||
702 | * **计划:**各级计划都需要基于信息(包括财务)的资金。服务财务管理支持使用预算、报告、预测和其他相关信息进行规划。 | ||
703 | * **改进:**所有改进都应优先考虑投资回报率。服务财务管理为改进评价和优先级提供工具和信息。 | ||
704 | * **契动:**财务考虑对于与服务消费者、供应商和合作伙伴建立和维护服务关系是非常重要的。对于一些利益干系人(投资者,赞助者)而言,财务方面的关系是最重要的。该实践通过提供财务信息来支持这一价值链活动。 | ||
705 | * **设计和转换:**服务财务管理通过提供财务计划和控制手段,有助于保持此活动的成本效益。它还确保了服务提供者的产品和服务成本的透明度,核算设计和转换花费的支出。 | ||
706 | * **获得/建立:**获得所有类型的资源得到预算支持(以确保充足的资金)和核算(以确保透明度和评估)。 | ||
707 | * **交付和支持:**持续的运营成本是组织支出的重要组成部分。对于商业组织而言,持续的服务提供活动也是收入来源。服务财务管理有助于确保对两者的充分理解。计费(如果适用)支持服务提供者和服务消费者与计费和报告的关系。 | ||
708 | |||
709 | (% style="text-align:center" %) | ||
710 | [[image:1640354473222-677.png]] | ||
711 | |||
712 | 图5.11服务财务管理对价值链活动的贡献热力图 | ||
713 | |||
714 | |||
715 | (% class="box" %) | ||
716 | ((( | ||
717 | **用新技术进行财务管理的演变:** | ||
718 | |||
719 | 财务管理是指以最合适的方式有效和高效地管理货币,以实现组织的财务目标。自成立以来,财务管理学科经历了不同程度的变革、改进和创新。这一变化的关键部分是新技术的出现。许多技术发展都对财务管理产生了影响,但三项关键的创新是引入了更多的数字技术、区块链、IT预算和支付模式。 | ||
720 | |||
721 | |||
722 | **数字技术** | ||
723 | |||
724 | 大型金融机构现在正在分析和使用诸如云、**大数据**、分析和人工智能(AI)等最新技术,或者仅仅是为了在市场上保持竞争优势。然而,新的金融组织也在使用这些技术,并在没有任何遗留IT、**技术债务**或官僚流程下开始运营,这意味着他们更敏捷。 | ||
725 | |||
726 | |||
727 | 金融机构正在使用大数据和分析来深入洞悉并理解其客户。捕获的数据量非常大,需要可扩展的计算能力来有效且经济高效地处理数据。作为回报,这种更深入的客户理解正在促使金融机构开发新的创新产品和服务。数据现在被称为“新石油”,因为组织正忙于捕获,分析和利用它。 | ||
728 | |||
729 | |||
730 | **区块链** | ||
731 | |||
732 | 财务管理的另一个发展是通过一种称为区块链的特定创新来实现,同样只能通过基于云的服务来实现。最初开发区块链是为了实现加密货币的分散管理,允许自动且廉价地审计和验证**交易**。 | ||
733 | |||
734 | |||
735 | 区块链技术用于管理公共数字分类账。这些数字分类账记录了许多全球分布式计算机的交易。记录的分发确保在不变更所有后续记录(也称为块)且没有整个分布式分类帐(也称为网络)的共识的情况下,不能变更每条记录。 | ||
736 | |||
737 | |||
738 | 全球金融机构正在研究这种区块链技术如何通过简化后台职能和降低银行交易的结算率来为他们提供竞争优势。新的金融机构正在研究区块链以提供替代银行业务,而其成本和管理费用仅为传统银行的一小部分。 | ||
739 | |||
740 | |||
741 | **IT预算和支付模式** | ||
742 | |||
743 | 新技术的出现不仅影响了金融组织,也影响了每个组织从财务角度管理其IT服务的方式。云计算已经实现了当前技术发展的大部分浪潮,在可预见的未来,这种趋势可能还会持续。这导致组织获得、资助和支付IT服务的方式发生了重大变化。 | ||
744 | |||
745 | |||
746 | 传统上,IT资源是使用前期资本支出(CAPEX)获得的。但是,在云模型下,IT基础设施、平台和软件的提供是“即服务”。此模型通常使用基于订阅或按使用付费的收费机制,这些收费机制是在运营支出(OPEX)之外支付的。 | ||
747 | |||
748 | |||
749 | 另一个发生变化的领域是组织设置和管理IT预算的方法。需要灵活的IT预算来满足扩展敏捷中基于云的服务的成本和按需方式。固定的IT预算(通常提前几个月进行预测)就很难以这种方式考虑IT资源的扩展问题。 | ||
750 | |||
751 | |||
752 | 组织内的采购规则也必须改变。还有固定价格的IT项目和服务;然而,基于云的数字服务通常以可变价格模式出售,即您使用和消费的越多,您支付的越多,反之亦然。因此,那些尚未更新采购规则以允许他们购买可变价格IT资源的组织将面临一个大的自制障碍,阻碍他们使用基于云的数字服务。为了尽可能有效,组织必须更新其策略并教育其员工,以确保他们可以在可变价格模型下购买IT。 | ||
753 | ))) | ||
754 | |||
755 | |||
756 | |||
757 | === **5.1.12 战略管理** === | ||
758 | |||
759 | |||
760 | **关键信息:** | ||
761 | |||
762 | 战略管理实践的目的是制定组织的目标,并采取行动和配置必要的资源来实现这些目标。战略管理确定组织的方向,集中精力,定义或阐明组织的优先级,并提供响应环境的一致性或指导。 | ||
763 | |||
764 | |||
765 | 战略管理的出发点是理解组织的背景,并定义期望的成果。该组织的战略建立了标准和机制,有助于决定如何最好地确定资源、能力和投资的优先次序,以实现这些结果,同时该实践可确保战略的定义、约定、维护和实现。 | ||
766 | |||
767 | |||
768 | 战略管理的目标是: | ||
769 | |||
770 | * 分析组织所处的环境,以识别有利于组织的机会 | ||
771 | * 确定可能阻碍业务成果实现的约束,并定义如何消除这些约束或减少其影响 | ||
772 | * 与相关利益干系人决定并同意组织的观点和方向,包括其愿景、使命和原则 | ||
773 | * 确定组织相对于客户和竞争对手的观点和立场。这包括确定将哪些服务和产品交付到哪个市场空间,以及如何保持竞争优势 | ||
774 | * 确保战略已转化为每个组织单位的战术和行动计划,以便交付战略 | ||
775 | * 确保通过战略计划的执行以及战略、战术和运营层面努力的协调来实施战略 | ||
776 | * 管理战略和相关文件的变更,确保战略与内外部环境及其他相关因素的变化保持同步 | ||
777 | |||
778 | 战略管理通常被视为组织的高级管理层和理事机构的责任。它使他们能够设定组织的目标,指定组织如何实现这些目标,并确定实现这些目标所需的投资的优先次序。然而,在当今复杂、瞬息万变的环境中,基于仔细考虑、广泛研究和情景规划的传统战略实践也在不断发展。战略变得越来越灵活,人们越来越注重建立组织的基本目的和原则,即使情况发生变化,也可以作为其所有行动的指导方向。例如,精益战略流程可用于平衡严格的计划和不受控制的实验的极端情况。该战略提供了组织的总体方向和一致性,既是创新思想必须通过的屏障,也是评价SVS成功的基础。它鼓励员工发挥创造力,同时确保他们与组织和谐相处,只追求有价值的机会。 | ||
779 | |||
780 | |||
781 | 战略必须为组织创造价值。良好的商业模式描述了实现组织目标的方法。组织的战略应该包括使其服务和产品对客户具有独特的价值方法;因此,它必须定义组织交付更好价值的方法。对战略的需要,不仅仅限于大型组织;对于小型企业来说,这一点同样重要,使他们有一个清晰的视角、定位和计划,以确保它们与客户保持相关性。 | ||
782 | |||
783 | 客户希望解决方案能够突破性能障碍,并在很少或不增加成本的情况下,实现更高质量的成果。这些解决方案通常通过创新产品和服务提供。该战略应平衡组织交付高效和有效运行的需求与创新和面向未来的活动。 | ||
784 | |||
785 | |||
786 | 从客户或组织的角度来看,产品和服务的价值可能会随着时间的推移而改变,因为条件、事件或组织控制范围之外的其他因素。战略管理确保对组织与客户的关系进行仔细考虑,以及在处理定义这些关系的价值变化时的敏捷性和弹性。 | ||
787 | |||
788 | |||
789 | 高绩效战略可以使组织在整个业务周期,行业中断期间,以及领导层发生变化时,始终如一地超越竞争对手。它应该关注整个组织需要做些什么来促进价值创造。 | ||
790 | |||
791 | |||
792 | 图5.12显示了战略管理对服务价值链的贡献,实践涉及所有价值链活动: | ||
793 | |||
794 | * **计划:**战略管理确保将组织的战略转化为预期将在战略上实现的每个组织单位的战术和运营计划。 | ||
795 | * **改进:**战略管理提供了用于确定优先级和评估改进的策略和目标。 | ||
796 | * **契动:**当机会或需求被组织识别出来时,关于如何确定优先级的决策是基于组织的战略以及风险评估和资源可用性。 | ||
797 | * **设计和转换,获取/构建,交付和支持:**战略管理通过战略计划的执行与这些活动的协调,来确保战略的实施。它还提供反馈,以便在设计和转换期间对产品和服务进行度量和评价。 | ||
798 | |||
799 | (% style="text-align:center" %) | ||
800 | [[image:1640354558607-828.png]] | ||
801 | |||
802 | |||
803 | 图5.12 策略管理对价值链活动的贡献热力图 | ||
804 | |||
805 | |||
806 | === **5.1.13 供应商管理** === | ||
807 | |||
808 | |||
809 | **关键信息:** | ||
810 | |||
811 | 供应商管理实践的目的是确保组织的供应商及其绩效得到适当的管理,以支持优质产品和服务的无缝提供。这包括与主要供应商建立更密切、更具协作性的关系,以发现和实现新价值,并降低失败风险。 | ||
812 | |||
813 | |||
814 | 这种实践的核心活动包括: | ||
815 | |||
816 | * **创建单一可见性和控制点,以确保一致性** 这应该适用于内部和外部供应商(包括作为供应商的客户)提供或运营的所有产品、服务、服务组件和程序。 | ||
817 | * **维护供应商战略、策略和合同管理信息** | ||
818 | * **协商与约定合同和安排** 协议需要与业务需求和服务目标保持一致。与外部供应商的合同可能需要通过组织的法律、采购、商业或合同职能进行谈判或达成一致。对于内部供应商,需要有内部协议。 | ||
819 | * **管理与内部和外部供应商的关系和合同** 在规划、设计、构建、协调、转换和运营产品和服务时,应与采购和绩效管理密切合作。 | ||
820 | * **管理供应商绩效** 应监控供应商绩效,以确保其符合合同和协议的条款、条件和目标,同时旨在提高从供应商及其提供的产品/服务中获得的资金价值。 | ||
821 | |||
822 | |||
823 | |||
824 | ==== **5.1.13.1 采购,供应商战略和关系** ==== | ||
825 | |||
826 | 供应商战略(有时被称为采购战略)定义了组织如何利用供应商的贡献来实现其整体服务管理战略的计划。 | ||
827 | |||
828 | |||
829 | 有些组织可能采取一种策略,规定只在非常具体和有限的情况下使用供应商,而另一个组织可能会选择在产品和服务提供时广泛使用供应商。成功的采购战略需要彻底理解组织的目标将会、交付该战略所需的资源、环境(例如市场)因素以及与实施特定方法相关的风险。 | ||
830 | |||
831 | |||
832 | 组织与其供应商之间存在不同类型的供应商关系,需要将其视为组织采购战略的一部分。这些包括: | ||
833 | |||
834 | * **内包** 产品或服务由组织内部开发和/或交付。 | ||
835 | * **外包** 外部供应商提供以前在内部提供的产品和服务的过程。外包涉及替代,即用供应商替代内部能力。 | ||
836 | * **单一来源或合作伙伴** 从一个供应商处采购产品或服务。这可以是直接提供所有服务的单一供应商,也可以是管理与所有供应商的关系并代表组织集成其服务的外部服务集成商。这些密切的关系(以及它们创造的相互依赖关系)促进了高质量、可靠性、短交付周期和合作行动。 | ||
837 | * **多源采购** 来自多个独立供应商的产品或服务。这些产品和服务可以组合在一起形成组织可以为内部和外部客户提供的新服务。随着组织将更多的注意力放在提高敏捷性的专业化和功能划分上,多源采购越来越成为首选。传统上,组织已经在组织的不同部分单独管理这些供应商,但现在有了开发内部服务集成功能或选择外部服务集成商的趋势。 | ||
838 | |||
839 | 个体供应商可以提供支持服务和产品,这些服务和产品在价值创造中独立地具有相对较小且相当间接的作用,但是共同为此和组织战略的实施做出更直接和重要的贡献。 | ||
840 | |||
841 | |||
842 | ==== **5.1.13.2 供应商的评价和选择** ==== | ||
843 | |||
844 | 组织应根据以下内容评价和选择供应商: | ||
845 | |||
846 | * 供应商提供的服务对企业价值的重要性和影响 | ||
847 | * 风险与使用服务相关的风险 | ||
848 | * 服务及其提供的成本。 | ||
849 | |||
850 | 评价和选择供应商的其他重要因素包括供应商定制产品的意愿或可行性,或在多供应商环境下的合作;组织或服务集成商对供应商绩效的影响程度;以及一个供应商对其他供应商的依赖程度。 | ||
851 | |||
852 | |||
853 | ==== **5.1.13.3 活动** ==== | ||
854 | |||
855 | 供应商管理实践的活动包括: | ||
856 | |||
857 | * **供应商计划:**此活动的目的是理解新的或变更的服务需求,并审查相关的企业文档,以制定采购战略和供应商管理计划,并结合其他实践相结合,如业务分析、组合管理、服务设计、服务级别管理。 | ||
858 | * **供应商和合同的评价:**此活动的目的是识别、评价和选择供应商,以交付新的或变更的业务服务。 | ||
859 | * **供应商和合同谈判:**此活动的目的是制定、协商、审查、更新,最终确定和授予供应商合同。谈判失败将触发新合同,更新合同或合同终止。 | ||
860 | * **供应商分类:**此规程旨在定期对供应商进行分类,并在颁发新的或更新的合同后进行分类。常用类别包括战略、战术和商品供应商。 | ||
861 | * **供应商和合同管理:**该活动的目的是确保组织获得物有所值,并根据合同和目标交付供应商的约定绩效。 | ||
862 | * **功效管理:**此活动的目的是管理功效要求或条款,并在出现功效问题时提供功效索赔,并与绩效管理相结合。 | ||
863 | * **绩效管理:**此活动包括建立和持续跟踪与内部和外部供应商共同约定的运行措施。它侧重于关键度量,然后可以在供应商记分卡上进行整合。监测将有助于查明系统性问题和改进机会,并为报告提供依据。 | ||
864 | * **合同续签和/或终止:**此程序旨在管理合同续订和终止,这是由供应商绩效的特定或定期审查触发的。 | ||
865 | |||
866 | |||
867 | |||
868 | ==== **5.1.13.4 服务集成** ==== | ||
869 | |||
870 | 服务集成负责合作或协调所有涉及产品和服务的开发和交付的供应商。它侧重于端到端的服务提供,确保对供应商的所有接口和成果进行控制,并促进供应商之间的协作。组织可以自己扮演服务集成商的角色,也可以使用第三方服务集成商。可以开发混合模型,其中组织负责某些服务集成功能,并使用外部服务集成商来增强该功能。服务集成功能也可由主要供应商操作。服务集成商也负责保证;这包括绩效管理和报告,定义角色和职责,维护各方之间的关系,领导定期论坛和指导委员会来解决问题,约定优先事项和做出决策。 | ||
871 | |||
872 | (% style="text-align:center" %) | ||
873 | [[image:1640354612519-904.png]] | ||
874 | |||
875 | 图5.13供应商管理对价值链活动的贡献热力图 | ||
876 | |||
877 | |||
878 | 图5.13显示了供应商管理对服务价值链的贡献,实践涉及所有价值链活动: | ||
879 | |||
880 | * **计划:**供应商管理提供组织批准的采购战略和计划。 | ||
881 | * **改进:**该实践识别现有供应商的改进机会,驱动新供应商的选择,并提供持续的供应商绩效管理。 | ||
882 | * **契动:**供应商管理层负责与所有供应商合作,并评估和选择供应商;谈判和同意合同和协议;并持续管理供应商关系。 | ||
883 | * **设计和转换:**供应商管理负责根据组织的需求和服务目标,确定与新的或变更的产品或服务相关的合同和协议的要求。 | ||
884 | * **获取/构建:**供应商管理支持从第三方采购或获取产品、服务和服务组件。 | ||
885 | * **交付和支持:**通过此实践管理实时服务的供应商绩效,以确保供应商满足其合同和协议的条款、条件和目标。 | ||
886 | |||
887 | |||
888 | |||
889 | **ITIL的故事:艾克苏的供应商管理** | ||
890 | |||
891 | **马可:**我被分配到艾克苏的供应商管理经理岗位。这意味着我将与供应商一起管理月度治理论坛,以跟踪其服务级别协议中列出的服务绩效。我将确保供应商的合同义务符合艾克苏汽车租赁的业务结果。 | ||
892 | |||
893 | **拉迪卡:**例如,我们向客户承诺汽车将始终保持清洁。我们曾经每周清洗一次汽车,但为了满足新的服务承诺,克雷格保洁将在每次返回汽车时清洁汽车。 | ||
894 | |||
895 | **亨利:**艾克苏的服务取决于多个合作伙伴和供应商。我们与汽车经销商和制造商、轮胎制造商、清洁工和路边救援机构合作。我们还拥有推广我们产品的艾克苏代理商,以及忠诚度计划中的合作伙伴,他们以特殊条款为我们的客户提供服务。 | ||
896 | |||
897 | **拉迪卡:**我们也为我们的IT系统使用了许多合作伙伴和供应商的服务。这支持了艾克苏在互联网访问和软件开发等多个层面的工作。 | ||
898 | |||
899 | **马可:**艾克苏的数字化意味着更多机会将IT融入我们的服务产品中。艾克苏应用程序可以通过个人设备预订和支付租车费用。Axle Aware系统安装在每辆车上,并得到IT和我们的合作伙伴的支持。车队维护计划基于我们车辆的租用历史,并由我们的IT系统控制。 | ||
900 | |||
901 | **亨利:**正因为如此,艾克苏的业务现在严重依赖IT和非IT供应商。集成和协调这些服务是供应商管理的一部分。我们希望供应商为艾克苏和我们的客户提供始终如一的质量水平。 | ||
902 | |||
903 | |||
904 | === **5.1.14 劳动力和人才管理** === | ||
905 | |||
906 | |||
907 | **关键信息:** | ||
908 | |||
909 | 劳动力和人才管理实践的目的是确保组织拥有具备适当技能和知识的正确人员,并以正确的角色支持其业务目标。该实践涵盖了一系列广泛的活动,重点是成功地与组织的员工和人力资源合作,包括规划、招聘、入职、学习和发展、绩效评估和继任计划。 | ||
910 | |||
911 | |||
912 | 通过帮助组织主动了解和预测未来的服务需求,劳动力和人才管理在建立组织速度方面发挥着关键作用。它还确保在合适的时间提供具备必要能力的合适人员,以提供所需的服务。 | ||
913 | |||
914 | |||
915 | 实现这一目标可以减少积压,提高质量,避免因缺陷造成的返工,减少等待时间,同时缩小知识和技能差距。随着组织转变其实践,自动化和组织能力以支持数字经济并加快产品上市速度,拥有合适的人才变得至关重要。 | ||
916 | |||
917 | |||
918 | 员工和人才管理使组织、领导者和管理人员能够专注于创建有效且可操作的人员战略,并在组织内的各个层面执行该战略。一个好的策略应该支持识别角色和相关知识,以及保持组织日常运作所需的技能和态度。它还应该解决为组织未来发展定位所需的新兴技术,领导力和组织变革能力。 | ||
919 | |||
920 | |||
921 | 管理和发展组织的员工和人才的想法并不新鲜。然而,随着第三方供应商的使用增加,以及可重复工作的自动化的迅速普及,传统角色正在发生巨大变化。因此,员工和人才管理应该是整个组织各个层面的领导者和管理者的责任。 | ||
922 | |||
923 | |||
924 | **定义**: | ||
925 | |||
926 | * **组织速率** 在组织运作的速率,有效性和效率。组织运作影响上市时间,质量,安全性,成本和风险。 | ||
927 | * **胜任力(Competencies)** 结合可观察和可衡量的知识、技能、能力和态度,有助于提高员工绩效并最终实现组织成功。 | ||
928 | * **技能(Skills)** 在思想、口头交流或身体动作方面的熟练程度或灵活性。 | ||
929 | * **能力(Ability)** 执行与职业或行业相关的身体或心理活动的能力或能力。 | ||
930 | * **知识**对通过经验或教育获得的事实或信息的理解;对某一主题的理论或实践的理解。 | ||
931 | * **态度** 针对特定对象、人物、事物或事件的一组情绪、信念和行为。 | ||
932 | |||
933 | |||
934 | |||
935 | ==== **5.1.14.1 劳动力与人才管理活动** ==== | ||
936 | |||
937 | 此实践的活动涉及领域广泛,并由特定目的的各种角色履行,包括: | ||
938 | |||
939 | * **劳动力规划:**将组织的战略和目标转化为所需的组织能力,然后转化为能力和角色。 | ||
940 | * **招聘:**获得新员工和承包商,以填补与所需能力相关的已识别差距。 | ||
941 | * **绩效评估:**根据预定义的能力,对既定的工作角色提供定期绩效度量和评估。 | ||
942 | * **个人发展:**员工利用已发布的工作角色和能力框架,主动规划个人成长和进步。 | ||
943 | * **学习和发展:**采用各种正式和非正式方法,进行有针对性的教育和体验式学习机会。 | ||
944 | * **指导和继任计划:**由领导层提供的正式指导、契动和继任计划活动。 | ||
945 | |||
946 | 图5.14 显示劳动力和人才管理的活动。 | ||
947 | |||
948 | |||
949 | (% style="text-align:center" %) | ||
950 | [[image:1640354667081-129.png]] | ||
951 | |||
952 | 图5.14 劳动力和人才管理活动 | ||
953 | |||
954 | |||
955 | 图5.15显示了劳动力和人才管理对服务价值链的贡献,此实践涉及所有价值链活动;但是,它是计划和改进活动的主要重点: | ||
956 | |||
957 | * **计划:**劳动力计划是此价值链活动的具体输出,因为领导层和管理层根据组织资源的未来需求以及服务组合中定义的产品和服务,评估其当前的组织能力。 | ||
958 | * **改进:**所有改进都需要有足够技能且有积极性的人才。劳动力和人才管理实践确保理解和满足这些要求。 | ||
959 | * **契动:**劳动力和人才管理与此价值链活动密切相关。它与关系管理、服务请求管理和服务台等实践协同工作,以理解和预测不断变化的服务需求,以及这将如何影响和指导劳动力规划和人才管理活动。 | ||
960 | * **设计和转换:**人才管理对于此价值链活动非常重要。特别关注与系统和设计思维相关的知识、技能和能力。 | ||
961 | * **获取/构建:**人才管理特别关注与协作、客户关注、质量、速度和成本管理相关的知识、技能和能力。 | ||
962 | * **提供和支持:**人才管理特别关注与客户服务、绩效管理、客户互动和关系相关的知识、技能和能力。 | ||
963 | |||
964 | (% style="text-align:center" %) | ||
965 | [[image:1640354689131-692.png]] | ||
966 | |||
967 | 图5.15劳动力和人才管理对价值链活动的贡献热力图 | ||
968 | |||
969 | |||
970 | |||
971 | |||
972 | == **5.2 服务管理实践** == | ||
973 | |||
974 | |||
975 | === **5.2.1 可用性管理** === | ||
976 | |||
977 | |||
978 | **关键信息:** | ||
979 | |||
980 | 可用性管理实践的目的是确保服务交付承诺的可用性级别,以满足客户和用户的需求。 | ||
981 | |||
982 | |||
983 | **定义:可用性** | ||
984 | |||
985 | IT服务或其他配置项在需要时执行其约定功能的能力。 | ||
986 | |||
987 | |||
988 | 可用性管理活动包括: | ||
989 | |||
990 | * 谈判并约定可实现的可用性目标 | ||
991 | * 设计可提供所需可用性级别的基础架构和应用程序 | ||
992 | * 确保服务和组件能够收集衡量可用性所需的数据 | ||
993 | * 监控、分析和报告可用性 | ||
994 | * 规划可用性的改进。 | ||
995 | |||
996 | 用最简单的术语来说,服务的可用性取决于服务失败的频率以及失败后恢复的速度。这些通常表示为平均故障间隔时间(MTBF)和平均恢复服务时间(MTRS): | ||
997 | |||
998 | * MTBF测量服务失败的频率。例如,MTBF为四周的服务,平均每年失败13次。 | ||
999 | * MTRS测量故障后服务恢复的速度。例如,平均四个小时的MTRS服务将在四个小时内从故障中完全恢复。这并不意味着服务将始终在四小时内恢复,因为MTRS是许多事件的平均值。 | ||
1000 | |||
1001 | 较旧的服务通常设计具有非常高的MTBF,因此它们很少会失败。最近,已经转向优化服务设计以最小化MTRS,从而可以非常快速地恢复服务。最有效的方法是设计反脆弱的解决方案,该解决方案可以自动且非常快速地恢复,几乎不会对业务产生影响。对于某些服务,即使是非常短暂的故障也可能是灾难性的,而对于这些服务,专注于增加MTBF更为重要。 | ||
1002 | |||
1003 | |||
1004 | 定义可用性的方式必须适合每个服务。重要的是要了解用户和客户对可用性的看法,并定义适当的指标、报告和仪表板。很多组织根据MTBF和MTRS计算可用性百分比,但这些百分比数字很少与客户的体验相匹配,因此不适合大多数服务。其他应考虑的事项包括: | ||
1005 | |||
1006 | * 不同应用程序故障会影响哪些重要的业务功能 | ||
1007 | * 性能下降到什么程度,以至于该服务实际上无法使用 | ||
1008 | * 何时需要提供服务,以及服务提供者何时可以进行维护活动。 | ||
1009 | |||
1010 | 适用于某些服务的测量包括: | ||
1011 | |||
1012 | * **用户中断分钟数:**通过将事件持续时间乘以受影响的用户数或通过将每个用户受影响的分钟数相加来计算。这适用于直接支持用户生产效率的服务;例如,电子邮件服务。 | ||
1013 | * **丢失的交易数量:**通过从该期间预期发生的数量中减去交易数量来计算。这适用于支持基于交易的业务流程的服务,例如制造支持。 | ||
1014 | * **业务价值损失:**通过测量支持服务失败对业务生产效率的影响来计算。这很容易被客户理解,并且可用于规划投资以提高可用性。但是,很难确定哪些丢失的业务价值是由IT服务故障引起的,哪些是其他原因造成的。 | ||
1015 | * **用户满意度:**服务可用性是服务最重要和最明显的特征之一,并对用户满意度有很大影响。除了满足正式商定的可用性目标之外,确保用户对服务可用性感到满意也很重要。 | ||
1016 | |||
1017 | (% style="text-align:center" %) | ||
1018 | [[image:1640354737687-319.png]] | ||
1019 | |||
1020 | 图5.16可用性管理对价值链活动的贡献热力图 | ||
1021 | |||
1022 | |||
1023 | 大多数组织没有专门的可用性管理人员。所需的活动通常分布在整个组织中。一些组织将可用性管理活动作为风险管理的一部分,而其他组织则将其与服务连续性管理或容量和性能管理相结合。一些组织拥有站点可靠性工程师(SRE),他们负责管理和改进特定产品或服务的可用性。 | ||
1024 | |||
1025 | |||
1026 | 定期测试故障转移和恢复机制需要一个流程。许多组织还具有用于计算和报告可用性指标的流程;然而,可用性管理受文化、经验和知识的驱动,也受以下程序的驱动。 | ||
1027 | |||
1028 | |||
1029 | 图5.16显示了可用性管理对服务价值链的贡献,该实践涉及所有价值链活动: | ||
1030 | |||
1031 | * **计划:**在服务组合决策中以及为服务和实践设定目标和方向时,必须考虑可用性管理。 | ||
1032 | * **改进:**在计划和进行改进时,可用性管理可确保服务不会降级。 | ||
1033 | * **契动:**必须理解和捕获新服务和变更服务的可用性需求。 | ||
1034 | * **设计和转换:**新的和变更的服务必须设计为满足可用性目标,并且在转换期间需要测试可用性控制。 | ||
1035 | * **获取/构建:**构建组件或从第三方获取组件时,可用性是一个考虑因素。 | ||
1036 | * **交付和支持:**此活动包括可用性的度量,并对可能影响实现可用性目标的能力的事态做出响应。 | ||
1037 | |||
1038 | |||
1039 | |||
1040 | === **5.2.2 业务分析** === | ||
1041 | |||
1042 | |||
1043 | **关键信息:** | ||
1044 | |||
1045 | 业务分析实践的目的是分析业务或其某些元素,定义其相关需求,并推荐解决方案以满足这些需求和/或解决业务问题,这必须促进利益干系人的价值创造。业务分析使组织能够以有意义的方式传达其需求,表达变更的基本原理,并设计和描述使价值创造与组织目标相一致的解决方案。 | ||
1046 | |||
1047 | |||
1048 | 分析和解决方案应以整体方式进行,包括对流程、组织变革、技术、信息、策略和战略规划的考虑。业务分析工作主要由业务分析师(BA)执行,尽管其他人可能会做出贡献。 | ||
1049 | |||
1050 | |||
1051 | 在IT中,业务分析实践经常应用于软件开发项目中,但它们也适用于更高级别的体系结构,服务和组织的服务价值系统(SVS)。将业务分析的应用局限于在软件开发本身,就是在冒着开发不完整解决方案的风险。 | ||
1052 | |||
1053 | |||
1054 | 与业务分析相关的关键活动包括: | ||
1055 | |||
1056 | * 在不断变化的内部和外部环境中分析业务系统、业务流程、服务或体系结构 | ||
1057 | * 确定SVS的各个部分并确定优先级,需要改进的产品和服务,以及创新机会 | ||
1058 | * 评价和建议可以采取的行动,以创造期望的改进。行动可能不仅包括IT系统变更,还包括流程变更,组织结构变更和员工发展 | ||
1059 | * 记录支持服务的业务需求,以实现所需的改进 | ||
1060 | * 对收集的需求进行分析并与利益干系人验证后,推荐解决方案。 | ||
1061 | |||
1062 | 业务需求可以侧重于功用或侧重于功效。 | ||
1063 | |||
1064 | |||
1065 | **定义**: | ||
1066 | |||
1067 | * **功效需求** 通常将非功能性要求作为关键利益干系人和其他实践的输入来捕获。组织应致力于管理预定义的功效验收标准库,以用于项目管理和软件开发与管理等实践。 | ||
1068 | * **功用需求** 由客户定义并且为特定产品特有的功能需求。 | ||
1069 | |||
1070 | 业务分析应确保最有效和全面地完成这些活动,但不能在没有后续行动意图的情况下错误地进行分析。一个组织不应该试图对一个问题进行如此深入地或长时间地分析,以至于无法及时解决问题,或者试图用一个单一的、大规模的计划来解决每个问题,而这个计划不能在足够的时间内促进价值创造以实际应用。与此实践相关的流程应该防止这些错误。 | ||
1071 | |||
1072 | |||
1073 | 业务分析实践的工作范围包括使用和评价来自运营和支持的信息,以构建服务和实践在运行环境中如何执行的知识。这些知识不仅有助于确定当前服务设计的改进领域,还可以汲取经验教训,以改进未来的设计。 | ||
1074 | |||
1075 | |||
1076 | 业务分析的角色可能在不同组织之间有不同的定义,但它是一个公认的学科,具有一组特定的技能。业务分析不仅需要批判性思维和评价,还需要倾听、沟通和促进技能,分析和记录业务流程和用例,以及执行数据分析和建模的能力。 | ||
1077 | |||
1078 | |||
1079 | 当被分析的系统或服务跨越许多组织边界时,重要的是所涉及的各个业务部门采用合作伙伴关系,以确保进行整体分析和全面解决方案的建议。如果需要从这些单位中的一个或多个做出妥协,那么合作伙伴般的合作关系有助于为所有各方提供价值的解决方案。 | ||
1080 | |||
1081 | |||
1082 | 如果没有正确的信息,业务分析就无法成功,而想要有效,它需要访问与所分析领域相关的所有信息。例如,对于业务流程,业务分析师需要访问所有流程文档,包括流程进度、规程和作业指导、策略和流程度量。他们可能不仅需要采访负责业务流程的人员,还需要采访参与流程各个部分的人员,以便清楚地了解流程和相关问题。 | ||
1083 | |||
1084 | |||
1085 | 部署的技术通常包括组织用于收集和记录需求的任何系统,以及用于收集和处理数据和分析信息的项目管理系统和报告工具。在呈现分析结果时,其他可以提供帮助的技术是可视化建模和绘图工具,以及许多典型的办公效率套件的功能,例如电子表格、演示软件和文字处理。 | ||
1086 | |||
1087 | |||
1088 | 与所有实践一样,业务分析无法孤立地确保成功的解决方案。例如,战略管理实践为业务分析提供高级指导,然后指导分析和解决方案建议。反过来,业务分析的建议可以影响技术和其他策略。为确保权利各方的参与,业务分析依赖于关系管理。此外,服务价值链的自然发展需要业务分析活动与服务设计、软件开发和管理、测量和报告以及许多其他活动之间的交互。 | ||
1089 | |||
1090 | |||
1091 | 图5.17显示了业务分析对服务价值链的贡献,实践涉及所有价值链活动: | ||
1092 | |||
1093 | * **计划:**业务分析有助于制定战略决策,确定要做什么和如何做。 | ||
1094 | * **改进:**所有级别的评价和改进都受益于业务分析,尤其适用于战略和战术层面。 | ||
1095 | * **契动:**业务分析是在价值链活动期间收集需求的关键。 | ||
1096 | * **设计和转换:**准确需求的收集,优先级排序和分析有助于确保设计出高质量的解决方案并将其推进到运营中。 | ||
1097 | * **获取/构建:**业务分析技能是定义商定解决方案不可或缺的组成部分。 | ||
1098 | * **交付和支持:**在设计服务变更时以及在寻找持续改进机会时,来自持续交付服务的数据可以成为业务分析活动的一部分。 | ||
1099 | |||
1100 | (% style="text-align:center" %) | ||
1101 | [[image:1640354786939-309.png]] | ||
1102 | |||
1103 | 图5.17业务分析对价值链活动的贡献热力图 | ||
1104 | |||
1105 | |||
1106 | === **5.2.3 容量和性能管理** === | ||
1107 | |||
1108 | |||
1109 | **关键信息:** | ||
1110 | |||
1111 | 容量和性能管理实践的目的是确保服务达到约定和预期的绩效,以平衡成本效益的方式来满足当前和未来的需求。 | ||
1112 | |||
1113 | |||
1114 | **定义:性能** | ||
1115 | |||
1116 | 衡量一个系统、人员、团队、实践或服务所取得或交付的成果。 | ||
1117 | |||
1118 | 服务性能通常与在一个时间范围内执行的服务操作的数量以及与在给定的需求级别上完成服务操作所需的时间相关联。服务性能取决于服务容量,服务容量定义为配置项或服务可以交付的最大吞吐量。容量和性能的具体指标取决于服务或配置项的技术和业务性质。 | ||
1119 | |||
1120 | |||
1121 | 容量和性能管理实践通常涉及服务性能及其所依赖的支撑性资源的性能,例如基础架构、应用程序和第三方服务。在不少组织中,人员也被纳入了容量和性能管理。 | ||
1122 | |||
1123 | |||
1124 | 容量和性能管理实践包括以下活动: | ||
1125 | |||
1126 | * 服务性能和容量分析: | ||
1127 | ** 研究和监控当前的服务性能 | ||
1128 | ** 容量和性能建模 | ||
1129 | * 服务性能和容量规划: | ||
1130 | ** 容量需求分析 | ||
1131 | ** 需求预测和资源规划 | ||
1132 | ** 性能改进计划。 | ||
1133 | |||
1134 | 服务性能是客户和用户期望与要求的重要方面,因此极大地提高了客户对其所使用的服务和所感知的价值的满意度。容量和性能分析和规划有助于服务规划和构建,以及持续的服务交付、评估和改进。对容量和性能模型及模式的理解有助于预测需求并处理事件和缺陷。 | ||
1135 | |||
1136 | |||
1137 | 图5.18显示了容量和性能管理对服务价值链的贡献,实践涉及所有服务价值链活动: | ||
1138 | |||
1139 | * **计划** 容量和性能管理通过有关实际需求和绩效的信息,以及建模和预测工具和方法来支持战术和运营规划。 | ||
1140 | * **改进** 通过此实践提供的性能信息识别和驱动改进。 | ||
1141 | * **契动** 客户和用户的期望由有关性能和容量限制和功能的信息进行管理和支持。 | ||
1142 | * **设计和转换** 容量和性能管理对于产品和服务设计至关重要:它有助于确保新的和变更的服务被设计为最佳性能,容量和可扩展性。 | ||
1143 | * **获取/构建** 容量和性能管理有助于确保获取或构建的组件和服务满足组织的性能需求。 | ||
1144 | * **交付和支持** 服务和服务组件由性能和容量目标,指标和度量以及报告目标和工具提供支持和测试。 | ||
1145 | |||
1146 | (% style="text-align:center" %) | ||
1147 | [[image:1640354853225-568.png]] | ||
1148 | |||
1149 | 图5.18能力和绩效管理对价值链活动的贡献热力图 | ||
1150 | |||
1151 | |||
1152 | === **5.2.4 变更控制** === | ||
1153 | |||
1154 | |||
1155 | (% class="box infomessage" %) | ||
1156 | ((( | ||
1157 | **关键信息:** | ||
1158 | |||
1159 | 变更控制实践的目的是通过确保风险得到适当评估,授权变更继续以及管理变更排程,最大限度地提高成功的服务和产品变更的数量。 | ||
1160 | ))) | ||
1161 | |||
1162 | (% class="box warningmessage" %) | ||
1163 | ((( | ||
1164 | **定义:变更** | ||
1165 | |||
1166 | 添加、修改或删除可能对服务产生直接或间接影响的任何事物。 | ||
1167 | ))) | ||
1168 | |||
1169 | 变更控制的范围由每个组织定义。它通常包括所有IT基础设施、应用程序、文档、流程、供应商关系以及可能直接或间接影响产品或服务的任何其他内容。 | ||
1170 | |||
1171 | |||
1172 | 区分变更控制与组织变更管理非常重要。组织变更管理是管理变更的人员方面,以确保改进和组织转型计划得到成功实施。变更控制通常侧重于产品和服务的变化。 | ||
1173 | |||
1174 | |||
1175 | 变更控制必须在做出有益的变更(这些变更可以带来额外价值)与保护客户和用户免受变更的不利影响的需求之间取得平衡。所有变更都应由能够理解风险和预期收益的人员进行评估;然后必须在部署之前授权变更。但是,此评估不应引入不必要的延误。 | ||
1176 | |||
1177 | |||
1178 | 授权变更的个人或团队称为**变更授权(change authority)**。必须为每种类型的变更分配正确的变更授权,以确保变更控制既高效又有效。在高速组织中,分散变更批准的做法很普遍,这使同行评审成为高绩效的最佳预测指标。 | ||
1179 | |||
1180 | |||
1181 | 变更的三种类型分别以不同的方式进行管理: | ||
1182 | |||
1183 | * **标准变更:**这些是低风险,预授权的变更,可以很好地理解和完整记录,并且无需额外授权即可实施。它们通常作为服务请求启动,但也可能是运维变更(operational changes)。当创建或修改标准变更的规程时,应对任何其他变更进行全面的风险评估和授权。每次实施标准变更时都不需要重复进行风险评估;只有在对其执行方式进行修改时才需要执行。 | ||
1184 | * **一般变更:**这些变更需要按照流程进行计划、评估和授权。基于变更类型的变更模型可确定评估和授权的角色。有些一般变更是低风险,而这些变更授权人通常是能够做出快速决策的人,通常使用自动化来加速变更。其他一般变更都是非常重大的,变更授权可能与管理委员会(或同等程度)一样高。一般变更的启动是由创建变更请求来触发。这可以手动创建,但具有用于持续集成和持续部署的自动管道的组织,通常会自动执行变更控制过程的大多数步骤。 | ||
1185 | * **紧急变更:**这些变更必须尽快实施;例如,解决事件或实施安全补丁。紧急变更通常不包含在变更排程中,加快评估和授权流程以确保快速实施。紧急变更应尽可能与一般变更进行相同的测试、评估和授权,但可以接受将一些文件推迟到实施变更后,并且有时由于时间限制,有必要减少测试来实施变更。紧急变更可能还有一个单独的变更机构,通常包括少数了解所涉及的业务风险的高级管理人员。 | ||
1186 | |||
1187 | 变更排程用于帮助计划变更、协助沟通、避免冲突和分配资源。也可以在部署变更后使用它来提供事件管理、问题管理和改进计划所需的信息。无论变更授权人是谁,他们都可能需要在整个组织内进行广泛沟通。例如,风险评估可能要求他们从许多具有专业知识的人那里收集意见。此外,通常需要传达有关变更的信息,以确保在部署变更之前人们已做好充分的准备。 | ||
1188 | |||
1189 | |||
1190 | 图5.19显示了变更控制对服务价值链的贡献,该实践涉及所有价值链活动: | ||
1191 | |||
1192 | * **计划:**对产品和服务组合、策略和实践的变更都需要某种程度的控制,而变更控制实践用于提供它。 | ||
1193 | * **改进:**许多改进需要进行变更,这些变更应以与所有其他变更相同的方式进行评估和授权。 | ||
1194 | * **契动:**根据变更的性质,可能需要向客户和用户咨询或通知变更。 | ||
1195 | * **设计和转换:**许多变更是由于新服务或已变更的服务而引发的。变更控制活动是转型的主要因素。 | ||
1196 | * **获取/构建:**组件的变更均受变更控制,无论它们是内部生成还是从供应商处获得。 | ||
1197 | * **交付和支持:**变更可能会对交付和支持产生影响,有关变更的信息必须传达给执行此价值链活动的人员。这些人也可能参与评估和授权变更。 | ||
1198 | |||
1199 | (% style="text-align:center" %) | ||
1200 | [[image:1640354886766-694.png]] | ||
1201 | |||
1202 | 图5.19变更控制对价值链活动的贡献热力图 | ||
1203 | |||
1204 | |||
1205 | **ITIL故事:变更控制** | ||
1206 | |||
1207 | **亨利:**汽车租赁市场正在以前所未有的速度发展。为确保艾克苏满足客户需求并抓住机遇,我们需要加快产品上市速度并尝试新想法。我们的新服务产品将在艾克苏看到很多变化。有些团队需要翻倍,而其他团队可能会减少。我们需要让艾克苏的每个人都参与其中。 | ||
1208 | |||
1209 | **拉迪卡:**艾克苏的变更控制实践确保我们的服务在灵活性和可靠性之间取得适当的平衡。 | ||
1210 | |||
1211 | **马可:**我们的一些流程是高度自动化的,专为快速部署变更而设计。这些是变更我们的预订应用程序和一些IT系统的完美选择。 | ||
1212 | |||
1213 | **苏:**在其他情况下,例如当我们更新车辆时,我们会混合使用手动和自动测试。例如,Axle Aware道路监控和安全系统需要咨询和批准后,我们才能对其进行更新。 | ||
1214 | |||
1215 | **马尔科:**Axle Aware等系统无法像预订应用程序那样进行变更。这些变更的首要任务是我们安全行事并遵守适当的法规。这比投放市场的时间更重要。 | ||
1216 | |||
1217 | |||
1218 | === **5.2.5 事件管理** === | ||
1219 | |||
1220 | |||
1221 | (% class="box infomessage" %) | ||
1222 | ((( | ||
1223 | **关键信息:** | ||
1224 | |||
1225 | 事件管理实践的目的是尽快恢复正常的服务运作,以尽量减少事件的负面影响。 | ||
1226 | ))) | ||
1227 | |||
1228 | (% class="box warningmessage" %) | ||
1229 | ((( | ||
1230 | **定义:事件** | ||
1231 | |||
1232 | 服务的计划外中断或者服务质量的降低。 | ||
1233 | ))) | ||
1234 | |||
1235 | |||
1236 | 事件管理可以对客户和用户满意度,以及客户和用户如何看待服务提供商产生巨大的影响。每个事件都应该被记录和管理,以确保在满足客户和用户期望的时间内得到解决。目标解决时间得到约定、记录和沟通,以确保预期是切合实际的。根据约定的分类确定事件的优先级,以确保对业务影响最大的事件首先得到解决。 | ||
1237 | |||
1238 | |||
1239 | 组织应设计其事件管理实践,以便为不同类型的事件提供适当的管理和资源分配。必须有效管理影响较小的事件,以确保它们不会消耗太多资源。影响较大的事件可能需要更多资源和更复杂的管理。通常有单独的流程来管理重大事件和管理信息安全事件。 | ||
1240 | |||
1241 | |||
1242 | 有关事件的信息应存储在合适工具中的事件记录中。理想情况下,此工具还应提供相关配置项、变更、问题、已知错误和其他知识的链接,以实现快速有效的诊断和恢复。现代IT服务管理工具可以将事件自动匹配到其他事件、问题或已知错误,甚至可以提供事件数据的智能分析,以生成有助于解决未来事件的建议。 | ||
1243 | |||
1244 | |||
1245 | 重要的是,负责事件的人员应及时提供高质量的更新。这些更新应包括有关症状、业务影响、受影响的配置项、已完成的操作和计划的操作的信息。这些中的每一个都应该有一个时间戳和相关人员的信息,以便相关或感兴趣的人可以随时了解情况。可能还需要良好的协作工具,以便处理事件的人员可以有效地协作。 | ||
1246 | |||
1247 | |||
1248 | 根据问题的复杂性或事件类型,事件可以由许多不同小组的人员诊断和解决。所有这些团队都需要了解事件管理流程,以及他们对此所做的贡献如何帮助管理所提供服务的价值、结果、成本和风险: | ||
1249 | |||
1250 | * 一些事件将由用户自己通过自助解决。应捕获具体自助记录的使用,以便在测量和改进活动中使用。 | ||
1251 | * 某些事件将由服务台解决。 | ||
1252 | * 更复杂的事件通常会升级到支持团队进行解决。通常,转派基于事件的类别,这有助于识别正确的团队。 | ||
1253 | * 事件可升级至供应商或合作伙伴,供应商或合作伙伴为其产品和服务提供支持。 | ||
1254 | * 最复杂的事件,以及所有重大事件,通常需要一个临时团队共同确定解决方案。该团队可能包括许多利益干系人的代表,包括服务提供商、供应商、用户等。 | ||
1255 | * 在某些极端情况下,可能会调用灾难恢复计划来解决事件。服务连续性管理实践中描述了灾难恢复(第5.2.12节)。 | ||
1256 | |||
1257 | 有效的事件管理通常需要团队内部和团队之间的高度协作。这些团队可能包括服务台、技术支持、应用程序支持和供应商。协作可以促进信息共享和学习,并有助于更有效地解决事件。 | ||
1258 | |||
1259 | |||
1260 | Tips: | ||
1261 | |||
1262 | 一些组织使用称为蜂群的技术来帮助管理事件。这涉及许多不同的利益干系人最初一起工作,直到明确哪一个团队最适合继续接手,哪些人可以去执行其他任务。 | ||
1263 | |||
1264 | |||
1265 | 作为服务组成部分的第三方产品和服务需要支持协议,该协议将供应商的义务与服务提供商对客户的承诺保持一致。事件管理可能需要与这些供应商频繁互动,供应商合同这方面的日常管理通常是事件管理实践的一部分。供应商还可以充当服务台,记录和管理所有事件,并根据需要将其升级为专家或其他方。 | ||
1266 | |||
1267 | |||
1268 | 应该有一个正式的记录和管理事件的流程。此流程通常不包括如何诊断、调查和解决事件的详细规程,但可以提供使调查和诊断更有效的技术。在初次接触期间,可能有一些脚本用于从用户那里收集信息,这可能直接导致对简单事件的诊断和解决。调查更复杂的事件往往需要知识和专家的意见,而不是程序步骤。 | ||
1269 | |||
1270 | 在每个价值链活动中,处理事件都是可能的,尽管最明显的(由于对用户的影响)是操作环境中发生的事件。 | ||
1271 | |||
1272 | |||
1273 | 图5.20显示了事件管理对服务价值链的贡献,该实践主要应用于契动、交付和支持价值链活动。除计划外,其他活动可能会使用有关事件的信息来帮助确定优先级: | ||
1274 | |||
1275 | * **计划:**事件记录是在战术和作战层面策划活动的关键输入 | ||
1276 | * **改进:**事件记录是改进活动的关键输入,并根据在事件频率和严重程度进行优先处理。 | ||
1277 | * **契动:**事件对用户可见,重大事件对客户也可见。良好的事件管理需要定期沟通,以了解问题,设定期望,提供状态更新,并同意问题已得到解决,以便可以关闭事件。 | ||
1278 | * **设计和转换:**事件可能发生在测试环境中,也可能发生在服务发布和部署期间。此实践可确保这些事件得到及时和可控的解决。 | ||
1279 | * **获取/构建:**在开发环境中可能发生事件。事件管理实践确保这些事件得到及时和可控的解决。 | ||
1280 | * **交付和支持:**事件管理为支持做出了重大贡献。此价值链活动包括解决事件和问题。 | ||
1281 | |||
1282 | (% style="text-align:center" %) | ||
1283 | [[image:1640355110775-789.png]] | ||
1284 | |||
1285 | 图5.20事件管理对价值链活动的贡献热力图 | ||
1286 | |||
1287 | |||
1288 | **ITIL的故事:艾克苏的事件管理** | ||
1289 | |||
1290 | **拉迪卡:**艾克苏面临许多潜在的IT和非IT事件。汽车可能会发生故障,可能会发生道路交通事故,或者我们的客户可能会面临不熟悉的道路规则带来的挑战。 | ||
1291 | |||
1292 | **马可:**汽车预订可能会受到我们应用中的错误或用户因我们的软件导航错误而迷路的影响。当事件发生时,我们必须准备好尽快恢复正常服务。我们还必须确保我们的团队知道如何以及何时从预定义的恢复规程切换到集体分析。 | ||
1293 | |||
1294 | **拉迪卡:**我们还确保在此类案件之后进行调查和改进。 | ||
1295 | |||
1296 | **亨利:**艾克苏针对所有类型的事件制定了明确的流程,并为频繁发生的情况提供变通方案,例如轮胎爆胎或互联网连接中断。 | ||
1297 | |||
1298 | **拉迪卡:**我们的团队与供应商和合作伙伴共同努力,确保快速有效的事件响应。在遇到任何事件时,我们会与合作伙伴一起开发和测试恢复规程。 | ||
1299 | |||
1300 | |||
1301 | === **5.2.6 IT资产管理** === | ||
1302 | |||
1303 | |||
1304 | (% class="box infomessage" %) | ||
1305 | ((( | ||
1306 | **关键信息:** | ||
1307 | |||
1308 | IT资产管理实践的目的是计划和管理所有IT资产的全生命周期,以帮助组织: | ||
1309 | |||
1310 | * 价值最大化 | ||
1311 | * 控制成本 | ||
1312 | * 管理风险 | ||
1313 | * 支持对资产购买、再利用、报废和处置的决策 | ||
1314 | * 符合法规和合同要求。 | ||
1315 | ))) | ||
1316 | |||
1317 | (% class="box warningmessage" %) | ||
1318 | ((( | ||
1319 | **定义:IT资产** | ||
1320 | |||
1321 | 任何有助于交付IT产品或服务的具有财务价值的组件。 | ||
1322 | ))) | ||
1323 | |||
1324 | |||
1325 | IT资产管理的范围通常包括所有软件、硬件、网络、云服务和客户端设备。在某些情况下,它还可能包括非IT资产,例如建筑物或信息,这些资产具有财务价值并且需要提供IT服务。IT资产管理可以包括运营技术(operational technology, OT),包括作为物联网一部分的设备。这些通常是传统上不被视为IT资产的设备,但现在包括嵌入式计算功能和网络连接。 | ||
1326 | |||
1327 | |||
1328 | (% class="box" %) | ||
1329 | ((( | ||
1330 | 资产管理的类型: | ||
1331 | |||
1332 | 资产管理是一种成熟的实践,包括组织资产的获取、运营、维护和处置,尤其是关键的基础设施。 | ||
1333 | |||
1334 | |||
1335 | IT资产管理(ITAM)是资产管理的子实践,专门用于管理IT设备和基础设施的生命周期和总成本。 | ||
1336 | |||
1337 | |||
1338 | 软件资产管理(SAM)是IT资产管理的一个方面,专门用于管理软件资产的获取、开发、发布、部署、维护和最终退运。SAM程序提供对软件资产的有效管理、控制和保护。 | ||
1339 | ))) | ||
1340 | |||
1341 | |||
1342 | 理解资产的成本和价值对于理解产品和服务的成本和价值至关重要,因此是服务提供者所做的一切的重要基础因素。IT资产管理有助于提高资产及其价值的可见性,这是成功的服务管理的关键因素,并且对其他实践也很有用。 | ||
1343 | |||
1344 | |||
1345 | IT资产管理需要准确的库存信息,并将其保存在资产登记簿中。可以在审计中收集此信息,但最好将其作为变更资产状态的流程的一部分来获取,例如,在交付新硬件时,或者在请求新的云服务实例时。如果IT资产管理与其他实践(包括服务配置管理、事件管理、变更控制和部署管理)具有良好的接口,则可以更轻松地维护资产状态信息。审计仍然是需要的,但可以减少频率,当已有准确的资产登记簿时更容易进行审计。 | ||
1346 | |||
1347 | |||
1348 | IT资产管理有助于优化宝贵资源的使用。例如,可以基于服务级别协议承诺,服务请求的度量绩效,以及来自容量和性能管理的需求预测来计算组织所需的备用计算机的数量。 | ||
1349 | |||
1350 | |||
1351 | 在软件供应商请求审计许可证使用后,一些组织发现需要进行IT资产管理。如果没有维护所需信息,这可能会带来很大压力,并且可能导致重大成本,包括在执行审计和支付任何附加的许可证成本。只需将有关软件许可证使用的信息作为常规IT资产管理活动的一部分进行维护,并根据任何供应商请求提供此信息,便可以节省很多成本,并且更加容易。软件在硬件上运行,因此应合并软件和硬件资产的管理,以确保正确管理所有许可证。出于同样的原因,还应包括对基于云资产的管理。 | ||
1352 | |||
1353 | |||
1354 | 如果组织不能以与其他IT资产相同的方式管理云服务,那么云服务的成本很容易失控。每次单独使用云服务可能相对便宜,但通过少量的支出,很容易消耗比计划多得多的资源,从而给组织带来相应的大笔账单。同样,良好的IT资产管理可以帮助控制这一点。 | ||
1355 | |||
1356 | |||
1357 | 对于不同类型的资产,IT资产管理的活动和要求将有所不同: | ||
1358 | |||
1359 | * 硬件资产必须贴上标签以便清晰识别。重要的是要知道它们在哪并提供帮助保护它们免遭盗窃、损坏和数据泄漏。它们在重新使用或退役时,可能需要特殊处理;例如,磁盘驱动器的擦除或粉碎取决于信息安全要求。硬件资产也可能受到监管要求的约束,例如欧盟废弃电气和电子设备指令。 | ||
1360 | * 必须保护软件资产免受非法复制,这可能导致未经许可的使用。组织必须确保遵守许可条款,并且只能以合同允许的方式重复使用许可。保留已验证的购买证明和运行该软件的权利很重要。当设备退役时,很容易丢失软件许可证,因此IT资产管理流程必须收回这些许可证,并在适当的情况下使其可供重复使用是很重要的。 | ||
1361 | * 基于云的资产必须将分配给特定产品或组,以便管理成本。必须对资金进行管理,以便组织可以灵活地在需要时调用新的云实例来使用,并删除不需要的实例,而不会带来成本失控的风险。必须以与软件许可相同的方式理解和遵守合同安排。 | ||
1362 | * 客户资产必须分配给负责其照管的个人。需要流程来管理丢失或被盗的设备,可能需要使用工具来从中删除敏感数据,或者确保该数据不随设备丢失或被盗。 | ||
1363 | |||
1364 | 在任何情况下,组织都需要确保对每个资产的整个生命周期进行管理。这包括管理资产配置;接收、退役和返回;硬件处理;软件重用;租赁管理;以及潜在的许多其他活动。 | ||
1365 | |||
1366 | |||
1367 | IT资产管理维护有关资产、成本和相关合同的信息。因此,IT资产注册通常与存储在配置管理系统(CMS)中的信息组合(或联合)。如果两者是分开的,那么在它们之间映射资产是很重要的,通常可以使用标准命名约定。可能还需要将IT资产注册与用于管理其他金融资产的系统或用于管理供应商的系统相结合(或联合)。 | ||
1368 | |||
1369 | |||
1370 | 在一些组织中,有一个集中的团队负责IT资产管理。该团队还可能负责配置管理。在其他组织中,每个技术团队可能负责管理其支持的IT资产;例如,存储团队可以管理存储资产,而网络团队管理网络资产。每个组织都必须考虑自己的背景和文化,以选择适当的集中化级别。然而,担任一些核心角色有助于确保资产数据质量和开发特定方面的专业知识,例如软件许可和库存系统。 | ||
1371 | |||
1372 | IT资产管理通常包括以下活动: | ||
1373 | |||
1374 | * 根据结构和内容以及资产和相关介质的存储设施定义、填充和维护资产登记簿 | ||
1375 | * 与其他实践协作控制资产生命周期(例如,升级过时的软件或使用笔记本电脑和移动电话招聘新员工),并记录对资产的所有变更(状态、位置、特征、分配等) | ||
1376 | * 提供当前和历史数据、报告,并支持与IT资产有关的其他实践 | ||
1377 | * 审计资产,相关介质和合规性(特别是法规、许可条款和条件),并推动纠正和预防性改进,以处理检测到的问题。 | ||
1378 | |||
1379 | 图5.21显示了IT资产管理对服务价值链的贡献,该实践主要应用于设计和转换,以及获取/构建价值链活动: | ||
1380 | |||
1381 | * **计划:**IT资产管理的大多数策略和指南来自服务财务管理实践。一些资产管理策略由治理驱动,而另一些由其他实践驱动,例如信息安全管理。IT资产管理可被视为一种战略实践,可帮助组织理解和管理成本和价值。 | ||
1382 | * **改进:**此价值链活动必须考虑对IT资产的影响,一些改进将直接涉及IT资产管理,以帮助理解和管理成本。 | ||
1383 | * **契动:**利益干系人可能对IT资产管理有一些需求。例如,用户可能报告丢失或被盗的移动电话,或者客户可能需要报告IT资产的价值。 | ||
1384 | * **设计和转换:**此价值链活动会变更IT资产的状态,从而推动大多数IT资产管理活动。 | ||
1385 | * **获取/构建:**IT资产管理支持资产采购,以确保资产从其生命周期的开始就可追溯。 | ||
1386 | * **交付和支持:**IT资产管理有助于定位IT资产,跟踪其移动并控制其在组织中的状态。 | ||
1387 | |||
1388 | (% style="text-align:center" %) | ||
1389 | [[image:1640355215587-921.png]] | ||
1390 | |||
1391 | 图5.21 IT资产管理对价值链活动贡献的热力图 | ||
1392 | |||
1393 | |||
1394 | === **5.2.7 监控与事态管理** === | ||
1395 | |||
1396 | Monitoring and event management | ||
1397 | |||
1398 | |||
1399 | (% class="box infomessage" %) | ||
1400 | ((( | ||
1401 | **关键信息:** | ||
1402 | |||
1403 | 监控和事态管理实践的目的是系统地观察服务和服务组件,并记录和报告已确定为事态的状态变化。该实践对基础设施、服务、业务流程和信息安全事态进行识别和划分优先级,并对这些事态进行适当的响应,包括可能导致潜在故障或事件的响应条件。 | ||
1404 | ))) | ||
1405 | |||
1406 | (% class="box warningmessage" %) | ||
1407 | ((( | ||
1408 | **定义:事态 Event** | ||
1409 | |||
1410 | 对服务或其他配置项(CI)的管理具有重要意义的任何状态变化。通常,通过IT服务、CI或监视工具创建的通知来识别事态。 | ||
1411 | ))) | ||
1412 | |||
1413 | |||
1414 | 监控和事态管理实践管理着整个生命周期中的事态,以防止、最小化或消除其对业务的负面影响。 | ||
1415 | |||
1416 | |||
1417 | 该实践的监控部分侧重于对服务和支持服务配置项的系统观察,以发现具有潜在意义的情况。监控应以高度自动化的方式执行,并且可以主动或被动地执行。事态管理部分侧重于记录和管理由组织定义为事态的状态监视、状态变更,确定其重要性,以及识别和启动正确的控制操作以管理它们。通常,正确的控制措施是启动另一种实践,但有时除了继续监控情况之外,不采取任何行动。监控对于事态管理是必要的,但并不是所有监控都能检测到事态。 | ||
1418 | |||
1419 | |||
1420 | 并非所有事态都具有相同的意义或需要相同的响应。事态通常分为信息、警告和异常。信息事态在识别时不需要采取行动,但是在以后分析从他们收集的数据可能会发现可能对服务有益的可取的主动步骤。警告事态允许在业务实际发生任何负面影响之前采取行动,而异常事态表明已确定违反已建立的规范(例如,达到服务级别协议)。即使可能尚未遇到业务影响,异常事态也需要采取措施。 | ||
1421 | |||
1422 | |||
1423 | 监测和事态管理实践所需的流程和规程必须涉及这些关键活动以及更多: | ||
1424 | |||
1425 | * 确定应监控哪些服务、系统、CI或其他服务组件,并建立监控策略 | ||
1426 | * 实施和维护监控,利用被观察元素的本地监视特性,以及使用专门设计的监控工具 | ||
1427 | * 建立和维护阈值和其他标准,以确定哪些状态变化将被视为事态,并选择标准来定义每种类型的事态(信息、警告或异常) | ||
1428 | * 建立和维护有关如何处理每种类型的监测策略,以确保适当的管理 | ||
1429 | * 实施定义的阈值、标准和策略所需的执行流程和自动化。 | ||
1430 | |||
1431 | 该实践与参与服务价值链的其他实践高度互动。例如,一些事态将指示当前问题为事件。在这种情况下,正确的控制行动将是启动事件管理实践中的活动。显示超出预期水平的重复事态可能是潜在问题的证据,这可能会启动问题管理实践中的活动。对于某些事态,正确的响应是启动变更,采用变更控制实践。 | ||
1432 | |||
1433 | |||
1434 | 虽然这种实践的工作,一旦到位,就高度自动化,但仍然需要人为干预,而且实际上是必不可少的。为了定义监控策略和特定阈值和评估标准,它可以帮助引入广泛的视角,包括基础设施、应用程序、服务负责人、服务级别管理以及功效相关实践的表示。请记住,该实践的起点可能很简单,为以后增加复杂性奠定了基础,因此管理参与者的期望很重要。 | ||
1435 | |||
1436 | |||
1437 | 组织和人员对于为监控的数据和事态提供适当的响应,并与政策和组织优先级保持一致,也是至关重要的。必须明确定义角色和职责,每个人或小组必须能够方便、及时地获取履行其职责所需的信息。 | ||
1438 | |||
1439 | |||
1440 | 自动化是成功监控和事态管理的关键。一些服务组件配备了内置的监控和报告功能,可以配置这些功能以满足实践的需要,但有时需要实现和配置专用的监控工具。监控本身可以是主动的也可以是被动的。在主动监控中,工具将轮询关键CI,查看其状态以在识别出异常情况时生成警报。在被动监控中,CI本身会生成操作警报。 | ||
1441 | |||
1442 | |||
1443 | 自动化工具也应该用于事态的相关性。这些功能可以由监控工具或其他工具(如ITSM工作流系统)提供。这种做法可能会产生大量数据,但如果没有明确策略和战略来限制、过滤和使用此数据,那么它将毫无价值。 | ||
1444 | |||
1445 | |||
1446 | 如果第三方在整体服务架构中提供产品或服务,他们还应提供其产品的监控和报告功能方面的专业知识。在尝试实施监控和事件管理策略和工作流时,利用这些专业知识可以节省时间。如果某些IT功能(例如基础设施管理)部分或全部外包给供应商,那么他们可能不愿意公开与其管理的元素相关的监控或事态数据。不要要求非真正需要的数据,但如果需要数据,请确保该数据的提供是供应商服务合同的一部分。 | ||
1447 | |||
1448 | |||
1449 | 图5.22显示了监控和事件管理对服务价值链的贡献,该实践涉及除计划外的所有价值链活动: | ||
1450 | |||
1451 | * **改进** 监控和事态管理实践对于密切观察环境以评价和主动改善其健康和稳定性至关重要。 | ||
1452 | * **契动** 监控和事态管理可能是内部契动行动的来源。 | ||
1453 | * **设计和转换** 监控数据可以为设计决策提供信息。监控是转换的重要组成部分:它提供有关所有环境中转换成功的信息。 | ||
1454 | * **获取/构建** 监控和事态管理支持开发环境,确保其透明性和可管理性。 | ||
1455 | * **交付和支持** 该实践指导组织如何管理已识别事态的内部支持,并酌情启动其他实践。 | ||
1456 | |||
1457 | (% style="text-align:center" %) | ||
1458 | [[image:1640355265955-942.png]] | ||
1459 | |||
1460 | 图5.22监控和事态管理对价值链活动的贡献的热力图 | ||
1461 | |||
1462 | |||
1463 | === **5.2.8 问题管理** === | ||
1464 | |||
1465 | |||
1466 | (% class="box infomessage" %) | ||
1467 | ((( | ||
1468 | **关键信息:** | ||
1469 | |||
1470 | 问题管理实践的目的是通过查明事件的实际和潜在原因,以及管理变通方案和已知错误,来减少事件的可能性和影响。 | ||
1471 | ))) | ||
1472 | |||
1473 | (% class="box warningmessage" %) | ||
1474 | ((( | ||
1475 | **定义** | ||
1476 | |||
1477 | * **问题**:一个或多个事件的原因或潜在原因。 | ||
1478 | * **已知错误**:一个已经分析但尚未解决的问题。 | ||
1479 | ))) | ||
1480 | |||
1481 | |||
1482 | (% style="text-align:center" %) | ||
1483 | [[image:1640355290627-179.png]] | ||
1484 | |||
1485 | 图5.23问题管理的阶段 | ||
1486 | |||
1487 | |||
1488 | 每项有错误、缺陷或漏洞的服务都有可能导致事件。它们可能包括服务管理的四个维度中的任何一个方面的错误。在服务上线之前,会识别并解决许多错误。但是,有些问题仍然没有被识别解决,并且可能对实时服务构成风险。在ITIL中,这些错误称为问题,它们由问题管理实践解决。 | ||
1489 | |||
1490 | |||
1491 | 问题与事件有关,但应加以区分,因为它们管理方式不同: | ||
1492 | |||
1493 | * 事件对用户或业务流程有影响,必须予以解决,以便进行正常的业务活动。 | ||
1494 | * 问题是事件的原因。他们需要调查和分析,以确定原因,制定变通方案,并建议长期解决方案。这减少了未来事件的数量和影响。 | ||
1495 | |||
1496 | 问题管理涉及三个不同的阶段,如图5.23所示。 | ||
1497 | |||
1498 | |||
1499 | 问题识别活动可识别问题并记录问题。这些包括: | ||
1500 | |||
1501 | * 执行事件记录的趋势分析 | ||
1502 | * 用户、服务台和技术支持人员检测重复和重复出现的问题 | ||
1503 | * 在重大事件管理期间,确定事件可能再次发生的风险 | ||
1504 | * 分析从供应商和合作伙伴收到的信息 | ||
1505 | * 分析从内部软件开发人员、测试团队和项目团队收到的信息。 | ||
1506 | * 其他信息来源也可能导致发现问题。 | ||
1507 | |||
1508 | 问题控制活动包括问题分析、记录变通方案和已知错误。 | ||
1509 | |||
1510 | |||
1511 | 根据问题所构成的风险,对问题进行优先级分析,并根据其潜在影响和可能性作为风险进行管理。没有必要分析每个问题;在最高优先级的问题上取得重大进展比调查组织所知道的每一个小问题更有价值。 | ||
1512 | |||
1513 | |||
1514 | 事件通常有许多相互关联的原因,它们之间的关系可能很复杂。问题控制应考虑所有促成因素,包括导致事件持续时间和影响的原因,以及导致事件发生的原因。从服务管理的所有四个维度的角度分析问题非常重要。例如,由不准确的文档引起的事件,可能不仅需要对文档进行更正,还需要对支持人员、供应商和用户进行培训和提高认知。 | ||
1515 | |||
1516 | |||
1517 | 当无法快速解决问题时,基于对问题的理解,为未来事件找到并记录变通方案通常是很有用的。变通方案记录在问题记录中。这可以在任何阶段完成;它不需要等待分析完成。如果在问题控制的早期记录了变通方案,则应在问题分析完成后对其进行评审和改进。 | ||
1518 | |||
1519 | |||
1520 | (% class="box warningmessage" %) | ||
1521 | ((( | ||
1522 | **定义:变通方案 Workaround** | ||
1523 | |||
1524 | 一种解决方案,可以减少或消除尚未提供完整解决方案的事件或问题的影响。一些变通方案可以减少事件发生的可能性。 | ||
1525 | ))) | ||
1526 | |||
1527 | |||
1528 | 当解决问题不可行或不具有成本效益时,有效的事件变通方案可以成为处理某些问题的永久方法。在这种情况下,问题仍然处于已知错误状态中,如果发生相关事件,则会应用记录的变通方案。每个记录在案的变通方案都应该包含对其适用症状的明确定义。在某些情况下,变通方案应用程序可以自动化。 | ||
1529 | |||
1530 | |||
1531 | 对于其他问题,应找到修复错误的方法。这是**错误控制(error control)**的一部分。错误控制活动管理已知错误,即是已完成初始分析的问题;它通常意味着已经识别出有缺陷的部件。错误控制还包括识别潜在的永久解决方案,这可能会导致需要变更请求实施解决方案,但这只有在在成本、风险和收益方面是合理的情况下才可以。 | ||
1532 | |||
1533 | |||
1534 | 错误控制会定期重新评估尚未解决的已知错误的状态,包括对客户的总体影响、永久解决方案的可用性和成本,以及变通方案的有效性。每次使用变通方案时,都应评估变通方案的有效性,因为可以根据评估对变通方案进行改进。 | ||
1535 | |||
1536 | |||
1537 | 问题管理活动与事件管理密切相关。需要将实践设计为在价值链中协同工作。这两种实践的活动可以相互补充(例如,确定事件的原因是可能导致事件解决的问题管理活动),但它们也可能发生冲突(例如,调查事件的原因可能会延迟恢复服务所需的行动)。 | ||
1538 | |||
1539 | |||
1540 | 问题管理、风险管理、变更控制、知识管理和持续改进之间的接口示例如下: | ||
1541 | |||
1542 | * 问题管理活动可作为风险管理的特定案例进行组织:旨在识别、评估和控制服务管理的四个维度中的任何一个方面的风险。采用风险管理工具和技术进行问题管理是很有用的。 | ||
1543 | * 解决问题的实施通常不在问题管理的范围内。问题管理通常通过变更控制启动解决方案,并参与实施后评审;但是,批准和实施变更超出了问题管理实践的范围。 | ||
1544 | * 问题管理实践的输出包括有关变通方案和已知错误的信息和文档。此外,问题管理可以利用知识管理系统中的信息来调查、诊断和解决问题。 | ||
1545 | * 问题管理活动可以识别服务管理的所有四个方面的改进机会。在某些情况下,解决方案可以被视为改进机会,因此它们包含在持续改进注册表(CIR)中,并使用持续改进技术对其进行优先级排序和管理,有时作为产品待办事项列表的一部分。 | ||
1546 | |||
1547 | 许多问题管理活动依赖于员工的知识和经验,而不是遵循详细的程序。负责诊断问题的人员通常需要具备理解复杂系统的能力,并能够考虑到可能发生的不同故障。发展这种分析和创造能力的组合需要指导和时间,以及适当的培训。 | ||
1548 | |||
1549 | |||
1550 | (% class="box" %) | ||
1551 | ((( | ||
1552 | **ITIL的故事:艾克苏的问题管理** | ||
1553 | |||
1554 | **亨利:**艾克苏参与了我们所有汽车制造商的反馈计划。我们与他们共享维护和维修数据,以帮助他们不断改进服务。作为回报,他们会提醒我们车辆中存在的任何潜在问题。 | ||
1555 | |||
1556 | **拉迪卡:**最近,我们收到警告,说我们的车队存在潜在问题。一家汽车制造商召回了我们车队中的一款受欢迎的车型,以修复安全气囊激活系统中发现的错误。 | ||
1557 | |||
1558 | **苏:**幸运的是,在艾克苏还没遇到任何事件之前就发现了它,但仍有可能发生问题,这意味着这是我们必须处理的问题。 | ||
1559 | |||
1560 | **马可:**我们在其他系统和服务也采用了类似的做法,包括我们使用的所有IT组件。 | ||
1561 | |||
1562 | **拉迪卡:**艾克苏的事件管理实践是我们系统错误信息最重要的来源之一。我们遇到任何重大事件后,都会对可能的原因进行调查。有时这会导致我们发现并修复系统中的错误,并且我们通常会找到减少艾克苏在未来发生的事件数量的方法。 | ||
1563 | ))) | ||
1564 | |||
1565 | |||
1566 | |||
1567 | (% style="text-align:center" %) | ||
1568 | [[image:1640355355861-337.png]] | ||
1569 | |||
1570 | 图5.24问题管理对价值链活动的贡献热力图 | ||
1571 | |||
1572 | |||
1573 | 问题管理通常侧重于运行环境中的错误。图5.24显示了问题管理对服务价值链的贡献,该实践主要应用于改进、交付和支持价值链活动: | ||
1574 | |||
1575 | * **改进:**这是问题管理的主要聚焦领域。有效的问题管理提供了减少事件数量所需的理解,以及减少无法避免的事件的影响。 | ||
1576 | * **契动:**客户和用户可以看到对服务产生重大影响的问题。在某些情况下,客户可能希望参与问题优先级排序,并且应该沟通管理问题的状态和计划。变通方案通常通过服务门户向用户提供。 | ||
1577 | * **设计和转换:**问题管理提供有助于改进测试和知识转移的信息。 | ||
1578 | * **获取/构建:**可以通过问题管理识别产品缺陷;然后将这些作为该价值链活动的一部分进行管理。 | ||
1579 | * **交付和支持:**问题管理通过防止事件重复和支持及时的事件解决做出了重大贡献。 | ||
1580 | |||
1581 | |||
1582 | |||
1583 | === **5.2.9 发布管理** === | ||
1584 | |||
1585 | |||
1586 | (% class="box infomessage" %) | ||
1587 | ((( | ||
1588 | **关键信息:** | ||
1589 | |||
1590 | 发布管理实践的目的是使新的和已变更的服务和功能可供使用。 | ||
1591 | ))) | ||
1592 | |||
1593 | |||
1594 | (% class="box warningmessage" %) | ||
1595 | ((( | ||
1596 | **定义:发布** | ||
1597 | |||
1598 | 可供使用的服务或其他配置项的版本,或配置项的集合。 | ||
1599 | ))) | ||
1600 | |||
1601 | |||
1602 | 一个发布可以包括许多不同的基础设施和应用程序组件,它们一起工作以交付新的或变更的功能,它还可能包括文档、培训(针对用户或IT人员)、更新的流程或工具,以及所需的任何其他组件。发布的每个组件可以由服务提供者开发,或者从第三方获得并由服务提供者集成。 | ||
1603 | |||
1604 | 发布的大小范围从非常小(仅涉及一个小的变更功能)到非常大(涉及许多提供全新服务的组件)。在任何一种情况下,发布计划都将指定要提供的新组件和已变更组件的确切组合,以及它们的发布时间。 | ||
1605 | |||
1606 | |||
1607 | 发布计划用于记录发布的时间。该计划应与客户和其他利益干系人协商并达成一致。发布后实施审核可以实现学习和改进,并有助于确保客户满意。 | ||
1608 | |||
1609 | 在某些环境中,几乎所有发布管理工作都在部署之前进行的,并制定了在特定发布中部署哪些组件的计划。然后,部署将使新功能可用。 | ||
1610 | |||
1611 | |||
1612 | (% style="text-align:center" %) | ||
1613 | [[image:1640355382054-290.png]] | ||
1614 | |||
1615 | 图5.25 发布管理在传统/瀑布环境中 | ||
1616 | |||
1617 | (% style="text-align:center" %) | ||
1618 | [[image:1640355417414-260.png]] | ||
1619 | |||
1620 | 图5.26 敏捷/开发运维一体化环境中的发布管理 | ||
1621 | |||
1622 | |||
1623 | 图5.25显示了如何在传统/瀑布环境中处理发布管理。在这些环境中,发布管理和部署可以组合在一起并作为单个流程执行。 | ||
1624 | |||
1625 | |||
1626 | 在Agile/DevOps环境中,部署后可能会有重要的发布管理活动。在这些情况下,软件和基础设施通常以很小的增量部署,而发布管理活动会在以后启用新功能。这可能是一个非常小的变更。图5.26显示了在这样的环境中如何处理发布管理。 | ||
1627 | |||
1628 | |||
1629 | 发布管理通常是阶段性的,向少数用户提供试用版,以确保在向其他组发布之前一切正常。这种分阶段的方法可以与图5.25和5.26中所示的两个序列中的任何一个一起使用。有时,发布必须同时对所有用户可用,例如需要对底层共享数据进行重大重组时。 | ||
1630 | |||
1631 | |||
1632 | 通常使用蓝/绿发布或功能标记来实现发布的暂存: | ||
1633 | |||
1634 | * 蓝/绿发布使用两个镜像生产环境。通过使用将其连接到正确环境的网络工具,可以将用户切换到已使用新功能更新的环境。 | ||
1635 | * 功能标记使特定功能可以以受控方式发布给各个用户或组。新功能将部署到生产环境中,而不会发布。然后,用户配置设置会根据需要将新功能发布给单个用户(或用户组)。 | ||
1636 | |||
1637 | 在DevOps环境中,发布管理通常与持续集成和持续交付工具链集成。发布管理工具可能由专人负责,但是关于发布的决定可以由开发团队做出。在更传统的环境中,发布是通过组件的部署来实现的。每个发布都由ITSM工具上的发布记录描述。发布记录链接到配置项和变更记录,以维护有关发布的信息。 | ||
1638 | |||
1639 | |||
1640 | 发布的组件通常由第三方提供。第三方组件的示例包括云基础设施、软件即服务组件和第三方支持。将第三方软件或开源软件作为应用程序开发的一部分也很常见。发布管理需要跨组织边界工作,以确保所有组件都兼容,并为用户提供无缝体验。它还需要考虑变更对第三方组件的影响,并计划如何发布这些组件。 | ||
1641 | |||
1642 | (% style="text-align:center" %) | ||
1643 | [[image:1640355455708-251.png]] | ||
1644 | |||
1645 | |||
1646 | 图5.27发布管理对价值链活动贡献的热力图 | ||
1647 | |||
1648 | |||
1649 | 图5.27显示了发布管理对服务价值链的贡献,该实践涉及所有价值链活动: | ||
1650 | |||
1651 | * **计划:**发布的策略、指导和时间表由组织战略和服务组合驱动。每个发布的大小、范围和内容都应进行计划和管理。 | ||
1652 | * **改进:**可能需要新的或变更的发布来交付改进,并且应该向任何其他发布一样计划和管理这些改进。 | ||
1653 | * **契动:**发布的内容和节奏必须设计得符合客户和用户的需求和期望。 | ||
1654 | * **设计和转换:**发布管理确保以受控方式向客户提供新的或变更的服务。 | ||
1655 | * **获取/构建:**组件的变更通常包含在以受控方式交付的发布中。 | ||
1656 | * **交付和支持:**发布可能会影响交付和支持。本实践提供了培训、文档、发行说明、已知错误、用户指南、支持脚本等,以促进服务恢复。 | ||
1657 | |||
1658 | (% class="box" %) | ||
1659 | ((( | ||
1660 | **ITIL的故事:艾克苏的发布管理** | ||
1661 | |||
1662 | **马可:**当我们发布预订应用程序的更新时,我们会确保为用户、客户和团队的用户意识和营销活动也会随之更新。我们为内部和外部的服务台和支持团队提供专门的培训。 | ||
1663 | |||
1664 | **拉迪卡:**有些变更可能需要额外的支持或引入新的组件。例如,Axle Aware发布了一个新的用户手册来解释系统。在发布之前,我们还确保Aware系统可以与艾克苏预订应用同步。 | ||
1665 | |||
1666 | **亨利:**对新应用程序和Axle Aware的支持确实有助于这两种新产品的发布,给用户留下了良好的第一印象,在我们的用户和客户以及我们自己的团队中获得了很高的认同度。 | ||
1667 | ))) | ||
1668 | |||
1669 | |||
1670 | === **5.2.10 服务目录管理** === | ||
1671 | |||
1672 | |||
1673 | (% class="box infomessage" %) | ||
1674 | ((( | ||
1675 | **关键信息:** | ||
1676 | |||
1677 | 服务目录管理实践的目的是提供关于所有服务和服务供应的一致信息,并确保对相关受众可用。 | ||
1678 | ))) | ||
1679 | |||
1680 | |||
1681 | 服务目录中的服务列表代表当前可用的服务,并且是服务提供者服务组合中跟踪的服务总列表的子集。服务目录管理确保服务和产品描述能够清晰传达给目标受众,以支持利益相关者契动和服务交付。服务目录可以采用多种形式,例如文档、在线门户、或使当前服务列表能够传达给受众的工具。 | ||
1682 | |||
1683 | |||
1684 | ==== **5.2.10.1 服务目录管理活动** ==== | ||
1685 | |||
1686 | 服务目录管理实践包括与发布、编辑、维护服务和产品描述及其相关供应的一系列持续活动。它提供了可用服务范围以及条款的视图。服务目录管理实践由诸如服务所有者和其他负责管理、编辑和更新可用服务列表的角色支持,这些服务在引入、变更或停用时都是如此。 | ||
1687 | |||
1688 | |||
1689 | (% class="box" %) | ||
1690 | ((( | ||
1691 | **量身定制的视图:** | ||
1692 | |||
1693 | 如上所述,服务目录能够创建价值,并被服务价值链中的许多不同实践所使用。因此,它需要根据其预期目的灵活地呈现所提供的服务细节和属性。因此,组织不妨考虑向不同的受众提供不同的目录视图。 | ||
1694 | ))) | ||
1695 | |||
1696 | |||
1697 | 服务目录中的完整服务列表可能不适用于所有客户和/或用户。同样,服务的各种属性(如技术规范、产品、协议和成本)不适用于所有服务使用者类型。这意味着服务目录应该能够为不同的利益干系人提供不同的视图和详细程度。视图的例子包括: | ||
1698 | |||
1699 | * **用户视图** 提供有关可请求的服务产品以及供应细节的信息。 | ||
1700 | * **客户视图** 提供服务级别、财务和服务性能数据。 | ||
1701 | * **IT到IT客户视图** 提供用于服务交付的技术、安全性和流程信息。 | ||
1702 | |||
1703 | 虽然服务目录可能有多个视图,但应尽可能避免在不同技术系统内创建单独或隔离的服务目录,因为这将促进分离、可变性和复杂性。 | ||
1704 | |||
1705 | |||
1706 | 为了让服务目录被客户组织认为是有用的,它必须做的不仅仅是提供一个静态平台来发布有关IT服务的信息。除非服务目录通过支持与标准和非标准服务产品相关的讨论,和/或自动化请求和订单履行流程来实现客户契动,否则其作为有用且有意义的资源的持续采用的可能性是最小的。出于这个原因,服务目录上的许多组织的焦点都集中在服务产品的可消耗或可订购元素上。这些通常被称为请求目录。 | ||
1707 | |||
1708 | |||
1709 | (% class="box warningmessage" %) | ||
1710 | ((( | ||
1711 | **定义:服务请求视图** | ||
1712 | |||
1713 | 服务目录的视图,提供有关现有服务和新服务的服务请求的详细信息,供用户使用。 | ||
1714 | ))) | ||
1715 | |||
1716 | |||
1717 | 图5.28显示了服务目录管理对服务价值链的贡献,该实践涉及所有价值链活动: | ||
1718 | |||
1719 | * **计划:**服务目录通过提供有关当前服务范围和产品的详细信息,使战略和服务组合投资决策得以实现。 | ||
1720 | * **改进:**不断监控和评价服务目录描述和需求模式,以支持持续改进、一致性和创造价值。 | ||
1721 | * **契动:**服务目录通过启用并可能自动执行诸如关系管理、请求管理和服务台等之类实践的各个方面,从而实现与客户和用户的战略、战术和运营关系的建立。 | ||
1722 | * **设计和转换:**服务目录可确保考虑和发布服务的功用和功效方面,包括信息安全策略、IT服务连续性级别、服务级别协议和服务产品。其他活动包括服务描述的定义和创建、请求模型以及要发布的视图。 | ||
1723 | * **获取/构建:**服务目录管理通过为组件和服务的采购提供服务目录视图来支持此价值链活动。 | ||
1724 | * **交付和支持:**服务目录提供有关如何交付和支持服务的上下文,并发布与协议和性能相关的期望。 | ||
1725 | |||
1726 | (% style="text-align:center" %) | ||
1727 | [[image:1640355529908-931.png]] | ||
1728 | |||
1729 | 图5.28服务目录管理对价值链活动的贡献热力图 | ||
1730 | |||
1731 | |||
1732 | === **5.2.11 服务配置管理** === | ||
1733 | |||
1734 | |||
1735 | (% class="box infomessage" %) | ||
1736 | ((( | ||
1737 | **关键信息:** | ||
1738 | |||
1739 | 服务配置管理实践的目的是确保有关服务配置以及支持服务的配置项的准确可靠的信息在需要之时和在所需之处可用。这包括有关如何配置CI以及它们之间的关系的信息。 | ||
1740 | ))) | ||
1741 | |||
1742 | (% class="box warningmessage" %) | ||
1743 | ((( | ||
1744 | **定义:配置项** | ||
1745 | |||
1746 | 为交付IT服务而需要管理的任何组件。 | ||
1747 | ))) | ||
1748 | |||
1749 | |||
1750 | 服务配置管理收集和管理有关各种配置项的信息,通常包括硬件、软件、网络、建筑物、人员、供应商和文档。服务也被视为配置项,配置管理可帮助组织了解为每项服务做出贡献的众多配置项是如何协同工作的。图5.29是一个简化的图,显示了多个配置项如何为IT服务做出贡献。 | ||
1751 | |||
1752 | |||
1753 | 配置管理提供有关每个服务及其关系的配置项的信息:它们如何交互、关联和相互依赖,以便为客户和用户创造价值。这包括有关服务之间依赖关系的信息。此高级视图通常称为服务映射或服务模型,并构成服务体系结构的一部分。 | ||
1754 | |||
1755 | |||
1756 | 收集和维护配置信息所需的努力与信息所创造的价值相平衡非常重要。维护有关每个组件及其与其他组件的关系的大量详细信息的成本可能很高,而且可能带来的价值很小。配置管理的需求必须基于对组织目标的理解,以及配置管理如何促进价值创造。 | ||
1757 | |||
1758 | |||
1759 | 配置管理创建的价值是间接的,但是可以使许多其他实践高效且有效地工作。因此,配置管理的规划应首先了解谁需要配置信息、如何使用配置信息、获取配置信息的最佳方式是什么、以及谁可以维护和更新此信息。有时,对于需要的典型it服务,简单地收集信息比预先收集和维护信息更有效,但在其他情况下,在配置管理系统(CMS)中提供信息是必不可少的。为每种类型的配置项记录的信息类型和数量应基于该信息的价值、维护信息的成本以及信息的使用方式。 | ||
1760 | |||
1761 | (% style="text-align:center" %) | ||
1762 | [[image:1640355569734-250.png]] | ||
1763 | |||
1764 | 图5.29典型IT服务的简化服务模型 | ||
1765 | |||
1766 | [[image:1659327399592-429.png]] | ||
1767 | |||
1768 | |||
1769 | (% class="box warningmessage" %) | ||
1770 | ((( | ||
1771 | **定义:配置管理系统** | ||
1772 | |||
1773 | 用于支持服务配置管理的一组工具、数据和信息。 | ||
1774 | ))) | ||
1775 | |||
1776 | |||
1777 | 配置信息应以受控方式共享。有些信息可能很敏感的;例如,它可能对试图破坏安全控制的人有用,或者它可能包含有关用户的个人信息,例如电话号码和家庭地址。 | ||
1778 | |||
1779 | |||
1780 | 配置信息可以存储和发布在整个组织的单个配置管理数据库(CMDB)中,但更常见的是它可以分布在多个源上。无论哪种情况,维护配置记录之间的链接都是很重要的,以便人们可以看到他们需要的全部信息,以及各种配置项是如何协同工作的。一些组织联合CMDB以提供集成视图。其他机构可能会维护不同类型的数据;例如,为资产管理数据(参见第5.2.6节)、配置详细信息、服务目录信息和高级服务模型提供单独的数据存储。 | ||
1781 | |||
1782 | |||
1783 | 用于记录事件、问题和变更的工具需要访问配置记录。例如,试图识别服务问题的组织可能需要查找与特定软件版本或磁盘驱动器型号相关的事件。了解对此信息的需求有助于确定应为该组织存储哪些CI属性;在本例中,是软件版本和磁盘驱动器型号。为了诊断事件,可能需要查看受影响的CI的最近变更,因此必须维护CI与变更之间的关系。 | ||
1784 | |||
1785 | |||
1786 | 许多组织使用数据收集工具从基础设施和应用程序收集详细的配置信息,并使用它来填充CMS。这可能是有效的,但也可能会鼓励收集太多数据,而没有足够的关系信息以及组件如何协同工作来创建服务。有时,配置信息用于实际创建CI,而不仅仅是记录它。此方法用于“基础设施作为代码”,其中基础设施的信息在数据存储库中进行管理,并用于自动配置环境。 | ||
1787 | |||
1788 | |||
1789 | 大型组织可能拥有专门用于配置管理的团队。在其他组织中,这种实践可以与变更控制相结合,或者可以有一个团队负责变更、配置和发布管理。一些组织应用分布式模型,其中功能团队在其控制和监督范围内更新和维护CI。 | ||
1790 | |||
1791 | |||
1792 | 配置管理通常需要以下流程: | ||
1793 | |||
1794 | * 识别新的配置项,并将其添加到CMS | ||
1795 | * 部署变更时更新配置数据 | ||
1796 | * 验证配置记录是否正确 | ||
1797 | * 审核应用程序和基础设施,以识别任何未记录的内容。 | ||
1798 | |||
1799 | 图5.30显示了配置管理对服务价值链的贡献,该实践涉及所有价值链活动: | ||
1800 | |||
1801 | * **计划:**配置管理用于规划新的或已变更的服务。 | ||
1802 | * **改进:**配置管理与服务管理的其他方面一样,应该进行度量和持续改进。由于配置管理的价值通常来自于它如何促进其他实践,所以理解这些实践如何使用配置信息,然后确定如何改进配置信息是很重要的。 | ||
1803 | * **契动:**一些利益干系人(合作伙伴和供应商、消费者、监管机构等)可能需要并使用配置信息,或向组织提供其配置信息。 | ||
1804 | * **设计和转换:**配置管理记录资产如何协同工作以创建服务。此信息用于支持许多价值链活动,并作为转换活动的一部分进行更新。 | ||
1805 | * **获取/构建:**可以在此价值链活动期间创建配置记录,描述新的或已变更的服务和组件。有时配置记录用于创建正在构建的代码或人工制品。 | ||
1806 | * **交付和支持:**有关配置项的信息对于支持服务恢复至关重要。配置信息用于支持事件管理和问题管理实践的活动。 | ||
1807 | |||
1808 | (% style="text-align:center" %) | ||
1809 | [[image:1640355598301-353.png]] | ||
1810 | |||
1811 | 图5.30服务配置管理对价值链活动的贡献热力图 | ||
1812 | |||
1813 | |||
1814 | === **5.2.12 服务连续性管理** === | ||
1815 | |||
1816 | |||
1817 | (% class="box infomessage" %) | ||
1818 | ((( | ||
1819 | **关键信息:** | ||
1820 | |||
1821 | 服务连续性管理实践的目的是确保在发生灾难时,服务的可用性和性能保持在足够的水平。该实践为建立组织的容灾能力提供了一个框架,能够产生有效的响应,来保护关键利益干系人的利益以及组织的声誉、品牌和价值创造活动。 | ||
1822 | ))) | ||
1823 | |||
1824 | |||
1825 | 服务连续性管理通过确保在灾难或危机之后,能够在所需和约定的业务时间范围内恢复IT和服务,从而支持整体业务连续性管理(BCM)和规划能力。当服务中断或组织风险发生的规模大于组织通过正常响应和恢复实践(如事件和重大事件管理)处理该风险的能力时,就会触发它。这种规模的组织事件通常被称为灾难。 | ||
1826 | |||
1827 | |||
1828 | 每个组织都需要了解在自身背景下什么构成了灾难。在组织和每个服务级别的触发事件之前,必须使用业务影响分析来考虑和定义灾难的含义。业务连续性研究所将灾难定义为: | ||
1829 | |||
1830 | >“对组织造成巨大破坏或严重损失的突发性意外事件。这会导致组织无法在预定的最短时间内提供关键业务功能。” | ||
1831 | |||
1832 | 引发灾害响应和恢复的来源是多种多样和复杂的,利益干系人的数量和潜在组织影响的不同方面也是如此。表5.3的例子所涉及的风险管理情况十分复杂,因此必须全面考虑服务连续性管理实践,设计灵活性并定期测试,以确保能够以业务生存所需的速度恢复服务。 | ||
1833 | |||
1834 | |||
1835 | 表5.3灾害来源,利益相关者和组织影响的示例 | ||
1836 | |||
1837 | |**灾难来源**|**涉及的利益相关者**|**组织影响** | ||
1838 | |供应链故障|员工|收入损失 | ||
1839 | |恐怖主义|经理|名誉受损 | ||
1840 | |天气|理事机构|丧失竞争优势 | ||
1841 | |网络攻击|供应商|违反法律、健康和安全法规 | ||
1842 | |卫生紧急事件|IT团队|人身安全风险 | ||
1843 | |政治或经济事件|客户|市场份额的短期和长期损失 | ||
1844 | |技术故障|用户| | ||
1845 | |公共危机|社区| | ||
1846 | |||
1847 | (% class="box warningmessage" %) | ||
1848 | ((( | ||
1849 | **定义:** | ||
1850 | |||
1851 | * **恢复时间目标(RTO) 当一个**服务中断后,在缺乏业务功能并严重影响组织之前,能够接受的最长时间。这表示产品或活动必须恢复或资源必须恢复的最大约定时间。 | ||
1852 | * **恢复点目标(RPO) **必须将活动使用的信息还原到该点,以使该活动能够在恢复时运行。 | ||
1853 | * **灾难恢复计划 **一组明确定义的计划,涉及组织如何从灾难中恢复并恢复到灾难前的状态,考虑到服务管理的四个方面。 | ||
1854 | * **业务影响分析(BIA) **服务连续性管理实践中的一项关键活动,用于识别重要业务功能(VBF)及其依赖关系。这些依赖关系可能包括供应商、人员、其他业务流程和IT服务。 BIA定义了IT服务的恢复要求。这些要求包括RTO、RPO和每个IT服务的最低服务级别目标。 | ||
1855 | ))) | ||
1856 | |||
1857 | (% class="box" %) | ||
1858 | ((( | ||
1859 | **Tips:服务连续性管理与事件管理** | ||
1860 | |||
1861 | 服务连续性管理聚焦于业务认为足以被视为灾难的那些事件(event)。不太重要的事件作为事件管理或重大事件管理的一部分进行处理。灾难、重大事件和事件之间的区别需要预先定义、约定和记录,并具有明确的阈值和触发因素,以便在没有不必要的延迟和风险的情况下,调用下一级响应和恢复行动。 | ||
1862 | ))) | ||
1863 | |||
1864 | |||
1865 | 随着组织越来越依赖于技术支持的服务,对高可用性解决方案的需求已成为组织的恢复力和竞争力的关键。组织通过结合业务规划、技术架构弹性、可用性规划、主动风险和信息安全管理,以及事件管理和问题管理来实现高可用性。 | ||
1866 | |||
1867 | |||
1868 | 图5.31显示了服务连续性管理对服务价值链的贡献,该实践涉及所有价值链活动: | ||
1869 | |||
1870 | * **计划:**组织的领导层和管理机构为组织建立初始风险偏好,并确定范围、策略、供应商战略和恢复选项投资。服务连续性管理通过关于组织当前连续性状态的相关信息以及用于规划和预测的工具和方法来支持此功能。 | ||
1871 | * **改进:**服务连续性管理确保持续监控和改进连续性计划、措施和机制,以适应不断变化的内部和外部环境。 | ||
1872 | * **契动:**该实践支持与各利益干系人合作,为组织应对灾难的准备提供保障。 | ||
1873 | * **设计和转换:**服务连续性管理确保产品和服务按照组织的连续性要求设计和测试。 | ||
1874 | * **获取/构建:**服务连续性管理确保组织的服务和组件具有连续性,并且采购的组件和服务满足组织的连续性需求。 | ||
1875 | * **交付和支持:**根据连续性需求和策略进行持续交付、操作和支持。 | ||
1876 | |||
1877 | (% style="text-align:center" %) | ||
1878 | [[image:1640355641334-979.png]] | ||
1879 | |||
1880 | 图5.31服务连续性管理对价值链活动的贡献热力图 | ||
1881 | |||
1882 | |||
1883 | === **5.2.13 服务设计** === | ||
1884 | |||
1885 | |||
1886 | (% class="box infomessage" %) | ||
1887 | ((( | ||
1888 | **关键信息:** | ||
1889 | |||
1890 | 服务设计实践的目的是设计符合目的、适合使用,并且能够由组织及其生态系统交付的产品和服务。这包括规划和组织人员、合作伙伴和供应商、信息、沟通、技术和新的或变更的产品和服务的实践,以及组织与客户之间的交互。 | ||
1891 | ))) | ||
1892 | |||
1893 | |||
1894 | 如果产品、服务或实践设计不当,它们就不一定能满足客户需求或促进价值创造。如果它们在没有适当的架构、接口或控制的情况下发展,它们就无法满足组织及其内部和外部客户的整体愿景和需求。 | ||
1895 | |||
1896 | |||
1897 | 即使精心设计了产品或服务,也很难以经济高效且具有弹性的方式提供满足组织和客户需求的解决方案。因此,考虑使用迭代和增量的方法进行服务设计是很重要的,这可以确保引入有效操作的产品和服务能够不断适应组织及其客户不断变化的需求。 | ||
1898 | |||
1899 | |||
1900 | 在没有正式的服务设计的情况下,产品和服务的运行成本可能过高,并且容易出现故障,从而导致资源浪费,产品或服务不是以客户为中心或进行整体设计。任何改进计划都不太可能达到最初正确设计所能达到的效果。如果没有服务设计,那么提供满足客户需求和期望的高性价比的产品和服务将非常难以实现。 | ||
1901 | |||
1902 | |||
1903 | 服务设计实践还应确保客户从需求到价值实现的过程尽可能愉快和顺畅,并尽可能提供最佳的客户成果。这是通过关注客户体验(CX)和用户体验(UX)来实现的。 | ||
1904 | |||
1905 | |||
1906 | 采用并实施以CX和UX为重点的服务设计实践将: | ||
1907 | |||
1908 | * 产生以客户为中心的产品和服务,包括设计活动中的利益干系人 | ||
1909 | * 考虑产品或服务的整个环境 | ||
1910 | * 使项目能够更准确地估算与服务设计相关的成本、时间、资源需求和风险 | ||
1911 | * 导致更高的成功变更数量 | ||
1912 | * 使设计方法更易于人们采用和遵循 | ||
1913 | * 使服务设计资产能够在项目和服务之间共享和重用 | ||
1914 | * 增强对新产品或服务可以按规范交付而不会意外影响其他产品、服务或利益干系人的信心 | ||
1915 | * 确保新的或变更的产品和服务将可维护且具有成本效益。 | ||
1916 | |||
1917 | 重要的是,对服务设计的所有方面采用一种整体的、以结果为导向的方法,并且在变更或修改服务设计的任何单个元素时,要考虑到所有其他方面。正是由于这个原因,服务设计与整个组织的SVS的协调方面是必不可少的。设计和开发新的或变更的产品或服务不应孤立地进行,而应考虑它将对以下方面产生的影响: | ||
1918 | |||
1919 | * 其他产品和服务 | ||
1920 | * 所有相关方,包括客户和供应商 | ||
1921 | * 现有架构 | ||
1922 | * 所需技术 | ||
1923 | * 服务管理实践 | ||
1924 | * 必要的度量和指标。 | ||
1925 | |||
1926 | 考虑这些因素不仅可以确保设计满足服务的功能要素,还可以确保管理和操作需求被视为设计的基本部分,而不是作为事后的想法添加。 | ||
1927 | |||
1928 | |||
1929 | 当对产品或服务进行的变更退出时,也应使用服务设计。除非精心计划产品/服务的退役,否则可能会对客户或组织产生意外的负面影响,而这些影响本来是可以避免的。 | ||
1930 | |||
1931 | |||
1932 | 并非每次对产品或服务的变更都需要相同级别的服务设计活动。每一个变更,无论多么小,都需要一定程度的设计工作,但确保成功所必需的活动规模将因变更类型不同而有很大的差异。组织必须定义每一类变更所需的设计活动级别,并确保组织内的每个人都清楚这些标准。 | ||
1933 | |||
1934 | |||
1935 | 服务设计支持这样的产品和服务: | ||
1936 | |||
1937 | * 以业务和客户为导向,专注并驱动 | ||
1938 | * 具有成本效益 | ||
1939 | * 满足组织和任何外部客户的信息和物理安全要求 | ||
1940 | * 具有灵活性和适应性,但在交付时适合用途 | ||
1941 | * 可以吸收变化量和变化速度不断增长的需求 | ||
1942 | * 满足不断增加的组织和客户对连续运营的需求 | ||
1943 | * 在可接受的风险水平上进行管理和运营。 | ||
1944 | |||
1945 | 由于对组织的压力很大,在协调实践和服务设计活动的相关方面时,可能会有一种“偷工减料”的诱惑,或者完全忽略它们。应该避免这种情况,因为整合和协调对于所交付的产品和服务的整体质量至关重要。 | ||
1946 | |||
1947 | |||
1948 | ==== **5.2.13.1 设计思维** ==== | ||
1949 | |||
1950 | 设计思维是一种实用的,以人为本的方法,可以加速创新。产品和服务设计人员以及组织使用它来解决复杂问题,并找到满足组织及其客户需求的实用、创造性解决方案。它可以被视为精益和敏捷方法的补充方法。设计思维利用逻辑、想象力、直觉和系统思维来探索可能性,并创造有利于客户的预期成果。 | ||
1951 | |||
1952 | |||
1953 | 设计思维包括一系列活动: | ||
1954 | |||
1955 | * 通过直接观察人员以及他们如何工作或与产品和服务交互,以及识别他们如何与其他解决方案进行不同的互动,可以获得灵感和同理心。 | ||
1956 | * 构思,即发散性思维和收敛性思维的结合。发散性思维是提供不同的、独特的或不同想法的能力,而收敛性思维是为给定问题找到首选解决方案的能力。发散性思维确保了许多可能的解决方案被探索,而收敛性思维将这些方案缩小到最终的首选解决方案。 | ||
1957 | * 原型设计,即对这些想法进行早期测试、迭代和改进。原型有助于收集反馈并改进想法。原型允许服务设计人员更好地理解新解决方案的优缺点,从而加快了创新的过程。 | ||
1958 | * 实施,将概念变为现实。这应与所有相关的服务管理实践和其他各方进行协调。可以采用敏捷方法以迭代方式开发和实现解决方案。 | ||
1959 | * 评价(与其他实践相结合,包括项目管理和发布管理)度量产品或服务实施的实际绩效,以确保满足验收标准,并找到任何改进机会。 | ||
1960 | |||
1961 | 设计思维最好由多学科团队应用;因为它平衡了客户、技术、组织、合作伙伴和供应商的观点,所以它具有很高的集成度,与组织的SVS保持一致,并且可以成为数字化转型的关键促成因素。 | ||
1962 | |||
1963 | |||
1964 | ==== **5.2.13.2 客户和用户体验** ==== | ||
1965 | |||
1966 | 服务设计的客户体验和用户体验方面对于确保产品和服务为客户和组织提供所需价值至关重要。客户体验设计专注于管理整个客户体验的各个方面,包括时间、质量、成本、可靠性和有效性。用户体验特别关注产品或服务的易用性以及客户如何与之交互。 | ||
1967 | |||
1968 | |||
1969 | (% class="box" %) | ||
1970 | ((( | ||
1971 | **精益用户体验:** | ||
1972 | |||
1973 | 精益用户体验(精益用户体验)设计是一种思维模式、一种文化和一种包含精益敏捷方法的过程。它以最小可行增量实现功能,并通过针对成果假设测量结果来确定成功。精益用户体验在使用敏捷开发方法的项目中非常有用。核心目标是集中精力尽早获得反馈,以便能够用于快速决策。 | ||
1974 | |||
1975 | |||
1976 | 精益用户体验的典型问题可能包括:该产品/服务的客户是谁,它将用于什么?什么时候使用,在什么情况下使用?最重要的功能是什么?最大的风险是什么? | ||
1977 | |||
1978 | |||
1979 | 每个问题可能有不止一个答案,这会产生比实际处理的更多假设。然后,团队将根据这些假设对组织及其客户所代表的风险确定优先顺序。 | ||
1980 | ))) | ||
1981 | |||
1982 | |||
1983 | |||
1984 | (% style="text-align:center" %) | ||
1985 | [[image:1640355712635-967.png]] | ||
1986 | |||
1987 | 图5.32服务设计对价值链活动的贡献热力图 | ||
1988 | |||
1989 | |||
1990 | 风险识别、评估和处理是所有设计活动的关键要求;因此,风险管理必须作为服务设计的一个集成方面。这将确保产品和服务的提供以及实践、技术和测量方法的操作所涉及的风险与组织风险和影响相一致,因为风险管理嵌入到所有设计过程和活动中。 | ||
1991 | |||
1992 | |||
1993 | 图5.32显示了服务设计对服务价值链的贡献,该实践涉及所有价值链活动: | ||
1994 | |||
1995 | * **计划:**服务设计实践包括计划和组织人员、合作伙伴和供应商、新的或变更的产品和服务的信息、沟通、技术和实践,以及组织与客户之间的互动。 | ||
1996 | * **改进:**服务设计可用于改进现有服务以及从头开始创建新服务。服务可以设计为最低可行的服务、部署,然后迭代和改进,以根据反馈增加更多价值。 | ||
1997 | * **契动:**服务设计融合了客户体验和用户体验,这是契动的典型例子。 | ||
1998 | * **设计和转换:**服务设计的目的是设计易于使用,令人满意并且能够由组织交付的产品和服务。 | ||
1999 | * **获取/构建:**服务设计包括识别需要为新服务或变更服务获取或构建的产品、服务和服务组件。 | ||
2000 | * **交付和支持:**服务设计通过服务的运行、恢复和维护来管理用户的全程。 | ||
2001 | |||
2002 | |||
2003 | |||
2004 | === **5.2.14 服务台** === | ||
2005 | |||
2006 | |||
2007 | (% class="box infomessage" %) | ||
2008 | ((( | ||
2009 | **关键信息:** | ||
2010 | |||
2011 | 服务台实践的目的为事件解决和服务请求捕获需求。它还应该是服务提供者及其所有用户的入口点和单点联系人。 | ||
2012 | ))) | ||
2013 | |||
2014 | |||
2015 | 服务台为用户报告问题、查询和请求提供了一个清晰的途径,并使它们得到确认、分类、拥有和执行。管理和交付这种做法的方式可能有所不同,从轮班工作的实际团队到虚拟连接的分布式组合,或自动化技术和机器人。无论模式如何,职能和价值都保持不变。 | ||
2016 | |||
2017 | |||
2018 | 随着自动化程度的提高和技术债务的逐步消除,服务台的重点是为“人员和业务”提供支持,而不仅仅是技术问题。服务台越来越多地被用来安排、解释和协调各种事务,而不仅仅是为了修复损坏的技术,服务台已成为任何服务操作的重要部分。 | ||
2019 | |||
2020 | |||
2021 | 需要理解的一个关键点是,无论服务台及其人员的效率如何,总会存在需要升级的问题以及其他团队的支持。支持和开发团队需要与服务台密切合作,向用户和客户展示并提供“联合”方法。 | ||
2022 | |||
2023 | |||
2024 | 服务台可能不需要很高的技术含量,尽管有些技术含量很高。然而,即使服务台相当简单,它仍然在服务的交付中扮演着重要的角色,并且必须得到其同行团队的积极支持。同样重要的是要理解服务台对用户体验和用户如何看待服务提供者的重大影响。 | ||
2025 | |||
2026 | |||
2027 | 一个好的服务台的另一个关键方面是对更广泛的业务环境、业务流程和用户的实际理解。服务台不仅通过事务行为(例如,事件记录)来增加价值,而且还通过理解和处理此操作的业务背景来增加价值。服务台应该是服务提供者与其用户之间共情和知会的连接。 | ||
2028 | |||
2029 | |||
2030 | 随着自动化、人工智能、机器人流程自动化(RPA)和聊天机器人的增加,服务台正在通过在线门户和移动应用程序直接提供更多自助式日志记录和解决方案。对服务台的影响是减少电话联系,减少初级工作,以及在需要个人联系时更好地专注于优秀的CX。 | ||
2031 | |||
2032 | |||
2033 | 服务台提供了各种访问渠道。这些包括: | ||
2034 | |||
2035 | * 电话呼叫,包括专业技术,如交互式语音应答(IVR)、电话会议、语音识别等 | ||
2036 | * 服务门户和移动应用程序,支持服务和请求目录以及知识库 | ||
2037 | * 聊天,通过在线聊天和聊天机器人 | ||
2038 | * 电子邮件,用于记录和更新,以及后续调查和确认。非结构化电子邮件可能难以处理,但基于AI和机器学习的新兴技术正在开始解决这个问题 | ||
2039 | * 现场服务台在某些领域变得越来越普遍,例如高等教育,那里的活动高峰需要有人到现场 | ||
2040 | * 文本和社交媒体消息,在发生重大事件时,用于通知和联系特定的利益相关者,但也可用于允许用户请求支持 | ||
2041 | * 公共和企业社交媒体和论坛,用于联系服务提供者和点对点支持。 | ||
2042 | |||
2043 | 一些服务台有一个有限的支持窗口来提供范围内服务可用(例如,周一至周五的08:00-20:00)。因此,工作人员应以轮班方式工作,以提供一致的支持水平。 | ||
2044 | |||
2045 | |||
2046 | 在某些情况下,服务台是一个有形的团队,在一个地方工作。集中式服务台需要支持的技术,例如: | ||
2047 | |||
2048 | * 智能电话系统,包括计算机电话集成、IVR和自动呼叫分配 | ||
2049 | * 用于路由和升级的工作流系统 | ||
2050 | * 劳动力管理和资源规划系统 | ||
2051 | * 知识库 | ||
2052 | * 通话录音和质量控制 | ||
2053 | * 远程访问工具 | ||
2054 | * 仪表板和监控工具 | ||
2055 | * 配置管理系统。 | ||
2056 | |||
2057 | 在其他情况下,虚拟服务台允许代理在地理位置分散的多个位置工作。虚拟服务台需要更复杂的支持技术,涉及更复杂的路由和升级;这些解决方案通常基于云的。 | ||
2058 | |||
2059 | |||
2060 | (% style="text-align:center" %) | ||
2061 | [[image:1640355762299-384.png]] | ||
2062 | |||
2063 | 图5.33服务台对价值链活动的贡献热力图 | ||
2064 | |||
2065 | |||
2066 | 服务台工作人员需要在多个广泛的技术和业务领域接受培训并具备相应的能力。特别是,他们需要展示优秀的客户服务技能,如同理心、事件分析和优先级、有效沟通和情商。关键技能是能够充分理解和诊断业务优先级方面的特定事件,并使用可用的技能、知识、人员和流程采取适当的行动解决此问题。 | ||
2067 | |||
2068 | |||
2069 | 图5.33显示了服务台对服务价值链的贡献,该实践涉及除计划活动之外的所有价值链活动: | ||
2070 | |||
2071 | * **改进:**持续监控和评估服务台活动,以支持持续改进、调整和创造价值。服务台收集用户的反馈,以支持持续改进。 | ||
2072 | * **契动:**服务台是与用户进行战术和运营契动的主要渠道。 | ||
2073 | * **设计和转换:**服务台提供了一个与用户沟通新的和变更服务的渠道。服务台员工参与发布计划、测试和前期支持。 | ||
2074 | * **获取/构建:**服务台员工可以参与获取用于完成服务请求和解决事件的服务组件。 | ||
2075 | * **交付和支持:**服务台是管理事件和服务请求的协调点。 | ||
2076 | |||
2077 | |||
2078 | |||
2079 | |||
2080 | === **5.2.15 服务级别管理** === | ||
2081 | |||
2082 | |||
2083 | (% class="box infomessage" %) | ||
2084 | ((( | ||
2085 | **关键信息:** | ||
2086 | |||
2087 | 服务级别管理实践的目的是为服务级别设置明确的基于业务的目标,并确保针对这些目标正确评估,监视和管理服务交付。 | ||
2088 | ))) | ||
2089 | |||
2090 | |||
2091 | (% class="box warningmessage" %) | ||
2092 | ((( | ||
2093 | **定义:服务级别** | ||
2094 | |||
2095 | 定义预期或实现的服务质量的一个或多个指标。 | ||
2096 | ))) | ||
2097 | |||
2098 | |||
2099 | 服务级别管理提供组织服务的端到端可见性。为实现这一目标,服务级别管理: | ||
2100 | |||
2101 | * 与客户建立服务和目标服务级别的共享视图 | ||
2102 | * 通过收集、分析、存储和报告已识别服务的相关指标,确保组织满足定义的服务级别 | ||
2103 | * 执行服务评审,以确保当前的服务连续性满足组织及其客户的要求 | ||
2104 | * 捕获和报告服务问题,包括针对定义的服务级别的绩效。 | ||
2105 | |||
2106 | 服务级别管理的技能和能力包括关系管理、业务联络、业务分析和商业/供应商管理。此实践要求以实用的方式关注整个服务,而不是仅仅关注其组成部分;例如,不应采用简单的单个指标(例如系统可用性百分比)来表示整个服务。 | ||
2107 | |||
2108 | |||
2109 | ==== **5.2.15.1 服务级别协议** ==== | ||
2110 | |||
2111 | |||
2112 | (% class="box warningmessage" %) | ||
2113 | ((( | ||
2114 | **定义:服务级别协议** | ||
2115 | |||
2116 | 服务提供者与客户之间的书面协议,确定所需的服务和预期的服务级别。 | ||
2117 | ))) | ||
2118 | |||
2119 | |||
2120 | 服务级别协议(SLA)长期以来一直被用作从客户的角度度量服务绩效的工具,并且在更广泛的业务环境中达成一致意见非常重要。使用SLA可能会带来许多挑战;通常它们不能完全反映更广泛的服务性能和用户体验。 | ||
2121 | |||
2122 | |||
2123 | 成功SLA的一些关键要求包括: | ||
2124 | |||
2125 | * 它们必须与服务目录中定义的“服务”相关;否则它们只是没有目的的单个指标,不能提供足够的可见性或反映服务的观点。 | ||
2126 | * 它们应与确定的结果相关,而不仅仅是运营的指标。这可以通过平衡的指标组合来实现,例如客户满意度和关键业务结果。 | ||
2127 | * 它们应反映“协议”,即服务提供者和服务消费者之间的契动和讨论。让所有的利益相关者都参与进来是非常重要的,包括合作伙伴、赞助人、用户和客户。 | ||
2128 | * 书写必须简单,便于各方理解和使用。 | ||
2129 | |||
2130 | 在许多情况下,使用基于单一系统的指标作为目标可能会导致服务合作伙伴之间在服务交付的成功和用户体验方面出现偏差和脱节。例如,如果SLA仅基于服务的正常运行时间百分比,那么提供者可以认为它是成功的,但这样会错过对消费者非常重要的重要业务功能和结果。这被称为“西瓜SLA”效应。 | ||
2131 | |||
2132 | |||
2133 | (% class="box" %) | ||
2134 | ((( | ||
2135 | **西瓜SLA效应:** | ||
2136 | |||
2137 | 传统SLA基于单独活动,例如事件解决时间、系统可用性('99.9')和容量指标(例如,事件或请求处理的数量)。如果没有业务环境,这些指标通常毫无意义。例如,虽然系统可用性99.6%令人印象深刻,但这仍然需要与关键业务要求保持一致。系统可能有一个可接受的不可用的0.4%,但如果在发生重要流程(例如商业交易,使用中的手术室或使用中的销售终端)时,则无论是否满足SLA,客户/用户满意度都将很低。 | ||
2138 | |||
2139 | |||
2140 | 如果服务提供者认为自己做得很好(报告都是绿色的),而实际上客户对收到的服务不满意,并且对提供者没有注意到这一点感到沮丧,那么对于服务提供者来说这可能是个问题。这就是所谓的西瓜SLA效应,因为像西瓜一样,SLA可能在外面看起来是绿色的,但实际上里面是红色的。 | ||
2141 | |||
2142 | |||
2143 | 服务级别管理确定的指标和措施是真实反映客户的真实体验和对整个服务的满意程度。这些因组织而异,了解这些内容的唯一方法是直接从客户那里找到。 | ||
2144 | ))) | ||
2145 | |||
2146 | |||
2147 | 服务级别管理需要专注和努力,以契动和倾听客户的要求、问题、顾虑和日常需求: | ||
2148 | |||
2149 | * 契动需要理解和确认客户的实际进行中的需求和要求,而不是简单的理解服务提供者的解释或几年前达成的协议。 | ||
2150 | * 倾听作为建立关系和建立信任的重要活动,可以向客户展示他们的评估和理解。这有助于使提供者摆脱总是处于“解决方案模式”的状态,并建立新的、更具建设性的合作伙伴关系。 | ||
2151 | |||
2152 | 契动和倾听的活动为建立更好的关系和关注真正需要交付的内容提供了一个极好的机会。它还让服务交付人员以体验为基础了解他们的技术所完成的日常工作,使他们能够提供更加以业务为中心的服务。 | ||
2153 | |||
2154 | |||
2155 | 服务级别管理涉及整理和分析来自多个来源的信息,包括: | ||
2156 | |||
2157 | * **客户契动Customer engagement** 这包括初始的倾听、发现和信息捕获,以此为基础进行指标、度量和正在进行的进度讨论。考虑向客户询问一些简单的开放式问题,例如: | ||
2158 | ** 您的工作涉及什么? | ||
2159 | ** 技术如何帮助您? | ||
2160 | ** 您的主要业务时间、地域、人员和活动是什么? | ||
2161 | ** 在您看来,美好的一天与糟糕的一天有什么区别? | ||
2162 | ** 哪些活动对您最重要? | ||
2163 | ** 您今年的目的、目标和度量标准是什么? | ||
2164 | ** 度量你成功的最佳标准是什么? | ||
2165 | ** 您对服务或IT/技术的看法和评价是建立在什么基础上的? | ||
2166 | ** 我们如何为您提供更多帮助? | ||
2167 | |||
2168 | * **客户反馈** 最好是从正式和非正式的多个来源收集,包括: | ||
2169 | ** **调查** 这些调查可以来自即时反馈,如事件的后续问题,也可以来自更具反思性的定期调查,以衡量对整体服务体验的反馈。两者都是基于事件的。 | ||
2170 | ** **与业务相关的度量 **这些是服务提供商与其客户之间根据客户认为重要的东西商定的措施。这可能是一系列SLA指标,也可能是一项非常具体的业务活动,例如销售交易、项目完成、或运营功能,例如在x分钟内将救护车送到事故现场。 | ||
2171 | * **运行指标** 这些是各种运行活动的初级指标,可能包括系统可用性、事件响应和修复时间、变更和请求处理时间以及系统响应时间。 | ||
2172 | * **业务指标** 这些指标可以是客户认为有用或有价值的任何业务活动,并用作衡量服务成功与否的方法。这些可能会有一些简单的交易二元测量,例如工作时间(每天09:00-17:00)的ATM或POS终端可用性,或成功完成乘客登记等业务活动。 | ||
2173 | |||
2174 | 收集并整理此反馈以供持续审核,就可以将其用作设计适当的度量和报告模型和实践的输入。 | ||
2175 | |||
2176 | |||
2177 | 图5.34显示了服务级别管理对服务价值链的贡献,其实践主要应用于计划和契动活动: | ||
2178 | |||
2179 | * **计划:**服务级别管理支持产品和服务组合及服务供应的规划,以及有关实际服务绩效和趋势的信息。 | ||
2180 | * **改进:**来自用户的服务反馈以及客户的要求,可以成为服务改进的驱动力。 | ||
2181 | * **契动:**服务级别管理通过反馈处理和持续服务审核确保与客户和用户的持续契动。 | ||
2182 | * **设计和过渡:**新的和变更的服务的设计和开发通过与客户的互动和作为过渡中的反馈循环的一部分,从这种实践中获得输入。 | ||
2183 | * **获取/构建:**服务级别管理提供了组件和服务绩效的目标,以及产品和服务的度量和报告能力。 | ||
2184 | * **交付和支持:**服务级别管理将服务绩效目标传达给运营和支持团队,并收集他们的反馈作为服务改进的输入。 | ||
2185 | |||
2186 | (% style="text-align:center" %) | ||
2187 | [[image:1640355949723-158.png]] | ||
2188 | |||
2189 | 图5.34服务级别管理对价值链活动的贡献热力图 | ||
2190 | |||
2191 | |||
2192 | (% class="box" %) | ||
2193 | ((( | ||
2194 | **ITIL故事:艾克苏的服务级别管理** | ||
2195 | |||
2196 | **苏:**我们定期收集客户的反馈意见,分析他们的要求和需求,并更新我们的服务供应,以满足他们的期望。 | ||
2197 | |||
2198 | **拉迪卡:**我们不能把每个客户的期望都写到我们的租赁协议中,但我们关心所有的客户,并尽我们最大的努力满足他们。 | ||
2199 | |||
2200 | **苏:**我们还监控合作伙伴和供应商提供的服务质量,例如克雷格保洁为我们所做的工作。在这样做时,我们需要确保我们服务的每个部分的质量都达到或超过我们用户的期望。 | ||
2201 | ))) | ||
2202 | |||
2203 | |||
2204 | |||
2205 | === **5.2.16 服务请求管理** === | ||
2206 | |||
2207 | |||
2208 | (% class="box infomessage" %) | ||
2209 | ((( | ||
2210 | **关键信息:** | ||
2211 | |||
2212 | 服务请求管理实践的目的是通过以有效和用户友好的方式处理所有预定义的、用户发起的服务请求,以此来支持约定的服务质量。 | ||
2213 | ))) | ||
2214 | |||
2215 | |||
2216 | (% class="box warningmessage" %) | ||
2217 | ((( | ||
2218 | **定义:服务请求** | ||
2219 | |||
2220 | 来自用户或用户授权代表的请求,该请求发起已被同意为服务交付中正常部分的服务动作。 | ||
2221 | ))) | ||
2222 | |||
2223 | |||
2224 | 每个服务请求可能包括以下一项或多项: | ||
2225 | |||
2226 | * 服务交付动作的请求(例如,提供报告或更换墨盒) | ||
2227 | * 信息的请求(例如,如何创建文档或询问办公的时间) | ||
2228 | * 提供资源或服务的请求(例如,向用户提供电话或笔记本电脑,或为开发团队提供虚拟服务器) | ||
2229 | * 访问资源或服务的请求(例如,提供对文件或文件夹的访问) | ||
2230 | * 反馈、表扬和投诉(例如,对新界面的投诉或对支持团队的称赞)。 | ||
2231 | |||
2232 | 服务请求的实现可能包括对服务或其组件的变更;通常这些是标准变更。服务请求是服务交付中的一个正常部分,而不是作为事件处理的服务失败或降级。由于服务请求是预先定义和预先约定的,是服务交付的正常组成部分,因此它们通常可以通过一个清晰的、标准的启动、批准、履行和管理程序将其正式化。有些服务请求具有非常简单的工作流,例如信息请求。其他的,例如新员工的设置,可能非常复杂,需要许多团队和系统的贡献才能实现。无论复杂程度如何,实现请求的步骤都应该是众所周知的。这使得服务提供者能够就实现时间达成一致,并向用户提供请求状态的清晰沟通。 | ||
2233 | |||
2234 | |||
2235 | 一些服务请求需要根据财务、信息安全或其他策略进行授权,而其他服务请求可能不需要任何授权。要成功处理,服务请求管理应遵循以下准则: | ||
2236 | |||
2237 | * 服务请求及其履行应尽可能标准化和自动化。 | ||
2238 | * 应制定策略,确定哪些服务请求将在有限或甚至不需要额外批准的情况下得到满足,以便简化履行。 | ||
2239 | * 应根据组织实际能交付的内容,明确设定用户对履行时间的期望 | ||
2240 | * 应确定并实施改进机会,以缩短履行时间并利用自动化。 | ||
2241 | * 应包括策略和工作流,以记录和重定向作为服务请求提交的任何请求,但实际上应作为事件或变更进行管理。 | ||
2242 | |||
2243 | (% style="text-align:center" %) | ||
2244 | [[image:1640356004174-576.png]] | ||
2245 | |||
2246 | 图5.35服务请求管理对价值链活动的贡献热力图 | ||
2247 | |||
2248 | |||
2249 | 有些服务请求可以从提交到关闭完全通过自动化实现,从而实现完全的自助服务体验。示例包括客户端软件安装或虚拟服务器的提供。 | ||
2250 | |||
2251 | |||
2252 | 服务请求管理依赖于精心设计的流程和规程,这些流程和规程通过跟踪和自动化工具实现,以最大限度地提高实践效率。不同类型的服务请求将具有不同的履行工作流,但是如果识别出有限数量的工作流模型,则将提高效率和可维护性。当需要将新服务请求添加到服务目录中时,应尽可能利用现有工作流模型。 | ||
2253 | |||
2254 | 图5.35显示了服务请求管理对服务价值链的贡献,除了计划活动之外,所有服务价值链活动都涉及该实践: | ||
2255 | |||
2256 | * **改进**:服务请求管理可以为用户提供改进计划、表扬和投诉的渠道。它还通过提供有关请求履行的趋势、质量和反馈信息来促进改进。 | ||
2257 | * **契动:**服务请求管理包括定期沟通,以收集用户特定要求、设置期望并提供状态更新。 | ||
2258 | * **设计和转换:**标准服务组件可以通过服务请求实现转换到生产环境。 | ||
2259 | * **获取/构建:**可以通过服务请求来完成对预先批准的服务组件的获取。 | ||
2260 | * **交付和支持:**服务请求管理为正常的服务交付做出了重大贡献。价值链的这种活动主要关注的是确保用户继续保持高效,有时还很大程度上取决于他们的要求是否得到满足。 | ||
2261 | |||
2262 | |||
2263 | |||
2264 | === **5.2.17 服务验证和测试** === | ||
2265 | |||
2266 | |||
2267 | (% class="box infomessage" %) | ||
2268 | ((( | ||
2269 | **关键信息:** | ||
2270 | |||
2271 | 服务验证和测试实践的目的是确保新的或变更的产品和服务满足定义的要求。服务价值的定义是基于来自客户、业务目标和监管要求的输入,并作为设计和转换的价值链活动的一部分被记录下来的。这些输入用于建立可度量的质量和绩效指标,以支持对保证标准和测试要求的定义。 | ||
2272 | ))) | ||
2273 | |||
2274 | |||
2275 | ==== **5.2.17.1 服务验证** ==== | ||
2276 | |||
2277 | 服务验证聚焦于建立部署和发布管理验收标准(生产就绪必须满足的条件),这些标准通过测试进行验证。验收标准可以是以功用或功效为重点,并通过理解客户、法规、业务、风险管理和安全需求来定义。 | ||
2278 | |||
2279 | 该实践的服务验证活动建立、验证和记录以功用和功效为重点的服务保证标准,并构成测试活动范围和重点的基础。 | ||
2280 | |||
2281 | |||
2282 | ==== **5.2.17.2 测试** ==== | ||
2283 | |||
2284 | 测试策略定义了测试的总体方法。它可以应用于环境、平台、一组服务或单个服务。测试应该在内部开发的系统和外部开发的解决方案上平等地进行。测试策略基于服务验收标准,并应与相应的利益干系人的要求保持一致,以确保测试符合风险偏好并且符合目的。 | ||
2285 | |||
2286 | |||
2287 | 典型的测试类型包括: | ||
2288 | |||
2289 | * 功用/功能测试: | ||
2290 | ** **单元测试** 对单个系统组件的测试 | ||
2291 | ** **系统测试** 系统的整体测试,包括软件和平台 | ||
2292 | ** **集成测试** 同时测试一组相关的软件模块 | ||
2293 | ** **回归测试** 测试以前的工作功能是否受到影响。 | ||
2294 | * 功效/非功能测试: | ||
2295 | ** **性能和容量测试** 检查负载下的速度和容量 | ||
2296 | ** **安全性测试** 测试漏洞、策略合规性、渗透率和拒绝服务风险 | ||
2297 | ** **符合性测试** 检查是否符合法律和法规要求 | ||
2298 | ** **操作测试Operational test** 用于备份、事态监控、故障切换、恢复和报告的测试 | ||
2299 | ** **功效要求测试** 检查必要文档、培训、支持模型定义和知识转移的验证 | ||
2300 | ** **用户验收测试** 由新系统或已变更系统的用户执行的用于批准发布的测试。 | ||
2301 | |||
2302 | 图5.36显示了服务验证和测试对服务价值链的贡献,该实践涉及除计划活动之外的所有价值链活动: | ||
2303 | |||
2304 | * **改进:**服务验证和测试的指标,例如逃逸缺陷、测试覆盖率和针对SLA的服务绩效,是改善CX和降低风险所需的关键成功措施。 | ||
2305 | * **契动:**让一些利益干系人参与服务验证和测试活动,有助于契动并提高服务的可见性和采用率。 | ||
2306 | * **设计和转换:**服务设计、知识管理、性能管理、部署管理和发布管理都与服务验证和测试实践紧密集成。 | ||
2307 | * **获取/构建:**服务验证和测试活动与从外部服务提供者获取服务相关的所有实践,以及瀑布式和敏捷方法中的项目管理和软件开发活动密切相关。 | ||
2308 | * **交付和支持:**服务验证和测试捕获已知错误,并与服务台和事件管理实践共享,以实现更快的服务恢复时间表。同样,有关服务中断或逃逸缺陷的信息也会反馈到服务验证和测试中,以提高验收标准和测试活动的有效性和覆盖范围。 | ||
2309 | |||
2310 | 图5.36服务验证和测试对价值链活动的贡献热力图 | ||
2311 | |||
2312 | [[image:1659339464364-725.png]] | ||
2313 | |||
2314 | |||
2315 | == **5.3 技术管理实践** == | ||
2316 | |||
2317 | |||
2318 | === **5.3.1 部署管理** === | ||
2319 | |||
2320 | |||
2321 | (% class="box infomessage" %) | ||
2322 | ((( | ||
2323 | **关键信息:** | ||
2324 | |||
2325 | 部署管理实践的目的是将新的或变更的硬件、软件、文档、流程或任何其他组件转移动到生产环境中。它还可能涉及将组件部署到其他环境以进行测试或仿真。 | ||
2326 | ))) | ||
2327 | |||
2328 | |||
2329 | 部署管理与发布管理和变更控制密切配合,但其本身是一个单独的实践。在某些组织中,术语“配置(provisioning)”用于描述基础设施的部署,而部署(deployment)仅用于表示软件部署,但在这种情况下,术语“部署”用于同时表示两者。 | ||
2330 | |||
2331 | |||
2332 | 有许多不同的方法可用于部署。多数组织使用这些方法的组合,具体取决于它们的特定服务和要求以及发布大小,类型和影响。 | ||
2333 | |||
2334 | * **分阶段部署:**新的或变更的组件一次仅部署到部分生产环境中,例如部署到一个办公室或一个国家/地区的用户。根据需要重复此操作多次,直到部署完成。 | ||
2335 | * **持续交付:**组件在需要时进行集成、测试和部署,为客户反馈循环提供频繁的机会。 | ||
2336 | * **大规模部署:**新的或变更的组件同时部署到所有目标。当依赖性阻止同时使用旧组件和新组件时,有时需要此方法。例如,可能存在与某些组件的先前版本不兼容的数据库架构变更。 | ||
2337 | * **拉式部署:**在受控存储库中提供新的或变更的软件,用户可以根据需要将软件下载到客户端设备。这使用户可以控制更新的时间,并且可以与服务请求管理集成,以使用户能够仅在需要时请求软件。 | ||
2338 | |||
2339 | 可用于部署的组件应维护在一个或多个安全位置,以确保在部署之前不会对其进行修改。这些位置统称为软件和文档的权威媒体库(definitive media library),以及硬件组件的权威硬件库(definitive hardware store)。 | ||
2340 | |||
2341 | |||
2342 | 支持部署的工具多种多样。它们通常与配置管理工具集成,可以为审计和变更管理提供支持。大多数组织都有用于部署客户端软件的工具,这些工具可以与服务门户集成,以支持请求管理实践。 | ||
2343 | |||
2344 | 围绕部署的沟通是发布管理的一部分。在发布之前,用户和客户通常不会对单个部署感兴趣。 | ||
2345 | |||
2346 | |||
2347 | 如果将基础设施作为服务提供,则通常由组织管理新的或变更的服务器、存储或网络的部署,通常将基础设施视为代码,以便组织可以自动化部署。在这些环境中,某些部署可能在供应商的控制之下,例如固件更新的安装,或者提供操作系统以及基础设施,可能部署操作系统的补丁。IT组织必须确保他们知道计划的部署以及已发生的部署,以维护受控环境。 | ||
2348 | |||
2349 | |||
2350 | (% style="text-align:center" %) | ||
2351 | [[image:1640356228610-552.png]] | ||
2352 | |||
2353 | 图5.37部署管理对价值链活动的贡献热力图 | ||
2354 | |||
2355 | |||
2356 | 如果将应用程序开发作为服务提供,则部署可以由外部应用程序开发人员、内部IT部门或服务集成商执行。同样,组织必须了解所有部署,以便维护受控环境。 | ||
2357 | |||
2358 | |||
2359 | 在具有多个供应商的环境中,重要的是了解每个组织的部署活动的范围和边界,以及这些活动将如何相互作用。大多数组织都有部署流程,通常由标准工具和详细规程来支持,以确保以一致的方式部署软件。不同的环境通常有不同的流程。例如,可能存在一个用于部署客户端应用程序软件的流程,以及完全不同的用于部署服务器操作系统补丁的流程。 | ||
2360 | |||
2361 | |||
2362 | 图5.37显示了部署管理对服务价值链的贡献,实践主要应用于设计和转换,获取/构建价值链活动,以及改进活动: | ||
2363 | |||
2364 | * **改进:**某些改进可能需要在交付之前部署组件,并且这些组件的规划和管理应与任何其他部署相同。 | ||
2365 | * **设计和转换:**部署管理将新的和已变更的组件移动到生产环境中,因此它是此价值链活动的重要元素。 | ||
2366 | * **获取/构建:**变更可以作为此价值链活动的一部分进行增量部署。这在DevOps环境中尤其常见,该环境使用完整的自动化工具链进行持续集成、交付和部署。 | ||
2367 | |||
2368 | (% class="box" %) | ||
2369 | ((( | ||
2370 | **ITIL故事:艾克苏的部署管理** | ||
2371 | |||
2372 | **马可:**在我们将变更部署到我们的预订应用程序之前,我们会将变更发布到测试环境。经过全面测试后,我们会向用户和客户提供变更。 | ||
2373 | |||
2374 | **拉迪卡:**我们最近意识到,可以将同样的逻辑应用于我们的一些非数字服务和组件。例如,上个月我们在一些大城市推出了两种全新的混合动力车型共出租。我们为新车创建了促销服务供应,更新了我们的营销材料,培训了我们的技术人员以使用新模型,并提前部署了所有内容-包括车辆。这发生在制造商正式推出混合动力汽车之前。当然,这是在他们允许的情况下发生的。 | ||
2375 | |||
2376 | **苏:**等那个日期到了,我们就可以出发了。我们当天就把汽车做好出租的准备。 | ||
2377 | |||
2378 | **亨利:**与我们的制造商合作意味着我们有一个成功且准备充分的发布会,为我们的客户和他们的客户创造了一个热门话题。 | ||
2379 | ))) | ||
2380 | |||
2381 | |||
2382 | === **5.3.2 基础设施和平台管理** === | ||
2383 | |||
2384 | |||
2385 | (% class="box infomessage" %) | ||
2386 | ((( | ||
2387 | **关键信息:** | ||
2388 | |||
2389 | 基础设施和平台管理实践的目的是监督组织使用的基础设施和平台。如果执行得当,此实践可以对组织可用的技术解决方案进行监控,包括外部服务提供商的技术。 | ||
2390 | ))) | ||
2391 | |||
2392 | |||
2393 | IT基础设施是物理和/或虚拟技术资源,例如服务器、存储、网络、客户端硬件、中间件和操作系统软件,可提供交付IT服务所需的环境。这包括客户用于访问服务或消费产品的任何CI。IT基础设施可以由服务提供商或外部供应商作为专用、共享或云服务来管理。基础设施和平台管理还可以包括组织用于运行其IT基础设施的建筑物和设施。 | ||
2394 | |||
2395 | |||
2396 | 基础设施和平台管理实践包括提供支持为组织及其利益相关者创造价值的活动所需的技术。这可以包括准备采用新技术,如机器学习、聊天机器人、人工智能、移动设备管理和企业移动管理。 | ||
2397 | |||
2398 | |||
2399 | 重要的是要考虑每个组织必须制定自己的战略,以使用任何类型的基础设施或平台来实现预期的结果。每个组织应设计自己的云管理系统,以便根据业务目标和预期的服务质量和运营效率来协调基础设施和平台的所有相互关联的组件。 | ||
2400 | |||
2401 | |||
2402 | (% style="text-align:center" %) | ||
2403 | [[image:1640356270924-886.png]] | ||
2404 | |||
2405 | 图5.38基础设施和平台管理对价值链活动的贡献热力图 | ||
2406 | |||
2407 | |||
2408 | 图5.38显示了基础设施和平台管理对服务价值链的贡献,该实践涉及除契动活动之外的所有价值链活动: | ||
2409 | |||
2410 | * **计划:**基础设施和平台管理提供有关用于组织战略和战术规划的技术机会和约束的信息。 | ||
2411 | * **改进:**此实践提供了有关可以支持持续改进的技术机会,以及所使用技术的任何限制的信息。 | ||
2412 | * **设计和转换:**产品和服务设计受益于提供的有关技术机会和约束的信息。 | ||
2413 | * **获取/构建:**基础设施和平台管理是此活动的关键贡献者,因为它提供了有关要获取的组件的必要信息。 | ||
2414 | * **交付和支持:**在操作层面,基础设施和平台管理支持服务和基础设施的持续维护,包括补丁管理、备份等的任何执行。 | ||
2415 | |||
2416 | (% class="box" %) | ||
2417 | ((( | ||
2418 | **云服务模型** | ||
2419 | |||
2420 | 云服务模型包括: | ||
2421 | |||
2422 | * **软件即服务(SaaS):**消费者可以使用在云基础设施中运行的应用程序,无需控制甚至管理底层云基础设施。 | ||
2423 | * **平台即服务(PaaS):**消费者可以将使用供应商支持的编程语言、服务、库、和/或工具创建的应用程序部署到云上,而无需控制甚至管理底层云基础设施。他们可以控制已部署的应用程序,有时还可以控制应用程序和托管环境的配置设置。 | ||
2424 | * **基础架构即服务(IaaS):**消费者可以获得处理、存储和/或任何其他计算资源,而无需控制底层基础设施。 | ||
2425 | ))) | ||
2426 | |||
2427 | (% class="box" %) | ||
2428 | ((( | ||
2429 | **云服务部署模型** | ||
2430 | |||
2431 | 每种服务模型都可以通过多种方式部署,可以单独使用,也可以混合使用以下各种方式: | ||
2432 | |||
2433 | * **私有云:**此类云可以位于组织内部或外部。它是一个由特定组织专用的云基础设施或平台,同时可以拥有一个或多个消费者。此云通常由组织、提供者或两者的组合管理和拥有。 | ||
2434 | * **公共云:**此类云位于云提供者的场所。它是供开放使用的,可由任何有兴趣使用它的组织拥有,管理和运营。 | ||
2435 | * **社区云:**社区云可能由社区中的一个或多个利益相关者拥有、管理和运营,可能存在于组织内部或外部。此云部署模型由多个云服务组成,这些服务旨在支持和共享一组具有相同要求且彼此具有相互关系的云服务客户。 | ||
2436 | * **混合云:**此云基础设施由两个或多个不同的云基础架构(私有,社区或公共)组成,这些基础设施仍然是独特的实体,但通过标准化或专有技术绑定在一起,从而实现数据和应用程序的可移植性。 | ||
2437 | ))) | ||
2438 | |||
2439 | (% class="box" %) | ||
2440 | ((( | ||
2441 | **ITIL实践和云计算** | ||
2442 | |||
2443 | 数十年来,云的出现一直是IT世界面临的最大挑战和机遇之一。只需按一下按钮即可获得快速、灵活的存储和IT服务的承诺,是许多组织都难以在内部交付的,这不是因为没有好处,而是因为他们自己的ITSM流程和控制尚未适应支持完全不同的工作方式。 | ||
2444 | |||
2445 | |||
2446 | IT服务的管理和控制是IT部门的关键技能,无论这些服务位于何处,ITIL提供的流程和控制都很容易适应支持那些云服务的管理。 | ||
2447 | |||
2448 | |||
2449 | 对云服务的管理做出协调的响应是至关重要的。试图仅将云服务提供作为运营问题(来解决)的组织将在战术方面遭受损失/受到影响,正如试图在战术方面控制云服务的组织将在战略层面遭受损失/受到影响一样。需要一种涵盖战略,战术和运营三个层面的联合方法。 | ||
2450 | |||
2451 | 除基础设施和平台管理实践外,基于云的服务的运营和管理还涉及许多其他实践。应该指出的是,这不是一个全面的清单: | ||
2452 | |||
2453 | * **服务财务管理:**IT部门经常为云计算做出的调整之一是财务计划,通常使用传统资本支出(CAPEX)和运营支出(OPEX)。随着云计算的出现,OPEX比CAPEX更受欢迎,因为云服务通常作为公用事业使用,并从运营预算中支付。如果云服务比内部服务更快,更容易访问,那么与它们相关的成本将随着企业的更多部分使用它们而增长。必须调整IT成本模型,并且服务财务管理实践可以帮助确定确保组织不会意外耗尽OPEX所需的技术和控制。 | ||
2454 | * **供应商管理:**此实践的重点需要从简单地选择供应商并让他们开始工作,转变为作为全面发布管理流程的前端。这将确保在新的云供应上市之前对IT安全,数据保护和法规遵从等领域进行了常规评估。 | ||
2455 | * **容量和性能管理:**与服务财务管理相结合,此实践应建立和监控预算,如果需求上升导致云服务成本增加,则应跟踪阈值并发布警告。 | ||
2456 | * **变更控制:**此实践的界限必须重新定义,因为云服务提供者通常在客户很少参与的情况下进行变更,而且几乎没有客户的批准。构建在云服务之上的产品和服务将需要更多地利用标准变更来释放云平台(及相关业务模型)提供的优势。 | ||
2457 | * **事件管理:**此实践的重点将从了解如何解决内部问题,到了解哪个云提供者支持哪些服务,以及解决问题所需的信息。需要更加谨慎地支持受影响的客户和团队。 | ||
2458 | * **部署管理:**此实践对IT部门仍然至关重要,但是,对于IT部门而言,安全搭载或卸载云提供者的能力将成为一个常见的需求。部署管理将成为成功IT组织的关键能力,以确保快速部署新的云能力并将其嵌入到内部服务供应中。 | ||
2459 | ))) | ||
2460 | |||
2461 | |||
2462 | === **5.3.3 软件开发和管理** === | ||
2463 | |||
2464 | |||
2465 | (% class="box infomessage" %) | ||
2466 | ((( | ||
2467 | **关键信息:** | ||
2468 | |||
2469 | 软件开发和管理实践的目的是确保应用程序在功能、可靠性、可维护性、合规性和可审核性方面满足内部和外部利益相关者的需求。 | ||
2470 | ))) | ||
2471 | |||
2472 | |||
2473 | 术语“软件”可用于描述从单个程序(或程序套件)到较大构建(例如操作系统,操作环境或数据库)的任何内容,包括运行的各种较小的应用程序、进程或工作流。因此,该术语包括但不限于桌面应用程序,或移动应用程序、嵌入式软件(控制机器和设备)和网站。 | ||
2474 | |||
2475 | |||
2476 | 软件应用程序,无论是内部开发还是由合作伙伴或供应商开发,对于在技术支持的业务服务中为客户提供价值方面至关重要。因此,软件开发和管理是每个现代IT组织的关键实践,确保应用程序适合目的和使用。 | ||
2477 | |||
2478 | |||
2479 | 软件开发和管理实践包括以下活动: | ||
2480 | |||
2481 | * 解决方案架构 | ||
2482 | * 解决方案设计(用户界面,CX,服务设计等) | ||
2483 | * 软件开发 | ||
2484 | * 软件测试(可包括多个组件,如单元测试、集成测试、回归测试、信息安全测试和用户验收测试) | ||
2485 | * 管理代码仓库或制品库,以维护制品的完整性 | ||
2486 | * 包创建,用于有效和高效地部署应用程序 | ||
2487 | * 版本控制,共享和持续管理较小的代码块。 | ||
2488 | |||
2489 | 两种普遍接受的软件开发方法称为瀑布和敏捷方法(有关这些方法的更多信息,请参见第5.1.8节)。 | ||
2490 | |||
2491 | |||
2492 | 软件管理是一种更广泛的实践,包括设计、测试、操作和改进软件应用程序的持续活动,以便它们继续促进价值创造。软件组件可以使用生命周期进行持续评估,该生命周期跟踪组件从构思到持续改进,并最终退出。该生命周期如图5.39所示。 | ||
2493 | |||
2494 | |||
2495 | (% style="text-align:center" %) | ||
2496 | [[image:1640356345570-581.png]] | ||
2497 | |||
2498 | 图5.39软件生命周期 | ||
2499 | |||
2500 | |||
2501 | 图5.40显示了软件开发和管理对服务价值链的贡献,该实践涉及除契动活动之外的所有价值链活动: | ||
2502 | |||
2503 | * **计划:**软件开发和管理提供与创建和变更组织软件有关的机会和约束信息。 | ||
2504 | * **改进:**服务改进涉及服务的软件组件,尤其是内部开发的服务,更依赖于此实践。 | ||
2505 | * **契动:**软件开发和管理通常需要持续的协作和协调与利益相关者合作。 | ||
2506 | * **设计和转换:**软件开发和管理允许组织整体设计和管理产品和服务的变更。 | ||
2507 | * **获取/构建:**内部产品的创建以及合作伙伴和供应商开发的产品配置依靠此实践。 | ||
2508 | * **交付和支持:**软件开发和管理为交付和支持团队提供了使用有助于共同创造价值的产品所需的文档。 | ||
2509 | |||
2510 | (% style="text-align:center" %) | ||
2511 | [[image:1640356365740-388.png]] | ||
2512 | |||
2513 | 图5.40软件开发和管理对价值链活动的贡献的热力图 | ||
2514 | |||
2515 | |||
2516 | |||
2517 | [[阅读下一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/6%20%E5%B0%BE%E6%B3%A8%20ITIL%E7%9A%84%E6%95%85%E4%BA%8B%EF%BC%8C%E4%B8%80%E5%B9%B4%E8%BF%87%E5%8E%BB%E4%BA%86/]] [[返回上一章>>http://itil4hub.cn/bin/view/1.1%20%E5%9F%BA%E6%9C%AC%E6%93%8D%E4%BD%9C/4%20%20ITIL%E6%9C%8D%E5%8A%A1%E4%BB%B7%E5%80%BC%E7%B3%BB%E7%BB%9F/]] |