一个550多万人口的城市，一款投入巨资建设的政务App，日活跃用户是多少？
60人左右。
这不是段子。
2026年，云南曲靖“曲靖通”引发广泛关注。
公开报道显示，“曲靖通”背后的“城市大脑”项目曾投入巨额资金。央视《焦点访谈》披露，整个项目市财政投入2970万元，地方国企出资1700万元，当地合计投入4670万元。
但截至2025年底，“曲靖通”日活跃用户只有60人左右。
更值得思考的是，它的70多个应用中，只有6个属于自建，其余大量功能实际上是其他应用的链接，其中不少功能与云南省早已建设的“一部手机办事通”重复。
2025年，项目终止运营。
2026年3月，“曲靖通”全面下架，永久停止服务。
这件事当然发生在政务信息化领域。
但如果你在一家稍微大一点的企业干过信息化，你可能会觉得这一幕异常熟悉。
因为很多企业内部，也有自己的“曲靖通”。
按照从左到右，从上到下的顺序依次来说说每幅画的意思：
客户：我家有三个小孩，我须要一个能三个人用的秋千。它是由一绳子吊在我园子里的树上。客户在描述需求时倾向于提供过多的信息。
产品经理：秋千这东西太简单了，秋千就是一块板子，两边用绳子吊起来，挂在树上的两个枝子上。
工程师按照产品经理的要求设计产品。 两个树枝上挂上秋千哪还能荡漾起来吗？除非是把树从中截断再支起来，这样就满足要求了。
程序员：开始写程序。两条绳，一块板，一棵大树，接在树的中段；太简单了，工序完成。
测试人员：收到开发部门的产品进行测试。一根在末端系了个圈的绳子。
销售人员：终于产品完成，销售人员开始向客户推销：通过人体工学，工程力学多方面研究，本着为顾客服务出发，我们的秋千产品让您如同坐着沙发一样舒适。
当需要用到文档的时候，总是找不到。这么小的工程没有文档很正常，只要需求说明书与合同就可以了。
实施人员交付的产品的时候，只要把绳子系在树上就可以了。
客户：花了这么多钱，真的能和过山车相媲美了。
客服解决问题的方法简单粗暴。
市场营销做的广告那是相当的高大上。
瞧！ 客户真正想要的只是一个简单的轮胎秋千。
一、企业里最可怕的系统，不是没建成，而是“成功验收了”
企业信息化项目最荒诞的一幕是什么？
不是项目失败。
而是：
项目成功验收了，但系统不好用。
立项成功。
招标成功。
合同签了。
项目启动会开了。
蓝图规划做了。
需求调研做了。
系统集成做了。
汇报PPT做得非常漂亮。
领导驾驶舱的大屏也亮起来了。
最终验收专家签字了。
尾款付了。
然后半年以后你再去业务部门看看：
Excel又用回来了。
微信群又建起来了。
线下审批单又打印出来了。
原来那个耗资几百万、几千万建设的信息系统，桌面上的快捷方式都不知道被谁删了。
于是一个非常值得追问的问题出现了：
系统到底算成功，还是失败？
按照项目管理流程，它成功了。
按照财务流程，它成功了。
按照验收材料，它也成功了。
但是按照使用效果，它可能已经死了。
这恰恰是很多信息化项目最大的问题：
我们非常擅长验收“有没有建成”，却很少验收“到底有没有人用”。
二、但我更想问：当初选这个产品的人，去哪了？
一个系统用了三年以后不好用，大家第一反应通常是什么？
“让运维看看。”
“是不是服务器有问题？”
“是不是数据库慢？”
“让信息化部门优化一下。”
“找厂家处理一下。”
慢着。
我们先把时间拨回三年前。
当初是谁决定买这个产品的？
为什么选A，没有选B？
有没有做过POC？
有没有真正让一线用户试用？
业务部门有没有参与需求确认？
有没有调查现有系统已经具备哪些能力？
有没有研究集团、上级单位是不是已经有类似平台？
有没有认真算过三年、五年的总拥有成本？
产品功能与实际业务到底匹不匹配？
如果这些事情当年都没有认真做，现在为什么一句“系统不好用”，就全部扔给运维？
这就像买房。
买房的时候，领导拍板、业务提要求、采购谈价格、厂商画效果图。
最后发现户型设计得一塌糊涂。
然后所有人一起找到物业：
“你们物业为什么不能把两室一厅运维成四室两厅？”
物业能怎么办？
给承重墙打补丁吗？
三、还有一个人更应该被找到：当年的业务需求负责人
很多失败的信息化项目有一个共同特点：
系统上线以后，需求负责人神奇地消失了。
项目建设的时候：
“这个必须做！”
“我们业务一定需要！”
“这个流程不能少！”
“这个字段必须保留！”
“领导驾驶舱必须有！”
三年以后：
“这个系统谁提的？”
所有人：
“不知道。”
于是你会发现一种非常奇怪的企业现象。
服务器有负责人。
数据库有负责人。
交换机有负责人。
防火墙有负责人。
甚至机柜里的PDU都有负责人。
唯独一个几千万的信息化项目，当初为什么建设、解决什么问题、业务目标是什么，反而找不到负责人了。
技术资产有主人，业务价值却成了孤儿。
这才是企业信息化最大的管理漏洞之一。
虚假的驾驶舱
四、系统不好用，到底应该问责谁？
这里必须说清楚：
系统失败，当然不能简单找一个人“背锅”。
真正成熟的做法，是沿着项目全生命周期倒查。
第一关：立项
先问：
为什么要建？
当时到底存在什么业务问题？
有没有现有系统可以解决？
有没有通过改造老系统解决的可能？
有没有重复建设？
有没有量化收益指标？
如果连“为什么建”都说不清楚，后面技术做得再漂亮也没有意义。
第二关：产品选型
再问：
为什么买它？
有没有POC？
有没有真实业务场景测试？
评分表是谁制定的？
功能权重是谁确定的？
最终用户有没有参加？
还是厂商演示了一套精心准备的数据，大家看完大屏以后觉得：
“不错，就这个。”
企业买信息系统最危险的一句话就是：
“别人都在用。”
别人能用，不代表你能用。
第三关：需求确认
这是最容易被遗忘的一环。
每一项重大需求，都应该能追溯：
谁提的、为什么提、谁确认、谁批准。
否则几年以后系统里出现一个没人使用的模块，所有人都会说：
“这是当年需求。”
至于是谁的需求？
不知道。
为什么有这个需求？
不知道。
现在还需不需要？
也不知道。
但是服务器必须继续开着。
数据库必须继续备份。
漏洞必须继续修。
账号必须继续管。
等保、审计、日志、安全检查一个都不能少。
一个已经失去业务价值的功能，依然可以持续制造运维成本。
五、最值得查的，其实是“验收”
曲靖这个案例还有一个特别值得企业信息化管理者警惕的细节。
央视报道提到，该项目验收过程中存在专家专业匹配度不足、短时间审阅大量材料等问题。
这恰恰戳中了很多信息化项目的痛点：
我们到底在验什么？
很多项目验收，验的是：
合同功能有没有；
文档齐不齐；
截图有没有；
测试报告有没有；
培训记录有没有；
签字盖章有没有。
这些当然都需要。
但还有几个更重要的问题：
业务人员真的在用吗？
核心流程真的跑通了吗？
性能达到生产要求了吗？
第三方接口真的稳定吗？
数据真的准确吗？
源代码、数据库、接口文档、部署文档、管理员账号真的交了吗？
厂家明天倒闭，我们自己能不能把系统恢复起来？
如果这些东西没有验收，仅仅因为合同里写的120项功能都能点击，就签了字、付了钱，那么项目真正的风险其实才刚刚开始。
六、然后集成商收完钱走了
这可能是很多企业信息化人员最熟悉的一幕。
建设阶段：
项目经理天天在群里。
售前天天来。
技术专家随叫随到。
销售经理隔三差五请大家吃饭。
群消息一分钟不回复，对方电话马上打过来。
等到终验以后：
项目经理换项目了。
技术人员离职了。
销售换区域了。
原厂说这是集成商的问题。
集成商说这是原厂的问题。
软件厂商说这是数据库的问题。
数据库厂商说这是操作系统的问题。
最后所有人的目光缓缓转向甲方运维：
“你们先排查一下吧。”
于是，神奇的事情发生了。
当年几百万元甚至几千万元采购的专业系统，经过一次终验，突然就变成了几个运维人员应该无师自通掌握的东西。
不会？
“你们不是运维吗？”
这句话，值得所有企业的信息化管理者好好琢磨。
七、运维可以兜故障，但不能兜项目失败
这里一定要划清一条线：
运行维护责任，不等于项目成败责任。
服务器宕机，运维应该处理。
磁盘满了，运维应该处理。
数据库异常，按照职责分工处理。
网络中断，应该排障。
证书到期，应该提前预警。
备份失败，应该处理。
这些都没有问题。
但是：
系统流程设计不合理，不应该变成运维责任。
产品选型错误，不应该变成运维责任。
业务部门不用，不应该变成运维责任。
项目重复建设，不应该变成运维责任。
接口架构先天有问题，也不能因为项目经理离职，就自动继承给运维。
更不能出现一种荒诞的逻辑：
建设的时候运维没有决策权，出了问题以后运维拥有无限责任。
权责必须对等。
八、所以企业真正需要的，不只是“交维”，而是“交账”
一个信息系统从项目组移交给运维团队的时候，绝不能一句：
“系统已经上线，以后你们维护。”
然后扔过来一个IP地址、一套账号密码和一本操作手册。
真正应该交接的至少包括：
这个系统为什么建设。
谁是业务Owner。
谁是技术Owner。
谁批准的需求。
谁负责产品选型。
谁进行了验收。
哪些功能仍然在使用。
哪些接口依赖其他系统。
维保什么时候到期。
软件授权什么时候到期。
源代码在哪里。
部署包在哪里。
配置文件在哪里。
数据库如何恢复。
账号密码如何重置。
厂商联系人是谁。
厂商撤场以后谁提供二线、三线支持。
系统发生灾难后如何恢复。
最重要的还有一句：
系统产生不了预期业务价值时，由谁负责？
这句话如果不写清楚，那么几年以后，大概率就是运维负责。
九、不要再把“能运行”当成“建设成功”
一套系统CPU正常、内存正常、数据库正常、端口正常、页面能打开，只能说明：
它还活着。
并不能证明：
它有价值。
信息系统应该有另一套指标。
比如：
月活用户多少？
核心功能使用率多少？
业务线上化率多少？
平均办理时间降低多少？
人工工作量减少多少？
重复录入减少多少？
接口调用量多少？
数据准确率多少？
用户满意度多少？
一年到底创造了多少可以量化的价值？
如果一个耗资千万的系统，最终核心KPI变成：
“全年可用率99.9%。”
那其实很尴尬。
因为一个根本没人用的系统，同样可以做到99.99%的可用率。
甚至更容易。
十、信息化最荒诞的事：成功建设一个没人需要的系统
“曲靖通”真正值得讨论的，并不只是一个App为什么只有60个日活。
公开报道显示，云南省早在2019年已经推出“一部手机办事通”，而后来建设的“曲靖通”70多个应用中仅6个自建，其余大量功能来自其他应用链接。
这提醒所有做企业信息化的人：
技术问题往往是最容易解决的问题。
服务器可以买。
存储可以买。
数据库可以买。
中间件可以买。
大屏可以买。
云平台可以买。
集成商也可以买。
真正买不到的是：
一个企业到底需不需要这套东西。
如果这个问题在立项之前没有回答清楚，那么后面投入的钱越多，沉没成本反而越大。
最后
我一直觉得，评价一个信息化项目，不能只问三个问题：
建没建？
验没验？
钱付没付？
还应该继续往下问：
谁在用？
解决了什么问题？
当初承诺的价值实现了吗？
如果没有实现，当初立项、选型、需求、实施、测试、验收各环节发生了什么？
更重要的是：
当年拍板的人还需要解释吗？
当年确认需求的人还需要复盘吗？
当年签字验收的人还需要承担相应责任吗？
集成商拿完项目款以后，还承担不承担合同约定的服务责任？
如果这些问题最后统统变成一句：
“系统已经转运维了，你们想办法维护吧。”
那么所谓的信息化项目全生命周期管理，就只剩下了前半句话：
建设的时候人人有权，出问题的时候运维兜底。
这不是运维。
这是把项目管理、业务管理、供应商管理和投资决策留下的历史问题，统统塞进了运维的工单系统。
一个真正成熟的企业，应该做到：
谁立项，谁说明价值；
谁提需求，谁确认结果；
谁选型，谁解释依据；
谁实施，谁保证质量；
谁验收，谁对验收结论负责；
谁运营，谁持续评价价值；
谁运维，谁只承担边界清晰的运行保障责任。
系统可以下线。
项目可以失败。
技术路线也允许走弯路。
真正不能接受的是——
几千万花完了，系统没人用了，项目组散了，集成商走了，当年参与决策的人也换岗位了。
最后留下一台服务器。
还有一个运维人员。
领导问他：
“这个系统怎么这么难用？”
他看了看系统的立项时间。
那一年，
他甚至还没来这家公司。