企業談 AI 導入時，常把問題歸咎於系統太舊。
ERP 已經用了十多年、資料散落在 Excel、表單仍靠 Email 傳遞，部分流程甚至要詢問資深同仁才知道下一步怎麼做。於是，企業容易得到一個看似合理的結論：必須先把舊系統全部換掉，才能開始使用 AI。
但真正卡住 AI 的，往往不只是技術年代，而是企業的作業規則沒有被說清楚。
先說結論：舊系統導入 AI，不必一開始就全面汰換。更務實的做法，是先盤點資料來源、判斷規則、例外情況與責任分工，再從一項範圍清楚的流程開始結構化。AI 才有足夠的工作脈絡，企業也能逐步驗證結果。
哪些訂單需要優先處理？什麼情況要請主管確認？客戶資料不完整時應該找誰補件？同樣的異常，在不同廠區為什麼有不同處理方式？這些判斷可能藏在程式碼、試算表公式、Email 往返、紙本註記與個人經驗中。系統仍能運作，不代表企業已經清楚掌握它如何運作。
IBM 於 2026 年 5 月 27 日發布的舊程式移轉文章指出，老舊應用通常累積了多年形成的商業邏輯與工作流程；當文件不足、相依關係複雜時，整合與現代化就會變得困難。文章也強調，在移動程式碼或重寫系統之前，必須先盤點資料流、相依關係及內嵌的商業規則。 IBM：Legacy code migration
IBM 的文章主要討論程式與系統移轉；若把同一套盤點思維延伸到企業日常作業，也能看見類似問題：真正影響工作的規則，往往分散在 ERP、Excel、Email、人工表單與人員經驗中。
舊系統真正難搬的，不是畫面，而是判斷方式
企業若只比較新舊系統的欄位，很容易低估轉換難度。
例如，舊系統裡可能只有「交期」一個欄位，但實際作業時，業務會先看客戶重要性，生管再確認物料與產能，遇到急單還要透過通訊軟體詢問主管。
最後輸入的交期，看似只是一個日期，背後卻包含多個部門的判斷。
又或者，客服人員看到某類客訴時，會先查近三個月紀錄，再依產品批次決定要轉給品保或業務。這套方法未必寫在標準作業程序中，而是靠熟悉流程的人補足。
當企業直接要求 AI「判斷交期」或「處理客訴」，AI 取得的如果只有最後結果，卻沒有判斷依據、例外條件與責任分工，就很難產生穩定且可檢查的結果。
因此，AI 導入前的第一項工作，不一定是更換系統，而是把原本隱藏的規則找出來。
企業規則通常藏在五個地方
1. 系統欄位與程式邏輯
部分規則已經寫進 ERP 或客製系統，例如狀態轉換、計價公式、必填條件與權限限制。這些規則相對明確，但也可能因歷年修改而缺乏完整文件。
2. Excel 公式與個人維護的表格
許多部門會從正式系統匯出資料，再用自己的公式、顏色與篩選條件進行判斷。真正影響決策的邏輯，可能不在主系統，而在某位同仁維護的試算表中。
3. Email、通訊軟體與口頭確認
當系統流程無法涵蓋例外情境，人員就會在系統之外補充說明、詢問或核准。時間一久，「照慣例處理」成為規則，卻很難被新進人員或 AI 理解。
4. 紙本表單與簽核註記
紙本上的手寫備註、退回原因與附件要求，常反映正式流程沒有記錄的判斷依據。如果只把表單掃描存檔，而沒有整理欄位與狀態，這些經驗仍無法被後續流程使用。
5. 資深同仁的經驗
最關鍵的規則有時只存在人的記憶中。大家知道遇到問題要找某位同仁，但不知道他是依哪些資訊判斷。當人員調職或退休，企業失去的不只是操作能力，也包括多年累積的例外處理知識。
不要急著問「AI 能不能接」，先完成三張盤點表
要讓舊流程具備 AI 應用條件，可以先用三張簡單的盤點表，把問題從「系統太舊」拆成可處理的項目。
第一張：資料盤點表
列出每項工作需要哪些資料、目前存放在哪裡、由誰維護，以及資料是否完整。例如客戶主檔在 ERP、跟進紀錄在 Excel、附件在共用資料夾、補充說明在 Email。
盤點時不要只記錄資料表名稱，也要確認欄位定義是否一致。「完成日」究竟是作業完成、主管核准，還是通知客戶的日期？名稱相同但定義不同，會直接影響 AI 的判讀。
第二張：規則與例外表
把標準處理方式與例外情況分開記錄。除了「正常情況怎麼做」，也要問：哪些案件經常被退回？什麼資料不足時不能繼續？遇到衝突時由誰決定？
這張表的目的不是一次寫出完美的標準作業程序，而是先找出最常發生、最影響結果的判斷點。
第三張：責任與確認表
釐清誰負責輸入、誰可以修改、誰需要確認，以及完成後要通知誰。AI 可以協助整理、分類或提出建議，但涉及正式資料異動與重要決定時，仍需依企業權限與流程安排確認。
三張表完成後，企業才比較容易判斷：哪些資料可以直接使用、哪些需要先整理、哪些工作適合由 AI 輔助，以及哪些判斷應保留給人員。
現代化不一定是全面汰換，也可以先重建周邊流程
舊系統仍穩定支撐財務、生產或庫存時，全面汰換可能帶來高成本與營運風險。另一種方式，是保留仍然可靠的核心系統，先改善它周邊依賴人工與零散工具的工作。
例如：
將原本散落於 Email 的申請內容改為結構化表單。
將 Excel 追蹤表中的負責人、狀態與期限改為可共同更新的案件紀錄。
將紙本缺件檢查整理成明確欄位與確認流程。
將資深同仁常用的判斷依據整理成規則說明與例外處理方式。
先讓 AI 協助摘要、分類、檢查缺漏或提出下一步建議，再由人員確認。
IBM 也將「保留既有系統、在外層建立 API」列為舊系統現代化的一種方式，並建議採取分階段移轉，而不是一次搬動全部功能。這套做法未必適合每一家企業，但它說明了同一件事：現代化不只有全面重建一條路，也可以先保留可靠核心，再逐步改善可拆分的周邊流程。 IBM：Legacy code migration
換句話說，AI 可以協助加快整理與分析，但企業仍需提供可靠的資料結構、規則與責任界線。
niio 如何承接整理後的工作脈絡
當企業盤點出資料、規則與責任後，可依實際需求在 niio 建立表單欄位、狀態與流程，將原本分散在 Excel、Email 或紙本中的作業，逐步轉成可追蹤的工作紀錄。
依 niio 官網目前公開資訊，AI Action 可針對當筆資料帶入欄位與上下文，協助整理摘要、分析狀態、提出後續建議或產生草稿；AI Agent 則可在授權範圍內執行查詢、更新、彙總與 API 呼叫，涉及資料異動時可加入使用者確認機制。 niio AI 功能介紹
這不代表 niio 能自動理解所有舊系統，也不代表任何系統都能直接串接。若既有系統可提供 API、匯出檔案或其他可用的資料交換方式，才可進一步評估欄位對應與串接；若無法串接，也可以先從周邊流程、人工匯入或新建立的案件資料開始。
關鍵不是把舊系統的所有內容一次搬進新平台，而是選擇一段高頻、規則相對清楚、人工整理負擔高的流程，先建立可驗證的資料與處理方式。
比「換掉舊系統」更務實的五個步驟
選定一項具體工作，不以整個部門或整套系統為範圍。
盤點資料來源、欄位定義與目前維護者。
訪談實際執行人員，記錄標準規則與常見例外。
先將周邊流程結構化，再評估 AI 摘要、分類或建議。
穩定運作後，才評估與既有系統的資料交換或進一步自動化。
舊系統本身不一定是 AI 導入的最大障礙。真正的問題是，企業是否知道資料在哪裡、規則如何判斷、例外由誰處理，以及哪些結果需要人工確認。
先把這些工作脈絡整理清楚，即使核心系統暫時不更換，企業仍能從一小段流程開始，逐步建立可追蹤、可改善，也更適合 AI 協作的工作方式。
如果企業正評估舊系統導入 AI，可以先選一項高頻、規則相對清楚的工作，完成三張盤點表，再決定是否需要串接既有系統。進一步了解 niio 如何將表單、流程、權限與 AI 結合，可參考 niio AI 功能介紹 。
返回文章列表