中臺之於銀行，蜜糖還是砒霜？

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

為什麼要做中臺?

資料中臺

(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”的定義，但是大資料的定義從來沒有統一，這也導致現在只要提到資料，都會冠以“大資料”之名。實質上，大家所指的絕大多數資料，並非是“大資料”，都是“小資料”。

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

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

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

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

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