The fundamental insight underlying our methodology is that exceptions represent the
violation of commitments. The smooth operation of a manufacturing plant, for example, relies implicitly on the commitment that the machinery therein will work reliably. Supply chains rely on commitments, often formalized as contracts, between subcontractors and contractors. A given Web computing infrastructure relies on the commitment that the design was
appropriate to the demands that will be placed on it. One can therefore understand the possible exceptions and responses for a business process by enumerating:
The commitments underlying the success of the business process.
The ways these commitments can be violated (i.e., the exceptions).
The processes by which these exceptions can be anticipated and avoided, and detected and resolved (i.e., the exception handlers).
We call this process Role–Commitment–Violation analysis (Klein and Dellarocas 2000).
While this analysis can of course be done from scratch for each new business process, it would be helpful if the results of analyses for other processes could be archived so that designers can take advantage of them when performing new analyses on similar processes.
This can save a lot of time, and if the knowledge base is reasonably complete, designers are much more likely to get a full picture of the exceptions and possible handlers for their
particular process. We describe, in this chapter, both an exception analysis methodology that is suitable for from-scratch analysis, plus a scheme for capturing the results of previous analyses in a way that facilitates their reuse.
It would be a huge task, however, to try to identify in one knowledge base all the important commitments, exceptions, and handlers for the whole world of possible business processes.
The exceptions important in chemical manufacturing (e.g., chemical spills), for example, are largely orthogonal to those that occur in the insurance industry (e.g., claim fraud). There is one subset of exceptions, however, that is critical to business processes cutting across multiple domains: those concerning coordination among the tasks in a business process. No matter what kind of work one does, one is faced with the challenge of figuring out who should do what when with what resources in order to achieve private and shared goals in a context of mutual interdependence. We have found that there is a manageably small number of ways that coordination can occur; the same basic ideas (e.g., market mechanisms, just-in-time logistics) tend to get used again and again in a wide range of contexts. Many of the most diffcult to detect and resolve exceptions, moreover, take the form of coordination failures, especially failures cutting across organizational boundaries.
Coordination-related exceptions thus represent a constrained but important and widely applicable subset of the world of possible business process exceptions. The examples in this chapter will all be drawn from the realm of coordination exceptions.
Identifying Commitments To identify the commitments involved in a business process, one needs to identify, starting from the penultimate outputs of the process, who (or what)
generates those outputs, and what is required in order to do so. Each of these requirements represent commitments that must be honored. One repeats this analysis for the
requirements so identified, working backward through the business process, until all the commitments have been identified. There are many different kinds of commitments, ranging from commitments to preserve a given state (e.g., wherein a piece of machinery is operating correctly) to commitments to make some change in state (e.g., pay someone in a timely way for a service they have performed). Every resource flow in a process (which we model in the Handbook as dependencies) represents the commitment to get the right amount of the right
resource to the right consumer at the right time.
Let us consider a simple example in order to make this concrete. One process commonly used for allocating tasks is the sealed-bid auction. This works as follows: a contractor identifies a task that it cannot or chooses not to do and attempts to find a subcontractor to perform the task. It begins by creating a 'Request for bids'(RFB) that describes the desired work, and then sending it to potential subcontractors. Interested subcontractors respond with bids (specifying such issues as the price and time needed to perform the task) from which the contractor selects a winner. The winning agent, once notified of the award, performs the work (potentially subcontracting out its own subtasks as needed) and submits the results to the contractor (figure 14.1).
This process involves several commitments. The contractor, for example, is responsible for sending the correct RFB to the correct subcontractors in a timely way. The subcontractors, in turn, are responsible for sending accurate bids to the contractor before the deadline. The contractor should award the work fairly and notify the subcontractors in a timely way. The winning subcontractors should produce the desired results with the promised delivery time, cost, and quality. To achieve these commitments, the contractors and subcontractors will make use of other subprocesses. They may use email, fax machines, or the US postal service, for example, to handle the flow of messages between them. These mechanisms in turn will rely on commitments of their own. If we carry this procedure far enough, we can have a complete picture of the commitments involved in this business process.
Figure 14.1: The sealed-bid task allocation auction
Because the range of coordination processes is relatively constrained, it is possible to create a knowledge base of such processes that is fairly complete, and use this to speed the identification of coordination-related commitments in a given business process. The Handbook project has been creating just such a knowledge base (figure 14.2).
The knowledge base consists of generic coordination mechanisms arranged into a taxonomy. A business process designer inspects this taxonomy to find the generic
mechanism that most closely matches the part of their business process they are currently analyzing. The commitments that appear in that generic mechanism represent a checklist of commitments that almost certainly appear in the particular business process being analyzed.
Using this taxonomy a business process designer could quickly determine, for example, that their current process for allocating claims to insurance adjusters is an instance of a 'first- come–first-served'coordination mechanism. They can then look at the commitments in the generic mechanism's description to get a pretty good idea of what coordination commitments must be considered in their own business process.
Figure 14.2: Portion of the coordination mechanism taxonomy
Identifying Exceptions The next step is to identify the exceptions that can occur in a process with a given set of commitments. Each kind of commitment has its own
characteristic set of ways in which it can be violated. The commitment to maintain a certain response time in a Web server, for example, could be violated because the server broke down, because demand exceeded the limits the server was designed for, and so on.
If one had a complete model of how all of the components in a business process could possibly behave, then it imaginably would be possible to logically, even automatically, deduce all the ways that commitment violations (i.e., exceptions) can occur. As a practical matter, however, one generally derives an understanding of the possible exceptions by experience. As with commitment identification, business process designers could go through this exception identification from scratch for every new process, but this can be made more effcient and complete by maintaining the results of this analysis in a knowledge base. The Handbook includes just such a knowledge base, focused for the reasons noted above on coordination-related exceptions.
The schema is simple. Since coordination can be defined as the management of resource flows across dependencies (Malone and Crowston 1994), the different types of coordination commitments is just another name for the different types of dependencies. There are three main dependency types:
Flow. A resource flows from a producer to a consumer. Any process that involves transporting messages or physical items can be viewed as a flow.
Sharing. A resource is produced by a single producer and shared among multiple consumers. A lottery, for example, can be viewed as a way of sharing goods among consumers.
Fit. Resources from multiple producers are consolidated by a single consumer. The design of a complex artifact like an airplane, for example, includes as an important component the process of 'fitting'together the design for different subsystems into a functioning airplane.
Commitments, including these three main types of dependencies, can be arranged to form a taxonomy like the one maintained in the Handbook knowledge base (figure 14.3). Every commitment in that taxonomy is linked to the exception types to which it can be prone. There are three main classes of exceptions:
Infrastructure commitment violations. This category includes such problems as communications failures and machinery breakdowns.
Agent commitment violations. This category includes problems where participants in the business process do not discharge their commitments to each other, such as when a subcontractor is overdue with a task.
System commitment violations. The designer of a coordination mechanism has the commitment of defining one that works well given the demands that will be placed on it.
There are cases, however, where an apparently reasonable coordination mechanism can produce ''emergent''dysfunctional behavior even with perfectly reliable
infrastructures and participants. One example is ''resource poaching,''wherein a slew of low-priority but long-duration tasks tie up the subcontractors, thereby freezing out resources needed for the higher-priority tasks that arrive later (Chia et al. 1998). This does not represent an error per se but rather an unexpected consequence of a simple mechanism applied in a complex environment.
Figure 14.3: Portion of the commitment type taxonomy
Exceptions, like commitments, can be arranged into a taxonomy (figure 14.4). These interlinked taxonomies can be used as follows: for every commitment one identifies in a business process, one finds the closest match in the commitment taxonomy, and then follows the links to the associated exceptions. Imagine, for example, that one's business process includes an auction mechanism with the commitment that the auctioneer accurately announce the winner of each round. This is an instance of a ''information
contract''dependency (itself a type of ''flow'') that has such characteristic exceptions as ''false information.''The power of using the knowledge base in this way is that it may suggest exceptions that one might not have otherwise considered, for example, that the auctioneer may give false information about who won the last auction round.
Figure 14.4: Portion of the exception type taxonomy
Identifying Exception Handlers The final step of the exception analysis process is to identify possible exception handlers for each of the important exceptions identified in the business process being analyzed. There are four main classes of exception handling processes, divided into two pairs. If a exception has not yet occurred, we can use:
Exception anticipation processes. These uncover situations where a given class of exception is likely to occur. Resource poaching, for example, can be anticipated when there is a flood of long duration tasks requiring scarce, nonpreempting sub-contractors to perform them.
Exception avoidance processes. These reduce or eliminate the likelihood of a given class of exception. Resource poaching can be avoided, for example, by allowing subcontractors to preempt their current tasks in favor of higher-priority pending tasks.
If the exception has already occurred, we can use:
Exception detection processes. These detect when an exception has actually occurred.
Some exceptions, such as bidder collusion, are diffcult to anticipate but can be detected post hoc by looking at bid price patterns.
Exception resolution processes. These resolve an exception once it has happened. One resolution for bidder collusion, for example, is to penalize and/or kick out the colluding bidders and re-start the auction for the good in question.
Like exception types, there appears to be no simple way to systematically identify all the potentially useful exception handlers. Exception handling techniques have emerged throughout human history, and appear to be limited in scope only by the bounds of human creativity. One can argue that a very significant proportion of human institutional innovations, including the police, law courts, disaster relief agencies, and so on, can all be viewed as representing exception handling mechanisms.
The Handbook contains a growing collection of exception handling techniques linked to the (coordination-related) exceptions to which they are relevant (figure 14.5). These handlers are arranged into a taxonomy such that handlers with similar functions appear close to one another. So, when a designer is looking for an exception handler suitable for a particular exception type, he or she will find that a range of potentially suitable handlers will appear as specializations or siblings of the handlers directly linked to the exception of interest. Note that since handlers are themselves processes, they themselves can have exceptions that require exception handlers.
Figure 14.5: Subset of the exception handler taxonomy
Summary Our exception analysis methodology can be summarized as follows (figure 14.6).
A given process is analyzed to determine the commitments contained therein. These
commitments are then mapped to the ways that they can be violated (i.e., to exceptions) and from there to handlers potentially suitable for anticipating and avoiding, or detecting and resolving them. The MIT Process Handbook contains a growing knowledge base of generic processes, commitments, exceptions, and handlers relevant to the important realm of coordination-related processes. This knowledge base can be used to increase the speed and completeness of exception analysis in the coordination domain by archiving this information in a way that makes it applicable to a wide range of business processes.
Figure 14.6: Summary of the exception analysis methodology