Document Your SAP Systems with SAP Solution Manager Tools: Q&A with Heiko Hecht on Using RBPD/SDA in 7.1

May 13, 2014

Heiko HechtSAP Solution Manager 7.1 offers new content and  improved functionality to document your next SAP project, providing a snapshot of the applications and business processes in your SAP systems.

Heiko Hecht, President, IBIS America and speaker at SAPinsider's Project Management 2014 event, took reader questions in our online Q&A on effective SAP system documentation, blueprinting, and tools options, including SDA, RBPD, Solution Documentation/Business Blueprint, and Scope and Effort Analyzer (SEA).

Review the chat replay and edited transcript here.


Bridget Kotelly, Admin 2014: Thanks for joining us for today’s online Q&A on SAP Solution Manager 7.1 for system monitoring. 

Today I’m joined by Heiko Hecht of IBIS America, who will share his experiences and expertise on SAP Solution Manager 7.1 for solution documentation.  Heiko is responsible for IBIS America’s collaboration with SAP AG on Reverse Business Process Documentation (RBPD) content and Solution Documentation Assistant (SDA) content for SAP Solution Manager 7.1.

We’re pleased to have Heiko here to take your questions on SolMan 7.1 tool options and its role as a project tool.

Heiko Hecht, IBIS America: Thank you very much for joining our Q&A session today! I'm very excited taking a look at your questions today.

Bridget Kotelly: Before we get started, I wanted to ask first about the tools for solution documentation with Solution Manager 7.1. There are certainly more options now for getting a view into your SAP systems. How is solution documentation different with 7.1 than it was in previous SolMan releases?

Heiko Hecht: SAP introduces a couple of changes with the introduction of SAP Solution Manager 7.1 in August 2011 and afterwards.

One change I'm really excited about is the introduction of the Reverse Business Process Documentation (RBPD) Content. Prior to SAP Solution Manager 7.1, the key focus was on the usage of technical objects like transactions and programs. Now it is possible to take a more detailed look behind the scenes.

 SAP and IBIS developed a lot more content to document your solution, including checks to analyze table entries, and we improved the business process repository (BPR) by adding more transactions, programs and also more details and processes/process steps. There were also some technical enhancements, such as being able to analyze 14 months and to cover Web Dynpros, etc.

Usage Procedure Logging (UPL) and Scope and Effort Analyzer (SEA) added also additional capabilities.

Bridget Kotelly: For those unfamiliar with RBPD, SDA, SEA, and UPL can you quickly define those?

Heiko Hecht: Absolutely!

Let's start with SDA. Solution Documentation Assistant (SDA) is SAP's approach to analyze your SAP systems automatically with SAP Solution Manager. SDA is also the tool which is used document your SAP system and it was already available in SAP Solution Manager 7.0. With SAP Solution Manager 7.1, SAP introduced its collaboration with IBIS Prof. Thome AG and offers now also selected SQL checks to identify process usage besides transactional checks verifying the use of transactions and programs.  

Reverse Business Process Documentation (RBPD) allows you to re-document your business processes in SAP Solution Manager. The re-documentation is done by analyzing the actual usage of the system and is supported by analysis content (RBPD content) for selected systems, industry solutions and topics pre-delivered from SAP in collaboration with IBIS Prof. Thome AG.

Usage and Procedure Logging (UPL) is a functionality available in ABAP-based system with SAP NetWeaver 7.01 SP10 or higher. It will be used to log called and executed ABAP units (procedures) like programs, function modules, methods and subroutines. It is a new log file but doesn't replace the workload statistics (ST03N).

And lastly SEA: The Scope and Effort Analyzer allows you to estimate the development and test effort for planned EHP (Enhancement Package) or SP (Support Package) maintenance projects. It is available with SAP Solution Manager SP11 and performs an impact analysis. It requires a business blueprint to determine the test effort and to create an effort estimate. It can create a technical business blueprint or reuse existing business blueprints.

Comment From Guest:  What are new vs. old features for documenting our systems in Solution Manager 7.1?

Heiko Hecht:  Solution Manager 7.0 already introduced Solution Documentation Assistant. As indicated it was primarily focuses on the use of technical objects, which gave you a very rough-cut business blueprint. SolMan 7.1 now can utilize the RBPD content, which helps you to get a more detailed Business Blueprint/Solution Documentation and, even more importantly, the chance to keep it up-to-date more easily.

SAP also introduced an option for uploading content via MS Excel,  there is the Scope and Effort Analyzer, which can create a technical Business Blueprint, and of course third-party tools and content.


Comment From Guest: What is the Scope and Effort Analyzer?

Heiko Hecht: I'll repeat the quick summary and then elaborate a little bit on this:

The Scope and Effort Analyzer allows you to estimate the development and test effort for planned EHP (Enhancement Package) or SP (Support Package) maintenance projects. It is available with SAP Solution Manager SP11 and performs an impact analysis. It requires a business blueprint to determine the test effort and to create an effort estimate. It can create a technical business blueprint or reuse existing business blueprints.

For companies that don't have a business blueprint at all and people who don't want to use SAP's BPR or other more process-oriented structures, SEA offers a structure based on SAP's Application Component Hierarchy. Very technical, it exists almost forever in your SAP system. It can be used, but it really depends on what you are trying to accomplish, e.g. who is your audience. Some challenges remain:

 1. How do you keep that structure up to date? (E.g. there is no RBPD content assigned to the application component structure, it is only evaluate by the use of technical objects)

2. Is it detailed enough? (For example, it does not include any RBPD content, technical information only)

3. Where do you assign your customization?  (Several packages  - formerly known as development classes -  and their corresponding transactions/programs are not assigned to the application component and you custom packages and transactions/programs are not assigned in the application component to the correct areas.)

Comment From Guest: We use SolMan to document projects that are not related to the SAP landscape. So we use the General Change for these, yet it still asks for an ibase and component. If the systems we are documenting are not linked to SAP, is there a way to eliminate the need for an ibase and component for the GC? 

Heiko Hecht: Unfortunately you will need a logical component for non-SAP systems as well. This might be painful now, but you can document your interfaces that way with more detail, which can enhance the quality of your solution documentation.

Comment From Guest: We want to use SDA to validate that we haven't missed documenting any key business processes. But how do you account for t-codes used by Basis or security, for example, that aren't part of a business process? Should these all be added to the blueprint?

Heiko Hecht: We typically add those technical transactions and programs as well. There is actually content for SAP NetWeaver via RBPD, and IBIS has assigned lots of those technical transactions, customizing, etc. Clearly Basis/security doesn't need to be an end-to-end process, but rather than stumbling over those transactions each and every time, we recommend assigning them in a separate area.  

Comment From Guest: Can you expand on the business blueprint requirements? What level of detail is required? Thanks. 

Heiko Hecht: There might not be an answer which satisfies everybody and every application, but in general, people don't document to have documentation. They want to support an upgrade, testing, etc.

For testing purposes, it makes sense to have a lot of detail, and it probably make sense to document on a process step level to support automated testing, etc.

SolMan offers some nice features like transaction variants, so you might not need to duplicate processes/process steps for process variants. There are links available that are helpful to find a compromise between being so detailed that you can't keep it up to date and not being detailed enough.


Comment From Guest: Heiko, So the blueprinting assists in creating the testing scenarios?

Heiko Hecht: Yes, that is a possibility I would like to recommend. Set up SAP Solution Manager, build the business blueprint, and then integrate it into your testing tools. Some organizations already have testing scripts or a testing structure. Those can be reused as well. SAP SolMan also offers several test options.

While you build your business blueprint, you probably will learn so much more about your system. You can identify users, processes and process variants with the supplementary services and it will help you to validate your testing structure/test cases and add additional content.

Comment From Perla Silva: Could the documentation in SolMan be used to document processes in SAP GRC?

Heiko Hecht: I would like to do some research on this but I'm not aware of a direct integration between SolMan and SAP GRC. SAP SolMan doesn't go down to the user level - e.g. we know that a transaction has been used, how often it has been used and you can get some monthly statistics, but there are not more details.

There is some content for Security/Basis in RBPD and we typically assign custom objects there as well for our customers.

SAP defined supplementary services for SAP Solution Manager and one of them specifically looks at User, Roles, etc.

Comment From Tom Tearpock: The new SEA seems to need NW EHP 1 (701) to be used. Is that the case for the other new BP features for Solman 7.1?

Heiko Hecht: The RBPD content already worked very well with SP04/SP05 of SAP Solution Manager 7.1. For example, I don't think SAP NetWeaver EHP 1 (701) was needed. Most of our customers are on SolMan SP09 or higher.

Comment From Tom Tearpock: Clarification: The managed system seems to need NW 701 for SEA to work. Do all the new SOL tools need minimum level on managed systems?

Heiko Hecht: Yes, there are certain requirements for the managed systems as well. Collective Note 1639050 gives you a nice overview of what's needed.

Comment From Guest: Can you talk more about Scope and Effort Analyser (SEA) and what are the prerequisites to run that?

Heiko Hecht: The Scope and Effort Analyzer requires its own setup and some authorization. It can be used to build a (technical) business blueprint structure or reuse an existing one. It conducts an impact analysis. It utilizes the semi-dynamic creation of TBOM's and utilizes UPL information.

Comment From Guest: Do you have a suggested best practice/strategy for how the functional analyst/module lead can use Solution Manager to document a new project in cases where the organization has never really used Solution Manager for that purpose before? Solution Manager is currently only used by the Basis team as a tool during annual support pack projects. What's the best approach for the BA to jump in and start using Solution Manager? Or is formal training first the best approach? 

Heiko Hecht: As it is true for most (IT) projects, it is very hard or impossible to manage a project without help. Based on my experience, we always recommend some training upfront. It doesn't need to be extensive and it shouldn't be too technical in the beginning. Gaining business/end-user support is the key in the beginning.

If you try to jump into SolMan you will get many questions and need to overcome some reservations. Let someone show them the full picture – “this is where we want to be” - and don't focus initially on how to get there.


Comment From shiva: What is the major use of this RBPD/SDA?

Heiko Hecht: That is a key question! Why do I need solution documentation?

SAP tried to address key pain points with SAP Solution Manager and with their ALM approach. It is not done by running a couple of tools and running SAP Solution Manager; there is more behind it.

Most of our contacts try to reduce their effort for release upgrades, EHP's etc. There is always testing involved in those projects. So instead of testing everything, maybe we can have a more focused approach, for example, by only testing what's impacted or with risk-based testing. Impact Analysis or BPCA are the key terms here.

RBPD and SDA help with solution documentation. You shouldn't change your SAP system if you don't have a good documentation to begin with. It helps with project management and eventually with organizational change management: Who do we need to involve, train, and educate? What needs to be tested?     

Comment From Pete: We are interested in Solution Manager, BPR, for an SAP project already post go-live. Will this session discuss approaches to SAP solutions in sustainment? 

Heiko Hecht: Yes, that is a key objective for the RBPD content! It will help you if you document your system very precisely at one point but if you don't keep that documentation up to date it will get outdated and will soon be worth less and, eventually, worthless. Utilizing SDA and the RBPD content will help you to keep the documentation up to date.

 As I said before, the use of SolMan and tools is important, but there is more to Solution Documentation and ALM. Additional details are needed, and should be included, on top of what SolMan provides out of the box.

Comment From Guest: Any estimate for implementing RPBD for a mature ERP system for a new solution (e.g. SAP Solution Manager) that the application team has never used?

Heiko Hecht: I would suggest a Solution Manager Overview Workshop, maybe three days, for the stakeholders involved.

Once SolMan is technically set up and configured, I think you can get to a solid business blueprint in 8 weeks, based on our experience. We use SAP standard content and tools and our own methods and tools, which accelerate the process. I think the knowledge transfer is key if your team wants to be successful.

Comment From Ezra: Do we need a Business Process Structure to roll out BPCA? 

Heiko Hecht: Yes, BPCA needs a business process structure, and I would go even further, it needs the best business process structure available. For example, you need to include all objects used, especially your custom transactions and programs, to get a useful Impact Analysis.

Comment From Guest: Have you seen any good presentations / media to help understanding SDA/BPM/RPBD/SEA?   

Heiko Hecht: I don't think you will find one link where all of that is available in one area but is a good starting point for SDA/RBPD.

Comment From Giovanni Gómez: Would you like to share with us an experience about implementing documentation through SAP Solution Manager in an SAP BPC Project?

Heiko Hecht: You’re referring to Business Planning and Consolidation, correct? There are several aspects to those scenarios. SAP's Business Process Repository (BPR) doesn't address Planning, Reporting or BW really thoroughly. That's why SAP has defined a supplementary offering for BW, for example.

The 5 supplementary services from SAP/IBIS for SAP Solution Manager are:

  1. RBE Plus: Differentiate and Compare
    Analyze multiple system landscapes, differentiate organizational units or process cluster (Business Blueprint per System, Region, Company Code/Plant)
  2. RBE Plus: Potential Analysis
    Uncover significant potential for improvement and cost reduction, take charge of your knowledge effectively (Additional detail documentation can be linked into SAP Solution Manager)
  3. RBE Plus: BPM Tool Integration
    Up-to-date system documentation, foundation for defining and validating a to-be model cross referencing BPR elements in SAP Solution Manager to enable full Solution Manager functionality after import (RBPD content can be used for non BPR projects)
  4. RBE Plus: User and Role Analysis
    Assess the license situation, review authorization strategy, documents user activities within the context of their authorization assignment (Process oriented analysis of users, e.g. which user is actively involved in which processes)
  5. RBE Plus: BW Analysis for SolMan
    Reverse-engineer a blueprint of BW processes based on usage statistics, usage analysis of all BW elements (Creates the BW data model in SAP Solution Manager)

Another aspect is comparing systems/org units. SAP Solution Manager can analyze several systems and the systems can be compared on a process level. The question is whether you want to build a global template. Do you want to merge different business blueprints? And on which level do you want to compare the different systems? There are supplementary services available defined by SAP and IBIS to help with comparing/consolidating systems or regions.

Bridget Kotelly:  We will have to wrap it up here. Thanks again, everyone, for all your great questions. I invite you to visit the SAPinsider Admin/Dev channel for recent Solution Manager coverage from our Admin2014 conference and the Project Management  channel for more discussion  - including tips from IBIS America’s Marci Braybrooks – on the Solution Manager tools for project teams.

And thanks again to Heiko Hecht of IBIS America for joining us today and taking the time to share your insights and advice!

Heiko Hecht: Thank you all very much for your questions and interest in this topics! Please contact the IBIS Team or me directly with any questions you might have at or 570-620-3028.
Thank you to Bridget and the SAPInsider team for hosting this Q&A session!
Have a great week and I hope to see you in an upcoming SAP/SAPInsider event!

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!