<span>Chapter 20: </span> How Can Cooperative Work Tools Support Dynamic Group Processes? Bridging the Specificity Frontier - Organizing Business Knowledge [Electronic resources] : The MIT Process Handbook نسخه متنی

Chapter 20: How Can Cooperative Work Tools Support Dynamic Group Processes? Bridging the Specificity Frontier

Abraham Bernstein

An earlier version of this chapter appeared as A. Bernstein (2000), How can cooperative work tools support dynamic group processes? Bridging the specificity frontier. Proceedings of the Conference on Computer Supported Cooperative Work (CSCW'2000), Philadelphia, ACM Press. 2000 ACM. Reprinted by permission.

20.1 Introduction

Many researchers have commented on the increased pace of change in today's economy. Increasingly groups and organizations have to adapt their processes to rapid changes arising from new technologies, new customer demands, or new competitors. Current process-support systems (e.g., ERP, work flow–management systems), however, are usually focused on supporting fixed organizational processes. Typically they are too rigid to easily support changing processes. They are mainly used for highly specified and highly routinized organizational processes. As an alternative, many organizations use communications support systems or Groupware (like e-mail or Lotus Notes) to support their rapidly changing, nonroutine processes. But these systems typically require users to do a lot of work themselves to keep track of and understand the ongoing processes: what has been done, what needs to be done next, and so forth.

This dichotomy is paralleled by an old debate in the CSCW-literature about the nature of collaborative work (e.g., see Schank and Abelson 1977; Winograd and Flores 1986; Suchman 1987; Winograd 1994; Suchman 1994). Both sides in this ongoing debate present some deeply rooted beliefs about how human actors perceive the world and decide to act.

One side follows the belief that human actors typically follow the cycle of problem analysis, solution search or synthesis, and then the execution of that plan. The goal of a process-oriented collaboration support system in this perspective is to increase the speed and effciency of each step in the cycle as well as facilitate a seamless integration of the steps. Work flow–management systems (WfMS) and other process support systems like enterprise resource planning systems (ERP) are based on this research stream and have typically focused on the execution of standardized, predefined organizational process (e.g., Hammer et al. 1977; Zisman 1978; Mohan et al. 1995; Jablonski and Bussler 1996).

The other side sees plans as resources for action (Suchman 1987), which are used in conjunction with the environment to articulate and reason about the next action steps (Gasser 1986; Gerson and Star 1986; Suchman 1996). Following this perspective typical WfMSs are too restrictive as they traditionally prescribe the work flow and do not allow users to adapt the process to the local situation. Therefore researchers following this tradition have often advocated using flexible communication support systems (e.g., e-mail and discussion databases) or repositories (e.g., document management/imaging systems) to support organizational processes. Those systems, however, have the disadvantage that an actor typically is on his/her own in deciding what to do next.

To date, none of the approaches has offered a conclusive answer. I concur with others (e.g., Newell and Simon 1972; Keen and Scott Morton 1978; Rock, Ulrich, and Witt 1990) that organizational activities often include a mix of both procedure and ad hoc parts. The research presented in this chapter therefore argues in favor of bridging between both perspectives by developing systems that will support the whole range of dynamic organizational activity: from well-specified and routine (reacting to exceptions as they occur) to highly unspecified and situated.

In this chapter, I will first ground this novel idea in a practical scenario and social science theory. This will help explain the approach as well as facilitate the presentation of the proof of concept prototype system. I will conclude with a brief survey of related work and a discussion of the major lessons learned.