客製化 OMS 訂單管理系統開發完整指南：6 個關鍵決策、3 個報價區間、5 個常見地雷

最近恆遠數位行銷在跟想客製化 OMS 的中小企業老闆對接時，最常被問同一句：「要花多少錢？」。我們的答案永遠是「先看清楚你要解的是哪一條斷裂」，而非直接給金額。蝦皮訂單進來、官網訂單進來、LINE 購物訂單進來，三個來源的庫存是不是同一個？退貨流程能不能反推進對帳系統？揀貨單跟物流托運單怎麼一鍵串起？這些問題答不清楚，任何報價都只是猜數字。這篇把整套採購邏輯拆給你看。

在展開細節之前，先把一個立場說清楚：OMS（Order Management System）的本質是「跨通路訂單的統一調度中樞」，它不處理財務總帳、不管生產排程、不追蹤倉位精度——那些分別是 ERP、MES、WMS 的領域。很多企業採購搞混邊界，導致規格書寫出「全功能系統」，最後每個系統都做得四不像。本文聚焦 OMS 這一層，並在適當位置指出哪裡需要跟其他系統串接。

什麼時候你需要 OMS（跟 WMS、ERP 的差別在這裡）

OMS 處理的是「訂單從進來到出貨的全流程調度」，包含：通路接單、庫存鎖定、揀貨指派、物流交接、退貨處理、金流對帳。它跟相鄰系統的邊界如下：

你需要 OMS 的三個明確訊號：① 同一個 SKU 在 2 個以上通路販售、② 出貨 SLA 在 24 小時以內、③ 每月退貨量超過 100 筆且退貨流程需要人工處理。三個訊號出現 2 個，就值得認真評估是買 SaaS 還是客製。

延伸閱讀：客製化 WMS 倉儲管理系統開發指南 和 客製化 ERP 系統開發攻略。

客製化 OMS 跟現成 SaaS（91APP / Cyberbiz / Shopify Plus）差在哪

市面上主流的電商 SaaS 平台都帶有基本的訂單管理功能，但設計邏輯是「以平台自身通路為中心」。一旦你需要跨平台整合，問題就開始浮現。以下是核心差異對比：

91APP 官方平台 提供 OMO 解決方案，但 API 開放程度有限，深度客製需要透過其 ISV 認證夥伴。91APP 官方網站的 OMS 模組適合以實體門市轉型 OMO 為主軸的品牌。

客製化電商系統跟 SaaS 的完整選型分析，可參考這篇：客製化電商系統 vs Shopify 選型指南。

客製化 OMS 的 6 個關鍵決策

這 6 個決策點是我們在系統開發案中反覆遇到的岔路口，每一個選錯，後期改動成本倍增。規格書沒有明確回答這 6 個問題，任何廠商報價都不算數。

這 6 個決策的複雜度組合，直接決定你在哪個報價區間。關於 ERP 串接的細節，可參考我們的客製化 ERP 開發指南。

3 個報價區間：你的 OMS 落在哪一段

OMS 的開發報價範圍很廣，從 50 萬到 1,200 萬以上都有，主要取決於上面 6 個決策的選擇。以下三個區間是我們在系統開發案中歸納的典型配置：

OMS 開發流程與時間表

一個完整的客製 OMS 專案通常分六個階段，每個階段有明確的交付物。以中型全通路（5-8 個月）為例：

關於如何撰寫 BRD，請參考：客製化系統需求書（BRD）完整寫法。

gantt
    title 客製化 OMS 開發時間表（中型全通路，約 6 個月）
    dateFormat  YYYY-MM-DD
    section 需求與規劃
    BRD 撰寫與審查          :a1, 2026-01-01, 21d
    PoC 技術驗證             :a2, after a1, 14d
    section 核心開發
    訂單核心 + 庫存模組      :b1, after a2, 42d
    通路串接（蝦皮/momo/官網）:b2, after a2, 35d
    section 金流物流串接
    金流串接 + 對帳模組      :c1, after b1, 21d
    物流串接 + 追蹤模組      :c2, after b1, 21d
    section 測試與上線
    串接 UAT + 壓力測試      :d1, after c1, 21d
    分批切換上線             :d2, after d1, 14d
    section 維運
    上線後穩定期監控         :e1, after d2, 30d

各階段重點說明：

• BRD 階段：釐清 6 個決策點、畫出訂單狀態機（State Machine）、定義異常處理規則。這個階段省掉的工，後面會加倍奉還。
• PoC 技術驗證：針對最高風險的 API（通常是蝦皮 OpenAPI 或 momo 對接）先做連通性驗證，避免到開發中期才發現 API 文件跟實際行為不一致。
• 核心開發：訂單狀態機 + 庫存鎖定邏輯是最複雜的部分，建議先做完再啟動通路串接，避免依賴未穩定的核心模組。
• 串接測試（UAT）：所有通路的訂單情境都要跑過，包含：超賣情境、部分出貨、退貨退款、物流異常。這個階段最容易被壓縮時間，卻是最不能省的。
• 分批上線：建議先切一個非主力通路測試，穩定一週後再切主力通路。全部同時切換的風險太高。

5 個最常見的 OMS 開發地雷

在系統開發案中，OMS 類型的專案踩地雷的頻率特別高，因為問題往往在上線後大流量、大退貨時才爆發。以下是最值得預防的 5 個：

關於軟體需求變更與合約保護，可參考：軟體需求變更 SOP：外包專案不被無限加價。

棱角 POV：我們對 OMS 客製化的判斷

恆遠的立場是：年營收 5,000 萬以下的品牌，不應該客製化 OMS。91APP 或 Cyberbiz 的基本 OMS 功能已經夠用，把錢拿去做選品和行銷，ROI 更高。花 150 萬做 OMS、省下的對帳工時，很可能 3 年都還不了本。

年營收超過 1.5 億、通路超過 5 個的品牌，客製 OMS 幾乎是必然路徑。SaaS 平台的 API 速率限制、抽成費用、功能黑盒，在這個規模都會成為明顯瓶頸。此時客製化的 ROI 計算很清楚：超賣損失 + 對帳工時 + 客服退貨 ticket，三項加起來每年節省通常超過 200 萬，2 年回本。

中間這段——年營收 5,000 萬到 1.5 億——是最難決策的地帶。這個區間很多廠商會推「模組客製」，也就是在 SaaS 基礎上疊加客製功能。我們的建議是：先把你的訂單流程 SOP 文件化，跑 6 個月看哪些地方每週要人工介入 3 次以上，那幾個點才是值得客製的標的，其餘維持 SaaS。

還有一個更長期的判斷：OMS 這個類別在未來 3-5 年，會被 agentic commerce（AI 自主下單、自主調度庫存）改變部分使用場景。目前 Gartner OMS 相關研究也開始提及 AI 驅動的訂單決策層。如果你打算未來 3 年要嵌入 AI 決策，建議在架構設計時就留好 API 層，而不是把邏輯全部寫死在後端。

ROI 試算：客製 OMS 怎麼算回本

ROI 計算要從「現在的損耗」出發，而不是從「未來的可能」出發。以月訂單量 3,000 筆、3 個通路、月 GMV 1,500 萬的電商品牌為例：

• 超賣損失：假設超賣率 0.5%（15 筆/月），每筆補償成本（退款 + 客服工時 + 貨損）約 2,000 元 → 每月損失 3 萬，年損失 36 萬
• 對帳工時：3 個通路各自下載帳務報表手工比對，假設 2 名會計每月各投入 20 小時，時薪 400 元 → 每月 1.6 萬，年 19.2 萬
• 客服退貨 ticket：每月退貨 150 筆，人工處理每筆 15 分鐘，客服時薪 300 元 → 每月 1.125 萬，年 13.5 萬
• 現有 SaaS 費用：假設月費 5 萬 + GMV 抽成 1.5% → 每月 5 + 22.5 = 27.5 萬，年 330 萬

年度總損耗：36 + 19.2 + 13.5 + 330 = 398.7 萬。客製化 OMS 開發費 200 萬 + 年維護 25 萬，第一年總成本 225 萬，第二年起每年只有 25 萬維護費。對比 SaaS 每年 330 萬，兩年內回本，第三年起每年節省 300 萬以上。

這個試算框架你可以帶進去找廠商時用：把你的實際數字填進去，算出「不做的代價」，比較「做的投資」，就能清楚判斷時機。CRM 整合通常也會影響訂單分析，相關參考：客製化 CRM 系統開發完整指南。

找廠商前的 7 個檢核題

在發 RFP（詢價單）之前，把這 7 個問題先問清楚，可以過濾掉 80% 不合格的廠商：

POS 整合部分也是 OMS 常見的延伸需求，可以一起參考：客製化 POS 收銀系統開發指南。

OMS 訂單管理系統要做得值得，關鍵往往不在功能多炫，而在把「手動轉單、對庫存、更新出貨狀態」這種重複工作從人身上拿掉、讓重複的部分自己跑——這也是恆遠做客製化系統時優先處理的：先消除那些每天重複、又最容易出錯的工時。想看不同產業實際怎麼用客製化系統省掉重複人工，可參考 其他業者用系統省掉重複工的實例。