The IT industry seems to have a habit of creating a new technology, over-marketing it and then spending several years making it work. Often, by the time the technology becomes viable and offers true business benefits, it has gained such a bad reputation that vendors face an uphill battle to sell it. Either the technology then fails or a new term must be created in order to sell it. Past examples here include artificial intelligence, expert systems, computer-aided software engineering, business process reengineering and, the focus of this column, knowledge management.

I decided to write this column because at a recent conference, I commented that knowledge management is at last practical, but we may have to find a new term to market it. Several people came up to me afterward and said they agreed with me that knowledge management is now viable, but they dare not use this term in their organizations because of its past false promises. Should we, therefore, try to correct the current misconceptions about knowledge management (KM)? Or, should we invent a new term for it? If so, what is the best term to use? Regardless, how does business intelligence (BI) relate to KM, and how do we use BI and KM together for the benefit of business users? These are some of the questions I want to address here.

Before discussing knowledge management in more detail, let's explore three related terms: data, information and knowledge. A Google search reveals a variety of different, interesting and sometimes confusing definitions. The ones I like the best are:

  • "Information is data and facts that have been organized and communicated in a coherent and meaningful manner."
  • "Information is the result of processing, manipulating and organizing data in a way that adds to the knowledge of the person receiving it."
  • "Knowledge is information associated with rules that allow inferences to be drawn automatically so that the information can be employed for useful purposes."
  • "Knowledge is what is known by perceptual experience and reasoning. For example, 1,234,567.89 is data. 'Your bank balance has jumped 8,087% to $1,234,567.89' is information. 'Nobody owes me that much money' is knowledge, and 'I'd better talk to the bank before I spend it because of what has happened to other people' is wisdom [and also, of course, a business decision]."

In a BI system, data (from a business transaction system, for example) is changed to information by BI applications analyzing the data and putting it into a business context. This information is then converted to knowledge by people applying their expertise (i.e., existing knowledge) to the information. The resulting knowledge can then be communicated to other people verbally or via an e-mail or report, for example. A historical record of these interactions may be recorded in a content management system.
The creation of knowledge can be automated by defining a person's expertise as a set of business rules. These rules can then be applied to the information produced by a BI application and an appropriate recommendation made or action taken.

A knowledge management environment should, therefore, provide users with easy access to the data, information and knowledge they need to do their jobs. It should also provide tools that allow users to communicate with each other, share information and knowledge, and discover other people in their community who have expertise that may add value to ongoing projects. Key technologies associated with KM include business intelligence and data warehousing, collaboration, content management and portals.

The challenge for KM to date has been the complexity of bringing together and integrating the diverse set of technologies, files and databases that are used to manage data, information and knowledge in an organization. Like many technologies, KM implementers have the choice of building an enterprise-wide solution from the top down or creating departmental solutions from the ground up. The top-down approach results in a well-integrated and consistent solution but will have a longer development time, even if it is built iteratively. Bottom-up approaches provide faster payback, but often lead to a disintegrated environment.

Claudia Imhoff recently sent the November/December 2004 supplement to KMWorld to me for comment. This supplement contained an article by Andy Moore, the KMWorld editorial director, which suggested that knowledge management had failed in the past because companies were trying to build enterprise-wide knowledge stores, rather than focusing on more localized departmental solutions. This statement reminds me of the many debates in DM Review and other venues on data marts versus the enterprise data warehouse and, more recently, on departmental versus enterprise portals.

Most debates on departmental versus enterprise solutions (really bottom-up versus top-down development approaches) often muddle logical and physical concepts. They also focus on data and information integration, rather than on the real problem of providing a common understanding of business information between projects and departments (i.e., on providing consistent meta data and meta models).

Departmental versus enterprise discussions are the wrong way to approach projects, regardless of whether we are talking about data warehouses, knowledge management or portals. We should be thinking in terms of the role each business user has in an organization, the information and knowledge he or she needs to perform this role and the community (or communities) to which he or she belongs that need to collaborate and share information. Each community needs its own knowledge management environment and associated community portal, content store and data warehouse. The various technology components of the community are connected via a common business model of the processes and activities carried out by the community.

Inevitably there will be a need to share information and knowledge between communities. This will especially be the case as projects move up the information food chain from supporting operational applications to tactical and strategic ones. Intercommunity projects will need to be driven and funded by senior executives or by a LOB executive who sees the importance of shared information and knowledge. An example would be a VP of sales who wants to ensure that the supply chain can support an increased level of demand caused by a new sales and marketing campaign.

In a cross-community project, the key to success will be the common understanding and sharing of business meta data. How these projects and their underlying knowledge, information and meta data stores are physically implemented will vary based on performance requirements, data cleanup needs, products used and so forth. The important thing is that the logical business view of the community will remain the same, regardless of physical implementation.

Returning to the questions I outlined at the beginning of this column, I think we should not create a new term for knowledge management. We should instead highlight the fact that knowledge management is at last viable and involves the bringing together of portal, content management, collaborative, and business intelligence technologies and products into a single information and knowledge framework. This framework should support both individual business user communities and also intercommunity communication and sharing of information and knowledge. 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access