信息化失败案例分享
一些CIO在ITValue中分享了他们所知或所经历的失败案例,因为其中很多涉及到企业机密,因此以下案例将以匿名的方式呈现,并作了部分简化和改写。
案例一:
这个事情发生在某公司刚采用软件外包服务的时候。相对于这家公司原本合作过的一两家规模较小的企业来说,这家外包公司一开始就给CIO留下了很深的印象,派了个老外来谈业务,开发的方法论以及整体的架构都看起来非常的专业,很快便与对方总经理见面详谈,认可了对方经营团队表现出来的专业度。到实质的项目合作阶段,从签定NDA防止泄密开始,到提出规格书给对方,到具体排定开发进度以及报价,在报价阶段,对方展现了非常大的弹性和诚意,很快双方就签了约。
项目前期,一切都还在控制之中,部门的项目经理在前期跟CIO报告过对方除了项目经理以外的人员都毕业不超过一年时,CIO认为对方的管理制度应该解决和面对这类问题,甲方只要定期审核项目进度就可以了,所以不以为意。
到了项目的后期阶段,问题终于爆发出来了。首先是要求对方做功能性的演示,发现整个流程甚至不能完整的跑完,对方为了赶进度,居然没有做好内部的QA环节,导致质量出现很大的问题。然后再出现很大的效能问题,程序的效能慢到无法接受,用户界面的友好性也完全无法接受。这个时候,他们的反馈居然是这些并没有明确定义在甲方提供的规格书当中,所以并不能算是乙方的问题。实际上,通过检查源代码,发现乙方的5个开发人员是完全各自按照自己的思路开发,而非遵循通常的统一开发流程。
还好,对方的销售人员还算愿意负责,承认他们的错误,大家友好的协商如何能够把项目结掉,但这个时候又发生了几件事情。
首先,开发人员产生很大的抵触情绪,认为他们按照规格来开发是没有错误的,现在要返工,对开发人员是不公平的,这个情绪直接导致开发人员效率不高。再来,发现项目质量有问题之后,对方的QA开始投入项目中,在项目质量及项目进度的双重压力下,居然导致了QA以及开发人员的对立,对方销售人员答应的进度因此一再跳票。用户则不断的在内部质疑项目到底何时能够上线。更离谱的是,乙方的项目经理居然在这个节骨眼,被抽调到另一个大客户的项目中。这导致甲方不得不要求就地结案,不付尾款。最后找了一个原来报价高出很多的供应商来做收尾工作,系统上线至少被推迟了三个月。
案例二:
3年前某集团开始做整体信息化的时候,经过招标选型,最后和国内某知名管理软件公司签约。除了集中财务管理、人事管理系统和OA办公系统之外,还牵扯到对主营业务的管理。由于主营业务的管理在市场上没有合适的商品化软件匹配,最后考虑定制开发,出于品牌效应和质量考虑,选择由同一家供应商来做。甲方为了帮助软件公司熟悉业务,还提前做了很多需求整理的工作,帮对方理清了需求的大框架。
但随后问题就出现了。对方并没有按合同签订的1个月内安排开发团队进场,一直抽不出足够的人手。多方沟通、交涉,终于在6个月后入场,但对方的开发团队不是本地的,而是在另外一个城市做开发,后来协调为对方在调研期间每周过来一次,开发期间每月过来一次。
需求调研和开发过程还算顺利,人员能力不错,过程中发现的较明显的问题要求对方整改,对方也表示没问题。半年后初版开发完成,开始给试点用户培训,并开展内测。
随后便发现很多严重的问题,遂要求对方派人现场驻点进行修改,连续两个月,越试用,发现的问题越多;越了解,发现对方的团队,除了一个有经验的程序员外,其他几个都是刚毕业的大学生,后面的代码都是菜鸟写的。然后,就是反复的僵持和扯皮,甲方觉得软件问题很多,功能有缺陷,质量和稳定性很差;乙方觉得甲方的需求老是在变,要求太高,他们驻场的成本费用太高。
就在这关键时刻,公司决定在另一个城市启动一个投资几亿的重大项目,主要的业务高管和业务骨干,大部分都被抽调到该城市,项目的试点和实施几近于停滞。CIO不得不暂停实施,砍掉一些非关键的业务功能,只保留系统的核心功能,以避免整体失败。一年后,公司在另一个城市的项目结束,一切才又回到正轨。
案例三:
某大型电子产品零售分销企业,投资100多万,和国内某知名软件公司签约,进行财务集中管理和供应链管理。一年后,项目实际上已经失败。现在该公司只用了财务集中管理软件,其供应链管理软件又换回了原来用的某小企业开发的分销ERP管理软件。
案例四:
某大型家具制造企业,投资几百万,和国内某知名软件公司签约,进行全面的信息化。经过一两年,项目也几近失败。后来该公司从外部引进一牛人担任CIO。该CIO上任后,分批逐步中断了与该软件公司的合作项目。全部采用某国外知名ERP公司的全套管理软件,现在逐步进入正轨。
案例五:
一家很有名的跨国公司的亚太CIO,公司的核心管理系统做了五六年了,但至今仍只上了一个MRP系统,其中不成功的项目很多,但究其原因还是因为其中国战略不稳定,公司一直分分合合,业务环境尚不明朗,职权分配都不清楚,要做成一个项目太难了,虽然他们公司用的系统都是最好的。项目失败和公司业务发展有根本联系。
案例六:
某公司有一次系统上线,时间紧迫,业务负责人要求不做盘库,直接拿旧的手工账做数据的迁移,结果导致上线后的MRP失败,原因是实际库存和账面差异很大。
信息化项目失败中总结的教训与经验
1、要有控制权、强硬的措施、不能委曲求全
项目经理一定要想办法保持自己对于乙方的控制权,并且在项目遇到麻烦的时候,甚至可以果断的暂停项目,对乙方施加强硬的措施,不能为了而所谓的整体利益或者后续的合作,而委曲求全,最后导致更大的危机出现。
2、前瞻性,和公司重大项目资源不冲突
在制定项目计划的时候,一定要具有前瞻性,不要和公司其他的重大项目在世家和人员安排上面发生冲突,否则到时候被PK掉的一定是信息化系项目。
3、信息项目应用水平要和公司的管理水平相匹配,保证能实现基本的功能,再求改进
信息化项目的应水平,一定要和公司的管理基础和水平相匹配,如果试图在公司自身的管理还不规范的时候,达到一个理想的效果,最后只可能连最基本的功能都做不好。
4、业务管理软件要重点,因为实施成功率低
诸如财务或OA之类的标注化程度比较高的系统,一般失败的几率很小,感觉真正容易发生问题的项目,一般都是业务管理软件,特别是定制开发的,或者是选型不当的。
5、不迁就业务的一些不合理要求
永远不迁就业务的一些不合理要求,该做的就是要不折不扣的完成。
6、项目开始之前就应该有大概议事规则等
项目还没开始就要有内部和外部的大概议事规则等,选型时候对项目负责人的预见力和洞察力的要求还是蛮高的。
7、甲方负责人要考虑的问题,保障项目成功,并且过程和结果的可控性
任何项目在选型、选产品、选合作团队的时候,作为甲方负责人我认为最关注的应该是围绕"如果我来负责这个项目,结合自己在甲方的位置和影响力及个人能力,团队能力,应该如何选择产品和顾问团队,来保障项目成功,并且过程和结果能够较为可控性"
8、合同内容明确,加强对乙方人员的控管
供应商在选型和谈判阶段,为了能够拿到项目,很多条件都可以答应,不合理的价格也可以接受,这就为未来的风险埋下了伏笔。建议大家以后一定要在合同中,对乙方的团队的人员予以明确约定,并就违反责任约定清楚,这样加强对乙方人员的控管。
9、项目的实施要有全面的统筹,实施过程中要有IT人员参与
有些企业项目的立项和预算是业务部门主导的,很多项目是业务做好后交给IT运维。项目的立项和实施缺乏全面的统筹,实施过程中IT人员没有很好的跟进和了解系统,系统为了上线又做了大量的客户化开发,后期运维的费用又不足以支撑这些开发导致的继续开发。
10、要有必胜的信心和执着的坚持
ERP的失败比ERP的成概念股更有效益,不管是对自己还是别人、IT项目的失败其实很普遍,据分析,信息系统失败的概率是70%。这么多年从事信息化,应该说特别失败的案例没有,但每一个项目其实都很不容易,如果没有必胜的信息和执着的坚持,是很难取得成功的。有些项目甚至是经过几年的努力坚持下来,最后取得一定效果的。
11、战略不稳定,业务不明朗,职权不清楚会导致信息化很艰难
公司战略不稳定,公司一直分分合合,业务环境尚不明朗,职权分配都不清楚,信息化系那个木由此艰难。
12、依据合同及时支付款项给乙方
阶段性成功后,甲方该支付给乙方的款项应该及时支付,对结果的担心可能造成对双方合作关系的直接伤害。
13、综合分析,得出几大类原因:公司战略不明确;上线时机选择不对;业务需求不明确、人员不配合;供应商不配合,能力差;信息化制度、机制不明确。