e-works数字化企业网  »  文章频道  »  信息化咨询  »  IT规划

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

2017/11/30    来源:互联网    作者:佚名      
关键字:信息化  
相对其他软件项目而言,应用软件项目失败的风险更大,其中有用户对自己需求熟悉不清、用人不当的原因,也有软件开发商开发能力不足,或者由于价格战,导致开发商动力不足的原因。

    我国的应用软件产业已经走过了几十个年头,从最初的财务软件到MIS,到MRP、MRPⅡ,再到ERPCRM,真正达到商家和终极用户双赢的项目并未几,更多的是失败的教训,甚至是一些不堪回首的记忆。尽管如此,却很少看到能够勇于面对这些失败的项目并进行深度分析者,究竟失败是很没有面子的事情。但假如我们连重视失败的勇气都没有,又从何处积累经验、总结教训,在以后项目中进行有效的防范呢?在此,笔者从两个方面来讨论应用软件项目的失败,即软件开发商和用户。笔者并非要各打五十大板,只是从不同的角度对失败进行剖析、阐述。

用户:需求不清,边界不明

    用户作为项目的发起者、软件需求的提出者,在整个应用软件项目中所起的作用至关重要。没有需求,应用软件开发商就成了无本之木,而且当应用软件开发完成以后,用户才是对软件功能体会最深的、最有发言权的人,那么用户在应用软件项目中轻易走进哪些误区呢?

    1.对软件熟悉不到位

    笔者就听到过“一张盘就值几十万?”类似的质问。事实上,软件的重要性已经有很多论述,但要从根本上转变这种观念并非易事。

    2.用人不当

    计算机和应用软件目前固然已经十分普及,但是对于大多数人来说还是比较陌生的,尤其是对于国内企业的中、高层治理职员。而年轻人接受新事物快,因此项目负责人、信息中心负责人不乏二十多岁的年轻人。然而,年轻人经验阅历不足,为了弥补这个不足,很多企业由副总或其他拥有更强业务能力、更高职位、更高威信的人担当项目总负责人,看起来似乎很公道,可是这样的组织结构为后期的失败已经打下了“坚实”的基础。原因如下:

    (1)所谓应用软件,一定与实际业务息息相关,往往需要很多工作经验才能够很好地对业务进行把握,尤其是涉及到核心业务功能或企业业务流程重组的时候。对于刚刚毕业或参加工作不久的职员来说,确实不具备这样的能力。

    (2)随着企业对应用软件需求的不断细化,各部分的业务协调、业务协作必不可少。有些时候复杂度甚至超过某些软件功能本身,假如其中还存在直接或间接的利益冲突,那就更加可怕了。这些题目会让阅历和资历都不足的年轻负责人苦恼万分。

    也许有人存在这样的疑问:不是有一个“有更强业务能力、更高职位、更高威信的人”可以咨询吗?事实上,这样的人很难发挥作用,由于其中很多人是企业的关键人物,同时负责诸多项目,他们一般只在涉及到企业直接利益的项目上花费较大的精力,而其他项目只是挂个名。所以,选择项目或信息中心负责人时千万不要以计算机熟练为惟一的评选标准。

    3.需求不清,边界不明

    假如已经存在用人不当的题目,则需求不清,边界不明”这个题目就早已经存在了。那么是不是找一个业务能力超强、具有独特眼光的人或者某个领域的专家就没有题目了呢?答案是否定的。

    说到需求固然用户最有发言权,但是可能会走向另一个极端,那就是对软件要求太高,以为软件能够解决一切题目,即:将软件的功能边界无穷扩大,反而使原本清楚的需求变得摇摆不定,甚至含糊不清。笔者参与过这样一个项目,用户方有一个行业专家,有近三十年的工作经验。在分析和设计阶段,需求报告反复修改了多次,该软件差未几包括了所有与业务相关的功能,而且已经考虑到了以后几年的发展,从物料编码到业务流程,无不功能强大、覆盖面广。然而,种种限制使得我们无法开发出这样完备、全面的软件系统,最后的结果并不理想。

    在此不是要否认专家的作用,而是我们应该如何借用他们的聪明。笔者以为进行需求分析和边界定义的时候,采用“四象限法”比较好。可以把需求按照“重要且紧迫”、“次要但紧迫”、“重要但不紧迫”、“次要且不紧迫”划分为四类,把项目分成几个阶段,首先完成“重要且紧迫”的,而后完成“次要且紧迫的”,第三完成“重要但不紧迫”的,最后在完成“次要且不紧迫”的。这样不仅保证了核心需求的边界,而且充分考虑了软件功能的扩展性,进而确保项目的正常进度和效果。

软件开发商:重打单,轻做单

    软件开发商作为项目的开发者,其重要性毋庸置疑,究竟一切有关应用软件的构想再全面、再完美,在没有变成现实以前,也都是纸上谈兵。很多软件开发商喊出“满足客户需求”的口号,但在实际开发过程中真的这样做了吗?尤其是当项目订单满天飞的时候,是不是存在下面的题目呢?

    1.职责不清,分工不明

    由于很多软件开发商现在还处于“作坊”的状态(只是存在“大作坊”和“小作坊”的区别),所以研发职员职责不清、分工不明的现象非常严重。有的甚至从调研到分析/设计,到开发、调试,再到实施、维护,一气呵成。先不说工作量有多大,仅从项目的风险来说就是非常可怕的,更不用说最大限度发挥研发职员的优点了。

    在笔者看来,研发职员的职责一定要进行划分,但是可以根据公司的实际情况来决定划分的粒度。

    2.眼高手低,重打单,轻做单

    研发职员与销售职员之间存在一定的矛盾,之所以存在矛盾主要是各自工作目的和所站角度有比较大的差异。研发职员以为销售职员到用户那里就是吹牛皮,压根儿不管技术难度与公道性;销售职员以为研发职员过于守旧,不放“卫星”如何能拿到订单。解决矛盾的办法,就是把研发职员和销售职员团结在一起,真正成为“一根绳索上的蚂蚱”,这样他们就会心往一处想,劲往一处使。笔者想从以下两点进行阐述:

    (1)协调研发与销售的关系

    对于销售职员的考核往往从签单量、回款量、回款周期几个角度,是否可以增加项目周期和项目本钱作为考核指标呢?究竟功能复杂的项目往往会花费较长的周期和较多用度,增加考核维度可以让销售职员多从项目整体的角度看题目,而不是仅仅从自身利益看题目。

    对于研发职员的考核大多从项目的开发质量、开发周期几个角度,是否可以增加功能满足度和功能使用度作为考核指标呢?我们开发软件目的是让用户能够更好地使用,以解决业务题目。功能是否好用固然比较主观不好量化,但还是可以从最基层的操纵员那里获取一手资料的,功能的使用度可以按周或月进行量化统计,这样可以比较有效地保证软件实用,使研发职员不仅关心是否开发出软件,更让他们关心开发完成以后用户的使用情况。

    能够让研发职员和销售职员达到最大程度的同一是比较困难的,作为公司领导层一定要重视该题目,避免产生不必要的内耗。这也许是为什么至公司的销售职员中很多来自研发职员的原因吧!

    (2)做单要专业

    笔者一直把“专业”这个词看得非常重,一个软件从界面到帮助、从提示信息到功能组织都能够体现出软件的专业性。假如最少的专业性都达不到,那么用户又如何信任你呢?专业性的体现是全面而细致的,从项目的计划书到软件培训方案、试运行计划,都要让用户感到你是确确实实为他着想。

    3.相互残杀,自取灭亡

    我们曾经在竞标时碰到过报价相差一半以上的事情(排除恶意竞争和故意报高价的情况),相信很多人也有过类似的经历。市场经济有它的规律和规则,大家即便想取得竞争的胜利,也要按照科学规律行事,否则别说先把蛋糕做大,而后大家再分,恐怕蛋糕还没有做好,就已经没有了。

    笔者无意让各个软件开发商串联,让用户多掏腰包,而是希看大家把竞争放到软件功能和服务质量中往,不要总是进行价格战,终极结果只能是“三败俱伤”,不仅软件开发商赚不到钱,而且用户也无法享受应该得到的软件和服务,不利于应用软件的发展。这又是何必呢?

责任编辑:程玥
本文来源于互联网,e-works本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供,并以尽力标明作者与出处,如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐