Version 25.1 by superadmin on 2020/06/15, 19:07
Show last authors
1 == Q1：在2019年版本更新后，为什么命名为ITIL 4，而不是ITIL v4？ ==
2
3
4 ITIL 的上一版本称为“ITIL v3/2011”，而在 2019 年更新后被称为“ITIL 4”，并不是“ITIL v4” 也不是“ITIL 2019”。这是一个细微的变化，学习者可能一开始没有注意到，甚至目前还有一些文章仍然错误地称之为“ITIL v4”。
5
6 实际情况是：一来，ITIL 官方为了匹配目前 IT 行业的发展变化，将各种更新的概念、实践、管理方法等都兼收并蓄，集成了敏捷、DevOps 和精益等最佳实践，对原有的框架进行了彻底的更改，将IT 服务管理利用价值流的形式，扩展到其他领域，提出了“一切组织皆为服务组织”的理念，并创造性地提出了 SVS 服务价值系统这一概念。为了凸显这次不仅仅是 ITIL 框架的版本更改和新技术和组件的合并，ITIL 的框架需要一个新名称，而不仅仅是版本号的变动。考虑到 ITIL 在这次更新中所经历的较大变化，它有必要更新命名体系。
7
8 二来，这个名字也反映了 ITIL 4 将在支持个人和组织引领第四次工业革命方面发挥的作用。当前 IT 是每个企业的核心，本次更新将使 ITIL 能够反映我们所处的 VUCA 环境，以及所需的新工作方式和新兴实践。更新的目的是为组织提供对现代服务型经济中服务管理的全面指导。ITIL 4 不再仅仅面向流程拥有者，同时也将面向更广的受众。ITIL 4（有潜力）发展为提供端到端的数字运营模式， 涵盖技术支持的产品和服务的全面交付，指导 IT 如何与更广泛的业务战略接口衔接，甚至进一步引[[image:image-20200615172050-1.jpg]]领业务的发展。所有这些不仅对ITSM 专业人员，也对在数字化转型领域工作的更广泛的专业人员而言， 是必不可少的。
9
10 对此，我们也作了一点畅想，“4（four）”在英语中和“for”同音，官方也可能希望通过“ITIL 4”让 ITIL 不在仅仅“for”IT 服务，更希望能“for”所有的服务型组织，“for”所有的价值共创方， 从而使 ITIL 能传递更多最大的价值。而我们也希望通过本书略尽绵力，让 ITIL 4 U ！
11
12 == Q2：ITIL为什么需要换版？ ==
13
14
15 我们可以从 ITIL 4 作者之一 Stuart Rance 的话中得到一些启示。Stuart Rance 是 ITIL 的资深作者和IT 行业权威，他在一篇名为《ITIL v3/2011 有什么问题？》的博文中，指出了 ITIL v3/2011（或者更准确地说，ITIL v3/2011 版本）需要更新的五个关键原因：
16
17 * ITIL v3/2011 过于关注过程；
18 * 需要在竖井中实现（组织分别运作每个流程），尤其是服务战略→服务设计→服务转换→服务运营→持续服务改进的生命周期模式，实在是太像传统的瀑布式服务交付模型了；
19 * 对价值、成果、成本和风险的关注太少；
20 * 需要支持数字化转型；
21 * 需要与敏捷、精益、DevOps 和其他管理方法兼容。
22
23 考虑到 Stuart 是 ITIL 4 的作者，可以假设这些原因不仅反映了 ITIL v3/2011 的问题，也反映了 ITIL 4 的变化。这次 ITIL 更新加强与业务策略的联系，并维持以前 ITIL 版本的仍然有价值的核心元素。
24
25 == Q3：个人认证方面，ITIL 4有哪些选择？应该如何选择学习路径？ ==
26
27
28 ITIL 4 的认证体系分为基础级（Foundation），中级（两条进阶路径 MP 与SL）和大师级（Master）。虽然目前只开放了 ITIL 4 基础级考试，但在不久的将来，进阶路径和大师认证都将开启。另外， ITIL 4 的认证体系已取消了 ITIL v3/2011 的学分制。
29
30
31 [[image:image-20200615172119-2.jpg]]
32
33
34 图4-1 ITIL 4认证体系图
35
36
37 与 ITIL v3/2011 一致的是，在基础级之上是左右两路分支，ITIL v3/2011 左右两路是对称的， 无论从左路或是右路进行学习，均等价，最后都可以从任一单路分支申请 Master。但 ITIL 4 左右两路却变成了不对称的互补形态，学习者必须完整学完左右两路所有课程，才可能申请最高级别的ITIL 4 Master。
38
39 ITIL 4 的进阶路径，包含了：
40
41 * 左路 ITIL Managing Professional （ITIL MP 管理专家），其中包含 4 门中级模块（3 门专业认证课程和 1 门战略师认证课程），主要面向跨业务的技术和数字团队中的 IT 从业者，相关课程提供如何成功运行 IT 项目、团队和工作流方面的实用技能知识。
42 * 该进阶路径具体包含的课程内容如下：中级课程：ITIL Specialist ITIL 专业认证课程：
43
44 ITIL 专家 Create，Delivery & Support-CDS（创建、交付和支持）
45
46 * 中级课程：ITIL 专家 Drive Stakeholder Value -DSV（驱动干系人价值）
47 * 中级课程：ITIL Specialist ITIL 专业认证课程：High Velocity IT-HVI（高速 IT）
48 * 中级课程：ITIL 战略 Direct，Plan & Improve-DPI（指导、计划和优化）。
49
50 据目前官方消息，MP 中四门课程模块将分两批于 2019 年 11 月和 2020 年 Q1 正式对外发布。
51
52 若需获得ITIL MP 管理专家认证资格，学习者需通过该路径中的所有 4 门认证培训和考试（CDS，
53
54 DSV，HVI，DPI）。当获得 ITIL 管理专家资格后，若学习者仍希望获得 ITIL 战略领导者路径资格，
55
56 则只需要考取 ITIL 领导者 - Digital & IT Strategy（数字化和 IT 战略）认证即可。
57
58 * 右路 ITIL Strategic Leader（ITIL SL 战略领导者）包括两门中级模块（包含 1 门战略师认证课程和 1 门领导者认证课程），课程着眼于体现 ITIL 的价值，跳出 IT 运营的框架，考虑更全面的数字化服务，经过认证的专家将在 IT 如何影响和指导业务战略方面有出众的表现。
59
60 进阶路径具体包含的课程内容如下：
61
62 * ITIL 战略 Direct，Plan & Improve - DPI（指导、计划和优化）
63 * ITIL 领导者 Digital & IT Strategy -DIS（数字化和 IT 战略）
64
65 若需获得ITIL 战略领导者认证资格，学习者需通过该路径中的 2 门认证培训和考试（DPI&DIS）。值得注意的是，报考 ITIL 战略领导者资格认证的学习者除了必须具有 ITIL 4 基础认证外，还需同时具备三年或以上的管理经验。
66
67 目前 SL 课程模块并无具体发布日期。建议有兴趣的读者可以关注艾拓先锋和北宙咨询的微信公众号，以便及时了解相关动向。
68
69 == Q4：ITIL 4基础级的学习对象有哪些？ ==
70
71
72 对 IT 服务有兴趣的从业或非从业者，都可以学习 ITIL 4 基础级。一般而言，学习对象主要有以下几类人士：
73
74 * 信息中心主任、CIO、IT 运维经理、数据中心经理；
75 * IT 运维人员、IT 项目经理、软件 / 系统开发主管；
76 * IT/ 业务经理、资深 IT 人员、IT 支持服务主管；
77 * IT 客户服务人员、Helpdesk 经理；
78 * IT 咨询顾问、IT 服务管理工具实施核心人员。
79
80 == Q5：为什么没有ITIL 4基础级过渡模块？ ==
81
82
83 由于 ITIL 4 基础级与 ITIL v3 基础级的知识结构差异非常大，整个 ITIL 框架也改变了，增加了大量的新内容、新实践，所以官方并未推出基础级级别的过渡模块。ITIL v3/2011 基础级认证的获得者需要重新进行 ITIL 4 基础级的考试，以评估学习者对新 ITIL 4 基础级指南的了解程度。
84
85 == Q6：ITIL 4与ITIL v3/2011相比，有哪些主要的改进？ ==
86
87
88 与 ITIL v3/2011 对比，ITIL 4 进一步演进，创建了服务价值系统（SVS），其改进内容可以归纳为以下五个主要方面：
89
90 * 推出了 SVS、SVC 全新框架，符合当前数字化转型的大趋势和方向；
91 * 改流程为实践，将流程、技术、人员和管理方法整合为同一概念，不再割裂地看待 IT 服务管理要素；
92 * 将分阶段、瀑布式的服务生命周期改为贯穿端到端的服务价值链；
93 * 与敏捷、精益、DevOps、云计算、大数据等最新管理思想和技术作了结合和融合。更强调业务价值；
94
95 总而言之，ITIL v3/2011 包含了服务管理中的 26 个流程和职能，各流程与职能散落于服务生命周期的五个阶段中：服务战略、服务设计、服务转换、服务运营和持续服务改进。而在ITIL 4中引入的服务生命周期消失了，采用了不同的呈现方式，使用 SVS 来展示机会/需求如何转化为价值。
96
97 这样修改的原因在于，不少人在了解和学习ITIL v3/2011 时，会误认为各个流程之间是割裂。比如， 有人误以为变更管理只出现在服务转换阶段，因为变更管理被归入到 ITIL V3/2011 生命周期的服务转换阶段。
98
99
100 |
101 | |[[image:image-20200615172119-3.jpg]]
102
103 图4-2 ITIL v2、ITIL v3/2011与ITIL v3/2011流程与职能示意图
104
105
106 取而代之的是，ITIL 4 引入服务价值系统 SVS，它包括了一系列指导原则、治理、SVC 活动以及一套合计 34 个实践和持续改进。ITIL 4 的SVC 与ITIL v3/2011 的服务生命周期之间的巨大差异在于， 采用热图的方式将所有实践在 SVC 中呈现。
107
108 == Q7：ITIL 4组件与ITIL v3/2011相比，关联程度如何？ ==
109
110
111 官方目前暂时未提供对应关系。感谢 YaSM 标准论坛的努力，其整理出了相关的内容。本书试译之， 供读者参考。
112
113 原文网址为 https:~/~/yasm.com/wiki/en/index.php/ITIL_4_vs_ITIL_V3。
114
115
116 表4-1：ITIL 4中的新内容与ITIL v3/2011关联
117
118 |(% colspan="3" %)(((
119 [[image:image-20200615172150-4.png]]
120
121 ITIL 4组件 vs. ITIL v3/2011
122 )))
123 |(% style="width:174px" %)ITIL 4组件|(% style="width:477px" %)ITIL 4中的新内容|(% style="width:426px" %)与ITIL v3/2011的关联
124 |(% colspan="3" %)ITIL 4关键概念
125 |(% style="width:174px" %)(((
126
127
128 服务管理的关键概念
129 )))|(% style="width:477px" %)(((
130
131
132 ·ITIL 4更注重价值创造，并更详细地解释了这个概念。
133 )))|(% style="width:426px" %)·其中一些概念在ITIL v3/2011出版物的介绍性章节中进行了讨论（请参阅“服务管理作为实践”一章）。
134 |(% colspan="3" %)ITIL 4四维模型
135 |(% style="width:174px" %)(((
136
137
138
139
140
141
142
143 服务管理的四个维度
144 )))|(% style="width:477px" %)(((
145 ·ITIL 4定义了四个维度，应该考虑这些维度来确保服务管理的整体方法：
146
147 1.人员；
148
149 2.信息和技术；
150
151 3.合作伙伴和供应商；
152
153 4.价值流和流程。
154
155 ·这些维度适用于一般的服务价值系统系统和特定的服务。
156
157 ·虽然流程在ITIL v3/2011中很重要，但ITIL 4与流程以及价值流相关，价值流描述了如何为客户和用户创建价值。
158 )))|(% style="width:426px" %)(((
159
160
161
162 ·ITIL v3/2011没有具体描述四维模型以及这些方面在服务管理中的角色，而是将服务管理引入到一个“ 系统方法” 中，该方法具有互连的资产和服务组件。 此外，人员、信息、技术、合作伙伴和流程是许多ITIL v3/2011流程和其他ITIL v3/2011指南中的关键考虑因素
163
164 （4Ps）。
165 )))
166 |(% colspan="3" %)ITIL 4服务价值系统（SVS）
167 |(% style="width:174px" %)(((
168
169
170
171
172 服务价值系统概览
173 )))|(% style="width:477px" %)(((
174 ·服务价值系统（SVS）是ITIL 4中的一个新概念。SVS描述了“组织中的所有组件和活动如何协同工作以实现价值创造”
175
176 ·ITIL 4服务价值系统包括五个部分： 1.指导原则；
177
178 2.治理；
179
180 3.服务价值链（SVC）；
181
182 4.持续改进；
183
184 5.实践。
185
186 ·ITIL 4和SVS采取了更全面的方法，为组织提供了一个灵活的运营模型，并支持不同的工作方法。ITIL 4没有定义特定的ITIL 4 流程，但实践事实上主要由流程组成，服务提供者可以自由地设计为其组织工作的定制流程。
187 )))|(% style="width:426px" %)(((
188
189
190
191
192
193 ·ITIL v3/2011拥有26个服务生命周期流程、职能和其他指南；其还描述了组织中的组件和活动如何协同工作。
194 )))
195 |(% style="width:174px" %)(((
196
197
198 指导原则
199 )))|(% style="width:477px" %)(((
200 ·ITIL 4指导原则是通用的建议，可以在许多情况下指导组织，例如“通盘思考和工作”和“保持简单和实用”。
201 )))|(% style="width:426px" %)·这些指导原则并不是原始ITIL v3/2011出版物的一部分，但它们已被ITIL Practitioner（从业者） 采用，这是ITIL v3/2011服务组合的最新添加部分。
202 |(% style="width:174px" %)(((
203 治理
204 )))|(% style="width:477px" %)·ITIL 4服务价值系统的治理组件是关于指导和控制组织的。|(% style="width:426px" %)·ITIL v3/2011在服务策略发布中涵盖了这个主题。
205 |(% style="width:174px" %)(((
206
207
208 服务价值链
209 )))|(% style="width:477px" %)(((
210 ·ITIL 4服务价值链是ITIL 4服务价值系统的核心要素。它展示了为客户创造价值所需的关键活动。六个价值链活动是： 1.计划；
211
212 2.改进；
213
214 3.契动；
215
216 4.设计和转换；
217
218 5.获取/构建；
219
220 6.交付和支持。
221 )))|(% style="width:426px" %)(((
222 ·ITIL v3/2011中的核心元素是包含五个阶段的服务生命周期：服务战略、服务设计、服务转换、服务运营以及持续服务改进。此生命周期与ITIL 4服务价值链并不相同，但是在更详细的级别上，ITIL v3/2011服务生命周期流程中的许多活动都与价值链活动存在大致对应。同时，我们也可以理解为，ITIL v3/2011的生命周期模型为ITIL 4价值链的一个价值流
223
224 实例。
225 )))
226 |(% style="width:174px" %)(((
227
228
229 持续改进
230 )))|(% style="width:477px" %)(((
231
232
233 ·ITIL 4持续改进模型描述了一种结构化的方法，用于识别和实现可在组织所有级别使用的改进。
234 )))|(% style="width:426px" %)(((
235 ·
236
237 ITIL 4中的持续改进模型包含7个步骤，在某些方面可以与ITIL v3/2011中的7步改进法的过程相比较。
238 )))
239 |(% style="width:174px" %)(((
240
241
242 ITIL 4实践
243 )))|(% style="width:477px" %)(((
244
245
246 ·ITIL 4没有使用ITIL v3/2011中26个流程，而是采用了“实践”的说法，将34个实践定义为“一组用于执行工作或完成目标的组织资源”。
247 )))|(% style="width:426px" %)(((
248 ·
249
250 在这些实践中可以看出，ITIL 4明显植根于ITIL v3/2011，因为当中的许多实践，均对应于ITIL v3/2011的流程。
251 )))
252
253 == Q8：ITIL 4能为组织带来什么样的好处？ ==
254
255
256 ITIL 4 将为组织带来如下的好处：
257
258 * 使 IT 服务与业务优先级保持一致，以实现战略目标；
259 * 提高服务组合的价值，同时降低成本和风险；
260 * 提高 IT 员工的岗位胜任力、工作能力和生产力，更好地利用员工的技能和经验；
261 * 提高用户和客户对服务 / 产品的满意度以及最终用户感知；
262 * ITIL 4 提供了一个整体的端到端视图，与精益IT、敏捷和DevOps 等新工作模式进行了整合。
263
264 == Q9： 对 于 ITIL 4 中 的 服 务 管 理 四 个 维 度， 我 们 如 何 结 合ITIL v3/2011 的 4P 进行理解？ ==
265
266
267 ITIL 4 将 ITIL v3/2011 中的 4P 概念进行了极大的扩展，使其能支持整体的服务管理方法，详见下图。
268
269 |
270 | |[[image:image-20200615172150-5.jpg]]
271
272 图4-3 ITIL 4服务管理四维模型
273
274
275 这四个维度不仅限于服务生命周期，还包括了带有所有价值流和实践的整个服务价值系统。但我们在使用四维度模型时，必须适当考虑所有四个方面，从而满足服务质量和效率的期望。值得一提的是， 各维度覆盖的范围难以精确描绘且具有许多重叠的边界。因此，在多供应商环境下，供应商的人员以及为其服务的员工都将被包括在内。实际上，我们需要考虑每个服务的所有四个维度并按需调整。
276
277 * 组织和人员
278
279 从原有 4P 中的“人员”扩展为“组织和人员”，这反映出一个趋势：外界对组织的要求持续增加。尤其是敏捷、SAFe 等工作方式的出现及其在大型组织中的逐步采用，目前正在进行敏捷转型的所有组织的复杂性都在增加。其运营模式必须确保明确角色、职责和沟通。因此，刚性的组织结构难以为继。组织需要一种支持其自身价值观和目标的文化，使其具备一定的弹性。同时，确保团队始终提供足够的能力，以履行他们必须完成的工作以不断增加价值。
280
281 ITIL 4 中的人员（people）被定义为客户、用户、供应商的员工以及其他利益相关者，这已非常全面。
282
283 ITIL 4 内的新内容不仅明确侧重于必要的技能和经验，而且还侧重于领导力和领导能力、沟通以及最重要的合作技能。虽然在 ITIL v3/2011 中就有那么一行小字“重要的是，组织中的每个人都清楚地了解他们为组织创造价值所作的贡献。”相信大部分人可能过目即忘，甚至是没有留意到。所以时至今日，我们还需要继续向采用 ITIL 4 的组织中每一位人员振聋发聩地问两个问题：“ITIL 4 如何为我们创建价值？为谁创建价值？”
284
285 * 信息和技术
286
287 4P 的“产品”现在扩展为“信息和技术”。我们都非常喜欢这种观点，这非常重要。信息是 21 世纪的石油，也是信息处理中的重要因素。信息是关于创建、管理或以其他方式处理和使用的所有数据。在过去的 4P 中，“人”与“流程”之间总是缺少了这个连接。其中的一个关键窍诀是，在每个价值交付的环节中，问下游的人：“为了更好地完成你的工作，你需要我提供怎样的信息”？
288
289 信息管理也需要加以区分，我们需要了解：
290
291 * 服务提供和管理的是哪些信息？
292 * 提供和确保服务需要哪些信息和知识？
293 * 这些信息和知识如何作为企业的资源被保护、获取、存档甚至删除？
294
295 信息管理必须是整体的，因为信息的处理无法在应用程序中单独完成。因此，必须清楚如何提供信息并与其他（可能是外部）服务进行交互。有必要对信息进行分类，并根据内部法规甚至 GDPR 等监管要求对其进行处理。
296
297 技术的使用必须考虑到组织的文化。许多组织目前正在讨论将基础架构、应用程序和数据迁移到云的问题——国企常头痛能否将信息放置于公有云之上，不开放则原有宝贵资源无法活用，边缘战略无法生效；开放则安全等管理问题将接踵而至。技术与服务交付的支持工具也相关，例如ITSM 工具、知识和协作工具、CMDB 工具、数据分析工具或 DevOps 的工具链。这些工具目前都在持续演变中。人工智能（AIOps）、机器学习和聊天机器人（运维中还有ChatOps）也将越来越广泛地应用于服务组织。这些技术也涉及支持服务本身的技术。
298
299 * 伙伴和供应商
300
301 将 4P 中的“伙伴”，扩充为“伙伴和供应商”。供应商被提升到与“伙伴”同等的地位。一个组织独霸垂直供应链的制造业时代已经过去了。现在，更多的是组织在服务生态系统中与外部合作伙伴和供应商的协作。各方共同组织、契动、设计、开发、部署和持续改进服务或产品。ITIL 4 中尤其提及需要将各方及其解决方案整合到更高级别的端到端服务中。这来源于SIAM 的“服务集成和管理” 理念。
302
303 影响供应商使用战略的因素包括：
304
305 * 战略重点：什么是组织的核心业务，我们从合作伙伴那里获得什么？
306 * 企业文化：过去与合作伙伴合作过什么？我们具有何种经验？
307 * 资源准备：我们可以自行开拓某些资源还是需要供应商的帮助？
308 * 成本考虑：中长期来看，更经济的做法是什么？
309 * 专业能力：如果我们需要合作伙伴的专业知识，我们是否拥有必要的专业知识或能否更快地采取行动？
310 * 外部限制：是否有必要在供应商战略中考虑相关外部规则？在分析外部因素时，我们可以考虑采用 PESTEL 分析法，见下图。
311
312 |
313 | |[[image:image-20200615172150-6.jpg]]
314
315 图4-4 PESTEL分析法
316
317
318 * 需求：客户需求是否会受到季节性波动的影响，是否可以在合作伙伴的帮助下实现平衡？
319 * 价值流和流程
320
321 将 4P 中的“流程”与“价值流”合并，并且将“价值流”放于首位。这个维度涉及整个服务价值系统，但也涉及特别提供个人服务。这包括实现商定目标的所有活动、工作流程、控制和程序。该维度与服务提供商组织和 SVS 相关，着眼于如何集成和协调业务的各个部分，以通过产品和服务增加价值。SVS 是关于确保和组织所有活动，以便为所有相关人员创造有效和高效的价值。为此，必须建立组织的更高级别的运营模式。这种通用的价值链运营模型可以同时包含各种价值流。
322
323 价值流是组织必须采取的一系列步骤，用于为其用户创建和交付产品和服务。因此，可认为价值流是有助于价值创造的活动和流程的组合。现在组织面临的主要挑战是需要确定其特定的价值流，从而满足用户的需求。价值流的一个较好的例子是 DevOps，其涵盖了从业务需求、开发、测试、发布计划到部署的一系列活动。
324
325 流程是逻辑上相互作用的活动，它们将输入转换为所需的输出。流程是价值流的一部分。例如， 用户支持的价值流可以包括事件管理、服务台、问题管理、变更控制和配置管理实践和流程。我们不应单独考虑流程，而应在价值流的各步骤中对流程进行结构化处理。
326
327 纵观 ITIL 4 的服务管理四维模型，有一点我们非常明确：“服务管理不应局限于通过流程或工具的实现”，它更需要管理层和员工等各层面怀有共同的信念，使 SVS 服务价值系统成为在数字化时代服务突围的理想方法。
328
329 == Q10：关于从ITIL v3/2011升级到ITIL 4，我还需要了解什么？ ==
330
331
332 您还需要了解两件事情：
333
334 1. 根据目前官方公布的信息，ITIL v3/2011 培训考试计划最早将于 2020 年 6 月不再继续提供。
335 1. 从 ITIL v3/2011 升级到 ITIL 4 认证的途径，根据不同的情况，我们给出以下三类建议：
336
337 * 情况一，您只拥有 ITIL v2 或 v3 基础级的认证：
338
339 如Q8 所述，您需要从ITIL 4 基础级开始考试。通过ITIL 4 基础级过渡到ITIL 4 的新认证体系中。然后选择自己感兴趣的模块，成为 ITIL 策略师、领导者，甚至大师。
340
341 当然，您也可以选择不升级。不升级其实也没有关系，因为我们相信您拥有一张早期的 ITIL 证书也是倍有面子的。只是，它无法证明您经过了 ITIL 4 的价值链与数字化服务思想的熏陶罢了。
342
343 * 情况二，您拥有 ITIL v3 Expert 的认证： 比较有性价比的方案是，您通过考取 ITIL Managing Professional 过渡模块（已于 2019 年九月发布），从而获得 ITIL 4 MP 管理专家认证。然后只需再完成 1 门 ITIL 领导者数字和战略模块ITIL Leader Digital & IT Strategy 即可成为 ITIL 4 战略领导者。这样仅需要 2 门课程，即可完成左右两路进阶课程，并将有资格进军 ITIL 4 Master。路线图如下：
344
345 |
346 | |[[image:image-20200615172225-7.png]]
347
348 图4-5 ITIL v3 Expert认证获得者升级ITIL 4建议路线图
349
350 我们还有另外一个建议，如果您已决定选择这条升级路线，请尽早启动学习。因为过渡模块只存在一个不会太长的过渡期中，过渡期后过渡模块将会取消。官方已于 2019 年 10 月正式对外发布过渡模块课程。之前也曾经有一个通过 Bridge 培训考试快速升级成 ITIL v3 Expert 的机会，放在一些拥有 ITIL v2 Manager 认证学习者的面前，但他们错过了，追悔莫及。
351
352 * 情 况 三， 您 已 经 在 ITIL v3/2011 的 认 证 体 系 中 持 有 若 干 门 ITIL v3 OSA/ PPO/RCV/ SOA/ Practitioner 等中级证书但却不足 17 个学分：那么您可以考虑两条路径。
353
354 路径 1——固本培元：您将从 ITIL 4 基础级开始，夯实基础，重新一步步逐级完成 ITIL 4 的学习。
355
356 路径 2—— 乾坤挪移：您继续参加尚未停止的 ITIL v3/2011 培训，在获得合计 17 个ITIL v3/2011 学分后， 就有资格参加 ITIL Managing Professional 过渡模块考试， 从而获得ITIL 4 MP 管理专家认证。这对您来说，能在节省一部分时间的同时，快速跟进 ITIL v3/2011 整个生命周期的课程和考试。当然了，您还是需要抓紧时间，因为无论是 ITIL v3/2011 的培训或过渡模块都有时间窗口，一旦错过，则无法再利用。
357
358 诚然，这次重大的变化，可能会给许多计划学习 ITIL v3/2011 认证的学习者带来不便，但他们从此时此刻开始，就必须认真考虑过渡到 ITIL 4 的事宜。
359
360 == Q11：ITIL 4是否已经抛弃了ITIL v3/2011中的服务生命周期？ ==
361
362
363 众所周知，ITIL v3/2011 的一个关键创新是引入了服务生命周期，包括五个服务生命周期阶段（服务战略、服务设计、服务转换、服务运营和持续服务改进）。ITIL v3/2011 流程分布在这个服务生命周期中。例如，服务组合管理流程是服务战略阶段的一部分，而服务目录管理流程则属于服务设计阶段。以这种方式，ITIL v3/2011 建立一个 PDCA 的循环，重点放在持续改进上。
364
365 ITIL 4 已经删除了服务生命周期的大部分内容，但“持续改进”仍然是一个关键的概念。“持续改进”是 ITIL 4 服务价值系统中的一个元素，而 ITIL 4 服务价值链及其 6 项活动（计划、改进、契动、设计和转换、获取 / 构建、交付和支持）则非常容易让人联想起 ITIL v3/2011 的服务生命周期。
366
367 == Q12：ITIL v3/2011和ITIL 4的认证模块间有无准确的映射关系？ ==
368
369
370 虽然在 ITIL 4 中保留了 ITIL v3/2011 内的众多核心元素，并且许多现有流程以及指导原则可在ITIL 4 中被部分识别，但 ITIL v3/2011 和 ITIL 4 两种认证方案之间没有非常近似的模块，无法准确地建立映射关系。
371
372 == Q13：ITIL 4中的流程去了哪儿？ ==
373
374
375 ITIL v3/2011 中的流程（Process）已被 ITIL 4 的实践（Practice）所取代，这也是 ITIL 4
376
377 比较精巧的设计。将流程由“重”转到实践之“轻”。过往不少人一听到 ITIL，第一反应就是一堆流程，万事流程先行。殊不知，单个流程虽然也有意义，但是仍需工具和支撑架构来扶持。实践被定义为“支持多个价值链活动并提供为确保实践成功所需资源的支持，这些资源可以来自供应商和内部的IT 组织”。我们也可以笼统地认为，流程是“一套完成工作的组织机制”。ITIL 4 中归纳为三类实践：
378
379 * 通用管理实践（General Management Practices），共 14 个，包括架构管理、关系管理等；
380 * 服务管理实践（Service Management Practices），共 17 个，包括资产管理、问题管理等；
381 * 技术管理实践（Technical Management Practices），共 3 个，包括部署管理、基础设施和平台管理、软件开发和管理等。
382
383 这里有两点值得一提：
384
385 1. ITIL v3/2011 中的访问管理（Access management）、设计协调计划和支持（Design Coordina tion planning and support）、需求管理（Demand Management）均未于ITIL 4 中以单独的“实践” 形式出现，但相关的内容会穿插于其他的“实践”中。
386 1. ITIL 4 拆分了 ITIL v3/2011 中的“发布部署管理”流程，把“发布管理”归为“服务管理实践”，把“部署管理”归为“技术管理实践”。这样的做法应该是考虑到“部署”有更强的技术属性， 和 DevOps、Agile 等密切相关。
387
388 总之，ITIL 4 面对快速变化的数字世界，主动做出了变化，除了将 ITIL v3/2011 中的流程纳入实践的范畴，将 DevOps、Agile 等也纳入ITIL 4 的实践中。ITIL 4 作为一个服务管理最佳实践的框架， 致力于将所有有用、有益、有价值的实践纳入其中，变为真正意义上的“库（Library）”。
389
390 == Q14：ITIL 4中实践与ITIL v3/2011中流程有无直接的对应关系？ ==
391
392
393 同样感谢YaSM 标准论坛，在其努力下，整理出 ITIL 4 实践和ITIL v3/2011 流程之间的对应关系， 详细描述了 ITIL 4 实践如何映射到 ITIL v3/2011 中服务生命周期过程。本书试译之并补充了少量内容，供读者参考。原文网址为：https:~/~/yasm.com/wiki/en/index.php/ITIL_4_vs_ITIL_V3。详情请见下表。
394
395 表4-2：ITIL 4实践和ITIL v3/2011流程内之间的详细比较
396
397
398
399 |(% colspan="3" %)(((
400 [[image:image-20200615172225-8.png]]
401
402 通用管理实践
403 )))
404 |(% style="width:123px" %)(((
405 ITIL 4
406
407 管理实践
408 )))|(% style="width:220px" %)(((
409 ITIL v3/2011中
410
411 相关流程
412 )))|(% style="width:734px" %)(((
413
414
415 对比
416 )))
417 |(% style="width:123px" %)(((
418
419
420 架构管理
421 )))|(% style="width:220px" %)(((
422
423
424 无
425 )))|(% style="width:734px" %)(((
426 ·ITIL v3/2011在服务战略发布中包含了对企业体系架构管理
427
428 的介绍。
429 )))
430 |(% style="width:123px" %)(((
431
432
433
434 持续改进
435 )))|(% style="width:220px" %)(((
436
437
438
439 ·七步改进法流程
440 )))|(% style="width:734px" %)(((
441 ·ITIL 4中的持续改进是关于持续改进组织的服务、实践和提供服务所需的所有其他要素。
442
443 ·在ITIL v3/2011中，持续服务改进（CSI）是服务生命周期的第五个阶段。ITIL v3 SI出版物描述了CSI的原则、方法和技术，并明确了一个CSI流程：“七步改进法”。
444
445 ·ITIL 4建议组织使用持续改进登记表（CIR）来管理他们的改进想法。这对应于ITIL v3/2011中使用的CSI登记册，也对
446
447 应于服务改进计划（SIP）。
448 )))
449 |(% style="width:123px" %)(((
450
451
452 信息安全管理
453 )))|(% style="width:220px" %)(((
454 信息安全管理
455
456 ·访问管理
457 )))|(% style="width:734px" %)(((
458 ·ITIL 4中安全管理实践中，有提及需要许多流程和程序支持信息安全管理，其中包括“身份和访问管理”，它对应于
459
460 ITIL v3/2011的访问管理流程。
461 )))
462 |(% style="width:123px" %)知识管理|(% style="width:220px" %)·知识管理|(% style="width:734px" %)·无变化
463 |(% style="width:123px" %)(((
464
465
466 测量和报告
467 )))|(% style="width:220px" %)(((
468
469
470 ·无
471 )))|(% style="width:734px" %)(((
472 ·ITIL v3/2011没有定义度量和报告流程，但是度量和报告实际上是多个ITIL v3/2011流程中的关键活动，比如服务级别管
473
474 理和七步改进法。
475 )))
476 |(% style="width:123px" %)(((
477
478
479
480 组织变革管理
481 )))|(% style="width:220px" %)(((
482
483
484
485 ·无
486 )))|(% style="width:734px" %)(((
487 ·组织变革管理（OCM）是一组管理技术和能力，而不仅是一个流程。
488
489 ·OCM处理变革的人力方面，与ITIL v3/2011的变更管理流程不同——ITIL v3/2011的目标是将生产环境变更所带来的风险最
490
491 小化。
492 )))
493 |(% style="width:123px" %)(((
494
495
496 组合管理
497 )))|(% style="width:220px" %)(((
498 ·服务组合管理
499
500 ·业务关系管理
501 )))|(% style="width:734px" %)(((
502 ·ITIL 4中服务组合管理实践，涉及各种类型的服务组合，例如服务、项目和客户组合。在ITIL v3/2011的服务战略中，也包含“客户协议组合”“客户组合”“项目组合”和“服务组合”，在服务设计中，还包含“应用组合”。
503 )))
504
505 续表
506
507
508 |(% colspan="3" %)通用管理实践
509 |(% style="width:134px" %)(((
510 ITIL 4
511
512 管理实践
513 )))|(% style="width:210px" %)(((
514 ITIL v3/2011中
515
516 相关流程
517 )))|(% style="width:733px" %)(((
518
519
520 对比
521 )))
522 |(% style="width:134px" %)(((
523
524
525 项目管理
526 )))|(% style="width:210px" %)(((
527
528
529 ·转换规划与支持
530 )))|(% style="width:733px" %)(((
531 ·ITIL v3/2011的转换规划与支持流程是服务转换生命周期阶段的一部分，主要是关于规划和协调服务转换项目。
532
533 ·ITIL 4项目管理实践的范围更广，其目的是确保组织内所有
534
535 项目均顺利完成。
536 )))
537 |(% style="width:134px" %)(((
538
539
540
541 关系管理
542 )))|(% style="width:210px" %)(((
543
544
545
546 ·业务关系管理
547 )))|(% style="width:733px" %)(((
548 ·ITIL v3/2011中的业务关系管理，更强调面向客户，且该流程与服务级别管理有很强的联系。
549
550 ·ITIL 4中的关系管理是指与组织的所有利害关系人（包括客
551
552 户）的关系。覆盖范围比ITIL v3/2011更广。
553 )))
554 |(% style="width:134px" %)(((
555
556
557 风险管理
558 )))|(% style="width:210px" %)(((
559
560
561 ·无
562 )))|(% style="width:733px" %)·作为负责识别、评估和控制风险的流程，风险管理并不在ITIL v3/2011流程之列，但风险管理技术在几个ITIL v3/2011 流程中均有进行描述，如变更管理、信息安全管理和IT服务连续性管理流程等，且ITIL v3/2011要求“协调的风险评估演习”。
563 |(% style="width:134px" %)(((
564
565
566 服务财务管理
567 )))|(% style="width:210px" %)(((
568
569
570 ·IT服务的财务管理
571 )))|(% style="width:733px" %)(((
572
573
574 ·无变化
575 )))
576 |(% style="width:134px" %)(((
577
578
579 战略管理
580 )))|(% style="width:210px" %)(((
581
582
583 ·IT服务的战略管理
584 )))|(% style="width:733px" %)(((
585
586
587 ·无变化
588 )))
589 |(% style="width:134px" %)(((
590
591
592 供应商管理
593 )))|(% style="width:210px" %)(((
594
595
596 ·供应商管理
597 )))|(% style="width:733px" %)(((
598 ·ITIL 4中的供应商管理实践包括关于多源采购和服务集成的新指引（来自SIAM框架的概念）。
599
600 ·ITIL 4放弃了ITIL v3/2011术语基础合同（UC），而是使用
601
602 更通用的术语（合同、协议、保修要求等）。
603 )))
604 |(% style="width:134px" %)劳动力和人才管理|(% style="width:210px" %)(((
605 ·无
606 )))|(% style="width:733px" %)·ITIL v3/2011的出版物中，提供了一些关于能力开发和培训的指导。
607
608 |(% colspan="3" %)(((
609
610
611 服务管理实践
612 )))
613 |(% style="width:137px" %)(((
614
615
616 ITIL 4管理实践
617 )))|(% style="width:212px" %)ITIL v3/2011中相关流程|(% style="width:728px" %)(((
618
619
620 变化：ITIL 4 vs. ITIL v3
621 )))
622 |(% style="width:137px" %)可用性管理|(% style="width:212px" %)·可用性管理|(% style="width:728px" %)·无变化
623 |(% style="width:137px" %)(((
624
625
626 业务分析
627 )))|(% style="width:212px" %)(((
628
629
630 ·可用性管理
631
632 ·需求管理
633 )))|(% style="width:728px" %)(((
634 ·该ITIL 4实践描述了分析系统、流程、架构等的技术。
635
636 ·其中一些技术应用于ITIL v3/2011流程，例如在
637
638 服务设计阶段定义了服务需求。
639 )))
640 |(% style="width:137px" %)(((
641
642
643 容量和性能管理
644 )))|(% style="width:212px" %)(((
645 ·容量管理
646
647 ·需求管理
648 )))|(% style="width:728px" %)(((
649
650
651 ·无变化
652 )))
653 |(% style="width:137px" %)(((
654
655
656 变更管理
657 )))|(% style="width:212px" %)(((
658 ·变更管理
659
660 ·变更评估
661 )))|(% style="width:728px" %)(((
662
663
664 ·无变化
665 )))
666 |(% style="width:137px" %)事件管理|(% style="width:212px" %)·事件管理|(% style="width:728px" %)·无变化
667 |(% style="width:137px" %)IT资产管理|(% style="width:212px" %)·服务资产和配置管理|(% style="width:728px" %)·无变化
668 |(% style="width:137px" %)监控和事态管理|(% style="width:212px" %)·事态管理|(% style="width:728px" %)·无变化
669 |(% style="width:137px" %)问题管理|(% style="width:212px" %)·问题管理|(% style="width:728px" %)·无变化
670 |(% style="width:137px" %)(((
671 发布管理
672 )))|(% style="width:212px" %)(((
673 ·发布和部署管理
674 )))|(% style="width:728px" %)(((
675 ·ITIL 4包含了一些对在敏捷/DevOps环境下管理发布的额外指引。
676 )))
677 |(% style="width:137px" %)服务目录管理|(% style="width:212px" %)·服务目录管理|(% style="width:728px" %)·无变化
678 |(% style="width:137px" %)服务配置管理|(% style="width:212px" %)·服务资产和配置管理|(% style="width:728px" %)·无变化
679 |(% style="width:137px" %)(((
680
681
682 服务连续性管理
683 )))|(% style="width:212px" %)(((
684 ·IT服务连续性管理
685
686 （ITSCM）
687 )))|(% style="width:728px" %)(((
688
689
690 ·无变化
691 )))
692 |(% style="width:137px" %)(((
693
694
695 服务设计
696 )))|(% style="width:212px" %)(((
697
698
699 ·设计协调
700
701 ·服务级别管理
702 )))|(% style="width:728px" %)(((
703 ·服务设计是ITIL v3/2011中的第二个服务生命周期阶段，设计协调和服务级别管理是其中关键流程。
704
705 ·ITIL v3/2011中的服务设计包括进一步细化的流程，如容量管理、可用性管理、IT服务连续性管理
706
707 等，这些流程对应于相同名称的ITIL 4实践。
708 )))
709 |(% style="width:137px" %)(((
710
711
712 服务台
713 )))|(% style="width:212px" %)(((
714 ·事件管理
715
716 ·请求履行
717 )))|(% style="width:728px" %)(((
718 ·ITIL v3/2011将服务台定义为“职能”，其活动
719
720 在事件管理和请求履行流程中进行了描述。
721 )))
722
723
724 续表
725
726
727 |(% colspan="3" %)(((
728
729
730 服务管理实践
731 )))
732 |(((
733
734
735 ITIL 4管理实践
736 )))|ITIL v3/2011中相关流程|(((
737
738
739 变化：ITIL 4 vs. ITIL v3
740 )))
741 |服务级别管理|·服务级别管理|·无变化
742 |服务请求管理|·请求履行|·无变化
743 |服务验证和测试|·服务验证和测试|·无变化
744
745 |(% colspan="3" %)技术管理实践
746 |ITIL 4管理实践|ITIL v3/2011中相关流程|对比
747 |(((
748
749
750 部署管理
751 )))|(((
752
753
754 ·发布和部署管理
755 )))|(((
756 ·ITIL 4部署管理实践解释了将硬件、软件和其他服务组件部署到生产环境中的各种方法。
757
758 ·ITIL v3/2011发布和部署管理流程包括了关于各种部署选项的类似指导。
759
760 ·ITIL 4为多个供应商的环境提供了一些额外的建议。
761 )))
762 |(((
763
764
765 基础设施和平台管理
766 )))|(((
767
768
769 ·无
770 )))|(((
771 ·ITIL 4实践关注组织中技术的使用，包括云服务和云计算的最新指导。
772
773 ·在ITIL v3/2011中，关于这个主题的指导非常有限。仅在服务策略出版物中包含的附录内，介绍了
774
775 云产品及其对服务策略的影响。
776 )))
777 |(((
778
779
780 软件开发和管理
781 )))|(((
782
783
784 ·无
785 )))|(((
786 ·ITIL v3/2011描述了服务发布中的应用程序管理功能，其中可找到类似的内容。
787
788 ·ITIL 4提供了软件开发和管理活动的高级概括。
789 )))
790
791 == Q15：ITIL 4各实践与各服务价值链活动间的关系如何？ ==
792
793
794 ITIL 4 定义了一个由 6 项活动组成的通用服务价值链：计划、改进、契动、设计和转换、获取 / 构建、交付和支持。每条价值流都会涉及几个甚至所有的服务价值链活动。而这些价值流可以包含各种流程活动，这些流程活动是根据服务的特定价值流量明确定制的。在 ITIL 4 中，已经明确了 34 种可用于实现价值流内 6 种价值链活动的实践。这些实践包含了必要流程、技能、信息、工具和界面。为帮助各位读者理解各个实践对服务价值链活动的贡献度，我们根据各实践的热图（Heat map）整理出下表：
795
796
797 表4-3：实践对服务价值链活动的贡献度表
798
799 |序号|实践|贡献度（从0-3：无、低、中、高）
800 |1|部署管理|0
801 |2|基础架构和平台管理|0
802 |3|软件开发和管理|0
803 |4|可用性管理|1
804 |5|容量和性能管理|1
805 |6|IT资产管理|1
806 |7|变更控制|1
807 |8|监控和事态管理|1
808 |9|发布管理|1
809 |10|服务连续性|1
810 |11|服务设计|1
811 |12|服务配置|1
812 |13|服务验证和测试|1
813 |14|知识管理|2
814 |15|架构管理|2
815 |16|问题管理|2
816 |17|测量和报告|2
817 |18|劳动力和人才管理|2
818 |19|组织变革管理|2
819 |20|组合管理|2
820 |21|项目管理|2
821 |22|服务财务管理|2
822
823 续表
824
825
826 |序号|实践|贡献度（从0-3：无、低、中、高）
827 |23|战略管理|2
828 |24|服务请求管理|3
829 |25|事件管理|3
830 |26|持续改进|3
831 |27|服务级别管理|3
832 |28|服务目录|3
833 |29|服务台|3
834 |30|供应商管理|3
835 |31|风险管理|3
836 |32|信息安全管理|3
837 |33|关系管理|3
838 |34|业务分析|3
839
840 == Q16：ITIL 4 和 ISO/IEC 20000-1:2018 的关系如何？能否相互映射？ ==
841
842
843 2018 年 9 月 15 日，虽然 ISO 组织一反常态地抢先于 ITIL 4 面世之前，发布了 ISO/IEC 20000-1:2018（下文简称“标准”）——ISO/IEC 20000-1:2011 的完全修订版。但实际上标准和 ITIL 4 仍存在不小的契合，并非将 ITIL 4 置之不顾。
844
845 标准与 ITIL 4 保留默契的地方主要有以下几点：
846
847 从标准上来看，似乎标准变得更广泛，更加复杂，还引入了新的需求（例如：服务规划和交付领域），并且在服务管理体系的运行中，还带有诸多的流程。但实际上，标准对各个主题的要求更加精简，文档要求也大为降低。这也使组织可以更自由地定义其流程。标准的设计更多的是面向“服务管理的效果”，而不是“服务流程的详细描述”，这和 ITIL 4 中“实践”的提法比较接近，只是没有 ITIL 4 的做法那么激进。因此，在标准中，领导力和承诺、风险管理、服务计划、绩效评估和改进等主题就变得更为重要。
848
849
850
851 [[image:1592218060581-860.png]]
852
853
854 图4-6 ISO/IEC 20000-1:2018框架图
855
856
857 1. 标准删除了 PDCA，增添了服务商品化、服务集成商等内容。ITIL 4 也与之保持了同步。
858 1. 标准增加了组织应对风险和机会的新要求，ITIL 4 中也将“风险管理”增添为“实践”与其呼应。
859 1. “事件管理”和“服务请求管理”，在标准和 ITIL 4 中都做了同样的拆分。而“服务可用性管理”和“服务连续性管理”在标准中也进行了拆分，与 ITIL 4 以及 ITIL v3/2011 保持了一致。
860 1. 最重要的一点是，标准适用范围不再仅限于“IT 服务”，而是“放诸四海皆准”。
861
862 关于两者之间的映射，我们的想法如下：ITIL 4 的首席架构师团队和 ISO20000:2018 的编写者有着密切的关系，所以可以确保 ITIL 4 跨标准地适当地、映射到 ISO20000 中。最明显的一点是 ITIL 4 引入了 SVS 的概念，这符合 ISO 20000:2018 版中对组织“建立、实施、维护和持续改进”服务管理系统的关键要求。
863
864 == Q17：ITIL 4与其他服务管理相关标准和实践的关系如何？ ==
865
866
867 ITIL 已经有了 30 余年历史，多年来作为服务管理的最佳实践被许多组织所采用。其虽然不时地进行更新，但其他更新、更快、更敏捷的服务管理框架、方法论在适应服务管理和信息技术的新趋势方面已经走在了前面。如下图所示，ITIL 4 对其他服务管理相关标准、实践等采取了非常开放的兼收并蓄方式，将他们引入 ITIL 的框架中，力图通过借鉴和集成，快速跟上时代的步伐。ITIL 4 认为各服务管理相关标准、实践等与其具备相同的原则，而通过这些相同的原则，能让组织有效地将各服务管理相关标准、实践等整合到 ITIL 中去。
868
869
870 |
871 | |[[image:image-20200615180054-1.png]]
872
873 图4-7 ITIL 4服务管理相关标准
874
875
876 ITIL 4 与 ISO/IEC 20000:2018—1 的 关 系 见 上 文。 我 们 认 为 ITIL 4 可 能 从 IT4IT（ 来 自The Open Group 的一个用于 IT 规划的方法）中获得了价值链的灵感，提出了 ITIL 的第一性原理“关注价值”，该“价值”可以（而且应该）不仅适用于服务消费者，而且适用于所有相关利益相关者及其各自的价值定义。ITIL 4 也从 VeriSM 方法的管理网格（Management Mesh）中得到了引入各类“实践”的启示——VeriSM 主要特色之一是通过管理网格来包罗万象，汇集了现有的管理实践、技术、环境、资源和新兴技术；让各类实践能胶合（glue）在一起，更好地为目标服务。在供应商管理的环节，ITIL 4 提出了“多源”和“服务集成”，这正是 SIAM 框架中的关键主题。而在治理方面，ITIL 4 也在 SVS 中，将“治理”列为其核心组件，强调组织要通过治理，使组织能够不断将其运营与管理机构设定的战略方向保持一致。
877
878 近年来，我们正经历着一场向敏捷和自组织发展的巨大变革。云计算、人工智能、区块链、物联网等新技术极大地改变了信息处理和服务提供的方式。各种旧有的框架，例如ITIL v3/2011 等，都被认为过于官僚，流程过于沉重。然而，Agile、Scrum 、LeSS或DevOps 等本身并不是框架，而是种种敏捷的方法或理念；治理、管理原则和实践需要配合时代的发展走得更远，这些纯粹的敏捷方法或理念并没有埋葬它们。在新的工作方法下，如何应用这些要素存在着很大的差异性和不确定性。ITIL 4 选择性地对它们进行了吸纳：SVS 支持许多工作方法，例如 Agile、Lean 和DevOps 等。尤其是近年来非常流行的开发运维一体化，即 DevOps。ITIL 4 与 DevOps 的关系，我们将在下文进一步介绍。
879
880 == Q18：ITIL 4与COBIT 2019的关系？ ==
881
882
883 在 2019 年，ISACA 发布了 COBIT 2019。巧合的是，和 ITIL 4 一样，ISACA 也抛弃了原有的版本顺序号概念，直接采用了年份 2019 作为框架的名称。两个最后版本都是 8 年前框架，同时采用了这样的命名方法，真的有点革旧鼎新的“英雄所见略同”。COBIT 2019 对上一个版本COBIT 5 进行了改进，在其坚实的基础上增加了影响企业信息和技术的最新发展。但这还不是全部。COBIT 2019 帮助企业治理信息和技术，无论它位于何处。COBIT 2019 新覆盖范围包括数据、项目和遵从性（这些对企业都至关重要），以及对网络安全和隐私等活动的更新，还包括对所有相关标准、指导方针、法规和最佳实践的更新。目前 COBIT 仍然是企业 IT 治理活动的主框架，也可以被认为是所有信息和技术相关治理和管理实践中最全面的框架。COBIT 本身看起来像一个伞形框架，与业务策略和目标保持更好的一致性， 其所有的 40 个治理和管理目标都相应地参考了其他指南，如 ITIL、PMBOK、TOGAF、ISO27001 等等。通过 COBIT 2019，可以确保对框架进行更高级别的控制。
884
885 ITIL 4 将治理纳入了 SVS 中，并指出：“SVS 的治理是通过对 SVS 的定期评估来指导并监控 SVS 的绩效来实现的”。我们尝试创建了一个 COBIT 2019 和 ITIL 4 之间的映射关系，但目前而言该映射相对粗略，仅供各位参考。从下图 ITIL 4-COBIT 2019 映射表中可以看出，许多 COBIT 2019 治理实践在ITIL 4 中并没有得到体现。因此，整体来看，两种框架都有各自的关注点，并有机会相辅相成。希望通过该映射图，我们可以将这两个出色的框架结合起来，交付更好的价值。
886
887 但在框架运用的过程中，我们也听到过一些真实的声音。实际上，在整个行业，对 IT 治理的接受程度都很低，而且实际上对最佳实践框架治理的理解和一致性也很差。IT 服务行业也不例外。根据2018 年一份 ITSM 工具调查揭示“COBIT 作为领先的 IT 治理框架之一，其接受程度也较低”。因此， ITIL 4 面临的一个挑战是与 IT 治理系统保持一致，并使在治理 SVS 时业务能确实发挥自身的作用。对于确保机会和需求进入 SVS，在组织绩效和合规性方面有相应的优先排序方面，治理很重要。这确保了业务不需要将所有的特性均放于同样的管理风险（如技术债务）、遵从性和安全性要求之上。治理还意味着确保能在价值链的末端实现价值，确保真正实现业务用例。这是一种很好的方式，可以提供关于业务在制定业务用例方面的效率反馈，而不是简单地追求特性。
888
889
890 [[image:1592218120707-101.png]]
891
892 图4-8 ITIL 4-COBIT 2019映射
893
894 == Q19：我们应该如何运用ITIL 4？ ==
895
896
897 ITIL 实际和其他框架、方法论、知识体系等一样，只有通过“是否有助于帮助我们达到目的”这一唯一标准进行检验。对于 ITIL 4 而言，其相关的实践是如何应用以及落地，是至关重要的。我们需要在任何时候都牢记“需要完成什么”以及“为什么需要完成”。“尽信书则不如无书”，如果只是盲目地跟随 ITIL 4 中的例子或者实践去做，而不考虑组织的现状、需求和目标，这必然会失败。
898
899 所以我们在使用 ITIL 的时候，有两种途径：
900
901 * 适应：尽力去理解 ITIL 最佳实践，明白他们为什么被推荐，尝试着去应用其中关键的思维， 用这些最佳实践去应对组织的环境、需求和目标。
902 * 采用：转向以服务为导向型的战略，推动组织内“以顾客为中心”的文化。服务管理的成功来源于对上述变革的真正认同。这种真正的认同，并不只是组织内的几句口号，而是组织内人们行动的以及其行动被激励的方式。
903
904 一旦对 ITIL 的认同达致一个极高水平，这将可能帮助组织在其愿景、目标、环境和约束下，有效地评估 ITIL 对组织的价值。只有通过这种方法，真正的价值才能向顾客传递并为组织所捕获。
905
906 == Q20：ITIL 4和云计算以及相关服务关系如何？ ==
907
908
909 [[image:image-20200615180054-4.jpg]]在 AXELOS 发布的《ITIL 4 与云》的白皮书中，有有如下详细的描述：新的数字技术要求组织改变或调整他们的商业模式。这种数字转型是由新兴技术推动的，例如：
910
911 * 云计算
912 * 大数据
913 * 物联网
914 * 区块链
915 * 人工智能
916
917 这些技术变革意义重大，而云计算是其中最普遍采用的数字技术。在迁移到云时，组织将某些元素、任务和职责外包给云服务提供商。这意味着组织和作为内部 IT 服务提供商的 IT 职能部门将不再管理提供该服务所涉及的一些技术组件。云本质上是一种外包形式，这种转变改变了组织和 IT 职能部门在 IT 流程管理、风险管理、财务管理、IT 架构、系统互操作性、安全性和 IT 服务管理等方面需要采取的方法。在传统的业务和信息技术模式看来，云是一项颠覆性的创新。因其改变了为消费者和服务提供商提供信息技术产品和服务的方式。这些变化，又推动着甚至是迫使着组织和个人去改变他们的工作方式。
918
919 在 ITIL 4 中，服务被定义为“一种通过促进客户所需结果实现，且无需客户管理特定成本和风险，从而实现价值共同创造的方法”。由此可见，云和基于云的服务（下文简称为“云基服务”） 与 ITIL 4 中定义的服务有着明显的共通点。云通过更大规模、更快、更便捷、更便宜的方式，提供IT、业务、客户和消费者服务，并且可以根据服务的需求自动调配，按需付费。
920
921 云基服务的与日俱增，并没有改变 ITIL 等框架或 IT 服务管理等发展的基本轨迹。组织希望获得符合目标、
922
923 适合使用并符合组织战略方针和需求的优质产品和服务。不管云的应用多寡，有一点“老生常谈”并不会改变——服务可外包但责任无法外包。IT 职能部门和组织仍需承担从设计、架构、互操作性、安全性和风险管理等端到端的总体责任。
924
925 当组织在采用 ITIL 早期版本的时候，他们往往从服务转换和服务运营阶段直接选择对应的流程去匹配云的管理。例如事件、问题、变更、可用性、服务级别管理等。但从实践效果来看，有不少问题没有得到解决，通常的原因是 IT 职能部门缺乏最佳行动方针的指导。常见的问题包括：事件流程中“当无法控制云服务供应商工作，并且无法访问其 IT 环境时，如何管理、恢复和汇报在云服务供应商环境内所发生的事件”。问题流程中“为什么公有云服务提供商没有提交上周发生的严重应用程序问题的根因分析”。变更流程中“为什么DevOps 团队能在不遵循我们变更流程或程序下进行变更”……而在ITIL 4 中，采用了一个灵活、协调和整合的框架来为云计算以及云基服务提供更佳的指导。通过 SVS 的架构，可以确保组织出于合适的原因，以合适的方式使用云基服务，并且与监管机构和利害关系人的需求及要求保持一致。ITIL 4 的指导原则可以被云基服务采用以及对标，例如在架构、战略、程序、变化数量、预算和财务控制、容量和性能管理、可用性、培训和教育等方面。在治理活动方面， 组织能依据 ITIL 4 中对治理的指导，根据组织的治理机构和利益相关者设定的战略方向来调整它们对于云基服务的选择和使用。ITIL 4 的 SVC 也可以灵活地进行调整以及定制，适用于云基服务。
926
927 在 ITIL 4 的实践当中，有相当一部分的实践任务能通过组织外包的形式，由云服务提供商以云基服务的方式提供。例如，对于云上电子商务系统而言，服务提供商负责电子商务系统背后的整个底层基础架构，包括事件、问题、变更、发布、部署、容量和可用性的流程和实践。但总体服务的责任仍由采购该服务的组织承担。这样做有不少的好处：
928
929 * 系统架构上，通过 PaaS 能很容易的实现 SOA、微服务等架构，为企业新业务的拓展带来很大的帮助；
930 * 流程上，通过云计算，能大大提高系统的可用性和弹性。因此在可用性、业务连续性和容量方面都有较大的帮助。尤其云数据中心一旦采用分布式的架构，则在云上运行的应用，就带有天然连续性属性。
931 * 日常使用上，云服务一般自带监控和汇报系统，在事件、问题、监控和事态管理方面，云上应用都将受益。
932 * 财务上，由于云服务往往带有计费系统，有利于 IT 职能部门统计支出。并且云服务的支出往往带来了基础设施和系统的投资、支持、维护和保养费用的缩减，也有利于节省组织整体 IT 投入资源。
933
934 云基服务有不少优点，但是参照 ITIL 4 框架，还存在一些有待解决的挑战，例如：
935
936 * 云服务供应商提供的云基服务往往是通用的服务，其是否符合组织所制定的 SLA，是否符合组织未来的发展需求？
937 * 随着更多的业务迁移上云，面对不时发生的云基服务宕机事件，组织如何有效地应对？
938 * 云计算的重要特征是按需自助服务和快速弹性，现有业务及其系统能否适应这种高速、高度自动化的转型？变更和部署流程应该如何做调整？
939
940 总括来说，ITIL 4 提供了组织利用现有技术应对新形态下服务管理挑战在一定程度上的指导，同时，ITIL 4 也增加了基础架构和平台管理实践来统一协调云计算对于云基服务价值交付的支持。而云帮助我们为消费者提供更好的服务，同时有可能为组织节省成本。组织有责任基于适当的理由作出正确的选择，从而取得正确的成果！
941
942 == Q21：ITIL 4的实践如何分类？ ==
943
944
945 我们可以将 ITIL 4 的 34 项实践，按照职能、技术、方法、流程分为四大类。
946
947 * 职能类（合计 2项）：
948
949 职能被定义为“专门执行某种类型的工作，并对所产生的特定结果负责的组织单元”。服务台， 是组织对外服务的统一窗口；劳动力与人才管理，专门执行与人力资源相关的工作，往往由人事部或人力资源部负责。
950
951 * 服务台（服务管理实践）
952 * 劳动力与人才管理（通用管理实践）
953 * 技术类（合计 3 项）：
954
955 技术管理实践中包含了 3 项实践，我们将其均列为技术类。前文也提及，“部署管理”因更具技术属性，与“发布管理”剥离，被划分至“技术管理实践”。
956
957 ITIL 4 中，基础架构和平台管理同云平台和云基服务关联相当紧密。软件开发管理考虑到现有系统和创新（甚至是颠覆）系统之间的分野，兼容传统的基于软件开发成熟度模型（CMM）理论体系的瀑布式开发和遵循《敏捷宣言》的敏捷开发理论。
958
959 * 部署管理（技术管理实践）
960 * 基础设施与平台管理（技术管理实践）
961 * 软件开发与管理（技术管理实践）
962 * 方法类（合计 3 项）：
963
964 在改进计划、组织变革管理、服务财务管理、业务管理等众多实践中，往往都需要持续改进实践来指导，以及项目管理实践来组织和管理其执行。持续改进实践还是 ITIL 4 的 7 项指导原则，包括了相关的方法、技术和文化，将其归类在方法类，还是比较合适的。正如现代组织的环境和生态系统变得更加复杂，其挑战也是如此。这些不仅包括如何提高效率和自动化，还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹性。在如此复杂的 IT 环境，任何变化都寸步难行，并且风险四伏。完整的体系架构管理实践应该涉及所有体系结构域：业务、服务、信息、技术和环境。可喜的是， ITIL 4 参考并融合了 SOA 框架和 TOGAF 企业架构方法论。
965
966 * 持续改进（通用管理实践）
967 * 项目管理（通用管理实践）
968 * 架构管理（通用管理实践）
969 * 流程类（合计 26 项）：
970
971 流程在 ITIL 4 中的定义是“将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入并将其转换为已定义的输出。流程定义了操作的序列及其依赖项”。这与ITIL v3/2011 中定义的“用于实现特点目标的一系列有组织的活动，流程获得一个或多个定义的输入， 然后将它们变成定义的输出，流程可以包括任何角色、责任、工具和可靠提供输出所需的管理控制”。差距并不大。ITIL 4 强调的是“流程”是有序列的，并且有依赖项。在ITIL v3/2011 则强调的是“控制”， 将输入加工成所需要的输出。说句题外话，不少术语在 ITIL 4 和 ITIL v3/2011 中的定义都有了相当大的变化。一般而言，在ITIL 4 内术语均显得较为简洁，无太多描述性的词语，并且覆盖面会更广。
972
973 根据定义，我们将通用管理实践中的 ITIL 前版本中所提及的知识管理、信息安全管理、关系管理等归入了流程类。服务管理实践内的大部分实践我们也归入了流程类。
974
975 * 信息安全管理（通用管理实践）
976 * 知识管理（通用管理实践）
977 * 组织变革管理（通用管理实践）
978 * 度量与报告（通用管理实践）
979 * 服务组合管理（通用管理实践）
980 * 关系管理（通用管理实践）
981 * 风险管理（通用管理实践）
982 * 服务财务管理（通用管理实践）
983 * 战略管理（通用管理实践）
984 * 服务设计（服务管理实践）
985 * 供应商管理（通用管理实践）
986 * 可用性管理（服务管理实践）
987 * 业务分析（服务管理实践）
988 * 容量与性能管理（服务管理实践）
989 * 变更控制（服务管理实践）
990 * 事件管理（服务管理实践）
991 * IT 资产管理（服务管理实践）
992 * 监控与事态管理（服务管理实践）
993 * 问题管理（服务管理实践）
994 * 发布管理（服务管理实践）
995 * 服务目录管理（服务管理实践）
996 * 服务配置管理（服务管理实践）
997 * 服务连续性管理（服务管理实践）
998 * 服务级别管理（服务管理实践）
999 * 服务请求管理（服务管理实践）
1000 * 服务验证与测试（服务管理实践）
1001
1002 == Q22：ITIL 4与敏捷开发之间的结合关系？ ==
1003
1004
1005 一听到“敏捷”，大部分 IT 从业人员，都会马上联想到“软件开发”，并回想起 2001 年发布的《敏捷宣言》。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发过程中，软件项目的构建被切分成多个子项目——有点类似 PMBOK 中的“工作包”，各子项目成果均通过测试，具备集成和可运行的特性。简而言之，就是把一个大项目分为多个关联但可独立运行的小项目，并分别完成， 在此过程中软件一直处于可用状态。目前敏捷软件开发方法已被许多公司和软件团队采用，并且在许多情况下已被证明是有效的。
1006
1007
1008 |
1009 | |[[image:image-20200615180054-5.jpg]]
1010
1011 图4-9 敏捷开发路线图
1012
1013
1014 与敏捷开发相关的概念非常多，包括测试驱动开发、持续集成、重构、结对编程、每日站会、小版本发布、自动化测试。敏捷软件开发通常包括：
1015
1016 * 通过反馈分析和直接观察收集不断变化的需求；
1017 * 将开发工作分成小的增量和迭代；
1018 * 建立基于产品的跨职能团队；
1019 * 直观地呈现（看板）并定期讨论（每日站会）工作进度；
1020 * 在每次迭代结束时向利益相关者展示一份（至少是最低可行性）软件——一般称为“MVP”， 最小化可行产品。
1021
1022 而在 ITIL 4 的教材中通篇可见“敏捷”，从侧面反映出了 ITIL 4 的态度：应采用整体的服务价值链方法，以确保服务提供商在整个服务生命周期内都是敏捷的。敏捷性应成为所有服务管理维度和所有服务价值链活动的质量衡量标准之一。在 ITIL 4 的指导原则中“基于反馈的迭代推进”、“协作和提升可视化程度”、“保持简单实用”、“优化和自动化”都包含了“敏捷”的元素。
1023
1024 敏捷开发与 ITIL 4 在组织内有相辅相成的共生之道。一方面，对于敏捷开发而言，成功的敏捷开发可以快速响应服务消费者不断变化的需求。但是，在许多组织中，敏捷开发的优势并未能得到良好的发挥。这通常是由于只在服务交付等少数阶段运用了“敏捷”，而在服务生命周期的其他阶段“脱敏”。这种孤立的敏捷性对组织的帮助不大，因为根据“木桶理论”——价值链的整体表现是由创造价值的最慢部分决定的。通过价值链的整体考虑方式，ITIL 为软件开发组织提供更广泛的视角和语言， 增强软件开发团队与别的服务团队的合作，也有助于提升敏捷开发在组织内的更好落地。另一方面，
1025
1026 对于 ITIL 的前版本而言，ITIL 在服务转换阶段，在软件开发方面相对较弱，在端到端服务的过程中也相对较弱，必须要借助敏捷的思维，保持对客户和用户价值的关注，摆脱流程变得笨拙、沉重且高度集中的可能性。两者间的协同工作方式如：
1027
1028 * 在服务交付阶段，引入持续交付，在同一个价值流图看整体的情况，统一安排工作项，分配统一的优先级，做到端到端的敏捷管理；
1029 * 变更和服务请求由专门的产品团队或以服务为中心的团队，以小迭代的方式处理，使产品或服务获得持续的反馈，且具有高可见性；
1030 * 日常运营活动可以而且应该与其他任务一起显示和进行优先排序。所有服务管理活动都可以而且应该不断提供、收集和处理反馈。
1031
1032 综上所述，只有敏捷开发和服务管理一起以类似的节奏发展，说“同一种语言”，才可以确保组织继续与所有利益相关者共同创造价值。
1033
1034 == Q23：ITIL指导原则是如何演变的？ ==
1035
1036
1037 AXELOS 在 2016 年发表了《ITIL 从业者指南》（ITIL Practitioner Guidance）。虽然 ITIL 的版本已经更迭，但指导原则历久弥新。
1038
1039 《从业者指南》中提出 9 项指导原则：
1040
1041 * 专注于价值
1042 * 为体验而设计
1043 * 从你所处的地方开始
1044 * 整体工作
1045 * 迭代地进步
1046 * 直接观察
1047 * 成为透明的
1048 * 协作
1049 * 保持简单
1050
1051 这些现在已经在 ITIL 4 中被削减、改变、添加到现在的 7 项 ITIL 指导原则：
1052
1053 * 聚焦
1054 * 从你所处的地方开始
1055 * 基于反馈的迭代推进
1056 * 协作和提升可视化程度
1057 * 通盘思考和工作
1058 * 保持简单实用
1059 * 优化和自动化
1060
1061 通过对比，可以看出 ITIL 4 保留了大部分的指导原则，并进行了扩充。例如《从业者指南》中提到的“为体验而设计”，实际在 ITIL 4 中已经融入了“聚焦价值”“通盘思考和工作”当中，并将其列为 34 个实践之一——“服务设计”。“协作”“成为透明的”也变成了“协作和提升可视化程度”。实际上通过可视化的工具，让流程等透明起来，才能更好地进行团队内、团队间、团队与组织、组织间的协作。“保持简单”扩充为“保持简单实用”。ITIL 4 将指导原则也融入了 SVS 中，而不是简单将其列出后就束之高阁。“自动化”也位居“优化”之后，被合并添加为指导原则之一，这也是一个非常棒的考虑。只有通过对活动的尽量优化后，活动才能有效地自动化。ITIL 4 建议大量地在各个实践中使用自动化，通过寻找自动化的机会，帮助节省组织成本、减少人为错误并改善员工体验。我们“应充分利用各种资源，特别是人力资源，并消除任何真正浪费的东西，用科技去实现它所能做到的一切， 人类干预应该只发生在真正有价值的地方”。
1062
1063 == Q24：ITIL 4和风险管理的关系？ ==
1064
1065
1066 关于风险管理，我们可以参考国际公认的权威——ISO31000:2018 风险管理指南。在 这个 版本中， 其提出了风险管理目的和原则的总体和一般视角。它们适用于任何类型的组织中的所有级别。有趣的是，该标准的上一版本也是发布于 2009 年，同样 9 年来第一次更新。ISO31000:2018 声明“风险管理的目的是创造和保护价值”，风险管理“提高绩效，鼓励创新并支持实现目标”。
1067
1068 ISO31000:2018 有 8 项主题：
1069
1070 1. 高管支持是基础；
1071 1. 在商业决策中考虑风险；
1072 1. 强调正确地履行；
1073 1. 风险管理不是放之四海而皆准的；
1074 1. 积极主动；
1075 1. 标准化词汇；
1076 1. 利用现有的最佳信息；
1077 1. 评价成功。
1078
1079 与之对比，ITIL 4 中风险管理实践的目的是确保组织理解并有效地处理风险，从而确保组织的可持续性和为客户创造价值。风险中有威胁也有机会，与威胁有关时，通常被认为是可以避免的。而与机会相关时，不抓住机会本身就是一种风险。风险管理是所有组织活动的一个必然的组成部分，对组织的 SVS 至关重要。近期华为在应对美国一系列动作时，就表现出极高的风险管理水平，当然，还有极高的业务连续性管理水平。
1080
1081 在 7 项指导原则中，和 ISO31000:2018 中 8 项主题有不少是能匹配的：
1082
1083 * 聚焦价值以及基于反馈迭代推进，对应于评价成功。这里强调衡量、评估和改进风险管理实践的价值。这样做的目的不是第一次就把所有的事情都做好，而是在每次迭代完成时都要持续改进它。即使是不完美的风险数据也可能有用，只要它与显示趋势的时间表一起呈现。最终，风险报告能为管理人员提供高质量信息。
1084 * 通盘思考和工作，对应高管支持是基础，以及风险管理不是放之四海而皆准的。风险管理是一个循环过程，有足够的定制和改进空间，但其并非万能，管理者应该从整体去考虑，为自己的组织定制风险管理指南——特别是其风险概况、文化和风险偏好。风险管理实践必须全面管理，以实现整个组织的一致性。为确保有效性，应与利益相关方进行持续磋商，并为组织的不同部门提供适当的灵活性。这种灵活性将允许开发定制的风险管理程序，以便解决组织单位和 / 或客户特定情况。同时， 组织需要根据其愿意承担的风险偏好（即风险水平），对风险进行识别、评估、监控和管理。管理者还需要确保风险管理实践在组织的所有级别上得到充分集成，并与组织的目标结合在一起，让风险意识融入企业的运作方式中。
1085 * 从你所处的地方开始，对应利用现有的最佳信息。当前很多风险管理都集中在可用的最佳信息上，而忽视了风险中的模糊性和不完善之处。管理者不应只是试图分享绝对的风险信息，而应利用这些模糊点，对他们提供的数据进行反思，从而更好地发现问题。
1086 * 保持简单实用，对应标准化词汇。通过风险管理实践，提供一种公共语言，对风险、事件、后果和概率有简单和不复杂的定义。组织内均应采用这些术语，以确保交流不会产生分歧。
1087 * 优化和自动化，对应积极主动。对风险应该采取积极的立场，并确保将风险管理集成到组织各级决策的各个方面。这包括在业务连续性管理、业务分析、劳动力和人才管理、信息安全管理、问题管理等方面，都需要作出主动的优化，形成主动风险管理行为。
1088
1089 回到管理实践中，我们试举几个和风险管理相关的例子：
1090
1091 * 在信息安全管理中，首当其冲的就是对可能产生的风险进行识别，以确保组织所需的信息安全性。
1092 * 在问题管理实践中，问题管理活动可以为风险管理提供特定的案例，可识别、评估和控制服务管理的四个方面的风险，此时采用风险管理工具和技术进行问题管理往往很有效。
1093 * 在可用性管理中，某些组织会将导致可靠性降低的因素作为风险管理的一部分。
1094 * 在服务连续性中，需要彻底考虑影响服务连续性的因素，以及多个因素之间的关系，。假如不做风险评估，那么应急相关对应的场景就无法有效的识别，可能存在应急预案缺失的问题。
1095 * 在服务设计方面，风险管理嵌入到了所有设计过程和活动中，确保所提供的产品和服务所涉及的风险和组织的风险控制水平保持一致。
1096 * 在服务验证和测试方面，风险管理相关的条件也是服务验证的输入之一。
1097
1098 == Q25：ITIL 4的价值流，能否以图形化的方式展现？ ==
1099
1100
1101 为了减少大家混淆流程活动和价值流活动，我们提出了如下的观点：流程活动中的“活动”是真正的动作，而价值流活动中的“活动”，主要负责价值的统计和呈现，并为进一步优化价值流提供了可能。价值流当中的“活动”可以理解为端到端的价值实现“步骤”，而价值流图可以认为是一个价值流动的看板工具。我们可以根据流程活动对价值流实现的不同阶段来将价值链划分为 6 大价值链活动，这些活动之间没有绝对的先后顺序之分，每个特定的价值流活动可以在各个价值链实现步骤间穿梭。因此我们将以泳道图的方式呈现基于 ITIL 4 的价值流图：将各个步骤设为泳道，流程的活动穿插于其中。
1102
1103 为了执行某项任务或响应特定情况，组织创建服务价值流。这些是活动和实践的特定组合，每个活动和实践都是针对特定场景而设计的——受众不同、目的不同。价值流可以是线性的或者瀑布式或者非瀑布式的，可以是动态的或者敏捷的，反之亦可行。
1104
1105 我们需要记住两个原则：一是价值链活动可以在价值流的过程中重复自己。而价值流是端到端的，以需求开始，以价值结束。任一价值流的目标都是将某一类特定的需求转换为价值。IT 组织通常缺乏这种“全局视野”，因为每个人的角色和流程都试图为客户做到最好，但可惜的是，每一个环节对于价值的理解可能都是片面的。只有当整个“价值流图”变得透明时，组织才能从全局的角度快速查看问题，并减少价值流中的浪费现象。
1106
1107 我们将根据一个软件功能升级的场景来展现价值流图样例，详情见下：
1108
1109 近期，由于总部颁布了一系列新的合规要求，部分 IT 服务系统无法满足，因此计划对这类 IT 服务系统进行升级。我们编制了该场景的价值流图如下：
1110
1111
1112 |
1113 | |[[image:image-20200615180117-8.png]]
1114
1115 图4-10 软件功能升级场景价值流图
1116
1117
1118 为了便于理解，这里，我们采用列表的方式将该价值流所经历的价值链活动以及对应的实践活动展示出来，帮助大家思考各个 ITIL 4 实践在服务价值链活动中的作用。
1119
1120
1121 表4-5：软件功能升级场景价值流活动
1122
1123 | |(% colspan="2" style="width:160px" %)价值链活动输入/输出|(% colspan="2" style="width:185px" %)(((
1124
1125
1126 ITIL实践
1127 )))|(% colspan="2" style="width:140px" %)(((
1128
1129
1130 实践角色
1131 )))|(% colspan="2" style="width:667px" %)(((
1132
1133
1134 实践活动
1135 )))
1136 | |(% colspan="2" style="width:160px" %)(((
1137 需求
1138 )))|(% colspan="2" style="width:185px" %) |(% colspan="2" style="width:140px" %)法务总监合规经理|(% colspan="2" style="width:667px" %)了解到不少IT服务系统需要升级来满足新的合规性要求。
1139 | |(% colspan="2" style="width:160px" %)(((
1140
1141
1142 契动
1143 )))|(% colspan="2" style="width:185px" %)(((
1144
1145
1146 关系管理
1147 )))|(% colspan="2" style="width:140px" %)(((
1148
1149
1150 法务总监合规经理CIO
1151 )))|(% colspan="2" style="width:667px" %)(((
1152
1153
1154 讨论新的监管要求，并商定将创建一个项目来管理实施工作。
1155 )))
1156 | |(% colspan="2" style="width:160px" %)(((
1157
1158
1159 获取/构建
1160 )))|(% colspan="2" style="width:185px" %)(((
1161
1162
1163 软件开发和管理、服务验证和测试 服务设计
1164 )))|(% colspan="2" style="width:140px" %)(((
1165
1166
1167 软件开发团队
1168 )))|(% colspan="2" style="width:667px" %)(((
1169
1170
1171 每个软件团队管理一个待办事项并为他们分配部分开发代码。每个团队还通过自动化流水线进行开发测试。所有代码每天都自动集成和测试两次，确保不同团队编写的代码能协同工作。
1172 )))
1173 | |(% colspan="2" style="width:160px" %)(((
1174
1175
1176 设计和转换契动
1177 )))|(% colspan="2" style="width:185px" %)(((
1178
1179
1180 项目管理
1181
1182 服务验证和测试服务设计
1183 )))|(% colspan="2" style="width:140px" %)(((
1184 项目经理
1185
1186 IT开发经理
1187
1188 软件开发团队
1189
1190 合规经理
1191 )))|(% colspan="2" style="width:667px" %)(((
1192
1193
1194 讨论并商定了发布和部署计划。在部署开始之前，批准了需要测试的级别以及发放授权给每个部署的人员。
1195 )))
1196 | |(% colspan="2" style="width:160px" %)(((
1197 获取/构建设计和转换
1198 )))|(% colspan="2" style="width:185px" %)(((
1199 服务设计
1200
1201 组织变更管理部署管理
1202
1203 服务配置管理
1204 )))|(% colspan="2" style="width:140px" %)(((
1205
1206
1207 软件开发团队
1208 )))|(% colspan="2" style="width:667px" %)(((
1209
1210
1211 新软件的部署工作一旦准备就绪，就会立即启动。对此不再需要变更批准，因为风险评估已提前完成，自动化确保了代码的部署完全按照计划进行。配置数据用于驱动部署，因此不需要单独的活动来更新。
1212 )))
1213 |(% colspan="2" %)(((
1214
1215
1216 契动
1217
1218 设计和转换
1219 )))|(% colspan="2" style="width:167px" %)(((
1220
1221
1222 项目管理发布管理服务台
1223
1224 服务目录管理
1225 )))|(% colspan="2" style="width:202px" %)(((
1226
1227
1228 项目经理
1229
1230 软件开发团队产品经理
1231
1232 服务目录经理
1233 )))|(% colspan="2" style="width:406px" %)(((
1234
1235
1236 新功能通过功能开关来发布的，该开关允许用户可以看到新功能。服务台和其他同事得到通知，新功能已经可以使用。同时服务目录已被更新。
1237 )))|
1238 |(% colspan="2" %)(((
1239
1240
1241 价值改进
1242 )))|(% colspan="2" style="width:167px" %)(((
1243
1244
1245 项目管理服务设计关系管理持续改进
1246 )))|(% colspan="2" style="width:202px" %)(((
1247
1248
1249 项目经理开发经理法务总监CIO
1250
1251 合规经理
1252 )))|(% colspan="2" style="width:406px" %)(((
1253
1254
1255 对该项目进行了审查和关闭。寻找改进机会并将其添加到持续改进登记册中。
1256 )))|
1257 |(% colspan="2" %)(((
1258
1259
1260 价值
1261 )))|(% colspan="2" style="width:167px" %) |(% colspan="2" style="width:202px" %)(((
1262 项目经理CIO
1263
1264 法务总监
1265
1266 合规经理
1267 )))|(% colspan="2" style="width:406px" %)(((
1268
1269
1270 更新的服务符合新合规要求。
1271 )))|
1272
1273 通过价值流的形式构建组织 IT 服务价值交付的价值链活动，使组织能够清楚地了解其提供的服务内容和方式，可视化了解价值的创造过程，不断发现价值增长过程中的瓶颈和浪费，不断改进服务。这是 ITIL 4 中所提倡的。因此识别和理解组织的各种价值流，对于提高组织整体绩效至关重要。设计完成后，价值流应该不断改进。价值流优化可能包括流程自动化或新兴技术的采用以及提高效率或增强用户体验的工作方式。上述的价值流图还可以进一步被深化应用，例如基于某一个工作周期的总绩效，以量化的方式通过价值链看板实时动态呈现。又例如可以在各个价值链活动阶段进行价值统计， 让客户对实时获得的价值一目了然，增加对 IT 服务提供方所创造的价值的认同；也让 IT 服务内部团队看清自身所创造的价值，针对瓶颈和浪费，进行持续改进。这些都将是有益的尝试。
1274
1275 值得一提的是，如果我们可以根据客户预期的价值，甚至在契动阶段就将客户引入，去制定共同的视图，则价值流图可以更全局化和端到端，使得服务提供方和服务消费方的联合价值共创更高效、更敏捷。
1276
1277 == Q26：ITIL 4和DevOps的关系？ ==
1278
1279
1280 ITIL 4 对过往的框架进行了重大变革，融合了各类最新的管理方法、思想和工具。其中包括近年来一直被认为挑战其江湖地位的 DevOps。在当今的 IT 服务管理领域中，两者存在着一定的交集，有些体现在理念、思维和指导原则层面，有些体现在产品和工具层面。细看这对“相爱相杀”的冤家， 相互学习，相互追赶超越，真的相映成趣，别有一番风景。我们尝试分析一下个中的异同。
1281
1282 相同之处：
1283
1284 1. 原则相互映射：DevOps 有三步工作法，每一个方法均有多个指导原则，而 ITIL 4 则有七项指导原则。ITIL 4 鼓励跨组织的协作和沟通，并为快速实现变更提供了更多的指导。过去 ITIL 强调规范、流程，而 DevOps 强调敏捷；而今天，从 ITIL 4 七项指导原则来看，其已充分吸收 DevOps“流动，反馈，持续学习和实验”的三步工作法的指导思想，使之为己所用。
1285
1286 |
1287 | |[[image:image-20200615180118-10.jpg]]
1288
1289 图4-11 DevOps三步工作
1290
1291 1. (((
1292 DevOps 的流动是为了加速从开发到运维的价值交付，而 ITIL 4 定义了价值流以及通盘思考和工作的指导原则。通过整体和系统的思考，聚焦于价值的传递和交付之上。
1293
1294 * DevOps 有反馈以建立更安全系统的工作制度，而 ITIL 4 定义了基于反馈的迭代推进以及持续改进。通过找到改进点与改进机会，进行优先级排序，消除瓶颈，从而不断地提升组织的管理能力与管理效率，让有效的反馈成为驱动改善系统控制回路的最大动力。
1295 * DevOps 有持续学习和实验，促进高度信任，形成“无谴责”的文化，将风险承担作为日常工作的一部分；而 ITIL 4 定义了从你所处的地方开始、通盘思考和工作、协作和提升可视化程度的原则以及持续改进的方法。通过工作中掌握的技能和与现有的工具来结合实践，形成更有效的价值链。
1296 )))
1297 1. 目的一致：双方都要求有可视化的价值流，需要通过可视化来管理价值的流动，最终都是追求从端到端打通为用户交付价值的链条，并且强调工作的可视化要考虑全局而不是局部，如果仅仅度量开发的完成率、度量系统的可用性，这些都只是局部的目标。两者都是更关注全局、端到端的价值流动。
1298
1299 相异之处：
1300
1301 1. 在各自体系中将对方所置的地位不同：在 ITIL 4 中，DevOps 被当作在服务设计和转换以及获取 / 构建阶段的执行者。而在 DevOps 知识体系中，ITIL 被一定程度地矮化，仅在运营与周期终止阶段作为一个轻量级的 ITSM（EOL）引入，重点保证 IT 架构和系统的连续性。
1302
1303 1. 发展理念不同：ITIL 4 中虽然扩展了关于价值、价值流、价值共创等理念，但是实际在做“减法”， 部分实践的方法指导相对旧版要显得抽象一些，这样为组织能更好、更简单、更灵活地应用 ITIL 以及适配未来层出不穷的新技术、新思维、新方法预留了弹性空间，也为广大 ITIL 爱好者们指明了更合适的演进路径。而 DevOps 尤其是在 2.0 版本中，开始做“加法”。其已经不再满足只是一条单纯的持续交付工具链或者一项敏捷的工作方法，它开始引入 Lean IT、敏捷等实践方法，试图定义整个ITSM 生态，并成为一种特有的文化。
1304
1305 那么两者是否能够进行整合或相互兼容，从而携手支持更短的交付周期，优化业务的上市时间并实现更高的部署频率呢？答案是可以的。从 ITIL 4 的视角看去，因为 DevOps 方法基于敏捷软件开发和持续交付的自动化技术，强调软件开发和技术操作之间的紧密协作，因此可利用高度自动化来节省专业技术人员的时间，使他们能够专注于增值活动，让 DevOps 能够提升软件产品的可操作性、可靠性和可维护性等。而DevOps 从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动， 以便产品和服务团队保持相同的目标并使用相同的方法。
1306
1307 DevOps 被认为是结合了软件开发技术（敏捷）、价值共创（ITIL 4），以及对学习和改进价值生产方式（精益）执着追求的整体方法。在 ITIL 4 中，组织面临的主要挑战之一是确定其特定的价值流。DevOps 是一个很好的ITIL 4 价值流实例，其涵盖了从业务需求、开发、测试、发布计划到部署的活动。因此，采用或借用 DevOps 方法将为改进软件产品的开发和管理方式提供更多机会，例如：
1308
1309 * 创建从交付和支持到软件开发和技术操作的快速反馈循环；
1310 * 简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值；
1311 * 分离部署管理与发布管理；
1312 * 倡导“整体系统视图”，强调企业治理，促进服务团队、软件开发和技术运维之间的紧密协作。
1313
1314 DevOps 将在 ITIL 4 服务目录管理、服务级别管理、变更管理、配置管理、发布管理、部署管理等实践中大展拳脚。
1315
1316 == Q27：ITIL 4和项目管理的关系？ ==
1317
1318
1319 在 2017 年，美国项目管理协会（PMI）更新了项目管理知识体系（PMBOK）。至此 PMBOK 升级为第 6 版。在第 6 版中，变动并不是太大。知识体系更结构化和标准化；对六个知识领域进行了微调， 并给出了知识领域的剪裁指南和敏捷化指南；取消了“项目管理过程”，提出了“项目经理的角色（The Role of Project Manager）”的概念。
1320
1321 新版本并未改变对项目的定义，仍为“为创造独特的产品、服务或成果而进行的临时性工作”。这直接意味着服务交付是项目类型之一，其中可交付的是客户请求的实际服务。根据 PMBOK 指南区分项目的主要特征，以及服务交付如何满足这些特征，我们可以看到以下几个特点：
1322
1323 * 临时（temporary:）：项目是一项临时的工作，有一个开始和一个结束。服务在其服务价值链中经历了从收到的需求 / 机会开始，到向客户交付价值的连续阶段，而持续改进、治理、实践、指导原则围绕着所有活动。
1324 * 独特的产品、服务或成果（unique product，service，or result）：一个项目的交付物被认为是独特的，不像在运营活动中的重复性活动，这是通过响应特定需求交付给特定客户的 IT 服务来满足的。
1325 * 渐进明细（progressive elaboration）：项目执行是迭代的，并且不断地循序渐进以响应变更，这可以通过 ITIL 4 框架中的持续改进以及基于反馈的迭代推进，以及相关实践来满足。
1326
1327 在过往，我们可以将 ITIL v3/2011 的生命周期与 PMBOK 的五大过程组粗略地做一个映射。服务战略对应启动过程与规划过程；服务设计、服务转换、服务运营对应执行过程，持续服务改进对应监控过程，服务退役对应收尾过程——ITIL v3/2011 并没有这个阶段，我们选择了最接近“关闭”的术语。
1328
1329 但在 ITIL 4 的时代，将 IT 服务交付视为项目表明项目管理的概念和原则与 IT 服务管理的概念
1330
1331 和原则之间存在必要的相似性或对应关系，我们舍易取难，根据 PMBOK 第 6 版的 5 大过程组和 49 个过程，与 ITIL 4 框架下的 34 个实践进行了映射和集成。我们考虑了应用每个 PMBOK 流程时应该考虑的实践，在特定情况下适用的过程集取决于特定的项目需求。在下表中，将概述这些交点。从 PMBOK 指南的角度看项目管理，从 ITIL 4 框架的角度看 IT 服务管理。
1332
1333 [[image:1592219175956-363.png]]
1334
1335 图4-12 ITIL 4-PMBOK第6版映射图
1336
1337
1338 ITIL 4 将项目管理作为一项实践，其与风险管理一样，穿插于不少的实践过程中。项目管理实践的目的是确保组织中的所有项目都能成功交付，这需要通过规划、指派、监控和维护对项目所有方面的控制，并保持相关人员的积极性来实现的。项目是向组织引入重大变更的手段之一，它们可以被定义为为了根据商定的业务案例提供一个或多个输出（或产品）而创建的临时结构。对于更复杂的转型项目，它们可能是一个独立的计划，也可能是一个更大的计划的一部分，以及其他相互关联的项目。但是，即使是独立项目也应该在组织的项目组合中考虑。最终，ITIL 4 通过调和项目管理与 ITIL 4 众多实践之间的关系，使各实践能与项目管理保持一致。
1339
1340 == Q28：ITIL  4和TOGAF的结合关系？ ==
1341
1342
1343 谈及架构管理，各位脑海肯定会浮现出 TOGAF。在 2018 年，TOGAF 也从旧版本 9.1 升级为 9.2。该标准经过重新设计，并重组为较小的出版物，其中包括了一些单独的指南。在新版标准中，TOGAF 框架的核心保持不变，增强了业务架构和内容元模型，对热点技术创新领域进行系统化的设计。TOGAF 目前分为六部分，包括：简介、架构开发方法（ADM）、架构开发方法指南和技术、体系结构内容框架、企业连续性工具以及体系架构能力框架。其架构开发方法见下图：
1344
1345
1346 |
1347 | |[[image:image-20200615180154-12.jpg]]
1348
1349 图4-16 TOGAF架构开发方法
1350
1351
1352
1353 TOGAF 列出了四种被广泛接受的子架构：
1354
1355 * 业务架构：定义了商业策略、管理、组织和关键业务流程；
1356 * 应用架构：为待配置的应用系统提供一个蓝图，从他们的交互、他们的关系到该组织核心的业务流程；
1357 * 数据架构：描述一个组织逻辑的和物理的数据资产和数据管理资源的结构；
1358 * 技术架构：描述了支持核心部署和关键任务应用的软件基础设施。
1359
1360 四种子架构，可以认为是 TOGAF 对 IT 世界的一种抽象的归纳。回想起 ITIL，也有这么一个术语与之匹配，那就是 CMDB（配置管理数据库）。我们的 CMDB 基于消费的情况来进行配置，当系统比较复杂，使用精度要求比较高的情况下，CI（配置项）同样可以按照业务、应用、数据、技术四类来进行分类。从最前端的业务开始，将 CI 最终分解到基础架构上去，并且其后带着 CI 之间上下、平行、互相引用等关系。
1361
1362 ITIL 4 将架构管理作为实践之一，纳入其 SVS 框架。该实践的目的是提供对构成组织的所有不同元素的理解以及这些元素之间如何相互关联，从而使组织能够有效地实现其当前和未来的目标。它提供了原则、标准和工具，使组织能够以结构化和敏捷的方式管理复杂的变更。这些不仅包括如何提高效率和自动化，还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹性。如果没有通过适当的架构管理实践来实现可见性和协调，最终组织只会获得一个传统架构下的迷宫，任何变化都难以实施，并具有极高的风险。
1363
1364 完整的体系架构管理实践应该涉及所有体系架构域：业务，服务，信息，技术和环境。对于规模较小且不太复杂的组织，可由架构师开发单一的集成架构。
1365
1366 * 业务架构：允许组织查看其能力，了解它们如何与为组织及其客户创造价值所需的所有具体活动保持一致。然后将这些与组织的策略进行比较，并执行目标状态与当前能力的差距分析。确定基线和目标状态之间的已确定差距的优先级，并逐步解决这些能力差距。以“路线图”的方式，描述了从当前状态到未来状态的转变，以实现组织的战略。
1367 * 服务架构：服务结构为组织提供了其提供的所有服务的视图，包括描述架构的服务和服务模型之间的交互（服务组件如何组合在一起）和每个服务的动态（活动、资源流和交互）。服务模型可以用作多个服务的模板或蓝图。
1368 * 信息架构：描述了组织的逻辑和物理数据资产以及数据管理资源。它显示了如何管理和共享信息资源以使组织受益。
1369 * 技术架构：定义了支持产品和服务组合所需的软件和硬件基础架构。IT 系统的运作往往需要依赖架构。组织提供服务时，受到挑战的往往是 IT 系统的综合能力，例如在双十一的凌晨，各大电商的后台如何处理突然倍速暴增的订单，这对该组织技术架构的弹性提出了巨大的挑战。
1370 * 环境架构：描述了影响组织的外部因素和变革的驱动因素，以及环境控制及其管理的所有方面、类型和水平。环境包括发展、技术、商业、运营、组织、政治、经济、法律、监管、生态和社会影响。
1371
1372 在应用过程中，ITIL 4 对 TOGAF 的架构开发方法，进行充分地融合。由于 TOGAF 本身所具有的开放性和灵活性，因此不会排斥组织中对其他框架理论的引入和使用，这当然也包括了 ITIL 4。企业架构开发方法各阶段的输入与输出可以不拘泥于其定义，可采用适合组织自身情况的其他框架中所定义的相关内容，并作适当的剪裁，甚至各阶段的先后顺序也是可以调整的。在架构管理的过程中，同样需要采用“持续优化”的方式，进行循环的迭代。
1373
1374 通过 TOGAF 的应用，能够为组织增加弹性、提高敏捷性、增加收入、降低成本以及整合横跨竖井的应用和组织。这些恰恰都是 ITIL 4 所需要的！组织在刚进行架构管理的时候，难免会因为架构的缺乏和粗略而举步维艰。但随着一个又一个架构被开发出来，被应用与管理，架构管理的循环持续进行着，则架构管理的内容将日趋丰富和成熟，从而架构的开发也会越发轻快，架构的管理也会越发纯熟。
1375
1376 总而言之，ITIL 4 将架构管理纳入实践，可以很好地将 TOGAF 的架构设计和演进方法引入服务的价值交付过程中，通过更优化的架构来为客户创造更大的价值。
1377
1378
深圳市艾拓先锋企业管理咨询有限公司