老闆問一個數字，工程師排隊三天才回覆——這件事本身就已經是決策警訊。不是工程師慢，也不是老闆太急，而是這家公司的數據結構還沒長到能支撐日常決策的程度。當每一次「我想看一下上個月哪個通路 ROI 最好」都要一次專案，行銷自然就會回到憑感覺下預算的老路。
這種困境不是導入一套 BI 工具就能解決。真正的問題通常在更上游：金流、電商、ERP、廣告後台、客服系統各自為政，同一筆訂單在不同系統長得不一樣，客戶編號規則對不上，退貨到底算哪個月也沒人拍板。報表撈得慢，只是這些混亂在最下游的症狀。
報表需求怎麼提，才不會變成無底洞
經營者發案時最常見的錯誤，是把需求寫成「我要一個儀表板，看得到營收、庫存、會員、廣告成效」。這句話對工程團隊來說幾乎沒有資訊量，因為每個名詞背後都藏著十幾個定義問題。營收是含稅還是未稅？退貨後要不要回沖？會員是註冊算還是有消費才算？
比較實用的提法，是先鎖定三到五個「你每週真的會拿來做決策的問題」。舉個例子，假設你是一家中型電商的老闆，你可能真正想回答的是：這週該加碼哪個廣告組合、哪些 SKU 要補貨、哪個客服議題重複出現。把問題列出來之後，需要哪些欄位、要串哪些系統，範圍自然就收斂了。
這樣做的好處，是報價會落在一個可控的區間。反過來說，如果你堅持要「先把所有數據都整合起來，之後再想要看什麼」，多半會做成一個很貴、很慢、上線後沒人打開的資料湖。我們在報價時通常會建議客戶，第一階段只做能回答三個決策問題的最小整合，跑三個月看使用狀況再擴充。
資料整合要做到哪一層才有用
資料整合有幾種深度，成本差異很大，該做到哪一層要看你的決策頻率。
最淺的一層是「定期匯出報表」，各系統每天或每週把 CSV 丟到同一個地方，人工或簡單腳本合併。適合決策頻率是週或月的中小企業，成本低，但無法做即時判斷。
中間一層是「建一個共用的資料倉儲」，把各系統的資料以固定排程同步進來，欄位定義統一過。適合已經有多個通路、需要跨系統交叉分析的公司。這一層的隱藏成本不在建置，而在事後的「欄位對齊」——誰來決定退貨的認列時點、誰來維護客戶 ID 對照表，這通常需要一個懂業務又懂資料的窗口，不能全丟給工程師。
最深的一層是「即時串接與事件驅動」，訂單一成立就同步進分析系統，廣告出價可以根據當下庫存自動調整。這一層才會用到比較重的技術，成本也跟著跳一階，通常只有訂單量夠大、決策要求秒級反應的業態才划算。
多數傳統產業與中小型電商，其實停在中間那一層就足以支撐大部分決策，不需要一開始就追求即時。發案前先誠實評估：你的決策節奏到底是每天、每週還是每月？別為了用不到的即時性付出十倍成本。
我們的觀察
報表撈不出來，八成是資料定義沒對齊，不是工具不夠好。發案前先花時間把「你到底想回答哪三個問題」寫清楚，比先挑 BI 工具重要得多。整合的深度要對應決策的頻率，過度投資跟不敢投資一樣傷。真正能讓行銷不再靠感覺的，是有人願意把業務規則講清楚，然後守住這份定義。