A SYSTEMATIC REPOSITORY OF KNOWLEDGE ABOUT HANDLING EXCEPTIONS IN BUSINESS PROCESSES1 MARK KLEIN Center for Coordination Science Massachusetts Institute of Technology E40-169 Cambridge MA 02139
[email protected] CHRYSANTHOS DELLAROCAS Sloan School of Management Massachusetts Institute of Technology E53-315
[email protected] A critical challenge to creating effective business processes is allowing them to operate effectively in environments where failures (‘exceptions’) can occur. An important barrier to achieving this has been the lack of systematized dissemination of exception handling techniques. This paper describes the MIT Exception Repository, a semi-formal Web-accessible repository, built as an augmentation of the MIT Process Handbook, that is designed to address this challenge directly by enabling learning about, adding to, and exploiting business process exception handling expertise. Keywords: business process failures exceptions
The Challenge A critical challenge for business process designers is their ability to create processes that can respond effectively when "exceptions" occur (Strong 1992); (Suchman 1983); (Grudin 1994); (Mi and Scacchi 1991); (Karbe and Ramsberger 1990) (Kreifelts and Woetzel 1987) (Chiu, Karlapalem et al. 1997). This is true for both for intra- and (perhaps especially) inter- organizational processes. We can consider an exception to be any departure from a process that achieves the process goals completely and with maximum efficiency. Exceptions can thus include infrastructural failures, participants reneging on commitments, as well as emergent dysfunctions such as resource use conflicts. A key barrier to the development and utilization of improved exception handling in business processes has been a lack of systematized dissemination of expertise in this area. Business process exception handling is fundamentally a multi-disciplinary topic with relevant research efforts and results scattered across disparate communities including management science, operations research, economics, manufacturing control, computer science and so on. The result is that good ideas developed within one discipline do not readily propagate to researchers and practitioners in other settings, and opportunities are lost to carry on a more systematic and cumulative exploration of potentially useful exception handling techniques.
1
Under review at the International Journal of Innovation Management.
The work described in this paper addresses these challenges directly by creating a semiformal Web-accessible repository of exception handling expertise known as the MIT Exception Repository, that is organized to facilitate key uses including: • • •
Pedagogy: helping students, researchers and practitioners learn about the state of the art in exception handling management Development: helping practitioners define more robust business processes Research: helping researchers identify gaps in exception management techniques, identify common abstractions, facilitate discussion, and foster development of new ideas
The remainder of this paper will describe the key ideas and tools making up the MIT Exception Repository, evaluate its efficacy with respect to the goals listed above, and describe potential directions for future work. Our Approach Our approach is to capture exception handling knowledge using a substantively extended version of the tools and techniques developed as part of the MIT Process Handbook project. The Handbook is a process knowledge repository which has been under development at the Center for Coordination Science (CCS) for the past six years (Malone and Crowston 1994) (Malone, Crowston et al. 1998). The growing Handbook database currently includes over 5000 process descriptions ranging from specific (e.g. for a university purchasing department) to generic (e.g. for resource allocation and multi-criteria decision making). The CCS has developed a Windows-based tool for editing the Handbook repository contents, as well as a Web-based tool for read-only access. The Handbook is under active use and development by a highly distributed group of more than 40 scientists, teachers, students and sponsors for such diverse purposes as adding new process descriptions, teaching classes, and business process re-design. In the following sections we will present the core concepts underlying the Handbook, describe how these concepts and associated tools were extended to capture exception handling expertise, and discuss how this enables pedagogy, research, and development. Underlying process handbook concepts
The Handbook takes advantage of four simple but powerful concepts to capture and organize process knowledge: attributes, decomposition, dependencies, and specialization. Process Attributes: Like most process modeling techniques, the Handbook allows processes to be annotated with attributes that capture such information as a textual description, typical performance values (e.g. how long a process takes to execute), as well as applicability conditions (i.e. constraints on the contexts where the process can be used).
Decomposition: Also like most process modeling techniques, the Handbook uses the notion of decomposition: a process is modeled as a collection of activities that can in turn be broken down (“decomposed”) into subactivities that themselves, potentially, are processes. Dependencies: Another key concept we use is that coordination can be viewed as the management of dependencies representing resource (control, data, material …) flows between activities (Malone and Crowston 1994). There are three primitive types of dependencies: “flow” dependencies which represent one-to-one resource flows (e.g. transferring money between accounts), “sharing” dependencies which represent one-tomany resource flows (e.g. allocating investment money to stocks) , and “fit” dependencies which represent many-to-one resource flows (e.g. fitting together the designs for multiple subsystems of a given system). Every dependency is “managed” by an associated coordination mechanism, which is simply the process that controls the resource flow and thereby coordinates the activities connected by the dependency. Different kinds of dependencies have different potentially appropriate coordination mechanisms, e.g.: Dependency Type Flow Fit Sharing
Possible Coordination Mechanisms Make to order (just-in-time) Make to forecast and stockpile Pre-defined subsystem design interfaces Post-hoc design conflict resolution First-come, first-served Market-like bidding
The key advantage of this conceptualization is that it allows us to distinguish the domainspecific activities of a process from the generic coordination functions, thereby enabling cross-domain sharing of coordination mechanism ideas. Specialization: The final key concept is that processes can be arranged into a taxonomy, with very generic processes at one extreme and increasingly specialized processes at the other. Processes are organized based on their function, so that processes with similar purposes appear close to each other. This facilitates finding and comparing alternative ways for performing functions of interest, thereby fostering easy transfer of ideas. Sibling processes can be grouped into “bundles” with tradeoff tables that capture the relative pros and cons of these alternatives. Extending the Handbook to capture exception knowledge
While the Handbook as described above is well-suited for describing business processes, it does not capture information concerning exceptions in these processes, i.e. what types of exceptions can occur, in which contexts (i.e. kinds of business processes) they can
appear, what impact they may have, or what processes are suitable for handling them. The novel contribution of the MIT Exception Repository involved extending the Handbook to capture this exception-related information. Before we describe these extensions, however, it is important to make a key point concerning the scope of this work. It would be a huge and perhaps impossible task to identify the exception expertise relevant to all or even most important business processes. The exceptions that can occur in the chemical processing industry (e.g. chemical spills), for example, are multitudinous and rapidly changing and largely orthogonal to those that occur in the insurance industry (e.g. claimant fraud). There is one subset of exception expertise, however, that is critical to business processes cutting across multiple domains: that concerning coordination. Coordination can be defined as the management of inter-dependent activities (Malone and Crowston 1994). No matter what kind of work one does, one is faced with the challenge of figuring out who should do what with what resources in order to achieve private and shared goals in a context of mutual inter-dependence. Many of humankinds’ most powerful innovations, including modern bureaucratic states, market economies, democracy, modern logistics and even the Internet represent, fundamentally, highly generic mechanisms for coordinating the activities of interdependent agents. Expertise concerning the management of the exception modes for these coordination mechanisms thus potentially have equivalent breadth and import. Our development of a repository of exception handling expertise therefore focuses on the subset of exceptions concerned with coordination. The Exception Taxonomy: The key innovation required to create the MIT Exception Repository is the idea of the exception taxonomy (Klein and Dellarocas 2000) (Klein 2000). The exception taxonomy is a specialization hierarchy of exception types, ranging from highly general exceptions on the left to more specific ones on the right (Figure 1):
Figure 1. A fragment of the exception type taxonomy. As the taxonomy shows, there are in general three main classes of coordination exceptions, all of which can be framed as violations of some (implicit or explicit) commitment between different participants in a coordination mechanism: •
Infrastructure Commitment Violations: Every coordination mechanism relies on the commitment of the infrastructure to provide such services as reliable communication, reliable hosts for the software agents involved in the process, and so on. In large distributed systems, however, unpredictable node and link failures may cause agents to die unexpectedly, messages to be delayed, garbled or lost, etc.
•
Agent Commitment Violations. Agents have a commitment to adhere properly to their roles and contracts in the coordination mechanism. In open contexts, however, agents can not always be trusted to so do, especially when, as in electronic commerce for example, there may be significant incentives for fraud. A non-compliant subcontractor could, for example, wreak havoc through fraudulent advertising, bidding or subcontracting. Imagine, for example, an agent that falsely advertises a comprehensive set of capabilities, sends in highly attractive but fraudulent bids for all pending tasks, and once it wins the awards does not perform as offered. The result would be that many if not all of the bids would be awarded to a non-performing agent.
•
System Commitment Violations. The definer/manager of a coordination mechanism has the commitment of providing a context wherein participants can get work done efficiently. There are cases, however, where an apparently straightforward coordination mechanism can produce dysfunctional behavior even with perfectly reliable infrastructures and fully agents. 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, Neiman 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.
We have developed a systematic technique, which we call Role Commitment Violation analysis, for identifying all the characteristic exceptions for a given coordination mechanism (Klein and Dellarocas 2000). Different coordination mechanisms, of course, have different characteristic exception types. Sealed-bid auctions, for example, are vulnerable to auctioneer fraud in a way that open-bid auctions are not. The MIT Exception Repository captures these relationships by building on the Process Handbook’s growing taxonomy of coordination mechanisms (Figure 2):
Figure 2. A fragment of the coordination mechanism taxonomy. Every coordination mechanism in the Repository is linked to the exception types that characterize it; a mechanisms’ exceptions are inherited by its specializations unless explicitly over-ridden. Every exception is annotated with its typical impact on the associated coordination mechanism. Auctioneer fraud, for example, typically results in increased buyer costs in sealed-bid second-price auctions (when the auctioneer inserts a bogus second bid that is just below to the winning bid). Exception types are linked, in turn, to the exception handling processes suitable for handling them; these processes are themselves arranged into a taxonomy, producing the following overall structure (Figure 3): coordination mechanisms
exception types has exception
is handled by
exception handling processes
Figure 3. Linkages to/from the exception type taxonomy The exception handing process taxonomy (see Figure 4) is where the bulk of the repository content resides:
Figure 4. A subset of the exception handling process taxonomy. 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, which 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, non-preempting subcontractors to perform them.
•
Exception avoidance processes, which 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, which detect when an exception has actually occurred. Some exceptions, such as bidder collusion for example, are difficult to anticipate but can be detected post-hoc by looking at bid price patterns.
•
Exception resolution processes, which 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.
Unlike exception types, there appears to be no 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. This suggests the wide range of sources that are available for uncovering exception handling expertise for inclusion in the Exception Repository. Using the MIT Exception Repository
As noted above, we have identified three important potential uses for the exception repository: pedagogy, robust business process design, and research:. We explore the utility of the repositoru for these uses in the paragraphs below. Pedagogy: We have developed a Web-accessible read-only version of the Repository suitable for pedagogical use as an extension of the MIT Process Handbook. This tool allows one to view, in outline form, any of the taxonomies (of coordination mechanisms, exception types, and exception handlers) in the Repository. One can also bring up a detailed description for any individual process or exception, with hotlinks that allow one to traverse to all related entities (e.g. from exceptions to the handlers for that exception) (Figure 5):
Figure 5: Screen snapshot of the Web-accessibl e version o f the exception repository. Robust Business Process Design: The MIT Exception Repository supports a simple but powerful methodology for (re-) designing the exception management procedures used in one’s business process (Klein and Dellarocas 2000).The essence of the idea is as follows: 1. A business process designer identifies the important dependencies and associated coordination mechanisms in an ‘ideal’ (exception-free) model of their process. 2. The designer then consults the Exception Repository to find the exceptions that are characteristic of these coordination mechanisms, and 3. selects the appropriate handlers to handle them, mindful of the benefits of handling that exception as compared to the cost of each candidate handler. We will illustrate this process in the context of a well-known case of a failed business process: the Barings Bank failure.
In February 1994, 233-year old Barings Bank, one of the oldest and most respected investment houses in the United Kingdom, went bankrupt (Fay 1997) (Zhang 1995). The entire bank collapsed because of losses of $1.4 billion incurred in a matter of days by a single young trader, Nicholas Leeson. Nicholas Leeson was a futures trader in the Singapore branch of the bank. For a number of reasons, which are still not entirely clear, Leeson began to engage in unauthorized futures trading in the Singapore exchange. Due to inadequate internal controls and other process failures, Leeson was able to maintain his unauthorized and highly risky activity undetected by the bank headquarters in London until the very end. As we shall see, the exception analysis methodology outlined above can be used to systematically point out the gaps in the Barings trading process controls that allowed disaster to occur, as well as to suggest ways for closing those gaps. As noted above, the first step is to capture the ‘ideal’ business process. Figure 6 depicts a simplified but accurate model of the Barings futures trading process; boxes correspond to process activities, and lines correspond to dependencies between these activities: Customer Place Request
Trader
Buy Futures Contract
Receive Certificate
Send Payment
Bank Treasury Transfer Funds
Prerequisite Flow
Figure 6. The Barings Futures Trading Process
When a customer requests a futures trade, the trader asks the bank headquarters for an advance of funds in order to cover the customer’s margin account2. Once the funds have arrived, the trader performs the trade, waits to receive the corresponding security certificate and finally pays the exchange. In an “ideal” world, a trader only performs trades when authorized to do so by customers, correct certificates are always received, and payment for trades exactly match the funds forwarded to the trader by the bank headquarters. These conditions are implied by the “prerequisite” and “exact flow” dependencies.
The next step is to identify the possible exceptions that are associated with each key dependency in the “ideal” process model. By consulting the exception repository onie can see that one possible exception for any prerequisite dependency management mechanism is a prerequisite violation (“B without A”), that is, the possibility of activity B happening without a prior occurrence of activity A. In the context of the Barings trade process such violations would translate into unauthorized trading, unwanted security receipts and unnecessary payment (Figure 7). Customer Place Request
Trader
Unauthorized trade
Buy Futures Contract
Wrong certificate
Receive Certificate
Send Payment
Bank Treasury Transfer Funds
Prerequisite Funds misused
Flow
Figure 7. The Barings Futures Trading Process with Associated Exceptions
Likewise, one possible exception for the mechanism managing an “exact flow” dependency is mismatch between the amount produced and the amount consumed. In the context of the Barings process this would translate into a misuse of headquarter funds. After possible exceptions have been identified, the next step is to find handlers suitable for mamaging the possible exceptions identified in step 1. It turns out that, because the trading process at Barings involves several independent entities (customer, bank, exchange) and requires some initiative from the part of the trader, there are were no practical mechanisms for avoiding the exceptions. There were, however, several mechanisms for detecting them.
Main Process
A
Update Log A
B
Exception Avoidance Process
Update Log B
Prerequisite Periodic Consistency Check
Exclusive access
Figure 8. Logging is a Generic Process for Detecting Prerequisite Violations
For example, logging is one (out of several) generic mechanism for detecting prerequisite relationship violations (Figure 8). Logging involves recording all occurrences of activities A and B in some reliable storage medium and periodically conducting checks for prerequisite violations. In order for logging to be successful it is, in turn, required that (a) all occurrences of A and B are reliably logged and (b) the log can only be modified by the processes that do the logging. If we insert a logging process for all dependencies listed in Figure 8 we get a model of a properly instrumented trading process (Figure 9). Flow Prerequisite Exclusive access
Customer Place Request Update Commits
Trader Update Reqs
Bank Treasury
Update Funds
Buy Futures Contract
Update Recv
Receive Certificate
Update Paid
Send Margin Payment
Transfer Margin Funds Daily Consistency Check
Figure 9. Barings Process Properly Instrumented with Logging Processes
At this point, we can compare the process derived using our approach with the actual Barings process. It can immediately be seen that, although Barings did log some information about trades, it had two crucial gaps relative to the properly instrumented process of Figure 10 (see Figure 10): Customer Barings failed to compare funds transferred against funds used for client transactions
Place Request
Trader Update Reqs
Bank Treasury
Update Funds
Buy Futures Contract
Update Commits
Barings failed to safeguard against exclusive access Update violations because trader Recv was given log modification privileges
Receive Certificate
Update Paid
Send Margin Payment
Transfer Margin Funds Daily Consistency Check
Figure 10. Comparison between Ideal and Actual Barings Process
First, it failed to log and compare the amount of funds forwarded by headquarters to the trader to the amounts actually paid by the trader for customer trades (in other words, the log labeled “Funds” in Figures 9-10 was missing from the Barings process). Second, Nick Leeson, in addition to being a trader, was also in charge of the back room operations in the Singapore branch. This gave him the authorization to modify the trades logs (and thus violated requirement (b) above of the logging process). Nick Leeson was able to use these two gaps to his advantage as follows: Whenever he received a trade request from a customer, he requested an amount of funds far greater than what was required for the customer trade. He then performed the customer trade, as well as some additional unauthorized trades on his behalf. All of these trades were automatically logged into logs “Commits”, “Received” and “Paid” (see Figures 9-10). Leeson then erased the records of his unauthorized trades from logs “Commits”, “Received” and “Paid”. Therefore, at the end of each day, the log of “Requests” matched perfectly the other three logs. By not checking for discrepancies between the funds forwarded to Leeson and the total funds recorded at the “Paid” log, headquarters remained unaware of Leeson’s activities until it was too late. It is probably too simplistic to claim that the Barings disaster would have been avoided if the management of Barings had at their disposal knowledge-based exception handling methodologies, such as the ones described in this paper. Nevertheless, this exercise demonstrates that these methodologies and tools can be used in real-life cases to alert
management of potential weaknesses and suggest ways for making vital business processes more robust. Facilitating Research: An exception repository can serve as a valuable resource for fostering more effective, accumulative and cross-disciplinary research on exception management, in several important ways. The cross-disciplinary transfer of ideas is facilitated because exception management expertise is captured in a single repository indexed by functional similarity rather than source domain. The taxonomic structure of the repository facilitates finding gaps in the exception management knowledge. One can, for example, look for exception types with no associated exception handlers. The Web version of the exception repository also supports structured discussions by allowing one to create discussion forums organized around focus topics such as filling in a particular branch of a taxonomy, adding to a tradeoff table, or detailing a particular process description. It has been our experience that such foci can be more effective than unstructured discussions for capturing process knowledge. Evaluation of The Contributions of This Work We have been unable to uncover any previous effort to produce a systematic multidisciplinary repository of exception handling expertise for business processes. There have been a few analogous efforts to capture knowledge about handling the subset of exceptions known as multi-agent conflicts (Matta 1996) (Castelfranchi 1996) (Ramesh and Sengupta 1994) (Feldman 1985) but they leave out other exception types, and are lacking key concepts incorporated in the MIT Exception Repository, such as the coordination mechanism to exception mapping and the taxonomy of exception handling processes. The MIT Exception Repository has been evaluated only on a limited internal basis to date, so it is premature to draw definitive conclusions about its utility for students, researchers and practitioners. Our experience to date suggests, however, that the repository is likely to have significant value. The repository currently includes knowledge derived from roughly 60 research publications, in addition to our own analyses of the exception types and associated handlers for a range of market-based and other coordination mechanisms. It is our judgement that the schema presented above captures all the significant aspects of the exception management information we have encountered to date. It is also clear, in addition, that the Process Handbook provides a high level of enabling technology for repository purposes, including a growing set of sophisticated search, navigation, business process re-design and structured discussion tools. Previous experience with these tools suggests that they can be powerful enablers. The Handbook has been successfully used, for example, to teach classes at the Sloan School of Management as well as Babson College. The Handbook process redesign methodology has been applied in several domains, most recently (in cooperation with the consulting firm AT Kearney) to re-design the hiring processes in a major financial services firm. The
participants in this study felt that the approach was effective in generating a much wider range of novel and promising process alternatives than would have been uncovered by traditional methods (Herman, Klein et al. 1998). Future Work The MIT Exception Repository is a work in progress. We will continue to add to the repository content, drawing from multiple disciplines. We plan to explore the use of additional repository structuring schemes and tools, such as the notion of a “guided tour’ that provides a suggested sequence for traversing the repository links for specific pedagogical purposes. We are also evolving the repository into the basis of a knowledgebased business process design assistant, e.g. making use of tools such as the MIT Process Recombinator process re-design tool (Bernstein, Klein et al. 1999). Our hope, finally, is to evolve the exception repository into a self-sustaining Web-based community resource, which will require addressing technological issues (for example, developing a Web-based authoring tool) as well as sociological issues (particularly concerning incentives for adding content). For additional information about this and related work, including eventual access to the MIT exception repository itself, please see http://ccs.mit.edu/klein/. Acknowledgements This work was supported by NSF grant IIS-9803251 (Computation and Social Systems Program) and by DARPA grant F30602-98-2-0099 (Control of Agent Based Systems Program). I am grateful for many helpful comments from the members of the MIT Center for Coordination Science: John Quimby, George Herman, George Wyner, Abraham Bernstein, and Prof. Thomas Malone. References Bernstein, A., M. Klein, et al. (1999). The Process Recombinator: A Tool for Generating New Business Process Ideas. Proceedings of the International Conference on Information Systems (ICIS-99), Charlotte, North Carolina USA. Castelfranchi, C. (1996). Conflict Ontology. Proceedings of the Workshop on Conflict Management, European Conference on Artificial Intelligence (ECAI). Chia, M. H., D. E. Neiman, et al. (1998). Poaching and distraction in asynchronous agent activities. Proceedings of the Third International Conference on Multi-Agent Systems, Paris, France. Chiu, D. K. W., K. Karlapalem, et al. (1997). Exception Handling in ADOME Workflow System. Hong Kong, Hong Kong University of Science and Technology. Fay, S. (1997). The collapse of Barings. New York, W.W. Norton.
Feldman, D. C. (1985). “A Taxonomy Of Intergroup Conflict Resolution Strategies.” The 1985 Annual Conference on Developing Human Resources. Grudin, J. (1994). “Groupware and Social Dynamics: Eight Challenges for Developers.” Communications of the ACM 37(1): 93-105. Herman, G., M. Klein, et al. (1998). A Template-Based Process Redesign Methodology Based on the Process Handbook. Unpublished discussion paper. Cambridge MA, Center for Coordination Science, Sloan School of Management, Massachussetts Institute of Technology. Karbe, B. H. and N. G. Ramsberger (1990). Influence of Exception Handling on the Support of Cooperative Office Work. Multi-User Interfaces and Applications. S. Gibbs and A. A. VerrijinStuart, Elsevier Science Publishers: 355-370. Klein, M. (2000). Towards a Systematic Repository of Knowledge About Managing Collaborative Design Conflicts . Proceedings of the International Conference on AI in Design (AID-2000), Boston MA. Klein, M. and C. Dellarocas (2000). Domain-Independent Exception Handling Services That Increase Robustness in Open Multi-Agent Systems. CCS Working Paper CCS-WP-211. Cambridge MA USA, Massachusetts Institute of Technology. Klein, M. and C. Dellarocas (2000). “A Knowledge-Based Approach to Handling Exceptions in Workflow Systems.” Journal of Computer-Supported Collaborative Work. Special Issue on Adaptive Workflow Systems. 9(3/4). Kreifelts, T. and G. Woetzel (1987). Distribution and Error Handling in an Office Procedure System . IFIP WF 8.4 Working Conference on Methods and Tools for Office Systems, Pisa Italy. Malone, T. W., K. Crowston, et al. (1998). “Tools for inventing organizations: Toward a handbook of organizational processes.” Management Science 45(3): 425-443. Malone, T. W. and K. G. Crowston (1994). “The interdisciplinary study of Coordination.” ACM Computing Surveys 26(1): 87-119. Matta, N. (1996). Conflict Management in Concurrent Engineering: Modelling Guides. ECAI Workshop on Conflict Management. Mi, P. and W. Scacchi (1991). Modelling Articulation Work in Software Engineering Processes. 1st International Conference on the Software Process. Ramesh, B. and K. Sengupta (1994). “Managing Cognitive and Mixed-Motive Conflicts in Concurrent Engineering.” Concurrent Engineering Research and Applications: Special Issue on Conflict Management in Concurrent Engineering II(3): 223-236. Strong, D. M. (1992). “Decision support for exception handling and quality control in office operations.” Decision Support Systems 8(3): 217-227. Suchman, L. A. (1983). “Office Procedures as Practical Action: Models of Work and System Design.” ACM Transactions on Office Information Systems 1(4): 320-328. Zhang, P. G. (1995). Barings bankruptcy and financial derivatives. Singapore, World Scientific Publishing Co.
