Knowledge systems and management decision support

Expert Systems With Applications, Vol. 3, pp. 187-194, 1991 0957-4174/91 $3.00 + .00 Printed in the USA. © 1991 Pergamon Press pie

Knowledge Systems and Management Decision Support

STAFFAN LOF AND BJORN MOLLER

Epitec AB, Link6ping, Sweden

Abstract--In the past, corporate decision maldng has been aided by conventional decision support and database management tools. There are a number of aspects of decision making, particularly qualitative, where these tools offer minimal assistance (e.g., business trouble shooting). In an attempt to overcome these deficiencies, we have combined these conventional tools with knowledge systems technology, that is, inference-based reasoning, in order to create an intelligent decision support system. This article presents such a system, named BUCKS (BUsiness Control Knowledge System), developed to support business controllers and district managers in performing their business analysis within the Digital Equipment Corp. SWAS (Software Applications and Services) operation in Sweden.

I. INTRODUCTION

MOST DECISION S U P P O R T SYSTEMS are data analysis and reporting tools used primarily by middle- and lower-level managers. Although they offer adequate support on these levels they might be of limited value in executive decision making. Executive decision making involves much more than data analysis; it involves establishing goals and criterias, assimilating information relevant to the goals and criterias, and providing judgments based on many years of professional experience.

Historically, corporations have used database management systems (DBMS) and decision support systems (DSS) as the major sources to provide factual and analytical information on which they base their decisions. The role of the DBMS in this context is fairly well understood. It serves as the repository for corporate data such as past and present operational data. The role of the DSS, on the other hand, is somewhat more diffuse. DSS are used not only to describe the past and the present, but also to partially examine the future, that is, to determine the analytical outcomes of different scenarios (for example, regarding marketing, types of projects, and pricing strategies).

While DBMSs and DSSs can be used to support the factual and analytical aspects of a decision there are other qualitative aspects where they offer minimal assistance. In particular they provide few facilities for automatically discovering opportunities/problems, for determining and explaining the causes of the problems when they occur, and for suggesting alternative causes of actions. Capabilities such as these can be achieved

by using knowledge systems technologies like inference base reasoning to incorporate judgmental knowledge. The following scenario illustrates the idea.

Assume you are an executive level manager in charge of a country level operation which is part of a large corporation. To run such an operation you need a staffofpeople who can, among other things, provide you with advice and information to support your decisions. Information needed for decisions ranges from simple reports to expert level analysis and suggestions such as:

• The Net Operating Revenues are good (21% over budget) and increasing. The Business Contribution Margin is good (18% over budget) and constant.

• Revenues are very high, even after subcontracted project revenues have been deducted. This is due to a lot of packaged services and a few good fixed price projects (mainly Company Corp. projects).

• It is possible that too much overtime is used. This together with the fact that subcontracting is going up indicates that our revenues may go down soon.

Such a report is normally produced by colleagues or assistants with expert level knowledge in economy and business control as well as a thorough understand- ing of the business and prevailing business goals. This particular report was, however, not produced by an expert but by BUCKS, a Knowledge System for Busi- ness Control, developed by Epitec, for and in cooper- ation with Digital Equipment Corp. (DEC) in Sweden.

In the following sections we describe BUCKS, and share some of the experiences we have gained and conclusions we have reached when developing BUCKS.

Requests for reprints should be sent to Staffan L6f, Epitec AB, S-582 24, Link6ping, Sweden.

2. BUSINESS CONTROL

BUCKS (BUsiness Control Knowledge System) was developed for district managers and controllers at Dig-

187

188 S. Lr f and B. MOiler

ital Equipment's SWAS/EIS (Software Applications and Services/Enterprise Informations Services) in Sweden. Each country serviced by Digital Equipment has a SWAS/EIS organization with several districts providing customers with consultancy services: fixed price projects, time and material priced services, packaged consulting ("Getting Started" services), and so forth. SWAS also supports sales with advisory per- sonnel.

Each district reports and comments on its performance at the end of each month. These reports are merged at the country level and sent to headquarters Geneva together with forecasts. The time from which one month's figures are available until the reports have to be submitted is only 2 days. Not only is it a very short period, but it also occurs at the busiest time of the month. High quality business analyses are, of course, crucial to the success of a district.

2.1. The Business Control Task

The business control task consists of monitoring and correcting the performance of a business. In the DEC SWAS/EIS case, managers will have to investigate revenues for different project types (fixed price, time and material projects, packaged consulting, etc.), direct and indirect costs (wages, subcontracted project costs, management and overhead, allocations, etc.), and business contributions measured in absolute figures and percentage of turnover. Results are reported for current month, quarter to date, and year to date. These figures are regularly compared to the corresponding budget and the variance is calculated.

In addition to this a number of key figures are fre- quently used, like utilization (billed hours in relation to total working hours), revenue per capita in different classes, and usage of subcontracted consultants. The interpretation task consists of: • Initially studying a basic set of figures. Deviations

are noted. • Judging figures in relation to each other. • Interpreting and assessing the situation--"making

observations." • Finding plausible causes for an observation. • Depending on the outcome of the previous steps, go

into further detail with some figures. This usually includes acquiring underlying information. One of the main problems is the interpretation of

deviations. There are basically two possible reasons for these: a real problem in the business performance or simply reporting/analysis difficulties. Examples of business problems are low profitability, too much overtime, or bad order intake. Examples of problems in the analysis are that a few big and profitable projects may hide small and unprofitable projects, the use of different currencies, incomplete information (like time

reporting, late billing), or temporary relocation of re- sources.

The expertise to carry out the task described above is, unfortunately, scarce. A few centrally located experts have this knowledge. By capturing and distributing the knowledge of the experts to a number of district managers it should be more valuable to the organization. The similarities with EMYCIN (Shortliffe, 1976), where expert knowledge was communicated to attending physicians through a knowledge base, is obvious.

3. R E P R E S E N T I N G B U S I N E S S CONTROL KNOWLEDGE

A knowledge-based system consists of." • A knowledge base containing knowledge about a

specific domain. • An inference engine matching the knowledge in the

knowledge base with a particular problem. • Interfaces for the end-user and the knowledge engi-

neer. • Integration, for example, with databases. This architecture can handle very complex problems. Also, programming can be separated from domain knowledge.

One of the main problems is how to represent knowledge from a specific domain in a knowledge base. The traditional way is to use rules. This allows a great deal of flexibility and allows the knowledge base to grow easily as new knowledge/rules are entered. On the other hand, well-structured parts of the problem cannot be well represented using rules. It may also be very difficult to keep track of rules. In too many cases, rules have been used to mix programming and domain knowledge, making the domain knowledge even harder to grasp than in a conventional program.

In this case a hybrid tool, Epitool (Epitec, 1989), was selected for the problem. Hybrid tools allow well- structured information to be represented in an object- oriented way using classes and instances. Algorithmic knowledge can be represented as functions. Rules are, of course, used to describe how new facts can be derived from known facts.

3.1. Which Knowledge to Put in a Knowledge Base?

There are several approaches to this question: • The knowledge of a decision-theory model that is to

be tested under real circumstances could be put in the knowledge base. In this way a system could also be used to enforce the use of a new model.

• The knowledge currently being applied by experts could be collected and put in a knowledge base. Such a system would mimic the behavior of one or more human experts. Since this was a commercial project it was decided

that the only available and reliable sources of business

Knowledge Systems and Management Decision Support 189

Module I lucks I CreMe Modify Root Show

Project ]

C o s t C e n t e r ]

Oistrlct ]

Ic~,,e

~ indlrServ FieldServAll°c J

I

\~l TMpr°jecte I

I

FIGURE 1. Some important classes in BUCKS.

specific knowledge in this case were two experts, a senior manager and a business controller.

3.2. Object-Oriented Knowledge Representation

The organizational/accounting model is easily represented in an object-oriented model. Initially objects in the domain were identified and classified. A taxonomy (hierarchy of classes) was constructed. An excerpt with 15 important classes is shown in Figure 1. The complete system contains 120 classes. Having created these classes it was easy to describe the organization by con- necting a number of instances of "district" to an instance of "country" as shown in Figure 2. A number of revenue and expense objects were connected to each district, and so forth. The complete system contains 2000 instances.

In addition to giving a strong model of the problem for the problem-solving process, this representation also gives a framework for the integration with external databases. If we look at the attribute (e.g., BUDGET) of an instance (Fixed Price Project Revenues of South District) together with the time period being examined (e.g., March Fiscal Year 1987) we get a full specification for a database search.

3.3. Rule-Based Knowledge Representation

The reasoning of the business control process is best represented as a set of IF-THEN rules. When the situation specified in the IF-part occurs, the rule will fire and draw the conclusions specified in the THEN-part of the rule. An example of a rule is shown in Figure 3.

Rules have been grouped into a number of rule sets carrying out different tasks: • Adjustment rules that make minor adjustments of

some figures depending on district, time of the year, and so forth.

"South" I "West . . . . North" m

I1--I1: District [ I1-11: District I H : District P r o l e ~ : ... ProJeo~: ... i Proleelm: ...

F IGURE 2. Sample object structure in BUCKS.

190 S. LOf and B. MO'ller

RULE NORoverBudget In Forward, Backward Is Forall ?D Whichis District; IF

?D.NOR = "High" And ?D.SubcontractedNOR = "Low" And ?D.FixedPprojectNOR = "Low"

THEN AddValue "Too much overtime is used"

To ?D.PossibleProblems; AddValue "Advisory is suffering"

To ?D.PossibleProblems; END;

FIGURE 3. Sample rule in BUCKS.

• Key figure rules that calculate various key figures. • Classification r u l e s that classify actual outcomes and

trends as high, low, normal, increasing, and so forth. This classification depends on parameters on a sep- arate file. Parameters are available both as company policies and user preferences.

• Observation rules. From the previous step it is possible to recognize situations such as "Very high subcontracting but revenues and business contribution are better than budget." Many of these observations are problem situations.

• Cause rules. If a problem has been detected the system can assert hypotheses for possible causes. Finally a knowledge fusion takes place. The knowl-

edge and observations of the system are then combined

with the knowledge of the district manager. Observa- tions are displayed and the user can select and add causes as well as typing in comments. It is possible to suggest causes not previously known by the system. When this happens the system saves a system improvement suggestion on a log file. The final result is half a page of important figures and comments, typically like the example given in the introduction. The different levels of information derived from the rules are shown in Figure 4.

4. THE BUCKS SYSTEM

BUCKS is essentially an umbrella system. Sitting on top of existing applications (e.g., financial systems, time and project reporting), it provides intelligent analysis and reporting.

The total BUCKS environment (Fig. 5) consists of: • Existing databases: FACTS, Time Reporting System,

Project Reporting System. A monthly extract from these is stored in the EXTRACT database;

• Additional database: ADD, manually updated; • Parameter files with company standard parameters

and user settings; • Report output for word processing and/or printing; • System improvement logging (as described later).

The BUCKS system consists of the following main parts (Fig. 6): • Database integration, collecting information from

EXTRACT and ADD;

Fusion

FIGURE 4. BUCKS levels of information.


Corporm Databases P s t s n l l t ~ s

© EXTRACT

-© I I BUCKS

1

FIGURE 5. The BUCKS environment.

• Basic accounting/organization model (object oriented);

• Key figure analysis; • Knowledge-based analysis (diagnosis/pattern

matching); • User interface running on different terminal types.

4.1. User Interface

The aim of the user interface is to provide easy access to the system and to visualize the information in the system. This includes the organizational structure and measures (profit, turnover, etc.) for different units. The top menu of the system (Fig. 7) displays the country and its districts together with business graphics indi- cating revenues and profit compared to budget. By se- lecting a district box the user can drill down to more detailed district information. Both standard terminals (VTIO0) and graphical displays (VAXstations) are supported.

" / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /

Organisation/Accounting Model / / / / / / / / / / / / / / / / / / / / / . / / / / / / / / / J

IIIIIl ll'lllllllllllllllllllllllllllll]lllllllllllll I Jl,,lllll FIGURE 6. The BUCKS system.

4.2. Database Integration

Information from existing databases is extracted each month and added to the EXTRACT data base. The main reason for this is the complex searches and ac- cumulations that would be too time consuming to carry out in real-time.

Some information needed to calculate certain key figures could not be found in existing databases. Some examples are manpower per district and working hours per month. To overcome this an additional database, ADD, was introduced.

Data in ADD and EXTRACT are stored in a gen- eralized BUCKS Data Format which enables data to be accessed using more general keys (time period, ac- cumulation over time, and organizational units, budget/actual) and more specific keys (type of revenue, data source).

4.3. Development of the System

The system was developed on a VAX. Most of the integration was implemented in Pascal and DataTrieve. The object-oriented model and the knowledge-based analysis was implemented in Epitool. The graphical interface was developed for Digitals VAXstations. Sev- eral prototypes were presented during the project, sup- porting both the development of the knowledge base and the graphical interface.

The knowledge was acquired from a business controller and a senior manager. The knowledge engi- neering was initially based on cases. The experts dis- cussed live situations making comments and describing their conclusions. When the basic framework of the problem solving was designed it was possible for the experts to formalize their knowledge on their own.

In order to keep the knowledge up to date, a feedback loop was introduced (Fig. 8). As described earlier,

192 S. L(ff and B. MOiler

Me Eat ~

I:- DEC EIS Sweden

: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . : . . . . . . . . . . . . . . . ; . . . . . . . . . . . . . . . :, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . :

i : i i South West North ELst

District DistHct Dlstrl©t District

NOR BCM% NOR BCM% NOR BCM% NOR BCM%

Of

FIGURE 7. BUCKS top menu.

suggestions for system improvements are logged. At a regular rate (usually each quarter), the experts and the knowledge engineer study the log. Suggestions that qualify as relevant knowledge are introduced into the knowledge base.

5. PRACTICAL RESULTS

An analysis that used to take hours or days to perform can now be completed in a few minutes by any district manager using BUCKS. This enables managers and controllers to perform more frequent analyses and cor-

rect potential problems sooner than was previously possible. It also reduces training time and sets a min- imum standard for the acceptable quality of an analysis. The open-ended architecture with a fusion of the users and the systems knowledge also makes it a useful tool for experienced managers.

6. PROPOSED CONCEPTUAL ARCHITECTURE

After having developed BUCKS and a number of other similar applications, we have observed an emerging

, . 0 , , , , . , , , . , , , . ' " " " " ' " " ' " ' ' " ' . , . , , I , , , l . , , , , , I , i i ,,l,, ,jr u',l,l,; ddp, i

/' '""""l BUCKS

,1111/,' I I

~ Knowledge Base

Expert & KE

User

Mllmlng Knowledge i

FIGURE 8. Knowledge feedback loop.


Presentation Level

Manager's Integrated Desktop

Knowledge -

Information Processing Level

Information Level

Data Level

Decision Support Services

Enterprise Information Repository (Enterprise Information Model)

Enterprise Databases

FIGURE 9. Proposed conceptual architecture.

common pattern in terms of overall architectural prin- ciples. Our experience suggests a four-level architecture outlined in Figure 9. The major objective with the proposed architecture is to make it possible to combine and integrate new technologies into already existing system concepts and at the same time protect and reuse existing investments in terms of corporate databases and systems.

Our model is based on the assumption that person- nel at the bottom level have a number of different and heterogeneous corporate databases which contain information relevant to the problem at hand. Before using that information we have to make sure it meets the requirements we have on quality and meaning (se- mantic precision) for example. We also have to derive necessary additional information that is not explicitly stored in any data base. Typical information of the latter kind is accumulated data during a desired period of time, aggregated information related to a particular organizational unit or level, and various models to reflect different perspectives of the business. Issues like that are considered in the transition from the Data level to the Information level. Performed transfor- mations should of course be consistent with definitions that exist in the Enterprise Information Model.

Having created that information repository we have a solid ground on which we can apply necessary information-processing procedures, ranging from report generators to Knowledge Systems, to generate quality information to support management decisions. We believe this is the appropriate place to integrate Knowledge Systems into our architecture. By combin-

ing technologies it is possible to reuse, integrate, and add value to existing applications. Adding value to existing applications also makes it possible to prolong their life length and thereby reduce life cycle cost.

The Presentation level in our architecture takes care of interaction and presentation issues. We believe it is important to treat them separately since they are special and of a somewhat different nature. The fact that there are a lot of tools around that make it easy to create interfaces using, for example, colors and graphics is no guarantee of success. On the contrary, there is an in- herent danger in the ease with which you can create flashy interfaces. Proper information presented the wrong way is a well-known way of failing. Special at- tention should be paid to reflect structural aspects of information--organizations as well as relationships and dependencies important to the decision at hand.

On the presentation level we also consider such problems as integration of all the services we provide into a consistent and easy to use environment which supports a manager's decision making. Special atten- tion should be paid to the integration of electronic mail, or other similar systems, to facilitate involvement of more than one decision maker in the decision process as well as communication of the decisions to affected parties.

The model we have proposed is intentionally non- technical in the sense that it makes no commitment whatsoever to implementation issues. We do, however, believe that it can be mapped easily onto any technical structure, be it a centralized or a decentralized environment.

194 S. L r f and B. Mrller

7. GENERAL CONCLUSIONS

In the preceding sections we described BUCKS, an intelligent decision support system for business controllers and area managers within the Digital Equipment Corp. SWAS organization in Sweden. By developing and deploying BUCKS we have shown that it is both possible and feasible to capture and distribute expert level knowledge within an organization to effectively support a business critical task--business control.

The major business benefits can be summarized as follows: • improved decision quality (and on time), • distribution of knowledge within the organization in

terms of common policies and procedures, • saves time for qualified people. From an information technology point of view we have experienced that by carefully combining different

technologies we have been able to add new function- ality, reuse, integrate, and add value to existing applications and thereby increase utility and prolong life length of old systems.

REFERENCES

Epitool Development Environment. (1989). Reference Manual, Ep- itec AB.

Reitman, W. (Ed.). (1984). Artificial intelligence for business. Nor- wood, N J: Ablex Publishing Corporation.

Shortliffe, E.H. 0976). Computer-based medical consultation: MYCIN. New York: Elsevier Computer Science Library.

Sprague, R.H., & Watson, H.J. 0989). Decision support systems. Englewood Cliffs, N J: Prentice-Hall International.

Thierauf, R.J. (1988). User-oriented decision support systems. En- glewood Cliffs, N J: Prentice-Hall International.

Documents

Knowledge systems and management decision support