SAP 与 ServiceNow 的 ERP 现代化

用 SAP 和 ServiceNow 做 ERP 现代化，意味着让每个平台做它最擅长的工作，并把它们正确地连接起来。SAP S/4HANA 运行结构化的交易：财务、采购、库存、薪资。ServiceNow 运行围绕这些交易的工作流：受理、审批、例外和服务请求。SAP Integration Suite 与 ServiceNow IntegrationHub 把两者连接起来。本指南写给正在规划从 SAP ECC 或早期 S/4HANA 系统启动现代化的 CIO、CFO 和企业架构师。内容涵盖按职能划分哪些工作放在哪里、AI 适用于何处、分阶段路线图和各种陷阱。先看职能表，再看路线图。

ERP 现代化几乎出现在我接手的每个项目里。我合作过一些仍在运行 SAP ECC 的企业，它们在本该多年前就退役的环境中管理财务或运营。一位物流客户，仅仅为了批准一项小的流程变更，就要经过四次手工交接。我们把 SAP 与 ServiceNow 连接起来，周转时间和可见性立刻就有了差别。

我常见的错误：以为 ERP 现代化就是升级到最新的 SAP 版本。如果您的系统彼此不能对话，您只是把问题搬到了一个更新的界面上。数据困在孤岛里。团队不再信任工具。人们追着问题跑，而不是去解决它们。

很多团队相信自己已经现代化了。实际上他们只是升级了。差别体现在日常工作中。

现代化意味着重新思考您的系统如何支撑今天的业务，而不是它们十年前被设计成怎样工作。它涉及架构、流程、数据、集成和用户体验。

CIO 们常问我：“所以这是要迁移到云，还是要替换我们的 ERP？”有时两者都是，但很少一次到位。真正的现代化通常始于 ERP 不再随业务扩展、摩擦变得显而易见的时候。

中东的一家消费品客户仍在运行 SAP ECC。财务部门把时间花在清理坏数据上，报表落后于运营。我们从重新评估实施本身开始：不只是技术，还有流程是否仍然符合业务的运作方式。然后是主数据。再然后是自动化：SAP 能在内部处理什么，ServiceNow 能在哪里填补缺口，尤其是审批、升级和流程跟踪。这个顺序给了领导层一份计划、一条时间线和可以跟踪的成果。

现代化很少意味着把一切都拆掉。更常见的是，企业保留已经有效的部分，围绕它进行现代化。这正是 SAP 和 ServiceNow 并肩工作得很好的地方。

SAP S/4HANA 处理结构化的核心：交易、财务、采购和库存，为控制和一致性而生。ServiceNow 处理 SAP 从未被设计为直接去做的事：受理、审批、跨职能工作流和例外处理。Clean Core 强化了这种分工。不属于 SAP 核心的工作流逻辑总得有个去处，现实的去处是 SAP BTP 上的并行（side-by-side）扩展或 ServiceNow。我的 Clean Core 指南解释了各种扩展选项。

连接通过 BTP 上的 SAP Integration Suite、ServiceNow IntegrationHub 和开放 API 完成，使数据流感觉像原生的，而不是外挂上去的。我认识的一位全球客户用 SAP 做采购，用 ServiceNow 管理采购请求，这省去了定制门户；之后它又把同样的结构用于供应商入驻。如果您仍在运行 SAP Process Orchestration（PI/PO），请规划迁移：PI/PO 所运行的 SAP NetWeaver 7.5，将在 2027 年底退出主流维护，可选的延长维护到 2030 年。我的 SAP Cloud Integration 指南介绍了目标平台。

1. 04ServiceNow跨团队的受理、审批、例外和服务请求
2. 03集成BTP 上的 SAP Integration Suite 与 ServiceNow IntegrationHub，基于开放 API
3. 02扩展SAP BTP 上的并行扩展，承载不属于核心的逻辑
4. 01SAP S/4HANA 核心财务、采购、库存和薪资，尽量贴近标准

按职能划分的用例

HR。 SAP（或 SuccessFactors）保留员工主数据、角色、薪资和福利。ServiceNow 协调入职任务、访问权限开通、晋升审批，以及横跨 IT、HR、财务和安全的离职流程。

财务。 SAP 处理发票、保管账簿、运行关账并出具法定报告。ServiceNow 运行工作流层：

财务流程	SAP 的角色	ServiceNow 的角色
应付账款	处理发票、匹配采购订单、管理付款	发票受理、例外路由、SLA 跟踪
应收账款	跟踪客户发票和催收	路由账单争议和信用冻结请求
财务关账	期间关账、公司间抵销、报告	关账清单、任务分配、对待处理事项的提醒
费用管理	记录条目、执行政策、触发报销	路由报告以供审批，标记例外
采购到付款	申请、采购订单、收货、供应商结算	受理表单、审批路由、例外处理

采购。 SAP 管理供应商主数据、采购订单、收货和三单匹配。ServiceNow 处理受理、供应商入驻核查、收货问题和采购服务台。

设施与运营。 SAP 跟踪固定资产、维护成本和空间。ServiceNow 处理办公场所请求、维护工单、技术人员分配、访问请求和事件路由。

AI 出现在越来越多的现代化讨论中，期望有时跑在结果前面。实际上，它处理边缘情况，自动化重复性任务，并浮现人们遗漏的东西。在 SAP 一侧，SAP 的 AI 助手 Joule 贯穿 S/4HANA、SuccessFactors、Ariba 和 SAP Build。在 ServiceNow 一侧，Now Assist 把生成式 AI 带入其 IT、HR 和客户服务工作流。

工作通常这样划分：

AI 用例	SAP 的角色	ServiceNow 的角色
发票匹配	匹配采购订单、收货和发票；标记异常	路由例外，并为高风险的不匹配排定优先级
预测性维护	根据设备数据分析使用和故障模式	创建维护工单并安排技术人员
现金流提醒	根据历史数据预测现金头寸	在突破流动性阈值时触发提醒和工作流
虚拟智能体	Joule 回答跨 SAP 应用的自然语言问题	虚拟智能体和 Now Assist 处理请求并调用 SAP 后端
异常检测	SAP BTP 上的模型或嵌入式分析标记交易中的离群值	标记工作流和审批中的异常，供审计审阅
请求分类	在采购流程中建议类别	Predictive Intelligence 对案例分类，并路由到合适的小组

我们合作过的一个 IT 团队，在引入能重置密码并获取 SAP 数据的虚拟智能体之后，一个季度内低价值支持工单下降了 30%。这一规律在 SAP 一侧同样成立：当流程稳定、历史数据干净、问题聚焦时，AI 的效果最好。即便如此，它也是在支持团队，而不是取代团队。

现代化常常停滞，是因为第一步感觉太大。我合作过一些客户拖了好几年，不是因为缺乏紧迫感，而是因为没有人能回答“我们从哪里开始？”。下面这个顺序往往行得通：

1. 评估并精简。 在迁移平台之前先清理基础。运行 SAP Readiness Check，评估自定义代码和兼容性的规模。在迁移之前而不是之后清理主数据。决定哪些系统、报表和流程保留。决定部署路线（RISE with SAP、GROW with SAP 或本地部署），并把 SAP Cloud ALM 规划为您的生命周期工具，因为 SAP Solution Manager 在 2027 年底退出主流维护。一次简短的技术探索冲刺，梳理哪些东西连接了哪些东西，通常能显示真正的风险藏在哪里。
2. 从 ServiceNow 开始。 先构建受理、审批和工作流。它们围绕着 ERP，产生的抱怨也最多。一位客户在 S/4HANA 迁移前六个月，用 ServiceNow 管理变更控制，把停机减少了 40%。这在您触碰 SAP 核心之前建立起纪律。
3. 借助 Clean Core 迁移 SAP 核心。 以尽可能少的自定义代码，把交易迁移到 S/4HANA。贴近标准能简化升级，降低维护成本。把自定义逻辑放在并行扩展或 ServiceNow 中，而不是核心里。并且要问，未来五年 ERP 应该赋能什么，而不是仅仅做迁移。
4. 优化并扩展。 在 SAP BTP 上加入分析和扩展，合适的地方加入 Joule，在 ServiceNow 一侧加入 Now Assist、虚拟智能体和低代码工作流。

各阶段可以重叠。让 ServiceNow 的稳定工作与 SAP 就绪度工作并行，可以在不偷工减料的情况下缩短时间线。对于 S/4HANA 部分，我的 ECC 到 S/4HANA 迁移指南介绍了路径和时间线。

财务部门很早就会问成本，而决定通常落在 CFO 头上，即使它是从 IT 开始的。

直接成本最先到来：基础设施、托管、存储和集成工具。许可证和支持保持不变，除非有人去精简，许多团队从不去查找未使用或重叠的许可证。在 RISE with SAP 上，请对整个期限内的 Full User Equivalent（FUE）定价下的用户增长建模，因为第三年的订阅费用很少与第一年的报价一样。

间接成本更难看见：缓慢的审批、错过的 SLA、削弱对 IT 信任的集成故障。它们不会出现在某一条预算行里，却会体现在运营绩效中。

要展示回报，在改变任何东西之前先做测量：发票审批、入职和采购申请的周期时间；错误率；集成延迟。哪怕只有部分基线，也能让回报成为一个数字，而不是一个故事。

这些陷阱在两个平台上都会出现：

陷阱	SAP 的失误	ServiceNow 的失误
跳过流程评估	迁移遗留问题，却不审视流程缺口	部署请求表单，却不了解真正的瓶颈
把工具当作万能药	以为 S/4HANA 能修复无人重新设计的流程	以为自动化能修复低效的请求设计
忽视主数据	迁移重复或不一致的数据	在不可靠的数据上触发审批
过早过度定制	在核心流程稳定之前构建扩展	在了解用户行为之前构建复杂的流程
没有治理	把决策留给 IT 或供应商，没有业务负责人	推出工作流，却没有规则和 SLA 的负责人
忽视变革管理	对新 SAP 流程的培训投入不足	没有教用户何时以及如何使用新的请求类型

我记得一位制造业客户，以为问题出在它的 ERP 上。真正的障碍是一条横跨五个团队的手工审批路径。我们引入 ServiceNow 层并把它连回 SAP 之后，瓶颈就消失了。

现代化不必一次完成。有些系统保留，有些改变。随着环境中更多的部分被连接起来、依赖变通办法的部分越来越少，价值也在累积。

我们需要一次性完成现代化吗？

不需要。现代化分阶段进行效果最好。许多组织先从 ServiceNow 工作流入手，在触碰 SAP 核心之前稳定运营，然后按摩擦程度的顺序处理其余部分。

一位客户在部署 S/4HANA 之前，ServiceNow 的受理工作流就已上线。员工逐步适应，这提高了采用率，也减少了抵触。

S/4HANA 迁移中，遗留的定制会怎样？

这取决于它们的业务价值。SAP Readiness Check 会尽早显示自定义代码量和兼容性问题。大多数系统带有的自定义代码，比任何人意识到的都多，而且其中很多已不再使用。

Clean Core 倾向于保持系统标准，把扩展放在 SAP BTP 上，或把工作流放在 ServiceNow 中。在 S/4HANA Cloud Public Edition 上，核心完全不能修改；在 Private Edition 和本地部署上可以，但每一处修改都会增加升级工作。保留有真实业务用途的，淘汰其余的。

ERP 现代化需要多长时间？

从 ServiceNow 的受理工作流开始，通常需要两到三个月。迁移到 S/4HANA 往往需要 9 至 18 个月，取决于复杂程度，对于定制很重的大型多实体企业则更长。

各阶段不必一个接一个地运行。让 ServiceNow 的稳定工作与 SAP 就绪度工作并行，可以缩短整体时间线。

SAP 与 ServiceNow 现代化的现实 ROI 时间线是怎样的？

大多数组织在三到六个月内看到软性回报：更短的周期时间、更少的手工交接、更好的可见性。实实在在的回报，也就是可衡量的成本下降和效率提升，往往在 12 至 18 个月内到来，特别是在两个平台都开始发挥作用之后。

在开始之前，先跟踪周期时间、错误率和 SLA 达标情况。没有基线，回报就只是一个故事，而不是一个数字。

怎么知道 ERP 现代化已经迟了？

常见的信号：支持工单上升、解决时间变长，升级和补丁一再推迟，同一份数据有多个事实来源，以及影子 IT 在填补 ERP 本应覆盖的缺口。

一家运行 SAP ECC 的医疗客户，在一个季度里错过了好几项 SLA。问题不在于努力不够，而在于技术债务：多年的小修小补层层叠加，事件记录的速度超过了任何人处理的速度。

SAP 和 ServiceNow 能与其他第三方系统集成吗？

能。SAP 使用 BTP 上的 SAP Integration Suite，通过基于 API 的连接对接外部系统。ServiceNow 提供 IntegrationHub，带有面向大多数企业平台的预置连接器，包括 Workday、Salesforce 和 Coupa。

从一开始就把集成当作一个工作流。接口范围定得晚，会在上线后造成最大的摩擦，所以要在蓝图阶段就开始集成设计。