Centralize data, decentralize knowledge

As a followup to a previous post, it seems to me that there are two dominant paradigms we should consider when thinking about our corporate knowledge.  It seems we should consolidate documents, transactions and information, and decentralize knowledge.

From a documents and data standpoint, it makes sense to centralize this stuff.  IT is very good at aggregating and building data warehouses and storage facilities, and this information lends itself to centralized management.  Once a document is created or data is generated, it rarely changes and if it does there's probably a record of the change.  Many people have greater access to data that is centrally stored and managed.  Additionally, data in these forms usually has "meta-data" associated with it that helps individuals search and find the information.  That makes the information more accessible and more useful.

Knowledge, however, is a much more difficult thing to "manage".  Knowledge is situational and specific to certain contexts and events, and changes frequently.  Rather than attempt to consolidate knowledge, we should attempt to keep knowledge decentralized but understand "where" it is and "who" has it.  To a certain extent we are trying to create a "hub and spoke" system for managing corporate information assets.  Hard, physical data and documents are stored at the center and constantly consolidated and aggregated.  Knowledge provides the spokes to connect the data and how to interpret it with the users of the information.

Many have tried to create centralized knowledge management.  It is an exceptionally difficult thing to do, since knowledge changes so frequently and is often so much more difficult to classify.  One almost needs an artificial intelligence search engine just to classify and find "knowledge" in a business.  I think it is probably more inportant to understand who is the "expert" or "master" of a particular bit of knowledge or experience, and allow people to tap into that through interaction, rather than attempt to have the "expert" record his or her knowledge in a database.  In that regard, it's more important to know who is the expert, rather than to document what the expert knows.

Centralized knowledge management systems are difficult to use and configure for this reason.  Often, it takes a long time to understand what people know and how to understand what they know in a particular context.  However, in a very brief conversation, if I know who to speak with I can gain insight and value from what a person knows very quickly.  This is an area of information management that humans still do much better than machines.  We can accept some fuzzy inputs, match them up to some fuzzy requirements and redirect a conversation that will have value for us.

So, the argument here is that "hard" information should be stored and managed centrally, but "knowledge" should be decentralized and managed to understand "who" the experts are and "how" best to contact them, rather than expect them to dump the contents of their heads into a managed database.

Comments

[Waseem Sadiq]

Hi,

At Macaw (www.macaw.nl) we are trying to achive exactly this by building a social network to be able to answer questions like "who knows something about what". We do this by identifying the relationships that exist between (in our case) people, projects, technologies and even artefacts like blog-posts.

Just thought you might find it interesting to know that we are kind of implementing this idea in software :-)

[futhermet]

Your comments here are very insightful. Thanks! I might suggest a few points regarding implications for a company struggling with their information sharing problems including where to begin, who to involve, and other facets to consider: Critically, while IT is great at aggregating/building solutions, content authors and consumers had better be involved, too. And while attention on consolidation might be a bottom-up path to a cohesive KM environment, both a top-down publishing-process paradigm and a content-author training strategy might be useful to deploy now that we've decided where data and information should go.