A Look at ChaRM Roles for SAP Solution Manager

SAP provides a standard workflow for processing requests for change and the fol­low-on change documents that ultimately deploy the change depending on the scope (i.e., normal, urgent, administrative, etc.).

Each step within these processes is aligned to an end-user role, based on SAP best practices and ITIL methodology. Further, SAP Solution Manager provides standard authorization roles that map to each of these end-user roles.

These roles serve as templates and guidelines for your organization when imple­menting change request management (ChaRM) to manage changes related to implementation or maintenance projects. Ultimately, the objective and recommendation is for your organization to align your processes and end-user functions to the templates, workflows, and processes provided standard with SAP Solution Manager.

However, due to dynamic differences and various requirements across organiza­tions, sometimes it isn’t possible to align strictly to the out-of-the box scenarios provided by SAP Solution Manager. In these cases, your organization will need to map current roles and functions with those in ChaRM and determine how the dif­ferences will be bridged.

The end-user roles identified in the table below are the standard roles that execute the steps necessary for ChaRM processes.

Let’s look at these in more detail.

Requester

The requester kicks off the entire ChaRM process by creating a request for change. The requester can either create the request for change from scratch, or it can be requested via alternative inbound channels.

Requesters can either be power users of the SAP system, end users (business ana­lysts), or members of the support team (first or second level) who require the authorization to create requests for change based on their job duties. More often than not, requesters will also be developers, testers, and IT operators. On the other hand, some organizations may have only business users as the requesters. It varies across organizations and depends on size, complexity, and organizational structure.

The responsibility of the requester is to provide enough detail about the request for the change approver to thoroughly validate it and position it for approval by the Change Advisory Board (CAB). The requester should fill out, at a minimum, a short description, descrip­tion of the change, reason for the change, and priority. Depending on the organi­zation and how requesters are trained on ChaRM, they also may provide basic categorization (entering categories, project, risk value, etc.).

Service Employee

Should a service transaction associated with Application Incident Management (AIM) warrant a request for change, it’s the responsibility of the service employee (e.g., message processor) assigned to the transaction to create the request for change.

A service transaction can include an incident, problem, or service request. The service employee is a message processor who either serves as Level 1 or Level 2 support for working the service transaction. If the problem, incident, or service requests requires a change to the IT landscape, a request for change document can be created as a follow-up by the service employee.

Change Approver

The change approver is a manager or above level within the IT organization who is responsible for coordinating, managing, and monitoring transport processes. This includes the request for change process, change process, and release manage­ment.

In the request for change process, change approvers validate the request for change. They are the first ones to handle the request after it has been created by the requester. Their job is to ensure that it’s documented with the required infor­mation, follows standard guidelines for Change Management, and contains the required project and scope data so the CAB can evaluate it for approval.

In the change process (i.e., normal or urgent), the change approver role also involves the approval or release of a change to the production system. They facil­itate phases within the ChaRM maintenance cycle as well as set the approvals themselves. These actions allow the change approvers to be fully informed and aware of what changes are occurring, or on deck, to the production environment.

Change Advisory Board (CAB)

The CAB in ChaRM approves or rejects requests for change. The CAB representa­tives should be an equal mix between the business and IT teams so that the deci­sion on what is implemented and promoted to production is unbiased and is made to best serve the holistic organization. Typical CAB members can include, but aren’t limited to, the following:

• Consultants
• Customers
• Suppliers
• IT staff
• Change manager

In ChaRM, the only time the CAB enters the system is during this approval/rejec­tion phase. However, they are the governing body that makes the decisions regarding what should be implemented and when the changes should be released to the production systems. The CAB makes these recommendations based on many factors.

Because the CAB is made up of a various mix of representatives across the IT organization, they are able to provide educated and knowledgeable insight on what is approved. They are aware of existing services, costs associated with changes, resource availability/constraints, and other important factors.

Developer

The term developer in ChaRM refers to a user who implements changes in the development system. While a developer is often associated with an ABAP pro­grammer who implements workbench requests associated with development, in ChaRM, a developer is someone who is a functional configuration expert.

The role of a developer in a ChaRM maintenance project could be shared across consultants, power users, or Level 1 and Level 2 support members. Their responsibility is to implement changes that are approved as part of the request for change process.

Further, they provide test instructions to the tester as well as document the implementation of the change. They perform the unit tests associated with the change and hand the changes off to the tester when they are finished with their implementation.

Tester

A tester in ChaRM is an individual who follows the test instructions provided by the developer and tests the change in the test system. They are responsible for creating the test result, which documents the outcome of the test.

If the outcome of the test is successful, they confirm the successful test so it can be approved for production by the change approver. If the test fails, it’s the responsibility of the tester to return it back to the developer and update the documentation accordingly.

IT Operator

IT operator is synonymous with the role Basis team member. In ChaRM, the role of the Basis team is more hands off than traditional TMS procedures. A common misconception is that because ChaRM uses the existing TMS infrastructure, then it’s a Basis-intensive tool that requires a lot of hands on from the Basis team. In practice, it’s the exact opposite.

The workflow (actions and conditions) built into ChaRM’s change process trig­gers the creation and release of transport requests behind the scenes. Further, all imports into the test system are automated. If there are errors associated with the application or transports, they are displayed directly in the change document for the user. Direct access is provided to TMS to view and analyze errors that may occur.

The role of the IT operator is to schedule or trigger the import of normal and urgent changes into production. Per the standard end-to-end processes for change documents, the only time the IT operator logs into ChaRM is to perform this function.

This isn’t to minimize the importance that IT operators play in the end-to-end deployment of changes. It’s true that if everything is running 100% smoothly, the IT operator’s only ChaRM end-user function is to trigger imports into production. However, from a system maintenance perspective, the IT operator plays a major role in ensuring that the system is available and performing in a manner that sup­ports the business. IT operators take care of the software logistics and support the landscape if ChaRM is disrupted in any way.

Conclusion

There are seven roles used by ChaRM within SAP Solution Manager. This blog post laid out each and described when they would appear in the change lifecycle.

Editor’s note: This post has been adapted from a section of the book ITSM and ChaRM in SAP Solution Manager by Nathan Williams.