Upstream knowledge management

April, 1999

Case study: CFO seeks lower costs, higher ROI on knowledge creation and reuse

This article draws on content from our Knowledge Base Publishing course series  

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: contacts index terms definitions subject headings informal documents (e-mail messages, interview notes) 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 January 7, 2012