Odoo ERP 導入指南：中小製造業評估前該弄對的順序
先給結論：評估 Odoo ERP 之前，順序比選型重要
要不要導入 Odoo ERP，這個問題現在還不用回答。先把三個順序弄對：第一，盤流程，做出一張屬於你自己的斷點清單；第二，才選系統，比的是誰維運、在地化怎麼來、升級誰負責；第三，最後才談 AI 與補助。我們做的那一段不綁 ERP 品牌，Odoo 在這篇是被評估的對象。
這篇會給你三樣可以帶走的產出：
- 一張你自己做得出來的斷點清單，拿去問任何一家導入商都問得下去。
- 一張社群版與企業版的判斷表，把「廠商說有支援」變成「我逐項確認過」。
- 一套第一週就要定下來的驗收指標，讓你事後量得出來有沒有變。
三個順序：先盤流程、再選系統、最後才談 AI 與補助
導入失敗常見的起點，是還沒看清楚自己的流程就開始選型。文件裡的 SOP 常常只是理想流程，真實流程藏在私人 Excel、LINE 群組與沒寫下來的口頭交接裡。順序顛倒的代價是：你用一張看不清楚的需求清單去比價，比到最後只能比價格，然後在上線第三個月才發現系統不合身。
這篇不教你為什麼要選 Odoo，而是教你怎麼判斷
Odoo 是一套企業管理軟體，依 Odoo 官方版本比較頁（2026-10-25 查證）分成開源的社群版與授權制的企業版；依 Odoo 官方的標準支援說明（2026-10-25 查證），目前最新的主要版本是 2026 年 9 月發行的 20.0。以上都是查得到的事實。判斷要你自己做，而且要在看過自己的流程之後做。
誰適合往下讀：正在評估 Odoo、或想換掉用了十年的舊 ERP
你是製造業老闆、廠務或資訊主管，手上有一套用很久的系統或一堆 Excel，最近被人推了幾份 Odoo 簡報。這篇建議你先把簡報放下，看自己的工廠。
第一步：先盤流程，再選系統（斷點清單怎麼做）
盤點一天就夠，前提是方法要對。我們的做法是請每天在跑那段流程的人，用三欄描述自己的工作，再把各部門的表貼上同一面牆接起來。
為什麼不要問「你的痛點是什麼」
因為沒有人答得出來。每天在做的事情對當事人來說是「本來就這樣」，痛感早就麻掉了。問痛點會得到兩種答案：一種是抱怨別的部門，一種是沉默。換個問法，問他東西從哪裡來、照什麼做、做完往哪裡去，每個人都答得出來，而且答得很細。
三欄盤點法：Input 投入從哪來、Process 處理照什麼做、Output 產出往哪去
三欄分別是 Input 投入、Process 處理、Output 產出（公司內部常把 IPO 當成內控循環的用語，這裡指的是這三欄）。每一欄要問的問題固定下來，才比得起來。
| 欄位 | 要問的三題 | 常見回答長相 | 要拍到的證據 |
|---|---|---|---|
| Input 投入 | 誰給你、用什麼形式給、多久給一次 | 業務用 LINE 傳圖、附一句口頭補充 | LINE 對話截圖、紙本簽收本 |
| Process 處理 | 照什麼規則做、規則寫在哪、例外怎麼處理 | 照經驗做，規則只寫在一份私人 Excel 裡 | 那份 Excel 的實際畫面 |
| Output 產出 | 交給誰、交什麼、對方拿去做什麼 | 印出來放在生管桌上 | 現場那疊紙、白板上的字 |
以少量多樣製造為例，一條常見的主線是：客戶需求進來、業務與工程確認規格、建立客製 BOM、現場多人報工、部分製程外發分批回廠、最後分批出貨。BOM 是物料清單，依 Odoo 19.0 官方 BoM 文件（2026-10-25 查證），它記錄生產或修理一項產品所需的元件與數量，常常也包含生產作業與步驟說明；它的上游與下游，可以在製造業名詞地圖的 BOM 卡查到。這條主線上的每一個交接點，都可能是斷點。
各部門貼同一面牆：對不起來的地方就是斷點，紙本與白板就是系統斷掉的地方
上一站的產出和下一站的投入對不起來，那裡就是一個斷點。紙本和白板出現的地方，就是系統斷掉的地方：紙上記的，通常是系統沒有欄位、或流程跟不上現場的那一段。
斷點的四種長相：形式斷、內容斷、時間斷、對象斷
把斷點分類，後面談系統範圍才有共同語言。
- 形式斷是上一站給的是紙本或口頭，下一站要的是系統單據，中間靠人重新打一次。
- 內容斷是下一站需要的欄位，上一站根本沒給，所以每次都要回頭問。
- 時間斷是東西已經動了，單子過幾天才補進系統，帳上庫存和現場永遠對不起來。
- 對象斷是流程上寫交給 A，實際上大家都直接找 B，因為處理需要的資料或權限沒有跟著流程交給 A。
證據位階：現場實見 ＞ 訪談 ＞ 客戶自填
這個位階我們寫死，一定要照這個順序採信。自填是「應該的樣子」，訪談是「記得的樣子」，現場實見才是「實際的樣子」。這三者之間的落差就是導入時最容易被漏掉的需求。所以盤點那天一定要走進現場，看人怎麼拿單、怎麼問、怎麼補。
一天盤完的產出：一張屬於你的斷點清單，拿去問任何一家導入商
盤點當天的執行順序是固定的。
- 找出每天真的在跑這段流程的人：經手的那幾位，不必找主管。
- 各自填三欄：一個人一張紙，寫自己的 Input 投入、Process 處理、Output 產出。
- 貼上同一面牆：按流程由前到後排，讓所有人都看得到全貌。
- 對接上下站：上一站的產出對下一站的投入，對不起來就用紅筆圈起來。
- 標斷點型態：每個紅圈標成形式斷、內容斷、時間斷或對象斷。
- 輸出清單：當場填完欄位，散會前印出來。
清單的欄位長這樣：編號、位置（哪兩站之間）、斷點型態、多久發生一次、一次多久、幾個人、象限（影響度乘導入速度，由參與的人自己標）、證據位置。問不到的格子就標「待驗證」，不要替自己補數字。這張清單不出總分、不排名，一天的盤點撐不起加權評分。想看報工現場怎麼量，可以參考報工即時掌握進度與成本的做法。
第二步：選系統前先搞懂 Odoo 社群版、企業版與成本結構
版本差異要看的是責任歸屬。
社群版與企業版怎麼選：看誰維運、在地化怎麼來、升級誰負責、換廠商難不難
依 Odoo 官方版本比較頁（2026-10-25 查證），企業版包含官方功能支援、版本升級與託管，社群版則不含這幾項。下表把中小製造業真正在問的四件事排開。
| 判斷面向 | Odoo 社群版 | Odoo 企業版 |
|---|---|---|
| 誰維運 | 自行架設、自己或委外廠商維運 | 官方託管的 Odoo Online；依定價頁，要自架或用 Odoo.sh 得選 Custom 方案 |
| 在地化怎麼來 | 自行安裝設定在地化模組 | 官方在地化模組隨方案提供 |
| 版本升級誰負責 | 自己處理，官方版本升級不含在內 | 官方版本升級包含在內 |
| 官方支援 | 不含官方功能支援 | 含不限次數的官方功能支援 |
| 換導入商難不難 | 原始碼與資料庫在手上，換人可行但要交接文件 | 授權在官方、導入實作在夥伴，兩件事要分開談 |
| 適合哪種公司 | 內部有人能維護、想先驗證流程 | 要官方升級與支援、不想養維運人力 |
社群版與企業版共用同一套核心，這件事對中小製造業的意義很實際。
「Odoo Community is the core upon which Odoo Enterprise is built - and you can switch versions at any time.」
先用社群版把斷點清單裡最痛的那一段跑起來、驗證流程對不對，之後再決定要不要換到企業版，是一條走得通的路徑。反過來從企業版退回社群版，要付出的力氣大得多。
Odoo 的版本節奏：每年秋天一個大版本，標準支援三年
依官方的標準支援說明（2026-10-25 查證），近幾個主要版本都在 9 月到 11 月之間發行，每個主要版本的標準支援涵蓋發行後的前三年，Odoo Online、Odoo.sh 與自架都適用，安全性更新只在這段期間提供。現在導入 19.0，標準支援預計到 2028 年 9 月；導入 20.0，預計到 2029 年 9 月；17.0 的標準支援已在 2026 年 9 月結束。
Odoo 17.0 發行
Odoo 18.0 發行
Odoo 19.0 發行
同月 16.0 的標準支援結束
Odoo 20.0 發行
同月 17.0 的標準支援結束
18.0 標準支援預計結束
19.0 標準支援預計結束
20.0 標準支援預計結束
資料來源：Odoo 標準支援和延伸支援說明
對照這張時程，評估時要先確認升級由誰負責：
- 標準支援結束後的延伸支援要另外付費，只能用在 Odoo.sh 的部分版本與自架。
- 依定價頁，Odoo Online 會定期升級；支援說明也寫到，雲端版每兩到三個月就有一個 SaaS 版本，而且不適用延伸支援。客製的報表與流程，要跟著每一次升級做回歸測試。
- 自架要自己排大版本升級，社群版沒有官方升級服務；依 Odoo 20.0 安裝文件（2026-10-25 查證），20 版把 PostgreSQL 的最低需求從 13 提高到 16，資料庫要一起升。
- 企業版的升級含在方案裡，客製程式的維護不含，定價頁把這兩件事分開寫；支援說明也寫明，可以升級到仍在標準支援、或結束標準支援未滿六個月的主要版本。
所以簽約前要問清楚：導入商要上的是哪一個主要版本、標準支援還剩多久；大版本升級時，客製模組由哪一方修改與測試，費用怎麼算。
Odoo 價格怎麼算：授權、導入、客製、維運四筆要分開看
依我們做案子的經驗，授權費通常是四筆裡最小的一筆。Odoo 官方定價頁（2026-10-25 查證）把方案分為 One App Free、Standard 與 Custom 三種，Standard 與 Custom 都是全模組單一費率、按使用者人數計，IAP 點數（應用內購買的點數，AI 用量也從這裡扣）另計。這篇不寫金額，實際費率依年繳或月繳、地區與當時公告而不同，以官方定價頁為準。
真正的成本在另外三筆：導入顧問與流程盤點、客製開發、上線後的維運與教育訓練，再加上換導入商或換系統時的退出成本。定價頁有標價的只有授權，其他幾筆都要拿斷點清單去問。
| 費用 | 定價頁寫了什麼（2026-10-25 查證） | 拿什麼去問 |
|---|---|---|
| 授權 | 全模組單一費率、按使用者人數計，另有輕量使用者一級 | 後台開單、輕量使用者帳號、只有人資紀錄，三種人數分開列 |
| 導入 | 導入服務不含在方案內；小公司通常直接找 Odoo，中大型公司通常找在地合作夥伴 | 斷點清單，加上最想先上的那一段 |
| 客製 | 客製模組要放在 Odoo.sh 或自架，得選 Custom 方案；Odoo.sh 主機費另計 | 斷點清單裡確認刪不掉、非客製不可的那幾段 |
| 維運 | 方案含支援、託管與升級，客製程式的維護不含 | 大版本升級時，客製模組由哪一方修改與測試 |
| 退出 | 用 Odoo Online 的話，資料庫備份可以隨時從控制中心下載 | 原始碼、資料與交接文件在誰手上，匯出是什麼格式 |
先有斷點清單再去問報價，你才問得出真實範圍；只拿一句「我要導 ERP」去問，每家報的都是不同的東西。ERP 比較那篇的判準二把退出成本寫成簽約前要問的五題，各家系統的公開牌價在同一篇的判準四。
授權那一筆還有一個變數：有幾件事會把方案從 Standard 推到 Custom，評估時先對一次自己要不要做。
| 你想做的事 | 方案會怎麼變 | 出處（2026-10-25 查證） |
|---|---|---|
| 裝 Odoo Studio，自己改欄位與畫面 | 自動切換到 Custom | 定價頁 |
| 一個資料庫管好幾家公司 | 自動切換到 Custom | 定價頁 |
| 讓舊系統或報表工具主動呼叫 Odoo 的 API | 外部 API 列在 Custom | 定價頁 |
| 自己架主機、用 Odoo.sh 或裝客製模組 | Standard 只放在 Odoo Online，要選 Custom | 定價頁 |
| 在 Standard 的資料庫裝 AI App | 自動觸發升級到 Custom | 20.0 AI 文件 |
現場人員也要算授權嗎：輕量使用者與人資裡的員工紀錄
用 Standard 或 Custom 方案就要算，但有輕量使用者這一級可以談。依 Odoo 官方定價頁（2026-10-25 查證），付費使用者有兩種：能進後台建立、查看或編輯單據的人，以及人資 App 裡沒有連到使用者帳號的員工紀錄；用入口網站看單據的客戶與供應商不算。
輕量使用者（Light User）是付費使用者裡的另一級，有兩種人會落在這裡：軟體裡被設成輕量使用者的帳號，可以請假、報支、看出勤與排班、做庫存條碼作業；人資 App 裡沒有連到使用者帳號的在職員工紀錄，可以領薪資單、用 POS 與製造的工作站（Shop floor）。要用這一級，得跟 Odoo 顧問約時間、依需求報價。
所以問報價時，把人數分成三種列：會登入後台開單的人、用輕量使用者帳號掃條碼或請假報支的人、沒有帳號只在人資有紀錄的人（只用製造工作站報工、不進後台的人可以放在這一種）。少了後兩種，報價就沒算到他們。
開源 ERP 的真正價值：原始碼與資料庫在你手上，但要有人會改才算數
開源 ERP 的價值寫在授權條款裡：社群版採 LGPL-3，依 iT 邦幫忙的 Odoo 基礎介紹（2026-10-25 查證），這套授權搭配 Odoo 的繼承框架，讓開發者做彈性客製時不必擔心自製模組被強制開源。資料庫用 PostgreSQL，資料模型是開放的。但這些自由要有人真的會改才兌現得了。沒人會改，原始碼在手上跟不在手上沒有差別。
什麼情況 Odoo 不是好選擇
這幾種情況我們會直接說先不要。
- 多廠區、多幣別、高頻交易且流程已高度標準化的集團：現有大型 ERP 撐得住就不要動，改善的力氣放在跨系統的資料串接上。
- 法遵與稽核要求極重、需要原廠背書與稽核軌跡認證的產業：先確認認證要求，再回頭看哪一類系統符合。
- 公司內部完全沒有人能維護、也不打算培養：開源的價值對這種組織等於零，改採全託管方案並把維運責任寫進合約。
- 只想買一套「上線就好」、不打算改任何流程：換什麼系統結果都一樣，先處理願不願意改流程這件事。
還有一種是「先不要換系統」：舊 ERP 的財會與主檔還可靠、痛點在跨部門交接。這種情況先疊一層編排，換系統的事一年後再說。
客製化之前，先問這段流程該不該存在
Odoo 的模組化架構容易讓人看到一張 Excel 就想「幫我把這個自動化」。我們給每一條痛點的施工順序是固定的，一步做完才准做下一步。
- 質疑需求
這件事為什麼存在，誰在用，不做會怎樣 - 刪掉環節
確認刪不掉，才有資格往下走 - 簡化
把留下來的步驟減少欄位與關卡 - 加快週轉
縮短等待與交接的時間 - 最後才自動化
確定形狀不會再變，才寫進系統
固定施工順序：質疑需求 → 刪掉 → 簡化 → 加快週轉 → 最後才自動化
這個順序防的是最常見的錯：先花錢客製了一段流程，做完才發現那張表之所以存在，只因為兩個部門各有一套「業績」的定義。該做的是把定義對齊，然後把表刪掉。自動化一個本來就不該存在的動作，只會讓它跑得更快、更難拿掉。
「通用需求用標準模組、核心製程才客製」這句話前面還少一步
這句話本身沒錯：進銷存、會計、人資這類通用需求交給標準模組，BOM 結構、委外流程、報價邏輯這些跟競爭力有關的環節才值得客製。但在它前面還要加一步：客製之前，先確認那段流程刪不掉。少了這一步，你會把預算花在保存現狀上。從需求出發的取捨脈絡，可以再看從自動化到智動化的規劃路徑。
刪掉的每個環節都要留下理由並由老闆簽認
刪掉的每一個環節，都要留下「為什麼可以不要」的證據，並由老闆簽認。沒有簽認，你們離開會議室之後它會長回來：某個月底有人覺得不放心，又把那張表印出來，三個月後它變回慣例。
已經有舊 ERP 怎麼辦：疊在上面，不取代
如果你已經有一套用了十年的 ERP，先別急著換。
換系統以年計，罩一層以週計
| 比較面向 | 直接換 ERP | 在既有系統上加一層編排 |
|---|---|---|
| 決策週期 | 以年計，要動到全公司 | 以週計，從一段流程開始 |
| 風險 | 全面性，帳務與出貨一起賭 | 局部，限縮在這段流程 |
| 對現場的干擾 | 大，所有人同時換工具 | 小，現場作業先維持原樣 |
| 失敗時的退路 | 回不去，資料已經搬走 | 停掉這一層，舊系統照跑 |
| 什麼情況選它 | 舊系統的財會與主檔已經不可靠 | 財會與主檔還可靠，痛點集中在跨部門交接 |
這張表是我們做案子累積的經驗判斷，手上沒有統計數字。
影子 Excel 是一級資料來源，接進來而不是消滅它
那些私人 Excel 是補丁，補的是系統沒做到的事。要求大家放棄它，換來的是兩套帳並行；把它接進來，你才拿得到現場真實的計算規則。影子 Excel 有哪四種、各補了什麼缺口，〈ERP 缺點與限制〉的影子 Excel 為什麼會長出來那一節有對照表。
系統先長得像現況，再改善現況；系統適應公司，不是公司適應系統
第一版要讓使用者一眼認得出來那是他的工作。認得出來才會用，用了你才有資料，有資料才談得上改善。
這一層吃進去什麼、交出來什麼
技術細節不用寫進評估文件，但這一層吃進去什麼、交出來什麼要講清楚。
- 吃進去的是舊 ERP 的匯出檔、各部門的 Excel、現場的人工紀錄，以及盤點時的訪談。
- 交出來的是照規則算完、寫回原系統的結果，不要求現場改用新畫面。
- 交出來的還有跨部門泳道流程圖，讓每個站點的責任看得見。
- 加上一份缺口與痛點清單，對應到前面那張斷點清單的編號。
- 最後是一份 AI 能直接開工的規格：哪張表、哪些欄位、什麼規則。
這一層的完整定義、一條報價流程的六步與 AI 的界線，寫在ERP 流程編排是什麼。
為什麼 Odoo 適合當這一層底座：逐模組上、資料模型開放
依 Odoo 官方定價頁（2026-10-25 查證），從單一應用的免費方案升級，做法是把需要的應用一個一個裝上去；依 Odoo 20.0 安裝文件，資料庫用的是 PostgreSQL。對已經有舊系統的公司，這代表你可以只上一個模組、只接一段流程，讓它跟舊 ERP 並存，不必一次全換。要讓舊系統主動呼叫 Odoo 的 API 查詢或更新資料，定價頁把它算成外部 API、列在 Custom 方案，評估時要一起算進去。
Odoo 的模組是一個一個裝的。來源：demo.odoo.com 線上示範環境，2026-10-23 截圖；示範環境已預先安裝多數模組。
導入第一週：先定指標，不是先定模組
進場第一週要做的是跟老闆一起定三個營運指標與它們現在的基線值，模組先不用決定。事後補的指標不算數。
跟老闆一起定三個營運指標與基線值（插單重排時間、月底關帳天數、報價工時）
能當驗收指標的，是現場跟老闆都看得到、事後量得出變化的營運數字。
| 指標 | 量的是什麼 | 能不能當驗收指標 |
|---|---|---|
| 插單重排時間 | 插單進來到排程重新排好要多久 | 可以 |
| 月底關帳天數 | 月底到帳關好要幾天 | 可以 |
| 報價工時 | 做一份報價實際花掉多少工時 | 可以 |
| 報價週期 | 從收到詢價到報價寄出要幾天 | 可以 |
| 訂單交期達成率 | 準時出貨的訂單占全部訂單的比例 | 可以 |
| 缺料停線次數 | 因為缺料停線幾次，現場自己就有感覺 | 可以 |
| 急件運費 | 為了趕交期多付的運費，錢的數字最難辯解 | 可以 |
| 庫存週轉天數 | 庫存多久轉一輪，看得出資金有沒有鬆開 | 可以 |
| 系統登入率 | 多少人登入，登入不等於流程變了 | 不該 |
| 報表數量 | 做了幾張報表，報表多只代表做得多 | 不該 |
| 模組上線數 | 上了幾個模組，量的是專案進度 | 不該 |
| 工時填報率 | 多少人填了工時，填報率高可能只是被逼著填 | 不該 |
標成「不該」的四個量的是活動量，拿來驗收只會逼大家做樣子。
第七天要有一個跑得動、跟你自己資料有關的畫面
第一週的節奏是這樣：
- 第一天定三個指標與基線：老闆在場，當場記下現在的數字。
- 第二到第六天接一條最短的資料路徑：從斷點清單裡挑最痛的那一段，只接這一段。
- 第七天交出一個跑得動的畫面：用使用者自己的資料，再爛都要有。
- 之後每週量同樣那三個數字：同一個定義、同一個算法，持續追蹤有沒有變。
一個只有一百筆髒資料的畫面，勝過第三十天才給的完美系統。資料沒清好，不能當延期的理由。界線要說明白：會影響金額與法遵的主檔（客戶、供應商、料號、會計科目、稅率）仍要先對齊，其他髒資料一邊跑一邊清。
交付的定義是三個數字變了，不是系統上線了
我們只把成效寫成觀測：定義三個基線指標、事後量它們有沒有變。變多少、往哪個方向變，要看實際跑出來的資料。
我們不接的兩種案子，以及為什麼
合約只寫「模組上線」、不寫營運指標的案子，我們不接；沒有高層拍板的案子，我們也不接。理由是：沒有人有權改流程，做的一切都會被組織排斥；合約不寫營運指標，我們就證明不了價值。
Odoo 19 的 AI 功能怎麼看：AI 做粗活，人做判斷
Odoo 19 把 AI 助理與代理放進了系統，20 版又把代理能做的事往前推了一步。評估時先看它被允許做什麼。
Odoo 20 的 AI 代理：指派了技能才寫得了資料，可被排程觸發，也能接外部代理
Odoo 20.0 的 AI、AI agents 與 AI MCP server 三份文件（2026-10-25 查證）寫到、跟評估直接相關的有四件事：
- 19.0 叫 Topics 的那一層，20.0 改名為技能（Skills）；沒有指派技能的代理只能提供資訊，不能完成任務，也不能變更資料庫。AI App 預先設定的技能包含更新紀錄（Update Records）與建立紀錄（Create Records），代理有沒有寫資料的能力，看它被指派了哪些技能。
- 代理可以由自動化動作與定時執行的排程動作觸發，不一定要有人在對話框下指令。
- 外部的 AI 代理可以經 Odoo 的 MCP 伺服器連進資料庫，讀取或修改資料。
- AI 用量扣 IAP 點數；Standard 方案的資料庫裝了 AI App，會自動觸發升級到 Custom 方案。
代理一旦被指派了能寫資料的技能，又能被定時排程叫起來，誰做什麼、哪些動作要人確認，就得在上線前寫清楚。
AI 負責不會漏，人負責不會錯
| 任務類型 | 誰做 | 舉例場景 | 會不會影響金額 | 生效要不要人確認 |
|---|---|---|---|---|
| 窮舉 | AI | 把散在信件與會議紀錄的需求列成待確認清單 | 否 | 要，看過才用、不直接送出 |
| 格式化 | AI | 把非結構化的規格描述整理成固定欄位 | 否 | 要，看過才用、不直接送出 |
| 初稿 | AI | 產出異常摘要或回覆草稿 | 否 | 要，看過才用、不直接送出 |
| 真偽 | 人 | 判斷這筆規格是不是客戶真的要的 | 可能 | 要，由有權限的人簽核 |
| 合併 | 人 | 決定兩筆相似需求要不要併成一張單 | 可能 | 要，由有權限的人簽核 |
| 定案 | 人 | 報價金額、成本、應收帳款 | 是 | 要，由有權限的人簽核 |
會影響金額的計算一律走規則算，AI 只提建議、生效要經人確認
這條界線沒有例外。報價、成本、應收帳款走規則算，AI 可以提建議，生效前要經人確認。理由在 Odoo 自己的文件裡就寫得很清楚。
「An AI agent is a smart assistant in Odoo that can understand natural language, perform tasks, and assist users by interacting with Odoo tools.」
重點落在「執行任務」這四個字。能執行任務，就需要事先列舉允許的動作與稽核紀錄。這句定義出自 19.0 文件，20.0 文件的同一句只多了 virtual 一個字，20 版一樣適用。依 Odoo 19.0 AI 文件（2026-10-25 查證），19.0 標準的 Ask AI 代理不能變更資料庫；代理能不能寫資料，19.0 與 20.0 的文件都寫成看它被指派了哪些 Topics 或技能。這代表權限範圍要自己設計，預設不等於安全。功能依版本、方案與 AI 點數而異，以官方文件為準。
AI 代理只接有定義的資料模型與白名單動作，每步留稽核紀錄
代理接的應該是你定義過的資料模型，加上一份列舉清楚的動作清單，不要讓它直接碰裸資料庫。每一步留稽核紀錄，出事才追得回去是誰、在哪一步、依據什麼做了什麼。
Odoo 自己的 MCP 伺服器也是這樣設計的。依 Odoo 20.0 的 AI MCP server 文件（2026-10-25 查證），資料庫預設只把取得欄位、取得模型、取得初始脈絡、搜尋與分組讀取這幾個查資料的工具開放給外部代理，其餘工具要有人手動開放才叫得動。
「The remaining tools are hidden from the client and must be manually exposed to be invoked.」
手動開放的做法，是在伺服器動作勾選「Available in MCP」。另一個勾選項「Readonly Tool」是標示這個工具不會寫入或修改資料，外部代理可以不經使用者同意直接呼叫，所以只該勾在真的只查資料的工具上。哪些工具勾了這兩項，都要寫進你的動作清單。
Odoo 20.0 說明文件 AI MCP server 頁的開放工具一節：預設開放的查資料工具，以及 Available in MCP 與 Readonly Tool 兩個勾選項。來源：Odoo 官方說明文件，2026-10-25 截圖。
動作清單實際長什麼樣、上線前還要補哪些護欄，可以對照〈ERP vibe coding 可以嗎〉整理的上線前的六條護欄。
評估時該問的三個問題：它讀哪一張表、動作經誰核准、錯了能不能追
把這三題丟給任何一家導入商。答不出來的，功能再炫也不要簽。這三題對應的是資料邊界、核決權限與事後追溯。套到 Odoo 20，三題都有對應的設定可以查：
- 「它讀哪一張表」要查代理被指派了哪些技能、技能裡的工具讀得到哪些模型；外部代理經 MCP 連線時，還要查它用的是哪個使用者的金鑰、那個帳號有哪些權限。
- 「動作經誰核准」要查哪些會寫資料的工具勾了 Available in MCP、是誰勾的，以及哪些工具勾了 Readonly Tool。
- 「錯了能不能追」要查每一步有沒有留下紀錄；每條連線都是一把 API 金鑰，金鑰設了多久到期、出事時由誰去刪，也要事先講好。
ERP 導入失敗的常見原因，與我們對應的做法
先看問題長什麼樣，再看做法。
| 常見原因 | 現場看起來長什麼樣 | 我們的做法 |
|---|---|---|
| SOP 與現場不符 | 系統照 SOP 設，上線當天現場卡死 | 三欄盤點加貼牆對接，以現場實見為準 |
| 一次全切換 | 全公司同一天換，出錯就回頭用 Excel | 從斷點清單挑一段先上，分段擴大 |
| 基礎資料髒 | 料號、期初庫存對不上，沒人信報表 | 影響金額與法遵的主檔先對齊，其他邊跑邊清 |
| 老闆不在場 | 跨部門爭議沒人裁決，流程改不動 | 高層拍板才接案，每週固定檢視三個指標 |
| 太晚發現不合身 | 專案中途追加客製，預算失控 | 先出斷點清單再談範圍與報價 |
SOP 只是理想流程，真實流程在 Excel、LINE 與沒寫下來的經驗和默契裡
這也是為什麼證據位階要寫死。會議室裡討論出來的流程，跟現場跑的流程往往差一段，而那一段通常就是導入後最先爆的地方。
一次全切換是豪賭；分段上線的切法
切法就照斷點清單：挑影響度高、導入速度快的那個象限先做，做完一段、讓使用者嚐到一次「這樣比較輕鬆」，再走下一段。
基礎資料不乾淨不是延期理由，但這兩類主檔要先對齊
影響金額的主檔（客戶、供應商、料號）與影響法遵的主檔（會計科目、稅率）要先對齊，其餘的一邊跑一邊清。這條界線講清楚，才不會被解讀成可以放任髒資料。
老闆只在簽約與驗收出現，流程就改不動
ERP 導入會重組跨部門的利益與作業邊界。沒有人有權裁決，爭議就會用「維持原狀」收場。
超支不是因為報價低，是因為太晚發現不合身
獨立顧問公司 Panorama Consulting 在〈Why ERP Projects Go Over Budget〉一文（2026-10-25 查證）整理了 8 項超支原因，第一項是把技術排在人前面。
「An ERP system impacts employees, business processes, and the overall company culture.」
先談人與流程，是因為系統改的就是人每天怎麼工作。第二項是缺少業務流程管理：沒弄清楚現在與未來的流程就選系統，這種不合身會換來大量又昂貴的客製。Panorama 發布 The 2026 ERP Report 的新聞稿（2026-10-25 查證）也提到，超出專案預算最常被提到的原因是追加的技術需求；同一份新聞稿引述 Panorama 客戶服務資深經理 Chris Devault 的話，組織常在專案後期才發現致命的不合身，於是轉向追加技術、擴大範圍與客製開發。先做盤點、先出斷點清單，就是把「發現不合身」這件事提早到還付得起代價的時候。
補助是槓桿，不是起點
補助可以壓低自付金額，但要做什麼還是得你自己決定。
順序：先有斷點清單與基線指標，再看哪個計畫對得上
- 先有斷點清單與三個基線指標，再去對當年度的計畫內容，不要反過來。
- 不要為了套一個補助去發明一個需求，那筆錢最後會變成維護負擔。
先盤流程再談補助的順序主張，在傳產數位轉型的三個採購判準有完整展開。
計畫年年變動，每次規劃前都要重查當年度公告
去年的版本不能拿來推估今年，每一次規劃都當成第一次查。當年度有哪些計畫、資格、金額與時程，整理在製造業 AI 補助總覽，總表表頭寫著查證日。
角色分工：申請文件潤謙可以協助撰寫，盤點結果與流程圖當佐證
申請文件潤謙可以協助撰寫，也可以由你自己或委任的單位處理，送件以你的公司具名。潤謙科技提供的是盤點結果、跨部門流程圖與指標基線，讓申請書裡的必要性說得出因果。核定後潤謙以資訊服務業者的身分做技術輔導與交付；輔導團三個階段（階段一 AI 診斷與輔導、階段二 AI 應用導入、階段三 研發轉型補助）裡，潤謙做階段二的 AI 工具交付，與階段三的申請文件協助撰寫、核定後的開發與導入，分工寫在申請與交付的分工。補助之間怎麼接、要不要照階段順序，看補助關係圖。
導入完成的定義：包含你自己能改
上線不等於完成，我們對完成的定義有三條。
- 第一週定的那三個營運指標有被持續量，而且量得出變化。
- 公司裡至少有一個人能獨立修改流程與設定，不必每次都找廠商。
- 文件、流程圖與規格留在你手上，換廠商不會變成從零開始。
公司裡至少要有一個人能獨立修改流程與設定
客戶自主是交付的一部分。做不到這一點，你買到的其實是一份長期外包合約。
教育訓練不是加購項目，是反黑箱的手段
訓練要教的是讓你們自己看得懂資料怎麼流、規則寫在哪、改了會影響誰。
把訪談與系統資料變成流程的數位分身
流程資料給你的是事實，業務脈絡給的是判斷標準；把訪談與 ERP 等系統資料放在一起，才做得出可以行動的判斷。我們用 Reefian 把這兩邊接成流程的數位分身，交出來的是泳道流程圖、SIPOC 表、缺口與痛點清單，以及 AI 能直接開工的開發脈絡包，拿來排專案範圍、交給開發端當規格。想再往下看一個具體的成本判斷情境，可以參考削價搶單的成本決策怎麼算。
不換 ERP 的兩個案例：報價與訂單履行
兩個案子都寫在潤謙的 ERP 流程編排服務頁上：報價那一案換掉的是原廠終止維護的報價系統；訂單履行那一案在既有 ERP 上加一層、ERP 不動。
| 案例 | 接手時的狀況 | 做了什麼 | 觀測到的變化 |
|---|---|---|---|
| 電子專業代工的報價 RFQ | 用了十年的報價系統原廠終止維護，從 BOM 前處理、上傳對映到六家通路回價比對全是手工 | 重寫一套報價系統，一條龍六步：BOM 匯入、欄位對映確認、RFQ 發出、回價匯入、定成本、加價簽核 | 一份參考報價從原本的至少兩週，縮短到一週內拿得到，目標是壓到一天；客戶提供的導入前後對照：連續三個月的整體營收提升 20% |
| 食品業的訂單履行 | 一張訂單能不能如期出貨，要同時看 ERP 裡的帳上庫存、Excel 裡的在途與效期，還有往返信件裡的客戶特殊條件 | 在既有 ERP 上蓋一層訂單履行的編排，庫存、在途、效期與客戶條件接進同一條流程，可用量依批號與效期即時算出來 | 一張訂單能不能如期出貨，從原本的七天縮短到兩天 |
通路回價單常見的原始長相：重複的頁首、空列、寫在同一格的品牌與型號、混用的單位與幣別。表中為範例資料，料號與數字皆為虛構。
兩個案子的金額、庫存與效期判斷全走規則，每一次調整都留稽核軌跡；表上的變化是個案的觀測。
再說一次立場：Odoo 是被評估的對象，不是結論
我們做的那一段不綁 ERP 品牌。這篇從頭到尾都在幫你建立判斷的順序，沒有要幫任何一套系統背書。
常見問題
Odoo 社群版和企業版差在哪？台灣中小製造業該選哪一個？
兩者差在誰維運、誰負責升級、在地化從哪來。依 Odoo 官方版本比較頁（2026-10-25 查證），企業版包含官方功能支援、版本升級與託管，社群版不含這幾項；官方也寫明社群版是企業版建構的核心，而且可以隨時切換版本。依官方定價頁，企業版的 Standard 方案只放在 Odoo Online，要自己架主機或用 Odoo.sh 得選 Custom 方案。判斷法很簡單：內部有人能維護、想先驗證流程，就先用社群版把斷點清單裡最痛的那一段跑起來；沒人維護、要官方升級與支援，就走企業版。功能清單以官方頁為準，評估當下逐項核對。
Odoo ERP 導入要花多少錢？費用由哪幾塊組成？
依我們做案子的經驗，授權費通常是四筆裡最小的一筆，真正的成本在導入、客製與維運，另外要算換人或換系統時的退出成本。依 Odoo 官方定價頁（2026-10-25 查證），方案分 One App Free、Standard 與 Custom 三種，Standard 與 Custom 都是全模組單一費率、按使用者人數計，另有輕量使用者一級要找 Odoo 顧問報價；Odoo.sh 主機費、導入服務、IAP 點數與客製程式的維護不含在方案內。裝 Studio、加公司、用外部 API、自架或用 Odoo.sh 都要 Custom 方案；依 20.0 AI 文件，Standard 方案的資料庫裝了 AI App 也會自動觸發升級到 Custom。實際費率依年繳或月繳、地區與當時公告不同，以官方定價頁為準。先有斷點清單再去問報價，你才問得出真實範圍。
已經有一套用很久的 ERP，該換成 Odoo 還是先疊一層在上面？
如果舊 ERP 的財會與主檔還可靠、痛點在跨部門交接，先疊一層編排，換系統的事一年後再說。換系統的決策週期以年計，疊一層以週計，這是我們做案子累積的經驗判斷，手上沒有統計數字。做法是把散在舊系統、Excel 與人工紀錄的資料撈出來、照規則算、寫回去；影子 Excel 當成一級資料來源接進來，不要要求人放棄它。等新的那一層比舊系統更完整，取代是自然發生的。
Odoo 19 的 AI 功能可以直接拿來報價和排程嗎？風險是什麼？
可以拿來做初稿與窮舉，不可以拿來決定金額。排程也照同一條界線：重排建議可以讓 AI 先列，排定由生管確認。2026 年 9 月發行的 20 版之後，這條界線更要先寫清楚。依 Odoo 20.0 的 AI、AI agents 與 AI MCP server 文件（2026-10-25 查證），AI App 預先設定的技能包含建立與更新紀錄，代理可以由自動化動作與定時執行的排程動作觸發，外部 AI 代理也能經 MCP 伺服器讀取或修改資料庫，預設只開放查資料的工具。所以要先談治理，再談功能：影響金額的計算一律走規則算，AI 只提建議、生效要經人確認；代理只接有定義的資料模型與動作清單，每步留稽核。評估時問三題：它讀哪一張表、動作經誰核准、錯了能不能追。功能依版本、方案與 AI 點數而異。
工廠現場只在工作站報工的人，也要算 Odoo 的使用者授權嗎？
用 Standard 或 Custom 方案就要算，但只在製造工作站報工、沒有後台帳號的人，可以落在輕量使用者這一級。依 Odoo 官方定價頁（2026-10-25 查證），人資 App 裡沒有連到有效使用者帳號的在職員工紀錄就算輕量使用者，可以領薪資單、用 POS 與製造的工作站（Shop floor）；被設成輕量使用者的帳號，可以請假、報支、看出勤與排班、做庫存條碼作業。這一級要跟 Odoo 顧問約時間、依需求報價。問報價時把後台開單、輕量使用者帳號、只有人資紀錄三種人數分開列，報價才算得到他們。
下一步
不論最後換成 Odoo，還是留在舊 ERP 上疊一層，最容易卡住的都是那張斷點清單的第一格：不知道該找誰、從哪一段流程開始貼牆。潤謙科技可以陪你走完一張真實訂單，把各部門的說法對到現場實見，整理成有編號、有證據位置的斷點清單，再跟你一起把三個營運指標的基線值定下來。想從你工廠的哪一段開始，跟我們約個時間談。