Chapter XXIII Systems Design with the Socio-Technical Walkthrough

Transcription

1 336 Chapter XXIII Systems Design with the Socio-Technical Walkthrough Thomas Herrmann University of Bochum, Germany Abstract Socio-technical systems integrate technical and organizational structures and are related to various stakeholders and their perspectives. The design of socio-technical systems has to support this integration and to take the differing perspectives into account. To support this goal, the design concepts have to be represented with appropriate documentation methods, which combine formal and informal aspects. Communication processes have to be facilitated which systematically refer to these kinds of documentation. Therefore a socio-technical, semi-structured modeling method (SeeMe) is introduced. It represents socio-technical concepts with diagrams which can be developed, evaluated and improved by the socio-technical walkthrough (STWT). This facilitation method together with a corresponding software-tool has proven to be suitable for socio-technical design in complex, practical projects. A maximum of explicitness leads to a minimum of understandability Ungeheuer, 1982 (translated from the German p. 328) Introduction Socio-technical systems comprise the interaction and dependencies between aspects such as human actors, organizational units, communication processes, documented information, work procedures and processes, technical units, human-computer interactions, and competencies. They are characterized by continuous evolution which is influenced by interests, conflicts and power relations. The socio-technical walkthrough ( STWT, Herrmann, Kunau, Loser and Menold, 2004a; Herrmann, Loser Copyright 2009, IGI Global, distributing in print or electronic forms without written permission of IGI Global is prohibited.

2 and Jahnke, 2007) is a methodological approach to take this multitude of aspects into account and to make them the subject of communication, negotiation and decisions in the course of the development of socio-technical systems. The documents which accompany the STWT mirror these aspects and build bridges between the developing competencies, organizational change, programming or configuration of software and identification of appropriate hardware. We suggest that the expectations of the various stakeholders being involved are better met: the more technical and organizational structures as well as relevant competencies are integrated and aligned to each other, and the more the different perspectives of the stakeholders are taken into consideration, valued and integrated during the discourse which accompanies the participatory design and evolution of socio-technical systems. Systematical support of socio-technical system design can be based on a wealth of methods, guidelines and principles, for example design principles according to Eason (1988) Cherns (1976) and (1987); ETHICS, Mumford, (1995); scenario-based design, Carroll, (1995); or socio-technical requirements-engineering, Jones & Maiden, (2005). The background of Participatory Design (e.g. MUST, Kensing, Simonsen and Bødker, 1996) provides guidance on how to integrate the experience of different stakeholders. However, the documentation of the requirements and concepts which accompany the design process do not usually sufficiently support an integrated view on varying aspects such as technical and organizational structures. The experience within a series of practical projects reveals that the available approaches, like prototyping, diagrams of use cases, story boards, mock-ups as well as a set of different visualizations (e.g. for contextual design Holtzblatt, 2002) do not sufficiently support an integrated (over-)view of the interrelationships between the aspects of socio-technical systems. For example, prototypes direct the feedback of evaluators on issues of screen design and lead to a neglect of issues concerning work processes and cooperation between users. A central problem of socio-technical design is the integration of technical functions with social structures and perspectives. This problem can be overcome by appropriate guidance for conducting workshops and by means of documentation. We propose the socio-technical walkthrough (STWT) as a documentation and facilitation method. It has been gradually developed, evaluated and incrementally improved during the course of several practical cases (Herrmann, Hoffmann, Kunau and Loser, 2004b) in the field of Computer Supported Cooperative Work (CSCW). A set of workplaces where several people s cooperation and communication is supported by CSCW-software is a typical example of a socio-technical system. The STWT combines two parts: the socio-technical, semi-structured modeling method SeeMe with which diagrams can be developed to document the concept of the socio-technical system, and a facilitation method for workshops where walkthroughs are applied to the SeeMe-diagrams to inspect and improve them step-by-step by asking certain questions. For example, the STWT helped to develop a solution for improving the coordination between dispatchers and truck drivers with mobile handhelds (cf. the CASE-STUDY section below). Both roles as well as software-engineers and a project manager were involved to discuss and improve diagrams step-by-step. They clarified the technical functionality needed and the accompanying organizational change. After deliberate analyses and negotiations in four workshops the participants agreed upon more than 10 comprehensive diagrams which described the projected solution. The series of STWT-workshops can serve as a scaffold which sustains projects where software-development, organizational change and development of competencies are parallely pursued. The theoretical background of socio-technical systems as referred to by the STWT is outlined in the following section. A further substantiation of the STWT is given by describing our research approach. The following sections describe the modeling method SeeMe, the particularities of the 337

3 STWT and how they are technically supported. The conclusion quotes some reactions to the STWT from different standpoints and elucidates further research questions. BACKGROUND AND Theory Starting from the historical development of the term socio-technical (Emery & Trist, 1960) we saw the necessity to adopt elements of newer systems theory (especially Luhmann, 1995; Maturana & Varela, 1980) to achieve a better understanding of how a social system and a technical system can become integrated. The early socio-technical concepts mainly referred to the advantages achieved if... work organizations were envisaged as socio-technical systems rather than simply as social systems. (Trist, 1993, p. 39 referring to Trist, 1950) and if the management recognizes... that the success of an enterprise depends upon how it works as a sociotechnical system, not simply as a technical system with replaceable individuals added to fit (Emery & Thorsrud, 2001, orig. 1969, p. 85). Consequently Socio-technical design is an approach that aims to give equal weight to social and technical issues when new work systems are being designed. (Mumford, 2000, p. 125). The design-oriented approaches in the field of socio-technical research (Mumford, 1995; Checkland, 1981; Eason, 1988) mainly adhere to the early concepts of systems theory and therefore cannot sufficiently explain the central characteristics of social systems such as contingency and the limited predictability of the systems evolution. These approaches are related to the concept of open systems to explain the intense interaction between the sociotechnical system and its environment. However, this concept fails to explain why the system cannot be deterministically controlled from outside and therefore in general reacts differently to identical stimuli in its environment. To overcome this deficit we refer to Luhman s theory of social systems who combines the closed-system perspective of living systems developed by Maturana and Varela (1987) with Parson s (1967) concept of contingency. Luhmann (1995) defines a social system as a web of communication acts which develops and reproduces itself on the basis of rules which are communicatively made by this web itself. From this viewpoint, organizational units can be understood as a web of communications that negotiates, defines, maintains and adapts a set of conventions, which characterizes the identity of the organization. The strength of this approach is that social systems are analyzed and understood with respect to the particularities and properties of its communicational interactions. Luhmann considers communication as contingent: a communicational utterance cannot determine how receivers react to it but can only influence their reaction. Therefore social systems cannot be programmed; they develop a certain strength (with respect to learning and adaptation) through their inherent possibilities for freedom of decision and build a contrast to technical systems which are designed to be programmable and controllable from outside and are intended to be reliable due to their constancy. Contingency... is opposed to necessity and universality, contingency refers to variability and particularity; unlike constancy and certainty, contingency refers to mutability and uncertainty... (Pedersen, 2000, p. 413). On the one hand, contingency means that the reactions of a system to events in its environment are not predetermined, but that each reaction is one of many options. However, on the other hand, the system creates its own necessity in its pattern of reactions towards these events (Kirkeby, 2000, p. 11). Luhmann s theory cannot explain all kinds of socio-technical phenomena such as the emergence of virtual communities. Yet, emphasizing the relevance of communicational relationships gives a deeper understanding of socio-technical systems: The degree of integration between organisational and technical structures is closely interrelated to the extent of: communication about the technical system and about the ways of using, maintaining and adapting it, communication which is mediated with the technical system, 338

4 the reciprocal mirroring of on the one hand knowledge about the technical structures in the social communication and, on the other hand, representations of social structures within the technical system (e.g. via access rights). These aspects emphasize that a socio-technical system is more than the coincidental connectedness of technical components and human beings. Furthermore, we conclude that a socio-technical system can be considered as a combination of controllable structures and contingent structures. This contraposition can also be related to other differentiations such as plans vs. situated actions (Suchman, 1987), anticipatable vs. non-anticipated changes (Orlikowski, 1996), informal vs. formal communication (Kraut, Fish, Root and Chalfonte, 1990), maps vs. scripts (Schmidt, 1999). An appropriate method to model socio-technical systems and to make them a subject of deliberate, participatory discourses has to be able to cover the whole scope of these differences. The success and efficiency of a socio-technical system depends on its balance of contingent and controllable structures, and on an appropriate understanding of the dynamics of its context. In accordance with an activity-theory perspective, the developmental dimension of work activity is to be taken into account as well as the question of how transformations in the collective organization of work are accomplished (Engeström, 1999, p. 64). EMPIRICAL BACKGROUND and related work The STWT-approach for socio-technical design has been incrementally developed since 1997 (cf. Herrmann et al., 2004b). We first developed the modeling method SeeMe to represent concepts of socio-technical systems with graphical diagrams. For this purpose, we analyzed a set of common modeling methods for their appropriateness in modeling socio-technical systems (Green & Benyon, 1996; Harel, 1987; Oberquelle, Kupka and Maass, 1983; Rational Software Corp., 1997; Yourdon, 1989; Moody, 1996). SeeMe is inspired by the extendedevent-process-chain (eepc) developed by Scheer (1992), by use-case diagrams (Rational Software Corp., 1997) and by State-Charts (Harel, 1987). We have combined aspects of these methods and extended them with possibilities to express vagueness which includes incompleteness and uncertainty. Vagueness in SeeMe is related to a qualitative lack of information and not to quantitative probabilities. SeeMe was applied in several practical projects (cf. Table 1) where socio-technical systems were analyzed or conceived. Within these projects we were involved as researchers as well as consultants and were guided by an action research approach (Avison, Lau, Myers and Nielsen, 1999) that included a cyclic process: knowledge is applied in practical problem solving, becomes refined step-by-step, and is scientifically reflected. The studies took place in practical fields where they were focused on qualitative data and on singular temporal events, which cannot be repeated. With respect to practical problem solving we were involved as the facilitators of workshops and as the modellers who translated the contributions of the participants into graphical diagrams with SeeMe. During the phases of scientific reflection, the modeling method was improved on an empirical basis. The sceptical views on the usage of diagrammatic modeling (Bannon, 1995; Bowers, 1992; Ehn, 1988; Robinson & Bannon, 1991; Suchman, 1995) were taken into account. The first projects revealed that it mainly depends on the facilitation of the workshops as to whether the problems which are stated by these authors occur. Therefore, we used the successive phases of critical reflection to understand the challenges which could be observed during the facilitation of workshops. This reflection (Herrmann et al., 2004a; Herrmann et al., 2007) deals with questions of how to prepare the workshops and present the SeeMe-diagrams to the participants, to ask proper questions which refer to the diagrams, 339

5 to intertwine the facilitation with the modeling, to improve the technical support for developing, presenting and modifying the diagrams, to deal with conflicts and focus attention etc. The improvement of the STWT-method was also supported by an intensive comparison with other approaches of participatory design, documentation and workshop facilitation. The comparison is explicitly documented in Kunau (2006). In the context of university classes, we (Carell, Herrmann, Kienle and Menold, 2005) conducted a controlled experiment where we compared four groups of three students each who used traditional facilitation support (pin boards and flip charts) with four other groups using SeeMe-diagrams. It became significant that using SeeMe increases the number of commitments to the technology usage that was planned during the workshop. And afterwards, the usage was significantly more intensive than was the case with the control groups. These results can be related to the effect of applying the walkthrough to the diagrams, a process which promotes a very detailed consideration of the technical functions and of the commitments underlying the planned cooperation. A Socio-Technical, Semi-Structured Modeling Method The modeling method SeeMe (cf. Herrrmann et al., 2007) is based on communication theory which suggests that communicators only make explicit what is not already obvious by their context (Kienle & Herrmann, 2003) or common ground. A designoriented notation must not enforce the depiction of all details as they are needed for tasks such as programming or configuration. It must be possible to represent incomplete or uncertain information and to indicate those aspects of a model which are only incompletely specified. If misunderstandings occur because of this incompleteness it can be gradually reduced by making the diagrams more explicit and formal. For the early phases of designing socio-technical systems or processes it is reasonable to use a modeling notation which can: Visualize the complex interdependencies between different people, between humans and computers, and between technical components. Integrate overview sketches of the planned solution with the representation of rich details, should a contributor want to introduce them. Integrate formal and informal structures as well as technical and social aspects. Indicate vagueness (for example if it is not clear which sub-activities are part of a task or under which conditions these sub-activities are carried out). Represent conventions, interests, and multiple perspectives. SeeMe helps to describe the interaction between people and physical or technical objects of the world, and therefore differentiates between three basic elements (see Figure 1): Roles (e.g. end-user, STWT-Team) which represent a set of rights, duties and responsibilities as they can be assigned to individuals, teams or organizations by reciprocal expectations. Roles represent the social aspects and relations. Activities (e.g. running a workshop) which are carried out by roles or characterize the transitions between states of machines. They stand for the dynamic aspects which represent change, such as the completing of tasks, functions etc. Entities (e.g. SeeMe-diagram) representing resources used or modified by activities, such as documents, tools, computer systems, programs, items from the physical world. 340

6 Table 1. Practical projects as a basis of the continuous development of the STWT-Method Case Maximum number of Participants Workshops Diagrams** from-to Results Knowledge management for a training company Development of a training concept for a print workflow Introduction of library software Knowledge management for consumer counselling Mobile communication system for a logistics services company Groupware for collaborative ordering of scientific journal papers Software for the exchange of radiographies Knowledge management for steel pipe manufacturing Knowledge management for switchhousing contract manufacturing Knowledge management for a propshafts assembly plant Analysis of IT-based production of digital air photo maps 4 + 2* (trainers and office assistants) 6 + 2* (print-technicians) 8 + 1* (members of a university library team) 4 + 1* (incl. IT-specialist and job steward) * (incl. 3 dispatchers, 2 drivers, 2 SW-Engineers) * (incl. 2 student workers from library team, 1 softwareengineer) 5+1* (incl. 1SW-engineer, 2specialists, 1job steward) * (incl. 8 technicians of pipe welding team, 1 job steward, 1 IT-specialist) * (incl. 2 welding engineers, 2 IT-specialists) * (incl. 2 quality assurance, 2 assembly men) * facilitator, researcher, assistants or SeeMe-Modeller; ** only diagrams with more than 20 elements 3 + 3* (incl. 1 manager, 2 technicians) /99-07/99 07/99-01/00 11/00-05/01 02/01-10/02 12/02-03/04 07/03-08/05 01/05-05/05 05/06-11/06 04/07-12/07 08/07-12/07 10/07-02/08 complete requirements specification + new software (SW) training was conducted organizational change instead of SW-replacement software role out but less usage than expected explicit concept, complete prototype but no sw-introduction (due to management strategy) SW usage and continuous improvement for three years new SW introduced, ensuring high reliability new SW introduced, need for more explicit quality improvement activities was accepted new software introduced, knowledge sharing and work processes improved No software introduction but increased mutual knowledge base Preparation of establishing a new branch in a new country Elements can be embedded into other elements: a sub-element is part of a super-element. Sub-roles can represent parts of the organizational structure of a more complex role as shown in Figure 1; entities can contain their components as sub-entities. Subelements can contain further sub-elements. It is useful to differentiate between whether a super-element is completely described by its sub-elements or only partially. In the latter case, incompleteness is indicated by a semi-circle. It is empty if the incompleteness is intentional; three dots indicate that we do not know enough to complete the specification and that further research is required. A question mark indicates doubts about the correctness of the used sub-elements. SeeMe offers nine standard relations represented by arrows. Their meaning depends on the types of elements being connected and on the arrow s direction. The most used relations are (Figure 1): The role carries out [1] the activity. the activity influences [2] the role (e.g. enduser). an activity produces or modifies [3] an entity (diagram). an entity (editor) is used by [4] the activity. an activity is followed by [5] another one. Relations can be connected to super-elements or to one of its sub-elements (that means crossing 341

7 the border of the super-element). If a relation is connected with a super-element, it also refers to all of its sub-elements. Relations can be incompletely anchored to elements: If it is not clear whether a relation refers to the whole super-element or only to a subset of its sub-elements (and to which of them), the relation crosses the super-element (STWT-team in Figure 1) and is not connected to a distinctive sub-element. In figure 1, the facilitator is responsible for the entire activity while the other team members only carry out an unspecified set of sub-activities. Relations can be left out, for instance between sub-activities if it is not clear in which sequence they occur. Figure 1 displays two perspectives: in the lower one, the activities of running a workshop are strictly sequenced with the relations, while the upper case (without arcs) indicates that they can be freely combined. The two perspectives are separated by a segment line. With segments, the modeler can juxtapose different views of a phenomenon within the same element. The two perspectives are also an example of how the degree of structuring can vary in a diagram. Relations can be combined with logical connectors (depicted as rhomboids). Typical logical constellations are or, xor or and. However, the logical type of a connector can be left unspecified if its meaning is clear from the context of a diagram, or if it is not reasonable to be more precise. If relations are logically connected with OR or XOR (Figure 2), it depends on conditions or events whether a certain relation is instantiated. In many cases, this decision can be clearly derived from the context. If not, so called modifiers can be annotated (hexagons in Figure 2). Modifiers can also be incomplete: they can be empty if we only know that the instantiation of an element or relation depends on a condition but the condition is unknown or unstable. Unspecified conditions (empty hexagons) can be used to express freedom of decision as shown by case b) of Figure 2. Case a) is controlled by the explicit specification that all contracts with a value higher than 5000 are checked by a supervisor. Including a check can then be en- Figure 1. Basic elements of SeeMe 342

8 Figure 2. Control vs. freedom of decision embedding sub-elements. Furthermore, SeeMe is not restricted to only presenting a view on selected aspects such as functionality, data, organization or flows, but can also integrate these views. SeeMe is compatible with other, more formal methods, since it can mimic structures as they can be found in activity diagrams, eepcs or in flow charts; it can represent many structures which are needed for programming. Vagueness can either be retained or gradually eliminated in the course of socio-technical design when the concepts mature. Those parts of the diagrams where all involved stakeholders know how they could be completed can remain incomplete. If the context and conditions of the software usage vary from case to case so that no persistent decision can be made of how to overcome the vagueness, incompleteness is also sustained. The Socio-Technical Walkthrough (STWT) forced by a workflow system. By contrast, in case b) the condition is empty and the meaning of the empty hexagon is that the clerk decides ad-hoc whether a checking of the contract is necessary. SeeMe is constructed in a way that it is flexible in both directions: it can be used to express vague, informal structures and it can support formal specifications which are similar to UML-activity diagrams, flow charts, eepc (Scheer, 1992) or entityrelation-diagrams (Moody, 1996). The strength of SeeMe if it is compared with other methods is the possibility to express and indicate vagueness. Furthermore, it is not exclusively focused on the interaction with the technical system, as is the case with use-case diagrams in UML which can also be considered as a means to support informal drafts. By contrast, SeeMe supports the presentation of entire processes and work settings. Compared with methods which are similar to flowcharts, SeeMe has been extended by adding the possibilities for STWT supports a series of workshops which are the basis of a participatory design process. It is mainly used to design concepts for the development and usage of systems which support cooperation and coordination. The outcome of the participatory design is a concept or an outline of a socio-technical system which is represented by a set of diagrammatic models. These models are either developed from scratch or derived from existing work processes by gradually modifying a diagram with respect to the technology to be introduced. A model has to be inspected step by step before it is considered as the final solution. Therefore the model of the socio-technical system is incrementally modified at every workshop. The STWT can be compared with, and is partially inspired by, the Cognitive Walkthrough (Polson, Lewis, Riemann and Wharton, 1992). However, these two methods mainly support the tasks of a single evaluator while the STWT includes several participants and combines evaluation with design. The selection of the STWT-participants is a critical factor: end-users, project-leaders, representatives of 343

9 Figure 3. Hide mechanisms applied to Figure 1: The SeeMe-Editor with context-menu the software-developers or other technical experts, and possibly members of the management board have to be included. The participatory development of a sociotechnical system usually needs a whole series of workshops. The first walkthrough has to be prepared by deliberately eliciting the characteristics and achieving an understanding of the field where the socio-technical system is to be established or adapted. The preparation includes the decision of how the whole participatory process should start and with whom. Since all types of participants must easily become familiar with the diagrams, SeeMe is constructed in accordance with the principle of low threshold high ceiling : The three basic elements and some elementary types of relations are usually sufficient to start; afterwards, more complex notation elements can be introduced to express specific concepts. The first workshop may start with the task of achieving a mutual understanding of the work procedures. Further walkthroughs collect information about relevant aspects such as documents being used and produced, types of current technical support and possibilities for improvement. In a follow-up workshop it is asked for the needs and possibilities for supporting the work with information technology. This phase of repeated questioning is decisive for maximizing the requirements gathering. Finally, the evaluation of prototypes can be guided by the diagrams which depict the interactive relations between work and the IT-system. The series of walkthroughs should be concluded by ensuring that the participants agree on the consolidated models. There can be a fluent transition to the training phases which are needed to adopt the socio-technical system especially by those who were not able to take part in the participatory process. Walking through the models is a suitable means of conducting training. STWT-workshops are characterized by the following facilitation activities (cf. Figure 1): Getting started: The facilitator usually prepares a diagram representing the results of the previous work. It is reasonable to begin with an overview diagram and to proceed with a strategy of how to inspect the complete diagram step by step. 344

10 Asking prepared questions: The facilitator discloses some parts of the diagram by using hide-and-show mechanisms (cf. Figure 3). Each phase of such a disclosure is one step (of about 7-15 per workshop) which is accompanied by one or two prepared questions such as: What is the next sensible activity?, Which information support is needed for this activity?. Collecting contributions: The facilitator collects the answers, hints, proposals, comments, references to further documents etc. It is important that the stakeholders contribute their varying and potentially conf licting viewpoints and make comments. Focusing on the diagram: The diagram serves as a boundary object (Star, 1989) which integrates the varying perspectives of the participants into a larger picture. Therefore, the facilitator makes sure that the collected contributions are inserted into the diagram, which is used to focus the participants discussion and attention. Dealing with conflicts: making differing positions comparable and visible helps to deal with conflicts and to support congruence (cf. Cherns, 1987, p. 158). The possibility of intentional vagueness allows the participants to express several routes to the same goal (Cherns, 1976, p. 788), or as Coakes (2002, p. 7) writes the...same function can be performed in different ways. Depending on the social context, the eventual solution to a conflict is found by negotiation or by a decision of the management. These decisions can also be postponed until first practical experience with the socio-technical solution has been made. Modifying the diagram: Inserting the contributions into the diagram leads to a continuous documentation of the incrementally developed concept and provides the opportunity to represent the different requests for change. The incremental development is made visible so that all the participants can check whether their proposals are documented or not. The socio-technical project continues between the STWT workshops when the diagrams, which include all the comments, have to be aesthetically improved, checked against the audio-recording of the workshops, and linked to additional documents. The coordination with the software-engineers goes on. They usually explain their needs for further specifications and reduction of impreciseness. It became apparent during the case studies that certain technical features, which support the editing and presenting of the diagrams, are indispensable. With the SeeMe-editor, sub-elements and/or relations can be temporally hidden and then shown again step-by-step to support the walkthrough. An invisible sub-element is indicated by a grey semicircle; a hidden relation appears as a grey, thickened residue of the arc. Fig. 3 shows a version of Figure 1 after the hide-function has been applied. The hiding of sub-elements can be used to shrink the diagram. Varying appearances of a diagram can be stored in snapshots and can then be displayed like a slideshow. Furthermore, the SeeMe-editor provides features to add free text and comments to the diagrams, to draw geometrical dividers into a diagram (e.g. to depict swim lanes ), and to insert hyperlinks which allow the facilitator to show additional information or illustration. Initially we started with paper and pen material which may invite the participants to a more direct modification of the representations. However, electronic support offers more flexibility: Unlike passive design materials, such as pen and paper, computational design materials are able to interpret the work of designers and actively talk back to them. (Fischer, 2004, p. 158). Case study In a case study we (Herrmann et al., 2004a) accompanied a company which planned to improve the communication and coordination processes between dispatchers and truck drivers with mobile information technology. The company, which offers logistics services, also intended to improve its business processes. 1 The unit that is involved 345

11 in the case study is called steel-delivery. Steeldelivery is a team of seven dispatchers working in offices in three different towns, 17 drivers and a team-leader who also used to work as a dispatcher. Two managers from the logistics-company s head office have advisory functions for the team. They are responsible for the complete delivery logistics of a large steel trading company. The dispatchers of steel-delivery receive purchase orders from the steel trading company and assign them to deliverytours for the drivers who load their trucks according to the pile of purchase orders. They are on the road for between 4 and 10 hours a day. Only in the case of irregular events do they communicate with the dispatchers during the tour. Before and after their daily tour, the drivers come into the office to hand in the documentation from their last tour and to receive the paperwork and additional information for their next tour. The project s main goal was to design, implement and test a technical infrastructure which supports the communication and coordination between drivers and dispatchers. The research goal was to apply and to improve the STWT method. The project had four phases (Kunau, 2006): In phase 1) ethnographic methods were used to understand steel-delivery and to develop a starting point for the STWT workshops. This included 9 days of accompanying and observing the work of dispatchers and drivers. Additionally, interviews and analysis of documents were conducted. The results of the first analysis were documented in written notes, on tape, as photos and in one large diagram. STWT-workshops started in phase 2) in order to receive feedback on the analysis of the status quo, and began by eliciting the requirements for the software prototypes from a socio-technical viewpoint. In phase 3) we combined socio-technical diagrams with a work-oriented evaluation of GUI-prototypes. In phase 4), STWT-workshops were used for training purposes. All in all we conducted 4 STWT-workshops. Because of organizational restrictions, not always the same participants could take part; but we usually had two people representing the drivers and up to three representing the dispatchers. In addition, a software developer, a manager of the head office and the local team leader were present at almost all workshops. Figure 4 and 5 mirror the development of the technical solution. They both refer to the so-called daily-report which has to be continuously updated by the drivers during their tour. For example they have to note the name and town, times of arrival and departure, the mileage etc. for each customer. Originally, the Daily-Report was solely paper work for the driver. During the elicitation of the requirements in phase 2), the diagram shown in Figure 4 emerged. It includes the idea that the system could automatically read data such as the mileage from the truck s data interface. The drivers have to complete the data by entering whether a delivery has been successful or was disturbed by problems. Subsequently, the dispatcher can access the data at any time. Fig. 5 is then taken from phase 3) and shows the screenshot with which the drivers can enter remarks about their jobs into the system. The drivers working steps during the process of delivery are refined in Figure 5 and related to the screenshots of the mobile devices. This refinement was triggered by the question: How could SpiW- Com support this working step? In the original workshop setting the diagram and the screenshot were not integrated in an overlapping mode as shown in Figure 5. However, it became apparent that this is a useful feature which is now available with the SeeMe-editor. Since about 10 of the diagrams became very complex it became clear that the facilitator should be supported by an extra person who modifies the diagrams. A problem within this case study was the coordination with the software developers who had expected more formally specified requirements and preferred software engineering oriented modeling methods, such as UML. It is important that a representative of the software developers takes part in every STWT-workshop. During the workshops the usage of indicators for vagueness proved as being necessary and helpful. The semi-circle in the data -entity in Figure 4 is only one example. 346

12 Figure 4. New work process at the customer s site (Herrmann et al., 2004a, p. 135) Figure 5. Relating activities to prototypical screen shots (Herrmann et al., 2004a, p. 135) It indicates that mileage is only one type of data which is automatically retrieved and that it remains an open question as to whether other types of date could be automatically entered. The findings of the case study are repeatedly challenged by the question whether the participants were really able to understand the diagrams. It became apparent that they comprehended the models, since they related their statements to the diagram, pointed to its details, expressed doubts about its appropriateness, or made proposals for changing it. Lessons learned and directions for further research The STWT and the semi-structured modeling with SeeMe proved useful to develop concepts for sociotechnical systems in several practical cases. It can be considered as a success factor that the design teams were inspired to project their thoughts into real as well as planned work processes to consider the interaction with technical components stepby-step. The following quotes from participants characterize the impact of the STWT: 347

13 Comments with respect to the modeling method (Kunau, 2006, p.222): Project-Leader: When I look at it after a workshop, the systematics of the models is much easier to understand; the same would be true for an outsider Software engineer: the modeling is helpful. For each method there are advantages and disadvantages. The advantage [for SeeMe] is that the notation can describe weakly structured work procedures - that is obvious. But that also creates the disadvantage: certain analyses that are based on certain formalisms cannot be made. Driver 1: I quite liked that [documentation]; it was helpful for me to get a better, even better picture of the system, to become more familiar with it. Because it became more complicated,... Answers to the question (Kunau, 2006, p. 200): Now, after the workshop, do you consider it necessary and sensible that dispatchers and drivers establish rules for their cooperation with the new software? Project-leader: I regard it as very necessary because otherwise everybody would interpret and use the system differently. Manager: I find it quite sensible because by doing it we have cleared controversial issues in advance. Driver 2: That is very important because otherwise the whole system would not work. From the perspective of the case studies, the main questions which are left for further research deal with the appropriate selection and involvement of the participants, in particular if there are more stakeholders than can reasonably take part in the STWT-workshops. Furthermore, the interaction with the software-developers needs to be improved. Although it was an advantage during the workshops that a modeling method which helped all kinds of participants to express more complex structures and interdependencies was used, a transformation into more software-engineering-related representations has to be supported. Therefore, it is a reasonable goal to provide a semi-automatic transformation of SeeMe into other modeling concepts which are more directly related to the support of programming. Such a transformation has to include dialogue features which help to complete unspecified parts of the diagrams by asking for missing information. Besides these problems it can be advantageous to extend the STWT-method to the phases of maintenance and continuous improvement of socio-technical systems. SeeMe diagrams can become a means to support design in use (Henderson & Kyng, 1991) or meta-design (Fischer & Giaccardi, 2006). The need for modifications, can be documented within SeeMe diagrams, as well as the changes which have been made. Furthermore, a collection of SeeMediagrams and the history of their adaptation during use could form a basis to extract useful patterns of socio-technical constellations and dynamics which have been successful in previous projects. References Avison, D., Lau, F., Myers, M., & Nielsen, P. A. (1999). Action Research. Communications of the ACM, 42(1), Bannon, L. (1995). The Politics of Design: Representing Work. C ACM, 38(9), Bowers, J. (1992). The politics of formalism. In M. Lea (Ed.), Contexts of Computer-Mediated Communication (pp ). Hempstead: Harvester Wheatsheaf. Carell, A., Herrmann, Th., Kienle, A., & Menold, N. (2005). Improving the Coordination of Collaborative Learning with Process Models. In T. Koschmann, D. Suthers, T. W. Chan (Eds.), Proceedings of CSCL The next 10 Years (pp ). Mahwah, New Jersey: LEA. 348

14 Carroll, J. M. (Ed.). (1995). Scenario-based Design for Human Computer Interaction. New York: John Wiley. Checkland, P. (1981). Systems Thinking, Systems Practice. Chichester: John Wiley & Sons. Cherns, A. B. (1976). The principles of sociotechnical design. Human Relations, 9(8), Cherns, A. B. (1987). Principles of Sociotechnical Design Revisited. Human Relations, 40(3), Coakes, E. (2002). Knowledge Management: A sociotechnical Perspective. In E. Coakes, D. Willis, S. Clarke (Eds), Knowledge Management in the Sociotechnical World. The Graffiti Continues (pp. 4-14). London: Springer. Eason, K. (1988). Information technology and Organisational Change. London: Taylor & Francis. Ehn, P. (1988). Work-oriented Design of Computer Artifacts. Stockholm: Arbetslivscentrum. Emery, F., & Trist, E. (1960). Socio-technical Systems. In C. W. Churchman & M. Verhulst (Eds.), Management Sciences Models and Techniques. Proceedings of the sixth international Meeting of the Institute of Management Science (pp ). London: Pergamon Press. Emery, F., & Thorsrud, E. (2001). Form and Content in Industrial Democracy: Some Experiences from Norway and Other European Countries. London: Tavistock. Engeström, Y. (1999). Expansive Visibilization of Work: An Activity-Theoretical Perspective. Computer Supported Cooperative Work, 8, Fischer, G. (2004). Social creativity: turning barriers into opportunities for collaborative design. In Proceedings of the Eighth Conference on Participatory Design, 1, PDC 04. (pp ). New York: ACM. Fischer, G., & Giaccardi, E. (2006). Meta-Design: A Framework for the Future of End User Development. In H. Lieberman, F. Paternò, & V. Wulf (Eds.), End User Development Empowering people to flexibly employ advanced information and communication technology (pp ). Dordrecht, The Netherlands: Kluwer. Green, T., & Benyon, D. (1996). The skull beneath the skin: entity-relationship models of information artifacts. Inernational Journal Human-Computer Studies, 44, Harel, D. (1987). Statecharts: A Visual Formalism For Complex Systems. Science of Computer Programming, 8, Henderson, A., & Kyng, M. (1991). There s no place like home: continuing Design in Use. In J. Greenbaum & M. Kyng (Eds.), Design at work: Cooperative design of computer systems (pp ). Hillsdale, New Jersey: Lawrence Erlbaum Associates Inc. Pub. Herrmann, Th., & Loser, K.-U. (1999). Vagueness in models of socio-technical systems. Behaviour and Information Technology, 18(5), Herrmann, Th., Kunau, G., Loser, K., & Menold, N. (2004a). Socio-technical walkthrough: designing technology along work processes. In Proceedings of the Eighth Conference on Participatory Desig - Volume 1, PDC 04 (pp ). New York: ACM. Herrmann, Th., Hoffmann, M., Kunau, G., & Loser, K.-U. (2004b). A Modeling Method for the Development of Groupware Applications as Socio-Technical Systems. Behaviour & Information Technology, 23(2), Herrmann, Th. (2006). SeeMe in a nutshell. Technical Report /content/seeme/seeme_in_a_nutshell.pdf Herrmann, Th., Loser, K-U., & Jahnke, I. (2007). Socio-technical Walkthrough (STWT): A means for Knowledge Integration. In E. Coakes & A. Ramirez (Eds.), International Journal of Learning Organisation. Special Issue: Solving Problems in Knowledge Sharing with Sociotechnical Approaches, 14(5),

15 Holtzblatt, K. (2002). Contextual Design. In J. A. Jacko & A. Sears (Eds.), The Human-Computer Interaction Handbook (pp ). Mahwah, New Jersey: LEA. Jones, S., & Maiden, Nam (2004). RESCUE: An Integrated Method for Specifying Requirements for Complex Socio-Technical Systems. In J. S. Mate & A. Silva (Eds.), Requirements Engineering for Sociotechnical Systems (pp ). London: Idea Group. Kensing, F., Simonsen, J., Bødker, K. (1996). MUST A Method for Participatory Design. In J. Blomberg, F. Kensing, E. A. Dykstra-Erickson (Eds.), Proc. of the PDC 1996 (pp ). Palo Alto, CA. Kienle, A., & Herrmann, Th. (2003). Integration of Communication, Coordination and Learning Material A Guide for the Functionality of Collaborative Learning Environments. In Proceedings of the 36th Annual Hawaii International Conference on System Sciences (Hicss 03). Washington, DC: IEEE Computer Society. Kirkeby, O. F. (2000). Management Philosophy. Berlin: Springer. Kraut, R. E., Fish, R. S., Root, R. W., & Chalfonte, B. L. (1990). Informal Communication in Organizations: Form, Function, and Technology. In Readings in Groupware and computer-supported cooperative work (pp ). Menlo Park: Morgan Kaufman. Kunau, G. (2006). Facilitating Computer Supported Cooperative Work with Socio-Technical Self-Descriptions. PhD-Thesis, University of Dortmund: Luhmann, N. (1995). Social Systems. Stanford: University Edition. Maturana, H., & Varela, F. (1987). The Tree of Knowledge: The biological roots of human understanding. Boston: New Science Library. Maturana, H. R., & Varela, F. J. (1980). Autopoiesis and cognition: The realization of the living. Dordrecht, The Netherlands: Kluwer Moody, D. (1996). Graphical Entity Relationship Models: Towards a more User understandable Representation of Data. In B. Thalheim (Ed.), Conceptual Modelling (pp ). Berlin: Springer. Mumford, E. (1995). Effective Systems Design and Requirements Analysis: The ETHICS Approach. London: Macmillan Press Ltd. Mumford, E. (2000). A Socio-Technical Approach to Systems Design. Requirements Engineering, 5, Oberquelle, H., Kupka, I., & Maass, S. (1983). A view of human-machine communication and cooperation. IJMMS, 19, Orlikowski, W. (1996). Improvising Organizational Transformation Over Time: A Situated Change Perspective. Information Systems Research, 7(1), Parsons, T. (1967). The social System. London: Glencoe. Pedersen, P. P. (2000). Our present: Postmodern? In H. Andersen & L. B. Kaspersen (Eds.), Classical and Modern Social Theory (pp ). Malden, MA: Blackwell. Polson, P. G., Lewis, C., Riemann, J., & Wharton, C. (1992). Cognitive walkthrough: a method for theorybased evaluation of user interfaces. International Journal of. Man-Machine Studies, 36, Rational Software Corp. (Ed.) (1997). Unified Modelling Language. Documentation Set Version 1.0. Santa Clara, CA: Rational Software Cooperation. Robinson, M., & Bannon, L. (1991). Questioning Representations. In L. Bannon, M. Robinson, K. Schmidt (Eds.), Proceedings of ECSCW 91 (pp ). Dordrecht, The Netherlands: Kluwer. Scheer, A.-W. (1992). Architecture of Integrated Information Systems, Foundations of Enterprise Modelling. Berlin: Springer. 350

16 Schmidt, K. (1999). Of maps and scripts the status of formal constructs in cooperative work. Information and Software Technology, 41, Star, Susan Leigh (1989). The Structure of Ill-Structured Solutions: Boundary Objects and Heterogeneous Distributed Problem Solving. In M. Huhns & L. Gasser (Eds.), Distributed Artificial Intelligence, 2, Menlo Park, CA: Morgan Kaufman. Suchman, L. (1987). Plans and situated actions: The problem of human-machine communication. Cambridge U.K.: Cambridge University Press. Suchman, L. (1995). Making Work Visible, CACM, 38(9), Trist E. (1993). Introduction to Vol. II. In E. Trist & H. Murray (Eds.), The Social Engagement of Social Science. A Tavistock Anthology (pp ). Philadelphia: University of Philadelphia Press. Ungeheuer, G. (1982): Vor-Urteile über Sprechen, Mitteilen, Verstehen. In Ungeheuer (Ed.) Kommunikationstheoretische Schriften, 1, Aachen: Rader. Yourdon, E. (1989). Modern structured analysis. Englewood Cliffs, NJ: Yourdon Press Key Terms Contingency: Characterizes those relations between a stimulus and a system s reaction which are possible but not necessary. Semi-structured modeling: Systematic description of a socio-technical system which combines context-free specifications which vague descriptions. Socio-technical diagram: Graphical representation of a system which can be based on a predefined modeling notation. Socio-technical documentation: All kinds of representations, including diagrams, which describe the structures and processes of the interplay and integration between a social system and its technical components. Stakeholder: all roles which are affected by or have an interest in a socio-technical system Vagueness: Incomplete specifications within the documentation of a socio-technical system which are either incomplete or possibly, but not necessarily, incorrect under certain conditions. Walkthrough: Deliberate inspection of the documentation of a system which applies step-bystep a selected set of prepared questions. Endnote 1 The case study was funded by the German Government (grant 01HT0143) in the context of work in the e-business. 351