Many times when I talk to customers and partners, I hear people who are resistant to or uncertain about SAP Solution Manager and its methodologies, saying things like:

• “Why do I need to bother with SAP Solution Manager?”
• “It seems very complex.”
• “I have been implementing SAP products for 10 years, and I can tell that you don’t need it!”

My answer is that, simply put, an implementation of any SAP solution will cost less and go more smoothly with SAP Solution Manager methodologies and tools. The total cost of ownership (TCO) is much higher when good methodologies are not used in SAP implementations. I have found SAP Solution Manager is especially useful in situations where implementations do not have any workable documentation or the original implementation team is no longer available.

This is not a technical issue because SAP Solution Manager is already a proven tool. Instead, it is a management issue. This article is aimed toward project managers, applications managers, IT managers, process teams, managers, or anyone else who organizes, sponsors, and runs SAP projects at a business. If you (or someone you appoint) does not act as a guide or mentor for the SAP Solution Manager proposal from the start, there is a chance that future projects and teams won’t use SAP Solution Manager or will use it incorrectly. When you introduce SAP Solution Manager in a resource-restricted environment where there is little experience using methodologies in projects, it is a best practice to approach the effort in this way:

1. Find the champion
2. Get support from the stakeholders
3. Promote a process-oriented approach
4. Set up project standards
5. Train and coach the users

1. Find the Champion

Before starting your first SAP Solution Manager project, you should begin discussions with a “champion” for it — someone you know who can talk to the stakeholders using the right words, choosing the right audiences, at the appropriate time. To succeed, it is important that you find a proper champion for the positioning of SAP Solution Manager as a strategic tool that not only contains information about your company processes, but also acts as the backbone for SAP support. This role should be given to someone who possesses and can balance technical and management viewpoints.

You should formalize the role of champion, and then create an SAP Solution Manager functional administrator position. This administrator performs the everyday work involved in SAP Solution Manager administration and definitions, including creating new projects, setting up standards in the system, reviewing usage, and other functional activities. This role should be filled as soon as possible so that he or she can be part of the entire process. If you find the right person, you have already won half the battle for an efficient application management strategy.

A clear ongoing communication plan should be set up with management so that the proper support is available at all times. The person who takes the champion role should be able to communicate with the right words the benefits for the organization of undertaking this endeavor. In some cases, the champion can also act as the functional administrator. You could choose to evaluate whether one person has the abilities for both roles or if it should be divided between two different people. If your organization is small, I’d recommend that you have one person doing both roles.

2. Get Support from Stakeholders

Once the champion has been identified (or you are in the process of getting that person on board), then you should start talking to the various stakeholders (with the support of the champion if possible). I’ve found that it is best to first talk to IT management or those who define strategies and then roll out to the mid-management level. You need to have this talk in “business speak.” Show the value of SAP Solution Manager to management before going into the technical details. They need to understand both the short-term and mid-term benefits and that only some of the benefits are quantifiable. Stress that the main purpose of SAP Solution Manager is to support application life cycle management over time, improving quality and reducing time and cost. These goals are mainly IT’s responsibility, so that is why you should tackle them first.

When you know that management supports your proposal for SAP Solution Manager and would like to hear more, go into details of the functionality. Focus on tools that cover the full life cycle and avoid a one-to-one feature comparison against other tools that may be available at the company (e.g., the help desk, document repositories, process modeling). Talk about integration: SAP Solution Manager is the technical platform on which many integrated functions (such as implementation projects, Service Desk, Change Request Management [ChaRM], monitoring, and business process monitoring) are available with no additional license fee from SAP. Review the details of the functionality, relate them to bottlenecks in the current processes, and focus on how SAP Solution Manager can help solve these issues. Concentrate on the big picture, which is that the integrated functionality of SAP Solution Manager supports your applications from inception to production.

Certain communication activities can persuade management (and the company as a whole) to adopt SAP Solution Manager. These activities include presentations, overview, and hands-on training for the various groups in the organization, coaching activities for actual projects, and internal communications about the value that SAP Solution Manager brings to the organization.

After the Initial Approval

When it comes to the actual implementation of SAP Solution Manager, you should start small — without losing the understanding that you need to think big eventually. Starting small means, for example, implementing solution monitoring, working with a small implementation project, and implementing out-of-the-box Service Desk or ChaRM urgent correction functionalities. So then what does it mean to think big? It means that you understand the full picture. Use the Information Technology Infrastructure Library (ITIL) to understand what the IT processes are (e.g., Incident Management, ChaRM), use Run SAP to define a way to implement these new IT processes, perform an assessment and scope to set up the complete framework for operations, and establish a clear scope with the roadmap to implement.

Ensure that application management, quality, the Project Management Office (PMO), and project management all support the SAP Solution Manager initiative from both the management position and from the functional rollout position regarding the use of the tool. You can get this support by approaching them during the communication activities I described earlier in this article. Management can help you roll SAP Solution Manager into projects. You must establish who the stakeholders are, what their stakes are, and their main needs and requirements (e.g., legal, auditing) regarding project information. These are some of the topics you should discuss with them to plan the deployment of SAP Solution Manager:

• Is there a current SAP project implementation methodology in place?
• Is that methodology compatible with the ASAP methodology and SAP Solution Manager functionality?
• Do you need reports on project performance? 
• Can you replace or complement project performance information using standard SAP Solution Manager reporting?

• Do you need to create specific ad hoc reporting?

3. Promote a Process-Oriented Approach

I have learned from my experience using SAP Solution Manager for projects — be it an implementation, upgrade, global template, or rollout — that you need to switch from a module to a process-oriented view. For example, setting up a structure using transaction SOLAR01 is technically simple, but you have to be sure that the structure you set up is an effective business structure that represents the actual processes of the company. It must be one that key users, process owners, and other businesspeople clearly recognize and understand. Once the business process structure is understood and agreed on with all the relevant teams, representing it in SAP Solution Manager is a straightforward activity.

Don’t hesitate to spend time discussing business process definitions before going into the details. It’s often a good idea to hire an SAP Solution Manager external consulting expert who can act as a support for the introduction of SAP Solution Manager in the company, has a solid process approach, and provides support during all phases to project managers and users. This expert can help people make the change from a solution approach to one based on processes. That message should then pass to the whole team. The first to be engaged in this approach, of course, should be the champion and the SAP Solution Manager functional administrator I discussed earlier.

ASAP methodology has been revamped in the last few years. From ASAP Implementation 3.5 on, there is a clear approach to the process. It starts as early as producing a scenario and process inventory in the Project Preparation phase and continues through the Business Blueprint phase. For more on ASAP, refer to https://service.sap.com/asap.

You can use Solution Maps and Solution Composer as support tools to define the scope of your project. They can be the basis for discussing specific business requirements and should support the gap analysis between what SAP provides as standard solutions for different processes and your company’s needs. For more information about Solution Maps and Solution Composer, go to https://service.sap.com/s-composer and https://service.sap.com/solutionmaps. They both help you improve communication with a common process language.

By combining an ASAP methodology and Solution Composer functionality, you can start working with a correctly defined, strong business model. You should establish clearly from the beginning that you are implementing a solution, not SAP modules. Therefore, you need to discuss which scenarios are part of the scope of that solution.

Ideally, you should define scenarios before the project starts. If you do this, you only need to update the scenario inventory as stated in the ASAP methodology in the Project Preparation phase. If you don’t define scenarios at that phase, then you can create an initial list using Solution Maps from Solution Composer. Select the right Solution Map. For example, you can select industry-specific map (e.g., the oil and gas industry) or cross-industry maps (e.g., the SAP Customer Relationship Management map). I prefer using the industry-specific solution map because it fits best to the company’s actual business, even if the implementation is only for standard SAP ERP functionality. You have a view of the value chain, scenarios, and groups of scenarios and this helps you better understand business processes. When you work with cross-industry solution maps, you may miss this view of scenarios.

After you have a list of the scenarios for your implementation, you can move to the Business Blueprint phase and continue to follow ASAP methodology. You can organize various workshops, starting with business scenarios and continuing with detailed business requirements. If you want to ensure that the process approach is considered, you should organize the project in functional teams assigned by specific scenarios and processes — not by SAP modules, which is still a very common approach. For example, in the workshops related to the purchase-to-pay scenario, you can pull together people with knowledge of logistics, accounts payable, and treasury processes so that they can take a look at the whole scenario and the processes that comprise that scenario. If you don’t use this strategy, you risk having a fragmented, vertical, and unconnected view of business processes.

You may need to overcome preconceived concepts in people who were trained in SAP modules and have experience organizing teams by module functionality. They sometimes do not see the advantage of switching to the process approach. If you set up the process approach from the very beginning, the company profits later on in many ways, such as:

• Easier integration testing definition during the project
• Easier setup of business process monitoring in SAP Solution Manager
• Easier integration with other testing tools, such as the SAP Quality Center by HP
• Preparation to move into the service-oriented architecture (SOA) approach

I cannot stress enough that communication with stakeholders during the project, including when you’re creating a process-oriented approach, is very important. Once you have identified the IT application management needs, the champion needs to communicate with and involve the mid-management level (e.g., project managers) so you can ensure that they will support the use of SAP Solution Manager. You want them to perceive it not as a burden, but as a tool that can clearly help them achieve their goals. There is a statement I use very often: “If you don’t find it in SAP Solution Manager, it does not exist.” A strong phrase like this to upper management, mid-management, and down to the team is crucial to the success of your SAP Solution Manager campaign. Success stories, experiences from other projects, and customer-to-customer talks are also important to convey. As a consultant, I find that my customers want reassurance not only from me but from outside sources, so you should have good references and examples at hand.

4. Set Up Project Standards

One of the most important tasks for deploying SAP Solution Manager in a company is to tie it to a methodology that will be used internally. You must create a set of standards, such as naming conventions, that ensures quality information is stored in SAP Solution Manager. The SAP Solution Manager functional administrator usually does this during initial setup, and it should be maintained over time.

Using SAP Solution Manager for projects means that your team will be creating and uploading information by the thousands. Naming conventions help identify different objects so they can be easily recognized, located, and referenced. The naming conventions should be kept the same in the future. If you are using a tool other than SAP Solution Manager (e.g., ARIS for SAP NetWeaver) for process design, a naming standard is still needed. The naming conventions apply to:

• Structure: Projects, scenarios, processes, steps, master data, and organizational units are created in transaction SOLAR01. A common naming convention is required. Avoid using technical names; use a hierarchical naming convention instead. A clear process approach is best, and the naming convention for the structure should be stable over time. An example of a process name is ORCA-000-000 - Order to Cash.
• Documents: One of SAP Solution Manager’s strongest functionalities is how it handles documentation. When organizing documentation, you need to think about two main types of documents: those related to solution documentation (documents related to the Business Blueprint and realization of the structure, such as scenarios, processes, and steps) and those related to the project or deliverable’s documentation. The first group should follow the same naming convention (i.e., prefix) used in the structure. For the second group, the document type is defined by the functional administrator. The naming convention should clearly identify the subject area (based on ASAP definitions), the sequence, and dates. For example, say that a project charter is produced and then you want to store in the roadmaps as a deliverable. A possible name would be Project XX – PM – Project Charter – V 1.1 – 200911. If you adjust the document, you can modify the version in the name to 1.2 so that you clearly identify the current version.
• Structure status: Statuses are used in different areas of SAP Solution Manager. It is important to identify the minimum meaningful status schema definition so you can produce effective project management and operational reporting. The status schema is used in the tabs of transaction SOLAR01 and transaction SOLAR02. You should coordinate with project managers on their needs for the structure status. For example, I used a set of statuses for the Realization phase in the Administration tab in transaction SOLAR02 (Table 1).

• Identification criteria: In the past, only naming and key words were available in SAP Solution Manager to help you classify and select the different structures (e.g., scenarios, processes, and steps). Now you are also able to implement new functionality using attributes. Analyzing reporting needs is the key goal for attribute definition. Starting with SAP Solution Manager 7.0 enhancement package 1, you can create your own set of attributes in the customizing of SAP Solution Manager. For example, say that you want to classify processes that belong only to a specific line of business. You can create your Line of business attribute with a table of the different values and assign them to each element in the business process structure. This helps in reporting processes for this attribute.

5. Train and Coach Users

Next, it’s essential to set up a strategy for training all the different people who are going to use it. SAP Solution Manager should become the everyday tool for the team to use. The planning, creation, and delivery of SAP Solution Manager training should be done by the champion and functional administrator. In many cases, it covers most of their SAP needs — so you need to show them that they can work with SAP Solution Manager to support their daily activities. There is a common tendency to rely on spreadsheets instead of a tool, so you must try to show the value of live reporting and timely access to important information.

In my experience, work done in the Project Preparation phase (e.g., setting up definitions and project standards) is key for the communication and training activities. You should deliver training and communication activities to the whole team at the beginning of the Business Blueprint phase. Later, you can provide configuration and testing training.

Each group uses SAP Solution Manager in different way, so you need to stress their specific user needs and benefits. For example, you can show team leaders that they can achieve improved and easier control over their work with reporting based on statuses. You can show developers that they can control the number of developments based on functional specs documents. You can show PMO employees the benefits of publishing meeting minutes in a common place.

To achieve familiarity with the tool, here is a list of the specific training that should be delivered:

• Project managers and team leaders: focus on document management functionality, status reporting, and issue management
• Functional teams (e.g., consultants, key users): focus on process modeling, document management functionality, the Business Blueprint, configuration, test preparation and execution, and assignment and status reporting
• Developer team: development documentation
• Auditing, process, and compliance teams: process modeling, reporting, and document management
• Testers: how to perform testing

The topics that need to be taught to the various groups according to their needs:

• Document management: How to create, upload, modify, link, share documents in the different structures. Also, the correct naming conventions and documents types to use in the projects.
• Roadmaps: Establish the structure level in the roadmap and the document type defined by deliverable type
• Process definition: How to create the business process structure (e.g., scenario, processes and steps, master data, and organizational units) and use of shortcuts, keywords, and attributes. This is similar to the roadmap (project deliverables) documentation.
• Blueprint generation: How to produce interim Business Blueprints
• Issue Management: How to deal with issues and messages during the project phases
• Reporting: How to generate reports for inventory and progress information on:
  • statuses based on the Administration tab and other tabs in transactions SOLAR01 and SOLAR02
  • documents from various tabs in transactions SOLAR01 and SOLAR02, including the Project Documentation, Configuration, Development, Test, and Training Materials tabs
  • object assignments (e.g., transactions, IMG entries, developments, and test cases)

The training should be delivered during certain different phases. Here is a suggestion of the phases in which you could train people:

• At the beginning of the Business Blueprint phase
• At the beginning of the Realization phase
• Before test plans are built
• Before execution of the different test plans

I advise that you ensure the company can support the training with e-learning materials, which are available through Learning Maps in SAP Solution Manager. Often, people get their hands into SAP Solution Manager long after its initial setup and you need to get them on board quickly.

After Training

The success of SAP Solution Manager relies on coaching, of which there are different types. An SAP Solution Manager expert must coach the champion and functional administrator. The expert also needs to communicate with management to ensure that they support the initiative during the project because the champion needs support.

In addition, the champion and functional administrator should provide coaching to the rest of the team. One of their main responsibilities is to ensure that SAP Solution Manager is used correctly in the organization. The people in these roles should be ready, visible, and available for the all the project teams whenever doubts or issues arise. Also, these roles require a proactive attitude — they should be reviewing information uploaded in the project, early identification of errors and inconsistencies, checking that the whole team is using the tool, and supporting them as they use it. The champion and functional administrator should consider it part of their job to produce SAP Solution Manager statistics, summaries, inventories, and reports.  

Standards that are closely tied to SAP Solution Manager adoption success are definition, communication, and use. The standards are vital not only during the initial project but over time. Ensure that documentation and structures remain up to date. It is key that you clearly state that quality is part of the project, and project managers and team leaders are responsible for enforcing it. Remind users that what they produce in SAP Solution Manager — such as documentation, references, and links — directly helps them support their SAP applications and will help others in the future do their work more efficiently.

Esteban Hartzstein

Esteban Hartzstein has a master of science degree in business administration, with a specialization in computer information systems, from Colorado State University and also holds the degree of Certified Public Accountant from Universidad de Buenos Aires. He is director and owner of Tebyon Consulting, a consulting firm dedicated to developing and implementing best practices for project management and IT operations while applying the latest methodologies, frameworks, and tools to support companies in improving their business processes and reducing total cost of ownership. Esteban has more than 25 years of experience in the IT field. In the last 13 years, he has worked in the SAP ecosystem in various roles in IT and consulting areas. He is a certified SAP ERP HCM consultant and solution manager.

You may contact the author at estebanh@tebyon.com.

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