Ta 08

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 6

Process Hierarchy

PUBLIC
TABLE OF CONTENTS
PROCESS HIERARCHY ................................................................................................................................... 3
LEVEL 2 – PROCESS GROUPS ...................................................................................................................... 3
Level 3 – Business Processes ....................................................................................................................... 3
Level 4 – Business Process Variants ............................................................................................................ 4
Level 5 – Process Steps .................................................................................................................................. 4
Level 6 – Activities........................................................................................................................................... 4
Business Scenario (End-to-End Process Chains) ....................................................................................... 5

2
PROCESS HIERARCHY
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.

Level 1 – Business Areas


A high-level aggregation of company functionality (core ore support functionalities, depending on the view of
processes to be analyzed).

https://wiki.scn.sap.com/wiki/display/ModHandbook/Level+1+Business+Areas

Level 2 – Process Groups


A bundle of processes that belong to the same area of responsibility dealing with similar tasks and activities
for functional or other reasons.
https://wiki.scn.sap.com/wiki/display/ModHandbook/Level+2+Process+Groups

Level 3 – Business Processes


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.
https://wiki.scn.sap.com/wiki/display/ModHandbook/Level+3+Business+Processes

3
Level 4 – Business Process Variants

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.

https://wiki.scn.sap.com/wiki/display/ModHandbook/Level+4+Business+Process+Variants

Level 5 – Process Steps

An activity performed by a 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.
Comments:
• 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 a 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.

https://wiki.scn.sap.com/wiki/display/ModHandbook/Level+5+Process+Steps

Level 6 – Activities
Activities are the lowest granularity for business process modeling and reflect the single actions a user or a
system performs to fulfill the Process Step. I.e. filling in the fields of a special mask consists of activities as
each field must 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 hierarchy.
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 hierarchy.
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.

4
https://wiki.scn.sap.com/wiki/display/ModHandbook/Level+6+Activities

Business Scenario (End-to-End Process Chains)


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.

https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=154600011

5
www.sap.com/contactsap

© 2017 SAP SE or an SAP affiliate company. All rights reserved.


No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See http://www.sap.com/corporate-en/legal/copyright/index.epx for additional trademark
information and notices.

You might also like