已有 ERP，為什麼還需要 B2B 下單入口？先把兩套系統的工作分清楚
「我們不是已經有 ERP 了嗎？」
一家批發商在討論 B2B 下單系統時，老闆通常很快就會問到這句。
ERP 裡有商品、客戶與價格，也能開單、扣庫存、出貨、對帳。既然資料都在裡面，為什麼還要多一個入口？
但回頭看每天的接單現場，客戶還是在 LINE 說「雞塊兩箱」、打電話問庫存，或把 Excel 丟給業務。業務看完再轉給助理，助理把客戶的說法翻成正式品號，最後才輸入 ERP。
公司有 ERP，沒錯。只是 ERP 真正開始工作的時間，往往是有人先把訂單整理好之後。
ERP 管的是內部交易，客戶下單發生在它前面
我們遇過一家餐飲食材供應商，客戶口中的「雞塊」其實是雞米花；供應商 ERP 裡的「雞塊」，卻真的對應另一款雞塊。
資深業助知道這位客戶的習慣，新人不知道。商品主檔沒有錯，客戶也不覺得自己講錯，但兩邊放在一起，就可能選到不同商品。
這正是 B2B 下單入口存在的位置。它不是把 ERP 再做一次，而是處理 ERP 前面的事：客戶看得到哪些商品、用什麼名稱找、套用哪一組價格、能買多少、由誰下單，以及送出前能不能自己再確認一次。
B2B 下單入口 | ERP |
客戶登入、公司與角色權限 | 客戶主檔與帳務資料 |
商品展示、客戶別名、歷史訂單與再次購買 | 正式品號、庫存、成本與會計科目 |
合約價呈現、最低／最高訂購量、可售資格 | 訂單成立、庫存異動、出貨與應收 |
收集並驗證客戶送出的訂購內容 | 成為公司內部正式交易紀錄 |
前台比較接近客戶，ERP 比較接近公司的營運核心。兩套系統可以分工，不能各自認定自己才是全部答案。
多一套系統會不會變成資料孤島？
會，如果商品、價格、庫存和訂單在兩邊各維護一份，而且沒人說得清楚哪一份算數。
但問題不在「有兩套系統」，而在資料責任沒有先定義。
例如正式品號以 ERP 為準；客戶別名可以由 B2B 前台補充。可售庫存由 ERP 或倉儲系統提供；前台只呈現允許客戶看到的數量。客戶送出的訂單在前台取得唯一編號，成功寫入 ERP 後回傳正式單號；若匯入失敗，訂單不能默默消失，也不能因為重送而變成兩張。
規則先講清楚，B2B 前台是在延伸 ERP；沒有講清楚，它才會成為資料孤島。
大型軟體廠商也採這種分工。Microsoft 讓 Shopify 與 Business Central 同步商品、庫存、客戶及訂單；SAP 的 B2B Portal 則連接 ERP，讓客戶自行查看訂單、交期與付款狀態。前台與 ERP 可以是互補關係。Microsoft Learn、SAP
舊 ERP 沒有 API，也不代表只能全部換掉
真正麻煩的通常在這裡。
台灣不少企業沿用多年的地端 ERP，沒有開放 API，甚至連批量匯入都不是標準能力。等要接 B2B、電商或 AI，才發現「資料怎麼進去」要另外評估。
常見做法有四種：
正式 API：較適合即時同步，但要確認讀寫範圍、費用、測試環境與異常回傳。
固定格式批量匯入：不一定即時，卻很適合先拿掉逐張 Key-in。一家生鮮批發商就是每天把前台訂單整理成固定 Excel，再匯入原 ERP，核心系統沒有因此被淘汰。
連接器寫入既有系統：可行，但欄位變動、ERP 升版與資料出錯後的責任要先說清楚。
RPA／桌面精靈代操作：當系統沒有正式入口時，可暫時模擬人員點擊；代價是畫面或流程一改，穩定性與維護就會浮上來。
不是每家公司都要追求即時 API。有時每天一次穩定的批量匯入，比一條沒人敢維護的即時串接更實用。
客戶真的會自己下單嗎？
不用把答案想成「全部會」或「全部不會」。
生鮮批發商讓小型客戶自行下單，不願改流程的大客戶仍由助理協助建單。另一家有兩千多項商品的美髮器材批發商，客戶一開始最常使用的甚至不是下單，而是查規格與庫存。單一電話線原本每天約 30～40 通，後來降到約 10 通，留下來的才是維修、客製與複雜商品建議。
McKinsey 2024 年對近 4,000 位 B2B 決策者的調查也顯示，買方會混用面對面、遠端溝通與數位自助。B2B 前台不必消滅業務或 LINE；它先接住適合自助的查詢、重複購買與標準訂單。McKinsey B2B Pulse 2024
導入前，先把這些問題問完
☐ 商品、客戶、價格與庫存，分別以哪套系統為準？☐ 客戶別名、包裝單位與歷史購買紀錄由誰維護？☐ 訂單用 API、批量匯入、連接器還是 RPA 進 ERP？☐ 匯入失敗時誰會收到通知，訂單停在哪個狀態？☐ 重送時如何避免 ERP 多出一張相同訂單？☐ ERP 的正式單號、出貨與付款狀態要不要回到客戶端？☐ ERP 升版或欄位調整後，誰負責修改與驗證？☐ 哪些客戶自行下單，哪些仍由業務或助理代建？
如果這些問題沒有答案，就算只買一套新模組，也可能很麻煩。反過來說，只要資料主責與例外流程清楚，保留既有 ERP，再補一個客戶真正用得上的入口，往往比一次推翻整套核心系統更務實。
如果你正在評估這段流程，可以先做「一張訂單被幾個人碰過」的 B2B 接單流程健檢。先找出訂單在哪一段被重新輸入、重新翻譯或等人確認，再決定需要的是前台、匯入、API，還是先改流程。
留言