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.