美國軟件企業Intuit公司在2000年前后推出了一個產品，叫做Quickbase，顧名思義，就是快速開發數據庫(應用)。它開了行業先河，不僅提供低代碼的企業應用開發環境，而讓應用直接在一個平臺上運行，用戶不再需要額外編譯代碼和配置運行環境。當然，在那個年代，APaaS這個品類名稱還沒有出現，一般都統稱這類應用為ASP。

[[334342]]

在接下來的十多年中，這個品類不斷發展，不僅做出了Smartsheet，Outsystems, ServiceNow這些獨立上市公司，像Salesforce和微軟也都在自己的核心產品線路中增加了APaaS能力。對于Salesforce來說，除了銷售，營銷，客服等核心應用以外，還有數千家開發者利用AppExchange市場向Salesforce用戶分發了通過APaaS平臺開發的行業應用和擴展應用。微軟在這個領域的發展可以分為兩條主線，一是Sharepoint，Dynamics的企業級軟件產品線，它們允許用戶在使用開箱應用的同時進行擴展開發，以滿足離散化的業務需求。另一條線是近兩年在Office 365產品線上延伸的Power系列產品，包括Power BI，Power Apps等，這些工具產品更多面向非代碼開發人員，有相當比例的開發者并不需要編寫代碼就能夠實現一些常見的場景，比如制作一個統計儀表盤，開發一個搜集數據的移動應用等。

所以，APaaS只是一個新的品類稱謂，但并非一個全新的品類。它在全球企業軟件市場甚至算是一個老資格了。可是為什么在2019年這個節點，國內市場對這個品類的熱度突然提高了呢?而且它的關注度還很詭異地和另外一個叫做RPA(流程機器人)的小品類聯系在一起。

Copy to China?

Copy to China的因素當然存在，和SaaS所有其他門類一樣，美國市場幾乎是一切企業軟件的策源地。從CRM，ERP到行業應用，中國從業者或多或少都借鑒了美國市場的產品。這沒有任何需要掩飾的，我們做IT行業的人從內心相信全球化的力量是社會進步的主要動力。

但是，APaaS品類和其他SaaS類型一樣，我們可以借鑒基本的方法論，但原封不動地照抄產品基本上不會有好的下場。國際產品如果想要直接進入中國市場也幾乎一定水土不服。到我寫這篇文章時，海外的APaaS產品，包括IT巨頭的相關產品線悉數都沒有進入大陸市場。

中國SaaS產品的特色已經越來越鮮明，而且在很多細節方面，做得可能已經比美國同行更好。所以，在中國重新定義APaaS產品的形態需要考慮中國國情中的這些要素：

• 用戶應用水平
• 客戶需求特點
• 開發者生態
• 應用生態

我在后面幾點會結合這四項環境差異來說明中國市場為什么特別需要APaaS，但是需要不一樣的產品形態。

真正面向非技術人員

雖說APaaS產品一直以來都降低了開發門檻，提高了效率，但是面向的用戶主要還是軟件研發人員。像Outsystems這樣的標桿產品，的確相當強大。它分離了一個應用軟件開發的所有要素，并將這些要素用可視化的方式來替代代碼開發。Outsystems對開發效率的提高并不是因為節省了代碼開發的時間，而是將常用的數據模型，業務邏輯和數據接口等都封裝成預制的組件。

即便如此，這些產品依然需要在必要的時候使用少數腳本型編程語言，比如數據查詢、表達式編寫和聯合表數據的時候。甚至它們用來開發應用的界面和一個標準的IDE開發環境都非常接近。

因為這樣的設計模式和產品復雜度，基本上把所有的非軟件工程人員排除在外了。低代碼也是代碼，一句代碼也會憋死不會寫代碼的英雄漢。APaaS對于軟件開發者來說是一個很不錯的效率工具，但絕對不是軟件產業的革命。Gartner所說的“APaaS能夠面向全民開發者(Citizen Developer)”，在這代產品上并沒有真正兌現。

所以，重做一遍APaaS最重大的意義就是讓非軟件技術人員能夠廣泛參與，讓一部分熟悉業務的業務專家能夠自助搞定絕大部分工作。為了達到這個目標，必須摒棄早期APaaS什么應用都能夠開發的目標，而重點定位那些APaaS產品具備優勢的業務領域。

在2015年以后出現的APaaS產品中，包括明道云在內，都明確樹立了這個目標。除了API對接開發，更友好的APaaS工具非常克制對腳本代碼的依賴，轉而采用可視化配置交互的方式來完成。有時候，這個過程的確非常艱難，因為要處理的情況可能非常多樣，但通過步驟分解和必要的舍棄，還是能夠成功地讓不會寫代碼的人完成必要的定義。

比如，在CRM應用中要給失效銷售線索加一個“恢復”的動作按鈕，明道云是這樣做的：

用一個可視化工作流來定義這個“恢復”按鈕。

實踐證明，這個可視化實現方式能夠被大部分業務人員掌握。對于那些邏輯思維習慣好的項目經理、產品經理來說，更加是信手拈來。

新型APaaS也竭力去除了軟件開發中過于專業的概念，比如實體、屬性、方法、函數、表達式、循環、遞歸等。這些詞匯本身有精確的含義，但是對于沒有經過計算機編程教育的人來說，掌握起來非常困難。雖然APaaS做不到像極簡的個人應用那樣言簡意賅，或者使用非常通俗的界面語言，但設計者有責任控制專業名詞的使用，每多使用一些，就多流失一些非技術型用戶。

在我們運營明道云的過程中，發現專業軟件開發者的確更容易掌握，但更讓我們興奮的是一般文職人員的上手容易度。一位銷售經理可能直接完成銷售漏斗的應用搭建;一位人事經理可能自己就能夠做一個小型EHR系統，甚至做到自動化的制薪。

圖是我們一位客戶老板(非技術人員)搭建的定制ERP系統。他一個人就搞定了。

為什么一定要讓非技術人員參與企業應用開發，除了提高效率，減少需求溝通的成本以外，還有一個非常重要的原因。這個我在后面還會重點說明。

APaaS的客戶需求和利基市場

APaaS只是一個軟件品類，它是軟件產業的革新，但并不可能替代其他的軟件品類。有人會望文生義地理解零代碼軟件開發，甚至問“那我們還要招聘程序員干嗎?”。提出這種挑戰的人顯然對軟件產業的復雜性缺乏了解。零代碼或者低代碼開發，并不針對所有類型應用的開發工作。

如果把整個軟件產業放到一個坐標上，我們可以按照需求的標準化程度作為橫軸。顯然，需求最普遍的，也是最標準的，從操作系統，數據庫，應用軟件到各種工具軟件，占據了軟件產業的大部分比例。這部分是任何其他解決方案都望塵莫及的，因為創新和差異化很難干得過規模化優勢和網絡效應。

但是在企業應用領域，往右延伸的長尾則包含了大量標準化程度越來越低的需求。沒有人真正統計過中國軟件產值(2017年大約在25000億人民幣左右)中標準化產品授權和定制集成類外包服務收入的比例。我猜測這個比例大約在50/50左右。大量產品型公司其實也提供圍繞自己產品的集成和定制服務。

那么這些長尾需求到底因何出現呢?

1. 業務離散度

所謂離散度高，就是分布的規律性差。在不同行業中，業務離散度高低本來就不均勻。比如像餐飲酒店業，它的業務運營標準化程度就很高，幾乎所有的同規模企業都是按照基本一致的協作流程來運行的，產品和服務在一段時間內也都相當穩定，即便有經營上的差異化，也和信息系統關聯不大。相反，像按單制造業就完全是另外一個極端，訂單有大有小，今天可能是這個產品，明天可能是另外一個產品。極端情況下，可能每個訂單都不一樣。這樣的行業一般不得不進行同業協作，所以訂單生產既包括自己生產也包括外包外協。在這種情況下，標準化的軟件產品能夠解決的問題非常有限，企業如果想要精細化管理業務數據和流程，就不得不訴諸于定制開發。

2. 業務差異化

差異化是企業之間競爭的結果。有的來自企業的主動追求，有的來自被動的競爭擠壓。不管是因為何種動因，企業總希望能夠和競爭對手的做法不一樣。標準化信息系統也可能無法滿足這類企業的需要。舉例來說，像瑞幸咖啡，喜茶這樣的連鎖餐飲企業，就不可能滿足于一個標準化的餐飲收銀系統，它們必須圍繞自己的運營策略，建立差異化的信息系統。這兩個例子當然都屬于規模較大的企業，但在中小企業中，因為競爭擠壓帶來的差異化需求也非常普遍，比如我認識的一家律師事務所就專注于知識產權業務，更具體地來說，他們專門幫助品牌在淘寶等電商平臺上打假維權。面對這種差異化業務，普通的律所業務管理系統當然滿足不了他們。

3. 各類集成需求

除了業務離散度和差異化帶來的定制需求，還有各種集成需求帶來的非標準化。每個公司都可能要使用不同的應用組合，用不同的員工賬戶管理平臺，業務數據也分散在不同的數據源和應用中。這時候就存在繁多的集成對接關系。有的是要將金蝶的ERP數據集成到定制的MES中，有的是要將定制的CRM應用和用友的財務軟件打通，有的需要將應用通知和釘釘、企業微信的消息打通，還有越來越多的企業需要建立一個能夠脫離應用系統的數據中臺，以方便拓展新的業務流程。所有這些集成需求一般都是通過定制開發的方式來實現的。我們一般把集成開發需求歸納為數據集成，用戶集成和應用集成幾個方向。APaaS的兩個兄弟品類—RPA(流程機器人)和IPaaS(整合平臺即服務)幾乎專門是為了集成需求而產生。

早期出現的APaaS的確也是重點圍繞這些長尾需求的。同樣以Outsystems這個標桿產品為例，在它的解決方案中，顧客體驗提升，運營效率提升，傳統系統現代化，SAP擴展，現場服務優化和數字化轉型幾乎全部落在這些長尾需求區間。

如果辨明了APaaS的目標利基市場，我們就可以圍繞中國市場當下的需求特點來重新設計APaaS產品主要解決的問題。

• 離散制造和工程領域的數字化管理(Customization Oriented)
• 外部協作環節，包括各類現場管理，數據搜集和供應鏈協作(Externalization Oriented)
• 從既有應用中抽取或同步數據，形成可高效開發的數據中臺(Integration Oriented)
• 不再依賴過多的套裝軟件，利用自有IT力量建立一體化的信息化系統，實現最大程度的數據互通和靈活度(Versatility Oriented)

至于各種集成需求，中國市場的應用環境和歐美幾乎完全不同。除了相對標準的關系數據庫和Restful API集成源以外，其他的應用數據集成都要重新根據國內生態重新做一邊。美國有Shopify的訂單，國內是電商ERP;美國用Salesforce，Dynamics，國內是銷售易、紛享銷客;美國用Google Suite，國內有釘釘、企業微信和飛書。雖然國內產品目前的開放度非常糟糕，但有了APaaS和IPaaS品類的助力，應用之間，應用和平臺之間的數據互通完全是可以實現的。

建立不一樣的生態或依存關系

最后一個原因：生態!

不過不要誤解，我說的不是軟件行業常見的“開發者生態”，而是更加容易建立的“業務專家依存關系”。

首先，任何低代碼或者零代碼開發平臺都很難有條件建立起繁榮的開發者生態。即便是最領先的Salesforce Appexchange，十多年來也只積累了3000多個應用，而且這當中絕大多數都是其他產品的連接器性質應用。這當中最主要的原因就是企業應用很難建立網絡效應，你用SAP，我用金蝶用友，并沒有什么關系。所以，即使市場占有率較高的平臺，也與一統天下距離甚遠。

所以，作為APaaS廠商，必須理性看待所謂建設生態的目標。生態不是一統天下，而是建立和不同角色的主體相互依存的關系。零代碼定位的APaaS帶來了一個優勢，它能夠吸引過往無法參與企業軟件建設的新群體——業務專家。

我在前面提到重建APaaS產品的第一個目標是真正面向非技術人員。但它真正的用意不僅僅是讓企業軟件開發擺脫對軟件工程師的依賴，還包括連接企業軟件的智慧來源——業務專家。

在企業軟件設計和開發中，最困難的過程不是寫代碼，而是理解業務需求。這個過程沒有任何廠商敢說是毫無問題的。很多垂直行業軟件公司為了讓產品能夠很好地滿足客戶需求，不得不聘請大量的行業專家，甚至有的時候不惜自己親自去運營相關業務。我就知道有一家酒店PMS廠商自己開了一家酒店，一家做健身會所管理的行業SaaS自己就是健身房老板出身。但不是所有的時候都能夠有這樣的奢侈，企業的離散業務需求不可能讓軟件設計人員親自靠運營業務來理解需求，所以我們這個行業始終面對著業務專業能力和軟件架構能力之間的斷層。

如果企業有足夠多的錢，當然可以通過聘請一流的咨詢公司，考察全球最佳實踐，引進最好的行業解決方案，再聘請經驗最豐富的實施公司來完成落地。但這個過程即便對財富500強公司來說，都是一筆不小的投入。

最好的辦法，就是讓業務專家自己能夠動手完成大部分工作。這就回到本文一開頭對現有APaaS產品的詬病。它們還不是真正意義上的面向業務專家的平臺。業務專家根本上不了手，更不用說兌現出完整的信息化方案了。

因此，做新一代的APaaS，不僅要提供零代碼，低門檻的技術工具，還要能夠幫助業務專家相互借鑒，跨行業學習，平臺內共享，并最終允許業務專家構筑和分發這些解決方案。如果某一位制造業專家過去依靠Excel和管理方法論解決了某行業的生產質量管理問題，那么他也一定能夠通過這一代的APaaS平臺構筑出更卓越的軟件方案，將Excel不能克服的問題解決得更好。他不僅能夠獲得咨詢和培訓收入，還能夠合理地通過這個軟件方案得到訂閱性收入。而因為他所付出的成本和技術門檻都足夠的低，企業客戶所需要支付的代價和實施風險也會同步降低。

我所說的新型依存關系，就是APaaS平臺需要業務專家來構筑行之有效和專業的解決方案，而業務專家也需要這樣的平臺來變現自己的產業知識。這樣的依存關系不需要很強大的網絡效應，哪怕只有第一組這樣的關系存在，就能夠開始產生價值。

重新開始的關鍵

重做新一代APaaS產品的前景看起來非常美妙，這也難怪企業服務投資領域最近都特別關注相關品類。但是它要進入有效商業化產出階段還有很大的阻力。從我們自己的經驗實踐看，最大的阻力來自于依然來自于信任，尤其是在大中型規模的企業中得到驗證。

APaaS模式說得天好地好，到底能不能解決我的問題?到底能不能做出復雜的應用方案?和定制開發相比，到底能夠節省多少的成本，實現怎樣的業務彈性?對于業務專家來說，他們是否信任這樣的平臺能夠實現腦中的構想，能否可靠地對終端客戶提供服務，價格是否合理?

這些問題都是我們當下最重要的問題，但意識到瓶頸關鍵就好辦。明道云的確已經在非常多的業務場景下得到了驗證，現在我們特別希望獲得更多有清晰愿景、希望在數字化建設中走在前面的大中型企業開始嘗試新一代APaaS產品，構筑比競爭者領先一步的企業信息化。

【本文是51CTO專欄作者“明道云”的原創稿件，轉載請通過51CTO聯系原作者獲取授權】

戳這里，看該作者更多好文