一、一块大屏，和一个被问住的讲解员

某次去一个城市的排水调度中心参观。大屏确实气派，整面墙，三维城市转着圈，管网流光溢彩，液位流量水质貌似一屏打尽。陪同的领导很自豪，讲解员很熟练，一套词下来行云流水。

有专家多嘴问了一句：昨天夜里城东那个溢流告警，后来工单派给谁了？闭环没有？

讲解员愣了一下，说老师您稍等，我查查另一个系统。

专家又问：巡检路线是大屏上这套系统排的，还是养护队按老经验排的？这回陪同的领导替她答了："养护还是按老规矩来，系统这套目前还再在调试中，暂时先是给参观看的。"

几千万建起来的平台，日常业务用不上，日常工作靠的仍是电话、微信群和老师傅的记性。大屏很亮，决策靠猜，中间隔着一整套没人用的系统。

二、把问题说透：平台为什么用不起来

这些年这样的中心建了几十上百个，其实毛病的根子却惊人地一致，归纳起来就两条。

第一条，为展示而建，不是为干活而建。立项时对标的是"领导来看了什么"，功能清单照着汇报场景写。三维建模要炫酷，界面要大气，至于告警出来谁接、工单怎么流转、巡什么修什么由谁来定，没人认真想过。建设方的合同里写的是"平台建成验收"，不是"业务跑通验收"。

第二条，业务和数据两张皮。平台建在一个部门，干活在另一个部门。养护队不看系统，系统也不懂养护；调度中心的大屏一轮播，底下的班组一天跑几趟现场，全凭班组长安排。时间久了，两边互相嫌弃，平台沦为接待窗口。

这两条叠加，出来的结果就是行业里那句自嘲：平台是给领导看的，活儿还是老办法干的。

说句公道话，这不完全是甲方的错。前些年"智慧城市"风口大，只要PPT做的够炫，大屏幕够大、够亮、够好看，上平台本身就是成绩，用不用得起来反而没人考核。风过去了，账还在那儿。

三、国标怎么说：应用决策，本来就是数字化的落脚点

很多人把数字化平台理解成"建系统、买大屏"，其实 GB/T 47884-2026《城镇排水管网数字化通用技术要求》把这件事的轻重缓急写得很明白，也要纠正这种不对的说法。

先复习一下标准的总体架构：数据采集、数据治理与建模、应用决策三块。前面几期聊的都是前两块，采什么、怎么管、怎么建模。但架构的终点是应用决策，也就是说，前面所有投入，最后都要在日常业务里兑现，否则就是半截子工程。

第 4 章总体要求还立了两条规矩。一条是数字化建设应编制专项规划，并与智慧城市建设相结合，意思是不能脑袋一热就立项，先想清楚干什么、跟谁衔接。另一条是应与市政、气象、交通、水利、环境等业务共享数据，平台不是哪个部门的私产，建的时候就要想着开放出去。

到了第 10 章应用决策，标准把"平台要干什么活"直接列了出来，几条都跟那天问住讲解员的问题对得上。

10.2 条讲日常业务管理，核心是两个词：形成运维闭环，巡检养护频次动态调整。闭环的意思是，从发现问题到派单、处置、复核，整条链条在系统里走得通、留得下痕迹。频次动态调整的意思是，哪段管网该多巡、哪段可以少巡，由运行数据说话，不是十年一贯制地撒胡椒面。

10.4 条讲运行分析，要求对液位、流量、水质、设备问题开展诊断，其中明列了雨污混接、外水入侵和偷排。这三样，恰恰是日常最容易"靠猜"的决策：溢流了猜是雨太大，浓度低了猜是河水倒灌，某个排水户排口不对劲，猜是夜间偷排。标准的态度很直接：别猜，用定量数据诊断。

10.5 条讲预警预报与工单联动。阈值怎么设，告警来了怎么自动触发工单，预报信息在系统界面显著位置高亮显示，还要能通过自动广播、电话、手机短信同步发出去。注意这条的细节——告警不是在大屏上闪一下红就算完事，是要推着人干活的。

还有一条容易被忽略。第 8 章数据使用部分提出，治理后的数据宜发布为数据服务，供第三方调用共享。这句话分量很重：数据不是平台墙上的装饰画，是可以开放出去的服务。第一步是内部先都用起来，数据只有使用才能改善，才能准确，才能真正发挥价值。下一步是共享给其他相关部门来实现真正的智慧城市，气象部门要你的液位数据做内涝预警，环保部门要你的排口数据查偷排，城市规划要你的管网易涝点做改造依据——给得出、调得动，才叫数字化。当然，上面的过程也需要循序渐进的推动，首先需要把高质量数据养出来。

四、怎么干：让平台嵌进日常业务的四件事

标准画的是框架，落到管理上，有四件事要先做扎实。

第一件，验收标准从"建成"改成"跑通"。以后开发平台，要求：上线三个月内，随机抽十个真实告警，查它们的工单流转和闭环记录。跑得通才算验收过。这一条要求写进去，建设方的设计思路立刻就变了，因为糊弄不过去了。

第二件，让干活的人参与定功能。功能清单不要只开汇报会定，把养护班组长、调度员、化验员拉进来，问他们一天里哪些决策最耗时间、最容易出错。他们的答案，就是平台最该先做的功能。曾经见过一个单位的做法很实在：平台第一版只做三件事，告警派单、巡检路线、台账导出。土得掉渣，但班组天天用，用了才有第二期的持续和改进。

第三件，巡检频次让数据说了算。把监测数据分区分级，高水位频繁冒溢的片区加密巡，长期平稳的片区降下来。省下来的人力投到问题片区去。这不靠觉悟，靠 10.2 条说的"动态调整"写进管理制度，每季度调一次，调完留档。

第四件，把数据服务当业务来经营。数据资源目录建起来，对内对外都清楚有什么数、怎么申请、谁负责。别小看这件事，它决定你的平台是一个部门的家当，还是整个城市排水治理的公共底座。

这里插一句监测端的老话。诊断、预警、动态调整，全都压在数据上。前端监测稀烂，10.2、10.4、10.5 全是空转。平台好不好用，一半功夫其实在井里，不在屏上。这也是前面几期反复唠叨布点和数据质量的原因。那一关没过，这一期说的一切都是白搭。

五、清环能搭把手的地方

清环做排水数字化，走的是监测、诊断到提质增效的全链条，平台在我们手里从来不是单独卖的软件产品，定制化的功能也不是我们的开发目标，我们只做最核心的监测诊断系统，它是诊断服务的操作台。所以我们对"能用、实用、管用"有明确的要求。参观当然也能看，但那是顺带的功能，不是设计的出发点，让相关人员每天能方便打开系统看数据才是我们开发这个软件的目的。

六、收尾：平台是用来干活的

要想把平台盘活，往往不是推倒重建，而是把已有平台的告警和工单打通，把监测数据接进诊断模型，把巡检频次从"拍脑袋"改成按数据调。盘活之后，大屏还在，三维还在转，但班组终于肯打开使用它了，讲解员也换了一套词介绍：上周多少告警、多少闭环、闭环平均多少小时，巡检路线这个月调了哪几段。数字都不亮眼，甚至有点琐碎。但是这些比三维城市好看多了，数字化技术真正融入了业务管理过程。

排水数字化到头来是个朴素的道理：系统存在的意义，是让干活的人少跑冤枉路、少做冤枉判断。领导参观时能不能转出一朵花来，真的不重要。

下一期，聊个和01闭环的话题：督察再上门，台账怎么交？日常业务里那些记录、报告、闭环凭证，怎么在督察面前变成你的底气而不是漏洞。咱们下期见。