事件管理流程设计样例

/信息中心事务管理流程业务需求文档日期:2012-11-26文档版本:V0.1

书目事务管理流程业务需求文档 1

介绍文档简介本文介绍XXXX信息中心事务管理流程和对工具的业务需求，供参和信息中心IT运维管理系统事务管理流程模块的开发和测试人员运用。文档目的为了保证即将建设的“IT运维管理系统”符合XXXX信息中心建设全省一体化协同运维体系的要求，本文对“IT运维管理系统”中的事务管理模块的业务需求进行细化。事务管理流程以确保在故障发生后尽快地复原服务，减小对业务的影响。事务管理流程关注快速地解决故障现象而非查找故障背后的根本缘由。前提和假设读者应当了解ITIL，并对事务管理流程具有基本的技能。文档结构本文由以下几个章节组成：第一章，“介绍”，描述了本文的适用对象、组织，以及相关术语。其次章，介绍“事务管理流程”的业务逻辑，定义了总体流程，具体流程，流程步骤、角色及职责、业务规则、事务单代码、流程衡量指标。第三章，介绍“事务管理流程”的工具功能需求以实现其业务逻辑，从工具用户特点、工单流程、和其他流程关系和流程评估和改进四个方面阐述。第四章，介绍服务台结构，省市服务台逻辑及联动模式，及为实现该种模式服务台业务逻辑的工具功能需求。术语为便利相关人员对事务管理流程的理解，下表对事务管理流程中涉及的术语进行说明。名词说明ITIL(ITInfrastructureLibrary)是英国政府在1987年制定的有关IT服务管理的最佳实践，现已成为事实上的IT管理标准。事务管理流程ITIL流程之一，事务管理负责处理IT事务和用户恳求。它的目的是尽快复原被中断或受到影响的IT服务，是以快速解决故障现象为目的，而不在于查找根本缘由。IT服务XXXX省局信息中心和地市信息科供应应全省税务系统业务部门的IT支持服务内容。事务不包含在标准服务操作之内，导致或可能导致服务中断或服务质量降低的事务。范围包括XXXX信息中心维护范围内的全部和IT基础架构和应用系统相关的故障、询问和服务恳求。事务单事务在流程管理系统中的数据记录。解决方案是指针对某一个或某一类已找到根本缘由的问题，提出的解决问题的最终方案。变通方法（也称临时措施）是指解决事务的临时修复方法或技术，目的是运用替代措施短暂复原SLA约定的服务，避开事务接着对客户的业务产生影响，该事务的永久解决措施有赖于对该事务潜在问题的最终解决。IT用户XXXX省局信息中心和地市信息科的服务对象。监控服务台监控服务台是信息中心为用户供应服务的唯一接口，是全省一体化协同运维体系中的重要组成部分。监控服务台的主要工作内容是记录和受理事务内容，通过学问库供应初始支持，或通过功能型升级到对应的运维组帮助用户复原到正常工作状态。事务分析员进行事务处理的支持人员，通常对应信息中心的二线或三线支持人员。事务经理负责协调和管理事务管理流程的各项活动。运维办事务经理流程全部者，负责对流程的审计和评估，持续改进该流程。CIConfigurationitem配置项RFCRequestforchange变更恳求单CMDB配置管理数据库

事务管理流程流程概述XXXX事务管理流程包括地市事务处理和省局信息中心事务处理两个部分。整个流程、执行步骤和各步骤执行的依次参见流程概览图。这个流程旨在确保全省全部和省级集中信息系统相关的事务得到有效记录和跟踪，使事务能在最短的时间内得到解决，并为问题管理等其它服务管理流程供应相关信息。要达到这个目标的重点在于：各地市信息科首先对事务进行有效记录和过滤，假如本级不能处理，则确保升级至省局的事务单信息完整和精确；地市和省局信息中心服务台精确分类分级事务；精确的将故障单分派给后台技术支持组或人员；确保用户对于事务的解决方案是满足的。事务管理流程由事务驱动，关注事务的响应速度以尽快复原业务运营。流程步骤描述事务记录（地市）描述:事务的记录是事务管理流程的起点。全部用户报告或系统产生的IT事务都必需从这个步骤起先。该步骤的目的是快速、精确地探测和捕获到在IT生产环境中发生的错误。除此以外，该活动也是其它用户相关恳求的入口，诸如信息询问、服务恳求。本步骤的重点是精确、完整地采集创建一个事务单所需的必要信息。流程主要内容:输入：任务：输出：事务驱动输入：来自于用户的恳求（提交方式：电话、邮件、Web）运维人员主动发起的事务0.11发起恳求0.12识别并验证用户信息0.13信息充分性推断0.14进一步供应信息0.15新事务推断0.16更新相关事务单0.17记录新事务单已创建的事务单已更新的事务单过程环节:0.11发起恳求执行者：用户用户向所在地市信息科服务台提交事务恳求。用户提交事务恳求的方式可以有多种：通过电话向服务台提交恳求；通过web网页形式向运行部提交恳求；通过电子邮件提交恳求；0.12识别并验证用户信息执行者：地市服务台接受用户的事务报告。提示：建议通过统一工作平台用户管理，建立客户信息库以提高识别和验证效率；可运用电话号码等作为用户的唯一识别；在提示：建议通过统一工作平台用户管理，建立客户信息库以提高识别和验证效率；可运用电话号码等作为用户的唯一识别；在发觉现有客户信息库不完整时，服务台须要刚好更新；用户姓名（必填）用户标识（是否为VIP用户）电话号码（手机）（二者必填一项）分机号码员工当前所在地点所属部门/所属办税服务厅地址检查该用户是否属于服务对象的范围。如有必要，更新用户资料，如联系方式。0.13信息充分性推断执行者：地市服务台对于事务恳求，服务台须要推断用户供应的信息是否足够用于后续供应支持，快速复原服务。假如足够，则进入环节“0.15新事务推断”假如不够充分，则进入环节“0.14进一步供应信息”0.14进一步供应信息执行者：用户用户依据服务台要求补充相关信息；0.15新事务推断执行者：地市服务台依据用户供应的事务描述信息，推断恳求是否为新的事务。新的事务，进入环节“0.17记录新事务单”原有的事务，进入环节“0.16更新相关事务单”0.16更新相关事务单执行者：地市服务台对于原有的恳求，依据用户所供应的描述信息，对之前由该服务恳求所产生的工单进行进一步补充。补充后的工单仍按原有工单流程进行处理。0.17记录新事务单执行者：地市服务台创建事务恳求，生成事务单，进入后续流程。在事务单中至少须要录入以下事务信息，以下信息须要具体而精确：事务单号（系统自动产生）事务的标题事务的具体信息，包括事务可能造成的服务影响，影响部门等。可能的描述事务现象的附件事务发生的时间事务单创建时间（系统自动产生）事务来源事务报告人信息事务单假如是来自用户，则须要填写用户信息，至少包含以下内容：用户姓名用户标识（是否为VIP用户）联系电话/手机所属部门/所属办税服务厅假如该事务单是由运维人员主动发起，运维人员作为事务提交者其相关信息由系统自动填写，至少包含以下内容：运维人员帐号或姓名运维人员联系电话事务分类分级和初步支持（地市）描述：该步骤的目的是推断事务级别和分类，随即在现存的解决方案中查询和该事务相匹配的方案，或依据个人阅历尝试在线对事务进行处理。若没有找到合适的解决方案或变通方法或须要离线对事务进行处理，该事务须要安排给二线具有合适技术技能的事务分析员。该步骤的重点是正确地安排事务，以避开后面对时间的奢侈。流程主要内容:输入：任务：输出：来自于步骤0.17新记录的事务单0.21分类分级0.22初步支持0.23能否解决问题0.24服务台分派事务单3.25推断是否接受事务单3.26受理事务单已分派的事务单表格STYLEREF1\s3SEQ表格\*ARABIC\s14受理和初步分析内容过程环节:0.21分类分级执行者：地市服务台确定事务等级；（具体请参见2.4.7）依据事务影响度和紧急度，确定优先级。（具体请参见2.4.8“优先级规则”）。确定CTI分类（具体请参见2.5.4“事务分类”）。假如是省级集中信息系统类事务单，则需标注。0.22初步支持执行者：地市服务台在事务管理中查询已经存在的解决方案/变通方法，或进行学问库有效学问的匹配进行在线事务解决；依据事务记录人员所拥有的技能尝试确定“解决方案或变通方法”，进行在线事务解决；假如可以解决，转至步骤IM-05“事务单关闭”中的步骤0.51。假如不能解决，转至步骤0.24“分派事务”。0.24分派事务单执行者：地市服务台依据事务分类不同，把事务分派给合适的事务分析员；若地市二线技术人员认为事务单派转不合理，则事务重新进入“分派事务”环节。0.25二线受理事务单推断执行者：地市二线地市二线事务分析员接到事务后，推断事务是否分派正确，即是否本人的工作职责和技能范围。假如是，则转步骤0.26。假如不是，说明理由，并须考虑是否须要对事务进行重新分类，以帮助服务台在下一次分派时更精确派单。流程返回步骤0.24“分派事务”。3.7受理事务单执行者：地市二线假如被分派的事务分析员确认该事务单分派正确，则接受该事务单，进入步骤0.31“故障分析”。二线受理和诊断（地市）描述:这个步骤的目标是对事务进行分析以便提出解决方案，不同技术领域的事务分析员将会参和到该步骤中以寻求一个事务解决方案，在有必要时会升级至省局信息中心以便快速解决复原事务影响。流程主要内容:输入：任务：输出：来自于步骤“0.26受理事务单”0.31收集相关信息0.32是否重复事务0.33关联至主事务单0.34进行事务分析0.35找到解决方案0.36升级至省局信息中心针对该事务的解决方案升级至省局信息中心的事务单过程环节:0.31收集相关信息执行者：地市二线二线对事务进行处理，并查找可能对事务处理有效的相关信息。该处理过程一线往往脱离开流程系统进行，在得到相关信息后，重新登录到流程系统，并将相关信息记录在事务单中。0.32是否重复事务执行者：地市二线找寻有相像症状(即由同一缘由造成)的事务:如找到类似的事务，即进入步骤0.33“关联事务到主事务”，假如在事务诊断过程中发觉匹配错误，可以取消此关联。假如没有找到，进入步骤0.34“事务单分析”0.33关联到主事务单执行者：地市二线推断当前事务单所描述的现象和之前未解决的事务是否有相像：假如确认是重复工单或主事务驱动工单，将新的事务单关联到原主事务单原有事务单被标识为“主事务单”原有事务单关联事务单数加一新建事务单出现在原有事务单重复工单列表中新事务单状态将随原有事务单状态的更新而更新，不单独进行处理。0.34事务单分析执行者：地市二线检索学问库查询可能的解决方案，查找的途径包括但不限于：通过对已记录激活和未激活学问记录进行查询通过以往已关闭事务单中的解决方案或处理过程进行查询通过其它公共的资料信息进行查询依据专业技术阅历找寻解决方案或者变更方法。经分析如发觉解决方案，转到步骤“0.41解决和复原”如未发觉解决方案，在转到步骤“0.36升级至省局信息中心”。假如在事务复原和解决阶段未能复原业务，或者在事务关闭阶段用户不满足解决方案，则需返回“0.34事务单分析”，由同一名事务分析员接着进行处理。5.8升级至省局信息中心执行者：地市二线假如当前地市事务分析员由于某些缘由不能解决该事务，须要将事务升级至省局信息中心监控服务台。（只限于省级集中信息系统类事务单）解决和复原（地市）描述:该步骤尝试运用解决方案和变通方法来解决事务。某些状况下，需引入变更管理来批准评估实施步骤。对于某些事务，即使得到了解决，仍旧须要创建问题单以进一步找寻其根源。流程主要内容:输入：任务：输出：来自于步骤“0.35找到解决方案”0.41实行复原操作0.42验证解决方案0.43服务是否复原0.44是否进行根源问题分析0.45创建新的问题并和事务关联复原受影响的服务创建根本解决该事务单的问题单过程环节:0.41实行复原操作执行者：地市二线 由二线工程师负责实施以确定的解决方案，以复原受影响的服务。0.42验证解决方案&0.43服务是否复原执行者：地市二线 验证解决方案的实施是否有效：对于方案无效的状况，转到子流程“0.34进行事务单分析”。对于方案有效的状况，转到子流程“0.51事务关闭”以及活动“0.44是否进行根源问题分析”0.44是否进行根源问题分析&0.45创建新的问题并和事务关联执行者：一线推断是须要对以解决的事务进行根源问题分析：对于须要分析的状况，转到活动“0.45创建新的问题并和事务关联”，针对该事务单新建一个问题单或关联到已有的问题单上。对于不须要分析的状况，转到步骤“0.51事务关闭”事务关闭（地市）描述:这个步骤确保用户对事务的处理状况感到满足。事务单的信息是正确、完整的，以便于以后生成报表。流程主要内容:输入：任务：输出：来自于步骤“0.43业务复原”0.51检查事务记录0.52是否须要和用户确认0.53和用户沟通0.54供应反馈信息0.54用户确认事务是否解决0.56关闭事务单已关闭的事务单过程环节:0.51检查事务记录执行者：地市服务台对于用户报告的事务单，服务台检查系统中事务单记录的完整性，对于不完整的记录进行补充。0.52是否须要和客户确认&0.53和客户沟通执行者：地市服务台服务台依据事务性质，推断是否须要和用户沟通事务的处理结果，以便确认事务的真正解决。如确认须要告知用户事务处理结果的状况，转入活动“0.53和用户沟通”，沟通形式包括但不限于：系统通告，短信告知，邮件通知，电话通知等方式。如确认不须要告知用户事务处理结果，转入活动“0.56关闭事务单”0.54供应反馈信息执行者：用户用户在接受服务台通知后，向服务台供应着呢对事务处理结果的反馈信息。0.55用户确认事务是否解决执行者：地市服务台服务台依据用户反馈确定事务是否被胜利解决：如确认事务未解决的状况，转入子流程“0.34进行事务单分析”，重新查找事务缘由。如确认事务已解决的状况，转入活动“0.56关闭事务单”0.56关闭事务单执行者：地市服务台依据关单原则对事务单进行关闭。事务受理和记录描述:这个步骤是XXXX省局信息中心事务管理流程的起点。全部地市升级至省局信息中心、IT工程师主动报告或监控平台产生的IT事务都必需从这个步骤起先。该步骤的目的是快速、精确地探测和捕获到在IT生产环境中发生的错误。本步骤的重点是精确、完整地采集创建一个事务单所需的必要信息。流程主要内容:输入：任务：输出：事务驱动输入：来自于地市信息科升级的事务单工程师主动发起的事务通过监控平台发觉的告警事务其他信息来源来自失败的变更实施1.1识别并验证事务单信息1.2信息充分性推断1.3进一步供应信息1.4新事务推断1.5更新相关事务单1.6监控告警1.7记录新事务单已创建的事务单已更新的事务单表格STYLEREF1\s3SEQ表格\*ARABIC\s12记录事务环节的内容过程环节:1.1识别并验证事务单信息&事务单信息充分性推断执行者：省局监控服务台对地市升级的事务单信息进行识别和验证，重点关注如下几点：用户基本信息是否完备；事务描述是否清楚，是否供应截图；事务分类分级是否合理；是否有对应“内部呈批表或加盖公章”；要求维护参数表代码表，确认是否有供应EXCEL格式的内容。监控服务台须要推断地市升级的事务单信息是否足够用于后续供应支持，快速复原服务。假如足够，则进入环节“1.4新事务推断”假如不够充分，则进入环节“1.3进一步供应信息”1.3进一步供应信息执行者：用户用户依据服务台要求补充相关信息；1.4新事务推断执行者：监控服务台依据地市升级的事务单描述信息，推断恳求是否为新的事务。新的事务，进入环节“1.7受理新事务单”原有的恳求，进入环节“1.5更新相关事务单”1.5更新相关事务单执行者：监控服务台将该事务单关联到原有事务单。可对主事务单进行进一步补充相关信息。关联后的工单仍按原有工单流程进行处理。1.6监控告警执行者：监控工具/工程师监控平台自动触发的，事务告警信息是通过系统接口自动载入的事务。由工程师主动发起，并在系统上自助填写事务单，并转监控服务台受理。1.7受理或记录记录新事务单执行者：监控服务台受理或记录新事务单恳求，进入后续流程。初步支持描述：该步骤的目的是监控服务台在现存的解决方案中查询和该事务相匹配的方案，或依据个人阅历尝试在线对事务进行处理。若没有找到合适的解决方案或变通方法，将事务安排给一个具有合适技术技能的运维组。该步骤的重点是正确地安排事务，以避开后面对时间的奢侈。流程主要内容:输入：任务：输出：来自于步骤1.7“受理或者记录新事务单”2.1确定事务分类分级2.2重大事务推断2.3供应初步支持2.4能否解决事务单2.5分派事务单2.6接受事务单分派推断2.7说明理由，返回服务台重新分派事务单2.8报告事务至中心领导层已分派的事务单管理升级的信息表格STYLEREF1\s3SEQ表格\*ARABIC\s14受理和初步分析内容过程环节:2.1确定事务分类分级&2.2重大事务推断执行者：监控服务台确定事务等级是否正确（具体请参见2.4.7“事务等级”），假如是重大事务则进行（管理升级）确定事务分类是否正确（具体请参见2.5.4“事务分类”）。依据事务等级和紧急度，确定优先级。（具体请参见2.4.8“优先级规则”）。假如不是重大事务则进入步骤“2.3供应初步支持”。2.3供应初步支持&2.4能否解决事务单执行者：监控服务台在事务管理中查询已经存在的解决方案/变通方法，或进行学问库有效学问的匹配进行在线事务解决；依据监控服务台人员所拥有的技能尝试确定“解决方案或变通方法”，进行事务解决；假如可以解决，转至步骤IM-06“事务单关闭”中的步骤6.1。假如不能解决，转至步骤2.5“分派事务”。2.5分派事务单执行者：监控服务台提示：在此环节，假如是分派到组，则该运维项目组必需制定负责人，由负责人负责对事务单的组内分派。组员也可主动认领未组内分派的提示：在此环节，假如是分派到组，则该运维项目组必需制定负责人，由负责人负责对事务单的组内分派。组员也可主动认领未组内分派的事务单。2.6是否接受事务单分派&2.7说明理由并返回服务台执行者：运维项目组运维项目组/人接到事务后，推断事务是否分派正确，即是否本组/人的工作职责和技能范围。假如不是，则须在事务单上说明理由，将事务单返回服务台进行重新分派。假如接受，则转步骤2.5“分派事务”。2.8报告事务至中心领导层执行者：监控服务台假如事务是重大事务，则马上向信息中心管理层报告事务。信息中心管理层须要考虑和决策是否须要启动重大应急流程或灾备流程。管理升级描述：该步骤的重点是明确默认的管理升级机制及事务处理过程中正确的进行事务信息通知。流程主要内容:输入：任务：输出：来自于步骤“IM-2.受理和初步分析”中确定为对事务单级别的推断来自于步骤“IM-5.事务分析”中确定为对事务处理时间的预估3.1起先管理升级3.2/3.5/3.8/3.11重要性推断3.3/3.6/3.9是否升级3.4/3.7/3.10/3.12持续关注3.13事务进展通报3.14是否启动紧急状态推断中心领导层宣布紧急状态管理层对事务处理指导和批示管理层对事务处理持续关注过程环节:3.1起先管理升级执行者：运维工程师运维工程师依据事务等级和性质对事务信息进行恰当的升级。默认的升级规则见图中管理升级中默认升级机制依据预定义的通知规则进行升级通知，通知的形式可能包括诸如：通过系统传递信息；电话，邮件或者短信；升级之后进入环节“3.2重要性推断”，推断是否有必要接着升级。3.2/3.5/3.8/3.11重要性推断&3.4/3.7/3.10/3.12持续关注执行者：各升级环节的负责人提示：事务管理升级应首先依据等级自动升级；在事务重要性发生变更时，可由适当级别的负责人进行人工升级依据下级人员供应提示：事务管理升级应首先依据等级自动升级；在事务重要性发生变更时，可由适当级别的负责人进行人工升级假如确定事务单应接着升级，转入下一升级环节。假如不需接着升级，转入“持续关注”环节。在“3.4/3.7/3.10/3.12持续关注”环节中，本环节负责人应刚好收听或查看和事务处理相关的报告或汇报，确保对事务进展的持续关注。3.13实时进展汇报执行者：运维工程师由事务的处理工程师向各级领导实施汇报事务的处理进展和当前的影响范围。3.14是否启动紧急状态执行者：中心领导层由中心领导层对事务的影响度及处置状况进行综合评估，推断是否将当前事务升级为重大紧急状态：假如确定是紧急状态，转至“IM-7重大紧急事务”子流程假如认为暂不构成紧急状态，转至“持续关注”环节亲密关注事务的进展和处置状况。故障分析描述:这个步骤的目标是对事务进行分析以便提出解决方案，不同技术领域的事务分析员将会参和到该步骤中以寻求一个事务解决方案，在有必要时会升级至三线或者原厂开发商以便快速解决复原事务影响。流程主要内容:输入：任务：输出：来自于步骤“2.6受理事务单”4.1收集相关信息4.2是否重复事务4.3关联至主事务单4.4进行事务分析4.5预估解决时间所需时间4.6推断是否找到解决方案4.7转派事务单（技术升级）4.8推断是否受理事务单4.9说明拒绝缘由4.10提出解决方案针对该事务的解决方案管理升级信息过程环节:4.1收集相关信息执行者：二线二线对事务进行处理，并查找可能对事务处理有效的相关信息。该处理过程一线往往脱离开流程系统进行，在得到相关信息后，重新登录到流程系统，并将相关信息记录在事务单中。4.2是否重复事务执行者：二线找寻有相像症状(即由同一缘由造成)的事务:如找到类似的事务，即进入步骤4.3“关联事务到主事务”，假如在事务诊断过程中发觉匹配错误，可以取消此关联。假如没有找到，进入步骤4.4“事务单分析”4.3关联到主事务单执行者：二线推断当前事务单所描述的现象和之前未解决的事务是否有相像：假如确认是重复工单或主事务驱动工单，将新的事务单关联到原主事务单原有事务单被标识为“主事务单”原有事务单关联事务单数加一新建事务单出现在原有事务单重复工单列表中事务单状态将随原有事务单状态的更新而更新，不单独进行处理。4.4事务单分析执行者：二线检索学问库查询可能的解决方案，查找的途径包括但不限于：通过对已记录激活和未激活学问记录进行查询通过以往已关闭事务单中的解决方案或处理过程进行查询通过其它公共的资料信息进行查询依据专业技术阅历找寻解决方案或者变更方法。4.5预估解决时间所需时间执行者：二线二线对事务处理所需的资源和时间进行预判，并将结果通过“IM-3管理升级”向管理层刚好通报。4.6推断是否找到解决方案执行者：二线经分析如发觉解决方案，转到步骤“5.1解决和复原”如未发觉解决方案，或者须要其他系统运维项目组协作解决，则转到步骤“4.7转派事务单（技术升级）”。4.7转派事务单（技术升级）执行者：二线假如当前事务分析员由于某些缘由不能解决该事务，须要将事务转派给其他系统运维项目组。被分派事务的事务分析员进入步骤4.8“是否接受事务”。5.8推断是否受理事务单&5.9说明拒绝缘由执行者：二线、三线运维项目组/人接到转派的事务后，推断事务是否分派正确，即是否本组/人的工作职责和技能范围。假如不是，则须说明理由，将事务单返回原事务处理人员。假如接受，则转步骤2.5“分派事务”。转派超过3次，则事务单自动到事务经理进行协调。5.10提出解决方案执行者：二线、三线二、三线工程师依据事务描述状况以及所驾驭的相关信息，对事务着手进行处理，并尝试找到解决方案或者应急方案。找到方案后，转IM5.1“事务解决和复原”解决和复原描述：这个步骤尝试运用解决方案和变通方法来解决事务。对于某些事务，即使得到了解决，仍旧须要创建问题单以进一步找寻其根源。另外，处理过程中的阅历能够得到记录以形成可重用的学问图STYLEREF1\s38解决和复原流程主要内容:输入：任务：输出：来自于步骤4.5&4.10“找到解决方案”5.1是否须要变更5.2实行复原操作5.3验证解决方案5.4服务是否复原5.5是否进行根源问题分析5.6创建新的问题并和事务关联复原受影响的服务针对该事务的须要根源解决的问题单过程环节:5.1推断是否须要变更执行者：二线、三线 首先推断解决方案/变通方法是否须要启动变更管理流程假如须要，则进入步骤4.2“创建变更单”，通过变更流程实施；假如不须要，则可以干脆执行，进入步骤5.2“实行复原操作”5.2实行复原操作执行者：二线、三线 实施已确定的解决方案，以复原受影响的服务。5.3验证解决方案&5.4服务是否复原执行者：二线、三线 验证解决方案的实施是否有效：对于方案无效的状况，转到步骤4.4“故障分析”。对于方案有效的状况，同步转到步骤6.1“事务关闭”以及步骤“5.5是否进行根源问题分析”5.5是否进行根源问题分析&5.6创建新的问题并和事务关联执行者：二线、三线推断是须要对已解决的事务进行根源问题分析：对于须要分析的状况，转到活动“5.6创建新的问题并和事务关联”，针对该事务单新建一个问题单或关联到已有的问题单上。对于不须要分析的状况，转到子流程6.1“事务关闭”事务关闭描述：这个步骤确保用户对事务的处理状况感到满足。事务单的信息是正确、完整的，以便于以后生成报表。流程主要内容:输入：任务：输出：来自于步骤“IM-5.4业务已复原”已解决的事务单6.1检查事务记录6.2是否须要和用户确认6.3和用户沟通6.4供应反馈信息6.5用户确认事务是否解决6.6关闭事务单已关闭的事务单过程环节:6.1检查事务记录执行者：监控服务台对于用户报告的事务单，服务台检查系统中事务单记录的完整性，对于不完整的记录进行补充。6.2是否须要和用户确认&6.3和用户沟通执行者：监控服务台服务台依据事务性质，推断是否须要和用户沟通事务的处理结果，以便确认事务的真正解决。如确认须要告知用户事务处理结果的状况，转入活动“6.3和用户沟通”，沟通形式包括但不限于：系统通告，短信告知，邮件通知，电话通知等方式。如确认不须要告知用户事务处理结果，转入活动“6.6关闭事务单”6.4供应反馈信息执行者：用户用户在接受服务台通知后，向服务台供应着呢对事务处理结果的反馈信息。6.5用户确认事务是否解决执行者：监控服务台服务台依据用户反馈确定事务是否被胜利解决：如确认事务未解决的状况，转入子流程“IM-5故障分析”，重新查找事务缘由。如确认事务已解决的状况，转入活动“6.6关闭事务单”6.6关闭事务单执行者：监控服务台依据关单原则对事务单进行关闭。紧急状态描述：这个步骤是针对重大紧急事务的子流程，该流程的启用必需通过管理升级确定。流程主要内容:输入：任务：输出：来自于步骤“IM-3管理升级”中确定是紧急状态的事务7.1指定紧急应对小组的负责人7.2成立紧急应对小组7.3收集相关信息进行事务分析7.4初步分析结果汇报7.5是否协调更多资源7.6是否有应急处置预案7.7提出紧急复原方案7.8提交ECAB审批7.9实施方案7.10方案是否有效紧急复原受影响的服务过程环节:7.1指定紧急应对小组的负责人执行者：中心领导通过管理升级确定为重大紧急事务后，由信息中心领导制定一名负责人作为紧急应对小组的负责人，对紧急状况进行指挥和处理。假如启动紧急应急状态，则事务单转到该负责人，由该负责人对事务单进行分派。7.2成立紧急应对小组执行者：紧急应对小组由紧急应对小组的负责人，选取适当的技术和业务人员成立紧急应对小组，对紧急事务进行处理。7.3收集相关信息进行事务分析执行者：紧急应对小组由紧急应对小组对事务的现象、相关CI、影响范围、技术相关领域的信息进行收集，以供分析诊断。7.4初步分析结果汇报&7.5是否协调更多资源执行者：紧急应对小组依据上一步骤收集的信息对重大紧急事务作出初步分析推断，并刚好提交报告至中心领导审批，由中心领导确定是否须要向紧急应对小组供应更多资源以便加快处理流程。如须要协调资源，转入活动“7.3收集相关信息进行事务分析”。如确认不要协调资源，转入活动“7.6是否有应急处置预案”7.6是否有应急处置预案&7.7提出紧急复原方案执行者：紧急应对小组 紧急应对小组查询已有资源，包括但不限于：可持续性支配、事务记录、学问库等，确定是否有可以应用于本领件的应急预案：如有应急预案，转入活动“7.8提交审批”。如确认没有应急预案，转入活动“7.7提出紧急复原方案”，由紧急应对小组审计编写应急方案，之后转入活动“7.8提交审批”。7.8提交审批执行者：ECAB 应急负责人组织中心领导和对紧急应对小组提交的解决方案进行审批：如审批通过，转入活动“7.9实施方案”。如确审批未通过，转入活动“7.7提出紧急复原方案”，由紧急应对小组审计重新编写应急方案。7.9实施方案执行者：紧急应对小组 紧急应对小组实施以审批的解决方案。假如解决方案须要启动变更管理流程，则需在事务复原后补录紧急变更单。7.10方案是否有效执行者：紧急应对小组 紧急应对小组检测事务解决方案的实施效果：如服务已复原，转入子流程“IM-6.1事务关闭”。如服务未复原，转入活动“7.7提出紧急复原方案”，由紧急应对小组审计重新编写应急方案。角色和职责本章节描述省局信息中心有关人员在参和执行和管理事务管理方案时的角色和责任。市局参和事务管理的角色可以参照省局对应角色进行设置。一个角色不等于对应一个人员，一个人员可以担当多个角色。例如，可以由同一个人员担当事务管理和问题管理负责人的角色。以下为事务管理流程中必需具有的角色：事务管理流程负责人事务管理流程负责人作为事务管理流程的责任人，对于整个流程执行的结果负责，并有肯定的权力管理流程。事务管理流程负责人的职责包括：全面负责流程的效率和成果建立考核和目标，以提升流程的有效性和效率为保障流程的有效性，需争取高级管理层承诺投入足够的资源鉴别和管理关键的流程胜利要素限制和带领流程的改进批准和拒绝偏离流程的恳求定义事务管理的角色、责任和应负的责任定义目标、流程、工作流、政策和规则，并和相关人员进行沟通强制事务管理流程的执行确保对流程的运用者供应适当的教化对其他流程负责人和管理层汇报流程的状况和进度对事务管理流程的有效性和效率进行监控，在须要的时候作出改进召开和主持对事务管理流程改进的季度会议审计事务管理流程的执行作为事务管理流程对外的代表事务经理事务经理负责协调事务管理的日常操作步骤，并管理工作的时间支配。事务经理的责任包括：协调事务管理的日常操作确定和执行流程本身的变更鉴别流程执行过程中的例外和异样状况，并进行管理传达流程的新政策和更新的政策确保流程标准和步骤得到遵循作出资源的承诺和安排鉴别和实施流程的改进建议产生和分派流程管理的报表对事务管理流程的负责人提出改进的建议作为流程的集中联络点，负责和用户、服务供应商、管理层之间的沟通组织解决须要跨越职能部门或项目组的问题，如有须要，应升级汇报对于不遵守流程的情形进行处理在须要的时候，依据升级政策中所定义的途径进行升级对不遵从事务管理流程的参和者作出通告执行日常的流程管理出席会议并传达和协调有关事务和问题打算和分析报表从事务管理流程的起先到结束进行跟踪事务分析员事务分析员，主要是省局信息中心作为二线、三线的专业支持人员，具有某个领域的技术技能。负责供应良好的事务分析和/或者是供应一个方案，来快速复原受到干扰的服务。省局信息中心的事务分析员按技能或者系统划分为运维项目组，例如应用运维项目组，大集中征管系统维保项目组等。事务分析员的责任包括：分析事务信息关联受事务影响的CI（配置项）确认事务的优先级查找相同的症状的事务，并进行关联确定复原服务所须要的必要条件，并启动适当的行动依据事务的优先级供应有效的解决方案/应急预案如有须要，和厂家和其他小组人员协同合作确定恰当的分派(例如转派到组内其他事务分析员或者其他组事务分析员)依据事务等级进行恰当管理升级识别解决方案或者变通方法是否须要提交变更申请记录解决方案/应急预案鉴别成为问题的事务，如须要找出问题的根源，创建问题单（待问题管理实施后需履行此职责）向服务台供应事务单处理进度有权限访问相关已知错误、问题解决方法和配置管理数据库(CMDB)监控服务台监控服务台作为省局信息中心的一线的支持人员，是用户、各地市信息科和省局信息中心的主要联系人。作为是事务的负责人，负责受理或创建事务单、跟踪、协调事务的解决。监控服务台的责任包括：接受用户或者地市信息科的事务报告或者事务升级恳求验证用户的基本信息，如有须要，更新用户的资料创建或者更新事务单收集和事务处理相关信息，并确保信息的完整（尤其是相关审批表）分析故障报告信息初步评估事务的优先级确定适当的分派基于学问库，初步解决事务对于不能解决的事务，分派给合适的事务分析组或人员若用户要求了解事务状态，则将事务的当前状况通知用户和用户确认事务的状况和解决方案更新和关闭事务单角色映射角色省局信息中心岗位映射监控服务台监控服务台岗事务分析员（二线）应用运维项目组、系统平台运维项目组、平安及网络运维项目组事务分析员（三线）各信息系统运维项目组，例如：大集中征管系统维保项目组、发票在线系统项目组、纳服整合平台项目组等事务经理监控服务台台长事务流程负责人运维办事务经理业务规则总体业务规则XXXX信息部门（包括省局信息中心和各地市信息科）支持的信息系统和网络环境中，全部对服务的正常供应有影响的事务都会通过事务管理流程处理；将通过流程中定义的标准、政策和指导进行管理。全部报告事务的部门将会参和统一的事务管理流程，不应当有任何例外。确保各地市服务台作为各地市信息科事务的统一入口，省局监控服务台作为省局信息中心事务的统一入口，从而保证全部的事务都能够记录和跟踪。故障处理人员假如因为时间紧迫没有对全部发觉的故障进行记录，干脆解决故障的话，应事后补单。（补单状况应通过管理来尽量避开）须要定期抽查事务单填写的质量，确保内容足够明确、具体。应当定期产生和回顾事务管理报表。对没有解决的问题，应当实行定期的事务管理睬议对这些事务进行评估。应当定期对流程进行回顾，以改进事务管理流程。责任人业务规则有效的管理事务的重要因素是定义一个责任人业务规则，以确保每个事务在任何时段都有适当的人员负责。当一个事务由地市服务台创建后且未升级至省局信息中心，地市服务台作为事务单的责任人，在事务单的全部生命周期内负责推动事务的处理进度。假如事务单升级至省局信息中心，则事务单的负责人是省局监控服务台，但是地市服务台接着跟踪该事务单的进度。假如事务单是由省局监控服务台或者工程师创建，则省局监控服务台是事务责任人，在事务单的全部生命周期内负责推动事务的处理进度。当事务单被分派后，接受事务单的事务分析员是此事务单的当前负责人；但是分派方（作出分派的服务台或是作出转派的事务分析员）有责任通知被分派的事务分析员并要求他接受或是拒绝此事务单。假如须要向用户通知处理状况，由事务单的当前责任人或服务台负责。分派和受理业务规则监控服务台可以干脆分派事务到运维项目组或人。各运维项目组可以指定组长对分派到该组的事务单进行转派。在运维项目组组长未刚好进行转派的状况下，组内任何成员均可主动受理此工单。事务处理人员在收到工单指派通知后应尽快做出响应。注:每个运维项目组都需设定一名组长角色。转派业务规则转派指监控服务台或者运维项目组组长分派后，被分派对象将事务单转给组内或者其他组的事务分析员（服务台分派事务不属于事务转派）。转派业务规则确保事务单不被过于常见的相互转派，以至于无法在规定时间内得到解决。事务单可以由事务分析员转派给本组或其他组的事务分析员。事务转派超过3次（含3次），事务单将升级给事务经理。服务台和事务分析员，由于某些缘由（例如出差，休假，培训等）离开本岗位时，必需确保将未处理完毕的事务单转派到本岗位其他事务分析员。服务台或者工具管理员可以手工干预对其单进行组内转派（不会影响一次分派胜利率）组内转派不影响KPI“首次分派胜利率”的计算，有两种状况：服务台下单后分派到服务台组，此种分派不算作第一次分派，不影响一次分派胜利率的计算，及后若接着在服务台组内转派，同样不影响一次分派胜利率的计算。服务台派单到后台各个分析员组后，事务分析员在其组内转派，也不影响首次分派胜利率的计算，若其须转派到其它组，则需先退回到服务台，再由服务台作转派。此时则算作首次分派不胜利，对一次分派胜利率的计算有影响。事务单转派时，按第一次状态变为“处理中”的时刻为“接受所分派事务”的时刻。从第一次“已分派”状态到第一次“处理中”状态之间的时间，作为响应时间。假如事务单被多次转派，则在KPI指标计算时，只计算大环节的“响应时间”和“解决时间”。即计算第一次“已分派”状态到第一次“处理中”状态为响应时间，第一次“处理中”状态到最终一次“已解决”状态为解决时间。关于中间的转派环节，须要打开具体的单来看，不必在报表中体现。不在岗业务规则假如事务分析员由于某些缘由（例如出差，休假，培训等）离开本岗位时，而无法处理事务单，必需在离开前在ITSM工具上把自己的状态设置为“不在岗”，并通过合适的方式通知服务台，以确保服务台和其他事务分析员不会派单给该事务分析员。重复事务业务规则重复事务：假如被报告的事务和某个已经创建且尚未解决的事务单症状相同，则该事务被认为是重复的。将会为此重复的事创建新的事务单，并标注此单为“重复”并和原始事务单相关联。原始事务将被标注为“主事务”。主事务解决时，从事务自动解决（自动变为“已解决”状态）。事务等级事务的等级表明白对事务单处理的优先程度。它是评定事务处理优先等级的一个重要指标。全部事务都将安排到四个等级中的一个。事务等级从一级到四级。本表针对省级集中系统的事务进行划分，地市自行开发业务系统的事务等级可参照设定。事务等级在事务的生命周期中是可以变更的。关于更改事务单等级的缘由和行为应当在事务单中记录。在故障处理过程中，随着事务影响范围扩大，故障等级应按扩大后的范围重新划定在下表中对事务的影响程度依据四个等级进行划分，每个等级中对事务的表象进行了描述，服务台可以依据影响程度的定义对事务进行等级的划分：一级二级三级四级级别描述导致两个（含）以上地市全部或部分重要业务系统税期中断服务的故障。导致单个地市的一个（含）以上系统全面中断或者重要业务系统税期重大服务的故障。导致单个地市单个系统全面或部分功能中断服务的故障。不属于上述故障的其他故障。主要负责人由信息中心分管主任或主任负责由运维项目组所在科室科长负责。由具体运维项目组负责人负责由具体事务分析员负责优先级规则优先级确定处理事务的依次及所需的资源。事务优先级可分为四级：最高、高、中、低。由事务重要程度和紧急程度两个维度共同确定。事务的紧急程度主要是以用户能容忍的故障解决时间来进行判定，详见下表：紧急程度用户能容忍故障解决时间11H22H34H46H结合事务等级和紧急程度，可以通过下表确定事务的优先级：事务优先级事务等级一级二级三级四级紧急度1最高最高最高高2最高高高中3最高高中低4最高高低低目标解决时间业务规则为了更好的限制事务的解决，整个流程被分解成几个组成部分。每个流程的阶段都设定了目标时间。事务管理的目标时间如下表所示：（时间的起点是事务单创建完成或者事务单升级至省局信息中心）。升级至省局信息中心的事务单的时间起点从提交至监控服务台的时间点算起。目标时间事务等级一级二级三级四级事务分派、接受和响应5min10min15min30min解决&关闭事务2H4H6H8HTotal2H4H6H8H每个步骤的目标时间达到后，仍未响应，自动邮件通知相关人员，其中二级以上事务自动通知事务经理和所在科室科长。全部超出目标时间的事务单将体现在每周、每月的统计报表中。同时，事务经理将得到通知。催办业务规则为了保证服务尽快复原，事务在没有在规定时间内响应或解决时，服务台人员须要对事务的处理过程进行干预，督促事务尽快处理。该功能须要结合事务的等级进行设定，不同等级的事务其响应时间和解决时间不同，催办的时间也不尽相同。一级二级三级四级第一次催办1H2H4H6H其次次催办2H4H6H8H注：催办时间从事务单产生或者提交至省局监控服务台的时间点起先计算。通知规则在服务不行用或复原时，须要将受影响服务的可用性信息刚好通知关键的IT部门和业务部门。业务部门的通知规则详见《运维公告规定》，IT部门的通知规则如下表：事务级别运维组负责人所在科室科长分管主任中心主任一级√√√√二级√√三级√四级管理升级内容通知内容应当以简单理解的方式进行描述并至少包含下述内容：事务的简要描述；受到影响的服务；正在实行的措施预料复原服务的时间（尽可能精确）；事务的最新进展等。技术升级规则对于不同优先级的事务，升级业务规则的目的是确保安排到合适的资源在规定的时间内复原服务。为了达到这个目的，在此定义了事务升级的业务规则时间框架。当达到下列时间要求假如事务还未解决，将触发升级业务规则。事务等级一线二线三线一级马上马上马上二级马上马上马上三级0.5H2H4H四级1H4H6H事务单关闭业务规则事务关闭有以下业务规则：由服务台分派的事务单应由服务台人员关闭。通过监控发觉的事务单可以由一线主动关闭此事务单。自动关闭事务单规则：对超过5个工作日的已解决的事务自动关闭。事务单代码事务类型事务类型是对用户恳求的分类。事务类型能够用来进行制作报表和查询。预定义的事务类型如下：事务类型描述询问应用或业务的运用询问服务恳求来自用户的对信息、标准变更的恳求。例如数据查询和修改、创建用户、变更系统权限或密码等。此类事务多因由业务规则或政策变更导致。操作错误用户因不熟识系统或者业务规则，对应用系统操作不当而导致的事务。此类事务因用户操作不当引起的后台数据修改故障因系统数据原来存在的缺陷、异样数据或其他缘由，即非用户操作不当导致，也非业务规则变更导致系统正常的操作事务单状态代码在事务的不同处理阶段拥有不同的状态，各阶段状态代码建议定义如下（需在产品的客户化设计中进行最终确定）：状态代码描述新建事务被记录或创建已分派事务已被分派给服务台、事务分析员（二、三线支持）或事务经理；处理中事务分析员（二、三线支持）接受了分派给他/她的事务单；等待事务信息不完整，或在某些状况下阻挡服务台或事务分析员对事务进行处理，等待的缘由可能为：等待用户进一步的信息等待RFC变更流程处理等待问题管理（仅对事务单有效）等待其他厂商/供应商处理等待业务部门领导批复已解决为一个事务找到解决方案或变通方法已关闭事务已经关闭事务来源当一个事务被登记后，服务台必需指定事务单的来源。这个信息能够帮助确定多数用户恳求来自哪里，这对优化用户能够带来最大潜在好处的接口时特别重要。事务来源描述E-Mail服务台通过电子邮件收到一个恳求。电话服务台通过电话收到一个恳求。Web通过工具的网上自助服务提出的事务。内部报告由运维人员主动发觉的故障告警事务由告警管理自动/手工产生的事务事务分类事务分类通常是标明一个事务的类别属性，依据不同的类别属性，由具备不同技能的事务分析员进行事务受理。事务类型也是用来统计事务单和制作报表时常用的一种汇报依据。总体来看，事务分类是用来推断：谁来负责解决事务（如，缺省的分派组）创建事务单须要那些信息可以用于配置事务的缺省优先级采纳三种分类方式按归属层次地市级系统故障省级大集中系统故障按影响范围影响全省；影响部分地市；影响一个地市。按事务发生的归属系统分类，运用不超过三级分类：类别（Category）类别是CTI分类方法的最高层。它将被用作对事务进行分组的第一层。例如：应用系统、系统平台、网络、桌面系统等。子类（Type）子类用来区分每个“系统”的基本组成模块。它将被用作对事务进行分组的其次层。例如：对类别“应用系统”来说，可以分为核心征管系统、发票在线系统等“子类”。对于类别“系统平台”来说，可以分为主机、数据库、中间件等“子类”。项目（Item）这个层次体系中第三层是项目。这一层是指在这个体系中特定的模块。项目这一层能够获得更具体的信息和更精确的搜寻。关闭代码每个事务单在关闭时，都须要填写关闭代码以标识该事务单被处理的最终结果。因为每个事务单的处理结果不肯定都有最终解决方案，因此为了更有效标识事务的解决结果，我们建议定义事务关闭代码如下（需在产品的客户化设计中进行最终确定）：关闭代码描述胜利关闭事务被正常解决变通方法事务已通过变通方法解决掉，但是须要进行更进一步的根源分析。未能解决已知的错误、变通方法或已实施的变更失败，在现有条件下不能解决这个事务不能重现事务自行消逝或者监控系统告警自行消退自动关闭系统自动关闭用户撤销用户撤销事务单人员信息为了满足对流程有效运作及流程角色的绩效统计，暂定人员属性信息如下（需在产品的客户化设计中进行最终确定）：数据对象数据源备注登录名内部信息姓名内部信息电话内部信息Email内部信息所属科室/公司内部信息所在地市/省局信息中心内部信息所在项目组内部信息一线、二线、三线内部信息单选运维项目组组长内部信息是否事务信息事务单包含的属性字段建议如下（需在产品的客户化设计中进行最终确定）：数据对象数据源备注事务单号系统自动生成事务描述必填，简短描述事务具体信息事务发生时间事务影响范围事务优先级事务类别事务子类以类别为依据事务条目以类别、子类为依据相关配置项相关配置项ID恳求人姓名恳求人联系电话事务分派组事务分派人工作日志记录不同状态下，人员的工作内容解决方案/变通方法用户反馈看法信息附件附件的主要目的是帮助问题流程衡量指标序号指标名称指标类型指标说明1全省事务单总数日常统计指标用途：当前事务的总数，用于了解系统中记录的事务数量。数量：在事务单中依据以下条件过滤【关联主事务】标示为空【事务创建时间】在统计周期内【事务创建时间】在统计周期之前，但在统计周期的起始时间还未关闭的事务单2事务关闭的数量/比率日常统计指标用途：当前事务处于“关闭”状态的数量以及占总事务数的比例，用于了解事务处理完毕的状况。数量：在事务总数中过滤【事务状态】＝‘关闭’比率：数量/事务总数×100%3各种关闭类型的事务数量/比率日常统计指标用途：了解事务单关闭状况分布数量：在事务总数中过滤【事务结束代码】＝胜利关闭、变通方法、未能解决、不能重现、自动关闭、用户撤销。比率：数量/事务关闭数量×100%4重大事务数量/比率日常统计指标用途：事务等级为一级的数量及占事务总数的比例，用于了解重大事务的发生率。数量：在事务总数中过滤【事务等级】＝‘一级’比率：数量/事务总数×100%5各类型事务单比例日常统计指标用途：各事务类型事务数量及占事务总数的比例，用于了解重大事务的发生率。数量：在事务总数中过滤不同【事务类型】比率：数量/事务总数×100%6各等级事务单比例日常统计指标用途：各等级事务数量及占事务总数的比例，用于了解重大事务的发生率。数量：在事务总数中过滤不同【事务等级】比率：数量/事务总数×100%7超过规定时间转出的事务数量/比率绩效衡量指标用途：超过预定一线转出时限的事务数量及占事务总数的比例，用于衡量服务台处理事务的效率。数量：在事务总数中过滤（【事务转出时间】－【事务登记时间】）<优先级对应的转出时限比率：数量/事务总数×100%8首次派单胜利率绩效衡量指标用途：未出现重分派状况的事务记录数量，用于衡量服务台对事务分类和对应支持资源的推断和协调实力。数量：在事务总数中过滤【事务重分派次数】=1；比率：数量/事务总数×100%9未超过规定时间解决的事务数量/比率绩效衡量指标用途：超过SLA指定解决时限的事务数量及占事务总数的比例，用于衡量事务流程对事务的处理实力。数量：在事务总数中过滤【处理是否超时】＝‘未超时’and【事务关闭代码】＝‘胜利解决’or‘变通方法解决’比率：数量/事务总数×100%10平均响应时间绩效衡量指标用途：响应事务的平均时间，用于衡量服务台、二线、三线的响应效率。服务台响应时间：累计响应事务的时间（【事务分派时间】-【事务登记事务】）/事务总数。省局信息中心的事务登记时间为地市提交至省局的时间。二线、三线平均响应时间：累计响应事务的时间（【事务受理时间】-【事务分派时间】）/事务总数11平均解决时间绩效衡量指标用途：服务台/二线/三线解决事务的平均时间，用于衡量服务团队对事务的处理实力。完成的事务数量：在事务总数中过滤全部【事务状态】＝‘已解决’or‘关闭’，同时【事务解决人角色】=‘服务台热线’or‘二线’or‘三线’的事务平均解决时间：累加完成事务的（【事务解决时间】－【事务登记时间】）/完成的事务数量12一线解决率绩效衡量指标用途：服务台解决事务的比例，用于衡量服务台对事务的处理实力。数量：在事务总数中过滤全部【事务解决人角色】＝‘服务台’比率：数量/事务胜利关闭总数×100%13二线解决率绩效衡量指标用途：二线解决事务的比例，用于衡量二线人员对事务的处理实力。数量：在事务总数中过滤全部【事务解决人角色】＝‘二线’比率：数量/事务胜利关闭总数×100%14三线解决率绩效衡量指标用途：三线解决事务的比例，用于衡量三线人员对事务的处理实力。数量：在事务总数中过滤全部【事务解决人角色】＝‘三线’比率：数量/事务胜利关闭总数×100%功能需求 在一样性流程处理的大的基本原则下，须要考虑不同地市流程处理要求的特别性。例如，事务管理流程角色设置在不同地市存在差异。系统平台软件须要针对具体差异进行敏捷的流程定制，并供应相应的统计分析功能；用户的特点本流程模块的用户特点如下表地市信息科用户状况21个地市（广州市、珠海市、中山市、惠州市、顺德区、东莞市、湛江市、肇庆市、茂名市、河源市、汕尾市、揭阳市、清远市、汕头市、潮州市、阳江市、韶关市、云浮市、梅州市、江门市），平均每个地市6个用户，其中广州、佛山、中山预估还需增加24。总共21*6+30=150人。角色状况其中每个地市信息科配置一个服务台角色，属于地市一线、一个事务经理、其余为事务分析员，属