3 W 公司运维服务流程现状分析
本文以 W 公司为例，对公司的运维服务进行全方位、准确的诊断，找出 W 公司运维服务流程存在的问题，并针对这些问题提出解决方案，设计流程再造的可行方案，根据再造方案进行运维服务流程再造。
3.1 W 公司简介
3.1.1 W 公司基本情况介绍
W 公司成立于 2001 年 11 月，公司注册资本 600 万元，注册地址在北京市海淀区万寿路街道翠微路，业务范围包括施工总承包、专业承包、劳务分包；信息和水利方面技术的开发、推广、转让、咨询、服务、培训等；计算机系统相关服务；各类数据处理业务；计算机维修和配件更换；基础软件开发；应用软件开发；销售各类计算机软硬件设备、电子通讯设备等；农业科学研究与试验发展；工程和技术研究与试验发展；自然科学研究与试验发展。公司目前具有国家高新技术企业认证、ISO9000 质量管理体系认证，具备计算机信息系统集成三级资质、双软认证资质、国家高新技术企业资质，并获得 9 项计算机软件着作权登记证书以及 9 项软件产品登记证书；拥有一项实用新型专利证书。
公司自成立以来一直从事水利自动化领域的规划设计、集成、施工等工作，取得了令人瞩目的业绩。主要业务为自动化系统方案设计、系统集成、软件开发及系统运行运维等，有能力承担雨水情遥测、供水监控、闸门监控、通信、水质监测、大坝安全监测、图像监视、计算机网络及软件开发集成等自动化系统工程及运维服务。公司曾先后承担过北京朝阳奥运承载区水环境治理项目、坝河北小河自动化系统工程、永定河生态环境综合整治工程、自动化管理设施建设工程、北京市密云水库管理处防汛指挥调度中心工程等水利自动化项目的建设。在水利自动化工程建设方面积累了丰富的技术经验，工程质量达到优良。部分工程获得了省、部、市级科技进步奖。近年来还承接了北京市南水北调应急供水运行管理信息系统建设工程、水情信息整合系统建设项目及北京市水资源配置管理系统（二期）--水务局中心的建设等水利信息管理的项目，在水资源配置与管理等具体业务方面，为北京水务信息做出了贡献。为更好地服务与支持“民生水务”、“科技水务”、“生态水务”,公司还承接了北京市密云水库自动化采集系统运维、北京市东水西调管理处自动化监控系统运维、北京市城市河湖管理处自动化采集系统运维等大量的自动化系统和综合管理系统的运维项目，保障了用户系统的正常运转，展现了公司扎实而过硬的业务能力。
随着水利行业信息建设的全面开展和深入，信息系统运维工作越来越重要，公司近年运维业务比重日益加重，运维业务的增加，对公司运维服务的要求也越来越高，同时也暴露出一些问题，如运维服务技术人员能力需要加强，运维响应速度不够及时等，特别是对运维响应速度问题，因水利行业的特殊性，对响应速度要求较高，响应速度提高是提高运维服务质量首要解决的问题。公司运维服务对象主要是北京水利行业相关单位，运维服务范围涉及北京市全境以及河北等周边地区。
3.1.2 W 公司组织结构
W 公司组织架构如图所示，公司总经理负责公司全盘工作，副总经理在总经理的领导下，负责所分管业务的具体领导、管理工作。技术总监负责公司所有技术方面的指导工作，没有具体针对的管理部门。具体职能部门包括行政办公室、人力资源部、财务部、项目管理部、技术部、系统集成部、资源开发部、运维中心等，公司主要是按照直线职能制来设置组织结构，同时因为还没有完全完成体制改革，职能部门的设置有很明显的事业编制的痕迹。
具体组织结构图如图 3.1 所示：
3.2 W 公司运维服务部门分析
W 公司运维服务业务最早开始于 2006 年，当时北京水利行业开始了信息化的建设，各个水管单位都展开了大规模的水利信息化系统的建设，W 公司承接了很多类似项目的集成建设工作。当时信息化普遍程度还不是很高，北京水利行业之前主要靠人工来进行各类业务的处理，很多职工尤其是老职工，甚至没有用过电脑，日常办公还没有实现电脑化。在这种情况下，推行信息化建设，在系统建设完成后，就出现了很多的问题。首先是系统的使用问题，如何进行日常操作，这需要提前进行培训，并进行现场操作指导。其次在运行过程中，电脑出现故障或者系统本身出现故障，需要及时的处理。第三在系统使用过程中，因为业务调整，需要对系统进行更新，这就需要对系统进行进一步的完善。在这种情况下，W 公司作为水利行业内部企业，同时又是系统的承建方，就开始提供运维服务。最初的运维服务，主要是针对公司自己承建的项目，作为售后服务的性质来开展运维服务。哪个部门负责建设的项目，由哪个部门来负责运维，不签订运维合同，不收取费用。随着业务开展一段时间以后，出现了一些问题：首先对于自己建设的项目，在过了一年的质保期以后，系统出现了问题，建设单位还是会找公司来处理，出于长期合作伙伴的关系，公司能解决的小问题，都会及时给处理了，这样无形中人力成本就会增加，有时候涉及到系统大的调整，甚至需要投入一定的资金，公司一个项目做下来，因为后期的运维使项目收益大打折扣。其次有些项目在建设的过程中，是由公司几个部门合作完成的，比如硬件部分由系统集成部完成，软件部分由资源开发部完成，在系统建设完成后，系统出现故障，客户自己不会去区分是硬件故障还是软件故障，只会找项目的联系人，这时候就出现各个部门之间分工不明确，沟通协调的问题。最后因为公司和合作伙伴的良好关系，很多水管单位由其他承建方建设的项目，在后期运维中出现问题，找不到最初的承建方，也会找 W 公司来处理，这就更是费人费力的事了。在这种情况下，自 2007 年初 W 公司开始了正式的运维服务业务。承接各类信息化项目运维服务，不管是公司承建的，还是其他公司建设的。签订正式的运维合同，收取相应的费用。
W 公司最早的系统运维业务由各个部门共同执行，没有单独的运维部门。项目管理部负责洽谈各种运维业务，签订运维合同。按照运维性质，软件部分的由资源开发部执行，硬件部分由系统集成部执行。在实际操作过程中，出现了很多协调方面的问题，造成运维工作明显滞后、相互推诿的情况，客户反映运维工作响应时间过长，运维效果没有达到要求，客户满意度不高，公司高层认识到运维业务的重要性，及时的对运维工作进行了改革，自 2011 年开始，成立了运维中心，由运维一部和运维二部组成，专门负责各类运维工作。因为运维工作除主动运维外，故障报修业务占主要部分，所以专门建立了报修呼叫中心，24 小时接听客户报修。在运维中心成立以后，项目管理部接洽的各项运维业务，直接交由运维中心来负责。运维中心组织架构如图3.2 所示：
具体人员职责如下：
副总经理：负责对运维服务方案、运维总结报告、运行监控指导书的批准工作。
部门领导（运维一部、运维二部）：部门主任负责运维服务合同的实施，确定项目经理和项目组成员，负责监督运维合同的执行情况。部门总工程师负责运维服务方案、运维总结报告、巡检方案、巡检报告、运行监控指导书的审查工作，负责协助处理运维服务过程中的重大疑难问题。部门副主任负责日常运维工作的组织和开展。
项目经理：承担运维项目的组织及具体运维工作；负责运维服务方案、巡检方案、巡检报告、运维总结报告的编制工作；负责运行监控指导书、运行监控记录表的修订工作；按照服务流程随时做好现场记录，定期对服务情况进行分析、总结。
运维工程师及助理工程师：根据运维服务方案及服务工单的要求，实施维修服务和运行监控工作；按照服务流程随时做好现场服务记录；配合项目经理完成各类方案、计划、报告的编制。
运行监控值班人员：负责日常的运行值班工作，负责电话的接听；负责根据监控体系进行系统运行状态的监控、记录，发现故障进行运维调度，建立运维工单派发；负责故障和报修的记录、转交和归档工作。
3.3 W 公司运维服务流程存在的问题分析
W 公司运维服务流程经过了多次修改优化。在 2006 年公司开始运维服务但是没有正式签订运维合同时，W 公司没有制定运维服务流程，运维服务主要是被动式的，即建设单位出现故障，找项目联系人，项目联系人找项目建设部门安排技术人员处理。
如果不是公司承建的项目，一般是建设单位找到公司领导层，公司领导层安排相应的部门去处理。即没有任何维护记录，也没有质量跟踪。发生的成本计入各部门的日常运营成本。在 2007 年正式开展运维服务业务后，为了方便运维服务的开展，制定了运维服务流程。具体流程如图 3.3 所示：
在这种流程的指导下，项目管理部负责洽谈各种运维业务，签订运维合同。按照运维性质，软件部分的由资源开发部执行，硬件部分由系统集成部执行。在运维服务业务开展的前期，公司运维服务合同还较少的情况下，流程还能正常运转，但是在运维服务合同越来越多，业务量越来越大以后，就出现了很多的问题：首先运维服务没有独立的财务立项，在合同签订后，具体的实施工作由不同的部门来执行，发生的费用计入各个部门的运营成本，但是没有相应的成本核算方法。造成每个运维服务项目无法准确的计算效益。其次大多数运维服务合同，都不是完全的硬件运维或者软件运维，而是两者兼有，在这种情况下，出现了很多协调方面的问题，造成运维工作明显滞后、相互推诿的情况，客户反映运维工作响应时间过长，运维效果没有达到要求，客户满意度不高。随着运维服务业务的开展，运维服务业务在公司业务比重的增加，同时运维服务业务具有长期性和稳定性，签订了第一年，如果没有大的失误，以后会比较容易继续签下去，业务来源比较稳定。公司高层认识到运维服务业务的重要性，调整了公司目标规划，开始对运维服务业务开始全面整顿，成立了专门的运维中心，对运维服务业务流程进行了调整，具体流程如图 3.4 所示：
在新的运维服务流程中，任务获取主要有两个途径，一类是公司负责建设的项目，建设完成后，在质保期内，由项目建设责任部门提出运维移交申请，经公司主管运维部门的副总审批后报项目管理科，项目管理科组织项目建设责任部门和运维部门进行运维移交。另一类是维保单位委托提供运维服务的，由项目管理科组织运维中心了解情况，签订运维合同。具体提供的运维服务分为两大类，一类是主动式维护，即定期对客户的系统进行检查，了解系统运行情况，根据业务需要提出优化整改意见，如不发生费用的增加，则立即实施，如有费用发生，则在双方协商后确定实施办法。另一类是被动式维护，即客户在系统出现故障后，通过呼叫平台向公司报修，公司根据呼叫请求安排人员进行维修，这类维护分为远程维护和现场维护，技术咨询类主要采取远程维护，重大故障处理主要是现场维护。
新的运维服务流程理顺了 W 公司的运维服务业务，每个运维服务合同进行了独立的财务立项，运维过程中发生的成本方便核算，运维服务效益也能明确量化出来。同时也方便了客户，之前出现了故障，因为故障类型不明确，客户即要找系统集成部，也要找资源开发部，一个故障可能来回找好几次才能解决，成立运维中心后，出现故障客户只要找运维中心的呼叫平台报修，其他的事情都不用自己去做，由运维中心来进行内部协调。新的运维服务流程执行后，取得了一定的效果，但是有一个问题却没有很好的解决，就是客户满意度问题。在运维中心成立之前，因为业务交叉开展的问题，公司没有对运维服务进行客户满意度调查，在运维中心成立以后，客户满意度是运维中心主要的绩效考核指标。每年 W 公司由项目管理科负责，对每个运维合同进行客户满意度调查，从 2011 年至 2014 年的客户满意度平均值如表 3.1 所示：
从表中可以看出，客户满意度总体来看比较低，有逐年下降的趋势。运维中心刚成立的时候，因为运维流程的捋顺，客户满意度相对来说高一些，但是后面几年的客户满意度都没有超过 50%.在 2014 年甚至发生了一件让 W 公司高层震惊的事情，在2014 年 W 公司收到了一份客户函，是一家水管单位以正式公文的形式发来的。对 W公司的运维服务提出了一些很尖锐的问题，表达了很明确的不满情绪。因为 W 公司是水务行业内部企业，和各个水管单位平时都保持着很好的关系，如果不是对运维服务意见很大，水管单位是不会做出这样的行为的。通过这个事件，公司高层意识到运维服务业务存在很大问题，需要进行更彻底、更全面的改造。运维服务流程再造提上了议事日程，本人作为运维部门的主管，受领导委任，全权负责对运维服务流程再造进行研究和设计，并组织再造实施。
在开始进行流程再造之前，我组织相关部门，通过因果分析法和头脑风暴法，找出运维服务流程存在的问题。首先分析问题原因，针对客户满意度低的问题，找出可能存在问题的方面，主要从技术人员、运维成本、运维响应以及公司信誉四个方面。
找运维部门相关人员，采用头脑风暴法找出所有可能的原因，将找出的原因进行归类整理，分析选取重要的因素。找到对这四个方面影响比较大的主要的原因。所产生的鱼骨图如图 3.5 所示：
在生成鱼骨图后，将鱼骨图上面列出的原因，针对客户和 W 公司员工，进行问卷调查，找出客户满意度低的主要原因。对 W 公司的 46 名与运维有关的员工进行了问卷调查，结果如下：
根据投票结果可以看出运维服务员工对往返时间长、批复手续时间长、备品备件不全以及内部流程复杂的投票率比较高，这四项占总投票数的比例达到 97%.
对 W 公司的 20 个运维服务主要客户进行问卷调查，结果如下：
根据投票结果可以看出，维护响应方面的问题是造成客户满意度的一个重要因素，而其中的到场时间长、备件更换慢以及设备维修慢几乎是每个客户都认为存在的问题。其次报修回复慢、技术人员能力水平低也占了一定的比例。
通过这一系列的调查和分析，最终找出 W 公司运维服务流程存在三个主要的问题：
第一任务获取涉及到的部门比较多，运维部门在合同签订的前期过程参与比较少，技术交底工作做得不够，各个部门之间的责权划分不是太明晰，负责项目建设的部门移交资料不是很规范，项目管理科的组织协调工作流于表面，不够深入，在运维工作具体实施过程中，因为技术交底不够，对所运维的系统了解不够，造成运维难度加大，成本超支。部门之间协调有一定难度，有相互推诿现象。
第二没有对运维服务内容进行分工，公司的运维服务主要针对的是水利行业，水利行业受地域限制比较明显，很多作业地点都在偏远山区，因为没有对服务内容进行分工，造成偏远山区的运维响应很不及时。运维业务流程较长，涉及的部门较多，分工过细，造成工作效率不高。备品备件更新不及时，没有建立备品备件库，在需要更换备品备件时，需要层层审批，耗时过长。
第三没有专门的运维质量监管部门，对运维服务监管不全面，只是对故障报修进行了满意度征询，没有对运维服务进行全程监管，存在运维效率低，同一个故障多次运维的现象。无法及时发现运维服务过程中出现的问题以及客户对运维服务的满意情况，客户的意见不能及时的传达到公司的管理层，小的矛盾堆积的结果就是大的意见的出现。
