Expand +



Back to Basics: An Introduction to Some Key Changes in SAP Solution Manager 7.2

by D. Russell Sloan, Implementation and Governance Specialist — SAP Solution Manager, IBM Global Business Services

February 17, 2017

Learn how Solution Documentation has changed in SAP Solution Manager 7.2 to an enhanced single source of truth for all aspects of a delivered solution.

Solution Documentation in SAP Solution Manager 7.2 is a whole new experience if you’ve used Solution Documentation in version 7.1 or in prior versions. SAP has completely rewritten the way the business process hierarchy (BPH) is maintained and how documentation is assigned to it. I show how to use the new Solution Documentation in the hopes of getting your teams up to speed to take advantage of Solution Manager 7.2 more quickly.

(Note: If your project is currently using Solution Documentation in Solution Manager 7.1 or below, you must activate the documentation prior to upgrading to 7.2. Documentation activation is beyond the scope of this article.)

First, we must begin with some basic terminology. Many of the terms in Table 1 are not new, but their definition and functionality have changed.




The solution contains all the applications and processes supporting the enterprise. Since the solution is a complex container, a company typically needs only one. A solution forms an independent area with limited access to outside systems and functionality. Therefore, the solution must be able to represent all the technologies and processes in the enterprise solution, not just the SAP system components.

Solution Documentation

The collection of all technical and process-related objects required for the enterprise solution to be built, delivered, and operated


A version of the Solution Documentation. All solutions have a production branch that is not modifiable and represents what is currently in production. Additional branches can include a maintenance branch for production support and one or more development branches for projects. In Solution Manager 7.2, the branch replaces the project. It is more robust than a project as it can migrate all its contents (including documentation and process models) into production via the change control functionality.


Technical objects used to perform activities or tasks in the system. They include transactions, Fiori apps, and Web Dynpro. They are always accessible to users.


A collection of reusable objects. Each type of object is housed in a separate library.

Object types include:

  • Process steps
  • Interfaces
  • Executables
  • Development objects
  • Configuration (Business Configuration Sets [BC Sets] and IMG objects)


Structure nodes are elements. They can have objects associated with them (such as documents) that are grouped in object lists. These lists are also referred to as elements.


A collection of business processes executed in a logical sequence to perform a business function. The processes typically cross multiple departments within a company and have dependencies on each other (i.e., order creation comes before deliveries in an order-to-cash scenario).


A sequence of business functions arranged in a logical way to perform a business task. The functions can be manual, user driven via interaction with the system, or system driven (for example an interface). A process can require the use of multiple SAP application components.


A discrete business function. It is a subtask of a process and is performed in exactly one SAP application component.

Table 1
Key terms and definitions

The objects described by the terms in Table 1 are used together to perform Solution Documentation. The Solution Documentation concept is based on a hierarchical arrangement of the objects.

The hierarchical arrangement of objects is used to document the business process decomposition. Business process decomposition is a systematic way of illustrating how business functions come together to support higher-order business activities. For example, the order-to-cash scenario uses the processes of order management, delivery management, and billing. Each of the processes is supported by a series of process steps such as create order in the order management process.

The central component is the unified solution. The unified solution allows for grouping together all parts of the enterprise system landscape with business processes, applications, interfaces, technical objects, and documentation versions into a single management object.

How Branches Are Used for Version Management in Solution Manager 7.2

The solution used to be an independent object from projects in prior versions of Solution Manager. Now, the solution is integrated with projects through the concept of the branch. Branches (which have replaced projects) are versions of Solution Documentation tied to a solution. All solutions must have a production branch that houses the production version of all elements of the production environment. The production branch is not modifiable.

Figure 1 shows the relationship of three branches in a solution.

Figure 1
The relationship of branches

For more detail about the relationship among branches, cllick here.

The production branch is the Solution Documentation (including technical objects) for what has already gone live and is running in production. In prior versions of Solution Manager, you would have an implementation project. As part of a cutover, you would migrate the content (Solution Documentation) from the implementation project into the solution so that the solution was the sum of all that had been released into production. That same concept is now represented by a development branch for the work in progress for the next release. At cutover, the development branch is released into the production branch to update the production branch.

To perform maintenance on the productive solution, a maintenance branch is created on the solution. The maintenance branch is considered a child branch of the solution. As such, it has access to all the content in the production branch.

If a change needs to be made to a process for a break fix or minor enhancement, a copy of the production content is created in the maintenance branch where the change is being made. Only changed objects are copied into the maintenance branch, but all production objects are visible in the maintenance branch.

SAP system users can create one or more development branches that are similar to the maintenance branch. These too are children to the production branch, and they are siblings to the maintenance branch and to each other. These development branches are analogous to implementation projects in prior versions of Solution Manager.

Reusable Libraries

Solution Manager now stores objects in collections of unique object occurrences called libraries. These libraries are the building blocks used to develop an enterprise solution. Libraries are visible in all branches, but the object exists only once. The objects in these libraries are called elements.

There are five different types of libraries.

  1. Process step library: This is a collection of business process steps used to design business processes. The steps in the process step library are grouped by their functional area such as finance, production, or sales.
  2. Executable library: This is a collection of reusable executable objects, such as transaction codes or web pages, used to give process steps a means to carry out the system functionality described by the business process step. The executables can be SAP, non-SAP, or customer-developed. For the SAP objects, the executable library can be populated based on managed system use data. Executable objects are grouped by the logical component groups associated with the managed system and are sub-grouped by their assignment to the application component hierarchy defined by SAP.
  3. Development library: This is a collection of customer-developed objects or customer-created programs only. Like the executable library, the development library can be populated from the use data of existing managed systems. The objects are organized by logical component group and then by the application component hierarchy.
  4. Interface library: A collection of reusable interfaces used to illustrate how application systems in the solution are bridged to meet business process needs. These are organized by the scenario in which they were originally created.
  5. Configuration library: This library contains a collection of configuration units (such as IMG objects or BC Sets) used to describe the configuration of system functionality. It is organized by functional domain.

Libraries 2 through 5 are collectively referred to as the Technical Object Library or TOL.

How Different Component Parts of Solution Documentation Relate to One Another

Within a branch, there is a hierarchy similar to the BPH in the prior versions of Solution Manager. This hierarchy is the structure that maintains the parent, child, and siblings in the Solution Documentation collection of content. It differs from the BPH in that you can create as many levels of business process decomposition as you desire to describe your solution. The scenario, process, and process step node objects still exist, but they are the lowest three levels of your BPH. No additional levels can be inserted between them, nor can any levels exist below a step. This allows you to change the definition of a scenario to meet your business process decomposition needs.

(Note: Be careful with this flexibility. Because you can create as many levels as you want and the number of sub-levels can vary from one parent level to the next, the definition or scope of the scenario can vary from one business process structure to the next within a branch. If not carefully documented, this can cause confusion as current and future team members traverse the tree. It is advisable that efforts be made to standardize the use of levels in the process decomposition. The number of levels to which users should be building their branch is beyond the scope of this article.)

End-to-end business process documentation, business process decomposition, including scenarios, processes, and steps, and content from the TOL are combined to form the Solution Documentation (Figure 2).

Figure 2
Relationship of the content in Solution Documentation

For more detail about the relationship of content in Solution Documentation click here.

Basic Information About the New User Interface (UI)

Before we go into adding content to your Solution Documentation, we need to cover a few basics of the new UI in Solution Manager 7.2. Figure 3 shows the main UI used to build out the Solution Documentation.

Figure 3
The new UI for Solution Documentation

The first thing to note is that the interface is not SAP GUI. It’s all been converted to HTML5 and runs in any major browser, including Safari. The screen is divided into four sections:

  • Section 1 is the Header section. This contains the title of the Solution Documentation branch, navigation functions, and bread crumbs that show you where you are in the solution. Note that the last bread crumb is the name of the node selected in section 2.
  • Section 2 is where all the structure work is done for your Solution Documentation. In short, windows have replaced levels in the solution structure. For every level of decomposition created, another window is added horizontally in section 2.
  • Section 3 is the list of elements assigned to the node selected in section 2
  • Section 4 is metadata about the node selected in section 2

Section 2 is dynamic in that the windows within the section are created as you add child nodes to the Solution Documentation structure. As you select a node in a window within section 2, the window to the right shows the children of that node. This creates a left-to-right navigation rather than top-down navigation as before in the BPH. The windows scroll horizontally as the decomposition continues. Three windows are always shown in section 2 with the selected window in the middle, the parent on the left, and any children on the right.

The way you interact with the interface is different as well. There are very few buttons compared with prior versions of Solution Manager. The functionality that was there before (and more) is still there; it has just been moved to context menus. (Context menus are menus that change based on the context selected when the right mouse button is clicked.)

Each of the four sections has a different context menu, so it is important that you have your mouse pointer in the proper section before right-clicking. The context menu for section 1 looks like Figure 4.

Figure 4
Context menu opened with a right-click

The four menu items here are also available on all context menus on the screen. The context menu for section 2 appears as shown in Figure 5 when a Structure node is selected.

Figure 5
Context menu for a Structure node

The context menu for section 3 changes based on the type of node selected in section 2. If a Scenario, Process, or Step node is selected, the context menu for section 3 looks like Figure 6.

Figure 6
Context menu when a node type of Scenario, Process, or Step is selected

If a Folder node is selected, the context menu for section 3 looks like Figure 7 because only documentation can be placed in a Folder. Objects from the TOL cannot be placed in Folders.

Figure 7
Context menu when a Folder node is selected

Basic Concepts of Adding Content to a Solution Branch

First, a structure is needed to organize the Solution Documentation content within the branch.

Structure editing is done in section 2 of the screen. Click the white space in any of the three windows in section 2, and subsequently perform a right-click. The context menu that appears is for working with siblings of the content in the currently selected window.

If you select an existing structure element before using the right-click, you can create new siblings or make changes to the selected node. Use the bread crumbs in section 1 to quickly identify which node in the structure is selected as well as where you are in the structure decomposition.

When you select a node and then select the next window to the right, you create children for the selected node. The context menu that is shown when you perform a right-click is based on the attributes of the parent node.

In short, whichever window you select in section 2, a right-click creates siblings in that window that are children of the node selected in the window immediately to the left of the selected window.

To build out your Solution Documentation structure begin by right-clicking the middle window of section 2 and moving the mouse pointer over New. A subordinate context menu appears (Figure 8) showing the types of nodes that can be created (refer to Figures 4 to 7).

If the node selected in the window to the left is a Scenario, Process, or Step, the options for New are different:

  • Scenarios can have organizational units, master data, or processes as children
  • Processes can have process steps or interfaces as children
  • Process steps are the lowest structural element and can have no children

If the node selected in the window to the left is a Folder:

  • Folders can have folders as children and grandchildren for any number of decomposition levels
  • Folders can have organizational units, master data, or scenarios as children

If the node selected in any window is an Organizational Unit or Master Data:

  • Organizational units cannot have children, only siblings
  • Master data structure elements cannot have children, only siblings

Figure 8
Nodes that can be added to the Solution Documentation structure

As you build out the structure, you can add element assignments to the different structure nodes. The element assignments are conceptually the same as assigning content on the tabs of the BPH structure in prior versions of Solution Manager. In Figure 9, the right-click has been performed in section 3 to assign elements the scenario selected in section 2.

Selecting the scenario in section 2 is analogous to navigating to a scenario Business Process Hierarchy node in SOLAR01 in prior releases of Solution Manager.

The right-click in section 3 is analogous to selecting a tab to assign content to the scenario. (i.e., documentation, configuration, or transactions).

Figure 9
Object types that can be assigned as elements to a scenario

Figure 10 shows a side-by-side view of the same activity in Solution Manager 7.1 and 7.2. Both images are selecting a scenario for object assignments. The listed objects on the context menu in the 7.2 image on the right are analogous to the tab strip in the 7.1 image on the left.

Figure 10
Side-by-side view of Solution Manager 7.1 and 7.2 for object assignment to a structure element

As you can see, a great many things have changed in Solution Manager 7.2, and we’ve only scratched the surface here. In upcoming articles look for how to activate your existing solution documentation when performing a Solution Manager upgrade or setting up a new Solution Manager 7.2 system along with other guides for building Solution Documentation. As always, take the time to explore these functions in a sandbox Solution Manager environment and be diligent in establishing naming conventions and project standards for the use of Solution Manager.

An email has been sent to:


D. Russell Sloan

D. Russell Sloan is a specialist in project and program governance for IBM. He focuses on the use of SAP Solution Manager for global rollout projects for IBM’s largest customers, having worked with SAP software since 1996. Russell has degrees in accounting and information systems and has been a team and project leader for SAP projects for more than 14 years. He has been developing and deploying software systems for over 30 years.


Please log in to post a comment.

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