SAP 整合平台：工具、授權與情境

把 SAP 整合進更大的系統環境，感覺就像在解一道拼圖，而且有幾片怎麼也放不進去。不同的工具、平台與資料格式，全都在爭奪注意力。整合選項實在太多，SAP Integration Suite 只是其中之一，每一個都說自己最適合，難免讓人不知所措。我看過團隊花了好幾週比較平台，最後才發現漏掉了很基本的東西，像是授權的影響，或系統在高負載下的延遲。

所以這個頁面想把事情講得更清楚。也許談不上完全清楚，但足以讓您有信心做出選擇。我從實務角度來看 SAP 整合平台：

哪些工具實際上能夠搭配得好
間接授權可能在哪裡絆倒您
SAP Integration Suite、CPI、PI 與 BTP 之間到底怎麼比較
什麼時候第三方工具比 SAP 自家工具更合適

沒有一個答案適用於所有專案。但只要把使用情境釘死，正確的整合路徑通常就會變得明顯。至少，這是我的期待。

1. SAP Integration Suite 簡介

SAP 導入很少只是把 SAP 設定好而已。更常見的情況，是讓 SAP 與其他一切協同運作：舊有系統、雲端應用程式、資料庫，以及企業多年來依賴的各種自建工具。

整合就是在這裡變得關鍵。它既可以把整個系統環境維繫在一起，也可能悄悄製造摩擦，直到出事才有人注意到。

實務上，整合往往被低估。團隊把重心放在功能、流程設計與測試上。到了後期，才有人發現：

關鍵資料無法即時同步
API 的用量上限早在幾週前就已觸頂
授權成本因間接使用而剛好翻倍
所選的中介軟體撐不住高負載下的資料量

這些事一開始並不總是顯而易見。但它們最終會影響時程、預算，甚至法規遵循。

這個頁面從這個角度來看 SAP Integration Suite：它們在專案實務中真正如何運作、解決哪些問題，以及風險通常藏在哪裡。

開始您的導入評估 SAP 整合

2. SAP 專案中常見的整合情境

SAP 專案通常不是從一張白紙開始。它們從一堆既有系統開始：有些文件齊全，有些則幾乎沒人搞得懂。整合必須把這一切理出頭緒，而且往往沒有太多延誤的餘地。

大多數系統環境中，都會出現幾種固定的模式：

SAP 到非 SAP 的連接。仍在使用的舊 ERP、CRM 或自行開發的應用程式。
混合式架構。雲端服務與地端系統並存，並試圖保持同步。
即時與批次流程。快是好事，但可靠往往更重要。
API 驅動與中介軟體架構。視情況，有時兩者並用。

像 SAP Integration Suite 這類工具，就是為了處理其中許多模式而設計，尤其是在混合式或以雲端為主的環境。但工具本身只是解決方案的一部分。

把 SAP 連接到外部平台，聽起來常常很簡單，直到格式、安全或時序出來擋路。我看過團隊為了一點小小的不相容，卡了好幾天。一邊講 REST，另一邊堅持要用平面檔案（flat file）。

混合式架構一開始看起來很有彈性。實際上，它們通常是由一堆例外拼湊而成。有一個服務即時推送資料，另一個卻還靠每晚的排程作業。

在規劃階段，即時整合對每個人都有吸引力。但只有在兩個系統都撐得住時，它才行得通。情況並不總是如此。

中介軟體提供結構，API 提供速度。要選哪一個，與其說取決於偏好，不如說取決於現有的架構，以及團隊實際上管得動什麼。

值得考慮的跨應用程式整合情境

1. SAP 與非 SAP 的整合

SAP 經常需要與 Salesforce、Oracle 或產業專用工具等平台連接。這些整合確保關鍵業務系統與流程之間的連續性。

讓 SAP 與第三方平台之間能進行結構化的資料交換
涉及驗證、欄位對應與轉換層
協助在 SAP 推行期間保留既有的業務流程

2. 混合式環境（地端／雲端）

多數 SAP 客戶都在混合式環境中運作。地端 SAP 系統與雲端平台並存，使整合成為維持資料一致性與業務敏捷性的必要條件。

將 SAP ECC 或 S/4HANA 與 SuccessFactors、Ariba 等雲端產品連接起來
橋接不同的通訊協定與安全模型
需要健全的治理，以避免延遲與同步問題

3. 即時整合與批次整合

要在即時整合與批次整合之間做選擇，取決於系統能力、資料量與業務需求。並非所有流程都同樣受益於即時資料同步。

即時整合適合訂單建立或庫存更新這類交易
批次整合更適合價格、主檔資料或歷史資料載入等大型資料集
多數環境兩者並用，視流程的關鍵程度而定

4. 以 API 為基礎的整合

以 API 為基礎的整合，讓應用程式能以輕量的通訊協定直接溝通。它們非常適合雲原生服務與現代化的開發環境。

非常適合將 SAP 與行動應用程式、入口網站或微服務連接
部署較快，但需要嚴謹的版本管理與安全處理
常與 SAP API Management 及 OData 服務搭配使用

5. 以中介軟體為基礎的整合

中介軟體為 SAP 與多個系統之間的整合，提供一個集中的控制點。它透過流程編排、訊息佇列與資料轉換，協助管理複雜度。

用於多個系統與 SAP 互動的環境
提供集中的監控與錯誤處理
例如：SAP PI/PO、SAP Integration Suite、MuleSoft、Dell Boomi

6. 混合式整合做法

多數企業會結合 API 與中介軟體兩種策略。這種混合模式能配合系統限制、團隊技能與長期支援需求。

結合直接與受管理的整合方式
為未來的擴充或工具更換保留彈性
協助讓整合同時符合技術與業務上的優先順序

3. SAP Integration Suite 概覽

談到 SAP 整合時的選擇，選對 SAP Integration Suite，比多數團隊預期的更重要。這個決定不只關乎功能與速度，還會影響時程、支援模式，甚至授權。我看過專案卡住，不是因為整合失敗，而是因為平台不符合業務的運作方式。

SAP 提供多種整合選項：有些較舊、有些較新，還有一些彼此重疊的程度超出一般人的想像。關於該用哪一個工具，常有爭論。當然，這要看情況：看您要連接什麼，看資料需要怎麼流動，看團隊熟悉什麼。

沒有任何一個工具能涵蓋所有需求。每一個都有取捨。但只要了解每個工具最適合用在哪裡，整體的全貌就會開始變得合理。

以下快速整理最廣泛使用的 SAP 整合平台，依據的是它們在真實專案中的實際應用方式，而不只是 SAP 的行銷說法。

SAP 整合平台

1. SAP PI / PO（Process Integration / Orchestration）

多年來，PI/PO 一直是地端 SAP 整合的標準。它處理訊息轉換、工作流程與各種通訊協定轉換。雖然可靠，但在變化較快的環境中顯得有點笨重。儘管如此，在處理複雜的後端邏輯時，它還是能把事情做完。

非常適合 SAP 對 SAP 以及舊系統的整合
支援 IDoc、BAPI、RFC、SOAP 等
常用於以 ECC 為基礎或混合式的架構

2. SAP CPI / Integration Suite

SAP CPI 的適應性更高，是為雲端優先與混合式環境而設計。它更容易上手，尤其對剛接觸 SAP 的團隊。預建的 iFlow 有幫助，不過真正的客製化仍然需要時間。對多數新的 S/4HANA 專案來說，這通常是預設的選擇。

支援雲端與混合式整合
包含可重複使用的內容套件與轉接器
屬於 SAP Integration Suite 授權模式的一部分

3. SAP API Management

它更著重於治理，而不是實際搬移資料。API Management 協助您控制誰可以在什麼條件下存取什麼。把它想成一道大門，會比想成運貨車輛更貼切。當您要把 API 開放給合作夥伴或內部使用者時，它很有用。

用於流量控管、節流與驗證
在把 SAP API 開放給外部應用程式時很有用
通常與 CPI 或其他後端工具互補

4. SAP BTP 整合服務

這是一個範圍更廣的傘形概念，涵蓋 CPI、API Management、事件處理等。它提供一個集中管理工具的地方，但各個工具本身的行為仍然相對獨立。價值在於把它們打包在一起，並鬆散地整合。

結合多個 SAP 整合元件
透過 SAP BTP cockpit 集中存取
適用於使用多種工具的整合環境

5. SAP Data Intelligence

Data Intelligence 用於資料需要在結構化的管線中跨平台流動的情況。重點更偏向分析，而不是交易。它把 SAP 與資料湖、機器學習（ML）工具，或其他不屬於日常流程的外部來源連接起來。

專注於跨平台的資料編排
可與分析及機器學習技術堆疊整合
最適合資料管線，不適合高頻交易

6. 選擇合適的工具

沒有哪個平台是唯一的「最佳」。合適的工具，取決於要整合什麼、整合的規模，以及需要多少彈性。有時候，這只是看您的團隊已經熟悉什麼。這一點也算數。

從使用情境出發，而不是從工具出發
評估授權、技能供給與支援模式
常常會同時並用不只一個工具

可搭配 SAP 的第三方整合平台

1. Dell Boomi

Dell Boomi 提供低程式碼的雲端平台，很適合需要快速部署與可重複使用整合的組織。它透過預建的連接器連接 SAP，並能有效處理即時與批次兩種工作流程。

低程式碼介面，加快導入
將 SAP 與雲端應用程式、CRM 及舊系統連接
適合有混合式需求的中型企業

2. MuleSoft

MuleSoft 常用於整合需求遠超出 SAP 的大型企業。它提供以 API 為導向的連接方式，以及豐富的開發者體驗。SAP 連接器很強，但可能需要在前期投入更多心力才能設定妥當。

API 優先的模式，讓服務設計更具彈性
用於將 SAP 整合進更廣泛的企業架構
更適合複雜或分散式的系統

3. Informatica

Informatica 在資料密集的環境中表現出色。以 ETL、主檔資料管理或分析為重點的整合，常會選用它。它支援與 SAP 直接整合，不過通常不像其他平台那麼著重即時性。

非常適合大量資料搬移與清理
常與 SAP 搭配，用於報表或 MDM 情境
適合 BI 環境成熟的組織

4. 何時使用第三方平台

有時 SAP 的原生工具並不適用，尤其是在多種系統並存的環境。第三方工具可能提供更好的連接器、更簡單的介面，或只是更符合內部既有的作法。

當團隊已經受過外部平台的訓練
當 SAP 只是更龐大架構中的一部分
當需要即時、低程式碼或進階資料整合

5. 授權與成本因素

各平台的授權差異很大。SAP 工具通常把整合功能打包進既有的訂閱中。第三方工具或許提供彈性，但定價模式可能隨著量或使用者數快速攀升。

依交易量與連接器數量評估成本
留意與既有已授權的 SAP 功能是否重疊
要考量總持有成本（TCO），而不只是授權費用

6. 整合的維護與支援

第三方平台可能需要不同的支援模式。有些有廠商的強力後盾，有些則高度仰賴內部技能。長期維護應該納入決策考量，而不只是看初期的設定速度。

檢查廠商的 SLA 與更新週期
把內部知識，或是否需要外部顧問，一併納入考量
規劃治理、版本管理與安全更新

4. 在 SAP Integration Suite 中選擇合適的元件

沒有完美的整合工具。在某個 SAP 專案行得通的做法，到了另一個專案可能徒增負擔。要在 SAP Integration Suite 中選對元件，取決於您面對的系統環境，以及您的整合將承受什麼樣的壓力：技術上的、營運上的，有時甚至是政治上的。

先依幾項準則縮小範圍：

系統環境：涉及多少個系統？全是 SAP，還是雲端與非 SAP 工具混合？
延遲需求：資料需要即時傳送，還是可以接受延遲？
擴充性：會經常加入新系統嗎？彈性是否比標準化更重要？
資料量：您每小時搬移的是幾筆資料，還是每分鐘數萬筆？

以下大致列出各平台與不同需求的對應：

SAP 對 SAP： PI/PO 或 CPI
雲端對雲端： CPI、MuleSoft、Boomi
API 管理： SAP API Management、MuleSoft
大量 ETL： Informatica、SAP Data Intelligence
複雜的流程編排： PI/PO、MuleSoft、BTP Integration Services

5. SAP Integration Suite 與 Oracle、Microsoft、Salesforce 的整合

在真實的 SAP 環境中，很少看到 SAP 單獨運作。許多環境都包含 Oracle、Microsoft 或 Salesforce 這類大型、對業務至關重要的平台。每一個都帶來自己的整合挑戰：有些屬於技術面，有些屬於結構面，還有些落在授權的灰色地帶。

1. SAP ↔ Oracle（ERP、HR、SCM）

SAP 與 Oracle 常在較大型的企業中並存。一個處理財務，另一個管理供應鏈或人資。要讓它們可靠地共享資料，一開始可能進展緩慢，尤其是當兩邊的資料模型差異超出預期時。

Oracle 的資料表通常需要透過 API 或暫存層對外開放
SAP 通常推送 IDoc 或使用 BAPI，需要進行轉譯
時序是關鍵：批次處理的時間窗口可能造成同步延遲
如果 Oracle 應用程式自動觸發 SAP 流程，間接存取的風險很常見

2. SAP ↔ Microsoft（Azure、Power Platform、M365）

Microsoft 與 SAP 的交會點，比多數人預期的多。無論是 Power BI 從 SAP 拉取資料，還是 Teams 顯示即時 KPI，這類連接都在增加。但整合需要謹慎設定。有些部分很順暢，有些就不那麼順了。

Azure Logic Apps 可以呼叫 SAP API，但認證資訊必須謹慎管理
Power Platform 提供連接器，但複雜的流程可能需要自訂函式
Microsoft 365（例如 Excel）常被用來離線編輯 SAP 資料，再同步回去。如果沒有追蹤，這種做法可能悄悄造成授權問題

SAP 與 Azure 的連線能力正在改善，但混合式模式仍然需要強健的驗證機制，尤其是涉及地端系統的時候。

3. SAP ↔ Salesforce（客戶資料、訂單、支援）

Salesforce 幾乎都是面向客戶的，SAP 則負責後端。要橋接兩者，通常是為了同步客戶資料、訂單狀態與服務歷程。

這類流程常使用 SAP CPI 或 MuleSoft
物件模型不同：Salesforce 較有彈性，SAP 較為嚴謹
Salesforce 的 API 呼叫頻率限制，可能讓大量同步停滯
如果 Salesforce 在沒有授權使用者的情況下觸發 SAP 交易，就有間接授權的風險

有時這些連接看起來很單純。但一旦量增加，或流程在專案中途改變，複雜度就會浮現。及早為這些例外情況做規劃，很少是白費力氣。

CPI 整合

6. 什麼是間接授權？

間接授權，指的是 SAP 以外的系統在幕後與 SAP 互動。沒有人直接登入 SAP，但業務流程仍然依賴它。常見的例子是 Salesforce 自動在 SAP 建立銷售訂單，而沒有任何 SAP 使用者碰過畫面。這也算數。

SAP 稱之為「間接存取」。這很重要，因為即使使用者完全沒看過 SAP，它仍被視為一個需要授權的事件。

為了管理這一點，SAP 推出了 Digital Access 模式，把重點從使用者轉移到單據。

一些典型的觸發情境包括：

第三方入口網站把訂單推送進 SAP
行動應用程式透過 API 查詢庫存水準
機器人（bot）在不登入的情況下更新客戶資料
CRM 即時從 SAP 取得價格

界線在哪裡，並不總是清楚。但只要 SAP 是在代替另一個系統處理某些事，就值得檢查一下。

7. 授權與法規遵循的考量（直接＋間接）

SAP 專案中的授權問題往往浮現得很晚，有時是在整合決策已經做完之後。但它很重要，比多數人預期的更重要，尤其是當第三方系統在沒有具名使用者的情況下，開始讀取或寫入 SAP 時。

核心問題往往歸結為直接存取與間接存取。直接存取很單純：一位具名的 SAP 使用者登入、觸發一個流程，這個動作就已經取得授權。但間接存取發生在外部系統（Salesforce、自建入口網站，甚至是機器人）在背景與 SAP 互動時。依 SAP 的條款，這仍然可能被算作使用。

為了處理這一點，SAP 推出了 Digital Access 模式。它不再依使用者收費，而是計算透過間接存取所建立的特定單據類型的數量，包括銷售訂單、發票或物料異動等。理論上，這樣比較清楚。實務上，仍然有灰色地帶。

法規遵循的風險，常常來自出於善意的自動化。例如：

不經使用者登入就從 SAP 取得價格的行動應用程式
自動在 SAP 建立客戶資料的 CRM
每小時查詢庫存水準的排程工具

這些全都有用。但如果沒有妥善追蹤與申報，可能引發授權風險。

有辦法管理成本。SAP 針對轉換到以單據為基礎的授權，提供 Digital Access Adoption Program（DAAP） 的獎勵。有些企業也會導入使用量監控工具（SAP Passport 或外部的日誌記錄工具），以追蹤風險所在。

稽核又是另一回事。稽核可能是技術面的、商務面的，或兩者兼具。有些稽核可以預期，有些則不然。無論如何，主動因應的成本，往往比被打個措手不及來得低。

1. Salesforce 在 SAP 中建立銷售訂單

業務人員在 Salesforce 輸入交易，Salesforce 再自動把訂單資料送進 SAP。沒有任何 SAP 使用者登入，但後端單據卻被建立了。

問題所在： 銷售訂單是透過間接存取產生的，屬於 SAP 數位授權的範疇。
因應方式： 採用 SAP 的 Digital Access 模式，將這些計為單據，或改為透過具名 SAP 使用者的工作流程來觸發。

2. 自建入口網站讀取 SAP 價格

面向公眾或合作夥伴的網站入口，顯示透過 API 從 SAP 取得的即時價格。過程中沒有使用任何 SAP 驗證。

問題所在： 價格資料的存取繞過了具名使用者，使 SAP 後端暴露在外，且無法追溯。
因應方式： 讓存取經由 SAP API Management，並套用適當的使用者驗證或配額控管。

3. 行動應用程式查詢庫存可用量

倉儲團隊使用的行動應用程式，不必直接登入 SAP，就能查詢 SAP 的即時庫存。

問題所在： 資料是以間接方式存取的，視量或頻率而定，可能引發授權責任。
因應方式： 為行動使用者取得授權，或確保存取符合以單據為基礎的授權門檻。

4. 電子商務平台建立發票

線上購買會自動將發票過帳到 SAP。整個流程完全是系統對系統，沒有任何 SAP 使用者參與。

問題所在： 依 SAP 的 Digital Access 模式，以間接方式建立發票，屬於需要授權的事件。
因應方式： 將發票單據納入您的數位存取授權計數，並監控量的趨勢。

5. 人資系統將員工資料寫入 SAP

第三方人資軟體管理員工主檔資料，並透過批次作業更新 SAP HCM。

問題所在： 在沒有已授權 SAP 使用者的情況下建立主檔資料，視資料的處理方式而定，可能不合規。
因應方式： 向 SAP 釐清這些是否被視為需要授權的單據，並實施使用量追蹤，或改為經由具名使用者路由。

6. BI 工具定期從 SAP 擷取報表

Power BI 或 Tableau 這類報表平台，依排程透過 OData 或 JDBC 連接到 SAP 資料表，悄悄地擷取資料。

問題所在： 如果沒有經過驗證，或使用者未取得授權，頻繁的資料擷取可能違反存取政策。
因應方式： 讓存取經由已授權的報表使用者，或使用經 SAP 認證、能妥善追蹤授權的分析連接器。

8. 我能怎麼協助您？

25 年的 SAP 與數位轉型經驗，讓我看過專案從啟動到上線的全過程，也看過沒有人願意談的混亂中段。有時我從一開始就帶領專案。有時，我是在情況走偏時被找來穩住局面。

無論哪一種，我的角色都一樣：把業務真正需要的，與系統實際能交付的連接起來。不說行話，不灌水。您在這裡看到的不是理論，而是多年在第一線、在真實壓力下解決真實問題所形塑出來的內容。

需求蒐集

9. 幾項整合最佳實務

專案初期，整合通常意味著讓東西動起來：把資料從一個系統搬到另一個系統，勾選幾個項目，然後繼續前進。但真正的挑戰出現在後面，當某個地方悄悄壞掉，或者沒有人記得這個介面當初是怎麼設定的。

最佳實務不是要遵守僵硬的標準，而是要降低可以避免的風險。這可能意味著採用更強的驗證，或在規模擴大之前先建立監控。有時，它只是意味著比當下覺得必要的程度，多寫一些文件。

有幾件事，有助於讓整合長期保持健康：

使用 OAuth2、SAML 或 X.509 等安全協定
即使流程看起來很簡單，也要建立監控
建立可重複使用或可擴充的 iFlow 或 API
記錄運作方式，以及失敗時該怎麼做

這些步驟很少是緊急的。但日後，它們能省下數小時，有時是數天。

1. 保護每一個整合點

安全問題往往處理得很晚，通常是在上線前夕。但那正是最難修正的時候。請依情境使用 OAuth2、SAML 或憑證。如果使用的是靜態認證資訊，就要妥善記錄並輪替。別只是把它們放在設定檔裡，然後期盼沒有人忘記。

使用端對端加密，而不只是對外加密
依資料風險選擇驗證協定
及早測試權杖的到期與更新

2. 從一開始就做好監控

監控常常是在事故發生之後才補上。但它在任何東西壞掉之前就已經存在時，效果最好。哪怕只是最基本的日誌記錄也有幫助。重點不在花俏的儀表板，而在於知道什麼東西失敗了、何時失敗、為什麼失敗。沒有這些，即使是小問題，也可能要花上數小時才能追蹤到。

針對失敗與逾時設定警示
記錄回應時間與重試次數
如果有現成的 SAP 監控機制，就加以利用

3. 為重複使用而設計，而不是為了一時

用一個快速、寫死的修補來解決眼前問題，很誘人。但每一次的一次性做法，日後都會增加摩擦。可重複使用的 iFlow、共用的轉換邏輯與參數化的輸入，在流程演進時能省下時間，而流程幾乎一定會演進。

盡可能使用範本
避免把業務規則放在對應步驟中
把邏輯與傳輸層分開

4. 以維運為出發點撰寫文件

文件往往止步於設計階段。但支援團隊需要的不只是圖表。他們需要知道，當端點掛掉或欄位缺失時會發生什麼事。好的文件會在工單被開出來之前，就回答這些問題。

包含重試邏輯、失敗處理與版本資訊
說明對上游與下游系統的假設
隨著流程改變，持續更新文件

5. 指派明確的負責人

有些整合已經運行了好幾個月，才有人發現沒有人負責。它出問題時，每個人都以為別人在盯著。要避免這種情況。指派負責人，即使是非正式的。光是這一步，就比多數技術修補更能減少停機時間。

為每個流程或介面界定責任歸屬
確保負責人能存取日誌與工具
把負責人資訊納入新人上手與交接文件

6. 為變化而建，而不只是為上線

介面不是靜態的。欄位會變，API 會改版，量會成長。如果流程太僵硬，即使是小小的改變也會讓它壞掉。一開始就要為調整預作規劃，即使目前的需求看起來很穩定。

對對應與設定進行版本控管
清楚記錄已知的限制與約束
在發版週期中檢視整合流程

10. 總成本與投資報酬率的考量

整合專案常常從技術目標開始：連接系統、同步資料、讓東西跑起來。但在這底下，成本扮演的角色比多數人意識到的更大。不只是前期的授權，還包括日後才浮現的那種成本：當工作負載擴大、需求轉變，或某個權宜之計變成永久做法的時候。

像 SAP CPI 這類雲端工具，在初期可能看起來更划算：不用硬體，設定更快。但在依用量計價的模式下，成本會隨著量而攀升。像 PI/PO 這類地端選項，價格比較穩定，但需要負擔基礎架構的開銷。

再來是第三方平台。每一個都有自己的授權模式：有些依使用者收費，有些依交易或連接器收費。累積起來就很可觀。

所以，從投資報酬率的角度看整合，要問的不只是「現在要花多少錢？」，而是要往前看：這會如何擴展？需要改變時，誰來付錢？

1. 雲端與地端的成本

像 SAP CPI 這類雲端平台提供更快的設定與更低的基礎架構成本，但價格常隨用量增加。像 PI/PO 這類地端工具，前期投資較高，但長期可能提供成本的穩定性，尤其是在硬體已經就位的情況下。

雲端：訂閱制，通常依訊息或連線數計費
地端：以資本支出（CAPEX）為主，經常性授權成本較低
價格取決於系統量與 IT 規模

2. SAP CPI 授權的影響

SAP CPI 採用分級、依用量計價的模式。您依訊息量與吞吐量付費。在低到中等用量的情境下是可預期的，但流量大或流程未經最佳化時，成本可能急遽上升。

起始級距通常約為每月 1,000 至 2,000 歐元
大量訊息或非標準轉接器會產生額外費用
每月追蹤用量，主動管理成本

3. 第三方中介軟體的定價

MuleSoft、Dell Boomi 與 Informatica 的定價模式各不相同：依連接器、依使用者，或依交易計費。基本價格可能看起來負擔得起，但規模擴大時，常會碰到觸發新費用的上限。

MuleSoft：授權＋API 用量＋核心套件（約每年 1.8 萬美元以上）
Boomi：依整合流程、連接器或使用者級距計費
Informatica：成本取決於 ETL 量與平台服務

4. 長期的變更成本

初期的設定成本只是故事的一部分。變更（新的端點、更新的對應，或業務規則的轉變）可能帶來額外的授權或開發成本，尤其是在僵化的環境中。

在複雜的環境中，預估每年的變更成本為 15% 至 30%
模組化程度較高的平台，往往能降低變更的摩擦
客製化可能需要擴充授權或顧問服務

5. 支援與維護成本

成本預估時，支援常被忽略。SAP CPI 包含基本的支援級別，但回應時間與 SLA 各不相同。第三方工具可能提供更快的支援，但要付出代價，或需要額外的服務合約。

SAP 的支援與既有的企業合約綁定
第三方工具的支援費，可能每年收取授權費的 15% 至 20%
內部支援需求可能隨系統複雜度增加

6. 評估設定之外的投資報酬率

真正的投資報酬率，包含長期的持有成本，而不只是導入。較便宜的平台可能缺乏彈性，成本較高的工具則可能在日後減少停機時間或變更的工夫。要以整個生命週期來評估，而不只是上線。

把授權、維護、支援與變更成本的總和都納入考量
以 2 至 3 年的期間來估算投資報酬率，而不只是專案階段
把整合失敗或延遲的成本，也納入潛在風險

常見問題

許多客戶在初次考慮 SAP 導入時，都會圍繞著同樣的問題打轉。

也許您自己也有其中幾個疑問：真正需要多久、可能要花多少錢，或系統上線後需要什麼樣的支援。這些都是合理的問題。

所以，與其讓您猜測，我整理了清楚而誠實的答案，幫助您更了解可以期待什麼，以及棘手的部分通常出現在哪裡。

歡迎聯絡我！

1. 什麼是 SAP CPI？

SAP CPI，也就是 Cloud Platform Integration，是 SAP Integration Suite 的一部分。它協助連接 SAP 與非 SAP 系統，主要用於雲端或混合式環境。可以把它想成中介軟體，但專為分散式環境打造。

它包含：

預建的整合流程（稱為 iFlow）
支援 HTTPS、SFTP 與 OData 等協定
可選擇自訂對應、撰寫腳本與路由

當從地端遷移到雲端，或第三方應用程式需要安全地與 SAP 溝通時，CPI 特別有用。

2. SAP 如何與 Salesforce 整合？

SAP 與 Salesforce 通常透過 API，或 SAP CPI、MuleSoft、Dell Boomi 這類中介軟體交換資料。

常見的使用情境包括：

同步客戶主檔資料
傳送訂單與發票明細
共享支援案件歷程或價格資訊

挑戰通常來自資料模型的差異，以及 Salesforce 端的 API 限制。謹慎的對應與節流是關鍵。

授權也可能是個疑慮。如果 Salesforce 在 SAP 中觸發動作，可能適用間接存取。

3. 什麼是 SAP 間接存取？

間接存取，發生在外部系統與 SAP 互動、而沒有使用者直接登入的時候。例如，入口網站或第三方應用程式透過 API 在 SAP 中建立銷售訂單。

SAP 認為這屬於其 Digital Access 模式下需要授權的行為，使用量依單據類型（訂單、發票等）追蹤。

這可能讓團隊措手不及。系統在背景安靜地運作，卻產生會引發授權風險的單據。

要管理這一點：

評估外部系統如何使用 SAP
監控單據的建立量
考量 SAP 以數位單據為基礎的授權架構

4. 哪一個 SAP 整合工具最好？

這取決於您要整合什麼、變動的頻率，以及由誰來維護。

雲端對雲端或混合式：SAP Integration Suite（CPI）
地端 SAP 對 SAP：SAP PI/PO
API 治理：SAP API Management
資料管線與分析：SAP Data Intelligence
更廣泛的企業整合：MuleSoft 或 Dell Boomi

多數環境會混合使用。何謂「最好」，更取決於適配度，而不是功能。

5. SAP 能與 Microsoft 和 Oracle 整合嗎？

可以，而且很常發生。

SAP ↔ Microsoft

Azure Logic Apps、Power Automate，或 Power BI 中的 SAP 連接器
常見用途：把 SAP 資料拉進 Excel、Teams 或儀表板

SAP ↔ Oracle

通常需要中介軟體（CPI、PI 或第三方）
使用情境包括財務、採購或人資整合

挑戰包括不同的驗證模型、時序不一致，以及某些情況下的授權問題。

6. 什麼是 SAP Integration Suite？

SAP Integration Suite 是 SAP 用來連接系統、應用程式與資料的雲原生平台。它包含 CPI、API Management、Open Connectors 與事件網格（event mesh）功能。

可以把它想成一個工具箱。有些部分是預建的，有些則可以設定。它是為雲端優先與混合式環境而設計的。

核心效益：

常見整合的預建內容
即時與批次處理
安全、監控與治理的工具

它被定位為 SAP 針對現代化環境的策略性整合層。

7. SAP CPI 正在取代 PI/PO 嗎？

在以雲端為主或混合式的環境中，是的：SAP CPI 是首選的方向。但 PI/PO 仍受支援並被廣泛使用，尤其是在以 ECC 為基礎的系統或地端架構中。

SAP 建議逐步轉移到 Integration Suite，但沒有強制切換。這取決於專案時程、系統路線圖與成本。

有些企業兩者並用，逐步導入 CPI。

8. SAP 如何處理 API 安全？

SAP 支援標準的安全協定：

OAuth2，用於以權杖為基礎的驗證
SAML，用於聯合身分
X.509 憑證，用於系統對系統的信任

Integration Suite 也提供 API 節流、配額執行與政策管理。多數團隊會把 SAP 的安全工具，與 Azure AD 或 Okta 這類企業身分提供者結合使用。

安全需求依情境而異，因此要及早規劃。

9. 什麼因素決定 SAP 整合的成本？

有幾個因素會影響成本：

工具類型（雲端或地端）
交易或訊息的量
介面與系統的數量
授權模式（例如 CPI 依用量計價）

例如，SAP CPI 的授權一開始可能看起來不高，但會隨著量快速增加。第三方中介軟體則可能依連接器或使用者收費。

估算時，一定要把支援與變更成本也算進去，而不只是授權費用。

10. 如何監控 SAP 整合？

SAP Integration Suite 內建監控儀表板、日誌與追蹤工具。您可以：

即時檢視訊息日誌與錯誤
追蹤效能與延遲
為失敗或緩慢的流程設定警示

對於 PI/PO 這類地端系統，監控是在 Integration Engine 中處理，或透過 SAP Solution Manager 進行。

關鍵在於及早建立監控。等到出事才處理，通常比事先規劃花更多錢。

請告訴我您目前在做什麼。

30 分鐘的通話。請您說明專案、需要做的決策或遇到的問題。我會直接告訴您我能不能幫上忙；如果不能，也會告訴您誰可能幫得上。

討論您的專案

SAP Integration Suite：工具、授權與實際情境

請告訴我 您目前在做什麼。

請告訴我您目前在做什麼。