The Metamorphoses of Workflow Projects in their ... - Semantic Scholar

Metamorphoses of workflow projects

1

The Metamorphoses of Workflow Projects in their Early Stages Thomas Herrmann, Marcel Hoffmann Informatics & Society, University of Dortmund August-Schmidt-Str. 12, D-44227 Dortmund, tel: +49 231 755 4715, fax: +49 231 2012, e-Mail: [email protected], [email protected]

Empirical studies on workflow usually focus on systems which have already been introduced and on the problems with these systems which mainly occur when handling exceptions. This study focuses on the problems occurring in the early stages of projects which intend to introduce workflow systems but do not necessarily succeed: In most cases of the companies under our investigation other types of software were introduced or the business processes were analysed and improved but not automated. We explain this phenomenon by referring to the concept of metamorphoses as observed by Orlikowski who analysed organizational change under the conditions of groupware usage. A number of empirical details of our study of seven companies during a three year period can be related to this concept as well as to literature on workflow: Summarizing our experience we come to a somehow irritating conclusion which we call the workflow paradox: It is sensible under certain circumstances to accept requests for workflowintroduction and to commence such a project since this might be the most promising way leading to alternative solutions.

Thomas Herrmann, Marcel Hoffmann

1

2

Introduction

Almost unnoticed from the point of CSCW-research, workflow management systems have matured and became a tool which is integrated in several standard products for content management, knowledge management, Enterprise Resource Planning (ERP) as well as collaboration tools (such as IBM-Notes platforms). For CSCW-research, workflow systems are still a multi-facetted phenomenon which stimulate reflections on categories, anticipatibility and designability of work practices and the role of technology and computerized artefacts for coordination and control of collaboration (e.g. Suchman, 1995; Schmidt, 1999). Empirical studies on workflow systems generally focus on systems which are or have been in use, and they mainly analyse the factors which lead to success or failure. This approach has delivered valuable results and especially supports the need for exception handling (e.g. Saastamoinen & White, 1995) and adaptive workflow systems (JCSCW, 3-4/2000). However, these studies do not shed light on those situations where the management had originally planned to introduce a workflow system and had to accept that other organizational or technical solutions would eventually be more feasible. We strongly suggest to pay more attention to the phases where the projects of introducing a workflow management system are conducted. The question of how these phases eventually shape the way of carrying out business processes in a company can be much more relevant than the processes when the usage of a workflow system starts. This suggestion is based on the following experience: We analyzed three workflow projects where we were directly involved and four others from which we received detailed reports. We use the term workflow project in all cases where the management has initiated activities which aim at the innovation, standardization and automatic coordination of business processes by workflow management software. We found that during the majority of these projects, the original intentions had changed and that breakdowns and subsequent adaptation of the projects’ procedures and approaches lead to results being much different from those which had been planed when the projects had started. This metamorphosis had affected the technical or organizational aims which were assigned at the start of the workflow project. In most cases, the metamorphosis was also mirrored by the procedures of the project itself. The assumption that the influence of the workflow project can be highly relevant is backed by the following observations: Most companies recognize the potential problems with exception handling in the case of workflow management, but problems with exceptions are not the main reasons for the metamorphoses which occur during the workflow projects. It might be that a considerable portion of workflow-systems, which have already been introduced, fail because of problems with exception-handling. In these situations, an improved adaptability of workflow systems might be the right answer. However, in our case studies we met many problems that occurred during the configuration and introduction of a workflow solution and that were not caused by the software’s support for exception handling or for


3

adaptability. A large portion of workflow projects, where the system is not introduced, end up with a non-workflow-system-solution. The evolutionary process which changes the way of how an organization adopts a new technology, uses it and possibly adapts it (see Orlikowski, 1996), does not only start after the system is introduced but much earlier when the project of introduction starts. This might even lead to the decision that the originally planned system (e.g. a wms) is replaced by an alternative. If the original technical aims of a workflow project are undergoing a metamorphosis, instead of workflow the whole spectrum of groupware solutions comes into consideration as well as other types of systems such as document management systems or enterprise resource planning solutions. Enterprises think more positively about workflow systems than about other groupware solutions since workflow systems are the genuine ally of business process re-engineering and they promise a technologically enforced standardization and process acceleration. However, the learning process during the workflow project can frequently lead to a withdrawal or to a non-workflow groupware-solution. Our findings have to be related to some typical characteristics of workflow projects. It is typical that they have a high organizational impact. The business processes (business processes) being the subject of these projects have to be analysed and described (usually with diagrams) so as to provide a sensible basis to configure and parameterise the workflow engine. On the basis of rough business process models more detailed representation of the workflows are constructed with the build-time component of the workflow management system (wms). Afterwards, the run-time component can be used to execute these formal descriptions. The explicitness of the business process (bp) models offers an opportunity to improve the processes. The improved models can be used to change the organization when a workflow system is introduced – or even without a wms. The tendency to a deliberate design of improved business processes can be related to the approach of business process reengineering (Hammer & Champy, 1994) and – of course – is linked with the traditions of centralized work rationalizations. Usually, the companies want to identify their key-business processes and/or they want to accelerate them and increase quality by improving the coordination between different tasks and by standardizing work procedures. Following the business process engineering argumentation, workflow projects frequently aim at supporting entire business processes, e.g. from customer requests to the delivery and settlement of services or products. As a result, they usually affect a large number of employees – or their roles – in different departments. Their knowledge is indispensable for the improvement of business processes, since the reality of the business processes and their perception on management level are quite different. This difference usually becomes apparent during workflow projects as well as the insight that the business process improvement needs a certain extent of organizational learning (Senge, 1990).


4

Our analysis aims on the metamorphoses of workflow projects and accompanying hypotheses. It is structured in the following way: Chapter 2 describes the methodological background and gives an overview of the different types of companies we worked with. In chapter 3 we refer to related work and the theoretical background which has inspired our studies as well as the interpretation of the findings. Although new insights and the most important point of our study are mainly based on empirical findings, the theoretical part is relatively elaborate since there is a wealth of considerations which concern workflow in particular as well as the relationship between technology and organizational development in general. The wide scope of these theoretical and literature-based considerations cannot be ignored but has to serve as a basis for the interpretation of the data. Our empirical results are described in the following chapters (4-6). In chapter 4 we explain the initial goals and expectations which were assigned to the projects and the different problems the companies had with these goals. In chapter 5 firstly we describe the metamorphoses which concerned the original plans of the projects’ procedure, and then in chapter 6 we outline any alterations to the original organizational and technical solutions. Chapter 7 – our conclusion – deals with the paradox role of workflow projects and with the arguement that light weight process models could serve as a basis to support coordination of cooperative work if their development is integrated with concepts of organizational learning and knowledge management.

2

The design of the investigation

The original goal of the research design was to observe the way in which companies that are introducing wms deal with the conflict between standardization and flexibility. We intended to analyse how far empirical findings and recommendations being documented in the literature can inform workflow projects. We wanted to know how this influence contributes to the requirements of engineering for technical solutions as well as whether an improvement of the work conditions (especially freedom of decision) of the employees could be achieved. Finally, we wanted to assess how feedback from and participation of the employees could successfully be organized. The investigations were embedded in the MOVE-project, a scientific project funded by the German Federal Ministry of Education and Research from 1996 up to the year 2000. Three scientific partners, the Information Systems Group of the University of Saarland in Saarbrücken, the Fraunhofer Institute for Software and System-Technology and the Research Group Informatics and Society at the University of Dortmund, took part in the project. Of the seven companies that rounded up the project three were funded to introduce a workflow system and to support the scientific analysis. The overall goal of the project was to define organizational procedures for the introduction of workflow systems and technological requirements for the improvement of workflow technology that would


5

reflect the need for flexible and adaptable process support within modern organisations. We refer to the cooperation of all theses partners as MOVE-project. We were the coordinators of this project and actively took part as consultants and system engineers in three workflow projects. There was an intensive exchange of information and influence between all of the partners. Thus it is not reasonable to focus the empirical analysis on only one of them but to consider them as one empirical basis. 2.1

SITES

The characteristics of the seven different companies involved in the MOVEproject are presented in table 1. We intended to gather data on a set of very different companies as we intended to conduct an exploratory study which provided a variety of hints about the success indicators and barriers which had to be overcome in workflow projects. Case

Type of

Size

business

Business processes

Planned

analyzed and

technology technology

supported - Claims and complaints WMS - Contract and discount negotiations and conclusion WMS - dispatching piece good and cargo - Claims & Complaints

Introduced

non

A

Express business

70.000 employees worldwide

B

Truckage business

> 200 employees

C

Production of fixing systems

- pre-calculation of small orders - Product Data Management

WMS

D

Insurance

3000-4000 employees in 18 countries most of them in Germany 12.000 employees

Producing and printing of client information

non

E

Optical products

general improvement of business processes

F

Telecommunication

14.000 employees worldwide (10.000 in Germany) 150.000 – 200.000 employees

document management system ERP

Any processes of maintaining telephone mainlines

WMS

G

Production of agricultural machines

2700 employees in Germany

general improvement of business processes

WMS

Self designed solution integrated in existing software non

Table 1: Characteristics of the companies being part of the network

Truckage business solution based on a customary groupware application Enterprise resource planning software

ERP


6

Our decision to not only be researchers but to be actively involved as consultants was related to our expectation that we would then be able to have access to insider experience which was not usually available to scientists. We were interested in understanding how practitioners would deal with the problems of exception handling and the need for flexibility and adaptability of workflow management systems. Since we wanted to accompany all the different stages (see fig. 1) and tasks of a workflow project, we set up a team of 13 researchers with a large scope of competences for the MOVE-project: Methods of data gathering and analysing of business processes. Business process improvement from the viewpoint of human needs, industrial psychology and economical requirements Software development, configuration and adaptation System selection and evaluation 2.2

FOCUS

The research, consulting and development activities took place over a period of three years. We assumed that a whole cycle (see figure 1) of wms introduction, evaluation and following improvements could be conducted during this time. However, the decisive factors which caused a need for change and adaptation of the workflow projects happened during the early stages, encircled with a grey line in figure 1.

Modeling, analyzing, improvement

evaluation

workflowmanagementsystem

Conceptualization and implementation of technical and organizational solutions

Testing and using

workflow project

data gathering

adaptation

participation

training

Figure 1: Stages of a workflow project including continuous improvement

It proved to be a decisive advantage for our empirical work that we had already been involved in the early stages and not only after the system had been introduced. The metamorphoses we could observe were related more to organizational


7

than to technical aspects. The focus of our study was mainly oriented towards workflow management and workflow projects as a matter of organizational decision and the relevance of wms technology had shifted from a pacemaker to an option which depended on these decisions. These decisions were formed in the early stages of the workflow project and were interwoven with tasks such as gathering data about the business processes, modelling, analysing and improving business processes, development and introduction of organizational and technical concepts (including prototyping, selection and integration of technical systems), organization of participation and training of the employees. These activities are displayed in figure 1 which was developed at the end of the MOVE-project: a part of them (data gathering, training, participation) can continuously intervene into the main cycle of stages and there are also sub-cycles which lead to a partial repetition of tasks of a certain stage. The cyclic order expresses the fact that the workflow projects in our studies were intended as a procedure of continuous improvement. 2.3

METHODS OF DATA GATHERING

The data available for our study can be divided into three parts. Firstly, we collected data on work practices which was gathered through participative observations, intensive interviews, and the usage of questionnaires. During the data gathering stage we tried to obtain a holistic picture of the business processes from different perspectives (such as efficiency, work load, quality of technical support) and asked for potentials for improvement right from the beginning. Built upon this data the scientific consultants and the companies’ project members constructed diagrammatic representations of the investigated business processes, which were analysed for potential improvements of the processes and deficits in task design. To evaluate task design and to estimate the impact of organizational and technological options, specific analysis techniques were employed that are built upon psychological methods for the assessment of working conditions (Volpert et al. 1989). The diagrams and the tasks-characteristics went through several iterations of presentation, discussion, correction and refinement together with the work force. At this level we experienced the limits of representing business processes in a formal and explicit way and were faced with work practices where intuition and tacit knowledge were indispensable ingredients of successful activity. Together with captured discussions, the process models and characteristics define an analytic perspective of the work practices. On the second level we collected oral reports of researches and practitioners which were presented during nine workshops from 1998 to 2000. These workshops (lasting 1-2 days, with 15 – 25 participants) were organized by the network of the involved companies and served as opportunities to exchange reports on the progress of the workflow projects as well as to discuss the problems and recommendations which could be presented to other companies outside of the network.


8

The reports and discussions were partially documented by the presentation material and the minutes taken during the sessions. The third level of empirical data is represented by four volumes of project reports (Herrmann et al., 1998a, 1998b, 1999, 2001) which have been published to inform practitioners and application oriented researchers of the problems and to provide recommendations which should be taken into consideration when running a workflow project. The volumes include 24 papers written by scientists and four papers which had been written together with practitioners. They serve as a collection of documents which backs our empirical analysis. The topics covered the stages presented in figure 1. During an ex-post analysis as we started to consider all the empirical material together in the light of related work and theoretical approaches the metamorphoses which are described below became visible.

3

Related Work and Theoretical Approach

We did not find any literature in the field of CSCW which focuses mainly on the analysis of projects which pursue the introduction of workflow management systems. It is the main purpose of this paper to compensate this deficit. However, there is a large body of literature which provides a valuable background to our study. It deals with the relationship between organizational transformation and groupware usage, with typical problems of workflow management systems, with redesign requirements for these systems and with the question of what types of coordination mechanisms are generally relevant. These topics are crucial to analyse and explain the expectations and the behaviour of the stakeholders in the workflow management projects. Furthermore, it seemed to be sensible to relate the interpretation of our data to a theoretical framework which combines approaches such as social systems theory, actor network theory, the concept of structuration etc. (cf. 3.1). The application of these theories is the basis for a the interpretation of the empirical data and provides a basis for our understanding of the problems with the management of change, the modelling of work and the concepts of workflow systems. 3.1

THEORETICAL FRAME

The general background of the discussion in the literature on workflow system – as outlined above – can be related to more basic theories of sociology, psychology and epistemology which also influence CSCW research. The essential question is how social structures, such as coordinated work processes, can evolve. There is a dualism between the individual activities of knowledgeable human agents (subject) and the structure of an organization or society (object) (Giddens 1984; Engeström, 1999). The meaningful behaviour of individual human beings constitutes social systems, but only in relation to social systems can behaviour be meaningful. How can social structure (e.g. coordination) evolve under these con-


9

ditions of circular dependency? It evolves by repetitive activities which are grounded in time and space (Giddens, 1984) and are related to each other. Structure evolves as a web of interactions where the relationship between activities is contingent: how one person behaves is influenced but basically not determined by another one and vice versa (see Luhmann, 1995). Similarly, the repetitive interactions in the course of collaborative work processes can lead to a routine (in the sense of Giddens, 1984) and imply coordination mechanisms. Social structures do maintain their stability and identity by a continuous process of selfreferential renewing. Luhmann (1995) relates this process of permanent renewing to Maturana’s and Varela’s (1998) concept of autopoiesis (self-remaking) of living systems. The continuous renewing includes the possibility of alteration which can lead to results that can be considered as adaptation processes. In the course of autopoiesis, self-referential systems refer exclusively to rules which are a part of their own structure and a result of their own dynamic processes. It is a strength of the communication processes in social systems that they can recursively reflect the phenomena of self-reference. We assume that this kind of reflecting on selfreference facilitates the processes of change. Self-referential systems develop boundaries against their environment and they represent an identity as an unity by maintaining these borders. From this point of view, social systems (e.g. a workgroup) have a kind of autonomy which lead to difficulties if other systems in their environment (e.g. the management or a customer) attempt to control them. Workflow systems, explicit models of work processes (Dourish, 2001) as well as other kinds of mediating artefacts can serve as boundary objects (Star, 1989) which facilitate interaction. If the presentations of workflow models are flexible enough, they can be used to coordinate the collaboration between departments on the one hand and to serve as a means of self-reference for every department on the other hand. In a process of change and innovation, innovative structures are conveyed and translated from one area or system to another. The patterns of the innovation are inscribed into the structure of the system undergoing a change On the level of social interaction, this concept of translation and inscription as a model for innovation is an important part of Latour’s (1999) actor network theory. On the level of individuals and psychological systems, this concept can be compared with the concept of expansive cycles which is described as a part of activity theory (Engeström, 1999; Kuutti, 1992): phases of externalisation and internalisation are coupled and lead to irreversible results with increased knowledgeability of the actors. The pieces of a theoretical framework as described in this section did not help us to develop a scheme of categories to analyse our empirical data. It was only during the course of reviewing the empirical data that we became aware of the fact that the explanation of several phenomena can be grounded in the theories described above. The theories helped us to better understand the behaviour of the actors and roles involved in the projects. For example, managers seem to prefer


10

technical systems since they are not self-referential and can be controlled from outside – even if they include mechanisms of adaptivity, since these mechanisms are also programmable and therefore controllable from outside. In this sense, wms are a typical means of reducing contingency and increasing standardized behaviour, if they are integrated into work structures. However, the reduction of contingency is accompanied by reduced possibilities of improvisation and flexibility, since it weakens the strength of self-referential structures. 3.2

MANAGEMENT OF CHANGE

The companies involved in our study agreed that the introduction of a workflowsystem offers an opportunity and in many cases brings with it the necessity to introduce new ways of coordination. Furthermore, they were aware that the projects were going to induce organizational change which was going to be highly interwoven with the behaviour of the employees and to include cyclic and repetitive procedures. However, they did not realize how intensively the introduction projects themselves would be affected by the altering of procedures and goals during “run-time”. We have chosen the term “metamorphosis” for this phenomenon of alteration by referring to Orlikowski (1996). She uses this term to give a very elaborated description of organizational transformations which occur during the usage of groupware in a software company. She claims that certain approaches of explaining organizational transformations – such as planned change, technological imperative, punctuated equilibrium – are not sufficient to explain the dynamics of organizations in a world of continuously changing technological, political and economical conditions. Referring to Mintzberg (1985) Orlikowski differentiates between deliberate vs. emergent changes of organization and focuses on the improvisational character of organizational transformation which is “[…] grounded in the ongoing practices of organizational actors, and emerges out of their […] accommodations to and experiments with the everyday contingencies, breakdowns, exceptions, opportunities, and unintended consequences that they encounter. ” [65] Orlikowski’s notion of change as ongoing improvisation can be considered as situated change, a term which corresponds with Suchman’s (1987) “situated action”. Similarly, we found in the projects under investigation a highly context dependent and situated modification of goals, procedures and pursued solutions. Orlikowski identifies five types of metamorphoses which are relevant for our analysis even though our empirical findings cannot be directly matched with these types. However, the tendencies she found (see the list below) in explaining these metamorphoses also became apparent in our studies. In this context, Orlikowski as well as others (Blythin et al., 1997; Orlikowski & Hofman, 1997; Pipek & Wulf; 1999; Feijen, 1997) describe a number of aspects which have strongly influenced our analysis because they are difficult to anticipate and create effects which support emergent changes: Workarounds in difficult situations and bypassing technology.


11

New definitions of jobs., e.g. more relevance of documentation tasks. The emergence of new conventions, informal guidelines, rules etc. Problems with the amount of ongoing support and dedicated resources being necessary for implementing and managing organizational change, in particular on the lower levels of an organization. Incompatibility of strategies and goals as well as problems with implementing strategically formulated change policies in particular localities. Concurrent introduction of organizational, technological and cultural changes Problems with “[… ] the practical prioritisations and reconciliation of long term policy and short term contingencies” (Blythin et al. 1997, 45). The question as to whether and how to include the potential participants, the knowledge gap between them and the designers and the educational challenges being involved with participatory design. Underestimation of the time needed to go “online”. These aspects are a source for metamorphoses as we have observed them. We use Orlikowski’s term of metamorphosis to emphasize how deliberate and emergent change are entwined, if the activities of managers as well as practitioners contribute to this change and if unanticipated reactions or developments take place at the same time. However, there is a difference: Orlikowski’s metamorphoses are based on the continuous repetition of everyday task which leads to an accumulation of experience and makes opportunities for change obvious while our projects had to react on single events, problems or alterations of the conditions. We suggest that the term metamorphosis is metaphorically appropriate because our definition is that it indicates a smooth transition which is not understood immediately by the actors themselves and is not the outcome of a reflected plan or decision. 3.3

THE DEBATE ON WORKFLOW MANAGEMENT

The different approaches in explaining organizational change introduced in the last section only refer to the phenomenon of workflow systems in an indirect way. The objection to workflow management that can be derived from this body of literature is, that such a system is built upon an anticipation of what future work processes will look like, and this is difficult to predict as work processes are generally affected by an ongoing organizational change which cannot be anticipated. This problem is mirrored on two levels: On the first level it is generally questionable as to how far it is possible to formally describe work process and how these descriptions are related to reality. On the second level it is analysed in which shape or form the problems with formal representations of work processes do show up in reality and how the workflow technology can be improved to deal with these problems. The discussions on these two levels have a long tradition and so it was possible to summarize the most essential arguments about the problems of formalization, explicitness, anticipation some years ago, (e.g. see Ellis & Wainer, 1994, 73f). However, it seems worth adding another summarization, as we wish to discuss whether the arguments of the literature have the potential to


12

influence practical projects of workflow introduction and help to understand empirical findings.

3.3.1

Representation of work processes

It is widely acknowledged that successful cooperative task performing needs articulation work to support its coordination (Schmidt & Bannon, 1992) and that the application of groupware needs coordination mechanisms (Schmidt & Simone, 1996). However, there is always a tension between coordination mechanisms which can be formalized or at least be pre-specified and spontaneous and intuitive task handling. It is an open question as to whether models or categorizations can help to support these mechanisms. Workflow management projects imply the need for models of the work processes. There is a large body of literature which has sceptical views on the usage of modeling (Bannon, 1995; Bowers, 1992; Robinson & Bannon, 1991; Ehn & Sjøgren, 1991; Schmidt, 1999; Suchman, 1995). To systematize the discussion on the appropriateness of explicit representation of cooperative work, we (Herrmann et al. 2002) differentiate between three levels of modelling (see figure 2): A) Reflecting on structure (mental model), B) Articulation and negotiation (explicit models), C) Contributing to the development of structure (reified models)

Figure 2: Three Levels of Structure


13

Ad A): Human actors build theories about the systems (Argyris & Schön, 1996) which we call mental models of the system’s structure. However, also in the case of these mental models, Bannon’s (1995) question of “what can, in principle, be captured in any model of the work process” has to be applied. In the case of cooperative work it might be an appropriate assumption that the overall structure of the cooperation is not replicated in any of the individual participants’ mental models. This concern can be related to Suchman’s (1983, ref. in Schmidt 1999, p. 323) statement that the procedural structure of organizational activities is the product of the orderly work of the office rather than the reflection of some enduring structure found behind the work. According to this, the overall structure of a cooperative work process is only present in the work itself or - to put into other words - human action cannot be described by “plans” that are separated from the action itself (Suchman, 1987). Consequently, the issue of whether mental models can represent relatively permanent reflection of the structure of cooperative work is questionable. Ad B): Articulation work (in terms of Schmidt & Bannon; 1992) can be facilitated by making mental models of the structure of cooperation processes explicit. However, explicit models share certain critical characteristics. Usually, people do have problems when they are asked to categorize the different steps and resources of their work. Compared with the ephemeral mental models, explicit models are more permanent, standardized, and generalized. Thus, it might be the case that the concrete problems of the work are ignored in procedural expressions modelling its structure (Schmidt, 1999; Suchman & Wynn, 1984). It is argued that the greater the distance to the ongoing work, the more stereotyped are the models (Suchman, 1995). However, it can also be stated that the problems of stereotyping and idealizing disappear if the appropriate tacit background assumptions can be meshed with the models (Schmidt, 1999). Furthermore, explicit models are the result of a political process: certain kinds of selections or beliefs, which are pushed into the model can be guided by interests (Suchman, 1995). In the course of our projects, Schmidt’s (1999) comment that protocols and other formal contracts are characterized by inherent and necessary underspecification proved repeatedly relevant. Ad C): Explicit models are often used to anticipate how the modelled system or process can be improved and to model the improved constellation. With the model of the improved “to-be”-situation, managers and system designers try to shape and to change the structure of reality. The aim is to develop guidelines or technical systems which shape the way of collaborative task performance. However, Suchman (1987) states that explicit representations of work structures can only serve as plans and as an orientation for situated action, but cannot be used to prescribe the processes of cooperation. She suggests the metaphor of maps for this kind of resource. Although valuing the work of Suchman, Schmidt (1999) states that her investigations do not provide sufficient insight in how standard procedures defined as pre-defined stipulations are applied in routine daily work. He suggests that beside maps also scripts are necessary. Referring to a company


14

which has introduced the kanban principle, he introduces scripts as a kind of protocol which conveys a specific stipulation (in this example in the form of a production order) to instruct actors, under the condition of social accountability. Schmidt emphasizes that scripts can be modified but not switched off and the modification has the purpose of making a return to the rules possible – whether the script is followed or not is a discretional matter. Schmidt emphasizes that formal models would be of only marginal utility if they were not inscribed upon artefacts. Workflow engines are only one candidate – but a prominent one – in the wide scope of possibilities to help design this kind of artefacts. In many cases a wms is confronted with the problem as to whether it will be able to support the flexibility and opportunity for improvisation which comply with the function of scripts as described above. Taking these three levels into consideration, we found (see Herrmann et al. 2002) that the question of as to whether explicit representations of work processes are beneficial and to which extent they can be useful as maps and scripts differs with the specific constellations of every case. Whether representations of collaborative work processes are useful or problematic, mainly depends on the method used to develop them – the plausibility of this hypothesis is outlined in Herrmann et al. (2002). The decisive question is, whether the models are developed within the modelled system or whether they stem from outside (Suchman, 1995; (Bowers, et al.,1995; Grinter, 2000). The more the models are created or commented on and negotiated by those who carry out the represented work processes, the more these models can serve successfully as maps or scripts, since they are more understood and accepted by the employees. The success of or problems with explicit models depends obviously on the modelling method being used: mainly the type of notation (Goguen, 1993). Graphical notations are especially useful in supporting comprehensibility with clear visual representations of the work process. The structure of the notation method can be decisive – e.g. Gruhn (1998) has observed, that modelling with State Transition Diagram oriented methods tends to loose the process view of the problem. He concludes that it is above all important to find modelling languages which lead to an intuitive description. We propose modelling methods which allow the modeller to consciously leave parts of the modelled reality unconsidered and to make this decision transparent in the model itself. We call this kind of modelling method semi-structured (Herrmann & Loser, 1999). Semi-structured modelling meets Jørgensen’s (2001) requirement that the degree of simplicity of a representation method must be flexible. The relevance of such a method was confirmed in the workflow projects we have studied.

3.3.2

Problems with the concept of workflow management systems

As pointed out above, one problem with workflow systems is that they might not provide sufficient flexibility to revise the scripts being enacted with them. In


15

general we can differentiate between two positions in the literature. The first one we call traditional workflow approach – it suggests that modification of the underlying script is an exceptional phenomenon. On contrary, the second approach includes specification and adaptation of workflow by the users as a permanent possibility and is therefore referred to as the user-centered approach. The traditional workflow approach holds that workflow systems do have problems with exceptions but only with non-anticipatable exceptions. Several authors (Thoresen, 1997; Saastamoinen & White 1995) claim that nonanticipated events are not avoidable and they provide a list or systematisation of different types of exceptions. The traditional workflow approach accepts that there is no technical solution to handle those non-anticipated events automatically but it assumes that they only rarely occur. In our case studies, some of the practitioners tried to handle exceptions as something which could be identified in advance and therefore be included in the workflow procedures while others did not want to “get distracted” by potential exceptions and wanted to focus on the “good cases”. In general it was the traditional workflow approach which they had in mind when they were starting the workflow projects. We roughly differentiate between two general strategies which are orientated at the user-centred workflow approach: A) Semi-structured workflow approaches Nastansky & Hilpert (1995) made an early proposal for providing a five-step-continuum between highly and loosely specified processes including three types of semi-structured workflows. Semistructured workflows are based on an integration of procedural (structured aspects of the process) and non-procedural content (unchoreographed interactions; Abott & Sarin, 1994). More recently Bernstein [2000] proposed a continuum including four steps which also cover aspects of semi-structured workflows. A process support system should be able to interpret process models with these varying degrees of predetermined specification and support jumping about between these possibilities during runtime. Others, such as Dourish et al. [1996] have emphasized a constraint based approach which is focused on dependencies between tasks. This gives users a broader space of choice on how to proceed. The user is able to maintain the specification of constraints by himself and a ‘soft constraint enforcement’ [Jørgensen 2001] can support proactive users in partly controlling the workflow themselves, e.g. to avoid strict sequencing. Thus, users can start with nearly unstructured models and structure will only emerge during enactment when users as participants make decisions. Other approaches to achieve more flexibility take the traditional approach as a starting point but allow users to change the workflow “on the fly” (e.g. Ellis et al., 1995). Milano (Agostini & DeMichelis, 2000) facilitates exception handling by user-controlled jumps in simple Petri Net models. Milano’s integration of a conversation tool for articulation and negotiation support is typical for semi-structured workflows. B) On the other hand, compositional workflows (Swenson et al. 1994) pursue the concept that workflow processes are composed from pieces supplied by dif-


16

ferent users who might have different ideas about the processes. The main challenge of this approach is to support the users so that they can develop workflow models which can be enacted. Abott & Sarin (1994) propose that a library of available process definitions (including an inheritance hierarchy) should be available. Van der Aalst & Basten (2001) propose generic workflow models which support the construction of variations by specialization and generalization. Also Jørgensens [2001] concept aims on the possibility to flexibly combine reusable model fragments. We found that our practitioners did not prioritise the question of flexibility and permanent change, since they were mainly focused on the idea to describe a fixed state of organizational procedures to have a basis which can be conveyed to the workflow system. When they emphasized the importance of user-centred workflow management they meant that the user should be involved in the job of describing the processes before they are enacted by the system, but that the participation should not be continued afterwards.

3.3.3

The relevance of workflow models for social processes

While the traditional as well as user-centered approaches focus on the control of work processes, the relevance of workflow mechanisms for the social processes accompanying the control of work is increasingly recognized. Workflow includes a wide variety of aspects such as articulation support, access control (user’s assignment to tasks), communication support (Jørgensen, 2001). Van der Aalst & Berens (2001) refer to the importance of the requirement that the processes can be understood by the employees who should also have insight in to the whole case to which the activities belong which they carry out. Under this perspective of increased transparency by workflow, Dourish (2001) gives a very detailed analysis of workflow systems as an organizational accounting device. Workflow systems can be used to visualize work, make it accountable and observable to certain roles – e.g. contractors – rather than manage it. They provide a structure within which an activity can be made plausible. With this conceptualisation of workflow systems, the role of scripts (see 3.3.1) as a social phenomenon achieves broader recognition. Schmidt & Simone (1996) present a detailed, systematic derivation of characteristics of coordination mechanisms. They develop the general requirements for coordination mechanisms and their supporting artefacts and these requirements can also be applied to workflow systems if they are required to cover the different social aspects of coordination. Schmidt & Simone state – for example – that these artefacts have to make the coordinative protocol objective and permanent and have to represent the state of the execution of the protocol and also that changes to the protocol by one actor have to be transparent to the other actors. We found that this broader view on workflow system as a multi-faceted coordination mechanism which covers aspects such as accountability, division of work, management of change etc. has a much broader relevance than the question


17

of adaptability and flexibility. Many of our partners, for instance, prioritised process reliability and accountability issues higher than the need for adaptation. In the case of company A guaranteeing asymmetric distribution of access rights on data for maximum price-reductions and the establishment of three different stages for process escalation were rated more important than adaptability. The adaptability strategy that would have provided additional escalation strategies and more flexible access on data was rejected. In exceptional cases where apparently external agents need to know about potential reduction rates, this information was planed to be passed on the basis of individual decisions by phone or through e-mail. Likewise, it was accepted if not desired that alternative escalation strategies can employ other coordination mechanisms than the workflow system. For four companies in our set comprehensible and rich visualizations of workflow processes were a key requirement for the selection of technology. All of these companies preferred graphical against tabular displays. Only one company chose technology that did not provide a kind of graphical display.

4

Problems with the initial plans and goals

We describe the metamorphoses of the workflow projects by explicating how the initial goals and intended project procedures were altered due to problems that became apparent in the course of the projects. We focus on those aspects which were recognized as “typical” by most of the members of the companies when the problems were discussed at the overall project meetings. 4.1

INITIAL GOALS OF THE COMPANIES

In most of the companies we worked with, the initial decision had been made to improve the most important business processes by selecting and buying a standard workflow management system. This decision includes the implicit assumption that the developers of the selected software have a sufficiently complete model (see 3.3.1) which covers all the aspects of the company’s business processes which are worth supporting. The management planned to prioritise those business processes where a large load of daily cases and repetitive tasks had to be worked on and where a clear effect of improvement could be quickly and evidently achieved – in terms of work stress, time needed per case or the quality of the results. In respect of the average completion-time, for instance, management assumed that the business processes were interspersed with idle phases which could be gradually eliminated and that the employees did not want or did not know how to achieve an acceleration. To support this continuous improvement, it was planned to use a monitoring component (in the case of company A) to regularly gain data of how the business processes were conducted, so that a basis was available which could reveal weak points and possibilities for change. The argument for the need of such a monitor-


18

ing component was, that work procedures and coordination mechanisms are mainly a matter of unconsciousness routine and that the employees do not have a model of their work which allows them to reflect on their practice and to make proposals for improvement. Most of the workflow projects were oriented towards the traditional workflow approach and the idea of providing scripts for activities which can be successfully enacted with a workflow engine (see 3.3.2). It was also supposed that the new workflow software could easily be made compatible with the existing software components which support the operational every day tasks. The practitioners as well as the researchers had not taken into consideration the fact that the old paradigms of non-workflow task processing were inscribed in the existing technology and caused serious problems with compatibility. The introduction of workflow management systems was in many companies not an isolated activity but part of a broader strategy covering various fields of the enterprise and its IT infrastructure. It was assumed that this strategy would be sustained during the period of the workflow project and that the employees would understand it as well as the implied priorities (for a contrast see Blythin et al. 1997, 3.2). 4.2

THE IDEAL PROJECT PROCEDURE

With respect to project-management, the basic concept was to implement projects of technological and organizational change which are well structured and are based on a sequence of stages which can be completed step by step without the necessity of loops which lead to a revision of preceding results. Thus the management was interested in a lasting organizational change which could be carefully planned and be deliberately controlled. The role of improvisation was hardly taken into account. A strict waterfall model was strived for, e.g. first modelling, then improving the model and afterwards a complete implementation or the model with a workflow system. The idea that users could detect and describe workflows by themselves and transfer them onto the machine was irrelevant from the management point of view. The concept of providing semi-structured workflows which provide flexibility was considered as an interesting approach which might possibly have relevance in exceptional cases. However, it was supposed that concepts of flexibility support do not have to be taken into consideration from the beginning and that it will become evident in time as to if such approaches are relevant. All in all there was only little awareness of the possibilities of emergent changes (in terms of Orlikowski, 1996) and for the factors which cause them. Correspondingly, it was expected that the relevant aspects and factors could be easily recognized and that the data needed for the project could be collected without sophisticated methods. For example, it had been considered as an easy task to identify a business process which is suitable as a successful starting point for the project since its efficiency can obviously be increased. Furthermore it had been expected that the relevant people could easily be identified and brought


19

together to contribute to the business process modelling and improvement. The management knew that some people might have difficulties in making their view on their work processes explicit but this was considered as a problem of unwillingness or a lack of cognitive abilities. According to another basic but simple belief, it is clearly and easily evident how a business process can be improved after it has been made explicit by a model. At the beginning of the projects we had no clue as to what kind of context information beside the business process models would be necessary to solve problems such as those involved in the improvement of the business process, in the selection of the appropriate workflow management software or in the configuration of this software. Against better theoretical knowledge there has been a kind of practical enforcement in our projects to neglect the theoretical insight that the models are inherently incomplete (cp. Schmidt, 1999, 3.3.1). These expectations of simplicity were also related to the situation after the introduction of the software: the users should be able to continue the usage of screens and functionality they were used to and the effort needed to make them familiar with the specialties of workflows should be negligible. The characteristics of the management’s model of change were that a continuous improvement should take place. However, it was left to the researchers to reflect on such a model and the management was not interested in making its model explicit and in discussing the implications, for example of the necessity of repeating certain stages of the project. While the researchers were convinced that the need for frequent alterations of the configuration of the wms was the decisive reason for choosing this technology, the management’s main concern was that the system would finally run in its first release and that this milestone would be the decisive basis for judging its success. One strategic assumption was that the experience which had been made with one business process could be easily transferred to other business processes so that more and more business processes could be supported by the workflow management system. This implied using a model of the company’s reality which is characterized by a certain homogeneity of the business processes so that the procedures and experience of the workflow project could easily be translated from one area to another. 4.3

PROBLEMS

The initial goals and plans for the running of the workflow project have been confronted with a number of problems which lead to the metamorphoses described in the following chapters.

4.3.1

Selection problems

One problem we ran into in most of the projects that reached this stage at all was to select a business area or process to start with. It turned out that it is difficult to select an appropriate field where the initial introduction of workflow manage-


20

ment would be sensible. Three companies (A, B and C) in which we were involved as researchers and consultants did not continue with the business process which was selected at first but chose a completely different field for the workflow application. The reasons were that It is not always clear what a business process is (where it starts, where it ends and what is part of it or not). There are a lot of criteria which have to be taken into account in judging the appropriateness of a business process for the application of a wms (degree of labor division, frequency of repetition, similarity but also independency between the instances of the business process, possibility for software-based support, potentials for improvement and need for alternations in the future). For example, in one company the process which was selected at first proved to be too simple so that it was not advisable to exchange the existing software solution with a more workflow oriented system. In another case the initially selected processes included work activities where different collections of business items were handled and coordinated. Handling relations among and collections of business cases, however, was beyond the functionality of workflow systems available on the market at this time. Unanticipated problems became obvious . Furthermore it was unexpectedly difficult to decide which kind of data should be collected, which data sources should be used and what kind of methods for data gathering were appropriate. The main problems for the data gathering teams were that: It was not sufficient to focus on data which describes only the business process but also to take information into account as to how they could be improved, e.g. to overcome insufficient availability of information. This led to the problem that there was a large variety of potential aspects for improvement but it was hardly foreseeable which of them were relevant. Conducting in-depth interviews and observations so as to gather ethnographic data would have been an optimal means of identifying needs for improvement. However, the time required to gather and analyse all the data which might be potentially relevant would obviously exceed the available resources. In one case (C), the management was worried about the possibility that the employees could manipulate the data gathering so as to avoid the disclosure of negative aspects of their work practice. The management itself was interested in not revealing certain facts about their business procedures, e.g. (case A) the regulations of how the extend of possible sales discounts is determined. It was nearly impossible to organize meetings and procedures where everyone who could contribute relevant experience could have been included without disturbing the ongoing business. Based on these reasons it is not only from an analytical but also from a practical point of view obvious that models of improved business processes have to be built on a necessarily incomplete data basis. It is more realistic to consider the


21

work groups as a kind of system where it is a matter of principle that they cannot display all the data describing their behaviour since the interactions in the course of data gathering are limited. This viewpoint corresponds with the perspective of recognizing workgroups as self-referential systems (cf. 3.1) which create and follow their own rules that cannot be understood from outside in the same way as the systems interprets them.

4.3.2

Unexpected organizational effort

Workflow management applications connect multiple organizational units or departments working together on the basis of specific types of work cases and processes. This strength proved to be a disadvantage for the design of an appropriate project organization where stakeholders from different departments had to be included. The need to integrate different opinions and viewpoints slowed down the whole process as well as the problems with finding time slots when the members of the project committees were available. In larger companies (A and F) with more branches it was assumed that all the branches run the selected business process in the same way and that it would be possible to transfer the solution to all once it had been found. Therefore, it was not considered necessary to integrate members from all branches into the project. This presumptions, however, proved to be wrong, since the different branches had established different and partially incompatible work practices and coordination mechanisms even though they had the same tasks. Furthermore, the extent of necessary training and effort needed to convince people was higher than expected: The basic idea of workflow and business process improvement was not self-evident to the employees and had to be intensively promoted; It became obvious that mediators were needed for the participative process if the researches weren’t going to play this role. In one case (C) we were able to clearly observe that users of the workflow system need a considerable period of time to get used to the new technology, manuals and a support team’s assistance were frequently asked for, the attempt to accelerate the adoption of the new technology by using online-help was also unsuccessful. In certain companies it was necessary to insert a piloting period when the system was started so the old and the new system were used as a tandem. This period caused severe unforeseen problems, especially with the acceptance of the wms. Partially due to the fact that the workload was doubled as the data had to be maintained on both systems. Having experienced technical problems it was also considered to be too risky to immediately switch from one system to the other. At this point of the project, where the pilot stage was started, the introduction of wms was considered to be an “opened heart surgery”.


4.3.3

22

Technical problems and Integration problems

Technical problems could be observed on different levels: The basic structure of workflow solutions did not always fit. In case B (transportation business) it became evident that different but similar instances of the same business process are merged together for certain tasks and split off for others, and that this merging and splitting can be repeated. From the perspective of conventional workflow modelling an incoming load of piece goods was to be considered as one business case. This conception, however, lead to problems when the load was dispatched on different outgoing cars. Alternative solutions lead to inefficient solutions. Handling collection of business cases was not compatible with the basic assumptions of workflow modelling incorporated in the available software. The build-time components of the workflow systems did not sufficiently support the deriving of the technical workflow model from the organizational business process model. It was not evident how the model of the improved business process would lead to a properly programmed wms. Thus the programming was time-consuming and the question was raised at how the integrity between both models could be guaranteed. One of the most challenging problems was the integration of the new wms with the company’s legacy systems which run the operational applications (Deiters et al., 1998). To establish interfaces between the workflow-system and legacy applications was much more difficult than expected. Technical reality and the organizational concepts of improved coordination were interfering and compromises had to be made. However, it was difficult to take these problems into account in the early stages of planning the project. In the case of a very large company (F), severe performance problems occurred after the system was introduced. Although the process of selecting an appropriate wms was conducted very carefully it was not possible to completely check whether the system would sufficiently comply with the requirements of performance, scalability and robustness.

4.3.4

Know how problems

In the course of the project, serious know how problems – of the practitioners as well as the scientists – became obvious which point at a lack of methods which are necessary to organize the introduction of workflow. Generally, the establishment of such methods is usually neglected while the maturity of the technology is brought forward. One example was the lack of guidance for the improvement of the business processes on the basis of diagrammed representations. Furthermore, there was no method of deriving the technical workflow model from a rough business process model which focuses on the improvement measures. A third example was that one company (A) which had planned to introduce a monitoring component did not know what kind of features such a component should have as


23

they did not know which data might be necessary to support the continuous improvement.

4.3.5

Conclusion

The problems described above lead to serious delays in the projects’ progress and made it clear that it was not as easy to achieve a quick improvement of bps as it had been originally purposed. In two companies (A and C) the strategic priorities in the area of information and communication technology changed before the projects had even delivered a success or return of investment. The alteration of the strategy also influenced the metamorphoses.

5 5.1

Metamorphoses of the project procedure PROJECT ORGANIZATION – NON-ANTICIPATABLE FLOW OF WORKFLOW PROJECTS

Although it was repeatedly announced that the progress of the project, its time schedule and the structure of the project groups have to be a matter of deliberate planning, a lot of decisions where made spontaneously and emerged from opportunities. Such decisions are always situated in the ongoing changes of the market conditions, the companies’ strategies and of the availability of resources as well as into other processes of reorganization, which accompanied the workflow projects. A typical example was the question of who will have or will be allowed to participate in the project. At the beginning of the project the researchers developed a detailed plan of how participation should be organized – who should take part in which jobs, what should be the rights and duties of the participants, and which kind of documents should be produced at which stages of the project (cf. Walter & Herrmann, 1998). Later on it became obvious that it was not possible to follow such a plan and that the decision of who will participate was more a question of availability and willingness of the potential participants, there interest in workflow management, and their knowledge of the business process. Consequently, an ad-hoc involvement of people who where knowledgeable about relevant questions casually took place. At the beginning of one project (A), the involvement of the work council was a matter of serious negotiation. After a while, this aspect was neglected. One reason being this that the whole project was too complex and too much knowledge was necessary for an outsider to influence it. Such difficulties are not known from workflow projects exclusively. However, since workflow systems have to be integrated with existing system and are meant to foster organizational improvement at the same time, they imply a very high complexity that is very likely to lead to the problems described above. Thus the first metamorphosis on the level of the project organization was a transformation from deliberately planning and execution of project stages to improvisa-


24

tional, opportunity-oriented decisions in a more experimental manner. While the data gathering could be conducted quite systematically and took a deliberately selected set of employees into account, the business process modelling and in particular the development of the ‘to-be’-concepts was characterized by a more experimental practice. The reason for this transformation can be seen in the complexity and the lack of knowledge and methodological guidance as outlined above (4.3.4) Due to the trial and error procedures of the experimental stage, the plan of strictly sequencing the phases of the project was interrupted by loops since certain activities had to be repeated: In three cases (A, B and C) the selection of the business process for the workflow piloting was revised after the first data gathering. Thus the data gathering had to be repeated. The revision of the selection was only partially caused by a rational reasoning being based on a catalogue of well reflected criteria (Goesman et al. 1998). By contrast it was also influenced by political reasons and by the question whether a department would be willing to support the mental change towards business process orientation or not. In several cases the selection of the wms proved to be inappropriate and had to be repeated or even led to a collapse of the whole project (in one case). Other companies changed their goals and the character of their projects during the course of the selection process and the character of their projects and became more oriented towards other solutions such as content management (G) or enterprise resource planning systems (E). Thus the experience made during system selection was a decisive impulse which led to a phase of experimentation. The sequence “specification of the improved business process and then programming” – which was implemented into the project management by an academic point of view – could not be maintained. The determination of the business processes had to be revised in the light of the characteristics and limits of the wms being selected, in compliance with comments on the prototypes and due to the problems with the legacy systems. Prototyping (cp. Floyd 1984) had an important role in the projects and neglecting it led to serious problems. In one case (B) deficits of the new system were detected too late (e.g. with the performance of the search mechanisms). The plan in another case (A) was that a wms was selected and was used to program the whole business process. In a preceding stage a prototype should be developed with the same system. This prototype should only enact a part of the business process and should neglect details such as the handling of known exceptions. Afterwards the prototype should be completed to support the enactment of the whole business process. The reality was that the prototype was thrown away after it had served as a demonstrator which had inspired the participants to make their comments. The reason being that the selection process of the wms had to be revised or – from another point of view – the first selection had to be completed very quickly so as to be able to develop a prototype which could influence the


25

early phases of the requirement refinement. At the end of the project, the “throw away prototype” was not considered as a mishap but as a reasonable methodological procedure. Besides this example there are multiple other possible reasons for ‘throw away prototypes’ – in case C), for instance, the wms-software which was used for prototyping was no longer available on the market after the prototyping stage had been completed. The first metamorphosis that lead from deliberate planning to improvisational experimentation was followed by a second one which could be referred to as “from experimental to focused progress”. After the final decision for a certain kind of system had been made and the ‘to-be’-business process-model had been fixed, a very concentrated process of programming and technical work started. During this stage, a number of aspects which had had certain importance before, were ignored and several goals of the project were no longer pursued. The second metamorphosis did not erase the influence of the first completely. Improvisation and opportunity oriented decision continued, as there were still enough problems to be solved which were mainly caused by a lack of resources. However, the project work focused more on the aim of technical realizations. Indicators for this transformation are the neglecting of the monitoring component, the implementation of feedback mechanisms for the users, the focus on user problems or wishes for adaptability, and the neglecting of measures which could facilitate the process of continuous improvement. Actually, during the implementation period all the ideas of continuous adaptation and flexible improvement were lost. The main goal was to be able to present an up and running workflow application. A further switch to experimentation and improvisation only started when the practical usage of the wms began and the users had to be supported to manage the handling of the system. 5.2

THE RELEVANCE OF FLEXIBILITY AND EXCEPTION HANDLING

The decision to start a workflow project was in most cases motivated by the prospect of a standardized and more efficient execution of the central business processes. When the projects were planned it was accepted that flexibility, handling of exceptions and continuous improvement were the main challenges which had to be dealt with. It was a central argument that a wms would make it easier to alter business process execution. However, when the complexity and the lack of methodological guidance had become apparent, the requirements for exception handling and flexibility were lost. One company (F) recommended focusing strictly on the “good processes” since taking into account all assumed exceptional conditions which might happen would make the process model so complex that the possibilities for improving the business process would not be detectable. The provisional “solution” was to postpone the question of how to deal with unanticipated exceptions until they occurred (with the hope that they would never occur). In this situation it was a kind of a methodological compromise between researchers and practitioners to prepare a checklist of how exceptional cases


26

could be systematized and easily recognized (cf. Herrmann & Just-Hahn, 1998; cp. also Kammer et al., 2000). However, this checklist was never systematically applied. Yet, some exceptional constellations became apparent which had to be dealt with such as the replacement of an insurance contractor (B), unexpected requirements of customers in the case of damages caused by transportation (B), or additional need for agreement which had to be organized by e-mail (A). Regarding flexibility and exception handling, our analysis reveals two contradictory metamorphoses: 1. From low to higher acceptance of the relevance of flexibility: The initial interest in workflow management was driven by the prospect of standardized and therefore highly efficient execution of business processes. During the planning stages of the project, the practitioners were more and more convinced by the researchers that flexibility, continuous adaptation and freedom of decision for the employees were decisive factors for success. 2. From high to lower awareness of the importance of flexibility: When the complexity and the lack of methodological guidance (cf. 4.3.4) became apparent in the course of the project, the concepts of supporting flexibility were lost out of focus. This re-orientation was not a matter of deliberate reflection or discussion but just an effect of time pressure and lack of resources.

6 6.1

Metamorphosis of the planned solutions PROCESS EXPLICATION AND IMPROVEMENT MORE VALUABLE THAN WORKFLOW AUTOMATION

It was of benefit for all the projects – no matter whether a wms was introduced or not – that the business processes were made explicit and could be analysed. One of the central metamorphoses that we can find when analysing our cases is that the analysis and improvement of the business processes became at least as important as the introduction of wms. The process of discovering unexpected benefits from process representation lead to a metamorphosis of the perspective on representation work in general. It became a main goal to make the business processes comprehensible and to alter them according to the possibilities of improvement. At the beginning only regarded as a tool for developing the workflow engine it became more and more obvious that representation was a multi-purpose means of facilitating discussions of organizational issues, training and guiding work practices. We entitle this metamorphoses of the role of representations: “representations of work processes – from a means to an end”. The strongest empirical evidence for this metamorphosis in most of our cases was the observation that the decision to alter the business processes was also brought to reality if the workflow automation was not introduced or replaced by another type of software. The decisive factor of success was that the result of the improvement – and the goals behind it – were made visible to the employees so that they became convinced


27

during the course of the workflow project that it was worthwhile to adapt their work practice to these newly organized processes. This observation corresponds with the importance of the social function of explicitly represented business processes (cf. 3.3.3) such as accountability (cp. Dourish, 2001). The decisive means to promote this metamorphosis is the combination of data gathering and workshops. They play an important role since they have to take into account all the aspects which are relevant for the social function of process description and for the improvement of the business processes, too. This includes finding information about the employees’ wishes and ideas, such as how they see their own roles or where they see room for improvement of their situation (Hoffmann et al. 1998). The analysis of the data and the representation of its results has to take into account that the employees should get appropriate feedback which includes transparency of the goals of the data gathering and the project of business process improvement. We realized that feedback workshops are relevant so as to initiate a mental change and to generate a positive attitude towards process-orientated thinking. These workshops contributed to the effect that the stakeholders of the workflow project had developed the impression that the proper understanding of the business processes as well as the potentials for their improvement and the commitment to bring them to reality might be the main outcome of the wms-project. Although workshops are time consuming they were only one factor amongst others which caused delays. One of the success factors of the workshops was the selection of appropriate methods of how the business processes and the accompanying data were presented. A variety of methods are possible such as text based description, rich pictures (Moody, 1996), storyboards (Harada, 1996], models being represented with formal (e.g. Scheer, 1992) or semi-structured diagrams (Herrmann & Loser, 1999). The representations should be represented in a way that makes them understandable on different levels of expertise so that they can function as boundary objects (cf. 3.1) between the different departments or hierarchical positions. 6.2

CHANGING THE PRIORITIES WITH REGARD TO WORKFLOW AUTOMATION

Beside the turn in the valuation of process explication we became also aware of another metamorphosis concerning the importance of certain aspects of the technical solutions which were planned. This metamorphosis is characterized by what became less important during the project and what became more important – in contrast to the initial plans.

6.2.1

What became less important

When we conducted the interviews of our final evaluation, the enforcement of a standardized sequence of how certain tasks have to be carried out was no longer considered as to be a central benefit. Similarly, the idea of the wms helping to


28

allocate the appropriate task to the appropriate person and that this allocation could be flexibly customized also lost relevance: while it was frequently mentioned by the management (A and C) at the beginning of the projects, it was neglected at the end. We believe that the reduced relevance of wms-based work allocation can be related to the fact that in our cases the allocation of tasks mostly takes place through the organizational context of the companies. Furthermore, the plan to integrate a monitoring component into the wms to store and evaluate the data of completed cases as a basis for detection of potentials of improvement was skipped. The reasons were to avoid conflicts with the works council (A), the prospect of negative impact on the motivation of the personnel (B) and – mainly – the lack of methods to determine what data is needed and how it could systematically be used to generate proposals for improvement.

6.2.2

What became more important

More important than the automatic sequencing and work allocation became the transparency of the status of cases being processed. This data was only relevant during the runtime of a case – and not for an ex-post evaluation. It should help to comprehend the status of the completion of a case and who is currently working on it – e.g. if a customer is asking for a report on the progress of the case. Another benefit more recognized than the automatic processing of cases was the enforced introduction of a homogenous structure and handling of data. The wms projects urged the companies to develop structures for documents and forms which were standardized for the whole company. These structures avoided transfers of data from one medium to another or from one operational software to another. Double entering of data was reduced. However, all types of groupware which offer a shared workspace contribute to this benefit. Furthermore, this effect of the integration of data does especially depend on groupware but can be achieved for all types of software – such as ERP – which rely on a companywide data model. Subsequently, the data integration led to the emergence of company-wide information bases – the search for data was accelerated and the number of situations where the work was delayed because of a lack of data were reduced. All in all, the impact was an additional saving of time, since the activities for data entering or maintaining the information bases were reduced.

6.2.3

Getting away from traditional workflow concepts

It is obvious that if factors such as transparency and data integration are considered as more relevant than workflow automation, the traditional workflow concepts loose their status as being the exclusive solution. In such a situation more technological options have to be considered. In our studies we could observe that the plans for introducing wms lost their attractiveness during the projects, when it became clear that the beneficial effects of the projects were not originally related


29

to the specific features of wms. Consequently, a variety of solutions were gradually considered as serious alternatives beside wms: Groupware: In one company (B) a Lotus Notes™ based groupware solution for truckage companies was introduced instead of a typical workflow solution. One problem was that the available wms were not compatible with the typical software solution for truckage companies. This was no longer a problem after it became apparent that the sequence of task processing was not as important as the universal availability of the relevant data and documents. Furthermore, a unified data structure was pursued by the kind of technology which was introduced. Similarly, Prinz & Kolvenbach (1996) found that shared workspaces were preferred to electronic circulation folders which enforce sequences. e-mail support: In another case (A) it was realized that wms was not the appropriate means for certain user groups, such as managers. Therefore, the workflow was partially continued outside of the wms by using e-mail. The fact, that such a decision became possible reveals the willingness of the company to abandon the goal of a unified workflow solution. Enterprise Resource Planning - ERP: In two cases (C and E), SAP™ was introduced since company-wide data integration had been gradually acknowledged as a strategic aim which promises more benefits. Lightweight workflow (Agostini & Michelis, 2000) being integrated into the existing solutions: SAP™ solutions offer the possibility to integrate the definition of workflows. Thus, the idea of workflow support did not loose its relevance but was sub-ordinated under another type of software. The same phenomenon can be realized with Lotus Notes™. The remaining process support can be considered as lightweight workflow, since the length of the workflow chains is usually reduced to a selected context where a sequence of task processing is indispensable. Content management: Another company (D) which had planned to combine document management with workflow management had realized that it would be sufficient for their strategic goals to stay on the level of content management solutions. It can be considered as the overall metamorphosis on the technical level that the companies started with the aim of introducing wms and ended up choosing other types of technology which support data integration and are compatible with the methods of business process re-organization. These other types of technology which were eventually introduced often deviate so much from the original plans that it is no longer appropriate to speak of a s solution. Altogether we entitle these metamorphosis of the priorities with regard to workflow automation “from ambiguous theoretical workflow concepts to integrated and practice oriented solutions”.


7

30

Conclusion: The workflow paradox

In the course of this paper we have introduced the setting of our empirical analysis on industrial workflow projects, our research questions, and our methodological approach. We discussed the relevance of our research with regard to theoretical perspectives that have been influencing the debate on workflow technology in CSCW. On the basis of these considerations we described the plans we initially met in our settings - in particular the goals of the projects and the planned project procedures - and we identified four types of problems that were encountered in the projects, namely selection problems, unexpected organizational efforts, technical integration problems and know-how problems. These difficulties lead to some developments in the projects that were described as metamorphoses of Workflow-Projects (cf. Figure 3). Metamorphosis of the project procedure 1 From deliberate planning to improvisational, opportunity-oriented decisions 2 From experimental to focused progress (Regarding flexibility and exception handling:)

3 From lower to higher acceptance of the relevance of flexibility

Metamorphosis of the planned solution 5 From ambiguous theoretical workflow concepts to integrated and practice oriented solutions (Regarding the role of representations of work:)

6 From considerring representations as a means to coonsidering them as an end

4 From high to lower awareness of the importance of flexibility

Figure 3: Metamorphoses of Workflow-Projects

Many troubles that interfered with the plans of our research project’s affiliate companies can be observed in other contexts, too. Since the relevance of traditional workflow management systems and automatic execution of large process chains does gradually decrease in the context of industrial practice, the concepts for flexible workflow technology will only play a minor role in the concert of possible alternatives. This practical tendency has to be seen in contrast to the importance and sustaining influence of the workflow discussion for CSCW research where increased understanding of dualisms such as maps and scripts, flexibility and standardization as well as planned and situated actions has made a tremendous contribution to a better understanding of cooperative work processes. Due to it’s strong connection to organizational redesign workflow still seems an ideal candidate to investigate the dual relationship between organizational changes and technical developments within organizations. The concluding question could be whether the outcome of the metamorphoses could be recommended as a goal which should be pursued right from the beginning instead of running through all these learning processes. We have to give a negative answer due to a phenomenon which we call the workflow paradox: you have to start with a workflow project to come to the conclusion that other


31

solutions than workflow management systems are more appropriate. The reason for this paradox being the attractiveness of the technically enforced and standardized execution of improved business processes. Although the managers involved in our projects knew that mental change, organizational development as well as training and participation of the employees are decisive factors, they did not want to rely only on them. The prospect that new organizational measures can be brought to reality by restrictive technical means seems to be more promising or is at least needed in many cases to legitimate the start of a project which deals with business process improvement. We also got the impression that the employees willingness to invest time in the reflection of the modelled business processes would increase if they knew that these processes would possibly be automatically enacted with the help of a technical system like wms. Practitioners and managers can hardly be guided by referring to results documented in scientific literature or empirical results which they themselves have not experienced. Therefore, it is sensible to start with a workflow project even though the introduction of a wms will only take place in some cases, for instance if legal conditions require strictly standardized process executions or if the project is pushed forward very rigorously so that there is not enough time to run through the learning processes of the observed metamorphoses. We suggest that these metamorphoses decisively contribute to the efficiency of the organization and to job satisfaction. It is sensible to start with a workflow project and to implement the possibility of processes of learning and re-orientation which are supported by the following approaches: Flexible self-description Business process-models can be seen as a form of self-description of an organization. This type of descriptions is an essential element of social systems which according to Luhmann (1995, p. 9) need a means to refer to their own rules, conventions or repetitive structures of interaction to maintain their characteristic of being “self-referential”, as described above (cf. 3.1). The reflection of this self-reference can improve the capabilities of an organization and the integration of technical and organizational structures. Both aspects have to be covered by the methods of description or modelling which support this reflection. They have to be formal enough to be exchanged between different stakeholders and related to technical aspects (Agostini & Michelis, 2000). On the other hand, they should be informal enough to cover the different viewpoints of various employees who should be supported in choosing between varying degrees of completeness and vagueness of descriptions, since the possibilities for explicitness vary between different roles or persons. Special modelling methods are needed which meet these requirements (e.g. SeeMe; Herrmann & Loser, 1999). The models of business processes should serve as boundary objects (Star, 1989; cf. 3.1) and support the referring to and access to persons, resources and activities that live outside the domain of a particular workflow.


32

Integration of process improvement and knowledge management It is reasonable to employ information technology to support the documentation of business process models. Therefore, knowledge management systems could be used to document and distribute business process models and to collect feedback and proposals for the modification of business processes. “Prototypes” for re-organized processes could be announced with such a system and the processes of negotiating them could be supported. The idea of integrating workflow management systems with knowledge management and organizational memory systems has early roots (e.g. Abbott & Sarin 1994, cf. 3.3.2, b) and has been formulated more explicitly from different viewpoints (e.g. Wargitsch, 1998, Herrmann, 2000). Knowledge management systems can strengthen the benefits which have been the outcome of the workflow projects such as more transparency of the processes or the introduction of an integrated, company wide information basis. Knowledge management systems can help to integrate business process models as well as the data and documents which are needed to execute the tasks that are part of the processes (Hoffmann et al. 2002). Focusing on lightweight workflows Although the management might be focused on complete workflow automation, the systems engineers should not be decided at the beginning but during the course of a workflow project as to whether a complete workflow system is introduced, or whether workflow components can be integrated into existing software, or whether a new application software should be installed which includes the possibility of workflow components. To be able to react so flexibly respects the tendency that workflow components are increasingly integrated into knowledge management systems, web-services, ERP or groupware applications. These components would only be used to automatically execute those segments of the work processes where a pre-specified sequencing might be sensible. In most cases the provider the possibility to work around pre-specified sequences if exceptional cases occur.

Based on the evaluation of workflow-projects at eight industrial sites we came to concrete recommendations for the introduction of workflow technology. During the course of the projects the metamorphoses in the companies’ strategies and perspectives were not always easy to observe. Even to us, some developments became visible only after the project and the public funding had ended. Specifics and peculiarities at the different sites were multiplied by the amazing capabilities of organizations or the organization’s stakeholders to change their opinions on desirable outcomes of technology-driven projects without neglecting previous positions, to sustain contradictory opinions, or simply to “separate theory from practise” as one of our partners put it. However, the six metamorphoses (cf. figure 3.) were present in all the projects. Traces and effects of them can be found in the projects’ documentations, the resulting technologies and organizational


33

configurations, the minutes of the nine workshops with practitioners, and in the recommendations published by the project’s participants. We found much evidence for the superiority of self-made experience over expert advise in our case studies. Although our partners did not always become aware that their difficulties resembled established scientific knowledge, at least the “theoretical opinions” about the role of representations or about the flexibility of workflow technology more and more converged with the researcher’s point of view. Starting a workflow project was in some respects more convincing than expert advise. Thus our formulation of the workflow paradox can be read as an acknowledgement of the limitations of scientific consultation, too. It also points at the necessity to relate to management rhetoric to a certain extent. More importantly, however, we want to emphasize that organizations being self-referential systems heavily rely on external as well as mental representation of their configuration and integrity. Flexible means for representing technical and organizational structures can therefore play an important role in reconciling different viewpoints and in innovating the organization with or without the introduction of technology.

Acknowledgements We are grateful to all the members of the companies in the MOVE Project for their dedicated support of our research. Furthermore, special thanks are due to Volker Wulf, and Will van der Aalst for their valuable comments on an earlier version of this document. We are also grateful to Paul Dourish for his comments on our perspective on structuring as outlined in this paper. Funding of this research has been provided by the Federal German Ministry for Education and Science (BMBF+T: 01 HB 9606/1).

References 1. Abbott, K. R., Sarin, S. K. (1994): Experiences with Workflow Managament: Issues for the Next Generation. In: Furuta, R., Neuwirth, Chr. (eds.): Proc. of CSCW ´94. New York: ACM Press, pp. 113-120. 2. Agostini, A.; Michelis, G. de (2000) : A light workflow management system using simple process models. In: Jcscw,9 ,335-363. 3. Argyris, C.; Schön, D. A. (1996): Organizational Learning II. Theory, Method and Practice. New York et al.: Addison Wesley. 4. Bannon, L.. (1995): The Politics of Design: Representing Work. In: Communications of the ACM, Vol. 38, No. 9. pp. 66-68. 5. Bernstein A. (2000): How can cooperative work tools support dynamic group processes? Bridging the specificity frontier. In: Proc. Of CSCW2000. New York: ACM, pp 279-288.


34

6. Blythin, S.; Hughes, J.; Kristoffersen, S.; Rodden, T. Rouncefield, M. (1997): Recognizing success and failure: Evaluating groupware in a commercial context. In: Proc. of Group97, New York: ACM, pp. 39-46. 7. Bowers, J. (1992): The politics of formalism. In: Lea, M. (1992): Contexts of ComputerMediated Communication. New York. pp. 232-261. 8. Bowers, J., G. Button and W. Sharrock (1995): Workflow from Within and Without: Technology and Cooperative Work on the Print Industry Shopfloor. In: Proc. of ECSCW95. Dodrecht et al.: Kluwer, pp. 51–66. 9. Deiters, W. ; Goesmann, T.; Striemer, R. (1998): Risikogetriebene Vorgehensmodelle zur Entwicklung von Workflow-Management-Anwendungen. In: Herrmann, Th.;Scheer, A-W.; Weber, H. (Eds.): Verbesserung von Geschäftsprozessen mit flexiblen Workflow-ManagementSystemen - Von der Erhebung zum Sollkonzept. Heidelberg: Physica, pp. 107-124. 10. Dourish, P. (2001): Process Descriptions as Organizational Accounting Devices: The Dual Use of workflow technologies. In: Proc. of Group 2001. ACM. pp 52-60. 11. Dourish, P.; Holmes, J.; MacLean, A.; Marqvardsen, P.; Zbyslaw, A. (1996): Freeflow: Mediating between Representation and Action in Workflow Systems. In: Proc. of CSCW96. ACM. S. 190-199. 12. Eason, Ken (1988): Information Technology and Organisational Change. Taylor and Francis. 13. Ehn, Pelle; Sjøgren, Dan (1991): From System Descriptions to Scripts for Action. In: Greenbaum, J.; Kyng, M. (1991): Design at Work: Cooperative Design of Computer Systems. Hilldale, NJ: Lawrence Erlbaum, 1991. 14. Ellis C., K. Keddara, G. Rozenberg: Dynamic Change within Workflow Systems. In: Comstock, N. et al. (Hg.): Proc. Conference of Organizational Computing Systems (COOCS) ‘95. ACM-Press Milpitas, 1995, S. 10-21. 15. Ellis, C.A.; Wainer, J. (1994): Goal-based models of collaboration. In: Collaborative Computing. Vol. 1, no. 1, pp. 61-86. 16. Emery, Fred; Thorsrud, Einar (1976): Democracy at work. Leiden: Martinus Nijhoff Social Sciences Division. 17. Engeström, Y.; (1999): Activity theory and individual social transformation. In: Engeström, Y.; Miettinen, R.; Punamäki, R.-L. (1999) (eds.): Perspectives on activity theory. Cambridge. pp 19-52. 18. Feijen, M. (1997): Workflow for electronic Publications in a national Library. In: Practice & Theorie, Vol.21, No.3 1997. Elsevier Science Ltd.; USA. pp. 327-336. 19. Floyd, Chr. (1984): A Systematic Look at Prototyping. In Budde, R. et al (Eds.), Approaches to Prototyping, Springer. Pp 1-18. 20. Giddens, A. (1984): The Constitution of Society. Berkley. 21. Goguen, J. A. (1993): On Notation. Technical Paper. Download from http://wwwcse.ucsd.edu/users/goguen/pubs/ on 02/12/98. 22. Grinter, R.E. (2000): Workflow Systems: Occasions for Success and Failure. Computer Supported Cooperative Work (CSCW): An International Journal, vol. 9, no. 2, pp. 189-214. 23. Grinter, R.E. (2000): Workflow Systems: Occasions for Success and Failure. Computer Supported Cooperative Work (CSCW): An International Journal, vol. 9, no. 2, pp. 189-214. 24. Gruhn, Volker; Urbainczyk, Juri (1998): Software Process Modelling and Enactment: An Experience Report Related to Problem Tracking in an industrial Project. In: ICSE 1998, pp. 13-21. 25. Hammer, M; Champy, J. (1994) : Reengineering the cooperation : A Manifesto for Business Revolution. New York: Harper Collins.


35

26. Harada, K.; Tanaka, E.; Ogawa, R.; Hara, Y. (1996): Anecdote: A Multimedia Story boarding system with seamless Authoring Report. In: ACM Multimedia 96. pp. 341-351. Herrmann, Th.; Loser, K.-U.: (1999): Vagueness in models of socio-technical systems. In: Behaviour and Information Technology. Vol. 18, no.5, pp 313-323. 27. Herrmann, Th. (2000): Evolving Workflow by user-driven coordination. In: R. Reichwald/ J. Schlichter (eds.): Verteiltes Arbeiten - Arbeit der Zukunft; D-CSCW 2000. Stuttgart et al.: B.G.Teubner, pp. 103-114. 28. Herrmann, Th., Loser, K.-U.: Vagueness in models of socio-technical systems. Behaviour & Information Technology, vol. 18, no. 5, pp. 313-323. 29. Herrmann, Th.; Hoffmann, M.; Kunau, G.; Loser, K.-U.: (2002): Modelling Cooperative Work: Chances and Risks of Structuring. In: Cooperative Systems Design, A Challenge of the Mobility Age (Coop 2002). IOS Press. S. 53-70. 30. Herrmann, Th.; Loser, K.-U.: (1999): Vagueness in models of socio-technical systems. In: Behaviour and Information Technology. Vol. 18, no.5, pp 313-323. 31. Herrmann, Th.; Scheer, A-W.; Weber, H. (eds.) (1998a):Verbesserung von Geschäftsprozessen mit flexiblen Workflow- Management- Systemen - Von der Erhebung zum Sollkonzept. Physica-Verlag, Heidelberg. S. 73 - 106. 32. Herrmann, Th.;, A-W.; Weber, H. (eds.) (1998b): Verbesserung von Geschäftsprozessen mit flexiblen Workflow-Management-Systemen – Band 2: Vom Sollkonzept zur Implementierung. Heidelberg: Physica-Verlag, 1998. 33. Herrmann, Th.; Scheer, A-W.; Weber, H. (eds.) (1999): Verbesserung von Geschäftsprozessen mit flexiblen Workflow-Management-Systemen – Band 3: Erfahrungen mit Implementierung, Probebetrieb und Nutzung von Workflow-Management-Anwendungen. Heidelberg: PhysicaVerlag, 1999. 34. Herrmann, Th., Just-Hahn, K. (1998): Die Erhebung von Sonderfällen. In: Herrmann, Th.; Scheer, A-W.; Weber, H. (Hrsg.): Verbesserung von Geschäftsprozessen mit flexiblen Workflow-Management-Systemen - Vom Sollkonzept zur Implementierung. Physica-Verlag, Heidelberg. 35. Herrmann, Th.; Scheer, A-W.; Weber, H. (eds.) (2001): Verbesserung von Geschäftsprozessen mit flexiblen Workflow-Management-Systemen – Band 4 Heidelberg: Physica-Verlag, 2001. 36. Hepsø, V. (2002): Translating and Circulating Change – The Career of an Integrated Organization and Information Technology Concept. Trondheim: University. 37. Hoffmann, M., Goesmann, T., Herrmann, Th. (1998): Erhebung von Geschäftsprozessen bei der Einführung von Workflow Management. In: Herrmann, Th., Scheer, A.-W., Weber, H. (Eds.): Verbesserung von Geschäftsprozessen mit flexiblen Workflow-Management-Systemen - Von der Erhebung zum Sollkonzept. Heidelberg: Physica, pp. 15 - 72. 38. Hoffmann, M.; Diefenbruch M.; Goesmann, T.; Herrmann, Th. (2002): PRomisE2 - Gathering and Providing Situated Process Information in Knowledge Management Applications. Accepted for I-KNOW`02 (11 - 12 July). 39. Jørgensen, H.D. (2001): Interaction as a framework for flexible workflow modeling. In: Proc. Of Group2001. New York: ACM, pp. 32-41. 40. Kammer, P.J.; Bolcer; G. A.; Taylor, R.N.; Hitomi, A.S.; Bergman, M. (2000): Techniques for supporting Dynamic and adaptive workflows, JCSCW, vol. 9 nos. 3-4 , pp. 269 – 291. 41. Kuutti, K. (1992): Identifying Potential CSCW Applications by Means of Activity Theory Concepts: A Case Example. Proceedings of CSCW ´92, pp. 233-240. 42. Latour, B. (1999): Pandora’s Hope: Essays on the Reality of Science Studies. Cambridge: Havard. 43. Luhmann, N. (1995) Social Systems. Stanford,CA, University press.


36

44. Maturana, H. (1980): Man and Society. In: Benseler, F.; Hejl, P.; Köck, W.K. (eds.): Aupoiesis, Communication and Society: The theory of autopoietic system in the social sciences. Frankfurt, pp. 1-31. 45. Mintzberg, H.; Waterws, J.A. (1985): Of Strategies: Deliberate and Emergent. Strategic Management J. , 6, pp. 237-272. 46. Moody, D. (1996): Graphical Entity Relationship Models: Towards a more User understandable Representation of Data. In: Thalheim, B. (ed.): Conceptual Modeling. Berlin et al. Springer. pp. 227 – 244. 47. Mumford, E. (1995): Effective Systems Design and Requirements and Analysis - the ETHICS aproach. Houndsmill, Basingstoke, Hampshire and London: Macmillan Press LTD. 48. Nastansky, L.; Hilpert, W. (1994): The GroupFlow System: A Scalable Approach to Workflow Management between Cooperation and Automation. Paderborn: University, pp. 1-12. 49. Orlikowski, W. J. (1996): Improvising Organizational Transformation over Time: A Situated Change Perspective, Information Systems Research, Vol. 7, No. 1, March 1996, pp. 63-92. 50. Orlikowski, W. J.; Hofman, Debra (1998): An Improvisational Model of Change

Management: The Case of Groupware Technologies. In: Sloan Management Review, Winter 1997. pp. 11-21. 51. Pipek, V.; Wulf, V. (1999): A Groupware’s life. In: Proc. of ECSCW99. Dodrecht et al.: Kluwer, pp. 199-218. 52. Prinz, W., Kolvenbach, S. (1996): Support for Workflows in a ministerial environment. In: Ackerman, M. (ed.): Proc. of CSCW 1996. New York: ACM Press, pp. 199-208. 53. Robinson, M.; Bannon, L. (1991): Questioning Representations. In: Bannon. L.J.; Robinson, M.; Schmidt, K. (eds.) (1991): Proc. of ECSCW 91. Dordrecht et al. pp. 219-233. 54. Saastamoinen, H.; White, G. (1995): On Handling Exceptions. In: Comstock, N. et al. (eds.): Proc. of COOCS´95. New York: ACM Press, pp. 302-310. 55. Scheer, August-Wilhelm (1992): Architecture of Integrated Information Systems, Foundations of Enterprise Modeling. Springer, Berlin. 56. Schmidt K. (1999): Of maps and scripts - the status of formal constructs in cooperative work. In: Information and software technology 41, 1999. Amsterdam, Elsevier. pp. 319-329. 57. Schmidt, K.; Bannon, L. (1992): Taking CSCW Seriously: Supporting Articulation work. JCSCW. Vol. 1, nos. 1-2, 7-40. 58. Schmidt, K.; Simone, C. (1996): Coordination mechanisms: Towards a conceptional foundation of CSCW Systems Design. JCSCW, vol. 5, nos. 2-3, pp. 155-200. 59. Senge, Peter M. (1990): The Fifth Discipline. The Art & Practice of The Learning Organization. New York: Currency Doubleday 60. Star, Susan Leigh (1989): The Structure of Ill-Structured Solutions: Boundary Objects and Heterogeneous Distributed Problem Solving. In: Huhns, M.; Gasser, L. (eds.): Distributed Artificial Intelligence 2. Mento Park, CA: Morgan Kaufman. S. 37-55. 61. Suchman, Lucy (1995): Making Work Visible. In: Communications of the ACM Vol. 38, No. 9. pp. 56-64. 62. Suchman, Lucy A. (1983): Office Procedure as practical Action: Models of work and System Design. In: ACM Transactions on OIS, Vol 1; No 4; 10/83. pp. 320-328. 63. Suchman, Lucy A. (1987): Plans and situated actions: The problem of human-machine communication. Cambridge U.K.: Cambridge University Press. 64. Suchman, Lucy, A.; Wynn, Eleanor (1984): Procedures and Problems in the Office. Office: Technology and People 2, pp. 133 – 154.


37

65. Swenson, K. D.; Maxwell, T.; Matsumoto, B.; Saghari, B.; Irwin, K. (1994): A business process environment supporting collaborative planning. In: Collaborative Computing. Vol. 1, no. 1, pp. 15-34. 66. Thoresen, K. (1997): Workflow meets Work Practice. Mgmt & Info. Tech., vol. 7. no.1, pp. 2136. 67. Van der Aalst, W.M.P.; Basten, T. (2001): Inheritance of Workflows: An approach to Tackling Problems Related to change. Theoretical Computer Science, to appear 68. Volpert, W.; Kötter, W.; Gohde, H.-E.; Weber, W.G. (1989): Psychological evaluation and design of work tasks: two examples. In: Ergonomics, 1989, Vol.32, No.7, 881-890. Berlin. S. 881-890. 69. Walter, T.; Herrmann, Th. (1998): The Relevance of Showcases for the Participative Improvement of Business Processes and Workflow-Management. In: R. Chatfield, S. Kuhn, M. Muller (Eds.): Proceedings of the PDC 98., Palo Alto: CPSR. pp. 117 - 127. 70. Wargitsch, C., Wewers, Th., Theisinger, F. (1998): An organizational memory based approach for an evolutionary Workflow-Management-System. Concepts and implementation. In: Nunamaker, J.R. (ed.): Proceedings of the 31st Annual Hawaii International conference on System Sciences. Los Alamitos: IEEE Press, pp. 174 – 183.