لطفا منتظر باشید ...
11.5 Conclusion
To conclude, we will briefly discuss the implications of our focus on dependencies for the design of analysis tools and the practice of managers and other process analysts.
11.5.1 Suggestions for Design of Tools
The approach presented in this chapter has strong implications for the design of process analysis tools. Many CASE (computer-assisted system engineering) tools can represent a decomposition hierarchy of activities. Some could handle the dependencies linking activities and resources. However, none that we know of explicitly represent the link between coordination mechanisms and the dependencies they manage. For example, to assist analysts building such representations, it would be handy to be able to drag an activity on to a dependency to indicate that the dependency is managed by that activity or to click on a dependency and pop up the list of alternative specializations.Since dependencies arise from shared use of resources, the representation of an activity could include an indication of the resources they need from which the system could automatically figure out some dependencies. For example, if two activities need a resource of which there is only one known instance, then the system might suggest resource-sharing mechanisms; if there is no known resource, it can suggest resource procurement mechanisms. If the resource is an actor, then a task assignment mechanism is needed. As an example, we are currently using these techniques to compile a Handbook of organizational processes at a variety of levels and in different domains (Malone 1994). Managers or consultants interested in redesigning a process could consult the handbook to identify likely alternatives and to investigate the advantages or disadvantages of each. Coordination theory makes the Handbook feasible by providing a framework for describing more precisely how processes are similar and where they differ.
11.5.2 Implications for Practitioners
Even though many people have documented and studied organizational processes, our approach to this problem is novel in important ways. Most important, in analyzing a given process, we identify the key activities that must be performed for the goal to be achieved, the resources created and consumed by these activities, and the dependencies between them. We define the managing of these dependencies as the coordination activities, and we postulate that there will be a set of generic coordination processes (and their various specializations) that will appear over and over in different processes.By identifying the various types of dependencies and the generic processes for managing them, we believe that we can create more concise process descriptions. A second benefit, however, is that this approach can help us generate new possibilities for processes. If we know that in general, there are several possible coordination processes for managing a given dependency, then we can automatically generate all of them as possibilities for managing that dependency in any new process we analyze. Some of these possibilities may be new or not obvious, and their generation requires no specific knowledge of the process other than the type of dependencies it involves.
The choice of coordination mechanisms to manage these dependencies results in a variety of possible organizational forms, some already known and some novel. The relative desirability of mechanisms is likely to be affected by the use of new information systems. For example, the use of a computer system may make it easier to find existing solutions to a problem, either in a database or from geographically distributed coworkers. Such a system could reduce both duplicate effort and coordination costs.
