Home
 > Research and Reports > TEC Blog > Demystifying SAP Solution Manager

Demystifying SAP Solution Manager

Written By: Predrag Jakovljevic
Published On: October 26 2011

This past decade has seen the advent of SAP Solution Manager, a unique offering for centralized support and system management. Needless to say, a typical SAP system landscape at global corporations may include a large number of SAP and non-SAP systems. “Complex” SAP environments (or heterogeneous IT landscapes) often comprise huge global corporations that use SAP ERP worldwide, with different divisions possibly using different releases of the product (which is a nightmare to manage in a manual or semi-automated manner). Add to that some third-party enterprise resource planning (ERP) systems in a so-called "two-tier ERP" scenario for remote divisions and plants (e.g., Microsoft Dynamics AX, SAP Business One, SYSPRO, Epicor, QAD, etc.) and third-party best-of-breed solutions, many of which are endorsed and even resold by SAP (e.g., SmartOps, Llamasoft, Vendavo, etc., in the supply chain management [SCM] realm), and the word “complexity” quickly becomes an understatement.

How can any ordinary mortal manage all that data and processes (both in a live system operation and during migrations to newer releases) without some systematic help? To that end, SAP Solution Manager tries to reduce and centralize the management of these diverse systems. In such a landscape, SAP Solution Manager (a.k.a., SolMan) is the managing system (the “brain,” if you will), and the SAP Business Suite applications, such as SAP ERP, SAP CRM, SAP PLM, SAP BI, SAP SCM, etc., are the managed systems (the individual “organs”).

 

What Does SolMan Actually Do?
Solution Manager is a set of tools for both functional and technical purposes. The technical aspect refers to the real-time monitoring, support, and maintenance (e.g., patches, support requests and related notes, etc.) of the entire IT landscape, regardless of the number of managed systems. For their part, functional tools serve to maintain a repository of documents and various SAP objects, and to provide centralized control for all phases of an implementation project. In addition, Solution Manager is a tool for the day-to-day management of any project within an SAP system. On a higher level, Solution Manager should perform the following functions:

  • Document repository: a single place to keep requirements descriptions, technical specifications, and other Microsoft Word or Adobe PDF documents.
  • Help desk: a tool that allows one to open a case, follow its status, insert a relevant documentation, close the case (one resolved), etc. This exceptions handling tool guides SAP’s staff and users in defining a model and the procedures necessary to efficiently manage exceptional situations and errors that occur during daily business operations.
  • Transport: refers to the migration of the system configuration and development objects from one SAP system to another: for example, from a development system (“client” in SAP’s lingo) to a testing system; from a testing system to a production (live) system, etc.
  • Security administration: allows users to determine who in the organization will have what kind of a profile, i.e., which transaction he/she can access in a “create/change” mode versus those in only a “display/view” mode.
  • Status reporting: on all of the above, including documentation, help desk cases, profiles, etc., (generally speaking, this is the most used function of SolMan).

The product can also help with the following:

  • Ascertain both the technical and organizational readiness for enterprise service–oriented architecture (eSOA).
  • Enable the remote supportability of customer solutions.
  • Monitor business processes and interfaces, and supervise mission-critical business processes.
  • Support data integrity to avoid data inconsistencies in end-to-end solution landscapes.
  • Manage large volumes of data to support inevitable data growth.
  • Manage the planning, scheduling, and monitoring of background jobs.
  • Provide transactional consistency to safeguard data synchronization across applications in distributed system landscapes.

SolMan supports the following 13 processes for application lifecycle management (ALM) for both projects and solutions (business configuration and business continuity) throughout the entire lifecycle:

  1. Solution Documentation—Maintains a central repository of documents and relates the business processes and technical information from SAP and non-SAP solutions to ensure transparency, efficient maintenance, and collaboration.
  2. Solution Implementation—Involves the identification, adaptation, and implementation of new and enhanced future-proof business and technical scenarios. This process involves decoupling technical installation from the innovative aspect of business systems, and uses SAP Solution Manager to implement innovative solutions within the system landscape.
  3. Template Management—Allows customers with multisite SAP installations to efficiently manage their business processes across geographical areas, such as part of a global rollout approach: from initial template definition to template implementation and template optimization.
  4. Test Management—Defines the integration testing requirements and test scope based on a change impact analysis. It is used to develop automatic and manual test cases, manage the testers, and report on the progress and the results of the tests.
  5. Change Control Management—Provides workflow-based management of business- and technology-driven solution improvement changes with integrated project management, quality management, and synchronized deployment capabilities to best manage the risks associated with the implementation of the solution, therefore ensuring technical and functional robustness. Change Control Management covers the deployment and the analysis of software and configuration changes.
  6. Application Incident Management—Enables centralized and common incident and issue message processing on multiple organizational levels, and offers a communication channel with all relevant stakeholders of an incident. The process includes a business user, SAP experts at the customer site, and SAP Service & Support and Partner Support employees. The process is integrated in all ALM processes of the SAP Solution Manager and in any SAP Business Suite solution. It can be connected to a non-SAP help desk application. It includes follow-up activities, such as knowledge research, root cause analysis, or change management—all end-to-end across different support levels and different technologies.
  7. Technical Operations—Represents all capabilities for monitoring, alerting, analysis, and administration of SAP solutions, and allows customers to reduce total cost of ownership (TCO) by predefined content and centralized tools for all aspects of SAP Solution Manager operations. It provides end-to-end reporting functionality either out of the box, or individually created by customers.
  8. System Administration—Describes how to administer SAP technology in order to run a customer solution efficiently. System Monitoring covers monitoring and reporting of the technical status of IT solutions.
  9. Business Process Operations—Comprise the most important application-related operations necessary to ensure the smooth and reliable flow of the core business processes to meet a company's business requirements.
  10. Maintenance Management—Covers software correction packages, from discovery and retrieval to test scope optimization, possibly including optional automatic deployment into the production environment.
  11. Landscape Transformation (LT)—Bundles software and services to address transformation scenarios in a holistic way. The first release of SAP LT software already covers a number of solutions to support the execution of transformation projects. In addition, SAP LT contains complementing service offerings of the System Landscape Optimization (SLO) group to support various additional requirements in transformation projects. Product functionality is expected to evolve with future releases.
  12. Custom Code Management—The innovative concept of Custom Code Management from SAP provides comprehensive insight into how companies can efficiently and effectively manage their homegrown custom code.
  13. Upgrade Management—Represents the identification, adaptation, and implementation of new and enhanced business and technical scenarios, and SAP Solution Manager comprehensively and effectively manages the upgrade of a project end-to-end. It allows SAP customers to better understand and manage the major technical risks and challenges with an upgrade project, and to make the upgrade project a “non-event” for the business.

 

The (Real) Need for Solution Manager
Solution Manager has naturally evolved during its more than a decade of history. The product was originally conceived to provide support with SAP solutions to customers with more than one system (e.g., for monitoring multiple systems). It was later merged with the AcceleratedSAP (ASAP) implementation tools to create a solution for complete application lifecycle management. Today, Solution Manager supports technical personnel (e.g., in technical operations), quality managers (e.g., in system testing), project teams and managers (e.g., in implementation), process managers & business experts (e.g., in business monitoring & analytics), the project management office (PMO) team (e.g., in portfolio and project management), support teams (e.g., in ticketing and root cause analysis), and IT management (with dashboards).

The latest NetWeaver release (SolMan is one component of NetWeaver after all) can handle all the different versions of SAP products, given that all these products are now compatible—as long as NetWeaver is the platform. Moreover, the NetWeaver Process Integration (PI) component provides communication with non-SAP systems within a diverse system landscape. 

SAP Standard customers are allowed to use SolMan with a basic scope (most of the functionality described in this article). SAP’s customers on Enterprise Support (ES) are entitled to the full scope of the product, with additional functionality for Custom Development Management Cockpit, Business Process Change Analyzer, and Quality Gate Management. Moreover, SolMan is not only limited to SAP components, but also comprises the full customer solution (meaning all IT components as documented in the solution documentation in SAP Solution Manager).

 

Clarifying Standard and Enterprise Support Benefits
SAP Enterprise Support includes everything in standard support plus several advanced elements such as a Service Level Agreement (SLA) with corrective action commitment, access to Solution Architect services, and the full use of Solution Manager for both SAP and non-SAP solutions. It also includes access to SAP’s 24x7 support advisory center and full access to SAP Support Academy, which also includes Expert Guided Implementation and Guided Self Services. It has very robust portfolio of services called continuous quality checks that can be leveraged during implementation projects, and productive operations. Access to SAP’s online service communities, documentation, and support portal is also provided along with bug fixes, product/technology updates, and legal changes (if applicable).
 
As said earlier, SAP Solution Manager is SAP’s platform for ALM that enables customers to manage their entire SAP solution landscape and further increases the value realized with SAP Enterprise Support. All SAP Enterprise Support customers are entitled to use SAP Solution Manger and all of its functionality, for application lifecycle management to support both projects and solutions (Business Configuration and Business Continuity) throughout the entire life cycle. An example of this would be SAP’s Business Process Change Analyzer, which helps customer reduce costs associated with regression testing.
 
Additionally, SAP Enterprise Support customers can use SAP Solution Manager for their full customer solution, meaning all IT components (both SAP and non-SAP), which are used in connection with the SAP business processes and documented in their solution documentation. For example, a customer could use the IT Service Desk application included with SAP Solution Manager as a general IT ticketing tool (without any additional licensing fees) to support a business process that uses mobile devices to enter orders, SAP CRM and SAP ERP to process them, a third-party database to save the data, and printers to print delivery notes. Figure 1 and figure 2 provide further details on what Solution Manager capabilities a customer is entitled to with Enterprise Support.


Figure 1

Figure 2

SAP Standard Support will include basic support elements, such as problem resolution (but with no SLA), bug fixes, product/technology updates, and legal changes (if applicable). From a service perspective, it includes two basic health checks. One is intended to be used during an implementation project (Go Live), the other is delivered in a post go live environment. Access to SAP’s online service communities, documentation, and support portal is also provided.

It is important to note that for Standard Support customers, Solution Manager usage is restricted to SAP components only. Not all SAP Solution Manager functionalities are available to Standard Support customers either. There are certain ALM and Run SAP functionalities that cannot be used by SAP Standard Support Customers. They can be summarized into the following:

  • Custom Development Management Cockpit
  • Business Process Change Analyzer
  • Quality Gate Management
  • Management dashboards
  • Test Automation Framework
  • Updated/Enhanced Business Process Documentation Capabilities
  • Updated/Enhanced System Monitoring Capabilities (Both technical and business process based)

Figure 3 provides further details on capabilities a SAP customer is entitled to with Standard Support.

Figure 3.

 

The (Plain English) Need for Solution Manager
Any seasoned SAP implementer can tell you why SolMan is often needed by any company using multiple SAP systems. Namely, one should never forget that any given SAP system could have multiple instances, which might mean that different SAP versions of the software are used by different departments in the company—but that is becoming less and less of a reality these days (mainly due to migration to NetWeaver). More often than not, though, SAP instances refer to multiple SAP systems within one user company, such as the following:

  • A sandbox system—where, as the name suggests, any user can play and mess around with the system (enter and delete dummy data, change configuration, etc.) without any controls (the idea behind this system is exactly that: for users to get acquainted with the system without any major consequences). Smaller companies might have one or at most two sandboxes that are hardware-wise about a one third of the size and power of the production system. Larger companies (e.g., Siemens and Caterpillar) can have up to eight sandboxes, some of which are equal in size to their production counterparts.
  • A development system (a.k.a., “dev”)—where the power users conduct the system configuration and development. This instance usually has multiple sub-instances, most often the “golden client” sub-instance that holds the copy(ies) of the system configuration, in case something goes wrong with the dev instance. As is the case with the aforementioned sandbox instance, the larger the company and its IT budget, the larger the likelihood that it has multiple dev sub-instances for various purposes and scenarios.
  • A quality assurance (QA) system (a.k.a., “quality”)—where power users perform system testing. This instance occasionally (but in a strictly controlled manner) gets refreshed with the data from the production (live) system. This instance might often have several sub-instances (or SAP “clients” in SAP’s lingo) such as the following: quality for upgrade, quality for new business improvement, quality for volume testing, quality for pre-staging (for loading a huge amount of data before the live system is updated, as an additional testing step), and so on and so forth. Generally speaking, QA is the last instance before the live system.
  • A production (live) system—as its name suggests, this instance is used in the company’s daily operations with ongoing data and transactions. In terms of hardware, the live system can span several physical servers, depending on how much flexibility the user company can afford, but in terms of business logic, the production instance should have only one SAP client (sub-instance) per se. I am aware only of Siemens having two live instances, but with a bunch of accompanying issues with synching up the data and transactions between the two systems on the daily basis. I am not sure whether the “one can never be too careful” attitude (and thus let’s have two live systems just in case one goes down) has been worth the additional effort and pain. 

When the live SAP systems are being configured functionally, the work starts in the dev instance, which gets transported to the QA instance, whereby, after successful and thorough testing, everything gets transported to the live instance. A similar route is followed in the development environment (i.e., all supporting Advanced Business Application Programming [ABAP] and Java programs). Even a relatively small company that has, say, only three SAP servers for keeping all of these instances and systems might get entangled when trying to manage all of the programs and configuration requests. It quickly becomes difficult to know exactly where something is, which version of which program is in what instance and why, which modules have passed the testing versus which need more work, and so on and so forth.

 

How It Used to Be Done
Imagine now an environment in a larger company, or even the largest global corporations, where these tasks become a mission impossible of a sort without some astute toolset to manage them all. This is the reason why SAP had to invent Solution Manager. Prior to SolMan, this kind of administration was done manually (on paper) or with the help of Microsoft Excel, which was both cumbersome and error-prone (imagine what would happen if someone were to record some wrong info or worse yet, delete something critically important). 

Needless to say, every company had its own system of administration, and as SAP grew, as did the number of users within these companies (which would translate into more requests for development, configuration, etc.), it eventually realized the need to come up with something that would facilitate the effort of all constituencies. SAP therefore offers Solution Manager free of charge to customers on active maintenance contracts, which is only fair. So, as SAP ERP systems had become so complex in order to support the needs of many companies and industries, SAP had to give something away for free (especially if it is only to ease the complexity that it had created in the first place).

SolMan is indisputably useful in managing the large volume of documents that come from the configuration and development of SAP systems. Indeed, one needs to document the following: the people that have ever initiated a request for a new configuration, the business case that justifies that request, the specification about what needs to be done, the required approvals and signatures, the test case, the user reference manual (once the configuration is finalized), the user acceptance, testing, and you name any other possible document. Solution Manager has added useful functionality for managing all this paperwork, including all necessary governance, version, and history management.

Some pharmaceutical companies, for example, have entire departments comprising staff that only work on SolMan-generated documentation: what must be approved, how and by whom, where it should be held (electronically and/or physically), procedures, processes . . . you get the drift. This is all the more pertinent, as Sarbanes-Oxley Act of 2002 (SOX) public companies are bound by the law to produce documentation upon request.

 

Who Is Really Using SolMan?
At the recent SAP TechEd 2011 event in September, SAP released SAP Solution Manager 7.1, which provides an overhauled and much easier to use interface (UI) along with several new functionalities, such as the following:

  • New monitoring and alerting infrastructure for the whole solution (both SAP and non-SAP applications)
  • Enhanced openness and integration with third-party products such as IBM Rational for Test Management
  • A way to automatically document existing business processes so now Business Process documentation is easily kept up to date


Solution Manager covers the following major SAP platforms: NetWeaver (which includes SAP Business Suite, SAP All-in-One solutions, and SAP Business ByDesign), Business Objects, Sybase, and HANA in-memory applications. The only exception is SAP Business One, which is used by a very small number of customers in comparison, and is therefore serviced via the SAP Service Marketplace. Given the scope as well as the significant evolution of SolMan since its inception over a decade ago (see the latest enhancements of the Solution Manager 7.1 release in figure 4), one may wonder how many SAP customers are really leveraging the solution.


Figure 4

According to SAP, today more than 70 percent of all SAP customers are using SAP Solution Manager, with more than 25,000 productive SAP systems managed overall. The vendor is seeing a constant rise in the adoption of SAP Solution Manager, which is provided as part of an SAP support agreement.

Perhaps a better question would be: How many SAP customers are using what percentage of SolMan’s entire scope? After all, all of the aforementioned SolMan functions are stand-alone, and can be used, but do not necessarily have to be used. To be precise, with the Solution Manager 7 version, all SAP customers are required to create support tickets via the tool, as SAP’s Active Global Support (AGS) staff uses SolMan to deliver support packages and corrections (patches) both externally (to clients) and internally (within SAP). In addition, both customers and SAP staff have direct access to Solution Manager 7 Release Notes. Thus, 100 percent of this support and reporting functionality is likely to be used.

Smaller companies will most likely use the system transport function and will often neglect the documentation function (or just use it for the most basic documents, e.g., request and specification sheets). On the other hand, larger corporations, which are bound by laws and regulations (anyone heard of the US Food and Drug Administration [FDA]?) and/or have internal needs for their own control will leverage much more SolMan functionality. One should never forget the not-so-evident cost issues: while SolMan comes from SAP free of charge, a company may need to employ an army of folks that will execute all the SolMan processes, maintain its hefty documentation, etc., which requires much deeper corporate pockets.

SAP candidly cites the following main reasons why companies are not using the tool to its full extent:

  • Some capabilities take more time to adopt (e.g., change request management) because they require a full customer project.
  • Functional deficits in SAP Solution Manager 7 (e.g., low support for management of non-SAP applications) have made it difficult for customers to adopt SAP Solution Manager as their standard management solution. These deficits have been eradicated in SAP Solution Manager 7.1
  • Many customers have not had sufficient support from SAP to warrant adopting SAP Solution Manager. SAP is therefore now providing a roadmap, knowledge transfer, and technical services for SAP Solution Manager.

 

Some Wishful Thinking
While SAP is seeing a constant adoption of more SolMan scenarios in its customer base, there has not been that much traction for Roadmaps. Roadmaps are part of the SAP Solution Manager that contain the standard SAP implementation methodology and cover the most important aspects and phases of an SAP implementation (best practices, project management, solution maps, etc.). Roadmaps provide links to accelerators and tools, which perform project tasks.

Alas, users do not deem these as necessary tools that also happen to be complex to use. SAP has been trying to persuade users to link ARIS process maps in SolMan (IDS Scheer’s renowned ARIS tool is embedded in NetWeaver for visual process modeling capabilities) to existing SAP Business Suite sessions and transactions. In theory this all sounds attractive: users can create an ARIS process map for, say, the procure-to-pay cycle with all the process steps, whereby all the diagram blocks are logically linked to the respective SAP ERP transactions. When an end user clicks on the diagram’s block, it invokes a particular SAP screen—impressive, you say?

Well, not that much is used in practice in the real life of end users. Even during the implementation, we are talking about an early stage of creating process maps (blueprinting), in which case users do not really care about linking to transactions yet (if they don’t know how the process will look in its final stage). But when the process is decided upon and finalized, end users do not really care about the map, but rather about creating concrete user instructions (including shortkeys, “favorites,” etc.), which can often be changed as time goes by. Handling all of these process variations via SolMan (and ARIS maps) incurs lots of unnecessary maintenance work. Even if the largest companies can offshore their documentation handling to lower-cost regions, they do not appreciate the unnecessary extra work and costs, even if not too exorbitant.

The trouble is also in the mindset and attitudes of folks. Larger corporations that have large budgets to afford an SAP implementation will rather pay a renowned consulting company to sit down with their staff and do the process blueprints the way they want (and not necessarily they way SAP is suggesting via some packaged process maps). On the other hand, smaller companies expect a turnkey project delivery (i.e., buy a package, install, and, voilà—it works à la Microsoft Office or Apple iPad!) and do not care to go through a bunch of agonizing questions and decisions such as “Do we want an automatic or semi-automatic vendor evaluation?” or “How often do we want to do a full materials requirements plan (MRP) run?” The sad truth is that many companies have no idea about what these questions mean and on the ramifications of their answers and decisions.

In other words, Solution Manager’s ability to generate the required project documentation, do a system pre-configuration, and generate system testing recommendations (based on users’ answers to provided implementation questionnaires) often fails to impress clueless users. Large corporations are skeptical about the packaged and automated approach, as they often want to do it their “outside the box” way (especially if they can afford that “pleasure”). For their part, smaller companies get deterred by the immense effort required to read all the manuals and evaluate their configuration parameters, especially if they had been under the impression that the system would just work in a turnkey manner. After all, why on earth did they just fork out a million bucks or so when they need to spend several weeks or months slogging away to get the thing to work?

 

Blessing and Curse of SolMan’s Uniqueness
As discussed in ZDNet’s blog post, SolMan is most frequently used for central administration, including user security maintenance (besides the aforementioned status report capability). SolMan becomes a gateway for central access to all the systems in the IT landscape that need to be administered. The product has been evolving at such a rapid pace that this article might even become outdated at the time of publication.

On one hand, given SAP’s notable effort and investment, SolMan can be regarded as an IT marvel, especially since no other vendor’s product covers all the functionality of SolMan. Most ERP products come with some implementation methodology with catchy names (QuickStep, SureStep, Accelerated Something, etc.). Some products have strong configuration management (e.g., Infor ERP SyteLine) and some have process modeling capabilities, such as QAD, Sage ERP X3, and Infor ERP LN (former Baan with Dynamic Enterprise Modeler [DEM]). Oracle has its own largely ERP agnostic Enterprise System Manager offering. TEC’s recent blog post talks about Epicor and SYSPRO dealing even with the realm of enterprise architecture (EA), but none of these vendors offer integrated testing or other sophisticated tools that SolMan offers.

Moreover, many products on the market for data center management have some similar functionality to SolMan. Many such products help software companies track what functionality their customers are using and enable their support staff to look at the installation in some form or another (e.g., the Sage Advisor, see the blog post). And many companies manage updates via a software package installed at the customer site (i.e., customers can download updates only if they go through this package).

On the other hand, SolMan can ironically be regarded as a testament to complexity and what has gone wrong in enterprise applications of a few decades ago (the mainframe and client-server/4GL era). Some might claim that the dearth of real competition for this package stems from its inability to provide meaningful information and value to a company. Indeed, the use of SolMan requires much effort and unintended costs to customers. SolMan is thus perceived by some as a necessary evil and SAP’s reaction to curbing complexity.

To be fair, during the era that preceded the current service-oriented architecture (SOA), cloud, social, mobility, and virtualization technologies, no small software vendor with a few hundred developers could have ever met the exacting requirements of Fortune 500 multinational corporations with more than 100,000 employees the way SAP has done (even if with complexity as a byproduct). Salesforce.com, Workday, and UNIT4 can talk nowadays about their successful implementations with post-implementation agility at large global corporations with no need to control which customer is on which product release (after all, they are all on the latest one in multitenant public clouds). But these vendors only cover a fraction of SAP Business Suite’s functional scope, and are departmental rather than enterprise-wide solutions.

At the end of the day, if and when enough investment is made by customers, Solution Manager proves to be a useful tool that eases the customer pain of daily system management. But many customers have yet to understand the solution in full, and the onus is on SAP to continue this education, perhaps by explaining how the giant’s staff uses it both internally and externally.

 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.