Page 3useful in the problem of process redesign. Hammer andChampy (1992, p. 129) argue that teams engaged in aredesign effort often get bogged down with analyzing thestatus quo:One of the most frequently committed errors inreengineering is that ... reengineering teams try toanalyze a process in agonizing detail rather thanattempting to understand it. People are prone toanalyze because it is a familiar activity. We knowhow to do it. It also feels good, because analysisgives us the illusion of progress.While it may feel good, we believe it is pointless to spend alot of energy mapping out how a particular activity isaccomplished if you have not yet decided whether thatactivity should be outsourced, combined with anotheractivity, or perhaps eliminated altogether. What is needed,instead, is a technique that allows the analyst to develop anunderstanding of the critical activities in the process andtheir interdependencies. In particular, the method shouldreveal important dependencies between steps and suggestways that these dependencies can be better coordinated.We believe this type of description will be most useful forthe design of systems to support work processes.To implement this approach, Malone et al. (1999) aredeveloping a "handbook" of organizational processes thatencodes descriptions of a wide variety of businessprocesses, including order entry and fulfillment, productdevelopment, sales and marketing, and so on. Thishandbook is intended to support the improved design of processes and the systems that support them. Therepresentation used in the handbook combines three basicconcepts in a novel way to create a taxonomy of processes:
Processes are decomposed intoactivities, which may in turn be further decomposed intosubactivities. Decomposition allows the nesting of processes within processes, and allows the handbook toshare and re-use process descriptions throughout thetaxonomy.
Processes (and activities) are alsospecialized in a manner similar to a traditional typehierarchy. Unlike a simple object hierarchy, each node isitself a complex entity that inherits a decomposition fromits parents.
Malone and Crowston (1991; 1994)define coordination as "managing dependencies." TheHandbook represents dependencies between activities inorder to suggest ways in which these dependencies can bebetter managed through the use of information systems.Dependencies are also inherited through the specializationhierarchy.This representational scheme has a number of propertiesthat we believe are especially useful in the design of newprocesses and systems to support them. First, therepresentation is generative. For example, it generates newprocesses through the creation of specializations whichinherit from multiple sources in the hierarchy. Second, itexplicitly represents dependencies between activities,which are an important class of constraints on theconfiguration of a process (Pentland, 1995). Everydependency creates a need for coordination, and at thesame time, creates an opportunity for choosing amongalternative coordination mechanisms. For example, ashared resource dependency can be managed by a variety of different coordination mechanisms, including bidding,rationing, first come, first served, etc. If so desired, thesecoordination mechanisms might be embodied in CSCWapplications. Finally, it represents processes in terms thatare meaningful to participants. Too often, systems analysisand CSCW formalisms have strayed from simple,descriptive terminology that people doing the work canunderstand.To be most useful, the Handbook must be populated with asubstantial number of process descriptions. Thesedescriptions must be collected in a way that allowsconsistent comparisons of processes in a wide variety of organizational contexts. Thus, the Process Handbook imposes a number of requirements for data collection thatcan be described as follows:
(1) Common vocabulary.
Descriptions must be consistentwith respect to a given vocabulary, but the problem is thatthe vocabulary is never a given. In general, it will reflectthe terminology that organizational members andparticipants use to describe their work. The research teammust then be able to abstract from these native descriptionsto create a generic description that can be codified in theHandbook.
As we confront new situations, we willinevitably come across new kinds of activities that arequalitatively different from those in the existingvocabulary. To accommodate these activities, newcategories of activities must be created, with the result thatthe vocabulary will grow. As it does so, it is critical thatthe proliferation of terminology not obscure underlyingsimilarities between steps in processes that take place indifferent contexts.
(3) Appropriate level of abstraction and granularity
Itis important to locate levels of abstraction and granularityat which meaningful and useful descriptions can beformulated. In principle, one could attempt to translateprocesses into primitive elements at an extremely fine-grained level. However, attempts to codify an appropriateset of primitives have not fared especially well. For