信息化项目失败，真的是IT的问题吗？

一、一个再熟悉不过的场景

项目失败复盘会上，业务部门说：

“这个系统根本不好用。”

领导说：

“IT这次项目做得不行。”

IT部门沉默，供应商解释了很多技术细节，但没有多少人真正关心。

最后结论很简单：这个项目，是IT的问题。

这几乎是很多企业信息化项目失败后的标准结局。系统是IT负责的，项目是IT推进的，出了问题，自然由IT背锅。

但问题是，这真的是事实吗？

二、IT为什么总是背锅？

信息化项目一旦出问题，责任往往默认属于IT。

首先，IT是系统的直接拥有者。系统打不开、流程跑不通、页面不好用，最容易被看到的对象就是IT。

其次，IT的交付结果最可见。业务部门的需求是否合理、流程是否清晰、配合是否充分，不一定容易被量化；但系统能不能用，一眼就能看出来。

再次，IT通常没有真正的决策权。项目目标是领导定的，流程规则是业务定的，时间节点是上面压的，供应商是采购流程定的，但最后承担结果压力的往往是IT。

这就形成了一个很典型的错位：决策权分散在各处，责任却集中在IT身上。

三、项目失败的真正责任结构

一个信息化项目，至少包含四类责任。

第一类是决策层责任

项目为什么做，目标是什么，优先级是什么，成功标准是什么，这些不是IT能够单独决定的。

第二类是业务责任

需求是否合理，流程是否清晰，是否愿意改变原有做法，是否深度参与测试和上线，这些直接决定项目是否能落地。

第三类是IT责任

系统架构是否合理，集成是否稳定，权限是否安全，数据是否可靠，这些是IT必须承担的专业责任。

第四类是供应商责任

是否理解业务，是否具备实施经验，是否按约定交付，是否真正负责解决问题。

项目失败，通常不是单点失败，而是系统性失败。但现实中，系统性失败很容易被简化为IT失败。

四、几个典型错位

1. 业务不改变，却要求系统提升效率

原有流程混乱，规则不统一，岗位职责不清晰，却希望系统上线后自动提升效率。这种期待本身就不现实。

系统不能凭空创造管理能力。它只能把已有的规则固化，把清晰的流程自动化，把明确的数据结构化。

如果企业自身混乱，系统往往只会让混乱更加明显。

2. 目标模糊，却要求IT保证成功

很多项目的目标写得很宏大，比如提升管理水平、推动数字化转型、加强协同能力。

这些话都正确，但无法交付。

IT需要的是具体目标，例如审批周期缩短多少、库存准确率提升多少、预算执行偏差控制在什么范围。没有可衡量目标，项目成功就没有标准。

3. 时间被压死，却要求质量完美

项目计划被压缩到极限，中间还不断增加需求，最后却要求上线质量完美。

这本质上是对项目规律的忽视。时间、范围、质量三者之间一定存在约束关系，不能同时无限要求。

4. 业务参与不足，却要求系统好用

一些项目中，业务只在需求阶段简单参与，上线前才集中提出问题。

系统好不好用，不是IT关起门来能设计出来的，而是业务和IT共同打磨出来的。

五、IT自身也确实有问题

不能因为IT经常背锅，就认为IT没有责任。

很多IT团队的问题在于过度技术导向，关注架构、系统、工具，却没有真正理解业务场景。

也有些IT团队不敢挑战业务，业务提什么就做什么，最后做出一堆功能，却没有解决真正问题。

还有一些IT团队缺少项目话语权，没有建立需求评审、范围控制、变更管理等机制，导致自己长期处于被动状态。

六、如何打破IT背锅困局？

第一，把信息化项目定义为业务项目，而不是IT项目

项目可以由IT组织实施，但业务负责人必须承担结果责任。

第二，明确责任结构

项目启动时，要把领导、业务、IT、供应商的责任写清楚，而不是靠默认理解。

第三，强制业务深度参与

需求确认、流程设计、测试验收、上线推广，都必须有业务部门参与和签字。

第四，建立问题导向机制

不要只讨论系统做什么，而要反复确认系统要解决什么问题。

七、企业实践建议

可以建立RACI责任矩阵，明确谁负责执行、谁拥有最终责任、谁需要参与、谁只需要知情。

可以把项目结果与业务KPI绑定，避免项目失败后只评价IT。

项目复盘也不应该是IT复盘，而应该是跨部门复盘。只有这样，企业才能真正看到问题全貌。

八、写在最后

信息化项目失败后，最容易问的问题是：IT哪里做错了？

但更应该问的是：

这个项目的责任结构是不是从一开始就错了？

IT不是万能的，也不是企业所有管理问题的根源。IT更像一面镜子，会把企业的流程、规则、权责和管理水平照出来。

如果企业本身混乱，系统只会让混乱更明显；如果企业本身清晰，系统才可能真正创造价值。

信息化项目失败，从来不是一个部门的问题，而是一家企业管理能力的真实映射。

2. 信息化项目失败，真的是IT的问题吗？