Conceptual Theory for Workflow Management Support Systems Stef Joosten Centre for Telematics and Information Technology, University of Twente, P.O. Box 217, 7500 AE Enschede, the Netherlands e-mail:
[email protected] July 5, 1995
Abstract Workflow Management is a relatively new field which has aroused much interest over the past few years. Largely driven by industrial developments (products, case studies), the field lacks a theory in which workflow can be founded. This paper develops a conceptual framework based on empirical evidence and literature. It provides the concepts and the relations between concepts that constitute the “research area of workflow”. It clarifies the content of the field and its position towards other fields of research.
1
Introduction
Workflow systems are being introduced in many different organisations, mainly larger administrative organisations for many different purposes such as rationalising a business process, coordinating work on electronic archives, reducing processing times and providing means for better insight in running processes. Nevertheless, users, managers and systems analysts are having trouble to understand the true nature of workflow systems. This leads to confusion during the implementation of automated workflows in the organisation. There is little theory yet to fill these needs. Although a glossary of workflow management terms has been produced by the Workflow Management Coalition, this list fails to identify the relationships between the various concepts. Besides, it is oriented towards tools rather than business processes. Apparently there is a need for a theory in which the concepts related to workflow management are identified and related to each other. Current practice shows many signs of a lack of theory. Tools, for example, demonstrate an obvious lack of concensus in concepts. Attempts to build workflow tools are often delayed or even frustrated because the tool designers can find no theory upon which their tools can be built (such as [25]). But also, workflow based innovations themselves suffer delays because too much time is spent in letting people know what workflow is [16]. A literature study [17] showed that two thirds of the workflow literature disclosed in a scientific database originated from industry rather than academia. The theory that is available is discussed in section 2 (Background). This paper contributes to the theory of workflow management support systems by presenting a conceptual framework that is founded both on literature and on empirical research. The approach taken is 1
to present a different conceptual framework for each of the relevant aspects of workflow management support systems. These aspects are identified on the basis of a generic architecture of such systems. In the end, all aspects are integrated into one single conceptual framework. After that, a discussion is held about the use of this framework. This paper is organised as follows. After an exposition of workflow backgrounds and of our research approach, workflow management support is explained on the basis of a generic architecture. Three specific aspects of workflow management support are treated in three subsequent sections. Section 8 then shows the result of integrating those aspects.
2
Background
There are different types of research related to workflow systems. So far, workflow literature reports about four types of research: technical, methodological, organisational and conceptual. Technical research is focused on finding technical primitives to support workflows. An example is the TriGSflow system in which workflows are organised on the basis of active objects [18]. Client/server architectures are being studied in order to enable workflow servers at different locations to cooperate [22]. Business transactions appear to be more complicated than database transactions. Consequently, researchers are looking into new transaction models [5, 3, 8]. Methodological research is motivated by the belief that workflow management represents a new paradigm. This justifies the search for new methods [1, 9, 10, 15]. However, the methodological research already goes back to early models for office automation [7]. Research in organisational and business sciences is done to find ways in which workflow tools are best exploited. Business process reengineering is a well known development in this area [13, 6]. The analogy with logistics has been noticed and used as a starting point for innovation of work procedures [29, 11]. However, much of this work remains on the organisational side, ignoring technonological issues. Conceptual research is conducted in order to describe workflows effectively and efficiently. The work of Winograd and Flores [27] about speech acts has started an important new development, leading to the Action Workflow Approach [20]. Many tools, however, use their own conceptual framework such as [19]. In such cases, the conceptual framework is usually postulated rather than founded. The workflow management coalition has released a glossary for workflow management in 1994, which contains definitions of terms involved in workflow management tools [28]. However, this glossary fails to relate the concepts to one-another. What is missing in the literature is an account of concepts and relations between those concepts such that there is a formal (i.e. mathematical) interpretation. This omission is the very motivation of this work: we claim to make a significant step in the development of a theory for workflow management support systems.
3
Research Approach
The research is best characterised as an empirically founded descriptive analysis. 2
Descriptive research is more appropriate than prescriptive research for the purpose of finding out about the concepts of workflow management support systems, albeit more labour intensive. It means that concepts are searched without imposing prefabricated definitions on the analysis. Source material has been analysed with respect to the use of language, in order to find out which concepts are important to workflow. Another foundation is the available literature on workflow. Articles that contribute to a conceptual framework are very often articles that describe a tool (e.g. [20, 19]). The conceptual analysis has proceeded in the following steps: 1. case studies [16] The empirical foundation of the research consists of 12 case studies that were carried out in 1993/’94. 2. language analysis Interview reports and corporate documentation were analysed with respect to their use of language, in order to find out which concepts are characteristic of workflow. Although a different set of words is used in every single source item, it is nevertheless possible in most cases to decide whether or not two different words refer to the same concept. Of course, this is an interpretation step, and can therefore introduce inaccuracies. 3. framework identification The set of concepts turned out to be too rich to present in a monolithic structure. The work done in defining a tool architecture [4] provided a proper framework for presenting the concepts in a logical and consistent manner. This has motivated the choice to structure the concepts along the lines of a generic architecture for workflow management support systems. 4. conceptual analysis Conceptual analysis is more than merely providing a list of definitions. It requires the study of the semantic structures and relationships between concepts. We have chosen to analyse the concepts by constructing entity-relationship models. This provides us with a systematic account of existence of the concepts and of the existential dependencies. The conceptual analysis has proceeded according to the ideas of Harmsen and Brinkkemper [14] on situational method engineering, the ideas of Stamper [24] on semantics and those of Gruber [12] on ontology. In Brinkkemper’s framework, the different aspects of a given domain are modeled in a way that is appropriate for the situation. Thus, a “method fragment” is defined for each aspect of interest. In order to support the entire system, the method fragments are integrated, as though they were views on a larger (more complicated) system. Stamper’s way of dealing with semantics is to study the signs that are used and try to find semantic relationships between signs rather than to attach a meaning to individual signs. Finally, Gruber’s ideas about ontology are in line with our choice to use entity-relationship diagrams.
4
Architecture
A generic architecture of a workflow management support system is given in order to provide a framework in which the concepts have their logical place. Some definitions precede the description of the architecture for obvious reasons. 3
Definition: [workflow management support system] A workflow management support system is a system that defines, manages and executes workflows through the execution of software whose order of execution is driven by a computer representation of the business process logic. The most central concept of workflow management support is that of workflow. Definition: [workflow] A workflow is a system whose elements are activities, related to one another by a trigger relation and triggered by external events, which represents a business process starting with a commitment and ending with the termination of that commitment. In this definition, a workflow represents a particular business process, such as the damage claim process in an insurance company. In order to be precise in our language, we must distinguish two levels of abstraction: the type level and the instance level. The word process is used at the generic process level (type level), as in damage claim process. The word case is used at the specific level (instance case level), as in Mr. Brown’s case of hurricane damage. In this sense, a process can be seen as a set of all cases that might be possible at any moment. The generic architecture of a workflow management support system is shown in figure 1. This is essentially a client/server architecture. It is generic in the sense that each of the components can occur multiply in different guises. It is also generic with respect to the concrete machines on which the components are located. Any component can be mapped on any machine, which includes the possibility of combinations of components on one machine. The workflow management support system itself consists only of those elements that are connected (in figure 1) with a shaded arrow. The application data and organisational data are part of the system (i.e. the set of people, procedures and means within the environment), but not of the support system (i.e. the tool). There are three different types of active component in a workflow management support system: interface processors, event managers and workflow managers. An interface processor links applications to the workflow system. It can be either custom or tailor-made. The event manager maintains a list of work to be done, guarding deadlines and work conditions and notifying other actors. A workflow manager coordinates within workflows, spawns and monitors other workflows, and communicates with other workflow managers when necessary. The clients occur in three different roles: workers, developers and managers. They are distinguished because they require different functionality from a workflow management support system. In practice, combinations of these roles are not uncommon. In many situations, workflow management support and document imaging are an obvious and successful combination. A mature electronic communication infrastructure within an organisation stores and transports most of the information objects used in a business process. This includes documents, files and archives, which makes the role of imaging technology an obvious one. A document imaging system is often an essential part of the infrastructure in which a workflow system is operational. 4
LEGEND client component
link to WSS component
active component link to external component
storage component
application data
organisational data
worker
developer
manager
Communication Network
Interface processor
event manager
workflow manager
definition data
process data
management data
Figure 1: Generic architecture In a workflow management support system we may distinguish five different kinds of data. This provides a good way to organise concepts, and can serve at the same time as an architectural decision to distinguish five (logically) different data sets. Definition data . The static information on the structure of workflow applications, e.g. workflow specifications and task specifications, is called the definition data. If a model of a business process is used to automate a workflow (similar to a case tool for software engineering), then the model should contain at least the definition data. Process data . The dynamic information on the current status and history of workflow applications is called the process data. This data is important when a workflow is processed. It is used to decide upon the actual order of events, assignment of actors, (re-)scheduling of activities etc. This makes the process data an essential component for the workflow engine. Besides, workers can draw upon the process data in order to track a workflow, provide customers with correct information about the current status of work, and to learn which activities are there for them to do (the worklist). Organisation data . Information about the organisational context of workflow applications, e.g. organisation structure, functions, resources is called organisation data. This data is not related to one specific business process, but contains information of a more general nature. Nevertheless, a workflow system needs access to such data in order to respect authorisations and qualifications that are defined within the organisation. Usually this means that the workflow management support system can make specific queries in existing organisational databases. Management data . Aggregated workflow process data that is used for management information and evaluation purposes is called management data. It consists mostly of statistics over several 5
workflows, which makes it different from process data. Management data is used by (mostly operational) managers to reschedule work when peaks in workloads are anticipated, to obtain insight in operational characteristics of a business process and to obtain metrics for productivity, process times etc. Application data Data proper to applications is called application data. Basically, application data constitutes the primary stream of work. The other four types of data are secondary in that they support the workflow. Application data are the workflow. that is actually processed by the workflow or descriptions thereof, e.g. order documents, client documents, etc. The structure of the definition data, process data and organisational data is laid out in detail in the following sections. Management data and application data are not treated for different reasons. Management data is derived data, and therefore it does not introduce new concepts. Application data are specific to each situation, and its structure has to be analysed separately in each situation. Applications introduce new concepts, mainly those that are proper to the business process under consideration. So, the data modelling phase in the application development can be seen as extending and tailoring the general model to the specific situation. So, in order to be complete about workflow concepts, only the first three data sets have to be analysed. After analysing the concepts behind the first three data sets, we show how the data sets are integrated conceptually.
5
Process Definition
The description of a workflow process is stored in a data set that contains process definitions (see figure 2). This data set typically contains the process definitions of all workflows that are supported object type
uses
process
ize
or
fy
ali
th
trigger
to
resource type
qu
from
uses
activity type au
sub
belongs to
role
Figure 2: Conceptual model of process definition information by the workflow enactment engine. From the point of view of a user, this is meta-information. Each time a workflow is started, an instance of the workflow is spawned according to the information in the definition data. The definition data consists of a hierarchy of processes and subprocesses. For example, the process process of going on a trip may consist of subprocesses like booking a flight, staying at a hotel and renting a car. We define a process as a collection of activity types. For example, the activity types in booking a activity type flight might be to select an airline, make the reservation, make the payment, etc. There is no hierarchy of activity types, subctivity types etc., because the notion of process is used for that purpose. Activity types are considered atomic in the sense that no further subdivision is done. 6
The precedence with respect to time between activity types is represented by triggers. In a process trigger definition model, triggers are modelled as arrows that connect activity types. This means that an event occurring in the first activity may cause the second activity to take place. In order to provide formal semantics of the triggering behaviour, activities have to be classified further in synchronisation activities and other activities. In [15], we show that making the distinction between complex, synchronisation and other activities gives a model from which a Petri-net can be derived algorithmically. The theory of Petri-nets [21] can then be applied to distinguish any allowable order of events from any illegal order. Thus, a formal semantics is given to the trigger model. The developer of a workflow system will need to know which data flows between which processes. The process definition contains information on which types of object are used by which processes. For object type example, the process of booking a flight requires information on the person who is flying. Similarly, resource types are registered in the workflow definition. For example, the activity make the reservation resource requires a resource "seat" is available. This information is also maintained in the relationship “uses”. type The definition data is completed with a registration of the responsible role (authorize) and performing role role (qualify) for each activity type. The meanings of the various relationships in the definition data (i.e. the lines and arrows in figure 2) are given by: uses A process p uses an object of type t. Example: A damage claim process uses a customer file. uses An activity of type a uses a resource of type r. A scarce object that is needed to perform an activity is called a resource. In the definition data, the resource types that are needed to perform a particular activity type are registered in the relationship “uses”. Example: In order to perform an activity of type "assess damage value" a resource of type "damage expert" must be used. The difference between resources and objects is that resources are used in competition with other uses of that same resource (i.e. it is scarce). sub A process p has subprocess p’. Processes may consist of subprocesses, which results in a hierarchy of processes. This hierarchy helps to maintain the overview in a complex process, by means of hierarchical decomposition. belongs to An activity of type a belongs to a process p. A process is defined as a collection of activities, which means that every activity type can be attributed to a given process. qualify A role r qualifies to perform an activity of type a. The relationship “qualify” is used to determine who is allowed to perform an activity. Since this information is registered when defining the process, roles are used rather than concrete actors. Example: a role “damage assessor” qualifies for the activity “assess damage”. 7
authorizes A role r is authorized for an activity of type a. The relationship “authorize” is used to register the responsible role for a given activity. Example: a role “partner” is authorized for the activity “acquire account”, which means that a partner may be responsible for account acquisition. This leaves alone who actually performs the activity. from/to A trigger t comes from an activity of type a and points to an activity of type a’. This means that an event that occurs as a result of performing a may cause a’.
6
Process Data
In the process of performing a workflow, all events that are relevant are registered in a log file. This event file registers at least the time of occurrence, the identification of the object by which the event was recognised, the trigger in which the event occurred, and the case to which the event belongs. This is represented by the entity “event” in figure 3. A case is an instance of a process for a given (specific) trigger
in
event of by object
refers to
case
sub belongs to
performs activity
responsible uses
actor resource
Figure 3: Conceptual model of process data case situation. For example: the damage caused by the flooding of Mrs. Brown’s bathroom on Nov. 18th is the start of a case. This case is an instance of the process water damage. Cases can be nested in the same way processes are nested. In the process data, cases are registered together with information on the parent case. Activities are elements of a case. An activity instance is created as a result of an event from (usually activity another) activity. In the process data, an entry is made for an activity when it starts. This entry is removed when the activity terminates. The objects used by an activity are accounted for in the object relationship “refers to”. Every activity has a performing actor and a responsible actor. Although actor these are often the same, it is not a general rule that responsibility and performance are shared by the same actor. Resources are objects that must be claimed in order to perform one or more activities.
8
A piece of resource
equipment or an amount of money can be used as a resource. All actors are resources in the sense that an actor is needed to perform any activity. Hence, actor is a specialisation of resource. Note that the process data are largely on the instance level whereas the definition data are largely on the type level. The meanings of the various relationships are given by the following sentences: refers to A case c refers to an object o. This means that o is visible throughout the case c, and (properly authorized) actors who work on that case can inspect or change it. in An event e occurs in a trigger t. This means that e enables an activity a, the type of which is pointed to by the arrow that represents t. by An event e is carried by an object o. This means that obect o serves to detect the event e. Example: a damage claim form can be the object that carries the event of claiming a damage. of An event e of case c. Every event occurs within the context of one case, so it makes sense to have a function (a n:1 relationship) by which the case can be referred to. responsible An actor r is responsible for activity a. This means that actor r is held accountable for anything that goes wrong with activity a. The actor r must be authorized for the type of activity of a. performs An actor r performs activity a. This means that actor r does everything necessary to complete activity a. The actor r must be qualified for the type of activity of a. belongs to An activity a belongs to a case c. All activities are performed within the context of a case. So it makes sense to refer to the case to which an activity belongs. uses A case c uses a resource r. The resources that are in use by a certain case are described by the relationship uses. sub A case c is a subcase of case c’. 9
7
Organisational Perspective
The structure of the organisational data is given in figure 4. The name “organisational unit” has been qualify role
function authorize
fy ali qu i ze or th au
actor
has function
belongs to sub organisational unit
Figure 4: Conceptual model of organisation data chosen as a neutral term for a collection of people that is considered a unit within the organisation, organisational rather than terms like department, division, section that may have specific meanings in a specific unit organisation. An “actor” is any person, machine or group that is capabable of performing activities or being responsible for activities. An employee can be an actor that is allocated to perform an activity, actor whereas an account manager can be allocated to bear responsibility for that activity. Actors are resources in the sense that activities have to compete for the energy of an actor. A distinction is made between responsibility and performance of activities. Consequently, the organisational data distinguishes between authorisation and qualification. Authorisation means that an actor is allowed to be responsible for an activity. Qualification means that an actor is allowed to perform an activity. Both properties are considered part of the organisational data. The entity “function” refers to the organisational function of actors within the organisation. For function example: Mr. Gates (actor) is CEO (function). A function differs from a role in that roles are related to certain activities. For example, damage assessor may be a role which can be taken by an employee role in the function of senior clerk. qualify A person (actor) with function f qualifies for role r. This means that anyone in function f can take on role r as a performer, and can therefore perform all activities that are performed by that role. authorize A person (actor) with function f is authorized for role r. This means that anyone in function f can take on role r as a responsible actor, and can therefore be responsible for any activity for which that role is authorized. 10
qualify An actor a qualifies for role r. In the cases in which an actor is not qualified by means of his function, that actor can be qualified separately. authorize An actor a is authorized for role r. In the cases in which an actor is not qualified by means of his function, that actor can be qualified separately. sub An organisational unit o is a sub-unit of organisational unit o’. The relationship “sub” contains the departmental hierarchy within the organisation. Notice that different organisations use different names for different levels in the organisation (e.g. divisions, departments, workgroups). Therefore, the more neutral name of organisational unit is chosen. has function An actor a has function f. This relation states the function of each actor. belongs to An actor a belongs to an organisational unit o. This information is static information, maintained by the personnel department of the organisation.
8
Integration
Having given the conceptual models of the different collections of data, it must be shown that it can be integrated conceptually. The reader may have noticed that there is overlap between the models of the different data sets. This overlap is limited to entities. Relationships are not shared among data sets. Therefore, the overall conceptual model of the whole workflow management support system can be given by “glueing” the parts together, as shown in figure 5.
9
Discussion
The development of a theory for workflow management support has the primary purpose of clarifying concepts and relating them. Basically, it is an exercise in ontology, being a systematic account of existence. Gruber [12], among others, have noticed that an entity-relationship model is a proper ontological representation. In the same article, he argues that an ontology should be more detailed than an entity-relationship model essentially is, and introduces Ontolingua as a language to provide that detail. This approach is more formal than the approaches taken for example by Bunge [2] or Wand [26], who do not insist in having a formal system at the basis of an ontology. 11
process
belongs to
qualify role
of
object
function authorize
by refers to
resource type
fy ali qu rize o th au
event
of type
of type
of type
to
trigger
in
uses
fy ali e qu oriz th au
from
sub
activity type
of type
uses
object type
case
sub belongs to
performs activity
responsible uses
actor
has function
resource belongs to sub
Legend
organisational unit
relationship total function (n:1 relationship) a x
entity called a
y
entities x and y, where every x is a y (specialisation)
Figure 5: Conceptual model of Mercurius Our work is more in line with Gruber than with Bunge. The prospect is that the entity-relationship models will be refined into a formal specification in Z [23], in order to provide the detail necessary for a sound theoretical basis of workflow management. In this sense, the work reported here is one step in a sequence that will lead to a solid foundation of workflow management support systems. The choice for using an entity-relationshipmodelling technique for structuring the concepts underlying workflow was motivated by the following requirements:
Some of the concepts are actually relationships between other concepts. Therefore it is necessary to do more than just sum up the list of definitions. The relationships between primary concepts needed to be investigated as well. An entity-relationship model shows a number of concepts in one diagram. This overview is considered useful in the light of the chosen framework. The semantics of an entity-relationship model provide an easy conception of database structures that might implement workflow management support systems. This is useful for understanding the concepts, but also for architectural considerations in the design of workflow tools. The step from empirical data down to a formal model (in Z) is considered too large. The entity-relationship model is used as an intermediate step. In fact, prototype software is being developed as a second intermediate step towards a formalisation.
12
This motivation for using entity-relationship models already sheds some light on the proposed uses of the conceptual model. In the current situation, we have the following uses of the conceptual framework for workflow management support systems in mind:
defining concepts supporting tool architectures matching the conceptual models of existing tools and thereby comparing existing tools providing a theory for integration of tools setting up an ontology for a knowledge base for workflow design designing a (generic) metamodel for workflow design tools Work is in progress on four of these uses (the first two and the last two). The ambitions for this theory are obviously high. This raises questions about the foundation of this theory, whether it is solid enough to support all these uses. In the current status, we think not. The current empirical evidence [16] is collected from 12 Dutch organisations, albeit by means of an indepth study of 40 person-months. Nevertheless, it can be argued that 12 is too few and the restriction of Dutch organisations violates representativity. The empirical evidence used to build the theory therefore requires independent validation, for which experimental and field research needs to be done. So, we anticipate that the presented framework will undergo minor changes in the near future. In spite of this criticism, which justifies collecting more empirical evidence, we are convinced that the framework is useful for all of its intended purposes. There is no reason for us not to go ahead with the development of these uses on the current basis. Actually, these developments will provide important validations that can help to improve the conceptual framework further.
10
Conclusions
We have established a consistent set of concepts that cover the most important parts of the field of workflow management support systems. We have shown how definition data, process data and organisational data can be integrated on a conceptual level. This demonstration makes further extensions likely and obvious. Being the first “workflow ontology” published, this work contributes to the formation of theory for workflow management support. Future work will involve the development of a formal system by way of refining the ontology further.
References [1] BLYTH, A., CHUDGE, J., DOBSON, J., AND STRENS, M. Ordit: A new methodology to assist in the process of eliciting and modelling organisational requirements. In Proceedings of the Conference on Organisational Computing Systems (Milpitas, California, USA, Nov. 1993), ACM Press, pp. 216 – 227. 13
[2] BUNGE, M. Vol 3: The furniture of the world. In Treatise on Basic Philosophy. Reidel, Boston, 1977. [3] DAYAL, U., HSU, M., AND LADIN, R. Organizing long-running activities with triggers and transactions. In Proceedings of the 1990 ACM SIGMOD International Conference on Management of Data (Atlantic City, NJ, 1990). [4]
DE
VRIES E.A, R. R. The mercurius proposal. June 1995.
[5] DEACON, A., SCHEK, H.-J., AND WEIKUM, G. Semantics-based multilevel transaction management in federated systems. In Proceedings the 10th Int. Conf. on Data Engineering (ICDE’94) (Houston, Texas, Feb. 1994). [6] DENNING, P., AND MEDINA-MORA, R. Case study: George mason university. In New Tools for New Times: The Workflow Paradigm (Alameda, CA, Mar. 1994), Future Strategies Inc., pp. 235–251. [7] ELLIS, C. A. Information control nets: A mathematical model of office information flow. In Proc. of the 1979 ACM Conference on Simulation, Measurement and Modelling of Computer Systems (1979), pp. 225–240. [8] ELMAGARMID, A. Database Transaction Models for Advanced Applications. Morgan Kaufmann Publishers, Inc., San Mateo, CA, 1992. [9] FAFCHAMPS, D. Ethnographic workflow analysis: specifications for design. In Human Aspects in Computing. Design and Use of Interactive Systems and Work with Terminals. Proceedings of the Fourth International Conference on Human-Computer Interaction (Amsterdam, 1991), H.-J. Bullinger, Ed., Elsevier, pp. 709–15. [10] GARNETT, P. Workflow: A methodology for performing a qualitative risk assessment. In 13th National Computer Security Conference. Proceedings. Information Systems Security. Standards - the Key to the Future, Washington DC (Gaithersburg, MD, USA, 1990), NIST, pp. 470–9 vol.2. [11] GERRITS, H. Redesigning information production processes for controlled production time. IFIP Transactions A [Computer Science and Technology] A-14 (1992), 143–149. [12] GRUBER, T. R. A translation approach to portable ontology specifications. Knowledge Acquisition, 2 (1993), 199–220. [13] HAMMER, M. Reengineering work: Don’t automate, obliterate. Harvard Business Review (July 1990), 104–112. [14] HARMSEN, F., BRINKKEMPER, S., AND OEI, H. Situational method engineering for information system project approaches. To be presented in CRIS ’94, the Netherlands, 1994. [15] JOOSTEN, S. Trigger modelling for workflow analysis. In Proceedings CON ’94: Workflow Management, Challenges, Paradigms and Products (Oct. 1994), G. Chroust and A. Bencz´ur, Eds., Oldenbourg, Wien, M¨unchen, pp. 236–247. [16] JOOSTEN, S., AUSSEMS, G., DUITSHOF, M., HUFFMEIJER, R., AND MULDER, E. Wa-12: an empirical study about the practice of workflow management. Tech. rep., University of Twente, dept. of Comp. Sc., P.O. Box 217, 7500 AE ENSCHEDE, the Netherlands, July 1994. Research monograph. 14
[17] JOOSTEN, S., MULDER, E., AND MCCRORY, J. Workflow literature guide. Sept. 1994. ¨ , B., RAUSCH-SCHOTT, S., AND RETSCHITZEGGER, W. Trigsflow active [18] KAPPEL, G., PROLL object-oriented workflow management. In Proceedings HICSS ’95 (1995). to appear. [19] LEYMANN, F., AND ALTENHUBER, W. Managing business processes as an information resource. IBM Systems Journal 33, 2 (1994). [20] MEDINA-MORA, R., WINOGRAD, T., FLORES, R., AND FLORES, F. The action workflow approach to workflow management technology. In Proceedings CSCW ’92: Sharing Perspectives (1515 Broadway, New York, New York 10036 USA, Nov. 1992), J. Turner and R. Kraut, Eds., Association for Computing Machinery, pp. 281–288. [21] PETERSON, J. Petri nets. ACM Computing Surveys 9, 3 (September 1977). [22] SCHUSTER, H., JABLONSKI, S., KIRSCHE, T., AND BUSS LER, C. A client/server architecture for distributed workflow management systems. In Proc. Parallel and Distributed Information Systems Conference (Sept. 1994), pp. 253–256. [23] SPIVEY, J. The Z Notation: A reference manual, 2nd ed. International Series in Computer Science. Prentice Hall, New York, 1992. [24] STAMPER, R. Signs, norms and information systems. to appear in: Holmqvist & Andersen, The Semiotics of the Workplace, 1995. [25]
VAN DE BELT, A. Representation of workflow design knowledge for the scarabaeus project. Master’s thesis, University of Twente, dept. of Comp. Sc., P.O. Box 217, 7500 AE ENSCHEDE, the Netherlands, to appear in 1995.
[26] WAND, Y., AND WEBER, R. An ontological model of an information system. IEEE Transactions on Software Engineering 16, 11 (Nov. 1990), 1282–1292. [27] WINOGRAD, T., AND FLORES, F. Understanding Computers and Cognition: A New Foundation for Design. Ablex Publishing Corporation, 335 Chesnutt Street, Norwood, New Jersey, 1986. [28] WORKFLOW MANAGEMENT COALITION. Glossary. Tech. rep., Workflow Management Coalition, Brussels, Nov. 1994. [29] WORTMANN, J. Factory of the future: towards an integrated theory for one-of-a-kind production. IFIP Transactions B [Applications in Technology] B-2 (1992), 37–74.
15
