If you have made a business case for implementing Change Request Management (ChaRM), chances are that you are eager to get started. To build ChaRM into a success story for your organization, and to be a living example of just how effective the tool is, there are specific tips that are important to learn before starting off.

Setting up a stable ChaRM solution to drive your change and release management processes is not achieved without pitfalls along the way. Mistakes, whether they are minor or significant, can be detrimental at any point.

I’ll provide 10 must-have tips, collected from approximately 20 full-scale ChaRM implementations, to help avoid detrimental mistakes and support a smooth ChaRM implementation.

ChaRM is an implementation project in and of itself. To successfully go live with ChaRM, you must follow an implementation methodology. This means you go through each project phase the same way you would approach any software life cycle development: prepare, design, configure, test, and go live. A common misconception is that a technical team member can execute the configuration activities and ChaRM can be up and running for a support organization. Due to ChaRM’s requirements for resources — budget, schedule, and people — along with its impact on current support procedures and cross-team activity, it is important that a plan be developed. Table 1 identifies the typical project phases in a ChaRM implementation and what can be expected to occur during each of these phases.

Table 1

Project phases with activities

2. Design Your SAP Solution Manager Landscape to Be Scalable, Flexible, and Integrated into Your SAP Systems

Establishing a landscape that provides a prototype environment for proof of concept (PoC) and testing activities is critical when designing a ChaRM landscape. Ideally, you should establish a two-tier (at minimum) landscape to support ChaRM activities. This translates into having one system for development activities such as:

• Applying maintenance packages and notes
• Performing configuration, development (if needed), and testing activities
• Delivering demos and training

The second system would be your production SAP Solution Manager system, which would be connected to the production SAP ERP landscape and manage change control in the production environments.

Within the development system, you should establish the ChaRM test bed, which simulates a production environment. Four clients are set up to represent the SAP Solution Manager system, the managed development system, the managed quality assurance (QA) system, and the managed production system. The Transport Management System (TMS) is configured within SAP Solution Manager so that configuration and development changes can migrate through the mock SAP ERP landscape and be controlled by the SAP Solution Manager client.

The development system and production system should be linked by a transport path so that the production and development systems are kept in synch at all times. No changes should be configured directly in the production system. They should be configured and tested in development and then promoted to the production system based on your organization’s change management procedure.  

Figure 1 provides an example of an SAP Solution Manager landscape and how it is integrated with your organization’s overall SAP ecosystem. This approach assumes a two-tier SAP Solution Manager landscape and a three-tier SAP ERP landscape.

Figure 1

Landscape strategy

3. Assemble a Core Implementation Team in the Beginning and Effectively Communicate Expectations

Although Basis and technical resources are essential to a ChaRM implementation, ChaRM requires input and contribution across the support organization throughout the life cycle of a project. Since ChaRM affects the way that Basis manages TMS, the way change managers process change requests, and the way teams configure, develop, and test changes, it is important to have cross-team integration.

Identifying a core ChaRM implementation team with cross-team representation in the beginning will support success throughout the project and into go-live. Core team members are vital during the design, play-back, and final sign-off of the ChaRM solution. These roles that are active during the project eventually evolve into support roles once ChaRM becomes live. Assembling a core team up front increases buy-in and support from the support organization.

Table 2 provides examples of roles throughout a ChaRM engagement, estimated effort, and their responsibilities.

Table 2

Roles and responsibilities matrix

4. Design Your Project Budget to Allow for a PoC and Continuous Improvement of Design

A helpful way to capture requirements for a change control solution is to build a ChaRM PoC and present demos on the functionality. During the Blueprint phase, you should divide ChaRM PoCs in two parts: build and refine.

During the build, the SAP Solution Manager specialist demonstrates the standard SAP functionality for processing each correction type (e.g., normal and urgent) in ChaRM. This provides the core implementation team with the appropriate knowledge to understand the capabilities and, in some cases, potentially viewed limitations (e.g., the inability to approve a change request from an email notification or an existing report that is used in the organization but not available in ChaRM). Updates to the standard processes and addressing limitations (sometimes deemed gaps) are both outputs of the blueprint workshops and incorporated during the build phase.

The second phase, refine, occurs after the core implementation team is able to see the to-be solution. The solution is adjusted per any final updates that are based on the team’s feedback. Another demo is delivered to confirm expectations, followed by a final review and sign-off of the new change management process.

Figure 2 depicts these two phases of the blueprint, the high-level tasks within these phases, and how ongoing design spans them.

Figure 2

Blueprint phase activities

5. Keep It Standard SAP and Don’t Overcomplicate the Workflow

SAP Solution Manager provides standard processes out of the box for change management scenarios. Two examples are:

• A process to manage normal changes that are bundled together and moved throughout the landscape based on a defined maintenance cycle
• A process to manage urgent changes that are independent of maintenance cycles and can be fast-tracked to the production system for critical system changes

The standards delivered with SAP Solution Manager are considered SAP best practice and comply with ITIL v3 processes for change management. Organizations should strive to execute against these processes, even if it means adapting current change management procedures.

In certain cases (e.g., an opportunity to decommission a home-grown tool), enhancing the workflow makes sense. In most instances, you can enhance the workflow with customizing. In these cases, ensure that Z transaction types are used. (I’ll discuss this more in tip 7.)

6. Ensure RFC Connections and Security Authorizations Are Properly Maintained

Most often, errors discovered during testing are a result of Remote Function Call (RFC) connections or incorrectly maintained security authorizations. Incorrect, or missing, configuration from either of these two areas may result in:

• Transports not released from development or imported into QA
• Login screens appearing where seamless transition should normally occur
• Erroneous errors
• ABAP short dumps

It is important to note that even SAP_ALL and SAP_NEW profiles do not contain specific trusted authorization objects required for testing and using ChaRM. Reference the SAP Solution Manager security guide in the SAP Service Marketplace for specific details on required ChaRM authorization objects by following menu path SAP Support Portal > Release & Upgrade Info > Installation & Upgrade Guides > SAP Solution Manager > <Latest Release> > Operations.

7. Copy Standard SAP Transaction Types into Your Own Z Customer Namespace

ChaRM is driven by SAP Customer Relationship Management (SAP CRM)-based documents. Rather than modifying the standard document types, you should make a copy into your own customer namespace (i.e., create a Z or Y transaction). Establishing Z transaction types allows you to scale efficiently should new requirements come into scope.

In addition, if a potential bug is discovered in your SAP Solution Manager system and must be escalated to SAP Support, it is easier to reach resolution if the standard SAP transaction types are preserved. SAP Support often requests that you temporarily revert back to the standard SAP transaction type to repeat the error. If the standard transaction type is modified, then support becomes an issue.

Finally, significant modification of standard SAP transaction types may mean an upgrade nightmare down the line. If you’ve customized the standard transaction types and then later apply a Support Package, your customization is overwritten. Creating Z transaction types ensures that your customization is preserved during the upgrade.

Table 3 provides examples of standard transaction types and their descriptions, along with how they can be copied to a customer namespace.

Table 3

Customer transaction types

8. Define a Cutover Plan That Facilitates a Smooth ChaRM Go-Live Without Disrupting Current Development Activities

A carefully planned and executed cutover may be considered the most important activity in a ChaRM implementation. Everything that has been designed, configured, and tested in a development environment will soon control changes to your production landscape. Additionally, ongoing development must be considered during the cutover. Depending on the volume of transports created, a strategy (e.g., reducing the number of transports or halting development altogether) should be in place to address ChaRM cutover activities.

Your cutover plan should address how to handle open transports prior to ChaRM activation. It is important to note that you must merge any transport that is open (i.e., not released) into a ChaRM transport request after ChaRM goes live. If transports are released before go-live, they are able to follow the normal (i.e., legacy) path to production.

A project check analysis (IMG activity Execute Check Report) must return positive results with all green lights prior to turning ChaRM over to the support organization. Figure 3 provides an example of what your results should look like after running the check.

Figure 3

Check report results

In addition, create a mock ChaRM request in the production environment and pass it to QA before ChaRM goes live. This mock ChaRM request should be a collaborative effort among the roles in the ChaRM process. It tests security, customizing, and transport management to ensure a change can be transported through to QA at the minimum. The mock ChaRM request should consist of a customizing (e.g., creating a Z security role) and workbench (e.g., updating a Z table or program) transport request.

9. Develop a Training Strategy That Successfully Enables Your Support Organization to Run ChaRM Efficiently

As previously mentioned, Basis team members play a vital role in a ChaRM implementation. However, ChaRM spans across multiple roles in a support environment. A training strategy must be developed and executed against prior to ChaRM going live — but not too early on in the implementation. A just-in-time approach to hands-on training ensures that the ChaRM users have the knowledge they’ll require fresh in their minds when ChaRM goes live.

Training should start with a go-live kick-off meeting. This is not to be confused with the project kick-off meeting that is held in the project preparation phase of the implementation. This go-live kick-off meeting should be led by the project sponsor (typically a leadership employee within the support organization). This meeting provides a very high-level overview of ChaRM, the vision of how support processes are being streamlined, and expectations for the users.

Following the go-live kick-off meeting, you should conduct classroom-led training for those team members who will be logging into SAP Solution Manager on a day-to-day basis to perform ChaRM functions. Table 4 identifies those roles and examples of various training aspects that you should incorporate into the training material.

Table 4

Training considerations

10. Become Familiar with Standard Reporting Capabilities to Support and Optimize Your ChaRM Scenario after Go-Live

It is not common for the topic of reporting to come up during the design and build of a ChaRM solution. You should table these requirements rather than develop specifications before ChaRM goes live. Reporting requirements that are discussed prior to go-live are often different than the reporting requirements that arise after ChaRM is productive. Support team members become more familiar with the functionality after it goes live, and may notice reporting features that would be useful that they weren’t using. Do not lose sight of the reporting discussions that come up during the implementation, but recognize that your actual requirements are only realized once ChaRM is supporting a live production landscape.

SAP Solution Manager offers out-of-the box reporting capabilities to track the status of change requests and corrections from approval to go-live. Additionally, there are standard reports that identify deltas between development, QA, and production regarding transport requests. Finally, troubleshooting tools are available to help identify and pinpoint technical errors that may occur across the ChaRM solution. Table 5 identifies several out-of-the box capabilities that help troubleshoot errors both during the configuration and operations.

Table 5

Standard reports

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.