Guidelines of Business Process Modeling

1 2 1
Jörg Becker , Michael Rosemann , Christoph von Uthmann
1
Westfälische Wilhelms-Universität Münster
Department of Information Systems
Steinfurter Str. 109, 48149 Münster, Germany
Phone: +49 (0)251/83-38100, Fax: +49 (0)251/83-38109
{isjobe|ischut}@wi.uni-muenster.de
2
Queensland University of Technology
School of Information Systems
2 George Street, Brisbane QLD 4001, Australia
Phone: +61 (0)7 3864 1117, Fax: +61 (0)7 3864 1969
m.rosemann@qut.edu.au

Abstract. Process modeling becomes more and more an important task not
only for the purpose of software engineering, but also for many other purposes
besides the development of software. Therefore it is necessary to evaluate the
quality of process models from different viewpoints. This is even more
important as the increasing number of different end users, different purposes
and the availability of different modeling techniques and modeling tools leads
to a higher complexity of information models. In this paper the Guidelines of
Modeling (GoM)1, a framework to structure factors for the evaluation of
process models, is presented. Exemplary, Guidelines of Modeling for workflow
management and simulation are presented. Moreover, six general techniques
for adjusting models to the perspectives of different types of user and purposes
will be explained.

1 Complexity and Quality of Business Process Models

The popularity of different process management approaches like Lean Management

[58], Activity-based Costing [52], Total Quality Management [21, 35], Business
Process Reengineering [16, 17], Process Innovation [7, 8], Workflow Management
[14], and Supply Chain Management [39] has two main effects concerning the
requirements on process models. First, the number and variety of model designers
and users has spread enormously. Especially, representatives from various business
and technical departments, who are not necessarily modeling experts are increasingly
involved in the design of process models. As a consequence, the understandability of
process models is of growing importance. Secondly, the number and variety of

1 This paper presents results from the research project Guidelines of Modeling (GoM), which was funded
by the German Ministry of Education, Science, Research, and Technology, project no.: 01 IS 604 A.

W. van der Aalst et al. (Eds.): Business Process Management, LNCS 1806, pp 30-49, 2000
 Springer-Verlag Berlin Heidelberg 2000
 Guidelines of Business Process Modeling 31

purposes process models are used for is growing. Besides the "traditional" use of
process models within software engineering these models are more and more used for
pure organizational purposes like process reorganization, certification, Activity-based
Costing or human resource planing (see as well [37]).
Process modeling is supposed to be an instrument for coping with the complexity
of process planning and control. Existing models show as well considerable
complexity themselves, though. Hence, the design of process models often turns out
to be very problematic. It has direct influence on the economic efficiency of the
underlying process-related project. In the first place the model design requires
personnel resources and (if necessary) the purchase of software tools. Moreover, the
risk exists that the process models, referring to their purpose, are not sufficient. For
example, semantic mistakes or the disregarding of relevant aspects can lead to
possibly expensive misjudgments. Consequently, the design of models always is an
economical risk and not only a modeling exercise.
Especially in enterprise-wide process management projects the design of
integrated process models can become a comprehensive challenge. The number of
process models can easily be higher 500 with five or more different levels. The
related risk will be increased if the model design is seen as a domain of "modeling
specialists" who are supposed to be the only ones who understand "their" models. In
contrast to this, a business process model should serve as a communication base for
all persons involved. Consequently, the quality of process models can beyond the
fulfillment of syntactic rules defined as its "fitness for use".
Within this context a framework called Guidelines of Modeling (GoM) has been
developed to assure the quality of information models beyond the accordance to
syntactic rules. The GoM-framework includes six guidelines, which aim to improve
the quality of information models (product quality) as well as the quality of
information modeling (process quality). The design of business process models is one
core field within the project.
This paper describes first the general intention and the framework of the
Guidelines of Modeling (section 2). Exemplary, Guidelines of Modeling for
workflow management and simulation, two main purposes of process modeling, are
discussed in the third section. Section 4 presents six different techniques for the
adaptation of models to perspectives of different users and purposes. The paper ends
with a brief conclusion.

2 The Guidelines of Modeling (GoM)

Various frameworks for quality assurance of information models were already

presented. Usually, they are either focussing only one kind of information models, in
particular data models (like the approaches from [1] or [31, 32]), they focus only
special requirements [2, 59], or they contain such high-level-statements, that it is
difficult to derive useful recommendations for modeling projects [24, 27].
The aim of the Guidelines of Modeling (GoM) is the development of specific
design recommendations in order to increase the quality of models beyond the
32 J. Becker, M. Rosemann, C. von Uthmann

fulfillment of syntactic rules [3, 41, 42]. The term GoM has been chosen as an
analogy to the Generally Accepted Accounting Principles (GAAP) [9, 29, 38]. On the
one hand, the GoM result from the selection of the relevant aspects for information
modeling from the GAAP.
On the other hand, the GoM adapt elements of the existing approaches for the
evaluation of information models. The Guidelines of Modeling, which are presented
here (see for an alternative suggestion [49]), contain six guidelines to ameliorate the
quality of information models. These are the principles of correctness, relevance,
economic efficiency, clarity, comparability, and systematic design (figure 1, see also
[31]). While the observance of the principles of correctness, relevance and economic
efficiency are a necessary precondition for the quality of models, the principles of
clarity, comparability and systematic design have a mere optional character.
The GoM-framework includes besides the six general guidelines (level 1) recom-
mendations for different views (level 2, e.g. process models) and for different
modeling techniques (level 3, e.g. Event-driven Process Chains (EPC) or Petri Nets).

syntactic rules system, procedure model

semantical process structures, reference models
correctness process instances structural model components
terminology resources, media ... Modelling
... Techniques
Correctness Relevance Economic
Efficiency Views

General
Model Quality

Clarity Comparability Systematic

Perspectives
Design
- Reorganization
topology (e.g. minimize conventions for view-integration - AB-Costing
crossing lines) modeling (e.g. activities level-integration - Automation/WFM
visualizing semantics as places or transitions) (e.g. ARIS) - IT-Inv.-Control,
naming/terminology terminology ... .... etc.
... ...

Fig. 1. The Framework of the Guidelines of Modeling (GoM)

2.1 The Basic Guidelines

The basic guidelines consist of the guideline of correctness, the guideline of

relevance, and the guideline of economic efficiency.
The guideline of correctness has got two facets [1]: the syntactic and the semantic
correctness. A model is syntactic correct, if it is consistent and complete against the
meta model (see for definitions of meta model ([33], p. 38, [44], pp. 104-105) the
model is based on. For the evaluation of the syntactic correctness of a model it is
indispensable to have an explicit (documented) meta model. Semantic correctness
postulates that the structure and the behaviour of the model is consistent with the real
world. Finally, the consistence between different models is viewed as a part of the
correctness of the model [59].
 Guidelines of Business Process Modeling 33

While many frameworks use completeness as a quality factor of information

models [1, 31], the GoM express this criteria in more relative terms.
The guideline of relevance postulates
• to select a relevant object system (universe of discourse),
• to take a relevant modeling technique or to configure an existing meta model
adequately, and
• to develop a relevant (minimal) model system.
A model includes elements without relevance, if they can be eliminated without
loss of meaning for the model user.
The guideline of economic efficiency is a constraint to all other guidelines. In the
GAAP-context it is called the cost/benefit constraint ([9], p. 51). It is comparable to
the criteria "feasibility" of LINDLAND ET AL. [27] and restricts e.g. the correctness or
the clarity of a model. Approaches to support the economic efficiency are reference
models, appropriate modeling tools or the re-use of models.

2.2 The Optional Guidelines

The pragmatic aspect of the semiotic theory [27] is integrated in the GoM by the
guideline of clarity. Without a readable, understandable, useful model all other efforts
become obsolete. This guideline is extremely subjective and postulates exactly, that
the model is understood by the model user. It is not sufficient, if a model designer
regard the model as understandable (see also understandability in the GAAP ([9],
p. 52). "Construct overload", the situation in the framework of WAND and WEBER in
which one object type of an information modeling technique map to at least two
ontological constructs is an example for missing clarity as additional knowledge
outside the modeling technique is required ([56], p. 211). Mainly layout conventions
put this guideline in concrete terms.
The guideline of comparability demands the consistent use of all guidelines within
a modeling project. It is one of the guidelines which corresponds directly with one
GAAP principle, the comparability principle ([19], pp. 551-552). Like the GAAP
which aims to increase the comparability between businesses and periods (e.g. avoid
different inventory methods like LIFO and FIFO), this guideline includes e. g. the
conform application of layout or naming conventions. Otherwise, two models would
follow certain, but different rules. The necessity to compare information models is
obvious if as-is-models and to-be-models or enterprise-specific and reference models
have to be compared.
The guideline of systematic design postulates well-defined relationships between
information models, which belongs to different views, e.g. the integration of process
models with data models. Every input and output data within a process model has to
be specified in a corresponding data model. Further interdependencies exist,
following for example the ARIS-approach [45, 46, 47], concerning the functions
(function view), the organizational units (organizational view), the results of a
process (output view) and the involved applications and databases (resource view).
One demand is to use a meta model which integrates all relevant views.
34 J. Becker, M. Rosemann, C. von Uthmann

2.3 The GoM Meta Model

Within the research project Guidelines of Modeling a meta model was designed in
order to structure and integrate the different project topics (figure 2, [42]). This model
shows that a perspective is defined as a person-purpose-model-relationship. The
purpose represents the intention of the modeling project. Besides the purposes the
perspective is determined by the involved persons. Here are two facets of relevance:
the existing methodological knowledge (expert, novice) which influences the
selection and configuration of the modeling technique, and the role (model designer
or user, active or reactive role), which influences the content of the model. Other,
more elaborated definitions of the terms perspective and also viewpoints can be found
in [6, 36].
Obviously, the guidelines vary in their perceived importance for different
perspectives. For example, information models used within the phase of requirements
engineering for the purpose of developing individual software and ideally
automatically processed by CASE-tools call for syntactical correct models (primacy
of the guideline of syntactical correctness in comparison with the guideline of
clarity). In contrast to this, process models which are used to explain the business to
end-users may include syntactical mistakes, if this supports compact and clear models
and if the economic efficiency and the clarity is more important. Consequently, it is
necessary to define also perspective-specific guidelines.

1,1

0,n 1,1 1,1 0,n 0,n is related 0,n

View belongs to Model system depicts Domain Class
to

0,n 1,n 0,n

view-specific is a has knowledge

GoM perspective about

0,n 0,n 0,n

0,n perspective- 0,n 0,n

Guideline intends Person
specific GoM D,T
0,n
intern
1,n 0,n 0,n
0,n
extern
1,n 0,n
is part of Purpose intends Objective

method- D,T
specific 0,n Designer
0,n GoM knows

is appropriate User
Quality criteria knows
to

0,n 0,n
0,n 0,n
belongs to 0,n Method 0,n includes 1,n Tool
0,n

D,T 0,n 1,1 Meta data

is designed Notation describes
model
with

Meta
Procedure 0,n 1,1
describes process
model
model

Fig. 2. The GoM meta model

 Guidelines of Business Process Modeling 35

In the following workflow management and simulation will be taken as two

examples for popular modeling purposes. Various recommendations for these two
purposes will be presented.

3 Guidelines for Selected Purposes of Business Process Modeling

3.1 Workflow Management

The economic efficient development of workflow-based applications [26] does not

only require a well considered planning and implementation of systems, but demands
the efficient design of workflow models (see also [22]). Workflow models serve in all
stages of system planning and development as a communication platform for those
who work on the project. However, the recent discussion of workflow modeling is
often focussing on syntactic questions. It neglects criteria that go beyond the notation
rules and include the specific semantic context of the individual modeling process.
In order to establish standards for the design of information models it is
advantageous to have a modeling technique that can be regarded as a quasi-standard
(like the ER-approach [4] for data models). Currently, this is not the fact with
workflow models. Every workflow management system uses rather its proprietary
modeling technique. Therefore, after a workflow management system has been
chosen, a revised workflow modeling according to the system-specific modeling
technique is in the most cases indispensable.
Experience has shown that the general number of business process models to be
transformed into workflow models is rather small. It is not unusual that a company
has 100 or more business process models, but only two or three workflow models.
Furthermore, concerning breadth and length, only a part of a business process model
can usually be controlled workflow-based. Thus, the manual revision of workflow
models often is more economic efficient than the use of interfaces (see WfMC
interface no. 1). These interfaces might provide some syntactical translation but can
not bridge the semantic gap between business process models and workflow models.
In the following, specific recommendations for workflow modeling will be given,
which focus on comparing these models with business process models. Moreover, it
will be distinguished between a first workflow model that is used for selecting a
workflow management system or discussing workflow alternatives, and the final
executable workflow model.

Function View
Concerning the functions (or activities) within a workflow model, usually a n:m-
relationship between business process models and workflow models exist.
Compared to organizational process models, in workflow models manual functions
should be largely avoided, in particular if one follows after the other immediately. On
the other hand the amount of functions rises, if the application systems or
36 J. Becker, M. Rosemann, C. von Uthmann

organization units involved allow further splitting of a function. In general one can
state that the granularity of the functions in workflow models are determined by a
(possible) change of the organizational unit and/or the application system. Figure 3
shows how with every change of the involved organizational unit and/or the
application system a new function has to be introduced. One has to consider the fact
that most workflow management systems do not allow a reuse of functions. In this
case, a redundant function specification is necessary.
For every function the start and end conditions should be precisely determined. In
particular, it has to be indicated if the function shall be started manually or automated.
As an option, for every function a deadline can be declared. When this deadline is
exceeded, a higher authority can be informed, ideally the person in charge for the
process (the process owner). It should be taken into account that not all workflow
management systems support a hierarchical modeling.
Thus, business process models can be used as a starting point for the development
of workflow models. In order to derive the workflow model, functions have to be
deleted and new functions have to be modelled. For the design of an executable
model, also further attributes (start and end conditions) have to be specified.

xor

AS
OE1
1

OU- AS AS
Change OE2
1 1

AS
OE2 AS- OU- AS-
1
Changel Change Changel

AS = AS AS
OE3
Application System 2 2
OU =
Organizational Unit

Fig. 3. Granularity of functions within workflow models

Data View
Unlike a business process model, a workflow model requires for every function the
description of the necessary input and output data. On the level of entity types,
attributes, etc. the workflow model has to depict these input and output information.
Due to the considerable modeling effort being necessary for the data view of a
workflow model, only data that is critical because of the underlying interfaces has to
be specified within the first workflow model. After a workflow management system
is selected and an executable workflow model is required, the data view has to be
 Guidelines of Business Process Modeling 37

completed with information like the data type or the exact data location (database
server, table, etc.).
Besides the input and output data, the data flow is to be described. The data flow
determines the flow from the function that produces data to the function that
consumes data. The data flow is restricted by the control flow as the data flow can not
precede the control flow. Consequently, the control flow has to be completed before
the data flow can be specified. A workflow model should include the data flow as this
enables an analysis of further interfaces beyond the use of the control flow
information. However, existing workflow management systems often do not allow the
visualization of the data flow and show only the (local) input and output data.

Organizational View
Every function within a workflow model must include a link to an organizational
construct, if it is not completely automated and shall be executed autonomously.
Relevant organizational constructs in the context of workflow management are role
(in the sense of a qualification or a competence), organizational unit (permanent or
temporary like a project team), position, position type and person as a static
information. Figure 4 describes using an extended ER-approach the relationships
between these organizational constructs. Moreover, a workflow owner should be
specified for the entire workflow.

Structure

Qualification

(0,n) (0,m)
(0,p)
Role D,T

is (0,m) (0,m)
substitute Competence owns
for
(0,n)

(0,n) (0,m)
is
(0,n)
Person member owns
of
(0,n)

(0,m) (0,n) (0,m)

Position (0,n) (1,1)

is member of Position Structure
Type

(0,m) (0,n) (0,n)

occupies

is part of

Temporary
Organizational
(0,m) (1,m) Unit

Organizational
Structure D,T
Unit

(0,n) Permanent
Organizational
Unit

Fig. 4. A reference model for the organizational constructs within workflow models [44]
38 J. Becker, M. Rosemann, C. von Uthmann

The organizational constructs in workflow management systems differentiate to a

considerable extent. Concerning the assignment of organizational constructs to
workflow functions, always the minimum set of organizational constructs which is
required for the workflow execution has to be chosen. The organizational constructs,
which are used for workflow modeling should refer to the "usual" organizational
constructs of the enterprise specified in an organizational chart. If information about
the workflow runtime history is of importance, (i.e. function no. 6 should be executed
by the same employee who was responsible for function no. 3), a detailed note has to
be placed in the workflow model (e.g., "RTH" (Run Time History)).
It has to be taken into consideration that in a workflow model the link between a
function and an organizational construct means "executes". During the run-time the
workflow management system interprets this link and the identified organizational
population receives the corresponding work item. In contrast, in business process
models this link often means "is responsible for".
If several organizational constructs are connected with only one function, there is
always an XOR-relationship between them. This means that the number of at run-
time addressed members of the organization is extended (e.g. procurement
department, all members of a special project and Mr. Smith receive the work item). If
a certain rule exists, according to which the relevant organizational constructs can be
selected, but the function itself as well as the involved application systems and data
are identical, a workflow-split (control flow) has to be defined. If there shall be an
AND-relationship between the organizational constructs, it has to be explicitly
declared at the borderline between function and organizational construct ("AND").
This could for example mean that both, task executive and project executive, must
sign a document. Again, it should be stressed that these comprehensive modeling
conventions can only apply for the general workflow model. As soon as a special
workflow management system is selected, its constraints usually do not allow this
elaborated specification between the workflow functions and the involved
organizational constructs.
In addition to the organizational constructs, further involved resources have to be
depicted. Again, it should be differentiated between a general specification of
resources in a first workflow model, which serves as a basis for discussions and the
executable workflow model. Only the final workflow model has to include the
complete and exact specification of all involved resources. All referred IT-
applications have to include specifications of the server, program parameters, etc.

Control View
The control flow describes the logic relationships between the workflow functions.
Whereas a linear sequence does not require special considerations (but see the
requirement to specify the start and end conditions), split and join constructs are far
more demanding. This is an important difference to business process models, which
can easily include various splitting and joining connections without that the modeler
has to be concerned about the process execution.
Possible (inclusive or exclusive) OR -splits have to be specified exactly in order to
become executable by the workflow management engine. If it is not a simple
 Guidelines of Business Process Modeling 39

transition condition (e.g., order value > 10.000 $), a reference has to be set that leads
to an explanatory document (i.e. rules of signatures, organizational handbook). It is
advantageous expressing the respective transition conditions by using dedicated
nodes in the models (e.g., predicates, places or arc-inscriptions in Petri Nets or events
in Event Driven Process Chains (EPC)).
As an optional construct, many workflow modeling tools allow an ELSE-exit
(also: default-connector). This connector is rated as "true", if the conditions of the
other corresponding connectors do not fit. This semantic relationship can be stressed
by explicit indication of the relevant connector with "ELSE".
OR-Joins require special consideration as many workflow management systems
execute them wrongly as an XOR-Join. While this is not critical within business
process models, inclusive OR-joins demand further information about the
connections, which are evaluated with true at run-time. One approach is the dead path
elimination [25]. In this case, the corresponding OR-split forwards an information to
the OR-join about all workflow paths, which will not be executed. With this input the
OR-join has all required information for the determination of the continuation of the
workflow.
Many workflow management systems demand one explicit start and final state
node respectively. This is usually not required in business process models. Therefore,
these nodes have to be added.

3.2 Simulation

Business Process Simulation (BPS) [12] has been mentioned, albeit only briefly, by
many researchers as a technique that could be helpful in the context of business
process change. HANSEN (1994) also advocates the appropriateness of simulation for
Business Process Reengineering, arguing that "an engineering approach to process
reengineering that incorporates modeling and simulation is necessary". Similarly,
KETTINGER ET AL. (1997) argue that there is a need for more user-friendly and
‘media-rich’ capture of business processes and simulation can accommodate these
requirements by providing easy visualization and allowing team participation in
process redesign. V. UTHMANN and BECKER [53, 54] discuss some detailed aspects of
the use of simulation within the business process management life-cycle (figure 5).
The design of simulation models, although it is a problematic task, is mostly
treated as a black box. There are only some unsatisfactory isolated hints like "use
refinements" or "formalize successively". For the reduction of complexity and the
efficient management of designing models three principles have been established in
systems engineering: the structuring of similar objectives in phases, the reuse of
solution components and the application of conventions to restrict the degree of
freedom. The central idea behind this is the identification of analogies in the problems
and the reuse of analogous solutions. The identification and utilization of such
analogies within the context of simulation models lead to phases, components and
conventions.
40 J. Becker, M. Rosemann, C. von Uthmann

GoM for GoM for GoM for

GoM for GoM for
BP-Structure BP-Simulation BP-Control
Transfer Transfer
Models Models Models

Simulation of BP-instances as a transfer medium

between BP-(Re)Engineering and BP-Control

xor

construct
BP-Model

or

Simulation of BP- Simulation of

instances for BP-Structure BP-Instance BP-Control BP- Instances for
Model Model Model
optimizing structures specification of
of informational or/and automatic
material processes analyze analyze Instances analyze instances BP-Control
(BP-(Re)Engineering) Structure experimentally Status (WFM, PPC)

Struct.-Ana. Instance Ana. Status Ana.

Results Results Results

xor xor xor

Manual Inst. Manual Inst. Autom. Inst.

Co-ordination Co-ordination Co-ordination

Fig. 5. Simulation within the business process management life-cycle

Model design recommendations should be applicable to a variety of simulation

tools. While the phases are independent of tools the components and conventions
have to be put in concrete form in terms of certain simulation modeling techniques
using their specific construction elements and terminology. As a reference method
higher Petri Nets [40] were chosen. Besides some other good reasons the Petri Net
specific design recommendation can, thanks to their general process understanding,
be transformed to other process modeling techniques pretty easily [53, 55].
A phase model of seven phases has been developed (figure 6, a more detailed
description of the guidelines is given in [54]). The separated view of process object
flows is directed to the purposes of processes and simplifies the process identification.
This meets the BPR objective of analyzing processes without taking care about
departments (= resources). In view of the widely used structure- and function-
oriented process descriptions (see [18]) it can be assumed that such a view of
processes is intuitively easier to understand than simulation models, especially by
modeling novices, and therefore, better accepted. Processing from phase 1 to 2 leads
towards a systematic successive transition from static structure models to dynamic
models. A further advantage of a separated view of process object flows is that
corresponding process models can easier be hierarchically refined without the
assignment of resources over different levels. Traditionally, from a function view a
process is understood as a succession of object-using, modifying and/or deleting
functions (activities), and from data view as a succession of states corresponding to
the existence of process-related objects. This differentiation is reflected in the phase
model: First in phase 1 (process object flows) it is recommended to start with a
 Guidelines of Business Process Modeling 41

function oriented process mapping (s. above). In phase 3 the object types are
specified within the static data view before the functions are procedurally (in contrast
to descriptively) described in phase 4. In the phases 1 to 4 there are considered
process structures, coordination mechanisms, operation and state times. Input,
disturbances/changes and initial states are designed in phase 5 to 7.
The phases offer a framework to decompose the design of process simulation
models in less complex subtasks. Within the phases certain objectives are to be
modeled applying to specific components and conventions.
The aim of using model components, which can be individually composed, is a
more efficient and correct model construction. There are reference simulation models
in the form of context-related model components [45]. Complementary to these ones
the guidelines comprise components, which are not related to concrete organizational
or engineering problems, but structure context independent analogies. These structure
components describe coordination mechanisms on different complexity levels where
components can consist of less complex components (down to the elements of the
meta model of the simulation language). Their higher abstraction level allows the use
of these components for a simplified individual construction of simulation models
from the scratch as it usually is necessary within process simulation. Moreover, the
structure components help model designers to be more sensitive towards possibly
relevant coordination mechanisms. The structure components are related to single
objectives, and therefore, are assigned to certain construction phases.

1 Process Object Flows

3 Object Types 2 Resource Obj. Flows. 4 Procedural Rules

5/6 Input/dist.+changes

Object-based
Process Understanding
PO RO
Process Related Objects

7 (Initial) States

Fig. 6. Phase model for simulation model design

Finally, some design conventions should be presented. Methods of process

modeling contain generally just a set of syntactic rules, which give model designers a
wide degree of freedom. Therefore, one objective can be depicted in (different)
models which are correct but do not have sufficient quality, e. g. they are misleading
or badly arranged. This has to be taken into account especially because of the (in
simulation models) usually high number and variety of involved model designers and
users of model. Conventions are supposed to restrict this freedom and lead to a higher
quality. One important intention of this is to ensure a uniform, clear (GoM-principle
42 J. Becker, M. Rosemann, C. von Uthmann

of clarity) and unequivocal understanding of models of all involved users. A further

important aspect of model conventions is the support of coping with the requirements
perspectives. Important conventions for simulation models refer especially to the use
of terminology, topology, start and end markings of processes, the visualization of
process and resource object types (including the media type) within their
organizational context, documentary aspects and the explication of different views
(e.g. data, function and organizational view). For the definition and consolidation of
terms the use of a business term model is proposed. Besides the discussed semantic
aspects the performance of simulation models has to be taken into account.

4 Techniques for Adjusting Models to Perspectives

Perspectives on process models can be distinguished by the involved persons and by

the modeling purpose. While a process model which specifies a workflow has to
depict among others the control flow, the data flow and program parameters (see
section 3.1), a model which is used within an organizational handbook or for certifi-
cation purposes includes mainly organizational facts (process owner, roles, etc.). A
rough impression of the great variety of perspectives on information models which
exists especially concerning process models can be found in figure 7.

cu s to m izing o f
so ftw a re sta n da rd so ftw are w orkflo w
d eve lop m e n t sp e cifica tio n
so ftw a re
se lec tio n sim ula tio n

BPR
a nim a tio n
co n tin uo u s
p ro ce ss h um an re so u rc e
m a n ag em en t p la n ning
a ctivity-b a se d
ce rtific ation co s tin g
p ro je c t
b en ch m a rking kn o w le dge m a n ag em en t
m a n ag em en t

Fig. 7. Potential perspectives on process models [42]

Within the research project Guidelines of Modeling we identify, characterize and

compare these perspectives using empirical studies. In the following, this paper is not
concentrating on these content-specific questions, but it will be discussed how
perspectives can methodically be distinguished. Six ways of customizing different
perspectives will be explained. They have an adjunctive relationship to each other,
which means that they can be used in combination. As an application of the guideline
of relevance they suppose to reduce the model complexity for every individual
perspective.
 Guidelines of Business Process Modeling 43

4.1 Different Layout Conventions

Different layout conventions exist, if the models of two perspectives concerning the
number and the naming of the information objects are identical, but different in their
representation (aesthetics). This kind of model differentiation is more determined by
the way of using the model than by the model content. It can be realized with
"reasonable effort", if the placement is identical and only form, color, size, etc. of the
objects are different. The transformation of "typical" information models with cycles
and squares into more colorful, more or less self-explainable models is important to
gain the acceptance in the business departments. Figure 8 portrays, taking ARIS Easy
Design as an example [20], how a process model designed for end users from
business departments can look like (see also [30] for a similar approach).
Different layout conventions become much more difficult to handle, if also the
placement of the information objects can vary. One example in (large) data models is
that different entity types are of different importance for different users. As a
consequence, in every model different entity types should be right in the middle of
the model, the area of most attention. For that, sophisticated algorithms are necessary,
which optimize models concerning metrics like the minimal (average, maximum)
length of edges, the minimal number of crossings, or the minimal drawing area [2, 34,
51]. Potential constraints are that only two directions are allowed (vertical, hori-
zontal) or symmetries have to be stressed (e.g. sons in hierarchies).

Fig. 8. A process model in ARIS Easy Design [20]

44 J. Becker, M. Rosemann, C. von Uthmann

4.2 Different Naming Conventions

A different naming in models related to different perspectives is of high importance

in distributed, especially international modeling projects and requires the possibility
to administer synonyms for the relevant model constructs. It is recommended to use a
business term catalogue, which defines and relates the main terms within a company
([23], pp. 127-133). Furthermore, one cluster of the business term catalogue should as
a part of the meta model define the constructs, which are relevant for information
modeling (e.g. entity type, cardinality) [50]. Between the single business terms exist
typical semantic relationships like "is related to", "classifies", "is part of", "is a" or "is
synonym of". A business term catalogue should substitute existing (textual) glossaries
and be as far as possible completed before the process modeling activities start. The
attributes of the business terms contain links to the different purposes and
characterize a term e.g. as a software-specific term (e.g. "Company Code" within SAP
R/3) or to specific qualifications (e.g. the German term "Unternehmen" for model
users familiar with German). The user or the user group has corresponding attributes,
so that for every user (group) the adequate terms can be selected automatically.

4.3 Different Information Objects

In comparison with different layout or naming conventions the perspectives are much
more individual, when different information objects are relevant for them. For
example, a workflow developer would not be interested in a detailed description of
the manual functions within a process, while someone who is responsible for the
implementation of activity-based costing may be especially interested in these time-
consuming functions (see also [43] for a comparison of workflow management and
activity-based costing requirements). On the other hand, batch-tasks depicted in a
process model may be not important for someone who is writing an organizational
handbook, while they have a specific meaning for the person who is responsible for
the customization of ERP software. In a next step the importance of the attributes of
every object or the appropriate degree of specialization can be discussed for every
perspective. It is not only the purpose but also the role, which determines the relevant
objects. For example, a doctor has got another perspective on the same process than
the patient and the person who allows traveling expenses another one than the person
who applies for them (see for another example ([28], pp. 60-61)). Thus, different
perspectives can be characterized as different projections on one common model.
Though this is very expensive to realize as it requires a relationship from every object
to the relevant perspectives, it is one of the most important forms to characterize
individual perspectives.
 Guidelines of Business Process Modeling 45

4.4 Different Information Object Types

In some cases the requirements of different perspectives can be generalized in a way,

that between the perspective and the information object types (e.g. entity type,
organizational unit type, etc.) of the common meta model a relevance relationship can
be identified. That means, different perspectives can be characterized as different
projections on a common meta model. For example, it is indispensable to depict the
object type role in a workflow model, while in ERP-specific reference models like the
ones from SAP [5] or BAAN [13] system organizational units (e. g. company code,
plant or sales organization in SAP R/3) are relevant.
This requirement is already realized in some modeling tools. For example, ARIS-
Toolset is offering method filters which reduce the meta model in a way that the user
is not confronted with the over-complexity resulting out of a non-appropriate
modeling technique [20].

4.5 Different Use of a Process Modeling Technique

The high number of different modeling techniques with a common root (e. g. Entity
Relationship model or Petri Nets) leads to the fact, that in many cases perspectives
can be distinguished because they are slightly different in their meta model. As an
explanation, the event-driven process chains (EPC) are taken as an example [45, 46].
EPC consist mainly of functions, events and control flow connectors. One notation
rule, which was stressed about the EPC, is that an OR-split never succeeds directly an
event. Nonetheless, in the most important book which is using the event-driven
process chains, "Business Process Engineering" [45] the included reference models
do not consider this rule (to get a higher clarity, because of shorter processes).
This kind of perspective differentiation requires individual rules to transform one
model into the other. It is one objective of the Guidelines of Modeling to identify for
widespread modeling techniques like the ERM or event-driven process chains typical
differences in using the meta model and as far as possible to prioritize one alternative
(see [41] for examples for the event-driven process chains).

4.6 Different Meta Models

As the first five approaches assume that one modeling technique serves for all the
different perspectives, the requirements for such a language are quite high [36].
Single perspectives have got the highest degree of individualization if they are
designed with different modeling techniques. Therefore, they already can be
distinguished by the underlying meta models. Such a differentiation may be
necessary, if a BPR-project requires easy to understand models designed for example
with event-driven process chains, while the introduction of workflow management
requires precise Petri Nets and the increase of the customer orientation of the
processes needs customer-supplier-protocols [48]. If this form of perspective
46 J. Becker, M. Rosemann, C. von Uthmann

differentiation is tolerated within a modeling project, it is recommended to design

relationship meta models: meta models which relate the elements and relationships of
the involved modeling techniques to each other [33]. They can be used for the
horizontal model transformation (within analysis) and for the vertical model transfor-
mation (from analysis to design).

5 Summary and Outlook

A continuously growing number of different purposes for process modeling, of

involved model designers and model users, and available comprehensive modeling
tools increases the complexity of process modeling. Thus, the management of the
quality of process models is becoming challenging.
This paper presented a framework called Guidelines of Modeling (GoM), which
structures different quality criteria and levels of abstraction in two dimensions. We
discussed the six guidelines of correctness, relevance, economic efficiency, clarity,
comparibility and systematic design (section 2). Workflow management and
simulation were taking as examples in order to put the modeling recommendations in
concrete terms for two selected purposes (section 3). More general, six different
techniques for the differentiation of process models for alternative purposes were
presented (section 4). The introduced concepts offer less experienced model designers
some hints for a systematic and adequate design of process models. The overall GoM
architecture and the detailed recommendations make more sensitive for critical
quality factors beyond the consistent use of a modeling technique.
The aim of the further work is the design of a "comprehensive" set of guidelines
for process models with Petri Nets as the uniform reference modeling technique
within the entire process life-cycle [10, 11]. Modeling Guidelines should force to
construct the common elements adequately for the core purposes of process
modeling, namely Business Process (Re)Engineering, workflow management and
simulation [53]. Furthermore, we are currently analyzing the potential for the
integration of an IS-related ontology into the GoM-framework. First results taking the
Bunge-Wand-Weber models [57] can be found in [17].

References

[1] Batini, C., Ceri, S., Navathe, S. B.: Conceptual Database Design. An Entity-Relationship -
Approach. Benjamin Cummings, Redwood City, California (1992)
[2] Batini, C., Furlani, L., Nardelli, E.: What is a good diagram? A pragmatic approach. In:
th
Chen, P. P.-S. (ed.): Proceedings of the 4 International Conference on the Entity-
Relationship Approach: The Use of ER Concept in Knowledge Representation. Elsevier,
North-Holland, 312-319
[3] Becker, J., Rosemann, M., Schütte, R.: Guidelines of Modelling (GoM). Wirtschafts-
informatik 37 (1995) 5, 435-445 (in German)
 Guidelines of Business Process Modeling 47

[4] Chen, P. P.-S.: The Entity-Relationship Model: Toward a Unified View of Data. ACM
Transactions on Database Systems 1 (1997) 1, 9-36
[5] Curran, Th., Keller G.: SAP R/3. Business Blueprint: Understanding the Business Process
Reference Model. Prentice Hall, Upper Saddle River (1998)
[6] Darke, P., Shanks, G.: Stakeholder Viewpoints in Requirements Definition: A Framework
for Understanding Viewpoint Development Approaches. Requirements Engineering 1
(1996), 85-105
[7] Davenport, T.H.: Process Innovation: Reengineering Work Through Information
Technology. Boston, Massachusetts (1992)
[8] Davenport, T.H., Short, J.E.: The New Industrial Engineering: Information Technology
and Business Process Redesing. Sloan Management Review 31 (1990) 4, 11-27
[9] Davis, M., Paterson, R., Wilson, A.: UK GAAP: Generally Accepted Accounting
th
Principles in the United Kingdom. 5 ed., Clays Ltd, Bungay, Suffolk (1997)
[10] Deiters, W.: Information Gathering and Process Modeling in a Petri Net Based Approach:
Part III, Chapter 1 of this volume
[11] Deiters, W.; Gruhn, V.: The Funsoft Net Approach to Software Process Management.
International Journal of Software Engineering and Knowledge Engineering 4 (1994) 2,
229-256
[12] Desel, J., Erwin, T.: Simulation of Business Processes: Part II, Chapter 2 in this volume
[13] van Es, R. M.; Post, H. A.: Dynamic Enterprise Modeling. A Paradigm Shift in Software
Implementation. Kluwer, Deventer (1996)
[14] Georgakopoulos, D.; Hornick, M., Sheth, A.: An Overview of Workflow Management:
From Process Modeling to Workflow Automation Infrastructure. Distributed and Parallel
Databases 3 (1995) 2, 119-153
[15] Green, P., Rosemann, M.: An Ontological Analysis of Integrated Process Modelling. In:
Jarke, M., Oberweis, A. (eds.): Advanced Information Systems Engineering. Proceedings
th
of the 11 International Conference - CAiSE '99. Lecture Notes in Computer Science,
Vol. 1626. Springer-Verlag, Berlin et al. (1999), 225-240
[16] Hammer, M.: Reengineering Work: Don‘t Automate, Obliterate. Harvard Business
Review 68 (1990) 4, 104-112
[17] Hammer, M., Champy, J.: Reengineering the Corporation: a Manifesto for Business
Revolution. London (1993)
[18] Hess, T., Brecht, L.: State of the Art des Business Process Redesign: Darstellung und
nd
Vergleich bestehender Methoden. 2 ed., Gabler-Verlag, Wiesbaden (1996) (in German)
nd
[19] Horngren, Ch. T.; Harrison, W. T.: Accounting, 2 ed. Prentice Hall, Englewood Cliffs,
New Jersey (1992)
[20] IDS Scheer AG: ARIS Methods. Version 4.1. Saarbrücken (1999)
[21] Ishikawa, K.: What is Total Quality Control? The Japanese Way, Prentice Hall, Engle-
wood Cliffs (1985)
[22] Jannsens, G. K., Verelst, J., Weyn, B.: Techniques for Modelling Workflows and their
Support of Reuse: Part I, Chapter 1 in this volume
[23] Kirchmer, M.: Business Process Oriented Implementation of Standard Software. Springer-
Verlag, Berlin et al. (1998)
[24] Krogstie, J., Lindland, O. I., Sindre, G.: Towards a Deeper Understanding of Quality in
Requirements Engineering. In: Iivari, J., Lyytinen, K., Rossi, M. (eds.): Proceedings of
th
the 7 International Conference on Advanced Information Systems Engineering –
CAiSE `95. Springer-Verlag, Berlin et al. (1995), 82-95
[25] Leymann, F., Altenhuber, W.: Managing business processes as information resources.
IBM Systems Journal 33 (1994) 2, 326-348
48 J. Becker, M. Rosemann, C. von Uthmann

[26] Leymann, F., Roller, D.: Workflow-based applications. IBM Systems Journal 36 (1997)
1, 102-123
[27] Lindland, O. I., Sindre, G., Sølvberg, A.: Understanding Quality in Conceptual Modeling.
IEEE Software 11 (1994) 2, 42-49
[28] Macaulay, L. A.: Requirements Engineering, Springer-Verlag, Berlin, Heidelberg, New
York (1996)
[29] Miller, M. M.: Comprehensive GAAP Guide. Harcourt Brace Jovanovich, Publishers, San
Diego et al. (1988)
[30] Moody, D. L.: Graphical Entity Relationship Models: Towards a More User Under-
th
standable Representation of Data. In: Thalheim, B. (ed.): Proceedings of the 15
International Conference on Conceptual Modeling: Conceptual Modeling – ER '96.
Springer-Verlag, Berlin et al. (1996), 227-244
[31] Moody, D. L.; Shanks, G. G.: What makes a Good Data Model? A Framework for
Evaluating and Improving the Quality of Entity Relationship Models. The Australian
Computer Journal, 30 (1998) 3, 97-110
[32] Moddy, D. L.: Shanks, G.: Improving the Quality of Entity Relationship Models: An
Action Research Programme. In: Edmundson, B., Wilson, D. (eds.): Proceedings of the
th
9 Australiasian Conference on Information Systems. Vol. II, Sydney (1998), 433-448
[33] Nissen, H. W., Jeusfeld, M. A., Jarke, M., Zemanek, G. V., Huber, H.: Managing Multiple
Requirements Perspectives with Metamodels. IEEE Software 13 (1996) 3, 37-48
[34] Nummenmaa, J.; Tuomi, J.: Constructing layouts for ER-diagrams from visibility-
th
representations. In: Kangassalo, H. (ed.): Proceedings of the 9 International Conference
on the Entity-Relationship Approach - ER `90: Entity-Relationship Approach. Elsevier,
North-Holland (1991), 303-317
nd
[35] Oakland, J.S.: Total Quality Management: The Route to Improving Performance. 2 ed.,
Nichols Publishing, New Jersey, NJ, (1993)
[36] Opdahl, A. L.: Towards a faceted modelling language. In: Galliers, R. et al.: Proceedings
th
of the 5 European Conference on Information Systems - ECIS ’97. Cork 1997, 353-366
[37] Pagnoni, A: Management-oriented Models of Business Processes: Part I, Chapter 7 in this
volume
rd
[38] Pareira, V., Paterson, R., Wilson, A.: UK/US GAAP Comparison. 3 ed., Briddles Ltd,
Guildford and King’s Lynn (1994)
[39] Poirier, C. A.: Advanced Supply Chain Management: How to Build a Sustained
Competition. Publishers’ Group West (1999)
[40] Reisig, W.: Petri Nets - An Introduction. Berlin (1985)
[41] Rosemann, M.: Complexity Management in Process Models. Gabler-Verlag, Wiesbaden
(1996) (in German)
[42] Rosemann, M.: Managing the Complexity of Multiperspective Information Models using
rd
the Guidelines of Modeling. In: Fowler, D., Dawson, L. (eds.): Proceedings of the 3
Australian Conference on Requirements Engineering. Geelong (1998), 101-118
[43] Rosemann, M, Green, P.: Enhancing the Process of Ontological Analysis - The "Who
cares?" Dimension. In: Dampney, K. (ed.): Proceedings of the IS Foundations-Workshop.
Sydney, 29. September (1999)
[44] Rosemann, M., zur Mühlen, M.: Evaluation of Workflow Management Systems - a Meta
Model Approach. Australian Journal of Information Systems 6 (1998) 1, 103-116
rd
[45] Scheer, A.-W.: Business Process Engineering. 3 ed., Springer-Verlag, Berlin et al.
(1998)
nd
[46] Scheer A.-W.: ARIS - Business Process Modeling. 2 ed. Berlin et al. (1999)
 Guidelines of Business Process Modeling 49

[47] Scheer, A.-W., Nüttgens, M: ARIS Architecture and Reference Models for Business
Process Management, Part III, Chapter 8 in this volume
[48] Scherr, A. L.: A new approach to business processes. IBM Systems Journal 32 (1993) 1,
80-98
[49] Schütte, R., Rotthowe, Th.: The Guidelines of Modelling as an approach to enhance the
quality of information models. In: Ling, T. W., Ram, S., Lee, M. L. (eds.): Conceptual
th
Modeling - ER '98. 17 International ER-Conference, Singapore, November 16-19, 1998.
Springer-Verlag, Berlin et al. (1998) 240-254
[50] Spencer, R., Teorey, T.; Hevia, E.: ER Standards Proposal. In: Kangassalo, H. (ed.):
th
Proceedings of the 9 International Conference on the Entity-Relationship Approach –
ER `90: Entity-Relationship Approach. Elsevier, North-Holland (1991), 425-432
[51] Tamassia, R., Di Battista, C., Batini, C.: Automatic graph drawing and readability of
diagrams. IEEE Transactions on Systems, Man, and Cybernetics 18 (1988) 1, 61-78
[52] Tunney, P.B., Reeve, J.M.: The Impact of Continuous Improvement on the Design of
Activity Based Cost Systems. Journal of Cost Management (1992) 43-50
[53] von Uthmann, C., Becker, J.: Petri Nets for Modeling Business Processes - Potentials,
Deficits and Recommendations. In: Proceedings of the Colloquium on Petri Net
Technologies for Modelling Communication Based Systems. Berlin 1999 (to appear)
[54] von Uthmann, C., Becker, J.: Guidelines of Modeling (GoM) for Business Process
Simulation. In: Scholz-Reiter, B., Stahlmann, H.-D., Nethe, A. (eds.): Process Modeling.
Berlin, Heidelberg (1999)
[55] van der Aalst, W.M.P., van Heh, K.M.: Business Process Redesign: A Petri-net-based
approach. Computers in Industry 29 (1996) 1-2, 15-26
[56] Wand, Y.; Weber, R.: On the deep structure of information systems. Information Systems
Journal 5 (1995) 3, 203-223
[57] Weber, R.: Ontological Foundations of Information Systems. Coopers & Lybrand
Accounting Research Methodology Monograph No. 4, Melbourne (1997)
[58] Womack, J. P., Jones, D. T., Roos, D.: The Machine That Changed the World: The Story
of Lean Production. Harpercollins (1991)
[59] Zamperoni, A., Löhr-Richter, P.: Enhancing the Quality of Conceptual Database Specifi-
cations through Validation. In: Elmasri, R. A., Kouramajian, V., Thalheim, B. (eds.):
th
Proceedings of the 12 International Conference on the Entity-Relationship Approach –
ER `93. Springer-Verlag, Berlin et al. (1993), 85-98