The JTEC panel's questionnaire asked about perceived obstacles to the introduction or proliferation of ESs in the organizations we surveyed. The following problems were reported, primarily by the JCMs, but also by many of the other companies:

Knowledge Acquisition

Several problems associated with knowledge acquisition were reported:

  1. Domain knowledge is hard to extract from domain-knowledgeable people.
  2. There are not enough tools available.
  3. There has been little success so far with domain shells. These shells are designed to allow domain experts to construct their own KBSs. Nikkei AI said that customers told them they found the products either too general (and therefore hard to use) or too specific (and still needing programming experts to customize).

Knowledge Maintenance

Knowledge changes often in the real world, hence the KBS needs constant updating. JAL, for example, uses two to three electronic data processing (EDP) people full time to change their crew scheduling program. Union rule changes, regulation changes, sickness, etc., all contribute to the need to reschedule frequently. The same problem would also arise if the applications were done with conventional data processing techniques, but it does tend to show that the use of KBS technology does not save on software maintenance.

Lack of Transferability

NKK found it hard to transfer a KBS application from one steel mill to another. They found that a few lines of a rule-based program were not difficult to understand, but the intent of the overall program was. Hence, they found that although the KB was locally understandable, the global knowledge was hard to discern.

Little Reuse of Knowledge

Every KBS application needs to be done ab initio. This is a well-known limitation of first-generation knowledge-based systems.

No CASE Methodology

There are no well established standards for creating a KBS. Techniques for testing a KBS to determine its scope of applicability are also not well established.

Expected Programmer Productivity

NKK commented that it found little evidence of an increase in programmer productivity over writing conventional data processing programs. Also the Nth application was not easier to do than the first. The main problem here may be that expectations raised by KBS technology were not met.

High Cost of Producing User Interface

Fujitsu found that 60 to 70 percent of the development cost of a KBS was spent on coding the user interface; other companies reported similar numbers.

Poor Performance

KBSs, particularly those with large knowledge bases, were found to run very slowly and to consume substantial computing resources. This affected the choice of applications. Real-time applications were mostly avoided, but so were others where resource consumption was a problem.

Programmer Education

Customers had little familiarity with LISP, in which most of the initial KBSs were written. Now that KBS products are being rewritten in C (and, in addition, Fujitsu has made available both FORTRAN/KR and COBOL/KR, which add rule capability to both of these languages), the language problem is going away. However, we also saw a reluctance to send EDP people to customer courses run by the computer companies. Companies often put great reliance on learning by trial and error. Unfortunately, many customers were unsuccessful in their attempts to build their first systems, and were turned off by AI.

Published: May 1993; WTEC Hyper-Librarian