Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Setting the Granularity or Appropriate Level of Detail for

Modeling Business Processes
Applies to:
Enterprise architects, BPXers, business analysts. Cross industry and not product specific.

Summary
In a previous article (Modeling Business Processes Using BPMN and ARIS) I dealt with modeling business
processes using the Business Process Modeling Notation (BPMN), which is a relatively easy task. A more
complex task to deal with is finding the right level of granularity (or level of detail) to guide you when
modeling your business processes. In this article, I suggest several criteria that you can follow to define what
level of detail to use.
Author: Natty Gur
Company: SAP
Created on: 28 January 2007

Author Bio
Natan Gur has 13 years of experience in the IT field. Recently, he has been working for SAP on
the SAP enterprise architecture (EA) framework. Natan has eight years of experience running
EA in companies and governmental bodies. Natan also serves as the technical director of the
International Association of Software Architects (IASA) and is a member of the IASA board of
directors. He has been elected by Microsoft as an MVP for the last four years.

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

1

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Table of Contents
Applies to ......................................................................................................................................... 1
Summary.......................................................................................................................................... 1
Author Bio ........................................................................................................................................ 1
Introduction ...................................................................................................................................... 2
Level of Detail for Modeling Capabilities ......................................................................................... 2
Solution Composer....................................................................................................................... 2
Business Process Master List - BPML......................................................................................... 5
Reference Models ........................................................................................................................ 6
Level of Detail for Modeling Business Processes............................................................................ 6
Process Actors ............................................................................................................................. 7
Events .......................................................................................................................................... 8
Tasks............................................................................................................................................ 9
BPMN ........................................................................................................................................... 9
Information ................................................................................................................................. 10
Summary........................................................................................................................................ 11
Related Content............................................................................................................................. 11
Copyright........................................................................................................................................ 12

Introduction
In a previous article (Modeling Business Processes Using BPMN and ARIS) I dealt with modeling business
processes using the Business Process Modeling Notation (BPMN), which is a relatively easy task. A more
complex task to deal with is finding the right level of granularity (or level of detail) to guide you when
modeling your business processes. In this article, I suggest several criteria that you can follow to define what
level of detail to use. While modeling your enterprise business domain, you must to deal with capabilities
(what) and business processes (how). Therefore, this article will provide you with granularity criteria for both
of these building blocks.
If you choose to use a top-down approach (which is the common approach in business modeling), you will
probably start by modeling capabilities, followed by modeling business processes to describe how each one
of your capabilities is carried out by your enterprise. Using this approach, lets start by dealing with criteria for
modeling capabilities. After that, we will discuss criteria for modeling business processes.

Level of Detail for Modeling Capabilities

Solution Composer
SAP has predefined criteria accompanied by predefined content for modeling capabilities. This definition
includes business scenario groups, business scenarios and business processes taken from the Solution
Composer. If you have ever had a look at the Solution Composer, you probably noticed that the lowest level
of detail represented by it is still too abstract. Therefore, we recommend breaking down the Solution
Composer processes to the level that reflects your needs. The most common criteria by which to break down
Solution Composer processes is along the enterprise hierarchy. By doing this, you break processes into subprocesses by finding out what the tasks are that every organizational unit (according to the hierarchy)
performs.

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

2

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Lets take an automotive original equipment manufacturer (OEM) as an example. When you open the
Solution Composers automotive OEM solution map, you see the higher level of capabilities, which are called
business scenario groups (Figure 1). Automotive OEM business scenario groups include: Time-to-Market,
Supplier Collaboration, Build-to-Order, Sales and Marketing, Customer Service and Enterprise Management
and Support.
Figure 1.0 Automotive OEM Business Scenario Groups

Choosing the expand all checkbox reveals the business scenarios that make up each business scenario
group. For example, Customer Service is composed of Warranty Management, Interaction Center, Service
Parts Planning and Service Parts Execution (Figure 2).

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

3

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Figure 2 Business Scenarios

Each of the business scenarios is composed of business processes. Service Parts Execution is composed of
Parts Purchase Order Processing, Parts Inbound Processing and Receipt Confirmation, Warehousing and
Storage, Physical Inventory, Parts Cross Docking, Returned Parts Quality Control, Sales Order Processing,
Parts Outbound Processing, Parts Transportation Execution, Billing, Complaints Processing, Product Service
Letter Processing, Supply Chain Monitoring and Control (Figure 3).
Figure 3 Business Processes

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

4

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

As already mentioned, processes are too abstract. Physical Inventory is a high-level capability that can easily
be broken into subprocess such as Cycle Counting Physical Inventory Preparation, Definition of Scope of
Periodic Inventory, Determination of Scope for Periodic and Continuous Inventory, Inventory Count, Physical
Inventory Analysis, Post Inventory Differences, Printout of Physical Inventory Document, Recount,
Specification of Cycle Counting Physical Inventory. These sub-capabilities begin to be more concrete
capabilities.
Business Process Master List - BPML
Another approach you can take in order to classify capabilities is to use the Business Process Master List
(BPML). BPML suggests five levels of hierarchy: Area, scenarios, group, processes and business process
procedure. If you look at one of the BPML sheets
(www.eitoolkit.com/tools/implementation/bpml_master_list.xls), youll find that business process procedures
are more concrete than the process levels in the Solution Composer. If you find business process
procedures too abstract, you can still follow the organizational hierarchy or a business reference model, as
described below.

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

5

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Reference Models
The last criterion that you can follow is to use any business reference model, such as SCOR
(http://www.supply-chain.org/page.ww?section=SCOR+Model&name=SCOR+Model ) or VCOR
(http://www.value-chain.org/en/cms/?4 ).
VCOR, for example, defines five levels of hierarchy:
1. Strategic processes (the macro business processes)
2. Tactical processes (a subset of the enterprise strategic processes that can be assigned to applicable
business tactics)
3. Operational processes (general processes that establish a link between activities)
4. Activities (decomposition of operational processes into specific activities)
5. Actions (individual work instruction items)
VCOR defines content only to the three first hierarchy levels in the reference model; so you still need to
define the fourth and fifth levels of capabilities yourself.
Relevant VCOR levels for Inventory Management:

SCOR has four levels:

1.
2.
3.
4.

Top level (process types)

Configuration level (process categories)
Process element level (decompose processes)
Implementation level (decompose process elements).

Level of Detail for Modeling Business Processes

Having a list of your enterprise capabilities is a huge leap forward for getting you current and target business
architecture. But most of the time capabilities are not enough, and we want to get the how perspective of
capabilities by modeling how the process or processes that support that capability are carried out in the
enterprise. There are several aspects in terms of level of detail that you need to decide on for modeling
business processes.
While modeling, you need to deal with organizational hierarchy, events, tasks, business rules, and
information needed to perform process tasks and transactions. Before we start modeling processes, we need
to consider and decide on the usage rules for these business process ingredients. These rules will set the
level of detail along which we will model the processes. The rules may be the same for all of the business
process modeling, or they may differ between the different levels of capability.

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

6

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Process Actors
The first decision to make involves the hierarchy level of the participant in the process modeling. It can start
from a higher level of abstraction, such as board members, and go down through the organization units
hierarchy to the employee level. Going down to employee level may be a very time-consuming effort.
Therefore, you usually make the enterprise the lowest level of participant in the processes. As stated earlier,
the level of actors in the process modeling should differ between different levels of capability.
Process modeling according to high-level hierarchy:

OEM

Car production

Message

Importer

Order Car

Message

Message

Car Shipment

Message

Request for car

Dealer

End event
Order Car

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

Car delivery

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

7

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Process modeling according to low-level hierarchy:

MRP Controller

Carry
out reservati...

OEM
REM-Production
Planner

Production

Message

Strategic
Buyer

Importer

Message

Message

Vehicle
locating...

Operative
Buyer

Process
order

Shipment
tracking

Transport
Manager

Transport
control

Message

Message

Message

Message

Request for car

Operative
Buyer

Vehicle
specificati...

Order
tracking
End event

Dealer
Warehouse
Worker

Goods
receipt...

Events
Events that start or change business flow, tasks that are performed by actors, and business rules that shape
the process are all essential to modeling a process. Although you can omit rules and/or events to reduce the
level of detail the business process models have to deal with, I think that they are essential for modeling
processes at the lower levels of capabilities. Its possible, however, to drop the details (roles and events),
and it might even make sense if you are modeling processes of high-level capabilities.

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

8

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Process modeling with rules and events:

MRP Controller

Carry
out reservati...

OEM
REM-Production
Planner

Production

Message

Strategic
Buyer

Importer

Message

Vehicle
locating...

Operative
Buyer

Production status
Shipment
tracking

Process
order

Finished message
Transport
Manager

Transport
control
Message

Message

Message

Request for car

Operative
Buyer

Vehicle
specificati...

Order
tracking
End event

Dealer
Warehouse
Worker

Goods
receipt...

Tasks
You cannot model a process without tasks being taken by actors, but you can limit the tasks by various
criteria. One common criterion is defined by Alec Sharp, Patrick McDermott in their book Workflow Modeling:
Tools for Process Improvement and Application Development. The workflow modeling approach suggests
three levels of granularity that you can assign to each one of the actors that you describing. You can model
handoffs, milestones or individual tasks.
BPMN
Another method you can use to define the level of detail is defined by the BPMN standard. BPMN
distinguishes between 3 types of business processes: private, abstract and collaboration. Basically, these
methods define what should be modeled in lanes (actors) that take part in the process.
Private denotes a single private business process usually performed by a single participant.
Abstract represents interaction between a private business process and another business process. Only
those activities that are used to communicate outside the private business process, plus the appropriate flow
control mechanisms, are included in the abstract process. All other internal activities of the private business
process are not shown. Thus, the abstract process shows the outside world the sequence of messages that
are required to interact with that business process (BPMN standard).
Collaboration represents interaction between a private business process and another business process, but
this time all of the participant activities and the flow control should be depicted by the model.
Private business process:

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

9

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Abstract business process:

Collaboration business process:

Information
Information that can be input or output for a task described in business process modeling can also be used
for setting the process modeling level of detail. You can decide to model your processes without any
reference to information, with limited information, or with just inputs or outputs. If you already have
conceptual and logical information models, you can also limit the information to conceptual or logical levels of
abstraction. You can also determine whether your business process modeling will include transactions or
not.

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

10

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Business process modeling with information:

Info
(schedule,
quantity,
configuration)
about planned vehicles

MRP Controller

Carry
out reservati...

OEM
REM-Production
Planner

Vehicle
configuration

Strategic
Buyer

Importer

Production

Message

Current
order
status

Message

Vehicle
locating...

Operative
Buyer

Delivery
documen
t

Production status
Shipment
tracking

Process
order

Finished message
Transport
Manager

Transport
control
Vehicle
configuration

Message

Message

Message

Request for car

Operative
Buyer

Vehicle
specificati...

Order
tracking
End event

Dealer
Warehouse
Worker

Goods
receipt...

Summary
In this article, I have tried to summarize the different criteria you can use to set the level of detail to use for
modeling both capabilities and business processes. These are the most common criteria that I use. Although
I list all of the criteria, keep in mind that combinations of these criteria can be used as well. The key for
successful process modeling is to determine in advance the capability level and the level of detail for each of
those capability business processes, and to follow those rules.

Related Content

http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%201-0%20Spec%2006-0201.pdf - OMG Final Adopted Specification, February 6, 2006

Workflow Modeling: Tools for Process Improvement and Application Development, by Alec Sharp
and Patrick McDermott, copyright 2001, Artech House Publishers.

www.eitoolkit.com/tools/implementation/bpml_mgmt_guide.ppt - Business Process Master List

(BPML) Management Guide, December 2003.

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

11

Setting the Granularity or Appropriate Level of Detail for Modeling Business Processes

Copyright
Copyright 2007 SAP AG. 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 AG.
The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,
zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are
trademarks or registered trademarks of IBM Corporation.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems
Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of
Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts
Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by
Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All
other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP
Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group 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.
These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied
warranties of merchantability, fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may
result from the use of these materials.
SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these
materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and
does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.
Any software coding and/or code lines/strings (Code) included in this documentation are only examples and are not intended to be
used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of
certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors
or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

SAP DEVELOPER NETWORK | sdn.sap.com

2007 SAP AG

BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com

12