這會決定
誰擁有資料、介面與失敗後的下一步
- 九個資料域的 system of record 與欄位寫入權
- 方向、頻率、ID、冪等、重試、重播與對帳契約
- 切換門檻、放行決策、復原與日常營運責任
Shopify × 企業系統決策與營運藍圖
整合要能接通，還要能負責、能復原。
Shopify ERP 整合藍圖 把商品、顧客、價格、庫存、訂單與財務資料，整理成來源真相、同步契約、失敗操作、切換證據與 RACI。
這是有邊界的決策與交接框架；不代表 connector 支援、即時能力、交付時程、SLA 或結果承諾。
整合控制層 決策圖
商務
Shopify
channel · experience
企業系統
ERP · PIM · OMS
records · operations
契約需要負責人
來源
權威來源識別碼＋
冪等性重播＋
對帳
權威來源識別碼＋
冪等性重播＋
對帳
營運
Detect → contain → replay
發布
門檻 → 切換 → 交接
這不預設
所有系統都該雙向、即時，或由單一平台主導
- 不先指定 Shopify、ERP 或中介層為所有資料的真相
- 不把正常流程 demo 當成營運韌性的證明
- 不以系統清單替代欄位權威、例外與責任簽核
01 / 資料領域責任
先定義真相，再設計同步。
system of record 不是一個全域標籤。每個資料域甚至每個欄位，都要回答誰可寫入、誰核准語意、如何傳遞，以及用什麼證據處理差異。
| 資料域 | 記錄與狀態 | 來源真相問題 | 方向與頻率問題 | 完成證據／Accountable |
|---|---|---|---|---|
| D01商品 | 主商品、變體、屬性、媒體、分類、可售狀態 | 哪個系統核准可銷售定義？哪些內容欄位可由商店或 PIM 覆寫？ | 建立、更新、下架分別由哪裡發起；採事件、批次或受控人工處理？ | 欄位權威表、識別碼對照、發布與退場樣本。A · 商品／內容域負責人 |
| D02顧客 | 身份、聯絡資料、偏好、標籤、帳號狀態 | 身份合併與欄位更新由誰核准？偏好與服務資料邊界在哪裡？ | 建立、合併、更新與刪除指令如何傳遞及留下證據？ | 身份匹配規則、欄位權限與例外紀錄。A · CRM／顧客資料負責人 |
| D03公司 | B2B 公司、地點、買方角色、條款、核准狀態 | 公司層級、地點與買方權限由哪個業務流程核准？ | 核准、停用與角色變更何時進入 Shopify 及下游系統？ | 公司／地點識別碼、角色對照與核准軌跡。A · B2B 商務負責人 |
| D04價格 | 基礎價、合約價、價目表、促銷、稅務輸入 | 基價、客戶價與促銷誰有最終權威？優先序衝突由誰判定？ | 價格生效與失效如何同步；過期或缺價時採何種保護狀態？ | 價格優先序、有效區間與邊界案例測試。A · 商務定價負責人 |
| D05庫存 | 現有量、保留量、可售量、庫位、調整 | 現有量與可售量由誰計算？保留、釋放與調整的責任邊界在哪裡？ | 更新頻率與容許延遲如何決定；尖峰、斷線與回補怎麼處理？ | 庫位對照、可售公式、延遲與差異門檻。A · 庫存／供應鏈負責人 |
| D06訂單 | 訂單、明細、付款狀態、取消、編輯、風險狀態 | 訂單建立後，哪個系統可推進或修改各階段狀態？ | 重送、順序錯置、部分失敗與人工編輯如何保持可追溯？ | 狀態機、冪等鍵、重複與延遲案例。A · 訂單營運負責人 |
| D07履約 | 分配、揀貨、包裝、出貨、追蹤、部分履約 | 分配與出貨狀態由 OMS、WMS、ERP 或承運流程中的誰核准？ | 部分出貨、改單與承運例外如何回寫並通知營運？ | 履約狀態對照、追蹤樣本與例外操作手冊。A · 物流／履約負責人 |
| D08退貨 | 退貨申請、RMA、收貨、退款、換貨、回庫 | 退貨核准、退款與回庫各自在哪個系統成為正式狀態？ | 部分退貨、跨單換貨與失敗退款如何重播及對帳？ | 退貨狀態機、金額／數量對帳與例外責任。A · 客服／退貨負責人 |
| D09財務 | 發票、折讓、稅額、收款、退款、入帳與關帳狀態 | 會計憑證與正式入帳由誰生成？電商狀態能否修改財務真相？ | 交易與調整以何種批次或事件進入會計流程；差額如何結案？ | 金額對帳、憑證關聯、關帳例外與核准軌跡。A · 財務／會計負責人 |
窄螢幕可水平捲動表格。所有主資料系統與負責人 均須由實際組織核准。
02 / 工作流規劃
不要一次解所有事；先排出會阻擋決策的三條線。
選擇 ERP、PIM、CRM、OMS、WMS 或會計情境，再選一到三項風險。工具只會產生三條方向性工作流。
匿名整合規劃工具
用系統情境與風險，排出三條先做的工作流。
不輸入公司或帳號資料，不儲存答案。結果是方向性工作底稿，不是架構定案、估價或交付承諾。
03 / 契約結構
「API 可用」不是介面契約。
一條可營運的資料流，必須在開發前就能回答權威、方向、頻率、識別、冪等、驗證與例外邊界。
權威來源
權威來源要明確到欄位與狀態，不能只指定一個系統名稱。
交付產物：資料域與欄位權威矩陣
流向與頻率
標記流入、流出或有明確理由的雙向同步；頻率依營運需求選擇事件、批次或受控人工處理。
交付產物：流向、觸發、頻率與容許延遲表
識別規則
固定主識別碼、各系統外部識別碼、建立時機與對照生命週期。
交付產物：識別碼命名空間與對照表
冪等與順序
定義冪等鍵、重複判定、訊息順序、延遲到達與版本衝突。
交付產物：去重、排序與衝突規則
驗證
分開驗證資料結構、商業規則、權限與參照完整性。
交付產物：驗證錯誤碼與處置矩陣
例外邊界
寫清楚重試停止點、隔離條件、人工修正與安全重播前提。
交付產物：錯誤分類與重送操作手冊
04 / Failure operations
復原必須留下可驗證的證據。
重試只是一個動作。完整復原要先界定影響、停止擴散、保留原始證據，再安全重播並完成跨系統對帳。
- 01
偵測
以關聯識別碼、狀態與錯誤分類找到失敗批次及受影響記錄。
離開條件：可界定影響範圍與第一責任人。
- 02
控制
停止擴散、隔離訊息，保留原始訊息內容與處理歷程。
離開條件：未完成記錄不會被誤認為成功。
- 03
重播
修正原因後，以冪等鍵與前置檢查安全重播或人工補救。
離開條件：重播不製造重複或覆蓋較新的狀態。
- 04
對帳
比較來源與目的地數量、金額、狀態及樣本，處理剩餘差異。
離開條件：差異為零，或每筆剩餘例外都有負責人與核准。
05 / 可操作性
能看見，也要知道誰可以處理。
可觀測性回答發生什麼；安全與存取則回答誰能查看、修改、重播與撤銷。兩者都需要 owner 與複核證據。
OBS
可觀測性
- 端到端關聯識別碼
- 成功、延遲、失敗與待處理量指標
- 告警接收、分級與升級路徑
誰值守、誰判定影響、誰可以關閉事件？
SEC
安全與機密
- 服務身分與最小權限
- 秘密保管、輪替與撤銷責任
- 傳輸與保存資料邊界
誰核准權限，誰管理憑證生命週期？
AUD
稽核與存取
- 設定與人工操作留痕
- 高權限操作與定期複核
- 供應商、內部與緊急存取邊界
誰能查看或重播資料，複核證據放在哪裡？
06 / Release gates
切換由一連串證據關卡組成，每一關都能決定暫停。
雙跑、shadow 或凍結策略是否適用，要依系統與風險決定；藍圖要求的是每一步都有明確問題、證據與核准權。
- G1
契約可驗證
正常、重複、延遲、錯序與失敗案例是否都有測試？
通過證據契約測試結果、未決缺口與接受風險。
核准負責人整合工程負責人
- G2
資料可準備
識別碼對照、初始載入、增量與對帳基準是否固定？
通過證據載入清單、基準數量與差異處理表。
核准負責人資料域負責人
- G3
切換可演練
凍結、回填、雙跑或平行觀察、冒煙測試及回復是否走過？
通過證據演練紀錄、實際耗用量測與修正版操作手冊。
核准負責人發布負責人
- G4
放行／不放行可判定
哪些證據允許前進，哪些訊號立即停止或回復？
通過證據簽核表、門檻、指揮頻道與回復觸發。
核准負責人業務負責人與發布負責人
- G5
穩定期可交接
告警、例外、對帳與日常操作由誰接手，何時結束加強監看？
通過證據交接確認、未結事項、營運儀表板與值守表。
核准負責人營運負責人
07 / 責任分工
每條資料流，都要有唯一核准責任。
R 執行 ResponsibleA 核准 AccountableC 協作 ConsultedI 知會 Informed
| 工作流 | 商務／資料域 | Shopify 產品 | 整合工程 | 營運／資料 | 平台／安全 | 發布負責人 |
|---|---|---|---|---|---|---|
| 定義資料域與欄位權威 | A / R | C | C | C | I | I |
| 設計介面、識別碼與冪等契約 | A | C | R | C | C | I |
| 核准例外、重播與對帳流程 | A | C | R | R | C | I |
| 核准服務身分、秘密與存取 | C | I | R | I | A / R | I |
| 執行切換與放行／不放行 | A | R | R | R | C | A / R |
| 接受穩定期與日常營運 | A | C | C | R | C | I |
角色是責任模板，不代表固定組織或 Tenten 的人力配置；正式 RACI 必須由實際參與團隊重新核准。
08 / 實作交接
交接的標準，是接手者能追溯每個決定。
交接包不綁定特定實作者。內部團隊、既有合作夥伴或後續選定的服務團隊，都應能用同一份證據進行估算、實作與驗收。
資料域決策文件包
九個資料域的來源真相、欄位權威、狀態機、負責人與未決事項。
介面契約文件包
每條資料流的方向、頻率、識別碼、冪等、驗證、權限與版本規則。
營運文件包
監測、告警、隔離、重試、重播、人工補救、對帳與結案證據。
發布文件包
測試、載入、凍結、切換、放行／不放行、回復、穩定期與 RACI。
09 / 常見問題
先把常見的整合捷徑拆開。
如果答案仍依賴實際系統、資料樣本或組織權責，藍圖會把它保留為待驗證問題，而不是補上一個看似確定的承諾。
不會。它先定義資料域、權威來源、介面契約與營運條件，再讓團隊用一致準則評估實作選項。頁面不宣稱支援任何特定串接工具。
不應預設。方向與頻率要由商業需求、容許延遲、系統限制、失敗成本與復原能力共同決定。雙向同步還需要額外的衝突、排序與欄位權威規則。
通常不夠。權威來源需要落到資料域、欄位與狀態。例如某系統可以建立訂單，但未必有權改寫財務入帳或履約結果；這些邊界必須逐項核准。
因為網路逾時、重送、延遲與部分失敗是整合的正常風險。若沒有穩定識別碼、冪等鍵和重播前置檢查，復原動作可能製造重複或覆蓋新狀態；若沒有對帳，團隊也無法證明已恢復一致。
不是。表格是責任檢核起點，實際角色可由內部團隊或合作夥伴承擔。重點是每項工作都有唯一核准責任、明確執行者，以及需要被諮詢與知會的人。
不會。選擇只存在目前元件的記憶體狀態，不使用帳號、文字輸入、cookie 或瀏覽器儲存，也不送出答案。分析事件只包含固定選項衍生的數量與工作項目代碼，不包含個人或公司資料。
帶著系統邊界來，不必先準備答案
把目前的系統、風險與未決權責帶來，我們先判斷該留下哪些證據。
討論 Shopify 企業整合
不需要先準備完整規格；可以從系統清單、資料域與最擔心的失敗情境開始。