TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION

LEVELS IN BUSINESS PROCESS MODELING

Ivan Markovic and Florian Hasibether

SAP Research CEC Karlsruhe, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe

Keywords:

Business process modeling, Business ontologies.

Abstract:

In process-driven organizations, process models are the basis on which their supporting process-aware infor-

mation systems are built. In this paper, we propose an approach for integrating perspectives and abstraction

levels in business process modeling. First, we propose six process perspectives to adequately organize infor-

mation about a business process. Second, we present the abstraction levels in process modeling and discuss

metamodel projections on each of the levels. Third, we provide a comparison of our approach to other efforts

in the ﬁeld. With our approach, we make a step towards reducing the complexity of process modeling.

1 INTRODUCTION

In the 1990s, the vision of a process enterprise was

introduced (Hammer and Champy, 1993) to achieve a

holistic view on an enterprise, with business processes

as the main instrument for organizing the operations

of an enterprise (Weske, 2007). Beneﬁts of investing

in business process techniques were demonstrated in

efﬁciency, increased transparency, productivity, cost

reduction, quality, faster results, standardization, and,

above all, in the encouragement of innovation, lead-

ing to competitive advantage and client satisfaction

(Chang, 2005).

Process orientation considered IT as a key enabler

and thus followed with the introduction of process-

aware information systems (PAIS) (Dumas et al.,

2005) as means to support the knowledge workers in

performing business processes. PAIS are driven by

explicit process models, which enable a better under-

standing of business processes, facilitate communi-

cation between business analysts and IT experts and

serve as a basis for the management and execution of

business processes.

Several issues contributed to the fact that the de-

sign of process models is still a complex task. First, a

broad knowledge must be taken into account when de-

signing a process model. This knowledge is scattered

in various business documents, presentations and the

heads of business people, making it difﬁcult to access

and reuse. Second, process modeling approaches do

not adequately support process perspectives (e.g. mo-

tivational, resource, functional, etc.). One of the ways

to reduce modeling complexity is to provide sepa-

rate process modeling perspectives which allow the

modeler to model only the desired aspect of the pro-

cess. Similar approaches can be found in software

design (Nuseibeh et al., 1994). This way of organiz-

ing and modeling of process information is more intu-

itive, easier to understand, analyze and later navigate

the process landscape based on deﬁned perspectives.

Third, there is no support for “abstraction levels” -

enabling different stakeholders to have their view on

a process model by ﬁltering out irrelevant informa-

tion depending on their role. For example, an ex-

ecutive might want to see how does the process re-

late to enterprise goals and strategies, what are its

key performance indicators (KPI) and how well is it

performing. He would not be interested in detailed

process ﬂow, information systems supporting the pro-

cess, business objects manipulated by the process, etc.

Similarly, a line of business manager might be primar-

ily interested in how a particular process contributes

to a broader business scenario, who is responsible for

it and who is involved. Existing modeling tools for

different stakeholders are often not based on a holis-

tic, uniﬁed metamodel which brings many problems

with respect to information integration, redundancies,

traceability and communication between different ab-

straction levels.

On the other hand, Semantic Web (SW) technolo-

gies (Hepp et al., 2005) have shown potential in inte-

grating the knowledge coming from various sources

by means of ontologies (Uschold and Gruninger,

1996). In addition, SW provides concepts and tools

286

Markovic I. and Hasibether F. (2009).

TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION LEVELS IN BUSINESS PROCESS MODELING.

In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Speciﬁcation, pages

286-291

DOI: 10.5220/0002017502860291

 SciTePress

for automated inference on the represented knowl-

edge, which enables the provision of additional ser-

vices based on existing process knowledge.

In order to address the listed issues, we present

an approach for integrating perspectives (Section 2)

and abstraction levels (Section 3) in process model-

ing, supported by ontologies. We compare our ap-

proach to other efforts in the area in Section 4 and

summarize our contributions in Section 5.

2 PROCESS PERSPECTIVES

Following (Curtis et al., 1992; Weske, 2007), we de-

ﬁne six key perspectives to adequately organize infor-

mation about a business process. We visualize them in

ﬁgure 1, motivated by the “orthographic projection”

paradigm used in mechanical and civil engineering

to create detailed drawings of physical objects. The

main idea is to enable the process modeler to eas-

ily manage and navigate the various perspectives in

process design. In the following, we shortly describe

each of them.

Functional perspective provides a functional

breakdown of activities that an enterprise performs.

Starting from high-level business functions (value

chain), the coarse-grained functions are broken down

into ﬁner-grained functional units by means of func-

tional decomposition. Functional decomposition has

proven to be an important concept for capturing and

managing complexity (Weske, 2007).

Motivational perspective is inspired by the recent

OMG speciﬁcation, the Business Motivation Model

(BMM) (OMG, 2008). The notion of motivation is

important for business processes because an enter-

prise should be able to say why it executes a particular

process. This perspective is divided in two segments:

intentional and directional.

The intentional segment captures the enterprise

aspirations - the things it wishes to achieve, i.e. goals.

Every business process exists for the purpose of

achieving some goal, which should be made explicit.

When formulating a process goal it is useful to al-

ready think about quantiﬁable results. The way to do

this is to deﬁne appropriate KPIs along e.g. the dimen-

sions time, cost or quality that measure the process.

The directional segment describes the things that

the enterprise will employ to achieve its goals,

i.e. strategies, business policies and rules. A strategy

shapes the way in reaching a goal, i.e. it channels ef-

forts towards a goal. Business policies and rules con-

trol, guide and shape strategies. With respect to pro-

cesses, it is important to know how a particular busi-

ness process ﬁts into the overall strategy (plan) and

Behavioural perspective

Technology

bjects

edia

Process

Flow

g. Units

Process

Owner

Roles

cess

Compliance

Business

Functions

Process

Activities

Goals

Rules

Strategy

ey Per

ormance

Indicat

ors

licies

Motivational

perspective

nctional per

spective

anizat

onal perspective

Compli

ance perspective

Resource perspective

Figure 1: Process perspectives.

what policies and rules guide (affect) its execution.

Organizational perspective represents by whom

(roles and organizational units) activities are per-

formed. We depict it in ﬁgure 1 by a grouping un-

der the label of stakeholders, encompassing organiza-

tional units, roles and process owners. It is important

to stress that processes run across one or more orga-

nizational units within a functional or divisional hi-

erarchy. A role is deﬁned as task and responsibility

bundle which is clearly distinguished from the per-

son that is performing the role. It can be held by dif-

ferent persons and one person can hold several roles.

Talking about roles and processes allows to easily talk

about the tasks that should belong together or should

be separated from a process perspective before map-

ping them to the organizational structure. The process

owner as an accountable manager for the process end-

to-end execution can be seen as a special role.

Resource perspective describes applications and

resources that should be spent when carrying out cer-

tain process activities (e.g. objects, IT systems, or re-

sources needed in order to accomplish the activity)

or that may be results of certain activities. As pro-

cesses essentially are transformations that manipulate

objects (e.g. create, change or delete) it is relevant to

capture information on these and the states they take

on during transformation. Technology acts as an en-

abler for certain steps in the process. In a tight con-

TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION LEVELS IN BUSINESS PROCESS MODELING

287

Manager

Executive

Business Analyst

Process

Flow

Business

Rules

Compliance

Purpose &

Goal

Strategy

Resources

Objects

Technology

Media

Key

Performance

Indicators

Stakeholders

Process

Owner

Roles

Organizational

Units

Process

Purpose

& Goal

Resources

KPI

Stakeholders

Process

Owner

Roles

Process

Flow

Compli-

ance

Process

Purpose &

Goal

Strategy

Resources

Compli-

ance

KPI

Stake-

holders

Process

Process Flow

Business

Rules

Purpose

& Goal

Resources

Media

Objects

Techno-

logy

Stake-

holders

Roles

Org.

Units

Additional levels

are possible

Additional levels

are possible

Figure 2: Projections of the metamodel.

nection to objects and data are the media used in a

process.

Compliance perspective represents compliance

requirements within process models. Compliance is

of high importance to nowadays businesses. Compli-

ance regulations especially impact processes as spe-

ciﬁc tasks in processes are required in order to fulﬁll

regulatory requirements. Thus, in process design it is

important to capture and incorporate these tasks.

Behavioral perspective captures process control

ﬂow. It represents the logical ordering of process ac-

tivities and their causal interrelationships. This per-

spective could be seen as the core of a process rep-

resentation and acts as a connection point (Weske,

2007) for the other perspectives.

The authors have presented a process-oriented en-

terprise ontology framework which formally captures

all of the aforementioned perspectives (Markovic

et al., 2009; Markovic and Kowalkiewicz, 2008). Us-

ing the speciﬁed relations between the perspectives,

the process modeler can navigate through different

aspects of a process representation and the process

space of an enterprise. Queries such as “What re-

sources are used by process a?”, “What is the goal

of process b?”, “Which processes does the org. unit

c participate in?”, “What processes are currently per-

formed in business function d?”, can be answered us-

ing this ontology framework (Markovic, 2008).

3 ABSTRACTION LEVELS IN

PROCESS MODELING

In this section we discuss abstraction levels in more

detail and motivate why they are important in the con-

text of process modeling.

Executive (Strategic) Level. Here the enterprise

goals and the general strategic direction are set. Key

performance indicators are determined for measuring

the progress in achieving goals. Business policies are

deﬁned in order to govern the enterprise courses of ac-

tion. Typical artifacts on this level may include goal

speciﬁcations, strategy documents and policy guide-

lines (cf. ﬁg. 2, left). Artifacts on this level of abstrac-

tion provide the motivation (“why”) for the processes

within the organization, which are deﬁned on further

levels. The modeling techniques are rather informal

or ad-hoc (ﬂip chart techniques or mind maps).

Line of Business manager Level. Based on the

artifacts produced at the executive level, line of busi-

ness managers need to provide quick and intuitive

overview of the business processes of an organiza-

tion. The aim is to depict processes from a high-level

perspective with a focus on understanding key points

of the process. These high-level processes are called

business scenarios and each of them represents a set

of logically related processes performed to achieve

deﬁned and measurable business goals. Models such

as Value Added Chain Diagrams (Porter, 1985) and

SAP Business Scenarios

are used for this purpose.

Business Analyst Level. Unlike the other two

perspectives, the business analyst faces a variety of

purposes in modeling. This includes business pro-

cess documentation, process improvement, system re-

quirements speciﬁcation, etc. Process models cre-

ated at this level detail each of the business scenar-

ios speciﬁed and serve as a starting point for the un-

derlying information system implementation (cf. ﬁg.

SAP Business Scenarios are delivered with the

SAP Solution Composer, a modeling tool provided by

SAP. http://www.sap.com/solutions/businessmaps/

composer/index.epx

ICEIS 2009 - International Conference on Enterprise Information Systems

288

2, right). There are numerous modeling techniques

(EPC (Keller et al., 1992), BPMN

, UML Activity

Diagrams) used in this space.

A major problem today is that the artifacts pro-

duced on each of the abstraction levels are not inter-

connected and integrated. This causes problems in

communication, inconsistencies, redundancies, trace-

ability between the levels and results in a signiﬁcant

amount of manual work. We argue that the aforemen-

tioned process-oriented enterprise ontology frame-

work can serve as a common metamodel for all ab-

straction levels, as shown in ﬁg. 2. Using metamodel

projection, abstraction level-speciﬁc models can be

derived (cf. ﬁg. 2).

We can think of the process-centric knowledge de-

picted in ﬁg. 2 (center) as being present on each level

of abstraction in smaller or greater detail. Parts of this

knowledge tend to grow stronger as we move down

the abstraction levels, e.g. process ﬂow. Of course,

high level knowledge such as strategic goals and core

strategy plans do not vanish as we reach a level of

higher detail. They get reﬁned and superimposed by

a more concrete view. Strategic goals grow to measur-

able and timed operational goals, strategic directions

to detailed plans, etc. For example, the executive ab-

straction level would encompass strongly concepts re-

lated to the motivational perspective (goals, strategy,

KPIs, etc.), while it would not be interested in de-

tailed process ﬂow, information systems supporting

the process or business objects (cf. ﬁg. 2, left). The

metamodel can be reduced (conﬁgured) to the execu-

tive level-speciﬁc needs and a new model is generated

by metamodel projection.

Using this approach we are also able to derive

abstraction-level speciﬁc models for the line of busi-

ness manager and business analyst levels. By having

a uniﬁed metamodel, the artifacts created in particu-

lar abstraction levels can be more easily traced and

navigated.

4 FEATURE COMPARISON WITH

COMMON METHODS

Sections 2 and 3 motivated different viewpoints that

business process modeling is concerned with. In

this section we build upon these descriptions and de-

ﬁne criteria for a comparison with common modeling

methodologies, both from academia and industry.

http://www.bpmn.org

4.1 Criteria for Comparison

First, we are interested in which part of the process-

knowledge (cf. ﬁg. 1) is covered by the various ap-

proaches. We refer to this criterion as (1) process

perspectives. Section 3 introduced the notion of dif-

ferent (2) levels of abstraction bound to typical roles

in process engineering. Therefore, we secondly in-

vestigate what viewpoints a methodology supports.

Thirdly we deal with what kind of models are pro-

duced, i.e. (3) modeling business knowledge. The last

two criteria discuss the abilities of a methodology to

work with the captured knowledge. Under (4) query-

ing/reuse we ask for what possibilities exist to retrieve

the modeled information, while (5) analysis/inference

asks for: What can be deduced and is not explicitly

modeled? How could weaknesses be detected?

To date there is no predominant modeling ap-

proach for neither enterprise modeling, nor business

process modeling. To give a brief survey on the abil-

ities of today’s modeling techniques we selected the

following, illustrating the broad spectrum of enter-

prise modeling: ARIS (Scheer, 1988), BMM (OMG,

2008), i* (Yu, 1995), TOVE (Fox, 1992).

4.2 Comparative Description

i* framework – The i* framework originates from

“early requirements” research and is used to under-

stand organizational processes, in terms of strategic

relationships and goals in order to elicitate the ratio-

nale for software requirements. Since i* is based on

intentionality, the concept of an actor, i.e. any active

entity, is central. The core work for i* (Yu, 1995) pro-

poses two types of diagrams, capturing the strategic

dependency relationships among actors (SD model)

and the strategic rationale model for expressing the

rationale behind dependencies (SR model). Using SD

and SR models, i* provides two levels of granularity:

The former focusing on the relation between actors,

using dependency links and actor aggregations. The

latter connects hard goals to tasks and softgoals (non-

functional goals) to contributing entities, thereby cap-

turing the agent’s intentions and abilities.

i* has been extended by a number of research ef-

forts

. A formal description for i* has been proposed,

using temporal logic and model checking for anal-

ysis (Fuxman et al., 2004). The approach can de-

tect self-contradictory speciﬁcations, over- and under-

speciﬁcation using a graphical modeling tool

with a

model checker interface. To check the satisﬁability of

http://www.troposproject.org/

http://www.dit.unitn.it/

TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION LEVELS IN BUSINESS PROCESS MODELING

289

i*-like goal models, label propagation techniques and

a SAT solvers are applied (Sebastiani et al., 2004).

The i* framework captures mainly information for

the motivational perspective (cf. ﬁg. 1). Although the

concept of goal and softgoals is rather detailed, there

is no concept of strategy or functional decomposition.

Resources and tasks stay on an abstract level. Since

the notion of actors is fairly general it provides no

speciﬁc means for modeling organizational structures.

Although tasks are important elements of SR model-

ing, there is no sequential connection between them.

The absence of policies/rules and performance indi-

cators underline, that enterprise modeling is not the

main goal of the i* approach. A number of tools are

provided by the i* community

. However, none of

those is capable of querying parts of the model.

BMM – The Business Motivation Model is an

OMG standard accepted in 2006 (OMG, 2008).

While i* stems from software requirements research,

BMM has its roots in the business rules community.

Central to BMM is the distinction between means,

ends, directives, assessments and inﬂuencers.The

ends state, what the business wants to accomplish, not

how. Means are concerned with how the business in-

tends to accomplish its stated ends. Rules and poli-

cies that constrain and/or govern the available means

are called directives. Inﬂuencers capture, who or what

from within or outside the company inﬂuences its ac-

tivities. Assessments judge the impact of inﬂuencers

and provide impetus for directives. Each of these cat-

egories are further reﬁned, with vision as a high level

statement of a state to reach made operative by some

mission. A desired result is either a goal (strategic)

or an objective (quantiﬁed and therefore operational).

Strategies are more general while tactics are more

speciﬁc courses of action. Within directives, business

policies are the basis for business rules. OMG sees

BMM as a blueprint for business planning which is

neutral in respect to methodology. It is not a com-

plete business model, nor is it intended to be one, but

should be supplemented by other standards such as

BPMN and UML and thus deals mainly with the mo-

tivational perspective given in ﬁg. 1.

Xactium

had BizModeler as the ﬁrst prototypic

tool supporting BMM. It allowed for drawing of Mo-

tivation Models from different perspectives using a

subset of the modeling elements in each of them.

The tool provided basic modeling aids regarding valid

linkage of elements. Large models could be searched

via string matching. Like BizModeler, KnowGrav-

http://www.cs.toronto.edu/km/ome/

http://www.cs.toronto.edu/km/openome/

http://www.xactium.com

ity’s KnowEnterprise

mainly focuses on implement-

ing the speciﬁcations in terms of model visualization.

Due to the lack of formality there are limited means

for analysis or inference on BMM models so far.

ARIS – The “ARchitecture of Integrated In-

formation Systems” is a mature, industry-adopted

method for business modeling. To deal with com-

plexity, the so called ARIS house describes differ-

ent views on processes: Organization view: Who

(e.g. organizations, departments, roles) is involved in

the process? Function view: Which functions are

carried out? Data view: Which objects represented

by data are manipulated? Output/Input view: Which

products or services are produced or consumed? Con-

trol view: How do the views mentioned before inter-

operate in a process? (Exeler and Wilms, 2003)

The functional view deals with hierarchical de-

compositions of business functions. A connection be-

tween the former and goal decomposition diagrams

is given in (Scheer, 1999). The organizational view

operates on organization charts. Data objects can be

modeled using Entity-Relationship-Diagrams. Prod-

uct models, either as a decomposition of different

types of product or as parts decomposition are sug-

gested in (Scheer, 1999) for the Output view. Event-

driven process chains (EPC) link the other views to-

gether within the control ﬂow. The initial notation

(Keller et al., 1992) was later updated to extended

EPCs by adding elements for roles, objectives, tech-

nical terms, organizational units, and others. ARIS

adopts Value Chain Diagrams (Porter, 1985) as a

means of modeling high level processes. Although

VCD capture functions which directly create corpo-

rate output, neither them, nor the an EPC ﬂow model

with additional goals elements do capture the entire

motivational perspective (cf. ﬁg. 1). The toolset grad-

ually evolved to several platforms for various model-

ing tasks. It was recently completed by an strategy

approach making use of cause-and-effect diagrams

and KPIs. The designer tool can ﬁlter modeling ele-

ments of a selected model type and provides capabil-

ities to generate reports from the process perspective.

Since all modeled elements are stored in a relational

database it allows for querying model elements and

their related objects (Davis and Brab

ander, 2007).

TOVE – Parallel to the early days of BPM in the

area of information systems, organizational modeling

was approached from knowledge management com-

munities. One of the earliest efforts aiming at the de-

velopment of an organizational ontology is the TOVE

initiative (Fox, 1992). It aims at creation of a shared

representation of the enterprise, deﬁnition of seman-

tics, development of a set of axioms in order to pro-

http://www.knowgravity.com

ICEIS 2009 - International Conference on Enterprise Information Systems

290

vide automatic deduction capabilities and ﬁnally def-

inition of symbols depicting deﬁned concepts. The

ontology underwent a large evolution and the current

versions are focused on multidimensional enterprise

modeling, and was converted into a set of tightly con-

nected sub-ontologies (Fox and Gruninger, 1998) de-

scribing many aspects and different aims. Although

the approach knows the concept of roles within the

enterprise model, it does not provide different levels

of abstraction for its usage. The model of the en-

terprise created in this approach, namely Common

Sense Model of Enterprise, distinguishes three lev-

els: a reference model with typical business functions

(ﬁnances, sales, ...), i.e. the functional perspective, a

generic model (concepts such as time, causality,...),

and a concept model (e.g. role, property, structure),

covering the organizational perspective. The behav-

ioral perspective is formally described using the situ-

ation calculus. Although rich axiomatization is given,

the lack of a contemporary ontology language the pro-

posed concepts are expressed in, is a drawback. Tool

support is another weak point.

5 CONCLUSIONS & OUTLOOK

In this paper, we proposed an approach for integrating

process perspectives and abstraction levels in business

process modeling. We deﬁned the perspectives neces-

sary to capture and organize information about a pro-

cess. Further, we presented different abstraction lev-

els in process modeling. We use a process-oriented

enterprise ontology framework to formally represent

all process perspectives and enable abstraction level-

speciﬁc process modeling views by means of meta-

model projection. Lastly, we provide a comparison of

our approach to inﬂuential work in the ﬁeld. By en-

abling the possibility to create abstraction level- and

perspective-speciﬁc views, we reduce the complexity

of process model design. In addition, using the formal

process representation we can perform querying and

automated inference on business process models.

We are currently working on tool-supported gen-

eration of a perspective and abstraction level-speciﬁc

modeling editor using the process-oriented enterprise

ontology framework.

REFERENCES

Chang, J. (2005). Business Process Management Systems:

Strategy and Implementation. Auerbach Publication.

Curtis, B., Kellner, M., and Over, J. (1992). Process model-

ing. Commun. ACM, 35(9):75–90.

Davis, R. and Brab

ander, E. (2007). ARIS Design Platform.

Springer.

Dumas, M., van der Aalst, W., and ter Hofstede, A. (2005).

Process-Aware Information Systems. Wiley.

Exeler, S. and Wilms, S. (2003). Change management with

ARIS. In Bus. Proc. Change Management. Springer.

Fox, M. (1992). The TOVE project: A common-sense

model of the enterprise. In Proc. IEA/AIE Conf.

Fox, M. and Gruninger, M. (1998). Enterprise modelling.

AI Magazine, 19:109–121.

Fuxman, A., Liu, L., Mylopoulos, J., Roveri, M., and

Traverso, P. (2004). Specifying and analyzing early

requirements in Tropos. Req. Eng., 9(2):132–150.

Hammer, M. and Champy, C. (1993). Reengineering the

Corporation. Harper Business.

Hepp, M., Leymann, F., Domingue, J., Wahler, A., and

Fensel, D. (2005). Semantic business process man-

agement. In IEEE Int. Conf. on e-Business Eng.

Keller, G., N

uttgens, M., and Scheer, A.-W. (1992). Seman-

tische Prozemodellierung auf der Grundlage Ereignis-

gesteuerter Prozeketten. Tech.R., Uni. d. Saarlandes.

Markovic, I. (2008). Advanced querying and reasoning on

business process models. In Proc. BIS08.

Markovic, I., Hasibether, F., Jain, S., and Stojanovic, N.

(2009). Process-oriented semantic business modeling.

In Wirtschaftsinformatik.

Markovic, I. and Kowalkiewicz, M. (2008). Linking busi-

ness goals to process models in semantic business pro-

cess modeling. In 12th IEEE EDOC Conf.

Nuseibeh, B., Kramer, J., and Finkelstein, A. (1994). A

framework for expressing the relationships between

multiple views in requirements speciﬁcation. IEEE

Trans. on Software Engineering, 20(10):760–773.

OMG (2008). Business Motivation Model v1.0. http://

www.omg.org/spec/BMM.

Porter, M. (1985). Competitive Advantage. The Free Press.

Scheer, A.-W. (1988). Wirtschaftsinformatik: Referenzmod-

elle f

ur industrielle Gesch

aftsprozesse. Springer.

Scheer, A.-W. (1999). ARIS. Business Process Modeling.

Springer.

Sebastiani, R., Giorgini, P., and Mylopoulos, J. (2004).

Simple and minimum-cost satisﬁability for goal mod-

els. In Proc. CAiSE 2004.

Uschold, M. and Gruninger, M. (1996). Ontologies: Prin-

ciples, methods and applications. Know. Eng. Rev.,

11:93–155.

Weske, M. (2007). Business Process Management: Con-

cepts, Languages, Architectures. Springer.

Yu, E. (1995). Modelling Strategic Relationships for Pro-

cess Reengineering. PhD thesis, Univ. of Toronto.

TOWARDS INTEGRATING PERSPECTIVES AND ABSTRACTION LEVELS IN BUSINESS PROCESS MODELING

291