信息化项目立项审计，到底在审什么？

很多人一听到“项目审计”，第一反应往往是：

项目已经做完了，看看钱花得合不合理；合同执行完了，看看有没有多付；系统验收了，再查一查有没有问题。

但信息化项目还有一些审计、评审工作，发生得更早。

系统可能还没开发，设备还没采购，甚至一分钱都还没有真正花出去，对项目的审查就已经开始了。

那么问题来了：

项目都还没开始，到底有什么可审的？

实际上，信息化项目很多后期问题，源头恰恰不在实施和验收，而是在项目立项时，就已经埋下了。

01 所谓“立项审计”，首先不是审钱花到哪了

这里所说的“立项审计”，并不是说全国所有信息化项目都存在一个名称完全统一、程序完全一致的“立项审计”环节。

不同地区、不同类型项目，可能体现为项目审批审查、预算评审、事前绩效评估、专项审计或者全过程跟踪审计中的前期审查。

但它们关注的核心问题其实很接近：

这个项目为什么要建？

准备建什么？

现有建设范围合理吗？

准备花的钱，与建设内容匹不匹配？

项目建成以后，能不能真正产生预期效果？

《国家政务信息化项目建设管理办法》建立了从项目建议书、可行性研究报告到初步设计方案和投资概算的项目管理机制，并明确强调政务信息化建设应坚持统筹规划、共建共享、业务协同、注重实效。

财政部现行《预算评审管理暂行办法》则进一步明确，预算评审要重点关注项目的必要性、可行性、完整性、合规性、合理性、经济性以及绩效目标和支出标准；其中可行性审核还包括项目预算规模与计划方案、目标任务是否匹配。

所以，从这个角度看：

立项阶段真正要审的，不是一张审批表有没有盖章，而是这项投资从一开始能不能站得住。

02 为什么信息化项目尤其值得在前面多问几句？

因为信息化项目有一个很明显的特点：

立项时，很多准备花钱购买的东西，还没有完全“长出来”。

买一台服务器，至少还可以看到处理器、内存、存储容量等参数。

但建设一套定制软件，立项材料里可能只有几句话：

“建设综合业务管理平台。”

“实现跨部门数据共享。”

“提升智能分析能力。”

“建设统一管理驾驶舱。”

这些表述可以说明建设方向，但距离真正能够设计、采购、造价和验收的内容，还差得很远。

“实现数据共享”，到底共享哪些数据？

从哪里获取？

提供给谁？

要建设新的共享平台，还是调用已有平台接口？

“建设智能分析”，又具体分析什么业务？多少指标？需要什么数据和算力？

如果这些问题还没有进一步说清楚，那么另一个问题就会随之而来：

建设内容还比较模糊，几百万元甚至几千万元的投资规模，是怎么确定出来的？

这也是信息化项目立项阶段特别值得关注的地方。

财政部《预算评审管理暂行办法》已经明确要求，项目内容范围、目标任务、规模标准应当清晰，项目预算规模还要与计划方案、目标任务相匹配。

换句话说：

需求深度和预算精度，至少应该基本匹配。

如果需求还停留在“建设一个什么平台”的层面，预算却已经精确到几十万元甚至几万元，后面的数字看起来越精确，反而越值得问一句：

这个数字下面，到底有什么东西在支撑？

03 立项阶段真正值得审的，其实是四件事

如果不站在审计人员的专业检查表角度，而是站在建设单位的角度来看，立项阶段真正需要说清楚的，无非四件事。

第一件：为什么一定要建？

有政策鼓励数字化、智能化，并不等于每一个具体系统都天然具有建设必要性。

真正应该回答的是：

现在业务到底存在什么问题？

影响了哪些部门、人员或者服务对象？

原有系统为什么解决不了？

是确实需要新建，还是升级原来的系统就可以解决？

其他部门、上级单位已有的平台和数据能力，能不能直接复用？

2025年，无锡市审计局在信息系统建设使用审计中，就把项目规划合理性和立项必要性放在前端关注，重点排查重复建设、过度建设以及“数据烟囱”等问题。

所以，必要性论证真正要避免的是：

因为“想做一个系统”，就直接跳到了“申请一笔建设资金”。

中间至少还应该回答一句：

为什么现有条件解决不了，必须再投入财政资金建设新的东西？

第二件：到底准备建什么？

必要性说清楚以后，还要继续把建设目标往下拆。

例如“提升审批效率”，最后可能对应流程优化、材料电子化、系统接口、消息提醒等具体功能。

“实现数据共享”，则应该继续明确数据来源、共享对象、数据范围、接口方式以及已有能力是否可以复用。

否则，同一句“数据共享”，有人理解的是几个接口开发，也有人可能理解成重新建设一整套数据平台。

这也是为什么立项材料不能只有宏观建设目标。

目标解决的是“为什么做”，需求解决的是“具体做什么”。

后面还有一个更重要的问题：

这些需求将来怎么验收？

如果立项时写的是“提升智能化水平”“加强数据赋能”，到了项目验收阶段，同样很难判断：

到底做到什么程度才算完成？

所以，立项阶段把建设边界说清楚，不只是为了算钱，也是为了给后面的采购、实施和验收留下一把真正能用的尺子。

第三件：这些东西真的需要这么多钱吗？

这是立项审查与信息化造价联系最紧密的地方。

项目预算合理不合理，并不是拿总投资和其他项目简单比较：

“别人做这个系统花了500万元，我们只报400万元，应该不贵。”

真正应该形成的是一条对应关系：

建设需求 → 建设规模 → 费用。

比如采购100台终端，是因为多少人员、多少点位存在实际需求；

申请20TB存储资源，要能够对应现有数据规模、年度增长量和保存周期；

购买成品软件，要说明授权数量、期限和部署范围；

定制开发软件，则应进一步落实到具体业务功能和软件规模。

财政部现行预算评审制度本身也要求关注预算需求是否合理、支出标准是否适用，并审核项目预算规模与目标任务、实施方案之间的匹配关系。

对于已经具备一定需求深度的定制软件项目，还可以进一步通过功能规模开展成本测算。

实际工作中，也可以借助软件造价喵辅助梳理功能清单、识别功能点和开展费用测算，结合平台沉淀的10年行业基准数据及70余项国家、行业、省市级软件和信息化项目造价标准，让“准备建设什么”和“准备花多少钱”之间形成更加清晰、可复核的对应关系。

这里最重要的，并不是立项审查一定要把预算压下来。

而是让主要费用都能够回答：

为什么需要花这笔钱？依据是什么？

第四件：建成以后到底有什么用？

这其实是立项阶段最容易被忽略的一问。

一个项目可能建设理由很充分，方案写得也很完整，预算也有测算依据。

但最后还要回答：

花完这笔钱，究竟准备改变什么？

是审批时间减少？

人工操作减少？

数据重复填报减少？

系统覆盖多少用户？

原来线下办理的业务，有多少转到线上？

还是原有多个系统整合以后，减少了一批重复建设和运维费用？

《中共中央 国务院关于全面实施预算绩效管理的意见》明确要求，对重大政策和项目开展事前绩效评估，重点论证立项必要性、投入经济性、绩效目标合理性和实施方案可行性等内容。

当初为什么要建设这些功能？预计谁来使用？使用频率是多少？建成后通过什么指标判断有效？

很多问题，其实在立项的时候就值得先问。

04 为什么越早审，反而越容易发现并解决问题？

立项阶段增加审查，有时容易给人一种感觉：

项目才刚准备建设，就开始提问题，会不会只是多增加了一道程序？

其实恰恰相反。

很多问题越早发现，处理成本越低。

需求阶段发现一个功能没有必要，可能只是删掉几页方案；

投资测算阶段发现服务器配置明显偏高，还可以重新调整；

立项论证时发现已有系统完全可以复用，甚至可以重新选择建设路径。

但同样的问题，如果等到采购以后再发现，就可能需要修改采购需求；

合同已经签订以后发现，就可能涉及合同变更；

到了验收时才发现某个功能实际上没人使用，能调整的空间就更小了。

所以，立项阶段的审查真正的价值，不是把项目“卡住”。

而是：

把原本可能两三年以后才暴露的问题，尽可能提前到还没有真正花钱的时候解决。

05 对建设单位来说，立项前不妨先回答四句话

其实，不必等到专家评审、财政评审或者后续审计，项目单位自己就可以先做一次简单检查。

第一，现状究竟有什么问题？

不是“信息化水平有待提升”，而是具体哪项业务做得慢、哪里重复填报、哪些数据无法共享。

第二，这次具体准备解决哪些问题？

每个主要建设内容，都应该能够往前找到一个现实需求。

第三，为什么需要这么大的建设规模和投资？

主要软硬件数量、软件功能规模、数据量、接口量以及服务内容，都应该能够逐步找到相应依据。

第四，项目建成以后，用什么证明这些钱没有白花？

最终要看的，不只是“系统上线了没有”，而是立项时准备解决的问题有没有真正发生变化。

如果这四句话能够说清楚，后面的需求、方案、预算和绩效目标通常也更容易形成对应关系。

反过来，如果一个项目只能反复解释：

“政策要求建设。”

“数字化转型需要。”

“其他地方也在做。”

却说不清现实问题、具体需求、建设规模和预期效果，那么这个项目或许还需要再往前多走一步论证。

结语

信息化项目立项阶段的审计和评审，面对的并不是一个已经完成、只能回头找问题的项目。

恰恰相反。

它面对的是一个还有机会改变的项目。

这个阶段最重要的，不是发现了多少问题，也不是最终把预算审减了多少。

而是在真正投入资金以前，把几个最基础的问题弄明白：

为什么要建？

究竟建什么？

为什么需要花这些钱？

最后准备产生什么效果？

真正有价值的立项审查，不是为了证明：

“这个项目能不能通过。”

而是为了在项目真正开始之前，尽可能先回答另一件更重要的事：

既然决定要花这笔钱，我们能不能把它花在真正需要的地方。