第14章 痛点、瓶颈与风险

本章导读

本章是全书唯一集中写问题的一章，也是第 15 章路径设计的前提。前十三章沿业务链条说明了 GIS 能做什么，本章做一次诚实的反向盘点：把技术能力之外的约束按数据、标准、模型、系统、组织与人才、投入与效益、安全与合规、技术与工程八个方面逐项拆开。每一节都落到具体的数据项、流程节点与岗位职责——账图物三套账及其处置优先级（表14-1）、编码与口径冲突（表14-2）、率定与模型资产化、烟囱建设与供应商锁定、数据责任人与考核缺位、全生命周期预算、分类分级与国产化适配、三维性能与工程实施；14.9 节把这些互为因果的痛点收束到制度、机制、技术、能力四层根因（表14-3）。读完后你应当能把本单位最痛的三件事准确归因到某一层，并分辨该动的是制度还是工具。

学习目标

读完本章，你应当能够：

• 说出数据之痛的六种面貌（底数不清、精度不足、更新滞后、多源异构、拓扑断裂、数据孤岛），指出哪一种最容易被上线初期的“数据导入”掩盖；
• 解释平面、高程、属性三重精度缺口分别对应“找得到”“算得准”“敢不敢用”哪一类业务失效，并各举本章一个例子；
• 对照表14-2 辨析管线长度统计与漏损率、产销差率两处口径冲突，说明口径不一致为什么会诱使基层选择性报数；
• 复述模型之痛的五个环节（率定、参数、算力、业务嵌入、资产化），判断本单位最可能卡在哪一环及其后果；
• 列出系统之痛的三种表现及其对使用率的连锁影响，说明“建设逻辑”与“运行逻辑”为什么必然冲突；
• 把八类痛点归入制度、机制、技术、能力四层根因（表14-3），并解释只做技术投入为何会导致“系统越建越多、数据越用越少”。

前十三章沿着供水、排水、污水、水环境、工程建设、调度应急与客户服务等业务链条，梳理了地理信息系统（GIS）在水务行业落地的基本图景。一个基本判断是：技术能力已不是主要约束，真正决定成败的是数据是否可信、标准是否统一、模型是否可用、系统是否协同、组织是否支撑。本章把这些约束逐项拆开，按数据、标准、模型、系统、组织与人才、投入与效益、安全与合规、技术与工程八个方面归纳痛点的具体表现、业务后果与形成机理，并在末尾做制度、机制、技术、能力四层根因分析。拆解不做笼统归因，而是对照具体的数据项、流程节点与岗位职责，让每一个判断都能在业务现场找到对应。写“痛”不是为了罗列问题，而是因为第十五章的路径设计必须建立在诚实的问题诊断之上——绕开痛点的路线图，最终都会回到原点。

14.1 数据之痛

GIS 的第一性原理是“位置即索引”：只有当每一个阀门、每一段管道、每一个排放口都能被唯一、准确、及时地定位，空间分析才有意义。数据之痛因此不是“数据太少”，而是“数据不可信、不可用、不可持续”。前者可以靠采购和普查解决，后者只能靠治理。实践中，数据问题通常以三种面貌出现：账、图、物三套账对不上；精度与完整性达不到业务门槛；更新机制缺失导致成果逐年衰减。三种面貌之下，还叠加着多源异构、坐标与高程不统一、拓扑断裂、数据孤岛等结构性问题。

14.1.1 底数不清：账、图、物三套账

固定资产台账按“项”管理，设备运行台账按“台”管理，GIS 按“段”和“点”管理，三种粒度、三套编码，彼此没有稳定的映射关系。财务关心原值与折旧，运行关心状态与检修，GIS 关心位置与连通，三者各说各话。一次完整的管网资产盘点，往往要同时核对财务卡片、设备台账、竣工资料和现场情况，工作量远超预期。

底数不清的直接后果发生在抢修现场。队伍按图找阀门，到场发现阀门井被路面覆盖、井位偏移数米，或者图上标注的阀门实际是消火栓；关阀方案按图推演，关完之后仍有来水，原因是存在一条未登记的连通管或私接管线。停水范围因此扩大，抢修时长被拉长，投诉随之上升。分区计量同样受影响：DMA（独立计量区）的边界阀门如果与图上不符，夜间最小流量（MNF）的读数就无法代表真实漏损水平，产销差核算也就失去基准。

造成底数不清的原因并不神秘。建设期按批次、按标段录入，一条道路下的多条管线被压缩成一条示意线；临时管线、迁改管线、代建管线缺少登记入口；报废管线没有注销流程，长期以“僵尸管”形态留在图层中；不同年代的普查成果叠加使用，同一管段存在两个版本。这些问题在系统上线初期被“数据导入”掩盖，运行两三年后集中暴露。

14.1.2 精度不足：平面、高程、属性三重缺口

精度不是一个测绘概念，而是业务可用性的门槛。平面精度决定“找得到找不到”：竣工测量成果与示意性上图的差异，在图上可能只是几毫米，在现场可能是整条车道。排水管线在综合管网图中常以示意方式表达，检查井位置按路侧估算，一旦发生冒溢，排查起点就会偏。

高程精度决定“算得准算不准”。给水管网缺少埋深与管顶高程，开挖方案、阴极保护评估、冬季防冻分析都只能凭经验；排水管网缺少管底高程与井底高程，重力流方向无法推算，内涝模型只能靠反复试参数凑结果，积水点的模拟位置与实际长期对不上。河道断面若用数字正射影像（DOM）和数字表面模型（DSM）粗略提取，滩地与护岸的高程误差会直接传导到洪水演进结果。

属性精度决定“敢不敢用”。管径、管材、敷设年代三项缺失，爆管风险模型就没有训练样本；阀门型号、开启方向、是否可带压操作缺失，抢修方案无法自动生成；排放口类型、汇水范围、是否设截流设施缺失，污染溯源就只能在图上“连线条”。很多单位把普查重点放在几何采集上，属性字段留空率很高，最终形成“图很漂亮、账算不清”的局面。

14.1.3 更新滞后：竣工数据不回流

工程竣工验收的资料包通常包括竣工图、管线点成果表、材质证明、试压与闭水试验记录。这些资料进了档案室，却没有按数据规则进入空间数据库。原因有三：一是合同里没有“数据交付”条款，施工单位只负责交图纸；二是竣工验收没有把“数据入库确认”设为前置条件；三是设计与施工单位使用的坐标、编码、图层命名与运维单位不一致，即使入库也要二次转换。

更新的滞后是渐进的，也最容易被忽视。新建道路下的管线要等到下一次普查才补录，改扩建后的管段仍显示旧版本，废弃管线迟迟不注销。系统上线时的数据是“快照”，三年后变成“历史地图”。业务部门一旦发现图上的信息不可靠，就会重新用回计算机辅助设计（CAD）图纸和纸质图，系统使用率下降，数据回流进一步减少，形成负向循环。

更隐蔽的问题是“更新责任”没有落到岗位上。工程部门认为数据由信息中心维护，信息中心认为数据应由管网部门提供，管网部门认为竣工资料在档案室。三方都能说出理由，结果是谁都不对新增数据负责。没有明确的责任人、交接单和时限，任何更新制度都会停留在文件层面。

14.1.4 多源异构与坐标高程不统一

水务企业的空间数据来源极其分散：设计院交来的是 DWG 图纸，施工单位交来的是管线点成果表和 PDF，普查单位交来的是 Shapefile 与 GeoDatabase，运行部门维护的是 Excel 与纸质记录，监测数据则来自数据采集与监视控制系统（SCADA）与时序库。格式不同只是表层，深层是空间参考不统一。CGCS2000（2000 国家大地坐标系）、西安80、北京54、地方独立坐标系在同一张图上混用，跨投影带的数据接边处出现明显错位。

高程基准的问题更隐蔽也更危险。1985 国家高程基准、地方高程系、工程假定高程常常混在同一批数据里，元数据却不记录。把两套高程直接叠加做淹没分析，结果会出现系统性偏差，而且偏差方向一致，很难通过“看起来不合理”发现。河道、管网、地面三套数据的高程基准如果不统一，内涝模拟的水面线与地面线就不在同一个参照系里。

时态不一致同样普遍。不同年份的普查成果、不同批次的竣工测量、不同厂商的入库数据叠加在一起，同一管段存在多个版本，却没有生效时间与失效时间字段。做历史回溯时无法判断“当时是什么状态”，做现状分析时又不知道哪一版最新。时空数据如果没有时间维度，就只是“会动的 CAD”。

14.1.5 拓扑断裂：图上相连、逻辑不通

拓扑关系是 GIS 区别于 CAD 的核心。CAD 的线条只表达几何，不表达“谁连着谁”；GIS 的网络要素必须表达节点、边、连通与方向。现实中大量管网数据是从 CAD 转换而来，交叉处没有打断，丁字口没有建节点，阀门没有作为可关闭的网络要素，结果就是“视觉上相连、逻辑上断开”。

拓扑断裂直接摧毁分析能力。连通性分析无法回答“关掉这个阀门，哪些用户会停水”；关阀分析无法给出最小关阀集合；污染溯源无法沿流向反向追踪；内涝汇流路径无法从洼地回溯到排放口。排水管网中的逆坡记录、断头管、雨污混接点如果未标注，模型会把错误的结构当成真实结构，算出来的结果比不算更危险。

修复拓扑断裂的成本常被低估。它不是“跑一个工具”就能解决，而需要逐段核对：哪些交叉是真实连接，哪些是上下穿越；哪些阀门是常开，哪些是常闭；哪些管段已经废弃。工作量往往与一次专项普查相当，因此越晚治理，欠账越大。

14.1.6 数据孤岛与主数据缺位

一个中等规模的水务企业，与空间位置相关的系统通常包括 GIS、SCADA、营收、工单、DMA 计量、水质在线、巡检、工程管理、客服等。每个系统都有自己的设施编码：GIS 用管段编号，营收用用户编号，工单用位置描述，SCADA 用测点编号。同一个小区在不同系统里有不同的边界，同一个阀门在不同系统里有不同的 ID，跨系统分析必须先做人工映射。

孤岛的根源是主数据缺位。主数据是企业在多个系统间共享、需要保持一致的核心实体数据，例如设施、客户、组织、区域。没有主数据管理（MDM），就没有权威源、没有唯一标识、没有变更分发机制。系统之间靠文件导出导入或数据库直连同步，接口没有版本、没有契约，一次字段变更就可能让下游系统静默出错。

孤岛的代价体现在闭环业务上。一次爆管处置，从 SCADA 报警到工单派发、关阀分析、停水通知、抢修回填、客服回访，要在四五个系统之间切换，每切换一次就要人工核对一次数据。所谓“一体化平台”，如果底层主数据没有打通，最终只是在界面上把几个系统拼在一起。

表14-1 数据之痛的典型表现、业务后果与处置优先级

【实践观察】某地级市供水管网普查成果的“三年衰减” 某地级市在上一轮管网普查中投入大量人力，形成了覆盖建成区的管线图层，一度成为省内示范。三年后的一次专项检查发现：新建道路下的管线大面积缺失，迁改管段仍显示旧线位，部分阀门位置与现场偏差明显，废弃管线未注销。复盘显示，问题不在普查质量，而在更新机制——竣工测量成果没有纳入工程验收，工程部门与管网部门没有数据交接单，GIS 岗位长期由一人兼任且以制图为主。 该市随后做了三件事：把“按标准提交竣工测量数据并完成入库确认”写入施工合同与验收流程；建立月度增量更新与季度账图物对账；设置专职数据管理员，把数据质量纳入部门考核。两年后，新增数据的现势性明显改善，关阀分析的现场符合率同步提升。 这个案例的启示是：普查是一次性投入，更新是长期机制。没有机制，再好的普查成果也会按年衰减；有了机制，哪怕起点低一些，数据也会逐步变好。

14.2 标准之痛

标准的价值在于让不同时间、不同厂商、不同部门生产的数据可以拼接。水务 GIS 的标准之痛，主要不是“没有标准”，而是标准不细、口径不一、落地无抓手、跨部门不对齐。国家标准与行业标准给出的是原则、分类与基本要求，真正决定数据能否互通的字段级规则，往往要靠地方细则和企业标准补齐。这个“最后一公里”如果没人修，标准就只是评审材料里的引用。

14.2.1 编码不统一

设施分类分级是第一道坎。供水专业习惯把网络拆成“管线—管段—管件”，排水专业习惯拆成“管道—检查井—雨水口—排放口”，污水厂又按“工艺单元—设备—仪表”组织。同样是“节点”，在供水里可能指三通，在排水里指检查井，语义并不相同。分类不统一，跨专业的数据汇交就要先做语义映射。

编码规则同样各行其是。有的按行政区、道路、序号分段编码，有的按拓扑关系自动编号，有的直接沿用设计图号，还有的在系统迁移时重新发号。图层命名与字段命名也是中文、英文、拼音混用，同一个“管径”在不同库中叫“管径”“口径”“DN”“直径”。这些差异看似琐碎，累积起来就是一张庞大的映射表，而映射表本身又需要维护，成为新的负担。

14.2.2 口径不一致

口径不一致比编码不一致更麻烦，因为它影响的是管理判断。管线长度按图上量算、按竣工测量还是按设计长度统计，结果不同；服务面积按行政区面积、管网覆盖面积还是实际供水面积统计，结论不同；污水集中收集率的分子分母如何界定建成区与处理量，也有多种算法。指标一旦被混用，管理层看到的数字就不可比。

漏损率与产销差率是最典型的例子。CJJ 92-2016《城镇供水管网漏损控制及评定标准》对漏损水量与漏损率有明确界定，漏损水量包括漏失水量、计量损失水量和其他损失水量；产销差率则是供水量与售水量之差占供水量的比例。两者数值接近但含义不同，前者用于漏损控制评价，后者用于经营分析。把两者当成同一个指标考核，基层就会选择对自己有利的口径，数据随之失真。

14.2.3 标准落地难

标准落地需要一条完整的转化链条：标准条文转化为数据字典，数据字典转化为校验规则，校验规则嵌入入库卡口，卡口产生质量报告，质量报告驱动整改。多数单位只走到第一步，把标准复印进项目文档，后面的环节全部缺失。数据入库时没有字段校验、没有拓扑检查、没有必填约束，标准自然落不了地。

标准更新也慢于业务变化。调蓄池、海绵设施、再生水管网、初期雨水截流设施等新对象不断出现，既有分类体系未必覆盖；监测设备从压力计扩展到水质光谱、噪声、振动，数据模型需要扩展。如果企业标准没有版本管理机制，新增对象只能以“其他”归类，几年后数据就变成一锅粥。

14.2.4 跨部门标准冲突

水务企业的数据要同时满足多个部门的要求：规划部门的用地分类、住建部门的市政设施统计、水利部门的河湖与水文、城管部门的生命线监管、应急部门的预案与演练。每个部门都有自己的图层清单、编码规则和上报格式，同一座泵站在不同报表里有不同的分类和名称。

城市信息模型（CIM）基础平台的建设进一步放大了这个问题。CJJ/T 315-2022《城市信息模型基础平台技术标准》强调城市级模型与建筑、道路、设施的语义表达，行业 GIS 则强调管网拓扑与运行参数，两者的模型粒度、属性深度、更新频率都不同。一次城市级数据汇交，往往要做多套转换，转换过程中拓扑关系和运行属性最容易丢失。

标准治理失败的深层原因往往不是技术，而是组织。标准由谁制定、由谁解释、由谁监督执行，如果没有明确，标准就会变成“谁强势谁说了算”。第十五章讨论路径时，标准体系会被作为独立举措提出，原因就在这里。

表14-2 典型标准冲突场景与影响

14.3 模型之痛

模型是 GIS 从“看图”走向“算账”的关键一跃。供水水力模型、排水管网模型、内涝模型、水质模型在示范项目中不难出彩，难的是长期可用。模型之痛集中在五个环节：率定、参数、算力、业务嵌入与资产化。任何一个环节缺失，模型都会退化为演示工具。

14.3.1 率定困难

率定是用实测数据反推模型参数、使模拟结果逼近现实的过程。供水模型（如 EPANET）需要节点需水量、管道粗糙系数、阀门开度、水泵曲线，以及足够密度的压力与流量实测点。现实中，压力监测点集中在水厂出口和主干管，末梢压力靠人工抄表；流量监测受大用户用水和压力管理干扰，夜间最小流量也不完全等于漏损。

排水模型的率定更难。SWMM 一类模型需要汇水区划分、不透水面积比例、洼蓄深度、管渠糙率、旱流污水量，以及降雨与流量同步监测。监测点少、雨季设备易损、场次降雨样本不足，导致参数只能在很宽的范围里试。模型能跑通，但误差不可知；一旦用于调度或内涝预警，结论就经不起追问。

14.3.2 参数不确定性

模型参数不是常数。管道粗糙系数随管龄、结垢、沉积变化，同一段管道在清通前后差异明显；需水量随气温、人口、水价政策、产业结构变化；排水管道沉积与结构性缺陷改变过流能力；汇水区下垫面因城市更新持续变化。用一次率定的参数跑五年，等于用旧地图找新路。

不确定性还来自观测本身。流量计安装位置、直管段长度、满管与非满管流态、数据采集频率，都会影响实测值。模型误差与观测误差混在一起，很难分离。成熟的做法是给出参数区间与置信度，而不是给出一个“精确值”；但多数交付成果只给一套参数，业务方无法判断可靠性。

14.3.3 算力与实时性

大型管网的全网格水力计算、多情景蒙特卡洛分析、一维二维耦合内涝模拟，对算力要求很高。云上弹性算力可以缓解，但数据同步、网络时延、许可成本又成为新约束。实时调度要求分钟级响应，若模型求解需要数十分钟，就只能用于事后分析，无法进入控制回路。

边缘侧的算力更有限。泵站、闸门、调蓄池的本地控制器需要轻量化模型，降阶模型、代理模型、规则化策略是可行方向，但工程化程度参差。很多“智能调度”项目最终退化为“定时启停”，原因不是算法不行，而是模型跑不动、结果不可信。

14.3.4 模型与业务脱节

模型成果通常以报告和图件交付，没有嵌入调度、抢修、规划审批的流程节点。调度员凭经验判断，模型结论只在大屏上展示；抢修队拿到的是关阀图，不是带置信度的方案；规划部门用模型做方案比选，输入却是三年前的管网。模型与业务之间缺少“接口”，也就没有使用的理由。

另一个脱节点是“不会用”。模型输出的是流量、压力、水位、淹没深度，业务人员需要的是“哪个泵该开”“哪条路会积水”“哪些用户要通知”。中间缺少一层“业务翻译”：把模型结果转成可执行的动作清单、优先级和时间窗。这一层往往被忽略，导致模型看起来很专业，用起来很遥远。

14.3.5 模型资产化与验证缺失

模型是资产，但多数单位没有按资产管理。没有模型登记、没有版本管理、没有率定报告、没有适用边界说明，换一家咨询单位就重建一次，人员流动就失传一次。模型文件散落在个人电脑和项目盘里，谁也说不清哪个是当前版本。

验证环节同样缺失。模型上线前的率定报告往往只展示“拟合较好”的时段，缺的是上线后的后评估：模型预测与实测的偏差有没有系统回看，偏差在什么工况下变大，参数是否需要调整。没有后评估，模型就不会进步；没有进步，业务方就不会信任。

14.4 系统之痛

系统之痛的本质，是“建设逻辑”与“运行逻辑”的冲突。建设按项目立项、按功能清单验收、按里程碑付款；运行按业务连续性、按数据质量、按用户体验考核。两套逻辑没有对齐，系统就会越建越多，越建越难用。

14.4.1 烟囱式建设

每个业务口一套系统，采购时间不同、厂商不同、技术栈不同。管网一套 GIS，营业一套营收，调度一套 SCADA，工程一套项目管理，巡检一套移动应用。地图服务、用户认证、消息通知、报表工具在各系统重复建设，每个系统都要单独维护一套组织机构和权限。

烟囱之间的连接方式也很原始：文件导出导入、数据库直连、定时批量同步。接口没有版本、没有契约、没有监控，一次字段变更就可能让下游系统静默出错。所谓“数据共享”，很多时候是“把表拷过去”。

14.4.2 重复投资与供应商锁定

同一区域多次建设“一张图”并不罕见：规划部门建一套，城管部门建一套，水务企业再建一套，底图不同、精度不同、更新节奏不同。平台换了三茬，数据模型没有统一，每次迁移都要重新清洗。重复投资的账面成本可见，沉没成本不可见。

供应商锁定是另一个隐性成本。老旧系统厂商不提供接口，或接口收费很高；数据以私有格式存储，迁移需要原厂支持；定制开发的代码没有交付，运维只能继续买服务。替换成本高到无法承受时，系统就失去了演进能力。

14.4.3 集成困难

集成的难点不在技术，而在治理。缺少应用程序编程接口（API）网关、服务目录、统一身份认证，系统之间只能点对点连接；连接一多，形成蜘蛛网，任何一次变更都要评估影响面。数据同步以按天批量为主，无法支撑实时业务；主数据不一致，集成之后仍要人工核对。

集成还涉及责任边界。一个系统调用另一个系统的接口，出问题时谁负责？接口的性能、可用性、数据质量由谁保障？没有服务等级协议（SLA）和告警机制，集成就是“能通就行”，一旦出问题就互相推诿。

14.4.4 体验差

一线人员的体验最真实。一次抢修任务，要在调度系统看报警、在 GIS 看管网、在工单系统派单、在营收系统查用户、在客服系统回访，四五个系统来回切换。移动端表单字段多、必填项不合理、离线能力弱，现场信号不好就填不了。地图首屏加载慢，图层组织按厂商习惯而非业务习惯，找一个图层要翻三层菜单。

体验差的后果是使用率低。使用率低，数据回流就少；数据回流少，系统价值就更低；价值低，预算就更难争取。这个负向循环一旦形成，再好的技术方案也推不动。

14.4.5 运维成本高

运维成本包括许可、专线、机房、驻场、等保测评、版本升级。很多单位在建设期预算充足，运维期没有稳定科目，只能“哪儿漏补哪儿”。版本升级牵一发动全身，厂商不敢升，用户不敢用，系统长期停留在老旧版本。

运维还缺少可观测性。没有统一的监控告警、没有容量规划、没有故障演练，问题往往在业务高峰暴露。运维费按系统数量而非服务质量拨付，厂商缺少持续优化的动力，“维而不运”成为常态。

14.5 组织与人才之痛

数据、标准、模型、系统的问题，最终都会落到“人”和“组织”上。技术方案可以采购，组织能力买不来。组织与人才之痛集中在四个方面：复合型人才短缺、部门壁垒、职责不清、考核缺位；四者相互强化，又共同削弱了组织的学习能力。

14.5.1 复合型人才短缺

水务 GIS 需要的是“翻译者”：既能听懂管网工艺的语言，包括管径、压力、流向、水质，又能把业务问题翻译成数据与空间分析问题，还能判断结果是否合理。这样的人才在市场上稀缺，在企业内部也难培养。多数 GIS 岗位由测绘或计算机背景的人员担任，业务理解需要长期积累；而业务骨干又往往缺少数据思维。

岗位定位也在削弱吸引力。GIS 岗在很多单位被定位为“制图、出图”，日常工作是为汇报做图、为规划配图，技术含量被低估，晋升通道窄。高校培养偏重软件操作与算法，企业需求偏重业务建模与数据治理，供需之间存在结构性错位。新入职人员缺少系统的在岗训练，只能跟着项目边干边学。

14.5.2 部门壁垒

管网、营业、调度、工程、信息中心各管一段数据。管网的竣工资料在工程部门，运行数据在调度部门，用户数据在营业部门，系统运维在信息中心。跨部门取数要层层审批，共享靠个人关系。数据被当成部门权力的延伸，“给你数据就是给你把柄”的心态并不罕见。

壁垒还体现在项目上。一个跨部门的数据治理项目，往往由信息中心牵头，但信息中心没有业务指挥权；业务部门配合与否，取决于项目负责人的个人影响力，而不是制度。项目结束，协作关系随之结束，数据共享又回到原点。

14.5.3 职责不清

数据质量谁负责？是生产数据的业务部门，还是维护系统的信息中心？数据更新由谁发起、谁审核、谁入库？系统运维与数据运维是否分开？这些问题在多数单位没有明确答案。出问题时，业务部门说“系统是信息中心的”，信息中心说“数据是业务部门给的”，最后不了了之。

成熟的做法是设立数据责任人与数据管理员两类角色：前者由业务部门负责人担任，对数据的完整性、准确性、时效性负最终责任；后者由熟悉业务的骨干担任，负责日常的规则执行、问题核查与整改跟踪。没有这两类角色，数据治理就没有“人”的落点。

14.5.4 考核缺位

考核指挥棒决定了行为。多数单位考核“系统上线率”“功能完成度”“投资完成率”，不考核数据质量与使用效果。数据更新率、拓扑正确率、核心字段完整率、模型使用率、工单闭环率，这些真正反映价值的指标，很少进入经营考核。

考核缺位的另一个表现是“项目验收即终点”。验收之后，系统由谁运营、数据由谁维护、效果由谁评估，没有安排。项目团队解散，运维团队仓促接手，知识没有交接，问题在半年内集中爆发。

14.5.5 组织学习能力

很多单位在同一个问题上反复交学费：这次普查发现的问题，下次普查仍然存在；这个项目踩过的坑，下个项目继续踩。原因是没有把项目经验沉淀为组织知识，没有复盘机制、没有案例库、没有内部标准、没有培训课程。外部厂商换了一茬又一茬，企业自身的能力没有增长。

【实践观察】某水务集团数据治理的“三次反复” 某省级水务集团在五年内三次启动数据治理。第一次以“一张图”项目名义采购平台，数据由厂商导入，项目验收后无人维护；第二次成立临时小组做数据清洗，清洗完成后小组解散，新数据继续按旧习惯录入；第三次把数据治理写入部门职责，设立数据责任人，把竣工数据入库作为工程验收前置条件，并把数据质量纳入年度考核，才逐步稳定下来。 三次反复的共同教训是：数据治理不是项目，而是运营；不是技术问题，而是责任问题。平台可以买，责任买不来；工具可以换，习惯换不掉。

14.6 投入与效益之痛

GIS 与数据治理的投入产出关系，与管网改造、水厂扩建明显不同。后者的效益可以直接计量，例如供水量、处理量、能耗；前者的效益分散在多个业务环节，且往往以“避免了什么损失”的形式出现。这种特性导致投入决策困难、效益证明困难、持续投入更困难。

14.6.1 投资回报周期与资金结构

数据治理、管网补测、模型率定属于“看不见的投入”，短期没有显性产出。一次全域普查的投入不小，产出却是一张“更准的图”，很难在财务报表上体现。建设资金通常有专项渠道，例如工程配套、技术改造、信息化专项，运维与数据治理资金却常常没有科目，只能挤占其他预算。

预算按年编制，数据治理却需要跨年连续投入。第一年做普查，第二年做入库，第三年做拓扑重建，第四年做模型率定，任何一年断档，前面的投入都会打折。现实中，领导换届、预算收紧、审计问责，都可能让项目中途停摆。

14.6.2 效益难量化

效益分散在漏损、能耗、抢修、投诉、合规等多个口径，归属难界定。漏损率下降可能来自压力管理、分区计量、管网改造、计量器具更换，GIS 只是其中一个因素；抢修时长缩短可能来自队伍调整、备件前移、交通改善，关阀分析的贡献很难单独剥离。

更基础的问题是缺少基线。系统上线前的漏损率、抢修平均时长、投诉率、工单闭环率，如果没有规范记录，上线后就无法对比。很多项目在验收时才想起“要有前后对比”，只能靠回忆和估算，结论自然缺乏说服力。

14.6.3 重建设轻运营

项目制思维贯穿始终：立项、建设、验收、移交，之后无预算、无团队、无考核。系统“建成就落后”，数据“上线即峰值”。运维费按系统数量拨付，不按数据质量与服务等级，厂商没有动力持续优化；业务部门没有参与建设，接手后不愿用、不会用。

运营缺位还表现在制度上。数据更新没有流程、没有时限、没有责任人；系统变更没有审批、没有测试、没有回滚；用户反馈没有入口、没有闭环。运营不是修修补补，而是一套持续改进的机制，这套机制在多数单位尚未建立。

14.6.4 采购方式与合同管理

按功能清单招标是常见做法，厂商以功能数量取胜，数据治理、模型率定、培训与运维被压到最低价。合同里写的是“提供某某功能模块”，不是“达到某某数据质量”或“模型精度满足某某要求”。验收时按功能点逐项打勾，数据能不能用、模型准不准，反而没有标准。

更合理的方式是把数据质量指标、模型精度指标、服务等级写进合同与付款节点：数据入库验收合格才付尾款，模型率定报告通过评审才进入下一阶段，运维期按服务质量考核付费。采购方式不改，技术投入的效益就很难保证。

14.7 安全与合规之痛

水务空间数据兼具“基础设施属性”和“地理信息属性”。前者关系到城市运行安全，后者受测绘地理信息管理约束。两重属性叠加，使安全与合规成为 GIS 建设中不能绕过的边界，而不是上线前补一份材料。

14.7.1 地理信息安全

地下管线、厂站、取水口、排放口等空间数据，在不少地区被列为敏感或受控数据。《中华人民共和国测绘法》（2017年修订）对地理信息的生产、保管、提供、使用提出要求；《地图管理条例》（2015年）对地图编制、审核、出版作出规定。对外提供数据、公开发布地图、在互联网地图上标注设施，都需要履行相应程序。

内部共享同样需要边界。哪些部门可以看全要素，哪些只能看脱敏后的图层，哪些数据可以导出，导出后如何追溯，这些都应有明确规则。实践中常见的问题是“一套权限走天下”：系统上线时给所有人开放全部图层，之后再也没有调整。

14.7.2 数据分类分级

水务数据横跨设施数据、运行数据、用户数据、财务数据、工程数据。《中华人民共和国数据安全法》（2021年）要求建立数据分类分级保护制度，《中华人民共和国个人信息保护法》（2021年）对个人信息处理提出告知同意、最小必要等要求。用户地址、用水量、缴费记录属于个人信息，与空间位置结合后，风险会放大。

分类分级不是贴标签，而是要落到控制措施：不同级别对应不同的访问审批、加密存储、脱敏展示、审计留痕、销毁流程。很多单位做了分类分级的表格，却没有对应的技术控制，表格就只是合规材料。

14.7.3 等保与关键信息基础设施保护

调度、SCADA、营收、客服等系统，按网络安全等级保护制度要求定级备案、建设整改、测评。涉及城市供水安全的系统，还可能被认定为关键信息基础设施，适用《中华人民共和国网络安全法》（2016年）和《关键信息基础设施安全保护条例》（2021年）的更高要求，包括专门安全管理机构、人员背景审查、年度检测评估、应急预案与演练。

云上部署后，责任边界需要重新划分。云服务商负责基础设施安全，运营者负责业务与数据安全，但“你中有我”的部分最容易出现空白。合同里如果只写“提供云主机”，不写安全责任矩阵，出问题时就很难界定。

14.7.4 供应链与国产化适配

数据库、GIS 平台、操作系统、芯片的国产化适配，是近年信息化建设的重要约束。适配不只是“能装能跑”，还涉及空间函数完整性、性能表现、生态工具链、运维人才。部分国产数据库对空间索引与复杂空间查询的支持仍在完善，迁移时需要做兼容性评估与性能压测。

多厂商混合环境增加了运维复杂度。国外平台与国产平台并存，数据格式与接口标准不一，版本升级节奏不同。离线或内网部署的环境，无法在线更新补丁，安全漏洞的修复周期更长，需要建立离线升级与漏洞响应机制。

14.7.5 权限、共享与审计

跨部门共享是趋势，但共享的前提是“可控”。需要明确授权边界，即谁可以申请、谁审批、有效期多长；需要明确脱敏规则，即哪些字段必须遮蔽；需要水印溯源，知道是谁泄露的；需要访问日志，记录谁在什么时候看了什么。外包人员、运维账号、测试环境是薄弱环节，测试数据如果直接使用生产数据，泄露风险很高。

安全与合规还有一个容易被忽略的维度：业务连续性。地理信息服务一旦中断，调度、抢修、客服都会受影响。备份、容灾、降级方案要在设计阶段考虑，而不是在事故之后补救。

14.8 技术与工程之痛

技术之痛不是“技术不先进”，而是“先进技术落不到生产环境”。工程之痛则是实施过程中的系统性偏差：需求变更、集成联调、数据迁移、验收标准，任何一环出问题都会拖垮项目。两者叠加，就出现“演示很成功、上线很失败”的常见结局。

14.8.1 三维性能与轻量化

实景三维、建筑信息模型（BIM）、激光雷达（LiDAR）点云数据体量大，浏览器端渲染压力大。倾斜摄影模型动辄数十 GB，加载慢、交互卡；BIM 模型构件数量多，属性查询与空间分析性能差。细节层次（LOD）、瓦片化、实例化、服务端渲染是常用手段，但工程化程度参差。

三维在方案汇报中很好看，在生产调度中用得少，原因往往不是“不需要三维”，而是“加载太慢、属性查不动、更新太麻烦”。三维要进入生产，必须解决三个问题：首屏加载时间可接受、构件与业务数据可关联、模型更新能跟上工程变更。

14.8.2 海量数据治理

遥感影像、倾斜摄影、点云、时序监测数据的入库、切片、更新耗时长。一次全域影像更新可能涉及数 TB 数据，处理链条长，任何一个环节失败都要重来。数据版本多、存储成本高，冷热分层与生命周期管理缺失，存储很快被占满。

数据治理还包括元数据管理。很多单位有数据、没有元数据：不知道数据什么时候生产、用什么坐标系、精度如何、覆盖范围多大、谁负责更新。没有元数据，数据目录就只是文件列表，无法支撑共享与复用。

14.8.3 人工智能的可信性

人工智能在排水管道缺陷识别、遥感地物提取、积水识别、投诉文本分类等场景已有应用，但可信性仍是瓶颈。样本不平衡导致少数类缺陷漏检；标注标准不统一导致模型学到的是标注员的习惯；模型可解释性不足，业务人员不敢用；数据漂移，例如新管材、新工艺、新场景，会导致训练集失效。

可行的路径是“机器初筛加人工复核”，把人工智能定位为提高效率的工具，而不是替代判断的主体。同时建立模型评估机制：召回率、精确率、误检分布、复核纠正率，定期回看。没有评估机制，效果就无法证明，也无法改进。

14.8.4 边缘与实时

泵站、闸门、DMA 的边缘计算需要低时延、断网续传、时钟同步。现场网络抖动、供电不稳，导致数据缺测；边缘设备的安全加固与远程运维能力不足，一旦被攻破，可能影响控制安全。边缘侧的数据质量治理也常被忽略：缺测、跳变、漂移没有标记，上传到云上就成了“脏数据”。

边缘与云端的职责划分也要清楚。哪些计算必须在本地完成，哪些可以上云，断网时降级到什么程度，恢复后如何补传与对账，这些问题要在设计阶段回答，而不是在运行中试错。

14.8.5 工程实施

多厂商集成、接口联调、数据迁移是项目延期的主因。需求在实施过程中不断变更，变更没有冻结机制；接口文档与实现不一致，联调反复；历史数据质量差，迁移脚本写了一版又一版。验收标准偏功能、轻数据，试运行期短，问题在上线后集中爆发。

工程实施还缺少性能压测与灾备演练。系统在演示环境跑得通，到了生产环境数据量一大就卡；灾备方案写在纸上，没有实际切换过。这些问题在上线前不显眼，上线后就是事故。

14.9 根因分析

上面八类痛点不是并列关系，而是互为因果。数据不准导致模型不可信，模型不可信导致系统没人用，系统没人用导致数据回流更少；标准不统一导致集成困难，集成困难导致重复建设，重复建设又强化了烟囱格局。把它们放回组织运行的真实场景，可以归纳为制度、机制、技术、能力四个层面。

制度层面，数据作为生产要素的地位尚未在企业管理中确立。数据不在资产负债表上，不进入工程交接清单，不进入离任审计；谁生产、谁维护、谁负责，缺少制度安排。制度不改，数据治理就只能靠运动式项目，项目一结束，一切照旧。

机制层面，投资、建设、运维、考核四条线彼此割裂。建设期不考虑运维，运维期没有改造预算；考核只看上线、不看使用；数据质量好坏与部门利益无关。机制不改，技术投入就没有持续的动力，也没有纠偏的反馈。

技术层面，缺少企业级时空数据底座，标准没有工程化，模型没有资产化。数据分散在各系统，服务没有统一入口，权限没有统一管理；标准停留在文档，没有变成校验规则；模型停留在项目，没有登记、版本与后评估。

能力层面，人才结构偏单一，组织学习机制缺失，过度依赖外部厂商。项目经验没有沉淀为组织知识，人员流动带走的不只是人，还有方法；外部厂商换一茬，企业就要重新交一次学费。

表14-3 四层根因、典型表征与破解抓手

四层之间是“制度定方向、机制给动力、技术做支撑、能力保落地”的关系。只做技术投入而不动制度与机制，结果就是系统越建越多、数据越用越少；只改制度而不给技术支撑，制度就会变成填表。第十五章的路径设计，正是按这四个层面同时发力。

14.10 本章小结

本章按八个方面拆解了 GIS 在水务业务中的痛点。数据、标准、模型是“地基”：数据不准，一切分析失真；标准不统一，数据无法拼接；模型不可信，决策无法依赖。这三者决定了 GIS 能力的下限，也决定了下游系统的价值上限。

系统、组织、投入是“骨架”：烟囱式建设与重复投资消耗资源，部门壁垒与职责不清让治理失去落点，重建设轻运营让投入无法持续。骨架不牢，技术能力再强也难以转化为业务效果。

安全合规是“边界”，技术工程是“施工质量”。前者决定能做什么、不能做什么，后者决定做得好不好、能不能长期运行。边界不清，创新就会踩线；施工不精，系统就会在细节上崩掉。

根因在制度、机制、技术、能力四层。痛点的价值在于为路径设计提供坐标：哪些必须先补课，哪些可以并行，哪些需要制度先行。这些问题不解决，任何新技术都只是在旧地基上加层，投入越多，沉没成本越高。第十五章将据此给出“十五五”期间的路线图。

思考与练习

1. 概念辨析：本章否定“数据之痛就是数据太少”这一流行说法。请用“账、图、物三套账”与普查成果“三年衰减”两个材料，说明“不可信、不可用、不可持续”与“数量不足”是三件不同的事，并指出各自的解法。
2. 现场作业：选一段你熟悉的管段做一次对账：图上阀门与现场阀门是否一致、是否存在未登记的连通管或私接、管顶（或管底）高程是否有记录、该管段最近一次变更有无入库。把结果填成一张“账图物对账表”，并标注哪一项会直接破坏关阀分析。
3. 计算题：某 DMA 夜间最小流量实测为 12 立方米每小时。若因边界阀门与图上不符，漏计了一个稳定用水 3 立方米每小时的用水单元，请写出漏损量估算式，说明该 DMA 的漏损率被高估还是低估、幅度约多少，并指出这会怎样改变检漏任务的排序。
4. 对照表14-3：本单位“竣工数据不回流”这一现象最可能落在哪一层根因？请分别从制度、机制、技术、能力四个层面各写一条可执行的破解抓手，并说明四者中应当先做哪一个、为什么。
5. 跨章关联：第 11 章的主数据管理、第 13 章的五级成熟度、第 15 章的三阶段路径，分别对应本章的哪一类痛点与哪一层根因？请用文字画出一条“痛点—根因—举措”的对应链。
6. 推演：假设一家企业连续三年只投入平台与三维建设，不动数据责任与考核。请推演第五年的状态：使用率、数据质量、预算谈判能力各会怎样变化，并指出这个负向循环最容易被哪一个动作打破。