A FRAMEWORK FOR ONTOLOGICAL STANDARDIZATION

OF BUSINESS PROCESS CONTENT

Maya Lincoln, Reuven Karni and Avi Wasser

Center for Dynamic Enterprise Modeling

The William Davidson Faculty for Industrial Engineering and Management

Technion, Israel Institute of Technology, Mount Carmel, Haifa 32000, Israel

Keywords: Business Process Management, ERP systems, Ontology Engineering, Process Modeling Concepts and

Information Integration Tools.

Abstract: One of the main challenges currently facing the world of enterprise information technology in general and

ERP/SCM/CRM systems in particular, is visibility into the business of organizations. The prevalent

approach utilizes conceptual business process modeling as the foundation for creating and managing this

visibility, aiming to connect business activity and its supporting information technology. While the

phenomena of devising structural execution frameworks is widespread in academia, there have been few

attempts to develop theory, empirical studies and supporting methods for the structured generation and

customization of complete business process models that also include actual content. These models move

beyond structural data modeling in the sense that they add semantics and relationships of actual business

essence. The research suggests a framework and a set of methods for the organization and structured

ontological construction of business process content.

1 INTRODUCTION

One of the main challenges currently facing the

world of enterprise information technology, and

ERP systems in particular, is visibility into the

business of organizations (Krumbholz and Maiden,

2001). The prevalent approach utilizes conceptual

business process modeling as the foundation for

creating and managing this visibility, aiming to

connect the business activity and its supporting

Information Technology (IT) systems (Holland and

Light, 1999). The current main thrust of business

process Modeling research has been focused on the

study of structural frameworks and execution

patterns (Weske et al., 2004), putting less emphasis

on the content layer that is supposed to populate

these frameworks. “Real life” business process

models, which contain practical content objects,

have been disregarded, except in illustrative

examples (Malone et al., 2003). Structural process

frameworks define formal architectures and

standards for representing business activities and

processes. The spectrum ranges from simple

descriptive frameworks such as activity diagrams,

suitable mostly for business users, through more

formal frameworks such as OPM (Dori and

Reinhartz-Berger, 2003), and Petri-nets (van der

Aalst et al., 2003) suitable mostly for software

implementers and IT system analysts, to code-

compatible structures such as BPEL and XLANG

(van der Aalst et al., 2003) suitable for software

developers.

We were able to locate, only a few scientific

publications addressing the topic of business process

content (Dellarocas and Klein, 2000), (Bernstein,

2003), (Malone, 2004), (Wasser et al., 2005). On the

other hand the initiative has been taken and business

process content was developed and applied, by

enterprise software vendors, IT integrators, and

BPM commercial firms. We divide this content into

three main types: (a) particular, enterprise specific

content; (b) vendor/integrator content such as the

OBM (Oracle Business Models) library and SAP

solution maps and (Wasser et al. 2005). (c)

collaborative/consortia content frameworks such as

OAGIS, SCOR and RosettaNet. (Wasser et al.

2006). Modeling in this context focuses on the

content layer of business process models.

We define the content layer as the itemization of

the suite of actual business processes constituting the

257

Lincoln M., Karni R. and Wasser A. (2007).

A FRAMEWORK FOR ONTOLOGICAL STANDARDIZATION OF BUSINESS PROCESS CONTENT.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 257-263

DOI: 10.5220/0002393902570263

 SciTePress

framework of business-related activity within a

particular industrial sector, or, alternatively, within a

particular enterprise.

Thus, while the phenomena of formulating

structural execution frameworks is widespread in

academia (van der Aalst and Hofstede, 2005) there

seem to be few attempts to develop theories,

empirical studies and supporting tools (Wasser et al.,

2005) (such as generation, customization, validation

and search mechanisms) for “complete” business

process models which incorporate an actual content

layer (Figure 1).

Figure 1: A process model as a combination of structure

and content layers

When the current research addresses business

process models it refers to “complete” models that

also include a content layer, so that the combination

of structure and content can display the actual suite

of business processes constituting the framework of

activity within the enterprise and enable subsequent

implementation through IT. For example: a

flowchart describing bottleneck leveling in

production, or a Petri-net describing the process of

managing a service request in a CRM process. Note,

that such business process models include a large

number of "real" interconnected objects (processes,

roles, events, related data, etc.). Complexity

increases when the models are to be expressed and

actualized by a corresponding IT system (e.g.

ERP/SCM/CRM), which requires verification and

validation of the business process models from a

functional and managerial point of view prior to

actual implementation and subsequent execution.

To confront this complexity, and in order to

enable effective handling of the business process

models content layer, this research suggests a

formalized framework and tools for business process

content generation and customization.

In section 2, we review the literature in the field

of business process generation. Section 3 suggests

two original models for the generation and

customization of business process content. Section 4

presents a method and related algorithm for the

standardization of business process content, and

section 5 concludes this research, and mentions

topics for future work.

2 CONSTRUCTION OF

BUSINESS PROCESS MODELS

Modeling the business processes of an enterprise is

an essential part of any IT development or

implementation process (Holland and Light, 1999).

It allows the analyst to capture the broad outline that

governs what a business does (Rolland and Prakash

2000). A paper analyzing “business process

reference models” (Fettke et al., 2005) refers to

process models that include a content layer as

“reference models” – “that represent dynamic

aspects of an enterprise, e.g. activity sequences,

organizational activities required to satisfy customer

needs, control flow between activities, particular

dependency constraints, etc.”. Since structural

frameworks can also be referred to as “reference

models” without containing any content, the terms

“reference model” or “generic model” may be

confusing (Compare (Becker et al., 2000) and

(Weske et al. 2004)).

To clarify this point, this research asserts that

actual business process models (that are otherwise

referred to as business process reference models,

universal process models, generic process models,

process model patterns, meta-process models,

process repositories, best practices, process

guidelines, and so on) are process models that

include a content layer. These models move beyond

structural data modeling in the sense that they add

semantics (meaning) and relationships of actual

business data. When the current research addresses

business process models it refers to “complete”

models that include an actual content layer, so that

the combination of structure and content can display

a real suite of business processes constituting the

framework of activity within an enterprise and

enable subsequent implementation through IT.

2.1 Incorporating Content within

Structure: The Formulation of

Actual Business Processes Models

The lack of suggestions for standard structure,

terminology and tools for the process content layer

has restricted the development of a “content

modeling science”, leaving it mostly to commercial

organizations (Wasser et al. 2005). Presumably,

professionals have developed business process

repositories on the basis of experience accumulated

through analyzing business activity and

implementing IT systems in a variety of industries.

This has led to a paradigm whereby these content

frameworks are presented as generic – i.e. typical for

an industrial sector or even cross-industrial (e.g.

SAP’s “Aerospace Industry” or “Human Capital

Structural Framework

Content

Structural Framework

Content

ICEIS 2007 - International Conference on Enterprise Information Systems

258

Management” Business Solutions). However, the

existence of many reference models, that vary

significantly between ERP developers, even for a

given sector, indicates a lack of scientific

systematization in developing such models and

raises the question as to whether these models

actually constitute generic prototypes.

For convenience, we have organized the

literature review on business process models into

three sections: (a) particular, enterprise specific

business process models; (b) vendor/integrator

defined commercial business process models; and

consortia/professional organizations and research

frameworks.

(a) Enterprise Specific Business Process

Models: These are usually developed and exploited

for internal organizational purposes and are not

openly accessible as they contain detailed

proprietary knowledge and know-how of how the

organization is operated and managed. A large

variety of modeling techniques are used to gather

information from key users about activities,

resources and business rules. We have located two

examples of such models: Siemens AG (Rohloff,

2002) and a Global financial institution (Maddern,

and Maull, 2003). The financial institution

completed a process modeling project as part of a

BPR (Business Process Re-engineering) initiative.

At the heart of the program was the development of

a Business Process Framework (BPF) - a three-level

process decomposition model. As part of the overall

program, a sub-project was initiated to develop a

process dictionary, with the following requirements:

(a) to interface with process maps and associated

process data and documentation; (b) to interface

with the process repository; (c) to move towards

prescribed process definitions; and (d) enable

flexible interrogation of the BPF and process

repository. Some 370 verbs were identified and

defined (such as "advise", "allocate"…). Each verb

was then coupled with a set of corresponding

business entities, forming the basis for 850 process

descriptions (such as "Advise of stopped payments"

or “Allocate to cashiers”). This example

demonstrates how a generic action dictionary was

developed for assisting the formation of a business

process model, presenting: (a) a common language

and architecture for better defining and

understanding processes; (b) a checklist to ensure

that all approved central processes are identified and

implemented (c) a building block for an organizing

mechanism for process management.

(b) Commercial Vendor/Integrator Defined

Business Process Models: These include, for

example, SAP’s industry and cross-industry

Business Solution Maps, Intentia’s ERM (Enterprise

Reference Models), and Oracle’s OBM (Oracle

Business Models) library (Lincoln and Karni, 2003).

In the SAP business solution maps, for example, the

top level “solution map” for an industrial sector

presents names and descriptions of the high level

functionalities for that industry (about 8), and the

corresponding main functions (about 7) for each

major function. From these categorizations vendors

and integrators develop a suite of processes,

reflecting what an enterprise does, or needs to do, to

achieve its objectives, as illustrated in Table 1.

Table 1: Process hierarchy based on the SAP solution

maps.

(1) Solution = “Procurement” (top level)

(2) High level flow = “Purchasing” (second level

of categorization)

(3) Process scenario = “Purchase Order

Management” (third level)

(4) Process = “Issue purchase order to local

supplier” (fourth level)

Commercial process models are based on the

assumption of significant similarity between

enterprises that operate within a certain industry.

Oracle corporation for example, offers process flows

that cover 19 industrial branches; SAP offers

Business Solutions for 24 industrial branches; and

other ERP/SCM/CRM vendors similarly base their

business models on a finite set of predefined

business processes, that comprise (Karagiannis and

Kühn, 2002) “industry-specific” reference models.

In summary, the research into commercial business

process models has introduced several concepts: (a)

the idea of generic reference industry-related

business process models; (b) the idea that a specific

enterprise process model is a sub-set of a generic

reference business process model; and (c) the idea

that the process model interconnects the business

and IT layers.

C.1. The MIT Process Handbook (PH) (MIT Process

Handbook (Retrieved June 2006, www.mit.edu/ph)

is a repository of business process knowledge that

has been under development at the MIT for over ten

years, (Malone, 2004), (Kankanhalli and Tan, 2005).

The PH aims to present a model of “everything that

goes on in a business”. It features five high level

basic activities that occur – in some form – in most

businesses: 'Buy’, ‘Make’, ‘Sell’, ‘Design’, and

‘Manage’ The PH also includes a set of six different

business model “archetypes” that companies can use

(rather than an industrial categorization) and a small

number of models developed by other organizations:

A FRAMEWORK FOR ONTOLOGICAL STANDARDIZATION OF BUSINESS PROCESS CONTENT

259

International Benchmarking Clearinghouse (APQC)

Process Classification Framework (271 activities),

Supply Chain Operations Reference (SCOR) Model

(215 activities), Lean Enterprise Manufacturing

Model (72 activities), European Foundation for

Quality Management (EFQM) Model (30 activities),

Xerox Management Model (51 activities).

C.2 The Operative BP repository. The

“BPM Company” (a fictitious name to preserve

confidentiality) is a unique participant in the Global

Business Process Management (BPM) market due to

its emphasis in connecting BPM with ERP systems.

The company has developed an extensive

categorized compendium of business processes,

including items from the principal ERP/CRM/SCM

vendors. This has resulted in a repository of over

6,500 business processes, which we term “The BP

repository”.

The descriptors represent actual processes

implemented, or intended to be implemented, in

customer organizations. The BP repository has the

following aims: (a) rapid design and generation of

an enterprise-specific business process model; (b)

rapid comparison of an enterprise-specific model

with a vendor offering; and (c) the ability to update

an enterprise-specific model and to guide changes in

the ERP/CRM implementation.

The BP repository is a five-level model: (a)

process category (e.g. human resource

management); (b) major process (e.g. employee

recruitment); (c) main process (e.g. vacancy

management); (d) basic process (e.g. talent pool

management); and (e) activity (e.g. the “process

flow” of activities involved in managing a talent

pool such as adding an entry to the pool). It

encompasses: 9 process categories, 100 major

processes, 500 main processes, 6,500 basic

processes and over 16,500 activities.

Table 2: Terminology for process hierarchy levels in the

BP repository.

(1) Category = “Procurement” (top level of

categorization)

(2) Major process = “Purchasing” (2

level of

categorization)

(3) Main process = “Purchase Order

Management” (3

level of categorization)

(4) Process = “Issue PO to local supplier” (4

level of categorization)

(5) Activity = “Sign the PO” (5

level)

It is thus highly representative of and

characterizes a wide range of business process

models implemented in the ERP/CRM/SCM world.

The BP repository uses the following hierarchy

levels (Table 2).

This categorization is used to characterize the

totality of business processes that constitute a

complete business process model, and the

descriptors of the processes in the repository are

identical to those of the vendors. When the process

is included in the repertoire of several vendors, one

of the descriptors has been chosen as representative,

and the others have been stored as “vendor variants”

elsewhere in the repository. The principle adopted in

selecting processes for inclusion in the repository

was that these are processes which exist in the

business models provided by the vendors. The

following sections are aimed at demonstrating (a) a

standardized format for describing the content of a

business process (business process descriptors); (b) a

taxonomy for classifying and characterizing business

processes based on current offerings of ERP vendors

that can assist in the generation and customization of

business process models.

3 MODELS

In order to formulate, demonstrate and evaluate the

proposed framework along with its underlying

theories, we present two methodological models that

organize the business process data and form the

foundation for content construction and

customization.

3.1 Process Descriptor Decomposition

Model

This model introduces the basic ideas and notations

for formally representing business process model

content objects by a hierarchal graph of descriptors,.

The model contains n levels of process hierarchy

, L

, … , L

). At each level, each process is

represented by a process descriptor, and each

process descriptor consists of one action, one object

that the action acts upon, and possibly one or more

action qualifiers, object qualifiers and means. For

example, a process descriptor can be defined as:

“Issue confirmed purchase order to local supplier by

e-mail”, comprising the following linguistic units:

(1) Action (A) = “Issue”; (2) Action Qualifier (AQ)

= “to local supplier”; (3) Object (O) = “Purchase

order”; (4) Object Qualifier (OQ) = “confirmed”; (5)

Means (M) = “e-mail”.

3.2 Business Action and Object

Taxonomy Model

This model organizes a set of process descriptors,

attempting to determine the relationships between

ICEIS 2007 - International Conference on Enterprise Information Systems

260

business actions and objects both longitudinally

(hierarchically) and latitudinally (in terms of

execution order). In this model an action is related to

an object by an operability connector, e.g. the action

“receive” is related to the object “invoice”.

Longitudinally- the action “issue” is considered a

subclass (a more specific form) of “produce”, and

the object “purchase order” is a subclass of

“purchasing document” (note that the operability

connectivity applies also to relations between

different hierarchy levels). Latitudinally, each object

holds: (a) a list of ordered actions that are applied on

that object (e.g. the object “product” is related to the

actions “plan” followed by “produce”); (b) a list of

ordered objects that express the object lifecycle (e.g.

the following lifecycle sequence: “raw material”Æ,

(…)Æ, “product”Æ, (…)Æ, “returns”Æ, (…)). In

addition, each action and each object holds a pointer

to its qualifiers. These longitudinal and latitudinal

viewpoints contribute another dimension for

analyzing and learning the business process model

content layer in terms of identifying action and

object hierarchies and execution sequences, as

further illustrated in section 4.

4 METHOD

4.1 Standardization of Business

Process Content

This method is carried out in two phases: (a)

standardizing the BP repository process descriptors;

and (b) organizing the standardized process

descriptors into action and object taxonomies. The

result is a standardized Process Descriptor Catalog

(PDC).

Phase 1: Converting BP Repository Data into

Standardized Process Descriptors: The

standardization of process p

into a set of process

descriptors PD

is executed below, using the

following notation: At any hierarchal level, an

original process name, p

, from the BP repository is

represented as a tuple t

={A

, O

, AQ

, OQ

, M

, OT

}

in which: (a) A

∈p

- a set of process actions; (b)

∈p

- a set of process objects; (c) AQ

∈p

- a set of

process action qualifiers; (d) OQ

∈p

- a set of

process object qualifiers; (e) M

∈p

- a set of process

means; (f) OT

∈p

- a set of other descriptor

components that may be discovered during the

analysis of the complete BP repository.

DU – a set of process descriptor units. The algorithm

starts with the set DU={1 action, 1 object, 0…n

action qualifiers, 0…k object qualifiers, 0…p

means}. This set can be expanded as we expect to

find more descriptor components during the analysis

of the complete BP repository.

Algorithm 1: Standardize a process description into a

business process descriptor.

Input: p

- an original process

description from the BP repository

Output: (1) PD

– a corresponding list of

process descriptors {pd

, …, pd

∪pd

∪…∪pd

express p

(2) A new set: DU

new

⊇DU

decompose p

to receive the tuple t

, O

, AQ

, OQ

, M

} according to

the components in DU

2: if (the # of elements in A

) > 1 then

split t

into a set of s tuples T

= {t

, …,

} | s = the number of elements in A

and ∀q∈{1,…,s}: t

= {a

∈A

, O

, AQ

, M

}

end if

if (the number of elements in O

) > 1

then

∀t

∈T

: split into a set of w tuples (t

iq1

…, t

iqw

) | w = the number of elements in

, and ∀p∈{1,…,w}:t

iqp

= {a

, o

∈O

, OQ

, M

}

end if

if p

contains elements that cannot be

expressed by any of the linguistic units

in DU then

Define an additional linguistic unit and

add it to DU

10:

end if

11: PD

= a list of all split tuples

12: return PD

, DU

Phase 2: Generation of Business Action and

Object Taxonomies: The goal of this phase is to

organize the standardized business process

descriptors into a Process Descriptor Catalog (PDC)

that comprises: (a) process descriptor component

hierarchies; (b) action execution sequences (e.g.

plan->approve->make->check->deliver->maintain);

>work in process->assembly parts->finished goods-

>delivered goods->returned goods.

This organization is carried out using the

following steps:

1. Organizing the action hierarchy: (a) Performing

clustering analysis on all actions in the process

descriptors set (the process descriptors’ actions

constitute the bottom level taxons of the action

taxonomy); (b) Defining, by identifying some

common characteristics among actions that

participate in the same cluster, the cluster’s

A FRAMEWORK FOR ONTOLOGICAL STANDARDIZATION OF BUSINESS PROCESS CONTENT

261

characterizing action that functions as a cluster

key. The defined cluster keys constitute second

level taxons of the action taxonomy; (c)

Performing a further cluster analysis based upon

the second-level taxons; (d) Iterating as long as

meaningful taxonomic levels are created

2. Organizing all other process descriptor

linguistic units (object, action qualifier, etc.) by

following the above four steps.

3. Coupling actions to objects that originally

formed part of the same process descriptor

4. Delineating the action sequence for each object:

(a) Expressing the actions that operate on each

object using a graph structure, including related

decisions that can split a sequence into more

than one possible paths; (b) Creating a link

between the object and its action sequence

5. Delineating an object lifecycle sequence: (a)

Articulating a sequence of names that refer to

the same object in different processing stages

using a graph structure, including any related

decisions; (b) Creating a link between each

object and the object lifecycle sequence in

which it participates

5 FRAMEWORK BASED

CONTENT GENERATION

5.1 Content Generation Method

The framework models and the PDC knowledge

base described in section 3 can be used as a basis for

new content generation for business process models.

The method for adding a new business process

within an existing business process model (e.g. an

ERP vendor’s off-the-shelf model) includes the

following phases:

1. New process definition using a process

descriptor template – e.g. adding a new process

for “receiving finished goods to the inventory

using barcode scanner”, is carried out by

choosing relevant values from the process

descriptor template (e.g. action = plan/ make/

approve/ check/ monitor/ …; object = order/

material/ contract/…; means = e-mail/ train/

barcode/ meeting/…)

2. Process lookup – checking if the defined

process (“p

new

”) already exists in the enterprise

model, by analyzing its descriptor. This phase

includes searching for similar processes in the

model. We define similarity as follows:

“p

existing

” is similar to “p

new

” if it satisfies at least

one of the following conditions: (a) p

new

and

existing

have identical process descriptors; (b)

existing

’s descriptor is a synthesis of p

new

’s

synonyms; (c) p

existing

is a superclass (a more

general description) of p

new

. Generally speaking,

existing

is a superclass of p

new

, if the procedure

involved in executing p

new

is contained in

existing

. This relationship can be identified

within the action and object hierarchies in the

BP repository. For example, the process

“approve payment for suppliers” is a superclass

of “approve payment for material suppliers”,

since “material supplier” is a subclass (a more

generalized form) of “supplier” in the object

hierarchy. If “p

new

” already exists in the

enterprise model, return its equivalent process;

else – continue.

3. Context lookup - identifying possible triggers

and subsequent processes for “p

new

” by

searching for processes that contain predecessor

and successor actions and/or objects within the

PDC.

4. Content lookup - identifying reference

processes for the construction of p

new

’s content

(activities, decisions, related data, involved

roles, activities flow). Such reference processes

are, for example, subclasses or superclasses of

new

, or processes that share the same action

(“A1”) operating on a different object (“O2”),

or the same object (“O1”) related to a different

action (“A2”). The closest distance between A1

and A2 or O1 and O2 (as defined in the PDC’s

object and action hierarchies) – shows increased

similarity between the processes. For example,

we can learn what activities are involved in the

process “prepare order” by checking the

activities that take part in the process “change

order” – since they both involve handling an

order’s data , as well as order related decisions,

and approvals.

5. Content suggestion preparation - synthesizing a

suggestion for p

new

’s content, including

triggering and subsequent processes, involved

activities and their execution sequence, involved

roles, related data and relevant events.

6 SUMMARY

Business process content is the fundamental basis

for the modeling, implementation and operation of

business processes. Content describes what the

business does (“purchase”, “plan”, “approve”) – the

itemization of the suite of actual business activities

or processes expressed as a compendium of business

process descriptors which constitute the compass of

activity of a specific enterprise or a particular

ICEIS 2007 - International Conference on Enterprise Information Systems

262

industrial sector. We have presented a framework

for the formulation, formalization and exploitation

of such business process content by: (a)

decomposing the descriptors of actual business

processes – compiled from vendor suites into

constituent actions, objects, qualifiers, etc.; (b) by

recombining and reordering these constituents – and

adding others where necessary - to create a

standardized process content in the form of content

descriptors and related terminologies; (c) using the

standard descriptors to represent and locate the

process both in a vertical hierarchy of business

categorizations and in a horizontal sequence of

business activities and business object lifecycle

transformations; (d) using the sequences derived

from a large repository of business processes to

locate and position other processes preceding or

succeeding a given process; and (e) thereby create a

basis for obtaining a complete and consistent set of

processes – i.e. a complete business process model –

for a given enterprise. It is hoped that, in this way,

practitioners will be able to generate complete and

consistent enterprise-specific business process

models as part of their services to ERP/CRM/SCM

user communities.

REFERENCES

van der Aalst W.M.P., ter Hofstede A.H.M., and Weske

M.. (2003). BPM 2003, volume 2678 of Lecture Notes

in Computer Science, pages 1-12. Springer-Verlag,

Berlin.

Karagiannis D., Kühn H. (2002). MetaModeling

Platforms. Proceedings of the Third International

Conference EC-Web 2002, volume 2455 of Lecture

Notes in Computer Science, page 182. Springer-

Verlag, Berlin.

Lincoln M., Karni R. A (2003) Generic Business Function

Framework for Industrial Enterprises. CD Proceedings

of 17th ICPR Conference, Blacksburg, VA, USA.

Holland C.P., Light B.. (1999). A critical success factors

model for ERP implementations, IEEE Software

Volume 16, pages 30–35.

Krumbholz M., Maiden N.. (2001). The implementation of

enterprise resource planning packages in different

organizational and national cultures, Information

Systems 26, page 185–204.

Rolland C., Prakash N.. (2000). Bridging the gap between

organizational needs and ERP functionality,

Requirements Eng. 41 180–193.

Becker J., Rosemann M., von Uthmann C. (2000).

Guidelines of Business Process Modeling. BPM2000:

30-49

Fettke, P.; Loos, P.; Zwicker, J. (2005). Business Process

Reference Models - Survey and Classification. In:

Kindler, E.; Nottgens, M.: Business Process Reference

Models – BPRM2005: 1-15.

van der Aalst W.M. P., ter Hofstede A. H. M., Weske M..

(2003). Business Process Management: A Survey.

BPM2003: 1-12

Weske M., van der Aalst W. M. P., H. M., Verbeek W.

(2004): Advances in business process management.

Data Knowl. Eng. 50(1): 1-8

van der Aalst W. M. P., ter Hofstede A. H. M.. (2005).

YAWL: yet another workflow language. Inf. Syst.

30(4): 245-275.

Dellarocas C., Klein M. (2000): A Knowledge-Based

Approach for Designing Robust Business Processes.

BPM2000: 50-65

Bernstein A. (2003) Process Recombination: An Ontology

Based Approach for Business Process Re-Design. SAP

Design Guild, Vol. 7.

Malone, T. W., Crowston, K. G., & Herman, G. (2003).

Organizing Business Knowledge: The MIT Process

Handbook. Cambridge, MA: MIT Press.

Malone, T. W. (2004). The Future of Work: How the New

Order of Business Will Shape Your Organization,

Your Management Style, and Your Life. Boston, MA:

Harvard Business School Press.

Wasser A., Lincoln M., Karni R., (2005). Accelerated

Enterprise Process Modeling Through a Formalized

Functional Typology. BPM2005: 446-451.

Wasser A., Lincoln M., Karni R., (2006): ERP Reference

Process Models: From Generic to Specific. Business

Process Management Workshops 2006: 45-54

Dori D., Reinhartz-Berger I. (2003). An OPM-Based

Metamodel of System Development Process.

Proceedings of ER 2003: 105-117.

Rohloff, M. (2002). Das Prozessrahmenwerk der Siemens

AG: Ein Referenzmodell für betriebliche

Geschäftsprozesse als Grundlage einer systematischen

Bebauung der IuK-Landschaft. In::

Wissensmanagement mit Referenzmodellen: Konzepte

für die Anwendungssystem- und

Organisationsgestaltung. Physica-Verlag, Heidelberg

227-235.

Maddern, H. and Maull, R. (2003). Second generation

process thinking: a case study from UK financial

services, Paper No. 03/07, Research Discussion

Papers in Management, School of Business and

Economics, University of Exeter, UK.

MIT Process Handbook (Retrieved June 2006).

www.mit.edu/ph.

Kankanhalli, A., and Tan, B.C.Y. (2005). Knowledge

Management Metrics: A Review and Directions for

Future Research. International Journal of Knowledge

Management (1:2), 20-32.

A FRAMEWORK FOR ONTOLOGICAL STANDARDIZATION OF BUSINESS PROCESS CONTENT

263