客戶資訊系統：中東國防業案例研究

這是一個案例研究，說明中東一家中型國防製造商如何修復它的客戶資訊系統。客戶資料散落在三個地方，報價發出時定價不一致，核准在電子郵件裡遺失。解方是在 Microsoft Dynamics 建立單一的客戶紀錄、在 Experlogix CPQ 中以規則進行報價，並透過 SAP Cloud Integration，把核准後的報價自動交接到 SAP 銷售與配銷（SD）。報價回覆時間平均縮短了 35%。本文寫給那些銷售週期長、產品可配置、法規遵循要求繁重的製造商中，負責銷售營運、IT 與財務的主管。接近結尾的導入順序與教訓，是可以直接拿來重複使用的部分。

當國防團隊要求客戶資訊系統時，他們通常要的不只是 CRM。他們要的是結構：一個讓複雜決策在脈絡中並存的地方，涵蓋漫長的銷售週期、法規遵循繁重的工作流程，以及不斷變動的決策者群體。

在擔任一家國防公司數位轉型總監的角色時，有人請我解決的正是這個問題。問題不在於缺少努力。大家都在做事。問題是這些努力沒有歸宿。沒有共用的平台、沒有可見性，也沒有讓所銷售的內容與所規劃的內容對齊。

中東一家中型的國防製造商。它在幕後運作：不是公眾品牌，能見度也不是重點。它的零組件用於軍用航空與保密通訊。

每筆銷售都循著一條詳盡的路徑：工程審查、法規遵循檢查、內部核准、受版本控管的報價。它不混亂，但很繁重。

客戶資訊系統正在瓦解。業務用一個平台。客服用另一個。營運則依靠試算表、離線資料夾，以及在任何人打開之前就已經過時的文件。

以下是哪裡壞了，以及它付出的代價：

哪裡壞了	影響
沒有用來掌握商機流程、或看見決策者的 CRM	對每筆交易進行到哪裡，沒有共同的全貌
定價由人工處理，沒有一致的紀錄	報價發出時帶著過時或互相矛盾的數字
核准透過電子郵件進行，常常遺失或延誤	法規遵循的稽核軌跡不完整
客戶紀錄在各系統間重複，細節略有不同	沒有人說得出哪個版本才是正確的

紙面上看起來有結構。但沿著一份報價從建立追到交付，它就崩解了。核准因為沒有明確的負責人而停滯。定價取決於是誰提交了報價。報價埋在電子郵件串裡。團隊一再互相詢問同樣的問題。這些都不是戲劇性的失敗，但經過數個月，小小的延誤累積起來，而對銷售週期很長的企業來說，流失的動能比多數人意識到的更重要。

目標不是取代一切。而是在不讓任何事更難使用的前提下，減少摩擦：幫助系統反映團隊原本的工作方式，而不是把人們逼進僵化的流程。

在動任何組態之前，我先花時間與各團隊相處。我觀察工作如何從擷取走到交付、工具在哪裡礙事，以及人們在哪裡不再信任資料。

那些討論中浮現了三項優先事項：

1. 一份共用的客戶紀錄，以相同的格式，讓業務、客服與營運都看得到。不再有平行的版本。
2. 結構化的報價，遵循一致的組態與定價規則，而不是個人習慣與舊範本。
3. 串接的訂單執行，讓核准的報價乾淨地交接給 SAP SD，不必人工重新輸入。

系統	解決了什麼
Microsoft Dynamics CRM	一份客戶紀錄，連結到銷售活動與商機
Experlogix Configure Price Quote（CPQ）	產品組態規則、定價邏輯、報價版本
SAP 銷售與配銷（SD）	訂單執行與履行
SAP Cloud Integration（CPI）	把 CPQ 與 CRM 連到 SAP SD 的整合層

Microsoft Dynamics 作為基礎。 我們需要一個地方，讓客戶資訊在完整的脈絡下既正確又可見。Dynamics 給了我們一個著手釐清資料的起點。對這個平台的熟悉度有幫助，它與 Outlook 和 Teams 的契合度也是。它不需要人們從頭開始；它需要的是調整，以符合企業的運作方式。一旦各團隊在不同職能間，看到相同格式的相同資料，信任便開始建立。

Experlogix CPQ 負責組態與定價。 之前，報價的做法太多種。人們靠記憶與手動修改。我們為 Experlogix 設定了明確的規則：產品組合、與組態掛鉤的定價，以及依交易類型與金額的核准路由。起初覺得受限，有些人也毫不避諱地這麼說，但它消除了模糊地帶。工程部門收到更乾淨的報價，業務也不再憑對先前交易的記憶來調整價格。

透過 SAP CPI 連接 SAP SD。 訂單本來就在使用 SAP SD。缺口在交接：核准後的報價，仍然得重新鍵入 SAP。我們透過 SAP CPI 把兩者整合起來，讓核准的報價直接以訂單形式推送進 SAP，客戶與訂單資料也在 Dynamics 與 SAP 之間保持同步。遇到限制的地方，我們加了客製邏輯。並非每一個都很優雅，但行得通。

1. 01客戶紀錄Microsoft Dynamics，每個團隊共用同一個版本
2. 02組態與定價Experlogix CPQ 的產品組合與定價規則
3. 03核准依交易類型與金額路由
4. 04建立訂單SAP CPI 把核准的報價推送進 SAP SD
5. 05履行SAP SD，客戶資料保持同步

不必重複輸入，且從核准到訂單都有稽核軌跡

導入分階段進行，歷時大約六到八個月。沒有什麼戲劇性：一層一層地改變，每一步都驗證。

1. 試行。 一小群使用者與特定情境，聚焦於 CRM 與 CPQ。我們測試邊界案例，找出缺口，並在擴大之前先做修改。
2. 清理資料。 客戶紀錄在進入 Dynamics 之前，先經過整併與去除重複，並把法規遵循文件連結到正確的商機。這比組態花了更長的時間。
3. 擴展到各部門。 試行流程調整完善之後，這套方案推廣到業務、客服與營運。
4. 在中途整合 SAP SD。 CPQ 到 SAP 的整合，是在上游系統穩定之後才上線，所以早期的問題不會連鎖影響到訂單。

資安與法規遵循從第一天起就納入設計。對國防客戶來說，稽核軌跡的完整性與以角色為基礎的存取控制，是不能妥協的。我們清楚定義了存取角色，並追蹤核准軌跡。資料落地問題及早確定：所有資料都留在阿拉伯聯合大公國（UAE）境內，符合國防產業的規範。這在一開始讓我們稍微慢了下來，卻避免了日後更嚴重的問題。

訓練很務實：簡短的課程、有針對性的教材、現場示範與操作影片，持續了數週與數個月，而不是一次完成。起初的採用並不完美。穩定的支援與看得見的好處，克服了早期的遲疑。轉捩點出現在團隊在真實情境中使用這些工具，並發現他們拿回來的資料是正確的時候。

成果	改變了什麼
報價回覆時間	平均縮短 35%；許多交易省下數小時，複雜的交易則省下數天
組態正確性	驗證規則在錯誤抵達工程部門之前就加以防止
稽核準備度	法規遵循檢查不再需要臨時趕工
跨團隊一致性	業務、客服與營運使用同一份客戶紀錄

35% 的縮減並非第一週就發生。早期的週期仍然涉及釐清與更正。一旦產品規則與定價邏輯趨於一致，報價就加快了。業務代表不再追著核准跑，也不再修正被重複使用的範本。這些步驟由系統處理。

對齊比技術更重要。 技術建置是比較容易的部分。讓各團隊信任單一事實來源、並停止維護自己的紀錄，才是比較困難的。這意味著，在要求人們依賴資料之前，先讓他們看到資料是可靠的。

整合的細節比功能更重要。 從 CPQ 到 SAP SD 的整合，才是讓整套系統有價值的地方。一個獨立的 CRM，加上獨立的報價，再加上人工輸入訂單，各自都只會有一點幫助。摩擦在它們之間的連接處消失。

支援與訓練讓它站得住。 部署完就丟下，不算交付。上線之後，訓練持續了數週與數個月，而那段時期，正是採用是否紮根、或是否瓦解的關鍵。

這個架構依然成立：以 CRM 管理客戶紀錄、以 CPQ 做結構化報價、以 ERP 整合執行訂單。如果同樣的專案現在才開始，有三件事會改變。

整合平台。 SAP CPI 現在是 SAP Integration Suite 內的 Cloud Integration 功能，旁邊還有 API 管理、事件式整合與預建的整合內容。一條從 Dynamics 到 CPQ 再到 SAP SD 的流程，今天所需的設計時間會更少。我的 SAP Cloud Integration 指南涵蓋了這個平台。

SAP 自己的 CRM 會列入短名單。 在以 SAP SD 為後端的情況下，新的專案應該拿現在已內建 Joule 的 SAP Sales Cloud，與 Microsoft Dynamics 做比較。在這個案例中，因為原本就熟悉，Dynamics 是正確的選擇。答案仍取決於功能與整合偏好，但 SAP 原生的選項，比以前更有說服力。我的適用於 SAP 的 CRM 系統比較涵蓋了這些選項。

美國聯邦範圍需要不同的託管模式。 這位客戶不需要，但在美國有聯邦業務的國防公司，會考慮 SAP National Security Services（SAP NS2）。2025 年，它取得了暫行授權，可在 FedRAMP+ Impact Level 5 運行 S/4HANA Cloud Private Edition 與 SAP BTP，且僅限美國境內營運。

國防特有的要求（稽核軌跡、以角色為基礎的存取控制、報價的版本控管、資料落地），不論平台世代為何都適用。關於更廣泛的法規遵循全貌，請參閱我寫的公部門的 SAP 法規遵循指南。

為什麼選擇 Microsoft Dynamics，而不是其他 CRM 平台？

它能管理完整的客戶生命週期，從潛在客戶到商機，再到售後互動，並能處理國防銷售漫長、複雜的交易週期。它與 Outlook 和 Teams 的契合度，有助於採用，而團隊對它的熟悉，進一步降低了門檻。

對一個法規遵循要求繁重的客戶來說，存取控制、稽核日誌、彈性與擴展空間，是另外幾項決定性的因素。

Experlogix CPQ 扮演什麼角色？為什麼需要 CPQ？

國防產品有複雜的組態規則。一份價目表，無法涵蓋產品變體、法規遵循要求與客戶專屬條款之間的交互作用。沒有 CPQ，每份報價都得仰賴製作者知道這些規則。

Experlogix 把這些規則放進報價工具。業務代表在建立報價時就能得到驗證回饋，而不是幾天後才收到工程部門的更正。錯誤被移到上游，在那裡修正的成本很低。

SAP SD 如何與 CRM 及 CPQ 整合？

SAP CPI 擔任中介軟體。Experlogix 中一份核准的報價，會觸發一個流程，在 SAP SD 中以正確的品項明細、定價與客戶資料建立訂單。CPI 也讓客戶與訂單資料，在 Dynamics 與 SAP 之間保持同步，並以驗證規則防止資料不一致。

以前，是由人把每一份核准的報價手動複製進 SAP。自動化消除了重複輸入的錯誤，並建立了從核准到訂單的乾淨稽核軌跡。

導入期間最大的挑戰是什麼？

首先是資料品質。各部門的客戶資料不一致，有重複與缺漏的欄位，必須先清理，Dynamics 才能成為事實的唯一來源。

其次是整合對應，尤其是三套系統之間的產品組態與定價。第三是讓業務、工程、IT 與財務對齊，特別是在流程某些部分的負責歸屬改變的時候。

資安與法規遵循是如何處理的？

從第一天起就內建。每個元件都必須符合內部資安政策與國家法規。以角色為基礎的存取控制，限制誰能看到並修改哪些紀錄。完整的稽核軌跡涵蓋報價、核准與資料變更。所有資料都留在阿拉伯聯合大公國境內，符合國防產業的規範。

因為設計是從這些要求出發的，所以法規遵循審查來臨時，資料早已是正確的形式。

導入花了多久？

大約六到八個月，分階段進行。它從聚焦於 CRM 與 CPQ 的試行開始，在取得回饋之後擴展到各部門，並在上游系統穩定之後，於中途加入 SAP SD 整合。訓練、支援與調校貫穿始終。

這個模式能套用到其他國防或製造公司嗎？

可以，只要銷售週期長、產品可配置、且需要法規遵循文件：航太、工業設備，以及任何報價在發出之前需要工程驗證的企業。

具體用哪些工具，不如整合邏輯重要。核准的報價必須不需重新輸入就流入 ERP，而客戶紀錄必須是單一事實來源。