由 superadmin 于 2024/06/24, 14:36 最后修改
Show last authors
1 [[返回本章节索引>>url:https://itil4hub.cn/bin/view/G%20%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E8%B5%84%E6%96%99/ITIL%E5%AE%9E%E6%96%BD%E9%A1%B9%E7%9B%AE%E6%B5%81%E7%A8%8B%E8%AE%BE%E8%AE%A1%E6%96%B9%E6%A1%88%E9%9B%86/%E7%AE%A1%E7%90%86%E8%A7%84%E8%8C%83/]]  阅读下一篇
2
3
4 = **某公司ITIL信息技术服务管理体系IT服务管理咨询—运行管理规范** =
5
6
7
8 === **1 日常工作管理建议** ===
9
10
11 ===== **1.1 日常管理** =====
12
13 ====== **1.1.1 轮班制度** ======
14
15 信息中心，尤其是服务台小组应当制定一个轮班制度和步骤，并明确由何人负责修改该制度、步骤，由谁授权这些修改，如何发布新的修改，并制定修改的规则，以保障操作员的利益。
16
17 ====== **1.1.2 休假，培训，病假和其他事假** ======
18
19 应当记录并维护所有的缺席状态，确保核心系统总是技术人员能够支持。应当制定审批休假的授权标准，确定授权人，确保现场有足够的人员工作。另外，应当制定备份方案，以防关键人员病假或者其他原因不能到场支持。
20
21 ====== **1.1.3 电话值班** ======
22
23 对于核心业务系统，每天应当确定在正常工作时间之外的主责支持人员和后备人员，称为“电话值班人员”，当天的支持人员应当确保手机等联络工具通畅。特别对于一些不太稳定的系统，工作时间之外可能更需要频繁的现场支持。值班人员应当清楚了解每个支持人员的联系方式，以防主责人员联系不到时可以联系后备人员。
24
25 应当建立内部的服务水平，如：对于紧急电话的响应时间、到现场时间、解决问题的时间等，加强对于紧急事件处理的责任感和效率。
26
27 如果支持人员未能响应，或者未能及时到场，可以采用事件升级的步骤。
28
29
30
31 ===== **1.2 检查清单（备忘录）** =====
32
33 ====== **1.2.1 换班交接检查清单 ** ======
34
35 可以为所有参与操作值班的员工制定一份检查清单，避免员工在交接班的时候遗漏任何应当转交的内容。
36
37 ====== **1.2.2 其他交接清单（如：服务台与操作小组之间的交接）** ======
38
39 同样，也可以为服务台（在工作时间接受事件报告）与操作组（在非工作时段接受事件报告）交接时制定交接清单。该清单应包括所在值班时段发生的重大事件，以及一些需要下一班注意的事项。
40
41 ====== **1.2.3 监控检查清单** ======
42
43 所有的维护组员工应当制定每日维护工作的检查清单，包括每日应当监控和检查的项目（如：必须人工检查的内容，设备指示灯、屏幕、以及运行一些检查脚本程序的结果等），以及其他每日例行的工作。检查清单可以细分为日检查清单、周检查清单、月检查清单、年检查清单。这些清单应当由小组长签字，确保所列项目都已执行。
44
45 如果某个员工遗漏了某些检查项目，必须有正当的理由。
46
47 ====== **1.2.4 值班日记（包括注意事项、意外情况、经验教训等） ** ======
48
49 很多IT部门的操作部门都会维护一份值班日记，纪录值班期间发生的意外情况、注意事项、经验教训等。值班日记也成为交接内容的一个重要部分。
50
51
52 ===== **1.3 公告管理** =====
53
54 “公告”指信息中心对其所服务对象（各业务部门）的信息公示手段，可采用的手段包括系统公告，邮件群发，张贴纸质通告等手段，目的就是将信息最有效的通知到目标人群。
55
56 公告建议由服务台人员统一管理。
57
58 非服务台人员在具备发出公告条件时，需通知服务台人员，由服务台人员负责发出公告，通知方式不限。
59
60
61 ===== **1.3.1 触发条件和通知对象** =====
62
63 |**种类**|**触发条件**|**通知对象**|**公示期限**
64 |文档发放|文档需要发放，如调查表等|文档所针对业务部门|文档有效期内
65 |信息公示|政策，规范等需要公示|信息所针对业务部门|信息有效期内
66 |操作指导|应用系统操作指导|所有用户|操作方式改变后
67 |故障通告|系统故障，对用户造成较大影响时，比如影响程度为1的事件|受影响用户|故障解决后
68 |停机通告|影响为1和2的变更在执行前，需要发出停机通告|受影响用户|变更完成后
69
70
71 ====== **1.3.2 公告用语** ======
72
73 公告包括“标题”“正文”“落款”三个组成部分。
74
75
76 |**种类**|文档发放
77 |**内容要求**|需说明发放部门，接收部门，文档用途，如果需要填写并回收的，需说明负责人、填写方法、回收方式及期限。
78 |**范例**|(((
79 OA系统使用情况调查表发放通知
80
81
82 为配合OA项目组更好的进行系统测试的工作，现下发OA系统使用情况调查表，希望各相关部门予以配合。
83
84 各部门每位OA使用者均需要填写，下载附件调查表并按表内提示填写完成后，交与各部门信息管理员汇总，由信息管理员统一发送至信息中心~*~**处。
85
86 截止日期为~*~*~*~*。
87
88 联系人电话：~*~*~*~*，邮箱：~*~*~*~*
89
90 谢谢配合！
91
92
93 附件：OA系统使用情况调查表.doc
94
95 信息中心
96
97 XXXX-6-20
98 )))
99
100
101 |**种类**|信息公示
102 |**内容要求**|需说明信息内容，信息所针对范围，信息生效和失效时间。
103 |**范例**|(((
104 公司OA系统使用规范v1.0
105
106
107 为配合OA系统的正式启用，现在发布《公司OA系统使用规范》v1.0版，主要是对公司内OA用户进行使用上的指导和规范，以及一些重要功能的操作指导和约束。请各OA用户认真下载阅读。
108
109 本规范从发布之日起生效。
110
111 谢谢配合！
112
113
114 附件：公司OA系统使用规范 v1.0.doc
115
116 信息中心
117
118 XXXX-6-20
119 )))
120
121
122 |**种类**|操作指导
123 |**内容要求**|需要说明系统名称，发布操作指导的原因和使用场景。
124 |**范例**|(((
125 访问公司主页系统乱码处理办法
126
127
128 近日很多用户向信息中心反映，在访问公司主页系统时会在新闻栏看到乱码，为此经过相关技术人员的研究，发现这是用户浏览器终端配置的问题，现将解决办法予以公示，当用户再次遇到类似问题时，可以按照提示自行解决，也可以选择拨打~*~*~*~*请信息中心服务台人员帮助解决。
129
130 谢谢配合！
131
132
133 附件：公司主页系统乱码处理办法.doc
134
135 信息中心
136
137 XXXX-6-20
138 )))
139
140
141 |**种类**|故障通告
142 |**内容要求**|需要说明故障原因，影响范围，预期解决时间，当然还要表示歉意
143 |**范例**|(((
144 6月20日OA系统故障通告
145
146
147 由于数据库系统故障，导致本日10:00开始OA系统停止服务，全公司OA用户均无法登陆OA系统，现在技术人员正在全力解决故障，预计本日15：30之前可以恢复服务。
148
149 因此给您带来的不便我们表示万分抱歉！并谢谢您的配合和谅解！
150
151
152 信息中心
153
154 XXXX-6-20
155 )))
156
157
158 |**种类**|停机通告
159 |**内容要求**|需要说明停机原因，影响范围，预期恢复时间，当然还要表示歉意
160 |**范例**|(((
161 6月22日OA系统停机通告
162
163
164 为了使OA系统可以更加稳定和高效的运行，经过信息中心及OA项目组研究决定，计划在6月22日19:00到23:00进行OA系统数据库升级，期间OA系统将停止服务，请各部门用户届时提前结束OA系统上的工作，并在此期间不要尝试登录OA系统。
165
166 因此给您带来的不便我们表示万分抱歉！并谢谢您的配合和谅解！
167
168
169 信息中心
170
171 XXXX-6-22
172 )))
173
174
175
176 === **2 服务台运行管理** ===
177
178
179 ===== **2.1 电话接听规范** =====
180
181 ====== **2.1.1 接听电话应当迅速** ======
182
183 1、服务台人员应在电话铃响起三声内接起,延迟应表示歉意。
184
185 2、电话响起时，服务台人员不在，应由其他服务台人员接起电话，以不耽误客户为主。
186
187 3、在电话铃响时，一面用左手拿起话筒，而右手马上伸到便条纸边，只要能采取这种姿势，应对的内容自然也会得体。
188
189 4、如使用悬挂式耳机和相关的信息记录系统，应在接起电话后迅速打开电脑记录页面，将电话中获取到的信息记录在系统中。
190
191
192 ====== **2.1.2 电话用语** ======
193
194 1. 使用 “您好”，“请问”，“不用客气”，“再见”等文明用语,不使用“嗨”，“唉”等不礼貌用语。
195 1. 声音甜美，声调稍微高一点使客户容易听清楚，不要把不好的情绪带进电话。
196 1. 报部门名称，询问客户部门等具体具体信息。
197 1. 询问客户问题详细情况，仔细倾听并记录。
198 1. 勿忘5W1H及电话中的传达和复诵。“5W1H”即：何时（WHEN），谁（WHO，WHOSE），何地（WHERE），何事（WHAT），如何处理（HOW）。传达时应力求简捷。为防止错误，应该在最后说：“请让我确认一下您刚才所说的话。”而复诵所记下的内容，倘若双方有传错或听错的情形，便可以在此时改过来，除此之外，如果是我们打过去的电话，而对方没有复诵时，我们也可以尽量要求对方再复诵一遍，以确认对方是否已正确的记下我们所要传达的事情。
199 1. 语速不要太快，解释尽量详细，以最终解决问题为目的。
200 1. 接电话时尽量不去接别的电话。
201 1. 不要主动提出挂电话。
202
203
204 ====== **2.1.3 工作时间不允许公话私用** ======
205
206 不允许在工作时间用服务台电话打私人电话。打到公司的电话，并不一定是有关公事，有时候是职员的家人或朋友打来的私人电话，由于私人电话很可能会妨碍到公事，应尽可能请家人或朋友打私人电话。但如果非常重要的事情，不得不在公司接听电话时，应该力求简洁，把要联络的事情说完即可，避免电话占线。
207
208
209
210 ===== **2.2 Case受理规范** =====
211
212 ====== **2.2.1 客户信息记录准确** ======
213
214 受理Case时首先要询问员工编号，没有员工编号的可以记录临时邮件账号或联系电话，以便进行Case问题的跟踪及进行信息反馈。
215
216 ====== **2.2.2 问题信息记录准确** ======
217
218 详细记录客户描述的问题现象，当可以解决问题时需记录问题原因及解决方法，以便放到知识库中使资源共享。未能解决的问题可以分发给现场或进行初步处理，进行初步处理的Case要对问题进行跟踪，直到问题解决。
219
220 ====== **2.2.3 处理客户投诉遵循的原则** ======
221
222 ====== **2.2.4 状态跟踪机制** ======
223
224 我们遇到投诉或者是投诉升级的时候经常会发现，好像每个处理的人都做了合理的事情，但是投诉还是产生和升级了。其实这就是由于没有一个事件跟踪的流程导致的，很多部门配合的时候更容易出现这样的情况，因此说这种事件状态跟踪机制是必需的，而且不仅仅是在投诉的处理上面。事情的处理一定是闭环的，有头有尾的。
225
226 服务台人员必须首先对自己接手处理的事件负责，有责任和义务跟踪自己处理事件的当前状态并在需要时反馈给用户。
227
228 服务台经理对整个服务台的事件处理情况负责。
229
230
231
232 ====== **2.2.5 投诉升级机制** ======
233
234 有了状态跟踪机制其实并不能保证事情得到及时的处理，这需要另外一个机制来控制——投诉处理升级机制。如果一件事情在相应规定的时间没有解决掉，相关的管理者会逐级得到信息——该投诉未能及时处理完成以及当前的状态。这样相应的管理人员就逐渐参与到投诉的处理当中，加快事件的处理。而一般的投诉专人负责的岗位就已经可以处理了，管理者只需要按时得到每周的报告就可以了。
235
236 事件超时时会自动升级至事件经理，事件经理通常是服务台经理兼任，事件经理有责任和权利协调资源优先处理升级事件，包括与二线团队协调资源。
237
238 ====== **2.2.6 报告机制** ======
239
240 已经有跟踪、升级处理等机制，但如果想把用户投诉的问题转化为服务提升的动力，那详细的分析报告将是非常重要和必需的。一个简单扼要、眼光敏锐、总结分析到位的报告对管理者提升服务来说是很有帮助的。
241
242 服务台建议设置周报和月报制度，每周和每月定时将报告汇总给服务台经理。
243
244 ====== **2.2.7 回访处理** ======
245
246 投诉处理结束了，我们还有事情要做，就是对曾经投诉我们服务的用户进行回访，投诉过你的用户今后可能还是你的用户，请他谈谈对改进后的服务的看法，听听用户对整体服务的意见和建议。
247
248
249
250 ===== **2.3 处理投诉的基本方法** =====
251
252 以下为对于服务台人员在处理投诉时的基本方法建议，实际上这些建议对于非投诉类Case的处理一样适用。
253
254 ====== **2.3.1 用心聆听** ======
255
256 聆听是一门艺术，从中你可以发现客户的真正需求，从而获得处理投诉的重要信息。
257
258 ====== **2.3.2 表示道歉** ======
259
260 如果你没有出错，就没有理由惊慌，如你真的出错，就得勇于面对。请记住客户之所以动气是因遇上问题，你漠不关心或据理力争。找借口或拒绝，只会使对方火上加油，适时的表示歉意会起到意想不到的效果。
261
262 ====== **2.3.3 仔细询问** ======
263
264 引导用户说出问题重点，有的放矢。表示同情如果对方知道你的确关心他的问题，也了解他的心情，怒气便会消减一半。找出双方一起同意的观点，表明你是理解他的。
265
266 ====== **2.3.4 记录问题** ======
267
268 对于投诉类的问题，必须忠实详尽的记录投诉者、投诉的原因、被投诉者、内容、处理过程、解决情况等信息。
269
270 ====== **2.3.5 解决问题** ======
271
272 探询客户希望解决的办法，一旦你找出方法，征求客户的同意。如果客户不接受你的办法，请问他有什么提议或希望解决的方法，不论你是否有权决定，让客户随时清楚地了解你的进程。如果你无法解决，可推荐其他合适的人，但要主动地代为联络。礼貌地结束。当你将这件不愉快的事情解决了之后，必须问：请问您觉得这样处理可以了吗？您还有别的问题吗？……。如果没有，就多谢对方提出的问题。
273
274
275
276 ===== **2.4 培训制度** =====
277
278 培训是服务台服务的重要成功因素。若没有适当的初期和持续培训，服务台将不能提供最佳的客户服务。持续培训可以使服务台人员掌握所需技能。它也可以提高生产力，改善客户服务，此外还能增加服务台人员的工作满意程度，自信心。
279
280 |**种类**|**机制**|**内容**|**培训者**
281 |上岗培训|上岗前培训，每名服务台人员必须接受至少一次上岗培训|(((
282 ITIL基础理论
283
284 服务台的概况和职能
285
286 运行管理规范
287
288 ITSM系统软件使用
289
290 一周观摩学习
291 )))|(((
292 服务台经理
293
294 服务台资深员工
295
296 专业培训人员
297 )))
298 |进阶培训|进阶培训的主要目的是提高服务台人员的工作效率和工作热情，内容主要是工作经验的分享和技巧的传授，不定期开展。|(((
299 工作总结
300
301 经验教训总结
302
303 典型案例分享
304
305 新技巧传授
306 )))|(((
307 服务台经理
308
309 服务台资深员工
310 )))
311 |专业技能培训|由服务台经理协调二线支持团队不定期进行专业技能的培训。目的为提高服务台人员的工作能力，并提高一线解决率。|(((
312 终端维护技能
313
314 ITSM系统软件使用
315
316 各系统常见故障处理等
317 )))|二线支持团队
318 |日常培训|即为传统意义上的“传帮带”|服务台日常工作熟练|服务台资深员工
319
320
321 ===== =====
322
323 ===== **2.5 考核标准** =====
324
325 以下是对服务台工作的考核标准
326
327 ====== **2.5.1 电话接通率和响应时间** ======
328
329 |类型|指标|目标|检查周期|定义
330 |接通率|<50|20|月|没有接通电话的量（主要指无人接听或非正常占线）。
331
332
333 ====== **2.5.2 客户满意度** ======
334
335 |类型|指标|目标|检查周期|定义
336 |客户满意度|85%|95%|月|(满意＋非常满意)/反馈数*100%
337
338
339 ====== **2.5.3 本月投诉 ** ======
340
341 |类型|指标|目标|检查周期|定义
342 |投诉|5%|1%|月|当月用户有效投诉数量/当月全部事件数量*100%
343
344
345 ====== **2.5.4 服务台解决率** ======
346
347 |类型|指标|目标|检查周期|定义
348 |解决率|50%|70 %|月|是否再被转到二线支持(不能在服务台得到解决)
349
350
351
352 === **3 流程运行管理规范** ===
353
354 ===== =====
355
356 ===== **3.1 工单分派** =====
357
358 ====== **3.1.1 技能组设置表** ======
359
360 为了支持运维流程的正常运转，有必要将信息中心所有IT支持人员进行编组，一般会按照其运维职责和技能情况进行编组。
361
362 流程设计和组织人员调整时，需填写技能组列表和人员技能组对应表，所需表格格式如下：
363
364 **技能组列表：**
365
366 |**部门**|**技能组**|**职责**|**默认联系人**
367 |(% rowspan="6" %)网络技术科|终端组|桌面终端系统维护|
368 |网管组|网络管理，网络设备维护|
369 |安全组|安全策略，安全设备维护|
370 |系统组|机房、主机、操作系统维护|
371 |数据库组|数据库维护|
372 |应用组|已交付生产的应用系统维护|
373 |(% rowspan="7" %)应用系统科|许可证管理系统组|许可证管理系统需求管理和研发|
374 |生产系统组|生产系统需求管理和研发|
375 |财务系统组|财务系统需求管理和研发|
376 |OA系统组|OA系统需求管理和研发|
377 |主页系统组|主页系统需求管理和研发|
378 |邮件系统组|邮件系统需求管理和研发|
379 |……| |
380
381
382 **人员技能组对应表：**
383
384 |**部门**|**职务**|**姓名**|**技能组（逗号分隔）**
385 | | | |
386 | | | |
387 | | | |
388 | | | |
389 | | | |
390 | | | |
391 | | | |
392
393
394 ====== **3.1.2 分派规范** ======
395
396 在ITSM系统中，技能组是工单分派的基本单元，工单将按照分类分派到与此分类有映射关系的技能组。
397
398 在流程设计和组织调整时，需填写分类与技能组对应表，下表为格式参考样例：
399
400 |**类别**|**子类**|**条目**|**技能组（逗号分隔，优先排序）**
401 |桌面|服务|镜像恢复|终端组
402 | | |硬件安装|终端组
403 | | |应用软件安装|终端组
404 | | |病毒处理|终端组
405 | | |应用客户端版本更新|终端组，应用组
406 | | |打印驱动|终端组
407 | |故障|硬件故障|终端组
408 | | |操作系统故障|终端组
409 | | |MS Office应用故障|终端组
410 | | |企业应用系统故障|终端组
411 | | |网络连通性故障|终端组，网络组
412 | | |打印故障|终端组
413
414
415 ====== **3.1.3 优先选择规范** ======
416
417 当同一分类有多个技能组可选择对应时，需指定优先顺序，如：桌面类网络故障有终端组和网络组可选，应优先选择终端组，只有当终端组人员紧张或拒绝接受工单时才可以选择非优先的技能组。
418
419 优先选择规范在ITSM系统中应该有具体的提示，但不具备强制性。
420
421
422 ====== **3.1.4 AB角规范 ** ======
423
424 每个技能组内部将实行“AB角”制度，设定一名员工为“A角”即“默认联系人”，其他组内人员为“B角”，当工单派发至技能组时，A角有权利同时也有义务第一时间代表所在技能组接受指派，当A角人员处于忙碌或不可用状态时，由B角人员代替。
425
426 “AB角”不是管理职位，其目的是为了流程的流畅运行，一名员工在甲技能组是“A角”，在乙技能组亦可能是“B角”。
427
428 “AB角”在ITSM流程中不存在强制性，由AB角人员自行判断接单。
429
430 每个员工应清楚了解自己在技能组中的角色位置，并履行权利义务。
431
432
433
434 ===== **3.2 工单信息填写** =====
435
436 在ITSM系统中的工单是由数十个信息项（字段）构成的电子表单，这些信息项分别承载记录了工单不同的信息，在填写时，首先需要根据提示区分必填、选填、只读字段。
437
438 必填字段为必须填写的字段，一般会在表单上以红色*号表示；
439
440 选填字段是一般的空白字段，可以按照需要选择填写或者留空；
441
442 只读字段是不允许填写或修改的字段，一般会在表单上以灰色填充表示。
443
444
445 此外，按照信息项种类的不同，填写时需遵循以下规范：
446
447 |序号|信息项|填写说明
448 |1|人员信息项|此类信息一般为相互关联的数个字段组成，如姓名、员工编码、电话等等，填写此类信息时一般填写其中一项即可自动完成其他信息，填写时注意务求准确。
449 |2|时间信息项|此类信息一般为固定格式的字段，也会有专门的日历表填写框供选择，填写此类信息需要注意的就是尽量不要手工修改字段中的日期时间格式，以免出错。另外，如果有相互关联的时间信息项，如计划开始时间和结束时间，填写时应注意不要将结束时间早于开始时间。
450 |3|预定内容信息项|下拉菜单、弹出式选择框等均为此类信息项，如事件类型、来源等信息。填写此类信息需要注意的就是应尽量避免选择错误，因为这些信息大多数时候都决定了流程的流转方向。
451 |4|工单分类|分类严格来说属于预定内容信息项，之所以单独提出足以说明其重要性，分类是系统区分工单流转的重要手段，填写时务必做到准确。ITSM系统的分类分为三级，选择时应按照“分类—子类—条目”的顺序逐级选择。其判断方法一般为工单发生的“所属系统主体”和“性质”
452 |5|工单标题|(((
453 工单的标题是快速了解工单内容的重要手段，填写的要求必须简明扼要。一般按照“时间+部门+主体+性质”的方式描述。
454
455 如：
456
457 事件标题“6月20日上午10点财务中心OA系统无法访问”
458
459 变更标题“6月22日下午7点网络技术科OA系统数据库升级”
460 )))
461 |6|工单详细信息|(((
462 详细信息用来对工单进行详细的说明和描述，详细信息一般为一个大容量的文本框，可以容纳足够多的信息。在填写时务必细致，准确，有条理的进行陈述。
463
464 其内容应包括：
465
466 发生时间、影响范围、事件症状或变更原因、期望或预计的恢复时间等等
467
468 如果是变更、发布、需求等信息中心内部流转工单，其详细信息应更加专业和准确。以确保受理人可以根据描述获取所需的关键信息。必要时，还需要通过附件Word文档来进行更加详细的说明。
469 )))
470
471
472
473
474 ===== **3.3 事件管理** =====
475
476 ====== **3.3.1 应用场景** ======
477
478 事件管理主要功能是尽快解决出现的突发事件，保持业务系统的稳定性。
479
480 下表为事件管理流程的应用场景和说明，在如下场景中，将使用事件管理流程来处理：
481
482 |**序号**|**场景**|**说明**
483 |1|故障处理|已提供的服务发生故障导致的服务中断或者服务质量下降
484 |2|咨询服务|用户以电话或其他方式提出的信息咨询或操作指导请求
485 |3|投诉处理|用户投诉的记录和处理
486 |4|服务请求|某些无需填写服务申请单的服务请求允许通过事件单处理
487 |5|监控告警|监控工具转发过来的告警，需要转交技术人员处理
488
489
490 ====== **3.3.2 各节点检查事项说明** ======
491
492 检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
493
494 这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
495
496
497 |**检查点**|**负责人**|**检查事项**
498 |服务台接单|服务台|(((
499 * 请求人和地点信息
500 * 报告时间和创建时间
501 * 事件分类、优先级和完成期限
502 * 事件标题和描述
503 * 关联配置项和其他工单
504 * 附件
505 )))
506 |二线接单|二线支持|(((
507 * 请求人和地点信息
508 * 报告时间和创建时间
509 * 事件分类、优先级和完成期限
510 * 事件标题和描述
511 * 关联配置项和其他工单
512 * 附件和日志
513 )))
514 |已解决事件|服务台|(((
515 * 请求人和地点信息
516 * 事件分类、优先级和完成期限
517 * 事件标题和描述
518 * 解决时间
519 * 解决方案
520 * 关联配置项和其他工单
521 * 附件和日志
522 )))
523 |跟踪回顾|N/A|(((
524 * 事件状态
525 * 受理人和流转日志
526 * 事件分类、优先级和完成期限
527 * 主从事件标记
528 * 是否超时标志
529 * 实际开始和完成时间
530 * 附件和日志
531 )))
532
533
534 ====== **​​​​​​​3.3.3 流程负责人制度** ======
535
536 事件管理各角色和职责：
537
538 |**角色**|**职责描述**
539 |流程负责人|(((
540 * 推动、推广事件管理流程，对流程的整体效果和效率负责。
541 )))
542 |用户|(((
543 * 负责提交事件，并准备事件的描述
544 )))
545 |事件经理|(((
546 * 负责对事件的解决协调资源，保证故障的最终排除
547 * 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进支持工程师快速恢复正常服务
548 * 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题
549 )))
550 |服务台|(((
551 * 在指定的响应时间内响应所有服务台热线电话、邮件、MSN等事件报告并完整记录事件信息
552 * 为事件进行适当的分类、为事件分配优先级等属性
553 * 尝试初步诊断、分析相关信息等方式解决问题
554 * 将事件分配给最合适的二线支持小组来处理
555 * 检查事件记录的处理进度
556 * 与用户确认事件解决方案，关闭事件
557 )))
558 |二线支持人员|(((
559 * 负责对分发来的事件进行处理
560 * 二线人员按照技能划分不同的小组
561 )))
562
563
564 工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
565
566
567 |**状态**|**描述**|**责任人**
568 |New（新建）|一个事件被记录或创建|创建人（服务台）
569 |Assigned（已分派）|一个事件已被分派给事件记录员，事件分析员（二线）|受理人
570 |Pending（等待中）|事件信息不完整，或在某些情况下阻止事件记录员或事件分析员对事件，问题分析员对问题进行处理，需要填写等待代码：|受理人
571 |Work In progress（处理中）|任何一个事件分析员（二线支持）接受了事件|受理人
572 |Resolved（已解决）|为一个事件找到解决方案或变通方法|创建人（服务台）
573 |Closed（已关闭）|事件已经关闭|创建人（服务台）
574
575
576 ====== **​​​​​​​3.3.4 考核指标** ======
577
578 流程考核指标参考：
579
580 |**种类**|**指标**|**计算方法**
581 |(% rowspan="6" %)流程
582 有效性|事件总数|(((
583 数量：在事件单中根据以下条件过滤
584
585 1. 【事件结束代码】不等于‘取消’
586 1. 【事件发生时间】在统计周期内
587 )))
588 |事件关闭的数量|数量 ：在事件总数中过滤【事件状态】＝‘已关闭’
589 |事件成功关闭的数量/比率|(((
590 数量：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’ or ‘服务提供商解决”
591
592 比率：数量 / 事件总数  × 100 %
593 )))
594 |规定时间内解决的事件数量/百分比|(((
595 数量：在事件总数中过滤【处理是否超时】＝“未超时”以及【事件结束代码】＝“成功解决”或“变通方法解决”
596
597 比率：数量/事件总数 × 100 %
598 )))
599 |超时未解决的事件数量|数量：在事件总数中过滤【处理已超时】＝“超时”以及【事件状态】！=“已解决”或“关闭”
600 |规定时间内响应的事件数量/百分比|(((
601 数量：在事件总数中过滤（【实际开始时间】－【登记时间】）< 优先级对应的响应时限
602
603 比率：数量/事件总数 × 100 %
604 )))
605 |(% rowspan="3" %)执行
606 效率|平均解决时间|(((
607 完成的事件：在事件总数中过滤所有【事件状态】＝“已解决”或“关闭”的事件
608
609 平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量
610 )))
611 |服务台解决率|(((
612 数量：在事件总数中过滤所有【事件解决人角色】＝“服务台”
613
614 比率：数量 / 事件总数 × 100 %
615 )))
616 |事件的一次解决率|(((
617 数量1：在事件总数中过滤【事件结束代码】＝“成功解决”或“变通方法解决”
618
619 数量2：在事件总数中过滤【事件结束代码】＝“不成功”
620
621 比率：（数量1－数量2 ） / 数量1 × 100 %
622 )))
623
624
625 ====== **3.3.5 回顾机制** ======
626
627 一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
628
629 流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
630
631 流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
632
633 流程回顾例会应包括以下内容：
634
635 |**回顾任务**|**描述**|**负责人**
636 |流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
637 服务台/事件经理
638
639 流程负责人
640 )))
641 |流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
642 服务台/事件经理
643
644 流程负责人
645 )))
646 |数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，某些重复事件需要升级为问题|(((
647 服务台/事件经理
648
649 流程负责人
650 )))
651 |案例分析|典型案例分析|(((
652 服务台/事件经理
653
654 流程负责人
655 )))
656 |KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
657 服务台/事件经理
658
659 流程负责人
660 )))
661 |流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果|(((
662 服务台/事件经理
663
664 流程负责人
665 )))
666
667
668
669 ===== **3.4 服务请求管理** =====
670
671 ====== **3.4.1 应用场景** ======
672
673 服务请求管理主要功能提供一个清晰的服务目录，提升IT服务的专业性，并降低沟通成本。
674
675 服务请求首先是配合着服务目录来决定对外提供哪些服务的，在江苏核电的环境中，服务请求用来处理所有需要用户填写申请表单的服务申请。
676
677 下表为服务请求流程的服务目录，在服务目录所列条目内的所有服务，将使用服务请求管理流程来处理，服务目录是随时更新的：
678
679 |**序号**|**场景**|**说明**|**需审批**
680 |(% rowspan="10" %)桌面终端|(% rowspan="5" %)硬件终端服务|办公电脑领用申请|N
681 |办公电脑调拨移动申请|
682 |数码配件升级更换申请|
683 |办公电脑借用申请|
684 |办公电脑回收申请|
685 |(% rowspan="5" %)软件终端服务|镜像恢复申请|N
686 |应用软件安装申请|N
687 |安全和专项软件安装申请|
688 |账号密码重置申请|N
689 |部门计算机管理员变更申请|
690 |(% rowspan="7" %)基础设施|(% rowspan="4" %)网络通讯类服务|网络访问开通申请|
691 |VPN开通申请|
692 |防火墙变更申请|
693 |网络建设维护申请|
694 |主机存储类服务|服务器空间资源申请|
695 |系统软件类服务|操作系统安装申请（服务器）|
696 |机房类服务|机房出入权限申请|
697 |(% rowspan="7" %)业务系统|(% rowspan="2" %)OA系统服务|内部员工OA账号权限申请|N
698 |外部员工临时OA账号权限申请|
699 |(% rowspan="2" %)邮件系统服务|内部员工邮件账号权限申请|N
700 |外部员工临时邮件账号权限申请|
701 |(% rowspan="2" %)ERP系统服务|内部员工ERP系统账号权限申请|N
702 |外部员工临时ERP系统账号权限申请|
703 |……|……|
704 |(% rowspan="2" %)通用服务|业务咨询类服务|业务培训申请|
705 |数据查询类服务|数据查询申请|
706
707
708 **3.4.2 各节点检查事项说明**
709
710 检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
711
712 这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
713
714
715 |(((
716 ====== **检查点** ======
717 )))|(((
718 ====== **负责人** ======
719 )))|(((
720 ====== **检查事项** ======
721 )))
722 |(((
723 ====== 业务审批 ======
724 )))|(((
725 ====== 业务审批人 ======
726 )))|(((
727 * (((
728 ====== 请求人和地点信息 ======
729 )))
730 * (((
731 ====== 创建时间 ======
732 )))
733 * (((
734 ====== 分类、紧急度和完成期限 ======
735 )))
736 * (((
737 ====== 标题和描述 ======
738 )))
739 * (((
740 ====== 相关自定义字段 ======
741 )))
742 * (((
743 ====== 备注和附件 ======
744 )))
745 )))
746 |(((
747 ====== IT部门审批 ======
748 )))|(((
749 ====== IT审批人 ======
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 ====== 标题和描述 ======
786 )))
787 * (((
788 ====== 相关自定义字段 ======
789 )))
790 * (((
791 ====== 备注和附件 ======
792 )))
793 )))
794 |(((
795 ====== 跟踪回顾 ======
796 )))|(((
797 ====== N/A ======
798 )))|(((
799 * (((
800 ====== 服务请求状态 ======
801 )))
802 * (((
803 ====== 审批人、受理人和流转日志 ======
804 )))
805 * (((
806 ====== 分类、紧急度和完成期限 ======
807 )))
808 * (((
809 ====== 审批代码和完成信息 ======
810 )))
811 * (((
812 ====== 是否超时标志 ======
813 )))
814 * (((
815 ====== 实际开始和完成时间 ======
816 )))
817 * (((
818 ====== 相关自定义字段 ======
819 )))
820 * (((
821 ====== 附件和日志 ======
822 )))
823 )))
824
825 ====== ======
826
827 ====== **3.4.3 流程负责人制度** ======
828
829 服务请求管理各角色和职责：
830
831 |**角色**|**职责描述**
832 |服务请求人|提交服务请求单，确认最后的服务效果，关闭服务请求单
833 |服务请求审批人|审批服务请求的必要性
834 |服务请求经理|审批服务请求的可行性和安全性，并指派受理人
835 |服务请求受理人|处理服务请求，将处理结果反馈
836
837
838 工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
839
840
841 |**状态**|**描述**|**责任人**
842 |New（新建）|一个服务请求单被记录或创建|请求人
843 |Approving （审批中）|正在审批服务请求|业务和IT审批人
844 |Assigned（已分派）|已被分派给受理人|受理人
845 |Pending（等待中）|信息不完整，或在某些情况下阻止受理人对服务请求进行处理，需要填写等待代码|受理人
846 |Work In progress（处理中）|任何一个受理人接受了事件|受理人
847 |Completed（已完成）|已经完成服务请求|请求人
848 |Closed（已关闭）|已经关闭|请求人
849
850
851 ====== **3.4.4 考核指标** ======
852
853 流程考核指标参考：
854
855 |**种类**|**指标**|**计算方法**
856 |(% rowspan="6" %)流程
857 有效性|服务请求总数|(((
858 数量：在服务请求单中根据以下条件过滤
859
860 1. 【服务请求结束代码】不等于‘取消’
861 1. 【服务请求发生时间】在统计周期内
862 )))
863 |服务请求关闭的数量|数量 ：在服务请求总数中过滤【服务请求状态】＝‘已关闭’
864 |服务请求成功关闭的数量/比率|(((
865 数量：在服务请求总数中过滤【服务请求结束代码】＝处理成功
866
867 比率：数量 / 服务请求总数  × 100 %
868 )))
869 |规定时间内解决的服务请求数量/百分比|(((
870 数量：在服务请求总数中过滤【处理是否超时】＝“未超时”以及【服务请求结束代码】＝处理成功
871
872 比率：数量/服务请求总数 × 100 %
873 )))
874 |超时未解决的服务请求数量|数量：在服务请求总数中过滤【处理已超时】＝“超时”以及【服务请求状态】！=“处理成功”或“关闭”
875 |规定时间内响应的服务请求数量/百分比|(((
876 数量：在服务请求总数中过滤（【实际开始时间】－【登记时间】）< 优先级对应的响应时限
877
878 比率：数量/服务请求总数 × 100 %
879 )))
880 |(% rowspan="3" %)执行
881 效率|平均解决时间|完成的服务请求：在服务请求总数中过滤所有【服务请求状态】＝“处理成功”或“关闭”的服务请求平均解决时间：累加完成服务请求的（【实际完成时间】－【登记时间】）/ 完成的服务请求数量
882 |解决率|(((
883 数量：在服务请求总数中过滤所有【服务请求解决人角色】＝“技能组名称”
884
885 比率：数量 / 服务请求总数 × 100 %
886 )))
887 |服务请求的一次解决率|(((
888 数量1：在服务请求总数中过滤【服务请求结束代码】＝“处理成功”
889
890 数量2：在服务请求总数中过滤【服务请求结束代码】＝“不成功”
891
892 比率：（数量1－数量2 ） / 数量1 × 100 %
893 )))
894
895
896 ====== **​​​​​​​​​​​​​​3.4.5 回顾机制** ======
897
898 一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
899
900 流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
901
902 流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
903
904 流程回顾例会应包括以下内容：
905
906 |**回顾任务**|**描述**|**负责人**
907 |流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
908 服务请求经理
909
910 流程负责人
911 )))
912 |流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
913 服务请求经理
914
915 流程负责人
916 )))
917 |数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，某些重复性较高的服务请求是否可以省去审批过程|(((
918 服务请求经理
919
920 流程负责人
921 )))
922 |案例分析|典型案例分析|(((
923 服务请求经理
924
925 流程负责人
926 )))
927 |KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
928 服务请求经理
929
930 流程负责人
931 )))
932 |流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
933 服务请求经理
934
935 流程负责人
936 )))
937
938
939
940 ===== **3.5 问题管理** =====
941
942 ====== **3.5.1 应用场景** ======
943
944 问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。
945
946 对于问题管理而言，问题的产生主要来自于四个方面：
947
948 |**序号**|**场景**|**说明**
949 |1|紧急事件触发|(((
950 紧急事件恢复服务后关联提出的问题，以便进行紧急事件的根本原因分析
951
952 【例如】：某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，紧急事件的处理人员在采取了手工切换的替代措施后，恢复了服务为了分析为什么会发生该紧急事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该紧急事件进行分析
953 )))
954 |2|系统维护中提出的问题|(((
955 二线支持在日常维护工作中提出的问题
956
957 【例如】：维护专家在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便分析
958 )))
959 |3|事件趋势分析|(((
960 分析事件记录找出的问题
961
962 【例如】：在定期的会议中，对某应用系统操作咨询类的事件进行分析后发现，上一阶段该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明该应用系统操作有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决
963 )))
964 |4|失败变更产生问题|变更失败后，可能需要生成一个问题进入后续的解决过程
965
966
967 ====== **3.5.2 各节点检查事项说明** ======
968
969 检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
970
971 这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
972
973
974 |**检查点**|**负责人**|**检查事项**
975 |问题确认、分类分派|问题经理|(((
976 * 请求人和地点信息
977 * 创建时间
978 * 问题分类、优先级
979 * 问题来源
980 * 问题标题和描述
981 * 关联配置项和其他工单
982 * 附件
983 )))
984 |问题调查诊断和处理|问题分析员|(((
985 * 请求人和地点信息
986 * 问题分类、优先级
987 * 问题来源
988 * 问题原因
989 * 问题标题和描述
990 * 重复问题标记
991 * 关联配置项和其他工单
992 * 问题日志
993 * 备注项和附件
994 )))
995 |问题验证|问题经理|(((
996 * 问题分类、优先级
997 * 问题来源
998 * 问题原因
999 * 问题标题和描述
1000 * 关联配置项和其他工单
1001 * 解决方案
1002 * 问题日志
1003 * 备注项和附件
1004 )))
1005 |跟踪回顾|N/A|(((
1006 * 问题状态
1007 * 受理人和流转日志
1008 * 分类、优先级
1009 * 问题来源和解决方案
1010 * 是否超时标志
1011 * 实际开始和完成时间
1012 * 日志
1013 * 备注项和附件
1014 )))
1015
1016
1017 ====== **3.5.3 流程负责人制度** ======
1018
1019 问题管理各角色和职责：
1020
1021 |**角色**|**职责描述**
1022 |流程负责人|(((
1023 * 推动、推广问题管理流程，对流程的整体效果和效率负责。
1024 )))
1025 |问题分析员|(((
1026 * 接受问题经理分派过来的问题
1027 * 分析和诊断问题，确定根本原因
1028 * 确定和测试解决方案
1029 * 提交变更请求并监控变更实施
1030 * 协助事件支持人员进行重大或紧急事件的处理
1031 * 需要时协调第三方的资源来帮助诊断和改正问题
1032 )))
1033 |问题经理|(((
1034 * 领导问题管理小组，确保大家的积极性、技能水平
1035 * 定期组织相关人员对事件记录进行分析，发现潜在问题
1036 * 确认和审核问题
1037 * 必要时对问题进行上报
1038 * 监视问题的诊断、分析和处理过程
1039 * 必要时与帮助台及问题请求者沟通问题的相关信息
1040 * 必要时协调所需资源
1041 * 定期制定问题报表，提供正确决策信息
1042 )))
1043
1044
1045 工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
1046
1047
1048 |**状态**|**描述**|**责任人**
1049 |New（新建）|一个问题被记录或创建|问题分析员
1050 |Assigned （已分配）|一个问题已被分派给问题分析员或问题经理 |问题分析员/问题经理
1051 |Pending （等待中）|问题信息不完整，或在某些情况下阻止问题分析员对问题进行处理，进入等待|问题分析员
1052 |Work in Progress （处理中）|一个问题分析员接受了问题，并正在处理 |问题分析员
1053 |Resolved （已解决）|为一个问题找到解决方案或变通方法 |问题经理
1054 |Closed （已关闭）|问题已经关闭|问题经理
1055
1056
1057 ====== **3.5.4 考核指标** ======
1058
1059 流程考核指标参考：
1060
1061 |**种类**|**指标**|**计算方法**
1062 |(% rowspan="5" %)流程
1063 有效性|问题总数|(((
1064 数量：在问题单中根据以下条件过滤
1065
1066 ~1. 【重复问题标记】为空
1067
1068 2. 【问题结束代码】不等于“取消”
1069
1070 3. 【登记时间】在统计周期内
1071 )))
1072 |已找到根本原因的问题数量|数量：在问题总数中，【问题状态】=“已定位原因”的问题数量
1073 |趋势分析问题所占比率|(((
1074 数量：在问题总数中，【问题来源】=“趋势分析”的问题数量
1075
1076 比率：数量 / 问题总数  × 100 %
1077 )))
1078 |关闭问题数量|数量：【问题关闭时间】在统计周期内，【问题状态】=“结束并关闭”的问题数量
1079 |通过变通办法解决的问题数量|数量：在关闭问题数量中，【问题结束代码】=“变通方法”的问题数量
1080 |(% rowspan="2" %)执行
1081 效率|问题成功解决率|(((
1082 数量：在关闭问题数量中，【问题结束代码】=“根本解决”的问题个数
1083
1084 比率：数量 /关闭问题数量  × 100 %
1085 )))
1086 |平均诊断时间|(((
1087 诊断完成问题数量：【实际诊断结束时间】在统计周期内的问题个数
1088
1089 平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
1090 )))
1091
1092
1093 ====== **​​​​​​​3.5.5 回顾机制** ======
1094
1095 一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
1096
1097 流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
1098
1099 流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
1100
1101 流程回顾例会应包括以下内容：
1102
1103 |**回顾任务**|**描述**|**负责人**
1104 |流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
1105 问题经理
1106
1107 流程负责人
1108 )))
1109 |流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
1110 问题经理
1111
1112 流程负责人
1113 )))
1114 |数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，找到根源的问题等|(((
1115 问题经理
1116
1117 流程负责人
1118 )))
1119 |案例分析|典型案例分析|(((
1120 问题经理
1121
1122 问题分析员
1123
1124 流程负责人
1125 )))
1126 |KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
1127 问题经理
1128
1129 流程负责人
1130 )))
1131 |流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
1132 问题经理
1133
1134 流程负责人
1135 )))
1136
1137
1138
1139 ===== **3.6 变更管理** =====
1140
1141 ====== **3.6.1 应用场景** ======
1142
1143 变更管理流程的根本目的是通过严格的控制将变更操作对生产环境产生的影响降到最小。
1144
1145 根据变更对象的不同，变更场景可以区分为两种：
1146
1147 |**序号**|**场景**|**说明**
1148 |1|基础设施变更|变更的主要组成部分，也是变更的主要意义所在，指的是对准生产和生产环境的基础设施（主机、网络、应用系统等）进行诸如安装、升级、维护、撤销等需要改变其固有属性的操作，一般来说此类操作时需要终止服务。
1149 |2|配置更新变更|此类变更是有ITSM系统配置管理流程所引发，主要指的是对系统中CMDB的CI信息变更。
1150
1151
1152 ====== **​​​​​​​3.6.2 各节点检查事项说明** ======
1153
1154 检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
1155
1156 这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
1157
1158
1159 |**检查点**|**负责人**|**检查事项**
1160 |评估构建|变更受理者|(((
1161 * 请求人和地点信息
1162 * 创建时间
1163 * 变更来源和变更类型
1164 * 变更所影响的部门和应用
1165 * 变更分类、优先级
1166 * 回退计划和测试计划
1167 * 变更标题和描述
1168 * 关联配置项和其他工单
1169 * 附件
1170 )))
1171 |审批|(((
1172 变更经理
1173
1174 变更审批者
1175 )))|(((
1176 * 请求人和地点信息
1177 * 创建时间
1178 * 变更来源和变更类型
1179 * 变更所影响的部门和应用
1180 * 变更分类、优先级
1181 * 变更计划开始和完成时间
1182 * 变更标题和描述
1183 * 关联配置项和其他工单
1184 * 附件
1185 )))
1186 |实施验证|(((
1187 变更受理者
1188
1189 变更实施者
1190 )))|(((
1191 * 变更来源和变更类型
1192 * 变更分类、优先级
1193 * 回退计划和测试计划
1194 * 变更标题和描述
1195 * 关联配置项和其他工单
1196 * 变更计划开始和完成时间
1197 * 工作日志
1198 * 附件
1199 )))
1200 |回顾关闭|变更经理|(((
1201 * 变更来源和变更类型
1202 * 变更分类、优先级
1203 * 变更标题和描述
1204 * 关联配置项和其他工单
1205 * 变更计划开始和完成时间
1206 * 变更实际开始和完成时间
1207 * 工作日志
1208 * 关闭代码
1209 * 附件
1210 )))
1211 |跟踪回顾|N/A|(((
1212 * 变更状态
1213 * 变更经理、受理人和流转系统日志
1214 * 变更分类、优先级
1215 * 变更来源和变更类型
1216 * 是否超时标志
1217 * 实际开始和完成时间
1218 * 工作日志
1219 * 关闭和等待代码
1220 * 备注项和附件
1221 )))
1222
1223
1224 ====== **​​​​​​​3.6.3 流程负责人制度** ======
1225
1226 变更管理各角色和职责：
1227
1228 |**角色**|**职责描述**
1229 |流程负责人|(((
1230 * 对整个流程的效率和结果负责
1231 * 发布衡量标准和目标，以提高流程的有效性和效率
1232 * 鉴别和管理关键的成功因素
1233 * 控制并领导流程改进活动
1234 * 批准或拒绝背离流程的事例
1235 * 定义变更管理团队的角色、职责和义务
1236 * 强化贯彻执行变更管理流程
1237 * 向同级的其他流程负责人以及管理层汇报流程的状态
1238 * 解决跨部门的问题
1239 * 审核、抽查变更管理流程的执行情况
1240 * 对变更管理流程中投入的成本和投资负责
1241 * 在组织内沟通新发布的和修改过的政策
1242 * 作为变更管理流程的代表，与其他外部部门沟通
1243 )))
1244 |变更请求者|(((
1245 * 接收和记录变更请求、分配变更请求的优先级，或者与变更的发起人员协作，记录变更请求。拒绝任何不切实际的变更请求
1246 * 如果采用工具，更新变更请求单
1247 * 确保RFC具有充分、准确的信息
1248 * 确保及时地沟通变更处理的情况
1249 * 初步评价变更的风险/影响，给变更请求设定适当的影响度
1250 * 协助变更经理或者变更受理者解决变更请求信息不完整、不一致之处
1251 * 回应变更审批人员提出的有关问题
1252 * 确保关于所提交的变更请求的所有疑问都得到适当的解答
1253 )))
1254 |变更受理者|(((
1255 * 变更受理者主要在技术方案上负责，把关变更计划中技术方面的问题
1256 * 负责构建变更并制定实施时间计划
1257 * 在验证测试环境中负责测试变更
1258 * 准备回退计划，以便在变更实施不成功时进行回退
1259 * 创建实施计划
1260 * 必要时更新操作手册或运行操作规程
1261 * 实施完毕进行回顾，判断是否由于变更的实施从而产生外部影响或新的需求
1262 * 检查实施完毕的变更，确保达到了预期的目标
1263 * 将不成功的变更通知变更经理，如果变更过程发生了未经计划的停机，必须进行解释
1264 * 协调变更中的有关事项
1265 * 关联所有与变更相关的配置项
1266 )))
1267 |变更经理|(((
1268 * 负责技术人员的协调沟通，在涉及多个部门的变更中，变更经理负责组织技术方案讨论会议，审核最终变更计划，并将初审通过的变更计划发给变更审批者进行进一步的审批
1269 * 分析已关闭的变更请求，判断其趋势，或找出明显的问题，并找到相关的科室、部门进行纠正
1270 * 定期产生变更管理的报表
1271 * 判断变更管理的会议应由哪些人员参与，根据审批人员的专业领域，确定各种类型的RFC应当由哪些人员评估
1272 * 根据变更日程，协助变更受理者联络、协调相关人员/部门，合作参与变更的构建、测试和实施
1273 * 负责确保变更管理流程的日常顺利运行
1274 * 判断例外及背离流程的情况，并进行管理
1275 * 监控变更管理流程的有效性和效率，提出改进流程的建议
1276 * 必要时与用户协商关于变更实施时需要停止服务的时间
1277 * 综合考虑变更的日程，解决日程之间的冲突
1278 * 确保以及时、适当的方式对变更进行沟通
1279 * 更新变更请求的状态并关闭变更请求
1280 * 更新RFC的状态并关闭RFC
1281 )))
1282 |变更审批者|(((
1283 * 确保所有标准审批流程的变更请求都经过评估
1284 * 对变更进行评估（从业务、技术、日程、实施角度全面评估），以确定变更实施与否所造成的影响
1285 * 任何问题或利害关系，都应当与变更经理、变更请求者以及事先指定的其他审批者进行及时沟通
1286 * 当审批者自身无法参与评估和审批时，应向变更经理推荐一位代替自己的人选
1287 * 考虑实施变更的日期，如：是否应当在周末、季度末执行变更等
1288 )))
1289 |CAB/EC|(((
1290 * 针对具体变更请求，评估潜在影响和风险，并分派相应资源
1291 * 指导变更经理对变更做出审批、决策
1292 * 参加CAB会议和紧急CAB会议
1293 * 对流程改进提出意见和建议
1294 )))
1295 |变更实施者|(((
1296 * 确保按时实施变更
1297 * 按照指导方针执行回退计划
1298 * 尽量解决在实施过程中出现的问题
1299 * 如果变更实施失败，执行回退方案
1300 * 必要时更新操作手册或运行操作规程
1301 * 如果变更实施失败，需要创建相应的变更事件故障单
1302 * 更新变更记录单状态
1303 * 通知操作人员/服务台关于变更处理的状态
1304 * 按要求执行回退方案，将生产环境（硬件/软件）恢复到变更前状态
1305 )))
1306
1307
1308 **此处需要强调的是CAB/EC的人员构成：**
1309
1310 CAB（变更顾问委员会）是由信息中心的管理人员组成的虚拟小组，主要由各相关部门的领导、各个服务负责部门的资深人员或者技术骨干组成，有时也会包括发起变更请求的业务部门的代表、第三方厂商集成商等参与。CAB应当由该专业有较高技能的人员组成，同时，这些成员对于业务需求、业务逻辑、IT系统技术、应用开发、测试、支持等方面也较为熟悉。
1311
1312 EC（紧急变更委员会）通常可以属于CAB的一个子集
1313
1314 CAB/EC由于成员不定，所以应该有一个最小集，我们建议的CAB/EC的最小集应包括：
1315
1316 1. 主管信息领导
1317 1. 信息部门负责人
1318 1. 变更经理
1319 1. 变更受理人
1320
1321
1322 工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
1323
1324
1325 |**状态**|**状态(英文)**|**描述**|**责任人**
1326 |新建|New|变更申请表正在填写之中|请求人
1327 |已分派|Assigned|变更请求已分派给变更受理者进行初始的计划、准备工作|变更受理者
1328 |计划中|Planning|变更受理者正在准备变更的计划|变更受理者
1329 |审批中|Approving|变更经理正在审阅变更的计划|变更经理
1330 |已审批|Approved|变更审批者已经完成了变更的审批|变更实施者
1331 |实施中|Working In Progress|变更正在处理中|变更实施者
1332 |已实施|Implemented|变更实施结束，并且返回结果|(((
1333 变更受理者
1334
1335 变更经理
1336 )))
1337 |已关闭|Closed|变更完成|变更经理
1338
1339
1340 1.
1341 11.
1342 111. **考核指标**
1343
1344 流程考核指标参考：
1345
1346 |**种类**|**指标**|**计算方法**
1347 |(% rowspan="6" %)流程
1348 有效性|每一变更类型的变更数量|数量：每一变更类型的【登记时间】在统计时间区间内的变更数量
1349 |每一变更分类的变更数量|数量：每一变更分类的【登记时间】在统计时间区间内的变更数量
1350 |每一风险等级的变更数量|数量：每一风险等级的【登记时间】在统计时间区间内的变更数量
1351 |变更实施失败的数量和比率|数量：【变更结束代码】=“失败”and 【关闭时间】在统计时间区间内的变更数量
1352 |变更实施成功的数量和比率|数量：【变更结束代码】=“成功”and 【关闭时间】在统计时间区间内的变更数量
1353 |被取消的变更数量和比率|数量：【变更结束代码】=“已取消”and 【关闭时间】在统计时间区间内的变更数量
1354 |执行
1355 效率|业务中断时长|业务中断时长：【变更状态】=“已完成”and 【实际完成时间】在统计时间区间内的【中断时长】，按【中断关键业务名称】分别对应到业务系统的子类，进行分类统计
1356
1357
1358 ====== **3.6.4 回顾机制** ======
1359
1360 一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
1361
1362 流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
1363
1364 流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
1365
1366 流程回顾例会应包括以下内容：
1367
1368 |**回顾任务**|**描述**|**负责人**
1369 |流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
1370 变更经理
1371
1372 流程负责人
1373 )))
1374 |流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
1375 变更经理
1376
1377 流程负责人
1378 )))
1379 |数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，失败变更等|(((
1380 变更经理
1381
1382 流程负责人
1383 )))
1384 |案例分析|典型案例分析|(((
1385 变更经理
1386
1387 变更受理者
1388
1389 流程负责人
1390 )))
1391 |KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
1392 变更经理
1393
1394 流程负责人
1395 )))
1396 |流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
1397 变更经理
1398
1399 流程负责人
1400 )))
1401
1402
1403 ===== **​​​​​​​3.7 发布管理** =====
1404
1405 ====== **3.7.1 应用场景** ======
1406
1407 发布管理流程通过规范操作流程，平稳地对生产系统进行变更，从而化解和控制变更可能产生的风险，满足业务发展的需要。
1408
1409 发布管理的应用范围与变更相同，但发布管理的规模和关注点与变更不同。
1410
1411 [[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml16320\wps7.jpg]][[image:图片1.png]]
1412
1413 一个发布要求实现一个整体目标，发布会关联出一系列变更来进行具体实施，并对这一系列变更进行总体的协调和控制以保证发布的质量
1414
1415
1416
1417 ====== **​​​​​​​3.7.2 各节点检查事项说明** ======
1418
1419 检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
1420
1421 这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
1422
1423
1424 |**检查点**|**负责人**|**检查事项**
1425 |评估|发布受理者|(((
1426 * 请求人和地点信息
1427 * 创建时间
1428 * 发布来源和发布类型
1429 * 发布所影响的部门和应用
1430 * 发布分类、优先级
1431 * 发布标题和描述
1432 * 备注和附件
1433 )))
1434 |审批|发布经理|(((
1435 * 请求人和地点信息
1436 * 创建时间
1437 * 发布来源和发布类型
1438 * 发布所影响的部门和应用
1439 * 发布分类、优先级
1440 * 发布标题和描述
1441 * 备注和附件
1442 )))
1443 |实施|发布实施者|(((
1444 * 请求人和地点信息
1445 * 创建时间
1446 * 发布来源和发布类型
1447 * 发布所影响的部门和应用
1448 * 发布分类、优先级
1449 * 发布标题和描述
1450 * 计划开始和完成时间
1451 * 工作日志
1452 * 备注和附件
1453 )))
1454 |验证|发布受理者|(((
1455 * 发布来源和发布类型
1456 * 发布分类、优先级
1457 * 发布标题和描述
1458 * 关联变更情况
1459 * 发布计划开始和完成时间
1460 * 发布实际开始和完成时间
1461 * 工作日志
1462 * 关闭代码
1463 * 备注和附件
1464 )))
1465 |跟踪回顾|N/A|(((
1466 * 发布状态
1467 * 发布经理、受理人和流转系统日志
1468 * 发布分类、优先级
1469 * 发布来源和发布类型
1470 * 是否超时标志
1471 * 关联变更情况
1472 * 实际开始和完成时间
1473 * 工作日志
1474 * 关闭和等待代码
1475 * 备注项和附件
1476 )))
1477
1478
1479 ====== **​​​​​​​3.7.3 流程负责人制度** ======
1480
1481 发布管理各角色和职责与变更相同。
1482
1483 工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
1484
1485
1486 |**状态**|**状态(英文)**|**描述**|**责任人**
1487 |新建|New|发布申请表正在填写之中|请求人
1488 |已分派|Assigned|发布请求已分派给发布受理者进行初始的计划、准备工作|发布受理者
1489 |计划中|Planning|发布受理者正在准备变更的计划|发布受理者
1490 |审批中|Approving|发布经理正在审阅发布的计划|发布经理
1491 |实施中|Working In Progress|发布正在处理中|发布实施者
1492 |已实施|Implemented|发布实施结束，并且返回结果|发布受理者
1493 |已关闭|Closed|发布完成|发布经理
1494
1495
1496 ====== **​​​​​​​3.7.4 考核指标** ======
1497
1498 流程考核指标参考，发布管理通过分解的变更具体实现，所以发布管理的衡量指标与变更管理一致：
1499
1500 |**种类**|**指标**|**计算方法**
1501 |(% rowspan="6" %)流程
1502 有效性|每一发布类型的发布数量|数量：每一发布类型的【登记时间】在统计时间区间内的发布数量
1503 |每一发布分类的发布数量|数量：每一发布分类的【登记时间】在统计时间区间内的发布数量
1504 |每一风险等级的发布数量|数量：每一风险等级的【登记时间】在统计时间区间内的发布数量
1505 |发布实施失败的数量和比率|数量：【发布结束代码】=“失败”and 【关闭时间】在统计时间区间内的发布数量
1506 |发布实施成功的数量和比率|数量：【发布结束代码】=“成功”and 【关闭时间】在统计时间区间内的发布数量
1507 |被取消的发布数量和比率|数量：【发布结束代码】=“已取消”and 【关闭时间】在统计时间区间内的发布数量
1508 |执行
1509 效率|业务中断时长|业务中断时长：【发布状态】=“已完成”and 【实际完成时间】在统计时间区间内的【中断时长】，按【中断关键业务名称】分别对应到业务系统的子类，进行分类统计
1510
1511
1512 ====== **3.7.5 回顾机制** ======
1513
1514 一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
1515
1516 流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
1517
1518 流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
1519
1520 流程回顾例会应包括以下内容：
1521
1522 |**回顾任务**|**描述**|**负责人**
1523 |流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
1524 发布经理
1525
1526 流程负责人
1527 )))
1528 |流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
1529 发布经理
1530
1531 流程负责人
1532 )))
1533 |数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，失败发布等|(((
1534 发布经理
1535
1536 流程负责人
1537 )))
1538 |案例分析|典型案例分析|(((
1539 发布经理
1540
1541 发布受理者
1542
1543 流程负责人
1544 )))
1545 |KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
1546 发布经理
1547
1548 流程负责人
1549 )))
1550 |流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
1551 发布经理
1552
1553 流程负责人
1554 )))
1555
1556
1557 变更和发布的回顾例会建议应该在一起进行。
1558
1559
1560
1561 ===== **3.8 配置和资产管理** =====
1562
1563 ====== **3.8.1 应用场景** ======
1564
1565 配置管理是一个持续性的过程，包括计划、记录和管理数据，它管理数据中心运行环境有关的组件。该流程为IT组织提供提供所管理的IT组件的情况，包括组件之间互相的关系和状况。
1566
1567 配置管理的目标是记录和维护IT架构中相关组件的准确信息（避免防止人为的误操作造成服务的不可用或服务质量的下降） ,包括组件之间的关系，为其他服务支持和服务供应流程提供信息。
1568
1569 IT资产管理是一个管理的过程，对于资产的生命周期进行记录与控制。该流程为IT组织提供所管理的IT物理资产在生命周期所产生的财务管理目标的基础数据。
1570
1571 IT资产管理的目标是记录和维护IT信息管理与IT相关的物理资产的生命周期与财务信息。IT资产管理相对于IT服务管理独立，只共用配置管理数据库。
1572
1573 IT资产管理和配置管理都是基于同一个配置管理数据库的，但资产管理与配置管理是用两种不同的视角去来衡量同一个事物。
1574
1575
1576 [[image:图片2.png]]
1577
1578
1579 各种不同类别的CI从“入库接收~-~-上线工作~-~-报废处置”的整个生命周期内，资产管理和配置管理各自涵盖的范围。
1580
1581 |**CI类别**|**资产管理**|**配置管理**
1582 |桌面终端|全生命周期|无
1583 |系统硬件|全生命周期|上线工作期间
1584 |系统软件|全生命周期|上线工作期间
1585 |业务平台|全生命周期|上线工作期间
1586 |逻辑实体|无|上线工作期间
1587 |配件部件|全生命周期|上线工作期间
1588
1589
1590 ====== **3.8.2 各节点检查事项说明** ======
1591
1592 检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
1593
1594 这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
1595
1596
1597 |**检查点**|**负责人**|**检查事项**
1598 |资产接收|资产管理员|(((
1599 * 采购单号
1600 * 接收类型和结果
1601 * 供货商、供货批次、合同号
1602 * 检验人和检验信息
1603 )))
1604 |资产发放|资产管理员|(((
1605 * 使用人和使用部门
1606 * 发放原因
1607 * 发放地点
1608 * 领用人（经办人）
1609 * 发放记录和日期
1610 * 备注
1611 )))
1612 |资产处置|资产管理员|(((
1613 * 申请人和经办人
1614 * 处置原因
1615 * 处置方案
1616 * 处置时间
1617 * 审批状态
1618 * 备注
1619 )))
1620 |配置审核|配置管理员|(((
1621 * 配置项编号
1622 * 配置项所有者
1623 * 配置项状态（与实际情况做对比）
1624 * 配置项通用属性和专有属性（与实际情况做对比）
1625 * 配置项地点（与实际情况做对比）
1626 * 最近审核时间
1627 )))
1628 |配置更新|配置管理员|(((
1629 * 配置项所有者
1630 * 配置项状态
1631 * 配置项通用属性和专有属性
1632 * 配置项地点
1633 * 最近审核时间
1634 * 最近更新时间
1635 )))
1636
1637
1638 ====== **​​​​​​​3.8.3 流程负责人制度** ======
1639
1640 各角色和职责：
1641
1642 |**角色**|**职责描述**
1643 |IT资产经理|对IT资产流程进行管理，对于IT资产管理员进行直接任命。
1644 |IT资产管理员|负责IT资产管理数据的一致性和准确性，确保为其他操作管理提供的数据是准确的。
1645 |IT采购专员|负责跟踪合同与采购单，与第三方供应商进行协调。
1646 |IT资产审批人|负责对资产采购申请进行审批
1647 |配置经理|协调配置管理的日常操作活动，负责整个流程执行的质量。也是与其他流程经理的交流界面。
1648 |配置管理员|负责配置管理数据的一致性和准确性，确保为其他操作管理提供的数据是准确的；执行审核计划。
1649 |综合/系统管理员|负责第三方厂商、文档等信息的维护。
1650 |流程负责人|负责整个运维流程的制订和监督流程质量
1651
1652
1653 ====== **3.8.4 考核指标** ======
1654
1655 流程考核指标参考：
1656
1657 |**种类**|**指标**|**计算方法**
1658 |(% rowspan="7" %)资产管理|采购成本|企业采购硬件所花费的总金额+企业采购软件所花费的总金额
1659 |部署和维护成本|资产维护中新购配件的金额+资产维护中使用付费服务的金额
1660 |报废成本|报废所花费的成本-所获得的金额-通过资产报废使税收节约增加的数额
1661 |总成本|采购成本+部署和维护成本+报废成本
1662 |硬件利用率|(((
1663 数量1.企业拥有的硬件的总数量
1664
1665 数量2.状态为在使用的硬件的数量
1666
1667 比率.数量2/数量1*100%
1668 )))
1669 |软件利用率|(((
1670 数量1. 总共购买的软件许可证的总数
1671
1672 数量2. 目前已经使用的软件许可证的数量
1673
1674 比率.数量2/数量1*100%
1675 )))
1676 |使用不当设备损坏率|(((
1677 数量1.使用不当导致设备发生故障的数量
1678
1679 数量2.此类设备总数量
1680
1681 比率.数量1/数量2*100%
1682 )))
1683 |(% rowspan="7" %)配置管理|周期性审核中与物理环境一致的CI数量（已审核数量）及比例|(((
1684 已审核数量：【删除状态】=‘正常‘and【审核状态】=‘已审核‘的CI数量
1685
1686 比例：已审核数量/【删除状态】=‘正常‘的CI数量
1687
1688 按照CI层次进行分组统计
1689 )))
1690 |周期性审核中与物理环境不一致的CI数量（不匹配数量）及比例|(((
1691 不匹配数量：【删除状态】=‘正常‘and【审核状态】=‘不匹配‘的CI数量
1692
1693 比例：不匹配数量/【删除状态】=‘正常‘的CI数量
1694
1695 按照CI层次进行分组统计
1696 )))
1697 |周期性审核中与发现物理环境中不存在的CI数量（丢失数量）及比例|(((
1698 丢失数量：【删除状态】=‘正常‘and【审核状态】=‘丢失‘的CI数量
1699
1700 比例：丢失数量/【删除状态】=‘正常‘的CI数量
1701
1702 按照CI层次进行分组统计
1703 )))
1704 |某时间周期内新增加的CI数量（新增数量）|(((
1705 新增数量：【删除状态】=‘正常‘and【 创建时间】在统计时间区间内的CI数量;
1706
1707 按照CI层次进行分组统计
1708 )))
1709 |某时间周期内删除的CI数量（删除数量）|(((
1710 删除数量：【删除状态】=‘已删除‘and【删除时间】在统计时间区间内的CI数量;
1711
1712 按照CI层次进行分组统计
1713 )))
1714 |某时间周期内CI服务可用时长比率|
1715 |某时间周期内CI出现故障数量|
1716
1717
1718 ====== **3.8.5 回顾机制** ======
1719
1720 一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
1721
1722 流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
1723
1724 流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
1725
1726 流程回顾例会应包括以下内容：
1727
1728 |**回顾任务**|**描述**|**负责人**
1729 |流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
1730 变更经理
1731
1732 流程负责人
1733 )))
1734 |流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
1735 变更经理
1736
1737 流程负责人
1738 )))
1739 |数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，失败变更等|(((
1740 变更经理
1741
1742 流程负责人
1743 )))
1744 |案例分析|典型案例分析|(((
1745 变更经理
1746
1747 变更受理者
1748
1749 流程负责人
1750 )))
1751 |KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
1752 变更经理
1753
1754 流程负责人
1755 )))
1756 |流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
1757 变更经理
1758
1759 流程负责人
1760 )))
1761
1762
1763 配置和资产的管理回顾例会不必要频率过高，推荐季度例会，配置和资产例会可以选择分别召开。
1764
1765
1766
1767
1768 ===== **3.9 需求管理** =====
1769
1770 ====== **3.9.1 应用场景** ======
1771
1772 需求管理主要功能提供一个用户提出对应用系统修改意见的通道，提升IT服务的专业性，并降低沟通成本。
1773
1774 需求管理的应用较为专业，只针对于业务部门汇报生产环境或准生产环境下的应用系统BUG或功能修改意见，提交于应用开发团队。
1775
1776
1777 ====== **3.9.2 各节点检查事项说明** ======
1778
1779 检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
1780
1781 这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
1782
1783
1784 |**检查点**|**负责人**|**检查事项**
1785 |业务审批|业务审批人|(((
1786 * 请求人和地点信息
1787 * 创建时间
1788 * 分类、紧急度和紧急度说明
1789 * 标题和描述
1790 * 备注和附件
1791 )))
1792 |IT评估审批|(((
1793 需求受理人
1794
1795 需求经理
1796 )))|(((
1797 * 请求人和地点信息
1798 * 创建时间
1799 * 分类、紧急度和紧急度说明
1800 * 标题和描述
1801 * 备注和附件
1802 )))
1803 |处理需求|(((
1804 需求受理人
1805
1806 需求实施人
1807 )))|(((
1808 * 请求人和地点信息
1809 * 创建时间
1810 * 分类、紧急度和紧急度说明
1811 * 标题和描述
1812 * 工作日志
1813 * 备注和附件
1814 )))
1815 |验证关闭|需求受理人|(((
1816 * 请求人和地点信息
1817 * 创建时间
1818 * 分类、紧急度和紧急度说明
1819 * 标题和描述
1820 * 完成信息
1821 * 未通过/等待/关闭代码
1822 * 工作日志
1823 * 备注和附件
1824 )))
1825 |跟踪回顾|N/A|(((
1826 * 需求状态
1827 * 审批人、受理人和流转日志
1828 * 分类、紧急度和紧急度说明
1829 * 审批代码和完成信息
1830 * 是否超时标志
1831 * 实际开始和完成时间
1832 * 工作日志
1833 * 备注和附件
1834 )))
1835
1836
1837 ====== **​​​​​​​3.9.3 流程负责人制度** ======
1838
1839 需求管理各角色和职责：
1840
1841 |**角色**|**职责描述**
1842 |用户|记录需求信息，负责与用户沟通
1843 |需求审批者(业务部门）|从业务的角度，负责决定是否提交该需求
1844 |需求审批者(IT部门)|对需求进行最终审批
1845 |需求受理者|负责需求的分析和处理
1846 |需求实施者|负责需求最终的实施开发工作
1847 |需求经理|初审需求，协调需求处理过程中的相关工作
1848 |流程负责人|推动、推广需求管理流程，对流程的整体效果和效率负责。
1849
1850
1851 工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
1852
1853
1854 |**状态**|**描述**|**责任人**
1855 |新建|客户提交一个新的需求申请|需求提交人
1856 |业务审批|提交业务部门领导进行审批|业务审批人
1857 |已分派|需求申请单根据需求分类被分派到相应的需求受理者|需求受理人
1858 |分析中|由需求受理人进行需求分析|需求受理人
1859 |待审批|需求申请单等待需求经理和需求审批人审批|需求经理
1860 |处理中|对需求进行开发实施|需求受理人
1861 |暂缓|需求暂缓处理|需求受理人
1862 |测试中|需求进行用户测试|需求受理人
1863 |上线中|需求等待变更和发布进行上线|需求受理人
1864 |已关闭|需求申请单关闭|需求经理
1865
1866
1867 ====== **3.9.4 考核指标** ======
1868
1869 流程考核指标参考：
1870
1871 |**种类**|**指标**|**计算方法**
1872 |(% rowspan="6" %)流程
1873 有效性|需求总数|(((
1874 数量：在需求单中根据以下条件过滤
1875
1876 1. 【需求结束代码】不等于‘取消’
1877 1. 【需求发生时间】在统计周期内
1878 )))
1879 |需求关闭的数量|数量 ：在需求总数中过滤【需求状态】＝‘已关闭’
1880 |需求成功关闭的数量/比率|(((
1881 数量：在需求总数中过滤【需求结束代码】＝处理成功
1882
1883 比率：数量 / 需求总数  × 100 %
1884 )))
1885 |规定时间内解决的需求数量/百分比|(((
1886 数量：在需求总数中过滤【处理是否超时】＝“未超时”以及【需求结束代码】＝处理成功
1887
1888 比率：数量/需求总数 × 100 %
1889 )))
1890 |超时未解决的需求数量|数量：在需求总数中过滤【处理已超时】＝“超时”以及【需求状态】！=“处理成功”或“关闭”
1891 |规定时间响应的需求数量/百分比|(((
1892 数量：在需求总数中过滤（【实际开始时间】－【登记时间】）< 对应的响应时限
1893
1894 比率：数量/需求总数 × 100 %
1895 )))
1896 |(% rowspan="3" %)执行
1897 效率|平均解决时间|(((
1898 完成的需求：在需求总数中过滤所有【需求状态】＝“处理成功”或“关闭”的需求
1899
1900 平均解决时间：累加完成需求的（【实际完成时间】－【登记时间】）/ 完成的需求数量
1901 )))
1902 |解决率|(((
1903 数量：在需求总数中过滤所有【需求解决人角色】＝“技能组名称”
1904
1905 比率：数量 / 需求总数 × 100 %
1906 )))
1907 |需求的一次解决率|(((
1908 数量1：在需求总数中过滤【需求结束代码】＝“处理成功”
1909
1910 数量2：在需求总数中过滤【需求结束代码】＝“不成功”
1911
1912 比率：（数量1－数量2 ） / 数量1 × 100 %
1913 )))
1914
1915
1916 ====== **3.9.5 回顾机制** ======
1917
1918 一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
1919
1920 流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
1921
1922 流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
1923
1924 流程回顾例会应包括以下内容：
1925
1926 |**回顾任务**|**描述**|**负责人**
1927 |流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
1928 需求经理
1929
1930 流程负责人
1931 )))
1932 |流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
1933 需求经理
1934
1935 流程负责人
1936 )))
1937 |数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，某些重复性较高的服务请求是否可以省去审批过程|(((
1938 需求经理
1939
1940 流程负责人
1941 )))
1942 |案例分析|典型案例分析|(((
1943 需求经理
1944
1945 需求受理人
1946
1947 流程负责人
1948 )))
1949 |KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
1950 需求经理
1951
1952 流程负责人
1953 )))
1954 |流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
1955 需求经理
1956
1957 流程负责人
1958 )))
1959
1960
1961 === **4 知识管理规范** ===
1962
1963
1964 ===== **4.1 知识库的管理** =====
1965
1966 1. 知识库的内容收集、更新、维护、清理、权限控制、审核与发布都应该建立完善的管理制度并责任到人。
1967 1. 服务台人员对已启用的事件管理平台和问题管理平台中出现的问题进行归类整理，对出现的各个事件按部门、类型、处理难易度、解决时间等进行化类区分，并存入知识库。
1968 1. 信息中心各部门应设有专门的知识库管理员和文档库管理员，负责知识和文档的统一提交、审核、整理、维护。
1969
1970
1971
1972 ===== **4.2 维护管理任务说明** =====
1973
1974 1. 知识审批流程
1975 1. 知识和文档分类与入库
1976 1. 新建知识库和文档库
1977 1. 知识库系统健康检查
1978 1. 知识访问相关统计
1979
1980
1981 ====== **4.2.1 知识管理系统健康检查** ======
1982
1983 * 工作内容： 知识管理系统健康检查
1984 * 责任人：系统管理员
1985 * 维护周期：每周
1986 * 执行时间：周五
1987 * 执行步骤：
1988
1989 1. 登录门户，进入知识管理模块，对任意知识库进行查询、浏览、检查知识库是否工作正常
1990 1. 检查知识模块的各项主要功能服务是否正常
1991
1992
1993
1994
1995 ====== **4.2.2 知识草稿审批** ======
1996
1997 * 工作内容： 知识管理系统健康检查
1998 * 责任人：知识管理员
1999 * 维护周期：每天
2000 * 执行时间：每天12:00
2001 * 执行对象：各知识库
2002 * 执行步骤：
2003
2004 1. 进入知识管理模块，查看上一日用户提交的知识草稿，发起知识审批流程
2005 1. 将审批通过的知识草稿进行分类、导入相应知识库成为正式知识
2006 1. 将未通过的知识草稿进行相应处理
2007
2008
2009 ====== **​​​​​​​4.2.3 知识提交、访问相关统计** ======
2010
2011 * 工作内容： 知识管理系统健康检查
2012 * 责任人：知识管理员
2013 * 维护周期：每月
2014 * 执行时间：每月5日17:00前
2015 * 执行对象：报表系统
2016 * 执行步骤：登录进入报表模块，访问知识提交、访问统计报表，生成相应的报表文件，并将结果反馈给知识经理。
2017
2018
2019 ====== **​​​​​​​4.2.4 知识重新分类** ======
2020
2021 * 工作内容： 知识重新分类
2022 * 责任人：知识管理员、系统管理员
2023 * 维护周期：每周
2024 * 执行时间：每周五  12:00前
2025 * 执行对象：知识库、文档库
2026 * 执行步骤：
2027
2028 1. 检查用户对最近新增知识的评价，汇总是否有知识重新分类的需求
2029 1. 对知识进行重新分类
2030
2031
2032
2033 === **5 日常的周期性维护操作** ===
2034
2035
2036 本章总结了系统管理操作员（应用系统管理员，数据库管理员，主机系统管理员、网络管理员）日常维护工作的流程和具体需要完成的工作纪录表。同时所有的系统管理操作员在做日常维护工作时，应按照系统要求的格式填写好相应的每日、每周、月度、年度维护工作记录表。
2037
2038
2039 ===== **​​​​​​​5.1 日常的周期性维护工作** =====
2040
2041 1 是否是周一
2042
2043 如果当天是周一，则需要先执行系统每周维护工作
2044
2045 2 是否是每月第一个工作日
2046
2047 如果当天是当月第一个工作日，则需要先执行系统每月维护工作
2048
2049 3 是否是财务年结之后第一个工作日
2050
2051 如果当天是财务年结之后第一个工作日，则需要先执行系统每年维护工作
2052
2053 4 填写维护工作记录表单（ITSM系统）
2054
2055
2056 ===== **5.2 系统每日维护检查工作列表** =====
2057
2058 ====== **5.2.1 应用系统管理员负责部分** ======
2059
2060 |应用系统管理员负责部分| | | | |
2061 |序号|工作内容|频率|时间|持续时间|备注
2062 |1|检查连接运行状态|1/日|上午|1－5分钟|应用连接和数据库连接
2063 |2|检查日志|1/日|上午|5－10分钟|主要检查报错信息
2064 |3|检查WEB服务运行状态|1/日|上午|1－5分钟|
2065 |4|检查报表服务运行状态|1/日|上午|1－5分钟|
2066 |5|检查进程运行状态|1/日|上午|1－5分钟|系统中相关进程是否运转正常
2067 |6|检查备份是否正常|1/日|上午|1－5分钟|
2068 |总计| | |上午|10－35分钟|
2069
2070
2071
2072
2073 ====== **5.2.2 数据库管理员负责部分** ======
2074
2075
2076 |序号|工作内容|频率|时间|持续时间|备注
2077 |1|检查备份日志|1/日|上午|1－5分钟|检查前一天备份的日志
2078 |2|查看数据库告警日志|1/日|上午|5－10分钟|查找是否有告警，查看日志中是否有ORA-XXXXX的告警。
2079 |3|检查SGA、PGA、锁|1/日|上午|5-10分钟|主要检查是否有超负荷或死锁
2080 |4|检查正在使用的模块是否有20%以上可用空闲表空间|1/日|上午|1－5分钟|在系统使用过程中，对表空间可用率不足20%应尽快进行处理
2081 |5|检查是否有表或索引已接近其可以使用的最多扩展的数量。|1/日|上午|1－5分钟|对于表或索引的可用扩展数量与最大可用扩展数量差小于5时，应该尽快进行处理
2082 |总计| | |上午|15－40分钟|
2083
2084
2085 ====== **5.2.3 主机系统管理员负责部分** ======
2086
2087
2088 | 序号|工作内容|频率|时间|持续时间|备注
2089 |1|检查文件系统利用率日志|1/日|上午|1－5分钟|使用df –k进行检查是否有文件系统利用率高于85%并且可用空间小于500M
2090 |(% rowspan="3" %)2|(% rowspan="3" %)查看系统硬件软件告警日志|(% rowspan="3" %)1/日|(% rowspan="3" %)上午|(% rowspan="3" %)1－5分钟|IBM主机使用errpt进行检查是否有硬件错误和告警，
2091 |SUN主机查看
2092 |/var/adm/messages
2093 |3|检查是否有僵死或运行时间过长的进程|1/日|上午|1－10分钟|使用ps –ef  进行检查（运行时间超过12小时的绝大部分是有问题的进程）
2094 |(% rowspan="2" %)4|(% rowspan="2" %)检查系统运行日志（系统CPU利用率，内存利用率，IO利用率，页面交换量的监控）|(% rowspan="2" %)1/日|(% rowspan="2" %)上午|(% rowspan="2" %)5－10分钟|IBM主机查看NMON的输出文件，并使用分析工具制作报表。
2095 |Sun主机查看top的输出，并使用分析工具制作报表。
2096 |5|检查系统高可用性（HA）的使用状态|1/日|上午|5-10分钟|检查集群软件日志文件的使用
2097 |总计| | |每日上午|13－40分钟|
2098
2099
2100 ====== **5.2.4 网络管理员负责部分** ======
2101
2102
2103 |序号|工作内容|频率|时间|持续时间|备注
2104 |1|检查网络连接情况|1/日|上午|1－5分钟|
2105 |2|检查网络硬件（路由器，交换机，防火墙）的运行状态|1/日|上午|1－5分钟|
2106 |3|检查网络系统安全日志，搜索是否有攻击行为|1/日|上午|1－5分钟|
2107 |总计| | |每天上午|3-15分钟|
2108
2109
2110
2111 ===== **5.3 系统每周维护检查工作列表** =====
2112
2113 ====== **5.3.1 应用系统管理员负责部分** ======
2114
2115
2116 |序号|工作内容|频率|时间|持续时间|备注
2117 |1|检查系统定期请求运行结果|1/周 |周一上午|1－5分钟|如备份策略或自动操作
2118 |2|汇总本周运行情况总结|1/周 |周一上午|10－30分钟|
2119 |总计| | |周一上午|15－35分钟|
2120
2121 |序号|工作内容|频率|时间|持续时间|备注
2122 |1|检查系统无效对象并编译|1/周 |周一上午|1－10分钟|对系统无效对象的处理
2123 |2|检查是否有表或索引设置增长的百分比或下一次的扩展的尺寸过大|1/周 |周一上午|1－5分钟|查找数据库表或索引增量TOP 10，根据表或索引实际的增长速率调整其增量大小
2124 |3|检查是否某表空间内对象的下一次扩展的总和超过目前表空间的最大可用尺寸|1/周 |周一上午|1－5分钟|查找是否表空间内对象的下一次扩展的总和超过目前表空间的最大可用尺寸
2125 |4|检查是否有数据库用户使用非TEMPORARY类型表空间作为临时表空间。|1/周 |周一上午|1－5分钟|运行SQL查询是否有用户使用非TEMPORARY类型表空间作为临时表空间，
2126 |5|检查是否有表或索引碎片过多需要优化|1/周 |周一上午|10－30分钟|进行碎块的检测和整理
2127 |6|检查空闲表空间是否碎块过多需要优化|1/周 |周一上午|10－30分钟|可使用alter tablespace <tablespace name> coalesce对碎块较多的空闲表空间进行整理
2128 |7|汇总本周数据库程序库缓冲命中率|1/周 |周一上午|1－5分钟|使用Oracle提供的statspack生成报表
2129 |8|汇总本周内存中排序比率|1/周 |周一上午|1－5分钟|使用Oracle提供的statspack生成报表
2130 |9|汇总本周数据库数据缓冲命中率|1/周|周一上午|1－5分钟|使用Oracle提供的statspack生成报表
2131 |10|汇总本周数据库级的TOP 5等待事件|1/周|周一上午|1－5分钟|使用Oracle提供的statspack生成报表
2132 |11|汇总本周最耗CPU的 TOP 10 SQL|1/周|周一上午|5－10分钟|使用Oracle提供的statspack生成报表
2133 |12|汇总本周磁盘I/O TOP 10的SQL|1/周|周一上午|5－10分钟|使用Oracle提供的statspack生成报表
2134 |13|汇总本周表空间I/O TOP 10|1/周|周一上午|5－10分钟|使用Oracle提供的statspack生成报表
2135 |总计| | |周一上午|1－2小时|
2136
2137 ====== ======
2138
2139 ====== **5.3.2 数据库管理员负责部分** ======
2140
2141
2142 ====== **​​​​​​​5.3.3 主机系统管理员负责部分** ======
2143
2144 |序号|工作内容|频率|时间|持续时间|备注
2145 |1|清理过时的系统临时文件|1/周 |周一上午|1－5分钟|清理超过14天未访问的$APPLTMP/, /usr/tmp/, 目录下的临时文件
2146 |2|检查磁带库和磁带使用情况|1/周 |周一上午|1－10分钟|检查是否有足够的空间保存备份，磁带库运行中是否有错误出现
2147 |总计| | |周一上午|5－15分钟|
2148
2149
2150 ====== **5.3.4 网络管理员负责部分** ======
2151
2152 |序号|工作内容|频率|时间|持续时间|备注
2153 |1|升级网络安全软件版本（入侵检测漏洞库，病毒库）|1/周|周一上午|10－20分钟|
2154 |总计| | |周一上午|10－20分钟|
2155
2156
2157
2158
2159 ===== **5.4 系统月度维护检查工作列表** =====
2160
2161 ====== **5.4.1 应用系统管理员负责部分** ======
2162
2163 |序号|工作内容|频率|时间|持续时间|备注
2164 |1|汇总本月用户登录审计信息，清除30天以前的审计信息|1/月|每月第一个工作日|5－10分钟|如果需要的话才进行统计
2165 |2|汇总本月用户和职责变动|1/月|每月第一个工作日|5－10分钟|
2166 |3|汇总上月工作纪录报告，和情况总结，提交主管审批|1/月|每月第一个工作日|2－4小时|
2167 |总计| | |每月第一个工作日|2.5－4小时|
2168
2169
2170 ====== **5.4.2 数据库管理员负责部分** ======
2171
2172 |序号|工作内容|频率|时间|持续时间|备注
2173 |1|修改数据库sys和system用户口令|1/月|每月第一个工作日|1－5分钟|
2174 |2|修改数据库APPS口令|1/月|每月第一个工作日|5－10分钟|需要停止服务
2175 |3|检查是否有索引使用的扩展数量过多需要优化|1/月|每月第一个工作日|5－10分钟|使用较大的Extent进行重建索引
2176 |4|检查系统Patch情况|1/月|每月第一个工作日|10分钟|检查Patch记录
2177 |5|汇总本月增长最快的10个表空间|1/月|每月第一个工作日|5－10分钟|根据表空间的已使用和空闲的空间计算增长速度
2178 |6|汇总上月工作纪录报告，提交主管审批|1/月|每月第一个工作日|2－4小时|
2179 |总计| | |每月第一个工作日|3－5小时|
2180
2181
2182 ====== **5.4.3 主机系统管理员负责部分** ======
2183
2184
2185 |(((
2186 ===== 序号 =====
2187 )))|工作内容|频率|时间|持续时间|备注
2188 |1|修改UNIX用户口令|1/月|每月第一个工作日|1－5分钟|修改过UNIX口令之后，需要通知需要知道口令的人员。
2189 |2|清洗磁带机|1/月|每月第一个工作日|1－5分钟|
2190 |3|汇总上月工作纪录报告，提交主管审批|1/月|每月第一个工作日|1－2小时|
2191 |总计| | |每月第一个工作日|1.5－2小时|(((
2192
2193 )))
2194
2195
2196 ====== **5.4.4 网络管理员负责部分** ======
2197
2198
2199 |序号|工作内容|频率|时间|持续时间|备注
2200 |1|汇总上月每天网络运行记录，提交主管审批|1/月|每月第一个工作日上午|15－30分钟|
2201 |总计| | |每月第一个工作日上午|15-30分钟|
2202
2203
2204 ===== **​​​​​​​5.5 系统年度维护检查工作列表** =====
2205
2206 ====== **5.5.1 应用系统管理员负责部分** ======
2207
2208 |序号|工作内容|频率|时间|持续时间|备注
2209 |1|汇总上年度的统计信息，编写年度运行报告|1/年|财务年结之后第一个工作日|4－8小时|
2210 |2|容量测试|1/年|财务年结之后第一个工作日|1－2天|
2211 |总计| | |财务年结之后第一个工作日|1.5－3天|
2212
2213
2214 ====== **5.5.2 数据库管理员负责部分** ======
2215
2216
2217 | 序号|工作内容|频率|时间|持续时间|备注
2218 |1|汇总上年度每月数据库运行情况，编写年度数据库运行报告|1/年|财务年结之后第一个工作日|4－8小时|
2219 |2|容量测试|1/年|财务年结之后第一个工作日|1－2天|
2220 |总计| | |财务年结之后第一个工作日|1.5－3天|
2221
2222
2223 ====== **5.5.3 主机系统管理员负责部分** ======
2224
2225
2226 |序号|工作内容|频率|时间|持续时间|备注
2227 |1|汇总上年度每月主机运行情况，编写年度主机系统运行报告|1/年|财务年结之后第一个工作日|4－8小时|
2228 |2|系统备份|1/年|财务年结之后的第一个周六|30分钟|
2229 |3|容量测试*|1/年|财务年结之后第一个工作日|1－2天|
2230 |4|资产盘点|1/年|财务年结之前或之后|5-15天|包括资产库和配置库的盘点
2231 |总计| | |财务年结之后第一个工作日|6－15天|
2232
2233
2234 ====== **5.5.4 网络管理员负责部分** ======
2235
2236 |序号|工作内容|频率|时间|持续时间|备注
2237 |1|汇总每月网络运行情况报告，形成运行年报|1/年|上午|1－5分钟|
2238 |2|考虑网络系统容量的扩容要求，撰写网络容量报告|1/年|上午|1－5分钟|
2239 |3|网络设备硬件，线路维护|1/年|每年第一个月|5-10天|注18
2240
2241
2242
2243 === **6 KPI设计** ===
2244
2245 建议采用IT平衡计分卡对管理信息系统部所提供的IT服务进行考核和评估，涵盖以下四个方面：
2246
2247 * 关注用户：IT服务的用户都是IT部门的客户
2248 * 价值贡献：IT服务关注于对组织的价值贡献
2249 * 运营效率：IT服务运营效率是IT部门内部流程的关注
2250 * 面向未来发展：面向未来发展考虑IT部门和员工的学习和成长
2251
2252 IT平衡计分卡内容总结如下图所示：
2253
2254
2255 [[image:图片3.png]]
2256
2257
2258 具体到本项目中，这四个主要成效区（KRA：Key Results Area）的具体体现如下表所示：
2259
2260 |主要成效区 KRA|本项目中的具体体现
2261 |(% rowspan="2" %)价值贡献|- 业务系统的可用性
2262 |- 对业务的支撑
2263 |(% rowspan="2" %)关注客户|- 用户满意度
2264 |- 客户投诉
2265 |(% rowspan="2" %)运营效率|- 运维流程的效果
2266 |- 运维流程的效率
2267 |(% rowspan="2" %)面向未来发展|- 监控管理中心的应用
2268 |- 服务的执行和改进
2269
2270
2271 借助IT平衡计分卡，能够实现以下目标：帮助组织树立IT价值观、建立起业务战略目标和IT目标的匹配、使IT绩效考核指标具备可操作性、促进IT部门与业务部门的交流、强化IT管理和IT治理能力。
2272
2273
2274 ===== =====
2275
2276 ===== **6.1 考核指标（KPI）设计原则** =====
2277
2278 ====== **6.1.1 关注客户** ======
2279
2280 从客户的视角评价IT服务水平和质量与成本的有效性，即IT提供的服务与支持在满足个人用户方面达到的水平（这里的用户指核电内部的IT用户），一直是IT部门关注的方面。
2281
2282 主要包括以下指标：
2283
2284 * 管理层：客户满意度（调查反馈）
2285 * 用户：客户满意度（调查反馈）
2286 * 服务支持：
2287
2288 * 客户投诉解决率
2289 * 客户投诉处理及时率
2290 * 客户投诉次数
2291
2292
2293
2294 ====== **6.1.2 价值贡献** ======
2295
2296 信息化系统建设对于IT价值的贡献主要体现在评价其服务性能的提高对于企业的综合影响，主要包括对业务部门的有效支撑。
2297
2298 主要包括以下指标：
2299
2300 * 端到端的服务可用性：
2301
2302 * 统一信息平台可用性
2303 * 关键业务系统可用性
2304
2305 * 服务可靠性：
2306
2307 * 统一信息平台重大故障次数
2308 * 关键业务系统重大故障次数
2309
2310 * 服务可维护性：
2311
2312 * 统一信息平台重大故障平均解决时间
2313 * 关键业务系统重大故障平均解决时间
2314
2315 * 业务支持：
2316
2317 * 处理业务开发需求的数量
2318 * 处理服务请求的数量
2319
2320
2321 ====== **6.1.3 运营效率** ======
2322
2323 运营效率评价的是IT部门服务的有效性和操作效率，要想以低成本为客户交付高质量服务，只有通过优化管理过程才能实现，只有通过对IT内部流程的提高来关注IT交付质量产品与服务的能力。
2324
2325 主要包括以下指标：
2326
2327 * 事件管理：
2328
2329 * 事件平均转派次数
2330 * 事件解决率
2331
2332 * 问题管理：
2333
2334 * 主动发起问题次数
2335 * 问题平均解决时间
2336 * 问题解决率
2337
2338 * 变更/发布管理：
2339
2340 * 变更回退次数
2341 * 变更成功实施率
2342 * 由问题触发的变更数量
2343
2344 * 配置管理：
2345
2346 * 未授权变更次数
2347
2348 * 知识库：
2349
2350 * 由事件或问题生成的知识数量
2351
2352
2353 ====== **6.1.4 面向未来发展** ======
2354
2355 信息化过程的改善和绩效的实现最终离不开正确的人、正确的技术使用和可控制化的流程操作，优化和发展就是通过技能水平的提高以及持续学习的能力为企业发挥导航器的作用，让员工提供交付高质量的服务以及提高个人和集体综合技能。
2356
2357 主要包括以下指标：
2358
2359 * 服务执行：使用监控管理中心各模块的次数
2360 * 服务改善：流程或监控系统优化的次数
2361 * 发展能力：
2362
2363 * 员工对知识库的贡献数量
2364 * 知识库解决方案被引用的次数
2365
2366
2367
2368
2369 ===== **6.2 考核体系量化设计** =====
2370
2371 ====== **6.2.1 考核体系量化建议** ======
2372
2373 建议按照事先定义的KPI，定义各部分权重，并每季度对权重进行审核和调整。
2374
2375 ====== **6.2.2 考核计算方法** ======
2376
2377 作为一种绩效考核方法，评估、核算和激励是基本的程序。具体的目标分解到指标，定期对每个指标进行评测，然后核算出加权的综合值，并按照考核结果行事，奖励每一个取得好成绩的省或人员。
2378
2379 |关键领域|考核指标|指标值|评分|权重|考核分数
2380 |关注客户|用户客户满意度| | | |
2381 | |客户投诉解决率| | | |
2382 | |客户投诉处理及时率| | | |
2383 | |客户投诉次数| | | |
2384 |价值贡献|统一信息平台可用性| | | |
2385 | |统一信息平台重大故障次数| | | |
2386 | |统一信息平台重大故障平均解决时间| | | |
2387 | |关键业务系统可用性| | | |
2388 | |关键业务系统重大故障次数| | | |
2389 | |关键业务系统重大故障平均解决时间| | | |
2390 | |处理业务开发需求的数量| | | |
2391 | |处理服务请求的数量| | | |
2392 |运营效率|事件平均转派次数| | | |
2393 | |事件解决率| | | |
2394 | |主动发起问题次数| | | |
2395 | |问题平均解决时间| | | |
2396 | |问题解决率| | | |
2397 | |由问题触发的变更数量| | | |
2398 | |变更回退次数| | | |
2399 | |变更成功实施率| | | |
2400 | |未授权变更次数| | | |
2401 | |由事件或问题生成的知识数量| | | |
2402 |面向未来发展|使用各模块的次数| | | |
2403 | |流程或监控系统优化的次数| | | |
2404 | |员工对知识库的贡献数量| | | |
2405 | |知识库解决方案被引用的次数| | | |
2406 |(% colspan="3" %) |(% colspan="2" %)总体结果：|
2407
2408
2409 === **7 维护管理制度** ===
2410
2411 * 维护管理制度的目标
2412
2413 为了实现服务管理系统的有效管理，确保江苏核电IT组织提供的服务各环节的规范性，统一客户服务流程模板，保障流程系统安全稳定运行，明确各部门在流程管理中的职责，进行流程管理系统维护管理制度的制定。
2414
2415 * 服务管理保障机制的原则
2416
2417 为了确保此次项目推广的服务管理系统得到严格的贯彻执行，并在执行过程中得到持续改进和提升，根据以往的经验，维护服务管理流程应遵循以下原则
2418
2419 1. 重视流程意识培养和流程内容的培训工作
2420 1. 强化流程的执行工作，与绩效考核挂钩
2421 1. 实施详细的流程回顾、报告工作
2422 1. 建立有效的执行状态审核评估体系
2423 1. 务实处理在实际工作中有关维护流程的问题，使流程不断改进提升
2424
2425 * 维护范围
2426
2427 ITSM系统管理的是信息化所维护的系统和网络，业务系统包括统一信息平台系统、网管监控系统、ERP财务系统、ERP人力资源系统、ERP物流系统、ERP综合统计系统；以及所有应用系统涉及到的设备包括业务主机、数据库、存储设备、接口主机、开发系统等。
2428
2429 流程系统维护管理将主要包括：
2430
2431
2432
2433 ===== **7.1 对组织的维护管理** =====
2434
2435 **1 流程改进委员会**
2436
2437 建议在江苏核电信息中心设立流程改进委员会，负责领导管理信息系统部的流程改进工作，为流程改进的思路和方向提供决策性意见，并为具体流程改进工作的开展提供管理层支持。流程改进委员会同时负责为新的服务管理流程确定流程负责人。
2438
2439 **2 流程及质量组**
2440
2441 建议在IT部门设立流程及质量组，由其负责牵头制订流程改进年度计划、确保流程改进年度计划的落实，收集分析流程改进建议，组织协调资源实施流程改进，并跟踪流程改进的实施效果。流程及质量组还负责对改进后的流程进行制度化、标准化，组织相关的培训，确保IT部门按改进后的流程运作。
2442
2443 **3 流程改进项目组**
2444
2445 对于重大的流程改进点，建议由流程改进委员会经过评审和批准后，成立专门的流程改进项目组，以项目管理的方式运作。流程改进委员会从资源、投入和管理层支持角度对项目提供保障。流程改进项目组负责组织协调资源制订详细的项目计划，领导项目实施，并主持试运行和推广工作。
2446
2447 **4 流程负责人**
2448
2449 流程负责人负责配合流程及质量组牵头制订流程改进年度计划，确保流程改进年度计划的落实(重点在其负责的流程)，收集分析流程改进的建议，实施流程改进，并跟踪流程改进的实施效果。各流程负责人还负责在流程及质量组牵头下，对改进后的流程进行制度化、标准化，组织相关的培训，并确保IT部门按改进后的流程运作。
2450
2451
2452
2453 ===== **​​​​​​​7.2 对流程的维护管理** =====
2454
2455 **1 对流程执行情况进行月度检查**
2456
2457 以月为单位，由各流程的经理对各流程执行情况进行回顾，主要检查流程中各角色是否按照流程中预先设定的规则、政策的要求进行执行，是否存在人员未按流程要求执行的情形。
2458
2459 **2 对流程执行情况进行季度检查**
2460
2461 以季度为单位，由各流程的经理对各流程的执行效果进行回顾，主要检查各流程中规则、政策定义的是否合理，是否符合实际的工作需求。例如事件流程三次转派升级到事件经理的政策是三次合理还是五次合理？
2462
2463 **3 对流程执行情况进行年度检查**
2464
2465 以年度为单位，由各流程的流程负责人组织，流程经理和流程各角色人员参加，对各流程的整体执行效果进行评估，主要评估流程是否执行的有效果和高效率，流程的政策和流程本身是否需要调整。例如事件流程三次转派升级到事件经理的政策是否应该保留？
2466
2467
2468 ===== **​​​​​​​7.3 对平台工具的维护管理** =====
2469
2470 **1 配置流程所需配置数据**
2471
2472 系统管理员应根据用户或实际工作的需要对流程所需的配置数据进行及时准确的设置，以保证流程系统的运转。例如配置流程角色，配置事件分类等等，具体配置任务可以参考系统维护手册。
2473
2474 **2 系统license管理**
2475
2476 系统管理员应留意系统中license的使用情况，以保证系统用户的系统操作不受到影响。License的使用情况可以通过Remedy的AR Admin工具进行查看。
2477
2478 **3 修改AR Server设置**
2479
2480 系统管理员应该根据实际工作需要对AR Server的系统配置进行合理修改。修改AR Server设置可以通过Remedy的AR Admin工具进行。
2481
2482 **4 启动和停止服务**
2483
2484 系统管理员应该根据实际工作需要对AR Server的服务进行启动和停止操作。
2485
2486 **5 监控服务状态**
2487
2488 系统管理员应该经常监控服务期的运行状态，主要包括以下进程：
2489
2490
2491 * Arsvcdsp
2492 * Arplugin
2493 * armonitor
2494 * arserverd
2495 * arforkd
2496 * com.remedy.arsys.emaildaemon.EmailDaemon（Email Engine java进程）
2497
2498 **6 监控系统日志**
2499
2500 系统管理员为保证系统运行的稳定，必须对系统日志进行监控，并留意日志文件的增长，避免出现磁盘容量不足的问题。系统日志监控主要对以下日志进行：
2501
2502 arerror.log
2503
2504 **7 系统数据备份**
2505
2506 Remedy平台所有的程序数据和业务数据全部保存在数据库中，所以只要对数据库进行备份即可。由于数据库备份原则已经在整个项目要求中明确，所以系统管理员主要要留意检查备份是否成功及应用服务器设置参数的备份。
2507
2508 **8 处理系统故障**
2509
2510 系统管理员应及时对系统出现的故障进行解决，或及时联系相关技术人员对系统故障进行解决。
2511
2512
2513
深圳市艾拓先锋企业管理咨询有限公司