企業導入 AI，第一關不是模型，而是散落在 Excel 裡的資料

談企業導入 AI，大家很容易先問：「要選哪個模型？要用 ChatGPT、Claude，還是自己架一套？」但我們這幾年跟企業交流後，常看到的第一個實際問題不是模型排行榜，而是更基礎、也更容易被忽略的事：公司資料到底在哪裡？誰知道它代表什麼？能不能以可信任的方式整理起來，讓不同部門和不同工具重複使用？

很多企業並不是沒有資料。相反地，資料多到每個部門都有自己的版本。ERP 裡有一份、POS 裡有一份、電商後台有一份，業務同事寄來的 Excel 又是一份；人資、客服、庫存、會計也各自維護熟悉的工作表。平常需要做報告時，大家會先把檔案找齊，再手動整理欄位、刪掉小計列、對照代碼、確認日期格式，最後才開始回答真正的業務問題。資料明明已經存在，卻要先花大量人力把它翻譯成機器看得懂、同事也能信任的樣子。

這種落差不只是我們在客戶現場看到的個案。Salesforce 的《State of Marketing》相關統計指出，84% 的受訪行銷人員使用第一方數據，但只有 31% 對跨來源資料整合能力感到完全滿意。這兩個比例放在一起看很有意思：企業逐漸知道自己的資料很重要，卻仍有不少團隊無法把各處資料整理成一致、可用的整體。1

PwC 2026 年對美國 767 位營運與供應鏈主管所做的調查，也呈現類似的現實。89% 的受訪者表示，科技投資尚未完全帶來原先期待的成果；87% 指出資料品質不佳影響了數位計畫創造價值的能力。這不是在說每家企業的數據都一團亂，而是提醒我們：如果把系統買進來、把 AI 帳號開通，卻沒有同步處理資料品質、系統銜接和工作流程，投入未必會自動變成成效。2

所以，去年我們開始把技能點投入一件看起來沒有那麼炫、但實際上很關鍵的工作：讓 AI 協助企業清理與整理資料。現在走過一年，產品逐步成熟，我們推出 AotterClam AI。這不是要再多做一個聊天視窗，而是希望幫企業把散在舊系統、報表與檔案裡的資料，整理成可以治理、可以更新，也能被後續 AI 和 BI 工具使用的資料基礎。

為什麼大家談 AI，最後卻常常先卡在 Excel？

我們電獺做數據相關工作十多年，熟悉資料工程與數據治理的日常。外界認識我們，可能是從電獺少女開始；但電獺一路從創作工具、內容產品，走進數據廣告、第一方資料應用，再到企業 AI，背後始終在處理同一類問題：怎麼縮短資訊變成價值的時間。當我們在媒體與廣告科技現場長期處理使用者行為資料，就會知道資料收進來只是開始。真正困難的是整理、定義、權限、用途，以及日後能不能繼續更新。10 11

第一方數據的討論，過去常出現在行銷和廣告領域，現在則愈來愈接近企業營運的核心。它不只是品牌直接蒐集到的會員或交易資料，也包括企業在合法、合理的業務關係中累積的訂單、庫存、客服互動與服務紀錄。這些資料能不能被掌握，關係到企業是否能在自己的營運情境裡建立分析能力，而不是每次都仰賴外部平台提供的概略答案。

這股趨勢也不是把「第一方」三個字貼上去就完成了。eMarketer 引述 2024 年的調查指出，在一項 B2B 行銷人員調查中，67% 把資料合規與準確性列為重要優先事項；另一項全球行銷人員調查則有 84% 表示會運用客戶、第一方及交易資料來理解受眾。這些數字反映的是特定調查對象和當時的市場情境，不代表每一家公司都已經具備成熟的資料治理能力；但它們清楚說明，企業開始同時在意資料能不能用，以及用的方式是否合規、是否準確。3

我們也想特別提醒，第一方資料不等於「自己拿到的資料就可以任意使用」。資料從何而來、蒐集時告知了什麼、允許拿來做哪些用途、誰可以看、保存多久、能不能與其他來源串接，都必須有清楚規範。真正有價值的第一方資料，是在合法與透明的關係中累積、能被組織持續管理的資料資產，而不是換個名稱繼續做過度蒐集或無限制追蹤。

而進入企業 AI 的情境後，資料瓶頸會以很務實的方式出現。很多公司使用的核心系統已經運作多年，ERP、POS、倉儲或訂單系統可能各自有自己的資料庫，但系統之間沒有適合的 API，或是 API 雖存在，企業卻沒有預算、權限或專人把它接好。實務上，現場最常用的對外出口仍是 Excel 或 CSV：每週匯出一份銷售表、每天寄一封報表信，或在月底由同事把不同部門的工作表合併。

不應該因為資料以 Excel 形式交付，就把它當成沒有價值的資料。這些工作表往往承載著企業多年營運經驗，只是表格設計原本服務的是人，不是資料管線。第一列可能是合併儲存格的標題，第二列才是欄位名稱；同一欄裡有日期、文字和註記；一張工作表裡還混著明細、小計、合計與備註。不同部門甚至會用不同名稱指同一個欄位，或用同一個名稱表示不同概念。

例如「金額」可能是未稅金額、含稅金額、扣除折讓後的淨額，也可能只是尚未扣退款的訂單總額。表格看起來都叫金額，拿來相加卻會得到完全不同的營運結論。又例如，一列資料可能代表一張訂單，也可能代表一張訂單中的一個商品品項。如果系統不知道資料的粒度，就把訂單總額複製到每個商品列，總營收很容易被重複計算。這些不是 AI 靈不靈光的小問題，而是商業定義沒有被寫清楚時，任何報表或模型都可能出錯的根源。

我們從去年起接觸許多 Generative BI、data lakehouse 與 semantic layer 解決方案。這些工具能協助企業查詢、分析和呈現資料，但多數使用情境通常假設資料已經過整理，並放進可分析的資料庫或資料倉儲。換句話說，它們很擅長處理「已經準備好的資料」，不一定會替企業解決最前面的資料盤點、欄位清理、規則定義、關聯建立和排程更新。

這就是企業常見的導入順序問題：大家急著看見 AI 問答，卻還沒先把資料準備好。現場資料分散在系統、附件和不同版本的試算表中，導入專案便得先花時間找資料、問人、確認欄位，再設法把它們放進同一個可分析環境。傳統作法多半需要顧問與系統整合團隊逐案盤點，投入數週甚至更長時間，才可能建立第一版可供分析的資料倉儲。這不代表顧問或 SI 沒有價值，而是企業常常需要先完成一段費時的資料工程，才能開始討論 AI 能替業務做什麼。

台灣在地調查也讓這個問題更具體。資策會數位轉型研究院與人工智慧科技基金會的 2025 年製造業 AI 普及度調查，將傳統製造業與資通訊科技業分開觀察。報告指出，傳統製造業受訪樣本中，35.8% 導入 ERP 或 MES 等資訊系統，跨系統 API 整合比例為 13.2%；傳統製造業進入 AI 導入驗證或規模化階段的比例為 22.7%，也低於資通訊科技業的 39.1%。這份研究的樣本規模有限，分組樣本各為 53 家傳統製造業與 74 家資通訊科技業，因此不應直接推論成整個台灣產業的精確普查結果；但它很清楚呈現出一種結構性落差：有系統，不代表系統彼此打得通；有資料，也不等於資料已經能支撐 AI。4

當企業找我們討論資料清理時，常聽到的答案是：「先找人把資料抽出來，做 ETL，整理好再入倉。」ETL 指的是擷取、轉換和載入資料的流程，本來就是資料工程的重要工作。然而，如果每一種報表都要從頭客製一套處理程式，資料格式一改就需要重修，後續換人也得重新理解過往規則，導入成本就很難降低。企業所需要的不是假裝資料清理很簡單，而是把大量重複、可描述、可驗證的步驟，整理成能被重用的規則。

因此，我們開始問一個看似很簡單的問題：Excel 格式千變萬化，是否仍有一些穩定的資料處理原子，可以被明確描述？一份表要怎麼讀、哪些列該排除、欄位要轉成什麼型別、如何判斷一筆紀錄、如何與另一張表建立關聯，以及新檔進來後要怎麼更新。這些工作當然不會因為加上 AI 就自然變得毫無風險，但它們可以被拆成定義、規則、驗證和執行，而不是每次都只依賴某位同事記得「以前大概是這樣做」。

經過數月研究，我們把資料科學與資料工程中反覆出現的處理方式，整理成一套宣告式語法。所謂宣告式，是把目標與規則清楚寫出來，例如「這欄代表訂單日期」「小計列不要進明細」「以訂單編號與品項編號識別一筆資料」「金額以扣除折讓後的淨額計算」，而不是只留下一段難以接手的手工流程。AI 可以先分析沒看過的 Excel，提出欄位、格式和關聯的初步理解；接著由熟悉業務的人檢查和修正，把核定後的定義保存下來，再交給固定流程處理之後的檔案。

資料進來也不必只靠同事手動上傳。如果企業原有 ERP 能定期匯出報表，可以沿用既有排程寄送 Excel 或 CSV；如果系統有 API，也可以直接串接。匯出檔到達後，系統再依核定定義清理、驗證、更新和入倉。以 AotterClam AI 官方產品說明為例，目前列出 Excel 與 CSV 檔案匯入、API 與排程同步，以及以報表郵件附件自動處理等方式；實際可用的來源、格式和部署方式，仍要依企業環境逐案確認。5

這個設計思路的重點，不是讓 AI 永遠代替人判斷，而是把 AI 最適合的工作放在「協助理解未整理資料、提出候選規則」的位置；把業務確認放在「判斷欄位與指標的意思」的位置；再把固定規則交給可重現的資料流程去執行。這樣做，資料工程不會因為每次匯入都要重新呼叫模型、重新猜一次而失去穩定性，業務人員也不必在每次查詢時重新講解整張表的背景。