IT服务系统构建全攻略
我让一个电话录音机当热线，这算不算响应呢？如果你的热线是接转电话给工程师，经过热线转一下的意义何在？工程师仍然处于随时待命的状态，你的服务资源没有任何节省，而是在浪费，同时让用户重复问题，或者让热线转述问题，造成信息缺失。
当你的服务台没有起到服务台的作用时，你会发现一个有意思的现象：用户会绕过你的服务台，直接打电话到工程师。不要说这是用户的问题，这是你的问题，你没有把一个正确的路径给用户，用户会按最有效率的路径来走的（是不是类似我们走草坪的情形？人们不会喜欢90度的直角小径，会用斜线穿越草坪）。
IT服务业的服务台不同于传统行业，用传统行业呼叫中心的做法去设立IT服务业的服务台，一般是行不通的。尤其当你的业务领域复杂时，可能虚拟服务台是一个不错的选择，没有一定的硬性标准，要根据自已实际的业务需要来。一个真正好的服务台，可以节省你的服务资源，而且可以更快把客户请求结束掉。
五．事件管理
事件管理是创建、处理事件的模块，一个事件的生命周期全部会在此模块内。在设计时，需要考虑以下的信息：
①事件的类型：事件管理在我们规划中，是一个非常重要的窗口模块。事件类型我们分为了有故障、请求、咨询、新需求、投诉，基本上面向客户的事务都会在此发起，这种类型也是为了日后的统计分析。
②事件的分类：由于项目众多，考虑到横向统计的需要，我们要定义一个公用的事件分类，以便运维管理分析。我们分了硬件、软件、网络、数据库、接口、业务这几个大类，日后可能会进一步细化分类，以便做更深入的分析，但这个难度很大，需要时间的积累。
③事件的等级：最开始我们希望引入优先级（严重度与紧急度），但发现这样定义非常困难，对指导工程师处理意义不大，还可能会误导信息，所以最后把事件硬切为5个等级。公司给出最粗的定义标准，然后由每个项目具体定义解释。这样每个工程师在作业时，就可以定义事件的等级。默认情况下，等级越高的事件，表示越严重，也表示要优先处理。虽然会相对粗放一些，但简单适用，而且我们的SLA是与此相关的。
④事件的状态：事件状态是为了表达事件单当前的处理状况，我们分了创建、分派中、处理中、等待中、解决、关闭。这样可以形成看板与统计。
⑤事件与CMDB的关联：CMDB的用处，在事件的应用就相当关键。事件发生时，要做一个关键动作，就是组件定位。需要搞清楚这个事件是发生在什么项目（CI）的什么地方（CI），需要事件创建者做出定位；然后派单时，根据你的CI定位，带出相关的责任工程师，与事件与CI的关联，给你的运维分析带来丰富的信息。你CMDB所有的信息与事件的信息可以交叉统计分析，比如上面说的事件的分类有硬件，那我想知道桌面项目一年中，硬盘发生了多少故障？希捷品牌的硬盘发生了多少故障？客户对哪一款软件的咨询次数最多？这些信息依靠事件中的组件定位，可以轻而易举告诉你。
⑥事件与其它流程的接口：事件与变更、问题、知识库是存在接口的，事件处理过程中可以直接发起变更申请，也可以发起问题申请与知识库申请。需要说明的是事件与变更的接口，我们的事件是否关闭没有硬性判断与之关联的变更是否终结，而是从事件单方面流出信息，并没有把变更的处理情况与事件单关联，让这个流程分线程去作业处理。主要是担心做得太死，可能导致事件单关闭受阻。
⑦事件的时长与工作量：在任何一个事件的处理时，对于时间有二个概念，一是事件的时长，即一个事件的处理周期（从8：00创建到12：00解决，4小时）；一是事件花费的资源量，即工作量（4小时的时长中，工程师可能投入了2小时来处理）。时长是为了SLA的计算，后者是为了运维资源的分析。
⑧统计分析：事件报表的统计分析非常丰富，可以从CMDB的角度出发，去统计每一个项目、每一个设备的事件情况；还可以从客户的角度出发，统计某个客户组织或某个客户的事件情况；还可以从运维组织的角度出发，统计我们的一个服务团队或一个服务人员的事件情况；可以从事件本身的信息出发，根据事件的类型、分类、等级、状态、来源（电话、邮件、WEB）去统计，还可以统计SLA方面的数据。
六．问题管理
问题管理处理逻辑其实是类似事件的，它的许多信息是继承事件，比如等级与类型等。在规划问题管理时，要想清楚问题的分类等级等信息跟事件是什么关系，问题管理的大概作业界面有哪一些，在系统流程上有哪几个步骤，如何留下问题的处理时长与工作量等等。
还要想清楚问题与事件在程序处理上的区别，比如问题的创建后需要有一个审批的动作，问题不服从SLA，问题有知名错误的概念，这一部份的设计如果你的事件规划好后，问题管理是相对简单的，它的难不在于程序，而在于日后的应用。
问题的统计报表，基本上与事件的纬度类似。
七．变更管理
在ITIL中，变更与发布是两个独立的流程，我们把这个流程合并为一个。发布的控制在程序中可以实现的控制点是很少的，而且它与变更是如此紧密。在我理解中，变更的实施就是发布流程，即发布可以理解为是变更的一个子流程。发布不仅仅是针对软件的，硬件一样也会有发布的概念，比如将一台新设备布署到生产环境中。
对
CMDB的控制，在业务层面全部需要通过变更来实现，CMDB精确度如何，很大程度上取决于变更的执行情况。我们考虑到一点，如果让CMDB的信息更新得到有效控制，当工程师在填写变更申请时，在界面上就提列出变更前后的具体信息；审批时，不光是审批变更的行为，更重要的是要审批变更的内容；如果审批通过，执行后，根据这些信息把CMDB做更新。这样可以相对减少没有约束的对CMDB更新的行为。
共4页: 上一页 [1] 2 [3] [4] 下一页
责任编辑：
评论加载中…
0631-3653338
站长中国编辑部
收藏本文
打印本文
告诉好友
投稿邮箱
