细说独特的APaaS软件门类

文/明道云创始人任向晖

美国软件企业Intuit公司在2000年前后推出了一个产品，叫做Quickbase，顾名思义，就是快速开发数据库（应用）。它开了行业先河，不仅提供低代码的企业应用开发环境，而让应用直接在一个平台上运行，用户不再需要额外编译代码和配置运行环境。当然，在那个年代，APaaS这个品类名称还没有出现，一般都统称这类应用为ASP。

在接下来的十多年中，这个品类不断发展，不仅做出了Smartsheet，Outsystems, ServiceNow这些独立上市公司，像Salesforce和微软也都在自己的核心产品线路中增加了APaaS能力。对于Salesforce来说，除了销售，营销，客服等核心应用以外，还有数千家开发者利用AppExchange市场向Salesforce用户分发了通过APaaS平台开发的行业应用和扩展应用。微软在这个领域的发展可以分为两条主线，一是Sharepoint，Dynamics的企业级软件产品线，它们允许用户在使用开箱应用的同时进行扩展开发，以满足离散化的业务需求。另一条线是近两年在Office 365产品线上延伸的Power系列产品，包括Power BI，Power Apps等，这些工具产品更多面向非代码开发人员，有相当比例的开发者并不需要编写代码就能够实现一些常见的场景，比如制作一个统计仪表盘，开发一个搜集数据的移动应用等。

所以，APaaS只是一个新的品类称谓，但并非一个全新的品类。它在全球企业软件市场甚至算是一个老资格了。可是为什么在2019年这个节点，国内市场对这个品类的热度突然提高了呢且它的关注度还很诡异地和另外一个叫做RPA（流程机器人）的小品类联系在一起。

Copy to China/h2>

Copy to China的因素当然存在，和SaaS所有其他门类一样，美国市场几乎是一切企业软件的策源地。从CRM，ERP到行业应用，中国从业者或多或少都借鉴了美国市场的产品。这没有任何需要掩饰的，我们做IT行业的人从内心相信全球化的力量是 会进步的主要动力。

但是，APaaS品类和其他SaaS类型一样，我们可以借鉴基本的方法论，但原封不动地照抄产品基本上不会有好的下场。国际产品如果想要直接进入中国市场也几乎一定水土不服。到我写这篇文章时，海外的APaaS产品，包括IT巨头的相关产品线悉数都没有进入大陆市场。

中国SaaS产品的特色已经越来越鲜明，而且在很多细节方面，做得可能已经比美国同行更好。所以，在中国重新定义APaaS产品的形态需要考虑中国国情中的这些要素：

1）用户应用水平

2）客户需求特点

3）开发者生态

4）应用生态

我在后面几点会结合这四项环境差异来说明中国市场为什么特别需要APaaS，但是需要不一样的产品形态。

真正面向非技术人员

虽说APaaS产品一直以来都降低了开发门槛，提高了效率，但是面向的用户主要还是软件研发人员。像Outsystems这样的标杆产品，的确相当强大。它分离了一个应用软件开发的所有要素，并将这些要素用可视化的方式来替代代码开发。Outsystems对开发效率的提高并不是因为节省了代码开发的时间，而是将常用的数据模型，业务逻辑和数据接口等都封装成预制的组件。

即便如此，这些产品依然需要在必要的时候使用少数脚本型编程语言，比如数据查询、表达式编写和联合表数据的时候。甚至它们用来开发应用的界面和一个标准的IDE开发环境都非常接近。

用一个可视化工作流来定义这个“恢复”按钮。

上图是我们一位客户老板（非技术人员）搭建的定制ERP系统。他一个人就搞定了。

为什么一定要让非技术人员参与企业应用开发，除了提高效率，减少需求沟通的成本以外，还有一个非常重要的原因。这个我在后面还会重点说明。

APaaS的客户需求和利基市场

APaaS只是一个软件品类，它是软件产业的革新，但并不可能替代其他的软件品类。有人会望文生义地理解零代码软件开发，甚至问“那我们还要招聘程序员干吗。提出这种挑战的人显然对软件产业的复杂性缺乏了解。零代码或者低代码开发，并不针对所有类型应用的开发工作。

如果把整个软件产业放到一个坐标上，我们可以按照需求的标准化程度作为横轴。显然，需求最普遍的，也是最标准的，从操作系统，数据库，应用软件到各种工具软件，占据了软件产业的大部分比例。这部分是任何其他解决方案都望尘莫及的，因为创新和差异化很难干得过规模化优势和 络效应。

但是在企业应用领域，往右延伸的长尾则包含了大量标准化程度越来越低的需求。没有人真正统计过中国软件产值（2017年大约在25000亿人民币左右）中标准化产品授权和定制集成类外包服务收入的比例。我猜测这个比例大约在50/50左右。大量产品型公司其实也提供围绕自己产品的集成和定制服务。

那么这些长尾需求到底因何出现呢br>

如果辨明了APaaS的目标利基市场，我们就可以围绕中国市场当下的需求特点来重新设计APaaS产品主要解决的问题。

1. 离散制造和工程领域的数字化管理（Customization Oriented）
2. 外部协作环节，包括各类现场管理，数据搜集和供应链协作（Externalization Oriented）
3. 从既有应用中抽取或同步数据，形成可高效开发的数据中台（Integration Oriented）
4. 不再依赖过多的套装软件，利用自有IT力量建立一体化的信息化系统，实现最大程度的数据互通和灵活度（Versatility Oriented）

至于各种集成需求，中国市场的应用环境和欧美几乎完全不同。除了相对标准的关系数据库和Restful API集成源以外，其他的应用数据集成都要重新根据国内生态重新做一边。美国有Shopify的订单，国内是电商ERP；美国用Salesforce，Dynamics，国内是销售易、纷享销客；美国用Google Suite，国内有钉钉、企业微信和飞书。虽然国内产品目前的开放度非常糟糕，但有了APaaS和IPaaS品类的助力，应用之间，应用和平台之间的数据互通完全是可以实现的。

建立不一样的生态或依存关系

最后一个原因：生态！

不过不要误解，我说的不是软件行业常见的“开发者生态”，而是更加容易建立的“业务专家依存关系”。

首先，任何低代码或者零代码开发平台都很难有条件建立起繁荣的开发者生态。即便是最领先的Salesforce Appexchange，十多年来也只积累了3000多个应用，而且这当中绝大多数都是其他产品的连接器性质应用。这当中最主要的原因就是企业应用很难建立 络效应，你用SAP，我用金蝶用友，并没有什么关系。所以，即使市场占有率较高的平台，也与一统天下距离甚远。

所以，作为APaaS厂商，必须理性看待所谓建设生态的目标。生态不是一统天下，而是建立和不同角色的主体相互依存的关系。零代码定位的APaaS带来了一个优势，它能够吸引过往无法参与企业软件建设的新群体——业务专家。

在企业软件设计和开发中，最困难的过程不是写代码，而是理解业务需求。这个过程没有任何厂商敢说是毫无问题的。很多垂直行业软件公司为了让产品能够很好地满足客户需求，不得不聘请大量的行业专家，甚至有的时候不惜自己亲自去运营相关业务。我就知道有一家酒店PMS厂商自己开了一家酒店，一家做健身会所管理的行业SaaS自己就是健身房老板出身。但不是所有的时候都能够有这样的奢侈，企业的离散业务需求不可能让软件设计人员亲自靠运营业务来理解需求，所以我们这个行业始终面对着业务专业能力和软件架构能力之间的断层。

如果企业有足够多的钱，当然可以通过聘请一流的咨询公司，考察全球最佳实践，引进最好的行业解决方案，再聘请经验最丰富的实施公司来完成落地。但这个过程即便对财富500强公司来说，都是一笔不小的投入。

因此，做新一代的APaaS，不仅要提供零代码，低门槛的技术工具，还要能够帮助业务专家相互借鉴，跨行业学习，平台内共享，并最终允许业务专家构筑和分发这些解决方案。如果某一位制造业专家过去依靠Excel和管理方法论解决了某行业的生产质量管理问题，那么他也一定能够通过这一代的APaaS平台构筑出更卓越的软件方案，将Excel不能克服的问题解决得更好。他不仅能够获得咨询和培训收入，还能够合理地通过这个软件方案得到订阅性收入。而因为他所付出的成本和技术门槛都足够的低，企业客户所需要支付的代价和实施风险也会同步降低。

我所说的新型依存关系，就是APaaS平台需要业务专家来构筑行之有效和专业的解决方案，而业务专家也需要这样的平台来变现自己的产业知识。这样的依存关系不需要很强大的 络效应，哪怕只有第一组这样的关系存在，就能够开始产生价值。

重新开始的关键

重做新一代APaaS产品的前景看起来非常美妙，这也难怪企业服务投资领域最近都特别关注相关品类。但是它要进入有效商业化产出阶段还有很大的阻力。从我们自己的经验实践看，最大的阻力来自于依然来自于信任，尤其是在大中型规模的企业中得到验证。

APaaS模式说得天好地好，到底能不能解决我的问题底能不能做出复杂的应用方案定制开发相比，到底能够节省多少的成本，实现怎样的业务弹性于业务专家来说，他们是否信任这样的平台能够实现脑中的构想，能否可靠地对终端客户提供服务，价格是否合理/p>

这些问题都是我们当下最重要的问题，但意识到瓶颈关键就好办。明道云的确已经在非常多的业务场景下得到了验证，现在我们特别希望获得更多有清晰愿景、希望在数字化建设中走在前面的大中型企业开始尝试新一代APaaS产品，构筑比竞争者领先一步的企业信息化。