Last modified by superadmin on 2024/12/25, 15:37
From version < 72.1 >
edited by superadmin
on 2024/05/12, 00:06
To version < 19.1 >
edited by superadmin
on 2021/01/29, 21:52
< >
Change comment: 上传新附件1600930052354-753.png

Summary

Details

Icon Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -服务管理实践 - 01 服务台
1 +01 服务台 （已发布）
Content
... ... @@ -1,33 +1,30 @@
1 -{{info}}
2 -===== **了解长河老师 ¥599元  ITIL4基础级认证核心考点讲解和习题辅导，请点击 [[ITIL 4 基础认证必考知识速学网课>>https://www.itil4hub.cn/bin/view/ITIL4%E8%AE%A4%E8%AF%81%E5%9F%B9%E8%AE%AD%E8%80%83%E8%AF%95%E8%B5%84%E6%96%99/ITIL4%E5%9F%BA%E7%A1%80%E8%AE%A4%E8%AF%81%E5%BF%85%E8%80%83%E7%9F%A5%E8%AF%86%E9%80%9F%E5%AD%A6%E7%BD%91%E8%AF%BE/]]** =====
3 -{{/info}}
1 +(% class="jumbotron" %)
2 +(((
3 +(% class="container" %)
4 +(((
5 += =
4 4  
5 5  
6 -**申明：**
8 +需要下载 **ITIL 4服务台实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“服务台实践”即可。
7 7  
8 -本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号：**ITILXF**，并回复“**服务台实践**”即可。
10 +[[image:http://itil4hub.cn/bin/download/C%20%E5%AE%9E%E8%B7%B5%E6%8C%87%E5%8D%97/03%20%E6%9C%8D%E5%8A%A1%E8%AF%B7%E6%B1%82%E7%AE%A1%E7%90%86/WebHome/%E5%BE%AE%E4%BF%A1%E5%9B%BE%E7%89%87_20200929154759.png?rev=1.2||alt="微信图片_20200929154759.png"]]
9 9  
10 -{{box cssClass="floatinginfobox" title="**Contents**"}}
11 -{{toc/}}
12 -{{/box}}
13 13  
14 -(((
15 -
13 +**申明：**
16 16  
15 +本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
16 +
17 17  请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
18 18  
19 -**翻译**：傅盛        **审校**：秦佩君        **审核**：姚凯 、严宝龙
20 20  
21 -
22 -
23 -----
24 -
25 -
20 +**翻译**：傅盛 **审校**：秦佩君 **审核**：姚凯、严宝龙     
26 26  )))
22 +)))
27 27  
28 28  
29 29  = 1 关于本文档 =
30 30  
27 +[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=1]]
31 31  
32 32  本文档提供服务台实践实用指南，分为五个主要部分，涵盖：
33 33  
... ... @@ -41,9 +41,9 @@
41 41  
42 42  ●对本实践的合作伙伴和供应商的考虑
43 43  
44 -
45 45  == 1.1 ITIL 4资格认证计划 ==
46 46  
43 +[[编辑>>url:http://itil4hub.cn/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/1%20%E5%85%B3%E4%BA%8E%E6%9C%AC%E6%96%87%E4%BB%B6/WebHome?section=2]]
47 47  
48 48  本文档中的部分内容可作为以下教学大纲的一部分以供检查：
49 49  
... ... @@ -59,12 +59,15 @@
59 59  
60 60  = 2  一般信息 =
61 61  
59 +[[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=1]]
62 62  
61 +== ==
63 63  
63 +[[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=2]]
64 64  
65 -
66 66  == 2.1 目的和描述 ==
67 67  
67 +[[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=3]]
68 68  
69 69  * **关键信息**
70 70  
... ... @@ -74,12 +74,11 @@
74 74  
75 75  与其他实践一样，该实践涉及服务管理四维度模型的所有维度：
76 76  
77 -(% style="width:445px" %)
78 -|(% style="width:152px" %)服务管理维度  |(% style="width:290px" %)服务台实践资源示例
79 -|(% style="width:152px" %)组织和人员|(% style="width:290px" %)专门小组，有时被称为“服务台”
80 -|(% style="width:152px" %)信息和技术|(% style="width:290px" %)专用信息系统，有时被称为“服务台”
81 -|(% style="width:152px" %)价值流和流程|(% style="width:290px" %)与用户沟通的工作流和程序
82 -|(% style="width:152px" %)合作伙伴和供应商|(% style="width:290px" %)相关第三方，在某些情况下被称为“服务台”
77 +|服务管理维度  |服务台实践资源示例
78 +|组织和人员|专门小组，有时被称为“服务台”
79 +|信息和技术|专用信息系统，有时被称为“服务台”
80 +|价值流和流程|与用户沟通的工作流和程序
81 +|合作伙伴和供应商|相关第三方，在某些情况下被称为“服务台”
83 83  
84 84  表2.1 服务管理维度示例
85 85  
... ... @@ -89,9 +89,9 @@
89 89  
90 90  服务台实践涉及服务提供商与用户沟通的所有价值流，其目的是确保这些沟通对所有相关方都是有效和便利的。
91 91  
92 -
93 93  == 2.2 术语和概念 ==
94 94  
93 +[[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=4]]
95 95  
96 96  === 2.2.1 沟通渠道 ===
97 97  
... ... @@ -99,16 +99,15 @@
99 99  
100 100  良好的沟通渠道允许用户和服务提供商以对各方都便利的方式交换信息，并保证信息质量。在这种情况下，术语“便利”的特征如表2.2所述。
101 101  
102 -(% style="width:572px" %)
103 -|(% style="width:178px" %)**“便利”特性**|(% style="width:392px" %)**解释**
104 -|(% style="width:178px" %)可访问性|(% style="width:392px" %)沟通渠道应该可访问。这可能包括语言、格式，以及用于任何视觉或其他方面受损的用户的特殊功能。可能需要通过特殊的应用程序、设备以及技能的界面访问沟通渠道。
105 -|(% style="width:178px" %)保障性|(% style="width:392px" %)各方应确保沟通渠道真实、安全，并符合适用的法规、政策和规则。
106 -|(% style="width:178px" %)可用性|(% style="width:392px" %)沟通渠道应在任何需要的地点和时间可用。根据服务的不同，沟通渠道可能包括各种范围的移动接口（从仅在组织内到覆盖全球范围）和可用时间的选项（从仅在工作时间内到连续可用）。
107 -|(% style="width:178px" %)情境智能化|(% style="width:392px" %)在可能的情况下，应整合沟通渠道和相关情景信息。该信息可以包括预先填写的情景数据、沟通历史、用户档案等。
108 -|(% style="width:178px" %)情感一致性（Emotional Alignment）|(% style="width:392px" %)在某些情况下，沟通渠道用于交流情感、感觉以及事实数据。在这种情况下，服务提供商应该促进服务同理心。这通常需要一个类似电话或面对面沟通的人机界面。
109 -|(% style="width:178px" %)熟悉度|(% style="width:392px" %)熟悉的沟通渠道比陌生的新渠道更便利。社交媒体、论坛、电子邮件、聊天室和其他沟通渠道可以有效地用于与服务提供商的联系。
110 -|(% style="width:178px" %)整合性|(% style="width:392px" %)服务提供商经常使用多种渠道与用户沟通。此外，服务交互中可能涉及多个其他系统。应整合这些系统，以减少或消除重复的数据输入，并防止信息丢失（参见以下全渠道沟通的定义）。
111 -|(% style="width:178px" %)易用性（Usability）|(% style="width:392px" %)(((
101 +|**“便利”特性**|**解释**
102 +|可访问性|沟通渠道应该可访问。这可能包括语言、格式，以及用于任何视觉或其他方面受损的用户的特殊功能。可能需要通过特殊的应用程序、设备以及技能的界面访问沟通渠道。
103 +|保障性|各方应确保沟通渠道真实、安全，并符合适用的法规、政策和规则。
104 +|可用性|沟通渠道应在任何需要的地点和时间可用。根据服务的不同，沟通渠道可能包括各种范围的移动接口（从仅在组织内到覆盖全球范围）和可用时间的选项（从仅在工作时间内到连续可用）。
105 +|情境智能化|在可能的情况下，应整合沟通渠道和相关情景信息。该信息可以包括预先填写的情景数据、沟通历史、用户档案等。
106 +|情感一致性（Emotional Alignment）|在某些情况下，沟通渠道用于交流情感、感觉以及事实数据。在这种情况下，服务提供商应该促进服务同理心。这通常需要一个类似电话或面对面沟通的人机界面。
107 +|熟悉度|熟悉的沟通渠道比陌生的新渠道更便利。社交媒体、论坛、电子邮件、聊天室和其他沟通渠道可以有效地用于与服务提供商的联系。
108 +|整合性|服务提供商经常使用多种渠道与用户沟通。此外，服务交互中可能涉及多个其他系统。应整合这些系统，以减少或消除重复的数据输入，并防止信息丢失（参见以下全渠道沟通的定义）。
109 +|易用性（Usability）|(((
112 112  所有类型的界面都应该清晰、直观、有用和实用。
113 113  
114 114  
... ... @@ -116,7 +116,6 @@
116 116  
117 117  表2.2沟通渠道的便利特性
118 118  
119 -
120 120  表2.2中概述的特征与常用于评估和管理信息质量的特征类似，这些特征包括可用性、可靠性、可访问性、及时性、准确性和相关性。需要注意的是，信息质量可能取决于沟通质量；其他信息特征则取决于信息源和相关方。
121 121  
122 122  多渠道通常用于服务提供者与用户之间的沟通。多渠道沟通可能很便利，但若不进行整合也会带来混乱。多渠道沟通提供无缝体验和信息流，其发展的极致即为全渠道沟通。
... ... @@ -125,7 +125,6 @@
125 125  
126 126  跨多个渠道的统一沟通，基于跨渠道的信息共享，提供无缝的沟通体验。
127 127  
128 -
129 129  === 2.2.2 服务同理心 ===
130 130  
131 131  * **定义：服务同理心**
... ... @@ -138,7 +138,6 @@
138 138  
139 139  服务同理心是用户满意度提升和服务提供商成功的重要因素。作为一个概念，服务同理心不仅应用于用户支持和相关服务交互的狭窄情景，它适用于所有的服务交互。
140 140  
141 -
142 142  === 2.2.3 用户满意度 ===
143 143  
144 144  服务台作为一种交流界面，对用户满意度、客户满意度提升和服务关系的整体成功具有重要影响。用户满意度的关键因素包括沟通渠道和互动的有效性与便利性。
... ... @@ -151,9 +151,9 @@
151 151  
152 152  服务台实践也用于收集关于用户满意度的信息。调查或其他满意度研究工具通常使用这种实践建立的沟通渠道。为了有效地收集这些信息，本实践的沟通渠道应该被用户认为是可信的、有效的和方便的；否则，对调查和其他沟通的反馈可能会受到影响。
153 153  
154 -
155 155  == 2.3 范围 ==
156 156  
151 +[[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=5]]
157 157  
158 158  服务台实践的范围包括：
159 159  
... ... @@ -162,21 +162,20 @@
162 162  
163 163  尽管一些活动和责任领域与服务台密切相关，但不包括在服务台实践中。表2.3中列出了这些活动和责任领域，以及对应的实践供参考。重要的是要记住，ITIL实践仅仅是在价值流情景下使用的工具集合，它们应根据情况的需要而组合起来使用。
164 164  
165 -(% style="width:540px" %)
166 -|(% style="width:217px" %)**活动**|(% style="width:320px" %)**实践指南**
167 -|(% style="width:217px" %)事件解决和管理|(% style="width:320px" %)事件管理
168 -|(% style="width:217px" %)服务请求的管理和实现|(% style="width:320px" %)服务请求
169 -|(% style="width:217px" %)用户和服务提供商之间沟通的内容、时机和格式的定义|(% style="width:320px" %)向用户提供信息或使用用户信息的所有实践，包括事件管理、问题管理、变更支持、发布管理、项目管理、软件开发和管理、基础设施和平台管理、信息安全管理以及许多其他内容
170 -|(% style="width:217px" %)技术和服务性能监控|(% style="width:320px" %)监控和事态管理
171 -|(% style="width:217px" %)改进计划的管理|(% style="width:320px" %)持续改进
172 -|(% style="width:217px" %)服务提供商和利益相关方之间的沟通，而非与用户的沟通|(% style="width:320px" %)关系管理
173 -|(% style="width:217px" %)维护和改进信息与知识的使用|(% style="width:320px" %)知识管理
160 +|**活动**|**实践指南**
161 +|事件解决和管理|事件管理
162 +|服务请求的管理和实现|服务请求
163 +|用户和服务提供商之间沟通的内容、时机和格式的定义|向用户提供信息或使用用户信息的所有实践，包括事件管理、问题管理、变更支持、发布管理、项目管理、软件开发和管理、基础设施和平台管理、信息安全管理以及许多其他内容
164 +|技术和服务性能监控|监控和事态管理
165 +|改进计划的管理|持续改进
166 +|服务提供商和利益相关方之间的沟通，而非与用户的沟通|关系管理
167 +|维护和改进信息与知识的使用|知识管理
174 174  
175 175  表2.3其他实践中描述的与服务台实践相关的活动
176 176  
177 -
178 178  == 2.4 实践成功因素 ==
179 179  
173 +[[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=6]]
180 180  
181 181  * **定义：实践成功因素（Practice Success Factor，PSF）**
182 182  
... ... @@ -189,6 +189,8 @@
189 189  1. 在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进
190 190  1. 实现用户沟通与价值流的有效整合
191 191  
186 +=== ===
187 +
192 192  === 2.4.1 在服务提供商与用户间实现有效、高效和便利的沟通并持续改进 ===
193 193  
194 194  用户和客户可用的支持渠道应该高效、有效且便利。通过为用户和客户提供满足其需求的渠道可以达到便利。用户的需求可能会根据地理区域、时间、首选语言和可访问性要求的不同而变化。服务越便利，用户体验越好。
... ... @@ -229,491 +229,156 @@
229 229  
230 230  在选择和设计服务渠道时，非常重要的是考虑用户对服务使用的准备度以及相关的风险和机会。不同的渠道会带来不同的挑战；组织必须准备好克服这些挑战。表2.4列出了其中的一些挑战。
231 231  
232 -[[image:1642235400045-491.png]]
228 +| |**渠道**|**挑战示例**|**解决方案示例**
229 +|(% rowspan="6" %)(((
230 +用
233 233  
234 -[[image:1642235424757-755.png]]
232 +户
235 235  
236 -表2.4 渠道示例及其挑战
234 +与
237 237  
236 +人
238 238  
239 -在大多数情况下，服务提供者使用多种渠道。重要的是确保各渠道间有效整合。沟通应是全渠道，而非多渠道。一段无缝的用户旅程，有可能在信息不丢失或损坏的情况下，在不同的渠道间切换，促进积极的用户体验。没有充分整合的多渠道沟通很可能会造成混乱并引发错误。图2.1演示了如何使用多种渠道支持用户。
238 +的
240 240  
241 -(% style="text-align:center" %)
242 -[[image:1600929628284-534.png]]
240 +互
243 243  
244 -图2.1多种沟通渠道
242 +动
243 +)))|语音|(((
244 +有限的可扩展性
245 245  
246 +主观态度和情绪
247 +)))|投资于支持型客服的职业发展、情商、对不同文化的认知和兴趣
248 +|实时聊天|主观态度和情绪|将人力支持限制在需要和合理的地方
249 +|电子邮件|(((
250 +非结构化信息
246 246  
247 -在非集成的多渠道沟通中，渠道间会有信息隔阂。例如，电话问询、在移动应用程序中的预约以及与来访工程师的沟通都可能需要重新输入（重新沟通）以触发呼叫支持服务。另一方面，在全渠道沟通中，情景将不断更新，并且可重用的数据将在任何关联的地方都可用。例如，用户在同一登录账号下执行的所有浏览和咨询都会添加到情景中，支持专家都可以看到。用户支持客服和来访工程师都可以获得所有相关数据。
252 +主观态度和情绪
253 +)))|在适当的情况下，利用可用资源自动记录非结构化信息
254 +|走访|(((
255 +有限的可扩展性
248 248  
249 -换而言之，在多渠道沟通中，用户将在每条渠道开始新的旅程。在全渠道沟通中，旅程持续并在不同渠道间便利地切换。
257 +主观态度和情绪
258 +)))|(% rowspan="3" %)(((
259 +
250 250  
261 +情况合适时推行自助服务以增加接待能力
251 251  
252 -=== 2.4.2 实现用户沟通与价值流的有效整合 ===
253 -
254 -作为服务提供商与用户双向沟通的节点，服务台实践的一个关键重点是有效地捕获、记录沟通信息并将其集成到相关的价值流中。像所有实践一样，本实践涉及多条价值流：只要服务提供商和用户之间需要沟通。
255 -
256 -由服务提供者发起的沟通由价值流中涉及的一个或多个其他实践共同定义和执行。例如，关于服务计划变更的沟通由变更支持实践和发布管理实践共同发起和执行。作为服务台实践的一部分，建立和管理沟通渠道，但沟通的内容、格式和时间的定义是价值流情景中变更支持实践和发布管理实践的一部分。
257 -
258 -然而，当用户发起沟通时，并不清楚属于哪条价值流，应该触发哪项ITIL实践活动。服务台实践为所有用户问询（包括咨询、事件、服务请求、投诉和表扬）的有效分类提供沟通界面和程序。当对用户查询进行分类并确定相关的价值流和实践后，将根据各自实践的流程和程序处理查询。有时，这涉及服务台团队资源和/或信息系统。
259 -
260 -
261 -== 2.5 关键指标 ==
262 -
263 -应在每个实践所贡献的价值流情境中评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用的情景中评估。然而，在设计和质量上，工具可能有很大的差异。当根据工具的目的使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准、关键绩效指标（Key Performance Indicators， KPIs）和其他有助于实现这一点的技术的进一步指导，请参见度量和报告实践指南。
264 -
265 -服务台实践的关键指标映射到其PSFs上。这些PSFs可以用作价值流情景下的KPIs，评估实践对这些价值流效能和效率的贡献。表2.5给出了一些关键指标的示例。
266 -
267 -(% style="width:721px" %)
268 -|(% style="width:258px" %)实践成功因素|(% style="width:460px" %)指标示例
269 -|(% style="width:258px" %)在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进|(% style="width:460px" %)(((
270 -通过服务台渠道接收的信息的质量，根据商定的信息质量标准衡量
271 -
272 -服务台沟通渠道和界面的便利性，根据商定的便利性标准衡量
273 -
274 -沟通关键利益相关者对信息质量和服务台沟通渠道的便利性的满意度
263 +提供明确的安全参数，并定期测试其有效性
275 275  )))
276 -|(% style="width:258px" %)实现用户沟通与价值流的有效整合|(% style="width:460px" %)(((
277 -与价值流的要求相比，通过服务台渠道接收到的信息的质量
265 +|驻场|(((
266 +有限的规模和可用性
278 278  
279 -关键利益相关者对通过服务台渠道传达信息的的满意度
280 -
281 -用户查询分类不正确的数量和百分比
268 +主观态度和情绪
282 282  )))
270 +|社交媒体|(((
271 +病毒效应，错误和冲突的高曝光率
283 283  
284 -表2.5实践成功因素的关键指标示例
273 +主观态度和情绪
285 285  
275 +非结构化信息
286 286  
287 -将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理以及服务台实践的定期评估和持续改进。对此没有唯一的最佳解决方案。度量标准基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
277 +安全约束
278 +)))
279 +|(((
280 +用
288 288  
282 +户
289 289  
284 +与
290 290  
291 -----
286 +技
292 292  
293 -= 3 价值流和流程 =
288 +术
294 294  
290 +的
295 295  
296 -== 3.1价值流贡献 ==
292 +互
297 297  
294 +动
295 +)))|网络门户，（电话）互动语音菜单，移动应用，聊天机器人以及其他|(((
296 +用户可以在其安全级别上完成范围有限的任务
298 298  
299 -像任何其他ITIL管理实践一样，服务台实践对多条价值流有帮助。重要的是要记住，价值流从来不是由单一实践形成的。服务台实践与其他实践相结合，为客户提供高质量的服务。这种实践促成的主要价值链活动有：
298 +数据不充分、不足够
300 300  
301 -●契动
300 +用户技术技能不充分、不足够
302 302  
303 -●交付和支持。
302 +缺乏服务同理心和情商
304 304  
305 -服务台实践对服务价值链的贡献如图3.1所示
304 +面对复杂环境的有限适用性
305 +)))|(((
306 +在实施自助前，评估用户技能和可用的支持操作范围
306 306  
307 -(% style="text-align:center" %)
308 -[[image:1600929812191-791.png]]
308 +使用用户熟悉的渠道和界面
309 309  
310 -图3.1 服务台实践对价值链贡献的热力图
310 +确保高质量的历史数据和知识支持
311 311  
312 +当使用机器学习时，确保数据和算法的高质量
312 312  
313 -== 3.2过程 ==
314 +提供人工备份支持选项
314 314  
316 +改进信息质量和导航工具
315 315  
316 -每个实践可以包括一个或多个流程和活动，这是实现这一实践目的所必需的。
318 +确保尽可能容易获得自助工具和行动
319 +)))
317 317  
318 -* **定义：流程**
321 +表2.4 渠道示例及其挑战
319 319  
320 -将输入转换为输出的一组相互关联或相互作用的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义了操作的顺序及依赖关系。
323 +在大多数情况下，服务提供者使用多种渠道。重要的是确保各渠道间有效整合。沟通应是全渠道，而非多渠道。一段无缝的用户旅程，有可能在信息不丢失或损坏的情况下，在不同的渠道间切换，促进积极的用户体验。没有充分整合的多渠道沟通很可能会造成混乱并引发错误。图2.1演示了如何使用多种渠道支持用户。
321 321  
322 -服务台活动分为三个流程：
323 -
324 -* 用户查询处理
325 -* 与用户沟通
326 -* 服务台优化
327 -
328 -=== 3.2.1 用户查询处理 ===
329 -
330 -该流程确保对用户查询的捕获、验证和分类，以便进一步处理。它包括表3.1中列出的活动，并将输入转化为输出。
331 -
332 -(% style="width:594px" %)
333 -|(% style="width:223px" %)**关键输入**|(% style="width:178px" %)**活动**|(% style="width:191px" %)**关键输出**
334 -|(% style="width:223px" %)用户查询|(% style="width:178px" %)确认并记录用户的查询|(% style="width:191px" %)记录并分类用户的查询
335 -|(% style="width:223px" %)服务管理记录，例如，事件记录、变更记录、问题记录等|(% style="width:178px" %)用户查询的验证|(% style="width:191px" %)开始处理已分类的用户查询
336 -|(% style="width:223px" %)服务配置信息、IT资产信息以及其它相关信息|(% style="width:178px" %)对用户查询进行初步处理并启动适当的活动|(% style="width:191px" %)
337 -
338 -表3.1 用户查询处理流程的输入、活动和输出
339 -
340 -
341 -图3.2 展示该流程的工作流图
342 -
343 343  (% style="text-align:center" %)
344 -[[image:1600929854496-543.png]]
326 +[[image:1600929628284-534.png]]
345 345  
346 -图3.2 用户查询处理的工作流
328 +图2.1多种沟通渠道
347 347  
330 +在非集成的多渠道沟通中，渠道间会有信息隔阂。例如，电话问询、在移动应用程序中的预约以及与来访工程师的沟通都可能需要重新输入（重新沟通）以触发呼叫支持服务。另一方面，在全渠道沟通中，情景将不断更新，并且可重用的数据将在任何关联的地方都可用。例如，用户在同一登录账号下执行的所有浏览和咨询都会添加到情景中，支持专家都可以看到。用户支持客服和来访工程师都可以获得所有相关数据。
348 348  
349 -表3.2将用户查询处理过程中每个人工交互和自动化活动进行比较。
332 +换而言之，在多渠道沟通中，用户将在每条渠道开始新的旅程。在全渠道沟通中，旅程持续并在不同渠道间便利地切换。
350 350  
334 +=== 2.4.2 实现用户沟通与价值流的有效整合 ===
351 351  
352 -[[image:1642580581960-553.png]]
336 +作为服务提供商与用户双向沟通的节点，服务台实践的一个关键重点是有效地捕获、记录沟通信息并将其集成到相关的价值流中。像所有实践一样，本实践涉及多条价值流：只要服务提供商和用户之间需要沟通。
353 353  
354 -[[image:1642580603544-786.png]]
338 +由服务提供者发起的沟通由价值流中涉及的一个或多个其他实践共同定义和执行。例如，关于服务计划变更的沟通由变更支持实践和发布管理实践共同发起和执行。作为服务台实践的一部分，建立和管理沟通渠道，但沟通的内容、格式和时间的定义是价值流情景中变更支持实践和发布管理实践的一部分。
355 355  
356 -[[image:1642580673860-313.png]]
340 +然而，当用户发起沟通时，并不清楚属于哪条价值流，应该触发哪项ITIL实践活动。服务台实践为所有用户问询（包括咨询、事件、服务请求、投诉和表扬）的有效分类提供沟通界面和程序。当对用户查询进行分类并确定相关的价值流和实践后，将根据各自实践的流程和程序处理查询。有时，这涉及服务台团队资源和/或信息系统。
357 357  
358 -表3.2自动化与人工交互比较
342 +== 2.5 关键指标 ==
359 359  
344 +[[编辑>>path:/bin/edit/01%20%E6%9C%8D%E5%8A%A1%E5%8F%B0/2%20%E4%B8%80%E8%88%AC%E4%BF%A1%E6%81%AF/WebHome?section=7]]
360 360  
361 -=== 3.2.2 与用户沟通 ===
346 +应在每个实践所贡献的价值流情境中评估ITIL实践的有效性和绩效。与任何工具的绩效一样，实践的绩效只能在其应用的情景中评估。然而，在设计和质量上，工具可能有很大的差异。当根据工具的目的使用时，这些差异定义了工具有效性的潜力或能力。关于度量标准、关键绩效指标（Key Performance Indicators， KPIs）和其他有助于实现这一点的技术的进一步指导，请参见度量和报告实践指南。
362 362  
363 -这个过程确保通过适当的渠道将各种类型的信息传达给用户。它包括表3.3所列的活动，并将输入转换成输出。
348 +服务台实践的关键指标映射到其PSFs上。这些PSFs可以用作价值流情景下的KPIs，评估实践对这些价值流效能和效率的贡献。表2.5给出了一些关键指标的示例。
364 364  
365 -(% style="width:533px" %)
366 -|(% style="width:199px" %)**关键输入**|(% style="width:219px" %)**活动**|(% style="width:113px" %)**关键输出**
367 -|(% style="width:199px" %)(((
368 -用户沟通需求
350 +|实践成功因素|指标示例
351 +|在服务提供者及其用户间实现有效、高效和便利的沟通并持续改进|(((
352 +通过服务台渠道接收的信息的质量，根据商定的信息质量标准衡量
369 369  
370 -沟通的信息
354 +服务台沟通渠道和界面的便利性，根据商定的便利性标准衡量
371 371  
372 -以前的沟通记录
356 +沟通关键利益相关者对信息质量和服务台沟通渠道的便利性的满意度
357 +)))
358 +|实现用户沟通与价值流的有效整合|(((
359 +与价值流的要求相比，通过服务台渠道接收到的信息的质量
373 373  
374 -服务管理记录，例如事件记录、变更记录、问题记录等
361 +关键利益相关者对通过服务台渠道传达信息的的满意度
375 375  
376 -服务配置信息、IT资产信息及其他相关信息
377 -)))|(% style="width:219px" %)(((
378 -识别并确认目标受众
379 -
380 -识别并确认沟通渠道
381 -
382 -信息打包
383 -
384 -信息发送
385 -
386 -收集和处理接受者的确认和反馈
387 -)))|(% style="width:113px" %)(((
388 -沟通消息
389 -
390 -沟通报告
363 +用户查询分类不正确的数量和百分比
391 391  )))
392 392  
393 -表3.3 与用户沟通过程的输入、活动和输出
366 +表2.5实践成功因素的关键指标示例
394 394  
368 +将度量标准正确地聚合到复杂的指标中，将使数据更容易用于价值流的持续管理以及服务台实践的定期评估和持续改进。对此没有唯一的最佳解决方案。度量标准基于组织的整体服务策略和优先级，以及实践所贡献的价值流的目标。
395 395  
396 -服务提供者和用户间的所有沟通都应该包括在此过程中。与用户沟通过程的需求通常由各种实践确定。沟通通常是标准化和自动化的，例如关于事件状态变化的通知。在某些情况下，还需要使用沟通流程将异常或其他重要信息传达给不同的受众。
397 397  
398 -图3.3展示该流程的工作流图。
399 -
400 -(% style="text-align:center" %)
401 -[[image:1600930001924-317.png]]
402 -
403 -图3.3与用户沟通过程的工作流
404 -
405 -
406 -表3.4概述了与先前已登记的查询相关的沟通过程活动。
407 -
408 -[[image:1642235731662-569.png]]
409 -
410 -[[image:1642235775142-492.png]]
411 -
412 -[[image:1642235790279-634.png]]
413 -
414 -表3.4关于先前已登记的查询的沟通过程活动
415 -
416 -
417 -=== 3.2.3 服务台优化 ===
418 -
419 -这一流程确保从管理用户沟通中吸取经验教训，并不断改进这一实践。它包括表3.5中列出的活动，并将输入转化为输出。
420 -
421 -(% style="width:427px" %)
422 -|(% style="width:156px" %)**关键输入**|(% style="width:132px" %)**活动**|(% style="width:137px" %)**关键输出**
423 -|(% style="width:156px" %)(((
424 -服务台绩效报告
425 -
426 -满意度调查结果
427 -
428 -技术机遇
429 -
430 -事件和服务请求报告
431 -)))|(% style="width:132px" %)(((
432 -服务台回顾
433 -
434 -服务台优化启动
435 -
436 -服务台优化沟通
437 -)))|(% style="width:137px" %)服务台优化沟通
438 -
439 -表3.5 服务台优化流程的输入、活动和输出
440 -
441 -
442 -图3.4展示服务台优化流程的工作流图
443 -
444 -(% style="text-align:center" %)
445 -[[image:1600930052354-753.png]]
446 -
447 -图3.4服务台优化过程的工作流
448 -
449 -
450 -表3.6概述了服务台优化过程的活动。
451 -
452 -(% style="width:510px" %)
453 -|(% style="width:128px" %)**活动**|(% style="width:379px" %)**描述**
454 -|(% style="width:128px" %)服务台回顾|(% style="width:379px" %)服务台团队经理与其他相关干系人一起回顾各种输入。确定改进这一实践的机会。
455 -|(% style="width:128px" %)服务台优化启动|(% style="width:379px" %)服务台团队经理记录改进计划。计划将通过引入持续改进实践或启动变更请求进行处理。
456 -|(% style="width:128px" %)服务台优化沟通|(% style="width:379px" %)如果服务台成功地完成优化，这一事实将会传达给相关的利益相关者。这通常由服务台经理通过沟通过程完成。
457 -
458 -表3.6 服务台优化过程活动
459 -
460 -
461 -
462 462  ----
463 463  
464 -= 4 组织和人员 =
465 465  
466 -
467 -
468 -
469 -
470 -== 4.1 角色、能力和责任 ==
471 -
472 -
473 -实践指南不描述实践管理角色，如实践所有者、实践负责人或实践教练。相反，指南关注特定的每个实践的专家角色。每个角色的结构和命名可能因组织而异，因此不应强制，甚至不应推荐ITIL中定义的任何角色。记住，角色并非职位头衔。一个人可担任多个角色，一个角色也可以分配给多个人员。
474 -
475 -在流程和活动的情景中描述角色。每个角色都有一个基于表4.1所示模型的能力类型。
476 -
477 -|能力代码|能力类型（活动和技能）
478 -|L|**领导Leader **决策、授权、监督其他活动，提供激励和动力，并评估结果
479 -|A|**管理员Administrator** 分配任务并确定优先级，保存记录，持续报告，并启动基本改进
480 -|C|**协调者/沟通者 **协调多方，维护利益相关者之间的沟通，并开展宣传活动
481 -|M|**方法和技巧专家 **设计和实施工作技巧、记录步骤、流程咨询、工作分析和持续改进
482 -|T|**技术专家 **提供技术（IT）专业知识并执行基于专家经验的作业
483 -
484 -表4.1 能力代码和能力类型
485 -
486 -
487 -表4.2列出了服务台实践中可能涉及的其他角色示例，以及相关的能力类型和特定技能。
488 -
489 -[[image:1642235912449-908.png]]
490 -
491 -[[image:1642235925791-414.png]]
492 -
493 -
494 -
495 -== 4.2 组织架构和团队 ==
496 -
497 -
498 -在其他实践中，组织单元根据其参与的价值流活动扮演不同的实践角色。与其他实践不同，服务台实践通常有一个专注于执行其流程的专业团队。
499 -
500 -通常，服务台团队是用户支持的第一线。除了与用户沟通之外，该团队还可以应用文档化或部分自动化的技术解决某些用户（和客户）的查询。通过知识管理工具，事件管理、问题管理、请求履行和服务级别管理等实践将这些技术的知识传递给服务台。应根据服务台实践的目的及其对服务台团队的影响，不断评估执行这些技术所产生的额外工作量。
501 -
502 -本节介绍了不同的组织模型。这些模型可以适应传统上分配给服务台团队的任务。
503 -
504 -
505 -=== 4.2.1 服务台组织模式 ===
506 -
507 -当服务提供商组织规模很小且致力于有限数量的服务时，服务台客服的角色可在员工之间共享。然而，这是一种与用户沟通的低效方式，随着服务和产品的不断发展会带来较大的工作量，而且单一用户交互产生的价值有限。
508 -
509 -即使是小型内部服务提供商也可以受益于专门处理用户查询的员工，在后台服务组件的技术和方法能力与最终用户服务消费相去甚远时更是如此。服务台员工，作为面向消费者的专业人士，通常有很强的沟通技巧和友好、自信的举止。他们也能在不同的任务之间快速切换，并且通常也具有一定技术能力。
510 -
511 -有几种常见的方式组建一个专门的用户交流团队，这将在4.2.1.1小节中讨论。
512 -
513 -
514 -**4.2.1.1 本地服务台团队**
515 -
516 -当服务台在物理上能够管理全渠道沟通时，或者说用户地理位置紧凑时，这种组织模式就能发挥作用。例如，可以为所有为客户服务的员工提供单一的办公空间，甚至可以为走访渠道提供单独团队，这时就适用本地服务台组织。
517 -
518 -这样做的优点是：
519 -
520 -* 团队内部和服务提供商组织之间快速高效的沟通。服务台团队应尽可能物理上与其他服务提供商团队在一起，以便能够快速了解信息和变化。
521 -* 易于人与人之间的接触。服务台团队创建信任，并将服务提供者呈现为可访问资源。
522 -
523 -这方面的挑战是：
524 -
525 -* 集中式联合团队倾向于较少使用查询自动化工具。工作是透明的，人们不理解为什么查询需要被记录。同样，流程和指南也是口头传达和更新的。这可能导致缺乏对用户沟通的控制。
526 -* 物理上的邻近会导致对特定个人，而非特定角色的依赖。这种风险应该通过流程控制减轻，但个人关系可能会形成“走后门式”的支持，并且在这些人离开后对服务提供造成干扰。
527 -
528 -**4.2.1.2 分布式服务台团队**
529 -
530 -该模型类似于本地服务台团队模型：用户群分布在多个位置，但IT和服务台团队之间仍有物理沟通渠道。用户的每个地理区域都与一个专门的服务台团队联系，每个服务台团队采用共同的沟通标准协调工作。
531 -
532 -这样做的优点是：
533 -
534 -* 能够随着客户组织或客户数量的增长而扩展服务提供者的存在，保证了存在和沟通标准。服务行为是任何服务提供的重要组成部分；确保服务行为可见很重要，可以保持积极和合作的声誉。
535 -* 对用户查询的快速反应。分布式服务台组织对用户最有益之处在于用户在所有地点的服务查询都能得到一致和快速的响应。
536 -
537 -这方面的挑战是：
538 -
539 -* 协调和自动化。由于团队是分布式的，因此需要通过一致的协作环境理解当前组织的事态。所有团队都需要类似的、一致的培训和控制。一些服务提供商采用单一的分布式团队名册管理需求波动并减轻职责，以适应工作场所的通勤时间（例如，所有团队成员都在同一个都市圈内）。
540 -* 不管如何自动协调，分布式服务台导致重复的专业知识和管理开销。一般来说，服务台工作人员处理的非沟通任务越多(处理模式化事件、IMAC请求或为用户提供支持)，团队之间的重复工作就会越多。服务提供者应该严格考查分布式服务台的价值（例如，面对面的交互），应对冗余安排造成的协调问题和共享成本。
541 -
542 -**4.2.1.3 虚拟服务台团队**
543 -
544 -服务台团队无法与用户在物理上协同工作时就出现了虚拟服务台团队模式。这与提供公众服务的商业服务提供商，如互联网接入提供商或用户软件供应商，尤其相关。
545 -
546 -在这种情况下，虚拟服务台团队在结构上可能类似于协同工作的本地或分布式团队，或者可能是一组使用通用用户查询管理和工作流工具在家工作的个人。
547 -
548 -虚拟服务台客服和用户之间没有物理交互，这将通过更先进的沟通渠道弥补。
549 -
550 -优点是：
551 -
552 -* 团队压力较小（当信息技术服务不完善时，压力可能会很大）。技术屏障界限有助于创造节奏，减少双方不适当的沟通。
553 -* 降低每次问询的成本。除了使用电话支持，其他大多数沟通渠道都是不连续的。每一方向另一方发送信息都有一个时间差。此外，服务台人员可以在电子邮件或在线聊天问询之间切换，但是电话对话需要服务台人员持续投入注意力。
554 -
555 -挑战是：
556 -
557 -* 服务提供者必须承诺在工具的设计和实现方面进行广泛和持续的投资，支持各种沟通渠道和记录管理。自动化工具（在5.2节中描述）可确保客户能够快速、方便地提交查询并轻松地找到并与相关的服务提供者沟通。应向寻求真人互动的用户提供各种便利且非常容易获取的工具，如在线聊天、电子邮件或电话。服务提供商必须仔细分析每种技术的价值和成本。
558 -
559 -**4.2.1.4 混合式服务台组织**
560 -
561 -大多数服务提供商需在本地和虚拟组织模式间选择一个最优点。这种权衡包括几种已知的妥协：
562 -
563 -* **驻场服务** 取代冗余的服务台团队的分布式网络，服务提供商可以决定在客户现场提供有限数量的员工和服务活动，并为用户的问询提供集中的跟踪系统。驻场服务是一种安排，即少量服务台客服在营业时间出现在客户场所，处理走访查询。这些客服可以自主处理基本的最终用户任务，例如：操作系统的小故障排查、业务应用程序支持、重要公告告知、客户沟通（与用户沟通相反），甚至是小的IMAC查询，少量次要组件（键盘、电池等）的现场维护。如果问题超出了他们的专业知识，或者如果等候队列超过了该服务点的某个阈值，他们就会通过已知的途径上报问询。这些问询在中央虚拟场所管理。驻场处理的问询必须与其他问询（电话、在线等）一起记录在中央问询管理工具中。对分布式服务台团队来说，这是一个合理且备受期待的折衷方案，与企业界中的数字转型一致。
564 -
565 -* **外勤服务 **客户组织中有用户在远程地点，并且服务提供商无法确保有常驻服务人员的情况下，处理物理上的工作可使用外勤服务。这些服务会产生服务提供者员工的差旅和住宿等费用，可能需要额外批准。在设计服务基础设施时，可以采用SaaS、授权用户或将一些现场服务委托给第三方的方式，减少这种模式存在的必要性。
566 -
567 -* **离岸和共享服务台团队** 这是从呼叫中心继承下来的实践。根据呼叫的来源，话务员使用不同的“行动手册”处理呼叫者的请求。一些大型的全球服务提供商和消费者技术供应商在劳动力成本较低的地方创建大型服务台中心，提供成本相对较低的服务台业务。尽管这种高度虚拟化的方法存在挑战，但其低廉的价格足以极大地推动对这种模式的需求。
568 -
569 -=== 4.2.2 服务台规模 ===
570 -
571 -并没有一种单一的方法确定服务提供商需要多少服务台团队。
572 -
573 -可以从影响工作量关键因素的简单思维图开始分析。这些因素包括：
574 -
575 -* 服务台组织类型
576 -* 排队理论或厄兰变量（Erlang Variables, 查询呼入率、可接受的等待时间、掉线率、队列长度等）
577 -* 服务台团队因其他实践（典型事件，IMAC请求，调查等）而产生的额外工作量
578 -* 用户和客户服务水平期望
579 -* 预期员工流失率
580 -
581 -**4.2.2.1 扁平vs垂直**
582 -
583 -传统认为服务台业务是一项职能或一个团队。将服务台实践和服务台团队区分很重要。服务台团队可能负责几项实践，并将与服务台、事件管理、服务请求管理、问题管理和服务级别管理实践等许多实践互动。构建和定位服务台团队有许多方法，合适的解决方案因组织而异。下面将详细介绍主要的选项，但组织可能需要建立一种结合了多类选项的结构，以便完全满足业务需求。
584 -
585 -
586 -**4.2.2.2 垂直或横向结构**
587 -
588 -在垂直结构中，服务台团队可能包括几个级别（层或线），如果用户问询在当前级别无法解决，则会升级到更高级别。技术知识水平通常随着级别的提高而提高，专业能力也是如此。垂直结构最大限度地减少了昂贵资源的使用，并专注于在尽可能低的级别上解决用户问询。
589 -
590 -在横向结构中，服务台团队拥有更好的沟通线、团队精神和知识共享文化。通常，常见的用户问询待办项与其他工作项一起维护。这样的团队经常使用多功能团队分担问询解决方案的责任。在这种结构中，可伸缩性可能是一个挑战。
591 -
592 -
593 -**4.2.2.3 本地或集中结构**
594 -
595 -在本地部署中，服务台团队位于其所服务的用户办公内或附近。这种部署常有助于沟通，并显示其存在，一些用户喜欢这种方式。这种结构效率低、耗费资源。此外，组织要占据多个地理位置可能不可行。
596 -
597 -将工作人员聚集到一个或多个集中式服务台团队结构中，可使服务台团队合并到一个或较少数量的地点，从而减少服务台团队的数量。这可能更高效、更具成本效益，允许更少的总计人数处理更大数量的用户问询。这种结构还可以通过处理大量熟悉的频繁事态提高技能水平。该结构可能仍然需要保留一些本地人员处理实际的支持需求，但这些人员可以通过集中式服务台控制和部署。
598 -
599 -广域的沟通技术正变得越来越便宜，这意味着更容易拥有远程服务台团队。这种结构还允许弹性化关键技术人员的办公地点，可以是居家工作、离岸外包、二级支持小组和外包。这种结构应特别关注语言和文化差异，以及客户满意度。用户可能会感到被忽视，并认为与服务台团队的关系是官方的和/或缺少人情味的。虚拟的无休服务台团队是集中式服务台团队结构的一个示例。
600 -
601 -
602 -**4.2.2.4 专业化考虑 **
603 -
604 -在规划服务台团队时，了解关键专家归属（在哪个团队、位置、向谁报告等）和工作约束条件很重要。
605 -
606 -
607 -**4.2.2.5 服务设计方法**
608 -
609 -用于组织服务设计的不同方法可能会影响服务台团队的组织方式。在CI/CD方法中，开发和运维间的界限可能模糊，这可能影响服务台团队结构。
610 -
611 -
612 -
613 -----
614 -
615 -= 5. 信息和技术 =
616 -
617 -
618 -
619 -
620 -
621 -== 5.1 信息交流 ==
622 -
623 -
624 -服务台实践的有效性取决于所用信息的质量。这些信息包括但不限于以下信息：
625 -
626 -* 用户
627 -* 服务，包括服务目录、服务请求目录，以及服务级别
628 -* 知识管理系统
629 -* 计划和执行的变更、变更时间表以及变更的可能影响
630 -* 合作伙伴和供应商，包括关于其提供服务的信息
631 -* 规范服务提供的策略和要求
632 -
633 -1. 利益相关方对实践的满意度
634 -
635 -信息可有多种形式。实践的关键输入和输出在第3节中列出。
636 -
637 -
638 -== 5.2 自动化和工具 ==
639 -
640 -
641 -在许多情况下，服务台的工作可从自动化中获得很大好处。在可行且有效的情况下，它可能涉及表5.1中概述的解决方案。
642 -
643 -[[image:1642236032706-313.png]]
644 -
645 -[[image:1642236047390-499.png]]
646 -
647 -表5.1服务台活动的自动化解决方案
648 -
649 -
650 -
651 -----
652 -
653 -= 6 合作伙伴和供应商 =
654 -
655 -
656 -很少的服务是仅用组织自身资源就能交付的。大部分（如果不是全部的话）依赖于其他服务，通常是由组织外的第三方提供的服务（参见ITIL Foundation：ITIL 4出版物第2.4节，服务关系模型）。支持服务引入的关系和依赖关系在《ITIL供应商管理和服务级别管理实践指南》中有相关叙述。
657 -
658 -全球的外部IT服务提供商能够积累和利用相当数量的特定服务台知识和经验。例如，为应对高流动率和工作倦怠的趋势，外部服务提供者必须为服务台员工发明并不断改进高度专业化的招聘、培训和绩效管理技术。这在高速变化的客户和数字转型的背景下尤为重要。
659 -
660 -在商业利益的驱动下，外包服务台流程和团队可以成为组建服务台团队的宝贵资源。在EUC的竞争环境中，最成功的服务台方法应易于根据PSFs选择。潜在客户或良好实践的采用者应该询问某个服务台的想法是否让用户更便利地使用沟通渠道，服务台管理的信息是否能为用户增值。
661 -
662 -当组织的目标是确保快速有效的服务台实践时，他们通常会尝试与合作伙伴和供应商达成紧密合作，消除沟通、协作和决策制定中形式化的官僚壁垒。有关这方面的更多信息，请参阅《供应商管理》实践指南。
663 -
664 -
665 -
666 -----
667 -
668 -= 7 重要提醒 =
669 -
670 -
671 -实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时，各组织应始终遵循ITIL指导原则：
672 -
673 -1. 聚焦价值
674 -1. 从你所处的地方开始
675 -1. 基于反馈迭代推进
676 -1. 协作和提升可视化程度
677 -1. 通盘思考和工作
678 -1. 保持简单实用
679 -1. 优化和自动化
680 -
681 -关于指导原则及其应用的更多信息，请参见ITIL Foundation：ITIL 4出版物第4.3节。
682 -
683 -
684 -
685 -----
686 -
687 -= 8 致谢 =
688 -
689 -
690 -AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员：
691 -
692 -
693 -== 8.1 作者 ==
694 -
695 -
696 -Jamie Bell, Miroslav Hlohovsky, Roman Jouravlev, Konstantin Naryzhny, Helen Nunn
697 -
698 -
699 -== 8.2 审阅者 ==
700 -
701 -
702 -Don Page, Aale Roos
703 -
704 -----
705 -
706 706  (% class="row" %)
707 707  (((
708 708  (% class="col-xs-12 col-sm-4" style="left: 106px; top: 362px;" %)
709 709  (((
710 710  
711 -
712 -
713 -
714 -
715 -
716 -
717 -
718 718  )))
719 719  )))
Icon 1642235400045-491.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -65.6 KB
Content Icon
Icon 1642235424757-755.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -50.2 KB
Content Icon
Icon 1642235551354-545.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -179.4 KB
Content Icon
Icon 1642235569989-774.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -148.2 KB
Content Icon
Icon 1642235622663-611.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -144.4 KB
Content Icon
Icon 1642235627930-339.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -144.4 KB
Content Icon
Icon 1642235731662-569.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -144.3 KB
Content Icon
Icon 1642235775142-492.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -140.8 KB
Content Icon
Icon 1642235790279-634.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -77.8 KB
Content Icon
Icon 1642235912449-908.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -69.9 KB
Content Icon
Icon 1642235925791-414.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -22.7 KB
Content Icon
Icon 1642236032706-313.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -81.4 KB
Content Icon
Icon 1642236047390-499.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -41.2 KB
Content Icon
Icon 1642580581960-553.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -115.8 KB
Content Icon
Icon 1642580603544-786.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -82.0 KB
Content Icon
Icon 1642580673860-313.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -145.2 KB
Content Icon
Icon 微信截图_20210206234644.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -36.4 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司