面对失败的企业信息化项目，不管是用户方、实施方或者供应商都能“公说公有理、婆说婆有理”的罗列出很多原因。外行看热闹，内行看门道。从失败案例中吸取教训、从甲乙双方甚至三方的争论中获得启发，就是我  们收集整理这些败案例、邀请众多资深信息化专家进行点评分析后，精心组织的《失败案例解析》系列报道的初衷。

俗话说：“一个巴掌拍不响”，任何一个项目的失败都应该是用户方和咨询方或实施方之间的不默契、不协调或者条件不具备而造成的恶果。但是主要责任人到底应该是谁呢？有意思的是，我们邀请的5位专家对这一案例进行点评后，结果形成了两派意见，一方认为主要责任在用户方领导不力，而另一方则认为咨询方水平有限。

华东的某个客户，我的项目。项目不大，2006年4月初签订服务协议。用户原计划7月1日上线，由于时间很紧，因此在我方说服下改为7月31日上线。用户总经理对这个项目很重视，这是一个不错的消息，但实际上由于总经理业务过于繁忙，因此指派手下某经理负责。项目伊始双方沟通了几次，觉得大方向是一致的，也比较好交流，本来应该顺风顺水的做好它，但项目进程中出的事情实在是……唉！

客户工厂的规模不大，人员配备不是很完整，个别部门干脆就只有主管一个人，身兼数职的情况比比皆是，因此项目初期作了几天Overview后，普遍感觉分身乏术，每天弄到很晚很晚，最后项目经理顶不住压力，决定辞职，当然原因肯定不止这一个。客户无奈暂时换财务经理作代理项目经理，但由于空缺的职位过于关键（SCM经理），因此，项目也只能暂时叫停。此时是4月下旬。

差不多2个月之后客户新的SCM经理已经熟悉了业务，于是项目继续进行。在简单做了2天Review后代理项目经理询问我能否先暂停一下，原因是制造经理的孩子要高考了，人生大事啊，我表示理解。

随后的某天又希望我能再延一段时间，原因是新来的SCM经理又辞职了，我当时郁闷啊……而且项目经理私下说，最好不要把项目拖到11月，因为11月他爱人生小孩，又一件人生大事，我也能理解，寒暄了一通后表示尽力赶在11月前上线，但前提是要找到不会短期内辞职的SCM经理。

同时，总经理也私下跟我谈到还是希望让SCM经理作项目的主导人，原因是SCM是企业的命脉，因此一定要等到这个位置稳定后再继续项目。这一点我赞同，因此项目就这样在刚刚重启动后又无奈的暂停。此时是6月下旬。
几周后突然接到项目经理的电话，通知我项目马上开始，由于迟迟没有招到合适的SCM经理，因此这个位置暂由制造经理兼任，同时财务经理也正式成为这个项目的负责人。经过一番沟通，我决定整理几天后项目继续。

就在我准备奔赴前线的时候，又一个电话，告诉我先不用过来了。我怒了，想发作，但是那边告诉我的情况又让我没办法怒起来，制造经理出车祸了。于是我只能询问几句后修改我的计划。项目再一次暂停。

由于我方的工作计划随着这个项目变来变去，我跟一起做这个项目的同事的日子也越来越不好过，因此被逼在10月末到了客户这边，试图强行启动项目。但是又失败了，原因是他们要迁厂……

最终，项目还是在没有完成迁厂的情况下重新启动了，原因是项目经理实在不能忍受没有系统的日子了——公司管理一团糟。项目12月下旬重新启动，预计2月31日上线。我又一次郁闷，原因是就算赶鸭子上架，这点时间也不多，况且还要迁厂，协调来协调去只能边干边看了。

半年内的时间里，客户经历了关键部门经理兼项目经理离职、关键部门经理孩子高考、关键部门经理再一次离职、关键部门经理车祸、关键部门经理爱人生小孩、公司迁厂等等，使我的工作计划一再被影响，为了这个离奇曲折的项目，搞得我差点被公司炒掉。

想想，也挺同情这个客户，半年内出了这么多事，对客户的影响是非常大的，当然对我们影响也是很大……总的来说客观因素主导了这个项目的进程。一句话，天有不测风云啊……

下一篇：一个BI（商用智能分析）项目的病因分析