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