Introduction
ChaRM kept SAP changes safe. It also kept SAP teams out of the agile delivery model the rest of the enterprise adopted years ago.
Agile principles have become standard in the operating models used by most organizations to deliver changes. Business owners maintain a long backlog of new capabilities that they need, and they prioritize and rank their requirements regularly. The changes that surface to the top are assigned to agile teams who iteratively deliver the new features in bi-weekly sprints. But for most organizations, SAP has remained the exception.
The reason, in many cases, is that SAP changes were historically controlled by a more rigorous governance process using tools like ChaRM in SAP Solution Manager. Properly configured, ChaRM did a good job ensuring there were no exceptions to the change process. However, the workflow was quite rigid, and not conducive to an iterative agile model.
With Solution Manager approaching end of mainstream support, SAP teams are considering their next move. Rather than recreating the past, SAP teams can take this opportunity to align with the same agile delivery model as the rest of the enterprise. This requires rethinking how SAP transport governance will be handled, but achieving an agile delivery model for SAP is not as hard as you might think.
ChaRM kept SAP changes safe. It also kept SAP teams out of the agile delivery model the rest of the enterprise adopted years ago.
Why ChaRM Kept SAP on a Different Track
ChaRM’s controls are thorough, but change documents aren’t always granular enough for agile delivery.
Given the rigid nature of ChaRM’s controls, change documents in ChaRM often get loaded up with a long list of transports. This makes it easier to manage approvals as the actions are applied at the document level, so fewer documents mean fewer approvals. Larger change documents also make it easier to manage dependencies, since ChaRM automatically sequences transports within a change document based on their dependencies.
The downside is that this means the entire change document is held up until every transport in the document is complete. One incomplete transport means, either the release gets delayed, or developers need to back out partial changes. The other issue is that with a whole list of transports piled into the same change document, it’s easy to lose track of what’s included in each release.
By connecting transports with an agile process, you get improved granularity of your changes. By associating transports with the user stories that drove the changes, capabilities can advance independently. When it comes time for the sprint reviews, it’s easy to see which changes made it, and user stories that didn’t get completed don’t necessarily hold up the release.
ChaRM’s controls are thorough, but change documents aren’t always granular enough for agile delivery.
Embedding Transport Governance in the Sprint Workflow
When transport governance runs inside the sprint workflow, SAP teams can deliver in the same sprint cadence.
With Solution Manager retiring, organizations have the chance to deliver SAP changes through the same agile process that the rest of the enterprise already uses. By integrating SAP Transport Management directly into Jira or Azure DevOps, you can maintain an agile process without losing the governance structure of ChaRM.
Here are some best practices for agile management of transports:
- Link transports directly to user stories. By attaching transports directly to work items in Jira or Azure DevOps, the movement of transports is synchronized with your work item status. Completed work can advance as long as all dependencies are met.
- Governance runs inline with the sprint. Rather than lengthy governance approval meetings, changes can be approved one-by-one, and the governance process happens during the sprint. As long as the work item achieves the definition of “done”, the change is ready to move forward.
- Releases have full traceability back to requirements. Every transport in the release is linked to the user story that initiated the change, making it easy to see what’s included, and what testing was executed. Audit evidence is captured as a natural byproduct of the workflow rather than assembled after the fact.
When transport governance runs inside the sprint workflow, SAP teams can deliver in the same sprint cadence.
Conclusion: ChaRM’s Retirement Is an Opportunity, Not a Gap
ChaRM’s retirement is not about replacing a tool. It is about evolving the operating model.
ChaRM enforced the discipline SAP landscapes required, but it also kept SAP teams locked into a delivery model the rest of the enterprise moved past years ago. With Solution Manager retiring, organizations have an opportunity to bring SAP into the same agile workflow.
The path forward is straightforward:
- Make changes more granular. Associate transports with user stories so that work can flow at the pace of the sprint rather than waiting on monolithic change documents.
- Embed transport controls in your agile tooling. Sequencing, dependency checks, and approvals should execute within Jira or Azure DevOps, not in a separate system.
- Treat this as a delivery model change, not a tool migration. The goal is not to replicate ChaRM. It is to give SAP teams the same agile operating model everyone else already has.
SAP delivery does not have to be the exception. With the right integration, it can follow the same rule.
