11.4 Discussion
To put our contribution into perspective, we will conclude by briefly comparing our work to other process analysis techniques and evaluating our technique.
11.4.1 Comparison to Other Process Analysis Techniques
Process design and coordination problems have been approached from diverse perspectives, including economics, organization theory, computer science, ecology, and general management theory. We will briefly review alternative approaches (some of this material is adapted from Malone et al. 1993).Perhaps the simplest form of a process description is a concise verbal account. Such accounts are commonly used and have the advantage that little or no special training is needed to produce or understand them. However, there are two key problems: first, it is diffcult to check a verbal description for completeness or consistency; second, verbal descriptions do not easily suggest the space of possible improvements. Therefore most analysts use a more formal representation, as do we. It is interesting to note that soft systems methodology uses ''all the verbs in the English language''(Checkland 1981, p. 164) for building conceptual models, but the goal of these models is to ''generate radical thought''(p. 170) and deliberately not to be descriptions of the actual system.
A PERT chart provides a detailed representation of a process, specifying the exact activities taken, when they begin and end, sequence dependencies between activities, and even which actors or resources are involved with which activities. PERT charts have one major drawback for the purpose of process improvement: they usually are used to present or plan a single execution of a process and do not represent the range of possible alternatives. However, our representation captures many of these details, such as dependencies between activities and the use of resources.Managers and analysts interested in improving processes often use some version of a flowchart to represent process characteristics. Flowcharts drop some information of a PERT chart but still indicate the activities to be performed, the order in which they are performed, and may include information on who does each activity or how long an activity takes to perform. However, they are not especially good at suggesting alternative activities that accomplish the same ends, at demonstrating feasible alternative activity sequencing, or at projecting what changes might be required if different actors performed selected activities.Our representation is most similar to a dataflow diagram, which represents the steps of a process but focuses on the ordering relationships imposed by the fact that data produced by some steps must be used by others (e.g., Yourdon 1989). Many dataflow techniques, such as IDEF0 and SADT, include decomposition as a key aspect. These representations are similar except they do not represent the full range of dependencies nor explicitly note the coordination mechanisms.To represent processes involving multiple actors, we may want to focus on the interactions among the actors. One approach to modeling interacting processes is suggested by Petri nets (Peterson 1977) and various representations derived from them (e.g., Holt 1988; Singh 1992). A Petri net is similar to a finite state machine but allows multiple states to be ''marked''simultaneously. Transitions between states may be synchronized, since multiple states may have to be marked at the same time for a particular transition to occur. To the extent that the activities we model have multiple inputs, then our representation can be seen as equivalent to simple Petri nets, although we do not take advantage of that fact.A second approach to representing multiple actors is to represent the process followed by each individual separately, using any of the techniques described above and explicitly modeling the exchange of information or objects between them. For example, the modeling technique developed by Crowston (1991) represents individual actors as programs written in logic. These actors can perform a variety of actions to achieve their goals, including speech actions to change the states of other actors. We believe that such representations could be used as a basis for simulating processes, thus providing a more detailed approach to examining trade-offs.
11.4.2 Evaluation
While the technique proposed in this chapter embodies a theory, it does not provide a way to test the theory. Indeed, Checkland (1981) argues that methodologies cannot be proved to work (or not to work) in the scientific sense (p. 241). Instead, the evaluation of the technique rests on how well it accomplishes the two goals we set out in the introduction: generativity and ease of use. The technique is a success if analysts can use it and if they find it provides insights into the process and how to change it. These two tests might partially trade off against each other: for example, if the technique provides unique insights, then analysts might be willing to undergo more of a learning process.As a further test of our technique, one of the authors taught coordination theory and versions of the methodology to four courses and two project teams over three years, totaling approximately 70 master's level students. Learning and applying our methodology occupied six to eight weeks of each course. Approximately half of the students were managers employed in a variety of industries and enrolled in a part-time MBA program. Students were required to redesign a process based on their analysis and to develop an information systems prototype that would support that redesign. Over all, they completed more than 40 process design projects, based on observations and analyses at large and small companies. The result was fairly consistent process innovation that exceeded the expectations of project participants. Our teaching experiences underline the paradigm shift need to think about organizational processes. It has been diffcult for participants to make the transition from focusing on inputs (e.g., strategies and resources) and outputs (e.g., organizational results) to focusing on the processes that derive those outputs. Likewise dependency analysis has been the most confusing aspect of methodology, hence our focus on it in this chapter.