The Usefulness of Process Models: A Lifecycle ... - CiteSeerX

The Usefulness of Process Models: A Lifecycle Description of how Process Models are used in Modern Organisations * Peter Kawalek and Peter Kueng Peter Kawalek, Department Computer Science, University of Manchester, England. Tel. +44 161 275 6183; Fax +44 161 275 6286; Email [email protected] Peter Kueng, Institute of Informatics, University of Fribourg, Switzerland Tel +41 26 300 83 22; Fax +41 26 300 97 26; Email [email protected]

Abstract Considerable attention has been given to the development of process modelling methodology over a number of years. As well as being used for the traditional concerns of analysis and design, executable process models have been developed in order to facilitate the implementation and evolution of systems. This paper investigates whether and how process models are useful. To answer this question a simple system development life cycle is set out, and at each stage the use of process models is described from accounts given in the literature and from practical experience. The process models considered in these accounts are both the conceptual forms and the executable forms of models. Our conclusions are that process models are still best understood and most successfully used as traditional analysis and design tools. Their usefulness in implementation is less obvious even in projects where the transfer of these technologies was a specific aim. We propose that further research should be done and we advocate the rigorous reporting of process modelling projects.

1 Introduction: Towards an Assessment of the Usefulness of Process Models Many writers (e.g. Beer, 1979; Handy, 1992; Trisoglio 1995) have described how modern organisations are confronted by turbulent operational conditions caused by a network of inter-related factors such as competition in the global market-place, changing customer expectations and technological innovation. The result is that these organisations are themselves not only complex but dynamic. They can be described as complex because they are made up of many interrelated parts arranged in some structure (e.g. federal, hierarchical) and the intricacies of the interrelationships between any combination of parts cannot be understood except by those taking part in them. They can be described as dynamic because they change their functions in order to innovate or respond to market conditions with resultant changes in the fabric of the organisation itself (e.g. its structure, its technology, its skills profile, its manpower level).

1

* This

paper has been published in Proceedings of the Second CAiSE/IFIP8.1 International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design; Barcelona, 16-17 June 1997, Keng Siau et al. (eds.).

1.1 From Analysis to Evolution: The Many Uses of Process Models In seeking to manage these difficult operational conditions, a number of sources have proposed the use of process modelling techniques towards the achievement of a number of different objectives. Snowdon (1997) characterises process modelling through its concern for the dynamic behaviour of organisations, businesses or systems more generally. Today there are a range of innovations in process modelling which extend the established concerns for analysis and design, and embrace the utilization of process models in the programming and implementation of high level systems, and the codifying of system evolution. Three prominent research communities – Software Process, Workflow and Business Process Reengineering (BPR) – have contributed to these developments. Working in different domains (i.e. software development and business in general) these communities have focused attention on the development of process modelling notations, design editors, executable modelling languages, change mechanisms and simulation tools. According to Curtis et al. (1992), process models may be usefully utilised in the following five areas: (1) facilitating human understanding and communication; (2) supporting process improvements; (3) supporting process management; (4) automating process guidance, i.e. supporting the use of tools for manipulating process descriptions; (5) automating execution support. Moreover, the use of process models is advocated as a facilitator for organizational learning (Schäl, 1990; Senge, 1993), towards benchmarking a companies performance (Childe & Smart, 1995), and in order to support process evolution (Robertson, 1996). Elsewhere, a critical perspective has been given by Wastell (1996) who argues that techniques such as process and data modelling can be used as a social defence to avoid meaningful engagement with the task at hand. 1.2 The Concerns of this Paper This paper seeks to provide an assessment of the usefulness of process models. It is motivated by the observation that whilst there is much literature which advocates either process modelling as a general approach or process modelling techniques in particular, little attention has been given to the empirical assessment of these techniques nor to describing the purposes to which they are applied. Given the paucity of literature available in this area, this paper does not pretend to be anything other than an initial report. It is part of an ongoing programme which shall aim to gather and examine evidence of the usefulness of process modelling techniques across a range of different uses. 1.2.1 The Lifecycle Model Given the wide range of ways in which process modelling techniques are used, and their contribution to many different aspects of organisational and IT systems development, the investigation 2

is structured using a simple lifecycle model. This describes analysis, design and implementation phases. The scope of each of these is introduced later. 1.2.2 The Practical Accounts The empirical accounts given in this paper have been gathered from a number of sources. Pseudonyms are used in all cases. Two cases are based in England and one in Switzerland. The English cases are of Burgess Petrochemicals and Amis Engineering. These refer to a company involved in the manufacture of chemicals and a research organisation involved in special engineering projects. Through collaborative technology transfer programmes undertaken with the University of Manchester, both of these companies were introduced to process modelling techniques in analysis and design, as well as more novel technology which allows a process description created in the process modelling language PML™ to be executed. Data collection was carried out by questionnaires submitted to investigators on process modelling projects in each company. This questionnaire featured thirty one closed questions and six open ended questions. The closed questions asked the investigators to grade features of process models according to whether they were ‘Essential’, ‘Very useful’, ‘Some marginal use’, or ‘No use’. A further category of ‘No relevant experience/do not understand the question’ was also provided. The Swiss case is of Matterhorn Drug, a company which produces pharmaceutica. Matterhorn Drug is one out of four partners which participates in the project ‘PROMOSYS – A Monitoring System for Information-based Business Processes’ initiated by Fribourg University. As part of this project, the participants create process models and use them for various activities. The second author was a collaborator in this project. In addition, data was also collected using the same questionnaire as was used for the English projects. The process modelling techniques used in all three case studies were variously Role Activity Diagrams (RADs) (Ould, 1995), IDEF0 (Rock-Evans, 1992; Mayer et al., 1995), Petri-nets (Billington & Reisig, 1996; Kueng et al., 1996), State Transition Diagrams (STDs) (Yourdon, 1989) and the process modelling language PML™ of the process support system PWISE™

(Snowdon & Warboys, 1994). 1.3 Process Models Wilson (1990) defines a model in the following way: “A model is the explicit interpretation of one’s understanding of a situation, or merely of one’s ideas about that situation. It can be expressed in mathematics, symbols or words, but is essentially a description of entities, processes or attributes and the relationships between them. It may be prescriptive or illustrative, but above all, it must be useful” (p. 11). To Beer et al. (1988), a model is “a representation of something else, designed for a special purpose.” They suggest: “All models have one characteristic in 3

common, whatever their purpose. This characteristic is the mapping of elements in the system modelled into the model.” A much more pragmatic and technique-oriented definition is given by Davenport (1993) as he defines a process as “a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs: a structure for action” (p. 5). It follows from these definitions that, in the broadest sense, a process model must be an abstraction of the behaviour of some system which shows the relationships between elements (e.g. activities, actors, tools) of that system.

2 The Usefulness of Business Process Models in the Analysis Phase 2.1 Introduction In our lifecycle model, the analysis phase refers to investigations which aim to facilitate a better understanding of the current patterns of operation in an organisation. Such investigations will typically act as a pre-cursor to a business redesign or IT development but they may also be self standing activities which serve only as a process audit. 2.2 The Contribution of Process Models in the Analysis Phase There has been some debate as to whether or not it is useful to use process models in an analysis phase, or indeed whether it is useful to undertake an analysis phase at all. The main opposition has come from Hammer and Champy for whom “putting aside much of the received wisdom of two hundred years” and “forgetting how work was done” is an integral part of BPR (1993, p. 2). Set against this radicalism is the tradition established by the structured methods of IT development of undertaking intensive analysis prior to design. To Ould, even where radical change is the motivation, there may be benefits gained from using process models in an analytical way. He writes that “broad-brush models of the way our business operates, of what processes we have and how they traverse the functional silos, could give us clues as to the sorts of change we might imagine” (1995, p. 5). For Kawalek (1995), process analysis can be part of the ongoing management of an organisation which is undertaken by stakeholders of different levels of seniority as part of their ongoing learning. Thus, in an analysis phase process models can act “as a sort of searchlight on the process” (Ould, 1995, p. 151). They can be used in interviewing actors, managers and other stakeholders. They can form a part of laboratory experiments, benchmarking exercises and can be created through ethnography. The model is used to reveal the process, the roots of its problems, and potential ways of attacking the trouble (Ould, 1995, p. 151).

4

2.3 Practical Accounts: The Case of Matterhorn Drug The project took place within the finance department, with about 80 collaborators, of the company Matterhorn Drug. The goal of the project was to analyse the four main financial processes and to improve them incrementally. From the beginning it was clear that the four processes had to be represented by process models. The initial effort to use the modelling tool ARIS™ was relatively high, but after a couple of weeks, the ‘chief modeller’ felt quite happy with the tool. This then lead to an enormous activity, and as a result the ‘chief modeller’ came out with process documentation of about 150 pages. The four process teams accepted the labour required to create these models although, in fact, the detailed documentation has never been used as a real working basis. One process team then began to document its process by themselves. This was done using a simple diagramming tool rather than a sophisticated modelling tool. After a short time they had depicted their process on just one sheet of A4 paper. This small document was of restricted usefulness: it gave an overview of the process which was useful for people who worked outside of it, but was not able to offer the process team a further insight, because the level of abstraction was too high. After a couple of weeks, the four teams within the finance department came to the conclusion that it was important to get a wider view of their process. In particular, they wanted to know how well their support-processes fit to the order process, i.e. the core process which has to be served by the financial processes. In order to do this, the four financial process teams and the order process team arranged a conjoint workshop in which they sought to gather the weaknesses of the overall business process. The chosen approach was ‘social simulation’. The principle of social simulation is that the real actors (or a selection of them) sit together and carry out some business cases. A token shows the sequence of the work flow. Each participant tells how he or she is carrying out the assigned activities, what difficulties are appearing, and who the communication partners are. Prior to the social simulation a rather general process model had been created, in co-operation between the moderator and the process teams. As a result, it was seen that the social simulation was well suited for analysing business processes and that the process model was a prerequisite to carry it out. The process model played in a way the role of a hub, a central means of facilitating the communication between the team members. What are the conclusions of this case study? Firstly, we can say that any assumption that “the more decomposed a process model, the more useful it is” has to be rejected. It revealed also that the appropriate level of decomposition cannot be defined in advance, it can only be identified by trial and error. Secondly, the process of composing a model may be as important as the model itself. In the cited case, the activities of the ‘chief modeller’ lead to an intensive effort to facilitate communication between the actors and the designer. Through this communication, the process 5

team got a better understanding of the different processes. Or to put it differently: had the ‘chief modeller’ not done his extensive work, the process teams would have had a much harder job.

3 The Usefulness of Business Process Models in the Design Phase 3.1 Introduction In our lifecycle model, the design phase refers to investigations which aim to facilitate the decision making process in the development or redevelopment of an aspect of the operation of an organisation. This may be through changes in the structure of an organisation, cultural changes, new technology or, most probably, through a combination of factors. The design phase will typically overlap with a later implementation phase wherein the decisions taken are brought into effect. It may or may not be preceded by an analysis phase. 3.2 The Contribution of Process Models in the Design Phase In the design of a new organisational process or IT system, difficult social and technical issues may be confronted as a complex interplay of forces becomes manifest. The design phase embraces the formulation and examination of proposals, the testing of hypotheses, the voicing of different perspectives and interests, discussion, and the attempted reconciliation of perspectives or the triumph of one over another. There are many accounts in the literature which testify to the great significance of social issues (e.g. Checkland & Scholes, 1990). The complexity of the design process and its impact upon the form of the finished artefact has been recognised and studied by other disciplines. For example, architecture and town planning have paid much attention to the impact of different design processes (e.g. formal consultation, community architecture etc.) upon the form, cost, and eventual success of the technical artefact produced. Various modelling mechanisms will be used by an architect as she or he is faced with the problems of designing a complex artefact and the need to secure the support of various different stakeholders (e.g. client, users, local authorities). Just as an architect will model a new building or settlement, the process designer will use some kind of notation to depict aspects of a business and its support systems. The authors reference work which propose the use of process modelling techniques both in the design of an IT system and in assisting the broader socio-technical changes which accompany it (Kawalek, 1995; Kueng & Kawalek, 1997; Ould, 1995; Warboys, 1997). Used towards these ends, high level process models act as a kind of bridge between the users descriptions of their behaviour and the design of the IT support systems which are essential to the users. Increasing attention is being given by researchers to high level models which can themselves be executed as

6

part of an implementation phase (Bruynooghe et al., 1991; Schäl, 1996; Snowdon, 1996; Swenson & Irwin, 1995). A problem for the designer is that some aspects of an organisation may be easily visualized by process models, whereas other aspects are more subtle and elusive. In the first category may be organisational aspects such as process, control, dataflow, roles and goals (Kueng et al., 1996). Other aspects of the organisational milieu which are more difficult to represent in a model are organisational power, skill requirements, management style, staff motivation, organizational norms and symbols, incentives and rewards. Thus, the process modeller works with a restricted vocabulary leading to the danger of concentrating only on those aspects which can be satisfactorily represented in the model to the exclusion of more subtle, but important, factors. Wastell’s critical commentary upon methodology in general showed how the application of structured methods in software engineering can lead to a ritualistic way of working (e.g. users sign-off the presented documents without having a sound understanding) and may inhibit creative thinking: “Methodology (...) may operate as an irrational ritual, the enactment of which provides designers with a feeling of security and efficiency at the expense of real engagement with the task at hand” (Wastell, 1996, p. 25). 3.3 Practical Accounts The project at Amis Engineering is concerned with the creation of software support for a project management process. Technology transfer is an explicit part of its aims and, as well as utilizing some novel techniques in an analysis phase, the project has sought to utilize process modelling in the design and implementation phases. As well as graphical techniques the project utilizes the ICL ProcessWise Integrator™ (PWISE) and its high level, textual programming language PML™. Commenting upon the usefulness of Role Activity Diagrams (RADs) and State Transition Diagrams in the design of a project management system at Amis Engineering, the designer most concerned with these aspects described them as “Very useful.” However, he also highlighted how the use of the executable language PML™ across the design and implementation phases can be useful. He wrote: “The most effective way of facilitating change has been in building the PWISE prototype. The diagrams (RADs) were too abstract – they (the users) wanted to see what it (the diagrammatic model) would translate to.” At Burgess Petrochemicals the use of process models in the design phase was also described as “Very Useful.” Here RADs were the fulcrum of an approach which also included application of the Booch methodology, Data Flow Diagrams (DFDs), Hammer’s process maps, and Soft System Methodology (SSM). The experience seemed to validate this multi-notation approach. The designer wrote that RADs were “..extremely useful for modelling people intensive, cross depart7

mental, task intensive processes. DFDs were inappropriate.” However, RADs also had limitations where a process was characterized by “non-conformances” and “exceptions”. The designer wrote: “Identifying ‘exceptions’ to a process is key to finding improvements, or defining more specific requirements for a new IT system. RADs were not successfully used but SSM offered a more flexible approach.”

4.0 The Usefulness of Business Process Models in the Implementation Phase 4.1 Introduction The implementation phase covers the activities associated with putting design decisions into practice; e.g. introducing a new process design and IT support. It is likely to be closely associated with the design phase because of the need to revaluate design decisions and assumptions as the implementation proceeds. 4.2 The Contribution of Process Models in the Implementation Phase That software systems can themselves be understood as models is an argument made in several places (e.g. Greenwood et al., 1995; Lehman, 1985; Snowdon, 1996). The value of having a high level executable model which retains value as a description by virtue of having a simple mapping with its domain is an issue addressed by Jacobson et al. (1994) and Kawalek (1995). While process models in the analysis and design phase are used on a conceptual level to define the processes, to evaluate the processes and to learn about the processes, in the implementation phase they will be used to compose an IT system which supports the execution of a business process. To support or automate business processes with IT, processes have to be expressed in a language which is interpretable by a computer. To achieve this either a low-level language or a high-level (and probably graphical) language can be used. As today’s workflow management systems – IT systems which support the coordination, control, and communication of workflow execution – are usually equipped with graphical user interfaces, the use of these high-level process definition languages has become more and more popular (Georgakopoulos et al., 1995; Waria, 1997; WfMC, 1997). There are many issues associated with this trend. For example, it has been reported that a high-level model (possibly in a graphical form) cannot be reliably translated into an executable system even when this model has been validated by users. It is suggested that this is because users will make assumptions about the model and intuitively treat it as an abstraction, whereas to a compiler it is a literal set of instructions; cf. (Glass, 1996) or (Kawalek, 1996). A further interesting aspect has been raised by Senge (1993). He points out that process models can play the role of so called “transitional objects.” These are objects which are used to facilitate learning about a complex situation so that people are able to make a transition to a new viewpoint 8

or state. They perform a similar function to toys and play in childhood, whereby the child is able to explore the nature of reality, but are used in the ongoing management of complexity e.g. by underwriters, bankers, managers, etc. According to Senge, process models make it possible to compose a microworld, a microcosm of reality where “it is safe to play” (1993, p. 314). 4.3 Practical Accounts At Amis Engineering one investigator reported that RAD process models were ‘very useful’ in the implementation phase. A second investigator was less enthusiastic, describing RADs as of ‘some marginal use’. He commented that the diagrams had “insufficient detail” and that they “need to be combined with other graphical representations”. Implicit in these comments is a belief that graphical models can be useful in the implementation phase, if they are detailed enough. The investigator at Burgess Petrochemicals was less circumspect, declaring the graphical notations he used to be ‘essential’ in the implementation phase and he emphasised their role as communication devices where there are management expectations. The investigator also commented on the use of executable modelling formalisms (e.g. PML) noting that when it later comes to changing systems, there are advantages if the process is “very visible” in the code. What are the main conclusion we can draw? Firstly, the use of explicit process models in the implementation of IT systems is still novel: technology transfer was an explicit aim of the Amis Engineering and Burgess Petrochemicals projects. Further efforts on technology transfer and further technological improvement are necessary if there is to be a broader penetration of process models within the implementation phase. Secondly, this is not a utopian solution. We do not envisage a time when users will simply compose a process in some graphical form and have a sophisticated compiler generate the required code. Rather, we envisage practical benefits resulting from the comprehensibility and manageability of systems, but alongside these benefits we envisage the need for a disciplined approach to the architecture of IT systems. Thirdly, the creation of both process models and process-support systems is an act which needs participation and iteration. The use of high level executable models helps all concerned to understand that the users and designers belong to the same work group.

5 Lessons Learned and General Conclusions Drawing upon general lessons from the cases studies we present the following findings of this report:

• In the analysis and design phase it is important to use a notation which is easily understandable to the process participants. The actual notation used is of secondary importance; it is more important that the process team feel comfortable. 9

• While creating a process model, communication is extremely important. Otherwise, the model – even if it is perfectly from a technical point of view – will not be accepted and used by the process team. It is therefore not surprising that the composition of a process model takes time – rather months than weeks.

• The evidence is that process models are an essential prerequisite in order to design and implement a new or a modified business process. They help integrating the technical aspects and the organisational issues.

• The appropriate level of aggregation (process decomposition) can only be identified by trial and error. This means that, assuming a top-down methodology, we decompose a process model until we recognize that we have gone too far. Then we have to go one step back. Furthermore it may be useful to take some parts of the too detailed model out and to rearrange the model at the higher level.

• A process model must not be seen as a method. A process model is an instrument, a facilitator which is able to support different methods, in the analysis and design phase as well as in the implementation and evolution phase.

• The process of creating the model is a learning process. In their creation, knowledge is gathered, assumptions are tested and dilemmas are confronted. Therefore, it is not just the process model as a product which has a positive impact, it is also the act of creating a process model.

• Rigorous reporting of process modelling projects will help to develop an understanding of their usefulness across the lifecycle.

6 Acknowledgments. The authors would like to thank the researchers at “Amis Engineering,” “Burgess Petrochemicals” and “Matterhorn Drug.”

7 References Beer, S. The Heart of Enterprise, John Wiley & Sons, Chichester, 1979. Beer, S., Strachey, C., Stone, R., Torrance., Model in Bullock, A., Stallybrass, O., Trombley, S., (eds.) The Fontana Dictionary of Modern Thought, revised edition 1988, Fontana, London. Billington, J. and Reisig, W. (eds.), Application and Theory of Petri Nets, Springer, Lecture Notes in Computer Science 1091, Berlin, 1996.

10

Bruynooghe, R.F., Parker, J.M., Rowles, J.S. “PSS: A System for Process Enactment,” in Proceedings of the First International Conference on the Software Process, M. Dowson (ed.), Manufacturing Complex Systems, Redondo Beach, California. IEEE Computer Society Press, Los Alamitos, pp. 128-141. Checkland, P. and Scholes, J. Soft Systems Methodology in Action, John Wiley & Sons, Chichester, 1990. Childe, S., Smart, A. “The use of process modelling in benchmarking,” in Benchmarking: Theory and Practice, Proceedings of the IFIP WG5.7 Workshop, Trondheim, 16-18 June 1994, A. Rolstadas (ed.), Chapman & Hall, London, 1995, pp. 190-199. Curtis, B., Kellner, M., Over, J. “Process Modelling,” Communication of the ACM, (35:9), September 1992, pp. 75-90. Davenport, T. Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, Boston, 1993. Georgakopoulos, D., Hornick, M. and Sheth, A. “An Overview of Workflow Management: From Process Modelling to Workflow Automation Infrastructure,” Distributed and Parallel Databases, (3:2), April 1995, pp. 119-153. Glass, R.L. “Some Thoughts on Automatic Code Generation,” The DATA BASE for Advances in Information Systems, (27:2), Spring 1996, pp. 16-18. Greenwood, R.M., Robertson, I., Snowdon, R.A., Warboys, B.C. “Active Models in Business,” in Proceedings of 5th Annual Conference on Business Information Technology, BIT ‘95, Department of Business Information Technology, Manchester Metropolitan University, 1995. Hammer, M. and Champy, J. Reengineering the Corporation: A Manifesto for Business Revolution, Nicholas Brealey Publishing, London, 1993. Handy, C. “Balancing Corporate Power: A New Federalist Paper”, Harvard Business Review, NovemberDecember 1992. Jacobson, I., Ericsson, M., Jacobson, A. The Object Advantage: Business Process Reengineering With Object Technology, Addison Wesley, Wokingham, 1994. Kawalek, P. “An introduction to a process engineering approach and a case study illustration if its utility,” in Re-engineering the Enterprise, J. Browne and D. O’Sullivan (eds.), Chapman & Hall, London 1995, pp. 248-272 Kawalek, P. A Method for Designing the Software Support of Coordination, PhD Thesis, University of Manchester, December 1996. Kueng, P., Bichler, P., Kawalek, P. and Schrefl, M. “How to compose an Object-Oriented Business Process Model?” in Method Engineering: Principles of method construction and tool support, S. Brinkkemper et al. (eds.), Chapman & Hall, London, 1996, pp. 94-110. Kueng, P. and Kawalek, P. “Goal-Based Business Process Models: Creation and Evaluation,” Business Process Management Journal, (3:1), April 1997, pp. 17-38. Lehman, M.M., “Approach To A Disciplined Development Process: The ISTAR Integrated Project Support Environment,” Presentation to the Second Process Workshop, Coto de Caza, Imperial College of Science and Technology Research Report 85/19, Imperial College, London, 1985. 11

Mayer, R., Benjamin, P., Caraway, B., Painter, M. “A Framework and a Suite of Methods for Business Process Reengineering,” in Business Process Change: reengineering, concepts, methods and technologies, W. Kettinger and V. Grover (eds.), Idea Group Publishing, Harrisburg, PA, 1995, pp. 245-290. Ould, M. Business Processes: Modelling and Analysis for Re-engineering and Improvement, John Wiley & Sons, Chichester, 1995. Robertson, I. “An Implementable Meta-Process,” in Proceedings of International Design and Process Technology Conference, Austin, Texas, December 1996. Rock-Evans, R. Data Modelling and Process Modelling: Using the Most Popular Methods, Computer Weekly Professional Series, Butterworth-Heinemann, Oxford, 1992. Senge, P.M. The Fifth Discipline: The Art & Practice of The Learning Organization, Century Business, London, 1993. Schäl, T. Workflow Management Systems for Process Orgaisations, Springer, Lecture Notes in Computer Science 1096, Berlin, 1996. Snowdon, R.A. “Active Models and Process Support,” in Software Process Technology Proceedings of the Fifth European Workshop, EWSPT ’96, C. Montangero (ed.), Springer, Lecture Notes in Computer Science 1149, 1996, pp. 93-98. Snowdon, R.A. “Overview of Process Modelling,” available: http://www.cs.man.ac.uk/ipg/Docs/ pmover.html, accessed 13th March 1997. Snowdon, R.A. and Warboys, B.C. “An Introduction to Process-Centred Environments,” in Software Process Modelling and Technology, A. Finkelstein, J. Kramer and B. Nuseibeh (eds.), Research Studies Press, Taunton, England, 1994, pp. 1-8. Swenson, K.D., Irwin, K. Workflow Technology: Tradeoffs for Business Process Re-engineering, Proceedings of the Conference on Organizational Computing Systems, Milpitas, California, August 1995. Trisolgio, A. “Managing Compexity,” working paper, London School of Economics and Political Science, 17 July 1995. Waria: Workflow And Reengineering International Association, “Workflow and BPR Tools,” available: http://www.waria.com/waria/gw4wfven.html, accessed 5th February 1997. Warboys, B. Business Systems Engineering: A Process Approach, Informatics Process Group, Department of Computer Science, University of Manchester, 1997 (in preparation). Wastell, D. “The fetish of technique: methodology as a social defence,” Information Systems Journal (6:1), January 1996, pp. 25-40. WfMC: Workflow Management Coalition, available: http://www.aiai.ed.ac.uk/WfMC/, accessed 15th March 1997. Wilson, B., Systems: Concepts, Methodologies and Applications, Second Edition, John Wiley & Sons, Chichester, 1990. Yourdon, E. Modern Structured Analysis, Prentince-Hall, Englewood Cliffs NJ, 1989.

12