David Weinberger
KMWorld Archive
This column is part of an archive of David Weinberger's columns for KMWorld. Used with permission. Thanks, KMWorld!


Link to Original at KMWorld  Index

David's home page | Bio | Speaking | Everyday Chaos

The Turing test for business

01 February 1999

"Oy, just what we need: another distinction!

I'm just getting awfully confused as "knowledge" gets applied to everything from the relationship of beer and diapers to Aristotle's Metaphysics.

In a sense, knowledge is like data. Before we had data management systems, corporations didn't have anything they called data. Likewise, before we had knowledge management, corporations didn't have anything they thought of as knowledge. But, while it was clear from the beginning what data management systems do, it still isn't completely clear what knowledge management systems do.

As a result, we're all damned confused about this damn knowledge stuff that we simply must have because what self-respecing business would admit, "No, we actually don't have any knowledge."

There seem to be several main ways of taking "knowledge." In one sense -- perhaps the most common because knowledge in this sense is the easiest to manage -- knowledge is the useful relationship among pieces of information. For example, men who buy diapers at the convenience store also tend to pick up a six pack of beer. Discerning relationships among data is in fact what we used to call "information" but for some reason, we seem to want to call it knowledge if it's up a single level of abstraction.

Another view of knowledge is that it's know-how. Know-how is important and we have a really good word for it: Know-how. You don't have to do data mining to find know-how: you have to gather it from your field people (and others) who have it, you have to check it to make sure that your field engineers aren't fixing airplane wings with Silly Putty, and you have to make it available. In short, this type of KM is primarily a publishing problem.

Then there's a third type of knowledge. This isn't statistical relationships or hands-on knowledge. It's what we call, in English, "ideas."

Managing ideas is different from managing the other two types of knowledge. The problem with ideas is having them in the first place, getting someone to listen to them, and then seeing if they make sense. Systematizing this is probably wrong. Rewarding people for having ideas -- good and bad -- is probably right. How wrong could you go by providing low-humiliation spots on your intranet where ideas can be spawned, hatched, and squished like the little cockroaches most of them are (um, I mean, acted upon, making your organization into an innovation-driven market leader).

But, whatever you do, keep the three types of knowledge separate in your minds. For one thing, they live in different strata. Knowledge mining is in the province of marketing data wonks. Know-how is in the province of people doing hands-on work with customers. Idea development generally is the job of office workers in various departments -- although good ideas can come from anywhere, of course (whereas the sources of bad ideas are usually easier to identify).

And, for another, how you "leverage" all three types of knowledge is different: you mine the first type of data, you publish the second, and you encourage the third.

One good way to avoid confusing these three distinct things would be refrain from calling any of them knowledge. Alternatively, we might want to start calling everything knowledge, including slogans, newsletters and the sounds and smells of strategy emanating from the executive washroom. By blurring all these distinctions, your organization can rapidly become the knowing-est of all.