Skip to Content

SAP Solution Manager Project Support: The end and the means (1/6)

SAP Solution Manager – Project Support


I have been working with clients on implementing what SAP calls Implementation Support, Implementation Content or Implementation Tools for a long time now. Since Solution Manager’s 15th Service Pack Stack the Solution Documentation tools were also added into the mix. The general consensus is that most clients are only partly aware of what Solution Manager offers in terms of project support and what the Solution Documentation tools are meant for.


A lot of clients had a lot of misconceptions about what Solution Manager’s Project Support application is intended for and what added value it brings. The Solution Documentation tools contributed to the confusion, as they largely depend on the Project Support tools to function and the two get mixed up.


This six part blog series will elaborate on the different features of Solution Manager’s Project Support and Solution Documentation applications. Hopefully the feature descriptions and use cases will get rid of some of the confusion and help you to effectively use the applications as they were intended and add the most value to your projects and documentation efforts.


Project Support – Four Features


I’m going to start with just Project Support and come back to Solution Documentation in later installments. The project support features can generally be divided into four applications:


  1. Project Administration
    The application to administer the general aspects of an SAP project, such as the delivery team, the system landscape, project standards and templates that are used in the other 3 applications, very basic planned versus actuals data and the context of the project in terms of, for example, whether FiCo or SD are going to be implemented. (Integration with another Solution Manager application, Change Request Management, is also controlled from here. This is a whole other ballgame and isn’t part of this series though.)
  2. Project Roadmaps
    A project management application to structure implementation, upgrade and change projects according to, for example, the ASAP methodology.
  3. Business Blueprint
    The application in which you design the business processes that are going to be implemented, upgraded or changed. Here you create the ‘to-be’ situation, mapping the business processes directly onto the systems they will need in order to run and the configuration that needs to be done in order for the business processes to function.
  4. Configuration
    The application through which you configure the business processes on the SAP systems[1] according to the design that was created in the Business Blueprint transaction and where you document the configuration.






The ‘linking pin’ between these 4 applications is application number 1, Project Administration. You create a project here, it receives a name or number of your choice and that becomes the unique identifier for your project in all four applications.


The end and the means


Why would you even consider using these four applications as a project tool when implementing, upgrading or changing business processes in SAP? The best way to explain that, is to provide you with the end-result of using the tool during a project and, later, during operations.


These applications are just a means to an end, as is any tool. Its objective is twofold, the first being to provide your operations organization (Competence Centre, Centre of Expertise, support organization, etc.) with a documented ‘current state’ of the system landscape in relation to the business processes running on it.


With this documented current state in hand, the operations organization can more easily determine the impact of maintenance changes. They can keep process configuration documentation and user training material up-to-date when maintenance changes are carried out and use the documented state in a host of other Solution Manager applications. Applications such as Job Scheduling and Documentation, Change Request Management, Test Management and Business Process Monitoring.


The second objective is that the next time a project is carried out, the project team can start out with this documented current state. All of the documentation, which we’ll look at a little bit further on, can be reused in future projects.


Single source of truth


Okay, I hear you thinking, I can do most of this with a Sharepoint site or a file structure on a network share. Right? Well, yes, I’d even go so far as to say that as far as plain document management goes, Solution Manager isn’t the most effective tool you could deploy. I’d certainly advise against end-users going anywhere near it…


The great advantage is that you build your current end-state using pre-delivered best practice content and the documentation goes a lot further than simple Word, Powerpoint and Excel files. Due to Solution Manager’s direct connection with the systems involved in the business processes, configuration information is derived from those systems directly.


So your documented current state actually consists of the IMG elements, programs, reports, user-exits, custom developments AND the Word, PowerPoint and Excel files describing them.


What you end up with in Solution Manager is what is called a ‘Solution’. Basically; a documented snapshot of your landscape as it is used by the business. A snapshot containing all the information relevant for operating, maintaining and improving or changing that landscape. All from a business process point of view, accessible by all parties who need it and re-usable in operations, projects and maintenance. What SAP refers to as the ‘single source of truth’.


The next part of the blog will cover the Project Administration application. 

[1] Note: it is possible to include non-SAP systems, but for the sake of clarity I will limit the explanations to SAP systems only.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.