Page tree
Skip to end of metadata
Go to start of metadata

Process Hierarchy

The process hierarchy builds the documentation structure for the entire process management and interacts with the process models and diagrams. The process hierarchy and process diagrams are two sides of the same coin.

The hierachy is not only important for business processes but also for the structuring of reuse elements which are managed in libraries. Libraries are structured according to the types of elements they manage, for example process steps, interfaces, configurations, executables, developments, and alerts. While some of the libraries are focusing on the IT objects, the process step library also partially represents the business view of needed capabilities required to operate your business.

The reuse libraries should also follow the first level of the process hierarchy. See further details about the libraries.

Functional Decomposition and Documentation Structure

A process hierarchy is necessary to divide a complex processes landscape into smaller better manageable parts. It follows the from-abstract-to-concrete principle and provides information about the processes on different levels of granularity. A process hierarchy delivers a defined information base on each level to ensure process models are comparable at a later stage.


The process hierarchy builds the foundation for a common understanding of the business processes operated by a corporation and should be used similaly by the business and IT departments. It acts as the breakdown of the customers business and is used to document and attach the information, following a from-abstract-to-concrete principle. 


A well-defined process hierarchy is the most important starting point for any process management, solution documentation, or process modeling activity. The process hierarchy and process diagrams are two sides of the same coin and are always managed as a whole.

The process hierarchy always consists of folders used to breakdown the processes into process groups. The process grouping is followed by a last level grouping, called scenario, with its processes and process steps. The final three levels are always scenario-process-process steps. The number of grouping folders before the nucleus starts can vary as required.



Find out more about process hierarchy and structure naming conventions.

How to Jumpstart a Meaningful Process Hierarchy?

Even if a customer-specific process hierarchy is always the ultimate goal, there are several options to jumpstart the definition of a well-defined process hierarchy. Companies and organizations such as APQC (, SCOR (, EFQM (, and VCG ( define best practice process hierarchies, KPIs, flows, and much more that make a good jumpstart. Also, many consulting firms maintain process hierarchies used as baseline for implementation projects. The best practice process hierarchies are typically tailored to industries. They describe in a well-defined from-abstract-to-concrete decomposition  what the processes are a company acting in a certain industry usually maintains. 

These predefined process hierarchies may not be ideal in all aspects but are definitely a good starting point to evolve your own process hierarchy from there. The following example shows you how you could upload 3rd party process content: MS Excel Upload (Example APQC content).  

Modular Processes

In addition to the holistic, integrative end-to-end processes in the operational process area, you can create more functional, modular processes. Modular processes are processes that typically do not exceed the functional domain of an organization. Hence, there is always one organization that has the responsibility for the entire process. These processes should be grouped by functional domains that very often correspond to organizational structures.


  • Finance
  • Human resources
  • Production
  • Procurement
  • Sales

Modular processes typically build a process hierarchy. You should understand them as the functional decomposition of business processes, represented by a hierarchical structure of folders and – on the lowest level – a process diagram showing process steps. Each level structures the process information in a way which makes navigation manageable and logic from a functional customer perspective, spanning different levels of granularity.


  • Sales
    • Lead management
    • Quotation management
    • Sales order management


The structuring of modular processes should follow your structural company organization. We recommend to organize modular processes by using no more than 5-7 levels. We also recommend to build modular processes from process steps of one functional domain only.

Due to the character of being related to one functional domain only, you should focus to assemble modular processes from process steps that belong to the same functional domain.

Even though this can surely be achieved to a large extend, processes are often require to also include functions from other domains. However, in spite of functions from other domains, the responsibility of an included function belongs to the domain it was designed in.

The highest level of the process hierarchy is the Modular Processes-folder containing all process areas as sub-folders which are again decomposed into further sub-areas. Within this structure, processes can be also grouped with regards to process variants. The last level of grouping processes is always a scenario.

You can model the actual process using a BPMN process diagram, representing an individual process. It shows the interaction of roles and depicts the process steps describing a process from a process flow perspective.


End-to-End Processes

Operational processes focus on end-to-end integration. Typical use cases of such process documentation from a business perspective is to understand the value creation process within the company. From IT perspective it can focus on integration or regression tests for a complete scenario However, you can also use these processes for publishing documentation or to discuss business requirements with the business users.


“[…] A process is a set of logically related activities performed to achieve a defined business outcome. […]” (Davenport & Short, 1990).

A process is defined by a process definition which consist of a set of referenced process steps and interfaces.
End-to-end processes do not stop at the boundaries of a process area or an organization. Typically, an end-to-end process involves multiple functional domains and represents a comprehensive flow of activities needed to solve large business matters.

Order-to-cash and procure-to-pay are very prominent examples of end-to-end processes. An order-to-cash process typically starts at a customer interaction with a sales clerk or a web shop and then invokes functions belonging to production, supply chain management and finance. End-to-end processes are usually complex because they involve a relatively high number of process steps and embed also modular processes if necessary. The fact that there is no single responsible person for all functions used in the end-to-end process even increases the effort needed to align and integrate all involved functions and parties.

Besides the complexity, end-to-end processes also deliver high value and represent the most critical business scenarios a company has to fulfil. We clearly recommend to identify the most critical business scenarios and to define end-to-end processes in a very detailed fashion on process step level in SAP Solution Manager 7.2. The end-to-end process will become rather big, but still you can use embedded sub-processes to simplify the process flow and to increase readability.

Depending on the use case, different documentation can be assigned to the processes. Reasonable for this kind of processes would be:
• Business process descriptions
• Integration test case descriptions
• End user training material

As these processes are executed across functional areas, they are the best candidates to include also interface information. So, besides the chain of process steps or sub processes you can also include interfaces as intermediate events of type interface.


The structuring of end-to-end processes should follow your operational process organization and your business value chains. We recommend to organize processes by using no more then 5-7 levels. End-to-end processes are built from process steps across functional domains.

The highest level of the end-to-end process structure is End-to-end processes-folder containing all required end-to-end process areas as sub-folders which are again decomposed into further sub-areas. The last level of grouping end-to-end processes is always a scenario.

You can model the actual end-to-end process using a BPMN process diagram. It shows the interaction of roles and depicts the process steps describing the process from a process flow perspective.

Check here for more on  Modular and End to End process design.

  • No labels


  1. Former Member

    I Like to see all the process in the system, how I can do that ?

  2. On the "Business Processes" folder switch to List view and filter by type "Process". Et voilà you have complete list of processes which you can further filter, sort, download by any given criteria.

  3. Hello Wulff-Heinrich / Barbara,

    How can customer's generate reports on the hierarchy logic of their Solutions, branches and folders etc?