Of Data and Knowledge
A thought provoking and insightful post at Thinking Faster entitled “Centralize data, decentralize knowledge” suggests we should centralize data, but decentralize knowledge in a corporate environment. Centralize the ‘what,’ but leave decentralized the who, where, why and how.
Key is the comment, “I think it is probably more important 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.”
This is reminiscent of Wurman’s comments in Information Anxiety 2 where he reminds us that conversation is a tool for creating understanding. Face to face conversations involve so much more than simple content and are filled with subtle clues and insights that enable understanding, or at least facilitate it. And, interesting, he also suggests conversations are implicit directions.
So what does this suggest for the company struggling with information sharing problems? It seems that instead of, or at the beginning of, a ‘knowledge management’ project, a focus on the data, the data/information architecture, the places-to-put-things, the identification of knowledge/information resources – including people! – and the sharing of this ‘directory’ of information resources will lead to the foundation of a knowledge-enabling environment. A bottom-up approach.
Critically, creating, pruning and adding to this directory must necessarily involve the content authors and owners though, as well as IT, “…who is very good at aggregating and building data warehouses and storage facilities…” Information is just data and data is just noise if you don’t understand the context.
That reminds me of Kurzweil in The Singularity is Near where he says that random noise is pure information and cannot be compressed, while a checkerboard contains less information and can be described much more simply. To IT the table of data is pure information, to the chemist, the average pH is 7.0 plus/minus 0.1. Data becomes information.
And how important is it to consolidate and aggregate the data and information? If you can identify the resources are you done, right? In any case, the hard work is identifying where all the good stuff is. Now that you know where it is, simple corporate inertia and a smaller (perceived?) ROI might stall consolidation efforts: if you know where everything is, why move it now? You can link to anything…but then maybe creating the links is aggregation.
Concurrent with the bottom-up focus on defining the information resources, a top-down approach might also prove useful. Now that we know-where-things-go, we need to define, and encourage the use of, processes for adding to the information-base. This includes training in the use of the information resources and the resources directory as well as coming up with defined ‘publication processes.’ Again, IT may not always be the place to turn in this area, and peer-training seems important.