立项论证回答的是“为什么建、建什么”，招标采购解决的是“由谁建、怎么建”。项目通过验收后，从程序上看，建设任务似乎已经告一段落。

但对信息化项目而言，系统交付并不意味着项目目标已经实现。

审计署《2026年第1号公告：中央部门单位2025年度预算执行等情况审计结果》披露，有的信息系统建成后停用超过3年，有的已建成子系统功能迟迟未投入使用，有的48个应用软件月均使用均不足1次，还有部分单位在自助办税设备使用需求下降后，仍继续新增配置或支付不必要的运维费用。

如果仅从技术层面分析，原因可能涉及需求调研、功能设计、系统运维和推广使用等多个方面。但进一步来看，这些问题还有一个共同特征：项目在建设阶段形成了较为完整的管理链条，进入运营阶段后，绩效目标的跟踪、运行责任的承接以及使用效果的评价，却未必能够同步延续。

换句话说，部分“建而不用”问题，表面上反映的是系统使用不足，背后可能是：

项目完成了建设闭环，却没有顺利接上运营阶段的绩效闭环。

01

PART

“建而不用”，不只是系统闲置

从审计情况看，“建而不用”既包括系统建成后长期停用，也包括部分功能未投入使用、软件低频运行、系统功能不完善，以及需求下降后仍继续建设或支付运维费用等情形。

这些问题表现不同，但都说明项目已经形成建设产出，实际应用和预期效益却未能同步实现。因此，“建而不用”不宜只作为技术或运维问题来看，还需要放到项目全生命周期绩效管理中进一步审视。

02

PART

制度延伸到运营期，为何仍会断档？

THE BROKEN PERFORMANCE CHAIN

现行制度并没有把项目验收作为绩效管理的终点。

《国家政务信息化项目建设管理办法》要求，项目备案时明确绩效目标和指标，建设期内评价目标执行情况；项目验收并投入运行后12至24个月内开展自评价，并将评价结果作为后续投资和运维经费安排的重要依据。

《关于开展国家电子政务工程项目绩效评价工作的意见》也提出，评价不仅要看项目是否建成，还要关注政务效能贡献、业务信息化推动、业务应用持续发展和信息系统能力适配性；对能够采集数据的指标，原则上尽量采用定量分析。

从制度设计看，一条完整的绩效链条已经比较清晰：

立项时设定目标，建设中跟踪目标，运行后评价效果，再根据评价结果调整后续投入。

问题可能并不在于缺少制度，而在于这条链条从建设阶段转入运营阶段时，目标、责任和数据未能有效衔接。

03

PART

项目验收后，绩效链条断在哪里？

01 / 03目标断裂：立项时讲效益，建设时管功能

信息化项目在立项阶段，通常会提出提高工作效率、促进数据共享、强化业务协同、提升服务能力等目标。

进入建设阶段后，这些目标需要转化为系统模块、功能点、数据接口和软硬件配置。项目管理的重点，也会逐步落到进度、投资、质量和合同履约上。

这种转化是项目落地的必要过程。但如果建设内容与原定绩效目标之间缺少持续对应，就容易出现一种偏差：立项时关注的是“项目建成后能够带来什么变化”，建设和验收时关注的却主要是“完成了多少功能”。

例如，项目提出“提高审批效率”，验收时可以检查审批模块是否交付；实际效果则需要结合办理时长、退回次数和线下补充材料等情况判断。

如果绩效目标没有进一步转化为运营期可观察、可验证的指标，较容易核验的功能、接口和设备数量，就可能逐渐替代较难即时衡量的业务成效。

此外，绩效目标也不能一经确定便长期不变。此次审计发现，在电子税务局及相关平台已经推广，且自助办税设备需求下降的情况下，部分单位仍继续购置设备或支付运维费用。

这表明，建设周期较长、业务环境变化较快的项目，还需要定期复核原有目标和投入安排是否仍符合实际需要。项目管理不仅要关注原计划是否按期执行，也要适时判断原计划是否仍有继续执行的必要。

02 / 03责任断裂：系统有人维护，应用成效由谁负责？

信息化项目建设期间，责任分工通常较为清晰：建设单位组织实施，承建单位负责开发交付，监理单位监督进度和质量，测试测评机构完成相关检测等。

项目通过验收后，承建单位可能进入质保或运维阶段，监理任务结束，项目专班也可能随之调整。此时，系统“能不能正常运行”一般有人负责，但系统“有没有真正发挥作用”由谁持续关注，有时还需要进一步明确。

技术运维责任与运营绩效责任并不完全相同。

技术运维更多关注系统是否可访问、故障是否及时处理、数据是否备份、安全是否稳定；运营绩效则需要持续了解业务部门是否实际使用、核心功能是否进入工作流程、原有工作方式是否得到改善，以及立项时设定的效益是否逐步实现。

一个子系统长期未投入使用，可能源于功能、数据、权限或制度条件，也可能是需求已经变化。系统未必发生技术故障，却需要有人分析原因并提出处置意见。

因此，系统从建设转入运营时，可以在技术运维责任之外，进一步明确业务应用和绩效管理责任：谁负责推动业务迁移，谁负责协调数据和流程，谁负责分析使用情况，谁负责组织后评价，谁根据评价结果提出优化、整合或退出建议。

建设责任阶段性完成，并不意味着绩效实现责任可以同步退出。只有责任得到承接，系统才可能从“按要求交付”继续走向“持续发挥作用”。

03 / 03数据断裂：有运行数据，没有绩效依据

信息化项目有一个明显特点：系统运行本身会持续产生数据。

用户登录、功能调用、业务办结、接口访问、异常失败等信息，都可以为绩效评价提供基础。此次审计能够发现48个应用软件月均使用均不足1次，也说明使用情况具有统计条件。

但运行数据客观存在，并不意味着已经形成有效的绩效监测机制。

登录次数只能说明用户进入过系统，不能证明业务已经通过系统完成；数据量持续增长，也未必意味着减少了重复填报；某项功能调用较少，既可能是功能利用不足，也可能是对应业务本身发生频率较低。

只有将运行数据与项目目标、业务场景和评价标准结合起来，才能判断核心功能是否进入业务流程、线下流程是否得到替代，以及效率和成本是否发生变化。

因此，所谓数据断裂，并不一定是系统没有数据，而是数据仍停留在系统日志、运维报告或供应商后台，尚未转化为绩效监控、原因分析和管理决策的依据。

对不同类型的系统，可以分层设置指标：先看目标用户是否采用，再看核心功能是否使用，继而判断业务是否完成，最后评价效率、成本和服务效果。这样有助于避免单纯以登录量、数据量评价系统绩效，也有助于更早识别低效使用及其原因。

04

PART

从“建成了”到“用起来”

从绩效管理的角度，可以在三个关键节点采取相应措施，推动项目从“建成了”走向“用起来”。

NODE 01建设期：绩效目标要“可衡量”

立项阶段就要设定清晰、可量化的绩效目标。《国家政务信息化项目建设管理办法》要求备案文件应当包括“绩效目标及绩效指标”。《政府投资项目可行性研究报告编写通用大纲（2023年版）》也将“绩效目标”列为可行性研究报告的必备内容。绩效目标应当是具体、可验证的——例如某项业务的办理时间缩短多少、某项数据的查询效率提升至什么水平——而非“提升管理效率”这类笼统表述。

绩效目标确定后，应当贯穿建设全过程，作为设计、开发、测试的参照。如果在建设过程中发现原定目标不现实或已发生变化，应当及时提出调整申请，按规定程序报批。

绩效目标要真正落到项目建设中，还有一个重要前提：建设内容本身需要拆得清、算得明。

在实际编制和评审过程中，需求材料常常存在表述口径不一、功能边界不清、测算依据较为分散等情况。针对这类问题，可以借助软件造价喵等专业工具，对需求材料进行功能拆解和功能点识别，结合相应造价标准与行业基准数据，形成较为清晰的功能清单、测算明细和评估成果。

这不仅有助于提高预算编制和造价评审效率，也能够为后续需求变更、合同履约和验收核对保留一套相对明确的建设基线。

NODE 02验收期：不仅验“功能”，还要验“目标”

验收时不仅要看系统功能是否实现，还要对照立项时的绩效目标逐一核查。目标达成了多少？未达成的部分是什么原因？后续如何改进？这些问题应当在验收报告中有所体现。

竣工验收并不意味着绩效管理的结束。《国家政务信息化项目建设管理办法》（国办发〔2019〕57号）要求备案文件应当包括“绩效目标及绩效指标”，并在运维环节对绩效目标的实现情况进行跟踪和评价。这意味着验收阶段需要对绩效目标的达成情况做出初步判断，为后续的运营期评价奠定基础。

NODE 03运营期：建立“用起来”的保障机制

系统上线只是起点，持续的运营才是关键。需要从以下几个方面建立保障机制：

明确运营责任。谁负责日常运维、谁负责数据更新、谁负责用户支持——这些应当在项目建设阶段就明确下来，并纳入相关岗位的职责范围。

保障运营经费。《国家政务信息化项目建设管理办法》要求“加强国家政务信息化项目建设投资和运行维护经费协同联动”。建设期和运营期的经费应当统筹考虑，避免“建得起、用不起”的情况。

建立使用情况监测机制。通过技术手段定期采集系统使用数据——登录次数、功能使用频率、用户活跃度等——作为运营管理的依据。公安部所属道路交通安全研究中心48个应用软件月均使用不足1次的情况，如果有日常的使用监测，问题可能在更早的阶段就能被发现。

定期开展后评价。按照《关于开展国家电子政务工程项目绩效评价工作的意见》（发改高技〔2015〕200号）的要求，项目投入运行后12至24个月内，项目单位应开展绩效自评价，重点评估项目建设目标达成情况和实际应用效果。评价结果与后续预算安排、项目审批挂钩。绩效评价的作用，不只是形成一份报告，更重要的是为下一步资源配置提供依据。系统“好不好”需要回答，但更需要回答的是：后续预算和运维资源应当如何安排。因此，“盘活”不等于对所有低效系统继续追加投入——评价结果应当成为资源优化配置的依据，而非简单维持现状的理由。

结语

信息化项目通过验收，意味着从规划设计到建设交付的任务基本完成，但系统能否真正进入业务、持续稳定运行并实现预期目标，还需要在运营阶段接受检验。

从此次审计披露的问题看，“建而不用”不仅涉及系统功能和运维，也反映出项目建设与运营之间的绩效管理衔接问题。

推动信息化项目从“建成了”走向“用起来”，可以把绩效管理贯穿到项目全生命周期：立项时明确应用目标，建设中关注需求和落地条件，验收时衔接运营评价，并让评价结果影响后续预算、运维、整合和退出决策。

系统建成，不是绩效管理的终点。对于信息化项目而言，它更像是实际应用效果开始接受检验的起点。