FUTURE DIRECTIONS FOR DEVELOPING DECISION SUPPORT SYSTEMS

FUTURE DIRECTIONS FOR DEVELOPING DECISION SUPPORT SYSTEMS*

Robert H. Bonczek, Purdue University Clyde W. Holsapple, University of Illinois Andrew B. Whinston, Purdue University

ABSTRACT

A formal, generic description of decision support systems is introduced. This description views a decision support system as having three principal components: a language system, a knowledge system, and a problem processing system. Several systems that fit the generic decision support system idea, but are (for the most part) not the customary kinds of systems encountered in business applications, are described. The concepts and techniques employed in these systems can make important contributions to the emergence of more powerful business-oriented decision support systems.

Subject Areas: Decision Support Systems, Computer Applications, and Information Management.

INTRODUCTION

This presentation commences with a formal, generic description of decision support systems (DSS) which will guide the remainder of our study. This description stems from a decision-making framework [2] and from the classification scheme introduced in a companion paper [ 5 ] . The generic description views a decision support system as having three principal components: a language system (LS), a knowledge system (KS), and a problem-processing system (PPS). We pro- ceed to examine several computer-based systems that adhere to the generic DSS description. These various systems are addressed from the angle of identifying techniques and concepts that can be used to enhance present-day, business- oriented decision support systems such as those reviewed in the companion paper.

This earlier paper surveyed systems into which models are incorporated. Even though the descriptions of such systems in the literature typically pay but scant attention to the languages used to direct retrieval and computation, such languages were recognized in the Xerox case [17]. This served as the basis for a classification scheme that stressed the distinction between languages for retrieval and languages for directing computation.

The retrieval languages form a continuum ranging from procedural languages, where a user explicitly states how data is to be retrieved, to nonprocedural languages with which a user merely states what data is desired (rather than a procedure for obtaining it). Between the two extremes are those retrieval languages with which a user invokes one of a number of predefined report

*Research supported in part by Army Grant Number DA 79C0154. The authors are indebted to the referees for comments on an earlier draft.

616

19801 DECISION SUPPORT SYSTEMS 617

generators; such languages tend to be nonprocedural, but they are less flexible than languages at either extreme.

Languages for directing numerical computations also cover a range between two extremes. At one extreme are procedural languages with which a user explicitly specifies all computations. At the other extreme are nonprocedural languages wherein a user merely states the computational problem to be solved in terms of the data desired. No mention is made of the computations needed to produce the desired data. Between the two extremes are languages that enable a user to invoke a predefined model by name; such languages are relatively nonprocedural, but they are not as flexible as languages at either extreme.

Since retrieval languages can be utilized by either human users or by models, the continuum of retrieval languages can be placed at a right angle to the continuum of computational languages. The two axes intersect where the difference between the appearance of retrieval languages and the appearance of computational languages vanishes: where a user merely states the data desired. A nine- category DSS classification scheme is the result. Human elements of a decision- making system use the computational languages, although it is imaginable that computations of one mechanical decision support system could be directed by another mechanical decision support system.

Language System

We shall refer to a language system (LS) as the sum total of all linguistic fa- cilities made available to the decision maker by a decision support system (see Figure 1). A language system may encompass either or both retrieval languages and computational languages. A language system is not concerned with the interfacing of models and data. As indicated in [ 5 ] , a user’s interface language could be so designed that the user is unaware of whether he or she is directing a retrieval or a modeling process (e.g., categories G, H, I, or L in [ 5 ] ) .

A language system is characterized by the syntax that it furnishes to the decision maker and by the statements, commands, or expressions that it allows the user to make. Thus a language system is a vehicle that allows decision makers to express themselves while limiting the permissible expressions. We say that an LS is

FIGURE 1 Language System

Decision Support System

User 4-kl LS

61 8 DECISION SCIENCES [Vol. 11

User -=

a vehicle in that it is a mode of conveyance, not of material but of information. The language used by a decision support system in responding to a user may also be regarded as a part of the LS.

* 1 I

I I

I I I I

I about Problem Domoin Z- Language I I Know ledge

for Stating Problems

Knowledge System

Unless it contains some knowledge about the decision maker’s problem domain, a decision support system is likely to be of little practical value. Indeed, a good deal of the power of a decision support system derives from its knowledge- ability about a problem domain (e.g., banking). This knowledge typically in- cludes large volumes of facts that the decision maker has neither the time, inclina- tion, nor opportunity to absorb into his own memory. But certain subsets of this volume of facts are important to a reasonable or good decision in the face of a particular problem from the problem domain.

We shall refer to a decision support system’s body of knowledge about a problem domain as its knowledge system (KS). (See Figure 2.) In the systems described in [ 5 ] , the KS consisted of what were termed data files or data bases. In the original descriptions of such systems in the literature the precise nature of their knowledge systems typically is left unexplained. That they possess some sort of KS is unmistakable, and sometimes the kinds of data held in the K S are detailed. But the crucial issue of how these data are organized is left unaddressed, perhaps due to space limitations.

FIGURE 2 Language System and Knowledge System

Knowledge represented in a KS must be retained in an organized, systematic manner. There are a variety of knowledge representation methods [3] [22]. The knowledge representation method utilized by a particular knowledge system may be thought of as a set of rules according to which knowledge is expressed for pur- poses of retention within the decision support system.

Problem-Processing System

The main function of a decision support system is to take strings of symbols organized according to language system syntax (problems) and strings of symbols


organized according to knowledge system representation rules (problem domain knowledge) and to produce information that supports (enhances or makes possible) a decision process. To do so there must be a mediating mechanism between expressions of knowledge in the KS and expressions of problems in the LS. We refer to this mediating mechanism as the problem processor or the problem- processing system (PPS). It is the PPS that has one or more of the seven abilities [2] required for decision making. A detailed representation of the generic description of decision support systems appears in Figure 3, where some of the PPS’s potential abilities are specified.

FIGURE 3 Generic DSS

Use

s

PPS c - KS I n f ormot ion Col I ect ion

Model Formulation Prob I em Recognition A n a l y s i s

LS -- - -- - - - ---- - - - - - -----

i etc. I A n a l v s i s I I eic. I 1 1

I Response I

Decision Support Systems: Human and Computer

Referring to Figure 3, a close analogy can be drawn between a computer- based decision support system and a human-based decision support system. The former is implemented with a computer whereas the latter is implemented with staff personnel or human consultants. In each instance, however, the decision support system must contain an LS, KS, and PPS.

In the computer-based case the PPS is computer software. The PPS in the human-based case consists of the mental skills of staff (“human software”). If decision support is to be provided, the software must be able to understand the decision maker’s requests as stated in some language, and it must be able to ex- tract pertinent information from some available pool of knowledge about the problem domain. The function of the software (be it human or computer) is to interface these two so as to produce an answer to the problem posed by a decision maker.

In some systems interfacing software may be simple, whereas it may be quite complex in others. On another dimension some software may be able to accept statements of problems in many languages; other PPSs may be more specialized, accepting statements in one language only. On yet another dimension, some software interfaces are specially constructed to access knowledge of one problem domain only. Other PPSs have knowledge of many problem domains (i.e., they can interface with many knowledge systems). On still another dimension, some

620 DECISION SCIENCES [Vol. 11

problem-processing systems may have models embedded within them (e.g., Pot- latch and Banking System in [ S ] ) . Other PPSs may be separated from modules that are stored in the KS, but the PPS “knows” how to use these to formulate models. This latter kind of PPS is along the lines of Simon’s “general strategies” discussed in [ 191.

In both computer-based and human-based decision support systems there is wide variation in the nature of the language used to direct the decision support system. In some decision support systems of each type there is the possibility of the PPS misunderstanding the intention that the decision maker is endeavoring to convey through the available language system. Decision support systems of each genre have interactive language systems. That is, the decision support system’s PPS is permitted to query the decision maker for further information in order to clarify what it recognizes as ambiguity in the decision maker’s initial statements. Thus in a decision support system of this type, communication via the language system is not a one-way avenue. Rather, the language system is a two-way avenue through which the decision maker and the PPS can interact.

THE SHAPE OF SYSTEMS TO COME

Although most were not developed with business applications in mind, the systems described in the remainder of this paper do fit the generic DSS pattern displayed in Figure 3. (As an exercise the reader can verify that the systems reviewed in [ 5 ] also fit the pattern.) The systems presented here have certain novel features not encountered in typical business-oriented systems. The descriptions given here are intended to provide overviews.

The first system discussed was specifically devised to aid managers in the model formulation activity. The next three systems have been drawn from the artificial intelligence literature. Some fairly general ideas on problem solving have been developed in the field of artificial intelligence. Since the ideas of this disci- pline are oriented towards solving semistructured or unstructured problems, it is useful to explore the basic concepts with an eye to their possible applications in the decision support field.

The artificial intelligence systems are often characterized as being theorem- proving systems. Use of the term “theorem proving” does not necessarily con- note proving theorems in mathematics. It is used in a broad sense that may be in- terpreted variously not only as a theorem to be proven but also as a goal to be achieved, a problem to be solved, or a query to be answered.

Finally, there is a description of a decision support system that is more general than the systems reviewed in [ 5 ] . That is, the system can be tailored to treat different problem domains such as banking, project management, corporate planning, etc.

The IBM Business Definition Language

Here we examine a system for supporting business decisions which is ap- proached from the angle of a language [ 101. The language has been designed to

19801 DECISION SUPPOR T S YSTEMS 62 1

provide business people with a means for stating their problems and how they are to be solved. This Business Definition Language (BDL) deals with four kinds of elements: documents, steps, paths, and files.

A document is a collection of data values organized according to some form. An example of a form is an invoice form (with no data values filled in). A particular group of data values properly written into the invoice form is an invoice document.

A step is a procedure that converts some input documents into some output documents. An irreducible step may be viewed as an operator that is directly available to the user of BDL. Paths connect steps by indicating that output documents of one step are input documents to another step.

The BDL user commences by stating the types of output documents that must be produced from a particular collection of input documents. The user must eventually specify an algorithm (program) for accomplishing this, in terms of paths connecting irreducible steps. The resultant program is a composite step in that it is composed of more primitive steps. A description of how the program construction process is interactively guided by a series of reductions that break composite steps into more primitive steps, until all primitive steps are irreducible, is contained in [lo].

The BDL approach to directing computations differs from that of systems reviewed in [5]; in those systems the user either called for a model (Potlatch) or specified a sequence of models (Xerox). The language system of the BDL is more procedural but more flexible than the language system of Potlatch or Xerox. I t falls nearer to the top of the classification matrix [5 ] than do Potlatch or Xerox. As with these systems, the BDL problem-processing system contains models (i.e., irreducible steps or modules). The BDL knowledge system consists of files.

Input documents to a BDL program may be directly provided by the BDL user, or they may be extracted fromfiles. A file is composed of documents of a single form which are more or less permanently maintained.

BDL has been described [lo] as having three major “components.” These are the Form Definition Component (FDC), the Document Flow Component (DFC), and the Document Transformation Component (DTC). The FDC specifies the forms of documents that can be used in the BDL program. The DFC is used to specify the BDL program in terms of paths and steps. Irreducible steps are programmed using a language contained in the DTC.

BDL is being developed in order to reduce the cost of labor-intensive application software. The user of BDL is interactively guided through a process of program (model) construction beginning with a composite step and eventuating in a sequence of irreducible steps. (The issues of branching and iteration in a resultant program are not dealt with in [lo]. Branching and iteration do, however, occur within irreducible steps, and the irreducible steps are possibly complex programs.) The thrust of the BDL development is directed towards easing the tasks of writing programs in a business problem domain.


PLANNER

One of the most prominent theorem-proving systems is PLANNER [21], which is under continuing development. In general, a theorem-proving system consists of the following: (1) some language for stating the theorem to be proven (LS); (2) some collection of axioms, assertions, or formulas embodying knowledge about a problem domain with which the system is concerned (KS); and (3) a theorem prover (PPS) that utilizes principles of logic to endeavor to deduce a stated theorem from problem domain knowledge.

A major point of variation among theorem-proving systems is the method for handling knowledge about how to perform the deduction involved in a particular proof, i.e., knowledge beyond those general principles of logic that are applicable to any proof. This “reasoning” knowledge is not to be confused with the problem domain knowledge mentioned in the preceding paragraph, since the former is knowledge about how to use the latter.

As the problem domain knowledge becomes large, the exclusive use of general deduction principles to prove a theorem tends to bog down due to blind ex- amination of the possibly large number of plausible proof procedures for a given theorem; many false starts are involved. Indeed, this was the source of some dis- couragement with the practicality of the theorem-proving field circa 1970 [20]. One remedy is to incorporate into a theorem-proving system more specialized reasoning knowledge, i.e., special deductive principles that are applicable to a certain problem domain, to a certain type of theorem, or even to particular theorems themselves.

This specialized reasoning knowledge could be embedded directly into the theorem prover (PPS) as a set of heuristics. Another conceivable approach would involve the storage of this knowledge in the form of rules (in the KS) that would be accessible to the theorem prover for use in governing the deduction process. The PLANNER approach is to have the system’s user state this specialized reasoning knowledge (in the LS) simultaneously with stating (actually, as a part of) the theorem to be proven. The philosophy underlying the PLANNER approach is that at the time of stating a theorem to be proven, the user also has some notion about how to carry out the deduction. Thus in the PLANNER language a theorem is really a program for guiding the deduction process giving the user con- trol over how to prove the theorem (i.e., how to use the problem domain knowledge vis a vis the theorem).

The primary problem domain in which PLANNER has been applied consists of a world of blocks of various colors, sizes, shapes, and locations which is inhab- ited by a robot that can act upon those blocks. Questions or “theorems” posed by a user can request information about the block world; this is obtained either directly from the problem domain knowledge, or it is deduced (inferred) from that knowledge (see Category J in [S]). A second type of question, problem, or “theorem” can request a change in the state of the block world. This entails a deduction of whether the requested change is possible, given the current state of the block world and given the actions that the robot can carry out; these two


Decision Maker A

“givens” are included in the system’s problem domain knowledge. A proof of this second type of theorem results in the execution of robot actions.

Although this PLANNER application is not oriented towards the direction or execution of computations of interest to managers, the execution of robot actions in response to a user’s problem is in a similar vein. That is, each involves a plan, but the plans are of different natures. One is a plan of computational analysis (i.e., a model) which, when executed, results in some data (refer to abilities I11 and V in [2]). The other is a plan of implementation which, when carried out, results in some change in a “world” that can be manipulated by the theorem- proving system (refer to abilities I11 and VII in [2]). This contrast is depicted in Figure 4. (Recall that PLANNER can also supply data to the user via inferential retrieval, as discussed earlier.) Finally, the architecture in Figure 4 could be al- tered to allow the decision maker to either approve or disapprove of the implementation plan devised by the theorem prover prior to its execution.

I I I I I I - LS 4--k PPS 7 KS I I I

FIGURE 4 Decision Support Versus Implementation

a. System Oriented Towards Analysis to Support a Decision

Prover Decision Maker

instructions to implement decision

‘world’

b. System Oriented Towards Implementation of a Decision


The GPS Approach and STRIPS

A fairly general and abstract approach to problem solving has been developed by Simon [18]. This approach appears in the guise of the General Problem Solver (GPS). The GPS concepts can be easily outlined, although applying them to give an operational system can be quite complicated.

GPS is concerned with three basic elements: states, operators, and goals. A state is simply a situation. Operators permit us to move from one state to another state, to transform one situation into another situation. A goal is a desired state. A problem is described in terms of an existing initial state and a goal.

The GPS concept of problem solving is characterized as selecting a series of operators that will successively move the problem from its initial state through in- termediate states to the goal state. Given any state, it is assumed that a difference can be determined between that state and the goal state. Operators are selected to reduce the difference between the current state and the goal state. Not all operators can be selected, however, since for a given state the set of applicable operators is a subset of the set of all operators. If, for example, the current state has a salesman in Chicago, then the operator “fly from New York to Albany” is not applicable.

One interesting aspect of the GPS approach is that it can be used recursively. To explain this, suppose that we are in a particular state (e.g., in Chicago) and when calculating the difference with the goal state (e.g., in Albany) we notice that a particular operator (e.g., fly from New York to Albany) if applied, would sub- stantially reduce or eliminate the difference. To use this particular operator we need to be in a certain state (e.g., in New York) other than that in which we are at present. Thus, we could set up a new goal (e.g., in New York) which would be to achieve a particular state that would allow the application of the selected operator (e.g., fly from New York to Albany). For the solution of this new problem (e.g., initial state: in Chicago, goal state: in New York) we can reapply the GPS approach. If a solution were found (e.g., fly from Chicago to New York), then we can return to solving our original problem. During the course of solving our new problem we may have again had recourse to using GPS in such a recursive fashion (e.g., f ly from Chicago to Cleveland, and then fly from Cleveland to New York).

A description of an implemention of the GPS approach and its use in solving a number of problems ranging from the cannibaVmissionary problem to sym- bolic integration appears in [7]. For comments on the relationship of the GPS approach to human problem solving see [ 131. The GPS approach involves several of the decision-making abilities presented in [2]. These include the collection of information about states and the formulation of models (sequences of operators) as a result of recursively recognizing problems.

The emphasis in GPS is therefore upon the use of the means-end (operators- goal) approach and recursive problem solving in order to automatically determine a method of solution. The principal outputs of systems such as those reviewed in [ 5 ] are reports such as income statements or sales forecasts. The principal outputs of systems developed in the spirit of GPS are solution methods in terms of operator sequences.

DECISION SUPPORT SYSTEMS 625

Now, suppose that we use the term “state” in the sense of a state of information (e.g., economic assumptions), and we take operators to be modules (e.g., re- gression, simulations, etc.). A module enables us to move from one information state (input) to another state (output). If our goal state is one of having a sales forecast, then a GPS approach would yield a sequence of operators (a model) that enables us to arrive at that goal. Incorporation of the GPS approach into a decision support system would therefore go a step beyond the BDL system in which the user sequences the operators. Techniques for incorporating a GPS-like approach into a system that also executes the sequence of operators are currently being investigated [4].

One implementation of a problem-solving system based on the GPS ideas was developed at Stanford Research Institute [8] and named STRIPS (Stanford Research Institute Problem Solver). Since the implementation was based on using predicate calculus and theorem proving, we do not examine STRIPS’S details here. We can, however, sketch out some of its main ideas in the context of our GPS discussion.

The STRIPS problem domain consists of a robot that must rearrange objects, navigate through rooms, etc. A state for the robot problem solver consists of a large number of facts about positions of the robot and objects, about the characteristics of the objects, and about walls and openings in the rooms that the robot can inhabit. Each STRIPS operator has a corresponding “action routine’’ which, when executed, causes the robot to take a certain action. Problem solving consists of finding a sequence of operators that will transform an initial state into a goal state.

In STRIPS, there are three lists of information associated with any operator. A prerequisite Iist specifies what must be true about a state before the operator can be applied. The delete and add lists specify the changes to make in the current state if the operator is applied, i.e., the facts that should be added and those that should be deleted.

The language system in STRIPS allows for the specification of goal states. Although the language used is predicate calculus, its statements can be para- phrased into English. An example is “Get boxes B and C to location A.” The STRIPS knowledge system consists of a description of the current state of the robot world. These facts are also represented in terms of the predicate calculus.

The problem processing system in STRIPS finds (if possible) a sequence of operators that permits the goal to be met. The PPS uses theorem-proving techniques to determine whether a goal is met by the current state. If it is, then no operator sequence needs to be determined. If it is not, then the GPS notion of “differences” is used, along with the previously mentioned operator lists, to se- lect an operator that would give a new current state that is “closer” to the goal. The PPS then once again uses theorem-proving techniques to determine whether the goal is met by the new current state. This process continues until a sequence of operators has been found that gives a state that can be proven to meet the goal.

Heuristic intricacies involved in the selection of operators appear in [8]. This can be contrasted with PLANNER, wherein determination of a sequence of robot


actions is guided by the user via the PLANNER LS. It can be further contrasted with the BDL approach of the user being guided by the system in eventually speci- fying a sequence of irreducible steps.

MYCIN

A very specific and apparently successful consultation system called MYCIN [6] is intended to help physicians diagnose and decide upon treatments for infec- tious diseases. Given an initial set of symptoms and basic information on the patient, the system acts as a consultant by requesting what it considers to be pertinent data about the patient, such as results of certain laboratory tests. The ac- quisition of each new bit of data about a patient serves to influence the next piece of data that the “consultant” requests from the physician. In this way a selective “data base” is gradually built.

The patient-specific “data base,” along with some knowledge about infections, allows the MYCIN system to suggest certain possible diagnoses and therapies, each with a likelihood factor. The physician is aided in the search for a diagnosis by the system’s suggestions and by the physician’s ability to request reasons for the proposed diagnosis. User interaction with MYCIN is via an English-like interface which significantly enhances its usability.

Although the features of MYCIN differ somewhat from those of the previously discussed systems, it too fits the generic description of a DSS. A consultation session is initiated by the user, but it is perpetuated and guided by MYCIN, Thus, MYCIN’s information collection from a user via the LS is instigated by MYCIN’s PPS (see [6] for examples of this). In contrast to the previously described systems, MYCIN’s LS is quite English-like in appearance. The user, however, is largely restricted to asking only one kind of question: namely, “What is the diagnosis and therapy?”

The PPS endeavors to condition this query by building a patient-specific “data base” as described earlier so that the query begins to look like “What is the diagnosis and therapyfor patient A having history B, symptoms C, D, and E, lab test results F and G, etc.?” This interactive conditioning process may be characterized as the problem-recognition ability of MYCIN’s PPS [2].

The exercise of this ability depends upon facts about infections which are maintained in MYCIN’s knowledge system. During the interactive conditioning of a user’s query, the next bit of data to be collected from a user (to further define or condition the problem) depends upon information already collected from the user (LS) and from the KS. The patient-specific “data base” that results from interactive problem recognition may be considered either as information internally held within the PPS or as a short-term part of the KS which is filled in as data are collected from a user.

The KS holds long-term (yet modifiable) knowledge concerning infections which exists across many consultation sessions. The patient-specific information, which the MYCIN authors call a “data base,” exists only for the consultation session involving that specific patient. A new patient demands a new patient-


specific “data base.” In this sense, a MYCIN “data base” is analogous to the in- ternal representation of a particular query in systems such as those reviewed in [5]. Both are comparatively ephemeral.

It is instructive to contrast the MYCIN handling of patient information against another conceivable approach, one that would store all patient information in the KS on a long-term basis. Where the potential patient population is large, the MYCIN approach is clearly superior since there would be too much data that are used too infrequently (and which are too volatile) to permit feasible long-term storage. The MYCIN approach is entirely consistent with the way in which the decision support systems of [5] handle very short-term information. Examples of such short-term information include the assumptions under which a sales forecasting model should be executed. We may want to execute the model assuming a 5 percent economic growth factor, and a moment later we may want to try a 7 percent factor. Just as it is not practical to store all patient data on a long-term basis, it is not practical to store all potentially interesting growth fac- tors on a long-term basis. On the contrary, such data are supplied by the user as needed through the system’s LS.

Even though MYCIN cannot quite be characterized as permitting computational management (recall the matrix of [5]), its approach to decision support has much to offer in terms of ideas for DSS development in business settings. MYCIN lies in Category L of [5], and its inferential retrieval is based upon Post’s production system [ 151. The notion of diagnosis and treatment of human patients can be extended to business firms. This expanded perspective would see corporate planners as “physicians” endeavoring to diagnose and recommend therapies for a firm’s “ills.” An interesting issue for research is the extent to which the MYCIN principles can be applied to situations where the patient is a business firm. This would necessitate a KS that deals, not with medical knowledge, but with knowledge about the anatomy, testing procedures, afflictions, and treatments for a business firm.

GPLAN

The Generalized Planning System (GPLAN), developed at Purdue Univer- sity [ 1 11, is more general than the systems reviewed in [5] in terms of the problem domains it can handle. GPLAN can be tailored to support decision makers in any of a variety of areas (e.g., inventory management [l] and water quality planning [ 121). Besides generality, there were other intentions for GPLAN: an easy-to-use language system, a flexible knowledge system, and a problem-processing system that could automatically interface a model with some data in the KS to perform a desired analysis.

The language system was designed for use by persons that are not program- mers. It is English-like in appearance, and with it a user can direct both data retrieval and computation nonprocedurally. When used for data retrieval, GPLAN falls into Category L (see [ 5 ] ) . When used for directing computations, the system as currently implemented falls into Category E (see [5]). That is, models are


invoked by name, and they obtain needed data from the KS by invoking special report generators.

Part of the system’s generality derives from the fact that the LS syntax re- mains the same, regardless of the problem domain. The syntax is:

<COMMAND > < FIND CLAUSE > <CONDITIONAL CLAUSE >

The vocabulary does change from one problem domain to another (see [l] and [12], for example). But since the GPLAN problem processor handles user statements using syntax-directed compilation techniques, vocabulary changes do not drastically affect the PPS.

In contrast, changes in the models to be used do affect the PPS in several ways. First of all, the models are treated as part of the PPS. So a change in problem domain from inventory management to water quality planning would cause the deletion of inventory management algorithms and the inclusion of water quality simulation models. Other models remain in the PPS regardless of the problem domain. These are statistical models, of the sort found in SPSS [14], that have wide applicability.

The incorporation of a new model into the system affects the LS vocabulary by adding a new command (e.g., RUN WATER SIMULATION), and it necessi- tates other changes in the PPS, such as the possible inclusion of additional report generators and checks to assure that the user’s CONDITIONAL CLAUSE fully specifies the assumptions (if any) under which the model is to be executed. Thus, the modeling aspect of GPLAN is its least general ability. This can be overcome as described in [4].

A final, quite general aspect of the system is its ability to gather information from the KS (which is a type of data base). The PPS is unaffected by the problem domain or the way in which problem domain knowledge is organized in the KS, having the ability to produce practically any subset of the data contained in the KS. In [3] it is shown how to extend the power of data bases for representing knowledge.

RATIONALE FOR THE STUDY OF A GENERALIZED PROBLEM PROCESSOR

The systems surveyed in this and its companion paper [ 5 ] serve to portray many of the major features and issues pertaining to decision support systems. The concepts and techniques on which these systems are founded furnish several of the tools needed for the development of a general PPS: that is, a single, in- variant mechanism whose code does not change with the problem domains that it supports. This implies that such a processor, while possessing various abilities involved in decision making, must be separated from anything that is domain specific. The design of such a processor is the subject of current research.

I t is appropriate at this juncture to pause for a consideration of the ad- vantages of such a generalized problem processor vis a vis domain-specific


processors. Perhaps the most significant attributes of the generalized approach is the conceptual framework that it affords. This is particularly important from the pedagogical standpoint. Given a knowledge of the general system, one is in a much better position to comprehend and derive specialized systems than would be the case in the absence of such knowledge. Possession of this knowledge furnishes a basis for systematic comparison, contrast, and discourse regarding special cases.

We do not mean to suggest that specialists be deterred from their lines of in- vestigation and development. Indeed, the specialist is quick to point out that with respect to execution and storage a specialized system is almost invariably more efficient than a general system. But, the price for greater operational efficiency is the forfeit of some degree of flexibility. Where efficiency is paramount it may be simpler or less costly (more efficient?) to constrain an existing general system to conform with some standard of operational efficiency than to devise a special system from scratch. In this connection, the tradeoff between development costs (which continually rise due to the high labor component) and execution plus storage costs (which continue their dramatic decrease) must not be ignored.

As a topic for research (and as a managerial strategy) there is a good deal to be said for concentrating on how to improve responses to needs over time under changing conditions. In the long run this may be more fruitful than devotion to augmenting one’s capabilities for finding solutions that are optimal at a given moment in time. This would imply a need for flexible systems that can easily adapt to what has been learned and to current needs. One is faced with two distinct courses of action: (1) investment of resources in a system that is optimal until conditions change, causing deterioration or incapacity; or (2) investment in a system that is not optimal (that can be mass produced and that is probably less ex- pensive), but that can be readily modified (and perhaps improved) when conditions change.

Furthermore, in an environment where numerous, diverse specialized systems are derived from the general system, there is an advantage of relative ease in understanding each since all have been based on the same general principles. This is contrasted with situations wherein one must learn several entirely distinct systems that are not derived from a common root. A further asset acquired from the study of a general system is its potential for engendering insights that allow what is known in one system to be translated to others.

The notions of machine software and “human software’’ were compared in an earlier section. Interestingly, this comparison can be continued with respect to the question of generalization versus specialization. So-called idiot savants studied by psychologists are persons capable of performing particular mental feats far beyond the capacity of normal humans but unable to carry on simple conversations or perform ordinary jobs [9]. The unusual mental feats performed by these persons, whose IQs fall in the range of 40 to 80, involve memory and prodigious calculations that surpass the abilities of the most brilliant people [ 161, The savant’s “software” appears to be extremely specialized and capable of such extreme concentration on a particular problem domain that the mental

630 DECISION SCIENCES [Vol. I1

“software” is not available for the wide range of problem domains addressed by more normal persons [16]. It is left to the reader to elaborate upon the interesting parallel between human and machine software with regard to the specialization versus generalization issue.

CONCLUSION

The paper began with a generic description of decision support systems that was based upon the frameworks, surveys, and classification schemes of earlier papers [2] [ 5 ] . The generic description holds that a decision support system has knowledge about a problem domain (a KS) and can accept stated problems (an LS). In order to solve a stated problem using problem-domain knowledge, there must be a PPS that possesses some of the seven abilities [2] involved in decision making.

Several systems that fit the generic DSS idea but are not the customary kinds of systems encountered in business applications were described. The distinguish- ing features of each were noted. It is of interest to speculate about why systems such as MYCIN are not found in business settings. The ideas and features of such systems certainly look attractive, but in viewing management systems [S] there is nothing at this level.

This is, in part, due to the newness of systems such as those described in this paper. It is also due to the origins of such systems. PLANNER, STRIPS, and MYCIN were developed by workers in the artificial intelligence field which until recently has dealt mainly with toy problems. Furthermore, workers in the field typically do not have business backgrounds. In contrast, designers of systems such as those reviewed in [S] come predominately from a data-base management-management information systems (DBM-MIS) background. The potential application of artificial intelligence techniques in conjunction with DBM-MIS techniques has yet to be widely recognized or investigated in the DBM-MIS field.

This presentation is an initial effort at remedying this situation. Research ef- forts directed towards the design of decision support systems that are built upon features and techniques from both traditions deserve support. Moreover, an in- vestigation of some degree of generality that goes beyond such systems as GPLAN, is important from both a pedagogical and a practical standpoint. For implementers or buyers of decision support systems, the question of precisely what level of generality is appropriate is neither a trivial problem nor a problem that has been solved. Nevertheless, an understanding of a quite general system should alert these persons to the various levels of generality that are possible, and it should furnish a repertoire of features and techniques that can be used to attain the desired degree of generality. [Received: January 2, 1980. Accepted: May 6, 1980.1

REFERENCES

[I] Bonczek, R. H., Holsapple. C. W., and Whinston. A. B. Aiding decision makers with a generalized data base management system. Decision Sciences, 1978, 9, 228-245.

19801 DECISION SUPPORT SYSTEMS 63 1

Bonczek, R. H., Holsapple, C. W., & Whinston. A. B. Computer based support of organiza- tional decision making. Decision Sciences. 1979, 10, 268-291. Bonczek, R. H., Holsapple, C. W., & Whinston. A. B. The integration of data base management and problem resolution. Information Systems, 1979, 4(2), 143-154. Bonczek, R. H., Holsapple, C. W., & Whinston, A. B. Representing modeling knowledge with first order predicate calculus. Manuscript submitted for publication, 1979. Bonczek, R. H., Holsapple. C. W.. & Whinston. A. B. The evolving roles of models in decision support systems. Decision Sciences, 1980, 11, 337-356. Davis, R., Buchanan, B., & Shortliffe, E. Production rules as a representation for a knowledge- based consultation program. Artflcial Intelligence. 1977, 8, 15-45. Ernst, G. W., & Newell, A. GPS: A case study in generality andproblem solving. New York: Academic Press, 1969. Fikes, R. E., & Nilsson, N. J. STRIPS: A new approach to the application of theorem proving to problem solving. Artificial Intelligence, 1971,2, 189-208. Goldenson, R. M. Encyclopedia of human behavior (Vol. 1). Garden City, N.Y.: Doubleday, 1970. Hammer, M. A very high level programming language for data processing applications. Com- munication of the ACM. 1917. 20, 832-840. Haseman, W. D., & Whinston, A. B. Introduction to data management. Homewood, I l l . : Irwin, 1977. Holsapple, C. W., & Whinston, A. B. A decision support system for area-wide water quality planning. Socio-Economic Planning Sciences, 1976, 10, 265-273. Newell, A., & Simon. H. A. Human problem solving. Englewood Cliffs, N.J.: Prentice-Hall. 1972. Nie, N. H., Hull, C. H., Jenkins, J. G., Steinbrenner. K., & Bent, D. H. Statisticalpackage for the social sciences (2nd ed.). New York: McGraw-Hill, 1975. Post, E. Formal reductions of the general combinatorial problem. American Journal of Mathe- matics, 1943, 65, 197-234. Rimland. B. The autistic savant. Psychology Today, 1978, 12(3), 68-80. Seaberg, R. A., & Seaberg, C. Computer based decision systems in Xerox corporate planning. Management Science, 1973,20, 575-584. Simon, H. A. The heuristic compiler. In H. A. Simon and L. Siklossy (Eds.), Representation and meaning. Englewood Cliffs, N. J.: Prentice-Hall. 1972. Simon, H. A. The new science of management decision. New York: Harper & Brothers, 1960. Van Emden, M. H. Programming with resolution logic. In E. W. Elcock and D. Michie (Eds.), Machine intelligence (Vol. 8). New York: Halsted Press, 1977. Winograd, T. Understanding natural language. New York: Academic Press, 1972. Wong, H. K. T., & Mylopoulos. J. Two viewsofdata semantics. Unpublished manuscript, Uni- versity of Toronto, 1976.

FUTURE DIRECTIONS FOR DEVELOPING DECISION SUPPORT SYSTEMS

Documents

Transcript of FUTURE DIRECTIONS FOR DEVELOPING DECISION SUPPORT SYSTEMS