什么是RISE with SAP？

RISE with SAP是SAP帮助企业迁移到S/4HANA Cloud的一种方式，企业无需自己把各个部分拼凑起来。它是一项打包服务，而不仅仅是许可证或云订阅。其中包括软件、基础设施、用于自动化和流程改进的工具，以及持续的支持，全部由SAP在一份合同下统一管理。

其出发点，是让数字化转型更有条理、不那么零散，尤其适合那些想要实现现代化、却不想为此管理十家不同供应商的中型到大型企业。

传统的本地部署要由您自己拥有并运营整个技术栈，而RISE把其中的大部分责任转移给了SAP。重要的决策仍由您来做，但技术上的繁重工作由SAP承担。这是另一种合作关系。在这种合作中，重心从单纯的“运行SAP”，转向真正推动业务运作方式随时间不断演进。

RISE with SAP最适合那些想要实现现代化、又不想自己管理整个ERP技术栈的企业。它面向的是已经准备好走向标准化，但在部署和可扩展性方面仍需要灵活性的企业。

虽然从技术上讲它可以支持各种规模的企业，但对需求更复杂的企业尤其实用。一些常见的适配迹象包括：

• 业务遍及多个国家的中型到大型企业

• 正在替换高度定制的遗留ERP系统的企业

• 缺乏内部云基础设施专业能力的组织

• 致力于实现目标明确的数字化转型的企业

• 愿意采用SAP最佳实践和Fit-to-Standard流程的团队

它并非放之四海而皆准，但只要方向明确，RISE就能让这段旅程变得简单。

开始您的实施评估

RISE with SAP在您需要结构的地方给您结构，在仍然重要的地方给您灵活性。S/4HANA Cloud背后的技术运营由SAP负责，而您可以选择环境托管在哪里。这个选择影响的不只是技术，它还会左右系统如何集成、谁来管理什么，以及整套架构如何随时间演进。

1. 在AWS、Azure或Google Cloud上运行RISE with SAP

最常见的路径，是把RISE运行在超大规模云服务商（hyperscaler）上。SAP支持Amazon Web Services（AWS）、Microsoft Azure和Google Cloud Platform（GCP）。它们都已获得S/4HANA认证，并且都深度融入了SAP的云路线图。如果您的IT团队已经在使用其中某一家，继续沿用它可以让运营和安全策略更容易管理。

各家的性能都很强。不过，有些企业为了与Microsoft兼容而倾向Azure，有些为了全球覆盖而倾向AWS。当数据和分析是重点时，偶尔会考虑GCP。

2. SAP数据中心

如果优先考虑中立性或简单性，SAP自己的数据中心也是一个选项。这些数据中心完全由SAP管理，中间没有超大规模云服务商。当您希望减少参与方，或采购部门更倾向于签订直接协议时，这会很有帮助。

3. 客户数据中心（CDC）

这种情况很少见，但仍然可以选择。如果贵公司对数据控制有严格规定，或处于受监管的环境中，SAP可以在您自己的基础设施内运行RISE。它仍由SAP管理，只是物理上位于您这一侧。它并不适合所有人，说实话，大多数企业用不上。

选择之前要考虑什么

无论托管在哪里，系统维护、升级、备份和性能监控都由SAP负责。

影响您选择哪种环境的几个因素：

• 现有的云供应商关系

• 数据驻留与合规要求

• 延迟和区域性能需求

• 内部云成熟度和集成策略

无论在哪里运行，它仍然是RISE。但托管决策的分量，比乍看上去要大。

企业刚开始了解RISE with SAP时，往往把注意力放在S/4HANA Cloud本身：它能做什么，它替换什么。但它运行在哪里、如何被管理，带来的差别比大多数人预期的要大。RISE背后的部署模式不只是一个技术选择。它影响您保留多少控制权、团队如何与SAP协作，甚至影响日后应对变化的速度。

无论是托管在AWS、Azure、Google Cloud，还是SAP自己的数据中心，基础都很重要。有些企业想保持简单。有些需要与现有的云投资保持一致。还有少数企业其实没有选择，它们受数据隐私法律或行业规定的约束。

所以在做选择之前，值得放慢脚步。这些好处是真实的，但具体体现为什么，取决于您今天的现状，以及您接下来想把事情带向何处。

1. 简化基础设施决策

云服务提供商由您选择：SAP、AWS、Azure或GCP。但一旦选定，其余的都由SAP负责，包括资源开通、补丁、备份和扩容。

• 无需与超大规模云服务商另签合同
• SAP始终是您唯一的责任方
• IT部门与供应商之间的反复沟通更少

2. 标准化部署，灵活托管

无论您使用超大规模云服务商，还是SAP数据中心，运营模式都保持一致。这意味着在上线推广阶段，未知因素更少。

• 无论平台如何，支持流程都相同
• 团队之间的交接可预期
• 需要时，日后仍有扩容或迁移的空间

3. 与内部战略更好地对齐

已经在AWS或Azure上运行工作负载了吗？把RISE托管在那里，可以降低复杂度，并帮助IT团队沿用已有的知识。

• 安全和策略保持一致
• 需要管理的新平台更少
• 与非SAP系统更容易集成

4. 降低迁移风险

RISE自带的工具和服务，让从ECC或遗留系统迁移不那么痛苦，搭配超大规模云服务商的可靠性时更是如此。

• 自动化检查和就绪度工具
• 资源开通和扩容由SAP负责
• 从第一天起就内置监控

5. 借助CDC选项获得监管灵活性

如果您所在的行业对数据处理有严格规定，RISE可以运行在您自己的数据中心内。这是小众选项，但对某些企业至关重要。

• 保持内部托管，同时不失去SAP的支持
• 满足数据主权或数据驻留的强制要求
• 与公有云相同的运营模式

6. 一份合同，更少意外

无需再分头处理许可证、托管和服务，一切都已打包在一起。您只需要与SAP打交道，且只与SAP打交道。这简化了规划和预算。

• 固定的订阅模式
• 内置技术支持和SLA
• 范围和成本一目了然

RISE with SAP是一套精心组合的打包方案，目的是简化您通往S/4HANA的道路，减少协调多家供应商带来的杂乱。您不必分别购买许可证、基础设施和工具，而是在一份合同下获得全部内容，由SAP统一管理（很棒，不是吗？）。

RISE with SAP套件通常包含以下内容：

• SAP S/4HANA Cloud（公有云版或私有云版）

• SAP Business Technology Platform（BTP），含使用额度

• SAP Signavio，用于流程建模和绩效洞察

• SAP Business Network的入门级访问权限，用于与合作伙伴连接

• 云基础设施，通过SAP、AWS、Azure或Google Cloud提供

• 技术迁移工具和生命周期管理，完全由SAP负责。

它有结构，但并不僵化。范围、节奏和托管合作伙伴仍由您决定。RISE提供的，是一个真正能够站得住的框架，尤其是当目标是转型，而不只是更换系统时。

RISE with SAP听起来很直截了当，但要判断它是否是适合您业务的模式，光是喜欢这个概念还不够。订阅包含的内容很多，但也限制了您可以定制的程度。在投入之前，值得放慢脚步，问自己几个棘手的问题。

• 您想修复、简化什么，或者想让什么经得起未来的考验？

• 您现有的系统和定制有多复杂？

• 您的团队是否已经准备好在更标准化、由SAP管理的环境中运作？

如果业务围绕转型达成了一致，RISE的效果会很好。如果这一点还很模糊，或者内部人才捉襟见肘，那么所需的准备可能比预期的要多。

1. 业务就绪度

RISE with SAP不只是一次系统升级，它带来的是有结构的变革。组织需要在目标、时间表和干系人对齐方面保持清晰。

• 领导层的支持不可或缺
• 明确的目标和优先级
• 清晰传达变革的影响

2. 内部团队能力

虽然运营由SAP负责，但配置、集成和推广应用仍需要内部团队的支持。请在流程早期就评估团队的就绪程度。

• 评估技能水平和可用时间
• 梳理各项目的IT工作量
• 如有缺口，规划外部支持

3. 标准化与定制

RISE鼓励采用Fit-to-Standard流程。如果现有系统依赖大量定制，就需要做出调整。

• 找出不可舍弃的自定义代码
• 用SAP Signavio梳理差距
• 重新设计不匹配的部分

4. 与云战略的契合度

当云的方向已经明确时，RISE的效果最好。它适合那些已经确定了安全、集成和托管策略的企业。

• 确认与企业架构保持一致
• 审视对超大规模云服务商的偏好和相关政策
• 明确SAP与内部IT之间的职责归属

5. 财务模式

RISE采用基于订阅的模式。财务和采购团队必须适应这种模式所要求的运营支出的思维方式。

• 按多年期预测成本
• 与现有的许可结构做比较
• 弄清楚哪些已包含，哪些不包含

6. 时机与专注度

大型转型项目需要领导层的关注，也需要业务部门有时间投入。请考虑现在是否是做出承诺的合适时机。

• 评估正在进行和即将开展的各项举措
• 落实高管赞助
• 确保有精力投入培训和变革

RISE with SAP合同不只是S/4HANA的许可证，而是一个旨在简化通往云ERP之路的打包方案。一切都包含在一份订阅中，纸面上听起来很整齐，但值得弄清楚究竟包含什么，以及哪些仍由您自己负责。它涵盖基础设施、ERP软件、支持服务，以及一些帮助推动变革的工具。

话虽如此，项目治理、培训和测试之类的工作，仍需要您自己投入资源。合同通常包含以下内容：

1. S/4HANA Cloud许可证

合同包含S/4HANA Cloud（公有云版或私有云版）的使用权，按完整用户当量（FUE）授权。

• 核心ERP模块
• 包含定期更新
• 基于订阅

2. 云基础设施

您的ERP运行在超大规模云服务商的基础设施（AWS、Azure、GCP或SAP数据中心）上，费用已包含在订阅成本中。

• 完全托管的IaaS层
• 可选择地理区域和服务提供商
• 安全与监控由SAP负责

3. 技术运营

作为托管服务模式的一部分，SAP负责备份、系统补丁和监控等关键技术工作。

• Basis管理
• 灾难恢复配置
• 7x24小时系统可用性支持

4. SAP Business Technology Platform

合同提供SAP BTP的使用额度，可用于扩展、集成或分析。

• 应用场景包括自定义应用
• CPI等集成服务
• 事件驱动的自动化

5. SAP Signavio

流程洞察是套件的一部分。Signavio工具可帮助您为当前状态和目标状态建模并加以优化。

• 流程发现与建模
• 差距分析工具
• Fit-to-Standard支持

6. SAP Business Network访问权限

合同包含对SAP Business Network的有限访问权限，提供供应商协作和基础采购功能。

• 供应商引入
• 基础采购工作流
• 需要时可升级

有结构而又灵活的框架

RISE with SAP以SAP Activate方法论为基础。您会频繁看到这个名字。它以分阶段、有指引的方式勾勒出通往S/4HANA Cloud的路径。这套结构很有帮助，但并不过于僵化，重点是保持在正轨上，而不是陷入过度设计。

Fit-to-Standard：起点

这一过程在很大程度上依赖Fit-to-Standard研讨会。这些研讨会旨在探讨您目前的工作方式在哪些方面符合SAP的最佳实践。有些领域能很好地对应，有些则可能引发争论。正是在这里，需要结合业务和IT双方的意见，尽早就标准化还是定制做出决定。

交付模式：合作伙伴、SAP，或两者结合

交付可以由合作伙伴主导、SAP主导，或采用共担模式。这里没有放之四海而皆准的正确选择，真正取决于您内部团队的经验、可用时间，以及承担主导责任的意愿。即使有外部支持，内部也仍然需要有人来掌舵。

时间线与关键阶段

大多数RISE项目需要6至12个月。关键阶段包括：

• 发现（Discover）：确定目标和总体范围

• 准备（Prepare）：组建团队、设置访问权限并制定时间表

• 探索（Explore）：开展Fit-to-Standard研讨会

• 实现（Realize）：配置、测试和集成

• 部署（Deploy）：规划切换并上线

• 运行（Run）：支持与演进

不只是技术交付

在搭建系统的同时，您还需要考虑培训、变革就绪度和持续支持。这些并不是额外项，而是项目中不可缺少的部分。在这方面不够重视，会拖慢日后的推广应用。

真正的变量：内部对齐

这套框架行之有效，但前提是业务和IT团队保持一致。值得在前期花时间，把决策将如何做出弄清楚。没有这种共同的理解就匆忙开始配置，往往会在后期造成拖延。

我在SAP与数字化转型领域工作了25年，见过项目从启动到上线的全过程，也见过没人愿意谈的、混乱的中间阶段。有时候我从一开始就主导项目。有时候，我是在事情出了岔子时被请来稳住局面。

无论哪种情况，我的角色都一样：把业务真正需要的，和系统实际能够交付的连接起来。不说行话，不说空话。您在这里看到的内容，来自多年的一线工作，是在真实的压力下解决真实问题得来的。

RISE with SAP简化了ERP项目中的许多技术环节。但这并不意味着难点消失了。实际上，一些真正的挑战上移到了上游，转移到决策、责任归属和思维方式上。有几种错误会反复出现。比如抱着本地部署系统时代的假设不放。或者以为自定义代码会自动跟着一起迁过去。还有的时候，团队根本不清楚内部到底谁该负责什么。

出现以下情况时，事情会进行得更顺利：

• 尽早而不是较晚地让流程负责人参与

• 把数据和集成当作关键路径

• 分阶段交付，让大家真正能够消化这些变化

下面是最容易引发摩擦的六个陷阱。

1. 本地部署思维

团队有时会期望云端照搬原有的本地流程。云ERP要求在角色和责任方面建立新的前提。

• 重新审视决策结构
• 定义清晰的云专属角色

2. 高估代码的可移植性

定制很少能原样迁移。许多需要重新设计，或迁移到SAP BTP上作为扩展来实现。

• 梳理现有的自定义代码清单
• 规划现代化改造或退役

3. 内部责任归属薄弱

实施合作伙伴引导系统搭建，但推广应用必须由内部团队掌舵。没有明确的责任人，项目就会失去方向。

• 任命一名专职的项目负责人
• 确保干系人保持参与

4. 低估数据复杂度

数据迁移往往会暴露出不一致和缺口。拖到后期才处理，会造成延误。

• 尽早开始数据剖析和清洗
• 为每个数据域指定数据管家

5. 时间表过于仓促

为了赶上雄心勃勃的日期而压缩各阶段，通常适得其反。分阶段交付更便于控制。

• 设定清晰的阶段关口
• 让上线日期与就绪程度保持一致

6. 缺少干系人的支持

变革疲劳是真实存在的。如果最终用户和高管没有尽早参与，上线后的抵触情绪会不断增长。

• 定期举办干系人研讨会
• 在培训中使用真实场景

RISE with SAP项目中的集成，需要比人们通常预期更多的关注。SAP管理基础设施，并不意味着系统之间的一切都由SAP处理。您仍然需要规划好什么连接到哪里、数据如何流动，以及谁负责哪些接触点。

RISE让您可以使用SAP Business Technology Platform（BTP），许多现代集成现在就放在那里。它支持API、事件驱动的流程和预置连接器。但较老的系统，无论是本地部署的还是第三方的，可能仍然依赖批处理作业或文件传输。如果没有前期规划，这种混合局面很容易变得混乱。

最好先做一次全面的盘点：

• 目前有哪些系统连接到您的ERP？

• 哪些必须实时，哪些可以异步？

• 有没有带硬编码连接的遗留工具？

您还应该尽早让IT和业务两方都参与进来。集成的范围往往只由其中一方划定，结果后面总会出意外。测试是另一个重点。不要以为“以前能用”就意味着现在也能用。

简而言之，把集成当作一个工作组来对待，而不是一项任务。分配足够的时间和合适的人。否则，即使ERP核心再干净，也无法带来您期望的价值。

系统上线之后，工作的性质就变了。您不再是配置或测试，而是在运行、调整和支持。RISE with SAP提供技术基础：基础设施、系统更新、监控。这部分有人负责。但业务层，也就是日常运营和决策，仍然在您的团队手里。

事情往往就是在这里慢下来的。支持角色可能没有明确分配。变更请求不断堆积，却没有排定优先级的办法。有些团队很早就发现了这一点，另一些则要等到引发摩擦才意识到。

Signavio、SAP BTP和分析仪表板等工具都包含在RISE中，但它们不会自己创造价值，需要有人来负责。

有几件事会有帮助：

• 尽早确定上线后的问题由谁处理，包括内部和与SAP之间

• 维护一份修复、更新和改进事项的待办清单

• 每隔几个月回顾一次使用情况和反馈

• 让后续增强与SAP的产品路线图保持一致

• 为优化留出空间，而不只是救火

目标是持续改进，即使项目在技术上已经“完成”。如果没有这方面的计划，系统就会停滞，而不是继续演进。通常这时缺口就开始显现了。

这也关乎清晰度：您今天在运行什么，愿意改变什么，以及内部由谁来带领这次转变。

先从流程的可视化开始。SAP Signavio之类的工具可以描绘出目前的运作方式，也能显示哪些环节停滞或重复。然后还有LeanIX，它能让您看清自己的应用全景，如果多年来积累了大量自定义工具，这尤其有用。其中有些可能不需要带到新系统里。

开始之前，有几件事值得考虑：

• 对您当前的业务流程做一次基线分析

• 建立应用、接口和数据流的清单

• 审查所有自定义代码：哪些是关键的，哪些不是

• 确定范围、例外和审批的决策人

RISE with SAP适合您吗？

这不只是一个技术决策，更是方向问题：您的业务希望如何运作，并随时间如何演进。RISE with SAP围绕云交付、流程标准化和共同责任构建。有些组织很快就能适应这种结构，另一些则可能需要暂停一下，重新评估。

问问自己：

• 我们是否愿意采用SAP的最佳实践，而不是一切从零开始构建？

• 我们的内部IT团队是否有能力主导转型，还是更侧重于支持和交付？

• 我们能否让核心ERP适应SaaS式的运营模式？

如果这些问题让您觉得切中要害，甚至有点不舒服，那就是一个好迹象，说明值得深入研究。

我们可提供引导式评估、就绪度研讨会，以及与RISE认证专家的一对一咨询。如果您不确定从哪里开始，或该评估什么，不妨先从一次交流开始，这有助于理清下一步。让我们一起看看RISE是否适合您的业务。

常见问题

很多客户在刚开始考虑SAP实施时，围绕的往往是同样的几个问题。

也许您自己也想过其中几个：到底需要多长时间，可能花多少钱，或者系统上线后需要什么样的支持。这些问题问得合理。

所以，与其让您去猜，我整理了一些清楚、坦诚的回答，帮助您更好地了解会发生什么，以及棘手的部分通常出现在哪里。

联系我吧！

1. RISE with SAP是什么意思？

RISE with SAP是SAP的打包方案，帮助企业迁移到基于云的ERP。它在一份合同下，把S/4HANA Cloud与基础设施、工具和托管服务结合在一起。

2. “rising SAP”是什么意思？

这不是技术术语。人们常常非正式地用它来指SAP推动云转型的举措，主要是通过RISE with SAP。

3. S/4HANA与RISE with SAP有什么区别？

S/4HANA是ERP产品。RISE with SAP则是商务与交付模式，它把基础设施、服务和支持与S/4HANA Cloud打包在一起。

4. RISE with SAP与GROW with SAP有什么区别？

GROW面向规模较小、快速成长的企业，只聚焦公有云。RISE服务于中型到大型企业，提供更多灵活性，包括私有云。

5. RISE with SAP与SAP HEC有何不同？

SAP HEC曾是一种托管服务方案。RISE with SAP则包含云ERP、工具和服务，更加全面，专为云优先的运营而打造。

6. SAP S/4HANA与传统SAP ERP有什么区别？

S/4HANA是新一代的SAP ERP。它速度更快，数据模型更简单，并支持实时分析。较老的系统（如ECC）更多依赖批处理，技术层次也更多。S/4HANA还采用Fiori界面，与传统的SAP GUI相比是一次很大的转变。

7. 什么是GROW with SAP？

GROW是SAP面向规模较小企业的SaaS ERP方案。它经过预配置，只提供公有云，遵循标准最佳实践，上线速度更快。

8. 什么是RISE with SAP合同？

这是一份基于订阅的合同，打包了S/4HANA Cloud、基础设施、Signavio等工具以及由SAP管理的服务，在一份协议下计费。

9. 如何迁移到RISE with SAP？

先从就绪度评估开始。然后选择部署路径（绿地、棕地或选择性迁移）。SAP Activate是迁移过程中使用的标准框架。

10. RISE with SAP的三大核心要素是什么？

核心要素是：

• S/4HANA Cloud（ERP平台）

• SAP Business Technology Platform（用于扩展和集成）

• SAP Signavio和Business Network（用于流程智能和协作）

简化SAP实施之旅的工具

SAP实施成本计算器

这个工具可以帮助您估算SAP实施的大致成本。

SAP人员职位描述生成器

如果您要为SAP项目招人，可以用这个工具生成职位描述。

数据迁移工作量与成本估算器

通过这个工具，您可以确定所需的数据对象，以及数据迁移相关的成本。

简单易用的ERP实施成本计算器

快速评估您的ERP预计成本和时间线。它并不完美，但能让您对成本有一个不错的了解。

SAP解决方案构建器与路线图生成器

这个工具根据您的行业、规模和目标，帮助界定合适的SAP解决方案范围和分阶段路线图，让您在合适的时间部署合适的模块。

S/4HANA迁移评估工具：绿地与棕地

根据系统年限、数据、自定义代码和流程需求，快速确定合适的迁移路径（绿地、棕地或选择性迁移）。

快速评估您的ERP预计成本和时间线。它并不完美，但能让您对成本有一个不错的了解。