Submitted by Joseph Brown
in
Any advice for a knowledge management (KM) department? I've joined a KM department in an oil and gas service company. The company got bought by a larger company, but the larger company did not have a KM department. The larger company saw the success the KM department had in the smaller company and wants to spread the km culture to the rest of the company. So we've been tasked with the responsibility of assimilating the other business units. Any advice on this subject? Any advice on KM in general? Any good books on KM?
Submitted by matt porritt on Wednesday February 25th, 2009 3:43 pm

What do you do differently that defines your KM culture?

Let's work from the big picture down.

Start with general practices - "We are proactive about collecting facts and information"

Then get into specific behaviors you do to display the general practice - "We email all data sources monthly asking for information. We send out reports to area directors on our collection process and the value it achieves."

List a few like this, and we can start giving you more specific advice about how to implement.

Submitted by Sam Baskinger on Wednesday February 25th, 2009 4:00 pm

... that as a developer, we almost never speak of knowledge management. Embarrassingly pathetic, in some ways. :)

Submitted by Joseph Brown on Friday February 27th, 2009 11:21 am

Well one reason I'm on a search for KM information, is that we don't know how other companies do KM and we'd like to see how we compare. I'll explain what we do.

We have a database on our intranet where people submit documents that could be proposals, failure reports, one page marketing material, lessons learned and things like that. These documents are reviewed for technical competence, spelling and grammatical errors, and trademark/copyright issues. Each submission in the database has a front page where a title, summary, and more detailed information is shown. Each submission can have multiple files attached, it depends on the subject of the submission.

This database is also used to store helpdesk tickets for solving problems that may come up. Such as a need for pictures of certain products on spec sheets. Or if there is a need for a new product, the needed specs are requested, and then it is used to keep track of the needed approvals and the creation process. These are just two examples.

This database is also connected to a search engine so a user can easily pull up information they may require. We also classify each submission with multiple tags so a user could also browse the classification structure and find submissions.

We also use a forum/bulletin board for questions that may come up in the field. For example if a person in the field needs to know the best product and best practice for a certain application they can ask in the forum for any experience, and lots of people participate. Another example would be if someone had a new client, they could ask if anyone else had experience in dealing with them.

We also have a number of reference pages built with SharePoint on a number of our products, regions, and other general items. On these pages we have links to our classification structure so users can easily find submissions.

We keep a list of subject matter experts who may be able to help or answer questions on various things. We also write papers on various subjects that may be needed. We get most of this data from subject matter experts, we are just in charge of compiling the data and writing the report or document. We host technical lunch seminars on various subjects.

Right now our effort is really focused on subjects for the field, we'd like to expand this to engineering, manufacturing, and other aspects of the company. At the moment we are a small group, only 4 people, but we should be hiring more people soon, the parent company really wants us to expand and get KM going.

Submitted by matt porritt on Thursday February 26th, 2009 8:52 am

I think your key here is getting people involved. You already have the technology and methods, you are now looking at the culture, "the way we do work around here" of the other departments they want you to roll out to.

I would start with an assessment of the culture of the other departments. You need to find out how KM can help people (specific, individual positions) do their jobs better and experience more success faster through KM.

How can people take little initial steps or changes in their work and be rewarded big time by plugging into the KM methods you have set up?

So for an assessment you need to find out what drives people to perform in their jobs, and how they could be better and more successful if they had the info you serve up with KM.

Start by interviewing people in each department. I would do a vertical slice and be sure to not only interview managers and directors, but get some time with the people that actually do the hands on stuff (front line). The front line workers are always the most honest, and it is especially important if they are doing a good deal of the participating in the KM system.

Ask these questions to determine what is valuable to them at work and what needs they have for knowledge management:

"What do you like to work on?"
"What work do you put off?"
"When do you know something is very important or serious?"
"Do you get enough information to do well around here?"
"Could you do better if people kept you better informed?"
"What is something you wish you knew more of before you do your work?"
"What information/feedback do you get or create in your job that should be kept or shared?"
....and so on....

Also ask general questions to get a feel for how the departmental culture is perceived.
"What's it like to work here?"
"What's the culture like?"

Come back together and think about the KM needs of each position and level. Put together your KM methods. Get people to take those little steps or little changes and make sure they are met with the full benefits of participating in your KM system once they do.

Submitted by Douglas Elmes on Monday March 16th, 2009 11:52 pm

Below is the introduction for a paper on Knowledge Management I wrote late last year.  I have left a quotes and definitions in there as well.  You might find this useful.
Knowledge Management (KM) was established as a discipline in 1995 and has become a widespread business practice within companies across the world.  KM comprises a range of practices used by an organisation to identify, create, represent, distribute and enable the use of what knowledge it knows, and how it knows it.

The purpose of knowledge management is to improve the effectiveness of decision making and to create the conditions for innovation.
Information Management is the management of the capturing, recording and storing of information resources of an organisation and involves the management of the technology platforms it resides in.  Knowledge Management is the creation and acquisition of new ideas and new patterns, the codification of knowledge, and the capturing and transfer of knowledge between people in the organisation.

"Knowledge Management is the discipline of enabling individuals, teams and entire organisations to collectively and systematically create, share and apply knowledge, to better achieve their objectives"
Ron Young, CEO/CKO Knowledge Associates International

To successfully implement KM, a holistic view needs to take into account four important dimensions:
1.    People: This needs to address personal motivation, recognition, and incentives for knowledge sharing
2.    Processes: This needs to address how knowledge is captured, validated, approved, and expired
3.    Organisation: The organisational culture, availability of specialised roles and policies are all a critical aspect to achieving success.
4.    Technology: This underpins the strategy and helps deliver knowledge to those who use and reuse it.
 
By addressing these four dimensions holistically, we ensure that we capture both tacit and explicit information at all levels as outlined in the ASHEN model (Snowden).

There are two forms of knowledge:
•    That which resides in our heads is called Tacit Knowledge
•    That which is written down and stored in forms that are accessible, is called Explicit Knowledge.

 
Research preformed over the past few years has concluded that something between 50% and 85% of the knowledge in an organisation is tacit, i.e. only available through people. Other research has also shown that much of the explicit knowledge is inaccessible - locked in systems that people cannot readily get at it.
 
Using the ASHEN model, knowledge can be divided into five additional categories; Artefacts, Skills, Heuristics, Experience, Natural Talent.  Each of these areas of knowledge is comprised of either tacit and explicit knowledge or combinations of both, and need to address differently within the organisation. 
•    Artefacts – codified, explicit, recorded data, information and knowledge
•    Skills – Tacit knowledge of which we can tangibly measure the successful acquisition
•    Heuristics – Rules of thumb that can be articulated without the need to be made fully explicit.  Effective ways by which decisions are made when insufficient information is available
•    Experience – Tacit knowledge that may be collective rather than individual, and may not be able to be easily replicated; heuristics with observable outcomes over a long period of time.
•    Natural Talent – Is not manageable as it is inherent in individuals, but we can foster its development when identified.  We cannot manufacture or transfer it between individuals
 
Because not all knowledge can been easily codified and made explicit and recorded in formal system, it is also important to ensure that there are other methods of knowledge transfer available in an organisation.  This can be done through the use of tools that help facilitate communities of practice and other methods of collaboration.  This will assist in the transfer of rules of thumb, and the experience of people within the organisation.

"We can always know more than we can tell, even after we have told it and we can always tell more than we can write."
Polanyi

Data:  discernible, recognisable states of the world;
Information: states of the world that is relevant to us and extracted from data.  Information is contextualised, categorised, calculated, corrected and condensed;
Knowledge:  the capacity and disposition to perform internal interaction with data and information.  People have an intuitive sense that knowledge is broader, deeper and richer than data and information.  It is the highest level at which one can and does work.

Knowledge is constantly changing and evolving.  It moves continuously between tacit and explicit knowledge, and the path it follows to do this can be broken down into the following four core transformations:
•    Socialisation
•    Externalisation
•    Combination
•    Internalisation
Figure 1 – The Four Knowledge Transformations
 
Socialisation is the transfer of knowledge between people across the table, in meetings, and so on.  It has many advantages, primarily personal, and can be adapted to suit the circumstances and the understanding and the responses of those listening.  However, outside of the exchange, nobody else gets to know anything.
Externalisation is where we either capture the knowledge, or verbally share it, so that it can be made available to a much wider audience.  Whilst this enlarges the recipient knowledge base, the downside is that the lack of personal interaction may lead to misunderstandings and misinterpretations, and a loss of context.
Combination is where we have the opportunity to classify and combine the knowledge with other knowledge.  This allows us to see associations with other factors, and is here where we can truly extract knowledge from what was previously just information.
Internalisation needs to occur before any knowledge is able to be used. In order to use knowledge a person needs to understand and internalise it.

"Knowledge is only ever volunteered: it cannot be conscripted"
Drucker

 
"Most valuable knowledge is only known when it is needed to be known."
Snowden

 
"Control only what you need to control"  No idea who said this.. but I certainly do. 
Regards
Douglas
 

Submitted by Douglas Elmes on Monday March 16th, 2009 11:59 pm

To help create a knowledge sharing culture rather than a culture focussed on knowledge control it is important to only control that knowledge that you need to control.  The harder you make it for somebody to contribute the less likely they are going to.
What I mean by this is.  If you have a knowledge base that allows a member of a business unit to create a document that they intend to be viewed by their own business unit only, then you only need minimal controls.  Those controls could be as simple as if they create a KI it is instantly viewable by all other member of the business unit.  Until a peer reviews it the document comes up with a "This document has not been validated" flag.  Once it has, it gets a Validated Flag.
If you want lets say, your branch to be able to see the document, it will require a higher level of authorisation than a peer, and if you want it to be visible to your customers, it needs an even higher level of authorisation.
And you make the ability to edit a document just as easy.  Any member of a team can edit a document that is only within your team (but with Audit controls recording who edited it etc)
Regards
Douglas.