Expand +



ChaRM Changes in Solution Manager 7.2: How to Transition Your Existing ChaRM Configuration Risk Free

by Vessy Panayotova, Senior SAP Solution Manager Analyst, Employment and Social Development Department, Government of Canada

June 1, 2018

Learn how the new Solution Documentation in SAP Solution Manager 7.2 affects the configuration and administration of Change Request Management (ChaRM) and what to address when upgrading existing ChaRM functionality.

The new version 7.2 of Solution Manager introduces completely redesigned Solution Documentation; for that reason, it is seen as the biggest and most talked about topic for this upgrade. I review how the redesign of the documentation and the introduction of documentation branches affects organizations that have already implemented Release and Change Request Management (ChaRM). I show how these processes are affected and what needs to be done as part of the upgrade from 7.1 to 7.2 to achieve a smooth transition and, at the same time, to profit from the new features introduced with the redesign of Solution Documentation. 

The audience for this article are primarily the experts responsible for configuring and maintaining the ChaRM tool in Solution Manager. The compares are always between version 7.1 to 7.2. The assumption is that by now no one is using 7.0 and the terminology from 7.1 is quite familiar and clear.  

Solution Branches

In the completely redesigned Solution Documentation with SAP Solution Manager 7.2, branches replace projects. A branch represents a version of the Solution Documentation part of a solution. Each solution has one production branch, which is not modifiable. Branches refer to Solution Documentation, not to the landscape. The logical component groups are assigned to a branch. For example, the production logical component group is assigned to the production branch and represents all production systems (including ERP, Portal, BI, and Solution Manager). Figure 1 shows the relationships between the branches. 

Figure 1
Relationships between the branches

The End of SOLAR_PROJECT_ADMIN and SOLAR01/02 Transaction Codes

With the new design of the Solution Documentation and the use of more advanced project management processes with SAP Portfolio and Project Management (PPM), transaction codes SOLAR_PROJECT_ADMIN and SOLAR01/02 are now obsolete. 

SAP Solution Manager offers excellent integration between Solution Documentation, ChaRM, and PPM, which, with version 7.2, is moving to the next level. It is up to every organization, however, to decide what to use and integrate. The use of these tools can be done in various combinations, which creates different flavors—for example, Solution Documentation and ChaRM, without PPM. It was similar with versions 7.0 and 7.1, in which not all options in SOLAR_PROJECT_ADMIN were used, if, for example, the organization was not using Solution Manager for project management.

The new version also introduces the SAP Fiori Launchpad, accessible via transaction code SOLMAN_WORKCENTER or SM_WORKCENTER. From there you can access  many of the Solution Manager tools via user-friendly tiles. The advantage of SAP Fiori is that each user gets only role-based tiles and does not need to remember or save transaction codes.

Table 1 lists where some project-related controls moved in SAP Solution Manager 7.2.


SAP Solution Manager 7.1 transaction code

SAP Solution Manager 7.2

Transaction code

SAP Fiori tile

Creating a project

Project milestones

Project team

Status values

General data



Project Management






Project Management

System landscape

Change management



Solution Administration



Documentation types



Solution Documentation

Business blueprint

Business process Repository

Technical Bill of Materials (TBOM)

Training materials

Test cases












Solution Documentation

Project reporting



Solution Documentation

Table 1
Project administration mapping from version 7.1 to version 7.2

What Happens with Existing Projects After Content Activation

Content preparation and content activation are two major complex activities designed by SAP to be used during the upgrade from 7.1 to 7.2. The preparation can be executed many times; however, the activation in a system upgraded to 7.2 can be executed only once.

All details regarding these multi-step activities are described in official  SAP documentation and are regularly updated. Always look for the latest versions published by SAP. Here is a very brief description of these key and complex activities that are specific for this upgrade (from version 7.1 to version 7.2): 

  • Content preparation is executed before the upgrade
  • During the upgrade, the prepared content is kept in a temporary location
  • Content activation is executed after the upgrade 

The content-preparation activity defines the scope of the content activation. Here is the place to do lots of clean-up and evaluation. You define for activation only those solutions and projects with current, up-to-date documentation and projects with active, not finished, ChaRM documents (for example, a future major release with already-approved and in-progress change documents, which were started in version 7.1, but will be implemented in version 7.2, after the Solution Manager upgrade).

It is important for these projects to be kept with the active cycle, not completed. Otherwise they will be ignored by the content preparation activity. A good practice is to complete all short-term projects, as weekly or biweekly maintenance types of releases, to simplify and shorten the content-preparation and content-activation activities.

The content-preparation activity also includes the following important steps:

  • Group the existing logical components in logical component groups
  • Maintain the logical component groups
  • Assign the logical component groups to target branches 

During content activation, the prepared content is created and activated. It is moved into the new Solution Documentation environment with applicable application content (for example, transactional data for ChaRM and PPM).

The ChaRM-relevant content is activated by the Activate ChaRM Content activity, during which a new cycle is created for each ChaRM project selected as in scope during content preparation. 

Changes That Affect ChaRM

With version 7.1, the cycles and tasks used in ChaRM were created from a project in SOLAR_PROJECTS_ADMIN. A project had to be created first and activated for ChaRM. Then the cycle/task was created. Now cycles are created directly in the CRM Web user interface (CRM Web UI) for a specific branch that has a development system, and the maintenance is much simplified.

The whole concept of project administration is redesigned and the use of projects (SOLAR_PROJECTS_ADMIN) is discontinued. Project-management activities related to schedules, time, and resources planning are now handled in the PPM tool and ChaRM administration is handled in Solution Administration (transaction code SOLADM) and in ChaRM (CRM Web UI).

Version 7.2 introduces new transaction types for cycles; the old ones are becoming obsolete. 

ChaRM content, including cycles of the old type and the linked change documents,  are not lost after the activation but remain as read only, if that content was not scoped for activation. All scoped content is converted under the new cycle types, keeping the same change documents. This is illustrated in Figure 2.

Figure 2
Transition of ChaRM content from version 7.1 to 7.2

The Change Cycle Transaction Types

The cycle types in SAP Solution Manager 7.1 can still be found in version 7.2, but they are read only. They are SMMN, SMDV, and SMMM. As illustrated in Table 2, the new cycles are SMIM, SMAI, and SMRE. The table also illustrates how the old cycle types are replaced by the new types. 

Project type in Solution Manager 7.1

Cycle type in Solution Manager 7.2

SMMN – Maintenance project SAP0 variant with M (maintenance) task list

SMIM phase cycle


SMDV – Implementation project with I task list

SMAI continual cycle


SMMM – Maintenance project using variant SAP1 with an M task list

SMRE release cycle

Table 2
Project types from version 7.1 to cycle types in version 7.2

Phase cycle is the most common type. This cycle accepts all change document types. It is created in the CRM Web UI directly, not in SAP GUI anymore. The task list is now created directly from the cycle document, also in the CRM Web UI, via a small guided procedure. 

A continuous cycle type can handle only urgent changes and most likely will have limited use, except in organizations that use only urgent changes. It is available for more flexibility. A continuous cycle is also created in the CRM Web UI directly. 

Figure 3 demonstrates where to find the Create button for the phase and continuous cycle types—directly in CRM Web UI > Change Request Management. 

Figure 3
Create a phase cycle or continual cycle from ChaRM

Figure 4 illustrates the screen for creating a new phase cycle. Note that the selections of Landscape and Branch are mandatory. 

Figure 4
Create a new phase cycle

Release cycle is a new concept introduced by a new tool in ChaRM—the release planning tool. This type does not have an equivalent in the old cycles. A release cycle is a type of change cycle that is used within release management for phase-driven changes that depend on the release plan. A release cycle is created from the release planning tool for each release in the CRM Web UI.  Table 3 provides a summary for the three new cycle types, including what kind of change documents can be used with each type. 

Cycle type

Change documents accepted by cycle

Release planning tool integration

Phase cycle

Urgent Change

Normal Change

Administrative Change

General Change

Defect Correction


Continuous cycle

Urgent Change


Release cycle

Urgent Change

Normal Change

Administrative Change

General Change

Defect Correction


Table 3
The new cycles’ relationships to the change documents in ChaRM

Release Management

Release management is used to plan, manage, and coordinate release activities.

The new release planning tool can help to organize releases by creating up-front major and minor release IDs, with planned go-live dates and dependencies, and to assign the release planning data to change control landscapes and branches. Minor releases are successors from an major release. You can define the number of minor successors in advance (by periodic selection, such as every two months) or successors can be created individually when necessary.  It also comes with a Gantt chart and release planning table. Figure 5 shows the Release Planning screen with several major and minor releases with different statuses.

Figure 5
Release Planning interface

Release numbering is automated. It uses the format X.X, in which 1.0 is a major release. Any of the type 1.1 or 1.2 are minor releases after 1.0, and before 2.0 (the next major release). The release go-live date can be adjusted and is visible on the Requests for Change (RfC) and change documents created for release cycles. 

To create a release cycle, the release should already be created for a specific branch with the source type system. As a last step, the release cycle is created from the release tool for each release. 

Figure 6 shows how to find the release planning tool under ChaRM. Click the Change Request Mgmt button and then the Release Planning button. That takes  you to Figure 7.

Figure 6
Access release planning from ChaRM

Figure 7
Creating a release cycle for a release from the Release Planning tool

Creating a release cycle for a selected planned release is shown in Figures 7 and 8. Click the Release Cycles button in Figure 7. Once the release cycle is generated, the release status changes from Planned to Build. A change document can be generated for this cycle and release. You then receive a success message (Figure 8).

Figure 8
Message for successful release cycle creation

Administration Cockpit

SAP Solution Manager 7.2 introduces the Administration Cockpit, which provides a central entry point to all administrative activities for Change Control Management.

The Administration Cockpit is launched from the SAP Fiori Launchpad (transaction code SM_WORKCENTER).  The Administration Cockpit tile is under the Change Management area in SAP Fiori (Figure 9).

Figure 9
The Administration Cockpit tile in SAP Fiori

Under menu path Tasks List > Phase Cycles, you can find the M* and I* (implementation) task lists from migrated SMMN and SMDV projects by content activation, as shown in Figure 10

Figure 10
The Administration Cockpit interface for phase cycles

The Administration Cockpit provides access to create new cycles and other Change Control Management administrative tools such as landscape overview, transport analysis, and others. 

The Need to Redo All Z Transactions and the Reason

The main transaction types in ChaRM remain the same in version 7.2. These are SMCR (Request for Change), SMMJ  (Normal Change), SMHF (Urgent Change), SMAD (Admin Change), SMCG (General Change), and SMTM (Defect Correction). Usually when an organization is using ChaRM, the change transactions are already created in the customer namespace version (usually Z or Y, created for version 7.1 when these transactions were introduced).  

The introduction of new cycles and the redesign of a number of configuration tables, checks, and conditions now make all ZMxx transactions unusable right after the upgrade, regardless if the content activation converted the active data under the new cycle types.

In Solution Manager, the link to a ChaRM-activated project is replaced by a link to the documentation branch and one of the new types of cycles. This major change defines the need to recreate the Z transaction codes again as a copy of SMxx types. It is becoming a mandatory part of an upgrade for implementations already using ChaRM. This means reconfiguring some or all of the previous customizations on the Z transaction codes to keep the business process the same or almost the same as on 7.1. This eventually will require you to review and repair the affected business processes to reflect the new reality.

The deletion and recreation of all existing Z transaction codes is not the subject of this article, but it needs to be mentioned, as it requires a significant level of effort and needs to be taken into account when upgrading an existing solution with activated ChaRM.

You can try to redo ZMxx transaction codes by using the option Overwrite existing data with the standard settings of report AI_CRM_CPY_PROCTYPE. As the report has some limitations, this option may not always work. If it is not working, then you need to use the long path to redo your ZMxx transaction codes:

  1. Use report AI_CRM_CPY_PROCTYPE to make a copy of all existing ZMxx versions to YMxx. This is only for archiving reasons, to have a reference to the past versions (optional).
  2. Manually delete all configurations related to ZMxx transaction codes.
  3. Use report AI_CRM_CPY_PROCTYPE to create a new version of all ZMxx transaction codes. Select the option to copy SMxx to ZMxx. The report may find still undeleted ZMxx entries showing red statuses. In this case, repeat step 2 (delete all table entries that generate a red status) and try step 3 again until you have successfully created the new ZMxx transaction codes. They will now look exactly like the SMxx versions and will be missing all previous adjustments and custom changes introduced during the use of version 7.1.
  4. Now you need to repeat all customizations to the ZMxx transaction codes in transaction code SPRO (configuration tables for action, conditions, status profiles, and so on) and in the CRM Web UI (hiding fields, new custom fields, assignment blocks order, and so on). To do this most time-consuming step, use the temporary copy created in step 1 as a point of reference or just refer to your non-upgraded production system running SAP Solution Manager 7.1. All your existing documentation from the past related to your custom changes can be of additional help. 
Better Change Control Management and Solution Documentation Integration

Solution Documentation with older versions of SAP Solution Manager used the Compare and Adjust activity to maintain the documentation and keep it up-to-date after enhancements went to production on go-live day, regardless if it was with or without ChaRM. This activity, if used, could take days or weeks before completion, as when to do it was up to the responsible people. The documentation would easily not represent the current solution 100 percent for at least some period until it was adjusted.

ChaRM in version 7.2 is much better linked to the documentation through the concepts of branches. As a branch represents a version of the Solution Documentation and the ChaRM cycles are created against a branch, this allows almost a real-time update of the Solution Documentation, once a change is promoted to the production system. This works when ChaRM documents (RfC and linked change documents) are associated (linked) with an element of the Solution Documentation. This link can be created from both directions—either from Solution Documentation or from a ChaRM transaction. Then the link is easily visible from both sides. The links are also active, meaning a click launches the other side and takes the user directly to the exact document.

The next few figures illustrate this integration. This example is made with the assumption that both Solution Documentation and ChaRM processes are implemented and used together.

Go to the Solution Documentation assignment block on a change document (for example, the administrative change shown in Figure 11), where the documentation is already linked, and click the selected link, in this case Create PO. The creation of a purchase order is used here as an example but it could be any functional step.

Figure 11
Link to Solution Documentation from the change document or RfC Solution Documentation assignment block (the same for all types of ChaRM documents)

That launches the Solution Documentation view as shown in Figure 12.

Figure 12
The Solution Documentation view accessed from the ChaRM link

Click the change document link in Figure 12 to go to the view in Figure 13, where the user has access to various filters. In my example, the change document link is Demo Dev Day 3, but it can be called anything else. 

Figure 13
View of all scoped/changed elements of Solution Documentation within the same ChaRM document

As mentioned above, there are two ways to link ChaRM documents to Solution Documentation elements:

1. From the ChaRM Solution Documentation block, by using the Single Element or Multiple Elements buttons shown in Figure 14.

Figure 14
Solution Documentation assignment block in all ChaRM documents

2. From Solution Documentation. Select and use the ChaRM link to assign an existing ChaRM document or to create new one as shown in Figure 15.

Figure 15
The Related Documents assignment block for a selected Solution Documentation element provides integration to ChaRM (RfC) and IT Service Management (ITSM) incidents

To create the ChaRM link from Solution Documentation, click the link 0 assigned in Figure 15 to get to the dialog in Figure 16.

Figure 16
Solution Documentation screen to create a new, delete, or assign an existing ChaRM or ITSM object

During the development (Build) phase of a project, the linked documentation is locked under the development or maintenance branch, where the documents are edited. Once the transports are promoted to the production environment and the change documents status is updated to Implemented, the locked documentation is automatically moved to the production branch, which now has the latest version. This almost-real-time documentation adjustment is one of the best new features with the redesigned Solution Documentation with SAP Solution Manager 7.2 as the documentation really displays the solution as is at any given moment.

Solution Documentation and the ChaRM processes can also be used separately, but the new version 7.2 is an excellent reason to start using the new and improved integration.

An email has been sent to:


Vessy Panayotova

Vessy Panayotova is an experienced certified SAP Solution Manager professional working for the government of Canada, focusing on ITSM, ChaRM, and Solman project administration. She has more than 15 years of SAP experience in configuring, testing, and support of various SAP modules, and has experience in ABAP, Basis, and Portals. For the last five years she has concentrated on SAP Solution Manager 7.0 and 7.1. Vessy holds an engineering degree in electronics from Technical University in Sofia, Bulgaria.


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!