以下是现场速记。
上海爱湃斯科技（ClickPaaS）CEO 胡柏
胡柏：各位领导、各位朋友，感谢大家今天下午的时间。低代码、无代码可能是过去一两年发展非常快，概念被大家所知。实际我们在15年回国做这件事情的时候，整个赛道都是很冷的，无论是产业界还是资本界，对到底什么是模型化驱动，什么是低代码，其实了解并不多。
我在下面听，前面一位尚老师在讲在双碳领域，怎么去构建他们的信息系统?原来我在甲骨文，甲骨文当年有一个非常大的收购行为，收购了cibel，它被甲骨文并购之后，他就从甲骨文离职了，他做了一家共叫C3，做十年前美国的双碳、碳积分、碳交易的系统。他为什么转做碳交易?因为他没有固定化的场景，因为他整个业务形态一直在变化，所以他需要一个敏捷的平台，需要去连接各种各样的OT设备，甚至往后走要连接到人工智能，所以C3这家公司的名字最开始叫C3，后来叫C3.iot变化了C3.AI。
我讲一下整个美国市场对低代码、无代码看法的变化。我原来在美国甲骨文做研发，我15年当时我们有一个契机觉得应该要回来创业，把我们在甲骨文做的东西拿回来再做一遍，所以我们名字叫Cleak+PaaS。我们回来时跟美国专家谈过，大家对这件事情看法有各种各样的争议。
第一个争议觉得这件事情很难做出来，甲骨文花很大代价构建底层再投向市场，到底中国公司能不能做出来?这个是疑问。
第二个会不会被并购。
很有意思的是今年过年时，我在跟这帮原来美国同事聊的时候，大家看法完全变了，大家认为低代码或者模型化驱动方式，一定是未来所有应用软件这个领域的必然发展方向。
为什么?不单单因为疫情驱动。大家知道应用软件市场里，软件市场主要是应用软件市场。美国分两块，中国也是一样，另外是定制化应用，这两块市场在美国是一比一，美国标准化应用是SaaS化应用，这些公司已经发展很好了，而且SaaS在美国渗透率很高了，但中国的SaaS还很早。
反而在定制化市场里面，在美国没有特别好的一堆公司或者一堆产品来解决定制化的问题。中国市场跟美国市场有同有异，同的地方是我们这些嘉宾谈论的，中国中大型企业市场跟美国没有什么区别。大家对于信息化的投入量、投入金额，我曾经做过对比，同样一个项目在美国和在中国花多少钱，对比完发现几乎是一样的，没有任何差别。反而中美之间在中小企业市场领域差别很大，这是第一个相同的点。
第二个不同点是中国行业化和个性化对比标准化应用比例远高于美国，反过来也解释了为什么SaaS在中国发展有些问题的原因，这个跟日本很像。我研究生在日本读的，专门做企业应用的架构。日本市场也这样，基本大的企业全部需要量体裁衣，大的企业自己对业务的理解远高于软件厂商，它一定是要通过量体裁衣的方式来做，这是背后大的变化。这也是我们15年回国做这件事情根本的动力。
市场分三个层级：
第一个层级是头部市场，这些企业原来用甲骨文，用SAP构建其信息化1.0，今天有很多人讲低代码变成热点继中台之后低代码变成热点。实际在当年，我们企业构建信息化1.0时，真正的中台其实就是ERP，就是依托于甲骨文、SAP构建的ERP。
有一个有意思的现象，我15、16年前开始加入做这个开始，当时在美国服务中国的头部企业。当时的中国头部企业想法是跟国际接轨，第一个梦想就破灭了，希望能用欧盟对价业务实现，但是它的适配率很低，因为管理阶段都不一样。
第二个维度用上了，把甲骨文、SAP做底座，基于此做行业个性化的开发。80%以上的需求，都是二次开发出来的，甚至有些企业做到95%以上的需求是二次开发出来的。95%的功能用标准功能，为什么还用甲骨文、SAP?因为底座稳固、稳建，做起来很可靠。这个市场在中国已经足够大了。
再往下把用友、金蝶客户画像过来，这个代表了腰部市场，这个市场跟美国同类型的企业本质来讲没什么区别。
这张图我画了一下，给大家解释一下低代码是怎么来的?任何一个行业一定会有演化的周期，演化的路径。大家知道我当时在读高中时，我们那时开始写代码，写应用程序，写程序时，你需要对硬件懂得，要知道硬件存储逻辑，那时你不是程序员是数学家，但慢慢的应用开发的模式开始变得抽象，接近于真实世界，脱离于真实世界。到10年时，用pason语言去写。在10年之前中国所有做应用科技的公司，基本遵循美国框架路径，美国人干啥我们干啥，它引领了我们的方向，中间可能差五到十年。
10年之后有个分水岭，10年时我们中国出现中台，我那时在美国，我当时美国同事问我们到底什么是中台?我当时说我也不知道中台是什么。但当时整个方向，无论做业务中台、数据中台还是什么中台，全部往这个方向走。但美国人没有做这个事情的，美国人干什么?美国人10年之后方向，他认为应用软件的核心价值并不在于代码的形态，不在于用java还是用PHP写，它的核心价值在于背后的业务模型、领域模型，背后的业务逻辑最关键。软件工程理论上等同于建筑工程。
前段时间人社部发了一个公告，很有意思定位程序员属于农民工一类，其实有这个异曲同工之妙。在建筑工程领域价值已经显性了，真正聚焦价值部分是在前面设计部分，我的建筑师、设计院设计好了建筑性、结构性。最后施工时是交给哪家施工，本质差别没那么大，大家都是相对规范完成的。
但是软件工程不是这样的，你去交给不同的人去做，而且你要交给一批P8级的农民工让他去干，这些人的技能还有他的组合差异非常之大，最后呈现的结果差别也会非常大。
美国也发现同样的事情，我在美国工作了15年，大家一定不要妄自菲薄，觉得美国一定在数字化方面多么先进。绝大多数行业，跟中国一样都是传统行业或者制造型行业，传统行业在跟先进行业竞争人才时都处于劣势，美国很多行业数字化转型也痛苦，他希望找到好的途径帮助他加速和变革。
我这张图也解释了一下我们在做这件事情的时候，15年回来的时候的思考。这个图现在已经慢慢被验证了，大家可以看到横坐标表示的是你做这件事情是简单场景还是复杂场景，这是一个分水岭，一个维度。另外一个维度，你做这件事情的代价，你的代价是你要花很大代价还是花比较小的代价来做?
今天第一类的场景，比如说我们今天大家如果做一个网站或者说你做一个调研问卷，其实市面上已经有很多工具了，你已经不需要程序员，不需要写代码了，这个是单应用场景，它已经完全脱离应用代码了。
第二个领域是当你做相对来说轻量化以协助为导向的，通过excel表方式可以实现多场景，但是它以协作为导向，以部门级以下的方式来做，这个在国内非常多，在美国也有很多这样的公司来发展。但它很难做到企业关键和核心应用，真正在企业里能够解决企业关键、核心应用还是那些传统应用型软件，不管它是本地部署还是走向了云原生化的模式。这些产品和方案遇到的问题，第一它构建时代价很高，第二当这些产品进入到比较大的企业里面时，最后一公里全代码化的，没有人完全用标准功能，一定会有大量的二开，这个二开代价又会变的非常高。
所以我们回国做这个事情非常难，第一我们要解决复杂业务建模，第二对技能门槛要求降低。
前段时间我跟美国同事在聊的时候，他们有一个很有意思的判断，他觉得应用软件市场经历了三代的变化，大家知道应用软件并不是上百年的市场，因为它原来就是IBM、甲骨文、SAP，就是七八年的时间，第一代软件，老外叫大一统软件，什么都有，用我的东西就行了。
第二代就走向云化、碎片化，每一个功能做碎化，通过连接方式构建应用。但有一个问题它解决不了核心应用的问题，在美国核心应用系统还是在用甲骨文、SAP来解决它的核心业务。
到了第三代老美认为他们进入到可组合式的平台，它背后是四件事情构成的：领域建模，我这个平台可以通过领域建模方式构建我的应用场景;AI，一定有AI人力在里帮助做预测和优化;当不能解决信息孤岛时用RPA;事件驱动的模式，会把事件驱动的技术放在里面。我们当时做这件事情的时候也是按照这个思路往前走。
我这张图给大家解释了一下这个行业是怎么分割的。大家可以看到这个背后有三个台阶，其实这个市场就分三个台阶，从技术角度量化来看分三个台阶。
第一个台阶当我们做轻量化应用，通过表单级应用来做的时候，通常情况下它的复杂度，单级复杂度是5到10张表，相当于用excel表里的列签是5到10个。第二类基于模块化构建的产品，就像aPaaS，它背后的最小元素其实并不是表，它最小元素是业务对象，它是通过业务对象，有点像当年的c++对象编程方式来抽象这个世界。一个业务对象对应多张表，但是为了横向比较当做一个东西，我们做的场景能做到500个左右的业务对象的复杂度。
我们看到这些头部企业他们做的这些场景，依托于SAP、甲骨文，主要依托SAP，开发长单体应用复杂度可以5千到1万张表。
表单级应用，它需要如果往上走就有难度了，结构导致它不太能往上走，所以需要单独建产品线。
我们在过去两年时，已经在头部央企里还有包括金融机构里已经站住了，有机会给大家分享，我们怎么在金融机构里面站住。他们对我们的要求已经不是技术问题，它已经跨越技术问题，技术问题必须要解决，比如替换SAP这些场景。最关键的第二步也是隐性门槛特别大的，它的稳定性、可靠性、安全性、可控性包括信创，这样的代价极高的，这是过往两年我们跨越的事情。
我简单讲一下我们是怎么做的，用简单的demo来讲一下。模型驱动背后并不是一个新东西，老美在实践开发领域实现30年的方法论，不单单SAP、甲骨文这么设计的，包括像SaaS公司都是这么设计的。它背后有几个基本逻辑：
第一个逻辑要把领域模型画出来。原来讨论业务模型时拿出个白板写成文档交给程序员开发。现在白板里把业务模型画出来，通过这样的方式构建出第一步业务的领域模型。
有了这个东西之后再往下你要构建你的数据结构，相当于盖房子一样，跟建筑工程类似。第一要有建筑师设计房子的功能性，第二要交给设计院设计房子的结构性。数字结构交给设计人员把这个画出来而非写代码写出来。
这个是怎么做页面，怎么做移动端，这些我们都做了。而且更多的是国内移动端它的要求比国外更高，大家现在都是用微方式启用钉钉、飞书等，这些我们都做了。而且国内对AI要求比国外高，国内大量UI接受了开源的设计库模式。
再往下就是流程的设计，你做完这个系统之后，会有流程设计。不单单有大的业务流程的设计，比如业务场景到了每一个节点都会控制点，但是每一个控制点之后，到了具体一个事项，一个事项背后系统干很多事情，同时要干四五件事情，原来的模式是通过BMP模式之后大量写代码，我们的设计模式或者老美的理论，在新的模式下也是通过图形化的方式，通过条件是什么，操作是什么?
一条一条的把它罗列出来。这样的好处在于它降低技能门槛，实现技能要求。第二因为现在系统大量迭代，你今天给业务部门看完要求改，过一段时间又要求改，换人接的时候很容易读懂前面的人做了什么东西，把原来迭代的成本跟技能要求大幅降低了。
再往下是怎么解决集成的问题，你在企业里光做应用不够，一定大量集成。这是一个真实案例，我们怎么跟SAP集成的，怎么同步，做物料的集成?我们的方式SAP有自己的巴比接口解析掉，相当于德语翻译成英语。另外一个系统肯定有自己的API，API订阅了自己的规范，我们把另外一端系统API解析掉，可能说日语的也翻译成英语，翻译完之后人需要干的就是你要做数据匹配，这边叫订单编码那边叫平台ID，这个需要连起来，连起来之后就可以帮你把集成自动生成，后面就是集成的管理等配置化实现。
这样的话，大大降低原来做这件事情的时间周期和要求。原来做主数据通常是程序员开发五天完成，现在可以在十分钟之内就可以干了。
怎么扩展?任何一种方法论、工具、产品一定会有边界，不可能没边界。但是我们服务的这些客户，它必须得达到要求，所以当你在建模的情况下，建模的方式不能满足客户需求的时候，我们可以支持客户来写代码。我们可以生成一个在线的开发环境，你再根据你自己喜好的方式、方法不管Java还是什么，写完之后我们管理你的参数，我们按照规范进行管理，自动化测试要通过，通过之后就可以连到系统里。
我们做过很多像城商行系统，它的整个算法是黑盒的，通过代码方式写然后连进来，领域模型不能解决算法的问题。
后面是报表BI层，BI层不用多讲了，这个很常见。我们有很多企业有自己的BI工具，可以把数据往外传，有一些不愿意用第三方BI工具，自己来做非常方便。
后面是非常重要的一点是环境管理，美国非常重视这一点。无论是甲骨文还是SAP在IT环境监测领域，它做了很多工作。这件事情我们也拿来复制了一遍，我们可以做到有正式环境，正式环境之后我点一个按钮，可以生成多个沙箱环境，然后在影子模式里做测试、开发，把你的新功能从沙箱环境发布到正式环境，发布过程中一旦有了问题，因为在环境管理时会有各种各样的环境情况，我们可以做到你的整个版本回归，保证你在版本发版时的安全。
现在的应用系统迭代非常快，它不像原来，原来我们做甲骨文、SAP的时候可能五年一个变化，今天可能是一个月一个变化，我们见到很多头部企业两周要升级一次，加新功能迭代，这个迭代是业务环境是导致的。高迭代、高版本发本的情况下对环境安全考虑也是重中之重。
这张图讲了我们做了什么事情?第一个是高性能PaaS，除了对于可控性要求之外，还有一点我们通过建模方式构建应用系统。你今天用汇编语言写，你的效率一定比用C语言写效率高，C语言效率比java语言效率高。当你的模型特别复杂的时候，要支撑运行，必须用高性能PaaS进行支撑，我们回国时就解决掉了这个问题。
基于这个之上，我们做了应用搭建的PaaS，我们怎么基于领域建模，把业务模型画出来来构建业务系统。怎么通过建模的方式解决掉集成的方式。
我们在国内有产品级伙伴，我们被OEM，他们拿去被产品的，有很多变成SaaS公司，也基于信创公司，拿我们东西去服务银行、服务机构。
这个市场里，美国有三类公司在做：第一类是mx公司，它蛮多年了过往几年发展都比较快，他们原来都是在欧洲公司，在欧洲诞生美国快速发展。第二类是云巨头公司，美国微软15年时提出offcie+team，另外一类是金融、政务、医疗三大行业。
我们回国之后定位做大型企业、复杂场景，而且我们已经进入到了在央企核心场景里进行替换，我们是国内官方市场的。
我们在过往几年服务了很多央企，帮他们出海，在海外帮他们做各种各样的产品替换，还有服务的外资企业，我们已经服务了46个国家，15万企业用户，帮他们去做各种各样的独特系统，不是常见的标准化应用系统。
欢迎大家有什么问题欢迎找我们沟通，这个市场包括这个方式一定会是很大的变化，今天路上的时候我看了一下赵薇的事件，整个中国政治经济包括社会在变革，软件行业、技术行业都一样，它有很多的技术变革点。模型化、可视化一定是未来很大的变革点，不管未来是什么样的软件形态，不管是做各种各样的应用，一定会或多或少采用到低代码或者模型化的技术。
谢谢各位!
京公网安备 11010502049343号