南宫NG28建设

To B企業應用服務領域構造平台商業模式會遇到種種困難和挑戰。第一时间遇到的就是流量問題，也就是規模市場問題。如果沒有足夠大的平台可達用戶市場規模，就不可能容納足夠數量的平台服務/產品供應商，所謂的平台商業模式就運轉不起來。其次，也是同等重要的問題是路徑依賴，企業應用領域（2B）由於專業化和行業分工的原因，能夠通達和連接數量可觀的企業用戶，並且形成一定的規模可不是一件容易的事情。這樣的企業一定是專業技術和市場能力深厚的大公司，一般都有較長的开展歷史。這是其寶貴的財富和資源，但同時也是商業和技術路徑選擇上的局限，即路徑依賴。因為這些能夠通達和連接的客戶，並非公共流量，可以顺利获得網絡平台或營銷手段輕易取得。這些資源主要是這個企業長期經營，而建立起來的Install-base——老客戶和商業關聯企業。其中大很大部分構成了這些企業的「現金牛」業務。讓他們把自己的Install-base開放給平台上的所有產品/服務供應商，這是何等糾結和肉疼的一件事情啊！

2B企業應用產品服務獨有的時空區隔市場格局

在之前的《軟件產品公司如何構建企業管理應用平台（系列之六）》中提到，（構建平台商業模式）軟件行業曾經開風氣之先，先有WinTel聯盟的操作系統+X86硬件平台，後有Android+智能手機、Apple移動操作系統+APP商店平台，這些平台先後支撐並壟斷了幾乎整個行業。但後來將平台模式從行業規模上發揚光大的卻是亞馬遜、阿里巴巴、Airbnb、滴滴、京東們，這裏面其實並沒有經典的軟件行業，特別是2B軟件（企業應用）行業。

2B企業應用市場之所以未能出現真正意義上的規模化的平台商業模式，除了前面所說的流量和路徑依賴之外，還有一個源於客戶-市場的重要原因：2B企業應用，無論是產品還是服務，嚴重依賴於客戶（企業）的應用場景，不易於規模化集中交易或交互，造成2B企業應用產品服務獨有的時空區隔市場格局。空間上，企業客戶不容易將應用場景挪到集市（平台亦然）上。時間上，企業客戶的交易-交互行為也多局限於「辦公或工作時間」。當然，移動互聯、IT產品和服務交付的XaaS化、企業運營管理的數碼化轉型，三種要素共同作用將會打破這種時空區隔市場格局。

誰可能轉型構建企業應用（2B）開放平台

獨有的路徑依賴使得企業應用（2B）開放商業平台，幾乎不可能由新創企業來創立。即便擁有黑科技創新的新興企業，「萬丈高樓平地起」在這個時空區隔市場也行不通。有可能創建或者轉型構建企業應用（2B）開放平台的企業可能來自於如下幾類：

1）基座廠商：SAP、甲骨文、微軟等企業信息化應用基座領導廠商，具備龐大規模的大型企業信息化客戶擁躉（Install-base）；

2）底盤廠商：用友、金蝶等以ERP為企業信息化「底盤」並有豐富的企業應用產品服務線的管理軟件廠商；中大型企業信息化領域的領導廠商，豐富的企業信息化產品和服務線，各產品線之間無縫連接、互補復用，佔據企業管理軟件市場主要份額；

3）連接廠商：借移動互聯、社交平台和IM等UC&C（統一通訊和協作）成功滲透到廣大企業用戶桌面和移動端的SaaS平台，騰訊企業微信、阿里釘釘等；

4）協同架構廠商：協同管理平台正在演進為企業工作和工作管理平台（即協同管理平台，OA只是企業協同的典型應用之一），這就為企業信息化向數碼化轉型给予了核心運營引擎和管理體系架構。因為協同平台正在成為具備豐富的語義引擎的體系架構，因而可以开展為企業應用的開放平台。

這些可能轉型構建企業應用（2B）開放平台的廠商，都有一個特點或者叫做前提條件：擁有可觀規模的可達用戶基數（Install-base），數萬、數十萬乃至數百萬的企業客戶連接，預先構成了商業平台的消費側規模「流量」。這就等於已經準備好了平台商業模式的半壁河山。但是，這與社交平台如微信、QQ、釘釘的數千萬、數億用戶規模相比，還是遠遠不及的。

作為可選的企業應用（2B）開放平台轉型構建廠商，還有一個不利的約束條件：B消費端流量的弱開放性和連接門檻。雖說預先構成了商業平台的消費側規模「流量」，但這個規模還是有限的，而且屬於Install-base擁躉，不是開放接入的。即這個平台對於B端市場並非完全開放，如果想將2B企業應用的所有潛在用戶-市場「引流」進入平台，還有一個不容忽略的連接門檻需要跨越。換句話說，這些平台就算是建立了起來，其對平台周邊市場的侵入滲透性可能不是覆蓋很廣，遠遠達不到「平台周邊寸草不生」的程度。

騰訊作為一個例外，它有連接數億用戶的微信平台，而且微信用戶也已遍佈B端企業客戶之中。特別是幾乎所有企業都運行着多個微信群，進行着工作性質的溝通與協作（UC&C）。但是就其連接的性質來考察，依然是平台——消費者個體（P-C-C{E in B}）模式。雖說微信和企業微信已經可以打通，但規模還很有限，B-B交互機制還在構建之中。如何將P-C{E in B}有效轉換為B-B連接仍然是難以逾越的壁壘。

做平台很難：商業模式轉換的風險與糾結

第一时间來看基座廠商，對於SAP、微軟、甲骨文、IBM這樣的在2B企業服務領域佔有大基數穩定市場份額，且擁有最優質頭部客戶群的基座廠商而言，在它們各自優勢領域長期的耕耘和積累，已經形成局域壟斷性技術和市場優勢，並开展成為類平台商業生態。平台化擴展肯定也是這些基座廠商的市場开展方向，但是它們企業應用（2B）軟件平台化努力的技術導向值得探討的。

企業管理軟件大鱷SAP被認為是最有希望建立起來企業軟件（2B）平台的候選者之一。SAP因為自己不僅擁有強大的企業應用開發技術支撐平台，還有最為全面和專業的企業應用產品。可以推斷由於無法對企業應用的平台收費（指單價金額小且單數規模量大的收費模式），像微軟對操作系統、甲骨文對數據庫、蘋果對手機+APP store 的APP分利潤一樣。SAP也不願和不能放棄自身應用（系統/模塊）的收費。SAP真的沒有充分的商業理由建立參與者不向平台價值溢出的商業模式。如果不能讓平台參與乙方（指在平台上供應企業應用產品和服務的供應商）平等地競爭取得參與甲方（指企業用戶）的交易機會，他們就不可能持续地成為平台參與方。平台的規模效應就不能湧現，最終平台的商業模式就不能確立。

SAP們在企業應用（2B）領域的平台化努力並不少，但是都以技術導向為主。也就是說這些廠商不断試圖建立一個通用的企業應用（2B）技術支撐平台如IaaS、PaaS、SaaS等。至於在這個平台上的真實的企業業務應用，到底由誰來做，如何做，怎麼收費，卻沒有多少成熟有價值的探索和方案。（《軟件產品公司如何馭風平台（之六——構建企業管理軟件平台）》）它們的平台化努力其實可以歸結為IaaS、PaaS、SaaS建設和擴展，而這些给予給企業用戶時可不是過路過橋費那麼簡單，用戶是要為此付出大價錢的。用融雲CTO毛煒的一句話說，「感覺此平台非彼平台。」

再看企業信息化的「底盤」廠商和協同架構廠商，以用友、金蝶為例，可以說幾年前平台化轉型就已經「在路上」了。不過金蝶和用友雖然都在宣稱向平台轉型，並且都有相應的技術架構方面的動作，但是我們還是認為兩者選擇了不同的戰略路徑。企業信息化資深人士陳政在一個TOB群中看到金蝶公開的PPT內容後得出這樣的結論：金蝶和用友的开展戰略分道揚鑣了。之所以能得出這樣評判，我覺得是金蝶的平台化轉型幅度比較大，舍的東西比較多，開放程度也大。最具代表性的事件便是金蝶將CRM應用徹底開放給平台夥伴紛享銷客的例子。金蝶在投資紛享銷客之後，10天內所有的CRM產品線下線，停止所有CRM研發，並交給紛享銷客去做，當然還是要求紛享銷客的研發產品線必須在金蝶的平台上做。看樣子，金蝶是真的下決心要做平台了，它要真的開放平台、開放資源。技術上強大、完備、開放的API和市場資源全面開放給所有的平台合作夥伴。

其實對於2B領域的平台模式候選廠商選擇平台化商業模式都有很大的風險。這其中包括難以割捨的現金牛業務，能開放出去的幾乎都是自己的Install-base，是自己的用戶，到现在為止還不断是金蝶的現金牛業務，自己能放棄麼？還是換一種方式，如金蝶的向雲方式遷移？已經佔據的市場優勢就忍心放棄，而換一條跑道與夥伴一起重新起跑？

專業優勢和技術資源不忍浪費。無論如何也不可能做這樣的事情：曾經的專業經驗、技術資源完全開放給夥伴，自己放着掙錢的生意不做。而且這平台溢價如何兌現還沒有想明白呢，充滿着不確定性。

議論：金蝶平台化轉型戰略詢疑

雖然我認為金蝶對平台化的戰略設計，特別是商業模式構想，還存在結構性矛盾，比如核心原則為產品互補，這就為平台开展埋下了巨大的風險。但是當金蝶國際董事長徐少春鄭重宣佈：到2025年，堅決開放市場與夥伴共同成長。我先信了金蝶的決心。但金蝶的平台化轉型的確有借鑑意義，更有討論的餘地。

從平台參與甲方（即企業應用的消費者，企業客戶們）來說，金蝶有足夠的Installed Base +渠道觸達能力，特別是市場端企業數碼化應用的需求強勁，這一點問題不太大，更何況金蝶從財務到ERP經驗豐富，渠道廣布。但是從平台參與乙方（即企業應用的開發商ISV，金蝶平台的合作夥伴們）來說可能問題有些糾結。金蝶雲生態合作的合作模式強調的，第一时间是產品互補，那麼作為一個平台，如何處理競品？是不是就不得不排他了。金蝶作為一個企業管理軟件的綜合性大企業，各類企業應用相對比較齊備，這就意味着註定要將一大批企業服務/軟件廠商排除到平台之外。這一點倒是有一個反向的例子來做正向的例證。金蝶投資了SAAS型CRM廠商紛享銷客，並把自己的CRM產品線停掉。當然，這個例子既證明了金蝶的確要在其平台上「產品互補」也證明了其平台化轉型的堅定決心。但紛享銷客的CRM在金蝶平台上只能是一個特例，對於各類企業應用的ISV們，金蝶不可能這樣，金蝶平台合作夥伴的前提是產品互補，這就意味着只要是金蝶有的產品或服務，平台上是容不下其他夥伴的。這個平台的開放式有限的。這就留下一個核心疑問題：只要平台主保留做應用的選項，應用開發商就不得不保留自主的流量入口或轉向其他平台的選項，自建渠道和使用開源技術當然是最便捷的選項之一。   

還有一個問題和阿里釘釘遇到的是一樣的，那就是平台方是否會涉足應用？在阿里釘釘，是說不保證，而企業微信卻是保證不涉足。參見平台廠商會不會做應用的爭論（ISV聯合釘釘，借船出海還是與虎謀皮？）。而在金蝶，我們看到的是金蝶應用產品線豐富的既成事實，問題是放給夥伴的應用，你會不會什麼時候一高興，就插足一下做起來？你會保證嗎？關鍵是夥伴們敢相信嗎？

退一萬步講，如果你真不做，金蝶的優勢和資源豈不是浪費掉了？幾十年的研發積累，企業數碼化應用開發積累了豐富的經驗和深厚的資源沉澱。

企業數碼化應用還有一個特點：就是項目集成，企業用戶往往要求將多個信息化應用以系統集成的方式發包，最終由一家系統集成商一攬子處理。這種情況下，其中各個應用不一定能滿足用戶的需求，就需要有相應的配置、定製、開發，總包商出於技術、成本、交付、實施或是商務上的考慮，難免會出現不符合一眾應用给予商意願的想法來。

這就為金蝶的平台戰略留下了可圈點的話題，金蝶的轉型平台戰略設計是不是有問題，真的能开展成為一個具有商業模式的平台嗎？

正如我在平台戰略系列文章之六所提出的，企業應用服務領域長期以來也未能建立起具有普遍商業意義的平台模式。連微軟、SAP、IBM、甲骨文這樣偉大的軟件公司也沒有做成這件事。原因就如前面所講的那樣，導致平台參與乙方（即合作夥伴ISV）的規模建立不起來。再說一遍，平台的規模效應就不能湧現，最終平台的商業模式就不能確立。

SAP們不能，金蝶、用友們就能成功嗎？其實，換一種思路來看，SAP、金蝶、用友們現行的商業模式難道不是一種現實可行的策略選擇嗎？