11 Steps to Building a Knowledge Map by Jason Bargent The steps involved in building a Knowledge Map, or K-map, are logical and follow a typical life-cycle approach. The success of your K-map is dependent on aligning it to a business pain or problem, which enables the K-map to directly address that problem. You use an iterative process to create the K-map, initially selecting a small group of data (known as the training set), and then slowly adding to this training set (see, "Glossary of K-Map-related Terms," below, for definitions of terms used in this article). Once you've spidered the training set and have initially created the K-map, members of your organization's business community (who know the data) use the K-map Editor to teach the Lotus Discovery Server (LDS) the correct category titles and positioning of the documents. As you add more data to the K-map, the less involved this effort becomes, resulting in the business community maintaining the K-map as a small ongoing task. (To learn more about LDS components and K-map security, see "How to Build an Effective Knowledge Map," May 2002.) The following steps describe in detail how to build a successful K-map. Step 1. Identify Requirements Before you rush off to create a corporate taxonomy or K-map from your organization's actual data, you must clearly define the goal of the K-map. This typically involves identifying a set of business pains and then targeting data sources for the K-map that address those pains. To identify business pains for the K-map to target, you should determine whether • people are having difficulty locating documents or experts in a particular area (e.g., a department, specific project, product) • you have too many "islands of data" in your organization, in which only a few people know where everything is stored (e.g., too many departmental intranets, excess file servers with incorrectly filed documents) • the data that you need to store is in legacy applications or relational database systems, potentially making it hard to access or share • people know that information exists, but they have too many sources to go to for the information, which can result in confusion • you're duplicating too much work and could benefit from reuse (this is particularly relevant in a project basis) A K-map can directly address all these questions. However, these problems may occur across the entire business, so you'll also need to decide the scope and target audience. For example, do you build a K-map for a specific project or department, or do you build a corporate-wide K-map that spans all departments (a first attempt at building a K-map should almost certainly be small and manageable). Note that at present with Lotus Discovery Server v1.1, you can build only one K-map per physical server. Although this may change in future releases, it's important to remember that you can easily extend the scope of a K-map to cover additional communities or departments. If you do, however, want to provide multiple K-maps (e.g., one per department or project), each department and/or project will require its own server. Keep in mind that you build a K-map relevant to a business pain, not for individual departments or projects. At anytime, you can increase the scope of the K-map to add new data sources (you can often achieve results more rapidly by starting small and then expanding). Step 2. Conduct an Information Audit Once you've established the business pains and scope of the K-map (such as a specific project or department), you audit all the electronic information used by the target audience. This information can include internal and external Web sites, Lotus Domino databases (including Lotus Domino.Doc as a document management system), files, and Page 1 of 8databases. You conduct this audit to define a detailed list of every data source used that can potentially be targeted for spidering. It's often advantageous to capture the information in a Lotus Domino database so that you can easily sort the contents. A typical information audit database for K-map sources contains information such as • classification (e.g., Web site/page, file system, Domino database, other database) • link to source (e.g., URL if a Web page, Universal Naming Convention (UNC) if a remote file or remote file share/folder) • type of information (e.g., a report, news feed, projects folder) • whether the information is duplicated in another part of the organization • who uses the data (e.g., a specific individual, groups of people) • whether others outside this team benefit from the information • importance of information to a job role • how the information is used (e.g., reference, storing information) • how often users access the information • whether the information is internal or external (e.g., external may be news feeds) • who owns the information (from a security/admin perspective) • whether the information is security protected • the life span of the information Most organizations or departments don't have a definitive list of useful information sources, so this list can also act as valuable output of your Knowledge Management initiative, ensuring that people have access to a single catalog of relevant internal information to a specific job role or function. Step 3. Define Information Sources to Use Now that you've established a complete list of data sources for the target K-map, subject matter experts (people who know, understand, and work with the data sources) must closely review the K-map as follows: • Remove useless sources: Almost every information audit will reveal irrelevant information. • Remove duplicates: Because many departmental Web sites can contain duplicate information, this step is particularly important if your K-map extends across the organization. • Evaluate each data source for its metadata: Quality metadata is fundamental to the result of an effective K-map. Metadata describes information such as the document title, author, and date. You use this information to show summary information in a K-map. Lotus Domino databases and document management systems are typically the best sources for metadata because behind each document are predefined fields in the forms. File system documents such as Microsoft Office or Lotus SmartSuite documents often aren't the best sources for high-quality metadata (just think how often you fill in the metadata of a