旗下微信矩阵:

为什么低代码行业长不出大公司?

理想的状态是,低代码能将所有与应用开发相关的活动,都收敛到同一个平台,从而产生更多方面的聚合效应与规模收益,但事实的发展却并不顺利。
2022-10-11 10:41 · 微信公众号:新眸  鹿尧   
   

当企业把数字化转型提上日程时,*意识到的往往是战略需求,而不是业务要求。随着转型由浅入深,速度和质量决定了生死,这时候才发现现有的开发工具与开发方式,管理水平及人才配备,其实很难胜任新的生产需求。

之前有数据统计,从转型成功率上看,信息化程度较高的行业小于26%,而传统行业只在4%~11%区间。为了解决这个问题,行业里常规的逻辑,企业如果要真的跨越周期,必须先使用合适的新工具,无论是云计算、Serverless、各种Xaas,目的都是为了理想化的降本增效,低代码也是同样的道理。

Gartner认为,未来企业间互动、需要更多的设备接入,业务会更加分散,专业开发者的数量并不足以满足企业IT需求。供需矛盾间,可视化+拖拉拽的低代码平台能让所谓的平民开发者,即普通的业务人员也能进行应用搭建,成为平台的最终用户,写更少的代码,花更少的钱,干更多的事,这看起来非常诱人,而且蕴含了巨大的商业前景。

2018年是一个有趣的节点,随着OutSystems成为超过10亿美元的新晋独角兽,低代码概念也被大量曝光,国内低代码赛道在近几年也尤为火热。

中国低代码行业投融资事件汇总

图源前瞻产业研究院

之后,从2019年阿里把内部产品宜搭正式对外商用,到两年后发布低代码开发聚合平台“钉钉搭”,腾讯上线微搭,华为有AppCube,百度有爱速搭,大厂之外,传统ISV躬身入局,一大批创业型选手也纷纷涌现。相比国内,国外巨头的布局更早,微软、谷歌、亚马逊都将低代码看作未来,也都拥有自己的低代码平台:PowerApps、Honeycode和Appsheet。

理想的状态是,低代码能将所有与应用开发相关的活动,都收敛到同一个平台,从而产生更多方面的聚合效应与规模收益,但事实的发展却并不顺利。

站在2022年这个节点上会发现,同为企业服务里的细分赛道,虽然近年来跑出不少低代码玩家,但既没有产生像erp里的用友、金蝶,更遑论crm领域的salesforce以及协同办公里的zoom。反而传出的更多是被收购的消息,比如西门子收购Mendix和TimeSeries、Magic收购PowPow、字节收购黑帕云。考古微软2005年开始投入的webform,InfoPath等工具,也早被时代淘汰,现在一些寄生大厂生态的明星厂商,名声并没有如雷贯耳。

愿景是美好的,不过现实中类似“低代码是不是伪需求、是否能真的商业化”的质疑声也一直不断,尽管理论上降低了开发门槛,但怎样让客户真正用起来,低代码还是难以实现纯粹的产品化推动。平台如果预设是代码小白,牺牲上限换短期效率,不仅会限制平台成长,是否真的增效也不一定;如果提供给专业开发者,作用又难免鸡肋,更不必说昂贵的变革成本。

为什么低代码里至今没有keyman,归根结底,这并不仅是战略层面拍脑袋能解决的问题,除了开发阶段,还要考虑产品的全生命周期,如果将价值认定框在降本增效的标准里,其实不太符合现实商业原则;数字化转型的过程中,风很大,具体到产品、市场、业务、用户、特定的应用场景,有太多的细节需要重新考虑。

01、厂商看技术,甲方看业务

模块化、可视化的编程方法由来已久。20多年前,微软的Visual Basic、Access以及Sybase PowerBuilder、Delphi Builder等编程工具风靡一时,都算作比较早期的低代码工具,多年来热度起起伏伏,很多人认为,如今不过是用“低代码”这个新瓶,装了表单、工作流、业务对象等旧酒,包装成面向业务应用层的低代码平台,本质仍是个OA自定义表单和自定义流程引擎而已。

到2020年左右,广义上的低代码开发平台包含低代码与无代码,前者面向程序员,后者提供给没有编程基础的业务人员,用友副总裁罗小江认为,“3-5年内可能低代码平台主要还是针对专业开发者,混合开发模式能够简化一些基础问题,程序员在此基础上做复杂开发。”低代码的成熟度,还停留在需要技术人员在一线业务员和开发商间做沟通的程度。

实际上,现在对于低代码的各种技术界定、渲染的实际意义不大,它的核心是为了解放生产力,那么业务逻辑比开发逻辑更重要。低代码之所以受市场追捧,源于数字化转型阶段的业务与产品供需矛盾。

当深入到具体业务会发现,现在的商业链条很复杂,比如从供货端、各种营销渠道,到各个电商平台推广卖货,现有的进销存软件并不能整合管理从收集订单、组织生产,到调派库存发货的不同平台订单数据,也不能分析销售情况进行客户追踪。

于是,有预算的企业想要自己开发软件,但在需求、交付时间、质量都不可控的情况下,供需问题短期内很难解决。回到一开始,任何的企业软件都只是技术手段,技术最终要解决的是业务和管理的问题。所以,真正要讨论的就变成了低代码是否真的好用,商业化落地是否可行。

比如在C端,消费者的需求千变万化,供应商是很难靠卖纯粹低代码平台来赚钱,加上用户的产品认知度不高,市场教育成本不容忽视;为了维持基础能力,要兼顾定制的灵活性和运行的高性能,因为使用的人越多,边际成本才越低,这些对一般初创厂商来说压力山大。

如果在B端,考虑是否真的给企业客户降低了成本,并且满足个性化需求,这意味着企业结果导向。市面很多产品都是固定化流程设计,功能缺失或冗余难以避免,比如当你买了一个进销存系统,但当想统筹管理人员绩效时,就得去买另一个,这种情况下的理想场景是,企业人员能够按需自行设计多场景系统,听起来似乎更实用。

大企业的业务流程、数据逻辑往往按照业务规范去做,低代码平台加上成熟的解决方案,可以更快捷地搭建;但受限于服务能力边界,低代码有明显的天花板,它无法替代当下的中、高级开发工作需求。中小企业的使用意愿也会被高估,即使用轻量化场景来,满足这些业务逻辑更简单的企业,除了搭建成本,还要因为业务不规范的“削履适足”,低代码反而不容易应对。

现阶段,不论在C端还是B端,在业务还没有实现标准化,数据也没建立标准时,低代码平台都不可能满足任意复杂度的业务,这也让它的应用场景被局限在那些只能被标准化的领域里,完成业务的全面覆盖更不现实,还会对企业的数据治理、信息安全产生隐患。

敏捷、普适、丰富的场景、性价比高,这是每一个低代码厂商在宣传自家产品时会用到的ppt话术,也是资本喜闻乐见的故事。不过作为入局者,钉钉、用友和简道云的相关负责人都曾表示,低代码市场的宣传是有些言过其实的,拓荒的过程很艰难,目前的渗透率极低,在所有的行业里渗透率基本上都是个位数,甚至仅仅1%、2%。

中国低代码市场渗透率低

图源洞见研报

在数字化浪潮中,RPA赛道的玩家们也正在经历类似的事情。由于低代码环境弱化编程需求,RPA市场边际扩大,并被认为是全球增速最快的细分软件市场,仅今年上半年,以达观数据、影刀为代表的国内RPA厂商累计融资金额达20亿,相关企业注册量接近400家。

但相较国外各领域对RPA的应用已经成熟,比如UiPath虽然验证了商业模式和落地场景的可行性,但国内的厂商仍在找试验田,具体到哪些业务流程适用RPA机器人,产品应用范围、边界及周期怎么定,市场还未实现规模化验证。加上产品功能的单一同质等问题,以至于国产RPA厂商客户年流失率平均在30%,远高于国外。

低代码和RPA的高开低走,其实不难理解,我们很多时候对于一个新兴概念的热捧,要远高于产品彼时存在的实际价值,即使它被认为是发展潜力巨大的风口,但在早期阶段,缺乏本土市场验证的情况下,产品是没有普适性的,更不是企业用来加速适应市场的“*药”,与其忽视市场的复杂去盲目照抄,或者积极炒作甚至削足适履,都不如在适当的阶段做恰当的事更合时宜。

02、从低代码平台到生态

今年上半年,低代码厂商黑帕云正式停服,从被资本热捧到被字节收购,黑帕云是赛道热潮中*退出的玩家,这件事也被看作国内低代码行业洗牌的开端。

低代码厂商图谱

图源艾瑞咨询

在停服之前,有人评价黑帕云是综合能力*用的轻量级数据协作工具。刚上手的时候可以直接当作Excel用,但它本身不仅比Excel更容易理解且支持协作,数据保存的完整性上也表现不错;接着在使用过程中加深对业务理解进一步升级业务系统,也就是说,软件本身并不是最重要,对业务和数据的理解、从而让业务系统不断生长的过程才是最重要的。

收购后不久关停,有人将原因归为飞书的核心产品多维表格,后者功能与黑帕云类似,虽然字节在低代码领域行事低调,但多维表格本身也是低代码的一个体现。飞书向来采取all in one 的策略,大客户的需求大多由飞书自己来做,随着业务的深化,用低代码去满足海量需求可以算是布局未来。

互联网巨头都在低代码领域加紧布局,像黑帕云的例子并不鲜见,虽然小企业的品牌变现能力对于大厂来说并不诱人,但沉淀下来的核心技术、产品理念和经验的确是有价值的。这也反映出,在本身冲突就很多的低代码赛道,走中小客和PLG增长这一路线的小团队,想要实现商业变现难上加难。

阿里的思路不太一样,在赛道之外,低代码起着“连接”和“高效办公”的作用。草蛇灰线,从2019年张勇首提“商业操作系统”,希望帮助企业实现品牌、商品、销售、营销、渠道管理、物流供应链等多环节的数字化;次年,钉钉升级为大钉钉事业部,并融入阿里云智能事业群,钉钉成了云服务的平台。

钉钉推出的低代码开发聚合平台”钉钉搭”,聚集了宜搭、简道云、氚云、轻流在内的8款主流低代码厂商,金蝶、用友、纷享销客等也是钉钉生态一员。与其说是细分赛道里的低代码平台厂商,钉钉更像一款协作办公平台,基于协同密度来建设应用生态,这样一来,对原有的存量系统服务,面对复杂且分散的业务,钉钉起到连接器和整合的作用。

同一时期,用友完成ERP到BIP,从产品服务模式升维到平台服务模式。2020年发布的低代码平台YonBuilder为用友自身、伙伴、客户的应用开发提供统一开发输出的能力,帮助用友BIP实现商业落地。YonBuilder的存在和后来加入的APICloud,完善了用友的服务链条,和钉钉主打平台及应用生态不同,用友侧重开发者生态和低代码产品。

在传统软件转云的厂商,和互联网玩家纷纷进军低代码的情况下,构建生态成为共识,意味着现阶段很难出现直接对标Airtable、Notion的独立产品。这类似曾经国内爆火的BI赛道,随着大厂BI产品销声匿迹,大部分独立BI厂商以被收购、退出市场或抱团取暖收尾。同样作为一种辅助性工具,从狭隘的定位上,低代码是否会重蹈覆辙还需观望。

03、比起开发,说搭建更合适

如果打开知乎搜索低代码,会发现很多人的字里行间不乏抱怨。“别的不说,单就工作量是一点都没有减少,反而平添了很多很多的麻烦,不用‘低代码’平台分分钟就能开发出来的功能,用了之后得花更多的时间。”

因为目前大部分低代码平台都是高度封装,高度耦合的开发模式,所有功能必须得按照平台既定的规则开发,假如只是简单的增删改查,导入导出,聘一堆薪资不高的外包去用低代码写重复度高的业务,那确实是没有问题。一旦遇到客户有类似五彩斑斓的黑的要求,平台现有的功能又无法满足,很多人连Excel都不会用,更别提改代码,最后只能是做开发的人来返工。

虽然不论是Gartner还是IDG,市场都对低代码的未来表现高度热情,但局中人冷静发言,“它既不是模式的问题,也不是资本问题,而是赛道问题。低代码产品好像什么需求都能做,但是好像每种需求又做不好。”简道云联合创始人单兰杰认为,低代码*的问题,是这种产品形态怎么能够持续地满足客户需求。

确实是这样,低代码可能会是程序员的一把工具,但不会成为颠覆行业的东西。正如前言,同为企业服务里的细分赛道,低代码这一支尤其分散,看似每一项业务都能适配,但实际的业务用途目前还是狭窄,大多限于简单的行政类、人事类需求,例如工作流和表单流转,大软件的部分功能延伸,面向企业用户的快速补充开发。企业的核心业务如生产、销售、采购库存等,还是要用传统的erp,这些很难用低代码去实现。

它的出发点是好的,我们倾向认为低代码弥补中小企业开发人员数量上的不足,但开发是一回事,能用起来是另一回事。低代码能力是否会变成一个与Office套件一样普及的基本办公职业技能,尚不可知;未来是继续加功能,还是开放更多的接口,做交付动作满足需求,还是产品保持简洁,通过一些其他模块,或应用市场的方式去解决问题,这些也不好回答。

【本文由投资界合作伙伴微信公众号:新眸授权发布,本平台仅提供信息存储服务。】如有任何疑问,请联系(editor@zero2ipo.com.cn)投资界处理。