List of Figures - Organizing Business Knowledge The Mit Process Handbook [Electronic resources] نسخه متنی

List of Figures

Chapter 1: Tools for Inventing Organizations — Toward a Handbook of Organizational Processes

Figure 1.1: Sample representations of three different sales processes. 'Sell by mail order' and 'Sell by retail store', are specializations of the generic sales process 'Sell something'. Subactivities that are changes are shadowed.

Figure 1.2: The 'Process compass'illustrates two dimensions for analyzing business processes. The vertical dimension distinguishes different parts of a process; the horizontal dimension distinguishes different types of a process.

Figure 1.3: Summary display showing specializations of the activity 'Sell something'. Items in brackets (e.g., '[Sell how?]') are ''bundles''that group together sets of related specializations. Items in bold have further specializations. (Note: The screen images used in this and subsequent figures were created with the software tools described below.)

Figure 1.4: A trade-off matrix showing typical advantages and disadvantages of different specializations for the generic sales process. (Note that the values in this version of the matrix are not intended to be definitive, merely suggestive.)

Figure 1.5: Three basic types of dependencies among activities (adapted from Zlotkin 1995)

Figure 1.6: Alternative views of the same sample process. The first view (a) shows a ''flow''dependency between two activities. The second view (b) shows the flow dependency replaced by the coordination process that manages it. The third view (c) shows the subactivities of the coordination process and the respective dependencies among them. Users can easily switch back and forth among these different views of the same process.

Figure 1.7: An outline view of the first two levels of the specialization hierarchy and selected further specializations of the generic activity 'Move'

Chapter 3: A Taxonomy of Organizational Dependencies and Coordination Mechanisms

Figure 3.1: Tasks use or produce resources

Figure 3.2: Dependencies between multiple tasks and resources.

Chapter 4: Toward a Design Handbook for Integrating Software Components

Figure 4.1: Representing a software application as a set of activities interconnected through dependencies

Figure 4.2: A simple software system

Figure 4.3: One protocol for managing the data .ow dependency of figure 4.2.

Figure 4.4: An alternative protocol for managing the dataflow dependency of figure 4.2.

Figure 4.5: A hierarchy of increasing specialized coordination protocols for managing prerequisite dependencies

Chapter 5: Defining Specialization for Process Models

Figure 5.1: Which diagram is the specialization?

Figure 5.2: State diagram as a class of possible event sequences

Figure 5.3: State diagram for full service restaurant

Figure 5.4: Additional restaurant state diagrams

Figure 5.5: Generalized restaurant transaction

Figure 5.6: Initial specialization hierarchy for restaurant information system

Figure 5.7: Full service restaurant with buffet

Figure 5.8: Example of a dataflow diagram: Order processing

Figure 5.9: Taxonomy of order processes

Figure 5.10: Order processing abstracted from books to products

Figure 5.11: Order processing with pre-payment

Figure 5.12: Order processing without shipment

Figure 5.13: Order processing without order

Chapter 6: Process as Theory in Information Systems Research

Figure 6.1: Relationship between ICT-induced changes in individual work and changes in organizational and industrial structures and outcomes

Figure 6.2: Restaurant service process. Actors are shown down the left side, activities performed by each are shown in order across the page. Activities performed jointly are connected with dotted lines.

Figure 6.3: Flow of resources between activities and resulting dependencies in the restaurant service process

Chapter 8: What Is in the Process Handbook?

Figure 8.1: Screen image of a sample entry in the Process Handbook

Figure 8.2: Excerpt of the ''related processes''shown for 'Sell': Other ways 'Sell'can be done

Figure 8.3: Sample trade-off matrix for the 'Advertise how?'bundle

Figure 8.4: Specializations of 'Sell'shown with the compass explorer user interface

Figure 8.5: The top level of produce as a business in the MIT business activity model

Figure 8.6: The subparts of 'Buy'and 'Sell'in the MIT business activity model have an intuitive correspondence with each other

Figure 8.7: One of the simplest possible views of the activities in a business

Figure 8.8: 'Buy'and 'Sell'activities are needed to manage the input flows and the output flows, respectively

Figure 8.9: 'Design'activity is needed to manage the fit dependency between the different activities that collectively produce the product a customer buys.

Figure 8.10: 'Manage'activity is needed to manage the sharing dependencies among all the other activities.

Figure 8.11: MIT Business Models Archetypes (from Herman, Malone, and Weill 2003). ''Asset''can be physical, informational, or financial. ''None''means broker never takes ownership of what is sold.

Figure 8.12: Sample case example describing the way Amazon.com distributes books via the Internet

Figure 8.13: Generalizations of 'Sell'(shown in the compass explorer view). The ''Ancestors''part of the figure shows the direct and indirect generalizations of 'Sell'. The ''Family tree''part of the figure also shows some of the other relatives of 'Sell'in the specialization hierarchy.

Figure 8.14: First-level specializations of 'Act'(shown in the compass explorer view). The next two levels of specialization under 'Create'are also shown here.

Figure 8.15:

Figure 8.16: Simplified map of the entire network of activities in the Process Handbook

Figure 8.17: Sample dependency diagram showing two .ow dependencies connecting three activities in an example of a process to manufacture a product. (This .gure is from the ''research'' version of the Process Handbook.)

Figure 8.18: Systems dynamics diagram. (This .gure is from the ''research'' version of the Process Handbook.)

Chapter 9: Let a Thousand Gardeners Prune — Cultivating Distributed Design in Complex Organizations

Figure 9.1: Steps in process innovation as described in Davenport (1993)

Figure 9.2: Resource flow diagram for process innovation

Figure 9.3: Simplification of process innovation

Figure 9.4: Design using solution strategies

Figure 9.5: Transforming a resource flow graph into a dependency diagram

Figure 9.6: First attempt at a dependency diagram

Figure 9.7: Symmetric dependency diagram

Figure 9.8: Identify activities and resources

Figure 9.9: Preliminary resource flow graph

Figure 9.10: Simplifying the resource flow graph

Figure 9.11: Simplification of reengineered business processes

Figure 9.12: First pass at a dependency diagram

Figure 9.13: Simplified dependency diagram

Figure 9.14: Design using classification

Figure 9.15: Design of high-risk systems

Chapter 10: A Coordination Perspective on Software Architecture — Toward a Design Handbook for Integrating Software Components

Figure 10.1: Example of cooperative resource use

Figure 10.2: Simple design space for selecting a data transportation mechanism

Figure 10.3: Taxonomy of resources

Figure 10.4: Generic model of resource .ow dependencies

Figure 10.5: Framework for managing usability dependencies

Figure 10.6: Framework for managing accessibility dependencies

Figure 10.7: Prerequisite dependency

Figure 10.8: Perishable prerequisites

Figure 10.9: Specialization relationships among different prerequisite dependency types

Figure 10.10: Generic processes for managing prerequisite dependencies

Figure 10.11: Generic processes for managing prerequisite dependencies using peer event synchronization

Figure 10.12: Taxonomy and examples of event types

Figure 10.13: Framework for managing prerequisite dependencies

Figure 10.14: Framework for managing sharing dependencies

Figure 10.15: Sharing of divisible resources in a .ow dependency

Figure 10.16: Sharing by restricting access to resource

Figure 10.17: First two levels of design dimensions for flow dependencies

Figure 10.18: Specialization relationships among timing dependencies

Figure 10.19: Relationships between prevention and perishable prerequisite dependencies

Figure 10.20: A simultaneity dependency can be transformed and managed as a composite prerequisite. Before activities X and Y can begin execution, all four prerequisite activites must occur. Then both X and Y can occur together.

Figure 10.21: Termination of the user-interface also requires termination of the database and graphics servers

Chapter 11: A Coordination Theory Approach to Process Description and Redesign

Figure 11.1: Basic work flow at MAG Services

Figure 11.2: High-level process decomposition view

Figure 11.3: Specializations illustrate process variety

Figure 11.4: MAG Services as a step in a value chain

Figure 11.5: Coordinating subdependencies within the 'Run job' process

Figure 11.6: Chapter flow and resources at MAG Services

Chapter 12: Inventing New Business Processes Using a Process Repository

Figure 12.1: Surface structures of two different business processes with the same deep structure. (Activities shown in unshadowed boxes are part of the coordination processes for managing the .ow dependency.)

Figure 12.2: Sample representations of three different sales processes. The deep structure of selling is represented by 'Sell product', and two alternative surface structures are represented by its specializations:'Sell by mail order' and 'Sell in retails store'. Subactivities that are changed in the specializations are shadowed.

Figure 12.3: ''Process compass''illustrating two dimensions for analyzing business processes. The vertical dimension distinguishes different parts of a process; the horizontal dimension distinguishes different types of a process.

Figure 12.4: Basic types of dependencies among activities

Figure 12.5: Deep structure for 'Hire'. The arrows represent the flow dependency among the components.

Figure 12.6: Subactivity recombinator user interface

Figure 12.7: Specialization tree generalizations for hiring process

Figure 12.8: Two alternative surface structures for the senior employee hire process

Figure 12.9: Trade-off table for 'Hire'process alternatives

Chapter 13: The Process Recombinator — A Tool for Generating New Business Process Ideas

Figure 13.1: Example of inheritance in specialization hierarchy (changed subactivities are shadowed)

Figure 13.2: Example of bundles in the specialization hierarchy

Figure 13.3: Example of a trade-off table (note that these particular values are for illustrative purposes only)

Figure 13.4: Three basic types of dependencies among activities

Figure 13.5: The deep structure for 'Hire'

Figure 13.6: Subactivity recombinator user interface

Figure 13.7: Results of using the subactivity recombinator

Figure 13.8: Dependency recombinator user interface

Figure 13.9: Specialization sub-tree for 'Install employee'

Figure 13.10: Part of the design space for the 'Install employee'process (the cell marked is the example described in the text)

Figure 13.11: Bundle recombinator user interface

Figure 13.12: Trade-off matrix for new process re-designs. (All values are for illustration purposes only.)

Chapter 14: Designing Robust Business Processes

Figure 14.1: The sealed-bid task allocation auction

Figure 14.2: Portion of the coordination mechanism taxonomy

Figure 14.3: Portion of the commitment type taxonomy

Figure 14.4: Portion of the exception type taxonomy

Figure 14.5: Subset of the exception handler taxonomy

Figure 14.6: Summary of the exception analysis methodology

Figure 14.7: Barings futures trading process

Figure 14.8: Barings futures trading process with associated exceptions

Figure 14.9: Logging is a generic process for detecting prerequisite violations

Figure 14.10: Barings process properly instrumented with logging processes

Figure 14.11: Comparison between the ideal and the actual barings process

Chapter 15: A New Way to Manage Process Knowledge

Figure 15.1: Process parts

Figure 15.2: Process types

Figure 15.3: Dow Corning's process repository. Dow Corning is putting its process repository on its corporate Intranet. Here, in a sample window, we see a portion of Dow's requisition procedure. Employees can click on any process step for more detailed information on policies and practices. The ''process compass'' in the upper left corner makes navigating the repository easy.

Chapter 16: Toward a Systematic Repository of Knowledge about Managing Collaborative Design Conflicts

Figure 16.1: Decomposition for the change memo process

Figure 16.2: Dependencies for the change memo process

Figure 16.3: Fragment of the process taxonomy for conflict detection

Figure 16.4: Fragment of the conflicts type taxonomy

Figure 16.5: Fragment of the collaborative design process hierarchy

Figure 16.6: Linkages to/from the conflict taxonomy

Figure 16.7: Subset of the conflict handling process taxonomy

Figure 16.8: Decomposition of the generic conflict management meta-process

Figure 16.9: Subset of the conflict management meta-process taxonomy

Figure 16.10: Screen snapshot of the Web-accessible version of the conflict repository

Figure 16.11: Snapshot of the process recombinator

Chapter 17: Genre Taxonomy — A Knowledge Repository of Communicative Actions

Figure 17.1: Example of correspondences in the ballot genre system in the common lisp project (excerpt)

Figure 17.2: Genre evolution example from business letter genre to electronic memo genre

Figure 17.3: Flow, fit, and sharing dependencies

Figure 17.4: Process inheritance and specializations of the activity 'Sell product'

Figure 17.5: Excerpt of process categories in the genre taxonomy

Figure 17.6: Description of the activity 'Communicate using face-to-face meeting system'

Figure 17.7: Dependency diagram of 'Genre use over time'

Figure 17.8: Specialization hierarchy example in the genre taxonomy

Figure 17.9: Genre coordinating aspects example: An excerpt of the specialization hierarchy of 'Coordinate information using genres'

Chapter 18: A Coordination Perspective on Software System Design

Figure 18.1: Implementation languages often force the distribution of coordination protocols among several code modules. In this example the implementation code of a pipe protocol for managing a single data flow dependency has been distributed among three code modules.

Figure 18.2: Representation of a simple file viewer application using SYNOPSIS

Figure 18.3: Example of an atomic activity and its associated code-level component description

Figure 18.4: SYNOPSIS representation of a data flow dependency and its associated pipe transfer coordination protocol

Figure 18.5: Hierarchy of prerequisite dependencies with increasingly specialized associated coordination protocols

Figure 18.6: Sketch of an algorithm used by SYNTHESIS to generate executable applications by successive specializations of their SYNOPSIS descriptions

Figure 18.7: Configuration of SYNTHESIS windows during design mode

Chapter 19: The Product Workbench — An Environment for the Mass-Customization of Production Processes

Figure 19.1: Specialization hierarchy for 'Sell .nancial service' (based on BankBoston 1998)

Figure 19.2: Trade-off matrix showing the alternative specializations of 'Sell credit service'compared to 'Loan purpose'and 'Loan security'

Figure 19.3: Template/case-browser

Figure 19.4: Incremental and iterative refinement of the process 'Sell combined product to Example Inc.'

Figure 19.5: Integrity checker pointing out problems in the decomposition browser by coloring the processes 'Analyze debit service'and 'Execute contract'in a darker color. 'Sell savings and investment services'and 'Sell combined product to Example Inc.'are also colored dark because they contain nonenactable subprocesses.

Figure 19.6: Overall product workbench architecture

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

Figure 20.1: Specificity frontier

Figure 20.2: Different execution types

Figure 20.3: Activity manager

Figure 20.4: Adding constraints

Figure 20.5: Planner

Figure 20.6: Starting a WfMS-like script

Figure 20.7: Process model parts

Figure 20.8: Example process

Figure 20.9: Related work

Appendix: Enabling Technology

Figure A.1: PIF class hierarchy

Figure A.2: Relationships among PIF classes

Figure A.3: Possible temporal relations between two activities

Figure A.4: Mapping between IDEF-0 and PIF constructs