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，Microsoft 版	主流维护已于 2026 年 6 月 30 日结束；仅提供客户专属维护	现在就规划退出。SAP 建议迁移到 SAP Business Data Cloud
BPC 11.1，BW/4HANA 2.0 版	已于 2025 年 12 月 31 日结束	升级到 BPC 2021 或迁移
BPC 10.1，NetWeaver（BW 7.5）版	主流维护到 2027 年 12 月 31 日；可选的延长维护到 2030 年 12 月 31 日	这是一个窗口期，而不是终点。在规划 S/4HANA 时做出决定
BPC 2021，BW/4HANA 2021 和 2023 版	到 2030 年 12 月 31 日，并承诺提供至少支持到 2040 年的后继版本	只要 BW/4HANA 留在您的架构里，就能再用很多年
BPC 10.1，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）作为单一记录。新的实施很少会选 BPC，除非有特殊原因，比如 Group Reporting 目前还处理不好的股权结构。

对于现有客户，问题在于时机。在 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 optimised for S/4HANA（S/4HANA 优化版）：运行在 S/4HANA 技术栈上，从通用日记账（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 技能	由 IT 主导、BW 技能强的环境
BPC for Microsoft	SQL Server、Excel 和 .NET 前端	仅限现有用户，正在规划退出
BPC optimised for S/4HANA	在通用日记账上做实时计划；无需复制	成熟、稳定、计划逻辑标准的 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 optimised 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 的 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 optimised 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 optimised for S/4HANA 在通用日记账上实时做计划，适合稳定、标准的流程。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 指南讲了这个时间线。