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. SAP Professional Journal already published an article on the topic (“Back to Basics: An Introduction to Some Key Changes in SAP Solution Manager”). With this article, 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 is primarily the experts responsible for configuring and maintaining the ChaRM tool in Solution Manager. The comparisons 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.

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 Solution Manager 7.2 SAP Fiori tile
Creating a project Project milestones Project team Status values General data	SOLAR_PROJECT_ADMIN	IT PPM	Project Management
Roadmaps	RMMAIN RMAUTH RMDEF	IT PPM	Project Management
System landscape Change management	SOLAR_PROJECT_ADMIN	SOLADM	Solution Administration
Attributes Keywords Documentation types	SOLAR_PROJECT_ADMIN	SOLDOC	Solution Documentation
Business blueprint Business process Repository Technical Bill of Materials (TBOM) Training materials Test cases Development Configuration	SOLAR01 SOLAR01 SOLAR02 SOLAR02 SOLAR02 SOLAR02 SOLAR02	SOLDOC	Solution Documentation
Project reporting	SOLAR_EVAL	SOLDOC	Solution Documentation

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

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.

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 continuous cycle
SMMM – Maintenance project using variant SAP1 with an M task list	SMRE release cycle

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 4 illustrates the screen for creating a new phase cycle. Note that the selections of Landscape and Branch are mandatory. 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 the cycle	Release planning tool integration
Phase cycle	Urgent Change Normal Change Administrative Change General Change Defect Correction	No
Continuous cycle	Urgent Change	No
Release cycle	Urgent Change Normal Change Administrative Change General Change Defect Correction	Yes

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. 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. 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).

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). 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. 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. That launches the Solution Documentation view as shown in Figure 12. 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. 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. 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. To create the ChaRM link from Solution Documentation, click the link 0 assigned in Figure 15 to get to the dialog in Figure 16. 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 it 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.