Manager
Learn how clearly identifying SAP Solution Manager roles that address your organization's requirements and support the future use of SAP Solution Manager functionalities can allow you to build a robust position-mapping role matrix.
Key Concept
After a successful implementation, SAP Solution Manager should run smoothly and provide transaction access to user groups with the proper authorizations at the correct times. In addition, end users should encounter minimal errors. However, crucial to achieving this state is identifying positions and roles for all users and then creating a role matrix that maps SAP Solution Manager transactions to these roles. By understanding key transactions, positions, and user group requirements, you can develop and customize a role matrix for long-term use.
Organizations implement SAP Solution Manager for a variety of purposes — for developing and recording the blueprint scope, to act as a document repository or a central tool for configuration, or for test plan and project management. These functionalities cater to different user groups, and each of these groups can perform unique tasks, related tasks, or tasks that overlap with one another. Organizations often also have multiple projects. This can become very detailed and confusing, so you must define clear roles and responsibilities for SAP Solution Manager. Although SAP Solution Manager is delivered with standard roles for various user groups, your organization may not be able to use them as is. These roles contain generic central authorizations, but organizations typically have custom requirements that span multiple roles and authorizations.
I’ll present a brief overview of the key activities typically performed in each project phase in SAP Solution Manager and indicate the transactions that correspond to each. I’ll then highlight some of the main criteria and issues you should consider while identifying and building a role matrix that encompasses all the user groups in your organization. I identify typical activities and transactions that are used in various positions and illustrate the process of developing a role matrix.
Additionally, I’ll provide a framework for identifying important roles across each SAP Solution Manager phase (Project Preparation, Blueprint, Realization, Final Preparation, and Go-Live and Support) as well as the reporting requirements. Based on positions in your organization, you can then assign SAP Solution Manager roles appropriately to your users.
SAP Solution Manager Activities and Transactions
As you may know, SAP Solution Manager acts as a central repository for setting up implementation or global template projects and linking them to corresponding systems where business processes are designed, configured, integrated, and tested during an implementation. A repository is a structured set of elements encompassing the business scenarios, configuration, and process documentation. Additional details on the repository process are available in Gaetano Altavilla’s "Guide Your Implementation Project with SAP Solution Manager." You can manage system monitoring after go-live with SAP Solution Manager. It also provides tools, content (e.g., Roadmaps), and best practices and acts as a gateway to SAP support.
The key activities in the project life cycle form the basis of SAP Solution Manager use and can help you determine the roles and authorizations required for a role matrix. These key activities are:
Project Preparation
In the project preparation phase, your organization must define the implementation strategy, system landscape, transport strategy, team members, and project standards for status reporting. I’ll show you an example of this later in the section “Identify Role Details and Transaction Access.”
Typical users in this phase include the project managers or project coordinators, functional consultants, and Basis team members. Project managers or coordinators chart out the project scope, implementation strategy (e.g., global template project vs. implementation project), team members, key milestones, and roadmaps, as well as provide input on the system landscape.
A template project is used to create a global template of a preconfigured solution. The template created in the template project can be used in other projects (e.g., implementation projects) independently of the template project in which the template was created. Implementation projects can be based on the global template and used for local site rollouts. You cannot reuse the structure of implementation projects in other projects. The functional consultants translate the SAP Solution Manager project requirements into actionable steps and work out the details in conjunction with the Basis team. The Basis team helps with installing SAP Solution Manager, connecting SAP systems to SAP Solution Manager, and setting up iBase, among other tasks. The functional consultants also assign team members to the project and define the project standards and visibility. By default, templates defined in the template project are not available or visible to other projects in the system. You can publish a template to make it visible by changing the visibility status in the Templates tab in project administration (transaction SOLAR_PROJECT_ADMIN) from private to public. This makes the template available for selection across all projects in the system using the Scope tab under project administration.
The key transactions used in this phase are:
- SMSY — system landscape
- SOLAR_PROJECT_ADMIN — project administration
The key criteria to understand in this phase are:
- What is the implementation strategy or project scope? This helps determine the project type.
- What are the various processes that will be implemented? These could be the SAP-defined templates or the custom scenarios implemented to suit specific needs.
- What is the solution and system architecture? This helps determine the logical landscape definition and transport strategy.
- What is the role of SAP Solution Manager consultants or the help desk in the overall setup? Differentiate the responsibilities between these groups and the Basis team members (e.g., an SAP Solution Manager consultant creates the project, supports the blueprint and realization, and creates business partners and teams for the Service Desk, while the Basis team helps with the system landscape setup).
- How will you prepare the project environment? In terms of activities in SAP Solution Manager, this criterion is the most important. It includes defining project standards, reporting processes, configuring SAP Solution Manager, preparing the project environment, and training the project team on Business Blueprint functions.
Tip!
As part of project preparation, understand the key project deliverables in each phase and clearly define document templates and naming standards. This helps facilitate consistency across teams and deliverables.
Business Blueprint
The Business Blueprint is the storehouse of the project structure used in a template project or an implementation project. In the Business Blueprint phase, process consultants work with an organization and its IT department to understand the current as-is process the business has in place and define the to-be business scenarios, organizational structure, and master data. This is a crucial phase because it forms the foundation for realization and subsequent activities.
Typical users in this phase are business, IT, and process consultants. Various business process-related documentation (e.g., swim lane diagrams, customer business process requirements, analysis, and documentation and management scoping) are created in this phase. The Business Blueprint team maps the transactions to the process steps of the Business Blueprint structure, generates the structure, and identifies any process gaps.
The key transactions used in this phase are:
- SOLAR01 — The Business Blueprint structure is defined and accessed with this transaction. It is also used to create documentation, assign administrative data at various hierarchical levels, assign transactions to process steps, and create messages on errors.
- CRM_DNO_MONITOR — The Transaction Monitor accessed with this transaction is used to monitor and process SAP Solution Manager messages. It offers a central location for managing the messages created in all the various project phases.
The key criteria to determine in this phase are:
Realization
The realization of the process structure defined in the Business Blueprint of a template project or implementation project is carried out in this phase. Activities such as configuration, FRICE (Forms, Reports, Interfaces, Conversions and Enhancement) object management, end user roles, test plan management, and defect management are carried out.
Typical users in the realization phase are the IT configurators, business testers, test plan administrators, and change management or training users.
The key transactions used in this phase are:
- SOLAR02 — The configuration transaction is used to assign transactions, programs, and IMG objects to the project structure; configure IMG nodes; create and edit test cases; and create documents for configuration-relevant settings
- STWB_2 — This Test Plan Management transaction is used by test administrators to define test plans or packages and to assign testers to them
- STWB_WORK — This is a work list that allows testers to access test cases and execute them
The key criteria to determine in this phase are:
Final Preparation
In this phase, the preparations for go-live are completed, integration and user acceptance testing are validated (along with data conversion rehearsals), and detailed cutover planning takes place. You can use the test plan management and tester work list transactions for integration and user acceptance testing. The cutover planning documents created in this phase are also stored in SAP Solution Manager.
Typical users in this phase are IT and business testers, integration managers, and change management or training personnel.
The key transactions used in this phase are:
Go-Live and Support
After go-live, continuous support is provided through solution monitoring for efficient system landscape management. This may include the use of external management tools and services provided by SAP, such as SAP EarlyWatch Alerts and optimization services.
Typical activities in this phase include handling problem messages with the Service Desk, Service Level Reporting for continuous monitoring and reporting, system monitoring for real-time monitoring of systems in the solution, and business process monitoring.
Typical users in this phase are the help desk and end users. Key transactions used in this phase are:
Role Matrix Creation
The role matrix creation process is broken down into three steps:
Step 1. Identify key positions in the organization
Step 2. Identify roles that will be performed by the users at the key positions
Step 3. Identify role details and transaction access, and map all of the above
Identify Key Positions in the Organization
I recommend a top-down process for identifying the key positions, activities, and transaction access. The advantage of this approach is that it provides flexibility to tailor the roles to an organization’s positions, responsibilities, and transaction use. This process involves defining the current as-is positions and activities performed by the positions, as well as the expected to-be positions and activities that will be performed in SAP Solution Manager.
The alternative approach is to have a bottom-up process in which you first define the expected roles. Then you map the positions, responsibilities, and transactions to these roles. The disadvantage is that this is often a repetitive process. You will have to redefine the roles if positions and responsibilities cannot be mapped to them or even modify the organizational structure (e.g., positions, responsibilities) to suit the roles.
A sample structure built using the top-down approach is illustrated in the next section of this article. You can define additional positions based on your needs. Typically, all system users need SAP Solution Manager access for performing their activities. Whenever a new system user is created for any of the component systems, you should also set up SAP Solution Manager access and the required roles. If necessary, you can set up and assign a display-only role to users that do not need SAP Solution Manager access.
Sample Structure
Program management group or office: Monitors overall project progress, views reports, and can also view the project scope and details
Project manager: Involved in the actual SAP Solution Manager project setup (e.g., project standards and locking the Business Blueprint), in addition to monitoring the milestones, project progress, and scope
Team lead: Defines the process scope, structure, implementation, testing, and reporting of the in-scope processes (e.g., order-to-cash lead and finance lead), depending on the project. Also coordinates, reviews, and approves the work of the team members.
Team configurator: Performs system configuration of component systems and adherence to Business Blueprint requirements, validates testing, and supports issue resolution (e.g., order-to-cash configurator and finance configurator)
Test team coordinator: Manages testing in all phases and validates test cases against the Business Blueprint scope. Responsible for tracking testing progress and status reporting. Facilitates defect management and issue resolution (e.g., integration test coordinator and finance unit string test coordinator).
Testers from the business: Identify and execute the test cases, and validate if the configuration and FRICE objects meet the business requirements. Identify and log defects in the Service Desk and validate the fixes. In addition, project team members (e.g., team configurators) are also sometimes involved in unit/string testing and log defects in the Service Desk.
SAP Solution Manager administrator: Supports initial SAP Solution Manager setup and project setup. Assists in landscape definition, including defining roles and responsibilities and implementing Service Desk and the supporting processes for its use (e.g., organization model and business partners). Also typically performs SAP Solution Manager activities in phases such as Business Blueprint and Realization (e.g., test management or customizing message status).
Tip!
The system landscape should remain in the scope of the Basis team because they are responsible for the management of the overall system environment.
Identify Roles Performed By Users
In any SAP Solution Manager template or implementation project, it is advisable to structure roles that can suit the positions you have previously identified. A role matrix that identifies roles and their activities can help minimize role redundancies.
A sample set of roles, along with the transactions you can define, follows. Note that the roles should cover the responsibilities of the positions that have been identified by your particular organization. Typically, you can map multiple roles to a position. An example set of the transaction codes mapped to the roles is shown in Table 2 later in this article.
Project manager:
- Creates, changes, copies, and deletes projects
- Displays the system landscape
- Has access to edit general data, scope, project team members, and project standards
- Runs differences between template and implementation projects. The SAP Solution Manager implementation project is based on the template from a template project or Business Process Repository. If the source template has changed, you can copy the changes over to the implementation project by executing the Compare and Adjust function via transaction SA_PROJECT_UPGRADE. This flags the differences in the project structure and documentation, and these changes can be copied over to the target project.
- Has access to lock the Business Blueprint from changes by the blueprint administrator and change the template visibility. If the template project is used for a global rollout via implementation projects, the project manager can lock the template against changes by locking the Business Blueprint structure in Project Administration (transaction SOLAR_PROJECT_ADMIN).
- Creates project IMG in component systems
- Displays access for Business Blueprint and configuration for all tabs and support messages
Team blueprint administrator: Defines the business process structure, creates and uploads documents, updates statuses and keywords, and assigns team members to the business process structure.
Team configurer: Configures the component systems based on the Business Blueprint requirements, creates and assigns test cases to business processes, assigns team members, adds IMG nodes, and creates configuration documents and Business Configuration (BC) Sets.
Test administrator: Identifies and creates test cases in SAP Solution Manager and performs test planning activities (including the creation of test plans and test packages, assigning testers, and test monitoring).
SAP Solution Manager configurer: Performs activities such as creating business partners, an organizational model, and determination rules for the Service Desk. Also supports any configuration-related activity (e.g., customizing a message status).
Tester: Executes the assigned test scripts, records results, and logs defects on errors. This role is the primary user of the Service Desk and depends on the scope of the use of Service Desk functions.
Tip!
You can define some testers as Level 1 Support and give them the responsibility of sending messages to SAP.
Message processor: Performs Level 1 Support activities for testing, resolves defects, and sends messages to SAP if required
Reporting role: Performs project analysis and generates periodic reports to assess progress in different phases (e.g., testing, Business Blueprint, and configuration activities)
Display role: Displays the project’s Business Blueprint structure, configuration, and messages. Can also view and display documents in the General or Project Documentation tabs of the blueprint and configuration transactions (SOLAR01 and SOLAR02).
Developer: Performs custom specific developments. Typically works with the ABAP Workbench and develops forms, reports, interfaces, or enhancements. These are linked in configuration SOLAR02 (via the Development tab), and developers can run the standard reports available in transaction SOLAR_EVAL to track status and work.
Tip!
You can expand the sample roles I provide to cover your specific requirements. For example, if the change management or training team is required to load only documents in the General Documentation or Project Documentation tab (in transactions SOLAR01 and SOLAR02), you can create a new role of document administrator. Additionally, you can create a separate role for software development that allows a user to edit only the Development tab and General Documentation or Project Documentation and Messages tabs in configuration while also providing display-only access to the Business Blueprint.
Table 1 shows an example of the assignment of positions to roles.
Table 1
Position to role mapping examples
Identify Role Details and Transaction Access
Once you have identified all the roles, you can create a transaction and authorization worksheet to map the roles and the transactions (Table 2). In this step, the transaction access required by the various roles is identified (e.g., will display-only access suffice for this user, or is create-and-change access needed?).
Table 2
Role transaction worksheet example
If additional roles are required, then transaction access must be determined. For example, if change management or training is an identified position that involves creating documents or Learning Maps, then you can create a new role called “change management/document administrator” with create and change access to the General Documentation tab, Project Documentation tab, and User Roles tab.
After you identify the roles and transactions and build the role matrix, the Basis team or the dedicated team responsible for authorizations can help set up the roles in the system. To validate that the roles created meet the requirements, you can create fake users and assign specific roles to the users for unit/string testing. Comprehensive test scripts can be written by the Basis team in conjunction with SAP Solution Manager administrators to simulate and validate user transaction use and the role setup to make sure that it works.
After you have tested the individual roles, you can optimize the role matrix and create composite roles for positions (Table 3). In my example, I structured the team lead position as a composite role with individual roles included in it.
Table 3
Example of a composite role set up
Sundar Chandrasekaran
Sundar Chandrasekaran, a manager at Deloitte Consulting LLP, is a process consultant in the aftermarket industry and has led global SAP supply chain SPP and SNC implementations. He has also managed supply chain integration, improvement, and sales & operations planning assessments. He holds an MBA from the Indian Institute of Management, Lucknow, and a bachelor’s degree in computer science engineering from REC India.
You may contact the author at suchandrasekaran@deloitte.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
Premium
