写点什么

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

作者:明道云
  • 2022-12-15
    安徽
  • 本文字数:5166 字

    阅读完需:约 17 分钟

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

公司介绍

首先请允许我介绍一下我的公司。东华软件本来是一家传统的软件公司,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 年秋季伙伴大会活动演讲,经校对编辑后整理为演讲精华。

用户头像

明道云

关注

还未添加个人签名 2020-07-13 加入

明道云(www.mingdao.com)是一个帮助企业快速搭建个性化业务应用的APaaS平台

评论

发布
暂无评论
零代码平台在政府智慧城市领域的应用_明道云_InfoQ写作社区