Are you considering implementing additional functionality within Solution Manager? Do you want to understand how different features within SolMan can benefit your business? Or do you already understand the features but want to ensure you are prepared for their implementation?
The following is part two in BayForce’s series on Solution Manager and details specific issues and key steps to consider when implementing ChaRM.
Solution Manager Part II: ChaRM Revealed
SAP has been encouraging customers to use Solution Manager for quite a while now; somewhat subtly in the beginning by making this the only channel to acquire installation keys. Customers with impending installations or upgrades reluctantly raced to stand up minimal instances of Solution Manager for the sole purpose of obtaining these keys while the remaining customers ignored it. Initially Solution Manager was widely viewed as a nuisance, one more instance of SAP that needed to be supported.
These initial instances of Solution Manager were very basic installations that a competent Basis resource could install and configure within a few hours. They required little attention or interaction unless new installation or upgrade keys were needed. Solution Manger has evolved into a comprehensive set of tools that provide system performance monitoring, problem tracking, root cause analysis and change and transport management. This new functionality requires extensive configuration and can touch every instance within an enterprise.
If you’ve attended Sapphire or SAP TechEd in the last few years you’ve no doubt seen a presentation on Solution Manager. SAP advertises Solution Manger as an included component, sometimes leading customers to believe that to activate its vast functionality requires only basic configuration. This combined with the historic belief that Solution Manger is a simple system, requiring little effort to install, has misled many an executive or manager. This is compounded by Basis/Technical resources believing that having mastered the support of SAP prepares them for the new requirements of Solution Manager. While the basic installation of Solution Manger remains a relatively simple task for a technical resource, gone are the days of a 1 day installation and configuration of Solution Manager.
To appreciate this complexity it’s valuable to break down the components of Solution Manager and identify some of the common pitfalls and challenges many customers face. The first and largest challenge is the decision process. Questions such as what components will be activated, what problems will be reported, who will be notified, where will the server reside, will it be a discreet instance and will it function as a central or distributed manager of change and problem tracking. These decisions rest with the project management and/or executive sponsors of the project. The challenge is people don’t know what they don’t know. Until the functionality of Solution Manager is peeled back layer by layer, management not only doesn’t know the answers, they don’t even know there was a question to be answered. Progress is hindered until these questions can be answered.
I know how glamorous the SAP product presentations appear. Customers are almost convinced that 90% of the advertised functionality comes with the installation itself. This is not true at all. Each installation of SAP Solution Manager is a unique configuration based on specific customer needs. It’s not unlike configuring any other component of SAP. For proper project planning it could be compared to configuring FI, a fundamental component of SAP. Experienced project teams staffed with power users and supplemented by consulting partners spend months developing business process blue prints and migration plans. Careful consideration is made to plan cutover during a weekend. Integration and performance testing scenarios are planned and executed. Support for critical projects such as this must start from the top. Can you see how the perspective that Solution Manager is essentially a Basis component merely needing activation is harmful to proper budget and project planning?
SAP has provided a comprehensive, useful toolset that can function beautifully as the central system management console when properly implemented. However, Solution Manager provides functionality for several business functions, each with specific, unique challenges that must be considered. I’ve found that most clients are focusing on ChaRM as the primary component to implement, so the following provides some specific information and issues relating to this component.
ChaRM Misunderstandings & Technical Challenges Explained
A common misunderstanding is the belief that implementing ChaRM will provide a pre-defined workflow and change management process. It’s true that ChaRM will force customers to adhere to a plan and inherently provide consistency but that is accomplished by the customer providing the plan. If your transport management process is a mess today, it will be hard to adapt to ChaRM without first adopting a consistent plan. The first critical step will be to identify users who will create transports, manage transports, test transports and approve transports. These users can either be manually assigned at the creation of a transport, or based on pre-defined criteria, they can be automatically assigned. They must exist and be identified or ChaRM cannot function.
One of the benefits of ChaRM is that it will provide much more formidable structure to organize transports automatically using multiple factors that previously were performed manually or thru substantial custom development. To realize this robust functionality, however, customers must learn how to create and manage Solution Manager Projects thru maintenance cycles. Decisions will need to be made as to which transports move into what environments based on the project(s) they are assigned to. A well defined set of criteria must be in place to sort transports into categories of routine, emergency or standard maintenance and different processes must be established for each of these along with potentially different transport routes.
Once Solution Manager is properly understood and appropriately planned, then you finally begin experiencing, and can address the technical challenges. Following are several of the key steps and issues you should be aware of when implementing ChaRM.
There are many configuration steps to complete the activation of ChaRM. These start with 2 critical activities that are actually not part of SolMan and are common problems. First, the SAP SLD (System Landscape Directory) must be setup. This is the foundation that provides the entire system mapping to Solution Manager and ChaRM. Another critical SAP specific task is to establish the Transport Routes and consolidated Transport Routes for the environment.
Transport routes must be defined in STMS in order for Solution Manager / ChaRM to function. Many initial problems are related to the SAP configuration being incomplete or non-compliant with ChaRM.
Following SLD and transport route related issues as the most common trouble areas, problems caused by a flawed basic configuration of ChaRM run a close second. It’s important to verify that the configuration of ChaRM was completed correctly. This verification can be accomplished like other SAP components via the IMG using transaction SPRO.
Another significant step often overlooked is the creation of an RFC connection between the ChaRM client and client 000 in the Solution Manager instance. This can be accomplished with transaction SMSY. Because clients often move their transport domain controller from development to production once they’ve gone live, it is necessary to recreate the RFC connection to the new instance if this occurs.
Additionally, it is important to verify that ChaRM has been activated by confirming that the table BCOS_CUST contains the following entries.
This will confirm that ChaRM has been activated for specific clients.
The activation of the BC Set for ChaRM SOLMAN40_CHARM_BASICFUNC_001 must be completed and Extended Transport Control must be activated.
Verify that the domain controller has been properly created within transaction STMS.
To request a link between two transport domains, proceed as follows:
- Log on to one of the two domain controller systems, in SolMan system, for example:
- Call transaction STMS (always being in client 000)
- Choose Overview > Systems
The system overview appears.
Choose SAP System > Create > Domain link
The dialog box Request for Linking 2 Domains appears.
Enter system name, DEV for example, hostname where is installed the system and system number, all this information is in SM51 of the DEV system, if DEV system is the domain controller of your real landscape.
Your SAP System performs the following actions automatically:
- Generates the required RFC destinations
- Sends the address data of the controller to the controller in the other domain
Afterwards, you need to logon in the domain controller, client 000, of your real landscape and confirm the link between these two domains as follows:
- Log on to the domain controller in the other domain
- Call Transaction STMS in client 000
- Choose Overview >Systems. The system overview appears
- Position the cursor on the domain controller where you requested the domain link, DOMAIN_SMM in our example, and choose SAP System Approve
- Confirm the prompt and distribute the configuration
The two domain controllers now exchange all necessary information about the systems in their domains. This information is distributed to all systems in the domain whose controller you are currently logged on to. A transport profile is generated, which contains all systems in both domains.
You have to see something like this in your SolMan system (called SSM in this real example):
And this in the DEV system (called ED4 in this real example):
To check that the domain link is good, go into the SolMan system and in the development system to STMS->transport routes, in the top of the screen you will see that in the SolMan system, the systems belonging to the other transport domain appear like boxes and are the same if you go to STMS in the DEV system, the box of the SolMan system can be seen.
Another area where a lack of experience can lead to a number of frustrating problems and wasted time through trial and error is the creation of a “Project”. Projects are the fundamental mechanism for managing change in ChaRM. There are 2 types of projects– implementation and maintenance.
For reference to creating projects please click here.
- Select SAP Solution Manager 7.0
- Select Learning Map for Supp Organizations/Serv providers
- Open Change Request Management section and see the iTutor called “Create a Project”
The following screen shots will walk through the process of creating and activating a ChaRM maintenance project.
Under the System Landscape Tab:
Systems: the Logical component is entered
Take into account that all systems that belongs to the TMS landscape must be assigned to the same logical component because all systems must have the same product version except when upgrading.
This means that in the same logical component each system must be assigned a role; you can have a minimum of two systems for a ChaRM scenario but you can have, for example, 5 systems with different roles in your real landscape.
The following screen shot represents this example:
A problem that many customers struggle with when trying to create a project is the inability to activate ChaRM. This will happen when the landscape that is defined in Solution Manager doesn’t exactly match the landscape in STMS. Until these landscapes are consistent, ChaRM can not be activated.
Under the IMG project tab: define the project
ALWAYS define projects in the development system ONLY! The project must be defined in the development system so that it can be assigned to all transport orders that are created with a Change request in the SolMan system. This is an absolute requirement when using ChaRM.
See the above iTutor to see how to define this IMG project.
Don’t define IMG projects in other roles, systems, different from development.
Under the Change Request tab: Select “Activate Change Request Management”
Select Create Task List
Select the name of your Maintenance Cycle also called Project Cycle.
Note: Choose Lock/Unlock Group/Subsequent Groups to unlock the tasks in the task list.
If all is working correctly a Task List and a Maintenance transaction type SDMN (called Service Desk Transaction in the screenshot) is being created.
Service Desk Transaction Tab: shows the SDMN document for this project cycle.
The task list is one representative of the cycle and represents the system landscape tracks with tasks to be used by an IT operator for managing project related IT activities, especially imports.
The SDMN transaction represents the service request for managing the phase changes.
It is recommended that you activate and change the phase by executing transaction CRM_DNO_MONITOR using transaction type SDMN.
So, phase shifts should be done from within the cycle transaction SDMN but not from within the tasklist.
In the case of the Task list not being created, please run the Check (transaction /n/tmwflow/charmchk) or go to the Application Log via the button or calling SLG1 directly.
In both places you will get information as to why the Task List and the Maintenance Cycle is not being created.
These steps will help verify that SAP and Solution Manger / ChaRM have been correctly configured to support the features of ChaRM.
I hope you find this document helpful in understanding and implementing ChaRM. These are just some examples of common problems that are experienced by customers implementing ChaRM and not a comprehensive list. This document is also not a replacement for proper consulting help. It’s imperative to have not only an experienced technical resource, but one who’s specifically experienced with Solution Manger implementation and configuration. There is a reason that SAP has a specific certification program for Solution Manager.
If you would like assistance evaluating, implementing, or trouble-shooting your Solution Manager system, please contact us and we will be happy to set up a preliminary call to discuss.
About the Author
Ken Asher holds a Masters degree in Engineering, Mathematics, and Computer Science. He has over 17 years of SAP experience and has worked as an SAP America liaison to various clients to resolve critical architecture and solution issues throughout his career including during his time with Andersen Consulting/Accenture. Ken was also a member of SAP’s ATAC team for advanced technical application consulting. He has a deep understanding of SAP architecture and has worked with all of the latest SAP technologies. In many of his previous projects he has been responsible for reviewing and recommending strategy as well as project planning for SAP clients including GMAC, Raytheon, and MIT. Ken is currently deployed by BayForce to assist Amtrak with multiple ongoing projects including one of their largest initiatives for Strategic Asset Management.
To contact Mr. Asher or discuss how we can assist you with your upcoming projects, please call Kim Snow, Vice President of Delivery at BayForce, at 813-908-8593 or send an email to firstname.lastname@example.org.