前陣子我去一家年營收破三億的台灣保養品電商做診斷，老闆很驕傲地跟我說，他們行銷、倉儲、客服三套系統都很完整。我問了一個問題：「上週五那檔限時搶購，你們是靠什麼判斷哪些品項要追加備貨？」現場安靜了五秒，最後行銷主管說：「我們是隔週一看報表才知道賣爆，但那時候貨已經斷三天了。」這就是我這篇想談的核心——數據孤島，以及為什麼我這幾年一直在勸客戶認真看待「中台架構」這件事。
我必須先說一個立場：中台不是萬靈丹，也不是每家公司都需要一次做到位。坊間把中台講得太神，好像導入了就能起飛，這是錯的。但對於已經跨越單一通路、開始多渠道營運的台灣電商來說，數據孤島確實是現階段最昂貴、最被低估的內傷。
數據孤島到底長什麼樣子
很多老闆聽到「數據孤島」會覺得很抽象，以為是大公司才有的問題。其實它非常具體。當你的 ERP、CRM、倉儲系統、官網平台、甚至實體 POS 各自存著一份用戶資料、一份庫存數字、一份訂單紀錄，而這些數字彼此對不起來的時候，孤島就形成了。
我自己判斷一家公司有沒有數據孤島，只問三個問題：第一，要回答「某個 VIP 客戶在線上跟實體一共消費多少」需要幾個部門開幾次會？第二，倉儲看到的庫存，跟前台網頁顯示的庫存，是同一個數字嗎？第三，行銷投廣告當下，能不能即時看到那批流量帶進來的訂單真的有出貨？只要其中一題答不出來，孤島就在那裡。
決策延遲：最貴的隱形成本
數據不同步最直接的傷害是決策慢半拍。行銷在主打某款熱銷品，倉儲系統卻顯示早就缺貨，採購又因為數據延遲還沒下單。這種跨部門的步調不一，不只讓你白白燒廣告費，更會在客人下單後才發現出不了貨，賠掉的是信任。我看過最誇張的案例，是一家公司花了八萬廣告費把人導到一個三天前就售罄的頁面，這八萬幾乎等於直接點火燒掉。
用戶體驗的斷裂感
另一個常被忽略的，是顧客體驗的斷裂。客人在實體店累積的紅利線上不能用，客服接到電話卻看不到對方剛剛在官網瀏覽什麼、購物車放了什麼。對客人來說，他面對的明明是同一個品牌，卻像在跟好幾個互不認識的部門打交道。這種被當成陌生人的感覺，正是跨渠道忠誠度建立不起來的主因。
為什麼我會推中台，而不只是「串 API」
有工程背景的讀者可能會問：那把系統用 API 串一串不就好了？我早年也這樣想，後來吃過虧。點對點串接在系統少的時候很省事，但當你有五套系統，要兩兩互通就是十條連線；加到八套，連線數量會爆炸到二十八條。每加一個新通路、換一個金流，都要回頭改一堆既有的串接，最後整個系統變成沒人敢動的義大利麵。
中台的價值就在這裡——它是一個「中間層」，把共用的能力集中起來，前端各通路只跟中台對話，不再彼此糾纏。我習慣把中台拆成兩塊來跟客戶解釋：數據中台負責讓「資料」流動，業務中台負責讓「能力」被重複使用。
| 面向 | 傳統點對點串接 | 中台架構 |
|---|---|---|
| 新增通路成本 | 每接一個都要改既有連線，越接越慢 | 直接調用既有模組，數天可上線 |
| 數據一致性 | 各系統各一份，常對不起來 | 單一真理來源，全公司看同一數字 |
| 決策速度 | 等隔週報表，事後諸葛 | 趨近即時，當天可調整 |
| 維護難度 | 牽一髮動全身，沒人敢碰 | 模組獨立，改一處不影響全局 |
| 適合對象 | 單一通路、規模小 | 多通路、已有規模壓力 |
數據中台：建立「單一真理來源」
數據中台的核心任務，是把全渠道的第一方數據——實體、官網、社群、客服——彙整成統一標準，建立一個全公司都認的「真理來源（Source of Truth）」。再透過工具對用戶做全方位標籤化，讓行銷、產品、物流都看同一份用戶輪廓。做到這一步，前面講的那種「賣爆三天才知道」的慘案才有機會變成秒級響應。
我要提醒一個台灣很常見的誤區：很多人以為數據中台就是買一套 CDP（顧客數據平台）裝上去。工具只是骨架，真正難的是先把資料定義喬好。光是「一個會員」這件事，官網用 email 當主鍵、POS 用手機號、CRM 又用自編會員碼，沒先做好身分對應（identity resolution），灌再貴的工具進去都是垃圾進垃圾出。
業務中台：把共用能力模組化
業務中台則是把支付、物流、庫存、行銷工具這些重複造的輪子抽出來，做成獨立的服務模組。當你想快速開新戰場——進軍東南亞、開直播電商、上新的購物平台——可以直接調用這些成熟模組，不必每次從零開發金流和物流。對台灣中小型電商而言，這一塊的投資報酬其實比數據中台更快看得到，因為它直接砍掉重複開發的人力成本。
組織才是真正的硬骨頭
講了這麼多技術，但我做這行最深的體悟是：中台九成的失敗不在技術，在組織。系統可以買、可以外包，但「願不願意共享數據」是政治問題。
很多公司的部門牆，是用數據壘起來的。行銷握著流量數據、業務握著客戶名單，數據對他們來說是個人績效的籌碼，一旦全公司透明化，等於把自己的護城河填平。我輔導過一家公司，技術面三個月就把中台架起來了，結果卡了半年動不了，因為業務部門死活不肯把客戶資料完整匯進去。所以我現在跟客戶談中台，第一場會議談的不是架構圖，是「老闆你準備好讓數據透明到什麼程度」。
組織上我會建議搭配任務導向小組：從科層制轉向敏捷制，以一個明確目標（例如「把某產品線的 LTV 拉高兩成」）為核心，組一個包含數據分析師、產品經理、行銷專員的跨功能團隊，並且真的賦予他們調動中台資源的權限。沒有授權的跨部門小組，最後只會變成另一個開不完的會。
台灣電商常踩的四個坑
- 一次想做完美的全功能中台。這是最致命的。我看過公司編了千萬預算要一次到位，做了一年半還沒上線。我的建議永遠是：從最痛的那塊先做，通常是「庫存即時同步」或「會員身分打通」，做出一個看得到效果的小勝利，再往外擴。
- 把中台當成 IT 部門的事。IT 只能建系統，建不了願意共享的文化。中台一定要老闆親自掛帥，不然推不動。
- 資料治理擺到最後。很多人先建系統才想到欄位定義、資料清洗、權限分級，結果回頭重做。資料標準應該是第一天就談的事。
- 盲目跟風大廠的架構。阿里那套中台是為了支撐幾千個事業群，台灣一家年營收幾億的電商照抄，等於拿大砲打蚊子，養不起也用不滿。規模要對得上需求。
我會怎麼建議你起步
如果你是台灣中型電商的老闆，看到這裡覺得自己有數據孤島問題，我的務實路徑是這樣：先花兩週做一次「數據盤點」，把公司現有幾套系統、各存了什麼、彼此對不對得起來，攤在一張表上。光這一步，很多老闆就會嚇一跳。接著挑一個最痛、最容易見效的場景先打通，通常是庫存或會員。等這個小勝利讓全公司相信中台是有用的，再逐步擴大到業務中台的模組化。
切記，中台是手段不是目的。如果你現在只有一個通路、營運順暢，那真的不必急著上中台，把錢花在更划算的地方。但如果你已經被多通路的數據打架搞到焦頭爛額，那這筆架構投資就是值得的——對台灣電商而言，誰先把破碎的數據整合成敏捷的營運火力，誰就握有了未來的指揮中心。架構的深度，最終決定了競爭的高度。
想進一步了解數據如何串接與調用，可以參考我們的 API 文件，裡面有實際的資料介接範例；對中台、CDP、第一方數據這些名詞還不熟的話，名詞解釋 幫你一次補齊；想看更多電商營運實戰，歡迎逛逛 部落格 其他文章。
常見問題 FAQ
Q1：小型電商也需要做中台嗎？
多數情況不需要急。如果你只有一兩個通路、營運順暢，貿然導入中台只會增加成本與複雜度。中台是給已經有多通路、數據開始打架的公司用的。判斷標準很簡單：當你發現跨部門對數字、對庫存常常對不起來，且這已經實際造成損失時，才是該認真考慮的時機。
Q2：導入中台大概要花多少時間和錢？
這沒有標準答案，取決於你現有系統的複雜度和想做的範圍。但我強烈反對一次做完整全套。建議用單一場景（如庫存同步）切入，這種小範圍試點通常數週到三個月可見效，預算也比較可控。把它當成漸進工程，而不是一次性大爆炸專案。
Q3：中台和 ERP、CDP 有什麼不一樣？
ERP 是管內部營運流程的系統，CDP 是專門整合顧客數據的工具，兩者都可能是中台的「組成零件」。中台是更上位的概念——它是一個中間層，把這些系統的共用能力與數據集中起來，讓前端各通路統一調用。簡單說，ERP、CDP 是工具，中台是把工具串成戰力的架構與組織方法。
Q4：為什麼很多公司中台做失敗？
我的觀察是九成敗在組織，不在技術。最常見的是部門不願共享數據（把數據當個人績效籌碼）、老闆沒親自掛帥（丟給 IT）、以及一開始就想做完美全功能。技術問題都有解，但組織政治和決心問題，是花錢買不到的。
Q5：要怎麼說服公司內部跨部門共享數據？
靠老闆權威硬推效果有限，我的做法是先創造一個讓大家有感的小勝利。例如先打通庫存同步，讓行銷部門親身體驗到「不再因斷貨白燒廣告費」的好處，他們自然會更願意把自己的數據也交出來。用實際利益降低抗拒，比開十場會議講大道理有用得多。
本文由電商顧問林克威撰寫，更多台灣電商數據與營運分析請見 ECPRO 部落格。