Most of the focus in knowledge management is on "downstream"
projects to organize thousands of existing documents that, through various
departmental tributaries, are flooding corporate intranets. But what about
"upstream" knowledge management -- organizing and adding value
when a source is identified or a document is written?
About a year ago, our CFO shamed the editorial staff
into developing a knowledge base for our team of researchers and writers.
Why weren't we using our skills at finding and organizing information
to reduce our costs, develop new products, and provide more value for
our clients, he wanted to know. But, we argued, how could we afford to
take time away from our regular tasks to do it? "Don't worry,"
he replied. "you can afford it; besides, you can't afford NOT to."
Our information needs We were already publishing both in print and on
the Web, using a variety of sources -- interview notes, E-mail messages,
Web pages, articles from electronic databases, and stories clipped from
print newspapers and magazines. Authors composed using one of several
programs -- Word, Pagemaker, Front Page, Powerpoint, and Outlook (for
E-mail). Everyone had his own system for filing electronic documents.
Print documents usually landed in one of several piles. We needed a system
that would not only help individuals get organized but also that would
allow us to share sources and documents. We needed to get quick answers
to the following questions:
What have we already written or published on this
topic?
Who are the experts in this topic and how do we
contact them?
Have any of our contacts or clients published anything
on this topic?
What sources have we used to prepare a specific
publication?
What are the best Web sites or databases to find
information on a particular topic?
How do we access Web sites for purchasing and updating
office tools?
Investigating our current capabilities For a small company like ours, an enterprise-level
knowledge management program such as Lotus
Notes or Documentum
would have been overkill. Besides, since we often work with "virtual"
colleagues in other locations, we needed a system that would work on most
computers. And since we didn't want to reinvent the wheel, we began by
investigating the capabilities of programs already on our desktop. In
the process, we learned some useful things:
1. One-stop searching. Although desktop programs
are constantly improving and become more Internet-friendly, they still
don't integrate well. For example, it's possible to organize bookmarked
Web sites and E-mail messages in "folders," but the two systems
remain separate. In other words, you'd have to look in at least two
places to locate an E-mail message and a Web page from the Montague
Institute.
We had already discovered a partial solution
to this problem by installing the AltaVista Discovery "personal
search engine." Discovery lets you do a full text search of all
relevant documents on your hard disk -- E-mail messages, Microsoft Office
documents, PDF files, and many other file formats. But, like the AltaVista
version on the Internet, it often returns too many "hits,"
and you can't use it to find all articles on a particular topic -- unless
the topic is mentioned explicitly in the text.
2. Indexing. For long documents such as books
or white papers, we include a back-of-the-book index that makes it easy
to find specific companies, people, and concepts. But creating an index
is a labor-intensive process and requires a standard list of terms to
ensure consistency among multiple publications. Programs like Word and
Pagemaker will create an alphabetized index with page numbers for print
documents if you insert index codes next to the index terms in the text.
How could we speed up the process, ensure consistency, and transfer
the results from print to Web?
By delving into program manuals and doing some experimenting,
we discovered some useful techniques. For example, Word has a feature
that automatically marks index terms in a document. This feature
matches a standard list of terms to any Word document and inserts the
codes that Word (and other desktop publishing programs) use to compile
an index. We not only saved time but gained consistency.
3. Saving and sharing. To effectively find
and reuse documents, we needed a system that would provide more detail
than a bookmark list, fewer "hits" than an AltaVista search,
and easier integration with our publishing system. All of this was possible
with a custom electronic "card catalog" database. We could
import bookmarks from a Web browser, then add as much detail as we liked.
Our own subject headings and index terms would make searching more accurate.
The database's sort, export, and Web capabilities would reduce our research,
collaboration, and publishing costs. Did such a program already exist?
Researching external options
We found some programs that did pieces of the job, but none that did everything.
Therefore, we began in early 1998 to develop our own virtual
card catalog using the same relational database program that served
for contacts, invoicing, and job costing. By the summer, our researchers
were using the system instead of bookmarks. By the beginning of 1999,
our editors were using it to produce indexes for print publications, maintain
links on our Web site, and compile a collection of previous newsletter
articles. Today, we are using it to track and contact experts, produce
glossaries and citation libraries for our publications, and deepen our
relationships with clients.
How the project evolved
Step 1. Build the "card catalog" file using
a relational database.
Step 2: Import bookmarks, create records for our own
publications, add records for new sources as they appear. This was
an iterative process, involving an initial data "clean-up" and
successive updates to add and refine data in each record.
Step 3. Develop our subject headings, classify documents
as we used or cited them.
Step 4. Train our researchers to use the Library as
well as add and update records. Researchers have access to the master
library file for searching. Each researcher also has a private "clone"
file (a copy of the master file with no records), used for adding and
updating records. The library editor-in-chief periodically reviews the
clone files, adding and updating the master file as necessary.
Step 5. Add features, for example:
Display index terms for each article, search for
publications containing an index term, use a standard list of terms
to create an index for print publications.
Link article or Web site information to contact
information for the author, the referrer (the person who suggested the
source), and the subjects of an article.
List of all articles authored by a specific person.
List all Web sites and articles cited in a specific
publication.
Step 6: Train writers in composition, train editors
in knowledge base publishing.
Step 7: Package the library for distribution as a research
deliverable and adjunct to our print/Web publications. This involves "binding"
the database with the necessary software so that users can use it as a
standalone application -- without having the database program running
on their computers.
Step 8: Publish the library on the Web. Passwords control
who can browse, search, and update the library.
click image to enlarge
An entry in the Documents segment
of the Knowledge Base. Other segments contain information about:
Web site
and Abstract fields are "active" links
that retrieve the full text document from the public Internet, a
commercial database, or a local storage medium (hard disk, LAN,
ZIP drive).
Future development
We are constantly "tweaking" the system to make it easier to
use -- e.g. streamlining screen design, eliminating keystrokes, and tightening
the integration with related processes. After almost eighteen months of
use, we need to edit our subject categories -- creating more cross-references,
eliminating duplication, expanding categories that have become crowded.
In addition, we are working to:
• Make all source materials accessible through
permanent links to commercial article archives. If clients already have
an account with the archive provider, they can enter it when they click
on a link. If not, they can buy a copy of the article with a credit card.
• Automate the creation of library records using
a method as simple as adding a bookmark in a Web browser. When the researcher
clicks on a button, the system should create a new record containing information
automatically extracted from the document or Web page -- title, author,
URL, publication date, publisher.
• Develop guidelines for deciding what kinds of
documents to include in the library. For example, we now have multiple
ways to handle E-mail messages. Many messages, of course, are simply read
and then discarded. But those we want to save are either stored in a "message
file" or treated as a library document (saved as a separate text
file with a corresponding "card catalog" record).
Benefits
Though we haven't quantified them, the benefits of the new system are
clear:
Higher quality publications without adding staff.
Time savings for research and publishing.
New revenue-generating products.
And our CFO is much happier. In a future article, we'll
detail how he uses the new system.
Created on April 27, 1998 l Updated on
April 5, 2007
