零代码平台在政府智慧城市领域的应用

大家好，我来自东华软件，我叫甘泉。

公司介绍

首先请允许我介绍一下我的公司。东华软件本来是一家传统的软件公司，2001 年在北京成立。现在公司已经有大概一万名员工，其中大概有七千人从事技术。但是这七千人并不都是开发，大部分是实施人员。因为在我们软件行业里，实施人员的数量可能远远超过销售人员和技术人员。

东华主要的服务领域有应用软件，有系统集成，有技术咨询，有网络产品。其中，我们有四个比较大的业务板块：医疗、金融、能源和智慧城市。其中，东华软件的智慧城市版块成立于 2013 年，在智慧城市里边算是比较早介入的公司了；目前东华软件已经在全国建立了四个智慧城市研发中心。

行业挑战

智慧城市要做的三件事

我们管智慧城市这个行业叫 G 端——Government。政府端其实和 B 端有些相似，但又有不同。我先简单讲一下智慧城市要做的三件事：善政、兴业、惠民。

善政，就是实现政府数字化、信息化。一方面是让政府领导借助像 AIOC、AIC 的城市运营大厅，把握好城市运作的方向盘；另一方面是实行一网通办，一网统管，为政府基层工作人员的工作减负。

惠民，为民众办事提供方便。像我们常说的一网通办、无证城市、健康码、智慧社区，这些都是惠民的应用。

最后是兴业，政府对城市最关心的指标之一就是经济指标。政府希望通过招商引资、政策通等方式，让更多企业到城市落户，让企业能够在城市里享受到营商便利。

智慧城市的体系架构

下面这张图叫做智慧城市架构图。这个架构图经过几番演变，现在大概演变成这样子。

一般来说，它从下往上分为 IaaS 层、Paas 层、和 Saas 层。IaaS 层一般跟云和硬件相关。Paas 层一般被叫做中台层，我们管它叫中台。中台又可能分为应用中台、数据中台、智能中台。这是腾讯的叫法，阿里可能会管应用中台叫业务中台；如果是华为，可能也会有另外一个叫法，但是大家的架构都差不多。最上面是 Saas 层，Saas 层放的是各种各样的应用。

实际上，我们的政府客户对这个架构并不关心。我做了很多回汇报以后，发现最关心架构图的是架构师。他们觉得这个架构图很重要，因为他们就像搭积木一样去搭建一个智慧城市的架构，而且通过这个架构可以解决很多问题。如果某个问题解决不了，我们就加一层架构。后面我会说，像明道云这类平台一般处在 Paas 层的上面——APaaS 层。现在人们也觉得数据很重要，怎么办？我们就再加一个 DaaS 层。

智慧城市的“七宗罪”

在智慧城市领域，我们通常会遇到很多难题，这些难题可能在正在我们的企业也会遇到。我把它们比喻为“七宗罪”，但可能不止七宗，还有更多。我这里只列举七个我觉得比较常见的困境。

多样定制。在企业领域，很多软件可以产品化，这代表着这些软件不需要过度定制。但是在政府领域，大部分软件都是高度定制化的。定制化就会带来大量人力成本的消耗，我们的交付成本也水涨船高。通常如果我们只做一个软件产品，它的利润很容易做高；但是如果每次都做定制产品，利润就很难做高。

时效紧迫。通常做政府项目都会面临这个问题。你的客户不着急的时候，他都不愿意搭理你，但是他一旦着急以后，就像有政治任务压下来了，他可能希望你最好明天就交付。做过政府项目的朋友可能都会感同身受。

需求变更。我们在做政府项目的时候，会面临非常频繁的需求变更。频繁到什么程度呢？可能本月是这个需求，下个月就是另一个需求了。客户有时候不管你的合同签没签，只要需求变了就必须跟着客户变，否则你很难把订单交付好。而且，很多时候并不是客户故意想要变更需求，而是上层政府下达的压力使得他不得不变。

在政府领域，很多应用的时效性非常强。比如疫情来了后，客户可能希望你在一周之内就上线应用。这个应用可能就用一两个月，一旦疫情过去了就不用了。搁置半年以后，疫情又回来了，这时可能他又要把应用拉出来用。这样的需求经常发生。

数据孤岛，我们也叫它“应用烟囱化”。由于政府项目的多样定制化，使得政府内部大量软件都是项目型的。每个项目型软件可能由不同的软件供应商提供，每家软件供应商都有自己的架构，做出来的系统是一个自闭环的系统，不和其他系统相关，只管解决自己爹问题就可以了。由此，数据孤岛的问题必然会出现。很多厂商都试图用 Paas 层来解决数据孤岛问题，但是很难。

重复建设。说来也挺奇怪的，一般来说，省一级、市一级政府的下面有四五十个业务部门，每个部门都有自己的需求，他们的需求会有重叠的部分。由于缺少跨部门沟通，这个部门做了一个应用，在那个部门也要做一个类似的。有的时候，一个省下面的每个市都要把相同的应用重复做一遍。

架空中台。刚才提到，我们引入中台是想要解决上面说的这些问题。但是后来我们发现，引用中台以后好像也没有解决问题。因为不同公司有不同中台，任何一个“小烟囱”都会建自己的小中台。每个公司都想用自己的中台，不想用其他公司的中台，这就导致你建设的中台很可能会被架空。

难以迭代。其实很多时候不是技术问题，而是项目制的问题。通常我们在做项目的时候，都希望在合同签完后尽快交付，把尾款拿回来就好了。客户的需求最好不要变来变去，也不要再迭代升级。当项目交付后，任何多出的新需求和功能迭代都会让交付成本提升。所以，难以迭代这件事也是我们厂商避之不及的一件事。

破局之法

面对这些问题，我和我的生态伙伴想了各种各样的解决方法，也提出了很多解决思路，但都没有我们觉得最好的解决方法。直到我们开始启用像低代码或零代码平台以后，才看到了一些转机。在讲低代码和零代码平台之前，我要先讲一个方法论。

向 IBM 取经

这个方法论是我从我的 IBM 合作伙伴那里学到的方法论。他们做了一个很有意思的项目，叫 IBMGarage（IBM 车库）。他们在 IBMGarage 里推行了一个叫 MVP 的方法论。这个方法论很不错，很多大公司都在学，包括阿里、华为等。这个图能非常直观地体现方法论的原理。

过去，我们要设计一辆车，可能会先做轮子，再做底盘和车体。最后把车设计好后，时间可能已经过去半年甚至一年了，但这时这辆车可能已经跟我当下的需求不是那么契合了。

那么 MVP 会怎么做？我们先做一个滑板车。这个滑板车虽然只有一个板两个轮，但是你可以滑起来，让你尝到一点甜头。在尝到甜头时候，你也会提出它的不足，比如说需要有一个直杆。紧接着，它又会进化成一辆自行车、一台摩托车，最终变成一台小汽车。它的每一步变化都能让用户快速尝到一点甜头，这样有利于这个项目推进。

用这两种不同方式做出来的车，最终的交付结果也许是完全不一样的。后者一方面能够让你以最小成本试错和纠正，因为你可能造出一个滑板车的时候，用户觉得并不合适，这时你就要寻找另一个方向。这就是所谓的 MVP 方法论。

除此以外，我还学到另外一点。IBM 有超过 1000 个软件的庞大工具集，可能没有一家软件公司敢说自己有这么多工具。IBM 的同事说：我们不可能对客户说你的问题解决不了，只有可能是我们的解决方法不合适。那么没关系，我们换一种工具，换一种方式，一定能解决你的问题。

尽管如此，他告诉我中国企业的智改数转（智慧化改造，数字化转型）成功率：一般咨询公司帮助企业智改数转的成功率可能连 10%都没有。在 MVP 方法论和庞大的工具集支撑下，IBM 可能只做到 30%左右。智改数转是一件很难的事，不是想改就能改成。

如何有效推进项目实施

把 MVP 方法论拉长以后，我们可以把解决问题的整个过程分成六步。一开始是商机采集和技术方案，这两步实际上是我们对于客户问题和痛点的理解。第二阶段是体验设计和架构研讨，是我们对痛点解决方案的摸索。实际上，前两步在过去并不是软件公司干的，它更像是个咨询公司的事。最后一步叫最小可行性产品的构建以及生产环境的部署，这两块才是我们软件公司正常要干的事情。

在最后两步，我们需要有一种不掉队的工具。因为如果我们不能快速地把方案兑现为产品，那么整个项目周期还是会被拖得很长。所以，这时候我们需要探索一种新方式去解决问题。我们设计了两条线路，一条是针对高度成熟化产品需求的研发线路，另外一条是针对高度定制化产品的研发线路。

在高定制化产品的研发路线上，我们还缺少一种零代码或低代码工具。在寻找工具的过程中，我用了不下 10 种工具，还找了大量资料去研究这件事。最终我把零代码和低代码平台大概分成了五大类——面向 B 端、面向 C 端，面向物联、面向地图、面向数字孪生，以及面向数据可视化的平台。

这五类平台基本可以覆盖我们遇到的所有问题，而在所有问题里，我们面临最多的就是 B 端应用平台。经过一系列选型后，我们最终选择了明道云。

一方面是因为明道云在我们心目中至少是前三的。另一方面，我和明道云同事交流的过程中，有种如沐春风的服务体验。特别感谢一直给我提供服务的程哲和孟晓，他们的服务意识让我最终选择了明道云。最后还有一点，当我提出一个 BUG 或者我遇到的难题时，明道云可以快速响应，去解决这个问题。这也是让我选择明道云的重要原因。

在实践中前行

因为再好的工具都会面临实践检验，因为客户不会为一个想法买单。所以，下面就是我们如何利用方法论和明道云来实践的过程。

过去，我们会为一个项目做大量 PPT，平均一个项目就有 20 几个 PPT 版本，为了就是让客户觉得我们 PPT 能讲到他的心坎里去。但是现在有了明道云后，我们发现了一种给客户演示的更好的方式。

PPT 还是不能丢，但是做完 PPT 之后，我们会立刻给客户上一些狠活——直接演示我们在平台上搭建的演示应用，让客户对我们的 POC 有一种实感。我们不是一个 PPT 公司，不是来给客户吹牛画饼的。

某地智慧城市项目

大概我们从今年 4 月份开始用明道云，到现在经历了四五个月，积累了非常多应用。同时我们还选用面向 C 端的平台 Zion。我们建立了面向政府部门的应用，比如城市指数、营商调研、办公审批、党建引领、应急防疫、一码通、环境监测、监督管理等等。

在面向产业这方面，我们也做了市场管理、资产管理、财务管理、薪酬管理等应用。第三类应用是面向市民的，包括社区管理、物业管理、社区团购、社区门店、疫情防控、智慧通行等等。

我们大概用了 4 个月的时间。在明道云和 ZION 上规划了 153 款应用，建成了 100 多款，这是我们真正做到的一件事情。单纯从时效上来说，过去我们做这件事情的话，可能要用现在的十倍的时间才能完成。

现在会用这种低代码平台的人，开发能力足以“一打十”，这样我们可以把成本缩减得非常低，但是实际上并不能缩减 1/10 那么多——因为我们发现具有这样的能力的人，实际上他是需要较高素质的，一要懂业务，二要懂一些编程。

有时候，我们甚至觉得低代码/零代码平台把我们东华整个应用开发的门槛提高了。因为在实践过程中，我们发现很多程序员根本不想了解业务，但是你想要把低代码平台做好，你必须去懂业务。要不你发展懂业务的人去学一点编码，要不你去发展懂编码的人去学习业务。

探寻可持续运营的商业模式

现在，我们的愿景是把东华的智慧城市项目经验形成一个“智慧城市创新工场”。为什么这么说？

因为现在我们做的智慧城市和以前不一样。以前做智慧城市时，我们只要给一个省市交付项目即可。现在我们不光要交付项目，还要给客户培育一支团队。

这个团队会一直陪着政府完成智改数转。如果团队慢慢扩大，政府可以把产品孵化出来，辐射到周边省市县，这样就可以给城市多一个新兴产业的机会。现在，所有政府都在研究如何做智慧城市，我们觉得这是一个对政府智政、智慧城市都有益的解决之道。

提供长效可运营的城市数字化服务

我们把以前项目交付型的商业模式变换成持续运营型的模式。现在，我们去见客户时，不再像以前那样，要么讲 PPT，要么给客户演示产品，要么展示我的解决方案或者先进架构图。我们会讲我们要做什么，一是打造“好办智办”的服务模式，一是推行“乐高式”建设。

我们在明道云上搭建的所有应用都是具备伸缩性的，你可以选用，也可以不用。刚才提到 IBM 里有 1000+工具可以给客户试用，而我们虽然没有那么多，但是可以在低代码、零代码平台上沉淀出很多智慧城市应用，目前我们已经沉淀了 100 多款应用。

我目标先做到两三百款，可以做到无论我去任何一个省市县给客户做演示的时候，都可以说：你的问题在我的工具库里一定能找到解决方案，你觉得好用你就买，你觉得不好用就不买。

这相当于是我们对自己产品的自信。另外，它也是一个最佳实践的“拿来主义”。为什么这么说？一方面，我们会把自己过去做的很多软件、我们生态伙伴拥有的实践惊讶吧、我们竞争对手的产品，都在零代码低代码平台上重构，其实过程并不复杂。另一方面，低代码零代码平台能把项目交付的流程缩短，把你的产品化过程缩短，而且成本也会打得更低。

最后一个叫“小切口，见时效，重运营”，这也是我们在政府部门推动的一件事。所谓的“小切口”就是刚才提到的 MVP 推进方式。实际上我觉得在很多企业用户里边也会有这样的实践经验：我们不用规划一个很大的应用，只要针对一个个小问题，用零代码平台去解决它就可以了。

我的演讲就到这，谢谢大家。

本文来自东华软件咨询顾问甘泉，在明道云 2022 年秋季伙伴大会活动演讲，经校对编辑后整理为演讲精华。