[原创]项目上线推进中的7宗罪 (入选推荐日志，加20币)

最近给一个客户做的IT服务管理项目终于要验收上线了，但到运维基层去转了一圈，发现这个系统的推广使用的力度始终差强人意。下面是一点点我的感想，系统推动的各方面阻力。

1.客户端安装的阻力
这是属于先天顽疾，试产品选型造成的。项目的规模、资金、各种深层原因导致了选型的产生，客户端功能强大，WEB端功能弱。这也是诸多无奈的一种。C/S结构的产品需要去逐个安装和部署，当然不如B/S环境来的干净简便，虽然C/S我们可以说其功能会更强大，系统会更稳定，速度会更快。。。但B/S淘汰C/S是不争的事实，就算不淘汰，至少两个也是并行走路，不会变得高低不平。对于纯粹C/S的东西，用户当然没什么信心和好感，谁愿意装一堆庞大的程序在自己的机器上呢？所以你不主动去装，更别指望用户自己动手了。
改进办法：主动的为用户装好环境，如碰见不合作的，不愿意装的，只想用B/S的非暴力不合作最终用户，也只好苦口婆心，最不行只好从项目管理角度让客户高层施压统一部署了，：（。

2.老系统使用习惯的阻力
虽然也培训完了，该做的都做了，但要最终用户瞬间完全摆脱原有系统的使用习惯还是很不现实的。毕竟他们的原有系统再不好不完善，用起来咬牙切齿骂爹骂娘，但人家也是用了5、6年的了，就像热恋中的人结婚转亲情一样，你的优点、缺点都一并被接受，成了生活中的习惯。因此上新系统，磨合肯定会有的，甚至新系统的一些优点反而被当作了桎梏，比如说流程里的负责制度和倒计时算法，就远不如原来系统的挂起状态来的顺手。以前的系统比较简单，也就很灵活，而现在少了人治，都成了法制，流程治，多了很多条框，当然不习惯。
改进办法：1.两个系统并行一段时间是必然的；2.新系统用一段时间也慢慢习惯了；3.制度的推行，流程的规范是需要客户方高层大力去做的事，中间的抵触情绪也是必然的。

3.没有一套规章制度的保证
举例而言，一个报障电话，如何根据所报的故障系统，引入对应的情景问答的环境？，顺利诊断出故障点呢（也许你先根据IP查看故障地点再继续分下去）？如何给每个系统，每种服务确定出优先级别呢，什么样的情况该立即升级？什么样的给一线，怎么诊断下才能给二线呢？没有行动的指南，怎么能保障有条不紊的进行行动规范呢？这些只有客户才能给出答案。作为实施方，我们只能给出一些建议，但自己的业务系统，其复杂性、层次型、依赖性、重要性，只有自己才明白。但请他们做一个指南出来的时候，部门间又互相推诿，难怪接线员跟我说我都不知道哪个系统往哪里分，跟上面要这些资料也都没有，来了电话怎么做？难怪运维人员跟我说：到时候不明白就问值班经理好了。。。晕，从中也可以看出他们运维内部的混乱了。
改进方法：主动跟客户一起制定各种指导文件，推进项目顺利起步。一开始肯定是混乱的，刚起步阶段肯定很难，但是要有信心，走上正轨就好了。

4.服务台人手调配的问题
本来我们建议，考虑到接线员以前不懂业务，开始无法承担起指导解决事件的任务，所以服务台初期由接线员、有丰富运维经验的一线支持以及值班经理组成。但由于一些客观原因导致现在服务台只有一个接线员和很多的机房运维人员组成。机房人员一般属于后台支持的角色，只接一线运维转来的电话，面向最终客户的一线运维处理经验不是很多，因此也造成了一线解决效果不会太好。

5.用户运维人员庞杂、分布广发的问题
很多运维人员都整天在现场、不上线、不用系统，不查看邮件，又屏蔽了手机短信，分配的事件也不知道，沟通不畅，导致处理不及时。对于系统推广也十分不利。

6.初始资料不完全
因为不了解系统，当初客户给的初始化资料很不全，比如人员只有运维部门的名单，而没有公司内部其他部门（也就是运维部的客户）的名单，还有工作组，并不含总公司下属分公司或分支机构的运维部门，也就是说整个系统只把总部的运维工作纳入了进来。而事实是很多外地的用户也会打电话报障，此时则需要子公司或协助机构去进行处理（比如HX用户要求开个帐号等），不能统筹到全局一盘棋。
这时候就不能单纯靠一个软件工具去走流程了，必须有替代方法

7.客户的系统多、地域分散
目前的接线员是直接让用户转拨电话打给相关其它部门的，这种现象还很普遍，而通过上新系统，也暂时不能解决这类的问题。

推荐到鲜果： 查阅更多相关主题的帖子: IT服务管理