ERP项目失控的九大原因

ERP项目失控的九大原因

【 分析评论】

前面讲系统论和项目管理，说到项目经理要牢牢抓住项目的控制权。项目失控就如同风筝断线、火车出轨，发展的趋势完全不可预知，是非常可怕的事情，项目失控是项目管理者永远的痛。究竟是哪些原因导致项目失控呢？这个问题很难回答，不幸的项目各有各的不幸。以笔者的经验和直感而言，以下这些因素虽然不是造成项目失控的全部，但绝对是项目经理需要高度警惕的、最大可能造成项目失控的危险因素。

第一、目标不明，范围不清

目标不明，范围不清的项目永远都不可能实施成功。所以项目一开始就应该把目标和范围定清楚，否则就不宜开始实施，如果不知道项目要达成什么目标，那最好的办法是索性不干，等目标明确了再干。还有范围不清，实施的软件到底包括哪些功能模块？覆盖到哪些部门和用户？管理层需要哪些报表和信息？这些都是范围介定的问题。

范围不清，目标不明在很多人看来是很滑稽的问题，甚至会问，目标都没想清楚为什么还要上？这应该是IT项目比较突出的问题，因为IT项目是无形的，很多时候客户的需求是朦胧的，比如客户看到或听说沃尔玛的信息化很好，能在一小时内实现全球近四千家分店的盘点，自己也心向往之，想借助信息化达到这种目的，这就是他的业务需求，这个目标太大、太不确定，但是你要让客户把他的需求表达得更具体点却很困难，他甚至说不出来具体需要哪些功能模块，客户往往不能明确表达他的需求是信息化项目最大的特点和难点，所以供应商要不断探索、引导、激发客户的需求。

经常的情形是这样的，在项目一开始的时候目标和范围都是有的，只不过这时目标和范围因为客户对ERP的理解不到位而具有不确定性和局限性，有些时候，实施方的实施顾问试图修正客户理解的这种具有不确定性和局限性的需求，却因为客户那种防范供应商投机取巧的心理而拒绝接受实施顾问的建议。但随着项目的进行，客户在实施的过程中有了对ERP的全面体验和直接的感受，他的需求才真正得到激发，于是，就强烈要求范围变更和目标再定义，在原来范围的基础上增加很多功能，范围不断扩大，而且，往往以客户就是上帝的有利地位逼迫供应商无条件答应，甚至工期还不能拖延。这就造成一个很大的矛盾，范围扩大，甚至目标改变，而投资不能追加，工期不能拖延，这样的项目不失控才怪。很多IT项目失败就是因为陷入这个需求的怪圈。

我想应该从两个方面入手来化解这个矛盾，首先，客户要在签约前尽可能深入了解供应商以及软件的功能，甚至多考查一些案例，我曾经提出过项目选型的“五实”模型(实力、实例、实际、实践、实施)，事前多了解一些，定位就更精准一些；其次，实施方的顾问还要做出努力，尽量引导客户的需求，甚至激发客户的需求，尤其是核心需求，就像盖房子必须要有洗手间一样，不管客户有没有明确提出，有洗手间都是核心需求，客户没有提出，顾问就要引导，有的顾问为了减少工作，对客户没有明确提出的核心需求也装聋作哑，敷衍搪塞，殊不知这种需求迟早是要实现的，等到客户省悟过来再去实现，就造成很大的被动；第三，就是双方都要作出努力，范围是项目的自变量，投资、工期是因变量，范围改变，投资和工期不改变是违反客观规律的、自欺欺人的做法，所以，范围和目标的小范围变更是难免的，和这种变更相配套的投资追加、工期延长也要跟上，这需要双方都作出让步，共同实现目标。这一点很多客户不理解，误以为强压供应商实现额外的需求是一种胜利，遗憾的是，这种手段的结果往往是造成项目失败和巨大损失，ISO9000标准中提出的八大质量管理原则很重要的一条就是与供方互利的原则。有人讲，把ERP卖贵了是欺骗客户，把ERP卖便宜是更阴险、更潜在的欺骗客户，因为，当供应商的收益不足以支撑他实施好该项目应有的投入时，项目失败的风险就会徒增。

第二、实施策略错误：

实施策略的失误是一种方法论上的错误。常见的有以下几种类型：

贪大求全：总想一步到位，摊子铺得太大，顾此失彼，总想一步到位，结果到不了位。

先难后易：没有采纳先易后难，循序渐进的原则，一上来就打攻坚战，比如有人选择先实施BOM，觉得这是最关键的，但问题是实施BOM所需要的很多基础数据是要从其他模块中来的，这些基础模块不到位，实施BOM就很困难，所以还要遵循ERP123的原则，退回到基础的进销存管理。如果一上来就试图解决难题，就会碰了钉子，受打击，进而丧失了信心，没积累到经验反倒积累了教训，这种惨痛的教训会让你害怕ERP，远离ERP。

缺乏统筹：工作安排缺乏统筹，前后衔接有问题。有的项目做了一半进行不下去了，原因是前一道更紧急的工序没做完，后面只能停工等待了。这种缺乏统筹安排的策略失误也经常会导致一个项目的失控，至少也要导致工期的拖延。

估计的错误：对项目工作量估算不足，没有留有余地，经不起节外生枝，某一环节耽误引起连锁反应，延误整个工期。

盲目赶工：快不总比慢好。我非常反感有一些项目盲目赶进度，应付上级检查的做法。这些项目后墙不倒，一定要赶到某一天验收，所以就盲目地赶工。有时候慢反倒是把稳一点，一味地追求速度，难免讲求速度忽视质量，等发现质量问题的时候再返回来，就欲速则不达，造成项目失控。

第三、过程监控不力

有的企业领导人把一把手工程做成大撒手工程，交钥匙工程。他们想：反正我又不懂，就交给懂一点的人去干，到时候你给我一个结果就行了。这种大撒手的做法实际上是一种不负责任的授权，是项目管理的大忌。因为从开始到有结果有一个很大的中间过程，这个中间过程中有太多的岔道和歧路，过程监控的作用就是及时把项目从岔道和歧路上拽回来，使其重新走向正轨，如果缺乏这个环节，那么，当企业领导发现项目走向歧途的时候已经为时已晚，无能为力了，项目陷入失控状态。

所以企业高层对项目阶段性的评审非常重要。高层哪怕对ERP不懂，也要经常过问，同样的，项目组也要阶段性地主动向高层汇报项目进展状况，让他了解到每一步，知其然，也知其所以然。如果高层不知其所以然的话，他就可能是一个定时炸弹，突然一天可能因为项目结果和他所预期的强烈反差而暴跳如雷，拍案而起。

过程评审是最常见的过程监控手段，目的是阶段性的检查项目是不是偏离了目标，过程的中间结果和预期有什么差异，这种差异通过什么样的手段来纠正和弥补。因为IT项目的中间结果是无形的，所以只有具备专业知识的专家才能给中间结果给予恰当的评价，这就给阶段评审带来一定的难度。

阶段评审不力的后遗症就是容易把错误的东西投入复制。一旦错误的方案被实施发布，再修复的代价就很高。一个有潜在问题的东西，你复制的越多，潜在的危险就越多，纠正或修复的成本就很大。微软的Windows设计缺陷导致冲击波病毒，为修复这个缺陷，微软要付出很大的代价，经常看到某款汽车曾因设计缺陷被厂家招回，这个招回的成本也是高得惊人的。所以，把有缺陷的方案投入复制，会导致项目的运行处于不可控的发散状态，非常危险。

本书“IT项目阶段评审指南”一文较详细地介绍了一般的阶段评审过程，可供大家参考，在此不再赘述。