A Process for Defining Processes / Understanding the Layers of KM

Someone recently asked me how I would go about defining a repeatable process for identifying, designing and implementing Knowledge Management processes. As I mentioned in my definition of KM, I am averse to defining a one-size-fits-all KM process, because although there are some commonalities and reoccurring themes, the needs differ from company to company and even between organizations within a single company.

However, the best methods for identifying and addressing those needs are probably quite consistent.

A standard approach for developing KM processes follows the same general outline as the methodologies for information architecture or solution architecture. The first step would be requirements analysis, including audience definition, task and gap analysis, etc. The difference would be that you are not looking at only a single business process you are trying to optimize. You need to look at and prioritize several "layers" of knowledge flow around the business. Which ones are important depend upon the organizational culture and the nature of the business processes. However, the layers that come to mind right away are:

• Knowledge within the business process. How to optimize knowledge sharing within the business process. The example from my current work in the systems integration (SI) business -- where the business is customer/project-based -- is the use of SharePoint spaces (WSS) for team collaboration. This is usually the easiest layer to identify.
  
• Knowledge about the business processes. How to optimize knowledge sharing about what business is being done. This is where businesses often have a gap. They know their processes, but what is actually being done within the process? This is either not known or scattered in multiple locations. Again using SI as an example, what projects are we doing or have we done? From a management perspective, there are management databases like SAP that are supposed to take care of this. But they tend to be high on numbers and short on context -- which makes them a poor source of usable knowledge about the projects themselves. (Besides which, they are usually inaccessible to most employees). So a more open alternative often needs to be developed, as well as ways for practitioners to share reusable content from one project to another.
  
• Knowledge among practitioners. Optimize the ability for sharing among those with common interests, across the business. This is traditionally where Communities of Practice reside. However, it can take time for CoPs to develop, so there are a number of interim steps that can be taken to encourage knowledge sharing (such as forums, PDLs, informal gatherings, and more recently blogs and wikis).
  
• Finally, knowledge about the business itself. Business structure, who's who, what they sell, etc. This usually doesn't fall within the KM domain, since it gets covered by the corporate intranet or other organizational functions. But I include it for completeness, because if it isn't covered already, it will then be a need within the KM domain.

There are probably other layers as well, but I think these are the big four.