在銀行，業務部門是利潤中心，而科技部門是成本中心（資料部門一般劃在科技部門底下），能賺錢的部門強勢嗓門大，同時壓力也大。為了完成KPI和抗住同行的競争壓力，業務部門經常需要快速提取各類業務資料名額。
業務需求提得急，科技反應慢，為難的就是夾在中間的銀行資料人（也就是銀行的“表哥表姐”）
- 給分行的填表模闆必須做好校驗，不然填的數字五花八門。
- 這張報表要跨幾個業務系統拉資料，暫時沒辦法做報表，能不能寫個宏把幾個報表的資料整合了？
這幾個場景裡，有很多業務資料人的痛點，比如曆史資料的管理，數出多門的問題，手工填報的準确性，共性需求的提煉，多資料源的打通等。但大部分業務資料人還是習慣用Excel來處理資料，雖然Excel很強大，可以應付絕大多數需求，但是在以上痛點環節仍然力不從心，更多時候充當的是輕量資料庫和計算功能。
懂IT的朋友可能會說，在資料庫寫兩條SQL就解決了，這話沒錯，但如果銀行資料人有工具能解決上述問題，并且支援資料庫之後的資料增改删、資料展現、互動分析、可視化/移動端大屏展示，并做到辦公協同，那就不用再受業務和科技部門的氣，也能減輕科技部門對報表的需求響應壓力！而這，就是我今天想來講的報表工具FineReport，它本質是一個通用的報表制作和資料可視化工具，是一個開放的企業級Web報表工具。
一、如何花1小時完成填報模闆，在保證手工填報準确性的同時，解放資料部門10+人力？
如果你是總行的資料部門，那麼必須給分行的填表模闆必須做好校驗，不然填的數字五花八門。
而填報就是向資料庫中錄入資料，用于固定格式的資料收集，就好比你注冊app時送出的郵箱、使用者名、密碼，都會按照格式存放到資料庫中。填報也需要一個模闆，模闆示例如下。
FineReport填報模闆示例
填報模闆由控件組成：文本控件、數字控件、密碼控件、單複選框、網頁、檔案等。控件對應着資料字段，有了填報模闆，就可以将填報模闆的連結分享給填報者，進而收集資料，并且允許使用者（填報模闆開發者）實作對資料庫的增删改。且出于資料品質和資料安全的考慮，還可以對填報資料做校驗操作、暫存填報資料等。
二、如何打通多資料源，實作跨業務系統取數做報表？
在銀行中，由于同一張報表的資料通常會來自多個不同的業務系統，甚至來自多個不同的異構資料庫，進而形成我們常說的多源報表。對此，FineReport提供了異構資料源模型，可以進行多源資料關聯，使得同一張報表的資料可以來源于同一資料庫的多個不同表，或多個不同資料庫。
将需要使用的多種資料源的資料預先處理好，并存儲至目标資料庫，報表隻要對接處理好的資料即可。
三、資料部門如何及時響應業務部門的報表需求？
這裡舉個案例說明，以南通農商銀行為例，其資料和IT部門借助FineReport針對業務部門的正常需求，開發了三項表資料分析頁面（如下圖），通過一張頁面，就可以實時檢視南通農商行當日存貸資料、存貸占比、各片區存貸彙總資料、各支行存貸詳細資料，并且在不同的層級之間設定了關聯，可以直接穿透和鑽取。
上司看到存貸占比異常，可以直接下鑽到各個片區，在從片區找到支行，直接定位到具體負責的支行，支行上司也可以用這個系統再詳細分析，找到具體哪塊的業務變化最大，然後做出業務調整或者人事調整，及時幫助業務部門和上司洞察資料趨勢，進而輔助決策。
總結
雖然Excel很強大，可以應付絕大多數需求，但是在以上痛點環節仍然力不從心，更多時候充當的是輕量資料庫和計算功能，且在銀行大資料處理量和需及時響應業務部門需求的背景下，資料部門應該及時找到替換Excel的合适報表/BI工具，釋放科技部門的報表取數精力，讓資料部門能夠快速支撐業務部門的資料分析需求。
最後把工具和模闆一起放這，需要自取。