文/明道云创始人任向晖

Gartner在上月底发布了中国低代码平台市场竞争格局报告（Competitive Landscape：Enterprise Low-Code Application Platforms in China）。这是Gartner针对中国市场为数不多的Competitive Landscape报告之一，足以显示这个细分市场当下和未来的重要性。

Gartner一贯以来是把No-Code产品排除在LCAP范畴之外的。但这次将零代码和业务开发者导向的CADP（Citizen Application Development Platform）明确包括在细分市场内，算是一个比较大的调整。除了CDAP以外，Gartner把金蝶、用友这类应用厂商的延伸开发平台，以及云计算公司的低代码工具产品一并纳入。因此，这份竞争格局报告相对完整地包含了所有为提升应用开发和部署效率目标的多样化产品和厂商。

1、市场构成

Gartner用了韦恩图来表达四个细分类别厂商的分布我认为是非常合理的。低代码开发平台，零代码应用平台，应用厂商和云计算厂商出于不同的动因进入这个市场，但是满足的是客户“快速应用实现”的共同目标。

主要力量：LCAP & CADP

Gartner在报告中声称中国市场的CADP产品要多于LCAP产品，竞争更为激烈。但我的直观感受并非如此。在报告附录提供的代表厂商列表中的实际分布也不相伯仲。实际上，我从市场上观察到的主要玩家大多数应该分到LCAP范畴，甚至云计算平台厂商和头部应用厂商所实现的平台产品，大多数也是采用的LCAP产品固有的画布模式（Canvas Model）。在全球产品中，几乎只有微软的Power Apps兼顾了模型驱动和画布两种模式。

很多读者还是对模型驱动和画布模式之间的区别有困惑。这组概念虽然是微软产品提出的，但是它们的确准确体现了LCAP产品和CADP产品之间完全不同的市场假设和实现路径。

LCAP产品假设：开发重复工作太多了，我们要让程序员减少代码编写量。

CADP产品假设：很多应用都没有必要代码开发，我们要让更多人能够配置出应用来。

应该说，这两个假设都对，也都有各自的价值。因为这个初始假设的不同，两类产品必然会有不同的初始用户群体，解决不同类型问题时适配度和成本存在差异。但这些都只是每一个厂商和产品的开端。随着产品成熟度的不断提升，两者之间必然会发生相互的借鉴和交叉。也就是说，两种定位的产品从不同的动因和初始条件出发，但最终都弥补了自己的缺陷，提升了客户需求的满足能力。这一点，Gartner在竞争挑战和建议中也明确了方向。

2、竞争情况

Gartner认为整个LCAP市场在中国还处于早期阶段，原因在于中国市场的碎片化和产品成熟度较低。报告列出了在中国市场参与竞争的若干挑战，包括：

（1）本地应用和生态的碎片化

（2）对全球性供应商合规的要求

（3）对多云部署、私有部署能力的支持

（4）客户企业IT成熟度的多样化

（5）多样化的产品在跨细分市场交叉竞争

这些竞争挑战当然都存在，但我认为Gartner还没有道出这个市场突破的关键障碍。这些障碍至少包括以下几点：

（1）大中型企业对定制开发模式的依赖。这导致很多进入LCAP厂商额商机大多以某一个特定项目需求出现，而不是对LCAP平台产品的购买需求。虽然从去年开始，我们已经观察到不少企业开始显性地进行相关产品选型，但市场的需求特点主流还没有开始质的变化。我们可以从软件项目招标公告中包含“低代码”和“无代码”的项目数量上得出这个结论。

（2）中小企业市场的贫瘠。这意味着我们这类产品很难先从中小企业这个基石市场出发，向上发展。换句话说，这个市场的金字塔底部和中部却缺乏使用和买单能力。所以，即使是像明道云这样的CADP，也不太可能大量地销售给中小企业，更不用说昂贵难用的LCAP了。我们这些产品，要赢取大型客户的信任，只能直接硬上，这对产品路线图设计，特性迭代规划和研发进程管理带来极大的挑战，意味着大多数产品都需要在比较困难的生存环境下坚持三到四年的连续迭代，才能具备服务大型企业的基本成熟度。

3）产品开放性差，集成困难。Gartner提到应用和生态的碎片化问题。事实上，碎片本身并不是问题，问题是每一个产品要方便集成。北美市场的企业软件产品要比中国市场多得多，但他们在产品开发性方面做得好得多。几乎任何成熟的软件产品都有完善的公开API。应用厂商绝对不敢在接口服务方面设置壁垒。这个开放性问题也制约LCAP和CADP产品的发展，因为一旦我们这类产品要用来解决深入的企业业务问题，就不得不需要和其他系统进行集成。集成成本虽然占比并不高，但它是一个前置成本。客户在没有完成集成验证之前，就无法推进应用本身的实现。

Gartner的竞争格局报告并没有给出具体厂商的市场占有率和排名。但从提名厂商分布上看，Gartner依然习惯性地将国际产品列为主要厂商，占据了不合理的篇幅比例。在报告末尾列出的Sample厂商档案中，我也很遗憾没有看到任何一个CADP产品。这和CADP产品在客户中实际的应用普及度是很不相称的。

3、客户细分

Gartner报告还提到不同IT成熟度的企业应用LCAP的方式和用例。简要来说，Gartner认为IT成熟度较高的企业倾向使用LCAP来服务内部的事业单元，也会和Vendor一起来打造垂直行业能力；中等成熟度的企业由IT部门或者业务部门购买LCAP/CADP产品来支持内部的专业和公民开发者，并和外部咨询公司和服务商一起来实现技术能力和业务领域知识的互补；而低成熟度的企业则大多由业务部门完成购买，支持内部公民开发者或者依赖外部的ISV提供服务，CADP和云计算厂商的产品更多集中服务这个板块的客户。

这种依据客户IT能力成熟度来描述市场细分情况不尽准确。虽然有开发能力的大型企业IT团队会倾向优先考虑拥有低代码类别的平台产品，但公民开发、IT团队和业务团队融合是所有企业都有的诉求。所以，我认为有价值的市场细分标准不应该从企业的IT成熟度出发，而是应该从客户的需求性质出发。

Gartner报告也列举了LCAP产品目前常见的应用场景：

（1）定制业务应用（Custom Business Application）。包括构建业务职能应用，或者在Oracle/SAP等套件基础上进行定制。

（2）业务流程自动化（Business Workflow Automation）。这类应用一般要求与现有的应用进行集成，读写数据，并构建各种自动触发或者人工参与的业务流，比如文档审批、流程任务管理和案件跟踪等场景。

（3）行业数字化解决方案（Industry Digital Solutions）。综合业务应用和流程管理需求，打造围绕一个特定行业需求的整体解决方案。例如制造管理（EMS），物联网（IoT），供应链（SCM），产品生命周期管理（PLM），建造和物业管理等。

（4）表单和办公自动化（Form/OA Application）。满足公民开发者快速构建协同工作管理系统，完成必要的数据集成和创建统计报表。

这四类场景的确是我们这个领域所满足的骨干需求，它们甚至也是今天大部分企业数字化的核心建设内容。但是归结起来，这些都属于围绕业务数据管理的中后台应用范畴。不管是繁是简，它们的本质都是CRUD（关系数据的增删改查）。针对这一大类，满足需求最好的方式还是完全模型驱动的CADP。它不仅提供了更高的实现效率，还让业务专家能够亲自上手或者直接参与。虽然所有的CADP都有一个通病——交互界面范式化，没有自由度，但是对于中后台企业应用来说，范式化的交互似乎并不是坏处。尤其是对那些表单繁多，字段冗长，流程繁复的需求场景来说，如果不使用模型驱动的方式，那么就需要花费数倍到数十倍的时间来构筑完整的前后端逻辑。

但实际上，除了这些场景以外，还有另外一些需求可能更适合LCAP产品。这些就是对前端交互自由度要求很高的前台型应用和行业现场型应用。前者指的是需要提供给消费者使用的应用，开发者希望能够完全控制界面要素，甚至要能够反映自己的品牌风格。后者指的是面向特定行业的现场服务类应用，它们可能要在非常局促的时空中让员工完成一系列操作，包括可能使用特殊设备，利用移动设备的特殊能力等。这两类需求会让CADP类产品感到吃力。云计算大厂的几个产品不约而同地都选择了低代码构建的方式，允许开发者绘制或拖拽出前端界面，甚至有直接连接微信小程序上传的能力，满足的就是这类需求。

对比这两大类需求场景，哪一个在中国市场需求量更大呢？纯粹从需求数量上看，可能找不到胜负的标准，但是从需求的价值含量上看，CRUD场景要明显高得多。这可能是Gartner报告中只描述了这四个场景的原因。

将客户需求细分成这两大类场景，更有利于我们看清楚LCAP/CADP两类产品的价值和适用场景。而且很显然，无论是大中小企业，这两种需求都是存在的，并不存在大企业都应该Low Code，小企业都应该No Code这样的规律和趋势。

4、竞争挑战

明道云在若干年前开始进行业务转型的时候，选择了APaaS方向。经过几年的发展，这个领域正在受到前所未有的关注。客户需求和购买意愿也在快速增长。但是，在增长的同时，我们也感受到一种系统性的阻力。这些阻力并不是和低代码零代码市场直接相关，而是普遍存在于中国企业软件行业中。

在报告的最后，Gartner为厂商提供了一些克服挑战的竞争建议。我觉得基本都说在了要点上。

（1）要同时支持专业开发者和公民开发者。

这的确是整个LCAP事业的重点价值。如果不能带入公民开发者，那么我们做的一切都只是开发效率工具。客观地说，对于真正专业的开发者来说，Low Code并不一定能够比Pro Code更高效。所以，即使是画布模式下的LCAP也要降低产品门槛，让非开发者能够快速理解和上手。CADP产品在满足了公民开发需求后，也要不断延伸自己的产品能力，通过函数、脚本语言来提供“局部代码能力”，让开发者不必因为少数Corner Case而转道完全的代码开发。Gartner在这两年非常强调IT和业务团队的融合（Fusion Team），在我看来，最简单直接的一个描述就是“让业务专家能够主导应用实现，让技术专家能够主导应用深化”。有关这一点，Gartner报告中也提到了Software Technology和Operation Technology的结合目标。

（2）满足区域需求特点，建立平台生态，适应中国市场。

这一点明显是说给国际厂商听的。但国内产品也没有做得足够好。前文提到的市场推广障碍中就包括这个重大阻力。值得我们整个市场的从业者来优先重视。与其等待其他应用产品的开发性提升，不如率先将自己的LCAP/CADP产品做得足够开放，并能够把常规的数据和应用集成工作也No Code化。

（3）通过优化互利关系来加强伙伴生态。

我一直认为，无论是LCAP，还是CADP，都必须专注在通用产品能力建设上。产品内部不应该，也不需要带有具体的行业属性。同样，我也不觉得各行各业的ISV有必要去研发APaaS这类基础产品。所以互利合作的道路就摆在这，ISV可以在既有的平台产品上构筑垂直解决方案。这种解决方案既可能是多客户复用的，也可能是为特定大客户按需定制的。在这种基于增值的伙伴关系中，客户、平台产品和垂直服务提供商是三赢的。