BEHAVIOUR & INFORMATION TECHNOLOGY, MARCH–APRIL
2004,
VOL.
23,
NO.
2, 119–135
A modelling method for the development of groupware applications as socio-technical systems THOMAS HERRMANN, MARCEL HOFFMANN, GABRIELE KUNAU and KAI-UWE LOSER Universita¨t Dortmund, Informatik and Gesellschaft, August-Schmidt-Straße 12, D–44221 Dortmund, Germany; e-mail: {thomas.herrmann, marcel.hoffmann, gabriele.kunau,
[email protected]}
Abstract. Special methodological approaches are needed, particularly in the area of modelling, to develop socio-technical systems in the field of CSCW. Engineering tasks and the development of organizational structures have to be integrated including elements of participatory design. From a theoretical background, needs for new modelling concepts can be derived: representation of contingency, explicit incompleteness, multiplicity of perspectives and self-referential meta-relations. Based on these concepts we developed the semi-structured, sociotechnical modelling method SeeMe and used it in five empirical cases to assess its practical relevance. We found that SeeMe can help people to become aware of the specific features and requirements of ‘their’ socio-technical system and therefore enables them to take part in processes of learning and improvement.
1. Introduction: analysing groupware applications as socio-technical systems It is widely acknowledged that Computer Supported Cooperative Work (CSCW) is an interdisciplinary field. This is due to the fact that on the one hand it deals with communication, co-operation and co-ordination which are subjects in sociology, psychology, anthropology and organizational sciences and on the other hand it deals with hard- or software, which are matters of computer science. Obviously, interdisciplinary efforts are needed to overcome the barrier between the different types of approaches and methods. This barrier can be described by referring to the basic differences between social and technical systems. Social systems are characterized by phenomena such as communication and cooperation between human individuals, emergence of meaning systems, self-referential development of structures and
learning processes, self-consciousness, and autonomy. In contrast, technical systems are characterized by artifacts, control, anticipation, state-transitions, preprogrammed adaptability, learning in respect to purposes which are determined from outside the system etc. This differentiation is well known – as well as the problems which it causes when a groupware system is introduced into an organization requiring a technical system and a social system to be integrated. When this integration is analysed or designed, the confrontation of the different paradigms underlying the involved disciplines causes well-known disputes. Examples refer to the difference of plans vs. situated actions (Suchman 1987), anticipatable vs. non-anticipated changes (Orlikowski 1996), informal vs. formal communication (Kraut et al. 1990) or the necessity vs. inappropriateness of categorization (Suchman 1994, Winograd 1994). We use the term ‘socio-technical system’ to cover both sides of this differentiation. This term, which has a long tradition (see below), is put into a new light by applying a theory of social systems as has been developed by Niklas Luhmann (1993b). It may appear questionable as to whether it is reasonable to introduce yet another type of theoretical consideration into the field of CSCW where a variety of theories such as activity theory (Kuuti 1992, Engestro¨m 1999, Turner and Turner 2001) or structuration theory (Giddens 1984) are already striving to be accepted as a grounding. One of the reasons that these theories have difficulties in being broadly accepted and adopted in the CSCW community is that they do not offer a sufficient foundation to support design. There are other approaches, which are more design-oriented (Checkland
Behaviour & Information Technology ISSN 0144-929X print/ISSN 1362-3001 online # 2004 Taylor & Francis Ltd http://www.tandf.co.uk/journals DOI: 10.1080/01449290310001644840
120
T. Herrmann et al.
1981, Eason 1988, Mumford 1995) with respect to sociotechnical systems, but they mainly adhere to the early concepts of systems theory and socio-technical design and cannot handle central aspects such as the lack of anticipation of the system’s evolution or the problems with contingency. As a consequence, some researchers (e.g. Hanseth and Monteiro 1998, McMaster et al. 1999) turn away from the concept of socio-technical systems and focus on those aspects of technology which lead to a web of multiple relationships between numerous actors (cp. Actor Network Theory (Latour 1999, Hepsø 2002)); while some practitioners doubt the relevance of a theoretical consideration of the interplay between social and technical systems. From our point of view, the orientation towards ‘systems’ is still appropriate in facilitating the dialogue between engineers and anthropologists as well as social scientists. It also provides sufficient potentials to explain the relationship between technology and social structures if it reflects new developments and aspects such as contingency, self-reference, situated action etc. We therefore introduce Luhmann’s approach into the discussion on the modelling of collaborative work as he combines new epistemological concepts with systems theory in the field of sociology. We found that the basic concepts (see section 2) of this theory are also relatable to those approaches which deal with social aspects in the context of information technology, such as activity theory (Kuuti 1992), coordination theory (Malone 1990), the studies of Kraut et al. (1990) on informal communication as well as the situated action approach (Suchman 1994) and the action language perspective (Winograd 1994). The essential question is whether these theoretical considerations can have any relevance for solving practical problems. We suggest that newer system theory helps to find appropriate concepts to describe and model aspects of reality and of the socio-technical system which is planned to be introduced. There are deficits when we need methods of description to support the design or shaping of socio-technical systems. This could be supported by modelling methods, but those which are available (such as UML or petri nets) focus too much on the engineering perspective and neglect the special characteristics of socio-technical systems. We have therefore introduced a set of new concepts for a modelling method which reflects the theoretical need to represent contingency, explicit incompleteness, multiplicity of perspectives and self-referential relations. The main outcome of this paper is that these concepts prove to be sensible from a theoretical point of view (section 4) as well as practicable in relation to an empirical background (section 5 and 6). We found that there is an urgent need to extend modelling methods with regard
to the characteristics of social systems since these aspects are not only neglected in the field of software-engineering but also in business-oriented approaches where modelling methods such as ARIS (Scheer 1992) have increased their influence with the ongoing deployment of ERP-software. Our modelling approach is not unaware of the large body of literature which has sceptical views on the usage of modelling methods to improve situated groupware applications (Ehn 1988, Robinson and Bannon 1991, Bowers 1992, Bannon 1995, Suchman 1995, Schmidt 1999). We have carefully analysed these positions and found that a differentiation of three levels is necessary (Herrmann et al. 2002): supporting the reflection on structure, explicit representation of structure and reification of modelled structure. We found that the success of using a modelling method depends on the chosen level, the purposes being pursued, the characteristics of the site, the participants’ experience and the features of the method itself. In section 2 we introduce some of the newer concepts of system theory which in our opinion need to be taken into account when modelling socio-technical systems. A review of existing modelling methods is given in section 3 together with an evaluation of their support for sociotechnical systems and a description of the basic modelling concepts of SeeMe. Section 4 then introduces modelling concepts to capture the specifics of sociotechnical systems. While section 4 resorts to abstract examples for the sake of clarity, five case studies are described in section 5 to prepare the ground for examples based on empirical work which are given in section 6.
2. The socio-technical approach and new concepts in systems theory The term ‘socio-technical system’ is often used in its basic meaning simply referring to a system that comprises of a social subsystem as well as a technical subsystem. Within the context of CSCW the term stands for the recognition that aspects of both, technical as well as social subsystems, need to be considered when an organization introduces new technology and that there is a very complex relationship between the two. For many researchers the term is also linked to a tradition founded at the Tavistock Institute in the 1950s: Trist and Bamforth (1951) and their colleagues analysed the situation in the British coal mining industry where productivity had dropped after the introduction of new technology. They found that along with the change of the technical system incisive changes in the social organization of the work had taken place. Enid
Modelling groupware as socio-technical systems Mumford (1995) transferred socio-technical concepts into the field of participatory design by developing ETHICS. Since the 1970s the socio-technical approach has been criticized for lacking real democratic concepts and not providing methods for participatory design (Ehn 1988). We agree with some of the criticism but we also see – as do some of the critics – that many insights, methods and instruments of the socio-technical approach are still valid and useful. When we use the term ‘socio-technical system’ we do so in acknowledgement of its history but also because we think that taking the original term literally and exploring its meaning in the light of new developments in systems theory and relevant social sciences can lead to helpful insights. From our perspective, the most relevant of these new concepts are the closed-system perspective on living systems developed by Maturana and Varela (1987), the neo-constructivists view on reality (von Glasersfeld 1996) and the dimension of self-reference (von Fo¨rster 1981). On this basis, Luhmann elaborates Parsons’ (1967) concept of contingency and Mead’s (1934) approach of exchanged perspectives.
2.1. Contingency and selectivity Living systems as well as social systems are autonomous with respect to the question of how they react to outside influences and how the perceived behavior of its environment is transformed into information processing or operations. The system selects whether and how it reacts on influences coming from the environment – this relationship between the environment’s stimuli and the system’s reactions is called contingency. Autonomy – as a basis of contingency – means that the behaviour of the system depends exclusively on its own structure (Varela 1981). The behaviour is oriented towards a continuous maintaining of the system’s identity and of its boundaries against the environment. The phenomenon that the system represents a unity which is perpetually re-made by the system itself is called autopoiesis (Varela 1981). The process of continuous self-remaking of the system is guided by a kind of description which is integrated into it as a part of itself. This phenomenon is one manifestation of self-reference (Luhmann 1993b): It is the system itself which implicitly – by remaking itself – ‘answers’ the question of which elements and relationships belong to it, or not. Luhmann stated that social systems are self-referential and therefore include descriptions of their own structures. If this kind of selfdescription can be found in the social system as well as in the technical system we can employ the term ‘reciprocal inscription’. The term inscription is used in Latour’s Actor Network Theory (Latour 1999, Hepsø
121
2002) to express the result of a translation process when an organization has integrated new patterns into its structures in the course of adaptation and innovation.
2.2. Incompleteness of Descriptions What a concrete system is or is not, always depends on the observers point of view. There are so many realities of a system as we have observing systems (including the observed system itself). Therefore, we have many different perspectives of how a system can be described and none of the descriptions is – compared with the point of view of others – complete. Incompleteness can be coercive – if the observer is not able to perceive certain aspects – or be intentional – if certain aspects are sorted out. One special characteristic of a socio-technical system is its way of developing itself. This includes special adaptation and adoption processes, e.g. when a system incorporates new technical elements. This adoption process is a social process, e.g. (Orlikowski 1996) which can only be incompletely planned and modelled in advance. Elaborated systems – especially socio-technical systems which can reflect their own evolution – can recognize parts of the incompleteness and the relevance of multiple perspectives.
3. The appropriateness of modelling methods for the design and practice of socio-technical systems To support the reflection and participatory discourses on the design and introduction of groupware applications, we can choose between different methods, for instance text based descriptions, rich pictures (Checkland 1981), or storyboards (Harada et al. 1996). Models, which are represented with diagrams, are only one possibility and it is not obvious that they are indispensable. Furthermore it can be questioned how far the modelling method should be based on a formal syntax, whether it should be domain specific and whether it should support different purposes such as requirements engineering, software development, or re-organization. Ehn (1988) suggests to design domain oriented organizational toolkits to create diagrams which are specifically appropriate for the organization under consideration. He states that the resulting diagrams are exclusively useful for the participants of the design project. We would extend the group of addressees of the artifact to more participants, because it is not likely that all potentially affected and relevant people are immediately involved in the design project. Usually, the diagrams are also relevant to many others, who possibly should act consistently with ideas
122
T. Herrmann et al.
that are represented by a method of externalization. Another argument is that design projects are embedded in an organizational setting to which they have several relations. The explicit description has to support these relations and a notation is needed, which provides enough formal consistency to be used in different domains and which is flexible enough to support different perspectives. Thus the description shares the characteristics which are typical for boundary objects. According to Star (1989): ‘Boundary objects are objects that are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use.’ To comply with the requirements of flexibility and robustness, we have developed a semi-structured, socio-technical modelling method (SeeMe). We have analysed a set of common modelling methods for their appropriateness in modelling sociotechnical systems (Oberquelle et al. 1983, Harel 1988, Yourdon 1989, Moody 1996, Green and Benyon 1996, Rational Software Corp. 1997). In particular HCI related research has developed a multitude of notations to visualize interactions between man and machine or the mediation of collective tasks by coordinative, communicative and cooperative artifacts. However a number of problems remain as becomes obvious with the most prominent cognitive approach for modelling HCI, the GOMS model (Card et al. 1983, John and Kieras 1996). It does not capture actors in different roles and therefore lacks a concept for modelling coordination requirements between multiple users. Distributed cognition (Hutchins 1995) on the other hand, focuses on the deployment of a scientific methodology but does not provide a practice-oriented, easy-to-use inventory of tools and methods, which are necessary for a wider adoption of the approach. Modelling methods are challenged by a variety of new developments: . . .
the metamorphosis of the computer from a singleuser tool to a multi-user media, technological advances, like workflow or enterprise resource planning systems, the interest in procedural relations between business activities as exemplified in the Business Process Reeningeering (BPR) approach (Hammer and Champy 1994).
These developments lead to new notations that integrate the representation of organizational, social and technological aspects of compound applications.
One prominent representative of this generation of modelling techniques is the extended-event-processchain (eEPC) developed by Scheer (1992) that is used, for instance, to configure business processes supported by a leading ERP-solution. The eEPC combines a modelling formalism based on Petri Net semantics to capture the flow of control with informal elements to depict various aspects of work-processes, like the access to resources or distribution of labour. Scheer’s work has significantly inspired the design of the basic elements of the SeeMe notation. However, eEPC does not provide means to indicate incompleteness or contingency. All in all none of the modelling methods mentioned above supports the differentiation between contingent and controlled interaction or between pre-programmed state-transitions and self-referential activities or enables different kinds of incompleteness to be indicated. The analysis of these deficits led us to requirements and the design rationale for the modelling method SeeMe. The method and the reasons for its specific notation have already been described in Herrmann and Loser (1999). We again describe some of the basic features which are needed to make our theoretical and empirical findings comprehensible. This description makes SeeMe comparable with other existing approaches while the next step (section 4) focuses on those aspects which are especially related to socio-technical phenomena. Basic elements: SeeMe is based on the concepts of role, activity, entity and relation. They reflect the conception of socio-technical systems from the point of view of contemporary activity theory. Activity is seen as mediating the transformation or the creation of material objects or immaterial cognitive entities by social subjects. Instead of distinguishing the object and the instrument of activity by using different concepts, as activity theory does, SeeMe models both, instruments and objects as being entities. The distinction becomes visible by relations: one entity is used, another is modified. Figure 1a gives an example of a simple SeeMe-diagram with the following basic elements: the role user, the activity requesting and the entities document and software system. Roles describe a set of rights and responsibilities assigned to a person, a group or an organizational unit. When persons playing a role1 are in action, they perform activities. Activities use entities as resources (documents, tools, computing systems etc.) or they manipulate entities. The distinction of role, activity, and entity is not strict. Entities like robots or software-programs can carry out certain procedures, ‘acting’ as artificial agents. Such procedures or methods constitute the entities’ behaviour and will be noted as activities being part of the element’s internal structure. However, the distinction of social actors from entities allows to emphasize social relationships and contingencies.
Modelling groupware as socio-technical systems Relations: To capture various relations between aspects of a socio-technical system SeeMe uses directed arcs that depict, for instance, the distribution of labor (when the arc is leading from roles to activities), the sequence of activities (when pointing from one activity to another), non-manipulating access on resources (entity to activity), mutual expectations (role to role), or the affection of roles by certain activities (activity to role). All mutual combinations between basic elements are possible and have a predefined meaning, which is determined by the types of basic elements being connected. For example: a relation between two activities means ‘is followed by’. Figure 1b) gives additional examples: the roles perform activity X and Y, activity X produces a document and activity Z modifies this document by using the technical system.
a) User
interacting Interest
requesting
Role A Software system
Role B competence
document Activity X
The diagram shows that it is not the document which is of main relevance for the user but the user’s interaction with the entire socio-technical system which produces the document. Connectors and Conditions: In addition to basicelements and relations, SeeMe provides AND, OR, and XOR-connectors to capture dependencies among relations. Similarly to Malone’s notation these connectors are inserted to capture dependencies among activities (Malone et al. 1999), but they can also be employed to model significant relations and dependencies between other basic-elements.
4. Concepts to capture socio-technical phenomena This section focuses on modelling aspects which enhance technically oriented notation sets with respect to the specialties of social systems as described in section 2. For example, a special relation in figure 1b expresses relations of ‘being interested’ by connecting a role with another relation. This means that the role is interested in the transition or the connection which becomes real when the relation is instantiated. It also becomes clear that SeeMe supports the nesting of elements: most relevantly the possibility of embedding competences into roles so as to indicate phenomena such as implicit knowledge.
User
b)
123
Activity Z
Document
4.1. Contingency and freedom of decision
technical System Socio-technical system
Figure 1.
Above we have defined contingency as the system’s possibility to freely select how it reacts to its environ-
Simple examples.
Employee [1]
Employee[2]
Employee[3] V x
Checking the decision
Preparing a decision
Figure 2.
V >z
Completing the decision
Determined decisions.
Employee [1]
Employee[2]
Employee[3]
Preparing a decision Checking the decision Completing the decision
Figure 3.
Roles making decisions.
124
T. Herrmann et al.
ment. In modelling methods the possibilities for selection can be represented by ramifications: two relations are combined with a XOR-connector (exclusive or). In figure 2 an XOR-connector is represented by a cross in a diamond. In technical systems it is clearly specified which branch of a ramification has to be chosen by adding conditions (hexagon symbols). In figure 2 the value being related to a decision specifies whether and by whom the decision has to be checked, and such a constellation is the typical basis for implementing a process with a workflow-engine. In the case of technical systems – such as workflow-engines – their behaviour is determined from outside2 in accordance with their purposes. Technical systems serve purposes which do not lie within themselves. In contrast, living systems as well as cognitive or social systems are autonomous in the sense that they determine their own purposes or rules of behaviour. Therefore, figure 3 uses a different representation which expresses that the employees make decisions how a case should be handled based on their knowledge. The empty hexagon is used, to indicate that in this case it is not sensible to determine any conditions. The roles which are involved have the autonomy to decide which branch of the ramification is chosen. Further support for representing contingency is the possibility of leaving the connector symbol empty. Thus, the employees (2) and (3) can decide whether one (XOR) or both (AND) will do the checking. In the case of CSCW, the constellations of figures 2 and 3 can be combined to express which decisions should be automated and which have to be made by humans.
4.2. Specific relations to express contingent selectivity In the context of technical systems, the relationships and therefore the interfaces between different elements are clearly specified. Figure 4 gives a simple example of a technically supported dialogue: the diagram shows that only after a question is completed (and conveyed, e.g. by e-mail), the answer can start. Therefore the relation is linked to the outside of the activity ‘asking’. In contrast, in the context of direct human communication answers can start before the question is
X
Y
asking
answering
completed. This is represented by an arrow which starts figuratively inside of the activity (see figure 5). This relation has an unspecified start point since it is not possible to determine any sub-activities of ‘asking a question’ with which it could be connected. This should not be confused with formal expressions, such as ‘Y can start after X has begun’ (Glance et al. 1996). Y can not start before a role has decided that a significant part of X has been completed. Therefore the roles being involved have to decide when the transition to the next activity starts. This kind of contingency can also be applied to the usage of entities: in figure 4 the answer is technically created and this should imply that all the items of the information source (e.g. a database) are taken into account. In contrast, if a person checks an information source to answer a question, the answer can vary from time to time and it depends on psychological factors (e.g. motivation or pursued aims) how the relevant parts are selected. Autonomous, contingent decisions as well as technically pre-defined selections are often combined in the context of CSCW and have to be represented together in one description.
4.3. Complete vs. Incomplete specifications Figure 5 expresses that only two types of sources (e.g. a programmers’ and the users’ manual) are used to give an answer. However, in many situations it might be sensible to express that even more information sources could be used than being depicted in the diagram. Generally spoken: It is usually impossible to specify all sub-elements which might be embedded into an element (e.g. an entity). It might be due to the complexity of a social system that it is not reasonable or possible to find out or to anticipate all the elements which belong to it. As pointed out in section 2 this is a typical characteristic of autopoietic systems which are also a subject of continuous adaptation to maintain their identity and
X
Y
asking
answering
Information source
Inf. source Ð Type 1
Inf. source Ð Type 2
Information source
Figure 4.
Dialogue under the conditions of technical support.
Figure 5.
Contingent selectivity in human interaction.
125
Modelling groupware as socio-technical systems self-reference. Therefore SeeMe allows the modeller to represent various kinds of vagueness as shown in figure 6. The empty semi-circle indicates that further specification of sub-elements might be possible but is not advisable because of a highly dynamic situation or because of the possibility of autonomous decisions being involved. Similarly the incomplete specification of an attribute’s value is expressed by a blank between parentheses. The three dots in the semicircle indicate that further specification is advisable but not possible and that further research is necessary. A question mark is used if the correctness of a specification is doubted. These symbols are necessary because many aspects of the structure or behaviour of an autonomous system cannot be sufficiently made explicit or anticipated. The notation of SeeMe implies that elements which do not contain sub-elements are obviously incompletely specified with regard to their sub-elements. In these cases, the empty semi-circle can be considered as implicitly conotated while its explicit use helps to avoid misunderstandings if only a part of the sub-elements but not all of them are shown.
4.4. Multiple concepts of reality and multiple perspectives As argued above different observer systems have different views on a system. None of them can be complete. In some cases it can be sensible to represent these different views in an integrated manner. Therefore SeeMe allows a modeler to represent different perspectives of decomposition of an element. Figure 7 shows two different ways of how the activity ‘Analysing of work conditions’ can be decomposed. The first one refers to a view of topics of the analysis, while the second one refers to the methods which are used.
database (see figure 8). This kind of change is different from the phenomenon of evolution which is based on structural change of a system, for instance the modification of the data structure of a database. Therefore we introduce a special symbol named metarelation (zigzag arrow in figure 8) to represent this type of modification. It can also be used to represent the self-referential process of autopoietic remaking which is based on a sub-system of a system which contains a description or a model of this system itself (see figure 8). Meta-relations are very useful in theoretical models, but hardly employed for practical cases.
5. Empirical background The examples given above are fictive and derived from theoretical considerations. However, the design of the socio-technical modelling method SeeMe has been informed by the experience of numerous case studies where we found that people were able to understand and use the diagrammatic modelling concepts. Since there is no single case study which can demonstrate the relevance and supportiveness of the full range of different concepts of SeeMe, we chose five case studies which will be described in this section. Each of these case studies describes the usage of special features of the modelling method. The studies are part of an ongoing action research process to develop the theories and methods which are presented in this paper.
Analysing of work conditions Analysing the Flow of information
Information source;
Information source;
next update: ( )
next update: 02-02-02 (?)
Inf. Source Ð type 1
Inf. Source Ð type 1
Inf. Source Ð type 2
Inf. Source Ð type 2
Conducting interviews
Various kinds of vagueness.
Observation
Analysing Documents
...
Figure 7.
Alternative decompositions of an activity.
entering data
modifying the data structure
System model of the System remaking
Database-system
. . .
Figure 6.
Analysing the Hierarchy
...
4.5. Self-Reference, evolution and meta-relations A system is dynamic by changing the values of its attributes. One example is the entering of data into a
Analysing Payment
Figure 8.
Examples for Meta-Relations.
126
T. Herrmann et al.
Action Research is a well known framework for information systems research (Avison et al. 1999), which includes expansion of scientific knowledge as well as practical problem solving in social settings (Lewin 1946). In a cyclic process, knowledge is applied in practical problem solving and thereby becomes refined step-bystep. Several critics of the action research approach relate to the validity of conclusions from very few lengthy projects, to the low control of the environment which leads to uncontrollable variables, and the personal involvement of the researcher, which creates a bias in the results. In response to these critics action research should be conducted with multiple cycles of refinement of results and the presentation of studies should follow specific guidelines (Kock et al. 1997, McKay and Marshall 1999). Especially the scientific goals should be clearly differentiated from the goals of the organization. While the previous sections were dedicated to our scientific interests, this section gives an overview of conducted studies and the lessons learned from each of the studies. Each of the projects also provides us with a different area of application of the modelling method, seeing that the application of the method is not limited to a certain kind of organization or software system, but has a broad scope of practical relevance. The descriptions of the first two cases are given in more detail to explain the method of deriving the elements of concrete diagrams from a process of participative data gathering (1st case), and to outline how the process of design and implementation is supported by diagrams to achieve a socio-technical solution (2nd case). In section 6 we will use concrete examples from these case studies to provide plausibility for the practical relevance of the different modelling concepts for socio-technical systems.
5.1. Case 1: New processes for a new software in a university library The first case is located in a university library: the introduction of a new technical system was the trigger for a radical organizational change. SeeMe was used to model the intended usage of the new technical system as well as the new organizational procedures. In this case it was of special importance to be able to allow the participants to be vague while working on the diagrams. Many instances of vagueness were eliminated at the end – however – during the process they helped the group to agree on interim versions of the diagrams. Vagueness was also used to elucidate the characteristics of a complex task by only enumerating some examples of its subtasks. Since
such an enumeration can never be complete, symbols were needed for incompleteness. Two departments of a university library were expected to use a new software-system for their work on the acquisition and cataloguing of books. Since there was a fundamental difference between the current organizational practice of co-operation and the type of processes triggered by the new technology, we were asked to support the redesign of the work processes. The traditional practice in the library was to start with the acquisition and then do the cataloguing. Now, with the availability of software system based catalogues, the simplification of the cataloguing reduces the required competence for the handling of most of the new books. With the new system, cataloguing can be carried out in the early steps of the process and guarantees a high quality of data. Another reason to introduce this new system is the seamless integration into the softwareplatforms of the other departments. However, the software system proved to be not sufficiently adaptable to the situation in the library. Within this project we developed a diagrammatic representation so that we could plan and discuss the possible practice with the new system. Figure 9 shows the overview of the diagram, including the main tasks performed during the modelling process. At the end of the process the group should have a ‘shared’ understanding of what future practice may look like. We conducted 11 workshops, in which the goals of the group were to design the work process, to create a documentation for reference purposes and to enable the departments to share experiences with the software system already been used. At the beginning of the modelling process, overviews were created showing the participating roles and the main activities of the process. They were based on the answers to the questions of what the main tasks for acquisition and cataloguing are. Furthermore, detailed tasks and subtasks of the main activities were informally collected to create an idea of the areas to be described. In the preliminary diagrams, vagueness-elements (semicircles with three dots) indicated the incompleteness of the diagrams. The participants agreed to use this early diagram to organize the modelling process. During the process, the participants discussed and envisioned the future practice step by step and referred to the diagram as an artifact which was continuously under development. Future practice was developed using the diagrams, and arguments for design variants were collected by envisioning what this practice would be like. The initial diagrams of the detailed parts were sketched using cards on pin boards and converted between the sessions into PowerPoint slides. The
127
Modelling groupware as socio-technical systems Preparation for Lending Checking and Ordering Checking
Ordering
Inventorying
Inventorying
Domain expert
Cataloguing
Check at domain expert
Sticking media number
Cataloguing
SIAS booking
Acquisition and cataloguing Bibliography, User request Info material, lists
Figure 9.
Figure 10.
delivery
Overview of the acquisition and inventorying process.
Participatory development of diagrams.
current state of the diagrams was plotted on posters and hung around the meeting room to be present for reference and correction. Figure 10 is a composition of some photos to provide an impression of what the development of the diagrams looked like. The final phase of the design process was to integrate the remaining special cases such as the handling of electronic dissertation theses, messages regarding orders, expiration of the delivery period, crediting/subsequent demand, bills, books for approval, gifts, donations or barter deals (all hidden in figure 9, but linked to a visible residue – the black semi-circle – on Acquisition and cataloguing).
During the final session, the diagrams were checked and adapted for consistency and correctness. The models supported the workgroup discussions about the design of the work processes under three aspects (for more details cf. (Loser and Herrmann 2002)): . . .
Adapting the work practice Allocating integrated tasks to the members of the personnel Workarounds, to overcome deficits of the system, where it was not in accordance with the specialties of the library
128
T. Herrmann et al.
5.2. Case 2: Designing a collaborative knowledge management system In the second case a knowledge management system was designed and introduced into a consumer counseling organization with the intention to reduce paperwork. The electronic distribution of the organization’s documents required a change of most of the organizational processes; in particular those related to the quality assurance of any modifications made to documents to be published. Vagueness was important in modelling the unclear and changing responsibilities for the verification process. A precise matching between roles and activities was only possible for some subtasks. Since it was neither the goal of the project nor wished for by the participants to be more specific, the vagueness remained in the diagrams. The system designed in this case is based on a commercial software (Livelink1). Together with consultants and members of the customer’s project team we used SeeMe diagrams to discuss, negotiate and document many facets of the application’s configuration and organizational environment: the hierarchy of contents to be shared within the application, data models, role definitions, access relations between roles and contents etc. This process involved technical aspects such as the design of metadata schemes as well as social aspects of the envisioned collaboration system, like the discussion
Scientific Assistant
Creating and revising consumer information
Verification
Editing a complete counselling Selecting a topic verification Editing an individual consumer procedure recommendation Creating new Updating Correction? recommend. recommend.
about use cases and the configuration of the business process. Figure 11 shows a diagram that was presented and discussed during a requirements specification workshops. The diagram visualizes the organizational changes which were related to the central production and publishing of counseling materials for local agencies. Crossed out activity and entity symbols point at the elimination of work steps and formerly used artifacts. An encircled sub-activity highlights changes within one sub-activity. During the negotiations of the organizational and technical design, many more diagrams were created and repeatedly compared with sample counselling materials from the existing archives. Figure 12 displays a snapshot of a diagram taken from the requirements specification document that was agreed upon after six months of analysis, discussion and design work between the consultants and the consumer counseling organization. It depicts the three major steps in the process of creation and publishing of consumer counseling materials and relates them to ElFi, the ‘Elektronisches Fachinformationssystem’ (electronic counseling-information-system). Therefore, the diagram serves as an example of how organizational and technical aspects can be integrated in a single representation. In the requirements specification document, diagrams are linked to natural language
Head of ........ Department
Release
Verification by group leader Verification by department II Verification by management
Classifying information O.K.
Verification by external unit
Draft version of Consumer information Request for correction Consumer Information Folder Figure 11.
Consumer Counselling Agency
Visualizing organizational and technical change in Case 2 (translated).
Final editing Publishing in “Hausgemacht” Updating index & TOC “Hausgemachtes” FMBeitrag Consumer Information
Updating Consumer Information Folder
Modelling groupware as socio-technical systems
129
After introduction of the system the same translation mechanism is used in reverse direction to create diagrammatic representations that visualize the evolution of the content hierarchy. Figure 13 shows translations between alternative representations and the application of diagrams for the configuration of a knowledge management application and for monitoring its evolutionary development in use.
5.3. Case 3: Analysing requirements for a knowledge management system for a training company
Figure 12. SeeMe diagram as part of requirements specification document.
usage scenarios as well as mock-up images and prototype screenshots that illustrate interface design. In this case study, the content hierarchy and metadata schemes were represented with SeeMe-diagrams as well as with a commercial mind mapping tool. To record and visualize the progress of group discussions, the project team favored the mind mapping tool as it allowed them the rapid creation and manipulation of a protocol. However, the SeeMe diagrams were preferred to display the relations between the roles, entities and activities that had been discussed and captured in the mind map. They provided a more readable image of complex relationships. XML-based import and export functionalities of the diagramming tools allowed us to synchronize both types of representations automatically during the negotiation process. Another highly valued contribution of the diagrams in this case was their facilitation of prototype creation. The diagrammatic representations had already been used during the requirements analysis stage to create various alternative initial configurations of the content hierarchy of the installed knowledge management system. Based on Livelink’s XML-Import functionality, diagrams were mirrored into hierarchies of folders, corresponding metadata schemas, and access rights could then be derived very efficiently. Especially the user in the counseling organization’s task force responded positively to this opportunity of testing alternative content configurations.
A small company offering training for leadership and sale stands in the centre of the third case study. The trainers and back office staff wanted to introduce a Know-How-Repository as a means of storing their training concepts. Here it was of utter importance to express the different ways in which the trainers organized their work. If the models had not shown the various contingencies of human work but rather masked the individual options in fulfilling the tasks, the models would have given a wrong impression of the situation and would have thereby lead to wrong implications for the technical system to be designed. We used SeeMe-Diagrams to suggest usage scenarios that integrated the design of a Know-How-Repository and the support of centralized procedures in the organization. Furthermore, we used SeeMe to capture and compare the results of ethnographic studies of the trainers’ working processes. The project resulted in a requirements definition that was passed to software developers and served as part of the contract between them and the training company. A varying number of trainers and two assistants participated in six workshops. The whole process was done in two cycles. During the first workshop, results of the ethnographic studies were presented and discussed. In the second workshop, a design proposal of the system was discussed to gather more requirement information and in the third workshop a final concept was presented. The first cycle focused on selected types of elements (e.g. teaching material) supporting trainings. The second cycle extended this to the whole variety of training elements. The main task was to design a software-system, but we tried to emphasize the priority of organizational design (e.g. division of labour, sequencing of tasks) throughout the entire project. Prototyped screens were only presented in relation to diagrams which presented the process of collaboration. Most of the adaptations and corrections of SeeMe diagrams were gathered during the negotiation processes in the organizational
130
Figure 13.
T. Herrmann et al.
Translations between alternative representations.
design workshops. They were the basis for generating the more software oriented requirements in the remaining workshops.
5.4. Case 4: Developing a tool for qualifying workers for new printing technology The fourth case study deals with a printing company that had newly introduced digital printing techniques using PDF-files. After a few experts had gained experience on the new machines, it was their goal to train others. We used socio-technical diagrams as the basis for the trainings. The technical complexity of the task was the challenge in this case: The decision as to whether or not a given file would lead to an acceptable printout needed a combination of experience and expertise which could not easily be captured in a model. Besides this it was not a goal to make all of this experience and expertise explicit in the models. It was sufficient to indicate that skilled people were needed and that they had to take the responsibility in deciding whether a printing process should be aborted or not. Therefore the team did not model all pre- and post-conditions of error situations and used a vague representation which left the decision to the people involved in the process. We discussed and developed a diagram that showed the PDF-Workflow – their process of creating print products using the Adobe Portable Document Format.
In the course of this workflow, various tools are used in a specific manner to create, check and process the various types of files and physical products. The underlying technology was newly introduced and only few experts with practical experience in using and configuring the tools were available. It was therefore intended to use the diagrams to train newcomers in the specifics of the process as well as to provide them with an overall understanding of it. Another, similar usage of explicit process descriptions is described by Dourish (2001). The gathering of information and the developing of the diagrams were integrated. The participants learnt to use the notation while creating the diagrams. A first diagram was created (initial modelling session) that gave an overall view of the major tasks in the process. Afterwards, missing details were filled in and new modelling constructs were introduced and applied instantly. During the discussions it became obvious, that the modelling components were understood and that they contributed to a shared understanding of the work practice. Finally, the last two sessions were used to prepare a training unit for other members of the organization. Screenshots were integrated to show how tasks are performed using the existing tools. Some numbers elucidate the complexity of the final model: An overview provides links to 18 detailed models with 271 basic elements (165 without repetitions) including 55 activities, 80 entities and 30 roles, connected with 240 relations.
131
Modelling groupware as socio-technical systems 5.5. Case 5: Developing a software system in a finance institution In this case, the aim of a finance institute was to develop a software system which helped to process the administration of governmental funds. A facilitator had to support the process of requirements engineering. She started by interviewing the administration department to compile a catalogue of the main functions. The result was a diagram representing the main activities and events which occur during the handling of applications for funds. In a best case procedure (figure 14 represents an extract), the main activities were: data entering, formal checking, checking for completeness, technical checking, calculating and preparation of the approval documents. However, there were several possible events and conditions causing a deviation from this ideal procedure, e.g. that further documents or an expert’s advice have to be asked for. Modelling with SeeMe was used to gain an overview; the resulting diagram was mainly used to discuss the problem of the activities being sequenced too strictly. The employees claimed that they were used to working more or less synchronously on the different tasks of a single case. Their work can also carry on if certain activities are pending. Eventually SeeMe was used to present a compromise between standardization and flexibility without loosing the option for vagueness and incompleteness (see figure 18 for an example).
6. Analyzing cooperative work with socio-technical modelling concepts The case studies described in section 5 provide many examples that illustrate how socio-technical modelling concepts can be used in real situations where sociotechnical systems have to be understood or developed. However, the open question remains whether the new concepts of the notation systems – as described in section 4) – are really relevant. Therefore, in the following sub-sections we describe real examples where
‘contingency’ and ‘incompleteness’ occurred and show how we have represented them with diagrams
6.1. Contingency 6.1.1. Unspecified conditions: In SeeMe diagrams empty hexagons represent situations where a decision is left to the role(s) being involved. Figure 15 gives an example from case 3: during a consultation (shown on the left) the trainers help the customers to specify their requirements for training. These trainers told us that they sometimes but not always have a review with an assistant and that this review might include a report on the customers’ expectations and potentially – but not definitely – this might be followed by a further consultation. This is a typical example of contingency as it occurs in the context of communication processes. According to Luhmann (1993a), three types of selections take place: the selection of information to be communicated by the first person, the selection of the form used for communication and the selection of information actually received by the second person. The trainers were not able to tell us the conditions of their ‘selections’ in advance because these vary with different persons and situations. Therefore, we used the empty hexagons to express that there are conditions involved which cannot be anticipated. The three dots indicate, that the review can contain further, unknown sub-activities. We had a similar situation in case 4 (pdf-workflow, figure 16) where we had to express that either subactivities of the pdf-workflow or even activities which lie outside of the pdf-workflow have to be activated in the event of an error or a mishap. Whether the solution lies inside or outside the pdf-workflow depends on variable conditions. This constellation is expressed by the empty hexagons. Also the kind of the ramification – whether or, xor or and – could not be specified in advance. This kind of incompleteness is due to the fact that the ‘not-okay’ situations were not
negotiating
checking formal
for
checking
completness
tech-
cal-
nical
cu-
checking
lating
asking for and obtaining
obtaining an
further documents
expertÕs advice
preparing for
consultation with the customer
acceptance
rejection
review with the assistance reporting the customerÕs expectations
Outlining an offer
asking for consultation ...
Figure 14. sequence.
Main activities of fund handling – idealized Figure 15.
Unpredictable conditions in Case 3.
132
T. Herrmann et al.
really understood and left space for the handling of exceptions. The ‘pdf-workflow’ activity can be considered as a socio-technical system which comprises technical components such as a pre-defined procedure. not every decision which is necessary in dealing with exceptions can lie inside of these technical components but must be specified from outside. How an exception is dealt with depends on the purposes of the pdfworkflow which are influenced by the printing company and its customers. The empty hexagons represent conditions which can only be specified by the roles (and the actors) of the social system at the moment when an instantiation of the pdf-workflow is carried out. In both cases (3 and 4), an indicator for unspecified conditions was needed to express what the interviewees told us and to make their situation more visible. 6.1.2. Unspecified anchoring of relations: Figure 16 expresses further contingent selections since the ‘notokay’ back loop has a non-specified start point – this means that the problem can be detected in any subactivity. Furthermore, the ‘not-okay’-relations do not point to specified elements. This implies that the back loop can lead to every sub-activity of the pdf-workflow – even to those which are not specified in advance (their existence is expressed by an empty semi-circle). Relations which are not completely anchored to elements proved to be an ideal means of expressing contingency. Figure 16 also presents an example of how relations to unspecified parts of entities or resources are also reasonable: The documentation of the underlying order of a pdf-workflow case is only partially used when the film is produced. Which part of the folder is used (it is rarely the whole folder) depends upon human decisions. Unspecified relations proved especially helpful if the assignment of roles to activities was based on a flexible division of labor. In case 3 (figure 17), we were told that a completely specified set of roles is given (trainer, customer and assistant) but that the work allocation cannot be anticipated. The fact that each of the three can be involved in the activity ‘outlining an offer’ is expressed with the non-specified start point of the arrow. It also expresses that at least one role has to be active. This construction is always useful if the extent of participation cannot be pre-specified in collaborative work settings. Another example is the avoidance of strict sequencing: One of the most important advantages of nonspecified relations can be found in the area of interconnected activities if it is necessary to avoid strict sequencing. Case 5 gives an example. Figure 14 presents a strict sequence as it was the result of the interviews
with the employees. For instance, figure 14 requires that checking is in the first instance completed before ‘obtaining further documents’ is carried out and has to be restarted afterwards. By contrast figure 18 presents a solution preferred by the employees: Here the semantics of the unspecified sequencing relation means that they can – if they want to – continue the checking for completeness while they wait for further documents. It is also expressed that it is neither sensible to try to specify the sub-activities from which the ‘asking and obtaining further documents’ starts nor to specify which sub activity exactly follows after they have been obtained. The same type of unspecified sequencing can be applied in many other situations. The concept of non-anchored start – or endpoints of relations offers a representation for selections which are autonomously made by the social system and its roles in accordance with its own principles (cp. Section 2)
pdf-workflow
not okay
exposing the film
producing a film
delivering the film
Documentation of the order
Figure 16.
Handling of exceptions in Case 4.
customer
trainer assistant
outlining an offer
Figure 17.
Vague allocation of work in Case 3.
Checking for completeness
Asking for and obtaining further documents Figure 18.
Avoiding strict sequencing in Case 5.
133
Modelling groupware as socio-technical systems 6.2. Incompleteness The design of socio-technical systems includes making a decision as to whether certain contributions of roles to the functioning of the system can be contingent or are restricted by the technical components. Section 6.1 gave examples of how this decision can be delegated to the roles of the system and how this delegation can be expressed by using graphical models. The decision to restrict possibilities for behaviour is only reasonable if the set of options for effective activities is sufficiently known. Since this is not the case in many constellations, the notation elements of SeeMe can be used to deal with incompleteness 6.2.1. Referring to parts vs. to the totality of an element: It is sensible to use relations which are related to the totality of an activity – particularly if an activity is being carried out for the first time and none of its subactivities have already been started. An example is ‘review with the assistant’ in figure 15. However, if the same activity is started a second time, e.g. by a back loop (initiated by ‘outlining an offer’ in case 3, figure 15), it is usually the case, that the activity is only partially repeated. However, we do only have incomplete knowledge to decide in advance which of the subactivities should be repeated. Therefore the selection has to be decided by the roles being in charge. The differentiation between these two types of relations proved to be reasonable in many cases. Another example is obtained if we alter figure 17 by adding a relation which is specifically typed as ‘being responsible’ (see figure 19). This relation refers to the totality of all three roles and indicates that they are responsible altogether for the outcome of the activity ‘outlining the offer’. This responsibility is given even if one of the roles decides not to contribute to the activity. It was frequently useful in our cases to visualize the difference between these two types of relations. 6.2.2. Incomplete specification of sub-elements: One of the main reasons for incompletely specifying the subelements of an element was that completion was neither required nor sensible because of the dynamic change or
the enormous number of possible variations of constellations. Therefore we have often only listed some examples as sub-elements and added three dots in a semi-circle to indicate that further research is needed, if a more complete description is necessary. Figure 20 gives an example of an activity (‘checking and correcting’) which is partially specified and explained by three examples which are represented as sub-activities and where completeness was not expected. In our cases, three dots and question marks were often applied to indicate aspects which required further investigation. A very special but striking example could be found in the library (case 1) where the representation of a role was required although it was neither appropriate to assign a name to it nor any attributes. This role was related to a special activity which could also be carried out by other roles. However, the role had to be represented because it was necessary to give someone a job for social reasons who was not able to work on other, more complex tasks. Since there was no sensible approach to how this role could be integrated into an official chart of the organization, everyone was happy with the solution shown in figure 21: A unspecified role is shown which puts the inventory number into the books and the notational symbol question mark indicates that the correctness of the unspecified role is doubtful and therefore a rethinking will have to take place at a certain point of time. This phenomenon that something exists which officially does not exist (Mambrey and Robinson 1997) can often be found. It is typical for social systems and becomes disclosed when new technology is introduced which influences the cooperation and division of labours. checking and correcting checking the file formats checking the fonts checking consistency
... Figure 20.
Specification by example in Case 4.
inventory
customer
trainer
office
domain ?
expert
assistant being responsible
invento-
putting a
chek-
rying
number into
king
the book
outlining an offer
Figure 19.
Responsibilities in Case 3.
Figure 21.
Unspecified Role in Case 1.
134
T. Herrmann et al.
7. Conclusion We have found many examples where the usage of explicit representation of incompleteness helped members of workshops to agree on a shared viewpoint of how things should be described. Thus the modelling of characteristics of social systems, such as contingency, incompleteness, multiple views on reality and selfreference is particularly useful in cases where processes of reorganization are combined with the introduction of technical support of cooperation. The representation of these characteristics is the more sensible the more the contrast with the possibilities of highly determined structures and processes of technical systems has to be made visible and understandable. We found that the specific concepts of our modelling method were understood: the participants of the workshops started to refer to these concepts in their comments and arguments. We found theoretical and empirical evidence that modelling methods can support the development of socio-technical system in the field of CSCW. The modelling method must contain specific concepts which are related to the characteristics of socio-technical systems. On this basis, the explicit modelling and reflection of structures is an appropriate means of strengthening the success of participatory projects when introducing groupware and developing patterns of its usage. The proposed semi-structured modelling concepts can serve as a means of self-description of the socio-technical system (cf. section 2). Self-descriptions of social systems are usually encoded in conventions, in the verbal elements of a shared semantic system, a meaning system or even in written rules or laws. In contrast, technical systems are described by engineering artefacts. Computer systems in particular are described by softwareengineering orientated modelling methods or program code. Both types of descriptions are frequently separated, often not made explicit and hardly reflecting each other. Semi-structured models as they were used in the projects described can build a bridge between both perspectives.
Notes 1. Our notion of roles is chosen to indicate that individuals have a specific relevance and meaning on the sociological level which is different to their existence as psychological systems. This connotation of roles should not be confused with organizational positions or a set of rights in a workflow system. In cases where it is necessary to represent an individual person, this can be done in SeeMe by using the
concept of roles; since the function of maintaining the identity as a person can also be considered as a role. 2. Even if the state transitions of or the interactions between technical systems are pre-programmed in analogy to autonomous or learning behaviour, there is still the need for the success of the programming efforts to be evaluated in controlled experiments.
References AVISON, D., LAU, F., MYERS, M. and NIELSEN, P. A. 1999, Action Research, C ACM, 42(1), 94–97. BANNON, L. 1995, The Politics of Design: Representing Work, C ACM, 38(9), 66 – 68. BOWERS, J. 1992, The politics of formalism, in M. LEA (ed.) Contexts of Computer-Mediated Communication, (Hempstead: Harvester Wheatsheaf), pp. 232 – 261. CARD, S., MORAN, T. P. and NEWELL, A. 1983, The Psychology of Human-Computer-Interaction (Hillsdale: Lawrence Erlbaum). CHECKLAND, P. 1981, Systems Thinking, Systems Practice (John Wiley & Son). DOURISH, P. 2001, Process Descriptions as Organizational Accounting Devices: The Dual Use of Workflow. In Proceedings of Group 2001, (New York: ACM), pp. 52 – 60. EASON, K. 1988, Information Technology and Organisational Change (London: Taylor and Francis). EHN, P. 1988, Work-oriented Design of Computer Artifacts (Stockholm: Arbetslivscentrum). ENGESTRO¨M, Y. 1999, Activity theory and individual social transformation. In Y. ENGESTRO¨M, R. MIETTINEN and R.-L. PUNAMA¨KI (eds) Perspectives on activity theory (Cambridge: Cambridge University Press), pp. 9 – 52. GLANCE, N., PAGANI, D. and PARESCHI, R. 1996, Generalized Process Structure Grammars (GPSG) for Flexible Representations of Work. In Proceedings. of CSCW96. (New York: ACM) pp. 180 – 189. GIDDENS, A. 1984, The Constitution of Society (Berkley). GREEN, T. and BENYON, D. 1996, The skull beneath the skin: entity-relationship models of information artifacts, Int. J. Human-Computer Studies, 44, 801 – 829. HAMMER, M. and CHAMPY, J. 1994, Reengineering the Corporation (Harper Business). HANSETH, O. and MONTEIRO, E. 1998, Understanding Information Infrastructure, Manuscript available online: http:// www.ifi.uio.no/*oleha/Publications/bok.html, Download in December 2001. HARADA, K., TANAKA, E., OGAWA, R. and HARA, Y. 1996, Anecdote: A Multimedia Story boarding system with seamless Authoring Report, ACM Multimedia, 96, 341 – 351. HAREL, D. 1988, On Visual Formalisms, C ACM, 31, 514 – 529. HEPSØ, V. 2002, Translating and Circulating Change – The Career of an Integrated Organization and Information Technology Concept (Trondheim). HERRMANN, Th., HOFFMANN, M., KUNAU, G. and LOSER, K.-U. 2002, Modelling Cooperative Work: Chances and Risks of Structuring. In M. BLAY-FORNARINO, A. PINNA-DERY, K. SCHMIDT and P. ZARATE´ (eds) Cooperative Systems Design, A Challenge of the Mobility Age (IOS Press), 53 – 70.
Modelling groupware as socio-technical systems HERRMANN, Th. and LOSER, K.-U. 1999, Vagueness in models of socio-technical systems, Behaviour and Information Technology, 18(5), 313 – 323. HUTCHINS, J. 1995, Cognition in The Wild (Cambridge: MIT Press). JOHN, B. E. and KIERAS, D. E. 1996, Using GOMS for User Interface Design and Evaluation: Which Technique?, ACM Transactions on Computer-Human-Interaction, 3(4), 320 – 351. KOCK, N. F., MCQUEEN, R. J. and SCOTT, J. L. (1997) Can action research be made more rigorous in a positivist sense? The contribution of an iterative approach. Journal of Systems & Information Technology, 1(1), S1 – S24. KRAUT, R. E., FISH, R. S., ROOT, R. W. and CHALFONTE, B. L. 1990, Informal Communication in Organizations: Form, Function, and Technology, in Readings in Groupware and computer-supported Cooperative Work, (Menlo Park: Morgan Kaufman) 145 – 199. KUUTTI, K. 1992, Identifying Potential CSCW Applications by Means of Activity Theory Concepts: A Case Example, Proceedings of CSCW ‘92, 233 – 240. LATOUR, B. 1999, Pandora’s Hope: Essays on the Reality of Science Studies (Cambridge: Havard). LEWIN, K. 1946, Action research and minority problems, Journal of social issues, 2(4), 34 – 47. LOSER, K.-U. and HERRMANN, Th. 2002, Enabling factors for participatory design of socio-technical systems with diagrams, Proceedings of PDC 2002 – Participatory Design Conference (Palo Alto: CPSR). LUHMANN, N. 1993a, Essays on Self-Reference (New York: Columbia). LUHMANN, N. 1993b (5th ed., 1st 1987), Soziale Systeme. Grundriß einer allgemeinen Theorie (Frankfurt: Suhrkamp). MALONE, T. W. 1990, What is Coordination Theory and How Can it help design cooperative work Systems?, Proceedings of CSCW ‘90, 357 – 370. MALONE, T. W., CROWSTON, K., LEE, J., PENTLAND, B. and O’DONNELL, E. 1999, Tools for Inventing Organizations. Toward a Handbook of Organizational Processes, Management Science, 45(3), 425 – 443. MAMBREY, P. and ROBINSON, M. 1997, Understanding the role of documents in a hierarchical flow of work. in S. HAYNE and W. PRINZ (eds.) W. Group 97: The Integration Challenge. (New York: ACM), 119 – 127. MATURANA, H. and VARELA, F. 1987, The Tree of Knowledge: The biological roots of human understanding (Boston: New Science Library). MCKAY, J. and MARSHALL, P. (2001), The dual imperatives of action research. In: Information Technology & People Vol. 14 No. 1. (MCB University Press) 46 – 59. MCMASTER, T., VIDGEN, R. and WASTELL, D. 1999, Networks of Association and Due Process in IS Development, in T. J. LARSEN, L. LEVINE and J. I. DEGROSS (eds.) IFIP WG8.2 and WG8.6 Joint Working Conference on Information Systems: Current Issues and Future Changes (Luxemburg), 341 – 357. MEAD, G. 1934, Mind, Self and Society. From the Standpoint of a Social Behaviorist (Chicago: University of Chicago Press). MOODY, D. 1996, Graphical Entity Relationship Models: Towards a more User understandable Representation of Data, in B. THALHEIM (ed.) Conceptual Modelling (Berlin: Springer), pp. 227 – 244.
135
MUMFORD, E. 1995, Effective Systems Design and Requirements and Analysis – the ETHICS approach (Basingstoke: Macmillan Press). OBERQUELLE, H., KUPKA, I. and MAASS, S. 1983, A view of human-machine communication and co-operation, IJMMS, 19, 309 – 333. ORLIKOWSKI, W. 1996, Improvising Organizational Transformation Over Time: A Situated Change Perspective, Information Systems Research, 7(1), 63 – 92. PARSONS, T. 1967, The social System (London: Glencoe). RATIONAL SOFTWARE CORP. Ed. 1997, Unified Modelling Language. Documentation Set Version 1.0. (Santa Clara, CA: Rational Software Cooperation). ROBINSON, M. and BANNON, L. 1991, Questioning Representations. In L. BANNON, M. ROBINSON and K. SCHMIDT (eds.) Proceedings of ECSCW 91 (Dordrecht), pp. 219 – 233. SCHEER, A.-W. 1992, Architecture of Integrated Information Systems, Foundations of Enterprise Modelling (Berlin: Springer). SCHMIDT, K. 1999, Of maps and scripts – the status of formal constructs in cooperative work, Information and software technology, 41, 319 – 329. STAR, S. 1989, The Structure of Ill-Structured Solutions: Heterogeneous Problem Solving, Boundary Objects and Distributed Artificial Intelligence, in M. HUHNS and L. GASSER (eds.) Distributed Artificial Intelligence 2. (Menlo Park: Morgan Kauffmann), 37 – 55. SUCHMAN, L. 1987, Plans and situated actions: The problem of human-machine communication (Cambridge: Cambridge University Press). SUCHMAN, L. 1994, Do Categories Have Politics? The language/ action perspective reconsidered, Computer Supported Cooperative Work (CSCW) 2(3), 177 – 190. SUCHMAN, L. 1995, Making Work Visible, CACM, 38(9), 56 – 64. TRIST, E. and BAMFORTH, K. 1951, Some social and psychological consequences of the long wall method of coal getting, Human Relations, 4, 3 – 38. TURNER, P. and TURNER, S. 2001, Describing Team Work with Activity Theory, Cognition, Technology & Work (London: Springer), 127 – 139. VARELA, F. 1981, Autonomy and Autopoiesis, in G. ROTH and H. SCHWEGLER (eds) Self-organizing Systems: an interdisciplinary approach (Frankfurt, New York), 14 – 23. VON FO¨RSTER, H. 1981, Observing Systems: Selected Papers of Heinz von Fo¨rster (Seaside, CA: Intersystems Publications). VON GLASERSFELD, E. 1996, Radikaler Konstruktivismus (Frankfurt am Main: Suhrkamp). WINOGRAD, T. 1994, Categories, Disciplines, and Social Coordination, Computer Supported Cooperative Work (CSCW) 2, 191 – 197. YOURDON, E. 1989, Modern structured analysis (Englewood Cliffs, NJ.: Yourdon Press).
TM
Livelink is a registered Trademark of Open Text Corporation.
