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.
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 (www.apqc.org), SCOR (www.apics.org/), EFQM (www.efqm.org), and VCG (www.value-chain.org) 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).
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.
- Human resources
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.
- 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.
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.