The Rev-Trac Release Management Workbench allows for an organization to recognize and separately control SAP changes which are not assigned to an SAP release.
This can be used to benefit an organization in a few ways and can be used differently depending on the type of change.
In this article I will discuss some of the benefits for the unassigned change feature in both an SAP project and an SAP support environment.
Useful variants
Using a variant in the Release Management Workbench, it is possible to make views very specific to the desired controls.
As release management is set up to use a common Rev-Trac-Project, it is likely that an organization’s various SAP support tracks and SAP project Tracks will be distinguishable by the Rev-Trac-Project field.
So it is important to set up variants specific to the SAP Releases that the organization would like to control.
To further control the Release Management Workbench, the variants should filter undesired requests from the view usually these are complete or deleted Rev-Trac requests.
Support environment
In an SAP support environment, it is possible to have the individual SAP changes work quite separately without ever interacting with a release until they have been fully tested, code reviewed and are ready for production.
In an ideal environment, the Change Advisory Board (CAB) will log into the Release Management Workbench during their production go-live meeting and will have a list of SAP changes in the unassigned changes column, which are at various statuses.
Further control of the variant will allow for the CAB to filter the unassigned changes to those in a status of ready for production.
All SAP changes which are marked ready for production are in a state which will allow for them to be added to an SAP support release and approved for migration to production at a release level.
The CAB will have full control of which changes can be added to the support release for that period through dragging and dropping the changes from the unassigned changes, or across releases.
Project environment
Due to the nature of SAP project work, it is often clear which SAP release a change should be part of early in the life of the SAP change.
As such, when the CAB gets ready to approve a project release either to pre-production or production (at the release level), the release will already have been built, and will include a proposed list of SAP changes for migration to the next environment (pre-production or production depending on the landscape setup).
The CAB will likely find changes which are not yet ready for production and may risk delaying the release.
At this time, the CAB or Release Manager can drag the pre-mature changes out of the release, either into the next scheduled release, or into the unassigned changes column.
At this time the CAB can also review the unassigned changes, to see if any are suitable to be included in the current release (perhaps relegated from a previous release due to issues in development, delayed testing, object collisions or dependencies).
The unassigned changes can be used as a powerful feature of the Release Management Workbench to improve quality, transparency and agility during a release go-live.
Over the next few months I will be providing some more insights into the abilities and recommended approaches to managing SAP releases with the use of the new Release Management Workbench.
