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
Copyright
c
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
(c) other business process models supported by
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) Other Business Process Models
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
nd
level of
categorization)
(3) Main process = “Purchase Order
Management” (3
rd
level of categorization)
(4) Process = “Issue PO to local supplier” (4
th
level of categorization)
(5) Activity = “Sign the PO” (5
th
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
1
, L
2
, … , L
n
). 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
i
into a set of process
descriptors PD
i
is executed below, using the
following notation: At any hierarchal level, an
original process name, p
i
, from the BP repository is
represented as a tuple t
i
={A
i
, O
i
, AQ
i
, OQ
i
, M
i
, OT
i
}
in which: (a) A
i
p
i
- a set of process actions; (b)
O
i
p
i
- a set of process objects; (c) AQ
i
p
i
- a set of
process action qualifiers; (d) OQ
i
p
i
- a set of
process object qualifiers; (e) M
i
p
i
- a set of process
means; (f) OT
i
p
i
- 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
i
- an original process
description from the BP repository
Output: (1) PD
i
– a corresponding list of
process descriptors {pd
1
, …, pd
m
}|
pd
1
pd
2
pd
m
express p
i
(2) A new set: DU
new
DU
1:
decompose p
i
to receive the tuple t
i
=
{A
i
, O
i
, AQ
i
, OQ
i
, M
i,
OT
i
} according to
the components in DU
2: if (the # of elements in A
i
) > 1 then
3:
split t
i
into a set of s tuples T
i
= {t
i1
, …,
t
is
} | s = the number of elements in A
i
,
and q{1,…,s}: t
iq
= {a
iq
A
i
, O
i
, AQ
i
,
OQ
i
, M
i,
OT
i
}
4:
end if
5:
if (the number of elements in O
i
) > 1
then
6:
t
iq
T
i
: split into a set of w tuples (t
iq1
,
…, t
iqw
) | w = the number of elements in
O
i
, and p{1,…,w}:t
iqp
= {a
iq
, o
ip
O
i
,
AQ
i
, OQ
i
, M
i,
OT
i
}
7:
end if
8:
if p
i
contains elements that cannot be
expressed by any of the linguistic units
in DU then
9:
Define an additional linguistic unit and
add it to DU
10:
end if
11: PD
i
= a list of all split tuples
12: return PD
i
, 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);
(c) object lifecycle sequences (e.g. raw material-
>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
p
existing
have identical process descriptors; (b)
p
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,
p
existing
is a superclass of p
new
, if the procedure
involved in executing p
new
is contained in
p
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
p
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