Last modified by superadmin on 2024/04/03, 18:59
From version < 12.1 >
edited by superadmin
on 2021/12/11, 21:13
To version < 23.1
edited by superadmin
on 2024/04/03, 18:59
<
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Content
... ... @@ -1,10 +1,24 @@
1 +
2 +
3 +
4 +[[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC8%E7%AB%A0%20%E6%8A%8A%E5%AE%83%E4%BB%AC%E9%9B%86%E6%88%90%E8%B5%B7%E6%9D%A5/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC6%E7%AB%A0%20%E6%B2%9F%E9%80%9A%E5%92%8C%E7%BB%84%E7%BB%87%E5%8F%98%E9%9D%A9%E7%AE%A1%E7%90%86/]]
5 +
6 +{{box cssClass="floatinginfobox" title="
7 +
8 +**Contents**"}}
9 +{{toc/}}
10 +{{/box}}
11 +
1 1  = 第7章 开发服务价值系统 =
2 2  
14 +
3 3  本章将讨论开发SVS，并强调从面向服务的环境到面向技术的环境的四维模型差异之处。
4 4  
5 5  
18 +
6 6  == 7.1 采用指导原则 ==
7 7  
21 +
8 8  尽管用于指导、计划和改进的基本概念和方法在任何组织中都是相同的，但是它们的关注点和驱动因素取决于组织采用的价值和原则。成功的服务提供商确保聚焦价值遍及每个级别的所有三个活动。
9 9  
10 10  指导、计划和改进应该：
... ... @@ -30,11 +30,18 @@
30 30  [[image:1639217790652-566.png]]
31 31  
32 32  
47 +(% class="wikigeneratedid" %)
48 +== ==
49 +
50 +(% class="wikigeneratedid" %)
51 +== ==
52 +
33 33  == 7.2 服务管理卓越中心 ==
34 34  
35 35  
36 36  === 7.2.1 服务管理战略的战术落地 ===
37 37  
58 +
38 38  服务管理是一组专门的组织功能，用于以服务形式为客户创造价值。因此，面向服务的组织需要定义战略以发展其专业组织能力，然后以适当的战术进行部署。
39 39  
40 40  根据驱动组织的愿景和使命的因素，可以通过许多方式完成指导、计划和改进服务管理。战略管理实践通过分析环境、确定约束条件、同意并建立共享的观点以及将战略转化为战术来帮助确定那些因素。
... ... @@ -50,8 +50,10 @@
50 50  在本章中，我们将讨论重要的注意事项以及开发SVS的相关方法。记住“从你所处的地方开始”的指导性原则是很重要的：转变为面向服务的组织是一个渐进、复杂而值得的努力，组织应该利用其现有的结构和资源，而不是从零开始。
51 51  
52 52  
74 +
53 53  === 7.2.2 ITIL 服务价值链作为运营模式 ===
54 54  
77 +
55 55  服务价值链是用于服务管理的灵活运营模式，允许将六个价值链活动（计划、改进、契动、设计和转换、获取或构建、交付和支持）创造性地组合到价值流中。服务价值链突出显示了价值共同创建中涉及的那些活动，以便了解组织的控制和指导下的功能。价值流中的每一个活动都可以利用不同实践组合的能力，具体取决于背景。
56 56  
57 57  尝试创建统一的运营模式产生了通常面向过程的方法，但这些在面向应用时却失败了。ITIL不是面向过程的：它在策略上解决了价值的问题。这使得基于需求的组织可以采用和适应管理的做法来创建独特的价值流。
... ... @@ -63,6 +63,7 @@
63 63  一些实践可能在组织内制度化，可能包括专门的资源、团队和组织结构；也可能包括共享资源和团队，没有正式的结构。无论哪种方式，都应该确定负责对重要实践持续进行开发及其在整个组织的个人或团体。这些人和团体可以组成一个称为服务管理办公室的团队。
64 64  
65 65  
89 +
66 66  **定义：服务管理办公室（SMO）**
67 67  
68 68  充当服务管理卓越中心的小组或部门，以确保组织的开发和应用管理实践始终如一。
... ... @@ -92,13 +92,22 @@
92 92  [[image:1639217885243-941.png]]
93 93  
94 94  
119 +(% class="wikigeneratedid" %)
120 +== ==
121 +
122 +(% class="wikigeneratedid" %)
123 +== ==
124 +
95 95  == 7.3 SVS中的服务管理四维模型 ==
96 96  
127 +
97 97  组织开发的系统允许他们高效运作并将职能集中在他们定义的使命上。服务管理环境日益增加的复杂性要求IT服务供应商也必须这样做。如果组织的SVS是在考虑到这四个维度的情况下开发的，则将使它能够高水平地执行当前的活动，能对快速的变更做出适当的响应，并在必要时进行实质性的转换。
98 98  
99 99  
131 +
100 100  === 7.3.1 SVS中的组织和人员 ===
101 101  
134 +
102 102  服务供应商组织经常与其他组织互动。组织和人员维度可确保将这些人为因素整合到SVS中时，对组织的使命做出适当的贡献。
103 103  
104 104  组织的愿景、使命、战略和目标一旦定义后，就会出现支持整体组织意图的结构、流程和角色。这些结构和有经验的员工与信息和技术交互，参与价值流和流程，并以合作伙伴和供应商的形式与其他组织和人员合作。
... ... @@ -106,8 +106,10 @@
106 106  确定组织的模型后，应将容量和劳动力的能力映射到该组织上。人员是任何SVS的关键要素且对于建立和培养所需的以服务为导向的文化是必不可少的。领导者在传达组织的指导和计划方面起着重要的作用，以便每个人都能理解并为自己所做的贡献感到自豪。
107 107  
108 108  
142 +
109 109  ==== 7.3.1.1 不同组织结构的影响 ====
110 110  
145 +
111 111  项目开始时的一个重要的早期决定是如何将人员分组，以交付和改进产品和服务。现代思想提出组织结构是新兴的和自治的：具有共同目标的自然成果。然而，并非所有团队都能以这种方式进行自组织。
112 112  
113 113  可以采用几种组织结构。有些结构是分层的；其他类似网络或矩阵型。许多组织根据员工的专业活动、技能、专业知识和资源将其分为几组。尽管很常见，但是这种方法会导致竖井式的团队，他们对其他团队做什么或如何做的知之甚少。依赖于跨职能工作的结构可以帮助团队保持对他们负责的产品和/或服务的共同关注，但是它们也可能使全面的产品组合概述难以产生，并可能导致重复的工作，甚至重复的服务。
... ... @@ -115,6 +115,7 @@
115 115  选择支持SVS的组织结构时，考虑诸如类型、规模、专业化和控制范围等因素是很重要的。至关重要的是组织需要确定哪种因素最能支持其产品和服务。精益技术应与持续改进实践相结合，以评估成功因素，并了解价值链和相关价值流的要求，以减少浪费。
116 116  
117 117  
153 +
118 118  ==== 7.3.1.2 角色与工作 ====
119 119  
120 120  
... ... @@ -136,17 +136,20 @@
136 136  角色很少能清晰地映射到工作上。组织有责任决定任务如何分配、分发及管理方式，以确保生产出高质量的产品和服务。
137 137  
138 138  
175 +
139 139  ==== 7.3.1.3 RACI职能矩阵和责任分配 ====
140 140  
178 +
141 141  职责分配矩阵（或RACI图表）是用于识别和记录角色和职责的工具，如表7.1所述。
142 142  
143 143  表7.1 RACI职能矩阵图表的角色及描述
144 144  
145 -|**缩写**|**权威**|**描述**
146 -|R|谁执行|担任此角色的人员执行活动。每个活动可能有不止一个负责人。
147 -|A|谁审批|此角色的人员是最终决策者，并对活动的的成果负责。
148 -|C|咨询谁|此角色中的人员根据其对活动的或其对未来项目的潜在影响的专业知识提供意见。
149 -|I|知会谁|此角色中的人员会定期更新有关活动的信息，但无需更多参与。
183 +(% style="width:484px" %)
184 +|(% style="width:74px" %)**缩写**|(% style="width:89px" %)**权威**|(% style="width:320px" %)**描述**
185 +|(% style="width:74px" %)R|(% style="width:89px" %)谁执行|(% style="width:320px" %)担任此角色的人员执行活动。每个活动可能有不止一个负责人。
186 +|(% style="width:74px" %)A|(% style="width:89px" %)谁审批|(% style="width:320px" %)此角色的人员是最终决策者，并对活动的的成果负责。
187 +|(% style="width:74px" %)C|(% style="width:89px" %)咨询谁|(% style="width:320px" %)此角色中的人员根据其对活动的或其对未来项目的潜在影响的专业知识提供意见。
188 +|(% style="width:74px" %)I|(% style="width:89px" %)知会谁|(% style="width:320px" %)此角色中的人员会定期更新有关活动的信息，但无需更多参与。
150 150  
151 151  RACI职能矩阵图表提供了一种紧凑、简明、直接的方法来跟踪谁在做什么，从而实现快速、自信的决策。无论组织是否倾向于利用RACI职能矩阵图表或其他方法，都不要缺失角色的分配，尤其是负责任的角色，以留给机会或延迟决策。
152 152  
... ... @@ -153,8 +153,10 @@
153 153  在SVS中，责任分配尤其重要。在一个复杂的组织中如果没有明确地为其主要活动和服务分配责任，那么可能会忽略问题，并且质量会受到影响。
154 154  
155 155  
195 +
156 156  ==== 7.3.1.4 服务所有权 ====
157 157  
198 +
158 158  服务供应商组织对确保正确管理和改善其服务具有浓厚的兴趣。有些组织可能会选择为其产品组合中的每个服务分配一个所有者，但每一个组织都应该为其最重要的服务分配所有者。确定是否应为服务分配所有者的一种方法是，根据以下因素考虑其重要性：
159 159  
160 160  ● 有多少客户使用服务
... ... @@ -165,7 +165,7 @@
165 165  
166 166  ● 服务需要多少维护或关注才能保持正常
167 167  
168 -● 服务对服务供应商及其客户的重要性是否在增加。
209 +● 服务对服务供应商及其客户的重要性是否在增加。                           
169 169  
170 170  根据服务供应商的不同，可能还要考虑其他因素。
171 171  
... ... @@ -176,18 +176,21 @@
176 176  所有者不仅应为自己拥有的服务负责，而且还应被赋予足够的权限以使他们真正有所作为。在没有相称权限的情况下，为某人分配责任将不会产生预期的结果。
177 177  
178 178  
220 +
179 179  ==== 7.3.1.5 角色和能力 ====
180 180  
223 +
181 181  角色的结构和命名因组织而异，并且在ITIL中定义的角色不是强制性的。ITIL 实践指南使用基于表7.2中所示模型的能力概要文件来描述每个角色。
182 182  
183 183  表7.2能力代码与类型
184 184  
185 -|**能力代码**|**能力简介（活动与技能）**
186 -|L|Leader领导：决策、授权、监督其他活动，提供激励和动力，并评估结果。
187 -|A|Administrator管理员：分配任务并确定优先级、保存记录、持续报告，并启动基本改进。
188 -|C|Coordnator协调者/沟通者：协调多方，维护利益相关者之间的沟通，并开展宣传活动。
189 -|M|Methods and techniques expert方法和技术专家：设计和实施工作技巧，文件化步骤，流程咨询、工作分析和持续改进。
190 -|T|Technical expert技术专家：提供技术（IT）专业知识并执行基于专家经验的作业。
228 +(% style="width:410px" %)
229 +|(% style="width:92px" %)**能力代码**|(% style="width:316px" %)**能力简介（活动与技能）**
230 +|(% style="width:92px" %)L|(% style="width:316px" %)Leader领导：决策、授权、监督其他活动，提供激励和动力，并评估结果。
231 +|(% style="width:92px" %)A|(% style="width:316px" %)Administrator管理员：分配任务并确定优先级、保存记录、持续报告，并启动基本改进。
232 +|(% style="width:92px" %)C|(% style="width:316px" %)Coordnator协调者/沟通者：协调多方，维护利益相关者之间的沟通，并开展宣传活动。
233 +|(% style="width:92px" %)M|(% style="width:316px" %)Methods and techniques expert方法和技术专家：设计和实施工作技巧，文件化步骤，流程咨询、工作分析和持续改进。
234 +|(% style="width:92px" %)T|(% style="width:316px" %)Technical expert技术专家：提供技术（IT）专业知识并执行基于专家经验的作业。
191 191  
192 192  成功执行活动需要综合能力。但是，对于一项活动某些能力比其他能力更为重要。能力在能力代码中的位置说明了其相对重要性。例如，在CAT的能力概要中，沟通和协调技能非常重要，管理技能有些重要，而技术知识对所描述的活动有用，但不那么重要。
193 193  
... ... @@ -221,8 +221,10 @@
221 221  **● 发展创新**   即使在内部服务管理组织里，企业和企业家的思维方式正日益成为一种要求。这种思维方式对于确定新的工作方式，提供服务和解决问题是必要的，可能涉及运用新技术，创造性思维或客户交互。
222 222  
223 223  
268 +
224 224  ==== 7.3.1.6 建立跨越价值链的有效接口 ====
225 225  
271 +
226 226  在整个服务价值链和价值流中，人们可以在协作和协调工作中做出最大贡献。在建立参与价值链活动的组织和人员之间的接口时，“ 协作和提升可视化程度”和“ 通盘思考和工作”的指导原则很重要。
227 227  
228 228  在组织和人员的背景中，与沟通和OCM有关的原理、方法和技术有助于开始建立接口。价值链和各自的价值流应进行检查，考虑这些接口如何能使人们能够一起工作。重要的是要确保每个人都在适当的时间访问相关的知识、信息和人员。随着时间的推移，协作和合作的最大障碍得以消除，组织将不得不更加仔细地检查其价值流图以发现改进之处。
... ... @@ -248,8 +248,10 @@
248 248  **● 注意权衡**      在大多数情况下，有几种方法可以完成任务。重要的是要权衡每种方法的优点和缺点，以及它们的影响如何在整个系统中传播。
249 249  
250 250  
297 +
251 251  ==== 7.3.1.7 服务供应商文化 ====
252 252  
300 +
253 253  文化可以描述为一群人共享的一套价值观，包括对人们应该如何行事、想法、信念和实践的期望。所有组织都有文化，文化使人类的行为可预测。
254 254  
255 255  组织文化的重要性经常被大大低估。要了解组织的文化及其对服务管理的准备情况，请务必提出以下问题：
... ... @@ -284,15 +284,22 @@
284 284  [[image:1639218088734-110.png]]
285 285  
286 286  
335 +
336 +(% class="wikigeneratedid" %)
337 +=== ===
338 +
287 287  === 7.3.2 SVS中的合作伙伴和供应商 ===
288 288  
341 +
289 289  与关键合作伙伴和供应商的关系应包含共同创造价值的概念。组织及其供应商都应该希望对方成功。为此，这段关系对双方都必须有价值。
290 290  
291 291  服务供应商应仔细考虑如何以及何时向合作伙伴或供应商申请契动，并应在提供服务的同时努力管理与供应商的关系。
292 292  
293 293  
347 +
294 294  ==== 7.3.2.1 与供应商和合作伙伴的服务关系 ====
295 295  
350 +
296 296  在服务关系中，组织将扮演服务供应商或服务消费者的角色。这两个角色不是唯一的：组织通常在随时提供，也在随时使用许多服务。图片7.1中显示了组织在角色之间使用转换的方式。
297 297  
298 298  (% style="text-align:center" %)
... ... @@ -308,28 +308,498 @@
308 308  表7.3三种原型服务关系类型
309 309  
310 310  
366 +[[image:1639218161001-613.png||style="float:left"]]
367 +
368 +[[image:1641536617924-170.png]]
369 +
370 + 基于组织定义的战略，一种类型的关系可能比其他类型的关系更受欢迎。
371 +
372 +
373 +(% class="wikigeneratedid" %)
374 +==== ====
375 +
376 +==== 7.3.2.2 基本关系 ====
377 +
378 +
379 +在IT和服务管理中，硬件供应的合同是这些安排中最直接的：成本设定、交付时间的协商、功用和功效的明确表达，并且很容易根据合同的预期报告性能。这种关系几乎没有歧义。货品要么按时交付并按预期执行，要么没有。如果没有达到预期，将会有合同要求和处罚措施规定补救行动。
380 +
381 +
382 +
383 +==== 7.3.2.3 合作关系 ====
384 +
385 +
386 +服务交付合同（例如平台（或技术）即服务）允许进行解释，因此在各方之间会产生误解。重要的是要了解各方对价值的定义，一个伙伴的责任在哪里终止，另一伙伴的责任在哪里开始，以及购买了什么级别的服务。
387 +
388 +例如，组织是否在平台上购买了专有租赁，或者是以共享服务的形式购买的？如果接受了共享租用安排，则组织将无法命令中断窗口或坚持更改共享基础设施组件，因为任何更改都需要使平台上的所有租户受益，或者至少没有负面的影响。
389 +
390 +组织是否同意“黑匣子”服务？如果是这样，则供应商必须提供满足合同要求的服务，但不需要详细说明那些可能具有商业敏感性的基础架构。合作伙伴有责任确保服务满足合同要求，但无需解释如何实现。
391 +
392 +
393 +
394 +==== 7.3.2.4 服务合作伙伴关系 ====
395 +
396 +
397 +在这种类型的服务关系中，合作伙伴双方都有共同的目标，并将共同努力为客户交付价值。员工入职就是一个很好的例子，IT、人力资源和设施应进行协调以向新员工提供高效的体验。
398 +
399 +这种协调具有挑战性。实际上，每个组织中都有许多事例表明未实现目标时会发生什么。例如，如果HR未将正确的信息提交给IT，则可能无法及时交付所需的硬件和软件。这种类型的流程的适当自动化将解决许多这类问题。
400 +
401 +
402 +
403 +==== 7.3.2.5 建立跨组织边界的有效接口 ====
404 +
405 +
406 +伙伴关系，无论是内部的还是外部的，都必须具有可以跨越内部和外部边界的完善有效的接口。沟通渠道必须开放，并为定期讨论和补救问题提供机会。
407 +
408 +包括明确的升级通道和联系点的协作流程对于维持健康的工作关系至关重要。这些流程应该很简单；如果很复杂，则很可能会被规避。在未及早建立沟通渠道的环境中，任何人都没有意识到发生了什么之前，关系可能会遭受无法挽回的损害。良好的沟通和在困难的情况下从不推卸责任是解决问题的最佳方法。
409 +
410 +
411 +
412 +==== 7.3.2.6 服务集成和管理 ====
413 +
414 +
415 +使用服务集成和管理方法来管理具有多个合作伙伴和供应商的复杂生态系统是一种日益普遍和有效的方法，其中建立了独立的服务集成商功能。服务集成旨在协调内部和外部服务供应商，以为组织及其客户提供具有凝聚力的服务。
416 +
417 +服务集成有四种主要模型。它们是：
418 +
419 +**● 将组织保留为服务集成和管理**  组织管理所有供应商，并自行协调服务集成和管理功能。
420 +
421 +**● 单个供应商**     供应商提供所有服务以及服务集成和管理功能。
422 +
423 +**● 服务守护者**     除了管理其他供应商外，供应商还提供服务集成和管理功能和一个或多个交付功能。
424 +
425 +**● 独立的服务集成商**       供应商提供服务集成和管理功能并管理其他供应商，即使该供应商未向组织提供任何服务。
426 +
427 +服务集成不是实践，但是它借鉴了其他几种实践来提供职能，其目的是最大程度地减少多源方法固有的风险。
428 +
429 +为了考虑服务集成，组织应该评估其内部技能和组织成熟度，以及他们将管理的环境复杂性。
430 +
431 +图片7.2显示了服务集成模型的基本轮廓。
432 +
311 311  (% style="text-align:center" %)
312 -[[image:1639218161001-613.png]]
434 +[[image:1639227400393-817.png]]
313 313  
314 -(% style="width:1061px" %)
315 -|(% style="width:89px" %) |(% style="width:264px" %)**基本关系**|(% style="width:408px" %)**合作关系**|(% style="width:299px" %)**服务合作伙伴**
316 -|(% style="width:89px" %)典型焦点|(% style="width:264px" %)支持与效率|(% style="width:408px" %)改进与效果|(% style="width:299px" %)创新与成长
317 -|(% style="width:89px" %)关系中典型的组织级别|(% style="width:264px" %)运营|(% style="width:408px" %)运营和战术|(% style="width:299px" %)运营，战术和战略
318 -|(% style="width:89px" %)关系的典型水平成熟度|(% style="width:264px" %)发起人或赞助人, 接单者|(% style="width:408px" %)服务供应商，值得信赖的顾问|(% style="width:299px" %)战略合作伙伴
319 -|(% style="width:89px" %)典型的服务类型|(% style="width:264px" %)商业现货服务，开箱即用的服务，高度标准化的商品服务或商品供应|(% style="width:408px" %)必须配置或定制以满足服务消费者需求|(% style="width:299px" %)具有独特价值主张自定义或定制服务
320 -|(% style="width:89px" %)协议的典型类型|(% style="width:264px" %)标准合同，SLA和基于经验的协议，主要针对大众市场|(% style="width:408px" %)高级SLA，基于体验的协议或基于成果的协议|(% style="width:299px" %)(((
321 -定制合同，基于成果的协议或无协议。
436 +图片7.2 服务集成模型
322 322  
323 -敏捷环境中、实验和假设测试。
438 +
439 +[[image:1639227418795-695.png]]
440 +
441 +
442 +
443 +=== 7.3.3 SVS中的价值流和流程 ===
444 +
445 +
446 +通过使用价值流来组织和改进服务管理的工作。这些构造定义了做什么以及如何做，并根据需要和情况进行了适当的调整。
447 +
448 +组织应该检查他们如何执行工作，并映射他们可以识别的所有价值流。这将使他们能够分析其当前状态，并确定工作流和非增值活动（即浪费）的任何障碍。应消除浪费的活动以提高生产效率。
449 +
450 +
451 +
452 +==== 7.3.3.1 聚焦价值流 ====
453 +
454 +
455 +价值流是向客户交付价值的工具。价值流包含将价值添加到服务价值链中正在处理的工作单元中的步骤，以将任何需求或机会转化有价值的结果。每个步骤均以定义的方式执行，并使用一种或多种实践。
456 +
457 +ITIL，尤其是“ 聚焦价值”的指导原则，旨在不断改善每个步骤的执行方式，无论是单独执行还是作为一系列要优化的步骤。当工作执行不正确或未创建所需的价值时，原因很可能是价值流的问题造成的。
458 +
459 +关注价值流提供了一种方法，可以识别出对特定价值流中涉及的工作流和实践的可能改进。这结合了精益的流程优化和消除浪费的方法，并带有“聚焦价值” “通盘思考和工作”和“基于反馈迭代推进”之类的指导原则。
460 +
461 +
462 +
463 +==== 7.3.3.2 价值流和实践之间的关系 ====
464 +
465 +
466 +许多服务管理指南，包括适用的ISO标准，都是面向流程的。流程是组织成功的基础，而作为四个维度一部分反映了这一点。流程支持通过价值流进行价值共创，但不应关注单一的流程或以流程本身为最终目标。
467 +
468 +但是，如果组织花太多时间专注于流程，则它对其产品和服务或为其客户创造价值就不能给予适当的关注了。ITIL 4注重价值流，以价值为导向。
469 +
470 +组织必须发展并保持向服务消费者提供服务的能力；这项努力得到了ITIL实践的支持。例如，当组织需要发展和维护其理解IT资产的能力时，它会将重点放在开发IT资产管理实践上，从而解决所有服务管理四个维度的问题。
471 +
472 +(% style="text-align:center" %)
473 +[[image:1639227473841-365.png]]
474 +
475 +图片7.3 价值流与实践之间的关系
476 +
477 +
478 +服务供应商使用价值链活动作为定义其价值流的构建块。随着每个价值流的实现，相关的实践也对其有所贡献。有些参与价值流的活动，其他的则通过提供信息来支持价值流中的决策做出贡献。图片7.3显示了价值流和相关实践之间的关系。
479 +
480 +价值流组织了为客户创建价值的过程，实践是组织将其特定资源应用于任务的方式。
481 +
482 +
483 +
484 +==== 7.3.3.3 价值流和流程之间的关系 ====
485 +
486 +
487 +价值流和流程不是一回事，但是它们有很多共同点。价值流和流程都与活动和工作流有关：它们帮助组织了解发生了什么以及如何发生。价值流图记录关键信息和资源在整个工作流中的移动，并说明可能在何处发现潜在的浪费。尽管并非每个组织都以图形方式记录其流程，但也可以映射流程。流程和价值流都定义了活动、输入和输出。
488 +
489 +价值流和流程之间的主要区别在于它们的重点和用法。这些差异可能是很细微的，但却是很重要的。几乎所有将输入转化为输出的相互关联的活动都可以视为一个流程。但是，价值流主要侧重于从需求或机会到价值的活动流（例如，从用户致电地板公司并询问如何重新装修木地板到用户的木地板已经完成重新装修为止的活动流，肯定是价值流）。例如公司在每月结束时生成当月财务报表的活动，则将其视为价值流就不合适了。每月进行财务计算的工作是流程。
490 +
491 +价值流图和流程文档的使用方式也非常不同。价值流图通常以视觉方式呈现，并用于整体查看端到端工作流，显示如何改进或消除单个步骤以及如何改进步骤之间的区域。
492 +
493 +流程图或其他流程文档通常更适合查找有关每个步骤执行方式的问题，但这有时会导致局部优化，而不是整体改进。
494 +
495 +
496 +
497 +==== 7.3.3.4 设计工作流 ====
498 +
499 +
500 +在为流程或价值流设计工作流时，需要回答的问题包括：
501 +
502 +● 什么会导致工作开始？
503 +
504 +● 创建定义的输出或结果需要什么信息，而无论是从外部利益干系人还是从内部获得？这些信息什么时候可用？信息将采用哪种格式？
505 +
506 +● 为了实现所需的输出，需要执行哪些步骤？哪些步骤可以并行执行，哪些步骤具有先决步骤、活动或子流程？每个步骤需要多长时间？
507 +
508 +● 工作流创建了哪些制品？
509 +
510 +● 每个步骤为服务供应商、服务消费者或其他利益干系人创造了什么价值？
511 +
512 +● 流程或价值流必须遵循哪些策略？
513 +
514 +● 将对工作流的哪些方面进行度量？数据将如何格式化、存储和使用？
515 +
516 +
517 +
518 +==== 7.3.3.5 高效设计的注意事项 ====
519 +
520 +
521 +流程设计通常借助于模板和工具包，这些模板和工具包可以在管理文献中找到，由顾问和培训师提供，或者由供应商以开箱即用的工具功能记录下来。这些通常是不断改进SVS及其资源的良好起点。此类文献应该根据服务组织的需求进行评估，调整文献或功能的机会或要求，以便可以尽快被识别和实施。
522 +
523 +已定义的工作方式指南对于意外或不可预测的事件可能会很有用；例如，如果团队的主要工具不再可用，该团队将如何记录事件？
524 +
525 +可以为任何工作流和活动定义几个重要的指标度量。这些在表7.4中概述，并在图片7.4中显示。
526 +
527 +表7.4工作流程指标度量
528 +
529 +|**术语**|**描述**
530 +|节点周期|完成离散工作单元，将输入转换为输出所需的时间。例如，如果需要五分钟来填写新的事件表单，那么节点周期就是五分钟。
531 +|等待时间|工作开始之前，离散工作单元在队列中等待的时间。例如，如果事件工单在开始工作前平均等待了四个小时，则等待时间为四个小时。
532 +|前置时间|节点周期和等待时间的总和。前置时间表示完成一个离散工作单元所需的总时间，从它进入流程队列到流程结束。
533 +|流程队列|等待流程操作的离散工作单元的数量。
534 +|在制品（WIP）|正在操作但尚未完成的离散工作单元的数量。
535 +|吞吐量|工作进出系统的速率。
536 +
537 +这些指标度量源自利特尔定律，有关更多信息，请参见运营管理或排队理论文献。利特尔定律可以简单地表示为：
538 +
539 +在制品= 吞吐量× 前置时间
540 +
541 +
542 +(% style="text-align:center" %)
543 +[[image:1639227556812-796.png]]
544 +
545 +图片7.4 流程时序
546 +
547 +在设计流程时，利特尔定律建议考虑以下注意事项：
548 +
549 +● 工作转换的次数应最小化。传输创建队列，队列会增加等待时间，从而增加了前置时间。这可以通过增加自动化程度、培训人员或重组团队来实现。
550 +
551 +● 吞吐量尤其是在外部事件和触发器的情况下通常不受服务供应商的控制，但可以使用数学和统计模型对其进行估算。
552 +
553 +● 等待时间可以表示为节点周期的职能。对于新的工作单元，它是节点周期乘系统中的工作单元。
554 +
555 +● 根据工作的性质，可以假定节点周期是固定的。
556 +
557 +● 为了稳定节点周期，可能有必要限制WIP。这是看板的前提，它能在吞吐量可预测的环境中良好工作。
558 +
559 +
560 +
561 +==== 7.3.3.6 约束理论 ====
562 +
563 +
564 +约束理论提供了另一种查看流程进度并确定瓶颈在哪里约束价值的方法。该理论指出，“任何系统的吞吐量都是由一个约束决定的”。增加流程的价值依赖于识别和消除这些关键约束。
565 +
566 +Eliyahu M. Goldratt（1984）描述了应用此理论的五个步骤：
567 +
568 +● 确定流程的约束。
569 +
570 +● 确定如何最好地利用流程的约束。
571 +
572 +● 使其他所有内容服从上述决定。
573 +
574 +● 评估流程的约束。
575 +
576 +● 消除约束并重新评估流程。
577 +
578 +
579 +
580 +==== 7.3.3.7 管理工作的看板技术 ====
581 +
582 +
583 +那些难以监督、确定优先级和管理工作的人常常发现看板很有用。人们在计划工作时可能会遇到困难，因为他们无法可视化所涉及的步骤。看板通过促进流程工作流的完全可视化来解决此问题。板面分为多个流程阶段，工作项（看板卡）放在上面，并随着阶段的进进展而移动。看板用于：
584 +
585 +● 可视化流程并将信息传递给团队
586 +
587 +● 限制在制品的数量
588 +
589 +● 管理和度量工作流。
590 +
591 +看板既简单又没有风险。它不需要对当前的流程进行任何更改，可以很好地扩展，并且不会产生额外的成本。图7.5显示了一个看板的示例。
592 +
593 +尝试看板方法的最简单方法是在白板上创建一个简单的看板，并将写在卡片（或便签）上的任务放在上面。看板卡应包含任务的名称，截止日期，完整性定义和指定的执行者。通常使用彩色卡片来指示特定类型的任务。
594 +
595 +设置在制品限制的目的是确保在一定时间内完成最大数量的任务。在制品限制可促进重点，消除浪费的多任务处理，并更容易发现瓶颈。
596 +
597 +
598 +(% style="text-align:center" %)
599 +[[image:1639227612623-124.png]]
600 +
601 +图片7.5 看板的示例
602 +
603 +改编自Mitchell（2012）：知识共享CC0 1.0通用公众域奉献的看板示例。
604 +
605 +
606 +
607 +(% style="text-align:center" %)
608 +[[image:1639227653882-224.png]]
609 +
610 +
611 +(% class="wikigeneratedid" %)
612 +=== ===
613 +
614 +(% class="wikigeneratedid" %)
615 +=== ===
616 +
617 +=== 7.3.4 SVS中的信息和技术 ===
618 +
619 +
620 +SVS的吞吐量，即从需求转变到价值的能力, 可以被技术决策和相关信息的管理所增强或限制。对最佳技术的渴望和大量可用的技术解决方案常常导致工具链断开。在计划如何精简该工具链时，至关重要的是要考虑信息技术的当前状态和需求，以及其他三个方面的信息和需求。组织不以这种方式考虑所有四个方面，可能会有很高比例的重叠技术，而这些技术的开发能力不足。应该利用治理和控件来防止断裂的工具链发展或恶化。
621 +
622 +选择和实施工具是一项投资。一旦采用了一项技术，就必须建立维护并最大化其收益的机制。实施一项新技术将会引入新的价值流进行管理。通常，一项技术不能应用于多个项目时，技术变得闲置无用，成为孤立的和/或已过时的解决方案。
623 +
624 +表7.5概述了组织可以利用的各种技术。
625 +
626 +表7.5可用技术
627 +
628 +(% style="width:775px" %)
629 +|(% style="width:85px" %)机器人|(% style="width:688px" %)(((
630 +机器人可用于模拟人类通过屏幕和应用程序执行的活动，以一致且可预测的方式捕获，解释和处理流程事务，触发响应以及创建和操作数据。
631 +
632 +这些机器人通常成本较低，易于实施。它们不需要对现有系统重新开发，也不需要在现有系统内进行复杂的集成。潜在的好处是显而易见的，因为它们允许以经济高效的方式实施一致、可靠和可预测的流程。一致性可以减少关键流程中的错误，增加收入，并提高客户服务和保留率。
633 +
634 +通常，机器人流程自动化技术有以下三种类型：
635 +
636 +● 流程自动化 这关注于依赖结构化数据的自动化任务，例如电子表格。
637 +
638 +● 增强和智能的流程自动化 此功能主要在非结构化数据作为输入的情况下进行；例如电子邮件和文档。这种类型的自动化可以从经验中学习，并将知识应用于流程的不同要求。
639 +
640 +● 认知平台 他们可以理解客户的查询并执行以前需要人工干预的任务。
324 324  )))
325 -|(% style="width:89px" %)例子|(% style="width:264px" %)(((
326 -正如服务供应商所期望的那样，服务消费者非常清楚地表达他们的期望。
642 +|(% style="width:85px" %)人工智能|(% style="width:688px" %)(((
643 +认知技术越来越多的应用在服务生命周期所有阶段的自动化，并为客户和为他们提供服务的人们增强服务体验。它在相关和支持领域也越来越普遍，例如软件开发和运营。
327 327  
328 -例如，向独立的外部服务消费者的广泛群体提供标准化服务。移动运营商、宽带服务供应商和运输公司通常采用这种方式。
329 -)))|(% style="width:408px" %)根据服务供应商和服务消费者之间的关系，服务供应商可能难以完全理解服务消费者希望实现的结果。在某些情况下，他们会共同定义所需的结果。例如，内部IT或人事部门的客户关系经理会定期与客户交谈并讨论他们的需求和期望。|(% style="width:299px" %)(((
330 -基于已根据客户指定要求计划和构建的服务提供和产品的服务。
645 +尽管人工智能技术已经存在了数十年，但新一代基于云的工具已经显著提高了人们对它的关注和使用。供应商现在提供了许多AI工具作为公有云服务。这极大地提高了人工智能工具的可访问性，解决方案以前可能需要复杂技术和大量财务支出，现在可以按需供应，成本可能更低。
646 +)))
647 +|(% style="width:85px" %)AIOps平台|(% style="width:688px" %)(((
648 +在IT运维领域中结合了大数据、分析和机器学习的实践。
331 331  
332 -服务消费者和服务供应商在共享团队中共同创建生产的敏捷产品开发。
650 +与其让孤立的团队各自监控基础设施的各个部分，不如将所有重要的监控数据集中在一个地方，并利用机器学习来识别模式和检测异常。这可以帮助IT部门更快地识别和解决事件，并在潜在故障发生之前发现它们。它还可以用于自动化处理常规任务。
651 +
652 +AIOps旨在将人工智能引入IT运营，以应对基础设施持续发展中的现代趋势所带来的挑战，例如软件定义系统的增长。这些新技术的影响，例如，基础设施重新配置和改造的速度加快需要更多的自动化和动态的管理技术，这可能会对数字化服务产生重大影响。
653 +
654 +AIOps利用数据平台和机器学习，收集观察性数据（例如事件、日志文件和操作指标度量）和参与数据（例如客户请求和服务台工单）。它通过对该数据应用认知或算法处理来得出洞察力。
655 +
656 +这些洞察力可用于驱动部分或全部范围的通用输出，例如：
657 +
658 +● 问题检测和预测，帮助服务组织更快地对事件做出响应
659 +
660 +● 主动进行系统维护和调整，从而减少了人工和潜在错误。
661 +
662 +● 阈值分析，可以更准确地了解系统的正常运维范围。
663 +
664 +一些组织还开始在IT运维以外使用AIOps，以向业务经理提供有关IT对业务影响的实时洞察，从而使他们随时了解最新情况，并使能够根据相关的数据做出决策。
333 333  )))
666 +|(% style="width:85px" %)机器学习|(% style="width:688px" %)(((
667 +AI的一种应用形式。它基于系统响应数据原则，并且随着系统不断接触到更多的数据时，相应地调整它们的操作和输出。在使用机器学习作为服务基础的情况下，这本质上意味着它成为决策的基础，而不是由人工服务设计者创建的指令所定义的路径。
334 334  
335 -
669 +随着随着任务复杂性的增加，将机器学习映射到该任务变得更加困难。机器学习通常最适合解决特定问题。例如，它可以有效地用于在支持记录上做出有关数据分类的决策。
670 +)))
671 +|(% style="width:85px" %)集成工具集|(% style="width:688px" %)(((
672 +这些工具集可自动执行记录和工作流管理，并充当参与和通讯工具。许多旨在支持服务管理的整体信息模型。这些工具集中的大多数都是为自动化ITIL 服务管理实践而设计的，并且它们也在不断发展以采用新技术。
673 +
674 +这些工具集最常用的功能是记录系统和参与系统。这些用于针对业务和技术基础设施的项目和领域（包括人员、IT、部门），服务和职能领域提出、分类、划分优先级、升级和解决问题、请求和变更。这还包括对交付和实现、批准、升级和消费期望的实时管理，以及库存、财务和生命周期管理的其他管理功能。这些工具集的价值在于管理工作量的实时动态能力，可以管理从小而简单到大而复杂的工作量，并提供有关性能、趋势、改进、成本和风险的报告和业务分析。此外，工具集还提供有关工作交付和“ 服务”资产和资源管理的责任和审计跟踪。规模和声誉各异的组织以某种形式使用这些工具集来优化常规记录保存，并展示了一定程度的责任心、一致性和控制力。但是，大多数组织仅使用工具集中的基本功能（事件管理、服务级别管理、库存管理），而忽略了跨流程进行多功能集成的机会。因此，很少利用工具集提供的端到端价值流集成的机会。但是，随着新的挑战和机遇的出现，对使用此功能和集成的需求也越来越大。
675 +)))
676 +
677 +本节的其余部分将回顾服务管理套件和新兴技术的价值，以及确保它们交付的信息具有可扩展性，满足利益干系人的需求并向他们交付价值的重要性。
678 +
679 +
680 +
681 +==== 7.3.4.1 服务管理工具套件 ====
682 +
683 +
684 +服务管理工具套件是一个包含多个应用程序的平台，通常从IT和服务管理扩展到人力资源、财务和设施部门以及运营业务，并最终成为为客户创造价值所需的其他能力。价值流和价值链贯穿多个ITIL实践，要求信息是可用的和可共享的。如果有多个系统来管理这项工作，那么集成可以减少系统之间切换所花费的时间。
685 +
686 +例如，IT资产通常是通过服务管理工具套件中的服务请求目录来申请的。但是，这些目录很少与采购系统连接。取而代之的是，有人手动将来自服务管理套件的信息输入到采购系统中。这会影响生产效率，准确性和资产的交付时间。
687 +
688 +
689 +**关键信息**
690 +
691 +重要的是，工具应支持这些实践，而不是命令他们。但是，可能有必要在工具和/或实践中做出一些折衷。如果需要折衷，则重要的是评估工具定制对于与实践一致是否至关重要或实践修改是否可以接受。
692 +
693 +应始终避免对开箱即用的产品进行广泛的定制。定制可能会限制升级的可能性，将供应商从支持义务中释放出来，并降低对核心功能的外部培训的价值。
694 +
695 +
696 +对服务管理工具套件的评估应该首先了解组织的独特需求。需要定义解决方案的短期和长期目标。所需工具的类型取决于对IT服务的业务需求，并在某种程度上取决于组织的规模。
697 +
698 +评估活动包括：
699 +
700 +● 确定需要，包括：
701 +
702 +● 短期和长期目标
703 +
704 +● 职能型需要
705 +
706 +● 非职能型需要
707 +
708 +● 通过以下方式确定候选人：
709 +
710 +● 评审组织的当前工具清单，以了解什么是适当的并定义任何差距
711 +
712 +● 评审市场调研，例如用于ITSM套件的Gartner魔力象限和Forrester Wave方法论
713 +
714 +● 在行业活动和用户组中与客户建立联系
715 +
716 +● 按重要性对需要进行排名；例如，通过使用MoSCoW方法
717 +
718 +● 通过以下方式评估选项：
719 +
720 +● 安排产品演示
721 +
722 +● 验证可以满足100％的强制性需要
723 +
724 +● 拜访其他客户并致电推荐人
725 +
726 +● 候选名单的选择依据：
727 +
728 +● 删除任何不符合强制性要求的产品
729 +
730 +● 请求提案，从而了解许可、订阅和维护的费用
731 +
732 +● 评分/排名，考虑是否：
733 +
734 +● 价值或概念的证明是必要的
735 +
736 +● 一个选项可以满足所有职能型和非职能型需求的80％或更高
737 +
738 +● 一个支持短期和长期目标的选项
739 +
740 +● 选择。
741 +
742 +
743 +一些评估注意事项包括：
744 +
745 +● 可维护性
746 +
747 +● 易于实施和持续的管理
748 +
749 +● 数据的结构和报告能力
750 +
751 +● 集成能力和接口
752 +
753 +● 多租户或其他域分离选项
754 +
755 +● 开放标准，社区开发
756 +
757 +● 易访问性需求
758 +
759 +● 移动性和浏览器支持
760 +
761 +● 数据备份，控制和安全
762 +
763 +● 可扩展性
764 +
765 +● 安全和访问控制
766 +
767 +● 补订和升级节奏
768 +
769 +● 可用性
770 +
771 +● 平台基础架构，操作系统等
772 +
773 +● 支持程序和可用性
774 +
775 +● 培训选择
776 +
777 +● 许可模型
778 +
779 +● 供应商策略、图像、财务、参考等。
780 +
781 +可以通过已定义的供应商管理实践来获得评估供应商的工具。
782 +
783 +
784 +
785 +==== 7.3.4.2 开发新兴技术的好处 ====
786 +
787 +
788 +有几种补充系统和工具，可以用来帮助增强服务管理套件的功能。不采用这些新兴技术的组织可能会被抛在后面。
789 +
790 +然而，认识到从这些投资中获得价值所需的技能和时间是很重要的。一些组织采用了太多的新工具，无意间消耗了资源。通常，采用工具来提高效率，但是大多数工具都需要资源来维护。因此，需要全面的商业论证来证明其合理性。
791 +
792 +无论是云计算、移动自带设备（BYOD）、认知计算解决方案、监控和报告，还是自动化和测试，IT运营部门都有责任及时经济高效地采用和调整这些不断变化的解决方案。
793 +
794 +最近数字化设备的数量和类型大量增加，导致了出现新型的在线社区和服务，这些在线社区和服务反过来又改变了业务和社交互动的工作方式。例如，智能手机和平板设备启用了新的移动商业模式，而该模式在十年前是不存在的。云服务是业务和IT运营的新模式，用于交付实时或近实时信息以及对服务的访问。人工智能和机器学习很快将再次给IT带来革命性的变化。
795 +
796 +工作流自动化呈指数级增长。所有新技术代表着新机遇。
797 +
798 +
799 +
800 +==== 7.3.4.3 建立信息模型 ====
801 +
802 +
803 +所有组织都有现有的信息模型。了解它们是什么、它们的来源以及如何维护它们是任何IT和服务管理实施的关键部分。信息模型包含有关数据模型之间关系的信息。
804 +
805 +
806 +**定义：信息模型**
807 +
808 +与分类法和数据与其他数据的关系有关的信息结构，需要以有意义且具有代表性的方式呈现和共享内容。
809 +
810 +
811 +商业IT和服务管理信息系统还将具有需要填充的数据和信息的预定义分类。信息建模是任何实施的基础，并且需要作为持续改进的一部分进行重新审视。
812 +
813 +组织的数据模型需要映射到IT和服务管理系统的数据模型。这种映射需要了解工具组织的本机方式并将其数据从一个表关联到另一个表。
814 +
815 +作为映射练习的一部分，并且在加载任何数据之前，重要的是通过询问以下内容来评估是否应使用数据：
816 +
817 +● 数据是否有明确的来源？什么或谁提供了此信息？
818 +
819 +● 必须整合多少个来源？是否有一个团队可以汇总和规范化来自这些来源的数据？
820 +
821 +● 数据是最新的吗？
822 +
823 +● 数据如何维护？
824 +
825 +● 数据当前稳定吗？经常变更吗？
826 +
827 +理想情况下，所需的信息可以从聚合和规范化数据的中心点获取。各个工具集都需要此核心信息；当需要更改时，代理降低了复杂性，并增加了信息的完整性。在可能的情况下，应该限制使用此数据所需的集成数量，以最大程度地减少各种系统升级期间对变更的管理和测试。
828 +
829 +重要的是避免在由外部源控制的IT和服务管理系统中手动更新数据。例如，如果用户的信息在系统中不正确，则应指导他们在确定的源系统中更新其信息。这样做可以安排自动更新，以几乎实时地维护此数据。如果允许手动更新，自动化将覆盖它们。通过自动更新源系统中的信息，可以最大程度地减少管理和维护的工作量。
830 +
831 +对数据的需求提出疑问可以帮助提高效率。例如，如果组织正在经历重大转型，则应评估对数据持续输入的需求。在填充数据并将其与其他数据关联之后，很难在不影响信息报告连续性的情况下进行更改。数据可以始终映射并保存卸载，直到识别出额外需求。
832 +
833 +在定义数据需求时，定义并记住目标是很重要的。为了帮助确定数据需求可以提出以下问题：
834 +
835 +● 信息如何组织和呈现？
836 +
837 +● 理想情况下，应该如何组织数据？
838 +
839 +● 信息是否传达给组织中的各个单位（团队，部门，领导者等）？
840 +
841 +● 模型是否准确并能反映当前的环境？
842 +
843 +● 是否需要合并，整理和分析来自其他工具集的数据？
844 +
845 +基础数据的更改可能非常昂贵。例如，假设一家公司对事件、问题、请求、配置项、变更、可用性和监控使用了自定义类别。该公司将发现很难比较和关联记录类型之间的数据。相反，应该利用共享的分类模型。例如，应该在定义了业务服务和IT服务的情况下生成服务目录。此信息将在配置管理数据库（CMDB）中建模，然后可以对服务建模应用程序和基础结构。该模型可用于可视化服务和组件的可用性。可以分析成本和服务的稳定性，因为可以通过共享分类模型轻松识别相关的事件、变更和问题。从自定义类别开始的公司将不得不做大量的工作来标准化分类。如此之多，以至于有些组织发现，从一个新的系统开始远比比修改他们现有的系统更容易。
846 +
847 +[[image:1639228426310-882.png]]
848 +
849 +
850 +
851 +(% class="wikigeneratedid" %)
852 +== ==
853 +
854 +== 7.4 总结 ==
855 +
856 +
857 +如果组织真正致力于采用一种专注于服务、价值和结果的工作方式，则它必须相应地设计其SVS。通过利用ITIL 指导原则并与组织的治理和战略保持一致，组织应该开发和配置其资源以支持价值共创。面向服务并保持这种定位本质上是具有挑战性的，但付出大量的努力是值得的。
858 +
859 +
860 +[[阅读下一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC8%E7%AB%A0%20%E6%8A%8A%E5%AE%83%E4%BB%AC%E9%9B%86%E6%88%90%E8%B5%B7%E6%9D%A5/]]  [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E6%8C%87%E5%AF%BC%E3%80%81%E8%AE%A1%E5%88%92%E5%92%8C%E6%94%B9%E8%BF%9B%E3%80%8BDPI/%E7%AC%AC6%E7%AB%A0%20%E6%B2%9F%E9%80%9A%E5%92%8C%E7%BB%84%E7%BB%87%E5%8F%98%E9%9D%A9%E7%AE%A1%E7%90%86/]]
Icon 1641536441897-744.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +33.9 KB
Content Icon
Icon 1641536463264-622.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +56.0 KB
Content Icon
Icon 1641536617924-170.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +96.4 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司