商业银行IT服务管理平台的设计方案

1 商业银行 务管理平台的设计方案 引言 题的提出 如今，银行业务在市场的刺激下飞速发展，众多的商业银行都积极的进行对应 统以及 础设施的配建工作，但是 门自身的信息化建设却相没有跟上，缺乏对事物以及问题处理过程进行全程控制的手段，缺乏统一的和规范的管理。众多的频发的事故，常常让 员忙得焦头烂额，同时在应对以及解决突发的预警事件显得能力不足等，导致无法及时的提供有效而高效的服务。银行提供服务的系统和设备越来越多， 门的压力也越来越来，提供一个稳定而高效的系统所面临的问题也越来 越多。 门的职能也向服务职能倾斜。众多情况表明，采用一套规范的有效的 务管理流程在目前银行信息化建设中扮演这越来越重要的角色。 商业银行 以为商业银行提供一个高效、稳固，健康而又灵活 务管理解决方案。目前 ,务管理在世界各国受到了越来越广泛的关注 ,在金融 业也将更多的得以实现和更好的应用，一展用武之地。 为了提高 供稳定有效的服务， ,提升 推广，金融公司需要提高他们的 强对它的整体性和可持续性建设中的应用。 基于目前汇丰银行商业银行部 务管理的现状 ,本文分析论证了银行 重点探讨 务管理平台的原理、方法以及目标 ,研究了包括事件管理（ 问题管理（ 变更管理（ 配置管理（ 多项服务流程。在平台设计上给出系统功能能的实现方法 ,并对 2 平台的集成与性能等非功能需求要求进行了分析。从技术角度 ,商业银行 并过通过构件技术构建出可扩展的具有高灵活度的应用解决方案 ,具有松散耦合、高度可扩展、易于实施等特点 ;从理论角度 ,银行 强调灵活性、规范化和标准化 ,以更好地帮助实现 内外现状 是一个很好的帮助企业对 发，实施和运行的高质量的有效管理方法。它结合了高质量的服务流程，人员和技术不可缺少的三个 重要元素可以用标准的方法获得的监控 务的运行状态管理”服务是一个过程为导向，以客户为中心的管理方法，通过它的服务与服务的整合，帮助企业提高 源于， 家电脑局）在 1980 开发的一套 在它的英国总结管理方法，成为规范，提供了一系列的研究和开发，从规划，为企业 门的标准操作方法的实现。本标准的许多企业已经在欧洲，美国和澳大利亚，目前在欧洲知道 0%至 60%的 0理解 务管理， 但在国内对 务管理所知甚少，但也增加了。 的和意义 本文将着于研究如何将 好的融入到 T 服务管理。 以说是第一批引入 法论，从 人入职 T 部门已有 8 个年头。如今每天的工作都要接触并使用到 期中的利弊体会颇多。 迄今为止， 没有一套专属与自己的或者说是为自己量身定做的 隔一年或者两年，公司都会斥资购买市面上（主要是欧美）的最流行的统。然而，这些新系统的不断引 入以及旧系统的淘汰和更新，导致了如今 统并存的紊乱状态。比如在 ，对于最常见 3 的事故管理（ 就同时使用了 家的系统；对于问题管理 (是有三种系统在同时使用，分别是 于 是用了微软的系统。 虽然引入了 是由于公司内部的特有情况，以及多个 务的质量和效率相对的却降低。公司管理层 越来越深刻的了解并理解，设计开发出一套自用的，为自己量身定做的 设计开发出一套为自己量身定做的 统，可以有效的将流程、人员和技术三大要素的有机结合，从而提高 综上所述，主要目的与意义有： 1) 设计 门完成支持服务管理、问题管理、事故管理等 2) 提高 门内部的工作效率和信息共享，提供及时、透明的服务 3) 帮助 信息技术资源高效共享。 文的主要工作 本文首先对国内外 后具体介绍了一些 背景知识，以 个案指出 需要正确的使用才有好的效果，并使用一些 本文总体上分为七大部分，第一部分，对国内外 用现状和本项目的背景以及为什么要引入 行了分析。第二部分，介绍了商业银行和 便让读者对 一个大概的了解，这样有助于更好的理解本项目的设计与实现。第三部分，进行系统需求分析， 对引 统的设计的进行细致的需求分析。第四部分，基于第三部分的系统需求分析进行比较详细的设计。第五部分，介绍 开发平台与环境的配置， 对一些常用的设计模式进行介绍，并举例介绍它在本项目中如何使用。第六部分，进行成本效益的分析。第七部分，对 4 第二章 商业银行与 景知识 业银行的背景探讨 最初使用“商业银行”这个概念，是因为这类银行在发展初期，只承做“商业”短期放贷业务。放款期限一般不超过一年，放款对象一般为商人和进出口贸易商。 商业银行（ 英文缩写为 为存储银行。商业银行的概念是区分于中央银行和投资银行的，是一个以营 利为目的，以多种金融负债筹集资金，多种金融资产为经营对象，具有信用创造功能的金融机构。一般的商业银行没有货币的发行权，传统的商业银行的业务主要集中在经营存款和贷款（放款）业务，即以较低的利率借入存款，以较高的利率放出贷款，存贷款之间的利差就是商业银行的主要利润。商业银行的主要业务范围包括吸收公众、企业及机构的存款、发放贷款、票据贴现及中间业务等。它是储蓄机构而不是投资机构。 人们将这种主要吸收短期存款，发放短期商业贷款为基本业务的银行，称为商业银行。中国的商业银行是指依照中华人民共和国商业银行法和中华 人民共和国公司法设立的吸收公众存款 办理结算等业务的企业法人。 商业银行发展到今天，与其当时因发放基于商业行为的自偿性贷款从而获得“商业银行”的称谓相比，已相去甚远。今天的商业银行已被赋予更广泛、更深刻的内涵。特别是第二次世界大战以来，随着社会经济的发展，银行业竞争的加剧，商业银行的业务范围不断扩大，逐渐成为多功能、综合性的“金融百货公司”。3 庄毓敏 商业银行业务与经营 M ：中国人民大学出版社 ， 2010 背景探讨 最终的 实施还是要依靠相应的工具和经验。由于国内的信息化仍处于起步阶段，因此以前更多的是关注技术，例如很多客户也采用 5 了网络管理、系统管理等管理工具，但技术只保证了服务的质量和效率，标准流程则负责监控 人员素质则关系到服务质量的高低。而 员和技术三大要素的有机结合。 1) 共性 用的语言”，为从事 相关人员提供了共同的模式、方法和同样的术语，使用户和服务提供者通过有 共性的工具深入讨论用户的需求，很容易达成共识。 2) 中立 理提供了实施框架，这样可以让用户不会受制于任何单独的服务提供商。 不会因下一代操作系统的发布而改变。 3) 实用 一种以流程为导向、以客户为中心的方法，它在兼顾理论和学术的同时，非常注重实用和灵活。 第三章 系统的需求分析 需求分析 是软件工程设计的第一步，是整个软件将要实现的目标和意义，只有真正作好软件设计需求分析，才能真正知道究竟要提供的服务是怎样的，才可以跟好的部署接下来的工作和流程，软件 系统的设计，软件系统的开发，软件系统的实施和使用都是建立在软件需求所分析出的各项需要实现的功能上的。接下来就针对商业银行引入 本文中要设计的 务管理平台是一套基于 务管理软件，可以对 于 程、人员以及技术。这三个重要的关键性的重要元素的很好的结合使用可以让 为企业 理人员管理企业 T 服务管理 模式以及运作方式 如今，银行客户对银行服务的要求越来越高，以及银行各种日常业务流程和处理对信息系统的依赖程度也越来越高。开发设计出其符合银行自身特点的 今广泛采用以及公认有效的银行 6 图 3上图 3们可以清晰的发现商业银行所需要的 服务台接收到某事件请求，该事件可以是客户的服务请求也可以是系统本身的可检测故障，如突发事件、问题、投诉和用户请求等。经过专业培 训的 即询问应在 自动生成以对应的 D，即刻进入事件管理去尽快的回复服务。如果是已知问题，可以立刻从知识库（ 中找到对应的解决问题的信息和相关知识，从而尽快解决事件或者故障，恢复服务。如果之前从未发生的事件，也无法从知识库中找到对应的知识和解决方法，则应转交事件管理的一线技术支持人员进行处理；如果还是不能解决那么就转给事件管理的二线技术支持专家。如果事件及时解决，则将次事件标记为已经解决，并将对应的解决方法和 所有的有关信息，连同该事件一并记录到知识库中，下次发生时，可以有 对于经常发生或者原名不明无法及时解决的事件，可以上升为问题，进行更深入的分析和跟踪处理，即进入问题管理。分析问题产生的根本原因，并且加以改进，给出最终的完整的解决方法。具体的解决方法可以需要对相关的软件系统或者硬件系统发起变更并进行变更流程处理。以上所有的细节都应详细的记录在各流程对应的问题处理进展中。 这种银行 进行设计，同时它也很好地服务 分的体现了将 足了我们的需要。 T 服务管理平台需求分析 体需求 总体目标是开发出 规范的、 达到国际标准的 时可以很好的支持并配合银行本身的业务和特殊需要，改进并提升 供可靠、稳定、安全的服务，同时实现对 能需求 建设 、事件管理（ 、问题管理（ 变更管理（ 配置管理（ 知识库（ 能。 1) 是用户与项功能通过集中方式提供服务，对于环球银行更应遵循 供对应的本地服务台（ 。 务台的根本目的是提供初始支持，还应通过变 通方法 以及解决方案可以升级（ 一线、二线支持等手段，从而可以最快的帮助用户或者对应的系统恢复到正常的使用或者工作状态。 有的客户请求已经系统自身的警报（无论是通过电话、电子邮件或者还是其他自助服务界面发出的）可以可以及时地通过服务天管理流程实现，服务管理模块已经对应的流程可以协助 级、分配、管理和解决事件。 要实现 事件或者系统警报进行全面的记录和对应的更新，之后充分利用知识管理工具在最大的程度上提高首次请求的解决率。当同样或者类似的事件再度出现时，可以自动 8 调用并更新这些解决方案和其他信息，有效地生成关于整体服务的绩效统计报告。 2) 事件管理需求 事件管理流程是为尽快地回复系统的正常工作和用户的正常使用而设计，快速的响应事件、快速的恢复服务，使故障对业务和用户的影响最低化。 事件管理流程的事件触发和驱动。所谓事件，是指传统的故障或故障非手术的发生，包括软件故障硬件故障和正常运行，任何影响用户操作和系统。不是所有的事件都 是由用户触发，报警监控管理平台也可以由触发事件。 事件可基于相关的配置项的关键等级和对用户使用的影响进行优先类分级。 事件管理的责任是与用户和问题管理流程交流从而及时的解决事件 , 记录、调查、分类、解决和监控跟踪事件， 3) 问题管理需求 问题是指一个或者几个暂时已经处理但无法找出根本远离的不明确事件，通常很多的事件往往可能是同一个问题引起的。 问题管理流程的最终目的是消除或者减少事件的发生，将系统内部缺陷导致的或者可能导致的各种事件以及问题的影响降到最低。问题管理流程中，对应的专家在分析调查研究，对问题的影响 以及严重程度进行评级，找出根本原因进行解决修复；然后通过生成对应的变更求 、变通方法或者建议预防性措施来方式事件的再次发生。所以问题管理流程和变更管理需要一起来实施，从而从根本上解决问题。 问题的来源主要有一下几种： a)已经解决的事件，经过回顾分析之后，可能形成一个问题 b)重大事件，虽然经过紧急处理后恢复服务，也可以形成一个问题 c）对于趋势性事件的分析，形成问题 d） 流程中形成的问题 4) 变更管理需求 变更管理是通过单一只能流程来管理和控制整个 同配置管理建立接口。变 更管理可以由管理工具来支持，管理的范围可以包括硬件 、软件、和文档等。变更请求通常由问题解决方案中需要对生产环境进行某些改变或者改进而产生。 变更顾问委员会（ 下简称 来帮助和支 9 持变更经理，根据变更内容来决定 员，通常包括开发人员、运维支持人员、客户代表、商务分析人员等。 5) 配置管理需求 配置管理是一个描述 、跟踪和汇报所有 些设备和系统被成为配置项（ 以下简称 一个 提供和支持 下简称 。 在定义一个 据相应的命名规则；同时对应的负责人、状态、已经其他相关属性也要被详细记录。 及对应服务的软件系统都要记录到 置管理还对 整性和统一性。 配置管理是 要确 保 整的、正确的记录和维护，从而为达到有效的服务管理奠定基础。例如，可以通过查询某 到对应的配置信息、与其他 务的软件系统、最近以及历史状况，服务台员工可以及时迅速的判断故障，找到有效的解决方案，从而高效的确保系统的稳定性和可用性。 6) 知识库管理 知识库管理是指通过对知识资源的开发和有效利用，提高企业的运维能力，从而提高创造价值能力的管理活动。它是一个不断积累 、共享、利用、和再创新的过程 . 知识哭管理流程着重与对现有的经验的累积和知识的 规整，正确、有效、及时的发布给需要的人员使用。主要活动包括经验撰写，更新、审批、发布以及定期的查询和审计。 功能需求 除上述功能需求外 ,平台还应考虑高可用性 、安全性、高性能、可扩张性、灵活性等多方面的非功能性需求。 1) 高可用性和安全性 务数据必须做到完整无丢失和安全补泄漏，尤其是客户的信息以及一切有关数据，禁止非法 10 获取和破坏数据。 2) 高性能和可扩展性 系统应可以支持高峰时众多员工同时并发进行业务处理。设计应考虑灵活可扩展性。在异常情况下系统遇到性能 瓶颈，可通过硬件设备的扩展来平衡负载。 3) 灵活性 平台应考虑适当的灵活性，尤其是在业务基本功能组件的重用方面。整个系统分为 务台 、事件管理、问题管理、变更管理、配置管理和知识库管理等，虽然各个模块都有其自己的的业务功能，但各个模块之间也有共同的数据基础，和相似的业务功能以及流程。通过采用适当的技术可以增加系统的重用性，而且有助于清晰划分系统结构和有效的开发、维护和管理。 4) 系统集成与接口 系统应实现与邮件系统 、监控系统、和呼叫中心等其他自助服务系统的集成。 11 第四章 系统设计 统总体设计 构框架设计 图 4统总体结构图 从上图中服务管理平台线框部分即为 务管理系统，可以看的出，其设计是实现了 事件管理、问题管理、变更管理、配置管理等主要流程模块构成。通过 务管理系统的建设以及同其他管理系统的配合，可以为银行业务部门提供高质量高效率的服务。 构框架设计 系统逻辑架构设计如图 4 12 图 4统逻辑架构图 从 2据展现，应用服务器，数据库服务器。三 层结构可以集中在一台机器上可以分布在不同的主机设备中。客户端可同时采用 现灵活接入； 台采用关系数据库其他同类产品，所有数据集中存储，方便管理。数据库服务器与应用服务器之间采用 接，并建有缓存机制，加快数据的读取。 热备份（ ，可极大的提高系统的可用性，可靠性和性能。应用服务器与监控平台之间具有事件和 配置数据接口，用于两个平台之间的数据同步。 全设计方案 鉴于本系统是银行 务管理的重要核心系统，对系统安全方面的考虑和设计就更为重要。 1) 主机安全控制 从图 以看出， 务器和应用服务器可设计城支持多服务器的负载均衡和热备份，大大提高系统的可靠性。当一台主机出现故障时，另外一台可以继续提供服务。 2) 网络安全控制 系统所有用户均处于办公网段，而系统服务器在生产网段，因此系统用 13 户访问 中代理方式实现。为了保证安全性，在应用身份鉴别的基础上另外采用了网络 身份认证方式，认证用户名和密码均采用 号和密码，从而实现以实现用用户实名制方式访问应用。 3) 应用安全控制 通过用户进行登录控制和角色权限设置，来防止出现非法访问和操作。系统区分系统管理员与普通用户角色。系统管理员无法直接操作业务，只饿能执行系统管理功能；业务用户角色之能使用业务功能，无法使用系统管理功能。 系统具有自动 能。即用户登录应用系统后，工作暂停时间达到或超过15 分钟的，应用系统会要求用户重新登录应验证身份。 系统有详细的应用日志信息，并保 留系统操作重要交易日志，便于时候监督以及稽核需要。 点分析与解决思路 本方案实施的难点在于通过本系统与其他周边系统的集成，让 务管理系统的效率得到更充分的发挥，这也是本方案的特色所在。 1) 与呼叫中心的集成 该系统通过电话提供了一个统一的技术服务，专业的服务人员接受各种事件，通过 务管理系统，各种事件将迅速和有效地转移，所有事件提供初步支持从一线，二线提供软件和其他支持，处理，记录和跟踪事件起了一个非常大的帮助 。 2) 与主机监控系统的集成 银行通常有很多大型主机，一般是依靠主机设备自带的监控 软件进行监控，并由机房运行的人员定时查看监控信息。当故障发生后，是无法实时处理的，需要登录 记事件，然后转发到二线支持人员处理。所有，处理的及时性无法得到保障。在解决方案中，我们考虑把系统与主机监控系统进行集成，对监控系统收集的事件根据过滤规则进行过滤处理，当发生一定级的的故障后，会实时在系统中自动生成事件单，并自动飞陪象形的二线人员进行处理，这样加快了事件处理得速度和效率。 3) 与邮件系统集成 为提醒相关人员登录系统查看和处理相关的事件，以免影响业务，但该系统和邮件集成设计系统的设计，在相关 的事件，提醒相关人员及时通过邮件。也可以在文件的分发，预定义的超时处理，自动升级没有事件相关的人事主管直接发邮件提醒火。该系统将调用外部邮件系统的系统用户发送电子邮件通知 。 能模块设计 整个 包括 11个流程和功能。限于篇幅看 14 率，本文的研究内容只涉及对服务支持（ 关并行比较流行的几个流程进行研究设计，包括：服务台（ IT 、事件管理 (问题管理 (变更管理 (配置管理 (以及知识库 (能。 能定义 整拟设计的银行 务管理系统包括以下功能摸板块：服务台管理模块 、事件管理模块、问题管理模块、变更管理模块、配置管理模块和知识库管理模块。下面将对各个功能模块给出具体的功能定义。 1. 服务台模块 服务台主要是实现用户或者客户和 持人员之间的交互窗口。该模块的主要功能有： 服务台人员的组成 角色设计 服务台基本 键绩效指标）设计 服务请求流程设计 服务支持体系 建立 服务台与其他服务无支持流程关系的设计 统计报表 2. 事件管理模块 事件管理模块主要是记录 、跟踪、监控业务部门对 理突发事件，快速相应、快速恢复，是故障对业务的影响最小化。该模块的主要功能有： 根据具体需求定制事件记录，提供事件记录的属性 支持事件记录的关闭和修改和创建、 支持事件记录的优先级（ 、影响（ 类别字段进行定义 创建事件记录自动创建 期、记录时间和 支持向事件记录时自动或者手动录入各种信息表述和解决方案信息 只有相关权限的人员才可以插卡、创建或者秀贵记录 可以方便定义自动升级处理（ 支持事件记录中 于服务台创建记录是粘贴必要的文件 提过对所有事件记录更新和解决活动的安全的历史审计日志 提供对各种事件记录的查询搜索 事件管理是可以实现事件受理、处理、跟踪和回访闭环管理 支持各种格式文档作为福建输入 关闭事件后，自动将解决事件的过程以及结果保存到知识库里，并提供以后查询 基 于 成各种统计报表 15 突发事件类别统计报表 突发事件频率统计报表 突发事件各种优先等级分析报表 突发事件各组别分类统计报表 3. 问题管理模块 问题管理模块对经常发生的事件进行分析，找出事件多次 、反复出现的根本原因。该模块的主要功能有： 问题的录入：通过事件管理创建一个问题，支持手动创建一个问题。 问题分类和优先级：支持按照问题的层次级别和内容定义问题的优先级 问题处理：支持 持问题报告的产生。 问题通知：可以通知任务，分配到个人，通知问题的详细信 息。 问题结束：问题经理选择了问题结束代码才能关闭当前问题。问题经理可以使用对应特权主动关闭问题。 问题审计：问题处理过程中所有的信息以及分析现就的过程都可以详细的记录下来。并自动等级问题记录的修改人信息。 问题的 醒功能：可以设置问题各阶段的处理期限，在逾期是发送邮件提醒，在显示列表中以特殊的醒目颜色标识 4. 变更管理模块 变更管理模块的作用是在对配置管理的内容进行修改时，可以进行追踪、审核、批准、实施和归档等。该模块的主要功能如下： 变更请求录入：支持多种变更请求的录入方式，包括由其他模块 ，比如事件管理、问题管理等创建一个变更请求，该变更请求与相关事件或者问题信息自动关联；同时支持手动创建一个变更请求。 变更分类和优先级：支持将变更请求分配到相应的人员，进行评估和授权等，没有授权的变更请求将不能得到实施。 变更处理：变更管理模块可与其他模块进行关联，如问题管理模块、事件管理模块、配置管理模块等，从变更管理中可以直接访问到相关联的其他模块信息。 变更升级和通知：变更支持任务分配到某人、需要某人审批变更是、变更开始时，通知手到影响或者关联的人员。通知的方式要灵活，比如支持邮件通知、电话和短信通知 等。 变更失败：变更流程失败后，可以进入失败查子过程，同时必须提供一个失败代码。变更失败代码支持自定义。 变更结束：变更经过变更流程处理后，可以关闭。关闭时，必须提供一个技术代码。结束代码支持自定义。可根据变更结束代码进行统计和查询。 5. 配置模块管理 配置管理的作用是管理 及记录所有配置变化的历史，确保其他各流程有效正确地运行。该模块的主要功能如下： 配置管理数据库：支持集中的配置管理数据库，存储艘有配置管理的数据和信息，为事件管理、问题管理、变更管理提供查询、诊断和纪律的基础，所有的配置 信息都需要记录在数据库里。 配置项标识：支持为新的配置项自动赋予唯一标识码，以便于管理。支 16 持多级层次话的结果描述配置项的关联逻辑，而且着用关联的逻辑能够以多层次的树状结构视图展现给操作者。 配置项显示：可以在配置视图中的任何节点通过点击进行机构扩展或收缩，可以通过鼠标右击来展示这个 的业务影响分析。 配置信息收集：支持配置项及其细节信息录入的导入，可以从其他管理平台导入到配置信息管理数据库中。 配置控制：支持在 整个生命周期内跟踪 状态，完成跟踪和审计。并提供安全控制，保证只有对应的权限管理人员 ，才可以跟新和创建配置信息。 审计和确认：支持 认和实际环境的一致性，从而确保配置信息的完整性。 支持统计报表。 6. 知识库管理模块 知识库管理模块只要是管理系统知识库，提供记录和检索等功能。知识库模块需要支持以下功能： 当事故但和呼叫记录处于挂壁状态，用户可以提供给备选方案。 支持对备选方案尽心评审。 支持分级检索功能，支持关键字检索 、模糊检索、分类检索等。 有专门的知识库管理流程，支持流程负责人、技术支持队伍协同工作，调整知识库中事件和问题的记录结构，以方便更快的检索 细设计 本系统中，各功能模块的设计和实现方式基本上是相同的，期中事件管理模块是银行 务管理系统的核心和基本模块本节以事件管理模块为例，介绍该模块的详细设计过程，主要包括流程内容表述 、流程设计、角色权限设计、界面字段设计、代码设计、表单设计、功能设计和邮件集成设计。 事件管理流程始于事件的接收和报告，结束于事件的解决。该流程包含如下主要内容。 事件接收和记录 这个关节是事件管理流程的起点。所有用户或系统报告的 步骤的目的是在事件发生时，可以快速准确 的发现，以协助事件的斩断和解决并通知先关人员。该步骤会收集并记录创建事件中所收集的信息。该环节的关键是信息的准确性和完整性。 分类和在线支持 事件本身是可以是一个用户申告的事件或服务请求，也可以是系统自身检测系统的警报或预警。对于每个事件，需要确定优先级、影响级和分类。如果没有现成的解决方案和临时解决措施，该事件将分配给合适的支持人员对此进行审查。该环节的关键是必要的支持库和正确的事件分派。 17 调查和诊断 如果支持人员无法解决事件，可运用问题库、诊断工具等进行更深入的分析研究找到恢复服务的临时措施 ，必要时可以调用多名支持人员以寻求解决措施。 解决和回复 支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认。 优先级为紧急的事件（紧急事件）和事件升级 对于紧急事件，服务台应立即提交给一线人员，有一线人员判断，上报给事件经理和相关管理层，有事件经理决定紧急事件的处理方式，却道得到最快最有效的解决。当事件的处理超过预期时间，将自动通知处理人员和相关管理层，以引起相关人员和管理人员的重视和参与。 结束事件 当用户确认事件结束后，此时可以技术 改事件，并在必要是更新知识库。 1) 事件管理流程总体设计 表 4件总体流程设计说明 序号 步骤名称 说明 责任人 件记录和分类 服务台对来自用户的事件进行详细记录，其中包括申告、咨询、故障、服务请求、问题类事件、终端故障处理 服务台富足在接受到事件后对事件进行分类和转发，终端故障处理、问题类事件转相应子流程处理、对申告、咨询、故障服务请求类事件进行转发 对于初步判断为紧急的事件马上升级到一线人员处理 对于非业务支撑维护职责范围的事件转给其他相关责任部门处理 服务台 始支持 属于服务台技能范围内可以处理的事件，服务台应尝试解决，如果无法解决，需及时升级到一线支持 不属于服务台职责范围的事件，立即分配到相应的一线支持 服务台 线尝试解决 一线支持人员在接收到服务台派发的事件后，进行调查诊断，尝试解决 对于需要变更解决的事件提出变更申请，通过变更流程实施解决方案 事件解决后在事件管理平台记录事件解决方案并更新事件状态 不能解决的事件，转 线尝试解决 一线支持 18 线尝试解决 二线支持人员接受事件后，进行调查诊断，尝试解决事件， 在必要的时候根据服务协议，联系第三方厂商帮助解决并负责核查 对于需要变更解决的事件提出变更申请，通过变更流程实施解决方案 事件解决后，在事件管平台记录事件解决方案并更新事件状态 制定事件内不能解决的事件，通告事件经理，由事件经理负责协调资源 二线支持 急事件再确认 一线支持人员在接收到服务台派发的紧急事件后，根据时事件的优先级标准再次确认事件是否为紧急事件 如果优先级确实紧急，则通知相应的管理层，并立即升级到事件经理，转 101紧急事件处理子流程 如不是，转 线尝试解决，开始正常事件 解决流程 一线支持 录解决方案细节 在事件得到解决后，各线支持人员负责详细记录事件的解决过程以及解决方案并更新事件信息 针对故障，一线 /二线支持必须记录业务恢复事件 服务台 一线支持 二线支持 闭事件 服务台与申报用户确认事件是否已经得到解决，如果成功解决，觉关闭事件；否则，事件不能成功关闭，重新开事件记录，并与原记录做关联，分拍到原处理人员继续处理 服务台在关闭事件的同时，必须同时确认事件单记录的业务回复事件是否准确 其他由一线或者二线人员自行创建的事件单，则有开单人员负责 关闭。 服务台 一线支持 二线支持 件处理的监控 负责监控所有未关闭的事件的处理状态，对接收到的超时警告予以及时关注，并负责协调资源，保证事件的最终解决 当事件优先级为紧急时，应按照紧急事件处理流程处理。 事件经理 101 紧急事件处理流程 事件经理负责协调紧急事件的处理，具体过程见紧急事件处理子流程 事件经理 19 102 故障事件处理子流程 故障处理子流程主要处理网点设备保障和维修进行处理的请求 基本的处理过程应该包括记录、开单、派单、现场支持、回单等步骤。可根据自己的运作情况具体话 一线 支持 二线支持 103 问题类事件处理子流程 问题类事件处理子流程是由于没有问题流程，在一线认为需要根本解决的事件带来的故障的时候需要升级的刘胜，具体过程见问题类事件处理子流程 一线支持 二线支持 2) （ 件记录和分类子流程设计 事件记录和分类子流程表述如下： 表 4件记录和分类子流程设计说明 序号 输入 输出 说明 步骤名称 责任人 话 监控系统 日常巡查 需要处理的事件 通过电话报告的事件，帮助服务台人员进行记录事件的表述和判断事件是否属于本职责范围 果认为是事件，则自行创建事件 接收和判断事件 服务台 一线支持 事件信息 是，进行事物分类处理 否，转 是，进行事物分类管理 否，直接关闭，补关键事件单 是否为服务台职责范围 服务台 一线支持 20 话 监控系统 日常巡查 新建的事件记录 创 建的事件记录应包括以下内容： 话，邮件，支行，部门 7设定事件状态为“以登记” 新建事物 服务台 一线支持 服务台 事件单 关闭的事件单 如果补属于对应的职责方位，直接把事件单状态设置为“关闭”，结束代码为拒绝“拒绝”，保存关闭 关闭 服务台 事件记录 相应的处理流程 是否是重复事件： 是，转 否 ,进行事件分类判断 是否为重复事件 服 务台 复事件 在重复事件但的“重复事件标记”中记录正在处理的事件单号，保存推出 重复事件处理 服务台 21 事件性质 相应的处理流程 根据事件性质区分不同的处理流程： 如果是终端故障处理，进行 103终端故障处理子流程 如果是问题类事件，进行 102 问题类事件子流程 件影响度，有限等级设定 事件性质区分 服务台 件记录 确定了影响度 ,范围和有限级的事件 根据上报的事件描述，判断对业务的影响程度和影响范围，系统自动子算出优先级别，服务台再根据 实际的情况来调整优先级别 事件影响度 服务台 事件优先级 相应的处理流程 优先级为紧急：进行 先级事件再确认 其他：进行 始支持 优先级为紧急 服务台 3) （ 一线支持尝试解决子流程设计 表 4线支持尝试解决子流程设计说明 序号 输入 输出 说明 步骤名称 责任人 件记录 一线处理 如果属于分派错误，则必须退单给服务台，并由服务台转派到到负责该业务的其他人，在退单时候，必须将报障的详细聂荣，排除本本部门原因等内容告知服务台 如接受，则此时事件状态为“一线处理中”； 如果判断接收到的事件是一个重复事件，则在事件单中记录重复事件单的单好，同时设置“重复事件标记”，此时状态置为和接受事件分配 一线支持 22 原重复事件一致的状态，继续原单的处理。 事件记录 一线处理 判断是否派给二线的回单 是，则判断时候有解决方案 是，转 用解决方案 否，转 续分配给二线解决 否，则继续判断是否为紧急事件 是否二线回单 一线支持 事件单 紧急事件处理子流程 判断是否紧急事件： 否，转 试处理寻找方案 是，一线支持发现该事件的 影响程度和优先级可以上升到紧急事件的程序；即转到 101 紧急事件处理子流程；同时转 是否紧急事件 一线支持 件记录 解决方案 一线支持借助工具或运用自己技能尝试找出解决方案 尝试找出解决方案 一线支持 找到解决方案 ,转 没有解决方案，转 时通知二线事件经理有事件升级到二线支持 是否有解决方案 一线支持 件记录 解决方案 一线支持实施解决方案，实习解决方案的过程，需要和相 关的申告放共同确认方案是否有效 应用解决方案 一线支持 23 是，转 ，转 续处理，同时通知事件经理 是否解决 件记录 分配到额先的事件单 一线支持选择相应的二线支持人员分派事件单，此时状态为“分配到二线” 分配到二线支持 一线支持 件记录 系统通知 将事件单的优先级修改为“紧急”， 务管理平台自动将优先级为紧急的事件告知经理和管理层，并上报信息技术部 通知事件经理管理层 一线支持 流程这个过程的实现 是通过不同的角色和责任的过程中实现的，所以每一个过程中的作用可以被定义为一个集合的系列工作，在实际的操作和管理，不同的人会有不同的责任，也可能被赋予更多的责任，同时，可以被委派人员结构管理职责。 1） 角色设计 表 4统角色配置 流程 角色 权限 描述 管理员 系统管理员 任何操作 系统管理员 事 件 管 理 流 程 服务台 新建，更新，关闭交互事件； 新建，更新，关闭突发事件 服务台人员 一线支持 新建，更新，解决，等待第三方，升级为问题的事件； 关闭，重新打开，接收，决绝突发事件 一线支持人 员 24 二线支持 更新，解决，等待第三方，升级为问题的事件； 重新打开，接受，拒绝突发事件 二线支持人员 部门事件经理 更新，解决，等待第三方，升级为问题的事件； 关闭，接受，拒绝突发事件 部门事件经理 事件经理 新建，更新，解决，等待第三方，升级为问题的事件； 关闭，重新打开，接收，决绝突发事件 事件经理 2） 角色和权限配置 对于用户来说，不同的流程模块中可以有不同的权限和角色，对应不同的配置文件。每个角色的信息和权限需要求配置文件来配置和实现 表 4色权 限配置设计 流程 角色 备注 配置文件 突发事件 服务台 服务台人员 发事件 一线支持 一线支持 发事件 二线支持 二线支持 发事件 事件经理 事件经理 25 表 4顶 部 公 共 信 息 字段描述 数据库字段名字 是否添加字段（ Y/N)