美国软件企业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?
Copy to China的因素当然存在，和SaaS所有其他门类一样，美国市场几乎是一切企业软件的策源地。从CRM，ERP到行业应用，中国从业者或多或少都借鉴了美国市场的产品。这没有任何需要掩饰的，我们做IT行业的人从内心相信全球化的力量是社会进步的主要动力。
但是，APaaS品类和其他SaaS类型一样，我们可以借鉴基本的方法论，但原封不动地照抄产品基本上不会有好的下场。国际产品如果想要直接进入中国市场也几乎一定水土不服。到我写这篇文章时，海外的APaaS产品，包括IT巨头的相关产品线悉数都没有进入大陆市场。
中国SaaS产品的特色已经越来越鲜明，而且在很多细节方面，做得可能已经比美国同行更好。所以，在中国重新定义APaaS产品的形态需要考虑中国国情中的这些要素：
- 用户应用水平
- 客户需求特点
- 开发者生态
- 应用生态
我在后面几点会结合这四项环境差异来说明中国市场为什么特别需要APaaS，但是需要不一样的产品形态。
真正面向非技术人员
虽说APaaS产品一直以来都降低了开发门槛，提高了效率，但是面向的用户主要还是软件研发人员。像Outsystems这样的标杆产品，的确相当强大。它分离了一个应用软件开发的所有要素，并将这些要素用可视化的方式来替代代码开发。Outsystems对开发效率的提高并不是因为节省了代码开发的时间，而是将常用的数据模型，业务逻辑和数据接口等都封装成预制的组件。
即便如此，这些产品依然需要在必要的时候使用少数脚本型编程语言，比如数据查询、表达式编写和联合表数据的时候。甚至它们用来开发应用的界面和一个标准的IDE开发环境都非常接近。
因为这样的设计模式和产品复杂度，基本上把所有的非软件工程人员排除在外了。低代码也是代码，一句代码也会憋死不会写代码的英雄汉。APaaS对于软件开发者来说是一个很不错的效率工具，但绝对不是软件产业的革命。Gartner所说的“APaaS能够面向全民开发者(Citizen Developer)”，在这代产品上并没有真正兑现。
所以，重做一遍APaaS最重大的意义就是让非软件技术人员能够广泛参与，让一部分熟悉业务的业务专家能够自助搞定绝大部分工作。为了达到这个目标，必须摒弃早期APaaS什么应用都能够开发的目标，而重点定位那些APaaS产品具备优势的业务领域。
在2015年以后出现的APaaS产品中，包括明道云在内，都明确树立了这个目标。除了API对接开发，更友好的APaaS工具非常克制对脚本代码的依赖，转而采用可视化配置交互的方式来完成。有时候，这个过程的确非常艰难，因为要处理的情况可能非常多样，但通过步骤分解和必要的舍弃，还是能够成功地让不会写代码的人完成必要的定义。
比如，在CRM应用中要给失效销售线索加一个“恢复”的动作按钮，明道云是这样做的：
用一个可视化工作流来定义这个“恢复”按钮。
实践证明，这个可视化实现方式能够被大部分业务人员掌握。对于那些逻辑思维习惯好的项目经理、产品经理来说，更加是信手拈来。
新型APaaS也竭力去除了软件开发中过于专业的概念，比如实体、属性、方法、函数、表达式、循环、递归等。这些词汇本身有精确的含义，但是对于没有经过计算机编程教育的人来说，掌握起来非常困难。虽然APaaS做不到像极简的个人应用那样言简意赅，或者使用非常通俗的界面语言，但设计者有责任控制专业名词的使用，每多使用一些，就多流失一些非技术型用户。
在我们运营明道云的过程中，发现专业软件开发者的确更容易掌握，但更让我们兴奋的是一般文职人员的上手容易度。一位销售经理可能直接完成销售漏斗的应用搭建;一位人事经理可能自己就能够做一个小型EHR系统，甚至做到自动化的制薪。
图是我们一位客户老板(非技术人员)搭建的定制ERP系统。他一个人就搞定了。
为什么一定要让非技术人员参与企业应用开发，除了提高效率，减少需求沟通的成本以外，还有一个非常重要的原因。这个我在后面还会重点说明。
APaaS的客户需求和利基市场
APaaS只是一个软件品类，它是软件产业的革新，但并不可能替代其他的软件品类。有人会望文生义地理解零代码软件开发，甚至问“那我们还要招聘程序员干吗?”。提出这种挑战的人显然对软件产业的复杂性缺乏了解。零代码或者低代码开发，并不针对所有类型应用的开发工作。
如果把整个软件产业放到一个坐标上，我们可以按照需求的标准化程度作为横轴。显然，需求最普遍的，也是最标准的，从操作系统，数据库，应用软件到各种工具软件，占据了软件产业的大部分比例。这部分是任何其他解决方案都望尘莫及的，因为创新和差异化很难干得过规模化优势和网络效应。
但是在企业应用领域，往右延伸的长尾则包含了大量标准化程度越来越低的需求。没有人真正统计过中国软件产值(2017年大约在25000亿人民币左右)中标准化产品授权和定制集成类外包服务收入的比例。我猜测这个比例大约在50/50左右。大量产品型公司其实也提供围绕自己产品的集成和定制服务。
那么这些长尾需求到底因何出现呢?
1. 业务离散度
所谓离散度高，就是分布的规律性差。在不同行业中，业务离散度高低本来就不均匀。比如像餐饮酒店业，它的业务运营标准化程度就很高，几乎所有的同规模企业都是按照基本一致的协作流程来运行的，产品和服务在一段时间内也都相当稳定，即便有经营上的差异化，也和信息系统关联不大。相反，像按单制造业就完全是另外一个极端，订单有大有小，今天可能是这个产品，明天可能是另外一个产品。极端情况下，可能每个订单都不一样。这样的行业一般不得不进行同业协作，所以订单生产既包括自己生产也包括外包外协。在这种情况下，标准化的软件产品能够解决的问题非常有限，企业如果想要精细化管理业务数据和流程，就不得不诉诸于定制开发。
2. 业务差异化
差异化是企业之间竞争的结果。有的来自企业的主动追求，有的来自被动的竞争挤压。不管是因为何种动因，企业总希望能够和竞争对手的做法不一样。标准化信息系统也可能无法满足这类企业的需要。举例来说，像瑞幸咖啡，喜茶这样的连锁餐饮企业，就不可能满足于一个标准化的餐饮收银系统，它们必须围绕自己的运营策略，建立差异化的信息系统。这两个例子当然都属于规模较大的企业，但在中小企业中，因为竞争挤压带来的差异化需求也非常普遍，比如我认识的一家律师事务所就专注于知识产权业务，更具体地来说，他们专门帮助品牌在淘宝等电商平台上打假维权。面对这种差异化业务，普通的律所业务管理系统当然满足不了他们。
3. 各类集成需求
除了业务离散度和差异化带来的定制需求，还有各种集成需求带来的非标准化。每个公司都可能要使用不同的应用组合，用不同的员工账户管理平台，业务数据也分散在不同的数据源和应用中。这时候就存在繁多的集成对接关系。有的是要将金蝶的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产品，构筑比竞争者领先一步的企业信息化。
【本文是51CTO专栏作者“明道云”的原创稿件，转载请通过51CTO联系原作者获取授权】
