大家好，我是东华软件，我叫甘泉。公司介绍首先，请允许我介绍一下我的公司。东华软件原是2001年在北京成立的一家传统软件公司，现有员工约10000人，其中技术人员约7000人。但是这7000人不都是开发者，他们中的大部分都是实现者。因为在我们的软件行业，实施者的数量可能远远超过销售人员和技术人员的数量。东华的主要服务领域包括应用软件、系统集成、技术咨询和网络产品。其中，我们有四个比较大的业务板块：医疗、金融、能源和智慧城市。其中，东华软件智慧城市板块成立于2013年，在智慧城市领域算是比较早的公司；目前东华软件在全国建立了四个智慧城市研发中心。行业挑战智慧城市需要做的三件事我们把智慧城市行业称为G端——政府。政府端其实和B端有些相似，但又有所不同。我简单说一下智慧城市应该做到的三件事：善治、兴业、造福人民。善政就是实现政务数字化、信息化。一方面，让政府领导可以借助AIOC、AIC等城市运营大厅，掌控城市运营的方向盘；另一方面，实行一网一网统一管理，减轻政府基层工作人员的工作负担。惠民，为民提供方便。我们常说，一站式服务、无牌城市、健康码、智慧社区，都是惠民的应用。最后，工业发展，政府最关心城市的指标之一是经济指标。政府希望通过招商引资和政策沟通，让更多企业落户本市，让企业享受到在本市开展业务的便利。智慧城市的架构下图称为智慧城市的架构。这张架构图经历了几次演变，现在大概是这个样子。一般来说，从下到上分为IaaS层、PaaS层、Saas层。IaaS层一般和云、硬件相关。PaaS层一般称为中台层，我们称之为中台。中台可以分为应用中台、数据中台和智能中台。这就是腾讯所说的。阿里可以称应用中台为业务中台；如果是华为，可能还有别的名字，但是大家的结构都是差不多的。最上层是Saas层，包含各种应用。事实上，我们的政府客户并不关心这种架构。在做了很多报告之后，我发现架构师最关心的是架构图。他们认为这个架构图非常重要，因为他们像搭积木一样搭建一个智慧城市的架构，很多问题都可以通过这个架构来解决。如果一个问题解决不了，我们就加一层架构。后面我会说，像明道云这样的平台，一般都是在PaaS层——APaaS层之上。现在大家也觉得数据很重要，怎么办？让我们添加另一个DaaS层。智慧城市的“七大罪”在智慧城市领域，我们通常会遇到很多问题，而这些问题在我们的企业中也可能会遇到。我把它们比作“七大罪”，但可能不止七个。我将在此仅列出七个我认为更常见的困境。多样化定制。在企业领域，很多软件都可以产品化，这意味着软件不需要过度定制。但在政府部门，大多数软件都是高度定制的。定制会带来大量的人工成本，我们的配送成本也会增加。通常，如果我们只做一个软件产品，它的利润很容易增加；但如果我们每次都做定制产品，就很难获得高利润。时间不多了。这个问题通常在政府项目中遇到。你的委托人不着急的时候不愿意跟你说话，一着急就好像有政治任务压下来了，他可能希望你明天交付。做过政府项目的朋友可能也有同感。要求的变化。我们在做政府项目的时候，会面临非常频繁的需求变更。多常？也许这个月是一个要求，下个月是另一个要求。客户有时候并不在意你的合同有没有签，只要需求有变化，他们就必须跟着客户的变化，否则你的订单很难交付。而且，很多时候，并不是客户刻意要改变需求，而是来自上级政府的压力，让他不得不改变。在政府领域，许多应用程序对时间非常敏感。比如疫情来了之后，客户可能希望你在一周内上线应用。这个应用可能只能用一两个月，等疫情过去了就不用了。搁置了半年，疫情又回来了，这个时候他可能又想把这个app给拔掉了。这种需求经常发生。数据孤岛，我们也称之为“应用烟囱”。由于政府项目的定制化繁多，政府内部大量的软件都是项目化的。每个基于项目的软件可能由不同的软件供应商提供，每个软件供应商都有自己的体系结构。它做的系统是一个自闭环系统，与其他系统无关，只需要解决自己的问题。这样一来，数据孤岛的问题就不可避免地出现了。很多厂商都在尝试通过PaaS层来解决数据孤岛的问题，但是难度很大。重复施工。说来也奇怪，一般来说，省市政府下属有40到50个业务部门，每个部门都有自己的需求，而且需求会重叠。由于缺乏跨部门的沟通，这个部门做了一个申请，那个部门也做了一个类似的。有时，一个省下的每个城市都必须重复相同的申请。架空平台。刚才说了，我们引入中台就是为了解决上面提到的问题。但是后来我们发现，引用中台似乎并不能解决问题。因为不同的公司有不同的中台，任何一个“小烟囱”都会搭建自己的小中台。每个公司都想用自己的中台，不想用其他公司的中台，导致你搭建的中台有被清空的可能。难以迭代。其实很多时候不是技术问题，而是项目体系问题。通常我们在做项目的时候，都希望在合同签订后尽快交付，拿到尾款就可以了。最好不要改变客户的需求，不要迭代升级。项目交付后，任何额外的新需求和功能迭代都会增加交付成本。所以，迭代的难度也是我们厂商无法回避的。打破局面的方法面对这些问题，我和我的生态伙伴想了各种办法，提出了很多方案，但都不是最适合我们的方案。直到我们开始启用低代码或零代码等平台，我们才看到一些转机。在讲低代码和零代码平台之前，我想先讲一个方法论。向IBM学习这种方法论是我从我的IBM合作伙伴那里学到的一种方法论。他们做了一个非常有趣的项目，叫做IBMGarage（IBM车库）。他们在IBMGarage中实施了一种称为MVP的方法。这个方法论很好，很多大公司都在学，包括阿里巴巴、华为。这个图可以很直观的反映方法论的原理。以前我们设计汽车，可能先做轮子，再做底盘和车身。汽车最终设计出来之后，可能已经过去了半年甚至一年，但此时的汽车可能不太适合我现在的需求。那么MVP会做什么呢？让我们先做一个滑板车。虽然这款滑板车只有一块板子和两个轮子，但是你可以把它滑上去，让你尝到一点甜头。当你尝到甜头的时候，也会提出它的缺点，比如需要直杆。然后，它会演变成自行车、摩托车，最后是汽车。它的每一步改动都能让用户快速尝到一点甜头，有利于本项目的推进。这两种不同方式制造的汽车最终交付结果可能完全不同。一方面，后者可以让你以最小的成本去尝试和改正，因为当你做一个滑板车的时候，用户可能觉得不合适，然后你就得另寻方向。这就是所谓的MVP方法论。另外，我还了解到另外一点。IBM拥有超过1000个软件的庞大工具集，可能没有哪个软件公司可以说它拥有这么多工具。IBM的同事说：我们不可能告诉客户你的问题解决不了，唯一的可能是我们的方案不合适。那没关系，我们换一个工具，换一种方法，一定能解决你的问题。尽管如此，他还是给我讲了中国企业数字化转型（smarttransformation、digitaltransformation）的成功率：一般咨询公司帮助企业进行数字化转型的成功率可能连10%都不到。在MVP方法论和庞大工具集的支持下，IBM可能只能做到30%左右。智能改变转数是一件很难的事情，想改也不容易。如何有效推动项目实施MVP方法论加长后，我们可以将整个解决问题的过程分为六个步骤。一开始是商机收集和技术解决方案。这两个步骤其实就是我们对客户问题和痛点的理解。第二阶段是体验设计和架构讨论，是我们对痛点解决方案的探索。其实前两步过去不是软件公司做的，更像是咨询公司。最后一步是构建最小可行产品和部署生产环境。这两件事是我们软件公司通常做的事情。最后两步，我们需要有一个不落伍的工具。因为如果我们不能把计划快速的实现成产品，整个项目周期还是会拖很久。因此，这时候就需要探索一种新的解决问题的方法。我们设计了两条线，一条是高度成熟产品需求的研发线，一条是高度定制化产品的研发线。在高度定制化产品的研发路线上，我们还缺乏零代码或低代码的工具。在找工具的过程中，用了不下10个工具，找了很多资料来研究这件事。最后，我把零代码和低代码平台大致分为五类——B端平台、C端平台、IoT平台、地图平台、数字孪生平台、数据可视化平台。这五类平台基本上可以涵盖我们遇到的所有问题，而在所有的问题中，B端应用平台是我们面临最多的。经过一系列的选择，我们最终选择了明道云。一方面是因为明道云在我们心目中至少是前三名。另一方面，在与同事明道云交流的过程中，我有一种如沐春风的服务体验。特别感谢一直为我提供服务的程哲和孟晓。他们的服务意识让我最终选择了明道云。最后，当我提出BUG或遇到的问题时，明道云可以快速响应解决问题。这也是我选择明道云的重要原因。在实践中前进，因为即使是最好的工具也会面临实践的考验，因为客户不会为一个想法付费。那么，下面就是我们如何运用方法论和明道云来修炼。以前我们会为一个项目制作大量的PPT，平均一个项目有20多个PPT版本，就是为了让客户觉得我们的PPT能说出他的心声。但是现在有了明道云，我们找到了一个更好的向客户展示的方式。PPT还是不能丢，但是做完PPT之后，我们会马上为客户做一些苦工——直接演示我们在平台上搭建的demo应用，让客户真正感受到我们的POC。我们不是PPT公司，也不是来吹嘘我们客户的。某地的一个智慧城市项目，我们大概是今年4月份开始使用明道云，到现在已经四五个月了，积累了很多的应用。同时，我们也选择了C端平台Zion。我们为政府部门建立了城市指数、业务调研、办公审批、党建指导、应急防疫、一码通、环境监测、监督管理等应用。在面向行业方面，我们也有做过市场管理、资产管理、财务管理、薪酬管理等应用。第三类应用是面向市民的，包括社区管理、物业管理、社区团购、社区门店、疫情防控、智慧交通等，我们用了大约4个月的时间。我们在明道云和ZION上规划了153个应用，构建了100多个应用。这是我们真正做到的。单纯从时效性上来说，如果我们过去这样做，可能需要的时间是现在的十倍。能用这个低代码平台的人，现在已经有足够的开发能力“一打”了，所以我们可以把成本降得很低，但实际上我们不能降到1/10——因为我们发现我们有这样的capabilities其实他需要更高的素质，首先要懂业务，其次要懂一些编程。有的时候，我们甚至觉得低代码/零代码的平台提高了我们在东华整个应用开发的门槛。因为在实践的过程中，我们发现很多程序员根本就不想懂业务，但是想要做好低代码平台，就必须懂业务。要么培养懂业务的人学一点代码，要么培养懂代码的人学业务。探索永续经营的商业模式现在，我们的愿景是将东华的智慧城市项目经验打造为“智慧城市创新工场”。你为什么这么说？因为我们现在做的智慧城市和以前不一样。以前我们做智慧城市的时候，只需要把项目交付到一个省或者一个市。现在我们不仅要交付项目，还要为客户培养团队。这个团队将永远陪伴政府完成智能化改造的转型。如果这个团队逐渐壮大起来，政府可以把产品孵化出来，辐射到周边省市县，让这个城市的新兴产业多一个机会。现在，各国政府都在研究如何建设智慧城市。我们认为这是一个有利于政府智慧治理和智慧城市的解决方案。为了提供长期可运营的城市数字化服务，我们将以往的项目交付业务模式转变为持续运营模式。现在，我们去见客户，不再像以前那样讲PPT，或者给客户演示产品，或者展示我的解决方案或者高级架构图。我们会讲我们要做的事情，一是打造“易办、智办”的服务模式，二是实施“乐高式”建设。我们在明道云上构建的所有应用程序都是可扩展的，您可以选择或不选择。我刚刚提到IBM有1000多种工具可供客户试用。虽然我们没有那么多，但我们可以在低代码和零代码平台上开发很多智慧城市应用。目前，我们已经积累了100多个应用程序。我的目标是先做两三百个模型，这样无论我到哪个省市县去给客户做演示，我都可以说：我一定会在我的工作中找到解决你问题的办法。工具库。你觉得好吗？会用就买，觉得不好用就别买。这相当于我们对我们产品的信心。此外，这也是“惯用主义”的最佳实践。你为什么这么说？一方面，我们会惊叹我们过去做的很多软件，我们生态伙伴拥有的实践，我们竞争对手的产品，都是在零代码和低代码平台上重构的.其实过程并不复杂。另一方面，低代码零代码平台可以缩短项目交付流程，缩短你的产品化进程，成本也会更低。最后一个叫“小刀切、看时效、重操作”，这也是我们在政府部门提倡的。所谓“小切口”，就是刚才说的MVP晋升方式。其实我想很多企业用户也有这样的实践经验：我们不需要去规划一个大的应用，只需要用零代码的平台去解决一个个小问题。我的演讲就到这里，谢谢大家。本文来自东华软件顾问甘泉，曾在明道云2022秋季合作伙伴大会上发表演讲，经校对编辑整理成演讲精华。
