銀行資料人生存現狀——問題如何產生，以及如何做出改變

在上一篇文章《銀行資料人生存現狀》裡，我們探討了銀行內部的兩種資料人：

技術資料人和業務資料人，他們的角色、職責和痛點，今天我們繼續探討一下，這種現象出現的原因以及我們能做些什麼。

在銀行，業務與科技的矛盾由來已久，業務抱怨科技開發慢，質量差，體驗不好，科技抱怨業務老改需求，自己需求都沒想清楚。

到了資料這裡，不過是業務與科技矛盾的延伸與加劇，延伸是因為資料也歸屬科技條線，加劇則是因為資料產生及提取加工的過程比科技開發更加滯後。

我們看下圖：

在物理世界裡，市場、客戶、監管的變化速度是非常快的。

能透過資料提取解決的需求，自然是透過資料提取來解決，通常也是為了應對市場、客戶或監管發生的變化，從上圖大家也可以看出，相比物理世界的變化，數字世界的變化肯定是延遲的，因此才需要儘量在每個環節縮短時間，以應對物理世界的變化。

對於資料提取解決不了的需求，物理世界發生變化以後，業務部門需要理解現狀，並把這些變化轉化為業務需求，這個過程也充滿挑戰。需要對監管意圖瞭解，對同業現狀熟悉，對本行系統更是如數家珍。

然後科技部門需要把業務需求轉化為技術開發需求，完成各種評審、立項流程後才能啟動開發。

這個過程，快則數日至數週，慢則數月。

實際開發的過程並不長，但是還有測試的過程，包括內部測試、SIT、UAT、準生產測試等等，測試完成後根據投產視窗定期上線。

國有銀行一年通常有4個大版本日，4-8個小版本日，股份制和城商行最快的也需要一月一個投產日，領先的網際網路銀行可以做到每週一版本(也僅限非核心繫統)，接近網際網路公司的迭代速度。

上線以後系統可以完成業務需求，但是資料的積累，以及積累以後的採集還需要一段時間，而且很多時候，僅採集一個系統的資料是不夠的，需要整合其他系統的資料，加工後一併採集。

這就涉及到資料倉儲和資料集市，資料入倉(載入進入資料倉儲)又需要一段時間。

這一系列流程結束之後，才可以進入到上文提到的資料提取流程。

因此，不是業務部門著急，而是市場變化、業務需求、系統開發、資料採集天然的存在巨大的時間差，業務考核的壓力大，不得不在每一個環節壓縮時間。

聽起來，這似乎是一個無解的問題，實際上還是有很多改進的地方。

• 比如提需求時，可以更加的有預見性，透過對過去和當前情況的研判，預測下一步市場、使用者、監管可能發生的變化，提出具有前瞻性的需求;

• 比如在開發時，透過敏捷開發的方式，小步快跑，快速迭代，採用先做出基礎產品用起來，再根據反饋逐步完善的模式，可以彌補開發滯後的時間差;

• 比如在資料採集階段，採用流資料採集和計算的模式，讓資料產生後能夠實時的被採集和計算;

• 比如在資料整合及提取階段，透過資料中臺等領先架構，整合全行資料，並預加工指標，讓業務可以直接探索資料，極大的縮短用數流程。

除此之外，要讓技術資料人和業務資料人真正互相理解，緩和矛盾，還是要讓彼此有機會站在對方的角度看問題，也就是讓技術資料人學點業務，或者讓業務資料人學點技術。

讓技術人學業務這件事情，非常依賴於組織架構和考核的調整。

不管是學業務還是學技術，核心的環節在於下場實操。如果光學不練，不下場真正的做業務或者使用技術，是無法找到感覺的，也無法真正理解對方。

要讓技術資料人真正的有做業務的感覺，必須讓他待在業務部門，每天和業務一起開會，討論經營目標，解決業務問題，急業務之所急，痛業務之所痛。資料不準一起捱罵，資料提取太慢一起著急，最好還背上一半的業務KPI。

因此，組織架構、考核機制不調整，技術資料人學業務這件事情還是挺難落地的。而業務資料人學技術這件事，倒不必調整組織架構或考核機制，只要自己真的學了，並且在日常工作中用了，就能實實在在的提升工作效率。

真正的難點，在於心態的調整。

建議業務資料人不必排斥技術，或者給自己設限。我接觸過很多業務部門的同事，一聽到技術專業術語就談虎色變：

“不要跟我講技術，我聽不懂”

“哎呀，我學不會的，還有好多事情，不浪費時間了”

“這高大上的，我小白不理解”

能進銀行，大家的智商都不低，都是本科研究生學歷，大行甚至都是985/211，要想學點新東西根本不難，但是大家還是習慣待在自己的舒適圈裡。

你不出圈，我不出圈，機構怎麼出圈，怎麼轉型?

稍微學點技術，能讓日常工作事半功倍，省下更多的時間可以幹更重要和緊迫的事，何樂而不為?

學習技術並不意味著一定要程式設計，可以先從使用工具開始。

版本管理工具：SVN

這可以說是最易上手的版本管理工具了。為什麼要用版本管理工具呢?

主要是在多人協作的場景下，如果幾個人同時需要修改一個文件，原有方式通常是A改完發B，B改完發C，如果有人基於歷史版本做了改動，那麼有些改動就會丟失，比如C在B改完之前，就開始基於A的版本修改了，那B修改的內容就會丟失，如果B又沒有采用審閱模式等可以追溯修改位置的功能，則只能透過兩個版本的檔案比對來查詢，效率極其低下，而且很容易出錯。

如果採用版本管理工具，類似問題完全可以避免。

SVN在修改檔案時，可以先鎖定檔案，如果想修改檔案時發現已經被鎖定，說明別人正在修改，可以等對方提交修改以後，再更新最新版本的檔案，然後鎖定、修改。

所有的最新版本檔案都存放在版本管理伺服器上。萬一本地檔案丟失也沒關係，而且最關鍵的，可以方便的追溯歷史上的每一個版本，如果在提交時加上註釋，還可以清楚的知道每一次因為什麼原因，修改了哪些內容。

學會SVN的常用操作大概只需要5-10分鐘，一杯下午茶的時間都用不了，強烈業務資料人，乃至於所有的非技術崗位嘗試一下。

資料庫：Access

一般安裝了Office套件都會安裝Access，在支援編寫SQL指令碼進行查詢的同時，Access也提供了功能強大的圖形介面，可以透過圖形介面的操作實現與SQL指令碼等效的功能，而且可以直接匯入Excel等常用資料來源。

為什麼要使用Access代替Excel呢?

不可否認，Excel功能非常強大，在日常工作中，沒有Excel做不到的，只有你想不到的。

但是，Excel在處理超過十萬行資料的時候，特別是涉及列之間透過公式加工計算等等操作時，由於全部需要載入到記憶體進行計算，會導致記憶體、CPU等資源迅速耗盡，從而使得完成基礎的操作都非常卡頓，甚至經常出現Excel程式崩潰的情況，這簡直是資料人的噩夢。

而Access，雖然是一個相當輕量級的資料庫，但是由於底層實現方式的不同，在處理大量資料時更加遊刃有餘，最關鍵的是學習成本低，透過圖形介面的操作即可完成常用操作。

不敢說救表哥表姐於水火之中，至少能極大的減輕日常工作量。

視覺化的資料分析工具

既然被稱作資料人，那就離不開資料分析。

雖然大部分場景，使用Excel就可以滿足要求，但是仍然有一些場景，需要建立一些簡單的模型。

做個迴歸分析，預測一些趨勢，給出一些基於資料分析的可靠結論，可以讓你的報告更加有說服力，讓領導對你的能力也更加認可。

目前有不少工具，可以透過視覺化的方式完成建模，一行程式碼也不用寫。

比如之前在《開源還是閉源，從Python與SAS說開去》中提到的WPS (據說現在已經更名為Altair SCL) ：

透過拖拉拽的方式，把資料來源、模型結果組裝在一起，就能自動完成建模和輸出的過程。這裡放一個介紹影片，感興趣的可以看看，核心特點是支援SAS, SQL,Python,R等語言來構建模型，可以混合多語言程式設計。

上面提到的是支援SAS的開源和閉源的資料分析工具，現在主流資料分析市場上還有很多人喜歡用Python，但對業務資料人來說，要在Jupyter Notebook上寫python進行建模是有一定門檻的。

現在市場上也出現了不少零程式碼資料建模工具，比如Knowledge Studio等產品，不需要編寫程式碼就可以建模，還支援完全自動建模，這就對業務資料人非常友好，只需要稍微學點資料分析的基礎原理就可以自主進行演算法模型的構建;

對於技術資料人來說，這類零程式碼的建模工具也可以大大提升建模的效率，更具有意義的事是有了此類零程式碼工具，自己也能有更多的時間抽出來進行業務的研究，提升自身業務的能力，更有利於長遠的職業生涯發展。

結語

總的來看，受制於銀行的組織架構和體制機制，業務資料人和技術資料人都面對著理想和現實的落差，一邊憧憬著高大上的機器學習模型，一邊苦哈哈的幹著最基礎的髒活累活。

整個機構的現狀很難改變，不妨先從自己開始改變，技多不壓身，當你的視角發生變化以後，一切都會慢慢的變得不同。