Wiki源代码2. 高速IT的关键概念
由 superadmin 于 2024/04/03, 17:07 最后修改
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | |||
2 | |||
3 | |||
4 | [[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%AB%98%E9%80%9FIT%E3%80%8BHVIT/3.%E9%AB%98%E9%80%9FIT%E6%96%87%E5%8C%96/]] [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%AB%98%E9%80%9FIT%E3%80%8BHVIT/1.%E4%BB%8B%E7%BB%8D/]] | ||
5 | |||
6 | {{box cssClass="floatinginfobox" title="**Contents**"}} | ||
7 | {{toc/}} | ||
8 | {{/box}} | ||
9 | |||
10 | = **2. 高速IT的关键概念** = | ||
11 | |||
12 | |||
13 | 本章介绍了与高速IT(HVIT)相关的一些关键概念。它探讨了数字化组织的性质,以及需要一种截然不同的工作方式, 并说明了如何将ITIL指南的核心概念用作构建和组织HVIT工作的基础。 | ||
14 | |||
15 | 本章定义了几个关键概念,包括: | ||
16 | |||
17 | * 高速IT | ||
18 | * 数字化技术 | ||
19 | * 数字化组织 | ||
20 | * 数字化转型 | ||
21 | * 高速IT目标和关键特征 | ||
22 | |||
23 | == 2.1 高速IT == | ||
24 | |||
25 | |||
26 | **定义:高速IT** | ||
27 | |||
28 | 数字化技术在实现重要业务上有着重大应用,因此上市时间、客户时间、变更时间和速度通常至关重要。高速IT不仅限于快速研发,从开始的创新到开发和运营,再到实际价值的实现,整个服务价值链都需要它。 | ||
29 | |||
30 | |||
31 | 就像某些数字化组织比其他组织更数字一样,某些组织的速度也要比其他组织高。但是,速度较高的组织并不一定更好。在某些情况下,较低的速度可能更有利。也没有必要甚至不建议组织的整个IT都是高速的。例如,可以通过HVIT工作方式来管理更具动态性的面向客户的系统,而以传统方式更好地处理后台传统系统。 | ||
32 | |||
33 | 高速不以解决方案的功用或功效为代价,并且高速通常等同于高性能。组织内部不断提高速度始终会带来成本和风险,尤其是在发生急剧变化而不是逐步改进的情况下。在某些情况下,通过有意识地冒险来获得或保持竞争优势。由于缺乏对背景的理解,并且在信息未达到决策水平之前就淡化了告警,常常会无意识地承担进一步的风险。当决策者受到不平衡的激励和目标的影响时,也可能会冒风险。例如,当做出的决策更有可能帮助实现短期目标而不是更具可持续性的目标时。 | ||
34 | |||
35 | 从科学上讲,速度也具有方向性。在HVIT中,这被解释为做正确的事。换句话说,不仅应满足高速方法的要求,而且还应就投资和可持续性做出正确的决定。 | ||
36 | |||
37 | HVIT为许多组织提供了更高程度的数字实现,但这并不总是一种谨慎的投资。对于某些组织来说,进行这样的转换是没有意义的,因为它们还有其它更重要的事情要做。其他人可能选择不尝试提高速度,因为他们认为涉及的文化变革太难实现,或者不太可能产成可接受的投资回报。 | ||
38 | |||
39 | |||
40 | |||
41 | **ITIL的故事:高速IT** | ||
42 | |||
43 | Henri:Axle的愿景是成为世界上最受认可的环保汽车租赁公司。这意味着我们在追求业务目标会采用新的绿色技术。根据ITIL指导原则采用和使用这些技术向董事会表明,明智的投资于正确的技术,正确的部署,是发展公司的有效途径。 | ||
44 | |||
45 | Marco::现代技术发展的步伐意味着工具和解决方案可能很快就会过时。五年前的最佳技术不一定是今天优化我们服务的最佳方式。我们的工具需要持续评审,并迅速的开发和部署任何必要的更新,以确保它们仍然有效。 | ||
46 | |||
47 | Radhika:我们的研究表明我们的网站已经过时。例如,它没有针对最新的智能手机进行优化。我们的竞争对手的平台可以更快速地量身定制,以应对日益依赖设备而不是计算机的业务市场需求。我们需要改进我们的平台,否则我们的客户将找到一种更轻松的方式预订他们的旅行。 | ||
48 | |||
49 | Solmaz:我们正在与采用技术并以新颖有趣的方式解决不断变化的客户需求的业务转换模型竞争。作为回应,Axle要求我们的几个分支机构尝试创新的业务模型。作为业务转换经理,我负责确保业务具有适应变化的敏捷性。 | ||
50 | |||
51 | |||
52 | |||
53 | == 2.2 数字化技术 == | ||
54 | |||
55 | |||
56 | **定义** | ||
57 | |||
58 | **数字化技术**是指将事物数字化或处理数字数据的技术。数字化技术是指信息技术(IT)和运营技术(OT)中已被数字化的的部分。 | ||
59 | |||
60 | **数字化**通过以二进制数字表示信息,将某些东西(例如文本,声音或图像)从模拟形式转换为数字形式的过程。 | ||
61 | |||
62 | (% style="text-align:center" %) | ||
63 | [[image:1639230762866-536.png]] | ||
64 | |||
65 | 图2.1 数字化技术 | ||
66 | |||
67 | 数字化技术由IT和OT组成。IT为用户提供数据和信息,而OT则检测或引起物理设备的变化(见图2.1)。 | ||
68 | |||
69 | |||
70 | |||
71 | === === | ||
72 | |||
73 | === 2.2.1 信息技术 === | ||
74 | |||
75 | |||
76 | IT作为信息系统而存在,由硬件、系统软件、数据和用于数据处理的应用程序组成。图2.2更详细地说明展示了信息系统技术堆栈。 | ||
77 | |||
78 | 信息是在特定的背景中有用的数据。在IT中,使信息可供最终用户可用是最终目标。这可以以数字或文本的形式显示在屏幕上,也可以以及其他的方式呈现,例如在地图上移动的位置。 | ||
79 | |||
80 | |||
81 | (% style="text-align:center" %) | ||
82 | [[image:1639230805549-636.png]] | ||
83 | |||
84 | 图2.2 信息系统技术栈 | ||
85 | |||
86 | |||
87 | **定义:信息技术** | ||
88 | |||
89 | 数字化技术的应用,用于存储、检索、传输和操作数据(数据处理),通常在业务或其他组织的背景中。传统观念上,IT的价值被认为是提升效率,因为它带来了自动化的信息系统,即系统并比人类更快,更可靠地以更低的成本处理和提供数据。人工智能(例如机器学习)越来越多地将IT应用于处理和提供数据,以及创建新的信息。 | ||
90 | |||
91 | 组织主要使用从传统的、自动化信息系统收集的信息进行内部决策。这样,它们有助于减少不确定性,而不确定性是信息的主要功能。信息价值只有在决策被采纳并据此做出改进的情况下才能实现。这样,通常只有在决策考虑到信息系统提供的信息后,才能真正实现IT投资的回报。如果不采取任何措施,则不会创建价值。在某些情况下,可以是不采取任何措施,例如,为了避免一个已确定的风险。 | ||
92 | |||
93 | 图2.3展示了IT堆栈如何通过明智的决策为价值创造做出贡献。 | ||
94 | |||
95 | |||
96 | (% style="text-align:center" %) | ||
97 | [[image:1639230838187-982.png]] | ||
98 | |||
99 | 图2.3 IT价值栈 | ||
100 | |||
101 | |||
102 | 尽管IT是全球组织的核心概念,但该术语经常被误解。“ IT”可指代以下任何一项: | ||
103 | |||
104 | * 组织IT职能(IT部门);本出版物将其称为“ IT职能” | ||
105 | * IT基础设施,包括通用的工作生产力应用程序(例如文字处理),但不包括支持特定业务功能的应用程序 | ||
106 | * 组织的内部信息系统 | ||
107 | * 用于创建“ 数字化产品”的技术组件 | ||
108 | * 数据处理技术(用于存储,检索,传输和处理数据) | ||
109 | |||
110 | 用于处理数据以使业务数字化和自动化的数字化技术。本出版物使用术语“ IT”指代数字化技术在数字化和自动化业务方面的数据应用。 | ||
111 | |||
112 | |||
113 | |||
114 | === 2.2.2 运营技术 === | ||
115 | |||
116 | |||
117 | **定义:运营技术** | ||
118 | |||
119 | 通过监控或控制检测或引起物理设备变更的数字化技术应用。 | ||
120 | |||
121 | |||
122 | 运营技术(OT)与IT的不同之处在于它使用数字数据作为实现物理目标的内部手段,而不是向用户提供信息。 | ||
123 | |||
124 | “ OT”是指采用数字数据进行物理操作的物理设备(例如,机械中的阀门和泵)。OT设备可以小到汽车的发动机控制模块(ECM),也可以大到国家电网的分布式控制网络。 | ||
125 | |||
126 | “工业控制系统”(ICS)的统称是指OT系统,例如监督控制和数据采集(SCADA)系统,分布式控制系统(DCS),远程终端单元(RTU)和可编程逻辑控制器(PLC),以及专用网络和组织单元。OT领域还包括嵌入式系统(例如智能仪器)和大量的科学数据采集,控制和计算设备。 | ||
127 | |||
128 | 物联网(IoT)支持OT设备,从而使它们既可以相互连接又可以与信息系统连接。 | ||
129 | |||
130 | |||
131 | **ITIL的故事:数字化技术** | ||
132 | |||
133 | Henri: Axle汽车租赁在机械或运营技术与信息技术集成方面处于领先地位。我们的汽车是数字平台的延申;它们是我们进入物联网的切入点。由我们的汽车中的传感器和GPS装置收集的信息被存储和共享,因此我们可以优化和自动化我们的服务。 | ||
134 | |||
135 | |||
136 | |||
137 | |||
138 | == == | ||
139 | |||
140 | == 2.3 数字化组织 == | ||
141 | |||
142 | |||
143 | 数字化组织通过数字化技术实现。数字化技术是促进组织内部流程的重要基础,并且通常是组织产品和服务的一部分。因此,数字化技术是数字化组织业务模型的战略部分,并应用于其主要(而非支持)活动。因此,优先考虑数字化技术(“ 数字优先”)通常是组织的文化的一部分(换句话说,在组织中做事的方式)。 | ||
144 | |||
145 | |||
146 | **定义:数字化组织** | ||
147 | |||
148 | 组织实现数字化技术,开展截然不同的业务。 | ||
149 | |||
150 | |||
151 | “数字”确切含义通常在组织之间会有所不同,但通常会反映在组织提供的客户体验,产品或服务,业务模型,运营模式以及员工体验上。在数字化组织中,这些将主要由数字化技术实现。 | ||
152 | |||
153 | 大多数组织都在某种程度上利用了数字化技术,从某种意义上讲,它们也是数字化的。但是,在实践中,如果组织对数字化技术进行差异化的战略性使用,则被视为“ 数字化”。例如,一家传统的出租车公司依靠数字化技术来运营。但是对于依赖于应用程序进行预订的出租车公司而言,数字化技术具有战略意义,并且是其业务模式的关键部分。 | ||
154 | |||
155 | 尽管组织的数字化通常会在其产品和服务中体现出来,但仅内部实践的数字化也可能足以将其定义为“ 数字化”,只要这能带来明显的好处。数字化组织不是完全一致地数字化,通常某些部分将比其他部分更数字化。在这些情况下,这种多样性将代表一项挑战,必须谨慎应对,以确保不同领域可以有效地协同工作。 | ||
156 | |||
157 | 部分高度数字化的组织对负责数字实现的人员提出了特定要求。这些需求取决于数字实现的程度,但通常高于支持活动的信息系统的需求。对于数字化产品和客户体验,需要创新的数字投资来建立或保持竞争优势,并且必须迅速实现。最终的数字化产品,服务和客户渠道必须在运营上具有弹性,并且它们的用户必须很好地使用它们才能获得预期的投资回报。 | ||
158 | |||
159 | 组织的数字化对其运营模式(换句话说,它需要的资源以及它们如何交互)具有重要意义。组织运营模型的主要考虑因素是IT功能的集中或分散,以及每个选项如何影响组织的有效性和效率。数字化组织的运营模式是基于服务提供者和服务消费者共同创造的价值,以确保数字投资的价值得到正确体现。 | ||
160 | |||
161 | 无论好坏,它对社会、政治和经济影响都是前所未有的。因此,数字化驱动组织承担着越来越高的道德义务,其中IT部门应赋予业务权力,而不仅仅是对其提供支持,以考虑他们如何将数字化技术应用到其直接的经济利益之外。 | ||
162 | |||
163 | |||
164 | **ITIL的故事:数字化组织** | ||
165 | |||
166 | Henri: 我们的业务具有数字功能,但并不总是数字集成的。例如,某些分支机构在亲自或通过电话预订方面的数字化滞后了。 | ||
167 | |||
168 | Radhika:我们已经看到了全自动租车服务的出现,其中每个接触点和服务交互都发生在用户友好、可定制的应用程序中,并且客户甚至可以在没有任何人干预的情况下定位和解锁汽车。 | ||
169 | |||
170 | Solmaz:某些客户更喜欢这种方式,尤其是当他们在不说当地语言的国家/地区时。我们需要跟上需求的发展,以便为客户提供最好的体验。 | ||
171 | |||
172 | |||
173 | == == | ||
174 | |||
175 | == 2.4 数字化转型 == | ||
176 | |||
177 | |||
178 | 转型就是做事情不同,或者做不同的事情。它涉及到重新设计工作,以使不同的方式思考事物,或者思考不同的事物。 | ||
179 | |||
180 | “ 数字化转型”通常用于表现在数字化,自动化和其他自动化形式上的重大投资,这些投资使组织能够以截然不同的方式来做业务,或去做显著不同的业务。这种技术变革通常要求组织改变其组织中如何使用数字解决方案的方式。 | ||
181 | |||
182 | |||
183 | **定义:数字化转型** | ||
184 | |||
185 | **指利用数字化技术在实现组织的目标方面取得重大进展,而这些目标是不可能通过非数字手段实现。** | ||
186 | |||
187 | 术语“ 数字化转型”并不特定于特定类型的转换,可以用来指代数字化应用的任何转换。转换后的实体通常是组织的客户体验、产品或服务、业务模型,运营模式(例如价值流)和员工体验的组合。 | ||
188 | |||
189 | |||
190 | **数字化与数字化转型(**Digitalization vs digitization) | ||
191 | |||
192 | 数字化转型有时被称为digitalization,但是,不建议使用此术语,因为它可能与digitization相混淆,digitalization这是将某些东西从模拟形式转换为数字化形式的技术流程。 | ||
193 | |||
194 | 正确使用的术语“转换”意味着重大的变更。尽管如此,转型并不一定意味着单个的、大的变化。基于组织选择的方法,转型可以通过一些大的变更或进行许多小的变更就可以成功实现。在许多情况下,一系列较小的变更甚至可能是更成功的方法。 | ||
195 | |||
196 | |||
197 | |||
198 | === 2.4.1 IT转型 === | ||
199 | |||
200 | |||
201 | 在将业务和IT视为独立组织职能的组织中, “IT转型”通常用于表示可改进IT服务提供方式的重大变化。IT转型的重点是如何开发、运行和支持IT服务和信息系统。这可以包括分散IT职能的权限并将其集成到数字业务线中。 | ||
202 | |||
203 | 在组织数字化转型之前,必须与内部或外部IT服务提供商分开管理组织。IT服务提供商专注于创建和交付IT产品和服务的IT资源管理,而服务消费者专注于其产品、服务和资源,包括由IT服务提供商交付或支持的产品、服务和资源的管理。作为服务消费者,该组织可能会影响服务提供商的管理。如图2.4中的模型1所示。 | ||
204 | |||
205 | |||
206 | (% style="text-align:center" %) | ||
207 | [[image:1639230976652-304.png]] | ||
208 | |||
209 | 图2.4 数字化转型和IT转型 | ||
210 | |||
211 | |||
212 | IT服务提供商和服务消费者都可以转换其管理、资源、产品和服务。这些转换可以是相互关联的,但是它们不会显著改变这些组织的协作方式或IT在服务消费者组织中的角色。如图2.4中的模型2所示。 | ||
213 | |||
214 | 当组织进行数字转换时,数字化技术在服务消费者的业务中的作用将会发生重大变化。这包括以下部分或全部: | ||
215 | |||
216 | * 组织产品和服务的数字化 | ||
217 | * 组织的管理实践的数字化 | ||
218 | * 组织资源的重要部分的数字化 | ||
219 | * 将IT管理与业务管理的融合; 与IT服务提供商建立伙伴关系或共同管理实践。 | ||
220 | |||
221 | 该数字转换如图2.4中的模型3所示。 | ||
222 | |||
223 | 如果业务和IT不像大多数数字化组织一样被视为独立的组织职能,那么“ IT转型”不是一个合适的术语,取而代之的是“ 数字化转型”。 | ||
224 | |||
225 | 本书出版物中描述的许多方法和技术都是面向软件的,与IT运维从业者似乎不太紧密。但是,随着物理平台转向诸如云,虚拟化,容器化和无服务器基础架构之类的代码驱动技术,这些从业人员必须具备胜任应用软件工程技术的能力。从业人员越来越多地使用脚本,代码和版本控制系统,例如GitHub来进行和管理变更,而不是手动实施。因此,对于HVIT环境中的从业人员而言,采用软件工程方法至关重要。 | ||
226 | |||
227 | 数字化产品和服务基于软件,这是IT运维从业人员投资于更多软件工程知识的另一个原因。软件是业务的主要关注点,例如,许多银行都将自己视为具有银行牌照的软件公司。重要性日益提高,导致外包策略发生了转变,其中应用程序开发和管理通常作为使用数字化技术的产品/ 服务线或业务线的组成部分而执行。这说明了在图2.5中: | ||
228 | |||
229 | * 在分散的IT职能中,每个业务部门都具有集成的IT职能并管理其IT服务。 | ||
230 | * 作为集中式服务提供商的IT部门为多个业务部门提供服务,并自己管理大多数IT服务。 | ||
231 | * 作为集中式服务集成商的IT部门为多个业务部门提供服务,并将其自身的IT服务与从外部服务提供商获得的IT服务相结合。 | ||
232 | * 当IT与业务部门集成在一起时,它们将专注于数字化业务服务的管理。 | ||
233 | |||
234 | 在这种分散的IT功能中工作的从业人员(IT功能是业务线的组成部分)比在专门的单元中工作的从业人员拥有更多领域的知识和能力。这些领域包括软件工程和业务本身的产品线。这些从业人员不再使用向其他部门提供服务的概念:相反,他们与同事一起为外部客户提供服务。 | ||
235 | |||
236 | |||
237 | (% style="text-align:center" %) | ||
238 | [[image:1639231006933-763.png]] | ||
239 | |||
240 | 图2.5 采购IT功能选项的示例 | ||
241 | |||
242 | |||
243 | |||
244 | **ITIL的故事:数字化转型** | ||
245 | |||
246 | Henri:我们在Axle汽车租赁中的目标是根据客户不断变化的需求推出新服务,并继续整合技术以改进我们的服务。当我们适应环境问题、优化客户旅程、增加服务定制并更新我们的服务时,我们确保我们正在反映当前的消费者趋势。 | ||
247 | |||
248 | Marco:我们最近将我们的服务从本地基础架构过渡到了混合云解决方案。这是我们IT团队的一项重大改革。我们必须更新脚本、代码和版本控制系统。现在,我们可以为内部客户提供更好的跨部门功能,而我们的业务团队也不再孤军奋战。 | ||
249 | |||
250 | Solmaz:我们的向混合云解决方案的转变并不是一个重大变更。为了达到最佳的变更控制目的,我们确保可以进行一系列较小的,有针对性的变更,这些变更可以在部署之前进行充分测试,并且可以不断进行审查和修订。 | ||
251 | |||
252 | |||
253 | |||
254 | |||
255 | == 2.5 高速IT目标和关键特征 == | ||
256 | |||
257 | |||
258 | === 2.5.1 高速IT目标 === | ||
259 | |||
260 | |||
261 | 技术对数字化组织的业务模型具有战略意义,因此,对其数字化产品的生命周期提出了更高的要求。 这些要求可以由五个高级目标来表示,这些目标将组织的愿景和战略转化为更多的运营目标和指标。 这些目标是: | ||
262 | |||
263 | * 有价值的投资 | ||
264 | * 快速研发 | ||
265 | * 弹性运营 | ||
266 | * 价值共创 | ||
267 | * 保证合规 | ||
268 | |||
269 | 重要的是要记住,这些目标不应孤立地管理。它们彼此影响并彼此交互,因此需要集中管理。它们在表2.1中概述。 | ||
270 | |||
271 | 表2.1 HVIT目标 | ||
272 | |||
273 | (% style="width:640px" %) | ||
274 | |(% style="width:111px" %)**目的**|(% style="width:275px" %)**描述**|(% style="width:252px" %)**密切相关的服务价值链活动** | ||
275 | |(% style="width:111px" %)有价值的投资|(% style="width:275px" %)战略性创新和有效的IT应用|(% style="width:252px" %)契动,计划,改进 | ||
276 | |(% style="width:111px" %)快速发展|(% style="width:275px" %)快速实现和交付IT服务和与IT相关的产品|(% style="width:252px" %)契动,设计和转换,获取/构建,改进 | ||
277 | |(% style="width:111px" %)弹性操作|(% style="width:275px" %)高弹性的IT服务和与IT相关的产品|(% style="width:252px" %)契动,交付和支持,改进 | ||
278 | |(% style="width:111px" %)共同创造价值|(% style="width:275px" %)服务提供商与服务使用者之间的有效互动|(% style="width:252px" %)契动,交付和支持,改进 | ||
279 | |(% style="width:111px" %)保证符合性|(% style="width:275px" %)遵守治理,风险和合规(GRC)要求|(% style="width:252px" %)所有价值链活动 | ||
280 | |||
281 | 如表2.1所示,每个目标与一个或多个ITIL 服务价值链活动密切相关,除了与ITIL 服务价值系统的治理部分相关并适用于所有活动的可靠一致性。目标与价值链活动的关系如下: | ||
282 | |||
283 | * 有价值的投资目标主要是通过作为计划价值链活动一部分的决策来实现。 | ||
284 | * 快速研发目标主要是通过在设计和转换以及获取/构建价值链活动中进行的应用程序开发和基础架构工程来实现的。 | ||
285 | * 弹性运营目标主要是通过运行和维护系统(作为交付和支持价值链实现价值的一部分)来实现的。 | ||
286 | * 价值共创目标主要是通过在交付和支持价值链活动(以及服务消费者的有效使用)中对系统提供支持来实现的。 | ||
287 | * 保证合规目标的实现是通过遵守合规性及公司和法规制度作为所有价值链活动的一部分,而不仅是在交付和支持期间。 | ||
288 | |||
289 | 正如所有价值链活动都支持保证合规目标一样,契动和改进价值链活动也有助于实现所有HVIT目标。 | ||
290 | |||
291 | 在某些情况下,不同目标之间会有冲突。例如,快速研发会对弹性运营产生负面影响,因为没有足够的时间来确保服务和产品的稳定可靠。因此,重要的是要确保目标达到适当的平衡。 | ||
292 | |||
293 | 有价值的投资目标决定一项投资的潜在价值。可以在不同领域进行投资,但最终应根据其他四个目标评估回报和收益。随着组织的发展,它将产生额外的成本,并且可能会导致价值降低,而解决方案和收益却不是最优的。实际实现的收益是投资的潜在价值与成本和价值降低之间的差额。然后,投资回报率可以表示为与组织投资相比的已实现收益。如图2.6所示。 | ||
294 | |||
295 | |||
296 | (% style="text-align:center" %) | ||
297 | [[image:1639231112052-360.png]] | ||
298 | |||
299 | 图2.6 从经济角度来看的目标 | ||
300 | |||
301 | |||
302 | (% style="text-align:center" %) | ||
303 | [[image:1639231127616-746.png]] | ||
304 | |||
305 | 图2.7 HVIT的主要特点 | ||
306 | |||
307 | |||
308 | |||
309 | === === | ||
310 | |||
311 | === 2.5.2 高速IT的关键特征 === | ||
312 | |||
313 | |||
314 | 可以采用多种方法来达到和维护HVIT。常见的HVIT方法有四个特征。这些是: | ||
315 | |||
316 | * 精益 | ||
317 | * 敏捷 | ||
318 | * 弹性 | ||
319 | * 持续交付 | ||
320 | |||
321 | 当组织正确的组合并一起使用这些特性时,这些特性可以实现价值的共创,如图2.7所示。 | ||
322 | |||
323 | 表中概述了每种特性的好处。表2.2描述了高速IT的主要特征 | ||
324 | |||
325 | (% style="width:397px" %) | ||
326 | |(% style="width:56px" %)**特性**|(% style="width:340px" %)**益处** | ||
327 | |(% style="width:56px" %)精益|(% style="width:340px" %)帮助提高生产量并减少浪费。 由于上市时间和客户时间的压力,HVIT环境受益于具有精益特性的方法。 | ||
328 | |(% style="width:56px" %)敏捷|(% style="width:340px" %)与用户增加紧密的迭代协作。具有敏捷性的方法对于HVIT环境非常重要,因为必须开发数字化产品和服务来应对不断变化的市场需求。 | ||
329 | |(% style="width:56px" %)弹性|(% style="width:340px" %)保持可行的可用性和性能。支持HVIT环境的系统非常复杂,因此容易出错。具有弹性特性的方法通过逐渐降级系统并快速恢复服务来最小化事件的影响。 | ||
330 | |(% style="width:56px" %)连续|(% style="width:340px" %)确保快速可靠的部署。具有连续特性的方法通过标准化和自动化集成、构建、测试和运输代码的流程来扩展精益生产能力,从而使数字化产品和服务在需要时可用。 | ||
331 | |||
332 | 当一起使用时这些特性时,才会共同创造价值,从而将方法的重点扩展到有效的服务消费。仅当用户实际使用数字化产品和服务时才实现价值。利用HVIT的所有四个关键特性的方法将帮助服务提供商确保服务消费者获得期望的成果。 | ||
333 | |||
334 | 这些特性本质上是技术性,更多地侧重于信息系统(产品)的有形部分,但是许多原理也可以应用于IT服务。 | ||
335 | |||
336 | 单独来看,这些特性不是HVIT独有的。但是,它们在一起有助于满足数字化驱动组织对IT提出的更高要求。他们有助于: | ||
337 | |||
338 | * 规划对数字化产品和服务的正确投资 | ||
339 | * 快速可靠的开发和部署这些产品和服务 | ||
340 | * 使它们持续运行 | ||
341 | * 确保服务消费者通过有效使用实现价值。 | ||
342 | |||
343 | 与五个HVIT目标相似,每个HVIT特性都涉及几个或所有ITIL服务价值链活动。表2.3对此进行了概述。 | ||
344 | |||
345 | 表2.3 HVIT特征对ITIL服务价值链活动影响的总结。 | ||
346 | |||
347 | (% style="width:425px" %) | ||
348 | |(% style="width:76px" %) |(% style="width:50px" %)**计划**|(% style="width:51px" %)**改进**|(% style="width:51px" %)**契动**|(% style="width:72px" %)**设计和转换**|(% style="width:58px" %)**获取/构建**|(% style="width:66px" %)**交付和支持** | ||
349 | |(% style="width:76px" %)精益|(% style="width:50px" %) |(% style="width:51px" %)√|(% style="width:51px" %) |(% style="width:72px" %)√|(% style="width:58px" %)√|(% style="width:66px" %) | ||
350 | |(% style="width:76px" %)敏捷|(% style="width:50px" %)√|(% style="width:51px" %) |(% style="width:51px" %)√|(% style="width:72px" %)√|(% style="width:58px" %)√|(% style="width:66px" %) | ||
351 | |(% style="width:76px" %)弹性的|(% style="width:50px" %)√|(% style="width:51px" %) |(% style="width:51px" %) |(% style="width:72px" %)√|(% style="width:58px" %) |(% style="width:66px" %)√ | ||
352 | |(% style="width:76px" %)持续交付|(% style="width:50px" %) |(% style="width:51px" %)√|(% style="width:51px" %)√|(% style="width:72px" %)√|(% style="width:58px" %)√|(% style="width:66px" %)√ | ||
353 | |||
354 | ==== ==== | ||
355 | |||
356 | |||
357 | ==== 2.5.2.1 精益 ==== | ||
358 | |||
359 | |||
360 | 具有精益特性的方法着重于将大型工作分解为较小的批处理。缩短交付时间是确保质量、客户满意度和员工满意度的最佳方法,而缩短交付时间的好方法是使用小批量的工作。因此,将较大的工作分解为较小的工作是有益的。这通常会给工作带来不同的挑战,将工作组织成更大的批次,并通过正式的移交规程在功能之间传递。 | ||
361 | |||
362 | 小批量可以帮助减少变更对产品系统的破坏性影响。变更越小,中断的风险越低。减小变更的大小还意味着可以更频繁地执行变更。较高的变更频率提高了组织的变更的能力,同时也降低了破坏操作系统的风险。反过来,这有助于减少快速研发和弹性运营的HVIT目标之间的组织紧张关系。 | ||
363 | |||
364 | 另一个提高吞吐量的精益技术是减少正在进行的工作。图2.8提供了基于带有一系列“工作站”的价值流的这种技术的示例。这些包括个人、团队或部门,他们的任务是根据另一个工作站的输入执行工作,然后将其输出移交给下一个工作站。 | ||
365 | |||
366 | 当特定工作站需要输入时,应该“拉”工作,而不是利用价值流中的每个工作站来最大化容量并将工作“推”到下一个工作站上。尽管工作站的效率(利用率)可能看起来很低,但这对于通过价值流的工作流程是有益的。 | ||
367 | |||
368 | |||
369 | (% style="text-align:center" %) | ||
370 | [[image:1639231183725-551.png]] | ||
371 | |||
372 | 图2.8有三个工作站的价值流 | ||
373 | |||
374 | |||
375 | 看板通过将待办工作、进行中的工作和已完成工作可视化来支持这种工作方式。 | ||
376 | |||
377 | 约束理论有关如何改进吞吐量有以下建议: | ||
378 | |||
379 | * 确定价值流中最弱的工作站。 | ||
380 | * 尽可能减轻负载。 | ||
381 | * 围绕最薄弱的环节组织工作。效率最低的工作站决定了彼此相互间工作站应以多高的效率工作,以实现最大的吞吐量。这很重要,因为让价值流中的每个工作站(或职能型团队)以最大的效率运行时,常常会导致下一个工作站的工作积压。 | ||
382 | |||
383 | |||
384 | ==== ==== | ||
385 | |||
386 | ==== 2.5.2.2 敏捷 ==== | ||
387 | |||
388 | |||
389 | 基于精益原则基础(小批量工作有利于提高吞吐量),具有敏捷特性的方法着重于交付小的产品或服务迭代,以便方法可以根据环境的变化来调整。在这些方法中,尽可能快地收集信息形式的反馈,并尽可能长地延迟决策。 | ||
390 | |||
391 | 敏捷技术专注于软件开发人员、业务人员以及改进客户体验的相关方正在进行的沟通和交互。此描述指软件开发过程中敏捷的工作方式得到了发展,但也可以应用于其他工作领域。 | ||
392 | |||
393 | 软件由小规模、相对独立、自组织和跨职能的团队开发,其中用户代表(通常称为产品负责人)扮演主要的角色。开发团队可以执行此工作,这意味着管理角色可以从控制转变为促进,从而创造出效率更高的环境(通常称为“ 服务型领导力”)。这通常与组织跨专业的职能型团队(例如设计、开发、部署和运营)的工作具有挑战性。 | ||
394 | |||
395 | 小型团队经过交叉训练的“T形”成员(在一个领域中具有广泛的常识和深厚的专业知识的成员;有关此方面的更多信息,请参见ITIL®4:创建,交付和支持),可以减少人与人之间的传递次数并改进工作流程,这些有助于团队提升效率。然而,当不同种类的任务由一个人组合并执行时,存在这样一种风险,即该任务基于适用于一种任务而不适用于将要执行的任务原则执行。例如,技术专长对于编码很重要,而响应用户请求时需要同理心。在某些情况下,在分析事态日志和响应用户呼叫之间执行多任务的服务专员,可能会表现出错误的行为的风险。可以通过仪式或标识在身体上增强角色的变化来缓解这种情况;例如,移动到另一个房间接听用户电话,或者穿着制服或徽章指示特定的职能。 | ||
396 | |||
397 | 产品负责人管理待办项的工作,根据其价值对进行优先级排序。可以通过估计每个工作项的延迟成本来确定此价值。 | ||
398 | |||
399 | |||
400 | **定义:延迟成本** | ||
401 | |||
402 | 指延迟启动或更新服务产品时可能会失去的好处。 | ||
403 | |||
404 | 在管理工作时,在工作被认为已经完成时,多个利益干系人(例如开发,支持和合规性)对何时完成工作有共同的理解可能是有益的。这被称为“ 已完成的定义”,包括讨论和商定的标准,它们指定了拟议的产品或服务所需的功用和功效。在敏捷软件开发中,“完成”通常意味着具有潜在可部署的软件增量。DevOps将此定义从仅可部署的软件扩展到三个类别:已部署,已发布和可使用。从共同创造服务的角度来看,将工作定义为“完成”的更好方法是用户从其投资中获得了期望的成果(有关“完成”的定义,请参见第4.3.3节)。 | ||
405 | |||
406 | DevOps方法建立在敏捷软件开发和服务管理技术之上,强调软件开发和技术运营角色之间的紧密协作。DevOps使用高度的自动化来释放熟练的专业人员的时间,以便他们可以专注于增值活动,DevOps有助于在管理服务的软件产品的可操作性,可靠性和可维护性等方面发挥作用,从而帮助管理服务。 | ||
407 | |||
408 | |||
409 | ==== ==== | ||
410 | |||
411 | ==== 2.5.2.3 弹性 ==== | ||
412 | |||
413 | |||
414 | 具有弹性特性的方法侧重于维护可用性和性能,并最大程度地减少事件的影响。具有弹性特征的方法的两个示例是站点可靠性工程(SRE)和DevOps。 | ||
415 | |||
416 | SRE将软件开发思维方式应用于IT运营,并有助于弥合开发与运营之间的鸿沟。SRE团队与现有的IT运营团队一起创建。这些SRE团队将时间分配给执行IT运营和指导IT运营团队,以及开发有助于增加IT系统的弹性和性能的软件。 | ||
417 | |||
418 | DevOps(更确切地说是DevSecOps)促进将安全性集成到应用程序开发和IT运营的日常工作中,而不是将其作为单独的“监控”功能。在这里,安全员的角色从指定要求和监控性能转变为使从业人员能够解决安全的问题。这可以使工作更快,更有效地完成,但是通常需要在信任从业者完成此任务方面有一个挑战性的飞跃。 | ||
419 | |||
420 | DevOps还促进了对生产中的IT系统的主动监控。这种主动监控与更快的平均恢复服务时间(MTRS)紧密相关。有许多可用的工具可提供有关运行系统的信息。应谨慎考虑提供信息的信噪比,因为大家吸收信息的能力有限,希望对重要信息和非重要信息有所区分,不然工具提供的信息不仅无效,也是不合理的负担。 | ||
421 | |||
422 | 增强弹性的其他方法包括抗脆弱性、软件和基础设施,微服务、容器化、特性切换、渗透测试和灾难恢复的这些弹性架构。 | ||
423 | |||
424 | |||
425 | ==== ==== | ||
426 | |||
427 | ==== 2.5.2.4 持续交付 ==== | ||
428 | |||
429 | |||
430 | 具有连续特性的方法,例如持续集成、交付和部署(CI / CD),基于这样的信念,小批量和频繁的工作不仅有价值,还可以更快获得反馈。因为可以更早地使用功能,变更更安全更小批量。 | ||
431 | |||
432 | 持续集成、持续交付和持续部署(CI / CD)是主要与软件工程相关的实践的描述性术语,它们是精益和敏捷软件开发理念的核心。这些做法的采用迅速增长,重要的是要在不断发展的系统开发实践的大背景下理解CI / CD的定义特征。 | ||
433 | |||
434 | 当实施以软件开发为基础的服务时,这些将在第4.2.5节中进一步详细描述。 | ||
435 | |||
436 | 持续集成、交付和部署的关键是所有相关方之间良好的工作关系和广泛的自动化: | ||
437 | |||
438 | * 构建自动化(CI阶段)包含版本控制,并将多个开发人员变更合并到一个共享代码分支中。 | ||
439 | * 测试自动化在类生产环境中自动测试和验证每个变更。 | ||
440 | * 自动配置安装和配置硬件和软件,以激活客户的购买服务。 | ||
441 | * 部署自动化将代码从预生产环境迁移到生产环境的流程自动化。 | ||
442 | * 部署之后的测试验证功能和非功能属性,尤其是性能/负载测试,这在部署之前很难实现测试。 | ||
443 | |||
444 | |||
445 | |||
446 | ==== ==== | ||
447 | |||
448 | ==== 2.5.2.5 结合HVIT特性共同创造价值 ==== | ||
449 | |||
450 | |||
451 | 精益、敏捷、有弹性和连续性的组织可以更好地为价值共创提供服务,服务形式可以轻松地适应不断变化的环境和客户的需求。 | ||
452 | |||
453 | 服务科学将服务定义为对资源(包括能力、技能和知识)的应用,以便对另一个组织进行有价值的变更。ITIL将服务定义为一种通过促进客户希望实现的成果而实现价值共创的方式,而客户不必管理特定的成本和风险。无论采用哪种定义,在任何服务中都至少存在两个交互的实体(在服务科学中称为服务系统)。服务提供商和服务消费者构成了一对服务系统的简单示例,但是还有其他一些,例如监管机构。服务主导逻辑是服务科学的核心概念。 | ||
454 | |||
455 | |||
456 | **定义:以服务为主导的逻辑** | ||
457 | |||
458 | 一种(经济)交换的思维模型,在这种模型中,组织在此过程中通过运用自己的能力和其他资源互利而共同创造价值,从而使彼此收益。 | ||
459 | |||
460 | 服务主导的逻辑将服务视为为另一方做某事并与另一方合作的过程。价值创造是协作的过程。在以服务为主导的逻辑中,价值总是共同创造的。服务主导逻辑与货品主导逻辑相反,后者,提供者通过转让货品的所有权将价值传递给客户。 | ||
461 | |||
462 | 在将服务主导逻辑应用于服务交付时,提供者会更加关注客户的具体情况,并使客户参与到服务交付过程中。这是帮助客户完成工作更有效方法。服务交互以消费者为核心,当消费者集成并应用服务提供者(和其他服务系统)的资源以实现交换时,消费者就创造了价值。每个消费者都基于个人需求在特定时间和特定的背景中确定服务体验的价值或质量。 | ||
463 | |||
464 | |||
465 | **ITIL的故事:高速IT的关键特征** | ||
466 | |||
467 | Henri:在Axle,我们为能够快速适应需求和机遇的变化而感到自豪。我们的技术所提供的服务不仅为我们创造了价值,而且为我们所有的利益干系人:我们的合作伙伴,供应商和客户创造了价值。 | ||
468 | |||
469 | Marco:我们确保我们的技术投资符合我们的目标,并遵守治理、法规和合规性的要求。 | ||
470 | |||
471 | Solmaz:我们的技术选择反映了高速IT的四个特征:精益、敏捷、弹性和连续。鉴于我们收集了大量的客户数据,我们确保数据和技术能够抵御网络攻击,并在压力下保持稳定。我们以小批量方式工作,根据客户需求量身定制每个变更,并采用持续集成、交付和部署方式。我们还监控流程,以尽可能减少精力浪费。 | ||
472 | |||
473 | |||
474 | == == | ||
475 | |||
476 | == 2.6 采用ITIL服务价值系统实现高速IT == | ||
477 | |||
478 | |||
479 | HVIT将与价值高度相关联的IT工作与高速业务相结合,达成从创新到价值的实现。这需要快速的迭代,快速的反馈和快速的改进,不仅可以使事情更快地完成,还可以提升与IT相关的产品和服务的质量。这对组织的IT运营模型具有重要意义。数字化驱动组织定义和构建与IT相关的活动和资源,这与IT战略重要性较小的组织不同。数字化组织对技术的更高要求反映在他们的运营方式上。例如,具有数字功能的组织可能拥有相对独立的基于产品/服务的团队,而非职能组织结构,并且对快速迭代的流程和失效有更高的兴趣。 | ||
480 | |||
481 | 本节说明如何使用ITIL指南为定义HVIT工作及组织的IT运营模型提供构建块。 | ||
482 | |||
483 | 运营模型是组织业务模型的“后端”,并提供该业务模型中定义的价值主张。运营模型代表组织的构建块及其之间的关系。它可以用作组织当前状态的描述,也可以用作未来的状态设计,称为“目标运营模型”。 | ||
484 | |||
485 | |||
486 | **定义** | ||
487 | |||
488 | * **运营模型**组织如何与其客户和其他利益干系人共同创造价值,以及组织如何运营的概念和/或可视化表示。 | ||
489 | * **高速IT运营模型**是一种运营模型,其中数字化技术在价值共创中扮演着重要角色。 | ||
490 | |||
491 | 当运营模型与客户共同创造价值时,运营模型变得更加数字化,或者对不确定、模棱两可和快速变化的环境做出反应时,运营模型通常需要采用高速方法。在创建运营模型的过程中,通常拥有与最终产品同等的价值,甚至更多。 | ||
492 | |||
493 | HVIT运营模型是数字化技术在价值共创中起着重要作用的模型。所有的运营模型都有一些数字元素,但是数字化技术是数字运营模型使模型成为可能的要素,否则模型将不可行或不实用。 | ||
494 | |||
495 | 数字化驱动组织的运营模型的重点在于: | ||
496 | |||
497 | * 为每个产品和服务都提供专用的价值流 | ||
498 | * 促进高性能和持续改进的共创文化 | ||
499 | * 永久的基于产品/服务的团队,而不是临时的项目团队 | ||
500 | * IT流程的自动化,包括将基础架构作为代码。 | ||
501 | |||
502 | 在ITIL中,价值流是运营模型的核心,因为它们是交付产品和服务所需的一系列步骤。HVIT可以由ITIL 服务价值系统的许多要素支持(见图2.9)。 | ||
503 | |||
504 | 以下各节概述了HVIT与以下概念的关系: | ||
505 | |||
506 | * 数字化产品和服务 | ||
507 | * 数字化产品生命周期 | ||
508 | * ITIL服务价值链 | ||
509 | * 价值流 | ||
510 | * ITIL管理实践 | ||
511 | * 服务管理的四个维度 | ||
512 | * 外在因素 | ||
513 | * 治理和管理 | ||
514 | |||
515 | (% style="text-align:center" %) | ||
516 | [[image:1639231309400-683.png]] | ||
517 | |||
518 | 图2.9 ITIL服务价值系统 | ||
519 | |||
520 | |||
521 | HVIT组织还可以从ITIL 指导原则的应用中受益。这些原则以及如何使用它们,将在第3章中详细讨论。 | ||
522 | |||
523 | |||
524 | === === | ||
525 | |||
526 | === 2.6.1 数字化产品和服务 === | ||
527 | |||
528 | |||
529 | ITIL将产品定义组织资源的配置,旨在为消费者提供价值。产品通过服务提供给消费者,使双方能够共同创造价值。这些服务通过获取货品、使用提供者的(有形)资源并与提供者进行交互的方式向消费者展示。当消费者运用自己的资源来消费产品时,价值是在服务提供和消费期间共同创造的。 | ||
530 | |||
531 | 某些产品可以定义为数字化产品。 | ||
532 | |||
533 | |||
534 | **定义:数字化产品** | ||
535 | |||
536 | 当数字化技术在货品、资源或相关的服务交互中起着重要的作用时,该产品就是数字化。 | ||
537 | |||
538 | 就数字化产品的定义而言,重要的角色通常意味着没有技术,产品要么不存在,要么缺乏关键特性或特点。 | ||
539 | |||
540 | 服务基于一种或多种产品,并且可以提供数字和模拟用户的体验。基于数字化产品的服务示例包括网上银行、共享乘车、电子商务、线上电子门票,照片和视频存储和共享、电子学习、机票预订和管理、音乐流媒体、智能手机应用和数字化相机。然而,随着数字化算法变得越来越复杂,模拟体验通常仅用于处理超出算法范围的特殊情况。 | ||
541 | |||
542 | 为了价值共创,提供者和消费者契动服务交互。服务交互发生在消费者使用提供者的服务时发生的事情,该服务提供服务提供者的产品和其他资源。 | ||
543 | |||
544 | 消费者和提供者之间的服务交互是三种交互的组合: | ||
545 | |||
546 | * **服务动作 **服务提供者在哪里(响应请求或主动地)应用其资源,例如通过提供有关IT服务使用的信息。HVIT组织使用数字化产品来自动化大量服务动作以及与消费者的交互,以提升效率和有效性。 | ||
547 | * **访问资源 **服务消费者利用服务提供者的资源,例如通过登录网站。HVIT组织提供对其资源的访问,或使用数字化产品提供的渠道访问消费者的资源。 | ||
548 | * **货品转让 **服务消费者获取服务提供者资源的所有权,例如通过购买笔记本电脑。HVIT组织通常不提供实物货品作为其数字化产品和服务的一部分。 | ||
549 | |||
550 | 提供者和消费者彼此拥有资源称为“可见范围”。某些资源对另一方是可见的,而某些资源是隐藏的或“不可见的”。在服务交互期间,消费者与提供者的某些资源进行交互,并且受到提供者使用的其他“不可见”资源的影响。 | ||
551 | |||
552 | |||
553 | (% style="text-align:center" %) | ||
554 | [[image:1639231348743-984.png]] | ||
555 | |||
556 | 图2.10 服务交互和可见范围 | ||
557 | |||
558 | |||
559 | 提供者在服务交互中扮演间接角色。同样,服务提供者与服务消费者的某些资源进行交互,并且间接受到服务消费者自己的“不可见”资源的影响。 | ||
560 | |||
561 | “可见范围“的宽度对于服务体验和服务交互的有效性至关重要。如果范围太广,任何一方都可能会因与互动无关或无关的事态而感到困惑或分心。如果范围太窄,任何一方都可能会因缺乏信息和影响而感到沮丧。必须实现微妙的平衡,并且处理此问题的正确方法因不同的提供商和消费者而异。为了有效地处理该问题,各方都应该能够理解对方的需求并适当地调整方法。HVIT组织经常使用由合作伙伴和供应商提供的产品和服务组成的复杂网络。在这样的生态系统中,提供者通常具有比消费者更多的可视化资源,反之亦然。 | ||
562 | |||
563 | 服务交互和可见范围的示例如图2.10所示。有关可见范围的更多信息,请参见ITIL®4:提高利益干系人价值。 | ||
564 | |||
565 | |||
566 | === === | ||
567 | |||
568 | === 2.6.2 数字化产品生命周期 === | ||
569 | |||
570 | |||
571 | 服务消费者和服务提供者对数字化产品有不同的看法。它们每个都有自己的产品生命周期,这些生命周期在消费者和提供者互动期间重叠。对于服务提供者而言,产品的生命周期持续存在,只要该产品有潜在的客户。对于服务消费者而言,只要使用产品,生命周期会一直持续,严格来说,这就是产品使用生命周期。 | ||
572 | |||
573 | 从服务消费者的角度来看,数字化产品的生命周期始于针对特定需求的可能解决方案的市场探索。这些消费者可以根据以下特征来表征 | ||
574 | |||
575 | |||
576 | (% style="text-align:center" %) | ||
577 | [[image:1639231381158-643.png]] | ||
578 | |||
579 | 图2.11 数字化产品生命周期从消费者和供应商两个角度展开 | ||
580 | |||
581 | |||
582 | 心理图形绘制映射他们共同的性格特征、信念、价值观、态度、兴趣、生活方式和其他因素。服务提供者在设计和提供产品或服务时经常考虑这些因素。 | ||
583 | |||
584 | 从服务提供者的角度来看,产品的生命周期首先始于对新产品投资市场的机会的探索,此时他们正在为现有产品寻找潜在客户。 | ||
585 | |||
586 | 在某个时刻,服务消费者和提供者会相互发现并契动交互,有时会发生转换。 | ||
587 | |||
588 | 在提供和消费服务之前,需要进行引入活动,双方都要进行准备。然后,提供者和消费者开始交互,使用服务价值共创,直到任何一方宣布参与结束。接下来是取消活动和脱离接触。终止服务关系的原因很多,其中包括: | ||
589 | |||
590 | * 消费者不再对产品有需求 | ||
591 | * 消费者对提供者不满意 | ||
592 | * 提供者无法满足变化的需求 | ||
593 | * 提供者停用了不盈利的产品 | ||
594 | |||
595 | 图2.11说明了服务消费者和提供者如何各自拥有自己的数字化产品生命周期。服务消费者与服务提供者互动,可能替代以前的服务提供者。约定期限过后,合同终止,服务消费者要么用另一个人替换服务提供者,要么根本不再需要服务提供者。 | ||
596 | |||
597 | 更详细地讲,客户旅程包括七个交互: | ||
598 | |||
599 | * **探索 **了解市场和利益干系人。 | ||
600 | * **契动 **促进人际关系。 | ||
601 | * **供应 **需求和服务产品。 | ||
602 | * **协议 **期望并同意服务。 | ||
603 | * **引入 **或撤销旅程。 | ||
604 | * **价值共创 **提供和消费。 | ||
605 | * **实现价值 **价值收获和改进。 | ||
606 | |||
607 | 客户旅程的模型如图2.12所示。有关客户旅程的更多信息,请参见ITIL®4:提高利益干系人价值。 | ||
608 | |||
609 | |||
610 | (% style="text-align:center" %) | ||
611 | [[image:1639231429603-449.png]] | ||
612 | |||
613 | 图2.12 客户旅程模型 | ||
614 | |||
615 | |||
616 | 更换服务提供者时,双方都有一段过渡期,才能提供和使用新的提供者的服务。服务消费者在将服务从当前的服务提供者转移到新的服务时通常需要帮助和保证。 | ||
617 | |||
618 | 当消费者仍有需求需要提供解决方案时,他们将面临着将不满意或已停用的产品下架,同时又开始着手更换产品。中断的风险是一个严重的问题。为了减少这种担忧,提供者有时会从当前的提供者到后续的供应来提供帮助进行过渡。图2.13显示了消费者视角的数字化产品生命周期的透视图。 | ||
619 | |||
620 | 表2.4从服务提供者和服务消费者的角度概述了数字化产品的生命周期阶段。 | ||
621 | |||
622 | |||
623 | (% style="text-align:center" %) | ||
624 | [[image:1639231448566-728.png]] | ||
625 | |||
626 | 图2.13 从消费者的角度看数字化产品的生命周期 | ||
627 | |||
628 | |||
629 | 表2.4 数字化产品生命周期的各个阶段 | ||
630 | |||
631 | (% style="width:530px" %) | ||
632 | |(% style="width:63px" %)**生命周期阶段**|(% style="width:248px" %)**服务提供者**|(% style="width:216px" %)**服务消费者** | ||
633 | |(% style="width:63px" %)探索|(% style="width:248px" %)服务提供商研究和开发产品和服务产品。|(% style="width:216px" %)服务使用者意识到产品的存在,并且认为有趣并令人期望,然后达成协议。 | ||
634 | |(% style="width:63px" %)引入|(% colspan="2" style="width:464px" %)已安装产品实例,并且用户组织已加入,有时需要从已替换产品过渡。 | ||
635 | |(% style="width:63px" %)共同创造价值|(% style="width:248px" %)((( | ||
636 | 服务提供商交付并支持产品,并增加、稳定或降 | ||
637 | |||
638 | 低的投资回报率,从而做出购买(使用和改进产 | ||
639 | |||
640 | 品),持有(使用但不改进产品)或出售(使用和使 | ||
641 | |||
642 | 用产品、减少、更换或停用)的投资决策。 | ||
643 | )))|(% style="width:216px" %)((( | ||
644 | 服务使用者使用该产品并体验到价值的增长、稳定或 | ||
645 | |||
646 | 下降,最终决定更换或停用该产品。 | ||
647 | ))) | ||
648 | |(% style="width:63px" %)撤销|(% colspan="2" style="width:464px" %)产品实例被卸载,用户组织被取消注册,有时需要过渡到替代产品。 | ||
649 | |(% style="width:63px" %)停用|(% style="width:248px" %)服务提供商不再提供或支持该产品。|(% style="width:216px" %)服务使用者不再使用此产品,但是其他使用者可以使用它。 | ||
650 | |||
651 | (% style="text-align:center" %) | ||
652 | [[image:1639231475298-755.png]] | ||
653 | |||
654 | 图2.14 ITIL服务价值链 | ||
655 | |||
656 | |||
657 | === === | ||
658 | |||
659 | === 2.6.3 ITIL服务价值链 === | ||
660 | |||
661 | |||
662 | 交付产品和服务所需的活动由组织的服务价值链和实践来建模。服务价值链描述了组织的原型活动(见图2.14)。 | ||
663 | |||
664 | ITIL服务价值链可用于以相当高的抽象水平描述服务提供者执行的活动类型。它可以帮助人们专注于每个价值链活动的目标以及输入和输出,而不会迷失在价值流中较低级别活动的细节中。 | ||
665 | |||
666 | 价值链活动紧密相关,可以按任何顺序安排以解释和讨论各种不同的情况。 | ||
667 | |||
668 | |||
669 | ==== ==== | ||
670 | |||
671 | ==== 2.6.3.1 价值链活动和DevOps ==== | ||
672 | |||
673 | |||
674 | 在HVIT环境中,经常使用“连续”的概念,这是许多HVIT方法的关键特征。“连续”是指短的反馈循环所支持的快速的、迭代的活动周期。CI / CD是这方面的一个众所周知的示例,其中新软件通过高度自动化和一部分的价值流的流量实现了无延迟地递增流动。 | ||
675 | |||
676 | DevOps社区经常使用一个数字8来说明这一点,该数字包含一个连续的应用开发和IT运维活动的连续循环,如图2.15所示。开发和运维活动由基础设施和平台支持,用于编码、测试、部署、生产等。 | ||
677 | |||
678 | 该循环可与ITIL服务价值链活动一起使用,以提供DevOps和ITIL的组合视角。用ITIL术语,DevOps专注于开发、部署和运营具体的服务组件,而不是无形的服务。DevOps中主要的服务组件是应用程序、数据和平台,它们一起构成了消费者的产品。 | ||
679 | |||
680 | |||
681 | (% style="text-align:center" %) | ||
682 | [[image:1639231520134-557.png]] | ||
683 | |||
684 | 图2.15 DevOps活动在一个连续的循环中服务价值链的重点是产品和服务,而不是单个服务组件。它描述了服务提供者的产品和其他资源(包括服务消费者的资源)之间的交互所需的资源。 | ||
685 | |||
686 | |||
687 | 图2.16显示了如何将DevOps循环和服务价值链活动结合在一起。一些服务价值链活动(例如设计和转换)已分为两个“子活动”,可以更轻松地映射到DevOps模型的各个部分。 | ||
688 | |||
689 | (% style="text-align:center" %) | ||
690 | [[image:1639231537049-887.png]] | ||
691 | |||
692 | |||
693 | 图2.16 DevOps和服务价值链 | ||
694 | |||
695 | |||
696 | 服务价值链活动通过以下方式链接到图2.16中的DevOps模型: | ||
697 | |||
698 | * 设计价值链活动与开发并行进行,与软件产品相比,更侧重于服务。 | ||
699 | * 获得价值链活动是与外部开发人员接口,将开发的软件产品与服务所包含的其他资源集成在一起。 | ||
700 | * 增值链活动对应于内部开发。 | ||
701 | * 转换价值链活动与从Dev到Ops的部署并行运行,并与之对应, | ||
702 | * 价值链的交付和支持活动与Ops相对应,通常比Ops更全面。 | ||
703 | * 契动价值链活动与所有基础活动并行运行。 | ||
704 | * 规划价值链活动对应于Dev的规划部分。 | ||
705 | * 价值链改进活动与DevOps的宗旨之一相对应:在所有DevOps活动中不断实验、学习和改进(通常称为DevOps的“第三种方式”)。 | ||
706 | |||
707 | 这是如何将HVIT应用于服务价值链的示例,通过允许从不同角度进行工作讨论来帮助弥合专业学科之间的鸿沟。对于各学科之间的协作,首先重要的是,每个学科都应理解对方的观点并使用另一学科熟悉的用语。一旦确立了这一点,讨论就可以从了解变成理解。 | ||
708 | |||
709 | |||
710 | ==== ==== | ||
711 | |||
712 | ==== 2.6.3.2 服务消费者 ==== | ||
713 | |||
714 | |||
715 | HVIT可以应用于服务价值链的另一种方式是说明服务提供者和服务使用者之间的交互程度。服务消费者在获取、提供和使用方面与服务提供者结合在一起进行交互。 | ||
716 | |||
717 | 消费者将其需要转换为需求,并雇用提供者提供服务,然后契动这些服务来创建价值。从消费者的角度来看,这可以表示为服务价值链,如图2.17所示。可以扩展此图,以结合服务提供者在服务价值链活动方面的观点。 | ||
718 | |||
719 | (% style="text-align:center" %) | ||
720 | [[image:1639231575585-440.png]] | ||
721 | |||
722 | 图2.17 服务消费者的视角 | ||
723 | |||
724 | |||
725 | (% style="text-align:center" %) | ||
726 | [[image:1639231590573-501.png]] | ||
727 | |||
728 | 图2.18 服务价值链互动 | ||
729 | |||
730 | |||
731 | 图2.18显示了服务提供者的六个价值链活动,上半部分是初始设计和开发,下半部分是交付和支持(与后续增强功能并行)。消费者和提供者之间的主要接口由消费者的需求(R)和提供者的服务(S)标记。设计和开发以及交付和支持由已部署的产品(P)连接。 | ||
732 | |||
733 | 图2.19显示了价值流如何在价值链活动中流动。与价值链活动和DevOps的链接一样,此组合可用于促进更好的工作方式(包括如何获得更快的反馈)。 | ||
734 | |||
735 | (% style="text-align:center" %) | ||
736 | [[image:1639231623115-904.png]] | ||
737 | |||
738 | 图2.19 引用服务价值链活动的服务价值流示例 | ||
739 | |||
740 | |||
741 | === === | ||
742 | |||
743 | === 2.6.4 价值流 === | ||
744 | |||
745 | |||
746 | 价值流是组织采取的一系列步骤,以创建产品和服务并将其交付给消费者。它们是根据指导方针(原则,方法,技术等)并且在约束(法规,政策,预算等)内执行的一组活动。 | ||
747 | |||
748 | 重要的是要认识到服务价值链和相关实践是实际价值流所基于的模型。在人力和其他资源价值共创的地方可以观察到价值流。服务价值链和相关的实践是无法观察到的,因为它们是用于模型价值流的抽象表示。 | ||
749 | |||
750 | 如图2.20所示,它由价值需求需求触发价值流,价值需求是使用产品和服务共同创造的。价值流包含将资源组合在一起的步骤,从而生成旨在为服务消费者和其他利益干系人创造价值的产品。资源执行的活动由组织采用的各种方法指导(实践中对价值流和流程/规程/工作说明的描述,服务价值链和指导原则中的活动描述)。 | ||
751 | |||
752 | 服务价值链描述了有效管理产品和服务所需的活动,而价值流包括创建产品和服务并将其交付给消费者的一系列实际步骤。因此,可以将价值流视为实际发生的地方:使用ITIL实践并价值共创的地方。价值流没有固定的结构,并且对于每个组织都是唯一的。HVIT组织通常以产品/ 服务为导向,并具有多个价值流,这些价值流反映了其产品和服务的多样性。因此,他们的运营模型包括多个价值流。 | ||
753 | |||
754 | |||
755 | (% style="text-align:center" %) | ||
756 | [[image:1639231647595-650.png]] | ||
757 | |||
758 | 图2.20 上下文中的价值流 | ||
759 | |||
760 | |||
761 | “流”一词表明吞吐量的重要性:快速、准时地完成工作。许多因素都会使价值流的运行速度变慢,包括切换和过载,这使得队列管理非常重要。如果每个任务都由一个人或一个团队完成,则吞吐量将受益,尽管这种情况很少发生。 | ||
762 | |||
763 | 也可以通过将输入的工作流程限制为“工作站”的容量来增加它。从端到端的角度来看,这意味着工作量应该在整个价值流之间保持平衡。 | ||
764 | |||
765 | 尽快获取反馈也很重要,不仅要实现可能需要的改进,而且对于不稳定HVIT 环境至关重要的是,还应评估是否需要改进工作方式或思维方式。在这些动态环境中,日常工作的改进点与实际进行日常工作一样重要。 | ||
766 | |||
767 | 在HVIT环境中,系统通常很复杂,因此不可预测。这使得详细的步骤、规程和工作指示不太可能有用,因为通常不会遵循它们。除了高度抽象的高层外,预测或指示价值流中的步骤顺序以及这些步骤中的活动也是没有用或不可行的。取而代之的是,活动和步骤的顺序通常会在执行过程中发生的“微交互”过程中并因此而出现。这意味着从业者必须能够观察到他们的行为以及其他行为所做出的预期和意料之外的变化,并相应地调整其下一个行为。这种工作方式是探索性的,而不是确定性的,从预测和控制转变为洞察和理解。从偶尔的大变化到频繁的小变化,从预先的详细规划到不断的实验和学习,从失效安全到安全失效。 | ||
768 | |||
769 | 价值流的三个关键方面是治理、执行和改进,如图2.21所示。治理适用于执行和改进,反过来改进适用于执行和治理。在执行过程中,将为运营提供必要的资源,并对运营和资源进行管理。价值流处于执行状态,因此受到治理和改进。 | ||
770 | |||
771 | 治理、管理、提供资源、不断改进的价值流以及指导和实现价值的资源,可以被视为运营模型的核心:这是组织与客户和其他利益干系人价值共创的方式。 | ||
772 | |||
773 | |||
774 | (% style="text-align:center" %) | ||
775 | [[image:1639231671593-147.png]] | ||
776 | |||
777 | 图2.21 价值流定位于治理、执行和改进方面 | ||
778 | |||
779 | |||
780 | === === | ||
781 | |||
782 | === 2.6.5 ITIL管理实践 === | ||
783 | |||
784 | |||
785 | ITIL 管理实践描述了实现特定目的所需的资源和活动,以及管理这些资源和活动的公认方法。 | ||
786 | |||
787 | 组织提供的服务(通常是货品)可以为客户提供帮助。这需要执行一组活动,无论有无客户的直接参与。为了执行这些活动,组织和客户都必须具有一定的能力。这些能力可能是某个特定活动所独有的,也可能是多项活动所必需的,例如在参与的每个阶段之间保持一种有效的关系。能力涉及人力和各种资源的相互作用。 | ||
788 | |||
789 | |||
790 | **ITIL术语** | ||
791 | |||
792 | ITIL实践代表了组织实现特定目标的能力。这涉及所有服务管四个维度的所有资源。实践可能受到各种组织解决方案的支持,包括专门的团队和工具。尽管这些团队和工具的名称可能与它们所隶属的实践的名称相同,但不要与它们混淆。 | ||
793 | |||
794 | ITIL管理实践共有34种,分为三类: | ||
795 | |||
796 | * 通用管理实践(例如组织变革管理)可在许多其他业务域中找到,但也适用于服务管理。 | ||
797 | * 服务管理的实践是服务管理的核心,并对其进行了详细描述,以便读者不仅了解实践,而且知道如何开发和使用所需的能力。 | ||
798 | * 技术管理实践与服务管理实践紧密相关,因为它们侧重于服务组件。换句话说,技术资源是服务的一部分。这些技术资源是应用程序、数据、平台和基础架构。 | ||
799 | |||
800 | 实践本身只是资源的集合,这些资源使组织可以执行某些活动。价值仅应用于价值流的背景下时才会从实践中产生。ITIL实践可以视为组织价值流的基础。每个实践都描述了如何将其作用于一个价值流,但是每个价值流都将以其自己的特定方式应用这些实践。尽管标准化有其好处,尤其是对于效率,但根据每个价值流的特定需求量身定制的做法通常更为有效。 | ||
801 | |||
802 | |||
803 | (% style="text-align:center" %) | ||
804 | [[image:1639231705680-314.png]] | ||
805 | |||
806 | 图2.22 涉及价值流的多种管理实践,描述为波特价值链的变体 | ||
807 | |||
808 | |||
809 | 价值流的每个步骤都包含管理实践中定义和描述的活动。其他实践可能会通过信息、工具或方法促进价值流。如图2.22所示。 | ||
810 | |||
811 | |||
812 | ==== ==== | ||
813 | |||
814 | ==== 2.6.5.1 HVIT的关键实践 ==== | ||
815 | |||
816 | |||
817 | 表2.5中说明了与HVIT和数字化产品最相关的实践。 | ||
818 | |||
819 | 表2.5实践及其与五项目标的相关性 | ||
820 | |||
821 | [[image:1641699892753-874.png]] | ||
822 | |||
823 | [[image:1641699933162-408.png]] | ||
824 | |||
825 | |||
826 | === === | ||
827 | |||
828 | === 2.6.6 服务管理的四个维度 === | ||
829 | |||
830 | |||
831 | 服务和服务管理需要主动和被动资源,这可以是组织为进行相关活动而获取或发展的任何资源。组织的员工、合作伙伴和供应商是活跃的(运营)资源或参与者。他们与其他参与者以及被动(操作数)资源和产品进行交互。 | ||
832 | |||
833 | 组织资源的示例包括: | ||
834 | |||
835 | * 组织(包括财务和物质资源,例如建筑物)和人员 | ||
836 | * 信息和技术 | ||
837 | * 合作伙伴和供应商。 | ||
838 | |||
839 | 这是服务管理四个维度中的三个,他们是ITIL框架的关键组成部分。服务管理四个维度受PESTLE各种外部因素的影响:政治、经济、社会、技术、法律和环境,如图2.23所示。 | ||
840 | |||
841 | 服务管理的四个维度确定了价值流中使用的资源的种类。四个维度中的三个(组织和人员,信息和技术,以及合作伙伴和供应商)是在价值流的执行过程期间可操作使用的具体资源。价值流和流程维度表示抽象资源,这些抽象资源用作价值流设计的输入。如图2.20所示。 | ||
842 | |||
843 | 以下各节介绍了各个维度应用于HVIT的示例。 | ||
844 | |||
845 | (% style="text-align:center" %) | ||
846 | [[image:1639231923289-128.png]] | ||
847 | |||
848 | 图2.23 服务管理的四个维度包括六大要素 | ||
849 | |||
850 | |||
851 | ==== ==== | ||
852 | |||
853 | ==== 2.6.6.1 组织和人员 ==== | ||
854 | |||
855 | |||
856 | 在HVIT环境中,IT是组织产品和服务不可或缺的一部分,IT职能很可能将成为负责各种产品和服务的业务部门的组成部分。通常会有基于产品/ 服务的多功能团队,既面向技术又面向业务。 | ||
857 | |||
858 | 面向IT的团队成员。尽管可能有一个集中化的IT服务中心来处理非差异化的数字化技术,例如电子邮件和Wi-Fi,但是差异化的数字化技术通常将作为主要活动的一部分进行管理。可能还有一些面向平台的团队,可以支持各种分散的基于产品/ 服务的团队。在这样的环境中,组织的挑战之一是管理混合环境,在该环境下某些技术是专用的,而某些技术则是共享的。并且小型、动态、面向产品的系统必须与大型、灵活性较差的后端系统进行转换。 | ||
859 | |||
860 | 在面向产品/ 服务的团队中,业务和IT之间没有服务级别协议,因为它们属于同一团队。团队中的IT小组之间的协议也是如此。可能仍然存在度量标准和指标,但它们与业务线的主要目标保持一致,而不是作为具有IT功能的内部事务的一部分。 | ||
861 | |||
862 | HVIT环境中的IT从业人员通常与非IT同事在相同的物理位置工作,通常在独立的产品/服务团队中。这不仅有利于沟通交流,而且还有助于更好地理解使用数字化技术的业务环境。 | ||
863 | |||
864 | |||
865 | ==== ==== | ||
866 | |||
867 | ==== 2.6.6.2 信息和技术 ==== | ||
868 | |||
869 | |||
870 | 本节涉及用作“生产资源“以生产包含数字化产品和服务的信息和技术。换句话说,用于生产产品的工具,而不是产品本身。 | ||
871 | |||
872 | 在从数字化技术中获得重要价值的的HVIT环境中,该价值的一部分与数字化系统提供的信息有关,而另一部分与可以快速,灵活,安全且高效地提供信息数字化技术有关。因此,对数字化组织的信息和技术以及支持IT流程的信息和技术(IT工具)都提出了更高的要求。HVIT工具的一个示例是自动化部署管道,它可以更快、更可靠地将新版本的应用程序交付到生产环境中。 | ||
873 | |||
874 | 信息通常是IT职能中利用率不高的资源。从业人员应该越来越了解自己掌握的数据,并更好地利用它。在HVIT环境中,实时地、有时地创建和使用信息是很常见的。例如,监控工具可在需要时(例如,当告警指示异常情况或已检测到事件时)提供对性能信息的实时访问。然后,可以根据需要将与漫游器(ChatOps)集成协作工具用于交换和获取其他信息。 | ||
875 | |||
876 | 了解信息的流动以及完成工作的方式至关重要,这样人们就可以在需要的时间和地点获得所需的信息,这是将其作为“照常工作”实践的一部分。业务分析部分满足了这一关键需求,但是业务信息管理的领域扩大了范围,包括信息的实际使用。业务信息管理不仅可以确保确定正确的信息需求,而且还可以确保信息在业务流程中得到有效使用。这同样适用于支持IT和服务管理领域中的支持流程的信息。自由流动的信息是高度信任组织的特征。这与“成长文化“是一致的,该特点是高度合作、共担风险、渴望创新以及从失效中学习,这在HVIT组织中经常存在的。 | ||
877 | |||
878 | 集成系统可以避免数据重复(存在不同事实来源的风险)。这也涉及使用不同的工具;例如,开发人员使用一种工具,而运营使用另一种工具,而没有接口和整合。自动添加一个常见的可见标识符(例如冲刺ID,待办事项ID或票证编号)是组合它们的一种方法。例如,在变更通过部署管道时,将用户故事ID添加到变更记录中,是采用“协作和提升可视化程度”以及“优化和自动化”的ITIL指导原则的一种好方法。 | ||
879 | |||
880 | 人工智能(AI)和机器学习的预期极限增长只会对管理良好的信息和知识提出更高的要求。 | ||
881 | |||
882 | |||
883 | ==== ==== | ||
884 | |||
885 | ==== 2.6.6.3 合作伙伴和供应商 ==== | ||
886 | |||
887 | |||
888 | HVIT环境通常广泛使用基于云的基础架构、平台和其他服务。这些功用服务通常由组织按其各自的条款和条件提供。公共云的服务通常是高质量且价格适中,但是个人消费者对提供商上几乎没有影响力。因此,至关重要的是分析依赖关系,并根据合同和SLA采取适当的措施,包括风险共担协议、二级提供商、应急计划以及规避措施。 | ||
889 | |||
890 | 在HVIT 环境中外包工作时,重要的是要考虑外部服务提供商是否以与其客户类似的方式工作,因为很难将具有根本不同工作方式的各方集成到同一价值流中。职能型外包,即将离散的功能(如测试)外包出去,通常比外包整个价值流的有效性低。由于这种约束,IT部门通常与外部人员签约合作,而不是外包工作。 | ||
891 | |||
892 | |||
893 | ==== ==== | ||
894 | |||
895 | ==== 2.6.6.4 价值流和流程 ==== | ||
896 | |||
897 | |||
898 | HVIT环境认识到为每个数字化产品或服务创建唯一的价值流可能更好。这可能不如为多种产品和服务提供服务的标准化集中式单一价值流有效,但是就有效性而言,带来的收益通常会超过成本,因此建议考虑使用这种替代方案。如果考虑使用此方案,组织还应考虑在适当的情况下跨价值流共享工具和最佳实践的方法。在设计独特的价值流时,重要的是要记住可扩展性可能需要某种标准化,因此要谨慎权衡。 | ||
899 | |||
900 | 流程是预先确定的相互关联的活动序列,该活动将输入转换为输出。流程可用于详细说明价值流中的步骤,并且规程和工作说明可提供进一步的详细指导。 | ||
901 | |||
902 | 因为流程是预先确定的,所以它们适用于可预测的情况。当情况无法预测时,流程的应用程序不太可能产生所期望的输出和成果。在这种情况下,基于案例的方法更为有效,因为它使从业者可以自由地应用他们的专业判断,哪些活动是合适的。HVIT环境通常会处理无法预测的复杂系统,因此应保留适用于可能预先确定适当活动顺序的情况。从业人员通常会根据可能起作用的各种活动方式进行思考,并会尝试为手头的任务选择正确的方式。 | ||
903 | |||
904 | |||
905 | === === | ||
906 | |||
907 | === 2.6.7 外在因素 === | ||
908 | |||
909 | |||
910 | 组织对市场、产品和服务以及资源和活动的选择受多种外部因素的影响,这些外部因素可以是政治、经济、社会、技术、法律和环境(PESTLE)。这些都是影响服务管理的四个维度。 | ||
911 | |||
912 | HVIT环境还具有相对较高的易变性、不确定性、复杂性、模糊性,其缩写为“ VUCA”。VUCA提出了严峻的管理挑战。 | ||
913 | |||
914 | 在组织的规划和管理中应予以考虑。组织对VUCA元素的体验程度反映在它是追求更短期还是长期的计划,以及它经历了多少次大规模转型计划。 | ||
915 | |||
916 | 基于外部和内部环境中对参与者的部署的评估,以及尝试影响这些参与者,在更大程度上体验VUCA的组织通常会采用更多的更深层次方法。在这些组织中,重点更多地放在管理当前,而不是制定和遵循路线图,以达到预定的未来状态。 | ||
917 | |||
918 | 管理人员通过施加由外部和内部策略、规则、惩罚等控制方法来约束行为。同时,工作人员确定如何在这些控件的范围内为组织做出贡献。在HVIT组织中,从业人员在组织性能和改进中发挥积极作用。它们还可以挑战刚性较差的边界。从业者有机会通过主动发挥领导作用。 | ||
919 | |||
920 | |||
921 | === === | ||
922 | |||
923 | === 2.6.8 治理与管理 === | ||
924 | |||
925 | |||
926 | 容易混淆术语“ 治理”和“ 管理”以及它们在组织中的应用方式。治理可以应用于最高级别的非执行理事机构,但也可以应用于较低级别,因为这越来越难以区分治理和管理。为了清楚起见,该出版物引用了治理和管理的不同组织实体。治理机构的权限级别高于受治理的组织实体,而管理者是该组织实体的一部分。 | ||
927 | |||
928 | 治理是指导和控制组织的手段。治理机构评估组织的状况、为管理人员设定方向,并监视组织的性能。 | ||
929 | |||
930 | 管理立足于治理。管理者负责规划、建立、组织和改进组织实体。 | ||
931 | |||
932 | 数字化技术责任是数字化驱动组织中数字化业务线中不可或缺的部分,而不是单独的一个单元,如集中式IT服务中心之类的部门(尽管对于诸如电子邮件这样的非差异化IT服务可能存在)。因此,受治理和管理的组织实体既负责数字化技术,又负责数字化产品和服务的使用。这对于组织中的业务和IT的协作是有益的,因为仅需要对业务、IT活动和资源进行协调,而不是将具有不同目标的组织实体分开。因此,数字化技术从业人员与技术水平较低的同事向相同的管理层汇报事务。 | ||
933 | |||
934 | 从业者在治理和管理框架内运行。他们了解适用的约束条件,知道如何在该框架内行动,他们的见识和判断影响他们的行动方式。他们拥有的洞察力越多,他们的判断能力越强,则在相关利益和风险是合理的情况下,从业者越会主动制定规则。这是非常有益的,因为HVIT环境通常是高度不可预测的,这意味着预定的指令既不可行也不理想。 | ||
935 | |||
936 | 因此,HVIT从业者必须对工作进行判断。为了有效地做到这一点,他们必须了解某些约束背后的原因。因此,管理者在HVIT 环境中的主要作用是提供环境并使从业人员可以负责。 | ||
937 | |||
938 | |||
939 | == == | ||
940 | |||
941 | == 2.7 总结 == | ||
942 | |||
943 | |||
944 | 第2章概述了与数字化组织相关的关键概念,包括数字化技术、数字化转型和高速IT。了解这些概念并使它们在组织和生态系统中形成的分类对于数字化转型计划的成功至关重要,因为它们通常涉及许多来自不同组织和背景的人。 | ||
945 | |||
946 | 为了成功实现数字化转型,组织需要(或变得)敏捷、精益、具有弹性并能够持续交付。所有这些属性可以以一种高速的方式实现价值共创:更快、有明确的发展方向。 | ||
947 | |||
948 | 最后,本章从高速角度探讨了ITIL 服务价值系统(SVS)及其组件,并描述了SVS的组件如何在高速环境中协同工作以确保有效、可持续和有弹性的价值共创。 | ||
949 | |||
950 | 总而言之,第二章解释了: | ||
951 | |||
952 | * 数字化转型和高速IT的关键概念 | ||
953 | * 实现高速和数字转换需要实现的目标 | ||
954 | * ITIL 4模型和概念如何帮助成功实现数字化转型 | ||
955 | |||
956 | 第3章将讨论数字化转型的文化方面:高速组织的关键行为模式以及相关文化演进的关键方法。 | ||
957 | |||
958 | |||
959 | |||
960 | [[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%AB%98%E9%80%9FIT%E3%80%8BHVIT/3.%E9%AB%98%E9%80%9FIT%E6%96%87%E5%8C%96/]] [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%AB%98%E9%80%9FIT%E3%80%8BHVIT/1.%E4%BB%8B%E7%BB%8D/]] |