尽管平时在ITValue社区或是电子周刊中讨论和报道的都是一些优秀企业的信息化成功案例，但也有CIO在社区中提出，在这些企业中，或是一些不那么成功或优秀的企业中，也一定会有很多失败或是不那么成功的信息化项目，这些失败所体现出来的经验教训似乎对CIO们做好信息化更有帮助和警示作用，也更能够让我们在信息化光环之外，体会到更多的东西，感受到更多的真实。

一些CIO在ITValue中分享了他们所知或所经历的失败案例，因为其中很多涉及到企业机密，因此以下案例将以匿名的方式呈现，并作了部分简化和改写。

案例一：
这个事情发生在某公司刚采用软件外包服务的时候。相对于这家公司原本合作过的一两家规模较小的企业来说，这家外包公司一开始就给CIO留下了很深的印象，派了个老外来谈业务，开发的方法论以及整体的架构都看起来非常的专业，很快便与对方总经理见面详谈，认可了对方经营团队表现出来的专业度。到实质的项目合作阶段，从签定NDA防止泄密开始，到提出规格书给对方，到具体排定开发进度以及报价，在报价阶段，对方展现了非常大的弹性和诚意，很快双方就签了约。

项目前期，一切都还在控制之中，部门的项目经理在前期跟CIO报告过对方除了项目经理以外的人员都毕业不超过一年时，CIO认为对方的管理制度应该解决和面对这类问题，甲方只要定期审核项目进度就可以了，所以不以为意。

到了项目的后期阶段，问题终于爆发出来了。首先是要求对方做功能性的演示，发现整个流程甚至不能完整的跑完，对方为了赶进度，居然没有做好内部的QA环节，导致质量出现很大的问题。然后再出现很大的效能问题，程序的效能慢到无法接受，用户界面的友好性也完全无法接受。这个时候，他们的反馈居然是这些并没有明确定义在甲方提供的规格书当中，所以并不能算是乙方的问题。实际上，通过检查源代码，发现乙方的5个开发人员是完全各自按照自己的思路开发，而非遵循通常的统一开发流程。

还好，对方的销售人员还算愿意负责，承认他们的错误，大家友好的协商如何能够把项目结掉，但这个时候又发生了几件事情。

首先，开发人员产生很大的抵触情绪，认为他们按照规格来开发是没有错误的，现在要返工，对开发人员是不公平的，这个情绪直接导致开发人员效率不高。再来，发现项目质量有问题之后，对方的QA开始投入项目中，在项目质量及项目进度的双重压力下，居然导致了QA以及开发人员的对立，对方销售人员答应的进度因此一再跳票。用户则不断的在内部质疑项目到底何时能够上线。更离谱的是，乙方的项目经理居然在这个节骨眼，被抽调到另一个大客户的项目中。这导致甲方不得不要求就地结案，不付尾款。最后找了一个原来报价高出很多的供应商来做收尾工作，系统上线至少被推迟了三个月。

案例二：
3年前某集团开始做整体信息化的时候，经过招标选型，最后和国内某知名管理软件公司签约。除了集中财务管理、人事管理系统和OA办公系统之外，还牵扯到对主营业务的管理。由于主营业务的管理在市场上没有合适的商品化软件匹配，最后考虑定制开发，出于品牌效应和质量考虑，选择由同一家供应商来做。甲方为了帮助软件公司熟悉业务，还提前做了很多需求整理的工作，帮对方理清了需求的大框架。

但随后问题就出现了。对方并没有按合同签订的1个月内安排开发团队进场，一直抽不出足够的人手。多方沟通、交涉，终于在6个月后入场，但对方的开发团队不是本地的，而是在另外一个城市做开发，后来协调为对方在调研期间每周过来一次，开发期间每月过来一次。

需求调研和开发过程还算顺利，人员能力不错，过程中发现的较明显的问题要求对方整改，对方也表示没问题。半年后初版开发完成，开始给试点用户培训，并开展内测。

随后便发现很多严重的问题，遂要求对方派人现场驻点进行修改，连续两个月，越试用，发现的问题越多；越了解，发现对方的团队，除了一个有经验的程序员外，其他几个都是刚毕业的大学生，后面的代码都是菜鸟写的。然后，就是反复的僵持和扯皮，甲方觉得软件问题很多，功能有缺陷，质量和稳定性很差；乙方觉得甲方的需求老是在变，要求太高，他们驻场的成本费用太高。

就在这关键时刻，公司决定在另一个城市启动一个投资几亿的重大项目，主要的业务高管和业务骨干，大部分都被抽调到该城市，项目的试点和实施几近于停滞。CIO不得不暂停实施，砍掉一些非关键的业务功能，只保留系统的核心功能，以避免整体失败。一年后，公司在另一个城市的项目结束，一切才又回到正轨。

案例三：
某大型电子产品零售分销企业，投资100多万，和国内某知名软件公司签约，进行财务集中管理和供应链管理。一年后，项目实际上已经失败。现在该公司只用了财务集中管理软件，其供应链管理软件又换回了原来用的某小企业开发的分销ERP管理软件。

案例四：
某大型家具制造企业，投资几百万，和国内某知名软件公司签约，进行全面的信息化。经过一两年，项目也几近失败。后来该公司从外部引进一牛人担任CIO。该CIO上任后，分批逐步中断了与该软件公司的合作项目。全部采用某国外知名ERP公司的全套管理软件，现在逐步进入正轨。

案例五：
一家很有名的跨国公司的亚太CIO，公司的核心管理系统做了五六年了，但至今仍只上了一个MRP系统，其中不成功的项目很多，但究其原因还是因为其中国战略不稳定，公司一直分分合合，业务环境尚不明朗，职权分配都不清楚，要做成一个项目太难了，虽然他们公司用的系统都是最好的。项目失败和公司业务发展有根本联系。

案例六：
某公司有一次系统上线，时间紧迫，业务负责人要求不做盘库，直接拿旧的手工账做数据的迁移，结果导致上线后的MRP失败，原因是实际库存和账面差异很大。

CIO维基的从项目失败中总结的教训与经验

1、项目经理一定要想办法保持自己对于乙方的控制权，并且在项目遇到麻烦的时候，甚至可以果断的暂停项目，对乙方施加强硬的措施，不能为了所谓的整体利益或者后续合作，而委曲求全，最后导致更大的危机出现。

2、在制定项目计划的时候，一定要具有前瞻性，不要和公司其他的重大项目在时间和人员安排上面发生冲突，否则到时候被PK掉的一定是信息化项目。
3、信息化项目的应用水平，一定要和公司的管理基础和水平相匹配，如果试图在公司自身的管理还不规范的时候，达到一个理想的效果，最后只可能连最基本的功能都做不好。

4、诸如财务或OA之类的标准化程度较高的系统，一般失败的几率很小，感觉真正容易发生问题的项目，一般都是业务管理软件，特别是定制开发的，或者是选型不当的。

5、永远不迁就业务的一些不合理要求，该做的就是要不折不扣的完成。

6、项目还没开始就要有内部和外部的大概议事规则等，选型时候对项目负责人的预见力和洞察力的要求还是蛮高的。

7、任何项目在选型、选产品、选合作团队的时候，作为甲方负责人我认为最关注的应该是要围绕“如果我来负责这个项目，结合自己在甲方的位置和影响力及个人能力，团队能力，应该如何选择产品和顾问团队，来保障项目成功，并且过程和结果能够较为可控制”。

8、供应商在选型和谈判阶段，为了能够拿到项目，很多条件都可以答应，不合理的价格也可接受，这就为后面的风险埋下了伏笔。建议大家以后一定要在合同中，对乙方团队的人员予以明确约定，并就违约责任约定清楚，这样才能加强对乙方人员的管控。

9、有些企业项目的立项和预算是业务部门主导的，很多项目是业务做好后交给IT运维。项目的立项和实施缺乏全面的统筹，实施过程中企业的IT人员没有很好的跟进和了解系统，系统为了上线又做了大量的客户化开发，后期运维的费用又不足以支撑这些开发导致的继续开发。

10、ERP的失败比ERP的成功更有教益，不管是对自己还是对别人。IT项目的失败其实很普遍，据分析，信息系统失败的概率是70%。这么多年从事信息化，应该说特别失败的案例没有，但每一个项目其实都很不容易，如果没有必胜的信心和执着的坚持，是很难取得成功的。有些项目甚至是经过几年的努力才坚持下来，最后取得一定效果的。

11、公司战略不稳定，公司一直分分合合，业务环境尚不明朗，职权分配都不清楚，信息化项目由此艰难。

12、阶段性成果后，甲方该支付乙方的款项应及时支付，对结果的担心可能造成对双方合作关系的直接伤害。

13、综合分析，得出几大类原因：公司战略不明确；上线时机选择不对；业务需求不明确、人员不配合；供应商不配合，能力差；信息化制度、机制不明确。