ISO20000广破论（10）-事件管理 破子
学习资料： ITIL培训基地专家讲堂直播 300期视频回放
1 事件管理
1.1 流程概论
1.1.1 流程目标
以最短的时间响应服务请求并恢复正常服务
1.1.2 术语定义
Ø 事件：服务请求、故障、新需求、投诉统称为事件
Ø 服务请求：已经定义好的由客户触发的标准服务，如咨询信息、口令重置、文档获取等等，它不属于故障。（注：此处所谓的标准服务，是指在服务合同中，事先定义好的、按既定的程序作业的服务操作，它是非主动性的，必须由客户触发的）
Ø 故障：服务出现异常（服务中断或服务质量下降）的任何情况
Ø 新需求：非服务合同内的，需要另外计费的服务作业。
Ø 投诉：客户任何关于服务或产品的不满意
注：在这里与ITIL的定义有一定差异，事实进一步扩大了事件管理的边界，同时统一界定了各个事件类型，ITIL的定义把事件与故障做了对等，而把服务请求置于一个模糊于事件之外的状态，这是从服务管理的角度是不合理的，许多时候一个服务请求的优先级会高于一个故障，事件的界面必须保持完整性与开放性，因为其处理会面临资源的调和问题，服务请求与故障之间存在许多紧密的联系，过多的服务请求可能意味着某种功能或主动服务的缺失，新需求同样如此，就如可以通过烟的存在来发现火的存在的道理一般，服务请求与新需求的背后可能潜藏着问题与改进点，这些信息需挖掘才能知悉。
Ø 优先级：根据影响面与影响度计算出的指导事件作业次序的等级信息，一般用5级来表示，1级优先级最高，5级优先级最低
Ø 影响面：事件影响的范围（广度），主要针对用户或业务数量的多少而言。可分为大、中、小
Ø 影响度：事件影响服务偏离正常级别的程度（深度），主要针对服务受到多严重的影响，可分为高、中、低
根据以上的逻辑会形成一个矩阵：
Uploads/UserDirs/1/390/155890/事件等级模型.bmp Uploads/UserDirs/1/390/155890/事件等级模型.bmp
注：这里与ITIL最大的区别在于，在流程中不引入任何现实时间因素，排除紧急度这种概念，因为紧急度暗示着时间，而绝对的时间是会随着项目不同而不同的，随着SLA的不同而不同的，更重要的是认为一级事件的处理时间最短，而五级事件处理时间最长，这种逻辑很可能是错误的，事实情况中一级事件的处理很可能比五级事件要长，因为它的处理过程更复杂。一定要把握事件等级的意义，它是指导服务人员先处理哪一个事件，而不是直接给出最终的时间约束，最终的时间约束是要SLA去定义的。
Ø 事件升级：在ITIL的定义中是指职能性升级（一线团队无法处理完成需要二线团队处理）与结构性升级（由行政领导干预事件过程）。
注：强调事件升级的意义很低，而且容易误导观念。因为以绝对时间去限定事件是否升级与否是不合理的，对于一、二、三线的团队而言，不是以时间去切分任务，而是以职能去切分任务，属于三线的职能范围的事件，比如是软件BUG，一线将事件分流给三线处理，这叫升级吗？这是一种最正常的作业机制。而所谓的结构升级，事实上是一个信息提醒的问题，在有软件工具的情况下，一个事件不能在SLA的要求时间内完成，就应该让服务管理者知道，甚至一个一级事件发生时就应该让服务管理者知道，这与我们通常理解的升级的概念是有很大分别的。现在有不少人以为事件升级是一个三级事件升级成了二级事件，这是不对的，一个事件的等级不会随着时间而发生变化，所以一个三级事件是永远不会变成一个二级事件的，一定要牢牢把握事件等级的概念与目的，在优先级中纳入任何时间因素的考虑，将使等级信息一直在解决状态时都处于高度动态的过程中，从而失去了其作用。
Ø N线支持：一般来说将服务团队是由几个职能小组组成，每一个职能小组依照其在事件流程中的参与次序进行排，第一个参与小组则为1线，第二个参与小组则为2线，以此类推。
注：为了后续沟通的方便，我们暂做一个定义，0线是指服务台（呼叫中心），1线是指负责解决基本的操作、配置、安装问题的服务工程师，2线是指主机层的系统管理工程师，3线是指软件开发工程师。
1.1.3 流程说明
事件管理是最根基的一个流程，它是服务质量的映射，各个层面的问题的最终都会反映在事件管理之中，即不是每一个事件都代表着质量问题的发生，但每一个质量问题一定是一个事件。事件管理它又是被动式的，它的存在意味着服务质量受到了干扰，需要IT服务力量介入处理，事件管理是客户与服务商在服务作业过程中的唯一交互界面，事件管理关注的是客户服务的恢复，而不是事件的原因，所以时间要素是事件管理的第一考虑。而服务级别协议的达到也极大程度的依赖于事件管理，因为最终服务级别协议的落实主要是依赖事件的处理来体现。
1.2 标准解读[
1.2.1 标准条文
目标：尽快恢复承诺的服务或响应服务请求。
Objective: To restore agreed service to the business as soon as possible or to respond to service requests.
应记录所有的事件；
All incidents shall be recorded.
应采用程序来管理事件的影响；
Procedures shall be adopted to manage the impact of incidents.
程序应规定所有事件的记录、优先级、业务影响、分类、更新、升级、解决方案和正式关闭；应保持通知客户事件报告或服务请求的进展，如果不能达到承诺的服务级别，应提前警告并采取承诺的措施；
Procedures shall define the recor**, prioritization, business impact, classification, updating, escalation, resolution and formal closure of all incidents. The customer shall be kept informed of the progress of their reported incident or service request and alerted in advance if their service levels cannot be met and an action agreed.
与事件管理有关的所有员工应有权限访问相关信息，如知名错误、问题解决方案和配置管理数据库（CMDB）；
All staff involved in incident management shall have access to relevant information such as known errors, problem resolutions and the configuration management database (CMDB).
重大事件应分类并按流程管理；
Major incidents shall be classified and managed accor** to a process.
1.2.2 条文解读
标准条文中第一强调的是所有的事件需要做记录，这一点要在管理程序中明确规定，同时要对事件进行分类分级，明确其业务影响，对事件信息的更新、升级、解决方案与关闭等做出了明确要求，所以每一个事件的记录需要非常全面，基本上事件数量较多时，没有一个软件辅助管理记录，是很难做到的，尤其是后续需要做大量的分析统计活动，所以标准的第一部份是明确了对事件记录的要求。第二部份是要求在事件处理过程中，如果无法满足服务合同定义的服务级别协议需要告知客户，并在处理过程中与客户保持信息交互。第三部份要求的是事件处理人员的信息支持，最后是对重大事件单独做了要求，在程序中要明确重大事件的处理流程，因为它可能与普通的事件处理流程是不一样的。
1.3 流程角色
角色
职责
服务经理
确保支持小组按事件规范进行事件处理
确保支持小组在规定的时间（SLA）内完成事件处理。
发现解决事件积压及作业瓶颈的情况
事件支持资源的协调（如外部供应商）
事件整体情况的分析与改进
重大事件的回顾与分析
收集提交事件流程的问题与改进建议
服务台
接受用户的事件申告，对事件进行确认
登记事件信息
对事件进行分级和分类
对职责内的事件进行处理
将事件正确分派给事件支持组
跟踪事件的处理过程，对违反SLA的事件进行升级
对已解决的事件回访，并确定关闭事件
与客户沟通的话术设计与改进
与客户沟通的渠道的管理
事件支持组
处理分派的事件，并记录处理过程与方法。
无法在SLA要求时间内完成，需要向服务经理提出协助。
对未知原因的事件进行问题建立。
在事件处理过程中，如果需要变更，则建立变更请求
事件处理完成后与用户确认。
已完成处理的事件提交服务台。
1.4 流程活动
1.4.1 流程图
Uploads/UserDirs/1/390/155890/事件流程.bmp Uploads/UserDirs/1/390/155890/事件流程.bmp
1.4.2 活动说明
1.4.2.1 事件申告
一个事件的申告的来源可能是多方面的，就性质而言由客户、服务商、工具都可以发现事件或做事件申告。客户申告是比较多普遍的，由客户提出一个需求或报告说出现一个故障（监控与主动服务的强大与客户申告的事件比例成反比），服务商做事件申告，多是手工发现或工具发现，在ITIL中监控职责属于服务台的一部份，但实际情况中可能很少公司可做到，因为监控的难易度有很大不同，所以目前的监控机制开始立体化，尤其在主机层的监控与应用层的监控将越来越深入，已无法依赖于一个独立的职能组作业了，所以大多数公司建立一个独立的监视团队都无法穷尽监控之职，更何况将其捆绑于服务台的职能内，此时将会出现大量的简单监控由公用的专职监控团队负责，复杂一些的将分解到支持小组。如果是服务商层面发现的，需要建立一个机制，把事件及时记录，以避免许多问题当时就处理了，但没有留下记录。
客户申告事件的渠道可能是多方位的，最常见的渠道是电话，其次是邮件，而随着网络技术的发现，通过IM工具与客户交互也越来越常见，象QQ群、MSN群、腾讯通、OCS，还有一些公司自行开发的工具等等，这些IM工具大大提高了与客户的紧密感，能够更加无缝的反映客户的服务情况，渠道的多样性也带来一系列的管理问题，比如话术问题，怎样有电话里去有效的了解到事件信息，采集客户数据，同时又让客户身心感到愉悦，这现在大多数公司可能有了比较成熟的方法了，但是怎样每一次有技巧的回复客户的邮件，怎么在MSN或QQ上跟客户有效率的沟通，怎样用邮件与QQ回访客户，这个很少人研究。还有因此带来的事件记录问题，以前一个电话或一个邮件过来，我们都知道这起码是一个事件，但在线交互时我们越来越发现对事件的判定需要更加精确，同时由于这种全天候的毫无阻碍的方式，某种程度上鼓励了用户提出更多的问题与意见，这些光是交流的基本应对都需要付出更大的成本。目前的经验是IM非常容易导致事件失去记录，要么与ITSM工具做很好的集成，要么建立严格的检查机制，对许多较为集中的商业组织的IT服务而言，IM工具的深入应用，将会给前端的服务管理带来革命性的影响。
建立一个带有菜单功能的语音系统的服务台是必要的，不建议在没有考虑好全面的机制前采用IM渠道做事件申报，统一集中的受理事件即单一界面的意义很大，规模越大，服务类型越多，客户越分散，这种整合的需要就越强，服务台是整个服务的监控组织，用非常技巧的方式把服务台的连接方式通告给用户，鼓励用户到服务台报障，要尽量避免服务台的边缘化，所以事件申告需要首先依赖于一个组织基础，即一个服务台，其次是需要一个客户与服务商的连接渠道，然后就是就一个训练有素的热线服务人员，及一套成熟的话术设计，就是说当用户通过某种方式呼叫服务后，服务台的人员需要迅速的了解到客户的需求所在，这种迅速更多不是IT专业知识造就的，而是话术所造就的，良好的话术有助于平和客户抱怨及更有效率的处理客户呼叫。在有软件工具的情况下，建立一个完备的客户数据库非常必要，它可能在技术层面提高客户的呼叫感受，同时为后面的事件处理过程节省大量联系信息查找的不便，甚至根据客户信息与事件信息，可以进行智能分析开展主动服务。
1.4.2.2 事件记录
在用户事件申报过程中，服务台人员会了解许多信息，比如客户碰到了什么问题，导致怎样的影响，即事件的表象与影响，这些事件信息需要进行详细记录，形成事件单，此时没有一个软件工具是不可想象的。事件的基本信息应包括：时间信息（何年何月何日何时），客户信息（姓名、职务、部门、电话）事件类型（故障、咨询、服务请求、投诉、新需求），事件等级（一级、二级、三级、四级、五级），事件分类（软件、硬件、网络、数据、业务、环境、接口），事件摘要（简单包含关键字的事件摘要信息），事件描述（事件现象、事件影响、事件时间、配置信息）,这些最初的事件信息由服务台人员记录，记录动作可能是在用户申告过程中发生，也可能是用户申告结束后记录，这取决于服务台的硬件与软件及人员情况。要注意的是，一个呼叫可能包含多个事件信息，比如一个客户电话到服务说，其部门的一台复印机无法使用，同时办公电脑提示有病毒，这是两个事件，服务台需要建立两个事件单，而不是一个，这非常重要，它涉及到基本的概念与后续的派单问题，比如建成一个事件单，如果负责电脑维护的是一个支持组，复印机又是一个支持组，此时派单就出现问题，又或者同时将单派派出去，电脑维护OK后，复印机要原厂商支持没有维护好，此时事件单关也不是，不关也不是，服务台人员必然有这种根本的事件识别意识。当一个事件已经有记录时，比如当网络中断时，会不断有客户打电话过来，此时再记录就重复了，在有工具软件的情况时可以进行事件关联，这样可以待主事件解决后，直接对从事件进行回访即可。
值得注意的是服务台的事件记录，很多可能信息是不全面甚至是不正确的，如果服务类型比较多，而服务台内部又没有进行分组建制的话，服务台必然无法深入到具体的服务层面，此时事件信息的判断与记录很可能是有问题的，这时就需要后续的支持小组去修正事件信息，服务台与支持小组的分工是需要明确的，如要服务台需要起到初步的支持作用，意味着服务强要兼并一部份一线职能，此时职能的冲突将会越发明显，尤其到后期，服务项目越来越多后，服务台很可能会异化成支持小组，而形成一个庞大的支持团队，所以这是一个矛盾，如果服务台比较深入的话，其本身最重要的职能将面临瓦解，同时与支持团队的职能将面临冲突，最后很可能重组成一个庞大的一线团队，于是又回到最初的问题，谁去负责效率的接入客户需求，同时去监督服务。如果服务台不深入，又面临着来自客户与支持团队的双层指责，客户觉得服务台浪费他们的时间，又不能帮助真正解决问题，甚至服务台连问题都无法了解，而支持团队又觉得服务台什么简单的问题都往下派，甚至还派错单记错单。这些矛盾与平衡的问题，比较可行的解决方法是，在服务类型较多的情况下，将服务台的建制分组，以做到适度的专业化，再通过语音菜单功能将客户呼叫分流至不同的服务台小组，对于服务类型复杂的服务商而言，追求服务台的首问解决率往往是不合适的，它会让服务台成为流程的瓶颈，这不符合ITIL精神与效率原则。
1.4.2.3 初步支持
服务台在受理事件时，要进行初步支持，此动作可能根据组织的不同要求不一样，服务台进行初步支持的目的在于迅速处理简单的事件，从而降低作业成本又提高效率，到底初步支持什么很关键，此时服务台扮演的是支持小组的角色，如果支持小组的职能上浮到服务台是需要进行控制的，服务台的初步支持的职责更多是动态的，比如近期大规模的邮箱切换，或病毒爆发，都可能导致用户在一段时间大量的事件申报，如果解决动作非常快捷简单，甚至只是做一个咨询解答即可，服务台直接进行处理是合适的，这种做法依赖一个较好的事件监控分析机制，支持小组需要有方法识别出这种类型的事件，进行设计简单可行的知识库对服务台进行培训，以应对突然的事件爆发；另外一种情况是服务台承担了部份支持小组的职能，比如电脑的维护，经常有用户某种设置不正确，而造成应用不正常，此时只需要远程进行指导即可，这种类型的事件直接由服务台人员处理即可。
服务台的初步支持要根据实际的情况进行定义，是动态还是静态，是长期还是短期，在不进行较好的控制的情况下，很有可能导致服务台的初步支持的职责范围越来越大，越来越深入，此时支持小组的一线职能开始往服务台转移，而服务台人员本身的职能也开始发生质的变化，会导致的新的问题发生，从而进行新的组织轮回。从正常情况下，不能认为由服务台从事简单的事件处理是合理的，因为这种认知会鼓励支持小组不做改进，从而无法形成一个正确的反馈回路，正确的服务情况下，不会发生爆发性的简单性质的事件，正常情况下，也不应该有大量简单性质的事件长期存在，这其中一定是支持小组在某个环节没有完善，比如邮件的咨询事件大量发生，很可能是用户手册的发放渠道不合理或用户手册编制得低劣，病毒也可能是后台的防毒工作出了问题，如果支持小组的犯错让服务台去承受后果，这本身不合理，也会失去让支持小组改进的最好压力，让人类身体保持健康的最好机制是，让最小的负面做法带来的痛苦最大化，让最小的正面做法带来的愉悦最大化，这种正确的回路机制会强化机体的正确作为。现在很多公司中反对本位主义，当发生问题，要求所有部门的人都协同解决，而很少有人去真正去发现这其中的管理真空，这些情况粗看起来好象是为公司利益在考虑，但事实上是对组织的进化与发展非常不利的，这只是为了眼前一点小利益而放弃长远利益，大家永远只在发生问题后不分权责的埋头处理，处理完后就大松一口气甚至庆祝，许多人很容易陷入那种救火队员所带来的成就感，而没有从本质与根源上去寻找为什么，然后永远有下一个类似的问题继续发生，要利用每一次错误或问题来充分的认识整个组织的缺陷，适当的本位主义会加速组织的成长与整个管理体系的完善。
1.4.2.4 事件处理
一线、二线、三线只是相对的概念，是针对项目而言，一个人可能在一个项目中是一线，而在另一个项目是二线，为什么要有一线、二线、三线之分？是因为效率、成本、专业使然，一个有几千人使用的应用系统，经常会有各种各样的问题，有用户的操作不熟悉，有时服务器宕机，有时软件出现BUG，现在随着技术的发展，象主机层与软件层已形成各自的专业了，所以公司需要找两个能承担服务器维护与软件维护的人，此时由于专业的不同带来了分层，这时如果每天总有10几个事件是用户的配置或操作问题，此时让负责服务器运维的系统管理工程师与软件开发的开发工程师去负责处理，他们的工作负荷已很大了，需要去再加一名工程师协助，从经营的角度，我们需要找一个怎样的人呢？找系统管理工程师与软件开发工程师，成本比较高，而且这样的专业人员不愿意长期从事这种简单的事务工作，这些基本的维护工作对技能要求也并不高，此时我们很容易就会想到找给这个项目配备一个普通的工程师，这样就有了3个人，职能不一样，在流程中根据与客户的远近我们叫他们一线、二线、三线，如果还有更多层级，以此类推，这样做的也是更有效率的，因为相对简单的问题我们可以更快速的帮客户处理提，提升了解决率。同样类型的服务项目的一线应该是一致的，按这样的方式去配置每一个项目的资源，岗位的标准化难度比较大，不处理好容易导致整个组织的岗位出现混乱。
当支持小组接到服务台的事件单后，会开始按照事件的优先级进行处理（1级事件最优先），一般而言是一线首先处理，在处理过程中可能需要联系客户，如果一线无法完成处理或判断此事件处理属于二线或三线的职责范围，则将事件单分派给二线或三线进行处理，此时事件的信息会不断丰富，一、二、三线根据各自的职责定义进行事件处理，事件单在这些不同的职能组之间的流动要非常顺畅，大家需要把各自的处理方法或步骤记录下来，这个过程如果没有工具软件是很困难的，如果在事件处理过程中，发现需要进行变更，此里支持小组需要发起变更申请，比如如果一个事件发现必然要对服务器进行重启，而服务器重启又是属于变更控制的范围，此时需要发起变更进行控制，所以一个事件单中可能包含一个变更单。事件处理以时间为第一考虑，即要尽快的恢复业务或满足客户的要求，故障的根本原因是不是找到，并不是事件流程的责任，但支持小组需要判断是不是需要创建一个问题单，去调查根本原因或寻求根本的解决措施。
有一些事件处理时，与客户的预约很重要，比如客户的电脑出现一些问题，提前与客户约定一个时间去处理很重要，一方面是客户不是时时刻刻的方便配合做事件处理，另一方面是让客户清楚我们在怎么安排处理他的问题，支持小组在处理事件过程中，如果无法在规定的SLA内完成，需要升级到事件经理处（服务经理），以谋求更多的资源介入，同时需用向客户做出解释与说明，很多细节问题出在与客户的互动过程中，所以凡是与客户直接联系的人员，进行一个行为规范是必要的，如何去跟客户打交道与交流，注意些什么，这些可以建立一些子规范，有一些特别的事件，比如投诉或重大故障，可能需要设计特别的子流程进行规定，这些都要根据实际的业务情况进行。还有一些事件处理规范，可能是根据项目不同进行设定的，这类规范则需要在《项目设计书》的进行约定，其适用范围仅仅是针对某个特定的项目。
1.4.2.5 用户确认
事件完成处理后，需要与用户进行确认（不是每一个事件），看业务是否恢复，或需求是否得到满足，这样的做法会增强用户的满意度，如果用户确认问题并没有得到解决（报表数据还是存在错误），或需求并没有得到全部满足（网络权限开通没有达到作业目的），事件需要继续进行处理，如果事件得到用户确认完成，此时则视为事件得到解决。在与用户确认时进行对故障原因进行适当的解释，会很大缓解用户的情绪，与客户做更好的服务沟通是很有实际意义的，但这些动作需要很好的设计在工程师的作业规范中，越偏技能专业的服务岗位越容易忽视用户的心理诉求。当支持小组的事件得到用户确认后，对事件信息进行检查与修订，以保证分类分级正确、描述清楚而工整，然后将事件提交给服务台进行处理。
1. 4.2.6 事件回访
回访的作用在于了解支持小组的处理是否规范，调查用户在事件处理后的实际感知是如何的，采集用户的意见进行分析改进。事件得到解决后就回到服务台进行回访，并非每一个项目的事件都需要回访，并非一个项目的每一个事件都需要回访，一是考虑到成本问题，二是考虑到实际意义，每一个事件都需要进行回访，将花费比较大的服务台成本，对于一个2分钟就完成处理的咨询事件，去进行一个电话回访的意义很低，同时现实作业中许多事件不是由用户触发的，也无法进行回访，事件的回访要智能化，这在没有工具软件时很难实现，通常来说，故障类的事件回访比例要比咨询类事件的回访比例要高一些，一级事件的回访要比五级事件的回访比例要高一些，一个很少报障的人的事件回访比例要比经常报障的人的事件回访比例要高一些，违反SLA的事件比没有违反SLA的事件的回访比例要高一些。当机械式的进行电话回访时，会让用户觉得是骚扰电话一般，比如一个用户一天申报3个事件并都处理完成了，此时需要进行3次电话回访同一个人吗？，当定义一个项目的事件回访比率要达到50%时，需要采用一个算法自动标记出哪一些事件需要进行回访，由于并不是每一个回访都能达到目的，所以还需要定义一个有效回访比率，即回访过程中完成了采集所需信息的事件。
对于满意度的测量，许多公司是一年或半年进行一次客户满意度调查，实际上事件回访过程测量出的满意度可能更具实际意义也更具指导及改进意义，事件回访会对支持小组形成一种强大的约束压力，从而使支持小组必须与用户的目标保持一致，这种融入作业过程的监控是最为有效的，这样满意度的实际情况是随时随地就可以知悉的，事件回访所采用的话术很重要，简洁而有效是很重要的原则，怎样去采集到客户真正的声音，是服务台要研究的最大课题，对于服务台而言话术是一个很重要的课题，不但要成熟，而且要新鲜，当你是用户一年到头总是听到同样的话同样的腔调，难免心生厌烦，所以针对回访的部份，是完全可以考虑周期性的进行话术更新的。
在回访时，服务台与用户取得联系，首先要核实事件是否真正解决，然后是请客户对事件处理过程做一个评价，一般是以5分制进行评价。如果发现事件并没有得到解决需要将事件重新派给支持小组，这种情况一般是视为违规了，可以由服务台直接将事件升级给事件经理（服务经理），或将事件重新分派给最后一个处理者。如果支持小组的行为规范比较详细了，在事件回访时需要设计一些针对支持小组的作业规范的调查，比如如果我们在程序中定义了，去客户现场之前必然与客户进行预约，以避免打扰客户的业务及无效的现场往返，此时话术中就可以询问客户工程师去现场前是否有预约，象海尔这些电器的售后维护，工程师上门需要套上鞋套才能进入客户的家中，针对这一点，同样是可以回访调查中一个点。在回访过程中如果客户有什么意见需要进行详细记录，在回访过程中客户如果反映一个新的需求或问题，此时服务台需要创建一个新的事件单进行处理，如果客户明确表示对本次事件的处理不满意，此时服务台需要创建一个新的事件单（投诉）进行处理。服务台回访的环节是最后的检查环节，除去真正意义的回访外，对事件单的质检同样是这个环节需要着重考虑的一环，对于事件信息模糊简单，记录不合格、分类分级不正确的事件单可以退回支持小组进行重新整改提交，在一些由于各种原因不进行用户回访的组织，可以将此部份的用户回访弱化为事件质检环节。
1.4.2.7 事件关闭
事件回访结束后，事件可以进行关闭，此时事件信息将被锁定，一个全面的事件档案将形成，它可能包括：事件信息（事件基本信息、处理动作、处理时间、解决方法、回访信息）、录音信息（申报、回访）、关联单据（问题单、变更单）、关联配置（CI信息）、升级信息（因何原因何时升级给何人）、关联附件（图片、文档）、SLA信息（需遵守的SLA条目、实际达成情况）。当个事件完成处理，且记录完备无误时事件才能关闭，此时一个事件才真正彻底结束。
1.5 流程管理
1.5.1 流程政策
u 服务商必须向用户提供单一联系点
u 先恢复业务后才考虑根本原因与根本措施
u 所有事件必须记录
u 重大事件需要进行独立分析与报告
u 事件违反SLA，必须回访
u 信息安全事件需要标识区分
u 事件处理过程如果涉及变更，必须遵从变更管理规定
u 。。。。。
1.5.2 触发条件
u 用户提交事件申告
u 支持小组发现服务异常
u 监控系统发现服务异常
1.5.3 关闭条件
事件解决得到用户确认
事件解决经过服务台确认
1.5.4 输入信息
事件申告人信息
事件信息
1.5.5 输出信息
事件档案
事件分析报告
1.5.6 流程要点
派单机制
当具有完备的一、二、三线建制时，派单的机制要明确化，不同的服务型态或组织类型，可能出现不同的派单机制，在上述的事件流程中，只是一个逻辑的流程示意，由服务台将事件单分流给一线，一线给二线，二线给三线，但现实中，有可能出现服务台直接派单给二线甚至三线的情况，也有可能出现一线直接派单给三线的情况，同时在事件处理过程中，二线、三线可能需要完成自已职责范围内的作业，再返单给一线进行最后的处理，这些由于无法很好的表达在流程图中，只能依赖文字说明了。如果服务台清楚支持小组内部的职能分工，并且清楚事件应归属几线的职能范围，由服务台直接派单组二、三线并非一定不合适的，但这里可能导致的一个问题是容易弱化一线的功用，后端高成本的资源的调度不受控制，而且服务台一般情况下难以做到这种层面的分析，所以由一线进行项目内所有事件的分析分流是相对合适的，由一线直接调度二线与三线资源，让一线成为类似战场中的前线人员的角色，信息最为集中的支持小组的一线人员，调度意味着权力，信息决定权力。这样的模式会比较有效率，同时避免服务信息的分裂。
升级机制
要考虑好什么情况下需要进行升级，职能升级已根据支持小组的一线、二、三线的定义做了解决，所以可以基本可以脱离升级的范围，而转化成一种正常的作业机制了，此处的升级更多是指什么情况下需要服务经理的介入，自动的机制比某种一事件一发生就通知（重大故障），一个事件长时间没有人处理、长时间没有得到解决、经过了太多次的分派，这些情况可以考虑升级到服务经理，详细的时间是多少，根据SLA中约定的时间的百分比进行配置是比较好的，也可以直接根据实际的项目情况设置具体的次数与时间，这些计算比较复杂，升级的方式可能考虑邮件、电话、短信等等。
瓶颈监控
事件容易出现瓶颈的地方有服务台的呼入、回访，可以从客户电话的丢失率去判断呼入的瓶颈，可以从待回访事件的积压数量与时间去判断回访的瓶颈，从一线、二线、三线的待处理事件的积压数量与时间可以看出事件在支持小组内部的瓶颈，这些点需要有人进行监控，一般而言由服务经理监控一、二、三线的瓶颈情况，服务台经理负责监控呼入与回访情况是比较合适的。发现这些瓶颈的存在就需要进行干预以缓解被动局面。
事件分析
要考虑对事件进行日、周、月、季、年的分析，可根据事件的基本要素，展开多个视角的分析活动，根据事件的基本要素，可以建立一个分析的矩阵：
根据这个基本的矩阵可以建立各种简单的分析与复杂的组合分析，比如看趋势情况，可以从各种角度，看事件等级、事件分类、用户部门等等，看每天或每周的变化，还可以看到底每个部门的事件类型或等级的分布特点。这是从事件数量层面去做的分析活动，还有从SLA层面去看SLA达成情况，或满意度情况，组合基本是无限的，在此就不一一叙述了。
意见分析
在事件过程中采集到的客户意见，需要进行规律性的处理，比如每天或每周进行汇总，各个项目的服务经理需要进行分析，并进行相应的处理，这其中可以找出大量的隐藏的问题与改进点，所以改进事宜可以通过服务改进计划进行管理。
职能分工
资源利用率最高的情况是服务台、一线、二线、三线的职能是动态的，当任何一个环节出现瓶颈时，可以调动资源进行补充，比如突然有一天事件大量爆发时，如果服务台继续要保障事件信息采集的质量，必然导致大量客户呼入丢失，此时是直接降低事件信息采集的质量，还是把当前相对空闲的一线调到服务台支援呢？同样的问题可能存在于一线与二、三线之间，这是一种情况。另外一些职能活动可以层层上浮，比如一种数据错误，需要三线写语句进行修复，这种事件处理方法三线可以设定的一个处理方案，交由一线执行，或者一线经常需要处理一些简单的咨询类事件，此时一线可以将此类事件的处理，对服务台进行培训，由服务台进行，这些情况没有绝对的硬性规则，但必须要考虑这些所谓灵活的做法带来的长远问题，企业的活动在许多环节其实是效率极其低下的，对于IT服务而言，过度的压榨人力追求短期效率，很可能是不合适的，比如三线的一个数据修复方案，由一线执行后，谁去控制这个数据修复方案本身的变更？，如果以后数据结构改变，你相信有人会记得这一次数据库变更会影响到哪一个一线的操作方案吗？再比如让服务台去处理简单的咨询问题，如果谁去关注这个答案本身以后是不是长久合适的？一线会不会因此认为服务台长久的就应该处理简单咨询问题呢？你能想象服务台的所有员工可以回答几十个项目的咨询问题吗？。这些复杂的业务现实，需要基于清醒的长远考虑，不成熟的应急措施只是解决了眼前的具体的问题，去带来长久而重大的问题。要对任何职能分工调整保持高度的敏感，严格来说，让服务经理去考虑这个问题是不现实的，这是整个体系要特别注意控制的事情。
1.6 流程关系
1) 服务级别管理
事件的范围与时间约束全部来自于服务级别管理的输出信息，服务级别的执行情况主要依赖于事件管理的信息输出。
2) 问题管理
问题的来源是依赖于事件管理的信息，事件需要调用问题管理的相关信息（知名错误、解决方案）。
3) 变更管理
事件有可能导致一个变更的产生，在体系设计时甚至可以定义成事件是变更的唯一来源。
4) 可用性管理
可用性管理约束了事件需要记录服务不可用的相关情况，即可用性指标是通过事件管理的输出计算所得。
5) 持续性管理
持续性管理中的灾难恢复方案为事件所用，灾难是事件的一部份。
6) 能力管理
能力监控发现的异常是事件的来源之一。
7) 信息安全管理
信息安全事件属于事件的一部份。
8) 配置管理
事件管理需要调用CMDB的信息，以便进行事件定位，同时事件管理可以在一定程度上校验CMDB的信息精度。
1.7 流程绩效
1) SLA达成率
2) 客户满意度
3) 服务台电话丢失率
4) 服务台有效回访率
5) 服务台平均回访时长
6) 一线事件解决百分比
7) 二线事件解决百分比
8) 三线事件解决百分比
9) 一线平均响应时长
10) 二线平均响应时长
11) 三线平均响应时长
12) 事件平均处理时长
顶起顶起顶起
页:
[1]