Computer-based system for work processes that consist of interdependent decisions involving one or more participants

This application is the National Stage of International Application No. PCT/US97/05969 filed Apr. 10, 1997, which claims the benefit of U.S. Provisional Application No. 60/016,080, filed Apr. 10, 1996.

FIELD OF THE INVENTION

The present invention pertains to the field of computer-supported collaborative work. More specifically it presents a method and apparatus for (1) analyzing the requirements of such work, (2) specifying the process by which such work shall be carried out, (3) instantiating work projects based upon the specified process pattern and (4) implementing computer-based systems to support the execution, control, and improvement of such collaborative work.

BACKGROUND OF THE INVENTION

“Best practice” in accounting, financial transaction processing, order processing, inventory management, and purchasing has benefitted greatly from, and is heavily dependent on, the use of information technology. Although desktop computers have become ubiquitous in other areas of business such as, engineering, marketing, sales and general management, the benefits have been far more modest. In these areas of largely professional and managerial work, computers have been used extensively to support the work of individuals. But information technology has been more difficult to exploit in professional and managerial work that requires significant collaboration among individuals. Three general approaches have been taken to leverage technology in the service of managerial and professional work-workgroup software, workflow software, and decision support software.

Workgroup software focuses on the need for communication among the many participants in managerial and professional work processes. It can be used to breach the organizational boundaries, both within and among organizations, and is adaptable to almost any set of organizational circumstances. Such flexibility can be advantageous when the requirements for communication are poorly understood or constantly changing. However, there are costs incurred for such flexibility. The administration and operation of such applications may become quite complex. Furthermore, it is sometimes advantageous to restrict the forms that a process may take to achieve not only greater economy but increased repeatability and reliability.

Workflow software is grounded in the paper metaphor of document routing. It should be economical in its use of resources and provide high repeatability due to a more restrictive, and therefore more definitive, structure than workgroup software. However, workflow software is better suited to clerical, document processing activities than to managerial and professional work. In contrast to clerical activities in which most decision situations are well understood and can be made by a single individual, managerial and professional work often entails decisions in which a number of people need to collaborate. This essential need for collaboration is the root of the ever present meetings that managers and professionals everywhere bemoan.

Early decision support software used information technology to support individual decision makers with data retrieval and data manipulation capabilities that could significantly enhance the quality of their decisions. Recent efforts have expanded decision support for individual decisions to group settings. However, decision support software does not attempt to structure the roles played in the decision by various individuals, nor does it usually structure the interdependencies of more than a few closely related decisions.

Professional and Managerial Work Processes

Professional and managerial work processes characteristically result, not in products made of wood, steel or plastic, but products that are composed predominately or even entirely of data. Business plans, product specifications, labels, advertisements, computer software, consulting reports, purchase orders, quotations, requests for quotation, and publications of all sorts, are typical products of managerial and professional work processes.

The data assemblies that are produced by managerial and professional work processes, like their physical counterparts, are sometimes built up in stages as sub-assemblies (e.g., the nutritional content section of the food package label, the terms and conditions section of the product quotation). This tiered structure is illustrated by <figref idrefs="DRAWINGS">FIG. 1</figref>, and more generally and succinctly by FIG. <b>2</b>.

Each data element, whether elementary, a sub-assembly or final assembly, is the product of a decision. That is, it is selected from two or more alternatives. For example, the color specified in a product specification might be red, green, or blue. The business plan that includes a $3 million advertising budget could have instead, included one for $2.5 or $ 2 million. Or it could have included separate line items for advertising by geographic region, or by type of media, or by product line, or various combinations of these possibilities. What it does contain is a matter of choice (i.e., a decision) and results in data.

The data assemblies that result from managerial and professional work processes are the product of numerous decisions. More importantly, many of these decisions are logically, and therefore temporally ordered. Just as we cannot assemble a computer before we produce its subassemblies, nor its subassemblies before the components it contains, neither can we assemble a business plan or a quotation before we make the decisions that produce the data from which it is assembled. There's a logical requirement that the components exist before the assembly.

In the physical work of manufacturing, there are also temporal precedence requirements that involve the transformation of materials, rather than the assembly of components. Raw material must be reduced to power or a molten state before it can be cast. And it must be cast before it can be machined. Analogously, in managerial and professional work processes data is sometimes required as the raw material for a decision even though it doesn't show up as a component of that decision's result. For example, the decision to label a product either “corrosive” or “non-corrosive” may require a prior determination of the product's pH. The pH is raw material that is processed, perhaps with other data, by the “Corrosive?” decision, but does not become a component of the result of the “Corrosive?” decision. Similarly, the number of households owning fewer than two television sets may be data that is required for the “Market Potential?” decision, but it is not assembled into that decision. However, both the market potential number and the number of households owning fewer than two TV's would probably be components of the assembly, “Product Marketing Plan”.

Need for Participation in Decision-Making. For a number of years there has been widespread recognition that it is desirable to get more people involved in important organizational decisions. The decisions made and actions taken in a complex organization composed of interdependent units frequently require contributions and commitments from many individuals if they are to succeed. Although this may seem a recent phenomenon, the interdependence and complexity were always there. In the past most people were not aware of it, nor did they need to be. Organizations ignored much of the complexity and used extra resources (e.g., people, inventories, equipment, time, etc.) to decouple the interdependencies.

But as progressive organizations began to use information technology to reduce the slack in their organizations and to increase their ability to deal with complexity, they gained competitive advantage. Others have had to follow or perish. In most businesses the elimination of slack resources has exposed inadequacies in the organizational infrastructure. The inability to adequately integrate and coordinate decision-making across tightly coupled organizational layers and functions is often a problem.

Involving others in decision-making is a way of integrating and coordinating complex organizational activity. The advantages of a more participative decision process include not only better decisions because of better information, but more readily implementable decisions because of the commitment of the participants to carry it out. Nevertheless, the results from involving more people in decision-making have frequently been disappointing at best and a frustrating waste of time at worst. In the '70's, “participative management” was espoused by academics, promoted by consultants, and loudly proclaimed by many managements. The disappointment, if not disillusionment that followed, was of course predictable. It was yet another case of a very valid and useful idea that was over-promoted and under-invested.

In the '80's “participative management” was superseded by the coming of “teams” with similar results. It is often at least useful, and perhaps essential, for a group of people to work together interactively-as a team. It is seldom adequate however, to roundup a group, anoint them with “teamhood,” provide team T-shirts and send them off to play the game. The football, basketball, and other teams that provide the model for organizational teams, don't usually play the game without considerable investment in learning how to “block and tackle” and then practicing the “blocking and tackling” repeatedly until they do it really well. They also develop “play books” and shared understanding of cryptic signals. They learn to anticipate each others moves, again as a result of much practice together. Where are the organizational equivalents of these indispensable requirements for the success of athletic teams? What one usually finds is a one day, or at most one week course, followed by a return to the workplace bearing an appropriately emblazoned coffee mug and plaque for the wall.

Participative decision-making was and is a good idea. However, it is an idea that contains several traps for the unwary. A common trap is the assumption (usually unexamined and unstated) that participation means equality-that everyone who participates, participates in the same way and to the same degree. From that assumption flows the further assumption that everyone gets a vote, that the majority rules or that unanimity or consensus must be achieved if a decision is to be made. While there may be situations where such assumptions are appropriate, in most organizational situations they are neither desirable nor realistic.

A critical omission from many organizational teams is an appropriate set of clearly differentiated roles for the players and a related vocabulary. The “players” need a way to communicate effectively with one another about the “positions” they are playing, the “moves” they intend to make, and what they expect of their colleagues.

We need a method to analyze, specify and support work processes that consist of many, interdependent decisions, at least some of which require collaboration among multiple participants for satisfactory results. This is at least part of an answer to two critical problems currently faced by most complex organizations—1) How to get better integration of effort across organizational boundaries, both those created within organizations (e.g., between engineering and manufacturing, or eastern sales region and central sales region) and the boundaries between organizations (e.g., customer and supplier, business and government, federal government and state government), and 2) How to improve the performance of managerial and professional work, where such performance may be measured in terms of reliability of the process in producing quality output, the productivity of the process, or the speed of the process.

SUMMARY OF THE INVENTION

The present invention provides a novel way of using information technology in support of professional and managerial work processes. The approach is based on the modeling of professional and managerial work processes as networks of multiple, interdependent decisions, some of which may involve multiple participants in specific, differentiated roles. The proposed method entails the modeling of the work process using several familiar entities—decisions, decision rules and data—and another less familiar set of entities—decision roles. The work process model produced using these entities is used as a pattern for the generation of project models. These project models are a central element in a computer—and communications-based infrastructure to direct and guide the behavior of the participants in the work process.

Like both workflow and workgroup software, this approach recognizes the importance of facilitating communication among collaborating individuals. Like decision support software, this approach recognizes the utility of assisting workers with access to appropriate data and the manipulation of that data. Unlike other approaches the proposed approach provides a method for structuring professional and managerial processes modularly using object technology and with a degree of structure that can be varied for each object independently. When understanding of the work process is great, that knowledge can be used to build more highly structured, and therefore more valuable, supporting infrastructure. Where less precise or less fully defined understanding of the work process is all that is available, the proposed method allows a correspondingly less structured supporting infrastructure that can be enhanced as understanding of the process increases.

The exploitation of information technology in support of professional and managerial work has been limited by failure to specify the processes used to accomplish such work. The available tools for modeling and specifying such work have been inadequate. The present invention is based on a methodology that addresses this inadequacy. Professional and managerial work processes are modeled as networks of linked decisions and data. The decisions that make up such work often require significant participation of many people. The approach utilized by the present invention identifies the roles that are useful and provides specifications for the behavior and requirements of individuals playing those roles.

Decision Networks. Every decision produces a result in the form of data. Although any decision may be viewed in isolation, it is useful to identify the data required to make the decision. That data is in turn the result of one or more other decisions. Therefore, the decision that requires data is dependent on the decisions that produce it (See FIG. <b>3</b>). Therefore, if we establish the interdependencies among decisions based on our understanding of the data they produce and the data they require, we have established a basis for both routing data and triggering decision situations. That is, send a data element to all decisions requiring it, and trigger a decision when all required data has been received.

Each decision is viewed as an “atomic” process-taking required data and processing it to produce a result as output data. The decisions that make up professional and managerial work processes are typically related to other decisions by virtue of their need for data resulting from earlier decisions. <figref idrefs="DRAWINGS">FIG. 4</figref> depicts a typical decision process, in this case a proposal preparation process for some equipment. The nodes of the network are the decisions with their associated data output. The decision interdependencies are depicted as directed arcs connecting the nodes. The connecting arcs run from the independent decision at the entry of the arc to the dependent decision at the exit end of the arc which is indicated by an arrowhead. Professional and managerial work processes are treated therefore, as “molecular” networks of such “atomic” decision processes that convert data to a desired output. The method of the present invention couples these decision networks to a structure for participation by multiple individuals in the “atomic” decision processes.

Decision Roles &amp; Responsibilities. A structure is needed for successful participative decision-making that explicitly recognizes the different reasons for participation and the different capacities in which participants can be expected to contribute. It has proven useful to distinguish five decision roles, namely: Decision Manager, Consultee, Approver, Inspector, and Informee.

The Decision Manager plays the central role that has traditionally been associated with the term “decision maker,” that is, making the choice of one from among two or more possible options. However, the role also carries critical additional responsibilities. The Decision Manager must manage the decision process and take responsibility for implementation of the decision. Our paradigm of the “decision maker” has been profoundly influenced by our experience of decision-making as a solitary, rather than a group process. The term “Decision Manager” has been deliberately chosen here to help break the paradigm's hold on our thinking—to emphasize responsibility for the conduct of the decision process rather than for the mere selection of an alternative. The decision maker has usually been associated only with the latter responsibility. Our Decision Manager is responsible for both the choice and the process of choosing.

The role of a Consultee is to provide either expertise required to make a good decision or commitment of resources needed for successful implementation. A Consultee has a right to the opportunity to influence the Decision Manager's choice, not a right to veto that choice. The consultation process, which is managed by the Decision Manager, may take any of several forms at the discretion of the Decision Manager. In decision situations that require more than two or three Consultees or that are new, unclear or complex, the Decision Manager may find it appropriate to bring the Consultees together for one or more face-to-face meetings. This differs from common practice only in having more thoughtfully selected attendees, more explicit delineation and definition of attendee roles, and a more precisely focused agenda. Usually, where the number of Consultees is few, or the decision straight forward, face-to-face meetings are probably unnecessary. Instead, the Decision Manager may hold a tele-conference, or she may simply solicit participation from the Consultees individually by any means of communication available, with or without some preliminary indication of the decision result that she has in mind. The only requirement is that the Consultees feel that they have had an adequate opportunity to influence the Decision Manager's choice.

An Approver's role is to prevent organizationally intolerable outcomes that might result from a decision made without the benefit of some expertise that the Approver has, and is not otherwise available to the Decision Manager. The other reason for an Approver is to assure that the decision has not been unduly influenced by the parochial interests of the Decision Manager to the detriment of the organization. The Approver role is like the Consultee role with two important differences. The Approver has veto power (i.e., he must be satisfied with the decision result and the process) and the Approver does not participate fully in the deliberations that take place before the decision. It is desirable for the Approver to be informed about the progress and content of lengthy and complex deliberations as they go on, rather than being informed at the conclusion. However, the Approver's full participation in the pre-decision deliberations would severely undermine the role of the Decision Manager, since the Approver would essentially be taking on the role of Decision Manager. (It would be better to make the Decision Manager a Consultee and make the Approver the Decision Manager—explicitly.)

An Informee's role is to make subsequent decisions and perform subsequent tasks in a way that is consistent with the decision made. The defining characteristic of this role is that, while an Informee's participation in the deliberations leading up to the decision is not useful, his or her failure to participate in carrying out the decision may seriously undermine the implementation. Consider, for example, the payroll clerk. In most organizations it would not be useful to include the payroll clerk in decisions regarding the size of salaries and bonuses to be awarded. But failure to inform the clerk of the decision once it has been made, renders the decision moot.

The Inspector's role is to ensure that the result of a decision conforms to any published specifications. Individuals who are called “approvers” are often merely inspectors. These so-called “approvers” are checking to see that others have done what they were supposed to have done-that is, they are checking to see that the result of the decision conforms to some set of specifications. For example, a lawyer may check to see that the copyright and trademark notices have been properly displayed. A marketing manager may verify that the artist has used the correct colors. This is a different role than the one we have outlined above in that the requirements are fully established and the so-called “approver” is simply checking to see that they have been met. Unlike the Approver's role, these tasks could be delegated to any conscientious person. This is an inspector's job and we therefor call the role “Inspector.”

The five decision roles and their specific responsibilities to others are set forth in Table A.

BRIEF DESCRIPTION OF THE DRAWINGS

In the accompanying drawings, the preferred embodiment of the invention and preferred methods of practicing the invention are illustrated in which:

<figref idrefs="DRAWINGS">FIG. 1</figref> is an object diagram illustrating a prototypical aggregation of data.

<figref idrefs="DRAWINGS">FIG. 2</figref> is an object diagram defining the general aggregation of data.

<figref idrefs="DRAWINGS">FIG. 3</figref> is a schematic diagram illustrating the relationship of data to decisions and the linking of decisions through data.

<figref idrefs="DRAWINGS">FIG. 4</figref> is a schematic diagram illustrating the network structure of decisions in a typical decision process—in this instance a hypothetical proposal preparation process.

<figref idrefs="DRAWINGS">FIG. 5</figref> is a class diagram illustrating the abstract and concrete classes comprising the application framework of the present invention.

<figref idrefs="DRAWINGS">FIG. 6</figref> is a class diagram illustrating the relationship between two of the abstract classes, Decision and Data, of the application framework and their concrete classes and object instances.

<figref idrefs="DRAWINGS">FIG. 7</figref> is a class diagram depicting the classes and objects comprising a prototypical process model generated with the application framework of the present invention (reference made to FIG. <b>4</b>).

<figref idrefs="DRAWINGS">FIG. 8</figref> is a class diagram depicting the classes and objects comprising a prototypical project model instantiated by the prototypical process model of FIG. <b>7</b>.

<figref idrefs="DRAWINGS">FIG. 9</figref> is a class diagram depicting the classes of the application framework of the present invention and their relationships to one another.

<figref idrefs="DRAWINGS">FIG. 10</figref> is state diagram depicting the aspects of the Project object that change over time.

<figref idrefs="DRAWINGS">FIG. 11</figref> is state diagram depicting the aspects of the Decision object that change over time.

<figref idrefs="DRAWINGS">FIG. 12</figref> is state diagram depicting the aspects of the Data object that change over time.

<figref idrefs="DRAWINGS">FIG. 13</figref> is state diagram depicting the aspects of the Directed Arc object that change over time.

<figref idrefs="DRAWINGS">FIG. 14</figref> is state diagram depicting the aspects of the Arc Entry Collection object that change over time.

<figref idrefs="DRAWINGS">FIG. 15</figref> is state diagram depicting the aspects of the Arc Exit Collection object that change over time.

<figref idrefs="DRAWINGS">FIG. 16</figref> is state diagram depicting the aspects of the Decision Manager object that change over time.

<figref idrefs="DRAWINGS">FIG. 17</figref> is state diagram depicting the aspects of the Consultee object that change over time.

<figref idrefs="DRAWINGS">FIG. 18</figref> is state diagram depicting the aspects of the Inspector object that change over time.

<figref idrefs="DRAWINGS">FIG. 19</figref> is state diagram depicting the aspects of the Approver object that change over time.

<figref idrefs="DRAWINGS">FIG. 20</figref> is state diagram depicting the aspects of the Informee object that change over time.

<figref idrefs="DRAWINGS">FIG. 21</figref> is a data flow diagram depicting the data flow and value transformations required to instantiate a Project object and the Decision, Directed Arc and Arc Collection objects of the Project.

<figref idrefs="DRAWINGS">FIG. 22</figref> is a data flow diagram depicting the data flow and value transformations required to instantiate Decision Role objects.

<figref idrefs="DRAWINGS">FIG. 23</figref> is a data flow diagram depicting the data flow and value transformations required to instantiate Data objects.

<figref idrefs="DRAWINGS">FIG. 24</figref> is a data flow diagram depicting the data flow and value transformations required to iterate a Project object.

DESCRIPTION OF THE PREFERRED EMBODIMENT

Glossary. The discussion of the present invention utilizes certain terms in a precise sense. The following definitions of those terms are provided for clarity.

“Decision” means a decision situation in which a choice is to be made from among two or more alternatives (e.g., color?, corrosive?, price?, supplier? quantity?). The number of alternatives may be infinite or unknown.

“Data” means the result of the act of deciding (e.g., red, yes, $5.00 each, Acme, 650). A data element may be divisible into constituent data elements (e.g., cells in a matrix, items in a list, characters in a string, delimited areas of a graphic).

“Decision Role” means the set of behaviors prescribed for a participant in a decision (e.g., Decision Manager, Consultee, Approver, Inspector, Informee). There can be any number of different roles defined for participants.

“Position” means position or job in an organization, usually designated by a title (e.g., President, CEO, Quality Manager, Foreman, Chemist) and job description.

“Process” means a system that converts inputs to outputs (e.g., computer system, manufacturing system, water purification system, justice system).

“Decision Process” means a process whose inputs and outputs are data, or artifacts containing data (e.g., business planning process, product development process, sales process, customer support process), and whose principal components are decisions.

“Process Model” means a model constructed of both concrete and abstract classes and object instances of some of those classes, that specifies and defines the way in which the work of a decision process will be performed.

“Project” is an instance of a process model (e.g., this year's business plan, the development of an improved widget, getting the Acme Company order, addressing the issues at Consolidated Corp.).

Terms of Art. The invention has been developed and is presented here using the conventions and practices of Object Modeling Technique (OMT).

A class is an abstraction that describes properties important to an application and ignores the rest. . . . Each class describes a possibly infinite set of individual objects. Each object is said to be an instance of its class. (Jame Raumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, and William Lorensen, <i>Object</i>-<i>Oriented Modeling and Design</i>, Prentice Hall: Englewood Cliffs, N.J., 1991, p. 2)

An abstract class is a class that has no direct instances but whose descendent classes have direct instances. A concrete class is a class that is instantiable; that is it can have direct instances. (ibid., p. 61)

The OMT methodology uses three kinds of models to describe a system: the object model, describing the objects in the system and their relationships; the dynamic model, describing the interactions among objects in the system; and the functional model, describing the data transformations of the system. Each model is applicable during all stages of development and acquires implementation detail as development progresses. A complete description of a system requires all three models.

The object model describes the static structure of the objects in a system and their relationships. The object model contains object diagrams. An object diagram is a graph whose nodes are object classes and whose arcs are relationships among classes.

The dynamic model describes the aspects of a system that change over time. The dynamic model is used to specify and implement the control aspects of a system. The dynamic model contains state diagrams. A state diagram is a graph whose nodes are states and whose arcs are transitions between states caused by events.

The functional model describes the data value transformations within a system. The functional model contains data flow diagrams. A data flow diagram represents a computation. A data flow diagram is a graph whose nodes are processes and whose arcs are data flows.

The three models are orthogonal parts of the description of a complete system and are cross-linked. The object model is most fundamental however, because it is necessary to describe what is changing or transforming before describing when or how it changes.

Object-oriented development places a greater emphasis on data structure and a lesser emphasis on procedure structure than traditional functional-decomposition methodologies. [It] adds [and relies on] the concept of class-dependent behavior. (ibid., pp. 6-7)

Abstract classes form the basis of a framework. If abstract classes factor out enough common behavior, other components, that is, concrete classes or other abstract classes, can be implemented based on the contracts offered by the abstract classes. A set of such abstract and concrete classes is called a framework.

The term application framework is used if this set of abstract and concrete classes comprises a generic software system for an application domain. Applications based on such an application framework are built by customizing its abstract and concrete classes. In general, a given framework anticipates much of a software systems's design. The design is reused by all software systems built with the framework. (Wolfgang Pree, <i>Design Patterns for Object-Oriented Software Development</i>, Addison-Wesley: Reading, Mass., 1995, p. 54.)

Conventions. References in the description to specific elements of figures are keyed with numerals that appear bold-faced in both the text and the figure. Numeric references to classes and their objects are numerals below <b>200</b> and are consistent across all figures. All other numeric references are specific to the particular figure. Notation used in figures is generally that of OMT (Rumbaugh, et. al., op. cit., inside front &amp; back covers.). Class, object and state names are capitalized. Abstract class names are also italicized and underscored in figures, but not in the text. A question mark, “?”, at the end of a class name is used to distinguish a concrete decision class or object name from their related concrete data class or object names.

Framework Architecture. The present invention consists of an application framework for the development of abstract, decision process models. Each such decision process model is used as a pattern to instantiate concrete project models that incorporate the work defined by the abstract process. The framework is built around a core set postulates—1) the work of the process requires the production of data or artifacts incorporating data, 2) decisions are the processes that produce data, 3) some decisions themselves require data, either as raw material which is processed or as a component of a data assembly, 4) some decisions require the participation of two or more persons in differentiated roles, 5) a process model specifies how work shall be done, 6) a project is a unit of work performed in accordance with the process, and 7) decisions that require data are logically, and therefore temporally dependent on the decisions that provide the required data.

Object Model

The Framework <b>99</b> is constructed from a related set of abstract and concrete object classes that are depicted in FIG. <b>6</b>. The abstract Decision class <b>100</b> has members that are classes of decisions which are specific to the application domain. In the example, depicted in <figref idrefs="DRAWINGS">FIG. 4</figref>, all of the boxes representing nodes of the network would be modeled as concrete class instances of the Decision class <b>100</b>. This relationship between the abstract Decision class <b>100</b> and some of its concrete classes and object instances are more clearly depicted in the upper half of FIG. <b>6</b>. The Data class <b>101</b> is also an abstract class that has a one-to-one relationship with the Decision class <b>100</b>. The relationship between the abstract Data class <b>101</b>, its concrete classes and their object instances is shown in the lower half of FIG. <b>6</b>. Referring again to <figref idrefs="DRAWINGS">FIG. 5</figref>, the other abstract classes of the Framework <b>99</b> are Arc Collection <b>115</b> and Decision Role <b>121</b>. The Arc Collection class <b>115</b> has two concrete subclasses, Arc Entry Collection <b>134</b> and Arc Exit Collection <b>136</b>. The instances of these classes are collections of Directed Arc <b>107</b> objects which are instances of another one of the Framework's <b>99</b> classes. These two subclasses are differentiated by the end of the Directed Arc <b>107</b> object that they use to determine their members; the former using the entry end of the Directed Arc <b>10</b> object (the end without the arrowhead in <figref idrefs="DRAWINGS">FIG. 4</figref>) and the latter using the exit end. The abstract Decision Role class <b>121</b> has five concrete classes in the preferred implementation, Decision Manager <b>142</b>, Consultee <b>143</b>, Approver <b>144</b>, Inspector <b>145</b>, and Informee <b>146</b>. These five concrete, subclasses model the behaviors and responsibilities described in Table A. As indicated in <figref idrefs="DRAWINGS">FIG. 5</figref>, there will be exactly one Decision Manager <b>142</b> related to each Decision <b>100</b>. There may or may not be any Position <b>119</b> designated to participate in a Decision <b>100</b> in any of the other four roles <b>143</b>, <b>144</b>, <b>145</b>, and <b>146</b>. Nor is there a limit on the number of Positions <b>119</b> that may participate <b>120</b> in any of these latter four roles. The final classes of the Framework <b>99</b> are the concrete classes Position <b>119</b> and Person <b>116</b> which model the organization and the incumbents of the organization respectively.

The Framework <b>99</b> depicted in <figref idrefs="DRAWINGS">FIG. 5</figref> has both abstract and concrete classes but no objects. Two of its classes do not have any concrete classes. <figref idrefs="DRAWINGS">FIG. 7</figref> depicts classes and objects of a hypothetical Process Model <b>129</b> derived from the Frame work and based on the example depicted in FIG. <b>4</b>. In addition to the elements of the Framework depicted in <figref idrefs="DRAWINGS">FIG. 5</figref>, the Process Model <b>129</b> has concrete subclasses Cost <b>10</b>, Price <b>11</b>, Terms <b>12</b> etc. of the of the abstract Data class <b>101</b>, and concrete subclasses Cost ? <b>14</b>, Price? <b>15</b>, Terms? <b>16</b> etc. of the of the abstract Decision class <b>100</b>. (the short broken lines <b>13</b> and <b>17</b> indicate that there are other concrete subclasses of these two abstract classes which have been omitted for clarity.) The Framework <b>99</b> abstracts the desired behavior common to all decision processes whether they be a proposal preparation process, a product development process, or a strategic planning process. The Process Model 129 is more concrete and specific. It abstracts only those desired behaviors that are common to the particular decision process being modeled, in the example illustrated in <figref idrefs="DRAWINGS">FIG. 4</figref>, <figref idrefs="DRAWINGS">FIG. 6</figref>, and <figref idrefs="DRAWINGS">FIG. 7</figref>, the proposal preparation process of the organization or organizations that use this particular process. The process Model <b>129</b> also includes the objects which are instances of the concrete classes Directed Arc <b>107</b>, Arc Entry Collection <b>134</b>, Arc Exit Collection <b>136</b>, Position <b>119</b>, and the five concrete subclasses of the Decision Role class <b>121</b> to the extent that any are specified for this particular process.

The only potential objects that are missing from the Process Model <b>129</b> are the objects that are instances of the concrete subclasses of Decision <b>100</b> and Data <b>101</b> and the concrete class Person <b>116</b>. Unlike the objects that are included in the Process Model <b>129</b>, the missing objects are expected to change from project to project as the process is followed. These are the objects that belong to the Project Model <b>127</b> and are so depicted in <figref idrefs="DRAWINGS">FIG. 8</figref> (see <b>23</b>, <b>24</b> and <b>25</b>).

<figref idrefs="DRAWINGS">FIG. 9</figref> depicts the classes of the Framework <b>99</b> with all of their important associations, some of which were omitted from the foregoing figures and discussion. As illustrated in <figref idrefs="DRAWINGS">FIG. 9</figref>, each instance of the Decision class <b>100</b> produces <b>102</b> one, and only one, instance of the concrete subclasses of Data class <b>101</b>. The instances of Data <b>101</b>'s concrete classes, may be of any type including two-valued boolean, simple scalars, text strings or more complex types such as matrices, graphics or documents. Data <b>101</b> is also related to Decisions <b>100</b> in another way. A Decision <b>100</b> may require <b>103</b> one or more elements of required Data <b>104</b> as input. A Decision <b>100</b> in such a relationship with required Data <b>104</b>, is a requiring Decision <b>105</b>. For example, the “quoted price?” Decision <b>100</b> may require <b>103</b> the required Data <b>104</b>, “quantity quoted”, which is produced <b>102</b> by the “quantity to quote?” Decision <b>100</b>. The “quoted price?” Decision <b>100</b> might also require Data <b>104</b> from the “customer class?”, “delivery requirement?”, “terms quoted?”, and “competitive situation?” Decisions <b>100</b>.

Each element of required Data <b>104</b> has <b>106</b> one or more Directed Arcs <b>107</b> which are paired <b>132</b> one-to-one with the required by <b>103</b> relationship between each element of required Data <b>104</b> and each of the requiring Decisions <b>105</b>. Each Directed Arc <b>107</b> is related at its exit <b>108</b> end to the requiring Decision <b>105</b> of the related <b>106</b> required Data <b>104</b>. At its entry <b>109</b> end, each Directed Arc <b>107</b> is related to the producing Decision <b>110</b> of the required Data <b>104</b> associated <b>106</b> with the Directed Arc <b>107</b>.

Requiring <b>105</b> Decisions <b>100</b> and their dependencies upon producing <b>110</b> Decisions <b>100</b> are connected by Directed Arcs <b>107</b> with an entry at the end of the arc connected to its respective producing <b>110</b> Decision <b>100</b> and an exit at the end of the arc connected to its requiring <b>105</b> Decision <b>100</b>. Each Directed Arc <b>107</b> is a member <b>133</b> of one Arc Entry Collection <b>134</b> comprised of <b>133</b> all and only those Directed Arcs <b>107</b> which have the same producing Decision <b>110</b>. Each Directed Arc <b>107</b> is also a member <b>135</b> of one Arc Exit Collection <b>136</b> comprised of <b>135</b> all and only those Directed Arcs <b>107</b> which have the same requiring Decision <b>105</b>. Arc Entry Collections <b>134</b> and Arc Exit Collections <b>136</b> are specializations of the Arc Collection <b>115</b> class, which specialization is based on whether the class is defined by its entry <b>109</b> relationship or its exit <b>108</b> relationship.

Persons <b>116</b> occupy <b>118</b> organizational Positions <b>119</b> which participate <b>120</b> in Decisions <b>100</b> in a Decision Role <b>121</b> that defines the expected and acceptable behaviors associated with that participation <b>120</b>.

A subset <b>122</b> of required Data <b>104</b> may be used as Rules <b>123</b>. Such Rules <b>123</b> may be used to make <b>124</b> Decisions <b>100</b>. For example, a rule for making a Decision that converts “quantity quoted” and “list price” into “price quoted” might be “IF {quantity quoted}&lt;10, THEN {price quoted}={list price}, ELSE {price quoted}=0.9*{list price}.” A Rule <b>123</b> may also be used to specify the applicability <b>125</b> of a Decision Role <b>121</b>, or both <b>126</b> of an element of required Data <b>104</b> and <b>127</b> its associated <b>106</b> Directed Arc <b>107</b>. Note that the Rule <b>123</b> determining the applicability of required Data <b>104</b> and the Rule <b>123</b> determining the applicability of its associated <b>106</b> Directed Arc <b>107</b> is constrained to be the same Rule <b>128</b> because required Data <b>104</b> and its associated <b>106</b> Directed Arc <b>107</b> must be either both applicable, or both inapplicable. Note also, that a Rule <b>123</b> may be used to specify the applicability <b>126</b> of another Rule <b>123</b>, since that other Rule <b>123</b> is also an element of required Data <b>104</b>. Examples of these uses of rules to govern applicability are:

(1) Decision Role <b>121</b> applicability <b>125</b>: “IF {product category]={lawn care}, THEN {Decision Manager}={Product Manager, Lawn Care}, ELSE IF {product category}={snow blowers}, THEN {Decision Manager}={Product Manager, Snow Handling}, ELSE {Decision Manager}={Marketing Manager};”

(2) Directed Arc <b>107</b> and required Data <b>104</b> applicability <b>126</b> and <b>127</b>, where required data does not operate as a rule: “IF {product's ‘kill claims’ }={none}, THEN {registration number} NOT REQUIRED by {label layout} AND Arc:{registration number } to {label layout} NOT APPLICABLE, ELSE; {registration number} REQUIRED by {label layout} AND Arc: {registration number} to {label layout} APPLICABLE;

(3) Directed Arc <b>107</b> and required Data <b>104</b> applicability <b>126</b> and <b>127</b>, where required data does operate as a rule: “IF {product status}={established}, THEN use {quantity discount rule}, ELSE, use {null rule }.”

All of the foregoing object classes other than Project <b>127</b> aggregate to Process <b>129</b>, which is managed <b>117</b> by a Person <b>116</b> occupying <b>118</b> a Position <b>119</b> which has been designated the “Process Manager.” Alternatively, a Person <b>116</b> could be directly designated to manage <b>117</b> a Process <b>129</b> without an intervening Position <b>119</b>. A Project <b>127</b> is instantiated <b>128</b> based on the pattern provided by the Process Model <b>129</b> and a related initial <b>130</b> Decision <b>100</b>. The Project <b>127</b> network consists of an instance of the initial <b>130</b> Decision <b>100</b>, together with an instance of each of the decisions in the Process <b>129</b> that require <b>103</b>, directly or indirectly, the data <b>104</b> produced by <b>102</b> the initial <b>130</b> Decision, and an instance of all the Directed Arcs <b>107</b> connecting the initial <b>130</b> Decision <b>100</b> and the directly and indirectly requiring <b>105</b> Decisions <b>100</b>. A Project <b>127</b> is managed <b>131</b> by a Person <b>116</b> designated the “Project Manager”. Alternatively, a Person <b>116</b> could be designated to manage <b>131</b> a Project <b>127</b> via an intervening Position <b>119</b>, as is indicated for management <b>117</b> of Process <b>129</b>.

Dynamic Model

Dynamic Behavior of Project <b>127</b> Object. The dynamic behavior of the Project <b>127</b> object is depicted in FIG. <b>10</b>. The Project <b>127</b> object is instantiated in Active <b>451</b> state. If a project is put on hold the Project <b>127</b> object transits <b>452</b> to Suspended <b>453</b> state. Upon release from project hold the Project <b>127</b> object transits back to Active <b>451</b> state. If the project receives a pause <b>455</b> the Project <b>127</b> object transits <b>455</b> to Paused <b>456</b> state. Upon resume <b>457</b> the Project <b>127</b> object returns <b>457</b> to Active <b>451</b> state. If the project is aborted from any of its three states the Project <b>127</b> object transits <b>458</b>, <b>459</b>, or <b>460</b> out of existence.

Dynamic Behavior of Decision <b>100</b> Object. The objects of the domain-specific, concrete classes generated from the abstract Decision <b>100</b> class are the central controlling actors of the “atomic”, intra-decision process. Referring to <figref idrefs="DRAWINGS">FIG. 11</figref>, upon its instantiation <b>200</b> as a component of the a Project <b>127</b>, a Decision <b>100</b> object is in Dormant <b>201</b> state. It remains in Dormant <b>201</b> state until activated by the Arc Exit Collection <b>136</b> related to it. When so activated, a Decision <b>100</b> object transits <b>202</b> to Decision Release Pending <b>203</b> state. From Decision Release Pending <b>203</b> state, a Decision <b>100</b> object transits <b>204</b> to Prepare Consultation <b>205</b> state upon “release” if the number of Consultees <b>143</b> designated for the Decision <b>100</b> object is greater than zero. If the number of Consultees <b>143</b> is zero, it transits to Deliberation <b>210</b> state, upon release. “Release” is the default value of a Decision <b>100</b> object's Release/Hold attribute. It can be toggled between “release” and “hold” by any authorized individual (most appropriately, the Project Manager) at any time that the Decision <b>100</b> object is in Decision Release Pending <b>203</b> or Dormant <b>201</b> states. If the Release attribute is toggled to “release” while the Decision <b>100</b> object is in Decision Release Pending <b>203</b> state, the object immediately transits <b>204</b> or <b>209</b> to either Prepare Consultation <b>205</b> state or Deliberation <b>210</b> state depending upon whether it does or does not have Consultees <b>143</b> designated. Upon exiting Decision Release Pending <b>203</b> for the first time, a Decision <b>100</b> object causes the instantiation of all its designated Decision Role <b>121</b> objects.

When in Prepare Consultation <b>205</b> state and the Decision Manager <b>142</b> is prepared to begin consultation with the designated Consultees <b>143</b>, the Decision Manager <b>142</b> initiates the Decision <b>100</b> object's transit <b>206</b> to Consultation <b>207</b> state. Transit <b>206</b> causes notification to be sent to all designated Consultees <b>143</b>, that Consultation <b>207</b> on this Decision <b>100</b> object has begun. When the Decision Manager <b>142</b> determines that the requirements for consultation have been satisfied, the Decision <b>100</b> object transits <b>208</b> to Deliberation <b>210</b> state, causing notification of all Consultees <b>143</b>. When the Decision Manager <b>142</b> enters the decision result, the Decision <b>100</b> object either transits <b>211</b> to Inspection <b>214</b> state, or transits <b>213</b> to Approval <b>215</b> state, or transits <b>212</b> to Standby <b>216</b> state, depending on whether the Decision <b>100</b> object has at least one Inspector <b>145</b> designated, or no Inspectors <b>145</b>, but at least one Approver <b>144</b>, or neither Inspectors <b>145</b> nor Approvers <b>144</b>, respectively. From the Inspection <b>214</b> state, the Decision <b>100</b> object either transits <b>219</b> to Approval <b>215</b> state, or transits <b>220</b> to Standby <b>216</b> state when the result of inspection is “pass” and the Decision <b>100</b> object has, respectively, at least one Approver <b>144</b> or no Approvers <b>144</b> designated. When the result of the inspection is “fail,” the Decision <b>100</b> object in Inspection <b>214</b> state either transits <b>217</b> to Prepare Consultation <b>205</b> state or transits <b>218</b> to Deliberation <b>210</b> state, depending on whether the Decision <b>100</b> object does or does not have any Consultees <b>143</b> designated. When a Decision <b>100</b> object is in Approval <b>215</b> state and the result is “deny,” it either transits <b>222</b> to Prepare Consultation <b>205</b> state or transits <b>223</b> to Deliberation <b>210</b> state, depending upon whether the Decision <b>100</b> object does or does not have any Consultees <b>143</b> designated. If the result in Approval <b>215</b> state is “grant,” the Decision <b>100</b> object transits <b>221</b> to Standby <b>216</b> state. Upon completion of a Project <b>127</b>, all of the Project's Decision <b>100</b> objects will be in Standby <b>216</b> state and will transit <b>230</b> out of existence.

The states Prepare Consultation <b>205</b>, Consultation <b>207</b>, Deliberation <b>210</b>, Inspection <b>214</b>, Standby <b>216</b>, and Approval <b>215</b> of a Decision <b>100</b> object aggregate to state InProcess <b>224</b>. While a Decision <b>100</b> object is in InProcess <b>224</b> state, it may become necessary to reconsider, and therefore to iterate the Decision <b>100</b> object's decision process from its initial state. Therefore, such iteration causes a Decision <b>100</b> object in InProcess <b>224</b> state to transit <b>225</b> to Dormant <b>201</b> state, or if in Decision Release Pending <b>203</b> state, to transit <b>226</b> to Dormant <b>201</b> state. If the Project <b>127</b> of which the Decision <b>100</b> object is a part, is aborted while in any state, the Decision <b>100</b> object transits <b>227</b>, <b>228</b>, or <b>229</b> to out of existence.

Dynamic Behavior of Data <b>101</b> Object. Each Decision <b>100</b> object is associated one-to-one with the Data <b>101</b> object it produces <b>102</b>. The dynamic behavior of Data <b>101</b> objects is depicted in <figref idrefs="DRAWINGS">FIG. 12. A</figref> Data <b>101</b> object is instantiated <b>240</b> in state Entry Pending <b>241</b> when the Decision Manager <b>142</b> of its producing <b>110</b> Decision <b>100</b> is ready to enter the decision result. Upon completion of the decision entry, the Data <b>101</b> object transits <b>243</b> to Inspection or Approval <b>245</b> state if there is at least one Inspector <b>145</b> or one Approver <b>144</b> designated for the Decision <b>100</b>. Otherwise, upon decision entry the Data <b>101</b> object in Entry Pending <b>241</b> state transits <b>244</b> to Data Release Pending <b>246</b> state. When inspection results have been entered by all Inspectors <b>145</b> designated for Decision <b>100</b>, the inspection results are evaluated. If any such result indicates “fail,” the Data <b>101</b> object's state transits <b>248</b> to Historical <b>249</b> state. If all inspections result in “pass,” and there are no Approvers <b>144</b> designated for the Decision <b>100</b>, the Data <b>101</b> object's state transits <b>251</b> to Data Release Pending <b>246</b> state. When there is at least one Approver <b>144</b> designated for said Decision <b>100</b>, the approval review results are evaluated. If all required approvals are “granted,” the Data <b>101</b> object's state transits <b>250</b> to Data Release Pending <b>246</b> state. If any approval is “denied”, the Data <b>101</b> object's state transits <b>247</b> to Historical <b>249</b> state.

When a Data <b>101</b> object's “hold/release” attribute is set to “release” and it is in Data Release Pending <b>246</b> state, the Data <b>101</b> object transits <b>252</b> to Standby <b>253</b> state and sends “active” to its Arc Entry Collection <b>134</b>. The “hold/release” attribute can be used to selectively retard a project's progress by toggling it to “hold” on selected Data <b>101</b> objects. When every Decision <b>100</b> object belonging to a Project <b>127</b> has an instantiated Data <b>101</b> object which is in state Standby <b>253</b>, the Project <b>127</b> is complete and all Data <b>101</b> objects transit <b>254</b> to Operational <b>255</b> state. When Data <b>101</b> objects in Operational <b>255</b> state are superseded by a Data <b>101</b> object from a subsequent Project <b>127</b>, the former Data <b>101</b> object transits <b>256</b> to Historical <b>249</b> state. The states Inspection or Approval <b>245</b>, Data Release Pending <b>246</b>, and Standby <b>253</b> aggregate to state InProcess <b>257</b>.

If a Project <b>127</b> iterates across Decision <b>100</b> objects with related Data <b>101</b> objects that are in InProcess <b>257</b> state, such Data <b>101</b> objects transit <b>260</b> to Historical <b>249</b> state. If a Project <b>127</b> iterates across Decision <b>100</b> objects with related Data <b>101</b> objects in Entry Pending <b>241</b> state, those Data <b>101</b> objects transit <b>261</b> out of existence.

If a Project <b>127</b> is aborted with Data <b>101</b> objects in InProcess <b>257</b> state, such Data <b>101</b> objects transit <b>258</b> to Historical <b>249</b> state. If a Project <b>127</b> aborts with Data <b>101</b> objects in Entry Pending <b>241</b> state, those Data <b>101</b> objects transit <b>259</b> out of existence.

Dynamic Behavior of Directed Arc <b>107</b> Object. The objects of the Directed Arc <b>107</b> class, are the central controlling actors of the “molecular”, inter-decision process. <figref idrefs="DRAWINGS">FIG. 13</figref> depicts the dynamic behavior of Directed Arc <b>107</b> objects. Upon instantiation <b>370</b>, each Directed Arc <b>107</b> object enters Dormant <b>371</b> state, notifying its related <b>135</b> Arc Exit Collection <b>136</b> of its state. When notified by its Arc Entry Collection <b>134</b> object that said collection has become active, a Directed Arc <b>107</b> object transits <b>372</b> to Active <b>373</b> state and, upon entering that state, notifies its related <b>135</b> Arc Exit Collection <b>136</b> of its new state. If, while in Active <b>373</b> state, the related Project <b>127</b> iterates over the related Decision <b>100</b> object, the Directed Arc <b>107</b> object transits <b>374</b> to Dormant <b>371</b> state, and upon entering that state, notifies its related <b>135</b> Arc Exit Collection <b>136</b> object of its new state. If the Project <b>127</b> to which a Directed Arc <b>107</b> object belongs aborts, the Directed Arc <b>107</b> object transits <b>375</b> or <b>376</b> out of existence from either Dormant <b>371</b> or Active <b>373</b> state respectively.

Dynamic Behavior of Arc Entry Collection <b>134</b> Object. The dynamic behavior of the Arc Entry Collection <b>134</b> objects is depicted in FIG. <b>14</b>. Upon instantiation <b>380</b> an Arc Entry Collection <b>134</b> object enters Dormant <b>381</b> state and sends a message to its member <b>133</b> Directed Arc <b>107</b> objects containing its state. When notified by the Data <b>101</b> object produced by <b>102</b> the Decision <b>100</b> associated with its entry <b>109</b>, that data release <b>252</b> has occurred, the Arc Entry Collection <b>134</b> object transits <b>382</b> to Active <b>383</b> state and sends it's new state to its member <b>133</b> Directed Arcs <b>107</b>. If, while in Active <b>383</b> state, the related Project <b>127</b> iterates over the related Decision <b>100</b> object, the Arc Entry Collection <b>134</b> object transits <b>384</b> to Dormant <b>381</b> state, and upon entering that state, sends it's new state to its member <b>133</b> Directed Arcs <b>107</b>. If the Project <b>127</b> to which a member <b>133</b> Directed Arc <b>107</b> object belongs aborts, the Arc Entry Collection <b>134</b> object transits <b>385</b> or <b>386</b> out of existence from either Dormant <b>381</b> or Active <b>383</b> state respectively.

Dynamic Behavior of Arc Exit Collection <b>136</b> Object. The dynamic behavior of the Arc Exit Collection <b>136</b> objects is depicted in FIG. <b>15</b>. Upon instantiation <b>390</b> an Arc Exit Collection <b>136</b> object enters Dormant <b>391</b> state and sends a message containing its state to the requiring <b>105</b> Decision <b>100</b> object associated with its member <b>135</b> Directed Arc <b>107</b> object's exit <b>108</b>. When all of its member <b>135</b> Directed Arcs <b>107</b> are in Active <b>373</b> state, the Arc Exit Collection <b>136</b> object transits <b>392</b> to Active <b>393</b> state and sends it's new state to the requiring <b>105</b> Decision <b>100</b> object associated with its member <b>135</b> Directed Arc <b>107</b> object's exit <b>108</b>. If, while in Active <b>393</b> state, the related Project <b>127</b> iterates over the related Decision <b>100</b> object, the Arc Exit Collection <b>136</b> object transits <b>394</b> to Dormant <b>391</b> state, and upon entering that state, sends it's new state to the requiring <b>105</b> Decision <b>100</b> object associated with its member <b>135</b> Directed Arc <b>107</b> object's exit <b>108</b>. If the Project <b>127</b> to which a member <b>135</b> Directed Arc <b>107</b> object belongs aborts, the Arc Exit Collection <b>136</b> object transits <b>395</b> or <b>396</b> out of existence from either Dormant <b>391</b> or Active <b>393</b> state respectively.

Dynamic Behavior of Decision Manager <b>142</b> Decision Role <b>121</b> Object. As depicted in <figref idrefs="DRAWINGS">FIG. 16</figref>, the Decision Manager <b>142</b> object is instantiated <b>265</b> in the Prepare Consultation <b>266</b> state. If there are no Consultees <b>143</b> designated for the related Decision <b>100</b> object the Decision Manager <b>142</b> object immediately transits <b>268</b> to Deliberation <b>270</b> state. Otherwise, the Decision Manager <b>142</b> object transits <b>267</b> to Consultation <b>269</b> when the incumbent in the Decision Manager role indicates the beginning of consultation. The Decision Manager <b>142</b> object transits <b>271</b> to Deliberation <b>270</b> when the incumbent in the Decision Manager role indicates the end of consultation. The Decision Manager <b>142</b> object transits <b>271</b> from Deliberation <b>270</b> to Standby <b>272</b> state when the Decision Manager incumbent enters the decision result. From Standby <b>272</b> state the Decision Manager <b>142</b> object either transits <b>273</b> or transits <b>274</b> upon inspection fail to either Prepare Consultation <b>266</b> state or Deliberation <b>270</b> state depending, respectively or whether the Decision <b>100</b> object does or does not have any Consultees <b>143</b> designated. Upon approval deny the Decision Manager <b>142</b> object either transits <b>275</b> or transits <b>276</b> from Standby <b>272</b> state to either Prepare Consultation <b>266</b> state or Deliberation <b>270</b> state depending, respectively or whether the Decision <b>100</b> object does or does not have any Consultees <b>143</b> designated. States Prepare Consultation <b>266</b>, Consultation <b>269</b>, Deliberation <b>270</b>, and Standby <b>272</b> aggregate to state InProcess <b>277</b>. If the Decision <b>100</b> object to which the Decision Manager <b>142</b> object is related iterates, the Decision Manager <b>142</b> object transits <b>278</b> from state InProcess <b>277</b> to state Dormant <b>279</b>. If the Project <b>127</b> object of which the Decision Manager <b>142</b> object is a component aborts, the Decision Manager <b>142</b> object either transits <b>283</b> from state InProcess <b>277</b> out of existence or transits <b>282</b> from state Dormant <b>279</b> out of existence. Upon Project <b>127</b> completion the Decision Manager <b>142</b> object either transits <b>284</b> out of existence.

Dynamic Behavior of Consultee <b>143</b> Decision Role <b>121</b> Object. As depicted in <figref idrefs="DRAWINGS">FIG. 17</figref> the Consultee <b>143</b> object is instantiated <b>290</b> in Dormant <b>291</b> state. Upon the start of consultation it transits <b>292</b> to Consultation <b>293</b> state. When end consultation occurs the Consultee <b>143</b> object transits <b>294</b> to Standby <b>295</b> state. If any related inspection fails, or approval is denied, or the related Decision <b>100</b> object is iterated, the Consultee <b>143</b> object returns <b>296</b>, <b>297</b>, or <b>298</b> respectively to Dormant <b>291</b> state. The three states of the Consultee <b>143</b> object aggregate to InProcess <b>301</b> state. If the Project <b>127</b> object of which the Consultee <b>143</b> object is a component, aborts, the Consultee <b>143</b> object transits <b>302</b> out of existence. Upon completion of the project, the Consultee <b>143</b> object transits <b>300</b> out of existence.

Dynamic Behavior of Inspector <b>145</b> Decision Role <b>121</b> Object. As depicted in <figref idrefs="DRAWINGS">FIG. 18</figref> the Inspector <b>145</b> object is instantiated <b>310</b> in Dormant <b>311</b> state. Upon decision entry it transits <b>312</b> to Inspection <b>313</b> state. If all inspections pass the Inspector <b>145</b> object transits <b>315</b> to Standby <b>316</b> state. If any inspection fails,or the related Decision <b>100</b> object is iterated, the Inspector <b>145</b> object returns <b>314</b> or <b>317</b> respectively to Dormant <b>311</b> state. If the related Decision <b>100</b> iterates while the Inspector <b>145</b> object is in Standby <b>316</b> state, the Inspector <b>145</b> object transits <b>318</b> to Dormant <b>311</b> state. The three states of the Inspector <b>145</b> object aggregate to InProcess <b>320</b> state. If the Project <b>127</b> object of which the Inspector <b>145</b> object is a component, aborts, the Inspector <b>145</b> object transits <b>321</b> out of existence. Upon completion of the project, the Inspector <b>145</b> object transits <b>319</b> out of existence.

Dynamic Behavior of Approver <b>144</b> Decision Role <b>121</b> Object. As depicted in <figref idrefs="DRAWINGS">FIG. 19</figref> the Approver <b>144</b> object is instantiated <b>330</b> in Dormant <b>331</b> state. Upon decision entry it transits <b>332</b> to Approval <b>334</b> state, provided that there are no Inspector <b>145</b> objects related to this Decision <b>100</b> object. If there are Inspector <b>145</b> objects related to this Decision <b>100</b>, the Approver <b>144</b> object transits <b>333</b> to Approval <b>334</b> state upon all inspections being passed. If all approvals are granted the Approver <b>144</b> object transits <b>336</b> to Standby <b>337</b> state. If any approval is denied, or the related Decision <b>100</b> object is iterated, the Approver <b>144</b> object returns <b>335</b> or <b>338</b> respectively to Dormant <b>331</b> state. If the related Decision <b>100</b> iterates while the Approver <b>144</b> object is in Standby <b>337</b> state, the Approver <b>144</b> object transits <b>339</b> to Dormant <b>311</b> state. The three states of the Approver <b>144</b> object aggregate to InProcess <b>341</b> state. If the Project <b>127</b> object of which the Approver <b>144</b> object is a component, aborts, the Approver <b>144</b> object transits <b>342</b> out of existence. Upon completion of the project, the Approver <b>144</b> object transits <b>340</b> out of existence.

Dynamic Behavior of Informee <b>146</b> Decision Role <b>121</b> Object. Although Informees are required to act on the information they receive, they are often playing some other Decision Role <b>121</b> in a subsequent Decisions <b>100</b> which require <b>103</b> the Data <b>104</b> of the producing <b>110</b> Decision <b>100</b> and are therefore Informees <b>146</b> of producing <b>103</b> Decision <b>100</b> they do not need to be modeled as Informees <b>146</b> because the inter-decision model structure handles their notification. If, however, an Informee's <b>146</b> need is associated with a Decision <b>100</b> that is beyond the model scope (i.e., is either unknown to the subject model or is undefined), messages (e.g., E-mail, office mail) must be sent to the Informee's <b>146</b> address of record. That is the function of the Informee <b>146</b> object. <figref idrefs="DRAWINGS">FIG. 20</figref> depicts the dynamic behavior of the Informee <b>146</b> object. Upon instantiation <b>350</b> the object enters Dormant <b>351</b> state. Upon data release the Informee object <b>146</b> transits <b>352</b> to Standby <b>353</b> state and sends a message to the role incumbent containing the Data <b>101</b> and the state (i.e., released but not yet operational). If the Project <b>127</b> iterates across the Decision <b>100</b> while an Informee <b>146</b> object of that Decision <b>100</b> is in Standby <b>353</b> state, the Informee <b>146</b> object transits <b>354</b> to Dormant <b>351</b> state and sends a message to the Informee <b>146</b> role incumbent indicating the change to Dormant <b>351</b> state. If the Project <b>127</b> aborts while an Informee <b>146</b> object of a Decision <b>100</b> is in Standby <b>353</b> state or Dormant <b>351</b> state, the Informee <b>146</b> object transits <b>356</b> or <b>357</b> respectively out of existence and sends a message to the Informee <b>146</b> role incumbent indicating the change. If the Project <b>127</b> completes while an Informee <b>146</b> object of a Decision <b>100</b> is in Standby <b>353</b> state, the Informee <b>146</b> object transits <b>355</b> out of existence and sends a message to the Informee <b>146</b> role incumbent indicating the change.

Table B indicates the concurrent states of the principal objects of the model (State=“None” before instantiation and after destruction of an object. State=“Dormant” after instantiation but before first use of an object. State=“Standby” pending possible need to iterate project prior to completion.). The vertical dimension is time, but is not to scale. Therefore the length of overlap is not significant. For example, the Directed Arc with an exit related to the decision will be active before the Decision can transit from “Dormant” to “Decision Release Pending” as indicated by the overlap of the Directed Arc's Active area and the Decision's Dormant area. However, the time of that overlap may be extremely short for some decisions and relatively long for others. States may be skipped or iterated (see the State Diagrams). Any horizontal line will cross possible concurrent states. Where a horizontal line can be drawn from a state on one object to multiple states of another object (e.g., Active state of Directed Arc (entry) to Dormant and Decision Release Pending states of Decision) all of the combinations are possible.

Functional Model

Project Instantiation. When a Project <b>127</b> is instantiated <b>128</b>, other objects are also instantiated as follows. Referring to <figref idrefs="DRAWINGS">FIG. 21</figref>, the Project Manager <b>700</b> identifies the concrete sub-class of the abstract Decision <b>100</b> class from which the initial decision <b>701</b> is to be instantiated. The initial decision <b>701</b> class is used to select <b>702</b> the required decision classes <b>703</b> and directed arc classes <b>704</b> from the Process <b>705</b> object. The selected classes are used to instantiate a Project <b>706</b> object and then to instantiate, as components of the Project <b>706</b> object, an instance of the identified Decision <b>100</b> sub-class together with an instance of every Decision <b>707</b> and Directed Arc <b>708</b> that is directly or indirectly dependent on the initial decision <b>701</b>. Instances of all the required Arc Exit Collection <b>709</b> objects and Arc Entry Collection <b>710</b> objects are also created within the Project <b>706</b> object.

Decision Role Instantiation. As depicted in <figref idrefs="DRAWINGS">FIG. 22</figref>, a Decision <b>720</b> object uses its decision <b>721</b> identification to select <b>722</b> the required decision role classes <b>723</b> and positions <b>724</b> from the Process <b>725</b> object. These are used to create an instance of each required Decision Role <b>726</b> participant as components of the Project <b>727</b> object.

Data Instantiation. <figref idrefs="DRAWINGS">FIG. 23</figref> depicts the instantiation of Data objects. A Decision <b>730</b> object provides its decision <b>731</b> identification which are used to select <b>734</b> the appropriate data class <b>735</b> from the Process <b>736</b> object. The Decision <b>730</b> object also furnishes the value of its data hold/release <b>732</b> attribute which is used to instantiate the Data <b>737</b> object with the hold/release value and state, as a component of the Project <b>738</b> object.

Project Iteration. During the course of a project, it may become necessary to revisit a decision that has already has already been made, inspected, approved and its released for use in other project decisions. Any decision instance that is in a non-dormant state is a potential candidate for iteration. When a decision is iterated the result may change and therefore, all decisions that use that result must also be iterated. Hence, decision iteration usually entails iteration of that portion of the project that is both active and “downstream” from the decision to be iterated. <figref idrefs="DRAWINGS">FIG. 24</figref> depicts the functional model of project iteration. The Project Manager <b>750</b> identifies the decision to be iterated <b>751</b>. The fist step <b>752</b> is to send a “pause” <b>753</b> message to the Project <b>754</b> object. Then The decisions <b>755</b> and directed arcs <b>756</b> are retrieved from the Project <b>754</b> object and those that are dependent on the decision to be iterated are selected. The state <b>759</b> of each of the previously selected decisions is retrieved from the Decision <b>758</b> objects and those which are in non-dormant state selected <b>760</b>. The identification of the selected decisions <b>763</b> together with the “iterate” <b>764</b> message is sent to the Decision <b>758</b>, Data <b>765</b> and Decision Role <b>766</b> objects. Finally, the project is resumed <b>767</b> by sending a “resume” <b>768</b> message to the Project <b>754</b> object.

While the present invention has been described with reference to a few specific embodiments, the description is illustrative of the invention and is not to be construed as limiting the invention. Various modifications may occur to those skilled in the art without departing from the spirit and scope of the invention as defined in the appended claims. For example, it would be natural to make the “data hold/release” toggle an attribute of the Data <b>101</b> object. However, the preferred embodiment defers the instantiation of Data <b>101</b> objects until they are required for entry of the Decision <b>100</b> result. It is desirable to be able to specify a hold on the release of the decision result at the time the Project <b>127</b> object is created. There are a variety of ways that this might be accomplished. The Data <b>101</b> object could be instantiated at Project <b>127</b> inception or all “data hold/release” attributes might be placed in an object instantiated for this purpose at Project <b>127</b> inception and pass them to Data <b>101</b> objects when the latter are instantiated. The preferred embodiment is to carry the “data hold” attribute value in the Decision <b>100</b> object, which is instantiated at Project <b>127</b> inception and pass it to the Data <b>101</b> object as the latter is instantiated.

A further example is the time chosen to instantiate the Inspector <b>145</b> and Approver <b>144</b> objects. Our preferred implementation instantiates them at the same time as the other Decision Role <b>121</b> objects on the expectation that there will be relatively few of them and that the model of their classes and relationships in the Process <b>129</b> model will be relatively stable. They could be implemented with a later instantiation, which would be preferred under circumstances other than those anticipated.

Nor are all the features of the implementation described here essential to the novelty or usefulness of the invention. For example, the ability to place holds selectively on the release of either decisions or their results is a feature that will probably be valued but need not be a part of the implementation. Similarly, the distinction made between the Inspector <b>145</b> and Approver <b>144</b> roles adds utility, but is not essential to the invention. These details of implementation are presented for their illustrative value and may be altered to accommodate the particular trade-offs of a specific application situation. They do not have any bearing on the scope or novelty of the present invention.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="308pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE A</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>DECISION ROLES AND RESPONSIBILITIES</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="91pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="126pt" align="left" /><tbody valign="top"><row><entry>ROLE</entry>&lt;entry /&gt;<entry>RESPONSIBLE</entry>&lt;entry /&gt;</row><row><entry>NAME</entry><entry>ROLE</entry><entry>TO . . .</entry><entry>RESPONSIBLE FOR . . .</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry>Decision</entry><entry>Manage the decision process,</entry><entry>The</entry><entry>Providing a timely, efficient and effective</entry></row><row><entry>Manager</entry><entry>make the decision and take</entry><entry>Organization</entry><entry>decision-making and implementation</entry></row><row>&lt;entry /&gt;<entry>responsibility for its</entry>&lt;entry /&gt;<entry>process.</entry></row><row>&lt;entry /&gt;<entry>implementation</entry><entry>Consultees</entry><entry>Providing an opportunity to influence the</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>decision before it is made.</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;<entry>Approvers</entry><entry>Submitting the decision for approval</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>after it has been made, but before any</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>commitment is made to implementation.</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;<entry>Informees</entry><entry>Providing timely notification of the</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>decision made, after it has been made.</entry></row><row><entry>Consultee</entry><entry>Provide expertise required to</entry><entry>The</entry><entry>Contributing expertise and resources</entry></row><row>&lt;entry /&gt;<entry>make a good decision or the</entry><entry>Organization</entry><entry>which will improve the decision of its</entry></row><row>&lt;entry /&gt;<entry>commitment of resources</entry>&lt;entry /&gt;<entry>implementation.</entry></row><row>&lt;entry /&gt;<entry>needed for its successful</entry><entry>Decision</entry><entry>Adhering to the decision process,</entry></row><row>&lt;entry /&gt;<entry>implementation. (Cannot</entry><entry>Manager</entry><entry>providing Decision Manager with relevant</entry></row><row>&lt;entry /&gt;<entry>veto.)</entry>&lt;entry /&gt;<entry>expertise, taking responsibility for</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>influencing and accepting the result when</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>the opportunity to influence has been</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>provided.</entry></row><row><entry>Approver</entry><entry>Prevent organizationally</entry><entry>The</entry><entry>Assuring that the Decision Manager has</entry></row><row>&lt;entry /&gt;<entry>intolerable outcomes that</entry><entry>Organization</entry><entry>not made a decision that favors parochial</entry></row><row>&lt;entry /&gt;<entry>might result from a decision</entry>&lt;entry /&gt;<entry>interests at the expense of the</entry></row><row>&lt;entry /&gt;<entry>made without the benefit of</entry>&lt;entry /&gt;<entry>organization's welfare or that will expose</entry></row><row>&lt;entry /&gt;<entry>expertise which is not</entry>&lt;entry /&gt;<entry>the organization to unacceptable risk.</entry></row><row>&lt;entry /&gt;<entry>otherwise available to the</entry><entry>Decision</entry><entry>Making the requirements for decision</entry></row><row>&lt;entry /&gt;<entry>Decision Manager, and assure</entry><entry>Manager</entry><entry>approval as clear and as specific as</entry></row><row>&lt;entry /&gt;<entry>that the decision has not been</entry>&lt;entry /&gt;<entry>possible, before the decision process</entry></row><row>&lt;entry /&gt;<entry>unduly influenced by the</entry>&lt;entry /&gt;<entry>begins, and providing timely notification</entry></row><row>&lt;entry /&gt;<entry>parochial interests of the</entry>&lt;entry /&gt;<entry>of approval or disapproval with the</entry></row><row>&lt;entry /&gt;<entry>Decision Manager to the</entry>&lt;entry /&gt;<entry>reasons for such disapproval.</entry></row><row>&lt;entry /&gt;<entry>detriment of the organization.</entry></row><row>&lt;entry /&gt;<entry>(Can veto.)</entry></row><row><entry>Inspector</entry><entry>Ensure that the result of the</entry><entry>The</entry><entry>Assuring that the decision result</entry></row><row>&lt;entry /&gt;<entry>decision conforms to the</entry><entry>Organization</entry><entry>conforms to all established specifications.</entry></row><row>&lt;entry /&gt;<entry>established specifications for</entry><entry>Decision</entry><entry>Assuring that the Decision Manager is</entry></row><row>&lt;entry /&gt;<entry>the decision result. (Can</entry><entry>Manager</entry><entry>aware of the result specifications before</entry></row><row>&lt;entry /&gt;<entry>reject.)</entry>&lt;entry /&gt;<entry>the decision is made and informing the</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Decision Manager of the inspection</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>results (including the reasons for any</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>failure to pass inspection) as soon as</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>possible after the decision has been made.</entry></row><row><entry>Informee</entry><entry>Make subsequent decisions</entry><entry>The</entry><entry>Making all subsequent decisions and</entry></row><row>&lt;entry /&gt;<entry>and perform subsequent tasks</entry><entry>Organization</entry><entry>performing all subsequent tasks in a</entry></row><row>&lt;entry /&gt;<entry>in a manner that is consistent</entry>&lt;entry /&gt;<entry>manner that is consistent with the</entry></row><row>&lt;entry /&gt;<entry>with it.</entry>&lt;entry /&gt;<entry>decision made.</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="413pt" align="center" /><thead><row><entry namest="1" nameend="1" rowsep="1">TABLE B</entry></row></thead><tbody valign="top"><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Object Concurrency</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="11"><colspec colname="1" colwidth="28pt" align="left" /><colspec colname="2" colwidth="35pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="42pt" align="left" /><colspec colname="6" colwidth="35pt" align="left" /><colspec colname="7" colwidth="42pt" align="left" /><colspec colname="8" colwidth="35pt" align="left" /><colspec colname="9" colwidth="35pt" align="left" /><colspec colname="10" colwidth="35pt" align="left" /><colspec colname="11" colwidth="42pt" align="left" /><tbody valign="top"><row>&lt;entry /&gt;&lt;entry /&gt;<entry>Directed Arc</entry>&lt;entry /&gt;<entry>Decision</entry>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Directed Arc</entry></row><row><entry>Object</entry><entry>Project</entry><entry>(Exit)</entry><entry>Decision</entry><entry>Manager</entry><entry>Consultee</entry><entry>Data</entry><entry>Inspector</entry><entry>Approver</entry><entry>Informee</entry><entry>(Entry)</entry></row><row><entry namest="1" nameend="11" align="center" rowsep="1" /></row><row><entry>State</entry>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;</row><row>&lt;entry /&gt;<entry>Active</entry><entry>Dormant</entry><entry>Dormant</entry>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Dormant</entry></row><row>&lt;entry /&gt;<entry>Paused or</entry><entry>Active</entry><entry>Decision</entry></row><row>&lt;entry /&gt;<entry>Suspended</entry>&lt;entry /&gt;<entry>Release</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Pending</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Prepare</entry><entry>Prepare</entry><entry>Dormant</entry>&lt;entry /&gt;<entry>Dormant</entry><entry>Dormant</entry><entry>Dormant</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Consulta-</entry><entry>Consulta-</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>tion</entry><entry>tion</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Consulta-</entry><entry>Consulta-</entry><entry>Consulta-</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>tion</entry><entry>tion</entry><entry>tion</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Deliberation</entry><entry>Deliberation</entry><entry>Standby</entry><entry>Entry</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Inspection</entry><entry>Standby</entry>&lt;entry /&gt;<entry>Pending</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Approval</entry>&lt;entry /&gt;&lt;entry /&gt;<entry>Inspection</entry><entry>Inspection</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Standby</entry>&lt;entry /&gt;&lt;entry /&gt;<entry>or Approval</entry><entry>Standby</entry><entry>Approval</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Data</entry>&lt;entry /&gt;<entry>Standby</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Release</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Pending</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Standby</entry>&lt;entry /&gt;&lt;entry /&gt;<entry>Standby</entry><entry>Active</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Operational</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>Historical</entry></row><row><entry namest="1" nameend="11" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>