由 superadmin 于 2024/12/25, 15:27 最后修改
从版本< 28.1 >
由superadmin编辑
在2020/06/17, 17:26上
到版本
由superadmin编辑
在2020/06/17, 17:22上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
Content
... ... @@ -2,8 +2,341 @@
2 2  
3 3  == ==
4 4  
5 -== ==
5 +== Q21：ITIL 4的实践如何分类？ ==
6 6  
7 +
8 +我们可以将 ITIL 4 的 34 项实践，按照职能、技术、方法、流程分为四大类。
9 +
10 +* 职能类（合计 2项）：
11 +
12 +职能被定义为“专门执行某种类型的工作，并对所产生的特定结果负责的组织单元”。服务台， 是组织对外服务的统一窗口；劳动力与人才管理，专门执行与人力资源相关的工作，往往由人事部或人力资源部负责。
13 +
14 +* 服务台（服务管理实践）
15 +* 劳动力与人才管理（通用管理实践）
16 +* 技术类（合计 3 项）：
17 +
18 +技术管理实践中包含了 3 项实践，我们将其均列为技术类。前文也提及，“部署管理”因更具技术属性，与“发布管理”剥离，被划分至“技术管理实践”。
19 +
20 +ITIL 4 中，基础架构和平台管理同云平台和云基服务关联相当紧密。软件开发管理考虑到现有系统和创新（甚至是颠覆）系统之间的分野，兼容传统的基于软件开发成熟度模型（CMM）理论体系的瀑布式开发和遵循《敏捷宣言》的敏捷开发理论。
21 +
22 +* 部署管理（技术管理实践）
23 +* 基础设施与平台管理（技术管理实践）
24 +* 软件开发与管理（技术管理实践）
25 +* 方法类（合计 3 项）：
26 +
27 +在改进计划、组织变革管理、服务财务管理、业务管理等众多实践中，往往都需要持续改进实践来指导，以及项目管理实践来组织和管理其执行。持续改进实践还是 ITIL 4 的 7 项指导原则，包括了相关的方法、技术和文化，将其归类在方法类，还是比较合适的。正如现代组织的环境和生态系统变得更加复杂，其挑战也是如此。这些不仅包括如何提高效率和自动化，还包括如何更好地管理环境的复杂性以及如何实现组织敏捷性和弹性。在如此复杂的 IT 环境，任何变化都寸步难行，并且风险四伏。完整的体系架构管理实践应该涉及所有体系结构域：业务、服务、信息、技术和环境。可喜的是， ITIL 4 参考并融合了 SOA 框架和 TOGAF 企业架构方法论。
28 +
29 +* 持续改进（通用管理实践）
30 +* 项目管理（通用管理实践）
31 +* 架构管理（通用管理实践）
32 +* 流程类（合计 26 项）：
33 +
34 +流程在 ITIL 4 中的定义是“将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入并将其转换为已定义的输出。流程定义了操作的序列及其依赖项”。这与ITIL v3/2011 中定义的“用于实现特点目标的一系列有组织的活动，流程获得一个或多个定义的输入， 然后将它们变成定义的输出，流程可以包括任何角色、责任、工具和可靠提供输出所需的管理控制”。差距并不大。ITIL 4 强调的是“流程”是有序列的，并且有依赖项。在ITIL v3/2011 则强调的是“控制”， 将输入加工成所需要的输出。说句题外话，不少术语在 ITIL 4 和 ITIL v3/2011 中的定义都有了相当大的变化。一般而言，在ITIL 4 内术语均显得较为简洁，无太多描述性的词语，并且覆盖面会更广。
35 +
36 +根据定义，我们将通用管理实践中的 ITIL 前版本中所提及的知识管理、信息安全管理、关系管理等归入了流程类。服务管理实践内的大部分实践我们也归入了流程类。
37 +
38 +* 信息安全管理（通用管理实践）
39 +* 知识管理（通用管理实践）
40 +* 组织变革管理（通用管理实践）
41 +* 度量与报告（通用管理实践）
42 +* 服务组合管理（通用管理实践）
43 +* 关系管理（通用管理实践）
44 +* 风险管理（通用管理实践）
45 +* 服务财务管理（通用管理实践）
46 +* 战略管理（通用管理实践）
47 +* 服务设计（服务管理实践）
48 +* 供应商管理（通用管理实践）
49 +* 可用性管理（服务管理实践）
50 +* 业务分析（服务管理实践）
51 +* 容量与性能管理（服务管理实践）
52 +* 变更控制（服务管理实践）
53 +* 事件管理（服务管理实践）
54 +* IT 资产管理（服务管理实践）
55 +* 监控与事态管理（服务管理实践）
56 +* 问题管理（服务管理实践）
57 +* 发布管理（服务管理实践）
58 +* 服务目录管理（服务管理实践）
59 +* 服务配置管理（服务管理实践）
60 +* 服务连续性管理（服务管理实践）
61 +* 服务级别管理（服务管理实践）
62 +* 服务请求管理（服务管理实践）
63 +* 服务验证与测试（服务管理实践）
64 +
65 +== Q22：ITIL 4与敏捷开发之间的结合关系？ ==
66 +
67 +
68 +一听到“敏捷”，大部分 IT 从业人员，都会马上联想到“软件开发”，并回想起 2001 年发布的《敏捷宣言》。敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发过程中，软件项目的构建被切分成多个子项目——有点类似 PMBOK 中的“工作包”，各子项目成果均通过测试，具备集成和可运行的特性。简而言之，就是把一个大项目分为多个关联但可独立运行的小项目，并分别完成， 在此过程中软件一直处于可用状态。目前敏捷软件开发方法已被许多公司和软件团队采用，并且在许多情况下已被证明是有效的。
69 +
70 +
71 +|
72 +| |[[image:image-20200615180054-5.jpg]]
73 +
74 + 图4-9 敏捷开发路线图
75 +
76 +
77 +与敏捷开发相关的概念非常多，包括测试驱动开发、持续集成、重构、结对编程、每日站会、小版本发布、自动化测试。敏捷软件开发通常包括：
78 +
79 +* 通过反馈分析和直接观察收集不断变化的需求；
80 +* 将开发工作分成小的增量和迭代；
81 +* 建立基于产品的跨职能团队；
82 +* 直观地呈现（看板）并定期讨论（每日站会）工作进度；
83 +* 在每次迭代结束时向利益相关者展示一份（至少是最低可行性）软件——一般称为“MVP”， 最小化可行产品。
84 +
85 +而在 ITIL 4 的教材中通篇可见“敏捷”，从侧面反映出了 ITIL 4 的态度：应采用整体的服务价值链方法，以确保服务提供商在整个服务生命周期内都是敏捷的。敏捷性应成为所有服务管理维度和所有服务价值链活动的质量衡量标准之一。在 ITIL 4 的指导原则中“基于反馈的迭代推进”、“协作和提升可视化程度”、“保持简单实用”、“优化和自动化”都包含了“敏捷”的元素。
86 +
87 +敏捷开发与 ITIL 4 在组织内有相辅相成的共生之道。一方面，对于敏捷开发而言，成功的敏捷开发可以快速响应服务消费者不断变化的需求。但是，在许多组织中，敏捷开发的优势并未能得到良好的发挥。这通常是由于只在服务交付等少数阶段运用了“敏捷”，而在服务生命周期的其他阶段“脱敏”。这种孤立的敏捷性对组织的帮助不大，因为根据“木桶理论”——价值链的整体表现是由创造价值的最慢部分决定的。通过价值链的整体考虑方式，ITIL 为软件开发组织提供更广泛的视角和语言， 增强软件开发团队与别的服务团队的合作，也有助于提升敏捷开发在组织内的更好落地。另一方面，
88 +
89 +对于 ITIL 的前版本而言，ITIL 在服务转换阶段，在软件开发方面相对较弱，在端到端服务的过程中也相对较弱，必须要借助敏捷的思维，保持对客户和用户价值的关注，摆脱流程变得笨拙、沉重且高度集中的可能性。两者间的协同工作方式如：
90 +
91 +* 在服务交付阶段，引入持续交付，在同一个价值流图看整体的情况，统一安排工作项，分配统一的优先级，做到端到端的敏捷管理；
92 +* 变更和服务请求由专门的产品团队或以服务为中心的团队，以小迭代的方式处理，使产品或服务获得持续的反馈，且具有高可见性；
93 +* 日常运营活动可以而且应该与其他任务一起显示和进行优先排序。所有服务管理活动都可以而且应该不断提供、收集和处理反馈。
94 +
95 +综上所述，只有敏捷开发和服务管理一起以类似的节奏发展，说“同一种语言”，才可以确保组织继续与所有利益相关者共同创造价值。
96 +
97 +== Q23：ITIL指导原则是如何演变的？ ==
98 +
99 +
100 +AXELOS 在 2016 年发表了《ITIL 从业者指南》（ITIL Practitioner Guidance）。虽然 ITIL 的版本已经更迭，但指导原则历久弥新。
101 +
102 +《从业者指南》中提出 9 项指导原则：
103 +
104 +* 专注于价值
105 +* 为体验而设计
106 +* 从你所处的地方开始
107 +* 整体工作
108 +* 迭代地进步
109 +* 直接观察
110 +* 成为透明的
111 +* 协作
112 +* 保持简单
113 +
114 +这些现在已经在 ITIL 4 中被削减、改变、添加到现在的 7 项 ITIL 指导原则：
115 +
116 +* 聚焦
117 +* 从你所处的地方开始
118 +* 基于反馈的迭代推进
119 +* 协作和提升可视化程度
120 +* 通盘思考和工作
121 +* 保持简单实用
122 +* 优化和自动化
123 +
124 +通过对比，可以看出 ITIL 4 保留了大部分的指导原则，并进行了扩充。例如《从业者指南》中提到的“为体验而设计”，实际在 ITIL 4 中已经融入了“聚焦价值”“通盘思考和工作”当中，并将其列为 34 个实践之一——“服务设计”。“协作”“成为透明的”也变成了“协作和提升可视化程度”。实际上通过可视化的工具，让流程等透明起来，才能更好地进行团队内、团队间、团队与组织、组织间的协作。“保持简单”扩充为“保持简单实用”。ITIL 4 将指导原则也融入了 SVS 中，而不是简单将其列出后就束之高阁。“自动化”也位居“优化”之后，被合并添加为指导原则之一，这也是一个非常棒的考虑。只有通过对活动的尽量优化后，活动才能有效地自动化。ITIL 4 建议大量地在各个实践中使用自动化，通过寻找自动化的机会，帮助节省组织成本、减少人为错误并改善员工体验。我们“应充分利用各种资源，特别是人力资源，并消除任何真正浪费的东西，用科技去实现它所能做到的一切， 人类干预应该只发生在真正有价值的地方”。
125 +
126 +== Q24：ITIL 4和风险管理的关系？ ==
127 +
128 +
129 +关于风险管理，我们可以参考国际公认的权威——ISO31000:2018 风险管理指南。在 这个 版本中， 其提出了风险管理目的和原则的总体和一般视角。它们适用于任何类型的组织中的所有级别。有趣的是，该标准的上一版本也是发布于 2009 年，同样 9 年来第一次更新。ISO31000:2018 声明“风险管理的目的是创造和保护价值”，风险管理“提高绩效，鼓励创新并支持实现目标”。
130 +
131 +ISO31000:2018 有 8 项主题：
132 +
133 +1. 高管支持是基础；
134 +1. 在商业决策中考虑风险；
135 +1. 强调正确地履行；
136 +1. 风险管理不是放之四海而皆准的；
137 +1. 积极主动；
138 +1. 标准化词汇；
139 +1. 利用现有的最佳信息；
140 +1. 评价成功。
141 +
142 +与之对比，ITIL 4 中风险管理实践的目的是确保组织理解并有效地处理风险，从而确保组织的可持续性和为客户创造价值。风险中有威胁也有机会，与威胁有关时，通常被认为是可以避免的。而与机会相关时，不抓住机会本身就是一种风险。风险管理是所有组织活动的一个必然的组成部分，对组织的 SVS 至关重要。近期华为在应对美国一系列动作时，就表现出极高的风险管理水平，当然，还有极高的业务连续性管理水平。
143 +
144 +在 7 项指导原则中，和 ISO31000:2018 中 8 项主题有不少是能匹配的：
145 +
146 +* 聚焦价值以及基于反馈迭代推进，对应于评价成功。这里强调衡量、评估和改进风险管理实践的价值。这样做的目的不是第一次就把所有的事情都做好，而是在每次迭代完成时都要持续改进它。即使是不完美的风险数据也可能有用，只要它与显示趋势的时间表一起呈现。最终，风险报告能为管理人员提供高质量信息。
147 +* 通盘思考和工作，对应高管支持是基础，以及风险管理不是放之四海而皆准的。风险管理是一个循环过程，有足够的定制和改进空间，但其并非万能，管理者应该从整体去考虑，为自己的组织定制风险管理指南——特别是其风险概况、文化和风险偏好。风险管理实践必须全面管理，以实现整个组织的一致性。为确保有效性，应与利益相关方进行持续磋商，并为组织的不同部门提供适当的灵活性。这种灵活性将允许开发定制的风险管理程序，以便解决组织单位和 / 或客户特定情况。同时， 组织需要根据其愿意承担的风险偏好（即风险水平），对风险进行识别、评估、监控和管理。管理者还需要确保风险管理实践在组织的所有级别上得到充分集成，并与组织的目标结合在一起，让风险意识融入企业的运作方式中。
148 +* 从你所处的地方开始，对应利用现有的最佳信息。当前很多风险管理都集中在可用的最佳信息上，而忽视了风险中的模糊性和不完善之处。管理者不应只是试图分享绝对的风险信息，而应利用这些模糊点，对他们提供的数据进行反思，从而更好地发现问题。
149 +* 保持简单实用，对应标准化词汇。通过风险管理实践，提供一种公共语言，对风险、事件、后果和概率有简单和不复杂的定义。组织内均应采用这些术语，以确保交流不会产生分歧。
150 +* 优化和自动化，对应积极主动。对风险应该采取积极的立场，并确保将风险管理集成到组织各级决策的各个方面。这包括在业务连续性管理、业务分析、劳动力和人才管理、信息安全管理、问题管理等方面，都需要作出主动的优化，形成主动风险管理行为。
151 +
152 +回到管理实践中，我们试举几个和风险管理相关的例子：
153 +
154 +* 在信息安全管理中，首当其冲的就是对可能产生的风险进行识别，以确保组织所需的信息安全性。
155 +* 在问题管理实践中，问题管理活动可以为风险管理提供特定的案例，可识别、评估和控制服务管理的四个方面的风险，此时采用风险管理工具和技术进行问题管理往往很有效。
156 +* 在可用性管理中，某些组织会将导致可靠性降低的因素作为风险管理的一部分。
157 +* 在服务连续性中，需要彻底考虑影响服务连续性的因素，以及多个因素之间的关系，。假如不做风险评估，那么应急相关对应的场景就无法有效的识别，可能存在应急预案缺失的问题。
158 +* 在服务设计方面，风险管理嵌入到了所有设计过程和活动中，确保所提供的产品和服务所涉及的风险和组织的风险控制水平保持一致。
159 +* 在服务验证和测试方面，风险管理相关的条件也是服务验证的输入之一。
160 +
161 +== Q25：ITIL 4的价值流，能否以图形化的方式展现？ ==
162 +
163 +
164 +为了减少大家混淆流程活动和价值流活动，我们提出了如下的观点：流程活动中的“活动”是真正的动作，而价值流活动中的“活动”，主要负责价值的统计和呈现，并为进一步优化价值流提供了可能。价值流当中的“活动”可以理解为端到端的价值实现“步骤”，而价值流图可以认为是一个价值流动的看板工具。我们可以根据流程活动对价值流实现的不同阶段来将价值链划分为 6 大价值链活动，这些活动之间没有绝对的先后顺序之分，每个特定的价值流活动可以在各个价值链实现步骤间穿梭。因此我们将以泳道图的方式呈现基于 ITIL 4 的价值流图：将各个步骤设为泳道，流程的活动穿插于其中。
165 +
166 +为了执行某项任务或响应特定情况，组织创建服务价值流。这些是活动和实践的特定组合，每个活动和实践都是针对特定场景而设计的——受众不同、目的不同。价值流可以是线性的或者瀑布式或者非瀑布式的，可以是动态的或者敏捷的，反之亦可行。
167 +
168 +我们需要记住两个原则：一是价值链活动可以在价值流的过程中重复自己。而价值流是端到端的，以需求开始，以价值结束。任一价值流的目标都是将某一类特定的需求转换为价值。IT 组织通常缺乏这种“全局视野”，因为每个人的角色和流程都试图为客户做到最好，但可惜的是，每一个环节对于价值的理解可能都是片面的。只有当整个“价值流图”变得透明时，组织才能从全局的角度快速查看问题，并减少价值流中的浪费现象。
169 +
170 +我们将根据一个软件功能升级的场景来展现价值流图样例，详情见下：
171 +
172 +近期，由于总部颁布了一系列新的合规要求，部分 IT 服务系统无法满足，因此计划对这类 IT 服务系统进行升级。我们编制了该场景的价值流图如下：
173 +
174 +
175 +|
176 +| |[[image:image-20200615180117-8.png]]
177 +
178 + 图4-10 软件功能升级场景价值流图
179 +
180 +
181 +为了便于理解，这里，我们采用列表的方式将该价值流所经历的价值链活动以及对应的实践活动展示出来，帮助大家思考各个 ITIL 4 实践在服务价值链活动中的作用。
182 +
183 +
184 + 表4-5：软件功能升级场景价值流活动
185 +
186 +| |(% colspan="2" style="width:160px" %)价值链活动输入/输出|(% colspan="2" style="width:185px" %)(((
187 +
188 +
189 +ITIL实践
190 +)))|(% colspan="2" style="width:140px" %)(((
191 +
192 +
193 +实践角色
194 +)))|(% colspan="2" style="width:667px" %)(((
195 +
196 +
197 +实践活动
198 +)))
199 +| |(% colspan="2" style="width:160px" %)(((
200 +需求
201 +)))|(% colspan="2" style="width:185px" %) |(% colspan="2" style="width:140px" %)法务总监合规经理|(% colspan="2" style="width:667px" %)了解到不少IT服务系统需要升级来满足新的合规性要求。
202 +| |(% colspan="2" style="width:160px" %)(((
203 +
204 +
205 +契动
206 +)))|(% colspan="2" style="width:185px" %)(((
207 +
208 +
209 +关系管理
210 +)))|(% colspan="2" style="width:140px" %)(((
211 +
212 +
213 +法务总监合规经理CIO
214 +)))|(% colspan="2" style="width:667px" %)(((
215 +
216 +
217 +讨论新的监管要求，并商定将创建一个项目来管理实施工作。
218 +)))
219 +| |(% colspan="2" style="width:160px" %)(((
220 +
221 +
222 +获取/构建
223 +)))|(% colspan="2" style="width:185px" %)(((
224 +
225 +
226 +软件开发和管理、服务验证和测试 服务设计
227 +)))|(% colspan="2" style="width:140px" %)(((
228 +
229 +
230 +软件开发团队
231 +)))|(% colspan="2" style="width:667px" %)(((
232 +
233 +
234 +每个软件团队管理一个待办事项并为他们分配部分开发代码。每个团队还通过自动化流水线进行开发测试。所有代码每天都自动集成和测试两次，确保不同团队编写的代码能协同工作。
235 +)))
236 +| |(% colspan="2" style="width:160px" %)(((
237 +
238 +
239 +设计和转换契动
240 +)))|(% colspan="2" style="width:185px" %)(((
241 +
242 +
243 +项目管理
244 +
245 +服务验证和测试服务设计
246 +)))|(% colspan="2" style="width:140px" %)(((
247 +项目经理  
248 +
249 +IT开发经理
250 +
251 +软件开发团队
252 +
253 +合规经理
254 +)))|(% colspan="2" style="width:667px" %)(((
255 +
256 +
257 +讨论并商定了发布和部署计划。在部署开始之前，批准了需要测试的级别以及发放授权给每个部署的人员。
258 +)))
259 +| |(% colspan="2" style="width:160px" %)(((
260 +获取/构建设计和转换
261 +)))|(% colspan="2" style="width:185px" %)(((
262 +服务设计
263 +
264 +组织变更管理部署管理
265 +
266 +服务配置管理
267 +)))|(% colspan="2" style="width:140px" %)(((
268 +
269 +
270 +软件开发团队
271 +)))|(% colspan="2" style="width:667px" %)(((
272 +
273 +
274 +新软件的部署工作一旦准备就绪，就会立即启动。对此不再需要变更批准，因为风险评估已提前完成，自动化确保了代码的部署完全按照计划进行。配置数据用于驱动部署，因此不需要单独的活动来更新。
275 +)))
276 +|(% colspan="2" %)(((
277 +
278 +
279 +契动
280 +
281 +设计和转换
282 +)))|(% colspan="2" style="width:167px" %)(((
283 +
284 +
285 +项目管理发布管理服务台
286 +
287 +服务目录管理
288 +)))|(% colspan="2" style="width:202px" %)(((
289 +
290 +
291 +项目经理
292 +
293 +软件开发团队产品经理
294 +
295 +服务目录经理
296 +)))|(% colspan="2" style="width:406px" %)(((
297 +
298 +
299 +新功能通过功能开关来发布的，该开关允许用户可以看到新功能。服务台和其他同事得到通知，新功能已经可以使用。同时服务目录已被更新。
300 +)))|
301 +|(% colspan="2" %)(((
302 +
303 +
304 +价值改进
305 +)))|(% colspan="2" style="width:167px" %)(((
306 +
307 +
308 +项目管理服务设计关系管理持续改进
309 +)))|(% colspan="2" style="width:202px" %)(((
310 +
311 +
312 +项目经理开发经理法务总监CIO
313 +
314 +合规经理
315 +)))|(% colspan="2" style="width:406px" %)(((
316 +
317 +
318 +对该项目进行了审查和关闭。寻找改进机会并将其添加到持续改进登记册中。
319 +)))|
320 +|(% colspan="2" %)(((
321 +
322 +
323 +价值
324 +)))|(% colspan="2" style="width:167px" %) |(% colspan="2" style="width:202px" %)(((
325 +项目经理CIO
326 +
327 +法务总监
328 +
329 +合规经理
330 +)))|(% colspan="2" style="width:406px" %)(((
331 +
332 +
333 +更新的服务符合新合规要求。
334 +)))|
335 +
336 +通过价值流的形式构建组织 IT 服务价值交付的价值链活动，使组织能够清楚地了解其提供的服务内容和方式，可视化了解价值的创造过程，不断发现价值增长过程中的瓶颈和浪费，不断改进服务。这是 ITIL 4 中所提倡的。因此识别和理解组织的各种价值流，对于提高组织整体绩效至关重要。设计完成后，价值流应该不断改进。价值流优化可能包括流程自动化或新兴技术的采用以及提高效率或增强用户体验的工作方式。上述的价值流图还可以进一步被深化应用，例如基于某一个工作周期的总绩效，以量化的方式通过价值链看板实时动态呈现。又例如可以在各个价值链活动阶段进行价值统计， 让客户对实时获得的价值一目了然，增加对 IT 服务提供方所创造的价值的认同；也让 IT 服务内部团队看清自身所创造的价值，针对瓶颈和浪费，进行持续改进。这些都将是有益的尝试。
337 +
338 +值得一提的是，如果我们可以根据客户预期的价值，甚至在契动阶段就将客户引入，去制定共同的视图，则价值流图可以更全局化和端到端，使得服务提供方和服务消费方的联合价值共创更高效、更敏捷。
339 +
7 7  == Q26：ITIL 4和DevOps的关系？ ==
8 8  
9 9  
深圳市艾拓先锋企业管理咨询有限公司