關于 aPaaS 產品的思考(下)

0 評論 3382 瀏覽 4 收藏 15 分鐘

aPaaS 解決的究竟是什么問題?本篇文章里,作者從更為落地的視角,探討了 aPaaS 的解決方案、AI 對 aPaaS 的影響等方面,我們不妨來看一下。

兩年前,在寫《關于 aPaaS 的思考(上)》時,正在求職關口,本質輸出就是最好的思考方式,分享了我對下面 3 個問題的思考:

  1. aPaaS 產品是什么
  2. aPaaS 產品面向的用戶是誰?
  3. 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 本身就是無法規?;漠a品,很難從流量的道路掙錢。

其次從工具的視角,去訂閱,也許是一個思路。但是作為工具,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 應用的探索,也需要借鑒低代碼產品的能力和產品思路

本文由 @弓弓田 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!