After an SAP implementation, your organization needs to put routines and tools in place to support day-to-day operations. A large part of your operations will be dedicated to managing changes implemented to your productive system. Change Request Management (ChaRM) is a useful SAP Solution Manager tool that facilitates the entire life cycle of this process, including:

• Issue detection  
• Change request submission and approval
• Development and testing  
• Release to production

For a production change request management process, you should enable ChaRM for maintenance (production) cycles. For the purposes of this article, I focus on using a maintenance cycle in ChaRM to manage your production environment.

A governance and production change request approach should be established in your organization so there is a defined process for handling the various types of changes that may be implemented in your productive environments. You need to have clearly defined roles in this process. Typically, an organization can expect to have the roles shown in Table 1 involved in the change request life cycle.

Table 1

Example of typical required roles for a production support group

You can establish these roles in ChaRM through role customization. Your SAP security team can work with you to build the authorizations for these roles. The roles you create will also be fields that are populated in your change request transactions in ChaRM — these fields are a key component in the workflow process and help support reporting out of ChaRM.

Most organizations want to establish their Service Desk support ticket tracking in SAP Solution Manager as well as ChaRM (this is outside of the scope of this article). This is not required — as support tickets and change requests are separate transactions — but establishing both components allows for end-to-end management of an issue. ChaRM facilitates the transaction from the initial report of a problem to the Service Desk to its eventual resolution through a change request.

You can choose to enable both the support ticket and change request functionality together, or you can use one initially and gain proficiency with that functionality before rolling out the other. The Service Desk and ChaRM functions within SAP Solution Manager complement each other and are closely integrated. They are designed to work together but they also can function separately. I recommend enabling both functions at the same time. Although this initially is an additional complexity for your organization, the benefits of using both together outweigh the challenges. Using them together capitalizes on the integration and traceability provided by the Service Desk and ChaRM. It allows for smoother associate (and end user) solution adoption and acceptance with the introduction of one new process rollout instead of breaking them apart. The recommendations in this article related to ChaRM assume that your organization is already using SAP Solution Manager Service Desk functions.

Generate a Change Request from a Support Ticket  

Using transaction CRM_ORDER, you can access multiple transaction types. Figure 1 shows buttons for SAP Change Request, Support Ticket, and Urgent Correction. This is the screen you use to generate transactions for change requests and Service Desk tickets.

Figure 1

Transactions available from the transaction CRM_ORDER screen

In the example in Figure 2, support ticket 2981 was generated by the Service Desk with a category of Operations Request. In this scenario, the organization has decided the issue needs to be addressed by introducing new code to the production environment. Therefore, a change request needs to be created. By clicking the actions icon on the toolbar of this screen and using the drop-down menu, you can turn the support ticket into a change request by clicking Create Change Request.

Figure 2

Example of a support ticket in process of changing to a change request

Click the document flow icon (Figure 3) on the same screen to see a table with the new transaction (change request) that was generated by your actions in Figure 2.

Figure 3

Click the document flow icon

Note that the original transaction, support ticket 2981, is still open. An additional transaction, SAP Change Request 2982, has been created (Figure 4). These transactions will always be tied to each other and the original support ticket will remain open until the change is released into production and verified. This feature is valuable because it ensures traceability and stores historical information on both the initial support ticket and the change request.

Figure 4

Both the support ticket and change request are visible

If you select the Next document field (Figure 4), SAP Solution Manager opens a new transaction in ChaRM (Figure 5). This new transaction is your change request. The original Reported by, iBase/Component, and Priority fields populated in your support ticket are carried over to the new transaction. The change request has additional fields, such as Change Sponsor and Change Advisory Board (Figure 5). The names and purposes of these fields are editable in the off-the-shelf solution, and with simple configuration, they can be changed to suit your organization’s needs.

Figure 5

Example of screen generated after turning a support ticket into a change request

The Change Sponsor is one of the roles identified in Table 1 as part of the change request life cycle. In this instance, the Change Advisory Board serves as a field to select which team will review and approve this request. These fields are populated with a business partner ID that can be designated as either an individual or a group. More on generating business partner IDs can be found in my previous article, “Establish a Production Support Framework Using SAP Solution Manager.”

After accessing the change request screen shown in Figure 5, you can add details necessary to change it from a support ticket into a change request (Figure 6). In this scenario, because this item started as an issue reported to the Service Desk and was then determined to need a change request, it is categorized as a Break Fix.

Figure 6

Example of a change request in edit mode

By clicking the document flow icon (previously shown in Figure 3), you can go back to the preceding document in the workflow (Figure 7). In this case, the preceding document is your original support ticket. This is an example of the integration of functions provided by ChaRM. This also supports traceability of records and maintains a history of the actions taken from your support ticket through your change request.

Figure 7

Workflow screen showing the preceding document

Generate a Standalone Change Request

In the example I’ve just shown, the change request was generated after a service ticket was entered. With ChaRM, these functions do not have to be tied together. There may be situations where an enhancement is needed and a release manager may sponsor a change request directly — without needing a service ticket. In this situation, you can still use transaction CRMD_ORDER. Figure 1 showed the main screen from this transaction where you would click the SAP Change Request button. To create a change request directly, you need to enter the appropriate information into the fields in Figure 8.

Figure 8

Create change request screen

Regardless of the way you submit a change request, with ChaRM, you can add more details than the standard fields provide using the free text field (shown on the bottom right in Figure 8). This field has drop-down selections with various categories that you can add and change with simple configuration. Using the drop-down menu, you can enter information for a particular category in the free-form text field and it will be saved in the Transaction Data tab. Figure 9 has examples of category types you may want to include in the free text field.

Figure 9

Example of categories in free text field

The change request primary data was entered on the Fast Entry tab. To see additional information on the history of your transaction, click the Transaction Data tab. This provides you with multiple options for viewing the details about the transaction and historical information. You can also attach documents using the Documents tab. If you have specific information that you would like to capture, you can create a new customized field (e.g., Customer Fields) to use for this purpose (Figure 10). Note that the sample screen has two Customer Fields tabs, but it is more efficient to just have one.

Figure 10

Example the of Transaction Data tab

Standard ChaRM Change Request Statuses and Life cycle

When you are ready to submit your change request to the appropriate approving body (e.g., a governance committee or change control board) from the Fast Entry tab, click the action icon (Figure 11). From the drop-down menu that appears, select Review the Change Request. This changes the transaction status from Submitted to Ready for Review, which indicates that this item is ready to be reviewed and approved.

Figure 11

Change the status of the change request to Ready for Review

Following the approval of the change request, you can use ChaRM to guide the ticket through development, testing, and release to production phases. You can generate transports necessary for code or configuration required for each change request from ChaRM. ChaRM also supports iteration cycles because you may need to send the item through the development and testing phases several times before you eventually approve the release to production. The status of the change request changes as it moves through this life cycle. The status is primarily controlled manually using the action icon (Table 2).

Table 2

Standard ChaRM change request statuses

ChaRM Change Request Transaction Types

As you build out your operations group, take into consideration that there are two types of change transactions you can use in ChaRM: urgent corrections and normal corrections. Deciding how to use them depends on your organization’s needs and your maturity in managing your SAP solution. Both of these functions can be enabled, or you can select to only use one of them. The primary focus of this article has been on the urgent correction, but because it is important to understand both types, I include this section. There are pros and cons to both described briefly in Table 3.

Table 3

Differences between urgent and normal corrections

You can apply the urgent correction functionality to separate transactions. For ease of rollout, your organization may want to consider starting with only the urgent correction functionality. You can create separate transactions: one for routine standard requests and another for truly critical requests. The standard transaction would be a change request that can be tied to the workflow and linked to from a Service Desk support ticket. After this change request is approved, an urgent correction is created.

The second transaction would be a true urgent correction, so you would not need to create separate support ticket and change request transactions. This transaction would be created for situations where there is an urgent defect that needs to be addressed immediately. It would not have the additional approvals, rigor, and workflow actions in the cycle of a change request. Because you don’t have a rigorous approval process in this situation, you should limit the security authorization on urgent corrections to a select few people in your organization so you have tight control over this transaction.