Advances in Information Systems and Management Science Michael zur Muehlen

In dieser Reihe erscheinen ausgewählte Schriften aus der Wirtschaftsinformatik

und der Betriebswirtschaftslehre. Sie stellen sowohl theoretisch fundierte Ergeb-
nisse als auch deren Anwendung auf praxisbezogene Fragestellungen vor.

Workflow-based
Workflow-based Process Controlling Systems provide companies with the
ability to measure the operational performance of their business processes in a
timely and accurate fashion. The combination of workflow audit trails with data
Process Controlling

Workflow-based Process Controlling

warehouse technology and operational business data allows for complex analyses
that can support managers in their assessment of an organization’s performance.
The increasing maturity of business process management and data warehouse
systems enables the design and development of advanced process-oriented
management information systems.
Foundation, Design,
Michael zur Muehlen discusses the integration of workflow audit trail data with and Application of Workflow-driven
existing data warehouse structures and develops a reference architecture for
process-oriented management information systems. Starting with an Process Information Systems
organizational and technical analysis of process organizations, this book provides
a comprehensive documentation of business process management, workflow
technology, and existing standardization efforts. The proposed reference
architecture is validated in an industry context. A prototypical implementation of
the reference architecture and its integration with a commercial business process
management system are demonstrated as well.

Advances in Information Systems

This book is directed at both practitioners and academics in the fields of business
process management, management accounting, and information systems.

and Management Science

Michael zur Muehlen is Assistant Professor of Information
Systems at Stevens Institute of Technology in Hoboken, NJ,
USA, where he directs the SAP/IDS Center of Excellence in Hier ein 23x33 mm Bild
in den 25x35 mm freien
Business Process Innovation. Michael is an active contributor to Bereich einfügen (1mm
several standardization groups in the workflow domain, and a Sicherheitsabstand zu
den Seiten)
director of the AIS special interest group on Process Michael zur Muehlen
Automation and Management.

Logos Verlag Berlin

ISBN 3-8325-0388-9 ISSN 1611-3101

Michael zur Muehlen

Workflow-based Process Controlling

Foundation, Design, and Application

of Workflow-driven Process Information Systems
D 6 2002

Erster Berichterstatter: Prof. Dr. Jörg Becker

Zweiter Berichterstatter: Prof. Dr. Edward A. Stohr
Dekan: Prof. Dr. Gerhard Schewe
Tag der mündlichen Prüfung: 17. Juli 2002
Foreword of the Editor -I-

Foreword of the Editor

The process-oriented design of organizations has been subject of the business administra-
tion literature for more than 70 years. While numerous approaches for the implementation of
process-oriented organizations exist, the methods and instruments of enterprise controlling are
mostly aligned with functionally structured organizations. The design of enterprise-wide pro-
cess controlling systems is hindered by the difficult sourcing of information about the opera-
tive execution of business processes.
Workflow management systems offer a solution to this problem. They support process-ori-
entation through the automated coordination of activities, data, and resources. This coordina-
tion is based on a formal representation of the process to be automated, a workflow model,
which is specified in the build time environment of the system. During the operation of a
workflow management system, workflow instances are created from the workflow model and
their execution is controlled through workflow enactment services. During the execution of
workflow instances, traces of each instance are written to a process protocol, the so-called audit
trail, recording the behavior of each instance. This audit trail represents a detailed and precise
collection of data about the operative process enactment within a company.
The use of audit trail data for process controlling purposes has only been analyzed partially
in the literature. Two of the missing pieces are an operational approach to integrate this type of
data into an existing controlling infrastructure, and an assessment, which controlling methods
and instruments can be applied to the analysis of this data. The success of the emerging fields
of Business Intelligence and Business Activity Monitoring relies on a solution to these prob-
lems.
Michael zur Muehlen addresses several important questions in this context. How can man-
agement understand and control automated work processes? How can highly regarded man-
agement control techniques such as Activity-based Costing (ABC) and Balanced Scorecard
(BSC) be implemented and automated through the information logged by a workflow manage-
ment system? What is the data and systems architecture for such advanced control systems?
Can such systems be implemented in practice?
Positioned at the intersection of business administration and information systems, this is an
important and original work. Based on an extensive investigation of existing workflow technol-
ogy and standards, Mr. zur Muehlen's dissertation contains the most thorough and compre-
hensive investigation of the problem of achieving organizational control through automated
work systems. Extensive automation of work is inevitable. The ideas developed by Mr. zur
Muehlen should therefore have lasting impact on management theory and practice.
Münster, June 2004 Prof. Dr. Jörg Becker
- II -
Foreword - III -

“How much time does it take to write a scientific paper? As much time as you have.”
Jeffrey V. Nickerson

Foreword
In early 1995 I was a graduate student at the University of Münster, when Michael Rose-
mann - then senior lecturer in Münster - offered a seminar on workflow management technol-
ogy. Curious as I was, I enrolled in the seminar, and soon I found myself analyzing the meta
models of workflow management tools such as FlowMark, LEU, WorkParty, and CSE Work-
Flow. I got hooked and - in retrospect - this seminar changed my life.
Almost ten years later, business process management and automation is still a hot research
topic, even though three out of the four systems we analyzed back in 1995 disappeared from
the market. The design and deployment of information systems for the automated coordina-
tion and enactment of business processes have proven to be popular topics, both in the aca-
demic and popular literature. Nevertheless, the majority of workflow-related publications are
driven by technical considerations. A fundamental analysis of the impacts this technology has
on organizations, their structure, and their management processes is still missing. This book is
a first step to fill this gap. It is looking at workflow through a managerial lens, studying the role
of process-enabled information systems for management decision making. In essence, we dis-
cuss the integration of process-related audit data into management information systems, and
the decisions managers can make based on this information.
It took me almost two years to rewrite this book from its original format as a dissertation
and to finally release it for publication. Going over the material, I noticed two things. First: Jeff
Nickerson’s assertion about the duration of the academic publication process is correct. Sec-
ondly: Within two years, the standards that were originally discussed in the third chapter of this
book have largely evolved; some have merged, and new ones have entered the marketplace. For
this reason, this book has to strike a balance between the description of current developments
and the explanation of fundamental concepts. I hope this balance has been maintained.
Although this book is a monograph, many people contributed to its creation. I was fortu-
nate to be surrounded by some very bright and talented people who allowed me to bounce
ideas back and forth, and who provided a test bed for some of the more academic concepts
developed in this book. Their ideas, inspirations, and comments have hopefully improved the
quality of what you are about to read. I appreciate the assistance of all these people in helping
me create this book. Should you notice any mistakes - they, of course, are all my own. Should
you feel inclined to send questions or comments, I will be more than happy to answer to feed-
back sent to michael@workflow-research.de. Eventual errata will be documented at the web address
http://www.workflow-research.de/Publications/Book/Errata.
I am extremely grateful to Prof. Dr. Jörg Becker, who provided me with an unparalleled
amount of freedom for my research work. He allowed me to present my ideas at numerous
national and international conferences, and was open to pursue new ideas in every area I wan-
dered in. He also provided timely encouragement and useful criticism of the concepts. Thank
you for five great years.
- IV - Foreword

Prof. Edward A. Stohr agreed to co-supervise this work. I am incredibly indebted to him for
his methodical insights, topical guidance, and critical discussions of the contents presented in
this book. In addition, he has opened many doors in the American academic community for
me that otherwise might have remained closed. He offered me to join Stevens Institute of
Technology, where I look forward to our continued collaboration.
Prof. Dr. Michael Rosemann introduced me to the world of academic research and sparked
my interest in process automation and workflow management. His guidance, enthusiasm, and
creativity opened a new world for me that continues to be both fascinating and intriguing.
Moreover, he is not just a colleague, but also a great friend - independent of longitude and lati-
tude. All the best to Brisbane.
I had the pleasure to work with three brilliant students on the Cassandra project - Björn
Blum, Henning Plöger, and Tobias Rieke, who put many hours of hard work into turning the
conceptual process controlling ideas into a working prototype. Their contribution to this work
is immense, and I would like to thank them for all of it.
Dr. Marc Gille and Michael Johann of Carnot allowed me to play with their “baby” and
were extremely supportive throughout many changing ideas and plans. Jon Pyke of Staffware
graciously offered me access to the Staffware 2000 product, and Marc-Thomas Schmidt
offered me helpful advice when I had questions regarding the IBM MQSeries products. The
members of the Workflow Management Coalition provided an invaluable reality check for my
ideas. I am especially indebted to Dave Hollingsworth, Charlie Plesums, Robert Shapiro, and
Keith D. Swenson for many intriguing insights into the commercial world of workflow.
The project team at the enterprise case study consisted of Dr. Andreas Tietz, Robert Freier,
Edith Deitermann, and my colleague Andreas Rottwinkel. They offered me valuable informa-
tion and support regarding the insurance case and graciously allowed me to publish the insight
gathered in the project.
My colleagues at the University of Münster provided me with priceless ideas, challenging
thoughts, and constructive criticism at times when it was most needed. I would like to thank
them all for five fascinating years. PD Dr. Roland Holten diligently read through the early
drafts of this book and guided me back to the right track when my train of thoughts was in the
danger of derailing. Dr. Christian Probst provided companionship, valuable ideas, and - most
important - a dose of pragmatism when the topic seemed to grow out of bounds. Sebastian
Beneloucif was incredibly helpful in managing the ever-growing list of references and went
beyond the call of duty more than once in order to ensure a timely completion of this book.
Maggie Bin Lai proofread the final draft, and Colleen Gibney shared her incredible talent for
writing style with me.
A very special thank you goes to Nersel, sevgilim esmerim, who gives me love, support, and
encouragement when I need it most. Seni çok seviyorum. My most heartfelt thanks go out to
my parents Heinrich and Helga zur Mühlen, who have provided me with unconditional love
and support throughout my education and my academic career. They have given my brother
Christian and me the most open-minded environment imaginable and provided constant inspi-
ration throughout the time of my dissertation. This book is dedicated to them.
Hoboken, NJ, June 2004 Michael zur Muehlen
Table of Contents V

Table of Contents
Table of Contents .............................................................................................. V
List of Figures...................................................................................................IX
List of Tables ....................................................................................................XI
List of Abbreviations..................................................................................... XIII
1 Workflow-based Process Controlling - An Introduction.................................... 1
1.1 Organizational Design and Process Performance ................................................... 1
1.2 Goal Statement..............................................................................................................6
1.3 Relevance of the Subject.............................................................................................. 7
1.4 Related Work...............................................................................................................10
1.5 Scientific Positioning..................................................................................................12
1.6 Procedure Model ........................................................................................................18
1.7 Structure of the Book.................................................................................................20
2 Management Support for Process Organizations ............................................ 23
2.1 A System Theoretic Framework for Organizational Analysis .............................23
2.1.1 Systems and System Theory ...........................................................................25
2.1.2 Companies as Socio-Technical Systems .......................................................30
2.2 Process-orientation and Process Organizations ....................................................37
2.2.1 Organizational Processes ................................................................................37
2.2.2 Process Definitions..........................................................................................38
2.2.3 A Taxonomy of Organizational Processes ..................................................40
2.2.4 Development of Process-oriented Organizations ......................................46
2.2.5 The ARIS Framework for Process Analysis and Design...........................49
2.3 Management of Process Organizations...................................................................55
2.3.1 Management - Concepts and Definitions ....................................................55
2.3.2 Management Control as a Feedback Loop ..................................................57
2.3.3 Levels and Tasks of Management .................................................................60
2.4 Controlling of Process Organizations .....................................................................70
2.4.1 Controlling of the Firm - Concepts and Definitions .................................70
2.4.2 Controlling as a Measure to Ensure Rational Management ......................73
2.5 Process Management and Process Controlling......................................................76
2.5.1 Process Management.......................................................................................76
2.5.2 Process Controlling .........................................................................................78
2.6 Life Cycle Approaches to Process and Workflow Management.........................82
3 Technology Support for Process Organizations .............................................. 89
3.1 History of Process Automation Technology..........................................................89
3.1.1 Office Automation Technology ....................................................................90
3.1.2 From Office Automation to Workflow Management ...............................92
VI Table of Contents

3.1.3 Other Related Technologies .......................................................................... 94

3.1.4 Commercial Use of Workflow Technology ................................................ 96
3.2 Workflow Application Concepts ............................................................................. 98
3.2.1 Terminology and Definitions ........................................................................ 99
3.2.2 Perspectives on Workflows ......................................................................... 103
3.2.3 Workflow Applications as Coordinating Systems.................................... 110
3.2.4 Workflow Applications as Integration Systems........................................ 111
3.3 Technology of Workflow Applications ................................................................ 114
3.3.1 Technical Structure of a Workflow Management System....................... 114
3.3.2 Stand-alone versus Embedded Workflow................................................. 116
3.4 Standardization Efforts in the Workflow Area ................................................... 118
3.4.1 Workflow Management Coalition (WfMC) .............................................. 119
3.4.2 WfMC Standards ........................................................................................... 120
3.4.3 Object Management Group (OMG).......................................................... 127
3.4.4 OMG Workflow Facility.............................................................................. 128
3.4.5 Workflow Management and Web Services Choreography..................... 133
3.4.6 Resource-oriented Process Choreography: Wf-XML and ASAP.......... 138
3.5 Development of Workflow Applications............................................................. 141
3.5.1 Procedure Models for Workflow Application Development................. 141
3.5.2 Process Modeling .......................................................................................... 143
3.5.3 Standards for Workflow Modeling Languages ......................................... 148
3.5.4 Organization Modeling................................................................................. 160
3.5.5 Application Integration ................................................................................ 168
3.6 Use of Workflow Applications .............................................................................. 169
3.6.1 Run Time Behavior....................................................................................... 169
3.6.2 Workflow Instance State Model ................................................................. 170
3.6.3 Activity Instance State Model...................................................................... 171
3.6.4 State Changes and Constraints.................................................................... 172
3.6.5 Audit Trail Information................................................................................ 173
4 Workflow-driven Process Controlling ............................................................. 175
4.1 Related Work on Workflow-based Monitoring and Controlling...................... 175
4.1.1 Data Perspective............................................................................................ 176
4.1.2 Usage Perspective.......................................................................................... 176
4.1.3 Tool Perspective............................................................................................ 177
4.1.4 Method Perspective ...................................................................................... 180
4.2 A Reference Meta Model for Audit Trail Data ................................................... 181
4.2.1 Information Content of Audit Trail Data ................................................. 181
4.2.2 Audit Trail Attributes ................................................................................... 183
4.2.3 Audit Trail Events......................................................................................... 189
4.2.4 Comparing the Information Content of Audit Trails.............................. 192
4.2.5 Conceptual Workflow Meta Model ............................................................ 195
Table of Contents VII

4.2.6 A Reference Data Structure for Audit Trail Information........................197

4.3 A Conceptual Framework for Process Controlling.............................................202
4.3.1 A Taxonomy of Audit Trail Information...................................................202
4.3.2 Process Monitoring versus Process Controlling .......................................206
4.3.3 Information Requirements and Information Supply ...............................210
4.3.4 Integration of Audit Trail Data with other Data Sources .......................212
4.4 A Cybernetic Model for Process Controlling.......................................................217
4.4.1 Cybernetic Business Process Control .........................................................217
4.4.2 Automatic Feedback Cycle...........................................................................219
4.4.3 Operative Management and Control ..........................................................222
4.4.4 Strategic Management and Control.............................................................223
4.5 Summary ....................................................................................................................226
5 Process Controlling: A Case Study and A Prototype...................................... 227
5.1 Process Controlling in an Insurance Company....................................................227
5.1.1 Case Outline ...................................................................................................227
5.1.2 A First Assessment ........................................................................................228
5.1.3 Information Availability................................................................................229
5.1.4 Improvement through Workflow Data Integration .................................231
5.1.5 Preconditions for Implementation..............................................................232
5.2 Cassandra - A Process Controlling Prototype......................................................234
5.2.1 Overall System Architecture ........................................................................234
5.2.2 Data Structure ................................................................................................236
5.2.3 Evaluation Methods ......................................................................................237
5.3 Summary ....................................................................................................................242
6 Summary, Reflection, and Outlook ................................................................ 243
References....................................................................................................... 247
Appendix..........................................................................................................281
VIII Table of Contents
List of Figures - IX -

List of Figures
Figure 1-1: Deming Cycle ................................................................................................................ 3
Figure 1-2: Positioning of Workflow-based Controlling ............................................................ 7
Figure 1-3: Structure of the Book.................................................................................................21
Figure 2-1: Taxonomy of System Concepts................................................................................27
Figure 2-2: Perspectives on Systems ............................................................................................29
Figure 2-3: Efficiency Goals..........................................................................................................32
Figure 2-4: Conflicts and Synergies between Efficiency Goals ...............................................33
Figure 2-5: System View of the Enterprise .................................................................................36
Figure 2-6: Classification of Process Attributes .........................................................................41
Figure 2-7: Architecture of Integrated Information Systems...................................................51
Figure 2-8: ARIS Phase Model .....................................................................................................52
Figure 2-9: Cyclic Management Model........................................................................................59
Figure 2-10: Cybernetic Feedback Loop .......................................................................................60
Figure 2-11: Management Tasks and Indicators ..........................................................................69
Figure 2-12: Controlling as a Function to Ensure Rational Management................................75
Figure 2-13: Functional Decomposition of Process Controlling ..............................................81
Figure 2-14: Decomposition of the Planning Phase....................................................................82
Figure 2-15: MOVE Workflow Life Cycle....................................................................................83
Figure 2-16: Workflow Management Cycle by Heilmann ..........................................................84
Figure 2-17: Process Life Cycle.......................................................................................................86
Figure 3-1: History of Office Automation and Workflow Systems........................................93
Figure 3-2: Functional Decomposition of Workflow Management .....................................101
Figure 3-3: Workflow Integration Requirements.....................................................................114
Figure 3-4: Technical Structure of a Workflow Application..................................................117
Figure 3-5: Workflow Services as Integration Technology ....................................................118
Figure 3-6: Workflow Management Coalition Reference Model ..........................................122
Figure 3-7: WfMC Interface 5 Data Structure..........................................................................126
Figure 3-8: Positioning of the Workflow Facility.....................................................................129
Figure 3-9: Workflow Facility Object Model............................................................................131
Figure 3-10: Standardization Areas in Business Process Integration......................................134
Figure 3-11: Taxonomy of Web Services Choreography Related Standards .........................135
Figure 3-12: Interaction Types......................................................................................................136
Figure 3-13: WSDL Meta Model ..................................................................................................137
Figure 3-14: Nested Workflow Interaction.................................................................................140
Figure 3-15: Wf-XML Message Types.........................................................................................141
Figure 3-16: Reference Model for the Workflow Application Design Process.....................143
Figure 3-17: WPDL Process Meta Model ...................................................................................150
Figure 3-18: WPDL Organizational Meta Model.......................................................................151
Figure 3-19: Schematic WSFL Flow ............................................................................................155
Figure 3-20: XLANG Schedule ....................................................................................................157
Figure 3-21: Organizational Meta-Model of Staffware 2000....................................................165
Figure 3-22: Organizational Reference Meta Model..................................................................166
List of Figures -X-

Figure 3-23: Generic State Model of a Workflow Instance ..................................................... 171

Figure 3-24: Generic State Model of an Activity Instance....................................................... 172
Figure 4-1: Audit Trail Data Structure of WfMC Interface 5................................................ 184
Figure 4-2: Audit Trail Data Structure of MQSeries Workflow ........................................... 186
Figure 4-3: Audit Trail Data Structure of Staffware 2000...................................................... 187
Figure 4-4: Audit Trail Data Structure of Carnot.................................................................... 188
Figure 4-5: Conceptual Workflow Meta Model....................................................................... 198
Figure 4-6: Reference Meta Model of Audit Trail Content ................................................... 199
Figure 4-7: Audit Trail Table Structure..................................................................................... 201
Figure 4-8: Analysis Dimensions of Audit Trail Information ............................................... 202
Figure 4-9: Activity, Segment, and Process Level Analysis.................................................... 206
Figure 4-10: Monitoring of an E-Commerce Order ................................................................. 207
Figure 4-11: Process State and Business State ........................................................................... 208
Figure 4-12: Technical Monitoring Facility ................................................................................ 210
Figure 4-13: Management Levels and Information Sources.................................................... 211
Figure 4-14: Relevant Temporal Aspects for Workflow Analysis .......................................... 214
Figure 4-15: Time-oriented Activity Data Mart......................................................................... 216
Figure 4-16: Business Process Control Cycles ........................................................................... 218
Figure 4-17: Cybernetic Feedback Model of Process Controlling.......................................... 220
Figure 4-18: Sample Performer Profiles...................................................................................... 221
Figure 4-19: Integration of Workflow Audit Trail Data........................................................... 224
Figure 4-20: Balanced Scorecard Framework ............................................................................ 225
Figure 5-1: Controlling Data Flow (As-Is) ............................................................................... 230
Figure 5-2: Controlling Data Flow (Target) ............................................................................. 232
Figure 5-3: Architecture of the Cassandra ABC Module ....................................................... 235
Figure 5-4: Cassandra Activity Instance Partial Fact Table ................................................... 236
Figure 5-6: Cost Center Report.................................................................................................. 238
Figure 5-5: Definition of a Cost Center.................................................................................... 238
Figure 5-7: Definition of Ratios for Evaluation Perspectives ............................................... 239
Figure 5-9: Target Definition Tab ............................................................................................. 240
Figure 5-8: Measure Definition Tester...................................................................................... 240
Figure 5-11: Measurement Viewer............................................................................................... 241
Figure 5-10: Relationship Definition Tab................................................................................... 241
Figure A-1: Entity Relationship Model...................................................................................... 281
Figure A-2: Relational Model ...................................................................................................... 282
Figure A-3: State Model ............................................................................................................... 282
List of Tables - XI -

List of Tables
Table 1-1: Fundamental Ontological and Epistemological Positions ...................................14
Table 1-2: Positioning of the Book.............................................................................................20
Table 2-1: Categories of Management Activities ......................................................................62
Table 2-2: Juxtaposition of Management Levels ......................................................................63
Table 2-3: Evolution of Cost Accounting Systems ..................................................................67
Table 2-4: Juxtaposition of Management Accounting and Controlling ................................72
Table 3-1: CIMOSA Generic Building Blocks........................................................................103
Table 3-2: Perspectives on Workflow Models and related Entities.....................................109
Table 3-3: Dependencies and Coordination Processes .........................................................110
Table 3-4: Efficiency Goals and Workflow Support..............................................................111
Table 3-5: Process Definition Languages ................................................................................146
Table 3-6: Comparison of PDL-driven and GPSG-driven Workflows..............................147
Table 3-7: Standards for Process Modeling Languages (Part 1)...........................................148
Table 3-8: Standards for Process Modeling Languages (Part 2)...........................................149
Table 3-9: Standards for Process Modeling Languages (Part 3)...........................................149
Table 3-10: Analysis of different Workflow Modeling Languages ........................................159
Table 4-1: Audit Trail Entries (Workflow Instance) ..............................................................193
Table 4-2: Audit Trail Entries (Activity Instance) ..................................................................194
Table 5-1: Audit Trail-based Information Availability...........................................................229
List of Tables - XII -
List of Abbreviations - XIII -

List of Abbreviations
ABC Activity-based Costing

ACM Association of Computing Machinery

API Application Programming Interface

ARIS Architecture of integrated Information Systems

BPEL4WS Business Process Execution Language for Web Services

BPM Business Process Management

BPMI Business Process Management Initiative

BPML Business Process Modeling Language

BPMN Business Process Modeling Notation

BPR Business Process Reengineering

BR Business Reengineering

BPI Business Process Improvement

BRC Business Reconfiguration

CIMOSA Computer Integrated Manufacturing Open System Architecture

CORBA Common Object Request Broker Architecture

DBMS Database Management System

EBNF Extended Backus-Naur Form

ebXML Electronic Business XML

e. g. exempla gratiae/exempli gratia (Latin: for example)

EJB Enterprise Java Bean

EPC Event-driven Process Chain

et al. et alii (Latin: and others)

etc. et cetera (Latin: and other things)

GPSG Generalized Process Structure Grammars

HTTP Hypertext Transfer Protocol

i. e. id est (Latin: that is)

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

List of Abbreviations - XIV -

J2EE Java 2 Enterprise Edition

KIF Knowledge Interchange Format

MIT Massachusetts Institute of Technology

MOF Meta Object Facility

NIST National Institute of Standards and Technology

OMG Object Management Group

ORB Object Request Broker

PIF Process Interchange Format

PSL Process Specification Language

SOAP Structured Object Access Protocol

SQL Structured Query Language

SWAP Simple Workflow Access Protocol

SWOT Strengths, Weaknesses, Opportunities, Threats

tpaML Trading Partner Agreement Markup Language

UDDI Universal Description, Discovery and Integration

UML Unified Modeling Language

WAPI Workflow Application Programming Interface

WiSt Wissenschaftliches Studium

WfMC Workflow Management Coalition

WfMS Workflow Management System

WPDL Workflow Process Definition Language

WSCI Web Services Choreography Interface

WSCL Web Services Conversation Language

WS-CDL Web Services Choreography Description Language

WSDL Web Services Description Language

WSFL Web Services Flow Language

XML eXtensible Markup Language

XPDL XML Process Definition Language

Organizational Design and Process Performance -1-

1 Workflow-based Process Controlling - An Introduction

1.1 Organizational Design and Process Performance
Organizational structures1 and their development is studied by a variety
of disciplines, such as sociology, psychology, and economics. The goal of
organizational research within the field of business administration is the
development of viable and efficient structures for enterprises as self-con-
tained economic units.2 Much of 20th century organizational research is
founded on the works of FAYOL3 and TAYLOR4. While FAYOL researched
the managerial structure of an enterprise, TAYLOR focused on the opera-
tional enactment of tasks as well as the design of organizational structures
that support the efficient execution of these tasks. The ideas devised by TAY-
LOR have dominated organizational research until the 1970s and can still be
found in many enterprises today.5 Until the 1970s the functional separation
of tasks was appropriate for existing market conditions. Since then, increas-
ing market segmentation and shorter product life-cycles, among other fac-
tors, have led both businesses and researchers to research organizational
structures better suited to adapt to changing market conditions, product
portfolios, and enterprise infrastructures. For this purpose, business pro-
cesses have become a focal point of organizational research.

1.
Within organizational theory, the term organization can have both an institutional and an
instrumental meaning. While the institutional view describes an organization as a self-con-
tained entity that has a specific structure, the instrumental term denotes the internal struc-
ture of such an entity (e. g., the internal organization of a company). American
organizational literature is dominated by the institutional notion of organization. For exam-
ple, DESSLER defines organizations as: “[...] purposeful social units [that] consist of people
who carry out differentiated tasks which are coordinated to contribute to the organization‘s
goals.” Dessler (1986), p. 6.
German organizational literature focuses primarily on the instrumental meaning of the term
“organization”. Following this approach, a distinction between the functional and configu-
rative organization can be identified. See, e. g., Schreyögg (1997). The functional organiza-
tion treats organization as a managerial function, i. e., the design and implementation of
efficient structures in order to support the goals of the enterprise. This functional approach
is performed after the initial stage of goal-setting and planning. The configurative approach,
mainly based on the works of KOSIOL, treats the design of an organizational structure as
the ultimate initial task, which determines or influences all subsequent activities. Planning is
executed within the boundaries set within this initial configuration. See, e. g., Kosiol (1978).
2.
Refer to, e. g., Lehmann (1992), p. 1539.
3.
See Fayol (1949).
4.
See Taylor (1947).
5.
Typical characteristics of tayloristic organizational structures include a high degree of sepa-
ration between tasks, the functional integration of similar tasks into larger organizational
units, and a strong separation between dispositive and operational work. Compare Adam
(1998), pp. 25ff., for a thorough discussion see, e. g., Sawalha (2000); Kugeler (2001).
-2- Organizational Design and Process Performance

The alignment of organizational structures with business processes has

been discussed in the organizational literature as early as the 1930s.6 Authors
such as NORDSIECK and HENNING created the distinction between the
static structure of the corporate organization (Aufbauorganisation) and the
organization’s processes (Ablauforganisation).7 This separation has led to a
duality within the field of organizational research, found mainly in the Ger-
man literature. Among American authors, CHAPPLE and SAYLES are the
most notable early proponents of process orientation.8
Despite this early interest in the topic, the process-oriented structuring of
organizations did not gain acceptance in corporate practice until the works
of PORTER9, DAVENPORT10, HARRINGTON11, and most notably HAMMER
and CHAMPY12 led to an increasing interest in process concepts and their
implementation.13 Today, the creation of process-oriented organizational
structures is widely seen as a suitable way to overcome coordination prob-
lems between functional units, which may result in long cycle times, low
product quality, and redundant task fulfillment.14
Despite strong interest, implementing process-oriented structures has
proven difficult for many companies.15 Some of the reasons for these diffi-
culties are existing information technology infrastructures, which support
functional organizations and hinder the transition toward process-oriented
structures.16
Workflow management systems (also known as Business Process Man-
agement Systems) address this problem. They support the execution of busi-
ness processes through the automated coordination of activities and
resources according to a formally defined model of the business process (the
workflow model).17 The use of workflow technology as a central building
block of modern information system architectures illustrates the increasing
importance of this type of application.18 Workflow technology leverages the

6. Compare, e. g., Nordsieck (1934), p. 76, who defines a process as the treatment of objects.
7. Refer to, e. g., Nordsieck (1931); Nordsieck (1934); Henning (1934); Nordsieck (1972).
8. See, e. g., Chapple, Sayles (1961).
9. Porter (1985).
10. Davenport (1993) and Davenport (1995).
11. Harrington (1991).
12. Hammer, Champy (1993); Hammer (1996).
13. A good overview of process concepts in the literature can be found in Körmeier (1995).
Notable German sources for process concepts are Gaitanides (1983) and Scheer (1990).
14.
See Nippa (1995a), p. 40ff.
15.
For a critical view of reengineering mistakes see, e. g., Davenport (1995), who criticizes the
lack of employee-orientation in failed reengineering efforts.
16.
Compare Luftman (2003).
17.
Compare Georgakopolous, Hornick, Sheth (1995).
18.
Compare Leymann, Roller (1996).
Organizational Design and Process Performance -3-

value of existing information system infrastructures and helps enterprises in

the transition toward a process-oriented organization.19
Implementing process concepts within organizations is only one step
toward achieving a corporate process focus. In order to reap ongoing bene-
fits from a process-oriented organization, continuous maintenance and con-
trol of the business processes is required. Process management deals with
the efficient and effective execution of business processes.20 It consists of
the planning, implementation, enactment and controlling of processes, and
forms a life-cycle that leads to continuous process improvement. Process
management addresses the requirement of companies to stay adaptable to
environmental and internal changes. Simultaneously it helps companies real-
ize efficiency gains through the exploitation of cost-effective ways to pro-
duce goods and perform services.
Using the Deming Cycle21 for continuous improvement efforts, the nec-
essary steps to align an organization with its processes can be structured
along the four phases plan, do, check, and act (compare figure 1-1).

Figure 1-1: Deming Cycle

19. Refer to Plesums (2002).

20. As a preliminary definition, a business process is the logical and temporal order of those
activities performed to manipulate an economically relevant object. Refer to, e. g., Becker,
Kahn (2002), p. 6; Becker, Schütte (1996), p. 53; Rosemann (1996), p. 9.
21.
Compare Deming (1992).
-4- Organizational Design and Process Performance

Planning Phase (Plan)

Within the planning phase, organizational processes are identified, mod-
eled and optimized. During this phase, various modeling methods can be
employed, such as Petri Net-based approaches or Event-driven Process
Chains. Most process engineering approaches focus on this phase. These
approaches both align and create modification plans for a company’s organi-
zational structures and processes. which then lead to reorganization efforts
in the execution phase.

Execution Phase (Do)

Throughout the execution phase, processes are implemented and the
organizational structure is realigned to fit these processes. Information sys-
tems that support single process steps are implemented, and process partici-
pants are trained in the organizational rules and regulations, as well as the
use of the supporting infrastructure. Metrics about the process performance
are collected during the execution of the new processes.

Evaluation Phase (Check)

Based on the data collected during the execution phase, the effectiveness
of the new organization is analyzed in the evaluation phase. Measurements
are compared across different processes and organizational units, and rele-
vant results are reported to operative and strategic management units.

Reengineering Phase (Act)

During the reengineering phase, the results of the evaluation phase are
reviewed by strategic and operative management units, and the attainment of
strategic and operative goals is analyzed. Depending on the performance of
the organization, adjustments to the underlying goal structure and measures
for the improvement of the current situation are used to create alternative
plans. One or more of these plans are chosen for implementation and are
handed over to the participants of the planning phase as guidelines for their
activities.
The Deming Cycle example illustrates that management of process-ori-
ented organizations requires appropriate measurements in order to verify
and ensure the effectiveness of an organization’s processes.22 Process con-
trolling strives to ensure the rationality of the decision making process by

22.
“Whatever measures are employed, they must reflect the process as a whole and must be
communicated to and used by everyone working on the process. Measures are an enor-
mously important tool for shaping people’s attitudes and behaviors; they play a central role
in converting unruly groups into disciplined teams.”, Hammer (1996), p. 16.
Organizational Design and Process Performance -5-

supplying relevant process execution information.23 One of the core tasks of

successful process controlling is the installation and maintenance of an infra-
structure that validates operational excellence by providing this necessary
information. Workflow management systems record events occurring during
the execution of process instances and are thus capable of providing detailed
information about the performance of operative processes.24
Since the implementation and deployment of a workflow-based applica-
tion systems is a complex and therefore time-consuming endeavor, it can be
assumed that once this kind of architecture has been successfully deployed,
many companies resist the urge to apply changes. Despite claims by vendors
that the introduction of workflow technology will foster a more flexible,
adaptable organization, we believe the opposite is true.25 The complexity of
workflow management projects, however, is only one cause for the reluctant
attitude observed toward change. The non-transparency of cause-effect rela-
tionships that describe the effects of workflow changes on the organiza-
tional, technical, or process level, is a more severe cause for this attitude.
This missing transparency can be attributed to the lack of an integrated
infrastructure for the gathering and presentation of performance indicators
which describe the behavior of a workflow-enabled organization. Such an
infrastructure would provide guidance on which parameter adjustments
might increase an organization’s efficiency. Even though management infor-
mation systems have been developed since the 1950s26, very few of them
take the business process perspective into account. A notable exception is
the recently developed Balanced Scorecard by KAPLAN and NORTON, which
explicitly includes a perspective for internal business processes.27
The existing criticism of financial performance indicators and cost con-
trolling approaches28 does not imply that this information is no longer
needed to substantiate managerial decisions. The cost-effective allocation of
resources as well as the efficient use of financial assets are important for the
sustainability of any economic entity. Focusing on financial information

23.
Compare Weber (1999) and the detailed discussion in section 2.4.2 on page 73.
24.
Compare McLellan (1995).
25.
The inflexibility of current workflow management approaches has been criticized, e. g., by
Dourish et al. (1996). The Generalized Process Structure Grammar, on which DOURISH’S
system Freeflow is based, is discussed in detail in section 3.5.3 on page 148.
26.
A landmark article commonly seen as the origin of modern decision support and manage-
ment information systems development was the article by LEAVITT and WHISLER “Man-
agement in the 1980’s”, in which the authors argue that decision processes in companies
would be automated in the future, leading to a decreasing number of managers. See Leavitt,
Whisler (1958).
27.
Compare Kaplan, Norton (1993); Kaplan, Norton (1996).
28.
Compare Kaplan, Cooper (1997).
-6- Goal Statement

alone, however, can lead to strategic managerial myopia and - ultimately - the
subsequent failure of the organization.29

1.2 Goal Statement

The goal of this book is the development of a reference architecture for
process information systems that utilize operational information generated
by workflow management systems. This controlling infrastructure is
designed to enhance traditional enterprise controlling instruments to pro-
vide a holistic and process-oriented view of enterprise operations. In order
to achieve this goal, it is necessary to have both a methodical discussion
about data that can be successfully gathered from a workflow infrastructure,
and a conceptual discussion about how this data can be integrated into the
management information infrastructure of a company. The purpose of the
methodical discussion is the development of a taxonomy of controlling
information required by process participants and managers at different lev-
els. The results serve as the basis of an evaluation where this information
demand can be met by the information supplied by workflow management
systems and where additional information sources are required. The concep-
tual discussion is intended to develop a design methodology that incorpo-
rates controlling information generated by workflow management systems
into (new or existing) management information systems.
Workflow-based controlling systems provide companies with the ability
to accurately measure the operational performance of business processes.
Combined with data warehouse technology and operational business data,
complex evaluations can be performed. These evaluations help enterprises
to assess their current situation more precisely than could be done through
the sole use of traditional (mainly financial) key performance indicators. The
increasing maturity of workflow and data warehouse products satisfy the
requirements for the implementation of workflow-driven controlling sys-
tems.
It should be noted that workflow-based controlling does not replace
other enterprise-controlling mechanisms, but enhances them significantly.
The positioning of workflow-based controlling in relation to other control-
ling techniques is shown in figure 1-2. While strategic controlling instru-
ments such as the Balanced Scorecard focus on qualitative aspects of the
enterprise, and traditional controlling methods rely on financial information,
few techniques exist that place the business process at the center of atten-
tion.
29.
For a critical discussion of traditional financial controlling measures see Wiese (1999), chap-
ter 3.1.
Relevance of the Subject -7-

Adapted from Kueng (1998), pp. 425 ff.

Figure 1-2: Positioning of Workflow-based Controlling

Workflow-based controlling tools that focus entirely on information con-

tained in the audit trail are limited to quantitative analyses of the event-based
history of completed processes.

1.3 Relevance of the Subject

Relevance from an organizational perspective

From an organizational perspective, the use of audit trail data for control-
ling purposes touches upon two areas of an organization: management con-
trol, which is based on the new level of information; and controlling, which
has to create and maintain a matching infrastructure to manage this informa-
tion and combine it with complementary data sources.
Management Control
The importance of business process performance measures for the opti-
mization process has been pointed out by HARRINGTON:
“[...] the lack of good white-collar measurements is a major obstacle to improved
business processes. [...] if you cannot measure it, you cannot control it. And if you
cannot control it, you cannot manage it.”30

30.
Harrington (1991), p. 164.
-8- Relevance of the Subject

Current application system architectures, which are based on workflow

technology, enable the collection of process metrics for very little cost. The
use of this information to support process-oriented decisions in the manage-
ment control phase of the management cycle has not been researched in
detail yet. One of the biggest unanswered questions deals with the identifica-
tion of relevant process metrics for managers. The analysis of process-related
information requirements at different levels of the management system and
the juxtaposition of these requirements with information made available by a
workflow-based software infrastructure can help shed some light on this
question.
Controlling
Audit trail information represents a new form of information that is avail-
able to controllers in their function as information suppliers. The usefulness
of this kind of information for management purposes has not been assessed
so far. An analysis of how audit trail information can enhance existing infor-
mation sources and which complementary information sources are required,
allows enterprise controllers to participate in the design phase of workflow
projects. Furthermore, such an analysis ensures that the resulting system
architecture delivers the measurements required by established controlling
methods.

Relevance from a technical perspective

From a technical perspective, the use of audit trail data for controlling
purposes is interesting in three areas: workflow application design, workflow
system design, and data warehouses and business intelligence design.
Workflow Application Design
Workflow application designers use workflow management systems as an
infrastructure component in the design of complex application systems.
They are faced with the necessity to integrate the workflow execution envi-
ronment with existing application logic and existing data sources. Analyzing
the dependencies between application data structures and workflow audit
trail records provides workflow application designers with information
about how these two data sources can be linked and which application data
needs to be accessible from a workflow management system. Also, the
development of a metrics framework helps workflow application designers
integrate appropriate measuring points in their design, which simplifies the
monitoring of the workflow implementation at run time.
Relevance of the Subject -9-

Workflow System Design

Workflow vendors use the audit trail mainly as a device for the debugging
of workflow applications. While the potential benefits of audit trail analysis
for business purposes are known, this potential has been realized by only a
few vendors.31 For example, JABLONSKI and BUSSLER describe a dedicated
history perspective within their MOBILE approach. They focus on the use of
audit trail data at run time for the identification of past events that impact
the current process flow as well as for recovery functions, and point out the
use of audit trail information for revision, analysis and reengineering pur-
poses from a business perspective.32 In the context of production workflow
systems, LEYMANN and ROLLER use the term monitoring to describe the use
of audit trail information to ensure the correct functioning of a workflow
implementation. In the same source the authors describe the use of audit
trail information in the area of process management without specifying a
system architecture for this purpose.33 A conceptual framework for the inte-
gration of workflow audit trail data in controlling applications would provide
workflow vendors with guidelines as to which information should be
included in a workflow audit trail and which methods should be supported
to access this information.
Data Warehousing and Business Intelligence Design-
Providers of management information and decision support systems typ-
ically deal with information generated by transaction processing systems.
This type of data represents business objects, customers, suppliers, and other
entities from the operative system of the company. Audit trail data differs
from this information, since it concerns the behavior of the organization
and its members, regardless of the business context in which this data was
generated.34 Therefore, both the design of data structures for the efficient
storage and retrieval of audit trail data and the combination of audit trail
information with related business data are of interest to data warehouse and
business intelligence vendors.

31.
Chaffey gives the metrics module of Staffware as an example for workflow-based analysis.
Compare Chaffey (1998), pp. 27-28. For a detailed discussion of related work refer to chap-
ter 4.1 on page 175.
32.
Compare Jablonski, Bussler (1996), pp. 184-185, pp. 264-267 and p. 307.
33.
See Leymann, Roller (2000), pp. 58-60 and pp. 105-111.
34.
Compare, e. g., the work by LIST ET AL. on the design of Data Warehouse structures for
workflow data. Refer to List et al. (1999) and List et al. (2000).
- 10 - Related Work

1.4 Related Work

The application of workflow management technology to the controlling
domain has been studied in a number of research projects. The existing
approaches can be grouped into three categories: The application of work-
flow concepts to data warehouse design and operation, the analysis of tech-
nical facilities for audit trail generation, and the analysis of workflow audit
trail data from an enterprise controlling perspective.

Applying Workflow Concepts to Data Warehouse Design

Sources that use workflow technology for the design of data warehouses
aim squarely at the design phase of data warehouse projects. Since the
retrieval and transformation of operational data into the data warehouse is a
frequent and structured process, it is a prime candidate for workflow auto-
mation.
BOUZEGHOUB ET AL. describe the modeling of data warehouse refresh-
ment processes as a workflow.35 They use an event-driven workflow model-
ing approach to trigger various parts of the refreshment process either after
a timer has expired or after a predefined condition in the data warehouse has
occurred. In particular, they distinguish between client-driven refreshment, when
a user activity causes an update to the data warehouse structure; source-driven
refreshment, when the changes to the source data of the data warehouses trig-
ger a refreshment process; and ODS-driven refreshment, which is triggered by
the data warehouse if the content of the operational data store (ODS) is
updated.
In his discussion of workflow and data warehouse concepts, PATTERSON
identifies several areas in the data warehouse design process that could bene-
fit from the use of workflow technology, such as the handling of update
anomaly problems.36

Technical Facilities for Audit Trail Generation

KOKSAL ET AL. discuss the management of audit trail data in the distrib-
uted workflow management system Mariflow.37 The authors focus on tech-
nical issues regarding the storage of audit data and the economical design of
queries on distributed data sources, but they do not address the business
value of process history data.

35.
See Bouzeghoub, Fabret, Matulovic-Broqué (1999).
36.
See Patterson (1996).
37.
See Koksal, Alpinar, Dogac (1998).
Related Work - 11 -

MUTH ET AL. present an approach for the tracking of history information

in a distributed workflow management system.38 Within the prototype Men-
tor-lite, data about current and past workflow instances are kept in a tempo-
ral database to be queried either at run time or for ex-post analyses.

Analysis of Audit Trail Data

The analysis of audit trail data has been researched for both technical and
economical purposes. AGRAWAL ET AL. use data mining techniques to create
workflow models from audit trail data.39 This project uses data from the ad-
hoc execution of processes to subsequently identify common rules and pro-
cedures and to create workflow models using a bottom-up approach. The
authors have tested their approach against artificial data sets and audit trail
data from a live workflow installation. A similar approach has been pub-
lished by VAN DER AALST ET AL.40 The practical use of the methodology
presented, however, requires the existence of a flexible workflow tool which
records processes while they are being created on the fly. Despite an obvious
demand for such a tool, the current workflow software market is lacking
products with this kind of execution flexibility.
A number of publications focus on the ex-post analysis of workflow audit
trail data with methods transferred from enterprise controlling.41 The con-
trolling of processes using workflow audit trail data has been discussed in
the German literature to some extent, for example in the works of DERZ-
TELER42, KUENG and KRAHN43, RAUFER44, ROSEMANN ET AL.45, and
WEISS46. A number of English sources dealing with this topic can be identi-
fied as well, for example KUENG47, LIST ET AL.48, MCGREGOR,49 MCLEL-
LAN50, ZUR MUEHLEN and ROSEMANN51. These sources are discussed in
more detail in chapter 4.

38.
See Muth, Weissenfels, Gillmann, Weikum (1999).
39.
See Agrawal, Gunopulos, Leymann (1998). The proposed concept of inductive model gen-
eration has been patented by IBM, refer to Agrawal, Leymann, Roller (1998).
40.
See van der Aalst et al. (2003), and http://www.processmining.org
41.
These papers can be divided into conceptual works on the general collection and evaluation
of audit trail data, see, e. g., McLellan (1996); List et al. (2001); zur Muehlen (2000), and zur
Muehlen (2001), as well as papers that deal with specific prototypes, e. g., Raufer (1997);
Weiß (1998); Derszteler (2000), and zur Muehlen, Rosemann (2000).
42.
See Derszteler (2000).
43.
Compare Kueng, Krahn (2000).
44.
Compare Raufer (1997).
45.
Compare Rosemann, Denecke, Püttmann (1996).
46.
Compare Weiß (1998); Weiß (1999).
47.
Compare Kueng (1998); Kueng, Krahn (1999); Kueng (2000)
48.
See List, Schiefer, Tjoa, Quirchmayr (1999); List, Schiefer, Bruckner (2001).
49.
Compare McGregor (2002); McGregor, Edwards (2001).
50.
See McLellan (1996).
51.
See zur Muehlen, Rosemann (2000).
- 12 - Scientific Positioning

1.5 Scientific Positioning

Any scientific work that deals with the development of conceptual enti-
ties, such as models, procedures or theories, requires a thorough explanation
of the underlying assumptions regarding real world observables and the
treatment of these assumptions. For the reader to best understand and eval-
uate the approach taken and views expressed in this book, the underlying
assumptions need to be made clear. This allows criticism of both the work
performed and the views presented.52 In the foundation of a scientific work
a critical reflection of the assumptions made and the clarity of the argumen-
tation are the most critical requirement. In particular, these assumptions deal
with the question whether a reality exists independent of an observer, and
whether the spatio-temporal objects contained in such a reality can be
observed independent of the individual observer.
A central aim of this book is the construction of models (describing both
data structures and processes) of an object system (the corporate environ-
ment or the technical infrastructure within this environment), which is part
of a universe of discourse (the economic and technical environment). On the
one hand, the scientific positioning is meant to illustrate the concepts under-
lying the models and procedures developed in this book (i. e., against which
concepts these models and procedures can be tested). On the other hand,
this positioning is necessary to illustrate the development process that lead
to the models and procedures presented in this book (i. e., what are the
building blocks of the models and procedures).
For the reasons given above, the two questions discussed in the next sec-
tion are whether the elements contained in the universe of discourse are
based on the existence of an objective reality (ontological question53) and
whether this objective reality can be perceived in a subject-independent way
(epistemological question54). The answer to the epistemological question

52.
Compare Schütte (1998), p. 13.
53.
The distinction between the terms ontology (from Greek ontos, existence and logos, teach-
ings) and metaphysics (from Greek meta, [the books] about and physica, physics) in the Ger-
man and Anglo-American philosophical literature is not always clear. For example, AUDI
uses both terms synonymous (Audi (1999), p. 563 and p. 631). Metaphysics is generally
defined as the investigation of the nature, constitution, and structure of reality. See Butch-
varov (metaphysics) (1999), p. 563; similar Mittelstraß (Metaphysik) (1995), p. 871. A dis-
tinct positioning of ontology and metaphysics is given by Schwemmer (1995), pp. 1077-
1079. According to SCHWEMMER, the first use of the word ontology was the denomination
of the philosophia prima (the fist part of ARISTOTELES’ theoretical philosophy), thus ontol-
ogy can be perceived as the successor to metaphysics. The German philosopher C. WOLFF
(*1679 - †1754) introduced the distinction between the general metaphics (metaphysica
generalis) which equals ontology and special metaphysics (metaphysica specialis). In this
sense, ontology is the part of metaphysics dealing with questions of existence and reality,
while special metaphyics subsumes rational theology, rational cosmology and rational psy-
chology. While there exist notions of ontology that are separate from the general metaphys-
ics (e. g. QUINE’S notion of ontological commitment), we follow the use of ontology as a
synonym of general metaphysics in this book.
Scientific Positioning - 13 -

determines whether the concepts presented in this work can be verified on a

subject-independent basis, whereas the answer to the ontological question
determines whether the truthfulness of the concepts presented in this book
can be determined objectively by comparing them to real world objects.
The philosophy of science offers various, fundamentally different views
based on the answers to the questions stated above. For both the ontological
as well as the epistemological question, idealistic and realistic positions can
be distinguished. While an ontological realist accepts the notion of an objec-
tive reality (i. e. objects exist regardless of their recognition by an observer),
the ontological idealist (or metaphysical anti-realist) refutes such a concept.55
Similarly, while an epistemological realist claims that reality can be observed
as such and therefore objective knowledge is possible, the epistemological
idealist denies this idea and states instead that knowledge always depends on
the observing mind. These views lead to three differing positions, as
depicted in table 1-1 (the combination of ontological idealism with episte-
mological realism is not possible, since it is impossible to claim a mind-inde-
pendent observation of a world-in-itself, if the existence of this world-in-
itself is refuted).56

54. Epistemology denotes the study of “(a) the defining features, (b) the substantive conditions
or sources, and (c) the limits of knowledge and justification.” see Moser (1999), p. 273.
55.
Ontological (or metaphysical) realism is founded on the belief that “(a) there are real objects
[...] (b) they exist independently of our experience or our knowledge of them and (c) they
have properties and enter into relations independently of the concepts with which we
understand them.” Butchvarov (metaphysical realism) (1999), p. 562. While ontological ide-
alism only denies the existence of material objects, not the existence of other mind-inde-
pendent spatio-temporal concepts (such as minds, states, words etc.), metaphysical anti-
realism rejects one or more of the three basic assumptions of metaphysical realism.
The discussion about the existence of real world objects leads to three different metaphysi-
cal world views. While metaphysical materialists accept the existence of material entities,
metaphysical idealists only accept non-material (i. e. mental) entities, such as minds and
their states. The existence of both types of objects is accepted by metaphysical dualists. See
Butchvarov (metaphysics) (1999), p. 563.
56.
See Vering (2002), p. 8. An extreme form of epistemological idealism is the skepticism
found, e. g., in social constructivism. Epistemological skeptics do not necessarily deny the
existence of an objective reality, but they claim this world-in-itself is unknowable. See, e. g.,
Bird (2000), p. 137.
- 14 - Scientific Positioning

ontological realist or ontological idealist or

metaphysical realist metaphysical anti-realist

A real world exists; it can be Not possible

epistemological observed independent of the mind
realist
of the observer

A real world exists; it cannot be A real world does not exist; thus all
epistemological observed independent of the mind observations depend on the mind
idealist
of the observer of the observer

Table 1-1: Fundamental Ontological and Epistemological Positions

Based on these fundamental positions, the philosophy of science has

developed several – partially conflicting – positions. The main philosophical
positions for scientific work in the area of information systems are critical
rationalism, and various forms of constructivism, which can be understood
as counter-positions.57 The positioning that applies to the statements of this
book is a radical constructivism with regard to the understanding of reality,
and a methodical constructivism with regard to the way how theories are
developed and communicated. The effects of this positioning on the results
presented in this book are discussed below. A deeper discussion of other
philosophical standpoints follows.
Rationalism is based on the belief that reason is the primary way of
acquiring knowledge, as opposed to the sensory knowledge acquisition
which forms the basis for empiricist positions.58 The critical rationalism,
found predominantly in the works of POPPER and ALBERT, is based on an
idealistic ontological view (i. e., there exists a world-in-itself).59 Theories can
be measured against this real world, but, as POPPER points out, it is impossi-
ble to prove a theory, but it is possible to disprove it through falsification.60
Constructivist scientific theory is based on the epistemological belief that
the perceived reality is the result of a construction process by an observing
subject.61 This does not necessarily deny the existence of a real world, it
merely indicates that the real world – should it exist – cannot be perceived in
an objective way. VON FOERSTER gives various examples of perceptions that
are not founded on the existence of real objects.62 This constructivist belief

57.
A good juxtaposition of these positions can be found in Schütte (1998), pp. 13-34.
58.
See, e. g., Garber (1999), p. 771.
59.
See, e. g., Albert (1985); Popper (1989).
60.
See Popper (1989), p. 8, where he states that the truthfulness of theories cannot be proved
by their validation (i. e., a valid theory is not necessarily true), and pp. 14-17: “an empirical-
scientific system has to be able to fail due to experience.”
61. For an introduction to the constructivist world view see von Foerster (1981), pp. 288ff.
where he pointedly writes: “the environment as we perceive it is our invention.” This con-
structivist view is an opposite extreme to the objectivist viewpoint that knowledge is based
on the stable properties of objects in a real world. Objectivists claim that knowledge pro-
duced by the analysis of the real world is external to the knower and thus transferable by
building appropriate models of the real world.
Scientific Positioning - 15 -

is fueled by the anatomy of the human sensory system. The reception of

optical and acoustic signals as well as other stimuli results in nerve cell
responses. These responses do not encode the nature of the source signal
(i. e., the quality of the signal), but merely indicate the strength of the sensa-
tion, which manifests itself in the amplitude of the electrical signal generated
by the cells (i. e., the quantity of the signal).63 Consequently, the synapses of
the brain receive similar electrical signals regardless of the source of these
signals. Depending upon the region of the brain that serves as the recipient,
these electrical signals lead to the sensory experiences that we associate with
“seeing”, “hearing”, “feeling”, et cetera. The brain in itself does not possess
a direct link to the outside world; it instead computes our perception of the
outside world through the processing of the electric charges received by the
synapses.64 The cognitive process results in the generation of new stimuli,
which in turn are received and processed by the brain. This leads to a recur-
sive process of cognition as a series of computations. Following this con-
cept, we arrive at an understanding of the brain as an autonomous, self-
referential system that can be influenced by the outside world.65
Within the constructivist area of philosophy, radical and methodical con-
structivism can be distinguished.66 The concept of radical constructivism is
based on the works of VON GLASERSFELD.67 A central theme of radical con-
structivists is the (almost) complete omission of ontological statements,
since the reality that concepts and theories refer to is the subjective reality
constructed by the modeler.68 VON GLASERSFELD emphasizes this point by
explaining why radical constructivism is radical (and not extreme): “Because
it breaks with convention and develops a theory of knowledge in which

62.
See von Foerster (1981) and the examples given there.
63.
Compare von Foerster (1981), pp. 292ff.
64.
VON FOERSTER illustrates this concept by rephrasing the definition of cognition from “com-
puting a reality” over “computing descriptions of a reality” over “computing descriptions of
descriptions” to the final statement “cognition = computation of computations”. Von
Foerster (1981), pp. 292ff.
65.
Compare Vering (2002), p. 10.
66.
There are a significant number of other constructivist approaches, such as social, physical,
evolutionary, post modern as well as information-processing constructivism. As ERNEST
points out: “There are as many varieties of constructivism as there are researchers.” Ernest
(1995), p.459. The differences between these approaches are mainly with regard to the ques-
tion how knowledge is constructed. While the radical constructivism sees knowledge
restricted to the mind of a single subject, social constructivism claims that scientific
knowledge does not arise within individuals but is socially constituted. See Riegler (2001),
footnote 1.
67.
See, e. g., von Glasersfeld (1984); von Glasersfeld (1995); von Glasersfeld (2001); Riegler
(2001).
68. Ontological statements are used to a small extent to explain modeling frameworks. The sys-
tem theoretic view discussed in chapter 2 is based on the existence of systems, and the exist-
ence of these systems is explicitly stated, e. g., by Luhmann (1991), p. 31: “There are self-
referential systems. [...] There are systems with the ability to create relationships with them-
selves and to differentiate these relationships from those relationships they have with their
environment.” The statement “there are systems” is an ontological statement in this context.
- 16 - Scientific Positioning

knowledge does not reflect an objective, ontological reality but exclusively an

ordering and organization of a world constituted by our experience.”69
A constructivist world view leads to subject-dependent cognitions that
cannot be verified or falsified against an outside reality. Due to the
unknowability of reality, an empirical verification of theoretical concepts is
impossible. VON GLASERSFELD replaces the concept of verifiability with the
notion of viability: “To the constructivist, concepts, models, theories, and so
on are viable if they prove adequate in the contexts in which they were cre-
ated.”70 In order not to arrive at an absolute relativism, where every model
constructed is as valid as any other model, criteria are necessary to select a
“fitting” model over other, competing models. Two distinct approaches to
arrive at a valuation of constructivist theories are coherence and consensus.
On an individual basis, coherence describes the agreement between different
cognitive patterns within one subject’s brain, while consensus describes the
agreement between the cognitive patterns of several subjects.71 In order to
communicate constructivist theories or concepts among several subjects, a
concept developed by one subject has to be reconstructed or comprehended
by the other subjects.
The inter-subjective communication of theoretical concepts is one of the
main work areas of the methodical constructivist movement, founded on the
works of the Erlangen School of philosophy by K AMLAH and LORENZEN.72
The movement is based on the notion of language critique, which seeks the
development of an inter-subjective scientific language that serves as the basis
of scientific discourse. Therefore, the focus of methodical constructivism is
the development of a viable procedure to construct scientific knowledge and
to communicate this knowledge among peers.
In order to establish a common language linking the author and his
intended audience, the creation of a common terminology is necessary.
Through discourse, agreement about basic terms as well as rules for abstrac-
tion and concept-building has to be achieved. This ortho-language consists
of basic predicates whose meaning is understood in the same way by all sub-

69. Von Glasersfeld (1984), p. 24, juxtaposes the words “match” and “fit” to illustrate the dif-
ference between metaphysical realism and constructivism. To illustrate our limited access to
reality, he uses the example of a lock and key. While a certain key unlocks the lock (it “fits”),
it does not reveal the capacities of the lock (e. g., if there are different keys that also “fit”
this particular lock).
70.
Von Glasersfeld (1995), p. 7.
71.
Compare Heylighen (2001). Consensus as the basis for concept validation ultimately leads
to social constructivism, see footnote 65 on page 15.
72.
Because of this, the methodical constructivism is sometimes called Erlanger Konstruktivismus.
See Kamlah, Lorenzen, Robinson (1984); Lorenzen (1987). For a discussion of the applica-
tion of methodical constructivist thoughts on the design on formal workflow modeling lan-
guages see Messer (1999), pp. 104 ff.
Scientific Positioning - 17 -

jects involved.73 Theories are built and explained step-by-step using agreed-
upon terms of the ortho-language. Inter-subjective comprehensibility is
therefore ensured. This way, reconstructed theories can be presented in a
comprehensible way to well-meaning and qualified subjects.74
Based on the statements above, the positioning of this book is as follows:
Regarding the recognizability of real world phenomena, the author follows a
radical constructivist approach. This follows from the fact that a business
process is a logical ordering of activities. Thus it is a theoretical construct that
by nature cannot be observed in the real world. From a critical rationalist
view, business processes could be observed as the sum of their instantia-
tions. Since all that can be observed are the individual actions of process par-
ticipants, the process as a whole has to be constructed by the observer
through abstraction and generalization. It should be noted that we do not
refute the existence of a world-in-itself (i. e., a reality), but whether this real-
ity exists or not does not have an impact on the concepts discussed in this
book.
As for the process of modeling and theory-building, we follow the
methodical constructivist approach of the Erlangen School. Using a basic set
of terms introduced in chapters 2 and 3, the models and theories con-
structed in this book should be accessible to any well-meaning and qualified
subject. The consequences of this position are as follows:75
„ An objective perception of a subject-independent reality is impossible.
Observations, deductions, inductions and subsequent statements are
based on a subject-dependent construction of reality. Therefore, a val-
idation of the statements given in this book against an objective reality
is not possible. Instead, the viability of the statements can be tested by
judging their “fit” into the constructed reality.
„ The subjects of this book are organizational processes and the oppor-
tunities to manage and control them with the help of an information
system. An organizational process is a conceptual entity. Unlike a
73. It should be noted that the Erlangen School relies on a given consensus about elementary
situations (Elementarsituationen des lebensweltlichen Erfahrens) and their terms. If no consensus is
presupposed, the deductive explanation of a certain word’s meaning leads to the problem of
Fries’ trilemma (Münchhausen-Trilemma). According to this trilemma, the deductive search for
an ultimate explanation leads either to an infinite regress, because every term that is used
for explanation can be questioned in turn, a vicious circle, because the explanation uses
terms that have been questioned before, or a dogmatic decision to suspend the procedure.
See Mittelstraß (Münchhausen-Trilemma) (1995), pp. 945-946 and Schütte (1997), pp. 33-
34.
74.
The property of well-meaningness is illustrated in POPPER’S assertion: “No rational argu-
ment will have a rational effect on a man who does not want to adopt a rational attitude.”
Popper (1947), p. 231.
75.
For a similar discussion of consequences compare Vering (2002), p. 12-13 and Meise (2000),
p. 7-8.
- 18 - Procedure Model

material object a process has no physical manifestation, other than (in

some instances) the output of the process. Therefore, the representa-
tion of a process in terms of a (formal) model is a theoretical con-
struct, whose features cannot be tested or validated against the
features of objectively perceivable “real world” entities.
„ An objective measure for the quality of the theories presented in this
book cannot be given. The goal of this book is instead the construc-
tion of inter-subjective comprehensible models and theories, which
can be evaluated by a group of well-meaning and qualified subjects.
This relates, for example, to the question of which metrics should be
used to determine the efficiency of a given process.
„ Due to the nature of constructivist perception, the same environmen-
tal situation can be observed and interpreted differently by different
subjects. In the context of process controlling, this means that given
the same values of the same set of parameters, different subjects may
arrive at different conclusions.
„ The problem of inter-subjectivity is evident with regard to linguistic
terms and expressions. In order to achieve a similar understanding of
the meaning of the basic terms, an initial discourse is necessary. This
discourse does not need to be complete and exact, but it has to fit the
situation in order to avoid an overly complex formal procedure.
„ The development of a terminological foundation is especially impor-
tant as this book is positioned at the junction of enterprise controlling
and information system design. In order to create models and theories
that are meaningful for both domains, a common understanding of
central terms has to be established, and potential homonym– and syn-
onym–conflicts have to be eliminated.76

1.6 Procedure Model

The goal of scientific work typically involves the finding of explanations
for certain phenomena77 or the formulation of recommendations for
actions. The discipline of information systems follows this separation by
pursuing both prescriptive and descriptive research approaches.78 While pre-
scriptive information systems research aims at the development and formu-

76.
For a deeper discussion of homonym and synonym conflicts in multi-domain environments
refer to Rosemann (1996), pp. 187-189.
77. KIM points out that “Just about anything can be the object of explanation: A concept, a
rule, the meaning of a word, the point of a chess move, the structure of a novel.” Kim
(1999), p. 298.
78.
Refer to Becker (1995), p. 133ff.
Procedure Model - 19 -

lation of design rules and guidelines for information technology and its
organizational deployment, descriptive information systems research works
to explain organizational and technological phenomena. For each of these
approaches methodical goals and functional goals can be distinguished.
Information systems research pursuing functional goals aims at the (descrip-
tive or prescriptive) development of information technology and its applica-
tions within a particular industry (e. g., the retailing industry or the
manufacturing domain). Following methodical goals, information system
research aims at the development of domain-independent methods and
techniques for the efficient development and application of information
technology in business scenarios.
In order to deliver a meaningful contribution to the field of information
systems, any information systems research has to generate results within this
portfolio. The goal of this book is the development of design methods for
process information systems based on information generated by workflow
management systems. Therefore, the focus of this book is the methodical
goal of information systems research, which is pursued using both descrip-
tive and prescriptive approaches. The central goals of this book, shown in
table 1-2, are positioned in the context of this portfolio.
Based on the analysis of the goals and functions of process management
and process controlling, the role of process controlling in the context of
other enterprise controlling functions is analyzed. Parallel to this, the sup-
port of process organizations through workflow management technology is
researched, and the quality of controlling information supplied by workflow
management systems is assessed.
The results of these analyses lead to the prescriptive development of an
information system architecture for the purpose of workflow-based process
controlling. Both methodical and architectural aspects are discussed and a
reference meta model for workflow-based controlling information is devel-
oped. The functional goal of this book is the confirmation of the concepts
through a case study at an insurance company. Finally, the development of a
research prototype based on the reference architecture serves as a feasibility
study for the ideas discussed.
- 20 - Structure of the Book

Descriptive Approach Prescriptive Approach

„ Analysis of process management „ Development of a reference meta

and controlling goals and func- model for workflow audit trail
tions information
„ Analysis of workflow technology „ Development of a data model for
Methodical support for process organizations the integration of workflow audit
Goal
„ Analysis of controlling informa- trail data in process controlling
tion supplied by workflow man- systems
agement systems „ Implementation of a prototype
process controlling system

„ Description of process controlling

Domain- requirements in an insurance
Specific Goal
industry case study

Table 1-2: Positioning of the Book

1.7 Structure of the Book

The book is structured in six chapters. Following this introductory chap-
ter, the second chapter discusses the management requirements and meth-
ods for process organizations. A system theoretic analysis of organizational
functions serves as the basis for the definition of central terms and the intro-
duction of a management framework. Based on this framework, manage-
ment and controlling of process organizations at the strategic and
operational level are discussed. We define process management and control-
ling, and introduce a life-cycle model for organizational processes and their
automation.
Chapter three presents workflow management systems as a technological
support platform for the implementation of process-oriented organizations.
After a discussion of the history and current status of workflow technology,
integration and coordination functions are presented on a conceptual level.
Following a review of the current level of standardization for workflow
management systems, the development and application of workflow-based
application systems is outlined. This discussion leads to the introduction of
the concept of workflow-based monitoring and controlling.
Chapter four discusses the use of workflow technology for controlling
purposes at the management levels established in chapter two. Following a
review of related approaches, we analyze the information supplied through
workflow audit trail data and develop a reference meta model of audit trail
information. In the next section, we develop a conceptual framework for
process controlling based on workflow audit trail data. Beginning with dif-
ferent categories of analysis, we outline the integration of audit trail informa-
tion in the enterprise controlling infrastructure. Finally, we integrate the
Structure of the Book - 21 -

information supply framework and analysis perspectives into a cybernetic

process controlling framework.
Chapter five illustrates the practical relevance of the previous discussion
using a case study from the domain of financial services. Following this sec-
tion, a prototypical implementation of a process controlling system is pre-
sented. The system architecture and the underlying data model are discussed
on a conceptual level, and sample evaluation methods are illustrated.
Chapter six reviews the findings of the book and present potential topics
for future research. Figure 1-3 shows a graphical representation of the struc-
ture of this book.

Figure 1-3: Structure of the Book

- 22 - Structure of the Book
A System Theoretic Framework for Organizational Analysis - 23 -

2 Management Support for Process Organizations

In this chapter we discuss the organizational foundations that contribute
to the topic of process monitoring and controlling. Starting from a system
theoretic view of organizations we discuss the role of management and con-
trol in relation to an organization’s processes. In chapter 2.1 we introduce
the foundation of system theory that is applied to the analysis of companies
in subsequent chapters. Chapter 2.2 provides an overview of processes in
organizations, the design of organizations around their processes, and
frameworks to describe and analyze these processes. We introduce a taxon-
omy of business processes and use the ARIS architecture as an example
framework for the analysis of business processes. Chapter 2.3 gives an over-
view of management activities that relate to an organization’s processes. In
particular, we focus on the differentiation between strategic and operative
management, and look at the functions of management control. After defin-
ing management control and its activities we use the cybernetic control loop
to further specify the activities of management control. Chapter 2.4 exam-
ines the management control aspect in more detail by looking at controlling
activities in the organization. We differentiate controlling from the field of
management accounting and introduce different controlling views from the
German business administration literature. Using WEBER’S definition of
rational controlling, we focus on the role of controlling in process-oriented
organizations. Chapter 2.5 synthesizes the results of the previous chapters
and applies them to business processes, setting the scope for the subsequent
chapters of this book. We define process management and process control-
ling, develop a life-cycle of business process management, and position pro-
cess management and controlling as phases of the overall process life-cycle.

2.1 A System Theoretic Framework for Organizational Analysis

A company, in the broadest sense, creates goods or provides services. In
order to achieve this, logistics processes for the sourcing, manufacturing,
storage and delivery of these goods and services have to be performed.
Input factors, such as other goods and services are consumed or trans-
formed in these processes.78 These logistics processes are connected with
financial processes which involve the raising, appropriation, and investment
of funds.79 Both the flow of goods and the flow of monetary assets form the
operative system of the firm. The goal of a firm’s operative processes is the
creation or use of tangible and intangible goods. (By contrast, the goal of
certain governmental processes is the impact on social structures.80) In most
78.
Compare Küpper (2001), p. 13.
79.
Küpper (2001), p. 13.
- 24 - A System Theoretic Framework for Organizational Analysis

cases the tasks performed in the operative system and the decision making
about aspects of the operative system are performed by different parties.
Therefore, the activities of these parties have to be coordinated in order to
contribute to the overall goals of the enterprise.
In order to understand the internal structure and behavior of different
organizational subsystems and their connections, we need a way to structure
and analyze these entities. Typically this is done using abstract representa-
tions of actual organizational facts, i. e. models. The term model has a differ-
ent notion in different scientific disciplines.81 In this book we base our
understanding of the term model on the definition of SCHÜTTE.82 A model is
an artificial construct designed using a particular language (the modeling language).
It is a representation of an original that is relevant at a certain time for the pur-
pose of a recipient (the model user). The creator and the user of a model may
or may not be the same entity. Therefore, the building blocks of a model are
an original, the construction process, the model user, a certain time of rele-
vance and a modeling language.
Particularly in the discipline of information systems, a large number of
modeling formalisms exist for purposes such as data modeling, process
modeling, or organizational modeling. In order to define and compare these
different modeling languages, we can use meta-models. A meta model is a
model that describes the grammar of the modeling language (i. e., the ele-
ments that can be used to construct models in the modeling language) and
the usage of the grammar (i. e., rules that describe the correct construction
of models using the grammatical elements available).83 A meta model can be
expressed in the same language as the modeling language it describes. For
instance, a dictionary (meta model) can be written in the same language as
the vocabulary it defines (modeling language).84

80.
Compare Küpper (2001), p. 13.
81.
Refer to Köhler (1975), col. 2702; Lehner (1994), pp. 16f.; Lehner, Hildebrand, Maier
(1995), pp. 32f.
82. Refer to Schütte (1998), p. 59 and SCHÜTTE’S extensive discussion of this definition on
pp. 40-62.
83.
Compare Strahringer (1996), who distinguishes language-oriented meta models such as the
one described in the text, and process-oriented meta models that describe the procedure of
creating a model using a specific modeling language. For example, while a dictionary
explains the vocabulary of a language (i. e., the syntax and semantics of the language ele-
ments), a style-guide explains the proper design of sentences and expressions in that lan-
guage (i. e., the process of creating a model using the language). In this sense, the dictionary
contains the language-oriented meta model, while the style-guide contains the process-ori-
ented meta model of the language. For a discussion of both types of meta models compare
Holten (1999), pp. 11-18.
84. Note that the meta meta model of the example given could be the instructions for using the
dictionary (i. e., the process-oriented meta (meta) model for applying the elements of the
(meta) model level). However, this meta meta model would have no impact on the elements
at the model level (a sentence in a particular language), because of the change in meta-
abstraction (from language-oriented to process-oriented). Compare Strahringer (1996),
p. 26; Holten (1999), p. 17.
A System Theoretic Framework for Organizational Analysis - 25 -

The system theoretic view of the company offers a framework for the
analysis of organizations in whole or in part. Within this book, we use orga-
nizational models that are based on the concepts found within system the-
ory.85 The elements of system theory thus form the basic vocabulary for our
modeling language. The following sections provide an overview of the gen-
eral principles of system theory, and outline, how these concepts relate to
the structuring of organizations.

2.1.1 Systems and System Theory

General system theory deals with the description of the structure and
behavior of (complex) systems. It is composed of a number of independent
scientific movements that originated in the 1940s. Biological system theory,
regarded by many as the origin of system theory in general, was founded by
the biologist LUDWIG VON BERTALANFFY.86 NORBERT WIENER used sys-
tem thinking for the analysis of the information flow within and between
systems, and founded the discipline of cybernetics.87 Simultaneously with
WIENER, CLAUDE SHANNON researched the mathematical foundations for
the reliable transmission of messages within information systems.88 His
information theory is another example of a system theoretic movement.
A system in its most general form is a set of entities and relationships
between these entities.89 Formally defined a system S consists of a triple (E,
R, U) where E contains the entities of the system and R contains the rela-
tionships between those entities. Systems can be nested, i. e. the elements of
a system can be other systems, forming a hierarchy of systems and sub-sys-
tems. From the perspective of a lower-level system, the higher-level systems
form the environment. In this case, the subordinate systems are called sub-

85. Note that we apply SCHÜTTE’S definition of a model using the vocabulary of system theory.
This use should be distinguished from e. g. HORVÁTH’S definition of a model: “[Models]
are (simplified) images of real or mental systems (e. g. the model of a house, data flow plan
of an information system). [...] Only the empirical evaluation shows, whether the results of
modeling are a reflection of reality.” Horváth (2001), pp. 101-102. This definition conflicts
with the constructivist standpoint outlined in chapter 1. Since reality cannot be observed in
an objective way, it is impossible to create an (objective) image of reality. Models are always
results of the subjective act of modeling by a modeler. The original from which a model is
constructed is the result of individual cognition (i. e., a model in itself). Only the use of an
agreed-upon modeling language and the fitness of a model for the purpose of the model
user can ensure the usability of a model. Furthermore, HORVÁTH’S definition restricts the
use of models to the representation of systems. Since systems are mental constructs in their
own right, the term “real [...] systems” is misleading. Compare Schütte (1998), p. 47, espe-
cially footnote 49.
86.
See von Bertalanffy (1968), pp. 8ff.; Ferstl, Sinz (1993), pp. 11ff.; Hill, Fehlbaum, Ulrich
(1994), p. 20; Lehner, Hildebrand, Maier (1995), pp. 44-57; Rosemann (1996), p. 14.
87.
Refer to Wiener (1948).
88.
Refer to Shannon (1948).
89.
ACKOFF defines a system as “a set of interrelated elements. Thus a system is an entity which
is composed of at least two elements and a relation that holds between each of its elements
and at least one other element in the set. [...] Furthermore, no subset of elements is unre-
lated to any other subset.” Ackoff (1971), p. 662.
- 26 - A System Theoretic Framework for Organizational Analysis

systems, the root system is called super-system. U is the world external to

the system (Umwelt), also called the environment.90 E is also called the uni-
verse of S, while R is the structure or S. E and R are non-empty sets, while
the section of E and U is empty.91
Systems can be classified according to different attributes.92 HILL ET AL.
distinguish between openness, complexity and dynamics.93 If relationships
exist between a system element e and an element of the environment u, a sys-
tem is called open system. Contrary, a closed system only contains relationships
between the elements of the system itself. The structural complexity of a system
describes the variety94 of the elements and relationships within the system
(i. e., their structural differences). The total number of (potentially similar)
elements and relationships within a system determines the organizational com-
plexity of the system.95
The state of a system is the set of relevant system properties at a given
point in time.96 In particular, a given system can be in different states at the
same time, if these states relate to different properties of the system.97 The
rate of change of a system’s state determines the dynamics of the system.98
Accordingly, a dynamic system has an inner state that can be changed through
inputs and that leads to an output of some sort, while a static system does not
90. In the aforementioned case of sub- and super-systems, the super-system constitutes the
environment of its sub-systems. Not all sub-systems need to be aware of the existence of all
other sub-systems. Instead, a system’s environment is usually treated as a black box.
91.
Compare Siegwart (1996), p. 191 and the references cited there.
92.
A classification of system attributes is provided e. g. by Ackoff (1971), pp. 662-667 and
Haberfellner (1974), p. 17.
93.
See Hill, Fehlbaum, Ulrich (1994), p. 22ff.
94.
Variety is defined as the set of distinguishable elements of a system, or the set of distin-
guishable states a system can be in. For example, a system containing the elements (a, b, c,
c, d, b, a, b, a) has a variety of four, since there are four distinguishable elements (a, b, c, d).
Compare Ashby (1956), pp. 121-126.
95.
The terms structural and organizational complexity relate to the German terms Komplexität
and Kompliziertheit, respectively. While the proper English translation for Kompliziertheit is
complexity, the use of the proper term would confuse the distinction between the two
terms, therefore the attributes structural and organizational are added. Within the scientific
literature, the distinction between structural and organizational complexity is discussed dif-
ferently. Bronner (1992), col. 1122, defines the combination of structural and organizational
complexity as complexity in the wider sense. Ropohl (1979), pp. 71f., derives the structural
complexity of a system from the number of different relationships, while the organizational
complexity is determined by the number of different sub-systems. Lehner, Hildebrand and
Maier (1995), p. 49, see the dynamics of a system as the source of its complexity. Sinz
(1996), p. 127, differentiates between extensional complexity, describing the number of a
specific element type, and complexity at the type level, which is a result of the difference
between system elements. Also refer to Kruse (1996), p. 28 and p. 34.
96.
Compare Ackoff (1971), p. 662.
97.
For example, a convertible car as a mechanical system can be in the state “moving” from
the perspective of a traffic observer, while it is in the state “roof closed” from the perspec-
tive of an exterior designer.
98.
ASHBY defines the state of a system as “any well defined condition or property which can
be recognized if it occurs again.”Ashby (1956), p. 25. State changes are often induced by an
interaction of a system with its environment. ACKOFF consequently defines the environ-
ment of a system as a set of elements and properties which can produce a change in the sys-
tem’s state. See Ackoff (1971), pp. 662-663.
A System Theoretic Framework for Organizational Analysis - 27 -

exhibit state changes.99 A special category of dynamic systems are homeostatic

systems, which are capable of maintaining a specific state in a changing envi-
ronment through internal adjustment.100
HABERFELLNER distinguishes between natural and artificial systems
depending on their creator, as well as specific or abstract systems, depending
on whether the system is a mental construction or represented through
“real” objects (compare figure 2-1 ).101

Source: Compare Haberfellner (1974), p. 17.

Figure 2-1: Taxonomy of System Concepts
The representation of a system can be organized by one of three different
system views:102
„ The hierarchical system view focuses on the composition of (super-)sys-
tems through other (sub-)systems. There is no limit to the number of
system levels that can be nested.103 The introduction of system hierar-
chies enables system designers to refine coarse systems (top-down-
approach) or to abstract from detailed systems (bottom-up-approach).
„ The functional system view focuses on the dynamic behavior of a system.
A typical view from the functional viewpoint is that of a system as an
99.
Compare Hill, Fehlbaum, Ulrich (1994), p. 23; Lehner, Hildebrand, Maier (1995), p. 50.
100.
Compare Ackoff (1971), p. 664. In order to remain stable in a changing environment, a sys-
tem needs to have as much internal variety as it is exposed to environmentally. This law of
requisite variety was first stated by ASHBY, see Ashby (1956), pp. 206-208. A homeostatic sys-
tem is an example of a system, which is capable of maintaining a stable state, also called an
equilibrium, refer to Ashby (1956), pp. 82-85.
101.Compare Haberfellner (1974), pp. 16-27. Note that this notion seems to conflict with the
world view used within this book. However, the constructivist philosophy simply states that
a reality cannot be perceived objectively. Whether such a reality exists is thus not relevant
for the evaluation of model quality. From a radical constructivist point of view every system
is a construction of the mind and thus an artificial system. For reasons of simplicity, HAB-
ERFELLNER’S classification of systems is shown in the original form.
102.
Compare e. g.Teubner (1999), p. 14-15 and the references cited there.
103.
While a hierarchical system view is a suitable way to abstract from or detail specific parts of
a system, a recursive repetition of systems within systems is a way to provide inheritance of
system attributes or behavior, comparable to the inheritance concept of object-orientation
(compare e. g. Oestereich (1997), pp. 38-41). An example is the viable system model by
BEER, which consists of 5 distinct systems in a recursive structure, i. e., the internal compo-
sition of the (sub-)systems 1A to 1D consists of the 5 distinct systems on a lower level of
recursion. Compare Holten (1999), pp. 142-153 and the references cited there.
- 28 - A System Theoretic Framework for Organizational Analysis

opaque entity (i. e., a black-box) that has certain inputs and outputs.
The system is fed via its inputs and produces a certain output. It can
be either stateful or stateless. In a stateful system, the behavior of the
system is influenced through inputs. As a typical result, a similar input
applied subsequently to such a system may produce a different output
than the original input, because the state of the system has changed
through the first operation. A stateless system does not exhibit this
behavior, i. e., the same input will always result in the same output.
„ The structural system view focuses on the organization of entities and
relationships within a system. This view can be built through a func-
tional or a structural analysis. The functional analysis tries to explain
the inner workings and behavior of a system (which is observed in the
dynamic view). The structural analysis leads to the development of
entity clusters whose internal relationships are significantly stronger
than relationships between this cluster and its environment.104 In
contrast, the functional analysis leads to abstract entity clusters that
can only be distinguished through their functions, but not necessarily
through their relationships to other entities.
The three different perspectives on systems are depicted in figure 2-2.

Inherent Dangers of the System View

The system theoretic analysis of organization poses certain perils, some
of which have been pointed out by HORVÁTH:105
„ Organizations can be perceived and structured as systems, but they are
not systems per se. A system view of the enterprise is only a mental
framework for further analysis.106
„ The assumption of teleological behavior is problematic, i. e., the
explanation of an element’s behavior through the behavior of the sur-
rounding system. This is especially true when the entities of the sys-
tem exhibit a certain behavior that cannot be attributed to system

104.
Compare Teubner (1999), p. 15.
105.
Compare Horváth (2002), pp. 104-106. HORVÁTH points out that talking about systems
does not provide empirical evidence of real world events (Horváth (2002), p. 105). Hor-
váth’s argument can be interpreted in the sense that the structure and behavior of a system
(i. e., an abstraction of a more complex underlying entity) does not necessarily have a direct
equivalent in the underlying entity (which may also be perceived as a system). One crucial
requirement for systems engineering efforts that can be derived from this insight is the
incorporation of well-defined quality guidelines for systems design. These guidelines have
been proposed by BECKER, ROSEMANN, SCHÜTTE and others as the Guidelines of Model-
ing (GoM). Compare Becker, Rosemann, Schütte (1995); Becker, Schütte (1996); Becker,
Rosemann, von Uthmann (2000). For quality guidelines for reference modeling see Schütte
(1998).
106.
Horváth (2002), p. 105.
A System Theoretic Framework for Organizational Analysis - 29 -

Source: Compare Teubner (1999), p. 14; Seiffert (1992), p. 127.

Figure 2-2: Perspectives on Systems
itself. From a system theoretic perspective, a company is comprised of
actors, who exhibit more or less rational behavior, but a generalization
of this behavior to the level of the company is problematic.107

Advantages of the System View

Advantages of the system theoretic view are mainly related to the reduced
complexity of the studied organization through systems engineering108:
„ Complex corporate relationships can be analyzed more easily. Within
the management and controlling aspect of organizational design this
means that planning and control activities, information objects and
their infrastructure can be segmented and analyzed separately; unre-
lated parts of the organization do not have to be considered.
„ Systems building is helpful for the isolation of interesting system
dimensions. Through the exclusion of irrelevant details the organiza-
tional complexity of the resulting system is reduced.
„ A system view of the organization is a valuable instrument for the
design of technical systems that are employed within an organization,
such as the information technology infrastructure.

107.
Compare Lawrence, Lorsch (1969), p. 2.
108.
Compare Horváth (2002), p. 105.
- 30 - A System Theoretic Framework for Organizational Analysis

„ The view of the organization as a system fosters the analysis of ongo-

ing system changes, therefore it enables the dynamic control and regu-
lation of system aspects.

2.1.2 Companies as Socio-Technical Systems

Organizations, and thus companies can be perceived as socio-technical
systems that are goal-oriented, have a specific purpose109, have relationships
to outside entities (i. e., they are open systems), exhibit a significant com-
plexity both in terms of structure and organization, and change within their
structure and organization over time (i. e., they are dynamic systems).110 The
constituting characteristic of a company as a system is the (artificial) demar-
cation between the company and the outside world.111 Typically this demar-
cation is based on the specific goals and objectives of the organization.

Organizational Goals and Objectives

Organizations are founded to achieve certain goals and objectives.112
These goals have a direct impact on the structure and behavior of the orga-
nization.113 In order to achieve these goals, different parts of the organiza-
tion are specialized on the achievement of individual goals. For example, the
task of the human resource staff relates to the system goals in the following
way: they are responsible for supplying qualified resources to carry out the
tasks within the enterprise, but they are typically not responsible for product
goals.
Organizational goals have a controlling function, since they can serve as a
benchmark for alternatives within decision processes in the organization.114
If several choices exist for a particular decision, an evaluation using the orga-
nization’s goals results in a ranking of alternatives, ultimately increasing the
quality of decision making if the best alternative is chosen (i. e., the one con-
tributing most to the goals). An important distinction can be made between
the overall goals of the organization (sometimes called enterprise goals) and

109.
Companies are purpose-oriented, because they produce an output, which is in the interest
of their environment, e. g. a product that satisfies the needs of customers. In the following
sections, the term organization is used as a synonym for the terms company and enterprise.
110.Compare for example Hill, Fehlbaum, Ulrich (1994), pp. 20ff; Schulte-Zurhausen (1999),
p. 36.
111.
Compare Luhmann (1991), pp. 34ff.
112.
Compare Staehle (1999), p. 437.
113.
Compare Staehle (1999), p. 437-452. He points out that the objectives and the goals of an
organization can (and should) be distinguished. While the objectives of an organization rep-
resent its contribution to its environment (e. g. society in general), and justify the existence
of the organization overall, the goals represent the organizational state or behavior that the
organization and its members strive to achieve. See Staehle (1999) p. 438.
114.
For an overview of organizational goals see Kugeler (2000), pp. 24-26.
A System Theoretic Framework for Organizational Analysis - 31 -

efficiency goals, which relate to the organizational structure and behavior of

the organization.115
Within this book, efficiency is defined as a relational predicate116 which
enables the user to evaluate the design or the result of organizational activi-
ties using multi-valued attributes. Effectiveness describes the overall suitability
of an activity, a structure, etc., to achieve a certain goal or objective.117 It is
mandatory for an organization to be effective in the sense that both its struc-
ture and its behavior contribute to the organization’s goal. The selection of
the appropriate structure and behavior that ensure the most effective pursuit
of the goal is the central task of organizational design.
Efficiency goals are a general guideline for organizational design, but they
cannot be interpreted as a blueprint for the design of an optimal organiza-
tional structure. LAWRENCE and LORSCH have pointed out that the consis-
tency of an organization’s internal states and processes with external
demands is an indicator for the effectiveness of the organization’s behav-
ior.118 This contingency theory states that there is not just one optimal structure
for any given organization. Instead, the optimal organizational structure (in
the sense of being the most effective and efficient) depends on both the
internal state of the organization as well as the conditions of its environ-
ment. Additionally, the degree of differentiation inside the organization
should reflect the diversity of the organization’s environment.119 This obser-
vation is consistent with ASHBY’S law of requisite variety, which states that a

115.The institutional organizational theory, which is dominant in the Anglo-American literature

(compare Hill, Fehlbaum, Ulrich (1994), p. 17; Voßbein (1989), p. 9), often fails to make
this distinction (compare Kugeler (2000), pp. 29-37 and the references cited there).
KUGELER points out that this unified view of organizational goals fails to acknowledge the
indirect relationship between organizational measures and (structural) organizational goals,
such as maximization of the return on capital invested. An appropriate counter-measure is
the definition of efficiency goals, which serve as sub-goals that are positively correlated with
the overall goals of the organization and which are instrumental in the evaluation of organi-
zational measures. Compare v. Werder (1999), p. 412.
A typical example for the integrated view of organizational goals is the classification by
PERROW, who distinguishes five goal categories:
„ Society goals address the society in general.
„ Output goals address the recipients of the organization’s output, i. e., its goods and ser-
vices.
„ System goals address the structure and behavior of the organization, e. g., growth, stability,
profitability.
„ Product goals address the characteristics of goods or services produced by the organiza-
tion, e. g., quantity, quality, design etc.
„ Derived goals address areas outside the primary organizational objectives, e. g., political
activities or regional development.
Compare Perrow (1970), p. 135, cited from Staehle (1999), p. 438.
116.
The expression relational predicate refers to the fact that different types of efficiency can be
distinguished, and that two measures of the same efficiency type can be compared directly.
117.
Refer to Kugeler (2000), p. 28; Welge, Fessmann (1980), col. 577.
118.
See Lawrence, Lorsch (1967), pp. 128-129.
119.
See Lawrence, Lorsch (1967), p. 128.
- 32 - A System Theoretic Framework for Organizational Analysis

system needs to expose at least as much variety internally as it is exposed to

externally, if it wants to maintain a stable state.120
The efficiency goals used within this book are based on the works of
FRESE, THEUVSEN and V. WERDER.121 The three organizational efficiency
goals are coordination efficiency, motivation efficiency and adjustment efficiency. Fur-
thermore, coordination efficiency can be broken down into the components
resource efficiency, process efficiency, motivation efficiency and delegation efficiency.
Figure 2-3 shows the relationship between these different organizational
efficiency goals.

Source: Compare Kugeler (2000), pp. 37-54.

Figure 2-3: Efficiency Goals
Because efficiency goals are not operational in the sense that they cannot
be readily measured, they need to be replaced by substitute goals in practice.
These substitute goals should have a positive contribution toward the substi-
tuted goal. For example, the reduction of cycle and idle times has a positive
impact on process efficiency, while a maximization of resource capacity uti-
lized has a positive influence on resource efficiency.

120.SeeAshby (1956), pp. 206-208 and the definition of a homeostatic system in footnote 100
on page 27.
121.
Compare Frese (2000), pp. 292ff.; Theuvsen (1996).; v. Werder (1998) and v. Werder
(1999).
A System Theoretic Framework for Organizational Analysis - 33 -

It is important to note that a simultaneous optimization of all efficiency

goals is not possible, since measures that improve one type of efficiency
often decrease another type of efficiency. Figure 2-4 shows potential syner-
gies and conflicts between efficiency goals.122

Source: Compare Kugeler (2000), pp. 55-57.

Figure 2-4: Conflicts and Synergies between Efficiency Goals
Especially problematic is the simultaneous pursuit of process and
resource efficiency.123 On the one hand, a specialization of resources (which
increases resource efficiency) increases the number of organizational inter-
faces in a process and thus has a negative impact on process turnaround
times (decreasing process efficiency). On the other hand, the unification of
activities through job enlargement (which reduces organizational interfaces
and increases process efficiency) has a negative impact on resource effi-
ciency, because the capacity of available resources can only be allocated on a
coarse level and this may lead to under-utilized resources.

122.For a thorough discussion of the relationship between efficiency goals compare Kugeler
(2000), pp. 55-57.
123.
This effect is known as the planning dilemma (Dilemma der Ablaufplanung), compare e. g.
Gutenberg (1983), p. 216; Adam (1998), p. 549.
- 34 - A System Theoretic Framework for Organizational Analysis

Management and Operative System

A common distinction made in the system-theoretic analysis of organiza-
tions is the separation of the decision making part of an organization (the
management system) from the operating part of the enterprise (the operative
system).124
The operative system of the enterprise transforms an input stream of
goods and services (upstream, supply chain) along the logistics processes to
an output stream that is delivered to the customer (downstream, demand
chain). In return a flow of monetary values is received through financial pro-
cesses and passed on to the suppliers as compensation for their goods and
services. Each of the logistics and financial processes is encompassed by,
and can be represented as an information flow.125 A financial transaction is
represented in terms of invoices, postings and account statements, while a
flow of physical products is accompanied by the relevant purchase orders,
bill of materials, assembly lists, or delivery notes. The creation, storage, and
management of these information objects is the purpose of the operative

124.Compare e. g. Horváth (2002), p. 112. The roots for this distinctions can be found in TAY-
LOR’S work on scientific management, which was originally published 1911 (Compare Tay-
lor (1947)). The separation between management and operative system has been criticized
by some authors, compare for example Weber (1999), pp. 28-29. This criticism relates to
the normative separation of management and operative systems, i. e., there is a lack of argu-
ments why a certain system configuration is chosen as opposed to other possible configura-
tions. In addition, critics of the system approach point out that in reality management and
operative functions are closely interwoven in certain areas (e. g., group-concepts in manu-
facturing). While these arguments are clearly valid (see the discussion in section 2.4.1 on
page 70), we use the separation of management and operative functions as a model, i. e., an
abstract representation of an organization, to explain the flow of information at different
levels of the enterprise.
125.
For a thorough discussion of the term information refer to Holten (1999), pp. 71-74 and
the references cited there. HOLTEN uses the framework defined by Bode (1997). According
to this framework, information can be classified within the dimensions dynamics, novelty,
truth, semiotics and carrier. From a semiotic perspective, information can either be defined in
a syntactic, semantic, or pragmatic way. The syntactical definition describes information as a
sequence of characters. The semantic approach defines information as a representation of
an object, i. e., information is a sequence of characters with a specific meaning, while the
pragmatic approach stresses the purpose of information, i. e., information has to be useful
for the preparation of decisions or activities. Information can be perceived as dynamic if the
process of informing a recipient is addressed. In a static sense, information relates to the
precondition and result of the information process. In terms of novelty, information can be
characterized as unknown to the recipient (individual-subjective view) or unknown within a
certain context (objective view). The aspect truth distinguishes between truth-dependent
information, i. e., information has to be true, or the sender has to believe in the correctness
of the information, and truth-independent information, i. e., there is a possibility that the
information is incorrect. Finally, information can be either restricted to humans as informa-
tion carriers, or the storage and transmission of information through technical resources is
accepted without altering the characteristics of information.
For the purpose of this book, information is defined as the representation of an object in a
particular language. Compare Bode (1997), p. 459. In the context of computer systems,
information denotes the technical representation of an object which is stored, manipulated,
transmitted, and/or displayed through the computer system. On a conceptual level, infor-
mation is a higher form of data, which is defined as a sequence of characters. Data has to be
distinguished from programs (or applications), which manipulate, store, retrieve, and/or
display data. Information relates to economically relevant entities of the company, e. g., an
invoice or a customer account, and is context-dependent, i. e., information is bound to a
particular purpose.
A System Theoretic Framework for Organizational Analysis - 35 -

information system of a company. The operative information system is typi-

cally connected to entities outside of the company through cross-enterprise
application integration or Business-to-Business integration (CEAI or B2BI).
CEAI links the operative information systems of organizations along the
supply chain in the support of recurring business transactions, such as order
placement, invoicing and offer solicitation.126 Similar integration exists in
the demand chain, where customer self-service applications and order man-
agement functions (among others) mirror the supply chain functionality.
The operative system works with a given set of resources and according
to a set of rules that are defined by the planning and control system of the
organization. In order to be able to regulate the behavior of the operative
system, the planning and control system depends on information supplied
by the management information system.127 This system can be fed by infor-
mation from both in- and outside the company. Internal information can be
gathered from the operative information system. This information is typi-
cally filtered in order to reduce the amount of detailed information to the
level required by the recipient.128 External information can either originate
from suppliers (e. g., shipping dates for supplies), customers (e. g., demo-
graphic information), third parties (e. g., credit reports from rating agencies),
or government bodies (e. g., tax schedules). The management information
system provides information to the entities involved in planning and control
processes. This information is used to evaluate alternative strategies, or to
control the execution of prior strategic decisions. This part of the manage-
ment system is traditionally realized through the front-ends of on-line ana-
lytical processing systems (OLAP)129, or through the provisioning of
printed reports. More recently, real-time analytics and so-called corporate
dashboards are used to provide decision makers with information about
operational performance.130 Based on the results of the planning and con-
trol process, the planning and control system exercises influence on the
operative system by setting goals, defining procedures, issuing guidelines or
similar measures which have to be implemented by the operative system.

126.Examples for these integration efforts are standards such as ebXML, refer to ebXML
(2002), Biztalk, see Thatte (2001) or CDIF, refer to EIA (1997) and Flatscher (1997).
127.
The use of information technology for managerial purposes was first described by LEAVITT
and WHISLER, compare Leavitt, Whisler (1958). Many of the early systems failed, because
the first approaches to provide managers with a view on operative data through Manage-
ment Information Systems (MIS) were driven by technical progress instead of actual infor-
mation requirements. Compare Ackoff (1967), who especially criticized the lack of
relevance in the information provided by MIS. For a detailed description of the history of
management information systems refer to Holten (1999), pp. 29-59.
128.
See section 2.3.3 on page 60 for a more detailed discussion of this topic.
129.
Refer to Codd, Codd, Salley (1993), who first used the term OLAP to differentiate analyti-
cal database use from productive database use.
130.
See Houghton et al. (2004) for a case study of corporate dashboards at Western Digital.
- 36 - A System Theoretic Framework for Organizational Analysis

Figure 2-5 shows the relationship between the management system and the
operative system of the enterprise.131 It is apparent that the management
system impacts the operative system as a whole, but does not selectively
change details about the logistics or financial processes. In fact, direct inter-
vention by management constitutes a bypass of organizational control and is
discouraged by system theorists.132 Instead, the management system pro-
vides guidelines that have to be implemented by the units of the operative
system.

Source: Compare Horváth (2002), p. 117; Wiese (2000), pp. 8-9.

Figure 2-5: System View of the Enterprise

131.
The links between the logistics and financial processes are shown bidirectional to include
processes such as the handling of returns, recycling, financial discounts, and reimburse-
ments.
132.
Compare BEER’S viable system model as an example of organizational management and
control structures. Beer (1985); Espejo and Harnden (1989).
Process-orientation and Process Organizations - 37 -

2.2 Process-orientation and Process Organizations

2.2.1 Organizational Processes

The operative system of a company is the environment in which the
financial,133 logistics and information processes take place.134 These pro-
cesses provide the dynamic structure of the organization, taking goods and
services as input factors and transforming them into goods and services as
output factors, in order to satisfy customer demands.135 However, organiza-
tional processes are rarely homogeneous entities that are performed by indi-
viduals in their entirety. Due to the limited qualitative and quantitative
capacity of resources, processes are typically realized through the division of
work among different process participants.136 Companies were able to real-
ize significant economies of scale through the pooling of similar resources
and the specialization of functional units.
With an increasing number of functionally specialized process partici-
pants, the coordination of the overall process becomes increasingly impor-
tant, because every hand-off or interface between process participants does
not contribute to the original purpose of the process and thus does not sup-
port the goals of the organization.137 The dominance of the functional
structuring of organizations with a subsequent planning of the flow of work
between the participants has always faced concern138, but in the 1990s the
level of criticism rose to such a level that alternative organizational structures
were researched by numerous companies. As a consequence, the process-
oriented design of organizations began to attract significant interest. In order
to establish a common understanding of the concepts of process-organiza-
tions, we take a closer look at the origins of organizational processes in the
following section.

133.
It should be noted that in most cases the financial processes are represented as information
processes (e. .g. postings from one account to another). Therefore, some authors distin-
guish between material and information processes, compare e. g. Schulte-Zurhausen (1999),
p. 51-52. This perspective will be applied throughout the rest of this book.
134.
Certain information processes are also part of the management system, especially the sup-
ply of managers with information for decision making processes.
135.
Compare Schulte-Zurhausen (1999), p. 49-56.
136.
Compare Wiese (2000), p. 24; Schulte-Zurhausen (1999), p. 4.
137.
Compare Gaitanides, Scholz, Vrohlings (1994), p. 2.
138.
For an early critical view of functional organizations compare, e. g., Nordsieck (1931).
- 38 - Process-orientation and Process Organizations

2.2.2 Process Definitions

The central focus of process-oriented organizational design is the flow of
work within the organization.139 Despite the duration of the process discus-
sion in the scientific and popular literature,140 no common process defini-
tion has emerged as of today. To a large extent, the contemporary
definitions of business processes originated in the reengineering literature of
the 1990s. One of the most prominent process definitions of the 1990s was
given by HAMMER and CHAMPY, who focus on the external behavior of a
process, noting that a process is:
“[...] a collection of activities that takes one or more kinds of input and creates an
output that is of value to the customer.”141
In a more refined approach, DAVENPORT proposes the following defini-
tion:
“[...] a process is a structured, measured set of activities designed to produce a spe-
cific output for a particular customer or market. It implies a strong emphasis on
how work is done within an organization, in contrast to a product focus’s empha-
sis on what. A process is thus a specific ordering of work activities across time and
place, with a beginning, an end, and clearly identified inputs and outputs: a struc-
ture for action.”142
A proponent of Total Quality Management efforts, HARRINGTON,
defines a business process in the context of his Business Process Improve-
ment approach as:
“[...] any activity or group of activities that takes an input, adds value to it, and
provides an output to an internal or external customer. Processes use an organiza-
tion’s resources to provide definitive results.”143
More specifically, he distinguishes between this (general) process and
more specific production and business process.144 In a similar definition,
SCHMIDT describes a business process as:

139.
Compare Becker, Kahn (2002), p. 6. The German organizational theory outlined the dis-
tinction between the organizational structure (Aufbauorganisation) and the flow of work
(Ablauforganisation) for a long time.
140.Compare the notes in section 1.1 on page 1.
141.See Hammer, Champy (1993), pp. 35 ff. In a later publication, HAMMER defines a process
equally vague: “We can think of a process as a black box that effects a transformation, tak-
ing in certain inputs and turning them into outputs of greater value.” Hammer (1996), p. 9.
142.
Davenport (1993), p. 5.
143.
Harrington (1991), p. 9.
144.
Harrington defines a production process as “any process that comes into physical contact
with the hardware or software that will be delivered to an external customer [...], up to the
point the product is packaged [...].” Harrington (1991), p. 9. He specifically excludes ship-
ping and distribution processes.
Process-orientation and Process Organizations - 39 -

“[...] [the] stepwise procedure for transforming some given input into some desired
output. The transformation is consuming or using resources. A business process has
some form of outcome, i. e. goods or services produced for a customer or customers
either outside or inside the enterprise.”145
The above definitions are similar with regard to the dynamic system view
employed, they all stress the input-process-output character of organiza-
tional processes. Nevertheless, these definitions are not precise enough to
allow for a detailed description of organizational processes using informa-
tion models. For instance, the definitions do not address the criteria separat-
ing different processes within an organization, which is a crucial distinction
for the development of organizational process models.146 In the context of
this work, we define a process in the tradition of BECKER and SCHÜTTE as
follows:
A process is a discrete, holistic, temporal and logical sequence of those
activities that are necessary to manipulate an economically relevant
object.147 This object is also called the process object and characterizes the
process. Additional supporting objects may become part of the process.
Depending on the properties of the process object, we can distinguish
between material and information objects.
Business processes are a specific category of processes.148 A business process
is defined as a high level process determined by the overall goals of the
enterprise.149 Business processes contain activities that interface with mar-
ket partners (i. e., customers, suppliers, or other third parties).
A workflow is a specific representation of a process, which is designed in
such a way that the formal coordination mechanisms150 between activities,
applications, and process participants can be controlled by an information
system, the so-called workflow management system.151

145.Compare Schmidt (1998), p. 192.

146.DAVENPORT describes this problem as follows: “Once the processes have been identified
at a high level, the boundaries between those processes need to be managed. Because pro-
cess definition is more art than science, boundaries are arbitrary.” Davenport (1993),
pp. 30-31.
147.Compare Becker, Schütte (1996), pp. 52-53; Rosemann (1996), p. 9; Becker, Kahn (2002),
p. 6.
148.
Although many authors use the terms process and business process as synonyms, we feel
that the distinction adds value.
149.
Compare Nordsieck (1972), col. 8-9, who defines the enterprise process as the stepwise
refinement of the enterprise goal.
150.A coordination mechanism is defined as “a construct consisting of a coordinative protocol
(an integrated set of procedures and conventions stipulating the articulation of interdepen-
dent distributed activities) and an artifact (a permanent symbolic construct) in which the
protocol is objectified.” Schmidt, Simone (1996). For a detailed discussion refer to section
3.2.3 on page 110.
151.
Compare zur Muehlen (1996); Rosemann, zur Muehlen (1998), p. 103. For a thorough dis-
cussion of workflows and workflow management systems refer to chapter 3 on page 89.
- 40 - Process-orientation and Process Organizations

2.2.3 A Taxonomy of Organizational Processes

Processes in organizations can be grouped into several categories,
depending on the nature of the process object. While logistics processes are per-
formed with the goal of manipulating a physical object or provisioning a ser-
vice (e. g., manufacturing a certain product or moving a shipment to a new
location), financial processes are performed when monetary value is exchanged
between two parties. Each of these processes is accompanied by an informa-
tion process, which represents the flow of data in the company’s information
systems that is caused by the relevant logistics or financial processes.
Figure 2-6 shows a classification schema for processes in form of a mor-
phological box. The left side of the box shows different properties
(attributes) of a process, while the right side shows the possible values of
these attributes. Besides general process design attributes, the morphological
box also contains workflow-relevant attributes. Depending on the value of
these attributes, we can identify different requirements for the automation
of a process.

Process Participants
The participants of a process can be either human or technical resources,
or a combination of both. Within technical resources we can differentiate
between hard- and software resources, respectively. Depending on the
resource type, the announcement and assignment of pending activities can
be performed either automatically (push) or manually (pull). Since the capac-
ity and availability of technical resources can be determined automatically in
many cases, automated assignment algorithms can be employed for technical
resources, while pull-strategies are more common for human process partic-
ipants.152

Structure
The process and activity structure dimensions determine if the details of a
process or activity can be documented prior to their execution. If the struc-
ture of processes and activities is known a priori, it can be specified using a
formal method. This specification in turn can be interpreted by a workflow
management system.

152.
For a review of different work distribution mechanisms compare Hagemeyer et al. (1998)
and Hoffman, Löffeler, Schmidt (1999), who analyze the capabilities of workflow manage-
ment systems in this regard. A more detailed discussion of this aspect can be found in zur
Muehlen (2004). The resource modeling aspects of workflow applications are addressed in
section 3.5.4 on page 160 in more detail.
Process-orientation and Process Organizations - 41 -

Source: Compare Kugeler (2000), p. 16, Becker, zur Muehlen, Gille (2002), p. 42.
Figure 2-6: Classification of Process Attributes
The degree of control flow coordination by the workflow management
system is directly related to the level of detail with which the process struc-
ture can be specified in advance. The difference between well-defined, rigid
process descriptions and ad-hoc, spontaneous collaboration has been dis-
cussed in the workflow management domain under the terms ad-hoc work-
flow153 versus production workflow.154

153.Compare Plesums (2002), p. 32, who characterizes ad-hoc workflows by the negotiation
used to determine the next activity of the process. An prototypical implementation for flex-
ible workflows has been presented by Weske (Flexible) (1997).
154.
Compare Leymann, Roller (2000).
- 42 - Process-orientation and Process Organizations

Ad hoc processes are those processes whose structure is unknown or

unknowable until they are executed. This may be because the structure of
the process is changing frequently due to reasons outside of the process
scope (e. g. customized orders), or because the analysis and documentation
of the process structure is regarded as too expensive (e. g. the multi-year
assembly of a particle accelerator as described by MCCLATCHEY ET AL.155).
Activities have an ad-hoc structure if it is unknown or too costly to deter-
mine which human, technical, financial, or information resources are
required for the execution and completion of the activity.156 Furthermore, if
the conditions that have to be met in order to complete an activity are
unknown, this activity is an ad-hoc activity.

Process Scope
The financial and logistics processes of a company stretch from the sup-
ply side to the demand side of the organization. The process scope dimen-
sion describes the boundaries of a given process.
Processes between organizations (inter-organizational processes) are either
inbound or outbound processes, which are triggered from outside the com-
pany or terminate outside the company borders.157 Typical examples for
these processes are delivery processes on the customer side, and replenish-
ment processes on the supply side. These inter-organizational processes can
also be found when one or more activities of a process are executed outside
the control sphere of the company, for example, if parts of the process have
been outsourced.158 A typical property of inter-organizational processes is
the limitation of control, i.e., parts of the process that reside at the process
partner are not manageable by the company itself, but instead constitute a
black box.159 For this reason, autonomous changes to an inter-organiza-
tional process have to consider the overall integrity of the process.160 In

155.
Compare McClatchey et al. (1998).
156.
The support of unstructured activities in workflow systems has been subject of a number
of research projects. Compare, e. g., Blumenthal, Nutt (1995).
157.The two dominant abbreviations for processes that cross company borders are B2B for
processes between companies (business-to-business) and B2C for processes between com-
panies and customers (business-to-consumer). To a lesser extent the terms B2G for pro-
cesses between companies and government agencies (e. g., electronic tax filings) and C2C
for consumer-to-consumer processes (e. g., online auctions) are used.
158.
Compare Bussler (2002) for a discussion of implementation aspects in business-to-business
scenarios.
159.
Only very few exceptions from this rule exist, for example if one of the two partners domi-
nates the business relationship and can demand process management from the smaller
party. An example for such a relationship is the relationship between car manufacturers and
their suppliers. Modern in-line manufacturing cells enable suppliers to finalize the produc-
tion of their components at the site of the receiving company. Even though the assembly
part of the process resides within the domain of the supplier, the car manufacturer can con-
trol the process due to the nature of the business relationship.
160.
Compare Hayami, Katsumata, Okada (2000).
Process-orientation and Process Organizations - 43 -

order to manage this restriction, the integration points between process part-
ners are often formalized using interoperability contracts,161 which may rely
on a standardized protocol. Figure 2-5 illustrates this through the supply
chain information system which extends beyond the system boundaries of
the company. Information about process performance may be restricted to
the part of the process which lies within the scope of an individual com-
pany.162
Processes within an organization (intra-organizational processes) are triggered
within the organization (e. g., the design of a new marketing brochure). The
company has complete control over the resources involved in these pro-
cesses and the implementation of the individual activities. KUGELER points
out that the majority of corporate processes are inter-organizational pro-
cesses.163 This is even more true if we focus on the value-adding processes
that directly support corporate goals.

Integration
The integration dimension describes to what extent the internal functions
of the application systems involved in the process are accessed.164 Process-
level integration refers to a coarse level of application invocation. This level of
integration is typically found in inter-organizational processes, when few
details about the invoked application systems outside the company bound-
aries are available.165
Application-level integration is found when entire applications are triggered
within the activities of a process. This level of integration if often applied
when the local decision autonomy of process participants should not be
controlled by a workflow system, i. e., if applications are provided as tools to
the process participants, but the workflow system does not control the usage
of these tools.
Function-level integration is typically implemented within technical processes
(with little human participation) that are enacted within or between applica-
tions.166 These processes serve the economic goals of the enterprise (e. g.,

161.
For interoperability contracts in business-to-business processes refer to Goodchild, Her-
ring and Milosevic (2000).
162.
Standardized protocols for process interoperability, as they are discussed in section 3.4.5 on
page 133, may incorporate ways to limit the visibility of process information. The value of
information in the supply chain was discussed by Holten et al. (2002).
163.
Compare Kugeler (2000), p. 18.
164.
Within this taxonomy, integration is defined as the unification of disparate system elements
to a new entity. For a detailed discussion of integration within the domain of workflow
management refer to section 3.2.4 on page 111.
165.Note that recent efforts around the development of Web Services, and Service-Oriented
Architectures (SOE) aim at the exposition of application functionality to external parties at
a finer level of granularity using standardized interface descriptions.
- 44 - Process-orientation and Process Organizations

the automated transfer of a delivery note to customer systems) and are

designed at a higher level of abstraction than software processes, which are
traditionally hard-coded within application systems.167

Granularity
The granularity dimension describes the representation of process objects
that are passed from one activity to the next. Depending on the level of
abstraction and the domain of a process, either atomic data elements (e. g., a
customer number), or complex objects (such as scanned documents, manu-
facturing parts, or finished products) are moved along the process. The
granularity dimension indicates the level of abstraction of the process, and
the proximity of the process description to a technical implementation.

Validity
The validity dimension relates to the intention of the process representa-
tion. An as-is process reflects the current implementation of a particular pro-
cess. If the process description represents a mid-term goal for either
organizational or technical developments that still have to be implemented
we call it a target process. The delta between the current process and the target
process indicates potential for change within the organization and can serve
as a guideline for restructuring efforts. An ideal process is a representation of
the best possible process implementation, but it may be too costly or too
complex to realize under the current circumstances. Whether there is a sig-
nificant difference between a target process and an ideal process is deter-
mined by the current organizational configuration, available resources and
other constraints, such as legal issues, or cost/benefit ratios.

Individuality
The individuality dimension of a process denotes whether the process is
specific to a single organization (e. g., the specific brewing procedure for a
patented drug), or whether it is a general representation, valid for a particular
domain (e. g., an invoice verification process for car manufacturers). An

166.
Within a single application system, an integration process may be executed to transfer data
between disparate components of the application system. A typical example for this are sys-
tems based on a middleware infrastructure such as CORBA or a J2EE application server.
Compare for example Weske (CORBA) (1997).
167.
Note that an increasing number of workflow systems is used to construct process-oriented
application systems. Vendors such as BEA, IBM, and Versata provide workflow compo-
nents as parts of their software development infrastructure. Application vendors such as
SAP, Siebel, and Oracle offer embedded workflow components that can be used to refine
the software processes within their large-scale application systems. We can observe a trend
to remove the top-level control flow from applications and have it managed by internal
workflow components. This type of software architecture is labeled by some as Business
Process Management System (BPMS), compare Smith, Fingar (2003).
Process-orientation and Process Organizations - 45 -

enterprise-specific process is valid for a single organization, but is not necessarily

internal to the organization. Inter-organizational processes, which are spe-
cific to a particular company, can also be classified as enterprise-specific pro-
cesses.168
Reference processes are valid beyond the scope of a single enterprise, but they
can be used for the design of individual processes.169 While reference pro-
cesses represent abstract types of enterprise-specific processes, they can be
instantiated through the addition of enterprise-specific information and thus
become enterprise-specific processes.170

Recipient
The recipient dimension describes the level to which a specific process
contributes to the overall company output. This dimension is based on POR-
171
TER’S classification of primary and support activities. Primary activities
are those activities that contribute to the production of a company’s output
and its delivery to the consumer, as well as post-sale activities, such as main-
tenance of delivered products. In contrast, support activities are designed to
support the primary activities and each other.172
In a similar notion, core processes create value and have a direct relation to
the goods and services created by a company.173 Core processes create value
for the organization. Support processes ensure the enactment of the core pro-
cesses through the provisioning of resources, material supplies, and the
maintenance of the company’s infrastructure. From a customer perspective,
support processes do not create value, but without them a company’s core
processes would not be functional. The distinction between core and sup-
port processes depends on the specific configuration of a company. For
example, a hiring process would be regarded as a support process within
many companies, but for a recruitment company this processes would con-
stitute a core process.

168.Compare Kugeler (2000), p. 17.

169.An example for this use of reference processes is the Process Handbook project at the
Massachusetts Institute of Technology, which collects process models from various indus-
tries and tries to inductively generate a repository of reference processes. Compare Malone
et al. (1993) for a description of the project and Lee et. al. (1998) for a discussion of the
modeling method applied to the reference models of the process handbook.
170.
For a thorough discussion of reference models and reference processes compare Schütte
(1999), pp. 69-86.
171.
Compare Porter (1986), pp. 38-45.
172.
PORTER names five categories of primary activities: inbound logistics, operations, out-
bound logistics, marketing and sales, and service. For support categories he names four cat-
egories: procurement, technology development, human resource management, and firm
infrastructure. Compare Porter (1986), pp. 39-43.
173.
Compare Becker, Kahn (2001), p. 7.
- 46 - Process-orientation and Process Organizations

Abstraction
A process instance represents an actual occurrence of a particular process,
such as the specific insurance claim of a customer. It describes the sequence
of activities for a specific configuration of a process object and shows no
abstraction or generalization.174
A process type is the general description of possible activity sequences for a
certain type of process object (e. g., expense reimbursement form). It can
serve as a template for individual process instances, which resolve the ambi-
guities of the process type.175

Hierarchy
The hierarchy dimension indicates whether a particular process is part of
the operative or the management system of the enterprise. Management pro-
cesses contain planning, decision, and control activities, while operative processes
consist of activities that lead to the production of a company’s goods and
services, and the maintenance of the infrastructure necessary for the enact-
ment of these activities. The strategic management process determines the overall
goals and guidelines for the company, while the operative management process
coordinates and controls the implementation of these strategies through the
operative processes and in conformance with corporate goals.176
Now that we have established a definition for an organization’s processes
and their context, we look at the organizational structure surrounding a
company’s processes.

2.2.4 Development of Process-oriented Organizations

TAYLOR’S scientific management approach initiated the separation of
management tasks for the operative core of the enterprise.177 In combina-
tion with stable markets, predictable customer behavior, and long product
life cycles, companies relied on functional specialization to increase the effi-
ciency of task completion. As a consequence, the functional organization
was the prevailing structure for the majority of 20th century organiza-
tions.178

174.
Compare Kugeler (2000), p. 18.
175.
A process type can contain alternative sequences of activities, depending on certain
attributes of the process object. A process instance derived from such a process type would
contain only one of the alternative sequences, determined by the actual attribute values of
the process object instance handled within this process instance.
176.
For a detailed discussion refer to section 2.3.2 on page 57.
177.
Compare Taylor (1947).
Process-orientation and Process Organizations - 47 -

With changing market conditions, such as global competition and the cre-
ation of micro-markets, increasingly individual customer profiles that led to
mass customization, and shorter product life cycles due to technological
innovation, the dynamics of the corporate environment have changed dra-
matically. STALK, EVANS, and SHULMAN point out the transformation from
externally oriented organizations toward a focus on internal capabilities:
“When the economy was relatively static, strategy could afford to be static. In a
world characterized by durable products, stable customer needs, well defined
national and regional markets, and clearly identified competitors, competition was a
“war of position” in which companies occupied competitive space like squares on a
chessboard, building and defending market share in clearly defined product or mar-
ket segments. [...]
[Today,] in this more dynamic business environment, strategy has to become corre-
spondingly more dynamic. Competition is now a “war of movement” in which suc-
cess depends on anticipation of market trends and quick response to changing
customer needs. Successful competitors move quickly in and out of products, mar-
kets, and sometimes even entire businesses. [...] In such an environment, the essence
of strategy is not the structure of a company’s products and markets but the dynam-
ics of its behavior.”179
The internal orientation of organizations has fueled the interest in meth-
ods and technologies to understand and manage the behavior of companies
more efficiently, and with more effective results. As discussed in the previ-
ous section, an organization’s output is generated by the organization’s oper-
ative system through the execution of financial, logistics, and information
processes. Using the system view of organizations180, enterprises are facing
the constant challenge to find the answer to the question: How can we manage
the operative system of the firm in such a way that the logistics, financial and information
processes are performed efficiently and effectively?

178.
A functional organization structure groups the entities of the organization according to
their functional specialization in order to maximize the resource efficiency. Compare Braun,
Beckert (1992), col. 640-655. Advantages of the functional structure are economies of scale
due to the size of the resulting departments, specialized (i. e., function-oriented) manage-
ment and simplified recruiting and training according to Dessler (1986), pp. 125-127.
179.
Compare Stalk, Evans, Shulman (1992), p. 62.
180.
Compare section 2.1.2 on page 30.
- 48 - Process-orientation and Process Organizations

In the context of process-oriented organizations, NORDSIECK noted the

necessity of a process-oriented organizational structure:
“The true structure of an enterprise is a flow. With every cycle it continuously creates
and distributes new products and services on the basis of the same or only slightly
changing tasks. […] Based on this perception, how can one order the tasks of an
enterprise differently, but following the natural-technical segments of the flow?”181
NORDSIECK even predicted the process-oriented design of information
systems:
“Think about [a] modern data processing [system]. This, too, represents a signifi-
cant process that is even connected with the business process and accompanies - or
even controls - this process across different segments.”182
A process-oriented organization is structured in such a way that the orga-
nizational entities are grouped according to the processes they perform. The
emphasis of process-oriented organizations is on the optimization of pro-
cess-, market- and motivation-efficiency, while the maximization of resource
and delegation efficiency are of lesser importance.183
Even though the origins of process-oriented organizations can be traced
back more than 30 years, the interest in process-oriented organizations did
not emerge until the late 1980s. As a result of this shift in interest, we have
seen the process as the focal point of organizational structuring in the 1990s.
Numerous process design, redesign, and management approaches were pub-
lished at that time that proposed either an evolutionary or a revolutionary
impact on existing organizational structures.184 The common use of the
term process in approaches such as Business Process Improvement (BPI)185,
Process Innovation (PI)186, Business Reconfiguration (BRC)187, Business
Process Reengineering (BPR)188 or Business Reengineering (BR)189 can be

181.
Nordsieck (1972), col. 9.
182.
Nordsieck (1972), col. 9.
183.
Compare Kugeler (2000), pp. 77-78, who points out that a situative valuation of the indi-
vidual efficiency goals is mandatory. Especially the compensation of process efficiency
through a higher resource efficiency in the case of functional specialization has to be ana-
lyzed on a process-individual basis.
184.
For a criticism of the various process (re-)engineering approaches compare Davenport
(1995).
185.
HARRINGTON defines Business Process Improvement as “a systematic methodology devel-
oped to help an organization make significant advances in the way its business processes
operate [...] The main objective is to ensure that the organization has business processes
that eliminate errors, minimize delays, maximize the use of assets, promote understanding,
are easy to use, are customer friendly, are adaptable to customers’ changing needs, provide
the organization with a competitive advantage, and reduce excess head count.” Harrington
(1991), pp. 20-21.
186.
Refer to Davenport (1993).
187.
See Venkatraman (1992).
188.
Compare Johannson et al. (1993); Stoddard, Jarvenpaa (1993) and (1994).
189.
See Hammer, Champy (1993); Hammer (1996).
Process-orientation and Process Organizations - 49 -

attributed to the refocusing of organizations on their processes. While BR

and BPR aimed at the fundamental restructuring of an organization’s pro-
cesses190, PI looked at the integration of information technology in this con-
cept.191 BPI relied on a less radical approach, focusing on the continuous
improvement of business processes through the implementation of a quality
framework in the tradition of the Total Quality Management idea.192 The
structural adjustment of organizations to provide a better fit for existing pro-
cesses was addressed at a general level in all these publications, but an oper-
ational work plan for the design of process organizations did not emerge.193

2.2.5 The ARIS Framework for Process Analysis and Design

Organizational processes exhibit structural complexity both through the
variety of activities and transitions found within an enterprise and through
the variety of perspectives that can be applied to processes during their anal-
ysis. In its most simple form, a process consists of activities and the transi-
tions between these activities. While any sequential algorithms can be
implemented using just three control flow elements (sequence, iteration and
selection)194, organizational processes require constructs for the description
of complex control flows, such as conditional and unconditional splits and
joins.195 In addition to the control flow, the support (or even the execution)
of activities through application systems is interesting for information sys-
tem designers. In addition, information about the data flow from and to
individual activities is necessary for the design of process-oriented applica-
tion systems. From the perspective of an organization designer, the respon-
sibilities for activity execution need to be described (in other words: which
resource is responsible for the execution of a specific activity). Process mod-
els can be employed for a variety of purposes, including software selection,

190.
Compare Hammer, Champy (1993), p. 32: “Reengineering [...] is the fundamental rethink-
ing and radical redesign of business processes to achieve dramatic improvements in critical,
contemporary measures of performance, such as cost, quality, service and speed.”
191.
While HAMMER and CHAMPY’S work named information technology as an “essential
enabler” of reengineering (Hammer, Champy (1993), p. 44), it fails to outline specific steps
to implement reengineering in practice (“For instance, we have written only a little about
how organizations can actually make reengineering happen”, Hammer, Champy (1993), p.
216). DAVENPORT tries to operationalize this approach and defines a stepwise procedure
for the modeling and improvement of business processes.
192.Compare Harrington (1991).
193.Compare Hammer, Stanton (1999), p. 108, who point out the clash of redesigned processes
with existing organization structures: “Many companies have integrated their core processes
combining related activities and cutting out ones that don’t add value, but only a few have
fundamentally changed the way they manage their organizations. The power in most com-
panies still resides in vertical units [...] and those fiefdoms still jealously guard their turf,
their people, and their resources.” A procedure model for the design of process-oriented
organizations was proposed by Kugeler (2000).
194.Refer to Böhm, Jacopini (1966), pp. 367ff.
195.This is due to the fact that the concurrent execution of activities within an organizational
process is easier to realize than the technical implementation of an algorithm with concur-
rent threads.
- 50 - Process-orientation and Process Organizations

customization of software systems, software development, development of

process-oriented applications, and process simulation. These perspectives
are typically used by application designers. Benchmarking, activity-based
costing, certification, knowledge management, and business reorganization
are potential perspectives of the organization designer.196 A framework for
the analysis of processes is necessary to accommodate these different per-
spectives and requirements. Such frameworks reduce the complexity of pro-
cess models through the introduction of different views. Examples for these
frameworks are the ZACHMAN framework for application design,
KRUCHTEN’S 4+1 view for object-oriented system architectures, and
SCHEER’S Architecture of Integrated Information Systems (ARIS).197 In the
following section we use ARIS as an exemplary framework for process anal-
ysis.
ARIS was developed as a framework for the analysis and design of infor-
mation systems, and distinguishes five different perspectives on a business
scenario: Organization, data, function, output and control view. Each of
these perspectives is divided into three layers, which are common across all
perspectives. These layers relate to the system development process:
Requirements definition, design specification, and implementation descrip-
tion.198 Figure 2-7 shows the overall structure of the ARIS framework.
Although the primary purpose of the ARIS architecture was to serve as a
framework for business-oriented software design and development, it has
found widespread acceptance for organizational modeling and analysis pur-
poses.199 This can be attributed to the complexity reduction that is achieved
through the different views. This complexity reduction enables an organiza-
tion designer to focus on a specific part of the problem at hand, while irrele-
vant perspectives are filtered out. For example, while a database engineer is
clearly interested in the data view, he will have less interest in the output
view or the organization view.200 Additionally, the phase concept of require-
ments definition, design specification, and implementation description
allows modelers to specify parts of an organization using a method that

196.Compare Rosemann, Schwegmann (2001), p. 58.

197.Compare Scheer (1999) and Scheer (2000).
198.At the same time, these layers replace a fifth view, the resource perspective, which would
include the information technology used within the process. Compare Scheer (1994),
pp. 12-13.
199.
Based on the ARIS architecture, a framework for the management of processes has been
proposed by Scheer, the so-called ARIS house of business engineering, which covers differ-
ent phases of the design of business-oriented application systems, from the conceptual
modeling of business processes to the implementation of workflow applications. Compare
Scheer (1996); Scheer (2000), p. 3.
200.In this example, the organizational view may be relevant to the database designer for the
development of access control mechanisms, but not for the design of the logical database
schema.
Process-orientation and Process Organizations - 51 -

Source: Compare Scheer (1999), p. 41.

Figure 2-7: Architecture of Integrated Information Systems
matches the situation of the model recipient. Figure 2-8 illustrates the ARIS
phase concept using the example of designing an inventory management
database.
Starting with an operational business problem, a model of the require-
ments is specified using a conceptual modeling language, in this case an
entity-relationship diagram. Based on this model the relational model of an
inventory management database is designed using a structured description of
the database tables. In the implementation description phase, this table
structure is transformed into Structured Query Language (SQL) statements
that are necessary to implement the proposed structure in a database man-
agement system (DBMS). The actual implementation concludes the project
and, as a result, a solution for the business problem is available.
The ARIS framework is a normative collection of views on processes, i. e.,
the selection of views is based on experiences from process modeling
projects and has been influenced by the event-driven process chain (EPC) as
- 52 - Process-orientation and Process Organizations

Source: Compare Scheer (1998), p. 39.

Figure 2-8: ARIS Phase Model
a particular modeling language for processes.201 In the following section we
discuss the individual views of the ARIS framework in more detail.

Function View
The function view of the ARIS framework contains process activities and
allows the modeler to create a hierarchical decomposition of high-level
activities into activities of finer granularity. Through the function view activ-
ities from different processes can be grouped according to different
attributes, e. g., all activities with customer interaction. SCHEER explicitly
allows the use of application software symbols and corporate goals in the
function view, which can be used to illustrate the purpose of activities, and

201.
The event-driven process chain was first introduced by Keller, Nüttgens, Scheer (1992). It
is regarded as a semi-formal process modeling language, because no explicit meta-model
was the basis for its inception. The lack of a rigid methodical foundation has been criticized
by some authors, who prefer the rigor of modeling methods based on mathematical formal-
isms, such as Petri-Nets (Petri (1962)). Compare e. g. v. Uthmann (1997); v. Uthmann
(1998) and v. Uthmann (2001). A (language-oriented) meta model for the EPC was first
provided by Rosemann (1996), pp. 122-123.
Process-orientation and Process Organizations - 53 -

to represent automated activities which are implemented through software

applications, respectively.202

Organization View
The organization view contains resources that participate in the execution of
a process and/or have responsibility for the process, in whole or in part.
This includes not only the performers of activities, but also their managers,
customers, suppliers, and so forth. Although the organization view is mostly
used to depict the hierarchical structure of an organization, it can also be
used to model interactions between resources.203

Data View
The data view of the ARIS framework hosts the messages and events that
trigger processes and activities, as well as environmental data that is trans-
formed through the execution of activities (i. e., a customer record that is
updated through the activity “change delivery address”).204

Output View
Within the output view, the input and output of activities and processes are
defined. SCHEER defines output as “the result of a production process, in
the most general sense of the word.”205 The defining criteria for output is
the fact that it is required as input by some party other than the producer,
that it has been requested by the receiving party, and that it is of value.206
Output recipients of an activity or process can reside inside or outside the
organization, i. e., output can be produced for both internal and external
customers. The output view was introduced in the last revision of the ARIS
framework, while in earlier editions the elements of the output view were
represented in the data view of the framework.207

202.
Compare Scheer (1999), p. 36.
203.
Resource interactions can be used to represent business processes. One example for this
type of process model is the action workflow approach, compare Winograd, Flores (1985)
and Medina-Mora, et al. (1992) and Mentzas, Halaris, Kavadias (2001). Another example (to
a certain extent) is the collaboration diagram of the Unified Modeling Language (UML),
which depicts interactions between objects (which can be representations of resources).
Compare Hruby (1998); Eriksson, Penker (2000), pp. 47-48; Object Management Group
(2001).
204.
Refer to Scheer (1999), pp. 35-36.
205.
Refer to Scheer (1999), p. 13.
206.
Compare Scheer (1999), p. 13.
207.
Compare for example Scheer (1994), p. 13.
- 54 - Process-orientation and Process Organizations

Control View
The control view (sometimes called process view) represents the union of
the other four views and describes the dynamic behavior of a process,
whereas the organization, data, function, and output views describe the
structural properties of a process.208 The control view contains the complete
process model, comprised of activities and control flow, their in- and out-
put, resources involved in their execution, triggers and messages. It connects
the entities described in the other views through named relationships, such
as “controls”, “creates”, “triggers”, or “uses”.

Evaluation
The ARIS framework provides modelers with a selection of distinct views
for the modularization and analysis of organizations. It has found wide-
spread acceptance in practice209, partially due to available modeling software
support.210 The partial models of the data, organization, function, and out-
put view can be integrated through the control view, enabling the distributed
modeling of partial aspects of an organization by different parties and the
subsequent integration into a unified model. Especially in larger organiza-
tions the availability of a central modeling repository and the option of dis-
tributing modeling tasks among a group of analysts is a precondition for the
use of modeling software.
In the previous sections we have outlined what business processes are,
their relationship to the structure of organizations, and ways to describe and
analyze these processes. In the following section we analyze the impact of
emerging process organizations on the role of management.

208.
Compare Scheer (1999), p. 36.
209.
For case studies from ARIS projects compare for example Scheer, Jost (2002).
210.
The ARIS Toolset of IDS Scheer AG provides software support for modelers using the
ARIS framework.
Management of Process Organizations - 55 -

2.3 Management of Process Organizations

2.3.1 Management - Concepts and Definitions

The origin of modern management theory can be seen as the publication
of FAYOL’S general principles of management in 1916, which provided a
first classification of managerial tasks.211 Within management theory the
role of management can be approached from an institutional as well as from
a functional perspective. While the former deals with the description of the
organizational entities that perform managerial tasks, the latter addresses the
processes and activities that are performed by these entities.212

Institutional Interpretation of Management

The institutional interpretation of management focuses on the position-
ing of managerial entities within the organizational structure. Within this
interpretation we can identify a significant difference between German and
American management approaches. Within the German organizational liter-
ature, management is perceived as the highest organizational layer of the
enterprise. In contrast, American authors discuss management as any posi-
tion that has disciplinary or direct authority over another position in the
organization.213 Critics of the latter position often point out that the person-
ified understanding of management mixes manager-employees with man-
ager-owners. This integration poses a problem for industry-economical
research that aims at comparing enterprises managed by owners with enter-
prises managed by independent employees.214

Functional Interpretation of Management

The functional interpretation of management focuses on the activities
that are performed with the intention to control the operative process of the
enterprise. Typically these activities are performed by specific parts of the
organization (thus linking the functional interpretation to the institutional
interpretation of management). Most authors describe management as a
cross-sectional function that controls the use of resources and choreographs
the operative activities of the enterprise. STEINMANN and SCHREYÖGG
define management as a conglomerate of controlling activities, which have
to be performed during the production of goods and services, and ensure
their success within division-of-labor-systems.215 Typical management func-
211.See Fayol (1949). While TAYLOR’S work on scientific management was concerned with the
separation of the organizational decision system from the executing system elements,
FAYOL’S work aimed at the classification of managerial tasks.
212.
Compare Staehle (1999), p. 71.
213.
Refer to Steinmann, Schreyögg (2000), p. 6.
214.
Compare Schreyögg, Steinmann (1981).
- 56 - Management of Process Organizations

tions include planning, organization, and control of the enterprise, although

a large number of different functional classifications exist.216
One of the most influential categorizations of management functions was
given by GULICK217, who built upon the work provided by FAYOL.218 His
classification consists of seven distinct functions:
„ Planning: The general decision what has to be done and how it should
be done in order to achieve corporate goals.
„ Organizing: The creation of a formal structure of authority that forms
and defines work units, and coordinates these work units in relation to
the overall goal.
„ Staffing: The recruiting and training of personnel and the constant
achievement of adequate working conditions.
„ Directing: The continuous decision-making in individual cases, and the
subsequent development of individual or general guidelines.
„ Coordinating: The general task to connect various parts of the work
process.
„ Reporting: The continuous information of the superior organizational
level about the development of the work process. This includes con-
tinuous self-information and the provisioning of information to sub-
ordinate employees.
„ Budgeting: The execution of all tasks that comprise budgeting, espe-
cially the creation of a budget and its supervision.
This functional catalog was subsequently modified by different authors.
For example, BLEICHER classifies management functions in three catego-
ries:219
„ Design of an institutional framework that enables an operating unit’s
capacity to survive and adapt.
215.
Compare Steinmann, Schreyögg (2000), p. 7.
216.
See, e. g., Steinmann, Schreyögg (2000), p. 6-7. This rather simplistic view of management
functions has been criticized, e. g., by MINTZBERG in his seminal paper “The Manager’s
Job: Folklore and Fact”. In this paper, he states: “If you ask a manager what he does, he will
most likely tell you that he plans, organizes, coordinates and controls. Then watch what he
does. Don’t be surprised if you can’t relate what you see to these four words.” Mintzberg
(1975), p. 49. He adds: “The field of management, so devoted to progress and change, has
for more than half a century not seriously addressed the basic question, 'What do managers
do?' Our ignorance of the nature of managerial work shows up […] in the computer con-
soles gathering dust in the back rooms because the managers never use the fancy on-line
MIS some analyst thought they needed.”
217.
Compare Gulick (1937), p. 13, cited after Steinmann, Schreyögg (2000), p.8.
218.
See Fayol (1949), which was first published in 1916.
219.
Compare Bleicher (2001), p. 54.
Management of Process Organizations - 57 -

„ Direction through the specification of goals and the definition, initia-

tion, and evaluation of goal-oriented activities within the system and
its elements.
„ Development is, on the one hand, the result of design and direction pro-
cesses over time. On the other hand, development happens indepen-
dently in social systems through the evolutionary learning of
knowledge, achievements, and attitudes.

2.3.2 Management Control as a Feedback Loop

KOONTZ and O’DONNELL were the first to substitute the functions
coordinating, reporting, and budgeting with a single function: controlling.220
Modern management theory thus relies on the five functions: planning,
organizing, staffing, directing and controlling. These functions are arranged
in a temporal and logical sequence along the management process.
The planning phase addresses the selection of corporate goals and the selec-
tion of the best way to achieve these goals.221 On the highest level, planning
deals with the development of goals, strategies, programs, and procedures
for either the entire organization or certain parts of the organization. The
management process starts with the planning phase, which serves as a pri-
mary function, i. e., it creates the original input for all subsequent phases of
the management cycle.
The organizing phase deals with the development of an execution frame-
work for the plans and processes that were described in the previous plan-
ning phase. Primary goal of the organizing phase is the development of an
organizational structure that consists of positions and their aggregations
(groups, departments, etc.). Furthermore, the distribution of competencies
and qualification requirements for these positions, and the development of a
communication system along the organizational structure are tasks within
the organizing phase.222
The staffing phase is concerned with the population of the organizational
structure that was designed in the organizing phase. Following the initial
staffing phase, the staffing function has to ensure and continuously maintain
the supply of qualified resources for the organization.

220.
Compare Koontz, O’Donnell (1955), cited after Steinmann, Schreyögg (2000), p. 8-9.
221.
Compare Steinmann, Schreyögg (2000), p. 9.
222.
Note that the term communication system in this context does not relate to technical communi-
cation equipment such as telephones, fax machines, and computer networks. Instead, the
rules and regulations for communication between the members of the organization have to
be determined during this phase (for example, which position reports to whom).
- 58 - Management of Process Organizations

While planning, organizing, and staffing are primarily concerned with the
preparation of the organization for efficient operation, the directing phase con-
tains the continuous initiation of task enactment and the coordination and
control of the operative system.
The final phase of the management cycle is the controlling or evaluation
phase, during which the achievements of the operative system are compared
with the plans devised during the planning phase. Planning and controlling
phases are regarded as twin functions, since controlling is impossible with-
out the target measures provided by the planning phase, while planning is
hardly possible without controlling information about the achievement (or
attainability) of goals.
Figure 2-9 shows the management process according to BLEICHER.223
The cyclic process emphasizes that management must not only be perceived
as a linear sequence of activities, but that it is rather an interconnected feed-
back loop, consisting of the three core phases decision, enactment and eval-
uation.224
The management process as described above is not an isolated sequence
of activities executed on the management level. Instead, each part of an
organization performs - to some extent - steps within the management cycle.
Due to the sheer complexity of large organizations a central coordinating
instance cannot be implemented with reasonable effort. One of the main
reasons for this is the limited information processing capacity of the human
brain.225 In order to ensure an optimal decision making process (which
includes the optimal allocation of resources) information about the entire
organization has to be aggregated and evaluated. Another reason for the lack
of centralized control are structural defects of decision processes.226 There-

223.
Refer to Bleicher (1999)[48], p. 49. The management process depicted here is a modified
version of the management process proposed by ULRICH and KRIEG, compare Ulrich,
Krieg (1974).
224.This cycle shows structural similarities to the Deming cycle depicted in figure 1-1 on
page 3.
225.
Compare Dessler (1986), pp. 110-113, who describes the increasing information load: “As
managers are faced with more and more information - with more uncertain information,
more complex information, or more types of information - they reach their capacity for
processing it and making decisions, and information overload occurs.”
226.
ADAM has classified the problems associated with complex decision making processes.
Solution defects can be found if for a certain problem more than one solution is possible (e. g.
the planning of production lots). Goal defects occur if certain desirable outcomes of an activ-
ity are in direct conflict (e. g., maximizing the return on investment while minimizing the
risk of loss). Valuation defects can be observed when the outcome of a certain decision can-
not be measured precisely (e. g., additional revenue from the development of a new prod-
uct). Finally, impact defects occur when the results of proposed activities cannot be
determined with certainty. This category of defects occurs frequently, when the internal
workings of organizational processes are not understood, and the relationship between
input factors (e. g., materials and human resources) and output factors (e. g., defect-free
products) are unknown. For a detailed discussion see Adam (1996), pp. 10-15.
Management of Process Organizations - 59 -

Source: Compare Ulrich, Krieg (1974); Bleicher (2001), p. 49.

Figure 2-9: Cyclic Management Model
fore, management processes are implemented at various levels of the organi-
zation, which enable the organization to continuously control itself, in order
to maintain its viability and development.
The cyclic structure of the management process corresponds with the
principles of the cybernetic feedback loop.227 A diagram of the cybernetic
feedback loop is depicted in figure 2-10. The operative system of the organi-
zation is the system being regulated by the control unit. The planning unit
provides target values for the output of the regulated system to the control
unit. Input for the planning unit comes from the normative management
level, which determines overall strategies, rules, and guidelines for the orga-
nization. The control system has to ensure that the regulated system pro-
duces an output within the tolerances defined for the target values. This unit
consists of three sub-units: Evaluation, control, and implementation. The
evaluation part measures the output of the regulated system as well as its
input (and eventual disturbances, which may affect the regulated system)
through sensors. During traditional feedback coordination, the output values
(actual values) are compared with target values provided by the planning
unit. If a deviation exists within certain tolerance levels, the control part of
the control unit determines the necessary measures to compensate for the

227.
For the following section refer to Küpper (2001), pp. 181-185; Wiese (2000), pp. 18-20;
Espejo et al. (1996), pp. 65-69.
- 60 - Management of Process Organizations

Source: Compare Espejo et al. (1996), p. 67; Wiese (2000), p. 19.

Figure 2-10: Cybernetic Feedback Loop
disturbances that may have caused the deviation. The implementation part
of the control unit performs the necessary adjustments to the input stream
of the regulated system. This ex-post evaluation can compensate for distur-
bances within a certain bandwidth, but it does not prevent the system from
attaining a state of self-oscillation.228 In order to stabilize this lower feed-
back loop, the control unit reports deviation outside of the tolerance band-
width to the planning unit, which can then adjust the target values
appropriately. Anticipatory control (feed-forward control) is performed if
the evaluation part of the control unit measures the disturbances before they
enter the regulated system, and the control system can devise preventive
measures to ensure the desired output. Finally, if a regulated systems allows
a view of its internal processes, it can be monitored during the processing
phase.229 If the system also allows a modification of its processes, real-time
adjustments can be administered through the control unit.

2.3.3 Levels and Tasks of Management

In section 2.3.1 on page 55 we have discussed the individual tasks that
make up the management function of an organization. These tasks can be
classified into different groups. The classification of managerial tasks can be
traced back to the works of ANTHONY, who differentiates between three
228.
Self-oscillation occurs when the planned compensation of a disturbance creates another
disturbance in the opposite direction, which in turn is compensated by an adjustment in the
direction of the original disturbance, and so forth.
229.
Monitoring can be defined as the gathering of data on the performance of an existing sys-
tem. Compare Lucas (1971), p. 80.
Management of Process Organizations - 61 -

distinct categories of management tasks: Strategic planning, management

control and operational control.230 This distinction is based on the different
objectives, focus, and information requirements of each category.
„ Strategic planning is directed at the development, the maintenance, and
the exploitation of success potentials, for which the organization’s
resources have to be used. It focuses on the organization in its entirety
and relies on internal and external information at a coarse level. The
relationship of the organization with its environment is a central issue
within this category.231
„ Management control is directed at ensuring the realization of strategic
plans through the provisioning of appropriate resources and pro-
cesses. It focuses on the human and technical resources of the organi-
zation and relies on guidelines that are provided by the strategic
planning entities, as well as on reported information from the underly-
ing operative system.232
„ Operational control is directed at the efficient and effective enactment of
the operative activities. GORRY and SCOTT-MORTON point out that
operational control mainly deals with tasks, whereas management
control mainly deals with resources.233
An overview of the different categories of management activities is given
in table 2-1.234
Based on this classification, a typical segmentation of management levels
is the distinction between strategic, tactical and operative management. This
distinction is based on a number of criteria:235
„ The position of the manager in the organizational hierarchy and the
potential for delegating decisions to subordinate units.

230.
Compare Anthony (1967), Gorry, Scott-Morton (1971), p. 59. Some authors call the strate-
gic planning level normative management, which deals with the overall goals of the enter-
prise, with principles, norms and rules that are designed to foster the ability of the
organization to survive and to develop. Compare Bleicher (2001), p. 74.
231.
Compare Gorry, Scott-Morton (1971), p. 58.
232.
Anthony defines management control as “the process by which managers assure that
resources are obtained and used effectively and efficiently in the accomplishment of the
organization’s objectives”. Anthony (1967), p. 27.
233.Compare Gorry, Scott-Morton (1971), p. 57.
234.Compare Anthony (1967).
235.Compare Hentze, Brose (1985), pp.117-118.; Welge, Al-Laham (2001), p. 6. Both authors
distinguish between three levels of managerial activity: strategic, operative and tactical level.
They refer to operative planning as the middle level and tactical planning as the lower level
of managerial activity. In order to reflect the distinction between the management and oper-
ative systems discussed on page 34, we use these terms in the reverse order, as they are
found in Wiese (2000), pp. 45-50.
- 62 - Management of Process Organizations

Information Information Information

Objective Focus Requirements Characteristic Sources

Deciding on Organization Information Infrequent, Balanced Score-

Strategic
Planning

objectives and about the orga- aggregate and card

policies for the nization and the obtained from On-line Analyti-
organization environment outside the orga- cal Processing
nization

Acquisition, effi- Resources Limited informa- Guidelines and Activity-based

Management

cient and effec- tion about the regulations from Costing

Control

tive use of the environment, strategic plan- On-line Analyti-

organization’s information ning, actual val- cal Processing
resources about the orga- ues from
nization operational con-
trol

Efficient and Processes and Information Frequent, accu- Operational

Operational

effective enact- Resources about the orga- rate, precise learning and
Control

ment of tasks nization from inside the control system

organization

Table 2-1: Categories of Management Activities

„ The scope of the managerial decisions, i. e., which parts of the organi-
zation are affected by a decision made at this specific level.
„ The object of managerial activities, i. e., the frequency, novelty, and
validity of decisions, the possibility of revising a decision, the flexibil-
ity in making specific decisions, and the formalization of decisions.
„ The structure of managerial decisions, i. e., criteria such as the complex-
ity, security, level of detail, degree of freedom, and information
requirements.
„ The process of managerial decisions, i. e., the programmability of the
decision process, the thought-style, behavior, and interdependencies.
„ The stimulus for managerial decisions, i. e., whether decisions are made
in an anticipatory way (feed forward), or if they are triggered by orga-
nizational events (feedback).
Table 2-2 shows a juxtaposition of the characteristics of strategic and
operative management.236 The attributes denote extremes of a continuum
and should be interpreted as “more common in strategic management” ver-
sus “more common in operative management”. In the following section we
discuss strategic and operative management and control in more detail, and
outline the different information requirements of both groups.

Strategic Management and Control

Management of Process Organizations - 63 -

Strategic Operative Management

Management and Control and Control

Scope entire organization departments, single units

Validity general (case-)specific

Reversibility low, expensive high, inexpensive

Decision Object

Flexibility very high very low

Frequency low high

Novelty innovative repetitive

Formalization weak strong

Authority centralized decentralized

Complexity high low

Decision Structure

Certainty high risk low risk

Structure unstructured (open) structured (closed)

Level of Detail low, global high, specific

Degree of Freedom high low

Inform. Requirements high medium/low

Programmable not possible partially possible

Decision Process

Normative Input high low

Thought Style holistic, intuitive, synoptic analytical, incremental

Behavior innovative, creative routine, repetitive

Interdependencies few frequent

Stimulus feed-forward control feedback control

Table 2-2: Juxtaposition of Management Levels

The purpose of strategic management and control is the alignment of the

entire organization based on external conditions (e. g., the market situation)
and internal capabilities. Corporate strategy addresses the selection of strate-
gic business units, the choice of competitive behavior237, and the identifica-
tion of core competencies. Strategic management and control is directed at

236.
Compare Hentze, Brose (1985), pp. 117-118. Note that HENTZE and BROSE use the term
tactical planning for what is named operative management in table 2-2. The middle level has
been eliminated from the table, because the attributes shown are a continuum and a
medium level would necessarily have a fuzzy distinction. Also, some of the attributes cho-
sen by HENTZE and BROSE have been omitted, because they no longer reflect the current
state of management science. For example, STEINMANN and SCHREYÖGG have pointed out
that the temporal scope of decisions no longer is a distinctive feature of strategic or opera-
tive management, respectively. Strategic plans can have a short-term scope, such as the
acquisition of a competitor due to a surprise offer or a turn-around effort in times of eco-
nomic peril. Also, the position of strategic management tasks at the top of the organiza-
tional hierarchy, while valid in many cases, is not a fixed rule. For example, reengineering
efforts that are initiated by members of the operative system may have a strategic impact on
the organization as a whole (e. g. the introduction of a document management system in
place of existing paper flows). Compare Steinmann, Schreyögg (2000), pp. 149-150.
237.
For example, whether the organization strives to attain cost leadership or quality leadership.
- 64 - Management of Process Organizations

the creation, maintenance, and exploitation of success factors. For these

purposes resources are employed.238 This generic strategy specifies the fun-
damental approach taken by an organization to pursue competitive advan-
tage and provides a framework for operative activities.239 STEINMANN and
SCHREYÖGG identify the following elements of strategic management and
control:240
„ Strategic analysis. Besides strategic control, strategic analysis is the core
task of strategic management, because it provides the information
framework for the successful selection and implementation of a strat-
egy. This task is comprised of the analysis of the environment, and the
analysis of the organization. Goal of the environmental analysis is the
identification of threats and opportunities for the organization’s activ-
ities from the perspective of markets, competitors, and customers
(immediate environment). To a lesser extent, the analysis of general
trends in society, political structures, and technological factors (distant
environment) is part of the environmental analysis.241 Goal of the
organizational analysis is the identification of strength and weaknesses
in terms of resource potential and capabilities, product portfolio, and
financial assets, which could provide a competitive advantage. The
results of environmental and organizational analysis are often com-
bined in form of a SWOT-analysis (strengths, weaknesses, opportuni-
ties, threats).242
„ Evaluation and selection of strategic options. Based on the findings of the
strategic analysis, alternative strategies are designed and evaluated.
Based on the valuation of different strategies, one of the alternatives is
chosen for implementation. Besides the factors identified during the
strategic analysis, ethical and management philosophical factors are
considered during this phase.
„ Development of a strategic program. Strategic programs provide orientation
for the operative planning and control processes. They provide guide-
lines and procedures for the implementation of corporate strategies,
but do not outline the implementation processes in detail. The
238.
Compare Bleicher (2001), pp. 75-76. BLEICHER identifies a normative level of manage-
ment, which deals with the overall goals of the organization and develops principles, norms
and guidelines that enable the company to sustain and develop. Compare Bleicher (2001),
pp. 74-75. This management level relates to the culture, politics and constitution of the
organization and is therefore outside the scope of our research. For the remainder of this
work the analysis is restricted to the two lower levels: strategic and operative management
and control.
239.
Refer to Porter (1985), p. 25.
240.
Refer to Steinmann, Schreyögg (2000), pp. 157-160.
241.
Compare Steinmann, Schreyögg (2000), p. 158.
242.
For a description of the SWOT analysis refer to Meffert (2000), pp. 67-68.
Management of Process Organizations - 65 -

emphasis of strategic programs is the provisioning of operative goals

for parts of the organization, which enable the different units to assess
the current implementation using measures and variables that relate to
these goals. The actual implementation of strategic programs is not a
task of strategic management.
„ Strategic control. The continuous evaluation of the activities of the oper-
ative system encompasses the strategic management process. While
some authors see strategic control as the final phase of the strategic
management cycle, several arguments can be given for an encompass-
ing view of strategic control.243 On the one hand, a feedback-based
control cycle does not deliver information in time, which could lead
to corrective measures during the implementation of the strategic
plan.244 This is due to the long planning cycles and potential irrevers-
ibility of strategic decisions made. On the other hand, changes in the
factors analyzed may require a revision of planning assumptions, but
these changes are only communicated upstream during a new cycle of
the management process or the control phase. Therefore, strategic
control has to accompany the management process and has to contin-
uously question its assumptions and results.245 During the different
phases of the management process two types of strategic control can
be distinguished:246 Premise control continuously monitors the assump-
tions made during the development of strategic programs. Execution
control continuously monitors the implementation of the strategic pro-
gram.
Information Requirements
Information requirements describe the type (quality) and amount (quan-
tity) of information required to satisfy the information needs of a decision
maker. Information needs have to be satisfied in such a way that the uncer-
tainty about the consequences of choosing a particular alternative are mini-
mized. Members of an organization involved in strategic management and
control have different information requirements during the different stages
of the planning and control process. During the strategic analysis, informa-
tion sources both internal and external to the organization are required. For
instance, the analysis of the environment is based on market data, demo-
graphic information, and competitor information, among others. Informa-
tion about the performance of different organizational units is required for
243.
Compare Schreyögg, Steinmann (1987).
244.
Compare Steinmann, Schreyögg (2000), p. 243.
245.
Refer to Band, Scanlon (1995).
246.
Compare Preble (1992). Some authors combine execution control and premise control with
strategic monitoring. Compare Steinmann, Schreyögg (2000), pp. 245-247.
- 66 - Management of Process Organizations

the analysis of the organization. This information may be put in perspective

through related external information, such as benchmarks247 for particular
processes or products.248 In the context of strategic control, internal infor-
mation about the achievement of milestones during the implementation of
strategic programs, as well as the contribution of different organizational
units to the overall goals of the organization is required. Premise control
requires information about the current state of planning assumptions.
Methods and Instruments
The execution of successful control as part of the strategic management
process depends on the precise definition of benchmarks, milestones, and
other metrics. Such metrics should reflect the intention and progress of the
strategic program, and should relate to the overall strategic goals of the orga-
nization. Traditionally, this is achieved by the use of financial measures,
which have the goal of making otherwise incomparable facts comparable
through a common valuation. These financial measures are typically
extracted from the operative accounting systems of the company and aggre-
gated using ratio systems, such as the RoI system of E. I. du Pont de Nem-
ours.249
Besides financial measures, which outline the cost aspect of a company’s
activities, non-financial measures are used to evaluate criteria such as quality,
timeliness, and service levels. KAPLAN and COOPER emphasize the use of
non-financial measures:
“Cost reduction is an important managerial objective. But cost improvement alone
may not be sufficient. Customers want not only lower prices and costs; they also
greatly value quality, responsiveness, and timeliness. Consequently, employees must
have information about both the cost consequences of their activities and the quality
and cycle time of processes under their control.”250
The performance measurement movement focuses on the use of non-
financial measures as an equal source for the selection of strategy alterna-
tives, staffing considerations, and other decisions. It aims to extend their tra-
ditional role as additional information for the enhancement of existing
financial frameworks.251

247.
Compare Eccles (1991), p. 133: “Benchmarking involves identifying competitors and/or
companies in other industries that exemplify best practice in some activity, function, or pro-
cess and then comparing one’s own performance to theirs.”
248.
Compare Lamla (1995) and Schmitz (1998) for a comprehensive discussion of process
benchmarking.
249.
Refer to Staehle (1973), pp. 224 ff.
250.
Kaplan, Cooper (1998), p. 49.
Management of Process Organizations - 67 -

Table 2-3 shows the evolution of cost accounting systems according to

KAPLAN and COOPER.252 Many companies today rely on information from
stage II systems, which provide cost information from responsibility centers,
but not related to activities, processes, services or customers.253 The system
output is backward-oriented and made available with a significant delay, due
to the fact that feedback-style controlling is employed. The integration of
non-financial measures and cross-departmental information sources is seen
as the biggest improvement potential for existing cost reporting systems.254

Stage I Systems Stage II Systems Stage III Systems Stage IV Systems

Financial
Broken Reporting Driven Specialized Integrated

„ Many errors „ No surprises „ Shard databases „ Fully linked data-

„ Large variances „ Meets audit stan- „ Stand-alone sys- bases and sys-
Data Quality
dards tems tems
„ Informal links

„ Inadequate „ Tailored to finan- „ Shard databases „ Fully linked data-

External cial reporting „ Stand-alone sys- bases and sys-
Financial
needs tems tems
Reporting
„ Informal links

„ Inadequate „ Inaccurate „ Several stand- „ Integrated activ-

Product/ „ Hidden cost and alone activity- ity-based man-
Consumer
profits based costing agement systems
Costs
systems

„ Inadequate „ Limited feedback „ Several stand- „ Operative and

Operative „ Delayed feedback alone perfor- strategic perfor-
and Strategic
mance measure- mance measure-
Control
ment systems ment systems

Table 2-3: Evolution of Cost Accounting Systems

Operative Management and Control

Purpose
Operative management and control operates within the framework pro-
vided by activities on the strategic level. Its purpose is the execution and
enactment of strategic plans with the organization’s specific resource contin-
gencies. For this purpose the strategic programs have to be broken down
into partial plans, structured by functional areas, product divisions, or
regions. ODIORNE has proposed the following procedure model for the
transformation of a strategic goal into operative goals:255

251.
The term performance measurement was coined by Eccles (1991). Criticism of existing
accounting systems, which are the main source for financial information about an organiza-
tion, was stated by Kaplan (1983) for the manufacturing domain and Johnson, Kaplan
(1987) on a more general basis.
252.
Refer to Kaplan, Cooper (1998), p. 12.
253.
See Kaplan, Cooper (1998), pp. 13-18.
254.
Refer to Ittner, Larcker (1999), who even argue that non-financial measures are better indi-
cators for the financial performance of a company than financial measures themselves.
- 68 - Management of Process Organizations

„ Identification of a responsible person for a particular time frame and a

particular result.
„ Identification of indicators that reflect the achievement of the goal.
„ Selection of key indicators from the pool of indicators identified in the
previous step.
„ Decision about additional constraints which have to be recognized.
„ Operationalization of key indicators and constraints through the agree-
ment on temporal and quantitative target values.
„ Implementation of the agreed-upon program.
The transformation of strategic programs into operative activities is seen
as the central weakness of strategy implementation.256 In contrast to the
procedural approach presented by ODIORNE, an integrated system of indica-
tors for managerial activities has been proposed by GÄLWEILER.257 The
basis of this framework is the liquidity of the company, since it presents a
condition for the survival of the organization. Due to its short-term orienta-
tion, a plan based on liquidity goals (taking income and expenses into
account) would neglect the future-orientation of the company. For this rea-
son, the analysis of a company’s profit through cost and revenue provides
the means to control the liquidity over a longer period of time. However, the
planning of balance sheets for the development of long-term strategies
neglects experience curves and the substitution potential of a company’s
products through its competitors. Therefore, existing core competencies and
success potentials form the basis for the next level of strategic planning.
While these indicators allow for a longer planning period, they do not recog-
nize changing market conditions, technological innovation, and changing
customer profiles. The continuous search for new success potential thus
forms the highest level of corporate strategy. Figure 2-11 shows the manage-
ment model by GÄLWEILER.
The planning and control cycle at the operative level focuses on the
implementation of the strategic programs developed during the strategic
planning and control cycle. Operative planning consists of the development
of implementation plans for logistics and financial processes as well as the
development of project plans for their actual implementation.258 Operative

255.
Compare Odiorne (1979), p. 121, whose management system is called management by objec-
tives.
256.
Refer to Staehle (1999), p. 663.
257.
Compare Gälweiler (1987), p. 34.
258.
Compare Steinmann, Schreyögg (2000), pp. 266-274.
Management of Process Organizations - 69 -

Source: Gälweiler (1987), p. 34.

Figure 2-11: Management Tasks and Indicators
control measures the progress of implementation and focuses on the effi-
ciency of the plan realization (“doing the things right”), whereas strategic
control focuses on the validation of goals (“doing the right things”).259
Besides the development of operative work plans and measurements, opera-
tive control executes a reporting function in the direction of strategic con-
trol. Because of the different intentions of operative and strategic control,
the scope of this reporting task can grow to a size that impacts the efficiency
of the original tasks of operative control.
Information Requirements
The information requirements of operative management and control are
twofold. On the one hand, measurements are required that allow operative
management to monitor the implementation of (parts of) the strategic pro-
gram within their control sphere. On the other hand, information has to be
gathered which is subsequently passed on to the strategic control level. For
this reason, a reporting infrastructure needs to be implemented that not only
satisfies the information requirements of the operative management, but
also allows the integration and aggregation of its results across organiza-
tional boundaries. A process controlling system needs to satisfy these
requirements.

259.
See Steinmann, Schreyögg (2000), p. 368.
- 70 - Controlling of Process Organizations

2.4 Controlling of Process Organizations

2.4.1 Controlling of the Firm - Concepts and Definitions

The organizational position of the controller has been a result of corpo-
rate practice,260 but it is lacking a theoretical foundation which outlines
potential development paths for controllership in practice.261 This problem
arises from the variety of definitions of the term controlling, of which none
is universally accepted.262 The interpretations of the term controlling range
from the positivistic view “Controlling is what controllers do”263 to information-
centric, coordination-centric, or management-centric definitions.264 We dis-
cuss each of these views in the following section, before we discuss their
integration in hybrid controlling definitions.

Information-Centric Controlling Definitions

The information-centric view on controlling focuses on the position of
the controller as a central information supplier.265 The controller has to sup-
port the decision making process through the supply of timely and relevant
information. For this purpose, an infrastructure for the collection, manage-
ment, and presentation of this information has to be created and maintained.
This aspect represents the system-building function of the controller.
Through the use of such a controlling infrastructure, the controller gathers
information from sources inside and outside the organization, aggregates
them to levels that reflect the information requirements of the decision
problem at hand, and ensures that decision makers have access to relevant
information. This aspect represents the system-utilizing function of the con-
troller. The core responsibility of the controller is the coordination of infor-
mation generation and supply with the existing information demand.266
Through this activity, the controller assumes responsibility for the transpar-
ency requirements of management.267 WEBER points out that through this
supporting task the controller disburdens management.268 Since the infor-

260.
The first roots of controllership in private companies can be traced back to the position of
the comptroller at the Atchinson, Topeka & Sante Fe Railway System in 1880. For a detailed
discussion of the historic roots of controlling see Weber (1999), pp. 2-10.
261.See Schäffer, Weber, Prenzler (2001), p. 2.
262.A critical discussion of the lack of agreement on the definition of controlling is part of
many controlling books. For a reference compare e. g. Schildbach (1992), pp. 21-27 and
Weber (1999), pp. 19-29, who points out the lack of generally accepted controlling principles.
263.
A critical perspective on this view can be found in Grob (1996), pp. 1-2.
264.
Compare for a discussion Weber, Schäffer (1999), pp.732-734. ANTHONY has characterized
the different views of controllership as follows: “In practice, people with the title of con-
troller have functions that are, at one extreme, little more than bookkeeping and, at the
other extreme, de facto general management.” Anthony (1965), p. 28.
265.
Compare e. g. Becker (1984).
266.
Compare Küpper (2001), pp. 10-11.
267.
Compare Weber (1999), p. 348.
Controlling of Process Organizations - 71 -

mation requirements of decision makers vary with the actual decision to be

made, the information supply function of controlling is highly context-
dependent.269
The information-centric view of the controller is closely related to the
domain of management accounting in the English literature. This view
includes the functions of operations research, budgeting, tax accounting, and
corporate revision as activities of the controller. While the information sup-
ply function was historically dominated by the use of financial measures and
related key indicators, this focus has been questioned since the mid-1980s
and alternative measurements for aspects such as product quality, customer
satisfaction, and process efficiency have been proposed.270 However, the
simple equation controlling = advanced management accounting ignores the
additional functions of the controller, which we discuss in the following sec-
tion. Table 2-4 shows the juxtaposition of the main attributes of manage-
ment accounting and controlling according to BECKER.271 While the
descriptions given in table 2-4 are extremes, which are unlikely to be found
in corporate practice, they outline the differences between the two functions.
Besides the provision of information, the controller is also responsible
for supplying the appropriate methods for the analysis of the information at
hand. These methods reach from frameworks for financial measures272 to
scorecards that provide a holistic view of the enterprise and its sub-
systems.273

Management-Centric Controlling View

The management-centric controlling view defines controlling as a specific
function of the management system. The controller has to ensure the effi-
ciency of the management cycle by continuously monitoring the alignment
of managerial activities with the enterprise goals.274

268.
Compare Schäffer, Weber, Prenzler (2001), p. 4.
269.
Compare Weber (1999), p. 39; Kaplan (1984), p. 414 points out the context dependency of
management accounting approaches: “Management accounting must serve the strategic
objectives of the firm. It cannot exist as a separate discipline, developing its own set of pro-
cedures and measurement systems and applying these universally to all firms without regard
to the underlying values, goals and strategies of particular firms.”
270.Compare Kaplan (1984), p. 414, who argues that management accountants should expand
their perspective beyond the use of financial measures: “The option to include non financial
measures in the firm’s planning and control system will be more unfamiliar, more uncertain,
and, consequently, less comfortable for managerial accountants. It will require them to
understand those factors that are most critical to the company’s long-term success.”
271.
Refer to Becker (1984), p. 22, cited after Weber (1999), p. 22.
272.
Compare for example the DuPont-System of Financial Control, which was established
1919. Compare Horváth (2001), pp. 571-574.
273.
Compare for example Kaplan, Norton (1996) and Kaplan, Norton (2001).
274.
Refer to Weber (1999), pp. 23-25.
- 72 - Controlling of Process Organizations

Management Accounting Controlling

Number-oriented activities Recipient-oriented activities

Goal: Numbers have to be recorded and Goal: Numbers have to lead to activities
adjusted properly

Accountant Information supplier and salesperson

Work is backward looking Work is forward looking

Numbers are delivered Numbers are sold

(recipients need to be convinced)

Work in secrecy Continuous communication about

revenue questions

Rigid guidelines Continuous adjustment to corporate require-

ments

Domain-specific terminology Translation in recipient-oriented terminology

Reports based on numbers Reports with look-ahead, summary, résumé,

information and (proposed) measures

Dominates accounting Dominates goals, plans and control

Table 2-4: Juxtaposition of Management Accounting and Controlling

Coordination-Centric Controlling View

Until recently, the majority of controlling definitions emphasized the task
of coordinating the different elements of the management system.275 Coor-
dination can be defined as the process of achieving unity among interdepen-
dent entities.276 Within the management cycle, the task of the controller can
be seen as the coordinating entity, which ensures the effective collaboration
of different parts of the management system, such as planning, control,
organization, personnel management of goal definition.277 The controller
has to ensure the efficiency and effectiveness of the management system in
the same way the management system has to ensure the efficiency and effec-
tiveness of the operative system.278

275.Compare for example Küpper (2001), pp. 12-29; Horváth (2000), pp. 118-120.
276.Compare e. g. Dessler (1986), p. 148, who defines coordination in relation to tasks: “Coor-
dination is the process of achieving unity of action among interdependent activities.” MAL-
ONE and CROWSTON define coordination in its most general form as “managing
dependencies between activities.” Malone, Crowston (1994), p. 90.
277.Compare Weber (1992), pp. 172-179. Note that Weber subsequently modified his position
and now advocates the rationality-supporting function of controlling, which is presented in
section 2.4.2 on page 73.
278.
See Weber (1999), p. 26.
Controlling of Process Organizations - 73 -

Hybrid Controlling Definitions

While the information-centric, management-centric, and coordination-
centric view of controlling describe different perspectives that can be
applied to classify the activities of a controller, most controlling definitions
combine elements from all three perspectives. For example, HORVÁTH’S
definition of controlling has found widespread use in the German literature:
“Controlling is - from a functional perspective - the sub-system of management,
which coordinates planning, evaluation,279 and information supply in a goal-ori-
ented, system-building, or system-connecting way. By doing so, controlling supports
the adaptation and coordination of the entire system.”280
The above definition sees controlling as goal-oriented, i. e., it supports
the overall economic goals of the enterprise. It has to coordinate conflicting
strategies, which may lead to local optimization, and it has to ensure an over-
all economic benefit for the organization. It is seen as a specific part of the
management system, which it coordinates. The management system itself
consists of the two sub-systems planning and control system and informa-
tion-supply system.

2.4.2 Controlling as a Measure to Ensure Rational Management

The above controlling definitions have been criticized in the literature for
a variety of reasons:
From a system perspective, if controlling coordinates the management
system, it cannot perform a management function in itself. Coordination of
a system can only be performed from a system of higher order, thus control-
ling would be a meta-management function.281 Most controlling definitions,
however, claim that controlling is a sub-system of the management system.
Industrial practice shows that management and operative functions are
closely interwoven, and that the separation of management and operative
system is not applicable in all cases.282 Also, the normative definition of
management sub-systems, chosen by the authors favoring the coordination
view, is lacking an explanation for why the particular structure of the man-
agement system is the best possible segmentation, or if the structure is
exhaustive. The separation of management sub-systems suggests a high

279.
Note that Horváth uses the German term Kontrolle, which translates to controlling. In order to
avoid a homonym conflict and a misleading recursive definition, the term evaluation has been
chosen for the translation.
280.
Horváth (2000), p. 153.
281.
Meta (Greek: above) denotes the location of the controlling system above the management
system which it coordinates.
282.
Compare Weber (1999), p. 28. See also footnote 124 on page 34.
- 74 - Controlling of Process Organizations

degree of structure within the management system, but fails to accommo-

date situative management decisions.283
WEBER argues that a common framework for controlling tasks is neces-
sary, although the tasks of information supply, coordination, and managing
systems reflect the controlling function only in part. He points out that the
most general description of controlling is “to perform quality control for
managerial tasks.”284 The importance of a quality control function is based
on the high level of complexity managers are faced with today. BLEICHER
even argues that the core task of management is the management of com-
plexity.285 Complexity relates to the feature of systems that in a given period
of time can take on a large number of different states, effectively making the
understanding and management of the system difficult for humans.286
Complexity can be managed through the systematic division of work in
combination with personal-professional specialization. This ultimately leads
to depersonalized and technocratic systems287 and structures, which are nec-
essary to manage large-scale decentralized organizations.288 These structures
contradict the development of faster decision processes, shorter information
cycles, and automated information flows. ULRICH and PROBST warn:
“If a company is caught in a web of detailed rules and regulations it loses its ability
to spontaneously adapt to changing environmental conditions. It loses the flexibility
necessary to survive in a volatile and changing environment.”
“Complexity-reducing measures are correct if well-known goals are rationally and
securely achieved using well-known pathways. They are wrong if new goals and
pathways are explored. What we don’t know we can’t sensibly control!”289
In the context of increasing complexity, the role of controlling can be
defined as follows:290

283.
See Weber (1999), p. 29, who points out that “the following question is not answered: Can
the system structure be maintained if new management problems demand new solutions?”
284.Refer to Weber (1999), pp. 38-39.
285.Compare Bleicher (2001), p. 31.
286.For a discussion of complexity refer to footnote 95 on page 26.
287.BLEICHER defines technocratic structures as the opposite of human-oriented structures.
They are defined by formal mass-production programs, a task-oriented division of work
which leads to horizontal interfaces (that increase the complexity) and vertical interfaces
due to multi-level hierarchies. Instrumental and quantifiable factors are used to create an
equilibrium among the distributed units. The result are short-term cost orientation and risk
avoiding strategies. See Bleicher (2001), p. 593.
288.
Compare Bleicher (2001), p. 32.
289.
Refer to Ulrich, Probst (1988), p. 63.
290.
Compare Weber (1999), p. 39; Weber, Schäffer (1999). For a critique of this position refer
to Irrek (2002). Since IRREK’S definition of controlling as a control system ignores the
information and method supply functions of controlling, WEBER’S approach is more suit-
able for this work.
Controlling of Process Organizations - 75 -

Controlling has the goal to ensure the rationality of management through

the provisioning of context-specific information and appropriate evaluation
methods, and by continuously monitoring the planning and implementation
process. Figure 2-12 provides a summary of the different controlling func-
tions from an institutional and a functional perspective.

Source: Weber (1999), p. 40.

Figure 2-12: Controlling as a Function to Ensure Rational Management

The shaded area on the left side indicates the aspects of controlling rele-
vant to this book, which focuses on the analysis of information supplied by
workflow management systems and the methods that can be applied for the
evaluation of this information.
- 76 - Process Management and Process Controlling

2.5 Process Management and Process Controlling

2.5.1 Process Management

Process management can be perceived as the application of the manage-
ment cycle with a focus on organizational processes. GAITANIDES ET AL.
define process management as the collection of planning, organizing, and
controlling activities for the goal-oriented management of the organization’s
value chain regarding the factors quality, time, cost, and customer satisfac-
tion.291 The main goals of process management are the achievement of
transparency with regard to process structure and process contribution.292
NEUMANN ET AL. see the main task of process management in accompa-
nying the process implementation, and ensuring the continuous, incremental
improvement of the organization’s processes.293 Process management and
process-oriented reorganization projects are not mutually exclusive. Instead,
the restructuring of an organization with a focus on the processes should be
followed by an institutionalized process management.294
VOLCK separates management into structural management, which deals
with the structural properties of the organization, such as positions and
departments, and process management, which focuses on the design of the
organization’s processes.295 This strict separation does not hold in practice,
because the institutional interpretation of process management requires the
creation of process owners and process managers, which is clearly a task of
structural management. In addition, the design of processes has a direct
impact on the resources involved in the process and therefore influences the
conditions under which structural management has to operate.296
GADATSCH defines process management as a component of an integrated
concept for business process- and workflow management.297 It consists of
the tasks process definition, process modeling, and operative process man-
agement.298 Relating to the ARIS phase model, GADATSCH places process
management within the requirements definition phase, whereas workflow
management constitutes the implementation phase. This approach has sev-
eral weaknesses. On the one hand, the definition of process management is

291.See Gaitanides, Scholz, Vrohlings (1994), p. 3.

292.Compare Gaitanides, Scholz, Vrohlings (1994), p. 16.
293.See Neumann, Probst, Wernsmann (2002), p. 297.
294.Compare Neumann, Probst, Wernsmann (2002), p. 298.
295.Compare Volck (1997), pp. 24-27.
296.Compare Kugeler (2001), p. 61.
297.Refer to Gadatsch (2000), p. 369; Gehring, Gadatsch (1999a); Gehring, Gadatsch (1999b),
p. 70.
298.
GADATSCH uses the term “Prozessführung”, which means operative leadership of processes.
Refer to Gadatsch (2000), pp. 370-371.
Process Management and Process Controlling - 77 -

recursive (if process management contains operative process management,

what is the management part of process management?). On the other hand,
not all processes of an organization are supported by workflow manage-
ment. As SCHULTE-ZURHAUSEN points out: Only repetitive processes can
be structured and thus organized and managed.299 Creative or innovative
processes, which are part of the management system, are not repetitive and
thus cannot be managed formally (much less automated through workflow
technology).300
If we take the management cycle as described in section 2.3.3 on page 60
and treat processes as the managed entity, the planning, implementation, and
control phases can be integrated in the following procedural description of
process management:301
„ The management cycle starts with the analysis phase, which consists of
the environmental analysis and the organizational analysis. As part of
the environmental analysis, the market partners for the processes in ques-
tion are determined (customers, suppliers, third parties) and their
technical and organizational restrictions regarding the processes are
identified (e. g., if an electronic interface to the systems of a partner is
generally feasible). In addition, legal and competitive restrictions have
to be analyzed (e. g., legal issues that arise from the flow of customer
data across international borders). The environmental analysis can
also deliver information on best practices found throughout the com-
petition and through benchmarks from other domains.
The organizational analysis deals with the assessment of the company’s
capabilities to implement and execute the processes in an efficient
manner. Existing technical and organizational restrictions (such as the
existing technological infrastructure) as well as the overall “fit” of the
processes have to be determined (i. e., do the processes adequately
reflect the policies and guidelines currently in place?).
„ Based on the results of the analysis phase, an evaluation and selection of
design options is the next phase. During this phase, alternative strategies
about the outsourcing of processes or process parts as well as the
technical infrastructure are identified and evaluated (for instance, a
standard-software-based implementation versus an individual-soft-

299.
Compare Schulte-Zurhausen (1999), p. 59; Kosiol (1976), p. 31.
300.
A number of research projects about workflow support for unstructured processes exist
(compare e. g. Blumenthal, Nutt (1995); Carlsen (1997); Glance, Pagani, Pareschi (1996);
Nutt (1996) and Weske (Flexible) (1997)), but in most cases the implementation cost out-
weigh the benefits from an automated process coordination by far.
301.
For a detailed description of a procedure model for a process-modeling project refer to
Becker, Berning, Kahn (2002), pp. 20-23.
- 78 - Process Management and Process Controlling

ware-based approach). Additionally, an enterprise-wide process

framework is developed, which serves as an integration platform for
the different processes and which can be used for orientation and
communication purposes by the process designers and partici-
pants.302
„ The next phase, development of a project plan outlines the implementation
of the processes through the design of appropriate project plans. Dur-
ing this phase, reference processes or similar tools for the communi-
cation of the overall process strategy are developed.
„ During the implementation phase, processes are deployed in the operative
part of the organization, adjustments of the infrastructure resources
supporting the processes are made, and staff training on new rules
and regulations takes place.
„ Following the implementation, the continuous operative management of
processes has to ensure the efficient execution of the implemented
processes through appropriate institutional structures such as process
managers or process owners. Besides identifying responsible person-
nel, this phase focuses on the creation and usage of adequate infra-
structures for information supply.

2.5.2 Process Controlling

Process controlling has been approached from two different perspectives
in the controlling literature. While some authors focus on the advancement
of traditional controlling toward a process-oriented controlling303, other
authors put the emphasis on the controlled object, i. e., enterprise pro-
cesses.304 For example, BREDE defines process controlling as an evolution
from cost accounting and revenue management:
“The goal [of process controlling] is the creation of analytical transparency in the
organization, which serves as a basis for the creative implementation of new pro-
cesses, designed according to customer and market requirements.”305

302.
Compare, e. g., Meise (2000).
303.
Compare Brede (1996), Brede (1997); Gerboth (2000).
304.
Compare Scheer, Breitling (2000); Schmelzer, Friedrich (1997); Schmelzer, Sesselmann
(2001).
305.
Brede (1997), p. 155.
Process Management and Process Controlling - 79 -

GERBOTH defines process-oriented controlling as a precondition for the

controlling of processes:
“A first step is the creation of process-oriented controlling, which requires the align-
ment of controlling processes and instruments with the business processes. As a next
step, the controlling of processes has to be implemented - a process controlling.”306
SCHMELZER and FRIEDRICH provide a functional definition of process
controlling:
“The task of process controlling is the planning and monitoring of business process
effectiveness and efficiency. It provides process managers with the information
required for the control of their business processes. Process controlling has a signifi-
cant impact on the success of products and R&D projects and thus on the produc-
tivity and competitiveness of a company.”307
Similar to the distinction of strategic and operative management, process
controlling has a twofold purpose. At the strategic level, process controlling
has to ensure that all organizational processes cooperatively support the
organization’s goals. For this purpose, process controlling has to provide an
evaluation framework that allows the assessment of different processes
using a common set of measures.
At the operative level, process controlling has to ensure the efficient exe-
cution of individual processes and the proper utilization of the resources
required for process execution. Operative process controlling overlaps with
operative process management, since both have the same purpose: The
maintenance of operative process efficiency. However, while operative pro-
cess management is embodied in process managers and process owners,
process controlling serves the information supply function for process man-
agers as depicted in figure 2-12. In the context of process monitoring,308 status
information about running process instances are presented to the participat-
ing (and qualified) members of the organization.309 Operative process controlling
provides aggregate information about completed process instances for fur-
ther analysis.310 An effective controlling system cannot rely on data from
internal processes exclusively.311 Rather, the entire supply chain should be
the scope of the analysis, starting with relevant interfaces to market partners
and ending with the delivery of finished products or services to the custom-
ers. This concept creates new recipients for controlling information outside

306.
Compare Gerboth (2000), p. 535.
307.
Schmelzer, Friedrich (1997), p. 336.
308.
Compare, e. g., Meyer (1997).
309.
Compare Scheer, Breitling (2000), p. 399.
310.
Compare zur Muehlen, Rosemann (2000).
311.
Compare Scheer, Breitling (2000), p. 399.
- 80 - Process Management and Process Controlling

the boundaries of the company. Suppliers and customers may request infor-
mation about the progress of “their” process instances, and independent
controlling bodies may be established for the management of supply
chains.312
Figure 2-13 shows the functional decomposition of process controlling
functions. Process controlling consists of three general support functions
that are performed during the planning, implementation, and operational
phases of process management. In addition, the information supply function
of process controlling is a continuous task, and consists of the maintenance
of a current process documentation and the provision of process reports.313
During the planning phase, process controlling supports the planning of
alternative process structures through the provisioning of measurements of
existing process designs, and simulation values of alternative process struc-
tures (e. g., processes with concurrent activities, eliminated process steps,
etc.). In the course of this activity, process controlling supplies information
about the goal contribution of process structures. In addition to the process
structure, process controlling can also provide information to assist in pro-
cess staffing decisions. Through an analysis of the existing skill-set of pro-
cess participants and a requirements analysis of process activities an
necessary training activities can be determined.
The planning of measurements and target values is necessary to integrate
process goals into the information supply infrastructure of process control-
ling. The achievement of process goals cannot be determined without mea-
surements. For this reason, two critical tasks of process controlling are the
identification of suitable measurements that reflect the process goals, and
the selection of target values for these measurements. Figure 2-14 shows the
decomposition of the process structure planning activity, which is per-
formed as part of the process management cycle, and the subsequent plan-
ning of process measurements and target values as part of the process
controlling cycle.

312.
Compare Holten et al. (2002).
313.
It can be argued that creating a process documentation is part of the planning, design, and
implementation phase, and not necessarily a core function of process controlling, since pro-
cess models (as a form of process documentation) can serve many different purposes, com-
pare Rosemann, Schwegmann (2002), p. 52-58. For example, for communication and
training purposes, process models may be used by the human resources department. These
models are not the subject of process controlling efforts. However, an up-to-date docu-
mentation of processes is a precondition for the provision of process reports and thus is
part of the process controlling function catalog. For this reason, the creation and mainte-
nance of a controlling-oriented process documentation is seen as a task of process control-
ling.
Process Management and Process Controlling - 81 -

Source: Modified from Gerboth (2002), p. 44.

Figure 2-13: Functional Decomposition of Process Controlling
Process support in the implementation phase relates to the design of an infra-
structure for process measurement. While the collection and integration of
financial performance indicators is a well known task in traditional manage-
ment accounting, process performance indicators also contain time-based
information, such as turnaround times or idle times during process execu-
tion. In order to capture these values, a measurement infrastructure along
the processes has to be established, e. g., by implementing reporting and
messaging functions in process-oriented application systems.
During the enactment phase, process controlling supports operative process
control through the continuous monitoring of running processes and the
evaluation of completed processes. Possible directions for process improve-
ment are indicated by process controlling. However, the selection and imple-
mentation of these measures is a task of process management.314 Once
314.
Compare Gerboth (2002), pp. 50-51.
- 82 - Life Cycle Approaches to Process and Workflow Management

Source: Compare Gerboth (2002), p. 45.; Kugeler (2000), pp. 189-190.

Figure 2-14: Decomposition of the Planning Phase
certain activities for the improvement of the current process structure are
chosen, process controlling closely monitors the implementation of the
measures chosen, in order to give a timely feedback about deviations from
expected improvements.

2.6 Life Cycle Approaches to Process and Workflow Management

The continuous development of strategic goals, the design of process
structures, the implementation, continuous monitoring, and evaluation/
improvement phases can be arranged to form a life cycle of process manage-
ment. In the context of workflow management, several of these life cycle
models have been proposed in the literature.315

315.
Besides the life cycles by Rolles and Heilmann, Derszteler (2000) and Galler, Scheer (1995)
have presented life cycles for process and workflow management. Since these models are
simpler than the ones presented here and their content is covered by the other two
approaches, they have been omitted from this section.
Life Cycle Approaches to Process and Workflow Management - 83 -

Source: Rolles (1998), p. 128.

Figure 2-15: MOVE Workflow Life Cycle

MOVE Life Cycle

ROLLES presented a procedure model developed in the context of the
project MOVE (Improvement of business processes with flexible workflow
management systems).316 The life cycle is designed in three segments, start-
ing with the evaluation and modeling of business processes. An implementa-
tion phase follows the modeling phase and is followed by the enactment
phase, which can be adjusted through a flexible adjustment loop. The subse-
quent evaluation phase leads back to the modeling phase. The segments tech-
nology design, employee orientation and organizational development indicate the
perspectives and goals of the phases covered under these segments.
Figure 2-15 shows the MOVE workflow life cycle.

316.
Compare Rolles (1998), pp. 127-129.
- 84 - Life Cycle Approaches to Process and Workflow Management

Source: Compare Heilmann (1997), p. 2.

Figure 2-16: Workflow Management Cycle by Heilmann

Workflow Management Cycle

The workflow management cycle proposed by HEILMANN extends the
scope of activities beyond the operative implementation and enactment of
workflows.317 Instead, she separates the strategic and tactical level of pro-
cess development from the operative level of workflow enactment. On the
strategic and tactical level, as-is processes are modeled and analyzed using
simulation and animation tools.318 Depending on the results of this analysis,
the process models may be refined, until target (to-be) models are created
that satisfy the requirements of the model recipients. The partial cycle
between the steps “as-is/to-be modeling” and “analysis, comparison, con-
trolling” can be enacted multiple times. If a satisfactory process model has
been designed, this model can be implemented at the operative level using a
workflow management system. The “control” step denotes the enactment of

317.
Compare Heilmann (1997), p. 2.
318.
Refer to Heilmann (1997), pp. 1-2.
Life Cycle Approaches to Process and Workflow Management - 85 -

workflow instances, including the integration of external applications. Com-

pleted workflow instances are recorded in the step “log file creation” and
may be sent to the corporate revision for auditing purposes. The analysis of
audit trail information in the step “analysis, comparison, controlling” can
lead to a new instantiation of the modeling cycle on the strategic or tactical
level. Figure 2-16 shows the workflow management cycle by HEILMANN.

Review of Existing Life Cycles

Both workflow life cycles cover the analysis of the current (as-is) situa-
tion, the modeling and implementation of process models in workflow man-
agement systems, and the subsequent analysis of workflow protocol data in
order to implement continuous process improvement. However, both
approaches do not separate the technical implementation of the workflow
infrastructure from the conceptual design of workflow models. Also, the
monitoring of workflow instances during their execution and adjustments to
running workflows are not addressed by both life cycle models. The feed-
back cycles describe work at the operative management level, but do not
address, how process-relevant information can be applied to management
control at the strategic level.

A Management-Oriented Process Life Cycle

A new process management life cycle is depicted in figure 2-17. It is
related to the life cycle models for workflow modeling shown above, and
integrates and extends the work performed by HEILMANN319, GALLER and
SCHEER320, and STRIEMER and DEITERS321. Additional input was taken
from the more coarse-grained process life cycle by NEUMANN, PROBST and
WERNSMANN322.
The cycle starts with an initial analysis of the project goals, the environ-
ment of the future workflow application, and the organizational structures
and rules surrounding the new system. This phase is followed by a process
design phase, during which the overall process structure is engineered, the
process model is designed, and the resources involved in the process execu-
tion and responsible for its results are specified. This includes the modeling
of organizational structures as well as the definition of task assignment poli-
cies and conflict resolution mechanisms.

319.
Compare Heilmann (1994), p. 14; Heilmann (1997), p. 2.
320.
Compare Galler (1997), p. 25; Galler, Scheer (1995), p. 22
321.
Compare Striemer, Deiters (1995).
322.
Neumann, Probst, Wernsmann (2002), p. 308.
- 86 - Life Cycle Approaches to Process and Workflow Management

Figure 2-17: Process Life Cycle

The completed process models are input of the process implementation
phase. During this phase, the infrastructure for business process support is
designed, and the solution is integrated with surrounding information sys-
tems.
During the process enactment phase, individual process instances are derived
from the process model and they may be coordinated by the process auto-
mation infrastructure. Process participants are notified about pending activi-
ties, and available resources are used during process execution. At the same
time, from an administrative perspective, process monitoring takes place. On the
technical side, the performance of the process management system itself is
Life Cycle Approaches to Process and Workflow Management - 87 -

measured. On the organizational side, measures such as the length of work

queues, the idle time of resources or the wait time of pending activities are
supervised.
The process evaluation phase completes the process management cycle. Dur-
ing this phase, the execution of process instances is analyzed from an ex-
post perspective, based on the execution protocols (audit trail). Results from
this analysis can serve as the basis for the planning of resource capacities
(i.e., how many performers an actual process instance needs to be staffed
with). The capacity adjustments might be tested during an animation and
simulation phase, where performance information from completed process
instances can be used as simulation parameters. In addition, adjustments to
the process structure can be tested with regard their impact on process per-
formance.
In this chapter we have focused on the organizational aspects of process
management, monitoring, and controlling. The following chapter focuses on
the technical infrastructure that enables process management, monitoring,
and controlling.
- 88 - Life Cycle Approaches to Process and Workflow Management
History of Process Automation Technology - 89 -

3 Technology Support for Process Organizations

In the previous chapter we have outlined the organizational aspects of
managing business processes, and discussed the monitoring and controlling
of processes from a perspective of management theory. In this chapter we
focus on the technology support for process organizations that provides the
infrastructure for process controlling applications. For this purpose, the
chapter starts with a historical retrospective and is then organized along the
process life cycle. We start with a review of the development of process
automation technology in chapter 3.1, and provide an overview of the core
technology concepts of workflow management and process automation in
chapter 3.2. Chapter 3.3 focuses on the technical realization of workflow
technology, while chapters 3.4 discuss standardization efforts in this area.
chapter 3.5 focuses on the development of process-aware application sys-
tems, while the final chapter in this section focuses on the deployment and
use of workflow applications.

3.1 History of Process Automation Technology

The idea of software support for corporate processes has been researched
since the late 1960’s. In the context of organizational theory, NORDSIECK
predicted the process-oriented design of information systems:
“Think about [a] modern data processing [system]. This, too, represents a percepti-
ble process that is even connected with the business process, and accompanies - or
even controls - this process across various [process] segments.”323
At the time - the late 1960s - application development was driven by
increasing volumes of data, which were of interest to different recipients
inside the corporation. However, real-time access to computing technology
from the desktop of the office worker was not economically feasible, even
for large corporations. The idea of time-sharing computers, which allowed
the end user to manipulate the data stored in the system was only addressed
by researchers like DOUGLAS ENGELBART at the Stanford Research Insti-
tute, who demonstrated the prototype of an office system called NLS
(oNLine System) at the Fall Joint Computer Conference 1968.324 The first
commercial efforts in the area of real-time applications was the Semi-Auto-
matic Business Research Environment (SABRE) by IBM and American Air-
lines, a travel reservation system that went into production in 1960. But even

323.
Nordsieck (1972), col. 9 (translated from the German original).
324.
See Freiberger, Swaine (2000), pp. 303ff., and the video of the noteworthy demonstration at
http://sloan.stanford.edu/MouseSite/1968Demo.html.
- 90 - History of Process Automation Technology

SABRE did not allow travel agents to connect to the system directly until
1976.325
The impact of computing technology on office work in the early 1970s
was determined by growing database applications and the advent of end-
user computing technology, where terminals were used for on-line main-
frame access. However, application development was just beginning to shift
from departmental-specific solutions with application-specific data storage
concepts to a more modular design, where application data was stored in
central databases. The business process logic was embedded in application
system code and thus difficult to change. Put concisely, the aim of workflow
management technology is the separation of process logic from application
logic, in order to enable flexible and highly configurable applications.
JABLONSKI and BUSSLER name seven fields as the conceptual ancestors of
workflow management technology:326 Office automation, database manage-
ment, e-mail, document management, software process management, busi-
ness process modeling, and enterprise modeling and architecture. In
addition to these fields, SHETH mentions distributed object management,
imaging technology, transaction processing monitors, workgroup software
and Internet technology as domains that are influential to workflow man-
agement technology.327

3.1.1 Office Automation Technology

The automation of production floor environments through production
planning and -control software, which simplified repetitive tasks such as the
scheduling of orders, led to significant productivity gains in the 1970’s and
1980’s. In contrast to these gains, the productivity of office workers had not
increased, despite the deployment of information technology in office envi-
ronments.328 Fueled by the enthusiasm over increasing computing power
and higher accessibility of information technology, a number of research
projects emerged that studied the application of information technology to
office environments.329 The focus of office automation research was
“to reduce the complexity of the user’s interface to the [office information] system,
control the flow of information, and enhance the overall efficiency of the office.”330
325.
See Anthes (2004), pp. 24-25.
326.
See Jablonski, Bussler (1996), p. 7 ff. The authors explicitly state that the seven conceptual
influences do not constitute an exhaustive list.
327.Refer to Sheth (1997), p. 18.
328.Compare Wißkirchen (1983), p. 11, who refers to the findings of Picot (1982): “As we
know, productivity gains in the area of office tasks are lagging significantly behind those in
the area of blue collar work.“
329.
See Burns (1977); White (1977).
330.
Ellis, Nutt (1980), p. 28.
History of Process Automation Technology - 91 -

The works of ELLIS and NUTT on office automation prototypes at the

Xerox PARC during the late 1970s had a significant impact on the develop-
ment of early office automation systems. Their systems, called Officetalk-
Zero331, Backtalk (a test environment for Officetalk-Zero)332, Officetalk-
P333, and Officetalk-D334 used a form-based analogy for the structuring of
business processes. These processes were represented as Information Con-
trol Nets (ICN), a formalism derived from Petri Nets. The focus of the
Officetalk prototype was the interaction of office workers with a graphical
user interface that used common office metaphors, such as inbox, outbox, and
forms.335 In the outlook of one of their articles, Ellis and Nutt foreshadow
the use of office automation systems for process controlling purposes:
“[...] an [Office Information System] might support successively higher levels of
management by offering [...] the chief executive officer the ability to control and
audit corporate resources.”336
One of the first prototype systems that supported organizational pro-
cesses was SCOOP (System for Computerization of Office Processes),
developed by MICHAEL ZISMAN. SCOOP was an office automation system
that used Petri Nets to represent business processes.337 His augmentation of
Petri Nets supported the multiple triggering of activities, in case the number
of activity instances necessary could only be determined at run time, and
deadlines, in case time constraints for activities were violated. Another lan-
guage for modeling office processes was introduced by KREIFELTS in 1983.
KREIFELTS predicted:
“[Future office systems] will rarely be the one or two-place text system. Instead, they
can be imagined as a group of ’intelligent’ workstations, connected via a local net-
work. [...] Not the single activity at a workplace solves a task within an office orga-
nization, but several of these single activities that are connected through a network
of customer-supplier-relationships.”338

331.
See the detailed description of Officetalk-Zero and its comparison to approaches like
SCOOP and BDL in Ellis, Nutt (1980).
332.
Refer to Nutt, Ellis (1979).
333.
Refer to Ellis (1979).
334.
Refer to Ellis (1982); Ellis, Bernal (1982).
335.
In the outlook of their paper, ELLIS and NUTT envisioned the next generation of office
automation systems: “The notion of the intelligent form [...] could be extended to allow a
forms process to guide itself through various work stations and measure its own progress,
utilizing the facilities of particular work stations within their own domains.” Ellis, Nutt
(1980), p. 57. At the same time, the technical state-of-the-art is illustrated by the following
quote from the same paper: “Areas on the screen are pointed to by a cursor under the con-
trol of an x-y coordinate input device called a mouse.” Ellis, Nutt (1980), p. 29.
336.
Ellis, Nutt (1980), p. 57.
337.
Refer to Zisman (1977), Zisman (1978).
338.
Kreifelts (1983), p. 216.
- 92 - History of Process Automation Technology

The findings of KREIFELTS and his colleagues at the German GMD led
to the development of the DOMINO system339, which was later used by
Olivetti as the basis of the commercial X_Workflow system.340 While most
office automation prototypes relied on Petri Net-based models for the rep-
resentation of office procedures, IBM developed a Business Definition Lan-
guage (BDL) as a high-level programming language for processes. BDL was
supposed to enable office workers to create formal office processes on the
fly, but had little success in practice.341

3.1.2 From Office Automation to Workflow Management

Figure 3-1 gives an overview over the historical development of office
automation systems and workflow technology.342 Research in office automa-
tion, which flourished between 1975 and 1985, laid the groundwork for the
development of industrial workflow applications through the analysis of
technology support for administrative processes.343
While the research interest in office automation ceased by the middle of
the 1980s344, the commercial exploitation of workflow technology began
between 1983 and 1985. It was fostered by advances in imaging and docu-
ment management technology on the one side, and enhanced e-mail systems
that extended traditional point-to-point mail routing with a predefined pro-
cess map on the other side.345 From this first generation of workflow sys-
tems, only few vendors are still active, while the majority of the early players
have been restructured through mergers and acquisitions, or dropped out of
the market altogether.

339.For a detailed description of the DOMINO system see Kreifelts et al. (1991) and Woetzel,
Kreifelts (1993).
340.
Compare Woetzel, Kreifelts (1993), p. 11.
341.
Refer to Hammer et. al (1977).
342.
Besides scientific prototypes, figure 3-1 shows a number of commercial systems that either
had a significant impact on the marketplace or were derived from scientific prototypes. The
current workflow market is extremely fragmented. For an overview of workflow vendors
and their systems refer to Karl (2001), and web sites such as the Workflow and Reengineer-
ing International Association (www.waria.com) or the Workflow Management Coalition
(www.wfmc.org). The current state of the workflow market versus the findings of researchers
in the workflow domain were discussed by Abbott, Sarin (1994); Georgakopolous, Hornick,
Sheth (1995); Alonso et al. (1997) and Du, Elmagarmid (1997).
343.
See Mahling, Craven, Croft (1995) and Nutt (1996).
344.
Compare Swenson, Irwin (1995).
345.
Examples systems within this category are Beyond Corporation’s BeyondMail (which was
bought by Banyan in 1995 and discontinued 1998), JetForm (now Accelio Corp.) and Pow-
erWork. Most e-mail based systems rely on an external e-mail and messaging systems, which
they enhance with routing and task assignment functionality.
History of Process Automation Technology - 93 -

Figure 3-1: History of Office Automation and Workflow Systems

- 94 - History of Process Automation Technology

3.1.3 Other Related Technologies

BECKER and VOSSEN have pointed out three areas that were influential
for the development of workflow management systems.346 As an extension
of electronic mail systems, workflow management systems enable the fast
communication and collaboration between geographically dispersed users
along a common workflow model. In addition, workflow management sys-
tems have similarities with active database systems that monitor the state of
a system and trigger activities upon these events.347 Finally, workflow man-
agement systems are related to federated databases and extended transaction
concepts, since - from the perspective of database management researchers -
a workflow can be perceived as a long-running transaction and requires
sophisticated fault handling and recovery mechanisms.348 Besides these
areas, the development of document management technology has been
instrumental in the commercial success of workflow technology.

Document Management Systems

The roots of commercial workflow management systems can be traced to
the design of workflow components for document management applica-
tions349 in the mid 1980s.350 Users like BlueCross/BlueShield and vendors
like FileNet enhanced existing imaging and document storage solutions with
functionality to route electronic images to the in-boxes of office workers,
based on a predefined activity sequence (compare figure 3-1). Workflow
management systems enhance document management systems with the abil-
ity to model approval processes, route documents based on their attributes
to the right performer, and increase process transparency through monitor-
ing functionality.351 Many economically successful workflow projects are
based on a combined workflow and document management infrastruc-
ture.352 In recent years, the use of workflow management in document pro-

346.
Compare Becker, Vossen (1996), p. 21.
347.
For a discussion of workflow management systems based on these event-condition-action
(ECA) rules compare Geppert, Tombros (1996); Casati et. al (1996); Kappel, Rausch-
Schott, Retschitzegger (1998).
348.
There is a large body of literature on the extension of database transaction concepts for
workflow purposes, compare for example Georgakopolous et al. (1993); Sheth, Rusink-
iewicz (1993); Rusinkiewicz, Sheth (1995); Tangt, Veijalainen (1995); Alonso et al. (1996).;
Worah, Sheth (1996); Zhou, Pu, Liu (1998).
349.
Document management system describes a collection of technologies, ranging from the
digitization of paper documents (Scanning), the automated classification of these docu-
ments according to their content (Indexing, Optical and Intelligent Character Recognition
(OCR/ICR)), the storage and retrieval of electronic documents (Archiving) to the manage-
ment of these archive structures with sophisticated retrieval and indexing technologies
(Document Management). Compare Bock (2001). Note that some authors use the term
document management for the handling of paper documents as well. Compare Götzer et. al
(2001), p. 7.
350.
Compare Georgakopolous, Hornick, Sheth (1995), p. 121.
351.
Compare Götzer et al. (2001), pp. 74-77.
History of Process Automation Technology - 95 -

cessing applications was extended to also cover the authoring of documents

and the management of document content (e. g., the workflow management
system handles the review-and-publish cycle by notifying reviewers and by
monitoring deadlines).353
The focus of document-oriented workflow management systems is the
process object (in most cases an electronic document). This view has an
impact on the process modeling paradigm employed by these systems. While
activity-based modeling methods represent a process as a sequence of tasks
with associated performers, document-oriented workflow applications are
often based on state-based modeling methods. These describe a process in
form of the legal state-changes of the process object, e. g., a document that
may change from drafted to reviewed to either rejected or approved.354

E-Mail Applications
Another predecessor of workflow technology are advanced e-mail appli-
cations.355 While standard e-mail system realize simple point-to-point rout-
ing of messages (with one or more recipients), workflow management
concepts extend this functionality to include a list of recipients that are
addressed sequentially (e. g., to coordinate the editing of a document).356
From a research point of view, messaging-based workflow systems are inter-
esting for aspects such as evolutionary workflow modeling or the support of
unstructured processes where the actual sequence of activities is determined
at run time. Another facet of this type of application, messaging-based work-
flow, is based on the notion of a network of processing stations that are sup-
plied with process objects in a structured way. This represents yet another
modeling paradigm as opposed to the activity-oriented or process-object-
oriented perspective.357

Database Management
Workflow management systems rely on database technology to store
workflow and organization models, the current state of workflow instances,
and data relevant to the execution of workflow instances. The resulting
impact on the design of database management systems has initiated a num-
352.
For a survey of studies from such implementation products compare the annual award
series of the Giga Information Group. Compare Fischer, Moore (1997); Fischer (1999); Fis-
cher (EIP3) (2000); Fischer (EIP4) (2000).
353.Compare Surjanto, Ritter, Loeser (2000).
354.For example, the modeling component of the system CSE WorkFlow (now SER FloWare)
relies on the state-based modeling technology. Compare Raetzsch (1999).
355.
Compare Becker, Vossen (1996), p. 21.
356.
For a case study compare Gebauer, Schad (1998).
357.
An example for a workflow-system based on the notion of intelligent processing stations
was presented by Barbará, Mehrotra, Rusinkiewicz (1996) with their INCAs project.
- 96 - History of Process Automation Technology

ber of research initiatives that analyze the use of database concepts in work-
flow applications.358
Two areas of database management have been of particular interest for
workflow researchers: Transaction management and active rules. From a
transaction management perspective, a workflow instance can be perceived
as a long-running transaction with multiple sub-transactions (i. e., the activi-
ties).359 Since workflow instances often interact with applications outside of
the control sphere of the workflow enactment service, the failure of applica-
tions during the enactment of a workflow instance has to be taken into
account. Also, since business-relevant data treated in the context of a work-
flow-instance is in most cases accessible to other applications as well, a
workflow engine cannot lock this data from access by other applications
without reducing the efficiency of the entire corporate information sys-
tem.360
From the perspective of active database research, workflow management
systems can be implemented through the specification of triggers and active
rules in databases, which monitor system conditions and raise triggers upon
the detection of specified events.361 The sequence of activities would thus
be implemented as a collection of database actions. The first activity would
be executed upon receipt of an external trigger and would create a new event
upon its completion, triggering new activities along the workflow model.

3.1.4 Commercial Use of Workflow Technology

Workflow management systems have found widespread attention since
the advent of this technology in the late 1980s.362 The Association for Infor-
mation and Image Management (AIIM) estimated the worldwide revenue
for workflow technologies to grow from $4.3bn in 2000 to $8.3bn in 2003 at
a compound annual growth rate of 31%.363 Especially in conjunction with

358.Compare for example the WIDE project as described in Grefen, Pernici, Sánchez (1999).
359.Compare Leymann, Roller (2000), pp. 20-21.
360.An example is the treatment of customer data in an order processing workflow. If the work-
flow engine locked the customer record from access by other applications, concurrent bill-
ing and shipping processes could not proceed, because they would not be able to access the
relevant customer record. The short time span of locking phases in database systems allows
measures like the 2-phase-locking protocol for consistency and integrity assurance in data-
base applications. The long time span of workflow instance enactment, which can span
days, or even weeks, requires relaxed transaction concepts to ensure the integrity of work-
flows. Compare Leymann, Roller (2000), pp. 20-22 and 232-282.
361.
Compare Geppert, Tombros (1996).
362.
Note that the increasing interest does not necessarily reflect the acceptance and use of
workflow systems. Ellis and Nutt point out that “The history of workflow application in
corporate America has been mixed; more systems have silently died than been successful.”
Ellis, Nutt (1996), p. 141. Also compare the findings of Bair (1981) and White, Fischer
(1994).
363.
Compare Emery (2000).
History of Process Automation Technology - 97 -

document management technology, workflow systems are perceived as the

enablers of office productivity gains through the elimination of manual rout-
ing and work distribution tasks.364 Recently, workflow management systems
have spread beyond the administrative environment and can also be found
as embedded software components, which enhance existing application
packages (e. g., ERP systems) as well as infrastructure components (such as
application servers) with process management functionality.365 For instance,
the current infrastructure component of the SAP NetWeaver package has
three process automation components: Cross-component Business Process
Management for the integration of applications across system boundaries;
Business Workflow for the automation of people-to-system processes within
a system component; and Collaborative Workflow for the automation of
unstructured, ad-hoc people-to-people processes.366
Although workflow management systems can increase the process effi-
ciency of an enterprise by as much as 150%367, they do not necessarily lead
to a more flexible organization.368 Since the introduction and deployment of
a workflow-based information system architecture is a complex and time-
consuming endeavor, it can be observed that - once this kind of architecture
has been successfully deployed - many companies resist the urge to apply
changes to the new system (an effect that can be observed at companies
introducing ERP packages as well).
One frequently criticized aspect of workflow management systems is the
enforcement of rigid process structures that do not offer the opportunity to
adjust the sequence or the content of activities to match the actual situation
at run time. One extreme example for this kind of lock in is the action work-
flow approach by WINOGRAD and FLORES, which represents a process as a
series of speech acts between a requester and a provider.369

364.
There are numerous publications regarding the synergies between document management
and workflow technology. Compare e. g. Attinger (1996); Frappaolo (2000); Emery (2000).
While the paperless office was the ultimate goal for many researchers in the 1980s, recent
research has shown that due to sociological reasons the elimination of paper from office
procedures is rather unlikely. Compare Sellen, Harper (2002).
365.
For the distinction between embedded and stand-alone workflow products refer to zur
Muehlen, Allen (2001).
366.Compare SAP AG (2004).
367.Compare Moore (2000).
368.The inflexibility of activity-based workflow models have been pointed out, e. g., by Wong,
Low, Ren (1998).
369.
Compare Medina Mora et al. (1994). Winograd, Flores (1996) provide the formal founda-
tion for the underlying speech act model.
- 98 - Workflow Application Concepts

Each of these conversations follows a cycle of four phases:

„ Preparation: During this phase a customer asks a performer to pro-
vide a specific service.
„ Negotiation: During this phase customer and performer negotiate the
conditions of service fulfilment, such as quality aspects and the due
date.
„ Performance: During this phase the performer creates the negotiated
service. The performer can ask other performers to provide parts of
the overall service. During these interactions the performer takes on
the role of a customer for the fulfilment of sub-services.
„ Acceptance: During the final phase of the cycle the result of the ser-
vice is inspected by the customer and either accepted or rejected.
SUCHMAN argues that activities are performed in situ and the design of
future activities depends on the actual execution of previous activities, thus
making an a priori process design at a fine level of detail impossible.370
Instead, she proposes the specification of processes as situated actions.
SCHMIDT - in the tradition of SUCHMAN - uses the metaphor of maps and
scripts for process specifications. 371 Process models are consulted as maps if
members of the organization do not know how to handle a specific situa-
tion. They are used as scripts if process participants have to adhere to a par-
ticular sequence of activities at all times. Following this metaphor, most
workflow management systems rely on the scripting of processes, while
most Groupware applications rely on representing processes as maps. Which
of these two extremes is applicable in a given situation depends - among
other factors - on the organizational context, the attributes of the process in
question and the corporate culture of the surrounding organization.

3.2 Workflow Application Concepts

In this section we establish the basic terminology used for workflow
applications in this book. After a review of the relevant terminology and the
definition of different perspectives that can be applied to the analysis of
workflow applications, we discuss two particular aspects of workflow appli-
cations: Coordination and integration.

370.
Refer to Suchman (1987) and her criticism of the action workflow approach in Suchman
(1994) and Suchman (1995).
371.
Compare Schmidt (1997).
Workflow Application Concepts - 99 -

3.2.1 Terminology and Definitions

“The relatively new field of workflow management systems suffers from confusion
caused by weakly defined concepts and a lack of consensus about the way in which
these concepts are used.”372
This statement by JOOSTEN illustrates the state of the workflow manage-
ment community at the middle of the 1990s. Due to different conceptual
ancestors and the variety of workflow-related technologies, terminology
from different computer science areas was used for the definition of work-
flow management systems and their underlying concepts. Despite the fre-
quent use of synonyms by users and vendors (e. g., task, step, procedure, to
name a few synonyms for elementary activities), the fundamental under-
standing of workflow management and workflow management systems has
been unified in large parts by the terminology and glossary work of the
Workflow Management Coalition (WfMC).373
Based on the discussion of the term process in chapter 2, we have defined
a workflow in section 2.2.2 as a specific representation of a process, whose
formal coordination mechanisms between activities, applications, and pro-
cess participants can be controlled by an information system, the so-called
workflow management system.
A workflow management system is defined by the WFMC as:
“A system that defines, creates and manages the execution of workflows through the
use of software, running on one or more workflow engines, which is able to interpret
the process definition, interact with workflow participants and, where required,
invoke the use of IT tools and applications.”374
Per this definition, a workflow management system consists of a model-
ing component for the creation of workflow models, functionality for the
creation of workflow instances from these workflow models, and functional-
ity for the execution of these workflow instances.375 The functional compo-
nent for the enactment of workflow instances is called workflow engine.376 The
engine metaphor has been criticized by a number of authors, as it implies
that the core functionality of a workflow management system is concen-
trated around one monolithic application. Instead, the critics point out, the
functionalities described above can be supplied by different services that

372.Joosten (1996), p. 2.
373.Compare WfMC (Glossary) (1999).
374.WfMC (Glossary) (1999), p. 9. The WfMC names the terms workflow automation, work-
flow manager, workflow computing system, and case management as possible synonyms.
375.
Within this book, the terms workflow model and process definition are used as synonyms.
376.
Compare WfMC (Glossary) (1999), p. 73, where a workflow engine is defined as “a soft-
ware service [...] that provides the run time execution environment for a process instance.”
- 100 - Workflow Application Concepts

may be implemented at different locations. It is important to note that a

workflow management system is typically composed of a workflow engine
(no matter how it is implemented) as well as additional components, such as
modeling environment, run time clients, and administration components.
A workflow model is defined by the WFMC as:
“The representation of a business process in a form which supports automated
manipulation, such as modeling, or enactment by a workflow management system.
The process definition consists of a network of activities and their relationships, cri-
teria to indicate the start and termination of the process, and information about the
individual activities, such as participants, associated IT applications and data,
etc.”377
This definition is limited to activity-based process modeling. Alternative
approaches to workflow process modeling are presented in section 3.5.2.
The restriction to business processes is an unnecessary limitation, since
workflow management systems can also be applied to the automation of
software processes.378 From a functional perspective, the main tasks of a
workflow management system can be grouped into planning, implementa-
tion, enactment, and evaluation of workflows. The planning and implemen-
tation phase are also called build time phase, while the enactment and
evaluation phase are considered as run time phase.379 Figure 3-2 depicts the
functional decomposition of these four phases.
During the planning phase the conceptual model of the process to be auto-
mated is created, and organizational responsibilities as well as the links to
external applications that are invoked during activity execution are specified.
The data model of the information that is passed along the activities is
designed during this phase as well. Finally, target values and measurements
for the duration of activities and processes are determined, as is the behavior
of external systems the workflow management system interacts with.
In the implementation phase the conceptual workflow model is transformed
into an executable representation. Some systems require a translation, since
their internal representation of the workflow model and the representation
used by workflow modelers are different. Other systems rely on a shared
database for the modeling and execution phases, and their executable work-
flow models are identified by an attribute. On a technical level, the interfaces
to external systems need to be implemented at this stage in order to realize

377.WfMC (Glossary) (1999), p. 11.

378.Compare Gruhn, Deiters (1994); Gruhn, Wolf (1995).
379.Compare Leymann, Roller (2000), pp. 62-63; The Workflow Management Coalition uses
the terms process definition mode and process execution, respectively. Compare WfMC
(Glossary) (1999), p. 31 and p. 66.
Workflow Application Concepts - 101 -

Figure 3-2: Functional Decomposition of Workflow Management

- 102 - Workflow Application Concepts

the communication between the workflow management system and invoked

applications as well as front-end systems used for user interaction.
The enactment phase refers to the instantiation and execution of a single
workflow instance from a previously defined workflow model (this instance
is sometimes called a workflow case). The workflow engine coordinates the
control flow by regulating the activation and execution of activities depend-
ing on the state of the overall process. It coordinates the data flow by trans-
ferring (and transforming, eventually) relevant data objects between
activities and between the workflow system and invoked applications. The
coordination of resource assignments relates to the identification and notifi-
cation of workflow participants about pending activities by the workflow
management system. The overall integrity of workflow instances is moni-
tored by the workflow management system, i. e., escalation procedures are
triggered if deadlines are exceed, and information about the current state of
workflow instances is provided to interested parties (e. g., customers that
inquire about the status of an order).
As part of the evaluation phase a workflow management system creates an
audit trail which contains information about the behavior of the system and
the execution of workflow instances. This functionality can also be part of
the enactment phase, since audit trail information can be used for the identi-
fication of workflow participants (e. g., to reroute an activity to the per-
former of a previous activity).
By taking the functional decomposition of workflow management into
account, we can define a workflow model as the conceptual representation
of a process, specified in a manner that allows the automated coordination
of activities, applications, process participants, and process objects through a
workflow engine. This representation can be graphical or text-based. An
external workflow model is specified using a modeling language readable for the
human workflow modeler. An internal workflow model is represented in a lan-
guage which can be interpreted by a workflow engine. Both models may be
represented using the same language, if this language fits both purposes.
A workflow instance is an individual representation of a process based on a
workflow model, which is enacted by the workflow engine.380 The activity
models of the workflow model are represented as activity instances. Workflow
participants are notified about pending activity instances through represen-
tations of these instances that are called work items. Each workflow partici-

380.
Compare WfMC (Glossary) (1999), p. 18.
Workflow Application Concepts - 103 -

pant is associated with one or more work lists, which serves as a repository
for work items assigned to this participant.
A workflow application system (or workflow-based application) is an applica-
tion system which uses (in whole or in part) a workflow engine for the coor-
dination of application components, users, data, or parts thereof. It consists
of one or more workflow engine(s), invoked applications, administration
components, user interfaces, and related data stores.

3.2.2 Perspectives on Workflows

A separation of views is necessary for the analysis of workflows and
workflow-based applications, in order to reduce the complexity of the sys-
tem analyzed. We can apply a number of frameworks for this purpose, start-
ing with the ARIS framework, which was introduced in section 2.2.5.
Another framework that supports the separation of views is the Computer
Integrated Manufacturing Open Systems Architecture (CIMOSA), which
was presented by VERNADAT.381 The CIMOSA architecture distinguishes
between function, information, resource, and organization views. The inten-
tion of the CIMOSA consortium - to provide an integrating infrastructure
for the execution of enterprise models - is closely related to the intention of
workflow management systems - to provide an integrating infrastructure for
the execution of process models. The generic building blocks of the
CIMOSA architecture are shown in table 3-1.382

Function View Information View Resource View Organization View

„ Domains „ Enterprise Objects „ Capabilities „ Responsibility

Requirements
Definition

„ Domain Processes „ Object Views „ Authority

„ Business Processes „ Object Relationships
„ Enterprise Activities „ Information Elements
„ Events „ Integrity Rules

„ Specified Functional „ „ Specified Capabilities „ Organization Units

Specification

External Schemata
Operations „ Conceptual Schemata „ Specified Resources „ Organization Cells
Design

„ Integrity Constraints „ Specified Resource

„ Database Transac- Units
tions

„ Implemented Func- „ Implemented External „ Implemented Capabil- „ Implemented Organi-

Implementation

tional Operations Schemata ities zation Units

Description

„ Internal Schema „ Implemented „ Implemented Organi-

„ Logical Data Schema Resources zation Cells
„ Physical Data Schema „ Implemented
Resource Units

Table 3-1: CIMOSA Generic Building Blocks

381.
Refer to Vernadat (1996); ESPRIT Consortium AMICE (1993).
382.
Refer to ESPRIT Consortium AMICE (1993), p. 53.
- 104 - Workflow Application Concepts

A framework of different perspectives for workflow analysis was pre-

sented by JABLONSKI and BUSSLER as part of the conceptual design sur-
rounding the MOBILE workflow management system.383 They distinguish
between the mandatory perspectives function, operation, behavior, informa-
tion, and organization. These perspectives can optionally be enhanced with
views covering the causality, integrity and failure recovery, quality, history,
security, and autonomy of the workflow.
Each view is separated into a factual perspective and a systemic perspec-
tive. Factual perspectives contain entities that exist independent of an actual
workflow implementation, i. e., they relate to the complete specification of a
workflow model which may or may not be automated. Systemic perspectives
relate to the implementation of a workflow model in the context of a spe-
cific workflow management system. They contain information pertinent to
the technical realization of a workflow. An example for this separation is the
treatment of information about completed activities. From the factual per-
spective, this information is relevant for auditing and process controlling
purposes; from the systemic perspective, this information may be used to
determine the behavior of activities at run time (e. g., if an activity has to be
executed by the manager of another activity’s performer).

Function Perspective
The function perspective contains a static description of the functional
entities the workflow model is composed of, i. e., the workflow process itself
as well as atomic and complex activities, which form a tree with the work-
flow process as the root element.384 This view corresponds to the function
view of the ARIS framework as well as the function view of the CIMOSA
framework.

Operation Perspective
The elements of the operation perspective describe the implementation
of the workflow activities, i. e., the business functionality that is performed
during the execution of a workflow activity.385 Independent (or autono-
mous) workflow management systems typically act as a process coordinator.
They use a black-box-model of activities, i. e., they coordinate the sequence
of activities, independent of the activity semantics. Nevertheless, for the

383.
Compare Jablonski, Bussler (1996), pp. 118-121.
384.
Compare Jablonski, Bussler (1996), p. 119; Weske, Vossen (1998), pp. 363-364.
385.
Leymann and Roller state that “building an activity implementation is sometimes called pro-
gramming in the small. All low-level algorithmic aspects of a business function must be dealt
with, data accesses must be performed, and communication with an end user must be
established. Programming in the small is the traditional notion of programming.” Leymann,
Roller (2000), p. 218.
Workflow Application Concepts - 105 -

invocation of application programs and the presentation of data associated

with an activity, the interaction of the workflow engine with existing applica-
tions and user interfaces is specified in the operation perspective.386

Behavior Perspective
The behavior perspective contains elements that describe the dynamic
properties of a workflow process.387 This includes the control flow between
activities (i. e., the logical ordering of activities) and constructs such as loops,
splits, joins, event synchronization, and triggers, which are used to refine the
control flow.388 Depending on the modeling language used, different model-
ing constraints have to be observed. For example, some languages demand a
cycle-free graph, which prohibits the modeling of loops through control
flow constructs. Instead, systems using these languages offer a specific activ-
ity type which is repeated until an exit condition is met. If the modeling lan-
guage allows the nesting of processes and activities (multiple levels of
processes and sub-processes), control flow loops can be represented in this
way.

Information Perspective
The information perspective contains the data objects processed within
the workflow as well as the data flow between different activities and data
type conversions. The Workflow Management Coalition distinguishes three
types of data within workflow systems:389
„ Application data represents those data objects that are manipulated by
the external applications during the enactment of a workflow instance.
This type of data is typically not accessible to the workflow manage-
ment system. An example for application data is a document that is
created by a workflow participant using a word processing application.
If the content of documents is not relevant to the control flow of a
process, these documents are regarded as application data.

386.
Compare Weske, Vossen (1998), pp. 366-367.
387.
Compare Jablonski, Bussler (1996), p. 120; Weske, Vossen (1998), p. 364. The specification
of the workflow model is called programming in the large by Leymann and Roller. “Specifying a
process model has many aspects in common with programming. Input and output struc-
tures of activities are defined, control and data flows between the various activities are fur-
nished, and transaction boundaries are established. This kind of programming is sometimes
called programming in the large, because it does not deal with low-level algorithmic aspects of
an application but specifies “what happens when” in the overall environment.” Leymann,
Roller (2000), pp. 217-218.
388.
For a discussion of control flow elements compare Jablonski (1995), pp. 34-37.
389.
Compare WfMC (Glossary) (1999), pp. 53-56.
- 106 - Workflow Application Concepts

„ Workflow relevant data is used by the workflow management system to

determine the control flow (i. e., transitions between activities) and
may be passed between workflow management systems and invoked
applications. Typed workflow relevant data is encoded in a format that
can be interpreted by the workflow engine. Using typed data, field val-
ues can be used to determine the control flow or the responsible
workflow participant for an activity instance.390 Untyped workflow rel-
evant data is treated as a black box by the workflow engine and passed
from one activity to the next. This type of data can be found in soft-
ware process applications where the workflow engine performs auto-
mated routing of data between application systems.
„ Workflow control data is produced by the workflow engine itself and is
not accessible to invoked applications. This type of data represents
information like the state of workflow instances and activity instances,
current resource assignments, users logged on to the system, and so
forth. If a workflow engine is embedded in a larger application, work-
flow control data may be made available to the surrounding applica-
tion through application programming interfaces (APIs). Workflow
control data is typically the source of audit trail information.391

Organization Perspective
The organization perspective addresses the assignment of activities to
organizational resources. Entities within this perspective include workflow
participants392, organizational structures (e. g., departments or responsibili-
ties), and roles (e. g., manager, clerk, auditor). Roles are used as a proxy
between actual system users and the activity specification, to foster the inde-
pendence between the workflow model and the organization structure. At
run time, the workflow engine determines system users that are members of
the specified role and notifies them about the pending activity instance. This
process is called staff resolution.393

390.
An example for typed workflow relevant data is a customer number passed along the activ-
ities. If the relationship between customers and customer representatives is encoded in the
organizational model, the workflow engine can assign the activity instances automatically to
the responsible agent depending on the value of the attribute “customer number”.
391.
The WfMC states that “workflow control data may be written to persistent storage periodi-
cally to facilitate restart and recovery of the system after failure. It may also be used to
derive audit data.” WfMC (Glossary) (1999), p. 56.
392.A workflow participant is a resource which performs an activity. Resources can be human
resources or technical resources, such as software agents. Compare WfMC (Glossary)
(1999), p. 20.
393.
Staff resolution is discussed in detail in section 3.5.4 on page 160.
Workflow Application Concepts - 107 -

Causality Perspective
The causality perspective describes under which conditions a workflow
can be executed. On the one hand, this information may provide a process
context necessary for the workflow performers’ actions. On the other hand,
a workflow system may monitor the environmental conditions and abort
running workflow instances, if the causality for their execution is no longer
given.394

Integrity and Failure Recovery Perspective

The integrity and failure recovery perspective contains elements that
relate to the correct execution of a workflow instance. These elements pro-
vide information which can be used by a workflow management system to
determine whether a workflow instance or activity instance has been com-
pleted successfully or not. If a workflow instance or activity instance fails,
predefined procedures for the maintenance of a consistent system state can
be executed.
The elements of this perspective mainly fall into two categories: Transac-
tion-related concepts and error handling concepts. Transaction-related concepts
apply elements from database transaction management to the handling of
workflow and activity instances, such as the definition of a transaction con-
text and compensation activities in case of transaction failures.395 Error han-
dling concepts relate to the management of unexpected situations during the
execution of a workflow.396 This can range from recovery procedure defini-
tion397 to organizational escalation handling mechanisms, if workflow
instances or activities exceed deadlines.398

Quality Perspective
The quality perspective is used to determine whether a workflow instance
has been executed in an efficient manner or not. This perspective reflects
our intention to establish a workflow-based process controlling. JABLONSKI
and BUSSLER restrict their discussion of this perspective to time and cost
parameters, which can be evaluated either during the execution of a work-
flow instance (workflow monitoring) or during subsequent evaluations of
completed workflow instances.399 However, they neither elaborate which

394.Nickerson illustrates this situation using the example of a long-running visa application
process, where the applicant deceases after the application process is started. Compare
Nickerson (2003).
395.
Compare for example Worah, Sheth (1996).
396.
Compare for example Casati (1998); Casati, Fugini, Mirbel (1999).
397.
Compare for example Kiepuszewski, Muhlberger, Orlowska (1998).
398.
Refer to Panagos, Rabinovich (1996).
- 108 - Workflow Application Concepts

methods should be used for the evaluation of this information; nor do they
provide guidelines, which quality attributes should be recorded during work-
flow execution.

History Perspective
The history perspective relates to the events recorded during the execu-
tion of workflow instances. These events comprise the so-called audit trail,
and provide detailed information about the actual sequence of activities exe-
cuted, the resources which performed the activities, (key) attributes for the
workflow instance, and so forth.400 The history perspective has two possible
applications. On the one hand, it can be used for system recovery purposes,
in order to establish the last known process state after a system failure.401
On the other hand, it provides source data for the analysis of the technical
and economical performance of the workflow management system.402

Security Perspective
The security perspective addresses access control aspects of a workflow
application.403 One of the biggest obstacles during the development of a
workflow application is the seamless integration of activity-based access
control regulations and application-based access control aspects. Access to
activity instances is controlled through the specification of users and roles in
the organization perspective. If this information is not aligned with the
access rights to invoked applications, users may be granted access to activi-
ties which they cannot perform, because they do not have the corresponding
access rights at the application level.404

Autonomy Perspective
The autonomy perspective covers the mobility aspect of workflow appli-
cations.405 In a mobile environment, users may be able to connect to a work-
flow management system using mobile devices, such as web-enabled cell
phones or personal digital assistants. In this case the workflow management
system may not be able to synchronize the work list of a user continu-
399.Refer to Jablonski, Bussler (1996), p. 188.
400.Compare Jablonski, Bussler (1996), pp. 120-121.
401.An example of such a recovery procedure is given by Kiepuszewski, Muhlberger, Orlowska
(1998).
402.
Refer to McLellan (1996).
403.
Compare Jablonski, Bussler (1996), p. 121.
404.
For a detailed discussion of security constraints and access control compare Bertino, Fer-
rari, Atluri (1999).
405.
Refer to Jablonski, Bussler (1996), p. 121, who use this perspective to cover mobility (of
workflow components), distribution (of activities or process parts, i. e., the execution over a
network at a remote location) and execution threads (i. e., the synchronous or asynchronous
invocation of sub-workflows or applications).
Workflow Application Concepts - 109 -

ously.406 In addition, users may have the requirement to check-out workflow

instances and activity instances, work remotely on their completion, and
check them back in at a later point in time.407

Comparison of the different frameworks

The different views found in ARIS, CIMOSA, and MOBILE are summa-
rized in table 3-2. While ARIS and CIMOSA distinguish between views and
phases, the MOBILE model only distinguishes different perspectives. The
table refers to the requirements definition phase of ARIS and CIMOSA,
unless stated otherwise.

ARIS CIMOSA MOBILE Entities

Data Information Information Data Types

Data Objects
Output Data Flow
Factual Perspectives

Function Function Function Activities

Control Behavior Control Flow

Organization Organization Organization Participants

Roles
Groups

Function Resource Operation Invoked Applications

(Implementation) Software agents

Control Causality Goals

Global Conditions

Control Function Integrity and Consistency constraints

(Implementation) (Implementation) Failure Recovery Dependencies
Systemic Perspectives

Compensation
procedures

Function Quality Time and cost

(as attributes) measurements

History Log files

Workflow protocols

Organization Organization/Resource Security Access constraints

(Implementation) (Implementation)

Autonomy Mobility
information

Table 3-2: Perspectives on Workflow Models and related Entities

406.
The same situation occurs, if users are notified by e-mail about pending work items. Only if
the workflow management system can exercise control over the mail server, expired work
items can be removed from the work list (in this case the inbox of the authorized user). A
solution for this scenario is the provision of a proxy address from workflow participants,
who select a work item. Upon activation of a work item, the participants are directed to a
server-generated web page that either provides a link to the activity implementation or
informs the user about the expiration of a work item.
407.
For a discussion of mobile workflow applications compare Jing et al. (2000).
- 110 - Workflow Application Concepts

While ARIS offers two distinct views of data objects, both CIMOSA and
MOBILE integrate these objects in the information perspective. This is con-
sistent with the criticism of the output view, as stated in section 2.2.5 on
page 53. Neither CIMOSA nor ARIS offer dedicated views for the handling
of history data as well as autonomy information. Since the history aspect is
significant for process controlling purposes, we apply the MOBILE frame-
work in the subsequent sections.

3.2.3 Workflow Applications as Coordinating Systems

From a conceptual perspective, the purpose of a workflow management
system is the coordination of all entities involved in the execution of a busi-
ness or software process. Coordination can be defined as the management
of dependencies between activities.408 MALONE and CROWSTON have classi-
fied dependencies and related coordination processes in a framework that is
shown in table 3-3.409

Dependency Description Coordination Process

Prerequisite An activity depends on the output Activity ordering

of another activity

Shared Resource Multiple activities require the Resource allocation

same resource

Simultaneity Two activities must be performed Activity synchronization

at the same time

Task/Subtask Top-level goal is dependent on the Goal decomposition

achievement of other goals

Table 3-3: Dependencies and Coordination Processes

Workflow management systems address these dependencies through their

coordination functions. Prerequisite dependencies between activities are
managed through the supervision of control and data flows. Shared
resources are managed through scheduling and staff resolution mechanisms.
Task/subtask dependencies are addressed through the hierarchical composi-
tion and decomposition of workflow models. Simultaneity constraints are
observed through event-based synchronization of processes and activities.
Through the automation of these coordination functions, workflow manage-
ment systems support several efficiency goals of the enterprise (see table 3-
4).410

408.
Compare Malone, Crowston (1994), p. 90. Refer also to Crowston (1994), who points out
that “coordination is seen as a response to problems caused by dependencies.”
409.
Compare Malone, Crowston (1990).
410.
A preliminary version of this table can found in Becker et al. (1999).
Workflow Application Concepts - 111 -

Efficiency
Goal Description Workflow Support

Optimization of process properties such as Coordination of activities through control

Process processing time (to be minimized) or adher- flow, alerts etc.
Efficiency
ence to deadlines (to be maximized)

Efficient use of the resources available for the Staff resolution and reminder in case of pro-
Resource execution of processes (human resources as cess escalation
Efficiency
well as application systems).

Proper positioning of the enterprise in its Well defined process interfaces for web ser-
relationship to market partners. This includes vices (defined external behavior), predictable
Market a reliable prediction of delivery times, trans- internal behavior through standardized pro-
Efficiency parent communication with suppliers and cesses
customers, and optimized procurement and
distribution processes.

Adequate use of the competencies of organi- Coordination of staff assignment, role con-
Delegation zational units, both superior (greater scope cepts
efficiency of vision along the process) and subordinate
(detailed knowledge about single activities).

Motivation of staff to act in a way aligned to Guidance to perform activities along a work-
Motivation the business goals of the enterprise. flow model, monitoring of progress and
Efficiency
explanation of preceding activities

Table 3-4: Efficiency Goals and Workflow Support

It is apparent that the benefits of workflow applications increase with the

number of coordination tasks that can be automated through a workflow
system. The number of coordination tasks varies with the granularity of the
components controlled through the workflow system as well as with the
type of the process controlled through the workflow system.

3.2.4 Workflow Applications as Integration Systems

Integration is regarded as one of the primary goals during information
system design.411 Literally, integration means to form, coordinate, or blend
something into a functioning or unified whole by ending existing segrega-
tion.412 Two distinct types of integration can be distinguished:413
„ Integration through connection occurs if a new system is created through
the creation of links between disparate, but logically connected enti-
ties or sub-systems. Typically this is an ex-post integration of existing
systems, such as the integration of enterprise applications through a
workflow management system.
„ Integration through combination occurs if similar system elements are com-
bined, thus leading to a decreased number of elements and relation-
ships within the system (in the sense of abstraction). Typically this
411.
Compare Rosemann (1999), p. 5; Heilmann (1989).
412.
Refer to Merriam-Webster (2002).
413.
Compare Rosemann (1998), pp. 155-165.
- 112 - Workflow Application Concepts

form of integration happens during the conceptual design phase of an

information system, for example the development of a complex appli-
cation with an integrated workflow layer for the transport of applica-
tion data.
ROSEMANN names reduction of redundancy, increased system consis-
tency and integrity, and better decision support through timely information
supply as the main goals of integration efforts.414 Integration can be charac-
terized regarding the information type, object, direction, scope, and realiza-
tion of integration. In terms of the dimensions of integration, data
integration, function integration, process integration, and object integration
can be distinguished. Integration can extend across an organization horizon-
tally (such as cross-organizational processes), or vertically (such as reporting
data flow up the organizational hierarchy).
The design of a workflow application creates integration requirements
that can be differentiated into internal and external integration requirements.
Internal integration requirements concern those systems a workflow appli-
cation needs to be connected to, in order to ensure the functionality of the
core workflow system. External integration requirements exist with regard
to systems that either invoke the workflow system from the outside (embed-
ded usage), or systems that are invoked by the workflow application.

Internal Integration Requirements

As stated above, workflow management systems coordinate activities,
workflow participants, data, and applications. Consequently, all these ele-
ments need to be integrated to ensure the functionality of the workflow sys-
tems.
„ Resource integration is required by the workflow system to keep track of
the participants available for activity assignment. Since many compa-
nies maintain resource information in organizational directories or
similar applications, a fully integrated workflow application would use
this information rather than replicate resource data in an internal data
store.
„ Data integration is required to make workflow relevant data accessible
to the workflow system. This can be achieved by connecting the sys-
tem to databases used by external application systems. If the workflow
system acts as an enterprise application integration hub, conversion of
data types and attribute values may be necessary.

414.
See Rosemann (1998), p. 156.
Workflow Application Concepts - 113 -

„ Application integration describes the ability of the workflow system to

invoke external application systems during the enactment of a pro-
cess. For organizational processes, applications are often called in
their entirety (e. g., a word processing application), while for software
processes the granularity of application invocation is at method or
function level.
In addition to these three integration requirements, the use of existing
security infrastructures is another important feature of workflow applica-
tions.
„ Security integration relates to the use of existing authentication and
authorization mechanisms through the workflow system, such as sin-
gle-sign-on and public key infrastructures.

External Integration Requirements

The external integration of a workflow system relates to the fact that a
workflow system is an application system in its own right. External applica-
tions may require calling the services of a workflow engine from the outside,
invoking workflow instances, querying the status of activity instances, or
handling resource assignments through external scheduling mechanisms. In
addition, the workflow system may be required to present work to outside
parties that are not direct users of the workflow application.
„ External invocation of the workflow engine is used, for example, in B2B
process integration. The workflow engine can exhibit its functionality
as a service to outside parties, allowing them to invoke a process and
pass initial data to the process instance.415 Examples for an external
invocation are e-mail (mail daemon triggers the workflow), the web (a
web server triggers the workflow), or other applications, which embed
the workflow system (a function within an application results in the
start of a workflow).
„ Presentation of information to outside parties is necessary, if the workflow
system has to notify external participants about the status of “their”
workflow instances, or if system load information is passed on to
external system management tools. Also, the use of audit trail infor-
mation through external applications falls into this category.

415.
This invocation model has been formalized in the Wf-XML specification by the Workflow
Management Coalition, and the ASAP (Asynchronous Service Access Protocol) specifica-
tion by OASIS, which represents a revised version of Wf-XML. See WfMC (Wf-XML)
(2001); Ricker et al. (2003).
- 114 - Technology of Workflow Applications

Figure 3-3 summarizes the internal and external integration requirements

of workflow applications.

Source: Modified from Becker, zur Muehlen, Gille (2002).

Figure 3-3: Workflow Integration Requirements

3.3 Technology of Workflow Applications

3.3.1 Technical Structure of a Workflow Management System

The structure of a workflow management systems is separated in a devel-
opment environment (build time component) and an execution environ-
ment (run time component).416 The development environment provides
workflow designers with tools for the design of workflow models, the speci-
fication of workflow relevant data structures, and the design of the organiza-
tional model relevant to the execution of the workflow models. While the
modeling of processes and organization structures are often supported
through graphical modeling tools, the specification of data structures and
integration adapters is mostly text-based and resembles a traditional pro-
gramming environment.
416.
The design discussed in this section represents a generic workflow management system and
is not based on a particular system architecture.
Technology of Workflow Applications - 115 -

A textual representation of workflow models that can be instantiated in

the run time environment is stored in a workflow model repository. In some
cases a translation of the workflow model into an executable format is
required. While some vendors rely on proprietary formats to store their pro-
cess models, the use of XML documents based on an XML schema for the
representation of workflow models is increasing.417
The organizational model, i. e., the list of users, their relationships and
associated roles, as well as organizational units, is either stored with the
workflow model in the same repository, or stored in and accessed from a
separate repository.418
The run time environment of a workflow management system (i. e., the
workflow engine) consists of a number of modules that cover different func-
tional aspects. These modules are typically connected through a coordina-
tion entity, such as an event handler, which sends event notifications to and
receives notifications from these modules.
„ The process management facility is responsible for the creation of work-
flow instances from the workflow model repository and the creation
of an appropriate entry in the workflow instance database. It has to
observe execution constraints, for instance the validity period of a
workflow model.
„ The control flow manager handles state changes of the workflow
instances and their associated activity instances.419 It evaluates control
flow conditions and creates activity instances, if the preconditions
defined in the activity models are met.
„ The worklist handler creates work items for these activity instances and
manages access rights to work items. It interacts with the work lists of
different users and handles conflicts, such as the concurrent selection
of the same work item by two users.

417.
Examples are the FlowMark Definition Language (FDL) by IBM, the Staffware format
XFR, or the XML Process Definition Language by the WfMC (compare WfMC
(XPDL)(2003).
418.An example for a separate organization modeling environment is the Organization and
Role Model (ORM) by Siemens-Nixdorf. Compare Rupietta (1997). Separate repositories
are used frequently if the organization uses a central organization directory, which is
accessed using the lightweight directory access protocol (LDAP).
419.JABLONSKI and BUSSLER define an additional module which handles the actual execution of
activities and their associated applications, the Kernel of a workflow engine. Compare
Jablonski, Bussler (1996), p. 229.
- 116 - Technology of Workflow Applications

„ The user management facility controls the access of system users to work
lists and the workflow management system in general. It uses infor-
mation from the organizational repository to determine the workflow
participants covered by a particular role.
„ The application invocation module manages the interaction of the work-
flow engine with invoked applications. It monitors return codes from
external applications to determine the successful completion of activ-
ity instances and passes data to and from invoked applications.
„ The data management component performs data conversion and data
mapping functions between activity instances.
„ The history management component logs system events in the audit trail.
These events can be either system related (e. g., user log-on and log-
off) or workflow instance related (e. g., activity started, activity com-
pleted).
„ Integration APIs provide access to the workflow engine for external
systems. This allows for the embedding of the workflow engine in
another application.420
Figure 3-4 shows the main components of a workflow management sys-
tem in a schematic diagram.

3.3.2 Stand-alone versus Embedded Workflow

Depending on the application context, workflow management systems
can either be “hidden” inside a workflow-enabled application system, or
they can operate as free-standing applications in their own right. While most
workflow solutions from the 1980s and 1990s were of the latter kind, many
workflow vendors are repositioning or redesigning their products as building
blocks for complex, process-aware application systems. Figure 3-5 illustrates
the position of a workflow service in an integration platform scenario.
A stand-alone workflow management system is functional without any
additional application software, with the exception of database management
systems and messaging middleware.421 For the deployment of an autono-
mous workflow solution, application systems that are external to the work-
flow management system are invoked at run time and workflow relevant
data is along the workflow participants. Stand-alone workflow management

420.
A popular requirement for embedded usage is the creation of a workflow instance from a
web page. In an e-commerce application, the completion of an on-line form creates a data-
base entry with the entered field values and an instance of the associated workflow model is
created through the web server, which uses the workflow engine API.
421.
Compare zur Muehlen, Allen (2000), p. 49.
Technology of Workflow Applications - 117 -

Figure 3-4: Technical Structure of a Workflow Application

systems typically provide their own user interfaces (i. e., a proprietary
worklist handler) and will access data from other applications. They are usu-
ally installed to support a variety of different applications.
An embedded workflow management system is only functional if it is
deployed with the surrounding (embedding) system - for instance, an Enter-
prise Resource Planning (ERP) system.422 The workflow functionality of
embedded workflow management systems is used by and exhibited to the
surrounding software system. Common examples include ERP and CRM
systems as well as content management applications. The workflow compo-
nents are used to control the sequence of application functions, to manage
work queues, and to assist with exception processing.

422.
For a comparison of embedded workflow management systems within ERP systems com-
pare Becker, Vogler, Österle (1998).
- 118 - Standardization Efforts in the Workflow Area

Figure 3-5: Workflow Services as Integration Technology

Embedded systems can be classified into two distinct categories. Work-
flow-based solutions are not functional without the built-in workflow func-
tionality, while workflow-enabled systems leave it to the discretion of the system
user, if the built-in workflow component is applied in a given context.423

3.4 Standardization Efforts in the Workflow Area

The increasing use of workflow management components as building
blocks for application software architectures as well as the use of workflow
systems embedded in larger application systems, such as ERP packages, ulti-
mately leads to the coexistence of several workflow management systems
within an organization. Since these workflow systems have to be integrated
into the existing information system infrastructure, the standardization of
integration interfaces promises reduced implementation times, and better re-
use of workflow components. In the field of cross-organizational workflow
management, the standardization of invocation interfaces and messaging
formats improves the development of plug-and-play solutions and reduces
the risk of using proprietary technology for the participants of a B2B pro-
cess. The following section presents an overview of standardization initia-
423.
An example for a workflow-enabled solution is the NetWeaver integration platform by
German software vendor SAP AG. Its workflow components Business Workflow, Cross-
Component BPM and Collaborative Workflow are standard components delivered with
every SAP NetWeaver installation. While Business Workflow is used for some software pro-
cesses, it is possible to use the NetWeaver package without explicit usage of the other two
workflow components. Compare SAP AG (2004). On the other hand, the Cheops system, a
customer care information system for public utility enterprises, was designed as use-case-
oriented application modules that were linked through a common workflow layer (ifs Uni-
voss, compare ifs GmbH (2001)). Without this workflow layer, the Cheops system would
not have been functional. Compare Thompson (2000).
Standardization Efforts in the Workflow Area - 119 -

tives in the field of workflow management and discusses standards that are
relevant to the development of process controlling systems.424

3.4.1 Workflow Management Coalition (WfMC)

Faced with a growing number of workflow products, each of which used
its own proprietary terminology, a group of large software users organized in
the Black Forest Group chartered a number of workflow vendors with the
task to develop interoperability standards in mid-1993. Following this chal-
lenge, an initial group of vendors and consultants founded the Workflow
Management Coalition (WfMC) in August 1993. Membership of the WfMC
is comprised of more than 250 vendors, users, consultants, and research
institutions with an interest in the field of workflow management. The mem-
bers are grouped into funding members, who may vote on the approval and
publication of standards proposals, and guest members, who may participate
in WfMC meetings, but have no voting rights. The WfMC standards are rec-
ommendations for workflow vendors, but there is no obligation for partici-
pating members to actually implement the standards. Also, there is currently
no formal conformance testing for standards adherence in place, i. e. ven-
dors who claim to support WfMC standards have not submitted their prod-
ucts to an independent conformance evaluation.

Formal Structure of the WfMC

The WfMC is organized in three committees:
„ The Technical Committee (TC) is responsible for the definition of techni-
cal WfMC standards and submits standards proposals to the Steering
Committee for approval and publication. The TC is organized in
working groups which focus on particular aspects of workflow
interoperability, such as the administration and monitoring interface,
or the XML process definition standard XPDL.425
„ The External Relations Committee (ERC) is the public relations arm of
the WfMC. It is responsible for the publication of approved WfMC
standards and the issuing of press releases about WfMC activities. The
ERC has a number of country contacts who report on regional devel-
opments of the workflow market and serve as contact persons for
membership prospects.

424.This section is intended as an overview of standards groups and their activities. For a criti-
cal discussion of standardization efforts in the area of workflow, and particularly web ser-
vices choreography, compare Nickerson, zur Muehlen (2003), and zur Muehlen et al. (2004).
425.
Both of these standards will be discussed later in this chapter.
- 120 - Standardization Efforts in the Workflow Area

„ The Steering Committee (SC) is the management organization of the

WfMC. The elected officers (chairperson, treasurer, secretary, general
manager) lead the SC and coordinate the work of ERC and TC. For
instance, they make sure that forthcoming standards are announced
by the ERC, and that the TC provides the ERC with sufficient docu-
mentation for publication purposes.
WfMC members meet three times a year, and use telephone conferences
between meetings to advance the standards development process. Each
major WfMC standard has one responsible TC working group chairperson,
who coordinates the development efforts.

Relationships to other Standardization Organizations

To date, the WfMC represents the only standardization organization
exclusively devoted to the standardization of workflow system interfaces. In
the area of workflow modeling languages, the work of other groups has an
overlap with WfMC proposals such as WPDL and XPDL. For example,
BPML by the Business Process Management Initiative (BPMI), BPEL4WS
by OASIS, WS-CDL by the World Wide Web Consortium (W3C) and the
Workflow Facility of the Object Management Group (OMG) pursue goals
similar to XPDL. The contributions of these groups will be discussed later
in this section.
The WfMC has working relationships with the Object Management
Group and its members have contributed to OMG standards such as the
Workflow Facility.426 It also maintains a working relationship with BPMI
and OASIS, and in several instances individual members contribute to both
organizations.

3.4.2 WfMC Standards

WfMC Glossary
Due to the increasing number of workflow vendors by the middle of the
1990s, vendor-specific terminology for workflow constructs led to an incon-
sistent vocabulary of workflow terms.427 In order to counter this trend, the
first goal of the WfMC was to establish a common terminology for work-
flow concepts, which led to the publication of the WfMC Terminology &
Glossary.428 Today, the WfMC glossary covers most workflow concepts and
gives definitions for terms such as activity, workflow management system, or partic-

426.
Compare section 3.4.4 page 128.
427.
Compare Joosten (1996).
428.
Compare WfMC (Glossary) (1999).
Standardization Efforts in the Workflow Area - 121 -

ipant. Although not all workflow vendors use standard terminology, the
WfMC vocabulary has found widespread acceptance in practice. It is per-
ceived as a valuable aid for the system selection process, since proprietary
terms used by different vendors can be transformed to a common basis,
thus enabling a comparison of systems on the basis of a single vocabulary.

WfMC Reference Model

The WfMC reference model was introduced in 1995 as a means to group
workflow-relevant interfaces according to their purpose and constitutes one
of the most influential workflow frameworks to date.429 The model consists
of five interfaces, which are depicted in figure 3-6. While the reference
model provides a framework that illustrates the role of the different inter-
faces, each interface is specified through an abstract specification that
describes the generic functionality of the individual interface. Depending on
the functionality of the interface, one or more interface bindings are pro-
vided as illustrations how an interface can be implemented using particular
languages or technologies.
All five interfaces are grouped around the execution core of the workflow
management system, the workflow enactment service, which encapsulates one or
more workflow engines. A system may consist of several workflow engines,
e. g., if it is implemented in a distributed manner. The communication
between the workflow enactment service and outside systems is provided
through an application programming interface (API), the workflow API
(WAPI). The WAPI is defined by the WfMC Interface 2 and 3 definition430,
with additional information provided by the other interface definitions. The
following sections present the individual interfaces in detail.

WfMC Interface 1
The WfMC Interface 1 provides a generic process description format, the
Workflow Process Definition Language (WPDL).431 The purpose of WPDL
is the exchange of workflow specifications between different workflow sys-
tems, or business process modelling tools and workflow management sys-
tems. For this purpose, WPDL provides a common subset of elements
found in most workflow management systems. WPDL is specified using an
extended Backus-Naur Form (EBNF)432 and a plain text description, but is
independent of a particular system implementation. Due to sometimes con-

429.
Compare WfMC (Glossary) (1999).
430.
Compare WfMC (WAPI) (1998).
431.
Compare WfMC (WPDL) (1999).
432.
Compare ISO (1996).
- 122 - Standardization Efforts in the Workflow Area

Compare WfMC (Glossary) (1999)

Figure 3-6: Workflow Management Coalition Reference Model
flicting modeling concepts used by different workflow vendors, the unifica-
tion process for WPDL turned out to be difficult. Examples for opposite
ends of the modeling spectrum are Petri Net-based tools such as LEU433
(which was based on Funsoft nets, a high-level Petri-Net type) and COSA on
the one side434, and speech-act based tools such as Action Workflow on the
other side.435
While a number of tool vendors have implemented WPDL (some in a
prototype stage), interface 1 is widely perceived to be without practical rele-
vance.436 In 2002 an XML representation of WPDL called XPDL was pub-
lished, which has been implemented in a number of open-source workflow
projects.437 To date, the re-use of workflow models is rarely found in prac-
tice. This may be attributed to the fact that the actual modeling of workflow

433.The workflow management system LEU originated from the research prototype MEL-
MAC at the University of Dortmund, compare Deiters, Gruhn (1990); Gruhn, Deiters
(1994). With a strong background in software process management, the system is a prime
example of research prototypes that were transformed into commercial products. Commer-
cially the system was a failure and its development ended in 1997, but the modeling envi-
ronment is still marketed by adesso (www.adesso.de) under the name LEUsmart.
434.
See, e. g., Dinkhoff et al. (1994); Gruhn, Kampmann (1996). For a comprehensive overview
of Petri Net-based workflow modeling approaches refer to Salimifard, Wright (2001) and
van der Aalst (1998).
435.
See, e. g., Medina Mora et al. (1992); de Michelis, Grasso (1994). For an introduction to
speech-act-based workflow modeling refer to Winograd, Flores (1986).
436.
Refer to McCoy (2000).
Standardization Efforts in the Workflow Area - 123 -

processes is the least time consuming step in a workflow project, compared

to the time needed for technical integration. Thus, the economic benefit
provided by a generic workflow model representation is limited. Neverthe-
less, on an educational level the WfMC Interface 1 specification provides a
good overview about the common elements of a workflow model and their
relationships.

WfMC Interface 2 & 3

The WfMC Interfaces 2 and 3 form the WAPI specification core. Interface
2 specifies the communication between a workflow engine and client appli-
cations that are used by workflow participants to interact with the workflow
management system. This concerns mainly the presentation of the work list,
the selection of work-items, and the notification for overdue items. Interface 3
specifies the API functions for the integration of invoked applications. This
relates mainly to the passing of data between the workflow engine and a
remote application, and handling application return codes.
While Interface 2 has a “pull” character, i. e., a workflow participant
actively selects a work-item for further processing, thus “pulling” the work
from the workflow engine, Interface 3 implements a “push” model, i. e., an
application is invoked by the workflow engine and returns control after it
has finished processing. The close relationship between the two interfaces
ultimately led to a merged specification, which defines a standard set of API
functions a workflow engine should support, the so-called Workflow Appli-
cation Programming Interface (WAPI).438 This abstract specification defines
on one side the operations a workflow management system performs on an
outside system, on the other side the operations that external systems can
invoke on a workflow engine. These operations include the instantiation,
starting, manipulation, and stopping of workflow instances. The current
specification contains - besides the abstract description - a reference imple-
mentation in C. It is in a stable state and has been implemented by a number
of vendors.439 Still, most workflow users rely on vendor specific API imple-
mentations, since these offer more functionality and are often offered as Java
classes or component objects (COM, CORBA-IDL), which offer a better fit
for the surrounding system architecture.

437.Compare WfMC (XPDL) (2002). An Open Source workflow engines that includes XPDL
support is Enhydra Shark (http://shark.objectweb.org); an Open Source graphical work-
flow editor that exports XPDL is JaWE (http://jawe.enhydra.org).
438.
Compare WfMC (WAPI) (1998).
439.
For example Concentus KI Shell, IBM FlowMark/MQSeries Workflow, Hitachi Work
Coordinator, SAP Business Workflow. Note that these conformance statements come
directly from the vendors and have not been validated by an independent certification
authority (http://www.wfmc.org).
- 124 - Standardization Efforts in the Workflow Area

WfMC Interface 4 and Wf-XML

The WfMC Interface 4 specifies the communication across different
workflow engines in the sense of a process-to-process interaction. The first
version of this interface was published in 1996,440 the current version 2.0
has been published in 1999.441 The specification of Interface 4 consists of
an abstract description of interoperability functions (e. g., instantiating a
workflow, starting, stopping, aborting a workflow instance, etc.), as well as
different bindings to messaging protocols and transport mechanisms. The
first published binding relied on MIME, which enabled workflow manage-
ment systems to interoperate through the exchange of e-mail messages.442
Operational implementations of this binding were presented in the course of
an interoperability challenge by three workflow vendors (DST, FileNet, and
Staffware) in March 1999. Despite the availability of a stable specification,
most workflow vendors are reluctant to implement the Interface 4 standard.
This reluctance can be explained by the following observations:
„ There is no pressure from the workflow user community to imple-
ment interoperability features yet. Many enterprises are still experi-
menting with workflow implementations, rather than employing
operative system.443 Only the increasing use of embedded workflow
systems, permeating the system infrastructure of enterprises, will cre-
ate the necessity to couple different workflow management systems
within one enterprise along a common process model.
„ E-Mail as a transport medium is not the optimal choice for workflow
interoperability, since quality-of-service standards as well as the
acknowledgement of messages are difficult to realize across different
e-mail platforms.

440.
Compare WfMC (IF4 1.0) (1996).
441.
Compare WfMC (IF4 2.0) (1999).
442.
Compare WfMC (MIME) (2000).
443.
Compare for example the survey by Chroust, Bergsmann (1995). Out of 8000 question-
naires, 227 responded to the survey, and 70 of those responding were using workflow. In a
similar study, KUENG stated that on January 1st, 1998, in Switzerland about 1% of small
enterprises (2-99 employees) used workflow technology, 6% of medium-sized enterprises
(100-499 employees) and 12% of large enterprises (500 or more employees). Compare
Kueng (1998); Kueng (2000). In Kueng (1997) the author points out that the interest in
workflow technology is a lot bigger than the number of actual projects.
The author of this book conducted a survey among German public utility companies in the
spring of 1998. Out of 128 questionnaires, 80 were returned. Out of these 80 companies,
14% had no plans to use workflow in the foreseeable future, 12% were conducting pilot
projects, 8% were using productive systems, 4% stated, their system implementation had
failed, 26% were planning to begin a project within 12 months, while 36% were planning a
project within the next 36 months. For further results of this study, refer to zur Muehlen
(EVU) (2002), pp. 520-526.
Standardization Efforts in the Workflow Area - 125 -

In the context of the Wf-XML standardization (described below), a new

binding for Interface 4 messages was presented. Within Wf-XML, the
interoperability messages are encoded using XML, and exchanged using the
web-specific Hypertext Transfer Protocol (HTTP). This version of Interface
4 will serve as the basis for further interoperability standards, while existing
Interface 4/MIME standards are mostly theoretical concepts without
matching implementations.
The WfMC provides standards which define only the basic operations for
a cross-enterprise or cross-system workflow implementation. For the defini-
tion of context data (i. e., business data that is exchanged during a B2B pro-
cess) as well as other relevant parameters (e. g., legal frameworks, quality of
service parameters, security mechanisms, etc.), the specification of so-called
interoperability contracts is recommended.444 Due to this fact, the WfMC
Interface 4 specification is mostly free of overlaps with existing or future
B2B standards. For example, the interoperability contract for a Wf-XML
implementation could be specified using IBM’s Trading Partner Agreement
Markup Language (tpaML)445, while context data may be described using
domain-specific formats.

WfMC Interface 5
Interface 5 describes the format of the run time protocol produced by a
workflow enactment service, the so-called audit trail.446 The current version
2.0 describes the data format of log entries as well as the state changes
responsible for creating these log entries. Figure 3-7 shows the data structure
of an audit trail entry that describes the creation of a process instance. The
data structure consists of a header, which is identical for every event type
recorded, and a body, which is different for each event type.
This data structure can be enhanced by workflow vendors to accommo-
date proprietary attributes. Interface 5, despite having received considerably
less attention than the other four WfMC interfaces, could be of interest for
users of different workflow engines, since the standardized audit trail format
makes it easier to integrate the output of different workflow management
systems into a consistent process controlling database. We present such an
approach in chapter 4.
On the one hand, timestamps and other attributes recorded in the audit
trail could help improve the quality of cost accounting methods such as

444.
Compare WfMC (IF4) (1999).
445.
Compare the tpaML specification at http://www-106.ibm.com/developerworks/library/
tpaml.html [Download 2002-06-02]
446.
Compare WfMC (IF 5) (1999).
- 126 - Standardization Efforts in the Workflow Area

Source: WfMC (IF 5) (1999); zur Muehlen (2000), p. 556.

Figure 3-7: WfMC Interface 5 Data Structure
activity-based costing.447 On the other hand, the provision of recorded
workflow information in front-end applications, such as Customer Relation-
ship Management systems (CRM) or call-center-applications can improve
the tracking of customer behavior and customer histories. Furthermore, the
use of data mining approaches on audit trail information may help discover
potential weaknesses of the underlying workflow models, which could be
corrected through reorganization measures.448
The most significant specifications of the WfMC so far, are the glossary,
the reference model, and different versions of Interface 4. Especially the Wf-
XML version of Interface 4 shows some promising aspects, even though
competing standards like BPML449, BPEL4WS450 (a merger of WSFL451

447.
For a discussion of the integration of workflow audit trail data into an activity-based costing
system compare Weiß, Zerbe (1995); Weiß (1998); Weiß (1999).
448.The reconstruction of workflow models from audit trail information has been proposed by
Agrawal, Gunopulos, Leymann (1998) and submitted for a patent by Agrawal, Leymann,
Roller (1998).
449.
Compare Arkin (2002).
450.
Compare Curbera et al. (2002).
Standardization Efforts in the Workflow Area - 127 -

and XLANG452), and WS-CDL453 are covering aspects of Wf-XML func-

tionality, and are based on XML and the HTTP protocol as well.454 From
the perspective of data warehouse and controlling users, a stronger emphasis
on Interface 5 would be desirable. How this demand will be addressed is still
unclear, since the WfMC - like many other standardization groups - is a vol-
unteer organization and only has a limited set of resources to work with. As
the only true workflow-oriented standardization organization, the work of
the WfMC will continue to impact the design of workflow management
products in the future. Even if proposed standards are not implemented by
its members, the standardization process in itself helps to increase the aware-
ness of workflow vendors and users about the requirements workflow infra-
structures have to satisfy in practice.

3.4.3 Object Management Group (OMG)

In addition to the WfMC, the Object Management Group partially
addresses the workflow domain. The OMG was founded in 1989 as a group
of software vendors, consultants and software users that were using (or were
interested in) object-oriented technology. It is organized in three commit-
tees:
„ The Platform Technology Committee (PTC) specifies basic technical
standards, for example services for the distribution of objects or
details of programming language specifications.
„ The Domain Technology Committee (DTC) is dedicated to standards
relating to specific business domains. It is organized in several work-
ing groups with domain-specific focus, for instance CORBAmed for
the area of health care.
„ The Architecture Board, similar to the Steering Committee of the
WfMC, controls the OMG activities and coordinates the consistency
and technical integrity of DTC and PTC work.
The OMG standardization process starts with the design of a request for
information (RFI) by a task force. After approval from the respective techni-
cal committee, the RFI is issued and responses are fielded by the task force,
to determine the interest and state-of-the-art of a particular technical field. If
the task force receives a satisfactory feedback, a request for proposals (RFP)
is drafted by the task force and is passed to the architectural board for
451.
Compare Leymann (2001).
452.
Compare Thatte (2001).
453.
Compare W3C (2004).
454.
For an extensive discussion of the design philosophies behind Wf-XML and the other stan-
dards mentioned above compare zur Muehlen et al. (2004).
- 128 - Standardization Efforts in the Workflow Area

approval. Such a request relates to ongoing standardization efforts and is

used to solicit standards proposals from companies interested in the particu-
lar field. If the architecture board approves the RFP, it is issued by the tech-
nical committee responsible for the task force and proposals are collected.
After an evaluation and voting phase, which can include several rounds of
supplements and improvements, one of the proposals is recommended to
the architecture board and to the board of directors of the OMG. After the
proposal is formally accepted by the architecture board and approved by the
board of directors, a finalization task force is instantiated, which deals with
suggestions and objections from OMG members. After the revision phase,
the standard is issued as an official OMG specification. Those companies
submitting a proposal have implicitly signaled their agreement to implement
the adopted standard within a 12 month time frame.
The core of OMG standards work is the Object Management Architec-
ture (OMA), which describes an architectural framework for the design of
object-oriented application systems. This framework is built around a central
distribution layer, the object request broker, which is designed according to
the common object request broker architecture (CORBA). This broker pro-
vides a communication bus that provides services for the integration of dis-
tributed, object-oriented application components. The components using
the broker infrastructure need not be aware of the location or technical spec-
ification of other components they communicate with. The interfaces for
the communication between the broker and the components are specified
using an interface definition language (IDL). Through the use of IDL, legacy
systems can be wrapped as CORBA-objects and integrated into a CORBA-
based environment. Some workflow management systems rely on CORBA
as a mechanism to realize the distributed implementation of their compo-
nents.455

3.4.4 OMG Workflow Facility

The OMG has standardized a Workflow Facility as a part of high-level
CORBA services (the so-called CORBA facilities).456 Through an imple-
mentation of this facility, an object request broker advances from being an
integration platform for workflow management systems to being a work-
flow-enabler and connection hub for application components. Figure 3-8

455.For example the WASA system described by Weske (CORBA) (1999).

456.Compare Object Management Group (2000); The original request for proposals was writ-
ten by Schulze, Schmidt, Zenie (1997); Schulze, Bussler, Meyer-Wegener (1998) provide a
discussion of expectations from the side of the OMG and a short evaluation of the initial
submissions. Some authors refer to the workflow management facility using the term joint-
Flow. This name was the original proposal of the submitting WfMC consortium, which was
finally adopted.
Standardization Efforts in the Workflow Area - 129 -

shows the positioning of the workflow facility among other CORBA ser-
vices. Services of the workflow facility can rely on services of the business
object facility. Business objects are application components that directly rep-
resent domain specific business logic.457 They are typically designed to fos-
ter a re-use within different component-based application systems. The
coordination of business objects using the workflow management facility
enables application designers to create workflow-enabled business applica-
tions, without the need to implement or integrate a dedicated workflow
engine.

Source: Compare Schulze, Bussler, Meyer-Wegener (1998), p. 24.

Figure 3-8: Positioning of the Workflow Facility

Structure of the OMG Workflow Facility

The workflow management facility consists of an object model, which
describes the interfaces of a workflow-enabled CORBA-object. Using this
object model, workflow-enabled applications can be distributed on the basis
of an object request broker and communicate using standardized interfaces.
The OMG workflow facility does not provide a blueprint for the internal
architecture of a workflow management system. Instead, it provides an
object interface for workflow applications, so client applications can create
workflow instances, and manipulate these instances using well-defined inter-
face methods. This must not be confused with the internal organization of a
workflow management system - many commercial workflow management

457.
Refer to Schulze (2000), pp. 81-97.
- 130 - Standardization Efforts in the Workflow Area

systems have been developed using object-oriented programming languages

and concepts (such as Smalltalk, C++, Java), even if they do not appear as
distributed systems to an observer.458 The use of the workflow facility can
serve as a wrapper for existing applications, in order to integrate these into
the workflow infrastructure of an enterprise, if the organization uses
CORBA as a middleware standard. From a functional perspective, the work-
flow facility represents a mixture of the WfMC WAPI and the function calls
of the WfMC interface 4. Historically, the OMG Workflow Facility provided
some core ideas for the later development of Wf-XML and ASAP.
The object model of the OMG workflow facility is shown in figure 3-9 as
a UML class diagram.The core object of the workflow facility is the WfPro-
cessManager object, which represents a specific workflow model (or any
other service that is capable of creating a workflow instances of this model).
The fundamental notion of the standard is the direct communication
between a requester and a workflow instance, as compared to the traditional
conversation between a requester and a central workflow engine managing
said workflow instance. Through the create_process() method, the
WfProcessManager creates a new instance of the workflow model it
manages, a WfProcess object. This object contains one or many objects of
the type WfActivity, which represent the executable steps of the process.
Both WfProcess and WfActivity inherit the interfaces from WfExe-
cutionObject, i. e., it is possible to query both the state of an activity and
the state of a workflow through the get_current_state() method.

Process Controlling Aspects of the Workflow Facility

For process controlling purposes, the workflow facility provides inter-
faces to access both the execution history of a process as well as changes in
the process context, such as changes of attribute values or resource assign-
ments.459 The list_history() method provides access to the objects of
the type WfEventAudit that are associated with a workflow or a particular
activity. These WfEventAudit objects contain information on the source
of the event and event-specific data. This information is made persistent,
independent of the life-cycle of the related workflow instance or its activi-
ties. However, access to this audit data store still requires the original associ-
ated object. For this reason, an export of audit information to a persistent
storage medium is necessary to preserve this information for later evalua-

458.Forexample, a part of the IBM FlowMark system was implemented in Smalltalk, while the
Carnot process engine is implemented in Java. Compare Leymann, Altenhuber (1994); Car-
not AG (2002).
459.
Compare Object Management Group (Workflow) (2000), pp. 2-38 - 2-47.
Standardization Efforts in the Workflow Area - 131 -

Source: Object Management Group (Workflow) (2000), p. 2-3.

Figure 3-9: Workflow Facility Object Model
tions, before obsolete workflow objects are purged from a system (e. g., for
performance reasons).

Future of the OMG Workflow Facility

The original request for proposals regarding the workflow management
facility was issued in the summer of 1997 and led to the submission of three
proposals (Nortel, EDS, and a consortium of WfMC members). After a
analysis and revision phase of more than a year, the jointFlow proposal by
the WfMC consortium was accepted in August 1998 and a revision task
force worked on the proposal until late 1999.460 The finalization of the spec-
ification implied that at least one of the submitting companies should have
implemented the OMG workflow management facility by now. However,
this is not the case, for the following reasons:
„ Certain operational aspects are not specified in detail, which are nec-
essary for the execution of workflow implemented using the object
model. One example for this is the relationship between WfActivi-
ties and WfResources, which is unspecified at the moment. In

460.
The final standard has been revised to version 1.2 in 2000, compare Object Management
Group (2000).
- 132 - Standardization Efforts in the Workflow Area

order to overcome this limitation, the OMG has issued a RFP for a
resource assignment interface, which received three submissions.461
„ Domain-specific working groups of the OMG show an increasing
interest in workflow. For example, the publications of the product
data management enablers working group as well as documents from
the CORBAmed domain task force contain concepts that are related
to workflow (e. g., resource management). However, a coordinated
effort is missing that could integrate these disparate approaches into a
homogeneous framework. As long as such a framework is missing,
vendors are better off using proprietary, but functional technologies,
instead of waiting for a unified standard.
„ Within the OMG opinions differ on what constitutes a workflow and
how it should be modeled. Traditionally a large share of the OMG
membership favors UML, which is used for the technical specification
of object-oriented systems. One critical issue with the current UML
diagramming types is the lack of expressions for the relationship
between activities and resources. As a result, the organizational
responsibilities for workflow processes cannot be expressed suffi-
ciently. There have been isolated attempts at the enhancement of
UML diagram types for workflow modeling, but a consolidated effort
to enhance the UML meta model for workflow purposes has not
taken place.462
„ There is no apparent customer demand to realize workflow interoper-
ability on the basis of the OMG model. While distributed and inter-
organizational workflow management systems have been addressed
by the research community since the mid-1990s,463 the corporate
practice still relies on pragmatic (and mostly proprietary) solutions.
Only the increasing use of Internet standards for business transac-
tions will ultimately lead to the development of interoperability
requirements among workflow users (e. g., through the use of B2B
domain standards such as RosettaNet). As a result of this develop-
ment, vendors of integration platforms have begun to integrate work-
flow components into their products and/or acquired workflow
vendors to enhance their product offerings.464
461.Compare IBM (2000).
462.Compare Hruby (1998); Wiegert (1998); Bastos, Bubugras, Ruiz (2002).
463.Compare Schuster (1997), who discusses architectural aspects of distributed workflow
management systems. Riempp (1998) presents concepts for wide-area workflow implemen-
tations using a groupware platform. The Exotica/FMQM project of IBM was aimed at the
distribution of the IBM FlowMark product. Results of the prototype found their way into
the IBM MQSeries Workflow system. Compare Alonso et al. (1995); Alonso, Reinwald,
Mohan (1997).
Standardization Efforts in the Workflow Area - 133 -

3.4.5 Workflow Management and Web Services Choreography

The standardization of lower level protocols that cover the encoding,
routing, and transport of data over the TCP/IP protocol (e. g., XML, SOAP,
HTTP, and WSDL) has given rise to a fast growing area of application inte-
gration under the label web services. In the widest sense, web services deal
with the standardized linking of applications through the exchange of XML
messages over the HTTP protocol. The increasing commercial interest in
web services has led to a shift in the activities of standardization organiza-
tions. While during the 1990s intra-company processes were at the center of
attention, these standards are currently being enhanced or replaced by speci-
fications of inter-organizational message exchange and related protocols.465
The resulting standards are partially competing and partially overlapping. Of
particular interest are standards that address the interaction between (poten-
tially long-running) processes, also known as Web Services Choreography.
Web Services Choreography aims at the coordination of long-running inter-
actions between distributed parties, which use web services to expose their
externally accessible operations. The coordination of long-running interac-
tions is necessary in almost any cross-organizational interaction, in areas
ranging from electronic publishing to supply chain management.
Figure 3-10 shows the current areas of activity in standardization groups
focused on inter-organizational process management. Two parties wishing
to engage in inter-organizational process integration have internal opera-
tions in form of private processes (A, B, and E), which are not exposed to
outside trading partners. As a façade, public processes (C and D) are created,
and their activities (C1 through C3 and D1 through D3) serve as contact
points for the other party. In order to automate this interaction, the two par-
ties need to agree on a number of standards. First of all, they need to specify
the semantics of the public process operations, and whether these opera-
tions receive or send data to the other party. Furthermore, the structure and
content of the messages that are to be exchanged need to be defined, for
example using an industry-specific format. In addition, the sequence of mes-
sages needs to be defined, including ways to detect messages that are lost or
out of sync. Finally, the partners need to agree on access, addressing and
authentication mechanisms that allow one party to send a message through
the network gateway of the opposite party. A taxonomy of standards related
to process modeling and web services is shown in figure 3-11.466

464.
Compare Bussler (2002).
465.
For an overview of the growing number of XML-related standardization organizations
compare Kotok (2002a) and Kotok (2002b).
- 134 - Standardization Efforts in the Workflow Area

Source: zur Muehlen, Nickerson, Swenson (2004).

Figure 3-10: Standardization Areas in Business Process Integration
Process modeling languages like XPDL and BPEL aim at the definition
of enterprise-specific business processes.467 The companies implementing
these processes exercise control over most of the resources involved in the
execution of these processes, such as workflow participants or application
systems. The technical implementation of these processes is based on pro-
cess-aware information systems such as contemporary ERP packages or
workflow management systems. The interfaces between these systems, the
internal processes of a company, and outside transaction partners are speci-
fied in form of web services, whose sequence of invocation is governed by
public processes.

466.
For a related taxonomy compare Aissi, Malu, Srinivasan (2002), p. 55. The overview in
figure 3-11 was created in collaborative meetings with members of the Workflow Manage-
ment Coalition and the Business Process Management Initiative, most notably Mike Gilger
and David Hollingsworth.
467.
Another example for process modeling languages in the workflow domain is the Business
Process Modeling Language, defined by BPMI.org (http://www.bpmi.org).
Standardization Efforts in the Workflow Area - 135 -

Figure 3-11: Taxonomy of Web Services Choreography Related Standards

WSDL is an XML format for the standardized specification of web ser-
vices in the form of access ports and related access protocols (bindings).468
The basic building block of WSDL is a message, which consists of typed ele-
ments such as documents and/or context data. Messages form operations,
which consist either of single messages or a request/response message pair.
The resulting four interaction patterns are presented in figure 3-12. Unidi-
rectional messages are either used by a requester to request an action from a
provider, or by a provider to notify a requester. Bidirectional messages either
form a request/response pair, where a requester asks a provider to perform an
action and the provider answers the request, or they form a solicit/response
pair, where the provider asks the requester for information, which is sup-
plied subsequently.
Multiple operations can be grouped to form a port type. A port type rep-
resents an abstract collection of semantically coherent operations (e. g., all
operations related to goods receipt processes). Only in conjunction with a
binding, the explicit implementation of a port type is determined. A binding
468.
Compare Christensen et al. (2001).
- 136 - Standardization Efforts in the Workflow Area

Figure 3-12: Interaction Types

specifies the data format of messages as well as the transport protocol for
the message exchange. A port is a specific implementation of a port type
using a specific binding. In principle the same port type can be implemented
multiple times. This may be desirable to support the same functionality using
different access mechanisms (web versus e-mail), or to provide scalability
through redundant ports. The top-level element of WPDL is a service, which
consists of one or more ports. Figure 3-13 shows the WPDL meta model as
an entity-relationship diagram.
Web services can be published in directories, which rely on a standardized
description format, such as Universal Description, Discovery and Integra-
tion (UDDI).469 XML-based formats such as the Trading Partner Markup
Language (tpaML) provide mechanisms to describe the non-technical
aspects of an inter-organizational process, and within the eb-XML standard
the specifications Collaboration Partner Protocol/Agreement (CPP and
CPA) cover these aspects as well. The content of the messages, which are
exchanged between business partners, can be defined using format stan-
dards, which are either generic, such as Biztalk or ebXML, or domain-spe-
cific, such as RosettaNet, SWIFT, or HL7.

469.
Compare Ariba, IBM, Microsoft (2000).
Standardization Efforts in the Workflow Area - 137 -

Figure 3-13: WSDL Meta Model

Figure 3-11 also includes the protocol stack for web service applications.
The foundation of the protocol stack are the three standards HTTP, SOAP
and WSDL. While HTTP serves as the transport protocol, messages, which
are exchanged between web services, are encoded in a SOAP envelope, and
sent between ports that are defined using WSDL. Using these three stan-
dards, it is possible to create web service applications that send point-to-
point messages. In order to enable more complex interactions (e. g., to
define the sequence of messages within a business context), an additional
protocol layer is required, the web services choreography layer. WSDL only
describes the functionality of web services, but not their behavior in the con-
text of a long running business process. This behavior is represented using
modeling languages for inter-organizational processes, such as the public
- 138 - Standardization Efforts in the Workflow Area

processes of BPEL4WS or the Choreography Definition Language of the

W3C (WS-CDL).
The structure of processes modeled in either private or public process
specifications can be driven by the use of reference models, or reference pat-
terns. For workflow management systems, VAN DER AALST ET AL. have
defined 23 design patterns that cover the most common control flow sce-
narios.470 For UML activity diagrams, another process modeling method,
some general design patterns can be applied. In the public process space,
domain-specific standards provide interaction patterns such as the Rosetta-
Net Partner Interface Processes.471
In the following section we characterize Wf-XML as one of the standards
proposed for the cross-organizational integration of business processes,
since it allows for the remote observation of processes - a feature that is of
interest for process monitoring and controlling applications.

3.4.6 Resource-oriented Process Choreography: Wf-XML and ASAP

Wf-XML provides a mixture between a process model and a service
description in form of a process-oriented interaction protocol. It serves as a
standard format for the interaction with stateful, complex services, such as
workflows. The Wf-XML protocol was published by the WfMC and is influ-
enced by the WfMC Interface 4, the OMG Workflow Facility, and the Sim-
ple Workflow Access Protocol.472 A generic version of Wf-XML for the
coordination of long-running services has been proposed in form of the
Asynchronous Service Access Protocol (ASAP).473

History of Wf-XML and ASAP

In early 1997 a number of WfMC members felt that a lightweight alterna-
tive to the existing Interoperability specification (WfMC Interface 4) was
needed and began developing an alternative protocol, which was called the
Simple Workflow Access Protocol (SWAP).474 The basic idea behind SWAP
was the use of standard Internet protocols for workflow interoperability. A
workflow model would be identified by a Uniform Resource Identifier
(URI) and could be manipulated using a number of commands based on
HTTP extensions (LISTINSTANCES, CREATEPROCESSINSTANCE etc.).
An initial draft was completed early 1998, and the authors submitted it to the

470.
Compare van der Aalst et al. (2003).
471.
Compare RosettaNet (2002).
472.
Compare Hayes et al. (2000); WfMC (Wf-XML) (2001).
473.
Compare Ricker et al. (2003).
474.
Compare Swenson (1998).
Standardization Efforts in the Workflow Area - 139 -

Internet Engineering Task Force (IETF), which was the desired standards
body for this endeavor. By the end of 1998, after two birds-of-a-feather
meetings475, it became clear that the IETF was not going to adopt the
SWAP specification, and members of the SWAP working group returned to
the WfMC, where the ideas of the SWAP proposal were enhanced with the
experiences of the OMG Workflow Facility submitters. In addition, the pro-
prietary extensions of the HTTP protocol were removed and replaced with
standard HTTP POST commands.476 The result was the Wf-XML specifica-
tion, which was published in 2000 and revised in 2001.477 In 2003 the desire
grew to extend the protocol beyond the workflow arena and apply it to long
running transactions in general. Due to the different intention, a working
group was founded within the OASIS standards body to work on an
extended specification titled Asynchronous Service Access Protocol
(ASAP). This effort is synchronized with work on a revision of the Wf-XML
protocol.

Wf-XML Structure
The core for Wf-XML is a set of messages that describes the interaction
between the provider of a process-oriented service, and a requester of this ser-
vice. From a conceptual perspective, the hierarchical decomposition of a
process can be perceived as a sequence of requester-provider message
exchanges. The actions of the provider are hidden from the requester in the
sense that the requester does not need to know details about the service pro-
visioning process. Figure 3-14 illustrates this concept using a top-level pro-
cess (P1) with a three-step sub-process (A1, A2, A3). Sub-process A3 is
implemented through two additional activities B1 and B2.
The interaction between requester and provider is realized through a set
of messages that are exchanged. During the first step of the interaction a
requester sends a CreateProcessInstance command to a process
manager (which represents the workflow model). The process manager cre-
ates a process instance and passes the address of this process instance back
to an observer, who will interact with the process instance. Requester and
observer can, but need not be the same entity. Subsequently the observer
communicates with the process instance (performer), but no longer with the
process manager. The observer can manipulate the state of the process
instance through the ChangeProcessInstanceState command, i. e.,

475.Compare Khare (1998).

476.Compare Swenson (2000).
477.Compare WfMC (Wf-XML) (2001). Interestingly the original effort was started outside of
the WfMC, because the consortium members were dissatisfied with the length of time it
took to specify and publish standards within the WfMC.
- 140 - Standardization Efforts in the Workflow Area

Source: Compare Swenson, zur Muehlen (2001).

Figure 3-14: Nested Workflow Interaction
he can start, suspend, resume, and abort the process instance through this
command. The process instance will notify the observer of state changes
(such as the completion of the process instance). Through the GetPro-
cessInstanceData command the observer can request elements from
an agreed-upon data structure (e. g., the shipping date of an order). Figure 3-
15 shows the basic interaction pattern between requester and provider.
The overall interaction between requester and provider is oriented along
the web architecture principles that have been documented by Fielding as
Representational State Transfer (REST).478 A monitoring agent could regis-
ter itself to a process instance as an observer and record events about the
execution of this process instance. The application of monitoring principles
to processes that are executed at different locations has been documented in
the AFRICA project.479 This project implemented a distributed help desk
478.
Compare Fielding (2000).
Development of Workflow Applications - 141 -

Figure 3-15: Wf-XML Message Types

process using three different process management systems. Monitoring
information about the current state of the process was collected and visual-
ized through a central process observer, using Wf-XML concepts.
The monitoring and controlling of business processes can deliver espe-
cially useful information, if the underlying structure of the business pro-
cesses is available for reference. Several standard modeling languages for
business processes in the workflow context have been indicated in figure 3-
11. We will discuss the properties of these languages in section 3.5.3.

3.5 Development of Workflow Applications

In the previous section we have discussed major standardization efforts in
the field of workflow management. In this section we focus on the actual
development of workflow applications, i.e., the design and deployment of
process-aware information systems that are based in whole or in part on
workflow technology.

3.5.1 Procedure Models for Workflow Application Development

The development of a workflow application is similar to the development
of a traditional application system, since workflow management systems are
a specific category of application systems.480 As a result, procedure models

479.
Compare zur Muehlen, Klein (2000).
480.
Compare Böhm (2000), p. 18.
- 142 - Development of Workflow Applications

for software development can be applied to the development of workflow

applications, such as the waterfall model481, the spiral model482, or the
Rational Unified Process.483 These procedure models can be classified
according to the main objective during the development phases.484 While
functional approaches focus on the development of algorithmic solutions,
data-oriented approaches stress the separation of data management and appli-
cation logic. Rule-based application development separates a rule-base from
an inference engine that processes these rules. Process-oriented development
approaches separate the application logic from the control flow, which
makes them suitable for the development of workflow applications.
KWAN and BALASUBRAMANIAN have presented a high-level development
process for workflow applications.485 After a requirements analysis phase
(study phase), the requirements definition documents are specified, and sepa-
rate development phases for process logic and activity logic start.486 The
design and development phase is performed in two concurrent threads, one
for the specification of the behavioral perspective, and one for the specifica-
tion of the functional and operational perspectives. Next, the results are inte-
grated, tested, and documented. Changes during the execution and
evaluation phase lead back to the development and specification tasks,
respectively.
ORTNER has proposed a generic multi-path procedure model for the
development of application systems, which he illustrates using examples
from the workflow management domain.487 His generic approach is based
on the separation of method-neutral and method-specific design phases.
WESKE ET AL. have analyzed different approaches for the design of work-
flow applications and identified a number of problems during the develop-
ment process that they try to overcome with the specification of a reference
procedure model.488 Their reference model for workflow application design
process is shown in figure 3-16. It is similar to the conventional waterfall
model, using feedback loops between the different development stages.

481.
Compare Royce (1970).
482.
Compare Boehm (1988).
483.
Compare Kruchten (2001).
484.
Compare Ortner (1998), pp. 329-331.
485.
Refer to Kwan, Balasubramanian (1998).
486.
The authors name this phase analysis phase, despite the specification activities. Compare
Kwan, Balasubramanian (1998), p. 315.
487.
Compare Ortner (1998).
488.
Compare Weske et al. (2001).
Development of Workflow Applications - 143 -

Source: Compare Weske et al. (1999), p. 4.

Figure 3-16: Reference Model for the Workflow Application Design Process
The following sections describe the main tasks of the workflow applica-
tion design phase, namely the specification of process models and organiza-
tion models, as well as the planning of application integration.489

3.5.2 Process Modeling

Identification of workflow-fit Processes

Prior to any process specification, the processes which should be auto-
mated have to be selected. The identification of processes with high work-
flow potential, i. e., those processes that can be supported by workflow
applications profitably, is an essential step in a workflow application devel-
opment project. The selected processes and their system environments are
core determinants of the technical and business-related requirements work-
flow systems have to satisfy.490 If a workflow management system is already
in place491, capabilities of the workflow enactment service have a direct
impact on the process selection. A structured framework for the selection of
489.
For a detailed discussion of the other phases, refer to Weske et al. (1999).
490.
Compare Bartholomew (1995).
- 144 - Development of Workflow Applications

workflow-fit business processes has been developed by BECKER ET AL.492

This model has been field tested in a workflow project in a public utility
enterprise. The framework separates fundamental workflow suitability, orga-
nizational constraints, and the economic benefits of process automation.
Workflow suitability takes into account factors such as process structure,
separation of tasks, and the number of organizational interfaces. Organiza-
tional constraints can impact the success of a workflow project, such as the
commitment of process participants to a workflow project. The economic
benefits of process automation are measured using the efficiency goals dis-
cussed in section 2.1.2 on page 30. Alternative taxonomies have been pre-
sented by KUENG493, who focuses on the external attributes of a process,
and KOBIELUS, who names six key criteria for the diagnosis of workflow
suitable processes: Speed, cost, accuracy, quality, customer satisfaction and
quality.494

Specification of Workflow Models

A variety of process modeling languages are available for the specification
of workflow models. These languages differ with regard to the focal model-
ing construct of the process model. Activity-centered languages allow the
modeling of processes as a network of tasks or activities that are ordered
using producer/consumer relationships, or transitions. Languages focusing
on the process object describe a process as the legal sequence of state
changes of the process object. An example of this approach to process mod-
eling are document publishing processes, where a document changes
between states such as draft, revised, accepted and rejected. Languages focusing
on the resources participating in the process may represent a process as a
network of processing stations that interact with each other.495
A different classification has been proposed by CARLSEN, who distin-
guishes five groups of process modeling languages:496

491.
For example, if a workflow-enabled application system is already being used by the organi-
zation.
492.
Compare Becker et al. (1999); A modified version of the framework was published in zur
Muehlen, v. Uthmann (2000) and Becker et al. (2000).
493.Compare Kueng (1995).
494.Refer to Kobielus (1997), pp. 20-21.
495.BARBARÁ, MEHROTRA and RUSINKIEWICZ describe a system, where an intelligent process
object migrates through a network of “black box” processing stations. If the processing sta-
tion is capable of performing the task required by the process object, it enacts this task.
Otherwise the process object migrates to another processing node. This modeling paradigm
is a mixture of the process-object-oriented and the process-participant-oriented modeling
methods. Compare Barbará, Mehrotra, Rusinkiewicz (1996).
496.
Compare Carlsen (1997).
Development of Workflow Applications - 145 -

„ Input-Process-Output-based languages, such as the activity networks used in

IBM MQSeries Workflow.497 These languages describe a workflow as
a directed graph of activities, denoting the sequence of their execu-
tion.
„ Speech-Act-based approaches (sometimes called Language Action
approaches) as used in Action Technologies’ Action Workflow prod-
uct.498 These approaches model a workflow as an interaction between
(at least) two participants that follow a structured cycle of conversa-
tion. Namely the phases negotiation, acceptance, performance and
review are distinguished.
„ Constraint-based modeling methods, such as Generalized Process Structure
Grammar (GPSG).499 These approaches describe a process as a set of
constraints, leaving room for flexibility that is otherwise governed by
the restrictions of the IPO- or Speech-Act-based approaches.
„ Role-modeling based process descriptions, such as Role Activity Diagrams
(RADs).
„ Systems thinking and system dynamics are concepts that are used in con-
junction with the concept of learning organizations.500
Process Definition Languages
Process definition languages for the specification of workflow models can
be separated into languages with a graphical representation and languages
with a textual representation. Graphical modeling languages are typically
found in business process modeling tools. They can be used for the specifi-
cation of the overall process structure and the decomposition of sub-pro-
cesses and activities. Aspects covered by these languages are the functional
and behavioral perspective of a workflow application. Nevertheless, graphi-
cal modeling languages often lack expressiveness for the specification of
other perspectives.501 WESKE and VOSSEN distinguish between graph-based
and net-based languages as well as workflow programming languages. While
graph-based and net-based languages may be either textual or graphical,
workflow programming languages are typically text-based. An overview of
graphical and text-based process definition languages is given in table 3-5.502
Generalized Process Structure Grammars

497.
Compare Leymann, Altenhuber (1994).
498.
Compare Medina-Mora et al. (1992).
499.
Compare Glance et al. (1996).
500.
Compare Senge (1990).
501.
Compare Böhm (2000), pp. 32ff.
- 146 - Development of Workflow Applications

Textual Representation Graphical Representation

„ Workflow Process Definition Language „ Activity Nets

(WPDL, XPDL) „ Business Process Modeling Notation
„ Business Process Modeling Language (BPMN)
Graph-based (BPML) „ Control Flow Graph
Languages
„ Business Process Execution Language „ Event-driven Process Chains
for Web Services (BPEL4WS)
„ EPC Markup Language (EPML)

„ Petri Net Markup Language „ Funsoft Nets

Net-based (PNML) „ Flow Nets
Languages
„ Yet Another Workflow Language (YAWL) „ Workflow Nets

Workflow „ Mobile „ State and Activity Charts

Programming „ FlowMark Definition Language (FDL)
Languages „ Transaction Datalog

Table 3-5: Process Definition Languages

The approach of Generalized Process Structure Grammars (GPSG) was

developed by members of the Rank Xerox Research Center in Grenoble in
the mid-1990s. GPSG is intended to enable the modeling of processes with-
out prescribing an exact execution path of activities.503 It was inspired by the
idea of Generalized Phrase Structure Grammar, which is a formal model of
the syntax of natural language.504 The fundamental objects of a GPSG are
rules, feature objects, and feature constraints.505 Activity-centered rules are
used to describe the goals of activities, and how these goals can be decom-
posed into sub-goals, including the conditions that describe dependencies
between activities. Document-centered rules describe the decomposition of
documents into sub-documents. Constraints for document-centered rules
describe the relationships among sub-documents, e. g., the fact that a sum-
mary in a management document precedes the body of the document.
Activities and documents are described in terms of name-value pairs (fea-
tures), i. e. attributes and their values, and therefore represent feature struc-
tures. Feature constraints describe interdependencies between objects.
The description of a process in GPSG is based on constraints that govern
the sequence of activities within the process. Through the specification of
502.
The references for the languages mentioned in the table are as follows: Activity Nets and
FDL, refer to Leymann, Altenhuber (1994). BPML, refer to BPMI.org (2002). BPMN, refer
to White (2002). Control Flow Graph, refer to Alonso et al. (1996). Event-driven Process
Chains, refer to Keller, Nüttgens, Scheer (1992); EPML, refer to Mendling, Nüttgens
(2004); Flow Nets, refer to Ellis, Keddara and Rozenberg (1995). Funsoft Nets, refer to
Gruhn, Deiters (1995). Mobile, refer to Jablonski, Bussler (1996). State and Activity Charts
refer to Harel (1988). Transaction Datalog, refer to Bonner (1999). PNML, refer to Jüngel,
Kindler, Weber (2000). Workflow Nets, refer to van der Aalst (1998). WPDL, refer to
WfMC (WPDL) (1999); XPDL, refer to WfMC (XPDL) (2002); YAWL, refer to van der
Aalst, ter Hofstede (2003).
503.
Compare Glance, Pagani, Pareschi (1996). Dourish et al. (1995) have implemented GPSG
in their Contraflow and FreeFlow prototypes.
504.
Compare Gazdar et al. (1985).
505.
Compare Glance, Pagani, Pareschi (1996), p. 181.
Development of Workflow Applications - 147 -

grammatical rules that define the constraints a process has to satisfy, a multi-
dimensional space of possible process execution paths is opened. GPSG-
based process models can be extended or altered by adding additional or
removing constraints from the process specification, much like a rule-based
expert system. GLANCE ET AL. illustrate this point:
“[...] Using a generative grammatical approach, a given process instance can be
incrementally singled out from the space of possible workflows defined by the rules as
the process evolves.”506
A comparison of traditional workflow management concepts, based on a
process definition language, and a GPSG-driven workflow system is given in
table 3-6.507

PDL Approach GPSG Approach

PDL grammar GPSG grammar

„ Parser of user-defined process models „ Generator of user-defined processes
Workflow „ Interpreter of process models „ Constraint solver
Engine
„ Lexicon: activities, dependencies among „ Compiler of processes
activities

„ Legal phrase defined by the user respect- „ User-defined process grammar

Workflow ing the PDL grammar „ Lexicon: activities, documents, dependen-
Model
cies defined as feature constraints

Workflow „ Instantiation of workflow model „ Legal phrase generated by the user from
instance the process grammar

Flexibility in „ Conditional statements in workflow „ New legal phrase in the process grammar
workflow model „ New phrase in the modified process
instance „ Change of the workflow model grammar

Table 3-6: Comparison of PDL-driven and GPSG-driven Workflows

While a PDL-driven workflow management system relies on a hard-

coded process definition language, GPSG allows the user to specify his own
language, including the objects that are part of the process (indicated as lexi-
con in the table).
GPSG as an alternative modeling approach does not address implementa-
tion issues necessary for the design of a workflow management system
based on a GPSG process model. Nevertheless, the unique capabilities of
GPSG, such as the extensibility of process instances as well as the virtually
unlimited number of control flows possible justify the analysis of this lan-
guage. Furthermore, the analysis of process instances based on a GPSG
specification is different from the PDL-style languages.

506.
Glance, Pagani, Pareschi (1996), p. 181.
507.
Modified from Glance, Pagani, Pareschi (1996), p. 183.
- 148 - Development of Workflow Applications

Because there is no predefined control flow for the entire process within
GPSG, a process controlling system would have to reconstruct process
models from audit trail entries without the help of a “traditional” process
model.508

3.5.3 Standards for Workflow Modeling Languages

Nearly every commercial workflow tool relies a proprietary modeling lan-
guage for the construction of workflow models, each of which offering a
different number of modeling elements to the process designer. Depending
on the technical implementation of the underlying workflow engine, the
same process semantics may be expressed using different modeling con-
structs. The purpose of standard process modeling languages is the provi-
sion of generic modeling languages that facilitate the exchange of process
and workflow models across applications.
Most standardization initiatives focus on the textual representation of
workflow models, but do not specify, how the elements of these languages
can be rendered graphically. Only recently, the Business Process Modeling
Notation was presented as an attempt to provide a unified graphical process
rendition that can be applied to different underlying modeling languages.509
An overview of current standardization efforts for process modeling lan-
guages in the context of workflow management is given in table 3-7, and
both table 3-8 and table 3-9.

Name WPDL/XPDL BPML PSL PIF

WfMC BPMI.org NIST MIT

Origin
Standardization Standardization Standardization Research

Specification EBNF, Text, XML XML Schema KIFa KIF

Notation No Yes, BPMN No No

Objective Model Exchange Modeling Modeling Model Exchange

Tool Support Product Prototype Prototype Prototype

Usage Workflows Business Processes Business Processes Business Processes

WfMC (WPDL) BPMI.org (2002) Knutilla et al. (1998) Lee et al. (1998)
Source (1998); WfMC Note: Merged with Note: Merged with
(XPDL) (2002) PIF PSL

Table 3-7: Standards for Process Modeling Languages (Part 1)

a. For an explanation of the Knowledge Interchange Format (KIF) refer to Genesereth (1998).

508.This relates to the process mining approaches mentioned earlier, compare Agrawal,
Gunopulos, Leymann (1998), van der Aalst et al. (2003), and www.processmining.org for an
overview of research projects on mining process models from workflow logs.
509.
Compare White (2002).
Development of Workflow Applications - 149 -

Name GSPG UML WSFL XLANG

Xerox OMG IBM Microsoft

Origin
Research Standardization Vendor Vendor

Specification Text MOF, UML, Text XML Schema XML Schema

Notation No Activity Diagrams No XLANG Schema

Objective Modeling Modeling Modeling Modeling

Tool Support Research Prototype Product see BPEL4WS see BPEL4WS

Area Workflows Workflows Web Services Web Services

Glance, Pagani, OMG (2001); DSTC, Leymann (2001) Thatte (2001)

Pareschi (1996); PrismTech (2001);
Source
Dourish et al. (1996) Kabira, Oracle, Web- Note: Merged with Note: Merged with
Gain (2002) XLANG to BPEL4WS WSFL to BPEL4WS

Table 3-8: Standards for Process Modeling Languages (Part 2)

Name BPEL4WS WSCI WSCL BPSS

BEA, IBM, Microsoft, SUN, BEA, Intalio HP Labs ebXML (OASIS)

Origin
SAP, Siebel (OASIS) W3C Note Research Standardization

Specification XML Schema XML Schema XML Schema XML Schema

Notation BPMN (planned) No No No

Objective Modeling Modeling Modeling Modeling

Tool Support Product None None Product

Area Web Services Web Services Web Services Web Services

Source IBM (2002) W3C (2002a) W3C (2002b) ebXML (2002)

Table 3-9: Standards for Process Modeling Languages (Part 3)

WPDL and XPDL

The Workflow Process Definition Language (WPDL) is an exchange for-
mat for workflow models, and has been published as part of the WfMC
Interface 1.510 XPDL is an XML schema representation of WPDL. Work-
flow models can be transferred between modeling tools and workflow man-
agement systems, if these can convert their internal models to the WPDL or
XPDL format.
A workflow process definition in WPDL consists of one or more work-
flow process activities that are linked through transitions. These transitions
reflect the control flow of the process. There are no constructs to explicitly
model the data flow aspect of a process. Activities within WPDL can be
atomic or complex, i.e., complex activities reference sub-processes. Since

510.
Compare WfMC (WPDL) (1999). For the XML rendition XPDL refer to WfMC (XPDL)
(2002).
- 150 - Development of Workflow Applications

Source: Extended from WfMC (IF1) (1999).

Figure 3-17: WPDL Process Meta Model
WPDL is based on the notion of an acyclic graph, a loop is represented as an
explicit loop activity. This is a sub-process that is repeated until a certain exit
condition is met. Figure 3-17 shows the meta model of the WPDL process
entities as an entity-relationship diagram.
Atomic activities in WPDL are assigned to workflow participants that are
either entities of a minimum meta model or entities of an external organiza-
tion schema that is accessed through a reference to an external repository
(e. g., and LDAP schema). The implementation of this external reference is
Development of Workflow Applications - 151 -

Source: Compare WfMC (WPDL-O) (1998).

Figure 3-18: WPDL Organizational Meta Model
specified in detail. The minimum meta model distinguishes between organi-
zational units, humans, roles and (technical) resources. Figure 3-18 shows
the meta model of the WPDL organizational entities.
Workflow models specified in WPDL can be saved as a text files (or XML
documents in the case of XPDL), which facilitates the transfer between
modeling tools. In addition to the exchange of models, elements of the
WPDL meta model can be created using a subset of the WAPI speficication.
These function calls create entities representing meta model elements within
a workflow enactment service that supports the relevant API subset. These
API commands are listed in the appendix of the Interface 2 & 3 standard,
e. g., WMAddTransition.511
In practice, WPDL and XPDL have found little support in the commer-
cial world, where only few systems use the interchange format for model
interoperability. However, emerging Open Source workflow systems such as
Enhydra Shark represent their models in XPDL. A process editor called
JaWE (Java Workflow Editor) that exports XPDL is available under an
Open Source license as well.

511.
Compare WfMC (WAPI) (1998).
- 152 - Development of Workflow Applications

BPML
The Business Process Management Initiative (BPMI.org) is a industry
consortium of approximately 200 companies in the workflow, business pro-
cess modeling, and systems integration space. It has the mission of develop-
ing an XML-based business process modeling language, a matching
notation, and a repository for models specified in this language. The initia-
tive was founded in August 2000 under the auspices of Intalio, which pro-
duces a BPMI-standards-compliant business process management system
and controls much of the regular BPMI operations. The standards defined
by BPMI are the Business Process Modeling Language (BPML), a matching Busi-
ness Process Modeling Notation (BPMN), as well as a query language for systems
operation at run time, the Business Process Query Language (BPQL).
BPML was designed as a modeling language for transactional, discrete
business processes.512 Besides entities such as elementary and complex
activities, connectors, and events, the BPML meta model offers a number of
entities for the management of data at run time (e. g., definition of an activity
context, which may contain shared data). In addition, elements for exception
handling, such as message, time-out, and failure event handlers are provided.
Constructs for the modeling of transactional process segments are available
as well. Using such a language construct, a modeler can mandate the idem-
potent behavior of a process part. I. e., a number of activities are executed
and committed in their entirety, or they are rolled back to the state before
the activity execution began (this relates to the ACID513 criteria of database
management).514 Compensation activities can be specified to handle possi-
ble transaction failures.515 The state model of BPML activities and processes
is comparable to the WPDL state model and differentiates between the
states ready, active, completing, completed, aborting and aborted.516

512.Compare BPMI.org (2002).

513.ACID relates to the desirable properties of a transactional information system: Atomicity
(i. e., a transaction is either executed in its entirety or not at all), Consistency (i. e., before
and after a transaction is executed the system is in a consistent state), Isolation (i. e., differ-
ent transactions do not influence another’s behavior) and Durability (i. e., after a transaction
is completed its results are made persistent). Compare Date (1995), p. 379.
514.
Leymann and Roller point out the importance of transactional behavior in workflows:
“A workflow management system coordinates the execution of the various activities consti-
tuting a single business process. As a result, activity executions of a given workflow share a
common fate: they represent a unit of work. The corresponding activities are no longer
independent of each other. The failure of one activity might impact other activities. Some
activities may have a very strong influence on the overall success of the business process;
other activities may have not influence at all.” Leymann, Roller (2000), p. 232.
515.
For a discussion of compensation spheres in workflow management systems compare Ley-
mann (1996), p. 342 and pp. 346-347.
516.
See Arkin (2002).
Development of Workflow Applications - 153 -

Parallel to the development of BPML a working group was established to

develop a matching process notation. Two different levels of abstraction of
this Business Process Modeling Notation (BPMN) are defined. On the one
hand, an execution level notation will represent the BPML semantics completely.
On the other hand, a business level notation shall serve as a “lean” notation for
organizational modeling purposes, and not contain every detail necessary for
the automation of the modeled processes. While the execution level notation
contains elements such as fault, compensation, transaction, and context, the
business level notation is designed with the intention of a comprehensible
graphical diagram, which allows the grouping of elements through swim-
lanes or participant lanes, respectively. A first version of the BPMN specifi-
cation was published in 2004.517

WSCI
The Web Services Choreography Interface (WSCI) is the official submis-
sion of the BPMI.org consortium to the Web Services Choreography Work-
ing Group of the World Wide Web Consortium (W3C)518, the official
standards body of the World Wide Web.519 While BPML and its associated
standards are published by BPMI.org as an industry initiative, standards that
are officially sanctioned by the W3C have the character of a vendor-neutral
standards recommendation. The W3C is working on the standardization of
World Wide Web related technologies and protocols, and most standards
that relate to Web Services are developed by W3C working groups. WSCI
has the status of a W3C note, i. e., it is an input document for the W3C
working group that develops a Web Services Choreography Definition Lan-
guage (WS-CDL).520

WSCL
The Web Services Conversation Language (WSCL) was submitted to the
W3C by members of the Hewlett Packard research laboratories in February
2002 and was accepted as a W3C note.521 It represents the results of HP
Labs research on the composition of e-services522, but has not been modi-
fied or pursued since its initial submission. Similar to WSCI, WSCL is used
as an input document by the WS-CDL working group.
517.
Compare White (2004).
518.
Compare W3C (2002a).
519.
Compare http://www.w3c.org/2002/ws. While the Internet Engineering Task Force
(IETF) is responsible for defining technology standards such as the Internet protocols
SMTP and TCP/IP, the W3C focuses on higher level protocols such as HTTP and Web
Services related standards.
520.
Compare W3C (2004).
521.
Compare W3C (2002b).
522.
Compare Kuno et al. (2001).
- 154 - Development of Workflow Applications

WSFL
The Web Services Flow Language (WSFL) was presented by LEYMANN in
May 2001 as an extension of WSDL to coordinate the interaction of long
running web services.523 It has since been superseded by BPEL4WS, but to
give readers a comprehensive overview of process modeling languages, we
are providing a characterization of the language. WSFL can be used to spec-
ify the processes within web services, as well as interactions between users
and providers of web services.524
WSFL consists of two components: Usage patterns specify the flows within
a web service (i. e., processes with an interface to outside partners), while a
global model describes the interaction of process partners using web services.
The meta model of WSFL is very similar to the meta model if the IBM
MQSeries Workflow product525, only the terminology has been adjusted to
match the web service domain. A WSFL flow is a directed graph, consisting
of activities, which are connected through control links. Splits and joins in the
control flow can be realized through the use of fork and join activities. For
every activity an exit condition can be specified in order to refine the control
flow. Through this exit condition the correct execution of an activity can be
monitored. If the exit condition is not satisfied, the activity has to be
repeated. In addition, join activities can be outfitted with a starting condition
called join condition. The data flow in the process model is represented
through data links between activities. A flow in its entirety can be supplied
with data through an input link, and can produce data for outside systems
through an output link.
The implementation of an activity is realized through a service provider. The
relationship between activities and service providers is realized in the WSFL
model through a reference to a service provider type, which in itself is a col-
lection of WSDL port types. At run time an activity performs a specific
operation on the service provider’s port that is associated with the activity.
The selection of a specific service provider from a pool of similar service
providers is based on a locator that states how a service provider is selected
at run time (e. g., through a static assignment or through market mecha-
nisms). Relationships between service providers in the global model are rep-
resented using plug links between the operations of participating service
523.Refer to Leymann (2001).
524.A web service is a well-defined interface to some business functionality, which can be
accessed over a network using XML messages. Typically these messages are transported via
http, the same protocol used for web pages. Compare Cerami (2002).
525.
For a description of the MQSeries Workflow product compare Leymann, Altenhuber
(1994); Leymann, Roller (1997); Leymann, Roller (2000). A comparison of the IBM Flow-
Mark meta model (the predecessor of MQSeries Workflow) with other tools can be found
in zur Muehlen (1999).
Development of Workflow Applications - 155 -

Figure 3-19: Schematic WSFL Flow

providers. Figure 3-19 shows the concept of a WSFL process on the local
and global level.
The recursive design of the WSFL specification allows for a re-use of
flows as web services in higher-level flows, thus leading to a hierarchical
composition of complex web service systems. In the example above, the
upper flow consists of three activities (A1, A2, A3), which are implemented
through operations. Mirrored operations are implemented as contact points
for external service providers or their port types, respectively. For example,
activity A1 may invoke a trigger operation. A notification interface is imple-
mented between activity A1 and external systems for this purpose. Activity
A2, on the other hand, receives a message from a notification operation.
Accordingly, the interface is realized as a trigger operation. Activity A3 has
been realized as an internal operation and does not have an external inter-
face. The above example can be specified in WSFL in its entirety. Through
the addition of public operations it could be published as a single web ser-
vice provider.
The specification of web services through WSDL and related processes
through WSFL does not contain context information such as legal contracts,
price agreements etc. The WSFL specification suggests the use of the Web
- 156 - Development of Workflow Applications

Services Endpoint Language (WSEL) for the formal specification of related

trading partner agreements.

XLANG
XLANG is a modeling language for business-to-business and enterprise
application integration processes which are modeled in the Microsoft Biz-
Talk server.526 XLANG has been merged with WSFL in August 2002 and is
superseded by BPEL4WS. Similar to WSFL, XLANG is presented here to
provide readers with background information on the predecessors of
BPEL4WS. XLANG processes are specified using a flowchart notation,
which is subsequently translated into a the XML format XLANG schedule.
Figure 3-20 shows a credit application process modeled using the XLANG
flowchart notation. XLANG schedules can be interpreted by a version of
the Microsoft BizTalk server that works as an integration hub and a work-
flow engine. Similar to WSFL, XLANG is designed as an extension to
WSDL in order to extend the static description of web service interfaces
with dynamic behavior. The process modeling constructs of XLANG are
thus similar to those of WSFL.
The top-level entity of XLANG is a schedule, which consists of one or
more tasks. Schedules can be linked through message queueing mechanisms,
but are independent otherwise. Besides typical model elements such as activ-
ities, splits, concurrent activities, and joins, XLANG offers dedicated sup-
port for transaction handling. Several activities can be grouped to a
transaction that is either executed in its entirety or not at all. For each transac-
tion, compensation activities can be specified. These are designed to undo
side effects that result from a partial execution of the transaction’s activi-
ties.527
The example process in figure 3-20 shows the process structure on the
left side, while the implementation of tasks is indicated through messaging
channels on the right side. The tasks “Request Credit Report” and “Receive
Credit Report” have been grouped to form a transaction. An XLANG-
schedule contains the specification of process data, which can be sent or
received via messaging channels. Data mappings between different message
formats enable the conversion of messages along a process. For example, an

526.Compare Lebovich, Woodgate (2002); Thatte (2001).

527.An example for a compensation activity is the sending of a correction message. Since mes-
sages sent to outside business partners can in most cases not be revoked, the respective
party has to be informed about a failure in the process. This example also illustrates that
failure handling and compensation activities in inter-organizational processes typically
require additional effort and need to be negotiated between the business partners. Compare
Stohr, Stohr (2001) for a discussion of possible transaction problems.
Development of Workflow Applications - 157 -

Figure 3-20: XLANG Schedule

incoming EDIFACT528 message can be converted into an application-spe-
cific message format through field-level data mapping.

BPEL4WS
In light of the overlap between WSFL and XLANG, IBM and Microsoft
decided to consolidate their efforts in the area of Web Services Choreogra-
phy.529 Together with Siebel, SAP, and BEA they founded an industry con-
sortium for the standardization of the Web Services Business Process
Execution Language, and a first version of the specification was published in
the fall of 2002. The standardization process was handed over to the stan-
dardization group OASIS (which also hosts the ASAP working group) in
mid-2003.530 BPEL4WS has generated a lot of interest and is being imple-
mented by software vendors such as SeeBeyond and SAP. It is widely per-

528.Electronic Data Interchange for Administration, Commerce and Transport (UN/EDI-

FACT) is (besides X12) the most popular pre-XML data format for business-to-business
messages, which has been standardized by the International Organization for Standardiza-
tion (ISO) in 1988. Compare ISO (1988).
529.Compare Leymann, Roller (2004).
530.Attempts by the W3C to receive BPEL as an input document a la WSCI and WSCL failed -
amidst other reasons - due to the IP policies of W3C, which require submitters to transfer
their intellectual property rights in submissions to the W3C.
- 158 - Development of Workflow Applications

ceived as the de facto standard for Web Services Choreography and a

number of complementary research projects have emerged.531 Since the
constructs of BPEL4WS are similar to those of WSFL and BPML, which
have been discussed above, the interested reader is referred to the
BPEL4WS specification, which can be downloaded from the OASIS website
free of charge.532

Summary
The different process modeling languages discussed above are juxtaposed
in table 3-10 using the workflow aspects discussed in section 3.2.2.
BPEL4WS exhibits the most comprehensive coverage of the workflow
aspects, with the exception of the autonomy perspective, and limitations in
the organization perspective. The WPDL/XPDL specification addresses all
aspects with the exception of the autonomy and the integrity and failure
recovery perspective. However, not all aspects are mandatory for a workflow
model specified using WPDL/XPDL. For example, the quality attributes
like time and cost are optional attributes, which need not be implemented by
all vendors supporting WPDL/XPDL. The more recent standards
BPEL4WS, BPML, WSFL and XLANG provide explicit support for failure
handling and transaction support, an aspect that is missing from WPDL
models. Also, the data handling and mapping capabilities of BPEL4WS,
BPML, WSFL, and XLANG are targeted at the integration of heteroge-
neous data sources. While WPDL/XPDL maintains the distinction between
application data533 and workflow-relevant data534, the other standards posi-
tion data integration as a core aspect of their process models.
It is important to note that BPEL4WS, BPML, XLANG and WSFL do
not provide constructs for the modeling of process participants or organiza-
tional responsibilities. This restricts the use of these modeling languages to
fully automated process scenarios, where every activity is either realized
through a software function, or where the service implementing the activity
has user-handling capabilities of its own. BPEL4WS specifies business part-
ners and partner links for the addressing of external service providers, but
the maintenance of organizational structures is not part of BPEL4WS,
BPML, WSFL, or XLANG. This indicates the intention of the creators to

531.
Compare, e. g., Mendling et al. (2004).
532.
See http://www.oasis-open.org/.
533.
Application data is defined as “Data that is application specific and not accessible by the
workflow management system.” WfMC (Glossary) (1999), p. 54.
534.
Workflow relevant data is a subset of application data, made available to the workflow
engine on a read-only basis, which is used to determine state transitions of activities and
transition conditions, for example, a variable that is evaluated to determine the control flow.
Compare WfMC (Glossary) (1999), p. 55.
Development of Workflow Applications - 159 -

WPDL/XPDL BPML WSFL XLANG BPEL

Workflow Process Process, composed Flow, composed of Schedule, com- Business process,
Function

Definition, com- of atomic and com- activities posed of tasks composed of activi-
posed of Workflow plex activities ties
Process Activities
and sub-processes

Activities invoke Atomic activities Implemented Implemented Activities invoke

application systems implement actions, through service pro- through service pro- Web Services,
e. g., message viders. Activities viders. Activities implement control
Operation

exchange interact with service interact with service flow constructs,

providers through providers through update data con-
their operation messaging inter- tainers, or manipu-
interfaces. Plug faces. late the state of
links connect activi- activities or pro-
ties and basic oper- cesses.
ations.

Transitions between Implicitly realized Control links Modeling elements Implicitly realized
activities through different between activities through different
Transition condi- activity types: Transition condi- activity types:
tions be used to „ all tions be used to „ sequence
restrict the control „ choice restrict the control „ switch
flow „ delay flow „ while
Behavior

Loop activities can „ foreach Activities have start „ pick

be used for itera- and exit conditions
„ join „ flow
tions to further restrict
Route activities can
„ sequence the control flow
Extensible by
be used to split and „ switch encapsulating exe-
„ until cution context
join the control flow
„ while
Extensible by
encapsulating exe-
cution context

Context data is Selectors can Explicit data flow No explicit data Data scopes define
restricted to work- extract data from Data links connect flow the execution con-
flow relevant data, messages and map activities’ in- and Context data con- text for activities.
Information

which describes it to properties, output containers tains data objects Messages can be
information rele- which form the pro- Data conversion for all in- and out- defined, and their
vant to the process cess context through data map- going messages content can be
(e. g., variables for pings on the data Data mapping extracted to be used
control flow condi- connectors between objects as workflow rele-
tions). No provision provides transfor- vant data.
for application spe- mation mechanism
cific data.

Activities are exe- Not specified Not specified Not specified Not specified for
cuted by performers internal task assign-
Included minimum ment. External
Organization

meta model for the assignment is pro-

local specification vided through the
of an organiza- definition of part-
tional model ner links and busi-
Link to external ness partners.
organizational
model for complex
applications

Table 3-10: Analysis of different Workflow Modeling Languages

- 160 - Development of Workflow Applications

WPDL/XPDL BPML WSFL XLANG BPEL

Not specified Transactions con- Not specified Transaction con- Transaction context
texts and compen- texts and compen- and compensation
Failure Recovery

sation activities can sation activities can handlers can be

Integrity and

be specified. be specified specified. Exception

Exception handling handling can be
can be specified specified through
through “fault” “fault” activities
activities and event and event handlers
handlers for mes- for messages, time-
sages, time-outs, outs, and faults.
and faults

Optional process Not specified Not specified in Not specified Deadline and dura-
and activity WSFL, should be tions are explicitly
attributes: defined in WSEL mentioned and can
„ responsible raise alarms.
Quality

„ duration
„ cost
„ working_time
„ waiting_time
„ priority

Not specified Not specified Not specified Not specified Not specified
Autonomy

Table 3-10: Analysis of different Workflow Modeling Languages

position these languages in the systems integration space rather than the
organizational process space. While this limited view on workflow models
results in a reduced complexity for software vendors implementing
BPEL4WS-based systems (e. g., they need not worry about access control
mechanisms to work items or the representation of heterogeneous organiza-
tional structures), the audit trail information that could be provided by such
systems does not distinguish between technical resources used for the imple-
mentation of an activity, and the resource that carried the organizational
responsibility for the activity (e. g., the human performer). In the next sec-
tion we discuss the representation of organizational structures in workflow
models in more detail.535

3.5.4 Organization Modeling

A resource is an entity that is assigned to a workflow activity and is
requested at run time to perform work in order to complete the objective of
the activity.536 A resource model contains the definition of human and technical
resources that may be used in the execution of a workflow model as work-

535.
The section is intended as an overview of organizational modeling in workflow applica-
tions. For a more thorough discussion refer to zur Muehlen (2004).
536.For a discussion of different resource modeling approaches compare zur Muehlen (1999).
A reference architecture for the organization model within workflow applications was
designed by BUSSLER. Refer to Bussler, Jablonski (1995); Bussler (1996); Bussler (1998).
Development of Workflow Applications - 161 -

flow participants.537 The division between a process model on one side, and
a resource model on the other side fosters the separate evolution of both
models. This has a good reason: The life cycle of human resources within an
enterprise typically varies from the life cycle of the enterprise processes. A
separation between the two enables workflow designers to create workflow
models that are independent of changes in the organizational structure of
the enterprise, adding to their robustness. In addition, a separate resource
model may be shared by several workflow engines used within one enter-
prise, reducing administrative overhead and preventing possible redundan-
cies, thereby increasing overall data quality.
Within the reference model of the WfMC, the management of resource
information lies within the responsibility of the workflow engine.538 This
reflects the fact that many workflow vendors have implemented proprietary
resource management facilities for their workflow management systems.
These are either part of the process modeling environment539 or constitute a
separate application.540 This type of implementation can lead to problems in
larger organizations, where several workflow management systems may be
involved in the execution of a complex process. These systems cannot share
common resource information, which leads to data redundancy. In addition,
information such as the workload of individual resources can only be deter-
mined, if data from the separate resource management components is con-
solidated. This data may not be easily accessible - a case where the efficient
use of enterprise resources can only be realized locally.
Resource models should satisfy a number of core requirements in order
to be applicable to different workflow scenarios. These requirements, which
can be derived from general quality criteria for software systems, are robust-
ness, flexibility, scalability and domain independence.541

537.We use the term resource model in order not to focus solely on workflow in administrative
environments. Workflow management systems may also be used in industrial applications,
interfacing with production planning and control (PPC) systems, computerized numerical
control (CNC) machines and software agents among others, which have to be defined for
use in the workflow management system through the resource model.
538.
Refer to WfMC (Glossary) (1999). The WfMC reference model is presented in section 3.4.2
on page 120.
539.
Examples for this type of implementation are IBM MQSeries Workflow and the Carnot
Process Engine.
540.An example for a separate organizational modeling environment is the Organization and
Resource Manager (ORM) by Siemens-Nixdorf, which was a component of the (discontin-
ued) workflow management system WorkParty. The designers of the ORM were influential
during the design of the organizational meta model for WPDL (see section 3.4.2 on
page 120). For a thorough discussion of the ORM entities refer to Rupietta (1992); Rupietta
(1994) and Rupietta (1997).
541.
Compare for example the criteria given by Dunn (1991)
- 162 - Development of Workflow Applications

„ Robustness: Changes to the resource model should not affect the work-
flow model. Moreover, changes to the workflow model such as the
addition of an activity should leave the resource model unaffected.
Therefore, the resource model needs at least one abstract entity type
that serves as a separation between the physical population and the
logical address referenced by workflow activities.
„ Flexibility: The resource model should be flexible enough to allow a
transfer of existing organizational structures without requiring a
change of the established enterprise terminology or the structure of
its organization. For this reason it should be possible to rename entity
types and/or to create new entity and relationship types from the
resource meta model.
„ Scalability: The integration of additional levels of hierarchy, new per-
missions, and obligations should be possible. If a company acquires
another company it should be possible to integrate the two organiza-
tional models under a single managing authority, possibly by adding
new levels to the existing hierarchy.
„ Domain Independence: A resource model for a collaborative software sys-
tem should be as domain-independent as possible. There may be situ-
ations where only human actors are involved in the execution of a
workflow as opposed to situations where only technical resources are
involved (e. g., in a manufacturing environment). The resource model
has to be flexible enough to handle these variations. In addition, it
should only contain a minimum number of entity types in order to
preserve maintainability.

Specification of Resource Assignments

Assignment policies describe how a workflow engine matches activities to
resources at run time. With regard to the assignment of resources to activi-
ties, three different concepts can be distinguished: Direct designation,
assignment by role, and assignment using a formal expression.
Direct Designation
Using direct designation, an activity is assigned to one or more entities of
the resource model directly. At run time, the workflow-engine can directly
look up these resources in the resource repository and place relevant work-
items on their respective work lists. This type of assignment is easy to handle
for the workflow administrator, because it focuses on a single entity type: the
workflow performer. If an activity should be made available to a group of
people, all members of the group have to be assigned to the workflow activ-
Development of Workflow Applications - 163 -

ity individually. The direct assignment concept provides no independence of

workflow model and organizational model, i. e., every change of the organi-
zational population is reflected in the workflow model, which has to be
changed as well. For this reason, the direct assignment mechanism is rarely
used in industrial practice.
Assignment by Role
Many workflow management systems provide workflow modelers with a
role construct. Within these systems, one role entity is used synonymously
with one or more resource entities. EDWARDS defines a role as a category of
users within an application system that inherit a common set of access con-
trol rights to objects specific to this application system.542 The main pur-
pose of the role model is the separation of workflow and resource model.
Changes of the organizational population no longer affect the workflow
model directly. The use of roles instead of direct assignment also provides
means of indirect workload balancing, because all members of a qualified
role are notified about a pending work item, but only one member of this
group needs to perform the activity. From a technical point of view, the
workflow management system has to perform a resolution process to deter-
mine the role members before it can notify these resources. An error han-
dling procedure has to be implemented, in case this resolution process
returns empty set of resources.
Assignment by Formal Expression
The most complex form of task assignment uses a formal expression,
e. g., a predefined function. An example of this type of assignment is the fol-
lowing expression:
activity_performer = superior(resource(activity(1)))
This expression returns the manager of the workflow initiator, i. e., the
resource that performed the first activity of the workflow instance. In this
case, not only the entity types of the resource model have to be known to
the workflow modeler, but also the relationship types between these entity
types, and possible functions that can refer to the workflow execution his-
tory. The attributes used in such a formal expression can be dependent on
the workflow instance, such as information about the performer of a partic-
ular activity. They can also be independent of the workflow instance, such as
the relationship of a resource to another resource.
BERTINO ET AL. propose three categories for the classification of formal
expressions:543 Static constraints such as the relationship between organiza-
542.
Refer to Edwards (1996).
543.
Compare Bertino et al. (1999).
- 164 - Development of Workflow Applications

tional units, dynamic constraints that refer to the history of the workflow
instance, and hybrid constraints that combine the former two. While static
constraints can be evaluated before the workflow instance is started,
dynamic constraints can only be evaluated at run time. If a formal expres-
sion is used for activity assignment, an error handling mechanism similar to
the one used during the assignment by role has to be implemented.
Formal expressions may not only relate to the relationships between
entity types of the resource model, but also to specific properties of
resources. For the assignment of a meeting room to the activity “perform
board meeting”, the location of the room and its availability during a speci-
fied time frame may be relevant properties for the assignment process.
Therefore, a resource management facility not only needs to handle current
information about the workload of resources, but should be able to forecast
available capacities, too. Capacity allocation algorithms, such as those used
by production planning and control systems (PPC-systems) could improve
the resource management component of workflow management systems.
This would enable the precise forecast of processing times for workflow
instances, thus increasing the quality of responses to customers that are
inquiring about the status of their individual workflow instances.

Specification of Assignment Strategies

While resource assignment specifies how a workflow management system
identifies matching resources for a pending activity at run time, an assign-
ment strategy (sometimes called assignment policy) specifies how the
resource is notified about pending work.544 Examples are direct allocation,
where a single resource is assigned to an activity, and indirect allocation,
where a group of resources are notified about pending work, and one of
these resources selects the relevant work item. The selection may either be
implemented using a scheduling basis (for example: first come first serve,
shortest job first), or using a market mechanism such as an open auction for
work items.545

Design Strategies for Resource Models

We can distinguish between two approaches for resource modeling in
workflow applications. These approaches have a direct impact on the design
of the resource meta model: The technology-driven approach, and the orga-
nization-driven approach.
544.A critical discussion of assignment strategies in commercial workflow systems can be found
in Hagemeyer et al. (1998); Hoffmann, Löffler, Schmidt (1999); zur Muehlen (2004).
545.
For a discussion of the advantages of direct assignment versus market-based allocation
strategies compare Tan, Harker (1997).
Development of Workflow Applications - 165 -

Technology-driven Approach to Resource Modeling

The technology-driven approach to resource modeling presumes no pre-
defined set of resources in the organization. Instead, the structure of entity
types needed in the workflow model is derived from the specification of the
workflow model itself. Typically, roles derived from an existing workflow
model are of the form “authorized to perform activity x”. This approach
enables a lean specification of necessary organization structure, because only
workflow-relevant resources have to be captured in the resource model. The
use of roles instead of particular resources makes the workflow model inde-
pendent of changes in the organizational population. However, changes in
the workflow model can easily affect the resource model, because newly
defined activities require new roles to be defined. A large number of com-
mercial workflow management systems show organizational meta models
that were designed following this approach (compare the resource model of
Staffware 2000 in figure 3-21).546 These meta models provide few entity
types with fairly restrictive cardinalities. Complex organization structures
(e. g., matrix organizations) cannot be represented adequately, if a tool based
on such a meta model is used without any extensions.

Figure 3-21: Organizational Meta-Model of Staffware 2000

Organization-driven Approach to Resource Modeling
The organization-driven approach to resource modeling can be found in
environments where workflow management systems are deployed in larger
organizations and a formally defined organization structure is already in
place. In this case, the current organizational structure has to be captured in
the resource modeling facility of the workflow management system, either
by direct modeling or through referral to an external resource repository.
Typical examples for such repositories are X.500 directories or the human
resources module of an ERP software system.
The advantage of the organization-driven approach is the identity of the
organizational structure within the workflow models and the real organiza-
tion. If workflow models are modified by domain experts as opposed to sys-
tem administrators it is easier for them to relate to the organizational model
depicted in the system. However, many commercial workflow management
systems lack basic entities defined in organizational theory, constructs such
546.
Another example are the organizational meta models of IBM FlowMark or CSE WorkFlow
as described in Rosemann, zur Muehlen (1998).
- 166 - Development of Workflow Applications

as organizational position or project team. This conflict can only be resolved

if the workflow management system allows the reference to an external
repository, or if existing entity types can be modified or enhanced to suit the
actual enterprise structure. An example for a semantically rich organization
model is depicted in figure 3-22.

Source: zur Muehlen (2004)

Figure 3-22: Organizational Reference Meta Model
Development of Workflow Applications - 167 -

Security Considerations
The assignment of workflow activities to a resource may not only depend
on the qualification and competencies of the resource, but also on the time
of the assignment. For example, a temporary worker in a bank may substi-
tute for a clerk for a limited period of time, therefore, activity assignments
resulting from this substitution should only be active during this specified
time frame. Furthermore, the planning of organizational development may
be performed a considerable time before it is being activated. In the HR
module of the mySAP ERP-System this fact is represented using different
organizational plans within the organizational development module HR-PD,
while only one of these plans is activated. The resource management facility
has to ensure that, e. g., the promotion of a resource can be put in effect
either immediately or at a specified point in the future. ADER proposes the
handling of security information as an additional entity type within the
resource meta model.547 In order not to increase the complexity of the
resource model we propose the implementation of time constraints for roles
should be handled at the attribute level, e. g., by adding the attributes
“valid_from” and “valid_through” to the entity type role. If an activity
becomes assignable during this time, it may be assigned to the resources that
are members of this role. The workflow management system or the resource
management facility, respectively, have to ensure that work items can only be
selected during the activation period of the role identified for their initial
assignment. If an activity has been assigned to a resource based on a compe-
tency and has not been executed when the competency is revoked, the work
item has to be removed from the work list of this resource. The tracing of
this information may become increasingly complex, especially if a work item
is transferred from one resource to another by means of delegation or sub-
stitution.
For auditing purposes it should be possible to trace the changes of a
resource profile, e. g., the granting and revocation of privileges over time.
Therefore, a resource manager should implement a version concept that
stores relationships between roles and resources with the beginning and end
of validity. For purposes of process controlling, information about the cur-
rent responsibilities and authorizations in the resource model is necessary,
should a post-execution audit of workflow instances be desirable. Informa-
tion about the organizational structure is also useful to identify social net-
works between workflow participants that may impact process
performance.548

547.
Refer to Ader (1996).
548.
Compare van der Aalst and Song (2004).
- 168 - Development of Workflow Applications

3.5.5 Application Integration

A workflow management system supports process participants through
the provision of application logic for the execution of their activities. Alter-
natively, it performs activities without user interaction through the auto-
mated invocation of application logic or services.549 The specification of
application integration modalities in a workflow model ranges from the
specification of scripts within activities, which are executed by the workflow
engine when the activity is enacted, to the design of integration adapters for
external application systems or web services.550 The use of applications in
activities can be either mandatory (for example, if data is passed to and
received from the application), or optional (for instance, if the workflow
management system offers the performer of an activity a support applica-
tion for an otherwise manual task).551
If external applications are referenced within activities, the workflow
model contains information about the access mechanisms (i. e., how the
application is invoked). This application invocation can be asynchronous, if
the workflow engine triggers the execution of an external application, but
does not wait for this application to finish. More frequently used is the syn-
chronous invocation of applications, when the workflow engine waits for a
signal from the application (or the user) to indicate the availability of result
data. If data is passed to and received from the application, the workflow
model may need to specify how data is transformed into and from the for-
mat of the external application. If the external application fails, the workflow
model should specify if the same activity can be executed again without
affecting the public result of the activity. This is critical if preliminary appli-
cation results may be visible to outside parties while the activity is being exe-
cuted (side-effects). In this case, compensation steps for aborted or failed
activities need to be specified.552
External applications manipulate data stores that are not directly accessi-
ble to the workflow management system, but that may be accessible to other
applications or users of the same application outside of the workflow con-
text.553 The workflow modeler has to specify mechanisms to ensure the
integrity of data that the workflow instance passes to and receives from
external applications.
549.
Compare Böhm (2000), p. 167.
550.
Some workflow management systems provide complex programming capabilities, including
the handling of user interfaces for data entry and processing. Compare for example Staff-
ware (Functions) (2000). These systems allow the specification of workflow applications
without the use of external application systems.
551.
Refer to Böhm (2000), p. 169.
552.
Refer to Böhm (2000), p. 171.
553.
Refer to Böhm (2000), p. 169.
Use of Workflow Applications - 169 -

Contemporary workflow management systems rely on messaging and

integration infrastructures, such as application servers554, which standardize
the communication between the workflow engine and external systems, sim-
plifying the application integration process for workflow developers signifi-
cantly. Compare figure 3-5 on page 118 for a workflow service in an
application server architecture. The application server contains adapters to
external systems, such as ERP software, database applications, or legacy
applications. The workflow developer has to specify interfaces to these
adapters, but not to the external systems directly. The standardization of web
services protocols such as WSDL and SOAP will continue to ease systems
integration, as the loose coupling of applications via their web services inter-
faces is becoming increasingly popular.

3.6 Use of Workflow Applications

In the previous section we have focused on the design of workflow appli-
cations, covering aspects from process and organizational design to the inte-
gration of external application logic. In this section we focus on the use of
workflow applications at run time.

3.6.1 Run Time Behavior

The run time environment of a workflow management system can be
accessed from three perspectives:
„ Workflow participants interact with their own work list handlers.
Through this interface they are informed about pending work items,
can select these work items for further processing, and are guided to
invoked applications, if the relevant activity has been implemented in
this way. Workflow participants can use the monitoring facility of the
workflow enactment service to consult the history of a particular
workflow instance (e. g., to identify the colleagues that worked on a
particular case), or to evaluate the overall load of the workflow engine
(e. g., the number of pending activity instances, running processes,
users logged on to the system, etc.).
„ Workflow administrators and process managers interact with the workflow
engine through an administration interface. They can reassign work
items to different workflow participants (e. g., to level the work load
in different departments). In addition, they can monitor the overall

554.
An application server is responsible to provide a standardized run time environment for an
application system. Thus run time environment provides services such as transaction man-
agement, scalability, platform independence and the functionality to access front- and back-
end systems in a transparent manner. Compare Schlumpberger (2001), p. 48.
- 170 - Use of Workflow Applications

performance of the workflow engine, either at a technical level

(administrator) or at an organizational level (manager). The informa-
tion provided by workflow management systems for these groups of
users is discussed in chapter 4.
„ Workflow customers interact with the workflow management system
through its process invocation interface. They trigger the creation of
workflow instances and may manipulate the status of these workflow
instances from the outside, if permitted (e. g., they may start, suspend,
and stop workflow instances). A direct interaction between workflow
customers and the workflow enactment service is less common.
Instead, the application programming interface of the workflow
engine is typically encapsulated by a front-end that enables workflow
customers to use the functionality they are authorized to access. A
workflow customer can also be represented through an application
system. If, for instance, the receipt of an e-mail triggers the instantia-
tion of a workflow, this process invocation is realized at a technical
level through the mail server sending a “create workflow instance”
command to the mail daemon of the workflow engine.

3.6.2 Workflow Instance State Model

During each phase of its enactment, a workflow instance maintains a well-
defined state. This state may be modified through the workflow engine or
through an external entity interacting with the workflow engine.555 Figure 3-
23 shows the state model of a workflow instance in form of a UML state
diagram.556 The model is composed of the two super-states open and
closed. A workflow instance in the state open can be manipulated
through the workflow engine or an external entity, while a workflow instance
in the state closed is finished and cannot be reactivated. Within the super-
state open, the workflow instance is either not_running (meaning that its
activity instances are not being worked on) or running (meaning that activ-
ity instances are created, assigned, and can be executed).
An open workflow instance can be finished either by completion, or by
forced termination. In the latter case, the resulting state can be
closed.cancelled.aborted, if running activities at times of the can-
cellation command were allowed to finish (this is also known as a graceful
abort). If the cancellation of the workflow instance leads to the immediate

555.The WfMC WAPI contains a number of commands for this interaction, for example
WMFetchProcessInstanceState or WMChangeProcessInstanceState.
Refer to WfMC (WAPI) (1997), pp. 23-44.
556.
For details of the notation refer to the notation guide in the appendix.
Use of Workflow Applications - 171 -

(compare WfMC (1997), p. 172ff.; Alonso, Mohan (1997), p. 5)

Figure 3-23: Generic State Model of a Workflow Instance
cancellation of running activity instances, the resulting state is
closed.cancelled.terminated (this is also known as a forced abort).

3.6.3 Activity Instance State Model

Similar to workflow instances, each activity instance follows a life-cycle
that can be described using a state model. Figure 3-24 shows the state-
change-diagram for a typical activity instance.557 Like the state-change-dia-
gram for the workflow instance itself, this model consists of several nested
states. An activity instance is either in the state open, and can be assigned,
started, suspended etc., or it is in the state closed, if it has been completed
or cancelled. Upon activation by the workflow engine, an activity instance is
in the state open.not_running.not_assigned, indicating that it has
not been assigned to a particular workflow participant.
If the activity instance is assigned to an arbitrary number of workflow
participants (i. e., via a role or an organizational entity such as a department),
the activity instance will be visible to all authorized participants through a
work item on their shared work list. Once a participants selects the work
item representing the activity instance for further processing, the activity
instance changes into the state open.running.assigned. This transi-
557.
The state-transition diagram in figure 3-24 is not based on an actual workflow management
system. The nested states have been taken from the WfMC state models, see WfMC
(WAPI) (1997), pp. 174 ff. Figure 3-24 does not distinguish between activity instance state
and work item state, instead, this information is embedded in the “assigned” and
“not_assigned” sub-states. A different state model for an activity instance can be found in
Alonso, Mohan (1997), p. 6, who explicitly incorporate start and end conditions into the
state model. The model presented here incorporates these constraints through guard condi-
tions on the transitions to the state open.not_running.not_assigned (start con-
dition) and from the state open.running.assigned to the state
closed.completed (end condition). If either condition is not met, the corresponding
transition must not be traversed.
- 172 - Use of Workflow Applications

(compare WfMC (1997), p. 172ff.; Alonso, Mohan (1997), p. 6)

Figure 3-24: Generic State Model of an Activity Instance
tion may also be traversed automatically, if the activity is assigned directly to
a particular workflow participant, or if the activity is executed without the
involvement of a (human) participant. In this case, the assignee is the work-
flow engine itself. Some systems allow users to reject work items, in this case
the transition may be traversed in the opposite direction.
An assigned activity may be suspended and resumed an arbitrary number
of times. It also may be reassigned to a different workflow participant (recur-
sive transition from the state open.running.assigned to the (same)
state open.running.assigned). If a workflow participant refuses to
perform an assigned activity, the activity’s state changes back to
open.not_running.not_assigned. From any of the sub-states of the
open superstate, the execution of the activity may be cancelled, resulting in a
transition to the state closed.cancelled.aborted. A closed activity
instance cannot be reactivated, but (system constraints permitting), the same
activity may be re-instantiated. A successfully completed activity instance has
the state closed.completed.

3.6.4 State Changes and Constraints

While the state models in figure 3-23 and figure 3-24 provide a general
overview of the execution dynamics at run time, additional constraints may
limit the ability of the workflow engine to traverse between certain states.
Use of Workflow Applications - 173 -

These constraints include the start and end conditions of activities, which
determine their eligibility for activation or completion, respectively. Also, the
transition between different states of a workflow instance or activity instance
is not always permitted, depending on the state of other system elements. If,
for example, a workflow instance is to be suspended (transition from
open.running to open.not_running.suspended) while there are
open activity instances, the behavior of the process instance can be imple-
mented in different ways by the workflow vendor:
„ The open activities are not affected by the suspension and their con-
tinued execution is permitted. Upon completion (or termination) of
the activity instances, the workflow engine does not evaluate the out-
going transitions from the completed activities, until the workflow
instance is resumed. This way, the effect of a workflow instance sus-
pension is not noticeable to workflow participants. There may be a
considerable time-lag between the suspension of the workflow
instance and the completion of the last running activity.
„ All open activities are suspended until the workflow instance is
resumed. This way, the suspension of a workflow instance is immedi-
ately noticed by those workflow participants, whose activities are sus-
pended by an external authority. Also, applications that perform
changes on external data sources may need to lock these data sources
for as long as the workflow instance is suspended. Effectively, they are
prohibiting other applications from accessing this data for an arbitrary
period of time.
„ All open activities are aborted, and when the workflow instance is
resumed, the activities are executed again. If the granularity of activi-
ties is coarse, intermediate results that are visible to external applica-
tions may need to be compensated.
The above example shows that log information of the type “a certain
workflow instance is in a certain state at a certain time” needs to be
enhanced with information about the semantics of the implementation, oth-
erwise it may not be possible to resume the execution of workflow instances
without damaging the integrity of surrounding applications and data stores.

3.6.5 Audit Trail Information

Most workflow engines record state transitions at the activity and work-
flow level (as well as certain system events, such as user log-on or log-off) in
a log file or database, called the audit trail.558 Depending on the implementa-
tion of the workflow engine, the quality of data recorded in the audit trail
- 174 - Use of Workflow Applications

varies significantly. Audit trail information is being kept by workflow sys-

tems for a variety of purposes:
„ Recovery purposes. Like the system log of a database system, the audit
trail file of a workflow system contains information about open and
closed (in the sense of completed) workflow and activity instances. In
case of a system failure the workflow engine can use the audit trail
upon restart to restore the last known system state. The system has to
consider potential side-effects created by activities that were running
at the time of system failure.559
„ Workflow execution purposes. The audit trail file typically contains infor-
mation about the resources associated with particular events (if these
events were caused by a workflow performer). This information can
be used by the workflow engine to determine the performers of
upcoming activities. For instance, in an administrative workflow such
as a travel expense settlement, the notification about reimbursement
approval or decline should be sent to the workflow participant that
started the workflow instance. Since several members of the organiza-
tion are authorized to start a travel expense reimbursement workflow,
the workflow participant responsible for the notification activity can-
not be specified in the workflow model at build time. Instead, the
workflow engine can use audit trail entries of the current process
instance to determine the process starter and use this information for
the presentation of the next work item.560
„ Evaluation purposes. Since the audit trail provides accurate and timely
information about the execution of workflow and activity instances,
this information can be used in the context of process monitoring and
controlling. We discuss this aspect in detail in the following chapter.

558.Some authors use the term workflow log as a synonym for audit trail, compare Agrawal,
Gunopulos, Leymann (1998). GEPPERT and TOMBROS refer to the audit trail as event his-
tory (Geppert, Tombros (1997), p. 67). SCHLUNDT ET AL. as well as KOKSAL ET AL. use the
term history management, see Schlundt, Jablonski, Hahn (2000) and Koksal, Alpinar,
Dogac (1998). MCLELLAN distinguishes between the audit trail as the raw data collection
and workflow metrics as evaluations based on this data (McLellan (1996), p. 303).
559.
For a discussion of recovery aspects compare e. g. Eder, Liebhardt (1996) and Liu et al.
(2000).
560.Of course, information about the process starter could also be treated as a workflow rele-
vant data object and stored in the workflow engine for the duration of the workflow
instance.
Related Work on Workflow-based Monitoring and Controlling - 175 -

4 Workflow-driven Process Controlling

In the previous two chapters we have determined the organizational,
managerial, and technological factors that play a role in the design and appli-
cation of workflow-based process monitoring and controlling systems. In
this chapter we outline the architecture of such a system. We start with a
review of related work in section 4.1. In section 4.2 we develop a reference
model for workflow audit trail data, a central basis for process monitoring
and controlling systems. The design of a conceptual framework, a reference
architecture for process controlling systems is discussed in section 4.3, and
in section 4.4 we return from the more technical aspects of process control-
ling to the organizational implementation, and present a process controlling
cycle based on the cybernetic controlling models discussed in chapter 2.

4.1 Related Work on Workflow-based Monitoring and Controlling

The use of workflow audit trail information for controlling purposes has
been recognized by the scientific community only recently. The first survey
of the analytical opportunities arising from audit trail information was pro-
vided by MCLELLAN in 1996.561 He provides an overview of the analysis of
historical process data and discusses the evaluation of audit trail data in
terms of workflow metrics. The controlling applications described in his
article are statistical evaluations as well as the run time detection of late cases
and overdue tasks. Since the publication of MCLELLAN’S paper, a number of
scientific and commercial approaches to process monitoring and controlling
have been published. Recently, the monitoring of business processes has
been branded as Business Activity Monitoring by the Gartner Group.562
Existing work on the monitoring and controlling of processes can be clas-
sified in four areas:
„ Data Perspective: How to collect, store, and represent process audit
trail data.
„ Usage Perspective: Management of exceptions versus the manage-
ment of regular process operations.
„ Tool Perspective: Architectures and prototypes of process monitoring
and controlling systems.
„ Method Perspective: Conceptual approaches to process monitoring
and controlling.

561.
See McLellan (1996).
562.
Compare Dresner, McCoy (2002); Dresner (2003).
- 176 - Related Work on Workflow-based Monitoring and Controlling

4.1.1 Data Perspective

WfMC Common Workflow Audit Data Format

The Workflow Management Coalition has specified an interface for
workflow audit data in the context of their generic workflow reference
model.563 The WfMC Interface 5 specifies the elementary information a
workflow management system should record the execution of workflow
instances.564 The existing standard provides a data format for the audit trail
data as well as guidelines, which events should be recorded. However, the
evaluation of this information is not addressed in the WfMC standard. After
the publication of the current standard document, a proposal for an API has
been submitted to the WfMC,565 but since the revision of the data format in
1999 little progress has been made in providing either a functional specifica-
tion or an XML schema for audit data.

4.1.2 Usage Perspective

Computer-based Process Performance Measurement (COPPA)

The COPPA project (Computer-based Process Performance Measure-
ment) conducted at the University of Fribourg, Switzerland, deals with the
design of a performance measurement system.566 Using a three stage
approach, the authors first surveyed the market and corporate practice of
performance measurement. During a second stage the architectural and
functional requirements of a performance measurement system were out-
lined, and during a third phase, a prototype of the performance measure-
ment system was implemented. In relation to workflow-based controlling,
the authors position process performance measurement at a higher level of
abstraction, which includes information about the strategic positioning of an
enterprise, whereas a workflow-based controlling system is mainly focused
on the analysis of operational data.

Chimera-Ex
In the EU-funded project WIDE project, CASATI ET AL. investigated the
issue of specifying and monitoring exceptions in workflow management sys-
tems which are most applicable for standard and repetitive business pro-
cesses.567 The authors introduce an exception language Chimera-Ex to

563.
Compare Hollingsworth (1995).
564.
See WfMC (IF5) (1999).
565.
Compare WfMC (IF5 API) (1999)
566.
See Kueng (1998), Kueng (2000).
567.
Compare Casati et al. (1999); Casati et al. (2000).
Related Work on Workflow-based Monitoring and Controlling - 177 -

model the exceptional situations for the workflow according to detached

active rules and patterns. The authors applied the language in the proposed
architecture FAR and integrated it with a commercial workflow management
system. The authors address exception handling in the context of workflow
management in some extent, however, all exceptions that can be managed by
this architecture are described at build-time, i. e., unpredictable exceptions
are not considered.

Process and Project Management

The capabilities of workflow technology in controlling and monitoring
business processes and project management were discussed by SHIH and
TSENG in 1996.568 They compare the similarities and differences in the con-
ceptual characteristics of business processes and project management, as
well as their respective management needs in the functions of planning, exe-
cution, monitoring, and controlling. The authors propose a workflow tech-
nology-based system with capabilities to handle concurrent coordination,
monitoring, and communication in business processes and large-scale
projects. An implementation of the proposed system is not provided.

4.1.3 Tool Perspective

WorkFlow Analyzer
The design of a process analysis tool named WorkFlow Analyzer was pre-
sented by DERSZTELER as part of his Ph.D. work.569 A partially functional
prototype was implemented on the basis of CleverPath Forest&Trees. Based
on audit trail data from the workflow management system WorkParty by Sie-
mens Nixdorf and target data from the business process modeling tools
ARIS and Bonapart, the prototype provides several quantitative evaluation
methods. However, the combination of the audit trail information with busi-
ness data was not realized in this approach. In addition, the platform-spe-
cific implementation and the reliance on a single (and discontinued)
workflow management system limit the general applicability of his approach.

IDWM - Process Controlling in the Manufacturing Domain

A more process-specific prototype was developed by RAUFER, who dis-
cussed the controlling of workflow-based processes using a case study from
the manufacturing domain.570 He focused on a specific process, which was
enhanced with cost information as well as target work- and cycle-times. The
568.
Compare Shih, Tseng (1996).
569.
See Derszteler (2000).
570.
See Raufer (1997).
- 178 - Related Work on Workflow-based Monitoring and Controlling

presented prototype, based on the workflow management system COI, is

targeted specifically at the process analyzed by RAUFER. As a result, the sys-
tem architecture cannot be generalized easily.

Workflow-driven Activity-based Costing

A similar prototype was presented by WEISS.571 He developed a work-
flow-driven activity-based-costing system for the commercial workflow
management system Staffware. The focus of his approach is the realization
of a single evaluation method, therefore, the resulting system is not designed
to be extended by additional evaluation methods.

PISA - Process Information System based on Access

The research project CONGO (Controlling and Monitoring of distrib-
uted Workflows for continuous Process Improvement) was conducted
between 1995 and 1999 at the University of Münster, Germany, and is the
predecessor of the research project presented in this book.572 Over the
course of this project, three process controlling system prototypes were
implemented, called PISA (Process Information System based on Access) I,
II and III.
PISA I was developed in the fall of 1995 as a working prototype based on
a Microsoft Access database. The system was able to access process models
from IDS Scheer’s ARIS Toolset Version 3.0 through an ODBC connection,
and imported the audit trail file from IBM FlowMark Version 2.2. This first
version served as a feasibility study and implemented elementary evaluation
methods based on a cube with the dimensions process, abstraction, and
organization. Whereas the first prototype employed only a few evaluation
methods, PISA II (also based on Microsoft Access) used more sophisticated
evaluation methods, such as the hedonic wage model573, and allowed addi-
tional evaluations on process objects, such as a cluster analysis.
PISA III was re-implemented in Java with the goal to realize a fully dis-
tributed system architecture. In addition platform, database, and client inde-
pendence should be realized. The PISA III Server is a stand-alone
application that coordinates the PISA clients and delivers evaluation meth-
ods, the matching graphical panels to display evaluation results, as well as the
results of audit data evaluations. The PISA client is realized as a Java applet
that can be executed within a Java-capable web-browser. Data source adapt-

571.
See Weiß (1998).
572.
Compare Rosemann, Denecke, Püttmann (1996); Rosemann (1997); zur Muehlen, Rose-
mann (2000); zur Muehlen (2000).
573.
Compare Sassone (1987).
Related Work on Workflow-based Monitoring and Controlling - 179 -

ers work as mapping modules to connect the contents of a workflow audit

trail database with the audit trail repository of the PISA III system. These
adapters perform conversions between system-specific data formats and
provide transparent access to data sources, enabling the system to integrate
the audit trails of different workflow systems.

Process Performance Manager

The Process Performance Manager is a commercial performance analysis
tool by IDS Scheer AG which can connect to different application sys-
tems.574 The system mainly integrates source data from modules of the
mySAP ERP system into a relational database and calculates predefined
ratios. These ratios are frequency- and time-related and computed at differ-
ent aggregation levels, reflecting recipients at the operative level, middle
management, and executives. Workflow-vendor Staffware has integrated the
Process Performance Manager with its workflow management system, and
offers a customized version of the Process Performance Management as an
OEM product for their Staffware 2000 workflow management system.

Business Process Intelligence

CASATI ET AL. at Hewlett Packard Laboratories have developed a Process
Data Warehouse for the collection of metrics from the workflow manage-
ment system HP Changengine.575 They propose the use of process mining
algorithms to derive behavioral patterns from workflow audit trail informa-
tion. As a front-end they propose a Business Process Cockpit, which uses
multi-colored bargraphs to illustrate time-based process attributes, such as
the processing times of individual activities.

IBM Solution Manager

JENG and SCHIEFER have developed an agent-based architecture with the
aim of providing continuous, real-time analytics for business processes.576
For the analytical processing they introduce an agent framework that is able
to detect situations and exceptions in a business environment, perform com-
plex analytical tasks, and reflect on the gap between current situations and
desired management goals. A more recent project of SCHIEFER, JENG, and
BRUCKNER aims at bridging the gap between existing workflow manage-
ment systems and decision supporting systems, since they are not able to
provide continuous, real-time analytics for decision makers.577 In their
574.
Compare IDS Scheer AG (2000).
575.
Compare Casati et al. (2002); Bonifati et al. (2001).
576.
Compare Jeng, Schiefer (2003).
577.
Compare Schiefer et al. (2003).
- 180 - Related Work on Workflow-based Monitoring and Controlling

paper, the authors introduce an agent-based architecture to support a busi-

ness intelligence process to sense, interpret, predict, automate, and respond
to changes in business processes in a timely fashion.
The proposed architecture is composed of five major components: Busi-
ness Intelligence Agents for analytical processing; An event processing con-
tainer (EPC) for the real-time transformation of process events; A Process
Information Factory for storing business process metrics (i. e., a process-
specific data warehouse); A policy management system for monitoring/
tracking all management agents running within the system; And a dashboard
for the visualization of business process metrics and analytical results. In a
later paper, SCHIEFER extended the Solution Manager architecture to expose
its functionality through four web services interfaces, for the set-up of the
solution manager, monitoring of running processes, analysis of data in the
process warehouse, and the feeding of event data.

4.1.4 Method Perspective

Workflow-driven Balanced Scorecard

MCGREGOR has analyzed the existing WfMC common audit data format
standard in order to design a process controlling prototype that uses this
information to generate the process perspective of a balanced scorecard.578
Her work aims at the development of a closed-loop system that takes audit
trail information as an input and delivers advice to process designers, regard-
ing which aspects of the workflow model could be optimized. She discusses
the impact of process controlling requirements on the WfMC Interfaces 1
and 5, and proposes extended attributes for the integration in the standards
specification.579 The analysis is based on a case study and is performed on a
conceptual level and served as input to the IW-MONS framework.

IW-MONS
MCGREGOR and KUMARAN have presented a Solution Management
framework that analyzes workflow audit logs, utilizing decision support sys-
tem principles and agent technologies to feedback performance measures.
This framework forms part of the Intelligent Workflow Monitoring System
(IW-MONS) methodology.580 An extension for this framework using web
services was proposed by MCGREGOR and SCHIEFER, who state that current

578.See McGregor (IF5) (2002).

579.Itshould be noted that the attributes proposed for an extension of Interface 5 are already
covered by the Prefix part of the existing specification, which is presented in section 4.2.2
on page 183.
580.
Compare McGregor (IW-MONS) (2002); McGregor, Kumaran (2002).
A Reference Meta Model for Audit Trail Data - 181 -

web service frameworks do not include the functionality required for web
service execution performance measurement from an organizational per-
spective.581 The work of MCGREGOR remains at a conceptual level, without
a physical implementation.

Workflow*BPR
SHOHAIEP ET AL. present a methodology for the identification of process
knowledge through the analysis of work practices.582 Even though their
method is called “Workflow*BPR” it does not require the use of a workflow
management system. Taking the basic idea of determining the knowledge
incorporated in a process, workflow audit trail data can be perceived as a
“knowledge store” in its own right. For example, the experience of a work-
flow participant could be computed taking the number of times into account
that this participant has performed a certain activity type. When this infor-
mation is fed back into the workflow management system, new staff alloca-
tion methods could be implemented, such as “assign this activity to the most
experienced person available”. The paper by SHOHAIEP ET AL. remains at a
conceptual level and does not discuss implementation details.

4.2 A Reference Meta Model for Audit Trail Data

4.2.1 Information Content of Audit Trail Data

The content of audit trail data that is available for subsequent analysis in
process controlling systems is determined by two factors: The event types
recorded by the workflow management system during the enactment of
workflow instances, and the types of attributes recorded with each audit trail
entry. The combination of these two factors determines the amount and
quality of raw data available for further analysis. In the following section we
analyze the audit trail data format of three commercial workflow manage-
ment systems and compare these with the common workflow audit data for-
mat proposed by the Workflow Management Coalition.583

Systems Analyzed
For our analysis we have chosen three systems that represent a spectrum
of classical and contemporary workflow products: IBM MQSeries Work-
flow, Staffware 2000, and Carnot Process Engine.

581.
Compare McGregor, Schiefer (2003).
582.
See Shohaiep, Housel, Kanevsky (1997).
583.
Compare WfMC (IF 5) (1999).
- 182 - A Reference Meta Model for Audit Trail Data

The IBM MQSeries Workflow system was first released in 1994 under the
name FlowMark, a name that was maintained until the release of version 2.3.
At this point, the core workflow system was re-implemented, replacing the
original communication infrastructure with support for the IBM MQSeries
message queueing middleware, and the system’s name was changed to match
the new infrastructure support. Prior to the re-implementation, FlowMark
was used as the basis platform for a research project at IBM Almaden
Research Center, which addressed distribution, transaction management,
and messaging aspects of the workflow infrastructure.584 The system was
included in the evaluation, because its development has been well docu-
mented585, and it has been analyzed in previous research projects.586
Staffware was one of the first workflow vendors that offered a pure-bred
workflow product and has competed in the workflow market since the mid-
dle of the 1980s.587 The workflow management system Staffware 2000 has
been a commercial success with more than 1,000,000 licensed clients, and
the largest installation covering 10,000 users.588 The Staffware 2000 system
provides support for the display of process metrics and its audit trail can be
extended with user defined entries. This system was included for its com-
mercial availability.
The Carnot Process Engine represents a workflow management system
based on an application-server-based software architecture.589 Instead of
being an independently executable application, the workflow engine is
deployed in a J2EE compliant application server that provides infrastructure
services such as messaging support, adaptors to legacy systems, and database
connectivity. The Carnot Process Engine stores workflow models and audit
trail information in a combined database structure. This system was chosen
as a representative of a new generation of workflow products that leverage
infrastructure standards. Carnot entered the marketplace 15 years after the
first version of Staffware was released, and 6 years after the release of IBM
FlowMark. For this reason, the three systems represent a sample of work-
flow management systems with different maturity.

584.
The Exotica project resulted in two prototypes that extended the functionality of Flow-
Mark. Exotica/FMDC added capability for the handling of mobile and disconnected cli-
ents. Compare Alonso, Agrawal et al. (1996). Exotica/FMQM added support for a message
queueing infrastructure layer. Compare Alonso et al. (1995). In addition, work on the sup-
port of advanced transaction models was performed. Compare Alonso, Günthör et al.
(1996).
585.
Compare e. g. Leymann, Altenhuber (1994); Leymann, Roller (1997); Leymann, Roller
(2000).
586.
Compare Rosemann, Denecke, Püttmann (1996).
587.
Compare figure 3-1 on page 93.
588.
Compare Karl, Karl (2000), p. 50.
589.
Compare Carnot AG (2002).
A Reference Meta Model for Audit Trail Data - 183 -

4.2.2 Audit Trail Attributes

The attributes stored in a workflow management system’s audit trail
determine the integration points of the audit trail entries with additional data
sources. For instance, if a workflow management system stores the identifier
of the business object that was manipulated during the execution of an activ-
ity instance, this reference can be used to enhance the audit trail information
with business-object-related information from data sources outside the
workflow management system’s scope.

Workflow Management Coalition Interface 5

As part of the WfMC reference model, the specification of Interface 5
provides guidance for workflow vendors with regard to which data should
be captured and stored in the audit trail of a workflow management system.
The intention of the common workflow audit data format (CWAD) is the
integration of audit trail information across different workflow management
systems and different processes to enable enterprise-wide and cross-enter-
prise process analyses.590 Figure 4-1591 shows the data structure proposed in
the WfMC Interface 5 specification.592 It consists of a prefix, a variable body,
and a suffix. The prefix contains the identifier of the process instance, which
caused the audit trail entry. In order to support hierarchical processes, each
entry contains the identifier of the root process instance (i. e., the direct
superior instance to the current instance, if applicable). The body of the data
structure varies for different types of events. The suffix data structure is
used for vendor-specific extensions of the data model. Using different
extension types, vendors can record additional attributes depending on the
events their systems are capturing.
The different data structures of the CWAD body can be grouped into
process-related events, activity-related events, and work-item-related events.
The state change of a process instance (e. g., the cancellation of the process
instance) causes the previous state of the process instance to be recorded. In
contrast, the state change entry of an activity instance contains both the pre-
vious and the current state of the activity instance. The current state of the
process instance is part of the prefix data structure.

590.
Compare WfMC (IF5) (1999), p. 5.
591.
The data structures are presented in object-relational notation. Bold attribute names indi-
cate mandatory attributes, while plain type attributes are optional (i. e., the table may con-
tain a NULL value for this attribute). The indicator “PK” denotes a primary key, while
“FK” denotes a foreign key.
592.
Note that audit trail entries concerning the remote invocation of processes have been omit-
ted from the diagram. These entries are designed for the consistent recording of processes
that are implemented across different workflow engines. For the purpose of this study, we
restrict the analysis to processes that are executed on a single workflow engine.
- 184 - A Reference Meta Model for Audit Trail Data

Source WfMC (IF5) (1999).

Figure 4-1: Audit Trail Data Structure of WfMC Interface 5
A Reference Meta Model for Audit Trail Data - 185 -

This example illustrates the varying number of attributes recorded for dif-
ferent event types. On the one hand, this allows the workflow engine to
record only those attributes that are relevant for the current event, thereby
reducing the number of NULL valued fields. On the other hand, the consis-
tent storage of audit trail information is hampered through the changing
data structures for different event types. Ultimately, the workflow manage-
ment system needs to maintain seven different log entry formats to be com-
pliant with the Common Workflow Audit Data format.

IBM MQSeries Workflow

The audit trail of IBM MQSeries Workflow is recorded in a single table
structure with fixed attributes as shown in figure 4-2. While the audit trail is
recorded in the database of the workflow engine, the single table structure
enables the system to export the audit trail entries in a single file or message,
simplifying the integration of this type of data into evaluation tools. Never-
theless, since not all recorded attributes are relevant for all types of events, a
number of NULL values will be recorded for most events. For example, the
transfer of a work item for the activity instance review invoice between the
workflow participants zur Muehlen and Becker in the process instance invoice ill-
bruck of the workflow model invoice auditing creates the following audit trail
entry:
2002-06-01:13:05:05:001,21009,invoice illbruck,
PID4711,invoice illbruck,PID4711,,P01,invoice auditing,
2002-05-01,,zur Muehlen,Becker,review invoice,
21100,21200,,,WID001,work item001,,,

The attributes of the audit trail contain a field with information about a
second user. This field is used when a work item is transferred or duplicated.
In this case, the second user field contains the user who was the source of
the transfer or duplication. The field is also used when a work item is cre-
ated: This event is initiated by the workflow engine, thus the first user field
refers to the workflow engine itself, and only the second user field contains
the name of the work item recipient. The attribute second activity name is
filled in conjunction with events created by transitions, and contains the
name of the target activity a transition is leading to. The field associated object
contains the object identifier of the work item, activity instance, or process
instance the event was recorded for. This value is different from the regular
identifier, since it can be used to locate the associated object in the underly-
ing audit trail database.
- 186 - A Reference Meta Model for Audit Trail Data

Source: Compare IBM Corporation (1999), pp. 37-45.

Figure 4-2: Audit Trail Data Structure of MQSeries Workflow

Staffware 2000
Figure 4-3 shows the audit trail data structure of Staffware 2000. While
the core audit trail record contains only eight attributes, it provides links to
the data structures for process instances (case_information), process models
(proc_index) and network structures (nodes). The events recorded in the audit
trail table are defined in a text file, which specifies a 3-digit event code and a
description of the event. This format makes it possible for system adminis-
trators to enhance the existing event codes with user defined event codes.
The Staffware audit trail table does not provide information about super-
or sub-processes in a direct manner. Instead, this information is stored in the
proc_index table (attributes is_subproc and has_subproc), since support for
hierarchical processes was only added for an upcoming product version, but
the version analyzed in this book did not support hierarchical processes.

Carnot Process Engine

The audit trail database structure of the Carnot Process Engine consists
of four categories of tables (compare figure 4-4). The tables on the left side
of the diagram contain the process structure of the workflow model, while
the tables on the right side of the diagram contain the entities describing the
organization model. The tables in the middle of figure 4-4 contain data
about the running and completed workflow instances. Instead of a central
A Reference Meta Model for Audit Trail Data - 187 -

Source: Compare Staffware plc (Oracle) (2000).

Figure 4-3: Audit Trail Data Structure of Staffware 2000
audit trail table, the Carnot Process Engine maintains four log tables that
record events that are produced by the workflow engine, the timer daemon,
or recovery tasks, i. e., when the state of running process instances is
restored after a system failure. The daemon_log table records events docu-
menting the behavior of system daemons, such as the mail daemon that
monitors incoming e-mails and triggers processes upon the receipt of rele-
vant e-mail messages.
The log_entry table contains the audit trail entries created by the workflow
engine during the enactment of workflow instances. Other than a timestamp
- 188 - A Reference Meta Model for Audit Trail Data

Source: Compare Carnot AG (2002), pp. 273-279.; Blum (2002), p. 17.

Figure 4-4: Audit Trail Data Structure of Carnot
and the type of event (subject), it only contains references to the process
instance object and activity instance object associated with the log entry.
Information about the originator of the event is stored with the object itself.
For instance, the activity instance table contains information about the per-
former of an activity instance. This combination of attributes improves the
performance of process monitoring queries, such as “who was the per-
former of the last activity”, since no database joins are required to identify
the performer of an activity. Still, the manipulation of activity instances, e. g.,
the delegation of an activity instance to another user, cannot be determined
A Reference Meta Model for Audit Trail Data - 189 -

ex-post, since the activity instance table only contains one attribute for the
actual performer of an activity.

4.2.3 Audit Trail Events

In addition to the attributes recorded by the workflow engine, the granu-
larity of information stored in the audit trail depends on the event types
which result in audit trail entries. The WfMC Interface 5 distinguishes four
categories of event types: Workflow instance related events, activity instance
related events, work item instance related events, and remote operation audit
trail information. The last type of events is recorded, if a workflow engine
manipulates activities or processes that run on a remote workflow engine, or
if it is being manipulated through a remote system in a similar fashion. This
type of information enables a consolidated recording of audit trail informa-
tion in one place, even though the logical workflow instance in question was
executed across different systems. For the first three event categories, the
WfMC specification differentiates between the following event types:593

Process Instance Audit Information

These events relate to state changes at the process instance level, such as
the instantiation, start, and completion of workflow instances.
Create/Start Process/Subprocess Instance Audit Data
„ WMCreatedProcessInstance: A new process instance was cre-
ated.
„ WMStartedProcessInstance: A process instance was started.
Change Process/Subprocess Instance State Audit Data
„ WMChangedProcessInstanceState: The state of a process
instance has changed due to an external or internal event.
„ WMCompletedProcessInstance: A process instance has been
completed normally.
„ WMTerminatedProcessInstance: A process instance has been
terminated (i. e., gracefully canceled before it was completed, pending
activities and sub-processes may still be active).
„ WMAbortedProcessInstance: A process instance has been
aborted (i. e., forcefully canceled before it was completed, all pending
activities and subprocesses have been cancelled as well)

593.
Compare WfMC (IF5) (1999), p. 30-31. Events regarding the remote invocation of pro-
cesses or activities have been omitted from the list.
- 190 - A Reference Meta Model for Audit Trail Data

„ WMWaitingOnEvent: A process instance is waiting for event(s) to

occur.594
„ WMEventOccurred: One or more event(s) on which a process was
waiting has occurred.
„ WMStartedSubprocess: A subordinate process has been started
by a process instance. This information is used by the workflow
engine to determine, if a process instance has any pending sub-pro-
cesses, in case the top-level process instance is aborted.
„ WMCompletedSubprocess: A subordinate process has been com-
pleted and control is returned to the parent process (in case of a syn-
chronized instantiation).
Assign Process Instance Attributes Audit Data
„ WMAssignedProcessInstanceAttributes: One or more
attributes of a process instance have been changed. Using this event, a
workflow engine can signal that a process instance has exceeded the
maximum permitted processing time, and an escalation was raised.
Other possible uses could be changes in process ownership, or a
change of process quality parameters, such as priority or deadlines.

Activity Instance Audit Information

The events relate to state changes at the activity instance level, such as the
availability or completion of an activity.
Change Activity Instance State Audit Data
„ WMChangedActivityInstanceState: The state of an activity
changed due to an external or internal event. This entry is also used to
record the initial state of the activity instance. In this case, the state of
the activity would be changed to “ready”.
„ WMCompletedActivityInstance: An activity instance has com-
pleted successfully. The workflow engine may be notified about this
event through a variety of mechanisms. Either the workflow partici-
pant has signaled the completion of the tasks associated with the
activity, all work items connected with the activity have reported com-
pletion, or an invoked application has transmitted a successful com-
pletion code.

594.Note that the WfMC specification does not support the handling of events. Therefore, this
audit trail entry only relates to workflow engines capable of handling events, but is not man-
datory for all workflow engines supporting the Interface 5 specification.
A Reference Meta Model for Audit Trail Data - 191 -

„ WMTerminatedActivityInstance: An activity instance has

been terminated (i. e., it has been ended gracefully).
„ WMAbortedActivityInstance: An activity instance has been
aborted (i. e., it has been ended forcefully).
„ WMWaitingOnEvent: An activity is waiting for one or more event(s)
to occur.
„ WMEventOccurred: One or more events have occurred an activity
was waiting for.
Assign Activity Instance Attributes Audit Data
„ WMAssignActivityInstanceAttributes: One or more
attributes of an activity instance have been changed. Similar to a pro-
cess instance, changes of activity instance attributes can signal the
occurrence of an escalation, or general property changes of an activity.

Work Item Audit Information

These events relate to state changes of work items, i. e., elements that rep-
resent activities to process performers.
Change Work Item State Audit Data
„ WMSelectedWorkItem: A user has selected a work item from his
or her work list. The activity associated with the work item is associ-
ated with the respective user and is locked from access by other users,
unless it is a group activity where several users are required to com-
plete the activity. This event type also covers the reservation of a work
item for later processing, and the checking out of a work item for pro-
cessing on a device that may be disconnected from the workflow
engine.
„ WMStartedWorkItem: A user has started working on tasks repre-
sented by a work item. Within most workflow management systems
this event coincides with the selection of a work item. If work items
are presented on work lists that are shared by several users it may be
desirable to reserve a work item first, and start working on it later.
„ WMChangedWorkItemState: The state of a work item has been
changed by an external or internal event. This event type is also used
to indicate the initial state of a work item.
„ WMCompletedWorkItem: All tasks related to a work item have been
completed successfully.
- 192 - A Reference Meta Model for Audit Trail Data

„ WMRejectedWorkItem: A work item has been rejected by a user. If

work items are offered for user selection this situation should not
occur often. Nevertheless, if the workflow engine “pushes” pending
activities to users through the use of scheduling algorithms, users
should have the option to refuse a work item presented to them.
Assign/Reassign Work Item/Work List Audit Data
„ WMAssignedWorkItem: A work item is placed on the work list of a
user, i. e., it is made visible to the user for selection.
„ WMReassignedWorkItem: A work item has been reassigned to one
or more users different from the original recipient.
„ WMReassignedWorklist: The entire work list of a user has been
reassigned to one or more users.

4.2.4 Comparing the Information Content of Audit Trails

Table 4-1 lists the workflow instance-related events recorded by the three
commercial systems. Table 4-2 contains the corresponding activity instance-
related events. As a reference, the event types supported by the WfMC Inter-
face 5 specification including the event name are listed as well.595 Since
Staffware and Carnot do not differentiate between activity instance events
and work item events, these event types have been combined into one table.

IBM MQSeries Workflow

The audit trail functionality of MQSeries Workflow offers both a concise
and a verbose option for audit trail recording. Using the concise option, only
a limited number of event types are logged, but more technical events are
not recorded in the audit trail. Using the verbose option, additional technical
events are recorded in the audit trail. Almost all event types specified by the
WfMC specification are supported, with the exception of a process abort.
For some event types, such as the suspend and resume events on the pro-
cess and activity level, the original user request as well as the system response
are recorded. For example, if the user requests the suspension of a process,
the system may actually set the state of the process to “suspended” only
when all pending activities and sub-processes have been completed. This
may result in a delay between the request and response events.
While the level of detail provided by the MQSeries Workflow audit trail
enables a very detailed analysis, the events recorded by the workflow engine
may result in potentially large amounts of data. LEYMANN and ROLLER have
595.
Compare WfMC (IF5) (1999)
A Reference Meta Model for Audit Trail Data - 193 -

IBM Carnot
MQSeries Staffware Process
Event WfMC
2000
Workflow Engine Interface 5
V 3.2 V 8.1 V 2.0

ready x 0 x x (WMCreatedProcessInstance)

start x x x x (WMStartedProcessInstance)

x (request and 0 x x (WMChangedProcessInstanceState)

suspend
result)

x (request and 0 x x (WMChangedProcessInstanceState)

resume
result)
Workflow Instance Event

x (error and x (error and x x (WMTerminatedProcessInstance)

terminate
requested) requested)

abort 0 0 0 x (WMAbortedProcessInstance)

complete x x x x (WMCompletedProcessInstance)

x x x x (WMAssignedProcessInstance-
overdue
Attributes)

restart x 0 0 x (WMChangedProcessInstanceState)

x (request and 0 0 0
delete
result)

„ Import „ user revisions „ schema „ Remote process invocation

„ Exit condi- „ user-defined changes „ Remote process control
other
tion failure events „ Event (wait/received)
„ Attribute changes

Table 4-1: Audit Trail Entries (Workflow Instance)

pointed out the risk of growing audit trails.596 They estimate the typical
number of log entries per activity to be five, equalling 1 KB for a fully fea-
tured audit trail entry. For a medium sized company that executes 10,000
process instances with 10 activities per day, this calculation results in an audit
trail of 500 MB every day, not including the associated business object infor-
mation. Numbers like these are not unusual. The average number of pages
received in the mail room of the insurance company described in chapter 5 is
on average 29,000 per day, resulting in 8,900 different process instances that
are instantiated every day.

Staffware 2000
The Staffware audit trail format offers fewer event types than proposed
by the WfMC Interface 5 standard. For instance, even though the system
supports the interruption of activity instance processing in the form of sus-
pend and resume operations, these events are not recorded in the audit trail.
This makes it impossible to determine the actual (productive) processing

596.
See Leymann, Roller (2000), p. 106.
- 194 - A Reference Meta Model for Audit Trail Data

IBM Carnot
MQSeries Staffware Process
Event WfMC
2000
Workflow Engine Interface 5
V 3.2 V 8.1 V 2.0

ready x x x x (WMChangedActivityInstanceState)

x (work-item) x x (WMSelectedWorkItem/
assign
WMAssignedWorkItem)

start x x x x (WMStartedWorkItem)

x (work-item) x 0 x (WMRejectedWorkItem/
reassign
WMReassignedWorkItem)

x (request and 0 x x (WMChangedActivityInstanceState)

suspend
result)
Activity Instance Events

x (request and 0 x x (WMChangedActivityInstanceState)

resume
result)

x x x x (WMCompletedActivityInstance/
complete
WMCompletedWorkItem)

x x (error and x x (WMAbortedActivityInstance)

abort
requested)

x (two-level) x x x (WMAssignedActivityInstance-
overdue
Attributes)

„ Mobile events „ Mail delivery „ Reassignment of entire worklists

(check-in/out) events „ Event wait and receipt
„ Duplicate „ Sub-case „ Change of activity instance
work-item events attributes
other „ Process and „ Withdrawn
activity and resent
import activities
„ User-defined
events

Table 4-2: Audit Trail Entries (Activity Instance)

time of an activity as opposed to idle time; only the general turnaround time
of an activity instance can be computed. In correspondence with system
functionality, Staffware supports the withdrawal of work items from user
work lists, and the resubmission of these work items to the same or different
users at a later point in time, and these events are recorded accordingly in the
audit trail.
While the lack of standardized event types limits the expressiveness of the
Staffware audit trail, the system allows for the definition of custom event
types (up to a maximum of 743 user defined event types), which can be
inserted into the audit trail.597 This enables the recording of additional infor-
mation related to a workflow instance, for example, the identifier of the
business object related to the current workflow instance. This additional
information is not recorded automatically, instead, a manual system function
has to be invoked to trigger the insertion of a custom audit trail entry. Con-

597.
Compare Staffware plc (Oracle) (2000).
A Reference Meta Model for Audit Trail Data - 195 -

sequently, the additional audit trail entries have to be specified during the
design phase of the workflow model and appropriate (automated) activities
have to be inserted into the workflow model at build time.

Carnot Process Engine

The Carnot Process Engine records almost all event types defined by the
WfMC specification in its audit trail database. Only state changes on the
work item level are not recorded, because the workflow engine does not dis-
tinguish between an activity instance and a work item. Consequently, the
performer attributes related to a work item are associated with the activity
instance, not the state change recorded in the audit trail.

4.2.5 Conceptual Workflow Meta Model

In order to create a framework for process controlling based on workflow
audit trail data, it is necessary to determine the entities contained in a work-
flow audit trail. Figure 4-5 shows the conceptual workflow meta model,
which outlines the elements and relationships that contribute to the work-
flow audit trail. This meta model is based on the activity-centered process
modeling paradigm, although it could be adjusted to accommodate different
approaches with relatively little effort. The left side of the entity-relationship
diagram contains a conceptual model of the workflow modeling method,
while the right side shows the entities related to run time dynamics. All ele-
ments of the reference meta model have been outlined in chapter 3, and
more detailed definitions can be found there.

Build Time Elements

A process (which may be hierarchically decomposed) consists of activities.
The activities are connected through transitions, and one activity may have
multiple incoming and outgoing transitions. Activities without an incoming
transition are start activities, activities without outgoing transitions are end
activities. Transitions may contain transition conditions, which restrict the con-
trol flow. A transition condition may refer to a property of a business object. A
business objects is a coherent collection of data that describes an economi-
cally relevant object that can be manipulated through one or more applica-
tions. Activities may reference a business object relevant application, unless
they are executed manually. In this case, the performer of an activity manipu-
lates a business object outside the control sphere of the workflow applica-
tion.
- 196 - A Reference Meta Model for Audit Trail Data

Run Time Elements

At run time, process instances are created from the process models defined
in the build time phase. A process instance contains one or more activity
instances, which are presented to workflow participants for selection and exe-
cution. Note that an activity instance belongs to exactly one process
instance, whereas an activity (at the model level) may exist independent of a
process model, or may be reused in different process models. A work item is
the representation of a particular activity instance for a particular workflow
participant. While the activity instance contains run time information that
can be interpreted by the workflow engine, e. g. invocation parameters for an
associated application, the work item contains performance instructions for
potential workflow participants (candidate performers). Other run time ele-
ments, such as application functions or business object instances, have been
omitted from the diagram for reasons of clarity.598

Audit Trail (State Model)

Process instances, activity instances, and work items each are in exactly
one specific state at any given point in time (e. g., ready, assigned, started,
completed, terminated). For this reason, the state of a process instance
(activity instance, work item) is modeled as a ternary relationship between
the entity types process instance (activity instance, work item), state, and
time. The state of these entities may change over time. Transitions between
process, activity, and work item states are modeled as relationship types over
the respective state entities. This explication of state transitions can be used
for subsequent extensions, such as the modeling of transition constraints,
which restrict the space of state transitions to a limited number of legal state
transitions.
The modeling of time as an independent entity type allows for the specifi-
cation of time points and time periods.599 The structure relationship type
over the entity type time allows for the combination of different time con-
structs. For example, if an activity instance is repeatedly suspended and
resumed, the total suspend time of the activity can be computed through the
combination of the individual suspend times. The time identifier is used to
denote the type of temporal construct represented by the time entity (e. g.,
open-ended period, closed period, combined period). The audit trail of a

598.This omission reflects the principle of relevance as stated in the Guidelines of Modeling,
compare Becker, Rosemann, v. Uthmann (2000), p. 32.
599.
Refer to Becker, Schütte (1996), pp. 161-162, who use this notion of time for the modeling
of purchasing conditions in retail enterprises.
A Reference Meta Model for Audit Trail Data - 197 -

workflow management system records the state changes of the three entity
types process instance, activity instance, and work item.600

4.2.6 A Reference Data Structure for Audit Trail Information

Based on the findings of the exploratory analysis in section 4.2.2 and
4.2.3 we can now develop a reference data structure for audit trail informa-
tion. Figure 4-6 shows the reference meta model for audit trail data.

Overall Structure
An audit trail contains one or more events, but it may be empty as well. An
event occurs at a specific time. Several events may occur simultaneously. An
event is caused by an originator, who is either a workflow participant, or a work-
flow engine. Workflow participants cause events when they actively manipulate
the objects presented to them by the workflow engine. The workflow engine
causes system events, such as the change of a process instance attribute (e. g.,
if a process instance exceeds a deadline). An event is represented as a ternary
relationship type between the entity types time, event type, and workflow
object. It exhibits a strong relationship with the entity types originator and
audit trail, respectively.
An event describes the state change of exactly one affected workflow object.
A workflow object is either a process instance, an activity instance, or a work item.
An event can be classified as belonging to an event type, for example, the
event type “created” defines the class of events such as “activity instance
4711 created at 09:32:01 by user zur Muehlen” and “process instance 0815
created at 03:15:00 by workflow engine”. Two corresponding start and end
event types define a state. States may be nested to form a hierarchy, as
described in the states models in section 3.6.2 and section 3.6.3.

Dimension Clusters
The audit trail meta model in figure 4-6 is marked with several dimension
clusters, in order to illustrate which areas of the meta model can be refined
for further analysis. The entity type workflow participant is the anchor point
for the resource dimension. A workflow participant typically belongs to an orga-
nizational unit and covers a certain role. Navigating through the workflow
audit trail, a process analyst could use these relationships to group audit trail
entries by organizational context. For example, he or she could determine,

600.Note that some systems do not differentiate between activity instances and work items. In
these cases the states of the work item are represented in the states of the corresponding
activity instance.
- 198 - A Reference Meta Model for Audit Trail Data

Figure 4-5: Conceptual Workflow Meta Model

A Reference Meta Model for Audit Trail Data - 199 -

Figure 4-6: Reference Meta Model of Audit Trail Content

- 200 - A Reference Meta Model for Audit Trail Data

which activities were carried out by a specific department, or how many pro-
cess instances were initiated by a specific work group.
The workflow objects work item, activity instance, and process instance
form the process instance dimension. Within this dimension, audit trail entries
can be grouped according to the process hierarchy, i. e., all work items
belonging to a specific activity instance, and all activity instances belonging
to a specific process instance. Since the instantiation relationships between
activity instances and activity models are known, as are those between pro-
cess instances and process models, audit trail information can be further
aggregated to include multiple instances of the same process type.
Both activity instances and process instances may be associated with a
business object. This business object links the process-focused workflow audit
trail with the economically relevant objects manipulated during the execu-
tion of activity and process instances. The recursive business object structure
allows for the composition of complex business objects from elementary
business objects. This feature can be used to integrate otherwise unrelated
business objects that are manipulated during the enactment of different
activity instances into a more complex process object.

Database Structure
In order to implement the audit trail structure represented by the meta
model, a corresponding database table structure is needed. Figure 4-7 gives
an overview of the audit trail table structure. The top part of the diagram
contains the tables filled during the build time phase of the workflow appli-
cation. They contain information about the activity and process structure.
Below these tables, the work item, activity instance, and process instance
tables are shown, which are filled by the workflow engine at run time. The
lower half of figure 4-7 shows the core audit trail table structure, the audit
trail table being the central access point for audit trail analysis.
A Reference Meta Model for Audit Trail Data - 201 -

Figure 4-7: Audit Trail Table Structure

- 202 - A Conceptual Framework for Process Controlling

4.3 A Conceptual Framework for Process Controlling

4.3.1 A Taxonomy of Audit Trail Information

Information recorded in the workflow audit trail can be analyzed in dif-
ferent ways, depending on the organizational function and information
requirements of the recipient. Figure 4-8 shows a classification of different
analysis dimensions for audit trail information. The dimensions can be clas-
sified into attributes that relate to the way how audit trail information is pre-
sented to the recipient, and the content of the information presented to the
recipient.

Source: Extended from Blum (2002), p. 18.

Figure 4-8: Analysis Dimensions of Audit Trail Information

Presentation of Information
Focus
The focus of audit trail analysis can be either business-oriented or technology-
oriented. This orientation is determined by the role of the process analyst and
by goals supported by the results of the process analysis. A technology-ori-
ented analysis relates to information that reflects the performance of the
A Conceptual Framework for Process Controlling - 203 -

workflow management application, such as response times, number of con-

currently logged in users, or system behavior at different work loads. In
addition, technology-oriented analyses can yield information about software
components invoked during workflow execution. For example, the analysis
of concurrent invocations of the same application program can be used to
determine the number of licenses required to match the current software
usage patterns.
Presentation
Audit trail information may be presented actively by the workflow manage-
ment system or process controlling system, if alert functions are imple-
mented. An active presentation of audit trail information is also required, if
this information represents input data for other automated processes, e. g.,
the daily recurring generation of a process report. A passive presentation of
audit trail information can be found, if the user has to select the information
he or she is interested in, and has to initiate the presentation of the informa-
tion manually.
Timeframe
Audit trail information may either relate to processes that have been com-
pleted (aborted, or terminated, respectively), or relate to processes that are
currently active in the workflow management system. The analysis of active
processes can be used for predictive purposes, e. g., to determine the esti-
mated time of completion of a process instance, or to determine the current
workload of a group of process participants.601 Audit trail information relat-
ing to completed processes are typically analyzed at an aggregate level, in
order to identify generalizable properties of a particular process type.
Aggregation
Audit trail data can either be analyzed on the instance level, e. g. if for a par-
ticular process instance a proof of execution is required, or at the type or
model level, e. g., if trends of process metrics over time are of interest. For pro-
cess controlling purposes, audit trail information is typically aggregated over
several instances of the same workflow model. If process models are modi-
fied, the process analyst needs to maintain information as to which versions
of a process model are compatible for analysis, i. e., the process instances of
which process model versions can be combined and/or aggregated.

601.Compare, e. g., Panagos, Rabinovich (1997), who use audit trail information to raise pre-
emptive escalations, if the current workflow instance might exceed the maximum permitted
turnaround time.
- 204 - A Conceptual Framework for Process Controlling

The opportunity to model and change processes using a workflow man-

agement system is significantly easier than the adjustment of hard-coded
process logic in application systems. Therefore, over time, enterprises using
workflow applications will adjust these processes to match their changing
environment. The change of the process structure, e. g., the replacement of
an activity with another, results in a change of the audit trail data during pro-
cess enactment. If an analysis is to be performed across a collection of pro-
cess instances, in many cases only those instances will be relevant whose
execution path is identical, i. e., those instances where the set of activity
instances is identical, and that refer to the same activity model (version) at
the type level. Therefore, it is vital for the validity of the process warehouse
information to record the underlying workflow model variant for every
workflow instance.

Information Content
Data Scope
The scope of data analysis can be restricted to process information, include
associated business objects, or consider the entire enterprise as an analysis domain.
In the first case, the information stored in the audit trail provides all neces-
sary information to compute frequencies, time-related ratios, and other
information at the process and activity levels. The integration of business
object information requires the linking of activity instance information with
business object identifiers, as it has been proposed in the audit trail reference
meta model. This is only possible if key attributes of the business object(s)
are accessible for the workflow engine as workflow-relevant data. Therefore,
process designers have to consider process controlling requirements already
in the conceptual design phase of a workflow application.
If the analysis of enterprise level information is desired, it may be neces-
sary to compare process performance metrics across different departments.
In this case it is useful to provide an enterprise framework of related pro-
cesses. In the example of a divisional organization, a process analyst may
wish to compare purchasing processes from different departments.
Object
The central object for process analysis can be either an event, activity, process,
resource, or the associated business object. Analysis at the event level may be
used to identify processes with irregular operation. For instance, an analysis
of all “abort process” events will result in a list of all processes that did not
complete successfully. The activity level yields information about the effi-
ciency of task fulfilment, and may be used to compare similar activities in
different processes. If processes are the central object of analysis, path analy-
A Conceptual Framework for Process Controlling - 205 -

ses may provide insight about the distribution of business cases and resulting
resource requirements. Analysis at the resource level aims at identifying
organizational ratios or developments, such as learning curves for the execu-
tion of a single activity over time, or the productivity of a work group.602
The business object focus allows for a grouping of processes in accordance
with the process object. This can be useful to analyze the performance of
processes with regard to certain process object attributes. For instance, an
analyst could compare the turnaround time of order processing workflow
instances for customers from Rhode Island with those instances for custom-
ers from New Jersey.
Process Scope
The process scope describes the part of a particular process model ana-
lyzed by the process controller. The finest level of granularity within this cat-
egory is the analysis at the activity level. The analysis of a larger part of a
process provides information about process segments. The study of the audit
trail at this level may be useful to determine the behavior of alternative pro-
cess paths, or alternative activity configurations. Analyzing the entire process
corresponds with the process object focus of the previously discussed cate-
gory. Finally, a process analyst may be interested in the behavior of an entire
process chain, which may be confined within the enterprise or stretch across
enterprise boundaries to include processes from suppliers and customers
(supply chain controlling). The analysis of process chains requires the identi-
fication of matching process instances, i. e., since the completion of one pro-
cess instance triggers the enactment of the next process instance, the audit
trail needs to contain information about the global process model, which
encloses all partial processes.603 Figure 4-9 illustrates the reach of different
process scopes.

602.
Note that the use of audit trail metrics for the measurement of organizational productivity
may be subject to legal restrictions. For instance, German privacy law provides strict rules
for the electronic storage and transmission of personal information. In order to satisfy
these restrictions, resource information in audit trail data can be locked from access,
deleted, or reduced. To reduce resource information it is possible, e. g., to aggregate process
performer data to the group level, while individual evaluations are not possible, or to anon-
ymize data by replacing actual values with proxy values. Compare Herrmann, Bayer (1999).
603.
The analysis of inter-organizational workflows on the basis of XML messages was analyzed
in the context of the AFRICA project at the University of Muenster, for more information
compare zur Muehlen, Klein (2000). Web Services Choreography languages that are used to
specify cross-organizational processes use the concept of correlation keys to identify matching
process fragments across different systems and/or business partners.
- 206 - A Conceptual Framework for Process Controlling

Figure 4-9: Activity, Segment, and Process Level Analysis

4.3.2 Process Monitoring versus Process Controlling

Process Monitoring
Process monitoring deals with the analysis and representation of process
instances at run time. Using monitoring information, workflow administra-
tors and process managers can manipulate the behavior of current workflow
instances and react to problems that arise during process enactment. Fur-
thermore, process monitoring is used to improve the responsiveness of an
organization to customer inquiries. When the current state of a process
instance can be determined with ease, customer inquiries such as “Who is
handling customer order 4711?” can be answered efficiently. For the individ-
ual workflow participant, process monitoring provides the ability to identify
those colleagues that worked on a particular case, if there are open issues
that need to be resolved. Figure 4-10 shows the monitoring of an online
order while it is being processed by the vendor.
A Conceptual Framework for Process Controlling - 207 -

Figure 4-10: Monitoring of an E-Commerce Order

Process monitoring beyond single process instances can be used to pre-

dict staffing requirements. If the average processing times of activities allow
for a forecasting of pending activity instances in the near future, the number
of active process instances as well as the current activity instances allow the
short-term prediction of staffing requirements. Combined with the ability of
workflow management systems to prioritize work items according to the
case attributes and the age of the case (i. e., the idle time of a pending case),
process monitoring can help companies maintain a consistent level of cycle
times even during seasons with high workloads.
The importance of workload transparency can be illustrated using the
case of a German insurance company. Due to a proposed change in tax leg-
islature, life insurances policies were subject to additional taxation if the pol-
icy was signed on or after January 1st, 2000. This announcement led to a
fourfold increase in life insurance applications during the second half of
1999. The staff at the life insurance department worked overtime to handle
the unusual amount of applications, neglecting all other cases that were not
new applications. As a result the structure and age of the remaining cases
was unknown and customers complained about the long time it took the
insurance to get back to them with regard to their inquiries. This situation
could have been avoided if a workflow management system had tracked of
all cases and prioritized those cases that were older than a certain threshold.
- 208 - A Conceptual Framework for Process Controlling

Under certain conditions it is desirable not to expose the detailed process

structure to the party monitoring a certain process instance. An example is
the presentation of workflow data to process participants outside of the
organization where the process instance is executed in, e. g., customers, sup-
pliers, or government agencies. Figure 4-10 shows the web display of an
ordering process at an e-commerce web site. Even though the internal pro-
cesses are much more complex, only four steps are displayed to the user.
This business state differs from the actual process state in the way that it is an
abstracted state model of the underlying process state model (NAEF et al.
call these state models shadow processes604). Figure 4-11 shows an example
of the abstraction level between the actual process state and a business state.

Figure 4-11: Process State and Business State

The four activities in section B and the two activities in section C are
combined into the single business states B’ and C’, respectively, whereas the
activities A, D, and E appear at the same level of granularity in the business
state model. In the (internal) process instance, activity A has been completed
and one activity of segment B is currently active. The corresponding busi-
604.
Refer to Naef, Schuler, Schuldt (2001), p. 90f.
A Conceptual Framework for Process Controlling - 209 -

ness state model shows state B’ as active, abstracting from the underlying
details of the “Manufacture Product” process segment. In the simplified
example, the business state model can only contain the same number of
states or fewer states than the process state model (n:1 relationship), since it
is derived from the workflow states exclusively. If context data is taken into
account - such as the values of certain process relevant variables, the coarse
states of the business state model may be refined into sub-states.
Besides organizational process monitoring, workflow management sys-
tems typically provide facilities for technical monitoring. Technical process
monitoring deals with the supervision of parameters such as response times,
system load, and the like. With regard to technical monitoring, workflow
management systems do not differ from complex application systems that
are managed through commercial packages such as TIVOLI605 or CAN-
606
DLE . Figure 4-12 shows a screenshot of the technical monitoring facility
of the Carnot Process Engine. Besides the current numbers of active users,
processes, and activities, the system also displays the number of pending
processes and activities, i. e., those processes and activities that have been
accepted by a user but that have not been completely processed.

Process Controlling
Process controlling deals with the ex-post analysis of process instance
audit trail data. Here the single process instances are aggregated according to
different evaluation dimensions schemes. Process controlling is useful for
the detection of long-term developments in process enactment and the
review of already existing workflow implementations. In order to identify
deviations in process execution, audit trail data is often compared to target
data which is derived from corresponding business process models. The
goal of workflow-based process controlling is the improvement of future
process enactment, thus its effects are more long-lasting than the results of
process monitoring.
Whereas the target audience for process monitoring data consists mainly
of administrative IT personnel (for technical information) and workflow
participants (for organizational information), process controlling data is
mainly used for enterprise controlling purposes. An isolated analysis of audit
trail data provides information about the temporal aspects of process execu-
tion. In addition, information about resource utilization on the process and
activity level can be derived. However, information about the business con-
text of a particular process cannot be answered by looking at audit trail data
605.
See the Tivoli Corporation Homepage: www.tivoli.com.
606.
See the Candle Corporation Homepage: www.candle.com.
- 210 - A Conceptual Framework for Process Controlling

Figure 4-12: Technical Monitoring Facility

alone. This is due to the fact that the audit trail of most workflow manage-
ment systems does not contain application data that is processed in work-
flow instances.

4.3.3 Information Requirements and Information Supply

Information requirements of decision makers at different levels of the
corporate hierarchy are not uniform. They depend on the management
objective pursued by the individual manager, the method chosen to analyze
the current situation, and the organizational measure used to realize the
management objective.

Management-driven Information Requirements

Figure 4-13 shows the relationship between managerial objectives and
available information sources as a meta model. Managerial tasks of the
enterprise are distributed among different management levels, which are
A Conceptual Framework for Process Controlling - 211 -

Figure 4-13: Management Levels and Information Sources

arranged in a hierarchy. Each management level has at least one management
objective, i. e., the set of corporate goals that the specific management level
has to achieve. In order to realize these objectives, one or more organizational
measures can be implemented. In order to decide which measure is suitable
for a given situation, a manager requires information about the situation of
the company, denoted as business information. The sum of all management
- 212 - A Conceptual Framework for Process Controlling

objective-specific information requirements with all management objectives

for a particular management level determine the management-level-specific infor-
mation requirements. For the implementation of organizational measures, man-
agers need information to determine the degree to which individual
organizational measures have been realized. Combined with the information
demand specific to a manager’s objectives we can determine the amount and
type of information required. This can provide an indication of the degree to
which an organizational measure supports a management objective.607

Technology-driven Information Supply

Company-specific business information that is required by managers to
perform their decision processes is generated by the operative system of the
enterprise. Functional application systems and process-oriented workflow audit
trails provide a basic set of business data for analysis purposes. This data is
integrated, transformed and analyzed through different controlling instruments.
The result of this transformation is the set of business information available
for managerial purposes.

4.3.4 Integration of Audit Trail Data with other Data Sources

From an enterprise controlling perspective, workflow audit trail data is
one of several information sources and needs to be integrated into a com-
mon repository for evaluation purposes. Examples of other information
sources that include in such a repository include financial statements from
an accounting system or log files from a transaction processing system. In
order to enhance the business value of audit trail data, it needs to be inte-
grated with such external data sources in order to enable the analysis of pro-
cesses using attributes that are not part of the workflow audit trail.
Data warehouses are a common repository for this kind of data, and elab-
orate on-line analytic processing tools exist that support the controlling
recipients during the evaluation of information stored in a data warehouse.
INMON defines a data warehouse as the subject-oriented, integrated, nonvol-
atile and time-variant collection of data in support of manager’s decisions.608

607.
An example for an organizational measure is the restructuring of a department and the cre-
ation of teams-oriented work places instead of individual work places. If the management
objective is to increase the resource efficiency, the success of the organizational measure
could be assessed by examining the staff productivity before and after the restructuring.
Measuring the employee satisfaction may also yield information about the success of the
organizational measure, but does not relate to the original goal, since employee satisfaction
contributes to the goal of motivation efficiency, but not necessarily resource efficiency.
608.
Compare Inmon (1996), p. 33; Inmon, Imhoff, Sousa (2001), p. 8.
A Conceptual Framework for Process Controlling - 213 -

INMON relates the subject-orientation of a data warehouse to the design of

data structures for evaluation purposes, which are modeled after the infor-
mation requirements of decision makers. BECKER argues that the basic data
model of a data warehouse has to be designed independent of evaluation
purposes, since the future information requirements are hard to predict.609
This argument is reflected in RIEBEL’S approach to cost accounting, where
he separates the purpose-independent computation of basic ratios, and the
subsequent purpose-oriented computation of evaluations.610 The practice of
data warehouse design supports the latter argument. The central data repos-
itory is enhanced by subject-specific data marts, which contain a purpose-
oriented selection of the main data warehouse data.611
The integration aspect of data warehouses refers to the consistent naming
of variables, encoding of attributes, and adjustment of different measure-
ments used by different operative information systems. This integration is
typically achieved through the implementation of an extraction, transforma-
tion, and loading (ETL) layer, which offers access to different operational
data sources, and provides functionality to cleanse, map, and convert the
contents of these data sources into a consistent repository.
Data in the data warehouse is not subject to changes, as opposed to data in
operative transaction processing systems, since analytical queries on the data
warehouse are read-only operations. For this reason, the data structure of a
data warehouse needs to be optimized for this type of operation, and may
differ from the data structure of operative data stores.
The aspect of time-variance relates to the fact that a snapshot of the opera-
tive data stores at a specified point in time is transferred to the data ware-
house and marked with a timestamp.612 If new data is transferred to the data
warehouse, existing data is not removed but remains available, and the newly
transferred snapshot is marked with a new timestamp. This enables the anal-
ysis of data changes over a longer period of time.
Due to the popularity of data warehouses as a foundation of the corpo-
rate management information system infrastructure, the integration of
workflow audit trail data into existing data warehouses provides the oppor-
tunity of enhancing existing controlling infrastructures with the ability to

609.Compare Becker (2002).

610.Compare Riebel (1994).
611.Inmon, Imhoff, Sousa (2001), p. 8, define a data mart as “a customized subset of data from
the data warehouse tailored to support the specified analytical requirements of a given busi-
ness unit.”
612.
Compare Holten (1999), p. 41.
- 214 - A Conceptual Framework for Process Controlling

analyze the business process perspective of an enterprise. This task is non-

trivial and we discuss its implications in the following section.

Extraction, Transformation and Loading

During the extraction, transformation, and loading phase of data ware-
house development, source data is converted into a format that fits the over-
all data warehouse schema. Depending on the format of existing audit trail
logs, which could exist in form of database records or flat file structures, an
appropriate import mechanism needs to be deployed. Using a transforma-
tion algorithm, the proprietary schema of the audit trail data has to be con-
verted into the data base schema of the data warehouse. If several workflow
management systems are used within the enterprise, the individual audit trail
schemas have to be converted into a consolidated schema that is suitable for
the analytical purposes of the data warehouse.

Data Mart Structures for Audit Trail Information

The content of the workflow audit trail is characterized by its detailed
notion of time. In the reference data model, this is one identifying element
of the triple relationship time - workflow object - event type, which defines the
core of the workflow audit trail. For this reason, audit trail data is naturally
suitable for a variety of temporal analyses.613 Figure 4-14 illustrates the rele-
vant temporal aspects using the example of an activity instance.

Source: Compare Rieke (2002), p. 63.

Figure 4-14: Relevant Temporal Aspects for Workflow Analysis

613.The importance of time-based analyses is noted e. g. by Karlof, Ostblom (1993), p. 56:

“Time [...] is an excellent unit for measuring the performance of an organization. Short
throughput times contribute to customer-perceived quality and most of all to productivity.”
A Conceptual Framework for Process Controlling - 215 -

Since the workflow audit trail provides timestamps, but not aggregate
information about time periods, it is useful to create a time-oriented data
mart from raw audit trail data. The data structure of such a data mart con-
tains a central fact table that contains derived information about its activity
instances. Figure 4-15 shows the data structure for a time-oriented data
mart. The central fact table contains references to the activity model of
which the activity instance was derived from, the process instance that
formed the context for the activity instance, the resource, i. e., the workflow
performer that executed the activity, and the business object that was manip-
ulated in the context of the activity. The facts contained in the fact table are
the calculated values for different processing time categories. The calculation
of these ratios is a non-trivial task, since each activity instance may have
switched an arbitrary number of times between the states idle and process-
ing. As a result, the values for idle time and processing time may be com-
posed of an arbitrary number of processing time fractions and suspend time
fractions, respectively.
The references to activities, processes, resources, and business objects
opens access to four evaluation dimensions that can be used to formulate
queries. For example, the business object perspective may be used to deter-
mine those activity instances that exhibit the longest idle time for a specific
type of business object. The result of this evaluation may give an indication
about popular and unpopular business cases, if the workload for the individ-
ual business cases is similar. The resource dimension may be used to deter-
mine the learning curve of an organizational unit for the processing of a
specific activity. If the processing times of activity instances continuously
decrease, the presence of certain learning effects can be assumed.,
In addition to time-oriented analyses of workflow audit trail data, fre-
quency-oriented analyses can be applied to workflow audit trails as well. A
data mart for frequency-oriented analyses contains facts about the availabil-
ity, start, and completion of activity instances. It facilitates queries such as
“How many activity instances of the type review account overdraft were per-
formed in the last three months?”
As stated in figure 4-8, the analysis dimensions for audit trail information
may select activities as well as process segments as the central object of anal-
ysis. Theoretically, an activity-centered data mart can be used to compute
process-specific ratios that relate to the parent process of an activity. This
can be achieved through a traversal along the process dimension, which
yields the process instance related to the activity instance in the fact table.
Ultimately, the originating process model can be determined as well. In order
to allow meaningful analyses, all activity instances from each process
- 216 - A Conceptual Framework for Process Controlling

Figure 4-15: Time-oriented Activity Data Mart

instance would need to be identified and their atomic facts would need to be
integrated into the evaluation. Since such an operation has a significant neg-
ative impact on the performance of process-related queries, it is advisable to
create separate data marts for the execution of process- and activity-related
queries.

Synchronization of Business Objects and Workflow Data

The audit trail format of some commercial workflow management sys-
tems does not contain references to the business object that has been
manipulated in a workflow instance. Still, meaningful evaluations in a busi-
ness context almost always require the workflow audit data to be linked to
some business object information, such as the customer account involved,
or the merchandise handled during the process. In our previous research
prototype PISA we manually added an activity to the workflow model that
created a database record containing the ID of the process instance and the
identifier of the business object that would later be manipulated by the
derived workflow instance. This artificial integration of workflow and busi-
A Cybernetic Model for Process Controlling - 217 -

ness data enables the navigation from a particular process instance to the
business context and allows for the application of high-level evaluation
methods. Nevertheless, the integration of audit trail information with busi-
ness object information can create a number of problems for the data ware-
house designer:
„ Not every workflow context is a business object. If a workflow instance uses
data from different application systems, an artificial wrapper for this
particular data set has to be created for every workflow instance in
order to make this data set accessible through a unified business
object ID (BOID). While object-oriented workflow management sys-
tems (e. g., those running inside a java-based application server) pro-
vide native support for this encapsulation concept, most stand-alone
workflow systems are designed to work with different applications
without an additional data wrapper.
„ Business data is subject to side-effects. The notion of application data was
introduced by the WfMC to make sure that mission critical data was
not locked from use while being used by a potentially long-running
workflow instance. Reverting this view, application data can be manip-
ulated by applications outside of the workflow context at any time. If
audit trail data is transferred through a batch procedure once a day,
intermediate changes to the business object data are invisible to the
data warehouse. To avoid this problem, business data would need to
be transferred to the data warehouse as soon as the workflow instance
treating this business object is finished. For performance reasons, this
may not always be feasible.

4.4 A Cybernetic Model for Process Controlling

In the previous section we have discussed the data offered by a workflow
audit trail for analytical purposes, evaluation possibilities for this kind of
data, and strategies for the technical integration of the resulting information
in the corporate controlling infrastructure. In the following section we dis-
cuss the role of workflow-based process controlling in the context of the
cybernetic controlling model that was presented in chapter 2.

4.4.1 Cybernetic Business Process Control

The analysis of audit trail data for controlling purposes takes place mainly
as ex-post evaluation, since data is only made available after the associated
processing has taken place in the workflow system. Workflow-based control-
ling thus represents a feedback-oriented controlling instrument.
- 218 - A Cybernetic Model for Process Controlling

In a study about control cycles for industrial product development pro-

cesses, V. UTHMANN and TUROWSKI have proposed a hierarchical model of
feedback cycles.614 They describe the role of the workflow management sys-
tem as the recorder of measurements, and discuss the implementation of
control directives at both the automated and the manual level. The inner-
most feedback cycle describes the automatic regulation of business pro-
cesses, e. g., if the workflow management system allocates pending work
items to different workflow participants depending on their current work-
load. The second feedback cycle relates to the interactive management of
running workflow instances. Monitoring information is provided to human
recipients who can actively change parameters of the running process
instances. For instance, if the deadline of an activity instance is exceeded, the
workflow management system notifies the process manager who in turn
reassigns the pending work item to an experienced process participant. The
third feedback cycle is used to continuously improve the workflow model.
Monitoring information is provided to workflow designers, who adjust the
workflow model in a persistent fashion, i. e., the changes to the model affect
all future workflow instances derived from this model.615 Figure 4-16 shows
the structure of the hierarchical feedback cycle model.

Source: v. Uthmann, Turowski (1996), p. 15.

Figure 4-16: Business Process Control Cycles

614.
Compare v. Uthmann, Turowski (1996).
615.
The change of workflow models at run time and the propagation of changes to running
workflow instances has been discussed, e. g., by Weske (1999). Marshalling change to run-
ning workflow instances requires an evaluation, whether a change would leave these
instances in a consistent state and is a non-trivial exercise.
A Cybernetic Model for Process Controlling - 219 -

Even though the structure of the hierarchical feedback cycle model

addresses the roles of different recipients, it is focused exclusively on the use
of workflow information, i. e., it does not explain the role of workflow infor-
mation at different management levels within the context of other informa-
tion sources. In addition, the model suggests that changes are always applied
to the workflow model or running workflow instances, but not to the sur-
rounding organization or its policies. The system theoretic view of the com-
pany shown in figure 2-5 on page 36 illustrates that strategic control does
not directly impact the operative processes of the enterprise. Instead strate-
gic control influences the behavior of operative management through the
definition of policies and resource contingencies. Operative management in
turn evaluates implementation alternatives for the strategic program and
chooses an alternative that suits the current state of the operative system
best.
Taking these findings into account, we can now rework the feedback
model by V. UTHMANN and TUROWSKI, and detail the role of different man-
agement layers. Figure 4-17 shows the system of feedback cycles, which is
based on the cybernetic feedback model discussed in chapter 2. A workflow
management system produces controlling information (i. e., audit trail data),
which is fed into three separate controlling units: Automated feedback, operative
management and control, and strategic management and control. In the following sec-
tions we discuss these controlling units in detail.

4.4.2 Automatic Feedback Cycle

The automatic feedback cycle is confined to the boundaries of the work-
flow management application itself. Based on formally encoded quality
parameters the feedback module analyzes the data supplied by the workflow
engine and regulates the execution of running workflow instances. These
quality parameters include values such as maximum activity duration, maxi-
mum work load for workflow participants, or work distribution strategies.
The measures implemented by the feedback unit are restricted to the capaci-
ties available to the workflow management system. For example, the feed-
back unit can reassign a pending work item to a workflow participant
different from the original recipient, in order to balance the overall work
load, but it cannot create resource capacity, since this parameter is deter-
mined at the operative management and control level. While the feedback
unit may not perform structural changes to the workflow model, it may
manipulate attributes of process and activity models as well as workflow par-
ticipants. An example for this type of feedback control is the experience-
based scheduling of workflow participants.
- 220 - A Cybernetic Model for Process Controlling

Figure 4-17: Cybernetic Feedback Model of Process Controlling

Example: Experience-based Scheduling based on Audit Trail Data

Workflow audit trail data contains information about the performer of an
activity instance. This data can be used to compute a level of experience that
is proportional to the number of activity instances performed by a workflow
participant, or the activity cycle time for this participant compared to the
average completion time across all performers. Using this metric, the
dynamic evolution of human resource capabilities can be traced by deter-
mining a level of expertise from the analysis of recorded audit trail data.
A Cybernetic Model for Process Controlling - 221 -

Even well structured processes, such as those found in so-called produc-

tion workflow environments, may exhibit a considerable number of excep-
tions that need to be handled. In the usual case, a workflow administrator or
the manager of the current process participant is notified if a workflow or
activity instance raises an exception. The importance of efficient exception
handling is pointed out by SACHS, who states that the efficiency of work is
less dependent on the structure of the workflow, but rather depends on the
exception handling capabilities of the resources involved in the process.616
Instead of using a hard-coded exception handling scheme, the workflow
engine can assign work to a more experienced performer when an exception
occurs. This way, line managers are less concerned with troubleshooting
activities, such as the reassignment of work items, and can perform activities
of higher business value. The economic impact of a qualification-adequate
task assignment can be measured using the hedonic wage model developed
by SASSONE.617 The hedonic wage model states that the overall cost of labor
increases, if workers perform tasks that lie below their level of qualification
and spend less time on tasks they have originally been hired for. Information
stored in the workflow audit trail can be used to monitor the value of atomic
labor units according to the hedonic wage model, and to adjust the assign-
ment policies accordingly. PISA II and III both implemented an evaluation
module for the hedonic wage model.

Figure 4-18: Sample Performer Profiles

The use of workflow audit trail data to assess user capabilities can also be
used to differentiate resource qualifications, e. g., with regard to processing
time or acceptance rate. Depending on the overall priority of a process it
might be desirable to assign an activity to the actor with the least average

616.
Compare Sachs (1995).
617.
Compare Sassone (1986).
- 222 - A Cybernetic Model for Process Controlling

processing time for the specific activity at hand. In other cases it may be nec-
essary to minimize the lead time until a work item is processed by a work-
flow participant. An analysis of the audit trail data can provide the resource
management component of the workflow system with relevant information
for this decision. An example for resource assignments using the level of
experience as an assignment factor is given in figure 4-18.

4.4.3 Operative Management and Control

The operative management and control loop starts with the supply of
workflow audit trail data to the operative management and control unit.
Since the amount of data required at this level differs from the raw data pro-
cessed by the feedback unit, filters have to be used which allow the presenta-
tion of relevant information objects only. An example for such filtering is
the elimination of technical events from the audit trail data stream, such as
system recovery messages written by the workflow engine to document the
state of the workflow system itself.
The operative management and control loop can be triggered manually,
(e. g., if a workflow application is reviewed on a regular basis), or automati-
cally (e. g., if predefined threshold values are exceeded and the workflow sys-
tem sends an alert message). The capabilities of operative management and
control are twofold with regard to changes at the workflow level. On the one
hand, parameters of the feedback unit can be controlled through the opera-
tive management and control entity (e. g., a different target cycle time for an
activity is defined). On the other hand, adjustments at the workflow system
level can be performed. These adjustments include the (re-)modeling of pro-
cesses, changing invoked applications, and changing the organizational struc-
ture. Within this portfolio, the operative management and control unit has
the capability to adjust resource contingencies available to the workflow
engine, which also represent the limits of the measures the automatic feed-
back unit can implement. In order to fulfil this task successfully, the opera-
tive management and control unit requires information about available
resource capacities and resource utilization from the workflow management
system.

Example: Workflow-driven Activity-based Costing

One suitable evaluation method for this purpose is activity-based costing.
According to COOPER and KAPLAN, an activity based costing model is “an
economic map of the organization’s expenses and profitability based on
organizational activities.”618
618.
Kaplan, Cooper (1997), p. 79.
A Cybernetic Model for Process Controlling - 223 -

Activity-based costing systems address the following questions:619

„ Which activities are being performed by the organizational resources?
„ How much does it cost to perform these activities and the aggregate
business processes?
„ Why does the organization need to perform activities and business
processes?
„ What fraction of each activity is required for the organization’s prod-
ucts, services, and customers?
The workflow audit trail can provide activity-based costing systems with
actual quantities of activity execution, in addition to a qualified list of the
resources used to perform these activities. The combination of workflow
audit trail data, operative learning and control, financial reporting, and activ-
ity-based costing systems supplies members of the operative management
and control unit with timely and precise information about resource utiliza-
tion in their domain of control. This information can be extended with
information about the processes and activities these resources have partici-
pated in. Figure 4-19 illustrates this combination.
Based on the results of an activity-based costing analysis, managers at the
operative level can adjust resource quantities to match the actual resource
requirements reported by the workflow-enhanced activity-based costing sys-
tem. Examples for such adjustments are the hiring of new staff members,
the training of staff members to perform different or additional tasks, or the
reduction of staff capacity.

4.4.4 Strategic Management and Control

The highest level of feedback control is the strategic management and
control feedback cycle. The strategic management and control unit receives
select information from the workflow audit trail. For this reason, a second
filter on top of the operative management and control filter needs to be
implemented at this stage. Additional information is delivered from the
operative management and control unit. This level reports to the strategic
management and control unit if the second-level feedback cycle escalates,
e. g., if adjustments of resource capacities don’t have the desired or predicted
effect on operative process performance.
Strategic management and control determines the framework for the
activities at the operative level and communicates these guidelines to the

619.
Compare Cooper, Kaplan (1992); Kaplan, Cooper (1997); Cooper, Kaplan (1998).
- 224 - A Cybernetic Model for Process Controlling

Source: Compare Cooper, Kaplan (1998), p. 115.

Figure 4-19: Integration of Workflow Audit Trail Data
operative management and control system through guidelines, specific tar-
gets, budgets, and other constraints and directives. In order to perform stra-
tegic management and control effectively, information about the actual
performance of the organization in light of the strategic goals is necessary.
This information can be gathered using performance measurement systems
that include both internal and external information. The subject of perfor-
mance measurement is the implementation and validation of the competitive
strategy selected by an enterprise.620

620.
Compare Eccles (1991).
A Cybernetic Model for Process Controlling - 225 -

Example: Workflow-driven Balanced Scorecard

A popular performance measurement framework is the Balanced Score-
card by KAPLAN and NORTON, which is shown in figure 4-20.621 The Bal-
anced Scorecard provides four different perspectives, which contain
objectives, measures, targets, and initiatives. The perspectives group these
elements with focus on the financial performance, internal business pro-
cesses, customer perception, and internal learning and growth. Each per-
spective should contain a balanced selection of leading and lagging
indicators that are related to the measures defined in the individual perspec-
tive. Lagging indicators reflect the operative behavior of the company from
an ex-post perspective. A typical example of this are financial ratios that
reflect the performance of a business unit over a previous time period. Lead-
ing indicators provide information about the current behavior of the organi-
zation and are used to determine, whether the company works in
compliance with the strategy goals or against these goals.

Source: Kaplan, Norton (BSc) (1996), p. 9.; Kaplan, Norton (Use) (1996), p. 76.
Figure 4-20: Balanced Scorecard Framework

621.
Compare Kaplan, Norton (BSc) (1996); Kaplan, Norton (2001).
- 226 - Summary

On the implementation side, the Balanced Scorecard is not restricted to

the strategic management level. It can be decomposed hierarchically in order
to communicate the business strategy from the strategic to the operative sys-
tem of the enterprise.622 On the basis of strategic targets, objectives, and ini-
tiatives, operative strategies have to be developed by the operative
management and control unit to satisfy these targets.
A workflow-based controlling system can provide source information for
the computation of ratios within the strategic Balanced Scorecard. Through
the timely provision of process and activity frequencies, process indicators
within the internal business process perspective can be determined with
ease. Also, certain aspects of the customer perspective, such as faithfulness
to negotiated deadlines, and the adherence to process design principles such
as “one face to the customer” can be evaluated using workflow audit trail
data. If customer-facing activities can be identified at the model level, a com-
parison of process participants in relation to different customer IDs or cus-
tomer types provides information on the number of different contact
persons a customer has to deal with across a process, or the profile of all
customers that a particular member of the organization is responsible for.

4.5 Summary
In this chapter, we have illustrated the design requirements of a work-
flow-driven process controlling system. Starting with a review of related
work, we have analyzed three commercial workflow management systems
and compared the content of their audit trails to a reference model provided
by the Workflow Management Coalition. Based on the findings of this anal-
ysis we have developed both a reference model for workflow application
concepts, and a reference model for workflow audit trail data. We have
shown, how this data can be integrated into data warehouse infrastructures,
and have illustrated the usefulness of workflow audit trail information using
a cybernetic feedback model that differentiates between automated feed-
back, operative management and control, and strategic management and
control. In the next chapter we discuss the application of these concepts in
an industry case, and show the implementation of these concepts in a
research prototype.

622.
Compare Wiese (2000).
Process Controlling in an Insurance Company - 227 -

5 Process Controlling: A Case Study and A Prototype

The first four chapters of this book looked at process controlling from a
conceptual perspective. We first established the role of process controlling in
contemporary organizations. We then looked at technological developments
in the area of process management and workflow automation that lay the
groundwork for the creation of process controlling systems by providing
detailed audit trail data. Based on our findings, we outlined the requirements
for the design and application of workflow-driven process controlling sys-
tems. In this chapter we take a look at process controlling in corporate prac-
tice. We describe the case of an insurance company that realized deficiencies
in its existing management information infrastructure, and illustrate the
expected benefits this company hopes to derive from a process controlling
solution. Furthermore, we describe the design and features of the process
controlling prototype Cassandra, a system that implements some of the con-
cepts outlined earlier in this book.

5.1 Process Controlling in an Insurance Company

5.1.1 Case Outline

In the following section we outline the practical relevance of our frame-
work by means a case study. The case study was conducted at a medium-
sized German insurance company with 1,200 employees between the years
2000 and 2002. The company had conducted an enterprise-wide business
process re-engineering project two years before the case study started. Over
the course of this project, the major business processes in the insurance-spe-
cific departments of the company had been documented and grouped into
process clusters. These clusters were compared with application functional-
ity provided by the company’s mainframe computer system. Processes were
split along the different application transactions that were part of the insur-
ance applications. Based on self-statements by employees, average process-
ing times for activities were documented using a basic resolution of minutes.
Based on the identified activity structure and the estimated resource utiliza-
tion in these activities, an activity-based costing system (ABC) had been
implemented, which was used for enterprise controlling purposes.
After the new system had been in use for two years, it was apparent that
the underlying business processes had evolved. In addition, information that
was required for managerial purposes, such as capacity planning during sea-
sonal peaks in workload, could not be obtained from the existing system. A
project was set up to investigate the potential benefits of a workflow-driven
process information system for the company.
- 228 - Process Controlling in an Insurance Company

5.1.2 A First Assessment

In a first step, existing metrics and measurement points were analyzed in
interviews with corporate management, enterprise controllers, and division
heads. It became apparent that quantifying the actual workload in the organi-
zation was very difficult, since traces of work only existed if transactions in
the mainframe system were executed. Work that did not result in these elec-
tronic transactions did not show up in the controlling applications. Cus-
tomer inquiries by phone and mail - which were very frequent - typically
triggered some follow-up activity, but rarely resulted in a traceable transac-
tion in the mainframe system. Thus, the actual frequency and distribution of
process instances was known only to department heads from their personal
experience. Log files from the transaction processing system reported the
frequency of individual transactions over a period of time (e. g., how often
transaction “issue homeowner’s policy” was executed in March 2004). They
were thus decoupled from the actual content of transactions, and did not
allow the drill down into individual cases, or the identification of customer
properties that might affect processing times.
The current workload of staff members could not be determined auto-
matically. On a regular basis, department heads would conduct a walk-
through and ask their staff members to count open cases on their desks, but
this information was not easily available for overall scheduling purposes.
Work would be dispatched based on the personal assessment of the depart-
ment heads with some formal rules in place, such as case allocation based on
the first letter of the customer’s surname. Proxy relationships were formal-
ized, but the documentation of an open case was not easily accessible, as
paper files had to be physically transferred between desks, and supporting
documents had to be requested from a document archive, with a turnaround
time of one day. Staff scheduling was rather conducted based on experience
from prior seasons, but not guided by accurate metrics.
Another shortcoming was the lack of information about processing times
and process instance states. Incoming mail was date-stamped, and this date
could be entered during further mainframe processing, but this information
was optional and frequently not maintained by the employees. It was there-
fore unclear, how much time elapsed on average between the receipt of a
piece of mail and subsequent processing in the receiving department. Lost
or misplaced cases and documents were not unusual, and typically these
cases were brought to the attention of managers by customers, who inquired
about the status of their requests.
Process Controlling in an Insurance Company - 229 -

Based on this assessment, the benefits of using process audit trails for
monitoring and controlling purposes were evaluated. Table 5-1 shows the
difference in auditing accuracy without and with audit trail information.

Without Audit Trail Data With Audit Trail Data

Recording of mail receipt date through Recording of detailed process and activity
manual input (optional) turnaround times, independent of user inter-
action

Recording of transactions within mainframe Recording of all process instances

applications (processes without transaction
processing content are not recorded)

Computations based on average values (e. g., Computations based on detailed analysis of
average duration of all car accident claims in time and volume
one year)

No drill-down possibilities to the level of indi- Drill-down possible

vidual business cases

Table 5-1: Audit Trail-based Information Availability

5.1.3 Information Availability

The existing activity-based costing system (ABC) was analyzed in the next
stage of the project. The goal of this phase was to identify the suppliers of
raw data for further analysis, the transformation operations performed on
this data, and the results that were delivered by the ABC application. The
results of this analysis are summarized in figure 5-1. The system was charac-
terized by a variety of data feeds, most of which were transferred and con-
verted in a manual, laborious process. The activity structure of the existing
business processes was transferred manually from Excel sheets into the pro-
prietary ABC-system.623 These activities were derived from the results of the
re-engineering project mentioned above, and it was clear to the parties
involved that the activity structure might no longer represent the current
state of the enterprise processes - but since no alternative information was
available, the existing activity breakdown was utilized. Transactions from the
operational insurance application systems were assigned to activities accord-
ing to a transformation schema developed during the re-engineering project.
Since the number of transactions were recorded in the legacy system, the log
files were used to compute the actual number of activities performed over a
given period of time. These frequencies were then mapped to the activity
structure, which was not a 1:1 representation of the application transactions,
since some transactions mapped to multiple activities. In these cases, a pro-

623.
The enterprise controlling department relied on BOC Adonis for some activity-based cost-
ing evaluations, and SAS as a platform for a data warehouse application, which was being
deployed as the project went underway. Remarkably, the responsibility for the data ware-
house application lay within the hands of a single programmer/analyst - for a company with
3,000 employees.
- 230 - Process Controlling in an Insurance Company

Figure 5-1: Controlling Data Flow (As-Is)

prietary BPR factor was used (also known as “magic number”). Using esti-
mated processing times per activity, the required personnel capacity for each
activity per period was computed using a custom Excel application. In
essence, the frequencies from the transaction logs were multiplied with the
self-assessed processing times, and adjusted using another BPR factor. The
result of this transformation process was the (more or less realistic) resource
capacity used per activity execution, which served as one input factor for the
ABC application. This data was combined with the documented activity
structure from the re-engineering project. In addition, the activity frequen-
cies recorded in the transaction logs were imported into the ABC application
(thus being reused for a different purpose than determining personnel
capacities). Financial information about resource valuation was derived from
the internal accounting information system. This information was collected
in a data warehouse application and manually transferred into the ABC-sys-
tem. Based on these input factors, the enterprise controller would then cal-
culate process and activity costs, such as the average cost for maintaining a
renter’s insurance per year.
The entire data transfer and evaluation process was time-consuming and
error-prone, due to many media-breaks and manual transfers. In addition the
results of the ABC-system did not reflect the actual operations at the insur-
ance company. For example, only those processes appeared in the ABC-sys-
Process Controlling in an Insurance Company - 231 -

tem that resulted in the execution of a traceable transaction in the

transaction processing system. Using this information, the ABC system doc-
umented 20,000 cases of customers cancelling their car insurance policies
annually. However, the actual number of cancellations was much higher,
since many customers could be convinced to revoke their cancellation
request before it was put into effect using the transaction processing system.
These cases did not appear in the ABC-system, even though their processing
took time and consumed resources. Furthermore, changes to the transaction
processing system jeopardized the link between the BPR activity structure
and the transactions recorded in the application log files, since the measured
amount of time necessary to perform a certain activity was tied to the trans-
action used within the activity. When a transaction was changed, the process-
ing time for the associated activity was affected, but this change was not
documented anywhere. However, one crucial assumption stuck out that
questioned the validity of the entire ABC evaluation: Full resource utiliza-
tion. The calculation of resources necessary to perform an activity was based
on the assumption that all employees of the company worked productively
during the time they were being paid for. There were attempts to soften this
assumptions through the use of the BPR factors mentioned above, but slack
time or idle times were not taken account in the ABC calculations. Instead,
available resource capacity was determined by multiplying the number of
employees in a department with their work time. This number was then
divided by the number of recorded activity instances in this department, and
the result was regarded as the actual amount of resources utilized per activity
execution.

5.1.4 Improvement through Workflow Data Integration

Based on the findings of the ABC system analysis, the project team
designed the concept for a workflow-driven process warehouse. This data
warehouse was designed to be used as a data feed for the existing ABC appli-
cation. The resulting scenario is illustrated in figure 5-2. The central compo-
nent of the workflow-based controlling infrastructure is a process
warehouse that serves as the central repository for all operational data that
needs to be evaluated. The workflow audit trail is transferred into the data
warehouse using two separate import filters. On the one hand, process and
activity information is extracted for process perspective evaluations. On the
other hand, resource information, i. e., which resource performed which
activity, is extracted for resource perspective evaluations. In order to provide
semantic information about the overall process composition, process and
activity structure information is transferred into the data warehouse at build
- 232 - Process Controlling in an Insurance Company

Figure 5-2: Controlling Data Flow (Target)

time. It should be noted that manual activities (e. g., phone calls) will still not
be recorded by the new system.
In order to link audit trail information to operational business data, two
tables need to be maintained separately. One table contains the relationship
between individual process instances and the insurance policies or customer
records involved in these process instances. Using this table as a bridge, a
drill-down operation from a single process to the customer who triggered
the process is possible. The other custom table contains the relationship
between workflow participants and the internal cost accounting structure of
the enterprise. Since workflow management systems in most cases record a
technical ID of the performer who executed an activity, this table is neces-
sary to valuate the resources used in a process with the relevant cost factors.

5.1.5 Preconditions for Implementation

The realization of the process warehouse will enable the insurance com-
pany to evaluate its operational business processes in a timely fashion and
with a much higher level of accuracy than it is currently possible. However, a
process warehouse depends on the existing of supporting infrastructure, in
particular a workflow application that provides source information.
Process Controlling in an Insurance Company - 233 -

In the case at hand, no workflow management system was in place that

could supply this information. Furthermore, most documents that entered
the organization were moved between workstations in paper form, since no
document management infrastructure existed. Archival of documents was
performed on microfilm, and the only electronic documents in existence
were incoming e-mails and faxes, which were handled through a Lotus
Notes application. This led to two alternative implementation strategies:
„ The process controlling system could be deployed as an add-on to the
existing mainframe applications. However, since documents would
still be routed in their paper form, employees would be required to
enter additional information manually, in order to capture process and
activity start and end time, and to maintain a link between process
instances and the physical documents. Clearly, this solution would
have increased the workload of individual employees and was there-
fore undesirable.
„ A new document management and workflow infrastructure would
need to be deployed prior to the establishment of a process control-
ling system. This would require a change in existing, paper-based
work practices, and require a substantial infrastructure investment,
since this infrastructure would have to be deployed enterprise-wide.
In light of some rogue document handling projects that had already
sprung up within the company, the CIO decided that this was the
desirable alternative, and chartered the project team with the mission,
to evaluate, select, and deploy a document management and workflow
infrastructure.
Even though the financial benefits that can be derived from an improved
process controlling infrastructure were difficult to determine, the projected
financial savings from the introduction of a document management and
workflow infrastructure were sufficient to provide a return on investment
just three years after the deployment of the new system. The ability to per-
form detailed process analyses was perceived as an added benefit of the new
infrastructure and work packages for the realization of the process control-
ling infrastructure were added to the project plan.
- 234 - Cassandra - A Process Controlling Prototype

5.2 Cassandra - A Process Controlling Prototype

In order to validate the concepts presented in this book, we have imple-
mented a process controlling system prototype named Cassandra, which
offers temporal and frequency-based analyses of audit trail data, support for
an activity-based costing module, and a Balanced Scorecard module. The
system was implemented in JAVA using Enterprise Java Beans technology.
The evaluation components can be deployed in an application server that
supports the JAVA 2 Enterprise Edition (J2EE) standard. While the process
warehouse and the evaluation components were built from scratch, audit
trail information for the Cassandra prototype was derived from the commer-
cial workflow management system Carnot Process Engine. Results from the
design of the prototype were evaluated by the workflow vendor and an
extended and revised version of the prototype is being offered as an addi-
tional component by Carnot.

5.2.1 Overall System Architecture

The data model of the Cassandra system is implemented in a relational
database (Oracle), which is accessed via JDBC. This database hosts the audit
trail of the Carnot Process Engine, as well as a variety of data marts for eval-
uation purposes. Each evaluation method is realized as an individual EJB
component, and consists of a visualization component and a configuration
component. For instance, the architecture of the Cassandra activity-based
costing module is illustrated in figure 5-3. The Carnot Process Engine pro-
vides process model information and audit trail data for the process ware-
house. The existing enterprise cost center structure is manually extracted
from a data source, such as an ERP system or a cost accounting system. This
information is maintained in the process warehouse through the ABC con-
figuration component. In a fully integrated system architecture, this informa-
tion would be integrated into the process warehouse through ETL adapters
that access the relevant source systems. To keep the prototype simple, the
manual integration of cost center data was chosen for the Cassandra proto-
type.
Cassandra - A Process Controlling Prototype - 235 -

Source: Compare Blum (2002), p. 74.

Figure 5-3: Architecture of the Cassandra ABC Module
- 236 - Cassandra - A Process Controlling Prototype

5.2.2 Data Structure

The evaluation database consists of the raw audit trail data provided by
the Carnot Process Engine, and two data marts for the activity-based costing
component, and the Balanced Scorecard evaluations, respectively.

Source: Compare Rieke (2002), p. 120.

Figure 5-4: Cassandra Activity Instance Partial Fact Table
Cassandra - A Process Controlling Prototype - 237 -

Figure 5-4 shows one of the fact tables of the underlying data warehouse.
To simplify the design of different data marts, a number of fact tables that
exist at the data warehouse level were replicated and modified at the data
mart level. In addition, model attributes of the Carnot Process Engine were
modified in order to accommodate necessary attributes for the computation
of activity-based costing results. These attributes include information such
as the average cost of resource utilization or the relationship between work-
flow participants and the cost center structure of the enterprise. In a full
implementation, the latter attribute would need to be maintained and syn-
chronized with the cost center structure that is typically maintained in sepa-
rate financial accounting systems.

5.2.3 Evaluation Methods

The Cassandra prototype contains two evaluation modules: An activity-
based costing module, and a balanced scorecard component.

Activity-based Costing Module

The activity-based costing module provides functionality for a financial
valuation of processes and activity. It supports the allocation of administra-
tive overhead and direct labor to cost centers depending on the resources
utilized during the performance of activity instances. In order to perform the
necessary calculations, the corresponding workflow model needs to be
enhanced with some ABC-relevant information. For example, the cost cen-
ters of the enterprise that are typically defined in cost accounting applica-
tions have to be maintained within the ABC module. Figure 5-5 shows the
creation of a new cost center for a particular planning period.
For each cost center, a cost factor for the utilization of corporate IT
infrastructure as well as a cost factor for the utilization of office space can be
allocated. In addition, other expenses necessary for the operation of the cost
center can be allocated as well (e. g., location-specific taxes or fees). The cost
centers that were created using this module can then be linked to activities
and subsequent analyses can be performed. Figure 5-6 shows a cost center
report for the cost center shown in figure 5-5.
The activity “Schadensakte aufbereiten” (maintain customer claim record)
was executed twice during the evaluation period and resulted in process cost
of 3680 units. During the same period, two overhead activities were per-
formed (“Abteilung leiten” = manage department, and “Mitarbeiter schulen” =
train employees). These activities are computed as a fraction of process
activity related work, and cost allocated to these activities are presented in
the lower half of the screen.
- 238 - Cassandra - A Process Controlling Prototype

Source: Blum (2002), p. 112.

Figure 5-5: Definition of a Cost Center
The ABC module allows for the definition of target cost per period and
activity execution. In the example, the execution of one instance of activity
“Schadensakte aufbereiten” is valued at 1980 units, exceeding the defined
target cost of 1600 units.

Source: Blum (2002), p. 114.

Figure 5-6: Cost Center Report
Cassandra - A Process Controlling Prototype - 239 -

Balanced Scorecard Module

The second evaluation module implemented in the Cassandra prototype
provides a variety of evaluations for Balanced Scorecard applications. The
Balanced Scorecard module uses the process warehouse to provide process-
related information within individual perspectives of the Balanced Score-
card. Similar to the ABC component, this module is split into a configura-
tion component and an evaluation component. The configuration
component supports the definition of individual Balanced Scorecard per-
spectives, in order to support domain-specific configurations. For each per-
spective, different metrics, ratios, and measures can be defined. In order to
facilitate the flexible specification of metrics, SQL statements can be used, as
shown in figure 5-7.

Source: Compare Rieke (2002), p. 110.

Figure 5-7: Definition of Ratios for Evaluation Perspectives

The screenshot shows a Balanced Scorecard configuration with two met-

rics defined in the customer perspective: On-time delivery, and customer sat-
isfaction. On-time delivery is defined as the measured deviation from the
delivery time that was negotiated with the customer. Using a specific data
mart for this purpose, a process analyst can specify this definition using a
SQL statement. The validity of this statement can be evaluated using a defi-
nition tester function. This is realized through the check button in figure 5-7.
Upon activation of this button, the configuration module executes the query
entered by the used and displays the results in a separate window. An exam-
ple of this statement evaluation is shown in figure 5-8.
- 240 - Cassandra - A Process Controlling Prototype

Source: Rieke (2002), p. 108.

Figure 5-8: Measure Definition Tester
For each user-defined measure, specific value targets with a related due
date can be specified, as shown in figure 5-9. These targets can be used in
the evaluation view to overlay actual measurements with target values, and
enable a quick evaluation of performance trends.

Source: Compare Rieke (2002), p. 110.

Figure 5-9: Target Definition Tab

Another component of the configuration module, the relationship defini-

tion tab, enables users to define positive or negative relationships between
measures and indicators. Furthermore, the Balanced Scorecard designer can
provide an explanation for the chosen relationship, which can later be dis-
played to the process analyst. The example in figure 5-10 shows relationship
between process cycle time, on-time delivery, and customer satisfaction.
Cassandra - A Process Controlling Prototype - 241 -

Source: Compare Rieke (2002), p. 113.

Figure 5-10: Relationship Definition Tab
In the evaluation view, the process analyst can choose to view the individ-
ual ratios in a separate window. For instance, figure 5-11 shows the develop-
ment of the cycle time for a loan process over time. The horizontal line at
the bottom of the window indicates the target processing time, the two
curves represent the actual processing time and a weighted mean value for
the process cycle time computed over the past 30 days. A mouse pop-up
provides users with detailed information about the process duration on a
specific day, if the user “hovers” over a particular point of the diagram.

Figure 5-11: Measurement Viewer

- 242 - Summary

5.3 Summary
In this chapter, we have illustrated the commercial interest in workflow-
based process controlling approaches by means of a case study. We were
able to clearly identify the business value of workflow-based process con-
trolling information by comparing the information derived from such an
infrastructure with an existing ABC application. However, we have also
shown that in many cases infrastructure investments may be necessary,
before the benefits of a process controlling infrastructure can be realized. In
order to demonstrate the validity our approaches, we have implemented a
research prototype. It should be noted that the prototype was intended as a
proof of concept, and has not been deployed in a commercial environment. It
has, however, influenced the implementation of a similar component by a
workflow vendor.
 - 243 -

6 Summary, Reflection, and Outlook

The goal of this book was the design and validation of a process control-
ling framework based on workflow audit trail information. Process-orienta-
tion has been discussed in the organizational literature for more than 70
years, however, the implementation of process-oriented organization struc-
tures has found widespread acceptance only within the last 15 years. While
the structuring of organizations along their processes has been extensively
discussed in scientific and popular publications, the operational realization
of process management and controlling, and the design of suitable manage-
ment information system support have received considerably less attention.
In order to bridge this gap, we have developed a methodical approach for
process-oriented controlling based on workflow audit trail data.
Based on a system theoretic view of organizations, we have identified dif-
ferent roles of management and controlling at the strategic and operative
level of organizations. We defined the goals and functions of process man-
agement and controlling and combined them with properties of process-ori-
ented organizations. Our findings led to the development of a comprehen-
sive process life-cycle.
Process management and controlling ensure the efficiency of operative
enterprise processes. At the strategic level, process controlling ensures that
all organizational processes cooperatively support the organization’s goals.
This purpose requires a unified process measurement framework. At the
operative level, process controlling ensures the efficiency and effectiveness
of individual process enactment. This task requires timely and precise infor-
mation about the operative behavior of business processes.
Workflow management systems support process-oriented organizations
through the automated coordination of activities, resources, application sys-
tems, and data along a formal workflow model. During the enactment of
workflow instances, audit trail data is produced. Audit trails precisely record
the execution of process and activity instances through the recording of
events. Even though an official standard for audit trail data exists, this stan-
dard has not been implemented by most workflow vendors. Furthermore,
the format of the current standard does not satisfy all requirements of a pro-
cess controlling system.
In order to overcome this dilemma, a reference meta model for workflow
audit trail data was constructed in an inductive fashion. We gathered data
through the study of commercial workflow systems and available standards,
and used the results of this analysis in the design of the reference meta
- 244 -

model. We were able to demonstrate the integration of audit trail informa-

tion based on this meta model into a generic process controlling infrastruc-
ture at the level of data integration. We discussed evaluation perspectives for
workflow-based controlling information, and created a cybernetic feedback
model for multi-level process management.
Through an exploratory case study of an insurance company we illus-
trated the relevance of the topic. Based on a detailed analysis of the existing
controlling infrastructure we were able to document the potential benefits of
a workflow-based process controlling infrastructure.
The feasibility of the proposed approach was demonstrated through the
implementation of a process controlling prototype, based on a process ware-
house. We documented the details of an activity-based costing module and a
Balanced Scorecard module, and thus illustrated the application of well
known controlling instruments to workflow audit trail information.

Evaluation
The contribution of the process controlling approach developed within
this book can be evaluated against empirically validated quality requirements
for controlling applications:624
„ Controlling has to start at the customer. The integration of information
from market partners into the process controlling infrastructure is an
important feature to enable early warning indicators (e. g., to forecast
and remedy delayed deliveries). The increasing use of workflow-based
web services allows companies to integrate audit trail information
from business-to-business processes with internal workflow audit
trails. In order to enable controlling across concatenated process
chains, global process models and matching correlation keys need to
be introduced, and an integration of different audit trail formats into a
unified schema is required. The audit data reference meta model
developed within this book provides a unified model of audit trail
information, regardless of the underlying workflow implementation.
„ Controlling has to take place in the heads of the employees. In order to raise the
awareness of process orientation among employees, monitoring and
controlling mechanisms should be accessible from the workplace of
every process participant. The communication of target values and
the continuous monitoring of process metrics enables process partici-
pants to evaluate the status of process and activity instances. They can

624.
Refer to Horváth, Seidenschwarz, Sommerfeldt (1993), p. 81.
 - 245 -

use performance indicators such as predicted completion time or on-

time performance. The process controlling framework presented in
this book reflects this through the active notification of workflow par-
ticipants in the case of target deviations as well as the presentation of
workflow information at the operative and strategic level.
„ Start immediately and improve continuously - especially processes. As soon as a
workflow-based application system is deployed within an organiza-
tion, audit trail data is available. Detailed controlling requirements
should be observed during the design of workflow models, but they
may also be added later on. Even simple time- and frequency-oriented
analyses on the basis of raw audit trail data provide valuable informa-
tion about the process performance of an organization. In chapter 4
we have presented a reference data model for a process warehouse.
This reference data model enables companies to integrate workflow
audit trail information into a corporate data warehouse, and subse-
quently create subject-oriented data marts.
„ Everybody needs to understand the control measures. Workflow management
systems coordinate operative activities. The metrics derived from
audit trail data relate to these activities, creating an immediate link
between the actual workplace of the individual employee and the
information derived from a process controlling system. The process
controlling framework developed in this book addresses different
information requirements at different levels of the corporate hierar-
chy.
„ Controlling needs to overcome departmental boundaries. A workflow-based
process controlling system provides information along the flow of
work, across functional boundaries. This way, it contributes to the cre-
ation of a holistic controlling infrastructure. Through the implementa-
tion of the Cassandra prototype and the integrated activity-based
costing module, we have demonstrated that workflow-based process
controlling not only supports the logical process structure of the
enterprise, but that it can also be used to document product- or cus-
tomer-related activity clusters.
„ Controlling must not end at the company gates. The analysis of internal busi-
ness processes is a first step toward a workflow-based supply chain
controlling that integrates information from trading partners into a
consistent process database.625 In order to achieve the cross-enter-

625.
Compare Holten et al. (2002).
- 246 -

prise integration of process controlling data, a unified data format for

audit trail information is necessary, as well as a methodical framework,
how this information can be evaluated. The reference meta models
provided within this book contribute to this goal.

Outlook
Workflow-based process controlling as a research domain can be
approached from a technical, organizational, or methodical perspective.
The development of a purpose-independent audit trail data model is the
first step toward a process-oriented data warehouse design. The systematic
development of purpose-oriented data marts for process-related analysis
methods as well as the analysis of performance issues for process-oriented
queries is a research topic closely related to this book. As such, it is beyond
the scope of this book.
The application of the hierarchical Balanced Scorecard at a process level
enables the communication and translation of strategic plans across different
levels of the corporate hierarchy. While the integration of process informa-
tion into a strategic Balanced Scorecard was outlined in an upstream fashion,
the definition of process-oriented initiatives and related measures in a down-
stream fashion remains subject of future research.
The increasing use of workflow technology as an integration technology
for web services creates the opportunity to capture process information
across organizational boundaries. The integration of process controlling data
along the supply chain, and related questions of privacy, security, data and
method integration between business partners, as well as the consolidation
of processes views across the supply chain remain some of the most chal-
lenging research questions within the area of process controlling.
 - 247 -

References

A
van der Aalst, W. M. P.: The Application of Petri Nets to Workflow Management.
Journal of Circuits, Systems and Computers, 8 (1998) 1, pp. 21-66.
van der Aalst, W. M. P.; van Dongen, B. F.; Herbst, J.; Maruster, L.; Schimm, G.;
Weijters, A. J. M. M.: Workflow Mining: A Survey of Issues and
Approaches. Data and Knowledge Engineering 47 (2003) 2, pp. 237-267.
van der Aalst, W. M. P.; van Hee, K.: Workflow Management. Models, Methods,
and Systems. Cambridge, MA, USA 2002.
van der Aalst, W. M. P.; ter Hofstede, A. H. M.; Kiepuszewski, B.; Barros, A. P.:
Workflow Patterns. Distributed and Parallel Databases, 14 (2003) 3, pp.
5-51.
van der Aalst, W. M. P.; ter Hofstede, A. H. M.: YAWL: Yet Another Workflow
Language. QUT Technical Report FIT-TR-2003-04. Queensland Univer-
sity of Technology, Brisbane, Australia, 2003.
van der Aalst, W. M. P.; Song, M.: Mining Social Networks: Uncovering interaction
patterns in business processes. In: International Conference on Business
Process Management (BPM 2004). Eds.: Wil M. P. van der Aalst, et al.,
Potsdam, 2004.
Abbott, K. R.; Sarin, S. K.: Experiences with workflow management: Issues for the
next generation. In: Proceedings of the 1994 Conference on Computer
Supported Cooperative Work. Ed.: T. W. Malone. Chapel Hill (NC) 1994,
pp. 113-120.
Ackoff, R.: Management Misinformation Systems. In: Management Science, 11
(1967) 4, pp. B147-B156.
Ackoff, R.: Toward a system of systems concepts. In: Management Science, 17
(1971) 11, pp. 661-671.
Adam, D.: Planung und Entscheidung. 4th edition, Wiesbaden 1996.
Adam, D.: Produktions-Management. 9th edition, Wiesbaden 1998.
Ader, M.: Organisational Modeling Impact on WfMC Specifications. Appendix to
WfMC Document Nr. WFMC-TC-1016o. White Paper, Brussels 1996.
Agrawal, R.; Gunopulos, D.; Leymann, F.: Mining Process Models from Workflow
Logs. In: Advances in Database Technology. Proceedings of the 6th
International Conference on Extending Database Technology. Eds.: H.-J.
Schek, et al. Valencia 1998, pp. 469-483.
Agrawal, R.; Leymann, F.; Roller, D.: Deriving process models for workflow man-
agement systems from audit trails. European Patent Application
98111410.1, filed by: IBM GmbH. Germany 1998. [1998-06-22]
Aissi, S.; Malu, P.; Srinivasan, K.: E-Business Process Modeling: The Next Big
Step. In: IEEE Computer, 35 (2002) 5, pp. 55-62.
Albert, H.: Treatise on Critical Reason. Princeton (NJ) 1985.
- 248 -

Alonso, G.; Agrawal, D.; El Abbadi, A.; Mohan, C.; Günthör, R.; Kamath, M.:
Exotica/FMQM: A persistent message-based architecture for distributed
workflow management. In: Proceedings of the IFIP WG 8.1 Workgroup
Conference on Information Systems, Development for Decentralized
Organizations (ISDO 95). Trondheim 1995.
Alonso, G.; Agarwal, D.; Abbadi, A. E.; Kamath, M.; Günthör, R.: Advanced
transaction models in workflow contexts. In: Proceedings of the 12th
International Conference on Data Engineering (ICDE-12). Ed.: S. Y. W.
Su. New Orleans (LA) 1996, pp. 574-581.
Alonso, G.; Agrawal, D.; El Abbadi, A.; Mohan, C.: Functionalities and Limita-
tions of Current Workflow Management Systems. In: IEEE Expert, 12
(1997) 5.
Alonso, G.; Günthör, R.; Kamath, M.; Agrawal, D.; El Abbadi, A.; Mohan, C.
Exotica/FMDC: A Workflow Management System for Mobile and Dis-
connected Clients. In: Distributed and Parallel Databases - An Interna-
tional Journal, 4 (1996) 3, pp. 229-247.
Alonso, G.; Reinwald, B.; Mohan, C.: Distributed data management in workflow
environments. In: 7th International Workshop on Research Issues in
Data Engineering (RIDE ’97). Birmingham 1997.
Alonso, G.; Mohan, C.: Workflow Management Systems: The Next Generation of
Distributed Processing Tools. In: Advanced Transaction Models and
Architectures. Eds.: S. Jajodia, L. Kerschberg. Boston (MA) 1997, pp. 32-
65.
Alonso, G.; Schek, H.-J.: Database Technology in Workflow Environments. Data-
base Research Group, Institute for Information Systems, ETH Zürich.
Zürich 1996.
Anthes, G. H.: Sabre Flies To Open Systems. Computerworld, 38 (2004) 22, pp.
21-25.
Anthony, R. N.: Planning and Control Systems: A Framework for Analysis. Grad-
uate School of Business Administration, Harvard University. Boston
(MA) 1965.
Ariba Inc.; IBM Corp.; Microsoft Corp.: UDDI Technical White Paper. September
6, 2000. Available at www.uddi.org. [Download 2002-06-02]
Arkin, A.: Business Process Modeling Language. Proposed Final Draft. BPMI.org,
San Mateo, CA 2002.
Ashby, W. R.: An Introduction to Cybernetics. London 1956.
Attinger, M. L.: Workflow: A Technology Primer. In: ARMA Records Manage-
ment Quarterly, 30 (1996) 3, pp. 3-8.
Audi, R. (Ed.) The Cambridge Dictionary of Philosophy. Cambridge 1999.
 - 249 -

B
Bair, J. H.: Office Automation Systems: Why some work and others fail. Proceed-
ings of the Stanford University Conference. Stanford University, Center
for Information Technology. San Jose (CA) 1981.
Band, D. C.; Scanlon, G.: Strategic control through core competencies. Long
Range Planning 28 (1995), pp. 102-112.
Barbará, D.; Mehrotra, S.; Rusinkiewicz, M.: INCAs: Managing Dynamic Work-
flows in Distributed Environments. In: Journal of Database Manage-
ment, 7 (1996) 1, pp. 5-15.
Bartholomew, D.: A Better Way To Work. Workflow systems, when combined
with business reengineering, speed tasks and processes. In: Information
Week. 1995-11-09, pp. 32-40.
Bashein, B. J.; Markus, M. L.; Riley, P.: Business Process Reengineering: Roles for
Information Technologies and Information Systems Professionals. In:
Proceedings of the 1994 computer personnel research conference on
Reinventing IS: managing information technology in changing organiza-
tions. Alexandria (VA) 1994, p. 308.
Bastos, R.; Dubugras, D.; Ruiz, A.: Extending UML Activity Diagram for Work-
flow Modeling in Production Systems. In: Proceedings of the 35th
Annual Hawaii International Conference on System Sciences (HICSS'02).
Ed.: R. Sprague, Jr. Waikoloa (HI) 2002.
Becker, H.-J.: Controller und Controlling. Grafenau 1984.
Becker, J.; Bergerfurth, J.; Hansmann, H.; Neumann, S.; Serries, T.: Methoden zur
Einführung Workflow-gestützter Architekturen von PPS Systemen.
Working Paper No. 73. University of Münster, Department of Informa-
tion Systems. Münster 2000.
Becker, J.; Berning, W.; Kahn, D.: Projektmanagement. In: Prozessmanagement.
3rd edition Eds.: J. Becker, M. Kugeler, M. Rosemann. Berlin et al. 2002,
pp. 17-45.
Becker, J.; Kahn, D.: Der Prozess im Fokus. In: Prozessmanagement. Ein Leit-
faden zur prozessorientierten Organisationsgestaltung. Eds.: J. Becker, M.
Kugeler, M. Rosemann. Berlin et al. 2002, pp. 3-15.
Becker, J.; Rosemann, M.; Schütte, R.: Grundsätze ordnungsmäßiger Modellierung.
In: Wirtschaftsinformatik, 37 (1995) 5, pp. 435-445.
Becker, J.; Rosemann, M.; von Uthmann, C.: Guidelines of Business Process Mod-
eling. In: Business Process Management: Models, Techniques, and
Empirical Studies. Eds.: W. van der Aalst, J. Desel, A. Oberweis. Berlin et
al. 2000, pp. 30-49.
Becker, J.: Strukturanalogien in Informationsmodellen - Ihre Definition, ihr
Nutzen und ihr Einfluß auf die Bildung von Grundsätzen ord-
nungsmäßiger Modellierung (GoM). In: Wirtschaftsinformatik '95. Ed.:
W. König. Heidelberg 1995, pp. 131-150.
Becker, J.; Schütte, R.: Handelsinformationssysteme. Landsberg/Lech 1996.
- 250 -

Becker, J.; Vossen, G.: Geschäftsprozeßmodellierung und Workflow-Management:

Eine Einführung. In: Geschäftsprozeßmodellierung und Workflow-Man-
agement. Modelle, Methoden, Werkzeuge. Bonn, Albany 1996, pp. 17-26.
Becker, J.; von Uthmann, C.; zur Muehlen, M.; Rosemann, M.: Identifying the
Workflow Potential of Business Processes. In: 32nd Hawaii International
Conference on System Sciences (HICSS 1999). Ed.: R. Sprague, Jr. Wailea
(HI) 1999.
Becker, J.; zur Muehlen, M.; Gille, M.: Workflow Application Architectures: Classi-
fication and Characteristics of workflow-based Information Systems. In:
Workflow Handbook 2002. Ed.: L. Fischer. Lighthouse Point (FL) 2002,
pp. 39-50.
Becker, M.; Vogler, P.; Österle, H.: Workflow-Management in betriebswirtschaftli-
cher Standardsoftware. In: Wirtschaftsinformatik, 40 (1998) 4, pp. 318-
328.
Becker, J.: Forschung in schnellebiger Zeit - eine Sicht der Wirtschaftsinformatik.
Manuscript submitted for publication. Münster 2002.
Beer, S.: Diagnosing the System for Organizations. Wiley. Chichester 1985.
Bertino, E.; Ferrari, E.; Atluri, V.: The Specification and Enforcement of Authori-
zation Constraints in Workflow Management Systems. ACM Transac-
tions on Information and System Security, 2 (1999) 1, pp. 65-104.
Bird, A.: Thomas Kuhn. Princeton (NJ) 2000.
Bleicher, K.: Das Konzept Integriertes Management. Visionen - Missionen - Pro-
gramme. 6th edition, Frankfurt, New York 2001.
Blum, B.: Workflow-basierte Prozesskostenrechnung - Konzeption und proto-
typische Realisierung eines Controlling-Moduls für die J2EE Plattform.
Diploma Thesis. Department of Information Systems, University of
Münster. Münster 2002.
Blumenthal, R.; Nutt, G. J.: Supporting unstructured workflow activities in the
Bramble ICN system. In: Proceedings of conference on Organizational
computing systems. Milpitas (CA) 1995, pp. 130-137.
Bock, A.: Dokumenten-Management-System (DMS). In: Handwörterbuch der
Wirtschaftsinformatik. 4th edition. Eds.: P. Mertens et al.. Berlin et al.
2001, 157-158.
Bode, J.: Der Informationsbegriff in der Betriebswirtschaftslehre. ZfbF, 49 (1997)
5, pp. 449-468.
Boehm, B. W.: A spiral model of software development and enhancement. In:
IEEE Computer, 21 (1988) 5, pp. 61-72.
Böhm, C.; Jacopini, G.: Flow Diagrams, Turing Machines And Languages With
Only Two Formation Rules. In: Communications of the ACM, 9 (1966)
5, pp. 366-371.
Böhm, M.: Entwicklung von Workflow-Typen. Berlin et al. 2000.
Bolcer, G. A.; Kaiser, G.: SWAP: Leveraging the Web to manage workflow. In:
IEEE Internet Computing, 3 (1999) 1, pp. 2-5.
 - 251 -

Bonifati, A.; Casati, F.; Dayal, U.; Shan, M.-C.: Warehousing Workflow Data: Chal-
lenges and Opportunities. Proceedings of the 2001 Conference on Very
Large Databases (VLDB ‘01). Rome, Italy 2001.
Bonner, A.: Workflow, transactions and datalog. In: Proceedings of the 18th ACM
Symposium on Principles of Database Systems (PODS'99). Philadelphia
(PA) 1999, pp. 294-305.
Bouzeghoub, M.; Fabret, F.; Matulovic-Broqué, M.: Modeling the Data Warehouse
Refreshment Process as a Workflow Application. In: Proceedings of the
International Workshop on Design and Management of Data Ware-
houses (DMDW '99). Eds.: S. Gatziu, et al. Heidelberg 1999, pp. 6.1-6.12.
BPMI.org: Business Process Modeling Language (BPML). Working Draft 0.4.
Business Process Management Initiative. Alameda (CA) 2001. [2001-03-
08]
Braun, G. E.; Beckert, J.: Funktionalorganisation. In: E. Frese (Ed.): Handwörter-
buch der Organisation. 3rd edition, Stuttgart 1992, col. 640-655.
Brede, H.: Prozeßorientiertes Controlling wandelbarer Organisationsstrukturen.
In: zfo, 65 (1996) 3, pp. 154-158.
Brede, H.: Prozessorientiertes Controlling wandelbarer Strukturen. In: Controlling,
9 (1997) 5, pp. 326-333.
Bronner, R.: Komplexität. In: Handwörterbuch der Organisation. Ed.: E. Frese.
Stuttgart 1992, pp. col. 1121-1130.
Burns, J. C.: The evolution of office information systems. In: Datamation, 23
(1977) 4, pp. 60-64.
Bussler, Ch.; Jablonski, S.: Policy Resolution for Workflow Management. In: Pro-
ceedings of the 28th Hawaii International Conference on Systems Sci-
ences (HICSS 1995), Maui (HI) January 1995.
Bussler, Ch.: Analysis of the Organization Modeling Capability of Workflow-Man-
agement-Systems. In: Proceedings of the PRIISM '96 Conference, Maui
(HI) January 1996.
Bussler, Ch.: Organisationsverwaltung in Workflow-Management-Systemen, Deut-
scher Universitäts-Verlag, Wiesbaden 1998. also: PhD dissertation, Uni-
versity of Erlangen-Nuremburg, 1997.
Bussler, C.: P2P in B2BI. In: Proceedings of the 35th Hawaii International Confer-
ence on System Sciences (HICSS 2002). Ed.: R. Sprague, Jr. Waikoloa
(HI) 2002.
Butchvarov, P.: Metaphysics. In: The Cambridge Dictionary of Philosophy. Ed.: R.
Audi. 2nd edition, Cambridge 1999, pp. 563-566.
Butchvarov, P.: Metaphysical Realism. In: The Cambridge Dictionary of Philoso-
phy. Ed.: R. Audi. 2nd edition, Cambridge 1999, p. 563.
Button, G.; Harper, R. H. R.: Taking the organization into account. In: Technology
in working order: Studies of work, interaction and technology. Ed.: G.
Button. London 1993.
- 252 -

C
Carlsen, S.: Conceptual Modeling and Composition of Flexible Workflow Models.
PhD Thesis, Information Systems Group. Department of Computer and
Information Science. Faculty of Physics, Informatics and Mathematics,
Norwegian University of Science and Technology. Trondheim 1997.
Carnot AG: Carnot Integrative Workflow Management Developer’s Guide. Ver-
sion 2.0 Beta, March 25th 2002. Frankfurt 2002.
Casati, F.: Models, Semantics, and Formal Methods for the design of Workflows
and their Exceptions. Ph.D., University of Milan. Milan 1998.
Casati, F.; Ceri, S.; Paraboschi, S.; Pozzi, G.: Specification and implementation of
exceptions in workflow management systems. ACM Transactions on
Database Systems (TODS), 24 (1999) 3, pp. 405-451.
Casati, F.; Ceri, S.; Pernici, B.; Pozzi, G.: Deriving active rules for workflow enact-
ment. In: 7th Intl. Conf. on Database and Expert Systems Application.
1996, pp. 94-115.
Casati, F.; Dayal, U.; Sayal, M.; Shan, M.-C.: Business Process Intelligence. HP
Laboratories Technical Report HPL-2002-119. Palo Alto 2002.
Casati, F.; Fugini, M.; Mirbel, I.: An Environment for Designing Exceptions in
Workflows. In: Information Systems, 24 (1999) 3, pp. 255-273.
Casati, F.; Stano, S.; Fugini, M.; Mirbel, I.; Pernici, B.: Using patterns to Design
Rules in Workflows. IEEE Transactions on Software Engineering, 26
(2000) 8, pp. 760-785.
Cerami, E.: Web Service Essentials. Distributed Applications with XML-RPC,
SOAP, UDDI & WSDL. Sebastopol (CA) 2002.
Chaffey, D.: Groupware, Workflow and Intranets. Reengineering the enterprise
with collaborative software. Boston (MA) 1998.
Chapple, E. D.; Sayles, L. R.: The Measure of Management. Designing Organiza-
tions for Human Effectiveness. New York (NY) 1961.
Christensen, E.; Curbera, F.; Meredith, G.; Weerawarana, S.: Web Services
Description Language (WSDL) 1.1. W3C Note 15 March 2001. W3C.
2001. Available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[2001-03-15]
Chroust, G.; Bergsmann, J.: Umfrage: Workflow. Eine Momentaufnahme über
Verbreitung, Einsatz und Meinungen über Workflow in den deut-
schsprachigen Ländern. Wien, München 1995.
Cooper, R.; Kaplan, R. S.: Activity-based systems: Measuring the costs of resource
usage. In: Accounting Horizons, 6 (1992) 3, pp. 1-13.
Cooper, R.; Kaplan, R. S.: The promise -and peril- of integrated cost systems. In:
Harvard Business Review, 76 (1998) 4, pp. 109-120.
Crowston, K.: A Taxonomy Of Organizational Dependencies and Coordination
Mechanisms. White Paper 174, Massachusetts Institute of Technology,
Center for Coordination Science. Cambridge (MA) 1994.
 - 253 -

Curbera, F.; Goland, Y.; Klein, J.; Leymann, F.; Roller, D.; Thatte, S.; Weer-
awarana, S.: Business Process Execution Language for Web Services, Ver-
sion 1.0. BEA, IBM, Microsoft, 2002. Available at http://www.ibm.com/
developerworks/library/ws-bpel/ [2002-07-31]

D
Date, C. J.: An Introduction to Database Systems. 6th edition, Reading (MA) 1995.
Davenport, T. H.: Process Innovation. Reengineering Work through Information
Technology. Boston (MA) 1993.
Davenport, T. H.: The fad that forgot people. In: Fast Company, 1 (1995) 1, p. 70.
Davenport, T. H.: Reengineering a Business Process. In: Harvard Business School
Note, 9-396-054 (1995), pp. 1-16.
de Michelis, G.; Dubois, E.; Jarke, M.; Matthes, F.; Mylopoulos, J.; Schmidt, J. W.;
Woo, C.; Yu, E.: A Three-Faceted View of Information Systems. In:
Communications of the ACM, 41 (1998) 12, pp. 64-71.
de Michelis, G.; Grasso, M. A.: Situating conversations within the language/action
perspective: the Milan conversation model. In: Proceedings of the confer-
ence on Computer supported cooperative work. Chapel Hill (NC) 1994,
pp. 89-100.
Deiters, W.; Gruhn, V.: Managing Software Processes in MELMAC. In: Proceed-
ings of the 4th Workshop on Software Development Environments. Irv-
ine (CA) 1990.
Deming, W. E.: Out of the Crisis: Quality, Productivity and Competitive Position.
Cambridge 1992.
Derzteler, G.: Prozeßmanagement auf Basis von Workflow-Systemen: Ein integri-
erter Ansatz zur Modellierung, Steuerung und Überwachung von
Geschäftsprozessen. Lohmar, Köln 2000.
Dessler, G.: Organization theory. Integrating structure and behavior. 2nd edition,
New York et al. 1986.
Dinkhoff, G.; Gruhn, V.; Sallmann, A.; Zielonka, M.: Business Process Modelling
in the Workflow-Management Environment Leu. In: Entity-Relationship
Approach - Proceedings of the ER’94 Conference. Ed.: P. Loucopoulos.
Machester 1994, pp. 46-63.
Dourish, P.: Process descriptions as organisational accounting devices: the dual use
of workflow technologies. In: Proceedings of the 2001 International
ACM SIGGROUP Conference on Supporting Group Work. Boulder
(CO) 2001, pp. 52-60.
Dourish, P.; Holmes, J.; MacLean, A.; Marqvardsen, P.; Zbyslaw, A.: Freeflow:
Mediating Between Representation and Action in Workflow Systems. In:
Proceedings of the 1996 Conference on Computer Supported Coopera-
tive Work (CSCW '96). Ed.: M. Ackerman. Boston (MA) 1996, pp. 190-
198.
- 254 -

Dresner, H.: Business Activity Monitoring: BAM Architecture. In: Gartner Sympo-
sium ITXpo. Ed.: Gartner Group, Cannes, 2003.
Dresner, H.; McCoy, D.: Business Activity Monitoring: BAM Scenario. In: Gartner
Symposium ITXpo. Ed.: Gartner Group, Orlando, FL, 2002.
DSTC; PrismTech: Submission to Workflow Process Definition. Object Manage-
ment Group. Framingham (MA) 2001.
Du, W.; Elmagarmid, A.: Workflow Management: State of the Art vs. State of the
Products. Software Technology Laboratory Report HPL-97-90. Hewlett
Packard. San Jose (CA) 1997.
Dunn, R. H.: Software-Quality. Concepts and Plans. Englewood Cliffs 1991.

E
ebXML: ebXML Technical Architecture Specification V. 1.0.4. OASIS and UN/
CEFACT. 2001. Available at http://www.ebxml.org/specs/ebTA.pdf
Eccles, R. G.: The Performance Measurement Manifesto. In: Harvard Business
Review, 89 (1991) 1, pp. 131-137.
Eder, J.; Liebhardt, W: Workflow Recovery. In: Proceedings of the First IFCIS
International Conference on Cooperative Information Systems (Coo-
pIS’96). Brussels 1996, pp. 124-134.
Edwards, W. K.: Policies and Roles in Collaborative Applications. In: Proceedings
of the 1996 ACM Conference on Computer Supported Cooperative
Work. Cambridge (MA) 1996, pp. 11-20.
Electronic Industries Association, C. T. C.: CASE Data Interchange Format -
Overview. Electronic Industries Association, CDIF Technical Commitee,
Extract of Interim Standard. Arlington (VA) 1997.
Ellis, C. A.: Information control nets: A mathematical system of office information
flow. In: Proceedings of the Conference on Simulation, Modeling and
Measurement of Computer Systems. Boulder (CO) 1979, pp. 225-240.
Ellis, C. A.: Officetalk-D: An Experimental Office Information System. In: Pro-
ceedings of the first ACM Conference on Office Information Systems.
Philadelphia (PA) 1982.
Ellis, C. A.; Bernal, M.: OFFICETALK-D: An experimental office information
system. In: SIGOA Newsletter, 3 (1982) 1, pp. 131-140
Ellis, C. A.; Keddara, K.; Rozenberg, G.: Dynamic Change Within Workflow Sys-
tems. In: Proceedings of the Conference on Organizational Computing
Systems (COOCS ’95). Milpitas (CA) 1995, pp. 10-22.
Ellis, C. A.; Nutt, G. J.: Office Information Systems and Computer Science. In:
ACM Computing Surveys, 12 (1980) 1, pp. 27-60.
Ellis, C. A.; Nutt, G. J.: Workflow: The Process Spectrum. In: NSF Workshop on
Workflow and Process Automation in Information Systems: State-of-the-
Art and Future Directions. Athens (GA) 1996, pp. 140-145.
 - 255 -

Emery, P.: The Workflow Market: A Global Perspective for 2000. In: Excellence
in Practice Volume IV: Innovation and Excellence in Workflow and
Knowledge Management. Ed.: L. Fischer. Lighthouse Point (FL) 2000,
pp. 41-47.
Eriksson, H.-E.; Penker, M.: Business Modeling with UML. Business Patterns at
Work. New York et al. 2000.
Ernest, P.: The one and the many. In: Constructivism in education. Eds.: L. Steffe,
J. Gale. New Jersey (NJ) 1995, pp. 459-486.
Espejo, R.; Harnden, R.: The Viable Systems Model - Interpretation and Applica-
tion of Stafford Beer's VSM. Chichester 1989.
Espejo, R.; Schuhmann, W.; Schwaninger, M.; Bilello, U.: Organizational Transfor-
mation and Learning. New York (NY) 1996.
ESPRIT Consortium AMICE Ed.: CIMOSA: Open System Architecture for CIM.
2nd edition, Berlin et al. 1993.

F
Farrell, N. J.: The Measure of Productive Efficiency In: The Journal of the Royal
Statistical Society, 120 (1957), pp. 253-290.
Fayol, H.: General and Industrial Management. London 1949.
Ferstl, O. K.; Sinz, E. J.: Grundlagen der Wirtschaftsinformatik, Band 1. 3rd edi-
tion, München 1998.
Fielding, R. T.: Architectural Styles and the Design of Network-based Software
Architectures. Doctoral Dissertation, Department of Computer Science,
University of California, Irvine, CA, Irvine, CA 2000.
Fischer, L.; Moore, C. (Eds.): Excellence in Practice. Innovation and Excellence in
Workflow and Imaging. Lighthouse Point (FL) 1997.
Fischer, L. (Ed.): Excellence in Practice. Innovation and Excellence in Workflow
and Imaging Vol. II. Lighthouse Point (FL) 1999.
Fischer, L. (Ed.) (EIP3): Excellence in Practice Volume III. Innovation and Excel-
lence in Workflow Process and Knowledge Management. Lighthouse
Point (FL) 2000.
Fischer, L. (Ed.) (EIP4): Excellence in Practice Volume IV. Innovation and Excel-
lence in Workflow Process and Knowledge Management. Lighthouse
Point (FL) 2000.
Flatscher, R.: Exchange of UML Models with EIA/CDIF. In: Workshop "Einsatz,
Bewertung und Stand der Unified Modeling Language (UML)". Man-
nheim 1997, pp. 3-13.
Frappaolo, C.: The Many Generations of Workflow. In: Workflow Handbook
2001. Ed.: L. Fischer. Lighthouse Point (FL) 2000, pp. 51-60.
Freiberger, P.; Swaine, M.: Fire in the valley. The Making of the Personal Com-
puter. 2nd edition, New York (NY) 2000.
- 256 -

Frese, E.: Gundlagen der Organisation. Konzept - Prinzipien - Strukturen. 8th

revised edition, Wiesbaden 2000.

G
Gadatsch, A: IT-gestütztes Prozessmanagement im Controlling. In: Controlling
Konzepte. Neue Werkzeuge und Strategien für die Zukunft. Eds.: C.-Ch.
Freindank, E. Mayer. 5th edition, Wiesbaden 2000, pp. 367-396.
Gaitanides, M.: Prozeßorganisation. Entwicklung, Ansätze und Programme
prozeßorientierter Organisationsgestaltung. München 1983.
Gaitanides, M.; Scholz, R.; Vrohlings, A.: Prozeßmanagement - Grundlagen und
Zielsetzungen. In: Prozeßmanagement. Konzepte, Umsetzungen und
Erfahrungen des Reengineering. Eds.: M. Gaitanides et al. München,
Wien 1994, pp. 1-19.
Galler, J.: Vom Geschäftsprozeßmodell zum Workflow-Modell. Wiesbaden 1997.
Galler, J.; Scheer, A.-W.: Workflow-Projekte: Vom Geschäftsprozeßmodell zur
unternehmensspezifischen Workflow-Anwendung. In: Information Man-
agement, 10 (1995) 1, pp. 20-27.
Gälweiler, A.: Strategische Unternehmensführung. Frankfurt, New York (NY)
1987.
Garber, D.: Rationalism. In: The Cambridge Dictionary of Philosophy. Ed.: R.
Audi. 2nd edition, Cambridge 1999, pp. 771-772.
Gazdar, G.; Klein, E.; Pullum, G.; Sag, I.: Generalized phrase structure grammar.
Cambridge (MA) 1985.
Gebauer, J.; Schad, H.: Building an Internet-based Workflow System. The Case of
Lawrence Livermore National Laboratories’ Zephyr Project. Fischer Cen-
ter Working Paper 98-WP-1030. University of California. Berkeley 1998.
Gehring, H.; Gadatsch, A. (1999a): Eine Rahmenarchitektur für Workflow-Man-
agement-Systeme. Fachbereichsbericht. Fachbereich Wirtschaftswissen-
schaft, Fern-Universität Hagen, Hagen 1999.
Gehring, H.; Gadatsch, A. (1999b): Ein Rahmenkonzept für die Prozessmodel-
lierung. In: Information Management & Consulting, 14 (1999) 4, pp. 69-
74.
Genesereth, M. R.: Knowledge Interchange Format - draft proposed American
National Standard (dpANS). NCITS.T2/98-004. Online document. 1998.
Available at http://logic.stanford.edu/kif/dpans.html
Georgakopolous, D.; Hornick, M.; Sheth, A.: An Overview of Workflow Manage-
ment: From Process Modeling to Workflow Automation Infrastructure.
In: Distributed and Parallel Databases, 3 (1995) 2, pp. 119-153.
Georgakopoulos, D.; Hornick, M. F.; Manola, F.; Brodie, M. L.; Heiler, S.; Nayeri,
F.; Hurwitz, B.: An Extended Transaction Environment for Workflows
in Distributed Object Computing. In: IEEE Bulletin of the Technical
Committee on Data Engineering, 16 (1993) 2.
 - 257 -

Geppert, A.; Tombros, D.: Event-based Distributed Workflow Execution with

EVE. Technical Report ifi-96-02. University of Zurich, Zurich 1996.
Geppert, A.; Tombros, D.: Logging and Post-Mortem Analysis of Workflow Exe-
cutions based on Event Histories. In: Proceedings of the third Interna-
tional Workshop on Rules in Database Systems (RIDS). Skoevde, Sweden
1997, pp. 67-82.
Gerboth, T.: Prozesscontrolling. Der nächste Schritt in einem prozess-orientierten
Controlling. Controlling, (2000) 11, pp. 535-542.
Gerboth, T.: Statistische Prozessregelung bei administrativen Prozessen im Rah-
men eines ganzheitlichen Prozesscontrollings. PhD Thesis, Fakultät V -
Verkehrs- und Maschinensysteme, Techniche Universität Berlin. Berlin
2002.
Glance, N. S.; Pagani, D. G.; Pareschi, R.: Generalized Process Structure Gram-
mars (GPSG) for flexible representations of work. In: Proceedings of the
1996 Conference on Computer Supported Cooperative Work (CSCW
'96). Ed.: M. Ackerman. Boston (MA) 1996, pp. 180-189.
Götzer, K.; Schneiderath, U.; Maier, B.; Boehmelt, W.; Komke, T.: Dokumenten-
Management. Informationen im Unternehmen effizient nutzen. 2nd edi-
tion, Heidelberg 2001.
Goodchild, A.; Herring, Ch.; Milosevic, Z.: Business Contracts for B2B. In: H.
Ludwig, Y. Hoffner, Ch. Bussler, M. Bichler In: Proceedings of the
CAiSE*00 Workshop on Infrastructures for Dynamic Business-to-Busi-
ness Service Outsourcing, Stockholm 2000, pp. 63-74.
Gorry, G. A.; Morton, M. S. S.: A Framework for Management Information Sys-
tems. In: Sloan Management Review, 13 (1971) Fall, pp. 55-70.
Grefen, P.; Pernici, B.; Sánchez, G.: Database Support for Workflow Management.
The WIDE Project. Boston et al. 1999.
Grob, H. L.: Positionsbestimmung des Controlling. Arbeitspapier des Lehrstuhls
für Wirtschaftsinformatik und Controlling der Reihe Computergestütztes
Controlling Nr.. 1, September 1996 Ed.: H. L. Grob. Münster 1996.
Gruhn, V.; Deiters, W.: The FUNSOFT Net Approach to Software Process Man-
agement. In: International Journal of Software Engineering and Knowl-
edge Engineering, 4 (1994) 3.
Gruhn, V.; Kampmann, M.: Modellierung unternehmensübergreifender
Geschäftsprozesse mit FUNSOFT-Netzen. In: Wirtschaftsinformatik, 38
(1996) 4, pp. 383-390.
Gruhn, V.; Wolf, St.: Software Process Improvement by Business Process Orienta-
tion. In: Software Process: Improvement and Practice 1 (1995) 1, pp. 49-
56.
Gulick, L. H.: Notes on the theory of organizations. In: Papers on the science of
administration. Eds.: L. H. Gulick, L. F. Urwick. New York (NY) 1937, p.
13.
- 258 -

H
Haberfellner, R.: Die Unternehmung als dynamisches System. Der Prozesscharak-
ter der Unternehmensaktivitäten. Zürich 1974.
Hagemeyer, J.; Rolles, R.; Schmidt, Y.; Scheer, A.-W.: Arbeitsverteilungsverfahren
in Workflow-Management-Systemen: Anforderungen, Stand und Perspe-
ktiven. Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft
145, Saarbrücken 1998.
Hammer, M.: Beyond Reengineering. How the Process-Centered Organization is
Changing our Work and our Lives. New York (NY) 1996.
Hammer, M.; Champy, J.: Reengineering the Corporation: A Manifesto for Busi-
ness Revolution., New York (NY) 1993.
Hammer, M.; Howe, W. G.; Kroksal, V. J.; Wladawsky, I.: A very high level pro-
gramming language for data processing applications. In: Communications
of the ACM, 20 (1977) 11, pp. 832-840.
Hammer, M.; Stanton, S.: How Process Enterprises Really Work. In: Harvard
Business Review, 77 (1999) 6, pp. 108-119.
Harel, D.: On Visual Formalisms. In: Communications of the ACM, 31 (1988) 5,
pp. 514-530.
Harrington, H. J.: Business Process Improvement. The Breakthrough Strategy for
Total Quality, Productivity, and Competitiveness. New York (NY) 1991.
Hayami, H.; Katsumata, M.; Okada, K.-i.: Interworkflow: A Challenge for Busi-
ness-to-Business Electronic Commerce. In: Workflow Handbook 2001.
Ed.: L. Fischer. Lighthouse Point (FL) 2000, pp. 145-159.
Hayes, J. G.; Peyrovian, E.; Sarin, S.; Schmidt, M.-T.; Swenson, K. D.; Weber, R.:
Workflow Interoperability Standards for the Internet. In: IEEE Internet
Computing, 4 (2000) 3, pp. 37-45.
Heilmann, H.: Integration: Ein zentraler Begriff in der Wirtschaftsinformatik im
Wandel der Zeit. In: HMD - Theorie und Praxis der Wirtschaftsinforma-
tik, 26 (1989) 150, pp. 46-58.
Heilmann, H.: Workflow Management: Integration von Organisation und Infor-
mationsverarbeitung. In: Handbuch der modernen Datenverarbeitung
(HMD), 31 (1994) 176, pp. 8-21.
Heilmann, H.: Die Integration der Aufbauorganisation in Workflow-Management-
Systeme. In: Information Engineering. Eds.: H. Heilmann, L. J. Heinrich,
F. Roithmayr. München 1996, pp. 147-165.
Henning, K. W.: Einführung in die betriebswirtschaftliche Organisationslehre.
Berlin 1934.
Hentze, J.; Brose, P.: Unternehmungsplanung. Bern, Stuttgart 1985.
Herrmann, Th.; Bayer, E.: Datenschutzkonzepte bei der Einführung von Work-
flow-Management-Systemen. In: Verbesserung von Geschäftsprozessen
mit flexiblen Workflow-Management-Systemen 3. Erfahrungen mit
Implementierung, Probebetrieb und Nutzung von Workflow-Manage-
 - 259 -

ment-Anwendungen. Eds: Th. Herrmann, A.-W. Scheer, H. Weber.

Heidelberg 1999, pp. 3-42.
Heylighen, F.: Epistemological Constructivism. In: Principia Cybernetica Web.
Eds.: F. Heylighen, C. Joslyn, V. Turchin. Brussels 1997.
Hill, W.; Fehlbaum, R.; Ulrich, P.: Organisationslehre 1. Ziele Instrumente und
Bedingungen der Organisation sozialer Systeme. 5th edition, Bern et al.
1994.
Hoffmann, M.; Löffeler, Th.; Schmidt, Y.: Flexible Arbeiteverteilung mit Work-
flow-Management-Systemen. In: Th. Herrmann, A.-W. Scheer, H.
Weber: Verbesserung von Geschäftsprozessen mit flexiblen Workflow-
Management-Systemen 3. Erfahrungen mit Implementierung, Probe-
betrieb und Nutzung von Workflow-Management-Anwendungen.
Heidelberg 1999, pp. 135-159.
Hollingsworth, D.: The Workflow Reference Model Version 1.1. Workflow Man-
agement Coalition, Winchester, UK 1995.
Holten, R.: Entwicklung von Führungsinformationssystemen: Ein methodenorien-
tierter Ansatz. Wiesbaden 1999.
Holten, R.; Dreiling, A.; zur Muehlen, M.; Becker, J.: Enabling Technologies for
Supply Chain Process Management. In: 2002 Information Ressource
Management Association International Conference. Seattle, Washington
2002.
Horváth, P.; Seidenschwarz, W.; Sommerfeldt, H.: Kostenmanagement - Warum
die Schildkröte gewinnt. Harvard Business Manager 15 (1993) 3, pp. 73-
81.
Horváth, P.: Controlling. 8th edition, München 2002.
Houghton, R.; El Sawy, O. A.; Gray, P.; Donegan, C.; Joshi, A.: Vigilant Informa-
tion Systems for Managing Enterprises in Dynamic Supply Chains: Real-
Time Dashboards at Western Digital. Management Information Systems
Quarterly Executive, 3 (2004) 1.
Hruby, P.: Specification of Workflow Management Systems with UML. In: Pro-
ceedings of the 1998 OOPSLA Workshop on the Implementation and
Application of Object-oriented Workflow Management Systems. Van-
couver (BC) 1998.

I
IBM Corporation: IBM MQSeries Workflow Administration Guide Version 3.2.
Document Number SH12-6289-02. Böblingen 1999.
IBM Corporation: Workflow Resource Assignment Interface. Submission to the
OMG Resource Assignment Interface RFP. Document No. bom/2000-
11-07. Framingham (MA) 2000.
IDS Scheer AG: Process Performance Manager. White Paper. Saarbrücken 2000.
Available at http://www.ids-scheer.de/sixcms_upload/media/35/ppm_
white_ paper_v1_0_dt.pdf [2002-01-17]
- 260 -

ifs GmbH: UNIVOSS Universelles Vorgangssteuerungssystem. Release 2.3.

Produktbeschreibung. Essen 2001.
Inmon, W. H.; Imhoff, C.; Sousa, R.: Corporate Information Factory. 2nd edition,
New York et al. 2001.
ISO/IEC: Electronic data interchange for administration, commerce and transport
(EDIFACT) - Application level syntax rules. ISO Standard 9735. Geneva
1988.
ISO/IEC: Information Technology - Syntactic Metalanguage - Extended BNF.
ISO Standard 14977. Geneva 1996
Ittner, C. D.; Larcker, D. F.: Are Nonfinancial Measures Leading Indicators of
Financial Performance? An Analysis of Customer Satisfaction. In: Journal
of Accounting Research, 36 (1999) Supplement, pp. 1-35.

J
Jablonski, S.: Workflow-Management-Systeme. Motivation, Modellierung,
Architektur. In: Informatik-Spektrum, 18 (1995) 1, pp. 13-24.
Jablonski, S.: Workflow-Management-Systeme. Modellierung und Architektur.
Bonn 1995.
Jablonski, S.; Bussler, C.: Workflow Management. Modeling Concepts, Architec-
ture and Implementation. London et al. 1996.
Jeng, J. J.; Schiefer, J.: An Agent-based Architecture for Analyzing Business Pro-
cesses of Real-Time Enterprises. In: Proceedings of the Seventh Interna-
tional Enterprise Distributed Object Computing Conference (EDOC
2003). Brisbane, Australia, 2003.
Jing, J.; Huff, K.; Hurwitz, B.; Sinha, H.; Robinson, B.; Feblowitz, M.: WHAM:
Supporting Mobile Workforce and Applications in Workflow Environ-
ments. In: Proceedings of the 10th International Workshop on Research
Issues in Data Engineering (RIDE ’00). San Diego (CA) 2000.
Johannson, H. J.; McHugh, P.; Pendlebury, A. J.; Johansson, H.; Wheeler, W. A.:
Business Process Reengineering. Breakpoint Strategies for Market Domi-
nance. Chichester et al. 1993.
Johnson, H. T.; Kaplan, R. S.: Relevance Lost. The rise and fall of management
accounting. Boston (MA) 1987.
Joosten, S. M. M.: WorkPAD: a Conceptual Framework for Process Analysis and
Design. In: ACM Transactions on Office Information Systems, Submit-
ted (1996).
Jüngel, M.; Kindler, E.; Weber, M.: The Petri Net Markup Language. Petri Net
Newsletter, 21 (2000) 59, pp. 24-29.
 - 261 -

K
Kabira; Oracle; WebGain: Joint Initial Submission to Workflow Process Defini-
tion. Object Management Group. Framingham (MA) 2002.
Kamlah, W.; Lorenzen, P.; Robinson, H.: Logical Propaedeutic. Pre-School of
Reasonable Discourse. Lanham, New York, London 1984.
Kaplan, R. S.: Measuring Manufacturing Performance: A New Challenge for Man-
agerial Accounting Research. In: The Accounting Review, 58 (1983) 4,
pp. 686-705.
Kaplan, R. S.: The Evolution of Management Accounting. In: The Accounting
Review, 59 (1984) 3, pp. 390-418.
Kaplan, R. S.; Cooper, R.: Cost & Effect. Using Integrated Cost Systems to Drive
Profitability and Performance. Boston (MA) 1997.
Kaplan, R. S.; Norton, D. P.: Putting the balanced scorecard to work. In: Harvard
Business Review, 71 (1993) 5, pp. 134-141.
Kaplan, R. S.; Norton, D. P.: The Balanced Scorecard. Translating Strategy into
Action. Boston (MA) 1996.
Kaplan, R. S.; Norton, D. P.: Using the balanced scorecard as a strategic manage-
ment system. In: Harvard Business Review, 74 (1996) 1, pp. 75-86.
Kaplan, R. S.; Norton, D. P.: The Strategy-Focused Organization. How Balanced
Scorecard Companies Thrive In The New Business Environment. Bos-
ton (MA) 2001.
Kappel, G.; Rausch-Schott, S.; Retschitzegger, W.: Coordination in Workflow
Management Systems - A Rule-Based Approach. In: Coordination Tech-
nology for Collaborative Applications - Organizations, Processes, and
Agents. Eds: W. Conen, G. Neumann. Berlin et al. 1998, pp. 99-120.
Karl, R.: Workflow-Management - Prozeßorientierte Vorgangsbearbeitung. In:
Office Management, 41 (1993) 3, pp. 45-47.
Karl, R.; Karl, W.: Dokumentenmanagement, Archiv, Workflow, Wissensmanage-
ment. dsk Studie 2000. Pfaffenhofen 2000.
Karlof, B.; Ostblom, S.: Benchmarking. New York (NY) 1993.
Keller, G.; Nüttgens, M.; Scheer, A.-W.: Semantische Prozeßmodellierung auf der
Grundlage "Ereignisgesteuerter Prozeßketten (EPK)". Arbeitsbericht.
Institut für Wirtschaftsinformatik Universität Saarbrücken. Saarbrücken
1992.
Khare, R.: Minutes of the second SWAP BoF meeting. E-Mail. IETF, 1998. Avail-
able at http://lists.w3.org/Archives/Public/ietf-swap/1998Dec/
0025.html
Kiepuszewski, B.; Muhlberger, R.; Orlowska, M. E.: FlowBack: Providing Back-
ward Recovery for Workflow Management Systems. In: ACM SIGMOD
International Conference on Management of Data. Seattle (WA) 1998.
Kim, J.: Explanation. In: The Cambridge Dictionary of Philosophy. Ed.: R. Audi.
Cambridge 1999, pp. 298-299.
- 262 -

Knutilla, A.; Schlenoff, C.; Ray, S.; Ployak, S. T.; Tate, A.; Cheah, S. C.; Anderson,
R. C.: Process Specification Language: An Analysis of Existing Represen-
tations. NISTIT 6160. National Institute of Standards and Technology
(NIST). Gaithersburg (MD) 1998.
Kobielus, J. G.: Workflow Strategies. Foster City (CA) 1997.
Köhler, R.: Modelle. In: Handwörterbuch der Betriebswirtschaftslehre. Eds.: E.
Grochla, W. Wittmann. Stuttgart 1974, pp. col. 2701-2716.
Koksal, P.; Alpinar, S. N.; Dogac, A.: Workflow History Management. In: ACM
Sigmod Record, 27 (1998) 1, pp. 326-348.
Körmeier, K.: Prozeßorientierte Unternehmensgestaltung. In: WiSt, 24 (1995) 5,
pp. 259-261.
Kosiol, E.: Organisation der Unternehmung. 2nd edition, Wiesbaden 1976.
Kotok, A.: Extensible And More: A survey of XML Business Data Exchange
Vocabularies, 2000-02-23, http://www.xml.com/pub/a/2000/02/23/
ebiz/index.html [Download 2002-06-02]
Kotok, A.: Even More Extensible and more: An Updated Survey of XML Business
Vocabularies, 2000-02-23, http://www.xml.com/pub/a/2000/08/02/
ebiz/extensible.html [Download 2002-06-02]
Kreifelts, T.: Bürovorgänge: Ein Modell für die Abwicklung kooperativer Arbeit-
sabläufe in einem Bürosystem. In: Informationstechnik und Bürosysteme.
Eds.: P. Wißkirchen, et al., Stuttgart 1983, pp. 215-245.
Kreifelts, T.; Hinrichs, E.; Klein, K.-H.; Seuffert, P.; Woetzel, G.: Experiences with
the Domino Office Procedure System. In: Proceedings of the 2nd Euro-
pean Conference on Computer-Supported Cooperative Work (ECSCW
'91). Eds.: L. Bannon, M. Robinson, K. Schmidt. Amsterdam 1993,
pp. 117-130.
Kruse, C.: Referenzmodellgestützte Geschäftsprozessmodellierung. Ein Ansatz
zur prozessorientierten Gestaltung vertriebslogistischer Systeme., Wies-
baden 1996.
Kruchten, Philip: Architectural Blueprints - The 4+1 View Model of Software
Architecture. IEEE Software 12 (1995) 6, pp. 42-50.
Kueng, P.: Ein Vorgehensmodell zur Einführung von Workflow-Systemen. Tech-
nical Paper 95.02. University of Linz, Austria 1995.
Kueng, P.: Workflow Management Systems: still few operational systems. In: SIG-
GROUP Bulletin 18 (1997) 3, pp. 32-34.
Kueng, P.: Supporting BPR through a Process Performance Measurement System.
In: Business Information Technology Management. Eds.: P. Banerjee, e.
al., New Delhi 1998, pp. 422-434.
Kueng, P.: Wirkungen von Workflow-Systemen: eine empirische Studie. In:
EMISA-Fachgruppentreffen. Eds.: H. Paul, I. Maucher. Gelsenkirchen
1998, pp. 13-24.
Kueng, P.: The Effects of Workflow Systems on Organizations: A Qualitative
Study. In: Business Process Management: Models, Techniques, and
 - 263 -

Empirical Studies. Eds.: W. van der Aalst, J. Desel, A. Oberweis. Berlin et

al. 2000, pp. 301-316.
Kueng, P.: Process Performance Measurement System: a tool to support process-
based organizations. In: Total Quality Management, 11 (2000) 1, pp. 67-
85.
Kueng, P.; Krahn, A.: Building a Process Performance Measurement System -
Some early experiences. In: Journal of Scientific & Industrial Research, 58
(1999) 3/4, pp. 149-159.
Kueng, P.; Krahn, A.: Performance-Measurement-Systeme: State-of-practise und
Weiterentwicklungen. Working Paper No. 00-12. Universität Freiburg.
Freiburg 2000. [September 2000]
Kugeler, M.: Informationsmodellbasierte Organisationsgestaltung : Modellierung-
skonventionen und Referenzvorgehensmodell zur prozessorientierten
Reorganisation. Berlin 2000.
Kuno, H.; Lemon, M.; Karp, A.; Beringer, D.: Conversations + Interfaces = Busi-
ness Logic. Technical Report. Software Technology Laboratory, HP Lab-
oratories, Palo Alto (CA) 2001.
Küpper, H.-U.: Controlling. Konzeption, Aufgaben und Instrumente. 3rd revised
and enhanced edition, Stuttgart 2001.
Kwan, M.; Balasubramanian, P. R.: Adding Workflow Analysis Techniques to the
IS Development Toolkit. In: Proceedings of the 31st Hawai’i Interna-
tional Conference on System Sciences. Ed: R. Sprague, Jr. Wailea (HI)
1998, pp. 312-321.

L
Lamla, J.: Prozessbenchmarking. München 1995.
Lawrence, P. R.; Lorsch, J. W.: High-performing Organizations in Three Environ-
ments. In: Organization Theory. Selected Readings. Ed.: Derek S. Pugh.
4th edition, London 1997, pp. 111-129. Original publication date 1967.
Lawrence, P. R.; Lorsch, J. W.: Developing Organizations: Diagnosis and Action.
Reading (MA) 1969.
Leavitt, H. J.; Whisler, T. L.: Management in the 1980's. New Information Flows
Cut New Organization Channels. In: Harvard Business Review, 36 (1958)
6, pp. 41-48.
Lebovich, I.; Woodgate, S.: Learning Biztalk Server 2000. Online training course.
Microsoft Corporation. 2001. Available at http://msdn.microsoft.com/
library/default.asp?url=/library/en-us/dnbiz/html/learnbtsan-
chor.asp?frame=true
Lechtenbörger, J.: Data Warehouse Schema Design. Berlin 2001.
Lee, J.; Gruninger, M.; Jin, Y.; Malone, T. W.; Tate, A.; Yost, G.: The PIF Process
Interchange Format and Framework Version 1.2. In: The Knowledge
Engineering Review, 13 (1998) 1, pp. 91-120.
- 264 -

Lehmann, H.: Organisationslehre, betriebswirtschaftliche. In: Handwörterbuch der

Organisation. Band II. Ed.: E. Frese. Stuttgart 1992, pp. 1538-1550.
Lehner, F.: Modelle und Modellierung in Angewandter Informatik und
Wirtschaftsinformatik oder "Wie ist die Wirklichkeit wirklich?" Fors-
chungsbericht Nr. 10 des Lehrstuhls für Wirtschaftsinformatik. Wissen-
schaftliche Hochschule für Unternehmensführung. Vallendar 1994.
Lehner, F.; Hildebrand, K.; Maier, R.: Wirtschaftsinformatik. Theoretische Grund-
lagen. München, Wien 1995.
Leymann, F.: Transaktionskonzepte für Workflow-Management-Systeme. In: Ge-
schäftsprozeßmodellierung und Workflow-Management. Eds.: J. Becker,
G. Vossen. Bonn et al. 1996, pp. 335-352.
Leymann, F.: Web Services Flow Language (WSFL 1.0). Technical report. IBM
Corporation. Stuttgart 2001. [May 2001]
Leymann, F.; Altenhuber, W.: Managing business processes as an information
resource. In: IBM Systems Journal, 33 (1994) 2, pp. 326-348.
Leymann, F.; Roller, D.: Workflow-based applications. In: IBM Systems Journal,
36 (1997) 1, pp. 102-123.
Leymann, F.; Roller, D.: Production Workflow: Concepts and Techniques. Upper
Saddle River (NJ) 2000.
Leymann, F.; Roller, D.: Modeling Business Processes with BPEL4WS. In: XML
Interchange Formats for Business Processes. Eds.: Markus Nüttgens, Jan
Mendling, Marburg, 2004, pp. 7-24.
List, B.; Schiefer, J.; Bruckner, R. M.: Measuring Knowledge with Workflow Man-
agement Systems. In: Second International Workshop on Theory and
Application of Knowledge Management (TAKMA 2001). Eds.: H. C.
Mayr, et al. München 2001, pp. 467-471.
List, B.; Schiefer, J.; Tjoa, A. M.; Quirchmayr, G.: The Process Warehouse - A
Data Warehouse Approach for Business Process Management. In: Pro-
ceedings of the International Conference on Management of Information
and Communication Technology (MiCT 1999). Copenhagen, Denmark
1999.
List, B.; Schiefer, J.; Tjoa, A. M.; Quirchmayr, G.: Multidimensional Business Pro-
cess Analysis with the Process Warehouse. In: New Trends in Knowledge
Discovery for Business Information Systems. Eds.: W. Abramowicz, J.
Zurada. Boston (MA) 2000.
Liu, C.; Orlowska, M.; Liu, X.; Zhou, X.: Improving Backward Recovery in Work-
flow Systems. In: Proceeding of the 7th International Conference on
Database Systyems for Advanced Applications (DASFAA'01),
HongKong 2001, pp. 276-283.
Lorenzen, P.: Constructive Philosophy., Amherst 1987.
Lucas, H. C.: Performance Evaluation and Monitoring. In: ACM Computing Sur-
veys, 3 (1971) 3, pp. 79-91.
Luhmann, N.: Soziale Systeme. 4th edition, Frankfurt/Main 1991.
 - 265 -

M
Mahling, D. E.; Craven, N.; Croft, W. B.: From Office Automation to Intelligent
Workflow Systems. In: IEEE Expert, 10 (1995) June, pp. 41-47.
Malone, T. W.; Crowston, K.: What is Coordination Theory and How Can It Help
Design Cooperative Work Systems? In: Proceedings of the conference on
Computer-supported cooperative work. Los Angeles (CA) 1990, pp. 357-
370.
Malone, T. W.; Crowston, K.: The Interdisciplinary Study of Coordination. In:
ACM Computing Surveys, 26 (1994) 1, pp. 87-119.
Malone, T. W.; Crowston, K.; Lee, J.; Pentland, B.: Tools for Inventing Organiza-
tions: Toward A Handbook of Organizational Processes. In: Proceedings
of the 2nd IEEE Workshop on Enabling Technologies Infrastructure for
Collaborative Enterprises. Morgantown (WV) 1993.
McClatchey, R.; Kovacs, Z.; Estrella, F.; Le Goff, J.-M.; Harris, H.; Baker, N.; Le
Flour, T.; Bazan, A.: The Integration of Product Data and Workflow
Management Systems in a Large Scale Engineering Database Application.
In: Proceedings of the 1998 International Database Engineering and
Applications Symposium. Eds.: B. Eaglestone, B. C. Desai, J. Shao,
Cardiff 1998, pp. 296-302.
McCoy, D.: Reality: Workflow Proliferation and Few Standards in Sight. Research
Note. Gartner Group. Stamford (CT) 2000. [2000-07-26]
McGregor, C. (IF5): The Impact of Business Performance Monitoring on WfMC
Standards. In: Workflow Handbook 2002. Ed.: L. Fischer. Lighthouse
Point (FL) 2002.
McGregor, C. (IW-MONS): IW-MONS: A Methodology for the Design of Intelli-
gent Workflow Monitoring Systems. Faculty of Information Technology,
University of Technology, Sydney, Sydney 2002.
McGregor, C.; Kumaran, S.: Business process monitoring using web services in
B2B e-commerce. In: Parallel and Distributed Processing Symposium.,
Proceedings International, IPDPS 2002, Abstracts and CD-ROM. 2002,
pp. 219-226.
McGregor, C.; Schiefer, J.: A framework for analyzing and measuring business per-
formance with web services. In: IEEE International Conference on E-
Commerce (CEC 2003). 2003, pp. 405-412.
McLellan, M.: Workflow Metrics - One of the great benefits of workflow manage-
ment. In: Praxis des Workflow-Management. Eds.: H. Oesterle, P.
Vogler. Braunschweig 1996, pp. 301-318.
Medina-Mora, R.; Winograd, T.; Flores, R.; Flores, F.: The Action Workflow
Approach to Workflow Management Technology. In: Proceedings of the
1992 Conference on Computer Supported Cooperative Work (CSCW
'92). New York (NY) 1992, pp. 281-288.
Meise, V.: Konstruktion von Ordnungsrahmen zur prozessorientierten Organisa-
tionsgestaltung. Strukturierung und Design von Modellen zur Kommuni-
- 266 -

kation intraorganisationalen Wandels. PhD Thesis, Department of

Information Systems, University of Münster. Münster 2000.
Mendling, J.; Strembeck, M.; Stermsek, G.; Neumann, G.: An Approach to Extract
RBAC Models from BPEL4WS Processes. In: 2nd International Work-
shop on Distributed and Mobile Collaboration (DMC 2004) at the 13th
IEEE International Workshops on Enabling Technologies: Infrastruc-
tures for Collaborative Enterprises (WETICE 2004). Modena, 2004.
Mendling, J.; Nüttgens, M.: Exchanging EPC Business Process Models with
EPML. In: M. Nüttgens, J. Mendling, eds.: Proc. of the 1st GI Workshop
XML4BPM - XML Interchange Formats for Business Process Manage-
ment" at Modellierung 2004, Marburg Germany, March 2004.
Mentzas, G.; Halaris, C.; Kavadias, S.: Modeling business processes with workflow
systems: an evaluation of alternative approaches. In: International Journal
of Information Management, 21 (2001) 2, pp. 123-135.
Merriam-Webster: Integration. Merriam-Webster's Collegiate Dictionary Online.
2002. Available at http://www.merriam-webster.com/cgi-bin/dictio-
nary?book=Dictionary&va=integration
Messer, B.: Zur Interpretation formaler Geschäftsprozeß- und Workflow-Modelle.
In: Wirtschaftsinformatik und Wissenschaftstheorie. Perspektiven und
Bestandsaufnahmen. Eds.: J. Becker, et al., Wiesbaden 1999, pp. 95-123.
Meyer, M.: Prozessmonitoring in SAP Business Workflow. In: DV-Management,
(1997) 4, pp. 163-167.
Mintzberg, H.: The Manager's Job: Folklore and Fact. In: Harvard Business
Review, 53 (1975) July-August, pp. 49-61.
Mittelstraß, J.: Metaphysik. In: Enzyklopädie Philosophie und Wissenschaftstheo-
rie. Eds.: S. Blasche, J. Mittelstraß. Stuttgart, Weimar 1995, pp. 870-873.
Mittelstraß, J.: Münchhausen-Trilemma. In: Enzyklopädie Philosophie und Wis-
senschaftstheorie. Eds.: S. Blasche, J. Mittelstraß. Stuttgart, Weimar 1995,
pp. 945-946.
Mohan, C.: Recent Trends in Workflow Management. Products, Standards and
Research. In: Proc. NATO Advanced Institute (ASI) Workshop on
Workflow Management Systems and Interoperability. 1997.
Moore, C.: Workflow Goes Mainstream. Planning Assumption. Giga Information
Group. Cambridge (MA) 2000. [2000-04-21]
Moser, P. K.: Epistemology. In: The Cambridge Dictionary of Philosophy. Ed.: R.
Audi. 2nd edition, Cambridge (MA) 1999, pp. 273-278.
Muth, P.; Weissenfels, J.; Gillmann, M.; Weikum, G.: Workflow History Manage-
ment in Virtual Enterprises Using a Lightweight Workflow Management
System. In: Proceedings of the 9th International Workshop on Research
Issues in Data Engineering: Information Technology for Virtual Enter-
prises (RIDE '99). Sydney, Australia 1999, pp. 148-155.
 - 267 -

N
Naef, A.; Schuler, C.; Schuldt, H.: Monitoring komplexer Dienste in unternehmen-
sübergreifenden Prozessen am Beispiel von SAP R/3 Business Work-
flow. In: Proceedings of the 9th GI-Conference Datenbanksysteme in
Büro, Technik und Wissenschaft (BTW 2001). Eds.: A. Heuer, F. Ley-
mann, D. Priebe. Oldenburg 2001, pp. 85-94.
Neumann, S.; Probst, C.; Wernsmann, C.: Kontinuierliches Prozessmanagement.
In: Prozessmanagement. Eds.: J. Becker, M. Kugeler, M. Rosemann. 3rd
edition, Berlin et al. 2002, pp. 297-323.
Nickerson, J. V.: Event-based Workflow and the Management Interfact. 36th
Hawaii International Conference on System Sciences (HICSS ’03).
Waikoloa (HI) 2003.
Nickerson, J. V.; zur Muehlen, M.: Defending the Spirit of the Web: Conflicts in
the Internet Standards Process. In: Workshop on Standard Making: A
Critical Research Frontier for Information Systems. Eds.: John L. King,
Kalle Lyytinen, Seattle, WA, 2003, pp. 327-343.
Nippa, M.: Anforderungen an das Management prozeßorientierter Unternehmen.
In: Prozeßmanagement und Reengineering. Die Praxis im deut-
schsprachigen Raum. Eds.: M. Nippa, A. Picot. Frankfurt am Main, New
York 1995, pp. 39-58.
Noeske, M.: Durchlaufzeiten in Informationsprozessen. Wege zur Beschleunigung
der Informationsverarbeitung. Wiesbaden 1999.
Nordsieck, F.: Aufgabenverteilung und Instanzenbau im Betrieb. In: Die Betrieb-
swirtschaft, 24 (1931) 7, pp. 204-210.
Nordsieck, F.: Grundlagen und Grundprinzipien der Organisation des Betrieb-
saufbaus. In: Die Betriebswirtschaft, 24 (1931) 6, pp. 158-162.
Nordsieck, F.: Grundlagen der Organisationslehre. Stuttgart 1934.
Nordsieck, F.: Betriebsorganisation. Lehre und Technik (Textband). 2nd revised
and enhanced edition, Stuttgart 1972.
Nutt, G. J.: The evolution toward flexible workflow systems. In: Distributed Sys-
tems Engineering, 3 (1996) 4, pp. 276-294.
Nutt, G. J.; Ellis, C. A.: Backtalk: an office environment simulator. In: Proceedings
of the 1979 International Conference on Communications. 1979,
pp. 22.23.21-22.23.25.

O
Odiorne, G. S.: MBO II: A system of managerial leadership for the 1980s. Belmont
(CA) 1979.
Object Management Group (Workflow): Workflow Management Facility Specifi-
cation Version 1.2. Document Number bom/00-05-02. Framingham
(MA) 2000.
- 268 -

Object Management Group: UML 1.4 Specification. Object Management Group.

Framingham (MA) 2001.
Oestereich, B.: Objektorientierte Softwareentwicklung. Analyse und Design mit
der Unified Method Language. 2nd edition, München, Wien 1997.
Ortner, E.: Ein Multipfad-Vorgehensmodell für die Entwicklung von Information-
ssystemen - dargestellt am Beispiel von Workflow-Management-Anwend-
ungen. In: Wirtschaftsinformatik 40 (1998) 4, pp. 329-337.

P
Panagos, E., Rabinovich, M.: Escalations in Workflow Management Systems. In
the DART Workshop, Rockville (MD) 1996.
Panagos, E., Rabinovich, M. :Predictive Workflow Management. In: Proceedings
of the 3rd International Workshop on Next Generation Information
Technologies and Systems. Neve Ilan, Israel, 1997.
Patterson, J. E.: Workflow and Data Warehouse Taxonomy. Masters Thesis, Uni-
versity of Texas. Arlington (TX) 1996.
Perrow, C.: Organizational Analysis: A Sociological View. London 1970.
Petri, C. A.: Kommunikation mit Automaten. PhD Thesis, Universität Bonn.
Bonn 1962.
Plesums, Ch.: Introduction to Workflow. In: L. Fischer (Ed.): Workflow Hand-
book 2002, Lighthouse Point (FL) 2002, pp. 19-38.
Picot, A.: Zur Steuerung der Verwaltung in Unternehmen - Notwendigkeit, Prob-
leme, Ansätze. In: Neue Systeme der Bürotechnik. Ed.: R. Reichwald.
Berlin 1982, pp. 365-395.
Popper, K. R.: The Open Society and its Enemies. London 1947.
Popper, K. R.: Logik der Forschung. 9th enhanced edition, Tübingen 1989.
Porter, M. E.: Competitive Advantage. Creating and Sustaining Superior Perfor-
mance. New York (NY) 1985.
Preble, J. F.: toward a comprehensive system of strategic control. In: Journal of
Management Studies, 29 (1992), pp. 391-409.

R
Raufer, H.: Dokumentenorientierte Modellierung und Controlling von
Geschäftsprozessen. Integriertes Workflow-Management in der Indus-
trie. Wiesbaden 1997.
Raetzsch, H. R.: Changes in the Workflow Paradigm. Presentation at the Move
Congress 1999. Dortmund 1999.
Ricker, J.; Swenson, K. D.; Silverstein, M.: Asynchronous Service Access Protocol
Working Draft 01. Standards Specification. Organization for the
Advancement of Structured Information Standards, Waltham, MA 2003.
[Accessed September 9th, 2003]
 - 269 -

Riebel, P.: Einzelkosten- und Deckungsbeitragsrechnung. Grundfragen einer

markt- und entscheidungsorientierten Unternehmensrechnung. 7th edi-
tion, Wiesbaden 1994.
Riegler, A.: toward a Radical Constructivist Understanding of Science. In: Founda-
tions of Science, 6 (2001) 1, pp. 1-30.
Rieke, T.: Workflow-basierte Balanced-Scorecard. Konzeption und prototypische
Umsetzung eines strategischen Controlling-Moduls für die J2EE-Platt-
form. Diploma Thesis. Department of Information Systems. University
of Muenster. Münster 2002.
Rolles, R.: Kontinuierliche Verbesserung von workflow-gestützten Geschäftsproz-
essen. In: Verbesserung von Geschäftsprozessen mit flexiblen Workflow-
Management-Systemen 1. Von der Erhebung zum Sollkonzept. Eds.: Th.
Herrmann, A.-W. Scheer, H. Weber. Berlin et al. 1998, pp. 109-133.
Ropohl, G.: Eine Systemtheorie der Technik. Zur Grundlegung der Allgemeinen
Technologie. München, Wien 1979.
Rosemann, M.: Komplexitätsmanagement in Prozessmodellen. Methodenspezi-
fische Gestaltungsempfehlungen für die Informationsmodellierung.
Wiesbaden 1996.
Rosemann, M.: Gegenstand und Aufgaben des Integrationsmanagements. In: Inte-
grationsmanagement. Eds.: A.-W. Scheer, M. Rosemann, R. Schuette.
Münster 1999, pp. 5-18.
Rosemann, M.; Denecke, T.; Püttmann, M.: Konzeption und prototypische Real-
isierung eines Informationssystems für das Prozeßmonitoring und -con-
trolling. Working Paper of the Department of Information Systems Nr.
49, University of Münster. Münster 1996.
Rosemann, M.; Schwegmann, A..: Vorbereitung der Prozessmodellierung. In:
Prozessmanagement. Eds.: J. Becker, M. Kugeler, M. Rosemann. 3rd edi-
tion, Berlin et al. 2001, pp. 47-94.
Rosemann, M.; zur Muehlen, M.: Evaluation of Workflow Management Systems -
a Meta Model Approach. In: Australian Journal of Information Systems,
6 (1998) 1, pp. 103-116.
Rosemann, M.: Arbeitsablauf-Monitoring und -Controlling. In: Workflow-Man-
agement - Entwicklung von Anwendungen und Systemen. Facetten einer
neuen Technologie. Eds: St. Jablonski, M. Böhm, W. Schulze. Heidelberg
1997, pp. 201-210.
RosettaNet Consortium: RosettaNet Implementation Framework: Core Specifica-
tion. Standards Specification. RosettaNet, 2002.
Royce, W. W.: Managing the Development of Large Software Systems: Concepts
and Techniques, In: Proceedings of the Western Electronic Show and
Convention, Los Angeles, Aug. 25-28, 1970. Los Angeles (CA) 1970,
pp. (A/1-1)-(A/1-9).
Rupietta, W.: Organisationsmodellierung zur Unterstützung kooperativer Vor-
gangsbearbeitung. In: Wirtschaftsinformatik, 34 (1992) 1, pp. 26-27.
- 270 -

Rupietta, W.: Organizational Models for Cooperative Office Applications. Data-

base and Expert Systems Applications. In: Proceedings of the 5th Inter-
national Conference DEXA '94. Ed.: D. Karagiannis. Athens, Greece,
September 1994.
Rupietta, W.: Organization and Role Models for Workflow Processes. In: The
Workflow Management Coalition Handbook. Ed.: Lawrence, P. Win-
chester 1997, pp. 165-172.
Rusinkiewicz, M.; Sheth, A.: Specification and Execution of Transactional Work-
flows. In: Modern Database Systems - The Object Model, Interoperabil-
ity, and Beyond. Ed: W. Kim. Reading (MA) 1995, pp. 592-620.

S
Sachs, P.: Transforming Work: Collaboration, Learning, and Design. In: Commu-
nications of the ACM, 38 (1995) 9, pp. 36-44.
Salimifard, K.; Wright, M.: Petri net-based modelling of workflow systems: An
overview. In: European Journal of Operational Research, 134 (2001),
pp. 664-676.
SAP AG: Composite Applications, SAP xApps and mySAP Business Suite - An
Overview. White Paper. SAP AG, Waldorf 2004.
Sassone, P. G.: Cost-benefit methodology for office systems. In: ACM Transac-
tions on Information Systems, 5 (1987) 3, pp. 273-289.
Sawalha, K.: Evaluation deutscher und amerikanischer Ansätze zur Organisations-
gestaltung - Vom Taylorismus zur Prozessorganisation. Master's Thesis,
Department of Information Systems, University of Münster. Münster
2000.
Schäffer, U.; Weber, J.; Prenzler, C.: Characterisind and Developing Controller
Tasks - A German Perspective. CCM Working Paper Nr. 3. Wissen-
schaftliche Hochschule für Unternehmensführung. Vallendar 2001.
Scheer, A.-W.: EDV-orientierte Betriebswirtschaftslehre. Grundlagen für ein effi-
zientes Informationsmanagement. Berlin et al. 1990.
Scheer, A.-W.: ARIS-House of Business Engineering: Von der Geschäftsprozeß-
modellierung zur Workflow-gesteuerten Anwendung. Universität des
Saarlandes, Institut für Wirtschaftsinformatik. Saarbrücken 1996. [Sep-
tember]
Scheer, A.-W.: Business Process Engineering. Reference Models for Industrial
Enterprises. 2nd edition, Berlin et al. 1994.
Scheer, A.-W.: ARIS - Business Process Frameworks. 3rd edition, Berlin et al.
1999.
Scheer, A.-W.: ARIS - Business Process Modeling. 3rd edition, Berlin et al. 2000.
Scheer, A.-W.; Joost, W.: ARIS in der Praxis. Berlin et al. 2002.
Scheer, A.-W.; Breitling, M.: Geschäftsprozesscontrolling im Zeitalter des E-Busi-
ness. In: Controlling, 12 (2000) 8/9, pp. 397-402.
 - 271 -

Schiefer, J.; Jeng, J.-J.; Bruckner, R. M.: Real-time Workflow Audit Data Integra-
tion into Data Warehouse Systems. In: 11th European Conference on
Information Systems. Naples, 2003.
Schildbach, T.: Begriff und Grundproblem des Controlling aus betrieb-
swirtschaftlicher Sicht. In: Controlling. Eds.: K. Spremann, E. Zur. Wies-
baden 1992, pp. 21-36.
Schmlumpberger, A.: Application Server. In: Lexikon der Wirtschaftsinformatik.
Eds: P. Mertens et al. Berlin et al. 2001, pp. 47-48.
Schlundt, M.; Jablonski, S.; Hahn, C.: Application Driven History Management for
Workflow Management Systems. Technischer Bericht am Lehrstuhl für
Datenbanksysteme. University Erlangen-Nürnberg. Erlangen 2000.
Schmelzer, H. J.; Friedrich, W.: Integriertes Prozeß-, Produkt- und Projektcontrol-
ling. In: Controlling, 9 (1997) 5, pp. 334-344.
Schmidt, G.: GPN. Generalised Process Networks. In: Handbook on Architec-
tures of Information Systems. Eds.: P. Bernus, K. Mertins, G. Schmidt.
Berlin et al. 1998, pp. 191-207.
Schmidt, K.: Of maps and scripts - the status of formal constructs in cooperative
work. In: Proceedings of the international ACM SIGGROUP conference
on Supporting group work: the integration challenge. Phoenix (AZ) 1997,
pp. 138-147.
Schmidt, K.; Simone, C.: Coordination mechanisms: toward a conceptual founda-
tion of CSCW systems design. In: Computer Supported Cooperative
Work, 5 (1996) 2-3, pp. 155-200.
Schmitz, J.: Prozessbenchmarking - Methodik zur Verbesserung von
Geschäftsprozessen. In: Controller Magazin, 23 (1998) 6, pp. 407-415.
Schreyögg, G.: Organisation. Grundlagen moderner Organisationsgestaltung.
Wiesbaden 1996.
Schreyögg, G.; Steinmann, H.: Zur Trennung von Eigentum und Verfügungsge-
walt. In: Zeitschrift für Betriebswirtschaft, 51 (1981), pp. 533-558.
Schreyögg, G.; Steinmann, H.: Strategic control. A new perspective. In: Academy
of Management Review, 12 (1987), pp. 91-103.
Schulze, W.: Workflow-Management für CORBA-basierte Anwendungen. Berlin
et al. 2000.
Schulze, W.; Böhm, M.; Meyer-Wegener, K.: Services of Workflow Objects and
Workflow Meta-Objects in OMG-compliant Environments. In: Proceed-
ings of the 1996 OOPSLA Workshop on Business Object Design and
Implementation. San Jose (CA) 1996.
Schulze, W.; Schmidt M.-T.; Zenie D.: OMG Workflow Management Facility -
Request for Proposals, OMG Document cf/97-05-06, May 9th, 1997.
Schulze, W..; Bussler, C.; Meyer-Wegener, K.: Standardizing on Workflow Man-
agement - The OMG Workflow Management Facility. In: SIGGROUP
Bulletin, 19 (1998) 3, pp. 24-30.
Schulte-Zurhausen, M.: Organisation. 2nd edition, München 1999.
- 272 -

Schütte, R.: Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion

konfigurations- und anpassungsorientierter Modelle. Wiesbaden 1998.
Schwemmer, O.: Ontologie. In: Enzyklopädie Philosophie und Wissenschaftstheo-
rie. Eds.: S. Blasche, J. Mittelstraß. Stuttgart, Weimar 1995, pp. 1077-
1079.
Seiffert, H.: Einführung in die Wissenschaftstheorie 3: Handlungstheorie, Modal-
logik, Systemtheorie. 2nd edition, München 1992.
Sellen, A. J.; Harper, R. H. R.: The Myth of the Paperless Office. Cambridge (MA)
2002.
Shan, M.-C.; Davis, J.; Du, W.; Huang, Y.: HP Workflow Research: Past, Present,
and Future. In: North Atlantic Treaty Organization –Advanced Study
Institute Workshop. Istanbul 1997.
Shannon, C. E.: A Mathematical Theory of Communication. In: Bell System Tech-
nical Journal, 27 (1948) July and October, pp. 379-423 and 623-656.
Sheth, A.: From Contemporary Workflow Process Automation to Adaptive and
Dynamic Work Activity Coordination and Collaboration. In: SIG-
GROUP Bulletin, 18 (1997) 3, pp. 17-20.
Sheth, A.; Rusinkiewicz, M.: On Transactional Workflows. In: IEEE Data Engi-
neering, 16 (1993) 2, pp. 34-40.
Shih, H. M.; Tseng, M. M.: Workflow technology-based monitoring and control
for business process and project management. International Journal of
Project Management, 14 (1996) 6, pp. 373-378.
Shohaiep, G.; Housel, T. J.; Kanevsky, V.: Workflow-BPR White Paper: Business
Process Auditing with Workflow-BPR. White Paper. University of South-
ern California. Los Angeles (CA) 1997. Available at http://www-
rcf.usc.edu/~housel/IOM499/wp.html [2001-07-15]
Short, J. E.; Venkatraman, N.: Beyond Business Process Redesign: Redefining Bax-
ter's Business Network. In: Sloan Management Review, 34 (1992) 1,
pp. 7-20.
Siegwart, G.: Systemtheorie. In: Enzyklopädie Philosophie und Wissenschaftstheo-
rie. Eds.: S. Blasche, J. Mittelstraß. Stuttgart, Weimar 1996, pp. 190-194.
Sinz, E. J.: Ansätze zur fachlichen Modellierung betrieblicher Informationssys-
teme. Entwicklung, aktueller Stand und Trends. In: Information Engi-
neering. Wirtschaftsinformatik im Schnittpunkt von Wirtschafts-, Sozial-
und Ingenieurwissenschaften. Eds.: H. Heilmann, L. J. Heinrich, F.
Roithmayr. München, Wien 1996, pp. 123-143.
Smith, H.; Fingar, P.: Business Process Management - The Third Wave. Tampa
(FL) 2003.
Sowa, J. F.; Zachman, J. A.: Extending and Formalising the Framework for Infor-
mation Systems Architecture. IBM Systems Journal, 31 (1992) 3, pp. 590-
616.
Staehle, W. H.: Kennzahlensysteme als Instrumente der Unternehmensführung.
In: WiSt, 2 (1973) Mai, pp. 222-228.
 - 273 -

Staehle, W. H.: Management. Eine verhaltenswissenschaftliche Perspektive. 8th

edition, München 1999.
Staffware plc (Functions): Staffware Expressions and Functions Reference Guide.
Issue 4, October 2000. Maidenhead 2000.
Staffware plc (Oracle): Staffware Oracle Server Administrator’s Supplement. Issue
3, December 2000. Maidenhead 2000.
Staffware plc (Server): Staffware Server Administrator’s Guide for Windows NT,
Windows 2000 and UNIX. Issue 4, October 2000. Maidenhead 2000.
Stalk, G.; Evans, P.; Shulman, L. E.: Competing on Capabilities. The New Rules of
Corporate Strategy. In: Harvard Business Review, 70 (1992), 3-4, pp. 57-
69.
Steinmann, H.; Schreyögg, G.: Management. Grundlagen der Unternehmens-
führung. Konzepte - Funktionen - Fallstudien. 5th enhanced edition,
Wiesbaden 2000.
Stoddard, D.; Javenpaa, S.: Business Process Reengineering: IT-Enabled Radical
Change. In: Harvard Business School Case, 9-193-151 (1993), pp. 1-5.
Stoddard, D.; Javenpaa, S.: Pacific Bell: Centrex Reengineering. In: Harvard Busi-
ness School Case, 9-195-098 (1994).
Stohr, E. A.: Transaction Resolution Networks: A Case Study. In: Presentation at
the 34th Hawaii International Conference on System Sciences, January 3,
2001. Ed.: R. Sprague, Jr. Wailea (HI) 2001.
Stohr, E. A.; Stohr, R. P.: Transaction Braks - A Litany of Errors. In: Proceedings
of the 14th Bled Electronic Commerce Conference. Bled, Slovenia, June
25-26 2001.
Strahringer, S.: Metamodellierung als Instrument des Methodenvergleichs. Eine
Evaluierung am Beispiel objektorientierter Analysemethoden. Aachen
1996.
Striemer, R.; Deiters, W.: Workflow Management - Erfolgreiche Planung und
Durchführung von Workflow-Projekten. Arbeitsbericht des Fraunhofer
Instituts für Software- und Systemtechnik. Dortmund 1995.
Suchman, L. A.: Office Procedures as Practical Action: Models of Work and Sys-
tem Design. In: ACM Transactions on Office Information Systems, 1
(1983) 4, pp. 320-328.
Suchman, L. A.: Plans and Situated Actions. The problem of human machine com-
munication. Cambridge (MA) 1987.
Suchman, L. A.: Do Categories Have Politics? The Language/Action Perspective
Reconsidered. In: Computer Supported Cooperative Work, 2 (1994) 3,
pp. 177-190.
Suchman, L. A.: Speech Acts and Voices: Response to Winograd et al. In: Com-
puter Supported Cooperative Work, 3 (1995), pp. 85-95.
Surjanto, B., Ritter, N., Loeser, H.: XML Content Management based on Object-
Relational Database Technology. In: Proceedings of the first Interna-
- 274 -

tional Conference on Web Information Systems Engineering (WISE),

Hongkong 2000, pp. 70-79.
Swenson, K. D.; Irwin, K.: Workflow Technology: Tradeoffs for Business Process
Reengineering. In: Proceedings of the Conference on Organizational
Computing Systems (COOCS '95). Milpitas (CA) 1995, pp. 22-29.
Swenson, K. D.: Simple Workflow Access Protocol. Internet Draft, http://
www.globecom.net/ietf/draft/draft-swenson-swap-prot-00.html [Down-
load 2002-06-02]
Swenson, K. D., zur Muehlen, M.: XML-based Standards for Process Integration.
Tutorial at XML World 2001 San Francisco, Nov 26, 2001.
Syring, M.: Möglichkeiten und Grenzen kommunikationsorientierter Systeme zur
Unterstützung arbeitsteiliger Prozesse im Büro. In: Wirtschaftsinforma-
tik, 34 (1992) 2, pp. 201-214.

T
Tan, J. C.; Harker, P. T.: Designing Workflow Coordination: Centralized Versus
Market-Based Mechanisms. Working Paper 97-02. University of Pennsyl-
vania, Department of Systems Engineering. Philadelphia (PA) 1997.
Tangt, J.; Veijalainen, J.: Transaction-oriented Work-flow Concepts in Inter-orga-
nizational Environments. In: Proc. of 4th International Conference on
Information and Knowledge Management (CIKM-95). Baltimore (MD)
1995, pp. 250-259.
Taylor, F. W.: Scientific Management. New York (NY) 1947.
Teubner, A.: Organisations- und Informationssystemgestaltung: Theoretische
Grundlagen und integrierte Methoden. Wiesbaden 1999.
Thatte, S.: XLANG - Web Services for Business Process Design. Initial Public
Draft. Microsoft Corporation. Redmond (WA) 2001. [2002-03-22]
Theuvsen, L.: Business Reengineering. In: Zeitschrift für betriebswirtschaftliche
Forschung, 48 (1996) 1, pp. 65-82.
Thompson, S.: XML Crosses the Chasm. In: Proceedings of the XML Europe
2000 conference, Paris 2000.
Tsichritzis, D. C.: Form management. In: Communications of the ACM, 25 (1982)
7, pp. 453-478.

U
Ulrich, H.; Krieg, W.: St. Galler Management-Modell. 3. edition, Bern 1974.
Ulrich, H.; Probst, G.: Anleitung zum ganzheitlichen Denken und Handeln. Ein
Brevier für Führungskräfte. Bern, Stuttgart 1988.
 - 275 -

V
Venkatraman, N.: IT-Induced Business Reconfiguration. In: The Corporation of
the 1990s. Information Technology and Organizational Transformation.
Ed.: Scott-Morton, M. S. New York, Oxford 1991, pp. 122-158.
Vering, O.: Methodische Softwareauswahl im Handel. Ein Referenz-Vorgehens-
modell zur Auswahl standardisierter Warenwirtschaftssysteme. PhD The-
sis, Department of Information Systems, University of Münster. Münster
2002.
Vernadat, F. B.: Enterprise Integration: On Business Process and Enterprise
Activity Modeling. In: Concurrent Engineering: Research and Applica-
tions, 4 (1996) 3, pp. 219-228.
Volck, S.: Die Wertkette im prozeßorientierten Controlling. Wiesbaden 1997.
von Bertalanffy, L.: General System Theory. Foundation, Development, Applica-
tions. Harmondsworth 1968.
von Foerster, H.: Observing Systems: Selected Papers of Heinz von Foerster. Sea-
side (CA) 1981.
von Foerster, H.: On Constructing a Reality. In: Observing Systems. Seaside (CA)
1981, pp. 288-309.
von Glasersfeld, E.: An introduction to radical constructivism. In: The Invented
Reality. Ed.: P. Watzlawick. New York (NY) 1984, pp. 17-40.
von Glasersfeld, E.: A constructivist approach to teaching. In: Constructivism in
education. Eds.: L. Steffe, J. Gale. New Jersey (NJ) 1995, pp. 3-16.
von Glasersfeld, E.: The Radical Constructivist View of Science. In: Foundations
of Science, 6 (2001) 1, pp. 31-43.
v. Uthmann, C.: Nutzenpotentiale der Petrinetz-Theorie für die Erweiterung der
Anwendbarkeit Ereignisgesteuerter Prozeßketten (EPK). In: Proceedings
zum Workshop Formalisierung und Analyse Ereignisgesteuerter
Prozeßketten (EPK). Eds.: M. Nüttgens, A. Oberweis, F. Rump. Olden-
burg 1997.
v. Uthmann, C.: Machen Ereignisgesteuerte Prozeßketten (EPK) Petrinetze für die
Geschäftsprozeßmodellierung obsolet? In: Emisa Forum - Mittleilungen
der GI Fachgruppe “Entwicklungsmethoden für Informationssysteme
und deren Anwendung”, (1998) 1, pp. 100-107.
v. Uthmann, C.: Geschäftsprozesssimulation von Supply Chains. Ein Praxisleit-
faden für die Konstruktion von Management-orientierten Modellen Inte-
grierter Material- und Informationsflüsse. San Diego et al. 2001.
v. Uthmann, C.; Turowski, K.: Workflow-basierte Geschäftsprozeßregelung als
Konzept für das Management industrieller Produktentwicklungsprozesse.
(unter Mitarbeit von M. Rehfeldt und M. Skall). Working Paper of the
Department of Information Systems Nr. 50, University of Münster. Mün-
ster 1996.
- 276 -

v. Werder, A.: Zur Begründung organisatorischer Gestaltung. In: Organisation im

Wandel der Märkte. Eds.: Glaser, H.; Schröder, E. F.; v. Werder, A. Wies-
baden 1998, pp. 479-509.
v. Werder, A.: Effizienzbewertung organisatorischer Strukturen. In: WiSt, 28
(1999) 8, pp. 412-417.
Voßbein, R.: Organisation. 3rd edition, München, Wien 1989.

W
W3C (2002a): Web Services Conversation Language (WSCL) 1.0. W3C Note 14
March 2002. Available at http://www.w3.org/TR/wscl10/ [2003-02-24].
W3C (2002b): Web Service Choreography Interface (WSCI) 1.0. W3C Note 8
August 2002. Available at http://www.w3.org/TR/wsci/ [2003-02-24]
Weber, J.: Die Koordinationssicht des Controlling. In: Controlling: Grundlagen,
Informationssysteme, Anwendungen. Eds.: K. Spreemann, E. Zur. Wies-
baden 1992, pp. 169-183.
Weber, J.: Einführung in das Controlling. 8th edition, Stuttgart 1999.
Weber, J.; Schäffer, U.: Sicherstellung der Rationalität von Führung als Funktion
des Controlling. In: DBW Die Betriebswirtschaft, 59 (1999) 6, pp. 731-
746.
Weikum, G.: Workflow Monitoring: Queries on Logs or Temporal Databases. In:
Proceedings of the 6th International Workshop on High Performance
Transaction Systems (HPTS '95). Asilomar (CA) 1995.
Weiß, D.: Prozeßkostenrechnung und Workflow Management: Konzeption und
Umsetzung eines Schnittstellensystems. Wiesbaden 1998.
Weiß, D.: Wie kann das Workflow Management die Prozeßkostenrechnung unter-
stützen? In: Controlling, 11 (1999) 11, pp. 543-549.
Weiß, D.; Zerbe, S.: Prozeßkostenrechnung und Vorgangssteuerung. In: Control-
ling, 7 (1995) 1995, p. 1.
Welge, M. K.; Fessmann K.-D.: Effizienz, organisatorische. In: Grochla, E. (Ed.):
Handwörterbuch der Organisation. 2nd edition, Stuttgart 1980, col. 577-
592.
Welge, M. K.; Al-Laham, A.: Strategisches Management. Grundlagen - Prozess -
Implementierung. 3rd edition, Wiesbaden 2001.
Weske, M. (Flexible): Flexible Modeling and Execution of Workflow Activities.
Arbeitsbericht Angewandte Mathematik und Informatik Nr. 8/97-I. Uni-
versity of Münster, Münster 1997.
Weske, M.: Workflow Management Through Distributed and Persistent CORBA
Workflow Objects. In: Proceedings of the 11th International Conference
on Advanced Information Systems Engineering (CAiSE '99). Eds.: M.
Jarke, A. Oberweis. Heidelberg 1999, pp. 446-450.
Weske, M.; Goesmann, Th.; Holten, R.; Striemer, R.:: A Reference Model for
Workflow Application Development Processes. In: Proceedings of th
 - 277 -

International Joint Conference on Work Activities Coordination and Col-

laboration WACC ’99. Eds.: D. Georgakopolous, W. Prinz, A. L. Wolf.
San Francisco (CA) 1999, pp. 1-10.
Weske, M.; Goesmann, Th.; Holten, R.; Striemer, R.:: Analysing, modelling and
improving workflow application development processes. In: Software
Process: Improvement and Practice, 6 (2001) 1, pp. 35-46.
Weske, M.; Vossen, G.: Workflow Languages. In: Handbook on Architectures of
Information Systems. Eds.: P. Bernus, K. Mertins, G. Schmidt. Berlin et
al. 1998, pp. 359-379.
WfMC (IF4 1.0): Workflow Management Coalition Workflow Standard - Interop-
erability. Abstract Specification. Document Number WfMC-TC-1012.
Version 1.0, October 20th, 1996. Brussels 1996.
WfMC (WAPI): Workflow Management Application Programming Interface
(Interface 2 & 3) Specification. Document Number WFMC-TC-1009.
Version 2.0e. Workflow Management Coalition. Winchester 1998.
WfMC (IF5 API): Workflow Management Coalition Workflow Audit Trail (Inter-
face 5) Application Programming Interface Specification. Document
Number WfMC-TC-1022. Version 0.1. Winchester 1998.
WfMC (Glossary): Terminology and Glossary, 3rd Edition. Document Number
WFMC-TC-1011. Workflow Management Coalition. Winchester 1999.
WfMC (IF4 2.0): Workflow Management Coalition Workflow Standard - Interop-
erability. Abstract Specification. Document Number WfMC-TC-1012.
Version 2.0a, November 30th, 1999. Winchester 1999.
WfMC (IF2): Audit Data Specification. Version 2. Document Number WFMC-
TC-1015. Workflow Management Coalition. Winchester 1999.
WfMC (WPDL): Interface 1: Process Definition Interchange Process Model. Doc-
ument Number WfMC-TC-1016-P Version 1.1 Final. Workflow Manage-
ment Coalition. Winchester 1999.
WfMC (MIME): Workflow Management Coalition Workflow Standard - Interop-
erability. Internet e-mail MIME Binding. Document Number WfMC-TC-
1018. Version 1.2, January 7th, 2000, Winchester 2000.
WfMC (Wf-XML): Workflow Management Coalition Workflow Standard -
Interoperability Wf-XML Binding Version 1.1, 14. November 2001.
Lighthouse Point (FL) 2001.
WfMC (XPDL): Workflow Process Definition Interface - XML Process Definition
Language. Document Status - 1.0 Final Draft. Document Number
WFMC-TC-1025. Workflow Management Coalition, Lighthouse Point
(FL) 2002.
White, S. A.: BPMN Fundamendals. Presentation at BPMI Meeting Nr. 6. Chicago
(IL) 2002.
White, S. A.: Business Process Modeling Notation (BPMN). Version 1.0 - May 3,
2004. BPMI.org, San Mateo, CA 2004.
- 278 -

White, T.; Fischer, L.: The Workflow Paradigm. The Impact of Information Tech-
nology on Business Process Reengineering. Alameda (CA) 1994.
Wiegert, O.: Business Process Modeling and Workflow Definition with UML -
Deficiencies and Actions to Improve. In: Presentation at the OMG Meet-
ing 1998-03-31. Manchester 1998.
Wiener, N.: Cybernetics. New York (NY) 1948.
Wiese, J.: Implementierung der Balanced Scorecard. Grundlagen und IT-Fach-
konzept. Wiesbaden 2000.
Winograd, T.; Flores, F.: Understanding Computers and Cognition. A New foun-
dation for Design. Norwood (NJ) 1986.
Wißkirchen, P.: Bürokommunikation im Überblick. In: Informationstechnik und
Bürosysteme. Eds.: P. Wißkirchen, et al., Stuttgart 1983, pp. 9-41.
Woetzel, G.; Kreifelts, T.: The Use of Petri Nets for Modeling Workflow in the
Domino System. In: Proceedings of the Workshop on CSCW, Petri Nets
and Related Formalisms at the International Conference on the Applica-
tion and Theory of Petri Nets. Chicago (IL) 1993, pp. 11-29.
Wong, K. F.; Low, B. T.; Ren, Y.: An Integrated Approach for Flexible Workflow
Modeling. Technical Report SEEM98-006. Department of Systems Engi-
neering and Engineering Management. Chinese University of Hong
Kong. Hong Kong 1998.
Worah, D.; Sheth, A.: What do Advanced Transaction Models Have to offer for
Workflows ? In: Proc. of the International Workshop on Advanced
Transaction Models and Architectures (ATMA). Goa 1996.

Y
Yongjie, R.: An Agent-based Workflow Model. In: Proceedings of the Doctoral
Consortium at the 1997 Conference on Advanced Information Systems
Engineering (CAiSE ’97). Eds.: J.-P. Tolvanen, A. Winter. Barcelona
1997.

Z
Zachman, J. A.: A Framework for Information Systems Architecture. IBM Sys-
tems Journal, 26 (1987) 3, pp. 276-292.
Zhou, T.; Pu, C.; Liu, L.: Dynamic restructuring of transactional workflow activi-
ties: a practical implementation method. In: Proceedings of the 1998
ACM 7th international conference on Information and knowledge man-
agement. Bethesda 1998, pp. 378 - 385.
Zisman, M.: Representation, Specification, and Automation of Office Procedures.
PhD Thesis, Wharton Business School, University of Pennsylvania. Phila-
delphia (PA) 1977.
Zisman, M.: Office Automation: Revolution of Evolution. In: Sloan Management
Review, 19 (1978) 3, pp. 1-16.
 - 279 -

zur Muehlen, M.: Der Lösungsbeitrag von Metamodellen und Kontrollflußprimi-

tiven beim Vergleich von Workflowmanagementsystemen. MSc Thesis,
Department of Information Systems, Universität Münster, Institut für
Wirtschaftsinformatik. Münster 1996.
zur Muehlen, M.: Evaluation of Workflow Management Systems Using Meta Mod-
els. In: 32nd Hawaii International Conference on Systems Sciences
(HICSS 1999). Ed.: R. Sprague, Jr. Wailea, HI 1999.
zur Muehlen, M.: Monitoring und Controlling von verteilten Geschäftsprozessen.
In: Forschungsjournal der Westfälischen Wilhelms-Universität Münster,
6 (1999) 2, pp. 50-54.
zur Muehlen, M.: Resource Modeling in Workflow Applications. In: Proceedings
of the 1999 Workflow Management Conference. Eds: J. Becker, M. zur
Muehlen, M. Rosemann. Münster 1999, pp. 137-153.
zur Muehlen, M.: Workflow-based Process Controlling - Or: What You Can Mea-
sure You Can Control. In: Workflow Handbook 2001. Ed.: L. Fischer.
Lighthouse Point (Fl) 2000, pp. 61-77.
zur Muehlen, M.: Process-driven Management Information Systems - Combining
Data Warehouses and Workflow Technology. In: Proceedings of the 4th
International Conference on Electronic Commerce Research (ICECR-4).
Ed.: B. Gavin. Dallas (TX) 2001, pp. 550-566.
zur Muehlen, M.: Workflow und Prozessmodellierung bei einem Energieversor-
gungsunternehmen. In: Prozessmanagement. Eds.: J. Becker, M. Kugeler,
M. Rosemann. 3. completely revised edition, Berlin et al. 2001, pp. 517-
538.
zur Muehlen, M.: Organizational Management in Workflow Applications. Infor-
mation Technology and Management, 5 (2004) 3, pp. 271-291.
zur Muehlen, M.; Allen, R.: Stand-Alone vs. Embedded Workflow - Putting Para-
digms in Perspective. In: Excellence in Practice Volume IV: Innovation
& Excellence in Workflow and Knowledge Management. Ed.: L. Fischer.
Lighthouse Point (FL) 2000, pp. 49-58.
zur Muehlen, M.; Klein, F.: AFRICA: Workflow Interoperability based on XML-
messages. In: CAiSE 2000 International Workshop on Infrastructures for
Dynamic Business-to-Business Service Outsourcing. Eds.: Martin
Bichler, et al., Stockholm, Sweden, 2000.
zur Muehlen, M.; Nickerson, J. V.; Swenson, K. D.: Developing Web Services
Choreography Standards - The Case of REST vs. SOAP. Decision Sup-
port Systems, 37 (2004).
zur Muehlen, M.; Rosemann, M.: Workflow-based Process Monitoring and Con-
trolling - Technical and Organizational Issues. In: Proceedings of the
33rd Hawaii International Conference on System Sciences (HICSS 2000).
Ed.: R. Sprague, Jr. Wailea (HI) 2000.
zur Muehlen, M.; von Uthmann, C.: Ein Framework für die Identifikation von
workflow-geeigneten Geschäftsprozessen. In: Handbuch der Modernen
Datenverarbeitung, 37 (2000) 2 (Heft 213), pp. 67-79.
- 280 -
 - 281 -

Appendix

Figure A-1: Entity Relationship Model

- 282 -

Figure A-2: Relational Model

Figure A-3: State Model