一場疫情，讓銀行數字化轉型再次提上日程。“無接觸銀行”不再是戰略規劃中亮眼的提法，而是如今各銀行經營中不得不面臨的切實問題。而中臺，作為數字化轉型中最火熱的概念，這兩年在行業里風頭無兩。中臺是數字化轉型的一劑良藥，還是另一個風投炒作的概念?銀行應該做中臺嗎?盲目上馬中臺項目有什么后果?本文嘗試給出一個答案。

為什么要做中臺?

數據中臺

(1)打通數據孤島

主流的觀點認為，做數據中臺是為了打通數據孤島。在互聯網企業確實可以理解， 但是銀行對于數據的應用很早就開始了。大行普遍 2008 年前后就建成了數據倉庫，數據層面早已將煙囪系統打通，那么數據中臺的意義何在?

銀行確實在數據方面很早就開始了嘗試，加上金融是個低頻場景，因此在相當長的一段時間內，T+1 甚至 T+2 的整合數據基本夠用了，更多數據整合和加工為的是滿足監管需求。

隨著移動互聯網時代的到來，用戶行為、市場、監管都發生了變化，各類服務移動化的趨勢下，用戶的使用時間碎片化，金融，特別是支付、理財等行為也變成了中高頻交易，并且隨著互聯網巨頭的進入，市場變化不可同日而語，銀行的危機感日漸增加。

業務需求響應再快，也趕不上市場、客戶、監管的變化速度，而應用開發速度就更慢了，大銀行半年左右，中小銀行三個月左右是常態。應用系統上線后，傳統的基于數倉、數據集市的數據采集和整合方式在時效性上已經很難滿足要求。可以說，銀行在打通數據孤島方面，或者更全面的說，在數據加工、分析，及發揮數據價值方面，嘗試得很早，但是效果不佳——既不快，也不好。

不快很好理解，即時效性達不到要求，利用最新的流數據處理，分布式 ETL 技術， 數據中臺可以更快的整合、加工數據。可是打通效果不好該如何理解呢?

(2)業務數據化

有句話說得好，數據是物理世界在數字世界的投影。既然是投影，那么光源和視角的不同，可能投影的結果也不同。

舉個例子，同樣一個事件，比如客戶刷卡消費，在財務視角看來，是一筆應收賬款;在業務視角來看，是一筆客戶消費，賬戶/卡活躍，積分增加;從科技角度來看，交易流水表增加一條記錄，賬戶余額表修改一條記錄。我們很難用數據去精確描述一個事件，或者說，在銀行的實際使用場景中，每個部門看待同一個事件的角度就是不同的，各部門需要從不同的角度看待同一件事，以便更好的完成自己的職能。在這里，各部門其實都是數據的使用者，即數據用戶，那么，我們可以得到一個結論：數據用戶對于數據的需求各不相同。

這也是銀行要打造數據集市的原因，數據倉庫采用相對標準化的數據模型(如FS-LDM)將數據聚合了起來，但是仍然難以滿足所有業務人員的需求。因此各部門都提出了自己的數據集市需求。

正如上節中提到的，隨著市場變化越來越快，客戶變化越來越快，業務需求已經越發追不上他們變化的速度了，而數據的采集和加工速度則更慢，難以支持數據決策。于是，各部門又經常提出各類報表和數據提取的需求，這些都是針對臨時的、緊急的、監管要求的、營銷統計的數據需求，雖然這些需求更加貼近業務需求，但是在分析和開發上通常也要花費不少時間。

現在，我們可以回答上一節末尾提出的問題：數據孤島打通的效果不夠好，指的是數據的業務友好度不夠。

總結銀行數據加工的現狀，可以得出下圖：

在我們傳統的數據應用中，隨著數據對于業務友好度的增加，其時效性也在減弱。而我們的目標，顯然是數據又快又好。既然各部門的需求都不一樣，為何不讓業務自助分析數據呢?于是我們有了右上角的目標狀態。但是這個理想狀態和我們現在的數據應用中間有巨大的空隙，靠什么來填補?答案是數據中臺。

業務中臺

(1)優化煙囪系統架構

銀行的數據之所以很早就在進行打通的嘗試，主要原因就在于產生數據的業務系統，長期存在重復建設和煙囪系統的問題。到底是什么原因，造成了這個現象。我們其實可以從軟件工程中經典的康威定律中窺見一斑：

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

——Melvin Conway(1967)

換句話說，就是組織的溝通方式，決定了其設計的系統架構。回想銀行內部的溝通方式，我們不難發現這些現象：以部門為中心，以部門 KPI 為導向，部門墻現象嚴重，跨部門溝通協作及其困難。由于 A 部門管理的 A 系統無法配合改造，為了實現相似的功能，B 部門只好新建一個 B 系統，這種情況屢見不鮮。這種種現象導致了銀行信息系統的建設和管理都是面向部門的，換句話說，形成了煙囪式架構。

因此，中臺的建設，必須包含組織架構的相應調整。否則，如果我們把中臺具象為一個具體的產品，仍然按照原來歸屬某一部門或業務條線管理的話，無非是又增加了一個大煙囪而已。

那么，煙囪式架構到底帶來什么問題呢?

對外，可能造成同一機構的不同產品、不同渠道，對客服務的體驗不一致，甚至賬號不互通，每用一個產品還需要客戶新注冊、開戶，體驗極差。

對內，成本高，可能造成重復建設，浪費本就緊張的科技資源，擠占排期時間， 激化內部矛盾;煙囪系統產生的數據，形成數據孤島，為后期統計分析帶來極大的困難，進而造成數出多門，甚至錯誤數據導致錯誤決策的嚴重后果;模塊無法復用，經驗無法共享，煙囪系統各自獨立，無法復用其他煙囪的模塊或經驗，哪怕他們高度相似。

其實，銀行也很早就開始煙囪式架構的治理，比如在渠道層，新建渠道整合平臺， 在用戶層，新建 ECIF 系統，所以說，銀行并不是中臺戰略的追隨者，而深感數據孤島、煙囪式架構之痛的銀行人，一直是中臺戰略的踐行者，只是沒有把這些嘗試體系化、結構化而已。

(2)支持前臺快速迭代

前文提到，市場、用戶和監管的變化速度，遠遠快過業務系統迭代的速度，為了抹平這個差異，我們需要讓業務系統，尤其是前端面向客戶的系統盡量的敏捷。這也是目前業界流行的“小前臺、大中臺”提法的由來。

中臺的故事，在國內起源于阿里，而其核心思想，來源于一家游戲公司(SUPER CELL)，相比游戲行業，甚至電商行業的業務領域，銀行的業務要復雜得多。因此在談到業務中臺時，我們難免會有疑慮：銀行的業務系統，真的有那么多可以復用的功能模塊嗎?

我們不必照搬互聯網企業的中臺思路，仔細梳理銀行業務流程，我們不難發現， 銀行對于同類客戶的產品，流程雖不同，功能多相似。以零售對客產品為例，站在用戶視角，功能可以抽象為：注冊、綁卡開戶、充值提現、轉賬、購買贖回等， 站在機構視角，還可細化出反欺詐、數據采集、客戶打標、交叉銷售等。由于銀行一直以來大多數依賴第三方供應商的成熟產品，為了應對不同銀行的需求，這類產品通常是“大而全”的，包含了所有必須和非必須的流程和功能。這就導致直銷銀行、手機銀行、微信銀行等等渠道，都重復實現了類似的功能。

其實微服務的思想就是將大的系統，拆分為小的應用和服務，高內聚、低耦合， 發布有價值的服務，即可被使用和共享的服務。而高內聚、低耦合也一直是銀行設計架構的基本原則。因此，我們可以看到，銀行的架構設計、微服務體系、中臺架構一脈相承，都是為了共享功能下沉復用，減少重復造輪子的現象。

這帶來的好處，就是新建應用的時候，可以通過已有成熟模塊的組裝，實現快速上線，從而加快業務系統的迭代，真正實現“小前臺”，更好更快的相應市場、客戶和監管的變化。

綜上所述，中臺建設是銀行進行數字化轉型的關鍵舉措，勢在必行。

中臺是什么?

2019 年被稱作中臺元年，一時間，各種中臺概念、各種形式的中臺方案如雨后春筍一般層出不窮。目前，中臺并沒有一個放之四海而皆準的標準定義，根本原因， 在于中臺并不是一個標準化的產品，根據每個企業自身的情況，中臺的建設方案可能千差萬別。

不過，可以達成共識的，是中臺的特點，它是企業共享能力、共享數據的組織或平臺，并且具備業務屬性，能夠實現業務價值，有響應的組織架構支撐。

中臺的形式也五花八門，除了公認的數據中臺、業務中臺以外，還有技術中臺、研發中臺、AI 中臺、移動中臺、算法中臺等等。參照中臺的特點，我們認為凡是與業務不直接相關的，都應算作后臺，雖然其他中臺也是能力的復用，或者間接產生了業務價值，但是為了厘清邊界，明確討論范圍，我們將集中就數據中臺和業務中臺展開論述。

數據中臺是什么

上一節我們探討了做數據中臺的原因，由此我們可以給出數據中臺的使命，是為了打通數據孤島、實現業務數據化，讓數據更快更好的產生價值。

結合數據中臺的使命，我們可以將其分為狹義的數據中臺和廣義的數據中臺。

狹義的數據中臺，指的是一套數據應用和工具，包括分布式 ETL、數據資產管理、數據標簽管理、數據沙箱、自助分析平臺、元數據管理、數據質量管理等等，底層則已現有的數倉、大數據平臺等為數據源，為企業提供數據資產管理的能力， 并持續挖掘數據價值，持續提供數據智能服務。

廣義的數據中臺，則在狹義的數據中臺基礎之上，包含了頂層數據戰略，數據治理體系以及數據管理及運營、數據文化培養和組織架構支撐，是一套持續管理和運營的體系。

可以這么說，狹義的數據中臺，是專為達成數據中臺的使命而打造，一類是讓數據更快的處理、整合、加工，比如分布式 ETL 工具。隨著傳統數據被大數據平臺逐步替代，ETL 工具對于大數據平臺的適配也需要與時俱進，支持分布式計算、彈性計算，并且減少開發量。

另一類是讓數據更好的產生業務價值，比如數據標簽管理，自助分析平臺等。數據標簽大家都在用，但是真正深度使用的企業都會感覺：建好容易用好難，如果沒有一套標簽管理系統，標簽是否重復加工，標簽的使用率、準確性等都無從掌控，業務部門想要針對近期營銷活動新建一個標簽，還得走開發流程，時效性也難以保證。

數據標簽管理系統就是為了解決數據標簽的使用問題而建立。自助分析平臺則是方便業務人員自助進行數據分析、加工、探索的平臺，它與數據沙箱結合，直接將去隱私話的生產數據提供業務人員分析，使數據更快的產生價值， 支撐關鍵決策。

廣義的數據中臺，則是輔助狹義數據中臺達成使命的機制，雖然看起來都很“虛”，但是卻是數據中臺成功落地的必要保障。

沒有數據戰略，在推進數據中臺建設，甚至建成后的日常運營中，難以溝通協調各部門利益，缺少“尚方寶劍”。沒有數據治理體系，數據管理無憑無據，無章可循，很容易造成 Garbage In-Garbage Out 的現象。

但是這里必須澄清一點，在銀行信息系統這樣復雜的環境中，數據質量的問題永遠存在。因此，“等數據治理好了，等數據質量控制好了，我們再開始做數據應用，做數據中臺”，這種想法是不切合實際的，因為不存在數據質量控制好了，數據治理好了的那一天，這是一個持續的過程，好到什么程度算好?誰來決定這個標準?

我們認為，數據質量很重要，需要持續改善，但是不影響數據中臺建設， 應該以用促治，在使用場景中有針對性的開展數據質量管理和數據治理。

沒有數據管理及運營，數據應用的價值無法持續產出，甚至會出現便宜甚至錯誤。缺乏數據文化，則會造成數據應用沒人會用，沒人想用，沒人愿意相信數據結論， 沒人愿意嘗試數據驅動，沒人愿意基于數據決策。沒有組織架構支撐，則會讓數據中臺這樣跨部門的體系難以推行，最終胎死腹中。

業務中臺是什么

同樣，業務中臺也可分為狹義與廣義，狹義的業務中臺，指的是由多個共享中心組成的服務整合平臺，通過梳理各業務系統共性的功能，在每個中心里將服務拆分、共享。我們建議，可以按風控中心、產品中心、用戶中心和旅程中心等維度整合共享，底層的數據能力由數據中臺提供。

廣義的業務中臺則包含了支撐各中心運營的組織架構和體制機制。正如前文提到， 沒有組織支撐，中臺不過是另一個大煙囪。每個業務中臺的子中心，都應有對應 的組織支撐，可以是虛擬的，也可以是實體的，最好由業務+科技+風險+數據的 綜合人員構成，小團隊作戰模式，以產品使用率、穩定性、客戶滿意度等為 KPI， 為業務中臺保駕護航。

風控中心管理全行所有的風控模型，以及對客產品交易、賬戶層面的動態安全策略，以底層機器學習平臺為支撐，共享全行風險管理能力。產品中心管理全行所有渠道的產品，控制購買額度、購買條件，靈活上下架等。

用戶中心基于數據中臺打通的全行用戶信息，建立用戶成長體系、權益體系，管理用戶標簽畫像，分析用戶行為軌跡，為旅程中心完成客戶全渠道一致體驗打下基礎。

旅程中心以用戶視角出發，以用戶體驗為最終目標，梳理、貫穿各渠道流程，整合、復用各渠道功能，最終達成全渠道客戶體驗統一。

結語——中臺的邊界

了解了中臺是什么，最后，我們來看看中臺不是什么，或者說，中臺的邊界在哪里。

首先，中臺不是銀彈。

沒有銀彈：沒有任何技術或管理上的進展，能夠獨立地許諾十年內使生產率、可靠性或簡潔性獲得數量級上的進步

——《人月神話》

軟件工程領域的“圣經”《人月神話》早就提出了沒有銀彈的說法，中臺也不例外。不要妄想通過中臺，解決企業內部一切的數字化問題。即使是上文提到的廣義中臺，也僅僅是包含了企業數字化轉型中，與數據、業務中臺相關的組織和機制，但是仍然無法涵蓋一個組織在數字化轉型過程中遇到的各種問題。中臺與其他新技術體系一樣，可以幫助企業降本增效，但是如何選擇業務方向，如何團結一心，如何切入市場，如何找到目標用戶等等，都是企業在中臺之外還需要努力的方向。

其次，中臺不是一個可以買來的即插即用產品。

不必為了做中臺而做中臺，也不必大干快上，一起步就是一個五年大工程。由于中臺與企業內部的數據、業務系統高度相關，雖然有相對標準化的產品可以預先研發，但是更多的工作，在于中臺與存量系統的對接、優化。

最后，中臺不是一個筐，別什么都往里裝。

當一個新技術體系難以明確定義時，最常見的現象就是邊界模糊，什么都可以放進去。最典型的例子就是“大數據”了。雖然有類似“5V”的定義，但是大數據的定義從來沒有統一，這也導致現在只要提到數據，都會冠以“大數據”之名。實質上，大家所指的絕大多數數據，并非是“大數據”，都是“小數據”。

概念的模糊，使得炒作時，無數企業擠破頭往里沖，也導致行業發生合規風險時， 與“大數據”沾邊的企業都風聲鶴唳，草木皆兵。這種現象，對于行業的發展弊大于利。

因此，我們必須厘清中臺的邊界：無共享，不中臺;無業務，不中臺;無組織， 不中臺。

沒有共享能力、數據的整合，不算中臺;沒有直接服務于業務，產生業務價值， 不算中臺;沒有組織支撐，仍然服務于某個部門，不算中臺。

行文至此，希望解答了大家心中的疑問。簡言之，做了中臺不見得就是數字化領軍企業，不做中臺也不見得就是古典互聯網時代的落后作坊。關鍵是認清自身的數字化現狀，擬定數字化目標，制定數字化路徑，優選場景，實現價值。中臺只是這條道路上，一套切實可行的行動方案。糟糕的公司治理，三天打魚兩天曬網的戰略定位，部門銀行的組織架構，即時搭建了中臺，也徒有其表，如此，中臺是砒霜。

堅定的戰略，清晰的目標，合理的組織架構，搭配中臺，可以使數據更快更好的發揮其價值，業務模塊更好的融合，用戶體驗得以更好的提升，如此，中臺是蜜糖。