“明年有一笔信息化预算，大概500万元。”“那我们看看500万元能做些什么。”

有些信息化项目，从一开始就有一个很奇怪的顺序。

于是，原本应该先回答的“为什么要建、要解决什么问题、到底需要哪些功能”，慢慢变成了另一个问题：

怎么把这500万元安排进去？

这并不只是一个假设场景。

重庆市关于2020年度市级预算执行和其他财政收支的审计工作报告曾指出，政务信息化项目的预算安排和投资管控衔接不够，部分新建项目先按照信息化项目清单限额安排年初预算，但可研、初设及概算批复较晚。截至当年年底，60个项目仍未启动，5.2亿元预算资金未使用。

2024年，深圳市审计局公布的一项专项审计调查也发现，多个信息化项目立项前未进行可行性分析或研究论证不充分，4家企业的7个项目未编制详细的分项概算；与此同时，部分已建项目存在功能模块未使用，甚至系统上线后一直闲置的情况。2025年南京市审计公布的网络安全和信息化建设专项审计中，也发现部分系统功能模块闲置或停用、项目建设进度慢和预算执行率低等问题。

这些问题不能简单归结为“预算编得不准”。

如果需求还没有成熟，预算却先被确定下来，后面的需求、方案、采购和验收，很容易都开始围着这个数字转。

01

预算为什么会跑到需求前面？

信息化项目有一个现实矛盾。

预算有预算的时间表，项目有项目的成熟过程。

为了申报下一年度预算，建设单位往往需要提前提出项目和资金需求。但此时业务调研可能刚开始，系统到底建设到什么范围、哪些旧系统可以复用、具体功能有哪些，还没有完全说清楚。

于是，为了“先把项目报上去”，很容易先形成一个项目名称、一段建设目标，再给出一个大致投资规模。

这本身并不一定有问题。立项阶段的投资估算，本来就不可能和最终合同价一样精确。

问题出在下一步：原本只是一个“初步资金判断”，后来却变成了一个需要被努力用完的“固定盘子”。需求开始围绕预算展开。

这也是立项审计中特别值得关注的一类问题。很多项目任务书并不是完全没有需求，而是“目标写得很完整，具体功能却很粗”。知道要建设“综合管理平台”“数据分析能力”“智能决策模块”，却很难进一步回答到底有多少业务流程、哪些用户使用、形成哪些具体功能。

这时，如果预算已经精确到几百万元甚至几千万元，就会出现一个很尴尬的问题：

需求只能说明“准备干什么”，预算却已经精确地告诉别人“准备花多少钱”。

两者的成熟度明显不匹配。

02

预算一旦成了“锚点”，需求就容易发生三种变化

第一种，是把“必要需求”变成“预算容量”。

假设项目初步安排了500万元。真正梳理下来，核心需求也许只需要建设十几个模块。但如果大家潜意识里认为“500万元已经批了，不用完以后不好解释”，就很容易继续增加大屏、移动端、驾驶舱、数据分析、智能推荐等内容。

这些功能未必完全没用。问题是，它们究竟来源于真实业务需求，还是因为预算还有空间？两者看起来都写进了《需求规格说明书》，性质却完全不同。

第二种，是让设计单位或者供应商反过来“填满方案”。

建设单位自身缺乏信息化设计能力时，让专业单位协助梳理需求很正常。但如果对方一开始就知道“项目大概有800万元预算”，需求调研就可能天然受到这个数字影响。

方案不再只是回答“业务需要什么”，还会不自觉地回答“这个预算能放进去什么”。最后可能出现一种很微妙的结果：方案看起来非常完整，每一笔预算也都找到了对应建设内容，但这些建设内容是不是业务真正需要的，反而没人再往前追问。

第三种，是实施阶段不断发生变更。

前期需求没有真正说清楚，系统开始开发以后，真实用户才逐渐参与进来。“这个流程实际不是这么走的”“这里还缺一个审批环节”“这个报表业务部门根本不用”“原来已有系统其实能提供这项能力”——于是不断调整功能、修改接口、重新测试，甚至影响工期和合同价款。

《第3205号内部审计实务指南——信息系统审计》在总结信息系统项目风险时也特别提到，需求分析不当，可能导致系统应用价值不高；需求说明书缺乏业务主管部门确认，后期需求不断变更，又可能带来项目成本增加和延期风险。

所以，很多实施阶段的“需求变更太多”，根并不一定在实施阶段。它可能在立项时就已经埋下了：钱先基本定了，需求却还没有真正成熟。

03

信息化预算，本来就不应该一开始“算得特别准”

这里容易走向另一个极端：既然需求还不成熟，是不是立项阶段就不能编预算？当然不是。

信息化项目从概念到落地，本来就应该经历一个逐步深化的过程。

《国家政务信息化项目建设管理办法》将项目建议书、可行性研究报告、初步设计方案等作为项目审批的重要环节，并要求建设单位按照批复的初步设计方案和投资概算实施；初步设计方案和投资概算未获批复前，原则上不下达项目建设投资。

不少地方的信息化项目管理办法也把需求分析放在项目申报之前或要求同步深化。一些地区还要求先梳理业务需求清单、系统功能清单，再申报项目建设方案和投资概算。

这背后的逻辑其实很简单：预算应该随着需求和设计逐步变清楚，而不是第一天就假装自己已经很精确。

项目刚提出时，可以先判断资金量级；需求调研完成后，再根据业务范围、功能规模、数据量、接口数量、软硬件资源等重新测算；等到初步设计和建设内容进一步明确，再形成更细的概算和控制依据。

前期允许“估”，但后面必须不断用更具体的需求和方案去校正这个“估”。

最怕的不是第一次估得不够准，而是第一次报了500万元，后面所有材料都开始证明“这个项目就应该值500万元”。

04

对建设单位来说，最重要的是把“需求—规模—费用”连起来

建设单位并不需要自己学会每一种造价方法。真正需要建立的是一条简单的逻辑链：每一笔钱，都应该能够向前找到对应的需求。

比如，采购100台终端，是因为多少用户、多少点位需要使用；新增20TB存储，是因为现有数据量、年度增长量和保存周期支持这个规模；开发一套软件，则应该能够落到具体业务流程、用户角色和功能清单。

对于定制软件，这一点尤其重要。“建设综合管理平台，实现信息查询、统计分析和协同管理”这样的描述，可以说明建设方向，却很难直接支撑一个精确的软件开发预算。

只有进一步拆成用户能够识别的业务功能，才能比较合理地判断软件规模和开发成本。

实际工作中，在需求已经具备一定深度后，可以借助软件造价喵这类工具辅助梳理功能清单、开展功能点识别和费用测算。平台沉淀了10年行业基准数据，并整合70余项国家、行业及省市级软件和信息化项目造价标准，可以帮助建设单位把相对抽象的需求进一步转化为可量化、可复核的规模依据。

05

立项阶段，不妨做三次“反向检查”

对于建设单位来说，要避免“预算先定、需求后凑”，其实不需要增加一套特别复杂的管理流程。在项目正式申报或者送审前，可以做三次反向检查。

第一次，从预算里抽一笔钱，往前追需求。

例如软件开发费300万元。能不能说清楚对应哪些系统、哪些模块、哪些核心业务流程？如果只能找到“平台建设费”几个字，这笔预算的基础还不够扎实。

第二次，从需求里随机抽一项，往后追成本。

例如提出“建设智能分析功能”。它需要新增软件开发、购买成品软件，还是调用现有平台能力？需要什么数据、算力和接口？如果需求写得很大，却完全找不到对应成本，也说明方案可能还停留在概念层面。

第三次，把“必须建设”和“可以优化”分开。

哪些内容不做，项目核心目标就无法实现？哪些属于体验优化、能力提升或者后续可以分阶段建设？把这两类需求分开，它的价值不是为了简单砍预算，而是让建设单位知道：预算变化时，究竟应该调整哪些建设内容，而不是让所有功能一起跟着一个总金额伸缩。

财政部在推进全面预算绩效管理时强调，要将绩效关口前移，对重大政策和项目开展事前绩效评估，防止“拍脑袋决策”，从源头提高预算编制的科学性和精准性。

信息化项目尤其需要这一点。因为软件不像一栋已经画好施工图的房子，需求稍微变化一点，后面的设计、开发、测试、接口和运维都可能跟着变化。

越是在立项阶段把需求和资金之间的关系说清楚，后面越少需要靠变更去“补课”。

写在最后

预算先定，再反过来凑需求，看起来只是立项阶段的顺序问题，但它很可能一路影响到后面的方案设计、采购报价、项目实施、需求变更和最终验收。

对于建设单位来说，真正值得追求的并不是“项目申报时就把价格算得一分不差”，而是保证预算每深入一层，都能找到更具体的需求和建设依据来支撑。

需求越清楚，预算才应该越精确。而不是预算越精确，需求就越要想办法往里面填。

说到底：

预算不是一个等着需求去填满的盒子。它应该是需求被逐步说清楚以后，用金额表达出来的建设边界。