CRM、POS、ERP 和電商系統怎麼整合：客製開發不是唯一的路

五套系統都有了，一個問題還是要三個部門各出一張 Excel

零售品牌盤點手上的系統，通常會列出這幾樣：電商平台、門市 POS、ERP、CRM，可能再加一套報表工具。看起來很齊全。接著有人問一個很日常的問題：上週在門市買過、又在官網看過同一個系列的人，有誰。

這個問題會讓會議室安靜下來。不是因為沒有資料，而是因為答案分散在四個系統裡，而它們沒有共用同一組顧客身分。實務上的解法往往是三個部門各匯出一張 Excel，然後有人用手機號碼在試算表裡比對到半夜。

這件事在產業標準裡早就不被當成需要特別客製的工程。制定 CDP 認證標準的產業公會 CDP Institute，在 RealCDP 認證的稽核細項裡列出一份預建連接器（prebuilt connectors）該涵蓋的範圍：「web, email, mobile, advertising, CRM, e-commerce, point of sale, data warehouse and lake, ERP, and second- and third-party data and ID graphs」。CRM、電商、POS、資料倉儲、ERP 全都在裡面。要說清楚的是，這是一份給 CDP 產品的認證標準，它證明的是「連接這些系統屬於成熟產品該有的能力」，並不等於任何品牌的整合都不需要客製。但它確實把舉證責任翻轉了：當供應商說某個連接只能客製，那是一個值得追問的答案，不該當成預設。

廠商報價單上那一欄，我們最常被問的問題

我們陪品牌看廠商報價單時，最常被指著問的就是「客製串接」那一欄：這筆一定要花嗎。問的人多半不是在殺價，他們真的無法判斷這一欄代表無可避免的工程，還是有另一種做法可以換。我們每次看到這一欄被含糊地寫成一個大數字，都覺得有點不忍心，因為簽下去之後維護責任歸誰，往往沒有人在那個時間點問清楚。

先分清楚每套系統負責的是哪一筆紀錄

多數混淆來自把系統當成功能清單在比。換一個問法會清楚很多：這套系統負責保管哪一筆紀錄，而且它是那筆紀錄的權威來源。

這張表講的是職責，不是產品清單。一套產品可以同時扛好幾格，供應商的套裝模組也常一次覆蓋數格，所以重點不在數格子，而在每一格有沒有人明確負責。表攤開之後，兩件事會浮現。

1. 沒有人負責「同一個人」。電商平台知道帳號、POS 知道當場刷的那張卡或那個手機號、ERP 知道那批貨去了哪裡，但沒有任何一套的職責是維護「這些紀錄指向同一位顧客」。CDP Institute 給 CDP 的定義正好是這一格：建立並維護一份持續存在、統一的顧客紀錄，而且其他系統取用得到。至於實際怎麼把門市與線上的同一個人認出來，那是另一個獨立的題目，牽涉比對欄位與規則設計，不在本文範圍。
2. BI 常被誤當成整合。報表工具把五套系統的數字彙總成一頁，看起來像整合完成了，但它產出的是給人讀的結論，不是可以拿去觸發行動的顧客名單。這兩者的差距，就是「看得到」與「用得到」的差距。

CRM 已經有了，為什麼還會缺一塊

CRM 裝了顧客資料，但它不負責判斷這些資料屬於同一個人，這就是缺口的位置。多數品牌的系統起點都是 CRM，所以這一段值得單獨講清楚。

缺口跟資料有無無關，出在資料模型的設計目的。CRM 的資料結構是為了承載「與這個顧客的往來過程」，它擅長記錄聯絡歷程、服務工單、溝通紀錄、階段推進。當你要它同時扛「跨四個來源判斷這些紀錄屬於同一人」時，它被派了一個它的結構沒有為之設計的工作。硬做的結果通常是在 CRM 裡開一堆自訂欄位，把門市消費、線上瀏覽塞進去，短期看起來會動，維護成本往往在一兩年後才浮現。

類似的落差在別的系統上也出現過。CDP Institute 在說明 CDP 為什麼存在時，點名企業資料倉儲與資料湖這兩種傳統做法並沒有解決統一顧客檔案的問題。它講的對象是倉儲與資料湖，不是 CRM，這裡不把那個結論直接套到 CRM 身上；但兩者失分的位置相同，都不是為「維護跨來源的同一個人」而設計的。CRM 做得好不好是另一回事，它負責的那一格本來就不是這一格。

還有一個技術之外的前提要先講明：門市 POS 的資料技術上接得進來，不等於法遵上可以拿去做行銷溝通。個人資料保護法對個人資料的蒐集、處理與利用設有必要範圍的限制，蒐集當時告知的特定目的寫了什麼，會決定這批資料的可用邊界。這一塊屬於資料治理的題目，本文不展開，接之前請與法務確認當下有效的條文。

把系統接起來有好幾條路，客製通常排在最後

把 CRM、POS、ERP 與電商系統接起來，實務上有好幾種做法，客製開發只是其中一種，而且通常應該排在最後才考慮。本文把常見的做法整理成以下五條路，它們不是互斥的分類，一個專案裡經常混用幾種，重點在於問的順序。

1. 原生同源：同一家供應商的模組本來就共用一份顧客與訂單資料，等於不需要「接」。適合願意把電商、POS、會員收在同一個供應商的品牌。代價通常是彈性較低、換供應商的成本高；好處是省掉介接維護的長期支出，資料口徑也比較容易一致。
2. 預建連接器與無程式碼設定：由平台方提供現成連接器，選一選、對一對欄位就會動。RealCDP 稽核明確把這類連接器涵蓋範圍列為檢查項，同時也檢視「client-built 與 no-code source setup」兩種設定方式，代表這在產業標準裡是被預期的常態能力。適合系統組合常見、欄位規格標準的品牌。
3. 標準 API 對接：兩邊都照公開規格開介面，由其中一方或第三方寫串接邏輯。OpenAPI Specification 這類標準的存在意義正是讓 API 能用與程式語言無關的方式被描述，降低雙方對接的溝通成本；它由 OpenAPI Initiative 維護，隸屬 Linux Foundation。適合有工程資源、或系統組合較特殊的品牌。
4. 檔案批次交換：定時匯出匯入 CSV。通常最便宜也最快能動，代價是資料落後一個排程週期，只適合對時效不敏感的用途，例如月結對帳。拿它支撐即時行銷觸發，會踩到時機永遠慢一步的坑。
5. 客製開發：為這個品牌的特殊流程寫專屬串接。真正適合的情況是系統老舊沒有可用介面、或流程確實獨一無二。它的成本形態要看清楚：報價單上是一次性的開發費，實際上還有持續的維護責任，供應商改版時誰負責修，這件事應該在簽約前就寫明。

判斷順序其實不難：先看能不能靠原生同源省掉整合，其次問有沒有預建連接器，再問標準 API 能不能接，時效不敏感的部分可以用批次先過渡，剩下真的無路可走才動客製。多數品牌被報價單上那一欄嚇到，是因為沒有人陪他們把前面四條路走一遍。

還有兩個問題比選哪條路更容易被跳過，而它們才是介接會不會出事的地方。

第一個是欄位怎麼對應。兩邊都叫「會員編號」，內容可能一邊是手機號、一邊是系統流水號；兩邊都叫「訂單金額」，一邊含運費與稅、一邊不含。連接器接得起來，欄位對錯了照樣產出錯的名單，而這種錯不會報錯，只會讓數字對不起來。要求供應商提供欄位對應表，並逐欄確認定義，這件事花的時間遠比事後查帳少。

第二個是誰是衝突時的權威來源。同一位顧客的手機號在 POS 與電商平台不一樣時，以哪邊為準；門市改了地址，要不要覆蓋線上的舊資料。這是規則決定，不是技術決定，沒有先講定，介接完成的那天就是資料開始互相覆蓋的那天。

要不要每一套都買

不必。這張地圖上的六格代表六種職責，不等於六張採購單，一格可以由一套系統兼任，也可以由供應商的模組覆蓋。真正該避免的是反過來的狀況：買了很多套，卻沒有任何一套負責「同一個人」那一格。工具愈買愈多、資料卻愈來愈碎，根源是缺一個統一的會員身分，這一點另一篇已經拆過，這裡不重複。

順序上，先確認顧客紀錄那一格有人負責，再往外加工具，加上去的每一套才會讀到同一份資料。若還沒把 CRM、CDP、ERP 三者的職責分清楚，這三個縮寫的角色差異值得先讀一遍；如果正在評估要換或要買 CRM，零售 CRM 的選型判準跟 B2B 的判準差很多。

顧客紀錄那一格，實務上由誰來顧

當品牌把上面那張地圖畫完，缺的通常就是顧客紀錄那一格。這也是 91APP CDMP 在客戶的系統地圖裡站的位置，它不取代 ERP、不取代 POS、不取代電商平台，它負責那一格，以及把那一格的結果送到能執行的地方。

1. 把跨來源的紀錄收成一份會員身分：線上行為、App、門市消費要對得起來，跨通路的消費才算得出來。這一步為什麼常卡住，往往不是技術，通路之間的利益怎麼分比串接更難談。
2. 把身分變成可以用的分群：CDMP 的會員生命週期分群把會員分成註冊未購、新客、活躍、主力預備、流失、沉睡六群，其中的購物週期是綜合全店與個人的消費頻次與消費時間演算出來的，每位消費者各自不同，而不是全店套用一個固定天數。另一組分群按未來十四天的購買機率把人排序，讓溝通的優先順序有依據。高購買意圖名單則供廣告投放使用。
3. 把名單送到會動的地方：分群要能直接推進推播、簡訊、Email、LINE 官方帳號與廣告受眾，行銷才不需要每次都排一張工單等資料。

至於整合做完之後，OMO 的成效該怎麼歸因與衡量，那是另一個題目，涉及制度與計算口徑，這裡先不展開。

簽客製之前，先把這張地圖畫出來

以下幾件事不需要等預算核准就能做完，做完再回去看報價單，那一欄該不該簽會清楚很多。

1. 畫一張你手上的系統地圖：六格職責逐格填上目前由誰負責，空白的那一格就是缺口（預期效果：把「要整合」這個模糊需求變成一格具體的空缺；建議週期：一次跨部門會議，兩小時內可完成）。
2. 逐格問供應商有沒有預建連接器：把手上系統的名字列出來，直接問對方現成支援哪幾個、要如何設定（預期效果：分辨報價單上的客製有幾成其實是現成能力；建議週期：詢價階段一次問完）。
3. 分清哪些資料需要即時、哪些可以批次：即時觸發與月結對帳的需求不同，混在一起談會把成本推高（預期效果：省掉不必要的即時介接；建議週期：與需求盤點同時做）。
4. 在合約裡寫清楚介接的維護責任：供應商改版、欄位變更時誰負責修、多久內修好（預期效果：避免第二年的隱形成本；建議週期：簽約前必須完成）。
5. 確認同意與特定目的涵蓋範圍：門市與線上蒐集時告知的特定目的，有沒有涵蓋後續的行銷使用，這件事要跟法務確認過再接（預期效果：法遵風險前置處理；建議週期：與地圖同步進行）。

這五件事有一個共同點：它們都在把「整合」這個大詞拆成可以逐項回答的小問題。拆完之後，需要客製的部分通常比原本以為的少。

整合不是一筆開發費，是一組先該問完的問題

回到報價單上那一欄。它之所以讓人不安，是因為它把一個可以拆解的決定，包成一個看不出內容的數字。

系統有好幾套，本身沒什麼問題。要問的是有沒有任何一套負責「同一個人」那一格，以及當你要接起來時，有沒有人陪你把原生同源、預建連接器、標準 API、批次交換都問過一遍。產業標準把連 CRM、POS、ERP、電商平台的連接器當成應有的能力，這代表品牌手上的籌碼比想像中多。

下一次那個問題再出現，上週在門市買過又在官網看過同一個系列的人有誰，衡量整合有沒有做好的標準很簡單：答案是一份可以直接拿去溝通的名單，還是三張要對到半夜的 Excel。

品牌最常問的系統整合問題

Q1：CRM、POS、ERP 和電商系統各自負責什麼？

A1：用「誰是哪一筆紀錄的權威來源」來分最清楚。電商平台管線上商品、訂單與網站行為；POS 管門市每一筆結帳；ERP 管庫存、進出貨、成本與財務憑證；CRM 管與顧客往來的互動與流程紀錄。BI 或報表工具把各家數字彙總成給人讀的結論。這四套都不負責維護「這些紀錄指向同一個人」，那一格屬於 CDP。

Q2：POS、ERP、CRM 和電商系統要怎麼整合，一定要找廠商客製嗎？

A2：不一定，客製只是五條路裡的一條，而且通常是最後一條。依序是原生同源（同一供應商模組共用資料）、預建連接器與無程式碼設定、標準 API 對接、檔案批次交換，最後才是客製開發。CDP Institute 的 RealCDP 稽核把涵蓋 CRM、電商、POS、資料倉儲、ERP 的預建連接器列為檢查項，代表這類連接在產業標準裡屬於常態能力。建議先把前四條路問過一遍，再決定客製的範圍。

Q3：我們已經有 CRM 了，為什麼還會缺一塊？

A3：缺口出在資料模型的設計目的，跟資料多寡無關。CRM 的結構是為了承載與顧客的往來過程，擅長聯絡歷程與服務流程；跨四個來源判斷紀錄屬於同一人，超出它結構被設計的用途。硬用自訂欄位把門市消費與線上瀏覽塞進 CRM，短期會動，維護成本往往在一兩年後才浮現。

Q4：這些系統要不要每一套都買？

A4：不必。地圖上的六格是六種職責，不是六張採購單，一套系統可以兼任多格，供應商的模組也可能一次覆蓋數格。要避免的是買了很多套卻沒有任何一套負責「同一個人」那一格。順序上先確認顧客紀錄那一格有人負責，再往外加工具，後面加的每一套才會讀到同一份資料。

Q5：CDP 跟 CRM 的差別到底在哪？

A5：CDP Institute 的定義是「建立並維護一份持續存在、統一的顧客紀錄，而且其他系統取用得到」的軟體。CRM 負責的是與顧客往來的流程與紀錄，資料模型為流程而設計；CDP 負責的是跨來源的身分統一與對外供給，資料模型為整合而設計。兩者互補而非替代，多數零售品牌是先有 CRM，後來才發現缺 CDP 那一格。

Q6：整合的時間怎麼估，最常見的失敗是什麼？

A6：時間主要由走哪一條路決定，而不是由系統數量決定：原生同源與預建連接器通常最快，標準 API 取決於雙方的工程排程，客製開發最久且維護責任拖得最長。與其問總共幾週，不如請供應商就你的系統組合逐條說明作法與前置條件，時程自然會落出來。最常見的失敗有兩種，一種是用檔案批次去支撐需要即時觸發的行銷，資料慢一個排程週期就失去意義；另一種是合約沒寫清楚介接的維護責任，供應商改版後沒有人負責修。這兩件事都該在簽約前問完。

延伸閱讀

1. CDP、CRM、DMP 差異與選型策略完整比較
2. CDP 導入流程實務：純電商與 OMO 的兩條路
3. 電商 CDP 導入失敗的十個原因與解法