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