For individuals who've not lived through a knowledge management project, what they know about that topic is what they have heard from colleagues and read in research reports and trade journals. Presently, a lot is being talked about and written about in the research reports and journals regarding "this" vendor and "that" vendor and how the buzzword of "enterprise portals" is ranking right up there with the buzzword "data warehouse" from a few years ago.

Portals are here to stay (rightly so) and pretty soon everybody will have one. The truth is that the portal is just the delivery piece, the "glory" so to speak, of the entire knowledge management cycle.

There isn't much written on the "guts" of how the knowledge that feeds the portal is identified, classified, organized, analyzed, sanitized and made available to the knowledge worker.

For starters, let's define knowledge management:

• A text book description from A Component-Based Knowledge Management System by Tom Finneran of CIBER, Inc. -- "Knowledge management is the discipline of spreading the knowledge of individuals and groups across the organization in ways that directly affect performance."
• A reality-based description (also from A Component-Based Knowledge Management System by Tom Finneran) states that knowledge management envisions getting the right information, in the right context, to the right person, at the right time, for the right business purpose.
• A hit-home reality description of knowledge management comes from thoughts of "Joe Specialist" and how Joe's knowledge of what to do and how to do things is being tapped all the time. Some folks say that it would be nice to have Joe around all the time; and everywhere; and to everyone in the company. Joe Specialist is YOU -- and the folks in the offices around you.

The exchange of knowledge works two ways -- you have information and knowledge other people don't have, and they have knowledge you don't have. Knowledge management doesn't come from implementing a portal. It comes from hard work, accountability, and a focus on leveraging what your company knows to impact company performance.

Sharing knowledge is a key to success. The way to achieve the "shared knowledge" pinnacle is through quality work on each of several focal areas of knowledge management.

This article is the first in a series that addresses the "trenches" of knowledge management and the core areas that require focus to deliver a successful knowledge "system." The seven focal areas touched on briefly in this article include:

• Component-Based Architecture
• Stewardship & Culture Change
• Meta Data & Classification & Search
• Artifact Management
• Collaborative Forums
• Portals & Customization
• Communities & Changing Culture

A few quick items to point out before getting started. "Culture change" will be addressed twice in this series. The ability to manipulate the organizational culture toward becoming a collaborative (knowledge-happy) environment will be a major determinant of whether business goals are reached.

Without a cultural shift the project is doomed to failure. In other words, you may build a darned nice portal, but if no one uses it or updates it for the purposes intended, it is not a success (and perhaps a costly failure).

Another item to be highlighted is the striking similarity between knowledge administration and data administration. Best practices in both areas include education, stewardship, meta data, modeling, change management, and browser-based delivery (to name just a few). In knowledge management, individuals and companies that are well versed in proven successes in data administration have a leg up on those that aren't.

The last item to point out is that "portals" are only mentioned close to the end of this series as one of the components of knowledge management. This doesn't mean that portals are not important. In fact that couldn't be further from the truth.

The portal is what the business and IS areas will focus on. The portal has to be great. Knowledge workers get acclimated to using the portal to send and receive knowledge on a regular basis. Therefore, it is certainly an advantage to have skilled (and quick) developers and a catchy portal design.

Component-Based Architecture

Architecture is a word thrown around in big business and recruitment circles. Architecture includes a plan that synchronizes business issues with resource deployment and technology solutions. The plan includes how to leverage people and existing hardware and software, and how to incorporate new hardware and software.

Most significantly, architecture includes a singular view of the business requirements (now and what is known about the future) and the plan to deliver solutions that addresses these requirements.

So what makes up a knowledge architecture? A knowledge architecture is made up of several components. These components address the whos, whats, and how to's of the knowledge delivery system. In other words, the architecture focuses on how to deliver information geared toward decision-making and concerning knowledge content, presentation, stewardship, administration, and technology.

As Tom Finneran states in his article, A Component-Based Knowledge Management System, "a knowledge component is a self-contained, reusable object that can be used independently or assembled with other components to satisfy knowledge management requirements. There is a generic set of architecture issues relevant to all components.

"Knowledge components have to interface with the knowledge portal, with the knowledge repository, and with other knowledge components. A knowledge component may need to be customized to handle knowledge of events specific to a given knowledge community. In a like fashion, component behavior may need to be customized to satisfy the special needs of the specific knowledge community."

The beauty of a component-based architecture is that it can be delivered in pieces. Special attention must be paid to making certain that the components "talk" to each other. When selecting an overall architecture, it is advisable that companies look to leverage their existing technologies (i.e., meta data repositories and administration tools, portal development tools, collaboration tools) by using them to fill the roles of the components, without introducing new technologies. Leveraging existing technologies plays well politically, costs less money, and forces the IT group to play an active role in what should be deemed a business-driven project.

A component-based architecture also leaves the organization open to the introduction of new technologies and analysis of market technologies that might be swapped out for another that better suits the company's needs without upsetting the rest of the architecture.

Stewardship and Culture

Information stewardship has been a hot topic on-and-off over the years. Accountability for data and information resources is often addressed as part of a basic data administration function. Companies identify and assign individuals to be responsible for defining, producing, and consuming data and information.

Stewardship includes tying these individuals' "actions" to management policy. Often stewardship is addressed in terms of the data that sources a business intelligence database. However, enterprise stewardship of all data resources is a monumental task and one that is difficult to achieve.

Stewardship of knowledge can be treated in much the same way as information stewardship. There are knowledge definers (what knowledge needs to exist), knowledge creators (documenters of the knowledge), and knowledge consumers (everyday knowledge workers). Each type of steward has a level of responsibility and accountability that can also be tied to management policy:

• Definers decide what should be made available for consumption while creators "write" the knowledge and pass it back to the definers for approval. The task of stewarding all of the enterprises knowledge is also monumental. Defining knowledge that will help specific business functions is easier to implement and has a greater propensity for success.
• Creators, well, they create knowledge or take knowledge that is available and put it in a format that is valuable and usable to the other knowledge workers of the enterprise.
• Consumers use the knowledge to perform their jobs. The ability to do the right thing right the first time is often based on what knowledge is available, how that knowledge can be retrieved, and how that knowledge is applied. Basically, knowledge users (consumers) require a knowledge management system.

Stewardship involves a change in culture. In the pre-knowledge management days it has been a "free for all" as far the knowledge that each person uses to perform their job. The more experienced individuals have been counted on to "be there" when a less senior person needs help.

When the more experienced person is not available, the less-senior struggles does what he or she "thinks" is right, or waits until the senior person becomes available. There are risks associated with each of these options.

With knowledge management, stewards (definers) are responsible for identifying knowledge that needs to be made available. In knowledge management, those who document the knowledge (creators) are required to contribute to the company's knowledge base. In knowledge management, workers (consumers) are expected to look for information that will help them and impact their effectiveness and efficiency.

These are fundamental shifts in how business folks react in their fast-paced environments. Stewardship and documented responsibility will immediately bring changes to the culture.

Meta Data and Classification and Search

The meta data area is the backbone of knowledge management. Just like "data meta data" is the information about the data and information systems that exist in the company, the "knowledge meta data" is the information about the knowledge that has been cataloged and classified by the company.

Being able to identify specific knowledge when it is needed has, perhaps, the greatest impact on the bottom line. If you have a question, you want to be able to find the answer. The answer is in the knowledge. The ability to find the knowledge is through the meta data.

In order to catalog the company's knowledge, it will be necessary to create a database that will store the meta data and knowledge workers must be able to access the meta data. Whether the database is built or bought can be based on available know-how of how to create a meta model and database.

Either way, the knowledge meta data model (meta model) must be made available and the database must be extensible to take on new aspects of knowledge and classification values.

Before knowledge is cataloged in the meta data database, an organizational schema must be developed to identify key locator and search information about the knowledge that will be cataloged. For example, the knowledge may need to be broken down by:

• who can see it (management level)
• what business areas it applies to (business subject)
• what type of knowledge it is (e.g., check list, project plan, account summary)
• when it needs to be reviewed, and so on

Once the meta data database is built and the classification and organization schema is built, the next step is to start classifying the knowledge into the database. Initially this may require a team of individuals who focus on entering submitted pieces of knowledge.

The more detailed the classification, the easier it will be to narrow the search, and the longer it will take to enter and manage each piece of knowledge. Worthless options in the search option may impact engine complexity and performance, potentially making the search for data more confusing.

Also, the amount of time it takes to classify a document is something to consider. Gauge how much "pain" the knowledge workers will be willing to tolerate to get their knowledge cataloged and strike a balance. The time to catalog becomes important when you are trying to catalog 50 documents from 20 business areas for 1000 pieces of knowledge.

It is important to develop an easy-to-follow (read well thought out, defined, and documented) workflow for knowledge to makes its way from the creator, through the steward, past the approver, and into the database. This workflow will be shared time and time-again as people become involved in knowledge management.

Artifact Management

For the purposes of this article, an artifact is defined as any piece of knowledge that exists in a format that can be classified, cataloged, and retrieved. An artifact can be a document, spreadsheet, diagram, plan, or anything else that can be cataloged and classified in the meta data database, researched, and found helpful for a business purpose.

Knowledge in someone's head is not an artifact until it is recorded. Recording can be done via text, graphic, audio, or video into a classifiable format. Knowledge exists in all of these, but that knowledge does not become an artifact until it is recorded and cataloged.

The importance of 'recording' an artifact becomes evident when you stop to consider trying to manage something that is not recorded. The truth is that we cannot manage something that is not recorded. Once it is gone, it's gone.

Now that we know that an artifact is recorded … how do we manage artifacts? Artifact management potentially will involve the use of document management and imaging, workflow management, meta data management, web development, plus other technologies. The following are how some of these technologies are related to knowledge management:

• Document management and imaging are related because a large percentage of the organization's knowledge will exist in documents and images that will be indexed and stored according to how they will be retrieved and used.
• Workflow management is related because knowledge artifacts will be required to follow a specific pattern (workflow) of design, development, submission, review, and acceptance before it is made available to the organization. Artifacts become dated and thus workflow management must be used to identify when artifacts should be reviewed, revised, and, potentially, retired.
• Meta data management is related for many of the reasons stressed previously in this article. Meta data is the backbone of the knowledge "system." A quality meta data database, whether purchased or built internally, will be integrated with all of the technologies in the prior points, plus the portal, the search engine.
• Web development change management is related because intranet pages either will or will not become classified as artifacts. If the web pages on your intranet are not classified and managed as artifacts, they must be managed using some other technology and/or process. Inevitably, intranet web pages become knowledge artifacts and become a part of artifact management process.

Content Management

Each of the focal points thus far have focused on the "how-to's" of knowledge management. Content management focuses on the "whats" of knowledge management. The "whats" include:

• What knowledge needs to be managed
• What knowledge doesn't need to be managed
• What knowledge exists within the company
• What additional knowledge from outside the company should be managed
• What does it take to manage the important content
• What is expected of those who will be responsible for managing the content

Vendors have recently been developing knowledge-based partnerships with suppliers of external knowledge (news, stock quotes, weather, flight schedules, delivery services, competitive data and so on) that can be consistently supplied and applied through their portals. Information of this type can be enabled such that specific content is always a click (or potentially two or three) away.

It is important that the content of the first knowledge collected during a knowledge management prototype or pilot is focused on a specific business purpose. Failure to focus on specific knowledge will quickly provide perception that the task of managing the organization's knowledge is too monumental to make a dent.

By identifying a specific purpose, and by focusing on managing content that improves performance for that purpose, a company can demonstrate specific value (fewer workers compensation claims, less rework, fewer resources needed, less time to market).

Once the core areas of knowledge management (the "how to's" addressed earlier in this article) are implemented, be on the lookout for content scope creep, particularly in the case of a prototype and pilot. Once the skeleton engine (or artifact factory) is in place, there is a tendency to want to classify as much as possible.

The truth is that successfully delivering knowledge management is still a distance from being achieved. Spending time classifying and organizing knowledge outside the defined scope is okay (this information will need to be classified someday anyway) as long as it doesn't interfere with the prototype and pilot purpose.

Collaborative Forums

Another focus for knowledge management is on collaboration -- individuals or groups working together for a single purpose (in this case create knowledge). In the day of the high-speed connection, faster computers and the intranet/Internet backbone, it has become easier to break down the barriers of location and have workers collaborate side-by-side even if they are thousands of miles away.

Collaborative forums are events where multiple individuals can offer their knowledge for a centralized purpose either linearly (in a threaded textual discussion), in real time (virtual conferences, video-conferences, chats, which are a combination of real time and linear discussion).

In linear textual discussion, it is rather simple to cut out a series of threads (lines of discussion), pull from the threads knowledge that needs to be classified, and create a knowledge artifact. In real time, the forum needs to be recorded via video and audio in order for someone (or some technology) to extract the knowledge context from the forum.

The differences between a collaborative knowledge artifact and individualized artifacts are minor but real. The true difference is in the number of "chefs" involve with each and how it is determined who is responsible for stewardship of the knowledge. Differences may also exist in how the artifact is classified and how the meta data is used.

There are several types of forums to consider when implementing a knowledge management effort:

• Threaded discussions are linear textual discussions that allow information and questions to be posted, responded to, and managed along multiple tree-d lines. Knowledge can be extracted from the linear text discussion by reading through the branches of the tree or by recording a section of the forum and summarizing it into an organized artifact.
• Virtual meetings bring individuals in different places together at one point in time. Virtual meetings allow multiple individuals to sit at their computers, see the same thing, hear the same thing, and transfer control of the screen and collaborated artifacts from place to place.
• Video conferences are video recorded to capture an event for future playback. The playback may then be either viewed directly or converted into an artifact via transcription.
• Chats are semi-real-time true linear discussions that can be used for a small number of people and can be managed much in the same way as threaded discussions. Without an effective facilitator, however, chats with more then a few people are more difficult to manage.
• E-mails can also be knowledge forums in ways similar to the threaded discussion and chat. An e-mail or a dialogue of e-mails can be recorded and converted into artifacts. Also, individual e-mails such as announcements, warnings, and other information pushes can either be converted into artifacts or they can be recorded and classified as is in the meta data database. Companies often consider creating a special e-mail address -- such as knowledge@mycompany.com -- for individuals to submit e-mails as potential artifacts.

Portals and Customization

As stated in the introduction to this article, the portal is the "glory" that comes after the guts. The portal is the light at the end of the tunnel. The portal is the pot of gold at the end of the rainbow. "To heck with the rest of the knowledge system, just give me a portal that will get me the answers to my questions."

The portal incorporates all of the areas that have been the focus of this article thus far and thus becomes "the place to go to share what you know." To develop a portal, attention must be paid to several portal components:

• Customizable bookmarks and folders
• Dynamic and customizable links and icons
• Collaboration tools
• Connection to all existing applications (e.g., word processing, spreadsheets)
• Connection to all user defined shortcuts
• Search engines and access to knowledge meta data
• Connection to the data warehouse
• Important messages (for quick distribution of knowledge)
• Recognition (for those who contribute to the knowledge)
• Administration (for those that manage the meta data, submit artifacts, etc.)

Customization is extremely important. Through authentication and security, knowledge workers can be recognized for who they are and can access a specific customizable view of the portal. To provide customized views, a separate database must be used that houses the user's customized selections stored and managed by user id.

Through customization, multiple portals ARE NOT needed for different parts of the business. The company can work from a single portal template (for consistency) that may look very different from one desktop to the next according to how the user has customized their "view."

Portal development and customization can include:

• Forced Content -- things that management decides that specific workers will see
• Optional Content -- things that management will allow specific workers to see
• Soft Content -- weather, package tracking, stock quotes, sport scores, and so on
• Other Content -- business-specific content that add to the knowledge worker's experience
• Content Order -- how the content is displayed on the portal

Knowledge Communities and Changing the Culture

Knowledge communities already exist in most companies. These communities are typically small, closed, very informal and are based on trust and the "I know who to call" mentality. When it comes down to it, there may be many people in your "community" (local or not) who have done what you do and who could probably offer a few pointers. You have something to offer them, too.

From a business perspective, take this example. A store manager in Atlanta probably goes through some of the same trials and tribulations as a store manager in Pittsburgh. A loading dock foreman in New Jersey may go through similar problems as the foreman in New York. The financial analyst in payroll downstairs may have solved the same problem as the financial analyst in accounting upstairs.

These people exist in similar communities. They may not know that each other exists (at least in a knowledge sharing capacity) but their jobs are tightly coupled. They can learn from each other. They can help each other.

Building the communities is not a problem. Finding people with similar responsibilities and issues is not a problem. Grouping people together by business function is not a problem. Getting individuals to document and submit their experiences and lessons-learned to a pool of collective knowledge - now, that is a problem. This will be a tremendous hurdle for the business areas to overcome.

The process of providing knowledge to others in the business through the portal has to be unobtrusive to "normal" business flow and has to be made accessible during the entire knowledge cycle from the submitter to the approver. If you have to read a manual to figure out how to submit an artifact - the artifact probably won't get submitted.

Changing the IT culture is significantly different from changing the business culture. Consider this sample dialogue during a recent business and IT meeting (embellished only slightly).

IT to Business: "Isn't KM just repackaging what is already on the intranet?"

Business to IT: "No … we are leveraging what is already on the intranet."

IT: "Oh. Okay. Did we do something wrong?"

Business: "No … But can I ask you a few questions?"

IT: "Certainly."

Business: "Is everything on the intranet still valid? Does anybody know everything that is out there? When was the last time the pages were checked for accuracy? Who is responsible for making certain the pages are up to date? How do they know when the pages need to be reviewed? Can you find everything that exists on the intranet using a search engine and how effective is the search engine? Do you want me to go on?"

IT: "No. I get your point. We need a knowledge management system."

The conversation won't be that quick or that easy. However, educating IT and teaming up with IT as a partner in knowledge management success is vital. Knowledge management doesn't just leverage the materials on the intranet. Knowledge management leverages the strengths of the IT department.

From the data administrators, to the database administrators, to the Web and portal developers and their ability to build component-based customization, to the network professionals, to the project managers, to the integration specialists … the knowledge management project will depend on all these folk's abilities to provide topnotch services and integration to the organization.

In addition, the better IT feels about their role in knowledge management, the less complicated the project management will be and the more likely the project will be successful. IT also holds the proverbial deck-of-cards when it comes to budget in many organizations. And IT will be used (perhaps with assistance from consultants) to deliver all aspects of the knowledge management system.

The IT and the business areas have to be on the same page working toward a common goal for a company to successfully manage their knowledge to impact performance.

Summary

As stated previously in this article, the exchange of knowledge is a two-way street: You have information and knowledge that other people don't have; they have knowledge that you don't have. Knowledge management doesn't come from implementing a portal. It comes from hard work, accountability, and a focus on leveraging what your company knows to impact company performance.

Sharing knowledge is a key to success. The way to achieve the "shared knowledge" pinnacle is through quality work on each of several focal areas of knowledge management.

This article has offered a very high level description of several focal areas of knowledge management. The "fuss" about knowledge management seems to be focused on the portal and the delivery of the knowledge. In reality, the portal is what the knowledge workers touch and feel. The portal has to be user-friendly, graphically appealing, easy to customize, easy to search, because if it is not all of these things, people will not accept it.

Behind the scenes, however, there is a lot of work that goes into making the knowledge of the enterprise available through the portal. The same holds true for data warehousing, ERP, and e-commerce efforts where the focal point often becomes what the end user will see. The truth is that knowledge management is not ALL about the portal.

Note: This article touches only briefly on seven focal areas of knowledge management. The intention in writing this article was to paint each of the focal areas with a broad brush, and paint back over each of the areas in separate installments of this article.

Please consider sending your experiences (a.k.a. your knowledge) of the management of these focal areas (or something similar) to the author at rseiner@tdan.com. The intent will be to incorporate TDAN.com reader's comments into the installment efforts that address each of the focus areas. Thanks.

---

Robert (Bob) S. Seiner is recognized as the publisher of The Data Administration Newsletter (TDAN.com), an award winning electronic publication that focuses on sharing information about data, information, content and knowledge management disciplines. Mr. Seiner speaks often at major conferences and user group meetings across the U.S. He can be reached at the newsletter at rseiner@tdan.com or 412-220-9643 (fax 9644).

Mr. Seiner is the owner and principal of KIK Consulting Services, a company that focuses on Consultative Mentoring or simply stated ... teaching company's employees how to better manage and leverage their data, information, content, and knowledge assets. Mr. Seiner's firm focuses on data governance/stewardship, meta-data management, business intelligence and knowledge management. KIK has developed a 4-Step Method© for Consultative Mentoring that involves customizing industry best practices to work in your environment.

For more information about Mr. Seiner, KIK Consulting Services and The Data Administration Newsletter (TDAN.com), please visit www.tdan.com and www.tdan.com/kik.htm.