Part IVA: Business Process Redesign
Chapter 12: Inventing New Business Processes Using a Process Repository
Chapter 13: The Process Recombinator — A Tool for Generating New Business Process Ideas
Chapter 14: Designing Robust Business Processes
Part IVB: Knowledge Management
Chapter 15: A New Way to Manage Process Knowledge
Chapter 16: Toward a Systematic Repository of Knowledge about Managing Collaborative Design Conficts
Chapter 17: Genre Taxonomy — A Knowledge Repository of Communicative Actions
Part IVC: Software Design and Generation
Chapter 18: A Coordination Perspective on Software System Design
Chapter 19: The Product Workbench — An Environment for the Mass-Customization of Production Processes
Chapter 20: How Can Cooperative Work Tools Support Dynamic Group Processes? Bridging the Specifcity Frontier
So far we've seen the basic concepts upon which the Process Handbook is based and a variety of kinds of content in the Handbook. But what good is all this? What can you do with it? In this section we present a number of representative examples of how the concepts, tools, and knowledge base we have developed in the Process Handbook can be used.
The section is divided into three parts, corresponding to the three kinds of uses we have emphasized so far: business process redesign, knowledge management, and software design and generation.
chapter 12, by Klein, Herman, Lee, O'Donnell, and Malone, which describes a methodology for inventing new organizational ideas by first analyzing the ''deep structure''of the process in question, and then generating many possible alternative ''surface structures''for the same deep structure. The chapter shows how using the Process Handbook significantly enhances the power of this methodology. The chapter illustrates these concepts by showing how we used the Process Handbook and this methodology to generate new ideas for how to do hiring in a financial services firm. See Krushwitz and Roth 1999 for a detailed ''learning history''of this organizational redesign research project.)
Chapter 13, by Bernstein, Klein, and Malone, describes an automated tool called the ''Process Recombinator''that automates part of the methodology described in the previous chapter. The Process Recombinator uses the Process Handbook database to automatically generate new process ideas (new ''surface structures'') by recombining elements already present in the database. While we don't believe that such tools will completely replace human creativity anytime soon, this chapter suggests intriguing possibilities for how they can enhance it.
Chapter 14, by Klein and Dellarocas, describes a new methodology and an extensive body of Process Handbook knowledge about the kinds of exceptions (or ''process failures'') that can occur in business processes. The methodology provides a systematic way to analyze a process for potential failures and to fix or prevent them from occurring. The chapter applies the methodology in analyzing a real business process crisis involving the unauthorized foreign currency trades that led to the bankruptcy of Barings Bank.
The second part of this section focuses on applications that, while they involve some aspect of process redesign, place more emphasis on using the Process Handbook to manage knowledge. This part begins with a brief article, by Carr, about the Process Handbook project that appeared in Harvard Business Review. In it are summarized the goals of the project, and a brief description is provided of an early commercial use of the Process Handbook at Dow Corning Corporation.
Chapters 16 and 17 emphasize research—rather than commercial—applications of the Process Handbook for knowledge management. Chapter 16, by Klein, describes how the same concepts of exception management that were described in chapter 14 by Klein and Dellarocas can be applied to problems in large multi-person design projects such as those for airplanes and cars. The chapter shows how a growing repository of knowledge can be developed about possible problems to anticipate in such multi-person design projects and how to avoid these problems.
Chapter 17, by Yoshioka, Herman, Yates, and Orlikowski, describes how the researchers have used the Process Handbook concepts to categorize various communication ''genres''within organizations, and also the Process Handbook software tools for documenting and storing their results. This chapter thus illustrates, on a small scale, an important aspect of the vision with which we began this book: how the creation of very precise and explicit taxonomies of organizational actions can help advance organizational theory.
The third part focuses on using the Process Handbook concepts and tools to design and/or customize complex software systems using libraries of preexisting software components. Chapter 18, by Dellarocas, continues the theme of chapters 4 and 10 by Dellarocas, and describes the tools Dellarocas has developed for generating software programs. The chapter includes, for instance, a language for representing the ''deep structure''of a software architecture and a ''design assistant''for automating parts of the process of generating actual programs from such architectural descriptions.
Chapter 19, by Bernstein, proposes a prototype implementation of a flexible software environment for service organizations (e.g., banks) that is analogous to a CAD/CAM tool for manufacturing organizations. Such a system would allow users to easily reconfigure a flexible set of software building blocks for each different customer or situation. In a sense, then, such a system would allow for the ''mass customization''of previously rigid services.
This idea is extended in the next chapter. Chapter 20, also by Bernstein, describes a prototype implementation of a system that allows a great deal of flexibility in using many different kinds of software tools. Here, however, the emphasis is not on tools for providing services to external clients but on tools for supporting cooperative work among groups of people. Interestingly, this system allows users not only to change the way that different software components fit together but also to easily change the amount of support the system provides in the first place: from extensive automated support for highly formalized processes (e.g., an ERP system) to much more limited (but also more flexible) support for completely ad hoc processes (e.g., a simple e-mail system).