IT administrators involved in virtually all large implementation projects face the challenge of managing configuration activities. Modern global implementations embark on a configuration subphase that can involve team members in many time zones and geographies working concurrently. Coordinating these activities is imperative to minimize the risk of rework and to help prevent conflicts with common configuration objects. 

For the purposes of this article, I’ll limit the scope of discussion to just the SAP ERP Central Component (SAP ECC) solution landscape, and more specifically, the Solution Manager system IMG itself. The examples used here apply to the SAP ECC IMG as well. Other considerations and techniques are required when you move into other SAP products such as SAP NetWeaver Business Warehouse or SAP Supplier Relationship Management. I’ll show you how to set up a successful framework for scoping and managing the configuration as well as explain how Solution Manager navigates your solution landscape to support your configuration activities.

A Framework for Success

While Solution Manager provides a technical framework that can help you minimize your risks during configuration, it is equally important that you have a project framework that is in harmony with the technical framework.

Before going further, it’s important to cover a few key terms:

• Business Process Hierarchy (BPH): This is the primary structure in the blueprint phase that is used to map out the scenarios, processes, and steps for the scope of your project.
• Configuration: The term configuration has several connotations. For the purposes of this article I use it to mean both the act of customizing the SAP solution and the name of a structure element within the BPH.

For this example, I’m using a project that has been built to manage the configuration of Solution Manager. This example is to support illustrating the concepts in a Solution Manager context to avoid making assumptions of the reader’s knowledge of the other SAP products.

Plan the Configuration

The first step is to plan the configuration work. In this context, I’m referring to both defining the scope and structuring the configuration activities around both the solution build and the support of business processes.

For the solution build activities, the BPH provides advantageous structural constructs that allow the team to manage work by both the way you build an SAP solution and how you tailor it to fit business process requirements.

In transaction SOLAR02, a secondary structure is made available. Unlike the predefined scenario, process, step hierarchy for the business processes in transaction SOLAR01, the configuration structure is very free form. Selecting the Structure tab in transaction SOLAR02 (Figure 1) reveals a different view from what you see in the Structure tab in transaction SOLAR01 (Figure 2).

Figure 1

Transaction SOLAR02 Structure tab

Figure 2

Transaction SOLAR01 Structure tab

The free-form nature of the Structure tab in transaction SOLAR02 allows you to build a hierarchy that represents how the solution is built rather than how it is used in transaction SOLAR01.

It is important to establish some guidelines for the team to help them take advantage of the benefits of these two different hierarchical organization structures.

Configuration Categories

Establish categories for the configuration activities. I recommend a few basic ones, as I’ll describe. Keep the number of categories for configuration to a minimum to avoid confusion.

Cross-Application and Technical Configuration

This type of configuration is required for the basic operation of the SAP ECC solution. This is configuration that must be performed regardless of the scope of the SAP ECC capabilities you are deploying. Figure 3 has some examples of the cross-application and technical configuration activities from the SAP ECC IMG.

Figure 3

An example of cross-application configuration

Cross-Process Configuration

Cross-process configuration is relevant for a business area or scenario, but it crosses business processes. An example is basic configuration for change control management in Solution Manager. These configuration elements are stored within the Configuration tab on the BPH on the Change Control Management scenario, rather than with the project-level Configuration folder structure. Figure 4 shows an example of the cross-process configuration assignment at the scenario level of the BPH.

Figure 4

Cross-process configuration stored at the scenario level in the Configuration tab

Process-Specific Configuration

Process-specific configuration is unique to a specific business process. For example, within the Change Control Management scenario, there is a collection of discrete business processes (e.g., general change, urgent change, normal change, administrative change, and defect management). Mapping the configuration for these business processes within the process level in the Configuration tab helps you align the configuration to the logical unit of work. This alignment allows you to deliver your finished solution fully business process aligned.

Figure 5 shows the selection of process-level configuration for Quality Gate Management from the Solution Manager IMG as an example.

Figure 5

Select the Quality Gate Management configuration elements from the Solution Manager IMG

Project Configuration Management and Coordination

Now that you know the capabilities at your disposal, you’re ready to begin building out the configuration scope for your project.

Using transaction SOLAR02, navigate to the Structure tab at the Configuration folder level in the hierarchy. From here, you can begin setting up the folder structure to organize and manage your configuration activities. (Remember, this area is for those configuration activities that cut across your business scope or are needed for the basic operation of the SAP ECC solution.)

As a general rule, I recommend starting out by emulating the IMG structure for those items that are the bare necessities of the SAP solution. In this example, I’m using the Solution Manager IMG and capturing those basic configuration items needed to set up Solution Manager for minimal operations requirements and the implementation scenario.

Figure 6 shows an example of an initial folder structure built in transaction SOLAR02. In this example, sample folder structures have been started for Solution Manager Basic Settings and Technical Settings. Additionally, there is a sample of a folder structure for cross-application settings for SAP ERP 6.0. This sample illustrates how Solution Manager provides for multiple SAP products to be managed in the same Solution Manager project.

Figure 6

Initial folder structures for configuration management for cross-application configuration for Solution Manager and SAP ERP 6.0

Note that the Structure tab in SOLAR02 has a Change Configuration Structure button rather than a table view such as in transaction SOLAR01. This is because transaction SOLAR02 supports a freely definable folder structure. Now you are ready to see how this structure is built.

When you click the Change Configuration Structure button, you are presented with a table for entering folder names for the first level of the structure. Enter the folder names for the top level of your planned structure and click save.

Figure 7 shows the entry view for creating the folders as described above. Note that the folder names match those shown in Figure 6, but that the lower structures for organizational units, master data, and business processes are not displayed.

Figure 7

Configuration structure maintenance view in transaction SOLAR02

After saving your data, click the refresh icon  to see the updates to the configuration structure. To create a folder at a lower level in the hierarchy, select the folder you want to be the parent (or higher order) folder for the new folder. Figure 8 shows the structure maintenance view for creating a lower-order folder underneath SAP Solution Manager – Technical Settings.

Figure 8

Create lower-order folders in the configuration structure

Figure 9 shows the folders created for the scope of the project. This example project does not have all the technical capabilities of Solution Manager in scope. Therefore, only a subset of folders is created to manage the configuration activities.

Figure 9

Folder structures beneath Technical Settings to manage the subset of technical capabilities in the scope for this project

You can repeat this process to build out a configuration management structure to as many levels as you need. This enables your project team to manage the configuration in the way that makes the most sense for your scope and project team structure.

Once you have your folder structure developed, it is time to begin assigning the configuration elements to the structure. 

Exit the configuration structure maintenance by clicking the green back arrow icon .

Next, select the folder in which you want to assign configuration elements and click the Configuration tab. Figure 10 shows the Configuration tab selected.

Figure 10

The Configuration tab selected for a configuration structure folder

Before I proceed further, it is necessary to understand a couple of key concepts about how Solution Manager sees your solution landscape. 

The first concept is that of the logical component. The logical component is a description of a particular product in your solution landscape. It is made up of the SAP product, version, systems, and clients.

For example, if you have SAP ERP 6.0 as part of your solution landscape, you probably have a development system, a quality assurance system, and a production system at a minimum. Further, you most likely have multiple clients in your development and quality assurance systems to support configuration management, development, testing, and training activities throughout your project. The logical component is used to describe this landscape to Solution Manager. Table 1 shows an example of the information that is housed in the logical component definition.

Table 1

Example data for a logical component definition

The first two columns in Table 1 tell Solution Manager about the product and version in the landscape. The remaining columns describe the system roles for the product landscape.

The second key concept is the system role. This combination of system ID (SID) and client is used for a specific purpose. In Table 1, the development system client 100 is used for configuration activities, while the development system client 120 is used for ABAP programming activities. 

You can assign many system roles to Solution Manager logical components to support complex SAP product landscapes. The SAP system delivers a series of system role names, and you can augment these by creating your own names. The definition and setup of logical components is beyond the scope of this article, but Figure 11 shows the logical component definition for the Solution Manager system used in this article, shown in transaction SMSY.

Figure 11

Logical component definition for Solution Manager

Why are logical components and system roles important for this discussion? When you assign a configuration scope to your project, Solution Manager connects to the satellite or managed systems to retrieve the IMG components. To accomplish this connection, Solution Manager needs to know to which system and client it should connect so that it can retrieve the proper IMG.

To assign the configuration to the project, first make sure you are using the correct system role. For example, if you wanted to assign configuration for SAP ERP 6.0, set the system role to Development Configuration based on the information provided in Table 1.

In the examples that follow, I’m assigning configuration for the Solution Manager system. The example Solution Manager system that I used to illustrate this activity of the system role is Production. This is because, unlike the other systems in the solution landscape, Solution Manager takes on a production-like role very early in the project.

To set the system role, use menu path Configuration > System Role. Figure 12 shows the selection of Production System.

Figure 12

Selection of a System Role for configuration mapping navigation

Once the system role is set, you can assign the configuration elements in the Configuration tab.

The first step is to select the Configuration tab and click the drop-down menu in the first column of the first row. This menu provides you with a list of the different types of objects that can be assigned to the Configuration tab. As you might recall from the note at the beginning of this article, special considerations are needed for managing configuration of other SAP products. There are many different object types available in the Configuration tab. For this example, I’m using IMG Object (Figure 13).

Figure 13

IMG Object selection for the Object Type column in the Configuration tab

The next column in the Configuration tab is for the selection of the logical component. This drop-down menu presents you all the logical components assigned to the project. This list is a subset of the logical components in Solution Manager and is managed via assignment in transaction SOLAR_PROJECT_ADMIN.

Once the logical component is chosen, you can move to the Object column to select the IMG objects you want to assign to the folder. When you click the drop-down menu or prompt button in the Object column, Solution Manager uses the combination of logical component and system role to determine how to navigate to the proper IMG in the solution landscape. A pop-up appears containing the IMG of the satellite system. This pop-up allows you to select one or more configuration objects from the satellite system to assign to your folders. Figure 14 shows the Configuration tab with the logical component selected and the results of prompting in the Object column.

Figure 14

IMG displayed when the Object column prompt is chosen

In the example in Figure 14, you see the IMG for the Solution Manager system because the Solution Manager logical component Z_SOLMAN_COMP is selected. Had you chosen a logical component defined for the SAP ERP system, then the IMG for SAP ERP would be displayed in the pop-up.

It is important that you take the time to navigate down the IMG tree to the lower levels of the structure. While it is technically possible to assign IMG objects to your project at any level, by assigning the IMG objects at the lower levels, you reduce the risk of navigation errors in subsequent configuration activities as well as improve the granularity of the solution documentation that is delivered with the final solution.

As you navigate down the IMG tree to select the appropriate configuration elements to assign to your project, use the following as a guide to determine how far down the structure you should go before selecting the element.

If you know you need to configure every element beneath a given IMG node, then it is valid to select the higher-level node as the assignment to the Configuration tab. If you are going to use only a subset of the child nodes, it is better to choose only the nodes in scope at the lower level of the structure.

The example project does not have Root Cause Analysis in scope for Solution Manager. Under the Client Copy section of the Solution Manager IMG, I selected only the first two child nodes (Figure 15). However, all aspects of Status for Documents are in scope for the example, so selecting the parent node is valid. Figures 15 and 16 illustrate these principles.

Figure 15

Selection of only some of the child nodes within an IMG section

Figure 16

Selection of all child nodes within an IMG structure

While in Figure 16 it may appear that I selected each of the child nodes individually, Solution Manager has selected all the child nodes for me because I selected the check box at the parent node.

Figure 17 shows the Configuration tab assignments that result from the selections illustrated in Figure 15. Note that each of the child nodes selected copies into the project as a separate row in the Configuration tab.

Figure 17

Child nodes copied to the Configuration tab for the project

Figure 18 shows how the parent configuration node is copied based on the selection illustrated in Figure 16.

Figure 18

Only the parent node is copied to the Configuration tab for the project

While the assignment of the parent node to the Configuration tab is quite convenient, it provides as much detail of the configuration activities in scope without navigating to the satellite system’s IMG. I recommend that you should establish standards of when to assign lower-level nodes and when to use parent node assignments to provide for consistency of solution documentation.

Repeat the process described above to finish your configuration structure and IMG object assignments until you assign the cross-process or cross-application configuration elements in scope for your project.

The next task is to map the configuration for the business process-specific IMG objects. These are configuration objects that pertain to the functionality of the business processes in scope for your solution. You can assign configuration elements to the organizational units and master data sections of the BPH in addition to the Business Processes section of the structure. The mechanics of doing so are the same for all three areas, so I’ll focus on just the assignment of IMG objects to the business processes.

To assign the IMG object for your business processes, navigate to the Business Processes section of the BPH. Figure 19 shows the BPH structure starting at the Business Scenarios section.

Figure 19

The BPH at the Business Scenarios section

Figure 19 shows the list of business scenarios in scope for the project. You can assign configuration elements to the Scenario level of the BPH for those configuration elements that cross business processes within the scenario. Again, if the configuration crosses scenarios, it may make better sense to create a folder for it in the Configuration section of the BPH.

As you navigate down the tree within a scenario, the business processes defined during blueprint are displayed. To assign configuration elements to a particular process, select the business process and then click the Configuration tab.

As before, select IMG Object for the Type column, choose the appropriate logical component, and then prompt on the Object column to display the IMG in the satellite system. Select the IMG objects for the business process by following the same rules and procedures that you used within the Configuration folders that I already described.

Figure 20 shows the selection for an individual business process.

Figure 20

Assign IMG objects to a business process

Continue making the IMG object assignments for your other business processes until you assign the entire configuration in scope for your project.

Perform Configuration Activities

When it is time to do the actual configuration, you simply navigate to the appropriate node on the BPH structure. Select the Configuration tab and select the row that contains the configuration element (or IMG object) for the configuration you want to perform. Click the configure icon  to open the IMG in the satellite system at the exact point you need to perform the configuration. This eliminates the time-consuming, error-prone tree navigation associated with direct access to the IMG via transaction SPRO.

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.

You may contact the author at solmanruss@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.