Printer Friendly

Better decision making through expert systems for management.

Computers have been tools used in managerial decision making for over 30 years. Electronic Data Processing (EDP) systems appeared in the mid-1950s, and Management Information Systems (MIS) followed in the '60s. Office Automation Systems (OAS) was developed mainly in the '70s, and Decision Support Systems (DSS) was introduced in the '70s and carried over into the '80s. Perhaps the hottest computerized decision aid in the '80s, however, was Expert Systems for Management (ESM). Many organizations, private and public, have been developing ESM to help their managers make better decisions (See sources 1, 3, 11, 12, 14, 15, 17).

This article presents an overview of ESM by discussing the following areas: * Basic concepts of ESM. * Appropriate tasks for ESM. * Major benefits of ESM to management. * Major steps and special computer facilities involved in building an ESM. * Barriers to building a successful ESM and remedies. * Points to be considered when planning to build an ESM.

Basic Concepts of ESM

An ESM is a software system designed to mimic the way human experts make managerial decisions. As shown in Figure 1, Expert Systems for Management belong to one of the three branches of Artificial Intelligence (AI). Early expert systems performed mainly medical diagnoses and geological prospecting. With the growing number of successful applications of expert systems in these areas, AI specialists began to think that this technology might also be used to help management make and implement decisions.

The basic idea behind an ESM is simple. The expertise of a human is transferred to a computer. Then, based on this vast body of task-specific knowledge stored in the computer, the system is able to make certain inferences and arrive at a specific conclusion. Moreover, the ESM usually explains the logic behind its conclusion.

An ESM has four key components: a knowledge base, an inference engine, a justifier, and a user interface (Figure 2). The knowledge base is derived form the expert's information and experience in the field and consists of two types of knowledge[9]. The first type, the "facts of domain," is knowledge shared and agreed upon among practitioners. The second type, heuristic knowledge, is a set of rules that directs the use of knowledge in solving specific problems. In other words, it is knowledge based on the practice and judgment the human expert has acquired over years of experience.

The second component, the inference engine, is the "brain'" of the ESM. Essentially, it is a computer program that provides a methodology for reasoning and formulating conclusions.[17] Simply put, it interprets the information in the knowledge base.

The third component of an ESM is the justifier.[6] It explains the actions of the system to the user, answering questions about why a particular conclusion was reached and why alternatives were rejected. It presents the whole chain of the decision-making process and the rules that were used to reach the conclusion. The final component is the user interface. It is the "mouth" of the ESM and covers all aspects of communication between user and the system. It normally operates through a dialogue--the system asks the user questions relating to the task. A "HELP" utility is usually provided to assist the user when he does not understand the question being asked. The interface is critical, as it directly influences how well the system will be accepted. If the interface is poorly designed, employees will use the system reluctantly, or not at all.

Appropriate Tasks for ESM

Not all tasks are appropriate for ESM. Tasks requiring creativity, discovery or innovation are not suitable, nor are managerial problems demanding everyday language or common sense. Since these tasks require human intelligence, they are too hard for ESMs. At the other extreme, tasks like recording and calculating payroll and basic tax returns, keeping inventory or doing simple statistical regression analysis do not justify the use of ESM.

These are too easy and could be performed using conventional software. Figure 3 provides some examples of tasks appropriate for ESM.[18]

Major Benefits of ESM to Management

Researchers have listed more than a dozen potential benefits that ESM offer. (See sources 3, 10, 17, 19, 20.) Three primary advantages are discussed below. 1. Retaining Scarce Expertise As in Figure 3, ESM are especially appropriate when a company's expert employee is not always available and outside counsel is prohibitively expensive. Perhaps the expert is about to retire or he or she is required on too many occasions or in too many geographical locations. Developing an ESM which can capture this scarce expertise is a good way to maintain the competitive strength of the company. 2. Training new or junior staff The system can be used effectively as a training device. Novices can gain experience by working with the system, especially by studying its explanation of the decision-making process. The expert would then have more time to devote to other projects. 3. Increasing the Speed of Response and the Quality and Reliability of the Work An ESM can respond much faster than a human expert, especially when the work involves a large volume of data. It also can increase quality, since it provides consistent advice and reduces the error rate. It is reliable because it will not become tired or bored or emotional, will pay attention to all details, and will not overlook any relevant information or potential solutions.

In sum, ESMs can help organizations maintain or even increase their competitive strength.

How to Build An ESM

This section briefly discusses the major steps of building an ESM. Although managers do not need to know technical details about the construction of the knowledge base and inference engine, they should know the basic building process. Figure 4 summarizes the major steps.[6]

The first step is identification. Here, the expert and knowledge engineer work together to identify the problem area and define its scope. They agree on the system's objectives, determine the computer facilities needed, and set a time-frame for completion of the project.

During the second state, conceptualization, the expert and knowledge engineer discuss and determine the key concepts, data relationships and information-flow characteristics that describe the problem-solving process.

In the formulation stage, the expert and engineer develop a knowledge base using the key concepts and relationships. The knowledge engineer must select a programming language, and with the help of the expert, represent the basic concepts and relationships within the language's framework.

During the implementation stage, the knowledge engineer makes this formalized knowledge compatible with the information-flow outlined in Step 2. The resulting set of rules and associated control structure define a prototype program capable of being executed and tested.

The final stage, testing, involves evaluating the prototype program and revising it to conform to the standards of excellence defined by the expert.

These five steps outline the development of an ESM. An essential point, however, is that these processes are not clear-cut or independent. An ESM cannot be constructed until this prototype has been repeatedly tested and the system's design and objectives finalized.

Building the ESM

Rather than build the system from scratch, parts may be borrowed from previously-built ESM. ES shells are a kind of software designed for this purpose. In simple terms, ES "shells" are expert systems stripped of their knowledge component. Only the inference and explanation mechanisms are intact. Some well-known shells are EMYCIN, KEE, ART, GURU, EXSYS, M.1 and INSIGHT 2.

Other types of software are called "tools." Unlike shells, tools are more flexible (but less focused), and provide knowledge engineers with a rapid prototyping environment in which they can build shells or specific expert systems. Three major categories of software packages are usually classified as tools: programming languages, system-building aids and support facilities.[17]

Although an ESM can be built using traditional problem-oriented programming languages like FORTRAN, Pascal or C, specific AI or symbolic manipulation languages like Lisp and PROLOG are more frequently used. An advantage of these AI-oriented programming languages is that they can conveniently manipulate symbols and relationships. This is essential in constructing the knowledge base and inference engine. Both of these languages are available for micros and larger computers.

System-building aids can be used to assist in the design and knowledge acquisition. Examples are TIMM, ROGET and SEEK. Also, support facilities can make programming more productive. These include debugging aids, knowledge base editors, and input/output and explanation systems.

While an ESM can run on regular computers or dedicated AI workstations, dedicated systems are preferable. In dedicated systems, the hardware is more compatible with the language. For example, Lisp machines (AI dedicated) have processors whose machine codes are especially designed to obey instructions useful to Lisp. Regular computers do not have this kind of specialized hardware. Some commercial vendors are developing new architectural designs which will allow resource sharing, and enable dedicated AI workstations to be used for general purpose computing. The cost of building an ESM would thus be greatly reduced.

Barriers to Building a Successful ESM

There are various kinds of barriers which would prevent an organization from developing a successful ESM. Technical difficulties are often a problem but non-technical barriers pose an equally important challenge. This section presents four possible non-technical barriers which managers should consider when planning an ESM, and gives recommendations for overcoming each of them.

Four Possible Non-technical Barriers

1. The expert is not available, capable or co-operative.

An expert is the source of knowledge for the expert system. Tsotsos suggests that the expert must be very experienced and have in-depth knowledge of the task being modeled.[16] The organization may not have a qualified expert. Or the expert might not have time to devote to the development of an ESM.

An expert may be unskilled in communicating his personal knowledge, judgment, and experience or the methods used to apply these elements to the particular task. Although this person has enough experience and knowledge to help develop the expert system, his or her inability to communicate would be a major barrier to creating a successful ESM.

Another barrier relating to the expert would be his or her potential unwillingness to co-operate. Studies indicate that the expert may not be willing to co-operate because he or she thinks that the system would eventually replace him or her.[2] 2. The knowledge engineers are "too technical."

A report published in 1984 listed about 140 expert-system projects in the United States.[5] Since few of them were designed for business applications, one could assume that knowledge engineers previously did not have much experience in building business-related expert systems. Because of this technical background, they might not know how to pose questions to the task expert. Also, in cases where there is more than one task expert involved, the knowledge engineer might not know how to reconcile the experts' conflicting views. 3. Management is not supportive enough or does not know how to handle the organizational change arising from the implementation of the expert system.

Many managers have the misconception that their primary responsibility is to provide financial support needed to develop an ESM. This is a necessary, but not exclusive, requirement. Psychological or behavioral support is also important, especially when the development of an ESM is met with resistance.

Another barrier is that management may not understand or know how to handle changes in the organization caused by the use of an ESM. Managers' inappropriate actions may provoke greater resistance to the system. 4. The user does not like or trust the system, or trusts it too much.

Some people are afraid of computers. In their minds, an ESM is even harder to use.

Others do not like the system because they have not been included in the system's development, but they are asked to use the system.

Others do not trust the system or the people who developed the system. While they may like the concept of ESM, they are not receptive to that particular ESM. If the system made errors during the implementation stage, it could foster this type of resentment.

At the other extreme, users may trust the system too much. They treat it like a human, expecting it to learn from mistakes. Mistakes are perpetuated when users rely too heavily on an ESM.

Some Recommendations

The above barriers are not unbreakable, and Figure 5 suggests some ways to help eliminate them. The Expert

If the organization does not have a task expert, no ESM can be built. However, if the expert is on staff, but too busy, management could help by offering enough support and planning the project carefully. Perhaps job responsibilities could be reduced during the development period.

One possible way to overcome an expert's unwillingness to co-operate is to explain the advantages the system offers. The Knowledge Engineers

As more business-related expert systems are built, knowledge engineers will become better able to communicate. Until that time, a technical team, consisting of staff members from the EDP or OR department, could facilitate communication between knowledge engineers from outside the firm and the expert. Management

Management needs to clearly understand their role in the expert-system development project. They provide both financial and psychological support to the project team.

Hiring consultants to help implement the plan is recommended if management is inexperienced in handling organizational changes. The Users

The major reason people are afraid of computers is that they do not have enough knowledge or training. Providing adequate computer training is one way to help overcome this barrier. Also, if the ESM has a good user interface and is designed so that the user needs little training, this problem may be resolved.

Managers can avoid uncooperative users by carefully selecting staff members for the project team. They can prevent users from relying too heavily on the system giving them a clear concept of what the ESM can and cannot do.

Ten Points to be Considered When Planning an ESM

In summary, there are ten managerial issues to consider before a company begins an ESM project. 1. Does the organization have at least one

expert that it wants modelled? 2. Is that expert able to devote the time

required to develop the system? 3. Is the expert capable of communicating his

or her personal knowledge, judgment and

experience and the methods used to apply

these elements to the task? 4. Is the expert willing to cooperate? 5. Who should be involved in the system's

development? 6. How will the expert(s) be determined and

selected? Who will be the "leading" expert,

and how will different opinions be

reconciled? 7. To what extent does management commit to

the project? 8. Currently, how widely used are computers in

the company? Are potential ESM users

already accustomed to using computers? 9. Is the system going to be so large that it

would significantly affect present business

procedures? Does management have the

ability to handle the changes arising from

the project? 10. Finally and most important, is it necessary to

build an ESM now? Both the costs and

benefits should be estimated.


Expert Systems for Management (ESMs) are the latest computer technology to be applied to the business world. Hundreds of cases have shown that an ESM is an invaluable decision-making tool. However, managers need to be aware of and help resolve barriers to the system's implementation.


[1]Aeh, R. K., "Knowledge Systems in Business and

Industry," Journal of Systems Management, Vol. 39,

No. 11, 1988, pp. 7-9. [2]Bell, M. Z., "Why Expert Systems Fail," Journal of the

Operational Research Society, Vol. 36, No. 7, 1985,

pp. 613-619. [3]David, D. B., "Artificial Intelligence Goes to Work,"

High Technology, April 1987. [4]Enslow, B., "The Payoff from Expert Systems," Across

the Board, Jan/Feb 1989, pp. 24-28. [5]Frenkel, K. A., "Toward Automating Software-Development

Cycle," Communications of the ACM,

Vol. 28, No. 6, 1985, pp. 578-589. [6]Hayes-Roth, F., D. A. Waterman and D. B. Lenat eds.,

Building Expert Systems, Reading, Mass: Addison-Wesley,

1983. [7]Keen, P. G. W. and M. S. Scott-Morton, Decision

Support Systems: An Organizational Perspective,

Reading, Mass.: Addison-Wesley, 1978. [8]Liebowitz, J., "Misinformation Prolongs Expert

Systems Myths," Data Management, Nov. 1987, pp.

26-29. [9]Lin, E., "Expert Systems for Business Application:

Potentials and Limitations," Journal of Systems

Management, Vol. 37, No. 7, 1986, pp. 18-21. [10]Michaelsen, R. and D. Michie, "Expert Systems in

Business," Datamation, Nov. 1983, pp. 240-246. [11]Mockler, R. J., Knowledge-based Systems for

Management Decisions, Englewood Cliffs, NJ: Prentice-Hall,

1989. [12]O'Connor, D. E., "Using Expert Systems to Manage

Change and Complexity in Manufacturing," in W.

Reitman, ed., Artificial Intelligence Applications for

Business, Norwood, NJ: ABLEX, 1984. [13]Prerau, D. S., "Knowledge Acquisition in the

Development of a Large Expert System," AI Magazine, Vol. 8,

No. 2, 1987, pp. 43-51. [14]Shamoon, S., "The 'Expert' That Thinks Like an

Underwriter," Management Technology, Feb 1985. [15]Shim, J. K. and J. s. Rice, "Expert Systems

Applications to Managerial Accounting," Journal of Systems

Management, Vol. 39, No. 6, 1988, pp. 6-13. [16]Tsotsos, J. K., "Expert Systems Overview: Where Does

the Phase Fit?" CIPS Review, Sep/Oct 1985, pp. 12-14. [17]Turban, E., Decision Support and Expert Systems:

Managerial Perspectives, New York, NY: Macmillan,

1988. [18]Van Horn, M., Understanding Expert Systems,

Toronto: Bantam Books, 1986. [19]Watson, H. J. and R. I. Mann, "Expert Systems: Past,

Present and Future," Journal of Information Systems

Management, Fall 1988, pp. 39-46. [20]Wigg, K. W., "AI: Management's Newest Tool,"

Management Review, Aug. 1986, pp. 24-28. Patrick Chau is a PhD candidate at the University of Western Ontario's School of Business Administration.
COPYRIGHT 1991 Society for the Advancement of Management
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 1991 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Chau, Patrick Y.K.
Publication:SAM Advanced Management Journal
Date:Sep 22, 1991
Previous Article:Productivity improvement: changing values, beliefs and assumptions.
Next Article:Is your organization ready for telecommuting?

Related Articles
Using expert system technology to foster innovation.
Can your business use artificial intelligence?
The future of expert systems.
Beyond expert systems: neural networks in accounting.
The role of expert systems in improving the management of processes in total quality management organizations.
Artificial intelligence in accounting and business.

Terms of use | Privacy policy | Copyright © 2018 Farlex, Inc. | Feedback | For webmasters