从 SAP GUI 到 API 自动化，为什么 SAP 团队必须把 API 拉到路线图中央

最近做 SAP 项目时，一个越来越明显的变化是，业务方已经不再满足于打开 SAP GUI、进入事务码、手工录入、等待审批、再导出 Excel 核对结果。很多流程从表面看只是一个小动作，销售订单交货冻结要解除，供应商主数据要修正，发票冻结要复核，物料主数据要补齐字段，背后却牵动着授权、校验、日志、审批、接口、回滚和审计。过去我们习惯用 Z 事务码、Z 报表、SAP Workflow、Batch Input、LSMW、GUI Scripting 把这些事情补起来，短期内确实能跑，但系统越用越重，升级越改越难，业务变化越快，技术债就越难压住。这也是 API Pull Factors 这个话题真正有价值的地方。所谓 API Pull Factors，并不是简单喊一句以后都用 API，也不是把所有 ABAP 程序都包装成服务。它更像一种架构上的吸引力，把流程执行、系统集成、自动化平台、AI Agent 和 Clean Core 慢慢拉向同一个方向。SAP 团队越早把核心业务能力以 API 方式暴露出来，越容易在自动化、低代码、流程挖掘、云迁移和 AI 场景里保持主动。SAP 这些年一直强调 Clean Core，其中一个很关键的原则，就是扩展要尽量使用稳定、受支持、可升级的接口，而不是直接修改核心对象。SAP 官方关于 Clean Core extensibility 的资料里明确提到，扩展要在需要的地方做，但同时要保障系统升级顺畅；SAP Learning 对 released APIs 的课程也强调，在 SAP S/4HANA Cloud 的 Clean Core 思路中，使用 upgrade stable interfaces 是非常核心的一环。这和很多 on premise 客户的现实情况形成了鲜明对照。业务部门听到