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

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

From version < 21.1 >

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

To version < 20.1 >

edited by superadmin
on 2020/06/15, 17:59

< >

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -14,7
          +14,7 @@
  我们可以从 ITIL 4 作者之一 Stuart Rance 的话中得到一些启示。Stuart Rance 是 ITIL 的资深作者和IT 行业权威，他在一篇名为《ITIL v3/2011 有什么问题？》的博文中，指出了 ITIL v3/2011（或者更准确地说，ITIL v3/2011 版本）需要更新的五个关键原因：
--*
++*
  ** ITIL v3/2011 过于关注过程；
  ** 需要在竖井中实现（组织分别运作每个流程），尤其是服务战略→服务设计→服务转换→服务运营→持续服务改进的生命周期模式，实在是太像传统的瀑布式服务交付模型了；
  ** 对价值、成果、成本和风险的关注太少；
@@ -39,13
          +39,13 @@
  ITIL 4 的进阶路径，包含了：
--*
++*
  ** 左路 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（指导、计划和优化）。
@@ -58,12
          +58,12 @@
  则只需要考取 ITIL 领导者 - Digital & IT Strategy（数字化和 IT 战略）认证即可。
--*
++*
  ** 右路 ITIL Strategic Leader（ITIL SL 战略领导者）包括两门中级模块（包含 1 门战略师认证课程和 1 门领导者认证课程），课程着眼于体现 ITIL 的价值，跳出 IT 运营的框架，考虑更全面的数字化服务，经过认证的专家将在 IT 如何影响和指导业务战略方面有出众的表现。
  进阶路径具体包含的课程内容如下：
--*
++*
  ** ITIL 战略 Direct，Plan & Improve - DPI（指导、计划和优化）
  ** ITIL 领导者 Digital & IT Strategy -DIS（数字化和 IT 战略）
@@ -76,7
          +76,7 @@
  对 IT 服务有兴趣的从业或非从业者，都可以学习 ITIL 4 基础级。一般而言，学习对象主要有以下几类人士：
--*
++*
  ** 信息中心主任、CIO、IT 运维经理、数据中心经理；
  ** IT 运维人员、IT 项目经理、软件 / 系统开发主管；
  ** IT/ 业务经理、资深 IT 人员、IT 支持服务主管；
@@ -93,7
          +93,7 @@
  与 ITIL v3/2011 对比，ITIL 4 进一步演进，创建了服务价值系统（SVS），其改进内容可以归纳为以下五个主要方面：
--*
++*
  ** 推出了 SVS、SVC 全新框架，符合当前数字化转型的大趋势和方向；
  ** 改流程为实践，将流程、技术、人员和管理方法整合为同一概念，不再割裂地看待 IT 服务管理要素；
  ** 将分阶段、瀑布式的服务生命周期改为贯穿端到端的服务价值链；
@@ -283,7
          +283,7 @@
  ITIL 4 将为组织带来如下的好处：
--*
++*
  ** 使 IT 服务与业务优先级保持一致，以实现战略目标；
  ** 提高服务组合的价值，同时降低成本和风险；
  ** 提高 IT 员工的岗位胜任力、工作能力和生产力，更好地利用员工的技能和经验；
@@ -318,7
          +318,7 @@
  信息管理也需要加以区分，我们需要了解：
--*
++*
  ** 服务提供和管理的是哪些信息？
  ** 提供和确保服务需要哪些信息和知识？
  ** 这些信息和知识如何作为企业的资源被保护、获取、存档甚至删除？
@@ -333,7
          +333,7 @@
  影响供应商使用战略的因素包括：
--*
++*
  ** 战略重点：什么是组织的核心业务，我们从合作伙伴那里获得什么？
  ** 企业文化：过去与合作伙伴合作过什么？我们具有何种经验？
  ** 资源准备：我们可以自行开拓某些资源还是需要供应商的帮助？
@@ -347,7
          +347,7 @@
  图4-4 PESTEL分析法
--*
++*
  ** 需求：客户需求是否会受到季节性波动的影响，是否可以在合作伙伴的帮助下实现平衡？
  * 价值流和流程
@@ -364,11
          +364,11 @@
  您还需要了解两件事情：
--1.
++1.
 . 根据目前官方公布的信息，ITIL v3/2011 培训考试计划最早将于 2020 年 6 月不再继续提供。
 . 从 ITIL v3/2011 升级到 ITIL 4 认证的途径，根据不同的情况，我们给出以下三类建议：
--*
++*
  ** 情况一，您只拥有 ITIL v2 或 v3 基础级的认证：
  如Q8 所述，您需要从ITIL 4 基础级开始考试。通过ITIL 4 基础级过渡到ITIL 4 的新认证体系中。然后选择自己感兴趣的模块，成为 ITIL 策略师、领导者，甚至大师。
@@ -375,7
          +375,7 @@
  当然，您也可以选择不升级。不升级其实也没有关系，因为我们相信您拥有一张早期的 ITIL 证书也是倍有面子的。只是，它无法证明您经过了 ITIL 4 的价值链与数字化服务思想的熏陶罢了。
--*
++*
  ** 情况二，您拥有 ITIL v3 Expert 的认证：
  |
@@ -389,7
          +389,7 @@
  我们还有另外一个建议，如果您已决定选择这条升级路线，请尽早启动学习。因为过渡模块只存在一个不会太长的过渡期中，过渡期后过渡模块将会取消。官方已于 2019 年 10 月正式对外发布过渡模块课程。之前也曾经有一个通过 Bridge 培训考试快速升级成 ITIL v3 Expert 的机会，放在一些拥有 ITIL v2 Manager 认证学习者的面前，但他们错过了，追悔莫及。
--*
++*
  ** 情 况 三， 您 已 经 在 ITIL v3/2011 的 认 证 体 系 中 持 有 若 干 门 ITIL v3 OSA/ PPO/RCV/ SOA/ Practitioner 等中级证书但却不足 17 个学分：那么您可以考虑两条路径。
  路径 1——固本培元：您将从 ITIL 4 基础级开始，夯实基础，重新一步步逐级完成 ITIL 4 的学习。
@@ -417,7
          +417,7 @@
  比较精巧的设计。将流程由“重”转到实践之“轻”。过往不少人一听到 ITIL，第一反应就是一堆流程，万事流程先行。殊不知，单个流程虽然也有意义，但是仍需工具和支撑架构来扶持。实践被定义为“支持多个价值链活动并提供为确保实践成功所需资源的支持，这些资源可以来自供应商和内部的IT 组织”。我们也可以笼统地认为，流程是“一套完成工作的组织机制”。ITIL 4 中归纳为三类实践：
--*
++*
  ** 通用管理实践（General Management Practices），共 14 个，包括架构管理、关系管理等；
  ** 服务管理实践（Service Management Practices），共 17 个，包括资产管理、问题管理等；
  ** 技术管理实践（Technical Management Practices），共 3 个，包括部署管理、基础设施和平台管理、软件开发和管理等。
@@ -663,6
          +663,7 @@
  )))|·ITIL v3/2011的出版物中，提供了一些关于能力开发和培训的指导。
++
  |(% colspan="3" %)(((
@@ -793,6
          +793,7 @@
++
  续表
@@ -906,6
          +906,7 @@
  |22|服务财务管理|2
++
  [[image:image-20200615172225-11.png]]续表
@@ -988,7
          +988,7 @@
  所以我们在使用 ITIL 的时候，有两种途径：
--*
++*
  ** 适应：尽力去理解 ITIL 最佳实践，明白他们为什么被推荐，尝试着去应用其中关键的思维， 用这些最佳实践去应对组织的环境、需求和目标。
  ** 采用：转向以服务为导向型的战略，推动组织内“以顾客为中心”的文化。服务管理的成功来源于对上述变革的真正认同。这种真正的认同，并不只是组织内的几句口号，而是组织内人们行动的以及其行动被激励的方式。
@@ -999,7
          +999,7 @@
  [[image:image-20200615180054-4.jpg]]在 AXELOS 发布的《ITIL 4 与云》的白皮书中，有有如下详细的描述：新的数字技术要求组织改变或调整他们的商业模式。这种数字转型是由新兴技术推动的，例如：
--*
++*
  ** 云计算
  ** 大数据
  ** 物联网
@@ -1019,7
          +1019,7 @@
  在 ITIL 4 的实践当中，有相当一部分的实践任务能通过组织外包的形式，由云服务提供商以云基服务的方式提供。例如，对于云上电子商务系统而言，服务提供商负责电子商务系统背后的整个底层基础架构，包括事件、问题、变更、发布、部署、容量和可用性的流程和实践。但总体服务的责任仍由采购该服务的组织承担。这样做有不少的好处：
--*
++*
  ** 系统架构上，通过 PaaS 能很容易的实现 SOA、微服务等架构，为企业新业务的拓展带来很大的帮助；
  ** 流程上，通过云计算，能大大提高系统的可用性和弹性。因此在可用性、业务连续性和容量方面都有较大的帮助。尤其云数据中心一旦采用分布式的架构，则在云上运行的应用，就带有天然连续性属性。
  ** 日常使用上，云服务一般自带监控和汇报系统，在事件、问题、监控和事态管理方面，云上应用都将受益。
@@ -1027,7
          +1027,7 @@
  云基服务有不少优点，但是参照 ITIL 4 框架，还存在一些有待解决的挑战，例如：
--*
++*
  ** 云服务供应商提供的云基服务往往是通用的服务，其是否符合组织所制定的 SLA，是否符合组织未来的发展需求？
  ** 随着更多的业务迁移上云，面对不时发生的云基服务宕机事件，组织如何有效地应对？
  ** 云计算的重要特征是按需自助服务和快速弹性，现有业务及其系统能否适应这种高速、高度自动化的转型？变更和部署流程应该如何做调整？
@@ -1043,7
          +1043,7 @@
  职能被定义为“专门执行某种类型的工作，并对所产生的特定结果负责的组织单元”。服务台， 是组织对外服务的统一窗口；劳动力与人才管理，专门执行与人力资源相关的工作，往往由人事部或人力资源部负责。
--*
++*
  ** 服务台（服务管理实践）
  ** 劳动力与人才管理（通用管理实践）
  * 技术类（合计 3 项）：
@@ -1052,7
          +1052,7 @@
  ITIL 4 中，基础架构和平台管理同云平台和云基服务关联相当紧密。软件开发管理考虑到现有系统和创新（甚至是颠覆）系统之间的分野，兼容传统的基于软件开发成熟度模型（CMM）理论体系的瀑布式开发和遵循《敏捷宣言》的敏捷开发理论。
--*
++*
  ** 部署管理（技术管理实践）
  ** 基础设施与平台管理（技术管理实践）
  ** 软件开发与管理（技术管理实践）
@@ -1060,7
          +1060,7 @@
  在改进计划、组织变革管理、服务财务管理、业务管理等众多实践中，往往都需要持续改进实践来指导，以及项目管理实践来组织和管理其执行。持续改进实践还是 ITIL 4 的 7 项指导原则，包括了相关的方法、技术和文化，将其归类在方法类，还是比较合适的。正如现代组织的环境和生态系统变得更加复杂，其挑战也是如此。这些不仅包括如何提高效率和自动化，还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹性。在如此复杂的 IT 环境，任何变化都寸步难行，并且风险四伏。完整的体系架构管理实践应该涉及所有体系结构域：业务、服务、信息、技术和环境。可喜的是， ITIL 4 参考并融合了 SOA 框架和 TOGAF 企业架构方法论。
--*
++*
  ** 持续改进（通用管理实践）
  ** 项目管理（通用管理实践）
  ** 架构管理（通用管理实践）
@@ -1070,7
          +1070,7 @@
  根据定义，我们将通用管理实践中的 ITIL 前版本中所提及的知识管理、信息安全管理、关系管理等归入了流程类。服务管理实践内的大部分实践我们也归入了流程类。
--*
++*
  ** 信息安全管理（通用管理实践）
  ** 知识管理（通用管理实践）
  ** 组织变革管理（通用管理实践）
@@ -1109,12
          +1109,13 @@
  |
  | |[[image:image-20200615180054-5.jpg]]
++
  图4-9 敏捷开发路线图
  与敏捷开发相关的概念非常多，包括测试驱动开发、持续集成、重构、结对编程、每日站会、小版本发布、自动化测试。敏捷软件开发通常包括：
--*
++*
  ** 通过反馈分析和直接观察收集不断变化的需求；
  ** 将开发工作分成小的增量和迭代；
  ** 建立基于产品的跨职能团队；
@@ -1127,7
          +1127,7 @@
  对于 ITIL 的前版本而言，ITIL 在服务转换阶段，在软件开发方面相对较弱，在端到端服务的过程中也相对较弱，必须要借助敏捷的思维，保持对客户和用户价值的关注，摆脱流程变得笨拙、沉重且高度集中的可能性。两者间的协同工作方式如：
--*
++*
  ** 在服务交付阶段，引入持续交付，在同一个价值流图看整体的情况，统一安排工作项，分配统一的优先级，做到端到端的敏捷管理；
  ** 变更和服务请求由专门的产品团队或以服务为中心的团队，以小迭代的方式处理，使产品或服务获得持续的反馈，且具有高可见性；
  ** 日常运营活动可以而且应该与其他任务一起显示和进行优先排序。所有服务管理活动都可以而且应该不断提供、收集和处理反馈。
@@ -1141,7
          +1141,7 @@
  《从业者指南》中提出 9 项指导原则：
--*
++*
  ** 专注于价值
  ** 为体验而设计
  ** 从你所处的地方开始
@@ -1154,7
          +1154,7 @@
  这些现在已经在 ITIL 4 中被削减、改变、添加到现在的 7 项 ITIL 指导原则：
--*
++*
  ** 聚焦价值
  ** 从你所处的地方开始
  ** 基于反馈的迭代推进
@@ -1185,7
          +1185,7 @@
  在 7 项指导原则中，和 ISO31000:2018 中 8 项主题有不少是能匹配的：
--*
++*
  ** 聚焦价值以及基于反馈迭代推进，对应于评价成功。这里强调衡量、评估和改进风险管理实践的价值。这样做的目的不是第一次就把所有的事情都做好，而是在每次迭代完成时都要持续改进它。即使是不完美的风险数据也可能有用，只要它与显示趋势的时间表一起呈现。最终，风险报告能为管理人员提供高质量信息。
  ** 通盘思考和工作，对应高管支持是基础，以及风险管理不是放之四海而皆准的。风险管理是一个循环过程，有足够的定制和改进空间，但其并非万能，管理者应该从整体去考虑，为自己的组织定制风险管理指南——特别是其风险概况、文化和风险偏好。风险管理实践必须全面管理，以实现整个组织的一致性。为确保有效性，应与利益相关方进行持续磋商，并为组织的不同部门提供适当的灵活性。这种灵活性将允许开发定制的风险管理程序，以便解决组织单位和 / 或客户特定情况。同时， 组织需要根据其愿意承担的风险偏好（即风险水平），对风险进行识别、评估、监控和管理。管理者还需要确保风险管理实践在组织的所有级别上得到充分集成，并与组织的目标结合在一起，让风险意识融入企业的运作方式中。
  ** 从你所处的地方开始，对应利用现有的最佳信息。当前很多风险管理都集中在可用的最佳信息上，而忽视了风险中的模糊性和不完善之处。管理者不应只是试图分享绝对的风险信息，而应利用这些模糊点，对他们提供的数据进行反思，从而更好地发现问题。
@@ -1194,7
          +1194,7 @@
  回到管理实践中，我们试举几个和风险管理相关的例子：
--*
++*
  ** 在信息安全管理中，首当其冲的就是对可能产生的风险进行识别，以确保组织所需的信息安全性。
  ** 在问题管理实践中，问题管理活动可以为风险管理提供特定的案例，可识别、评估和控制服务管理的四个方面的风险，此时采用风险管理工具和技术进行问题管理往往很有效。
  ** 在可用性管理中，某些组织会将导致可靠性降低的因素作为风险管理的一部分。
@@ -1202,6
          +1202,7 @@
  ** 在服务设计方面，风险管理嵌入到了所有设计过程和活动中，确保所提供的产品和服务所涉及的风险和组织的风险控制水平保持一致。
  ** 在服务验证和测试方面，风险管理相关的条件也是服务验证的输入之一。
++
  == Q25：ITIL 4的价值流，能否以图形化的方式展现？ ==
@@ -1219,6
          +1219,7 @@
  |
  | |[[image:image-20200615180117-8.png]]
++
  图4-10 软件功能升级场景价值流图
  为了便于理解，这里，我们采用列表的方式将该价值流所经历的价值链活动以及对应的实践活动展示出来，帮助大家思考各个 ITIL 4 实践在服务价值链活动中的作用。
@@ -1363,6
          +1363,7 @@
  更新的服务符合新合规要求。
  )))|
++
  通过价值流的形式构建组织 IT 服务价值交付的价值链活动，使组织能够清楚地了解其提供的服务内容和方式，可视化了解价值的创造过程，不断发现价值增长过程中的瓶颈和浪费，不断改进服务。这是 ITIL 4 中所提倡的。因此识别和理解组织的各种价值流，对于提高组织整体绩效至关重要。设计完成后，价值流应该不断改进。价值流优化可能包括流程自动化或新兴技术的采用以及提高效率或增强用户体验的工作方式。上述的价值流图还可以进一步被深化应用，例如基于某一个工作周期的总绩效，以量化的方式通过价值链看板实时动态呈现。又例如可以在各个价值链活动阶段进行价值统计， 让客户对实时获得的价值一目了然，增加对 IT 服务提供方所创造的价值的认同；也让 IT 服务内部团队看清自身所创造的价值，针对瓶颈和浪费，进行持续改进。这些都将是有益的尝试。
  值得一提的是，如果我们可以根据客户预期的价值，甚至在契动阶段就将客户引入，去制定共同的视图，则价值流图可以更全局化和端到端，使得服务提供方和服务消费方的联合价值共创更高效、更敏捷。
@@ -1376,13
          +1376,15 @@
 . 原则相互映射：DevOps 有三步工作法，每一个方法均有多个指导原则，而 ITIL 4 则有七项指导原则。ITIL 4 鼓励跨组织的协作和沟通，并为快速实现变更提供了更多的指导。过去 ITIL 强调规范、流程，而 DevOps 强调敏捷；而今天，从 ITIL 4 七项指导原则来看，其已充分吸收 DevOps“流动，反馈，持续学习和实验”的三步工作法的指导思想，使之为己所用。
++
  |
  | |[[image:image-20200615180118-10.jpg]]
++
  图4-11 DevOps三步工作法
--1.
++1.
 *. DevOps 的流动是为了加速从开发到运维的价值交付，而 ITIL 4 定义了价值流以及通盘思考和工作的指导原则。通过整体和系统的思考，聚焦于价值的传递和交付之上。
 *. DevOps 有反馈以建立更安全系统的工作制度，而 ITIL 4 定义了基于反馈的迭代推进以及持续改进。通过找到改进点与改进机会，进行优先级排序，消除瓶颈，从而不断地提升组织的管理能力与管理效率，让有效的反馈成为驱动改善系统控制回路的最大动力。
 *. DevOps 有持续学习和实验，促进高度信任，形成“无谴责”的文化，将风险承担作为日常工作的一部分；而 ITIL 4 定义了从你所处的地方开始、通盘思考和工作、协作和提升可视化程度的原则以及持续改进的方法。通过工作中掌握的技能和与现有的工具来结合实践，形成更有效的价值链。
@@ -1392,6
          +1392,7 @@
 . 在各自体系中将对方所置的地位不同：在 ITIL 4 中，DevOps 被当作在服务设计和转换以及获取 / 构建阶段的执行者。而在 DevOps 知识体系中，ITIL 被一定程度地矮化，仅在运营与周期终止阶段作为一个轻量级的 ITSM（EOL）引入，重点保证 IT 架构和系统的连续性。
++
 . 发展理念不同：ITIL 4 中虽然扩展了关于价值、价值流、价值共创等理念，但是实际在做“减法”， 部分实践的方法指导相对旧版要显得抽象一些，这样为组织能更好、更简单、更灵活地应用 ITIL 以及适配未来层出不穷的新技术、新思维、新方法预留了弹性空间，也为广大 ITIL 爱好者们指明了更合适的演进路径。而 DevOps 尤其是在 2.0 版本中，开始做“加法”。其已经不再满足只是一条单纯的持续交付工具链或者一项敏捷的工作方法，它开始引入 Lean IT、敏捷等实践方法，试图定义整个ITSM 生态，并成为一种特有的文化。
  那么两者是否能够进行整合或相互兼容，从而携手支持更短的交付周期，优化业务的上市时间并实现更高的部署频率呢？答案是可以的。从 ITIL 4 的视角看去，因为 DevOps 方法基于敏捷软件开发和持续交付的自动化技术，强调软件开发和技术操作之间的紧密协作，因此可利用高度自动化来节省专业技术人员的时间，使他们能够专注于增值活动，让 DevOps 能够提升软件产品的可操作性、可靠性和可维护性等。而DevOps 从业者倡导的文化方面可以并且应该扩展到价值流和所有服务价值链活动， 以便产品和服务团队保持相同的目标并使用相同的方法。
@@ -1398,7
          +1398,7 @@
  DevOps 被认为是结合了软件开发技术（敏捷）、价值共创（ITIL 4），以及对学习和改进价值生产方式（精益）执着追求的整体方法。在 ITIL 4 中，组织面临的主要挑战之一是确定其特定的价值流。DevOps 是一个很好的ITIL 4 价值流实例，其涵盖了从业务需求、开发、测试、发布计划到部署的活动。因此，采用或借用 DevOps 方法将为改进软件产品的开发和管理方式提供更多机会，例如：
--*
++*
  ** 创建从交付和支持到软件开发和技术操作的快速反馈循环；
  ** 简化价值链活动和价值流，使工作需求可以快速转化为多个利益相关者的价值；
  ** 分离部署管理与发布管理；
@@ -1413,7
          +1413,7 @@
  新版本并未改变对项目的定义，仍为“为创造独特的产品、服务或成果而进行的临时性工作”。这直接意味着服务交付是项目类型之一，其中可交付的是客户请求的实际服务。根据 PMBOK 指南区分项目的主要特征，以及服务交付如何满足这些特征，我们可以看到以下几个特点：
--*
++*
  ** 临时（temporary:）：项目是一项临时的工作，有一个开始和一个结束。服务在其服务价值链中经历了从收到的需求 / 机会开始，到向客户交付价值的连续阶段，而持续改进、治理、实践、指导原则围绕着所有活动。
  ** 独特的产品、服务或成果（unique product，service，or result）：一个项目的交付物被认为是独特的，不像在运营活动中的重复性活动，这是通过响应特定需求交付给特定客户的 IT 服务来满足的。
  ** 渐进明细（progressive elaboration）：项目执行是迭代的，并且不断地循序渐进以响应变更，这可以通过 ITIL 4 框架中的持续改进以及基于反馈的迭代推进，以及相关实践来满足。
@@ -1486,7
          +1486,7 @@
  TOGAF 列出了四种被广泛接受的子架构：
--*
++*
  ** 业务架构：定义了商业策略、管理、组织和关键业务流程；
  ** 应用架构：为待配置的应用系统提供一个蓝图，从他们的交互、他们的关系到该组织核心的业务流程；
  ** 数据架构：描述一个组织逻辑的和物理的数据资产和数据管理资源的结构；
@@ -1498,7
          +1498,7 @@
  完整的体系架构管理实践应该涉及所有体系架构域：业务，服务，信息，技术和环境。对于规模较小且不太复杂的组织，可由架构师开发单一的集成架构。
--*
++*
  ** 业务架构：允许组织查看其能力，了解它们如何与为组织及其客户创造价值所需的所有具体活动保持一致。然后将这些与组织的策略进行比较，并执行目标状态与当前能力的差距分析。确定基线和目标状态之间的已确定差距的优先级，并逐步解决这些能力差距。以“路线图”的方式，描述了从当前状态到未来状态的转变，以实现组织的战略。
  ** 服务架构：服务结构为组织提供了其提供的所有服务的视图，包括描述架构的服务和服务模型之间的交互（服务组件如何组合在一起）和每个服务的动态（活动、资源流和交互）。服务模型可以用作多个服务的模板或蓝图。
  ** 信息架构：描述了组织的逻辑和物理数据资产以及数据管理资源。它显示了如何管理和共享信息资源以使组织受益。

粤ICP备17056641号

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