aPaaS 解决的究竟是什么问题？本篇文章里，作者从更为落地的视角，探讨了 aPaaS 的解决方案、AI 对 aPaaS 的影响等方面，我们不妨来看一下。
两年前，在写《关于 aPaaS 的思考（上）》时，正在求职关口，本质输出就是最好的思考方式，分享了我对下面 3 个问题的思考：
这两年里又一头扎入「模型驱动」的 aPaaS 产品中，在宏观商业模式模式的思考外，补充了很多更落地的视角。再次站在职业选择的路口，补上《关于 aPaaS 的思考（下）》，也算是给自己的阶段性小结。
相比两年前，对于这个问题，我的视角会有所不同。
零代码的视角：从无序到有序，提高中小企业的经营效率
在做零代码时，我们关注的是从无到有，是中小企业「管理思路」的工具化。我们判断中小企业，由于缺少高性价比的数字化管理工具，会导致企业整体经营效率会比较低。
比如：百人以内的电商代运营团队，每天花费大量人力用电子表格来进行库存管理。
低代码的视角：降低内部系统的成本
而在最近工作的两年里，观察市场上在投入 aPaaS 方向的企业，更多是中大型公司，而其核心的动机是「如何以更低的成本迭代各种内部系统」以满足企业快速发展的诉求。
比如：A 公司内部已经有了 OA、人力、差旅等多个系统，但是系统数据不打通，希望搭建 aPaaS 层的工具，实现系统层的数据、流程互通。
B 公司存在大量业务线需要客服工具，于是中台打造通用客服产品，但是发现业务支持时，存在大量个性化需求，迭代不过来，于是搭建 aPaaS 工具层，快速响应。
所以从企业视角，本质都是解决「企业应用」的问题，主要是看解决「中小企业的从无到有」，还是「大企业的从有到优」，而这两种思路，从商业化上，各自有其需要解决的问题，商业化尚待验证：
专注解决「中小企业的从无到有」：这类客户画像是缺少 IT 能力的，要求产品上手门槛低，且会非常注重性价比，客单价也会低。这些要素决定了零代码产品，本身产品上无法搭建复杂度过高的应用，商业上无法实现高客单价，需要通过「走量」来拉升商业空间。
那最大的难点是：「量」如何走起来？一定不是依赖厂商自身的服务能力，最好的预期是产品门槛足够低，中小企业能在教学资料的辅导下，自己完成闭环，退而求其次就是建立生态。
专注解决「大企业的从有到优」：这类客户要么已有自研产品、要么已经采购 SaaS 系统，这些企业应用的复杂度一般较高，对于 aPaaS 产品的天花板要求也更高。
对于 aPaaS 来说，产品上的难点是底层如何抽象，既能实现提效又能保持能力的灵活性和天花板，商业上的难点是如何证明采用 aPaaS 的解决方案，可以给客户省钱，能省多少钱 – aPaaS 是工具，客户有诉求找过来，无法开箱即用，要证明这个价值，比如有人力投入进来，先把应用搭起来，那价值被证明前，客户是肯定不愿意投人，厂商就需要自己解决这个问题，就会导致服务成本很高。
另外一个思路是，场景化的打造1-2个标杆产品，用于价值的证明，但是大企业的需求，又极个性化。所以产品 & 商业的这两个难题，还是在摸索中前进。
本质上，aPaaS 是搭建应用的工具，对于个人用户而言，如果有一定的抽象能力，也是可以用 aPaaS 解决很多个人场景的问题。比如：
还有一个小例子，有一次我希望找一个 PDF 分割的工具，网上找了几个都要付费，最后用 Power Automate 的桌面流，几分钟解决了。当然，Power Automate 的桌面流能做到的事情还有很多很多。
其实，我最开始对 aPaaS 产生兴趣，也是因为 Ta 让我这样一个学文科、完全没有代码经验的同学，能够按照我的个人意愿，搭建个人知识管理的应用。
总结起来，其实对于个人而言，aPaaS 是一个极其灵活、且门槛相比写代码更低的工具，能帮个人去快速实现一些小的需求。
但是市面上，面向个人的 aPaaS 产品很少，几乎没有，除了微软 Power Platform 的全家桶套装，我基本没接触到其他面向个人用户，也能使用的 aPaaS 产品（也许是我见识少…
这个从商业上，也可以理解：
首先从用户规模上，aPaaS 仅提供工具，不提供实际解决需求的产品，对于用户而言，无法解决动力问题，为什么我不去直接找一个解决我问题的产品，而是要研究这个工具来搭建，而且这个学习成本还不低。所以面向 C 端，aPaaS 本身就是无法规模化的产品，很难从流量的道路挣钱。
其次从工具的视角，去订阅，也许是一个思路。但是作为工具，aPaaS 面向的场景有没有那么明确，是需要用户自己去发现需求，再去解决，不像是 Photoshop 这类的工具产品，场景很纵深（虽然在国内也不一定赚到钱）。
所以面向个人，有价值，但是商业上可以想象的空间不多。👇下面聊到的部分，会以企业场景为主。
由于 aPaaS 本质是「应用开发」工具，那 aPaaS 产品本身就是从「全代码」-「无代码」中间的平衡。
但是在产品设计上，其实二者的抽象思路还是有很大的区别：
零代码是从业务层往下抽象，基于企业应用的通用属性，抽象对应的产品功能。
低代码是从技术层往上抽象，基于代码开放的路径和工具进行封装，实现产品功能。
简单的业务系统，业务层基本可以抽象为四个通用的部分：数据收集、流转、存储、分析。对应零代码的主要功能模块如上：
同时，为了更大程度，降低用户的使用成本，表单：数据表在结构关系上，基本是 1:1 绑定，部分产品流程：表单：数据表也是1:1:1绑定。在搭建表单时，就完成了数据表的搭建，同时可以基于表单搭建对应的数据流程。此类架构，默认帮用户完成了前端和数据的绑定关系，极大降低用户的搭建成本，但也降低了灵活性。如果业务希望搭建个性化的前端界面或者是有灵活的数据关系，可能就没办法实现。
这里再次 call back 到上文提到的零代码产品在商业上的难点，很多零代码产品无法解决量的问题，到千万量级基本就会遇到营收的瓶颈。部分产品此时选择的路径，可能是朝着低代码转型，强化其二开能力，提高客单价，个人认为，这不一定是好的思路，架构上的转向是很难的，要么另起新产品，要么还是可以考虑下零代码在产品力上，如何更好满足中小企业诉求，同时又能开箱即用，同时在渠道上，看如何能更好找到中小企业的客户。
从开发一个 APP 的研发工程来进行抽象，得到对应的产品能力：
各模块之间相关独立，无耦合，可以通过调用和绑定来实现特定逻辑，比如页面需要展示指定数据，需要页面去主动查询获取指定数据并且绑定在页面组件。
优点是，产品极其灵活+个性化，能搭建千人千面的应用，问题是配置成本极高。而到具体功能设计中，每个产品的封装程度各不相同，比如一些模型驱动的产品，为减少配置成本，会通过一些配置，默认帮用户进行数据的绑定，而另一些产品则会更倾向于减少封装逻辑，足够原子化，操作权交给用户。
抽象的中台的 SaaS 产品支持各业务线，但是发现业务线的定制化需求多，导致产品迭代成本越来越高。于是希望借助 aPaaS 产品来沉淀底层配置化能力，实现对业务支持的提效。
支持企业内部应用开发的技术部门：企业快速发展，存在大量内部系统的需求，不希望借助外部 SaaS 产品，还是以自研为主，同时作为成本部门，又希望能以较低的成本支持内部系统的落地。于是希望搭建企业内部的 aPaaS 工具，借助 aPaaS 工具，完成内部系统的快速搭建。
已有 SaaS 标品，在支持客户时需要响应大量个性化诉求，但做定制化开发，投入产出比低，于是在标品的基础上，沉淀 aPaaS 工具层，基于 aPaaS 工具层，在标品上拓展个性化开发的诉求。
本身无 SaaS 标品，仅提供 aPaaS 的工具能力，在产品运营层，提供各场景和行业的解决方案，切入客户场景。需要考虑在和 SaaS 产品竞争时，自身的核心优势是什么，相比在垂直领域深耕的 SaaS 产品，可能是缺乏行业 Know how 的。
对零代码的冲击，应该很小。零代码面向的是中小客，本身缺少 IT 能力，当前 AI 也无法直接搭建一个数字化应用，只能在片段化的场景提效。
对低代码产品，可能会有些冲击，AI 和 aPaaS 都定位是面向有 IT 能力的企业，提升开发效率的工具。AI 在代码写作能力上，已经有很好的应用了，能实现提效的目标，且从实际用户-程序员的接受度上，使用 AI 来帮我写片段化的代码 vs 学习一个可能其他公司都不会用的 aPaaS 工具来实现业务需求，当然前者对自身的成长更有帮助。
不过二者也并不是互斥的，AI + 全代码开发 vs AI + 低代码开发，可能后者还是效率会更高，所以 aPaaS 产品如何在搭建侧更好融入 AI 的能力，也是未来一个机会。比如 Zapier 已经支持 AI 去帮忙搭建流程的节点、实现数据的转化等，还有些产品支持 AI 直接生成页面，同时用户可以手动对页面进行微调。
除了 AI + 低代码外，很多公司在探索 Native AI 的应用，这其中也融合很多低代码的能力，比如工作流的搭建、数据库的管理、API 的管理等
总结起来，AI 对零代码的场景，基本无冲击，AI 能部分解决低代码解决的问题，如果低代码产品能很好融合 AI 的能力也可能是更大的机会。同时 Native AI 应用的探索，也需要借鉴低代码产品的能力和产品思路
本文由 @弓弓田 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。