Change Request Management (ChaRM) helps facilitate the life cycle of a production release. You can use these releases to implement planned maintenance, upgrades, and enhancements in SAP systems. As any change manager knows, a successful release depends not only on the technology supporting your solution but also on the use of standard routines to ensure that your technical functions are appropriately enabled. I’ll share best practices for SAP release management that are process focused and relevant across many industries. Then I’ll provide tips for using ChaRM maintenance cycles to manage a release. This is article is aimed primarily at change managers and release managers.  

The Production Release to an SAP Solution

SAP production releases are a routine (e.g., weekly, monthly, or quarterly) exercise to incorporate system changes into the SAP production environment. The need for change in your systems can come from errors found in the productive environment and reported to the Service Desk in SAP Solution Manager. They can also be standard maintenance activities related to the following:

• Changes to SAP configuration
• Custom development to reports, interfaces, conversions, enhancements, and forms (RICE-F)
• Infrastructure
• SAP software
• Security
• Data structures
• Master data changes

A successful release depends on engaging the right teams and resources into your release cycle. See Table 1 for a description of key resources and teams to engage in a production release.   Now let’s look at some standard milestones to achieve on a production release. In this example, a monthly release period is given starting four weeks ahead of the release date, with T being the day of release. The order of activities below is important, but the time frames are suggested and can be adjusted as necessary depending on the amount of time allotted to implement a release.

• T-28: Release kick-off and scope review — to be conducted with key stakeholders of the release
• T-24: Perform data refresh (production to quality) — copy of production data down to lower environments. Ensures the quality assurance environment matches the production environment for execution of user and functional testing. Typically, a specific client in a lower quality environment is designated for the data refresh and subsequent testing.
• T-22: Create a maintenance cycle and open quality and development environments — lower environments open and development activities begin
• T-21: Additional scope review — identify any new change controls added to the release and assess them for dependencies and any end user impacts. For example, is communication or user education required as a result of these changes? Identify change sponsors for each change request.
• T-15: Release closed — all approved ChaRM change controls must be in the quality assurance environment (i.e., this is the test phase of a maintenance cycle, so any coding that is complete should be transported to a test environment). Setting a date to close the release allows limitations on the size of the release and ensures enough time for development and testing.
• T-14: Final cross-functional review and testing requirements — key milestone of the release where all change requests are submitted and the team can sign off on full development and testing requirements
• T-8: Technical and functional testing complete — allowing a period of several days between completion of testing and go-live is a best practice
• T-7: Deployment review — review of schedule and order of activities, sequencing of transports, timing for deployment, and production validation schedule prior to the go-live date
• T-3: Formal go or no-go approval — represents the final change to review change requests for accuracy and ensure all defects are corrected prior to go-live
• T-0: Go-live — all approved scope moves to production. This typically occurs after standard business hours to ensure minimal disruption to the production environment.

As planning begins for the production release, scope confirmation is an important step to ensure that the capacity of development and testing teams is not exceeded and dependencies of change controls within the release are identified. A careful scope review also highlights any dependencies to be aware of or effects the release could have on a production environment. By using transaction CRM_DNO_MONITOR in SAP Solution Manager, you can generate basic reports that show approved change controls along with their statuses for each release. A developer can also develop customized reporting that supports an organization’s specific needs.

Establish a ChaRM Maintenance Cycle

To implement a production release, create a project in ChaRM. Within that project, establish a maintenance cycle using transaction SOLAR_PROJECT_ADMIN. Set up the project for a planned period of time in which development and testing for change requests will occur and then be implemented together at a designated date. A maintenance cycle is a project set up in ChaRM that represents the time frame in which change requests undergo development. Transport records are generated and migrated into follow-on systems for testing. The conclusion of testing signifies that all the transport records in the maintenance cycle are ready to implement into your SAP production system. Maintenance cycles are generated from transaction type SDMN and include a task list in the Schedule Manager. This task list represents all the change requests and subsequent transport records that are included in the release. Figure 1 represents a maintenance cycle that has an established task list.     The maintenance cycle represents all the change requests that will be developed and tested in the lower environments and, once verified, implemented into a productive environment. Change requests are represented as corrections in ChaRM and created by selecting the appropriate transaction type. Three standard types of corrections are: Regular (use the standard task list), Urgent (separate task list created), and Test (no task list needed). The following transaction types are used to support maintenance releases:

• SLFN — Service Desk ticket (may be turned into a change request through the use of the document flow)
• SDCR — Change requests
• SDHF — Urgent corrections
• SDMJ — Normal corrections

Using transaction code CRM_ORDER, access the Business Transaction screen by selecting Business Transaction > Create (Figure 2). This produces the screen in Figure 3, from which you can select multiple transaction types. A change request is generated for every change generated in the release. Change requests may be created due to an error reported to the Service Desk, an individual enhancement request, or a need for system maintenance or upgrade.     Each maintenance cycle follows standard phases. The release manager controls the movement of the change requests in the maintenance cycle through the phases shown in Figure 4.   Now I’ll go through each phase in a little more detail.

Phase 1: Created

This is the original status of the maintenance cycle.

Phase 2: Development Without Release

The status changes as soon as the maintenance cycle is created and indicates that the cycle is open for development. You can create, approve, and add change requests to the maintenance cycle, and generate and transport the transport records that are created, but not release them.

Phase 3: Development with Release

When development of change requests is complete, the maintenance cycle changes to this phase and transport records for each change request can be released into a testing environment.

Phase 4: Test

A code freeze is enacted and the priority is to test the development to identify defects. Typically the transport records are moved into a new environment dedicated to testing that is separate from the development environment. You can then report any errors that are found to the developers through the use of test messages. The transport records are moved back down to the lower environments for additional development and correction. At the conclusion of this phase, your set of changes to import into productive environments should be complete.

Phase 5: Preparation for Go-Live

This phase allows for the addition of more change requests via urgent correction (SDHF). This would be considered an emergency change control and introduced only for reasons where an immediate release or break/fix is required. The transport records and any new tasks that result from any new corrections must be assigned to the maintenance cycle through the use of the task list and schedule manager. Prior to formal go-live, the entire list of transport records in the maintenance cycle is exported from the test environment and creates what is known as the project buffer.

Phase 6: Go-Live

The project buffer (containing transport records for all change requests in the maintenance cycle) is imported into production systems. The order in which transport records are imported mirrors the exact order that occurred when the transport records were exported from the test phase. Following import into production systems, each change request can be verified and closed. If a defect is found in production, the change sponsor can elect through the task list in ChaRM to send it back to the development phase to address the error. That action leaves the maintenance cycle open until the full iterative development and testing cycles complete again. In addition to the six phases shown in Figure 4, there are two additional phases beyond go-live.

Phase 7: To Be Closed

When all change requests are confirmed in production systems, change sponsors individually change the status to confirm, then close the change request. Closing a change request closes any associated corrections and Service Desk tickets in the system.  

Phase 8: Closed

All open requests and transactions are decoupled from the task list. The maintenance cycle is officially closed and no additional changes can be made to any associated change requests.   

Change Control Workflow in ChaRM

After establishing a maintenance cycle, use the change management functions in ChaRM to govern your release. You should create individual change requests that represent each item to be included in the release. For normal corrections, one change request is created for each item of work that generates a transport record. For urgent corrections, multiple transport records can be associated with a single change request. Figure 5 represents a blank change request that will be populated with information supporting the particular change.   The fields in this request are typically populated by the individual who is requesting the change. Business partner numbers are entered into each field designated as a role (e.g., sold-to-party, reporter, and change manager). When selecting the iBase/Component, ensure that the correct information is selected as this field cannot be changed once the change request is submitted. Another field to note is the Subject field. This is where you select either to turn this change request into a normal correction or an urgent correction. Table 2 shows a brief overview of workflow for urgent versus normal corrections.   Typically, there are many maintenance cycles established within your SAP system. Both normal and urgent corrections can be included in the same maintenance cycle, but a particular maintenance cycle supports only one iBase. In a situation where you have multiple maintenance cycles established, upon approval of the change request, a pop-up box appears instructing you to assign the change request to a maintenance cycle (Figure 6). The options for assigning the change request are limited to those maintenance cycles established for whatever iBase is selected.   When each change request is submitted and approved for the release, it follows the workflow described in Table 3. Each step in the workflow is achieved through changing the change request status in ChaRM. This workflow is managed by use of the action icon in ChaRM (Figure 7). Traceability is achieved because the task list records and time stamps each move through the workflow. Approvals for each step in the workflow are governed by the business partner or role required to move the change request to the next phase of the workflow.