文 | 王健
本篇就嘗試將這段時間的思考落筆成文，從中臺實施過程中經常遇到的各種實際問題出發，將視角提升到組織層面，看看為什麼說以“Platform as a Product”的思路來開展中臺建設是有價值的。
1。中臺建設過程中的問題
之前的文章我一直圍繞在“為什麼建中臺”、以及“中臺到底是什麼” 這些偏抽象的問題上。
但是接觸的中臺場景越多，就越發現其實每家企業建設中臺的目的可能都是不一樣的，大面上就能分成：內部研發效能提升、資源整合、新零售、全週期、全渠道、開放銀行、多品牌戰略、全球化戰略、產業互聯、構建商業生態等等等等。
中臺這個概念，隨著市場的炒作，越來越像一個個“許願池”，承載了每家企業對於自己未來發展的美好願景。但理想總是很豐滿，而現實總是很骨感。
當我們真正下定決心，捋起袖子加油幹，嘗試真正去推動中臺落地的時候，才發現原來通往美好遠方的是條佈滿荊棘之路：
中臺的建設經費從哪裡來？中臺團隊的人從哪裡來？誰應該為中颱的建設買單？
中臺的建設效果如何來體現？誰來驗收誰來評價？
我們說中臺是企業級，要支撐多個前臺團隊，那四面八方的需求湧進來，會不會出現擁堵和排期？如何處理排序需求？
如果不同的前臺團隊的需求出現矛盾和衝突，中臺如何處理？都是金主，以誰為主？
前臺與中臺的職責怎麼劃分？
前臺不配合中臺團隊怎麼辦？
前臺提的需求不合理怎麼辦？
……
問題還有很多，但仔細觀察就不難發現，這些常見的問題大多與技術無關，而多是出現在組織的邊界上。中臺的建設既然是“企業級”，必然會涉及到組織的調整，甚至是組織的重新劃分以及利益的重新分配，而這些都早已超出了技術能解決的範疇。
說實話，近兩三年我也算參與了不少大大小小的中臺建設。大多時候，作為一名外部顧問和諮詢師，一直是想方設法繞過組織這座大山，迴歸到我熟悉的技術領域，嘗試用技術的方式去解決碰到的所有問題，但神奇的是組織的大山總會在中臺建設的某個關鍵階段，像海市蜃樓一樣突然出現在面前，阻擋在前進的路上，繞也繞不開。
甚至，我都有種越來越強烈的感覺：組織可能不是中臺建設的阻礙，而恰恰是中臺建設的本質。
既然繞不過去，那就跨過它！
2。為什麼中臺建設需要關注組織架構
回答這個問題可以從兩個方向推演：一個是
自上而下
，一個是
自下而上
。
（1）自上而下：組織重構是戰略落地的必經之路
我之前就提到過，中臺就是「企業級能力複用平臺」，“企業級”就意味著中臺規劃是屬於公司戰略的一部分，是需要自上而下做頂層設計的。
而戰略的落地，往往就是靠組織的調整來實現的。
美國的管理大師錢德勒就表達過組織結構從屬於戰略的觀點，即“企業的發展取決於兩個變數，一個變數是企業正確的戰略，另一個變數，就是企業的組織結構。這兩個變數之間，前者決定後者，後者保證前者的落地實現。”
馬雲也曾在湖畔大學的分享《使命、願景、價值觀、組織、人才、KPI》中提到過：“戰略最後的本事不是你設計了多好一個Plan，而是你落實到了什麼樣的組織，誰來幹，考核指標是什麼？”
可見中臺戰略之所以是企業級的數字化戰略轉型的一部分，從戰略落地的角度來看，組織調整是其中重要的一環，也是戰略真正落地的重要體現。
（2）自下而上：組織是中臺建設荊棘道路上的一道坎
我的同事王威提出了中臺建設的三條原則：
但是，如果實際去觀察，目前很多企業的中臺建設，仍然主要是以技術驅動為主，以IT治理為目標，天天談論的還大多是微服務怎麼拆、技術架構如何選型此類的問題。
不是說這些問題不重要，而是技術驅動的一個主要問題在於：很難講清楚中臺建設對於業務的價值。而講不清楚中臺建設對於業務的價值，就得不到相應的資源，這裡的資源主要就是錢和人。
沒有資源的支援，技術團隊就只能自己委屈點兒，吃苦耐勞，加班加點，用有限的資源既要滿足業務上的需求，又要藉著這個機會做中臺的改造，甚至是悶著頭偷著做的，臥薪嚐膽。
但結果卻往往並不好，好不容易硬著頭皮加班加點趕完了一個版本，上線了，需要前臺應用接入了，這時問題才暴露出來，例如經常出現這樣的聲音：
我們（其他團隊）為什麼要用你的中臺，我們也建了一個，要不你用我的吧……
我們（其他團隊）為什麼要把資料給你？我這兒也有一個數據中臺，你能不能把你的資料先給我一份兒……
此時大家抬起頭來才發現，原來隔壁部門、兄弟團隊也在搞中臺，原來大家嗤之以鼻的“系統孤島、資料孤島”，現在則變成了“中臺孤島”……
中臺建設從技術視角看來，看似清晰，無非是搭建一個平臺，將可複用的能力沉到平臺裡來，對前臺進行復用，感覺上就可以實現“大中臺小前臺”。
但現實遠比這要困難得多，根據康威正反定律我們可知，企業的IT架構與組織架構緊密聯絡，而組織架構說白了就是對於責任和利益的分配方式。
而我反覆強調的中臺建設既然是“企業級”，就必然會影響到企業內責任和利益的重新分配，最終也是體現在組織架構上。
這就能解釋開頭說的，為什麼中臺建設必然會在某個階段遇到組織這個無法逾越的坎，所以如果不在一開始考慮清楚，必然會讓自己在中臺建設的某個階段處於一個進退兩難的境地，非常被動。
3。從兩種典型的組織架構中臺演進看中臺困境
組織是個很大的問題，典型的組織架構就包括：直線職能型（U）、事業部型（M）、矩陣型、網路型、平臺型，還不算各種組合和變體；如果結合經營模式，還需要了解大家常常提到的阿米巴經營模式以及海爾的自主經營體……
所以，肯定不是一篇文章就可以講清楚的。
本文定位白話，我就還試著收斂回到中臺的上下文上，聚焦到數字化團隊組織的形態上，以中臺化場景中最典型的兩種數字化團隊組織結構的中臺建設演進推導為案例，試圖從組織演進的視角來看看到底為什麼中臺的建設會碰到這麼多問題？以及尋求破解之法。
（1）直線職能型組織結構的中臺推演
直線職能型組織有時候又被簡稱為職能型組織，是從直線型組織發展而來，也是大中型企業最常見的組織形式，大多數企業都採用這種組織結構形式。
在這種企業組織架構下，數字化團隊最常見的形式就是業務團隊（BT）與技術團隊（IT）分離體系。
在這種組織架構下業務團隊因為更多的承載了使用者與業務的需求，往往更具話語權和主動權，也掌握著預算分配的主動權，技術團隊更多情況下是從業務團隊申請預算，負責IT系統設施的建設與運維，完成業務團隊的需求。
不過，隨著企業業務的發展，IT系統也越來越多，自然就會出現越來越多“煙囪型”的系統，再加上整體架構的老化與腐化，技術團隊的工作負擔越來越重，對於業務團隊的需求響應能力也逐漸降低，開始出現需求堵塞，需求排期問題日漸嚴重，業務團隊不滿情緒積累，技術團隊則同樣不堪重負，矛盾日益顯現。
怎麼辦？
肯定會有人說，中臺啊！中臺不是就是解決煙囪問題的麼，你想想，只要能將各個系統重複的能力抽取出來，沉澱成共享服務，大家一共享，一變都變。對於新需求前臺直接拼拼湊湊，拖拖拽拽就能快速滿足，簡直不能更完美。
嗯，聽起來也是這麼個道理，說幹就幹，於是技術團隊就開啟了寄託著美好願景的“中臺改造”，因為是技術團隊基於IT治理的需求驅動的，也就代表“中臺改造”對於業務往往是透明的。
不過隨後就發現，中臺建著建著，之前提到的那些問題就開始一個接一個出現。
根本原因在於中臺改造往往涉及到大量的工作量，難度也非常高，而由於其“業務透明性”，表面上並沒有直接的業務價值。看不到業務價值就代表沒有業務團隊願意為這些工作買單，甚至相反因為技術資源會被中臺改造佔用，對於業務的響應不升反降，業務團隊怨聲載道。
技術團隊內也逐漸出現問題，隨著架構複雜度急速上升，再加上中臺改造出現了團隊之間的服務交叉耦合，跨團隊的溝通成本也急速增加。
看起來一切都在向著期望相反的方向加速進行，直到失控的邊緣。
中臺建設不是號稱可以增加IT的響應力麼，為什麼會適得其反？是不是分離出一個獨立的中臺團隊就會好些了呢？
中臺技術團隊應運而生，但不久我們就會發現，問題並沒有被解決。
仍然是因為“業務透明性”，在沒有新的資源支撐前提下，團隊也自然無法擴張。只能將原來的團隊進行重新切割，分為中颱技術團隊和前臺技術團隊（事實上，已經很少有企業有魄力能走到這一步）。
業務團隊的壓力和需求此時就會透過前臺技術團隊傳導到中臺技術團隊。而中臺團隊則因為要同時支撐多條業務線多個APP，複雜度高，之前提到的需求擁堵、排期、衝突的問題仍然無法得到很好的解決，只是轉移到了中臺技術團隊而已。
那是不是因為直線職能型組織天生就不適合做中臺改造呢？
其實恰恰相反，從某種角度看，中臺本質上就是一種Shared Service。Shared Service不是一個新概念，原本就是代表一種共享組織結構，由來已久，例如我們常常聽到的共享財務中心。而直線職能型組織結構下的技術團隊，本身就是一個IT Shared Service（IT共享中心），不但不是八字不合，反而非常的契合，那問題到底出在哪呢？
中臺概念來自網際網路，那我們就再來看看另一種在網際網路企業更常見的組織結構，事業部（產品型）組織結構，是不是就可以在中臺建設的過程中避免出現類似的問題？
（2）事業部（產品型）組織結構的中臺推演
事業部組織結構是分級管理、分級核算、自負盈虧的一種形式，即一個公司按地區或按產品類別分成若干個事業部，從產品的設計，成本核算 ，產品製造，一直到產品銷售，均由事業部負責，實行單獨核算，獨立經營， 集團總部只保留人事決策，預算控制和監督大權，並透過利潤等指標對事業部進行控制。
由於網際網路企業的產品基因，往往是由一款產品做起，隨著業務的擴張，逐漸出現了多條並行的產品線。網際網路因為競爭激烈，往往講究的就是一個快字，誰先佔領了市場和使用者誰就佔據了主動權。因為事業部組織架構相對於直線職能型組織架構，更強調“縱向”的執行力和靈活性，自然成為大多數網際網路企業預設的組織演進方向。
同樣，如果只聚焦於數字化團隊的組織架構，事業部職能結構可以簡單理解成產品型團隊。從單一產品開始，多一個產品，多一個團隊，團隊之間就像產品之間一樣，有很強的獨立性，例如大家熟知的阿里巴巴淘寶團隊和天貓團隊，這樣的例子有很多。
產品型團隊的問題就在於產品之間的割裂和缺少橫向協同。
相信不用多說，如上圖所示，“煙囪產品”的問題已經非常明顯：隨著各產品線的獨立快速發展，各個產品間的重複建設、技術棧混亂、設計混亂等問題日益突出。
怎麼辦？
能不能成立一個單獨的組織來處理協同的問題，讓產品型團隊專注於自己各自前臺產品的差異部分，透過組織的分層來解決產品型組織的問題呢？
中臺團隊又一次應運而生。
但區別於前臺產品團隊，此時的中臺團隊與直線職能型團隊中的中臺團隊一樣，仍是以一個偏職能型的內部共享技術團隊存在的。（我在圖例中用紅框來代表產品型團隊，用籃筐來代表職能型團隊）
乍一看，這種“分層組織結構”解決了產品團隊組織結構下的協同問題。
前臺產品團隊繼續負責產品差異部分的獨立開發，承載著企業的縱向“靈活性”；中臺職能團隊負責產品間的協同和通用部分的開發，承載著企業的橫向“經濟性”。理想情況下，透過分層組織結構，就可以透過不斷調整前臺產品團隊與中臺職能團隊的組織邊界，來調節企業在“經濟性”與“靈活性”之間的動態平衡，一切看似完美……
但是，同樣隨著中臺建設的推進，我們就會發現，之前出現在直線職能型組織中的中臺團隊所面臨的問題（需求堵塞、排期、衝突、資源競爭、邊界定義、團隊衝突……），同樣也會出現在這種事業部（產品型）組織架構的中臺團隊裡，問題並沒有得到解決……
究其原因其實也是一樣的，中臺團隊因為不是直接服務於終端終端使用者，而是透過服務前臺產品團隊間接服務終端使用者。所以並沒有直接的收入來源，需要從各個產品線抽取一定的資源（人+錢），組建中臺團隊，為前臺團隊服務，前臺團隊與中臺團隊的關係與直線職能型組織一樣，仍是一種被服務與服務的關係，區別無非在於前臺是產品型還是職能型團隊而已，並無本質區別。
4。覆盤：問題的本質到底是什麼？
基於上述，無論是以傳統行業為代表的直線職能型組織，還是以網際網路為代表的事業部（產品型）組織，亦或是各種組合變種（例如最常見的矩陣組織結構），我們發現在中臺建設的演進過程中都會或多或少陷入到同樣的問題。
所以，問題不在於企業原本是哪類的組織結構，問題在於中臺團隊本身的定位。
在兩種組織結構的推演中，因為Shared Servie（共享服務中心）的組織概念歷史悠久，深入人心。所以我們大多預設會將中臺團隊一開始就定位成一個內部的共享職能團隊。
中臺團隊被定位成一個共享職能團隊，中臺團隊與前臺團隊之間的關係是服務和被服務的關係，這才是問題的關鍵。
因為中颱是一個共享服務團隊，與前臺是服務與被服務的關係。那自然前臺出錢，中臺團隊為其提供服務就是天經地義的事情，正所謂“拿人錢財替人消災”。
這時候就會出現兩種情況：
一種情況是，因為中颱建設的複雜性和長期性，導致短期無法滿足前臺團隊的短期業務需求，業務方不滿，覺得花了錢沒有得到相應的服務；中臺團隊責因為揹負著業務的持續施壓，無法按照自己的節奏推進中臺建設，痛苦不堪，矛盾產生。我管這種矛盾叫做：短期戰術目標與長期戰略目標的矛盾。
一種情況是，中臺團隊迫於壓力極力滿足前臺的需求。但因為中颱的企業級性質，中臺團隊需要同時面對多個不同的前臺業務、前臺團隊。因為每一個前臺團隊都是“金主、客戶、甲方”，在中臺團隊眼中地位是一樣的，都是需要極力滿足需求的。而因為前臺團隊“花了錢”，為了能獲取更多的中臺資源使用權，自然都會給中臺團隊提出各種各樣的需求，來爭取到更多的中臺資源，導致中臺團隊的需求短時間劇增，但因為畢竟中臺的資源有限，所以自然而然會出現之前反覆提到的需求劇增、排期、衝突等問題，矛盾產生。我管這種矛盾叫做：多前臺由於中臺資源競爭所產生的矛盾。
5。破局：產品化中臺建設
問：那，如何破？
答：給中臺一個邊界，產品的邊界，將中臺團隊從共享職能團隊轉變為中颱產品團隊，將前臺與中臺的關係由被服務與服務的關係變為產品與產品的關係 ，既：
Platform as a Product！
呼……終於回到了主題，希望你還在：）
我發現一旦我開始嘗試用產品化的視角和思路去思考中臺時，腦子就像開了閘一樣，持續不斷地蹦出各種各樣的問題，而思考和回答這些問題的過程，恰恰就是回答之前各種困擾和問題的過程。
不信？你也可以試試，像我一樣，對照著自己的中臺，問自己下面這些問題，看看是不是也有所啟發？
而我自己，就在思考後認為，如果中臺是一個產品，則意味著：
中臺作為產品需要有自己的願景定位，不一定需要滿足所有前臺客戶的需求，這同樣也意味著前臺可以選擇不使用中臺的某些能力而選擇自建。
中臺作為產品需要有自己清晰的使用者定位和使用者劃分，前臺作為中颱的使用者不再是平等的，VIP前臺使用者的需求要優於免費前臺使用者的訴求，透過產品上常見的使用者劃分來解決需求膨脹、排期、優先順序和衝突問題。
中臺作為一個產品，需要想方設法體現自身的價值，真正為前臺客戶解決實際問題，並關注前臺使用者體驗，透過營銷和售前等手段獲取前臺客戶，透過清晰的使用者定位和產品力吸引前臺客戶，讓其主動選擇採購中臺產品。
產品的建設初期，不一定啟動資金直接從業務上切分，可能需要類似於天使投資的企業戰略投資進行初始孵化，減少中臺前期建設的業務交付壓力，甚至作為企業的戰略級產品，需要一些內部保護和孵化，但仍需要快速驗證其價值，獲取客戶，實現自負盈虧。
產品的建設過程可以借鑑精益創業思路，需要儘快體現其商業價值，如果一定時期內無法獲取相應的前臺使用者（前臺不用），或是其他考核指標不達標，則需要進行中臺建設止損，類似於創業失敗。
甚至在特殊情況下，允許同一型別的中臺產品存在合理的內部競爭，同時對兩個相似的中臺產品進行孵化，使用類似於內部賽馬的機制解決內部服務差異性帶來的內部產品壟斷和定價困難問題。
中臺產品為了使用者留存，需要對於前臺客戶提供產品級SLA，提供客戶運營，客戶售後服務，保持產品平滑更新，關注使用者滿意度，實現客戶留存與轉化。
……
有意思的是，在思考這些問題的同時，回頭再去看看這幾年一直關注的阿里中臺，才意識到答案其實一直就在那裡。阿里巴巴早已將自身的中臺能力，透過產品化包裝整合到了阿里雲上，對外輸出，無論是承載了技術中臺能力的Aliware，還是承載著資料中臺能力的Dataphin，還是承載著研發效能能力的雲效。
再去看各大網際網路巨頭，亦是如此，早已將眼光放到了更寬闊的企業外部，放到了整個社會，放到了各個行業，透過中臺能力的產品化包裝和輸出，開始打造各自的生態系統了。
6。總結
基於企業的使命與願景，結合當前的商業形勢，制定匹配的公司戰略，並基於戰略迅速調整組織進行戰略落地。 再根據康威定律，透過組織的變化引導IT架構的演進，所以中臺的誕生只是企業戰略層面上，在企業發展某個階段強調加強組織橫向協同性的一箇中間產物而已。
天下大事分久必合合久必分。戰略在不斷調整，組織就會不斷調整，IT架構就會不斷調整。凡事沒有完美，沒有完美的戰略，沒有完美的組織，也自然沒有完美的IT架構，都是在持續地演進中。所以要將關注點從試圖找到完美的解決方案轉換到提升調整能力上來，這點無論是對於戰略、組織還是IT架構都是適用的。
聚焦到中臺建設的過程中，引入產品化的思路則可以讓我們換個視角更好的思考中臺的邊界和責任，思考其核心的建設價值，更好的解決中臺建設過程中出現的各種矛盾與問題。
同時可以將中臺切成更小的產品單元，引入類似於組織中臺這樣的內部孵化投資管理組織，對於中臺產品群進行產品化市場運作。這樣的好處還在於可以透過投資方向的調整來引導內部IT架構的演進，加速企業的戰略調整落地。
使用產品化的思路來建設中臺，還有一個巨大的好處：因為中颱作為一個產品，除了產品形式（可能就是API）和使用者（內部前臺團隊）外，其他方面和其他產品沒有什麼不同。這就意味著在產品構建上我們過去已經積累了的大量成熟的方法和工具，都可以平移應用到中臺的建設上來！
哦，對了，差點忘了，我還是覺得「企業級能力複用平臺」這個定義還是Work的……只不過，再加上產品化的建設思路和方法就更完整了：）
歐電雲官網：http://www.odianyun.com/
