中國資訊化建設發展了幾十年，像政府和央企、國企這類不差錢的，很多系統購買的原因之一就是“消除資料孤島”。這個口号喊了幾十年，結果系統是越來越多，資料孤島也越來越嚴重。就像給褲子打更新檔，哪裡破了個洞，哪裡補一塊，到最後更新檔越來越多，但褲子卻沒法穿了。
看了很多文章，大家對于解決資料孤島問題都是淺談即止，今天跟大家一起深入思考一下，為什麼消除資料孤島這麼困難？歡迎大家在評論區探讨。
可能有朋友經常聽說這個詞，但對概念還不清晰，我這邊先給大家介紹一下。
什麼是資料孤島？
看上面這張圖，應該就能明白。
企業發展的過程中，由于不同業務部門使用的系統不同，資料存儲的方式、地方都不同，這就導緻了部門之間的資料無法共通，最後這些資料就變成了一個個孤島，毫無關聯性。
資料孤島又有兩種不同的類型
- 實體性資料孤島：不同部門的資料互相獨立存儲和維護，彼此間在實體層面不互通。
- 邏輯性資料孤島：不同部門定義和管理資料的方式不同，跨部門合作溝通成本非常高。
為什麼會出現資料孤島？
想要搞清楚資料孤島産生的原因，我們先來回顧一下軟體行業發展經曆的幾個階段：
- 單機工具軟體階段
最早的軟體就是單機運作的，而軟體産生的資料也都是采用各自的資料格式存儲的，甚至大多數企業級資料還會進行一定的加密處理。很明顯，每個單獨的檔案與生俱來就是孤島，可以說有了軟體，就有了「資料孤島」。
- 資料庫軟體階段
資料庫軟體逐漸發展，就開始采用應用與資料分離的系統設計，各系統采用關系型資料庫存儲系統資料。但這個階段仍然采用集中式資料存儲的方式，資料标準不一，是以這個階段資料庫之間仍舊不能形成互通。
- 分布式軟體階段
随着軟體設計架構的變動，資料開始采用分布式存儲方式，不同儲存設備之間的資料能夠通過網絡連接配接起來，對外作為一個整體提供存儲服務。但這類軟體的出現，主要目的是解決資料存儲的效率和安全性問題，對于不同系統資料的共享互動幫助不大。
- 雲計算軟體階段
軟體發展到今天，基本上屬于進入了雲計算時代，資料存儲都采用了分布式雲存儲資料中心。在這個階段，系統之間資料共享和互動的可能性增大了，但真正要實作資料共享還牽扯着政策、提質和利益的關系。
弄清楚了發展階段，我們也很能夠明白「資料孤島」産生的原因。最初的原因是單機工具軟體與生俱來的弊端，那為什麼到雲計算時代仍然會存在資料孤島呢？核心的問題是，不管在哪個階段，各個系統在設計的時候都是聚焦業務系統本身的，而很少考慮與其他系統之間的互動和共享。
是以，「資料孤島」的産生既是業務系統的問題，也是人的問題。
國産化大趨勢下，測評了國内知名的幾大軟體，最後還是選擇了FineReport。如果你們公司目前「資料孤島」問題很嚴重，但還沒有思考出合理的解決方案，那我建議你繼續看下去，FineReport既可以解決系統的問題，也能解決“人”的問題。
從系統層面來說，FineReport能夠實作整合各個業務系統資料的功能，作為一個純 java 軟體，跨平台相容性非常好，能夠和各類業務系統進行內建。比如打通銷售部門和庫存管理部門的資料，庫存管理人員能夠第一時間了解到銷售訂單情況，及時備貨，防止出現傳遞逾期現象。
其次是資料标準，FineReport能夠直接設定填報标準，直接填報資料。從實際操作來說：資料填報頁面開發者開發完一張填報模闆後，将填報模闆連結分享給30個基層機關的填報人員，他們就可以直接在網頁上填寫資料，在滿足開發者設定的資料送出格式要求後，就可以成功送出資料，資料能夠按照一定規則彙聚到大資料共享平台。
最後是解決“人”的問題。
業務部門隻關心本部門資料和利益是再正常不過的事情，隻有在觸碰到痛點，比如需要跨部門取數的時候，業務部門才會覺得資料不通的痛楚。這個時候，他們往往直接給IT部門提取數需求，然後不停地催促，壓根不會思考“能不能打通兩個系統”這種問題。
整合系統資料本就是IT部門或者說CIO思考的事情，CIO應該思考的是如何讓業務部門更規範地使用資料和提需求，如何賦能業務。
FineReport在業務層面，能夠通過制作各種業務分析報表，加速業務決策的精準度和效率。
生産部門
第一步是整理資料名額體系。
第二步是建立生産管理駕駛艙。
營銷部門
第一步是做好計劃分析、執行監管和銷售營運，幫助營銷部門打通與其他部門之間的資料壁壘，及時回報營運風險和市場變化的洞察。
第二步是建構營銷分析類大屏，輔助業務決策。
财務部門
第一步是根據财務分析的闆塊，梳理财務部門的名額體系。
第二步是根據财務部門的需求制作相應的分析大屏。
篇幅有限，關于大資料決策平台具體的建設方案這邊不一一展示，大家可以自己下載下傳下來閱讀，除了建設理論，還給大家整理了實踐案例，建議大家閱讀，少踩坑。