方案设计西北实施周期 44 周水务 · 计量收费
44 周
实施周期
含 3 轮并行期
36 个月
质保方式
全远程，含版本升级
8 个
核心模块
抄表到报表全链路
11 年
数据迁移
历史用水与缴费记录
本项目为方案设计阶段，页面中的数字来自需求测算与架构推演，不是上线后的实际运行数据。 已交付项目会单独标注「已交付」。
Challenges
这个项目难在哪
每个案例的难点都不一样。先把难点说清楚，方案才有意义。
01
老系统运行十一年，数据字典没有文档，表结构和业务含义只能靠老员工口述加数据反推。
02
营业厅不能停业，新旧系统必须并行一段时间，同一笔缴费不能重复入账。
03
智能水表品牌混杂，NB-IoT 和 LoRa 两种制式并存，还有一部分仍是人工抄表，三套数据源要统一到一张账单上。
04
阶梯水价按年累计，跨年清零，历史欠费要按当年价格重算，规则比看起来复杂得多。
不是换系统，是换一套账
水务营销系统和普通业务系统最大的区别在于：它管的是钱。每一笔水费背后是抄表读数、价格规则、减免政策、缴费记录、欠费滞纳金的组合。老系统跑了十一年，这些规则以代码形式散落在各处，没有人能完整说清。
所以这个项目的核心不是「用新技术重写一遍」，而是「先把业务规则提取出来，再决定怎么实现」。
第一阶段：把规则从代码里挖出来
我们安排了三轮规则梳理，每轮都有业务人员和财务人员同时在场——很多规则只有两边对账时才会暴露。
| 梳理对象 | 发现的隐性规则 | 处理方式 |
|---|---|---|
| 阶梯水价 | 年度累计跨年清零，但欠费按欠费年度价格重算 | 单独建价格版本表，账单绑定版本 |
| 减免政策 | 低保户按季度核验资格，资格失效当月起恢复原价 | 减免做成可撤销的挂账，不直接改账单 |
| 滞纳金 | 超过 90 天按日计息，但疫情期间有政策性暂停 | 滞纳金规则可配置，支持时间段豁免 |
| 多表合一 | 同一户有生活用水和经营用水两个表，合并出账但分开计价 | 户—表—账三层模型 |
!最容易出事的地方
滞纳金和历史欠费重算。这两块如果迁移时算错，会直接引发用户投诉和监管问询。方案里专门设了一轮「迁移前后对账」，用三个月的真实数据跑双轨比对，差异必须为 0 才能切换。
三套数据源怎么统一到一张账单
抄表侧有三种情况：NB-IoT 智能表自动上报、LoRa 表经网关汇聚、老式机械表人工抄录。平台侧不区分来源，统一按「抄表事件」建模。
- NB-IoT 表：运营商平台推送到我们接口，按表号匹配用户，日冻结读数。
- LoRa 表：本地网关每小时汇聚一次，网关离线时缓存，恢复后补传。
- 人工抄表：移动端 App 录入，带 GPS 和拍照，防止估抄漏抄。
- 异常处理：连续两次读数倒走、或单月用量超过历史均值 5 倍，自动进异常池待人工确认，不直接出账。
这一层的价值在于：不管以后换哪种表、加哪种制式，账单侧的规则不用改。
迁移与并行：营业厅一天都不能停
- 1数据迁移：11 年历史数据分批迁，先迁静态档案（用户、表具、价格），再迁流水（缴费、发票、欠费）。
- 2双轨并行：新系统上线后老系统继续可查，新业务只走新系统，老系统设为只读。
- 3对账机制：每日自动比对两边的应收、实收、欠费三个总数，出现差异当天定位。
- 4切换窗口：选择月初非缴费高峰的周末做最终切换，预留 48 小时回滚窗口。
| 阶段 | 周次 | 关键交付 |
|---|---|---|
| 需求与规则梳理 | W1–W8 | 业务规则手册、数据字典 |
| 系统开发 | W9–W24 | 8 个核心模块 + 移动抄表端 |
| 数据迁移与联调 | W25–W32 | 迁移脚本、双轨对账报告 |
| 并行试运行 | W33–W40 | 3 轮对账差异归零 |
| 切换与验收 | W41–W44 | 正式切换、培训、交付文档 |
36 个月全远程质保怎么保证可用
项目地点在西北，服务方在华中，现场支持的差旅成本和时间成本都很高。所以质保方案设计成以远程为主、现场为辅：
- 远程接入：客户侧部署堡垒机，我们通过 VPN 接入，所有操作留审计日志。
- 响应分级：P1（收费中断）30 分钟响应、4 小时恢复；P2（部分功能异常）4 小时响应、24 小时恢复；P3（咨询类）下一工作日。
- 现场支持：每年包含 4 次现场巡检，重大版本升级和年度结账期可申请驻场。
- 版本升级：质保期内小版本免费升级，大版本按次报价。
Talk to Us
有类似的项目？
把你的现场情况说清楚就行，不用先写需求文档。我们会告诉你从哪切入最划算、哪些环节其实可以不花钱。
工作时间内 2 小时内回复
先判断可行性，再谈报价
不需要的不会推销