xxx集团xxx项目it服务管理需求分析报告

IT服务需求分析报告全部2文档说明目录1项目背景42项目运维访谈介绍521受访者522文件63运维现状与差距分析731信息系统服务内容清单7311面向用户服务目录7312运维服务详细内容732维护现状总结与ITSM差距分析12321事件流程/服务台12322问题流程14323变更流程16324配置流程184本期需求分析2041本期实施范围和运维管理模式2042本期XX运维管理实施内容21421运维电子化平台的部署22422统一受理服务台23423事件流程32424问题流程48425变更流程52426配置流程62427知识管理67428升级76429催办784210回访784211系统权限7834212衡量指标与报表784213接口定义835非功能性需求886附录A9161XX部运维现状91611各应用对象维护现状917附录B10441项目背景当今通信市场正由传统的以通信网和市场为中心的竞争转变为以客户为中心的服务质量的竞争。为在新形势下，利用现有资源，提高现有的维护工作效率，XXX建设了新大楼和亦庄两个XX中心机房，以统一为BSS、OSS、MSS等关键业务系统提供支撑服务，面对BSS、OSS、MSS等关键业务系统的复杂多样性和不断扩充的业务需求，如何保障各业务系统的正常稳定运行，从而确保并逐步提升XX的服务质量，迫切要求建立一个能够对XX机房负责承载的业务系统进行集中监控、集中维护、集中管理的信息安全和网管监控系统。XX信息安全和网管监控系统应不仅能够对系统的网络边界、核心网段提供安全防护，及时监测并发现各增值业务系统中存在的、潜在的各类问题，以保证系统的稳定运行和业务的正常开展；同时还将对服务和运行维护工作进行规范化、流程化管理。通过发现、总结和挖掘所存在问题，不断明确管理重点并优化管理流程，从而加强服务和运行维护管理能力、提高服务和运行维护工作效率、改善服务和运行维护工作质量，进而保证各关键业务系统服务质量和运行维护水平的可持续性提升。52项目运维访谈介绍20062010年XXXX战略的重点是以“统一规划、规范管理、分步实施、创造价值“为指导原则，全面开展应用系统的整合、数据中心的整合、以及DCN网络的整合。伴随数据中心整合的脚步，XX运维集中化也提到了议事日程上。在运维集中化战略的大前提下项目组在3月针对XX基础架构部分进行了初步的网络、系统和平台的运维现状调研，受到了XX部主管领导的重视，并指出运维工作不能孤立的划分为基础架构或应用等层面，应从服务对象及维护对象着手进行调研，并为XX建成后的统一运维提出可行性的方案作为访谈目标之一。为了实现建立统一运维体系调研全面的运维现状，项目组于4月进行了运维深度访谈，对XX部所维护的各应用系统软硬件现状、维护现状、维护流程等进行了全面而深入的了解，本文结合访谈现状，进行了需求汇总和差距分析。访谈记录详见附录21受访者本次调研中访谈了以下人员姓名职务访谈日期622文件本次访谈中获取了以下XXX集团的文件文件类型名称文件文件文件文件文件文件文件文件文件图表图表图表73运维现状与差距分析31信息系统服务内容清单311面向用户服务目录序号服务目录1系统软件/技术问题咨询2系统软件/故障申告3系统软件/功能变更开发4系统软件/功能配置变更5系统权限/新建/删除/变更6系统硬件变更办公/生产7网络故障申告办公/生产8网络变更办公/生产9安全管理办公/生产312运维服务详细内容IE版本低或被恶意修改IE打不开二级链接IE经常死机或自动退出IE使用或操作类问题IE无法浏览内网或外网备份或导数据补丁版本低操作中系统报错或蓝屏带入带出域软件服务桌面通用软件操作系统更改用户配置文件8共享文件夹类计算机名称不符合要求计算机升级重装OS弱口令使用方面的咨询网络设置问题无法登录系统系统无法启动系统运行慢硬件驱动程序用户帐号或密码问题域策略应用问题其他ACROBATMCAFEE问题MSN问题OFFICE类问题超级解霸解压缩工具金山词霸看图软件其他部门应用系统输入法常用工具其他OE中无法收发邮件OUTLOOK使用咨询POP方式问题PST文件过大或出错WEB页邮箱问题查杀邮件内病毒打补丁导出数据、联系人、个人通讯录导入数据第三方软件等影响无法发送邮件更改邮箱名称共享联系人共享日历其他删除帐号设置个人签名邮件问题使用类咨询9添加其他邮箱添加新个人文件夹无法PING通邮件服务器（可以PING通网关）无法发送某邮件地址新建帐号邮件规则类问题邮件组问题邮箱已满或被关闭帐号到期重新配置OUTLOOKBEAWEBLOGIC问题TUXEDO问题IBMWEBSPERE问题MQ问题中间件BIZTALK问题ORACLE9IDB2MSSQL数据库NCRTEREDATAUNIX操作系统WINDOWS安全监控系统防病毒系统认证及加密系统基础架构软件基础应用平台网管系统XX计费帐务系统整合（南方一期）南方客户服务系统BSS集团客户投诉中心系统新网络资源管理系统原XX控股骨干网资源管理系统OSS原控股安徽省本地资源管理系统XXX业务订单调度系统EAIEAI联接系统ERP系统人力资源管理系统ERP系统财务资源管理系统集团门户和办公系统邮件系统域管理系统防病毒系统系统管理应用系统故障申告/功能变更MSS综合统计信息管理系统10借用领用回收声卡显示卡笔记本其他光驱回收键盘借用联系维修商维修领用内存声卡鼠标网卡显示卡显示器硬盘主板台式机其他终端外设类其他HPIBMSUNDELL服务器其他HPIBMSUNEMC主机类故障/扩容/升级/迁移/割接/备份存储存储服务器路由器交换机HUB光电转换器线路拨号服务器骨干网（核心、汇聚、接入）MODEM路由器硬件服务网络设备故障/扩容/割接局域网（办公、生产、数据中心）交换机11HUB光电转换器线路拨号服务器MODEM负载均衡设备入侵检测安全设备防火墙空调电源设备UPS机房内布线架机房设备机柜其他硬件设备IPSECVPN,远程拨号业务服务器端问题WLAN类无法登录VPN在家中设置拨号安装VPNCLIENTVPN其他网关PING不通视频会议网口问题网线问题新开网口用户PING服务器严重丢包制作网线DCN网络MSS网网控DCN网网络服务其他VIRUSSCAN、EPOAGENT软件损坏感染病毒补丁安装不完全感染病毒安全服务终端安全防病毒各种补丁（系统补丁，重要临时补丁，OUTLOOK补丁等）安装完全，VIRUSSCAN、EPOAGENT运行正常情况下感染病毒。12客户端私自安装盗版非法软件感染病毒客户端用机显示感染病毒，但无法自动清除域外计算机感染病毒漏洞攻击应用系统安全网络安全DCN网络安全32维护现状总结与ITSM差距分析321事件流程/服务台简介描述事件管理管理事件的处理过程以确保尽快恢复到正常的运作。减小对业务运作的影响。描述服务台接收，记录，分类，一线支持，解决和关闭问题；监控跟踪事件并及时进行各方反馈的收集及沟通；改善用户关系，响应时间，与用户沟通和进行有效的团队合作。为管理层集中提供管理信息。对应关系对XX部来说事件流程的管理范围应是所有运维工作过程中的突发事件、服务请求、疑问、咨询等，如下表显示哪些用户请求属于事件流程管理范畴事件管理范畴服务目录1系统软件/技术问题咨询2系统软件/故障申告5预授权的系统权限新建/删除/变更6系统硬件故障办公/生产7网络故障申告办公/生产13事件管理范畴服务目录8安全事件办公/生产9其他用户突发事件请求流程情况XX部初步定义了运维管理规程和故障处理流程，但没有明确定义的事件管理流程规范。上述运维管理规程定义了故障的分级、升级、等运维指标，还定义了如“先局内后局外；先本端后对端；先交换后IP。先重点后一般；先语音后数据；先调通后修理，故障消除后立即复原”的故障处理原则，并使用适当的记录和文档资料模板辅助流程的执行，包括需求变更单模版等。在实际工作中，由于各应用系统分散运维，运维水平参差不齐，当前的事件处理部分由运维人员手工处理，除重大故障和告警等故障外基本没有事件记录，使得实际的运维处理过程和书面制定的规范有些差异。事件处理部分有两块业务从人员技能构成到流程管理相对比较完整终端支持运维由于较早的投入了ITSM的管理方法及电子工具，目前事件流程相对比较规范，但是由于该电子系统并未延伸到后台管理，使这部分业务在事件流程的整个生命周期中对后台部分的支持管控显得不太有力，造成服务质量的不统一，前后台知识传递不顺畅。客服系统支持部分有明确的人员分工、故障分级等，但故障记录还采用手工方式，咨询及其他受理并不记录。这两块的事件管理已经具备基本雏形，有专人专管，并且针对事件流程有绩效考核在紧急事件的处理的工作细化方面，定义了部分紧急事件处理流程。在实际工作中，各维护负责人会根据经验判断何种故障为紧急故障，并协调相关资源和及时上报。在紧急故障处理中，专门明确定义了沟通的方式和方法，明确定义责任体系，按照组织架构中的职责体系进行协调处理。所有紧急故障或者申告均会进行总结和分析，并有后续行动计划不是所有的事件均进行记录，终端支持部分是全部来话均进行了记录，客服支持业务是故障均会有详细记录，ERP等有自身的WEB网站支持，其他部分业务对于维护人员主动发现的问题或者直接找到维护人员处理的问题，则没有记录，但是重大故障都会有记录汇报故障情况、原因等。定义了故障的分类和处理时限以及优先级等，但对于事件严重等级14和处理时限的定义由故障发起人自己判断，有一定的主观性。没有专人对事件管理流程负责，部分事件流程基本缺失，没有明确定义的事件流程衡量指标和流程监控。终端支持有较完整的知识库，但是个文档库，不太方便查阅；其他事件流程暂无知识经验库积累。系统情况在流程的工具化层面只有客户端支持有一个HPOPENVIEWHELPDESK作为流程平台；ERP方面有一个可以进行受理、查询、关闭的公开WEB网站，但不是一个完整的流程平台。其他业务均无流程工具支持。作为日常运维监控的另一个重要方面系统监控平台和网络监控等，可以实现对事件的主动告警，由于系统分散在不同机房，监控工具随各机房配备监控工具，没有统一的系统监控和安全管理，所以也没有实现监控系统和运维管理平台之间的集成。人员情况在日常运维工作分工方面，各业务分散运维，没有统一模式，除客服系统运维724外，其他业务运维基本上都是58，XX运维人员主要承担系统管理、协调内部业务部门及开发厂商、代维厂商的职责，应用运维按应用系统种类划分，基础架构运维按网络、主机、数据库、存储等IT领域划分岗位；硬件主要有原厂商的维保，软件及应用维护主要由代维厂商实际执行。优势与主要问题内部IT客户端支持及客服系统支持人员结构相对较完整，业务成熟度高，积累了丰富的流程经验。有部分电子化的监控和运维管理平台，大部分故障均有详细的申告记录和处理记录。但同时也存在一定的问题，如监控平台和服务管理平台之间的集成上，经常由于同一个问题引发告警风暴。除客户端支持外其他业务基本没有专人对事件管理流程负责，没有对于流程的衡量和考核指标，在流程的电子化平台执行中存在一定的问题，如对事件的及时处理缺乏考核。该平台基本上是一个工作流处理平台，也就没有和其他流程之间衔接的说法。15322问题流程简介描述事件控制，问题控制，错误控制，上报，症结原因分析和预防性管理确保预防问题的发生，如果问题已经发生，则预防其再次发生。问题管理为管理层提供有价值的管理信息。流程情况目前在运维工作中未明确将事件和问题进行区分，没有专门的问题管理规范流程。也没有专门的人员从事该流程管理工作。但在实际操作上，客户已经有了一些初步的问题和事件的划分概念，并在实际工作中尝试。如存在部分与问题管理相关的活动和工作要求，如故障处理原则中“先调通后修理，故障消除后立即复原”就是要求在故障处理中，在采取一定措施恢复服务后，再进行深层原因的分析和彻底查找解决方案和规避措施，同时会提交故障分析报告，并据此进行其它潜在问题的研究和预防。由于缺乏正式的衡量点，目前的工作主要是依赖运维人员的经验和意识进行，处于自发状态。从主动性问题防范的角度，目前重复规律性的事件和趋势分析主要依赖对运维人员和代维厂商的的经验和主动工作意识，没有明确的流程活动定义。从实际工作的角度，运维人员对于重大问题均会进行问题根本原因的查找、解决方案实施、处理结果汇报等工作，但没有采用专门的问题分类、分级解决方法，可能导致资源使用和解决方案有效利用方面的欠缺。没有专门针对性的问题流程管理和责任人，也没有流程的监控和优化活动。事件流程和问题流程之间有一些自发默认的流程衔接。对于问题的根本原因分析后，会发起变更来解决问题，但没有明确的流程衔接定义。人员情况基于XX部组织架构和流程的现状，没有设立专门的问题经理。一般由维护人员担负问题处理专家的职责。系统情况随着XX的建设，集中的网络和安全监控系统将会为问题的预防和发现提供便捷的信16息平台。在维护管理平台方面，现有的终端业务运维管理系统中没有区分事件和问题，将事件和问题统一处理。其他应用业务没有运维系统，也就谈不上对问题管理的系统支持了。优势与主要问题没有对问题和事件有比较清晰的划分，基本都没有问题管理流程，大家处理问题的模式基本都是被动管理，即有了问题，通过主管经理召开会议讨论的方式进行。处于一种初始的状态，更谈不上完善的流程和流程监控。应持续对运维人员灌输问题管理的相关概念和内容，树立问题管理的意识。需要对所有重大问题均深入进行分析，对分析结果通过变更进行改进等。针对标准的问题管理的要求，缺乏针对问题的分类、解决优先级、分析结果。缺乏流程规范，流程负责人以及流程的衔接。323变更流程简介描述变更记录，影响评估，时间安排，计划与实施。有效地制定变更决策并安排工作进度。提高分布式企业中变更的可视性和通报能力。减少变更带来的负面影响。对应关系变更管理范畴服务目录1系统软件/功能变更开发2系统软件/功能配置变更5须审批的系统权限新建/删除/变更6系统硬件变更办公/生产7网络变更办公/生产17变更管理范畴服务目录8安全管理变更办公/生产9其他IT环境内的变更流程情况从流程规范的角度看，XX部没有设计和定义统一的变更管理流程。但各应用系统都有类似的文档来描述需求功能等变更管理流程，如需求变更流程、系统割接管理规范和软件版本管理规范。为配合应用软件版本、需求变更的变更管理流程执行，还定义了一系列的辅助表格工具，如软件版本升级需求申请表、需求申请单和需求变更完工单等模板。实际工作中，没有严格按照该流程规范执行，各应用的变更基本上使用一个约定俗成的模式进行，如果认为对前台业务有影响，均有实施方案、计划以及测试方案，测试报告等，需要按照变更内容向有关的部门提交申请并得到批准后实施，实施前会向影响用户发布变更影响通知。现有范围的应用系统的变更管理流程主要有业务部门发起，IT组件的变更由维护人员负责，没有设定明确的流程责任人负责对流程的使用效果、范围进行监控和提升。从流程衔接的角度，在变更处理中，会用到一些配置信息，没有流程或者工具支撑。人员情况没有正式定义变更流程经理的职责，任何人员都可以根据情况发起变更，召集相关部门开会讨论。在规划、协调，实施过程中各级运维部门和系统集成商均会涉及其中。系统情况没有工具支撑。对于重大的影响前台业务的变更，一般会通过OA系统发布变更通知。优势与主要问题18针对应用系统的新版本发布有流程规范，重大IT基础架构的变更有割接管理流程，总的来说，对于影响到一线前台业务的变更控制有约定俗成的变更流程，但对于一般的变更没有流程控制。没有一个统一的变更管理流程规范，各个应用业务均制定了有关变更方面的流程。由于有些应用系统的IT设备位于其他部门机房托管，其IT组件和应用系统的变更完全独立。变更管理和其他流程没有定义的流程衔接，但实际工作中，均会有事件或者问题引发变更，变更处理中，可能会修改配置。324配置流程简介描述验证，控制，状态管理，项目验证硬件，软件，人员，位置，文档，业务流程，构成IT环境及现有环境中的相互关系；提高IT资产管理水平，更好地支持变更管理；改善事件与问题管理；便于评估法规条例的依从状况。流程情况XX部尚未定义配置管理流程，实际工作中仅完成了部分资产管理的工作。当前的配置管理基本上处于各小组范围内进行配置管理工作，没有配置管理的策略，配置信息基本在各管理员自己掌握，配置信息的详细程度，对运维支撑的程度没有统一的标准，而且存在大量配置信息与原有存档不一致的情况，对那些IT组件进行配置管理以及管理到什么程度没有定义，完全处于相关IT组件负责人的个人能力。从整体上看，没有完整的配置管理流程，也就没有与其它运维流程形成明确的衔接。从访谈上看，IT组件的管理员普遍意识到配置管理在日常运维工作中的重要性，并且希望在本期项目中能帮助他们初步建立统一CMDB。人员情况XX部目前没有定义配置管理的专门角色。在现有情况下主要配置信息在各管理员手中，有一部分在代维厂商处管理。但上述所有的管理工作主要依赖于系统负责人的经验和意识。从流程上看，处于较为欠缺的状态系统情况19所有的配置信息均保存在相关配置项负责人自己手中，但没有完整意义上的配置管理电子系统。优势与主要问题配置管理的工作在实际工作并未开展，各IT组件负责人掌握一部分配置信息，对部分关键IT组件有统一的命名规范和标签。但没有完善的配置管理流程规范，尚没有将其与其他运维流程，如事件/故障等管理流程相衔接。技术信息的配置没有统一要求。由系统或业务应用的支持人员根据自己的经验进行管理。但各IT组件负责人已经意识到配置管理的重要性，在配置管理推广上应会起到正面的作用，但仍需加强运维人员的配置管理理念。实施配置管理的初始化工作较艰巨。204本期需求分析41本期实施范围和运维管理模式结合上述运维现状及本期项目就是要保障XX自身运维管理的运维目标，如下图所示统一的IT服务支撑体系事件处理流程问题处理流程变更处理流程配置处理流程统一受理企业内部客户服务数据、EAI、应用系统EDC系统运维应用系统运维DCN系统运维管控基础架构网络主机机房环境数据库信息安全存储备份OSSBSSMSS管控管控统一客户接口近期建设范围DCN安全DCN网络附图1近期建设范围首先保证XX建成后其内部运维管理的覆盖是全面的，流程是顺畅的，能达到协调各责任人快速处理XX内部运维突发事件恢复服务的第一目标。另外根据XX部运维集中的规划，将在本期建立统一接入的客户受理接口，将对XX部目前所支持的业务服务和内部IT客户的受理接口统一，实现用户满意度的提升，服务质量的监督等。这也是充分契合XX集团“服务编织未来”的企业理念，是XX集团对内部及外部的运维支持趋近于统一的明智之选。如上图所示的红色T字型部位即是本期实施的重点，T字型框架也是未来实现21统一的IT服务支撑体系的骨架，随着本期项目的顺利开展，伴随应用系统的整合和DCN网络的整合，将会分期分批的不断在骨架中填充更多应用系统的支持，在建设中不断校正。附图2目标运维业务模式如上图所示依据信息化建设规划建立全面的统一的服务台是XX信息系统服务支撑体系建设的目标之一，作为各系统、用户受理的单一联系点，全面支持网管/安全突发事件、客户端桌面支持业务、客服系统支持业务，及其他各专业应用系统的支持受理工作，并围绕统一受理平台展开各管理流程的建设和推广工作，将规划中的流程虚拟角色定义在日常运维工作中得以实现。42本期XX运维管理实施内容综上本期的实施范围建议运维电子化平台的部署平台功能的需求分析平台的安装、部署统一受理平台的建设建设统一受理服务台22接受来自客户端、客服系统、其他应用系统及DCN网络用户的服务受理事件管理流程的部署XX系统突发事件流程设计、实施问题管理流程的部署XX系统问题流程设计、实施配置管理流程的部署XX配置流程设计、实施XX配置信息管理库建设变更管理流程的部署XX变更流程设计、实施运维服务管理平台与监控管理平台/安全管理平台接口的实现运维服务管理平台能够接受来自于监控管理平台和安全管理平台的事件信息，然后按照事件管理流程进行处理，当处理结束后，将反馈信息返回给监控管理平台或安全管理平台中。运维服务管理平台能够接受来自于监控管理平台的配置信息，且当运维服务管理平台的配置信息发生变动后，能够将该变动信息发送到监控管理平台中。服务管理平台提供查看CI的接口。运维服务管理平台与其他管理系统接口的实现服务管理平台可以发送信息到邮件系统421运维电子化平台的部署作为有效支撑服务体系建设的工具化手段，将使用BMC公司的REMEDY产品在本期建设XX运维管理平台，系统部署如下图所示23422统一受理服务台4221服务台现状目前XX部服务台情况如下表所示应用系统电话号码是否使用呼叫中心设备有无电子工具支持运维模式终端桌面支持是有HPOPENVIEW5X9客服系统支持是无7X24ERP系统支持否有ERPWEB网站5X9其他专业系统否无5X9利用现有呼叫中心设备的IVR支持如下示意244222本期建设统一受理服务台方案比较方案一设置统一服务台热线，现有呼叫中心利旧利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台配备服务台人员配置专职的服务台人员，受理除客户端支持、客服系统支持外的其他应用系统和IT问题，该服务台受集团信息化部直接管辖。客户端支持、客服系统支持及新设立的统一服务台人员构成了信息化部统一服务台修改IVR语音，增加其他系统问题修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音25配置到新设置的服务台人员受理新建其他系统问题服务台支持人员使用本期流程平台系统终端支持、客服支持仍采用现有支持方式，在本期不做改变。其他系统问题全部记录在本期REMEDY流程平台系统上，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户及外部部门来说是透明的。如图附图3服务台模式方案一优点对原有支持模式改动较小，对服务提供质量降低的风险较小；实施周期短；缺点由于其他系统问题并不是頻发，建立初期服务台受理量较低；26并未改善客户端支持及客服系统支持等日常支持的服务水平；如配备新人须具备基本的IT系统技能，否则在设立之初可能会用户造成服务不够专业的印象方案二设置统一服务台热线，现有呼叫中心利旧利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台复用XX服务台人员无须配备新的服务台人员，由现有XX服务台人员受理除客服系统支持外的终端问题、其他应用系统和IT问题，该服务台管理模式不变。重新调整的具备多种应用受理的XX热线人员、客服系统支持人员构成了信息化部统一服务台。换句话说原XX服务台职能变更为XX部对外统一受理服务台修改IVR语音，增加其他系统问题修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音配置到现有XX热线人员技能组XX服务台使用本期流程平台系统客服支持仍采用现有支持方式，在本期不做改变。XX服务台将现有HPOPENVIEW摒弃，使用新的REMEDY流程平台处理事件，客户端问题从受理到处理各环节均在REMEDY流程平台上实现；其他系统问题全部记录在本期REMEDY流程平台系统上，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户及外部部门来说是透明的。如图27附图4服务台模式方案二优点1、现有XX热线支持人员结构完整，流程角色清晰，并积累了长时间的管理经验；2、具备服务台应有技能，较易扩展到支持其他应用系统的综合受理职能；3、现有XX终端支持具备ITSM的基本理念、较习惯使用ITSM领域的相关电子工具；4、内部客户端支持业务与各办公系统、基础架构部分的业务联系较紧密，将这部分业务在本期一次性完整的迁移到统一运维体系框架中，完善原有运维流程，如将前台人员及后台管理员纳入统一的平台中；5、修正原有系统的诸多使用缺陷，完善考核质量监控体系等缺点1、实施周期相对方案一较长，须将现有系统的功能、数据等在新系统中实现28方案三设置统一服务台热线，现有呼叫中心利旧利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台复用XX客服支持服务台人员无须配备新的服务台人员，由现有XX服务台人员受理除终端系统支持外的客服系统问题、其他应用系统和IT问题，该服务台管理模式不变。重新调整的具备多种应用受理的XX热线人员、终端系统支持人员构成了信息化部统一服务台。换句话说原XX服务台职能变更为XX部对外统一受理服务台修改IVR语音，增加其他系统问题修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音配置到现有XX热线人员技能组XX服务台使用本期流程平台系统终端支持仍采用现有支持方式，在本期不做改变。XX服务台使用新的REMEDY流程平台处理事件，客服系统问题从受理到处理各环节均在REMEDY流程平台上实现；其他系统问题全部记录在本期REMEDY流程平台系统上，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户及外部部门来说是透明的。如图29附图5服务台模式方案三优点1、现有XX热线支持人员结构完整，流程角色清晰；2、客服系统是个小而全的系统，现有XX完全具备服务台技能，较易扩展到支持其他应用系统的综合受理职能；3、本期客服系统作为第一批搬迁XX的系统，有利于完善原有运维流程，如将前台人员及后台管理员纳入统一的平台中；5、服务支持模式为7X24缺点1、实施周期相对方案一较长302、支持人员由无电子工具到使用流程平台工具，带来的适应性问题3、原有热线人员数量配备可能不足方案四（我方推荐方案）设置统一服务台热线，现有呼叫中心利旧利用现有排队机、IVR、CTI设置一个XX部对外统一服务热线，如1234，或将现有XX号码设置为统一服务热线，对拨打用户来说收听相应的IVR语言留言进入不同的技能支持组，对外既是统一受理服务台；虚拟服务台由实体技能组来组成，各技能组权限独立，即各技能组受理并记录的工单，只有各帮助台技能组察看和管理。复用XX客服支持服务台人员无须配备新的服务台人员，由现有XX服务台人员受理除客服系统支持外的终端问题、其他应用系统和IT问题，该服务台管理模式不变。重新调整的具备多种应用受理的XX热线人员、客服系统支持人员构成了信息化部统一服务台。换句话说原XX服务台职能变更为XX部对外统一受理服务台修改IVR语音，增加其他系统问题；增加XX在IVR上的分支修改现有CTI设置，在语言引导中加入其他系统支持的语音留言，并将该语音配置到现有XX热线人员技能组；将现有XX作为目前语音向导中的一个分支设立，以确保未来条件允许情况下所有运维支持统一拨打服务台号码可获得全部支持。详见附图6统一服务台全部使用本期流程平台系统为达到统一服务标准，规范服务流程的目的，建议服务台及前后台支持人员全部使用新的REMEDY流程平台处理事件，从受理到处理各环节均在REMEDY流程平台上实现；其他系统问题全部由终端支持受理并记录在本期REMEDY流程平台系统上，通过给服务台人员配置各系统支持人员一览表，达到系统外分派处理的目得，但不依赖于平台处理，分派处理等环节不在系统中实现，闭环于帮助台，对申告用户及外部部门来说是透明的。31如图附图6服务台模式方案四优点1、真正实现了统一服务台的基础设置2、其他系统问题由XX终端支持，未来易于扩展支持全面的专业应用系统支持职能3、所有运维服务可以统一服务标准，提供可衡量的服务质量考核依据4、全部使用新的REMEDY系统平台，前后台运维人员的可以在一个统一的平台中使用同一流程语言进行日常运维处理，大大提高了沟通和处理的效率325、使XX部信息系统规划中日常运维角色设置完整的系统平台中得以实现，利于新的服务体系架构的推广和调整缺点1、实施周期较其他方案时间最长；推广难度较其他方案更高2、支持人员由无电子工具到使用流程平台工具，带来的适应性问题3、需要更多双方的资源调配呼叫中心与流程平台结合流程平台REMEDY支持与现有呼叫中心作结合，以达到用户电话呼入，自动弹出流程系统界面，并将用户基础信息直接导入，调取用户语言留言，预呼等接口功能。经厂家求证，REMEDY本身并不提供与XX现有呼叫中心的成熟接口套件，需要另行开发。开发则需要CTI厂家提供接口开发包，但该开发包是需要单独购买的，所以在本期暂不考虑实现呼叫中心与流程平台的自动整合。当用户呼叫至人工坐席后，须手动调用起REMEDY系统界面，填入用户主叫号码，可以自动回填该用户信息，前提是基础数据已经导入REMEDY系统中。423事件流程目前有故障报修流程，其工作模式类似于突发事件处理流程。4231事件的理解事件可以分为突发事件和服务请求。突发事件，是指发生了非常规的运作情况，包括系统崩溃、软件故障、任何影响用户业务操作和系统正常运作的故障、以及影响业务流程或违背服务水平协议的情况。服务请求，是指用户的业务咨询、常规操作类的事情，并非导致故障的请求。如，重设用户密码。不是所有的突发事件都由用户产生，监控管理平台产生的告警也可引发事件。33通常由帮助台负责记录事件相关信息，向用户提供对已知问题的处理方法，报告突发事件和尽快恢复服务，目的是在事件管理阶段获得尽可能高的事件解决率。突发事件基于相关配置元素的关键等级和影响度进行优先级分类。事件管理的责任是记录、分类、调查/诊断、解决已知问题、监控跟踪事件、与用户和问题管理流程交流、最终解决事件。4232本期事件管理实现的目标虽然XX的主要服务对象是XX集团内部，如何确立XX部的标牌服务形象，同时为XX的整合提供更好的运维支持，在现阶段，我们需要确立以下目标1、确立服务热线的标牌，在XX集团内部实现有IT事件发生找XX部的局面。从而实现帮助台的统一受理，即事件都由帮助台负责登记、派发。建议将现有XX热线定义为统一接入号码，树立XX服务热线品牌2、形成闭环式的服务流程。服务台负责对用户进行回访，体系客户关怀。附图7事件处理闭环流程3、设立帮助台、一线支持人员、二线支持人员、事件经理等流程角色，并将现有运维人员与流程角色进行匹配。4、实现事件分类处理，不同技能的支持人员处理不同类别的事件请求。5、确立事件的负责人，实现事件处理责任制。6、实现突发事件的跟踪机制，帮助台可以随时了解到突发事件的处理情况，在必要时，实现突发事件催办。347、实现突发事件的紧急程度划分，根据事件紧急程度不同，响应时间不同，解决时间不同，升级机制不同。8、设立升级机制，根据突发事件的严重等级不同，设定不同的升级时间和升级策略。9、建立知识共享机制，缩短突发事件处理的进程。10、建立考核机制，具体方式以报表的形式体现。4233事件管理的差距分析目前来说，除了桌面维护部分有一个HPOPENVIEWHELPDESK流程外，其他各岗位的事件处理都没有流程系统进行约束，从而造成了以下的一些问题1、虽然设立了XX服务热线，但其功能仅仅局限在XX集团内部的桌面系统的维护上，面对网络、系统数据库等的事件处理，并没有发挥统一受理的职能。2、各岗位的管理员每天处在繁忙的工作以及突发事件的处理中，却没有处理事件工作量的统计。3、有时候，我们做了很多事情，却没有分清楚事情的轻重缓急，导致最后事情做了也没有得到认可。4、没有时间上的约束，导致很多问题得不到有效的解决。5、因为没有流程，很多人并不清楚自己在事件处理中应当担当的角色是什么6、缺乏知识共享，导致处理一些常规突发事件时必须找到某个人才可能将事件解决，导致事情延误。7、目前因为流程上的缺陷，导致没有体现出很好的客户关怀。4234面临的挑战为了实现以上目标，我们还需要接受一些挑战351、根据目前状况，建设统一受理平台要求帮助台即能处理一般性的咨询请求、桌面系统的事件划分，还能受理客服系统等其他应用的咨询及报障，如果将网络、系统、应用等事件请求统一归入服务台，对服务台的处理能力形成挑战，比如专业事件描述是否能够准确，是否会给用户造成一定的麻烦等。2、XX内部的规范可以统一，但很难约束其他部门和公司统一到帮助台来。如果用户遵循了我们的规范，却发现事件解决的效率降低了，在系统该启用的时候很容易出现这样的现象，如何规避这样的风险3、固有习惯事件处理方式的克服。4、如果通过帮助台做客户回访目前可能造成帮助台工作量加大，是否能够承受4235我们的建议为了确立运维支持中心的核心地位，提高运维质量，在现阶段，我们可以做到以下几点1、帮助台作为事件统一受理，负责记录用户反映的突发事件以及解决用户的服务请求。2、帮助台有职责对人员信息进行维护，保障服务的及时性和有效性。3、帮助台需要对事件进行合理划分，并根据事件类型进行优先等级的区分。当电话、WEB事件同时进入帮助台，根据优先级进行决定受理顺序，同优先级以创建时间作为受理顺序4、面对帮助台技能方面存在的压力，本期统一帮助台可以由现有XX帮助台部分人员和客服支持帮助台人员共同组成，通过语音技能设定，分拣来自客服座席的支持号码给客服系统代维人员，闲时也可以支持其他IT客户端问题5、各管理员归纳一些常见事件的描述信息给帮助台，帮助服务台人员熟悉业务的基本概念。6、根据管理员归纳的信息结果，在事件记录界面上设计可选项，有助于帮助台36人员记录事件描述的准确性，实现事件分类的准确定位。7、规范服务意识，即使在打破用户习惯的不利情况下也会让用户感觉到规范流程给他带来的优质的服务。8、可以根据用户的级别不同、提交事件的类型不同实现不同的用户回访方式。9、设立事件自动关闭时限，在事件处理完成后，没有得到客户确认响应一段时间后，事件可以实现自动关闭。4236事件管理流程总图附图8事件管理流程总流程概述该流程始于突发事件或系统故障的探测和报告，结束于问题的解决。该流程包含下述步骤42361事件信息的监测和记录该步骤是事件管理流程的起点。所有客户报告的事件请求必须由此步骤开始。此步骤37的目的是在事件发生时快速准确地发现故障，以协助事件的诊断和解决并通知相关支持人员。在此步骤中将会收集创建事件记录所需的信息。该步骤的关键是信息的准确性和完整性。42362分类和在线支持事件可以是一个变更请求、服务请求、信息请求或服务故障。对于服务故障，则需要确立该故障的优先级、影响度、紧急度和分类。若没有现成的解决方案或临时措施来恢复服务，该事件将分配给合适的支持人员对此进行调查。42363调查和诊断若在线无法解决的问题，必须进行更加深入的诊断以找到恢复服务的方法，必要时将可能使用多名技术员以寻求解决措施。在调查和诊断过过程中需要对以往案例解决方案进行查找，以期快速找到可能恢复的方法，需要实现知识库与事件及问题管理流程的联动，有效支撑事件的快速恢复42364解决和恢复通知客户解决方法或临时措施并加以实施。解决措施一旦成功，可以根据事件的处理过程难度、发生频率等因素判断生成知识案例库的解决方案，通过提交知识沉淀有效经验。42365事件请求结束当客户确认事件解决后，此时可以结束该事件请求并在必要时更新知识库。最后该事件得以结束。若客户对此解决方案不满意，则对该事件进行重新打开并再分派处理。事件请求结束后应由系统自动派生本次服务的满意度调查，并以邮件方式发送给事件提交者，提交者填写完毕后可以直接回复到系统中，由系统对调查结果进行归档并作报表统计数据源。满意度调查报告应包含本次服务满意度、响应满意度、处理满意度等几项调查。3842366事件监控该步骤监控所有事件的生命周期。该步骤始于事件记录的创建，并在事件请求结束时终止。42367状态图表附图9事件状态表423671状态转移表状态新建已分派进行中的工作撤销待决已解决关闭新建YNNNYN已分派NYYYYYN进行中的工作NYYYYN撤销NNNNNN待决NYYYYN已解决NYNNNY关闭NNNNNN423672状态转移4236721当前事件状态为新建时状态变化为合法性事件描述相关信息已分派Y用户提交事件请求，分派到相应的处理人员或组通知被分派的组成员准备处理请求，并告知请求提交人请求的分派结果进行中的工作N未经过分派的过程，是不可能处于正在处理的状态的。39撤销N未记录的事件请求，是不可能处于撤销状态的。待决N未经过分派的过程，是不可能处于正在等待的状态的。已解决Y在知识库中可以查到相关的解决方案时，问题不必再提交到支持组进行解决，客户可以自行关闭提交的请求关闭N未经过客户确认的解决方案4236722当前事件状态为已分派时状态变化为合法性事件描述相关信息新建N新建确定为初试值，不可逆已分派Y支持组成员之间可以相互派转已分派到本组或本人的请求通知被分派的组成员准备处理请求，并告知分派请求的人员分派结果，同时通知分派者的主管经理请求被重新分派进行中的工作Y表明接单人响应请求并开始着手处理请求撤销Y事件请求提交人发现问题的解决方案，并通知帮助台请求撤回先前的请求。通知被分派的组成员可以停止事件处理操作；同时通知事件请求提交人事件请求已被撤销。待决Y表明接单人响应请求，但相关信息需要进一步确认或其他关联信息已解决Y简单问题快速处理通知请求提交人问题已解决，需要进行结果确认。关闭N客户未撤销请求，事件不能被关闭4236723当前事件状态为进行中的工作时状态变化为合法性事件描述相关信息新建N新建确定为初试值，不可逆已分派Y相应的支持人员处理请求过程中，可以重新将请求分派给其他人员进行处理通知被分派的组成员准备处理请求，并告知请求提交人请求的重新分派结果，同时通知经理请求被重新分派撤销Y事件请求提交人发现问题的解决方案，并通知帮助台请求撤回先前的请求。通知被分派的组成员可以停止事件处理操作；同时通知事件请求提交人事件请求已被撤销。待决Y表明接单人响应请求，在请求处理过程中发现相关信息需要进一步确认或其他关联信息40已解决Y问题解决并等待客户最终确认通知请求提交人问题已解决，需要进行结果确认。关闭N客户未撤销请求，事件不能被关闭4236724当前状态为撤销时状态变化为合法性事件描述相关信息新建N新建确定为初试值，不可逆已分派N事件请求已被撤销，处理流程结束。通知被分派的组成员事件请求被撤销。同时通知事件请求提交人事件请求已被撤销。进行中的工作N事件请求已被撤销，处理流程结束。通知被分派的组成员事件请求被撤销。同时通知事件请求提交人事件请求已被撤销。待决N事件请求已被撤销，处理流程结束。通知被分派的组成员事件请求被撤销。同时通知事件请求提交人事件请求已被撤销。已解决N事件请求已被撤销，处理流程结束。关闭N事件请求已被撤销，处理流程结束。4236725当前状态为待决时状态变化为合法性事件描述相关信息新建N新建确定为初试值，不可逆转已分派Y相应的支持人员处理请求过程中，可以重新将请求分派给其他人员进行处理通知被分派的组成员准备处理请求，并告知请求提交人请求的重新分派结果，同时通知经理请求被重新分派进行中的工作Y当所有待决状态下的问题都被解决后，支持人员可以开始正式处理请求。撤销Y事件请求提交人发现问题的解决方案，并通知帮助台请求撤回先前的请求。通知被分派的组成员可以停止事件处理操作；同时通知事件请求提交人事件请求已被撤销。已解决Y问题解决并等待客户最终确认通知请求提交人问题已解决，需要进行结果确认。关闭N客户未撤销请求，事件不能被关闭414236726当前状态为已解决时状态变化为合法性事件描述相关信息新建N新建确定为初试值，不可逆已分派YES客户不认可解决方案，重新打开请求通知被分派的组成员准备处理请求，并告知请求提交人请求的重新分派结果，同时通知经理请求被重新打开进行中的工作N请求被重新分派状态。撤销N事件处理已完成，客户不能进行事件撤销待决N请求被重新分派状态。关闭Y客户认可该解决方案并最终关闭请求。通知支持人员该请求被用户关闭。4237事件管理流程与其他管理流程间的关系附图10各流程间关系和问题管理流程的关系事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后做为问题进行进一步的分析和处理。42和配置管理流程的关系需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复。和变更管理流程的关系帮助台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件。在事件的解决过程中，必要时需要发起变更请求来解决事件。4238事件流程角色、技能组和权限定义服务支撑平台设定的目的之一是要将人员技能进行合理划分。从人员构成来说应符合金字塔结构。服务台、桌面支持业务支持人员管理层技能设置的目的根据REMEDYITSM应用的需求依据XX集团XX部目前的机构设置，为了实现事件的正确路由，保证事件的自动分派和缩短事件手动分派的时间。必须设定合适技能的人员处理相应的事件，需要对事件分类与人员技能进行匹配。支持人员分属于不同的组，一个支持人员可以有多项技能，即属于多个技能组。由系统进行权限控制，人员技能不同，可以访问不同记录、对单条记录中字段具备不同的可读、可写权限。使支持人员责任更加明确，避免受到不属于本技能解决范围的事件服务入口，一般性支持业务专业性支持业务包括一线支持、二线支持等统计、管理、监控、协调43干扰。技能设置的依据根据XX部目前的机构设置和运维访谈结果，并根据REMEDYITSM应用的要求，根据运维人员技能的不同规划技能组。技能设置的建议根据目前事件的处理状况及XX整合后运维人员可能发生的变化，建议人员技能组的划分以此为依据。帮助台客户服务组一线支持组桌面支持组二线支持组客服系统维护组、系统主机维护组、数据库支持组、安全支持组、网络支持组、存储支持组等管理组各组负责人及主管领导事件经理专职技能分类说明技能组名称职责帮助台在指定的响应时间内响应所有帮助台热线电话、邮件、传真等事件报告，进行事件登记，并根据事件影响范围等因素设定严重等级。可以回答客户的咨询类问题或简单的故障请求。桌面应用可以直接进行处理。完整记录所有接收的事件信息，包括记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等，并负责补充来电客户的基本信息。为事件进行适当的分类、为事件分配优先级等属性尝试使用工具、初步诊断、分析相关信息等方式解决问题44如果帮助台不能解决这个事件，应当将事件分配给最合适的一线支持小组/人员来处理解决被一线支持退回的问题，重新与客户进行沟通。检查事件记录的处理进度，保持与事件报告人的联系，适时通知事件处理进展与用户确认事件解决方案，关闭事件一线支持组一线支持人员负责对帮助台无法解决的事件进行快速有效的分析，提出解决方案以尽快恢复服务，并在必要时提供现场支持。负责记录用户直接提交的事件请求并进行分派处理。验证事件的描述和信息，在帮助台对事件描述不清的情况下，直接与用户进行沟通，进一