圖片來源@視覺中國

文 | 穆勝

與數字化轉型一起火起來的，是“中台建設”。如今，在大多數實踐者眼中，中台就是數字化轉型标配，以至于，一個幫助企業建設中台的創業賽道異軍突起。同樣，喊出中台建設口号的企業不少，但真正建起來中台的，更是屈指可數。

但随着中台建設的火爆，有關“中台建設究竟成不成立”的争論也如影随形。就連被認為是中台建設典範的阿裡，有段時間也傳出了正在“拆中台”的消息。有人更是戲稱：“大公司上中台，錢沒了；小公司上中台，公司沒了。”

本項研究将探讨數字化轉型中的三個關鍵問題：一是Why，即是否應該建設中台？二是What，即應該建設什麼樣的中台？三是How，即如何建設中台？

01 數字化轉型與中台建設

數字化轉型是互聯網浪潮發展到一定階段的必然。沿着互聯網商業的進程，數字化轉型呼之欲出。整體來看，數字化轉型一共分為三個大類：數字化營銷、工業數字化和數字化管理，也有若幹對應的同義詞或延伸詞（如表1）。我們對這些關鍵詞的百度指數進行了加權統計，發現了數字化轉型的三波浪潮（如圖1）。

表1：數字化轉型關鍵詞

資料來源：穆勝咨詢

圖1：數字化轉型浪潮熱度趨勢圖 資料來源：穆勝咨詢

備注：關鍵詞熱度參考百度指數加權計算，加權方式主要考慮了各個同義詞/延伸詞與中心詞的關聯度。

第一波數字化轉型浪潮是“數字化營銷”，出現在2015年。互聯網的上半場屬于需求側的消費互聯網領域，而數字化營銷顯然是焦點。

第二波數字化轉型浪潮是“工業數字化”，出現在2017年。在流量紅利消失之前，互聯網就開始切換到下半場——供給側的産業互聯網。其中，工業數字化是毫無疑問的C位。

第三波數字化轉型浪潮是“管理數字化”，目前處于正在爬坡，預計會是在2022-2023年之間達到高點。前兩個浪潮裡，“數字化營銷”和“工業數字化”兩個趨勢進一步倒逼出了企業内部的“數字化管理”。要将産業的供給用于滿足用戶需求，必須要有企業作為樞紐。如果兩頭都是數字化的，企業就不得不讓自己的管理也走向數字化。過去，這個領域一直是由ERP（Enterprise Resource Planning）來承接，但ERP作為工業經濟時代的産物，顯然無法滿足互聯網與數字化時代的需求。

管理數字化的本質，是打通企業内部的“連接”從而提升效率。這可以通過兩個方面來實現：

一是傳統的連接，即建設“業務中台”，實現資源或能力的極度共享，這是最傳統的效率來源。我曾舉過一個簡單的例子：糖醋排骨、魚香肉絲、松鼠桂魚這幾道菜，都需要糖、醋、生抽、老抽、澱粉等調料做成的糖醋汁，于是，廚師就可以提前調制好，在做某道菜時直接加進去就行。

其實，傳統企業也這麼做，例如，将營銷資源集中起來，建立一個營銷體系作為業務中台供前台團隊調用。但這種操作在節約成本的同時，也會導緻資源或能力輸送不到前線去，産出下降，速度也變慢。所以，傳統企業會權衡利弊，選擇是否建業務中台。

二是數字化的連接，即建設“數據中台”，讓資源和能力在極度共享後形成數據彙集，并基于算法進行智能決策。互聯網企業在資源和能力的共享上似乎沒有太多顧慮，因為他們有數字化的解決方案。數據作為生産資料的價值已經無需多言，簡單的數據彙集，就可以發現更多的效率提升空間。加上算法智能決策（算法也是自動進化的），這種效率優化空間實在太吸引人了。

其實，企業根本無法抵抗數字化轉型趨勢，某種程度上，其選擇中台建設是“被卷入”的。可以說，有無中台決定了企業的未來，因為，有無之間的效率根本不是一個量級。

02 業務中台建設的本質

先談談業務中台。

業務中台，被形容成為前台打仗提供“彈藥”支持。什麼是“彈藥”呢？一般的描述是，“彈藥”是交付産品、服務或解決方案的中間件，既有實物形态，也有非實物形态。但這種說法并不全面，容易導緻中台建設偏差。

業務中台實際上是後台的延伸，考慮後台主要是做“平台規則設計”和“資源池建設”兩項任務，業務中台提供的彈藥也應該是這兩個方面。

一個被絕大多數人忽略的事實是，中台提供的彈藥同時包括了“落地規則”和“輸送資源”兩個方面，根本就分不開，也沒有必要分開。

例如，一家酒店集團的供應鍊部門作為業務中台提供的彈藥，應該是供應鍊能力。供應鍊能力具體包括什麼呢？看得見的是“資源”的構成，即整合供應商提供的設計、裝修、供材、信息系統資源；看不見的則是“規則”的導向，包括供應商準入标準、甄選标準、服務标準等。“資源”隻有進入“規則”的框架，才能成為可以被前台使用的彈藥。

另一類情況裡，“資源”和“規則”就是一回事。例如，金融機構的風控部門作為業務中台提供的彈藥，應該是風控能力。他們看似常常都在說“這不行”“那不行”，但他們卻是以自己的風控知識（模型）來對具體業務進行判斷，他們的風控結論也會進入最終的産品裡。他們提供了一種非實物形态的彈藥，既是資源（知識），也是規則。

對于業務中台應該把資源池裡的資源變成中間件，已經是不用争論的共識，在考核上，自然是關注資源經營的效能（Efficiency）；但對于其如何把平台規則變成中間件，尚且存在認知盲區，也沒有明确的考核标準。

過去，很多人把規則設計相關的職能統一放到後台，認為後台設計的規則隻要足夠有彈性，自然就可以應對一線作戰的複雜需求。實際上，這是不可能完成的任務，或者說，這種判斷根本就是缺乏對于組織規律的認知。規則是死的，市場是活的，一定要有人基于基本規則去做不同應用場景的匹配。規則也應該有中間件，這也應該是業務中台的主要任務。其實，如果沒有這一塊職能，業務中台要想把後台傳遞過來的資源經營出好效能，是不可能實現的。

所以，我們既可以說業務中台應該對資源的效能負責，也可以說業務中台應該為平台的規則負責，這兩者之間并不矛盾，而是高度統一的。在過去，大多企業所謂的“業務中台部門”似乎更強調自己在落地規則，而沒有強調自己在經營資源。他們實際上是帶着後台的腦子走到了業務中台，是“僞業務中台”。

我們甚至可以大膽地推斷，大多所謂“業務中台”部門強調自己的主要職能是“落地規則“，本身也是因為這個職能難以考核。試想，如果業務中台要主張自己落地（堅守）了後台的規則，“一刀切”地當個規則的二傳手，不是很容易嗎？

我的建議是，把考核倒過來，從主要考核落地規則，到主要考核經營資源的效果。隻有如此，他們才會以經營資源為前提，考慮如何彈性地适配規則，為前台找到經營空間。

進一步看，一個能夠真正“落地好規則”和“經營好資源”的業務中台，應該擁有三項能力（如圖2）：

• 連接能力——連接内外部合作者的能力，能夠監管住合作者，讓合作者交付有質量的服務，相當于蓋木屋時取到合适木材。如供應鍊中台連接供應商的能力，再如生産部門連接設計部門的能力。

• 整合能力——基于自身對于某一領域的理解，将各種服務進行整合的能力，相當于把木材搭建成一個木屋的基本框架。如供應鍊中台設計各類流程和标準，讓供應商能夠各司其職，高效服務于生産。

• 交付能力——基于自身的基礎能力，按照前台要求進行定制化交付的能力，相當于按照（前台）客戶的要求對木屋進行一定的個性化。如供應鍊中台根據前台的特殊需求，給出彈性的服務。

圖2：業務中台的三項能力要求 資料來源：穆勝咨詢

03 數據中台建設的本質

無論以“落地規則”還是“輸送資源”的形式輸送彈藥，本質上都是業務中台沉澱知識的外化。知識，在這個時代是以數據為表現形式的，以數據來呈現知識，也是最高效的方式。數據中台是業務中台高效運轉的根本支撐。

當然，數據隻是一個大概念，現在的時代，任何人都可以毫不費勁地高呼“數據就是一切”。但數據從哪裡來？如何在“落地規則”和“輸送資源”上發揮作用？

讓我們先回到知識的概念。我認為，在數字化的時代，知識有三層：

• 指标（Indicator）——将看到的事實變成數字，進入一個絕對标準化的對話頻道。例如，将人才的某項素質變成分值。

• 模型（Model）——連接數字，說明數字之間的關系。在程序設計的語言裡，有點像函數（Function）或子程序。例如，按照素質模型的5項維度來計算人才素質的綜合得分，這就是一個簡單的模型。

• 框架（Framework）——連接模型，說明模型之間的關系。在程序設計的語言裡，有點像類庫（Class Library）。一項“落地規則”或“輸送資源”的賦能，一定是依靠綜合知識的支撐，一定需要調用某個領域的若幹模型。例如，要為前台經營單元輸送人才，需要綜合經營單元裡角色的素質、經驗、技能等級等模型，甚至要考慮人才的業績産出節奏，再計算出候選人的适配程度，選出最合适的人。

數據，實際上是經過“指标”計量之後，在“框架”和“模型”裡頻繁計算後，得出有價值的資産。數據讓規則适用更加明确，讓資源分布更加清晰，從而大大提升了企業的各種效率。

數據中台的建設，我以前曾将其稱為“全域數字化打通”。其實，數據中台應該稱之為“業務中台的數據化”。我的意思是，如果沒有業務中台的建立，強行建立數據中台是很難打通各類業務的。而業務如果不能打通，那麼數字化可能就是隔靴搔癢：一是收集到的數據就不可能有太大價值；二是數據的結果也很難産生足夠的業務影響。最終，數據中台可能有名無實。

數據中台的意義在于：一方面，它連接了需求側的各種應用場景，各種用戶需求被翻譯為數字，便于企業最大程度進行消化；另一方面，它連接了供給側的各大職能，研發、采購、生産、客戶關系等職能一體化協同，高效回應用戶需求。這種“連接力”的根本原因是，數字是最沒有争議的溝通頻道，與傳統溝通方式相比，威力不是一個量級。

數據中台必然建立在IT架構上，但在這個方向上，尚且存在分歧。

傳統的IT架構匹配的是傳統的金字塔組織，企業在信息化的過程中，按照職能劃分，建設了若幹具有重複功能且缺乏連接的系統，被戲稱為“重複造煙囪”。顯然，将能夠共享的能力建設成為統一的平台，才能适應平台型組織的趨勢。

有的企業在寄希望于“微服務”這種模塊化技術構架，這是不可取的。微服務依然是基于獨立業務形成的“煙囪式解決方案”，不同之處隻是在“煙囪”之間搭建了橋梁（通過标準協議進行訪問），形成了一種松散耦合的效果。從數據層面來看，微服務的數據隻能通過接口進行交互，無法在數據庫層實現相互訪問。

一個不容回避的事實是，構建系統如果不能從全局出發，而隻是在各項業務上尋求局部最佳解決方案，必然是低效的。一方面，局部的最優方案大多并不是整體的最佳方案，而不斷尋找最優方案的過程中增加的複雜性，将導緻更大的系統複雜性；另一方面，如果業務無法連通，數據困死在煙囪内部，必然喪失整個系統可觀的協同效應。

如果構建系統要從全局出發，組織上就不能分而治之，一定要有一個統管全局的數據中台部門。在此基礎上，為了避免數據中台陷入“事後看數據”的誤區，還應使其與業務中台緊密連接，形成一個協作閉環（如圖3）：

首先，業務中台生産數據并傳遞給數據中台；

其次，數據中台處理數據，産生結論後（如各職能的最優決策建議），分享給業務中台；

再次，業務中台使用結論後，又産生了新的、數量更大、顆粒度更細的數據，給予了數據中台更多的“原料”。

最後，數據中台通過處理更多更優質的數據，産生了更高質量的結論，讓業務中台更靠近用戶的真實需求，并能産生更多更優質的數據。

圖3：業務中台與數據中台的協作閉環

資料來源：穆勝咨詢

這個閉環是無限循環的（Infinite Loop），每循環一圈，企業就能産生更大的競争優勢——供需的連接更加緊密。而這種競争優勢的集中體現，就是“數據資産”。更可怕的是，這種優勢的增加是不可逆的。另外，這種競争優勢一旦超過一個阈值，企業的霸主地位就再也無法被撼動。其實，這才是若幹清醒的企業瘋狂追逐數字化的原因。

04 中台建設的組織原理

從組織的角度，中台被翻譯為Middle Office；從IT設施架構的角度，中台也被翻譯為Middle Platform。所以，不少人将業務中台理解為一個IT架構、工具或産品，例如，阿裡打通淘寶和天貓的五彩石項目就被普遍理解為一個IT架構上的創新。

從IT角度建設數據中台的思路，應該說已經相對成熟，這得益于這個賽道近年來的蓬勃發展。我們發現，從雲徙科技、奇點雲等企業開始，幫助企業建立數據中台已經成為了一個頗有想象空間的生意，還獲得了大量融資（圖4-圖5）。

圖4：2017-2021年數據中台服務商融資筆數 資料來源：天眼查，穆勝咨詢

備注：樣本為天眼查中含“數據中台”标簽企業

圖5：2017-2021年頭部數據中台服務商融資金額 資料來源：天眼查，穆勝咨詢

備注：頭部數據中台服務商指樣本企業中單筆融資金額超過1億RMB的服務商。

但我還是要強調，數據中台并不是一個成熟的IT産品，而應該是一個解決方案。數據中台的服務商應該擁有一個方法論，但這種方法論必須導入企業，基于企業所能夠提取的數據，對數據進行加工，并對數據流轉機制進行設計後，才能形成企業自己的數據中台。部分服務商号稱自己有數據中台的成熟産品，這相當于兜售萬能靈藥，是相當不靠譜的。正是因為不少服務商的冒進，這個賽道由最初的高歌猛進，逐漸走向了泡沫刺破後的穩定。2021年度，無論從融資筆數還是從頭部企業的融資額來看，數據中台賽道的熱度都在回調。

進一步看，即使将數據中台理解為解決方案，也并沒有觸及本質，可能會導緻企業在中台建設中迷失。無論是業務中台還是數據中台，說到底都是組織建設問題，IT系統是組織結構的一種呈現形式。

早在1967年，著名計算機科學家、程序設計師和黑客麥爾文·康威（Melvin Conway）就曾經提出過一個觀點，後來被總結為“康威定律”——設計系統的組織，其産生的設計等同于組織之内、組織之間的溝通結構。這個定律中，最基礎的一個觀點就是——組織溝通方式會通過系統設計表達出來。

下面，我将嘗試闡述穆勝咨詢幫助企業建立業務中台的思路，再基于“業務-數據”的聯動關系，引出數據中台的建設思路。

業務中台一定是要沉澱出可以“被共享的能力”，如果前台依靠自己的本地能力解決問題，那就與業務中台無關。而要實現能力的沉澱，業務中台部門應該有三層結構（如圖6）：

• 基石層——聯動後台的界面，确保了對後台資源和規則的感知。這個部分負責把後台提供的資源和規則初步轉化為知識（即“框架化”和“模型化”）。同時，他們也要負責向後台反饋，這可能引發整個職能條線（後台→中台→前台）建設思路的變化。

• 夾心層——知識的應用層，确保了知識的彈性。這個部分在基石層提供知識後，通過應用場景的采集和分類，形成方向性的解決方案（這種方式也被稱為“業務中台的碎片化”）。同時，他們也要負責基于反饋來修正方向性的解決方案。

• BP層——向前台派出的BP（Business Partner），确保了對于市場溫度的感知。這些BP進入前台團隊，與他們協同作戰，在感知市場溫度的前提下，确保解決方案能夠定制化交付。同時，他們也要負責将市場的反饋向企業内部進行傳遞。

圖6：業務中台的三層結構 資料來源：穆勝咨詢

有一個說法是，業務中台應該專注于沉澱能力進行共享，因此應該與前台部門進行邏輯分離。這種說法有一定的道理，要提供被共享的能力，一定要從前台業務中抽象出模型和框架，就不能把太多的精力放到參與具體業務中。但如此一來，卻容易造成業務中台不接地氣。而上述的三層結構完美解決了這個問題，至少，在我們的咨詢項目實踐裡，這種組織設計是比較受企業認可的。

數據中台的結構顯然應該和業務中台有很大程度上的相似性，也應該是三層結構（如圖7）：

• 基石層——基于企業全局構建IT系統（或者稱DT系統），形成數字化的底層框架。同時，他們也要負責彙總反饋數據，修正底層框架。

• 夾心層——基于底層框架，形成次級框架和主要的模型，對接每類應用場景，以産品形式支撐每個方向的解決方案。同時，他們也要負責基于反饋來清洗數據，修正模型和框架。

• BP層——向業務中台派出的BP，這些BP進入業務中台團隊，确保數據中台提供的産品實現服務化，即讓商業智能（Business Intelligence）完美落地。同時，他們也要負責基于業務邏輯抓取數據。

圖7：數據中台的三層結構 資料來源：穆勝咨詢

直觀上看，夾心層和BP層的建設應該是最難也是最亟需的。實踐中，不少企業都對我們提出了此類要求。但他們幾乎都忽略了，自己的基石層太過羸弱，根本無法支持夾心層和BP層。于是，他們推出的BP層幾乎都無法融入派去的組織模塊，他們的夾心層也會做出大量華而不實的“産品”，雙中台的建設也會因此走向失敗。

我們的項目經驗揭示了兩個中台建設規律：

其一，先有業務中台建設，再有數據中台建設。解決了業務中台，數據中台的建設事半功倍。

聚焦到業務中台建設，其本質就是一個“組織轉型項目”，具體包括了業務中台的流程、架構、考核、激勵、知識管理等一系列子模塊，這是企業走向數字化的前提。說白了，這類項目既是在幫助企業為各職能條線的運作補課，又是在幫助這些職能條線實現更大的賦能彈性。

其二，建設基石層、夾心層、BP層投入的項目時間應該是5：3：2。解決了基石層，夾心層和BP層的問題迎刃而解。

基石層建設的難度在于，大量職能條線基本都是憑“手感”在運作。他們既沒有能力說清楚規則，更沒有意願說清楚規則。就前者來說，需要有理解和重塑業務的能力；就後者來說，需要有推動組織轉型的能力，巧妙地撬動各個職能條線去改變的動機。

所以，無論從哪個角度說，企業的中台建設可能都需要外部咨詢機構的賦能。但這種賦能絕非不是兜售“萬能解藥”那麼簡單。

05 組織和數字化轉型的因果糾結

最後一個需要被解決的問題是——究竟是組織轉型推動數字化轉型，還是數字化轉型推動組織轉型？不少企業在兩者之間糾結徘徊，其實大可不必。

一方面，如果組織不變，數字化轉型必然事倍功半。

第一個理由是如果僅僅将數據中台作為一種IT工具，不可能打通部門牆。

數字化轉型讓各部門之間的數據形成連接，共享可視，而數據自動形成的決策也會相對中立，從而大大加強協同。但不要忘了，用數據的始終是人，如果沒有組織轉型，員工的責權利沒有變，每個人都可以找到理由不使用數據，尤其是在數據中台尚未成熟時，這些理由更是可以信手拈來。

第二個理由是數字化轉型着重依賴的IT部門不可能強大到撐起整個數字化轉型。

當前，大量的企業自然是以CTO或CIO帶領IT部門作為數字化轉型的龍頭。最開始，他們也是信心滿滿地投入戰鬥，但越推動就發現越尴尬。大量的業務部門連标準化都沒有實現，如何進行數據化甚至數字化？但業務部門可不管這些，他們把IT部門當成萬能的機器貓，要求他們無限“賦能”。可不是嗎？我輔導的企業的某位業務大佬的話很有代表性——“數字化轉型不就是讓業務變得更好，給我們賦能的嗎？”IT部門有苦難言，卻又無言以對，隻能被逼充當“産品經理”，但這相當于要他們在沙堆上建高樓，效果可想而知。

另一方面，如果沒有數字化，組織轉型也必然事倍功半，或者說，沒有經過數字化轉型加持的組織轉型，可能會損失可觀的轉型紅利。

當組織内的部門、團隊、個人在一體化的數據中台上實現連接，此時的協作是最穩定而高效的。所以，當組織結構的改變帶來業務模式和相應數據流轉機制的改變，就應該通過數字化轉型來固化和強化改革成果。而平台型組織的架構決定了，企業是以用戶為中心，各組織模塊并聯協作的。這類組織模式需要信息以數字的方式進行高度共享，沒有一體化的IT平台，根本無法達成這個要求，這必然需要數字化轉型。

這裡舉個實際的例子。穆勝咨詢輔導一家汽車模組制造企業轉型平台型組織，當項目能看到雛形時，我們就建議他們重新評估數字化轉型的重要性。因為，當前中後台已經明确了市場化的激勵機制，即對賭之後的超額利潤分享，如何讓這種激勵機制落地下去就是一個隻有數字化才能解決的事。

随便舉一個小問題吧。不同難度的項目，項目參與者應該有不同提成比例吧（與公司分享利潤）？而項目難度又是由什麼決定的呢？由設計難度、生産難度、供應鍊難度、客戶穩定性等十幾個因素決定。每個因素變了，項目的難度等級都可能變化。而項目難度變了，整個項目團隊的規模就應該變化，項目團隊規模變了，提成之後的利潤分邊（給每個人的）又會動态變化。市場的瞬息萬變，隻有通過數字化系統才能消化，否則，組織轉型無法深入。

最後，我們需要戳穿一個一直争論不休的僞命題——中台建設究竟成不成立？

有人以大廠為标杆，一直關注大廠在“拆中台”還是“建中台”，并以此作為中台建設是否成立的論據。這種思維是狹隘的，陷入了非此即彼的誤區，實際上還是沒有理解組織和數字化轉型之間的關系。

企業發展的階段不同，面對的市場不同，有的企業在“建中台”，有的企業在“拆（舊的）中台”，但他們一定會“建（新的）中台”。業務中台和數據中台的邏輯是恒定的，不會消失。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部