Portal progress and knowledge management: the framework

By Joseph M. Firestone

Very early in the portal revolution, Sarah Roberts-Witt characterized portals as "knowledge management's killer app." I think that view is a myth. Portal vendors still have a long way to go before their products approximate the Enterprise Knowledge Portal, a benchmark-to-be I formulated at about the same time as Roberts-Witt's characterization. So how much progress have portal vendors made in offering products that really do support knowledge management?

In this column, I'll evaluate products and the support they provide for knowledge processing (KP) and knowledge management (KM). To begin, however, I'll define knowledge management and what I mean by support for it. And I'll outline a framework, developed by Mark McElroy and myself at the KMCI Research Center products do (or don't) provide support for KP and KM. That framework is called The New Knowledge Management (TNKM). In later columns, I'll apply the framework to portal products, reviewing each one through its lens and assessing it accordingly.

Processes

Let's begin with decisions and actions. Decisions produce actions, and actions--activities--are the stuff of which social processes, social networks and (complex adaptive) social systems are made. Now let's distinguish three categories of business processes:

• operational business processes;

• knowledge processes, and;

• knowledge management processes.;

Operational processes are those that use knowledge but, apart from knowledge about specific events and conditions, do not produce or integrate it.

There are two knowledge processes: knowledge production, the process an agent executes that produces new generalizing knowledge, and knowledge integration, the process that presents the new knowledge to agents comprising the producing agent.

There are nine knowledge management processes, which are listed later. For now, note that their purposes are to enhance knowledge processing, to perform KM-level knowledge processing and to integrate the knowledge management function itself.

Knowledge processes

Knowledge production is a process made up of four task clusters (or sub-processes):

• information acquisition;

• individual and group learning;

• knowledge claim formulation, and;

• knowledge claim evaluation. ;

Knowledge integration is made up of four more task clusters, all of which may use interpersonal, electronic or both types of methods in execution:

• knowledge and information broadcasting,;

• searching/retrieving;

• knowledge sharing (peer-to-peer presentation of previously produced knowledge), and;

• teaching (hierarchical presentation of previously produced knowledge).;

Among the eight sub-processes above, it is important to remember that individual and group learning is itself knowledge processing. Individual and group learning produces knowledge claims for consideration at higher levels of analysis of knowledge processing. But at the individual and group levels themselves, learning is knowledge production, and depending on the group level, all four task clusters are involved at that level too. Let's call it the "nesting" of knowledge processing in the enterprise.

Knowledge outcomes

Knowledge processes, of course, produce outcomes. From the KMCI point of view, knowledge is an encoded, tested, evaluated and still surviving structure of information that helps the adaptive system (agent) that developed it to adapt.

Two types of knowledge are important in organizations:

(1) tested, evaluated and surviving beliefs or belief predispositions (in minds) about the world, and

(2) tested, evaluated and surviving, sharable (objective), linguistic formulations (knowledge claims) about the world.

There are also other outcomes of knowledge processes, the most important of which are knowledge claims about (1) and (2) . . . the track record of knowledge claim evaluation.

The various outcomes of knowledge processes may be viewed as part of an abstraction called the Distributed Organizational Knowledge Base (DOKB). The DOKB has electronic storage components, but it is more than that because it contains all of the outcomes of knowledge processing in documents and non-electronic media. And because it includes beliefs and belief predispositions as well, it also includes all of the mental knowledge in the enterprise.

How things work

Here is how things work in TNKM. Operational business processes are performed by agents who use previous knowledge in the DOKB, both mental knowledge and knowledge in organizational repositories to make decisions. Sometimes the DOKB and an agent's perceived situation doesn't provide the answers it needs. A problem has arisen--an epistemic gap between what an agent knows and what it needs to know to participate in the business process. In the KMCI view, such a problem initiates knowledge processing, specifically a new knowledge production process. Once the problem is perceived, there is a need to formulate tentative solutions. Those can come from new individual and group learning addressing the problem, or from external sources through information acquisition, or from entirely creative knowledge claim formulation, or, of course, from all three.

Where the tentative solutions come from and in what sequence are of no importance to the self-organizing knowledge processing pattern of knowledge production. The only important thing about sequence here is that knowledge is not produced until the tentative solutions, the previously formulated knowledge claims, have been tested and evaluated in the knowledge claim evaluation sub-process. And that sub-process, Knowledge Claim Evaluation (KCE), is the way in which agents select among tentative solutions, competitive alternatives, by comparing them against each other in the context of perspectives, criteria or newly created ideas for selecting among them to arrive at the solution to the problem motivating knowledge production.

Knowledge Claim Evaluation

KCE is at the very center of knowledge processing and knowledge management. Think about it. Without KCE, what is the difference between information and knowledge? How do we know that we are integrating (broadcasting, searching/retrieving, sharing or teaching) knowledge rather than just information? And finally, how do we know that we are doing knowledge management and not just information management?

Once knowledge and other tested and evaluated information are produced by KCE, the process of knowledge integration of the solution begins. There is no particular sequence to the integration sub-processes listed earlier. One or all of them may be used to present what has been produced to the enterprise's agents or to store what has been produced in the various repositories in the enterprise system.

Those agents receiving knowledge or information don't receive it passively. For them, it represents an input that may create a knowledge gap and initiate a new round of knowledge production at the level of the agent receiving it. Integration of the knowledge, therefore, doesn't signal its acceptance. It only signals that the instance of knowledge processing initiated by the first problem is over and that new problems have been initiated for some by the solution. For others, the knowledge integrated is knowledge to be used--either to continue with executing the business process that initiated the problem or at a later time when the situation calls for it.

Knowledge LIfe Cycle

Either way, the original problem that motivated knowledge processing is gone. It was born in the operational business process, solved in the knowledge production process, and its solution was spread throughout the organization during knowledge integration, and in that way, it ceased to be a problem--i.e., it died. That pattern is a life cycle, a birth-and-death cycle for problems arising from business processes.

The life cycle gives rise to knowledge, both mental and cultural (linguistic), and so we call it the Knowledge Life Cycle (KLC). Every organization produces its knowledge through the myriad KLCs that respond to its problems: KLCs at the organizational level and KLCs at every level of social interaction and individual functioning in the organization. It is through the KLCs that knowledge is produced, and the organization acquires the solutions it needs to adapt to its environment.

Organizations differ in the profile of their KLCs. They acquire information in different ways. They formulate solutions in different ways. They integrate them in different ways. And above all, they evaluate tentative solutions in different ways. Organizations also differ in the patterning of their knowledge outcomes. They have different procedures for doing things, different software capabilities, different sales forecasting models, different performance monitoring schemes.

KM processes

Knowledge Management is the set of processes that seek to change the organization's present pattern of knowledge processing to enhance both it and its knowledge outcomes. That implies that KM doesn't directly manage knowledge outcomes, but only impacts processes, which, in turn, impact outcomes. For example, if one changes the rules affecting knowledge production, the quality of knowledge claims may improve, or if a KM intervention supplies a new search technology based on semantic analysis of knowledgebases, that may result in improvement in the quality of models.

There are at least nine knowledge management processes:

• symbolic representation;

• external relationship building with others practicing KM;

• leadership;

• KM-level knowledge production;

• KM-level knowledge integration;

• crisis handling;

• change in knowledge processing rules;

• negotiation for resources with representatives of other organizational processes, and;

• resource allocation for knowledge processes and for other KM processes.;

KM-level knowledge production and integration reflects the idea that KM may also be about responding to epistemic gaps arising from knowledge management operational processes themselves. The change in the knowledge processing rules process, for example, may develop epistemic problems. In that case, KLCs at the level of KM processing will be initiated and will produce and integrate new knowledge about how to change knowledge processing rules to enhance information acquisition, knowledge claim evaluation or one of the other sub-processes of the KLC.

IT applications and KM

When is an IT application a knowledge processing or management application, as distinct from an information processing or management application? I think part of the answer lies in the framework presented earlier. With the framework as background, the short answer to the above question is that an IT application supports knowledge processing to the extent that its use cases support the eight sub-processes of knowledge production and integration discussed earlier. Further, it supports KM to the extent that it supports the nine knowledge management processes.

Some may think that an IT application supports KM if it performs content management, or if it supports collaboration, or if it performs data mining. But I think the connection between those and other types of applications and knowledge processing and KM is at best indirect, and at worst very tenuous, because each such application may or not provide support for the knowledge or KM processes. In each case of an IT application, therefore, the connection from the application in question to knowledge processing and KM use cases must be demonstrated. The connection is simply not self-evident because the application in question is a content management or a collaborative application.

Portals, knowledge processing and knowledge management

The point I've made in connection with IT applications, in general, applies with equal force to enterprise information portals. Whether any particular portal product or solution supports knowledge processing and KM is not a question whose answer should be assumed. The answer instead should flow from careful analysis of the extent to which a product or solution supports the eight knowledge processes and/or the nine KM processes . . . and whether, in so doing, it aids knowledge management in enhancing the KLCs within an organization, and with them the organization's adaptive capability.

When a portal product provides appreciable support for KLC and KM processes, and especially when it supports the critical KCE process, it is proper to call that portal an enterprise knowledge portal (EKP). But until then, we should resist using that term and recognize that however desirable the halo effect of the name, the application involved is one that has not yet crossed the line from mere information processing and management to knowledge processing and KM.

In future columns, I'll analyze products from the point of view expressed here. Frankly, I don't expect to find any EKPs out there yet. What I do expect to find, however, is progress toward them: support for use cases that are closely related to those that might support critical knowledge processing and KM functionality, architectures that fulfill requirements and conditions that the knowledge portal will need, products that make use of intelligent agents in ways that would be necessary for the knowledge portal, uses of XML in semantic networking, applications that track the history of collaborative efforts at problem-solving, and other advances. I'll chart such progress and in each case attempt to evaluate how far away the portal is from crossing the finish line to become KM's first true "killer app."

Joseph M. Firestone, Ph.D, is co-CEO and executive VP of the Knowledge Management Consortium International (kmci.org), CKO of Executive Information Systems (dkms.com), and author of "Enterprise Information Portals and Knowledge Management," KMCI Press/Butterworth-Heinemann, 2003, e-mail eisai@comcast.net.