中国人民大学在事件管理的设计实践中，特别强调了以下几个方面：

第一，事件往往表现出数量多、处理繁琐的特点，特别强调合理清晰的分类、分级、分权、分角色。

第二，事件管理作为一切流程的基础，是服务受理、处理、反馈、跟踪的一条龙过程，一头连着用户，一头连着服务人员，一头连着技术支持人员，特别强调过程的控制以及界面的实现。既要保证过程控制的权限粒度．又要避免繁杂，特别是技术支持人员之间的传递和沟通要灵活。界面强调清晰和简约，保证效率。

第三，事件管理是服务级别管理、业务关系管理、问题管理、容量管理、可用性管理、配置管理的集中展现，又是各流程绩效考核的参考，事件管理中表单的内容设计要综合方方面面。

基于以上考虑，我们主要完成了六个方面的设计：事件的分级分类定义、流程设计、角色和权限设计、流程执行准则设计、流程关联准则、事件管理统计报表和绩效指标。

1．事件的分级和分类

为了使繁杂的事件易于分辨，需要对事件进行分类。同时，为了保证服务级别和事件处理效率，需要将有限的资源合理配置到每个事件中，因此，必须对事件进行分级中国人民大学在事件管理的实践中，根据自身业务职能和机构组织的特点，将事件分为三类：故障、服务请求、重大信息事件。其中，故障分为l3个二级子类，服务请求分为6个二级子类21个三级子类，重大信息事件定义了17类。特别是服务请求的范围，涵盖了所有业务职能，使得事件管理成为所有服务受理和处理的统一平台图1为用户根据事件的分类建立新事件。

优先级即处理事件的先后顺序。通过优先级，支持人员可以判断、协调资源分配，用户可以明确解决时间，从而保证服务响应节奏和服务成本。

影响度：衡量时间对业务的影响程度，主要参照影响范围、数量和重要程度。

紧急度：主要根据业务对IT需求和依赖程度以及可以忍受的时限。

中国人民大学综合考虑了事件的影响度和紧急度．为事件设定了三级优先级，并分别定义了响应时间、解决时限和升级准则。

2．事件管理设计

(1)流程设计

事件管理涉及的人员角色多，处理过程分支多。我们共设计实现了7流程，包括：1个主流程和6子流程，包含记录分类、一线解决、二线解决、申请事件经理协调解决、关闭事件子流程以及重大信息事件处理子流程。图2为事件管理的综合流程。

(2)角色和权限设计

流程的执行涉及多个部门、多项职能，采用基于角色的灵活方法才能合理清晰地设计出流程中的角色和权限，才能保证流程成功运行。在事件管理流程中。我们设计了6个角色并赋予每个角色不同的权限。其中包括：事件管理流程负责人、事件管理经理、二线工程师、一线工程师、服务台和用户。

事件管理流程负责人只在重大信息事件处理中负责总体协调、向上级报告或者申请事件的管理升级。事件管理经理：事件经理对于流程富有主要责任，其目标是为事件的技术升级做好预备工作，以避免事件的管理升级。监控流程的效果和效率、改进流程建议、协调内外资源。

一线、二线工程师主要是处理事件并记录处理结果、申请技术升级、关联其他流程等。二线工程师角色实际上还包含两类角色：工程师和科室主任，科室主任也承担工程师的角色来处理事件，同时，负责事件的调查分析、技术升级等。

服务台主要是接收、记录、分派、追踪、关闭。设计的核心是针对状态改变实施控制的。所有表单的可写字段的“读”和“写”权限赋予该流程中的所有角色。每个状态的“改变状态权限”只赋予该状态的负责人这样的设计主要是依据我们的机构职能划分、人员岗位职责划分以及人力资源配置的现实状况，在有限的资源配置和成本中实现最合理的响应和处理。

事件管理中涉及受理、分派、处理、递交处理、升级、审批、报告、反馈、关闭等多个执行环节，环环相扣地推动事件管理的开展。其中一个环节的延误或停滞或错误都直接影响事件管理效率，甚至服务级别的不符合。因此，我们在几个关键环节中特别制定了执行准则，保证各个角色在每个执行环节中“有法可依”。

事件管理流程的执行准则设计包括：责任制准则、事件升级准则、事件分派准则、事件关闭准则、重大信息事件报告制度。在此重点阐述责任制准则、分派准则和升级准则。

1)责任制准则

核心是事件统一受理和首问负责制。即：所有服务须经服务台统一受理，采用首问负责制，负责跟踪事件处理的全过程直至解决、关闭。

2)事件分派准则

核心是将事件分派到合适的支持团队来解决，支持团队不可拒绝接受分派。如果被派事件不属于本团队支持的专业范围或者自身能力无法处理．可以递交给其他相关支持团队进行解决，但必须注明原因。

3)事件处理升级准则

事件的处理不能在规定的时间内解决，就要进行事件升级，它可以发生在处理过程的任何时间和任何支持级别。

简单地讲，事件升级分为技术升级和管理升级。技术升级：需要更多专业技能、处理权限、更多时间和人力投入来参与事件的处理。管理升级：需要更高级别的管理机构参与解决。

我们将事件技术升级设计为两部分：一是优先级、二是处理资源。优先级主要是针对重点用户、重要类别的事件，处理资源主要是针对事件的复杂程度。服务台、一线、二线工程师和事件管理经理都有事件升级权利。

要进行管理升级的事件被设计为需要学校领导参与协调处理的事件，例如：重大信息安全事件。只有事件管理流程负责人有权进行事件的管理升级。一般先考虑技术升级，尽量避免管理升级。

特殊的、重复发生的事件，引发了问题的建立，触发问题管理流程。事件管理和问题管理一并作为解决流程．有着一致的目的——降低故障发生率．减少由于系统故障所带来的业务损失。但是没有一致的目标。两者的本质差异在处理的手段上。问题管理以找到并解决故障根源为手段．更关注故障发生的深层次原因以及能否根除故障的隐患，而不太关注解决恢复时间。

为尽快恢复服务，事件管理鼓励采用临时方案、变通方案．但会掩盖问题。问题管理会依据事件管理中收集的信息，查处潜在错误，提供与特定问题相关的信息、已知错误、应急措施以及补救办法为事件管理提供帮助。

2．变更管理和配置管理

事件处理过程中，常常会通过实施变更来解决，如更换设备。为事件管理提供预定变更及其状态信息有助于解决事件，但是错误的或包含错误的变更也可能引发事件。

在配置管理流程的实践中，我们有很多困惑和争论。其一是系统和设备的配置管理与运维监控存在矛盾，接口不清晰，无法实现；其二是配置管理能给我们带来哪些效率、效益和帮助。

笔者很长时间不能理解图3中通过CI如何将事件管理与配置管理关联。其原因是笔者对配置或者CMDB理解的肤浅。此处的配置远大于系统管理中的配置概念。CMDB可以为事件做定位，例如：事件发生在什么系统中、什么型号规格的设备、软硬件指标、运行参数、设备的物理位置、逻辑结构等。设备的配置信息与事件建立链接以提供相关错误信息。CMDB还可以帮助评估事件的影响度和紧急程度。因此，无论是事件管理还是配置管理．在关联关系的实践中还有不少有待我们思考和改进之处。

五、事件管理的目标

事件管理是中国人民大学体系实践的第? 步，通过实施事件管理流程和服务台，我们的IT服务管理改变了原先混乱松散状态，进入有流程、有管理、有规范状态。

(1)故障和服务请求的全面受理，事件处理流程规范，处理全过程有记录，处理状态和结果可追踪。

(2)通过事件处理记录，验证和考核服务指标，特别是响应时间、恢复时间可测量判断是否符合服务级别要求。

(3)IT工程师的工作量考核一直是难题，事件处理记录可以辅助考核工作量。

(4)设计统计指标项，例如：事件总数、各科室事件数、重大事件数、各类事件数、按优先级计算的解决时间、事件解决数占比、在SLA 目标内解决的事件占比、员工平均解决事件数、非现场解决事件数、一次分派正确率等，辅助分析，改进流程、方案和服务、修正服务级别。

六、结束语

理论上将事件管理流程实现的关键成功因素归为以下四个方面：及时更新的配置管理数据库，知识库，适当的支撑工具，与服务级别管理相关联的合适的优先级和解决时限。导致失败的因素包括：用户或支持人员故意避开流程，事件处理超载和堆积，事件升级、定义和协议不清晰，缺少管理层承诺，升级的增加，执行成本增加等。由此看出，合理的设计和规范的执行是成功实践保证。

随着体系的运行，各流程中数据的积累，如何通过变更管理对事件处理中的过程进行控制，通过配置管理提供的信息定位，通过问题管理提供的知识库和问题预测．使事件管理的效率、效果得到提升，使其进入一个良性推动的闭合循环状态，能够形成主动预防事件的模式，是我们下一步思考和实践的目标。