一份資料存了3次：保險公司的資料孤島求生記（上）｜專家論點【黃婉中】

作者：黃婉中（雲端架構師）

上禮拜跟一個做保險業的客戶聊天，聊到他們內部的資料環境，我心裡默默算了一下：他們光是核心保單系統的資料庫，就有 400 到 450 GB，而且累積了 10 到 15 年的歷史資料。

客戶說：「我們每天晚上跑資料整理，要跑 8 個小時。」

這段時間差限制了分析與財務洞察能力，也讓與合作夥伴的資料交換效率低落。 

「AI履歷健檢」看見自己優勢：https://campaign.1111.com.tw/resume-review/
更多科技工作請上科技專區：https://techplus.1111.com.tw/

這篇想跟你聊聊，一間傳統企業的資料環境，是怎麼一步步變成「不敢動」的樣子，以及這種狀況背後，到底卡在哪裡。

先講結論：資料太散

這間公司做的是車險，保戶買車廠配套保險的時候，背後的核保、理賠、財務資料，都要靠這套系統撐著。

問題不是資料量大，而是資料散落在太多地方：

• 好幾套版本不一的 SQL 資料庫，各自存著不同時期的保單資料
• 資料在地端（on-premises）和雲端之間，各放一部分
• 跟外部夥伴（維修廠、其他保險公司、產業公會）交換資料的時候，沒有安全又方便的管道
• 想知道「這筆資料是從哪裡來的、被誰改過」，答案幾乎是「不知道」

這就是我們常說的「資料孤島」（Data Silo），資料被鎖在各自的小房間裡，沒有人能拿到完整的全貌。

資料孤島

如果你也在企業裡管過資料，大概能想像這幾個場景：

報表是昨天的
因為資料每天晚上才批次處理一次，主管想看「現在」的數字，得到的永遠是「昨天算完的」數字。對這間保險公司來說，這代表核保、理賠、財務的決策，都慢一拍。

同一份資料，被存了好幾次
資料從原始系統，被搬到分析用的資料湖，又被搬到給主管看報表的資料倉儲。同樣的東西存三次、算三次，浪費儲存空間，如果是跨平台或地區，帳單也跟著長大三倍。

沒人敢保證資料是乾淨的
資料散落各處，加上缺乏治理機制，代表沒有人能很有信心地說：「這份數字是對的，來源也查得到。」對一間受金融監理單位監管的保險公司來說，這是合規風險。

維護像走鋼索
資料流程串了一堆環節，中間只要有一個關卡壞掉，整條線就卡住。而且這套系統背後，還牽涉到公司正在推動的核心系統轉換，舊資料架構跟新系統之間，需要一個可靠的橋樑。

為什麼改架構這麼難

看到這裡你可能會想：「那就重新設計架構啊，有什麼難的？」

難的地方在於，這種老舊架構通常已經運作了 10 年以上，牽一髮動全身。財務、理賠、核保，每個部門都依賴著現有的報表和流程，貿然改動，風險比維持現狀還高。

再加上企業內部往往缺乏足夠的資料治理經驗，就算知道問題在哪，也不知道怎麼下手：是先解決資料搬運的效率問題？還是先補上治理和安全的缺口？兩件事其實環環相扣，很難單獨處理。

這也是為什麼很多企業的資料環境，會一直維持「堪用但很痛」的狀態，不是不知道問題，是不知道從何改起。

下一篇，我會跟你分享這間公司後來怎麼解決這個問題，用的是現在資料圈很熱門的一種新架構思維，把「搬資料」這件事的複雜度，降到最低。