一、架构（宏观）

图1 架构图

数字底座分为核心基础、应用基础以及服务基础三个基础。

1）核心基础

核心基础，即数据。信息是由数据组成的，信息化的实现离不开数据。

数据的采集手段是“核心基础”中关键的一环，在数据采集的过程中，可能会遇到数据标准不统一、数据来源多样化、数据质量层次不齐的情况。

为了解决这些问题，笔者认为：

需要专门组建一个数据中心，该数据中心主要实现两个目标，分别为数据的采集和数据的标准建设。

同时，该数据中心需要具备专业性和权威性，专业性是为了保证数据的安全，权威性是为了保证数据的采集范围。

例如：

在上海的模式中，“上海市大数据中心”作为隶属于上海市人民政府办公厅的事业单位，承担政务数据、行业数据、社会数据和各方面数据归集和应用融合工作。同时，也会拟定数据资源归集、互联、共享、应用等技术标准和管理办法，指导本市各区、各部门数据管理工作。

在广东的模式中，数据的承建单位为各级政数局，虽然政数局同样隶属于政府办公厅的部门管理机构，但是笔者认为，在一些因素的影响下，政数局在数据的归集工作和数据标准工作的发挥空间不够，对于任务的复杂性的解决存在阻力。因此，容易导致数据采集的范围不全，标准不齐，质量不好，时效性低等情况。

笔者认为，是否可以有一种新型的数据服务模式，数据的基础性和协调性工作可以由政数局/大数据中心等政府代表牵头，协同国有的信息化企业，借助国有企业的产品专业性和技术专业性，完成数据的采集和数据的标准建设工作。

最终的目的就是，通过合作开放的方式，打造一个“政务数据超级大湖”，并且通过”数据河流”连接各式各样的“小数据湖”（不限于政务数据），在不同的河湖之间建设不同的“政务水利工程”来保障数据的传输性和安全性等。

因此，在数字化转型的过程中，需要不断的完善数据采集机制和数据对接标准，在标准化手段的基础上，直接或者间接采集各行各业的数据，打造好“核心基础”。

2）应用基础

数据的应用需要平台的支撑，因此，提出应用基础的概念，即数据中台。

数据中心（核心基础）搭建完成后，在数据转换为信息的过程中，需要对数据进行进一步的处理，包括数据的流通、数据的计算以及数据的应用。

此处的数据应用，更多的场景是体现在大屏（驾驶舱、指挥中心），因为大屏的实现蕴含了大量的数据计算和应用。

因此，针对大屏或者其他的需求实现，可以交给数据中台来负责处理和计算数据，为大屏及其他产品需求提供更好的基础支撑。

笔者认为，上述的数据中台，需要考虑平台的归属或者管理问题。因为数据中台的目的是为了更好更快的为应用提供服务，如果服务不能够得到及时的响应，那也可能会变成一种“摆设”。

同时，大屏的价值体现和对业务的理解水平紧密相关，也和数据的敏感性密切相关。因此，数据中台的建设非常考验数据的建模水平。

最后，在数据中台的建设过程中，建议数据产品和数据工程师需要在业务上形成紧密的联系，避免在数据建模的过程由于业务认知的差异性导致后续大屏指标的偏离。

3）服务基础

在数据应用的过程中，大部分的技术能力是具备公共服务属性的，因此，提出服务基础的概念。服务基础包含服务中台和算法中心。

服务中台主要是指将公共的能力或者技术进行标准化的包装，根据权限适当的内部开放或者外部开放。例如：人口库、法人库、空间地理库等。

算法中心（中枢）主要是指将算法的能力进行标准化的包装，根据权限适当的为内部或者外部赋予技术能力。例如：AI识别、知识图谱等。

4）总结

数据是核心，应用基础和服务基础是数据基础的衍生，这三个基础同时平台赋能的同时也需要具备自定义拓展的能力，即“通用”、“实用”和“好用”。

数字化应用分为智慧平台、指挥中心、专题专项三个应用。笔者认为，智慧平台的应用会优先于指挥中心，因为决策的基础是有用户的使用以及业务数据的沉淀。

建设思路是，在使用或者实践的过程中，通过使用产生的数据分析或者使用过程中提出的意见反馈来反向推动指挥中心的构建和完善。

该思路笔者称之为“应用优先，在实践过程中挖掘决策需求”。上海也有类似的口号，称为“从能用、好用到愿用、爱用”。

即：先能用，在打磨成好用，最后通过决策改进升级成爱用。

1）智慧平台方面，从主要角色出发，可以分为以下三个方向：

1. 公职人员（类公职人员）: 此类平台主要为公职人员（类公职人员）服务，从行政职能出发，通过平台或者数字化信息化的手段更加高效、智能的完成和发挥职能工作，更加的管理好城市运行工作。此类平台包含智慧司法、智慧法院、智慧环保、智慧应急、智慧党建、智慧政务等。
2. 公民、法人及其他组织: 此类平台主要为公民、法人及其他组织服务，即为民生服务。此类平台包含智慧医疗、智慧停车、智慧教育、智慧社区等。
3. 其他: 此类平台主要为其他方向的内容服务，例如产业、行业、物体等定义性的内容。此类平台包含智慧农业、智慧商务、智慧旅游、智慧园区等。

2）指挥中心和智慧平台不同，平台主要为目标（工作目标、民生目标等）服务，指挥中心为领导服务。

通过大屏、数据分析、报表、周月报等形式为领导提供决策支撑，直观掌握城市运行情况。

此类中心包含运行管理指挥中心、舆情中心、预警中心等。

值得注意的是，现有政务体系的决策支撑产品化内容更多的只是数据的可视化，个人认为并没有达到一个数据分析的可视化，分析的能动性大部分还是需要用户自身驱动，但是用户的时间和信息化水平是否能够用好呢？这是个需要思考的课题。

3）专题专项主要是为了重大的、紧急的、重要的任务服务，它和上述两个不同，专题专项更具备任务的紧急性和严谨性。

此类专题包含了营商环境专题、疫情防控专题、经济复苏专题等。

4）总结笔者认为，专题专项和平台之间存在场景或者业务的重合性，在建设过程中，如果是不同成员之间，那么紧密的交流和联系是必要的，切莫各自为战，应该是统一战线。

二、实施（微观）

第一部分主要从宏观上对于底座和应用的一些思考阐述，第二部分主要从微观上阐述模式和工作机制上的一些思考。

由于城市数字化转型的工程复杂，周期长，以及涉及关系较多，因此关于项目的模式，笔者仅以自身工作经验中浅谈其中的做法。

在笔者的经验认知中，有两种信息化项目的建设模式，分别为传统的项目模式和新颖的运营模式。

1）项目模式项目模式，即以系统需求和功能建设为导向，根据系统建设的软硬件需求和功能需求来进行立项。

在项目模式的过程中，笔者总结了以下2个遇到的问题：

①需求问题

因为立项方案的时间一般是早于需求调研的时间，因此很多需求或者功能的设计是基于拍脑袋的方式提出的，并不能完全贴合实际的应用场景。

但是，智慧城市的建设，特别是关于民生的建设，我认为必须是以用户实际价值为核心的。因此，这种项目模式会导致验收时的建设不符合预期的情况。

②服务问题

项目模式在一定程度上基本属于一次性的建设服务，最多就是附带几年的支撑服务，而且考虑到建设方的成本问题，支撑服务的质量一般。

但是，现代化城市的发展是迅速的，如果建设的平台不能够跟上城市化发展的进程，如果该建设需求不是非必要性的场景适用，总有一天是会被荒废的（即无效建设）。

2）运营模式运营模式，即以用户价值和用户服务为导向，根据提供服务的数量和要求以及建设系统的内容来进行立项的信息化项目建设模式。

值得一提的是，该模式并不是完全抛弃系统建设内容本身，它还是存在系统建设（软件功能设计），只是这块内容并不是方案的核心。

运营模式的好处在于，在方案的规划过程中，可以不必过于挖掘用户的更加细节的需求，而是先专注于思考为用户提供哪些方面的服务，它比项目模式更加的抽象化。

在运营模式的过程中，笔者总结了以下2个遇到的问题：

①指标问题

运营模式的难点在于，如何细分服务的内容，如何明确服务的边界，如何规划服务的框架以及如何量化服务。量化的核心在于项目金额的计算。这个可能非常考验参与立项的人员水平（因为涉及审计的风险问题）。

②边界问题

虽然运营模式弱化了系统建设本身，但是正因为弱化了此项内容，在项目的建设过程中，如何把握系统建设的边界，如何控制成本，如何规划项目建设的优先级，是一个比较棘手的难题。

由于智慧城市的主体包含管理者、应用开发商、系统集成商、服务运营商、第三方机构等，其中的复杂性笔者还不具备专业能力阐述。因此，下面仅以笔者经历过的项目角度讨论。

1）管理者管理者，项目的主要协调和决策者，一般是由政府承担。

管理者在项目的推动过程中起了很重要的领头作用。

例如在某省的智慧平台项目中，虽然是省政府重点关注项目，但是实际的管理者是省政府的组成部门（非办公厅牵头），虽然该部门在其中也具备很大的说话权，但是不乏有部门不买账，或者配合力度不够的情况。

因此，在项目的实际推进过程中，会存在和各行业机关部门的联系不够紧密的情况。仅仅只是牵头部门通过拟定标准，按照统一标准执行落地项目。因此，会导致用户的实用性并不是太可观，也会导致使用率不高。

再比如在某直辖市的智慧平台项目中，同样是市政府重点关注项目，和某省的不同之处在于，它实际的管理者就是市政府的内设机构部门，同时也会指定相应的组成部门作为业务主导方和技术主导方。

所有的项目推进和汇报都是以市政府的内设机构部门为主，在项目推进和部门联系上，虽然也会有一点的阻碍，但是不影响主要流程的顺畅进行。

2）应用开发商项目的应用开发商，一般是由企业担任。

某省的智慧平台项目模式中，“xx企业”是省级数字政府建设运营中心，它提供顶层设计、平台建设、业务创新等服务，其余的系统建设、实施运营等服务由合作的企业（生态伙伴）负责。

这种模式的优点在于，“xx企业”能够保障某省的数字政府项目的顶层统一性、架构专业性以及数据安全性，并且能够规范项目的交付流程。

缺点在于，首先是业务知识的薄弱性问题，“xx企业”因为重点聚焦于标准和统一，因此在业务的钻研上，还是存在一定的局限性。

同时，“xx企业”掌握着和用户沟通的直接桥梁，系统的建设方（生态伙伴）不能及时直接的和用户调研沟通，会导致建设方的需求设计质量和创新不够。

其次，交付周期较长。成也流程规范，败也流程规范，项目并不是一成不变的，项目落地过程中如果不能够及时的变通流程规范，会导致项目的交付周期延长，甚至增加建设方的成本。

某市的智慧平台项目模式中，业务部门（市的组成部门）作为业务的主导方和需求的把控方，技术部门（市的下属事业单位）作为技术的主导方和赋能的提供方，建设企业（厂商）作为项目的建设方，并且会参与市政府办公厅、业务部门以及组成部门的项目小组中，一起推动项目的建设和落地。

这种模式比较考验建设方也就是建设企业的专业性和标准性，即是否有足够的专业能力承担起标准的建设和项目的建设。

在建设的过程中，项目建设方需要不同角色参与并完成项目的落地，如产品、设计、测试、运维等。

以下是我所理解的工作机制模式：

1）里程碑首先是里程碑，里程碑是项目的核心。

该里程碑一般由项目管理者制定，由管理者界定每个时间点应该完成的工作目标，并且该目标通过发文的形式通知到各合作方，作为项目的推动背景（推手）。

2) 实施计划里程碑制定完成后，由建设方配合管理者细化每一个里程碑的推广实施安排，可以按照不同的维度分组或者分类，细粒到每一个涉及的单位以及时间点安排。

计划制定后，由管理者组织项目推广大会，并发函给各参与单位，在大会中明确项目的重视程度和对各单位的要求。

3) 倒排计划在实施计划的基础上，由项目建设方协同项目参与方确定更加详细的倒排计划。

该倒排计划制定完成后，固定周期内通过某种形式汇报给管理者及抄送给其他参与者，如果有计划的延期风险或者存在推进难度，及时组织会议协调解决。

4) 工作小组根据上述拟定的计划，组建工作小组，明确工作小组的责任人和联系人，定期组织项目例会沟通计划的进度和计划的风险。

5) 版本规划根据计划规划版本，在版本规划的过程中，可能会出现版本之外的需求或者任务，需要及时的进行动态调整以及汇报。

版本规划中关于角色职能的思考如下：

①项目经理（PMO）

项目经理分为对外沟通和对内沟通两个角色。

1. 对外的项目经理负责和客户沟通，和客户建立良好的沟通关系，及时收集和汇报项目信息。
2. 对内的项目经理负责项目的跟进，把控项目或者版本的进度，分解项目内容，合理规划资源，输出项目汇报材料等。

②产品经理等其他角色

各司其职的同时，需要产品同学拉通整个项目组的目标，即目标的统一性和业务的专业性。不能为了交付而交付，更重要的是应该达到各成员对业务都有一定的理解性。

总结：版本交付是一个因素变化很大的工作，特别是合作方多的情况下，最重要的还是如何把信息拉通以及如何预防风险。

三、商业模式

笔者认为，智慧城市的方向是为民，为城市运行服务。但是，服务的前提是生存，生存的核心是价值。企业如何在赛道中生存，如何提供更大的价值，是商业模式中重要的一环。

笔者建议，在项目落地的过程中，需要摒弃以交付为核心的理念，重视以产品为核心的理念。

因为，每个城市的市场、环境和条件层次不齐，如果需要把产品向外渗透，或者成为标杆，需要在打造智慧城市的项目过程中，尽可能的解耦每一个业务板块，让每个业务板块都具备独立运作的能力。

其次，需要尽可能的让平台具备通用性，或者，让平台具备高拓展性，这样可以尽可能的在其他城市中复制和改造。

值得一提的是，在政企的信息化服务范围中，笔者认为还是存在纯公益服务性的产品化内容，这类内容需要摒弃商业化的思想，从“公益服务”的角度出发，切实的解决人民的问题，从量化问题的解决下手，不断的投入和产生公益价值。

最后，在营收方面，是否可以从政府中获取的项目收入的同时，后续可以把标准化的能力或者数据包装成服务，对B端销售。

以上内容仅为个人在工作中以及阅读中的总结和思考，描述若有不当之处，还请批评指正，谢谢！

四、参考文献

《百度城市数字化转型白皮书》-刘捷、徐志发

《新型智慧城市设计与建造》-刘伊生

本文由 @小刘 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。