1. 为什么90%的信息化项目一开始就注定失败？

一、一个真实的项目现场

某集团启动ERP项目。

立项会上，领导拍板：“这个项目必须在6个月内上线，这是集团今年最重要的工作。”

业务部门说：“系统一定要符合现在的流程，不能影响业务。”

IT部门说：“会全力配合供应商推进。”

供应商说：“没问题，这类项目做过很多。”

一切看起来都很正常。目标有了，团队有了，供应商有了，计划也有了。

但半年后，项目延期了三次，需求增加了一倍，用户开始抵触，数据一团混乱，最终系统上线了，却很少有人真正使用。

这个项目没有在文件里被定义为失败，但所有参与者都知道，它已经失去了原本的意义。

二、问题到底出在哪里？

项目失败后，企业往往会习惯性归因：供应商不行，IT能力不足，业务不配合，项目经理协调能力弱。

这些原因都可能存在，但如果看过足够多信息化项目，会发现一个更残酷的事实：大多数项目不是做坏的，而是一开始就错了。

错的不是某一个功能，不是某一段代码，也不是某一次会议，而是项目启动时的底层认知。

很多企业还没有想清楚为什么做，就已经开始讨论怎么做；还没有定义问题，就已经开始选择系统；还没有统一目标，就已经安排上线时间。

在这样的起点下，后面的所有努力都只是补救。

三、信息化项目的三大先天缺陷

1. 把系统建设当成目标

很多企业启动信息化项目，第一反应是选系统、找厂商、定预算、排计划。

但真正应该先问的是：企业到底要解决什么问题？

如果问题没有定义清楚，系统越先进，越可能成为新的负担。系统只是工具，不是目标。没有问题导向的信息化项目，最终很容易变成一场软件采购。

2. 把现状流程当成合理流程

业务部门常说：“系统要按照现在的流程来。”

但现实是，很多现状流程本身就不合理，只是长期运行下来形成了惯性。

信息化不是简单地把线下流程搬到线上，而是一次流程显性化、标准化、结构化的过程。如果流程本身混乱，系统只会把混乱固化下来。

3. 把项目当成IT任务

信息化项目表面上是系统建设，本质上是业务变革。

如果项目被定义为IT任务，就会出现一种常见局面：IT在前面推，业务在旁边看；IT在解释需求，业务在评价结果；IT承担压力，业务保留意见。

这类项目即使上线，也很难真正改变业务。

四、为什么这些问题必然发生？

因为很多企业的信息化项目启动方式是错误的。

典型路径是：领导提出目标，IT开始选型，业务提供需求，供应商进场实施，项目按计划推进。

这个路径最大的问题，是缺少“问题定义”环节。

正确的启动逻辑应该是：先明确核心问题，再识别业务矛盾，然后设计目标状态，最后再决定是否需要系统、需要什么系统、如何分阶段建设。

很多项目的失败，本质上是还没有想清楚“为什么做”，就已经进入了“怎么做”。

五、项目失败的经典信号

如果一个项目出现以下迹象，通常说明风险已经很高。

需求永远在变，说明项目目标和边界没有真正确定。

计划不断调整，说明项目缺少稳定的前提条件。

会议越来越多，说明沟通正在替代决策。

用户参与度越来越低，说明业务并没有真正认同项目。

上线前大家都在凑合，说明项目已经从“创造价值”变成了“完成任务”。

六、如何避免先天失败？

第一，项目开始前不要急着谈系统。

先回答三个问题：当前最大的问题是什么？这个问题影响了什么？不解决的代价是什么？

第二，强制做目标状态设计。

不要一上来就收集需求，而是先讨论未来流程应该是什么样。需求是现状的表达，目标状态才是变革的方向。

第三，项目负责人必须来自业务。

IT可以负责技术实现，但不能替业务承担业务变革责任。没有业务负责人真正牵头，项目很容易变成IT独角戏。

七、企业实践建议

企业可以建立项目启动评审机制。任何信息化项目立项前，都必须回答：为什么做？不做会怎样？成功标准是什么？由谁负责业务结果？

可以用问题导向文档替代传统需求文档。文档重点不只是功能列表，而是问题描述、业务影响、目标状态和解决路径。

项目KPI也不应只看是否上线，而要看业务效果，例如效率是否提升、数据是否改善、流程是否规范、管理是否可控。

---

八、写在最后

很多人以为信息化项目失败是能力问题，但更深层的原因往往是认知问题。

项目不是从开发开始，也不是从采购开始，而是从理解问题开始。

如果起点错了，方法再好也很难弥补；如果方向错了，团队越努力，偏离越严重。

项目的成败，不是在上线那一天决定的，而是在立项那一刻就已经埋下了伏笔。