Since the inception of SAP Solution Manager, there has always been a value proposition for leveraging as much functionality as possible in an effort to lower total cost of ownership (TCO) and increase return on investment (ROI) regarding supporting an SAP environment. Although there was value in adopting a tool that was integrated into the SAP landscape, was business process driven, and was included as part of the company’s maintenance fee, there were challenges. Let’s take a closer look at these challenges and relate them to the topic at hand, Change Request Management (ChaRM).

Challenges with SAP Solution Manager 7.0 and earlier include:

• User acceptance levels of Solution Manager (ChaRM in particular) were mixed between both consultants implementing SAP systems as well as SAP customers themselves. On the consulting side, SAP Solution Manager was often perceived as a tool that lacked the powerful functionality that could be performed by third-party alternatives. The look and feel of Solution Manager was often perceived as too closely related to the standard SAP GUI of an SAP ERP Central Component (ECC) or SAP Customer Relationship Management (CRM) system. Specifically for a change control tool, where end users may typically not be SAP savvy, Solution Manager did not offer the intuitiveness that a third-party Web-based or in-house tool offered.
• Third-party tools for managing changes made their stake in the market early on and continued to build on their expansive functionality to better serve the requirements of their customers. The investment in licensing, deploying, and maintaining these tools further slowed the momentum to develop a logical business case to replace them with ChaRM.
• Even when SAP Solution Manager matured as an operational application life cycle management (ALM) platform, it lacked specific capabilities to manage customer solutions beyond SAP. As system landscapes became more complex with business processes spanning multiple products, the demand rose for a central platform to extend beyond SAP to manage the holistic IT solution.

Solution Manager 7.1 allows you to overcome many of these challenges. The enhancements and new functionality delivered with 7.1 present the SAP market with solutions to pain points associated with prior versions of Solution Manager (ChaRM specifically).

You may also refer to my article “10 Brand-New Application Incident Management Features in SAP Solution Manager 7.1” for more new features delivered with SAP Solution Manager 7.1. The majority of the features described in my previous article also apply to the new release of ChaRM.

Now I’ll walk through the eight key new features involved with ChaRM in 7.1.

1. Transaction Types

A transaction type, also referred to as a document type, is a term that defines the attributes and characteristics of a CRM business transaction. Transaction types exist in Solution Manager for any functionality that leverages the messaging capabilities. For example, problem messages, incident messages, defect corrections, and requests for change are all defined as transaction types in Solution Manager. Individual transaction types that drive each messaging capability support all ITSM processes within Solution Manager (Problem Management, Defect Management, Incident Management, and Change Request Management).

One of the most significant changes delivered with Solution Manager 7.1 is that these ITSM functions are now built on the CRM 7.0 infrastructure. The purpose of this enhancement is to offer better messaging capabilities from both a user interface and functionality perspective. In other words, if you are upgrading to Solution Manager 7.1 and plan to take advantage of the new ITSM features you must transition from 7.0-based transaction types.

Table 1 identifies the new transaction types, their descriptions, and predecessors.

Table 1

Change control transaction types

2. Transaction Copy Tool

Copying transaction types is typically one of the first steps in configuring ITSM functions after enabling post-installation technical and basic settings. Not only is this an SAP-recommended best practice, it is a recommendation that should not be ignored. Copying the standard transaction types into your own customer namespace (i.e., switching the leading character of the naming convention from S to Z or Y) is critical for better scalability, maintenance, and future support of your solution.

Copying the standard transaction types ensures that changes (both during implementation and in the future) to customizing are not overwritten as a result of Support Packages, upgrades, or related maintenance activities. Additionally, SAP support typically requests that companies revert to the standard transaction types if they require remote access for troubleshooting customer messages. If the standard transaction types are not preserved, you may find yourself in a difficult position for SAP support. Similarly, it is helpful to keep the standard transaction types as a reference for your own benefit. In case of errors in the customer transaction types, you can check if the error occurs in the SAP transaction type. If it doesn’t, you have a better idea about how to troubleshoot or analyze the root cause of the problem.

Keeping your processes standard is also a recommendation. However, there are circumstances in which certain business, audit, or security requirements initiate a change to the standard SAP configuration. Even if your organization is disciplined enough to adhere to the SAP standards, you may encounter a requirement down the road that changes configuration. To build a foundation for scalability and flexibility, I recommend that you still copy the transaction types regardless of how you start off.

Solution Manager 7.1 provides an automatic transaction type copy tool to rapidly achieve copies of standard transaction types. Prior to the release of 7.1, Solution Manager administrators had to manually copy transaction types within the IMG activity Define Transaction Types. Additionally, components of the transaction types such as status profiles, partner determination procedures, and action profiles had to be manually copied and assigned to the customer transaction type. These activities are now fully automated and available in the IT Service Management area of transaction SOLMAN_SETUP. Figure 1 shows the Copy Transaction Type section.

Figure 1

Copy transaction types in transaction SOLMAN_SETUP

Figure 2 shows the tool once prompted from transaction SOLMAN_SETUP. In this screen you have three functions available:

1. Copy Transaction Type: A second screen allows you to copy the dependent entries (e.g., action profile or status profile)
2. Update Transaction Type: This applies to a transaction type that has been previously copied. It is important to note that only transaction types that are created with the transaction type copy tool can be updated.
3. Display Transaction Type: This allows you to display the technical details of a transaction type

Figure 2

Transaction type copy tool

3. Request for Change Validation

It is a safe assumption that most practitioners familiar with ChaRM have an understanding of the significant enhancements and changes that Solution Manager 7.1 offers. Many may still be in the process of ramping up on their knowledge to specific details, but the market has been made aware that Solution Manager 7.1 has been changed drastically when compared to its predecessor.

ChaRM has been significantly overhauled to improve the control of changes in your IT landscape as well as enhance the end-user experience. Although there are a vast number of alterations regarding functionality and the user interface, the core processes (formerly termed normal and urgent corrections) remain the same. With the exception of a couple of changes to terminology (e.g., now these transaction types are termed changes and not corrections), no major changes to processing these changes are introduced with 7.1.

A slight exception is the request for change transaction type, formerly known as a change request in Solution Manager 7.0. In addition to the scope extension feature, described in the next section, a request for change validation has been included in the standard workflow.

SAP recommends that your Solution Manager security roles be set up so that the change manager is the user who can authorize this validation. Figure 3 represents the standard request for change process from SAP.

Figure 3

Request for change process

Validating a change can be considered the first layer of approvals before the request for change is actually approved by the change advisory board (CAB) to begin development. Your organization’s CAB must be established as a business partner in the Solution Manager system for this to occur. The following list provides a few examples of items that the change manager might review during validation:

• Appropriate values have been maintained (e.g., impact, urgency, priority, category, and business partners)
• The request is actually a change and not a problem, incident, or training issue
• Clarity and completeness of short and long descriptions have been maintained
• All required documentation has either been described or uploaded as an attachment

After the validation period is complete, the change manager releases the request for change for approval. The document enters the status of To Be Approved and the workflow continues until the follow-on document (e.g., urgent or normal change) is created by the system.

4. Scope Extension

A scenario that is very common, and often unavoidable, is that a change request requires additional functionality once it has reached testing. The developer may determine that what was originally requested in the scope of the change is not sufficient to fully execute the implementation. There are many factors that could prompt the need for an extension to the original scope. The change may have integration effects that require additional configuration to accommodate, reports may need to be changed, or a break may have occurred as a result of the change request.

In Solution Manager 7.0, the only option was to fully confirm the original change request or reject it and open a new request. Manual effort was required to copy and paste the text of the change, re-attach documentation, and advance the workflow. Additionally, reporting and metrics were compromised because the original change request wasn’t really rejected and it wasn’t actually fully implemented.

Solution Manager 7.1 provides functionality to extend the scope of a request for change to accommodate those situations in which additional work is needed to complete a change at any point in the process. As shown in Figure 4, you can extend the scope of a change by selecting Extending Scope from the Actions button. Subsequently, you can select the scope of the change (e.g., Normal or Urgent) from the Change Request Scope assignment block as shown in Figure 5. The workflow is then enabled to loop back through your approval procedures and create the follow-on document type.

Figure 4

Extend the scope of a change

Figure 5

Select scope in the Change Request Scope assignment block

Figure 6 provides the process flow for extending the scope of a change. These process steps are an extension of the standard request for change process.

Figure 6

Request for change process with scope extension

5. Multiple Approval Procedures

When adopting a tool to manage changes to your IT landscape, it is important to have control but also a degree of flexibility. A single approval procedure, as you are familiar with in 7.0, was often too strict and limited organizations requiring a tool to support multiple approval procedures. Solution Manager 7.1 offers more flexibility in that multiple approvals are supported when processing a request for change.

The approval procedure can involve one or multiple steps. Each of these steps is assigned to a specific business partner function as well as to a specific business partner. When configuring the approval procedure you can define which steps can be executed at the same time. Alternatively, you can also define which steps must depend on another step. In addition to the customization of the approval procedure itself, you can also define rules to determine the approval procedure or the approver. These determination points are executed automatically based on the transaction type data.

There are two types of rules when defining approval procedures:

1. Approval procedure determination: Determines which approval procedure is called
2. Approval step determination: Determines which business partner is populated as the approver of a specific step

Figure 7 is an image of the details assignment block highlighting the option to select one of many approval procedures when planning for the change. Depending on the scope of the change, priority, or business area affected, the change can follow the appropriate path to approval. Rather than approving a change as a result of an action or status update, as in Solution Manager 7.0, Solution Manager 7.1 uses a more advanced, intuitive way of defining the appropriate approval procedure.

Figure 7

Select the Approval Procedure

6. Test Workbench Integration

The test workbench is now fully integrated into Solution Manager 7.1 change transaction types. This new feature allows defect corrections (for example) to link to the associated test plans and test packages directly within the defect correction in ChaRM.

This integration, accessible via the Test Management assignment block, provides direct access to import test information and documentation. You can launch the test package, access the test plan, view the status of the test package, and view the status of each test case within a test package.

The new features associated with aligning test management and ChaRM enhance visibility and transparency as well as support the overall integration between ALM and ITSM.

7. General Changes

In the beginning of this article I mentioned that one of the previous challenges of ChaRM in Solution Manager 7.0 was that it often lacked specific capabilities to manage customer solutions beyond SAP. Although the functionality of ChaRM in 7.0 worked as designed, there was often a limit to the scope of changes it could manage. The administration change in 7.0 (now termed administrative change) offered a way to manage changes that did not require a transport request. However, the administration change was still linked to a maintenance cycle and the intention that it was used for non-Transport Management System (TMS) changes (e.g., master data and other non-transportable changes).

With Solution Manager 7.1, a general change transaction type (SMCG) is available to manage changes that occur outside your SAP landscape altogether — for example, if a printer needs to be changed at your workstation or other IT assets need maintenance. General changes within Solution Manager 7.1 support the vision of supplying a single platform for managing customer solutions even beyond SAP.

General changes, like every transaction type, are delivered with their own workflow and status profiles. Table 2 provides the status values available for general changes.

Table 2

General change status values

8. Central Access to TMS and Landscape Data

The Transport Management assignment block and Landscape assignment block, as shown in Figure 8, provides central access to transport details as well as access to the managed systems. Rather than supplying the details of the transports and tasks in an overview text log, those details are provided in an organized manner in their own section of the change document. The example in Figure 8 is taken from an urgent change.

Figure 8

Transport Management and Landscape assignment blocks

Transport requests are no longer created from an actions button. All the functionality required to create a transport request, release a transport request, create a new task, refresh the details of the data, and process critical objects are all centrally performed in one dedicated area.

In the Actions column under Transport Management in the screen in Figure 8 you can see two icons. The icon that looks like a paper scroll (show log icon) directs you to the overview for all the transport logs associated with the urgent change’s transport. The magnifying glass (show details icon) provides you with an overview of the request. Each of these options directs you to these details within the development system.

Additionally, the landscape is now accessed within the Landscape assignment block. Rather than logging on to the managed landscape via the actions button, as previously achieved in Solution Manager 7.0, you can now log directly into the managed systems with one click.

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.