Manager
Learn about the roles and responsibilities of the team members using Solution Manager during the configuration phase. Walk away with some recommendations on how to store your documentation and transport references to deliver a more fully documented solution to your support organization.
Key Concept
Defining roles, responsibilities, and procedures for the configuration phase improves the quality and consistency of the configuration activities. Establishing standard procedures for storing the configuration documentation and transport references enables you to deliver more complete solution documentation that can reduce the cost of future support activities.
The configuration or realization phase of the project is when the team sets out to build the solution based on the business requirements defined and discovered in the blueprint phase. I like to say it’s the time to realize the dream of the blueprint.
During this phase there are many activities happening concurrently that have the potential to conflict with one another. These activities include doing baseline configuration and final configuration along with technical setup and configuration to support custom development. Here’s what happens during those activities:
- Baseline configuration: This is the configuration required to get the solution up and running. It covers the configuration activities required for the general operation of the SAP solution as well as the setup of business process functionality for normal business operations.
- Final configuration: This is the configuration required to handle business process exceptions, support third-party bolt-on applications, and to support custom development required to fill the business process gaps not supported by standard SAP functionality.
- Technical setup: These activities support the fundamental operation of the SAP solution. These activities activate application-level configuration for such things as cross-module and cross-system communication, standards for systems operation, enabling support functions, and other business process-independent capabilities.
- Custom development: The categories that make up custom development known as WRICEF: workflow, reports, interfaces, conversions, enhancements, and forms. This is all the custom programming needed to meet the business requirements.
- Configuration to support custom development: A significant number of WRICEF development objects depend on the presence of configuration. For example, an enhancement that uses plants or storage locations for decision logic needs the plants or storage locations configured before any testing is performed.
Lowest Common Denominator
One thing that all these activities have in common is the use of the Correction and Transport System (CTS). This is the SAP-delivered functionality for managing the release of system changes throughout the landscape. This process is also known as change deployment or software logistics.
For the remainder of this article, I’ll take a closer look at techniques for the management of transports for configuration and how to document your configuration in a way that can reduce support costs for break fix and future upgrades.
Note
You can use similar techniques for the management of transports for custom development, system patches, and other system change activities. The primary emphasis of this article is for the transports related to configuration. Further, this article does not distinguish between customizing and workbench requests. You can apply the processes described to both types of requests.
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 in harmony with the technical framework.
Manage the Use of Transports During Configuration
Separating the duties associated with the correction and transport processes provides better control of how configuration is bundled for release to the quality assurance (QA) environment. It serves your project well to centralize the creation of the transports and decentralize the creation of tasks within transports. This model provides your project with more control over how many transports are created through the course of your implementation.
Establishing clear roles and responsibilities early in the build (or configuration) phase is vital to governing the build. Three key roles and responsibilities that I recommend you establish in preparing to do configuration are the configuration coordinator, configuration team member, and functional unit tester:
- Configuration coordinator: This role involves understanding the relationships between configuration objects and activities. Using this knowledge, the configuration coordinator assigns work to team members to minimize conflicts. This person also creates and releases transport requests that deliver the configuration throughout the landscape. On large projects, a central team sometimes forms to manage the release of transports. This central transport release team serves as a secondary quality control point to assist in preventing cross-team-object conflicts and preserving the release sequence of transports.
- Configuration team member: This role handles the actual configuration and functional unit testing. This person has the authority to create and release tasks within transport requests, but cannot create or release the transport requests themselves.
- Functional unit tester: This role writes and executes test scripts that test a unit of functionality within the solution. For example, a unit could be a single SAP transaction. This person could also confirm that master-data-required fields are configured properly.
Your project will have many other roles related to technical and functional testing, data creation and management for test data, business involvement for confirmation of solution functionality before transport release, and so on. These roles are beyond the scope of this article.
Perform Configuration
Configuration activities must be carefully managed from the beginning to avoid object conflicts and to prevent sequencing errors related to the release of transports to the QA and subsequent systems.
Managing the configuration from Solution Manager allows you to control access to the configuration and encourage continuous documentation during the build phase of your project.
As I showed you in “Manage Configuration Through Solution Manager,” mapping the configuration elements to the Solution Manager Business Process Hierarchy (BPH) can reduce IMG navigation errors and save time for the configuration team by providing one-click access to the configuration table. Now let’s look at how the roles described above can help bring more control to the process of creating, testing, and releasing configuration changes in your environment.
Support Configuration Management in Solution Manager
Figure 1 shows a sample of configuration elements mapped to the BPH. In this example, it is configuration related to a specific process, and the lower order IMG objects have been mapped.
Figure 1
Configuration objects mapped to the BPH
The configuration coordinator is the one to perform the mapping of the IMG objects to the BPH. The reason for this is that the configuration manages configuration activities and scope. This role is usually a more senior role and relies on knowledge and experience to properly align the correct IMG objects to the business process.
As part of the mapping process, the configuration coordinator navigates the assigned IMG object to the satellite system and makes an innocuous change to the table to trigger the creation of the transport request. The coordinator creates the transport request and names it according to project standards.
The configuration coordinator then assigns the IMG object to a configuration team member to perform the configuration by putting the team member’s ID in the Person Responsible field on the IMG object assignment row. In Figure 2, you can see that user DRSLOAN is assigned as the person responsible for performing the configuration for business process Quality Gate Management — Information and Configuration Pre-Requisites. The configuration coordinator assigns all the configuration activities to the appropriate configuration team members within the given BPH node.
Figure 2
Assign a team member to the configuration element at the BPH node
The configuration coordinator can also assign the transport request to the BPH node to house the configuration activities associated with the BPH node. Because the configuration team member is authorized to create transport tasks, the assignment of the transport to the BPH node can help remind the configuration team member which transport to use when doing configuration for this process.
Note
The assignment of transports to the Configuration tab in the BPH is not a requirement of required Solution Manager or CTS functionality. Adhere to all project standards and policies for transport assignment and documentation.
The configuration team member documents the configuration activities according to project standards as they perform the configuration. This documentation is then stored with the configuration on the BPH node on the Configuration tab as shown in Figure 3.
Figure 3
Assign the configuration documentation with the configuration element assignment and the related transport
This process repeats with throughout the other IMG assignments to the BPH structure.
As the configuration team member completes a collection of configuration activities related to a particular business process, the member performs a unit test to verify the configuration is ready to move to the QA environment.
Once the unit testing is complete, the configuration team member releases the transport tasks and notifies the configuration coordinator that the configuration is ready to move to the QA environment. Note that the procedures and criteria for determining the successful completion of a unit test are defined by the project, not by this article or the designed functionality of Solution Manager. The procedures for releasing the task are also defined by the project.
The configuration coordinator reviews the work done by the configuration team member and determines if the transport is ready to release to QA. The procedures for this determination are beyond the scope of this article.
Figure 3 shows how following these procedures results in the ability to deliver all the configuration elements, transports, and documentation related to the customizing of a business process over to a support organization as a process-aligned unit of work. This provides for easier troubleshooting when doing break fix and can reduce the cost of doing impact analysis for process change or upgrades.
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.
