THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com October 2000

Introduction

For individuals that have not lived through a knowledge management project, what is known about the 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 buzz-word of “enterprise portals” is ranking right up there with the buzzword “data warehouse” of a few years ago. Portals are here to stay (rightly so) and pretty soon everybody will have one (or more than one – although one would suffice).

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 ...

• For a text book description … Knowledge management is the discipline of spreading the knowledge of individuals and groups across the organization in ways that directly affect performance. (1)
• A reality-based description 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. (2)
• 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 both ways -- 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 is the first of a series that addresses the “trenches” of knowledge management and the core areas that require focus in order 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

Note …

A few quick items to point out before getting started … “culture change” will be addressed two times 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 damn 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 pointed out is the striking similarities 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 as one of the components of knowledge management and close to the end. This doesn’t mean that portals are not important. In fact that couldn't be farther from the truth … The portal is the part that the business and IS areas will focus on. The portal has to be great. Knowledge workers get acclimated to use the portal to send and receive knowledge on a regular basis. Therefore, it is certainly an advantage to have strong (and quick) developers and a catchy portal design. BUT after reading this article (and the ones to follow) you will realize … “It’s Not ALL About the Portal”.

Component-Based Architecture

Architecture is a word thrown around in big business and recruitment circles (recruiting business architects, data architects, solution architects, ... is a tough task these days). Architecture includes a plan that synchronizes business issues with resource deployment and technology solutions. The plan includes the leveraging of people, existing hardware and software, the incorporation of new hardware and software, and 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 address the requirements.

So … what makes up a knowledge architecture? A knowledge architecture is made up of several components. These components address the who-s, what-s, and how-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.

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 the 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. (3)

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.

Note …

For more information about a component-based architecture for knowledge management, please visit the article titled “A Component-Based Knowledge Management System” written by Tom Finneran and published in TDAN.com in June of 1999 – see linkhttp://www.tdan.com/i009hy04.htm.

Stewardship & 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 individual’s ”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 (every day 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 and does one of two things – 1) what they "think" is right – or 2) wait until the senior person becomes available. There are risks associated with each of these option.

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 & Classification & 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 (check list, project plan, account summary, etc.) -- when it needs to be reviewed -- … and on and 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 that focus on entering submitted pieces of knowledge.

The more detailed the classification, the easier it will be to narrow the search. Also, 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, a spreadsheet, diagram, plan, … anything 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. A drawing on a napkin over lunch is not an artifact -- A phone conversation is not an artifact -- A series of emails is not an artifact -- A video-conference 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. Later in this article, collaborative forums such as threaded-discussions, virtual meetings, chats, video conferences and emails will be discussed in terms of converting them to artifacts. 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 is 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. Here is how some of these technologies are related to knowledge management …

• Document management and imaging is related because a large percentage of the organizations 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 in the previous section. 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-s” of knowledge management. Content management focuses on the “what-s” of knowledge management. The “what-s” 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, and 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 on and on) that can be consistently supplied and applied (“plugged in”) 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 (lowered worker’s compensation claims, less rework, lower number of resources needed, less time to market, …).

Once the core areas of knowledge management (the “hows” or earlier sections 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 the successful delivery of knowledge management will still have yet to happen. Spending time classifying and organizing knowledge outside the defined scope is okay (this information will need to be classified some day 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, even if they are not awake at the same time.

Collaborative forums are events where multiple individuals can offer their knowledge for a centralized purpose either 1) linearly (in a threaded textual discussion) or 2) in real time (virtual conferences, video-conferences, chats – although chats 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 exist. The true difference is in the number of chefs 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 use of that playback may be to either view the video directly or for the video to be 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. Chats with more then a few people are more difficult to manage without the effective use of a facilitator.
• Emails can also be knowledge forums is ways similar to the threaded discussion and chat. An email or a dialogue of emails can be recorded and converted into artifacts. Also, individual emails 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 emails address – such as knowledge@mycompany.com -- for individuals to submit emails as potential artifacts.

Portals & 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." In fact, if this were a knowledge management presentation, we would be just about ready to demonstrate the portal for you. We have purposely kept it under wraps this long just to build your anticipation. Now we are ready to unveil …

Hey, wait a minute … that looks a little like “my-yahoo” or “my-iwon” or any of a variety of my-portals that are available in the internet.

So what did you expect.

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". The development of a portal requires that attention is paid to several portal components ...

• Customizable bookmarks and folders
• Dynamic and customizable links and icons
• Collaboration tools
• Connection to all existing applications (word processing, spreadsheets, ...)
• Connection to all user defined short-cuts
• 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, ...)

Customization is extremely important. Through authentication and security, the knowledge worker can be recognized for who they are and they will see a specific customizable view of the portal. This requires the use of a separate database that houses the user's customized selections stored and managed by user id.

Customization makes it such that 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 a specific worker to see
• "soft" content - weather, package tracking, stock quotes, sport scores, ...
• "other" content - business specific content that add to the knowledge worker's experience
• content "order" - how the content is displayed on the portal

Note …

One client has gone as far as saying that the portal will be "THE" desktop or the default screen that knowledge workers (everybody) will see when they turn their computer on. Everything the user needs will be available through the portal including access to word processing, spreadsheets, presentation tools, ... and all of the short-cuts that have been defined on their present desktops. Certainly the knowledge workers can view Gate's gate (Windows ... or the operating system of choice) if they want to minimize the portal but this will be frowned upon. This client has also included a "quote of the day", "hot-line messages", and several other bell and whistles that make the portal a place people want to return to.

Knowledge Communities & 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) that have done what you do and who could probably offer a few pointers. You have something to offer to them too.

From a business perspective … 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 don't know each other exist (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 leap over.

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 a manual needs to be read 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 and it will not be 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 these folk’s ability to provide top-notch 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 utilized (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 earlier 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.

But ... you and I now know that behind the scenes 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 only touches briefly on seven focal areas of knowledge management. The intention of 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. The intention was for the article to carry under 2,000 words. Slowly each focal area required a broader but still descriptive definition and slowly the number of words crept up close to 4,500. However, justice still wasn’t served to any one of these focal areas and rest assured that there is much more to be said in future installments.

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.

(1)A Component-Based Knowledge Management System by Tom Finneran of CIBER, Inc. in The Data Administration Newsletter (TDAN.com) Issue 9.0 in June 1999. http://www.tdan.com/i009hy04.htm

(2)A Component-Based Knowledge Management System - Finneran - TDAN.com Issue 9.0 in June 1999. http://www.tdan.com/i009hy04.htm

(3)A Component-Based Knowledge Management System - Finneran - TDAN.com Issue 9.0 in June 1999. http://www.tdan.com/i009hy04.htm

A special thank you to Tom Finneran and Bill Smit - my friends and colleagues -- Tom, for your introduction to knowledge management and your assistance in becoming well-versed on the topic -- Bill, for your focus and persistence in doing what is right and always looking for better ways.