SAP BPC：何時行得通、何時行不通，以及接下來怎麼走

SAP BPC（Business Planning and Consolidation，業務規劃與合併）在 2026 年仍受支援，但能支援多久，取決於您使用的版本。BPC for Microsoft 已於 2026 年 6 月 30 日退出主流維護。BPC 10.1 for NetWeaver 將在 2027 年底退出。BW/4HANA 與 S/4HANA 版本則規劃支援到 2040 年。對於新的工作，SAP 把規劃導向 SAP Analytics Cloud（SAC），把合併導向 S/4HANA Group Reporting。這份指南寫給正在決定要保留、重新設計還是取代 BPC 的 CFO、財務會計主管與財務系統負責人。請先在下表找出您的版本，再用決策指南訂出下一步。

多數 BPC 導入都把基本功做對了。系統上線。報表自動化。資料依固定時程送到財務手上。

然後幾個月後，財務團隊又重新建起了以前用的離線模型。

原因很少是軟體本身，而是部署方式。範本太僵硬，不符合業務的運作方式。合併邏輯技術性太強，沒有人敢碰。預測更新要靠 IT。報表在送到領導層面前，還是要人工調整格式。BPC 最後變成了疊在它本該取代的流程之上的報表層，投資報酬永遠沒有到來。

SAP 的 2025 年 10 月 BPC 策略更新逐版本說明了維護的情況：

BPC 版本	維護	對您的意義
BPC 10.1 for Microsoft	主流維護已於 2026 年 6 月 30 日結束；僅提供客戶專屬維護	現在就規劃退場。SAP 建議移轉到 SAP Business Data Cloud
BPC 11.1 for BW/4HANA 2.0	已於 2025 年 12 月 31 日結束	升級到 BPC 2021 或進行移轉
BPC 10.1 for NetWeaver（BW 7.5）	主流維護至 2027 年 12 月 31 日；可選的延伸維護至 2030 年 12 月 31 日	這是一個時間窗口，不是終點。在 S/4HANA 規劃期間做決定
BPC 2021 for BW/4HANA 2021 與 2023	至 2030 年 12 月 31 日，並承諾後繼版本至少延續到 2040 年	只要 BW/4HANA 仍留在您的架構中，就能再用好幾年
BPC 10.1 optimized for S/4HANA	與每個 S/4HANA 版本同步，至少到 2040 年	可與 S/4HANA 地端部署版或私有雲版並行使用

1. 2025BPC 11.1 for BW/4HANA 2.0 已結束12 月 31 日。升級到 BPC 2021 或進行移轉
2. 2026BPC for Microsoft 退出主流維護6 月 30 日。僅提供客戶專屬維護
3. 2027BPC 10.1 for NetWeaver 退出主流維護12 月 31 日。之後可選擇延伸維護
4. 2030NetWeaver 延伸維護結束BPC 2021 也支援到這一年，之後由後繼版本接手
5. 2040BW/4HANA 產品線與 BPC for S/4HANA計畫至少到 2040 年

來源: SAP BPC 策略更新，2025 年 10 月

另外還有兩項改變值得注意。第一，SAP 在 2025 年推出了 SAP Business Data Cloud，BPC 10.1 for NetWeaver 或 BPC 2021 可以連同 BW 一起搬進其私有雲版。這是搬遷，不是重新設計。第二，SAP 在規劃領域的 AI 投入都放在 SAC 上。Joule 的分析洞察自 2025 年中起正式推出，使用 SAC 的「just ask」功能回答自然語言的問題。BPC 沒有對等的功能。

對新專案來說，預設的架構是以 SAC 做規劃、以 S/4HANA Group Reporting 做法定合併，並以 Universal Journal 作為單一紀錄。除非有特殊理由，例如 Group Reporting 尚未能妥善處理的持股結構，新的導入很少會選擇 BPC。

對既有客戶來說，問題在於時機。在 S/4HANA 專案期間進行移轉，通常比日後另外做一個財務專案便宜，因為資料、設計與測試工作是共用的。

我的看法：BPC 仍然堪用、仍受支援，在多實體合併方面，也仍有 SAC 比不上的做法。它是針對特定時間窗口的戰術性選擇，而不是長期的平台賭注，除非您已決定投入 BW/4HANA 或 S/4HANA 地端部署。即使執行還在兩年之後，現在就該規劃路線圖。

BPC 在市場上已超過 20 年。它靠結構化的結帳週期、嚴格的稽核法遵，以及跨多個實體的法定合併，贏得了使用者。它有四種平台變體：

1. BPC Standard（NetWeaver 或 BW/4HANA）：資料、邏輯與安全性都在 BPC 內。更容易由財務自行負責。
2. BPC Embedded：建立在 BW 物件之上。與營運資料的整合更緊密，但您需要 BW 技能來維護模型。
3. BPC for Microsoft：SQL Server 搭配 Excel 與 .NET 前端。自 2026 年 6 月起已退出主流維護。
4. BPC optimized for S/4HANA：執行於 S/4HANA 技術堆疊上，從 Universal Journal（ACDOCA）讀取實績，並可將規劃資料寫入規劃表（ACDOCP）。即時，不需複製資料。

SAC Planning 在以驅動因子為基礎的規劃與跨部門協作上，處理得比 BPC 好。但它並不原生支援法定合併。對於有多層持股、公司間交易沖銷，以及受稽核控管的結帳週期的集團，BPC 仍有 SAC 開箱即用做不到的功能。

對 S/4HANA 客戶來說，合併的路徑是 Group Reporting，不是 BPC，也不是 SAC。Group Reporting 假設來源資料在 S/4HANA 內是乾淨流動的。如果您的資料不乾淨，移轉就會碰上與任何其他合併工具相同的資料問題。我的 SAP FICO 指南談到了餵給它的財務設計。

BPC 在四種情況下仍保有其地位：

1. ECC 客戶，以及尚未準備好採用 Group Reporting 的分階段 S/4HANA 移轉
2. 持股層級複雜、需要少數股權計算的合併
3. 稽核軌跡與資料鎖定不容妥協、法遵要求高的環境
4. 合併需要 SAC 無法表達的自訂業務規則的混合式環境

從 BPC 獲益最多的財務團隊，是深入運用四項功能，而不是想用遍所有功能。

結構化的規劃範本。 損益表、成本中心與營收的輸入表單，與規劃日曆連動，附有驗證、明確的負責人與期限，全部都在 Excel 中完成。使用者專注於數字，而不是結構。

法定合併與公司間交易沖銷。 持股、幣別換算、沖銷與少數股權。這是 BPC 勝過多數替代方案的地方。在有合資企業或多層持股的集團中，BPC 透過腳本邏輯、業務規則與維度設計所提供的控制力，很難被複製。

資料鎖定與稽核控管。 已提交並通過驗證的資料會被鎖定。稽核軌跡記錄誰在何時、為何改了什麼。介面不是最漂亮的，卻正是內部控制與外部稽核人員所需要的。

版本管理。 預算、預測 1、預測 2 與實績並排。要試算營運費用刪減 5% 或營收短少 12%，不必重建模型，也不必等 IT。

部署模式決定了誰擁有規劃模型、資料移動得多快，以及在情況改變時財務能多快回應。多數 BPC 問題，都始於一個做得太快的架構決策，往往是依夥伴的偏好，而不是依財務的運作方式。

部署模式	運作方式	最適合
BPC Standard	資料與邏輯都在 BPC 內；維護不需要 BW 技能	想要掌控、不想依賴 IT 的財務主導團隊
BPC Embedded	使用 BW 物件；邏輯變更需要 BW 或 ABAP 技能	具備深厚 BW 技能、由 IT 主導的環境
BPC for Microsoft	SQL Server、Excel 與 .NET 前端	僅限既有使用者，並正在規劃退場
BPC optimized for S/4HANA	在 Universal Journal 上即時規劃；不需複製資料	成熟、穩定且採用標準規劃邏輯的 S/4HANA 環境
BPC 與 SAC 混合式	以 BPC 處理合併與規則；以 SAC 處理儀表板與情境	一邊移向雲端、一邊保留結構化合併的組織

混合式架構，是許多團隊悄悄最後落腳的做法。當角色分開時它才行得通：BPC 負責規則型預測、法遵與合併；SAC 負責情境與使用者輸入。沒有這道界線，兩個工具都承載規劃邏輯，您就會有兩個版本的事實。我的 SAP Analytics Cloud 指南談到了 SAC 的部分。

依您的平台與 S/4HANA 計畫來選擇路徑：

1. 使用 BPC for Microsoft。 進行移轉。主流維護已經結束。要選擇的是目的地：如果 S/4HANA 即將到來，就選 SAC 加 Group Reporting；如果不是，就選另一套合併產品。
2. 使用 BPC 10.1 NetWeaver，且兩年內會進行 S/4HANA 移轉。 把 BPC 的決定併入 S/4HANA 專案。在設計階段，而不是在上線之後，就評估以 Group Reporting 做合併、以 SAC 做規劃。
3. 使用 BPC 10.1 NetWeaver，且 2028 年之前沒有 S/4HANA 計畫。 重新設計有問題的部分，為延伸維護編列預算，並訂下重新檢視的日期。
4. 使用 BPC 2021 for BW/4HANA，並繼續使用 BW/4HANA。 保留它。修正負責人與範本設計。如果您想把 BW 移出自己的資料中心，可以考慮 Business Data Cloud 的私有雲版。
5. 已經使用 S/4HANA。 針對您的合併需求測試 Group Reporting。只有在 Group Reporting 有明確缺口之處，才保留 BPC optimized for S/4HANA。

SAP BPC 對比 Oracle FCCS

Oracle Financial Consolidation and Close（FCCS）是純雲端，屬於 Oracle 的 EPM Cloud。它部署較快，標準合併功能強大：幣別換算、公司間交易沖銷與法定報表邏輯。它吸引精簡的團隊。

當業務需要超出標準合併的自訂邏輯時，它就開始受限。BPC 對合併規則提供更多控制，代價是需要 SAP 技能來維護。如果財務想掌控每一塊邏輯，而且具備那些技能，BPC 較占優勢。如果見效速度與現代化介面更重要，FCCS 是一條正當的路。

SAP BPC 對比 Anaplan

Anaplan 是雲端原生，而且速度快。財務與供應鏈團隊不需 IT 就能自行建立模型。

多年來它的弱點是合併。這在 2024 年 Anaplan 收購 Fluence Technologies以補上財務結帳與合併之後改變了。對於結帳週期複雜且需要稽核的集團，在仰賴它之前，請先確認這項整合成熟到什麼程度。當您要從零開始建立跨部門的預測模型時，Anaplan 最強。

SAP BPC 對比 OneStream

OneStream 把合併、規劃與報表統一在一起，稽核與安全性扎實。當合併與規劃分散在多個工具中時，它就會被提出來。

它導入起來不一定比 BPC 快，而且上線後，負責人往往落在進階使用者或專職管理員身上。如果您使用 SAP ERP，BPC optimized for S/4HANA 可避免資料複製並即時規劃。對於尚未使用 S/4HANA 的公司，BPC 能維持其地位的時間，可能比供應商的說法更長。

三項比較的模式都一樣。工具失敗，是因為沒有人問上線後誰來維護模型，而不是因為缺少功能。

SAP 中的 BPC 代表什麼？它做什麼？

BPC 代表 Business Planning and Consolidation（業務規劃與合併）。它是 SAP 用於規劃、預算、預測與財務合併的工具。

它可以在 NetWeaver 或 BW/4HANA（Standard 或 Embedded）、S/4HANA 技術堆疊，或 Microsoft SQL Server 上執行。Standard 由財務主導，較容易維護；Embedded 把邏輯綁在 BW 物件上，需要更多技術技能。

它的核心用途是結構化的預算與預測週期、含公司間交易沖銷的法定合併，以及受稽核控管的結帳。

SAP BPC 會被停止嗎？

不會，但支援取決於版本。BPC 10.1 for Microsoft 已於 2026 年 6 月 30 日退出主流維護。BPC 11.1 for BW/4HANA 2.0 已於 2025 年 12 月結束。BPC 10.1 for NetWeaver 的主流維護到 2027 年底，可選的延伸維護到 2030 年。BW/4HANA 產品線與 BPC optimized for S/4HANA 則規劃至少支援到 2040 年。

SAP 的策略性規劃工具是 SAP Analytics Cloud。S/4HANA 上的合併，路徑是 Group Reporting，不是 SAC。

SAP BPC 與 SAP Analytics Cloud：我該用哪一個？

它們做的是不同的工作。BPC 是為結構化的規劃與法定合併而打造，具有嚴格的稽核控管、資料鎖定與版本管理。SAC Planning 則是為以驅動因子為基礎的規劃、情境與協作而打造，介面更視覺化，也有 SAP 的 AI 投資作為後盾。

許多組織兩者並用：BPC 作為合併與法遵的引擎，SAC 作為規劃與儀表板層。只有在角色明確劃分時，這種做法才行得通。

對於新的規劃導入，SAC 是面向未來的選擇。如果您已有成熟的 BPC 合併模型，而 Group Reporting 對您來說還不可行，太早移轉可能製造出比解決的更多的問題。

SAP BPC 有哪些部署模式可選？

五種。BPC Standard 把邏輯留在 BPC 內，適合財務主導的團隊。BPC Embedded 倚賴 BW 物件，適合具備 BW 技能、由 IT 主導的環境。BPC for Microsoft 已退出主流維護，且不再接受新的部署。BPC optimized for S/4HANA 在 Universal Journal 上即時規劃，適合穩定、標準的流程。BPC 與 SAC 混合式，則把合併與情境及儀表板分開。

混合式架構的界線，要在建置之前就定義好，而不是上線之後。

SAP BPC 與 Oracle FCCS 及 OneStream 相比如何？

Oracle FCCS 部署較快，標準合併功能強大，但一旦需要自訂邏輯就會受限。BPC 對合併規則提供更多控制，但需要 SAP 技能來維護。

OneStream 整合且現代，稽核與安全性強。它不一定導入得比 BPC 快，而上線後的負責人往往落在專職管理員身上。如果您的規劃與 SAP ERP 資料緊密相連，BPC 相對於需要額外整合層的工具，表現相當穩健。

這些工具都不是因為缺少功能而失敗。它們失敗，是因為上線後沒有人擁有這個模型。

我應該何時檢視或重新設計我的 SAP BPC 設定？

當財務正在 BPC 之外重建離線模型的時候。這是最明確的訊號，代表系統已經變成報表層，而不是規劃工具。

其他徵兆：每一次預測變更都需要 IT、合併邏輯技術性太強，財務無法維護、實績資料遲到或不完整，以及高階主管的報表仍然要人工調整格式。

要重新設計還是移轉，取決於您的版本與 S/4HANA 計畫。在 ECC 上且近期沒有移轉計畫，改善 BPC 就合理。如果 S/4HANA 即將到來，在決定重新設計之前，請先評估 Group Reporting 與 SAC。我的 ECC 移轉到 S/4HANA 指南談到了這個時程。