智慧城市治理产品该如何构建？作者结合自身经历，总结过去所负责的产品和项目，梳理并构建城市治理（智慧城市）的整体业务架构、以及通过调研分析城市治理的发展趋势和市场情况，并对其需要进行产品设计。
本篇文章，旨在对个人从事 TOG 工作 3 年半（待过 2 家做 2G 业务的公司）的工作内容的一个总结和回顾，结合个人所负责过的一些产品和项目，梳理并构建城市治理（智慧城市）的整体业务架构、以及通过调研分析城市治理的发展趋势和市场情况，给出广义城市治理业务下的产品解决方案（" 一网统管 " 产品架构），并就【智慧城市产品矩阵】中的【数据融合治理】平台，进行需求分析和产品设计。
本篇文章对哪些人有帮助？
1、对智慧城市、一网统管业务，对公安、安全、城管等政府部门业务有调研了解需求的童鞋；
2、对不知如何从业务下手，进而实施产品和功能设计的童鞋，或是想要加强从业务 ->产品 ->功能基本功练习的童鞋；
3、对数据中台、数据融合治理平台 - 产品设计感兴趣的童鞋；
一、城市治理业务现状、市场竞争格局及发展趋势
1.1 城市治理业务现状（业务流程及业务架构）
城市治理业务，狭义来讲，指的是 " 城市管理 "，即由城管部门负责的各类城管违章事件的治理；广义来讲，城市治理等于 " 一网通管、一网通办 "，甚至再广点说，可以上升到国家安全层面的治理。
为什么城市治理这么重要？
——城市是国家主体在运行过程中的实体单元。只有一个个城市稳定高效运行，且城市之间有多种动态的互动和联系，才能让每个城市中的人、财、物、意识形态等资源可以流动并形成闭环，整个国家才得以运转（个人拙见）。因此，城市治理很重要。
参与广义城市治理的政府部门有：国安体系、公安体系、大城管体系。
国安体系，有国安部，以及下辖的情报局 / 技侦局 / 网络安全局等。
公安体系，有公安部、省级公安厅 / 市级公安局 /xx 总队 /xx 大队 /xx 支队（经侦、刑侦、网安、治安、技侦等）；
大城管体系，有城运（城指）中心 / 城管执法局 / 政务服务中心 / 交管局 / 水务局 / 气象局 / 农业局等；
政府部门城市治理的业务职责和业务需求是：在法律权责约束下，解决城市运行过程中的一系列问题，包括基础设施的建设，人民和企业主体在日常生活工作过程中遇到的各类紧急及非紧急问题 / 事件，最终目标是运用各种先进的手段（管理手段、技术手段），不断提高人民群众的幸福感和满意度，为中国的战略目标实现（以中国式的现代化，推进中华民族的伟大复兴）提供支撑。
因此，整个城市治理（广义城市治理：一网统管 + 一网通办）的业务架构，基本如下：
" 一网统管，一网通办 "- 业务架构图
一网统管的最终目标，就是说，老百姓和企业发现上报的各类问题以及政府主动治理防范发现的各类问题，都通过一个系统纳管，统一汇聚数据、统一分配数据、统一治理和分析数据，从而解决问题和防范问题。而不是每个体系，每个部门单打独斗。一网统管解决的就是：系统功能和应用重复建设，以及打破系统间的数据壁垒，实现政府数据资产的全链路管理。而当下，各个城市 - 智慧城市建设进展大多仍处于 " 进行中 " 状态，仍存在 " 各政府部门间数据未打通 "、" 系统重复建设 " 等问题，有的地区可能尚未开始，有的地区可能已经建设的较为完善了。
一网通办的最终目标，就是说，尽可能地将老百姓的各类办事入口挪到线上，线下少跑腿。譬如微信、支付宝、百度小程序里面的各类面向企业和市民的小程序已经实现的譬如：" 生活缴费 "（水电燃气费）、" 电子身份证 "、" 医保电子凭证 "、" 居住证办理 "、" 智慧出行 "（地铁公交乘车码）等功能，通过这几款产品入口都能达到同样的办事目的。而当下，一网通办业务也处于 " 进行中 " 状态，已经取得一些成果了，仍有一些政府办事需要迁移至线上。
1.2 城市治理领域的市场竞争格局
早在上述政策出台前，也就是从 2016 年 " 互联网 +" 概念提出，再到后来的 "AI+"、" 智慧城市 " 等概念 / 战略提出，整个期间，一系列 " 互联网 +"、"AI+"、" 一网统管、一网通办 "、" 智慧城市 " 的产品和解决方案问世（市）。
那在这个【智慧城市】领域的玩家，有哪些典型代表？
互联网科技厂商，如阿里、百度、华为、腾讯、浪潮、商汤等；
做系统集成的服务商：有国企央企背景的，如国投、电信、联通、移动等运营商；
还有一些其它专攻智慧城市细分业务的厂商，如公安领域的 " 任子行 "、" 烽火科技 " 等；
还有做硬件起家的科技公司，如 " 海康威视 " 等。
当然还有一些地方知名的小厂商，比如 " 易视通联 " 等；
——各家也是挑自家所长，做自己能做的解决方案 / 产品 / 服务 / 方案 + 产品 + 服务组合…
——而且各家的 " 解决方案 / 产品 / 服务 / 方案 + 产品 + 服务组合 " 也是逐步迭代、完善的一个过程。
总体来看，各厂商在【城市治理业务架构】中，分别做了如下东西：
在感知层：提供智能采集软硬件方案 / 产品，如商汤 / 旷视 / 海康威视的可以智能识别交通违章类型的摄像头、各种智能 IOT 设备（气压、气温、湿度、能见度检测仪等）；
在认知层：NLP（自然语言理解、自然语言生成）技术，理解市民和企业需求。主要数据来源有大城管上报的、110 口上报的…，通过数据融合汇聚 ->数据治理及分析，深度挖掘社情民意，给领导提供决策支撑。
在决策层：提供 IOC（领导驾驶舱 - 大屏形态为主），辅以数字人、地图等能力，以一张图形式将城市中的人、地、事、物、组织进行关联，将城市中的人、地、事、物等城市核心要素落点落图，方便管理与决策；
在执行层：提供协同办公系统，如 " 国泰新点 "、" 首都信息发展公司 "、" 中国电信 - 亿迅 " 等，以使得政府内部各部门、各角色，能够将上报的城市治理事件进行分发、处置、流转等业务办理操作。
1.3 城市治理业务的发展趋势
P：国家国务院等部门，倡导各级政府领导班子，执行 " 一网通管、一网通办 " 城市治理策略，各政府部门数据要协同、协作，解决数据孤岛问题，切实利用适用于本地区发展的技术手段和管理手段，解决各自的业务问题，提高人民群众的幸福指数，打造城市治理标杆案例，提高国际影响力，促进国际交流合作；也陆续出台了一系列政策。
近期 23 年 9 月份出台的政策，则强调更多的是运用人工智能、云计算等技术，提高城市科学化、精细化、智能化治理水平，如下：
E：经济水平，我国一直处于世界第二大经济体，虽然当前社会大环境不太乐观，且国家内部有些地区还属于贫困地区，但总体经济水平较前几个十年已经改善了很多；
S：人们的生活水平（包括精神水平、物质水平）在国家的繁荣发展下，得以不断改善提高，所以人民和企业越来越看重政府的公信力，期望办事能够少跑几趟，政府办事效率提高，解决问题能力提高，切实提升社会主体中人民群众的幸福感和归属感；
T：大模型、AI、云计算、互联网 + 等技术不断发展，为各类业务场景提供了强有力的技术支撑。
因此，总体来看，到 2027 年，城市治理业务的发展趋势，都围绕着一个主基调：科学化、精细化、智能化。
二、城市治理业务场景下的 - 产品解决方案
在进行产品方案设计时，除了要考虑业务需求和业务发展趋势情况，还要充分考虑市场竞争和自身优劣势因素，选择一个公司和团队能够落地的产品方案。
2.1 产品解决方案设计
通过前面对城市治理业务现状、不足、行业发展趋势、市场竞争现状的分析，可以得出如下结论：
城市治理的现状与问题：城市治理业务中，有非常多的细分业务场景，比如公安、消防、城管、交通、水务、气象、园林绿化…现阶段主流的做法是：每一个单点的业务场景，单独建立产品，单独管理自身业务。——这就造成了：各个政府部门之间协作力度不够，彼此之间的数据处于割裂状态，无法充分发挥数据价值，也就间接导致了城市治理成效提升不显著。
城市治理业务发展趋势和目标：科学化、精细化、智能化、协同化。
因此，在未来，如何充分发挥城市治理业务中各要素（人、地、事、物、组织、情报）数据的价值，各级政府部门如何更好地协作联动、如何推进科学化、精细化、智能化，将成为城市治理的主旋律。
如下图，是个人根据业务水平和认知给出的城市治理 / 一网统管业务的 - 产品架构设计，包含几层：基础设施层、数据采集及接入层、数据融合治理 & 各类配置层、业务执行、精细化运营管理与决策层。
想了解更多，大家可自行搜索百度云、华为云、阿里云、腾讯云、电信云等公司官网，查看这些大厂给出的智慧城市产品解决方案 / 产品架构。
2.2 数据融合治理平台 - 产品设计
以下是我抽象出的，关于【数据融合治理】平台核心功能的建设思路（分析需求 ->给出需求方案）：
*（1）首先数据融合治理平台，需要对接不同数据来源的、不同数据规模的、不同数据处理频次的数据，并入库存储；
–因此需要具备【大数据】存储和管理功能，并提供入库接口或其它数据入库方式（如 kafka 中间件、直接后台写入数据库等）；在技术选型上，需要考虑支撑实时数据处理（流式、批处理等）、离线数据处理等多种场景。
*（2）由于各类数据可能是结构化的，可能是半结构化的，也可能是非结构化的（办公文档、文本、图片 , HTML、各类报表、图像和音频 / 视频信息等），因此需要具备对半结构化和非结构化数据的处理能力；
*（3）因为数据融合治理平台，其治理成果要支撑城市治理业务精细化、智能化决策与分析。因此需要对数据治理的实体对象（人、地、事、物、组织）构建相对全面的标签画像。
以上三步，可根据业务建设需要，选择合适的【数据处理系统】架构，比如借鉴数仓概念和架构，对数据进行分层治理，分为：ODS 层（原始数据层）、DW（数仓层）、ADS 层（数据应用层）。
在建设前期，需要制定【统一的数据标准】即数据字典，并与各业务方宣贯，避免出现数据标准不一致的问题。
在上述第三步，治理生成的可供业务直接查询应用的各类主题数据，即人、地、事、物、组织数据，需要运用到各类 AI 技术，进行数据治理，比如需要支撑下述核心需求场景的实现：
（1）实体多维度画像刻画。运用 NLP&CV 机器学习 / 深度学习等技术对这些实体进行多维度画像刻画。在支撑实体画像刻画前，还需建设标签体系，以及开发相配套的标签运营团队 / 工具，以制定打标策略、检验打标效果等。
（3）实体及实体属性的对齐。运用 AI 算法（文本相似度算法、图片相似度、多模理解等技术）进行实体及实体属性的对齐，即不同的描述，但均指向同一对象。比如 " 吴亦凡 "（吴签），均有可能指向同一人；又比如不同社交账号，但其使用者均为同一人；再比如同一事件（涉事主体、事件摘要、事发地均为同一地点），但文本描述上有所不同，需要运用 NLP 语义识别能力，将其识别出来并做好归一，并给出相似度分数；再比如同样一个标签，在业务场景 A 种叫做 " 噪音扰民 "，在业务场景 B 中叫做 " 噪声扰民 "，但本质是一个意思，这就需要在数据治理时，对标签名称进行规范化（规范化的一个好处就是：提高数据治理的效率；当然有些标签在不同业务场景中就是有自己独特的定义，这时便不需要做规范化处理，具体情况需要根据实际业务场景甄别）。
（3）挖掘人、地、事、物、组织、账号等实体间的关联关系。运用 AI、知识图谱技术挖掘这些实体间的关联关系挖掘，这些关系可能包含显性关系（即张三与李四是 " 母女 " 关系；" 张三 " 与 " 白白 " 近期在微博平台互动 100 次；），可能需要人工提前梳理出【实体 - 关系 - 实体】关系集合，以引导实现初版策略，而后算法可基于这个策略自迭代；
（4）数据融合治理成果，需支持多种数据使用场景：PULL OR PUSH。即打了多维度标签的人 / 地 / 事 / 物 / 组织等数据，需要支持业务多条件查询，或主动 push 给业务，供业务查看；
在实际开发数据服务过程中，除了要事先明确好数据标准规范，关于各类标签的计算规则也要进行明确。一般来说，关于业务标签可以分为这几类：规则类标签、算法模型类标签、统计类标签等；不同标签业务要求的更新频率可能不同，比如关于某些个重点人物的网络发言，其监测和分析的时效性要求实时，而一些非重点人物的网络发言及其它行为分析–时效性可能就不会要求很实时，比如天级别、周级别、月级别。——数据治理与分析系统，要结合实际的数据分析业务场景来制定相应的产品需求和技术方案。
此外，关于数据的存储、管理，还需要配合【各类数据管理工具】，以方便数据开发人员管理数据；以及【功能权限设置与管理功能、审批流程】等，以实现数据的权限审批管理等；以及配套的监控与报警服务，对各线程进行监控，并设置服务挂断自动重启等宕机解决方案。
下图是 58 公司的数据中台产品架构，可供读者们学习思考。
写在最后：这是我在漫漫产品升级打怪这条路上的第 4 个年头了（2020 年夏天正式开始的，四舍五入），刚开始工作时，接触的都是一些看不着界面的 API、PaaS 类产品，天天忙着给 AI 模型找 badcase，也有一些大屏、小程序的产品，但都止步于 demo 阶段，我甚至连 PaaS 概念是啥都不清楚，也不清楚为何 2G 产品就偏要私有化，哦，甚至连什么是私有化都不知道。就这样，我像一个小陀螺一样被一个又一个接踵而来的 " 新概念 " 鞭挞着转圈圈。
直到后来，我决定跳出这个圈，去开拓自己的产品视野，我加入了另一家公司，负责了 SaaS 前后台产品，我才知道 我在百度两年里做的产品到底算什么、是什么（有点夸张了啊，真的是要平时多思考，建立起自己的产品体系，所有问题都会迎刃而解，在你的体系里，缺哪补哪即可）。
所以，产品经理们，请不要真的像个螺丝一样，我们要除了要搞懂我们自己做的产品是 2B、2G、2C 外，还要搞懂：
我们做的是【前台】、【中台】还是【后台】？
我们做的是功能型产品，还是策略型产品（AI 产品）？是行业化 AI 应用，还是 AI 机器学习平台、数据标注平台这种平台型产品？
我们做的产品，是项目定制的？还是标准化产品？（可规模售卖的）；
我们做的产品是 SaaS、PaaS（即 Web 产品），还是需要下载安装的客户端产品？
我们做的产品，是平台化产品吗？（平台化产品，要能同时解决一类问题，甚至是多类问题，本质就是各类功能、流程的抽象提炼和配置化）。
所以，共勉 ~~ 加油！也为我自己说。欢迎各位留言交流 ~
本文由 @南方碟道 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
