Business processes can get quite complex and this makes it tough to model a real big process into just one graphical model. It makes no sense to model an end-to-end-process like "order to cash" into just one graphical model comprising everything like "article selection to shopping cart", "submission of purchase order", "money transfer", "packaging", "logistics" etc. A process hierarchy is necessary to divide complex processes into smaller parts. A process hierarchy follows the "from abstract to concrete" principle. This means it provides information about the processes on different levels of granularity. Therefore it is possible to get information about the abstract value chain (e.g. Purchasing, Production, Sales) or about very specific process steps and their logical order (e.g. create customer, approve purchase order). A process hierarchy is defined by its levels and the information given in these levels. It is key to have a defined information base on each level (e.g. a process step is always performed by a specific role instead of an abstract organizational unit), otherwise process models won't be comparable at a later stage. The model below shows the process hierarchy model and provides an example for each level - the process model consists of six Levels.
A high level aggregation of company functionality (core ore support functionalities, depending on the view of processes to be analyzed).
A bundle of processes that belong to the same area of responsibility dealing with similar tasks and activities for functional or other reasons.
The Business Process is the level that aggregates business oriented functions or steps to a unit that is meaningful and comprehensive in the sense that the steps or functions incorporated are essential to fulfill a business mission related task. I. e. a Business Process is defined by steps that transform an input into an enriched output.
The Process Variant is meant to fulfill the same business mission but in a different manner or with a different application compared to a Business Process. I.e. Input and Output are more or less the same but the way to reach the output is different.
Each Business Process (or variant) consists of process steps. The steps itself contain activities performed by an user or a system in order to fulfill the business mission.
An activity performed by an user or a piece of software together with other Process Steps forming a Business Process or a Business Process Variant.
I. e. Business Processes do consist of more than one process step.
• A Process Step is an activity that is related to exactly one object (e.g. human, sheet of paper, purchase order (system) ...).
• A Process Step is typically executed by one person and documented using an appropriate representation of the object (paper, data in IT-system,...).
• From an user interaction point of view a Process Step is a single work task in a causal work flow without role change. A Process Step is typically identified by the fact that the task owner has got all necessary responsibilities to execute the task. A Process Step can be performed by a human being alone or by an interaction between human/system and system/system.
Activities are the lowest granularity for business process modeling and reflect the single actions an user ore a system performs in order to fulfill the Process Step. I.e. filling in the fields of a special mask consists of activities as each field has to be filled to end the step.
With this process hierarchy it is possible to model the processes of different business areas. However in order to model End-To-End scenarios it is necessary to have an additional view on the process hierachy. This view includes the modeling of business scenarios that consume business processes from different business areas. The example given above regarding the order to cash process would therefore consume necessary business processes from different business areas. The usage and modeling of business scenarios is described in the below section: Business Scenarios.
For overview aspects it is essential to understand that this structure model provides a common terminology and naming convention. The following overview shows how the process hierarchy is translated and adopted across different tools.
With this process hierarchy it is possible to model the processes of different business areas. However in order to model End-To-End scenarios it is necessary to have an additional view on the process hierachy. This view includes the modeling of business scenarios that consume business processes from different business areas. The example given above regarding the order to cash process would therefore consume necessary business processes from different business areas. The usage and modeling of business scenarios is described in chapter 2.3.11.
Detailed Definitions will be found in the following chapters. For overview aspects it is essential to understand that this structure model provides a common terminology and naming convention. The following overview shows how the process hierarchy is translated and adopted across different tools.
The Business Scenario is a separate view on the sequence of Business Processes (and Business Process Variants) triggering each other and thereby forming an end-to-end process flow. These end to end process chains may consist of various Business Processes and Business Process Variants executed in a logical order. Business Processes and its Business Process Variants may belong to different Business Areas and Process Groups.
A Business Scenario is geared towards the achievement of a defined business objective. The achievement of this objective is measurable with KPIs. The KPIs clarify the customer's value and benefit he wants to achieve. A Business Scenario describes at full extent and completely the processing of one business operation. Unanimity refers to both economical operational sequence and functions as well as to data consistency. A Business Scenario is always described from the point of view of one company. It shows the B2B interactions with other companies but not the processing in these other companies. It can include collaboration functionality.