IT服务需求分析报告.doc

IT服务需求分析报告(全部)文档说明目录1项目背景42项目运维访谈介绍52.1受访者52.2文件63运维现状与差距分析73.1信息系统服务内容清单73.1.1面向用户服务目录73.1.2运维服务详细内容73.2维护现状总结与ITSM差距分析123.2.1事件流程/服务台123.2.2问题流程143.2.3变更流程163.2.4配置流程184本期需求分析204.1本期实施范围和运维管理模式204.2本期XX运维管理实施内容214.2.1运维电子化平台的部署224.2.2统一受理服务台234.2.3事件流程324.2.4问题流程484.2.5变更流程524.2.6配置流程624.2.7知识管理674.2.8升级764.2.9催办784.2.10回访784.2.11系统权限784.2.12衡量指标与报表784.2.13接口定义835非功能性需求886附录A916.1XX部运维现状916.1.1各应用对象维护现状917附录B1041 项目背景当今通信市场正由传统的以通信网和市场为中心的竞争转变为以客户为中心的服务质量的竞争。为在新形势下，利用现有资源，提高现有的维护工作效率，XXX建设了新大楼和亦庄两个XX中心机房，以统一为BSS、OSS、MSS等关键业务系统提供支撑服务，面对BSS、OSS、MSS等关键业务系统的复杂多样性和不断扩充的业务需求，如何保障各业务系统的正常稳定运行，从而确保并逐步提升XX的服务质量，迫切要求建立一个能够对XX机房负责承载的业务系统进行集中监控、集中维护、集中管理的信息安全和网管监控系统。XX信息安全和网管监控系统应不仅能够对系统的网络边界、核心网段提供安全防护，及时监测并发现各增值业务系统中存在的、潜在的各类问题，以保证系统的稳定运行和业务的正常开展；同时还将对服务和运行维护工作进行规范化、流程化管理。通过发现、总结和挖掘所存在问题，不断明确管理重点并优化管理流程，从而加强服务和运行维护管理能力、提高服务和运行维护工作效率、改善服务和运行维护工作质量，进而保证各关键业务系统服务质量和运行维护水平的可持续性提升。2 项目运维访谈介绍2006-2010年XXXX战略的重点是：以“统一规划、规范管理、分步实施、创造价值“为指导原则，全面开展应用系统的整合、数据中心的整合、以及DCN网络的整合。伴随数据中心整合的脚步，XX运维集中化也提到了议事日程上。在运维集中化战略的大前提下项目组在3月针对XX基础架构部分进行了初步的网络、系统和平台的运维现状调研，受到了XX部主管领导的重视，并指出运维工作不能孤立的划分为基础架构或应用等层面，应从服务对象及维护对象着手进行调研，并为XX建成后的统一运维提出可行性的方案作为访谈目标之一。为了实现建立统一运维体系调研全面的运维现状，项目组于4月进行了运维深度访谈，对XX部所维护的各应用系统软硬件现状、维护现状、维护流程等进行了全面而深入的了解，本文结合访谈现状，进行了需求汇总和差距分析。访谈记录详见附录2.1 受访者本次调研中访谈了以下人员：姓名职务访谈日期2.2 文件本次访谈中获取了以下XXX集团的文件：文件类型名称文件文件文件文件文件文件文件文件文件图表图表图表3 运维现状与差距分析3.1 信息系统服务内容清单3.1.1 面向用户服务目录序号服务目录1系统软件/技术问题咨询2系统软件/故障申告3系统软件/功能变更开发4系统软件/功能配置变更5系统权限/新建/删除/变更6系统硬件变更：办公/生产7网络故障申告：办公/生产8网络变更：办公/生产9安全管理：办公/生产3.1.2 运维服务详细内容软件服务桌面通用软件操作系统IE版本低或被恶意修改IE打不开二级链接IE经常死机或自动退出IE使用或操作类问题IE无法浏览内网或外网备份或导数据补丁版本低操作中系统报错或蓝屏带入带出域更改用户配置文件共享文件夹类计算机名称不符合要求计算机升级重装OS弱口令使用方面的咨询网络设置问题无法登录系统系统无法启动系统运行慢硬件驱动程序用户帐号或密码问题域策略应用问题其他常用工具AcrobatMcAfee问题MSN问题Office类问题超级解霸解压缩工具金山词霸看图软件其他部门应用系统输入法其他邮件问题OE中无法收发邮件outlook使用咨询POP方式问题PST文件过大或出错WEB页邮箱问题查杀邮件内病毒打补丁导出数据、联系人、个人通讯录导入数据第三方软件等影响无法发送邮件更改邮箱名称共享联系人共享日历其他删除帐号设置个人签名使用类咨询添加其他邮箱添加新个人文件夹无法ping通邮件服务器（可以ping通网关）无法发送某邮件地址新建帐号邮件规则类问题邮件组问题邮箱已满或被关闭帐号到期重新配置Outlook基础架构软件中间件BEA Weblogic问题tuxedo问题IBM Webspere问题MQ问题BizTalk问题数据库Oracle9iDB2MS SQLNCR Teredata操作系统UnixWindows基础应用平台安全监控系统防病毒系统认证及加密系统网管系统应用系统故障申告/功能变更BSSXX计费帐务系统整合（南方一期）南方客户服务系统集团客户投诉中心系统OSS新网络资源管理系统原XX控股骨干网资源管理系统原控股安徽省本地资源管理系统EAIXXX业务订单调度系统EAI联接系统MSSERP系统人力资源管理系统ERP系统财务资源管理系统集团门户和办公系统邮件系统域管理系统防病毒系统系统管理综合统计信息管理系统硬件服务终端外设类笔记本借用领用回收声卡显示卡其他台式机光驱回收键盘借用联系维修商维修领用内存声卡鼠标网卡显示卡显示器硬盘主板其他其他主机类故障/扩容/升级/迁移/割接/备份服务器HpIBMSunDell其他存储HpIBMSunEMC存储服务器网络设备故障/扩容/割接骨干网（核心、汇聚、接入）路由器交换机Hub光电转换器线路拨号服务器Modem局域网（办公、生产、数据中心）路由器交换机Hub光电转换器线路拨号服务器Modem负载均衡设备安全设备入侵检测防火墙机房设备空调电源设备UPS机房内布线架机柜其他硬件设备网络服务Ipsec vpn,远程拨号业务服务器端问题Wlan类VPN无法登录VPN在家中设置拨号安装VPN Client其他网关ping不通视频会议网口问题网线问题新开网口用户ping服务器严重丢包制作网线DCN网络MSS网网控DCN网其他安全服务终端安全防病毒Virusscan 、EPO Agent软件损坏感染病毒补丁安装不完全感染病毒各种补丁（系统补丁，重要临时补丁，Outlook补丁等）安装完全，Virusscan、EPO Agent运行正常情况下感染病毒。客户端私自安装盗版非法软件感染病毒客户端用机显示感染病毒，但无法自动清除域外计算机感染病毒漏洞攻击应用系统安全网络安全DCN网络安全3.2 维护现状总结与ITSM差距分析3.2.1 事件流程/服务台 简介描述 (事件管理):管理事件的处理过程以确保尽快恢复到正常的运作。减小对业务运作的影响。 描述 (服务台): 接收，记录，分类，一线支持，解决和关闭问题；监控跟踪事件并及时进行各方反馈的收集及沟通；改善用户关系，响应时间，与用户沟通和进行有效的团队合作。为管理层集中提供管理信息。 对应关系对XX部来说事件流程的管理范围应是所有运维工作过程中的突发事件、服务请求、疑问、咨询等，如下表显示哪些用户请求属于事件流程管理范畴事件管理范畴服务目录1系统软件/技术问题咨询2系统软件/故障申告5预授权的系统权限新建/删除/变更6系统硬件故障：办公/生产7网络故障申告：办公/生产8安全事件：办公/生产9其他用户突发事件请求 流程情况：XX部初步定义了运维管理规程和故障处理流程，但没有明确定义的事件管理流程规范。上述运维管理规程定义了故障的分级、升级、等运维指标，还定义了如“先局内后局外；先本端后对端；先交换后IP。先重点后一般；先语音后数据；先调通后修理，故障消除后立即复原”的故障处理原则，并使用适当的记录和文档资料模板辅助流程的执行，包括：需求变更单模版等。在实际工作中，由于各应用系统分散运维，运维水平参差不齐，当前的事件处理部分由运维人员手工处理，除重大故障和告警等故障外基本没有事件记录，使得实际的运维处理过程和书面制定的规范有些差异。事件处理部分有两块业务从人员技能构成到流程管理相对比较完整：终端支持运维由于较早的投入了ITSM的管理方法及电子工具，目前事件流程相对比较规范，但是由于该电子系统并未延伸到后台管理，使这部分业务在事件流程的整个生命周期中对后台部分的支持管控显得不太有力，造成服务质量的不统一，前后台知识传递不顺畅。客服系统支持部分有明确的人员分工、故障分级等，但故障记录还采用手工方式，咨询及其他受理并不记录。这两块的事件管理已经具备基本雏形，有专人专管，并且针对事件流程有绩效考核在紧急事件的处理的工作细化方面，定义了部分紧急事件处理流程。在实际工作中，各维护负责人会根据经验判断何种故障为紧急故障，并协调相关资源和及时上报。在紧急故障处理中，专门明确定义了沟通的方式和方法，明确定义责任体系，按照组织架构中的职责体系进行协调处理。所有紧急故障或者申告均会进行总结和分析，并有后续行动计划不是所有的事件均进行记录，终端支持部分是全部来话均进行了记录，客服支持业务是故障均会有详细记录，ERP等有自身的Web网站支持，其他部分业务对于维护人员主动发现的问题或者直接找到维护人员处理的问题，则没有记录，但是重大故障都会有记录汇报故障情况、原因等。定义了故障的分类和处理时限以及优先级等，但对于事件严重等级和处理时限的定义由故障发起人自己判断，有一定的主观性。没有专人对事件管理流程负责，部分事件流程基本缺失，没有明确定义的事件流程衡量指标和流程监控。终端支持有较完整的知识库，但是个文档库，不太方便查阅；其他事件流程暂无知识经验库积累。 系统情况：在流程的工具化层面只有客户端支持有一个hp openview helpdesk作为流程平台；ERP方面有一个可以进行受理、查询、关闭的公开Web网站，但不是一个完整的流程平台。其他业务均无流程工具支持。作为日常运维监控的另一个重要方面系统监控平台和网络监控等，可以实现对事件的主动告警，由于系统分散在不同机房，监控工具随各机房配备监控工具，没有统一的系统监控和安全管理，所以也没有实现监控系统和运维管理平台之间的集成。 人员情况：在日常运维工作分工方面，各业务分散运维，没有统一模式，除客服系统运维724外，其他业务运维基本上都是5*8，XX运维人员主要承担系统管理、协调内部业务部门及开发厂商、代维厂商的职责，应用运维按应用系统种类划分，基础架构运维按网络、主机、数据库、存储等IT领域划分岗位；硬件主要有原厂商的维保，软件及应用维护主要由代维厂商实际执行。 优势与主要问题：内部IT客户端支持及客服系统支持人员结构相对较完整，业务成熟度高，积累了丰富的流程经验。有部分电子化的监控和运维管理平台，大部分故障均有详细的申告记录和处理记录。但同时也存在一定的问题，如监控平台和服务管理平台之间的集成上，经常由于同一个问题引发告警风暴。除客户端支持外其他业务基本没有专人对事件管理流程负责，没有对于流程的衡量和考核指标，在流程的电子化平台执行中存在一定的问题，如对事件的及时处理缺乏考核。该平台基本上是一个工作流处理平台，也就没有和其他流程之间衔接的说法。 3.2.2 问题流程 简介描述: 事件控制，问题控制，错误控制，上报，症结原因分析和预防性管理确保预防问题的发生，如果问题已经发生，则预防其再次发生。问题管理为管理层提供有价值的管理信息。 流程情况：目前在运维工作中未明确将事件和问题进行区分，没有专门的问题管理规范流程。也没有专门的人员从事该流程管理工作。但在实际操作上，客户已经有了一些初步的问题和事件的划分概念，并在实际工作中尝试。如存在部分与问题管理相关的活动和工作要求，如故障处理原则中“先调通后修理，故障消除后立即复原”就是要求在故障处理中，在采取一定措施恢复服务后，再进行深层原因的分析和彻底查找解决方案和规避措施，同时会提交故障分析报告，并据此进行其它潜在问题的研究和预防。由于缺乏正式的衡量点，目前的工作主要是依赖运维人员的经验和意识进行，处于自发状态。从主动性问题防范的角度，目前重复规律性的事件和趋势分析主要依赖对运维人员和代维厂商的的经验和主动工作意识，没有明确的流程活动定义。从实际工作的角度，运维人员对于重大问题均会进行问题根本原因的查找、解决方案实施、处理结果汇报等工作，但没有采用专门的问题分类、分级解决方法，可能导致资源使用和解决方案有效利用方面的欠缺。没有专门针对性的问题流程管理和责任人，也没有流程的监控和优化活动。事件流程和问题流程之间有一些自发默认的流程衔接。对于问题的根本原因分析后，会发起变更来解决问题，但没有明确的流程衔接定义。 人员情况：基于XX部组织架构和流程的现状，没有设立专门的问题经理。一般由维护人员担负问题处理专家的职责。 系统情况：随着XX的建设，集中的网络和安全监控系统将会为问题的预防和发现提供便捷的信息平台。在维护管理平台方面，现有的终端业务运维管理系统中没有区分事件和问题，将事件和问题统一处理。其他应用业务没有运维系统，也就谈不上对问题管理的系统支持了。 优势与主要问题：没有对问题和事件有比较清晰的划分，基本都没有问题管理流程，大家处理问题的模式基本都是被动管理，即有了问题，通过主管经理召开会议讨论的方式进行。处于一种初始的状态，更谈不上完善的流程和流程监控。应持续对运维人员灌输问题管理的相关概念和内容，树立问题管理的意识。需要对所有重大问题均深入进行分析，对分析结果通过变更进行改进等。针对标准的问题管理的要求，缺乏针对问题的分类、解决优先级、分析结果。缺乏流程规范，流程负责人以及流程的衔接。3.2.3 变更流程 简介描述: 变更记录，影响评估，时间安排，计划与实施。有效地制定变更决策并安排工作进度。提高分布式企业中变更的可视性和通报能力。减少变更带来的负面影响。 对应关系变更管理范畴服务目录1系统软件/功能变更开发2系统软件/功能配置变更5须审批的系统权限新建/删除/变更6系统硬件变更：办公/生产7网络变更：办公/生产8安全管理变更：办公/生产9其他IT环境内的变更 流程情况：从流程规范的角度看，XX部没有设计和定义统一的变更管理流程。但各应用系统都有类似的文档来描述需求功能等变更管理流程，如需求变更流程、系统割接管理规范和软件版本管理规范。为配合应用软件版本、需求变更的变更管理流程执行，还定义了一系列的辅助表格工具，如软件版本升级需求申请表、需求申请单和需求变更完工单等模板。实际工作中，没有严格按照该流程规范执行，各应用的变更基本上使用一个约定俗成的模式进行，如果认为对前台业务有影响，均有实施方案、计划以及测试方案，测试报告等，需要按照变更内容向有关的部门提交申请并得到批准后实施，实施前会向影响用户发布变更影响通知。现有范围的应用系统的变更管理流程主要有业务部门发起，IT组件的变更由维护人员负责，没有设定明确的流程责任人负责对流程的使用效果、范围进行监控和提升。从流程衔接的角度，在变更处理中，会用到一些配置信息，没有流程或者工具支撑。 人员情况：没有正式定义变更流程经理的职责，任何人员都可以根据情况发起变更，召集相关部门开会讨论。在规划、协调，实施过程中各级运维部门和系统集成商均会涉及其中。 系统情况：没有工具支撑。对于重大的影响前台业务的变更，一般会通过OA系统发布变更通知。 优势与主要问题：针对应用系统的新版本发布有流程规范，重大IT基础架构的变更有割接管理流程，总的来说，对于影响到一线前台业务的变更控制有约定俗成的变更流程，但对于一般的变更没有流程控制。没有一个统一的变更管理流程规范，各个应用业务均制定了有关变更方面的流程。由于有些应用系统的IT设备位于其他部门机房托管，其IT组件和应用系统的变更完全独立。变更管理和其他流程没有定义的流程衔接，但实际工作中，均会有事件或者问题引发变更，变更处理中，可能会修改配置。3.2.4 配置流程 简介描述: 验证，控制，状态管理，项目验证 (硬件，软件，人员，位置，文档，业务流程)，构成IT环境及现有环境中的相互关系；提高IT资产管理水平，更好地支持变更管理；改善事件与问题管理；便于评估法规条例的依从状况。 流程情况：XX部尚未定义配置管理流程，实际工作中仅完成了部分资产管理的工作。当前的配置管理基本上处于各小组范围内进行配置管理工作，没有配置管理的策略，配置信息基本在各管理员自己掌握，配置信息的详细程度，对运维支撑的程度没有统一的标准，而且存在大量配置信息与原有存档不一致的情况，对那些IT组件进行配置管理以及管理到什么程度没有定义，完全处于相关IT组件负责人的个人能力。从整体上看，没有完整的配置管理流程，也就没有与其它运维流程形成明确的衔接。从访谈上看，IT组件的管理员普遍意识到配置管理在日常运维工作中的重要性，并且希望在本期项目中能帮助他们初步建立统一CMDB。 人员情况：XX部目前没有定义配置管理的专门角色。在现有情况下主要配置信息在各管理员手中，有一部分在代维厂商处管理。但上述所有的管理工作主要依赖于系统负责人的经验和意识。从流程上看，处于较为欠缺的状态 系统情况：所有的配置信息均保存在相关配置项负责人自己手中，但没有完整意义上的配置管理电子系统。 优势与主要问题：配置管理的工作在实际工作并未开展，各IT组件负责人掌握一部分配置信息，对部分关键IT组件有统一的命名规范和标签。但没有完善的配置管理流程规范，尚没有将其与其他运维流程，如事件/故障等管理流程相衔接。技术信息的配置没有统一要求。由系统或业务应用的支持人员根据自己的经验进行管理。但各IT组件负责人已经意识到配置管理的重要性，在配置管理推广上应会起到正面的作用，但仍需加强运维人员的配置管理理念。实施配置管理的初始化工作较艰巨。4 本期需求分析4.1 本期实施范围和运维管理模式结合上述运维现状及本期项目就是要保障XX自身运维管理的运维目标，如下图所示：附图1. 近期建设范围 首先保证XX建成后其内部运维管理的覆盖是全面的，流程是顺畅的，能达到协调各责任人快速处理XX内部运维突发事件恢复服务的第一目标。另外根据XX部运维集中的规划，将在本期建立统一接入的客户受理接口，将对XX部目前所支持的业务服务和内部IT客户的受理接口统一，实现用户满意度的提升，服务质量的监督等。这也是充分契合XX集团 “服务编织未来”的企业理念，是XX集团对内部及外部的运维支持趋近于统一的明智之选。如上图所示的红色T字型部位即是本期实施的重点，T字型框架也是未来实现统一的IT服务支撑体系的骨架，随着本期项目的顺利开展，伴随应用系统的整合和DCN网络的整合，将会分期分批的不断在骨架中填充更多应用系统的支持，在建设中不断校正。附图2. 目标运维业务模式如上图所示依据信息化建设规划建立全面的统一的服务台是XX信息系统服务支撑体系建设的目标之一，作为各系统、用户受理的单一联系点，全面支持网管/安全突发事件、客户端桌面支持业务、客服系统支持业务，及其他各专业应用系统的支持受理工作，并围绕统一受理平台展开各管理流程的建设和推广工作，将规划中的流程虚拟角色定义在日常运维工作中得以实现。4.2 本期XX运维管理实施内容综上本期的实施范围建议：q 运维电子化平台的部署- 平台功能的需求分析- 平台的安装、部署q 统一受理平台的建设- 建设统一受理服务台- 接受来自客户端、客服系统、其他应用系统及DCN网络用户的服务受理q 事件管理流程的部署- XX系统突发事件流程设计、实施q 问题管理流程的部署- XX系统问题流程设计、实施q 配置管理流程的部署- XX配置流程设计、实施- XX配置信息管理库建设q 变更管理流程的部署- XX变更流程设计、实施q 运维服务管理平台与监控管理平台/安全管理平台接口的实现- 运维服务管理平台能够接受来自于监控管理平台和安全管理平台的事件信息，然后按照事件管理流程进行处理，当处理结束后，将反馈信息返回给监控管理平台或安全管理平台中。- 运维服务管理平台能够接受来自于监控管理平台的配置信息，且当运维服务管理平台的配置信息发生变动后，能够将该变动信息发送到监控管理平台中。- 服务管理平台提供查看CI的接口。q 运维服务管理平台与其他管理系统接口的实现- 服务管理平台可以发送信息到邮件系统4.2.1 运维电子化平台的部署作为有效支撑服务体系建设的工具化手段，将使用BMC公司的Remedy产品在本期建设XX运维管理平台，系统部署如下图所示：4.2.2 统一受理服务台4.2.2.1 服务台现状目前XX部服务台情况如下表所示：应用系统电话号码是否使用呼叫中心设备有无电子工具支持运维模式终端桌面支持是有 hp openview5 X 9客服系统支持是无7 X 24ERP系统支持否有 ERP Web网站5 X 9其他专业系统否无5 X 9利用现有呼叫中心设备的IVR支持如下示意：4.2.2.2 本期建设统一受理服务台方案比较 方案一： 设置统一服务台热线，现有呼叫中心利旧利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台 配备服务台人员配置专职的服务台人员，受理除客户端支持、客服系统支持外的其他应用系统和IT问题，该服务台受集团信息化部直接管辖。客户端支持、客服系统支持及新设立的统一服务台人员构成了信息化部统一服务台 修改IVR语音，增加其他系统问题修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音配置到新设置的服务台人员受理 新建其他系统问题服务台支持人员使用本期流程平台系统终端支持、客服支持仍采用现有支持方式，在本期不做改变。其他系统问题全部记录在本期Remedy流程平台系统上，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户及外部部门来说是透明的。如图：附图3. 服务台模式方案一 优点对原有支持模式改动较小，对服务提供质量降低的风险较小；实施周期短； 缺点由于其他系统问题并不是頻发，建立初期服务台受理量较低；并未改善客户端支持及客服系统支持等日常支持的服务水平；如配备新人须具备基本的IT系统技能，否则在设立之初可能会用户造成服务不够专业的印象 方案二 设置统一服务台热线，现有呼叫中心利旧利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台 复用XX服务台人员无须配备新的服务台人员，由现有XX服务台人员受理除客服系统支持外的终端问题、其他应用系统和IT问题，该服务台管理模式不变。重新调整的具备多种应用受理的XX热线人员、客服系统支持人员构成了信息化部统一服务台。换句话说原XX服务台职能变更为XX部对外统一受理服务台 修改IVR语音，增加其他系统问题修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音配置到现有XX热线人员技能组 XX服务台使用本期流程平台系统客服支持仍采用现有支持方式，在本期不做改变。XX服务台将现有HP Openview摒弃，使用新的Remedy流程平台处理事件，客户端问题从受理到处理各环节均在Remedy流程平台上实现；其他系统问题全部记录在本期Remedy流程平台系统上，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户及外部部门来说是透明的。如图：附图4. 服务台模式方案二 优点1、现有XX热线支持人员结构完整，流程角色清晰，并积累了长时间的管理经验；2、具备服务台应有技能，较易扩展到支持其他应用系统的综合受理职能；3、现有XX终端支持具备ITSM的基本理念、较习惯使用ITSM领域的相关电子工具；4、内部客户端支持业务与各办公系统、基础架构部分的业务联系较紧密，将这部分业务在本期一次性完整的迁移到统一运维体系框架中，完善原有运维流程，如将前台人员及后台管理员纳入统一的平台中；5、修正原有系统的诸多使用缺陷，完善考核质量监控体系等 缺点1、实施周期相对方案一较长，须将现有系统的功能、数据等在新系统中实现 方案三 设置统一服务台热线，现有呼叫中心利旧利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台 复用XX客服支持服务台人员无须配备新的服务台人员，由现有XX服务台人员受理除终端系统支持外的客服系统问题、其他应用系统和IT问题，该服务台管理模式不变。重新调整的具备多种应用受理的XX热线人员、终端系统支持人员构成了信息化部统一服务台。换句话说原XX服务台职能变更为XX部对外统一受理服务台 修改IVR语音，增加其他系统问题修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音配置到现有XX热线人员技能组 XX服务台使用本期流程平台系统终端支持仍采用现有支持方式，在本期不做改变。XX服务台使用新的Remedy流程平台处理事件，客服系统问题从受理到处理各环节均在Remedy流程平台上实现；其他系统问题全部记录在本期Remedy流程平台系统上，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户及外部部门来说是透明的。如图：附图5. 服务台模式方案三 优点1、现有XX热线支持人员结构完整，流程角色清晰；2、客服系统是个小而全的系统，现有XX完全具备服务台技能，较易扩展到支持其他应用系统的综合受理职能；3、本期客服系统作为第一批搬迁XX的系统，有利于完善原有运维流程，如将前台人员及后台管理员纳入统一的平台中；5、服务支持模式为7 X 24 缺点1、实施周期相对方案一较长2、支持人员由无电子工具到使用流程平台工具，带来的适应性问题3、原有热线人员数量配备可能不足 方案四（我方推荐方案） 设置统一服务台热线，现有呼叫中心利旧利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台；虚拟服务台由实体技能组来组成，各技能组权限独立，即各技能组受理并记录的工单，只有各帮助台技能组察看和管理。 复用XX客服支持服务台人员无须配备新的服务台人员，由现有XX服务台人员受理除客服系统支持外的终端问题、其他应用系统和IT问题，该服务台管理模式不变。重新调整的具备多种应用受理的XX热线人员、客服系统支持人员构成了信息化部统一服务台。换句话说原XX服务台职能变更为XX部对外统一受理服务台 修改IVR语音，增加其他系统问题；增加XX在IVR上的分支修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音配置到现有XX热线人员技能组；将现有XX作为目前语音向导中的一个分支设立，以确保未来条件允许情况下所有运维支持统一拨打服务台号码可获得全部支持。详见附图6. 统一服务台全部使用本期流程平台系统为达到统一服务标准，规范服务流程的目的，建议服务台及前后台支持人员全部使用新的Remedy流程平台处理事件，从受理到处理各环节均在Remedy流程平台上实现；其他系统问题全部由终端支持受理并记录在本期Remedy流程平台系统上，通过给服务台人员配置各系统支持人员一览表，达到系统外分派处理的目得，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户及外部部门来说是透明的。如图：附图6. 服务台模式方案四 优点1、真正实现了统一服务台的基础设置2、其他系统问题由XX终端支持，未来易于扩展支持全面的专业应用系统支持职能3、所有运维服务可以统一服务标准，提供可衡量的服务质量考核依据4、全部使用新的Remedy系统平台，前后台运维人员的可以在一个统一的平台中使用同一流程语言进行日常运维处理，大大提高了沟通和处理的效率5、使XX部信息系统规划中日常运维角色设置完整的系统平台中得以实现，利于新的服务体系架构的推广和调整 缺点1、实施周期较其他方案时间最长；推广难度较其他方案更高2、支持人员由无电子工具到使用流程平台工具，带来的适应性问题3、需要更多双方的资源调配 呼叫中心与流程平台结合流程平台Remedy支持与现有呼叫中心作结合，以达到用户电话呼入，自动弹出流程系统界面，并将用户基础信息直接导入，调取用户语言留言，预呼等接口功能。经厂家求证，Remedy本身并不提供与XX现有呼叫中心的成熟接口套件，需要另行开发。开发则需要CTI厂家提供接口开发包，但该开发包是需要单独购买的，所以在本期暂不考虑实现呼叫中心与流程平台的自动整合。当用户呼叫至人工坐席后，须手动调用起Remedy系统界面，填入用户主叫号码，可以自动回填该用户信息，前提是基础数据已经导入Remedy系统中。4.2.3 事件流程目前有故障报修流程，其工作模式类似于突发事件处理流程。4.2.3.1 事件的理解事件可以分为：突发事件和服务请求。突发事件，是指发生了非常规的运作情况，包括系统崩溃、软件故障、任何影响用户业务操作和系统正常运作的故障、以及影响业务流程或违背服务水平协议的情况。服务请求，是指用户的业务咨询、常规操作类的事情，并非导致故障的请求。如，重设用户密码。不是所有的突发事件都由用户产生，监控管理平台产生的告警也可引发事件。通常由帮助台负责记录事件相关信息，向用户提供对已知问题的处理方法，报告突发事件和尽快恢复服务，目的是在事件管理阶段获得尽可能高的事件解决率。突发事件基于相关配置元素的关键等级和影响度进行优先级分类。事件管理的责任是记录、分类、调查/诊断、解决已知问题、监控跟踪事件、与用户和问题管理流程交流、最终解决事件。4.2.3.2 本期事件管理实现的目标虽然XX的主要服务对象是XX集团内部，如何确立XX部的标牌服务形象，同时为XX的整合提供更好的运维支持，在现阶段，我们需要确立以下目标：1、 确立服务热线的标牌，在XX集团内部实现有IT事件发生找XX部的局面。从而实现帮助台的统一受理，即事件都由帮助台负责登记、派发。建议将现有XX热线定义为统一接入号码，树立XX服务热线品牌2、 形成闭环式的服务流程。服务台负责对用户进行回访，体系客户关怀。附图7. 事件处理闭环流程3、 设立帮助台、一线支持人员、二线支持人员、事件经理等流程角色，并将现有运维人员与流程角色进行匹配。4、 实现事件分类处理，不同技能的支持人员处理不同类别的事件请求。5、 确立事件的负责人，实现事件处理责任制。6、 实现突发事件的跟踪机制，帮助台可以随时了解到突发事件的处理情况，在必要时，实现突发事件催办。7、 实现突发事件的紧急程度划分，根据事件紧急程度不同，响应时间不同，解决时间不同，升级机制不同。8、 设立升级机制，根据突发事件的严重等级不同，设定不同的升级时间和升级策略。9、 建立知识共享机制，缩短突发事件处理的进程。10、 建立考核机制，具体方式以报表的形式体现。4.2.3.3 事件管理的差距分析目前来说，除了桌面维护部分有一个hp openview helpdesk流程外，其他各岗位的事件处理都没有流程系统进行约束，从而造成了以下的一些问题：1、 虽然设立了XX服务热线，但其功能仅仅局限在XX集团内部的桌面系统的维护上，面对网络、系统数据库等的事件处理，并没有发挥统一受理的职能。2、 各岗位的管理员每天处在繁忙的工作以及突发事件的处理中，却没有处理事件工作量的统计。3、 有时候，我们做了很多事情，却没有分清楚事情的轻重缓急，导致最后事情做了也没有得到认可。4、 没有时间上的约束，导致很多问题得不到有效的解决。5、 因为没有流程，很多人并不清楚自己在事件处理中应当担当的角色是什么？6、 缺乏知识共享，导致处理一些常规突发事件时必须找到某个人才可能将事件解决，导致事情延误。7、 目前因为流程上的缺陷，导致没有体现出很好的客户关怀。4.2.3.4 面临的挑战为了实现以上目标，我们还需要接受一些挑战：1、 根据目前状况，建设统一受理平台要求帮助台即能处理一般性的咨询请求、桌面系统的事件划分，还能受理客服系统等其他应用的咨询及报障，如果将网络、系统、应用等事件请求统一归入服务台，对服务台的处理能力形成挑战，比如专业事件描述是否能够准确，是否会给用户造成一定的麻烦等。2、 XX内部的规范可以统一，但很难约束其他部门和公司统一到帮助台来。如果用户遵循了我们的规范，却发现事件解决的效率降低了，在系统该启用的时候很容易出现这样的现象，如何规避这样的风险？3、 固有习惯事件处理方式的克服。4、 如果通过帮助台做客户回访目前可能造成帮助台工作量加大，是否能够承受？4.2.3.5 我们的建议为了确立运维支持中心的核心地位，提高运维质量，在现阶段，我们可以做到以下几点：1、 帮助台作为事件统一受理，负责记录用户反映的突发事件以及解决用户的服务请求。2、 帮助台有职责对人员信息进行维护，保障服务的及时性和有效性。3、 帮助台需要对事件进行合理划分，并根据事件类型进行优先等级的区分。当电话、Web事件同时进入帮助台，根据优先级进行决定受理顺序，同优先级以创建时间作为受理顺序4、 面对帮助台技能方面存在的压力，本期统一帮助台可以由现有XX帮助台部分人员和客服支持帮助台人员共同组成，通过语音技能设定，分拣来自客服座席的支持号码给客服系统代维人员，闲时也可以支持其他IT客户端问题5、 各管理员归纳一些常见事件的描述信息给帮助台，帮助服务台人员熟悉业务的基本概念。6、 根据管理员归纳的信息结果，在事件记录界面上设计可选项，有助于帮助台人员记录事件描述的准确性，实现事件分类的准确定位。7、 规范服务意识，即使在打破用户习惯的不利情况下也会让用户感觉到规范流程给他带来的优质的服务。8、 可以根据用户的级别不同、提交事件的类型不同实现不同的用户回访方式。9、 设立事件自动关闭时限，在事件处理完成后，没有得到客户确认响应一段时间后，事件可以实现自动关闭。4.2.3.6 事件管理流程总图附图8. 事件管理流程总流程概述该流程始于突发事件或系统故障的探测和报告，结束于问题的解决。该流程包含下述步骤：4.2.3.6.1 事件信息的监测和记录该步骤是事件管理流程的起点。所有客户报告的事件请求必须由此步骤开始。此步骤的目的是在事件发生时快速准确地发现故障，以协助事件的诊断和解决并通知相关支持人员。在此步骤中将会收集创建事件记录所需的信息。该步骤的关键是信息的准确性和完整性。4.2.3.6.2 分类和在线支持事件可以是一个变更请求、服务请求、信息请求或服务故障。对于服务故障，则需要确立该故障的优先级、影响度、紧急度和分类。若没有现成的解决方案或临时措施来恢复服务，该事件将分配给合适的支持人员对此进行调查。4.2.3.6.3 调查和诊断若在线无法解决的问题，必须进行更加深入的诊断以找到恢复服务的方法，必要时将可能使用多名技术员以寻求解决措施。在调查和诊断过过程中需要对以往案例解决方案进行查找，以期快速找到可能恢复的方法，需要实现知识库与事件及问题管理流程的联动，有效支撑事件的快速恢复4.2.3.6.4 解决和恢复通知客户解决方法或临时措施并加以实施。解决措施一旦成功，可以根据事件的处理过程难度、发生频率等因素判断生成知识案例库的解决方案，通过提交知识沉淀有效经验。4.2.3.6.5 事件请求结束当客户确认事件解决后，此时可以结束该事件请求并在必要时更新知识库。最后该事件得以结束。若客户对此解决方案不满意，则对该事件进行重新打开并再分派处理。事件请求结束后应由系统自动派生本次服务的满意度调查，并以邮件方式发送给事件提交者，提交者填写完毕后可以直接回复到系统中，由系统对调查结果进行归档并作报表统计数据源。满意度调查报告应包含本次服务满意度、响应满意度、处理满意度等几项调查。4.2.3.6.6 事件监控该步骤监控所有事件的生命周期。该步骤始于事件记录的创建，并在事件请求结束时终止。4.2.3.6.7 状态图表附图9. 事件状态表4.2.3.6.7.1 状态转移表状态新建已分派进行中的工作撤销待决已解决关闭新建 YNNNYN已分派NYYYYYN进行中的工作NYYYYN撤销NNNNNN待决NYYYYN已解决NYNNNY关闭NNNNNN4.2.3.6.7.2 状态转移4.2.3.6.7.2.1 当前事件状态为新建时状态变化为合法性事件描述相关信息已分派Y用户提交事件请求，分派到相应的处理人员或组通知被分派的组成员准备处理请求，并告知请求提交人请求的分派结果进行中的工作N未经过分派的过程，是不可能处于正在处理的状态的。撤销N未记录的事件请求，是不可能处于撤销状态的。待决N未经过分派的过程，是不可能处于正在等待的状态的。已解决Y在知识库中可以查到相关的解决方案时，问题不必再提交到支持组进行解决，客户可以自行关闭提交的请求关闭N未经过客户确认的解决方案4.2.3.6.7.2.2 当前事件状态为已分派时状态变化为合法性事件描述相关信息新建N新建确定为初试值，不可逆已分派Y支持组成员之间可以相互派转已分派到本组或本人的请求通知被分派的组成员准备处理请求，并告知分派请求的人员分派结果，同时通知分派者的主管经理请求被重新分派进行中的工作Y表明接单人响应请求并开始着手处理请求撤销Y事件请求提交人发现问题的解决方案，并通知帮助台请求撤回先前的请求。通知被分派的组成员可以停止事件处理操作；同时通知事件请求提交人事件请求已被撤销。待决Y表明接单人响应请求，但相关信息需要进一步确认或其他关联信息已解决Y简单问题快速处理通知请求提交人问题已解决，需要进行结果确认。关闭N客户未撤销请求，事件不能被关闭4.2.3.6.7.2.3 当前事件状态为进行中的工作时状态变化为合法性事件描述相关信息新建N新建确定为初试值，不可逆已分派Y相应的支持人员处理请求过程中，可以重新将请求分派给其他人员进行处理通知被分派的组成员准备处理请求，并告知请求提交人请求的重新分派结果，同时通知经理请求被重新分派撤销Y事件请求提交人发现问题的解决方案，并通知帮助台请求撤回