第四章 ITIL 4学习与实践FAQ

Q17：ITIL 4与其他服务管理相关标准和实践的关系如何？

ITIL 已经有了 30 余年历史，多年来作为服务管理的最佳实践被许多组织所采用。其虽然不时地进行更新，但其他更新、更快、更敏捷的服务管理框架、方法论在适应服务管理和信息技术的新趋势方面已经走在了前面。如下图所示，ITIL 4 对其他服务管理相关标准、实践等采取了非常开放的兼收并蓄方式，将他们引入 ITIL 的框架中，力图通过借鉴和集成，快速跟上时代的步伐。ITIL 4 认为各服务管理相关标准、实践等与其具备相同的原则，而通过这些相同的原则，能让组织有效地将各服务管理相关标准、实践等整合到 ITIL 中去。

                                  图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 中，将“治理”列为其核心组件，强调组织要通过治理，使组织能够不断将其运营与管理机构设定的战略方向保持一致。

近年来，我们正经历着一场向敏捷和自组织发展的巨大变革。云计算、人工智能、区块链、物联网等新技术极大地改变了信息处理和服务提供的方式。各种旧有的框架，例如ITIL v3/2011 等，都被认为过于官僚，流程过于沉重。然而，Agile、Scrum 、LeSS或DevOps 等本身并不是框架，而是种种敏捷的方法或理念；治理、管理原则和实践需要配合时代的发展走得更远，这些纯粹的敏捷方法或理念并没有埋葬它们。在新的工作方法下，如何应用这些要素存在着很大的差异性和不确定性。ITIL 4 选择性地对它们进行了吸纳：SVS 支持许多工作方法，例如 Agile、Lean 和DevOps 等。尤其是近年来非常流行的开发运维一体化，即 DevOps。ITIL 4 与 DevOps 的关系，我们将在下文进一步介绍。

Q18：ITIL 4与COBIT 2019的关系？

在 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，可以确保对框架进行更高级别的控制。

ITIL 4 将治理纳入了 SVS 中，并指出：“SVS 的治理是通过对 SVS 的定期评估来指导并监控 SVS 的绩效来实现的”。我们尝试创建了一个 COBIT 2019 和 ITIL 4 之间的映射关系，但目前而言该映射相对粗略，仅供各位参考。从下图 ITIL 4-COBIT 2019 映射表中可以看出，许多 COBIT 2019 治理实践在ITIL 4 中并没有得到体现。因此，整体来看，两种框架都有各自的关注点，并有机会相辅相成。希望通过该映射图，我们可以将这两个出色的框架结合起来，交付更好的价值。

但在框架运用的过程中，我们也听到过一些真实的声音。实际上，在整个行业，对 IT 治理的接受程度都很低，而且实际上对最佳实践框架治理的理解和一致性也很差。IT 服务行业也不例外。根据2018 年一份 ITSM 工具调查揭示“COBIT 作为领先的 IT 治理框架之一，其接受程度也较低”。因此， ITIL 4 面临的一个挑战是与 IT 治理系统保持一致，并使在治理 SVS 时业务能确实发挥自身的作用。对于确保机会和需求进入 SVS，在组织绩效和合规性方面有相应的优先排序方面，治理很重要。这确保了业务不需要将所有的特性均放于同样的管理风险（如技术债务）、遵从性和安全性要求之上。治理还意味着确保能在价值链的末端实现价值，确保真正实现业务用例。这是一种很好的方式，可以提供关于业务在制定业务用例方面的效率反馈，而不是简单地追求特性。

                                   图4-8 ITIL 4-COBIT 2019映射

Q19：我们应该如何运用ITIL 4？

ITIL 实际和其他框架、方法论、知识体系等一样，只有通过“是否有助于帮助我们达到目的”这一唯一标准进行检验。对于 ITIL 4 而言，其相关的实践是如何应用以及落地，是至关重要的。我们需要在任何时候都牢记“需要完成什么”以及“为什么需要完成”。“尽信书则不如无书”，如果只是盲目地跟随 ITIL 4 中的例子或者实践去做，而不考虑组织的现状、需求和目标，这必然会失败。

所以我们在使用 ITIL 的时候，有两种途径：

• 适应：尽力去理解 ITIL 最佳实践，明白他们为什么被推荐，尝试着去应用其中关键的思维， 用这些最佳实践去应对组织的环境、需求和目标。
• 采用：转向以服务为导向型的战略，推动组织内“以顾客为中心”的文化。服务管理的成功来源于对上述变革的真正认同。这种真正的认同，并不只是组织内的几句口号，而是组织内人们行动的以及其行动被激励的方式。

一旦对 ITIL 的认同达致一个极高水平，这将可能帮助组织在其愿景、目标、环境和约束下，有效地评估 ITIL 对组织的价值。只有通过这种方法，真正的价值才能向顾客传递并为组织所捕获。

Q20：ITIL 4和云计算以及相关服务关系如何？

在 AXELOS 发布的《ITIL 4 与云》的白皮书中，有有如下详细的描述：新的数字技术要求组织改变或调整他们的商业模式。这种数字转型是由新兴技术推动的，例如：

• 云计算
• 大数据
• 物联网
• 区块链
• 人工智能

这些技术变革意义重大，而云计算是其中最普遍采用的数字技术。在迁移到云时，组织将某些元素、任务和职责外包给云服务提供商。这意味着组织和作为内部 IT 服务提供商的 IT 职能部门将不再管理提供该服务所涉及的一些技术组件。云本质上是一种外包形式，这种转变改变了组织和 IT 职能部门在 IT 流程管理、风险管理、财务管理、IT 架构、系统互操作性、安全性和 IT 服务管理等方面需要采取的方法。在传统的业务和信息技术模式看来，云是一项颠覆性的创新。因其改变了为消费者和服务提供商提供信息技术产品和服务的方式。这些变化，又推动着甚至是迫使着组织和个人去改变他们的工作方式。

在 ITIL 4 中，服务被定义为“一种通过促进客户所需结果实现，且无需客户管理特定成本和风险，从而实现价值共同创造的方法”。由此可见，云和基于云的服务（下文简称为“云基服务”） 与 ITIL 4 中定义的服务有着明显的共通点。云通过更大规模、更快、更便捷、更便宜的方式，提供IT、业务、客户和消费者服务，并且可以根据服务的需求自动调配，按需付费。

云基服务的与日俱增，并没有改变 ITIL 等框架或 IT 服务管理等发展的基本轨迹。组织希望获得符合目标、

适合使用并符合组织战略方针和需求的优质产品和服务。不管云的应用多寡，有一点“老生常谈”并不会改变——服务可外包但责任无法外包。IT 职能部门和组织仍需承担从设计、架构、互操作性、安全性和风险管理等端到端的总体责任。

当组织在采用 ITIL 早期版本的时候，他们往往从服务转换和服务运营阶段直接选择对应的流程去匹配云的管理。例如事件、问题、变更、可用性、服务级别管理等。但从实践效果来看，有不少问题没有得到解决，通常的原因是 IT 职能部门缺乏最佳行动方针的指导。常见的问题包括：事件流程中“当无法控制云服务供应商工作，并且无法访问其 IT 环境时，如何管理、恢复和汇报在云服务供应商环境内所发生的事件”。问题流程中“为什么公有云服务提供商没有提交上周发生的严重应用程序问题的根因分析”。变更流程中“为什么DevOps 团队能在不遵循我们变更流程或程序下进行变更”……而在ITIL 4 中，采用了一个灵活、协调和整合的框架来为云计算以及云基服务提供更佳的指导。通过 SVS 的架构，可以确保组织出于合适的原因，以合适的方式使用云基服务，并且与监管机构和利害关系人的需求及要求保持一致。ITIL 4 的指导原则可以被云基服务采用以及对标，例如在架构、战略、程序、变化数量、预算和财务控制、容量和性能管理、可用性、培训和教育等方面。在治理活动方面， 组织能依据 ITIL 4 中对治理的指导，根据组织的治理机构和利益相关者设定的战略方向来调整它们对于云基服务的选择和使用。ITIL 4 的 SVC 也可以灵活地进行调整以及定制，适用于云基服务。

在 ITIL 4 的实践当中，有相当一部分的实践任务能通过组织外包的形式，由云服务提供商以云基服务的方式提供。例如，对于云上电子商务系统而言，服务提供商负责电子商务系统背后的整个底层基础架构，包括事件、问题、变更、发布、部署、容量和可用性的流程和实践。但总体服务的责任仍由采购该服务的组织承担。这样做有不少的好处：

• 系统架构上，通过 PaaS 能很容易的实现 SOA、微服务等架构，为企业新业务的拓展带来很大的帮助；
• 流程上，通过云计算，能大大提高系统的可用性和弹性。因此在可用性、业务连续性和容量方面都有较大的帮助。尤其云数据中心一旦采用分布式的架构，则在云上运行的应用，就带有天然连续性属性。
• 日常使用上，云服务一般自带监控和汇报系统，在事件、问题、监控和事态管理方面，云上应用都将受益。
• 财务上，由于云服务往往带有计费系统，有利于 IT 职能部门统计支出。并且云服务的支出往往带来了基础设施和系统的投资、支持、维护和保养费用的缩减，也有利于节省组织整体 IT 投入资源。

云基服务有不少优点，但是参照 ITIL 4 框架，还存在一些有待解决的挑战，例如：

• 云服务供应商提供的云基服务往往是通用的服务，其是否符合组织所制定的 SLA，是否符合组织未来的发展需求？
• 随着更多的业务迁移上云，面对不时发生的云基服务宕机事件，组织如何有效地应对？
• 云计算的重要特征是按需自助服务和快速弹性，现有业务及其系统能否适应这种高速、高度自动化的转型？变更和部署流程应该如何做调整？

总括来说，ITIL 4 提供了组织利用现有技术应对新形态下服务管理挑战在一定程度上的指导，同时，ITIL 4 也增加了基础架构和平台管理实践来统一协调云计算对于云基服务价值交付的支持。而云帮助我们为消费者提供更好的服务，同时有可能为组织节省成本。组织有责任基于适当的理由作出正确的选择，从而取得正确的成果！

Q21：ITIL 4的实践如何分类？

我们可以将 ITIL 4 的 34 项实践，按照职能、技术、方法、流程分为四大类。

• 职能类（合计 2项）：

职能被定义为“专门执行某种类型的工作，并对所产生的特定结果负责的组织单元”。服务台， 是组织对外服务的统一窗口；劳动力与人才管理，专门执行与人力资源相关的工作，往往由人事部或人力资源部负责。

• 服务台（服务管理实践）
• 劳动力与人才管理（通用管理实践）
• 技术类（合计 3 项）：

技术管理实践中包含了 3 项实践，我们将其均列为技术类。前文也提及，“部署管理”因更具技术属性，与“发布管理”剥离，被划分至“技术管理实践”。

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 内术语均显得较为简洁，无太多描述性的词语，并且覆盖面会更广。

根据定义，我们将通用管理实践中的 ITIL 前版本中所提及的知识管理、信息安全管理、关系管理等归入了流程类。服务管理实践内的大部分实践我们也归入了流程类。

• 信息安全管理（通用管理实践）
• 知识管理（通用管理实践）
• 组织变革管理（通用管理实践）
• 度量与报告（通用管理实践）
• 服务组合管理（通用管理实践）
• 关系管理（通用管理实践）
• 风险管理（通用管理实践）
• 服务财务管理（通用管理实践）
• 战略管理（通用管理实践）
• 服务设计（服务管理实践）
• 供应商管理（通用管理实践）
• 可用性管理（服务管理实践）
• 业务分析（服务管理实践）
• 容量与性能管理（服务管理实践）
• 变更控制（服务管理实践）
• 事件管理（服务管理实践）
• IT 资产管理（服务管理实践）
• 监控与事态管理（服务管理实践）
• 问题管理（服务管理实践）
• 发布管理（服务管理实践）
• 服务目录管理（服务管理实践）
• 服务配置管理（服务管理实践）
• 服务连续性管理（服务管理实践）
• 服务级别管理（服务管理实践）
• 服务请求管理（服务管理实践）
• 服务验证与测试（服务管理实践）

Q22：ITIL 4与敏捷开发之间的结合关系？

一听到“敏捷”，大部分 IT 从业人员，都会马上联想到“软件开发”，并回想起 2001 年发布的《敏捷宣言》。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发过程中，软件项目的构建被切分成多个子项目——有点类似 PMBOK 中的“工作包”，各子项目成果均通过测试，具备集成和可运行的特性。简而言之，就是把一个大项目分为多个关联但可独立运行的小项目，并分别完成， 在此过程中软件一直处于可用状态。目前敏捷软件开发方法已被许多公司和软件团队采用，并且在许多情况下已被证明是有效的。

                                     图4-9 敏捷开发路线图

与敏捷开发相关的概念非常多，包括测试驱动开发、持续集成、重构、结对编程、每日站会、小版本发布、自动化测试。敏捷软件开发通常包括：

• 通过反馈分析和直接观察收集不断变化的需求；
• 将开发工作分成小的增量和迭代；
• 建立基于产品的跨职能团队；
• 直观地呈现（看板）并定期讨论（每日站会）工作进度；
• 在每次迭代结束时向利益相关者展示一份（至少是最低可行性）软件——一般称为“MVP”， 最小化可行产品。

而在 ITIL 4 的教材中通篇可见“敏捷”，从侧面反映出了 ITIL 4 的态度：应采用整体的服务价值链方法，以确保服务提供商在整个服务生命周期内都是敏捷的。敏捷性应成为所有服务管理维度和所有服务价值链活动的质量衡量标准之一。在 ITIL 4 的指导原则中“基于反馈的迭代推进”、“协作和提升可视化程度”、“保持简单实用”、“优化和自动化”都包含了“敏捷”的元素。

敏捷开发与 ITIL 4 在组织内有相辅相成的共生之道。一方面，对于敏捷开发而言，成功的敏捷开发可以快速响应服务消费者不断变化的需求。但是，在许多组织中，敏捷开发的优势并未能得到良好的发挥。这通常是由于只在服务交付等少数阶段运用了“敏捷”，而在服务生命周期的其他阶段“脱敏”。这种孤立的敏捷性对组织的帮助不大，因为根据“木桶理论”——价值链的整体表现是由创造价值的最慢部分决定的。通过价值链的整体考虑方式，ITIL 为软件开发组织提供更广泛的视角和语言， 增强软件开发团队与别的服务团队的合作，也有助于提升敏捷开发在组织内的更好落地。另一方面，

对于 ITIL 的前版本而言，ITIL 在服务转换阶段，在软件开发方面相对较弱，在端到端服务的过程中也相对较弱，必须要借助敏捷的思维，保持对客户和用户价值的关注，摆脱流程变得笨拙、沉重且高度集中的可能性。两者间的协同工作方式如：

• 在服务交付阶段，引入持续交付，在同一个价值流图看整体的情况，统一安排工作项，分配统一的优先级，做到端到端的敏捷管理；
• 变更和服务请求由专门的产品团队或以服务为中心的团队，以小迭代的方式处理，使产品或服务获得持续的反馈，且具有高可见性；
• 日常运营活动可以而且应该与其他任务一起显示和进行优先排序。所有服务管理活动都可以而且应该不断提供、收集和处理反馈。

综上所述，只有敏捷开发和服务管理一起以类似的节奏发展，说“同一种语言”，才可以确保组织继续与所有利益相关者共同创造价值。

Q23：ITIL指导原则是如何演变的？

AXELOS 在 2016 年发表了《ITIL 从业者指南》（ITIL Practitioner Guidance）。虽然 ITIL 的版本已经更迭，但指导原则历久弥新。

《从业者指南》中提出 9 项指导原则：

• 专注于价值
• 为体验而设计
• 从你所处的地方开始
• 整体工作
• 迭代地进步
• 直接观察
• 成为透明的
• 协作
• 保持简单

这些现在已经在 ITIL 4 中被削减、改变、添加到现在的 7 项 ITIL 指导原则：

• 聚焦
• 从你所处的地方开始
• 基于反馈的迭代推进
• 协作和提升可视化程度
• 通盘思考和工作
• 保持简单实用
• 优化和自动化

通过对比，可以看出 ITIL 4 保留了大部分的指导原则，并进行了扩充。例如《从业者指南》中提到的“为体验而设计”，实际在 ITIL 4 中已经融入了“聚焦价值”“通盘思考和工作”当中，并将其列为 34 个实践之一——“服务设计”。“协作”“成为透明的”也变成了“协作和提升可视化程度”。实际上通过可视化的工具，让流程等透明起来，才能更好地进行团队内、团队间、团队与组织、组织间的协作。“保持简单”扩充为“保持简单实用”。ITIL 4 将指导原则也融入了 SVS 中，而不是简单将其列出后就束之高阁。“自动化”也位居“优化”之后，被合并添加为指导原则之一，这也是一个非常棒的考虑。只有通过对活动的尽量优化后，活动才能有效地自动化。ITIL 4 建议大量地在各个实践中使用自动化，通过寻找自动化的机会，帮助节省组织成本、减少人为错误并改善员工体验。我们“应充分利用各种资源，特别是人力资源，并消除任何真正浪费的东西，用科技去实现它所能做到的一切， 人类干预应该只发生在真正有价值的地方”。

Q24：ITIL 4和风险管理的关系？

关于风险管理，我们可以参考国际公认的权威——ISO31000:2018 风险管理指南。在 这个 版本中， 其提出了风险管理目的和原则的总体和一般视角。它们适用于任何类型的组织中的所有级别。有趣的是，该标准的上一版本也是发布于 2009 年，同样 9 年来第一次更新。ISO31000:2018 声明“风险管理的目的是创造和保护价值”，风险管理“提高绩效，鼓励创新并支持实现目标”。

ISO31000:2018 有 8 项主题：

1. 高管支持是基础；
2. 在商业决策中考虑风险；
3. 强调正确地履行；
4. 风险管理不是放之四海而皆准的；
5. 积极主动；
6. 标准化词汇；
7. 利用现有的最佳信息；
8. 评价成功。

与之对比，ITIL 4 中风险管理实践的目的是确保组织理解并有效地处理风险，从而确保组织的可持续性和为客户创造价值。风险中有威胁也有机会，与威胁有关时，通常被认为是可以避免的。而与机会相关时，不抓住机会本身就是一种风险。风险管理是所有组织活动的一个必然的组成部分，对组织的 SVS 至关重要。近期华为在应对美国一系列动作时，就表现出极高的风险管理水平，当然，还有极高的业务连续性管理水平。

在 7 项指导原则中，和 ISO31000:2018 中 8 项主题有不少是能匹配的：

• 聚焦价值以及基于反馈迭代推进，对应于评价成功。这里强调衡量、评估和改进风险管理实践的价值。这样做的目的不是第一次就把所有的事情都做好，而是在每次迭代完成时都要持续改进它。即使是不完美的风险数据也可能有用，只要它与显示趋势的时间表一起呈现。最终，风险报告能为管理人员提供高质量信息。
• 通盘思考和工作，对应高管支持是基础，以及风险管理不是放之四海而皆准的。风险管理是一个循环过程，有足够的定制和改进空间，但其并非万能，管理者应该从整体去考虑，为自己的组织定制风险管理指南——特别是其风险概况、文化和风险偏好。风险管理实践必须全面管理，以实现整个组织的一致性。为确保有效性，应与利益相关方进行持续磋商，并为组织的不同部门提供适当的灵活性。这种灵活性将允许开发定制的风险管理程序，以便解决组织单位和 / 或客户特定情况。同时， 组织需要根据其愿意承担的风险偏好（即风险水平），对风险进行识别、评估、监控和管理。管理者还需要确保风险管理实践在组织的所有级别上得到充分集成，并与组织的目标结合在一起，让风险意识融入企业的运作方式中。
• 从你所处的地方开始，对应利用现有的最佳信息。当前很多风险管理都集中在可用的最佳信息上，而忽视了风险中的模糊性和不完善之处。管理者不应只是试图分享绝对的风险信息，而应利用这些模糊点，对他们提供的数据进行反思，从而更好地发现问题。
• 保持简单实用，对应标准化词汇。通过风险管理实践，提供一种公共语言，对风险、事件、后果和概率有简单和不复杂的定义。组织内均应采用这些术语，以确保交流不会产生分歧。
• 优化和自动化，对应积极主动。对风险应该采取积极的立场，并确保将风险管理集成到组织各级决策的各个方面。这包括在业务连续性管理、业务分析、劳动力和人才管理、信息安全管理、问题管理等方面，都需要作出主动的优化，形成主动风险管理行为。

回到管理实践中，我们试举几个和风险管理相关的例子：

• 在信息安全管理中，首当其冲的就是对可能产生的风险进行识别，以确保组织所需的信息安全性。
• 在问题管理实践中，问题管理活动可以为风险管理提供特定的案例，可识别、评估和控制服务管理的四个方面的风险，此时采用风险管理工具和技术进行问题管理往往很有效。
• 在可用性管理中，某些组织会将导致可靠性降低的因素作为风险管理的一部分。
• 在服务连续性中，需要彻底考虑影响服务连续性的因素，以及多个因素之间的关系，。假如不做风险评估，那么应急相关对应的场景就无法有效的识别，可能存在应急预案缺失的问题。
• 在服务设计方面，风险管理嵌入到了所有设计过程和活动中，确保所提供的产品和服务所涉及的风险和组织的风险控制水平保持一致。
• 在服务验证和测试方面，风险管理相关的条件也是服务验证的输入之一。

Q25：ITIL 4的价值流，能否以图形化的方式展现？

为了减少大家混淆流程活动和价值流活动，我们提出了如下的观点：流程活动中的“活动”是真正的动作，而价值流活动中的“活动”，主要负责价值的统计和呈现，并为进一步优化价值流提供了可能。价值流当中的“活动”可以理解为端到端的价值实现“步骤”，而价值流图可以认为是一个价值流动的看板工具。我们可以根据流程活动对价值流实现的不同阶段来将价值链划分为 6 大价值链活动，这些活动之间没有绝对的先后顺序之分，每个特定的价值流活动可以在各个价值链实现步骤间穿梭。因此我们将以泳道图的方式呈现基于 ITIL 4 的价值流图：将各个步骤设为泳道，流程的活动穿插于其中。

为了执行某项任务或响应特定情况，组织创建服务价值流。这些是活动和实践的特定组合，每个活动和实践都是针对特定场景而设计的——受众不同、目的不同。价值流可以是线性的或者瀑布式或者非瀑布式的，可以是动态的或者敏捷的，反之亦可行。

我们需要记住两个原则：一是价值链活动可以在价值流的过程中重复自己。而价值流是端到端的，以需求开始，以价值结束。任一价值流的目标都是将某一类特定的需求转换为价值。IT 组织通常缺乏这种“全局视野”，因为每个人的角色和流程都试图为客户做到最好，但可惜的是，每一个环节对于价值的理解可能都是片面的。只有当整个“价值流图”变得透明时，组织才能从全局的角度快速查看问题，并减少价值流中的浪费现象。

我们将根据一个软件功能升级的场景来展现价值流图样例，详情见下：

近期，由于总部颁布了一系列新的合规要求，部分 IT 服务系统无法满足，因此计划对这类 IT 服务系统进行升级。我们编制了该场景的价值流图如下：

                                        图4-10 软件功能升级场景价值流图

为了便于理解，这里，我们采用列表的方式将该价值流所经历的价值链活动以及对应的实践活动展示出来，帮助大家思考各个 ITIL 4 实践在服务价值链活动中的作用。

                                                          表4-5：软件功能升级场景价值流活动

通过价值流的形式构建组织 IT 服务价值交付的价值链活动，使组织能够清楚地了解其提供的服务内容和方式，可视化了解价值的创造过程，不断发现价值增长过程中的瓶颈和浪费，不断改进服务。这是 ITIL 4 中所提倡的。因此识别和理解组织的各种价值流，对于提高组织整体绩效至关重要。设计完成后，价值流应该不断改进。价值流优化可能包括流程自动化或新兴技术的采用以及提高效率或增强用户体验的工作方式。上述的价值流图还可以进一步被深化应用，例如基于某一个工作周期的总绩效，以量化的方式通过价值链看板实时动态呈现。又例如可以在各个价值链活动阶段进行价值统计， 让客户对实时获得的价值一目了然，增加对 IT 服务提供方所创造的价值的认同；也让 IT 服务内部团队看清自身所创造的价值，针对瓶颈和浪费，进行持续改进。这些都将是有益的尝试。

值得一提的是，如果我们可以根据客户预期的价值，甚至在契动阶段就将客户引入，去制定共同的视图，则价值流图可以更全局化和端到端，使得服务提供方和服务消费方的联合价值共创更高效、更敏捷。

Q26：ITIL 4和DevOps的关系？

ITIL 4 对过往的框架进行了重大变革，融合了各类最新的管理方法、思想和工具。其中包括近年来一直被认为挑战其江湖地位的 DevOps。在当今的 IT 服务管理领域中，两者存在着一定的交集，有些体现在理念、思维和指导原则层面，有些体现在产品和工具层面。细看这对“相爱相杀”的冤家， 相互学习，相互追赶超越，真的相映成趣，别有一番风景。我们尝试分析一下个中的异同。

相同之处：

1. 原则相互映射：DevOps 有三步工作法，每一个方法均有多个指导原则，而 ITIL 4 则有七项指导原则。ITIL 4 鼓励跨组织的协作和沟通，并为快速实现变更提供了更多的指导。过去 ITIL 强调规范、流程，而 DevOps 强调敏捷；而今天，从 ITIL 4 七项指导原则来看，其已充分吸收 DevOps“流动，反馈，持续学习和实验”的三步工作法的指导思想，使之为己所用。

                                   图4-11 DevOps三步工作

1.  DevOps 的流动是为了加速从开发到运维的价值交付，而 ITIL 4 定义了价值流以及通盘思考和工作的指导原则。通过整体和系统的思考，聚焦于价值的传递和交付之上。

   • DevOps 有反馈以建立更安全系统的工作制度，而 ITIL 4 定义了基于反馈的迭代推进以及持续改进。通过找到改进点与改进机会，进行优先级排序，消除瓶颈，从而不断地提升组织的管理能力与管理效率，让有效的反馈成为驱动改善系统控制回路的最大动力。
   • DevOps 有持续学习和实验，促进高度信任，形成“无谴责”的文化，将风险承担作为日常工作的一部分；而 ITIL 4 定义了从你所处的地方开始、通盘思考和工作、协作和提升可视化程度的原则以及持续改进的方法。通过工作中掌握的技能和与现有的工具来结合实践，形成更有效的价值链。
2. 目的一致：双方都要求有可视化的价值流，需要通过可视化来管理价值的流动，最终都是追求从端到端打通为用户交付价值的链条，并且强调工作的可视化要考虑全局而不是局部，如果仅仅度量开发的完成率、度量系统的可用性，这些都只是局部的目标。两者都是更关注全局、端到端的价值流动。

相异之处：

1. 在各自体系中将对方所置的地位不同：在 ITIL 4 中，DevOps 被当作在服务设计和转换以及获取 / 构建阶段的执行者。而在 DevOps 知识体系中，ITIL 被一定程度地矮化，仅在运营与周期终止阶段作为一个轻量级的 ITSM（EOL）引入，重点保证 IT 架构和系统的连续性。

1. 发展理念不同：ITIL 4 中虽然扩展了关于价值、价值流、价值共创等理念，但是实际在做“减法”， 部分实践的方法指导相对旧版要显得抽象一些，这样为组织能更好、更简单、更灵活地应用 ITIL 以及适配未来层出不穷的新技术、新思维、新方法预留了弹性空间，也为广大 ITIL 爱好者们指明了更合适的演进路径。而 DevOps 尤其是在 2.0 版本中，开始做“加法”。其已经不再满足只是一条单纯的持续交付工具链或者一项敏捷的工作方法，它开始引入 Lean IT、敏捷等实践方法，试图定义整个ITSM 生态，并成为一种特有的文化。

那么两者是否能够进行整合或相互兼容，从而携手支持更短的交付周期，优化业务的上市时间并实现更高的部署频率呢？答案是可以的。从 ITIL 4 的视角看去，因为 DevOps 方法基于敏捷软件开发和持续交付的自动化技术，强调软件开发和技术操作之间的紧密协作，因此可利用高度自动化来节省专业技术人员的时间，使他们能够专注于增值活动，让 DevOps 能够提升软件产品的可操作性、可靠性和可维护性等。而DevOps 从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动， 以便产品和服务团队保持相同的目标并使用相同的方法。

DevOps 被认为是结合了软件开发技术（敏捷）、价值共创（ITIL 4），以及对学习和改进价值生产方式（精益）执着追求的整体方法。在 ITIL 4 中，组织面临的主要挑战之一是确定其特定的价值流。DevOps 是一个很好的ITIL 4 价值流实例，其涵盖了从业务需求、开发、测试、发布计划到部署的活动。因此，采用或借用 DevOps 方法将为改进软件产品的开发和管理方式提供更多机会，例如：

• 创建从交付和支持到软件开发和技术操作的快速反馈循环；
• 简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值；
• 分离部署管理与发布管理；
• 倡导“整体系统视图”，强调企业治理，促进服务团队、软件开发和技术运维之间的紧密协作。

DevOps 将在 ITIL 4 服务目录管理、服务级别管理、变更管理、配置管理、发布管理、部署管理等实践中大展拳脚。

Q27：ITIL 4和项目管理的关系？

在 2017 年，美国项目管理协会（PMI）更新了项目管理知识体系（PMBOK）。至此 PMBOK 升级为第 6 版。在第 6 版中，变动并不是太大。知识体系更结构化和标准化；对六个知识领域进行了微调， 并给出了知识领域的剪裁指南和敏捷化指南；取消了“项目管理过程”，提出了“项目经理的角色（The Role of Project Manager）”的概念。

新版本并未改变对项目的定义，仍为“为创造独特的产品、服务或成果而进行的临时性工作”。这直接意味着服务交付是项目类型之一，其中可交付的是客户请求的实际服务。根据 PMBOK 指南区分项目的主要特征，以及服务交付如何满足这些特征，我们可以看到以下几个特点：

• 临时（temporary:）：项目是一项临时的工作，有一个开始和一个结束。服务在其服务价值链中经历了从收到的需求 / 机会开始，到向客户交付价值的连续阶段，而持续改进、治理、实践、指导原则围绕着所有活动。
• 独特的产品、服务或成果（unique product，service，or result）：一个项目的交付物被认为是独特的，不像在运营活动中的重复性活动，这是通过响应特定需求交付给特定客户的 IT 服务来满足的。
• 渐进明细（progressive elaboration）：项目执行是迭代的，并且不断地循序渐进以响应变更，这可以通过 ITIL 4 框架中的持续改进以及基于反馈的迭代推进，以及相关实践来满足。

在过往，我们可以将 ITIL v3/2011 的生命周期与 PMBOK 的五大过程组粗略地做一个映射。服务战略对应启动过程与规划过程；服务设计、服务转换、服务运营对应执行过程，持续服务改进对应监控过程，服务退役对应收尾过程——ITIL v3/2011 并没有这个阶段，我们选择了最接近“关闭”的术语。

但在 ITIL 4 的时代，将 IT 服务交付视为项目表明项目管理的概念和原则与 IT 服务管理的概念

和原则之间存在必要的相似性或对应关系，我们舍易取难，根据 PMBOK 第 6 版的 5 大过程组和 49 个过程，与 ITIL 4 框架下的 34 个实践进行了映射和集成。我们考虑了应用每个 PMBOK 流程时应该考虑的实践，在特定情况下适用的过程集取决于特定的项目需求。在下表中，将概述这些交点。从 PMBOK 指南的角度看项目管理，从 ITIL 4 框架的角度看 IT 服务管理。

                              图4-12 ITIL 4-PMBOK第6版映射图

ITIL 4 将项目管理作为一项实践，其与风险管理一样，穿插于不少的实践过程中。项目管理实践的目的是确保组织中的所有项目都能成功交付，这需要通过规划、指派、监控和维护对项目所有方面的控制，并保持相关人员的积极性来实现的。项目是向组织引入重大变更的手段之一，它们可以被定义为为了根据商定的业务案例提供一个或多个输出（或产品）而创建的临时结构。对于更复杂的转型项目，它们可能是一个独立的计划，也可能是一个更大的计划的一部分，以及其他相互关联的项目。但是，即使是独立项目也应该在组织的项目组合中考虑。最终，ITIL 4 通过调和项目管理与 ITIL 4 众多实践之间的关系，使各实践能与项目管理保持一致。

Q28：ITIL  4和TOGAF的结合关系？

谈及架构管理，各位脑海肯定会浮现出 TOGAF。在 2018 年，TOGAF 也从旧版本 9.1 升级为 9.2。该标准经过重新设计，并重组为较小的出版物，其中包括了一些单独的指南。在新版标准中，TOGAF 框架的核心保持不变，增强了业务架构和内容元模型，对热点技术创新领域进行系统化的设计。TOGAF 目前分为六部分，包括：简介、架构开发方法（ADM）、架构开发方法指南和技术、体系结构内容框架、企业连续性工具以及体系架构能力框架。其架构开发方法见下图：

                               图4-16 TOGAF架构开发方法

TOGAF 列出了四种被广泛接受的子架构：

• 业务架构：定义了商业策略、管理、组织和关键业务流程；
• 应用架构：为待配置的应用系统提供一个蓝图，从他们的交互、他们的关系到该组织核心的业务流程；
• 数据架构：描述一个组织逻辑的和物理的数据资产和数据管理资源的结构；
• 技术架构：描述了支持核心部署和关键任务应用的软件基础设施。

四种子架构，可以认为是 TOGAF 对 IT 世界的一种抽象的归纳。回想起 ITIL，也有这么一个术语与之匹配，那就是 CMDB（配置管理数据库）。我们的 CMDB 基于消费的情况来进行配置，当系统比较复杂，使用精度要求比较高的情况下，CI（配置项）同样可以按照业务、应用、数据、技术四类来进行分类。从最前端的业务开始，将 CI 最终分解到基础架构上去，并且其后带着 CI 之间上下、平行、互相引用等关系。

ITIL 4 将架构管理作为实践之一，纳入其 SVS 框架。该实践的目的是提供对构成组织的所有不同元素的理解以及这些元素之间如何相互关联，从而使组织能够有效地实现其当前和未来的目标。它提供了原则、标准和工具，使组织能够以结构化和敏捷的方式管理复杂的变更。这些不仅包括如何提高效率和自动化，还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹性。如果没有通过适当的架构管理实践来实现可见性和协调，最终组织只会获得一个传统架构下的迷宫，任何变化都难以实施，并具有极高的风险。

完整的体系架构管理实践应该涉及所有体系架构域：业务，服务，信息，技术和环境。对于规模较小且不太复杂的组织，可由架构师开发单一的集成架构。

• 业务架构：允许组织查看其能力，了解它们如何与为组织及其客户创造价值所需的所有具体活动保持一致。然后将这些与组织的策略进行比较，并执行目标状态与当前能力的差距分析。确定基线和目标状态之间的已确定差距的优先级，并逐步解决这些能力差距。以“路线图”的方式，描述了从当前状态到未来状态的转变，以实现组织的战略。
• 服务架构：服务结构为组织提供了其提供的所有服务的视图，包括描述架构的服务和服务模型之间的交互（服务组件如何组合在一起）和每个服务的动态（活动、资源流和交互）。服务模型可以用作多个服务的模板或蓝图。
• 信息架构：描述了组织的逻辑和物理数据资产以及数据管理资源。它显示了如何管理和共享信息资源以使组织受益。
• 技术架构：定义了支持产品和服务组合所需的软件和硬件基础架构。IT 系统的运作往往需要依赖架构。组织提供服务时，受到挑战的往往是 IT 系统的综合能力，例如在双十一的凌晨，各大电商的后台如何处理突然倍速暴增的订单，这对该组织技术架构的弹性提出了巨大的挑战。
• 环境架构：描述了影响组织的外部因素和变革的驱动因素，以及环境控制及其管理的所有方面、类型和水平。环境包括发展、技术、商业、运营、组织、政治、经济、法律、监管、生态和社会影响。

在应用过程中，ITIL 4 对 TOGAF 的架构开发方法，进行充分地融合。由于 TOGAF 本身所具有的开放性和灵活性，因此不会排斥组织中对其他框架理论的引入和使用，这当然也包括了 ITIL 4。企业架构开发方法各阶段的输入与输出可以不拘泥于其定义，可采用适合组织自身情况的其他框架中所定义的相关内容，并作适当的剪裁，甚至各阶段的先后顺序也是可以调整的。在架构管理的过程中，同样需要采用“持续优化”的方式，进行循环的迭代。

通过 TOGAF 的应用，能够为组织增加弹性、提高敏捷性、增加收入、降低成本以及整合横跨竖井的应用和组织。这些恰恰都是 ITIL 4 所需要的！组织在刚进行架构管理的时候，难免会因为架构的缺乏和粗略而举步维艰。但随着一个又一个架构被开发出来，被应用与管理，架构管理的循环持续进行着，则架构管理的内容将日趋丰富和成熟，从而架构的开发也会越发轻快，架构的管理也会越发纯熟。

总而言之，ITIL 4 将架构管理纳入实践，可以很好地将 TOGAF 的架构设计和演进方法引入服务的价值交付过程中，通过更优化的架构来为客户创造更大的价值。