來源 / ToB行業頭條 （ID：wwwqifu）
作者 / 黃允聰
編輯 / 李曉松 瑞雪
近兩年，國內阿里、騰訊、華為、位元組跳動等大廠，都開始搞SaaS生態。相信關注ToB行業頭條的朋友，已經對國內SaaS生態的概念、現狀以及未來有了一定了解。
不過今天我們不聊概念，而是想講講搭建SaaS生態繞不過iDaaS、iPaaS、aPaaS等技術。
iDaaS比較好理解，主要解決賬號互通的問題，可iPaaS、aPaaS雖然在國內流行多年，卻鮮有人可以把它們講明白。
因此，在與編輯溝通、修改的過程中，我會盡可能地淡化術語，以便讀者可以理解SaaS生態講的iPaaS、aPaaS到底是什麼東西？
其實，不管是阿里的“雲釘一體”，還是騰訊啟動的“SaaS技術聯盟”，目的都是為了搭建一個平臺，解決SaaS廠商互聯互通和研發效率等問題。
我們可以把這個平臺當成是企業的Windows作業系統，即透過釘釘或企業微信這樣的平臺，企業就可以接入不同型別、不同功能的SaaS軟體，從而實現一家公司只用一個平臺系統，就能實現多種服務。
比如騰訊SaaS技術聯盟推出的典型案例，就是將協同辦公產品道一雲、騰訊會議、法大大、金山辦公、易企秀等產品相連線，以此實現視訊會議過程中使用WPS文件、電子簽約、協同OA等功能。
如果沒有生態，這需要多家廠商坐到一起，商量介面、資料傳輸等問題，各家的產品都要為其他產品做較大幅度的調整。可如果有騰訊這個中間商當做平臺，設立統一的標準，確實能在一定程度上實現整合化解決方案。
當然，實現上述功能不是光靠想象就可以的，這其中涉及到很多技術，而賬戶通iDaaS，整合平臺iPaaS和應用平臺aPaaS，就是進一步解決 SaaS生態互聯互通和需求多樣化問題的關鍵。
1. iDaaS使用者通
iDaaS最容易理解，也相對最容易實現，解決的就是賬號互通的問題。比如現在很多應用都可以透過微信和QQ賬戶直接登陸，而騰訊內部也在把企業微信、騰訊雲，以及生態內的SaaS廠商之間的賬戶和支付體系互相打通。
這樣透過一個賬號（比如企業微信或釘釘的），就可以使用生態內的不同SaaS產品，解決多賬號管理麻煩的問題。這也為後續不同SaaS間的資料互通、資訊互通、產品協同等場景打好了基礎。
2. aPaaS應用平臺：利弊參半，並非萬能
解決了最好理解的iDaaS問題，我們來聊聊相對難以理解的aPaaS問題。
aPaaS 全稱是application Platform as a Service，即應用程式平臺即服務。主要特徵有2個：
1）可以提供快速開發的環境，讓使用者在幾個小時內就能完成應用的開發、測試、部署，並能夠隨時調整或更新；
2）就是低程式碼或零程式碼，非技術人員就能完成應用開發。
目前，國內做aPaaS企業非常多，阿里和騰訊都有自己的廠商，市場上也有很多獨立的aPaaS廠商。
本人研究了一些主要的aPaaS廠商，透過研究它們各自網站上提供的模板案例，和與一些使用aPaaS開發朋友的交流，得出了很多有意思的結論。
aPaaS確實可以快速開發一些簡單型別的應用，而且效率上也有很大的提升。
我的一位SaaS創業校友把之前一些工資高的核心開發都砍掉了，保留了略懂程式碼的做產品的人員，這樣就可以利用aPaaS能力滿足自己的開發需求。
aPaaS可以同時開發出WEB版和手機版本，因為aPaaS提供了很多UI元件直接可以使用。所以，aPaaS會取代之前一些簡單應用的開發模式，例如：簡單的OA功能、報銷和審批等通用化強的東西，以及業務邏輯簡單明瞭的應用。
不過 aPaaS取代不了複雜應用的開發，本人也看了aPaaS平臺上面ERP的案例，這些案例和成熟的ERP相比，更像是大學生的畢業設計。
因為即使市面上成熟的ERP也無法解決很多行業特定需求的問題，例如：服裝紡織分銷和生產，餐飲行業，所以aPaaS並非是萬能的。
上述兩個行業是本人最熟悉的行業， aPaaS如果能夠解決複雜的問題，這兩個行業就不會有虧損幾個億、被迫賣身的企業了。
下面是aPaaS平臺iVX創始人的公開講話截圖，也可以在一定程度上佐證我的觀點。
aPaaS更適合簡單短小專案的開發，不適合長期的迴圈迭代產品的開發，尤其產品要面對多樣化需求，必須具備高配置屬性的時候。
因為aPaaS在開發階段就確定了很多屬性，不能在後期使用過程中進行動態調整，所以很難應對複雜的多變需求場景。
舉一個簡單易懂的小例子，比如表格展示。比較好的表格需要做到不同使用者看到不同行、不同列。老闆、財務、普通員工看到的表格肯定不能一樣，因為裡面會涉及到價格、成本這些敏感資訊。
可是aPaaS開發出的軟體和國內絕大多數B端軟體都是忽略這種客戶需求的，大多都只提供統一化的表格。
很多行業軟體蘊含著大量的行業Know-How（專業技能、專業經驗），沒有踩過坑、有過經驗，基本不可能把軟體做好，更不要談使用者體驗了。
例如：餐飲軟體分析要看翻檯率等指標，服裝要看售罄率、庫銷比，服裝行業的尺碼橫排表格要求等等，這些在通用化軟體中根本看不到。
國外是先有SaaS應用，有了積累以後才有aPaaS來做擴充套件。可國內是先有aPaaS，然後在aPaaS上面建立SaaS，方向做反了。
國外是提供了盛宴，自己新增佐料和搭配甜點。國內aPaaS是提供了原料，其他人去做盛宴，因此導致了“什麼都行，什麼都做不好”的局面。
aPaaS對非程式碼人員是友好的，但對程式設計師是多餘的，而且是降低效率的，起碼除錯軟體非常麻煩。
本人也是堅持一線作戰的老炮程式設計師了，職業生涯中也用過很多拖拉開發工具，如最早的VB和MFC，自動化生成的東西開發時非常爽，但後期維護就變成了噩夢。
優秀的產品化專案必須在滿足多樣化需求的同時保持一份程式碼，這樣才方便持續維護和迭代。
可是，國內市場為了避免不同客戶需求之間的衝突，很多使用aPaaS開放的企業會選擇一個客戶做一個應用，這樣也就變成了專案化而非產品化，短期比較爽，長期很難實現持續積累和完善。
iPaaS是最抽象最難實現的，因為支撐不同廠家之間的資料互聯互通，iPaaS目標是：建立標準，實現類似集裝箱物流的效果。
“不管神戶還是紐約，拉集裝箱的車和碼頭裝箱吊車是一樣的，貨物容易流通，大大降低成本”。這種標準的建立就是iPaaS的價值。
其實很多行業都有這樣的標準，如：機械行業的螺絲標準，電腦行業的硬體標準，軟體底層作業系統標準，通訊行業標準等等。
那為何SaaS行業很難建立統一標準呢？因為這個行業內的需求太多樣化了，無法使用標準的東西滿足客戶的需求，抽象和建立的難度太大。
打個比方，假如我們想建立一個標準化的語言方便世界人民來溝通交流，可如果我們連各國的語言和文化都沒有搞清楚，這個通用的語言要怎麼建立呢？
所以，建立iPaaS的難度就是對行業Know-How的深刻理解，同時還必須具備超強的技術能力和抽象分析能力。
可國內SaaS市場的狀況是，在網際網路背景下成長出的新一代技術人才不具備行業背景能力，而具備行業背景能力的人又老了或者不懂新技術，沒有一定時間的積累磨練沉澱，如何做出適合實際需求的iPaaS呢？
本人在2001-2005年就職於KN物流（世界頂級物流公司），當時的專案就是做一個第四方物流的Hub，要對接非常多的ERP系統和倉庫管理系統，其實這種B2B的對接實踐在美國2000年就開始了，後面才出現開源的實現MuleSoft。
我們也知道，MuleSoft可以說是出生於國外環境的iPaaS，最後被Salesforce以65億美金收購。但是這種iPaaS的使用是大公司的專利，因為需要專業人員才能搞定，還是很難解決中國的中小企業問題，中小企業沒錢找懂行業和技術的開發人員。
中國SaaS企業要達到這個水平，要走的路還很長，這不僅要解決技術的問題，更需要市場與時俱進，並不是一兩句可以說清楚的。