Information Support

This view suggests that decisions are made according to standard operating procedures (SOPs) within subunits of the larger organization. Each subunit is considered to have its own store of institutional knowledge and procedures for making decisions. In this view, decision analysis depends on identifying organizational roles and relationships among the subunits (Simon 1957).

The Political View

This view suggests that decisions are based on political constraints, aspirations, and interactions-not on systematic methods. Decisionmaking is a bargaining process, and requires an understanding of the political processes involved and the strategies and compromises required to incorporate the interests and constraints imposed by all actors in the decision process (Simon 1957).

The Individual Differences View

This view is based on the premise that each decisionmaker is a unique individual with personalized strategies and abilities. The methods for making decisions and using information are assumed to vary from person to person. Therefore, in this view, it is difficult to define one approach for producing a decision. An influential theory about information use during decisionmaking has arisen from the Individual Differences View. Cognitive Complexity Theory states that decisionmakers can be overloaded with information because of weaknesses in differentiation decisionmaker skills. Low levels of differentiation result in a limit on the number of information categories a decisionmaker can process. This theory suggests that too much information during decisionmaking can be as detrimental as too little (Keen and Morton 1978; Miller 1965; Newell and Simon 1972; Olshavsky 1979; Payne 1976).

Back to Table of Contents

Back to KWS Home Page

Description of the Knowledge Worker and Decisionmaking Activities

Knowledge workers each have unique skills and personalized strategies for decisionmaking. They are driven by the goals of their organizational subunit and their relationships with the organization as a whole. The quality of their performance depends on access to their organization's store of institutional knowledge and SOPs. Knowledge workers frequently make decisions by considering alternatives, then using heuristics developed through on-the-job experience to choose among those alternatives. In some instances, decisions are based on methods for finding optimal solutions. Finally, knowledge workers are often influenced by political constraints, individual aspirations for career development, and interactions with key actors in the decisionmaking (or approval) chain.

From this brief description of knowledge workers and their general environment, it can be seen that no single theory discussed above will adequately describe knowledge worker decisionmaking activities. A model incorporating all of these theories appears to be necessary.

A Model of Information Support for Knowledge Worker Decisionmaking

Based on the understanding of knowledge worker decisionmaking outlined above, a model for providing information support to the worker was developed. The model is a special case of the more general Knowledge Work Process model previously developed by USACERL, which is shown in Figure 1 (Thomas and Schmidt, August 1992). The Knowledge Worker Information Support (KWIS) model is illustrated in Figure 2.

Figure 1. USACERL Knowledge Work Process Model.
(Source: Thomas and Schmidt, August 1992.)

The KWIS model illustrates the knowledge work process with required support for information management. The central element of the process is the task. The task is the activity to be performed by the knowledge worker. It consists of two subelements: task details and task execution.

Figure 2. Knowledge Worker Information Support (KWIS) Model.

Task details describes specific characteristics of a task, such as the organization responsible for the task, who assigned the task, the destination of the task output, relationships with other tasks, priority, and due date.

Task execution denotes how the task is performed. This component includes the use of any mechanism that enables the knowledge worker to complete the task. These mechanisms could be expert systems, spreadsheets, word processors, procedural programs, or any other enabling technology. Task execution can be automatic, to provide support for programmed decisions, or participatory, by providing assistance in completing nonprogrammed decisions.

Information required to support a task is acquired through the link with the information component. This component represents the information associated with a specific task. The lack of an arrow in Figure 2 to indicate the flow of information into a task is intentional. The information is only associated with the task, but not necessarily required to perform the task. The information may be used if the individual knowledge worker chooses to use it. Information consists of three subcomponents: standard operating procedures, institutional knowledge, and data.

Standard operating procedures (SOPs) (when applied to Army activities, the official term is standing operating procedures) include all references, regulations, and guidance required for the performance of a task. These procedures are specific to the organizational subunit performing the task.

Institutional knowledge includes the how-to information and heuristics accumulated through on-the-job experience. This knowledge is specific to the organizational subunit performing the task. Any type of information that might affect the execution of a task is included in this component.

Data are the supporting facts provided to knowledge workers through databases and other information management systems.

The product is the result of the knowledge worker task. Examples include an oral or written report, a decision, an analysis, or any other type of information-based outcome.

The complete model for knowledge worker decisionmaking must show the interrelationships among each individual knowledge work process in an organizational subunit as well as those with the entire organization (Figure 3). The links between processes (ellipses) indicate a relationship. The ordering from left to right indicates sequence in time, showing predecessor and successor relationships between processes. Each group of processes, designated by the boxes enclosing them, represents those for an organizational subunit. The entire diagram represents all processes for an organization.

Figure 3. Interrelationships Between Knowledge Work Processes Across Organization Units.

Back to Table of Contents

Back to KWS Home Page

Validation of Model

To validate the accuracy of the model, an actual decision process was selected and applied to the model. A knowledge worker within the Military Programming and Execution Support Office (CEMP-P) at Headquarters, U.S. Army Corps of Engineers (HQUSACE) was interviewed to obtain a description of one process performed within the organization issuing funds to District offices. A detailed flowchart of this process can be found in Figure 4.

Figure 4. Process Details for Issuing Design Funds to Districts.

Issuing Design Funds to District Offices Process

The process of issuing design funds to District offices consists of five main tasks. Performance of each of these tasks requires information support. The following sections describe the information support needed and shows the correspondence between the process and the KWIS model.

Task 1: Determining Whether Funds Have Been Appropriated. This task requires institutional knowledge of the fact that funds must be appropriated by Congress and signed into law before they can be legally used for a project. The information the worker needs is contained in a textual document, the Public Law Conference Report. The amount of funds appropriated for military construction projects is input to the CAPCES database by another organization-the Programming and Planning Division, Assistant Chief of Staff for Installation Management (ACSIM). The knowledge worker has the option of checking the Public Law Conference Report or the CAPCES database for the existence of a value in the APPROP_AMT data field. The check on the CAPCES database requires expertise on how to access the database as well as which field contains the appropriated amount value.

Task 2: Determining Whether Funds Have Been Approved by the Secretary of Defense. Institutional knowledge is required to know that once funds have been appropriated they must be apportioned by the Office of Management and Budget (OMB) to the Office of the Secretary of Defense (OSD). Apportionment is assumed to have been done because it is automatic. After apportionment, OSD approves funds on a line-item detail and issues the approval on a SD 460 form. In addition, the OSD comptroller issues a Funding Authorization Document (FAD) for the Assistant Secretary of the Army Financial Management Branch (which is attached to the SD 460 form). Based on this background information, the knowledge worker has the option of checking the SD 460 Form or the FAD to determine if funds have been approved by OSD.

Task 3: Determining Whether the Funds Have Been Issued by the Army to the Corp. Once funds have been approved, the next check is to determine whether they have been issued by the Department of the Army (DA) to the Corps of Engineers (CE). Once again, this is institutional knowledge required by the knowledge worker. There are two sources of information that can be used to determine whether the funds have been issued to CE: the FAD or a report available on the PBAS system. Checking the FAD requires knowledge of where to locate the hard copy, which is stored in a binder in chronological order at CEMP-P. Finding the information on PBAS requires knowing that the information can be found by running the PROGSTATUS report entitled Status of Detail Program Distribution by DA to GOA. In addition, the knowledge worker needs expertise to access and use the PBAS system and locate the information on the PROGSTATUS report.

Task 4: Determining Whether the Funds are Available to Issue. The knowledge worker must now determine whether the funds that were issued to CE are still available to issue to District offices. Based on institutional knowledge, the knowledge worker knows this information can be found by running the PBAS PROGSTATUS report Status of Detail Program Distribution by GOA to FOA. As in the previous subtask, expertise is required on how to access and use the PBAS system, and where to locate the information on the PROGSTATUS report.

If the PBAS information indicates that the funds are not available to issue, the knowledge worker must determine why. Since funds were apportioned they should have been issued from DA to CE. The experienced knowledge worker would know to check whether there was an oversight or if they were withdrawn for some reason. This check involves knowing the appropriate points of contact (POCs) in the Defense Finance and Accounting Service and the Army Budget Office. These POCs can, through their own decision process, determine if the problem is due to an oversight, fix it, and make the funds available. In addition, these POCs are the source of any "inside information" that could affect issuing the funds. Something might have caused withdrawal of the funds, or a POC may know of an impending event that might affect availability of the funds. Often, such events are political, and access to inside information is essential to predict their occurrence.

If the unavailability of funds is not due to an oversight and the funds have not been withdrawn, the knowledge worker must determine why funds are not available for issue. The following cases give explanations for nonavailability of funds, and the solutions for making them available.

The money was used for an official reprogramming. This information is determined by checking PBAS to see if the funds available at DA are less than what was appropriated initially. Another way to determine this is by checking the SD 460, which would show a negative amount in the "Formal Reprogramming" column. If the money was officially reprogrammed, the amount cannot be increased and there are no funds available to support the request.
All of the appropriated funds were already issued for the project. This information is determined by checking PBAS. In this case, another project may be identified as a source of funds and money can be borrowed from it. Funding sources are identified by checking PBAS. First a project is identified with undistributed funds. Next it must be determined if the project will require the funds by checking one of several sources containing the current working estimate (CWE) on the project-Financial Management System (FMS), CAPCES, or AMPRS. The CWE obtained is then compared to the amount issued to determine if there is an excess. If there is an excess, the knowledge worker must check with the Program Manager in the Army Branch (CEMP-MA) to make certain that the funds will not be required for the project. This check is also necessary because the CWE obtained is not always current. If a source of funds is identified, the following rules for borrowing money must be followed:
1. If the request is less than 15 percent of the appropriated amount, then no approval is required.
2. If the request is between 15 and 20 percent of the appropriated amount, then approval from the Secretary of the Army (SA) is required.
3. If the request is greater than 20 percent of the appropriated amount, then Congressional approval is required.
The money was borrowed for another project below threshold reprogramming. In this case, money can be borrowed from another project. The rules and procedures given for borrowing money in item 2 above must be followed.
The funds may have expired before they were used for the project. In this case, the funds can still be used if the request meets the rules for use of expired funds. Regulations state that expired funds can be used for supervision and administration costs, engineering and design during construction, or to pay claims. If the request does not qualify for use of expired funds, then money can be borrowed from another project. Once funds are identified for borrowing, the project is "split funded," and a request must be made to add the AMS code to PBAS for the year of funds planned for issue. This is called "Requesting an AMS Code."

Task 5: Issuing the Funds. Once it is determined that funds are available for issue, the knowledge worker follows SOP for issuing funds. This action is acccomplished by selecting the "Issue Funds" option on the PBAS system. The data from the request document and the AMS code obtained from previous reports or Army Regulation 37-100-XX (where XX is fiscal year) is entered into the system. A hard copy of the FAD is printed and stored in a folder with the request document.

Representation of the Process as a Model

Figure 5 represents the decision points for issuing funds to district offices in the KWIS model format. The model depicts the five knowledge worker tasks described. Each task is in a rectangle, stated as a "yes" or "no" question. The flow of the process depends on the decision made at any point.

The direction of the arrows between processes denotes the predecessor and successor relationships between tasks. In the first four processes, there are two possible products for a task. These products are not tangible objects, but rather decisions made by the knowledge worker. For example, in the first process if the knowledge worker determines that the funds have not been appropriated the decision is made to wait for appropriation before issuing funds. If the funds have been appropriated, the decision is made to perform the next task. In the last process, issuing funds, there is only one product-a funded project. Information sources that may be required to perform these tasks are defined by the link between the task and the information components. Each information source that could be used is included, but the knowledge worker determines which sources actually to use.

This example validates the use of the KWIS model to represent knowledge worker processes. Chapter 3 describes how the KWIS model could be implemented to support knowledge workers in their daily decisionmaking activities.

Figure 5. Decision Points for the "Issuing Funds" Process Represented in KWIS Model Format.

Back to Table of Contents

Back to KWS Home Page

3 IMPLEMENTATION OF THE KWIS MODEL

The model described in the previous chapter shows a basic framework for providing knowledge workers with information to support their decisionmaking activities. Using computer-based technologies, this model can be further developed to provide knowledge workers with an integrated knowledge-based environment for information support during decisionmaking. The major issues for developing such an environment using the KWIS model are discussed briefly in the following sections.

Model Development Methodologies

The knowledge worker process modeled for the example in Chapter 2, issuing design funds to district offices, was developed through a semistructured interviewing technique known as verbal protocol analysis (Newell and Simon 1972; Payne 1976), sometimes called the "think-aloud method." The interview subject was asked to "think aloud" about the decisionmaking process for issuing design funds. Although the subject's responses were semistructured and incomplete, which is common when this method is used, they could be combined with objective information and the author's background knowledge to formulate a coherent process model. (It should be noted that this methodology is not considered adequate for developing large models that describe several related processes within and across organizational subunits. A structured methodology is recommended to develop consistent models that are easily maintained and validated.)

Many modeling techniques exist today for representing business processes. These techniques are generally used to describe a process for the purpose of automating it using static procedures and databases. The resulting process models typically contain information on data flows and business rules pertaining to the data, but do not contain any information on why or how an activity is performed. Their primary purpose is to assist in automating an activity. Generally, the models exist only as diagrams used to communicate between system developers and the user during the system design process. Because of this, such models are not easily used for maintenance and validation, and they are limited in the type of activities they can represent.

Modeling knowledge worker processes requires a methodology that can capture the logic and information sources used, as well as the interrelationships among tasks and coworkers during performance of a task. Models must provide background information to (1) help knowledge workers find and interpret the information needed to support a task, (2) provide the user with expertise associated with a task, (3) support an automatic execution of repetitive programmable tasks, (4) train inexperienced knowledge workers to perform a task, and (5) coordinate tasks among coworkers.

Preliminary investigations determined that existing model development methodologies by themselves are not capable of providing the knowledge-based information support required by knowledge workers. However, by extending appropriate methodologies to include the additional requirements imposed, a structured methodology for developing knowledge worker process models could be developed. This research did not involve in-depth investigations of existing model development methodologies, however, so no recommendation for using one particular technique is given.

Back to Table of Contents

Back to KWS Home Page

Model Implementation

The knowledge work process models developed through continuing research will be implemented as a software system to support knowledge workers. In effect, the model must portray the business process and present it to the knowledge worker in an automated performance support environment. Since the model is supposed to represent a real-world process, it must be able to continuously adapt to changes within the environment. For example, employees leave, procedures change, and organizations restructure. In addition, users may need to see the model from different perspectives: managers require a broad view of the process whereas the knowledge worker actually performing the task may require detailed step-by-step instructions.

Object-oriented technologies can be used to provide a dynamic modeling capability. An object is defined as a real-world entity about which information is stored. Object-oriented programming provides a way to represent both objects and their relationships with other objects. Using this paradigm, the information, task, and product components of the KWIS model could be represented as objects. These objects would contain information on their specific attributes, relationships with other objects, and methods for executing a process.

Because of the potentially large size of the process models that will be developed and the need for interaction between these processes across organizational units, the capability of storing and managing many objects across several computer networks is required. This capability can be provided by distributed object-oriented database systems. These systems are an emerging technology, often referred to as "next-generation database systems" (Cattell 1991). They provide the same capabilities of commercial database systems along with the complex data modeling available through the use of objects.

Back to Table of Contents

Back to KWS Home Page

Knowledge-Based Programming

Knowledge-based programming is a mechanism for incorporating human expertise into software. Object-oriented models are well suited to this task because they are, by definition, patterned after the way people think: object-oriented models describe systems in terms of objects and their interrelationships.

Knowledge-based programming can be used to store the institutional knowledge required by knowledge workers. For example, an expert's knowledge about the idiosyncracies of a temperamental office laser printer can be encoded into a laser-printer object. When a knowledge worker is having trouble with the printer, the laser-printer object can help. In a graphical user environment such as Microsoft Windows or X-Windows, the knowledge worker may simply be able to click on the appropriate portion of a picture of the printer. The object can then tell the user how to solve the problem.

The advantage of using an object-oriented model in such a case may not be immediately obvious. But suppose that solving the printer problem requires procurement of a part from the computer services department. The laser-printer object can simply hand off the user to the parts-request-form object, or to the telephone-directory object. The laser-printer object does not need to know how to solve problems that are not really its responsibility-it can rely on other objects to perform their specific work.

Furthermore, object-oriented systems readily adjust to changes within objects. Suppose an organization changes to a new set of telephone extensions. With an object-oriented system there is no need to reprogram the laser-printer object with the new telephone extensions-updating the telephone directory object will make the proper changes throughout the system. In fact, any object can make any internal change without affecting the rest of the system. This capability is another advantage of the object-oriented paradigm.

There are many software packages for developing knowledge-based systems. Software that follows the object-oriented paradigm is preferred because such packages facilitate the representation of institutional knowledge within the objects depicting knowledge worker processes.

Back to Table of Contents

Back to KWS Home Page

Information Resources and Linkages

The developer of the process models will define many links between tasks and needed information. However, the dynamic nature of the models makes it impossible to provide all needed links in advance. In some cases, the knowledge worker will need help to determine which information best meets his or her needs.

Providing such help requires mechanisms for identifying sources of information and simplifying access to those sources. Knowledge workers could be supported in this effort through the development of (1) a knowledge base on information resources and (2) a library of linkage objects for accessing those resources.

Most business processes involve a core set of information resources. The Information Resource Knowledge Base would assist users not only in identifying these resources, but also in using them effectively. Furthermore, this knowledge base could maintain links within each process, guiding users from one information resource to others that may also be helpful.

The heavily used core of information resources would be identified as the knowledge worker process models were developed. Each object representing an activity would be given a list of resources frequently used to carry out the activity. Expertise on the content and use of specific resources could be captured through interviews with the experts using verbal protocol analysis (as described under "Model Development Methodologies" in Chapter 3). This expertise could then be maintained in the Information Resource Knowledge Base.

Such a knowledge base would be feasible because most business processes require only a small set of information resources; this implicitly limits the requirements of the software system. In addition, it is not necessary that the knowledge base include all information resources that might ever be accessed by any worker. It would be sufficient to store only the most frequently used resources because, by definition, those are the cases that consume the most worker time.

Most workers now seek help from others-experts-who are more experienced in a particular process. A knowledge base containing the fruits of these experts' experience would eliminate the need to interrupt them at their work. More importantly, it would typically enable the user to get information more quickly. The knowledge base would be more accessible than the expert, and it could directly help users access the information they needed-for example, by assisting them in constructing a database query.

The feasibility of knowledge bases that give users such specific assistance was investigated at USACERL for the Construction Appropriations, Programming, Control, and Execution System (CAPCES) database (Kappes et al., May 1991). Researchers developed a knowledge-based natural-language interface (Expert-CAPCES) that uses knowledge of the CAPCES database to translate queries into the FOCUS command language required to retrieve the data. Another version of the system provided this same CAPCES knowledge in a hypertext-based program. The hypertext version helped users search for data, and also served as a tutorial on the contents and purpose of the data contained in CAPCES.

In addition to the Information Resource Knowledge Base, an Information Linkages Library could provide instructions on how to access the required information. In many cases, the Information Linkages Library could partially or fully automate access. Using object-oriented terminology, these linkages would be objects that "knew" how to access a specific information resource. The object would contain information about the resource's location, format, access procedure, and any other unique aspects. These objects could be activated through direct links with a task, or they could be activated indirectly through assistance provided by the Information Resource Knowledge Base. Figure 6 depicts both strategies by illustrating (1) a direct link to a database and (2) an indirect link provided by interaction with the Information Resource Knowledge Base.

Information Representation

The types of information that could be accessed from this kind of automated support environment may vary from process to process. One process might require access to a variety of forms, regulations, and databases; another might require ad hoc access to online information services or CD-ROM libraries. The information could be presented to the user through knowledge-based hypertext systems, written documents, databases, computer graphics, geographic information systems, or even video. The information support system should be able to access information regardless of format.

Object-oriented programming can fulfill this requirement. Adding the ability to access a new type of information source simply requires adding a new object that "knows" what needs to be done. There is no theoretical restriction on what types of information can be accessed: as new types of information become available, the system can always be modified to access them.