编辑导语：从用户的视角理解aPaaS产品，它的定位应该是一个工具型产品，能帮助所有想开发app的人，用更简单的方式和更低的成本来实现app的开发。那么，aPaaS产品面向的群体用户和场景是什么呢？一起来看一下吧。
aPaaS产品的英文全称是 application platform as a service，是在云计算的platform as a service 的服务模式上演化而来，强调在讲云计算平台层的软件，开发能力作为一种服务，提供给用户。
“aPaaS”的概念是从技术开发者的视角，解释这类型的产品在云服务的整个体系的定位：即aPaaS产品不是PaaS类型产品，只服务于技术人员，也不是SaaS产品，可以面向最终的用户，而是作为PaaS和SaaS的中间层，通过对开发、运维过程的任何有开发app需求的用户，都可以使用aPaaS产品来开发他们的个性化app。
如果从用户视角来理解aPaaS产品，它的定位应该是一个工具型产品，帮助所有想要开发app的人，用更简单的方式和更低的成本来实现app的开发。但关于如何定义这个需求，拆解具体的产品功能方案，目前而言都还是摸索的过程。
从长远来看，aPaaS产品的愿景肯定是希望实现全民开发，让没学过编程的人，也能轻松开发自己的app，这一点目前业界是共识的。原因如下：
但短期而言，第一步应该切“技术人员”还是“非技术人员”，各产品的看法有所不同。
一部分厂商以业务人员为切入点，同时提供代码进行二开的能力。
此部分厂商提供的解决方案是表单驱动，从应用构建者的视角，不需要区分前端展现层和后端数据结构，二者是完全绑定，自动生成，搭建应用时，在表单引擎里定义需要的字段，管理后台table里自动生成数据结构；提供集成&自动化引擎、BI功能，支持数据流转和商业智能。
好处是去除了复杂的技术概念，非技术人员在使用时，理解成本较低，不过也正是因为这种简化，在产品能力在解决复杂需求上，会有所不足。
目前国内表单驱动的典型产品包括明道云、简道云、伙伴云、宜搭，国外表单驱动的产品包括Zoho Creator。
另一部份厂商以技术人员为切入点，整体逻辑是通过提供封装好的组件，来对软件开发的流程做简化。
此部分厂商提供的解决方案是模型驱动，从应用构建者的视角、应用的前端、后端、逻辑层各自独立，需要构建者去建立三者的联系，比如你想实现一个访客系统，在表单驱动的模型里，你只需要在表单里，拖拉拽选择你需要的字段，定义好名称和字段间的逻辑关系，完成了应用的构建。
但在模型驱动里，首先需要在数据库里建张表，定义好表里的字段，然后去前端开发的工具里，拖拉拽前端的控件，把后端刚刚定义好的字段和控件关联上，如果有页面跳转、按钮点击等事件，还需要定义好这些事件的逻辑关系，这样才算是应用构建完成。
好处是符合技术人员开发逻辑，技术人员可以快速用起来，首先比较复杂的产品需求，缺点是基本把非技术人员拒之门外了。
目前国内模型驱动的产品包括ClickPaaS、活字格，国外Power platform、mendix、outsystems，都是这个思路。
从市场表现来看，表单驱动的产品市场空间有限，从用户需求上，虽然实现了非技术人员做简单应用的需求，但无法承接复杂应用的开发，分析此类产品的官网案例可以发现，目前应用的场景都是企业边缘应用，可从侧面佐证这一点，另外一个可以印证的数据是，此类型的产品发展了4-5年，头部营收规模约在千万，增长还是有瓶颈。
从市场发展预期来看，个人认为表单驱动型产品可持续性不强，无法满足企业深度信息化的需求。一是产品架构决定了产品整体的技术可拓展性较弱，非技术人员能实现的需求有限，技术人员无法快速了解这种架构的底层逻辑，进行二开时可能成本会更高，所以长期来看，只能覆盖企业服务里的边缘性场景，这种场景下的用户付费意愿相对较弱；
而模型驱动产品，在技术圈是收到更多肯定，国外低代码路线也是一直沿着技术驱动来进行，国内目前此类产品的盈利模式是打造自身的ISV生态，与ISV合作，ISV寻找客户资源，aPaaS产品作为工具，从中收取授权费用。
从市场表现上，国内ClickPaaS获得b轮融资，资本市场还是比较看好这种模式，但是目前此类产品年营收也在千万，每家产品都非常注重打造自身产品的影响力，希望通过培养了ISV的工具习惯，来形成市场壁垒。
从市场预期上，回到最初的话题，模型驱动产品在短期切入技术人员，为技术人员提效肯定是没有问题，但若不能解决让非技术人员也能用得懂的问题，其市场也会很容易碰到天花板。在中国，aPaaS产品发展也存在国情的特殊性，中国人力成本低于美国，大量外包的存在让IT成本并不是很高，aPaaS工具即使能帮技术人员提效50%，给企业带来的收益也是比较有限的，企业的付费意愿自然就会减弱；所以模型驱动的路径没有问题，但长期来看，需要考虑这种路径下，如何让非IT人员也能用得懂。
总结下来，理想的aPaaS产品应该是技术&非技术人员都友好的产品。但如何实现还是需要长期探讨的话题，或许可以参考Excel，一个产品，两种模式，面向两种不同的群体，普通业务人员，熟练应用表格的公式，就可以实现复杂的场景，技术人员可以通过VBA实现进阶的需求。
把aPaaS产品的官网看一遍后，可以发现目前宣传的场景主要是“企业应用”，那由此产生三个问题：
关于为什么是“企业应用”？我是从“可实现性”和“市场空间”两个维度理解。
“可实现性”上来说，“企业应用”是标准化程度很高的产品，很容易抽象出通用型的实现方案与流程。企业业务系统高度抽象可以总结为4个部分（以报销申请系统为例）：
那从aPaaS产品的维度，来拆解业务系统，对应需要提供的低代码能力：
这样再来看power platform的产品矩阵，power app对应页面设计器，power automate对应流程&自动化引擎，power bi对应BI引擎，data verse对应元数据引擎，而AI builder & data connector则对应连接和智能能力的深化。
相比于个性化程度非常高的其他产品，企业应用是“可实现性”决定了他成为aPaaS产品切入的第一步。
“市场空间”则看谁愿意为这个类型的产品付钱。宏观而言，企业信息化是大趋势，而中国企业信息化的程度很低，尤其是中小企业，所以这块有比较高的市场天花板；具体到付钱的人，企业应用一般满足的是企业降本增效防风险的目的，是可以直接给企业带来利润率的提升。
比如之前一个案例，信息化后，一个制造锅炉厂把他们的仓库管理起来，让整体采购、生产、销售的效率提高了，老板自然就愿意为此付费。
aPaaS产品是工具，企业需要的解决问题的应用。如何跨越这一gap，实现aPaaS产品到“企业应用”？
第一个思路是“卖工具”，企业或ISV用工具来搭建“企业应用”。工具永远是工具，只有放在会使用的人手上才能发挥价值。
理想思路上，企业管理者有一套成熟的管理方法，用aPaaS工具搭建管理系统，事件自己的管理思想，实际情况是，管理者不一定有管理方法论，有方法论的管理者不一定有时间亲自搭建这样的系统。
落到采购人员这里，除非是it人员抱着采购工具的目的去，企业直接采购工具的概率是比较低的，毕竟采购完了，谁去搭建解决方案呢。
目前市面上，卖工具的aPaaS产品，最大的客户是咨询公司&ISV，咨询公司在做管理咨询时，顺便卖一套应用，ISV用更高效的方式实现企业的需求，提高自己的利润。所以之前明道云的老板提到，明道云衍生的isv市场规模比明道云本身流水高多了。
当然这个思路上，aPaaS厂商的话语权就比较低，尤其目前aPaaS产品百花齐放的时候，而且所谓产品能力，除非真的吊打竞争对手，一般很难拉起护城河。
第二个思路是卖“标准化解决方案”，aPaaS产品先把自己打造成一个企业应用市场，用自己的工具搭建行业化、场景化的解决思路。企业不想自己搭，没关系，你直接免费拿去用，用得不顺心，有个性化的需求，你再学习下我这工具的使用逻辑，自己按照想法改。
等企业越用越深了，再按照SaaS模式，按人头收取年费。
一般这样的模式，如果没有处理好和客户的关系，客户提的定制化需求&服务越来越多，企业的服务模式就会越来越重。
目前进行商业化的产品，基本都是面向企业应用，但我认为，apaas的最终目标还是以简单方式，实现所有应用类型的构建。
以头部的power platform为例，除了刚刚提到的面向企业应用的产品矩阵，power platform还提供vitual agent、AI builder这种探索性产品，通过把AI能力工具化，让不同类型企业都能够用比较低的成本，实现智能化的需求，同时power automate里提供的桌面流需求，是面向C端的需求，也并非企业应用的一部分。
整体思路上，power platform为代表的apaas产品，在尝试能力工具化的路径，能够封装的能力都可以打造为零代码的组件，最终为用户提供下一代的“Excel”，不论是企业还是个人，都可以用以实现数据分析、AI识别等能力。
本文由@弓弓田 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。