中臺在銀行業的應用

曾巍奕

一場疫情，讓銀行數字化轉型再次提上日程。“無接觸銀行”不再是戰略規劃中亮眼的提法，而是如今各銀行經營中不得不面臨的切實問題。而中臺，作為數字化轉型中最火熱的概念，近年來在行業里風頭無兩。

數據中臺

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

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

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

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

不快很好理解，即時效性達不到要求，利用最新的流數據處理，分布式ETL技術，數據中臺可以更快地的整合、加工數據?？墒谴蛲ㄐЧ缓迷撊绾卫斫饽兀?/p>

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

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

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

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

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

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

業務中臺

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

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

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

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

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

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

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

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

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

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

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

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

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

2019年被稱作中臺元年，一時間，各種中臺概念、各種形式的中臺方案如雨后春筍一般層出不窮。目前，中臺并沒有一個放之四海而皆準的標準定義，根本原因，在于中臺并不是一個標準化的產品，根據每個企業自身的情況，中臺的建設方案可能千差萬別。不過，可以達成共識的是中臺的特點，它是企業共享能力、共享數據的組織或平臺，并且具備業務屬性，能夠實現業務價值，有響應的組織架構支撐。

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

數據中臺的使命，是為了打通數據孤島、實現業務數據化，讓數據更快更好的產生價值。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

首先，中臺不是銀彈。沒有銀彈：沒有任何技術或管理上的進展，能夠獨立地許諾10年內使生產率、可靠性或簡潔性獲得數量級上的進步?！度嗽律裨挕?/p>

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

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

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

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

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

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

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

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

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

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