Wiki source code of Q25:ITIL 4的价值流,能否以图形化的方式展现?
Version 1.1 by superadmin on 2020/06/17, 17:26
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | |||
2 | |||
3 | 为了减少大家混淆流程活动和价值流活动,我们提出了如下的观点:流程活动中的“活动”是真正的动作,而价值流活动中的“活动”,主要负责价值的统计和呈现,并为进一步优化价值流提供了可能。价值流当中的“活动”可以理解为端到端的价值实现“步骤”,而价值流图可以认为是一个价值流动的看板工具。我们可以根据流程活动对价值流实现的不同阶段来将价值链划分为 6 大价值链活动,这些活动之间没有绝对的先后顺序之分,每个特定的价值流活动可以在各个价值链实现步骤间穿梭。因此我们将以泳道图的方式呈现基于 ITIL 4 的价值流图:将各个步骤设为泳道,流程的活动穿插于其中。 | ||
4 | |||
5 | |||
6 | 为了执行某项任务或响应特定情况,组织创建服务价值流。这些是活动和实践的特定组合,每个活动和实践都是针对特定场景而设计的——受众不同、目的不同。价值流可以是线性的或者瀑布式或者非瀑布式的,可以是动态的或者敏捷的,反之亦可行。 | ||
7 | |||
8 | |||
9 | 我们需要记住两个原则:一是价值链活动可以在价值流的过程中重复自己。而价值流是端到端的,以需求开始,以价值结束。任一价值流的目标都是将某一类特定的需求转换为价值。IT 组织通常缺乏这种“全局视野”,因为每个人的角色和流程都试图为客户做到最好,但可惜的是,每一个环节对于价值的理解可能都是片面的。只有当整个“价值流图”变得透明时,组织才能从全局的角度快速查看问题,并减少价值流中的浪费现象。 | ||
10 | |||
11 | 我们将根据一个软件功能升级的场景来展现价值流图样例,详情见下: | ||
12 | |||
13 | |||
14 | 近期,由于总部颁布了一系列新的合规要求,部分 IT 服务系统无法满足,因此计划对这类 IT 服务系统进行升级。我们编制了该场景的价值流图如下: | ||
15 | |||
16 | | | ||
17 | | |[[image:http://itil4hub.cn/bin/download/D%20%E3%80%8AITIL%204%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E8%AE%A4%E8%AF%81%E8%80%83%E8%AF%95%E6%8C%87%E5%8D%97%E3%80%8B/%E7%AC%AC%E5%9B%9B%E7%AB%A0%20ITIL%204%E5%AD%A6%E4%B9%A0%E4%B8%8E%E5%AE%9E%E8%B7%B5FAQ/WebHome/image-20200615180117-8.png?rev=1.1||alt="image-20200615180117-8.png"]] | ||
18 | |||
19 | 图4-10 软件功能升级场景价值流图 | ||
20 | |||
21 | |||
22 | 为了便于理解,这里,我们采用列表的方式将该价值流所经历的价值链活动以及对应的实践活动展示出来,帮助大家思考各个 ITIL 4 实践在服务价值链活动中的作用。 | ||
23 | |||
24 | 表4-5:软件功能升级场景价值流活动 | ||
25 | |||
26 | | |(% colspan="2" %)价值链活动输入/输出|(% colspan="2" %)((( | ||
27 | |||
28 | |||
29 | ITIL实践 | ||
30 | )))|(% colspan="2" %)((( | ||
31 | |||
32 | |||
33 | 实践角色 | ||
34 | )))|(% colspan="2" %)((( | ||
35 | |||
36 | |||
37 | 实践活动 | ||
38 | ))) | ||
39 | | |(% colspan="2" %)((( | ||
40 | 需求 | ||
41 | )))|(% colspan="2" %) |(% colspan="2" %)法务总监合规经理|(% colspan="2" %)了解到不少IT服务系统需要升级来满足新的合规性要求。 | ||
42 | | |(% colspan="2" %)((( | ||
43 | |||
44 | |||
45 | 契动 | ||
46 | )))|(% colspan="2" %)((( | ||
47 | |||
48 | |||
49 | 关系管理 | ||
50 | )))|(% colspan="2" %)((( | ||
51 | |||
52 | |||
53 | 法务总监合规经理CIO | ||
54 | )))|(% colspan="2" %)((( | ||
55 | |||
56 | |||
57 | 讨论新的监管要求,并商定将创建一个项目来管理实施工作。 | ||
58 | ))) | ||
59 | | |(% colspan="2" %)((( | ||
60 | |||
61 | |||
62 | 获取/构建 | ||
63 | )))|(% colspan="2" %)((( | ||
64 | |||
65 | |||
66 | 软件开发和管理、服务验证和测试 服务设计 | ||
67 | )))|(% colspan="2" %)((( | ||
68 | |||
69 | |||
70 | 软件开发团队 | ||
71 | )))|(% colspan="2" %)((( | ||
72 | |||
73 | |||
74 | 每个软件团队管理一个待办事项并为他们分配部分开发代码。每个团队还通过自动化流水线进行开发测试。所有代码每天都自动集成和测试两次,确保不同团队编写的代码能协同工作。 | ||
75 | ))) | ||
76 | | |(% colspan="2" %)((( | ||
77 | |||
78 | |||
79 | 设计和转换契动 | ||
80 | )))|(% colspan="2" %)((( | ||
81 | |||
82 | |||
83 | 项目管理 | ||
84 | |||
85 | 服务验证和测试服务设计 | ||
86 | )))|(% colspan="2" %)((( | ||
87 | 项目经理 | ||
88 | |||
89 | IT开发经理 | ||
90 | |||
91 | 软件开发团队 | ||
92 | |||
93 | 合规经理 | ||
94 | )))|(% colspan="2" %)((( | ||
95 | |||
96 | |||
97 | 讨论并商定了发布和部署计划。在部署开始之前,批准了需要测试的级别以及发放授权给每个部署的人员。 | ||
98 | ))) | ||
99 | | |(% colspan="2" %)((( | ||
100 | 获取/构建设计和转换 | ||
101 | )))|(% colspan="2" %)((( | ||
102 | 服务设计 | ||
103 | |||
104 | 组织变更管理部署管理 | ||
105 | |||
106 | 服务配置管理 | ||
107 | )))|(% colspan="2" %)((( | ||
108 | |||
109 | |||
110 | 软件开发团队 | ||
111 | )))|(% colspan="2" %)((( | ||
112 | |||
113 | |||
114 | 新软件的部署工作一旦准备就绪,就会立即启动。对此不再需要变更批准,因为风险评估已提前完成,自动化确保了代码的部署完全按照计划进行。配置数据用于驱动部署,因此不需要单独的活动来更新。 | ||
115 | ))) | ||
116 | |(% colspan="2" %)((( | ||
117 | |||
118 | |||
119 | 契动 | ||
120 | |||
121 | 设计和转换 | ||
122 | )))|(% colspan="2" %)((( | ||
123 | |||
124 | |||
125 | 项目管理发布管理服务台 | ||
126 | |||
127 | 服务目录管理 | ||
128 | )))|(% colspan="2" %)((( | ||
129 | |||
130 | |||
131 | 项目经理 | ||
132 | |||
133 | 软件开发团队产品经理 | ||
134 | |||
135 | 服务目录经理 | ||
136 | )))|(% colspan="2" %)((( | ||
137 | |||
138 | |||
139 | 新功能通过功能开关来发布的,该开关允许用户可以看到新功能。服务台和其他同事得到通知,新功能已经可以使用。同时服务目录已被更新。 | ||
140 | )))| | ||
141 | |(% colspan="2" %)((( | ||
142 | |||
143 | |||
144 | 价值改进 | ||
145 | )))|(% colspan="2" %)((( | ||
146 | |||
147 | |||
148 | 项目管理服务设计关系管理持续改进 | ||
149 | )))|(% colspan="2" %)((( | ||
150 | |||
151 | |||
152 | 项目经理开发经理法务总监CIO | ||
153 | |||
154 | 合规经理 | ||
155 | )))|(% colspan="2" %)((( | ||
156 | |||
157 | |||
158 | 对该项目进行了审查和关闭。寻找改进机会并将其添加到持续改进登记册中。 | ||
159 | )))| | ||
160 | |(% colspan="2" %)((( | ||
161 | |||
162 | |||
163 | 价值 | ||
164 | )))|(% colspan="2" %) |(% colspan="2" %)((( | ||
165 | 项目经理CIO | ||
166 | |||
167 | 法务总监 | ||
168 | |||
169 | 合规经理 | ||
170 | )))|(% colspan="2" %)((( | ||
171 | |||
172 | |||
173 | 更新的服务符合新合规要求。 | ||
174 | )))| | ||
175 | |||
176 | |||
177 | 通过价值流的形式构建组织 IT 服务价值交付的价值链活动,使组织能够清楚地了解其提供的服务内容和方式,可视化了解价值的创造过程,不断发现价值增长过程中的瓶颈和浪费,不断改进服务。这是 ITIL 4 中所提倡的。因此识别和理解组织的各种价值流,对于提高组织整体绩效至关重要。设计完成后,价值流应该不断改进。价值流优化可能包括流程自动化或新兴技术的采用以及提高效率或增强用户体验的工作方式。上述的价值流图还可以进一步被深化应用,例如基于某一个工作周期的总绩效,以量化的方式通过价值链看板实时动态呈现。又例如可以在各个价值链活动阶段进行价值统计, 让客户对实时获得的价值一目了然,增加对 IT 服务提供方所创造的价值的认同;也让 IT 服务内部团队看清自身所创造的价值,针对瓶颈和浪费,进行持续改进。这些都将是有益的尝试。 | ||
178 | |||
179 | 值得一提的是,如果我们可以根据客户预期的价值,甚至在契动阶段就将客户引入,去制定共同的视图,则价值流图可以更全局化和端到端,使得服务提供方和服务消费方的联合价值共创更高效、更敏捷。 |