中小銀行是否具備以“以客戶為中心”去了解客戶的資本？
作者：張慧丹（廣州農商行網絡金融部）
客戶眾眾，場景之中。大數應用、銀行好逑。
求之不得，寤寐思服。心之所念，輾轉反側。
面對業界如此火熱、備受追捧的“大數據”，筆者借用PS《詩經·關雎》開篇，希望藉此表達中小銀行在銀行業務中應用大數據的嚮往之情和求索之苦。
嚮往之情在於，在線下客戶越來越少親臨網點，即使是在線上，客戶也不再依賴銀行的電子渠道。在客戶流失的同時，更令銀行憂慮的是銀行可掌握的客戶數據源越來越單一，對客戶的瞭解程度越來越片面。
以前銀行經營客戶可以通過網點、網上銀行\\移動銀行等銀行渠道開展存款、轉賬、理財、貸款等業務。現在客戶可以方便的通過微信、支付寶、淘寶等第三方平臺辦理支付、轉賬、理財、小額貸款、繳費、白條等形式多樣的金融服務。面對漸行漸遠的客戶、面對紛繁複雜的金融業務（更多的還有非金融類的社交、消費活動等），我們迫切需要一雙慧眼去看清楚客戶身邊所發生的一切變化。
“大數據”就是這雙慧眼，銀行需要通過“大數據”去收集客戶的行為數據、交易數據等，需要通過“大數據”去刻畫出客戶的完整數據畫像（不僅僅侷限於金融數據畫像），並以此為據去挑選客戶、服務客戶，根據客戶的喜好、特徵去優化產品、改進服務。
求索之苦在於，大部分銀行的科技實力還停留在“IT”時代，而在如今的“DT”、“AI”時代下，大部分銀行的科技實力遠遠落後於一些領先的互聯網企業，即使在研發效率上也是落後於大部分IT公司。銀行缺少實踐最新金融科技的工具、技術、方法、經驗、資源。
既然“自力更生”有短板，那就尋求“他山之石”以“攻玉”吧。可在尋求的道路上，不少銀行都經歷過諸多坎坷：
內部數據比較零散
這種情況主要是傳統的銀行數據存儲往往是以產品或業務為中心去設計存儲結構的。而現在不論是從技術實現到業務推廣所提倡的都是“以客戶為中心”，所以當真正去實施大數據應用項目時，在進行業務數據梳理、清洗的第一個環節時，經常會遇到很多數據歸集、整合問題。
缺少合適外部數據
這種情況經常發生在線上授信業務和零售業務方面。在開展線上授信業務時，由於缺少客戶在具體行業、場景中的行為數據、交易數據，多數銀行只能採取與外部機構合作，開展聯合風控。銀行自身的風控能力侷限在人行徵信風控，缺少對業務場景的一手風控措施。在開展零售業務時，營銷目的主要是促進客戶理財、支付、消費等交易活躍，但多數情況下能利用的僅有銀行內部的交易數據，在這種情況下所刻畫出的客戶畫像比較片面，其被假定為“該客戶僅是某銀行的單一客戶”。如果客戶是活躍客戶，那據此開展的一些營銷措施還是有效的。但當客戶是沉默客戶時，那據此開展的一些營銷措施就收效甚微，因為無法判定客戶在銀行外部場景是否活躍，是否有其他業務需求。
投入大週期長見效慢
目前銀行在實施大數據應用時（如：授信風控、客戶畫像/營銷），多數是選擇與專業技術解決方案供應商合作，而相關的系統軟件部署、研發人員投入等費用也是較之往銀行傳統業務系統的費用投入有很大增幅。同時，這些項目除了投入費用大之外，往往需要經過項目立項、採購招標、研發實施等過程後才能實現業務上線，這個過程至少1年。即使上線後，還需要一段時間去生產環境驗證數據、訓練模型，前後至少1-2年業務才能算是基本穩定。這個週期明顯與不少中小銀行的“當年立項、當年見效”的期望不符。
面對上述坎坷，很多中小銀行往往無法邁開步子，其中當然是有很多現實的無奈。但是就束手無策了嗎？就坐以待斃了嗎？我們很多銀行的童靴們開啟了DIY模式，通過SQL、Python、SAS等編碼語言及相關工具在日常工作中自行編寫腳本進行業務數據的統計、分析，以解決部分業務需求、提交工作效率。這種精神值得鼓勵，但筆者並不提倡，此乃無奈之舉，無異於隔靴搔癢。
如果銀行在靠自身科技資源無法自建大數據應用，又難以抉擇與哪些合適的供應商進行業務合作的情況下，筆者認為可以從三個方面思考，逐步解決大數據應用的難題。
一、重構數據結構：按“以客戶為中心”的思想重構業務系統數據結構；
二、豐富數據資源：在合法、合規的前提下，以開放的心態與外部機構開展數據資源共享合作；
三、支持業務創新： 大數據應用項目以及其他金融科技項目往往被看作是傳統銀行實現自我救贖的靈丹妙藥，所以在項目抉擇時慎之又慎。但筆者認為，越是新的技術越是需要大膽嘗試，越是需要長時間的實踐積累。因此，需要在資金、人員、時間上給予業務部門足夠的支持。
在上述三個方面的問題當中，筆者認為“重構數據結構”更是當務之急，應當優先解決。
因為目前提倡的是“以客戶為中心”，當銀行在經營意識、服務方式、產品功能等方面下功夫、花精力，尋求如何“以客戶為中心”提升服務能力的時候，往往忽視了一個問題：是否具備以“以客戶為中心”去了解客戶的資本？
自從進度IT時代，銀行認識客戶的途徑就不再以人的意志為轉移（即：憑人為經驗累積），而是通過對相關業務系統存儲的客戶個人數據、歷史交易數據、資產數據等的解讀去了解客戶。當進入DT時代後，銀行可以通過整合內外部數據，拓展認識客戶的維度。
但僅僅擁有數據並不能說明銀行擁有“以客戶為中心”去了解客戶的資本，是否建立合適的數據結構和具備有序的數據管理能力才能決定銀行是否具備“以客戶為中心”去了解客戶的資本。因此，不論我們是尋求外部供應商實施大數據應用，還是通過自有科技資源完善大數據基礎建設。重構數據結構都是我們必須重視，也是必須儘早實施的基礎工作。
在軟件行業中有一個編碼思想“面向對象程序設計(Object Oriented Programming)”，這種理念與“以客戶為中心”有異曲同工之妙，具體落實在數據結構重構方面，筆者覺得可以稱之為“面向用戶數據設計(User Oriented Database Design)”。傳統的銀行業務系統往往是以產品為中心或以賬戶為中心進行業務數據存儲的，這種數據存儲設計對於單個業務系統的處理效能是比較合適的選擇。
但這種數據存儲結構使得客戶數據之間的關聯性不高、邏輯性不強，增加了我們以客戶為中心去管理數據、統計數據、分析數據的難度。因此，需要以“面向用戶數據設計(User Oriented Database Design)”為指導重構數據結構，以滿足大數據相關業務應用落地實施的基本要求。
按照“面向用戶數據設計(User Oriented Database Design)”設計思想，可以把數據結構分為三個模塊，即：用戶模塊（User Module）、標籤/屬性模塊（Tag/Attribute Module）、事件模塊（Event Module）。
用戶模塊（User Module）
主要記錄用戶的標識及基本信息，為了適應內外部數據整合的需要，用戶標識應該包含主標識（如：身份證號）以及關聯標識（如：手機號、社交平臺賬號、設備號等）。因為我們認識客戶的數據很多來自於外部互聯網平臺，這些平臺的用戶大多並非實名用戶，補充關聯標識將有助於據此關聯識別客戶在互聯網平臺的交易行為。
標籤/屬性模塊（Tag/Attribute Module）
主要記錄客戶的自然屬性信息（如：年齡、性別、職業、學歷等）以及相關的業務標籤（如：資產等級、是否支付活躍客戶、是否移動銀行沉默客戶等）。業務標籤的種類、維度、數量是隨著業務的發展需要不斷優化、完善。
事件模塊（Event Module）
主要記錄客戶在什麼時間、什麼渠道做了什麼交易。交易的業務品種是什麼、價格多少、交易對手是誰等等。其中，還需要重點記錄的是客戶的行為事件，例如：客戶登錄App的時間、停留的頁面、查看的產品、耗費的時間等。過去這些行為事件往往被銀行業務部門忽略，以至於在想改善客戶體驗、識別客戶潛在需求時又苦於沒有數據支撐。
上述設計思想的實施並不需要依靠特別的技術手段，大多數銀行依靠行內自有的科技資源就可以實現。同時，通過與各類大數據供應商進行交流也可以發現，大多數供應商所提供的大數據畫像/營銷解決方案也是按照類似“用戶->標籤->事件”這樣的實施邏輯去構建其底層的數據結構。在這個層面上大多數供應商的處理方法大同小異，不同供應商的核心競爭力的區別在於後續的數據分析\\建模能力，以及配套的營銷管理工具的完備程度、易用程度等。
重構數據結構這項工作始終是銀行必須首先邁過的坎，只有邁過這道坎，後續的數據建模、營銷分析、標籤優化、客戶促活、決策指引等系統實施/業務運營工作才能有條不紊的持續開展下去。
同時，筆者也希望提供金融科技解決方案的企業可以多從技術賦能、業務賦能的角度去調整產品結構、服務結構。除了面向銀行提供一攬子解決方案的同時，也可以按業務板塊或功能模塊提供相對獨立的產品或技術服務，以滿足中小銀行“小步快跑、逐步迭代”的需要。
那些年銀行錯失了“餘額寶”，流失了存款；那些年銀行錯失了“紅包雨”，流失了支付；那些年銀行錯失了“場景”，流失了“貸款”。如今銀行希望追尋大數據，不再與用戶錯過。追尋的道路雖坎坷，但只要拋開顧慮，勇敢堅定的走好每一步，就能夠真切的擁抱大數據，擁有大未來。
閱讀更多 九卦金融圈 的文章
