Swiss Workflow Management in Distributed Environments
Database Technology Research Group, University of Zurich Research Group Information Engineering, University of Bern CSS Insurance Company
Potential of Business Process Modeling with regard to available Workflow Management Systems
Rainer Endl / Martin Meyer
SWORDIES Report Nr. 20
February 1999
Published in
Scholz-Reiter, B.; Stahlmann, H.-D.; Nethe, A. (Eds)
„Process Modelling“
Berlin, Heidelberg, New-York, 1999
Potential of Business Process Modeling with regard to available Workflow Management Systems
Abstract
Even though many workflow management systems (WfMS) are commercially available, only few existing systems are supporting business processes which are of main interest for the enterprise. This paper deals with the requirements of business process modeling and workflow modeling. These activities are not yet sufficiently supported by common methods.
Based on the requirements, problem areas are identified and illustrated by SAP's Business Workflow (SAP BWF). Finally, we suggest some solutions to meet the outlined problems.
Introduction
Motivation
The increasing dynamics and the continuous change of the market places forces the enterprises to meet thoroughly the needs and requirements of the customer. Many enterprises are trying to improve their competitiveness by designing their organisations to be process oriented, flexible, and adaptable. While the traditional theory of organisation focusses primarily on structure, the trend to a process oriented organisation of an enterprise is significant.1
In the context of this paper, business process- (BPM) and workflow-management (WFM) are treated as different views on the processes within an enterprise. While BPM is assigned to the conceptional level, WFM deals in the first place with the automation and the management of a business process or instances of them.
To model, analyse, and optimise business processes and building workflows, several tools and methods are commercially avalaible2. In the meanwhile, some of them have achieved a broad
1 cp. Nippa/Picot (1995), S. 14 ff.
2
cp. Kurbel/Nenoglu/Schwarz (1997), S. 67.
acceptance. Nevertheless, some problem areas exist which restrict the potential benefits of the use of BPM/WFM, e.g.
− Hetereogeneous modeling tools with different methodology and functionality:
Commercially available products are commonly based on different modeling approaches and are supporting different methods. The set of constructs provided by the modeling methods determines the power of the modeling methods and therefore the power of the tool supporting this method.3 It is difficult for the user to find the most appropriate method for his needs.
− The absence of proven directions and guidelines supporting the whole process of developing and modeling business processes and their implementation as workflows in an automated environment: Most of the commercially available tools are not associated to such guidelines supporting the developing process. Thus, it is up to the user to apply the method and the tools more or less systematically.
Aim of this paper
This paper investigates the modeling of business processes with respect to their implementation in workflow management systems. In the next chapter, the goals of modeling business processes and workflows and their requirements are explained in more detail. Based on these requirements, areas of problems are identified and illustrated by SAP's Business Workflow (SAP BWF). Finally, we suggest in chapter four some solutions to meet the outlined problems.
Modeling business processes and workflows
Goals of business process modeling
Modeling business processes can be divided into a strategic and a tactical/operational development task. The modeling on the strategic level is the starting point and determines the modeling on the succeeding level. In principle the following goals of process modeling are achieved:
− To help both, analysts and users, to gain a strong, commonly accepted understanding of the coherence of activities to achieve a business objective: By using appropriate methods and tools, transparency about elements needed within a business process and their relationships can be achieved4. On one hand, the model can reflect the actual state of the business, on the other hand the method can be used to develop a state which is desired for the future. The models foster the understanding of the relevant aspects of the business and their relationships and therefore facilitate the communication and discussion about issues
3 cp. Endl et al. (1997).
4
cp. Krcmar/Scheer (1994).
of improvements. This goal can be achieved on the condition that the models are readable and understandable by different user groups.
− Specification and configuration of packaged software: Some vendors of packaged software provide their systems in conjunction with an enterprise model.5 These so-called reference models often provide a process oriented view on the enterprise model and can be very useful for the evaluation and customisation of packed software: The reference model can support the identification and the choice of components and functions of the packaged software relevant to the enterprise. Given that the business processes planned for the future are modeled in the same way as the processes in the reference model of the packaged software, one can compare these models, determine the fundamental suitability of the packed software and furthermore derive the amount of work required for customisation. In the whole, the comparison of process models with reference models enables the evaluation and assessment of alternatives with respect to process structures and -ressources.6 For that purpose, several reference models are commercially available today.
− Basis for the development of application systems:7 The paradigm of process oriented modeling affects the methods for the development of application systems in the business environment, e.g. implementing a business process in a WfMS. Especially their implementation and therefore their automation with a WfMS requires the preceeding modeling of the business process.
Process- vs. Workflow-Modeling
As mentioned in the section above, one of the important prerequisites for workflow management is the process centered view. Workflow management learns from the business process modeling to take all aspects of an application system into account and not just to concentrate on certain partial aspects8. Thus, modeling business processes is a conceptional task while modeling workflows focusses primarily on the implementation aspects of a process and therefore provides a much more detailed view.
Given the different point of views, the following consequences occur:
− The modeling of business processes aims at the optimisation of the supply - customer relationship, while workflow modeling aims primarily at operational aspects of the process and IT-related questions such as: Which role or office is responsible for the execution of an activity within the process? Which application system on which server is designated to support a given activity within the process? Which file formats are suitable to put the necessary informations throughout the process?
− Analysing and documenting the business process is achieved with non-formal or semi- formal description languages in contrast to the specification of workflows, where formal
5
cp. Buck-Emden/Galimow (1995).
6 cp. Scheer (1998), S. 61 ff.
7 cp. Kurbel/Nenoglu/Schwarz (1997).
8
cp. Jablonski/Bussler (1996), S. 11f.
description languages are strictly used. The implementation of the business process with a WfMS is primarily a task for IT-specialists, while modeling the processes is a task to be accomplished under the authority of the business departments.9
− Business process models are used as a communication instrument between the involved persons, e.g. IT-specialists, consultants, business department staff. Decreasing the level of abstraction more and more, operational and IT-related know-how is required to understand the models. Thus, a workflow model on the most detailed level serves as the formal specification of the workflow to be implemented in a WfMS.
− In both business process- and workflow modeling the same information types are needed.
But stepping down the abstraction level, the information types become more and more concrete, e.g., the specification of functions leads to activities, the specification of entity types leads to data stores, and the specification of departments responsible for a function leads to roles responsible for some activities. In addition, according to the level of abstraction additional modeling constructs are required.
Important requirements
In the preceeding chapter we introduced the different levels of process and workflow modeling. Based upon this, several requirements can be derived. These are often listed in requirements catalogues for the evaluation of WfMS10. In this chapter, we explain some selected requirements whereas later in this paper ideas for their solution are suggested:
− Generality: The process of detailing the business process model must be accomplished with the same modeling instruments and without changing the paradigm.
− Availability of directions and guidelines supporting the whole process of developing and modeling business processes and workflows: Methods for business process- and workflow modeling must be supported by modeling guidelines and directions. These directions and guidelines are represented as rules which determine how the whole modeling process from the first model to its implementation has to be accomplished. These rules must be enforced by a modeling tool to ensure the integrity of the models11.
− Flexible Organisation model: The method of modeling the organisational aspects of a process must support a broad range of organisational concepts. At least the following three concepts must be provided by a modeling method:
• Role: Depending on the concrete definition, a role can be either a role with respect to a designated qualification or with respect to a specific competence- or knowledge-run activity within the process.
• Users or persons involved in a specific activity within the process.
• Organisational units and their relationhips.
9 cp. Halter (1998).
10 cp. Derungs/Vogler/Österle (1995); Endl et al. (1997); Heimig/Borowsky (1997).
11
cp. Knolmayer et al. (1997).
The modeling of roles, users and organisational units and its stepwise refinement must be possible as well. Furthermore, a flexible assignment of roles, users and organisational units has to be provided12.
Support of ad hoc workflows13: In practice it is often not convenient - or even impossible - to model all the situations which potentially can occur at runtime. The user should rather have the possibility to modify the workflow instance at runtime if any exceptional situation occurs. Thus, at least the following operations for the treatment of ad hoc-workflows must be supported:
• To skip an activity defined in the workflow model.
• To repeat an activity or a sequence of activities, e.g., if any errors are encountered.
• To abort an activity, e.g., a customer has canceled his order wich is already in execution.
Depending on the activity, the abort operation triggers either a rollback of activities already executed or the activation of another workflow to reverse the completed activities.
Concerning the modeling aspects, a method must support
• the definition of possible exit points in activities.
• the specification of events or event classes which lead to an abnormal termination of the activity.
• the definition of the operation types mentioned above which are triggered by the exception events.
The mentioned ad hoc operations executed at run-time do not affect the workflow model. But some ad hoc modifications could be recognized as universally valid, i.e., for all subsequent workflow instances. In this case, the changes must be available on all levels of abstractions, not only on the level of the workflow specification. To avoid repeated top-down modeling caused by changes on the level of workflow specification, a bidirectional approach is required which makes persistent changes on all levels of abstractions available.
Problems for modeling processes and workflows illustrated by SAP BWF
In this chapter, the problems derived from the requirements outlined in the preceeding chapter are discussed and illustrated by SAP's BWF. This system represents the class of so-called integrated WfMS, because it is build upon a packaged software14.
12 cp. Endl et al. (1997); Rosemann/zur Mühlen (1998).
13 cp. Georgakopoulos/Hornick/Shet (1995), S. 125 ff.
14
cp. Becker/Vogler (1997), S. 58.
We choose SAP BWF because it is a part of SAP R/3 and therefore one of the most common WfMS15. Furthermore, some evaluations have considered SAP BWF as one of the most mature WfMS with respect to the modeling component.16
The following problems may occur when modeling business processes and workflows using SAP R/3:
− Generality: Most of the common WfMS are provided with modeling tools. These modeling tools are proprietary and can not interact with tools designed for process modeling. Thus, a gap arises between business process- and workflow modeling, leading to additional activities for workflow specification. Moreover, there is no way to ensure the integrity of the workflow model with respect to the business process model automatically or at least supported by a computer. These disadvantages may occur with SAP BWF as well. It contains a graphical editor, which allows the specification of workflows by using Event driven Process Chains (EPC). One can model the business processes directly with these EPC´s. But nevertheless it is not possible to import business process models designed with another tool using another method than EPC. It is the same reason why a feedback from the level of the workflow model to the level of business process models is impossible. But this is an important requirement from the perspective of the management of the whole workflow life cycle17.
− The absence of directions and guidelines supporting the process of developing and modeling business processes and workflows: Common guidelines and directions are specific either to an enterprise or only to a part of the developing and modeling process. No solutions exist with respect to the transformation of business processes into workflow models which are sufficient for the practical use18. In SAP BWF, e.g., no sufficient guidelines exist for the support of the development and the use of the WfMS. On one hand, the available guidelines distinguish the development phases roughly between planning, realisation and implementation, on the other hand, the guidelines focus mainly on the implementation phases19.
− Modeling the organisation:
• Insufficient possibilities to model the organisation structure: The modeling of organisational aspects are treated insufficiently by common methods for business process and workflow modeling. Many systems support only parts of the constructs required to model the organisation. Given an example, temporarily existing organisation units, e.g. projects, may not be integrated into the process model if they establish a matrix organisation structure. In common, the possibilities for modeling multidimensional organisations are very restricted20. In SAP BWF exist constructs for
15 cp. Meyer/Wimmer (1998).
16 cp. Petrovic/Altenhofen (1998), S. 8; Joos/Endl/Tombros (1997).
17
cp. Galler (1997); Kurbel/Nenoglu/Schwarz (1997), S. 75.
18 cp. Joos/Endl/Tombros (1997).
19 cp. SAP (1997a); SAP (1997b).
20
cp. Rosemann/zur Mühlen (1998).
modeling occupied jobs, vacant jobs, organisation unit, roles and employees. The method is quite convenient to model hierarchical organisation structures21. Using both modeling constructs, role and vacancy, it is partly possible to model temporary organisation units22. But of course this is not sufficient to model multidimensional organisation structures often found in enterprises.
• Insufficient possibilities to relate employees to jobs and substitutes: Modeling the substitution of employees is insufficient in the sense that often only one person can act as a substitute to an employee. Further, defining a person as a substitute employee implies that he has the necessary qualifications to fullfil the job. We would prefer a role based modeling of substitute employees instead of a person based modeling. With a role based modeling, a set of employees will be available, which contains all persons who potentially can act as a substitute. SAP BWF for example allows the definition of a substitute employee only at run-time. The role based definition of substitute employees is not supported. In this context, the insufficient possibilities to relate jobs to employees must be mentioned. Most of the common methods do not consider that a job in the same organisational unit may be owned by several employees at the same time, e.g., in case of shift work23.
Insufficient flexibility with respect to ad hoc-workflows: The requirements with respect to ad hoc-workflow support as stated in chapter 2.3 are either not or insufficiently supported by common modeling methods24. For example, SAP BWF supports only some user initiated ad hoc-operations at run-time. Constructs for modeling aspects of ad hoc- workflows are not avaliable.
Solution approaches
Standards provided by the Workflow Management Coalition (WfMC)
The Workflow Management Coalition (WfMC) was founded in 1993 as an international nonprofit organisation by several vendors developing workflow management systems. At september 1998, the WfMC counts 200 members, including consultancy companies, universities, WfMS-users and -vendors25. The WfMC states its mission as follows26:
Increase the value of customer investment in workflow technology.
Decrease the risk of using workflow products.
Expand the workflow market through increasing awareness of workflows.
21 cp. Meyer/Pfahrer (1997), S. 21.
22 cp. Karl/Deiters (1997), S. 36.
23
cp. Rosemann/zur Mühlen (1998).
24 cp. Bürgi (1998).
25 Home page of the Workflow Management Coalition: http://www.aiim.org/wfmc/.
26
cp. WfMC (1994).
The WfMC developed a WfMS-reference model which specifies a framework for workflow systems as well as identification of their characteristics, functions and interfaces27 (cp. Fig. 1).
Process Definition Services
Invoked Applications Workflow
Client Applications
Other Workflow Enactment Service(s) Workflow Enactment Services
Administration and Monitoring Services
Workflow Engine(s)
5 4
1
2 3
A3 A2 A1
Fig. 1: The WfMC-reference model
The WfMC considered the five interfaces in the reference model as WAPI´s (Workflow Application Programming Interfaces and Interchange Formats). At WfMC five working groups are established to work on one of the following interfaces (cp. Fig. 1):
− Process Definition Tools
− Workflow Client Applications
− Invoked Applications
− (Other) Workflow-Enactment Services (Interoperability)
− Administration and Monitoring Tools.
With respect to business process and workflow modeling, the interface one is of particular importance. It defines a standard interface between a process definition tool and the workflow engine(s). To achieve this, a standard is developed for the import and export of workflow specifications. The interchange format contains, among other things, the following information:
− Conditions under which a workflow starts and terminates.
− Identification of activities within a process.
− Identification of data types and access paths, definition of transition conditions, and rules to control the flow.
− Information concerning the allocation of resources.
Basically, the standardisation of the interface one enables the automatic transformation of the business process model into the WfMS and its use for workflow specification. But currently the functionality of the interfaces considered in the reference model is not defined in detail28.
27 cp. WfMC (1994); Eckert (1995); Weiß/Krcmar (1996).
28
cp. Jablonski (1997), S. 80.
Furthermore, the question whether the interface one is universally valid remains, because the WfMC has defined just the kernel of the interface model which may be enhanced by vendors with proprietary features29.
Approaches of the SWORDIES-project
Within the project SWORDIES30 (Swiss WORkflow Management in DIstributed EnvironmentS), which is partly sponsored by the Swiss National Science Foundation, the department of information engineering at the University of Berne researches on business rule based modeling of business processes and workflows. The aim of this work is to develop a rule based method to analyse and model business processes and their specification in different target systems. Besides the method, general guidelines and directions will be provided to support the whole workflow life cycle. These guidelines are formulated as rules as well and result in a set of meta-rules.
Another goal is the consideration of aspects of modeling ad hoc-workflows which includes mechanisms to transform changes made on the level of workflow specification to a higher level of abstraction.
Business rules can be defined as statements about how the business is done, i.e., about guidelines and restrictions with respect to states and processes in an organisation31. Business rules trigger an action of an information system, send an alerter to a human factor or define the feasible space for human action. The rule based modeling method therefore builds on ECA-rules (ECA: Event, Condition, Action) well known in active database systems.The ECA- Rules were extended by constructs representing specific features of business and workflow modeling, e.g., to model the organisational structure32. In addition, a construct to model alternative actions (similarily to the if ... then... else...-statements in programming language) were introduced which enhances ECA to ECAA33. Depending on the level of abstraction, the content of the rule components contains colloquial or formal statements. Every rule within the business process or workflow is identified by a unique name. The components of a rule are described as follows:
− Event: An elementary or complex event which triggers the processing of the rule. It contains the information when a business rule has to processed34.
− Condition: Contains the conditions or circumstances which have to be checked before the action-part will be performed.35
29
cp. Derszteler (1996), S. 591.
30 http://www.ifi.unizh.ch/groups/dbtg/SWORDIES/
31 cp. Herbst (1997).
32
cp. Knolmayer et al. (1997).
33 cp. Knolmayer et al. (1997).
34 cp. Herbst/Knolmayer (1995).
35
cp. Herbst (1997).
− Action: Contains information about what has to be done if the condition is true.
− Alternative Action: Contains information about what has to be done if the condition is false36.
Note that while performing an action part of a business rule, events may be raised which trigger further business rules. In addition, the condition and the alternative action part of a rule are optional. Figure 2 gives an example of a sequence of actions modeled by business rules containing only the parts event and action37
ON DO
e1
a1
ON DO a2
e2 ON
DO ...
e3
e2 e3
Fig. 2: Modeling a sequence of actions
Several case studies have shown that common modeling methods, e.g., EPC, fun soft-nets, and petri nets may be transformed into business rules at every level of abstraction38. In the same way, one can transform processes modeled by business rules to different target systems, e.g., in a workflow description language like TRAMS39 or in database systems40. Furthermore, business rules can be used to generate the parts of the logic of an application system41. So one can think of business rules as a standardised representation of business processes. The process models eventually obtained by employing different process modeling tools (by decentralised or virtual enterprises or along a supply chain) may be transformed to a rule based description of the business processes. This business rule model may be refined stepwise until the system is represented by elementary business rules (Fig. 3).
During the refinement of business rules, the relationship between the different levels is preserved42. This is one of the most important prerequisites for bidirectional modeling and a potential advantage with respect to other modeling methods (e.g. EPC). Following the path of abstraction in reverse direction allows one to make changes on a very formal level, e.g. on the level of workflow specification, and transform the changes to the other abstraction levels in a controlled manner. Thus, ad hoc-modeling of workflows can be supported on all levels of abstraction.
36
cp. for example Herbst/Knolmayer (1995).
37 cp. Endl/Knolmayer/Pfahrer (1998).
38 cp. Knolmayer et al. (1997).
39
cp. Kradolfer/Geppert (1997).
40 cp. Gatziu (1995).
41 cp. Mallens (1997).
42
cp. Endl et al. (1998)
Process Modeling Method 1 (e.g. ARIS)
Process Modeling Method 3 (e.g. Petri Nets)
Process Modeling Method n (e.g. ECAA)
WF-Specification for TRAMS WF-Specification
for commercial available WFMS (e.g. FlowMark)
Triggers and Stored Procedures
of active DBMS Business Transactions
in Application Code
. . .
. . .
Business Rule Oriented Process Model
WF Specification for Enterprise Management Systems
(e.g. SAP R/3) Process Modeling
Method 2 (e.g. BONAPART)
Business Rule Oriented Workflow Model Stepwise Refinement
Fig. 3: Business rules as integration layer between process and workflow models
Outlook
Currently, the considerations made up in the preceding chapter are tested for their practicability. In parallel, we are working on the specification of a repository supporting the business process and workflow life cycle. Furthermore, we started a project to develop guidelines and directions to support the business rule oriented process modeling.
Following the vision of a learning WfMS, a bidirectional modeling method can build its basis.
A learning WfMS registers all activities, to which in the past ad hoc-workflows were invoked, and evaluates and stores the relevant environment parameters. Based on this information, the WfMS can support the decision of the user about the continuation of the process if any situation occurs which is similar to an ad hoc-workflow initiated in the past. The user then can view the suggested alternatives at any level of abstraction and modify or accept one of them.
Such a learning WfMS could be a valuable contribution to the knowledge management in an enterprise, in particular with respect to the organisational know-how.
Literature
Becker, M., Vogler, P., Workflow-Management in betriebswirtschaftlicher Standardsoftware - Konzepte, Architekturen, Lösungen, Arbeitsbericht IM HSG/CC PSI/9,
Version 1.0, Institut für Wirtschaftsinformatik, Universität St. Gallen 1997.
Buck-Emden, R., Galimow, J., Die Client/Server-Technologie des System R/3, Bonn et al.:
Addison Wesley 1995.
Bürgi, J.-M., Möglichkeiten und Grenzen für das Management von Ad-hoc-Workflows am Beispiel von SAP Business Workflow, Lizentiatsarbeit, Institut für
Wirtschaftsinformatik, Universität Bern 1998.
Carlsen, S., Organizational Perspectives of Workflow Technology, Working Paper, The Norwegian Institute of Technology, University of Trondheim 1995.
Derszteler, G., Workflow Management Cycle, in: Wirtschaftsinformatik 38 (1996) 6, S. 591 - 600.
Donatelli, S., Simone, C., Trentin, D., Combining abstraction and context: a challenge in formal apporaches to workflow management, in: van der Aalst, W. (Ed.), Proceedings of the Workshop on Workflow Management: Net-based Concepts, Models, Techniques and Tools (WFM’98), Computing Science Reports,
Eindhoven University of Technology 1998, pp. 194 – 209.
Derungs, M., Vogler, P., Österle, H., Kriterienkatalog Workflow-Systeme, Arbeitsbericht IM HSG/CC PSI/1, Version 1.0, Institut für Wirtschaftsinformatik, Universität St.
Gallen 1995.
Eckert, H., Die Workflow Management Coalition, Zielsetzungen, Arbeitsgebiete und erste Arbeitsergebnisse, in: Office Management 43 (1995) 6, S. 26 - 32.
Endl, R., Knolmayer, G., Pfahrer, M., Modeling Processes and Workflows by Business Rules, Swordies Report, Institut für Wirtschaftsinformatik, Universität Bern 1998.
Endl, R., Duedal, L., Fritz, B., Joos, B., Anforderungen an Workflowmanagementsysteme aus anwendungsorientierter Sicht, Arbeitsbericht Nr. 92, Institut für Wirtschafts- informatik, Universität Bern 1997.
Galler, J, Vom Geschäftsprozeßmodell zum Workflow-Modell, Wiesbaden: Gabler 1997.
Gatziu, S., Events in an Active, Object-Oriented Database System, Hamburg: Dr. Kovac Verlag 1995.
Georgakopoulos, D., Hornick, M., Sheth, A., An Overview of Workflow-Management: From Process Modeling to Workflow Automation Infrastructure, in: Distributed and Parallel Databases 3 (1995) 2, S. 119 - 153.
Halter, U., Auswahl und Konzeption von Workflow-Anwendungen, in: Informatik 5 (1998) 2, S. 18 - 22.
Heimig, I., Borowsky, R., Geschäftsprozeßgestaltung mit integrierten Prozeß- und Produktmodellen (GiPP), Ergebnisbericht aus den Projektgemeinschaften, Evaluierungskatalog zur Bewertung von Workflow-Systemen, Institut für Wirtschaftsinformatik, Universität Saarbrücken 1997.
Herbst, H., Knolmayer, G., Ansätze zur Klassifikation von Geschäftsregeln, in: Wirt- schaftsinformatik 37 (1995) 2, S. 149 - 159.
Herbst, H., Business Rule-Oriented Conceptual Modeling, Heidelberg: Physica 1997.
Högl, M., Derszteler G., Vom Business Process Reengineering zum Workflow-Management, Ein Vorgehensmodell zur Einführung effizienter, DV-gestützter
Geschäftsprozesse, in: DV-Management 7 (1997) 1, S. 28 - 33.
Jablonski, S., Bussler, C.: Workflow Management. Modeling Concepts, Architecture and Implementation. London et al.: International Thomson 1996.
Jablonski, S., Workflow-Management-Systeme, Modellierung und Architektur, Bonn:
Thomson 1995.
Jablonski, S., Anforderungen an die Modellierung von Workflows, in: Österle, H., Vogler, P.
(Hrsg.), Praxis des Workflow-Managements, Grundlagen, Vorgehen, Beispiele, Braunschweig - Wiesbaden: Vieweg 1996, S. 65 - 81.
Jablonski, S., Architektur von Workflow-Management-Systemen, in: Informatik, Forschung und Entwicklung 12 (1997) 2, S. 72 - 81.
Joos, B., Endl, R., Tombros, D., Evaluation von Workflow-Management-Systemen,
SWORDIES Report Nr. 3, Institut für Wirtschaftsinformatik, Universität Bern 1997.
Joosten, S., Trigger Modelling for Workflow-Analysis, in: Chroust, G., Benczur, A. (Hrsg.), Workflow Management: Challenges, Paradigms and Products, Conference Proceedings of CONnectivity '94, Linz, October 19-21, München: Oldenbourg 1994,
S. 236 - 247.
Kappel, G., Lang, P., Rausch-Schott, S., Retschitzegger, W., Workflow Management based on Objects, Rules and Roles, in: IEEE Data Engineering Bulletin 18 (1995) 1, S.
11 - 18.
Karl, R., Deiters, W., Workflow Management, Groupware Computing, Studie über SAP Business Workflow, Release 3.1, 2. Aufl., Pfaffenhofen: dsk 1997.
Keller, G., Nüttgens, M., Scheer, A.-W., Semantische Prozessmodellierung auf der Grundlage ereignisgesteuerter Prozessketten (EPK), in: Veröffentlichungen des Instituts für Wirtschaftsinformatik, Heft 89, Universität Saarbrücken 1992.
Kilov, H., Ross, J., Information Modeling. An Object-Oriented Approach, Englewood Cliffs:
Prentice Hall 1994.
Knolmayer, G., Endl, R., Pfahrer, M., Schlesinger, M., Geschäftsregeln als Instrument zur Modellierung von Geschäftsprozessen und Workflows, Arbeitsbericht Nr. 105, Institut für Wirtschaftsinformatik, Universität Bern 1997.
Kradolfer, M., Geppert, A., Modeling Concepts for Workflow Specification, Arbeitsbericht, Institut für Informatik, Universität Zürich 1997
Krcmar, H., Schwarzer, B., Prozessorientierte Unternehmensmodellierung - Gründe,
Anforderungen an Werkzeuge und Folgen für die Organisation, in: Scheer, A.- W. (Hrsg.), Prozessorientierte Unternehmensmodellierung, Gabler: Wiesbaden 1994.
Kurbel, K., Nenoglu, G., Schwarz, C., Von der Geschäftsprozeßmodellierung zur
Workflowspezifikation - Zur Kompatibilität von Modellen und Werkzeugen, in: HMD - Theorie und Praxis der Wirtschaftsinformatik 34 (1997) 198, S. 66 - 82.
Mallens, P., Business Rule Automation, Naarden: USoft 1997.
Meyer, M., Pfahrer, M., Erfahrungen beim Einsatz von SAP Business Workflow und IBM FlowMark, Arbeitsbericht Nr. 93, Institut für Wirtschaftsinformatik,
Universität Bern 1997.
Meyer, M., Wimmer, F., Bedeutung und Einsatz von SAP Business Workflow in der Schweiz, Arbeitsbericht Nr. 108, Institut für Wirtschaftsinformatik, Universität Bern 1998.
Nippa, M., Picot, A. (Hrsg.), Prozeßmanagement und Reengineering: Die Praxis im deutschsprachigen Raum, Frankfurt a. M. - New York: Campus 1995.
Rosemann, M., zur Mühlen, M., Modellierung der Aufbauorganisation in Workflow- Management-Systemen: Kritische Bestandsaufnahme und
Gestaltungsvorschläge, in: EMISA Forum, Mitteilungen der GI-Fachgruppe 2.5.2 "Entwicklungsmethoden für Informationssysteme und deren Anwendung"
7 (1998) 1, S. 78 - 86.
SAP AG (Hrsg.), R/3 System Release 3.1G, Online Documentation, Compact Disk, Walldorf 1997a.
SAP AG (Hrsg.), SAP Business Workflow - Einsatz und Konfiguration, Kursunterlagen zum Kurs BC 085, Regensdorf 1997b.
Scheer, A.-W., ARIS - Vom Geschäftsprozeß zum Anwendungssystem, 3. Aufl., Berlin et al.:
Springer 1998.
Siebert, R., Anpassungsfähige Workflows zur Unterstützung unstrukturierter Vorgänge, in:
EMISA Forum, Mitteilungen der GI-Fachgruppe 2.5.2 "Entwicklungsmethoden für Informationssysteme und deren Anwendung" 7 (1998) 1, S. 87 - 90.
Teufel, S., Sauter, C., Mühlherr, T., Bauknecht, K., Computerunterstützung für die Gruppenarbeit, Bonn et al.: Addison-Wesley 1995.
Vogler, P., Jablonski, S., Editorial, Workflow-Management, in: Informatik 5 (1998) 2, S. 2.
Weiß, D., Krcmar, H., Workflow-Management: Herkunft und Klassifikation, in:
Wirtschaftsinformatik 38 (1996) 5, S. 503 - 513.
Weske, M., Überlegungen zur Flexibilisierung von Workflow-Management-Systemen, in:
EMISA Forum, Mitteilungen der GI-Fachgruppe 2.5.2 "Entwicklungsmethoden für Informationssysteme und deren Anwendung" 7 (1998) 1, S. 91 - 95.
WfMC (Hrsg.), The Workflow Reference Model, TC00-1003, Issue 1.1, 1994,
http://www.aiim.org/wfmc/DOCS/refmodel/rmv1-16.html [Stand: 1998-04- 16].
Zarri, G.P, Azzam, S., Building up and making use of corporate knowledge repositories, in:
Plaza, E., Benjamins, R. (Eds.), Knowledge acquisition, Modeling and
Management, 10th European workshop, EKAW’97, Berlin et al.: Springer, pp.
301 – 316.
