Methods of acquiring knowledge can be classified into two major categories:
The second method can be further subdivided into:
These three methods of acquiring knowledge are not always completely separated, for example you can read about riding bicycles (2b) but then you still have to actually get on a bike and ride it (1), and you may have someone standing by giving you further advice on how to ride it (2a).
However, in the workplace, the separation of learning into each of these three categories is usually more complete.
Assuming in the first instance that you, the worker, are not on some type of apprenticeship, or internship, then for the most part you are not being paid to learn from experience.
And when it comes to learning something you need to know in order to do your job, everyone's time is considered precious.
So either you can learn what you need to know without social interaction, because it is available in document form, eg on the office intranet, or, it isn't available, so you need to find someone to tell you. When you find this someone, the relevant social interaction will be concentrated on communicating what needs to be communicated, and the other person won't want to spend time watching you trying to learn from experience, or watching you read documentation on the intranet.
Given the dichotomy between learning that requires social interaction, and learning which does not require social interaction, we can categorise knowledge to be learned as either socialized or desocialized.
Knowledge Management is defined (in Wikipedia) as the process of capturing, developing, sharing, and effectively using organisational knowledge (Wikipedia cites a source, but what appears to be an online version of that source does not contain that definition, or even the term "Knowledge Management").
This definition, by itself, doesn't necessarily rule out social processes of Knowledge Management, ie:
Nevertheless, implicit in most discussions of Knowledge Management, and certainly in most advertisements for Knowledge Management Tools, is that Knowledge Management requires the capturing, development and sharing of information via non-social interactions, in particular, in the simplest case, by writing knowledge down, into a document, and putting that document somewhere, ie on the office intranet.
The worst case of Knowledge Management failure is when some item of knowledge is only known to one person. The only way to do a task requiring that knowledge is for that person to do it. If the person gets sick, goes on holiday, dies, retires or gets another job, the organization is screwed.
A lesser case of Knowledge Management failure is where a number of people in the organisation do "know" the thing in question, but, no one has ever written it down.
If enough people know something, then the so-called "bus-factor" (ie how many people have to get run over by a bus in order to prevent stuff getting done) is larger, and the risk of total loss is reduced.
But, it is still problematic if the only way to acquire certain knowledge is via social interaction. And most Knowledge Management "Initiatives" necessarily include the assumption that the Management of Knowledge should be separated from "inside people's heads", which implies that:
Knowledge Management = The Desocialization of Knowledge
If "bus-factor" is the only motivation for the sharing of knowledge, then purely socialized knowledge sharing can, in principle, be sufficient.
But there are reasons why the full desocialization of knowledge is beneficial:
There are various reasons why people in an organization are oblivious to the socialized nature of organisational knowledge, and the consequent failure to desocialize. In many cases desocialization is not regarded as an important or significant goal, with perhaps an occasional observation that it would be nice if someone sometimes wrote important things down, just in case too many people go on holiday all at once.
Here are some factors that may prevent or create resistance to attempts to desocialize organizational knowledge:
Software source code seems, on first look, to be something that is very desocialized, because, by its very nature, it is written down.
However, the primary audience for software source code is the computer system that is going to run the software. Just because the computer system can read the source doesn't mean that any person can read the source code.
Other developers are only a secondary audience for the source code, and source code can very easily enter a state where it cannot be read very easily by someone encountering it for the first time, even if that person is an experienced software developer.
Some software enters a state where no one understands the source code, in which case you have already achieved a bus-factor of zero, which is not a good thing.
More commonly there might be one developer who understands, from his/her experience of the software, most of what is going on. So this developer can be tasked with improvements, bug fixes, etc.
If other developers need to work on the software, most likely those developers will consult, via social interaction, with the current developer who "knows" the software.
In this situation, the requirement for social interaction implies the existence of socialized knowledge, ie knowledge which has not been desocialized, which therefore constitutes a failure of Knowledge Management.
In other words, even though writing the source code involved writing a whole lot of stuff down, it was not written down in a way that enabled the desocialization of knowledge about the software application. The names of classes, variables and methods may not have been chosen to be descriptive enough and/or there were things which should have been written as comments but which weren't.
In many cases it's not just the implementation of the software which fails to be desocialized: often the requirements of the software have not been documented sufficiently, so social interaction is required to understand what the software is actually for. (Indeed sometimes one can understand how certain software works more easily than one can understand its purpose: "The program seems to be reporting the number of hoojamaflips wrongly" "Oh, I can see there is a one-off error in the accumulation logic - I can deploy a fix tomorrow. By the way, what is a hoojamaflip?" "Call Doug in the Purchasing Department – he knows that a hoojamaflip is.")
Database schemas are somewhat, but not exactly, like software application source code.
Most database schemas are not that large, if considered in written form, and compared to the amount of source code that might exist, for example, in a business Java application.
Nevertheless, database schemas can come into that category of information which is vitally important to the operation of the organization, and yet there are fundamental facts about the database which have never been written down.
A common problem with software source code is that objects in the software are given names, and these names later turn out to be less than ideal. Unfortunately the costs and risks associated with changing those names discourage attempts by developers to change them, and as a result the source code is full of names of things that don't quite mean what they say.
This problem is even worse with databases, since an organizational database can be used by so many different applications that things like table names and column names can never be changed, no matter how misleading or non-descriptive they may be.
Unlike most modern programming languages, databases often lack features for adding "comments". Or, if there are such features, they are risky to use. For example, comments can be added to the live production database. But this requires the executions of SQL against that same live production database with a database user that has write access. Due to the extreme importance of the live production database, SQL statements cannot be executed via a database user with write access without sign-off from three levels of management. Documentation may be "important", but of course it's never as important as up-time of the live production database.
In practice, the existence of "comment" features in SQL databases is a distraction, and the best solution to Knowledge Management for Databases is to have a tool which maintains information about each and every element of a database schema in some location other than the database itself (and which limits its interaction with the database to queries which help determine the list of things for which documentation is or might be required).