跳至正文

SAP 变更工具:Cloud ALM、ChaRM、Rev-Trac、ActiveControl

哪款 SAP 传输和变更管理工具适合您的系统环境:SAP Cloud ALM、Solution Manager ChaRM、Rev-Trac,还是 ActiveControl,也就是当年以 Transport Express 名称销售的那款工具。

开发人员在多块屏幕上查看代码和仪表盘,下方是技术变更管理的标题
目录
  1. 变更管理体系必须覆盖什么
  2. 四款工具
  3. SAP Cloud ALM
  4. Solution Manager ChaRM
  5. Rev-Trac
  6. ActiveControl(前称 Transport Express)
  7. 四款工具如何对比
  8. 哪款工具适合哪种情形
  9. 常见问题

SAP 技术变更管理工具控制着什么内容、以什么顺序、经由谁的批准进入生产。几乎每一次评估都会出现四款工具。SAP Cloud ALM 是 SAP 为新项目选择的战略方向。Solution Manager ChaRM 是本地部署环境中成熟的原生选项。Rev-Trac 适合高传输量和并行开发。Basis Technologies 的 ActiveControl,最初以 Transport Express 的名字销售,是另一款主要的第三方选项。您的部署模式和传输量,比任何功能对比都能更快地缩小候选范围。

以前我在为一家欧洲制造集团主持上线时,吃过一次狠亏。一位开发人员没有经过任何批准,就把一个传输请求直接移入了生产。没做任何检查。系统没有崩溃,但库存数字乱了套,我们花了两天才清理干净。从那时起,我们才认真对待变更工具。

我刚开始管理 SAP 系统环境时,以为传输请求只是技术上的交接:移动代码,测试,完事。后来漏掉了一个依赖项,我改变了这个看法。真正重要的是下面这几个部分:

  1. 变更请求工作流。 没有未记录的变更,没有后门。一切都要有迹可循。
  2. 传输排序。 顺序错了,您就得花上几个小时去修复各系统之间的不一致。
  3. 对象历史。 谁在什么时候、为什么改了什么。
  4. 依赖和冲突检查。 常被跳过。造成的痛苦最多。
  5. 审计日志。 即使没有 SOX 要求也有用。出问题的时候您会需要这条轨迹。
  6. 审批关口。 在任何东西到达生产之前,设置恰当的摩擦。
  7. 受限的移动权限。 并不是每个人都需要导入到生产。

通常有四类问题会触发工具评估。传输请求被直接推到生产。各部门的审批方式不同,财务用工单,物流用邮件。两位开发人员在不同的传输请求里编辑同一个对象,于是最后一次导入覆盖了另一个。还有没人有时间去写的文档。

每一项变更进入生产应走的路径这四款工具把这些控制自动化。跳过其中任何一项的传输请求,都是一起等待发生的生产事故。
  1. 变更请求有文档记录,没有后门
  2. 审批关口生产之前设置恰当的摩擦
  3. 排序和冲突检查先检查顺序和依赖项
  4. 导入生产只有被允许导入的人才能操作
  5. 审计轨迹谁在何时为何改了什么

生产中的每项变更都能追溯到一个已批准的请求

SAP Cloud ALM

SAP Cloud ALM 是 SAP 基于云的应用生命周期管理服务,是 Solution Manager 的继任者。它包含在带 Enterprise Support 的 SAP 云订阅(云版本)中,也包含在本地部署客户的 SAP Enterprise Support 中。

它的变更和部署管理用“特性”把变更文档与承载变更的传输请求捆绑在一起。对于 S/4HANA Private Edition 以及 7.40 及以上版本的本地部署 ABAP 系统(包括 ECC),它连接到变更和传输系统(CTS)。在 Public Edition 中,它使用 Adaptation Transport Organizer;对于 BTP 和 Integration Suite 的内容,则使用 SAP Cloud Transport Management。不支持 CTS+。

有两个限制很重要。SAP 将质量关口管理(ChaRM 具备这项功能)列为目前不在 Cloud ALM 的范围内。而且 SAP 不打算转移 ChaRM 的变更数据;它建议先在 Solution Manager 中关闭未完成的变更周期,然后再激活 Cloud ALM 的部署管理(SAP Support)。对于受监管的环境,或带有 Retrofit 或数字签名的复杂 ChaRM 配置,SAP 自己的指引是等缺失的功能补齐之后再迁移。

适用情形: 您正在任意版本上启动新的 S/4HANA 项目,您运行 RISE 或 GROW,或者您计划退役 Solution Manager。在 Cloud ALM 覆盖这些功能之前,预计要在自己的流程里补上审批关口。

Solution Manager ChaRM

如果您购买了 SAP Enterprise Support,您就已经拥有 Solution Manager 7.2 中的变更请求管理(ChaRM)。大多数客户只用了它所提供功能的一部分:变更请求和变更文档、紧急变更、副本传输、双系统环境 Retrofit 和质量关口管理。

我认识一家制造业的 SAP 客户,当时正在争论是买一款外部工具,还是用它已有的 ChaRM。它的量大约是每天 50 到 60 项变更。评估了它的依赖要求之后,我们发现 ChaRM 可以胜任,无需额外许可。三个月后,它已经管理了 2000 多个传输请求,没有出过一次部署问题。差别在于质量关口和审批工作流设置得当。

问题在于时间。“包含在许可里”不等于免费,而一套好的 ChaRM 配置需要数月时间。Solution Manager 7.2 的主流维护在 2027 年底结束。购买了 Business Suite 扩展维护的客户,可以获得 Solution Manager 到 2030 年的有限扩展维护,其中仍包括变更控制管理。

适用情形: Solution Manager 已经上线,您的审计人员期望完整的可追溯性,而且您今天就需要质量关口或 Retrofit。请把迁移到 Cloud ALM 的计划与您的 S/4HANA 时间线放在一起规划,而不是启动一个新的 ChaRM 建设。

Rev-Trac

Rev-Trac 在整个 SAP 系统环境中自动完成传输排序、冲突检测和审批,并原生运行在 SAP 系统内。该厂商目前声称,其客户的发布周期加快了 60%,传输错误减少了 99%(Rev-Trac)。请把这些当作厂商的说法,并要求提供与您的系统环境类似的客户参考。

在我密切跟进的一个实施项目中,团队平均每月出现 15 起生产问题,大多数能追溯到排序不当。部署 Rev-Trac 三个月后,这个数字降到了两起。自动检查在冲突到达生产之前,几乎全部标出。

这些成果不是装上就有的。我认识一家全球性公司,没有把依赖规划设置好就上了 Rev-Trac,挣扎了好几周。Rev-Trac 每年的费用可能在 15 万至 50 万美元之间,取决于系统和用户数量。在足够复杂的环境里,您买的是更少的生产事故,而不是一款工具。

适用情形: 您每天运行数百个传输请求、有多条并行开发线,或者 ECC 与 S/4HANA 混合的系统环境,而且冲突已经在到达生产。

ActiveControl(前称 Transport Express)

本文早先的版本把“Transport Express”描述为一款独立的轻量级工具。那是错的。Transport Express(有时写作 Transport Expresso)是 Basis Technologies 变更管理产品最初的名字,后来改名为 ActiveControl。如今它是一款经 SAP 认证的变更、发布和 DevOps 自动化工具,具备审批工作流、副本传输、ServiceNow 集成和 CI/CD 流水线支持(Basis Technologies)。它与 Rev-Trac 是竞争关系,而不是低一档的产品。

一位制药行业的客户,无法为昂贵的发布协调工具找到合理的理由,于是换用 Transport Express 来获得更好的变更文档。两个月内,其传输错误减少了 65%。

适用情形: 您想要把自动化的 SAP 变更和发布管理,连接到更广泛的 DevOps 工具链,而且 Rev-Trac 也在您的候选名单上。

这是我为决策所做的定位。

SAP Cloud ALMSolution Manager ChaRMRev-TracActiveControl
出品方SAPSAPRev-TracBasis Technologies
许可包含在 SAP 云订阅和 Enterprise Support 中包含在 Enterprise Support 中;需要配置投入商业订阅商业订阅
覆盖的系统Public Edition(ATO)、Private Edition 和 ABAP 7.40+ 本地部署(CTS)、BTP(Cloud Transport Management)通过 CTS 和 CTS+ 的 ABAP 系统ECC 和 S/4HANA 系统环境ECC 和 S/4HANA 系统环境
审批和质量关口特性审批;质量关口管理尚未纳入范围完整的质量关口管理基于规则的审批路由可配置的审批工作流
冲突和排序检查按顺序部署特性;请向 SAP 确认当前范围跨系统对象锁定和降级保护(如已配置)自动化,核心优势自动化
DevOps 集成API、Jira 集成有限,需定制接口Jira、Git、Jenkins 连接器ServiceNow 和 CI/CD 集成
未来SAP 的战略工具主流维护于 2027 年结束厂商路线图厂商路线图

没有恰当的传输排序和依赖检查,即使经过充分测试的变更也可能弄坏生产系统。在错误的时间移入的好代码,造成的破坏不亚于坏代码。

并非每个系统环境都需要同样程度的控制。先从这些问题开始:

  1. 您所在的、或者正在迁往的部署模式是哪一种:Public Edition、Private Edition、本地部署 S/4HANA,还是 ECC?
  2. 平时和发布高峰时,每天有多少个传输请求?
  3. 有多少个团队并行开发,分布在多少个时区?
  4. 审计人员是否需要 SOX、GxP 或类似要求的传输请求级证据?
  5. 审批今天是真正的控制点,还是靠邮件追着要?
  6. 开发人员有没有在生产中覆盖过彼此的工作?
您的情形我会从哪里开始
在 RISE 或 GROW 上的新 S/4HANA 项目Cloud ALM,只有在传输量或并行开发线需要时,才加上 Rev-Trac 或 ActiveControl
本地部署系统环境,ChaRM 运行良好在 S/4HANA 迁移期间保留 ChaRM,然后规划切换到 Cloud ALM
受监管行业,ChaRM 中有 Retrofit 或数字签名留在 ChaRM,直到 Cloud ALM 覆盖这些功能;如果 2027 年迫使您做决定,可以考虑第三方工具
每天数百个传输请求,并行开发线Rev-Trac 或 ActiveControl,同时用 Cloud ALM 做文档
系统环境小、传输量低、没有 Solution Manager采用严格 CTS 路线和审批的 Cloud ALM

在复杂的系统环境中,答案往往是两款工具:Cloud ALM 用于变更文档和与 SAP 保持一致,再加上 Rev-Trac 或 ActiveControl,用于大批量下的排序和冲突控制。

合适的工具,是能解决您实际问题的那一款,而不是功能最多的那一款。我见过 ChaRM 在治理不佳的系统环境里失败,而更简单的方案在纪律严明的环境里成功。变更控制还需要与您的质量关口和测试工具对齐。如果问题出在人而不是传输请求上,我的变更管理计划指南讲了这一面。

什么是 SAP 技术变更管理工具?

控制 SAP 系统变更的工具,使每一项配置或代码变更都被跟踪、被批准,并按正确的顺序导入。评估最多的四款是 SAP Cloud ALM、Solution Manager ChaRM、Rev-Trac 和 ActiveControl。没有它们,您只能依赖电子表格、邮件和记忆,而漏掉一个依赖项就可能造成生产中断。

SAP Cloud ALM 会取代 Solution Manager ChaRM 吗?

会,不过要经过一段时间。Cloud ALM 是 SAP 战略上的继任者,而 Solution Manager 7.2 的主流维护将在 2027 年结束。Cloud ALM 现在已经可以管理 Public Edition、Private Edition 以及 7.40 及以上版本的本地部署 ABAP 系统的传输请求。SAP 不会迁移 ChaRM 的变更数据,质量关口管理也尚未纳入 Cloud ALM 的范围。对于配置了复杂 ChaRM 的受监管客户,建议等这些功能补齐。

SAP Cloud ALM 能管理 ECC 的传输请求吗?

能。Cloud ALM 的变更和部署管理,连接到 7.40 及以上版本 SAP NetWeaver ABAP 系统的变更和传输系统。这包括 ECC、本地部署的 S/4HANA 和 Private Edition。不支持 CTS+,被管理的系统需要装好前提条件的支持包和 SAP Note。

Transport Express 后来怎么样了?

Transport Express,也写作 Transport Expresso,是 Basis Technologies 的 SAP 变更管理产品最初的名字。随着它从传输管理发展为变更、发布和 DevOps 自动化,被改名为 ActiveControl。如果您在对比工具,请把 ActiveControl 与 Rev-Trac 放在一起评估。

Rev-Trac 在什么时候合适?

当传输量很大、多条开发线并行,或者冲突已经在到达生产时。它的优势是自动化的冲突检测和排序。它需要先设置好依赖规划,而且要花真金白银,所以理由在于更少的生产事故。

我该如何选择 SAP 变更管理工具?

先看您的部署模式,再看传输量、并行开发线的数量、审计要求,以及您是否已经在运行 Solution Manager。选能解决您实际问题的那款工具,并为设置和培训做预算,它们比工具本身更重要。

Noel D'Costa

作者

Noel D'Costa

我在航空、政府、金融、零售和制造行业的SAP与Oracle ERP项目中工作了25年,财务出身。我帮助管理层如实界定转型范围,挽救陷入困境的项目,并搭建能够撑过上线第一年的系统。

下一步

您现在正在推进ERP项目吗?

如果这篇文章谈到的正是您当前正在推进的项目,那么一次30分钟的交流,往往比再花一周做内部分析走得更远。