中后台产品实践：以智慧城市场景【数据融合治理平台】产品为例_复兴网_复兴新闻网

智慧城市治理产品该如何构建？作者结合自身经历，总结过去所负责的产品和项目，梳理并构建城市治理（智慧城市）的整体业务架构、以及通过调研分析城市治理的发展趋势和市场情况，并对其需要进行产品设计。

“一网统管，一网通办”-业务架构图

一网统管的最终目标，就是说，老百姓和企业发现上报的各类问题以及政府主动治理防范发现的各类问题，都通过一个系统纳管，统一汇聚数据、统一分配数据、统一治理和分析数据，从而解决问题和防范问题。而不是每个体系，每个部门单打独斗。一网统管解决的就是：系统功能和应用重复建设，以及打破系统间的数据壁垒，实现政府数据资产的全链路管理。而当下，各个城市-智慧城市建设进展大多仍处于 “进行中”状态，仍存在“各政府部门间数据未打通”、“系统重复建设”等问题，有的地区可能尚未开始，有的地区可能已经建设的较为完善了。

一网通办的最终目标，就是说，尽可能地将老百姓的各类办事入口挪到线上，线下少跑腿。譬如微信、支付宝、百度小程序里面的各类面向企业和市民的小程序已经实现的譬如：“生活缴费”（水电燃气费）、“电子身份证”、“医保电子凭证”、“居住证办理”、“智慧出行”（地铁公交乘车码）等功能，通过这几款产品入口都能达到同样的办事目的。而当下，一网通办业务也处于“进行中”状态，已经取得一些成果了，仍有一些政府办事需要迁移至线上。

1.2 城市治理领域的市场竞争格局

早在上述政策出台前，也就是从2016年“互联网+”概念提出，再到后来的“AI+”、“智慧城市”等概念/战略提出，整个期间，一系列“互联网+”、“AI+”、“一网统管、一网通办”、“智慧城市”的产品和解决方案问世（市）。

那在这个【智慧城市】领域的玩家，有哪些典型代表？

互联网科技厂商，如阿里、百度、华为、腾讯、浪潮、商汤等；
做系统集成的服务商：有国企央企背景的，如国投、电信、联通、移动等运营商；
还有一些其它专攻智慧城市细分业务的厂商，如公安领域的“任子行”、“烽火科技”等；
还有做硬件起家的科技公司，如“海康威视”等。
当然还有一些地方知名的小厂商，比如“易视通联”等；

——各家也是挑自家所长，做自己能做的解决方案/产品/服务/方案+产品+服务组合…

——而且各家的“解决方案/产品/服务/方案+产品+服务组合”也是逐步迭代、完善的一个过程。

总体来看，各厂商在【城市治理业务架构】中，分别做了如下东西：

E：经济水平，我国一直处于世界第二大经济体，虽然当前社会大环境不太乐观，且国家内部有些地区还属于贫困地区，但总体经济水平较前几个十年已经改善了很多；
S：人们的生活水平（包括精神水平、物质水平）在国家的繁荣发展下，得以不断改善提高，所以人民和企业越来越看重政府的公信力，期望办事能够少跑几趟，政府办事效率提高，解决问题能力提高，切实提升社会主体中人民群众的幸福感和归属感；
T：大模型、AI、云计算、互联网+等技术不断发展，为各类业务场景提供了强有力的技术支撑。

因此，总体来看，到2027年，城市治理业务的发展趋势，都围绕着一个主基调：科学化、精细化、智能化。

二、城市治理业务场景下的-产品解决方案

在进行产品方案设计时，除了要考虑业务需求和业务发展趋势情况，还要充分考虑市场竞争和自身优劣势因素，选择一个公司和团队能够落地的产品方案。

2.1 产品解决方案设计

通过前面对城市治理业务现状、不足、行业发展趋势、市场竞争现状的分析，可以得出如下结论：

城市治理的现状与问题：城市治理业务中，有非常多的细分业务场景，比如公安、消防、城管、交通、水务、气象、园林绿化…现阶段主流的做法是：每一个单点的业务场景，单独建立产品，单独管理自身业务。——这就造成了：各个政府部门之间协作力度不够，彼此之间的数据处于割裂状态，无法充分发挥数据价值，也就间接导致了城市治理成效提升不显著。
城市治理业务发展趋势和目标：科学化、精细化、智能化、协同化。

因此，在未来，如何充分发挥城市治理业务中各要素（人、地、事、物、组织、情报）数据的价值，各级政府部门如何更好地协作联动、如何推进科学化、精细化、智能化，将成为城市治理的主旋律。

如下图，是个人根据业务水平和认知给出的城市治理/一网统管业务的-产品架构设计，包含几层：基础设施层、数据采集及接入层、数据融合治理&各类配置层、业务执行、精细化运营管理与决策层。

*（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外，还要搞懂：