Tag and Ye Shall Find?

MagnifyingGlassI just read a good summary of taxonomies (formal, forced-choice method to categorize information) vs. folksonomies (organic tagging method to organize information) in KM World; this author felt they were not equal and definitely not interchangeable. I am really glad someone has formally stated that.

Tagging does not necessarily create a repeatable, easy-to-find organizational structure. Tagging is great if your objective is to raise the most popular items to the top, which might work for certain organic sharing like in forums, blogs or social network sites. I have played with both and have found that there still is a need to have a standard classification method to help people find information especially for formally published items, like documents.

Now, that standard taxonomy must be maintained, reviewed and updated to reflect new products, programs and vernacular within an organization. Too often, a taxonomy is set and forgotten about until five years later no one can find anything because a product is no longer called “value statement” but, rather, “value proposition”.

One way to compensate for those changes is to create a synonym in your search tool so that they equal each other. This is why I am such a big fan of search. However, in the workplace, I have observed that many people prefer to browse over search.  Yet, in their personal lives, they would never browse the Internet, they use Google. This is a really astounding phenomenon to me and one that deserves a good deal of change management attention.

Until internal search becomes perfected, a sound taxonomy is needed but so is tagging. I still balance both. I ask users to select a formal category but also allow them to free-form tag the document as well. Those tags provide valuable insight into how people might search for information and how we may need to evolve the taxonomy!

Is Records Management the Same as Knowledge Management?

Many organizations separate Records Management from Knowledge Management because they are seen as two distinct functions. There are many differences between the two – one is focused on retention and standards while the other is focused on collaboration and bubbling up good information for active use. However, there is certainly overlap in very important areas that businesses need to consider. Organizations that separate the two functions could be taking on risk they may not have planned for.

At a minimum, Records and Knowledge groups need to be talking to each other if not organized on the same branch of the org chart. They are two sides of the same legal coin; they both facilitate and manage content – content that should be findable by people in their organization and can be discoverable in a lawsuit. Search and e-Discovery are booming businesses today and both functions need to work together to establish policies and processes to provide for both.

RM_KM_chart

Here are some key strategies to ensure findability and discovery needs are met:Establish lifecycles for each type of content. A sales proposal may be a good example of a current strategy and have a short lifespan in a Salesperson community but what if it leads to actual client work? Then, it should be formally versioned, archived and retained per the client agreement. Content lifecycles and uses are key elements to define together.

  • Define where each type of content should be stored. What should go in a community site vs. the Document Management system? Should client information be stored in the sales wiki or the CRM database? Where content should be stored has a lot to do with its lifecycle and purpose. For example, Facts and figures about a client should go into the CRM for people to find it; but where the client likes to play golf may not be essential but helpful information and could go in a wiki.
  • Set up governance and roles and responsibilities that naturally break along people, process and technology lines for the two groups. For example, Records should be the managers of standards, document naming conventions, lifecycles and policies; Knowledge should be responsible for community oversight and strategy, collaboration tools, sharing processes and capturing lessons learned. The two groups should collaborate on taxonomy development! Which leads me to my final point…
  • Mesh taxonomies to reduce confusion. Both groups should focus on taxonomy development and be aware of changes made. Knowledge people may feel folksonomies are more effective, organic and collaborative. Regardless, there will be a common vocabulary, common high-level categories, industry lists, client lists, however content should naturally be organized. These two groups must work together to ease the burden on the user. Having identical or very close taxonomies also helps if content from a document library on a collaborative space actually needs to move into a formal records repository.