Changes for page 第4章 ITIL 4学习与实践FAQ

Last modified by superadmin on 2024/12/25, 15:27

From version < 25.1 >

edited by superadmin
on 2020/06/15, 19:07

To version < 23.1 >

edited by superadmin
on 2020/06/15, 18:48

< >

Change comment: 上传新附件1592218120707-101.png

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)
Attachments (0 modified, 0 added, 1 removed)
- 1592219175956-363.png

Details

Page properties

Content

@@ -14,13
          +14,14 @@
  我们可以从 ITIL 4 作者之一 Stuart Rance 的话中得到一些启示。Stuart Rance 是 ITIL 的资深作者和IT 行业权威，他在一篇名为《ITIL v3/2011 有什么问题？》的博文中，指出了 ITIL v3/2011（或者更准确地说，ITIL v3/2011 版本）需要更新的五个关键原因：
--* ITIL v3/2011 过于关注过程；
--* 需要在竖井中实现（组织分别运作每个流程），尤其是服务战略→服务设计→服务转换→服务运营→持续服务改进的生命周期模式，实在是太像传统的瀑布式服务交付模型了；
--* 对价值、成果、成本和风险的关注太少；
--* 需要支持数字化转型；
--* 需要与敏捷、精益、DevOps 和其他管理方法兼容。
++*
++** ITIL v3/2011 过于关注过程；
++** 需要在竖井中实现（组织分别运作每个流程），尤其是服务战略→服务设计→服务转换→服务运营→持续服务改进的生命周期模式，实在是太像传统的瀑布式服务交付模型了；
++** 对价值、成果、成本和风险的关注太少；
++** 需要支持数字化转型；
++** 需要与敏捷、精益、DevOps 和其他管理方法兼容。
--       考虑到 Stuart 是 ITIL 4 的作者，可以假设这些原因不仅反映了 ITIL v3/2011 的问题，也反映了 ITIL 4 的变化。这次 ITIL 更新加强与业务策略的联系，并维持以前 ITIL 版本的仍然有价值的核心元素。
++考虑到 Stuart 是 ITIL 4 的作者，可以假设这些原因不仅反映了 ITIL v3/2011 的问题，也反映了 ITIL 4 的变化。这次 ITIL 更新加强与业务策略的联系，并维持以前 ITIL 版本的仍然有价值的核心元素。
  == Q3：个人认证方面，ITIL 4有哪些选择？应该如何选择学习路径？ ==
@@ -31,7
          +31,7 @@
  [[image:image-20200615172119-2.jpg]]
--                                                             图4-1 ITIL 4认证体系图
++图4-1 ITIL 4认证体系图
  与 ITIL v3/2011 一致的是，在基础级之上是左右两路分支，ITIL v3/2011 左右两路是对称的， 无论从左路或是右路进行学习，均等价，最后都可以从任一单路分支申请 Master。但 ITIL 4 左右两路却变成了不对称的互补形态，学习者必须完整学完左右两路所有课程，才可能申请最高级别的ITIL 4 Master。
@@ -38,14
          +38,16 @@
  ITIL 4 的进阶路径，包含了：
--* 左路 ITIL Managing Professional （ITIL MP 管理专家），其中包含 4 门中级模块（3 门专业认证课程和 1 门战略师认证课程），主要面向跨业务的技术和数字团队中的 IT 从业者，相关课程提供如何成功运行 IT 项目、团队和工作流方面的实用技能知识。
--* 该进阶路径具体包含的课程内容如下：中级课程：ITIL Specialist ITIL 专业认证课程：
++*
++** 左路 ITIL Managing Professional （ITIL MP 管理专家），其中包含 4 门中级模块（3 门专业认证课程和 1 门战略师认证课程），主要面向跨业务的技术和数字团队中的 IT 从业者，相关课程提供如何成功运行 IT 项目、团队和工作流方面的实用技能知识。
++** 该进阶路径具体包含的课程内容如下：中级课程：ITIL Specialist ITIL 专业认证课程：
  ITIL 专家 Create，Delivery & Support-CDS（创建、交付和支持）
--* 中级课程：ITIL 专家 Drive Stakeholder Value -DSV（驱动干系人价值）
--* 中级课程：ITIL Specialist ITIL 专业认证课程：High Velocity IT-HVI（高速 IT）
--* 中级课程：ITIL 战略 Direct，Plan & Improve-DPI（指导、计划和优化）。
++*
++** 中级课程：ITIL 专家 Drive Stakeholder Value -DSV（驱动干系人价值）
++** 中级课程：ITIL Specialist ITIL 专业认证课程：High Velocity IT-HVI（高速 IT）
++** 中级课程：ITIL 战略 Direct，Plan & Improve-DPI（指导、计划和优化）。
  据目前官方消息，MP 中四门课程模块将分两批于 2019 年 11 月和 2020 年 Q1 正式对外发布。
@@ -55,12
          +55,14 @@
  则只需要考取 ITIL 领导者 - Digital & IT Strategy（数字化和 IT 战略）认证即可。
--* 右路 ITIL Strategic Leader（ITIL SL 战略领导者）包括两门中级模块（包含 1 门战略师认证课程和 1 门领导者认证课程），课程着眼于体现 ITIL 的价值，跳出 IT 运营的框架，考虑更全面的数字化服务，经过认证的专家将在 IT 如何影响和指导业务战略方面有出众的表现。
++*
++** 右路 ITIL Strategic Leader（ITIL SL 战略领导者）包括两门中级模块（包含 1 门战略师认证课程和 1 门领导者认证课程），课程着眼于体现 ITIL 的价值，跳出 IT 运营的框架，考虑更全面的数字化服务，经过认证的专家将在 IT 如何影响和指导业务战略方面有出众的表现。
  进阶路径具体包含的课程内容如下：
--* ITIL 战略 Direct，Plan & Improve - DPI（指导、计划和优化）
--* ITIL 领导者 Digital & IT Strategy -DIS（数字化和 IT 战略）
++*
++** ITIL 战略 Direct，Plan & Improve - DPI（指导、计划和优化）
++** ITIL 领导者 Digital & IT Strategy -DIS（数字化和 IT 战略）
  若需获得ITIL 战略领导者认证资格，学习者需通过该路径中的 2 门认证培训和考试（DPI&DIS）。值得注意的是，报考 ITIL 战略领导者资格认证的学习者除了必须具有 ITIL 4 基础认证外，还需同时具备三年或以上的管理经验。
@@ -71,11
          +71,12 @@
  对 IT 服务有兴趣的从业或非从业者，都可以学习 ITIL 4 基础级。一般而言，学习对象主要有以下几类人士：
--* 信息中心主任、CIO、IT 运维经理、数据中心经理；
--* IT 运维人员、IT 项目经理、软件 / 系统开发主管；
--* IT/ 业务经理、资深 IT 人员、IT 支持服务主管；
--* IT 客户服务人员、Helpdesk 经理；
--* IT 咨询顾问、IT 服务管理工具实施核心人员。
++*
++** 信息中心主任、CIO、IT 运维经理、数据中心经理；
++** IT 运维人员、IT 项目经理、软件 / 系统开发主管；
++** IT/ 业务经理、资深 IT 人员、IT 支持服务主管；
++** IT 客户服务人员、Helpdesk 经理；
++** IT 咨询顾问、IT 服务管理工具实施核心人员。
  == Q5：为什么没有ITIL 4基础级过渡模块？ ==
@@ -87,10
          +87,11 @@
  与 ITIL v3/2011 对比，ITIL 4 进一步演进，创建了服务价值系统（SVS），其改进内容可以归纳为以下五个主要方面：
--* 推出了 SVS、SVC 全新框架，符合当前数字化转型的大趋势和方向；
--* 改流程为实践，将流程、技术、人员和管理方法整合为同一概念，不再割裂地看待 IT 服务管理要素；
--* 将分阶段、瀑布式的服务生命周期改为贯穿端到端的服务价值链；
--* 与敏捷、精益、DevOps、云计算、大数据等最新管理思想和技术作了结合和融合。更强调业务价值；
++*
++** 推出了 SVS、SVC 全新框架，符合当前数字化转型的大趋势和方向；
++** 改流程为实践，将流程、技术、人员和管理方法整合为同一概念，不再割裂地看待 IT 服务管理要素；
++** 将分阶段、瀑布式的服务生命周期改为贯穿端到端的服务价值链；
++** 与敏捷、精益、DevOps、云计算、大数据等最新管理思想和技术作了结合和融合。更强调业务价值；
  总而言之，ITIL v3/2011 包含了服务管理中的 26 个流程和职能，各流程与职能散落于服务生命周期的五个阶段中：服务战略、服务设计、服务转换、服务运营和持续服务改进。而在ITIL 4中引入的服务生命周期消失了，采用了不同的呈现方式，使用 SVS 来展示机会/需求如何转化为价值。
@@ -100,7
          +100,7 @@
  |
  | |[[image:image-20200615172119-3.jpg]]
--               图4-2 ITIL v2、ITIL v3/2011与ITIL v3/2011流程与职能示意图
++图4-2 ITIL v2、ITIL v3/2011与ITIL v3/2011流程与职能示意图
  取而代之的是，ITIL 4 引入服务价值系统 SVS，它包括了一系列指导原则、治理、SVC 活动以及一套合计 34 个实践和持续改进。ITIL 4 的SVC 与ITIL v3/2011 的服务生命周期之间的巨大差异在于， 采用热图的方式将所有实践在 SVC 中呈现。
@@ -115,24
          +115,25 @@
  表4-1：ITIL 4中的新内容与ITIL v3/2011关联
++
  |(% colspan="3" %)(((
  [[image:image-20200615172150-4.png]]
  ITIL 4组件 vs. ITIL v3/2011
  )))
--|(% style="width:174px" %)ITIL 4组件|(% style="width:477px" %)ITIL 4中的新内容|(% style="width:426px" %)与ITIL v3/2011的关联
++|(% style="width:94px" %)ITIL 4组件|(% style="width:420px" %)ITIL 4中的新内容|(% style="width:559px" %)与ITIL v3/2011的关联
  |(% colspan="3" %)ITIL 4关键概念
--|(% style="width:174px" %)(((
++|(% style="width:94px" %)(((
  服务管理的关键概念
--)))|(% style="width:477px" %)(((
++)))|(% style="width:420px" %)(((
  ·ITIL 4更注重价值创造，并更详细地解释了这个概念。
--)))|(% style="width:426px" %)·其中一些概念在ITIL v3/2011出版物的介绍性章节中进行了讨论（请参阅“服务管理作为实践”一章）。
++)))|(% style="width:559px" %)·其中一些概念在ITIL v3/2011出版物的介绍性章节中进行了讨论（请参阅“服务管理作为实践”一章）。
  |(% colspan="3" %)ITIL 4四维模型
--|(% style="width:174px" %)(((
++|(% style="width:94px" %)(((
@@ -141,7
          +141,7 @@
  服务管理的四个维度
--)))|(% style="width:477px" %)(((
++)))|(% style="width:420px" %)(((
  ·ITIL 4定义了四个维度，应该考虑这些维度来确保服务管理的整体方法：
 .人员；
@@ -154,8
          +154,10 @@
  ·这些维度适用于一般的服务价值系统系统和特定的服务。
--·虽然流程在ITIL v3/2011中很重要，但ITIL 4与流程以及价值流相关，价值流描述了如何为客户和用户创建价值。
--)))|(% style="width:426px" %)(((
++·虽然流程在ITIL v3/2011中很重要，但ITIL 4与流程以及价值流相关，价值流描述
++
++了如何为客户和用户创建价值。
++)))|(% style="width:559px" %)(((
@@ -164,13
          +164,19 @@
  （4Ps）。
  )))
  |(% colspan="3" %)ITIL 4服务价值系统（SVS）
--|(% style="width:174px" %)(((
++|(% style="width:94px" %)(((
++
++
++
++
++
++
  服务价值系统概览
--)))|(% style="width:477px" %)(((
++)))|(% style="width:420px" %)(((
  ·服务价值系统（SVS）是ITIL 4中的一个新概念。SVS描述了“组织中的所有组件和活动如何协同工作以实现价值创造”
  ·ITIL 4服务价值系统包括五个部分： 1.指导原则；
@@ -184,29
          +184,46 @@
 .实践。
  ·ITIL 4和SVS采取了更全面的方法，为组织提供了一个灵活的运营模型，并支持不同的工作方法。ITIL 4没有定义特定的ITIL 4 流程，但实践事实上主要由流程组成，服务提供者可以自由地设计为其组织工作的定制流程。
--)))|(% style="width:426px" %)(((
++)))|(% style="width:559px" %)(((
++
++
++
  ·ITIL v3/2011拥有26个服务生命周期流程、职能和其他指南；其还描述了组织中的组件和活动如何协同工作。
  )))
--|(% style="width:174px" %)(((
++|(% style="width:94px" %)(((
++
++
  指导原则
--)))|(% style="width:477px" %)(((
++)))|(% style="width:420px" %)(((
++
++
  ·ITIL 4指导原则是通用的建议，可以在许多情况下指导组织，例如“通盘思考和工作”和“保持简单和实用”。
--)))|(% style="width:426px" %)·这些指导原则并不是原始ITIL v3/2011出版物的一部分，但它们已被ITIL Practitioner（从业者） 采用，这是ITIL v3/2011服务组合的最新添加部分。
--|(% style="width:174px" %)(((
++)))|(% style="width:559px" %)·这些指导原则并不是原始ITIL v3/2011出版物的一部分，但它们已被ITIL Practitioner（从业者） 采用，这是ITIL v3/2011服务组合的最新添加部分。
++|(% style="width:94px" %)(((
++
++
  治理
--)))|(% style="width:477px" %)·ITIL 4服务价值系统的治理组件是关于指导和控制组织的。|(% style="width:426px" %)·ITIL v3/2011在服务策略发布中涵盖了这个主题。
--|(% style="width:174px" %)(((
++)))|(% style="width:420px" %)·ITIL 4服务价值系统的治理组件是关于指导和控制组织的。|(% style="width:559px" %)·ITIL v3/2011在服务策略发布中涵盖了这个主题。
++|(% style="width:94px" %)(((
++
++
++
++
++
++
  服务价值链
--)))|(% style="width:477px" %)(((
++)))|(% style="width:420px" %)(((
++
++
  ·ITIL 4服务价值链是ITIL 4服务价值系统的核心要素。它展示了为客户创造价值所需的关键活动。六个价值链活动是：       1.计划；
 .改进；
@@ -218,48
          +218,44 @@
 .获取/构建；
 .交付和支持。
--)))|(% style="width:426px" %)(((
++)))|(% style="width:559px" %)(((
  ·ITIL v3/2011中的核心元素是包含五个阶段的服务生命周期：服务战略、服务设计、服务转换、服务运营以及持续服务改进。此生命周期与ITIL 4服务价值链并不相同，但是在更详细的级别上，ITIL v3/2011服务生命周期流程中的许多活动都与价值链活动存在大致对应。同时，我们也可以理解为，ITIL v3/2011的生命周期模型为ITIL 4价值链的一个价值流
  实例。
  )))
--|(% style="width:174px" %)(((
++|(% style="width:94px" %)(((
++
  持续改进
--)))|(% style="width:477px" %)(((
++)))|(% style="width:420px" %)(((
  ·ITIL 4持续改进模型描述了一种结构化的方法，用于识别和实现可在组织所有级别使用的改进。
--)))|(% style="width:426px" %)(((
--·
--
--ITIL 4中的持续改进模型包含7个步骤，在某些方面可以与ITIL v3/2011中的7步改进法的过程相比较。
--)))
--|(% style="width:174px" %)(((
++)))|(% style="width:559px" %)·ITIL 4中的持续改进模型包含7个步骤，在某些方面可以与ITIL v3/2011中的7步改进法的过程相比较。
++|(% style="width:94px" %)(((
++
++
  ITIL 4实践
--)))|(% style="width:477px" %)(((
++)))|(% style="width:420px" %)(((
  ·ITIL 4没有使用ITIL v3/2011中26个流程，而是采用了“实践”的说法，将34个实践定义为“一组用于执行工作或完成目标的组织资源”。
--)))|(% style="width:426px" %)(((
--·
++)))|(% style="width:559px" %)·在这些实践中可以看出，ITIL 4明显植根于ITIL v3/2011，因为当中的许多实践，均对应于ITIL v3/2011的流程。
--在这些实践中可以看出，ITIL 4明显植根于ITIL v3/2011，因为当中的许多实践，均对应于ITIL v3/2011的流程。
--)))
--
  == Q8：ITIL 4能为组织带来什么样的好处？ ==
  ITIL 4 将为组织带来如下的好处：
--* 使 IT 服务与业务优先级保持一致，以实现战略目标；
--* 提高服务组合的价值，同时降低成本和风险；
--* 提高 IT 员工的岗位胜任力、工作能力和生产力，更好地利用员工的技能和经验；
--* 提高用户和客户对服务 / 产品的满意度以及最终用户感知；
--* ITIL 4 提供了一个整体的端到端视图，与精益IT、敏捷和DevOps 等新工作模式进行了整合。
++*
++** 使 IT 服务与业务优先级保持一致，以实现战略目标；
++** 提高服务组合的价值，同时降低成本和风险；
++** 提高 IT 员工的岗位胜任力、工作能力和生产力，更好地利用员工的技能和经验；
++** 提高用户和客户对服务 / 产品的满意度以及最终用户感知；
++** ITIL 4 提供了一个整体的端到端视图，与精益IT、敏捷和DevOps 等新工作模式进行了整合。
  == Q9： 对 于 ITIL 4 中 的 服 务 管 理 四 个 维 度， 我 们 如 何 结 合ITIL v3/2011 的 4P 进行理解？ ==
@@ -266,10
          +266,11 @@
  ITIL 4 将 ITIL v3/2011 中的 4P 概念进行了极大的扩展，使其能支持整体的服务管理方法，详见下图。
++
  |
  | |[[image:image-20200615172150-5.jpg]]
--                                                          图4-3 ITIL 4服务管理四维模型
++图4-3 ITIL 4服务管理四维模型
  这四个维度不仅限于服务生命周期，还包括了带有所有价值流和实践的整个服务价值系统。但我们在使用四维度模型时，必须适当考虑所有四个方面，从而满足服务质量和效率的期望。值得一提的是， 各维度覆盖的范围难以精确描绘且具有许多重叠的边界。因此，在多供应商环境下，供应商的人员以及为其服务的员工都将被包括在内。实际上，我们需要考虑每个服务的所有四个维度并按需调整。
@@ -288,9
          +288,10 @@
  信息管理也需要加以区分，我们需要了解：
--* 服务提供和管理的是哪些信息？
--* 提供和确保服务需要哪些信息和知识？
--* 这些信息和知识如何作为企业的资源被保护、获取、存档甚至删除？
++*
++** 服务提供和管理的是哪些信息？
++** 提供和确保服务需要哪些信息和知识？
++** 这些信息和知识如何作为企业的资源被保护、获取、存档甚至删除？
  信息管理必须是整体的，因为信息的处理无法在应用程序中单独完成。因此，必须清楚如何提供信息并与其他（可能是外部）服务进行交互。有必要对信息进行分类，并根据内部法规甚至 GDPR 等监管要求对其进行处理。
@@ -302,20
          +302,22 @@
  影响供应商使用战略的因素包括：
--* 战略重点：什么是组织的核心业务，我们从合作伙伴那里获得什么？
--* 企业文化：过去与合作伙伴合作过什么？我们具有何种经验？
--* 资源准备：我们可以自行开拓某些资源还是需要供应商的帮助？
--* 成本考虑：中长期来看，更经济的做法是什么？
--* 专业能力：如果我们需要合作伙伴的专业知识，我们是否拥有必要的专业知识或能否更快地采取行动？
--* 外部限制：是否有必要在供应商战略中考虑相关外部规则？在分析外部因素时，我们可以考虑采用 PESTEL 分析法，见下图。
++*
++** 战略重点：什么是组织的核心业务，我们从合作伙伴那里获得什么？
++** 企业文化：过去与合作伙伴合作过什么？我们具有何种经验？
++** 资源准备：我们可以自行开拓某些资源还是需要供应商的帮助？
++** 成本考虑：中长期来看，更经济的做法是什么？
++** 专业能力：如果我们需要合作伙伴的专业知识，我们是否拥有必要的专业知识或能否更快地采取行动？
++** 外部限制：是否有必要在供应商战略中考虑相关外部规则？在分析外部因素时，我们可以考虑采用 PESTEL 分析法，见下图。
  |
  | |[[image:image-20200615172150-6.jpg]]
--                                          图4-4 PESTEL分析法
++图4-4 PESTEL分析法
--* 需求：客户需求是否会受到季节性波动的影响，是否可以在合作伙伴的帮助下实现平衡？
++*
++** 需求：客户需求是否会受到季节性波动的影响，是否可以在合作伙伴的帮助下实现平衡？
  * 价值流和流程
  将 4P 中的“流程”与“价值流”合并，并且将“价值流”放于首位。这个维度涉及整个服务价值系统，但也涉及特别提供个人服务。这包括实现商定目标的所有活动、工作流程、控制和程序。该维度与服务提供商组织和 SVS 相关，着眼于如何集成和协调业务的各个部分，以通过产品和服务增加价值。SVS 是关于确保和组织所有活动，以便为所有相关人员创造有效和高效的价值。为此，必须建立组织的更高级别的运营模式。这种通用的价值链运营模型可以同时包含各种价值流。
@@ -331,25
          +331,33 @@
  您还需要了解两件事情：
--1. 根据目前官方公布的信息，ITIL v3/2011 培训考试计划最早将于 2020 年 6 月不再继续提供。
--1. 从 ITIL v3/2011 升级到 ITIL 4 认证的途径，根据不同的情况，我们给出以下三类建议：
++1.
++11. 根据目前官方公布的信息，ITIL v3/2011 培训考试计划最早将于 2020 年 6 月不再继续提供。
++11. 从 ITIL v3/2011 升级到 ITIL 4 认证的途径，根据不同的情况，我们给出以下三类建议：
--* 情况一，您只拥有 ITIL v2 或 v3 基础级的认证：
++*
++** 情况一，您只拥有 ITIL v2 或 v3 基础级的认证：
  如Q8 所述，您需要从ITIL 4 基础级开始考试。通过ITIL 4 基础级过渡到ITIL 4 的新认证体系中。然后选择自己感兴趣的模块，成为 ITIL 策略师、领导者，甚至大师。
  当然，您也可以选择不升级。不升级其实也没有关系，因为我们相信您拥有一张早期的 ITIL 证书也是倍有面子的。只是，它无法证明您经过了 ITIL 4 的价值链与数字化服务思想的熏陶罢了。
--* 情况二，您拥有 ITIL v3 Expert 的认证：                                                                                                                                                                                                                                比较有性价比的方案是，您通过考取 ITIL Managing Professional 过渡模块（已于 2019 年九月发布），从而获得 ITIL 4 MP 管理专家认证。然后只需再完成 1 门 ITIL 领导者数字和战略模块ITIL Leader Digital & IT Strategy 即可成为 ITIL 4 战略领导者。这样仅需要 2 门课程，即可完成左右两路进阶课程，并将有资格进军 ITIL 4 Master。路线图如下：
++*
++** 情况二，您拥有 ITIL v3 Expert 的认证：
  |
  | |[[image:image-20200615172225-7.png]]
--                                  图4-5 ITIL v3 Expert认证获得者升级ITIL 4建议路线图
++比较有性价比的方案是，您通过考取 ITIL Managing Professional 过渡模块（已于 2019 年九月发布），从而获得 ITIL 4 MP 管理专家认证。然后只需再完成 1 门 ITIL 领导者数字和战略模块ITIL Leader Digital & IT Strategy 即可成为 ITIL 4 战略领导者。这样仅需要 2 门课程，即可完成左右两路进阶课程，并将有资格进军 ITIL 4 Master。路线图如下：
++
++图4-5 ITIL v3 Expert认证获得者升级ITIL 4建议路线图
++
++
  我们还有另外一个建议，如果您已决定选择这条升级路线，请尽早启动学习。因为过渡模块只存在一个不会太长的过渡期中，过渡期后过渡模块将会取消。官方已于 2019 年 10 月正式对外发布过渡模块课程。之前也曾经有一个通过 Bridge 培训考试快速升级成 ITIL v3 Expert 的机会，放在一些拥有 ITIL v2 Manager 认证学习者的面前，但他们错过了，追悔莫及。
--* 情 况 三， 您 已 经 在 ITIL v3/2011 的 认 证 体 系 中 持 有 若 干 门 ITIL v3 OSA/ PPO/RCV/ SOA/ Practitioner 等中级证书但却不足 17 个学分：那么您可以考虑两条路径。
++*
++** 情 况 三， 您 已 经 在 ITIL v3/2011 的 认 证 体 系 中 持 有 若 干 门 ITIL v3 OSA/ PPO/RCV/ SOA/ Practitioner 等中级证书但却不足 17 个学分：那么您可以考虑两条路径。
  路径 1——固本培元：您将从 ITIL 4 基础级开始，夯实基础，重新一步步逐级完成 ITIL 4 的学习。
@@ -376,9
          +376,10 @@
  比较精巧的设计。将流程由“重”转到实践之“轻”。过往不少人一听到 ITIL，第一反应就是一堆流程，万事流程先行。殊不知，单个流程虽然也有意义，但是仍需工具和支撑架构来扶持。实践被定义为“支持多个价值链活动并提供为确保实践成功所需资源的支持，这些资源可以来自供应商和内部的IT 组织”。我们也可以笼统地认为，流程是“一套完成工作的组织机制”。ITIL 4 中归纳为三类实践：
--* 通用管理实践（General Management Practices），共 14 个，包括架构管理、关系管理等；
--* 服务管理实践（Service Management Practices），共 17 个，包括资产管理、问题管理等；
--* 技术管理实践（Technical Management Practices），共 3 个，包括部署管理、基础设施和平台管理、软件开发和管理等。
++*
++** 通用管理实践（General Management Practices），共 14 个，包括架构管理、关系管理等；
++** 服务管理实践（Service Management Practices），共 17 个，包括资产管理、问题管理等；
++** 技术管理实践（Technical Management Practices），共 3 个，包括部署管理、基础设施和平台管理、软件开发和管理等。
  这里有两点值得一提：
@@ -399,45
          +399,50 @@
  |(% colspan="3" %)(((
  [[image:image-20200615172225-8.png]]
--                                                                                       通用管理实践
++通用管理实践
  )))
--|(% style="width:123px" %)(((
++|(((
  ITIL 4
  管理实践
--)))|(% style="width:220px" %)(((
++)))|(((
  ITIL v3/2011中
  相关流程
--)))|(% style="width:734px" %)(((
++)))|(((
  对比
  )))
--|(% style="width:123px" %)(((
++|(((
  架构管理
--)))|(% style="width:220px" %)(((
++)))|(((
--无
--)))|(% style="width:734px" %)(((
++·无
++)))|(((
  ·ITIL v3/2011在服务战略发布中包含了对企业体系架构管理
  的介绍。
  )))
--|(% style="width:123px" %)(((
++|(((
++
++
++
  持续改进
--)))|(% style="width:220px" %)(((
++)))|(((
++
++
  ·七步改进法流程
--)))|(% style="width:734px" %)(((
++)))|(((
  ·ITIL 4中的持续改进是关于持续改进组织的服务、实践和提供服务所需的所有其他要素。
  ·在ITIL v3/2011中，持续服务改进（CSI）是服务生命周期的第五个阶段。ITIL v3 SI出版物描述了CSI的原则、方法和技术，并明确了一个CSI流程：“七步改进法”。
@@ -446,44
          +446,48 @@
  应于服务改进计划（SIP）。
  )))
--|(% style="width:123px" %)(((
++|(((
  信息安全管理
--)))|(% style="width:220px" %)(((
--信息安全管理
++)))|(((
++
++·信息安全管理
++
  ·访问管理
--)))|(% style="width:734px" %)(((
++)))|(((
  ·ITIL 4中安全管理实践中，有提及需要许多流程和程序支持信息安全管理，其中包括“身份和访问管理”，它对应于
  ITIL v3/2011的访问管理流程。
  )))
--|(% style="width:123px" %)知识管理|(% style="width:220px" %)·知识管理|(% style="width:734px" %)·无变化
--|(% style="width:123px" %)(((
++|知识管理|·知识管理|·无变化
++|(((
  测量和报告
--)))|(% style="width:220px" %)(((
++)))|(((
  ·无
--)))|(% style="width:734px" %)(((
++)))|(((
  ·ITIL v3/2011没有定义度量和报告流程，但是度量和报告实际上是多个ITIL v3/2011流程中的关键活动，比如服务级别管
  理和七步改进法。
  )))
--|(% style="width:123px" %)(((
++|(((
++
  组织变革管理
--)))|(% style="width:220px" %)(((
++)))|(((
++
  ·无
--)))|(% style="width:734px" %)(((
++)))|(((
  ·组织变革管理（OCM）是一组管理技术和能力，而不仅是一个流程。
  ·OCM处理变革的人力方面，与ITIL v3/2011的变更管理流程不同——ITIL v3/2011的目标是将生产环境变更所带来的风险最
@@ -490,16
          +490,21 @@
  小化。
  )))
--|(% style="width:123px" %)(((
++|(((
++
  组合管理
--)))|(% style="width:220px" %)(((
++)))|(((
++
++
  ·服务组合管理
  ·业务关系管理
--)))|(% style="width:734px" %)(((
--·ITIL 4中服务组合管理实践，涉及各种类型的服务组合，例如服务、项目和客户组合。在ITIL v3/2011的服务战略中，也包含“客户协议组合”“客户组合”“项目组合”和“服务组合”，在服务设计中，还包含“应用组合”。
++)))|(((
++·ITIL 4中服务组合管理实践，涉及各种类型的服务组合，例如服务、项目和客户组合。在ITIL v3/2011的服务战略中，也包含“客户协议组合”“客户组合”“项目组合”和“服务组
++
++合”，在服务设计中，还包含“应用组合”。
  )))
  续表
@@ -506,28
          +506,29 @@
  |(% colspan="3" %)通用管理实践
--|(% style="width:134px" %)(((
++|(((
  ITIL 4
  管理实践
--)))|(% style="width:210px" %)(((
++)))|(((
  ITIL v3/2011中
  相关流程
--)))|(% style="width:733px" %)(((
++)))|(((
  对比
  )))
--|(% style="width:134px" %)(((
++|(((
++
  项目管理
--)))|(% style="width:210px" %)(((
++)))|(((
  ·转换规划与支持
--)))|(% style="width:733px" %)(((
++)))|(((
  ·ITIL v3/2011的转换规划与支持流程是服务转换生命周期阶段的一部分，主要是关于规划和协调服务转换项目。
  ·ITIL 4项目管理实践的范围更广，其目的是确保组织内所有
@@ -534,17
          +534,17 @@
  项目均顺利完成。
  )))
--|(% style="width:134px" %)(((
++|(((
  关系管理
--)))|(% style="width:210px" %)(((
++)))|(((
  ·业务关系管理
--)))|(% style="width:733px" %)(((
++)))|(((
  ·ITIL v3/2011中的业务关系管理，更强调面向客户，且该流程与服务级别管理有很强的联系。
  ·ITIL 4中的关系管理是指与组织的所有利害关系人（包括客
@@ -551,50
          +551,48 @@
  户）的关系。覆盖范围比ITIL v3/2011更广。
  )))
--|(% style="width:134px" %)(((
++|(((
++
++
  风险管理
--)))|(% style="width:210px" %)(((
++)))|(((
++
++
  ·无
--)))|(% style="width:733px" %)·作为负责识别、评估和控制风险的流程，风险管理并不在ITIL v3/2011流程之列，但风险管理技术在几个ITIL v3/2011 流程中均有进行描述，如变更管理、信息安全管理和IT服务连续性管理流程等，且ITIL v3/2011要求“协调的风险评估演习”。
--|(% style="width:134px" %)(((
++)))|·作为负责识别、评估和控制风险的流程，风险管理并不在ITIL v3/2011流程之列，但风险管理技术在几个ITIL v3/2011 流程中均有进行描述，如变更管理、信息安全管理和IT服务连续性管理流程等，且ITIL v3/2011要求“协调的风险评估演习”。
++|(((
  服务财务管理
--)))|(% style="width:210px" %)(((
++)))|·IT服务的财务管理|(((
--·IT服务的财务管理
--)))|(% style="width:733px" %)(((
--
--
  ·无变化
  )))
--|(% style="width:134px" %)(((
++|(((
  战略管理
--)))|(% style="width:210px" %)(((
++)))|·IT服务的战略管理|(((
--·IT服务的战略管理
--)))|(% style="width:733px" %)(((
--
--
  ·无变化
  )))
--|(% style="width:134px" %)(((
++|(((
++
  供应商管理
--)))|(% style="width:210px" %)(((
++)))|(((
++
  ·供应商管理
--)))|(% style="width:733px" %)(((
++)))|(((
  ·ITIL 4中的供应商管理实践包括关于多源采购和服务集成的新指引（来自SIAM框架的概念）。
  ·ITIL 4放弃了ITIL v3/2011术语基础合同（UC），而是使用
@@ -601,36
          +601,41 @@
  更通用的术语（合同、协议、保修要求等）。
  )))
--|(% style="width:134px" %)劳动力和人才管理|(% style="width:210px" %)(((
++|劳动力和人才管理|(((
++
++
  ·无
--)))|(% style="width:733px" %)·ITIL v3/2011的出版物中，提供了一些关于能力开发和培训的指导。
++)))|·ITIL v3/2011的出版物中，提供了一些关于能力开发和培训的指导。
++
  |(% colspan="3" %)(((
  服务管理实践
  )))
--|(% style="width:137px" %)(((
++|(((
  ITIL 4管理实践
--)))|(% style="width:212px" %)ITIL v3/2011中相关流程|(% style="width:728px" %)(((
++)))|ITIL v3/2011中相关流程|(((
  变化：ITIL 4 vs. ITIL v3
  )))
--|(% style="width:137px" %)可用性管理|(% style="width:212px" %)·可用性管理|(% style="width:728px" %)·无变化
--|(% style="width:137px" %)(((
++|可用性管理|·可用性管理|·无变化
++|(((
++
  业务分析
--)))|(% style="width:212px" %)(((
++)))|(((
++
  ·可用性管理
  ·需求管理
--)))|(% style="width:728px" %)(((
++)))|(((
  ·该ITIL 4实践描述了分析系统、流程、架构等的技术。
  ·其中一些技术应用于ITIL v3/2011流程，例如在
@@ -637,69
          +637,80 @@
  服务设计阶段定义了服务需求。
  )))
--|(% style="width:137px" %)(((
++|(((
  容量和性能管理
--)))|(% style="width:212px" %)(((
++)))|(((
  ·容量管理
  ·需求管理
--)))|(% style="width:728px" %)(((
++)))|(((
  ·无变化
  )))
--|(% style="width:137px" %)(((
++|(((
  变更管理
--)))|(% style="width:212px" %)(((
++)))|(((
  ·变更管理
  ·变更评估
--)))|(% style="width:728px" %)(((
++)))|(((
  ·无变化
  )))
--|(% style="width:137px" %)事件管理|(% style="width:212px" %)·事件管理|(% style="width:728px" %)·无变化
--|(% style="width:137px" %)IT资产管理|(% style="width:212px" %)·服务资产和配置管理|(% style="width:728px" %)·无变化
--|(% style="width:137px" %)监控和事态管理|(% style="width:212px" %)·事态管理|(% style="width:728px" %)·无变化
--|(% style="width:137px" %)问题管理|(% style="width:212px" %)·问题管理|(% style="width:728px" %)·无变化
--|(% style="width:137px" %)(((
++|事件管理|·事件管理|·无变化
++|IT资产管理|·服务资产和配置管理|·无变化
++|监控和事态管理|·事态管理|·无变化
++|问题管理|·问题管理|·无变化
++|(((
++
++
  发布管理
--)))|(% style="width:212px" %)(((
++)))|(((
++
++
  ·发布和部署管理
--)))|(% style="width:728px" %)(((
--·ITIL 4包含了一些对在敏捷/DevOps环境下管理发布的额外指引。
++)))|(((
++·ITIL 4包含了一些对在敏捷/DevOps环境下管理发
++
++布的额外指引。
  )))
--|(% style="width:137px" %)服务目录管理|(% style="width:212px" %)·服务目录管理|(% style="width:728px" %)·无变化
--|(% style="width:137px" %)服务配置管理|(% style="width:212px" %)·服务资产和配置管理|(% style="width:728px" %)·无变化
--|(% style="width:137px" %)(((
++|服务目录管理|·服务目录管理|·无变化
++|服务配置管理|·服务资产和配置管理|·无变化
++|(((
  服务连续性管理
--)))|(% style="width:212px" %)(((
++)))|(((
  ·IT服务连续性管理
  （ITSCM）
--)))|(% style="width:728px" %)(((
++)))|(((
  ·无变化
  )))
--|(% style="width:137px" %)(((
++|(((
++
++
++
  服务设计
--)))|(% style="width:212px" %)(((
++)))|(((
++
++
  ·设计协调
  ·服务级别管理
--)))|(% style="width:728px" %)(((
++)))|(((
  ·服务设计是ITIL v3/2011中的第二个服务生命周期阶段，设计协调和服务级别管理是其中关键流程。
  ·ITIL v3/2011中的服务设计包括进一步细化的流程，如容量管理、可用性管理、IT服务连续性管理
@@ -706,15
          +706,15 @@
  等，这些流程对应于相同名称的ITIL 4实践。
  )))
--|(% style="width:137px" %)(((
++|(((
  服务台
--)))|(% style="width:212px" %)(((
++)))|(((
  ·事件管理
  ·请求履行
--)))|(% style="width:728px" %)(((
++)))|(((
  ·ITIL v3/2011将服务台定义为“职能”，其活动
  在事件管理和请求履行流程中进行了描述。
@@ -721,6
          +721,7 @@
  )))
++
  续表
@@ -747,10
          +747,14 @@
  |(((
++
++
  部署管理
  )))|(((
++
++
  ·发布和部署管理
  )))|(((
  ·ITIL 4部署管理实践解释了将硬件、软件和其他服务组件部署到生产环境中的各种方法。
@@ -757,15
          +757,20 @@
  ·ITIL v3/2011发布和部署管理流程包括了关于各种部署选项的类似指导。
--·ITIL 4为多个供应商的环境提供了一些额外的建议。
++·ITIL 4为多个供应商的环境提供了一些额外的建
++
++议。
  )))
  |(((
++
  基础设施和平台管理
  )))|(((
++
++
  ·无
  )))|(((
  ·ITIL 4实践关注组织中技术的使用，包括云服务和云计算的最新指导。
@@ -794,8
          +794,12 @@
  ITIL 4 定义了一个由 6 项活动组成的通用服务价值链：计划、改进、契动、设计和转换、获取 / 构建、交付和支持。每条价值流都会涉及几个甚至所有的服务价值链活动。而这些价值流可以包含各种流程活动，这些流程活动是根据服务的特定价值流量明确定制的。在 ITIL 4 中，已经明确了 34 种可用于实现价值流内 6 种价值链活动的实践。这些实践包含了必要流程、技能、信息、工具和界面。为帮助各位读者理解各个实践对服务价值链活动的贡献度，我们根据各实践的热图（Heat map）整理出下表：
--                                                             表4-3：实践对服务价值链活动的贡献度表
++
++表4-3：实践对服务价值链活动的贡献度表
++
++
++
  |序号|实践|贡献度（从0-3：无、低、中、高）
  |1|部署管理|0
  |2|基础架构和平台管理|0
@@ -820,9
          +820,10 @@
  |21|项目管理|2
  |22|服务财务管理|2
--续表
++[[image:image-20200615172225-11.png]]续表
++
  |序号|实践|贡献度（从0-3：无、低、中、高）
  |23|战略管理|2
  |24|服务请求管理|3
@@ -847,13
          +847,14 @@
  从标准上来看，似乎标准变得更广泛，更加复杂，还引入了新的需求（例如：服务规划和交付领域），并且在服务管理体系的运行中，还带有诸多的流程。但实际上，标准对各个主题的要求更加精简，文档要求也大为降低。这也使组织可以更自由地定义其流程。标准的设计更多的是面向“服务管理的效果”，而不是“服务流程的详细描述”，这和 ITIL 4 中“实践”的提法比较接近，只是没有 ITIL 4 的做法那么激进。因此，在标准中，领导力和承诺、风险管理、服务计划、绩效评估和改进等主题就变得更为重要。
++[[image:image-20200615172225-12.jpg]]
--[[image:1592218060581-860.png]]
--                            图4-6 ISO/IEC 20000-1:2018框架图
++图4-6 ISO/IEC 20000-1:2018框架图
++
 . 标准删除了 PDCA，增添了服务商品化、服务集成商等内容。ITIL 4 也与之保持了同步。
 . 标准增加了组织应对风险和机会的新要求，ITIL 4 中也将“风险管理”增添为“实践”与其呼应。
 . “事件管理”和“服务请求管理”，在标准和 ITIL 4 中都做了同样的拆分。而“服务可用性管理”和“服务连续性管理”在标准中也进行了拆分，与 ITIL 4 以及 ITIL v3/2011 保持了一致。
@@ -870,7
          +870,7 @@
  |
  | |[[image:image-20200615180054-1.png]]
--                                  图4-7 ITIL 4服务管理相关标准
++图4-7 ITIL 4服务管理相关标准
  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 中，将“治理”列为其核心组件，强调组织要通过治理，使组织能够不断将其运营与管理机构设定的战略方向保持一致。
@@ -887,10
          +887,13 @@
  但在框架运用的过程中，我们也听到过一些真实的声音。实际上，在整个行业，对 IT 治理的接受程度都很低，而且实际上对最佳实践框架治理的理解和一致性也很差。IT 服务行业也不例外。根据2018 年一份 ITSM 工具调查揭示“COBIT 作为领先的 IT 治理框架之一，其接受程度也较低”。因此， ITIL 4 面临的一个挑战是与 IT 治理系统保持一致，并使在治理 SVS 时业务能确实发挥自身的作用。对于确保机会和需求进入 SVS，在组织绩效和合规性方面有相应的优先排序方面，治理很重要。这确保了业务不需要将所有的特性均放于同样的管理风险（如技术债务）、遵从性和安全性要求之上。治理还意味着确保能在价值链的末端实现价值，确保真正实现业务用例。这是一种很好的方式，可以提供关于业务在制定业务用例方面的效率反馈，而不是简单地追求特性。
--[[image:1592218120707-101.png]]
++|
++| |
--                                   图4-8 ITIL 4-COBIT 2019映射
++图4-8 ITIL 4-COBIT 2019映射
++
++
  == Q19：我们应该如何运用ITIL 4？ ==
@@ -898,8
          +898,9 @@
  所以我们在使用 ITIL 的时候，有两种途径：
--* 适应：尽力去理解 ITIL 最佳实践，明白他们为什么被推荐，尝试着去应用其中关键的思维， 用这些最佳实践去应对组织的环境、需求和目标。
--* 采用：转向以服务为导向型的战略，推动组织内“以顾客为中心”的文化。服务管理的成功来源于对上述变革的真正认同。这种真正的认同，并不只是组织内的几句口号，而是组织内人们行动的以及其行动被激励的方式。
++*
++** 适应：尽力去理解 ITIL 最佳实践，明白他们为什么被推荐，尝试着去应用其中关键的思维， 用这些最佳实践去应对组织的环境、需求和目标。
++** 采用：转向以服务为导向型的战略，推动组织内“以顾客为中心”的文化。服务管理的成功来源于对上述变革的真正认同。这种真正的认同，并不只是组织内的几句口号，而是组织内人们行动的以及其行动被激励的方式。
  一旦对 ITIL 的认同达致一个极高水平，这将可能帮助组织在其愿景、目标、环境和约束下，有效地评估 ITIL 对组织的价值。只有通过这种方法，真正的价值才能向顾客传递并为组织所捕获。
@@ -908,11
          +908,12 @@
  [[image:image-20200615180054-4.jpg]]在 AXELOS 发布的《ITIL 4 与云》的白皮书中，有有如下详细的描述：新的数字技术要求组织改变或调整他们的商业模式。这种数字转型是由新兴技术推动的，例如：
--* 云计算
--* 大数据
--* 物联网
--* 区块链
--* 人工智能
++*
++** 云计算
++** 大数据
++** 物联网
++** 区块链
++** 人工智能
  这些技术变革意义重大，而云计算是其中最普遍采用的数字技术。在迁移到云时，组织将某些元素、任务和职责外包给云服务提供商。这意味着组织和作为内部 IT 服务提供商的 IT 职能部门将不再管理提供该服务所涉及的一些技术组件。云本质上是一种外包形式，这种转变改变了组织和 IT 职能部门在 IT 流程管理、风险管理、财务管理、IT 架构、系统互操作性、安全性和 IT 服务管理等方面需要采取的方法。在传统的业务和信息技术模式看来，云是一项颠覆性的创新。因其改变了为消费者和服务提供商提供信息技术产品和服务的方式。这些变化，又推动着甚至是迫使着组织和个人去改变他们的工作方式。
@@ -920,6
          +920,7 @@
  云基服务的与日俱增，并没有改变 ITIL 等框架或 IT 服务管理等发展的基本轨迹。组织希望获得符合目标、
++
  适合使用并符合组织战略方针和需求的优质产品和服务。不管云的应用多寡，有一点“老生常谈”并不会改变——服务可外包但责任无法外包。IT 职能部门和组织仍需承担从设计、架构、互操作性、安全性和风险管理等端到端的总体责任。
  当组织在采用 ITIL 早期版本的时候，他们往往从服务转换和服务运营阶段直接选择对应的流程去匹配云的管理。例如事件、问题、变更、可用性、服务级别管理等。但从实践效果来看，有不少问题没有得到解决，通常的原因是 IT 职能部门缺乏最佳行动方针的指导。常见的问题包括：事件流程中“当无法控制云服务供应商工作，并且无法访问其 IT 环境时，如何管理、恢复和汇报在云服务供应商环境内所发生的事件”。问题流程中“为什么公有云服务提供商没有提交上周发生的严重应用程序问题的根因分析”。变更流程中“为什么DevOps 团队能在不遵循我们变更流程或程序下进行变更”……而在ITIL 4 中，采用了一个灵活、协调和整合的框架来为云计算以及云基服务提供更佳的指导。通过 SVS 的架构，可以确保组织出于合适的原因，以合适的方式使用云基服务，并且与监管机构和利害关系人的需求及要求保持一致。ITIL 4 的指导原则可以被云基服务采用以及对标，例如在架构、战略、程序、变化数量、预算和财务控制、容量和性能管理、可用性、培训和教育等方面。在治理活动方面， 组织能依据 ITIL 4 中对治理的指导，根据组织的治理机构和利益相关者设定的战略方向来调整它们对于云基服务的选择和使用。ITIL 4 的 SVC 也可以灵活地进行调整以及定制，适用于云基服务。
@@ -926,16
          +926,18 @@
  在 ITIL 4 的实践当中，有相当一部分的实践任务能通过组织外包的形式，由云服务提供商以云基服务的方式提供。例如，对于云上电子商务系统而言，服务提供商负责电子商务系统背后的整个底层基础架构，包括事件、问题、变更、发布、部署、容量和可用性的流程和实践。但总体服务的责任仍由采购该服务的组织承担。这样做有不少的好处：
--* 系统架构上，通过 PaaS 能很容易的实现 SOA、微服务等架构，为企业新业务的拓展带来很大的帮助；
--* 流程上，通过云计算，能大大提高系统的可用性和弹性。因此在可用性、业务连续性和容量方面都有较大的帮助。尤其云数据中心一旦采用分布式的架构，则在云上运行的应用，就带有天然连续性属性。
--* 日常使用上，云服务一般自带监控和汇报系统，在事件、问题、监控和事态管理方面，云上应用都将受益。
--* 财务上，由于云服务往往带有计费系统，有利于 IT 职能部门统计支出。并且云服务的支出往往带来了基础设施和系统的投资、支持、维护和保养费用的缩减，也有利于节省组织整体 IT 投入资源。
++*
++** 系统架构上，通过 PaaS 能很容易的实现 SOA、微服务等架构，为企业新业务的拓展带来很大的帮助；
++** 流程上，通过云计算，能大大提高系统的可用性和弹性。因此在可用性、业务连续性和容量方面都有较大的帮助。尤其云数据中心一旦采用分布式的架构，则在云上运行的应用，就带有天然连续性属性。
++** 日常使用上，云服务一般自带监控和汇报系统，在事件、问题、监控和事态管理方面，云上应用都将受益。
++** 财务上，由于云服务往往带有计费系统，有利于 IT 职能部门统计支出。并且云服务的支出往往带来了基础设施和系统的投资、支持、维护和保养费用的缩减，也有利于节省组织整体 IT 投入资源。
  云基服务有不少优点，但是参照 ITIL 4 框架，还存在一些有待解决的挑战，例如：
--* 云服务供应商提供的云基服务往往是通用的服务，其是否符合组织所制定的 SLA，是否符合组织未来的发展需求？
--* 随着更多的业务迁移上云，面对不时发生的云基服务宕机事件，组织如何有效地应对？
--* 云计算的重要特征是按需自助服务和快速弹性，现有业务及其系统能否适应这种高速、高度自动化的转型？变更和部署流程应该如何做调整？
++*
++** 云服务供应商提供的云基服务往往是通用的服务，其是否符合组织所制定的 SLA，是否符合组织未来的发展需求？
++** 随着更多的业务迁移上云，面对不时发生的云基服务宕机事件，组织如何有效地应对？
++** 云计算的重要特征是按需自助服务和快速弹性，现有业务及其系统能否适应这种高速、高度自动化的转型？变更和部署流程应该如何做调整？
  总括来说，ITIL 4 提供了组织利用现有技术应对新形态下服务管理挑战在一定程度上的指导，同时，ITIL 4 也增加了基础架构和平台管理实践来统一协调云计算对于云基服务价值交付的支持。而云帮助我们为消费者提供更好的服务，同时有可能为组织节省成本。组织有责任基于适当的理由作出正确的选择，从而取得正确的成果！
@@ -948,8
          +948,9 @@
  职能被定义为“专门执行某种类型的工作，并对所产生的特定结果负责的组织单元”。服务台， 是组织对外服务的统一窗口；劳动力与人才管理，专门执行与人力资源相关的工作，往往由人事部或人力资源部负责。
--* 服务台（服务管理实践）
--* 劳动力与人才管理（通用管理实践）
++*
++** 服务台（服务管理实践）
++** 劳动力与人才管理（通用管理实践）
  * 技术类（合计 3 项）：
  技术管理实践中包含了 3 项实践，我们将其均列为技术类。前文也提及，“部署管理”因更具技术属性，与“发布管理”剥离，被划分至“技术管理实践”。
@@ -956,16
          +956,18 @@
  ITIL 4 中，基础架构和平台管理同云平台和云基服务关联相当紧密。软件开发管理考虑到现有系统和创新（甚至是颠覆）系统之间的分野，兼容传统的基于软件开发成熟度模型（CMM）理论体系的瀑布式开发和遵循《敏捷宣言》的敏捷开发理论。
--* 部署管理（技术管理实践）
--* 基础设施与平台管理（技术管理实践）
--* 软件开发与管理（技术管理实践）
++*
++** 部署管理（技术管理实践）
++** 基础设施与平台管理（技术管理实践）
++** 软件开发与管理（技术管理实践）
  * 方法类（合计 3 项）：
  在改进计划、组织变革管理、服务财务管理、业务管理等众多实践中，往往都需要持续改进实践来指导，以及项目管理实践来组织和管理其执行。持续改进实践还是 ITIL 4 的 7 项指导原则，包括了相关的方法、技术和文化，将其归类在方法类，还是比较合适的。正如现代组织的环境和生态系统变得更加复杂，其挑战也是如此。这些不仅包括如何提高效率和自动化，还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹性。在如此复杂的 IT 环境，任何变化都寸步难行，并且风险四伏。完整的体系架构管理实践应该涉及所有体系结构域：业务、服务、信息、技术和环境。可喜的是， ITIL 4 参考并融合了 SOA 框架和 TOGAF 企业架构方法论。
--* 持续改进（通用管理实践）
--* 项目管理（通用管理实践）
--* 架构管理（通用管理实践）
++*
++** 持续改进（通用管理实践）
++** 项目管理（通用管理实践）
++** 架构管理（通用管理实践）
  * 流程类（合计 26 项）：
  流程在 ITIL 4 中的定义是“将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入并将其转换为已定义的输出。流程定义了操作的序列及其依赖项”。这与ITIL v3/2011 中定义的“用于实现特点目标的一系列有组织的活动，流程获得一个或多个定义的输入， 然后将它们变成定义的输出，流程可以包括任何角色、责任、工具和可靠提供输出所需的管理控制”。差距并不大。ITIL 4 强调的是“流程”是有序列的，并且有依赖项。在ITIL v3/2011 则强调的是“控制”， 将输入加工成所需要的输出。说句题外话，不少术语在 ITIL 4 和 ITIL v3/2011 中的定义都有了相当大的变化。一般而言，在ITIL 4 内术语均显得较为简洁，无太多描述性的词语，并且覆盖面会更广。
@@ -972,33
          +972,36 @@
  根据定义，我们将通用管理实践中的 ITIL 前版本中所提及的知识管理、信息安全管理、关系管理等归入了流程类。服务管理实践内的大部分实践我们也归入了流程类。
--* 信息安全管理（通用管理实践）
--* 知识管理（通用管理实践）
--* 组织变革管理（通用管理实践）
--* 度量与报告（通用管理实践）
--* 服务组合管理（通用管理实践）
--* 关系管理（通用管理实践）
--* 风险管理（通用管理实践）
--* 服务财务管理（通用管理实践）
--* 战略管理（通用管理实践）
--* 服务设计（服务管理实践）
--* 供应商管理（通用管理实践）
--* 可用性管理（服务管理实践）
--* 业务分析（服务管理实践）
--* 容量与性能管理（服务管理实践）
--* 变更控制（服务管理实践）
--* 事件管理（服务管理实践）
--* IT 资产管理（服务管理实践）
--* 监控与事态管理（服务管理实践）
--* 问题管理（服务管理实践）
--* 发布管理（服务管理实践）
--* 服务目录管理（服务管理实践）
--* 服务配置管理（服务管理实践）
--* 服务连续性管理（服务管理实践）
--* 服务级别管理（服务管理实践）
--* 服务请求管理（服务管理实践）
--* 服务验证与测试（服务管理实践）
++*
++** 信息安全管理（通用管理实践）
++** 知识管理（通用管理实践）
++** 组织变革管理（通用管理实践）
++** 度量与报告（通用管理实践）
++** 服务组合管理（通用管理实践）
++** 关系管理（通用管理实践）
++** 风险管理（通用管理实践）
++** 服务财务管理（通用管理实践）
++** 战略管理（通用管理实践）
++** 服务设计（服务管理实践）
++** 供应商管理（通用管理实践）
++** 可用性管理（服务管理实践）
++** 业务分析（服务管理实践）
++** 容量与性能管理（服务管理实践）
++** 变更控制（服务管理实践）
++** 事件管理（服务管理实践）
++** IT 资产管理（服务管理实践）
++** 监控与事态管理（服务管理实践）
++** 问题管理（服务管理实践）
++** 发布管理（服务管理实践）
++** 服务目录管理（服务管理实践）
++** 服务配置管理（服务管理实践）
++** 服务连续性管理（服务管理实践）
++** 服务级别管理（服务管理实践）
++** 服务请求管理（服务管理实践）
++** 服务验证与测试（服务管理实践）
++==   ==
++
  == Q22：ITIL 4与敏捷开发之间的结合关系？ ==
@@ -1008,16
          +1008,17 @@
  |
  | |[[image:image-20200615180054-5.jpg]]
--                                     图4-9 敏捷开发路线图
++图4-9 敏捷开发路线图
  与敏捷开发相关的概念非常多，包括测试驱动开发、持续集成、重构、结对编程、每日站会、小版本发布、自动化测试。敏捷软件开发通常包括：
--* 通过反馈分析和直接观察收集不断变化的需求；
--* 将开发工作分成小的增量和迭代；
--* 建立基于产品的跨职能团队；
--* 直观地呈现（看板）并定期讨论（每日站会）工作进度；
--* 在每次迭代结束时向利益相关者展示一份（至少是最低可行性）软件——一般称为“MVP”， 最小化可行产品。
++*
++** 通过反馈分析和直接观察收集不断变化的需求；
++** 将开发工作分成小的增量和迭代；
++** 建立基于产品的跨职能团队；
++** 直观地呈现（看板）并定期讨论（每日站会）工作进度；
++** 在每次迭代结束时向利益相关者展示一份（至少是最低可行性）软件——一般称为“MVP”， 最小化可行产品。
  而在 ITIL 4 的教材中通篇可见“敏捷”，从侧面反映出了 ITIL 4 的态度：应采用整体的服务价值链方法，以确保服务提供商在整个服务生命周期内都是敏捷的。敏捷性应成为所有服务管理维度和所有服务价值链活动的质量衡量标准之一。在 ITIL 4 的指导原则中“基于反馈的迭代推进”、“协作和提升可视化程度”、“保持简单实用”、“优化和自动化”都包含了“敏捷”的元素。
@@ -1025,9
          +1025,10 @@
  对于 ITIL 的前版本而言，ITIL 在服务转换阶段，在软件开发方面相对较弱，在端到端服务的过程中也相对较弱，必须要借助敏捷的思维，保持对客户和用户价值的关注，摆脱流程变得笨拙、沉重且高度集中的可能性。两者间的协同工作方式如：
--* 在服务交付阶段，引入持续交付，在同一个价值流图看整体的情况，统一安排工作项，分配统一的优先级，做到端到端的敏捷管理；
--* 变更和服务请求由专门的产品团队或以服务为中心的团队，以小迭代的方式处理，使产品或服务获得持续的反馈，且具有高可见性；
--* 日常运营活动可以而且应该与其他任务一起显示和进行优先排序。所有服务管理活动都可以而且应该不断提供、收集和处理反馈。
++*
++** 在服务交付阶段，引入持续交付，在同一个价值流图看整体的情况，统一安排工作项，分配统一的优先级，做到端到端的敏捷管理；
++** 变更和服务请求由专门的产品团队或以服务为中心的团队，以小迭代的方式处理，使产品或服务获得持续的反馈，且具有高可见性；
++** 日常运营活动可以而且应该与其他任务一起显示和进行优先排序。所有服务管理活动都可以而且应该不断提供、收集和处理反馈。
  综上所述，只有敏捷开发和服务管理一起以类似的节奏发展，说“同一种语言”，才可以确保组织继续与所有利益相关者共同创造价值。
@@ -1038,25
          +1038,27 @@
  《从业者指南》中提出 9 项指导原则：
--* 专注于价值
--* 为体验而设计
--* 从你所处的地方开始
--* 整体工作
--* 迭代地进步
--* 直接观察
--* 成为透明的
--* 协作
--* 保持简单
++*
++** 专注于价值
++** 为体验而设计
++** 从你所处的地方开始
++** 整体工作
++** 迭代地进步
++** 直接观察
++** 成为透明的
++** 协作
++** 保持简单
  这些现在已经在 ITIL 4 中被削减、改变、添加到现在的 7 项 ITIL 指导原则：
--* 聚焦
--* 从你所处的地方开始
--* 基于反馈的迭代推进
--* 协作和提升可视化程度
--* 通盘思考和工作
--* 保持简单实用
--* 优化和自动化
++*
++** 聚焦价值
++** 从你所处的地方开始
++** 基于反馈的迭代推进
++** 协作和提升可视化程度
++** 通盘思考和工作
++** 保持简单实用
++** 优化和自动化
  通过对比，可以看出 ITIL 4 保留了大部分的指导原则，并进行了扩充。例如《从业者指南》中提到的“为体验而设计”，实际在 ITIL 4 中已经融入了“聚焦价值”“通盘思考和工作”当中，并将其列为 34 个实践之一——“服务设计”。“协作”“成为透明的”也变成了“协作和提升可视化程度”。实际上通过可视化的工具，让流程等透明起来，才能更好地进行团队内、团队间、团队与组织、组织间的协作。“保持简单”扩充为“保持简单实用”。ITIL 4 将指导原则也融入了 SVS 中，而不是简单将其列出后就束之高阁。“自动化”也位居“优化”之后，被合并添加为指导原则之一，这也是一个非常棒的考虑。只有通过对活动的尽量优化后，活动才能有效地自动化。ITIL 4 建议大量地在各个实践中使用自动化，通过寻找自动化的机会，帮助节省组织成本、减少人为错误并改善员工体验。我们“应充分利用各种资源，特别是人力资源，并消除任何真正浪费的东西，用科技去实现它所能做到的一切， 人类干预应该只发生在真正有价值的地方”。
@@ -1063,7
          +1063,7 @@
  == Q24：ITIL 4和风险管理的关系？ ==
--关于风险管理，我们可以参考国际公认的权威——ISO31000:2018 风险管理指南。在 这个 版本中， 其提出了风险管理目的和原则的总体和一般视角。它们适用于任何类型的组织中的所有级别。有趣的是，该标准的上一版本也是发布于 2009 年，同样 9 年来第一次更新。ISO31000:2018 声明“风险管理的目的是创造和保护价值”，风险管理“提高绩效，鼓励创新并支持实现目标”。
++[[image:image-20200615180117-6.jpg]]关于风险管理，我们可以参考国际公认的权威——ISO31000:2018 风险管理指南。在 这个 版本中， 其提出了风险管理目的和原则的总体和一般视角。它们适用于任何类型的组织中的所有级别。有趣的是，该标准的上一版本也是发布于 2009 年，同样 9 年来第一次更新。ISO31000:2018 声明“风险管理的目的是创造和保护价值”，风险管理“提高绩效，鼓励创新并支持实现目标”。
  ISO31000:2018 有 8 项主题：
@@ -1080,20
          +1080,22 @@
  在 7 项指导原则中，和 ISO31000:2018 中 8 项主题有不少是能匹配的：
--* 聚焦价值以及基于反馈迭代推进，对应于评价成功。这里强调衡量、评估和改进风险管理实践的价值。这样做的目的不是第一次就把所有的事情都做好，而是在每次迭代完成时都要持续改进它。即使是不完美的风险数据也可能有用，只要它与显示趋势的时间表一起呈现。最终，风险报告能为管理人员提供高质量信息。
--* 通盘思考和工作，对应高管支持是基础，以及风险管理不是放之四海而皆准的。风险管理是一个循环过程，有足够的定制和改进空间，但其并非万能，管理者应该从整体去考虑，为自己的组织定制风险管理指南——特别是其风险概况、文化和风险偏好。风险管理实践必须全面管理，以实现整个组织的一致性。为确保有效性，应与利益相关方进行持续磋商，并为组织的不同部门提供适当的灵活性。这种灵活性将允许开发定制的风险管理程序，以便解决组织单位和 / 或客户特定情况。同时， 组织需要根据其愿意承担的风险偏好（即风险水平），对风险进行识别、评估、监控和管理。管理者还需要确保风险管理实践在组织的所有级别上得到充分集成，并与组织的目标结合在一起，让风险意识融入企业的运作方式中。
--* 从你所处的地方开始，对应利用现有的最佳信息。当前很多风险管理都集中在可用的最佳信息上，而忽视了风险中的模糊性和不完善之处。管理者不应只是试图分享绝对的风险信息，而应利用这些模糊点，对他们提供的数据进行反思，从而更好地发现问题。
--* 保持简单实用，对应标准化词汇。通过风险管理实践，提供一种公共语言，对风险、事件、后果和概率有简单和不复杂的定义。组织内均应采用这些术语，以确保交流不会产生分歧。
--* 优化和自动化，对应积极主动。对风险应该采取积极的立场，并确保将风险管理集成到组织各级决策的各个方面。这包括在业务连续性管理、业务分析、劳动力和人才管理、信息安全管理、问题管理等方面，都需要作出主动的优化，形成主动风险管理行为。
++*
++** 聚焦价值以及基于反馈迭代推进，对应于评价成功。这里强调衡量、评估和改进风险管理实践的价值。这样做的目的不是第一次就把所有的事情都做好，而是在每次迭代完成时都要持续改进它。即使是不完美的风险数据也可能有用，只要它与显示趋势的时间表一起呈现。最终，风险报告能为管理人员提供高质量信息。
++** 通盘思考和工作，对应高管支持是基础，以及风险管理不是放之四海而皆准的。风险管理是一个循环过程，有足够的定制和改进空间，但其并非万能，管理者应该从整体去考虑，为自己的组织定制风险管理指南——特别是其风险概况、文化和风险偏好。风险管理实践必须全面管理，以实现整个组织的一致性。为确保有效性，应与利益相关方进行持续磋商，并为组织的不同部门提供适当的灵活性。这种灵活性将允许开发定制的风险管理程序，以便解决组织单位和 / 或客户特定情况。同时， 组织需要根据其愿意承担的风险偏好（即风险水平），对风险进行识别、评估、监控和管理。管理者还需要确保风险管理实践在组织的所有级别上得到充分集成，并与组织的目标结合在一起，让风险意识融入企业的运作方式中。
++** 从你所处的地方开始，对应利用现有的最佳信息。当前很多风险管理都集中在可用的最佳信息上，而忽视了风险中的模糊性和不完善之处。管理者不应只是试图分享绝对的风险信息，而应利用这些模糊点，对他们提供的数据进行反思，从而更好地发现问题。
++** 保持简单实用，对应标准化词汇。通过风险管理实践，提供一种公共语言，对风险、事件、后果和概率有简单和不复杂的定义。组织内均应采用这些术语，以确保交流不会产生分歧。
++** 优化和自动化，对应积极主动。对风险应该采取积极的立场，并确保将风险管理集成到组织各级决策的各个方面。这包括在业务连续性管理、业务分析、劳动力和人才管理、信息安全管理、问题管理等方面，都需要作出主动的优化，形成主动风险管理行为。
  回到管理实践中，我们试举几个和风险管理相关的例子：
--* 在信息安全管理中，首当其冲的就是对可能产生的风险进行识别，以确保组织所需的信息安全性。
--* 在问题管理实践中，问题管理活动可以为风险管理提供特定的案例，可识别、评估和控制服务管理的四个方面的风险，此时采用风险管理工具和技术进行问题管理往往很有效。
--* 在可用性管理中，某些组织会将导致可靠性降低的因素作为风险管理的一部分。
--* 在服务连续性中，需要彻底考虑影响服务连续性的因素，以及多个因素之间的关系，。假如不做风险评估，那么应急相关对应的场景就无法有效的识别，可能存在应急预案缺失的问题。
--* 在服务设计方面，风险管理嵌入到了所有设计过程和活动中，确保所提供的产品和服务所涉及的风险和组织的风险控制水平保持一致。
--* 在服务验证和测试方面，风险管理相关的条件也是服务验证的输入之一。
++*
++** 在信息安全管理中，首当其冲的就是对可能产生的风险进行识别，以确保组织所需的信息安全性。
++** 在问题管理实践中，问题管理活动可以为风险管理提供特定的案例，可识别、评估和控制服务管理的四个方面的风险，此时采用风险管理工具和技术进行问题管理往往很有效。
++** 在可用性管理中，某些组织会将导致可靠性降低的因素作为风险管理的一部分。
++** 在服务连续性中，需要彻底考虑影响服务连续性的因素，以及多个因素之间的关系，。假如不做风险评估，那么应急相关对应的场景就无法有效的识别，可能存在应急预案缺失的问题。
++** 在服务设计方面，风险管理嵌入到了所有设计过程和活动中，确保所提供的产品和服务所涉及的风险和组织的风险控制水平保持一致。
++** 在服务验证和测试方面，风险管理相关的条件也是服务验证的输入之一。
  == Q25：ITIL 4的价值流，能否以图形化的方式展现？ ==
@@ -1112,104
          +1112,96 @@
  |
  | |[[image:image-20200615180117-8.png]]
--                                        图4-10 软件功能升级场景价值流图
++图4-10 软件功能升级场景价值流图
--
  为了便于理解，这里，我们采用列表的方式将该价值流所经历的价值链活动以及对应的实践活动展示出来，帮助大家思考各个 ITIL 4 实践在服务价值链活动中的作用。
++[[image:image-20200615180118-9.png]]表4-5：软件功能升级场景价值流活动
--                                                          表4-5：软件功能升级场景价值流活动
--| |(% colspan="2" style="width:160px" %)价值链活动输入/输出|(% colspan="2" style="width:185px" %)(((
++
++| |(% colspan="2" %)价值链活动输入/输出|(% colspan="2" %)(((
  ITIL实践
--)))|(% colspan="2" style="width:140px" %)(((
++)))|(% colspan="2" %)(((
  实践角色
--)))|(% colspan="2" style="width:667px" %)(((
++)))|(% colspan="2" %)(((
  实践活动
  )))
--| |(% colspan="2" style="width:160px" %)(((
++| |(% colspan="2" %)(((
++
++
  需求
--)))|(% colspan="2" style="width:185px" %) |(% colspan="2" style="width:140px" %)法务总监合规经理|(% colspan="2" style="width:667px" %)了解到不少IT服务系统需要升级来满足新的合规性要求。
--| |(% colspan="2" style="width:160px" %)(((
++)))|(% colspan="2" %) |(% colspan="2" %)法务总监合规经理|(% colspan="2" %)了解到不少IT服务系统需要升级来满足新的合规性要求。
++| |(% colspan="2" %)(((
  契动
--)))|(% colspan="2" style="width:185px" %)(((
++)))|(% colspan="2" %)(((
++
  关系管理
--)))|(% colspan="2" style="width:140px" %)(((
++)))|(% colspan="2" %)法务总监合规经理CIO|(% colspan="2" %)(((
--法务总监合规经理CIO
--)))|(% colspan="2" style="width:667px" %)(((
--
--
  讨论新的监管要求，并商定将创建一个项目来管理实施工作。
  )))
--| |(% colspan="2" style="width:160px" %)(((
++| |(% colspan="2" %)(((
++
  获取/构建
--)))|(% colspan="2" style="width:185px" %)(((
++)))|(% colspan="2" %)(((
  软件开发和管理、服务验证和测试 服务设计
--)))|(% colspan="2" style="width:140px" %)(((
++)))|(% colspan="2" %)(((
++
  软件开发团队
--)))|(% colspan="2" style="width:667px" %)(((
++)))|(% colspan="2" %)每个软件团队管理一个待办事项并为他们分配部分开发代码。每个团队还通过自动化流水线进行开发测试。所有代码每天都自动集成和测试两次，确保不同团队编写的代码能协同工作。
++| |(% colspan="2" %)(((
--每个软件团队管理一个待办事项并为他们分配部分开发代码。每个团队还通过自动化流水线进行开发测试。所有代码每天都自动集成和测试两次，确保不同团队编写的代码能协同工作。
--)))
--| |(% colspan="2" style="width:160px" %)(((
--
--
  设计和转换契动
--)))|(% colspan="2" style="width:185px" %)(((
++)))|(% colspan="2" %)(((
  项目管理
  服务验证和测试服务设计
--)))|(% colspan="2" style="width:140px" %)(((
--项目经理
--
--IT开发经理
--
--软件开发团队
--
--合规经理
--)))|(% colspan="2" style="width:667px" %)(((
++)))|(% colspan="2" %)项目经理   IT开发经理 软件开发团队合规经理|(% colspan="2" %)(((
  讨论并商定了发布和部署计划。在部署开始之前，批准了需要测试的级别以及发放授权给每个部署的人员。
  )))
--| |(% colspan="2" style="width:160px" %)(((
++| |(% colspan="2" %)(((
++
++
++
  获取/构建设计和转换
--)))|(% colspan="2" style="width:185px" %)(((
++)))|(% colspan="2" %)(((
++
++
  服务设计
  组织变更管理部署管理
  服务配置管理
--)))|(% colspan="2" style="width:140px" %)(((
++)))|(% colspan="2" %)(((
--软件开发团队
--)))|(% colspan="2" style="width:667px" %)(((
--
--新软件的部署工作一旦准备就绪，就会立即启动。对此不再需要变更批准，因为风险评估已提前完成，自动化确保了代码的部署完全按照计划进行。配置数据用于驱动部署，因此不需要单独的活动来更新。
--)))
++
++软件开发团队
++)))|(% colspan="2" %)新软件的部署工作一旦准备就绪，就会立即启动。对此不再需要变更批准，因为风险评估已提前完成，自动化确保了代码的部署完全按照计划进行。配置数据用于驱动部署，因此不需要单独的活动来更新。
  |(% colspan="2" %)(((
@@ -1216,57
          +1216,51 @@
  契动
  设计和转换
--)))|(% colspan="2" style="width:167px" %)(((
--
--
++)))|(% colspan="2" %)(((
  项目管理发布管理服务台
  服务目录管理
--)))|(% colspan="2" style="width:202px" %)(((
--
--
++)))|(% colspan="2" %)(((
  项目经理
  软件开发团队产品经理
  服务目录经理
--)))|(% colspan="2" style="width:406px" %)(((
--
--
--新功能通过功能开关来发布的，该开关允许用户可以看到新功能。服务台和其他同事得到通知，新功能已经可以使用。同时服务目录已被更新。
--)))|
++)))|(% colspan="2" %)新功能通过功能开关来发布的，该开关允许用户可以看到新功能。服务台和其他同事得到通知，新功能已经可以使用。同时服务目录已被更新。|
  |(% colspan="2" %)(((
++
  价值改进
--)))|(% colspan="2" style="width:167px" %)(((
++)))|(% colspan="2" %)(((
  项目管理服务设计关系管理持续改进
--)))|(% colspan="2" style="width:202px" %)(((
--
--
++)))|(% colspan="2" %)(((
  项目经理开发经理法务总监CIO
  合规经理
--)))|(% colspan="2" style="width:406px" %)(((
++)))|(% colspan="2" %)(((
++
  对该项目进行了审查和关闭。寻找改进机会并将其添加到持续改进登记册中。
  )))|
  |(% colspan="2" %)(((
++
  价值
--)))|(% colspan="2" style="width:167px" %) |(% colspan="2" style="width:202px" %)(((
++)))|(% colspan="2" %) |(% colspan="2" %)(((
  项目经理CIO
  法务总监
  合规经理
--)))|(% colspan="2" style="width:406px" %)(((
++)))|(% colspan="2" %)(((
++
  更新的服务符合新合规要求。
  )))|
@@ -1286,14
          +1286,13 @@
  |
  | |[[image:image-20200615180118-10.jpg]]
--                                   图4-11 DevOps三步工作
++图4-11 DevOps三步工作法
--1. (((
-- DevOps 的流动是为了加速从开发到运维的价值交付，而 ITIL 4 定义了价值流以及通盘思考和工作的指导原则。通过整体和系统的思考，聚焦于价值的传递和交付之上。
--* DevOps 有反馈以建立更安全系统的工作制度，而 ITIL 4 定义了基于反馈的迭代推进以及持续改进。通过找到改进点与改进机会，进行优先级排序，消除瓶颈，从而不断地提升组织的管理能力与管理效率，让有效的反馈成为驱动改善系统控制回路的最大动力。
--* DevOps 有持续学习和实验，促进高度信任，形成“无谴责”的文化，将风险承担作为日常工作的一部分；而 ITIL 4 定义了从你所处的地方开始、通盘思考和工作、协作和提升可视化程度的原则以及持续改进的方法。通过工作中掌握的技能和与现有的工具来结合实践，形成更有效的价值链。
--)))
++1.
++1*. DevOps 的流动是为了加速从开发到运维的价值交付，而 ITIL 4 定义了价值流以及通盘思考和工作的指导原则。通过整体和系统的思考，聚焦于价值的传递和交付之上。
++1*. DevOps 有反馈以建立更安全系统的工作制度，而 ITIL 4 定义了基于反馈的迭代推进以及持续改进。通过找到改进点与改进机会，进行优先级排序，消除瓶颈，从而不断地提升组织的管理能力与管理效率，让有效的反馈成为驱动改善系统控制回路的最大动力。
++1*. DevOps 有持续学习和实验，促进高度信任，形成“无谴责”的文化，将风险承担作为日常工作的一部分；而 ITIL 4 定义了从你所处的地方开始、通盘思考和工作、协作和提升可视化程度的原则以及持续改进的方法。通过工作中掌握的技能和与现有的工具来结合实践，形成更有效的价值链。
 . 目的一致：双方都要求有可视化的价值流，需要通过可视化来管理价值的流动，最终都是追求从端到端打通为用户交付价值的链条，并且强调工作的可视化要考虑全局而不是局部，如果仅仅度量开发的完成率、度量系统的可用性，这些都只是局部的目标。两者都是更关注全局、端到端的价值流动。
  相异之处：
@@ -1306,10
          +1306,11 @@
  DevOps 被认为是结合了软件开发技术（敏捷）、价值共创（ITIL 4），以及对学习和改进价值生产方式（精益）执着追求的整体方法。在 ITIL 4 中，组织面临的主要挑战之一是确定其特定的价值流。DevOps 是一个很好的ITIL 4 价值流实例，其涵盖了从业务需求、开发、测试、发布计划到部署的活动。因此，采用或借用 DevOps 方法将为改进软件产品的开发和管理方式提供更多机会，例如：
--* 创建从交付和支持到软件开发和技术操作的快速反馈循环；
--* 简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值；
--* 分离部署管理与发布管理；
--* 倡导“整体系统视图”，强调企业治理，促进服务团队、软件开发和技术运维之间的紧密协作。
++*
++** 创建从交付和支持到软件开发和技术操作的快速反馈循环；
++** 简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值；
++** 分离部署管理与发布管理；
++** 倡导“整体系统视图”，强调企业治理，促进服务团队、软件开发和技术运维之间的紧密协作。
  DevOps 将在 ITIL 4 服务目录管理、服务级别管理、变更管理、配置管理、发布管理、部署管理等实践中大展拳脚。
@@ -1320,9
          +1320,10 @@
  新版本并未改变对项目的定义，仍为“为创造独特的产品、服务或成果而进行的临时性工作”。这直接意味着服务交付是项目类型之一，其中可交付的是客户请求的实际服务。根据 PMBOK 指南区分项目的主要特征，以及服务交付如何满足这些特征，我们可以看到以下几个特点：
--* 临时（temporary:）：项目是一项临时的工作，有一个开始和一个结束。服务在其服务价值链中经历了从收到的需求 / 机会开始，到向客户交付价值的连续阶段，而持续改进、治理、实践、指导原则围绕着所有活动。
--* 独特的产品、服务或成果（unique product，service，or result）：一个项目的交付物被认为是独特的，不像在运营活动中的重复性活动，这是通过响应特定需求交付给特定客户的 IT 服务来满足的。
--* 渐进明细（progressive elaboration）：项目执行是迭代的，并且不断地循序渐进以响应变更，这可以通过 ITIL 4 框架中的持续改进以及基于反馈的迭代推进，以及相关实践来满足。
++*
++** 临时（temporary:）：项目是一项临时的工作，有一个开始和一个结束。服务在其服务价值链中经历了从收到的需求 / 机会开始，到向客户交付价值的连续阶段，而持续改进、治理、实践、指导原则围绕着所有活动。
++** 独特的产品、服务或成果（unique product，service，or result）：一个项目的交付物被认为是独特的，不像在运营活动中的重复性活动，这是通过响应特定需求交付给特定客户的 IT 服务来满足的。
++** 渐进明细（progressive elaboration）：项目执行是迭代的，并且不断地循序渐进以响应变更，这可以通过 ITIL 4 框架中的持续改进以及基于反馈的迭代推进，以及相关实践来满足。
  在过往，我们可以将 ITIL v3/2011 的生命周期与 PMBOK 的五大过程组粗略地做一个映射。服务战略对应启动过程与规划过程；服务设计、服务转换、服务运营对应执行过程，持续服务改进对应监控过程，服务退役对应收尾过程——ITIL v3/2011 并没有这个阶段，我们选择了最接近“关闭”的术语。
@@ -1330,11
          +1330,50 @@
  和原则之间存在必要的相似性或对应关系，我们舍易取难，根据 PMBOK 第 6 版的 5 大过程组和 49 个过程，与 ITIL 4 框架下的 34 个实践进行了映射和集成。我们考虑了应用每个 PMBOK 流程时应该考虑的实践，在特定情况下适用的过程集取决于特定的项目需求。在下表中，将概述这些交点。从 PMBOK 指南的角度看项目管理，从 ITIL 4 框架的角度看 IT 服务管理。
--[[image:1592219175956-363.png]]
--                              图4-12 ITIL 4-PMBOK第6版映射图
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++图4-12 ITIL 4-PMBOK第6版映射图
++
++
++
  ITIL 4 将项目管理作为一项实践，其与风险管理一样，穿插于不少的实践过程中。项目管理实践的目的是确保组织中的所有项目都能成功交付，这需要通过规划、指派、监控和维护对项目所有方面的控制，并保持相关人员的积极性来实现的。项目是向组织引入重大变更的手段之一，它们可以被定义为为了根据商定的业务案例提供一个或多个输出（或产品）而创建的临时结构。对于更复杂的转型项目，它们可能是一个独立的计划，也可能是一个更大的计划的一部分，以及其他相互关联的项目。但是，即使是独立项目也应该在组织的项目组合中考虑。最终，ITIL 4 通过调和项目管理与 ITIL 4 众多实践之间的关系，使各实践能与项目管理保持一致。
  == Q28：ITIL  4和TOGAF的结合关系？ ==
@@ -1346,16
          +1346,18 @@
  |
  | |[[image:image-20200615180154-12.jpg]]
--                               图4-16 TOGAF架构开发方法
++图4-16 TOGAF架构开发方法
++[[image:image-20200615180154-13.png]]
  TOGAF 列出了四种被广泛接受的子架构：
--* 业务架构：定义了商业策略、管理、组织和关键业务流程；
--* 应用架构：为待配置的应用系统提供一个蓝图，从他们的交互、他们的关系到该组织核心的业务流程；
--* 数据架构：描述一个组织逻辑的和物理的数据资产和数据管理资源的结构；
--* 技术架构：描述了支持核心部署和关键任务应用的软件基础设施。
++*
++** 业务架构：定义了商业策略、管理、组织和关键业务流程；
++** 应用架构：为待配置的应用系统提供一个蓝图，从他们的交互、他们的关系到该组织核心的业务流程；
++** 数据架构：描述一个组织逻辑的和物理的数据资产和数据管理资源的结构；
++** 技术架构：描述了支持核心部署和关键任务应用的软件基础设施。
  四种子架构，可以认为是 TOGAF 对 IT 世界的一种抽象的归纳。回想起 ITIL，也有这么一个术语与之匹配，那就是 CMDB（配置管理数据库）。我们的 CMDB 基于消费的情况来进行配置，当系统比较复杂，使用精度要求比较高的情况下，CI（配置项）同样可以按照业务、应用、数据、技术四类来进行分类。从最前端的业务开始，将 CI 最终分解到基础架构上去，并且其后带着 CI 之间上下、平行、互相引用等关系。
@@ -1363,11
          +1363,12 @@
  完整的体系架构管理实践应该涉及所有体系架构域：业务，服务，信息，技术和环境。对于规模较小且不太复杂的组织，可由架构师开发单一的集成架构。
--* 业务架构：允许组织查看其能力，了解它们如何与为组织及其客户创造价值所需的所有具体活动保持一致。然后将这些与组织的策略进行比较，并执行目标状态与当前能力的差距分析。确定基线和目标状态之间的已确定差距的优先级，并逐步解决这些能力差距。以“路线图”的方式，描述了从当前状态到未来状态的转变，以实现组织的战略。
--* 服务架构：服务结构为组织提供了其提供的所有服务的视图，包括描述架构的服务和服务模型之间的交互（服务组件如何组合在一起）和每个服务的动态（活动、资源流和交互）。服务模型可以用作多个服务的模板或蓝图。
--* 信息架构：描述了组织的逻辑和物理数据资产以及数据管理资源。它显示了如何管理和共享信息资源以使组织受益。
--* 技术架构：定义了支持产品和服务组合所需的软件和硬件基础架构。IT 系统的运作往往需要依赖架构。组织提供服务时，受到挑战的往往是 IT 系统的综合能力，例如在双十一的凌晨，各大电商的后台如何处理突然倍速暴增的订单，这对该组织技术架构的弹性提出了巨大的挑战。
--* 环境架构：描述了影响组织的外部因素和变革的驱动因素，以及环境控制及其管理的所有方面、类型和水平。环境包括发展、技术、商业、运营、组织、政治、经济、法律、监管、生态和社会影响。
++*
++** 业务架构：允许组织查看其能力，了解它们如何与为组织及其客户创造价值所需的所有具体活动保持一致。然后将这些与组织的策略进行比较，并执行目标状态与当前能力的差距分析。确定基线和目标状态之间的已确定差距的优先级，并逐步解决这些能力差距。以“路线图”的方式，描述了从当前状态到未来状态的转变，以实现组织的战略。
++** 服务架构：服务结构为组织提供了其提供的所有服务的视图，包括描述架构的服务和服务模型之间的交互（服务组件如何组合在一起）和每个服务的动态（活动、资源流和交互）。服务模型可以用作多个服务的模板或蓝图。
++** 信息架构：描述了组织的逻辑和物理数据资产以及数据管理资源。它显示了如何管理和共享信息资源以使组织受益。
++** 技术架构：定义了支持产品和服务组合所需的软件和硬件基础架构。IT 系统的运作往往需要依赖架构。组织提供服务时，受到挑战的往往是 IT 系统的综合能力，例如在双十一的凌晨，各大电商的后台如何处理突然倍速暴增的订单，这对该组织技术架构的弹性提出了巨大的挑战。
++** 环境架构：描述了影响组织的外部因素和变革的驱动因素，以及环境控制及其管理的所有方面、类型和水平。环境包括发展、技术、商业、运营、组织、政治、经济、法律、监管、生态和社会影响。
  在应用过程中，ITIL 4 对 TOGAF 的架构开发方法，进行充分地融合。由于 TOGAF 本身所具有的开放性和灵活性，因此不会排斥组织中对其他框架理论的引入和使用，这当然也包括了 ITIL 4。企业架构开发方法各阶段的输入与输出可以不拘泥于其定义，可采用适合组织自身情况的其他框架中所定义的相关内容，并作适当的剪裁，甚至各阶段的先后顺序也是可以调整的。在架构管理的过程中，同样需要采用“持续优化”的方式，进行循环的迭代。

1592219175956-363.png

Author

...	...	@@ -1,1 +1,0 @@
1		-XWiki.superadmin

Size

...	...	@@ -1,1 +1,0 @@
1		-183.5 KB

Content

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司