編輯導(dǎo)語：從用戶的視角理解aPaaS產(chǎn)品，它的定位應(yīng)該是一個工具型產(chǎn)品，能幫助所有想開發(fā)app的人，用更簡單的方式和更低的成本來實現(xiàn)app的開發(fā)。那么，aPaaS產(chǎn)品面向的群體用戶和場景是什么呢？一起來看一下吧。

01 什么是“aPaaS產(chǎn)品”？

aPaaS產(chǎn)品的英文全稱是 application platform as a service，是在云計算的platform as a service 的服務(wù)模式上演化而來，強調(diào)在講云計算平臺層的軟件，開發(fā)能力作為一種服務(wù)，提供給用戶。

“aPaaS”的概念是從技術(shù)開發(fā)者的視角，解釋這類型的產(chǎn)品在云服務(wù)的整個體系的定位：即aPaaS產(chǎn)品不是PaaS類型產(chǎn)品，只服務(wù)于技術(shù)人員，也不是SaaS產(chǎn)品，可以面向最終的用戶，而是作為PaaS和SaaS的中間層，通過對開發(fā)、運維過程的任何有開發(fā)app需求的用戶，都可以使用aPaaS產(chǎn)品來開發(fā)他們的個性化app。

如果從用戶視角來理解aPaaS產(chǎn)品，它的定位應(yīng)該是一個工具型產(chǎn)品，幫助所有想要開發(fā)app的人，用更簡單的方式和更低的成本來實現(xiàn)app的開發(fā)。但關(guān)于如何定義這個需求，拆解具體的產(chǎn)品功能方案，目前而言都還是摸索的過程。

02 aPaaS產(chǎn)品面向的用戶群體到底是誰？

從長遠來看，aPaaS產(chǎn)品的愿景肯定是希望實現(xiàn)全民開發(fā)，讓沒學(xué)過編程的人，也能輕松開發(fā)自己的app，這一點目前業(yè)界是共識的。原因如下：

但短期而言，第一步應(yīng)該切“技術(shù)人員”還是“非技術(shù)人員”，各產(chǎn)品的看法有所不同。

1. 面向業(yè)務(wù)人員的零代碼

一部分廠商以業(yè)務(wù)人員為切入點，同時提供代碼進行二開的能力。

此部分廠商提供的解決方案是表單驅(qū)動，從應(yīng)用構(gòu)建者的視角，不需要區(qū)分前端展現(xiàn)層和后端數(shù)據(jù)結(jié)構(gòu)，二者是完全綁定，自動生成，搭建應(yīng)用時，在表單引擎里定義需要的字段，管理后臺table里自動生成數(shù)據(jù)結(jié)構(gòu)；提供集成&自動化引擎、BI功能，支持數(shù)據(jù)流轉(zhuǎn)和商業(yè)智能。

好處是去除了復(fù)雜的技術(shù)概念，非技術(shù)人員在使用時，理解成本較低，不過也正是因為這種簡化，在產(chǎn)品能力在解決復(fù)雜需求上，會有所不足。

目前國內(nèi)表單驅(qū)動的典型產(chǎn)品包括明道云、簡道云、伙伴云、宜搭，國外表單驅(qū)動的產(chǎn)品包括Zoho Creator。

2. 面向技術(shù)人員的低代碼

另一部份廠商以技術(shù)人員為切入點，整體邏輯是通過提供封裝好的組件，來對軟件開發(fā)的流程做簡化。

此部分廠商提供的解決方案是模型驅(qū)動，從應(yīng)用構(gòu)建者的視角、應(yīng)用的前端、后端、邏輯層各自獨立，需要構(gòu)建者去建立三者的聯(lián)系，比如你想實現(xiàn)一個訪客系統(tǒng)，在表單驅(qū)動的模型里，你只需要在表單里，拖拉拽選擇你需要的字段，定義好名稱和字段間的邏輯關(guān)系，完成了應(yīng)用的構(gòu)建。

但在模型驅(qū)動里，首先需要在數(shù)據(jù)庫里建張表，定義好表里的字段，然后去前端開發(fā)的工具里，拖拉拽前端的控件，把后端剛剛定義好的字段和控件關(guān)聯(lián)上，如果有頁面跳轉(zhuǎn)、按鈕點擊等事件，還需要定義好這些事件的邏輯關(guān)系，這樣才算是應(yīng)用構(gòu)建完成。

好處是符合技術(shù)人員開發(fā)邏輯，技術(shù)人員可以快速用起來，首先比較復(fù)雜的產(chǎn)品需求，缺點是基本把非技術(shù)人員拒之門外了。

目前國內(nèi)模型驅(qū)動的產(chǎn)品包括ClickPaaS、活字格，國外Power platform、mendix、outsystems，都是這個思路。

3. 市場表現(xiàn)和發(fā)展預(yù)期

從市場表現(xiàn)來看，表單驅(qū)動的產(chǎn)品市場空間有限，從用戶需求上，雖然實現(xiàn)了非技術(shù)人員做簡單應(yīng)用的需求，但無法承接復(fù)雜應(yīng)用的開發(fā)，分析此類產(chǎn)品的官網(wǎng)案例可以發(fā)現(xiàn)，目前應(yīng)用的場景都是企業(yè)邊緣應(yīng)用，可從側(cè)面佐證這一點，另外一個可以印證的數(shù)據(jù)是，此類型的產(chǎn)品發(fā)展了4-5年，頭部營收規(guī)模約在千萬，增長還是有瓶頸。

從市場發(fā)展預(yù)期來看，個人認為表單驅(qū)動型產(chǎn)品可持續(xù)性不強，無法滿足企業(yè)深度信息化的需求。一是產(chǎn)品架構(gòu)決定了產(chǎn)品整體的技術(shù)可拓展性較弱，非技術(shù)人員能實現(xiàn)的需求有限，技術(shù)人員無法快速了解這種架構(gòu)的底層邏輯，進行二開時可能成本會更高，所以長期來看，只能覆蓋企業(yè)服務(wù)里的邊緣性場景，這種場景下的用戶付費意愿相對較弱；

而模型驅(qū)動產(chǎn)品，在技術(shù)圈是收到更多肯定，國外低代碼路線也是一直沿著技術(shù)驅(qū)動來進行，國內(nèi)目前此類產(chǎn)品的盈利模式是打造自身的ISV生態(tài)，與ISV合作，ISV尋找客戶資源，aPaaS產(chǎn)品作為工具，從中收取授權(quán)費用。

從市場表現(xiàn)上，國內(nèi)ClickPaaS獲得b輪融資，資本市場還是比較看好這種模式，但是目前此類產(chǎn)品年營收也在千萬，每家產(chǎn)品都非常注重打造自身產(chǎn)品的影響力，希望通過培養(yǎng)了ISV的工具習(xí)慣，來形成市場壁壘。

從市場預(yù)期上，回到最初的話題，模型驅(qū)動產(chǎn)品在短期切入技術(shù)人員，為技術(shù)人員提效肯定是沒有問題，但若不能解決讓非技術(shù)人員也能用得懂的問題，其市場也會很容易碰到天花板。在中國，aPaaS產(chǎn)品發(fā)展也存在國情的特殊性，中國人力成本低于美國，大量外包的存在讓IT成本并不是很高，aPaaS工具即使能幫技術(shù)人員提效50%，給企業(yè)帶來的收益也是比較有限的，企業(yè)的付費意愿自然就會減弱；所以模型驅(qū)動的路徑?jīng)]有問題，但長期來看，需要考慮這種路徑下，如何讓非IT人員也能用得懂。

總結(jié)下來，理想的aPaaS產(chǎn)品應(yīng)該是技術(shù)&非技術(shù)人員都友好的產(chǎn)品。但如何實現(xiàn)還是需要長期探討的話題，或許可以參考Excel，一個產(chǎn)品，兩種模式，面向兩種不同的群體，普通業(yè)務(wù)人員，熟練應(yīng)用表格的公式，就可以實現(xiàn)復(fù)雜的場景，技術(shù)人員可以通過VBA實現(xiàn)進階的需求。

02 aPaaS產(chǎn)品面向的場景是什么？

把aPaaS產(chǎn)品的官網(wǎng)看一遍后，可以發(fā)現(xiàn)目前宣傳的場景主要是“企業(yè)應(yīng)用”，那由此產(chǎn)生三個問題：

1. 為什么是“企業(yè)應(yīng)用”？
2. 如何面向“企業(yè)應(yīng)用”？
3. 是不是只有“企業(yè)應(yīng)用”？

1. 為什么是企業(yè)應(yīng)用？

關(guān)于為什么是“企業(yè)應(yīng)用”？我是從“可實現(xiàn)性”和“市場空間”兩個維度理解。

“可實現(xiàn)性”上來說，“企業(yè)應(yīng)用”是標(biāo)準(zhǔn)化程度很高的產(chǎn)品，很容易抽象出通用型的實現(xiàn)方案與流程。企業(yè)業(yè)務(wù)系統(tǒng)高度抽象可以總結(jié)為4個部分（以報銷申請系統(tǒng)為例）：

• 業(yè)務(wù)數(shù)據(jù)收集：報銷申請系統(tǒng)，首先需要有申請單的頁面，員工可填報
• 業(yè)務(wù)數(shù)據(jù)流轉(zhuǎn)：員工填報完畢后，這個申請單需要流轉(zhuǎn)到審批人
• 業(yè)務(wù)數(shù)據(jù)存儲：申請整個流程完成后，需要歸檔，要考慮數(shù)據(jù)存儲在哪里
• 業(yè)務(wù)數(shù)據(jù)使用：當(dāng)沉淀了大量申請數(shù)據(jù)時，可以進行智能分析，比如看報銷額分布等

那從aPaaS產(chǎn)品的維度，來拆解業(yè)務(wù)系統(tǒng)，對應(yīng)需要提供的低代碼能力：

• 頁面設(shè)計器：提供不同的字段來方便用戶進行落地頁的搭建
• 流程&自動化引擎：實現(xiàn)數(shù)據(jù)在不同應(yīng)用、不同成員間的自定義流轉(zhuǎn)
• 元數(shù)據(jù)引擎：支持定義數(shù)據(jù)結(jié)構(gòu)，實現(xiàn)頁面設(shè)計器數(shù)據(jù)的存儲
• BI引擎：支持對沉淀的數(shù)據(jù)進行不同維度分析

這樣再來看power platform的產(chǎn)品矩陣，power app對應(yīng)頁面設(shè)計器，power automate對應(yīng)流程&自動化引擎，power bi對應(yīng)BI引擎，data verse對應(yīng)元數(shù)據(jù)引擎，而AI builder & data connector則對應(yīng)連接和智能能力的深化。

相比于個性化程度非常高的其他產(chǎn)品，企業(yè)應(yīng)用是“可實現(xiàn)性”決定了他成為aPaaS產(chǎn)品切入的第一步。

“市場空間”則看誰愿意為這個類型的產(chǎn)品付錢。宏觀而言，企業(yè)信息化是大趨勢，而中國企業(yè)信息化的程度很低，尤其是中小企業(yè)，所以這塊有比較高的市場天花板；具體到付錢的人，企業(yè)應(yīng)用一般滿足的是企業(yè)降本增效防風(fēng)險的目的，是可以直接給企業(yè)帶來利潤率的提升。

比如之前一個案例，信息化后，一個制造鍋爐廠把他們的倉庫管理起來，讓整體采購、生產(chǎn)、銷售的效率提高了，老板自然就愿意為此付費。

2. 如何面向企業(yè)應(yīng)用？

aPaaS產(chǎn)品是工具，企業(yè)需要的解決問題的應(yīng)用。如何跨越這一gap，實現(xiàn)aPaaS產(chǎn)品到“企業(yè)應(yīng)用”？

第一個思路是“賣工具”，企業(yè)或ISV用工具來搭建“企業(yè)應(yīng)用”。工具永遠是工具，只有放在會使用的人手上才能發(fā)揮價值。

理想思路上，企業(yè)管理者有一套成熟的管理方法，用aPaaS工具搭建管理系統(tǒng)，事件自己的管理思想，實際情況是，管理者不一定有管理方法論，有方法論的管理者不一定有時間親自搭建這樣的系統(tǒng)。

落到采購人員這里，除非是it人員抱著采購工具的目的去，企業(yè)直接采購工具的概率是比較低的，畢竟采購?fù)炅?，誰去搭建解決方案呢。

目前市面上，賣工具的aPaaS產(chǎn)品，最大的客戶是咨詢公司&ISV，咨詢公司在做管理咨詢時，順便賣一套應(yīng)用，ISV用更高效的方式實現(xiàn)企業(yè)的需求，提高自己的利潤。所以之前明道云的老板提到，明道云衍生的isv市場規(guī)模比明道云本身流水高多了。

當(dāng)然這個思路上，aPaaS廠商的話語權(quán)就比較低，尤其目前aPaaS產(chǎn)品百花齊放的時候，而且所謂產(chǎn)品能力，除非真的吊打競爭對手，一般很難拉起護城河。

第二個思路是賣“標(biāo)準(zhǔn)化解決方案”，aPaaS產(chǎn)品先把自己打造成一個企業(yè)應(yīng)用市場，用自己的工具搭建行業(yè)化、場景化的解決思路。企業(yè)不想自己搭，沒關(guān)系，你直接免費拿去用，用得不順心，有個性化的需求，你再學(xué)習(xí)下我這工具的使用邏輯，自己按照想法改。

等企業(yè)越用越深了，再按照SaaS模式，按人頭收取年費。

一般這樣的模式，如果沒有處理好和客戶的關(guān)系，客戶提的定制化需求&服務(wù)越來越多，企業(yè)的服務(wù)模式就會越來越重。

3. 是不是只面向“企業(yè)應(yīng)用”

目前進行商業(yè)化的產(chǎn)品，基本都是面向企業(yè)應(yīng)用，但我認為，apaas的最終目標(biāo)還是以簡單方式，實現(xiàn)所有應(yīng)用類型的構(gòu)建。

以頭部的power platform為例，除了剛剛提到的面向企業(yè)應(yīng)用的產(chǎn)品矩陣，power platform還提供vitual agent、AI builder這種探索性產(chǎn)品，通過把AI能力工具化，讓不同類型企業(yè)都能夠用比較低的成本，實現(xiàn)智能化的需求，同時power automate里提供的桌面流需求，是面向C端的需求，也并非企業(yè)應(yīng)用的一部分。

整體思路上，power platform為代表的apaas產(chǎn)品，在嘗試能力工具化的路徑，能夠封裝的能力都可以打造為零代碼的組件，最終為用戶提供下一代的“Excel”，不論是企業(yè)還是個人，都可以用以實現(xiàn)數(shù)據(jù)分析、AI識別等能力。

本文由@弓弓田 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自unsplash，基于CC0協(xié)議。