IT服务系统构建全攻略
任务管理更多是为了管理者的工作而设计的，这也是运维服务作业中最后一块没有被记录的话动。这样下来后，事件、问题、变更、操作、任务就构成了任何一个运维服务人员，无论他是领导还是一线员工的作业平台，只有监视所有的活动，其资源使用才被全部监视。
任务管理的报表有针对任务执行情况的，还有横向分析任务类型的，即任务的资源占用情况。如果数据积累足够多时，这种分析展开，会让我们非常吃惊，因为运维服务的大量资源是被无效使用的。这样运维服务管理才有改善的方向与具体指标。
十一．SLM管理
某种程度上，我们的ITSM系统并没有实现真正意义的SLM管理，系统中并不关心SLA制订出来前的过程，也没有把UC与OLA等纳入其中，我们只把制订出来的SLA设置在系统中，以实现监控与作业。所以以下说的是SLA的管理实现方式。
SLA在我们业务中分为故障解决率与Q指标，EUS（客户满意度）是另一个纬度的数据，不在此列。故障解决率是指在规定时间内完成事件处理的百分比，Q指标是持续运行时间。
具体谈一下我们的实现方式。前面说的服务日历是很重要的一个基础数据，没有它，SLA的计算全部会错。我们把事件分成了5个等级（SLA只适用于事件处理），每一个项目都会针对每一个事件等级设置解决时间要求值（比如一级事件需要2小时，二级事件需要4小时，三级事件6小时，四级事件8小时，5级事件12小时）。
这里定义的时间值是与服务日历匹配的，比如服务日历定义5*8是指周一至周五的8：00-12：00，14：00-18：00。如果一个一级事件发生在周五的1 7：00，即便是第二周周一的8：30解决，也没有违反SLA（虽然现实中我们会马上处理，但SLA计算是如此）。
另外Q指标的定义是这样的，每一个项目要定义清楚到底哪一个事件等级会纳入Q指标的计算中，比如一级、二级事件的故障时间（从事件创建到事件解决）会纳入计算，三、四、五级的事件故障时间就不纳入计算，这样随时可以计算你当前的Q指标是多少。
SLA设置完成后，就会在事件中就用。当你把事件定位在一个项目时（CI），你选择了事件等级，此时系统会调出事件解决的时间要求；当你创建完成时，系统开始倒计时。SLA的报表主要是针对故障解决率与Q指标的，只是统计的纬度是多样的。
十二．知识库管理
知识库管理考虑现实情况，我们没有做得太复杂，运维服务的知识有较强的时效性，更新较快。这里说的知识是针对故障处理方面的，并不是指员工的技能或知识培养方面，这与通常说的KM有不少区别。
运维过程中的知识非常具有针对性，所以没有把通用的知识纳入考虑，都是从项目的角度提出来。知识的创建有三个来源，事件生成、问题生成、手工创建。为了便于查找，我们的做法是以项目为纲，以分类为目，以关建字为辅，即最根本的分类是项目，然后是根本事件问题的分类，最后是用关键字，用这几个手段查找知识点，供工程师处理事件时调用查看。
无论知识是从事件或问题或手工创建，都会有一个审批的过程控制知识库的更新，还可以设置知识有效期限。另外，知识库的创建可以做一些统计与分析，看哪一个团队的知识复用较多，哪一种类型的知识较多。对于知识的利用，不建议纳入系统考虑，因为在软件中难以识别，靠点击意义不大。一个人打开知识看后，可能发现根本不是他想要的，或者他只是借鉴看一下，这时强迫按钮操作没有意义。
十三．调查管理
调查管理原本是希望改变以前手工发邮件采集满意度调查的做法，设计时，发现可以对象化，做得更灵活些。我们是这样考虑的：可以设计许多问卷，可能是针对客户满意度的，可能是为了调研我们的服务方式改进方向的，也可能是为了解服务产品化的潜在空间的。问卷设计好后，可以生成调查任务，一个问卷可以被无限调用，而调查结果是针对调查任务而不是针对问卷的。
调查可以直接发网址到客户邮箱（取自客户数据），也可以直接把问卷发过去。如果是WEB采集数据，可以生成用户名与密码发到客户邮箱，用户登陆系统填写，也可以手工回收。但WEB是省力的，因为调研结果由系统自动生成。
有一些细节需要考虑，比如任务的开始与结束时间决定问卷填写开始与停止，是不是设置必填与可选，是翻页填写还是整页显示，甚至问卷的答案选项与分值设置，还要注意调研对象散与客户资料的集成（从某一个客户组织选择一定百分比），还有CMDB（针对某一个系统或项目）的接口。
基本上把我们大的模块写完了，有些大杂烩，有些地方不够深入，也没有把一个ITSM系统每一个模块应该具备的元素提炼好，象一些绩效点没有成体系写出来。但上述许多设计仍然是国内公司一段时间内较难企及的，这里包含许多年来各种各样的思考，软件的、管理的、ITIL的，对运维业务本质的理解。从事这种系统开发的公司或个人能知道其中的价值。
共4页:
上一页 [1] [2] [3] 4 下一页
0631-3653338
站长中国编辑部
收藏本文
打印本文
告诉好友
投稿邮箱
评论加载中…
