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

Last modified by superadmin on 2024/06/24, 14:36

From version < 4.1

edited by superadmin
on 2024/06/24, 14:36

To version < 3.1 >

edited by superadmin
on 2024/06/24, 14:30

Change comment: 上传新附件图片3.png

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,0 @@
1		-32 某公司ITIL信息技术服务管理体系IT服务管理咨询—运行管理规范

Parent

...	...	@@ -1,1 +1,0 @@
1		-G 参考资料.ITIL实施项目资料.ITIL实施项目流程设计方案集.管理规范.WebHome

Content

@@ -1,2513
          +1,0 @@
--[[返回本章节索引>>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/]]    阅读下一篇
--
--
--= **某公司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的事件|受影响用户|故障解决后
--|停机通告|影响为1和2的变更在执行前，需要发出停机通告|受影响用户|变更完成后
--
--
--====== **1.3.2 公告用语** ======
--
--公告包括“标题”“正文”“落款”三个组成部分。
--
--
--|**种类**|文档发放
--|**内容要求**|需说明发放部门，接收部门，文档用途，如果需要填写并回收的，需说明负责人、填写方法、回收方式及期限。
--|**范例**|(((
--OA系统使用情况调查表发放通知
--
--
--为配合OA项目组更好的进行系统测试的工作，现下发OA系统使用情况调查表，希望各相关部门予以配合。
--
--各部门每位OA使用者均需要填写，下载附件调查表并按表内提示填写完成后，交与各部门信息管理员汇总，由信息管理员统一发送至信息中心~*~**处。
--
--截止日期为~*~*~*~*。
--
--联系人电话：~*~*~*~*，邮箱：~*~*~*~*
--
--谢谢配合！
--
--
--附件：OA系统使用情况调查表.doc
--
--                                                         信息中心
--
--                                                         XXXX-6-20
--)))
--
--
--|**种类**|信息公示
--|**内容要求**|需说明信息内容，信息所针对范围，信息生效和失效时间。
--|**范例**|(((
--公司OA系统使用规范v1.0
--
--
--为配合OA系统的正式启用，现在发布《公司OA系统使用规范》v1.0版，主要是对公司内OA用户进行使用上的指导和规范，以及一些重要功能的操作指导和约束。请各OA用户认真下载阅读。
--
--本规范从发布之日起生效。
--
--谢谢配合！
--
--
--附件：公司OA系统使用规范 v1.0.doc
--
--                                                         信息中心
--
--                                                         XXXX-6-20
--)))
--
--
--|**种类**|操作指导
--|**内容要求**|需要说明系统名称，发布操作指导的原因和使用场景。
--|**范例**|(((
--访问公司主页系统乱码处理办法
--
--
--近日很多用户向信息中心反映，在访问公司主页系统时会在新闻栏看到乱码，为此经过相关技术人员的研究，发现这是用户浏览器终端配置的问题，现将解决办法予以公示，当用户再次遇到类似问题时，可以按照提示自行解决，也可以选择拨打~*~*~*~*请信息中心服务台人员帮助解决。
--
--谢谢配合！
--
--
--附件：公司主页系统乱码处理办法.doc
--
--                                                         信息中心
--
--                                                             XXXX-6-20
--)))
--
--
--|**种类**|故障通告
--|**内容要求**|需要说明故障原因，影响范围，预期解决时间，当然还要表示歉意
--|**范例**|(((
--6月20日OA系统故障通告
--
--
--由于数据库系统故障，导致本日10:00开始OA系统停止服务，全公司OA用户均无法登陆OA系统，现在技术人员正在全力解决故障，预计本日15：30之前可以恢复服务。
--
--因此给您带来的不便我们表示万分抱歉！并谢谢您的配合和谅解！
--
--
--                                                         信息中心
--
--                                                             XXXX-6-20
--)))
--
--
--|**种类**|停机通告
--|**内容要求**|需要说明停机原因，影响范围，预期恢复时间，当然还要表示歉意
--|**范例**|(((
--6月22日OA系统停机通告
--
--
--为了使OA系统可以更加稳定和高效的运行，经过信息中心及OA项目组研究决定，计划在6月22日19:00到23:00进行OA系统数据库升级，期间OA系统将停止服务，请各部门用户届时提前结束OA系统上的工作，并在此期间不要尝试登录OA系统。
--
--因此给您带来的不便我们表示万分抱歉！并谢谢您的配合和谅解！
--
--
--                                                         信息中心
--
--                                                             XXXX-6-22
--)))
--
--
--
--=== **2 服务台运行管理** ===
--
--
--===== **2.1 电话接听规范** =====
--
--====== **2.1.1 接听电话应当迅速** ======
--
--1、服务台人员应在电话铃响起三声内接起,延迟应表示歉意。
--
--2、电话响起时，服务台人员不在，应由其他服务台人员接起电话，以不耽误客户为主。
--
--3、在电话铃响时，一面用左手拿起话筒，而右手马上伸到便条纸边，只要能采取这种姿势，应对的内容自然也会得体。
--
--4、如使用悬挂式耳机和相关的信息记录系统，应在接起电话后迅速打开电脑记录页面，将电话中获取到的信息记录在系统中。
--
--
--====== **2.1.2 电话用语** ======
--
--1. 使用 “您好”，“请问”，“不用客气”，“再见”等文明用语,不使用“嗨”，“唉”等不礼貌用语。
--1. 声音甜美，声调稍微高一点使客户容易听清楚，不要把不好的情绪带进电话。
--1. 报部门名称，询问客户部门等具体具体信息。
--1. 询问客户问题详细情况，仔细倾听并记录。
--1. 勿忘5W1H及电话中的传达和复诵。“5W1H”即：何时（WHEN），谁（WHO，WHOSE），何地（WHERE），何事（WHAT），如何处理（HOW）。传达时应力求简捷。为防止错误，应该在最后说：“请让我确认一下您刚才所说的话。”而复诵所记下的内容，倘若双方有传错或听错的情形，便可以在此时改过来，除此之外，如果是我们打过去的电话，而对方没有复诵时，我们也可以尽量要求对方再复诵一遍，以确认对方是否已正确的记下我们所要传达的事情。
--1. 语速不要太快，解释尽量详细，以最终解决问题为目的。
--1. 接电话时尽量不去接别的电话。
--1. 不要主动提出挂电话。
--
--
--====== **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 培训制度** =====
--
--培训是服务台服务的重要成功因素。若没有适当的初期和持续培训，服务台将不能提供最佳的客户服务。持续培训可以使服务台人员掌握所需技能。它也可以提高生产力，改善客户服务，此外还能增加服务台人员的工作满意程度，自信心。
--
--|**种类**|**机制**|**内容**|**培训者**
--|上岗培训|上岗前培训，每名服务台人员必须接受至少一次上岗培训|(((
--ITIL基础理论
--
--服务台的概况和职能
--
--运行管理规范
--
--ITSM系统软件使用
--
--一周观摩学习
--)))|(((
--服务台经理
--
--服务台资深员工
--
--专业培训人员
--)))
--|进阶培训|进阶培训的主要目的是提高服务台人员的工作效率和工作热情，内容主要是工作经验的分享和技巧的传授，不定期开展。|(((
--工作总结
--
--经验教训总结
--
--典型案例分享
--
--新技巧传授
--)))|(((
--服务台经理
--
--服务台资深员工
--)))
--|专业技能培训|由服务台经理协调二线支持团队不定期进行专业技能的培训。目的为提高服务台人员的工作能力，并提高一线解决率。|(((
--终端维护技能
--
--ITSM系统软件使用
--
--各系统常见故障处理等
--)))|二线支持团队
--|日常培训|即为传统意义上的“传帮带”|服务台日常工作熟练|服务台资深员工
--
--
--=====   =====
--
--===== **2.5 考核标准** =====
--
--以下是对服务台工作的考核标准
--
--====== **2.5.1 电话接通率和响应时间** ======
--
--|类型|指标|目标|检查周期|定义
--|接通率|<50|20|月|没有接通电话的量（主要指无人接听或非正常占线）。
--
--
--====== **2.5.2 客户满意度** ======
--
--|类型|指标|目标|检查周期|定义
--|客户满意度|85%|95%|月|(满意＋非常满意)/反馈数*100%
--
--
--====== **2.5.3 本月投诉 ** ======
--
--|类型|指标|目标|检查周期|定义
--|投诉|5%|1%|月|当月用户有效投诉数量/当月全部事件数量*100%
--
--
--====== **2.5.4 服务台解决率** ======
--
--|类型|指标|目标|检查周期|定义
--|解决率|50%|70 %|月|是否再被转到二线支持(不能在服务台得到解决)
--
--
--
--=== **3 流程运行管理规范** ===
--
--=====   =====
--
--===== **3.1 工单分派** =====
--
--====== **3.1.1 技能组设置表** ======
--
--为了支持运维流程的正常运转，有必要将信息中心所有IT支持人员进行编组，一般会按照其运维职责和技能情况进行编组。
--
--流程设计和组织人员调整时，需填写技能组列表和人员技能组对应表，所需表格格式如下：
--
--**技能组列表：**
--
--|**部门**|**技能组**|**职责**|**默认联系人**
--|(% rowspan="6" %)网络技术科|终端组|桌面终端系统维护|
--|网管组|网络管理，网络设备维护|
--|安全组|安全策略，安全设备维护|
--|系统组|机房、主机、操作系统维护|
--|数据库组|数据库维护|
--|应用组|已交付生产的应用系统维护|
--|(% rowspan="7" %)应用系统科|许可证管理系统组|许可证管理系统需求管理和研发|
--|生产系统组|生产系统需求管理和研发|
--|财务系统组|财务系统需求管理和研发|
--|OA系统组|OA系统需求管理和研发|
--|主页系统组|主页系统需求管理和研发|
--|邮件系统组|邮件系统需求管理和研发|
--|……| |
--
--
--**人员技能组对应表：**
--
--|**部门**|**职务**|**姓名**|**技能组（逗号分隔）**
--| | | |
--| | | |
--| | | |
--| | | |
--| | | |
--| | | |
--| | | |
--
--
--====== **3.1.2 分派规范** ======
--
--在ITSM系统中，技能组是工单分派的基本单元，工单将按照分类分派到与此分类有映射关系的技能组。
--
--在流程设计和组织调整时，需填写分类与技能组对应表，下表为格式参考样例：
--
--|**类别**|**子类**|**条目**|**技能组（逗号分隔，优先排序）**
--|桌面|服务|镜像恢复|终端组
--| | |硬件安装|终端组
--| | |应用软件安装|终端组
--| | |病毒处理|终端组
--| | |应用客户端版本更新|终端组，应用组
--| | |打印驱动|终端组
--| |故障|硬件故障|终端组
--| | |操作系统故障|终端组
--| | |MS Office应用故障|终端组
--| | |企业应用系统故障|终端组
--| | |网络连通性故障|终端组，网络组
--| | |打印故障|终端组
--
--
--====== **3.1.3 优先选择规范** ======
--
--当同一分类有多个技能组可选择对应时，需指定优先顺序，如：桌面类网络故障有终端组和网络组可选，应优先选择终端组，只有当终端组人员紧张或拒绝接受工单时才可以选择非优先的技能组。
--
--优先选择规范在ITSM系统中应该有具体的提示，但不具备强制性。
--
--
--====== **3.1.4 AB角规范 ** ======
--
--每个技能组内部将实行“AB角”制度，设定一名员工为“A角”即“默认联系人”，其他组内人员为“B角”，当工单派发至技能组时，A角有权利同时也有义务第一时间代表所在技能组接受指派，当A角人员处于忙碌或不可用状态时，由B角人员代替。
--
--“AB角”不是管理职位，其目的是为了流程的流畅运行，一名员工在甲技能组是“A角”，在乙技能组亦可能是“B角”。
--
--“AB角”在ITSM流程中不存在强制性，由AB角人员自行判断接单。
--
--每个员工应清楚了解自己在技能组中的角色位置，并履行权利义务。
--
--
--
--===== **3.2 工单信息填写** =====
--
--在ITSM系统中的工单是由数十个信息项（字段）构成的电子表单，这些信息项分别承载记录了工单不同的信息，在填写时，首先需要根据提示区分必填、选填、只读字段。
--
--必填字段为必须填写的字段，一般会在表单上以红色*号表示；
--
--选填字段是一般的空白字段，可以按照需要选择填写或者留空；
--
--只读字段是不允许填写或修改的字段，一般会在表单上以灰色填充表示。
--
--
--此外，按照信息项种类的不同，填写时需遵循以下规范：
--
--|序号|信息项|填写说明
--|1|人员信息项|此类信息一般为相互关联的数个字段组成，如姓名、员工编码、电话等等，填写此类信息时一般填写其中一项即可自动完成其他信息，填写时注意务求准确。
--|2|时间信息项|此类信息一般为固定格式的字段，也会有专门的日历表填写框供选择，填写此类信息需要注意的就是尽量不要手工修改字段中的日期时间格式，以免出错。另外，如果有相互关联的时间信息项，如计划开始时间和结束时间，填写时应注意不要将结束时间早于开始时间。
--|3|预定内容信息项|下拉菜单、弹出式选择框等均为此类信息项，如事件类型、来源等信息。填写此类信息需要注意的就是应尽量避免选择错误，因为这些信息大多数时候都决定了流程的流转方向。
--|4|工单分类|分类严格来说属于预定内容信息项，之所以单独提出足以说明其重要性，分类是系统区分工单流转的重要手段，填写时务必做到准确。ITSM系统的分类分为三级，选择时应按照“分类—子类—条目”的顺序逐级选择。其判断方法一般为工单发生的“所属系统主体”和“性质”
--|5|工单标题|(((
--工单的标题是快速了解工单内容的重要手段，填写的要求必须简明扼要。一般按照“时间+部门+主体+性质”的方式描述。
--
--如：
--
--事件标题“6月20日上午10点财务中心OA系统无法访问”
--
--变更标题“6月22日下午7点网络技术科OA系统数据库升级”
--)))
--|6|工单详细信息|(((
--详细信息用来对工单进行详细的说明和描述，详细信息一般为一个大容量的文本框，可以容纳足够多的信息。在填写时务必细致，准确，有条理的进行陈述。
--
--其内容应包括：
--
--发生时间、影响范围、事件症状或变更原因、期望或预计的恢复时间等等
--
--如果是变更、发布、需求等信息中心内部流转工单，其详细信息应更加专业和准确。以确保受理人可以根据描述获取所需的关键信息。必要时，还需要通过附件Word文档来进行更加详细的说明。
--)))
--
--
--
--
--===== **3.3 事件管理** =====
--
--====== **3.3.1 应用场景** ======
--
--事件管理主要功能是尽快解决出现的突发事件，保持业务系统的稳定性。
--
--下表为事件管理流程的应用场景和说明，在如下场景中，将使用事件管理流程来处理：
--
--|**序号**|**场景**|**说明**
--|1|故障处理|已提供的服务发生故障导致的服务中断或者服务质量下降
--|2|咨询服务|用户以电话或其他方式提出的信息咨询或操作指导请求
--|3|投诉处理|用户投诉的记录和处理
--|4|服务请求|某些无需填写服务申请单的服务请求允许通过事件单处理
--|5|监控告警|监控工具转发过来的告警，需要转交技术人员处理
--
--
--====== **3.3.2 各节点检查事项说明** ======
--
--检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
--
--这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
--
--
--|**检查点**|**负责人**|**检查事项**
--|服务台接单|服务台|(((
--* 请求人和地点信息
--* 报告时间和创建时间
--* 事件分类、优先级和完成期限
--* 事件标题和描述
--* 关联配置项和其他工单
--* 附件
--)))
--|二线接单|二线支持|(((
--* 请求人和地点信息
--* 报告时间和创建时间
--* 事件分类、优先级和完成期限
--* 事件标题和描述
--* 关联配置项和其他工单
--* 附件和日志
--)))
--|已解决事件|服务台|(((
--* 请求人和地点信息
--* 事件分类、优先级和完成期限
--* 事件标题和描述
--* 解决时间
--* 解决方案
--* 关联配置项和其他工单
--* 附件和日志
--)))
--|跟踪回顾|N/A|(((
--* 事件状态
--* 受理人和流转日志
--* 事件分类、优先级和完成期限
--* 主从事件标记
--* 是否超时标志
--* 实际开始和完成时间
--* 附件和日志
--)))
--
--
--====== **3.3.3 流程负责人制度** ======
--
--事件管理各角色和职责：
--
--|**角色**|**职责描述**
--|流程负责人|(((
--* 推动、推广事件管理流程，对流程的整体效果和效率负责。
--)))
--|用户|(((
--* 负责提交事件，并准备事件的描述
--)))
--|事件经理|(((
--* 负责对事件的解决协调资源，保证故障的最终排除
--* 当事件优先级为紧急或者事件将超过规定的时限，负责按照升级方法对事件进行处理确保有效协调资源，促进支持工程师快速恢复正常服务
--* 确保正确和广泛地收集和分析事件数据，发现IT和业务相关的问题
--)))
--|服务台|(((
--* 在指定的响应时间内响应所有服务台热线电话、邮件、MSN等事件报告并完整记录事件信息
--* 为事件进行适当的分类、为事件分配优先级等属性
--* 尝试初步诊断、分析相关信息等方式解决问题
--* 将事件分配给最合适的二线支持小组来处理
--* 检查事件记录的处理进度
--* 与用户确认事件解决方案，关闭事件
--)))
--|二线支持人员|(((
--* 负责对分发来的事件进行处理
--* 二线人员按照技能划分不同的小组
--)))
--
--
--工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
--
--
--|**状态**|**描述**|**责任人**
--|New（新建）|一个事件被记录或创建|创建人（服务台）
--|Assigned（已分派）|一个事件已被分派给事件记录员，事件分析员（二线）|受理人
--|Pending（等待中）|事件信息不完整，或在某些情况下阻止事件记录员或事件分析员对事件，问题分析员对问题进行处理，需要填写等待代码：|受理人
--|Work In progress（处理中）|任何一个事件分析员（二线支持）接受了事件|受理人
--|Resolved（已解决）|为一个事件找到解决方案或变通方法|创建人（服务台）
--|Closed（已关闭）|事件已经关闭|创建人（服务台）
--
--
--====== **3.3.4 考核指标** ======
--
--流程考核指标参考：
--
--|**种类**|**指标**|**计算方法**
--|(% rowspan="6" %)流程
--有效性|事件总数|(((
--数量：在事件单中根据以下条件过滤
--
--1. 【事件结束代码】不等于‘取消’
--1. 【事件发生时间】在统计周期内
--)))
--|事件关闭的数量|数量 ：在事件总数中过滤【事件状态】＝‘已关闭’
--|事件成功关闭的数量/比率|(((
--数量：在事件总数中过滤【事件结束代码】＝‘成功解决’or‘变通方法解决’ or ‘服务提供商解决”
--
--比率：数量 / 事件总数  × 100 %
--)))
--|规定时间内解决的事件数量/百分比|(((
--数量：在事件总数中过滤【处理是否超时】＝“未超时”以及【事件结束代码】＝“成功解决”或“变通方法解决”
--
--比率：数量/事件总数 × 100 %
--)))
--|超时未解决的事件数量|数量：在事件总数中过滤【处理已超时】＝“超时”以及【事件状态】！=“已解决”或“关闭”
--|规定时间内响应的事件数量/百分比|(((
--数量：在事件总数中过滤（【实际开始时间】－【登记时间】）< 优先级对应的响应时限
--
--比率：数量/事件总数 × 100 %
--)))
--|(% rowspan="3" %)执行
--效率|平均解决时间|(((
--完成的事件：在事件总数中过滤所有【事件状态】＝“已解决”或“关闭”的事件
--
--平均解决时间：累加完成事件的（【实际完成时间】－【登记时间】）/ 完成的事件数量
--)))
--|服务台解决率|(((
--数量：在事件总数中过滤所有【事件解决人角色】＝“服务台”
--
--比率：数量 / 事件总数 × 100 %
--)))
--|事件的一次解决率|(((
--数量1：在事件总数中过滤【事件结束代码】＝“成功解决”或“变通方法解决”
--
--数量2：在事件总数中过滤【事件结束代码】＝“不成功”
--
--比率：（数量1－数量2 ） / 数量1  × 100 %
--)))
--
--
--====== **3.3.5 回顾机制** ======
--
--一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
--
--流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
--
--流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
--
--流程回顾例会应包括以下内容：
--
--|**回顾任务**|**描述**|**负责人**
--|流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
--服务台/事件经理
--
--流程负责人
--)))
--|流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
--服务台/事件经理
--
--流程负责人
--)))
--|数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，某些重复事件需要升级为问题|(((
--服务台/事件经理
--
--流程负责人
--)))
--|案例分析|典型案例分析|(((
--服务台/事件经理
--
--流程负责人
--)))
--|KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
--服务台/事件经理
--
--流程负责人
--)))
--|流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果|(((
--服务台/事件经理
--
--流程负责人
--)))
--
--
--
--===== **3.4 服务请求管理** =====
--
--====== **3.4.1 应用场景** ======
--
--服务请求管理主要功能提供一个清晰的服务目录，提升IT服务的专业性，并降低沟通成本。
--
--服务请求首先是配合着服务目录来决定对外提供哪些服务的，在江苏核电的环境中，服务请求用来处理所有需要用户填写申请表单的服务申请。
--
--下表为服务请求流程的服务目录，在服务目录所列条目内的所有服务，将使用服务请求管理流程来处理，服务目录是随时更新的：
--
--|**序号**|**场景**|**说明**|**需审批**
--|(% rowspan="10" %)桌面终端|(% rowspan="5" %)硬件终端服务|办公电脑领用申请|N
--|办公电脑调拨移动申请|
--|数码配件升级更换申请|
--|办公电脑借用申请|
--|办公电脑回收申请|
--|(% rowspan="5" %)软件终端服务|镜像恢复申请|N
--|应用软件安装申请|N
--|安全和专项软件安装申请|
--|账号密码重置申请|N
--|部门计算机管理员变更申请|
--|(% rowspan="7" %)基础设施|(% rowspan="4" %)网络通讯类服务|网络访问开通申请|
--|VPN开通申请|
--|防火墙变更申请|
--|网络建设维护申请|
--|主机存储类服务|服务器空间资源申请|
--|系统软件类服务|操作系统安装申请（服务器）|
--|机房类服务|机房出入权限申请|
--|(% rowspan="7" %)业务系统|(% rowspan="2" %)OA系统服务|内部员工OA账号权限申请|N
--|外部员工临时OA账号权限申请|
--|(% rowspan="2" %)邮件系统服务|内部员工邮件账号权限申请|N
--|外部员工临时邮件账号权限申请|
--|(% rowspan="2" %)ERP系统服务|内部员工ERP系统账号权限申请|N
--|外部员工临时ERP系统账号权限申请|
--|……|……|
--|(% rowspan="2" %)通用服务|业务咨询类服务|业务培训申请|
--|数据查询类服务|数据查询申请|
--
--
--**3.4.2 各节点检查事项说明**
--
--检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
--
--这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
--
--
--|(((
--====== **检查点** ======
--)))|(((
--====== **负责人** ======
--)))|(((
--====== **检查事项** ======
--)))
--|(((
--====== 业务审批 ======
--)))|(((
--====== 业务审批人 ======
--)))|(((
--* (((
--====== 请求人和地点信息 ======
--)))
--* (((
--====== 创建时间 ======
--)))
--* (((
--====== 分类、紧急度和完成期限 ======
--)))
--* (((
--====== 标题和描述 ======
--)))
--* (((
--====== 相关自定义字段 ======
--)))
--* (((
--====== 备注和附件 ======
--)))
--)))
--|(((
--====== IT部门审批 ======
--)))|(((
--====== IT审批人 ======
--)))|(((
--* (((
--====== 请求人和地点信息 ======
--)))
--* (((
--====== 创建时间 ======
--)))
--* (((
--====== 分类、紧急度和完成期限 ======
--)))
--* (((
--====== 标题和描述 ======
--)))
--* (((
--====== 相关自定义字段 ======
--)))
--* (((
--====== 备注和附件 ======
--)))
--)))
--|(((
--====== 受理 ======
--)))|(((
--====== 受理人 ======
--)))|(((
--* (((
--====== 请求人和地点信息 ======
--)))
--* (((
--====== 创建时间 ======
--)))
--* (((
--====== 分类、紧急度和完成期限 ======
--)))
--* (((
--====== 标题和描述 ======
--)))
--* (((
--====== 相关自定义字段 ======
--)))
--* (((
--====== 备注和附件 ======
--)))
--)))
--|(((
--====== 跟踪回顾 ======
--)))|(((
--====== N/A ======
--)))|(((
--* (((
--====== 服务请求状态 ======
--)))
--* (((
--====== 审批人、受理人和流转日志 ======
--)))
--* (((
--====== 分类、紧急度和完成期限 ======
--)))
--* (((
--====== 审批代码和完成信息 ======
--)))
--* (((
--====== 是否超时标志 ======
--)))
--* (((
--====== 实际开始和完成时间 ======
--)))
--* (((
--====== 相关自定义字段 ======
--)))
--* (((
--====== 附件和日志 ======
--)))
--)))
--
--======   ======
--
--====== **3.4.3 流程负责人制度** ======
--
--服务请求管理各角色和职责：
--
--|**角色**|**职责描述**
--|服务请求人|提交服务请求单，确认最后的服务效果，关闭服务请求单
--|服务请求审批人|审批服务请求的必要性
--|服务请求经理|审批服务请求的可行性和安全性，并指派受理人
--|服务请求受理人|处理服务请求，将处理结果反馈
--
--
--工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
--
--
--|**状态**|**描述**|**责任人**
--|New（新建）|一个服务请求单被记录或创建|请求人
--|Approving （审批中）|正在审批服务请求|业务和IT审批人
--|Assigned（已分派）|已被分派给受理人|受理人
--|Pending（等待中）|信息不完整，或在某些情况下阻止受理人对服务请求进行处理，需要填写等待代码|受理人
--|Work In progress（处理中）|任何一个受理人接受了事件|受理人
--|Completed（已完成）|已经完成服务请求|请求人
--|Closed（已关闭）|已经关闭|请求人
--
--
--====== **3.4.4 考核指标** ======
--
--流程考核指标参考：
--
--|**种类**|**指标**|**计算方法**
--|(% rowspan="6" %)流程
--有效性|服务请求总数|(((
--数量：在服务请求单中根据以下条件过滤
--
--1. 【服务请求结束代码】不等于‘取消’
--1. 【服务请求发生时间】在统计周期内
--)))
--|服务请求关闭的数量|数量 ：在服务请求总数中过滤【服务请求状态】＝‘已关闭’
--|服务请求成功关闭的数量/比率|(((
--数量：在服务请求总数中过滤【服务请求结束代码】＝处理成功
--
--比率：数量 / 服务请求总数  × 100 %
--)))
--|规定时间内解决的服务请求数量/百分比|(((
--数量：在服务请求总数中过滤【处理是否超时】＝“未超时”以及【服务请求结束代码】＝处理成功
--
--比率：数量/服务请求总数 × 100 %
--)))
--|超时未解决的服务请求数量|数量：在服务请求总数中过滤【处理已超时】＝“超时”以及【服务请求状态】！=“处理成功”或“关闭”
--|规定时间内响应的服务请求数量/百分比|(((
--数量：在服务请求总数中过滤（【实际开始时间】－【登记时间】）< 优先级对应的响应时限
--
--比率：数量/服务请求总数 × 100 %
--)))
--|(% rowspan="3" %)执行
--效率|平均解决时间|完成的服务请求：在服务请求总数中过滤所有【服务请求状态】＝“处理成功”或“关闭”的服务请求平均解决时间：累加完成服务请求的（【实际完成时间】－【登记时间】）/ 完成的服务请求数量
--|解决率|(((
--数量：在服务请求总数中过滤所有【服务请求解决人角色】＝“技能组名称”
--
--比率：数量 / 服务请求总数 × 100 %
--)))
--|服务请求的一次解决率|(((
--数量1：在服务请求总数中过滤【服务请求结束代码】＝“处理成功”
--
--数量2：在服务请求总数中过滤【服务请求结束代码】＝“不成功”
--
--比率：（数量1－数量2 ） / 数量1  × 100 %
--)))
--
--
--====== **3.4.5 回顾机制** ======
--
--一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
--
--流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
--
--流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
--
--流程回顾例会应包括以下内容：
--
--|**回顾任务**|**描述**|**负责人**
--|流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
--服务请求经理
--
--流程负责人
--)))
--|流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
--服务请求经理
--
--流程负责人
--)))
--|数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，某些重复性较高的服务请求是否可以省去审批过程|(((
--服务请求经理
--
--流程负责人
--)))
--|案例分析|典型案例分析|(((
--服务请求经理
--
--流程负责人
--)))
--|KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
--服务请求经理
--
--流程负责人
--)))
--|流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
--服务请求经理
--
--流程负责人
--)))
--
--
--
--===== **3.5 问题管理** =====
--
--====== **3.5.1 应用场景** ======
--
--问题管理流程的根本目的是消除或减少生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的IT环境，提高IT服务的可用性。
--
--对于问题管理而言，问题的产生主要来自于四个方面：
--
--|**序号**|**场景**|**说明**
--|1|紧急事件触发|(((
--紧急事件恢复服务后关联提出的问题，以便进行紧急事件的根本原因分析
--
--【例如】：某日发生了一起集群无法切换的事件，导致某台主机发生故障后，没有切换到备用主机中去，从而影响了业务，紧急事件的处理人员在采取了手工切换的替代措施后，恢复了服务为了分析为什么会发生该紧急事件，以及查看其他的集群是否也存在类似的问题，此时可以提出一个问题记录，以便对该紧急事件进行分析
--)))
--|2|系统维护中提出的问题|(((
--二线支持在日常维护工作中提出的问题
--
--【例如】：维护专家在日常维护中发现，目前的数据库版本可能会存在着死锁、心跳不一致等方面的问题，此时就可以提出一个问题记录，以便分析
--)))
--|3|事件趋势分析|(((
--分析事件记录找出的问题
--
--【例如】：在定期的会议中，对某应用系统操作咨询类的事件进行分析后发现，上一阶段该类型的事件比平常的时候多了30％，超过了规定的阀值，这表明该应用系统操作有可能存在着一些潜在的隐患，此时就可以提出一个问题记录，以找出问题的原因并解决
--)))
--|4|失败变更产生问题|变更失败后，可能需要生成一个问题进入后续的解决过程
--
--
--====== **3.5.2 各节点检查事项说明** ======
--
--检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
--
--这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
--
--
--|**检查点**|**负责人**|**检查事项**
--|问题确认、分类分派|问题经理|(((
--* 请求人和地点信息
--* 创建时间
--* 问题分类、优先级
--* 问题来源
--* 问题标题和描述
--* 关联配置项和其他工单
--* 附件
--)))
--|问题调查诊断和处理|问题分析员|(((
--* 请求人和地点信息
--* 问题分类、优先级
--* 问题来源
--* 问题原因
--* 问题标题和描述
--* 重复问题标记
--* 关联配置项和其他工单
--* 问题日志
--* 备注项和附件
--)))
--|问题验证|问题经理|(((
--* 问题分类、优先级
--* 问题来源
--* 问题原因
--* 问题标题和描述
--* 关联配置项和其他工单
--* 解决方案
--* 问题日志
--* 备注项和附件
--)))
--|跟踪回顾|N/A|(((
--* 问题状态
--* 受理人和流转日志
--* 分类、优先级
--* 问题来源和解决方案
--* 是否超时标志
--* 实际开始和完成时间
--* 日志
--* 备注项和附件
--)))
--
--
--====== **3.5.3 流程负责人制度** ======
--
--问题管理各角色和职责：
--
--|**角色**|**职责描述**
--|流程负责人|(((
--* 推动、推广问题管理流程，对流程的整体效果和效率负责。
--)))
--|问题分析员|(((
--* 接受问题经理分派过来的问题
--* 分析和诊断问题，确定根本原因
--* 确定和测试解决方案
--* 提交变更请求并监控变更实施
--* 协助事件支持人员进行重大或紧急事件的处理
--* 需要时协调第三方的资源来帮助诊断和改正问题
--)))
--|问题经理|(((
--* 领导问题管理小组，确保大家的积极性、技能水平
--* 定期组织相关人员对事件记录进行分析，发现潜在问题
--* 确认和审核问题
--* 必要时对问题进行上报
--* 监视问题的诊断、分析和处理过程
--* 必要时与帮助台及问题请求者沟通问题的相关信息
--* 必要时协调所需资源
--* 定期制定问题报表，提供正确决策信息
--)))
--
--
--工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
--
--
--|**状态**|**描述**|**责任人**
--|New（新建）|一个问题被记录或创建|问题分析员
--|Assigned （已分配）|一个问题已被分派给问题分析员或问题经理 |问题分析员/问题经理
--|Pending （等待中）|问题信息不完整，或在某些情况下阻止问题分析员对问题进行处理，进入等待|问题分析员
--|Work in Progress （处理中）|一个问题分析员接受了问题，并正在处理 |问题分析员
--|Resolved （已解决）|为一个问题找到解决方案或变通方法 |问题经理
--|Closed （已关闭）|问题已经关闭|问题经理
--
--
--====== **3.5.4 考核指标** ======
--
--流程考核指标参考：
--
--|**种类**|**指标**|**计算方法**
--|(% rowspan="5" %)流程
--有效性|问题总数|(((
--数量：在问题单中根据以下条件过滤
--
--~1. 【重复问题标记】为空
--
--2. 【问题结束代码】不等于“取消”
--
--3. 【登记时间】在统计周期内
--)))
--|已找到根本原因的问题数量|数量：在问题总数中，【问题状态】=“已定位原因”的问题数量
--|趋势分析问题所占比率|(((
--数量：在问题总数中，【问题来源】=“趋势分析”的问题数量
--
--比率：数量 / 问题总数  × 100 %
--)))
--|关闭问题数量|数量：【问题关闭时间】在统计周期内，【问题状态】=“结束并关闭”的问题数量
--|通过变通办法解决的问题数量|数量：在关闭问题数量中，【问题结束代码】=“变通方法”的问题数量
--|(% rowspan="2" %)执行
--效率|问题成功解决率|(((
--数量：在关闭问题数量中，【问题结束代码】=“根本解决”的问题个数
--
--比率：数量 /关闭问题数量  × 100 %
--)))
--|平均诊断时间|(((
--诊断完成问题数量：【实际诊断结束时间】在统计周期内的问题个数
--
--平均诊断时间：累加诊断完成问题的（【实际诊断结束时间】－【实际诊断开始时间】）/ 诊断完成问题数量
--)))
--
--
--====== **3.5.5 回顾机制** ======
--
--一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
--
--流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
--
--流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
--
--流程回顾例会应包括以下内容：
--
--|**回顾任务**|**描述**|**负责人**
--|流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
--问题经理
--
--流程负责人
--)))
--|流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
--问题经理
--
--流程负责人
--)))
--|数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，找到根源的问题等|(((
--问题经理
--
--流程负责人
--)))
--|案例分析|典型案例分析|(((
--问题经理
--
--问题分析员
--
--流程负责人
--)))
--|KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
--问题经理
--
--流程负责人
--)))
--|流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
--问题经理
--
--流程负责人
--)))
--
--
--
--===== **3.6 变更管理** =====
--
--====== **3.6.1 应用场景** ======
--
--变更管理流程的根本目的是通过严格的控制将变更操作对生产环境产生的影响降到最小。
--
--根据变更对象的不同，变更场景可以区分为两种：
--
--|**序号**|**场景**|**说明**
--|1|基础设施变更|变更的主要组成部分，也是变更的主要意义所在，指的是对准生产和生产环境的基础设施（主机、网络、应用系统等）进行诸如安装、升级、维护、撤销等需要改变其固有属性的操作，一般来说此类操作时需要终止服务。
--|2|配置更新变更|此类变更是有ITSM系统配置管理流程所引发，主要指的是对系统中CMDB的CI信息变更。
--
--
--====== **3.6.2 各节点检查事项说明** ======
--
--检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
--
--这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
--
--
--|**检查点**|**负责人**|**检查事项**
--|评估构建|变更受理者|(((
--* 请求人和地点信息
--* 创建时间
--* 变更来源和变更类型
--* 变更所影响的部门和应用
--* 变更分类、优先级
--* 回退计划和测试计划
--* 变更标题和描述
--* 关联配置项和其他工单
--* 附件
--)))
--|审批|(((
--变更经理
--
--变更审批者
--)))|(((
--* 请求人和地点信息
--* 创建时间
--* 变更来源和变更类型
--* 变更所影响的部门和应用
--* 变更分类、优先级
--* 变更计划开始和完成时间
--* 变更标题和描述
--* 关联配置项和其他工单
--* 附件
--)))
--|实施验证|(((
--变更受理者
--
--变更实施者
--)))|(((
--* 变更来源和变更类型
--* 变更分类、优先级
--* 回退计划和测试计划
--* 变更标题和描述
--* 关联配置项和其他工单
--* 变更计划开始和完成时间
--* 工作日志
--* 附件
--)))
--|回顾关闭|变更经理|(((
--* 变更来源和变更类型
--* 变更分类、优先级
--* 变更标题和描述
--* 关联配置项和其他工单
--* 变更计划开始和完成时间
--* 变更实际开始和完成时间
--* 工作日志
--* 关闭代码
--* 附件
--)))
--|跟踪回顾|N/A|(((
--* 变更状态
--* 变更经理、受理人和流转系统日志
--* 变更分类、优先级
--* 变更来源和变更类型
--* 是否超时标志
--* 实际开始和完成时间
--* 工作日志
--* 关闭和等待代码
--* 备注项和附件
--)))
--
--
--====== **3.6.3 流程负责人制度** ======
--
--变更管理各角色和职责：
--
--|**角色**|**职责描述**
--|流程负责人|(((
--* 对整个流程的效率和结果负责
--* 发布衡量标准和目标，以提高流程的有效性和效率
--* 鉴别和管理关键的成功因素
--* 控制并领导流程改进活动
--* 批准或拒绝背离流程的事例
--* 定义变更管理团队的角色、职责和义务
--* 强化贯彻执行变更管理流程
--* 向同级的其他流程负责人以及管理层汇报流程的状态
--* 解决跨部门的问题
--* 审核、抽查变更管理流程的执行情况
--* 对变更管理流程中投入的成本和投资负责
--* 在组织内沟通新发布的和修改过的政策
--* 作为变更管理流程的代表，与其他外部部门沟通
--)))
--|变更请求者|(((
--* 接收和记录变更请求、分配变更请求的优先级，或者与变更的发起人员协作，记录变更请求。拒绝任何不切实际的变更请求
--* 如果采用工具，更新变更请求单
--* 确保RFC具有充分、准确的信息
--* 确保及时地沟通变更处理的情况
--* 初步评价变更的风险/影响，给变更请求设定适当的影响度
--* 协助变更经理或者变更受理者解决变更请求信息不完整、不一致之处
--* 回应变更审批人员提出的有关问题
--* 确保关于所提交的变更请求的所有疑问都得到适当的解答
--)))
--|变更受理者|(((
--* 变更受理者主要在技术方案上负责，把关变更计划中技术方面的问题
--* 负责构建变更并制定实施时间计划
--* 在验证测试环境中负责测试变更
--* 准备回退计划，以便在变更实施不成功时进行回退
--* 创建实施计划
--* 必要时更新操作手册或运行操作规程
--* 实施完毕进行回顾，判断是否由于变更的实施从而产生外部影响或新的需求
--* 检查实施完毕的变更，确保达到了预期的目标
--* 将不成功的变更通知变更经理，如果变更过程发生了未经计划的停机，必须进行解释
--* 协调变更中的有关事项
--* 关联所有与变更相关的配置项
--)))
--|变更经理|(((
--* 负责技术人员的协调沟通，在涉及多个部门的变更中，变更经理负责组织技术方案讨论会议，审核最终变更计划，并将初审通过的变更计划发给变更审批者进行进一步的审批
--* 分析已关闭的变更请求，判断其趋势，或找出明显的问题，并找到相关的科室、部门进行纠正
--* 定期产生变更管理的报表
--* 判断变更管理的会议应由哪些人员参与，根据审批人员的专业领域，确定各种类型的RFC应当由哪些人员评估
--* 根据变更日程，协助变更受理者联络、协调相关人员/部门，合作参与变更的构建、测试和实施
--* 负责确保变更管理流程的日常顺利运行
--* 判断例外及背离流程的情况，并进行管理
--* 监控变更管理流程的有效性和效率，提出改进流程的建议
--* 必要时与用户协商关于变更实施时需要停止服务的时间
--* 综合考虑变更的日程，解决日程之间的冲突
--* 确保以及时、适当的方式对变更进行沟通
--* 更新变更请求的状态并关闭变更请求
--* 更新RFC的状态并关闭RFC
--)))
--|变更审批者|(((
--* 确保所有标准审批流程的变更请求都经过评估
--* 对变更进行评估（从业务、技术、日程、实施角度全面评估），以确定变更实施与否所造成的影响
--* 任何问题或利害关系，都应当与变更经理、变更请求者以及事先指定的其他审批者进行及时沟通
--* 当审批者自身无法参与评估和审批时，应向变更经理推荐一位代替自己的人选
--* 考虑实施变更的日期，如：是否应当在周末、季度末执行变更等
--)))
--|CAB/EC|(((
--* 针对具体变更请求，评估潜在影响和风险，并分派相应资源
--* 指导变更经理对变更做出审批、决策
--* 参加CAB会议和紧急CAB会议
--* 对流程改进提出意见和建议
--)))
--|变更实施者|(((
--* 确保按时实施变更
--* 按照指导方针执行回退计划
--* 尽量解决在实施过程中出现的问题
--* 如果变更实施失败，执行回退方案
--* 必要时更新操作手册或运行操作规程
--* 如果变更实施失败，需要创建相应的变更事件故障单
--* 更新变更记录单状态
--* 通知操作人员/服务台关于变更处理的状态
--* 按要求执行回退方案，将生产环境（硬件/软件）恢复到变更前状态
--)))
--
--
--**此处需要强调的是CAB/EC的人员构成：**
--
--CAB（变更顾问委员会）是由信息中心的管理人员组成的虚拟小组，主要由各相关部门的领导、各个服务负责部门的资深人员或者技术骨干组成，有时也会包括发起变更请求的业务部门的代表、第三方厂商集成商等参与。CAB应当由该专业有较高技能的人员组成，同时，这些成员对于业务需求、业务逻辑、IT系统技术、应用开发、测试、支持等方面也较为熟悉。
--
--EC（紧急变更委员会）通常可以属于CAB的一个子集
--
--CAB/EC由于成员不定，所以应该有一个最小集，我们建议的CAB/EC的最小集应包括：
--
--1. 主管信息领导
--1. 信息部门负责人
--1. 变更经理
--1. 变更受理人
--
--
--工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
--
--
--|**状态**|**状态(英文)**|**描述**|**责任人**
--|新建|New|变更申请表正在填写之中|请求人
--|已分派|Assigned|变更请求已分派给变更受理者进行初始的计划、准备工作|变更受理者
--|计划中|Planning|变更受理者正在准备变更的计划|变更受理者
--|审批中|Approving|变更经理正在审阅变更的计划|变更经理
--|已审批|Approved|变更审批者已经完成了变更的审批|变更实施者
--|实施中|Working In Progress|变更正在处理中|变更实施者
--|已实施|Implemented|变更实施结束，并且返回结果|(((
--变更受理者
--
--变更经理
--)))
--|已关闭|Closed|变更完成|变更经理
--
--
--1.
--11.
--111. **考核指标**
--
--流程考核指标参考：
--
--|**种类**|**指标**|**计算方法**
--|(% rowspan="6" %)流程
--有效性|每一变更类型的变更数量|数量：每一变更类型的【登记时间】在统计时间区间内的变更数量
--|每一变更分类的变更数量|数量：每一变更分类的【登记时间】在统计时间区间内的变更数量
--|每一风险等级的变更数量|数量：每一风险等级的【登记时间】在统计时间区间内的变更数量
--|变更实施失败的数量和比率|数量：【变更结束代码】=“失败”and 【关闭时间】在统计时间区间内的变更数量
--|变更实施成功的数量和比率|数量：【变更结束代码】=“成功”and 【关闭时间】在统计时间区间内的变更数量
--|被取消的变更数量和比率|数量：【变更结束代码】=“已取消”and 【关闭时间】在统计时间区间内的变更数量
--|执行
--效率|业务中断时长|业务中断时长：【变更状态】=“已完成”and 【实际完成时间】在统计时间区间内的【中断时长】，按【中断关键业务名称】分别对应到业务系统的子类，进行分类统计
--
--
--====== **3.6.4 回顾机制** ======
--
--一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
--
--流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
--
--流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
--
--流程回顾例会应包括以下内容：
--
--|**回顾任务**|**描述**|**负责人**
--|流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
--变更经理
--
--流程负责人
--)))
--|流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
--变更经理
--
--流程负责人
--)))
--|数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，失败变更等|(((
--变更经理
--
--流程负责人
--)))
--|案例分析|典型案例分析|(((
--变更经理
--
--变更受理者
--
--流程负责人
--)))
--|KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
--变更经理
--
--流程负责人
--)))
--|流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
--变更经理
--
--流程负责人
--)))
--
--
--===== **3.7 发布管理** =====
--
--====== **3.7.1 应用场景** ======
--
--发布管理流程通过规范操作流程，平稳地对生产系统进行变更，从而化解和控制变更可能产生的风险，满足业务发展的需要。
--
--发布管理的应用范围与变更相同，但发布管理的规模和关注点与变更不同。
--
--[[image:file:///C:\Users\Admmini\AppData\Local\Temp\ksohtml16320\wps7.jpg]][[image:图片1.png]]
--
--一个发布要求实现一个整体目标，发布会关联出一系列变更来进行具体实施，并对这一系列变更进行总体的协调和控制以保证发布的质量
--
--
--
--====== **3.7.2 各节点检查事项说明** ======
--
--检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
--
--这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
--
--
--|**检查点**|**负责人**|**检查事项**
--|评估|发布受理者|(((
--* 请求人和地点信息
--* 创建时间
--* 发布来源和发布类型
--* 发布所影响的部门和应用
--* 发布分类、优先级
--* 发布标题和描述
--* 备注和附件
--)))
--|审批|发布经理|(((
--* 请求人和地点信息
--* 创建时间
--* 发布来源和发布类型
--* 发布所影响的部门和应用
--* 发布分类、优先级
--* 发布标题和描述
--* 备注和附件
--)))
--|实施|发布实施者|(((
--* 请求人和地点信息
--* 创建时间
--* 发布来源和发布类型
--* 发布所影响的部门和应用
--* 发布分类、优先级
--* 发布标题和描述
--* 计划开始和完成时间
--* 工作日志
--* 备注和附件
--)))
--|验证|发布受理者|(((
--* 发布来源和发布类型
--* 发布分类、优先级
--* 发布标题和描述
--* 关联变更情况
--* 发布计划开始和完成时间
--* 发布实际开始和完成时间
--* 工作日志
--* 关闭代码
--* 备注和附件
--)))
--|跟踪回顾|N/A|(((
--* 发布状态
--* 发布经理、受理人和流转系统日志
--* 发布分类、优先级
--* 发布来源和发布类型
--* 是否超时标志
--* 关联变更情况
--* 实际开始和完成时间
--* 工作日志
--* 关闭和等待代码
--* 备注项和附件
--)))
--
--
--====== **3.7.3 流程负责人制度** ======
--
--发布管理各角色和职责与变更相同。
--
--工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
--
--
--|**状态**|**状态(英文)**|**描述**|**责任人**
--|新建|New|发布申请表正在填写之中|请求人
--|已分派|Assigned|发布请求已分派给发布受理者进行初始的计划、准备工作|发布受理者
--|计划中|Planning|发布受理者正在准备变更的计划|发布受理者
--|审批中|Approving|发布经理正在审阅发布的计划|发布经理
--|实施中|Working In Progress|发布正在处理中|发布实施者
--|已实施|Implemented|发布实施结束，并且返回结果|发布受理者
--|已关闭|Closed|发布完成|发布经理
--
--
--====== **3.7.4 考核指标** ======
--
--流程考核指标参考，发布管理通过分解的变更具体实现，所以发布管理的衡量指标与变更管理一致：
--
--|**种类**|**指标**|**计算方法**
--|(% rowspan="6" %)流程
--有效性|每一发布类型的发布数量|数量：每一发布类型的【登记时间】在统计时间区间内的发布数量
--|每一发布分类的发布数量|数量：每一发布分类的【登记时间】在统计时间区间内的发布数量
--|每一风险等级的发布数量|数量：每一风险等级的【登记时间】在统计时间区间内的发布数量
--|发布实施失败的数量和比率|数量：【发布结束代码】=“失败”and 【关闭时间】在统计时间区间内的发布数量
--|发布实施成功的数量和比率|数量：【发布结束代码】=“成功”and 【关闭时间】在统计时间区间内的发布数量
--|被取消的发布数量和比率|数量：【发布结束代码】=“已取消”and 【关闭时间】在统计时间区间内的发布数量
--|执行
--效率|业务中断时长|业务中断时长：【发布状态】=“已完成”and 【实际完成时间】在统计时间区间内的【中断时长】，按【中断关键业务名称】分别对应到业务系统的子类，进行分类统计
--
--
--====== **3.7.5 回顾机制** ======
--
--一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
--
--流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
--
--流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
--
--流程回顾例会应包括以下内容：
--
--|**回顾任务**|**描述**|**负责人**
--|流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
--发布经理
--
--流程负责人
--)))
--|流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
--发布经理
--
--流程负责人
--)))
--|数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，失败发布等|(((
--发布经理
--
--流程负责人
--)))
--|案例分析|典型案例分析|(((
--发布经理
--
--发布受理者
--
--流程负责人
--)))
--|KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
--发布经理
--
--流程负责人
--)))
--|流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
--发布经理
--
--流程负责人
--)))
--
--
--变更和发布的回顾例会建议应该在一起进行。
--
--
--
--===== **3.8 配置和资产管理** =====
--
--====== **3.8.1 应用场景** ======
--
--配置管理是一个持续性的过程，包括计划、记录和管理数据，它管理数据中心运行环境有关的组件。该流程为IT组织提供提供所管理的IT组件的情况，包括组件之间互相的关系和状况。
--
--配置管理的目标是记录和维护IT架构中相关组件的准确信息（避免防止人为的误操作造成服务的不可用或服务质量的下降） ,包括组件之间的关系，为其他服务支持和服务供应流程提供信息。
--
--IT资产管理是一个管理的过程，对于资产的生命周期进行记录与控制。该流程为IT组织提供所管理的IT物理资产在生命周期所产生的财务管理目标的基础数据。
--
--IT资产管理的目标是记录和维护IT信息管理与IT相关的物理资产的生命周期与财务信息。IT资产管理相对于IT服务管理独立，只共用配置管理数据库。
--
--IT资产管理和配置管理都是基于同一个配置管理数据库的，但资产管理与配置管理是用两种不同的视角去来衡量同一个事物。
--
--
--[[image:图片2.png]]
--
--
--各种不同类别的CI从“入库接收~-~-上线工作~-~-报废处置”的整个生命周期内，资产管理和配置管理各自涵盖的范围。
--
--|**CI类别**|**资产管理**|**配置管理**
--|桌面终端|全生命周期|无
--|系统硬件|全生命周期|上线工作期间
--|系统软件|全生命周期|上线工作期间
--|业务平台|全生命周期|上线工作期间
--|逻辑实体|无|上线工作期间
--|配件部件|全生命周期|上线工作期间
--
--
--====== **3.8.2 各节点检查事项说明** ======
--
--检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
--
--这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
--
--
--|**检查点**|**负责人**|**检查事项**
--|资产接收|资产管理员|(((
--* 采购单号
--* 接收类型和结果
--* 供货商、供货批次、合同号
--* 检验人和检验信息
--)))
--|资产发放|资产管理员|(((
--* 使用人和使用部门
--* 发放原因
--* 发放地点
--* 领用人（经办人）
--* 发放记录和日期
--* 备注
--)))
--|资产处置|资产管理员|(((
--* 申请人和经办人
--* 处置原因
--* 处置方案
--* 处置时间
--* 审批状态
--* 备注
--)))
--|配置审核|配置管理员|(((
--* 配置项编号
--* 配置项所有者
--* 配置项状态（与实际情况做对比）
--* 配置项通用属性和专有属性（与实际情况做对比）
--* 配置项地点（与实际情况做对比）
--* 最近审核时间
--)))
--|配置更新|配置管理员|(((
--* 配置项所有者
--* 配置项状态
--* 配置项通用属性和专有属性
--* 配置项地点
--* 最近审核时间
--* 最近更新时间
--)))
--
--
--====== **3.8.3 流程负责人制度** ======
--
--各角色和职责：
--
--|**角色**|**职责描述**
--|IT资产经理|对IT资产流程进行管理，对于IT资产管理员进行直接任命。
--|IT资产管理员|负责IT资产管理数据的一致性和准确性，确保为其他操作管理提供的数据是准确的。
--|IT采购专员|负责跟踪合同与采购单，与第三方供应商进行协调。
--|IT资产审批人|负责对资产采购申请进行审批
--|配置经理|协调配置管理的日常操作活动，负责整个流程执行的质量。也是与其他流程经理的交流界面。
--|配置管理员|负责配置管理数据的一致性和准确性，确保为其他操作管理提供的数据是准确的；执行审核计划。
--|综合/系统管理员|负责第三方厂商、文档等信息的维护。
--|流程负责人|负责整个运维流程的制订和监督流程质量
--
--
--====== **3.8.4 考核指标** ======
--
--流程考核指标参考：
--
--|**种类**|**指标**|**计算方法**
--|(% rowspan="7" %)资产管理|采购成本|企业采购硬件所花费的总金额+企业采购软件所花费的总金额
--|部署和维护成本|资产维护中新购配件的金额+资产维护中使用付费服务的金额
--|报废成本|报废所花费的成本-所获得的金额-通过资产报废使税收节约增加的数额
--|总成本|采购成本+部署和维护成本+报废成本
--|硬件利用率|(((
--数量1.企业拥有的硬件的总数量
--
--数量2.状态为在使用的硬件的数量
--
--比率.数量2/数量1*100%
--)))
--|软件利用率|(((
--数量1. 总共购买的软件许可证的总数
--
--数量2. 目前已经使用的软件许可证的数量
--
--比率.数量2/数量1*100%
--)))
--|使用不当设备损坏率|(((
--数量1.使用不当导致设备发生故障的数量
--
--数量2.此类设备总数量
--
--比率.数量1/数量2*100%
--)))
--|(% rowspan="7" %)配置管理|周期性审核中与物理环境一致的CI数量（已审核数量）及比例|(((
--已审核数量：【删除状态】=‘正常‘and【审核状态】=‘已审核‘的CI数量
--
--比例：已审核数量/【删除状态】=‘正常‘的CI数量
--
--按照CI层次进行分组统计
--)))
--|周期性审核中与物理环境不一致的CI数量（不匹配数量）及比例|(((
--不匹配数量：【删除状态】=‘正常‘and【审核状态】=‘不匹配‘的CI数量
--
--比例：不匹配数量/【删除状态】=‘正常‘的CI数量
--
--按照CI层次进行分组统计
--)))
--|周期性审核中与发现物理环境中不存在的CI数量（丢失数量）及比例|(((
--丢失数量：【删除状态】=‘正常‘and【审核状态】=‘丢失‘的CI数量
--
--比例：丢失数量/【删除状态】=‘正常‘的CI数量
--
--按照CI层次进行分组统计
--)))
--|某时间周期内新增加的CI数量（新增数量）|(((
--新增数量：【删除状态】=‘正常‘and【 创建时间】在统计时间区间内的CI数量;
--
--按照CI层次进行分组统计
--)))
--|某时间周期内删除的CI数量（删除数量）|(((
--删除数量：【删除状态】=‘已删除‘and【删除时间】在统计时间区间内的CI数量;
--
--按照CI层次进行分组统计
--)))
--|某时间周期内CI服务可用时长比率|
--|某时间周期内CI出现故障数量|
--
--
--====== **3.8.5 回顾机制** ======
--
--一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
--
--流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
--
--流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
--
--流程回顾例会应包括以下内容：
--
--|**回顾任务**|**描述**|**负责人**
--|流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
--变更经理
--
--流程负责人
--)))
--|流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
--变更经理
--
--流程负责人
--)))
--|数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，失败变更等|(((
--变更经理
--
--流程负责人
--)))
--|案例分析|典型案例分析|(((
--变更经理
--
--变更受理者
--
--流程负责人
--)))
--|KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
--变更经理
--
--流程负责人
--)))
--|流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
--变更经理
--
--流程负责人
--)))
--
--
--配置和资产的管理回顾例会不必要频率过高，推荐季度例会，配置和资产例会可以选择分别召开。
--
--
--
--
--===== **3.9 需求管理** =====
--
--====== **3.9.1 应用场景** ======
--
--需求管理主要功能提供一个用户提出对应用系统修改意见的通道，提升IT服务的专业性，并降低沟通成本。
--
--需求管理的应用较为专业，只针对于业务部门汇报生产环境或准生产环境下的应用系统BUG或功能修改意见，提交于应用开发团队。
--
--
--====== **3.9.2 各节点检查事项说明** ======
--
--检查事项说明是流程在每个节点上时，当前节点负责人对工单信息填写情况执行必要检查的一个参考。
--
--这些检查事项并不是包括了工单的全部信息，它只是说明，在某一节点上，某些信息相对而言应该优先被关注。
--
--
--|**检查点**|**负责人**|**检查事项**
--|业务审批|业务审批人|(((
--* 请求人和地点信息
--* 创建时间
--* 分类、紧急度和紧急度说明
--* 标题和描述
--* 备注和附件
--)))
--|IT评估审批|(((
--需求受理人
--
--需求经理
--)))|(((
--* 请求人和地点信息
--* 创建时间
--* 分类、紧急度和紧急度说明
--* 标题和描述
--* 备注和附件
--)))
--|处理需求|(((
--需求受理人
--
--需求实施人
--)))|(((
--* 请求人和地点信息
--* 创建时间
--* 分类、紧急度和紧急度说明
--* 标题和描述
--* 工作日志
--* 备注和附件
--)))
--|验证关闭|需求受理人|(((
--* 请求人和地点信息
--* 创建时间
--* 分类、紧急度和紧急度说明
--* 标题和描述
--* 完成信息
--* 未通过/等待/关闭代码
--* 工作日志
--* 备注和附件
--)))
--|跟踪回顾|N/A|(((
--* 需求状态
--* 审批人、受理人和流转日志
--* 分类、紧急度和紧急度说明
--* 审批代码和完成信息
--* 是否超时标志
--* 实际开始和完成时间
--* 工作日志
--* 备注和附件
--)))
--
--
--====== **3.9.3 流程负责人制度** ======
--
--需求管理各角色和职责：
--
--|**角色**|**职责描述**
--|用户|记录需求信息，负责与用户沟通
--|需求审批者(业务部门）|从业务的角度，负责决定是否提交该需求
--|需求审批者(IT部门)|对需求进行最终审批
--|需求受理者|负责需求的分析和处理
--|需求实施者|负责需求最终的实施开发工作
--|需求经理|初审需求，协调需求处理过程中的相关工作
--|流程负责人|推动、推广需求管理流程，对流程的整体效果和效率负责。
--
--
--工单在每个状态时均有不同的负责人，对当前工单的处理负责，以有利于跟踪和追溯。下表记录了在不同状态时的默认责任人。
--
--
--|**状态**|**描述**|**责任人**
--|新建|客户提交一个新的需求申请|需求提交人
--|业务审批|提交业务部门领导进行审批|业务审批人
--|已分派|需求申请单根据需求分类被分派到相应的需求受理者|需求受理人
--|分析中|由需求受理人进行需求分析|需求受理人
--|待审批|需求申请单等待需求经理和需求审批人审批|需求经理
--|处理中|对需求进行开发实施|需求受理人
--|暂缓|需求暂缓处理|需求受理人
--|测试中|需求进行用户测试|需求受理人
--|上线中|需求等待变更和发布进行上线|需求受理人
--|已关闭|需求申请单关闭|需求经理
--
--
--====== **3.9.4 考核指标** ======
--
--流程考核指标参考：
--
--|**种类**|**指标**|**计算方法**
--|(% rowspan="6" %)流程
--有效性|需求总数|(((
--数量：在需求单中根据以下条件过滤
--
--1. 【需求结束代码】不等于‘取消’
--1. 【需求发生时间】在统计周期内
--)))
--|需求关闭的数量|数量 ：在需求总数中过滤【需求状态】＝‘已关闭’
--|需求成功关闭的数量/比率|(((
--数量：在需求总数中过滤【需求结束代码】＝处理成功
--
--比率：数量 / 需求总数  × 100 %
--)))
--|规定时间内解决的需求数量/百分比|(((
--数量：在需求总数中过滤【处理是否超时】＝“未超时”以及【需求结束代码】＝处理成功
--
--比率：数量/需求总数 × 100 %
--)))
--|超时未解决的需求数量|数量：在需求总数中过滤【处理已超时】＝“超时”以及【需求状态】！=“处理成功”或“关闭”
--|规定时间响应的需求数量/百分比|(((
--数量：在需求总数中过滤（【实际开始时间】－【登记时间】）< 对应的响应时限
--
--比率：数量/需求总数 × 100 %
--)))
--|(% rowspan="3" %)执行
--效率|平均解决时间|(((
--完成的需求：在需求总数中过滤所有【需求状态】＝“处理成功”或“关闭”的需求
--
--平均解决时间：累加完成需求的（【实际完成时间】－【登记时间】）/ 完成的需求数量
--)))
--|解决率|(((
--数量：在需求总数中过滤所有【需求解决人角色】＝“技能组名称”
--
--比率：数量 / 需求总数 × 100 %
--)))
--|需求的一次解决率|(((
--数量1：在需求总数中过滤【需求结束代码】＝“处理成功”
--
--数量2：在需求总数中过滤【需求结束代码】＝“不成功”
--
--比率：（数量1－数量2 ） / 数量1  × 100 %
--)))
--
--
--====== **3.9.5 回顾机制** ======
--
--一个好的管理流程必然是一个可以自我进化的管理流程，流程自我管理除了需要有意义的KPI之外，还需要一套行之有效的回顾机制，在回顾中找到不足并予以改正，不断优化。
--
--流程回顾一般会采用报表和会议相结合的机制，即通过报表系统收集有效的流程运行情况统计，然后以这些数据为基础召开流程回顾的例会，总结经验教训并修正不合适的KPI指标。
--
--流程回顾例会应根据需要选择以周例会、月例会、季度例会的方式进行。
--
--流程回顾例会应包括以下内容：
--
--|**回顾任务**|**描述**|**负责人**
--|流程有效性|流程有效性可以衡量一个流程在企业中应用的程度，以及流程的健康程度。|(((
--需求经理
--
--流程负责人
--)))
--|流程执行效率|流程执行效率是衡量流程参与者的工作效率指标，可以拿来衡量一个团队乃至个人的工作效率|(((
--需求经理
--
--流程负责人
--)))
--|数据分析研讨|根据报表提供的原始数据，集思广益找出值得注意的规律和变化，并决定如何处理，如，某些重复性较高的服务请求是否可以省去审批过程|(((
--需求经理
--
--流程负责人
--)))
--|案例分析|典型案例分析|(((
--需求经理
--
--需求受理人
--
--流程负责人
--)))
--|KPI修正|每次回顾会议时都需要讨论是否需要修正流程的KPI，并记录讨论结果|(((
--需求经理
--
--流程负责人
--)))
--|流程修正|每次回顾会议时都需要讨论是否需要对流程本身的设计进行修正，并记录讨论结果，如服务目录|(((
--需求经理
--
--流程负责人
--)))
--
--
--=== **4 知识管理规范** ===
--
--
--===== **4.1 知识库的管理** =====
--
--1. 知识库的内容收集、更新、维护、清理、权限控制、审核与发布都应该建立完善的管理制度并责任到人。
--1. 服务台人员对已启用的事件管理平台和问题管理平台中出现的问题进行归类整理，对出现的各个事件按部门、类型、处理难易度、解决时间等进行化类区分，并存入知识库。
--1. 信息中心各部门应设有专门的知识库管理员和文档库管理员，负责知识和文档的统一提交、审核、整理、维护。
--
--
--
--===== **4.2 维护管理任务说明** =====
--
--1. 知识审批流程
--1. 知识和文档分类与入库
--1. 新建知识库和文档库
--1. 知识库系统健康检查
--1. 知识访问相关统计
--
--
--====== **4.2.1 知识管理系统健康检查** ======
--
--* 工作内容： 知识管理系统健康检查
--* 责任人：系统管理员
--* 维护周期：每周
--* 执行时间：周五
--* 执行步骤：
--
--1. 登录门户，进入知识管理模块，对任意知识库进行查询、浏览、检查知识库是否工作正常
--1. 检查知识模块的各项主要功能服务是否正常
--
--
--
--
--====== **4.2.2 知识草稿审批** ======
--
--* 工作内容： 知识管理系统健康检查
--* 责任人：知识管理员
--* 维护周期：每天
--* 执行时间：每天12:00
--* 执行对象：各知识库
--* 执行步骤：
--
--1. 进入知识管理模块，查看上一日用户提交的知识草稿，发起知识审批流程
--1. 将审批通过的知识草稿进行分类、导入相应知识库成为正式知识
--1. 将未通过的知识草稿进行相应处理
--
--
--====== **4.2.3 知识提交、访问相关统计** ======
--
--* 工作内容： 知识管理系统健康检查
--* 责任人：知识管理员
--* 维护周期：每月
--* 执行时间：每月5日17:00前
--* 执行对象：报表系统
--* 执行步骤：登录进入报表模块，访问知识提交、访问统计报表，生成相应的报表文件，并将结果反馈给知识经理。
--
--
--====== **4.2.4 知识重新分类** ======
--
--* 工作内容： 知识重新分类
--* 责任人：知识管理员、系统管理员
--* 维护周期：每周
--* 执行时间：每周五  12:00前
--* 执行对象：知识库、文档库
--* 执行步骤：
--
--1. 检查用户对最近新增知识的评价，汇总是否有知识重新分类的需求
--1. 对知识进行重新分类
--
--
--
--=== **5 日常的周期性维护操作** ===
--
--
--本章总结了系统管理操作员（应用系统管理员，数据库管理员，主机系统管理员、网络管理员）日常维护工作的流程和具体需要完成的工作纪录表。同时所有的系统管理操作员在做日常维护工作时，应按照系统要求的格式填写好相应的每日、每周、月度、年度维护工作记录表。
--
--
--===== **5.1 日常的周期性维护工作** =====
--
--1 是否是周一
--
--如果当天是周一，则需要先执行系统每周维护工作
--
--2 是否是每月第一个工作日
--
--如果当天是当月第一个工作日，则需要先执行系统每月维护工作
--
--3 是否是财务年结之后第一个工作日
--
--如果当天是财务年结之后第一个工作日，则需要先执行系统每年维护工作
--
--4 填写维护工作记录表单（ITSM系统）
--
--
--===== **5.2 系统每日维护检查工作列表** =====
--
--====== **5.2.1 应用系统管理员负责部分** ======
--
--|应用系统管理员负责部分| | | | |
--|序号|工作内容|频率|时间|持续时间|备注
--|1|检查连接运行状态|1/日|上午|1－5分钟|应用连接和数据库连接
--|2|检查日志|1/日|上午|5－10分钟|主要检查报错信息
--|3|检查WEB服务运行状态|1/日|上午|1－5分钟|
--|4|检查报表服务运行状态|1/日|上午|1－5分钟|
--|5|检查进程运行状态|1/日|上午|1－5分钟|系统中相关进程是否运转正常
--|6|检查备份是否正常|1/日|上午|1－5分钟|
--|总计| | |上午|10－35分钟|
--
--
--
--
--====== **5.2.2 数据库管理员负责部分** ======
--
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|检查备份日志|1/日|上午|1－5分钟|检查前一天备份的日志
--|2|查看数据库告警日志|1/日|上午|5－10分钟|查找是否有告警，查看日志中是否有ORA-XXXXX的告警。
--|3|检查SGA、PGA、锁|1/日|上午|5-10分钟|主要检查是否有超负荷或死锁
--|4|检查正在使用的模块是否有20%以上可用空闲表空间|1/日|上午|1－5分钟|在系统使用过程中，对表空间可用率不足20%应尽快进行处理
--|5|检查是否有表或索引已接近其可以使用的最多扩展的数量。|1/日|上午|1－5分钟|对于表或索引的可用扩展数量与最大可用扩展数量差小于5时，应该尽快进行处理
--|总计| | |上午|15－40分钟|
--
--
--====== **5.2.3 主机系统管理员负责部分** ======
--
--
--| 序号|工作内容|频率|时间|持续时间|备注
--|1|检查文件系统利用率日志|1/日|上午|1－5分钟|使用df –k进行检查是否有文件系统利用率高于85%并且可用空间小于500M
--|(% rowspan="3" %)2|(% rowspan="3" %)查看系统硬件软件告警日志|(% rowspan="3" %)1/日|(% rowspan="3" %)上午|(% rowspan="3" %)1－5分钟|IBM主机使用errpt进行检查是否有硬件错误和告警，
--|SUN主机查看
--|/var/adm/messages
--|3|检查是否有僵死或运行时间过长的进程|1/日|上午|1－10分钟|使用ps –ef  进行检查（运行时间超过12小时的绝大部分是有问题的进程）
--|(% rowspan="2" %)4|(% rowspan="2" %)检查系统运行日志（系统CPU利用率，内存利用率，IO利用率，页面交换量的监控）|(% rowspan="2" %)1/日|(% rowspan="2" %)上午|(% rowspan="2" %)5－10分钟|IBM主机查看NMON的输出文件，并使用分析工具制作报表。
--|Sun主机查看top的输出，并使用分析工具制作报表。
--|5|检查系统高可用性（HA）的使用状态|1/日|上午|5-10分钟|检查集群软件日志文件的使用
--|总计| | |每日上午|13－40分钟|
--
--
--====== **5.2.4 网络管理员负责部分** ======
--
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|检查网络连接情况|1/日|上午|1－5分钟|
--|2|检查网络硬件（路由器，交换机，防火墙）的运行状态|1/日|上午|1－5分钟|
--|3|检查网络系统安全日志，搜索是否有攻击行为|1/日|上午|1－5分钟|
--|总计| | |每天上午|3-15分钟|
--
--
--
--===== **5.3 系统每周维护检查工作列表** =====
--
--====== **5.3.1 应用系统管理员负责部分** ======
--
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|检查系统定期请求运行结果|1/周 |周一上午|1－5分钟|如备份策略或自动操作
--|2|汇总本周运行情况总结|1/周 |周一上午|10－30分钟|
--|总计| | |周一上午|15－35分钟|
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|检查系统无效对象并编译|1/周 |周一上午|1－10分钟|对系统无效对象的处理
--|2|检查是否有表或索引设置增长的百分比或下一次的扩展的尺寸过大|1/周 |周一上午|1－5分钟|查找数据库表或索引增量TOP 10，根据表或索引实际的增长速率调整其增量大小
--|3|检查是否某表空间内对象的下一次扩展的总和超过目前表空间的最大可用尺寸|1/周 |周一上午|1－5分钟|查找是否表空间内对象的下一次扩展的总和超过目前表空间的最大可用尺寸
--|4|检查是否有数据库用户使用非TEMPORARY类型表空间作为临时表空间。|1/周 |周一上午|1－5分钟|运行SQL查询是否有用户使用非TEMPORARY类型表空间作为临时表空间，
--|5|检查是否有表或索引碎片过多需要优化|1/周 |周一上午|10－30分钟|进行碎块的检测和整理
--|6|检查空闲表空间是否碎块过多需要优化|1/周 |周一上午|10－30分钟|可使用alter tablespace <tablespace name> coalesce对碎块较多的空闲表空间进行整理
--|7|汇总本周数据库程序库缓冲命中率|1/周 |周一上午|1－5分钟|使用Oracle提供的statspack生成报表
--|8|汇总本周内存中排序比率|1/周 |周一上午|1－5分钟|使用Oracle提供的statspack生成报表
--|9|汇总本周数据库数据缓冲命中率|1/周|周一上午|1－5分钟|使用Oracle提供的statspack生成报表
--|10|汇总本周数据库级的TOP 5等待事件|1/周|周一上午|1－5分钟|使用Oracle提供的statspack生成报表
--|11|汇总本周最耗CPU的 TOP 10 SQL|1/周|周一上午|5－10分钟|使用Oracle提供的statspack生成报表
--|12|汇总本周磁盘I/O TOP 10的SQL|1/周|周一上午|5－10分钟|使用Oracle提供的statspack生成报表
--|13|汇总本周表空间I/O TOP 10|1/周|周一上午|5－10分钟|使用Oracle提供的statspack生成报表
--|总计| | |周一上午|1－2小时|
--
--======   ======
--
--====== **5.3.2 数据库管理员负责部分** ======
--
--
--====== **5.3.3 主机系统管理员负责部分** ======
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|清理过时的系统临时文件|1/周 |周一上午|1－5分钟|清理超过14天未访问的$APPLTMP/, /usr/tmp/, 目录下的临时文件
--|2|检查磁带库和磁带使用情况|1/周 |周一上午|1－10分钟|检查是否有足够的空间保存备份，磁带库运行中是否有错误出现
--|总计| | |周一上午|5－15分钟|
--
--
--====== **5.3.4 网络管理员负责部分** ======
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|升级网络安全软件版本（入侵检测漏洞库，病毒库）|1/周|周一上午|10－20分钟|
--|总计| | |周一上午|10－20分钟|
--
--
--
--
--===== **5.4 系统月度维护检查工作列表** =====
--
--====== **5.4.1 应用系统管理员负责部分** ======
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|汇总本月用户登录审计信息，清除30天以前的审计信息|1/月|每月第一个工作日|5－10分钟|如果需要的话才进行统计
--|2|汇总本月用户和职责变动|1/月|每月第一个工作日|5－10分钟|
--|3|汇总上月工作纪录报告，和情况总结，提交主管审批|1/月|每月第一个工作日|2－4小时|
--|总计| | |每月第一个工作日|2.5－4小时|
--
--
--====== **5.4.2 数据库管理员负责部分** ======
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|修改数据库sys和system用户口令|1/月|每月第一个工作日|1－5分钟|
--|2|修改数据库APPS口令|1/月|每月第一个工作日|5－10分钟|需要停止服务
--|3|检查是否有索引使用的扩展数量过多需要优化|1/月|每月第一个工作日|5－10分钟|使用较大的Extent进行重建索引
--|4|检查系统Patch情况|1/月|每月第一个工作日|10分钟|检查Patch记录
--|5|汇总本月增长最快的10个表空间|1/月|每月第一个工作日|5－10分钟|根据表空间的已使用和空闲的空间计算增长速度
--|6|汇总上月工作纪录报告，提交主管审批|1/月|每月第一个工作日|2－4小时|
--|总计| | |每月第一个工作日|3－5小时|
--
--
--====== **5.4.3 主机系统管理员负责部分** ======
--
--
--|(((
--===== 序号 =====
--)))|工作内容|频率|时间|持续时间|备注
--|1|修改UNIX用户口令|1/月|每月第一个工作日|1－5分钟|修改过UNIX口令之后，需要通知需要知道口令的人员。
--|2|清洗磁带机|1/月|每月第一个工作日|1－5分钟|
--|3|汇总上月工作纪录报告，提交主管审批|1/月|每月第一个工作日|1－2小时|
--|总计| | |每月第一个工作日|1.5－2小时|(((
--
--)))
--
--
--====== **5.4.4 网络管理员负责部分** ======
--
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|汇总上月每天网络运行记录，提交主管审批|1/月|每月第一个工作日上午|15－30分钟|
--|总计| | |每月第一个工作日上午|15-30分钟|
--
--
--===== **5.5 系统年度维护检查工作列表** =====
--
--====== **5.5.1 应用系统管理员负责部分** ======
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|汇总上年度的统计信息，编写年度运行报告|1/年|财务年结之后第一个工作日|4－8小时|
--|2|容量测试|1/年|财务年结之后第一个工作日|1－2天|
--|总计| | |财务年结之后第一个工作日|1.5－3天|
--
--
--====== **5.5.2 数据库管理员负责部分** ======
--
--
--|    序号|工作内容|频率|时间|持续时间|备注
--|1|汇总上年度每月数据库运行情况，编写年度数据库运行报告|1/年|财务年结之后第一个工作日|4－8小时|
--|2|容量测试|1/年|财务年结之后第一个工作日|1－2天|
--|总计| | |财务年结之后第一个工作日|1.5－3天|
--
--
--====== **5.5.3 主机系统管理员负责部分** ======
--
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|汇总上年度每月主机运行情况，编写年度主机系统运行报告|1/年|财务年结之后第一个工作日|4－8小时|
--|2|系统备份|1/年|财务年结之后的第一个周六|30分钟|
--|3|容量测试*|1/年|财务年结之后第一个工作日|1－2天|
--|4|资产盘点|1/年|财务年结之前或之后|5-15天|包括资产库和配置库的盘点
--|总计| | |财务年结之后第一个工作日|6－15天|
--
--
--====== **5.5.4 网络管理员负责部分** ======
--
--|序号|工作内容|频率|时间|持续时间|备注
--|1|汇总每月网络运行情况报告，形成运行年报|1/年|上午|1－5分钟|
--|2|考虑网络系统容量的扩容要求，撰写网络容量报告|1/年|上午|1－5分钟|
--|3|网络设备硬件，线路维护|1/年|每年第一个月|5-10天|注18
--
--
--
--=== **6 KPI设计** ===
--
--建议采用IT平衡计分卡对管理信息系统部所提供的IT服务进行考核和评估，涵盖以下四个方面：
--
--* 关注用户：IT服务的用户都是IT部门的客户
--* 价值贡献：IT服务关注于对组织的价值贡献
--* 运营效率：IT服务运营效率是IT部门内部流程的关注
--* 面向未来发展：面向未来发展考虑IT部门和员工的学习和成长
--
--IT平衡计分卡内容总结如下图所示：
--
--
--[[image:图片3.png]]
--
--
--具体到本项目中，这四个主要成效区（KRA：Key Results Area）的具体体现如下表所示：
--
--|主要成效区 KRA|本项目中的具体体现
--|(% rowspan="2" %)价值贡献|- 业务系统的可用性
--|- 对业务的支撑
--|(% rowspan="2" %)关注客户|- 用户满意度
--|- 客户投诉
--|(% rowspan="2" %)运营效率|- 运维流程的效果
--|- 运维流程的效率
--|(% rowspan="2" %)面向未来发展|- 监控管理中心的应用
--|- 服务的执行和改进
--
--
--借助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 考核计算方法** ======
--
--作为一种绩效考核方法，评估、核算和激励是基本的程序。具体的目标分解到指标，定期对每个指标进行评测，然后核算出加权的综合值，并按照考核结果行事，奖励每一个取得好成绩的省或人员。
--
--|关键领域|考核指标|指标值|评分|权重|考核分数
--|关注客户|用户客户满意度| | | |
--| |客户投诉解决率| | | |
--| |客户投诉处理及时率| | | |
--| |客户投诉次数| | | |
--|价值贡献|统一信息平台可用性| | | |
--| |统一信息平台重大故障次数| | | |
--| |统一信息平台重大故障平均解决时间| | | |
--| |关键业务系统可用性| | | |
--| |关键业务系统重大故障次数| | | |
--| |关键业务系统重大故障平均解决时间| | | |
--| |处理业务开发需求的数量| | | |
--| |处理服务请求的数量| | | |
--|运营效率|事件平均转派次数| | | |
--| |事件解决率| | | |
--| |主动发起问题次数| | | |
--| |问题平均解决时间| | | |
--| |问题解决率| | | |
--| |由问题触发的变更数量| | | |
--| |变更回退次数| | | |
--| |变更成功实施率| | | |
--| |未授权变更次数| | | |
--| |由事件或问题生成的知识数量| | | |
--|面向未来发展|使用各模块的次数| | | |
--| |流程或监控系统优化的次数| | | |
--| |员工对知识库的贡献数量| | | |
--| |知识库解决方案被引用的次数| | | |
--|(% colspan="3" %) |(% colspan="2" %)总体结果：|
--
--
--=== **7 维护管理制度** ===
--
--* 维护管理制度的目标
--
--为了实现服务管理系统的有效管理，确保江苏核电IT组织提供的服务各环节的规范性，统一客户服务流程模板，保障流程系统安全稳定运行，明确各部门在流程管理中的职责，进行流程管理系统维护管理制度的制定。
--
--* 服务管理保障机制的原则
--
--为了确保此次项目推广的服务管理系统得到严格的贯彻执行，并在执行过程中得到持续改进和提升，根据以往的经验，维护服务管理流程应遵循以下原则
--
--1. 重视流程意识培养和流程内容的培训工作
--1. 强化流程的执行工作，与绩效考核挂钩
--1. 实施详细的流程回顾、报告工作
--1. 建立有效的执行状态审核评估体系
--1. 务实处理在实际工作中有关维护流程的问题，使流程不断改进提升
--
--* 维护范围
--
--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 处理系统故障**
--
--系统管理员应及时对系统出现的故障进行解决，或及时联系相关技术人员对系统故障进行解决。
--
--
--

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司