by
Sandra Kappes, Wayne J. Schmidt, and Duane D. Sears
ABSTRACT
"Knowledge workers" are personnel who perform business processes that involve the use of information resources to generate a product that is itself some form of manipulated information. The U.S. Army Corps of Engineers' Construction Engineering Research Laboratories (USACERL) is conducting research and development on a performance support environment for knowledge workers, called Knowledge Worker System (KWS) that enables workgroups to define the tasks, information resources, institutional knowledge, and computer applications required to perform their business processes. KWS provides the capability for knowledge workers to define associations ("attachments") between a task and the information resources required to execute their tasks. Attachments allow knowledge workers to access documents while executing a task, and can be associated with any electronically stored information resource from anywhere within the KWS process model.
This research: (1) developed a strategy for providing KWS users with improved attachment management capabilities and (2) developed methods to implement this strategy through a series of modifications to KWS Version 2.0, now available to KWS users.
Back to KWS Home Page
FOREWORD
This study was conducted for the Directorate of Military Programs,
Headquarters, U.S. Army Corps of Engineers (HQUSACE), under Project
4A162784AT41, "Military Facilities Engineering Technology";
Work Unit FF-AT5, "Knowledge Worker Information Management".
The technical monitor was John Sheehey, CEMP-MC.
The work was performed by the Business Process Division (PL-B)
of the Planning and Management Laboratory (PL), U.S. Army Construction
Engineering Research Laboratories (USACERL). The USACERL principal
investigator was Sandra Kappes, CECER-PL-B. Moonja Kim is Acting
Chief, CECER-PL-B, L. Michael Golish is Acting Operations Chief,
and David M. Joncich Chief, CECER-PL. The USACERL technical editor
was William J. Wolfe, Technical Resources Center.
COL James T. Scott is Commander and Acting Director of USACERL
and Dr. Michael J. O'Connor is Technical Director.
1 INTRODUCTION
Background
In both the Government and Industry today, a large number of personnel
are classified as knowledge workers. Knowledge workers perform
business processes that involve the use of information resources
to generate a product. These products are not necessarily a tangible
item such as a piece of machinery but rather some form of manipulated
information. An example would be a Government contract document.
In the development of this product a knowledge worker requires
access to a variety of information resources. These include Government
contracting regulations, required forms, vendor information, previous
contracts, information on funds status, and so on. Once accessed,
the knowledge worker uses this information to generate the final
product - the contract document.
Because information is the primary input to knowledge work, the
quality of a knowledge worker's product depends on the ability
to access and use the relevant documents containing this information.
Managing and ensuring access to documents has always been a difficult
task. The "Information Age" has simplified document creation and, as a result, the sheer number of documents has increased
considerably. Because of this, managing documents - especially in electronic form - has become increasingly difficult.
The U.S. Army Corps of Engineers' Construction Engineering Research
Laboratories (USACERL) is conducting research and development
on a performance support environment for knowledge workers. This
system, called Knowledge Worker System (KWS), is an automated
tool that enables a workgroup to define the tasks, information
resources, institutional knowledge, and computer applications
required to perform their business processes. This information
is stored in KWS making it available to provide support for task
execution.
KWS provides on-line access to information resources through associations
of a business process or task with the information and/or documents
required to support that task. For example, a task "Write
Technical Report" requires the use of several information
resources and the actual report document being generated. These
resources could include instructions for required report format,
content guidelines, referenced documents, author notes, and a
wordprocessing template for technical reports. Access to these
resources is then provided to all knowledge workers involved in
executing the defined task.
KWS associations can be made to any electronically stored information
resource. These associations are implemented in KWS through "attachment
links". The associated electronic documents are referred
to as "attachments". Users can access the attachments relevant to
a specific task from anywhere in a KWS process model (Figure 1).
Attachments may be defined during the initial development of a
KWS business process model or on an ad hoc basis as required
by the user. Attachments can exist in a variety of formats and
can be generated by multiple sources. As the size and complexity
of the KWS model increases, the number, format, and sources of
attachments also increases, making it essential that KWS effectively
manages the creation and use of attachments to ensure that the
knowledge worker can easily access needed information. This step
in ongoing KWS research investigated the effective management
of attachments within KWS and developed and implemented a strategy
to provide state-of-the art capabilities for attachment management
within KWS.
Objectives
The objectives of this research were to: (1) develop a strategy
to provide KWS users with improved attachment management capabilities
and (2) develop methods to implement this strategy through a series
of modifications to KWS.
Approach
The basic document management requirements of knowledge workers
were identified and commercially available document management
services were reviewed to determine state-of-the-art document
management capabilities. These results were used to develop a
three-step strategy for improving KWS attachment management:
Mode of Technology Transfer
The findings of this research will be incorporated into current
and future USACERL work units addressing the development of the
Knowledge Worker System.
2 KNOWLEDGE WORKER DOCUMENT MANAGEMENT REQUIREMENTS
Document Management
"Document management" is a term used to refer to the
storage, retrieval, tracking, and administration of documents
within an organization. Its primary origin was the use of manual
file cabinets to store paper-based documents in alphabetized categories
based on the document's contents. Since the widespread use of
computer technologies, document management now also applies to
electronic documents and paper-based documents that have been
converted to electronic form. These electronic documents exist
in a variety of formats to include wordprocessing files, spreadsheets,
graphics, video, audio, bit-mapped images, and compound documents
incorporating multiple formats. Now, instead of manual file cabinets,
automated tools for document management are required to provide
users with services to access electronic documents.
The Knowledge Worker System provides electronic access to information
resources through associations of a business process with the
documents required to support that task. As the size and complexity
of the KWS business process model increases the number of attached
documents also increases. It is essential that KWS provide document
management services for effectively managing attached documents.
This will ensure that the knowledge worker is able to easily access
and utilize the needed information to support KWS processes.
Basic Knowledge Worker Document Management Requirements
The following sections will describe the basic document access
requirements of knowledge workers and the document management
services required to support them. These basic requirements are
what is needed within KWS to provide simple access and manipulation
of documents. The services required include support for document
creation, storage, retrieval, tracking, and administration within
an organization. By providing these services, KWS will be able
to effectively provide knowledge workers with the information
required to support execution of their processes. (Additional
services to provide more advanced support will be discussed in
Chapter 6.)
Document Creation and Editing via Commercial Applications.
Knowledge workers use a variety of commercial applications to
create and edit documents. Examples include wordprocessing, spreadsheet,
graphics, and electronic forms software. KWS users need to be
able to access their preferred commercial applications to create
and edit documents from within KWS. Document management services
must be provided that support the use of these commercial applications.
Document Storage and Retrieval.
After documents are created, services are required that eliminate
the burden on knowledge workers to determine where they should
be stored. Automated routines are required that determine the
specific location to store the document. This is analogous to
the determination of which file and file cabinet to physically
store the document. It should not be the responsibility of the
knowledge worker to do this. Instead, document management services
should be provided that determine this location based on specific
information about the document such as the individual creating
the document, the content of the document, and the business process
it supports.
Knowledge workers should also not have to know the cryptic "server\volume:
directory\ filename" DOS file naming structure in order to
retrieve documents. Instead, knowledge workers should be able
to retrieve documents using meaningful names that describe the
content of the document.
Enterprise Document Storage Architecture
A storage architecture is required that ensures knowledge workers
access to documents throughout an organization. Documents may
need to be shared by one or more knowledge workers at one storage
site or across multiple storage sites. An architecture is required
that defines where to store documents and ensures quick access
to them. In essence, this architecture would define which "file
cabinet" a document should be stored in. In computer-based
terminology, this "file cabinet" is called a "file
server" and would be accessible via the computer network.
The enterprise document storage architecture would define the
locations of the various file servers in an organization. Using
this architecture, documents would be stored to the appropriate
file server that would enable access to them by anyone requiring
it.
Multiple Storage Media
Knowledge workers also require support for storing documents to
a number of different storage media. Besides file servers on local
area networks, documents can be stored to hard disks, Bernoulli
disks, Floppy disks, CD-ROM, jukeboxes, and so on. These media
serve different purposes for document storage. For example, storing
to floppy disks allow knowledge workers to remove a document from
the network in order to edit it on a laptop computer away from
the office. Jukeboxes are a cost effective solution for archiving
files while still maintaining the capability to access them in
a reasonable time period. Storage management routines would be
determined based on the organizations specific document storage
requirements.
Backup and Archival
The information stored in KWS attachments is a vital resource
to an organization. Mechanisms are required that ensure the safety
of this information. The capability to backup documents to appropriate
media is required and should be performed on a regular basis.
As the number of attachments in KWS grows, so do the number of
documents. Because of storage limitations on any individual file
server, management strategies are required that migrate files
to secondary storage media. These strategies would be based on criteria
such as period of time since last use. Since these documents may
be required at a later time, services are also required to allow
knowledge workers to retrieve them on an "as needed" basis.
Shared Document Access
The collaborative nature of KWS may precipitate the use of a single
document by more than one knowledge worker. Because of this it
is necessary to provide mechanisms that maintain the integrity
of the document. For instance, document management services are
required that prevent modifications to the same document at the
same time or the document will not accurately reflect the changes
made by simultaneous edits. This capability would allow only one
knowledge worker to edit a document at a time while still allowing
other knowledge worker's to read the document.
Document Import from Multiple Sources
Many documents used by knowledge workers are generated from external
sources. They can originate in either paper or electronic format.
KWS requires the capability to import electronic documents in
a variety of formats to include wordprocessing files, spreadsheets,
graphics, video, audio, bit-mapped images, and compound documents
incorporating multiple formats. To provide quick access to paper
documents within KWS mechanisms are required to provide an interface
between KWS and electronic scanning technologies capable of converting
paper documents to electronic form. Once converted the knowledge
worker may require the capability to either view or edit the file.
Viewing the file requires an interface to technologies that allow
the knowledge worker to display the electronic image of the document
generated during the conversion process. Editing the file requires
an interface to optical character recognition (OCR) technologies
capable of converting the electronic image of the document into
a wordprocessing file format.
Document Viewing
Knowledge workers need the capability to view documents in multiple
formats without having to launch the application used to create
it. For example, if a knowledge worker accessed a Standard Operating
Procedure (SOP) relevant to the task being performed they only
need to look at the document not edit it. Also, without this capability
the knowledge worker would be limited to viewing only documents
created in application software for which they have legal copies.
This would unnecessarily limit enterprise-wide access to documents
generated across organizations in multiple formats.
Document Versioning
Versioning provides the capability to track changes made to the
working version of a document. Multiple revisions of the working
document can be maintained to allow one or more users to modify
the original document. Once the revisions are reviewed and approved
the revisions can be reconciled to produce the final document.
Versioning also provides the capability to track multiple versions
of the final document generated by incremental content revisions.
For example, during the execution of a government contract multiple
versions of the contract may be generated. The initial document
is the first version created by the knowledge worker. During the
course of contract execution, modifications to this initial document
may be required to add to or modify the contractor's tasks. It
is necessary to maintain the initial document as well as the revised
document. Versioning provides this capability and allows tracking
the history of the contract.
Security
An essential aspect of document management is that all documents
are secure from unauthorized access. Each document varies in the
type of security required based on its content. For example, there
are legal requirements to maintain high levels of security on
preaward contract documents until the contract is awarded. After
that time, the document must be made available to anyone requesting
it. Some documents may require different levels of security. For
example, some members of a workgroup may be authorized to modify
a document and other members may only be allowed to view it. Document
management services are required that can provide mechanisms for
assigning a variety of access rights to each document based on
its information content.
Document Management Strategy for KWS
Since both KWS and document management are rapidly developing
technologies, an open-ended approach was developed to incorporate
document management into KWS. This three-step strategy is meant
to provide KWS users with better document management capabilities
through a series of modifications to KWS and to allow access to
the more advanced document management technologies as they become
available.
The first step was to identify the immediate document management
capabilities required to support basic document management in
KWS and to implement them through modification of KWS. This step
is described in more detail in the following chapter.
The second step of the strategy involved identifying a mechanism
for providing state-of-the-art document management capabilities
in KWS in a relatively short time period. Integration of KWS with
commercial document management systems was the mechanism chosen
to do this. The feasibility of this mechanism was demonstrated
through a prototype integration with a single commercial DMS.
This step is described in more detail in Chapter 5.
The third step of the strategy was to define advanced document
management capabilities required by knowledge workers and provide
recommendations for providing them in future versions of KWS.
These recommendations address emerging document managment technologies
and are described in Chapter 6.
3 REVIEW OF DOCUMENT MANAGEMENT SYSTEMS
Some commercially available document management systems exist
that can provide users with state-of-the-art capabilities for
document management. Attachment management in KWS has an added
layer of complexity in managing an organization's documents due
to the need to maintain the task/document associations. However,
many of the capabilities available in commercial document management
systems can be directly applied to KWS. A review of commercially
available document management systems was conducted to identify
the capabilities they support. No attempt was made to compare
the capabilities or strengths of individual systems. Rather, this
review concentrated on their overall capabilities and the benefits
such systems provide to users. This review will serve as input
into the determination of how document management can be improved
in KWS.
DMSs automate document management on computer networks. These
systems make it possible for workgroups to locate and share documents
without having to know the DOS filename or physical location of
the document. A DMS also provides system administration functions
by establishing criteria that are used to determine storage location
or document archival actions. In addition, security criteria can
be assigned to limit unauthorized access to documents. Essentially,
DMSs provide a means of organized access and effective administration
of an organization's documents.
A DMS works by storing critical information required to access
the document in a document "profile". The profile includes
such information as the document type, author, creation date,
access rights, and so on. A good DMS allows for customizing the
document profile to meet the particular needs of an individual
organization. This profile information is stored in a database
that is used to retrieve the document without the user having
to remember the DOS filename and storage location. Through profiling,
a DMS provides quick access to the user's documents by allowing
the use of meaningful document names and searches by multiple
criteria defined in the profile. Informative file descriptions
can be specified in the document profile eliminating the users
need to know the cryptic "server\volume:directory\filename"
DOS file naming structure. For example, the user can retrieve
a file by specifying a descriptive title such as "Knowledge
Worker Document Management Strategy" instead of "s:\attach\kappes\wpfiles\stratrpt.wp6".
In addition to locating documents from the information stored
in the document profile, a DMS can also index document text allowing
users to perform full text searches to find documents. The user
simply needs to input a word or phrase and the DMS will find and
list all of the documents containing that input. However, the
additional time and overhead required for generating and storing
the indexes for this capability must be considered before providing
it to users.
Most organizations deal with documents in multiple formats. These
formats range from ASCII text documents to spreadsheet or graphical
documents. A DMS provides support to allow users to either edit
documents in any format or view and print them without having
to load the application software that created them. A DMS can
also provide mechanisms for converting paper documents to electronic
form via integration with scanning and optical character recognition
(OCR) technologies.
Other features provided by a DMS include the ability to copy a
document and save it with a new profile, generate multiple versions
of a single document, and track changes made to a document. A
DMS can also provide the capability to temporarily check out documents
from the network. Checking out copies the document to a removable
media and locks access to the original document on the network.
The document can then be edited at another location such as a
laptop computer away from the office and then checked back into
the DMS. If another user tries to access a checked out document,
the DMS will indicate that it has been checked out, who checked
it out, expected return date and any other relevant information.
As workgroups produce more information the storage requirements
for documents increase. A DMS provides administrative capabilities
to manage these increasing storage requirements. As the number
of files grows, an organization will not be able to store them
on one file server. It is therefore important to develop management
strategies for migrating files to other storage media. These strategies
can be implemented via the DMS to determine where a document is
stored, how long it is stored, and when it should be archived
to another location. For example, a document can be tagged for
archival based on period of time since its last use. An important
feature is that even though the document is moved offline the
profile information is retained so users can still retrieve the
document when necessary.
A DMS can also provide support for enterprise-wide access to documents
through the capability to support document sharing across multiple
servers on the local area network or on servers at remote locations.
This capability allows large organizations spread across various
physical locations to deal with documents residing at these multiple
locations as a single corporate information resource.
Although DMSs support many capabilities, it was also found that
they are an evolving technology. Because of this, considerable
effort is required to install and update a DMS and incompatibilities
exist between the various systems. Standards are being developed
to address these issues and should soon be available. In addition,
the evolving nature of this technology is an indication that more
capabilities will be provided as the technology matures.
4 BASIC DOCUMENT MANAGEMENT IN KWS
Introduction
The requirement for effective document management is not unique
to KWS. However, KWS is unique in the way that it provides direct
associations between the document and the task being performed.
Therefore, document management within KWS also refers to the maintenance
of the associations between a task and a document as defined in
the attachment link. Because of this additional requirement, document
management within KWS is also referred to as "attachment
management".
Review of KWS Version 1.7 Attachment Management
The basic requirements for attachment management in KWS include
those described in Chapter 2 for simple access and manipulation
of attachments within a workgroup. In addition, there is a requirement
for attachment maintenance in order to manage the task/document
associations. A review of KWS Version 1.7 was conducted to identify
what attachment management functions it provided and to determine
if it provided the capabilities required. After completion of
these reviews the modifications required to improve attachment
management in KWS were developed and implemented in KWS Version
2.0.
Attachment Creation
Within KWS Version 1.7, attachment links can only be made to documents
that have previously been created outside of the KWS environment.
For example, if a KWS user is performing a task that requires
the creation and editing of a wordprocessing document, the user
must open the wordprocessing application, create the file, edit
it and save it to a user generated filename. The user must then
create an attachment link within KWS to that attachment document.
By not supporting the capability to create and automatically link
attachment documents within KWS, the user must execute the steps
required to ensure the attachment link is made. In many cases,
the user may forget to link the attachment or avoid the extra
work and use the document entirely outside of the KWS environment.
This results in important task/information associations supporting
the tasks performed by the individual to not be captured as part
of the business process reducing the benefits gained by KWS.
Attachment Modification
Attachments are modified through the attachment modify option
in KWS. The software application used to launch the attachment
is defined when the attachment link is made. This is done by specifying
the DOS command line required to execute the application. Using
this definition, KWS launches the specified application with the
associated filename. The problem with this is that the command
line is specific to the individual user creating the attachment
link. For example, if an attachment link is defined for a document
created in WordPerfect the user must specify the command line
used to execute WordPerfect on their individual workstation, e.g.
c:\wpwin\wpwin.exe. This command will work for some users but
it will not work for users who have WordPerfect installed in a
different drive or directory.
File Storage Management
Attachment links in KWS are generated by the user who must specify
where the document is located when creating the link. Once the
link is made, the attachment remains in the location specified.
This approach can result in attachment files being stored in various
locations throughout the organization. Lack of storage management
routines can result in (1) users being unable to share documents,
(2) administrators being unable to backup and archive KWS attachments,
and (3) accidental corruption of the attachment link.
The ability to effectively share documents in a workgroup depends
on the users' abilities to access attachments. If an attachment
is stored to a local hard drive instead of a shared file server
no one will be able to access it except from that workstation.
Guidance on efficient directory structures for storing KWS attachments
can be given to users to decrease this problem but automated management
routines are required to enforce them. These automated routines
could determine where files are stored based on whether the document
is to be accessed by other members of the workgroup or by only
one individual.
When documents are spread out in various locations with no discernable
directory structure, maintenance functions for backing up and
archiving files are unnecessarily complex if not impossible. Storage
management routines should enforce storage of attachments to centralized
storage locations dedicated completely to KWS attachments. This
will simplify maintenance functions for backing up files since
the system administrator will know exactly which locations contain
KWS attachment documents.
Attachment links to documents stored in random locations are very
vulnerable to accidental corruption. This corruption is caused
when the attached file is either deleted, renamed, or moved using
DOS file commands from outside of the KWS environment. If the
user tries to access an attachment with a corrupted link, KWS
will be unable to find it since the original filename has been
changed. Centralized storage management routines within KWS can
prohibit or at least limit file access via external DOS file commands
avoiding accidental corruption. If corruption does occur, recovery
could then be possible through backup mechanisms.
Security Features
No mechanism is provided for limiting unauthorized access to attachments
within KWS Version 1.7. Without these security features, attachments
are not protected from modification by unauthorized users. This
weakness forces users who want limited attachment access to store
documents on their local workstation or to floppy disks that can
be shared by selected individuals, a method is unacceptable in
a workgroup environment. A capability to store attachments on
a shared file server and to designate specific access rights to
selected members of the workgroup is a better solution. Access
rights assignment in KWS would limit access to attachments, thereby
assuring users that their attached documents are secure from unauthorized
access. For example, certain individuals may need access to edit
a document while others may only need to look at it. In some cases,
KWS need only indicate that there is an attachment and provide
no access rights to it at all. If an attachment were stored on
a user's local workstation, and the user tried to access it from
another workstation, KWS' attempt to retrieve the document would
fail. Instead of attempting to access the document, KWS would
indicate to the user that they do not have access rights to the
document. To gain access to the document, the user could then
request authorization from the attachment's owner.
Attachment Viewing
Document viewing allows users to view documents without having
to launch the application used to create it. KWS Version 1.7 allows
for viewing text files only. This deficiency results in requiring
users to have a copy of the application used to create the attachment
document before they can look at it. Even if a user has the application
it is important to note that it is improper to allow the user
to view it by launching the application since the objective is
not to retrieve or edit the file but only to look at it. Allowing
the application launch also subjects the attachment to unauthorized
modifications.
Attachment Tracking
KWS Version 1.7 does not provide any features for tracking the
history of attachment documents. It is important to keep a history
of when the attachment was created, who created it, who edited
it last and when. This information can be used for several purposes.
First, it provides the user with a quick overview of who's responsible
for the document and how current it is. Next, KWS can use this
information to facilitate security and archival mechanisms. For
example, KWS could enable document archival based on the period
of time since the last edit. In addition, access rights to attachment
links could be restricted to the attachment creator providing
security against unauthorized modifications.
Attachment Versioning
Versioning provides the capability to save variations of single
document as separate files that can be used to track revisions
to a document. KWS can provide this function but not in an efficient
manner. The user must select a "Get Copy" option in
KWS which copies the document to a user specified location. The
user is then responsible for creating an attachment link to the
new document and specifying in the Attachment Title that it is
a version of the original document. This method is not only time
consuming for the user but eliminates any possibility of KWS to
provide mechanisms for ensuring that the versions are maintained
as a single entity for other document management functions, i.e.,
archival.
Tracking Attachment Links
KWS allows a single document to be attached to multiple tasks
causing a unique management requirement. The number of links associated
with an attachment file are maintained by KWS but are not displayed
to the user. This information could be useful in understanding
the impact of the process on the attachment document. For example,
if the attachment is linked to a series of tasks in a review process
the user is able to easily view the actions that will be performed
on the attachment. KWS should also use this information for determining
if documents should be deleted after all attachment links have
been removed. This could lead to a large number of useless attachment
documents being stored on the user's local workstation or shared
file server. Although this deletion should not be automatic the
user should be provided with the option to move the document to
another location when all links are removed.
Automatic Document Attachment
Documents can be created within KWS as the result of executing
external software applications. For example, a report can be generated
by a query to a mainframe database system or a document generated
from an electronic forms package. KWS provides this capability
through the "Do It" function. For instance, the task
"Generate Funding Authorization Report" could have a
"Do It" linked to it that executes a computer application
for logging onto a mainframe database, generating the report,
and storing the report to the user's workstation. Upon completion
of this "Do It", KWS should automatically attach the
generated report to the task. KWS Version 1.7 does not support
automatic document attachment.
Exporting Attachments
On occasion, a knowledge worker may require access to a copy of
an attachment outside of the KWS environment. KWS does provide
users this capability through the Get Copy option. This
option will save a copy of an attachment file to a KWS user specified
location and filename. An example of when this might be needed
is if a user wanted to convert an attachment file into another
application or file format. For example, if the attachment file
is a PowerPoint file and the user wants to convert it to a Freelance
file. The user would not be able to do this by making another
version of the attachment and changing the Application value since
Freelance it would require the user to convert it to its format
via the Freelance Import option. However, the user could use Get
Copy to save the file to their hard disk, import it into Freelance,
save the file and then import it into KWS.
Get Copy provides a valuable function to KWS users however it
could lead to problems if the user's intent was similar to the
check out capability described previously. Once the user removes
the document from the KWS environment, the only way to return
it is to create another attachment link to it. However, if the
document was edited outside of KWS and returned via a new link
there could be confusion as to what to do with the original file.
Should it be removed or should it be considered a version? Also
if the original attachment in KWS was not protected from update
while the copy was out of KWS there is no way to indicate if changes
were made.
KWS Attachment Management Modifications
After reviewing the existing capabilities for attachment management
in KWS Version 1.7 and those required by knowledge workers, a
set of modifications to KWS that could be implemented in a short
time period were defined. These modifications were then implemented
in KWS Version 2.0.
KWS's capacity to support attachment management was expanded by
adding Attachment Profiling, storage management routines, and
new options for creating, editing, viewing, and versioning attachments.
Essentially, these features resulted in the modification of the
KWS data base to support the additional attributes required in
the attachment profile and modification of the KWS software to
support the added functionalities.
Storage Management Routines
When attachments are created within KWS, the attachment is now
given a KWS generated document name and stored in a location reserved
specifically for KWS attachment documents. This location is based
on the Storage Type assigned to the attachment by the user (see
Storage Type section below). The user is only required to designate
this value and is not responsible for determining the actual physical
location where the document is to be stored. KWS then uses the
Storage Type value and information specific to the user's organization
to determine the physical location to store the document.
Automated management routines for attachment backup were not included
in this modification. However, this process has been simplified
by the centralized storage mechanisms enforced by KWS. Routine
network and workstation backups can now be performed on storage
locations that were established for the organization during KWS
installation. Archival routines were also not included but will
be addressed in future modifications.
Viewing Attachments
The capability to display a selected attachment without launching
the associated application has been added to KWS. This function
is provided through an external interface between KWS and commercially
available file viewing software. A file viewer is a software package
that displays the contents of a file as it would normally be displayed
in the application that created it. There are a variety of commercially
available file viewers that allow users to view common file formats
such as text files, word processing documents, database files,
and graphic files. For instance, a file created in WordPerfect
can be viewed on the computer screen without requiring a copy
of WordPerfect. KWS will not require a user to have a file viewing
package, if the user does not specify a file viewer the View option
will not be available.
The Attachment Profile
KWS was modified to include the capability to "profile"
attachments. The Attachment Profile is used in KWS to describe
each attachment linked to a task (Figure 2). When an attachment
is created within KWS the profile information is stored in the
KWS database and is used to search for and retrieve the file.
The attributes associated with an attachment that were considered
essential to meet KWS's basic attachment management requirements
were:
Attachment Title. The Attachment Title is a descriptive
name given to the attachment document, not the actual DOS file
name. For an individual task, the Attachment Title should be unique.
However, the Attachment Title does not have to be unique across
all tasks since the combination of the task/attachment title will
provide uniqueness.
Application. Application identifies the computer
program used to create and launch the attachment file.
The user selects the Application value from a list of applications
available to them. This list is generated when KWS is initially
installed on the user's workstation. The list contains information
about the name of the application and the command line used to
execute the software. It can be easily modified by the user as
software packages are removed or added to the user's environment.
The advantage to this modification is that it allows a user to
define separately from the attachment's profile the command line
used to execute the application. It eliminates the problem described
previously where one user is unable to access an attachment because
of an incompatibility in the command line.
When attaching an existing document, KWS will try to identify
the associated application from the file name extension and display
it as the Application value otherwise the value is left blank
and the user must select it from the application list. If the
application is not on the list, the user must add it to the application
list and then set the value. The Attachment Profile can be saved
with the Application value as blank but the user will not be able
to modify the attachment since KWS will be unable to launch the
associated application. However, even if the Application value
is blank the user is still able to view the attachment document
since the originating application is no longer necessary for viewing.
The Application value also provides KWS user's with the capability
to create a document within KWS and have it automatically linked
as an attachment. To do this the user completes the Attachment
Profile for the attachment to be created. The application is then
launched using the defined application command line retrieved
from the Application List and the KWS generated filename. The
user then follows normal procedures for creating and saving the
document within the selected application.
Storage Type. The Storage Type value is used
to indicate the storage location type of the attachment. The available
values for Storage Type are public, private, or removable. Attachments
with Storage Type Public are stored on the KWS shared file server
on the local area network, storage type Private are stored in
the \kws\attach directory on the user's KWS workstation, and Removable
are stored on user designated removable media such as floppy or
Bernoulli disks. The directories for Public and Private attachments
are defined by the KWS system administrator during the KWS installation
process. When an attachment file is designated as "Removable",
the user is prompted to specify the drive and directory of the
removable media for storing the file and 2) enter a description
used to physically identify the media. KWS will then store this
information and use it to assist the user in subsequent retrievals
of the attachment For example, if the attachment file "McClendon
MADOC contract" is stored to the user's Bernoulli disk
labeled MADOC contracts #1 in drive d:, KWS will display
a message to the user requesting that they "Insert Bernoulli
disk titled MADOC contracts #1 in drive d:\" to retrieve
the attachment file "McClendon MADOC contract".
Access Rights. The Access Rights value indicates
who has authorization to access the attachment. Current options
are View Profile, Read/Copy, and Read/Copy/Edit. View Profile
allows users to view the attachment profile, but not to access
the attachment. Read/Copy allows users to view the attachment
profile and read or to make copies of the original attachment.
Read/Copy/Edit allows users full rights to view, copy, or edit
the attachment as well as view the Attachment Profile.
KWS automatically gives the attachment's creator Read/Copy/Edit
access rights to the attachment. In addition, only the attachment
creator is allowed to edit or delete an attachment profile. This
ensures that unauthorized users do not alter an attachment profile.
The attachment creator can change the defaults as desired by selecting
values from the available options.
KWS provides default values for Access Rights to other users based
on the value of Storage Type. The default value given for Public
attachments is Read/Copy/Edit access rights to all users. The
default value for Private attachments is View Profile access rights
to all users. Allowing access to a Private attachment would result
in a retrieval failure since Private attachments are stored to
the attachment creator's local workstation. Although if users
are not able to access the document, by giving them View Profile
access they are able to determine who owns the attachment so they
can be contacted if access is desired.
KWS also allows users to designate an attachment as "Sensitive".
By doing this KWS imposes restrictions to allow only the attachment
creator to view the attachment profile and access the attachment
file. In addition, the Storage Type value is forced to Removable.
Forcing sensitive attachments to be stored on a removable media
ensures that users do not inadvertently mark a file sensitive
while keeping the Storage Type value Public, or Private causing
the attachment to be stored on a nonsecurable media such as their
local workstation or shared file server. If an attachment is Sensitive,
KWS does not display the attachment link to unauthorized users.
This provides additional security since if other users do not
know that the attachment exists they would be unlikely to try
to obtain access by other methods. These modifications did not
address security for sensitive attachments stored on nonremovable
media since these functions must be provided via network security
protocols or file encryption mechanisms and were beyond the scope
of basic attachment management.
Version. This value contains the version number
of the attachment file. KWS provides the capability for users
to quickly create new versions of a document through the Version
option. When a new version is created, a copy of the attachment
is made, the highest version number of the selected attachment
is incremented by 1 and assigned to the new version of the attachment.
The version creator will then be the owner of the new version
which will be reflected in the Attached By field value. All other
profile information remains the same and the user is no longer
allowed to edit the Attachment Title. This restriction is imposed
to maintain the relationship between the original document and
its revisions. Allowing a name change would essentially change
the attachment to a copy of the original not a revision. Future
modifications should include management capabilities that treat
an attachment and its versions as a single entity. For example,
deleting an attachment with versions should remove all instances
of the attachment. The current versioning structure will support
additional modifications to KWS to allow for more sophisticated
management.
Attached By. This value contains the KWS ID of the
user who created the link to the attachment file. This value is
used by KWS to determine who has subsequent modify rights to the
attachment's profile. Only the attachment creator or System Administrator
will be able to modify an attachment profile. If a user other
than the one who created the link establishes another link to
the attachment file from another task the original creator will
still maintain ownership of the link and will be the only one
able to modify the attachment's profile. If another user makes
a copy of the attachment file and links it to another task, a
new attachment profile is created and the KWS ID of the user copying
the attachment becomes the value of the Attached By field.
The following attributes were added to KWS to provide simple history
tracking mechanisms:
Date Attached. This is the date the attachment was
created.
Last Edit By. Contains the KWS ID of the user who
last edited the attachment file.
Last Edit Date. Contains the date the attachment
file was last edited.
Links. This value contains the number of links associated
with an attachment file. From within the Attachment Profile a
KWS user can display a list of the titles of all tasks currently
linked to the attachment file. As stated previously, this information
is useful for understanding the impact of the process on the attachment
document. KWS was also modified to use the link value for determining
if documents should be deleted after all attachment links have
been removed. This deletion is not automatic. The user is given
the option to move the document to another storage location when
all links are removed if desired. This will eliminate the problem
of managing non-KWS documents being stored in KWS only designated
storage location.
Modifications were also made to the methods used by KWS Version
1.7 to manipulate attachment links. Users need the capability
to:
KWS was found acceptable in it's capability to support the first
requirement but changes were required to improve support for the
rest. The ability of users to perform these functions have also
been impacted by the addition of the Access Rights described previously.
Essentially, the attachment creator owns the link between the
attachment and the task. The effect of this ownership limits other
users from deleting or moving links they do not own.
Linking multiple tasks to a single attachment was provided in
KWS Version 1.7 through the Copy function. However, this was an
improper implementation since it appeared to the user that they
had made a copy of the attachment that could be modified without
affecting the original attachment. In actuality, the user had
created another link to the same attachment and any modifications
made from either task were made to that same attachment. To correct
this problem, the Copy function was modified to allow the user
to create a new copy of the attachment file and link it with the
desired task (Requirement 3). Any relationship with the previous
link is now removed. All profile information remains the same
as the original attachment file except for the Attached By and
Date Attached values which are updated by KWS. The user can then
change profile information for the new attachment if desired.
The function of linking attachments to multiple tasks previously
provided by Copy is now performed by the Link option. Link creates
a new link between an existing attachment and the selected task.
Any modifications performed on the attachment for any of the linked
tasks are reflected in all linked instances of the attachment.
All previous links and profile information remains the same. KWS
was found acceptable in it's ability to move attachment links
to other tasks (requirement 4). Move creates a link with a new
task and deletes the link from the original task. The new Access
Rights allow only the attachment creator to move a task.
Automatic Document Attachment
The capability to enable Do Its to automatically attach documents
created as a result of their execution has been developed. Because
of the complexity of "Do It" development this capability
is not a user accessible attachment management function within
KWS but is available to "Do It" developers. Essentially,
this capability allows "Do It" developers to create
the attachment link by adding an attachment record to the KWS
database with the appropriate Profile information assigned.
5 INTEGRATING KWS WITH EXTERNAL DOCUMENT MANAGEMENT SYSTEMS
The DMS review discussed in Chapter 3 clearly shows that technology
exists for meeting most of the document management needs of KWS.
These systems provide state-of-the-art document management capabilities
that have been the result of many years of research and development.
The second step of the KWS document management strategy is to
investigate how KWS could incorporate these existing technologies
This research has dealt with determining whether the existing
DMSs support integration with external applications and if so
developing a mechanism for integrating KWS with an external DMS.
A literature review was conducted to identify potential document
management systems for integration with KWS. The systems identified
were then evaluated to determine if they could provide the capabilities
required by KWS and a system was selected for integration. An
external interface capability in KWS was required in order to
be able to integrate the selected system with KWS. A mechanism
for providing this interface was developed and the selected system
was integrated with KWS.
The KWS DMS Integration Architecture
One requirement in developing the KWS DMS integration was that
it appear transparent to the user. Consequently, the interface
should provide users with state-of-the-art document management
via the external application, but appear as if it were provided
by KWS. The mechanism chosen to support this requirement was the
development of a client/server relationship between KWS and the
DMS.
A client/server relationship is an architecture where the local
workstation (the client) requests services from a supplying machine
(the server) such as a Local Area Network File Server. The client
is responsible for providing the user interface while the server
responds to data requests from the client. The services provided
by the server depend on the application environment but are typically
centered around multi-user database access. This multi-user access
is an essential role of the server meaning that the server is
used for more than just a remote file server. The server is responsible
for all data manipulation on the supplying machine passing only
the answer back to the client.
The KWS DMS client/server relationship was defined with KWS acting
as the client and the DMS as the server. All KWS attachment management
functions were provided by making requests from KWS to the DMS.
This architecture provided KWS users with transparent access to
the capabilities of the DMS meeting the integration requirements.
Selecting a DMS for Integration with KWS
To be considered for integration with KWS, the DMS had to meet
three criteria:
The three products that met these criteria were PC DOCS Open,
SoftSolutions, and Saros Corporation's Mezzanine.
All of the three products meeting the criteria were good candidates
for the KWS/DMS integration. SoftSolutions was selected
because it seemed to provide the best capability for integrating
with the KWS application through the SoftSolution's "Software
Developer's Kit" (SDK). This SDK enables application developers
to write software routines to access the SoftSolutions'
DMS database. This capability also supports the required client/server
architecture.
The selected system was not required to provide the "best"
set of user capabilities. This was not a criteria since the objective
of this research was to investigate the feasibility of integrating
KWS with commercially available DMSs not to identify a single
integration to meet all user requirements. In addition, because
of the rapidly evolving nature of DMS products at the time of
this research it would have been difficult to identify the criteria
required to establish the "best" set of user capabilities.
Even if this had been a requirement, the three packages investigated
were found to offer essentially the same capabilities.
The Integration Process
The integration process consisted of three parts:
For KWS to communicate with the DMS a mechanism within KWS is
required by which KWS can call functions of the DMS. In addition,
there must be a mechanism provided by the DMS to allow these function
calls. SoftSolutions provided this capability through a
Software Development Kit (SDK). The KWS source code was modified
to utilize the SDK enabling the required communication between
the applications.
Since this integration will result in DMS functions being provided
by SoftSolutions the existing document management capabilities
within KWS were disabled. At the time of this research there was
no established way to disable or replace these functions in KWS.
Modifications were made directly to the KWS source code to permit
rerouting of this functionality. Additional modifications were
made to the KWS interface to change the way KWS displayed attachment
information.
The process of maintaining integrity of shared data between applications
is called data synchronization. Because KWS is using the DMS to
manage attachments, the two applications need to agree on common
keys to reference attachment records and they each need to maintain
some data about attachments. This common, or shared, data must
at all times be synchronized so that each application "knows"
the same facts about an attachment.
For this integration not all information about an attachment needed
to be stored in both applications. At a minimum it is required
that KWS needs to store information on the reference for each
attachment in the DMS. This information can then be used by KWS
to request the document from the DMS. For performance reasons,
it is recommended that any document information stored in the
DMS that is to be displayed in the KWS interface should also be
stored within KWS. This includes basic information about the document
such as access rights, author, title, and version number. It was
not necessary in this integration to store any additional information
from KWS in the DMS data base.
The additional requirement of KWS to manage attachment links may
appear to add a layer of complexity to data synchronization in
the KWS DMS integration. However, attachment link management does
not affect this integration. In the existing KWS architecture,
functions for managing and tracking attachment links are already
provided. Any retrieval of information related to attachment links
can already be provided through queries to the KWS database. These
queries would provide the information required to request the
document from the DMS and retrieval of the actual documents would
be performed through requests to the DMS.
The Integration Environment
KWS is written in C and compiled using the Microsoft Visual C++
programming environment. The integration to SoftSolutions
was accomplished by making modifications directly to the KWS attachment
module using the SoftSolutions SDK. The SoftSolutions
SDK includes two integration libraries the application programmers
interface (API) and the integrations DLL. Functions from both
of these libraries were used to complete this project. The SoftSolutions
SDK is a C based interface available for both DOS and Windows
environments.
The integration of KWS and SoftSolutions required changing
the functions of the KWS attachment menu options to invoke the
services of the DMS instead of the built in functions already
provided by KWS. KWS retained the functions required to display
the attachment profile and create, delete, and modify attachment
links. All document related functions were replaced with SoftSolutions'
functions. These included attachment editing, versioning, viewing,
storage management, and security and access restrictions that
had previously been performed by KWS. Only a portion of the document
management functions available in SoftSolutions were made
accessible via the KWS interface. Some functions, such as full
text searching, were not included in this integration but could
be made available in future revisions.
Four new fields were added to the attachment data base record
in KWS: (1) The SoftSolutions document number, (2) the
version number, (3) the security group code, and (4) the application
name. These modifications to the KWS attachment table represent
the minimum data base restructuring needed to complete this project.
Additional fields could be added to display more information about
the attachment to the user.
The KWS Attachment options are the same as those provided in KWS
Version 2.0. The following sections describe how these options
are impacted by the integration with SoftSolutions.
Insert
To insert an attachment, KWS displays an attachment profile dialog
box prompting the user for information about the attachment. Within
the attachment profile, the user can specify the attachment title,
the application used to create/edit the attachment, the security
group code, the author (not necessarily the same as the creator),
and the document type. Other profile options are managed by SoftSolutions
and will be discussed later.
Once the profile has been completed the user is given the option
of importing an existing document as the new attachment or creating
a new document. If the import option is chosen, the user is asked
to specify the DOS filename of the document being imported. The
user is next given the option of editing the new attachment. If
this option is chosen the attachment's application is launched
and the attachment file is loaded for editing. If the create option
is chosen, the new attachment's application is launched with an
empty file ready for editing. In either case, SoftSolutions
generates a Document Number for the new attachment and stores
it in the appropriate location. Also, after files are added to
SoftSolutions, an indexer window appears briefly as SoftSolutions
adds the profile information to its index tables.
Delete
Choosing this function will cause the selected attachment(s),
and all of their versions, to be deleted from SoftSolutions.
The appropriate profile information is then removed from the SoftSolutions
index tables. The user is asked by SoftSolutions to verify
the decision to delete before the deletion occurs. KWS is then
responsible for deleting attachment link information to the deleted
document from the KWS data base.
View/Print
The SoftSolutions 4.0 Document Suite comes with a file
previewer that will work with most types of file formats. The
previewer is defined for each application and is specified in
the SoftSolutions application setup screen. Any previewer
can be used but the SoftSolutions' previewer is specified
by default. Most file previewers provide the ability to print
as well as view documents. The SoftSolutions file previewer
provides viewer and printer support for most text, spreadsheet,
bitmap, drawing, and database file formats.
The SoftSolutions file previewer is a separate executable
program that is launched by SoftSolutions. Only the latest
version of the document can be previewed. Earlier versions must
be accessed via the Edit option.
Get Copy
This options allows the user to save a copy of the attachment
file to a specified location. The user must have security rights
to at least view the document in order to use this function. If
more than one version of the document exists the user is prompted
to specify the desired version.
Profile
The profile option allows the user to view and modify profile
information. If the user has "edit" access to the attachment
then any of the information that was specified in creating the
attachment can be modified. All other users are able to view the
profile information (even if the profile is private), but cannot
make any modifications.
As stated previously, the KWS interface provides the Attachment
Profile display. However, information is stored in the SoftSolutions'
database that is not contained in the KWS database. The user can
access this information from within KWS through an "Additional
Information" option on the KWS Attachment Profile display.
Selecting this option result in the display of a SoftSolutions'
screen that contains an activity list showing all operations that
have been performed on any versions of the specified attachment.
The activities list is ordered by date the most recent operation
appearing first in the list. Users that have "view/copy"
and "edit" access to the attachment will be able to
access this screen, however, all other users will be limited viewing
only the profile dialog box.
Edit
The ability to edit an attachment is available only to those users
that have "edit" access to the specified attachment.
When an edit function is invoked a call is made to SoftSolutions
to execute the application specified in the attachment profile
and to pass to this application the file name associated with
the chosen attachment. When editing has been completed and the
application has been closed by the user, control returns to KWS.
If the attachment being edited has more than one version, the
user is asked to specify the version to be opened.
SoftSolutions will dynamically map and unmap network drives
if necessary to provide access to the selected document. The system
administrator is responsible for specifying the appropriate mapping
parameters during SoftSolutions installation.
Version
This option is only available to users with "edit" access
to the specified attachment. When this option is chosen by an
authorized user the SoftSolutions version screen is displayed.
When versions are added to existing documents a comment can be
entered for each version. The user has the option of viewing the
existing version comments or creating a new version. When a new
version is created, the profile information is reindexed and the
version count is incremented by one.
Security
Security for attachments is provided entirely by SoftSolutions.
The server software comes with three predefined security classes
public, semiprivate, and private. Public access has no restrictions.
Private access will allow viewing of the profile dialog box only.
Semiprivate access will not allow any "edit" access
but does allow the attachment to be copied, previewed, and printed.
Additional security groups can be defined by the system administrator.
Document security can be used to control the storage location
of documents in SoftSolutions. Thus, a system administrator
could declare that all private documents be stored on the users
local drive (if one exists). Sensitive material can be forced
onto removable media as well using this capability. Each individual
user's environment can be customized so that "sensitive"
material is stored to an appropriate location.
Lessons Learned
Additional effort is required to develop this integration into
a fieldable product. However, the feasibility of integrating KWS
with a commercially available DMS was proven by this prototype
integration. The lessons learned while completing this integration
can be used to fine tune the integration process.
First of all, the KWS code needs to be modified to simplify the
integration process. For this prototype, the KWS source code had
to be extensively modified to disable the existing DMS functions.
To simplify integration the KWS source code needs to be modified
to separate attachment link routines from document management
routines. Essentially this separation was demonstrated by this
integration but further refinement is required before modifications
should be made to the working version of KWS. This separation
would also enable the integration of KWS with any system providing
DMS services. This includes the basic DMS services provided by
KWS as described in Chapter 5 or commercially available systems.
Better tools are required for developing the routines necessary
to communicate between the KWS attachment link routines and the
DMS routines. This function was provided by the SoftSolutions'
SDK for the prototype integration. However at the time of this
research, the SoftSolution's SDK was not well defined making the
integration process more difficult than it should have been. A
standard set of tools is required that could be used to initiate
requests to any DMS. These standards would eliminate the need
to deal with integrating KWS with multiple DMSs. Since this initial
integration, an Open Document Management API has been developed
to provide a standardized, high-level interface between applications
and document management systems. The use of this ODMA API should
be investigated for providing the capabilities required for further
KWS/DMS integration efforts.
The DMS capabilities provided through a KWS/DMS integration are
limited only by the existing capabilities of commercial software.
The time and cost of providing these capabilities via the integration
was significantly lower than what it would take to modify the
KWS code to include them. In addition, integrating KWS with a
commercial DMS also supports the Department of Defense, Directorate
of Defense Information Management, Corporate Information Management
(CIM) Initiative for use of Off-the-Shelf software. This initiative
requires DOD organizations to utilize existing commercial software
when possible instead of developing software in house.
6 ADVANCED DOCUMENT MANAGEMENT IN KWS
In addition to the basic requirements for accessing information
resources, knowledge workers require capabilities to enhance information
utilization. Information utilization is the actual process conducted
by knowledge workers to generate a product from the information
resources they access. Advanced document management in KWS involves
the integration of a wide range of technologies to not only store,
retrieve, track, and administer documents but also to promote
electronic document sharing, distribution, review, and creation
through collaboration among workgroups. By providing advanced
features to enhance information utilization within KWS, the quality
of knowledge worker products can be improved.
Activities that involve knowledge worker information utilization
were analyzed to determine the capabilities required by knowledge
workers. Next, potential mechanisms for supporting these capabilities
through modification to KWS or integration with existing and/or
emerging technologies were identified. The following sections
describe these requirements and supporting mechanisms.
Support for Workgroup Information Manipulation
Knowledge worker information manipulation is often a workgroup
activity requiring the support of several technologies. For example,
one knowledge worker may gather the data for a task while another
is responsible for generating a report from the analysis of the
data. Once the report is generated, that knowledge worker may
distribute the report to several knowledge workers who must review
it and provide feedback. After incorporating review comments,
the report could then be routed back to the review group for final
approval and then be distributed electronically throughout the
organization. To support this process, KWS users require several
advanced document management capabilities. These include the capability
to (1) pass completed attachments to the next KWS task in the
process; (2) allow several knowledge workers to author and review
a document at the same time; and (3) electronically distribute
documents to the appropriate members of the organization. These
capabilities could be provided through technologies supporting
workflow, group authoring and document review, and electronic
document distribution.
Workflow
Workflow is a capability that allows an organization to create
and monitor the flow of documents from one place to another. Commercially
available systems exist that provide automated workflow to track
each document throughout the system. These systems track documents
based on a predefined set of linked transactions that governs
the document's route from person to person in the organization.
As each person completes their assigned action on the document,
the document is passed to the next person in the workflow. Insurance
claim processing is a classic example of a workflow application.
There is a predefined set of actions that occur on the insurance
claim document from its point of receipt in the claims office
to the time it is processed and the final action is taken on the
claim. This type of process, one that is easily defined as a step-by-step
set of actions, can be readily supported by commercial workflow
applications.
KWS differs from workflow systems in that it is "task"
centered instead of "document" centered. Instead of
routing documents within a workgroup, KWS schedules tasks with
attached documents. So, unlike workflow applications, KWS is concerned
with the status of a task not a document. In the case where a
document is the end product of a task, completion of the task
would indicate completion of the document. In addition, KWS differs
from workflow systems in its assumption that most knowledge worker
tasks are not easily defined in a step-by-step fashion. Therefore,
the workflow paradigm would impose an inappropriate definition
structure on knowledge worker business process models. However,
some knowledge worker tasks can be defined in a step-by-step fashion
and KWS should support such a structure.
KWS requires additional features to provide the capability to
define portions of a task hierarchy in a step-by-step fashion.
This capability would allow knowledge workers to automatically
pass attached documents to the next task upon indicating the completion
of a task. The exact method for doing this will be determined
in future research but preliminary functionality could be provided
through modifications to the KWS database and task status routines.
KWS already provides the capability to define tasks in sequential
order via the predecessor, successor functions. An additional
attribute could be included in the attachment profile to indicate
whether the attachment is an end product of the task being performed.
When the task is marked as completed, the KWS task management
routines would determine if the task had a successor and if so,
its associated end products would be linked to the successor.
Additionally, a "ready to start" status value would
have to be included in the task status attribute to indicate to
the user that a successor task could be started once the task's
predecessor was completed. (KWS currently supports task status
values of "Not Started," "Started," Finished,"
and "Overcome by Events.") For example, if the task
"Write Technical Report" with the end product "Technical
Report" is marked as complete within KWS, its successor task
"Review Technical Report" would be given the status
"Ready to Start" and the document containing the technical
report would be automatically attached to it. In the enterprise-wide
case where the successor task was assigned to a KWS user at another
location, KWS would also manage the process of moving the attachment
to the file server at the appropriate location so it would be
available when needed.
Group Authoring and Document Review
Knowledge workers require the capability to simultaneously edit
and review documents. Workgroup conferencing software is being
investigated as a potential technology that could be utilized
within KWS to support this requirement. This is an emerging technology
that provides a platform for group discussion and decision-making.
It enables information to be simultaneously transmitted to multiple
personal computers via a local area network or modem connections
where it can be discussed and modified. This allows the capability
for conducting virtual meetings that do not require the attendees
to physically reside at the meeting location. Also called whiteboard
software, this technology allows one or more users to simultaneously
annotate graphics files and scanned images. These annotations
are useful for the knowledge worker responsible for incorporating
reviewer notes into the revised document. In addition, this software
can provide support for application sharing which enables participants
to run third-party software at the same time. This capability
could be used to enable group authoring of documents by knowledge
workers at a single location or multiple sites.
Electronic Document Distribution
Knowledge workers frequently need to disseminate information generated
by the execution of a task to non-KWS users. This dissemination
is commonly done by printing a hardcopy of the document and routing
it to the appropriate individuals. Features could be provided
in KWS that would enable users to select a mechanism such as electronic
mail or FAX to automatically distribute an attached document to
the appropriate individuals.
Access to Enterprise Information Resources
Information utilization is often supported by referential documents
defining procedures, regulations, and so on required to execute
a task. Knowledge workers typically need access to a core set
of referential documents relevant to the specific missions of
their individual organization. In KWS, this set is established
as the process model is developed. It is not likely that every
possible association between each task and the relevant reference
would be established within KWS. This is because of the dynamic
nature of the KWS process models. KWS models are continually changing
as new tasks are added to the model and there is a continual requirement
to identify new associations. Because of this, knowledge workers
require ad hoc access to these references from anywhere in a task
hierarchy to assist in identifying new associations to support
task execution. Also, it is not always necessary to create an
attachment link to a reference each time it is accessed. Therefore,
knowledge workers require the flexibility to review references
on an as needed basis without having to create an attachment link.
Reference Document Library
Enterprise reference documents utilized within KWS should be organized
in a central location. By accumulating all such documents in this
central location, a reference document library would be established
for the organization. This structure would ensure that KWS users
know where to locate reference documents and that the documents
could be accessed by anyone in the organization. In addition,
this structure would reduce inefficiencies caused by storing multiple
copies of the same document. These inefficiencies include increased
requirements for storage capacity and additional efforts required
to manage document updates. For example, if two KWS tasks require
access to the same reference document multiple two links should
be established to the one copy of the document. Without access
to a library of resources to select from, KWS users may be unaware
that a document is already stored in the KWS environment. Thus,
it is very likely that two copies of the document would be imported
into KWS with each task linked to a different copy.
Modifications to the existing document management routines and
centralized file storage structure of KWS could support creation
of an organization's reference document library. Additional attributes
could be included in the attachment profile to indicate that a
document is a reference and the contexts in which it is used.
For example, a document defining the development of a Government
contract could be defined as a reference for the context "Contract
Development". Additional document management search routines
could then be developed to provide KWS users assistance in locating
references in the library.
Task Inheritance of Referential Document Attachment Links
Many attachment links from tasks to references in KWS may actually
be relevant for multiple if not all tasks in a particular hierarchy.
It is possible to create multiple links to the reference document
from each task in the hierarchy but this would be unnecessarily
complicated. Instead, a mechanism could be provided within KWS
to enable a child task to inherit attachment links from its parent
task. So instead of manually creating a link between each task
and the reference document, one link could be created at the appropriate
level of the hierarchy and all sublevel tasks would automatically
be associated with the document.
Document Search and Retrieval
Even when knowledge workers are provided with quick access to
the set of information resources relevant for their tasks, it
may not be enough for them to simply retrieve the references.
Instead, they may need assistance in identifying a subset of available
references, viewing a specific section of a reference, or viewing
all relevant sections of a reference. For example, a KWS process
"Generate Government Contract" would have several tasks
in the process hierarchy that require associations with Government
contracting regulations. Depending on the requirements of the
particular contract, only a subset of these references may be
required by specific task. From this subset, a task may always
require an association with a particular paragraph within a reference
while another task may require the capability to access specific
portions of the regulation based on the requirements of the particular
contract (e.g. all portions related to Automated Data Processing
(ADP) services).
Full Text Query
The requirements for accessing a subset or portions of all relevant
documents could be provided through full text query capabilities.
Full text query is a technology that allows searching for a specific
word or phrase within a document or set of documents. In the previous
example, a knowledge worker could enter the phrase "ADP"
and a list of documents containing this phrase would be provided
to the user. The user could then search each of these documents
individually to view all sections containing a reference to ADP.
Bookmarks
The ability to link a task to a specific portion of a document
could be achieved through the use of bookmarks. Bookmarks are
used to mark a location in a document so that the user can return
to that location quickly. Capabilities for placing "electronic"
bookmarks in a document are provided in many commercially available
wordprocessing and spreadsheet packages. This can meet knowledge
worker requirements for bookmarking within documents they create.
In addition, bookmarking is a common feature available in electronic
publishing software used to create and distribute corporate information
repositories.
Global Access to External Information Resources
In addition to the core set of information resources, knowledge
workers may require access to a variety of external information
resources from anywhere within the KWS task hierarchy. For example,
the World Wide Web is a quickly expanding resource of information
in a variety of subjects. The World Wide Web was created as a
way to enable physicists to collaborate more effectively over
the Internet. It has since expanded to support collaboration around
the world among a multitude of workgroups. As the World Wide Web
continues to grow the benefits to knowledge workers for accessing
the information on it also grows. KWS users need a way to easily
access and share information on the World Wide Web with members
of their workgroups residing at remote sites around the world.
Access to other external information resources such as online
library catalogs, documents published on CD-ROM, and so on are
also required.
World Wide Web Access
KWS can integrate with external software from individual tasks
via "Do Its" or globally from all tasks via the "Tools"
option. Essentially, the "Tools" option allows a user
to launch external software by selecting it from the set of tools
listed. Several commercially software packages enable users to
easily log onto the Internet and browse through its information
resources (e.g. Mosaic). By providing access to these packages
via the tools option, KWS can provide users with access to the
World Wide Web from anywhere within the KWS task hierarchy.
Online Document Repositories Access
An increasing number of document collections are becoming available
on electronic media such as CD-ROM. For example, "Computer
Select" is a commercial CD-ROM library containing articles
from a number of computer trade journals. Through the Computer
Select interface, a user can identify and retrieve relevant documents
using full text query. Access to Computer Select or other online
document services could be provided in the same manner as World
Wide Web access via the KWS tools option.
7 SUMMARY AND RECOMMENDATION
Knowledge workers require access to a variety of information resources
that support execution of their business processes. KWS provides
the capability for knowledge workers to define associations between
a task and the information resources required to support execution
of the task. These associations, called attachments, allow knowledge
workers to access documents while executing a task if needed.
Attachments can be made to any electronically stored information
resource from anywhere within the KWS process model. As the size
and complexity of the KWS model increases, the complexity of managing
the documents involved also increases. An effective mechanism
for managing the creation and use of attachments is required to
ensure that the knowledge worker is able to easily access their
required information resources.
This research: (1) developed a strategy for providing KWS users
with improved attachment management capabilities and (2) developed
methods to implement this strategy through a series of modifications
to KWS. This was done through a three-step approach that provides
KWS users with increasing attachment management support:
This research contributed to the development of improvements subsequently
incorporated into KWS Version 2.0, now available to KWS users.
This study demonstrated the feasibility of providing state-of-the-art
capabilities via integration of KWS with a commercially available
DMS. Also, several potential mechanmisms were identified for meeting
the advanced needs of knowledge workers in support of information
manipulation.
Continued research and development is required to fully implement
the document management capabilities described in this report.
The following activities are recommended to achieve this end:
REFERENCES
Berry, M.D., and M.A. Goulde, "A New View of Documents: Integrated
Information Management in the '90s," The Workgroup Computing
Report, vol 17, no. 17, (August 1994), pp 3(16).
Bloor, R., "Workflow and Document Management: Managing Documentation
Efficiently in an Inefficient World," DBMS, vol 7,
no. 10, (September 1994), pp 12(2).
Bowden, E. J., et. al, "Get a Better Grip on Your Documents:
Document Managers Make it Easy for You to Track Documents and
Easy for Network Users to Share Them," LAN Times,
vol 10 no. 12, (June 23, 1993), pp 65(9).
Endoso, J., "DOD Releases Long-Awaited Vision Plan for CIM
Initiative," Government Computer News, vol 13, no.
13, (June 27, 1994), p3(2).
Elliott, E., and O. Rist, "Sharing Information Across the
Board," Computer Shopper, vol 15, no. 1, (January
1995), pp546(6).
Gay, K., "Desktop Link Saves Money," Computing Canada,
vol. 20, no. 15, (July 20, 1994), p31(1).
Garris, J., "Mezzanine/Document Manager," PC Magazine,
vol 13, no. 19, (November 8, 1994), pNE5(3).
Garris, J., "SoftSolutions," PC Magazine,
vol 13, no. 19, (November 8, 1994), pNE10(2).
Garris, J., "PC DOCS Open," PC Magazine, vol
13, no. 19, (November 8, 1994), pNE8(2).
Hackathorn, R., Enterprise Database Connectivity: The Key to
enterprise Applications on the Desktop, (John Wiley and Sons,
Inc., 1993).
Kehoe, M. B., "Out from the Abyss: Document and Image Management
Comes of Age," HP Professional, vol 7, no. 9, (September
1993), p40(7).
Powers, A., "Manage Your Group's Documents," PC World,
vol 12, no. 9, (September 1994), p72(2).
Rymer, J. R., "A Middleware Road Map: Six Steps Toward Selection
of an Optimal Foundation for Client/Server Applications,"
Distrubuted Computing Monitor, vol 9 no. 5, (May 1994),
p3(20).
Vaughan-Nichols, S., "Collaboration Software: Meet Me in
Cyberspace," Windows Sources, vol 2, no. 11, (November
1994), pp102(4).
White, R., "SoftSolutions Suite 4.0: a Lending Library
for Your Files," PC-Computing, vol 7, no. 11, (November
1994), p96(1). 
Figure 1. KWS Attachments links menu.
Figure 2. KWS Attachment Profile.
Figure 3. KWS manipulation of attachment links.
Back to Table of Contents