« Business-IT Convergence? What happened to Alignment? | Main | Linking Business Performance and IT Performance »

June 16, 2005

KM as a System

Often we define "benefits" quite simply -- as "needs that are to be satisfied". In daily operations, the needs that are perceived to be most challenging often seem so because they require use of assets that, on the occasion, seem to be either hidden or moving targets.

As a critical influencer on the organizational asset we call "knowledge", knowledge management (KM) needs to solve business problems, and it must do so both pragmatically and strategically. In asset management, the most important pragmatic strategy is focused on capacity.

How does capacity management pertain to managing knowledge? We're targeting the robustness of our ability to distribute good ideas effectively against any level of demand. Here, the concern is the marriage of intellectual assets that contain ideas, and digital assets that contain and carry the intellectual assets.

I.

Capacity here needs to be seen in two ways.

- One aspect is about the supply of "knowledge-delivery capability" available on demand. Typically, we want capability to be systematic. So, this looks at all components of what might be considered as, or developed into, the delivery system.

- Another aspect is about the supply of the content being delivered. We're concerned about whether the "right" content is available to deliver, regardless of the probable level of demand.

Consider how wide-ranging the elements might be to help the need . Dramatizing the point, what if an American workgroup needs to bolster a PDF proposal brief with an argument based on the latest concept update or breakthrough, but at that time the latest demonstration of the concept actually exists only in the form of a Shockwave clip in Italian used by the Milan sales office?

II.

Solving such an outrageous problem would be really great, and even circumstantially necessary. It might be a pragmatic motivator for a KM initiative -- but not necessarily sufficient as a basis for enterprise KM. Conducting knowledge-support of a business event such as this one might only be an ad-hoc procedure, a point-solution, or a one-off custom application.

On the other hand, if we look at what accomplishments that support ideally includes, we readily see the catalog of basic benefits from any kind of practical asset management. (Below, simply replace the word "asset" with the word "knowledge"...)

- Avoid unnecessary duplication of asset acquisition costs

- Maximize convenience and effective speed in the search for and discovery of needed assets

- Confidently secure rights to utilization of assets

- Sustain an optimal balance of asset quality vs. asset location

In those cases, we're happy to report that satisfying any one need usually offers a bonus by partially satisfying other needs too...

But to meet any of those needs, it's first necessary to create an infrastructure that supports the efforts for getting those benefits accomplished.

The most important efforts supported by the infrastructure usually sound like "best practices" that need to apply at all organizational departments and locations, and across their functions.

1. Optimize asset storage and retrieval through classification

2. Establish "version control" in the use of similar assets

3. Continuously track asset distribution and asset changes, against type of user and type of usage

4. Proactively manage demand on assets

Overall, these practices sound like a job for a sophisticated system. And they are not the only justification.

III.

The idea that "knowledge is an asset" ckearly makes sense... But this idea deserves some refinement.

For example:
- we can easily appreciate that there is a big difference between data and concepts. The nature of that difference is that concepts are all about "meaning" while data exists happily outside of that.
- Similarly, there is a difference between information (which is a lot like data) and knowledge (which is a lot like concepts).

Now, we're used to the idea that our information systems manipulate our data.

But how about a knowledge system that manipulates our concepts?

The motivation for doing that would not be unusual at all. We attach value to data in the context of the meanings we think the data will help to generate. Attaching value to it is what makes us think of data as an asset. In the same way, we come to think of information as being an asset -- if information supports concepts then it is generating meaning, in the form of knowledge. We attach value to the information, and so we think of the information as an asset.

Treating things as assets is a real sign that we care about them! We tend to build systems to be sure we will take care of them effectively.

Primarily, the reason why we think concepts are important is because they help us get things done, which is a subtle but critical observation. When we say what concepts "mean" to us, we're normally talking about their usefulness, not their intrinsic enlightening qualities. Likewise, the context that makes knowledge valuable, and that makes it an "asset" to manage, is its application.

This emphasizes the need to make knowledge "available for application", which zeros in on the set of practical issues that a KM infrastructure and system must address.

If we have a "knowledge system" to manipulate our concepts, the key manipulations are those very same moves -- i.e, best practices -- that support satisfaction of the needs we initially listed above.

IV.

To enable those manipulations, concepts will have to be "captured" and packaged in portable form. In looking (as we do below) at the range of techniques that meet this requirement, it quickly becomes apparent why so many different kinds of tools are brought to the KM effort.

Meanwhile, it's most important to see this packaging from the "knowledge consumer's" point of view. We refer to the package delivery and acceptance together as "transfer of knowledge" -- which precedes the consumer's application (use) of the knowledge.

In knowledge-transfer, there are three success factors: concepts must be (a.) deliverable; (b.) understandable; and (c.) relevant. Without these factors, the knowledge transfer effort risks simply becoming information exposure.

1. Concept delivery:
- Conversation packages concepts and transports them from one person to another. Memory makes conversation repeatable. Requirement: the ability to engage anyone who remembers the conversation or who originated the concept.

- Documentation provides a "proxy" for engaging the concept originator or other concept holders. Not being interactive, documentation has to be tailored in advance to the presumed interpretive abilities of the recipient. Requirement: the ability to use a medium (language, format, etc.) that offers fidelity to the description of the concept. [Two sidebars here. One, just because something is animated doesn't mean it is interactive. Two, form should follow function, but the medium can definitely hide the message; I own one of the only remaining copies of the Excel Users Manual in Polish: fascinating as a curiosity and, since I never learned Polish, absolutely meaningless to me as instruction.]

2. Concept recognition:
- Categorization allows one concept to be identified in more than one way, and it also allows multiple concepts to be identified in one way. This keeps differences amongst types of users (and their differing points of view)from preventing identification of the potential usefulness of the concept. Requirement: the ability to cross-reference concepts with types of usages.

- Translation allows different types of users to grasp the same concept through different means. Requirement: ability to generate, maintain and identify multiple versions of the same designated concept.

3. Concept incorporation:
- Comparison takes into account the fact that the awareness of how to use a concept may be a sudden and/or unprecedented event, because the usage situation may not have called on the concept before. Although we usually have a good idea of how often previous problems have been addressed with previous concepts, it is relatively mysterious as to when and where a genuinely new problem will occur, demanding research. Here the immediate point is to make the research easy. Requirement: ability to test or certify the relative quality of a concept for the purpose -- including testing concepts against other concepts.

- Protocol governs the communications behavior between two parties, factoring in the known or suspected impacts of certain modes of (as we usually call it) information transfer and knowledge transfer. Requirement: ability to manage users' access rights to concepts by profiling users.

As we step through those three success factors, looking for the combination of concept availability and concept usability, we can imagine everything ranging from teleconferencing and IM, to voicemail/email and blogs/portals, to taxonomic systems and concept matching and XML, to content management and artificial intelligence and business rules. Along with myriad other tools and approaches, these help to construct an infrastructure for KM. Integration of these into a knowledge system is part art, part science and likely to be an ongoing evolutionary effort.

Then, in executing processes that manage knowledge as an asset, the general conversion of ideas into "reusable content" becomes a routine expectation of the population of knowledge-users.

V.

With that expectation in place, management has a couple of even bigger fish to fry.

One, when users see other users as the knowledge provider, there are many issues, particularly of protocol, that social relationships have resolved but that are largely undetermined and unresolved between users who don't know each other. KM requires intervention on a level of cultural norms, changing norms to accomodate successful interactions explicitly independent of social relationships yet compatible with them. Unlike in academia, most companies have not readily organized their protocol around knowledge-peer networks that rival the authority of the org chart...

Two, if the idea of usefulness is not being managed, then the idea of managing knowledge availability loses a lot of its value. The single most hospitable environment for KM is an environment in which the population's common awareness of the organization's strategy is very high, driving the perceptions of resource usefulness. Strategy Management should be assessed as one of the very first steps in planning the development of a Knowledge Management practice in the organization.

Posted by Malcolm Ryder at June 16, 2005 7:06 AM

Comments

Post a comment