Having studied, implemented, and supported SAP Solution Manager since its earliest versions, I was really excited last year to be included in the 7.1 Ramp-Up program. Specializing in IT service management (ITSM) capabilities, I was particularly excited with the new look of Application Incident Management (AIM) and Change Request Management (ChaRM) and all the new capabilities that came with the SAP CRM 7.0 infrastructure. At last, these services and processes were given the overhaul needed to make it easier for companies to stick with what they are already paying for and adopt Solution Manager to handle all types of change, not just changes related to SAP.

Throughout the time I have implemented these scenarios (Service Desk and ChaRM), I have come across what seems like every requirement imaginable. Most requirements were met with standard functionality, some achieved with development, and some just couldn’t happen. The development hours on the table and the fact that key requirements just weren’t going to happen led most companies to look at third-party alternatives for a change control tool. Understandably, if a tool is selected as a central platform to manage change, you want to go with something that is the best fit for your organization.

Over the years, SAP has continued to expand ChaRM’s capabilities, making it harder to develop a business case to procure, license, deploy, and maintain a change control tool when Solution Manager has come close in satisfying core requirements. Release 7.1 provided the interface, openness, and best-of-breed messaging capabilities. Support Package 05 (SP05) shows that consistent customer requirements, where third-party tools once ruled the field, are now available in ChaRM.

I’ll walk through some questions and requirements that I’ve heard during my experience as an introductory note to each section. Then I’ll describe the feature in SP05 that addresses these common requirements. But first, I’ll provide a quick introduction on maintenance cycle strategy to set the stage.

Maintenance Cycle Strategy

As part of every ChaRM implementation, a maintenance cycle strategy must be defined, agreed upon, communicated, and strictly adhered to once ChaRM is live for supporting changes to your production environment. A maintenance cycle strategy is how and when an organization chooses to handle the import of transport requests to the production system. It deals with every aspect of the release. You may be familiar with the two major change processes available in ChaRM for managing transportable changes to the SAP landscape:

• Normal change: Changes that are bundled and move, per a planned release cycle, to the follow-on systems together controlled by phases in the maintenance cycle. The phases represent the time that changes are developed, tested, and promoted to production. Examples of normal changes can include minor fixes, functionality requests, or routine maintenance.
• Urgent change: Changes that are deemed an emergency and must have a fast track to production. They receive their own task list (for workflow purposes) and are independent from the overall maintenance cycle. They remain in the production buffer and are reimported once the maintenance cycle goes live.

For normal changes, the organization must determine the duration of each maintenance cycle phase and when the import to production should occur. For example, the development occurs during a five-day window, the testing occurs during a two-day window, and the go-live happens every other Friday. Additionally, the organization must determine exactly what constitutes a normal change and what can be approved as an urgent change. All these strategies, planning efforts, and decisions encompass the maintenance cycle strategy.

Typically, once an organization goes live with ChaRM, it starts with a weekly maintenance cycle. In some cases, I have seen organizations start off with urgent changes, which is okay as long as there is a strategy to wean off urgent changes and move into a routine maintenance cycle that eventually processes normal changes.

Going live with ChaRM can be a big organizational change, so sometimes it is necessary to provide more flexibility out of the gate, familiarize the organization with how ChaRM operates in a live environment, stabilize the system, and then gravitate to a more controlled process. The goal should be eventually to get to a bi-weekly maintenance cycle, and then hopefully pushing it to monthly. Of course, this all depends on the stability and size of the landscape — maintenance cycle strategies across organizations differ.

Often, organizations get in a rhythm of processing urgent changes and tend to abandon the maintenance cycle strategy once ChaRM is live. They think: Going live with ChaRM was a major milestone, it’s working great managing our production changes, and our auditors are happy. Understandably, organizations keep the habit of creating only urgent changes and have a hard time migrating to normal change processes.

To reduce the impact to production operations, you should eventually work toward the normal change process. Having hourly, daily, or one-off imports into production with urgent changes can introduce risk and compromise stability in any production landscape. However, limitations in prior versions of ChaRM have kept companies complacent with using only urgent changes. ChaRM was not flexible enough within the normal change process to provide companies with incentive and motivation to migrate away from strictly urgent changes. SP05 changes that.

In the following sections, I explain features that are delivered in SP05 that provide the flexibility and functionality companies have longed for to make the normal change processes a reality within their organizations. Further, these features narrow the gap between what ChaRM offers versus what third-party vendors offer with similar change control tools and they help build the business case to implement or upgrade to ChaRM in 7.1. After all, you already own it.

Change the Maintenance Project Assignment

Problem: A normal change was assigned to the maintenance project for the next release, but it requires more time for development and testing. I don’t want it to go live with the current release, so how can I assign it to a later release?

Solution: I hear of this situation often. Until SP05, there was no easy way to do this, nor was there functionality built within ChaRM to facilitate the switch of a maintenance project or cycle automatically. Workarounds (e.g., backing out of development objects) had to be performed to accomplish this. Alternatively, the change document could reside unattended and be taken over by the next maintenance cycle after go-live (an automatic feature that has been a great functionality in ChaRM for some time). While these workarounds essentially worked, reporting data was compromised and it wasn’t the seamless solution that was provided by third-party change control tools.

Figure 1 provides one section of a maintenance cycle strategy. In this example, the company was adhering to a quarterly release, but normal corrections needed to be assigned to Release 2.

Figure 1

Quarterly maintenance cycle strategy

Now, normal changes can be easily reassigned to another maintenance project directly within the normal change document via the Change Project Assignment option within a normal change created in the CRM Web UI interface in Solution Manager (Figure 2). This functionality is not relevant for urgent changes.

Figure 2

Change the project assignment

Table 1 provides details about when a normal change document can be assigned to another project. As described in Table 1, once transport objects come into the picture, they must be decoupled from the normal change before you change the project assignment. Further, once the transport is released, the Change Project Assignment option is not available. Changing the project assignment for released objects has been rumored (but not confirmed) to be available in SP08.

Table 1

Criteria for changing the project assignment

Decouple Transport Requests from Change Documents

Problem: A normal change has been created and set to the status of In Development. A developer has created a transport request and already assigned development objects to it. As a change manager, I’ve determined that the objects should not go live. How do I back the objects out of the normal change?

Solution: As mentioned in the previous section, once a normal change has reached the status In Development and transport objects are assigned, they must be decoupled from the document for the project to be reassigned.

Another use case for this new feature is if the objects are not ready to go live with the current maintenance cycle. The objects can be decoupled from the normal change to remove the link to the development objects that shouldn’t go live in the current release. If a maintenance cycle must be moved to the go-live phase, and development objects are included within the normal change that aren’t ready to go live, they can be decoupled from the normal change using this functionality.

To decouple a transport request highlight the request and select the option More > Decouple Transport Request from the Transport Management assignment block (which you can find by scrolling down on the normal change) as shown in Figure 3.

Figure 3

Decouple the transport request

Confirm the webpage dialog box by selecting Yes as shown in Figure 4.

Figure 4

Confirming the decouple

Once the objects have been decoupled from a change document, they should be assigned to another change document to help mitigate the risk I just mentioned. This action is performed in the same manner as the objects were decoupled.

Select the Assign Transport Request option from the Transport Management assignment block as shown in Figure 5.

Figure 5

Assign the transport request

You then have several options for searching for the transport request as shown in Figure 6. Highlight the appropriate transport request and click the Assign Transport Request button.

Figure 6

Search for the transport request

The transport request is now assigned to the normal change document (Figure 7).

Figure 7

View the assigned transport request

Request Preliminary Import to the Production System

Problem: My normal change has become urgent! How do I get it into production now?

Solution: Having a normal change suddenly turn into an emergency is common. Similarly, this is another area in ChaRM that was lacking in flexibility and was keeping companies from eventually weaning themselves off the use of only urgent changes.

Naturally, companies feel comfortable with urgent changes. There are controls, intuitive workflow steps, and audit capabilities available. Moreover, urgent changes provide the flexibility of being able to import the change into production at any time.

Normal changes, as previously described, are grouped together as a bundle and are transported to production all at the same time. Previously, if a normal change became urgent, workarounds had to be used for the right transports to get in at the right time.

With SP05, preliminary imports to the production system can be requested directly within the normal change document. I’ve decomposed the process for the preliminary import in Figure 8. The main text within the box identifies which action must be selected within the normal change document. The text within italics identifies the status that the document goes into after each action is executed.

Figure 8

Preliminary import process flow

As you can see, a preliminary import of a normal change to production requires its own process, approval, and status values. For this reason, there are new status values introduced to the SMMJHEAD status schema. It is important that the piece lists are activated (part of transaction SOLMAN_SETUP) so these changes take effect. Additionally, your security authorizations must be updated so your ChaRM users have the appropriate authority to request, approve, test, release, and import the normal change prematurely to production.

Status-Dependent Import of Transport Requests

Problem: Just because I confirmed the successful test of my change doesn’t mean I wanted it imported into production!

Solution: With the Status-Dependent Import of Transport Requests function available in SP05, change documents can be imported into production based on their status value. This function is only available if you follow the related configuration steps. As is, the system imports all change documents that have released transport requests when the maintenance cycle phase is switched to go-live. For example, if a normal change is in the status Preliminary Import Requested and the maintenance cycle is switched to go-live, since the status of the transport request is released at this time, it goes into production. This overwrites the entire preliminary approval procedure.

Other examples that benefit this functionality:

• Urgent changes being imported to production only when their status has reached Released for Production
• Test messages being imported to production only when their status is Confirmed

Nathan Williams

Nathan Williams is the Global SAP Solution Manager Practice Lead at Monocle Systems. For over a decade, Nathan has supported organizations in their efforts to leverage SAP Solution Manager as an integral component to manage their SAP solutions across the entire application lifecycle. Coordinating with IT, business, and program management teams, he has effectively defined strategies to help SAP customers seamlessly transition to SAP Solution Manager processes and capabilities. He is the author of ITSM and ChaRM in SAP Solution Manager and a co-author for SAP Solution Manager – Practical Guide.  

You may contact the author at nwilliams@monoclesys.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.