一个4670万元的ZF项目，是怎样一步步走向失败的？

央视《焦点访谈》8月26日报道了云南曲靖“城市大脑”和“曲靖通”App项目的情况。

其中有两个数字很容易让人记住：曲靖市常住人口550多万，而截至2025年底，“曲靖通”App的日活跃用户只有60人；60和4670万放在一起，当然很有新闻冲击力。但如果只是把这件事归结为“投资浪费”“重复建设”或者“zheng务App没人用”，其实低估了这个案例的价值。

因为从数字化转型的角度看，它真正值得研究的地方，不是一个App为什么没人使用，而是一个看起来目标正确、概念先进、有方案、有供应商、有预算、有验收甚至还有持续运营费用的数字化项目，为什么last会走到这一步。

如果把整个过程重新串起来，会发现一个很值得管理者警惕的现象：

数字化项目很少突然失败。真正的失败，往往从项目还没有启动的时候就已经开始了。

而且每一步，看起来可能都有自己的理由。

项目真正的起点，不应该是“我们要建什么”。---数字化

报道里有一段话，比“日活60人”更值得数字化从业者认真看。

曲靖市委chang委、副shi长吴以华在接受采访时谈到，当时看到杭州“城市大脑”给城市治理带来了很大效果，“大家都看到了它的好，但没看到我们自身能力的差距”，并进一步反思这里存在科学决策方面的薄弱环节。

这其实已经触及了很多数字化项目initial的认知偏差。数字化建设非常容易从“别人已经有什么”开始，而不是从“我们究竟存在什么问题”开始。

看到其他城市建设城市大脑，于是开始讨论自己的城市大脑；看到同行建设数据中台，于是研究自己的数据中台；现在看到很多企业部署大模型、建设智能体，又开始讨论自己的AI Agent平台。

这种决策逻辑危险的地方，不是学习先进经验。企业当然应该学习先进经验。真正的问题在于，我们很容易把别人解决问题之后形成的“答案”，误认为是自己问题的“起点”。

杭州为什么需要城市大脑，它当时面对什么治理问题，积累了什么数据，形成了怎样的组织协同机制，具备什么技术能力，这些条件共同决定了那个方案为什么在那里成立。

换一个城市，条件变了，问题变了，治理能力变了，同样的答案未必仍然成立。

企业数字化转型也是如此。值得复制的，从来不是别人last建成的那个系统。

值得复制的是别人如何发现问题、判断价值、选择优先级以及持续验证的过程。

这一区别看似简单，却决定了项目后面的所有事情。

如果从问题出发，组织会不断追问：“它究竟解决了什么？”

如果从方案出发，组织更容易不断追问：“它究竟建完了没有？”

两种不同的问题，finally会把项目带向完全不同的方向。

当“城市大脑”成为目标，真实需求反而容易退到后面---数字化

报道中另一个细节，把这个问题表现得非常具体。

“曲靖通”2021年投入使用，七十多个应用中只有六个是自建，其余大量功能实际上是其他应用程序的链接，其中不少来自云南省已经建设的“一部手机办事通”。而省级平台早在2019年就已经推出，在曲靖实名注册用户约190万人，累计办件量约2154万件。

如果把“建设一个城市App”作为项目目标，这个项目完全可以成立。

可以设计界面，可以开发功能，可以接入服务，可以上线应用，可以完成验收。

但如果把问题换成：曲靖市民还缺少什么数字化公共服务？

项目逻辑可能从一开始就会发生变化。

因为此时首先需要回答的，不是App应该有什么功能，而是已有省级平台解决了什么、没有解决什么；市级平台究竟有什么不可替代的价值；市民为什么需要增加一个新的入口；哪些服务必须由本地建设才能获得明显改善。

报道里市民的一句话其实已经给出了朴素的产品评价：“除了给孩子上小学报名，平时这个App几乎没有任何用处。”

这不是简单的“推广没有做好”。

如果一个拥有550多万常住人口的城市，一款面向公众的zheng务Appfinally只有约60人的日活，那么首先应该怀疑的不是宣传力度，而是产品存在的理由。

数字化产品真正的生命力，从来不是功能数量，而是使用价值。

用户不会因为ZF建了一个App就产生一个新的需求，也不会因为企业建设了一个数字平台，就主动改变自己的工作习惯。

一个系统必须进入真实的业务过程，解决一个过去解决不了、解决不好或者解决成本过高的问题，它才有持续存在的理由。

这也是为什么我一直认为，数字化项目极需要警惕的一种错觉就是：

“系统上线”被误认为“数字化发生了”。

系统上线只是一个技术事实。

只有当人的行为、业务过程或者组织决策因此发生变化，数字化才能真正发生。

更值得警惕的是，错误的需求会制造出“正确”的方案---数字化

报道显示，由于自身不具备相应技术能力，当地把相关技术论证和方案的主导交给了外部企业。随后形成的是一个相当完整的“大而全”方案，其中包括数据库、数据能力中心、数字驾驶舱、“曲靖通”和“一网统管”等内容。

站在项目建设角度，这种方案并不奇怪。甲方希望建设“城市大脑”，供应商自然会回答：一个完整的城市大脑应该包含什么。

于是数据库应该有，数据平台应该有，驾驶舱应该有，移动端应该有，城市运行管理服务平台也应该有。架构会越来越完整，方案会越来越专业，投资测算也会越来越具体。

问题在于，这时候讨论的已经悄悄从：“曲靖究竟需要解决哪些问题？”变成了：“一个城市大脑应该长什么样？”这可能是整个项目重中之重的转折点。

数字化项目中有一种很隐蔽的风险：方案本身可能没有错，但它回答了一个错误的问题。

供应商有能力设计技术架构，却无法替代甲方完成价值判断。

企业可以外包开发，可以采购平台，可以购买咨询服务，甚至可以把大量运营工作交给专业机构，但有一项能力永远不能真正外包：

定义自己为什么要做这件事情。

因为只有甲方自己知道什么问题值得解决，什么结果值得投入，什么变化对业务真正重要。

如果甲方自己不能回答这些问题，外部供应商finally只能用自己熟悉的产品、技术和解决方案替甲方回答。

last得到的往往不是一个坏方案。恰恰相反，它甚至可能是一份非常漂亮的方案。只是它与真实问题之间，没有建立足够牢固的联系。

到这里，项目其实已经开始从“创造价值”滑向“完成建设”---数字化

接下来发生的事情，就更加值得数字化项目管理者反思。

央视报道提到，“城市大脑”建成以后，“曲靖通”使用情况不理想；“一网统管”原计划覆盖城市运行管理、环保、综合治理、应急管理、卫生教育等十余个领域，希望通过数字化解决跨部门、跨层级复杂问题，但实际很多工作仍停留在展示层面。

这里有一个词特别值得注意：展示。

数字化项目很容易产生的一种错觉，就是“可展示”与“可使用”之间的混淆。

驾驶舱能够展示多少指标，地图能够呈现多少图层，大屏能够汇聚多少数据，这些都很直观。领导参观的时候也容易看到。

但真正困难的问题通常藏在大屏后面。

数据是谁产生的？准确不准确？出现问题谁负责？不同部门是否愿意共享？指标发生异常以后有没有人采取行动？跨部门事项由谁协调？原来的业务流程有没有因为平台发生改变？

如果这些问题没有解决，大屏只是把原来的管理问题可视化了。

看见问题，并不等于解决问题。

数字化转型真正困难的部分，从来不是把现实世界搬到屏幕上，而是借助数字技术重新组织现实世界里的业务活动。

这就是为什么有些数字化项目看起来完成度很高，却始终无法进入日常经营和管理。

技术系统建起来了，组织运行方式没有改变，数字化finally停留在了技术层面。

真正让人警觉的，是项目后面的验收方式---数字化

报道披露，三年来的项目验收资料平均每年都有五六本，总页数超过千页。以2024年为例，专家组成立到完成验收总共120分钟。报道还提到，当时参与验收的相关人员介绍，主要是对照方案中的建设内容，看相应内容“建了没有”，建了就通过。

这种验收思路并不限于zheng务项目。很多企业数字化项目至今仍然按照类似方式管理：

需求有没有实现，功能有没有上线，接口有没有打通，文档有没有提交，培训有没有完成。这些当然都需要检查。

问题是，这些只能证明供应商完成了约定的工作，并不能证明企业完成了数字化转型。

管理学里经常区分两个概念：Output是产出，Outcome是结果。

建成一个App，是Output，市民因此更加方便地办理公共事务，才是Outcome。

建成一个数据平台，是Output，数据真正进入经营决策并改善决策质量，才是Outcome。

部署一个AI系统，是Output，它真正缩短业务周期、提高服务质量或者降低运营成本，才是Outcome。

如果一个数字化项目从立项、合同到验收，管理的始终都是Output，那么供应商理性的行为当然就是完成Output。

一个组织用什么标准验收项目，实际上就是在告诉所有参与者：什么才是这个项目真正重要的东西。

如果“有没有人使用”不是验收的重要内容，项目建设过程中就很难真正围绕用户展开。

如果“有没有解决问题”不是付款的重要依据，供应商自然更关心功能是否交付。

如果“有没有产生价值”从来没有被量化，价值finally就会成为项目总结材料里的一句话。

所以，数字化项目极需要改变的，也许并不是验收流程，而是验收对象：

我们究竟是在验收一个系统，还是在验收一次业务改变？

zhong极问题，是我们仍然习惯用“工程建设”去理解数字化---数字化

报道还显示，项目运营效果与预期存在明显差距，但按照合同约定，项目验收以后，根据年度考核结果支付运营服务费，2022年至2024年每年支付990万元。后来在整改过程中，合作方认为现有费用不足以继续开展更多整改；在运营效果不佳的情况下，当地finally决定停止支付运营费用，项目随之终止，“曲靖通”也在2026年3月quan面下架。

从这段过程里可以看到一个非常典型的矛盾。

我们已经进入数字时代，但很多组织仍然用工业时代的工程项目思维管理数字产品。

立项→建设→交付→验收。

在传统工程项目中，这套逻辑非常成熟。桥修好了，楼建好了，工程基本完成。

但数字产品不是这样。

一个App上线的时候，不是项目价值实现的终点，恰恰只是产品接受真实用户检验的开始。

用户会不会使用，功能是否符合实际场景，流程是否需要调整，数据是否可靠，体验是否需要改善，都只能在运营中不断验证。

因此，真正的数字化能力不是“把系统建出来”，而是围绕业务结果持续运营和持续改进的能力。

这也是很多数字化项目为什么di1年轰轰烈烈，第二年勉强维持，第三年逐渐沉寂。系统留下来了，却没有人真正对它持续创造价值负责。

所以，4670万元究竟是什么时候开始“打水漂”的？---数字化

如果一定要找一个时间点，我认为不是2026年3月App下架的时候，甚至不是2025年决定终止运营的时候。真正的问题可能在更早的时候就已经形成了。

当“别人有城市大脑”开始替代“我们有什么问题”的时候，di1次偏离发生了。

当“建设一个完整平台”开始替代“解决几个高价值场景”的时候，第二次偏离发生了。

当甲方无法清晰定义业务价值，只能依赖外部力量定义方案的时候，项目进一步失去了方向控制。

当项目验收开始主要关注“建了没有”，而不是“用了没有、改变了没有”的时候，建设完成与价值实现正式分开。

等到日活只剩60人，问题其实已经不需要分析了，60只是结果。

真正导致这个结果的，是前面一系列管理决策共同构成的因果链。

这也是为什么数字化转型失败不能简单归因于“技术选错了”“供应商能力不行”或者“用户不愿意使用”。

大量数字化项目的失败，本质上首先是管理失败，然后才表现为技术投资失败。

数字化转型真正需要治理的，是“做正确的事”---数字化

企业谈数字化治理时，很容易把注意力放到数据安全、架构标准、项目审批、技术规范这些内容上。

这些当然属于治理。

但治理还有一个更上游、更重要的责任：

确保组织把有限的资源投入到值得数字化的事情上。

技术管理更多解决“怎样把事情做正确”。治理首先要回答“我们是不是在做正确的事情”。这是两个完全不同的问题。

如果方向正确，项目管理、架构、开发、运营可以帮助企业不断把事情做好。如果方向本身错误，越专业的执行有时反而意味着越高效地把错误变成现实。

所以我并不认为这个案例值得总结的经验是“以后要做好需求调研”。这还是太技术化了。

真正应该建立的是一套贯穿数字化投资全过程的价值治理机制：在投资之前能够质疑需求，在建设过程中能够验证假设，在运营过程中能够观察价值，在事实证明原来的判断不成立时，也能够及时调整甚至停止。

停止一个不再创造价值的项目，本身也是一种数字化能力。

成熟不是永远做对。成熟是组织能够尽早发现自己做错了，并且付得起纠正错误的成本。

写在last：数字化比较大的风险，从来不是技术落后---数字化

报道last把这类项目称为“数字盆景”，我觉得这个词非常准确。报道同时援引当地反思，指出不能再只重建设、不重实际用户需求，应当更多关注真正的强需求。“数字盆景”极为麻烦的地方，不是它不好看。恰恰是因为它很好看。

有平台，有大屏，有数据，有App，有概念，有架构，汇报的时候每一样东西都说得过去。

only的问题是：它没有真正成为业务的一部分。

一个真正成功的数字化产品，last往往会变得非常普通。

员工每天使用它，客户自然地通过它完成业务，管理者依据它的数据进行判断。没有人天天讨论“数字化转型”，因为数字化已经进入了组织正常运行的肌理。

反过来，一个项目如果长期需要依靠宣传、行政推动、考核甚至不断追加投资才能证明自己存在的价值，就应该重新审视：究竟是用户还没有适应这个产品，还是这个产品本身就没有解决一个足够重要的问题。

所以，如果一定要从曲靖这个案例里留下一句话，我更愿意留下的不是“数字化不能重复建设”，也不是“数字化必须重视需求”。而是

数字化转型极为重要的能力，不是知道什么新技术应该上，而是知道企业究竟为什么要用它。

因为AI正在把数字化建设的门槛降得越来越低。做一个应用越来越容易，开发一个Agent越来越容易，搭建一个平台也越来越容易。

当“能不能做”越来越不成问题以后，“为什么做”就会成为真正稀缺的管理能力。

技术不断扩大企业能够做什么的边界，而治理决定企业finally选择做什么。

曲靖这个案例真正值得我们警醒的，也正在这里。

数字安全 关注安言