返回本章节索引    阅读下一篇

某公司ITIL信息技术服务管理体系IT服务管理咨询—运行管理规范

1 日常工作管理建议

1.1 日常管理

1.1.1 轮班制度

信息中心，尤其是服务台小组应当制定一个轮班制度和步骤，并明确由何人负责修改该制度、步骤，由谁授权这些修改，如何发布新的修改，并制定修改的规则，以保障操作员的利益。

1.1.2 休假，培训，病假和其他事假

应当记录并维护所有的缺席状态，确保核心系统总是技术人员能够支持。应当制定审批休假的授权标准，确定授权人，确保现场有足够的人员工作。另外，应当制定备份方案，以防关键人员病假或者其他原因不能到场支持。

1.1.3 电话值班

对于核心业务系统，每天应当确定在正常工作时间之外的主责支持人员和后备人员，称为“电话值班人员”，当天的支持人员应当确保手机等联络工具通畅。特别对于一些不太稳定的系统，工作时间之外可能更需要频繁的现场支持。值班人员应当清楚了解每个支持人员的联系方式，以防主责人员联系不到时可以联系后备人员。

应当建立内部的服务水平，如：对于紧急电话的响应时间、到现场时间、解决问题的时间等，加强对于紧急事件处理的责任感和效率。

如果支持人员未能响应，或者未能及时到场，可以采用事件升级的步骤。

1.2 检查清单（备忘录）

1.2.1 换班交接检查清单 

可以为所有参与操作值班的员工制定一份检查清单，避免员工在交接班的时候遗漏任何应当转交的内容。

1.2.2 其他交接清单（如：服务台与操作小组之间的交接）

同样，也可以为服务台（在工作时间接受事件报告）与操作组（在非工作时段接受事件报告）交接时制定交接清单。该清单应包括所在值班时段发生的重大事件，以及一些需要下一班注意的事项。

1.2.3 监控检查清单

所有的维护组员工应当制定每日维护工作的检查清单，包括每日应当监控和检查的项目（如：必须人工检查的内容，设备指示灯、屏幕、以及运行一些检查脚本程序的结果等），以及其他每日例行的工作。检查清单可以细分为日检查清单、周检查清单、月检查清单、年检查清单。这些清单应当由小组长签字，确保所列项目都已执行。

如果某个员工遗漏了某些检查项目，必须有正当的理由。

1.2.4 值班日记（包括注意事项、意外情况、经验教训等） 

很多IT部门的操作部门都会维护一份值班日记，纪录值班期间发生的意外情况、注意事项、经验教训等。值班日记也成为交接内容的一个重要部分。

1.3 公告管理

“公告”指信息中心对其所服务对象（各业务部门）的信息公示手段，可采用的手段包括系统公告，邮件群发，张贴纸质通告等手段，目的就是将信息最有效的通知到目标人群。

公告建议由服务台人员统一管理。

非服务台人员在具备发出公告条件时，需通知服务台人员，由服务台人员负责发出公告，通知方式不限。

1.3.1 触发条件和通知对象

1.3.2 公告用语

公告包括“标题”“正文”“落款”三个组成部分。

2 服务台运行管理

2.1 电话接听规范

2.1.1 接听电话应当迅速

1、服务台人员应在电话铃响起三声内接起,延迟应表示歉意。

2、电话响起时，服务台人员不在，应由其他服务台人员接起电话，以不耽误客户为主。

3、在电话铃响时，一面用左手拿起话筒，而右手马上伸到便条纸边，只要能采取这种姿势，应对的内容自然也会得体。

4、如使用悬挂式耳机和相关的信息记录系统，应在接起电话后迅速打开电脑记录页面，将电话中获取到的信息记录在系统中。

2.1.2 电话用语

1. 使用 “您好”，“请问”，“不用客气”，“再见”等文明用语,不使用“嗨”，“唉”等不礼貌用语。
2. 声音甜美，声调稍微高一点使客户容易听清楚，不要把不好的情绪带进电话。
3. 报部门名称，询问客户部门等具体具体信息。
4. 询问客户问题详细情况，仔细倾听并记录。
5. 勿忘5W1H及电话中的传达和复诵。“5W1H”即：何时（WHEN），谁（WHO，WHOSE），何地（WHERE），何事（WHAT），如何处理（HOW）。传达时应力求简捷。为防止错误，应该在最后说：“请让我确认一下您刚才所说的话。”而复诵所记下的内容，倘若双方有传错或听错的情形，便可以在此时改过来，除此之外，如果是我们打过去的电话，而对方没有复诵时，我们也可以尽量要求对方再复诵一遍，以确认对方是否已正确的记下我们所要传达的事情。
6. 语速不要太快，解释尽量详细，以最终解决问题为目的。
7. 接电话时尽量不去接别的电话。
8. 不要主动提出挂电话。

2.1.3 工作时间不允许公话私用

不允许在工作时间用服务台电话打私人电话。打到公司的电话，并不一定是有关公事，有时候是职员的家人或朋友打来的私人电话，由于私人电话很可能会妨碍到公事，应尽可能请家人或朋友打私人电话。但如果非常重要的事情，不得不在公司接听电话时，应该力求简洁，把要联络的事情说完即可，避免电话占线。

2.2 Case受理规范

2.2.1 客户信息记录准确

受理Case时首先要询问员工编号，没有员工编号的可以记录临时邮件账号或联系电话，以便进行Case问题的跟踪及进行信息反馈。

2.2.2 问题信息记录准确

详细记录客户描述的问题现象，当可以解决问题时需记录问题原因及解决方法，以便放到知识库中使资源共享。未能解决的问题可以分发给现场或进行初步处理，进行初步处理的Case要对问题进行跟踪，直到问题解决。

2.2.3 处理客户投诉遵循的原则

2.2.4 状态跟踪机制

我们遇到投诉或者是投诉升级的时候经常会发现，好像每个处理的人都做了合理的事情，但是投诉还是产生和升级了。其实这就是由于没有一个事件跟踪的流程导致的，很多部门配合的时候更容易出现这样的情况，因此说这种事件状态跟踪机制是必需的，而且不仅仅是在投诉的处理上面。事情的处理一定是闭环的，有头有尾的。

服务台人员必须首先对自己接手处理的事件负责，有责任和义务跟踪自己处理事件的当前状态并在需要时反馈给用户。

    服务台经理对整个服务台的事件处理情况负责。

2.2.5 投诉升级机制

有了状态跟踪机制其实并不能保证事情得到及时的处理，这需要另外一个机制来控制——投诉处理升级机制。如果一件事情在相应规定的时间没有解决掉，相关的管理者会逐级得到信息——该投诉未能及时处理完成以及当前的状态。这样相应的管理人员就逐渐参与到投诉的处理当中，加快事件的处理。而一般的投诉专人负责的岗位就已经可以处理了，管理者只需要按时得到每周的报告就可以了。

事件超时时会自动升级至事件经理，事件经理通常是服务台经理兼任，事件经理有责任和权利协调资源优先处理升级事件，包括与二线团队协调资源。

2.2.6 报告机制

已经有跟踪、升级处理等机制，但如果想把用户投诉的问题转化为服务提升的动力，那详细的分析报告将是非常重要和必需的。一个简单扼要、眼光敏锐、总结分析到位的报告对管理者提升服务来说是很有帮助的。

服务台建议设置周报和月报制度，每周和每月定时将报告汇总给服务台经理。

2.2.7 回访处理

投诉处理结束了，我们还有事情要做，就是对曾经投诉我们服务的用户进行回访，投诉过你的用户今后可能还是你的用户，请他谈谈对改进后的服务的看法，听听用户对整体服务的意见和建议。

2.3 处理投诉的基本方法

以下为对于服务台人员在处理投诉时的基本方法建议，实际上这些建议对于非投诉类Case的处理一样适用。

2.3.1 用心聆听

聆听是一门艺术，从中你可以发现客户的真正需求，从而获得处理投诉的重要信息。

2.3.2 表示道歉

如果你没有出错，就没有理由惊慌，如你真的出错，就得勇于面对。请记住客户之所以动气是因遇上问题，你漠不关心或据理力争。找借口或拒绝，只会使对方火上加油，适时的表示歉意会起到意想不到的效果。

2.3.3 仔细询问

引导用户说出问题重点，有的放矢。表示同情如果对方知道你的确关心他的问题，也了解他的心情，怒气便会消减一半。找出双方一起同意的观点，表明你是理解他的。

2.3.4 记录问题

对于投诉类的问题，必须忠实详尽的记录投诉者、投诉的原因、被投诉者、内容、处理过程、解决情况等信息。

2.3.5 解决问题

探询客户希望解决的办法，一旦你找出方法，征求客户的同意。如果客户不接受你的办法，请问他有什么提议或希望解决的方法，不论你是否有权决定，让客户随时清楚地了解你的进程。如果你无法解决，可推荐其他合适的人，但要主动地代为联络。礼貌地结束。当你将这件不愉快的事情解决了之后，必须问：请问您觉得这样处理可以了吗？您还有别的问题吗？……。如果没有，就多谢对方提出的问题。

2.4 培训制度

培训是服务台服务的重要成功因素。若没有适当的初期和持续培训，服务台将不能提供最佳的客户服务。持续培训可以使服务台人员掌握所需技能。它也可以提高生产力，改善客户服务，此外还能增加服务台人员的工作满意程度，自信心。

2.5 考核标准

以下是对服务台工作的考核标准

2.5.1 电话接通率和响应时间

2.5.2 客户满意度

2.5.3 本月投诉 

2.5.4 服务台解决率

3 流程运行管理规范

3.1 工单分派

3.1.1 技能组设置表

为了支持运维流程的正常运转，有必要将信息中心所有IT支持人员进行编组，一般会按照其运维职责和技能情况进行编组。

流程设计和组织人员调整时，需填写技能组列表和人员技能组对应表，所需表格格式如下：

技能组列表：

人员技能组对应表：

3.1.2 分派规范

在ITSM系统中，技能组是工单分派的基本单元，工单将按照分类分派到与此分类有映射关系的技能组。

在流程设计和组织调整时，需填写分类与技能组对应表，下表为格式参考样例：

3.1.3 优先选择规范

当同一分类有多个技能组可选择对应时，需指定优先顺序，如：桌面类网络故障有终端组和网络组可选，应优先选择终端组，只有当终端组人员紧张或拒绝接受工单时才可以选择非优先的技能组。

优先选择规范在ITSM系统中应该有具体的提示，但不具备强制性。

3.1.4 AB角规范 

每个技能组内部将实行“AB角”制度，设定一名员工为“A角”即“默认联系人”，其他组内人员为“B角”，当工单派发至技能组时，A角有权利同时也有义务第一时间代表所在技能组接受指派，当A角人员处于忙碌或不可用状态时，由B角人员代替。

“AB角”不是管理职位，其目的是为了流程的流畅运行，一名员工在甲技能组是“A角”，在乙技能组亦可能是“B角”。

“AB角”在ITSM流程中不存在强制性，由AB角人员自行判断接单。

每个员工应清楚了解自己在技能组中的角色位置，并履行权利义务。

3.2 工单信息填写

在ITSM系统中的工单是由数十个信息项（字段）构成的电子表单，这些信息项分别承载记录了工单不同的信息，在填写时，首先需要根据提示区分必填、选填、只读字段。

必填字段为必须填写的字段，一般会在表单上以红色*号表示；

选填字段是一般的空白字段，可以按照需要选择填写或者留空；

只读字段是不允许填写或修改的字段，一般会在表单上以灰色填充表示。

此外，按照信息项种类的不同，填写时需遵循以下规范：

3.3 事件管理

3.3.1 应用场景

事件管理主要功能是尽快解决出现的突发事件，保持业务系统的稳定性。

下表为事件管理流程的应用场景和说明，在如下场景中，将使用事件管理流程来处理：

3.3.2 各节点检查事项说明

检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。

这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。

​​​​​​​3.3.3 流程负责人制度

事件管理各角色和职责：

工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。

​​​​​​​3.3.4 考核指标

流程考核指标参考：

3.3.5 回顾机制

一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。

流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。

流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。

流程回顾例会应包括以下内容：

3.4 服务请求管理

3.4.1 应用场景

服务请求管理主要功能提供一个清晰的服务目录，提升IT服务的专业性，并降低沟通成本。

服务请求首先是配合着服务目录来决定对外提供哪些服务的，在江苏核电的环境中，服务请求用来处理所有需要用户填写申请表单的服务申请。

下表为服务请求流程的服务目录，在服务目录所列条目内的所有服务，将使用服务请求管理流程来处理，服务目录是随时更新的：

3.4.2 各节点检查事项说明

检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。

这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。

3.4.3 流程负责人制度

服务请求管理各角色和职责：

工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。

3.4.4 考核指标

流程考核指标参考：

​​​​​​​​​​​​​​3.4.5 回顾机制

一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。

流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。

流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。

流程回顾例会应包括以下内容：

3.5 问题管理

3.5.1 应用场景

问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。

对于问题管理而言，问题的产生主要来自于四个方面：

3.5.2 各节点检查事项说明

检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。

这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。

3.5.3 流程负责人制度

问题管理各角色和职责：

工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。

3.5.4 考核指标

流程考核指标参考：

​​​​​​​3.5.5 回顾机制

一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。

流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。

流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。

流程回顾例会应包括以下内容：

3.6 变更管理

3.6.1 应用场景

变更管理流程的根本目的是通过严格的控制将变更操作对生产环境产生的影响降到最小。

根据变更对象的不同，变更场景可以区分为两种：

​​​​​​​3.6.2 各节点检查事项说明

检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。

这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。

​​​​​​​3.6.3 流程负责人制度

变更管理各角色和职责：

此处需要强调的是CAB/EC的人员构成：

CAB（变更顾问委员会）是由信息中心的管理人员组成的虚拟小组，主要由各相关部门的领导、各个服务负责部门的资深人员或者技术骨干组成，有时也会包括发起变更请求的业务部门的代表、第三方厂商集成商等参与。CAB应当由该专业有较高技能的人员组成，同时，这些成员对于业务需求、业务逻辑、IT系统技术、应用开发、测试、支持等方面也较为熟悉。

EC（紧急变更委员会）通常可以属于CAB的一个子集

CAB/EC由于成员不定，所以应该有一个最小集，我们建议的CAB/EC的最小集应包括：

1. 主管信息领导
2. 信息部门负责人
3. 变更经理
4. 变更受理人

工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。

1. 
   
   1. 
      
      1. 考核指标

流程考核指标参考：

3.6.4 回顾机制

一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。

流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。

流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。

流程回顾例会应包括以下内容：

​​​​​​​3.7 发布管理

3.7.1 应用场景

发布管理流程通过规范操作流程，平稳地对生产系统进行变更，从而化解和控制变更可能产生的风险，满足业务发展的需要。

发布管理的应用范围与变更相同，但发布管理的规模和关注点与变更不同。

一个发布要求实现一个整体目标，发布会关联出一系列变更来进行具体实施，并对这一系列变更进行总体的协调和控制以保证发布的质量

​​​​​​​3.7.2 各节点检查事项说明

检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。

这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。

​​​​​​​3.7.3 流程负责人制度

发布管理各角色和职责与变更相同。

工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。

​​​​​​​3.7.4 考核指标

流程考核指标参考，发布管理通过分解的变更具体实现，所以发布管理的衡量指标与变更管理一致：

3.7.5 回顾机制

一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。

流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。

流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。

流程回顾例会应包括以下内容：

变更和发布的回顾例会建议应该在一起进行。

3.8 配置和资产管理

3.8.1 应用场景

配置管理是一个持续性的过程，包括计划、记录和管理数据，它管理数据中心运行环境有关的组件。该流程为IT组织提供提供所管理的IT组件的情况，包括组件之间互相的关系和状况。

配置管理的目标是记录和维护IT架构中相关组件的准确信息（避免防止人为的误操作造成服务的不可用或服务质量的下降） ,包括组件之间的关系，为其他服务支持和服务供应流程提供信息。

IT资产管理是一个管理的过程，对于资产的生命周期进行记录与控制。该流程为IT组织提供所管理的IT物理资产在生命周期所产生的财务管理目标的基础数据。

IT资产管理的目标是记录和维护IT信息管理与IT相关的物理资产的生命周期与财务信息。IT资产管理相对于IT服务管理独立，只共用配置管理数据库。

IT资产管理和配置管理都是基于同一个配置管理数据库的，但资产管理与配置管理是用两种不同的视角去来衡量同一个事物。

各种不同类别的CI从“入库接收--上线工作--报废处置”的整个生命周期内，资产管理和配置管理各自涵盖的范围。

3.8.2 各节点检查事项说明

检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。

这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。

​​​​​​​3.8.3 流程负责人制度

各角色和职责：

3.8.4 考核指标

流程考核指标参考：

3.8.5 回顾机制

一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。

流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。

流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。

流程回顾例会应包括以下内容：

配置和资产的管理回顾例会不必要频率过高，推荐季度例会，配置和资产例会可以选择分别召开。

3.9 需求管理

3.9.1 应用场景

需求管理主要功能提供一个用户提出对应用系统修改意见的通道，提升IT服务的专业性，并降低沟通成本。

需求管理的应用较为专业，只针对于业务部门汇报生产环境或准生产环境下的应用系统BUG或功能修改意见，提交于应用开发团队。

3.9.2 各节点检查事项说明

检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。

这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。

​​​​​​​3.9.3 流程负责人制度

需求管理各角色和职责：

工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。

3.9.4 考核指标

流程考核指标参考：

3.9.5 回顾机制

一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。

流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。

流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。

流程回顾例会应包括以下内容：

4 知识管理规范

4.1 知识库的管理

1. 知识库的内容收集、更新、维护、清理、权限控制、审核与发布都应该建立完善的管理制度并责任到人。
2. 服务台人员对已启用的事件管理平台和问题管理平台中出现的问题进行归类整理，对出现的各个事件按部门、类型、处理难易度、解决时间等进行化类区分，并存入知识库。
3. 信息中心各部门应设有专门的知识库管理员和文档库管理员，负责知识和文档的统一提交、审核、整理、维护。

4.2 维护管理任务说明

1. 知识审批流程
2. 知识和文档分类与入库
3. 新建知识库和文档库
4. 知识库系统健康检查
5. 知识访问相关统计

4.2.1 知识管理系统健康检查

• 工作内容： 知识管理系统健康检查
• 责任人：系统管理员
• 维护周期：每周
• 执行时间：周五
• 执行步骤：

1. 登录门户，进入知识管理模块，对任意知识库进行查询、浏览、检查知识库是否工作正常
2. 检查知识模块的各项主要功能服务是否正常

4.2.2 知识草稿审批

• 工作内容： 知识管理系统健康检查
• 责任人：知识管理员
• 维护周期：每天
• 执行时间：每天12:00
• 执行对象：各知识库
• 执行步骤：

1. 进入知识管理模块，查看上一日用户提交的知识草稿，发起知识审批流程
2. 将审批通过的知识草稿进行分类、导入相应知识库成为正式知识
3. 将未通过的知识草稿进行相应处理

​​​​​​​4.2.3 知识提交、访问相关统计

• 工作内容： 知识管理系统健康检查
• 责任人：知识管理员
• 维护周期：每月
• 执行时间：每月5日17:00前
• 执行对象：报表系统
• 执行步骤：登录进入报表模块，访问知识提交、访问统计报表，生成相应的报表文件，并将结果反馈给知识经理。

​​​​​​​4.2.4 知识重新分类

• 工作内容： 知识重新分类
• 责任人：知识管理员、系统管理员
• 维护周期：每周
• 执行时间：每周五  12:00前
• 执行对象：知识库、文档库
• 执行步骤：

1. 检查用户对最近新增知识的评价，汇总是否有知识重新分类的需求
2. 对知识进行重新分类

5 日常的周期性维护操作

本章总结了系统管理操作员（应用系统管理员，数据库管理员，主机系统管理员、网络管理员）日常维护工作的流程和具体需要完成的工作纪录表。同时所有的系统管理操作员在做日常维护工作时，应按照系统要求的格式填写好相应的每日、每周、月度、年度维护工作记录表。

​​​​​​​5.1 日常的周期性维护工作

1 是否是周一

如果当天是周一，则需要先执行系统每周维护工作

2 是否是每月第一个工作日

如果当天是当月第一个工作日，则需要先执行系统每月维护工作

3 是否是财务年结之后第一个工作日

如果当天是财务年结之后第一个工作日，则需要先执行系统每年维护工作

4 填写维护工作记录表单（ITSM系统）

5.2 系统每日维护检查工作列表

5.2.1 应用系统管理员负责部分

5.2.2 数据库管理员负责部分

5.2.3 主机系统管理员负责部分

5.2.4 网络管理员负责部分

5.3 系统每周维护检查工作列表

5.3.1 应用系统管理员负责部分

5.3.2 数据库管理员负责部分

​​​​​​​5.3.3 主机系统管理员负责部分

5.3.4 网络管理员负责部分

5.4 系统月度维护检查工作列表

5.4.1 应用系统管理员负责部分

5.4.2 数据库管理员负责部分

5.4.3 主机系统管理员负责部分

5.4.4 网络管理员负责部分

​​​​​​​5.5 系统年度维护检查工作列表

5.5.1 应用系统管理员负责部分

5.5.2 数据库管理员负责部分

5.5.3 主机系统管理员负责部分

5.5.4 网络管理员负责部分

6 KPI设计

建议采用IT平衡计分卡对管理信息系统部所提供的IT服务进行考核和评估，涵盖以下四个方面：

• 关注用户：IT服务的用户都是IT部门的客户
• 价值贡献：IT服务关注于对组织的价值贡献
• 运营效率：IT服务运营效率是IT部门内部流程的关注
• 面向未来发展：面向未来发展考虑IT部门和员工的学习和成长

IT平衡计分卡内容总结如下图所示：

具体到本项目中，这四个主要成效区（KRA：Key Results Area）的具体体现如下表所示：

借助IT平衡计分卡，能够实现以下目标：帮助组织树立IT价值观、建立起业务战略目标和IT目标的匹配、使IT绩效考核指标具备可操作性、促进IT部门与业务部门的交流、强化IT管理和IT治理能力。

6.1 考核指标（KPI）设计原则

6.1.1 关注客户

从客户的视角评价IT服务水平和质量与成本的有效性，即IT提供的服务与支持在满足个人用户方面达到的水平（这里的用户指核电内部的IT用户），一直是IT部门关注的方面。

主要包括以下指标：

• 管理层：客户满意度（调查反馈）
• 用户：客户满意度（调查反馈）
• 服务支持：

• 客户投诉解决率
• 客户投诉处理及时率
• 客户投诉次数

6.1.2 价值贡献

信息化系统建设对于IT价值的贡献主要体现在评价其服务性能的提高对于企业的综合影响，主要包括对业务部门的有效支撑。

主要包括以下指标：

• 端到端的服务可用性：

• 统一信息平台可用性
• 关键业务系统可用性

• 服务可靠性：

• 统一信息平台重大故障次数
• 关键业务系统重大故障次数

• 服务可维护性：

• 统一信息平台重大故障平均解决时间
• 关键业务系统重大故障平均解决时间

• 业务支持：

• 处理业务开发需求的数量
• 处理服务请求的数量

6.1.3 运营效率

运营效率评价的是IT部门服务的有效性和操作效率，要想以低成本为客户交付高质量服务，只有通过优化管理过程才能实现，只有通过对IT内部流程的提高来关注IT交付质量产品与服务的能力。

主要包括以下指标：

• 事件管理：

• 事件平均转派次数
• 事件解决率

• 问题管理：

• 主动发起问题次数
• 问题平均解决时间
• 问题解决率

• 变更/发布管理：

• 变更回退次数
• 变更成功实施率
• 由问题触发的变更数量

• 配置管理：

• 未授权变更次数

• 知识库：

• 由事件或问题生成的知识数量

6.1.4 面向未来发展

信息化过程的改善和绩效的实现最终离不开正确的人、正确的技术使用和可控制化的流程操作，优化和发展就是通过技能水平的提高以及持续学习的能力为企业发挥导航器的作用，让员工提供交付高质量的服务以及提高个人和集体综合技能。

主要包括以下指标：

• 服务执行：使用监控管理中心各模块的次数
• 服务改善：流程或监控系统优化的次数
• 发展能力：

• 员工对知识库的贡献数量
• 知识库解决方案被引用的次数

6.2 考核体系量化设计

6.2.1 考核体系量化建议

建议按照事先定义的KPI，定义各部分权重，并每季度对权重进行审核和调整。

6.2.2 考核计算方法

作为一种绩效考核方法，评估、核算和激励是基本的程序。具体的目标分解到指标，定期对每个指标进行评测，然后核算出加权的综合值，并按照考核结果行事，奖励每一个取得好成绩的省或人员。

7 维护管理制度

• 维护管理制度的目标

为了实现服务管理系统的有效管理，确保江苏核电IT组织提供的服务各环节的规范性，统一客户服务流程模板，保障流程系统安全稳定运行，明确各部门在流程管理中的职责，进行流程管理系统维护管理制度的制定。

• 服务管理保障机制的原则

为了确保此次项目推广的服务管理系统得到严格的贯彻执行，并在执行过程中得到持续改进和提升，根据以往的经验，维护服务管理流程应遵循以下原则

1. 重视流程意识培养和流程内容的培训工作
2. 强化流程的执行工作，与绩效考核挂钩
3. 实施详细的流程回顾、报告工作
4. 建立有效的执行状态审核评估体系
5. 务实处理在实际工作中有关维护流程的问题，使流程不断改进提升

• 维护范围

ITSM系统管理的是信息化所维护的系统和网络，业务系统包括统一信息平台系统、网管监控系统、ERP财务系统、ERP人力资源系统、ERP物流系统、ERP综合统计系统；以及所有应用系统涉及到的设备包括业务主机、数据库、存储设备、接口主机、开发系统等。

流程系统维护管理将主要包括：

7.1 对组织的维护管理

1 流程改进委员会

建议在江苏核电信息中心设立流程改进委员会，负责领导管理信息系统部的流程改进工作，为流程改进的思路和方向提供决策性意见，并为具体流程改进工作的开展提供管理层支持。流程改进委员会同时负责为新的服务管理流程确定流程负责人。

2 流程及质量组

建议在IT部门设立流程及质量组，由其负责牵头制订流程改进年度计划、确保流程改进年度计划的落实，收集分析流程改进建议，组织协调资源实施流程改进，并跟踪流程改进的实施效果。流程及质量组还负责对改进后的流程进行制度化、标准化，组织相关的培训，确保IT部门按改进后的流程运作。

3 流程改进项目组

对于重大的流程改进点，建议由流程改进委员会经过评审和批准后，成立专门的流程改进项目组，以项目管理的方式运作。流程改进委员会从资源、投入和管理层支持角度对项目提供保障。流程改进项目组负责组织协调资源制订详细的项目计划，领导项目实施，并主持试运行和推广工作。

4 流程负责人

流程负责人负责配合流程及质量组牵头制订流程改进年度计划，确保流程改进年度计划的落实(重点在其负责的流程)，收集分析流程改进的建议，实施流程改进，并跟踪流程改进的实施效果。各流程负责人还负责在流程及质量组牵头下，对改进后的流程进行制度化、标准化，组织相关的培训，并确保IT部门按改进后的流程运作。

​​​​​​​7.2 对流程的维护管理

1 对流程执行情况进行月度检查

以月为单位，由各流程的经理对各流程执行情况进行回顾，主要检查流程中各角色是否按照流程中预先设定的规则、政策的要求进行执行，是否存在人员未按流程要求执行的情形。

2 对流程执行情况进行季度检查

以季度为单位，由各流程的经理对各流程的执行效果进行回顾，主要检查各流程中规则、政策定义的是否合理，是否符合实际的工作需求。例如事件流程三次转派升级到事件经理的政策是三次合理还是五次合理？

3 对流程执行情况进行年度检查

以年度为单位，由各流程的流程负责人组织，流程经理和流程各角色人员参加，对各流程的整体执行效果进行评估，主要评估流程是否执行的有效果和高效率，流程的政策和流程本身是否需要调整。例如事件流程三次转派升级到事件经理的政策是否应该保留？

​​​​​​​7.3 对平台工具的维护管理

1 配置流程所需配置数据

系统管理员应根据用户或实际工作的需要对流程所需的配置数据进行及时准确的设置，以保证流程系统的运转。例如配置流程角色，配置事件分类等等，具体配置任务可以参考系统维护手册。

2 系统license管理

系统管理员应留意系统中license的使用情况，以保证系统用户的系统操作不受到影响。License的使用情况可以通过Remedy的AR Admin工具进行查看。

3 修改AR Server设置

系统管理员应该根据实际工作需要对AR Server的系统配置进行合理修改。修改AR Server设置可以通过Remedy的AR Admin工具进行。

4 启动和停止服务

系统管理员应该根据实际工作需要对AR Server的服务进行启动和停止操作。

5 监控服务状态

系统管理员应该经常监控服务期的运行状态，主要包括以下进程：

• Arsvcdsp
• Arplugin
• armonitor
• arserverd
• arforkd
• com.remedy.arsys.emaildaemon.EmailDaemon（Email Engine java进程）

6 监控系统日志

系统管理员为保证系统运行的稳定，必须对系统日志进行监控，并留意日志文件的增长，避免出现磁盘容量不足的问题。系统日志监控主要对以下日志进行：

 arerror.log

7 系统数据备份

Remedy平台所有的程序数据和业务数据全部保存在数据库中，所以只要对数据库进行备份即可。由于数据库备份原则已经在整个项目要求中明确，所以系统管理员主要要留意检查备份是否成功及应用服务器设置参数的备份。

8 处理系统故障

系统管理员应及时对系统出现的故障进行解决，或及时联系相关技术人员对系统故障进行解决。