How to Design and Build the Solution Manager Process Tree – Part 1
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:
See you in Part 2.