Brahms-Simulating Practice 1 BRAHMS : SIMULATING PRACTICE FOR WORK SYSTEMS DESIGN

A continuing problem in business today is the design of human-computer systems that respect how work actually gets done. The overarching context of work consists of activities, which people conceive as ways of organizing their daily life and especially their interactions with each other. Activities include reading mail, going to workshops, meeting with colleagues over lunch, answering phone calls, and so on. Brahms is a multiagent simulation tool for modeling the activities of groups in different locations and the physical environment consisting of objects and documents, including especially computer systems. A Brahms model of work practice reveals circumstantial, interactional influences on how work actually gets done, especially how people involve each other in their work. In particular, a model of practice reveals how people accomplish a collaboration through multiple and alternative means of communication, such as meetings, computer tools, and written documents. Choices of what and how to communicate are dependent upon social beliefs and behaviors— what people know about each other’s activities, intentions, and capabilities and their understanding of the norms of the group. As a result, Brahms models can help human-computer system designers to understand how tasks and information actually flow between people and machines, what work is required to synchronize individual contributions, and how tools hinder or help this process. In particular, workflow diagrams generated by Brahms are the emergent product of local interactions between agents and representational artifacts, not pre-ordained, end-to-end paths built in by a modeler. Clancey, et al.: Brahms-Simulating Practice 2 We developed Brahms as a tool to support the design of work by illuminating how formal flow descriptions relate to the social systems of work; we accomplish this by incorporating multiple views— relating people, information, systems, and geography— in one tool. Applications of Brahms could also include system requirements analysis, instruction, implementing software agents, and a workbench for relating cognitive and social theories of human behavior. Clancey, et al.: Brahms-Simulating Practice for Work Systems Design 3 OVERVIEW OF OBJECTIVE, THEORETICAL STANCE, AND CONTRIBUTION Brahms is a multi-agent simulation framework (Tokoro, 1996) for modeling work practice, incorporating state-of-the-art methods from artificial intelligence research and insights about work and learning from the social sciences. A Brahms model is a kind of theatrical play, intended to provoke conversation and stimulate insights in groups of people seeking to analyze or redesign their work. Rather than modeling technical knowledge in detail, Brahms models focus on the conventions by which people choose to use particular tools and interact with each other, such as how they communicate. The quality, methods, and evaluation criteria of technical problem solving— the focus of most computer systems design— are constrained by this social-interactional context (Sachs, 1995; Schon, 1983; Weickert, 1995; Zuboff, 1987). We hypothesize that multiple, complementary views— cognitive, social, physical— integrated into one model provide a better basis for understanding organizations than cognitive task models, which are disembodied and oriented around individuals, or business process models, which are overly abstract, and hence decontextualized. More generally, we are interested in how organizations change themselves, and thus how to design a workplace so that people will dynamically reconfigure their processes, use of tools, and collaboration to creatively affect how a job gets done (Nonaka and Takeuchi, 1995). In Brahms we apply and extend knowledge-based techniques in a way that seeks to understand how information and workflow actually happens. Our approach demonstrates how symbolic cognitive modeling, traditional business process modeling, and situated cognition theories may be brought together in a coherent approach to the design of human-computer systems. This introduction provides an overview of our objectives, theoretical stance, and contribution to human-computer system design. Subsequent sections in this paper describe the relation of Brahms to situated cognition and workflow modeling, the methodology, provide examples, present results, and analyze broader implications. Practice, work systems design, and modeling work Broadly speaking, work practice may be contrasted with work process; practice concerns how people actually behave within a physical and social environment, as distinct from the functions they accomplish. For example, a description of work practice might include who picks up a fax, where it is delivered (to a desk? to a group of mailboxes? ), and when this is done. In contrast, a typical description of work process would only show that an order, for example, is sent from one organization to an agent who processes it. The faxing process and how it is carried out might not be mentioned at all. In short, a model of practice is oriented around agents— how they interact with their environment and what they do during the course of a day. A model of work process is typically oriented around work products (such as orders)— how they are transformed and flow Clancey, et al.: Brahms-Simulating Practice for Work Systems Design 4 from one transformation to the next. A key finding of our work is that a representation of work process, such as work flow diagrams, can be derived from the result of a simulation of practice. The notion of “practice” is central to work systems design, which has its roots in the design of socio-technical systems, a method developed in the 1950s by Eric Trist and Fred Emery (1959, 1960). Socio-technical systems design sought to analyze the relationship of the social system and the technical system, such as manufacturing machinery, and then design a “socio-technical system” that leveraged the advantages of each. Work design (Ehn, 1989; Greenbaum and Kyng, 1991; Pasmore, 1994; Weisbord, 1987 (see Chapter 16)) extends this tradition by focusing on both the formal features of work (explicit, intentional) and the informal features of work (as it is actually carried out “in practice,” analyzed with the use of ethnographic techniques). The aim of analyzing both the formal and the informal work practices is two-fold: to understand what it takes to actually accomplish a business function in order to use those insights in design, and to ensure that new designs of work can be effectively implemented. Socio-technical and work systems design aim at producing both a productive workplace and a positive work environment, which fosters human development by providing dignity, meaning and community. By contrast, business process reengineering focuses on the structuring of key business process, eliminating duplication and unnecessary steps, formulating processes and procedures and using information technology extensively to improve work processing. Consequently, business process reengineering focuses more exclusively on tasks, does not take into account the informal nature of work, and does not hold as important the dignity of work or human development. In short, work design includes a focus on practice, while business process design exclusively focuses on process (Sachs, 1993). The methods of business process reengineering (BPR) and work system design differ considerably. BPR tends to be conducted by external consultants who analyze the flow of work products in terms of business functions, and not how product get from one place to another. Work design is more typically carried out by people who actually do the work (both workers and managers), and emphasizes not only what flows, but how and why work products manage to get from one place to another. For example, managers, office workers, crafts people, and researcher-facilitators collaborate to understand an existing work setting (such as new order processing for a telecommunications company) in order to develop a comprehensive design for the business organization, work process, computer tools, documents, facilities (such as seating arrangements), training, performance metrics and incentives, etc. Both approaches may also be contrasted with an economic or business strategy analysis, which invents the products and services that both business process reengineering and work system design seek to deliver. Clancey, et al.: Brahms-Simulating Practice for Work Systems Design 5 The two approaches differ in their view of how information technology should be used. In BPR, models of technical problem-solving, for example, tend to result in business process designs in which information technology is seen as an opportunity to “do the work” (e.g., to automate as much of the work as possible). In work systems design, information technology is seen in terms of augmenting and supporting human work practices. These outlooks have profoundly different consequences for the design of software systems. We emphasize that in work design the design process attempts to treat everyday work as the result of a combination of interacting conceptual and physical influences and that practices will develop over time through learning and worker invention. Because work systems are not simply “implemented,” but develop and grow through the learning of communities, workers and designers (such as software engineers) must collaborate in the design process (Greenbaum and Kyng, 1991). The differences in these two approaches reflect theoretical underpinnings about the nature of knowledge and learning (what does “knowledge of work” mean when an individual is part of the work, or not part of it all at? See discussion below on Situated Cognition). Finding ways to effectively “see” process and practice at work has been a key challenge for us. We have developed Brahms because we think it provides a step forward in visualizing, analyzing, and thinking about the mul