Publish Content or Knowledge About Content?

As an extension of the discussion on when to publish content or pointed to content, we can think to a few different buckets when thinking of how to codify knowledge. Or should I say "when to codify or not codify".

Codification was part of Arthur Anderson's problem in the 90's. They built a large repository, capture a hord of content, and then realized they needed to thinking about usage. And of course, integration with existing business processes.

In Financial Services, the ability to share information about deals in progress or even closed can be difficult since information about the company and its strategy can be included in case studies and pitchbooks. This information may not be shareable for many reasons, including another Deal Team working with a competitor in the same industry. Thus, the conversation around santization. Even sharing information in Case Studies around Product Strategies used can be equially difficult for the same reason.

Santization is one answer. As we have learned at Morgan Stanley, this is a huge barrier. It requires manual effort by Investment Bank Analayst and Associates to scrub the data and allow it to be posted. Without the right performance incentices in place, no one is compelled to spend the time doing it. Other options include:

* Devloping a central content publishing group to scrub the data. Both costly and injects time delays. Offshore is probably not an option due to data sensitively. A central group was tried here, but got disbanded during the 2008-2009 downturn.

* Putting in place an automated scrubbing process. We have never attempted this, but while entities like blinding Company Names can be easily done, knowing which numbers, charts and deal details need to be taken out or blinded requires manual oversight of someone on the deal team familiar with the deal.

This leads me to the 'buckets'. Some content is easily captured, codified and made searchable for re-use. And other content is not.

Bucket 1 - Explicit Content (Not Sensitive)
This is perfect for codification, storage, tagging and re-use

Bucket 2 - Explicit Content (Sensitive or Difficult to Stage)
In this case, the content is available, but is either too sensitive, requires too much manual intervention to reformatted, or if in a format too cumbersone to stage. This is perfect for codification, storage, tagging and re-use

Bucket 3 - Tactic Knowledge
This is either information that people know in their heads about clients, processes, or products that is not currently codified anywhere.

If your content falls into Buckets 2 and 3, rather that tried to capture everything, a simple template that briefly describes the best practice or product strategy might be the better answer. This could be as simple as:
- Problem We Were Solving For
- Solution Used
- When This Strategy Would Make Sense
- Contact Information
- Keywords for tagging

By doing this, others can understand the strategy without knowing anything about the deal of client. They can then follow up with the person(s) listed as Contacts to learn more, and that person can assess what is relevance to be shared.

Bottom line, knowledge management is NOT all about storing content. It's about managing a company's Intellectual Capital. Sometimes this can be done by storing content for search and re-use, other cases by providing summaries (as described above) for sharing who know's what or what has been done with the goal of connecting people, and in other cases, just connecting people.

There are lots of reasons by the capture of explicit content is not always the answer. In our current 'Google' world, we have the tendency to want to frame all content problems in terms of search and retrieval, but strategies for sharing and optimizing intellectual capital are much broader.