The Limitations of SharePoint as a Knowledge Management System

Originally posted 7/18/2013 on the Inmagic blog

SharePoint seems to be everywhere these days. Many customers have been told by their IT departments that their knowledge management repositories should or will be converted to SharePoint by IT. Many customers are resisting this request, but often find it difficult to make IT understand that SharePoint is not capable of performing some of the functions that are important for managing and organizing content.

This lack of understanding by IT is often due to their “forest”-level view. They sometimes assume that because SharePoint is a text database with integrated search, conversion will be easy. But, as information professionals know, the devil is in the details.

So how should you respond?

The following are examples of the kinds of items that SharePoint implementations often lack and cannot do. This is the “tree”-level view of managing content. The list is not all-inclusive, but covers just a few of the many items that SharePoint lacks and that IT will find very hard or impossible to provide when they “convert” your database out of its legacy home.

1. SharePoint does not provide the alpha numeric sorting you need.

2. SharePoint will not properly sort items with leading articles.

3. SharePoint does not know how to deal with “fuzzy dates.”

SharePoint is not able to properly sort or search for “fuzzy dates” such as:

• June 2010
• Spring 2011
• 2012

SharePoint can handle dates in a DD-MM-YYYY format, or “Spring 2011” as text. However, it cannot sort “Spring 2011” so it falls between January 2011 and June 2011.

4. SharePoint’s multi-value fields (repeating fields) are very primitive.

In SharePoint, multi-value fields are a “single string, in which the values are separated by special characters.” The field is not sortable.

Information professionals need multi-value fields where:

• The field can be sorted.
• Each entry (value) is treated as if it was not in a repeating field. For example, if you have a book database with a multi-value author field, you need to be able to:

Create “see also” links for each individual author (e.g., find other books by each author).

Use “linked records” that allow each entry to function as a lookup within another database, so that users can see details about each author easily and quickly.

• Each entry can be an individual filter within faceted search results.
• The display of the entries can be carefully controlled. The field should not be treated as a “blob,” for example:

Mark, Twain

Clemens, Samuel

OR:

Mark, Twain; Clemens, Samuel

5. SharePoint does not support authority control (via a thesaurus) during data entry.

SharePoint is good at many things, but our clients want more precision out of their information management systems. They want a system that understands that some periodicals come with the date of “Spring 2013” and books are often written by multiple authors. Sorting needs to be intelligent; otherwise, users will not find what they seek and the system you have built will not serve its intended purpose.