美国软件公司Intuit在2000年左右推出了一款名为Quickbase的产品，顾名思义就是数据库（应用）的快速发展。这是业内首创。它不仅提供低代码的企业应用程序开发环境，还允许应用程序直接在平台上运行。用户不再需要编译代码和配置运行环境。当然，在那个年代，还没有出现APaaS这个品类名称，一般把这类应用统称为ASP。在接下来的十年左右，这一类别继续发展。不仅Smartsheet、Outsystems、ServiceNow成为了独立的上市公司，Salesforce和微软也在核心产品线中加入了APaaS能力。对于Salesforce而言，除了销售、营销、客服等核心应用外，数以千计的开发者利用AppExchange市场，将通过APaaS平台开发的行业应用和扩展应用分发给Salesforce用户。微软在这个领域的发展可以分为两条主线。一个是Sharepoint，Dynamics的企业级软件产品线，它允许用户使用开箱即用的应用程序，同时执行扩展开发以满足离散的业务需求。另一条线是近两年在Office365产品线中延伸出来的Power系列产品，包括PowerBI、PowerApps等，这些工具产品更多的是面向非代码开发者，有相当比例的开发者不需要写代码就可以实现一些常见的场景，比如做一个统计仪表盘，开发一个收集数据的手机应用等等。因此，APaaS只是一个新的品类名称，而不是一个全新的品类。更是全球企业软件市场的老手。但为什么在2019年的这个节点，这个品类在国内市场的热度突然上升了呢？而它的注意力奇怪地与另一个叫做RPA（流程机器人）的小类联系在一起。复制到中国？复制到中国的因素肯定存在。与所有其他类别的SaaS一样，美国市场是几乎所有企业软件的来源。从CRM、ERP到行业应用，中国从业者或多或少都借鉴了美国市场的产品。没有必要隐藏这一点。我们IT行业从内心深处相信，全球化的力量是推动社会进步的主要动力。但是，APaaS类别与其他SaaS类型相同。基本的方法论我们可以借鉴，但是基本上原封不动的照搬产品，是不会有好下场的。国际产品如果想直接进入中国市场，几乎肯定水土不服。到我写这篇文章的时候，海外的APaaS产品，包括IT巨头的相关产品线，都还没有进入大陆市场。中国SaaS产品的特点越来越鲜明，在很多细节上，他们可能比美国同行做得更好。因此，重新定义APaaS产品在中国的形态需要考虑中国国情的这些要素：用户应用层面客户需求特征开发者生态应用生态我将在以下几点结合这四个环境差异来说明为什么中国市场特别需要APaaS，但需要不同的产品形式。真正面向非技术人员虽然APaaS产品一直在降低开发门槛，提??高效率，但主要用户还是软件开发人员。像Outsystems这样的标杆产品，确实是相当强大的。它将应用软件开发的所有元素分离，并以这些元素的可视化方式代替代码开发。Outsystems对开发效率的提升，并不是因为它节省了代码开发的时间，而是因为它把常用的数据模型、业务逻辑和数据接口都封装到了预制组件中。即便如此，这些产品仍然需要在必要时使用少量的脚本编程语言，例如数据查询、表达式编写、合并表数据时。甚至他们用来开发应用程序的界面也非常接近标准的IDE开发环境。因为这样的设计模式和产品的复杂性，基本上把所有非软件工程人员排除在外。低代码也是代码，一句代码就憋死一个不会写代码的英雄。APaaS对于软件开发者来说是一个非常好的效率工具，但它绝对不是软件行业的一场革命。Gartner所说的“APaaS可以针对公民开发者”在这一代产品中并没有真正实现。所以重做APaaS最重要的意义就是让非软件技术人员广泛参与，让一些熟悉业务的业务专家自己搞定大部分工作。为了实现这个目标，需要放弃APaaS早期的任何应用都可以开发的目标，而专注于那些APaaS产品具有优势的业务领域。在2015年后出现的APaaS产品中，包括明道云，已经明确确立了这个目标。除了API对接开发，更友好的APaaS工具都非常克制依赖脚本代码，转而使用可视化配置交互来完成。有时候，这个过程确实很艰难，因为要处理的情况可能非常多样，但是通过步骤分解和必要的舍弃，还是可以成功地让不会写代码的人完成必要的定义。例如，在CRM应用程序中，需要为无效的销售线索添加一个“恢复”操作按钮。明道云是这样做的：用一个可视化的工作流来定义“恢复”按钮。实践证明，大多数业务人员都能掌握这种可视化方法。对于逻辑思维习惯良好的项目经理和产品经理来说，更是得心应手。新的APaaS也力求剔除软件开发中过于专业的概念，如实体、属性、方法、函数、表达式、循环、递归等，这些词本身具有精确的含义，但对于没有计算机编程教育的人来说很难理解掌握。虽然APaaS不能像极简个人应用那样简洁明了，或者使用非常流行的界面语言，但设计师有责任控制专业术语的使用。每一次他们使用更多，他们就会失去更多的非技术用户。在操作明道云的过程中，我们发现专业的软件开发人员确实更容易掌握，但更让我们兴奋的是普通文职人员的易用性。销售经理可以直接完成销售漏斗的应用构建；人力资源经理或许可以自己搭建一个小型的EHR系统，甚至可以实现自动发薪。图片是我们的一位客户老板（非技术人员）搭建的定制ERP系统。他一个人做这一切。为什么一定要让非技术人员参与企业应用开发？除了提高效率，降低需求沟通的成本，还有一个很重要的原因。稍后我将重点介绍这一点。APaaS客户需求和利基市场APaaS只是一个软件类别。它是软件行业的创新，但不能替代其他软件类别。有些人会听上去理解零代码软件开发，甚至会问“为什么我们还需要雇用程序员？”。提出这一挑战的人显然缺乏对软件行业复杂性的理解。零代码或低代码开发并不针对所有类型的应用程序开发。如果把整个软件行业放在一个坐标上，我们可以用需求的标准化程度作为横轴。很显然，最通用、最标准的需求，从操作系统、数据库、应用软件到各种工具软件，占据了软件行业的绝大部分。这部分是其他任何解决方案都达不到的，因为创新和差异化很难做到规模优势和网络效应。但在企业应用领域，向右延伸的长尾包含大量标准化程度越来越低的需求。没有人真正统计过标准化产品授权和定制化集成外包服务收入占中国软件产值（2017年约2.5万亿元）的比重。我猜这个比例大约是50/50。大量产品公司实际上围绕自己的产品提供集成和定制服务。那么为什么会出现这些长尾需求呢？1、业务分散所谓高度分散，就是分布的规律性差。在不同的行业中，业务分散程度本来就是不平衡的。例如，在餐饮和酒店行业，其业务运作高度标准化。几乎所有同规模的企业都按照基本一致的协同流程运作，其产品和服务在一段时间内都相当稳定。差异化也与信息系统无关。相反，按订单制造完全是另一个极端。订单大小不一。今天可能是一种产品，明天可能是另一种产品。在极端情况下，每个订单可能不同。这类行业一般要相互合作，所以订单生产包括自产和外购。在这种情况下，标准化的软件产品能够解决的问题就非常有限了。企业要想对业务数据和流程进行精细化管理，就不得不借助定制化开发。2、企业差异化差异化是企业间竞争的结果。有的来自企业的主动追求，有的来自被动竞争。不管是什么原因，公司总是希望与竞争对手不同。标准化的信息系统也可能无法满足此类企业的需求。比如瑞幸咖啡、喜茶等连锁餐饮企业，就不能满足于标准化的餐饮收银系统。他们必须围绕自己的运营战略构建差异化的信息系统。当然，这两个例子都属于大型企业，但在中小企业中，竞争挤压带来的差异化需求也很普遍。比如我认识的一家律师事务所，专注于知识产权业务，更具体地说，他们专门帮助品牌商在淘宝等电商平台上打假维权。面对如此差异化的业务，普通律师事务所的业务管理系统当然不能满足他们。3、各种集成需求除了业务分散化、差异化带来的定制化需求，还有各种集成需求带来的非标准化。每个公司可能使用不同的应用组合，使用不同的员工账户管理平台，业务数据也分散在不同的数据源和应用中。这时候有很多整合和对接的关系。有的需要将金蝶的ERP数据集成到定制的MES中，有的需要将定制的CRM应用与用友的财务软件对接，有的需要将应用通知与钉钉、微信对接，越来越多的企业需要建立一个数据中台，可以与应用系统分离，方便开发新的业务流程。所有这些集成需求一般都是通过定制开发来实现的。我们一般将集成开发需求概括为数据集成、用户集成和应用集成。APaaS的两个兄弟类别——RPA（流程机器人）和IPaaS（集成平台即服务）几乎专门为集成需求而创建。早期出现的APaaS确实是针对这些长尾需求。同样以对标产品Outsystems为例。在其解决方案中，客户体验提升、运营效率提升、传统系统现代化、SAP扩容、现场服务优化、数字化转型等几乎都属于这些长尾需求范围。如果确定了APaaS的目标利基市场，我们就可以围绕当前中国市场的需求特点，重新设计APaaS产品要解决的主要问题。离散制造和工程领域的数字化管理（面向定制）外部协作链接，包括各种现场管理、数据收集和供应链协作（面向外部化）从现有应用中提取或同步数据，形成数据中心，可高效开发（IntegrationOriented）不依赖过多的打包软件，利用自身的IT力量建立一个集成的信息系统，实现最大程度的数据互操作性和灵活性（VersatilityOriented）针对各种集成需求，应用环境中国市场与欧美市场几乎完全不同。除了相对标准的关系型数据库和RestfulAPI集成源，其他应用数据集成都要根据国内生态进行返工。美国有Shopify订单，国内电商ERP；美国使用Salesforce、Dynamics，国内销售易销、享销；美国用GoogleSuite，国内有钉钉、企业微信、飞书。虽然目前国内产品的开放性很差，但是借助于APaaS和IPaaS类，应用之间、应用与平台之间的数据互通是完全可以实现的。建立不同生态或依赖关系的最后一个原因：生态！但不要误会，我说的不是软件行业普遍存在的“开发者生态”，而是更容易建立的“业务专家依赖关系”。首先，任何低代码或零代码的开发平台都很难建立繁荣的开发者生态。即使是领先的SalesforceAppexchange，在过去十年也仅仅积累了3000多个应用，而且大部分都是其他产品的连接器应用。主要原因是企业应用很难建立网络效应。你用SAP我用金蝶用友没关系。因此，即便是市场占有率高的平台，也远谈不上一统天下。因此，作为APaaS厂商，我们要理性看待所谓的生态建设目标。生态不是要主宰世界，而是要与不同角色的主体建立相互依存的关系。具有零代码定位的APaaS带来了优势。可以吸引过去无法参与企业软件建设的一批新的业务专家。我前面提到，重构一个APaaS产品的首要目标是真正针对非技术人员。但其真正用意不仅在于让企业软件开发摆脱对软件工程师的依赖，更在于连接企业软件的智慧之源——业务专家。在企业软件设计和开发中，最难的不是写代码，而是理解业务需求。没有厂家敢说这个过程没有问题。很多垂直行业的软件公司为了让自己的产品很好地满足客户需求，不得不聘请大量的行业专家，有时甚至不惜自己经营相关业务。我知道有一个酒店PMS厂商自己开酒店，还有一个管理健身俱乐部的SaaS行业。他本人是健身房老板。但并不是每时每刻，我们都能拥有这样的奢侈。企业离散的业务需求不能让软件设计人员通过运营业务来理解需求。因此，我们这个行业始终面临着专业业务能力和软件架构能力之间的差距。.如果公司有足够的资金，当然可以聘请一流的咨询公司，考察全球最佳实践，引入行业最佳解决方案，然后聘请最有经验的实施公司完成实施。但这个过程即使对于世界500强企业来说也是一笔不小的投资。最好的方法是让业务专家自己完成大部分工作。这又回到了本文开头对现有APaaS产品的批评。它们还不是真正的业务专家平台。业务专家根本无法入门，更谈不上实现完整的信息化解决方案。因此，构建新一代APaaS，不仅要提供零代码、低门槛的技术工具，还要帮助业务专家相互学习，跨行业学习，平台内共享，最终让业务专家能够构建和分发这些解决方案。如果一个制造专家曾经依靠Excel和管理方法论来解决某个行业的生产质量管理问题，那么他一定可以通过这一代APaaS平台构建出更优秀的软件解决方案，解决Excel无法解决的问题克服。更好的。他不仅可以获得咨询和培训收入，还可以通过该软件解决方案合理获得订阅收入。而且因为他付出的成本和技术门槛足够低，企业客户需要付出的成本和实施风险也会同步降低。我说的新的依赖关系是APaaS平台需要业务专家来构建有效的、专业的解决方案，业务专家也需要这样的平台来变现自己的行业知识。这种依赖不需要强大的网络效应，即使只有第一组这样的关系存在，它也可以开始产生价值。重头开始的关键重做新一代APaaS产品的前景看起来非常美好。也难怪最近企业服务投资领域格外关注相关品类。但要进入有效商业化输出阶段，仍面临诸多阻力。从我们自己的经验和实践来看，最大的阻力还是来自于信任，尤其是在大中型企业。APaaS模型非常好。它能解决我的问题吗？它能做出复杂的应用解决方案吗？与定制开发相比，它能节省多少成本，能实现怎样的业务灵活性？对于业务专家来说，他们是否信任这样的平台来实现他们心中的想法，他们能否可靠地为终端客户提供服务，价格是否合理？这些问题是我们目前最重要的问题，但很容易实现瓶颈。明道云确实在很多业务场景中得到了验证。现在我们特别希望能得到更多有远见，希望在数字化建设中走在前面的大中型企业开始尝试新一代APaaS产品，搭建领先于竞争对手的平台。企业信息化一步到位。【本文为专栏作家“明道云”原创稿件，转载请联系原作者获得授权】点此阅读更多该作者好文
