好，这一篇我们直接承接上一篇，做一个更容易引发共鸣、评论区会吵起来的选题。

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

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

项目失败复盘会上。

业务部门说：

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

领导说：

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

IT部门沉默。

供应商解释了一堆技术细节，但没有人认真听。

最后结论很简单：

这个项目，是IT的问题。

这几乎是所有企业信息化项目失败后的“标准结局”。

但问题是：

这真的是事实吗？

二、IT为什么总是“背锅侠”？

如果你在企业里待得够久，会发现一个规律：

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

为什么？

不是因为IT一定做错了，而是因为：

1. IT是“系统的拥有者”

系统出了问题，第一反应一定是：

“IT没做好”

但现实是：

系统只是结果
问题往往在前面

2. IT是“最容易被评价的部门”

业务可以说：

“需求我们提了”
“配合我们也做了”

但IT的交付是可见的：

系统能不能用
页面好不好
速度快不快

可见，就意味着容易被批评

3. IT通常没有“决策权”

很多项目里：

决策是领导拍的
流程是业务定的
时间是上层压的

IT真正能决定的，其实很少。

但结果出了问题：

IT却要承担结果责任

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

我们来把一个典型信息化项目拆开看：

🧩 1. 决策层（战略问题）

为什么做这个项目？
目标是什么？
成功标准是什么？

如果这里错了，项目一定失败

🧩 2. 业务部门（需求问题）

提的需求是否合理？
是否愿意改变流程？
是否深度参与项目？

如果业务不变，系统一定失败

🧩 3. IT部门（实现问题）

架构是否合理？
实现是否稳定？
是否具备交付能力？

IT只是“最后一环”

🧩 4. 供应商（执行问题）

是否理解业务？
是否有经验？
是否负责？

结论很明确：

项目失败，很少是单点问题，而是“系统性失败”

但现实中却变成：

系统性问题 → IT单点背锅

四、几个你一定见过的“经典错位”

❌ 错位一：业务不改变，却要求系统提升效率

现实：

原有流程混乱
多人手工干预
规则不统一

但要求：

“系统上线后要提升效率”

结果：

系统只是把混乱数字化了。

❌ 错位二：目标模糊，却要求IT保证成功

项目目标常见表达：

提升管理水平
实现数字化
提高效率

这些都是“正确的废话”

IT无法交付这种目标。

❌ 错位三：时间被压死，却要求质量完美

现实：

6个月上线
中间不断加需求

结果：

IT只能“做一个能跑的系统”

然后被评价：

“系统不够好”

❌ 错位四：业务参与不足，却要求系统好用

业务常见行为：

不参与设计
不做测试
上线才提意见

结果：

系统上线后：

“不好用”

五、IT真正的问题在哪里？

说到这里，也不能替IT“洗白”。

IT确实也有问题，但问题通常在：

1. 过度技术导向

关注：

架构
技术选型
系统设计

忽视：

业务本质

2. 不敢挑战业务

很多IT：

接需求就做
不质疑合理性

结果：

做了一堆“无效功能”

3. 缺乏项目话语权

没有建立：

项目机制
决策规则

导致：

被动执行

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

给你几个非常现实的建议：

✔ 1. 把项目定义为“业务项目”，不是IT项目

项目负责人必须是：

业务负责人

而不是IT。

✔ 2. 明确责任结构（非常关键）

项目启动时必须明确：

角色	责任
领导	目标与决策
业务	需求与流程
IT	系统实现
供应商	执行交付

写清楚，而不是默认

✔ 3. 强制业务深度参与

例如：

需求必须业务签字
UAT必须业务主导
上线必须业务确认

✔ 4. 建立“问题导向机制”

不是问：

系统做什么

而是问：

解决什么问题

七、企业实践建议

如果你在企业中，可以尝试推动：

✔ 建立项目RACI机制

谁负责（Responsible）谁决策（Accountable）谁参与（Consulted）谁知情（Informed）

让责任透明

✔ 引入“业务KPI绑定项目结果”

例如：

项目失败 → 业务也承担责任

避免“只评价IT”

✔ 项目复盘必须“跨部门”

不是IT复盘，而是：

项目复盘

八、写在最后

很多企业的信息化项目失败后，总会问：

“IT哪里做错了？”

但真正应该问的是：

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

IT不是万能的，也不是问题的根源。

它只是：

企业决策、业务逻辑、管理方式的“放大器”

如果企业本身是混乱的：

IT只会让这种混乱更明显

如果企业本身是清晰的：

IT才能真正创造价值

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