7. 信息化项目的正确打开方式：不是立项，而是“问题定义”

一、很多项目从第一步就走偏了

企业启动信息化项目时，常见动作是立项、做预算、找供应商、排计划、收需求。

这些动作看起来很专业，也符合管理流程。

但问题在于，它们都默认一个前提：项目要解决的问题已经清楚了。

现实往往不是这样。很多项目在立项时，问题并没有被真正定义，只是有一个模糊方向，比如提升效率、加强管控、推动数字化、建设统一平台。

这些方向并不错误，但太抽象，无法直接转化为项目目标。

二、为什么立项不是项目真正的起点？

立项只是管理动作，不是认知动作。

它解决的是项目有没有资格启动、预算能不能安排、资源能不能投入的问题。

但它不一定解决项目为什么做、解决什么、做到什么程度的问题。

如果没有问题定义，立项越快，风险越大。

很多项目的失败，不是因为没有立项，而是因为立项之前没有把问题讲清楚。

三、问题定义到底是什么？

问题定义不是写一段背景介绍，也不是列一堆需求。

真正的问题定义，至少要回答四个问题。

第一，当前发生了什么问题？

第二，这个问题影响了哪些业务结果？

第三，这个问题的根因是什么？

第四，项目成功后，现状应该发生什么变化？

只有回答这些问题，项目才有清晰起点。

四、没有问题定义会带来什么后果？

首先，需求会变得无限发散。

因为没有核心问题，所有需求都看起来合理。每个部门都能提出自己的诉求，项目范围会越来越大。

其次，优先级无法判断。

当所有事情都重要时，就等于没有优先级。项目团队不知道应该先解决什么，也不知道哪些需求可以延后。

再次，验收标准会模糊。

如果项目目标只是“提升管理水平”，上线后很难判断是否成功。最后只能用“系统上线”代替“项目成功”。

五、问题定义应该如何做？

第一，从业务结果出发。

不要一开始就讨论功能，而要讨论结果。例如订单处理周期过长、库存准确率低、预算执行偏差大、数据口径不一致。

第二，识别问题根因。

同样是效率低，可能是流程问题，也可能是数据问题、职责问题、系统问题。根因不同，解决方案完全不同。

第三，定义目标状态。

目标状态不是功能清单，而是项目完成后业务应该如何运行。

第四，形成项目假设。

明确项目通过什么路径解决问题，例如流程重构、数据治理、系统集成、权限重建等。

六、企业实践建议

企业可以在立项前增加一个“问题定义评审”。

评审重点不是系统方案，而是问题是否真实、影响是否明确、目标是否可衡量、责任是否清晰。

也可以建立问题定义模板，包括业务背景、问题描述、影响范围、根因分析、目标状态、成功指标和关键约束。

对于重大项目，可以先做小范围诊断，而不是直接进入实施。

---

七、写在最后

信息化项目最危险的地方，不是没有计划，而是带着错误的问题开始计划。

立项只是形式，问题定义才是起点。

如果问题定义清楚，后面的需求、范围、计划和验收才有依据。

如果问题定义模糊，项目越往后走，偏差越大。

项目真正的第一步，不是立项，而是把问题讲清楚。