文/明道云创始人的勤奋路人

美国的软件企业Intuit公司在2000年前后发表了一种叫做Quickbase的产品，顾名思义，是迅速开发数据库(APP )。 作为行业先锋，不仅提供了低代码的企业APP开发环境，而且通过在一个平台上直接运行APP应用，用户不再需要添加编译代码或配置运行环境。 当然，gldzx、APaaS这一类别名称还没有出现，一般统称为ASP。

在未来的十多年里，这个品类持续发展，不仅打造了Smartsheet、Outsystems、ServiceNow这些独立的上市公司，Salesforce、微软等也在自己的核心产品线路上增加了APaaS能力。 Salesforce除了销售、营销、客服等核心APP外，还向Salesforce客户分发了数千家开发者利用AppExchange市场在APaaS平台上开发的行业APP和扩展APP。 微软在这一领域的发展分为两条主线： Sharepoint、Dynamics的企业软件产品线，用户在使用开箱APP的同时，为了满足个别化的业务需求而进行扩展开发另一条线是近两年在Office 365产品线中扩展的Power系列产品，包括Power BI、Power Apps等。 这些工具产品面向非代码开发人员，有相当大比例的开发人员无需编写代码即可实现常见场景。 例如，创建统计面板或开发收集数据的移动APP。

因此，APaaS是新类别的称呼，但不是全新的类别。 在全球企业的软件市场上，也是一种古老的资格。 但是，为什么在2019年的这个节点上，国内市场对这个类别的热度突然高涨了呢？ 并且，其关注度与另一个叫做RPA (过程机器人)的故事类型联系在一起。

Copy to China?

Copy to China的要素当然存在，和SaaS的所有其他部门一样，美国市场几乎是所有企业软件的源泉。 从CRM、ERP到行业APP，中国员工或多或少参考了美国市场的产品。 没必要隐瞒这个。 我们IT界的人真心相信全球化的力量是社会进步的主要动力。

但是，APaaS类别和其他SaaS类型一样，可以参考基本的方法论，但直接抄写产品几乎没有什么结果。 国际产品要直接进入中国市场，几乎水土不服。 在我写这篇文章之前，包括海外APaaS产品、雪白铃铛在内的相关产品线都没有进入大陆市场。

中国SaaS产品的特色越来越鲜明，在许多细节上可能优于美国同行。 因此，在中国重新定义APaaS产品的形态时，需要考虑中国国情中的这些因素。

1 )用户应用水平

2 )客户需求的特征

3 )开发者生态

4 )应用生态

我将在之后的几点结合这四种环境的不同，来说明中国市场为什么特别需要APaaS，但需要不同的产品形态。

虽然

真正面向非技术人员

APAas产品此前降低了开发门槛，提高了效率，但目标用户主要是软件开发者。 像出局系统这样的基准产品确实相当强大。 分离一个APP开发的所有元素，并将这些元素可视化而不是代码开发。 Outsystems开发效率的提高，不是因为节省了代码开发的时间，而是因为将常用的数据模型、业务逻辑、数据接口等封装在了预编写的组件中。

尽管如此，这些产品还是需要根据需要使用少量的脚本编程语言，如数据查询、表达式创建和表数据绑定。 用于开发这些APP的接口与标准IDE开发环境非常接近。

由于这种设计模式和产品的复杂性，基本上排除了所有非软件工程人员。 低沉的代码也是代码，一句代码都屏住呼吸写不出代码的英雄汉。 APaaS对软件开发者来说是一个很好的效率工具，但绝不是软件产业的革命。 Gartner所说的“APaaS面向全民的开发者(Citizen Developer )”在这一代产品中并没有实际实现。

因此，重新做APaaS的最大意义是让非软件技术人员广泛参与，让熟悉业务的一些业务专家可以自助完成大部分工作。 为了实现这个目标，必须放弃初期的APaaS可以开发任何APP应用的目标，而把焦点放在APaaS产品具有优势的商业领域上。

在2015年以后出现的APaaS产品中，包括明道云在内，明确确立了这个目标。 除了API对接开发之外，更友好的APaaS工具极大地抑制了对脚本代码的依赖，取而代之的是采用视觉定位交互方式完成的。 这个过程确实可能非常困难。 处理的情况可能非常多样，但通过分解步骤和必要的销毁，可以为不会写代码的人完成必要的定义。

例如，要在CRM APP中失效的销售线索中添加“恢复”的动作按钮，明道云如下所示。

由视觉化工作流程决定

义这个“恢复”按钮。

实践证明，这个可视化实现方式能够被大部分业务人员掌握。对于那些逻辑思维习惯好的项目经理、产品经理来说，更加是信手拈来。

新型APaaS也竭力去除了软件开发中过于专业的概念，比如实体、属性、方法、函数、表达式、循环、递归等。这些词汇本身有精确的含义，但是对于没有经过计算机编程教育的人来说，掌握起来非常困难。虽然APaaS做不到像极简的个人应用那样言简意赅，或者使用非常通俗的界面语言，但jkdy有责任控制专业名词的使用，每多使用一些，就多流失一些非技术型用户。

在我们运营明道云的过程中，发现专业软件开发者的确更容易掌握，但更让我们兴奋的是一般文职人员的上手容易度。一位销售经理可能直接完成销售漏斗的应用搭建；一位人事经理可能自己就能够做一个小型EHR系统，甚至做到自动化的制薪。

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

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

APaaS的客户需求和利基市场

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

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

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

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

业务离散度

所谓离散度高，就是分布的规律性差。在不同行业中，业务离散度高低本来就不均匀。比如像餐饮酒店业，它的业务运营标准化程度就很高，几乎所有的同规模企业都是按照基本一致的协作流程来运行的，产品和服务在一段时间内也都相当稳定，即便有经营上的差异化，也和信息系统关联不大。相反，像按单制造业就完全是另外一个极端，订单有大有小，今天可能是这个产品，明天可能是另外一个产品。极端情况下，可能每个订单都不一样。这样的行业一般不得不进行同业协作，所以订单生产既包括自己生产也包括外包外协。在这种情况下，标准化的软件产品能够解决的问题非常有限，企业如果想要精细化管理业务数据和流程，就不得不诉诸于定制开发。

业务差异化

差异化是企业之间竞争的结果。有的来自企业的主动追求，有的来自被动的竞争挤压。不管是因为何种动因，企业总希望能够和竞争对手的做法不一样。标准化信息系统也可能无法满足这类企业的需要。举例来说，像瑞幸咖啡，喜茶这样的连锁餐饮企业，就不可能满足于一个标准化的餐饮收银系统，它们必须围绕自己的运营策略，建立差异化的信息系统。这两个例子当然都属于规模较大的企业，但在中小企业中，因为竞争挤压带来的差异化需求也非常普遍，比如我认识的一家律师事务所就专注于知识产权业务，更具体地来说，他们专门帮助品牌在淘宝等电商平台上打假维权。面对这种差异化业务，普通的律所业务管理系统当然满足不了他们。

各类集成需求

除了业务离散度和差异化带来的定制需求，还有各种集成需求带来的非标准化。每个公司都可能要使用不同的应用组合，用不同的员工账户管理平台，业务数据也分散在不同的数据源和应用中。这时候就存在繁多的集成对接关系。有的是要将金蝶的ERP数据集成到定制的MES中，有的是要将定制的CRM应用和用友的财务软件打通，有的需要将应用通知和钉钉、企业微信的消息打通，还有越来越多的企业需要建立一个能够脱离应用系统的数据中台，以方便拓展新的业务流程。所有这些集成需求一般都是通过定制开发的方式来实现的。我们一般把集成开发需求归纳为数据集成，用户集成和应用集成几个方向。APaaS的两个兄弟品类—RPA（流程机器人）和IPaaS（整合平台即服务）几乎专门是为了集成需求而产生。

早期出现的APaaS的确也是重点围绕这些长尾需求的。同样以Outsystems这个标杆产品为例，在它的解决方案中，顾客体验提升，运营效率提升，传统系统现代化，SAP扩展，现场服务优化和数字化转型几乎全部落在这些长尾需求区间。

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

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

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

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

最后一个原因：生态！

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

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

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

我在前面提到重建APaaS产品的第一个目标是真正面向非技术人员。但它真正的用意不仅仅是让企业软件开发摆脱对软件工程师的依赖，还包括连接企业软件的智慧来源——业务专家。

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

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

最好的办法，就是让业务专家自己能够动手完成大部分工作。这就回到本文一开头对现有APaaS产品的诟病。它们还不是真正意义上的面向业务专家的平台。业务专家根本上不了手，更不用说兑现出完整的信息化方案了。

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

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

开始的关键

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

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

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

利益声明：作者本人是APaaS厂商明道云的创办人。目前在国内主要的独立APaaS产品包括明道云、简道云、氚云、伙伴云和轻流等。