一句話結論：官網與 ERP 整合的價值不在於技術本身，而在於讓對外的資訊和內部的真實狀況一致——網站上的庫存、交期、產品規格不再是三年前寫的。但整合有一個前置條件常被跳過：內部資料本身要準。資料不準就串接，只會把錯誤更快地送到客戶面前。
很多公司的官網和內部系統是兩個世界。ERP 裡有即時的庫存與交期，官網上寫的是「請來電洽詢」或一個三年前的數字。這個落差對內部來說只是不方便，但對買家來說是直接的篩選依據。
這篇文章談三件事：整合能帶來什麼具體改變、整合前必須先確認的資料品質問題、以及資訊安全在這件事裡的角色——因為一旦把內部系統對外開放介面，安全就不再只是 IT 的事。
資料孤島造成的具體損失
「資料孤島」聽起來抽象，但它造成的損失很具體。
| 狀況 | 實際損失 |
|---|---|
| 網站寫「請洽詢」，ERP 裡有現貨 | 急需現貨的買家直接跳過你 |
| 網站的交期是舊資料 | 客戶依此規劃卻無法履行，或反之錯失訂單 |
| 規格在網站與 ERP 不一致 | 報價與實際出貨不符，產生糾紛 |
| 訂單從網站進來要人工轉錄 | 人力成本與轉錄錯誤 |
| 客戶問進度要打電話 | 業務時間被查詢占用 |
| 停產品項還掛在網站上 | 收到無法滿足的詢問，浪費雙方時間 |
最後一項最常見也最容易修。很多網站上還掛著早就停產的品項，因為沒有人負責同步。即使不做完整串接，光是建立「停產品項要從網站下架」的固定流程，就能減少不少無效詢問。
哪些資料該串、哪些不該
不是所有資料都適合或需要對外。判斷原則是：變動頻率高、且買家決策需要的，才值得串接。
| 資料 | 建議 | 理由 |
|---|---|---|
| 庫存狀態 | 串接，但可只顯示粗略狀態 | 變動快，寫死一定會錯 |
| 標準交期 | 串接或定期更新 | 影響買家判斷，但不必到即時 |
| 產品規格 | 以 ERP 或 PLM 為單一來源同步 | 避免兩邊不一致造成糾紛 |
| 停產狀態 | 一定要串或建立流程 | 掛著停產品項損失最直接 |
| 客戶專屬價格 | 串接，但須登入後才顯示 | 商業敏感，不可公開 |
| 訂單進度 | 串接，登入後查詢 | 可大幅減少電話查詢 |
| 成本與毛利 | 絕對不要對外 | 無對外價值，風險極高 |
| 其他客戶的資料 | 絕對不要 | 個資與商業機密 |
庫存不一定要顯示確切數字。多數 B2B 買家只需要知道「有、沒有、還是要排程」。顯示粗略狀態（例如現貨供應／需排程／停產）就能滿足需求，而且避免了「顯示三件結果客戶要五件」這類尷尬，也不洩漏實際庫存水位。
整合前必須先確認的資料品質
這是整個專案最容易被跳過、也最容易導致失敗的一段。技術串接本身通常不難，難的是串接的資料本身是不是對的。
- 料號是否唯一且一致？常見狀況是同一個產品在不同部門有不同叫法、Excel 裡有多個版本。這一項沒處理好，串接後必然出現對不上的品項。
- 庫存數字是否準確？如果倉庫實際數量和系統數字常有落差，先處理盤點流程。串接只會把這個誤差更快地送到客戶面前。
- 規格資料是否有單一來源？如果規格同時存在 ERP、型錄原稿、網站三個地方且內容不同，必須先決定以哪一份為準。
- 停產與新品的狀態是否有人維護？如果 ERP 裡的狀態欄位本身沒人更新，串接過來也是舊的。
- 單位與換算是否統一？有的部門用「個」、有的用「箱」、有的用「公斤」，換算規則要明確。
實務上的建議：把「資料盤點與清理」當成專案的獨立第一階段，明確寫在報價與時程裡，而不是當成開發的附帶工作。這一階段沒有畫面可以看，在內部不好推，但跳過它幾乎一定會在上線後出問題。而且這一階段的成果本身就有價值——即使後來決定不做串接，乾淨的資料對任何作業都有幫助。
串接方式與各自的取捨
| 方式 | 怎麼運作 | 適合 | 要注意 |
|---|---|---|---|
| 即時 API 查詢 | 網站每次都向系統查 | 需要最新資料的查詢 | 系統負載、連線失敗要有備援顯示 |
| 定時同步 | 每隔一段時間把資料複製到網站 | 變動不快的資料 | 有時間差，要標示更新時間 |
| 事件推送 | 系統有變動時主動通知網站 | 狀態變更通知 | 需要系統端支援 |
| 中間資料庫 | 兩邊都讀寫一個中介資料表 | 原廠系統不開放 API | 架構較複雜，要處理同步衝突 |
多數情況定時同步就夠了。即時 API 查詢聽起來最理想，但它讓網站的可用性依賴內部系統的可用性——內部系統維護時，網站就查不到資料。對 B2B 的庫存與交期而言，每小時或每天同步一次通常足夠，而且架構單純得多。選即時之前先問：真的需要到秒級嗎？
對外開放介面之後的安全要求
一旦讓官網能讀取內部系統，安全的層級就不同了。這不是在談合規文件，而是幾件必須做到的事。
- 不要讓網站直連內部資料庫。應該經由一層 API，只開放必要的欄位與操作。網站若被入侵，攻擊者拿到的只是有限的查詢權限，而不是整個資料庫。
- 最小權限原則。查庫存的帳號就只給查庫存的權限，不要給可以寫入或讀取其他表的權限。
- 全程加密傳輸。官網與 API 之間一律使用 HTTPS，不要有任何明文傳輸的環節。
- 登入後才顯示的資料要確實驗證。客戶專屬價格、訂單進度這類資料，必須驗證「這個登入者有權看這一筆」，而不是只檢查有沒有登入。這是最常見的漏洞類型。
- 記錄存取日誌。誰在什麼時候查了什麼，要留紀錄。出事時這是唯一能釐清範圍的依據。
- 備份要做還原測試。有備份不等於能還原。實務上很多公司的備份從沒測試過，真的要用時才發現不完整。
關於第 4 項要特別強調：只檢查「有沒有登入」而不檢查「有沒有權限看這一筆」，是 B2B 系統最常見的資料洩漏原因。例如網址裡帶訂單編號，改一個數字就看到別家客戶的訂單。這類問題在開發階段很容易被忽略，建議在驗收項目中明確列入測試。
分階段導入與可驗收的項目
這類專案建議切成可以各自驗收的階段，避免做到一半無法評估。
| 階段 | 做什麼 | 可驗收的項目 |
|---|---|---|
| 一 | 資料盤點與清理 | 料號唯一性報告、規格單一來源確認 |
| 二 | 建立唯讀 API | 可查詢庫存與交期，含權限與日誌 |
| 三 | 網站顯示狀態（粗略） | 前台正確顯示，連線失敗時有備援文字 |
| 四 | 登入後專屬資訊 | 越權存取測試通過 |
| 五 | 訂單寫入 | 防重複送出測試、審核流程運作 |
第三階段的「備援文字」很重要。當內部系統連不上時，網站應該顯示「庫存資訊暫時無法取得，請洽詢」，而不是顯示錯誤訊息或顯示零庫存。這一項在驗收時要實際測試——把 API 關掉看前台的反應。
我們做這類整合最常遇到的狀況是：技術串接兩週就能完成，但資料整理花了兩個月。所以我們現在會把資料盤點列為獨立階段並單獨報價，讓客戶在一開始就知道這段的必要性。另一個我們一定會要求的驗收項目是越權存取測試——登入 A 公司的帳號，試著改網址參數去查 B 公司的訂單。這個測試很簡單，但它是 B2B 系統最常見的漏洞類型，而且一旦出事涉及的是客戶的商業資料。
常見問題
我們的 ERP 比較舊，還能串接嗎？
多數情況可以評估。如果原廠系統不開放 API，常見的替代方案是透過中間資料表或定時匯出匯入。這比打掉重練務實得多。但要先確認一件事：舊系統是否仍在維護？若原廠已停止支援，串接前要先評估風險。
庫存數字不準，可以先串接之後再處理嗎？
不建議。串接只會把既有的誤差更快地送到客戶面前，而且是放大到客戶看得到的地方。較務實的順序是：先顯示粗略狀態（有／無／需排程），同時處理內部盤點準確度，等數字穩定後再做精確顯示。
一定要做到即時同步嗎？
多數情況不必。即時 API 查詢讓網站的可用性依賴內部系統的可用性——系統維護時網站就查不到。對 B2B 的庫存與交期，每小時或每天同步一次通常足夠，架構也單純得多。選即時之前先確認真的需要到秒級。
整合之後最大的安全風險是什麼？
越權存取：只檢查「有沒有登入」而不檢查「有沒有權限看這一筆」。例如網址帶訂單編號，改一個數字就看到別家客戶的資料。這是 B2B 系統最常見的洩漏原因，建議在驗收項目中明確列入測試，而且不要讓網站直連內部資料庫。
這類專案大概怎麼切階段？
建議切成五段各自驗收：資料盤點與清理、建立唯讀 API、網站顯示粗略狀態、登入後專屬資訊、訂單寫入。第一階段沒有畫面但最關鍵；最後一階段必須有防重複送出與審核機制。每一段都要有可實測的驗收項目。
甫東科技提供哪些相關服務？
甫東科技提供 ERP 與官網整合的可行性評估、資料盤點與清理規劃、API 設計與串接開發、權限與越權存取測試、分階段導入規劃，以及整合後的維護。服務以高雄、屏東、台南為核心，嘉義、台東與全台皆可遠端合作。
想評估 ERP 與官網整合的可行性？
甫東科技提供免費整合評估，檢視你的系統開放程度與資料現況，告訴你哪些該先整理、哪一階段最快能見效，以及安全上要注意什麼。
預約免費整合評估 →甫東科技有限公司｜高雄市大寮區鳳林一路 184 巷 20-11 號
電話 07-641-8686｜Email service@fulldot.com.tw｜了解企業系統開發
