企业信息化应用软件项目失败原因分析

newmaker

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 相对其他软件项目而言，应用软件项目失败的风险更大，其中有用户对自己需求认识不清、用人不当的原因，也有软件开发商开发能力不足，或者由于价格战，导致开发商动力不足的原因。 我国的应用软件产业已经走过了几十个年头，从最初的财务软件到MIS，到MRP、MRPⅡ，再到ERP、CRM，真正达到商家和最终用户双赢的项目并不多，更多的是失败的教训，甚至是一些不堪回首的记忆。尽管如此，却很少看到能够勇于面对这些失败的项目并进行深度分析者，毕竟失败是很没有面子的事情。但如果我们连正视失败的勇气都没有，又从何处积累经验、总结教训，在以后项目中进行有效的防范呢？在此，笔者从两个方面来讨论应用软件项目的失败，即软件开发商和用户。笔者并非要各打五十大板，只是从不同的角度对失败进行剖析、阐述。 用户: 需求不清，边界不明 用户作为项目的发起者、软件需求的提出者，在整个应用软件项目中所起的作用至关重要。没有需求，应用软件开发商就成了无本之木，而且当应用软件开发完成以后，用户才是对软件功能体会最深的、最有发言权的人，那么用户在应用软件项目中容易走入哪些误区呢？ 1. 对软件认识不到位 “重硬轻软”是最普榈囊恢执砦笮奶Ｓ布蚧乩匆院蠓旁谖葑永铩耙淮蠖选薄⒑苷嫉胤剑瓷先ヒ埠苷腥讼不丁６砑兀坎还且徽殴馀?以前更不起眼，几张软盘而已)。笔者就听到过“一张盘就值几十万？”类似的质问。事实上，软件的重要性已经有很多论述，但要从根本上转变这种观念并非易事。 2. 用人不当 计算机和应用软件目前虽然已经十分普及，但是对于大多数人来说还是比较陌生的，尤其是对于国内企业的中、高层管理人员。而年轻人接受新事物快，因此项目负责人、信息中心负责人不乏二十多岁的年轻人。然而，年轻人经验阅历不足，为了弥补这个不足，很多企业由副总或其他拥有更强业务能力、更高职位、更高威信的人担当项目总负责人，看起来似乎很合理，可是这样的组织结构为后期的失败已经打下了“坚实”的基础。原因如下: (1) 所谓应用软件，一定与实际业务息息相关，往往需要很多工作经验才能够很好地对业务进行把握，尤其是涉及到核心业务功能或企业业务流程重组的时候。对于刚刚毕业或参加工作不久的人员来说，确实不具备这样的能力。 (2) 随着企业对应用软件需求的不断细化，各部门的业务协调、业务协作必不可少。有些时候复杂度甚至超过某些软件功能本身，如果其中还存在直接或间接的利益冲突，那就更加可怕了。这些问题会让阅历和资历都不足的年轻负责人苦恼万分。 也许有人存在这样的疑问: 不是有一个“有更强业务能力、更高职位、更高威信的人”可以咨询吗？事实上，这样的人很难发挥作用，因为其中很多人是企业的关键人物，同时负责诸多项目，他们一般只在涉及到企业直接利益的项目上花费较大的精力，而其他项目只是挂个名。所以，选择项目或信息中心负责人时千万不要以计算机熟练为惟一的评选标准。 3. 需求不清，边界不明 如果已经存在用人不当的问题，则需求不清，边界不明”这个问题就早已经存在了。那么是不是找一个业务能力超强、具有独特眼光的人或者某个领域的专家就没有问题了呢？答案是否定的。 说到需求虽然用户最有发言权，但是可能会走向另一个极端，那就是对软件要求太高，认为软件能够解决一切问题，即: 将软件的功能边界无限扩大，反而使原本清晰的需求变得摇摆不定，甚至含糊不清。笔者参与过这样一个项目，用户方有一个行业专家，有近三十年的工作经验。在分析和设计阶段，需求报告反复修改了多次，该软件差不多包括了所有与业务相关的功能，而且已经考虑到了以后几年的发展，从物料编码到业务流程，无不功能强大、覆盖面广。然而，种种限制使得我们无法开发出这样完备、全面的软件系统，最后的结果并不理想。 在此不是要否认专家的作用，而是我们应该如何借用他们的智慧。笔者认为进行需求分析和边界定义的时候，采用“四象限法”比较好。可以把需求按照“重要且紧迫”、“次要但紧迫”、“重要但不紧迫”、“次要且不紧迫”划分为四类，把项目分成几个阶段，首先完成“重要且紧迫”的，而后完成“次要且紧迫的”，第三完成“重要但不紧迫”的，最后在完成“次要且不紧迫”的。这样不仅保证了核心需求的边界，而且充分考虑了软件功能的扩展性，进而确保项目的正常进度和效果。 软件开发商: 重打单，轻做单 软件开发商作为项目的开发者，其重要性毋庸置疑，毕竟一切有关应用软件的构想再全面、再完美，在没有变成现实以前，也都是纸上谈兵。很多软件开发商喊出“满足客户需求”的口号，但在实际开发过程中真的这样做了吗？尤其是当项目订单满天飞的时候，是不是存在下面的问题呢？ 1. 职责不清，分工不明 由于许多软件开发商现在还处于“作坊”的状态(只是存在“大作坊”和“小作坊”的区别)，所以研发人员职责不清、分工不明的现象非常严重。有的甚至从调研到分析/设计，到开发、调试，再到实施、维护，一气呵成。先不说工作量有多大，仅从项目的风险来说就是非常可怕的，更不用说最大限度发挥研发人员的长处了。 在笔者看来，研发人员的职责一定要进行划分，但是可以根据公司的实际情况来决定划分的粒度。 2. 眼高手低，重打单，轻做单 研发人员与销售人员之间存在一定的矛盾，之所以存在矛盾主要是各自工作目的和所站角度有比较大的差异。研发人员认为销售人员到用户那里就是吹牛皮，压根儿不管技术难度与合理性; 销售人员认为研发人员过于保守，不放“卫星”如何能拿到订单。解决矛盾的办法，就是把研发人员和销售人员团结在一起，真正成为“一根绳子上的蚂蚱”，这样他们就会心往一处想，劲往一处使。笔者想从以下两点进行阐述: (1)协调研发与销售的关系 对于销售人员的考核往往从签单量、回款量、回款周期几个角度，是否可以增加项目周期和项目成本作为考核指标呢？毕竟功能复杂的项目往往会花费较长的周期和较多费用，增加考核维度可以让销售人员多从项目整体的角度看问题，而不是仅仅从自身利益看问题。 对于研发人员的考核大多从项目的开发质量、开发周期几个角度，是否可以增加功能满意度和功能使用度作为考核指标呢？我们开发软件目的是让用户能够更好地使用，以解决业务问题。功能是否好用虽然比较主观不好量化，但还是可以从最基层的操作员那里获取一手资料的，功能的使用度可以按周或月进行量化统计，这样可以比较有效地保证软件实用，使研发人员不仅关心是否开发出软件，更让他们关心开发完成以后用户的使用情况。 能够让研发人员和销售人员达到最大程度的统一是比较困难的，作为公司领导层一定要重视该问题，避免产生不必要的内耗。这也许是为什么大公司的销售人员中很多来自研发人员的原因吧！ (2)做单要专业 笔者一直把“专业”这个词看得非常重，一个软件从界面到帮助、从提示信息到功能组织都能够体现出软件的专业性。如果起码的专业性都达不到，那么用户又如何信任你呢？ 专业性的体现是全面而细致的，从项目的计划书到软件培训方案、试运行计划，都要让用户感到你是确确实实为他着想。 3. 相互残杀，自取灭亡 我们曾经在竞标时遇到过报价相差一半以上的事情(排除恶意竞争和故意报高价的情况)，相信很多人也有过类似的经历。市场经济有它的规律和规则，大家即便想取得竞争的胜利，也要按照科学规律行事，否则别说先把蛋糕做大，而后大家再分，恐怕蛋糕还没有做好，就已经没有了。 笔者无意让各个软件开发商串联，让用户多掏腰包，而是希望大家把竞争放到软件功能和服务质量中去，不要老是进行价格战，最终结果只能是“三败俱伤”，不仅软件开发商赚不到钱，而且用户也无法享受应该得到的软件和服务，不利于应用软件的发展。这又是何必呢？(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (6/20/2006)