Skip to Content
Personal Insights
Author's profile photo Oded Dagan

How to Design and Build the Solution Manager Process Tree – Part 1

Hi Guys!

Due to these special times everywhere I have decided to share my 25 years of experience in building these trees for the benefit of everyone! This is the first blog in a two piece series.

Many in the SAP community regard and fear the task of building a proper and truly representative Process Tree in SOLMAN as long, tedious and expensive. THIS IS NOT TRUE! For many organizations this is a major deterrent from implementing and gaining benefit from SOLMAN so I will try to break down this obstacle.  I am referring to basic Process Tree Structure and executables.

When I start this task for a new organization I guarantee the complete implementation using only 2 work days from each implementer/consultant and usually finishing much earlier. When they all work in parallel this is also the total time for the whole organization. This also applies for large and complex organizations because the business processes implemented in an organization are usually distributed between all of the consultants evenly so that each consultant is responsible for 100-300 processes. So the consultant should be able to name and write down in the following excel file his processes and transactions quite quickly. Newbies might need some guidance, prioritization, changing of levels and resolution.


The best way is to plan in an excel file. This is the basic and convenient structure for the Process Tree. Note that each level (Scenario, Process, Process Step and Transaction) should be on a separate line!

This is very intuitive and straight forward. It resembles good old SOLAR01 structures and SOLAR_EVAL reports from SOLMAN 7.1 and will be the basis to build for SOLMAN 7.2 Documentation Management – SOLDOC. Now SAP’s recommendation is for one transaction for one Process Step. This plays out as very useful for testing purposes and building BPCA TBOMS.

For example you could use the create, change and display transactions for one Process Step:

But even better would be to separate them. For example you might have different developments and checking routines for them and might test them differently:

Now for some rules of thumb:

There are transactions that can represent more than one Process Step, meaning that they can support many use cases depending on the internal use of the transaction.

For example in the Logistic modules we have the Order which has Order types. Typically an Order type represents different fields to be used, different customer code you have developed, different test cases etc. So you should list a separate Step for each Order type with its description. For example:

This rule can be used for Orders, Notifications, Contracts etc. in MM, SD, PP, PM, QM etc. If you have tens or hundreds of Order types you may want to define only the major ones and aggregate the remaining. I don’t recommend splitting up financial document types into Steps because the processing is usually similar.

In HCM we use PA30 and PA40 for many use cases. I recommend defining the Steps by actual HR usage and not by InfoType:

There are many other examples in the SAP systems: large inclusive transactions in IS-Insurance, IS-Automative, CRM etc. where there are many process variants and use cases within one transaction. This requires defining each one as a separate Step.

Now that you have gotten the hang of this a few general words:

Level of resolution – When considering the division of a transaction into several Steps the question you must answer is – Am I going to test this process separately and in a distinct fashion? If so – define it as a Process Step. If not – it can be aggregated with other processes. So the answer is specific to each organization and process.

More Levels – SOLMAN 7.2 was designed to provide as many levels as needed in the Process Tree Structure using Folder columns that can be added to the left of the Scenario. So you can use many levels as long as the 3 levels to the right are Scenario, Process and Process Step. Use this for reaching the level of detail you need within the planning excel file where you can easily change the levels. After importing to SOLMAN it is not as flexible.

Completeness – It is important that you capture all of the Business Processes used in SAP to ensure that you really have a complete picture of the SAP based activities in your organization. You will need this completeness for it to be “the single source of truth” and to use it for regression testing, documentation etc.

E2E/End to End Processes – Yes it is technically possible to try and build your tree according to a particular process flow. I do not recommend this for these reasons: the process flow you pick is only one out of many different variations: One type of Purchase Requisition can lead to many types of Purchase Orders can lead to many types of Deliveries, Invoices etc. So you may have hundreds or even thousands of different process flow combinations in your organization. The place to document them is in the Test Suite – where you decide exactly which common and important variants you test for. So the Process tree is your repository for all processes which you should organize according to your consulting teams because they are the guys who are going to maintain the tree. They are usually built according to the SAP modules.

Executables – In my examples I used transactions but you should include everything a user can execute: Programs (as in jobs or interfaces), Web Dynpros, URLs to UI5 apps or even non-SAP apps, CRM Webclient Applications, Job definitions and Fiori Applications. To correctly use Fiori parameters follow:

Documents, Configuration, Developments, Test Cases – These are all very good uses for the Process Tree which can be implemented after building your organizations basic Tree.

Building the Tree in SOLMAN – should be done by each consultant manually. In the next blog I will describe how to upload from excel.

Tutorials – I recommend learning from the SOLMAN Media Center:!GR_267560D84F4CD84#group!GR_76EEC9EE858AF393&show=group!GR_267560D84F4CD84&library=library.txt

See you in Part 2.

Oded Dagan

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Heiko Hecht
      Heiko Hecht

      This is very helpful and definitely an option.

      SAP used to support this process with Reverse Business Process Documentation (RBPD) in SolMan 7.1.

      We have the Library Generation Cockpit in SolMan 7.2 which is not ideal and more technically focused and we have SAP's S/4HANA Best Practices of course.

      My recommendation is to use the S/4HANA Best Practices at this point. Eventually S/4 will become relevant for many SAP customers. While the Best Practices are far from being perfect, they are a good starting point, they include process diagrams, Fiori Apps, IMG objects etc. Do we really want and need to invent the wheel from scratch? Naturally the S/4 Best Practices don't really map the "legacy" ECC transactions to well but that is also an area where the consultants can come in.

      My understanding is that SAP is also working on the Best Practices and we might see some new content there in the near future as well.

      SAP customer can also consider using the Model Company content as a starting point.

      Author's profile photo Oded Dagan
      Oded Dagan
      Blog Post Author

      Hello Heiko!

      Thanks for your thoughts and comments.

      I agree, RBPD was very useful and gave a good head start. Even better was the SOLMAN 7.1 program RUTILITY_BLUPRINT_GENERATION_PARAMETERS which actually built a Process Tree according to the actual transaction usage. I tried twice in the SAP INFLUENCE sessions to convince SAP to include it in 7.2 and failed to do so.

      S4 Best Practices is also useful because of the FIORI Apps documentation in it. But ECC Best Practices, which you can still import and use, are less useful in my opinion. Apart from the financial modules which are standardized everywhere, the logistic and HR process vary greatly.

      So I think that your comment on using the  Library Generation Cockpit in SolMan 7.2 is a very good idea! After a while the folders in the Executables Library include all the transactions and programs used in PROD and this is an good repository to start with. I also use the list of transactions out of ST03N.

      Keep Well!


      Author's profile photo Cara Stone
      Cara Stone

      Enjoyed the article, thanks.  Can semi-dynamic TBOMS be created for Fiori executables, or must we record Dynamic TBOMS for BPCA analysis?

      Author's profile photo Oded Dagan
      Oded Dagan
      Blog Post Author


      TBOMS only record APAP. Which means that it doesn't matter if you record dynamic or semi - the UI5 part of the app wont be reflected in the TBOM. So if the FIORI App is original SAP with no additions - your ok. If there were UI5 additions - they wont be detected by BPCA.

      This is my knowledge - you might want to check it with SAP.

      Best Regards,

      Author's profile photo Axel Schulze
      Axel Schulze

      Hi Cara,

      SAP is piloting the option to capture semi-dynamic TBOMs for Fiori App.

      Please reach out to me if you are interested to participate.